mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-30 03:27:44 -04:00
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: (54 commits) tpm_nsc: Fix bug when loading multiple TPM drivers tpm: Move tpm_tis_reenable_interrupts out of CONFIG_PNP block tpm: Fix compilation warning when CONFIG_PNP is not defined TOMOYO: Update kernel-doc. tpm: Fix a typo tpm_tis: Probing function for Intel iTPM bug tpm_tis: Fix the probing for interrupts tpm_tis: Delay ACPI S3 suspend while the TPM is busy tpm_tis: Re-enable interrupts upon (S3) resume tpm: Fix display of data in pubek sysfs entry tpm_tis: Add timeouts sysfs entry tpm: Adjust interface timeouts if they are too small tpm: Use interface timeouts returned from the TPM tpm_tis: Introduce durations sysfs entry tpm: Adjust the durations if they are too small tpm: Use durations returned from TPM TOMOYO: Enable conditional ACL. TOMOYO: Allow using argv[]/envp[] of execve() as conditions. TOMOYO: Allow using executable's realpath and symlink's target as conditions. TOMOYO: Allow using owner/group etc. of file objects as conditions. ... Fix up trivial conflict in security/tomoyo/realpath.c
This commit is contained in:
Linus Torvalds
commit
95b6886526
36 changed files with 6487 additions and 2843 deletions
68
Documentation/security/keys-ecryptfs.txt
Normal file
68
Documentation/security/keys-ecryptfs.txt
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
Encrypted keys for the eCryptfs filesystem
|
||||
|
||||
ECryptfs is a stacked filesystem which transparently encrypts and decrypts each
|
||||
file using a randomly generated File Encryption Key (FEK).
|
||||
|
||||
Each FEK is in turn encrypted with a File Encryption Key Encryption Key (FEFEK)
|
||||
either in kernel space or in user space with a daemon called 'ecryptfsd'. In
|
||||
the former case the operation is performed directly by the kernel CryptoAPI
|
||||
using a key, the FEFEK, derived from a user prompted passphrase; in the latter
|
||||
the FEK is encrypted by 'ecryptfsd' with the help of external libraries in order
|
||||
to support other mechanisms like public key cryptography, PKCS#11 and TPM based
|
||||
operations.
|
||||
|
||||
The data structure defined by eCryptfs to contain information required for the
|
||||
FEK decryption is called authentication token and, currently, can be stored in a
|
||||
kernel key of the 'user' type, inserted in the user's session specific keyring
|
||||
by the userspace utility 'mount.ecryptfs' shipped with the package
|
||||
'ecryptfs-utils'.
|
||||
|
||||
The 'encrypted' key type has been extended with the introduction of the new
|
||||
format 'ecryptfs' in order to be used in conjunction with the eCryptfs
|
||||
filesystem. Encrypted keys of the newly introduced format store an
|
||||
authentication token in its payload with a FEFEK randomly generated by the
|
||||
kernel and protected by the parent master key.
|
||||
|
||||
In order to avoid known-plaintext attacks, the datablob obtained through
|
||||
commands 'keyctl print' or 'keyctl pipe' does not contain the overall
|
||||
authentication token, which content is well known, but only the FEFEK in
|
||||
encrypted form.
|
||||
|
||||
The eCryptfs filesystem may really benefit from using encrypted keys in that the
|
||||
required key can be securely generated by an Administrator and provided at boot
|
||||
time after the unsealing of a 'trusted' key in order to perform the mount in a
|
||||
controlled environment. Another advantage is that the key is not exposed to
|
||||
threats of malicious software, because it is available in clear form only at
|
||||
kernel level.
|
||||
|
||||
Usage:
|
||||
keyctl add encrypted name "new ecryptfs key-type:master-key-name keylen" ring
|
||||
keyctl add encrypted name "load hex_blob" ring
|
||||
keyctl update keyid "update key-type:master-key-name"
|
||||
|
||||
name:= '<16 hexadecimal characters>'
|
||||
key-type:= 'trusted' | 'user'
|
||||
keylen:= 64
|
||||
|
||||
|
||||
Example of encrypted key usage with the eCryptfs filesystem:
|
||||
|
||||
Create an encrypted key "1000100010001000" of length 64 bytes with format
|
||||
'ecryptfs' and save it using a previously loaded user key "test":
|
||||
|
||||
$ keyctl add encrypted 1000100010001000 "new ecryptfs user:test 64" @u
|
||||
19184530
|
||||
|
||||
$ keyctl print 19184530
|
||||
ecryptfs user:test 64 490045d4bfe48c99f0d465fbbbb79e7500da954178e2de0697
|
||||
dd85091f5450a0511219e9f7cd70dcd498038181466f78ac8d4c19504fcc72402bfc41c2
|
||||
f253a41b7507ccaa4b2b03fff19a69d1cc0b16e71746473f023a95488b6edfd86f7fdd40
|
||||
9d292e4bacded1258880122dd553a661
|
||||
|
||||
$ keyctl pipe 19184530 > ecryptfs.blob
|
||||
|
||||
Mount an eCryptfs filesystem using the created encrypted key "1000100010001000"
|
||||
into the '/secret' directory:
|
||||
|
||||
$ mount -i -t ecryptfs -oecryptfs_sig=1000100010001000,\
|
||||
ecryptfs_cipher=aes,ecryptfs_key_bytes=32 /secret /secret
|
||||
|
|
@ -53,12 +53,19 @@ they are only as secure as the user key encrypting them. The master user key
|
|||
should therefore be loaded in as secure a way as possible, preferably early in
|
||||
boot.
|
||||
|
||||
Usage:
|
||||
keyctl add encrypted name "new key-type:master-key-name keylen" ring
|
||||
keyctl add encrypted name "load hex_blob" ring
|
||||
keyctl update keyid "update key-type:master-key-name"
|
||||
The decrypted portion of encrypted keys can contain either a simple symmetric
|
||||
key or a more complex structure. The format of the more complex structure is
|
||||
application specific, which is identified by 'format'.
|
||||
|
||||
Usage:
|
||||
keyctl add encrypted name "new [format] key-type:master-key-name keylen"
|
||||
ring
|
||||
keyctl add encrypted name "load hex_blob" ring
|
||||
keyctl update keyid "update key-type:master-key-name"
|
||||
|
||||
format:= 'default | ecryptfs'
|
||||
key-type:= 'trusted' | 'user'
|
||||
|
||||
where 'key-type' is either 'trusted' or 'user'.
|
||||
|
||||
Examples of trusted and encrypted key usage:
|
||||
|
||||
|
|
@ -114,15 +121,25 @@ Reseal a trusted key under new pcr values:
|
|||
7ef6a24defe4846104209bf0c3eced7fa1a672ed5b125fc9d8cd88b476a658a4434644ef
|
||||
df8ae9a178e9f83ba9f08d10fa47e4226b98b0702f06b3b8
|
||||
|
||||
Create and save an encrypted key "evm" using the above trusted key "kmk":
|
||||
The initial consumer of trusted keys is EVM, which at boot time needs a high
|
||||
quality symmetric key for HMAC protection of file metadata. The use of a
|
||||
trusted key provides strong guarantees that the EVM key has not been
|
||||
compromised by a user level problem, and when sealed to specific boot PCR
|
||||
values, protects against boot and offline attacks. Create and save an
|
||||
encrypted key "evm" using the above trusted key "kmk":
|
||||
|
||||
option 1: omitting 'format'
|
||||
$ keyctl add encrypted evm "new trusted:kmk 32" @u
|
||||
159771175
|
||||
|
||||
option 2: explicitly defining 'format' as 'default'
|
||||
$ keyctl add encrypted evm "new default trusted:kmk 32" @u
|
||||
159771175
|
||||
|
||||
$ keyctl print 159771175
|
||||
trusted:kmk 32 2375725ad57798846a9bbd240de8906f006e66c03af53b1b382dbbc55
|
||||
be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e024717c64
|
||||
5972dcb82ab2dde83376d82b2e3c09ffc
|
||||
default trusted:kmk 32 2375725ad57798846a9bbd240de8906f006e66c03af53b1b3
|
||||
82dbbc55be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e0
|
||||
24717c64 5972dcb82ab2dde83376d82b2e3c09ffc
|
||||
|
||||
$ keyctl pipe 159771175 > evm.blob
|
||||
|
||||
|
|
@ -132,14 +149,11 @@ Load an encrypted key "evm" from saved blob:
|
|||
831684262
|
||||
|
||||
$ keyctl print 831684262
|
||||
trusted:kmk 32 2375725ad57798846a9bbd240de8906f006e66c03af53b1b382dbbc55
|
||||
be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e024717c64
|
||||
5972dcb82ab2dde83376d82b2e3c09ffc
|
||||
default trusted:kmk 32 2375725ad57798846a9bbd240de8906f006e66c03af53b1b3
|
||||
82dbbc55be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e0
|
||||
24717c64 5972dcb82ab2dde83376d82b2e3c09ffc
|
||||
|
||||
|
||||
The initial consumer of trusted keys is EVM, which at boot time needs a high
|
||||
quality symmetric key for HMAC protection of file metadata. The use of a
|
||||
trusted key provides strong guarantees that the EVM key has not been
|
||||
compromised by a user level problem, and when sealed to specific boot PCR
|
||||
values, protects against boot and offline attacks. Other uses for trusted and
|
||||
encrypted keys, such as for disk and file encryption are anticipated.
|
||||
Other uses for trusted and encrypted keys, such as for disk and file encryption
|
||||
are anticipated. In particular the new format 'ecryptfs' has been defined in
|
||||
in order to use encrypted keys to mount an eCryptfs filesystem. More details
|
||||
about the usage can be found in the file 'Documentation/keys-ecryptfs.txt'.
|
||||
|
|
|
|||
Loading…
Reference in a new issue