{"id":811,"date":"2020-04-23T11:27:03","date_gmt":"2020-04-23T11:27:03","guid":{"rendered":"https:\/\/blog.pufsecurity.com\/?p=811"},"modified":"2022-04-06T05:26:01","modified_gmt":"2022-04-06T05:26:01","slug":"build-trust-in-silicon-a-myth-or-a-reality-2","status":"publish","type":"dlp_document","link":"https:\/\/www.pufsecurity.com\/zh-hant\/document\/build-trust-in-silicon-a-myth-or-a-reality-2\/","title":{"rendered":"Build Trust in Silicon: A Myth or a Reality?"},"content":{"rendered":"\n

Abstract:<\/strong><\/h2>\n\n\n\n

Currently, there is a strong belief among the cyber security experts that hardware security is imperative<\/em> 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<\/em> to provide a firm foundation for electronic systems security.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Introduction<\/strong><\/h2>\n\n\n\n

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. <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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 \u201cwhether TEE & HRoT itself is built securely?\u201d and \u201chow to develop effective vulnerabilities mitigations and secure design rules so that TEE & HRoT could be securely integrated in a larger system?\u201d.<\/p>\n\n\n\n

Issues of Trust on Chip and How to Build Trust in Silicon <\/strong><\/h2>\n\n\n\n

Per Reference [1], there are several well-known techniques used to build security features into silicon including adding security extensions (e.g., ARM\u2019s 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

There are several existing challenges that need to be addressed to effectively detect and prevent hardware vulnerabilities [2]:<\/p>\n\n\n\n

\n

Challenge #1: Security policy capture<\/p>\n\n\n\n

Challenge #2: Security analysis must scale to SoC level<\/p>\n\n\n\n

Challenge #3: Hardware and software must be analyzed together<\/p>\n\n\n\n

Challenge #4: Security verification must have low overhead<\/p>\n<\/div><\/div>\n\n\n\n

To address these security vulnerabilities, [1] proposed a \u201cDesign For Security\u201d (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.<\/p>\n\n\n\n

The US and EU R&D Projects on Chip Security<\/strong><\/h2>\n\n\n\n

Currently, many US and EU cyber security experts believe that hardware security is imperative<\/em> 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.<\/p>\n\n\n\n

Three representative EU-funded projects on IoT & Chip Security as summarized below [3, 4, 5]:<\/p>\n\n\n\n

  • 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<\/em> of stored<\/em> or transmitted<\/em> or processed<\/em> data<\/em> or the related functions<\/em> or services<\/em> offered by, or accessible via IoT devices throughout their life cycle<\/li><\/ul>\n\n\n\n
    • Future TPM (Future Proofing the Connected World: A Quantum-Resistant Trusted Platform Module): provides a new generation of TPM-based solutions, incorporating robust<\/em> and formally verified <\/em>QR cryptographic primitives.<\/li><\/ul>\n\n\n\n