1
CRESS: Quantifying Vulnerabilities of Attack Scenarios in Hardware Reverse Engineering
arXiv:2606.05459v1 [cs.CR] 3 Jun 2026
Alexander Hepp, Matthias Ludwig, Michaela Brunner, Johanna Baehr, Georg Sigl Abstract—The safety, security, and reliability of microelectronic systems depend on a trustworthy, secured supply chain and design flow. Globally distributed supply chains or unintentional design weaknesses leave the door open for attacks on the hardware level. These scenarios encompass counterfeiting, hardware trojans, or on-device attacks. For these, hardware reverse engineering (RE) results play a pivotal role. The ongoing publication of new RE-involved attacks motivated the development of the common RE scoring system (CRESS). The system enables a general classification of RE-involved scenarios for a common, consistent rating. In this work, the originally qualitative system is extended to a quantitative system. We performed an extensive interview study with experts in the field. The interview results allowed us to derive weights that measure the severity of different RE-involved attack categories. The weights form an equation that quantifies scenarios, resulting in the severity-indicating CRESS score. The score enables the coherent rating of novel scenarios, renders them comparable, and supports the development of effective countermeasures. To showcase the effectiveness of the quantitative CRESS Score, six selected case studies are rated qualitatively and quantitatively. The CRESS Score proves to be significantly more expressive than the industry-standard Common Vulnerability Scoring System (CVSS). Index Terms—hardware reverse engineering, hardware security, security framework, vulnerability quantification, threat analysis, case study, IC trust, IP theft, hardware trojans
✦
1
I NTRODUCTION
A
TTACK scenarios on hardware are increasing. These include on-device attacks (i.e. fault injection [1] or sidechannel analysis [2]) and supply chain-related scenarios (i.e. counterfeiting [3], intellectual property (IP) theft, or Hardware Trojans (HTs) [4]). Academia and industry are in the throes of new or more sophisticated attack capabilities and defense methods. Hardware has evolved as a viable attack target, beyond software, for many applications. Additionally, the extremely distributed microelectronics supply chain, born of cost pressures, has a strong division of labor, which further exacerbates the situation. Potentially untrustworthy actors are in the supply chain. It is challenging to focus on safety, security, and reliability measures during distributed design and implementation. This opens the doors to malicious activities in the form of counterfeiting or HTs. Ultimately, a tradeoff between trust, i.e. safety, security, and reliability, on the one hand, and profitability, on the other hand, is the practice. Standardized means to establish trust are available in the form of certification procedures (e.g. common criteria (CC) [5], platform security architecture (PSA) [6]), norms (e.g. SAE [7], [8], IDEA-STD-1010 [9]), vulnerability enumerations (e.g. Common Vulnerabilities and Exposures (CVE) [10], Common Weakness Enumeration (CWE) [11]), or scoring schemes (e.g. Common Vulnerability Scoring System (CVSS) [12]). For most hardware attack scenarios, hardware Reverse Engineering (RE) plays a significant role. This role might be direct, in the form of IP theft or counterfeiting, or indirect –
•
•
Alexander Hepp, Matthias Ludwig, Michaela Brunner and Georg Sigl are with the TUM School of Computation, Information and Technology, Munich, Germany. E-mail: {alex.hepp, matthias.ludwig, michaela.brunner, sigl}@tum.de Johanna Baehr and Georg Sigl are with the Fraunhofer Institute for Applied and Integrated Security (AISEC), Munich, Germany. E-mail: [email protected]
i.e. supporting – to aid HT insertion or simplify on-device attacks. RE research is at an all-time high, and the multitude of novel attack scenarios makes it extremely difficult to assess them. Previously mentioned standard scoring schemes allow a rough assessment of RE-involved scenarios. Yet, rating these with sufficient granularity is impossible. This motivated the development of a RE-specific rating scheme: the common reverse engineering scoring system (CRESS) by Ludwig et al. [13]. The framework allows a general, qualitative rating of RE-involved attack scenarios and renders them comparable. In this work, we aim to extend this framework by providing the CRESS score, i.e. the quantification of REinvolved attack scenarios, to enable quantitative comparability. The outline of this paper is: • First, the published qualitative CRESS framework [13]
is introduced. This includes a brief introduction to RE methods, their link to hardware attacks, and an explanation of the construction of the CRESS framework. • For the development of an adequate equation, interviews with experts in the field were conducted. The interview is outlined in detail regarding participants, style, and questions. • The results of the interviews are evaluated and utilized to build the equation for calculating a CRESS score. The resulting CRESS equation is introduced and explained in detail. • Finally, the framework is applied and evaluated via six selected case studies: A RE-improved laser fault injection [14], a RISC-V cryptographic chip with HTs [15], stealthy dopant HTs [16], IP infringement and subsequent vulnerability detection, and an attack based on reading out Non-Volatile Memory (NVM).
2
Foundry
Product
Chip Scans
Production
High Level Description
Netlist Abstraction
Standard Cell Identification
Interconnection Identification
Functional RE
Stitching
Imaging
Sample Preparation
Physical RE
GL netlist Hardware RE
Figure 1: Process flow for hardware reverse engineering of integrated circuits [13].
2
BACKGROUND
In the following, background on hardware reverse engineering and the architecture of the Common Reverse Engineering Scoring System (CRESS) is provided. 2.1
A Brief RE Overview
Hardware RE is the process of obtaining information of human-made devices. In the case of microelectronics, we can distinguish between system-level tear-downs, technology analyses, and layout or circuit extraction [17]. The results of the first category are component identification, bill of material creation, or simple packaging analyses. The latter two are more relevant to this work and are briefly explained below. The intermediate RE results ( RR ) used in CRESS are highlighted in italic. An overview of the RE process is illustrated in Figure 1. After the design and production of microelectronic devices in semiconductor fabs or foundries, typical RE would follow the depicted process. This process is divided into a physical and functional RE part. In the remaining paper, the attributes and values comprising CRESS are highlighted as Attr Value (see also section 2.2). 2.1.1 Physical RE Physical RE covers both technology analyses and layout or circuit extraction. Comprehensive studies of this flow have, e.g., been conducted in [18] or [19]. The first sub-process is the sample preparation. During sample preparation, the silicon die is removed from its package via a chemical or mechanical process. The die is depackaged DC , and a dieshot DS can be acquired. To get sensible results in the later stages, a cross-section CS of the die is produced. This exposes the manufacturing parameters of the front-end or wafer-level production phase, which includes the technology node, utilized materials, and geometrical parameters. Scanning electron microscopy allows the measurement of these technological parameters TM . Further, if a database of technologies is available, the identification of specific technologies TI is possible. Additionally, this information is required for sensible delayering, which is the gradual removal of the layers of the die. Via a mixture of chemical and mechanical processes, the metallization and active layers are exposed. For every layer, an imaging step is conducted. The tool for image acquisition is a high-resolution Scanning Electron Microscope (SEM). Due to large scanning areas, a single scan is insufficient, and several (up to 1000) unstitched images US are acquired. In the stitching process, they are aligned to
geometry-conserving two-dimensionally aligned mosaics SL . Following this, adjacent layers are superimposed to create a 3D stack LA . Interconnection identification, synonymously called backend-of-line extraction, is the process of segmenting conducting parts of metallization and vertical interconnect accesses via image processing (e.g. threshold, deep learning, or other specialized algorithms) and converting them to an appropriate format, e.g. GDSII GD . The identification of standard cells SI is handled differently. Features of cells are extracted and clustered accordingly. For every cluster, the cells’ functionality is inferred. The final stage of the physical RE phase is the gate-level flat-netlist FN generation, generally a gatelevel graph. This graph (G) is an ordered pair G = (V, E), where V is a set of vertices (or nodes), and E is a set of edges connecting the vertices. The edges can be either directed or undirected and may have weights (values) assigned to them. Small deviations of the sequential physical RE flow are possible. E.g., due to technological constraints, it might not be possible to utilize pattern recognition on the gate-level. Then, RE must work entirely on the transistor-level netlist to perform the gate-level reconstruction via graph partitioning [20]. 2.1.2 Functional RE The functional RE process is not sequential and is an explorative process that strongly depends on the specific target of an analysis. Yet, the basis for all analyses is the product of physical RE: the gate-level netlist or the netlist in graph representation. In the following, common analysis methods and respective results are introduced. These are in no particular order. A gate-level netlist can be partitioned PN by graph clustering methods [21], [22]. Via this approach, modules can be abstracted from the complete netlist. The identification and assignment of high-level signals HS allows a “data sheetlike” representation of signals such as input and output or the clock and reset [23]. The identification of data paths DI [24] allows the abstraction of combined signals such as buses. From a previously partitioned netlist, functional blocks PH [25] can be identified via structural- or similaritybased approaches, which match these modules to a library of modules. Besides the identification of the data path, another possibility is the extraction of the control logic CI or finite state machine (FSM) [26], [27]. Finally, we define a partial PF or complete functional identification CF at the gate level as the last result of functional reverse engineering.
3
Exploitability
Impact
RE Exploitability
Attack Exploitability
Entry point
Attack complexity
RE result
Supply chain intrusion
Intended
Timestamp Possible
IP / On-device confidentiality IP / On-device integrity
Available device information
2021-08-09
CRESS Vector String
+
10 0 CRESS Score This work
On-device availability
Remediation Strategies
Figure 2: Overview of the CRESS. The metrics result in a unique vector string for an individual scenario [13]. This involves a perfect reconstruction allowing functional or formal verification like in the forward design process. The RE result is only part of the complete CRESS architecture, which will be discussed in the following. 2.2
State of the CRESS
The architecture of CRESS is illustrated in Figure 2. From a high-level point-of-view, the architecture shows three main dimensions determining the CRESS vector string and score. These are the exploitability, the impact, and the timestamp. The target of the CRESS is the assignment of an attack vector by assessing the individual categories, as outlined in the following. The exploitability dimension is subdivided into two parts, of which the first is the RE exploitability. Here, the first attribute is the entry point, i.e. who is the attacking entity ( EP ). The individual values are the end customer E , foundry F , physical or back-end designer B , front-end designer in leading L or partial P role, and third-party IP providers I . Next, the previously elaborated RE result is categorized. This explains which RE result is necessary to enable a subsequent attack. The final attribute within the RE exploitability is the available device information ( AI ). An attack might target a fully open source design O , a partially open source design P , or a closed source design C . Next, the attack exploitability is rated, which comprises two attributes. First, the attack complexity ( AC ) describes the complexity of an attack that uses a given RE result. Overall, we define five generic values: N none, L low, M medium, H high, and X extreme. The none category refers to an attack in which the RR is directly used by the attacker, such as for IP theft, with no subsequent attack. A hobby attacker would be able to perform low-complexity hardware attacks. Next, unspecialized laboratories (medium) and specialized laboratories (high) could be involved. Finally, the extreme category describes attacks that only attack entities with unlimited resources, e.g., attacks which state actors could perform. Via the supply chain intrusion ( SI ), the permissions an attacking party requires for successful attack execution is defined. One option is that no intrusion is required N . Further, we define read-only access at selected abstraction levels L , read and write at a single abstraction level M , and read and write permission at multiple abstraction levels H . The final category included in the RE- and
the attack exploitability is remediation strategies ( RS ). We define these as countermeasures that are effective against the given attack vector. To avoid complexity, four categories are defined. None N defines that no countermeasure is available. Existing countermeasures are divided into active A** , observing *O* , and logic **L . Active countermeasures are defined as pre-silicon countermeasures that specifically aim to thwart RE, hardware attacks, or a combination of both. Examples are standard cell camouflaging [28] or logic locking [29]. Observing countermeasures, mostly postsilicon methods, aim for the detection of supply chain modifications. These methods include hardware Trojan detection [15], or avoidance and integrity or authenticity verification tools (e.g. such as in [30] or [31]). Finally, the logic category defines non-technical or technical solutions aiming at attack prevention; e.g. via access restrictions (e.g. to photo masks or GDSII design files) or split manufacturing [32]. The next dimension is the impact of an attack. The impact is categorized via three-letter symbols. The first letter defines whether an impact target was intended I** by an described attack, or was just a possible or unintended byproduct P** . The second letter describes the attack target. An attack vector might aim at on-device information *O* , including user data or key material. Another aim of an attack is IP *I* . This includes learned information like netlists or layout data. Finally, the third letter defines the attack targets. These are **C confidentiality, **I integrity, and **A availability. For on-device attacks, infringement of all three is possible, whereas for IP-related scenarios, only confidentiality and integrity can be targeted. Finally, a date timestamp is added in RFC3339 format [33] to account for ever-changing attack and defense mechanisms. These dimensions constitute the qualitative CRESS vector as published in [13]. As indicated by the red dashed box in Figure 2, the creation of the quantitative CRESS score is discussed in the following.
3
M ETHODOLOGY
The core idea of CRESS is to render hardware vulnerabilities and attacks based on RE comparable. The current state of CRESS allows to compare qualitatively. To allow a quantitative comparison, the scoring results must be translated into a numeric value using an equation. This section explains how such an equation can be built and how the influence of each CRESS attribute on the resulting score can be analyzed and decided. 3.1
Designing an Equation for CRESS
To the best of our knowledge, there are no numerical scoring systems for reverse-engineering based hardware attacks in the literature. However, similar to CRESS, the CVSS [12] up to version 3 uses an equation to derive the numeric score from the selected attribute values. The CVSS was, similar to CRESS, built to enable a quantitative comparison of vulnerabilities, but in Information Technology (IT) systems. Over 3 versions, the exact composition and weighing of factors in the equations were defined more precisely, but the general composition of the equation remained untouched.
4
CVSS calls its numeric score a “Technical Severity” [34], not a risk, as it does not include a valuation of the possible damage. This severity score uses the interval [0, 10], where 10 stands for the maximum possible severity and 0 stands for no severity. The following details are provided by the specification document of CVSSv3.1 [12]. CVSS builds its numeric score from two separately analyzed subscores: The exploitability score and the impact score. The exploitability explains how difficult it is to use the vulnerability or to allow the attack, while the impact scores how far an attack on the vulnerability can influence the operation of the IT system. Each subscore is a calculation on numeric values. Each numeric value corresponds to one CVSS attribute. Each attribute value has an associated numeric value used in the score calculation. While analyzing the score calculation, we noticed that the score calculation can be understood as a calculation on probabilities. The exploitability subscore is calculated by multiplying values akin to an intersection of independent probabilities. It can be understood that each exploitability value independently renders the vulnerability more or less probable, so that the exploitability probability can be calculated as the intersection of all the values. The impact subscore is calculated by multiplying values after subtracting them from 1 and subtracting the result from 1 again. This is akin to the calculation of the union of independent probabilities by using the complements. That means that the impact of an attack using the vulnerability will cause damage related to the combination of impacts. In the end, both subscores are combined in a weighted sum calculation (weighted arithmetic mean), akin to a mixture distribution. The final score both values the difficulty and the impact of the vulnerability with individual weights. As a result, the CVSS equation can be understood as a weighted calculation of probabilities in the interval [0, 1], which is afterwards scaled to [0, 10]. The aim for the design of the CRESS equation was to keep this intuitive explanation of the equation. In particular, the following aims were set for the equation design: • Explainable as a calculation on probabilities • Sensitive to changes both in Exploitability as well as Impact • Produces scores across the complete interval of [0, 10], by scaling the final score with a factor of 10. • Supports individual weights to control the influence of each attribute A similar calculation on numeric attribute values using some combination function that allows to include weights is required for CRESS. In general, to achieve a result in the interval [0, 1], such a weighted combination function must be carefully defined for given input intervals. When restricting the input intervals to [0, 1], the combination functions used in the CVSS equation (multiplication, complement multiplication, arithmetic mean) achieve this property. While designing the equation for CRESS, we decided to follow the intuitive pattern of CVSS for building the equation. As a consequence, for each CRESS attribute value an associated numeric value is required and needs to be defined. Furthermore, the influence of each attribute on the total score can and should be different, requiring a weight
of influence of the attribute on the total score. To collect a maximum of expertise into the CRESS equation, these weights and numeric values were collected with expert interviews. It must be noted, however that the newest version 4.0 of CVSS uses a different method for calculating the scores, that is a lookup table that encodes a total order of possible CVSS strings and produces a vulnerability score by enumerating this total order from 0 to 10. To achieve this total order, the CVSS 4.0 authors used various simplifications and assumptions to bring the number of possible combinations into a manageable magnitude and collected a large number of interviews for ordering this reduced list of combinations. We did not follow this approach due to the even larger number of possible combinations in CRESS. 3.2
Interview
To derive reasonable weights and numerical values for the novel scoring equation, we take into account the expertise of various specialists in the field of hardware RE, hardware attacks, and hardware implementation. A special concern during the design and evaluation of our interviews was to receive results with minimal human bias. To address this issue, we employed several methods, including the selection of interviewees, the choice of interview style, and specific techniques during the interview to ensure honest, focused, and unbiased responses. We aimed to interview experts with diverse backgrounds and varying areas and levels of expertise to reduce individual bias. To ensure every interviewee had an equal opportunity to respond, we scheduled individual interviews with sufficient time to cover the complete process. Furthermore, we established clear criteria for selecting interviewees, especially focusing on the expertise. More information on the interviewees can be found in section 4. While we initially considered survey questionnaires, early tests showed that they were not ideal for effectively capturing the nuanced understanding required for the complex subject matter, leading us to opt for structured interviews instead. We conducted pilot interviews to better understand the types of biases or misunderstandings that could occur. Using these findings, we planned, performed, and evaluated structured interviews with volunteering experts. To achieve measurable and evaluable results, we developed an interview concept that was well adapted to our objective of deriving scoring equation weights and numeric values, see Section 3.1. Additionally, the interview concept was designed to eliminate complex and confusing questions, aiming to minimize the need for long explanations and reduce the potential for misunderstandings. Considering this, and to ensure consistency between all the interviews, we decided to use a tool called Conceptboard [35] to carry out our interview in a standardized way. Conceptboard can be used to establish an interactive interview platform. The interviewee can answer each interview question by placing colored text boxes on a prepared scale. We chose to use scales to minimize bias, as they allow for quantified, precise, and comparable responses, while also reducing subjectivity. Depending on the intended granularity of the result, the order of the text boxes was either
5
(a) Exemplary question with free text box order
(b) Exemplary question with fixed text box order
Figure 3: Exemplary questions of the interactive interview using Conceptboard free to choose or fixed. To rate the attack severity of the RE result values and entry point values, and of the impact attributes, the interviewee was asked to place the text boxes on a scale from “not critical” to “critical”. The order of the values or attributes was not provided, see the example for the impact values in Figure 3a. To rate the attack severity of the available device information, attack complexity, and supply chain intrusion values, the interviewee also placed the text boxes on a scale from “not critical” to “critical”. However, the order of the text boxes was predetermined, and it could not be altered; see the example for attack complexity in Figure 3b. To gain further insights into the remediation strategy attribute RS , we asked the interviewees to sort various remediation strategies based on their implementation difficulty. The interviewees could also add new remediation strategies if they felt it was necessary. Finally, the interviewee placed a symbol for each exploitability attribute ( EP , RR , AI , AC , SI ), a symbol for the remediation strategy RS , and a symbol for the joint impact on a separate scale. In this way, the interviewee explained how strongly the respective attribute should influence the total vulnerability score. In addition to the semi-structured interview format with predefined questions, we also included an interview guideline for the interviewer, ensuring a consistent set of questions for all interviewees to maintain uniformity in data collection. This also guarantees the best possible comparability between the different interviews. Thus, independent of the interviewer, the introduction, explanations, examples, and questions remain consistent throughout the interviews. The interview started with a short introduction, including information about the interviewers, the reason for the interview, a short summary of the existing CRESS framework, the interview conditions, and an overview of Conceptboard. This also ensures that the research objective of the interview is clear to the interviewee, which helps to focus their answers. For this purpose, we prepared an introduction slide to highlight the most important facts about CRESS, as well as a slide to test the correct functionality of Conceptboard. During this introductory phase, we also wanted to create a comfortable environment for our participants; we utilized icebreaker questions to foster trust and encouraged honest responses. Next, the main part of the interview started. In this
phase, each rating question was preceded by a concise introduction, explanation and example. Then, the question itself, along with the action task, was presented, requiring the interviewee to assign a placement for each item as described before. We specifically phrased all interviewer text to be neutral and non-leading to avoid influencing the responses. To improve the later evaluation of the results, we recorded the interview in writing with the consent of the interviewees. We consciously chose not to record the interview audio or video to encourage more open responses. The written recording allows for cross-evaluation with the answers provided in Conceptboard. Furthermore, this approach allowed for the documentation of contextual notes, which helped us interpret the data more accurately later. Consequently, each interview was conducted by a moderator and attended by a dedicated recorder We also encouraged the interviewees to comment on their actions and think out loud while answering the questions. This made potential biases recordable and helped us understand ratings of specific values or attributes, providing us with new insights into their thought processes. Additionally, the final question asked the interviewee to rate their expertise in various areas related to RE and hardware security. For this, the interviewee placed research fields, such as netlist RE, FPGA, or physical attacks, on a two-dimensional diagram with axes representing the time spent working on the topic and their level of expertise. Additionally, the interviewee had the option to add a new research field. The final Conceptboard interview can be found at [36].
4
R ESULTS
This section describes how the CRESS score equation was derived from the knowledge gained in the interviews. 4.1
Interview
We performed 21 interviews, including an interview for each of the authors. Despite the small number of interviewees, we believe their insights are significant, especially given the limited pool of experts in the field, particularly those knowledgeable in hardware reverse engineering. To recruit volunteering specialists, we invited known experts in the field of hardware reverse engineering, attacks, or implementations in person or by email. We identified these experts through academic publications, funded projects, and industry associations related to the topic of hardware reverse engineering. We also advertised at hardware securityspecific workshops. While many of the interviewees are based in Europe, experts from Asia, the Middle East, and North America were also represented. A final review of the recordings showed that the results of two complete interviews and portions of two other interviews needed to be excluded from the final evaluation because, despite careful planning, substantial misunderstandings occurred during the interviews. Thus, for the evaluation of the majority of the questions, we could use the data from 19 interviews. We are optimistic about the gathered results from these interviews, although we are
6
Table 1: Overall Weight, Attribute Weight (wattr ) and derived Numeric Value (Vattr ) for each Attribute Value. Weights not directly derived from interview results are indicated by an asterisk (*). Overall Weight
Attribute Weight (wattr )
Entry point EP
0.75
RE result RR
0.73 0.65
Available device information AI
0.35
Attack complexity AC
0.73
Supply chain intrusion SI
0.69
E
F
B
P
I
L
0.74
0.69
0.48
0.43
0.70
0.44
DC
CS
TM
TI
DS
US
SL
LA
GD
0.91
0.76
0.79
0.74
0.90
0.62
0.51
0.42
0.37
SI
FN
PN
HS
PH
CI
DI
PF
CF
0.50
0.34
0.24
0.35
0.24
0.21
0.21
0.11
0.07
C
P
O
0.87
0.66
0.41
N* 1.00
L
M
H
X
0.93
0.76
0.50
0.28
N
L
M
H
0.93
0.75
0.50
0.34
N* 1.00
AOL
0.48
H* 0.90
L* 0.22
N* 0.00
0.61
H* 0.90
L* 0.22
N* 0.00
(I/P) On-Device Confidentiality *OC
0.68
H* 0.90
L* 0.22
N* 0.00
(I/P) On-Device Integrity *OI
0.65
H* 0.90
L* 0.22
N* 0.00
(I/P) On-Device Availability *OA
0.57
H* 0.90
L* 0.22
N* 0.00
Remediation Strategy RS (I/P) IP Confidentiality *IC Impact
Numeric Value (Vattr )
(I/P) IP Integrity *II
0.84
aware that the inherent limitations of a smaller sample will be reflected in a margin of error. However, the depth and detail of the interviews, as well as special considerations taken to minimize human bias, can mitigate some of the limitations that come with this smaller sample size. The expertise of our interviewees included several specialists in hardware RE, but also specialists in software and hardware implementations, physical/backend or digital design, failure analysis, or physical attacks. We asked our interviewees to assess their expertise and years of expertise across 24 categories, though they were not required to rate themselves in every category. On average, they provided ratings for 10 categories. The responses for four of the more commonly chosen categories are illustrated in Figure. 4. For example, many of the interviewees rated themselves with a high level of expertise and long experience in netlist reverse engineering, whereas for physical reverse engineering the ratings were more spread out. 4.2
Interview Evaluation
For the final evaluation, the Conceptboard slides with the placed text boxes were translated into a tabular format. In each interview and question, for each text box, a value in [0, 1] is assigned, which describes the relative horizontal
0.63
10 years Years of Experience
Exploitability
Attribute
1 month Novice
Expert Level of Expertise
Figure 4: Self-rated Interviewee expertise and experience for netlist RE, physical RE, digital design, and hardware attacks. position on the scale (see Figure 3). In the following, we will refer to this value as Data Point (DP). These DPs are then used to derive the weights and numeric values for the scoring equation. All weights and numeric values are shown in Table 1. We also provide the anonymized raw data for
7
each interviewee [36]. We define Vattr as the numeric value associated with the CRESS Attr Value in Table 1, whereas wattr is the attribute weight associated with the CRESS Attr in Table 1. Weights not directly derived from interview results are indicated by an asterisk (*). We also show standard deviations of the DPs for the weights in Figure 5. All weights and numeric values are derived by averaging over the available DPs. For averaging, we used the mean or the median. As the mean is not robust against outliers, it allows us to represent the disagreement of the interviewees’ DPs. Instead, the median is robust against outliers and thus allows us to find consensus from the interview DPs. For example, the DPs for end user EP E have a high spread because the interviewees’ argumentation varied. Most interviewees scored EP E as a highly critical entry point EP because a malicious end user might be more common than, e.g. a malicious front end designer. In contrast, some interviewees scored the end user EP E as an uncritical entry point EP , as the end user’s influence is limited to one or a few products. In contrast, a front end designer can compromise an entire batch of products. This is also reflected in the high standard deviation for the Entry Point Attribute EP , as shown in Figure 5. Other attributes, such as the RE Result RR or Available Device Information AI have a smaller standard deviation for their values, suggesting a similar view among interviewees regarding the impact of these values on the severity of the attack. The arithmetic mean was used for averaging the DPs of the numeric values. Thus, we numerically represented the disagreement there. However, the exploitability attribute weights DPs were averaged with the median to find a consensual compromise. As the impact numeric values were set empirically (see section 4.3), the impact attribute weights were averaged using the mean so that interviewees’ disagreement is not disregarded. Figure 5 shows the mean and median for the exploitability numeric values and impact attribute weights. The attribute weights wattr in Table 1 show similar weights for the attributes entry point EP , RE result RR , attack complexity AC , and supply chain intrusion SI , while rating the attribute available device information AI less severe. For the possible and intended impacts ( P** , I** ), on-device Confidentiality *OC was identified as having the greatest impact on severity, whereas attacks affecting IP Confidentiality *IC were considered to be less critical. Finally, to determine the final severity, we assessed the results for the overall weight of exploitability and impact. We calculate the overall weight of exploitability as mean of the derived weights of the following attributes: entry point EP , RE result RR , available device information AI , attack complexity AC , and supply chain intrusion SI . The overall weight of impact could be derived directly from the interview DPs. The results, as shown in Table 1, indicate that impact attributes are deemed to have a greater influence on attack severity compared to exploitability. This means that, according to our interviewees, the potential and intended impact ( P** , I** ) play a more crucial role in evaluating the seriousness of the attack. We also derived the numeric values for all remediation
strategy values. However, the evaluation shows no significant difference when examining the means of the numeric values of the various types of remediation strategies, namely 0.41 for pre-silicon remediation strategies RS A** , 0.48 for detection-based post-silicon remediation strategies RS *O* , and 0.45 for logic-based remediation strategies RS **L . Also, deriving an individual numerical value for each remediation strategy separately, is not considered as a reasonable approach. A very wide range of remediation strategies exist, and new methods are constantly developed, so any list would immediately be outdated or incomplete. Thus, for our equation, we decided to consider only the fact of whether a remediation strategy exists for the attack or not, without considering graded numerical values for any concrete strategies. This is also emphasized in Table 1. We derive the numeric value for “existing remediation strategy” by taking the complement of the derived remediation strategy attribute weight: 1 − 0.37 = 0.63. 4.3
Equation Implementation
The interview results provide the basis for deriving the CRESS scoring equation. Based on the analysis in section 3.1, we define the CRESS exploitability subscore Exp. Score = (VEP )wEP · (VRR )wRR · (VAI )wAI 1 ·(VAC )wAC · (VSI )wSI wEP +wRR +wAI +wAC +wSI .
(1)
Thus, the exploitability score is calculated as the weighted geometric mean of the exploitability attribute value weights. The multiplication ensures that the exploitability score is an intersection of the individual attributes, while the exponentiation ensures a weighted combination. For the impact score, it is necessary to join the impact numeric value of the intended aim with the impact numeric value of the possible aim within each impact variant. To join the impacts, we define a impact sum V attr = min VIntended Attr + 0.5 · VPossible Attr , 0.9) (2) Thus, the combined impact of intended and possible aim is a capped sum of the respective impact attribute numeric values, in which the possible aim will only contribute with half the intensity. This non-linear combination increases the influence of the possible impact iff the intended impact is not H . With this, we define the impact subscore wIC wII Imp. Score = 1 − 1 − V IC · 1 − V II wOC wOI · 1 − V OC · 1 − V OI (3) w +w +w 1 +w +w wOA IC II OC OI OA . · 1 − V OA Thus, the impact score is calculated as the complement of the weighted geometric mean of the complement of the capped impact sums. The calculation on complements produces a result similar to the union of the impact of the individual attributes, while the exponentiation weights the combination.
8
Entry Point
RE Result
1
1
0
0 E F B P
I
L
DC CS TM TI DS US SL LA GD SI FN PN HS PH CI DI PF CF
Available Device Information
1
Attack Complexity
1
0
1
0 C
P
O
Supply Chain Intrusion
1
0 L
M H
Impact Attribute Weights
0
X
N
L
M H
IC
II DC DI DA
Figure 5: Standard Deviation and mean • / median (×) of Numeric Values for Exploitability and Attribute Weights for Impact Finally, we define the total CRESS score CRESS Score =
10 ·
(4) 0.65 · sensitize(Exp. Score)· VRS + 0.84 · Imp. Score · 1.111 /1.49, , if Any Impact ̸= N 0, else
sensitize(x) =
1.0071 1 + exp [−20(x − 0.6372)]
(5)
The total score is, in general, a weighted mean calculation on the exploitability and impact subscores, thus akin to a mixture distribution calculation. However, several adaptions were made to better match the aims stated in section 3.1. The sensitize transformation is a logistic function that ensures that the total score is sensitive to changes in exploitability. Only after this transformation the equation achieves the goal that a significant change in an exploitability attribute (eg. from AC L to AC X ) results in a significant change in the total score (eg. from 6 to 5). The parameters of the logistic function were set empirically. As the weighted geometric mean is 0 if one of its factors is 0, the complementation means that the impact subscore would be 1 if any impact is 1, so the equation would miss sensitivity to changes in any other impact attributes. To achieve sensitivity to changes in impact, we choose the numeric values for the impacts to be 0.9 at maximum. The other numeric values are chosen empirically, resulting in: H = 0.90, L = 0.22, and N = 0.00, see Table 1. However, H = 0.90 means that the impact subscore can reach a value of 0.9 at maximum, so the total score would not achieve values in [0, 10]. Thus, the scaling factor of 1.111 ensures that the impact subscore is scaled to the interval [0, 1]. Finally, the total score is scaled with 10, so that it produces scores in the interval [0, 10]. If exploitability and
impact scores are displayed separately, they should also be multiplied by 10 for comparability. When the remediation strategy is treated as a binary decision, the total number of possible combinations across all attributes is 765,275,040. Figure 6 illustrates the analysis of the equation’s outcomes for each of these combinations, using a histogram with 1,000 bins distributed evenly between 0 and 10. The distribution of the CRESS Score approximately follows a normal distribution centered around a mean value of approximately 5, as expected and desired from such a score. For the exploit score, we show both the final exploit score, which includes the remediation strategy and sensitization, as well as the original exploit score, without the remediation strategy and logistic function. We can observe the clear impact of sensitization. The final exploit score approximately follows a geometric distribution, while the impact variable approximately shows an inverted geometric distribution. Together, these result in the desired final score.
5
C ASE S TUDIES
In the following, selected case studies are rated. These are taken from the original CRESS paper [13], where they were described qualitatively. For a basic understanding, the studies are briefly explained and, subsequently, quantitatively discussed. 5.1
RE-Improved Fault Injection
The first study is a RE-improved fault injection published by Courbon et al. [14]. In the exemplary scenario, a hardwareimplemented AES cipher is attacked. For the attack, two devices are necessary. One is for reverse engineering of the device, and the other is for the subsequent laser fault injection. The reverse-engineered sample is prepared to the polysilicon layer, effectively exposing the structure of the gates. After scanning and two-dimensional stitching, flipflops are detected through a pattern recognition algorithm.
9
IIC H . Further impact is unintended and minor caused as a by-product of the laser fault-injection POI L , POA L . This results in the following CRESS vector string:
(a) CRESS Score for all combinations
EP:E/RR:SI/AI:C/AC:H/SI:N/RS:A/IIC:L/III:N/IOC:H/IOI:N/IOA:N/ PIC:N/PII:N/POC:N/POI:L/POA:L/T:2023-12-01.
0
1
2
3
4
5
6
7
8
9
10
(b) Exploit Score for all combinations
0
1
2
3
4
5
6
7
8
5.2
9
10
(c) Exploit Score for all combinations without logistic function and remediation score
0
1
2
3
4
5
6
7
8
9
10
9
10
(d) Impact Score for all combinations
0
1
2
3
4
5
6
7
8
The CRESS total score (Equation 4) of this scenario is 4.42, with an impact subscore (Equation 3) of 5.3 and an exploitability subscore (Equation 1) of 6.6.
Figure 6: Histogram of CRESS Scores for all combinations of attributes. Via this approach, the location of the flip-flops enables a highly improved attack for which pre-localized areas are targeted. With additional knowledge about the AES implementation characteristics and timing information, the overall attack duration is reduced by a factor of several hundred. This scenario is first qualitatively rated, allowing the deduction of the CRESS vector string: RE exploitability: In the scenario, the entry point is the end-user EP E . His/her target is the detection of standard cells RR SI , which is a relatively high target, building on intermediate targets such as the delayered, scanned, or stitched IC. Further, no additional information is available AI C . Attack exploitability: The laser fault injection requires specialized equipment, usually only found in dedicated laboratories AC H . The attack targets the end product, thus no supply chain intrusion is required SI N . There exists an effective defensive mechanism against this attack vector RS A . Possibilities are cell camouflaging to thwart the easy detection of flip-flops [28] or fault-resistant AES implementations [37]. Impact. The main target of the attack is on-device confidentiality, aiming at the extraction of the secret AES key IOC H . Further, RE reveals design information like the floorplan or information about the standard cell library, including the position of the attacked flip-flops resulting in
RISC-V Hardware Trojans
The next case study is a RISC-V implementation with hardware Trojans by Hepp and Sigl [15]. The authors taped out an open-source microcontroller design with post-quantum cryptographic accelerators. Four HTs infected the design, and the attacker is assumed to be a malicious IP provider of the microcontroller base design. For this example, we focus on one of the HTs that leaks arbitrary data through power or EM emanation. The rating of the attack is as follows: RE exploitability: The attacking party is the IP provider EP I . To be able to insert a functional HT, which enables the side-channel, the attacker requires the information from a partial functional identification (source of leaked data, trigger conditions, etc.) RR PF . The available device information in the scenario is open source AI O . Attack exploitability: Modifications in the supply chain are required by the addition of logic at the RTL level (read and write) and also for the corresponding software compiler framework (read and write), resulting in a high level of supply chain intrusion SI H . The side-channel can be exploited with equipment found in a standard, unspecialized laboratory AC M . Remediation strategies are available,e.g. obfuscation or HT detection approaches RS AO . Impact. The HT insertion heavily affects two aspects. The first is the design integrity III H caused by the HT insertion. The second is on-device confidentiality caused by data leakage through the side-channel IOC H . Further minor, possible impacts are on-device integrity or availability POI L , POA L potentially caused by device overheating or voltage depletion caused by the HT execution. The attack vector yields following CRESS vector string: EP:I/RR:PF/AI:O/AC:M/SI:H/RS:AO/IIC:N/III:H/IOC:H/IOI:N/IOA:N/ PIC:N/PII:N/POC:N/POI:L/POA:L/T:2023-12-01.
The CRESS total score of this scenario is 4.15, with an impact subscore of 7.4 and an exploitability subscore of 3.8. 5.3
Stealthy Dopant Hardware Trojans
The third case study also focuses on an HT insertion scenario titled stealthy dopant Trojans by Becker et al. [16]. The HT scenario merely requires the modification of a single photomask or layer in the layout file – the dopant mask or layer – and subsequently enables covert power side channels. The strength of the attack is that the modification of dopant polarities, such as alterations of vertical interconnect access or metallization layers, cannot be detected via scanning electron microscopy. In the following, we focus on a specific attack scenario in the paper: the side-channel leakage of parametrically modified improved Masked Dual-Rail Logic (iMDPL) gates. Through a change of dopant masks, a change of transistor areas leads to power side-channels. Via a correlation power analysis (CPA) on the SBox of an AES
10
implementation, the key is leaked via this modification. RE exploitability: .The attacking party is a fab or foundry EP F . The attacking party must perform a partial functional identification RR PF . I.e., starting from the physical layout, the location and adjacent functionality of the targeted gates must be reverse-engineered for HT insertion. No available device information is necessary AI C . Attack exploitability: The attack complexity is high AC H . Specialized equipment is necessary to exploit the covert sidechannels. The supply chain intrusion is medium SI M , with read and write permission needed for the layout. Remediation strategies against this vector are available RS AO . Active strategies are e.g. obfuscation techniques such as logic locking. An observing countermeasure is the passive voltage contrast of delayered devices [38]. Impact. The impact is similar to the previous HT example. The major impact is the on-device confidentiality IOC H (sidechannel leakage) and the IP integrity III H (layout tampering). A minor, possible impact is the on-device integrity and availability POI L , POA L . The scenario results in the following CRESS vector string: EP:F/RR:PF/AI:C/AC:H/SI:M/RS:AO/IIC:N/III:H/IOC:H/IOI:N/IOA:N/ PIC:N/PII:N/POC:N/POI:L/POA:L/T:2023-12-01.
The CRESS total score of this scenario is 4.16, with an impact subscore of 7.4 and an exploitability subscore of 4.0. 5.4
IP Infringement Scenarios
The next scenarios focus on IP infringement and have equal RE exploitability. The first scenario covers merely the theft of an exemplary proprietary design. For the second scenario, a vulnerability is detected and exploited via design analysis. The RE exploitability for both scenarios is the following: They are performed by an end user EP E . Partial functional identification RR PF of the specific module is the necessary identification target to enable either the theft and re-use of the IP or an attack on the IP. Both scenarios are carried on proprietary, closed source designs AI C . 5.4.1 IP Theft of a Proprietary Multiplier Architecture This example does not include a subsequent attack, and the identification or theft of the proprietary multiplier architecture is already the attack AC N , SI N . Remediation strategies exist RS A in the form of making the design extraction complex. It can be achieved by obfuscation methods such as camouflaging, logic locking, or watermarking to prevent the piracy of proprietary IP. Impact. The only impact of this vector is IP confidentiality IIC H . All other categories are none. This results in the following CRESS vector string: EP:E/RR:PF/AI:C/AC:N/SI:N/RS:A/IIC:H/III:N/IOC:N/IOI:N/IOA:N/ PIC:N/PII:N/POC:N/POI:N/POA:N/T:2023-12-01.
The CRESS total score of this scenario is 2.17, with an impact subscore of 3.1 and an exploitability subscore of 5.4. 5.4.2 Vulnerability Detection in a Proprietary Cryptographic Algorithm This case tackles vulnerability detection in a proprietary cryptographic algorithm. Via RE, the functionality of the algorithm is profoundly understood, enabling the vulnerability exploitation of it. We assume a trivial example: The
design is identified to use the vulnerable SHA-1 hash function. For this, the attacker can use public collision attack strategies[45]. Attack exploitability: The subsequent attack may be executed with unspecialized equipment AC L . Further, no supply chain intrusion is needed SI N . Again remediation strategies exist RS A . They are the same as in the previous example (active), plus the usage of a secure algorithm can thwart an attack (e.g. SHA-3). Impact. The impact of the attack is IP confidentiality IIC H , i.e. the hash algorithm, and the on-device integrity IOI H , as the hashed data can be exchanged. This results in the following CRESS vector string: EP:E/RR:PF/AI:C/AC:L/SI:N/RS:A/IIC:H/III:N/IOC:N/IOI:H/IOA:N/ PIC:N/PII:N/POC:N/POI:N/POA:N/T:2023-12-01.
The CRESS total score of this scenario is 3.91, with an impact subscore of 6.2 and an exploitability subscore of 5.3. 5.5
Reverse Engineering Data in Non-Volatile Memory
The final case study considers an attack on a device with unprotected NVM. Assume that the memory stores cryptographic keys both for on-device encryption and secure boot. The attack uses reverse engineering techniques to read the non-volatile data and aquire these keys (e. g. [46], [47]). RE exploitability: The attacking party is the end user EP E . The attacking party must aquire unstitched SEM images of the NVM to read the stored keys RR US . No available device information is necessary AI C . Attack exploitability: The attack complexity is medium AC M , Courbon et al. [46] explicitly state that the equipment can be found in a standard, unspecialized laboratory. No supply chain intrusion is necessary SI N . Remediation strategies against this vector are available RS A . Active strategies are e.g. obfuscation techniques or using tamperproof memory such as with anti-fuses [47] or memory encryption. Impact. The impact both considers the readout of the device keys as a minor IP impact IIC L , as well as the total control over the device, as the security of encryption and secure boot is breached ( IO* H ). The scenario results in the following CRESS vector string: EP:E/RR:US/AI:C/AC:M/SI:N/RS:A/IIC:L/III:N/IOC:H/IOI:H/IOA:H/ PIC:N/PII:N/POC:N/POI:N/POA:N/T:2023-12-11.
The CRESS total score of this scenario is 7.36, with an impact subscore of 8.6 and an exploitability subscore of 7.6. 5.6
Discussion
The strength of CRESS is explicit when utilized comparatively. The comparison is illustrated in Table 2. 5.6.1 CRESS renders attacks comparable The least-severe attack scenario is the IP-theft. While the exploitability is on a medium level, the low impact score leads to a low overall score. The most-severe attack is the readout of the NVM, because both exploitability as well as impact are severe. Notably, the first three scenarios lead to similar overall scores. That means that by using CRESS, we can identify these attacks as similarly dangerous. On an absolute scale, the three attacks show medium danger. This is on-par with
11
Table 2: Overview of the five case studies with exploitability subscore, impact subscore, and total score. On the right, the scores are compared to CVSS v3.1a . The CVSS Medium rating interval is 4.0 − 6.9. Case study Fault attack [14] RISC-V HTs [15] Dopant HTs [16] IP theft Vuln. detection NVM readout
CRESS Exploitability Impact
Score
Exploitability
6.6 3.8 4.0 5.4 5.3 7.6
4.42 4.15 4.16 2.17 3.91 7.36
5.02 3.77 3.77 5.02 5.02 5.02
5.3 7.4 7.4 3.1 6.2 8.6
CVSS v3.1 Impact Score 3.56 3.56 3.56 2.39 2.39 5.60
5.3 4.9 4.9 4.9 4.2 6.4
Rating Medium Medium Medium Medium Medium Medium
[39] [40] [41] [42] [43] [44]
p √ a. The CVSS v3.1 exploitability was calculated as 4 AV · AC · P R · U I · 10 and the impact as 1 −3 (1 − C) · (1 − I) · (1 − A) · 10 to make these sub-scores’ intervals comparable to those of CRESS.
industry practice: The level of danger associated with such attacks is medium, because only at-risk systems are protected against fault and hardware trojan attacks. The major difference between these scenarios becomes explicit when focusing on the exploitability and impact subscore. The attacks involving HTs (i.e. RISC-V [15] and dopant HTs [16]) have relatively high impact subscore. Yet, their low exploitability subscore indicates their exploitation requirements are high. On the opposite, the Fault attack case study shows high exploitability, because the RE effort is low, but the impact is more limited. The IP-theft-based attack scenarios achieve low CRESS scores. While the exploitability yields a high score, the impact is limited. IP leakage of the mentioned proprietary multiplier module might be uncritical for end-users. Yet, the economic or reputation damage for the designer is significant. An attack that performs significant RE to find the vulnerable use of SHA-1 bears little danger, as other means, such as a protocol analysis, can achieve this result without any RE. The last case study shows that even with moderate RE effort, a high CRESS score can result if the impact is significant. This is on par with industry best practice, as non-volatile memory for security-related purposes is always tamper-proofed. 5.6.2 CRESS is more expressive than CVSS Using the CRESS score, the attack scenarios are much more comparable than the scores produced by CVSS. All case studies produce a rating in the medium range, three rate equally. The exploitabilities of all but the HT case studies are equal because the CVSS cannot represent the details of hardware attacks. The granularity of the impact is equally low. This is because the whole category of IP impact is not represented and the possibility of a further compromise using a non-patchable hardware exploit cannot be represented with CVSS. CVSS also gives obviously-wrong results because it rates the IP-theft case study more dangerous than the IP theft with an additional attack on the hardware—This is because in the IP-theft scenario, the IP-impact can only be represented by a scope change, else this scenario would be rated with zero impact. We conclude that CVSS is not fit for rating hardware attack scenarios. 5.6.3 CRESS is applicable to all hardware CWE As the CRESS is more expressive than the CVSS, it provides advantages when evaluating hardware-based attack scenar-
ios. The CWE provides a broad taxonomy of weaknesses in hardware [48], ranging from manufacturing management to physical access. These listed weaknesses can, partially, be found using software-based discovery or random testing. These techniques do not involve RE. Consequently, attack scenarios based on such attack vectors are out of the scope of CRESS. However, all attack scenarios using any weakness listed in the Hardware Design CWE can be rated using CRESS, as soon as the process of weakness discovery uses any kind of hardware RE. This renders CRESS broadly applicable to a wide range of attack scenarios, as most direct hardware attacks involve some kind of hardware RE.
6
C ONCLUSION
We have enhanced the existing categorization of reverse engineering-based attacks by introducing a formula that assigns a score to describe the severity of these attacks. The formula was developed by consulting specialists to assign value to each CRESS attribute and value, followed by a thorough evaluation of their responses. Higher-rated attacks are considered more severe, while lower-rated attacks are either difficult to exploit or have minimal impact. This scoring system not only allows us to categorize attacks based on their qualitative values in each category but also enables us to calculate a quantitative score for each type of attack. This is highly beneficial as it allows us to better compare different attack types and provides a quantifiable measure of the severity of new attacks. Additionally, it allows for the analysis of potential future attacks and the implementation of appropriate countermeasures. By leveraging the CRESS Score, we can develop accurate and tailored countermeasures for attacks that are deemed severe enough to warrant them. A web-based tool is available at [36]. The tool allows users to select CRESS attribute values according to their scenario to score it. The tool will then calculate the total CRESS score as well as the exploitability and impact subscores. With the CRESS Score, it is now possible to rate attacks based on weaknesses in the hardware CWE database more expressively. CRESS is applicable as long as the attack does not fall outside the realm of reverse engineering and cannot be classified and quantified using the CRESS Score. Furthermore, while CRESS provides a quantified, comparable, and useful rating, it is important to consider more granular ratings when necessary. Nevertheless, we believe that our approach covers a wide range of attacks that require some form of reverse engineering and provides a fair platform for
12
rating them. Our methodology strikes a balance between generality for the purpose of comparison and specificity to allow for good differentiation. As with the CVSS, we anticipate and hope for multiple iterations of the score as the community engages with and enhances it, fostering continuous improvement.
[19]
ACKNOWLEDGMENTS
[22]
We would like to sincerely thank our interviewees for their valuable contributions to this research: Nils Albartus, Navid Asadi Zanjani, Leonid Azriel, Steffen Becker, Ann-Christin Bette, Swarup Bhunia, Domenic Forte, Bernhard Lippmann, Samuel Pagliarini, Jofre Pallarès, Endres Puschner, Jonas Ruchti, Julian Speith, Zain Ul Abideen, René Walendy, and Edward Wang. This work was partly funded by the German Ministry of Education and Research in the project VE-FIDES under Grant No.: 16ME0257.
[20] [21]
[23] [24]
[25] [26]
R EFERENCES [1] [2] [3] [4] [5] [6] [7]
[8] [9]
[10] [11] [12] [13]
[14]
[15] [16] [17] [18]
A. Benso and P. Prinetto, Eds., Fault Injection Techniques and Tools for Embedded Systems Reliability Evaluation. 2003, 1241 pp. S. Mangard, E. Oswald, and T. Popp, Power Analysis Attacks: Revealing the Secrets of Smart Cards, 1st. 2010. M. M. Tehranipoor, U. Guin, and D. Forte, Counterfeit Integrated Circuits: Detection and Avoidance. 2015. S. Bhunia and M. M. Tehranipoor, The Hardware Trojan War: Attacks, Myths, and Defenses. 2017. Bundesamt für Sicherheit in der Informationstechnik. “Common Criteria Certification. ”https://www.commoncriteriaportal.org/ cc/. PSA Certified. “Platform Security Architecture (PSA) Certification. ”https://www.psacertified.org/. SAE International, Test Methods Standard; General Requirements, Suspect/Counterfeit, Electrical, Electronic, and Electromechanical Parts AS6171, 2016. https://www.sae.org/standards/content/ as6171/. SAE International, Counterfeit Materiel; Assuring Acquisition of Authentic and Conforming Materiel AS6174, 2017. https://www. sae.org/standards/content/as6174/. The Independent Distributors of Electronics Association (IDEA), IDEA-STD-1010-B: Acceptability of Electronic Components Distributed in the Open Market, 2018. https : / / idofea . org / quality standards/. The MITRE Corporation. “The Common Vulnerabilities and Exposures (CVE). ”https://www.cve.org/. The MITRE Corporation. “Common Weakness Enumeration (CWE). ”https://cwe.mitre.org/. I. FIRST.Org. “Common Vulnerability Scoring System version 3.1: Specification Document. ”https : / / www. first . org / cvss / v3.1/specification-document. M. Ludwig, A. Hepp, M. Brunner, and J. Baehr, “CRESS: Framework for Vulnerability Assessment of Attack Scenarios in Hardware Reverse Engineering,” in 2021 IEEE Physical Assurance Inspection Electron.s (PAINE), (Dec. 2021), 2021. F. Courbon, P. Loubet-Moundi, J. J. A. Fournier, and A. Tria, “Increasing the efficiency of laser fault injections using fast gate level reverse engineering,” in 2014 IEEE Int. Symp. HardwareOriented Secur. Trust (HOST), 2014. A. Hepp and G. Sigl, “Tapeout of a RISC-V Crypto Chip with Hardware Trojans,” in Proc. 18th ACM Int. Conf. Comput. Frontiers. 2021. G. Becker, F. Regazzoni, C. Paar, and W. Burleson, “Stealthy dopant-level hardware Trojans: Extended version,” J. Cryptogr. Eng., 2014. R. Torrance and D. James, “The State-of-the-art in Semiconductor Reverse Engineering,” in Proc. 48th Des. Automat. Conf., 2011. R. Quijada, R. Dura, and J. Pallares, “Large-Area Automated Layout Extraction Methodology for Full-IC Reverse Engineering,” in J. Hardware Syst. Secur., 2018.
[27] [28] [29] [30]
[31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44]
B. Lippmann et al., “Verification of physical designs using an integrated reverse engineering flow for nanoscale technologies,” Integration, 2020. M. Putz, M. Ludwig, B. Lippmann, and H. Graeb, “PLaNe: Reverse Engineering of Planar Layouts to Gate-Level Netlists,” in 2023 IEEE Physical Assurance Inspection Electron.s (PAINE), 2023. P. Subramanyan et al., “Reverse Engineering Digital Circuits Using Structural and Functional Analyses,” IEEE Trans. Emerg. Topics Comput., 2014. M. Werner, B. Lippmann, J. Baehr, and H. Gräb, “Reverse Engineering of Cryptographic Cores by Structural Interpretation Through Graph Analysis,” in 3rd IEEE Int. Verification Secur. Workshop, 2018. J. Couch, E. Reilly, M. Schuyler, and B. Barrett, “Functional block identification in circuit design recovery,” in 2016 IEEE Int. Symp. Hardware Oriented Secur. Trust (HOST), 2016. N. Albartus, M. Hoffmann, S. Temme, L. Azriel, and C. Paar, “DANA Universal Dataflow Analysis for Gate-Level Netlist Reverse Engineering,” IACR Trans. Cryptogr. Hardware Embedded Syst., 2020. Y. Shi, B. Gwee, Ye Ren, Thet Khaing Phone, and Chan Wai Ting, “Extracting functional modules from flattened gate-level netlist,” in 2012 Int. Symp. Commun. Information Technologies (ISCIT), 2012. T. Meade, S. Zhang, and Y. Jin, “Netlist reverse engineering for high-level functionality reconstruction,” in 21st Asia South Pacific Des. Automat. Conf., 2016. M. Brunner, J. Baehr, and G. Sigl, “Improving on State Register Identification in Sequential Hardware Reverse Engineering,” in 2019 IEEE Int. Symp. Hardware Oriented Secur. Trust (HOST), 2019. H. Gomez, C. Duran, and E. Roa, “Defeating Silicon Reverse Engineering Using a Layout-Level Standard Cell Camouflage,” IEEE Trans. Consum. Electron., 2019. S. Dupuis and M.-L. Flottes, “Logic Locking: A Survey of Proposed Methods and Evaluation Metrics,” J. Electron. Testing, 2019. E. Puschner, T. Moos, S. Becker, C. Kison, A. Moradi, and C. Paar, Red Team vs. Blue Team: A Real-World Hardware Trojan Detection Case Study Across Four Modern CMOS Technology Generations, Cryptology ePrint Archive, Paper 2022/1720, 2022. https : / / eprint.iacr.org/2022/1720. M. Ludwig, A.-C. Bette, B. Lippmann, and G. Sigl, “Counterfeit Detection by Semiconductor Process Technology Inspection,” in 2023 IEEE European Test Symp. (ETS), 2023. K. Vaidyanathan, B. P. Das, E. Sumbul, R. Liu, and L. Pileggi, “Building trusted ICs using split fabrication,” in 2014 IEEE Int. Symp. Hardware-Oriented Secur. Trust (HOST), 2014. G. Klyne and C. Newman, “Date and Time on the Internet: Timestamps,” Tech. Rep., 2002. FIRST.Org, Inc. “Announcing CVSS v4.0. ”https : / / www. first . org/cvss/v4-0/cvss-v40-presentation.pdf. Conceptboard. “Conceptboard. ”https://conceptboard.com/. A. Hepp, M. Ludwig, M. Brunner, J. Baehr, and G. Sigl. “Common Reverse Engineering Scoring System (CRESS) resource page. ”https://purl.org/cress/thetool. H. Mestiri, N. Benhadjyoussef, and M. Machhout, “Fault Attacks Resistant AES Hardware Implementation,” in 2019 IEEE Int. Conf. Des. & Test Integr. Micro & Nano-Syst. (DTS), 2019. T. Sugawara et al., “Reversing Stealthy Dopant-Level Circuits,” in Cryptogr. Hardware Embedded Syst. 2014. FIRST.Org, Inc. “Common Vulnerability Scoring System Version 3.1 Calculator – Result. ”https://www.first.org/cvss/calculator/ 3.1#CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L. FIRST.Org, Inc. “Common Vulnerability Scoring System Version 3.1 Calculator – Result. ”https://www.first.org/cvss/calculator/ 3.1#CVSS:3.1/AV:P/AC:H/PR:H/UI:N/S:U/C:H/I:L/A:L. FIRST.Org, Inc. “Common Vulnerability Scoring System Version 3.1 Calculator – Result. ”https://www.first.org/cvss/calculator/ 3.1#CVSS:3.1/AV:P/AC:H/PR:H/UI:N/S:U/C:H/I:L/A:L. FIRST.Org, Inc. “Common Vulnerability Scoring System Version 3.1 Calculator – Result. ”https://www.first.org/cvss/calculator/ 3.1#CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N. FIRST.Org, Inc. “Common Vulnerability Scoring System Version 3.1 Calculator – Result. ”https://www.first.org/cvss/calculator/ 3.1#CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N. FIRST.Org, Inc. “Common Vulnerability Scoring System Version 3.1 Calculator – Result. ”https://www.first.org/cvss/calculator/ 3.1#CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.
13
[45] [46]
[47] [48]
M. Stevens, E. Bursztein, P. Karpman, A. Albertini, and Y. Markov, “The First Collision for Full SHA-1,” in Advances Cryptology – CRYPTO 2017, J. Katz and H. Shacham, Eds., 2017. F. Courbon, S. Skorobogatov, and C. Woods, “Reverse Engineering Flash EEPROM Memories Using Scanning Electron Microscopy,” in Smart Card Research Advanced Applications, K. Lemke-Rust and M. Tunstall, Eds., 2017. S. E. Quadir et al., “A Survey on Chip to System Reverse Engineering,” J. Emerg. Technol. Comput. Syst., 2016. The MITRE Corporation. “CWE VIEW: Hardware Design. ”https: //cwe.mitre.org/data/definitions/1194.html.