1#######################################
2Rollback protection in TF-M secure boot
3#######################################
4
5:Author: Tamas Ban
6:Organization: Arm Limited
7:Contact: Tamas Ban <tamas.ban@arm.com>
8
9Anti-rollback protection
10========================
11The goal of anti-rollback protection is to prevent downgrading of the device to
12an older version of its software, which has been deprecated due to security
13concerns.
14
15Elements of software upgrade
16============================
17During a software upgrade the following entities are involved:
18
19 - Boot loader
20 - Manifest data: Metadata of the software image: size, version, hash,
21   signature, etc.
22 - Software image: binary data, elf, etc.
23
24Validation of new image
25=======================
26Boot loader is responsible to authenticate the new image according to the
27required policies and decide whether the new image is fulfilling all the
28requirements. Boot loader verifies the image integrity (hash calculation) and
29the origination (signature validation), and might verify other requirements as
30well. If the new image is successfully authenticated then the boot loader is in
31charge to do the necessary steps (load to execute address, etc.) to enable the
32new image to be executed. During the validation process the image and the
33manifest data is checked.
34
35Manifest format in MCUBoot
36==========================
37MCUBoot has a custom manifest format, which is composed of two parts:
38
39 - Image header: Prepended to the beginning of the image.
40   It is integrity protected:
41 - TLV section: Appended to the end of the image. It is not integrity protected:
42
43  - Hash of public key, hash of image, signature of image
44
45.. code-block:: c
46
47    struct image_header {
48        uint32_t ih_magic;
49        uint32_t ih_load_addr;
50        uint16_t ih_hdr_size;
51        uint16_t _pad1;
52        uint32_t ih_img_size;
53        uint32_t ih_flags;
54        struct image_version ih_ver;
55        uint32_t _pad2;
56    };
57
58Security counter
59================
60The aim of a security counter is to have an independent (from the image version)
61counter in the image manifest to ensure anti-rollback protection. During
62software release the value of this counter must be increased if a security flaw
63was fixed in the current version. Later when this image is installed on the
64device then it is not allowed to go back to earlier versions. It is beneficial
65to handle this counter independently from image main version number:
66
67 - It does not need to increase with each software release
68 - It makes it possible to do software downgrade to some extent: if the security
69   counter has the same value in the older image then it is accepted.
70 - If the boot loader verifies multiple images then these can be handled
71   independently.
72
73However, as an alternative solution the image version number also could serve
74as the security counter of the image. Even the version number itself could be
75checked during the anti-rollback verification or the value of the security
76counter could be derived from the image main version. It is the responsibility
77of the software issuer to define which policy to apply.
78
79Implementation of security counter
80==================================
81The value of the security counter is a security critical data. Any change in
82its value has a security implication. Therefore it must be in the integrity
83protected part of the image manifest. Because the image header is almost fully
84utilized (few unused fields) and the change of image header structure could
85lead to compatibility issues between boot loader and runtime software, it is
86proposed to extend the integrity protection to some part of the TLV section.
87One of the unused fields in the image header can be used to store the size of
88the integrity protected area of the TLV section. This is necessary to know how
89to calculate properly the image hash and signature. With this extension of the
90integrity protected area other attributes that require integrity protection
91can easily be added to the image manifest.
92
93Trusted non-volatile (NV) counters
94==================================
95The Trusted Base System Architecture (TBSA-M) defines non-volatile (NV) counters
96or version counters as a counter with the following properties:
97
98 - It must only be possible to increment a version counter through a Trusted
99   access.
100 - It must only be possible to increment a version counter. It must not be
101   possible to decrement it.
102 - When a version counter reaches its maximum value, it must not roll over,
103   and no further changes must be possible.
104 - A version counter must be non-volatile, and the stored value must survive
105   a power down period up to the lifetime of the device.
106
107Trusted non-volatile counters can be used to store the value of security
108counters per updatable software image. Ideally all independently updatable
109software images should have a separate security counter. In current TF-M
110implementation the BL2 is not updatable and the secure and non-secure images
111are updated together as a single binary. Therefore, one counter is enough to
112implement rollback protection. In future the secure and non-secure binaries
113will be handled independently; at that time the introduction of a second
114counter will be necessary.
115
116Currently the NV counters can be manipulated through the interface described
117in ``tfm_plat_nv_counters.h``.
118
119NV counters and anti-rollback protection
120========================================
121Trusted non-volatile counters might not be supported by a hardware platform.
122In this case anti-rollback protection might still be feasible.
123
124The device threat model needs to consider the following aspects:
125
126 - What is the trust level of the boot loader towards the active software
127
128  - If the boot loader cannot protect the anti-rollback mechanism from the
129    secure image then the following threat is unmitigated: The content of the
130    memory area which holds the active image could be replaced with a valid but
131    an older version of the software with software only attack, i.e.: remote
132    code execution.
133  - If the boot loader does not trust the loaded image at all then security
134    counter must have a copy in NV counter area.
135
136 - Another aspect to consider is where the active image is stored
137
138  - Trusted memory: i.e. on-chip flash (eFlash). The threat that a malicious
139    actor can modify the content of trusted memory with HW attack is out of
140    scope for the current implementation. It is assumed that if an active image
141    and related manifest data is stored in trusted memory then the included
142    security counter cannot be compromised.
143  - Untrusted memory: i.e. external (off-chip) storage, where malicious actor
144    can physically access it so it is possible to modify its content, therefore
145    the value of included security counter is unreliable.
146
147If the active image is stored in untrusted storage and it is feasible to modify
148its content (i.e. replace the whole image to an older version including
149corresponding manifest) then the value of security counter must be copied to
150the NV counter area. During software validation the boot loader must compare
151the new image's security counters against the security counter stored in
152non-volatile counters.
153
154If the active image is stored in trusted memory and boot loader trusts in the
155active software then it is not mandatory to store the security counter to
156non-volatile counter area. During software validation the boot loader is
157allowed to compare the new image's security counters against active image's
158security counter.
159
160The evaluation of trusted and untrusted memory must be done per target platform
161during threat modelling.
162
163For the most robust implementation the following principles should be applied:
164
165 - Always use NV counters for storing security counter value if supported by
166   the hardware.
167 - Each software stage must not be able to decrease their corresponding NV
168   counter.
169
170Boot flow with anti-rollback protection
171=======================================
172During software upgrade as part of the image validation process the new and
173active image security counters must be compared. The new image can be accepted
174if its security counter has a greater or equal value than the active image
175security counter. From where to extract the active image security counter it
176can be platform dependent. It might read out directly from active image
177manifest data (only if it is in trusted memory) or the corresponding
178non-volatile counter is read.
179
180If non-volatile counters are used to save security counters then their value
181must be updated:
182
183 - If the boot loader does not support to revert previous images (just
184   overwrites the previously active image with the new one) in case of faulty
185   update then the non-volatile counter can be updated to be equal with the
186   new image security counter after successful authentication of the new image.
187 - If revert is supported then non-volatile counter can be updated just after
188   a test run of the new software when its health check is done. Just in case
189   of successful health check can the counter updated to avoid the prevention
190   of the revert. This might require a secondary restart of the device.
191
192Tool support
193============
194There is a Python script, ``imgtool.py`` which is used to prepare the new image
195for upgrade (add header, sign the image, append TLV section). This script must
196be modified to get an additional command line argument which serves as security
197counter. The security counter must be included in the integrity protected part
198of the TLV section.
199
200--------------
201
202*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
203