Protecting products and intellectual property (IP) from attackers is a fairly new concept that many engineers have not yet had to face. It is only a matter of time, though, until products—which are becoming more embedded and integrated with the real world—become targets for attacks leading to theft of service, loss of revenue, or a damaged corporate reputation. Consumer electronics, financial and medical technology, and network products are all at risk.
In this article, I’ll focus on the “why” and the “what” of embedded security, also known as secure hardware. Why does it matter? Why is it important to you, the designer? In what ways can someone attack your product? Because you can’t incorporate secure design methods without understanding what you are protecting and why, this article is a fitting introduction to the complexities of embedded security.
Reading this article won’t turn you into a security expert overnight. Nor will it provide all the answers to your secure hardware design needs. But, it will help you understand the major classes of attack and the mindsets of potential attackers. Actual secure hardware mechanisms come in all shapes and sizes, ranging from tamper-resistant enclosures to embedded IC dies in PCBs (to make them more difficult to probe). I’ll discuss these in a future Circuit Cellar article.
What embedded security typically comes down to is this: Is the cost of a successful attack greater than the value of what’s being protected? I’ll present some guidelines to help you make a determination.
UNDERSTAND YOUR RISK
As with everything in engineering, embedded security is all about trade-offs—risk management, as they say in the business world. Are there components or data in your system that need to be protected? If so, how much is it worth to protect them?
Forget what the glossy marketing material says about security products. There’s never a single answer and a single product to solve everybody’s product security needs. Every product has its own threat risks and is susceptible to certain types of attacks. Before being able to make an educated, informed decision, you need to understand the threat, the value of the contents being protected, and the reason for protecting such contents. Essentially, weaker, more vulnerable devices should contain less valuable secrets.
— ADVERTISMENT—
—Advertise Here—
For example, a priceless family heirloom might be stored in a fireproof and tool-resistant safe. However, it wouldn’t make much financial sense to purchase such a safe to store an easily replaceable, inexpensive piece of jewelry. By the same token, it wouldn’t be feasible to implement an extremely secure, multilayered hardware solution just to protect a single password that is used to access undocumented features in a mobile phone; but, it would be in order to protect a financial institution’s cryptographic keys used for encrypted communications whose theft could result in the loss of millions of dollars.
When defining the security envelope of your product, there are three questions you should ask yourself (or your design team). First, what needs to be protected? Identify the critical components in your circuit that need to be protected before you start construction. It’s extremely difficult to implement proper security mechanisms after the fact. Such components to protect may include specific algorithms, device identifiers, digital media, biometrics, cryptographic keys, or product firmware. In addition to protecting discrete data contents, you may be interested in implementing a secure product boot sequence, secure field programmability, or a secure remote-management interface. Be aware that in some cases, even noncritical portions of your design can unknowingly compromise the security of the system, especially if they fail in an unanticipated way.
Second, why is it being protected? In most situations, critical data is being protected to prevent a specific attack threat. Ignoring or overlooking the possibility of attack can lead to a vulnerable product. In some countries, protecting certain content may be a legislative requirement. For example, a medical device containing confidential patient information must be secured in order to meet the U.S. Health Insurance Portability and Accountability Act (HIPAA) requirements.
Finally, whom are you protecting against? The types of attackers vary, ranging from a curious, harmless hardware hacker to an entire group of researchers backed by a competitor, organized crime, or government. As such, it’s important to attempt to properly identify the skill level and theoretical goals of the primary attackers against your product.
As a designer, you have the challenging task and responsibility of creating and ensuring your system’s security. You must understand every possible aspect of the design and are typically constrained by technical, financial, and political agendas. Attackers have an easier job, which is to exploit insecurities in the system. They need only to discover one vulnerable area of the design, and they typically have few constraints on their methods. They’ll likely choose the attack that yields the best results in the easiest and most repeatable fashion.
CLASSES OF ATTACK
No system will ever be 100% secure. “Secure” simply can be defined as when the time and money required to break the product is greater than the benefits to be derived from the effort. Given enough determination, time, and resources, an attacker can break any system.
At the highest level, four classes of security threat exist, as described by C.P. Pfleeger in Security in Computing. Through interception (or eavesdropping) an attacker can gain access to protected information without opening the product. With embedded systems, this can be achieved by monitoring the external interfaces of the device and by analyzing compromising signals within electromagnetic radiation or current fluctuations. On a computer network, this can be done by illicitly copying data or through promiscuous mode network monitoring. Although a loss may be discovered fairly quickly for certain attacks, like credit card theft or spoofed user authentication, a silent interceptor might not leave any traces.
Interruption (or fault generation) is a threat because an asset of a product becomes unavailable, unusable, or removed. An example is the malicious destruction of a hardware device, the intentional erasure of program or data contents, or a denial-of-service network attack. Fault generation consists of intentionally provoking malfunctions, such as operating the device under abnormal environmental conditions, which may lead to the bypassing of certain security measures.
The third type of threat is modification, which involves tampering with a product’s asset. Modification is typically an invasive technique for both hardware (e.g., circuit modifications or microprobing) and software/firmware (e.g., changing the values of data or altering a program so that it performs a different computation).
— ADVERTISMENT—
—Advertise Here—
Lastly, fabrication creates counterfeit assets in a product or system. Fabrication can come in many forms, including adding data to a device, inserting spurious transactions into a bus or interface, and a man-in-the-middle attack on a network. Sometimes these additions can be detected as forgeries, but if skillfully done, they may be indistinguishable from the real thing.
TYPICAL ATTACK GOALS
When a product is targeted, the attacker usually has a goal in mind. This may be a simple goal, such as reverse engineering the circuitry in order to personalize or customize the device, or a more dedicated one, such as retrieving cryptographic keys or sensitive product trade secrets.
The specific goal of an attack tends to fit into one of four categories. The first is competition (or cloning), which is a scenario in which an attacker (usually a competitor) reverse engineers or copies specific IP in order to gain an advantage in the marketplace. The goal is to improve a product by using the stolen technology or to sell lower-priced knockoffs. Common target areas are circuit board features and product firmware.
Theft-of-service attacks aim to obtain a service for free that usually requires payment. Examples include mobile phone cloning, bypassing copy protection schemes on video game systems, and modifying cable boxes to receive extra channels.
User authentication (or spoofing) attacks are typically focused on products that are used to verify the owner’s identity, such as an authentication token, smartcard, biometric reader, or one-time-password generator. The attacker’s main goal is to gain access to personalized data and systems by spoofing the identity of the legitimate user.
Privilege escalation (or feature unlocking) attacks are aimed at accessing the hidden/undocumented features of a product and increasing the amount of control given to the user without having legitimate credentials. For example, using specialized circuitry to communicate with a mobile phone to gain access to phone diagnostics or acquiring administrator access on a network appliance.
Generally, an attack is achieved in one of three ways. In a focused attack, the adversary brings the target product into a private location to analyze and attack it on his or her own time with little risk of being discovered. A focused attack is probably the most familiar type of attack. Consider a curious student modifying a piece of hardware in his dorm room or a more determined criminal in a laboratory attempting to crack encryption routines.
Lunchtime attacks often take place during a small window of opportunity, such as a lunch or coffee break. Typically, the attack would need to be completed in a short period of time, ranging from a few minutes to a few hours. Lunchtime attacks are risky because they are easily detected if the target product is missing or has visibly been tampered with. For example, if you check your coat at a restaurant, an attacker could remove your PDA, retrieve the desired data, and return the PDA to your coat pocket within a matter of minutes and without being detected. Another example is an attacker copying data from a target’s authentication token or USB thumb drive that they left on their desk while attending a meeting.
Finally, there’s the insider attack, which may come in the form of run-on fraud by a manufacturer (producing additional identical units of a product to be sold on the gray market) or a disgruntled employee willing to sabotage the product or sell critical information such as system firmware or encryption keys. Many, but not all, insider threats can be thwarted with strict compartmentalization of critical data, access control, and chain-of-custody policies.
PRODUCT ACCESS
There are many ways an attacker can gain access to your product, but it often corresponds directly to the attack goal and usually involves one of four methods. In the first instance, the attacker purchases the product through a retail outlet, often with no means of detection (e.g., paying with cash). Multiple products could be purchased, with the first few serving as disposable units to aid in reverse engineering or to discover any existing tamper mechanisms. This scenario may be financially prohibitive for low-budget attackers but is typical for most focused attacks.
In the second instance, the attacker rents or leases the product from a vendor, distributor, or rental company, often on a monthly basis. Most attack types are possible in this instance, but because there is a high risk of detection when the product is returned, attackers will be cautious not to tamper with it.
In some cases, the attacker does not own the target product. The product is in active operation and may belong to a specific person (e.g., a mobile phone or smartcard), but the attacker may have physical access to the product. This is the most difficult type of attack because risk of detection is high.
In the final scenario, the attacker does not have access to the product, so all attacks are performed remotely (e.g., through a wired or wireless network). The attacker does not require special hardware tools and can easily mask his location. The risk of detection is low. Remote access attacks are common against computer networking equipment and appliances, such as routers, firewalls, access points, web servers, and storage area networks.
UNDERSTAND THE ATTACKER
“The only way to stop an attacker is to think like one.” That’s a favorite saying of mine. An FBI profiler tries to put himself in the mind of his subject. You must do the same when figuring out what, if any, security features you need to implement in our design. Today, because of advances in technology, the lower cost of products, and easy access to once-specialized tools, attacks against hardware are becoming more prevalent.
Attackers can be classified into three groups depending on their expected abilities and strengths: class I (clever outsiders), class II (knowledgeable insiders), and class III (funded organizations). This classification is essentially an industry standard for describing attackers in an academic fashion.[1]
— ADVERTISMENT—
—Advertise Here—
Class I attackers are often extremely intelligent but might have insufficient knowledge of the system. They might have access to only moderately sophisticated equipment. They often try to take advantage of an existing weakness in the system rather than try to create one. Sometimes referred to as “script kiddies” in the computer security industry, these attackers run preprogrammed scripts to exploit known security vulnerabilities instead of finding their own.
Class II attackers have a substantial amount of specialized technical education and experience. They have a decent knowledge of the product or system, and often have highly sophisticated tools and instruments for analysis.
Class III attackers are teams of specialists with related and complementary skills backed by great funding. They are capable of performing in-depth system analysis, designing sophisticated attacks, and using the most advanced analysis tools. They may use Class II adversaries as part of the attack team.
Table 1 is comparison of each attacker class against available resources. The table may help to visualize the capabilities of the various attacker groups.
![Table 1: Take a look at each attacker class compared to available resources. As you can see, each class has specific capabilities that will play a part in determining your product’s risk of attack.[2]](https://i0.wp.com/circuitcellar.com/wp-content/uploads/2016/11/Grand-169-Table.jpg?resize=672%2C221)
Table 1: Take a look at each attacker class compared to available resources. As you can see, each class has specific capabilities that will play a part in determining your product’s risk of attack.[2]
ADDING SECURITY
Security is a process, not a product. Security must be designed into your product during the conceptual design phase, and it should be considered for every portion of the design. It must be continually monitored and updated in order to have the maximum effect against attacks. Security can’t be added to a product and forgotten about. The product won’t remain secure forever.
Many times, an engineering change will be made to the product circuitry or firmware without a reevaluation of system security. Without a process in place to analyze changes throughout the design cycle, security that was properly implemented at the beginning of the design may become irrelevant by the time the product goes into production.
The primary concern is to incorporate risk analysis and security considerations into each step of your product’s development life cycle. Five principles, which are based on recommendations from the National Institute of Standards and Technology, serve as a good checklist. For more information, refer to “Engineering Principles for Information Technology Security (A Baseline for Achieving Security)” by G. Stoneburner et al. Let’s take a look at each one.
First, treat security as an integral part of your overall product design. It’s extremely difficult to implement security measures properly and successfully after a system has been developed.
Second, reduce risk to an acceptable level. Elimination of all risk is not cost-effective and likely impossible because nothing is 100% secure. A cost-benefit analysis should be conducted for each proposed secure hardware mechanism to ensure that it is performing its intended task at a desired cost.
Next, implement layered security. (Ensure no single point of failure.) Consider a layered approach of multiple security mechanisms to protect against a specific threat or to reduce overall vulnerability.
Fourth, minimize the system elements you’re relying on. Security measures include people, operations, and technology. The system should be designed so that a minimum number of elements need to be trusted in order to maintain protection. Put all your eggs in one basket by isolating all critical content in one secure area (physical or virtual) instead of having multiple secure areas throughout the design. This way, you can focus on properly securing and testing a single critical area of the product instead of numerous disparate areas.
Finally, don’t implement unnecessary security mechanisms. Every security mechanism should support one or more defined goals. Extra measures should not be implemented if they do not support a goal because they could add unneeded complexity to the system and are potential sources of additional vulnerabilities.
KEYS TO THE KINGDOM
Understanding and evaluating the risks and threats against your product is the first step toward a successful secure hardware design. There are many combinations of potential vulnerabilities, and it’s impossible to prevent against all of them. The good news is that vendors have recognized the need for embedded security, and we’re starting to see ICs and modules that reflect that. The more you can spread the word to your colleagues about making secure products, the safer all of us will be.
I’ve just started to scratch the surface of the embedded security topic. In a future article, I’ll take a no-nonsense look at a wide variety of practical secure hardware design solutions that you can implement in your product.
REFERENCES
[1] D.G. Abraham et al, “Transaction Security System,” IBM Systems Journal, vol. 30, no. 2, 1991, www.research.ibm.com/journal/sj/302/ibmsj3002G.pdf.
[2] P. Kocher, “Crypto Due Diligence,” RSA Conference 2000.
RESOURCES
C.P. Pfleeger, Security in Computing, 2nd ed., Prentice Hall, 2000.
G. Stoneburner et al., “Engineering Principles for Information Technology Security (A Baseline for Achieving Security),” NIST Special Publication 800-27, June 2001, csrc.nist.gov/publications/nistpubs/800-27/sp800-27.pdf.
AUTHOR
Joe Grand specializes in embedded system design, computer security research, and inventing new concepts and technologies. Joe holds a B.S.C.E. from Boston University. This article first appeared in Circuit Cellar 169, 2004.
Sponsor this Article
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
