Security Working Group meeting - Wednesday August 31 - results

[George Almasi]

 > the measurements.
> Yes, but maybe not for anyone that asks.
> The measurement (Evidence) needs to be signed by the TPM (that's part of the protocol).
> There is a freshness requirement, for instance the Verifier can provide a
> nonce through the protocol to be included in the signed Evidence.  Another
> way is to use a TLS Extractor (TLS-Unique in TLS <1.3) to get a key.
>
> You can read more about the architecture at:
>      https://www.ietf.org/archive/id/draft-ietf-rats-architecture-21.html#name-architectural-overview
> (Yes, I'm a lead author)
> I've been really busy on Wednesdays, so I haven't joined lately, but I could
> if you want to talk more about this stuff.

Thank you for the reference document. To the extent I can tell, the 
current keylime verifier implements the picture in Section 3 
(Architectural Overview) fairly accurately, at least up to "attestation 
results". And yes, it does use nonces -- replay attacks are ugly.

Keylime is slightly older than the referenced document, so some of the 
things explicit in the diagram are less than obvious. However, when we 
implemented remote measured boot attestation support for keylime, we 
took care to separate reference values from appraisal policy.

>      > Redfish has specs for getting server TPM measurements, but does not have any
>      > specs for getting BMC TPM measurements.
>      > Because of this, the group doing the work is proposing for the BMC's Keylime
>      > Agent service to open a separate port, and to not use Redfish to get the
>      > actual measurements.  In support of this view: there are Keylime verifiers
>      > already available to use this new port, but there are no Keylime verifiers to
>      > use Redfish.
>
> Sounds accurate, but it seems like doing it through redfish is entirely
> reasonable to me.
That is what we are hoping to get an agreement on. In preliminary 
discussions with the keylime developers, it might be possible to operate 
the keylime agent as a library, built into someone else's REST service 
(e.g. redfish). But *not right away*. So the idea is to get going with 
keylime operating as a standalone basis at least initially.
>      > Keylime is written in Python.  I think the the idea was to either port that
>      > version, or to use the new implementation in Rust.  We did not discuss any
>      > difficulties in image size increase due to Python or in getting the Rust
>      > language environment ported to bitbake.
>
> I imagine that the bitbake recipe is probably the critical path, but I also
> suspect that Rust is being used somewhere with bitbake.
>
We never seriously considered using the keylime Python agent on OpenBMC. 
The requirements in software depdencencies, CPU usage, RAM, _you name 
it_ are horrendous. Rust it is, for a few MBytes of RAM usage (the 
stripped binary is 24MB on my Intel box).

-- George