All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Reynolds <jrey@linux.ibm.com>
To: Patrick Williams <patrick@stwcx.xyz>
Cc: openbmc <openbmc@lists.ozlabs.org>
Subject: Re: Security Working Group meeting - Wednesday August 31 - results
Date: Mon, 5 Sep 2022 13:56:39 -0500	[thread overview]
Message-ID: <5723faf6-66c3-1793-699d-ffbf61bf3268@linux.ibm.com> (raw)
In-Reply-To: <YxCWpNZ+O89B+ulA@heinlein.stwcx.org.github.beta.tailscale.net>

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.

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

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


  parent reply	other threads:[~2022-09-05 18:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-31  1:08 Security Working Group meeting - Wednesday August 31 Joseph Reynolds
2022-08-31  1:16 ` Security Working Group meeting - Wednesday August 31 - new venue Joseph Reynolds
2022-08-31 18:09 ` Security Working Group meeting - Wednesday August 31 - results Joseph Reynolds
2022-09-01 11:25   ` Patrick Williams
2022-09-01 12:41     ` Brad Bishop
2022-09-01 15:07       ` Patrick Williams
2022-09-05 19:04       ` Joseph Reynolds
2022-09-01 21:23     ` Michael Richardson
2022-09-02 16:07       ` Thore Sommer
2022-09-06 13:10         ` Patrick Williams
2022-09-05 18:56     ` Joseph Reynolds [this message]
2022-09-06  8:05       ` Michael Richardson
2022-09-06 13:09         ` Patrick Williams
2022-09-12 19:31         ` George Almasi
2022-09-06 13:07       ` Patrick Williams
2022-09-07  8:01         ` Michael Richardson
2022-09-01 11:27   ` Patrick Williams
2022-09-05 18:59     ` Joseph Reynolds
2022-09-06 20:16       ` Patrick Williams
2022-09-08 18:57 George Almasi
     [not found] ` <101586.1662709990@dooku>
2022-09-09 18:49   ` George Almasi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5723faf6-66c3-1793-699d-ffbf61bf3268@linux.ibm.com \
    --to=jrey@linux.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=patrick@stwcx.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.