After months of tracking down bugs and expanding test coverage, you are finally confident your chip design is ready to ship.  However, if you don't include security in your testing and verification process your confidence in the design is likely misplaced -- and nothing demonstrates this fact more clearly than a critical vulnerability. Tortuga Logic consistently finds these vulnerabilities in open-source and commonly used cryptographic cores. In fact, one such vulnerability might be living in your design right now [1]. 

 We of course know that a large and growing percentage of the total effort that is required to bring a new design to market is in the testing and verification, many quoting up to 70%. However, this cost is a critical part of building both embedded software and custom silicon designs. The finality of a release means that the risk associated with delivering under functioning systems is high.  A "show-stopping" bug is not something that any engineer wants to see escape into the wild. 

 More often than not, systems are deployed every day with numerous bugs, both known and unknown. So what makes a bug a show-stopper?  It really comes down to the old joke-- Patient: “Doctor, it hurts when I move my elbow like this”; Doctor: “Well ... then don't do that!”  If a bug affects a functionality that many users depend on, and whose presence significantly limits the usability of the end system, it's a show-stopper.  The bug means a couple hundred people need to reboot their phone at least once every 6 months?  That is probably fine.  The bug means you broke the internet?  People will notice.  The point is that in traditional correctness verification, the risk associated with a bug is really the product of the number of people that will run into that problem through the natural use of their device and the magnitude of the effect it will have on their experience.  When this same reasoning is applied to security, you suddenly see an important difference.

 The problem in silicon security is twofold: 1) The behaviors that excite the latent vulnerabilities in designs are decidedly unnatural.  They are carefully crafted by adversaries to cause all of the pieces of an attack to fall into place.  An attacker does everything possible to make sure that the perfect sequence of behaviors happens to compromise the device occurs.  Simply put, coverage of the most common behaviors says almost nothing useful about the security of the devices as attacks live almost exclusively in the corner cases of behavior.  2) Most security systems are fragile.   Dropping even a subset of the bits from a single key or flipping a few bits of internal state can be enough to completely subvert years of careful policy design, cryptographic cleverness, and architecture security support.  Thus the risk equation instead becomes the product of the probability an attacker can find a vulnerability and the cost associated with that vulnerability when it is used to maximum effect. 

So how do we turn our understanding of this difference into an actionable testing plan?  First, we consider the many possible things an attacker might try (including things we as testers might not have ever considered) on the most critical state in the system.  Here is where information flow analysis proves to be so powerful.

 Back to our example of a real system.  Consider the following implementation of the AES encryption block [1].  While incredibly clever methods for extracting bits of the secret key exist (e.g. through cache side channel analysis), in this design none of that is even needed.  This is a perfectly functional implementation of AES.  Give it a secret key and a plain text, and 506 cycles later the encrypted value is returned.  Great!  But what happens on the other 505 cycles before result is returned? We used our Sentinel security language to express the following security check: key_i =/=> data_o, which states that no information about the secret key should leak to the data output of the AES core. In any implementation of AES, the encrypted output of the core should be affected by the value of the secret key, as the encrypted output is a function of the secret key. We then used Prospect to check the Sentinel property for a pass-or-fail result. And what do you know? This property failed! None of you should be surprised. But, interestingly enough, Prospect reported that this property was failing within 4 cycles, and not after the expected 506 cycles stated in the functional spec. Upon further investigation, we found that the design was improperly written and was leaking the secret key to the data output as data_o = data_i key_i, which is a disastrously large leak of information. The kind that can compromise billions of devices.

[Think you have this problem? Check out our Hardware Security Assessments]

 The RTL for this core was downloaded unmodified and was analyzed purely from its input and output ports and the analysis did not require knowledge about the inner workings of the design. Let’s be clear – this AES core would have passed ALL functional tests and correctly encrypts and decrypts data according to the AES standard, but was likely never tested with a proper security spec. And the end result is a ticking time bomb sitting in any silicon design.

 Summary

An IC that is thoroughly verified and functions perfectly to specification but has security vulnerabilities will fail in today’s market. Security verification is thus no longer optional and must be viewed as equally important to functional verification for product success. In upcoming blogs we’ll be discussing the barriers to overcome in adopting security verification -- cultural and organizational (defeating the “resistance to change” that is so prevalent among engineering teams), the requirement that security threat models be included in all design specifications, and acknowledging that security verification requires an investment in new tools and expertise.

About Tim Sherwood

Dr. Sherwood has worked both in industry and academia on silicon security for over a decade. He is a Professor in the department of Computer Science at UC Santa Barbara, specializing in the development of novel computer architectures for security, monitoring, and control. He leads an award-winning research lab focused on these areas, with funding from several major government grants. His work and teaching have both been recognized, as he is the recipient of the 2009 Northrop Grumman Teaching Excellence Award, the National Science Foundation Career Award, and the ACM SIGARCH Maurice Wilkes Award. Prior to joining UCSB in 2003, he graduated with a B.S. in Computer Science and Engineering from UC Davis (1998), and received his M.S. and Ph.D. from UC San Diego (2003).

 References

1. Opencores.org, “128-bit verilog aes core.” http://opencores.org/project,systemcaes, April 2010.

2.Lackie, Lara. Vulnerability, Just Ahead. Digital image. Nearly All Websites Have Serious Security Vulnerabilities – New Research Shows. ITSecurityGuru, 15 July 2015. Web.

3.Computer Chip. Digital image. Alamy Stock Photo. South West Images Scotland, Oct. 2007. Web. 14 Sept. 2016.

 

Comment