Event Logs for Veraison

Adding Event Log support to Veraison

Veraison has not needed to consider Event Log (EL) support to date, as the architectures behind the current set of attestation technologies (schemes) have not required it.

However, there are existing schemes that may require use of Event Logs and potential integration with Keylime brings event logs (example TPM boot, IMA use cases) .

Veraison Impact

There are two required areas of change for Veraison to support event logs: transfer of the EL to the Verifier service and processing the EL in schemes.

Transfer

ELs will be available separately from the attestation report and can be large (in particular if considering the IMA use case). The current verification submission API does not accommodate this. Note also that there may be many clients for verification from the same host and that the host has no hard link to the verification server. The risk then is that to any or all verification calls will incur an overhead of transmitting the EL. A change to the API needs to support a scheme that avoids sending the EL to the verification server on every request. The proposed API modifications are as follows:

The Session POST API is extended such that the token document can support new parameters: Event-log-hash - a hash of the event log artifact as seen at the client (the onus being on the client to compute this hash). If this param is missing or absent, the server component assumes no event log is used for this verification. Event-log-hash-algm - the algorithm used to compute the hash

Potential responses to a posted hash are: Event-log-needed: no event log is known for that Attester identity (identity determined from attestation token eg. cca-platform-instance-id). In the event that requiring partial parsing of the attestation token is too much overhead, an additional parameter will be required providing an identity in a scheme specific manner (e.g. hash of host name?). Such an additional parameter may also be required in case the attester is participating in a group scheme for privacy purposes. The onus then is that the Verifier will need to be part of the privacy preserving scheme and can receive a device specific identity - in theory communicating the event log could be used to fingerprint devices so this requirement may already be in place.

Event-log-up-to-date: (the server has already received an event log conforming to that hash). May be part of either 'Accepted' or 'Response' responses.

Event-log-delta-required: the server has previously seen an event log from this Attester but not this hash, implying that the EL has new entries added. This response will also contain a 'hint' parameter that will enable the caller to calculate the delta to send. This hint could be a timestamp or event log index depending upon scheme. Note that some more thought is required here to cope with Attester reset between calls. In the event that the client cannot (will not) process a delta or the hint is not found, the client is expected to transmit the whole event log (as for Event-log-needed response).

A new API will be used to transmit the event log. The exact design of the API needs work to cover the scope of 'large object upload' however the following aspects are considered: the API can be in scope of the session to provide linkage to the target Attester. A parameter can provide the client's view on whether the update is a full EL for that Attester or a delta (in which case it should be accompanied by the relevant hint). For robustness, the implementation may want to check that a reported delta doesn't contain a full update (shared head to current store) or that a reported full log is not smaller than the current store. The server will need a new store (cache) for event logs against Attester identities.

Processing

Processing is scheme specific, however there appears to be a common pattern: the processed event log will yield the identity of a set of reference values which can be composed to create a single measurement per target component. When the log processing is complete, the measurement can be compared to the equivalent measurement taken from the Attester attestation report. NB: this probably differs for IMA where the set of components is unbounded - need to check how current 'golden' IMA entries are currently collected (or leave this as an exercise for implementers).

The overall log processing should also yield a rolling hash of the entries which can be compared to the 'event log security' value from the attestation report.

Scheme specific requirements (e.g security version parsed from EL entries) may yield the need to maintain related information per component alongside the compound measurement. The role here of the scheme verification is to extract the state of such values to be either considered by further appraisal policy or to be incorporated into the attestation results for Verifier client appraisal.

A feature like determining state at realm startup could extend the requirements on the cache design to keep intermediate values of EL processing.