opencryptoki/doc

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.