Hardware Security Evaluation Using Assurance Case ...

Hardware Security Evaluation Using Assurance Case Models Henrique Kawakami, Roberto Gallo, Ricardo Dahab, Erick Nascimento University of Campinas, SP, Brazil {ra992911, gallo, rdahab}@ic.unicamp.br, [email protected]

Abstract—The security of computing systems relies heavily on their hardware architecture. Currently, hardware is evaluated using mostly manual processes that are prone to errors, and generate a large, complex workload. In this paper, we are the first to report the use of the Assurance Case methodology to guide a hardware architecture security analysis. We were able to analyze real-world systems, and to detect known and some possibly unknown vulnerabilities. We also show that, by employing Assurance Cases, other benefits are gained, such as better security analysis coverage and better documentation of the security-relevant aspects of the system. Keywords-Hardware security, Assurance Case, security.

I. I NTRODUCTION Hardware plays a major role on the security of virtually any computer system: it needs to behave as commanded by software as well as to provide a computing base that is both flexible and complete, so the overall system may achieve its intended security goals. Without such a secure computing base, it is essentially impossible to achieve a trustworthy system. Various examples of hardware attacks are present in the literature, and some of them can affect a potentially large base of users. The SMM memory attack [1], Xen hypervisor attack[2], and the AMT ”ring -3” attack are interesting attacks that leverage hardware vulnerabilities [3]. As with other types of products, hardware products go through a development life cycle that includes architecture, design and implementation phases. In each phase, security vulnerabilities may arise. Fixing security vulnerabilities during the architecture/design phase is usually much less costly than doing so once its implementation has started. It therefore makes economical sense to evaluate the product from the security standpoint during the architecture phase [4]. In this paper, we focus on the security validation of hardware components/systems while they are being designed, and while their architecture can still be perfected. Hardware Security Evaluation: Current Practice Currently, most security evaluations of hardware architectures are manual and ad-hoc [5]. Evaluators form a mental model of the system by reading the product architecture and design specifications, and by interacting with product architects and designers. Their goal is to extract an abstract model that contains only the security-relevant aspects of the system. Using their expertise on security analysis, they then identify the possible security issues in this abstract

model. The output of this process is usually a list of existing vulnerabilities, or a statement that no issues have been found. The process as described above has a number of limitations: • The extraction of the abstract model is a time-consuming process that is repeated every time an evaluator analyzes a new system; • the requirements on the security evaluators are very demanding, since their knowledge of security and hardware must be comprehensive and deep; • the resulting abstract model is essentially mental and thus not documented, which prevents it from being re-used, shared, or reviewed; • because the evaluation process is largely informal, it is not always clear how complete an evaluation is and, consequently, how secure the target design is. In this work, and to the best of our knowledge, we are the first to employ the Assurance Case methodology to assess hardware security. We show how it can be used to improve various aspects of the design review process, overcoming key limitations of the standard manual review process. This paper is organized as follows: in Section II we present a brief introduction to the Assurance Case methodology. In Section III we describe how the methodology can be used in hardware security analysis, and present a sample case. Section IV presents a few concluding remarks. II. I NTRODUCTION TO A SSURANCE C ASES The Assurance Case framework is a generalization of the Safety Case framework [6], which was created to ensure that mission-critical systems (in aerospace, nuclear power, defense, and other industries) were adequately designed. According to the original definition [7], a Safety Case is: A documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environment. According to Suleiman et al. [8], the major benefits of Safety Cases are: • Making the implicit explicit: – easier to review the arguments, question the evidence and challenge the adequacy of the reasoning presented; – creating greater transparency in the overall assurance process; • aiding communication among stakeholders; • integrating and assessing evidence sources;

Assurance Case should have supporting evidence for all aspects related to the top-most claim. The reasoning that leads to unfolding the top-most claim into sub-claims is called a strategy. In the GSN notation, the strategy can be annotated between a claim and its sub-claim. There is also the concept of justification (for a strategy) that can be also annotated besides the strategy.

Fig. 1.

Assurance Case example.

aiding safety management and governance. Similarly, an Assurance Case is a documented body of evidence that a system holds a given claim. Quoting from NATOs Allied Engineering Publication #67 (AEP-67) [9]: System assurance is the justified confidence that the system functions as intended and is free of exploitable vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system at any time during the life cycle. This ideal of no exploitable vulnerabilities is usually unachievable in practice, so programmes must perform risk management to reduce the probability and impact of vulnerabilities to acceptable levels. The Assurance Case is the enabling mechanism to show that the system will meet its prioritized requirements[. . . ] It is a means to identify all the assurance claims, and from those claims (formally) trace through to their supporting arguments, and from those arguments to the supporting evidence. As the names suggest, Assurance Cases share commonalities with legal cases. They both consist of a group of structured, objective evidence that support a given claim. As with legal cases, the evidence can be compiled into a text document. However, Assurance Cases can also be graphically represented using standardized notations such as GSN (Goal Structuring Notation) [10] or ASCAD [7]. A sample Assurance Case is shown in Figure 1. The claim at the top of the figure is called the top-most claim. It can be supported by other sub-claims or arguments that support it. Arguments, in turn, have to be supported by some type of evidence. Typically, evidence consists of reported measurements, tests or statistical data. Thus, a finished •

III. A SSURANCE C ASES A PPLIED TO H ARDWARE S ECURITY Extensive bibliographic review showed no previous report of usage of the Assurance Case methodology for hardware system security evaluation. Some adoption in the software industry [10][11][12] has been noticed, but not as a widespread practice: software can be very complex and fast evolving, and developing and (often) updating a case tends to be expensive. Moreover, there is usually a strong interdependence among software modules, which would require an Assurance Case to include parts of a diverse range of system software, such as the OS, drivers, etc. And since most software may be patched relatively fast and cheaply, it might be difficult to justify the costs associated with maintaining an Assurance Case for general, non-critical systems. On the other hand, hardware problems are generally difficult and expensive to patch. In fact, hardware functionality validation is a very rigorous process that can be as rigorous as the safety analysis of critical systems, such as aircraft and life support systems. Thus, we believe that hardware systems share more commonalities with the rigour of safety cases than that of software testing. In addition to being less complex than software, hardware is easier to modularize. In fact, most hardware is designed and separated in modules that are physically isolated, with a well defined inter-communication interface: i.e., there is no way for a subverted module to bypass its communication interface and subvert another module that is physically separate. Hence, unlike software components, these modules can be analyzed separately. Thus, in our view, hardware is a natural candidate for Assurance Case security evaluation. Table I briefly compares the characteristics of safety systems with those of hardware and software systems. In the next sections we demonstrate how the methodology can be applied to security analysis during the architecture review phase of hardware products. Section III-A presents an example of the Assurance Case methodology applied to the analysis of a real-world system. Section III-B introduces the concept of Assurance Case Patterns, and Sections III-C and III-D list the perceived benefits and challenges of the methodology. A. Example of an Assurance Case applied to hardware - SMM In this example we show how Assurance Cases can be used in a real-world architecture analysis. The case was built using the D-Case editor [13], which is an Eclipse-based tool to build dependability cases using GSN (Goal Structuring Notation). D-Case has evolved to support argument patterns and integration with other dependability analysis tools, but for this case we are using it to develop a security-related case using GSN.

Adversary Complexity Locality Cost of patches

Software security The adversary applies a set of coordinated actions to attack the system. Highest (e.g. MS Word has more than 3M lines of code) Low Lower

Hardware security The adversary applies a set of coordinated actions to attack the system Higher (e.g. LEON3 SoC has 600k lines of code) Medium Higher

Mechanical systems (safety) System is stressed in an uncoordinated way. High High Higher

TABLE I C OMPARISON OF SOFTWARE , HARDWARE , AND SAFETY SYSTEMS .

We analyzed the System Management Mode (SMM) subsystem of the Intel CPU architecture, from the point of view of an architecture review analyst. SMM is the system management mode of most modern Intel CPUs. It allows the computer’s BIOS to control system variables such as fan speed control, independently from the operating system. For this reason, SMM code runs at a higher privilege than the OS itself. This architecture was chosen because it is relatively simple and had two known vulnerabilities [14]. The target architecture refers to the first-generation Intel Core processor with the Q35 chipset, which can be considered obsolete but is still valid for this exercise. The first known vulnerability is that the CPU only restricts SMM memory access from external memory read/write operations. Still, once inside the CPU cache, the SMM code could be overwritten, effectively bypassing the restriction mechanism [1]. The second vulnerability is that the memory which stores the SMM code had its access restricted by the CPU. However, the external chipset was able to remap that memory to a unrestricted address, overriding the CPU protection mechanism [15]. In order to facilitate the readability and explanation, the analysis was divided into four distinct steps that are shown in Figures 2 to 5. Note that the D-Case editor already inserts a unique identifier to each element (e.g. “G1 ”), so that it may be later referenced in a textual version of the case, or used by other tools. We already had previous knowledge of the SMM system, and it took approximately 20 hours to build this case, using 483 pages of architecture documentation. Most of the effort was spent in the search for specific information in the architecture manuals, but we consider that the time was used in an efficient way; instead of browsing through the manuals searching for possible vulnerabilities (as in the standard manual analysis process), we had a clear goal of searching for evidence to support our case. SMM Assurance Case - Step 1 (Figure 2). The analysis process starts by stating the global desired system security property that we are interested to assure. In our case, it is the security of the SMM system: we want to assure that malicious code cannot run with SMM privileges. This is stated in goal G1 . It is important to note that this goal is described with a negative sentence. This is due to the nature of the security assurance problem: since there are many ways in which an attacker may try to compromise the system, we have to

systematically list and analyze each of these potential ways. This is different from standard requirement specifications, where most features are listed as positive sentences (e.g. “The SMM system must control fan speed”). The topmost goal is then supported by two sub-goals, where one of them, G3 , is not developed in our case. This means that we do not have evidence to support it. In this case, the responsible party for this specific goal would be the BIOS vendor. This undeveloped goal would be useful for communicating to all BIOS vendors what is expected from the BIOS code in order to guarantee the SMM system security. SMM Assurance Case - Step 2 (Figure 3). In this step we expand goal G2 from the previous step. Two sub-goals are derived, G4 and G7 . G4 is developed into G5 , which is itself developed into G6 . While it would be possible to state a single goal that would encompass G4 , G5 , and G6 , we prefer to keep them separate, so that their relationship is explicit. This makes it easier for a reviewer to detect possible inconsistencies or wrong assumptions. Goal G6 is supported by our first evidence, E1 , which is, in our example, a fictional check that our system correctly disable interrupts in a certain way that is required by the architecture reference manual. In a real-world scenario, this evidence could be linked to the associated interrupt-disabling code, and to the architecture manual paragraphs that state this need. In such a way, it becomes explicit that a possible SMM vulnerability may arise if that code is eventually disabled for some reason. The other sub-goal from G2 , G7 , is developed into G8 , followed by a strategy box S1 . The strategy does not state a goal by itself, but only states the strategy that was used to develop the following sub-goals in step 3. Justification J1 is a note that makes explicit why goal G8 was developed in a specific way. SMM Assurance Case - Step 3 (Figure 4). In step 3, we show how strategy S1 was used to derive sub-goals from goal G8 . In this step, we ran into a series of undeveloped goals that are directly related to possible vulnerabilities of the hardware architecture. For U2 , U3 , and U4 , we did not have the necessary documentation to provide an evidence. Thus, they can be considered as possible unknown vulnerabilities that affect this system. Since uncovering new vulnerabilities was not the primary objective of this work, they were not further investigated. For the undeveloped claim U5 , there is a known attack that overwrites the SMM code after it is cached inside the processor [1]. This is the first vulnerability that we were able to detect during the case’s development. SMM Assurance Case - Step 4 (Figure 5). Step 4

Goal:G_1 Malicious code can not be executed with SMM privileges.

Goal:G_3

Goal:G_2

Malicious code can not be inserted into BIOS.

The only code that executes with SMM privileges is the code loaded into SMRAM by the BIOS during boot.

Undeveloped:U_1

Fig. 2.

SMRAM Assurance Case - step 1.

Goal:G_2 The only code that executes with SMM privileges is the code loaded into SMRAM by the BIOS during boot.

Goal:G_4

Goal:G_7

Non-SMM code can not be executed with SMM privileges.

The CPU executes the SMM code loaded by BIOS with SMM privilege.

Goal:G_5

Justification:J_1

Non-SMM code cannot be executed while CPU is in SMM mode.

Code always is executed from cache memory.

Goal:G_8 SMM code that is fetched and executed from the CPU cache can not be modified before or during execution.

Goal:G_6 Strategy:S_1

Interrupt handling code can not be executed with SMM privileges while CPU is in SMM mode.

List all memory locations where SMM code could be stored and modified before being fetched.

Evidence:E_1 Interrupts are disabled and NMI are treated as instructed by the architecture manual.

Fig. 3.

SMRAM Assurance Case - step 2.

continues the analysis of goal G18 from step 3, and ultimately results in the undeveloped claim U6 . This claim refers to the vulnerability that is described in [15], which is the memory remapping mechanism exploit to overwrite SMM code. Thus, we found the second known vulnerability that affected the SMM subsystem.

similar to templates that can be used to provide guidance and speed up the process of building Assurance Cases. Ideally, these patterns should be created by experts, and then be used by less experienced analysts to build more solid Assurance Cases. There is already support for creating and applying argument patterns in some of the available tools [16][17].

B. Use of Assurance Case Argument Patterns

As an example, we extracted an argument pattern from strategies that were used in the presented SMM and ME assurance cases. The pattern in Figure 6 states necessary conditions to guarantee that a certain memory location cannot be overwritten. It could be used to inform the security analyst some important details that have to be taken into account. For instance, in our example it is critical to know that memory contents can also be stored and modified in the cache memory without necessarily being modified in the external memory. This information is embedded in the argument pattern, and

There are two important issues with Assurance Cases. The first is that it is very important to use the right strategies to develop the top level claim. An inexperienced analyst could miss important points during the case development, and end with an incomplete analysis. The other issue is that the case development tends to be a very time-consuming task, specially when the strategies have to be created from scratch. To alleviate these two problems, we resort to the concept of Assurance Case argument patterns. Patterns are constructions

Strategy:S_1 List all memory locations where SMM code could be stored and modified before being fetched.

Goal:G_9

Goal:G_10

External memory locations from where SMRAM code is fetched can not be modified.

SMM code in cache can not be modified and then executed with SMM privileges.

Strategy:S_2

Undeveloped:U_5

List all devices that can write to memory.

Goal:G_11

Goal:G_12

Main CPU can not write to SMRAM memory.

Goal:G_13

Chipset DMA controller (DMAC) cannot execute transfers to SMRAM memory.

Goal:G_18 Chipset blocks access to SMRAM address range.

PCI bus-mastering devices cannot write to SMRAM memory.

Undeveloped:U_2

Undeveloped:U_3

Fig. 4.

Goal:G_14 Northbridge Management Engine microcontroller cannot write to SMRAM memory.

Undeveloped:U_4

SMRAM Assurance Case - step 3.

Goal:G_18 Chipset blocks access to SMRAM address range.

Goal:G_19 Other memory regions cannot be remapped to SMRAM memory.

Goal:G_20

Goal:G_21

SMRAM address range is correctly configured by BIOS.

Evidence:E_3

Undeveloped:U_6

SMRAM address is correctly configured by BIOS.

Fig. 5.

SMRAM address range cannot be modified.

Evidence:E_4 D_LCK bit locks SMRAM address and is correctly set by BIOS before boot.

SMRAM Assurance Case - step 4.

would be useful for analysis of similar systems. C. Lessons Learned: Benefits From our exercise with hardware security Assurance Cases, we can list various perceived benefits. Documentation. The Assurance Case methodology product is, by itself, a well documented security analysis. It can be later reused, shared, and reviewed by peers. Completeness indication. One of the problems with the manual analysis of hardware architectures is that it is not always clear when the analysis process is finished, or when it should be stopped. This is the opposite of what happens when the design is tested for functionality, where there are

testbenches and code coverage analysis to ensure that a sufficient amount of testing is done. When applied to hardware architecture analysis, the Assurance Case methodology can provide the analyst with indications of the completeness of the security analysis. The presence of unsupported claims is a clear indication of a still unfinished analysis, and the amount of well documented evidence can give a measure of confidence in the analysis process. Test cases. Because Assurance Cases require clearly statement of (sub)claims, it can be used to find useful test cases for security aspects of the design. These tests can be incorporated into the standard functionality testing, and be used as evidence to support the mentioned (sub)claims.

Goal:G_1 X code that is fetched and executed from Y cannot be modified prior or during execution

Strategy:S_1 List all memory locations and include memory remap if applicable; list cache memory

Goal:G_2

Goal:G_3

(all external memory locations) from where X code is fetched or executed cannot be modified

Fig. 6.

X code in cache cannot me modified and then executed with Z privileges

Assurance Case pattern for memory protection.

Source code monitoring. One benefit of the Assurance Case for hardware security analysis is that it can be used to map which portions of the documentation or source code are critical for the design of security objectives. These portions of code could then be monitored for intentional or unintentional modifications. Hardware documentation. As an example, in the PC architecture there are some registers (e.g. SMM registers) that have to be correctly configured by BIOS vendors before execution control is passed to the operating system. While searching for evidence to support a given claim, the security analyst will eventually find which are the security relevant aspects of the configuration process, and these can be made explicit to the BIOS developer, for instance. D. Lessons Learned: Challenges Sub-claim strategies. The strategies that are used to unfold top claims are the most critical aspect of the methodology. If an improper strategy is applied, the case will eventually be incomplete or flawed. Over time, good strategies can eventually be re-used and converted into patterns, so that less experienced security analysts can leverage from past experiences. Tools. Although there are both free and commercially available software tools to develop Assurance Cases, they are not designed for hardware security analysis. They are, instead, optimized for safety cases, assurance cases, or dependability cases. A hardware security tool could provide features to leverage some of the mentioned potential benefits, such as a link between test case, code, and architecture manual. IV. C ONCLUSION The Assurance Case is an emerging methodology for dependability and security analysis of critical systems. Although it has not been widely adopted for use in software analysis, we believe that it has a potential use for hardware security analysis.

We were able to build Assurance Cases for real-world hardware architectures, and in our example we showed how two known vulnerabilities could be detected during the analysis process. We also found other possible unknown vulnerabilities that may affect the same subsystem. We did not further investigate whether the latter are real vulnerabilities, since we would need to implement a proof of concept of an attack, which is not the focus of this work. Besides allowing a deep analysis of the target architecture, there were also the benefits of guiding the analysis process and providing documentation that can be shared and peerreviewed, which are two major drawbacks of the standard security evaluation process. ACKNOWLEDGMENT This research was partially supported by a research grant from Intel Corporation. The authors would like to thank David Ott and Hao-chi Wong for the several fruitful discussions that contributed to the ideas and methods described in this work. R EFERENCES [1] R. Wojtczuk and J. Rutkowska, “Attacking smm memory via intel cpu cache poisoning,” Invisible Things Lab, 2009. [2] J. Rutkowska and R. Wojtczuk, “Preventing and detecting xen hypervisor subversions,” Blackhat Briefings USA, 2008. [3] A. Tereshkin and R. Wojtczuk, “Introducing ring -3 rootkits,” in Blackhat USA, 2009. [4] M. L. King, “Practical security validation,” in Microprocessor Test and Verification (MTV), 2013 14th International Workshop on, pp. 35–38, IEEE, 2013. [5] N. Potlapally, “Hardware security in practice: Challenges and opportunities,” in Hardware-Oriented Security and Trust (HOST), 2011 IEEE International Symposium on, pp. 93–98, IEEE, 2011. [6] T. S. Ankrum and A. H. Kromholz, “Structured assurance cases: Three common standards,” in High-Assurance Systems Engineering, 2005. HASE 2005. Ninth IEEE International Symposium on, pp. 99–108, IEEE, 2005. [7] R. Bloomfield, P. Bishop, C. Jones, and P. Froome, “Ascad adelard safety case development manual,” 1998. [8] A. S. Ewen Denney, Ganesh Pai, “Advocate: An assurance case automation toolset (tool demonstration),” ICSE, 2013. http://ti.arc.nasa.gov/m/profile/edenney/papers/sassur2012.pdf. [9] NATO, “Nato aep-67 - engineering for system assurance nato in programmes.” nsa.nato.int/nsa/zpublic/ap/aep-67. [10] T. Kelly and R. Weaver, “The goal structuring notation–a safety argument notation,” in Proceedings of the dependable systems and networks 2004 workshop on assurance cases, Citeseer, 2004. [11] T. Rhodes, F. Boland, E. Fong, and M. Kass, “Software assurance using structured assurance case models,” Journal of Research of the NIST, vol. 115, no. 3, p. 209, 2010. [12] C. B. Weinstock and J. B. Goodenough, “Towards an assurance case practice for medical devices,” tech. rep., DTIC Document, 2009. [13] Y. Matsuno, “D-case editor: A typed assurance case editor,” University of Tokyo, 2011. [14] L. Duflot, O. Levillain, B. Morin, and O. Grumelard, “Getting into the smram: Smm reloaded,” CanSecWest, Vancouver, Canada, 2009. [15] J. Rutkowska, “A quest to the core,” 2009. [16] Y. Matsuno, H. Takamura, and Y. Ishikawa, “A dependability case editor with pattern library,” in High-Assurance Systems Engineering (HASE), 2010 IEEE 12th International Symposium on, pp. 170–171, IEEE, 2010. [17] Y. M. Shuichiro Yamamoto, “An evaluation of argument patterns to reduce pitfalls of applying assurance case,” ICSE, 2013.