-
Notifications
You must be signed in to change notification settings - Fork 53
Overview
This page is designed to give insight into the intended use of Kmyth along with the processes involved. The processes described on this page should generalize to implementations using either TPM 1.2 or TPM 2.0. Note that we denote the kmyth tool with all lower case letters, while Kmyth refers to the project.
For more details on TPM-specific implementations, see:
TPM 1.2: kmyth-seal kmyth-unseal kmyth-getkey
TPM 2.0: kmyth-seal kmyth-unseal kmyth-getkey
Kmyth is designed to do the heavy lifting for the user, in that it abstracts details of TPM interactions as much as possible.
Although kmyth-seal can be used to ensure the confidentiality of any type of data, for the sake of kmyth-getkey, we assume the data to be protected is the client authentication private key (CAPK). Kmyth-seal involves more than just binding data to the TPM. It includes the entire process from storage key creation through saving the encrypted CAPK. The individual steps are:
- Create a storage key.
- Create the client wrapping key (CWK).
- Encrypt the CAPK. The default encryption algorithm is AES/GCM/NoPadding/256.
- Seal the client wrapping key to the TPM.
- Store a .ski file containing the sealed CWK and SK, and the encrypted CAPK, along with necessary metadata required to reconstruct the original CAPK.
A good question one might ask at this point is "Why use a separate wrapping key instead of just sealing the CAPK directly?" The reason for this is because the TPM can only seal small data blobs, and the file containing the private key will possibly (and likely for RSA) be too long to seal in one pass. While the file could be broken into multiple parts and each part could be sealed separately, using a wrapping key is cleaner and still provides a TPM supported key hierarchy. This is also the approach taken by tpm-tools. There are two key differences between kmyth and tpm-tools. First, kmyth allows the user to select the algorithm used to encrypt the CAPK. Second, kmyth only uses the WKS. This is because kmyth is intended to be used in a distributed system where requiring a human to input a password for each unseal is not practical.
Kmyth-unsealing is the process of obtaining the material protected by the TPM. The individual steps are almost the reverse of kmyth-seal:
- Input the .ski file.
- Unseal the CWK.
- Unwrap the CAPK using the CWK.
- Write the CAPK to disk or to stdout.
Kmyth is intended to be used in conjunction with a key server for operational key retrieval. This tool is designed to establish a TLS connection to retrieve a key from a key server. Kmyth assumes the key server has been established and already possesses a key we wish to acquire. Kmyth-getkey does not currently support any standard key retrieval protocols, e.g. KMIP.
- Use kmyth-unseal to access the CAPK. (The user does not need to run kmyth-unseal separately -- the functionality is implemented in kmyth-getkey.)
- Retrieve the operational key from key server.
- Output the operational key to stdout, preferably directed to a RAM file.
Within the TPM: Storage Key, Storage Root Key, PCR values
Encrypted on local file system: CAPK, Storage Key, CWK, expected PCR values
Stored on remote key server: Operational Key
Once the operational key is retrieved, it can be used in one of three ways:
- Used within the program that retrieved the key
- Piped into another program on the command line
- Stored to a local file system
- If stored to a local file system, it is strongly encouraged that the key be stored in a RAM file as briefly as possible.
During client provisioning:
- Create an SK within the TPM.
- Create a CWK which will be used to encrypt the CAPK.
- Encrypt the CAPK.
- Use the SK to seal the CWK.
- Store the sealed SK and CWK, and the encrypted CAPK to file.
Upon client start-up: 6. Unseal the CWK using the SK. 7. Decrypt the CAPK using the CWK. 8. Retrieve the operational key with the CAPK via TLS.