374 lines
17 KiB
Plaintext
374 lines
17 KiB
Plaintext
The trusted boot framework on Marvell Armada 38x
|
|
================================================
|
|
|
|
Contents:
|
|
|
|
1. Overview of the trusted boot
|
|
2. Terminology
|
|
3. Boot image layout
|
|
4. The secured header
|
|
5. The secured boot flow
|
|
6. Usage example
|
|
7. Work to be done
|
|
8. Bibliography
|
|
|
|
1. Overview of the trusted boot
|
|
-------------------------------
|
|
|
|
The Armada's trusted boot framework enables the SoC to cryptographically verify
|
|
a specially prepared boot image. This can be used to establish a chain of trust
|
|
from the boot firmware all the way to the OS.
|
|
|
|
To achieve this, the Armada SoC requires a specially prepared boot image, which
|
|
contains the relevant cryptographic data, as well as other information
|
|
pertaining to the boot process. Furthermore, a eFuse structure (a
|
|
one-time-writeable memory) need to be configured in the correct way.
|
|
|
|
Roughly, the secure boot process works as follows:
|
|
|
|
* Load the header block of the boot image, extract a special "root" public RSA
|
|
key from it, and verify its SHA-256 hash against a SHA-256 stored in a eFuse
|
|
field.
|
|
* Load an array of code signing public RSA keys from the header block, and
|
|
verify its RSA signature (contained in the header block as well) using the
|
|
"root" RSA key.
|
|
* Choose a code signing key, and use it to verify the header block (excluding
|
|
the key array).
|
|
* Verify the binary image's signature (contained in the header block) using the
|
|
code signing key.
|
|
* If all checks pass successfully, boot the image.
|
|
|
|
The chain of trust is thus as follows:
|
|
|
|
* The SHA-256 value in the eFuse field verifies the "root" public key.
|
|
* The "root" public key verifies the code signing key array.
|
|
* The selected code signing key verifies the header block and the binary image.
|
|
|
|
In the special case of building a boot image containing U-Boot as the binary
|
|
image, which employs this trusted boot framework, the following tasks need to
|
|
be addressed:
|
|
|
|
1. Creation of the needed cryptographic key material.
|
|
2. Creation of a conforming boot image containing the U-Boot image as binary
|
|
image.
|
|
3. Burning the necessary eFuse values.
|
|
|
|
(1) will be addressed later, (2) will be taken care of by U-Boot's build
|
|
system (some user configuration is required, though), and for (3) the necessary
|
|
data (essentially a series of U-Boot commands to be entered at the U-Boot
|
|
command prompt) will be created by the build system as well.
|
|
|
|
The documentation of the trusted boot mode is contained in part 1, chapter
|
|
7.2.5 in the functional specification [1], and in application note [2].
|
|
|
|
2. Terminology
|
|
--------------
|
|
|
|
CSK - Code Signing Key(s): An array of RSA key pairs, which
|
|
are used to sign and verify the secured header and the
|
|
boot loader image.
|
|
KAK - Key Authentication Key: A RSA key pair, which is used
|
|
to sign and verify the array of CSKs.
|
|
Header block - The first part of the boot image, which contains the
|
|
image's headers (also known as "headers block", "boot
|
|
header", and "image header")
|
|
eFuse - A one-time-writeable memory.
|
|
BootROM - The Armada's built-in boot firmware, which is
|
|
responsible for verifying and starting secure images.
|
|
Boot image - The complete image the SoC's boot firmware loads
|
|
(contains the header block and the binary image)
|
|
Main header - The header in the header block containing information
|
|
and data pertaining to the boot process (used for both
|
|
the regular and secured boot processes)
|
|
Binary image - The binary code payload of the boot image; in this
|
|
case the U-Boot's code (also known as "source image",
|
|
or just "image")
|
|
Secured header - The specialized header in the header block that
|
|
contains information and data pertaining to the
|
|
trusted boot (also known as "security header")
|
|
Secured boot mode - A special boot mode of the Armada SoC in which secured
|
|
images are verified (non-secure images won't boot);
|
|
the mode is activated by setting a eFuse field.
|
|
Trusted debug mode - A special mode for the trusted boot that allows
|
|
debugging of devices employing the trusted boot
|
|
framework in a secure manner (untested in the current
|
|
implementation).
|
|
Trusted boot framework - The ARMADA SoC's implementation of a secure verified
|
|
boot process.
|
|
|
|
3. Boot image layout
|
|
--------------------
|
|
|
|
+-- Boot image --------------------------------------------+
|
|
| |
|
|
| +-- Header block --------------------------------------+ |
|
|
| | Main header | |
|
|
| +------------------------------------------------------+ |
|
|
| | Secured header | |
|
|
| +------------------------------------------------------+ |
|
|
| | BIN header(s) | |
|
|
| +------------------------------------------------------+ |
|
|
| | REG header(s) | |
|
|
| +------------------------------------------------------+ |
|
|
| | Padding | |
|
|
| +------------------------------------------------------+ |
|
|
| |
|
|
| +------------------------------------------------------+ |
|
|
| | Binary image + checksum | |
|
|
| +------------------------------------------------------+ |
|
|
+----------------------------------------------------------+
|
|
|
|
4. The secured header
|
|
---------------------
|
|
|
|
For the trusted boot framework, a additional header is added to the boot image.
|
|
The following data are relevant for the secure boot:
|
|
|
|
KAK: The KAK is contained in the secured header in the form
|
|
of a RSA-2048 public key in DER format with a length of
|
|
524 bytes.
|
|
Header block signature: The RSA signature of the header block (excluding the
|
|
CSK array), created using the selected CSK.
|
|
Binary image signature: The RSA signature of the binary image, created using
|
|
the selected CSK.
|
|
CSK array: The array of the 16 CSKs as RSA-2048 public keys in DER
|
|
format with a length of 8384 = 16 * 524 bytes.
|
|
CSK block signature: The RSA signature of the CSK array, created using the
|
|
KAK.
|
|
|
|
NOTE: The JTAG delay, Box ID, and Flash ID header fields do play a role in the
|
|
trusted boot process to enable and configure secure debugging, but they were
|
|
not tested in the current implementation of the trusted boot in U-Boot.
|
|
|
|
5. The secured boot flow
|
|
------------------------
|
|
|
|
The steps in the boot flow that are relevant for the trusted boot framework
|
|
proceed as follows:
|
|
|
|
1) Check if trusted boot is enabled, and perform regular boot if it is not.
|
|
2) Load the secured header, and verify its checksum.
|
|
3) Select the lowest valid CSK from CSK0 to CSK15.
|
|
4) Verify the SHA-256 hash of the KAK embedded in the secured header.
|
|
5) Verify the RSA signature of the CSK block from the secured header with the
|
|
KAK.
|
|
6) Verify the header block signature (which excludes the CSK block) from the
|
|
secured header with the selected CSK.
|
|
7) Load the binary image to the main memory and verify its checksum.
|
|
8) Verify the binary image's RSA signature from the secured header with the
|
|
selected CSK.
|
|
9) Continue the boot process as in the case of the regular boot.
|
|
|
|
NOTE: All RSA signatures are verified according to the PKCS #1 v2.1 standard
|
|
described in [3].
|
|
|
|
NOTE: The Box ID and Flash ID are checked after step 6, and the trusted debug
|
|
mode may be entered there, but since this mode is untested in the current
|
|
implementation, it is not described further.
|
|
|
|
6. Usage example
|
|
----------------
|
|
|
|
### Create key material
|
|
|
|
To employ the trusted boot framework, cryptographic key material needs to be
|
|
created. In the current implementation, two keys are needed to build a valid
|
|
secured boot image: The KAK private key and a CSK private key (both have to be
|
|
2048 bit RSA keys in PEM format). Note that the usage of more than one CSK is
|
|
currently not supported.
|
|
|
|
NOTE: Since the public key can be generated from the private key, it is
|
|
sufficient to store the private key for each key pair.
|
|
|
|
OpenSSL can be used to generate the needed files kwb_kak.key and kwb_csk.key
|
|
(the names of these files have to be configured, see the next section on
|
|
kwbimage.cfg settings):
|
|
|
|
openssl genrsa -out kwb_kak.key 2048
|
|
openssl genrsa -out kwb_csk.key 2048
|
|
|
|
The generated files have to be placed in the U-Boot root directory.
|
|
|
|
Alternatively, instead of copying the files, symlinks to the private keys can
|
|
be placed in the U-Boot root directory.
|
|
|
|
WARNING: Knowledge of the KAK or CSK private key would enable an attacker to
|
|
generate secured boot images containing arbitrary code. Hence, the private keys
|
|
should be carefully guarded.
|
|
|
|
### Create/Modifiy kwbimage.cfg
|
|
|
|
The Kirkwook architecture in U-Boot employs a special board-specific
|
|
configuration file (kwbimage.cfg), which controls various boot image settings
|
|
that are interpreted by the BootROM, such as the boot medium. The support the
|
|
trusted boot framework, several new options were added to faciliate
|
|
configuration of the secured boot.
|
|
|
|
The configuration file's layout has been retained, only the following new
|
|
options were added:
|
|
|
|
KAK - The name of the KAK RSA private key file in the U-Boot
|
|
root directory, without the trailing extension of ".key".
|
|
CSK - The name of the (active) CSK RSA private key file in the
|
|
U-Boot root directory, without the trailing extension of
|
|
".key".
|
|
BOX_ID - The BoxID to be used for trusted debugging (a integer
|
|
value).
|
|
FLASH_ID - The FlashID to be used for trusted debugging (a integer
|
|
value).
|
|
JTAG_DELAY - The JTAG delay to be used for trusted debugging (a
|
|
integer value).
|
|
CSK_INDEX - The index of the active CSK (a integer value).
|
|
SEC_SPECIALIZED_IMG - Flag to indicate whether to include the BoxID and FlashID
|
|
in the image (that is, whether to use the trusted debug
|
|
mode or not); no parameters.
|
|
SEC_BOOT_DEV - The boot device from which the trusted boot is allowed to
|
|
proceed, identified via a numeric ID. The tested values
|
|
are 0x34 = NOR flash, 0x31 = SDIO/MMC card; for
|
|
additional ID values, consult the documentation in [1].
|
|
SEC_FUSE_DUMP - Dump the "fuse prog" commands necessary for writing the
|
|
correct eFuse values to a text file in the U-Boot root
|
|
directory. The parameter is the architecture for which to
|
|
dump the commands (currently only "a38x" is supported).
|
|
|
|
The parameter values may be hardcoded into the file, but it is also possible to
|
|
employ a dynamic approach of creating a Autoconf-like kwbimage.cfg.in, then
|
|
reading configuration values from Kconfig options or from the board config
|
|
file, and generating the actual kwbimage.cfg from this template using Makefile
|
|
mechanisms (see board/gdsys/a38x/Makefile as an example for this approach).
|
|
|
|
### Set config options
|
|
|
|
To enable the generation of trusted boot images, the corresponding support
|
|
needs to be activated, and a index for the active CSK needs to be selected as
|
|
well.
|
|
|
|
Furthermore, eFuse writing support has to be activated in order to burn the
|
|
eFuse structure's values (this option is just needed for programming the eFuse
|
|
structure; production boot images may disable it).
|
|
|
|
ARM architecture
|
|
-> [*] Build image for trusted boot
|
|
(0) Index of active CSK
|
|
-> [*] Enable eFuse support
|
|
[ ] Fake eFuse access (dry run)
|
|
|
|
### Build and test boot image
|
|
|
|
The creation of the boot image is done via the usual invocation of make (with a
|
|
suitably set CROSS_COMPILE environment variable, of course). The resulting boot
|
|
image u-boot-spl.kwb can then be tested, if so desired. The hdrparser from [5]
|
|
can be used for this purpose. To build the tool, invoke make in the
|
|
'tools/marvell/doimage_mv' directory of [5], which builds a stand-alone
|
|
hdrparser executable. A test can be conducted by calling hdrparser with the
|
|
produced boot image and the following (mandatory) parameters:
|
|
|
|
./hdrparser -k 0 -t u-boot-spl.kwb
|
|
|
|
Here we assume that the CSK index is 0 and the boot image file resides in the
|
|
same directory (adapt accordingly if needed). The tool should report that all
|
|
checksums are valid ("GOOD"), that all signature verifications succeed
|
|
("PASSED"), and, finally, that the overall test was successful
|
|
("T E S T S U C C E E D E D" in the last line of output).
|
|
|
|
### Burn eFuse structure
|
|
|
|
+----------------------------------------------------------+
|
|
| WARNING: Burning the eFuse structure is a irreversible |
|
|
| operation! Should wrong or corrupted values be used, the |
|
|
| board won't boot anymore, and recovery is likely |
|
|
| impossible! |
|
|
+----------------------------------------------------------+
|
|
|
|
After the build process has finished, and the SEC_FUSE_DUMP option was set in
|
|
the kwbimage.cfg was set, a text file kwb_fuses_a38x.txt should be present in
|
|
the U-Boot top-level directory. It contains all the necessary commands to set
|
|
the eFuse structure to the values needed for the used KAK digest, as well as
|
|
the CSK index, Flash ID and Box ID that were selected in kwbimage.cfg.
|
|
|
|
Sequentially executing the commands in this file at the U-Boot command prompt
|
|
will write these values to the eFuse structure.
|
|
|
|
If the SEC_FUSE_DUMP option was not set, the commands needed to burn the fuses
|
|
have to be crafted by hand. The needed fuse lines can be looked up in [1]; a
|
|
rough overview of the process is:
|
|
|
|
* Burn the KAK public key hash. The hash itself can be found in the file
|
|
pub_kak_hash.txt in the U-Boot top-level directory; be careful to account for
|
|
the endianness!
|
|
* Burn the CSK selection, BoxID, and FlashID
|
|
* Enable trusted boot by burning the corresponding fuse (WARNING: this must be
|
|
the last fuse line written!)
|
|
* Lock the unused fuse lines
|
|
|
|
The command to employ is the "fuse prog" command previously enabled by setting
|
|
the corresponding configuration option.
|
|
|
|
For the trusted boot, the fuse prog command has a special syntax, since the
|
|
ARMADA SoC demands that whole fuse lines (64 bit values) have to be written as
|
|
a whole. The fuse prog command itself allows lists of 32 bit words to be
|
|
written at a time, but this is translated to a series of single 32 bit write
|
|
operations to the fuse line, where the individual 32 bit words are identified
|
|
by a "word" counter that is increased for each write.
|
|
|
|
To work around this restriction, we interpret each line to have three "words"
|
|
(0-2): The first and second words are the values to be written to the fuse
|
|
line, and the third is a lock flag, which is supposed to lock the fuse line
|
|
when set to 1. Writes to the first and second words are memoized between
|
|
function calls, and the fuse line is only really written and locked (on writing
|
|
the third word) if both words were previously set, so that "incomplete" writes
|
|
are prevented. An exception to this is a single write to the third word (index
|
|
2) without previously writing neither the first nor the second word, which
|
|
locks the fuse line without setting any value; this is needed to lock the
|
|
unused fuse lines.
|
|
|
|
As an example, to write the value 0011223344556677 to fuse line 10, we would
|
|
use the following command:
|
|
|
|
fuse prog -y 10 0 00112233 44556677 1
|
|
|
|
Here 10 is the fuse line number, 0 is the index of the first word to be
|
|
written, 00112233 and 44556677 are the values to be written to the fuse line
|
|
(first and second word) and the trailing 1 is the value for the third word
|
|
responsible for locking the line.
|
|
|
|
A "lock-only" command would look like this:
|
|
|
|
fuse prog -y 11 2 1
|
|
|
|
Here 11 is the fuse number, 2 is the index of the first word to be written
|
|
(notice that we only write to word 2 here; the third word for fuse line
|
|
locking), and the 1 is the value for the word we are writing to.
|
|
|
|
WARNING: According to application note [4], the VHV pin of the SoC must be
|
|
connected to a 1.8V source during eFuse programming, but *must* be disconnected
|
|
for normal operation. The AN [4] describes a software-controlled circuit (based
|
|
on a N-channel or P-channel FET and a free GPIO pin of the SoC) to achieve
|
|
this, but a jumper-based circuit should suffice as well. Regardless of the
|
|
chosen circuit, the issue needs to be addressed accordingly!
|
|
|
|
7. Work to be done
|
|
------------------
|
|
|
|
* Add the ability to populate more than one CSK
|
|
* Test secure debug
|
|
* Test on Armada XP
|
|
|
|
8. Bibliography
|
|
---------------
|
|
|
|
[1] ARMADA(R) 38x Family High-Performance Single/Dual CPU System on Chip
|
|
Functional Specification; MV-S109094-00, Rev. C; August 2, 2015,
|
|
Preliminary
|
|
[2] AN-383: ARMADA(R) 38x Families Secure Boot Mode Support; MV-S302501-00
|
|
Rev. A; March 11, 2015, Preliminary
|
|
[3] Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
|
|
Specifications Version 2.1; February 2003;
|
|
https://www.ietf.org/rfc/rfc3447.txt
|
|
[4] AN-389: ARMADA(R) VHV Power; MV-S302545-00 Rev. B; January 28, 2016,
|
|
Released
|
|
[5] Marvell Armada 38x U-Boot support; November 25, 2015;
|
|
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell
|
|
|
|
2017-01-05, Mario Six <mario.six@gdsys.cc>
|