Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The short answer is no. The nuanced answer is that having access to TPM, TEE, or similar secure enclaves can be useful and, for example, enable the storage of private keys and other data, that is coming from or needed by DICE. But that is something going beyond the specification. So, if and when we make changes like that, it should at least be compatible with the specification and even better make it into the specification as some kind of extension.

How will the private key of the Alias key-pair be protected if the last DICE layer is the OS?

Under normal circumstances, the Alias key-pair will be accessible to all clients running at the same exception level. That means that a Alias key-pair accessible to the Linux kernel will be accessible to all kernel code. Likewise if it’s extended all the way to user space, the keys would be exposed to everything in userspace. Having said that, there are featuers like AppArmor, SELinux etc that eventually can address that to some extent.

In short, having access to the private key is problematic. But, we have to remember that the public key from the key-pair has been put into a certificate (Alias certificate), that in turn has been signed by the previous layer. This goes all the way back to the root of trust. I.e,. the certificate chain will ensure that this public key indeed belong to and comes from this particular device. If we imagine that we use the private Alias key to sign an attestation request, then the remote verifier will only be able to successfully verify that signature using the matching public key. Any other attempt to verify either a tampered signature or a signature made with another private key will fail.

But we still have the problem that if anyone can access this private key, then in theory an attacker could sign known good data and return that to an attestation request, while the attacker at the same time have modifier code and data elsewhere.

For this reason we suggest that a TEE environment or similar, owns the last layers key-pair and that the TEE environment is responsible of responding to attestation requests.

General

What is the minimum we need to do if we want to be prepared to support DICE later on?

...