Security Working Group meeting - Wednesday August 31

Security Working Group meeting - Wednesday August 31

[Joseph Reynolds]

This is a reminder of the OpenBMC Security Working Group meeting 
scheduled for this Wednesday August 31 at 10:00am PDT.


ATTNTION - Venue Change.  The meeting moved to Discord voice, beginning 
with this meeting.  Please update your calendars.

=== MEETING ACCESS ON DISCORD VOICE starting on Aug 31, 2022  ===

Discord > OpenBMC > Voice channels >  Security ~ 
https://discord.com/channels/775381525260664832/1002376534377635860 
<https://discord.com/channels/775381525260664832/1002376534377635860>



We'll discuss the following items on the agenda 
<https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
and anything else that comes up:

1. Continue Measured Boot discussion.

2. Gerrit review: Proposal for dynamic changes to Redfish authorization 
rules https://gerrit.openbmc.org/c/openbmc/docs/+/56401


Access, agenda and notes are in the wiki:
https://github.com/openbmc/openbmc/wiki/Security-working-group 
<https://github.com/openbmc/openbmc/wiki/Security-working-group>

- Joseph

Re: Security Working Group meeting - Wednesday August 31 - new venue

[Joseph Reynolds]

Effective immediately, the Security Working Group meeting access is on 
Discord voice.  Please update your calendars.   The meeting date and 
time is unchanged.

Discord > OpenBMC > Voice channels >  Security:
https://discord.com/channels/775381525260664832/1002376534377635860


On 8/30/22 8:08 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday August 31 at 10:00am PDT.
>
>
> ATTNTION - Venue Change.  The meeting moved to Discord voice, 
> beginning with this meeting.  Please update your calendars.
>
> === MEETING ACCESS ON DISCORD VOICE starting on Aug 31, 2022  ===
>
> Discord > OpenBMC > Voice channels >  Security ~ 
> https://discord.com/channels/775381525260664832/1002376534377635860 
> <https://discord.com/channels/775381525260664832/1002376534377635860>
>
>
>
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
> and anything else that comes up:
>
> 1. Continue Measured Boot discussion.
>
> 2. Gerrit review: Proposal for dynamic changes to Redfish 
> authorization rules https://gerrit.openbmc.org/c/openbmc/docs/+/56401
>
>
> Access, agenda and notes are in the wiki:
> https://github.com/openbmc/openbmc/wiki/Security-working-group 
> <https://github.com/openbmc/openbmc/wiki/Security-working-group>
>
> - Joseph

Re: Security Working Group meeting - Wednesday August 31 - results

[Joseph Reynolds]

On 8/30/22 8:08 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday August 31 at 10:00am PDT.
>
>
> ATTNTION - Venue Change.  The meeting moved to Discord voice, 
> beginning with this meeting.  Please update your calendars.
>
> === MEETING ACCESS ON DISCORD VOICE starting on Aug 31, 2022  ===
>
> Discord > OpenBMC > Voice channels >  Security ~ 
> https://discord.com/channels/775381525260664832/1002376534377635860 
> <https://discord.com/channels/775381525260664832/1002376534377635860>
>
>
>
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
> and anything else that comes up:

Attendees (as Discord screen names): josephreynolds, galmasi, alda, 
ddaniil, dsp, fnichols3, jiangz, pgc, Rob, RussWilson, 
skotheshwara,YutakaSugawara.


0 We took about 15 minutes to try out the new Discord voice access and 
to escort folks from the old Webex meeting.

1 Continue Measured Boot discussion

DISCUSSION: Create two separate designs for:

  *

    Enable measured boot.

  *

    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.


2  Proposal for dynamic changes to Redfish authorization rules 
https://gerrit.openbmc.org/c/openbmc/docs/+/56401 
<https://gerrit.openbmc.org/c/openbmc/docs/+/56401>

No discussion.


3 Proposal to change the meeting time so folks from other time zones can 
better participate.

We are also looking for alternate (non voice) ways to cover the material.

We looked at recording the call, but Discord does not have a record button.

We proposed alternating meeting times to cover time zones in California, 
US Central, Europe, India, China, and Australia.  (So, pretty much the 
whole world.)

TODO: Joseph to create a poll, suggest alternate meeting times: 9am CDT 
& 5pm CDT or 8am Australia.



>
> Access, agenda and notes are in the wiki:
> https://github.com/openbmc/openbmc/wiki/Security-working-group 
> <https://github.com/openbmc/openbmc/wiki/Security-working-group>
>
> - Joseph

Re: Security Working Group meeting - Wednesday August 31 - results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

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

Are we also planning on providing attestation information over Redfish?

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security Working Group meeting - Wednesday August 31 - results

[Brad Bishop]

On Thu, Sep 01, 2022 at 06:25:24AM -0500, Patrick Williams wrote:

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

Is the suggestion that they rewrite it in C++ and contribute that?  If 
it is, why would they invest in building a project and community from 
scratch as opposed to using an existing one just because all the other 
in-tree servers are hyper-cost optimized?

Re: Security Working Group meeting - Wednesday August 31 - results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

On Thu, Sep 01, 2022 at 08:41:53AM -0400, Brad Bishop wrote:
> On Thu, Sep 01, 2022 at 06:25:24AM -0500, Patrick Williams wrote:
> 
> >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).
> 
> Is the suggestion that they rewrite it in C++ and contribute that?  If 
> it is, why would they invest in building a project and community from 
> scratch as opposed to using an existing one just because all the other 
> in-tree servers are hyper-cost optimized?

I'm not suggesting anything at this point.  I don't really understand
what Keylime achieves.  I'm just pointing out that it is Python which is
another negative for it.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security Working Group meeting - Wednesday August 31 - results

[Joseph Reynolds]

On 9/1/22 7:41 AM, Brad Bishop wrote:
> On Thu, Sep 01, 2022 at 06:25:24AM -0500, Patrick Williams wrote:
>
>> 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).
>
> Is the suggestion that they rewrite it in C++ and contribute that?  If 
> it is, why would they invest in building a project and community from 
> scratch as opposed to using an existing one just because all the other 
> in-tree servers are hyper-cost optimized?

I read "applicability" into Patrick's question.  My first thought was 
someone asking why IBM is proposing to put complex and space-consuming 
features into the project, and who else needs them?

I recall from the meeting, but didn't put into the minutes, that the 
Keylime project is creating an implementation based on the Rust language.
The OpenBMC project discussed Rust some years ago, as a language which 
adds additional safety guarantees.  But I am aware of no discussion or 
progress since then, and I didn't find any Rust support in the 
OpenEmbedded/bitbake project (but I think it would be welcome).

Joseph

Re: Security Working Group meeting - Wednesday August 31 - results

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]


My understanding is that keylime is being rewritten in Rust.
(but, it was a comment made in possing, which maybe I misunderstood)

{Also IETF RATS Architecture editor...}

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Security Working Group meeting - Wednesday August 31 - results

[Thore Sommer]

> My understanding is that keylime is being rewritten in Rust.

The Keylime agent is rewritten in Rust and the plan is that it will
become the official agent over the next couple of months.
The tracking issue can be found here:
https://github.com/keylime/keylime/issues/986

The server components are in Python and there is currently no plan to
change that.

Re: Security Working Group meeting - Wednesday August 31 - results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

On Fri, Sep 02, 2022 at 07:07:58PM +0300, Thore Sommer wrote:
> > My understanding is that keylime is being rewritten in Rust.
> 
> The Keylime agent is rewritten in Rust and the plan is that it will
> become the official agent over the next couple of months.
> The tracking issue can be found here:
> https://github.com/keylime/keylime/issues/986
> 
> The server components are in Python and there is currently no plan to
> change that.

Thank you for the info Thore.  The agent is the most important piece to
us on this effort.  The server side (verifier) typically has a lot more
flexibility in what software stack it can run.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security Working Group meeting - Wednesday August 31 - results

[Joseph Reynolds]

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

Re: Security Working Group meeting - Wednesday August 31 - results

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 2707 bytes --]


Joseph Reynolds <jrey@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:
    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.

    > 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@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Security Working Group meeting - Wednesday August 31 - results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

On Tue, Sep 06, 2022 at 04:05:19AM -0400, Michael Richardson wrote:
> Joseph Reynolds <jrey@linux.ibm.com> wrote:
>     > 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.

Yes, there is already Rust support in bitbake/Yocto.  It has been
available since probably Dunfell.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 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

Re: Security Working Group meeting - Wednesday August 31 - results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 4946 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security Working Group meeting - Wednesday August 31 - results

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]


Patrick Williams <patrick@stwcx.xyz> wrote:
    > 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.

Presumably customer that want to have measured boot for their BMC have the
incentive to install such a system.  I know that IBM has sufficiently people
involved with TCG that they ought to already have product that can do this,
but I don't know the product names.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Security Working Group meeting - Wednesday August 31 - results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On Wed, Aug 31, 2022 at 01:09:10PM -0500, Joseph Reynolds wrote:

> 2  Proposal for dynamic changes to Redfish authorization rules 
> https://gerrit.openbmc.org/c/openbmc/docs/+/56401 
> <https://gerrit.openbmc.org/c/openbmc/docs/+/56401>
> 
> No discussion.

Does "no discussion" mean?
   - This topic was not covered.
   - Nobody present seemed to have an opinion.
   - Everyone present was onboard with it as-is.

I'm trying to gauge where consensus is at.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security Working Group meeting - Wednesday August 31 - results

[Joseph Reynolds]

On 9/1/22 6:27 AM, Patrick Williams wrote:
> On Wed, Aug 31, 2022 at 01:09:10PM -0500, Joseph Reynolds wrote:
>
>> 2  Proposal for dynamic changes to Redfish authorization rules
>> https://gerrit.openbmc.org/c/openbmc/docs/+/56401
>> <https://gerrit.openbmc.org/c/openbmc/docs/+/56401>
>>
>> No discussion.
> Does "no discussion" mean?
>     - This topic was not covered.
>     - Nobody present seemed to have an opinion.
>     - Everyone present was onboard with it as-is.
>
> I'm trying to gauge where consensus is at.

I use "no discussion" when the topic was introduces and described, but 
nobody expressed any interest or asked any questions.  I think someone 
asked for the review link, which was already in the agenda. <-- Is there 
a better way I could say this in the meeting minutes?
When an agenda item is skipped or omitted from the meeting, I'll put 
something like "the following topics were not covered" with the reason why.

Joseph

Re: Security Working Group meeting - Wednesday August 31 - results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On Mon, Sep 05, 2022 at 01:59:56PM -0500, Joseph Reynolds wrote:
> On 9/1/22 6:27 AM, Patrick Williams wrote:
> > On Wed, Aug 31, 2022 at 01:09:10PM -0500, Joseph Reynolds wrote:
> >
> >> 2  Proposal for dynamic changes to Redfish authorization rules
> >> https://gerrit.openbmc.org/c/openbmc/docs/+/56401
> >> <https://gerrit.openbmc.org/c/openbmc/docs/+/56401>
> >>
> >> No discussion.
> > Does "no discussion" mean?
> >     - This topic was not covered.
> >     - Nobody present seemed to have an opinion.
> >     - Everyone present was onboard with it as-is.
> >
> > I'm trying to gauge where consensus is at.
> 
> I use "no discussion" when the topic was introduces and described, but 
> nobody expressed any interest or asked any questions.  I think someone 
> asked for the review link, which was already in the agenda. <-- Is there 
> a better way I could say this in the meeting minutes?
> When an agenda item is skipped or omitted from the meeting, I'll put 
> something like "the following topics were not covered" with the reason why.

Thank you for the clarification.

I assumed it was either 2 or 3 from my list above.  Sounds like you are
using "no discussion" to mean 2.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Security Working Group meeting - Wednesday August 31 - results

[George Almasi]

First off, apologies if I am messing up the mailing list threading. I'm 
going to attempt to address
questions raised by Patrick about keylime and openbmc in the last few days.

> Is the suggestion that they rewrite it in C++ and contribute that?  If 
> it is, why would they invest in building a project and community from 
> scratch as opposed to using an existing one just because all the other 
> in-tree servers are hyper-cost optimized?

No. To repeat what Thore Somers mentioned: the Red Hat team has done
a good job of porting the keylime *agent* to Rust.

We will never attempt to cram Python into OpenBMC :)

The rust agent compiles and runs on the generic ARM version of OpenBMC;
we have tested this, and Angelo Ruocco is working on a recipe. We are
having difficulties with the AST2600 in particular, but that seems to
be more of a Rust/ARM compilation issue than anything else. We are having
zero troubles on a generic armv7 qemu emulator.

In reply to Michael Richardson -- the _entire_ keylime project is not being
rewritten in rust; only the agent is. The verifiers and registrars and whatnot
have no reason to exist on embedded systems, and there is no reason to make
small footprint versions of them.


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


Valid concern. Agreed on not advertising firmware (or kernel) (or anything)
versions to anyone who has no business knowing these things. Fortunately
the keylime developers have considered these issues and over time have
come up with a fairly safe architecture for establishing mutual trust between
agents and other keylime components (like registrars and verifiers). The
security architecture _has_ been peer reviewed and tweaked.

I am not going to attempt to reproduce the entire process here,
but I'll mention salient points of it. First off, the keylime agent will
not blindly talk to just anyone. The agent has to be configured a-priori
with the IP address of a registrar, and it will not attempt to establish
communication with any other entity.

Of course IP addresses can be spoofed, so the keylime agent possesses a certificate
that will authenticate the registrar. The current implementation is an mTLS cert, but a server
side certificate would suffice for this, as the entity being authenticated is the registrar,
not the OpenBMC agent.

Next, of course, the agent has to authenticate itself to the registrar. The TPM device is a crypto engine
with a key pair built into it for the express purpose of identifying itself (the Endorsement Key).
The process of authenticating a TPM device to the registrar is fairly complex and involves a a roundtrip.
In this process other (secondary) keys are created that are henceforth used for regular communication.

I'm going to stop here before this becomes a lecture. From a practical standpoint, getting the keylime
agent into OpenBMC involves getting the agent built in the ecosystem, and inventing a way to
configure the system. Since attestation with keylime can be done at _any point_ in the lifecycle
of an OpenBMC deployment, it is sufficient for us to configure the keylime agent with redfish; and that is
our plan. Details to follow.

Re: Security Working Group meeting - Wednesday August 31 - results

[George Almasi]

On 9/9/22 3:53 AM, Michael Richardson wrote:
> Thank you for the post.
> I'm interested in understanding how you will do provisioning of the TPM keys.
Hi Michael. I'm going to describe the standard keylime agent 
registration process in a bit more detail -- but not too much, or this 
will be a very long post indeed.

1. EK certificate.

What this is for: The EK certificate on each TPM is verifiable against 
the root CA of the manufacturer, which gives us confidence that the TPM 
is the genuine article and not a counterfeit.

Keylime makes the assumption that the TPM device's EK certificate is 
available on the device. While the
EK certificate can be deleted from the TPM by the end user, devices 
[ought to] ship with it from the TPM manufacturer.

It is possible to use self-signed EK certificates for TPM devices. But 
that weakens the chain of trust provided by keylime, since it involves 
you -- the creator of said certs -- in the process, instead of using the 
likes of Infineon or Nuvoton for the purpose. We think it is *always* 
better to use the manufacturer's key if it is available, rather than 
create our own keys and headaches. Keylime comes with a pre-populated 
list of manufacturer certificates it will accept, and said list includes 
the most widely used manufacturers of TPM devices. FWIW our AST2600 EVBs 
have Nuvoton devices, whereas my Raspberry Pi has an Infineon Optiga :)

2. Public EK (endorsement key)

What this is for: This key defines the identity of the TPM device, and 
is used as such by keylime. It is signed by the EK certificate. To some 
degree of approximation this key pair is "burned into the device" -- not 
literally true, but can be re-generated at will from seeds that *are* 
burned into the device.


The keylime agent usually (re)generates the EK and sends the public part 
(the only part available to anyone outside the device) to the keylime 
registrar, together with the EK certificate. The registrar can then make 
a decision about whether the keylime agent has a genuine TPM device in 
possession, and whether the message coming from network address X and 
hostname Y really corresponds to the correct EK. This guards against say 
spoofing an entire node with keylime.


3. AK (attestation key)

What this is for: the attestation key is the key pair the TPM device 
will use for signing its reports ("quotes") when asked to do so by the 
keylime agent.

The attestation key is established and authenticated cooperatively 
between the TPM device, the keylime agent and the keylime registrar 
using a very careful choreography. The keylime agent must guard against 
someone spoofing the registrar (we use a pre-established server TLS cert 
for this purpose, much like your browser does when it decides to trust 
e.g. ibm.com). The keylime registrar decides whether to trust the 
keylime agent sending it the EK pubkey and certificate as described above.

I will not describe the roundtrip process to establish and activate the 
attestation key.

But *once this roundtrip is complete*, the TPM is "tied" to the keylime 
registrar and will be able to respond to quote requests in a manner that 
is not susceptible to MitM attacks ... which is the goal of the exercise.

That's it. There are additional keys used by keylime for the purpose of 
establishing direct connection between the agent and third parties 
(called "tenants"), but those keys do not involve the TPM device so I'm 
not going to describe them here.


-- George