* Re: Security Working Group meeting - Wednesday September 15 - results
2021-09-14 18:48 Security Working Group meeting - Wednesday September 15 Joseph Reynolds
@ 2021-09-15 19:02 ` Joseph Reynolds
0 siblings, 0 replies; 2+ messages in thread
From: Joseph Reynolds @ 2021-09-15 19:02 UTC (permalink / raw)
To: openbmc
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
^ permalink raw reply [flat|nested] 2+ messages in thread