It should all be local PKI over Bluetooth or something,
That would be a fun discussion. For a phone, it would be fine. For a key fob, we need something that could run on a PIC for a year without a battery change. We haven’t even tried to do anything new with PICs since 32bit microcontrollers got so cheap, but I’m not sure people would buy into something that had to charge to unlock their car.
I suppose using your phone wouldn’t be unreasonable. Maybe some of the better NFC as a backup?
Im not sure it would be to much to do. We already have Bluetooth beacons that can run for several years on a single small battery, reporting telemetry data every few seconds.
The key fob would only need to be active for a few moments a few times a day, so even if it was doing more work, it would be doing so much less frequently.
Depending on the ciphers chosen, they might be extremely energy efficient, since modern ones were often chosen as a standard with the requirement that they be able to be efficiently implemented in hardware.
Since we have the advantage of being able to be relatively certain that we can bring the car and the fob together, we don’t really need full public key, just the ability to verify the key to the car. Establishing a shared secret between the two and then using simpler symmetric ciphers makes it a lot easier
Those beacons are relatively insecure. Their narrowed down to the absolute minimum power consumption and aren’t terribly concerned with bluejacking or bluesnarfing. In the case of things like tiles, your cell phone is doing all the serious work. If you started asking most of this beacons to do even a little crypto their battery life would severely plummet.
You need to verify the key to the car but you also need to make sure that a replay attack can’t happen. You’re probably still going to end up with at least rolling code + psk as the shared secret.
If we stopped here, at this point, I’m not entirely certain we would have any advantage over the current systems. Thefts by rolling code stealing are pretty rare.
Ideally, you’d have the transponder send out a hey I’m here message, you’d have the car generate a challenge, have the transponder encrypt the message and broadcast it back. The car could then compare the challenge to the crypto response and unlock.
I see plenty of SSL accelerator chips, But I don’t see anything that’s quite as simple as a pic controller barfing some data into a buffer. Most of the stuff seemed purpose built to be tied into a full-on microcontroller.
Full disclosure, I’m not at work for a few months so I am far off my crypto system design game. I’m usually pretty good though. :)
Rather than full SSL I was thinking something along the lines of an hmac. Because we can introduce the two devices to each other physically we don’t need to worry too much about a full challenge response. It should be sufficient to send an hmac signed message with an always increasing counter to prevent replays.
Even if we went with challenge response, I think you could get acceptable battery life using symmetric algorithms instead of public key.
Bluetooth security fobs already exist that do far more than would be required for a car key, and they get a few months of battery life with typical daily usage.
I think something like NFC or encrypted RFID with the reader in the car would be nice, but would rely on the car having power which is another failure point. Really the best is just to have the fallback of a physical key like a lot of non-Tesla fobs have. Tech for convenience, physical for reliability.
Mostly I think it’s crazy that Tesla’s require an internet connection to unlock “from the phone”. You can’t just connect directly. It spawned an It’s Always Sunny episode when one of the guys had his Tesla fob stop working and then parked in a parking garage and “locked himself out” because the car didn’t have signal and it took days to resolve.
That would be a fun discussion. For a phone, it would be fine. For a key fob, we need something that could run on a PIC for a year without a battery change. We haven’t even tried to do anything new with PICs since 32bit microcontrollers got so cheap, but I’m not sure people would buy into something that had to charge to unlock their car.
I suppose using your phone wouldn’t be unreasonable. Maybe some of the better NFC as a backup?
Im not sure it would be to much to do. We already have Bluetooth beacons that can run for several years on a single small battery, reporting telemetry data every few seconds.
The key fob would only need to be active for a few moments a few times a day, so even if it was doing more work, it would be doing so much less frequently.
Depending on the ciphers chosen, they might be extremely energy efficient, since modern ones were often chosen as a standard with the requirement that they be able to be efficiently implemented in hardware.
Since we have the advantage of being able to be relatively certain that we can bring the car and the fob together, we don’t really need full public key, just the ability to verify the key to the car. Establishing a shared secret between the two and then using simpler symmetric ciphers makes it a lot easier
Those beacons are relatively insecure. Their narrowed down to the absolute minimum power consumption and aren’t terribly concerned with bluejacking or bluesnarfing. In the case of things like tiles, your cell phone is doing all the serious work. If you started asking most of this beacons to do even a little crypto their battery life would severely plummet.
You need to verify the key to the car but you also need to make sure that a replay attack can’t happen. You’re probably still going to end up with at least rolling code + psk as the shared secret.
If we stopped here, at this point, I’m not entirely certain we would have any advantage over the current systems. Thefts by rolling code stealing are pretty rare.
Ideally, you’d have the transponder send out a hey I’m here message, you’d have the car generate a challenge, have the transponder encrypt the message and broadcast it back. The car could then compare the challenge to the crypto response and unlock.
I see plenty of SSL accelerator chips, But I don’t see anything that’s quite as simple as a pic controller barfing some data into a buffer. Most of the stuff seemed purpose built to be tied into a full-on microcontroller.
Full disclosure, I’m not at work for a few months so I am far off my crypto system design game. I’m usually pretty good though. :)
Rather than full SSL I was thinking something along the lines of an hmac. Because we can introduce the two devices to each other physically we don’t need to worry too much about a full challenge response. It should be sufficient to send an hmac signed message with an always increasing counter to prevent replays.
Even if we went with challenge response, I think you could get acceptable battery life using symmetric algorithms instead of public key.
https://shop.ftsafe.us/collections/security-keys-ble/products/feitian-multipass-fido2-fido-u2f-usb-c-nfc-ble-security-key-k32
Bluetooth security fobs already exist that do far more than would be required for a car key, and they get a few months of battery life with typical daily usage.
I think something like NFC or encrypted RFID with the reader in the car would be nice, but would rely on the car having power which is another failure point. Really the best is just to have the fallback of a physical key like a lot of non-Tesla fobs have. Tech for convenience, physical for reliability.
Mostly I think it’s crazy that Tesla’s require an internet connection to unlock “from the phone”. You can’t just connect directly. It spawned an It’s Always Sunny episode when one of the guys had his Tesla fob stop working and then parked in a parking garage and “locked himself out” because the car didn’t have signal and it took days to resolve.