So your phone would be continually sending out the keys to your car, for anyone to intercept, record, and replay? I would hope that the unlock would need to be a 2-way sequence (challenge / response), at least, perhaps preceded by a full pairing and exchange of security keys.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
If they use iBeacon technology, then the car would constantly be sending out a low powered signal advertising itself. The phone would be configured for the Tesla app to handle it, and would then be able to connect and set up a more secure communications channel. This channel would be encrypted with a key that was setup during the pairing process and be completely* secure. The processing power of the phone could actually make this process much more secure than a normal fob, as it would be trivial to thwart replay attacks.
*as secure as anything can be
Ok,so that makes it 2-way and encrypted, which is what I was hoping for. But I have an Android phone... iBeacon for Android?
Edit: Still doesn't solve the issue with too much range, but progress. We really need more info from Tesla on how exactly this works.
You can have connectable beacons for 2 way communication.
Another option is a rolling code based on current time, so no repeats (cell and gps could both provide the time sync). This way there is minimal delay for comms in the fast approach, long arm, door open scenario.
iBeacon is an open standard, and google also has a competing technology (Eddystone). I have no idea if they are actually using iBeacon, but it’s technically feasible.
Range can be mitigated by testing round trip signal time (like Apple does with Apple Watch unlocking). Possibly also with signal strength (although based on interference that might not be as reliable).
However, I would argue that we want longer range for the initial connection, then once connected they can test for distance. That way by the time you get close to the car the connection has been established and there won’t be any delay before the doors unlock.
I do agree, more information from Tesla would be nice! Or at least some owner videos showing how it works.
I think Android 5.0 and ios 7 both allow phones as beacons. Signal strength is fairly good at range detection, especially at short distance, same sort of thing the S and X fobs do.
It's been stated by many Model 3 reviewers that the RFID card will have to be "swiped" across the B pillar to open the car. Had to basically almost touch the pillar. So you will have to take it out of your wallet to open the car.
508 posts (Including mine) speculating about how Model 3 unlocking/locking will work, and no end in sight...
AlanSqB
Dog Chauffeur
If only there were 30 or so of them out in the public where people could test them to their hearts content.
WHERE ARE OUR YOUTUBE VIDEOS?!?!?!?
You can rssi (signal strength) a Bluetooth module without/ before connecting. However, it requires a scan which is power hungry and can interfere with other BT things happening on the phone.
I built a proof of concept system with a normal BT (non-beacon). It worked ok, phone orientation differences made rssi flaky, but could get decent proximity detection.
Yes, the car would be the beacon. The phone would be configured to take action when the beacon is detected.
The two factors I see influencing the setup are battery usage and reaction time. The phone has the smaller battery so I would lean toward the setup that reduces its energy usage. From a short Google romp, it appears being the transmitter is lower power (due to duty cycle), but I'm not seeing that iPhones can transmit in the background, but they can scan in background since 7.1. So there may not be a choice.
Timing wise, that goes to polling rate/ battery usage again. Ideal would be short bursts from phone, and communication instantiation from the vehicle.
However, it seems the newer phones are not impacted heavily by beacon scanning, so vehicle as beacon and phone as scanner may be the way to go. Probably more popular for users too, since they are not transmitting "I have the tesla app" all the time.
I have done BTLE beacons before iBeacon protocol even existed. And again, they are not instant detection. On iPhones, 90% percentile detection occurs within 10 seconds, on android devices, its longer and very inconsistent between device manufacturers, and some, outright terrible. Even then there are other issues like device is monitoring too many iBeacons, then the delay is much longer. Other issues include temperamental things like if the user kills the app from task switcher, iOS prevents the app from waking up in background from things like beacon region entry (ibeacon detection) and other host of things that make it good enough for non-mission critical tasks.
Opening a car door while phone is in pocket is mission critical IMO. Working 95% of the time is not enough. The 5% will annoy the crap out of users.
Agreed, polling rate vs transmit rate vs energy usage then pile on device/ operating system overhead....
There was a reason I used android for my test system. I see app support being a potential headache for Tesla.
voip-ninja
Give me some sugar baby
Nobody who has one has any incentive to do that, is connected to Tesla and has probably been asked not to.
Will take first 'civilian' owners for that to happen.
{sigh} Ok, so we're probably not looking at iBeacon as the underlying technology, but are any of the others any better? Worse, wearing an admittedly borrowed "security hat", it would be risky for Tesla to roll their own... Too many stories in the past of folks inventing their own security architecture, only to have built new vulnerabilities too.
Liking the key card as the primary key more and more...
Liking the key card as the primary key more and more...
