Modern cars are essentially software on wheels—“smart” collections of automotive systems, including entertainment, braking, power, 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 cyber criminals looking to attack vehicle systems.
As with other vehicle systems, key fobs are becoming increasingly complex, supporting an array of features. Key fobs not only unlock the vehicle 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 process is:
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 can’t be started until the immobilizer successfully authenticates a key fob to prevent hotwiring of the vehicle by 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 many different key fobs are 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 security vulnerabilities in car key fobs, 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, Transport Layer Security (TLS) uses asymmetric encryption to securely exchange a secret symmetric key at the start of a session. Subsequently, 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 (Fig. 1).
1. Because symmetric encryption shares a secret key with the nodes at both ends of the network link, its security depends on the secrecy of the key.
The problem, of course, is how can keys be exchanged without someone or something intercepting them? That’s 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 (Fig. 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.
2. Asymmetric encryption uses public and private keys to provide a high level of security. Device A, to the left, uses the public key to encrypt data. Device B then uses its corresponding private key—the only key available—to decrypt the message.
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, and 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. 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 apply 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. This allowed 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 (National Institute of Standards and Technology) recommends key lengths of 128 bits or longer for AES encryption algorithms (symmetric encryption). Several key fobs utilize only 40- or 80-bit key lengths, resulting in solutions that are easily broken.
Improving Key-Fob Encryption—the Right Hardware
The fundamental issue in each failed scenario was the attempt to utilize symmetric-encryption algorithms for authentication by encrypting a sharing a 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 with asymmetric encryption. That is, after all, the intent behind asymmetric encryption.
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 make sure they’re truly random.
Improving Key-Fob Encryption—the Right Software and PKI
An appropriate hardware solution is a first step toward building a secure authentication solution for automotive key fobs. This solution must be paired with an appropriate authentication solution that’s not easily defeated. Use of asymmetric encryption with certificate-based authentication provides a strong solution.
Implementing that requires a public key infrastructure (PKI) solution to issues and managing certificates. Solutions such as Sectigo’s IoT Identity Management platform enable OEMs to quickly and easily implement a PKI solution that’s 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, available to developers in February 2020, includes a new “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 depend 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. In addition, Apple has consistently built strong security into its products, and they’re unlikely to make the security errors suffered by many key-fob systems.
Other companies are also working on smartphone applications as well as implementing biometric authentication solutions to replace or augment key-fob-based solutions.
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’s risk of vulnerabilities being present in the solution.
When adding security to a device, it’s imperative that care be taken to ensure the system is resilient to common attacks and to utilize a crypto scheme that’s consistent with the protection needs of the device. Using a crypto algorithm because it’s low cost or convenient simply isn’t good enough—especially for the next-generation of smart, autonomous vehicles.
Alan Grau is VP of IoT and Embedded Solutions at Sectigo.