- Release Signoff Checklist
- Summary
- Motivation
- Proposal
- Design Details
- Drawbacks
- Alternatives
- Infrastructure Needed (optional)
- 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]
The IMA event logs can grow to multiple thousands of log entries with each entry being ~100 bytes or even larger when IMA appraisal is being used on a system. With Keylime initiating frequent attestations, Mbytes of network bandwidth are consumed for the transfer of the IMA log and many CPU cycles are consumed by the verifier to verify each IMA log. This enhancement attempts to address the resource consumption issues by introducing incremental IMA attestation where the verifier requests only the difference in the IMA log (since last attestation) using the next-to-request IMA log entry number. This allows the verifier to resume the verification of the IMA log where it left off the previous time. For this to work, it also needs to maintain the state of the IMA PCR alongside the next-to-request IMA log entry number.
In the ideal case, a verifier would only perform the check of the TPM quote rather than verifying the entire IMA log of a host that has not had any new entries in its IMA log.
The motivation of this enhancement is driven by the realization that bandwidth consumption as well as the CPU cycle consumption can be greatly reduced and the scalability and efficiency of the Keylime verifier be increased when only the differences in the IMA logs from the last (previous) attestation verification are transferred.
The goal of this enhancement is to reduce network bandwidth consumption as well as the verifier's CPU cycle consumption and increase overall scalability of Keylime when IMA attestation is being used.
The verifier will need to maintain per-agent state that reflects the state of the IMA PCR from the last attestation along with the next-to-request IMA log entry. The verifier needs to be extended to request the IMA log starting at a specific entry in the IMA log. There are no changes required to the TPM quote.
To maintain backwards compatibility with older verifiers, the updated agent will return the entire IMA log when the verifier's request does not contain the number of the next IMA entry to return, which indicates and 'old' verifier.
Similarly, to maintain backwards compatibility with older agents, an updated verifier has to be able to deal with the situation where the agent did not respond with the partial log but the entire IMA log. This situation is indicated by the agent not returning the number of the first IMA log entry it returned, thus the verifier will assume the log starts at the first entry.
From the above it can be seen that the benefits of reduction of network bandwidth and CPU cycle consumption are only going to take effect when updated verifiers and updated agents are being used.
While no attestation state is persisted: Upon restart of the verifier, it will request the IMA log from the first entry (entire log) when resuming communication with a particular agent. Therefore, startup of the IMA verification will be as costly (in terms of resource consumption) as it was before this enhancement.
Once the number of the next-to-request IMA log entry and the state of the IMA PCR(s) along with the last-known boottime of the agent have been persisted, the verifier can try to resume the attestation from where it left off. It will request the measurement list to be sent from the next-to-request IMA log entry number and the agent will respond with an IMA measurement list along with its boottime. If the boottime is found to be different than the last known boot time then the current attestation will be skipped and the next time a full attestation starting at entry 0 will be requested.
An administrator who wants to increase the number of systems monitored by Keylime using IMA and who does not want to use a larger machine or more CPUs dedicated to the Keylime verifier(s) will find Incremental Attestation support important since it will require far less CPU cycles during steady-state monitoring (rather than startup) of those systems.
The design is based on the assumption that affinity between a keylime verifier and agent is maintained.
Since only a pull model is currently implemented in Keylime (verifier initiates the quote request) we do not need to deal with the case where affinity of an agent is not maintained during attestation. If this was to change, then the Keylime verifier will have to read the last state of the attestation every time before it runs the log verification. Since this it not necessary today, the implementation will not read the last state every time.
No known risks.
Many of the details are already given above.
The verifier database table will need to be extend with entries for:
- last known boottime of agent system
- state of the IMA PCR(s)
- the next-to-request entry number for the IMA log
The PR implementing this proposal will add
- unit tests for some newly added functions
- integration tests for testing incremental attestation
The database migration scripts will be able to handle the upgrade and downgrade ot the verfier database table.
Compatibility between old verifiers and new agents and new verfiers and old agents is maintained.
The be abel to get the boottime of a system we need the psutil package. We require psutil >=5.4.2 since Ubuntu Bionic provides this version and RHEL 8 provides 5.4.3.
No known drawbacks.
No known alternatives.
No additional infrastructure is needed.