bmcweb: Install encrypted certificate to BMC

bmcweb: Install encrypted certificate to BMC

[Zhenfei Tai]

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

Hi,

Currently certificate installation is supported by bmcweb via
*redfish/v1/Managers/bmc/Truststore/Certificates*, where the certificate
content is part of the JSON request.

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.

Since it's not supported by the Redfish schema, my plan is to use the
*redfish/v1/CertificateSerivce/OemActions* URI and a request payload like
below:
{
  "key": "encrypted key in binary",
  "certificate": "encrypted certificate in binary"
}

The reasons to use the URI and payload are:
1. It's related to certificate service although in opaque blobs.
2. It's fairly company specific that probably isn't universally applicable.

My questions are:
1. Is this a reasonable approach?
2. Shall we define an OEM schema for our request?

Thanks,
Zhenfei

[-- Attachment #2: Type: text/html, Size: 1379 bytes --]

Re: bmcweb: Install encrypted certificate to BMC

[Michael Richardson]

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


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?
Is this an IDevID-like installed by the manufacturer, or is this a cert/key
to be used on the production floor (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....)

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.

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



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

Re: bmcweb: Install encrypted certificate to BMC

[Ed Tanous]

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.

Re: bmcweb: Install encrypted certificate to BMC

[Patrick Williams]

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

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.

-- 
Patrick Williams

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

Re: bmcweb: Install encrypted certificate to BMC

[Ed Tanous]

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