close By using this website, you agree to the use of cookies. Detailed information on the use of cookies on this website can be obtained on OneSpin's Privacy Policy. At this point you may also object to the use of cookies and adjust the browser settings accordingly.

6 Minutes of Security: Achieving Automotive Safety with Security

By John Hallman

Security researchers have demonstrated extensively how cybersecurity attacks can have disastrous consequences in automobiles. A successful car hack in an automotive control system such as the drive train or brakes could affect an entire fleet of vehicles and put many lives in danger. Moreover, car owners' privacy and the protection of intellectual properties (IPs) and other assets of car manufactures and their supply chain are also at stake. Unlike safety, however, automotive cybersecurity is in its infancy. The upcoming “ISO/SAE 21434 Road Vehicles – Cybersecurity Engineering” standard promises to modernize and harmonize cybersecurity activities across the automotive supply chain...

Hardware Security

The ISO/SAE 21434 standard addresses the entire life cycle of electrical and electronic (E/E) systems for road vehicles, from the concept phase to decommissioning. While security has historically focused on software, attacks increasingly involve hardware and firmware weaknesses and vulnerabilities. The MITRE CWE database recently introduced, in version 4.0, a section dedicated to hardware. Hardware development relies on a global, fragmented supply chain, which involves service companies, semiconductor IP and IC suppliers, foundries, and distributors. Trustworthiness and quality of third-party components cannot be assumed but needs to be supported by adequate processes and evidence. A security-by-design methodology and rigorous pre-silicon assurance verification strategy are crucial to increase confidence and generate objective, auditable metrics and reports. Electronic design automation (EDA) tools and solutions for integrity assessment, like those for  functional correctness and trust and security checking of semiconductor IPs and ICs provided by OneSpin Solutions, can be used to implement automated, scalable hardware security assurance flows.

Threat Analysis and Risk Assessment

TARA is the security counterpart of the ISO 26262 hazard analysis and risk assessment (HARA) process. It is important to list a system's assets and their cybersecurity properties, including confidentiality, integrity, and availability. What is perhaps more challenging is identifying threat scenarios that may violate cybersecurity goals and perform a risk assessment. ISO/SAE 21434 demands a calculated risk value, between 1 (lowest risk) and 5 (highest risk), for each  identified threat scenario. The risk associated with a threat scenario depends on the feasibility of the attack and its impact. If the attack requires a team of expert hackers and costly equipment, the risk is lower than an attack that anyone can execute and lead to the same damage. In the worst-case scenario, the attack is easy to carry out and has severe consequences. The standard does not prescribe a specific method to analyze the system and calculate risk values, but it does provide some guidance and examples. As may be expected, threat scenarios that could lead to high-severity consequences deserve more attention and, potentially, require the specification and implementation of controls or other mitigations for risk reduction (see Figure 1).

The cybersecurity assurance level (CAL) is an attribute that can be associated with a system, a component, or a specific cybersecurity goal. It expresses the level of assurance required for assets. There are 4 CALs, CAL1 being the least stringent, and CAL4 the most demanding. Depending on the target CAL, certain cybersecurity activities can be omitted or carried out with less rigor. A component classified as CAL4 indicates that it might be suitable to perform critical functions that require a high level of security assurance and protection of critical assets. CALs are important to tailor cybersecurity activities according to the target assurance level and simplify communication among stakeholders and parties in the supply chain. Engineers familiar with ISO 26262 will see a strong resemblance between CALs and automotive safety integrity levels (ASILs).

While CALs and risk values are related concepts, they have significant differences. CALs are described in an annex of the standard, an informative (as opposed to normative) section. This could change in the first release of the standard. The concept of risk value and its determination, on the other hand, is part of ISO/SAE 21434 requirements. Moreover, while CALs are, at least in an ideal case, constant, risk values may change during the product lifecycle. A risk value that is deemed too high may require additional controls until it is reduced to an acceptable level.

To better mitigate threat risks in hardware, more specifically in the IP and IC’s, more exhaustive verification should be done to prove the absence of security vulnerabilities and weaknesses. The only way to achieve such thorough verification is with formal technology. OneSpin’s investment in safety certification is being leveraged as a model for the new security standards allowing our users to be able to meet these critical security standards head on and more easily. Known security hazards can now be planned for and combatted early in the process in order to be better prepared for new threats that may be introduced throughout the hardware and product lifecycle.

Back