Securing Highly Sensitive Assets in Embedded Devices Marcel van Loon AuthenTec

Explore AuthenTec IP here

The need for Security in Embedded Devices

Lots of devices these days rely on the use of secret data to execute their intended function. For instance, devices require secret data to:

• Get access to the service network that they are part of, for example:
  • to access a mobile network
  • be able to decrypt Conditional Access media
  • to access a bank’s remote banking server
• Offer certain security services to their users, such as:
  • Secure storage and access control to user passwords, licenses, or loyalty data
  • Encryption of removable storage data such as hard disks or USB memory sticks
  • Allow remote access to, and secure communication with, a company network
• Ensure their own operational integrity, through:
  • Booting from authenticated and encrypted boot software
  • Running only authenticated programs
  • Securely storing device-specific data such as :
    • Configuration- and feature enablement settings
    • Operational parameters (e.g. Radio transmitter settings)

Apart from the fact that the items above require the protection of certain secret data from ‘some’ attacker, it is good to recognize that the different items represent:

• Interests from different parties (mobile operator, device user, and device manufacturer)
• Different monetary or perceived value (free mobile access, device software theft or hacking, and identity theft)

In other words, a single device may have to protect data belonging to different parties, as well as data that has different value to different people (both data owners and attackers), which means that the amount of effort spent to protect a piece of data, as well as the amount of effort that can be expected to be spent on attacking the data, can differ greatly. If you add to that the observation that in a lot of cases, the party whose data needs to be protected, is not the party paying for its protection, you start to get a grasp of the interesting security landscape that a lot of devices have to deal with.

Recognizing the different threat models, key owners, and key usage scenarios, it will be clear that the device will have to be able to deal with different levels of protection to balance usability, protection cost and security of the sensitive data it holds.

Just as the attacker has different methods at his disposal to attempt to attack the device, so does the device, to protect itself. For instance it can limit access to sensitive data through:

• Restricting the physical location of plaintext key material, e.g. by keeping the data:
  • Inside a secure execution environment
  • Inside the chip package
  • Only temporarily visible in off-chip memory
• Restricting access to key material:
  • Based on cryptographic mechanisms and secret- or preshared key material, such as login credentials, public/private key pairs or internally generated secret key material
  • Based on application separation provided by an OS kernel or Hypervisor
  • Based on (system) mode of operation (boot, debug, mission mode)
  • Based on processor mode of operation (Secure vs. Normal, Privileged vs. Restricted)
  • Based on physical device (Baseband Processor vs. Application Processor)

The device can also deploy attack detection mechanisms (anti-tampering technology) and act upon the detection of a tampering attempt by destroying sensitive data.

Clearly the different protection mechanisms provide different levels of protection against different types of attacks; for instance keeping data inside an (on-chip) secure execution environment protects the data against PCB-level attacks and logical attacks (from other SW running inside the chip) but not necessarily against intrusive- or destructive attacks.

A protection mechanism almost always comes with an associated cost, not just in terms of device complexity but also in terms of the usability of the material. In the secure execution environment example, the additional cost comprises the need for a separate (isolated) processor with its infrastructure (device complexity), but it also requires any application that needs to access or use the data inside the secure execution environment, to be ported (at least partially) to run inside that environment.

AuthenTec SafeZone Secure Platform

The previous chapter illustrates the complexity of the security playing field, for devices containing and protecting data they cannot allow falling in the hands of an attacker. The device will have to recognize different levels of security and attempt to successfully combine these with other design constraints such as usability, complexity as well as manufacturing, provisioning and maintenance cost. This requires a robust and flexible security architecture that must be adaptable to the device needs during every stage of its lifetime.

To help the device Security Architect, AuthenTec has developed a comprehensive Secure Platform to act as the foundation for a security architecture that can be tailored to meet the protection requirements the Security Architect needs. The Secure Platform provides the cryptographic building blocks, as well as the so-called ‘trust anchors’ in hardware, to allow the Security Architect to implement comprehensive security architecture without having to bother with the complexities of low-level cryptographic operation and key management.

The AuthenTec SafeZone Secure Platform comprises of three main components:

• The SafeXcel EIP-123 Crypto Module hardware, to provide the cryptographic acceleration and the ability to put a root of trust in hardware, and to provide the trusted execution environment for the Asset Store (below).
• The SafeZone Software, to allow efficient use of the hardware and to provide higher level services using, if needed, the trust anchors provided by the hardware and the Asset Store.
• The Asset Store, implemented as firmware inside the Crypto Module but also available as software component, to provide key management, storage and access control to key material, protected by hardware.

Asset Store Features

The key feature of the Asset Store is its ‘key lock box’ function, which

• Keeps plaintext key material, once imported or generated within the Asset Store, inside the secure execution environment offered by the Crypto Module.
• Provides the ability to securely store key material in off-chip Flash memory, cryptographically protected in such a way that only the device that ‘owns’ the stored keys, can use them.

Protecting key material requires more than just the capability to store the key material behind some fence. Having key material makes no sense if the keys cannot occasionally be used securely as well. However, if the protection of the key material also needs to be extended to cover the secure usage of the keys, then care must be taken that:

• The keys are only used according to the (user) access policy set by the key owner
• Keys can only be used by the algorithm they are intended for
• Any intermediate material produced or required by the algorithms that may contain information on the key material, must be protected as well (e.g. keyed hash state, stream cipher algorithm state, derived key material)

Figure 1 AuthenTec Secure Platform Asset Store

SafeZone Software features

SafeZone Software is designed to allow easy integration into the customer application environment, and to unlock the powerful features offered by the Asset Store, through a well known, publicly available, API.

Some of the key features of the SafeZone Software are

• PKCS#11 API to applications
• Fully integrated with key protection and usage mechanisms offered by Asset Store
• Comprehensive Cryptographic library
• Secure Boot library
• Secure Storage library
• Digital Certificate library
• Hardware enablement for SafeXcel Trusted/Crypto Module
• Easy adaptation to target hardware and software environment

Figure 2 SafeZone Software Libraries

Crypto Module Hardware features

• ROM code controlled operation- not possible to influence from external processors
• All key material used by the algorithms present inside the module – no external key exposure
• Ability to cooperate with multiple hosts using separate mailbox (control) interfaces, and support priority/Quality of Service support
• Built-in public key and TRNG support
• Low power – support for active clock control
• Low gatecount
• Flexible support for built-in hardware crypto- and hash algorithms

Figure 3 SafeXcel-EIP-123 Crypto Module

Read the White Paper: Securing Highly Sensitive Assets with AuthenTec's SafeZone Secure Platform

Explore AuthenTec IP here

• EIP-123: AuthenTec (SafeNet) SafeXcel-IP-123 Secure Platform Crypto Module; Embedded Security Solution for Mobile & Consumer applications
• EIP-76: AuthenTec (SafeNet) SafeXcel-IP-76 FIPS 140-3 compliant True Random Number Generator
• EIP-150 AuthenTec (SafeNet) SafeXcel-IP-150 Public Key Accelerator Family

About the Author

Marcel van Loon
Solutions Architect
AuthenTec

Mr. van Loon is Solutions Architect for the Embedded Security Solutions group of AuthenTec, Inc. He has over 14 years of experience in embedded security, ranging from high speed cryptographic protocol acceleration to low power, high security embedded systems. Mr. van Loon holds an Electrical Engineering Degree from the Eindhoven University of Technology in the Netherlands.