SECURITY CHALLENGES IN EMBEDDED DESIGNS

Eran Rippel
Discretix Technologies, Ltd.

ABSTRACT
We present several use-cases where embedded security is a fundamental
requirement. For each use-case, we list a set of security-related
characteristics and translate these characteristics into security requirements.
We continue by analyzing the security requirements and identifying the
embedded security building blocks of each one. The information for each
use-case is presented in a tabular format combined with detailed analysis,
facilitating easy reference per specific use-case.

1 INTRODUCTION
Security is becoming a de-facto requirement in the embedded industry, where system integrity,
content and connectivity are gaining increasing market attention. This naturally leads to security
accounting for a more significant share of embedded designs cost. At the same time, with the
prevalence of software there is also a need to meticulously build a design to guarantee the security,
authenticity and availability properties of the overall solution.
In this paper we analyze the following use-cases where security challenges are involved:
 Software integrity protection
 Software IP protection (reverse-engineering protection, anti-cloning)
 Secure information and data logging
 Preventing use of non-original peripherals
 Secure communication
 Digital Rights Management (content protection)
 Multi-CPU System-On-Chip
For each use-case, section ‎2 lists the various security requirements and maps those to security building
blocks. Section ‎3 provides a more in-depth description of each security building block.

2 USE-CASE ANALYSIS
In this section we examine various security use-cases. We begin by taking each use-case and listing the
set of security-related characteristics that must be provided to support the use-case. We then take
each characteristic and translate it into distinct security requirements. Finally, we take each identified
security requirement and list the embedded security building blocks that must be in place in order to
answer that security requirement.

2.1 SOFTWARE INTEGRITY PROTECTION

Software resides on a permanent external storage device (e.g. external flash), which is relatively easy
to access by simple off-the-shelf tools. An attacker can replace parts of the software image or the
entire software image on external storage, causing the CPU to execute software which was not

January 2009 Page 1 of 16

 Security Challenges in Embedded Designs

originally provided or approved by the manufacturer. Such software modifications can cause a wide
range of undesired system behavior. The result can vary from simple loss of revenue to hazardous
unintended behavior malfunctions.
The manufacturer introduces software to the system at two distinct occasions. During manufacturing,
the manufacturer introduces software to the device by programming the flash memory. At a later
stage, the manufacturer can update the software image on flash by means of a secure software update
session. The requirement is to maintain the integrity of the manufacturer software on both occasions
and this is done by assigning a unique signature to the manufacturer’s software.
The unique signature over the software image is based on public key cryptography. A unique digest (e.g.
hash) value is calculated over the software image and the manufacturer uses its private key to sign the
software image hash. The software image and its signature are then loaded to the system during
system manufacturing, along with the associated manufacturer’s public key. Whenever there is a need
to authenticate the software image, a digest of the software image is calculated and the public key is
used to authenticate the private-key-generated signature. Any piece of software not signed by the
manufacturer is detectable at a later stage as non-authentic software.
Secure Key Storage must store the public key and protect it against modifications, otherwise the
authentication mechanism can be easily broken. An attacker interested in injecting a new software
image can randomly create a new private-public key pair. The attacker then uses the private key to sign
the new software image (in the same manner as the manufacturer does) and loads the new software
image, new signature and the matching new public key to the system. During such an attack, the
authentication scheme passes successfully, as the public key used for authentication matches the
private key which was used to sign the software image. This attack is foiled by storing the public key in
a secure key storage area. This prevents an attacker from loading a different public key to the device.
There are many options for secure manufacturer public key storage. The public key can be stored in on-
chip ROM – there is a clear advantage that the public key cannot be replaced, but also the
disadvantage of lack of flexibility – all systems have the same public key, meaning that all
manufacturers must use the same private key to sign the software image. A second option is to store
the public key in on-chip One-Time-Programmable (OTP) technology – the advantage here is flexibility,
where each chip can have a different public key, but carries the disadvantage of silicon area cost of a
large number of OTP bits. A remedy for that is a third option, where the public key is stored on external
flash, but a hash value of the public key is stored in on-chip OTP – maintains the solution flexibility but
dramatically reduce the number of required OTP bits.
Detection is carried out primarily by a Secure Boot function at boot time – during system boot the
software image is authenticated versus its signature. The Secure Boot function is an on-chip ROM-
based procedure, which carries the above-mentioned authentication scheme. The reason the function
must be ROM-based is so that an attacker cannot intercept the procedure and so that authentication is
always carried during boot, bringing the system to a known and trusted starting point. Whenever the
manufacturer wishes to update the software image on flash, best practice is to do so at Secure Boot
time, because at this point in time the system is at a known state for the update to commence.
An attacker is also likely to attempt to modify the software while the system is running. There is a need
for Run-Time Integrity Checking (RTIC) capability, which periodically authenticates the software image
post-boot, either directly on XIP NOR flash or on external RAM for NAND flash implementations. RTIC
January 2009 Page 2 of 16
 Security Challenges in Embedded Designs

operation is similar to Secure Boot operation, with slight modifications to accommodate runtime
changes. RTIC function must run in a Secure Execution Environment (SEE) with its own dedicated RAM,
where it is guaranteed that the RTIC functionality has not been tampered with by an attacker.
Considering that an attacker can attempt to modify the RTIC code or the procedure that calls the RTIC
in the first place, it is evident that the RTIC must run in an SEE. The SEE must also maintain a Secure
Timer, which periodically triggers the RTIC function.

Software Integrity Protection Requirement

Enable the manufacturer to introduce software
●
Bring system to a known and trusted starting
point at boot ● ●
Detect if software has been modified during
runtime ● ●
Enable secure update of the software image
● ●
Unique software signature

Boot-time Integrity Checking

Run-Time Integrity Checking

Secure software update

Security Requirement

Security Building Block

● ● ● ● Cryptographic algorithms
● ● ● ● Secure Key Storage
○ ○ ○ Key Management
○ ○ ○ Software Version Revocation
● ● ● Secure Boot
● ● ● Dedicated ROM
● Secure Execution Environment
● - mandatory ● Dedicated RAM
○ - optional ● Secure Timer

Optional mechanisms helpful for software integrity protection include a mechanism for Key
Management, in situations where more than one private-public key pairs need to be supported (for
example, to enable private-public key pair revocation for stolen keys). A Software Version Revocation
mechanism is important for long-lived systems, where the manufacturer may want to advance the
system to a new version of the software and prevent roll-back to an older version. In such a case a
software version counter is tied as part of the Secure Boot signature, enabling this mechanism.

January 2009 Page 3 of 16

 Security Challenges in Embedded Designs

2.2 SOFTWARE IP PROTECTION

The software code image that the CPU executes may contain valuable IP and know-how, which the
device manufacturer wishes to protect. Protection is required both against cloning of the system (anti-
cloning protection), as well as against reverse-engineering of the software. Cloning provides the
attacker with the ability to create a copy of the device, which would result in loss of revenue to the
original manufacturer who cannot sell its own device. Reverse-engineering carries an even greater
penalty, as the attacker is gaining access to the manufacturer knowledge base, and is able to build
many competing devices, not just the specific device where the IP was stolen from.
As mentioned, the software resides on an external storage device, which is relatively easy to access. An
attacker can copy the software image, as well as reverse-engineer the software to reveal the
manufacturer’s ideas and know-how. A starting point for protecting the software image is by means of
code encryption, such that the attacker doesn’t have access to the encryption key. Access must also be
prevented to the plain code itself once decrypted, when it is located in on-chip RAM.
The encryption key used to encrypt the software image must be stored using a Secure Key Storage
mechanism. At the basic level, key storage can be with on-chip ROM (less flexible) or One-Time-
Programmable (OTP) bits. Optionally, for more advanced systems which handle a large number of keys,
keys are better handled using a full Secure Storage solution based on a Unique Secret Key, with a Key
Management function to handle all key material (see section ‎3.2)
Finally, the code encryption key must be loaded into the system, as well as the encrypted software
image. Key material is loaded using a Provisioning mechanism. Provisioning refers to the
manufacturer’s ability to load data into the system in a secure manner, even when manufacturing is
performed in unsecure locations. Provisioning is necessary both for loading the encryption key as well
as loading the code image. The code image can be pre-encrypted and loaded already encrypted to the
flash, or loaded plain to the flash and encrypted during the system’s first boot.
Once the image is ready encrypted on flash, there is a need for fast on-the-fly code decryption. On-the-
fly refers to the capability to decrypt the code as it is being read from external storage and into on-chip
RAM. Fast decryption is required in order to add minimal stalls to the system performance. As with the
code encryption phase, the encryption key must be available for the decryption engine.
The manufacturer can update the software image on flash at any point in time by means of a software
update session. This requirement has been discussed in the previous section for when the update
software already arrives encrypted. Otherwise, the only difference here is that the update session
includes an encryption phase.
An attacker might also try to extract IP by probing internal RAM, where the code resides in plain form,
using the chip JTAG interface. The requirement here is to provide JTAG debug interface protection.
Debug port protection is carried out by a dedicated Secure JTAG unit, which resides on the JTAG entry
point. Whenever a technician is interested in debugging the chip, the technician uses the debug tool to
ask the on-chip Secure JTAG unit to send a challenge (based on a cryptographic scheme). The challenge
is received by the debug tool and if it is an authorized debug tool then the debug tool is able to create
the appropriate response to authenticate itself. The secret for the authentication protocol must be
provisioned to the chip at an earlier stage, similar to key provisioning described above.

January 2009 Page 4 of 16

 Security Challenges in Embedded Designs

Software IP Protection Requirement

Prevent an attacker from reading plain
software code from external storage device ● ●
Prevent an attacker from reading plain
software code by bus probing on PCB ● ●
Maintain CPU performance characteristics
even when IP protection mechanisms exists ●
Prevent an attacker from accessing chip
debug port ●
Coupling a CPU software image on external
storage device to a specific CPU ●

Code encryption

Secure software update

On-the-fly code decryption

Debug port protection

Unique chip identification

Security Requirement
Security Building Block
● ● ● ● ● Cryptographic algorithms
● ● ● ● ● Secure Key Storage
○ ○ ○ Key Management

○ ○ ○ Secure Storage

● Secure Boot
● Secure JTAG Mechanism
○ Life Cycle State Management
● ● ● Provisioning
● - mandatory ○ ○ ○ ● Unique Secret Key
○ - optional ● Dedicated ROM

Once authenticated, the Secure JTAG unit opens the JTAG chains and enables debugging of the chip. An
attacker would have a hard time accessing JTAG chains and internal RAM when such a mechanism is in
place.
Optionally, the Secure JTAG can rely on a Life Cycle State Mechanism. The Life Cycle State mechanism
is a one-way function which indicates the current system state (e.g. development, production, user,
end-of-life, etc). When the system is in development, a developer would not want to perform the
challenge-response procedure every time. The Secure JTAG mechanism can hook to the Life Cycle State
indication and since development stage is carried out in a secure environment, disable the JTAG
protection.

January 2009 Page 5 of 16

 Security Challenges in Embedded Designs

Even if the code image is encrypted, the code image is not tied to a single chip or a single CPU.
Therefore, cloning the system is possible by copying the code image as is and running it on an identical
chip over the cloned system. Since the cloned chip CPU knows how to read the encrypted image,
cloning at the system level is possible. The attacker doesn’t understand the code that is executing on
the CPU, but gets the expected behavior out of the CPU. The solution here is to use a Unique Secret
Key per a specific chip and tie the chip’s code encryption to this unique key.

2.3 SECURE INFORMATION AND DATA LOGGING

Secure logging of information and data is an essential system property. Some pieces of information
require only protection against modification (e.g. identity), while other items in the database also
require protection against reading (e.g. private keys). Implications of not enforcing access restrictions
on such pieces of information range from commercial fraud to legal repercussions.
The basic requirement for secure information logging is to provide a Secure Storage database. The
Secure Storage is based on a unique secret key stored by a Secure Key Storage mechanism and
cryptographic algorithms which provide the security infrastructure, which will be discussed shortly.
Throughout this paper we outline mechanisms which are based on secret encryption keys. Each such
key can be stored using on-chip ROM or OTP bits, although such solutions are either inflexible (ROM)
or costly in terms of OTP silicon space. The system approach to alleviate the large on-chip storage
requirement is to use a Secure Storage database, which is based on a single on-chip unique secret key.
The Secure Storage database can store an unlimited number of keys or any other data items. Secure
Storage creates a hierarchical approach, where one on-chip key protects a large number of off-chip
keys.
Maintaining high-reliability of the underlying database is of key importance. Two features providing for
high-reliability are the ability of the database to correct itself against unexpected errors. For example,
unexpected power-loss can render the database at an unknown state. An application error can also
have a similar effect, resulting in a corrupted database. Protection against unexpected errors can be
accomplished by journaling methods, where a journal of database transactions is maintained. Such
journaling methods can facilitate database roll-back capability, as well as unexpected power-down
recovery. Even when using such techniques, it is important to remember that we are discussing a
secure database, where the database is constantly protected for its integrity. Every update to the
database also requires updating the integrity mechanisms.
Attacks on the database can occur off-line or on-line. An off-line attack involves reading or modifying
the database on the external storage device (most likely flash) while the system is powered-down. In
order to prevent reading database items, the database should employ encryption methods to provide
data confidentiality. In order to prevent modifications of database items, the database should employ
digest methods to provide data integrity. Both the confidentiality and the integrity of the database are
based on encryption keys and therefore require Secure Key Storage capability. If the attacker doesn’t
know the encryption keys, the attacker cannot decipher the database items, nor break their integrity
without being detected. In order to raise the security barrier further, it is best to use hardware-based
key storage techniques (e.g. OTP), which provide significant improvement in the level of security
compared to software-based techniques.

January 2009 Page 6 of 16

 Security Challenges in Embedded Designs

Secure Information and Data

Logging Requirement
Provide high-reliability storage
● ● ● ●
Protect stored data against
unauthorized off-line modification ● ● ● ●
Protect stored data against
unauthorized on-line modification ● ● ● ●

Provide a secure database

Protect against power failures

Protect against application errors

Database integrity

Database confidentiality

Hardware-based database security

Debug port protection

Database access control

Security Requirement
Security Building Block
● ● ● ● ● Cryptographic algorithms
● ● ● ● ● Secure Key Storage
● Secure Storage
● ● Roll-back capability
● ● Unknown-state recovery
● Re-flash protection
● Secure JTAG mechanism
○ Life Cycle State Management
● Provisioning
● Process Caller ID
● Secure Execution Environment
● - mandatory ● Secure Boot
○ - optional ● Dedicated ROM & RAM

In order to prevent on-line database modification, a secure JTAG mechanism must be employed. This
mechanism has been discussed earlier in this paper. Furthermore, the software handling the Secure
Storage database must be isolated and executed in a Secure Execution Environment (SEE) with its own
Secure Boot function and dedicated ROM & RAM, so that all key material is handled in a trusted
compartment. The Secure Storage database should be integrated with the operating system, so that
better access control is available. In particular, using cryptographic methods a unique process Caller ID
indication can be provided per each system process, enabling the Secure Storage software to identify
the various processes which are asking for database services.

January 2009 Page 7 of 16

 Security Challenges in Embedded Designs

Finally, even the Secure Storage database is prone to re-flash attacks. Re-flash attacks refer to the
attacker’s ability to save a copy of the database now and at a later point in time overwrite the database
with the saved copy. Because the saved copy is a legal copy of the database (passes all integrity checks),
the attacker is able to bring the system to a known previous state. The solution to re-flash attacks
involves adding a secure timestamp to the database integrity. Adding such a secure timestamp requires
some on-chip Non-Volatile-Memory (NVM) counter, which is increased every-so-often and added as
part of the Secure Storage database integrity.

2.4 PREVENT USE OF NON-ORIGINAL PERIPHERALS

Loss of revenue occurs when non-original peripherals are used instead of authorized parts. The
manufacturer is interested in preventing such a scenario and limiting the system to work only with
authorized components.
In order to detect non-original peripherals, each peripheral must have a non-forgeable identity. The
identity doesn’t necessarily have to be unique per a specific peripheral – a batch of peripheral
components can have the same signature (for example, to ease inventory control). In order to establish
peripheral attestation, one needs to securely provision a secret in the original peripheral. Example
secrets can be the peripheral manufacturer’s private key, or a shared secret. The matching public key
or shared secret can then be used to uniquely identify the peripheral. The secret must be kept securely
in the original peripheral, such that it is not possible to easily extract it.
Peripheral authentication is one-way, in the sense that the chip is authenticating the peripheral and
not vice versa. When the chip wishes to identify the peripheral, the chip sends a challenge to the
peripheral. The original peripheral is able to use its provisioned secret to provide a response back to
the chip. The chip can then verify the response with its provisioned information. The chip must keep
the secret in Secure Storage, so an attacker cannot replace the secret (as before, more complex Key
Management schemes can be used if the total system key count is high). If an attacker is able to
replace the secret, then whenever the attacker’s non-original peripheral is embedded in a system, the
attacker provides a hack to replace the matching secret in the chip storage, thus enabling the non-
original peripheral to work.
Installing a new peripheral relies on the non-forgeable identification of the component, as well as the
algorithm which is unknown to the attacker. The process of binding a peripheral to a chip involves the
chip authenticating the peripheral, as well as registering its identification and possibly other
parameters in the chip’s Secure Storage database.
Secure Boot running from on-chip ROM is mandatory for detecting non-original peripherals. Only when
the system is at a known and trusted starting point is it possible to verify all connected components
and take action in case of detecting a non-original peripheral.
It is possible to raise the security bar by performing two-way authentication, where the original
peripheral is also authenticating the chip. This requires similar security logic to be implemented at the
peripheral side and is likely to be commercially applicable only for high-end components.

January 2009 Page 8 of 16

 Security Challenges in Embedded Designs

Prevent Use of Non-Original Peripherals

Requirement
Detect if a non-original peripheral is installed
● ●
Enable secure replacement of peripherals
● ●

Non-forgeable component identity

Chip-Peripheral binding

Secure component introduction

Security Requirement
Security Building Block
● ● ● Cryptographic algorithms
● ● ● Secure Key Storage
● Provisioning
○ ○ ○ Key Management
● ● Secure Storage
● - mandatory ● ● ● Secure Boot
○ - optional ● ● ● Dedicated ROM

2.5 SECURE COMMUNICATION

The purpose of secure communication is to prevent an attacker from masquerading and sending false
or misleading data to the chip. Secure communication can also enable one-way or mutual
authentication between the chip and other entities.
When the chip communicates with a target entity, the chip primarily needs to ascertain the identity of
the entity. This requires the entity to have a non-forgeable identity. Utilizing public key cryptography
methods would provide the most effective way to address this requirement – the target entity holds a
private key and the chip is provisioned with the matching public key. Using the public key, the chip is
then able to authenticate the target entity. The public key must be kept in a Secure Key Storage,
otherwise the attacker might replace it and lead the chip to believe it is communicating with a different
entity.
The previous paragraph dealt with one-way authentication, where the chip authenticates that target
entity. Certain use-cases would require mutual authentication, where the target entity also needs to
authenticate the chip. Such mutual authentication is easily achieved in the same manner as just
described, using a second private-public key pair: this time the chip holds the private key and the
target entity holds the matching public key. A Key Management mechanism can optionally assist in key
handling if the system holds a large number of keys.
January 2009 Page 9 of 16
 Security Challenges in Embedded Designs

Finally, there is a need to establish a secure communication channel, which means that data is
encrypted for confidentiality and also integrity-protected. Various security protocols are useful here,
including Diffie-Hellman if there is a need for secure key agreement.

Secure Communication Requirement

One-way authentication of a target
entity communicating with the chip ●
Mutual authentication between chip
and target entity ● ●
Provide a secure communication
channel ● ●

Non-forgeable target entity identity

Non-forgeable CPU identity

Confidential channel

Integrity-protected channel

Security Requirement Security Building Block

● ● ● ● Cryptographic algorithms
● ● Secure Key Storage
● - mandatory ● ● Provisioning
○ - optional ○ ○ Key Management

2.6 DIGITAL RIGHTS MANAGEMENT

Digital Rights Management (DRM) is mandatory today in places where valuable content exists. The
device is responsible for enforcing the content access rights, and is liable for commercial loss if broken.
Security aspects of DRM include, amongst other things, enforcement of usage rights, key protection as
well as content decryption.
DRM content arrives encrypted. Therefore, the DRM process concludes when the system obtains the
content decryption key. Once the content decryption key is available, it is possible to decrypt the
protected content. The security aspects of the content decryption process involve Secure Storage of
the content decryption key when not used, using some Key Management functions to retrieve the
content decryption key and applying the appropriate cryptographic algorithm to the content. At any
point in time, all key material must be protected from potential attackers (for example, by using a
hardware-based decryption engine, where any key material never leaves the hardware environment).
DRM Key material protection is required not only for the content decryption key, but also for any other
DRM-related keys. An example of such key material is the device key, which is used by the licensing
entity to uniquely identify the device. Key material protection involves not only using a Secure Storage

January 2009 Page 10 of 16

 Security Challenges in Embedded Designs

mechanism, but also a secure provisioning solution, which is able to securely inject the device key into
the system.

Digital Rights Management Requirement

Secure Content Decryption
●
Protect DRM key material
● ●
Enforce usage rights
● ●

Protect content keys

Protect device keys

Secure Rights Objects storage

Secure Rights Objects handling

Security Requirement
Security Building Block
● ● ● ● Cryptographic algorithms
● ● ● Secure Storage
● ● ● Key Management
● Provisioning
● RO parsing capability
● Secure Time
● Secure Execution Environment
● - mandatory ● Secure Boot
○ - optional ● Dedicated ROM & RAM

At its basis, DRM deals with usage rights enforcement, as appearing in Rights Objects (ROs). Working
with ROs has two security-related aspects – RO storage and RO handling. First, ROs must be stored
securely in a Secure Storage database. Since a DRM-enabled system can hold numerous ROs, a full-
blown database must be used, enabling unlimited number of data items to be stored securely with an
efficient search mechanism. Secure Storage is mandatory (as opposed to regular storage), since ROs
contain enforcement parameters, such as the remaining usage counter, or the expiration date. Second,
ROs must be handled in a Secure Execution Environment (SEE). The SEE must handle two aspects of
security – parsing the RO correctly and keeping track of secure time. Secure RO parsing is necessary as
some RO fields are not fail-safe in nature. For example, OMA DRM ROs have the time constraint in
plain XML format – an attacker can simply erase the appropriate XML lines and the time constraint
disappears. Secure Time is necessary in order to be able to enforce any time-related usage.

January 2009 Page 11 of 16

 Security Challenges in Embedded Designs

2.7 MULTI-CPU SYSTEM-ON-CHIP

A System-on-Chip (SoC) is not limited to hosting just one CPU. The use-case discussed here is of a single
central security engine that provides security services to multiple CPUs. When consolidating several
CPUs together into a single SoC, it is important to provide a framework for mutual-distrust between
the CPUs, such that one CPU cannot compromise the security of other CPUs.

Multi-CPU System-on-Chip Requirement

Provide mutual-distrust between CPUs
using a single security engine ● ● ●

engine
Identify the CPU accessing the security
material belonging to another CPU
Prevent one CPU from accessing security
execution space between the CPUs
Share a single security software

Security Requirement
Security Building Block
● ● ● Multi-source-aware interface
● ● Cryptographic algorithms
● ● Secure Storage
● ● Key Management
● Secure Execution Environment
● - mandatory ● Secure Boot
○ - optional ● Dedicated ROM & RAM

The first step to establish distrust between CPUs is to enable the central security engine to distinguish
which CPU is addressing it at any point in time. Identification must be robust and therefore should be
based on hardware signals. As an example, many advanced bus architectures today provide the
transaction source indication as an integrated part of the transaction, using side-band signals.
Once the CPU accessing the central security engine is identified, there is a need to prevent that CPU
from accessing security-related material belonging to another CPU. Assuming lack of dedicated RAM
per each CPU, the best method to provide such access separation is by means of cryptography. At
system initialization, a Key Management unit assigns a dedicated random key to each CPU. These keys
are kept protected using a Secure Storage mechanism. All security related material belonging to a given
CPU is encrypted using its dedicated random key and is therefore inaccessible to other CPUs.

January 2009 Page 12 of 16

 Security Challenges in Embedded Designs

Additional mechanisms can be added on top of the basic separation mechanism just described. For
example, if two CPUs need to share information in a secure manner, then a random inter-CPU
communication key can be defined, which is accessible only to the two CPUs.
If more than one CPU needs to execute security related software, then it makes sense to use a central
security software execution space. The execution space is based on a Secure Execution Environment
(SEE) with its own dedicated ROM for Secure Boot and dedicated RAM for software execution. The SEE,
being trusted by all CPUs, has access to all key material and is therefore able to support all CPUs
without compromising each CPU’s security.

3 SECURITY BUILDING BLOCKS

In this section we provide details on some of the security building blocks that were identified in
section ‎2.

3.1 CRYPTOGRAPHIC ALGORITHMS

Cryptographic algorithms are an essential building block of a robust security solution. Generally
speaking two types of algorithms are utilized: symmetric cryptography and public key cryptography.
Symmetric algorithms are used mainly for data encryption and data integrity, due to their high
performance characteristic. Public key cryptography is used mainly for key exchange, attestation and
authentication, due to its asymmetric nature and lower performance characteristics.
The Advanced Encryption Standard (AES) is a secure choice for a symmetric block cipher. The Secure
Hash Algorithm (SHA) is the industry accepted block hashing algorithm. For public key cryptography,
Rivest-Shamir-Adleman (RSA) is the most widespread algorithm, with Elliptic-Curve-Cryptography (ECC)
gaining market traction, due to its improved performance-to-key-size ratio.
Systems can instantiate a cryptographic algorithm either as a hardware cryptographic engine or a
software cryptographic engine. The advantages of a hardware-based engine are security and obviously
faster performance. Security is more robust as key material is only present in hardware registers
inaccessible to the software and never in relatively easy-to-access RAM. The disadvantage of a
hardware-based engine is the silicon footprint. The advantages of a software-based engine is flexibility,
while the downside is that a software-based engine takes considerable MIPS from the processor on
which it is running, which is likely to need the computation power for other tasks.

3.2 SECURE STORAGE

Secure Storage is as basic a building block as the cryptographic algorithms. Cryptographic algorithms
require keys as their basis for operation. Since the algorithms are published and known to all, including
to potential attackers, protecting the secrecy of the key is an important issue for security. Secure
Storage essentially deals with protecting access to keys and other pieces of data. Secure Storage also
needs to be persistent, such that items are not lost during power cycles.
Examples of persistent storage are on-chip ROM memory, on-chip One-Time-Programmable (OTP)
technology, as well as off-chip flash memory. On-chip storage has the advantage in that it can be more
easily hooked to the security solution, while having the disadvantage of larger silicon footprint and lack
of flexibility. Off-chip storage is very flexible, but requires employing more careful access control

January 2009 Page 13 of 16

 Security Challenges in Embedded Designs

schemes. If more than a few keys require protection, then on-chip solutions quickly become
unpractical and it’s best to use off-chip storage.
The first step in order to protect access to plain keys (or any other data items) on an external flash is to
encrypt the keys prior to their storage. Such encryption is able to thwart basic attacks techniques of
simply reading flash content or probing the bus signals passing between the flash chip and the CPU
chip. Adding integrity protection for each key also prevents the attacker from utilizing replacement
attacks.
Once the encrypted key is within the chip boundary, it is still prone to attacks. The basic question is
which root key is used to encrypt all other keys residing in the Secure Storage database. The best
practice here is to use a hardware-based solution for this root key: on-chip OTP bits. Using OTP bits
provides the chip manufacturer with the flexibility to program a different random root key for each and
every chip, which in turn leads to a Secure Storage database which is encrypted with a different key for
every chip. The other option is to use a software-based root key, where the root key is stored
somewhere in the software image on flash.
Breaking a Secure Storage database with a root key that is hardware-based requires the attacker to
decap the chip and attempt to read the OTP value. Such an attack is not scalable, since the attacker
needs to repeat the same attack for every chip. On the other hand, using a software-based root key
provides a scalable attack pattern: once an attacker manages to analyze the software image and find
the root key, the attacker is able to easily distribute the attack and reveal every root key in every chip.
Assuming that the root key is indeed hardware based, it should still be used in a secure manner. The
best practice here is to use a dedicated hardware module which reads the root key directly from OTP
bits and decrypts encrypted keys fetched from the Secure Storage on flash. Using such a dedicated
hardware module means that the root key is contained in a defined hardware block and is never
exposed in more attack-prone locations such as CPU RAMs. The dedicated hardware module can range
from a single dedicated engine up to a full Secure Execution Environment – depending on the type of
assets available on the chip.
The final aspect of access protection is to limit the CPU applications which are accessing Secure Storage
keys. A robust Secure Storage solution is able to use cryptographic measures to uniquely identify each
CPU application and ascertain whether this application is allowed to use the root key in order to
decrypt Secure Storage data.
Additional features are required in order to provide a complete Secure Storage solution. Primarily, the
Secure Storage database should be able to recover from unexpected power-loss as well as unexpected
application errors – neither one should render the database useless. Fast search capability is required
when handling a large database, providing reasonable performance characteristics. Smart utilization of
buffers is essential in order to decrease flash wear out, both for reads and writes. Finally, as discussed
in section ‎2.3, the Secure Storage database is prone to re-flash attacks. The solution to re-flash attacks
involves adding a secure timestamp to the database integrity.

3.3 SECURE BOOT

The purpose of Secure Boot is to bring the system to a known and trusted state. Because CPU software
image resides as plaintext (i.e. unencrypted) on external flash, an attacker can easily modify the code
and cause the CPU to run code which was not intended to run.
January 2009 Page 14 of 16
 Security Challenges in Embedded Designs

Secure Boot, as described in section ‎2.1, works by calculating a hash value of the software image. The
hash value is then signed using the software manufacturer private key, to create a unique signature
which an attacker cannot forge without access to the private key. The unique signature is then loaded
to the flash alongside the software image. The software manufacturer’s public key is also provisioned
to the system.
The Secure Boot routine is a ROM-based routine which performs the following steps at boot time:
reads the software image from flash, calculates the hash value of the software image and uses the
software manufacturer’s public key to verify that the new hash just calculated matches the old hash
present on flash and signed by the software manufacturer’s private key. Even a single bit modification
of the software image will lead to a different hash and as a result will lead to Secure Boot failure. As
mentioned in section ‎2.1, the Secure Boot function must be ROM-based, so that an attacker cannot
intercept the procedure.
Additional features are required in order to provide a complete Secure Boot solution. These include the
ability for software update at any point in time. Given that the software is correctly signed with the
software manufacturer private key, the Secure Boot routine should pass successfully. If the software
image is constructed of several components, the Secure Boot routine should be able to accommodate
multiple software vendors and multiple keys used to sign the image. If a private key has been
compromised, the Secure Boot routine should support revocation of a compromised private key and
discard the appropriate public key. Finally, a Software Version Revocation mechanism is able to
advance the system to a new version of the software image and prevent roll-back to an older version.

3.4 SECURE JTAG

The JTAG interface is a debugging interface for chips. It is used primarily during development and
manufacturing, but also used to help debug errors that are found in the course of the lifetime of the
system.
The JTAG interface is potentially exploitable by attackers, who can try to read internal registers or
memories. A current widespread solution is to disable JTAG completely when the system leaves the
manufacturer’s facility, by physically disconnecting the JTAG lines. Of course this solution is secure, but
prevents the manufacturer from any future debug capability.
It is possible to leave the JTAG interface active and protect it using a Secure JTAG mechanism.
Whenever a debug tool is interfacing the chip through the JTAG interface, the Secure JTAG mechanism
issues a challenge-response protocol with the debug tool, as was described in section ‎2.2. The purpose
of the protocol is to authenticate the debug tool attempting access to chip internal JTAG chains and is
based on some shared secret between the chip and the manufacturer who controls the debug tools.
The shared secret needs to be provisioned to the chip during manufacturing and be kept securely.
An additional feature required in order to provide a flexible Secure JTAG solution is a Life Cycle State
Mechanism, which enables the Secure JTAG mechanism to know whether the chip is currently in
development (and hence no need to enforce the access policy on the JTAG interface), or already
deployed in the field (at which time the JTAG access policy is enforced).

January 2009 Page 15 of 16

 Security Challenges in Embedded Designs

3.5 SECURE EXECUTION ENVIRONMENT

Throughout this paper we have discussed several use-cases which require a Secure Execution
Environment (SEE). An SEE is a processing unit which is capable of executing applications in a protected
manner, meaning the attacks originating from outside the SEE cannot tamper with code and data
belonging to the SEE.
The first building block of an SEE is of course a secure processor – either a dedicated processor or one
capable of supporting a secure mode, which is hardware compartmentalized from the non-secure
mode. Utilizing a dedicated processor has the advantage of ease of separation as well as offloading the
main processor from handling security tasks. The disadvantage of a dedicated processor is the increase
in silicon footprint. The advantages of using one processor with two compartments is exploiting
remaining MIPS if available, while the disadvantages include the need for better system design, loss of
MIPS, and harder proof of security robustness.
The second building block is secure code and data memory – most likely dedicated on-chip RAMs. It is
important to remember that whenever code is present outside the SEE memory it should be integrity
protected against modifications (and possibly protected for confidentiality by means of encryption if
required). Whenever data is present outside the SEE memory it should be protected both for
confidentiality and for integrity.
Using dedicated memories has the disadvantage of increasing the chip silicon footprint. In order to
reach the optimal memory size, careful analysis needs to be performed over all security applications
and their total memory requirement aggregated to reach the size of necessary on-chip memory. A
better approach is to use secure cache mechanisms. Secure caches offer an unlimited code and data
spaces, supporting a virtually unlimited number of security applications, while maintaining a constant
and small on-chip dedicated memories (for example, 8Kbyte for I-cache, 8Kbyte for D-cache). Secure
cache mechanisms keep the SEE code and data secure on external RAM and fetch the necessary code
and data as the security application is running, accommodating on-the-fly decryption and integrity
verification. As mentioned above, whenever code or data are available outside the SEE it should be
adequately protected.

4 SUMMARY
In this paper we have looked at several use-cases that require security foundations. For each use-case
we defined the set of features that involve security and from these feature we derived the security
requirements. Analyzing each security requirement we identified the embedded security building
blocks. The use-case analysis was also presented in a tabular format, showing the clear flow from
requirements to building blocks. Finally, several security buildings block were discussed to some extent,
highlighting characteristics which are of importance to the system designer.

January 2009 Page 16 of 16