Do You Trust Your IP Supplier?

How much do you trust your IP supplier, regardless of whether IP was developed in-house or by a third-party provider? And what implications does it have a system integrator?

These are important questions that many companies are beginning to ask. Today, there are few methods, other than documentation, that provide the necessary information. The software industry may be ahead of the hardware industry, but Accellera is attempting to leverage that work and extend it into the hardware world. The EDA industry is looking at how they can provide analysis and mitigation, making the process more robust.

At the recent DVCon, Accellera provided a workshop to explain what they have been doing. Mike Borza, principal security technologist for Synopsys, Ambar Sarkar, platform architect at NVIDIA, and Adam Sherer, verification account executive at Cadence, were the presenters. Brent Sherman, security consultant at Intel also contributed to the material, but was unable to be at the conference due to COVID-19 concerns.

What follows is a condensation of the presentation material.

The number of reported incidences as captured by the CVE database — a software and systems database of security issues or attacks — have skyrocketed over the past few years. The cyber crime economy is flourishing. Inexpensive hacking toolkits have appeared on the market and these involve both hardware and software. Prices range from $1 to $200, but probably should say zero dollars because there are a huge number of open source software hacking toolkits that are used for both white-hat and black-hat hacking.

Part of the problem comes from everything being connected. There are multiple dependencies and assumptions built into this, both functional and assurance types of concerns. Breaking the chain in one place causes it all to fall apart. There is increasing demand for IP reuse and this leads to different kinds of security concerns. There is more complexity and with more complexity comes an increase risk that something is not secure and with the increased risk comes the hard probability that you may see attacks. Reuse means increased exposure.

This is why Accellera founded the IP Security Assurance (IPSA) Workgroup in October 2018 with 61 members representing 21 companies. The scope was to look at security concerns when integrating hardware IP into embedded systems. The group wants to define completeness, accuracy, and overall quality of a supplier’s security assurance collateral. The approach is to look at known security concerns that have been identified either by industry or security researchers, then to disseminate information about the attacks that have been successfully exploited. Knowing the common vulnerabilities means they can adopt ways to mitigate that and spread the knowledge around so that collectively, as an industry, more secure products can be made.

Accellera presented a white paper last September that detailed the approach being taken. It talks about the methodology, the known concerns and weaknesses, such that related IP should know about them, and then it shows an open source example. Since then, Accelera has been updating the document based on feedback.

The goal is to create a standard way to express security aspects of an IP and capture that in a way that the IP integrator and EDA tools can take advantage of it.

Figure 1 shows the overall methodology and the part the working group is defining.

Fig. 1: Workflow of the IP Security Assurance strawman. Source: Accellera

Along with an IP there should be a document that defines things that need protection. These are defined to be assets, and that becomes part of the IP definition. Then, an EDA tool can look at the asset definition in the IP and, separately, consult a database of known security concerns associated with this type of IP. The tools analyses the IP and known weaknesses for the class of IP, and identifies the IO ports that could be used to exploit that weakness in that IP. The document provides one example where a register needs to be protected because it may allow run status to be elevated. The EDA tool can find the ways in which that register could be attacked and in addition to the expected access method, may identify additional paths, such as through a debug port, or other control lines. Note, that these EDA tools do not exist today, but vendors are working on them.

It is also worth noting that this standard is looking at functionality in the traditional sense. In theory, power lines or electromagnetic radiation could also be thought of as ports through which a vulnerability could be exploited. Power analysis attacks are becoming more prevalent and other kinds of energy emanation attacks and becoming more sophisticated, such as timing attacks. But it is difficult to capture that information in a way that can be systematically tested during functional verification. They are not aware of good tools to analyze this kind of vulnerability and thus are not tackling that problem today.
Security objectives could involve confidentiality, integrity and availability. These can be defined as:

• Confidentiality: Ensure only authorized information disclosure.
• Integrity: Ensure only authorized information modification or destruction.
• Availability: Ensure information is available when needed.

There may be situations where a security concern creates a safety violation or safety risk and those need to be taken into account as you build safety mechanisms. Conversely, if you build safety mechanisms and safety response systems, those can open up attack surfaces that may have a potential security risk down the road.

In the future, an IP should be shipped with a definition of the ports and the attack surface. It may define the attack surface for confidentiality which may not be the same as the attack surface for integrity. The IP provider will provide a list, based on the known security concerns that affect that IP and that IP family, along with the ports that could be used to create an attack surface, and the details about the attack surface such as the conditions that affect it.

It is not necessarily the case that all IP will protect against all scenarios, nor should they. That may not be part of the objectives for the IP. Imagine some registers in a system where the trust model for the system as a whole is secure. Those registers can be accessible to anything that is able to talk to them. In other scenarios, the registers should be access controlled, so only certain trusted entities are allowed to talk to those registers or read those registers. It is appropriate for IP that does not have that concern, not to be burdened by the extra gates or area and power consumption that comes along with providing the necessary access control.

Not all IP will be expected to conform to identical security objectives, but it is important to be able to elucidate those. There also will be things in any IP provider’s filing about any particular product that is unsafe. This does not mean that they are vulnerable, but it does mean they do not know or have not thought of what the exposure to a particular risk is. One needs to do some analysis to figure that out. Still, at least it becomes obvious when you have a list of things that they did try to mitigate. Then there are the things that they didn’t think of, or say anything about. Those represent unknown risk.

The industry has already been working on databases for weaknesses. One example is the Common Weakness Enumeration (CWE) from Mitre, which is mainly focused on software. Recently, some of the hardware-oriented issues have been added to the database and that work is ongoing. In Feb 2020, CWE 4.0 was released that had more than 800 software weaknesses, and for the first time it included 31 hardware weaknesses.

The EDA industry also has to make some changes in other areas to address security. For example, when you integrate and synthesize IP, some constructs in the IP related to security could well be optimized away by synthesis, making the IP security change in unexpected ways. Directives are required to tell the synthesis tools to maintain the security. The same is true for safety where redundancy is used. This is a symptom of how engineers have been trained to think about logic design, which is that everything that is not an explicit functional requirement that is traceable to some input requirement is the subject for optimization. We are learning about how to try and prevent tools from being overly zealous in that optimization.

Capturing security concerns knowledge
Accellera is developing the standard for IP providers to communicate with IP consumers about the security aspects of their products. This not only makes them aware of the problems, but also could be used in the IP selection process. When the work started there wasn’t a readily available catalog of known concerns that pertained to hardware, so they created a sub-group to look into that. Their work forms the Common IP Security Concerns Enumeration (CIPSCE), and they continue to talk with CWE about ways in which the work can be done in cooperation. If they do not merge, they have looked for the minimal possible subset of information that needed to be common between the CWE and the CIPSCE database to make them interoperable.

CWE is used as input to software design teams and programmers so they can look for patterns of attack — or patterns that repeat and lead to attacks — and try to avoid those. When an attack is identified, it is documented along with the nature of that attack, what it is traceable to, and this is tied back to the CWE saying that this is fundamentally a violation of these things and what the people should have done.

In the hardware world, individual IP vendors and individual integrators maintain databases of things they have found in their own products. Considering the nature of hardware, compared to the length of time it takes for well-known attacks to be beaten out of the software ecosystem, it is far worse in hardware because you will have products that live for 5 or 10 years. They need to continue to operate in an environment in which there are active threats. Making the knowledge widely available is far more problematic in hardware than in software.

An important attribute in the database is the family attribute that can be attached to a concern. It may indicate that this family of IP tends to see repeated exploitation of defects of this type, and so these are the things to watch for. Using that family value in the IP description, the product description, and then in the weakness enumeration, it is possible to connect these two things. It is simplistic to say that a single family captures the issues for all possible weakness and for all possible IPs, so it allows for a particular entity to have multiple family members ascribed to it. There are 16 on the list right now.

Once the family is defined, it allows things to be related. This leads to the question of what information needs to be captured in order to produce something that is fairly complete and useful to someone trying to analyze security properties of their products. General items include:

• Reference Identifier – a unique identifier to refer to an entry.
• Version identifier – if a source allows multiple versions of a piece of knowledge, it should have an identifier for a specific version.
• Title – a descriptive name that helps to find items of interest.
• Description – a detailed overview of the specific security concern.
• Relationship – reference(s) to related security concern(s), such as the RefID of another concern.
• Examples – descriptive examples that can help others understand a concern.

Mitigation is important. It is not unreasonable for IP products to leave particular concerns unmitigated. These are the communications aspects of this standard, which state what issues are not being mitigated. A lot of times it is more important to handle a security concern or the mitigation of it at the system level or higher, thereby closing off a whole family of related, unmitigated weaknesses in a single solution.

Best practices
The industry needs to define best practices. When coding the IPSA tables, they should be both human- and machine-readable. People need to be able to examine descriptions of the attack surfaces, the assets associated and the elements contained in the tables, but certain aspects can be automated. The committee is looking at doing this in JSON rather than IP-XACT, because even though IP-XACT is clear source, it is not easily readable by humans.

The recommendation is that two engineers should code the tables, providing a check and balance. In a positive way, Engineer A can look over Engineer B’s shoulder. They may have different perspectives and possibly even different disciplines, such as design and verification. There is also the implication that if one of the individuals happens to be less than trustworthy, there is a second set of eyes. A single individual who may be compromised in some way could provide a description that is itself compromised.

What tools will be developed remains unclear. Formal techniques should be used wherever possible. Identifying attack surfaces from assets is a made for formal application. Searching for unexpected assets is a way of identifying a Trojan intrusion. Document traceability should be part of any development environment using formal engines to read it, and then gathering coverage and building a model of what you have verified.

This raises question about IP encryption. If you encrypt the IP and the tables, you could lock down the interfaces. There are some advantages in that. It limits the integrator’s ability to circumvent your APIs. You define the way in which the IP should work and you have built verification for that IP, so you expect the integrator to follow those rules. You may need to provide a lot more data to substantiate the work that you have done, though. If you provide clear source, there is the risk that the integrator modifies something, and that could have unintended consequences.

IP providers basically would be creating a security manual for their IP. It potentially can define the usage for APIs, such as the debug interface that describes how it needs to be turned off or cauterized when you integrate it into a system.

Security does not stop when silicon leaves the building, either. If bugs are identified in an IP, you need to provide that information to the integrator. They need to know the impact in their system. These things are generally true where safety is an issue, and we need to address them. For some consumers of the IP in some of the longer-lifecycle application areas, this is probably the hardest thing to do. It requires a great deal of cooperation.

That includes setting up expert reviews on both the functional and security side, and conducting an API design review to make sure that you are integrating it properly. It also requires identifying potential threats within your target system using expert assessment by your own security folks.

Perhaps the most important words of wisdom are to set up a culture of security and always take action. If you see something that is not right, make sure you have an internal path to raise that issue. Document it and take action.