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
Flexible support for built-in hardware crypto- and hash algorithms
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.