Automotive cybersecurity begins with secure ASIC, FPGA and SoC hardware
So, when researchers at the Chinese firm Tencent revealed they could burrow through the Wi-Fi connection of a Tesla S, all the way to its driving systems and then remotely activate the vehicle’s brakes, they exposed not one but a chain of security issues. Security vulnerabilities can be introduced throughout the design lifecycle starting at the architectural level, where fundamental flaws in the security architecture, such as storing implicitly trusted boot code in unprotected writable SPI Flash can open systems to attack.
A flawed microarchitectural design decision can also open hardware to vulnerabilities (ex. Meltdown and Foreshadow). Vulnerabilities can also be introduced during RTL design, such as unintentional backdoors in test and debug circuitry, as well as errors in configuration and usage of hardware by low-level firmware and software.
Commonly employed security verification techniques, which include manual design and code review, formal verification, and simulation-based functional verification are important as part of a larger verification strategy but do not provide a unified scalable methodology which can be applied during all stages of the pre-silicon design lifecycle.
Automotive security development lifecycle
The trend of rooting security into hardware is growing rapidly. In a 2015 survey from the Global Semiconductor Alliance (GSA) and McKinsey, semiconductor executives listed security as the top priority 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.
Functional safety has long been a primary deign concern for OEMs and their suppliers. However, now with the connected and autonomous vehicles, cybersecurity poses additional design challenges. The auto industry’s upcoming standard ISO/SAE 21434 is intended to drive security activities and process at all phases of the vehicle life cycle. The goal is to keep people and information safe. This new standard will be based, in part, on the existing Auto-ISAC (Automotive Information Sharing and Analysis Center) best practice guide.
The Auto-ISAC best practice guide for automotive security covers key cybersecurity functions. The guide outlines risk assessment and management strategies designed to be the first step to mitigate the potential impact of cybersecurity vulnerabilities. The best practices focus on processes for identifying, categorizing, prioritizing, and treating cybersecurity risks that could lead to safety and data security issues. Specially, section 4.3 calls out the best practices for “Security 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 Auto-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 interactions that might affect cybersecurity. Many of these efforts can be fully leveraged for the secure design of hardware for automotive.
Auto-ISAC security development lifecycle best practices:
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.
Pre-development: Considers existing system architectures that constrain future design decisions. Additionally, organizations may want to define the types of cyber 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.
-
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 capabilities 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.
Auto-ISAC security development lifecycle automation
Tortuga Logic’s Radix solution can help automate steps in the Auto-ISAC security development lifecycle by providing a unique environment to specify security properties and then using standard SoC, ASIC, and FPGA 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.
As shown in Figure 3, 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.
Conclusions
As more connected vehicles hit the roads, vulnerabilities will become accessible to malicious hackers using cellular networks, Wi-Fi, and physical connections to exploit them. Failure to address these risks can be a costly mistake, including the impact they may have on consumer confidence, personal privacy, and brand reputation. The existence and exploitation of hardware vulnerabilities can also increase time-to-market, reduce vendor trust, and lead to costly lawsuits, chip recalls or even loss of life.
Radix leverages existing functional verification environments, without causing any disruption in workflow. With Radix, security vulnerabilities can be identified and prevented before tape-out and deployment. As part of your automotive security development lifecycle, the tool enables a security sign-off methodology, providing automotive security and design teams with a reliable and efficient way to verify the security of their hardware systems.
About the author:
Dr. Jason Oberg is Co-founder and CEO of Tortuga Logic Inc. – www.tortugalogic.com
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
