Lines Matching +full:initial +full:- +full:key
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
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
50 +-------------------------------------+ +--------------+
52 | +----------++---------------------+ | | +----------+ |
55 | | || | | <- PSA -> | | | |
56 | | Secure || Trusted Firmware-M | | APIs | | Zephyr | |
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:
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
93 thanks to the public signing key(s) built into it. As the name implies,
97 services and components in TF-M, such as the Secure Partition Manager (SPM),
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
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,
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
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
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:
155 * Public signing key(s) are baked into the bootloader
159 * By default, uses static flash layout of two identically-sized memory regions
165 * Hashing and signing are applied over the un-encrypted data
166 * Uses ``AES-CTR-128`` or ``AES-CTR-256`` for encryption
167 * Encryption key randomized every encryption cycle (via ``imgtool``)
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.
184 Once the secure bootloader has finished executing, a TF-M based secure image
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/``
197 ---------------
199 As of TF-M 1.8.0, the following secure services are generally available (although vendor support ma…
203 * Initial Attestation
213 `TF-M Documentation <https://tf-m-user-guide.trustedfirmware.org/>`__.
215 Key Management and Derivation
216 -----------------------------
218 Key and secret management is a critical part of any secure device. You need to
219 ensure that key material is available to regions that require it, but not to
223 The **Internal Trusted Storage** service in TF-M is used by the **PSA Crypto**
226 Crypto operations that make use of key material, such as when signing payloads
227 or when decrypting sensitive data, all take place via key handles. At no point
228 should the key material ever be exposed to the NS environment.
231 processing environment as a one-way operation, such as during a factory
234 new private key itself, and the public key for that can be requested during
235 provisioning and logged in the factory. This ensures the private key
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
249 value (depending on the key derivation algorithm used). This removes the
253 ``TFM_CRYPTO_ALG_HUK_DERIVATION`` identifies the default key derivation
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