Modern cars are essentially software on wheels — “smart” collections of automotive systems, including entertainment, braking, power, door locks, window controls, and so on. As the number of Electronic Control Units (ECUs) in vehicles explodes, so do the number of lines of code, presenting a rich field of opportunities for hackers.
In turn, key fobs, the small hardware devices with built-in authentication used to control and secure access to the vehicle, have proven to be low-hanging fruit for cybercriminals looking to attack vehicle systems.
As with other vehicle systems, key fobs are becoming increasingly complex with an array of supporting features. Key fobs not only unlock the car doors, disarm the security system, and enable the ignition controls, but can be used to lower windows, open a sunroof, fold in mirrors, and set seat locations and radio channels. Tesla Model S and Model X key fobs can even be used to initiate automated parking and unparking sequences. Hit “Summon” on the key fob and your Tesla comes to you!
These features make key fob encryption a very attractive target for cyberattacks. The increased functionality results in more data being transmitted over this interface, which means more data for hackers to analyze when trying to break the encryption scheme and clone the key fob.
How Key Fob Encryption Works
Most key fobs use a Radio Frequency IDentification (RFID) transponder to enable it to unlock the vehicle and perform a variety of additional functions.
- The key fob sends encrypted data to the vehicle; this is often a rolling code that allows the vehicle to ID the key fob.
- The vehicle then decrypts this data and uses the decrypted data to authenticate that this particular key fob should unlock this vehicle.
- Authentication is performed by the vehicle immobilizer, an anti-theft system within the car. The car cannot be started until the immobilizer successfully authenticates a key fob to prevent hotwiring of the vehicle by car thieves.
A variety of attacks have shown that this encryption can be broken, allowing the key fob to be duplicated by an unauthorized party who can then unlock the vehicle and drive off just as the owner would. These attacks defeat the encryption used between the key fob and the immobilizer, resulting in a serious security breach.
While there are many different key fobs in use, most utilize similar underlying technologies in their implementation, and in some cases, even the same chipsets. Most key fobs use a form of symmetric encryption. Before diving into the details on the key fob security vulnerabilities, let’s take a closer look at symmetric vs. asymmetric encryption.
Asymmetric vs. Symmetric Encryption
Most security protocols and systems employ both symmetric and asymmetric encryption. For example, SSL/TLS uses asymmetric encryption to securely exchange a secret symmetric key at the start of a session. Subsequently, SSL/TLS transitions to symmetric encryption using the secret key established during the key-exchange process. The reason for this approach warrants some explanation.
Symmetric encryption is conceptually straightforward. It uses a single secret key that is shared by both communicating entities (see Figure 1).
The problem, of course, is how can keys be exchanged without someone or something intercepting them? That is where asymmetric encryption comes into play. It allows the symmetric encryption key to be securely exchanged.
Asymmetric encryption uses a key-pair consisting of a public key and a private key (see Figure 2). Each node has its own key pair. The private key must be protected and kept secret, but the public key can be shared with other nodes.
Key-pairs are created in such a way that data encrypted with a public key can be decrypted only with the correct private key, and vice versa. If Device A wants to send data to Device B, then Device A can encrypt that data using Device B’s public key. That data can only be decrypted using Device B’s private key. Only Device B knows the private key, so only Device B can decrypt the message.
All key-pairs are mathematically related to enable encryption/decryption in this manner.
It’s critical that the private keys are never exchanged; only the public keys. The mathematical relationship between the public and private keys ensures that data encrypted with the public key can only be decrypted together with the private key. It can be decoded only with the intended receiver’s private key.
One major shortcoming of asymmetric encryption is that it can easily use 100x more CPU cycles than symmetric encryption. This processing load causes problems for any system, especially embedded devices that perform time-sensitive operations and/or have limited system resources. The solution is to run an asymmetric session only to create an initial encrypted connection for exchanging a secret symmetric key. Thereafter, that symmetric key is used for the remainder of the communication session.
To date, most car manufacturers have used a symmetric encryption scheme for key fobs, leaving the system vulnerable if the symmetric key is discovered.
Key Fob Encryption Failures
A Google search will quickly reveal a large number of key fob encryption failures that have occurred. Because automakers often reuse technology across model years, an attack found in one vehicle may impact other vehicle makes and models. Some of the vulnerabilities found in key fob systems include:
- Replay attack vulnerabilities: Hackers have been able to record transmissions from a key fob and later reply them to the same vehicle.
- Encryption keys generated from public data: In some cases, the encryption key is algorithmically derived from publicly readable information from the transponder, such as the transponder serial number. Once the algorithm is discovered, the key can be generated for any transponder.
- Insufficient entropy for generating encryption keys: Security keys must be random, but many key fobs don’t have access to enough random data to enable key generation. This has resulted in encryption keys that can be predicted.
- Discoverable encryption keys: In one key fob, the encryption key was stored in a 384 byte EEPROM, allowing the key to be discovered using a combination of an attack that read the EEPROM from the key fob and a brute force attack that attempted all sequences of bytes in the EEPROM for the encryption key.
- Deprecated key strength: NIST recommends key lengths of 128 bits or longer for AES encryption algorithms (symmetric encryption). Several key fobs utilize only 40-bit or 80-bit key lengths, resulting in solutions that are easily broken.
Improving Key Fob Security with The Right Hardware
The fundamental issue in each failed scenario was the attempt to utilize symmetric encryption algorithms for authentication by encrypting a shared rolling code used by the car to validate the key fob. Further, use of weak underlying encryption algorithms and other implementation issues exacerbates the problem.
Ultimately strong authentication is best achieved using asymmetric encryption. That is, after all, what asymmetric encryption was designed for.
To achieve strong security with key fobs, automakers must invest in hardware that will support asymmetric encryption, ensure that proper key lengths and algorithms are selected, and verify that all keys are generated using sufficient entropy to ensure they are truly random.
Improving Key Fob Encryption with the Right Software and PKI
An appropriate hardware solution is the first step toward building a secure authentication solution for automotive key fobs. This solution must be paired with an appropriate authentication solution that is not easily defeated. The use of asymmetric encryption with certificate-based authentication provides a strong solution.
Implementing such a solution requires a PKI solution to issue and manage certificates. Solutions such as Sectigo’s IoT Identity Management platform enable OEMs to quickly and easily implement a PKI solution that is scalable, easily managed, and cost-effective.
Unique Approaches to Vehicle Authentication
Apple is taking a unique approach to this problem. Apple’s iOS release 13.4 that became available to developers in February 2020 included a “CarKey API.” This API works with the Apple Wallet to enable the phone to authenticate to a vehicle’s authentication app. Because the phone will be authenticating to the vehicle app, the strength of the authentication will still be dependent on the car manufacturer’s implementation of the vehicle app.
That said, this does solve the problem introduced in many key fobs that were designed to be very low-cost. An iPhone has the built-in processing power and security capabilities to enable strong authentication without driving up the cost of the key fob. Additionally, Apple has consistently built strong security into its products and is unlikely to make the security errors that many key fob systems suffer from.
Other companies are also working on smartphone applications as well as implementing biometric authentication solutions to replace or augment key-fob-based solutions.
In short, cryptography is hard. New crypto schemes are widely accepted only after thorough and broad vetting by many security experts. Virtually all security critical systems utilize NIST-approved security algorithms with NIST-recommended key strengths. Any time a design ventures away from these approved and vetted security algorithms, there is risk of vulnerabilities being present in the solution. When adding security to a device, it is imperative to ensure the system is resilient to common attacks and to utilize a crypto scheme that is consistent with the security needs of that device. Using a crypto algorithm because it is low-cost or convenient is simply not good enough—especially for the next-generation of smart, autonomous vehicles.
You can learn more about automotive key fobs security by listening to Root Cause, episode, ”Automotive Key Fobs and Cryptography”.