Detecting and Preventing Automotive Hardware Security Vulnerabilities

Ensuring hardware security, one chip at a time. VISIT: TORTUGALOGIC.COM Automating the Automotive Security Development Lifecycle

Connected and autonomous vehicles present a exposed not one but a chain of security issues. promising target, much like retailers or banks, For Fiat-Chrysler vehicles, it was a remote attack where hackers can troll for personal details and that could be performed against vehicles located identity theft. anywhere in the United State that caused a 1.4 million vehicle recall as well as changes to the Is your vehicle secure? Tesla found out the hard Sprint carrier network. way. Hacking typically begins by finding a series of vulnerability issues that create a path through European vehicles are also not immune. A study the car’s maze of defenses. So, when research- by German auto club ADAC found hackers could ers at the Chinese firm Tencent revealed they wirelessly open any BMW, Mini and Rolls-Royce could burrow through the Wi-Fi connection of vehicles in minutes. An estimated 2.2 million a Tesla S, all the way to its driving systems and vehicles equipped with BMW’s ConnectedDrive then remotely activate the vehicle’s brakes, they service were vulnerable.

Connected and autonomous vehicles present a promising target, much like retailers or banks, where hackers can troll for credit card numbers, home addresses, e-mail information and other personal details required for identity theft.

Hackers bent on identity theft are expected to infiltrate vehicles through the infotainment portal, as the Jeep hackers did, as well as with malicious apps that appear harmless or even helpful but steal personal information.

Software and firmware security protection is not enough to ensure a tamperproof vehicle. Auto- motive security begins with hardware.

2 www.tortugalogic.com Connected and Autonomous Vehicles

Connected and autonomous vehicles depend on an array of electronics, sensors, and computer systems. These attack surfaces require strong cybersecurity to ensure systems work as intended and are built to mitigate safety and security risks from potential attack vectors.

Sensors used by today’s vehicles include, LiDAR, used, the more attacks they are susceptible to. radar, cameras, ultrasonic and GPS systems. For example, booting an Electronic Control Unit The OEM’s challenge is securing the software, (ECU) insecurely can open the door to running algorithms and processing hardware behind unauthentic or malicious code on the ECU which these sensors. This is typically done using a may allow for unauthenticated access to private combination of off the shelf and custom chips driver information or harmful ECU malfunction. including application-specific integrated circuits This can also cause changes in operation that (ASICs), System on Chips (SoCs) and in case result in vehicle theft or worse, life-threatening of early model applications, field-programma- consequences. In these critical environments, its ble gate arrays (FPGAs). The challenge system fundamental that hardware provides the secure developers face is the more technology that is foundation in which to build the system on.

Security Begins with Hardware 3 Secure Over-The-Air (OTA) Updates

Since connected and autonomous vehicles are sold without wired connections, wireless OTA transmis- sions are often used to update the system with the most recent software. Of course, this must also be done in a secure manner in order to prevent any malicious third party from updating the vehicle with their own unauthorized configurations. The security of a system is only as good as its weakest link. There is no longer isolation of unrelated functions. OTA systems are often shared by Advanced Driv- er-assist Systems (ADAS), Infotainment and even the drive train.

It is imperative the security of OTA systems is driven down into the individual SoCs to maintain security across the entire chain of trust.

Hardware itself is becoming more commonplace for providing the basis of trust in OTA updates. The hardware facilitates secure boot (providing assurance the device is running authenticate code), remote attestation to authenticate the efficacy of the code running on the hardware and provides for storing unique and private data on the automobile’s driver.

Due to the high security requirements for OTA updates, it is now imperative that automotive systems manufacturers that employ ASIC, SoC and FPGA hardware, design in security up front. Designing security into hardware may include secure storage to protect keys, code and configuration settings from unauthorized access. Cryptographic hardware primitives may also be used to enable secure over OTA authentication and attestation using either a software-based Trusted Execution Environment (TEE) or design intellectual property (IP) as a separate Hardware Root of Trust (HRoT).

4 www.tortugalogic.com Rooting Security into Hardware

The trend of rooting security into hardware is growing rapidly. In a 2017 survey from the Global Semi- conductor Alliance (GSA) and McKinsey [1], semiconductor executives listed security as the top prior- ity for the Internet of Things (IoT) with a large emphasis on automotive. This same survey also listed endpoints and chips some of the most vulnerable attack points in a modern car.

One technique for designing security into hardware is using a Hardware Root of Trust (HRoT). Often called a cryptographic subsystem, secure enclave, and in some cases a Hardware Security Module (HSM), A HRoT is a minimum set of hardware and software dedicated to providing security from the moment the system is powered on until it is handed off for general use (to an operating system or its normal operating environment). HRoTs are typically built into System-on-Chips (SoC) as a secure processing subsystem to help ensure the hardware device boots securely and provides mechanisms for provisioning key material and storing unique IDs.

HRoTs have taken many forms including the use of Trusted Execution Environments (TEEs) and hardware intellectual property (IP) cores with secure microkernels. HRoTs are used for the root of security during all operation phases, secure boot during power up, run time operations and communications with external entities and provide the basis of security for the entire system. As such, it is critically important to ensure the root of trust is trustworthy: that the system has been independently validated and is not introducing harmful security vulnerabilities. Specifically, one needs to provide:

01 02 03

Assurance that the Hardware Confidence HRoT securely The HRoT can be activated securely Root of Trust (HRoT) operates clears its information when during normal operating modes to securely without unexpected handed off to normal operating ensure appropriate issuance of OTAs side effects mode and provisioning keys and unique IDs

Fortunately, there are some growing industry initiatives that can be leveraged to help detect and prevent security vulnerabilities in automotive SoCs, ASICs, and FPGAs. Specifically, many of the tech- niques built into the Automotive Security Development Lifecycle (ASDL) can be leveraged for secure automotive hardware design.

Security Begins with Hardware 5 Automotive Security Development Lifecycle

Functional safety has long been a primary deign The Auto-ISAC best practice guide for automo- concern for OEMs and their suppliers. However, tive security covers key cybersecurity functions. now with the connected and autonomies vehicles, The guide outlines risk assessment and manage- cybersecurity poses additional design challenges. ment strategies designed to be the first step to The auto industry’s upcoming standard ISO/SAE mitigate the potential impact of cybersecurity 21434[2] is intended to drive security activities vulnerabilities. The best practices focus on pro- and process at all phases of the vehicle life cycle. cesses for identifying, categorizing, prioritizing, The goal is to keep people and information safe. and treating cybersecurity risks that could lead This new standard will be based, in part, on the to safety and data security issues. Specially, sec- existing Auto-ISAC [3] (Automotive Information tion 4.3 calls out the best practices for “Security Sharing and Analysis Center) best practice guide. by Design” including:

Identify and address potential threats and attack targets in the design process Layer cybersecurity defenses to achieve defense-in-depth Identify trust boundaries and protect them using security controls Testing hardware and software to evaluate product integrity and security as part of component testing

In addition, the Automotive Security Development Lifecycle (ASDL), also developed by the Au- to-ISAC, helps ensure that appropriate cybersecurity protections are identified in the early stages of design. This is when implementation costs are lower and there is also time to consider design interac- tions that might affect cybersecurity. Many of these efforts can be fully leveraged for the secure design of hardware for automotive.

6 www.tortugalogic.com Auto-ISAC ASDL Stages

The Auto-ISAC ASDL covers the entire vehicle life cycle including pre-development, design and development through post development all of which have relevance for hardware.

AUTO-ISAC SECURITY DEVELOPMENT LIFECYCLE

Auto-ISAC Security Development Lifecycle

Pre-development: Considers existing system architectures that constrain future design decisions. Additionally, organiza- tions may want to define the types of cybersecurity risks that are acceptable and unacceptable for the final SoC, ASIC, or FPGA being deployed.

Design and Development: Is a comprehensive superset of all required cybersecurity specifications that can be tailored to a hardware component based upon its features during initial requirements design.

Security Begins with Hardware 7 Requirements: During the product requirements stages, it is important to think about what parts of the SoC, ASIC, or FPGA design that will need further threat modeling, penetration testing, or fuzz testing later in the development lifecycle. For example, you might place a requirement to ensure that proper memory protection mechanisms are put in place to protect your customers’ data. This stage serves as a way of identifying that further threat modeling is needed during the Design/Architecture stage.

Design/Architecture: At this stage, it is important to perform threat modeling on portions of the design deemed to be important for security as identified during the first step. Threat modeling is the process of considering the appropriate capa- bilities of an attacker, what they aim to achieve from the attack, and how they might perform it using acceptable amounts of resources (money, time, etc.). For example, an attacker will likely at least try to compromise memory protection by simply trying to read from privileged memory locations that may store key information, unique IDs, or private customer data. At this stage, this type of threat should be identified to prevent it during implementation.

Implementation: When implementing the design, it is important to follow the threat models put forth in the prior step. For example, a hardware memory protection unit has been implemented in the design to prevent unprivileged software from reading the protected memory regions and the design has been adequately tested to ensure this capability. The use of some automated hardware security platforms is very beneficial here to ensure implementations are in fact secure features based on the threat models and that the features are designed securely and not introducing vulnerabilities into the system.

Test and Verification: This is one of the final stages prior to tape-out, or manufacturing of your SoC or ASIC design. At this stage, all the security features that were implemented must be verified to be secure features. Manual review is the most often used method here, but automated hardware security solutions reduce the level of effort required to perform this step. Once final silicon is received, it may also be important to perform fuzz or penetration testing depending on whether your threat models cover physical based attacks to the chip.

Post-Development: During this stage, manufactures monitor vehicle for cybersecurity issues that emerge post-development, during vehicle operations and maintenance, to provide a feedback loop for the requirements and design phases of the automotive SDL process to aid in continuous improvements in security. It is important to have a feedback loop for next generation silicon and firmware updates to ensure when vulnerabilities are found, they can be quickly mitigated.

8 www.tortugalogic.com Auto-ISAC ASDL Automation

Tortuga Logic’s Radix™ solution can help automate steps in the Auto-ISAC ASDL. In securing hardware, there are typically two major properties than can be violated by a security vulnerability:

Confidentiality: This security property provides assurance that data is securely 01 managed and does not get exposed to an attacker. Some examples include access to private customer data, leakage of root device keys, and exposure of unique devices IDs.

Integrity: This security property provides assurance that critical resources in your hardware are never modified by an attacker. This can include unauthorized 02 modification of a public key stored in a device, changing of a privilege register for memory protections, or corruption of a firmware image to cause harmful side effects.

Often integrity and confidentiality violations work together, where finding an integrity vulnerability opens the door to a confidentiality one and visa-versa.

Security Begins with Hardware 9 Automating the Security Development Lifecycle with Radix

Radix detects and prevents security vulnerabilities, including integrity and confidentiality in ASIC, SoC and FPGA designs. Radix helps automate steps in the Auto-ISAC Security development lifecycle by providing a unique environment to specify security properties and then using standard simulation and emulation software from Cadence, Mentor Graphics and Synopsys, to detect and prevent security vulnerabilities. These security vulnerabilities can be due to system architecture, implementation, or system integration errors. Deployed during pre-silicon design, its patented technology and analysis helps teams identify and isolate serious security vulnerabilities before the device is manufactured, saving costly design re-spins or catastrophic system failure due to an attack.

AUTOMATING THE AUTO-ISAC SECURITY DEVELOPMENT LIFECYCLE

Automating the Security Development Lifecycle with Radix

As shown in, Radix fits well into the ASDL for hardware by providing the ability to specify security requirements during the earliest planning stages and the effectively detect and prevent vulnerabilities during design, implementation, and test and verification.

10 www.tortugalogic.com Conclusion

Connected and autonomous vehicles are here today. dor trust, and lead to costly lawsuits, chip recalls or By 2030, Renault predicts 100% of all vehicles sold even loss of life. will be connect and 15% will be autonomous. As more connected vehicles hit the roads, vulnerabilities Radix leverages existing functional verification will become accessible to malicious hackers using environments, without causing any disruption in cellular networks, Wi-Fi, and physical connections to workflow. With Radix, security vulnerabilities can exploit them. be identified and prevented before tape-out and deployment. Radix as part of your Automotive Failure to address these risks can be a costly mistake, Security Development Lifecycle enables a security including the impact they may have on consumer signoff methodology. Only Radix can provide au- confidence, personal privacy, and brand reputation. tomotive security and design teams with a reliable The existence and exploitation of hardware vulnera- and efficient way to verify the security of their bilities can also increase time-to-market, reduce ven- hardware systems.

About Tortuga Logic

Tortuga Logic is a cybersecurity company that provides hardware security verification solutions and ser- vices that enable ASIC, SoC and FPGA design and security teams to detect and prevent security vulnerabilities. Unlike software and firmware security solutions that do not find underlying hardware flaws or manual penetration testing that find issues after the device is manufactured, Radix detects and prevents hardware security issues, early in the design process, leveraging your existing design and verification tools and methodologies. For more information, please visit tortugalogic.com.

References: [1] Security in the Internet of Things, Mckinsey & Company April 2017

[2] Schmittner, Christoph & Griessnig, Gerhard & Ma, Zhendong. (2018). Status of the Development of ISO/SAE 21434: 25th European Conference, EuroSPI 2018, Bilbao, Spain, September 5-7, 2018, Proceedings. 10.1007/978-3-319-97925-0_43

[3] Auto-ISAC Automotive Security Development Lifecycle Best Practices https://www.automotiveisac.com/best-practices/

Security Begins with Hardware 11