In less-sophisticated times, it was enough to lock the doors and to fit ignition and steering and or gearshift locks. However, thieves and joy riders have learnt to bypass such technical hurdles (especially if the owner/operator has failed to engage one or more of them) so lawmakers have mandated it necessary to increase the level of technical protection against unauthorised use by the nefarious fraction of the population. That’s the nefarious fraction who want to use the car, not the lawmakers.
Immobilizers prevent a car from being used if the mechanical locks have been bypassed. They operate by preventing the engine from being started or frustrate vehicle operation by e.g. stopping the engine after a short time.
The proposed implementation is to prevent starting in the first place by not starting the fuel pump, engine management system (controlling injection and ignition) or the starter motor if the immobilizer is engaged. Frustration, if all 3 measures have been bypassed, is possible by e.g. turning warning lights into a merry display and causing the gauges to “wobble” in a doom-saying manner.
The immobilizer may be armed after a certain period of the engine being switched off and/or the car being locked.
How do we know that the person is authorized?
I’m glad I asked. 😉
Rolling-key systems such as the proprietary Key-Loc® have been demonstrated to be weak. A stronger system for authentication is needed which entails bi-directional communications.
Recent developments by chip manufacturers provide secure SHA-based authentication that is difficult to breach (e.g. Atmel’s ATSHA204) at low cost and easily interfaced with low-end microcontrollers. Chips have unique serial numbers and can generate their own secret keys to use in authentication. The authorised operator carries one or more such chips and at least one chip is in the vehicle network. The chip in the vehicle which knows what other chips are authorised but the other chips only know about themselves and the one in the vehicle.
Communications can be encrypted using e.g. AES.
Wireless communications can be implemented to run in bursts at speeds of up to 2Mbps (using e.g. a Nordic nRF24L01 transceivers) which makes snooping more difficult. Replay attacks will be fruitless as authentication is unique each time that it occurs.
Wired communications via USB-serial act as a fall-back in the even of the wireless device having a flat battery or due to wireless communications not being possible.
The problem of determining that the holder of the authenticating device is authorised doesn’t go away because authorisation is still based on what they have, not what they know. Basically, it’s a second key. But such appears sufficient for the lawmakers who want to be seen as doing something.
It’s easy to implement a challenge-response system with a microcontroller for greatly improved security, where the authorised user knows the correct responses to a small set of challenges.
A keyfob is used for both wireless and wired operation.
The authentication chip is to be built into a keyfob for attachment to a keyring, along with a wireless transceiver, microcontroller and (concealed) USB port. There may be a small vibrating motor in the unit. (Exact mechanicals aren’t yet defined).
The top surface of the keyfob features a central button surrounded by a ring with several button areas and 4 LED-illuminated areas.
Locking and unlocking is done by pressing the middle button whereupon the LED’s light up in an anti-clockwise sequence until the controller in the car responds with its authentication acknowledgement, or until the unlock sequence times out for lack of response. Should the remote unlock/immobilizer have been configured for something-you-know authentication (SYKA), then one of the 4 LEDs will continue to blink. The user must then press a button that corresponds to the blinking LED; which isn’t necessarily the one that’s blinking. Unlocking occurs if the correct button is pressed within a couple of seconds. The response is sent encrypted.
There is a 1 in 5 chance of a guess being successful. The unlock sequence must be restarted if an incorrect button has been pressed. Authentication is slowed by delaying the car’s response in issuing the challenge, delays increasing exponentially. The keyfob’s receiver is kept awake by intermittent padding packets sent from the car. Successive challenges illuminate a different, random LED, slowing access by unauthorised persons who have “found” the keyfob.
The car remembers each keyfob’s individual status.
SYKA can be improved by adding a second challenge to the sequence. The user must respond to both challenges successfully but is not made aware of the success or failure of the first response. That makes working through the possible combinations even more tedious. The additional inconvenience may be worth it for the vehicle owner.
If the battery in the keyfob is flat, or it’s undesirable to operate wirelessly, the keyfob can be detached from the keyring, a USB plug folded out and the keyfob plugged into a socket on the dashboard. That socket is wired to the immobilizer which will then conduct the authentication process over USB-serial; data being encrypted between the keyfob and the immobilizer.
Wired Wireless Network
Plugging the keyfob into the USB port of a computer provides an encrypted wireless connection into the car’s network. After plugging the keyfob into a computer and opening the corresponding serial port, pressing one of the ring buttons will start authentication with the car, without unlocking the car. Authentication follows the same protocol as for other modes.
Once authenticated, the keyfob provides an encrypted path to the car network for diagnostics, configuration or vehicle monitoring. Access may be restricted, depending on which keyfob is being used, privileges being set in the immobilizer module.
Keyfobs need to be registered to the immobilizer. The process is conducted in wired mode with the aid of a “root key device” (RKD). The RKD is not a keyfob that can be used to perform any function other than to authenticate keyfobs. The car is immobilized while the RKD is plugged in.
The RKD is plugged into a special port on the dashboard and the keyfob to be branded is inserted into the USB port for wired operation. The ignition key is switched on. If the keyfob is already known to the immobilizer, not much happens. Lights on the keyfob will simply blink to indicate that the keyfob is registered.
If a keyfob is not known to the immobilizer, then digital key exchange takes place for future authentication by that keyfob. Lights on the keyfob will blink to indicate completion of the process.
Should the immobilizer have been configured for something-you-know authentication, then the responses to challenges can be taught individually on each keyfob once it’s registered. Each LED on the keyfob will, in turn, blink rapidly until one of the buttons is pressed to teach the user’s response to a challenge of that LED. They teach cycle repeats to ensure that the user got it right.
The ignition must be switched off after each keyfob has been registered/taught and remain off until the next one has been inserted. The immobilizer module will “complain” if the ignition is switched on without a keyfob in the USB port, and the RKD is connected.
Keyfobs may be registered to more than one “immobilizer”. This allows e.g. the same keyfob to be used to securely open or close a garage door.
When a keyfob has been stolen or lost, it must be de-registered to prevent unauthorised vehicle use. The RKD is not required for this process.
A registered keyfob is inserted into the USB port and the ignition is switched on. Authentication proceeds but instead of starting the car, a pre-defined sequence of buttons is pressed on the keyfob to place the immobilizer into de-registration mode.
Lights will blink on the keyfob to confirm that it’s being remembered and remains registered. Switch off the ignition once that happens, remove the keyfob and insert the next remaining keyfob and switch on the ignition within 10 seconds. Wait for registration to be confirmed and repeat until all keyfobs have been presented.
To abort the session switch the ignition on within 10 seconds without a keyfob plugged into the USB port. All previously registered keys will remain registered.
After the last keyfob has been removed, leave the ignition switched off for at least 30 seconds. That will cause the immobilizer to “forget” any keyfobs not presented during the session.
Root Key Device Security
The RKD should be stored securely, away from the car. If the RKD is lost, then all the LINbus nodes and keyfobs that know about the immobilizer must be re-flashed. This provides a hurdle to car thieves equivalent in height to regular, manufacturer-based lost-key management.
The immobilizer will generate a new key using the digital key of the replacement RKD when first powered up and an RKD connected. If LINBus nodes are also equipped with SHA hardware and aware of an immobilizer, they will initialize accordingly as they register to their respective cluster.