Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Minimizing Security Vulnerabilities in Connected Cars Starts with Silicon
Mike Borza, Principle IP Security Technologist, Synopsys
By 2023, IHS Markit predicts that more than 70 million connected cars will be on the road. As the connected car market grows, risk of cybersecurity threats also grows. In response, automotive IC designers and OEMs must adopt new techniques and technologies to build security into automotive software and systems.
The complexity of vehicle electronics is also growing. Figure 1 shows a schematic of a luxury car, which uses the FlexRay protocol for safety-critical solutions such as actuators. More connections bring in multiple network topologies, which may or may not be secure. As they are all intertwined and interconnected, any connection to get into the vehicle’s electronics is a potential point of attack for hackers. For example, jamming RFID signals could disable the immobilizer to allow theft of the vehicle. Intercepting V2X or VSRC can open communication channels between vehicles to hack into or spy on users. Seemingly innocuous interfaces can provide a way into the vehicle, so protecting the car starting at the silicon level is critical.
Figure 1: More network topologies provide more potential attack points
(Source: IHS Market webinar, "Security and the Connected Car")
Silicon Provides the Foundation for Defense
The foundation of security is an in-depth defensive strategy for securing the vehicle. At the heart of every software program is the hardware on which it runs. To ensure that an IC has not been compromised, it should be able to assess its own integrity as it comes out of reset. Then, when it is deemed secure, it can bring up the network that ultimately forms the intelligence inside the car that will eventually connect to the outside world. IC designers need to bring these systems out of reset and integrate them in a way that ensures trust, security, and integrity, ensuring that they're just as the manufacturers intended them to be supplied.
Network Security
Beyond the individual car, remote entity identification and authentication is required to connect the vehicle to other entities. For example, message authentication ensures that over-the-air messages are going only where intended and are only being interpreted by the authorized systems. Providing secure, authenticated channels through remote entities such as the vehicle service network or manufacturers’ network enables faster, over-the-air software and firmware updates. In fleet operations, operator networks can be used to securely coordinate the activities of multiple vehicles. With the growth of Internet of Things (IoT) in automotive applications, vehicles are connected to owners’ phones and smart homes for a variety of purposes including vehicle monitoring and tracking for theft prevention and recovery. Each network connection offers a potential opportunity for hackers.
To help designers with this arduous task, Synopsys provides tRoot Hardware Secure Modules (HSMs) that can be embedded at the chip level in the car’s electronic computer unit (ECU) processor. tRoot HSMs deliver the security that lives at the heart of the chip – the Root of Trust. As shown in Figure 2, tRoot is based on a hardware layer with a set of very simple services like asymmetric cryptography, symmetric cryptography, true random number generators, memory protection, and one-time-programmable (OTP) non-volatile memory (NVM).
Figure 2: DesignWare tRoot HSM provides the foundation for secure systems
The Security Primitives layer shows the services that run on that tRoot processor, including secure storage, hardware key ladders (allowing designers to build a chain of trust for the platform), and platform integrity (bringing the system out of reboot and knowing that the software is as it was intended). Debug and JTAG services allow designers to develop software on these platforms and close off that avenue once the development phase is done.
In the top two layers, a variety of services are supplied to the host. The IC itself has a host processor, which is typically something complex like a symmetric multi-processor, and it can run on very standard firmware. For example, infotainment systems could run a Linux system that is developed for AUTOSAR, or other products from companies like Wind River or Unix. A tRoot HSM enables security services for a host processor to execute various communication, both inside the vehicle and then ultimately onto the external devices.
Hardware: The Foundation of the Root of Trust
Figure 3 shows an advanced ECU IC, where the hardware security module at the core may include several protocol accelerators or other cryptographic units used to provide specific functions for things like networking security. Non-volatile memory (NVM), which is built into the chip, is used to store keys. Control logic and sensing logic executes intrusion detection within the chip to discover actors that are attempting to bypass the security of the chip. The Root of Trust brings the host CPU out of root set in a secure fashion to initialize memory controllers, networking, and other subsystems in the system and get them up and running.
Figure 3: ECU IC with hardware security enclave enabled by tRoot Hardware Secure Modules
Once the ECU is running, the Root of Trust enables the IC to make connections through trusted channels to other devices around the vehicle and ultimately onto systems that operate in the cloud or in the network at the vehicle roadside.
Host Software Security
Host software security addresses what happens on the host once it has been booted. Secure boot is often split into two phases. First, the HSM brings the chip out of rest, does an initial bootstrap loader verification for the host software, and then passes control to the host software once the boot loader has been validated. Then, the host itself has use of additional available services. It can then make calls back to the HSM to execute asymmetric cryptographic operations to verify that the software that's installed for the mission-mode operating system is working correctly.
Trust, authentication, and hardware enforce separation of functionality of one module from the others to ensure both physical and cybersecurity around accessing and operating the vehicle.
Hardware Root of Trust Provides SoCs with a Unique Identity
Maintaining control of the system in the face of increasing complexity leads designers to use trusted execution environments (TEEs) that are based on a separate enclave processor (Figure 4). A TEE supplies security services that can be used to build the trust in the rest of the system. Separating the security processing function from other processing activity in the system enables the security enclave to run the security protocols in a very small, tightly controlled environment.
Figure 4: tRoot HSM is the basis for trusted execution environments
The DesignWare tRoot HSMs provide the opportunity to create, store, and manage secrets in a secure fashion and then extend the trust to other internal and external entities as different systems require authentication after reset. The tRoot HSMs reduce the requirements for designers to be able to manage their own security requirements. Rather than building their own security solution, designers can take advantage of Synopsys’ product development teams’ expertise and build their design using Synopsys’ hardware security IP.
For strong security, the tRoot includes multi-stage secure bootstrap to validate software and data integrity, secure authentication, secure updates, secure storage, and secure debug enablement to provide management of the device itself, and key management and cryptographic programming interfaces that provide services to host-based applications that need the services running in the ECU (Figure 5). Cryptographic acceleration is also available for systems requiring high-performance cryptography.
Figure 5: DesignWare tRoot HSM block diagram
Features of the DesignWare tRoot HSMs include a small CPU with a tight code base, a limited amount of internal RAM that is secure and isolated for this processor, and a secure instruction controller and secure data controller for external memory in the ECU to be used as trusted memory within tRoot. These provide cryptographic confidentiality and authentication of the contents of the memory. They allow tRoot to detect when an external entity, like a rogue program, has tried to manipulate the memory, replace it, or cause it to misexecute or execute the incorrect instructions. If tRoot detects unexpected activity, it transitions to a safe state.
tRoot HSMs include entropy inputs for random number generators built inside the module so that the random number generators are completely isolated from the system and can't be manipulated by outside programs.
The tRoot HSMs also include communication interfaces via UARTs that are used to detect and respond to system-level upsets, including over and under voltage and over and under frequency operation of a chip. Device identity input brings in the keys that are stored in one-time programmable memory at the SoC level, and a host port interface is used to communicate with the host processor.
Security is Key to Ensuring Quality and Safety Automotive systems must meet functional safety standards, which means implementing security functions to ensure that functional safety cannot be tampered with. Without security, there is no safety or reliability, so automakers are approaching functional safety and security with a more holistic approach. Secure systems must be able to handle unpredictable inputs that would create unacceptable behaviors. Designing the security into automotive SoCs from the hardware level will help ensure that connected cars behave as expected and are able to fend off attacks.
For more information: