Skip to content

Home

Jump to bottom
b-carr edited this page Jul 27, 2020 · 4 revisions

Kmyth

Kmyth is a project about enabling distributed key management using cryptography and specialized, commodity hardware. The long-term goal of this project is to design and prototype a secure distributed key management system. While this system is expected to evolve over time, the initial efforts involve enabling access to the Trusted Platform Module (TPM) for users wanting to protect keys with trusted hardware. We extend the trust rooted in the TPM through a key hierarchy to protect various types of data. Kmyth simplifies the process of using a TPM to encrypt/decrypt a file through sealing and unsealing within the TPM.

Currently, Kmyth is built for Linux and TPM 1.2/2.0. It provides tools that use the TPM to protect data, similar to the Trousers tpm-tools for TPM 1.2 and tpm2-tools for TPM 2.0. The libraries in Kmyth provide tools to retrieve sealed data within a program, allowing the program to use the data without it ever being written to disk. An example of this can be found in kmyth-getkey.

Kmyth is a prototype and still in development. It is not a production ready tool.

Key design goals for Kmyth:

  • Component of hardware-backed key management for distributed systems
  • Support cryptographic security for both data-at-rest and data-in-use
  • Limit access to sensitive keys/data by system administrators and system users
  • Provide easy-to-use access to the TPM
  • Enable integration with existing key management technologies

Table of Contents

Kmyth Overview

Command Line Tools

Kmyth TPM 1.2 Details

Kmyth TPM 2.0 Details

Related Information

Kmyth Summary

Kmyth is intended to be a component of distributed key management within clouds, protecting individual nodes through system startup. These distributed systems consist of a relatively light control layer with most of the computations and data manipulation occurring at the lowest level on commodity nodes that store the data. We assume there is a key server that the nodes can access. Since the nodes are the clients in client/server communications, we will refer to them as such.

The Kmyth system is built with two key assumptions in place:

  1. The TPM is available
    • Commands such as tpm_takeownership or tpm2_takeownership have been executed
    • The process for each TPM varies. We provide some high level instructions for the TPM 1.2 and more comprehensive information can be found on our helpful links page.
  2. A key server is in use
    • There is a public key infrastructure covering the clients and key server.
    • The public key infrastructure supports the establishment of a secure, mutually authenticated communication channel between each client and the key server, using the TLS protocol.

In particular, the following are true:

  • Clients are enrolled in the installation's public key infrastructure.
  • Each client has a public/private key pair with the associated certificate.
  • The server has a public/private key pair with the associated certificate.
  • The certificates are signed by an appropriate Certificate Authority.
  • An operational key required by the client is stored on the key server.

These are prerequisites and are outside the scope of the kmyth tool.

Definitions

This section provides a brief definition of keywords found throughout the documentation.

Trusted Platform Module:

  • Trusted Platform Module (TPM): A cryptographic coprocessor included on most commodity machines. Kmyth leverages its ability to encrypt/decrypt and verify the boot process.
  • Platform Configuration Register (PCR): A register within the TPM that can only be updated within the TPM. It holds hash values, called PCR values, that encapsulate information about the state of the node at a given time.
  • Seal: The internal TPM process of using a combination of a SK, 0+ PCRs, and an additional (optional) password to encrypt data. Data sealed in this manner can only be accessed if the node starts-up in a predetermined state. At this time Kmyth does not support the use of an additional password.
  • Unseal: The internal TPM process of using a combination of an SK, 0+ known PCR values, and an additional (optional) password to decrypt sealed data. If the value in any PCR was used in sealing the data, then the current value in that register will be used in the unseal process and must match the value used when the data was sealed. At this time Kmyth does not support the use of an additional password.
  • Authorization Policy: These policies provide more authorization granularity than only PCRs. They are only available for TPM 2.0.
  • Well-known Secret (WKS): When a TPM is enabled and takeownership is executed, the TPM password is assumed to be this value, which is twenty bytes of 0x00.

Types of keys:

  • Storage Root Key (SRK): The root of the TPM's internal key hierarchy. The specifications for this key vary across TPM versions.
  • Storage Key (SK): A key protected by the SRK, that is used to protect the client wrapping key.
  • Client Wrapping Key (CWK): A symmetric key used to wrap either the client's authentication private key or other file contents via kmyth-seal.
  • Client Authentication Private Key (CAPK): This is the key the client uses to authenticate to the key server.
  • Operational Key: This is the operational key the client retrieves from the key server.

Seal and Unseal Disambiguation

The words seal and unseal have different meanings within kmyth.

  • With respect to the TPM, seal and unseal are the invocation of those commands within the TPM, where data is encrypted within the TPM incorporating the system state measurement (such as PCRs).
  • With respect to kmyth, seal and unseal (referred to as kmyth-seal and kmyth-unseal) involve the creation and decryption of a .ski file. Creation and decryption of .ski files use the TPM seal and TPM unseal functionality respectively.
Clone this wiki locally