Lines Matching +full:key +full:- +full:2
5 Trusted and Encrypted Keys are two new key types added to the existing kernel
6 key ring service. Both of these new types are variable length symmetric keys,
30 Rooted to Storage Root Key (SRK) which never leaves the TPM that
33 (2) TEE (Trusted Execution Environment: OP-TEE based on Arm TrustZone)
35 Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
41 mode, trust is rooted to the OTPMK, a never-disclosed 256-bit key
43 Otherwise, a common fixed test key is used instead.
45 (4) DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs)
47 Rooted to a one-time programmable key (OTP) that is generally burnt
48 in the on-chip fuses and is accessible to the DCP encryption engine only.
49 DCP provides two keys that can be used as root of trust: the OTP key
50 and the UNIQUE key. Default is to use the UNIQUE key, but selecting
51 the OTP key can be done via a module parameter (dcp_use_otp_key).
59 (2) TEE
71 environment. Only basic blob key encryption is executed there.
72 The actual key sealing/unsealing is done on main processor/kernel space.
80 verifications match. A loaded Trusted Key can be updated with new
82 such as when the kernel and initramfs are updated. The same key can
86 (2) TEE
105 TPMs have well-documented, standardized interfaces and APIs.
107 (2) TEE
109 TEEs have well-documented, standardized client interface and APIs. For
110 more details refer to ``Documentation/driver-api/tee.rst``.
118 Vendor-specific API that is implemented as part of the DCP crypto driver in
119 ``drivers/crypto/mxs-dcp.c``.
124 purpose must be assessed when using them to protect security-relevant data.
127 Key Generation
131 ------------
134 a child key in the storage key hierarchy. Encryption and decryption of the
135 child key must be protected by a strong access control policy within the
144 * TEE: OP-TEE based on Arm TrustZone based RNG
156 * DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs)
164 command-line to override the used RNG with the kernel's random number pool.
167 --------------
170 for encryption/decryption. New keys are created either from kernel-generated
171 random numbers or user-provided decrypted data, and are encrypted/decrypted
172 using a specified ‘master’ key. The ‘master’ key can either be a trusted-key or
173 user-key type. The main disadvantage of encrypted keys is that if they are not
174 rooted in a trusted key, they are only as secure as the user key encrypting
175 them. The master user key should therefore be loaded in as secure a way as
183 -----------------------
187 time with the TrouSerS utility: "tpm_takeownership -u -z".
189 TPM 2.0: The user must first create a storage key and make it persistent, so the
190 key is available after reboot. This can be done using the following commands.
192 With the IBM TSS 2 stack::
194 #> tsscreateprimary -hi o -st
196 #> tssevictcontrol -hi o -ho 80000000 -hp 81000001
198 Or with the Intel TSS 2 stack::
200 #> tpm2_createprimary --hierarchy o -G rsa2048 -c key.ctxt
202 #> tpm2_evictcontrol -c key.ctxt 0x81000001
209 keyctl update key "update [options]"
213 keyhandle= ascii hex value of sealing key
216 keyauth= ascii hex auth for sealing key default 0x00...i
225 allowed value is sha1. For TPM 2.x the allowed values
226 are sha1, sha256, sha384, sha512 and sm3-256.
232 seal the key.
234 "keyctl print" returns an ascii hex copy of the sealed key, which is in standard
235 TPM_STORED_DATA format. The key length for new keys are always in bytes.
236 Trusted Keys can be 32 - 128 bytes (256 - 1024 bits), the upper limit is to fit
240 -----------------------
248 "keyctl print" returns an ASCII hex copy of the sealed key, which is in format
249 specific to TEE device implementation. The key length for new keys is always
250 in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
253 ------------------------
261 "keyctl print" returns an ASCII hex copy of the sealed key, which is in a
262 CAAM-specific format. The key length for new keys is always in bytes.
263 Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
266 -----------------------
274 "keyctl print" returns an ASCII hex copy of the sealed key, which is in format
275 specific to this DCP key-blob implementation. The key length for new keys is
276 always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
279 --------------------
282 key or a more complex structure. The format of the more complex structure is
287 keyctl add encrypted name "new [format] key-type:master-key-name keylen"
289 keyctl add encrypted name "new [format] key-type:master-key-name keylen
290 decrypted-data" ring
292 keyctl update keyid "update key-type:master-key-name"
297 key-type:= 'trusted' | 'user'
299 Examples of trusted and encrypted key usage
300 -------------------------------------------
302 Create and save a trusted key named "kmk" of length 32 bytes.
304 Note: When using a TPM 2.0 with a persistent key with handle 0x81000001,
315 -3 --alswrv 500 500 keyring: _ses
316 97833714 --alswrv 500 -1 \_ keyring: _uid.500
317 440502848 --alswrv 500 500 \_ trusted: kmk
331 Load a trusted key from the saved blob::
346 Reseal (TPM specific) a trusted key under new PCR values::
362 quality symmetric key for HMAC protection of file metadata. The use of a
363 trusted key provides strong guarantees that the EVM key has not been
366 encrypted key "evm" using the above trusted key "kmk":
373 option 2: explicitly defining 'format' as 'default'::
385 Load an encrypted key "evm" from saved blob::
395 Instantiate an encrypted key "evm" using user-provided decrypted data::
397 $ evmkey=$(dd if=/dev/urandom bs=1 count=32 | xxd -c32 -p)
417 TPM 2.0 ASN.1 Key Format
418 ------------------------
420 The TPM 2.0 ASN.1 key format is designed to be easily recognisable,
433 type is what distinguishes the key even in binary form since the OID
435 binary pattern at offset 3 in the key. The OIDs currently made
438 2.23.133.10.1.3 TPM Loadable key. This is an asymmetric key (Usually
442 2.23.133.10.1.4 TPM Importable Key. This is an asymmetric key (Usually
448 represents a symmetric key and must be unsealed before
451 The trusted key code only uses the TPM Sealed Data OID.
453 emptyAuth is true if the key has well known authorization "". If it
454 is false or not present, the key requires an explicit authorization
458 parent represents the parent key handle, either in the 0x81 MSO space,
459 like 0x81000001 for the RSA primary storage key. Userspace programmes
461 this happens the Elliptic Curve variant of the primary key using the
475 ---------------
477 .. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c
480 .. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c