A Hardware Security Standard Advances

Security is a slippery topic. We all agree that “something should be done”, but most of us are waiting for someone else to lead the way. There’s no shortage of proprietary solutions, though given the distributed nature of the problem it’s difficult to see how those separately or collectively can rise to the occasion. What we really need are standards and then either regulation or market forces to drive non-compliant providers out of business. Accellera has taken a step in this direction with their first release of the standard “Security Annotation for Electronic Design Integration”. Otherwise known as SA-EDI, informally SADIE, a new hardware security standard.

Where do you start?

When you think about it, the best place to start isn’t some kind of idealized technology or language. No matter how ingenious these proposals might be, new attacks by definition exploit weaknesses we haven’t considered. We don’t need a standard which will become obsolete as soon as some completely new exploit emerges. Instead, start with a list of all known exploits. Call these common vulnerabilities and exposures (CVE), which is what the Mitre Corporation did in building their list for software exploits. If a new exploit appears, just add it to the list, no matter how clever or different the technique it uses.

Next, dig into each exploit to find the underlying weakness(es) that made that exploit possible. Make a list of these and call it a common weaknesses enumeration (CWE). Again, Mitre Corporation have done this. In fact these guys have led the way so effectively in software, and have started to do the same thing for hardware exploits, that Accellera is following their approach quite closely, in philosophy, though Accellera calls their database the Security Weakness Knowledge Base. This can refer to multiple knowledge bases such as Mitre CWE as well as in-house databases.

Entries can be decorated with tags to specify product families in which attacks most commonly appear, revisions (since attacks also go through upgrades), and other useful info. So a part of the SA-EDI standard defines a structure for this knowledge base information. One very important tag lists the risks associated with a weakness using the familiar CIA (Confidentiality, Integrity, Availability) classification.

Annotating IPs

A goal for the standard is to promote development of checking technologies, but it can’t assume any particular style of checking. Assertions probably aren’t appropriate. But there are common factors in all such checks. One is information about what assets you want to protect. An example would be an encryption key. Assets aren’t necessarily just data. A watchdog timer is an asset to protect if you use it to trigger a safety or security check for example.

Then you need to indicate what attacks from the knowledge base might be relevant for each asset and what elements in the design (ports, interfaces, configurations) would be used in such an attack. These together with any security mitigations you might add form what the standard calls an attack point security objective (APSO).

SA-EDI is an annotation standard. The goal is to annotate the IP with this information. How you create that information is up to you. In the near term, this may be manual, with minimal scripting support. Annotation is handled through a side JSON file. I’ve seen some mention also of XML, presumably for IP-XACT support. The current bias seems to be more to JSON which I must admit is more human-readable than XML.

A quick sidebar on mitigation. If the IP developer knows there is a security weakness in their IP, why don’t they fix it? That might not always be appropriate. A local fix may be the least optimal solution to a security problem. The right place to fix a JTAG security problem is at the top-level, not in every individual IP instance that path touches. However the IP vendor should annotate that the test/debug path into their IP is a security weakness and should be addressed in integration.

SA-EDI and integration

With suitable tools (scripts or later more advanced tools) an integrator can verify the correctness of the delivered SA-EDI package, checking that the IP vendor didn’t skip some of the weaknesses they should have considered. Integrators can also adapt the annotation, dropping weaknesses they know won’t be a concern (they don’t plan to hookup JTAG for example). They can also add new weaknesses they want to consider, maybe based on an in-house knowledge base. Finally they run whatever security verification analyses they have available.

When can we expect tooling?

Synopsys, Cadence, Tortuga and OneSpin all have representatives on the working group. Tortuga is fairly closely involved with Mitre on their hardware list. So I have to believe work is progressing to develop tools/apps/extensions. That said, addressing a complete list is going to require a number of different technologies. Just looking quickly at the Mitre list for hardware:

• Some checks relate to package completeness, eg missing documentation
• Formal checks may work well in some cases, eg improper lock behavior after power state transition
• Some may require fairly deep verification, eg DMA enabled too soon in boot phase
• The list includes side-channel attacks but this is a very broad topic. I expect further division here
• Functional verification tools are not going to address manufacturing and lifecycle management concerns

There’s some concern about simulation-based checks unless we develop a robust sense of coverage for security. Nevertheless I can see plenty of opportunity for more automation in support of the standard. Great start!

You can download the standard HERE.