Root/
1 | Encrypted keys for the eCryptfs filesystem |
2 | |
3 | ECryptfs is a stacked filesystem which transparently encrypts and decrypts each |
4 | file using a randomly generated File Encryption Key (FEK). |
5 | |
6 | Each FEK is in turn encrypted with a File Encryption Key Encryption Key (FEFEK) |
7 | either in kernel space or in user space with a daemon called 'ecryptfsd'. In |
8 | the former case the operation is performed directly by the kernel CryptoAPI |
9 | using a key, the FEFEK, derived from a user prompted passphrase; in the latter |
10 | the FEK is encrypted by 'ecryptfsd' with the help of external libraries in order |
11 | to support other mechanisms like public key cryptography, PKCS#11 and TPM based |
12 | operations. |
13 | |
14 | The data structure defined by eCryptfs to contain information required for the |
15 | FEK decryption is called authentication token and, currently, can be stored in a |
16 | kernel key of the 'user' type, inserted in the user's session specific keyring |
17 | by the userspace utility 'mount.ecryptfs' shipped with the package |
18 | 'ecryptfs-utils'. |
19 | |
20 | The 'encrypted' key type has been extended with the introduction of the new |
21 | format 'ecryptfs' in order to be used in conjunction with the eCryptfs |
22 | filesystem. Encrypted keys of the newly introduced format store an |
23 | authentication token in its payload with a FEFEK randomly generated by the |
24 | kernel and protected by the parent master key. |
25 | |
26 | In order to avoid known-plaintext attacks, the datablob obtained through |
27 | commands 'keyctl print' or 'keyctl pipe' does not contain the overall |
28 | authentication token, which content is well known, but only the FEFEK in |
29 | encrypted form. |
30 | |
31 | The eCryptfs filesystem may really benefit from using encrypted keys in that the |
32 | required key can be securely generated by an Administrator and provided at boot |
33 | time after the unsealing of a 'trusted' key in order to perform the mount in a |
34 | controlled environment. Another advantage is that the key is not exposed to |
35 | threats of malicious software, because it is available in clear form only at |
36 | kernel level. |
37 | |
38 | Usage: |
39 | keyctl add encrypted name "new ecryptfs key-type:master-key-name keylen" ring |
40 | keyctl add encrypted name "load hex_blob" ring |
41 | keyctl update keyid "update key-type:master-key-name" |
42 | |
43 | name:= '<16 hexadecimal characters>' |
44 | key-type:= 'trusted' | 'user' |
45 | keylen:= 64 |
46 | |
47 | |
48 | Example of encrypted key usage with the eCryptfs filesystem: |
49 | |
50 | Create an encrypted key "1000100010001000" of length 64 bytes with format |
51 | 'ecryptfs' and save it using a previously loaded user key "test": |
52 | |
53 | $ keyctl add encrypted 1000100010001000 "new ecryptfs user:test 64" @u |
54 | 19184530 |
55 | |
56 | $ keyctl print 19184530 |
57 | ecryptfs user:test 64 490045d4bfe48c99f0d465fbbbb79e7500da954178e2de0697 |
58 | dd85091f5450a0511219e9f7cd70dcd498038181466f78ac8d4c19504fcc72402bfc41c2 |
59 | f253a41b7507ccaa4b2b03fff19a69d1cc0b16e71746473f023a95488b6edfd86f7fdd40 |
60 | 9d292e4bacded1258880122dd553a661 |
61 | |
62 | $ keyctl pipe 19184530 > ecryptfs.blob |
63 | |
64 | Mount an eCryptfs filesystem using the created encrypted key "1000100010001000" |
65 | into the '/secret' directory: |
66 | |
67 | $ mount -i -t ecryptfs -oecryptfs_sig=1000100010001000,\ |
68 | ecryptfs_cipher=aes,ecryptfs_key_bytes=32 /secret /secret |
69 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9