Security Working Group meeting - Wednesday September 15

Security Working Group meeting - Wednesday September 15

[Joseph Reynolds]

This is a reminder of the OpenBMC Security Working Group meeting 
scheduled for this Wednesday September 15 at 10:00am PDT.

We'll discuss the following items on the agenda 
<https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/edit>, 
and anything else that comes up:

1. (gerrit review) Encrypted eMMC design - 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/46573 
<https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/46573>


2. (email) Reminder that configuration matters. 
https://lore.kernel.org/openbmc/6593206c0bc90186f255c6ea86339576576f70dc.camel@codeconstruct.com.au/ 
<https://lore.kernel.org/openbmc/6593206c0bc90186f255c6ea86339576576f70dc.camel@codeconstruct.com.au/>Discusses 
AST2500 default register configuration (ESPICTRL[9] = 0) which allows 
the host to have full control over the GPIOs.

More?


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

Re: Security Working Group meeting - Wednesday September 15 - results

[Joseph Reynolds]

On 9/14/21 1:48 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday September 15 at 10:00am PDT.
>
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/edit>, 
> and anything else that comes up:

Meeting held 2021-09-15

Attended: Joseph Reynolds, Milton Miller (attended second: IPMI over 
DTLS topic), James Mihm, Vernon Mauery, Daniil Engranov, Dhananjay MSFT, 
Dick [Phoenix], John Wedig, John Broadbent, Nancy Yuen


1 (gerrit review) Encrypted eMMC design - 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/46573 
<https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/46573>

DISCUSSION:

John reviewed the design: eMMC exposed as Dbus object.

We briefly discussed the need for a device-provided cryptographically 
secure erase function, because the block-by-block algorithms don’t work 
in the presence of wear leveling.

How to provide encryption key/password.  Use cases and risk models:

  *

    Key is stored off of the BMC (by client, on eeprom, by host).

  *

    Intent of encryption is to protect against someone physically
    removing the emmc.

  *

    This design does not does not protect against an attacker who has
    BMC root access.


2 (email) Reminder that configuration matters. 
https://lore.kernel.org/openbmc/6593206c0bc90186f255c6ea86339576576f70dc.camel@codeconstruct.com.au/ 
<https://lore.kernel.org/openbmc/6593206c0bc90186f255c6ea86339576576f70dc.camel@codeconstruct.com.au/>Discusses 
AST2500 default register configuration (ESPICTRL[9] = 0) which allows 
the host to have full control over the GPIOs.

NO DISCUSSION.


3 (meeting process) Discuss the use of this document 
(https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI) 
as a record, and not intended as a living conversation.  Idea: Add a 
note to the top of this document to that effect.

DISCUSSION:

Agreement: This doc is only for minutes only, please move discussions 
elsewhere.  Add note.  DONE.


4 (gerrit review) 
https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/46811 
<https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/46811>Change the 
dropbear SSH server “scp” protocol to use “sftp” internally (while still 
supporting scp connections).

DISCUSSION:

We discussed:

  *

    Why do we need sftp?

  *

    Sftp has a better user experience than scp.  The client has better
    controls.

  *

    We should explain how specific platforms or downstream
    configurations can disable sftp?  Should it be disabled by default? 
    Reference:
    https://github.com/openbmc/openbmc/wiki/Configuration-guide
    <https://github.com/openbmc/openbmc/wiki/Configuration-guide>

Agreed: Eventually disable scp by default?  Yes.

There was a general agreement with this proposal: Enable sftp now, have 
both scp and sftp enabled for one release (about a year), then disable 
scp by default.  (The overlap is intended to give time for testers and 
operational procedures to convert to sftp or reconfigure.)

Discussion will continue in the gerrit review.


BONUS TOPIC:

Added after the meeting started, and went about 8 minutes over time.


5 IPMI over DTLS (gerrit review) - 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548 
<https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548>

DISCUSSION:

This is a continuation from last time.

A new question is: Should password authentication be supported?

  *

    Use case: Large scale datacenters will use cert auth, but cert or
    2FA requires infrastructure which small scale users may not have.

  *

    Both cert-based 2FA auth require a synchronized clock:

  *

    The BMC TOD clock may reset to beginning of epoch 1970

  *

    2FA and cert solution needs steady clock: battery backup or NTP


Is it okay to use the same cert for both host and for IPMI?  If one 
service allows the private key to be disclosed or learned, that 
jeopardizes the other services which use that same key.

Disambiguation: User CA cert, host cert.

If we look ahead to process isolation (where each service has its own 
user), what solution will work?

Can we use trusted execution environments: (Op-tee, TPM, kernel support, 
ARM TrustZone), so we don’t expose the key (as much) when establishing a 
session?

We also discussed if IPMI has a service identifier vs a system 
identifier.  IPMI can get the server’s GUID, same as from Redfish.

Discussion will continue in the gerrit review.


> 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