Embedded security is one of the most important topics in our industry. You could build an amazing microcontroller-based design, but if it is vulnerable to attack, it could become useless or even a liability. 
Virginia Tech professor Patrick Schaumont explains, “perfect embedded security cannot exist. Attackers have a wide variety of techniques at their disposal, ranging from analysis to reverse engineering. When attackers get their hands on your embedded system, it is only a matter of time and sufficient eyeballs before someone finds a flaw and exploits it.”
So, what can you do? In CC25, Patrick Schaumont provided some tips:
As design engineers, we should understand what can and what cannot be done. If we understand the risks, we can create designs that give the best possible protection at a given level of complexity. Think about the following four observations before you start designing an embedded security implementation.
First, you have to understand the threats that you are facing. If you don’t have a threat model, it makes no sense to design a protection—there’s no threat! A threat model for an embedded system will specify what can attacker can and cannot do. Can she probe components? Control the power supply? Control the inputs of the design? The more precisely you specify the threats, the more robust your defenses will be. Realize that perfect security does not exist, so it doesn’t make sense to try to achieve it. Instead, focus on the threats you are willing to deal with.
Second, make a distinction between what you trust and what you cannot trust. In terms of building protections, you only need to worry about what you don’t trust. The boundary between what you trust and what you don’t trust is suitably called the trust boundary. While trust boundaries were originally logical boundaries in software systems, they also have a physical meaning in embedded context. For example, let’s say that you define the trust boundary to be at the chip package level of a microcontroller.
This implies that you’re assuming an attacker will get as close to the chip as the package pins, but not closer. With such a trust boundary, your defenses should focus on off-chip communication. If there’s nothing or no one to trust, then you’re in trouble. It’s not possible to build a secure solution without trust.
Third, security has a cost. You cannot get it for free. Security has a cost in resources and energy. In a resource-limited embedded system, this means that security will always be in competition with other system features in terms of resources. And because security is typically designed to prevent bad things from happening rather than to enable good things, it may be a difficult trade-off. In feature-rich consumer devices, security may not be a feature for which a customer is willing to pay extra. The fourth observation, and maybe the most important one, is to realize is that you’re not alone. There are many things to learn from conferences, books, and magazines. Don’t invent your own security. Adapt standards and proven techniques. Learn about the experiences of other designers. The following examples are good starting points for learning about current concerns and issues in embedded security.
Security is a complex field with many different dimensions. I find it very helpful to have several reference works close by to help me navigate the steps of building any type of security service.
Schaumont suggested the following useful resources:
- R. Anderson, Security Engineering, Second Edition, Wiley Publishing, Indianapolis, IN, 2008.
- BBC Newsnight, “Chip and PIN is Broken,” www.youtube.com/watch?v=1pMuV2o4Lrw.
- D. Bernstein and T. Lange, “EBACS: ECRYPT Benchmarking of Cryptographic Systems,” http://bench.cr.yp.to/supercop.html.
- E. Biham, O. Dunkelman, S. Indesteege, N. Keller, and B. Preneel, “How to Steal Cars—A Practical Attack on Keeloq,” COSIC, www.cosic.esat.kuleuven.be/keeloq/.
- S. Checkoway, “Comprehensive Experimental Analyses of Automotive Attack Surfaces,” www.youtube.com/watch?v=bHfOziIwXic.
- E. Diels, “Technicolor Security Newsletter,” www.technicolor.com/en/hi/technology/research-publications/security-newsletters/security-newsletter-20.
- N. Fain and Vadik, “Embedded Analysis,” http://events.ccc.de/congress/2010/wiki/Embedded_Analysis.
- ———, “JTAG/Serial/Flash/PCB Embedded Reverse Engineering Tools and Technique,” www.youtube.comwatch?v=8Unisnu-cNo.
- N. Ferguson, B. Schneier, and T. Kohno, Cryptography Engineering, Wiley Publishing, Indianapolis, IN, 2010.
- Flylogic’s Analytics Blog, www.flylogic.net/blog/.
Circuit Cellar's editorial team comprises professional engineers, technical editors, and digital media specialists. You can reach the Editorial Department at editorial@circuitcellar.com, @circuitcellar, and facebook.com/circuitcellar
Leave a Comment