Security Working Group meeting - Wednesday February 2

Security Working Group meeting - Wednesday February 2

[Joseph Reynolds]

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

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

1. followup from previous meeting: OpenBMC’s AST2600 RoT work 2. discuss 
the concept and need for NoAccess users and how they would be different 
from disabled BMC user accounts



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 February 2

[Joseph Reynolds]

On 2/1/22 9:24 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday February 2 at 10:00am PDT.
>
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
> and anything else that comes up:

Attended: Joseph, Jiang, Dick, Michael Richardson, Daniil, Surya, James, 
Dhananjay

Note that we started on topic 1 (RoT), and then covered topic 3 (CNA) 
before returning to topic 1.  Topic 2 (NoAccess users) was not covered.


>
> 1. followup from previous meeting: OpenBMC’s AST2600 RoT work 2. 
> discuss the concept and need for NoAccess users and how they would be 
> different from disabled BMC user accounts

1 followup from previous meeting: OpenBMC’s AST2600 RoT work is here 
https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/49789 
<https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/49789>with the 
underlying OE/bitbake recipe here: 
https://github.com/openbmc/openbmc/blob/master/meta-aspeed/classes/socsec-sign.bbclass 
<https://github.com/openbmc/openbmc/blob/master/meta-aspeed/classes/socsec-sign.bbclass>.  
Note OTP refers to one-time programmable memory used to set the signing 
key, etc.  Also I (Joseph Reynolds) believe the AST2600 specs are not 
public domain.

…  and general  OpenBMC Root of Trust (RoT) discussion


DISCUSSION:

Secure boot trust chain: the BMC hardware performs secure boot of the 
bootloader (e.g., U-Boot, then U-Boot verifies 
{kernel,devicetree,rootfs}, etc., up to starting the application.


Secure boot has three layers: 1 hardware validates uboot, 2 U-Boot 
validates the Readonly fs, 3 the operation system validates applications.

To validate before starting applications:  DMverity, IMA


The OpenBMC project is working to support the first layer, specifically 
AST2600 secure booting U-Boot.  The intention is then to support U-Boot  
securely booting the next layer (kernel, etc.)  Also there is interest 
in using DMverity and IMA, but no agreements.


Who programs the BMC’s OTP memory?  Different use cases: one of: BMC 
vendor, board manufacturer, or customer/installation.


How to validate the BMC hardware?  Different use cases: RoT is the BMC 
-vs- an external component.


Does BMC download applications as part of its intended operation?  
Different use cases.

In the base use case, the BMC read only file system has all 
applications.  Only developers (and advanced diagnostics) download code, 
presumably to test fixes or collect more diagnostic data.

Use cases include both validating the filesystem which has the code, and 
validating the app itself as it is loaded (exec’d) into a Linux process.


Does OpenBMC support Firmware encryption?  symmetric/asymmetric.    
AST2600 supports AES encrypted bootloaders. But there is not currently 
support for this in OpenBMC.

Note that the latest U-Boot version supports encrypted firmware (for 
example, it decrypts the kernel).



2 Do we need to discuss the concept and need for NoAccess users and how 
they would be different from disabled BMC user accounts?  See discussion 
in https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/49295 
<https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/49295>

DISCUSSION - was not discussed because we were out of time.



3 CNA Organization Admin account and authorized users

DISCUSSION:

James is working with Mitre to get a “CNA organizational admin” account 
so OpenBMC can write CVEs in its role as a CNA.

Working the OpenBMC vulnerability backlog…intends to write CVEs.

We briefly discussed our direction to use Github security workflow to 
publish OpenBMC security bulletins on github.



Joseph

>
>
> 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 February 2

[Andrew Jeffery]

On Thu, 3 Feb 2022, at 07:51, Joseph Reynolds wrote:
> On 2/1/22 9:24 PM, Joseph Reynolds wrote:
>> This is a reminder of the OpenBMC Security Working Group meeting 
>> scheduled for this Wednesday February 2 at 10:00am PDT.
>>
>> We'll discuss the following items on the agenda 
>> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
>> and anything else that comes up:
>
> Attended: Joseph, Jiang, Dick, Michael Richardson, Daniil, Surya, James, 
> Dhananjay
>
> Note that we started on topic 1 (RoT), and then covered topic 3 (CNA) 
> before returning to topic 1.  Topic 2 (NoAccess users) was not covered.
>
>
>>
>> 1. followup from previous meeting: OpenBMC’s AST2600 RoT work 2. 
>> discuss the concept and need for NoAccess users and how they would be 
>> different from disabled BMC user accounts
>
> 1 followup from previous meeting: OpenBMC’s AST2600 RoT work is here 
> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/49789 
> <https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/49789>with the 
> underlying OE/bitbake recipe here: 
> https://github.com/openbmc/openbmc/blob/master/meta-aspeed/classes/socsec-sign.bbclass 
> <https://github.com/openbmc/openbmc/blob/master/meta-aspeed/classes/socsec-sign.bbclass>.  
> Note OTP refers to one-time programmable memory used to set the signing 
> key, etc.  Also I (Joseph Reynolds) believe the AST2600 specs are not 
> public domain.

There's another related patch in-flight that adds the OTP configuration 
for p10bmc. It might be a helpful reference. The only thing I'd ask is 
that people use big-endian mode for their keys (which isn't what has 
happened with p10bmc):

https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/50716

SOCSEC_SIGN_ENABLE: command not found
Other than that the only thing that's required is setting  in the 
machine configuration, e.g:

https://github.com/openbmc/openbmc/blob/bb99d22ecef61f3af21290b1e1ead3083f25d20f/meta-ibm/conf/machine/p10bmc.conf#L56

>
> …  and general  OpenBMC Root of Trust (RoT) discussion
>
>
> DISCUSSION:
>
> Secure boot trust chain: the BMC hardware performs secure boot of the 
> bootloader (e.g., U-Boot, then U-Boot verifies 
> {kernel,devicetree,rootfs}, etc., up to starting the application.
>
>
> Secure boot has three layers: 1 hardware validates uboot, 2 U-Boot 
> validates the Readonly fs, 3 the operation system validates applications.

This is close but could be more general and more precise:

1. The hardware loads loads the bootloader and validates its signature
2. The bootloader loads the kernel and validates its signature
3. The kernel locates the rootfs and uses a mechanism to verify its 
integrity

Mapping that to the AST2600, we have:

1. The ROM code loads the u-boot SPL into SRAM and validates its 
signature using the public keys from the OTP

2. The SPL loads the u-boot FIT image into DRAM and validates the 
configuration signatures over the hashes of the embedded images using 
the keys residing in the SPL image

3. u-boot loads the kernel FIT image into DRAM and validates the 
configuration signatures over the hashes of the embedded images using 
keys residing in the u-boot image

4. The kernel locates the rootfs and uses a mechanism to verify its 
integrity

> To validate before starting applications:  DMverity, IMA
>
>
> The OpenBMC project is working to support the first layer, specifically 
> AST2600 secure booting U-Boot.  The intention is then to support U-Boot  
> securely booting the next layer (kernel, etc.)  

Again, not quite true.

It's already the case that the SPL validates u-boot and u-boot 
validates the kernel where signing for each is enabled.

Again, leaning on p10bmc as a reference, this scheme is enabled here:

https://github.com/openbmc/openbmc/blob/bb99d22ecef61f3af21290b1e1ead3083f25d20f/meta-ibm/conf/machine/p10bmc.conf#L39-L40

The patches linked earlier add the hardware root-of-trust support 
(generating the AST2600 OTP image and signing the SPL in a manner that 
can pass verification using the OTP image).

> Also there is interest 
> in using DMverity and IMA, but no agreements.

dm-verity is conceptually simpler than IMA, but has limitations that 
IMA can help overcome, so as you say, at least from IBM's perspective, 
we're still working through the details here.

> Does BMC download applications as part of its intended operation?  
> Different use cases.
>
> In the base use case, the BMC read only file system has all 
> applications.  Only developers (and advanced diagnostics) download code, 
> presumably to test fixes or collect more diagnostic data.
>
> Use cases include both validating the filesystem which has the code, and 
> validating the app itself as it is loaded (exec’d) into a Linux process.

If no modifications are made to the filesystem then validating the 
integrity of the filesystem is the same as validating the integrity of 
the application. However in the face of run-time modifications to the 
filesystem, IMA's design helps prevent arbitrary code execution by 
enabling policies such as "any exec'ed file must have a valid 
signature". Trying to enforce a signed execution environment in the 
face of mutable filesystems is hard with dm-verity.

Andrew

Re: Security Working Group meeting - Wednesday February 2

[Andrew Jeffery]

On Thu, 3 Feb 2022, at 10:01, Andrew Jeffery wrote:
>
> SOCSEC_SIGN_ENABLE: command not found

I did say something else here but it got eaten by my awful 
line-wrapping strategy :(

I think it was pointing out that you just need to set

SOCSEC_SIGN_ENABLE = "1"

to enable SPL signing.

Andrew

Re: Security Working Group meeting - Wednesday February 2

[Michael Richardson]

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


Thanks for the great notes!

It would be good if this commit noted that socsec-sign is a tool that comes from AST.
Perhaps I can figure out how to do the gerrit dance and make the comments there.

It would also be good if the document which contains the details was noted in
the commit by name and/or document ID.  Yes, as I understand it's under NDA
but at least, if someone comes along and wants details, they'll know
exactly what they want details on.

In order to support signing the uboot images, and for the uboot image to
verify the flatenned image tree https://elinux.org/images/f/f4/Elc2013_Fernandes.pdf
then the manufacturer needs to maintain some set of signing keys.
There are many ways to do this.  Some time ago, I started an ontology
document about how to describe the different ways.

Your comments would be welcome on:
   https://github.com/mcr/idevid-security-considerations
and:
   https://datatracker.ietf.org/doc/draft-richardson-t2trg-idevid-considerations/

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [





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

Re: Security Working Group meeting - Wednesday February 2

[Andrew Jeffery]

On Fri, 4 Feb 2022, at 05:43, Michael Richardson wrote:
> Thanks for the great notes!
>

You might also be interested in chapters 9 and 10 of https://github.com/AspeedTech-BMC/openbmc/releases/download/v08.00/SDK_User_Guide_v08.00.pdf :)

Andrew

Re: Security Working Group meeting - Wednesday February 2

[Michael Richardson]

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


Andrew Jeffery <andrew@aj.id.au> wrote:
    > On Fri, 4 Feb 2022, at 05:43, Michael Richardson wrote:
    >> Thanks for the great notes!
    >>

    > You might also be interested in chapters 9 and 10 of https://github.com/AspeedTech-BMC/openbmc/releases/download/v08.00/SDK_User_Guide_v08.00.pdf :)

So, not completely under NDA then.
Thank you for pointing at that.
I wish I could edit the missing articles into that document.

I saw that the section after socsec is about boot from uart, which requires a
jumper to be moved.

I see a place for an RSA private key as well as the public ones to validate
the boot image.  Multiple OTP headers, up to 64k bits (8K bytes I guess) is
available.

Is anyone out there using this *today* for signing evidence for a measured
boot?  Or for including an IDevID into the system?   You can unicast me if
you prefer.

Getting manufacturer signed IDevIDs in is critical to getting better
onboarding story for BMCs.  I would love to work with someone to prototype this.

(Ah, xmodem/ymodem brings back many memories.  How much zmodem kicked their
ass.  And telebit trailblazers..)

I wonder if the OpenBMC project cares about the case of the name... as ASPEED
has "OpenBmc" everywhere.  Some people care... It's a bit like Brown M&Ms :-)
(e.g., RFC4301 says it is "IPsec" and not "IPSec")


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




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