Lines Matching +full:secure +full:- +full:only
1 Trusted Firmware-M Overview
4 `Trusted Firmware-M (TF-M) <https://tf-m-user-guide.trustedfirmware.org/>`__
6 `IoT Security Framework <https://www.psacertified.org/what-is-psa-certified/>`__.
10 Zephyr RTOS has been PSA Certified since Zephyr 2.0.0 with TF-M 1.0, and
11 is currently integrated with TF-M 2.1.0.
13 What Does TF-M Offer?
16 Through a set of secure services and by design, TF-M provides:
18 * Isolation of secure and non-secure resources
19 * Embedded-appropriate crypto
22 * Protected off-chip data storage and retrieval
29 When using TF-M with a supported platform, TF-M will be automatically built and
31 build process makes a number of assumptions about how TF-M is being used, and
35 * The secure processing environment (secure boot and TF-M) starts first
36 * Resource allocation for Zephyr relies on choices made in the secure image.
41 A TF-M application will, generally, have the following three parts, from most
42 to least trusted, left-to-right, with code execution happening in the same
43 order (secure boot > secure image > ns image).
45 While the secure bootloader is optional, it is enabled by default, and secure
46 boot is an important part of providing a secure solution:
50 +-------------------------------------+ +--------------+
51 | Secure Processing Environment (SPE) | | NSPE |
52 | +----------++---------------------+ | | +----------+ |
55 | | || | | <- PSA -> | | | |
56 | | Secure || Trusted Firmware-M | | APIs | | Zephyr | |
57 | | Boot || (Secure Image) | | | |(NS Image)| |
59 | +----------++---------------------+ | | +----------+ |
60 +-------------------------------------+ +--------------+
62 Communication between the (Zephyr) Non-Secure Processing Environment (NSPE) and
63 the (TF-M) Secure Processing Environment image happens based on a set of PSA
65 the TF-M build, and implemented in Zephyr
66 (see :zephyr_file:`modules/trusted-firmware-m/interface`).
71 TF-M is based upon a **Root of Trust (RoT)** architecture. This allows for
80 The following RoT hierarchy is defined for TF-M, from most to least trusted:
84 * PSA Immutable Root of Trust: secure boot
85 * PSA Updateable Root of Trust: most trusted secure services
86 * Application Root of Trust (**ARoT**): isolated secure services
89 system, to which subsequent Roots of Trust are anchored. In TF-M, this is the
90 secure boot image, which verifies that the secure and non-secure images are
92 secure bootloader also verifies new images during the firmware update process,
96 The **PSA Updateable Root of Trust** implements the most trusted secure
97 services and components in TF-M, such as the Secure Partition Manager (SPM),
98 and shared secure services like PSA Crypto, Internal Trusted Storage (ITS),
102 The **Application Root of Trust** is a reduced-privilege area in the secure
104 building TF-M, has limited access to the PRoT, or even other ARoT services at
106 Protected Storage (PS), and generally custom secure services that you implement
111 non-secure environment, and has the least privilege in the system. This is the
115 ----------------
117 At present, there are three distinct **isolation levels** defined in TF-M,
122 * **Isolation Level 1** is the lowest isolation level, and the only major
123 boundary is between the secure and non-secure processing environment,
124 usually by means of Arm TrustZone on Armv8-M processors. There is no
130 where ARoT services have limited access to PRoT services, and can only
142 Secure Boot
145 The default secure bootloader in TF-M is based on
146 `MCUBoot <https://www.mcuboot.com/>`__, and is referred to as ``BL2`` in TF-M
147 (for the second-stage bootloader, potentially after a HW-based bootloader on
148 the secure MCU, etc.).
150 All images in TF-M are hashed and signed, with the hash and signature verified
153 Some key features of MCUBoot as used in TF-M are:
159 * By default, uses static flash layout of two identically-sized memory regions
164 * Only the payload is encrypted (header, TLVs are plain text)
165 * Hashing and signing are applied over the un-encrypted data
166 * Uses ``AES-CTR-128`` or ``AES-CTR-256`` for encryption
168 * The ``AES-CTR`` key is included in the image and can be encrypted using:
170 * ``RSA-OAEP``
171 * ``AES-KW`` (128 or 256 bits depending on the ``AES-CTR`` key length)
172 * ``ECIES-P256``
173 * ``ECIES-X25519``
175 Key config properties to control secure boot in Zephyr are:
178 * :kconfig:option:`CONFIG_TFM_KEY_FILE_S` overrides the secure signing key.
179 * :kconfig:option:`CONFIG_TFM_KEY_FILE_NS` overrides the non-secure signing key.
181 Secure Processing Environment
184 Once the secure bootloader has finished executing, a TF-M based secure image
185 will begin execution in the **secure processing environment**. This is where
186 our device will be initially configured, and any secure services will be
189 Note that the starting state of our device is controlled by the secure firmware,
190 meaning that when the non-secure Zephyr application starts, peripherals may
191 not be in the HW-default reset state. In case of doubts, be sure to consult
192 the board support packages in TF-M, available in the ``platform/ext/target/``
193 folder of the TF-M module (which is in ``modules/tee/tf-m/trusted-firmware-m/``
196 Secure Services
197 ---------------
199 As of TF-M 1.8.0, the following secure services are generally available (although vendor support ma…
205 * Secure Storage, which has two parts:
213 `TF-M Documentation <https://tf-m-user-guide.trustedfirmware.org/>`__.
216 -----------------------------
218 Key and secret management is a critical part of any secure device. You need to
223 The **Internal Trusted Storage** service in TF-M is used by the **PSA Crypto**
225 private keys are only ever accessible to the secure processing environment.
230 One exception is that private keys can be provisioned into the secure
231 processing environment as a one-way operation, such as during a factory
238 TF-M also makes extensive use of the **Hardware Unique Key (HUK)**, which
239 every TF-M device must provide. This device-unique key is used by the
251 protected in secure devices, and inaccessible directly by users.
255 algorithm is ``HKDF`` (RFC 5869) with a SHA-256 hash. Other hardware
258 Non-Secure Processing Environment
261 Zephyr is used for the NSPE, using a board that is supported by TF-M where the
266 to run in the NSPE, correctly build and link it with the TF-M secure images,
267 sign the secure and non-secure images, and merge the three binaries into a
268 single ``tfm_merged.hex`` file. The :ref:`west flash <west-flashing>` command
271 At present, Zephyr can not be configured to be used as the secure processing