Building a security-optimized embedded design using protected key storage

Editor’s Note: In this Product How-To article, Todd Whitford and Kerry Maletsky of Atmel Corporation describe the many ways in which the security of an embedded microcontroller design can be compromised and how to use the company’s ATSHA204 authentication device to protect critical system IP.

How much security can you afford to add to your next design? In many cases, equipping an embedded system to protect its proprietary intellectual property (IP) and the data it’s entrusted with represents only a small fraction of the unit’s overall cost. But can you afford even this small increase and still remain competitive in the unforgiving global technology market?

Or, is it better to ask if you can afford not to include it? Many incidents occurring throughout the high-tech economy illustrate some of the challenges embedded systems designers face in defending their products and the customers who use them against sophisticated attacks. Many of these are various forms of cyber-theft that seek to extract the information stored or transported by an embedded system. Once limited to simply pirating copyrighted movies, audio, and other multimedia, IP theft has evolved rapidly over the last decade as industrial spies and other cyber criminals have learned to extract the firmware, FPGA code, and other details of a product’s design for their own use or sale to the highest bidder.

Some of the most common ways that stolen IP can undermine both the immediate profits and long-term success of legitimate manufacturers include:

Hardware cloning A time-honored tradition in black-market electronics whereby a product’s circuit boards, components, and often even its mechanical design are copied and used to produce unlicensed knock-offs. Modern cloning practices usually include use of pirated firmware and FPGA code. When grey-market manufacturers begin selling unauthorized knock-offs of propriety peripherals and accessories (ink cartridges, cables, batteries, and other consumables), the OEM loses a reliable revenue stream.

Overbuilding A relatively recent variant of cloning in which an authorized third-party assembly facility deliberately builds more units than a client has ordered with the intent of selling them through alternate channels. Unless a product was designed with provisions to secure it against this practice, overbuilding is nearly undetectable.

Reverse engineering Even if a competitor does not produce a copy of your product, stolen IP can allow them to inexpensively acquire proprietary technologies and features which give your products market differentiation.

Shortened design cycles Pirated designs allow would-be competitors to bring their products to market quickly, reducing the time an innovative company gets to enjoy the marketing advantages and premium pricing that a product’s unique features make possible.

Developing a complete security strategy
A complete security strategy must address traditional security concerns about securing the system’s wired and wireless network connections. Authentication of network nodes, encryption of network data, message integrity protection, secure key management, and other traditional (but often overlooked) security measures are necessary. After all, your customers won’t buy products unless they know their data, services, and infrastructure will be protected against intrusion, theft, and sabotage.

A number of techniques are available to inject malicious code during routine software upgrades. Once inside your system, the new code can turn into a convenient point of entry to your customer’s (or your) network that can be used to gain access to sensitive consumer and corporate data.

The same techniques can be also used by those with more sinister intent to do physical harm. Several Pentagon studies and recent real-world incidents such as the Flame and Stuxnet viruses should serve as clear warnings that cyber-terrorism is a real possibility – especially in applications involving public infrastructure (utilities, communication, transportation) or mission-critical systems (medical, industrial control).

Part of the design process is to decide which of the issues listed above apply to your product and whether they are a primary or secondary requirement. Once the product’s security requirements are defined, they can be used to develop a security strategy which serves as a tool for selecting the technologies and products best-suited to meet the application’s unique combination of threats, performance requirements, and cost constraints. The security strategy should also consider whether the security solutions must be capable of being updated to deal with new threats as they emerge.

Depending on the level of security and performance required by your application, you can protect your system using a strategy based on software, hardware, or a mixture of both. Each of these strategies has its own unique advantages and drawbacks.

No security The simplest strategy is to not include any security in a design. In certain cases, the lower bill of material (BOM) and manufacturing costs, faster time-to-market, and lighter microcontroller (MCU) workload in the absence of security-related software outweigh the hidden costs of leaving a product vulnerable to hacking. But since some basic security measures can be implemented at little or no cost, few, if any, applications can afford to ignore security altogether.

Software-only solutions If the existing MCU has sufficient memory and processing cycles to support it, a security algorithm can be implemented in software. In most software-only security solutions, critical items such as secret keys are stored in the MCU’s existing memory resources (EEPROM, Flash).

  • Advantages: These solutions are often perceived to be free, although they may have hidden costs due to additional development time and cost.
  • Disadvantages: Storing keys in unsecured memory resources puts them at risk of exposure. In addition, many firmware or software implementations of cryptographic algorithms are vulnerable to attack due to performance tradoffs, code size reduction efforts, use of general purpose hardware, and/or errors in the code.


Software/hardware hybrid solution (e.g. hardware on client, software on host)
  A client-side system’s MCU can be augmented with a hardware security device that provides secure key storage and implements some, or all, of the security algorithm in hardware.

  • Advantages: Lower overall solution cost because no security device is required on host.
  • Disadvantages: In this solution, the host-side system’s keys are stored in an unsecured resource, putting them at risk for interception, theft, or alteration. In addition, the software for the host-side algorithm may contain flaws in its implementation which leave it vulnerable to hacking techniques.

Defendable hardware-based solution   An all-hardware solution includes tamper-resistant secure key storage devices used at all critical points in the system.

  • Advantages: With its keys securely stored in a hardened device specifically designed for the purpose and its security algorithm implemented in hardware, the resulting system is much more resistant to hacking without burdening the host processor. In addition, the development time required to bring a fully tested verified product to market is dramatically shortened.
  • Disadvantages: Many designers avoid all-hardware solutions because they are perceived as adding potentially unnecessary cost to a design.

Implementing security strategy
Protecting a system against intrusion and data theft requires providing appropriate levels of both design security (protecting a system’s software and other critical details about its design) and data security (protecting the information stored in or transported by the system).

Failing to do so can expose your system to various types of attacks which seek to extract the information stored or transported by an embedded system. In many cases, the information contained in leading-edge products is pilfered by hackers serving second-tier manufacturers (often located offshore) who are employed to produce copycat products–or as an inexpensive alternative to doing their own R&D. The resulting over-builds, cloned products, and unauthorized knock-offs of propriety peripherals and accessories can erode or eliminate a manufacturer’s profits.

Secure key storage is a highly cost-effective approach to security that provides many of the same attributes of a fully-hardened system at a much lower solution cost. These systems use an inexpensive key management and storage device which can be paired with virtually any MCU to create an embedded system that is highly-resistant to the attacks commonly used to steal sensitive data, software, and other types of IP.

A closer look at secure key storage  One example of an advanced secure key storage solutions is the Atmel ATSHA204 , an authentication device that includes a 4.5Kb EEPROM. Its secure memory can be used to store encryption keys, perform miscellaneous read/write or read-only memory operations for managing passwords or secret data and consumption tracking information.

Access to the various sections of memory can be restricted in a variety of ways and then the configuration can be locked to prevent changes. The device features a wide array of defensive mechanisms specifically designed to prevent physical attacks on the device itself or logical attacks on the data transmitted between the device and the system.

Each ATSHA204 ships with a guaranteed unique 72-bit serial number. Using the cryptographic protocols supported by the device, a host system or remote server can prove that the serial number is both authentic and not a copy. The ATSHA204 can also generate high-quality random numbers and employ them for any purpose, including use by the device’s own crypto protocols. Its flexible command set makes it easy and cost-effective to use in many applications, including anti-counterfeiting, protection for firmware or media, secure data storage, user password checking, and session key exchange.

The secure storage device’s basic functions enable many sophisticated security capabilities such as:

Secure boot Ifan embedded device’s operating program is stored in an external Flashdevice, it's hard to prevent its contents from being copied and modifiedto run a fraudulent program. The ATSHA204’s secure authenticationcapabilities can be used to implement a secure boot function whichensures that only the manufacturer’s authenticated firmware can be runon the system.

To implement secure boot, a validating code orsignature is stored in flash along with the boot code. The signature iscreated at the time of manufacture or code update and is the output of acryptographic hash function, an irreversible algorithm that condensesthe operating code into a compact but unique digest, typically 32-128bytes in length.

At system start-up, part of the boot sequencerequires the security device to verify the signature accompanying theboot code. Only if the verification succeeds will the operating programbe executed, allowing the system to operate in the normal way. Evenmodifying the operating program by a single bit will require a newvalidating signature. Both code images and downloaded media files can bestored using an encryption key which, if desired, can be usable only ona single authenticated system.

Secure session key exchange Inorder to manage a confidential communications channel, a host systemand its client exchange stream encryption keys in a secure manner. Thekeys are then used by a symmetric encryption/decryption engine in thesystem microprocessor such as AES or DES. The ATSHA204 can facilitatesecure key exchanges by using the unique response it produces as the keyto the symmetric encryption algorithm.

A random number is usedin the encryption key’s generation process. This can be supplied by theATSHA204’s on-chip random number generator. The key exchange is thenperformed by sending a random challenge to the Host ATSHA204, which inturn generates a response. The host’s response is used as a session-keyfor encrypting the message. The message and the random number are thensent to the client ATSHA204.On the client side, the random number is fedinto the ATSHA204 device to generate the response which is used as thekey to decrypt the message. It should be noted that the root key is thesame on both the host and client and never leaves the ATSHA204 device.

Figure 1: Secure session key exchange

Asimilar process can be used to encrypt firmware being downloaded to anembedded system. In this case, the random number (or seed) used togenerate the encryption session key is transmitted along with theencrypted firmware. When the system receives the encrypted firmware, ituses the received seed to generate the decryption key and then decryptsthe firmware.

Host/client authentication Wirelesstransmission devices must verify each node prior to allowing access tothe network. ATSHA204 devices in each radio node (Client), allows thetransmitting node (Host) to verify that it is communicating with validnetwork nodes before transmitting important commands or information.Adding an ATSHA204 device to each node provides safe storage of keysand/or data.

Figure 2: Host/client authentication

Inthe next section, we’ll look at several specific use cases for securekey storage based on Atmel’s ATSHA204 CryptoAuthentication device.

Use models for secure key storage technology
1. Firmware IP protection   Protectingflash-resident firmware that may contain proprietary algorithms orother IP against theft can be accomplished by encrypting it before it isstored. A secure key storage device such as the ATSHA204 manages thekeys that the system MCU uses to decrypt the firmware and otherinformation stored in flash memory.

If required, the ATSHA204can also be used to implement other measures which provide additionallayers of protection against software theft. These include:

  • Multiple challenge-response pairs
  • Chaining challenge-responses
  • Periodic/random challenge responses during operation
  • Computing the challenge on the fly
  • Encrypting blocks of executable code that rely on each decrypted block for successful operation

2. Consumable authentication/anti-counterfeiting and anti-cloning   Inthis use model, the ATSHA204 device is used to validate that aremovable, replaceable, or consumable client product is authentic. Thefollowing scenario illustrates how a simple and inexpensive cryptodevice such as the ATSHA204 makes it possible to ensure that onlyauthentic ink cartridges, air filters, medical consumables, etc. areaccepted and will function with authorized OEM systems.

Figure 3: Consumable authentication/anti-counterfeiting and anti-cloning

Foranti-counterfeiting and/or anti-cloning applications, the device isembedded in the consumable (Client). When the consumable is installed orfirst used in the system (Host) it’s sent a challenge from the Host inthe form of either a fixed or random value. Once the Client receives thechallenge, its ATSHA204 security device calculates a response value andsends it back to the Host where it is compared with the expected value.Only a consumable that provides the expected response can be used inthe system. This type of consumable authentication system is aninexpensive way to ensure that both your customers and your revenues areprotected.

3. Accessory authentication   A similarapproach can be used to make sure your system will work only withmanufacturer-authorized plug-ins, cables, batteries, or otheraccessories. In some cases, the primary damage caused by knock-offaccessories such as power supplies, speakers, or specialized cables islost revenue. In other cases, an unauthorized accessory such as abattery, surgical instrument, or medical device which does not fullymeet OEM requirements has the potential for causing serious harm.

Inthese applications, the ATSHA204 device in the host generates a randomchallenge for the client (accessory) and evaluates its response. Inaddition, since the host’s challenge is generated internally using theATSHA204, even the host processor is unaware of its response. Isolatingthe processor from the security function enables the use of aninexpensive non-security-hardened processor without providing a weakpoint through which an attacker can extract the system’s secrets.


Figure 4: Accesssory authentication

4. Preventing cloning, over-builds, and other types of firmware theft   Inhighly-competitive markets, a product’s firmware is often one of itskey differentiators and must be protected against exposure and resultingtheft for use in gray market knock-off products. In these applications,challenge-response functionality, diversified key schemes, rollingkeys, and other protections are implemented to thwart would-be thieves.

Conclusion
OEMscan no longer afford to ignore security or count on “security byobscurity” to protect their products. IP theft has become a majorindustry, with skilled teams of engineers extracting software, FPGAcode, and even entire designs, which are then used to produce cut-rateproducts that eat into a legitimate manufacturer’s sales and possiblytheir reputation. Producers of copyrighted audio, video, and otherlicensed IP are being similarly impacted by both amateur andprofessional data pirates. Worse yet, the cost of lost markets,tarnishing of a company’s brand image, and product liability issuesresulting from failure to properly secure an embedded system can produceeven larger, more persistent impacts to a company’s revenue stream.

Thegrowing presence of embedded systems in nearly every type ofinfrastructure and mission-critical equipment also makes them anattractive target for cyber-criminals bent on either profit or mayhem.Meanwhile, increased use of networking technologies provides would-behackers with a potentially convenient means of entry.

Fortunately,today’s silicon manufacturers have developed an arsenal of versatiletools and products that greatly reduce the cost and difficulty ofimplementing security. Once a designer clearly identifies the level ofsecurity their application requires, they can explore a spectrum ofsolutions to find the one that meets the price and performance goalsappropriate for their target market.

Kerry Maletsky isa Senior Product Line Director at Atmel with over 30 years experiencein the semiconductor industry. Prior to joining Atmel, Mr. Maletskyworked for a number of high tech companies including Bell Labs andSimtek Corporation. He has worked in a variety of areas, including highend microprocessors, computer aided design software, and high securitycryptographic devices. He received his BS in Electrical Engineering andhis MS in Computer Science from Stevens Institute of Technology in NewJersey. He holds 12 patents.

Todd Whitford is a Product MarketingManager for CryptoAuthentication products at Atmel Corporation. He hasmore than 25 years experience in the semiconductor industry, duringwhich he has held a variety of management positions in operations andmarketing. He holds a B.S. in Engineering from San Jose StateUniversity.

2 thoughts on “Building a security-optimized embedded design using protected key storage

  1. “After having invested so much onto a product, why not go the extra mile and embed security features onto it as well? It is only a single step more to go in order to ensure that no breaches could take place and destroy all your past efforts. This isn't som

    Log in to Reply
  2. “This was a very interesting module for me. It's really quite wonderful to see how such a simple concept is penned down to illustrate what is really needed to provide a secure network for your business and communications framework. Hopefully I will be able

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.