Security Working Group meeting - Wednesday August 31 - results

[George Almasi]

First off, apologies if I am messing up the mailing list threading. I'm 
going to attempt to address
questions raised by Patrick about keylime and openbmc in the last few days.

> Is the suggestion that they rewrite it in C++ and contribute that?  If 
> it is, why would they invest in building a project and community from 
> scratch as opposed to using an existing one just because all the other 
> in-tree servers are hyper-cost optimized?

No. To repeat what Thore Somers mentioned: the Red Hat team has done
a good job of porting the keylime *agent* to Rust.

We will never attempt to cram Python into OpenBMC :)

The rust agent compiles and runs on the generic ARM version of OpenBMC;
we have tested this, and Angelo Ruocco is working on a recipe. We are
having difficulties with the AST2600 in particular, but that seems to
be more of a Rust/ARM compilation issue than anything else. We are having
zero troubles on a generic armv7 qemu emulator.

In reply to Michael Richardson -- the _entire_ keylime project is not being
rewritten in rust; only the agent is. The verifiers and registrars and whatnot
have no reason to exist on embedded systems, and there is no reason to make
small footprint versions of them.


> This is very concerning to me.  There is no authentication?

> Blindly advertising to the world which versions of firmware you are
> running so an attacker knows exactly which vulnerabilities you are
> likely to have doesn't sound appealing.


Valid concern. Agreed on not advertising firmware (or kernel) (or anything)
versions to anyone who has no business knowing these things. Fortunately
the keylime developers have considered these issues and over time have
come up with a fairly safe architecture for establishing mutual trust between
agents and other keylime components (like registrars and verifiers). The
security architecture _has_ been peer reviewed and tweaked.

I am not going to attempt to reproduce the entire process here,
but I'll mention salient points of it. First off, the keylime agent will
not blindly talk to just anyone. The agent has to be configured a-priori
with the IP address of a registrar, and it will not attempt to establish
communication with any other entity.

Of course IP addresses can be spoofed, so the keylime agent possesses a certificate
that will authenticate the registrar. The current implementation is an mTLS cert, but a server
side certificate would suffice for this, as the entity being authenticated is the registrar,
not the OpenBMC agent.

Next, of course, the agent has to authenticate itself to the registrar. The TPM device is a crypto engine
with a key pair built into it for the express purpose of identifying itself (the Endorsement Key).
The process of authenticating a TPM device to the registrar is fairly complex and involves a a roundtrip.
In this process other (secondary) keys are created that are henceforth used for regular communication.

I'm going to stop here before this becomes a lecture. From a practical standpoint, getting the keylime
agent into OpenBMC involves getting the agent built in the ecosystem, and inventing a way to
configure the system. Since attestation with keylime can be done at _any point_ in the lifecycle
of an OpenBMC deployment, it is sufficient for us to configure the keylime agent with redfish; and that is
our plan. Details to follow.