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