Re: bmcweb: Install encrypted certificate to BMC

[Ed Tanous <ed@tanous.net>]

On Sat, Apr 17, 2021 at 11:56 AM Michael Richardson <mcr@sandelman.ca> wrote:
>
>
> Zhenfei Tai <ztai@google.com> wrote:
>     > For our use case it's a more restricted environment in which we don't want
>     > to have plaintext certificates in the request. Instead we want to send a
>     > pair of encrypted key and certificate from the host to the BMC and there
>     > will be another daemon to decrypt them using an internal library.
>
> certificates are public objects.
> Perhaps you are transfering a private key?

Correct;  This wasn't made clear in the initial email, but this
"certificate" is really a certificate and the private key.

> Is this an IDevID-like installed by the manufacturer, or is this a cert/key
> to be used on the production floor (DC).

DC.

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

>
>     > My questions are:
>     > 1. Is this a reasonable approach?
>     > 2. Shall we define an OEM schema for our request?
>
> Finally, I am working on a BRSKI (RFC8995, aka
> draft-ietf-anima-bootstrapping-keyinfra, not quite published, still in middle
> of AUTH48) module for OpenBMC.

Neat.  Looking forward to seeing it.

>   You may prefer help with that instead of
> inventing something that hasn't gone through the same level of review.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
>

While there are efforts to standardize these kinds of payloads (see
cerberus and opentitan) the systems today will never be physically
capable of implementing whatever protocol gets standardized, so we
will need some solution regardless.

In this case, I see 3 options for how to proceed.

1. Create an OEM action within CertificateService, specific to Google,
and namespaced as such.  I'm imagining something like "Google/SetKey".
Considering the TPM-like devices have a device-specific format, and
will only ever be seen on a Google system, this seems like an
appropriate and intended use of Redfish OEM schemas.  If we went this
route, I would commit our team to at least make progress on solving
the existing OEM schema tech debt
(https://github.com/openbmc/bmcweb/issues?q=is%3Aissue+is%3Aopen+label%3A%22OEM+schema%22)
so as this would not make the situation worse.
2. Similar to 1, but the action would be namespaced within OpenBMC.
While this would also solve the problem, in-lies another problem with
how a client would know what the format of the file should be.  Other
systems that implement ROT solutions will likely have their own
format, and clients won't be able to inspect the format.
3. Put it within a google/v1 namespace path similar to ibm/v1.  This
would prevent using Redfish aggregators, which would be a problem for
the intended use case of deploying this to many bmcs.