PSA: Phone-as-a-Key Security Issue

[rosspa2]

I have a band for my car and I lock the fob in the car when I use the band, doing so disables the fob in the car. So even if some breaks in the fob will not start the car. I have to unlock with the band for the key to become active again.

As a few people have pointed out the right answer is to disable any "key" that is in proximity to the truck at the point that it is locked and don't reactivate them until you unlock the car with the a key that isn't disabled. This fixes the issue and ensures that someone can't just break a window and drive away.

Sponsored

 

[RivianBowerbird]

Are you certain that the Rivian app can turn on bluetooth on your phone if you have turned it off? I have never had the Tesla app do this to me. I just turn off bluetooth and put the phone in the pin protected glovebox (when it's cool enough to not bake in there).

 

[Craigins]

TL;DR BLE wasn't intended to be used this way, so the car can easily be tricked into using a phone that isn't yours.

Has nothing to do with BLE.

Just shitty implementation of "secure" communication. Switching to another RF frequency isn't going to magically solve anything.

Easiest way to do a semi secure verification is using public/private keys. Have the phone/fob sign a timestamp value and have the vehicle verify the signature, check that the timestamp is within x milliseconds, then record that timestamp as used.

Hard part here is keeping the clocks in sync. But that could be done by transmitting the time, encrypted, after a failed out of band transmission.

The idea here is keeping the time tolerance tight, so any attempt to relay would invalidate the request.

Encryption also drains batteries, so the FOB would drain batteries much faster.

 

[frostbit3]

Has nothing to do with BLE.

Just shitty implementation of "secure" communication. Switching to another RF frequency isn't going to magically solve anything.

Easiest way to do a semi secure verification is using public/private keys. Have the phone/fob sign a timestamp value and have the vehicle verify the signature, check that the timestamp is within x milliseconds, then record that timestamp as used.

Hard part here is keeping the clocks in sync. But that could be done by transmitting the time, encrypted, after a failed out of band transmission.

The idea here is keeping the time tolerance tight, so any attempt to relay would invalidate the request.

Encryption also drains batteries, so the FOB would drain batteries much faster.

Seems to be entirely centered around BLE:

https://research.nccgroup.com/2022/...ey-passive-entry-vulnerable-to-relay-attacks/

 

[Craigins]

Seems to be entirely centered around BLE:

https://research.nccgroup.com/2022/...ey-passive-entry-vulnerable-to-relay-attacks/

As the latency added by this relay attack is within the bounds accepted by the Model 3 (and likely Model Y) passive entry system,

They need to tighten the latency window. The article states it adds 8ms of latency, that is quite a lot. Tesla probably has a wider window to allow for a better user experience, at the cost of security.

Any RF signal can be relayed, it isn't just BLE. The article is focused on BLE because that is what tesla uses.

 

[godfodder0901]

Has nothing to do with BLE.

Just shitty implementation of "secure" communication. Switching to another RF frequency isn't going to magically solve anything.

Easiest way to do a semi secure verification is using public/private keys. Have the phone/fob sign a timestamp value and have the vehicle verify the signature, check that the timestamp is within x milliseconds, then record that timestamp as used.

Hard part here is keeping the clocks in sync. But that could be done by transmitting the time, encrypted, after a failed out of band transmission.

The idea here is keeping the time tolerance tight, so any attempt to relay would invalidate the request.

Encryption also drains batteries, so the FOB would drain batteries much faster.

They need to tighten the latency window. The article states it adds 8ms of latency, that is quite a lot. Tesla probably has a wider window to allow for a better user experience, at the cost of security.

Any RF signal can be relayed, it isn't just BLE. The article is focused on BLE because that is what tesla uses.

 

[godfodder0901]

Are you certain that the Rivian app can turn on bluetooth on your phone if you have turned it off? I have never had the Tesla app do this to me. I just turn off bluetooth and put the phone in the pin protected glovebox (when it's cool enough to not bake in there).

This is a permission that can be requested by the app in the Android ecosystem. Other apps that handle locking and unlocking do this as well (August for example).

 

[frostbit3]

They need to tighten the latency window. The article states it adds 8ms of latency, that is quite a lot. Tesla probably has a wider window to allow for a better user experience, at the cost of security.

Any RF signal can be relayed, it isn't just BLE. The article is focused on BLE because that is what tesla uses.

Okay I see my misunderstanding, I was under the impression that this device they developed was simulating the phone's bluetooth and able to trick the vehicle into thinking it was present. But as you said, it's simply just relaying it which has been a thing for quite some time. So as long as they're not able to clone and generate the signal, then yeah this appears to be no different than the same thing they've had for years with RF based proximity keys.

 

[Craigins]

Okay I see my misunderstanding, I was under the impression that this device they developed was simulating the phone's bluetooth and able to trick the vehicle into thinking it was present. But as you said, it's simply just relaying it which has been a thing for quite some time. So as long as they're not able to clone and generate the signal, then yeah this appears to be no different than the same thing they've had for years with RF based proximity keys.

Ugh i would hope tesla would be better than just MAC verification of ble devices.

What you originally thought used to be an issue, since many devices used to use that for verification, i think some older electronic door lock systems had that vulnerability.

The security issue is always going to be a balancing act. Encryption takes power, when working with remote devices, you have to budget power consumption.

 

[MRE]

Wow, quite the thread here. I'm an Android user and just don't let any of my apps turn connections on themselves, so killing Bluetooth (or just powering off) solves the issue. I'd also never dream of leaving my phone (as a key or otherwise) in my vehicle, and certainly not powered on if I did... But that's just me.

 

[Craigins]

Your phone is a key that you're leaving in your car...

Simple solution... put your phone (aka your key) in a faraday bag when you leave it in your car.

just turn off the phone at that point. You'll drain battery and overheat the phone on hot days as it searches for a cell signal.

i guess you could put it in airplane mode instead of turning it off. When I go up to northern WI i typically leave my phone in airplane mode with wifi enabled, otherwise the battery will drain in like 4 hours as it attempts to search for cell towers.

 

[howler99]

I don't think my truck has mysteriously unlocked, but when I have it in our carport, and I walk by sometimes maybe even 15-20 feet away it does unlock.

I'm not crazy about this feature, and I wish the wristbands were being shipped.

 

[RegReader]

I thought so too. I was testing some scenarios the other day and locked myself in the back seat with no seatbelt, and I don't see why there would be an airbag sensor in the rear seats. The vehicle never went to sleep, and I was in there for over an hour (waiting for baseball practice to end).

It's not an airbag sensor in the rear seat, but there is an occupancy sensor in the seat for seat belt reminders instead.

The front passenger seat has an occupant classification system (OCS) that tells the airbags how to deploy in case there's a small or large occupant, a child seat, someone sitting right on the edge of the seat against the dash, etc. This is required by regulation in the US, and incidentally currently being recalled on some R1Ts. Additionally, all vehicles in Europe (per regulation), and many in the US (not regulated here) nowadays have an occupant detection system (ODS) in the rear seats that is more basic and just indicates if there's something sufficiently heavy on the seat or not that could be a person. These are just used to support the seat belt reminders. Logic is something like IF seat = occupied AND vehicle = driving AND seatbelt = unbuckled THEN flash the lights and chime the chimes ELSE don't.

 

[SeaGeo]

This is a permission that can be requested by the app in the Android ecosystem. Other apps that handle locking and unlocking do this as well (August for example).

So, I was confused why my PAAK would only work after recently having opened the app as I hadn't disabled any permissions. Then I remembered I had turned off the permanent notification, which seemed to prevent it from the behavior you're encountering. Have you tried that as an interim fix?

 

[godfodder0901]

So, I was confused why my PAAK would only work after recently having opened the app as I hadn't disabled any permissions. Then I remembered I had turned off the permanent notification, which seemed to prevent it from the behavior you're encountering. Have you tried that as an interim fix?

Not that specifically. There are several ways to tackle this issue temporarily. I have decided to simply disable proximity unlock while at work until this is resolved.

Sponsored