You've already forked opencryptoki
mirror of
https://github.com/opencryptoki/opencryptoki.git
synced 2026-10-24 05:39:17 +03:00
e6aa900049
Closes: https://github.com/opencryptoki/opencryptoki/issues/454 Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
95 lines
3.6 KiB
Plaintext
95 lines
3.6 KiB
Plaintext
TPM STDLL README
|
|
Kent Yoder <shpedoikal@gmail.com>
|
|
|
|
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.
|