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.