1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
..
# Copyright (c) 2022-2023, Arm Limited.
#
# SPDX-License-Identifier: MIT
######################
Software architecture
######################
*****************
Arm Corstone-1000
*****************
Arm Corstone-1000 is a reference solution for IoT devices. It is part of
Total Solution for IoT which consists of hardware and software reference
implementation.
Corstone-1000 software plus hardware reference solution is PSA Level-2 ready
certified (`PSA L2 Ready`_) as well as System Ready IR certified(`SRIR cert`_).
More information on the Corstone-1000 subsystem product and design can be
found at:
`Arm corstone1000 Software`_ and `Arm corstone1000 Technical Overview`_.
This readme explicitly focuses on the software part of the solution and
provides internal details on the software components. The reference
software package of the platform can be retrieved following instructions
present in the user-guide document.
***************
Design Overview
***************
The software architecture of Corstone-1000 platform is a reference
implementation of Platform Security Architecture (`PSA`_) which provides
framework to build secure IoT devices.
The base system architecture of the platform is created from three
different types of systems: Secure Enclave, Host and External System.
Each subsystem provides different functionality to overall SoC.
.. image:: images/CorstoneSubsystems.png
:width: 720
:alt: CorstoneSubsystems
The Secure Enclave System, provides PSA Root of Trust (RoT) and
cryptographic functions. It is based on an Cortex-M0+ processor,
CC312 Cryptographic Accelerator and peripherals, such as watchdog and
secure flash. Software running on the Secure Enclave is isolated via
hardware for enhanced security. Communication with the Secure Encalve
is achieved using Message Handling Units (MHUs) and shared memory.
On system power on, the Secure Enclave boots first. Its software
comprises of a ROM code (TF-M BL1), Mcuboot BL2, and
TrustedFirmware-M(`TF-M`_) as runtime software. The software design on
Secure Enclave follows Firmware Framework for M class
processor (`FF-M`_) specification.
The Host System is based on ARM Cotex-A35 processor with standardized
peripherals to allow for the booting of a Linux OS. The Cortex-A35 has
the TrustZone technology that allows secure and non-secure security
states in the processor. The software design in the Host System follows
Firmware Framework for A class procseeor (`FF-A`_) specification.
The boot process follows Trusted Boot Base Requirement (`TBBR`_).
The Host Subsystem is taken out of reset by the Secure Enclave system
during its final stages of the initialization. The Host subsystem runs
FF-A Secure Partitions(based on `Trusted Services`_) and OPTEE-OS
(`OPTEE-OS`_) in the secure world, and U-Boot(`U-Boot repo`_) and
linux (`linux repo`_) in the non-secure world. The communication between
non-secure and the secure world is performed via FF-A messages.
An external system is intended to implement use-case specific
functionality. The system is based on Cortex-M3 and run RTX RTOS.
Communication between the external system and Host (Cortex-A35) is performed
using MHU as transport mechanism and rpmsg messaging system (the external system
support in Linux is disabled in this release. More info about this change can be found in the
release-notes).
Overall, the Corstone-1000 architecture is designed to cover a range
of Power, Performance, and Area (PPA) applications, and enable extension
for use-case specific applications, for example, sensors, cloud
connectivitiy, and edge computing.
*****************
Secure Boot Chain
*****************
For the security of a device, it is essential that only authorized
software should run on the device. The Corstone-1000 boot uses a
Secure Boot Chain process where an already authenticated image verifies
and loads the following software in the chain. For the boot chain
process to work, the start of the chain should be trusted, forming the
Root of Trust (RoT) of the device. The RoT of the device is immutable in
nature and encoded into the device by the device owner before it
is deployed into the field. In Corstone-1000, the BL1 image of the secure
enclave and content of the CC312 OTP (One Time Programmable) memory
forms the RoT. The BL1 image exists in ROM (Read Only Memory).
.. image:: images/SecureBootChain.png
:width: 870
:alt: SecureBootChain
It is a lengthy chain to boot the software on Corstone-1000. On power on,
the secure enclave starts executing BL1 code from the ROM which is the RoT
of the device. Authentication of an image involves the steps listed below:
- Load image from flash to dynamic RAM.
- The public key present in the image header is validated by comparing with the hash.
Depending on the image, the hash of the public key is either stored in the OTP or part
of the software which is being already verified in the previous stages.
- The image is validated using the public key.
In the secure enclave, BL1 authenticates the BL2 and passes the execution
control. BL2 authenticates the initial boot loader of the host (Host TF-A BL2)
and TF-M. The execution control is now passed to TF-M. TF-M being the run
time executable of secure enclave which initializes itself and, at the end,
brings the host CPU out of rest. The host follows the boot standard defined
in the `TBBR`_ to authenticate the secure and non-secure software.
***************
Secure Services
***************
Corstone-1000 is unique in providing a secure environment to run a secure
workload. The platform has TrustZone technology in the Host subsystem but
it also has hardware isolated secure enclave environment to run such secure
workloads. In Corstone-1000, known Secure Services such as Crypto, Protected
Storage, Internal Trusted Storage and Attestation are available via PSA
Functional APIs in TF-M. There is no difference for a user communicating to
these services which are running on a secure enclave instead of the
secure world of the host subsystem. The below diagram presents the data
flow path for such calls.
.. image:: images/SecureServices.png
:width: 930
:alt: SecureServices
The SE Proxy SP (Secure Enclave Proxy Secure Partition) is a proxy partition
managed by OPTEE which forwards such calls to the secure enclave. The
solution relies on OpenAMP which uses shared memory and MHU interrupts as
a doorbell for communication between two cores. Corstone-1000 implements
isolation level 2. Cortex-M0+ MPU (Memory Protection Unit) is used to implement
isolation level 2.
For a user to define its own secure service, both the options of the host
secure world or secure encalve are available. It's a trade-off between
lower latency vs higher security. Services running on a secure enclave are
secure by real hardware isolation but have a higher latency path. In the
second scenario, the services running on the secure world of the host
subsystem have lower latency but virtual hardware isolation created by
TrustZone technology.
**********************
Secure Firmware Update
**********************
Apart from always booting the authorized images, it is also essential that
the device only accepts the authorized (signed) images in the firmware update
process. Corstone-1000 supports OTA (Over the Air) firmware updates and
follows Platform Security Firmware Update specification (`FWU`_).
As standardized into `FWU`_, the external flash is divided into two
banks of which one bank has currently running images and the other bank is
used for staging new images. There are four updatable units, i.e. Secure
Enclave's BL2 and TF-M, and Host's FIP (Firmware Image Package) and Kernel
Image (the initramfs bundle). The new images are accepted in the form of a UEFI capsule.
.. image:: images/ExternalFlash.png
:width: 690
:alt: ExternalFlash
When Firmware update is triggered, u-boot verifies the capsule by checking the
capsule signature, version number and size. Then it signals the Secure Enclave
that can start writing UEFI capsule into the flash. Once this operation finishes
,Secure Enclave resets the entire system.
The Metadata Block in the flash has the below firmware update state machine.
TF-M runs an OTA service that is responsible for accepting and updating the
images in the flash. The communication between the UEFI Capsule update
subsystem and the OTA service follows the same data path explained above.
The OTA service writes the new images to the passive bank after successful
capsule verification. It changes the state of the system to trial state and
triggers the reset. Boot loaders in Secure Enclave and Host read the Metadata
block to get the information on the boot bank. In the successful trial stage,
the acknowledgment from the host moves the state of the system from trial to
regular. Any failure in the trial stage or system hangs leads to a system
reset. This is made sure by the use of watchdog hardware. The Secure Enclave's
BL1 has the logic to identify multiple resets and eventually switch back to the
previous good bank. The ability to revert to the previous bank is crucial to
guarantee the availability of the device.
.. image:: images/SecureFirmwareUpdate.png
:width: 430
:alt: SecureFirmwareUpdate
******************************
UEFI Runtime Support in U-Boot
******************************
Implementation of UEFI boottime and runtime APIs require variable storage.
In Corstone-1000, these UEFI variables are stored in the Protected Storage
service. The below diagram presents the data flow to store UEFI variables.
The U-Boot implementation of the UEFI subsystem uses the U-Boot FF-A driver to
communicate with the SMM Service in the secure world. The backend of the
SMM service uses the proxy PS from the SE Proxy SP. From there on, the PS
calls are forwarded to the secure enclave as explained above.
.. image:: images/UEFISupport.png
:width: 590
:alt: UEFISupport
***************
References
***************
`ARM corstone1000 Search`_
`Arm security features`_
--------------
*Copyright (c) 2022-2023, Arm Limited. All rights reserved.*
.. _Arm corstone1000 Technical Overview: https://developer.arm.com/documentation/102360/0000
.. _Arm corstone1000 Software: https://developer.arm.com/Tools%20and%20Software/Corstone-1000%20Software
.. _Arm corstone1000 Search: https://developer.arm.com/search#q=corstone-1000
.. _Arm security features: https://www.arm.com/architecture/security-features/platform-security
.. _linux repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
.. _FF-A: https://developer.arm.com/documentation/den0077/latest
.. _FF-M: https://developer.arm.com/architectures/Firmware%20Framework%20for%20M-Profile
.. _FWU: https://developer.arm.com/documentation/den0118/a/
.. _OPTEE-OS: https://github.com/OP-TEE/optee_os
.. _PSA: https://www.psacertified.org/
.. _PSA L2 Ready: https://www.psacertified.org/products/corstone-1000/
.. _SRIR cert: https://armkeil.blob.core.windows.net/developer/Files/pdf/certificate-list/arm-systemready-ir-certification-arm-corstone-1000.pdf
.. _TBBR: https://developer.arm.com/documentation/den0006/latest
.. _TF-M: https://www.trustedfirmware.org/projects/tf-m/
.. _Trusted Services: https://www.trustedfirmware.org/projects/trusted-services/
.. _U-Boot repo: https://github.com/u-boot/u-boot.git
|