Re: bmcweb: Install encrypted certificate to BMC

From: Ed Tanous <edtanous@google.com>
To: Patrick Williams <patrick@stwcx.xyz>
Cc: Justin Chen <juschen@google.com>,
	Michael Richardson <mcr@sandelman.ca>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Ed Tanous <ed@tanous.net>, Richard Hanley <rhanley@google.com>,
	gmills@us.ibm.com, Zhenfei Tai <ztai@google.com>
Subject: Re: bmcweb: Install encrypted certificate to BMC
Date: Fri, 23 Apr 2021 09:37:12 -0700	[thread overview]
Message-ID: <CAH2-KxBWxHkSwKbfkymTV8amdGQAcdtrnG0+bphVtq9FKPDfxg@mail.gmail.com> (raw)
In-Reply-To: <YILK8BCaKDbVnad+@heinlein>

On Fri, Apr 23, 2021 at 6:26 AM Patrick Williams <patrick@stwcx.xyz> wrote:
>
> On Mon, Apr 19, 2021 at 12:18:15AM -0700, Ed Tanous wrote:
> > On Sat, Apr 17, 2021 at 11:56 AM Michael Richardson <mcr@sandelman.ca> wrote:
> > > Zhenfei Tai <ztai@google.com> wrote:
> > > If you have a daemon present that can decrypt things, then you already have a
> > > private key (or symmetric key) present, and that key is subject to attack.
> > > (Unless you add yet another layer of indirection via TPM chip....)
> >
> > This wasn't clear in the initial email, but yes, this would be a case
> > of exactly what you described in the "unless" part.  The TPM-like chip
> > has a specific format that we're hoping to upload to it through the
> > OOB interfaces that would give it a form of identity.
> >
> > >
> > > I strongly recommend that you do not invent new technology here.
> > > EST (RFC7030) is considered the best technology here, with SCEP (RFC8894)
> > > being a legacy choice.
> >
> > I read through that spec a bit.  The issue there is that it has no
> > compatibility with Redfish, so implementing that would be yet another
> > subsystem to build and maintain, and wouldn't work in tandem with
> > Redfish aggregators once the key was decoded.  While I wouldn't be
> > against anyone implementing that on OpenBMC, that wouldn't meet the
> > needs of what we're trying to accomplish;  Also, it isn't clear that
> > RFC8894 has provisions for custom certificate formats, of which this
> > would definitely be one.
>
> There really isn't much in Redfish (or our dbus interfaces) about TPMs.
> I think that provisioning and attestation are two big functional areas
> that are coming to the forefront.  It would be nice if someone with
> bandwidth and access could pave the way on the Redfish side of things
> for TPM management.  I am certainly interested in the attestation end.

FYI, Redfish just added SPDM support via the MeasurementBlock property
in the SoftwareInventory schema.  Might be worth looking into for the
attestation case.

>
> --
> Patrick Williams