Secure Silicon Lifecycle Management Architecture For Functional Safety

The rapid growth of electronics for automotive applications fueled by advanced ADAS systems pose new challenges for complex SoC design and Silicon Lifecycle Management (SLM) in the supply chain as well as in-field monitoring and management of the population of chips.

In these modern complex devices, ensuring the correct and safe operation requires not only functional safety to check for reliability issues due to silicon defects and aging, but also functional monitoring to ensure functional safety, safety of the intended function, and security issues. Ensuring that chips are not compromised in manufacturing, in the supply chain, or during field use is usually enabled by a Root of Trust (RoT) and other security mechanisms inside the chip.

By combining the mature SoC test infrastructure for Hierarchical DFT, IJTAG (IEEE1687) and In-System Test (IST) with advanced technologies on in-chip embedded analytics, methodologies for Supply Chain Security and Chip Lifecycle Management, and partnership-driven ecosystem platforms for functional safety, SoC suppliers are equipped with a comprehensive foundation that can accelerate their roadmap of next generation autonomous vehicles and software services connected to smart infrastructure.

Simply put, by architecting SoCs to integrate IP for sensors, security and chip identity and inserting such IP along with DFT IP as part of the mature RTL-to-GDSII design flows, SoC suppliers can establish a foundation of hardware enablement for trusted and secure SLM.

However, with the increasing volume of sensitive data being made available within these devices, hardware enablement for Trusted SLM is not sufficient. The industry needs to evolve software chip-to-cloud infrastructure platforms, open APIs, and standards that enable the deployment of SoC embedded analytics through secure SoC data access for monitoring and managing the population of chips in the supply chain and the field. Such infrastructure will fuel SoC-enabled Software IoT services that are projected to grow to $460 billion by 2026 for many vertical markets. And any services related to functional safety will be at the core of the market growth for automotive, mil-aero and industrial IoT applications.

A software chip-to-cloud infrastructure can evolve by partnering with PLM and Cloud Service providers, if SoCs are architected to support a wide variety of use cases including mass zero-touch enrollment during manufacturing, traceability through the supply chain, onboarding to the cloud and ultimately monitoring and managing automotive devices over the air (OTA). And in order for partnerships to create value, chip suppliers should focus on gathering requirements from the end application inward as parts of their strategy for next generation SoC roadmap.

Holistic view of the SoC architecture
Automotive applications have a long lifecycle, which requires a more strategic and holistic view of a wide variety of use cases for functional safety, security, and test that need to be supported.

SLM enabled by in-chip embedded analytics and secure chip access adds a new dimension to the SoC architecture since it can enable a plethora of use cases and services. SoC architects should consider up-front all those use cases and how they affect the SoC architecture.

The key considerations for next generation SoC architecture to support SLM are:

• Breadth of in-chip observability for embedded analytics & diagnostics;
• Scope of RoT use cases for SoC security & protection mechanisms;
• Methods to generate a unique identifier tied to each chip and its data;
• Assessment on who needs the chip data and how to grant access; and
• Plan on how the SoC data and embedded analytics can enable services value.

Any economic value derived from data originated from the chip is the responsibility of the chip supplier. This is another reason why chip security and secure chip access is essential. If chip suppliers own the data produced inside their chips, they can extract value from services using the data. If the data produced by the chip is based on data inputs from external sources, then it is essential that these chips can securely handle the data and key chains related to customer-supplier relationships in the IoT value chain.

That is why in-chip observability, security, identity, and data access must be considered up-front during the SoC architecture phase driven by use cases of end application requirements.

Breadth of in-chip observability for embedded analytics & diagnostics
The first SoC architecture consideration is what visibility may be needed into the chip and what data is needed for embedded analytics.

Such data may be for analysis of reliability, system performance, or even security intrusions.

It is also not feasible to assume that all vehicles are connected 100% of the time. Coupled with the fact that safety features require low latency response to real time events, a system implementation where there is localized event response is critical. A system where this sits alongside the cloud-based statistical analysis of the larger data set is most likely the implementation that is common.

The statistical feedback from the larger data set can be used throughout the lifetime of the vehicle to help enhance and improve the performance, power consumption, or reliability of the system. These enhancements can be reflected in OTA software updates, which can include remedies for handling intrusions throughout the life of the system when the vehicle is online.

Scope of RoT use cases for SoC security & protection mechanisms
The second SoC architecture consideration is related the growing volume of sensitive data. That is, which data we are trying to protect and what security is needed to access the SoC? Any embedded analytics data may include personal data based on the vehicle and its users. This data can be valuable to other parties, not only those interested in the silicon test and reliability.

Automotive SoCs today use a root of trust (RoT) for a narrow set of use cases such as key management, secure boot, secure update, secure storage, authentication, attestation, etc. However, embedded SoC analytics will require support for additional use cases such as secure test access, secure in-system test operation, and restricted test instrument access.

An RoT-enabled SoC architecture can be used to support few or many of the above use cases. The IEEE1687 IJTAG architecture implemented by the Mentor Tessent DFT flow lends itself extremely well to being enabled to support a RoT without significant changes. The segmented nature of the network, gives the option for different levels of accessibility.

Mentor’s Consulting Division (MCD) has the expertise in SoC architecture planning and the advanced knowledge in the area of test, safety, and security to assist SoC designers with the insertion of sensors as well as RoT IP integration during the DFT insertion process.

Depending upon the scope of embedded analytics and security needed, this can add complexity to chip connectivity and the IJTAG network. In addition, using such an architecture avoids trade-offs between security (to limit chip access) and functional safety, which requires lots of access to gather large data sets for analytics. This dichotomy is an essential consideration in optimizing the SoC architecture up-front for trusted SLM (i.e. security by design), which is another reason why it’s essential to understand the various end-application use cases at the early stages of SoC architecture planning.

Methods to generate a unique identifier tied to each chip and its data
The third SoC architecture consideration is that each chip needs to have a unique and immutable Identifier, so that any operations such as in-field provisioning, data gathering, monitoring and management can be linked to each chip history and lifecycle data.

Since chips are aggregated into PCBs and subsequently PCBs are then aggregated into systems, a device identity may encompass plethora of identifiers. These will be key in tying the security of digital assets (vertical software stack) with the trust of physical assets (horizontal value chain) in order to establish provenance and traceability in the supply chain. Such traceability can happen by evolving industry standards and APIs to close chip-to-cloud infrastructure gaps.

This is one reason why the GSA Trusted IoT Ecosystem Security (TIES) plans to develop liaison ties with standards organizations like SEMI.org and IPC.org and drive use cases for identifiers and protocols bridging Security & Trust with blockchain, said Tom Katsioulas, Chair of GSA TIES.

Generation of unique Identifiers for the population of chips is another use case for an RoT. It can be used generate identifiers at first power-up during wafer or probe test. Such identifiers can be linked to Manufacturing Execution Systems (MES) for internal provenance & traceability or visual identifiers during packaging for external provenance & traceability. The RoT will require credentials and identifiers to be injected, or generated, during first power-up at wafer/probe test. And in order to minimize overhead, credentials and identifiers should be created together.

Injected Identifiers is the most common method of creating chip identities at first power-up (chip birth). It requires a trusted facility and potentially a costly infrastructure to automate the process. Private/public key pairs are generated in a server and sent to chips via ATE. If this is done as part of volume production testing, then a command is sent to the chip along with the credentials to generate the identifiers inside the chip. Public keys stay in the server whereas private keys are injected once into the chip and stay there forever. If the injection of chip identifiers is done post packaging it adds overhead managing SKUs.

Inborn Identifiers is an emerging method that uses the existing DFT and ATE infrastructure. It does not require a trusted facility. It leverages the wafer/probe test setup and volume testing process to enroll chip Identifiers en masse into a server. The RoT is inserted during SoC design along with the DFT circuity and inborn credentials are created during 1st power-up for test. The public keys are sent to the server and the private keys stay in the chip forever. This method can enable a security-by-design ecosystem for zero-touch enrollment of chip identifiers into a server which is essential to establish provenance in the supply chain during chip birth.

Assessment on who needs the chip data and how to grant access
The fourth SoC architecture consideration is what data is needed from the chip, who needs the data, and how to access the chip and grant access rights to securely read or write data OTA on a per chip Identifier basis. There are several use cases and beneficiaries in the supply chain. The more use cases the SoC architecture can support, the higher the potential for services.

From the SoC architecture point of view, granting access can be as simple as locking and unlocking the IEEE 1149.1 JTAG for full chip data access, or as complicated as granting access though the IEEE 1687 IJTAG network to specific sensors and IPs.

From a user point of view, the question is which access rights are granted to specific users registered in the enterprise LDAP. And from a supplier/consumer point of view, the question is what access rights are granted by the system and application providers and for what purpose.

SoC suppliers may want to avoid fusing JTAG in order to manage RMAs. A typical use case for single device after a field return (RMA) include diagnosis test by the SoC supplier for a specific batch of chips. Such tests are typically done by returning the chips to the supplier. However, with identity-based OTA management there is potential to do certain tests remotely and reduce costs. Another potential use case for SoC suppliers may be SoC analysis by enabling/disabling software debug and using the data to optimize the SoC architecture.

During manufacturing it is important to be able to trace devices as they progress through the various stages of testing, as even at this early phase in manufacturing, there may be some form of feature provisioning taking place. If the device itself also contains memory and logic repair, this early data can be linked to the device through its identity and used as the baseline to report the health of the silicon. Traceability is also essential for knowing which and how many dies or chips did not make it to the end market. As such, if these turn up at some point on the gray market they can be disabled and rejected to avoid unsafe silicon ending up in vehicles.

ODMs and OEMs may care about chip authentication and traceability at each power-up for test in the supply chain or field use in order to ensure that there were no new defects or intrusions in the chip. They may also care about analytics on device performance and reliability linked to chip identifiers in order to monitor the health of the device and provide feedback to users for preventative maintenance.

Identification of end application use cases is also essential for monetization of data and analytics originating from chips. There are already service companies making use of this secure data within vehicles. It’s critical that these third party service companies only have a very restricted access to the data that they need or have paid for.

Plan on how the SoC data and embedded analytics can enable services value
With over 22 million connected vehicles driving around providing over 4 billion data points a day through available APIs, application providers are developing a wealth of third party services and pay-per-use apps to harvest data targeted for users, insurance companies, city planners, and smart infrastructure monetization. And that is only for the automotive market segment.

Functional safety is at the core of many application markets including mil-aero, industrial, and other vertical markets connected to smart infrastructure. Partnerships for end-to-end solutions from chip-to-cloud are starting to emerge in the semiconductor industry which is the core of electronics. SoCs have a unique opportunity to enable a plethora of secure IoT services apps.

EDA, IP, and SoC suppliers must partner with PLM, MES, and Cloud IoT services vendors in order to participate in software IoT Services markets. Ecosystems are starting to develop in anticipation of the $460 billion tidal wave for IoT services. Laggards will be swallowed. Leaders will surf it.