Disk unlocking contains at least three entities: a disk, a computer and a third party. The disk is encrypted using a volume key. The computer that wishes to decrypt the disk must obtain this volume key. The third party authenticates the computer and grants it access to the volume key.

Since a compromise of a disk's volume key requires full disk re-encryption, it is essential that the volume key not be used directly for authentication. Therefore, key acquisition is a process by which some metadata stored in an unencrypted header can be used to compute the disk's volume key. Hence, we can define key acquisition as a function which takes metadata as input and produces the volume key as output.

Key Acquisition by Password

The method described here is the method used by LUKS on Linux.

1. Metadata is read from the disk header. In this case, the metadata contains one or more encrypted copies of the volume key as well as the parameters used for volume key encryption and key hashing.

2. Implicit mutual authentication occurs between the computer and the third party based upon physical access to the keyboard or a trusted KVM.

3. The third party then types the password into the physical keyboard. The password is derived using the derivation parameters contained in the metadata. Finally, the volume key is decrypted.

4. The disk is decrypted using the volume key.

images/ka-password.png

Key Acquisition by Escrow

1. The metadata is loaded from the disk. This typically contains:

   • a public key used to identify the third party to the computer
   • a secret used to identify the computer to the third party
   • the volume key encrypted to the remote key
   • a volume identifier
   • configuration used to contact the third party (optional)
   • remote key derivation parameters (optional)

2. Explicit mutual authentication occurs between the computer and the third party based on the keys stored in the metadata.

3. The third party returns the remote key associated with the volume identifier. This key is optionally derived using the metadata specified derivation parameters. The remote key is used to decrypt the volume key. An encryption tunnel is required to protect the returned remote key.

4. The disk is decrypted using the volume key.

The main advantage of this method when compared to key acquisition by password is that this process can be fully automated. One downside is that the computer itself is not authenticated, but rather the disk. For many applications, this trade-off is considered acceptable. However, it must be noted that we cannot discard authentication altogether since this would permit anyone to obtain the remote key; greatly decreasing security.

The remote third party configuration can be offloaded to another system and thus need not be contained in the metadata in all cases. Two examples of this are: DHCP and DNS.

images/ka-escrow.png

Key Acquisition by Exchange

This method uses the observation that the required secret for key acquisition by escrow can be used to derive a key instead of fetching a remote key. This is done by utilizing a key agreement methodology (not defined here).

1. The metadata is loaded from the disk. This typically contains:

   • the volume key encrypted to the exchange key
   • exchange key derivation parameters
   • a secret key used for the exchange
   • configuration used to contact the third party (optional)
   • a volume identifier (optional)

2. The computer performs a key agreement with the third party. This exchange may or may not be authenticated because the third party never needs to see any disk-specific information and no key travels over the wire. No encryption tunnel is needed.

3. The agreed upon key is derived using the method specified in the metadata. This derived key is used to decrypt the volume key.

4. The disk is decrypted using the volume key.

This approach has several advantages. First, the server implementation is completely stateless, simple to develop and highly performant. Second, so long as the third party's keys are available offline, systems can be provisioned without any need to contact the server. Third, no encryption tunnel is required since no secret is transferred. This lends itself to lightweight implementations which are critical for early boot implementations.

images/ka-exchange.png

Key Acquisition by TPM

1. The metadata is loaded from the disk. This typically contains:

   • the volume key encrypted to a TPM key
   • a volume identifier (optional)
   • the TPM-unlock key (optional)

2. A TPM key is selected, optionally using the volume identifier. The volume key is decrypted by the TPM using the selected TPM key. This may require a TPM-unlock key stored in the metadata.

3. The disk is decrypted using the volume key.

This method is conceptually similar to the password method, but the third party (the TPM chip) is brought inside the computer. This has very strong cryptographic properties. However, TPM chips are not universally available and come with some additional management burdens and political considerations. Further, using the TPM means that the disk cannot easily be moved to another computer; which is sometimes a required property.

images/ka-tpm.png

Key Acquisition by TPM and Escrow

This method is a straightforward combination of the TPM and Escrow methods.

1. The metadata is loaded from the disk. This typically contains:

   • a public key used to identify the third party to the computer
   • the volume key encrypted to the remote key
   • a volume identifier
   • configuration used to contact the third party (optional)
   • remote key derivation parameters (optional)
   • the TPM-unlock key (optional)

2. A TPM key is selected, optionally using the volume identifier. This may require a TPM-unlock key stored in the metadata.

3. Explicit mutual authentication occurs between the computer and the third party based on the selected TPM-unlock key and public keys stored in the metadata.

4. The third party returns the remote key associated with the volume identifier. This key is optionally derived using the metadata specified derivation parameters. The remote key is used to decrypt the volume key. An encryption tunnel is required to protect the returned remote key.

5. The derived remote key is used

The main advantage of this method is that the storage of the key for authenticating the computer to the third party is offloaded from the disk metadata to the (more secure) TPM.

images/ka-tpm-escrow.png

Key Acquisition by TPM and Exchange

This method is a straightforward combination of the TPM and Exchange methods.

1. The metadata is loaded from the disk. This typically contains:

   • the volume key encrypted to the exchange key
   • exchange key derivation parameters
   • a secret key used for the exchange encrypted to the TPM key
   • configuration used to contact the third party (optional)
   • a volume identifier (optional)
   • the TPM-unlock key (optional)

2. A TPM key is selected, optionally using the volume identifier. This may require a TPM-unlock key stored in the metadata. The secret exchange key is decrypted using the TPM key.

3. The computer performs a key agreement with the third party using the decrypted secret exchange key. This exchange may or may not be authenticated because the third party never needs to see any disk-specific information and no key travels over the wire. No encryption tunnel is needed.

4. The agreed upon key is derived using the method specified in the metadata. This derived key is used to decrypt the volume key.

5. The disk is decrypted using the volume key.

The main advantage of this method is that the storage of the secret exchange key for the key agreement is encrypted to the TPM. This guarantees that if any person reads the disk header, the secret key is not compromised. This, in turn, binds the disk decryption to the computer motherboard. This may or may not be a desirable feature.

images/ka-tpm-exchange.png

Key Acquisition using Shamir's Secret Sharing

In all the previous methods, we presumed that all key acquisition sources (such as third parties or TPM) would be just a single entity or that they would be mixed together in ways that presumed a logical-AND relationship (such as TPM and Escrow). However, other types of relationships exist between third parties. For example:

• password OR escrow
• at least two of: password, escrow OR TPM

A simple algorithm exists for splitting a key in such a way that policy controls how many segments of a key are required to restore the full key. This algorithm is called Shamir's Secret Sharing (SSS). The algorithm takes two parameters:

• N: the number of segments to split the key into
• M: the number of segments required to reconstruct the key

Where M = N, a logical AND relationship between the keys is expressed. Where M = 1, a logical OR relationship is expressed. Where 1 < M < N, a threshold relationship is expressed.

Unlocking using SSS might look like this:

1. Metadata is loaded from the header. This includes at least:

   • the volume key encrypted to the SSS key
   • the SSS parameters

2. Key segments are acquired from all acquisition sources in parallel.

3. As soon as M third parties respond with key segments, the SSS key is reassembled and the volume key is decrypted using the SSS key.

4. The disk is decrypted using the volume key.

images/ka-sss.png

Generalized Key Acquisition

All key acquisition operations can be generalized into a simple interface. This means that acquisition methods can be plugable and can be arranged in ways such as to create sophisticated unlocking policies.

We will define this as a two-stage process:

1. provisioning
2. acquisition

Provisioning

Provisioning simply takes method-specific configuration and the key as input and provides method-specific metadata as output:

metadata = provision(config, key)

The metadata is stored in the header.

Acquisition

Acquisition is simply the definition used at the beginning of this document: it takes metadata as input and produces a key as output. Hence:

key = acquire(metadata)

Recursion

Notice that this process can be performed recursively. The use of recursion, along with not-terminal acquisition methods such as SSS, allow us to define sophisticated nested policies. One such example might be:

    (password OR escrow) AND TPM

In the first case, TPM is always required. However, recovering the volume key also depends on either entering a password or having the escrow available. This relationship can be expressed by using SSS and recursion:

    SSS(2, [SSS(1, [password, escrow]), TPM])

Here is another example:

    (password AND (>2 of exchange)) OR password

In this case, we have two passwords. The first is a normal user's password. The second is a master recovery password. In order for the normal user's password to unlock the disk, at least three exchange servers must be available.

This too can be expressed recursively:

    SSS(1, [SSS(2, [password, SSS(3, [exch, exch, exch])]), password])