Lines Matching full:key
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,
13 Trusted Keys as Protected key
15 It is the secure way of keeping the keys in the kernel key-ring as Trusted-Key,
18 - Key-blob, an encrypted key-data, created to be stored, loaded and seen by
20 - Key-data, the plain-key text in the system memory, to be used by
23 Though key-data is not accessible to the user-space in plain-text, but it is in
26 attack accessing the system memory can lead to a chance of the key getting
29 In order to protect the key in kernel space, the concept of "protected-keys" is
30 introduced which will act as an added layer of protection. The key-data of the
31 protected keys is encrypted with Key-Encryption-Key(KEK), and decrypted inside
32 the trust source boundary. The plain-key text never available out-side in the
34 protected key, can only be done by the trust source, which generated the
35 key blob.
37 Hence, if the protected-key is leaked or compromised, it is of no use to the
43 - Key-Blob, to be loaded, stored and seen by user-space.
61 Rooted to Storage Root Key (SRK) which never leaves the TPM that
66 Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
72 mode, trust is rooted to the OTPMK, a never-disclosed 256-bit key
74 Otherwise, a common fixed test key is used instead.
78 Rooted to a one-time programmable key (OTP) that is generally burnt
80 DCP provides two keys that can be used as root of trust: the OTP key
81 and the UNIQUE key. Default is to use the UNIQUE key, but selecting
82 the OTP key can be done via a module parameter (dcp_use_otp_key).
102 environment. Only basic blob key encryption is executed there.
103 The actual key sealing/unsealing is done on main processor/kernel space.
111 verifications match. A loaded Trusted Key can be updated with new
113 such as when the kernel and initramfs are updated. The same key can
158 Key Generation
165 a child key in the storage key hierarchy. Encryption and decryption of the
166 child key must be protected by a strong access control policy within the
203 using a specified ‘master’ key. The ‘master’ key can either be a trusted-key or
204 user-key type. The main disadvantage of encrypted keys is that if they are not
205 rooted in a trusted key, they are only as secure as the user key encrypting
206 them. The master user key should therefore be loaded in as secure a way as
220 TPM 2.0: The user must first create a storage key and make it persistent, so the
221 key is available after reboot. This can be done using the following commands.
231 #> tpm2_createprimary --hierarchy o -G rsa2048 -c key.ctxt
233 #> tpm2_evictcontrol -c key.ctxt 0x81000001
240 keyctl update key "update [options]"
244 keyhandle= ascii hex value of sealing key
247 keyauth= ascii hex auth for sealing key default 0x00...i
263 seal the key.
265 "keyctl print" returns an ascii hex copy of the sealed key, which is in standard
266 TPM_STORED_DATA format. The key length for new keys are always in bytes.
279 "keyctl print" returns an ASCII hex copy of the sealed key, which is in format
280 specific to TEE device implementation. The key length for new keys is always
292 "keyctl print" returns an ASCII hex copy of the sealed key, which is in a
293 CAAM-specific format. The key length for new keys is always in bytes.
302 where, 'pk' is used to direct trust source to generate protected key.
307 "keyctl print" returns an ASCII hex copy of the sealed key, which is in a
308 CAAM-specific format. The key length for new keys is always in bytes.
320 "keyctl print" returns an ASCII hex copy of the sealed key, which is in format
321 specific to this DCP key-blob implementation. The key length for new keys is
328 key or a more complex structure. The format of the more complex structure is
333 keyctl add encrypted name "new [format] key-type:master-key-name keylen"
335 keyctl add encrypted name "new [format] key-type:master-key-name keylen
338 keyctl update keyid "update key-type:master-key-name"
343 key-type:= 'trusted' | 'user'
345 Examples of trusted and encrypted key usage
348 Create and save a trusted key named "kmk" of length 32 bytes.
350 Note: When using a TPM 2.0 with a persistent key with handle 0x81000001,
377 Load a trusted key from the saved blob::
392 Create and save a trusted key as protected key named "kmk" of length 32 bytes.
417 Load a trusted key from the saved blob::
432 Reseal (TPM specific) a trusted key under new PCR values::
448 quality symmetric key for HMAC protection of file metadata. The use of a
449 trusted key provides strong guarantees that the EVM key has not been
452 encrypted key "evm" using the above trusted key "kmk":
471 Load an encrypted key "evm" from saved blob::
481 Instantiate an encrypted key "evm" using user-provided decrypted data::
503 TPM 2.0 ASN.1 Key Format
506 The TPM 2.0 ASN.1 key format is designed to be easily recognisable,
519 type is what distinguishes the key even in binary form since the OID
521 binary pattern at offset 3 in the key. The OIDs currently made
524 2.23.133.10.1.3 TPM Loadable key. This is an asymmetric key (Usually
528 2.23.133.10.1.4 TPM Importable Key. This is an asymmetric key (Usually
534 represents a symmetric key and must be unsealed before
537 The trusted key code only uses the TPM Sealed Data OID.
539 emptyAuth is true if the key has well known authorization "". If it
540 is false or not present, the key requires an explicit authorization
544 parent represents the parent key handle, either in the 0x81 MSO space,
545 like 0x81000001 for the RSA primary storage key. Userspace programmes
547 this happens the Elliptic Curve variant of the primary key using the