Security Working Group meeting - Wednesday March 29 - results

[Joseph Reynolds]

An OpenBMC Security Working Group meeting was held on Wednesday March 29 
at 10:00am PDT.

MEETING ACCESS ON DISCORD VOICE
First, join Discord via https://discord.gg/69Km47zH98 
<https://discord.gg/69Km47zH98> and confirm via email.
Then, to join: navigate Discord > OpenBMC > Voice channels >  Security ~ 
https://discord.com/channels/775381525260664832/1002376534377635860 
<https://discord.com/channels/775381525260664832/1002376534377635860>

Access and notes about the Security Working Group are in the OpenBMC 
Security wiki:
https://github.com/openbmc/openbmc/wiki/Security-working-group 
<https://github.com/openbmc/openbmc/wiki/Security-working-group>

The meeting agenda and minutes are in 
<https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
items proposed on the Discord OpenBMC #security channel, and anything 
else that comes up:

Attended: Joseph Reynolds, dsp (Dhananjay), Daniil Engeranov, jejb, cacih

TOPICS:

1 Joseph: Is there a common use case to get “service” access to the 
BMC?  A “service user” means a person authorized by the system 
manufacturer or OEM who is trusted to access BMC internals as needed to 
diagnose or fix problems on the BMC; they are allowed to use interfaces 
which are not accessible to BMC admin user, for example REST APIs only 
allowed to “service” users, or to get root user access to the BMC 
command shell.


For context, assume the BMC admin user does not have access to the BMC 
command shell and can only access the BMC’s REST APIs and similar 
external interfaces; that is, the BMC admin has no access to BMC 
internals.  Also, assume the BMC admin has access to the BMC’s 
management network, and can share that access with a service user.


DISCUSSION (joseph and dsp):

Joseph discussed IBM’s custom Access Control File (ACF) solution, and 
Dhananjay discussed Microsoft's Secure Unlock.


IBM ACF: Joseph reviewed the steps for an IBM service agent to get 
service access to a customer BMC.  The steps are:

 1.

    The customer calls for service and gives the system serial number to
    the service rep.

 2.

    The service rep uses their access (access to the private key, which
    is stored behind their organization’s firewall) to create a token
    (an ACF file).  This ACF file contains a request to access to BMC,
    identifies a date range, and identifies the system serial number. 
    It is digitally signed by a private key held by the service
    organization, and the BMC can validate the signature via a public
    key which is built into the BMC firmware.

 3.

    The service rep gives the ACF file to the customer/admin.  (The ACF
    file has no secrets other than the secure hash of the service
    account’s password.)

 4.

    The BMC admin uploads the ACF to the BMC.  Doing so enables the
    service user password access.

 5.

    The service user can now login to the BMC, using the password stored
    in the ACF.

 6.

    If desired, the admin or service agent can delete the ACF, or allow
    it to expire.

WIP Design: https://gerrit.openbmc.org/c/openbmc/docs/+/45201 
<https://gerrit.openbmc.org/c/openbmc/docs/+/45201>  .  The 
implementation is in IBM’s public downstream (github.com/ibm-openbmc) 
version of bmcweb and phosphor-certificate-manager.

Note: the ACF is ASN.1-encoded (binary file) but is not an x.509 
certificate.


Microsoft Secure Unlock: Dhananjay reviewed Secure Unlock.  The 
approximate steps are:

 1.

    Retrieve info from BMC’s RoT.

 2.

    This info goes to the service organization (behind the firewall),
    which uses it to create a token needed to access the BMC.

 3.

    This access token is uploaded to BMC.

Touchpoint: a use case for this token is to disable secure boot


The common use case?

There is a common use case for REST APIs to:

  *

    Initiate a request for service access to the BMC.

  *

    Upload a service access token to the BMC.

With additional APIs desired for inspecting and deleting the access token.

[Although not discussed, I presume at most 1 access token at a time is 
allowed.]


A common use case:

In addition to the use case to get BMC root access…

Recover admin account access.  Customers regularly call for service 
because they lost access to their admin account.  Recovery means, for 
example: recreate the admin account or set it to a usable state, and set 
its password to a known value, reset its password lockout, etc.

It is desired to be able to create an access token which performs only 
this admin account recovery, and does not grant general access to BMC 
internals.


There are at least 2 shared use cases for the access token.  That is, 
the access token can be create for one of these purposes:

 1.

    Enable service user login.

 2.

    Recover access to the BMC’s admin account.

There are multiple other purposes; one mentioned is to disable secure boot.

In other words, the token encodes a specific action, such as listed above.

Each manufacturer would have a different set of purposes for the tokens, 
and we do not image these would be shared.


Anti-replay protection for these access tokens is assumed.  For example, 
an access token used to get access to a BMC command shell could not be 
used twice: the second attempt to upload it should result in permission 
denied with reason: anti-replay protection.  (In this example, login 
access is allowed multiple times until the ACF expires or is deleted.)


TODO for Joseph: We decided to start a design for this. Daniil asked: 
Create a new bitbake image feature to optionally build in the “service 
access” APIs.  When present a system integrator would have to hook up an 
appropriate implementation ~ 
https://github.com/openbmc/openbmc/wiki/Configuration-guide 
<https://github.com/openbmc/openbmc/wiki/Configuration-guide>.

When the service access APIs are built into the image, should there be 
an API to disable it?




- Joseph