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.
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.