|
|
|
|
|
|
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
IP Security Assurance StandardSeptember 4, 2019 Authors Brent Sherman, Intel Corporation Abstract A System on Chip (SoC) or Application Specific Integrated Circuit (ASIC) is comprised of multiple components referred to as Intellectual Property (IP) blocks or just IP. These blocks come from multiple sources such as internal development teams, IP suppliers, tool-generated IP, etc. Typically, the SoC/ASIC owner integrates multiple IPs from multiple sources, which raises concerns about security risk. How much risk is the Silicon owner (i.e., Integrator) inheriting? What potential security concerns exist that the Integrator must address to ensure the security objectives of the SoC/ASIC are upheld? This paper introduces an emerging new standard called IP Security Assurance (IPSA) to address these concerns in a manner that is low-overhead, non-disruptive, and scalable across IP families. The standard specifies an approach to highlight IP assets and associated entries in the Common IP Security Concerns Enumeration (CIPSCE) knowledge base for the mitigation implementer to address. Introduction This paper is Accellera’s initial proposal to address the industry’s security concerns involving IP integration. Since Integrators typically treat IP as a “black box”, vulnerabilities may inadvertently be inserted into an SoC/ASIC. To highlight this, a study was performed [1] showing what could happen in this scenario; a real-case example [2] was discovered in 2018. Table 1 shows the goals and corresponding methods of the IPSA standard. The stakeholders of the standard are Electronic Design Automation (EDA) vendors, IP suppliers, and IP Integrators. The standard also assumes the relationships between the stakeholders are trusted and there are no malicious actors. The standard does not address security concerns in the supply-chain flow between the stakeholders.
Table 1. IPSA Standard Goals and Methods The IPSA standard defines a specification that addresses security concerns for hardware IP and its associated components when integrated into a Silicon product. With the standard, IP vendors will be able to identify security concerns to either 1) mitigate themselves, or 2) acknowledge for the SoC/ASIC owner to address at the integration level. The standard is also defined outside of the IP definition. This maximizes flexibility by removing dependencies on existing standards, provides scalability for future capabilities, and allows applicability to existing or legacy designs. This paper includes some ubiquitous terms that may have different definitions outside of the paper. When referenced, therefore, these terms have the following definitions:
It is important to note that the goal of this paper is to solicit feedback from the greater industry that is outside of the Accellera IPSA Working Group. Attributes, their associated fields, and definitions described here may be changed or appended in the initial release of IPSA standard. This paper is sectioned in the following manner:
Methodology The IPSA standard introduces new components to add to an IP’s delivery collateral: 1) Asset Definition, 2) Attack Surface, and 3) Threat model informed by the CIPSCE knowledge base. The additions are highlighted in the conceptual workflow shown in Figure 1.
Figure 1. Conceptual Workflow The workflow shows an addition (i.e., the asset definition defined by the IPSA standard) to the IP definition, which is formed today from existing standards such as SystemVerilog, Verilog, VHDL, SystemRDL, etc. The IPSA standard identifies assets within the IP and by using qualifying attributes produces an attack surface over which to perform a security analysis. This security analysis process may be manual or may be augmented through the use of a generation tool (e.g., EDA tool). Similarly, security concerns to highlight for the Integrator may be extracted manually or using a generation tool. The CIPSCE database provides a standard nomenclature and cataloging of common security concerns to help simplify and classify the applicable weaknesses. The IPSA standard defines the relationship between the asset and CIPSCE database with an attribute association [A] as shown in Figure 2. In the following sections, the attributes that pertain to associations are in bold italic text.
Figure 2. IPSA Attribute Association Until the tools become available to help consume and digest the IPSA collateral, it is recommended to use a “divide and conquer” approach when applying the methodology to large or complex designs. The rationale is that for large and complex designs (e.g., processors, controllers, etc.), the collateral produced can be difficult for human comprehension. With “divide and conquer,” complex IP can be broken down into basic blocks that are easier to analyze and verify. This approach aligns with other methodologies such as formal verification, functional modeling, etc. The use case example OR1200 (CPU) in the OpenCores Examples section shows how this approach is applied to a complex IP. IPSA – Asset Attributes An asset can be identified as a port, module, register, combination, and so on that is part of the design that the IP Developer deems important for the SoC/ASIC owner to consider during integration. Selecting the appropriate asset is a critical step in using the IPSA standard since this is a fundamental building block of the standard. The paper in [1] provides more information, along with examples, about how to identify assets within an IP. Once an asset is identified, its definition is comprised of the attributes defined in Table 2. Each asset will have its own asset attribute table. These attributes are to be provided by the IP Developer. The standard does not define which fields are inputs or outputs to be used by a tool for auto-generation.
Table 2. Asset Attributes IPSA – CIPSCE Attributes The CIPSCE knowledge base is an enumeration of security concerns or weaknesses that are associated with a particular IP family or functionality. The attributes of the entries are similar to [3] except with some modifications to address specific IP characteristics. The goal is to have Accellera host a public database that will support field queries and downloads for scalability. The content will be controlled by Accellera, but the greater community can contribute to the database by submitting entries to the IPSA Working Group for review and approval. This process is currently not defined; however the idea is to allow any contributor (i.e., commercial, researcher, government, etc.) to share knowledge in order to improve the security robustness of products. The attributes for each entry in the database are listed in Table 3.
Table 3. CIPSCE Attributes IPSA – Conceptual Workflow Figure 1 shows the conceptual workflow, however it lacks the details of how the standard can be applied. Below are the steps showing the roles of each stakeholder and the actions to be taken. 1. EDA Vendor:
2. IP Developer:
3. IP Integrator:
The workflow described implies that EDA tools provided by different vendors produce equivalent results. In practice, this may not be the case. Creation of a compliance test suite to verify that different tools produce comparable results is outside the scope of this standard. CIPSCE Knowledge Base At the time of this paper, content in the CIPSCE knowledge base does not exist. However, it is worth listing the topics the knowledge base may address. Table 4 shows a list of potential security concerns. This list is expected to be dynamic.
Table 4. CIPSCE Topics OpenCores Examples To illustrate how the workflow and methodology apply to real IPs, two modules were selected from the OpenCores library: 1) Computer Operating Properly [4] and 2) OR1200, which is part of the Minisoc [5]. These blocks were chosen because of their contrast in complexity and functionality which demonstrates the agnostic applicability of the standard. At the time of this paper, the CIPSCE database was just being created, so the entries associated with the assets are minimal. In a mature state there would be more entries associated. Regardless, the value remains and should not diminish the conceptual workflow. Computer Operating Properly (COP) This module is basically a watchdog timer that triggers a system reset if not regularly serviced. The block diagram is shown in Figure 3. One can easily argue that the “Watchdog Counter” block is critical to proper functionality since if it was to be controlled by an adversary that has put the system in a compromised state, a timeout (i.e., cop_rst_o) would never assert.
Figure 3. COP Block Diagram Inside the counter block (cop_count.v), the register cop_counter holds the timeout value of the watchdog. This is what an adversary would want to control, thus making it an asset. The values for the IPSA asset table are shown in Table 5. It is also important to call out the expression in the “Condition” attribute. The COP has a write protect feature that prevents the counter from being disabled or reconfigured. Once the cwp bit is asserted, this ensures that the “Availability” security objective is upheld. This would be one of the conditions to verify during the integration phase of the IP. The COP has several conditions that should be accounted for in the asset table; for simplicity, only the write protect is highlighted. It is recommended that conditions that support different security objectives be separated into their own asset table.
Table 5. COP Counter Asset Values Once the asset table is complete, the IP Developer uses an EDA tool to produce the attack surface and CIPSCE entries associated to the IP family and functionality. This can be done manually if no such tool is available. For the COP, this is shown in Table 6.
Table 6. COP Counter Asset with Attack Surface Defined Part of the attack surface is obvious to an Integrator (e.g., clock, reset, Wishbone bus), however what is interesting are the non-standard signals that can influence the counter (e.g., stop_mode_i, debug_mode_i, etc.). Furthermore, since availability is one of the security objectives, the cop_rst_o output should not be gated by an untrusted agent. These concerns should be called out as security concerns for the Integrator to consider. This can be done by manually adding to the “CIPSCE References” attribute if the EDA tool didn’t make that association. Additionally, the IP Developer can use the “Additional Security Concerns” attribute to provide even more guidance. The CIPSCE references listed in Table 6 are just examples because the database was not active at the time of the paper. However, to illustrate how such entries may look, Table 7 shows associated CIPSCE entries that would be applicable.
Table 7. CIPSCEs for COP OR1200 (CPU) The Minisoc contains a RISC core named OpenRISC 1200 (OR1200). Below is a brief description about the core taken from the “OpenRISC 1200 IP Core” documentation.
There are many assets in this IP, however for purposes of this paper only one will be shown as an example. From the documentation, Figure 4 shows the block-level architecture for the core. Critical to the IP is performing proper data translations in the DMMU to ensure access protections are upheld. This is implemented in the Verilog module or1200_dmmu_tlb. The concern would be if an adversary could influence or alter its behavior then maybe the adversary could extract sensitive data without the associated permission (i.e., privilege escalation). The point of this example is not to conduct a security review of the architecture or design, but to highlight how the IPSA standard can be used to identify potential vulnerabilities that can compromise an asset.
Figure 4. OR1200 Core Architecture The asset table for the DMMU TLB is listed in Table 8. Once the asset table is complete, the IP Developer uses an EDA tool to produce the attack surface and the associated CIPSCE entries to the IP family and functionality. The attack surface for the DMMU TLB is shown in Table 9.
Table 8. OR1200 DMMU TLB Asset Values
Table 9. Complete Asset Values for DMMU TLB Just like the COP example, the attack surface in the DMMU TLB asset table quickly shows there are debug signals (i.e., “dbg”) that can influence the translation. Debug signals are always a concern when it pertains to security. In this case, since it was not specifically called out in the “Family” attribute, a tool probably would not associate such CIPSCE entries to the asset table. However, an Integrator would be able to easily recognize that these are debug signals and therefore manually scan the CIPSCE database for such associations. Summary and Outlook This paper has demonstrated how the emerging IPSA standard can be used to minimize risk when integrating IP into an SoC/ASIC. It has provided a methodology that identifies an attack surface to an asset within an IP and associates potential security concerns (i.e., CIPSCE). The methodology also provides the hooks for tools to auto-generate and auto-verify parts of the collateral. There are still some areas that need more attention before a complete standard can be released. One of these is that the data format of IPSA attributes needs to be defined. The data format needs to be both human- and machine-readable. Currently the IPSA Working Group is favoring an XML schema, however it has not determined how that schema would look. Since there are not many attributes defined in the IPSA standard, a bare minimum XML schema would probably be sufficient. Anything more may be considered overhead and add unnecessary complexity. Another area that needs more focus is the CIPSCE database. How this knowledge base will be presented, queried, and maintained is still under discussion. In addition, there are security concerns that need to be taken into consideration when supporting a database with public access. The working group is currently working with Accellera to see what resources are required to replicate something similar to [3]. References [1] Sherman, B., Borza, M., Rosenberg, B. et al. J Hardw Syst Secur (2017) 1: 38. https://doi.org/10.1007/s41635-017-0002-5 [2] Severe Security Advisory on AMD Processors, https://safefirmware.com/amdflaws_whitepaper.pdf [3] Common Weakness Enumeration, CWE List Version 3.3, https://cwe.mitre.org/data/index.html [4] OpenCores. COP. Retrieved fromhttp://opencores.org/websvn,listing?repname=cop&path=%2Fcop%2F&rev=0 [5] OpenCores. Minisoc. Retrieved from https://opencores.org/projects/minsoc [6] FIPS 199: Standards for Security Categorization of Federal Information and Information Systems, NIST, 2004, https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf Footnotes [A] The attribute association is inherently flawed since by definition the standard is meant to grow (e.g., as new threats are discovered). This means some associations will be missed or overlooked due to new values being added to the association. The IPSA Working Group is looking for feedback/solutions to help resolve this. [B] Case-sensitivity may be dependent on the language of the RTL source. To provide feedback or have questions? Visit the Community Forum |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
Home | Feedback | Register | Site Map |
|
|
|
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |
