
With the proliferation of advanced driver-assistance systems (ADAS) and connected autonomous vehicles (CAVs), complex electronics are involved in – and increasingly in charge of – ever more critical driving functions and private information management. You might have heard this from me already: there is no safety without security. Neither there is privacy. Unlike safety issues, mostly due to human errors, security issues often originate from abuse and misuse of hardware and software components. Security researchers and hackers are some of the most creative people. One of the consequences is that new vulnerabilities are discovered frequently, raising the challenges of supply chain management and post-sales support to a whole new level. Who in the supply chain is responsible for keeping cars protected?
Original equipment manufacturers (OEMs) have two main directions to address the cybersecurity hot potato challenge. The first is to move hardware and software development as much as possible in house. The second is to distribute cybersecurity activities across the supply chain using a strict and standard approach. The ISO/SAE 21434 “Road vehicles – Cybersecurity engineering” standard can come in handy.

Cybersecurity lifecycle. Source: Hyunday Motor Group
Go in-house
As electronics become key to differentiation and semiconductors reportedly enable 80% of vehicle innovation, OEMs have plenty of reasons, beyond cybersecurity, to take the in-house path. Tesla has invested significantly in software development for a while. True to the statement that “people who are really serious about software should make their own hardware,” in 2019, Elon Musk himself presented Tesla’s first full-self driving chip developed in house.
At DVCon Europe 2020, Matthias Traub, head of E/E-Architecture and Platforms at the Volkswagen Group, which includes Audi, Seat, Skoda, and numerous other brands, delivered a very interesting keynote. Automotive architectures are not flexible. Tens of electronic control units (ECUs) function mostly independently. Each ECU has its own software stack, making suppliers running in the hundreds. In January 2020, the Volkswagen Group established an independent organization expected to employ 5000 software engineers by the end of the year. Taking the in-house path simplifies the supply chain, but no organization can do everything on its own.
Share the pain
ISO/SAE 21434 allows sharing the pain of newly discovered vulnerabilities across the supply chain. The standard covers the entire life cycle of automotive electronics, including the operation and maintenance phase, and identifies continuous cybersecurity activities. Monitoring of newly discovered vulnerabilities, threats, and proposed mitigation is the first step. When the information collected is relevant to an item or component (under development or already on the road), this is considered a cybersecurity event. An assessment process is required to determine the event’s criticality. The vulnerability may have to be analyzed, to identify its root cause, and properly managed. For example, in some cases, the additional risk could be deemed acceptable, while a remedial action might have to be implemented in others. Any update or change in hardware or software has to be managed according to the standard’s requirement. When in the operation and maintenance phase, a cybersecurity event can rise to the level of incident. The draft standard includes a note stating that “the organization can define the criteria for invoking incident response.” There are requirements dedicated to this special scenario.
The OEM will not have all the expertise, tools, and platforms to implement these requirements. Luckily, ISO/SAE 21434 considers that cybersecurity activities may have to be distributed across the supply chain. Customers and suppliers must have formalized agreements that clarify how responsibilities, decisions, and information are shared. Customers must also evaluate the supplier’s capabilities to implement a standard-compliant process during development and, crucially, to support post-development activities, such as assessing a newly discovered vulnerability’s criticality. It is worth noting that a Tier1 can be a supplier for an OEM and a customer for a Tier2 supplier.
Remediate
Avoiding incidents is always preferable (and much cheaper). ISO/SAE 21434 has plenty of requirements and recommendations to shape processes and foster an organizational culture that integrate cybersecurity from the concept phase. While hardware security is still in its infancy, the electronic design automation (EDA) industry already offers numerous relevant solutions. Formal methods and hardware model checking support the detection of weaknesses and vulnerabilities during the pre-silicon development phase of semiconduction IPs and system-on-chip (SoC) devices. OneSpin Solutions provides highly automated apps dedicated to hardware trust and security verification. The technology reduces the development time and the risk of vulnerabilities being discovered after deployment.
However, security is an arms race. It is impossible to reduce the risk to zero. Suppliers of integrated circuits (ICs) and semiconductor IPs must analyze newly discovered vulnerabilities efficiently. They need to maintain and enhance the hardware development environment for post-silicon analysis. This is crucial to determine the root cause of a security issue and identify remedial actions. OneSpin has unique design analysis technology that can be targeted at specific design functions. It can also be used to carry out a rigorous, exhaustive “what-if” analysis to develop – and fully validate – hardware and software remediations.
Learn more
I invite you to take a look at the trust and security glossary, download the white paper Trust Assurance and Security Verification of Semiconductor IPs and ICs, and join the LinkedIn group ISO/SAE 21434 Automotive Cybersecurity. And of course, don’t miss the next 6 Minutes of Security blog post!
Sergio Marchese
(all posts)Sergio Marchese is technical marketing manager at OneSpin Solutions. He started his career at Infineon Technologies, applying coverage-driven constrained-random simulation and formal methods to verify the TriCore CPU, an architecture widely used in today's automotive SoCs. He has since worked on projects in the communications, consumer, industrial and aerospace domains. Most recently, he served as verification expert at Huawei Technologies, leading worldwide formal verification activities for ARM CPU and consumer SoC designs. Marchese also built and managed state-of-the-art teams, successfully signing off complex hardware designs using formal verification.
November 11, 2020 at 03:09PM
https://ift.tt/36tjJ3t
Who's Got The Hot Potato? - SemiEngineering
https://ift.tt/2rh4zOj
Potato
No comments:
Post a Comment