Overcoming threats to Vehicle Security

Introduction

The rise of fully autonomous vehicles may soon render car ownership obsolete, as ride-sharing companies like Uber embrace the concept of driverless cars. To survive, automotive manufacturers must develop business models that allow feature activation to be tied both to the user as well as to a specific vehicle. However, weak ciphers used in key signals and vulnerabilities within in-vehicle networks can be exploited by attackers to gain unauthorized access or steal the car. To address these threats, the Trusted Computing Group (TCG) has developed a secure access and feature activation system for cars, using a Trusted Platform Module (TPM) 2.0 as a hardware trust anchor in the vehicle to enforce the system security policy and secure the system against software and hardware cyberattacks. The TPMs Enhanced Authorization Mechanism is used to design flexible and secure access policies.

An Innovative System Design

There are three key elements of the model to consider: a backend system that manages roles, rights and issues policies, the car itself where access to feature activation keys is enforced based on presented policies, and the user, who carries an authentication token such as a smartphone capable of storing a signature key. Each element leverages a trusted component which stores and processes security-critical data. The TPM, which is especially hardened against logical and side channel attacks, is deployed as trusted component within the vehicle, as it is physically exposed to its environment and thus is the most vulnerable element in the system. In particular, the TPM is deployed inside the so-called ‘Function Controller’ – the electric control unit (ECU) of the car responsible for all external communications and enabling features.

Typically, a user registers with the backend system to bind an authorization key to their identity. This key is stored within a shielded location of their token. Once registered, a user can then obtain various features such as general car access and infotainment options, which are all bound to respective feature keys inside the TPM. Key usage is then authorized by downloading and presenting a respective policy at the TPM which at least has been authenticated by the backend system and bound to a user’s authentication key. Further restrictions can be embedded into the policy.

Designing Flexible Access Policies

To actively prevent unauthorized access to the car’s features, the TPM securely stores one key per feature. Depending on the use case, this could be either a decryption, hash-based authentication code (HMAC) or a signing key. Leveraging the ‘TPM2_PolicyAuthorize’ command allows to create valid policies after key creation, which can be successfully verified so long as their digest is signed by the backend. This ensures that only the backend can issue valid policies.

To ensure that key usage is only granted to the user to whom a policy was issued to, it needs to be bound to their unique authentication key. This is achieved through ‘TPM2_PolicySigned’ found in each user policy. During execution, the command will ask the authorizing party to sign a challenge, binding the policy to the user with the correct signing key and preventing authorization of any illegally obtained policy. It can also be used to assign roles and rights to specific users, with the backend creating a policy that activates features of a distinct role - a repair shop employee for example - and binding specific user keys to said policy to enable access to debugging interfaces of the ECU.

The presented policy may contain additional information like usage restrictions which can then be validated by the TPM once compared to Non-Volatile indices or internal clock values. For example, with ‘TPM2_PolicyNV’ the policy can be bound to counter value in the Non-Volatile memory of the TPM and with the ‘TPM2_PolicyCounterTimer’ command, a policy can be bound to timing values within the TPM, meaning policies can be made invalid before or after a specific value, enhancing the security measures of the vehicle. Revocation can be handled similarly to usage restriction, as the backend only needs to increment the counter within the car in order to actively revoke a policy and need to provide users with new updated policies.

Delegating access right to other users is achieved by requesting a special delegation policy from the backend. The delegation policy allows the user to add further constraints and the delegated user’s authentication key. Then it can be sent to the delegated user who can use it to authenticate towards the vehicle. Required policies for offline authentication are downloaded online through a backend connection and stored on the user’s token. When the user authenticates with the car, communication is done over shortrange technologies like Bluetooth, with the TPM 2.0 enforcing usage and time restrictions and examining the key stored on the token to attest the user’s identity. The TPM 2.0 will then verify that the processed policy originates from an authorized user before granting access. For offline rights delegation, the relevant policies contain an additional ‘TPM2_Policy Authorize’ command which is bound to the authentication key, allowing the user to create sub-policies independent of the backend. Through TPM verification of the entire policy path, the restrictions defined by the backend will not be widened by the user’s actions.

Test and Measurement

This concept was prototyped using a Raspberry Pi as the function controller due to its similarities to current automotive head units, with the TPM attached through an Iridium add-on board. Two Android smartphones were also used as user tokens. The authentication key was stored in Android KeyStore, with the device communicating to the function controller via Bluetooth.

For the prototyping the system was implemented using the TSS 2.0 Feature API (FAPI) for communicating with the TPM. FAPI is a high-level API that is designed to take over many security-relevant tasks and eases work of the developer. Necessary FAPI enhancements were contributed back to the TSS Open-Source project and a now available for all developers. Performance was measured through transmitted message sizes and execution times for basic policies. The time required to complete an offline user authentication for both a basic user and a basic delegation policy served as a baseline for testing.

Addressing Environmental Factors

To support the capabilities of in-vehicle networks and ECUs, the TPM not only acts as the trust anchor but also a ‘cryptographic broker’. It converts asymmetric cryptography to more lightweight symmetric cryptography more appropriate for the in-vehicle network. The system considers the varied environments the vehicle may operate in, such as areas with low network coverage, by designing the crucial authentication and optional delegation protocol steps to work offline. This enables users to access their vehicle and features no matter their surroundings.

The system has little integration overhead to existing automotive electrical/electronic (E/E) architectures, only needing to add a TPM as hardware trust anchor to the vehicle. As stated before, already established symmetric cryptography can be maintained with the ‘cryptographic broker’ approach making the system adaptable to a variety of different vehicle architectures, covering the majority of application scenarios.