SoC与IP安全基石：设计、验证与调试指南

需积分: 13 189 浏览量更新于2023-05-19 收藏 7.69MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

10 S. Ray et al.

Usages Assets Exposed

Browsing Browsing history

Fitness tracking Health information,sleep pattern

GPS Location

Phone call Contacts

Banking,Stock trading Finances

Fig. 2.1 Some typical smartphone applications and corresponding private end user information

(a) (b)

Fig. 2.2 Some potential attacks on a modern SoC design. a Potential attack areas for a smartphone

after production and deployment. b Potential threats from untrusted supply chain during the design

life cycle of an SoC design

out to unauthorized sources. This includes cryptographic and DRM keys, premium

content locks, ﬁrmware execution ﬂows, debug modes, etc. Note that the notion of

“unauthorized source” changes based on what asset we are talking about: end user

may be an unauthorized source for DRM keys while manufacturer/OEM may be an

unauthorized source for end user private information.

In addition to criticality of the assets involved, another factor that makes SoC

security both critical and challenging is the high diversity of attacks possible.

Figure 2.2 provides a ﬂavor of potential attacks on a modern SoC design. Of par-

ticular concern are the following two observations:

∙ Because of the untrusted nature of the supply chain, there are security threats at

most stages of the design development, even before deployment and production.

∙ A deployed SoC design inside a computing device (e.g., smartphone) in the hand

of the end user is prone to a large number of potential attacker entry points, includ-

ing applications, software, and network, browser, and sensors. Security assurance

must permit protection against this large attack surface.

We discuss security validation for the continuum of attacks from design to deploy-

ment. Given that the attacks are diverse, protection mechanisms are also varied, and

2 Security Validation in Modern SoC Designs 11

each induces a signiﬁcantly diﬀerent validation challenge. However, validation tech-

nology is still quite limited. For most of the security requirements, we still very much

depend on the perspicuity, talent, and experience of the human validators to identify

potential vulnerabilities.

2.2 Supply Chain Security Threats

The life cycle of a SoC from concept to deployment involves number of security

threats at all stages involving various parties. Figure 2.2b shows the SoC life cycle

and the security threats that span the entire life cycle. These threats are increasing

with the rapid globalization of the SoC design, fabrication, validation, and distribu-

tion steps, driven by the global economic trend.

This growing reliance on reusable pre-veriﬁed hardware IPs during SoC design,

often gathered from untrusted third-party vendors, severely aﬀects the security and

trustworthiness of SoC computing platforms. Statistics show that the global market

for third-party semiconductor IPs grew by more than 10 % to reach more than 2.1

billion in late 2012 [1]. The design, fabrication, and supply chain for these IP cores is

generally distributed across the globe involving USA, Europe, and Asia. Figure 2.3

illustrates the scenario for an example SoC that includes processor, memory con-

trollers, security, graphics, and analog core. Due to growing complexity of the IPs

as well as the SoC integration process, SoC designers increasingly tend to treat these

IPs as black box and rely on the IP vendors on the structural/functional integrity of

these IPs. However, such design practices greatly increase the number of untrusted

components in a SoC design and make the overall system security a pressing con-

cern.

Hardware IPs acquired from untrusted third-party vendors can have diverse secu-

rity and integrity issues. An adversary inside an IP design house involved in the

IP design process can deliberately insert a malicious implant or design modiﬁ-

cation to incorporate hidden/undesired functionality. In addition, since many of

the IP providers are small vendors working under highly aggressive schedules,

it is diﬃcult to ensure a stringent IP validation requirement in this ecosystem.

Design features may also introduce unintentional vulnerabilities, e.g., intentional

information leakage through hidden test/debug interfaces or side-channels through

power/performance proﬁles. Similarly, IPs can have uncharacterized parametric

behavior (e.g., power/thermal) which can be exploited by an attacker to cause irrecov-

erable damage to an electronic system. There are documented instances of such

attacks. For example, in 2012, a study by a group of researchers in Cambridge

revealed an undocumented silicon level backdoor in a highly secure military-grade

ProAsic3 FPGA device from MicroSemi (formerly Actel) [2], which was later

described as a vulnerability induced unintentionally by on-chip debug infrastruc-

ture. In a recent report, researchers have demonstrated such an attack where a mali-

cious upgrade of a ﬁrmware destroys the processor it is controlling by aﬀecting

the power management system [3]. It manifests a new attack mode for IPs, where

2 Security Validation in Modern SoC Designs 13

2.3 Security Policies: Requirements from Design

In addition to supply-chain threats, the design itself may have exploitable vulnerabil-

ities. Vulnerabilities in system design, in fact, forms the quintessential objective of

security study, and has been the focus of research for over three decades. At a high

level, the deﬁnition of security requirement for assets in a SoC design follows the

well-known “CIA” paradigm, developed as part of information security research [6].

In this paradigm, accesses and updates to secure assets are subject to the following

three requirements:

∙ Conﬁdentiality: An asset cannot be accessed by an agent unless authorized to do

so.

∙ Integrity: An asset can be mutated (e.g., the data in a secure memory location can

be modiﬁed) only by an agent authorized to do so.

∙ Availability: An asset must be accessible to an agent that requires such access as

part of correct system functionality.

Of course, mapping these high-level requirements to constraints on individual assets

in a system is nontrivial. This is achieved by deﬁning a collection of security poli-

cies that specify which agent can access a speciﬁc asset and under what conditions.

Following are two examples of representative security policies. Note that while illus-

trative, these examples are made up and do not represent security policy of a speciﬁc

company or system.

Example 1 During boot time, data transmitted by the cryptographic engine cannot

be observed by any IP in the SoC other than its intended target.

Example 2 A programmable fuse containing a secure key can be updated during

manufacturing but not after production.

Example 1 is an instance of conﬁdentiality, while Example 2 is an instance of

integrity policy; however, the policies are at a lower level of abstraction since they

are intended to be translated to “actionable” information, e.g., architectural or design

features. The above examples, albeit hypothetical, illustrate an important character-

istic of security policies: the same agent may or may not be authorized access (or

update) of the same security asset depending on (1) the phase of the execution (i.e.,

boot or normal), or (2) the phase of the design life cycle (i.e., manufacturing or pro-

duction). These factors make security policies diﬃcult to implement. Exacerbating

the problem is the fact that there is typically no central documentation for security

policies; documentation of policies can range from microarchitectural and system

integration documents to informal presentations and conversations among architects,

designers, and implementors. Finally, the implementation of a policy is an exercise

in concurrency, with diﬀerent components of the policy implemented in diﬀerent IPs

(in hardware, software, or ﬁrmware), that coordinate together to ensure adherence to

the policy.

Unfortunately, security policies in a modern SoC design are themselves signiﬁ-

cantly complex, and developed in ad hoc manner based on customer requirements

14 S. Ray et al.

and product needs. Following are some representative policy classes. They are not

complete, but illustrate the diversity of policies employed.

Access Control. This is the most common class of policies, and speciﬁes how diﬀer-

ent agents in an SoC can access an asset at diﬀerent points of the execution. Here an

“agent” can be a hardware or software component in any IP of the SoC. Examples 1

and 2 above represent such policy. Furthermore, access control forms the basis of

many other policies, including information ﬂow, integrity, and secure boot.

Information Flow. Values of secure assets can sometimes be inferred without direct

access, through indirect observation or “snooping” of intermediate computation or

communications of IPs. Information ﬂow policies restrict such indirect inference.

An example of information ﬂow policy might be the following.

∙ Key Obliviousness: A low-security IP cannot infer the cryptographic keys by

snooping only the data from crypto engine on a low-security communication fab-

ric.

Information ﬂow policies are diﬃcult to analyze. They often require highly sophisti-

cated protection mechanisms and advanced mathematical arguments for correctness,

typically involving hardness or complexity results from information security. Con-

sequently they are employed only on critical assets with very high conﬁdentiality

requirements.

Liveness. These policies ensure that the system performs its functionality without

“stagnation” throughout its execution. A typical liveness policy is that a request for

a resource by an IP is followed by an eventual response or grant. Deviation from

such a policy can result in system deadlock or livelock, consequently compromising

system availability requirements.

Time-of-Check Versus Time of Use (TOCTOU). This refers to the requirement

that any agent accessing a resource requiring authorization is indeed the agent that

has been authorized. A critical example of TOCTOU requirement is in ﬁrmware

update; the policy requires ﬁrmware eventually installed on update is the same

ﬁrmware that has been authenticated as legitimate by the security or crypto engine.

Secure Boot. Booting a system entails communication of signiﬁcant security assets,

e.g., fuse conﬁgurations, access control priorities, cryptographic keys, ﬁrmware

updates, debug and post-silicon observability information, etc. Consequently, boot

imposes more stringent security requirements on IP internals and communications

than normal execution. Individual policies during boot can be access control, infor-

mation ﬂow, and TOCTOU requirements; however, it is often convenient to coalesce

them into a uniﬁed set of boot policies.

剩余315页未读，继续阅读

soctest2010

粉丝: 0
资源: 6

会员权益专享

SoC与IP安全基石：设计、验证与调试指南

Fundamentals of RF and Microwave Transistor Amplifiers

F. Reif Fundamentals of Statistical and Thermal Physics

英文原版-Fundamentals of Anatomy and Physiology 2nd Edition

fundamentals of ip and soc security : design, verification, and debug

Fundamentals of Physics. Extended

fundamentals of power electronics 高清 pdf

fundamentals of physics 第10版 课件

fundamentals of signal enhancement and array signal processing 图书

【数字逻辑fundamentals of digital logic with verilog design | 3rd editio

fundamentals of computer graphics第三版和第四版差别

fundamentals of electric circuits 6th edition

fundamentals of power electronic

fundamentals of superscalar processors

fundamentals of microelectronics答案

fundamentals of photonics 答案

fundamentals of computer graph

fundamentals of logic design

fundamentals of microelectronics 答案

fundamentals of massive mimo

fundamentals of power electron

会员权益专享

最新资源

fundamentals of physics 第10版课件