Deep Quote Operation

[lukehinds]

Placeholder issue for discussions on Deep Quote support in swtpm. I will start adding content shortly.

[stefanberger]

I haven't looked at keylime nor the Xen implementation or the Deep Quote command so far, but here are some 'bullet points' that I think are worth discussing as a basis for Deep Quote design:

• The host can either have no TPM, TPM 1.2, or TPM 2.0. All configurations should be supportable, including not activating Deep Quote functionality at all.

• The Deep Quote command should take some input parameters that allow to formulate the Quote command to run on the host.

  • The PCRs to quote can be passed as the typical TPM PCR Selection byte array; this should work easily for both TPM 1.2 and TPM 2.0
  • Pass in a nonce
  • Should the user have control over the signing scheme at all?
    • A TPM 1.2 only supports signing with a SHA1+RSA key while TPM 2.0 has different signature schemes with different hashes and types of keys. How does a client find out whether the host has a TPM 1.2 or TPM 2.0?
  • Also: The setup of the quoting key should probably be a task that is up to the host admin. So, maybe the host admin chooses the signing scheme to use as well as the key to use.
  • Do we allow the user to pass in a handle for a key to use or is it a matter of configuring the program on the host to use the right key? Would there be any reason for the host to have multiple quoting keys? Any key handle passed in should probably be some kind of alias for the actual key being used. So key 0x0 would make the host use the first key.

• The Deep Quote command should return the following:

  • Indication of whether a TPM 1.2 or TPM 2.0 was used
  • The actual quote
  • The signing scheme that was used for signing the Quote
  • The number of BIOS/TPM logs relevant for the Quote
  • If only PCRs 0-7 were quoted, only the BIOS log is relevant
  • For all others the IMA log would be relevant
  • A list of the relevant log identifiers along with the file sizes of these logs at the time of Quote

• There should be a TransferLog command that allows one to retrieve the BIOS and IMA logs

  • The input to the TransferLog command should be an identifier of the log to transfer data from along with an offset into the log from where to start reading bytes from
  • The output of the TransferLog should be the identifier, offset and the length of the byte stream and the bytes itself. Only a limited number of bytes will fit through the TIS/CRB interfaces

• Similarly there should probably be a TransferCertificate command that allows a client to retrieve the certificate of the key used for the Quote. Here a key handle would be ideal to indicate which key's cert to get. The return would indicate the full size of the file each time, among the offset from where it was read etc.

Libtpms should be extended with the above commands but only handle the parsing of the commands and the construction of the responses. A callback function registered by swtpm with libtpms would be used to do the actual work for quoting and getting the data for the above commands. With this I would want to avoid having to link libtpms with a TSS client library. A simple signature of this callback could look like this

TPM_RC Callback(enum Command, void *input, void **output);

The enum Command could be something like COMMAND_QUOTE and void *data would be a struct do_quote * with the necessary parameters. Similarly there would then be COMMAND_GET_LOG to retrieve parts of a log and COMMAND_GET_CERT to retrieve the cert at certain file offsets.

swtpm would need a quite extensive configuration file to know how to handle all of this. Maybe a JSON document like this would help:

{
  "host": {
    "securityfs": "/sys/kernel/security",    # so we know where the logs are
  },
  "tpm1.2": {  # in case there's a TPM 1.2 on the host
    "keys": [
        {
           "handle": 0,
           "file": "path_to_key_file",
           "cert": "certificate",
        }
    ]
  },
  "tpm2.0": {  # in case there's TPM 2.0 on the host
    "keys": [
        {
           "handle": 0,
           "file": "path_to_key_file",
           "cert": "certificate",
           "signature": {
             "hash": "sha256",
             "scheme": "RSA-PSS",
           }
        }
    ]
  }
}

There could be more fields of course. Another possibility is to have swtpm load some form of plugin that handles the commands and have the plugin digest this JSON config file . Question is also which TSS 2 client stack to use, but this decision could be pushed into the plugin.

swtpm [...] --deepquote plugin=plugin.so,config=path_to_config[,tpmfd=fd-of-tpmrm0]

Note: swtpm runs with an SELinux or AppArmor profile under libvirt. Due to SELinux labeling, it will not be able to easily access /dev/tpmrm0, so we may need to be able to pass an open file descriptor of this device into swtpm if we were to use the IBM TSS stack. I am not sure what the requirements for the Intel TSS stack would be, maybe an open Unix socket ? All these file descriptors would need to be kept open then...

[stefanberger]

Closing now due to inactivity.