Security Working Group meeting - Wednesday August 31 - results

[Patrick Williams]

Overall, I don't have strong opinions if someone wants to implement the
Keylime agent as an option for attestation if they think their customers
will find value in it.  I do think we should be careful about any
wording that suggests it is the preferred way because at this time I'm
not convinced it is an appropriate solution for the majority of users.

I'm not expecting IBM to implement attestation over Redfish but I
suspect that will be far more applicable in a general sense.

I could be wrong on Keylime.  My initial reaction is that it is going to
be difficult to get a broad install base on the Verifier side.

On Mon, Sep 05, 2022 at 01:56:39PM -0500, Joseph Reynolds wrote:
> On 9/1/22 6:25 AM, Patrick Williams wrote:
> > On Wed, Aug 31, 2022 at 01:09:10PM -0500, Joseph Reynolds wrote:
> >
> >> DISCUSSION: Create two separate designs for:
> >>      Enable Keylime Agent.  Direction is for the keylime agent to open
> >>      the BMC network port (using systemd, sort of like how SSH works).
> >>      The intention is to engage with Redfish for how to configure the
> >>      Keylime Agent: certificates, start/stop the application, etc.
> > I guess you said someone is working on a design for this.  The Keylime
> > website seems light on details to me, but I'm having trouble
> > conceptualizing how it is applicable to the BMC.  It seems more like it
> > is geared towards a self-selecting cluster of services (which reject
> > peers they don't trust).  Keylime does have the unfortunate aspect of being
> > written entirely in Python, which makes it very difficult for us to support
> > on any of the NOR-based systems (all of them except IBM's latest).
> 
> Yes, an IBM group is working this design.  The design we discussed in 
> the security working group meeting has two parts, which I barely 
> comprehend.  The parts are:
> 1. Code running on the BMC will "extend measurements" to a trusted 
> platform module (TPM).  Two separate pieces of code are in U-Boot and in 
> the Kernel.  The "measurements" are the readonly code image being loaded 
> and run.
> 2. Code running on the BMC (the Keylime "Agent") will query the TPM and 
> offer the results to whoever asks.

This is very concerning to me.  There is no authentication?

Blindly advertising to the world which versions of firmware you are
running so an attacker knows exactly which vulnerabilities you are
likely to have doesn't sound appealing.

> 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.
> 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.
> 
> 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.  

The way this is worded feels a bit like a stretch argument.  If Redfish
already has a schema for getting the measurements for a managed entity,
wouldn't it be trivial to extend this schema for the management entity?

> 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.
> 
> 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.

Alright.  Maybe there is authentication?

mTLS presents a bit of a chicken-and-egg issue, doesn't it?

    1. I don't want to install device-level certificates on a device I
       haven't attested.

    2. I can't attest a device until I install device-level
       certificates on it in order to support mTLS.

You've briefly mentioned "BMC admin" above, which sounds like something
manual a human does.  This doesn't work at any kind of scale, so we need
to consider how automation would perform this activity, especially in
light of the fact that it doesn't trust the device it is configuring
yet.

> 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.
> 
> Joseph
> 
> > Are we also planning on providing attestation information over Redfish?
> >
> 

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220906/0ccd0505/attachment.sig>