Build Trust in Silicon: A Myth or a Reality?
By Albert Jeng, PUFsecurity
Abstract:
Currently, there is a strong belief among the cyber security experts that hardware security is imperative since it is more efficient, effective, reliable and tamper-resistant than software security. As a matter of fact, providing trusted execution environment (TEE) and embedding a hardware root of trust (HRoT) as the anchor are necessary to provide a firm foundation for electronic systems security.
However, since hardware is almost impossible to patch once it is fabricated, therefore how to build Trust/Security in silicon and how to verify the security of the hardware components at design time become very important hardware security issues and challenges.
There are several well-known techniques used to build security features into silicon including adding security extensions, implementing Trusted Platform Modules (TPMs), and incorporating a Physical Uncloneable Function (PUF). All of these design principles and primitives are necessary to ensure that the resulting silicon has the tools in place for software to build a trusted computing environment.
PUF-based Hardware Root of Trust | Related |
There are both US and EU funded hardware security projects with special focus on development of hardware security architectures and associated design tools which are able to block hardware attacks on HRoT. Each US or EU project has its own goal, use cases, technical approaches/research fields, and outstanding research results.
In this column, we will first discuss the importance of providing TEE & HRoT as a firm foundation for electronic systems security. Next, we will address issues of trust on chip and how to build trust in silicon. Third, we will provide an overview on the US and EU R&D projects on chip security. Finally, we will comment on the status of building trust in silicon followed by a short conclusion.
Introduction
It has been well publicized that computer hardware and firmware are perceived as more dependable and trustworthy than software since the latter is susceptible to design and implementation flaws and not impervious to subversion by malicious code. Hardware security is a physical device using a dedicated security IC, or a processor with specialized security hardware specifically designed to provide cryptographic functions and also protect itself and the associated critical data against attack. The typical examples of hardware security include Hardware Security Modules (HSMs), Trusted Platform Modules (TPMs), Physical Uncloneable Functions (PUFs), etc.
Securing distributed 5G or IoT/AIoT networks requires verifying the authenticity of data and identities of devices as well as an effective and efficient encryption to provide secure communication between 5G or IoT/AIoT nodes. This could possibly be done by providing trusted execution environment (TEE) and embedding a hardware root of trust (HRoT) in hardware to provide the firm foundation necessary for a more secure 5G or IoT/AIoT implementation.
However, since hardware is almost impossible to patch once it is fabricated, therefore how to build Trust/Security in silicon and how to verify the security of the hardware components at design time become very important hardware security issues and challenges.
Recently there are many proposals for applying TEE & HRoT to 5G or IoT/AIoT security. Although most of them claimed they leveraged TEE & HRoT to provide an efficient, flexible and scalable security for 5G or IoT/AIoT, many of them actually overlooked or failed to address key secure issues involved in injecting TEE & HRoT -based solutions. The two key issues are “whether TEE & HRoT itself is built securely?” and “how to develop effective vulnerabilities mitigations and secure design rules so that TEE & HRoT could be securely integrated in a larger system?”.
Issues of Trust on Chip and How to Build Trust in Silicon
Per Reference [1], there are several well-known techniques used to build security features into silicon including adding security extensions (e.g., ARM’s TrustZone) to processors to allow them to run in secure and non-secure modes, implementing Trusted Platform Modules (TPMs) to secure hardware by integrating cryptographic keys, and incorporating a Physical Uncloneable Function (PUF) to provide a unique challenge-response mechanism. All of these design principles and primitives are necessary to ensure that the resulting silicon has the tools in place for software to build a trusted computing environment.
However, simply including a security primitive (e.g., PUFs, TPMs and Crypto processors) is not enough to make the system or silicon secure since security vulnerabilities can still exist within a SoC design due to several design and verification issues that often arise due to varying levels of trust and expertise.
There are several existing challenges that need to be addressed to effectively detect and prevent hardware vulnerabilities [2]:
Challenge #1: Security policy capture
Challenge #2: Security analysis must scale to SoC level
Challenge #3: Hardware and software must be analyzed together
Challenge #4: Security verification must have low overhead
To address these security vulnerabilities, [1] proposed a “Design For Security” (DFS) methodology by identifying and verifying silicon security properties throughout the hardware design lifecycle, from architecture discussions to tapeout. In both [1] and [2], Tortuga Logic claimed that as SoC design teams implement DFS methods within their register transfer level (RTL) design flows, security vulnerabilities can be addressed and eradicated from architecture to tapeout, ensuring a fully secure system. They also provide security verification products that detect and prevent hardware security vulnerabilities within the existing chip verification strategies. This is possible due to their patented technology capable of detecting unexpected and unidentifiable information flows in the system during functional simulation.
The US and EU R&D Projects on Chip Security
Currently, many US and EU cyber security experts believe that hardware security is imperative since it is more efficient, effective, reliable and tamper-resistant than software security. There are both US and EU funded hardware security projects with special focus on development of hardware security architectures and associated design tools which are able to block hardware attacks on HRoT. Each US or EU project has its own goal, use cases, technical approaches/research fields, and outstanding research results.
Three representative EU-funded projects on IoT & Chip Security as summarized below [3, 4, 5]:
- Eurosmart IoT Security Certification Scheme (SCS): To ensure that IoT devices certified under this scheme comply with specified requirements supported by the industry with the aim to protect the availability, authenticity, integrity and confidentiality of stored or transmitted or processed data or the related functions or services offered by, or accessible via IoT devices throughout their life cycle
- Future TPM (Future Proofing the Connected World: A Quantum-Resistant Trusted Platform Module): provides a new generation of TPM-based solutions, incorporating robust and formally verified QR cryptographic primitives.
- SOPHIA (Securing Software against Physical Attacks): focuses on executing software securely and efficiently in the presence of physical attacks. It covers hardware security, secure system architectures, cryptographic implementations and side channels
There are also US-funded projects on IoT & Chip Security as well including [6]:
- The DARPA “System Security Integrated Through Hardware and Firmware” (SSITH) program complements DARPA software security efforts (e.g., High-Assurance Cyber Military Systems (HACMS) and the Cyber Grand Challenge (CGC) ) by taking advantage of new technologies to develop ICs that are inherently impervious to software end-runs.
- DARPA Contract under SSITH performed by Tortuga Logic to “Develop Novel Hardware Security Solutions”.
- UL’s IoT Security Rating Solution following NIST’s Guidelines for mitigating and managing IoT Cybersecurity and Privacy Risks and meeting forthcoming state regulations
Status of Building Trust in Silicon
The most prominent “Building Trust in Silicon” project is DARPA’s SSITH program [6, 7, 8]. Since its announcement in 2017, DARPA has six teams working on 15 different SSITH prototypes using open source RISC-V cores and ranging from low-end IoT devices up to high-performance computing systems. The goal of SSITH program is to provide security against hardware vulnerabilities that are exploited through software and to increase security throughout the microelectronics enterprise. Instead of just asking software to handle security by relying only on software-based security patches, SSITH proposed to protect against cyber attackers at the hardware and circuit level, by designing security directly at the hardware architecture level.
The overview and status of SSITH program are summarized as follows [6, 7, 8]:
- Background:
- DARPA aims to block hardware attacks at the source and reduce the need for software patches by turning to a new microprocessor design to help achieve that goal
- Strategic Challenges:
- Develop new IC architectures that lack the current software-accessible points of illicit entry, yet retain the computational functions and high-performance the ICs were designed to deliver
- Block buffer overflow and other hardware attacks at the source and reduce the need for software patches for flaws caused by underlying hardware issue
- Goal:
- To develop hardware security architectures and associated design tools (e.g., an open source chip) which are able to block hardware attacks and reduce the need for software patches
- To develop design tools so that hardware-anchored security would eventually become a standard feature of ICs in all electronic systems
- Technical Areas Focus:
- Development and demonstration of hardware architectures that protect against the seven vulnerability classes and the needed design tools for including hardware-based security innovations in design and manufacturing practices
- Methodologies and metrics for measuring the security status of the newly designed electronic systems and any tradeoffs the hardware-won security might levy in the form of system performance, power needs and efficiency, circuit area, and other standard circuit features
- Areas of Exploration: anomalous state detection, meta-data tagging, and churning of the electronic attack surface
- Approaches:
- SSITH seeks to encourage collaboration between research teams, commercial teams, and traditional DoD performers to provide robust and flexible solutions applicable to both DoD and commercial electronic systems
- To develop hardware security architectures and associated design tools (e.g., an open source chip) which are able to block hardware attacks and reduce the need for software patches
- Focus on Seven Classes of Hardware Vulnerabilities (listed in the Common Weakness Enumeration ( cwe.mitre.org): some 2800 software breaches have already taken advantage of one or more of these hardware vulnerabilities
- permissions and privileges,
- buffer errors,
- resource management,
- information leakage,
- numeric errors,
- crypto errors, and
- code injection
- Research Result:
- On 8/26/19 DARPA Unveils First SSITH Prototype to Mitigate Hardware Flaws
- The prototype designs are using open source hardware, including RISC-V processors, and frameworks will be adopted by other manufacturers in order to help make devices more secure
- DARPA has six teams working on 15 different SSITH prototypes using open source RISC-V cores and ranging from low-end IoT devices up to high-end systems
When the SSITH program is over, DARPA hopes the prototype designs it develops using open source hardware, including RISC-V processors, and frameworks will be adopted by other manufacturers in order to help make devices more secure. However, this may be a bit of wishful thinking according to Jake Williams, founder and president of Rendition Infosec as reported in [8]. His main critiques circled around SSITH’s implementation and adoption. He argued that any academic project like SSITH which claimed their customized hardware would block attacks could have both poor performance overhead and market adoption of a custom SSITH chip issues. On one hand, “Nobody wants custom chips even if they’re safer” and “There’s no appetite for custom ‘secure’ processors in the market right now”. On the other hand, “The security on the mobile side has been all about secure key storage. Anything that increases overhead simultaneously increases heat and decreases battery life …”.
Therefore, although DARPA’s academic pursuit in SSITH to develop a new IC architecture / microprocessor design to block hardware attacks and reduce the need for software patches is interesting and technical feasible, it is questionable whether the worldwide market is ready and willing to adopt a safer custom chip like SSITH for a more secure 5G or IoT/AIoT implementation and other electronic systems security.
Conclusion
For a long time, “Trust” in modern silicon has been something that most of us take for granted. In the pursuing of building security features (e.g., TPM, PUF, Crypto Processor) into silicon, it has been recognized that simply including such a security primitive is not enough to make the system or silicon secure since security vulnerabilities can still exist within a SoC design. There are both US and EU funded hardware security projects with special focus on development of hardware security architectures and associated design tools which are able to protect against cyber attackers at the hardware and circuit level, by designing security directly at the hardware architecture level. The most prominent “Building Trust in Silicon” project is DARPA’s SSITH program.
DARPA has unveiled its first SSITH prototype to mitigate hardware flaws on 8/16/2019. The prototype designs are using open source hardware, including RISC-V processors, and frameworks will be adopted by other manufacturers in order to help make devices more secure. In addition, in DARPA Contract under SSITH performed by Tortuga Logic to “Develop Novel Hardware Security Solutions”, they proposed a “Design For Security” (DFS) methodology by identifying and verifying silicon security properties throughout the hardware design lifecycle, from architecture discussions to tapeout. The research results accomplished in SSITH program have clearly demonstrated that “Build Trust in Silicon” is no longer a myth but a true reality!
However, due to the consideration of SSITH’s implementation and adoption regarding both poor performance overhead and market adoption of a custom SSITH chip issues as discussed at the end of Section 4, the jury is still out on whether at the termination of SSITH, the prototype designs it develops using open source hardware, including RISC-V processors, and frameworks will be adopted by other manufacturers in order to help make devices more secure.
Reference
- Oberg, J. “Issues of trust in silicon”, August 3, 2016 Jason Oberg, Tortuga Logic
- https://www.cadence.com/content/dam/cadence-www/global/en_US/documents/solutions/aerospace-and-defense/aerospace-and-defense-security-wp.pdf
- Eurosmart IoT Certification Scheme
- Future TPM website
- SOPHIA website
- SSITH website
- http://mil-embedded.com/news/security-at-the-hardware-level-is-the-goal-of-darpas-ssith-program/
- https://searchsecurity.techtarget.com/news/252469138/DARPA-unveils-first-SSITH-prototype-to-mitigate-hardware-flaws
|
PUFsecurity Hot IP
Related Articles
New Articles
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
- Timing Optimization Technique Using Useful Skew in 5nm Technology Node
- Streamlining SoC Design with IDS-Integrate™
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- PCIe error logging and handling on a typical SoC
- UPF Constraint coding for SoC - A Case Study
E-mail This Article | Printer-Friendly Page |