Lines Matching refs:to
13 TF-M has several keys that are bound to the device itself instead of a secure
16 referred to as "builtin keys", and include (but are not limited to):
22 which requires some key-loading logic to be implemented by that partition. The
34 handle, which can be leveraged to allow TF-M to define a set of handles for the
37 Defining these constant handles allows these keys to be used by secure partition
38 and non-secure callers (subject to access policy), via the standard PSA crypto
41 Ideally, it would be possible to just have PSA builtin keys that are stored in
50 The PSA crypto driver API allows most PSA Crypto APIs to defer their operation
51 to an accelerator driver in preference of the software implementation. It also
52 adds the concept of storage locations for keys, which is used to access keys
68 1) A request is made to a PSA Crypto API that references a key by a key
74 in ``crypto_keys.h``. This function maps each builtin key to a driver, which
77 number, which is a driver-specific index to specify the key.
81 to the TF-M builtin keys driver) calls the previously hooked function
84 ``tfm_key_loader_get_builtin_key_len``, allow Mbed TLS to copy the
86 calls to using that same builtin key ID are made.
88 In order to load the keys into the tfm_key_loader memory (in the crypto
103 considers to be builtin keys. A platform can specify extra builtin key IDs by
104 setting the ``PLATFORM_DEFAULT_CRYPTO_KEYS`` variable to ``OFF``, creating the
112 public information. TF-M must mediate access to the keys, which is done in the
114 function maps the caller ID to a particular key usage, which allows granular key
116 not have permission to use the key.
123 requires keys that are bound to a particular context. For example, Protected
124 Storage derives keys uniquely for each user of the service which are used to
125 encrypt each user's files. In order to provide HUK derivation to every secure
139 to derive the same keys as other NS callers.
141 For keys that are not exposed outside the device, this is transparent to the
142 service that is using the key derivation, as they have no access to the builtin
146 public key is used to verify attestation tokens) so the actual builtin key is
149 The decision has been taken to derive platform keys for any key that can be used
160 are keys where the key material is directly accessible to the PSA Crypto core),
161 so some modifications had to be made. Opaque keyslots have the same basic
162 structure as standard transparent keyslots, and can be passed to the functions
164 may not continue to work in future versions. Therefore, the only modification
165 required currently is to force keys that have the location
166 ``TFM_BUILTIN_KEY_LOADER_KEY_LOCATION`` to be passed to the functions that only