1HW crypto key integration in TF-M secure boot
2=============================================
3
4:Author: Tamas Ban
5:Organization: Arm Limited
6:Contact: Tamas Ban <tamas.ban@arm.com>
7
8Abstract
9--------
10
11`PSA Trusted Boot and Firmware Update <https://pages.arm.com/psa-resources-tbfu.html>`__
12specification requires the support of at least one immutable root of trust
13public key (ROTPK) for firmware verification. This can be stored using a locked
14on-chip flash memory, a secure-element or on-chip OTP memory. It also beneficial
15to be able to provision these keys during the factory life-cycle of the device
16independently from any software components. The current key handling solution
17in TF-M secure boot does not supports this key provisioning process. MCUBoot
18requires compile time built-in public key(s) for image verification. This
19limitation does not fit well with a scenario with multiple vendors where
20multiple MCU software components might be deployed by different vendors in
21different points in the life-cycle of the device and they do not want to share
22the keys in-advance for embedding in the bootloader code. The goal of this
23document to propose a solution to decouple MCUBoot from public key(s) and
24enable the independent deployment of ROTPK.
25
26Existing key handling solution
27------------------------------
28
29MCUBoot code contains a compile-time built-in key array which can store any
30number of key(s) for firmware verification: ``bl2/ext/mcuboot/keys.c``. These
31public key(s) must be available when MCUBoot image is built. There is a script
32``bl2/ext/mcuboot/scipt/imgtool.py`` which can generate a new key pair, and
33extract the public key part in the expected ASN.1 format and encode it as C
34structure. The script is also capable of signing the image with the private key.
35In order to identify and validate the corresponding public key during image
36verification the hash of the public key is appended to the image manifest area
37(TLV encoded metadata). During image verification the bootloader retrieves the
38hash of the public key from the manifest area and compare against the on-the-fly
39calculated hash value of the built-in public keys. An exact match identifies and
40validates the public key which must be used for image verification.
41
42Current memory layout::
43
44    |----------------------|
45    |                      |
46    |     MCUBoot code     |
47    |                      |
48    |   Full public key    |
49    |                      |
50    |----------------------|
51    |                      |
52    |       Image          |
53    |                      |
54    |----------------------|
55    |  Image Manifest(TLV) |
56    |                      |
57    |  Hash of public key  |
58    |----------------------|
59    |                      |
60    |   Rest of memory     |
61    |                      |
62
63Requirements
64------------
65
66- Multiple independent vendor scenario must be supported, when more than one
67  ROTPK is provisioned to the device.
68- The corresponding public key for image verification must be identifiable and
69  verifiable.
70- Key identity must be immutable and anchored to the device itself.
71- Key(s) can be provisioned independently from bootloader.
72
73Design proposal
74---------------
75HW key(s) might stored in OTP memory which is an expensive resource, so
76storing a large key (such as RSA) is inefficient. Therefore, it is assumed that
77only the hash of the ROTPK will be stored in the HW. If only the hash of the
78public key is stored in the HW then the whole public key must be transfered to
79the device, because it must be available during image verification. This
80transfer can be done in the same way as how the hash of the key is transfered
81to the device with the current solution. A new TLV type (TLV_KEY) can be
82introduced to carry the whole public key. The corresponding public key will be
83appended to the image itself in the manifest area. It has the drawback that the
84image will be bigger, but it is assumed that the additional cost of the bigger
85image (extra flash area + power for download) is less than the cost of the OTP
86area.
87
88The verification flow:
89
90 - Look up the TLV_KEY field to get the public key.
91 - Calculates its hash(SHA256) value.
92 - Get the hash of ROTPK from the platform layer (stored in HW)
93 - Compare the two hash values, if they match then the key can be used to
94   validate the image. In case of failure consider the images as unauthenticated.
95
96Proposed memory layout::
97
98    |----------------------|
99    |                      |
100    |     MCUBoot code     |
101    |                      |
102    |    NO PUBLIC KEY     |
103    |                      |
104    |----------------------|
105    |                      |
106    |       Image          |
107    |                      |
108    |----------------------|
109    |  Image Manifest(TLV) |
110    |                      |
111    |   Full public key    |
112    |----------------------|
113    |                      |
114    |                      |
115    |   Rest of memory     |
116    |                      |
117    |                      |
118    |----------------------|
119    |   Immutable memory   |
120    |                      |
121    |  Hash of public key  |
122    |----------------------|
123    |                      |
124
125Platform support
126----------------
127
128A new platform API used by the bootloader must be introduced to retrieve the
129image corresponding hash of ROTPK:
130
131``enum tfm_plat_err_t tfm_plat_get_rotpk_hash(uint8_t image_id,
132uint8_t *rotpk_hash, uint32_t *rotpk_hash_size);``
133
134The mapping between image identity and public key can be hard-code in the
135platform layer. This simplifies the validation of the public key, because no
136look-up would be needed. It is assumed that the memory area of the ROTPK hash is
137not directly accessible, therefore a buffer is allocated by the caller to store
138the hash there.
139
140Compile time configurability
141----------------------------
142
143The solution must be compile time configurable in order to be able to switch
144between built-in key(s) and HW key(s) support, and also due to backwards
145compatibility.
146
147Tooling
148-------
149
150``bl2/ext/mcuboot/scipt/imgtool.py`` will be modified to include the whole
151public key to the TLV area (instead of the hash).
152
153Table to compare the current and proposed solution::
154
155    |---------|-----------------------|-------------------|--------------------|
156    |         |Key format in manifest |Key in MCUBoot code|     Key in HW      |
157    |---------|-----------------------|-------------------|--------------------|
158    |Proposed |    Full public key    |  No key embedded  | Hash of public key |
159    |---------|-----------------------|-------------------|--------------------|
160    |Current  |   Hash of public key  |  Full public key  |   No key in HW     |
161    |---------|-----------------------|-------------------|--------------------|
162
163--------------
164
165*Copyright (c) 2019, Arm Limited. All rights reserved.*
166