Crypto D100 Betriebsanweisung PDF herunterladen (Seite 8)

Secure Boot with i.MX28 HAB Version 4, Rev. 1

8 Freescale Semiconductor

Designing for code signing

The arrows in Figure 3 show the authentication flow. For example, the SRK is used to authenticate both

the CSF key certificate and the image key certificates.

There are several important features to note. First, each key can certify multiple instances of the objects

beneath it. For example, a single SRK can certify multiple CSF keys, a single CSF key can authenticate

multiple CSFs (for example, on different product revisions), and a single image key can certify multiple

images. Nevertheless, the CSF key can only authenticate the CSF headers and commands. The objects

closer to the root of the PKI have greater impact if compromised, and require more protection. To some

extent, this is offered by the CST tool, but it is important that the CST user adopt appropriate policies and

processes. For example, a poorly planned CSF can open the way for malicious applications to be loaded

in place of the authentic one. It is therefore prudent to plan the CSF so it does not need to change with

every new version of the application, and restrict the group authorized to sign CSFs to a relatively small

number of people.

Second, the authentication of an image key through the CSF may be a little different to the other links

shown in Figure 3. In order to provide better key separation, an image key may be bound to the CSF using

a hash fingerprint embedded in the CSF. This means that it would not be possible to use the CSF with other

image keys, even if they have been certified by the same SRK. The addition of the hash is optional and is

dependent on whether the Hash Algorithm argument is present in the Install Key command. See the Install

Key command documentation in the HAB CST User’s Guide for further details.

Thirdly, each key type can authenticate only one data type. The SRK can authenticate only key certificates,

not CSFs or images. A CSF key can authenticate only CSFs. An image key can authenticate only images.

3 Designing for code signing

3.1 What components are required?

A secure boot requires a number of data components to be added to an image. This includes certificates,

signatures, Device configuration data (DCD) and CSF data.

NOTE

Although the i.MX28 ROM supports the use of DCD configuration of the

chip, it is optional. On the i.MX28, device configuration is typically

performed using bootlets using the Call command supported by the ROM.

See section 3.1.2 for further information on DCD.

When performing a secure boot on the i.MX28, Boot ROM and HAB require the following data

components to be defined in the image:

• Image Vector Table—A table of pointers used by the Boot ROM to locate other required data

components.

• CSF data—A block of data containing the commands that HAB will execute during boot.

• Certificates and associated signatures HAB uses to verify an image.

In addition to the above components, the location of the ROM Vector Table (RVT) is also required. The

RVT is a table of addresses defining the location of each of the HAB API functions. This is required as the

HAB library will be called to authenticate the next component in the boot chain. The structure of the RVT

1 2 3 4 5 6 7 8 9 10 11 12 13 ... 30 31

Keine Kommentare

Crypto D100 Betriebsanweisung Seite 8