Security Working Group meeting - Wednesday August 31 - results
mcr+ietf at sandelman.ca
Tue Sep 6 18:05:19 AEST 2022
Joseph Reynolds <jrey at linux.ibm.com> wrote:
> In my limited comprehension, the end-to-end flow is:
> 1. The BMC boots up and extends measurements into its TPM.
> 2. the BMC admin configures the BMC's Keylime Agent. That is, starts the
> "Keylime Agent service", and provisions certificates, etc.
Number 2 has to occur, but only once, while you have put it into a regular flow.
> 3. A network agent (a "Keylime Verifier") contacts the BMC's Keylime Agent
> and asks for the measurements. The Agent that queries the TPM and provides
> 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:
(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.
> 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.
> It should be clear from the paragraphs above that the intended use case is
> for a client server model, not a network of peers. The Keylime Verifier
> client running on the BMC's management network contacts the Keylime Agent
> running on the BMC. The mutual-TLS method is used for authentication.
> 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.
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the openbmc