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 se- curity 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 hard- ware 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 devel- opment 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