* Security Working Group meeting - Wednesday February 2
@ 2022-02-02 3:24 Joseph Reynolds
2022-02-02 21:21 ` Joseph Reynolds
0 siblings, 1 reply; 7+ messages in thread
From: Joseph Reynolds @ 2022-02-02 3:24 UTC (permalink / raw)
To: openbmc
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Security Working Group meeting - Wednesday February 2
2022-02-02 3:24 Security Working Group meeting - Wednesday February 2 Joseph Reynolds
@ 2022-02-02 21:21 ` Joseph Reynolds
2022-02-02 23:31 ` Andrew Jeffery
2022-02-03 19:13 ` Michael Richardson
0 siblings, 2 replies; 7+ messages in thread
From: Joseph Reynolds @ 2022-02-02 21:21 UTC (permalink / raw)
To: openbmc
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Security Working Group meeting - Wednesday February 2
2022-02-02 21:21 ` Joseph Reynolds
@ 2022-02-02 23:31 ` Andrew Jeffery
2022-02-03 5:05 ` Andrew Jeffery
2022-02-03 19:13 ` Michael Richardson
1 sibling, 1 reply; 7+ messages in thread
From: Andrew Jeffery @ 2022-02-02 23:31 UTC (permalink / raw)
To: Joseph Reynolds, openbmc; +Cc: Christopher J Engel, jamin_lin
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Security Working Group meeting - Wednesday February 2
2022-02-02 23:31 ` Andrew Jeffery
@ 2022-02-03 5:05 ` Andrew Jeffery
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Jeffery @ 2022-02-03 5:05 UTC (permalink / raw)
To: Joseph Reynolds, openbmc; +Cc: Christopher J Engel, Jamin Lin
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Security Working Group meeting - Wednesday February 2
2022-02-02 21:21 ` Joseph Reynolds
2022-02-02 23:31 ` Andrew Jeffery
@ 2022-02-03 19:13 ` Michael Richardson
2022-02-04 7:21 ` Andrew Jeffery
1 sibling, 1 reply; 7+ messages in thread
From: Michael Richardson @ 2022-02-03 19:13 UTC (permalink / raw)
To: openbmc
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Security Working Group meeting - Wednesday February 2
2022-02-03 19:13 ` Michael Richardson
@ 2022-02-04 7:21 ` Andrew Jeffery
2022-02-04 16:54 ` Michael Richardson
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Jeffery @ 2022-02-04 7:21 UTC (permalink / raw)
To: Michael Richardson, openbmc
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Security Working Group meeting - Wednesday February 2
2022-02-04 7:21 ` Andrew Jeffery
@ 2022-02-04 16:54 ` Michael Richardson
0 siblings, 0 replies; 7+ messages in thread
From: Michael Richardson @ 2022-02-04 16:54 UTC (permalink / raw)
To: Andrew Jeffery, openbmc
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-02-04 16:55 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-02 3:24 Security Working Group meeting - Wednesday February 2 Joseph Reynolds
2022-02-02 21:21 ` Joseph Reynolds
2022-02-02 23:31 ` Andrew Jeffery
2022-02-03 5:05 ` Andrew Jeffery
2022-02-03 19:13 ` Michael Richardson
2022-02-04 7:21 ` Andrew Jeffery
2022-02-04 16:54 ` Michael Richardson
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.