Today, embedded systems often handle sensitive information such as application code (IP) and data, making security a major concern in their design. To establish a reasonable foundation for judging whether the proposed security system is sufficient to fend off attackers or is overly defensive, it is necessary to identify the perceived security threats. This means we need to clarify who the adversaries are, what capabilities they possess, and what their objectives are. What do we need to protect, and against whom or what threats should we defend? There is no one-size-fits-all solution in the world, nor is there a security system that is 100% secure. However, a security system does not have to be a flawless solution, nor does it need to be so impenetrable that it loses its application value. A security system only needs to be sufficiently secure, meaning it can withstand potential enemy attacks during the expected effective time of the data it protects.
If there is no application environment, security is meaningless.
Embedded system designers often misunderstand security, thinking that security measures such as specific encryption algorithms and security protocols are merely additional features of the system. Security is a process, not a product or an ultimate state that remains unchanged forever. Moreover, security measures cannot simply be added to a product under the assumption that the product will remain secure indefinitely. One of the most challenging problems facing today’s designers is to clearly define the security requirements and objectives of embedded systems. There are many methods to help solve this problem, and the methods discussed in this article involve threat modeling and risk assessment, aimed at helping designers define security strategies and then design countermeasures to implement those strategies.
Security Design—Detecting Threats in the Initial Design Phase
When designing security solutions, the first step is to define a threat model and then create a security strategy. Once the assessment is completed, specific technologies can be confidently selected to implement security countermeasures. Threats determine response strategies, and strategies determine design. See Figure 1.
Figure 1. Designing a security solution requires (1) defining a threat model, and (2) creating a security strategy.
Many designers make the same mistake of not clearly understanding the real threats they may encounter when designing a security system, as well as the significant risks these threats pose to their end products. Instead, they dogmatically pile various security technologies together, hoping to achieve high security. This approach is costly, as no system can defend against all security threats, and including unnecessary technologies in the design that defend against non-existent threats is meaningless.
Threat Modeling—Value Means Risk
For resource-constrained devices, embedded systems must strike a balance between parameters such as storage capacity, power consumption, processing capability, time-to-market, cost, and security requirements. Despite the challenges of limited resources, it is still possible to develop systems that effectively operate in open environments by carefully considering the threat model and designing the system to work within the available computational limits that meet that model.
For system designers, considering the principles of “threat modeling” is very useful. Threat modeling is based on the assumption that every system has inherent value worth protecting. However, because these systems are valuable, they are also open to internal or external threats, which can and often do cause damage to the end product. Security vulnerabilities that are identified after the design is completed are often unfixable and jeopardize the invested funds and development resources. Therefore, it is necessary to enhance the demand for security assessment in the early stages of the design cycle and to monitor and iteratively correct throughout the design cycle.
Essentially, we can define a threat model as: “Identifying a set of possible attacks in order to consider a comprehensive risk assessment strategy.” With a threat model, we can assess the probability of attacks, potential harm, and priority.
Threat modeling is difficult, but it is necessary. Threat modeling requires considering how the system may be attacked. If the modeling is successful, it can address potential system security failure risks, such as how failures occur and what happens during failures. Typically, under market and cost pressures, this assessment is conducted in a particular way, namely by brainstorming all possible attacks the system may face (of course, potential hackers may be one step ahead of you). A more systematic and repeatable approach for this process is to use attack trees, a concept first introduced by Bruce Schneier. Attack trees provide a systematic way to categorize the different ways to attack a system. Generally, it describes the attacks on the system in a tree structure, where the nodes of the tree represent attacks. The root node of the tree is the overall goal of the attacker, and the different paths to achieve that goal are the leaf nodes, as shown in Figure 2.
Figure 2. Attack tree representing any embedded system that must protect intellectual property (IP), such as mobile phones, VoIP, video surveillance systems, etc.
When threat modeling is completed correctly, the real threats are identified. However, if possible threats are misunderstood, the cost can be high. One case of designers misunderstanding threats is the protection measures for DVDs. Although DVD discs are encrypted and the keys are placed in the player, as long as the player contains anti-tampering hardware, this protection method is sound. However, when software players are introduced, the keys can be exposed, and through reverse engineering, the keys can be recovered, allowing anyone to freely copy and distribute any DVD content.
In this case, it is a flawed threat model. Although there are security measures, they do not truly solve the problem.
Risk Assessment
Merely listing a bunch of threats is not enough; since the risks of different threats vary, it is also necessary to know the risk of each threat. The next step in threat modeling is risk assessment, which is a critical part of any security system design. Some fundamental questions for risk assessment, such as “What to protect,” “Why to protect,” and “Who to defend against,” should be clarified in the early stages of the design cycle. Taking the measures shown in Table 1 as early as possible will help you choose effective and secure prevention technologies and defense strategies.
Table 1. Risk Assessment
Security Strategy
After identifying threats and weighing risks, the next step is to establish a security strategy. The security strategy is the strategy behind the solution, while technology is merely a tactical means. The security strategy describes “why,” not “how.”
For example, one of the goals of a security strategy based on FPGA design may be to “maintain the confidentiality of the configuration bitstream,” which is a system objective. “How to do it” or the implementation of countermeasures may involve encrypting the configuration bitstream using symmetric key encryption such as AES to achieve this goal.
The overall design process can be summarized as follows:
Understand the real threats to the system and assess the risks of these threats.
Evaluate which threats are the most dangerous and most likely to occur.
Document and archive the security strategies needed to systematically defend against these threats. This will be a series of statements such as, “Only trusted code is allowed to enter restricted memory,” or “Password keys must be kept confidential.”
Design and implement preventive measures that strengthen the system’s security strategy. Theoretically, these preventive measures are a mix of protection, detection, and response mechanisms.
Preventive Measures
Once potential attacks have been identified and security objectives defined, preventive technologies can be considered to mitigate risks. An effective security prevention measure includes three different parts: protection, detection, and response. These countermeasures must work together rationally based on known threats to the system. If the protection mechanism is breached, detection and response mechanisms must be relied upon to fend off the attack. If the response mechanism is absent or ineffective, having a detection mechanism is meaningless.
In embedded systems, protection, detection, and response technologies can take many forms (see Table 2). These technologies work together to prevent potential attacks or provide useful court audit information after an attack.
Table 2. Preventive Technologies
Conclusion
Security design is a dynamic process related to specific systems and is often complex. For every security topic discussed in this article, there is a wealth of research and specialized technical materials available for designers to study and learn. The most important thing when starting a design is to begin security requirement assessments early, define system security objectives, and regularly determine whether the initial threats have changed or expanded based on system usage and market changes.
When can you know that a system is secure enough? Robbie Sinclair, who is responsible for security at Country Energy in New South Wales, Australia, once said, “Security measures are always excessive until you feel insecure.” When you start your security assessment, please provide your answer to the question of “How secure is secure enough?”
Philip Giordano is a Senior Application Engineer at ADI, having joined the company in 1998, currently responsible for new product development of embedded processors with a focus on security features.
1.Where Are the Opportunities for AI Chips in China? Keep Three Points in Mind
2.Sorting Linux Module Frameworks
3.Intel May Use CPU+GPU+FPGA Combinations to Compete in AI!
4.Software Architecture Is Important! The Path to Mastering Embedded C Language
5.If You Are Doing IoT Development, Remember These Chip Companies!
6.Example: Using STM32 Microcontroller to Solve Quadrotor Drone Flight Control
Disclaimer: This article is a network reprint, and the copyright belongs to the original author. If there are copyright issues, please contact us, and we will confirm the copyright based on the copyright certification materials you provide and pay the remuneration or delete the content.