Lines Matching +full:user +full:- +full:otp
7 and in both cases all keys are created in the kernel, and user space sees,
10 system. All user level blobs, are displayed and loaded in hex ASCII for
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
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
51 the OTP key can be done via a module parameter (dcp_use_otp_key).
105 TPMs have well-documented, standardized interfaces and APIs.
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.
131 ------------
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
194 #> tsscreateprimary -hi o -st
196 #> tssevictcontrol -hi o -ho 80000000 -hp 81000001
200 #> tpm2_createprimary --hierarchy o -G rsa2048 -c key.ctxt
202 #> tpm2_evictcontrol -c key.ctxt 0x81000001
226 are sha1, sha256, sha384, sha512 and sm3-256.
236 Trusted Keys can be 32 - 128 bytes (256 - 1024 bits), the upper limit is to fit
240 -----------------------
250 in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
253 ------------------------
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 -----------------------
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 --------------------
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'
300 -------------------------------------------
315 -3 --alswrv 500 500 keyring: _ses
316 97833714 --alswrv 500 -1 \_ keyring: _uid.500
317 440502848 --alswrv 500 500 \_ trusted: kmk
364 compromised by a user level problem, and when sealed to a platform integrity
395 Instantiate an encrypted key "evm" using user-provided decrypted data::
397 $ evmkey=$(dd if=/dev/urandom bs=1 count=32 | xxd -c32 -p)
398 $ keyctl add encrypted evm "new default user:kmk 32 $evmkey" @u
402 default user:kmk 32 2375725ad57798846a9bbd240de8906f006e66c03af53b1b382d
418 ------------------------
455 phrase. This is used by most user space consumers to decide whether
475 ---------------
477 .. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c
480 .. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c