Securing the Automotive Industry with PKI and Identity Management

Vehicles are becoming increasingly complex and connected. New vehicles can contain up to 300 million lines of code and more than 150 electronic control units (ECUs) which intelligently communicate with systems within the vehicle. Then they can communicate with outside systems, which can include vehicle-to-vehicle (V2V), vehicle-to-grid (V2G), vehicle-to-infrastructure (V2I), and more, creating the ever-broadening V2X ecosystem. No longer can we think of a vehicle as just a machine that moves us from point A to point B. We must think of them as the intelligent, interconnected devices they are. — an IoT device that is a network of other IoT devices. 

Vehicle security is an ever-evolving challenge. All the components of the vehicle must be secure. General communication with the car, like firmware and software updates or “infotainment,” must be secure. Future V2V connections must be secure. To ensure security, every device needs an identity, and every identity needs to be managed.  

We have seen how weak security can have catastrophic effects. In 2015, hackers were able to take over a Jeep while it was on a highway. Recently, insurance companies have stopped covering certain Kia and Hyundai models as they are too easy to steal. 

This blog will look at some challenges and solution principles specific to the automotive industry. 

Vehicles are made of many connected ECUs and components, the majority of which are not made by the automotive manufacturer but by a Tier 1 supplier. This presents multiple challenges, as automotive manufacturers must now have security procedures for managing identities they did not create, or they must have an infrastructure to create the identities and make them accessible to multiple Tier 1 suppliers.  

With every added intelligent subsystem, the attack surface for bad actors increases. Knowing that the systems are connected inside the vehicle provides multiple avenues to critical systems like the engine, power steering, or brakes. A vulnerability in any connected system can be daisy-chained to other systems. This requires a close, trusted relationship between the automotive manufacturer and their Tier 1 suppliers and, in turn, their suppliers.  

Networks. Devices. Infrastructure. Grid. Other vehicles. The number of “things” a vehicle can connect to continues to grow. As with OTA updates, each connection presents an opportunity for a malicious actor to intercept, read, and alter the data and commands shared within the ecosystem.  

Standards will be a key moving forward, but at times can lag behind the development of the technology. Additionally, manufacturers doing business internationally must adhere to competing standards. For example, in the United States, manufacturers must prepare for IEEE 1609.2, while in Europe, C-ITS will have different requirements, while both must prepare for UNECE 155/156. This means any system for security implemented today must be flexible and scalable enough to handle the uncertainty of the future. 

No matter how careful developers are or what QA processes are put in place, software and firmware need to be updated and maintained. With vehicles, that can be done by physically connecting a vehicle at an authorized dealership or through OTA updates, just like updating the software on a phone. In theory, this is a simple task: the vehicle reaches out to the manufacturer’s network or device at the dealership, connects, pulls down the update, then applies it.  

However, how does the vehicle know the update is legitimate and not malicious? Whether injected through a hijacked remote connection or through a direct physical update, new code can be put onto the vehicle allowing for remote control, data breaches, or even possibly ransomware. Software and firmware updates must have the means to prove they are from a legitimate source before being installed. 

The best way to prepare for the uncertainty of tomorrow’s standards and new technologies is to implement a flexible and scalable system today. This starts at the code level. 

Implementing proper code signing is fundamental to secure updates and can be a last line of defense against a malicious attack.  

In the event of unauthorized communication, remote or physical connection, proper code signing checks add a layer of security. Now, the bad actor must not only gain access to communication but also have a signature certificate from the software/firmware developers. A properly designed system would reject the software and trigger alert notifications if they were to send unsigned code.  

Using a code signing solution and properly protecting its signing certificates makes it much more difficult for a bad actor to insert malicious code. 

The hallmark of secure communication is that every device has a trusted and verifiable identity. This identity most often comes in the form of a signed certificate. With a proper PKI, manufacturers can issue identities to the primary communication ECU and, in partnership with their Tier 1 suppliers, to all the ECUs within the vehicle.  

In the unlikely event of a breach of a root certificate, automated certificate lifecycle management is imperative. This can allow for the bulk repeal of tainted certificates and the identification of devices that may not be online but will need to be handled during the next communication.  

Whether you’re an automotive OEM or Tier 1 supplier, you need an end-to-end solution that protects your entire ecosystem. Keyfactor EJBCA, Keyfactor Command for IoT, and Keyfactor SignServer make that possible with an end-to-end IoT identity platform to sign software/firmware, and manage and automate identities for devices from manufacturing to end-of-life.