forked from opencryptoki/opencryptoki
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.tpm_stdll
94 lines (79 loc) · 3.65 KB
/
README.tpm_stdll
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
TPM STDLL README
Kent Yoder <[email protected]>
Current architecture:
SRK
|
+ User Root Key (URK)
| |
| + [1..N] User Base Key (UBK)
| |
| + Migratable Leaf Key (MLK)
| | |
| | + Auth Data for User Created Keys
| |
| + [1..N] User Created Keys
|
+ Migratable Root Key (MRK)
|
+ Migratable Leaf Key (MLK)
1. When the SO logs in:
A) its verified that she is root (currently commented out)
B) the token searches for the User Root Key (URK), and if found, the SO's key
chain is loaded, up to the SO's protection key. Some junk data is
encrypted and decrypted to challenge the auth data passed in and if that
test passes, the SO is logged in
C) if the URK isn't found, its assumed that the SO is logging in for the first
time, and
i. The URK is generated in software
ii. The URK's private key is wrapped with the public key of the SRK, and TSS
and PKCS#11 objects are created for it, storing it in the PKCS#11 data store
D) i and ii are repeated for the Migratable Root Key (MRK)
E) The Protection Key is generated by the TPM as a child of the MRK
F) Some junk data is encrypted and decrypted to challenge the auth data passed
in and if that test passes, the SO is logged in
2. When the USER logs in:
A) The URK is searched for and if not found, failure (The SO has not
initialized the token)
B) If the URK is found, the User's Base Key (UBK) is searched for and if
found, the user's key chain is loaded, up to the USER's protection key.
Some junk data is encrypted and decrypted to challenge the auth data passed
in and if that test passes, the USER is logged in
C) if the UBK is not found:
i. The UBK is generated in software
ii.The UBK's private key is wrapped with the public key of the URK, and TSS
and PKCS#11 objects are created for it, storing it in the PKCS#11 data
store
D) The User's Protection Key is generated by the TPM as a child of the UBK
E) Some junk data is encrypted and decrypted to challenge the auth data passed
in and if that test passes, the USER is logged in
Prior to release 2.4.1, the tpm stdll has the password for the SRK hardcoded to
NULL and the policy secret mode set to TSS_SECRET_MODE_PLAIN.
Starting in release 2.4.1, the environment variables,
OCK_SRK_SECRET and OCK_SRK_MODE can be set to indicate the Storage Root Key's
secret and it's policy's secret mode to the tpm stdll.
OCK_SRK_MODE
The possible secret modes are:
- TSS_SECRET_MODE_NONE
- TSS_SECRET_MODE_PLAIN
- TSS_SECRET_MODE_SHA1
- TSS_SECRET_MODE_POPUP
- TSS_SECRET_MODE_CALLBACK
OCK_SRK_SECRET
The storage root key may be:
- a text string.
OCK_SRK_MODE should be set to TSS_SECRET_MODE_PLAIN.
i.e. export OCK_SRK_SECRET="MyBigSecret"
- SHA1 hash string.
The SHA1 hash must be expressed as a 40 byte hexadecimal string. Recall a
byte value is represented by two hexadecimal digits. So a SHA1 hash length
of 20 bytes requires 40 hexadecimal digits to represent it.
This option also requires that OCK_SRK_MODE is set to TSS_SECRET_MODE_SHA1
to indicate the string is a sha1 hash.
i.e. export OCK_SRK_SECRET="22596363b3de40b06f981fb85d82312e8c0ed511"
export OCK_SRK_MODE=TSS_SECRET_MODE_SHA1
Note: If using the well known secret, then express as a 40 byte hex string
of zeroes.
i.e. export OCK_SRK_SECRET="0000000000000000000000000000000000000000"
export OCK_SRK_MODE=TSS_SECRET_MODE_SHA1
If neither OCK_SRK_MODE nor OCK_SRK_SECRET are set, then the passwd will be set
to NULL, and the mode to TSS_SECRET_MODE_PLAIN.