This feature allows to protect user data via signing cryptographic keys stored on hardware tokens, rather than via passwords.
The hardware token needs to present a valid signature for the generated challenge to unseal a secret seed value (aka “cryptohome KDF passphrase”). The VKK key is derived from this passphrase using Scrypt KDF, and is then used, as usual, to get VK and mount the user's cryptohome directory.
The sealing algorithm involves TPM capabilities for achieving the security strength. The algorithm is different depending on the version of the TPM chip installed into the Chrome OS device - see below for specific descriptions.
The rough idea is:
cryptohome_kdf_passphrase := concat( tpm_sealed_secret, deterministic_signature_of_salt)
where tpm_sealed_secret
is the secret blob which is sealed using TPM in a way that unsealing requires presenting valid signatures of the specified blobs, and deterministic_signature_of_salt
is the signature of a per-user salt obtained using a deterministic signing algorithm.
TODO(emaxx): Fill this up while the feature gets implemented.
This algorithm is based on the “TPM2_PolicySigned Extended Authorization Policy” feature of TPM 2.0. In essence, it allows to encrypt the given blob of data via the TPM's SRK and associate it with the given public key, so that the TPM will only decrypt it back after being presented a valid signature for the TPM-generated random nonce.
Technically, the TPM2_PolicySigned function is used when preparing the policy session both for sealing and for unsealing. The difference is that the signature is required only for the latter; for the former, the so-called “trial” policy session is used and only the public key information is provided.
Additionally, the sealed data is bound to PCR0 (via the TPM2_PolicyPCR policy).
The input for the sealing operation - that is, the actual KDF passphrase - is a randomly generated blob.
This algorithm is based on the “Certified Migratable Key” (CMK) feature of TPM 1.2. In a nutshell, CMK is an RSA key generated by the TPM and stored encrypted by its SRK. The CMK is associated at the creation time with the specified Migration Authority key (“MA key”). The TPM allows to “migrate” the CMK onto the specified Migration Destination Key - that is, re-encrypt it from SRK onto the Migration Destination key - if a valid signature with the MA key is provided. The data to be signed is derived (by SHA-1 hashing) from the public keys of all three keys involved in the migration - that is, the CMK, the MA Key and the Migration Destination Key.
In our application, the role of the secret data to be sealed will be played by the private part of the CMK (or, to be precise, its SHA-256 hash - in order to avoid any bias). The CMK will be generated randomly by the TPM during the first sign-in. The protection key from the hardware token will be the MA Key. Finally, the Migration Destination Key will be generated randomly on each sign-in of the user.
Some of operations with CMKs require special privileges; for those, some additional permissions were added to the delegate that is created during the TPM ownership taking. The delegate is also changed to be bound to PCR0, which implies that CMK unsealing is restricted to that PCR as well.