Djam/arm-trusted-firmware
1
0
Fork 0
mirror of https://github.com/ARM-software/arm-trusted-firmware.git synced 2025-04-23 21:44:15 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update cryptographic algorithms in TBBR doc

Browse source 
The TBBR documentation has been written along with an early
implementation of the code. At that time, the range of supported
encryption and hash algorithms was failry limited. Since then, support
for other algorithms has been added in TF-A but the documentation has
not been updated.

Instead of listing them all, which would clutter this document while
still leaving it at risk of going stale in the future, remove specific
references to the original algorithms and point the reader at the
relevant comprehensive document for further details.

Change-Id: I29dc50bc1d53b728091a1fbaa1c3970fb999f7d5
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
This commit is contained in:
Sandrine Bailleux 2020-03-03 13:00:10 +01:00
parent f9ea3a6291
commit 316c5cc6a2
1 changed files with 13 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
docs/design/trusted-board-boot.rst
View file

@ -19,7 +19,9 @@ A Chain of Trust (CoT) starts with a set of implicitly trusted components. On
the Arm development platforms, these components are:
- A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the
trusted root-key storage registers.
trusted root-key storage registers. Alternatively, a development ROTPK might
be used and its hash embedded into the BL1 and BL2 images (only for
development purposes).
- The BL1 image, on the assumption that it resides in ROM so cannot be
tampered with.
@ -32,17 +34,17 @@ essential information to establish the CoT.
In the TBB CoT all certificates are self-signed. There is no need for a
Certificate Authority (CA) because the CoT is not established by verifying the
validity of a certificate's issuer but by the content of the certificate
extensions. To sign the certificates, the PKCS#1 SHA-256 with RSA Encryption
signature scheme is used with a RSA key length of 2048 bits. Future version of
TF-A will support additional cryptographic algorithms.
extensions. To sign the certificates, different signature schemes are available,
please refer to the :ref:`Build Options` for more details.
The certificates are categorised as "Key" and "Content" certificates. Key
certificates are used to verify public keys which have been used to sign content
certificates. Content certificates are used to store the hash of a boot loader
image. An image can be authenticated by calculating its hash and matching it
with the hash extracted from the content certificate. The SHA-256 function is
used to calculate all hashes. The public keys and hashes are included as
non-standard extension fields in the `X.509 v3`_ certificates.
with the hash extracted from the content certificate. Various hash algorithms
are supported to calculate all hashes, please refer to the :ref:`Build Options`
for more details.. The public keys and hashes are included as non-standard
extension fields in the `X.509 v3`_ certificates.
The keys used to establish the CoT are:
@ -63,10 +65,10 @@ The keys used to establish the CoT are:
non secure world image (BL33). The public part is stored in one of the
extension fields in the trusted world certificate.
- **BL3-X keys**
- **BL3X keys**
For each of SCP_BL2, BL31, BL32 and BL33, the private part is used to
sign the content certificate for the BL3-X image. The public part is stored
sign the content certificate for the BL3X image. The public part is stored
in one of the extension fields in the corresponding key certificate.
The following images are included in the CoT:
@ -219,8 +221,7 @@ certificates (in DER format) required to establish the CoT. New keys can be
generated by the tool in case they are not provided. The certificates are then
passed as inputs to the ``fiptool`` utility for creating the FIP.
The certificates are also stored individually in the in the output build
directory.
The certificates are also stored individually in the output build directory.
The tool resides in the ``tools/cert_create`` directory. It uses the OpenSSL SSL
library version to generate the X.509 certificates. The specific version of the
@ -259,7 +260,7 @@ Instructions for building and using the tool can be found in the
--------------
*Copyright (c) 2015-2019, Arm Limited and Contributors. All rights reserved.*
*Copyright (c) 2015-2020, Arm Limited and Contributors. All rights reserved.*
.. _X.509 v3: https://tools.ietf.org/rfc/rfc5280.txt
.. _Trusted Board Boot Requirements (TBBR): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a