How secure is secure for embedded systemsí design
Noting that security is a process, Phil describes a methodology that incorporates threat modeling and risk assessment, which designers can employ to define and enforce a security policy.
Today’s embedded systems often handle sensitive information in the form of application code (IP) and data, making security a major concern in their design. Forming a rational basis for deciding if a proposed security system will be adequate or overkill calls for identifying the perceived security threat. By threat we mean what set of adversaries do we believe we need to thwart, what are their capabilities, and what are their goals? What are we trying to protect, and who or what are we protecting against? One solution will not fit everyone, and no security system is ever 100 percent secure. However, a security system does not have to be a perfect solution, nor does it need to be utterly unbreakable to be useful. Rather, it needs to be strong enough to resist attacks by likely enemies for whatever length of time the data it protects is expected to remain valid.
Without context, security has no meaning
Security is often misconstrued by embedded system designers as the addition of features such as specific cryptographic algorithms and security protocols to the system. Security is a process, not a product or an end state that remains unchanged for all time. Nor can security be simply added to a product with the assumption that the product will forever remain secure. Properly defining security requirements and goals for embedded systems is one of the most difficult tasks facing designers today. Various methodologies exist to help in this task. The methodology we’ll discuss here involves threat modeling and risk assessment, which can help designers to define a security policy and then devise countermeasures to enforce this policy.
Security design – Detecting threats early in the process
In designing a security solution, it is first necessary to define a threat model, and then create a security policy. Once the assessment is done, specific technologies can be confidently chosen for employing countermeasures. The threats determine the policy, and the policy determines the design. See Figure 1.
One thing that many designers get wrong is designing a security system without first identifying and understanding real threats that are likely to be encountered and represent significant risk to their end products. Instead they take a cookbook approach, throwing together an assortment of security technologies in the hopes of achieving security “magic.” Such methods are costly. Defending against things that are not real threats has as much of an impact as not catching real security risks. Although no system can defend against everything, it is simply not practical to include unnecessary technologies in a design.
Threat modeling – If it has value, it is under threat
Embedded systems deal with resource-constrained devices where parameters such as memory capacity, power consumption, processing power, time to market, and cost must strike a balance with security requirements. Despite the resource challenges, it is possible to develop a working system that allows a product to be effective in the wild by carefully considering a threat model and designing a system to work within the limitations of the available computing power addressing that model.
It is useful for a system designer to consider the principle of threat modeling. Threat modeling is based on the assumption that every system has intrinsic value that is worth protecting. However, because these systems have value, they are also open to internal or external threats, which can, and often will, cause damage to the end product. Final design security breaches are often unrecoverable and jeopardize investments of dollars and development resources, reinforcing the need for security assessment at the beginning of the design process, which is then monitored and revisited throughout the entire design life cycle.
We can define a threat model as: “Identifying a set of possible attacks to consider coupled with a thorough risk assessment strategy.” Having a threat model enables us to assess the probability, the potential harm, and the priority of attacks.
Threat modeling can be difficult, but it is necessary. It involves thinking about how a system can be attacked. When successful, it addresses potential system security failures such as how it fails and what happens when it fails. Market and financial pressures often cause an ad hoc approach to assessment. We brainstorm all the possible attacks that can be perpetrated on a system (of course, our potential hacker may still be one step ahead of our brainstorming session). A more systematic and repeatable approach to this process is to use attack trees, a term first introduced by Bruce Schneier [1,2]. Attack trees provide a way to systematically categorize the different ways in which a system can be attacked. A tree structure models attacks against a system using nodes to represent attacks. The root node of the tree is the global goal of an attacker, and leaf nodes are different ways of achieving that goal, as shown in Figure 2.
When threat modeling is done properly, the real threats are identified. Getting the threat wrong, however, can be costly. One example in which designers got the threat wrong is evident in the protection used for DVDs. Even though DVD disks were encrypted, the keys also were resident in the players. This worked fine as long as the players were comprised of tamper-resistant hardware. When software players were introduced the keys became exposed, allowing for reverse engineering to recover the keys and permitting anyone to freely copy and distribute the content of any DVD.
In the case of DVD disks, it was the threat model that was flawed. Security countermeasures were in place, but they did not solve the correct problem.
Listing a number of threats is not enough, we also need to know how much to worry about each of them as some are more threatening than others. The next step following the threat modeling is risk assessment, a vital element in any security system design.
Assessing what you are protecting, why you are protecting it, and who are you protecting it from should be accomplished at the very beginning of your design cycle. Taking the measures shown in Table 1 early will lead to effective, secure countermeasure technology choices and defense strategies.
Once we’ve identified threats and weighted risks, it is time to establish a security policy. The security policy is the strategy behind the solution, while the technologies are merely tactics. The security policy describes the “why,” not the “how.”
For example, one goal in a security policy involving an FPGA-based design might be to: “maintain the confidentiality of the configuration bit stream.” This is a goal of the system. The how, that is, the countermeasure implementation, would likely be to use symmetric key encryption such as AES to encrypt the configuration bit stream.
The overall design process can be summed up as follows:
n Understand the real threats to the system, and assess the risk of these threats.
n Assess which threats are most dangerous and most likely to occur.
n Describe and document the security policy required to systematically defend against these threats. This will be a series of statements such as: “Only trusted code will be allowed access to restricted memory” or “Secret cipher keys must be kept confidential.”
n Design and implement the countermeasures that enforce the system’s security policy. Ideally, these countermeasures will be a mixture of protection, detection, and reaction mechanisms.
Once potential attacks are identified and security goals are defined for a system, it is then time to consider implementing countermeasure technologies to mitigate risk. There are three distinct parts of an effective set of security countermeasures: protection, detection, and reaction. These countermeasures must logically work together based on the known threats to the system. If the protection mechanisms are breached, the detection and reaction mechanisms must be relied upon to thwart the attack. If the reaction mechanism is not present or is ineffective, there is no point in having a detection mechanism.
In embedded systems, protection, detection, and reaction technologies can take many forms (see Table 2). Working in tandem, they can head off potential attacks, or provide forensic audit information after an attack, should one occur.
Security design is by nature a dynamic, system-specific, and sometimes complex process. For each security topic discussed here, there are volumes of documented research and expertise to investigate and consider. What is most important when starting the design process is beginning security needs assessment early, defining the system’s security goals, and constantly revisiting changing system uses and market changes to determine if original threats have changed or broadened.
When do you know that your system is secure enough? Robbie Sinclair, Head of Security, Country Energy, NSW Australia, once said, “Security is always excessive until it's not enough.” The answer to the query “How secure is secure?” exists, as long as we ask the right questions.
Philip Giordano is a senior applications engineer with Analog Devices. He joined Analog Devices in 1998 and is currently involved in new product development of embedded processors with a focus on security features.
1. Bruce Schneier. “Attack trees: Modeling security threats.” Dr. Dobb's journal, December 1999.
2. Bruce Schneier. “Secrets & Lies: Digital Security in a Networked World.” Wiley, 2000.
[3 – See Table 2] S.H. Weingart, " Physical Security Devices for Computer Subsystems: A Survey of Attacks and Defenses 2008'', http://www.atsec.com/downloads/pdf/phy_sec_dev.pdf.
Analog Devices, Inc.
+1 781 329 4700