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.