Security Challenges in Embedded Designs

8/6/2019 Security Challenges in Embedded Designs

1/16

January 2009 Page 1 of 16

SECURITY CHALLENGES IN EMBEDDED DESIGNSEran 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 INTRODUCTIONSecurity 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-ChipFor each use-case, section2 lists the various security requirements and maps those to security building

blocks. Section3 provides a more in-depth description of each security building block.

2 USE-CASE ANALYSISIn 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 toanswer that security requirement.

2.1 SOFTWARE INTEGRITY PROTECTIONSoftware 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


2/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 updatesession. 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 manufacturers 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 manufacturers 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


3/16



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.

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.

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

Uniquesoftwaresignature

Boot-timeIntegrityChecking

Run-TimeIntegrityChecking

Securesoftwareupdate

SecurityRequirement

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


4/16



2.2 SOFTWARE IPPROTECTIONThe 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 greaterpenalty, 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

manufacturers ideas and know-how. A starting point for protecting the software image is by means of

code encryption, such that the attacker doesnt 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 section3.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

manufacturers 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 systems 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.


5/16



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.

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 characteristicseven 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

Codeencryption

Securesoftware

update

On-the-flycodedecryption

Debugportprotection

Uniquechip

identification

SecurityRequire

ment



Secure Key Storage

Key Management

Secure Storage

Secure Boot

Secure JTAG Mechanism

Life Cycle State Management

Provisioning

- mandatory Unique Secret Key

- optional Dedicated ROM


6/16



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 doesnt 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 chips code encryption to this unique key.

2.3 SECURE INFORMATION AND DATA LOGGINGSecure 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 doesnt

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.


7/16



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.

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

Provideasecuredatabase

Protectagainstpowerfailur

es

Protectagainstapplicationerrors

Database

integrity

Databaseconfidentiality

Hardware-baseddatabases

ecurity

Debugportprotection

Databaseaccesscontrol

SecurityRequirement


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


- mandatory Secure Boot

- optional Dedicated ROM & RAM


8/16



Finally, even the Secure Storage database is prone to re-flash attacks. Re-flash attacks refer to the

attackers 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 aspart of the Secure Storage database integrity.

2.4 PREVENT USE OF NON-ORIGINAL PERIPHERALSLoss 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 doesnt 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. Examplesecrets can be the peripheral manufacturers 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 attackers non-original peripheral is embedded in a system, theattacker 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 chips 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.


9/16



2.5 SECURE COMMUNICATIONThe 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 differententity.

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.

Prevent Use of Non-Original Peripherals

Requirement

Detect if a non-original peripheral is installed

Enable secure replacement of peripherals

Non-forgeablecomponentidentity

Chip-Peripheralbinding

Securecomponentintroduction

SecurityRequirement



Secure Key Storage

Provisioning

Key Management

Secure Storage


- optional Dedicated ROM


10/16



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.

2.6 DIGITAL RIGHTS MANAGEMENTDigital 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 thecontent 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

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-forgeabletargetentityidentity

Non-forgeableCP

Uidentity

Confidentialchan

nel

Integrity-protecte

dchannel

SecurityRequirement



Secure Key Storage

- mandatory Provisioning

- optional Key Management


11/16



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

the system.

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.

Digital Rights Management Requirement

Secure Content Decryption

Protect DRM key material

Enforce usage rights

Protectcontentkeys

Protectdevicekeys

SecureRightsObjectsstorage

SecureRightsObjectsha

ndling

SecurityRequirement


Cryptographic algorithms Secure Storage Key Management

Provisioning

RO parsing capability

Secure Time





12/16



2.7 MULTI-CPUSYSTEM-ON-CHIPA 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.

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 RAMper 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.

Multi-CPU System-on-Chip Requirement

Provide mutual-distrust between CPUs

using a single security engine

IdentifytheCPUacces

singthesecurity

engine

PreventoneCPUfrom

accessingsecurity

materialbelongingto

anotherCPU

Shareasinglesecurity

software

executionspacebetweentheCPUs

SecurityRequirement


Multi-source-aware interface


Secure Storage

Key Management





13/16



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 CPUs security.

3 SECURITY BUILDING BLOCKSIn this section we provide details on some of the security building blocks that were identified in

section2.

3.1 CRYPTOGRAPHIC ALGORITHMSCryptographic 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 obviouslyfaster 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 STORAGESecure 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


14/16



schemes. If more than a few keys require protection, then on-chip solutions quickly become

unpractical and its 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 replacementattacks.

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 discussedin section2.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 BOOTThe 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.


15/16



Secure Boot, as described in section2.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 manufacturers 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 manufacturers 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 section2.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 accommodatemultiple 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 JTAGThe 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

manufacturers 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 section2.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).


16/16



3.5 SECURE EXECUTION ENVIRONMENTThroughout 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 SUMMARYIn 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.

Documents

Security Challenges in Embedded Designs