Skip to content

Latest commit

 

History

History
277 lines (219 loc) · 11.5 KB

40-tpm2-pre-boot-event-log-support.md

File metadata and controls

277 lines (219 loc) · 11.5 KB
Raw

enhancement-#40: TPM 2.0 Pre-Boot Event log support

Release Signoff Checklist

  • Enhancement issue in release milestone, which links to pull request in [keylime/enhancements]
  • Core members have approved the issue with the label implementable
  • Design details are appropriately documented
  • Test plan is in place
  • User-facing documentation has been created in [keylime/keylime-docs]

Summary

Provide Keylime with the ability to extract and process the TPM 2.0 Pre-Boot Event Log Keylime. Event logs are highly useful in attestation given that these can be used to reconstruct the values of any TPM PCR. With the proposed enhancement, Keylime agents will to access the contents of the event log (via securityfs), ship it to a verifier, and have it properly processed there. This framework is very similar to what is already done currently for IMA, with the added benefit of this being applicable to the "reconstruction" of values of PCRs other than the #10.

Motivation

In any modern datacenter, the usual scenario is one with literally hundreds of different types of nodes, and simply "getting the contents of the boot aggregate (PCR 10) from a list of well-known values" has shown itself to be unfeasible from an operational standpoint (just to give some perspective: when nodes are netbooted, the value of every PCR1 is different as it encodes the MAC address of the NIC). Our experiments with the "TPM 2.0 Pre-Boot Event log" demonstrated that, with a "recent enough" Kernel (e.g. 5.4.X), and a "recent enough" version of tpm2-tools, we can access the contents of the aforementioned log to re-create (or debug) the values of PCRs [0-9],14 without requiring a pre-measurement (i.e., a "golden value").

Goals

  • Add support for the agents to (conditionally) read and ship the TPM 2.0 event log
  • Add support on the verifier to replay the event log and reconstruct the values of PCR [0-9],14
  • Add support on the tenant CLI to specify an "event log desired state", which can then be consumed by the verifier to attest a given event log

Non-Goals

  • The "policy", which will take a given event log, a given "event log desired state" and issue a pass/fail on the former based on the latter is outside of the scope of this enhacement. We will provide a way for a verifier to execute a generic policy, but the actual policy code will be provided by Keylime deployers/users.

Proposal

  • The tenant CLI will provide a new option to indicate an "event log desired state"
  • The agent, upon being notified that a new "event log desired state" exists, will read the TPM2.0 pre-boot event log from /sys/kernel/security/tpm0/binary_bios_measurements and ship it back to the verifier
  • Whenever the agent reads the TPM2.0 pre-boot event log, it will also read (and ship to the verifier) the contents of PCRs [0-9], 14.
  • The verifier will be extended to support the replaying of the event log, making sure it matches the contents of the aforementioned PCRs.
  • The verifier will also be extended to support the execution of generic python code, in the form of a "policy", which will read the contents of the TPM2.0 Pre-Boot Event Log extracted by the agent, the contents of the "event log desired state" (supplied via tenant CLI and stored on the database) and then apply a pass/fail attestation test to the event log.
  • Test cases will be written that a very simple "policy", which will simply read the contents of the event log and attest it as legitimate, will be available by default. This means that the TPM2.0 Pre-Boot Event Log will be simply read on its entirety and that is can properly reconstruct PCRs [0-9],14.

Notes/Constraints/Caveats (optional)

  • More complex policies will have to provided by the user, since these are very site-specific. For instance, we have an internal policy to check for firmware versions of all hardware devices, an information which is recorded on the TPM2.0 Pre-Boot Event Log, and thus we have special custom "desired state" policy which will not be made available as open-source.

Risks and Mitigations

  • What is being proposed here is not dissimilar to what is already done with IMA in the sense that: - it is an optional capability, which should not interfere with the "regular" operation of KL - adds, to each interaction verifier<->agent interaction, no more than tens of KB (which is the total size of the "TPM2 Pre-Boot Event log").
  • While we do expect very little impact on KeyLime's scalability by adding this capability, it is important to remember that we are constantly testing KL in a configuration with 5K nodes (with IMA), and can provide experimental evidence to back this hypothesis.

Design Details

  • The "event log desired state" will be provided, via tenant CLI, in JSON format, and it is up to the specific policy code to read, interpret and apply it to the received TPM2.0 Pre-Boot Event Log

Test Plan

  • The simplest "always pass" code for the policy would allows us to make sure that TPM2.0 Pre-Boot Event Log can be extracted by the agent, sent to the verifier and that the replaying of such log will match the values on PCRs [0-9],14.

Upgrade / Downgrade Strategy

  • This is an optional feature, and thoroughly backward compatible with current Keylime deployments.

Drawbacks

  • No known drawbacks.

Alternatives

  • No known alternatives.

Infrastructure Needed (optional)

  • A relatively recent linux kernel (5.4.X) is needed to access the contents of the TPM2.0 Pre-Boot Event Log via securityfs