Search Mailing List Archives
[liberationtech] PrivateCore and secure hosting
steveweis at gmail.com
Fri Jun 21 15:49:51 PDT 2013
Hi Eleanor. tl;dr: Today we bootstrap from the TPM.
"To have a secure channel between two processes/compartments (in this case,
the CPU of the hosted machine and the remote,
non-service-provider-controlled system), they must share a secret."
This is a good question since it's not necessarily clear. Let's call the
untrusted host H and a local management system M. We can provide H a
non-secret boot image that contains M's public key. That will be the only
authorized key that can connect to H.
How does M know its talking to a valid H, since it's by definition
Here's were we go into trusted computing land:
The host H will have a trusted platform module (TPM). When H boots up, it
will measure all software state into platform control registers (PCRs) in
the TPM. See Intel Trusted Execution Technology (TXT) for more info how
The TPM will have a public key, which M can verify with a certificate chain
through the TPM manufacturer and a root CA. M can then engage in an
attestation protocol with H to prove that H's TPM knows the corresponding
private key. M will also obtain signed PCR contents, which it can validate.
If M trusts H's TPM, it will believe it is talking to a system which booted
with a specific, unmodified software configuration and will only accept
connections from M's public key. The promise of TXT is that if malware
modifies the boot image, boot parameters, BIOS, SINIT, etc, then different
values will be measured and attestation will fail.
What if the TPM is compromised?
Then an attacker can forge measurements and trick M into talking to a
malicious system. There are some known potential TPM risks, but the bar is
significantly higher than where it is today. Regardless, eliminating the
dependency on a TPM is an active area of research.
Is attestation the end of the story?
No, attestation is necessary but not sufficient. Even if you attest the
system, software state is still vulnerable while in memory and on the bus.
Think DMA, cold boot, NV-DIMMs, bus analyzers, etc. This is why we're fully
encrypting data in the CPU before writing it to main memory.
There's also a risk since the kernel and drivers are written trusting
physical devices in the system. You also need to lock down all the software
interfaces from the CPU to the rest of the physical host.
On Fri, Jun 21, 2013 at 1:32 PM, Eleanor Saitta <ella at dymaxion.org> wrote:
> To have a secure channel between two processes/compartments (in this
> case, the CPU of the hosted machine and the remote,
> non-service-provider-controlled system), they must share a secret.
> Just encrypting local system memory with a key generated on the CPU
> doesn't permit secure communication - e.g., you have no way of getting
> data in and out of the compartment. Doing computation on known inputs
> where trojaned hardware can read both the input data and the code
> isn't useful, because the work can just be done in parallel by your
> adversary. So, to provide useful benefit, I assume you must have a
> method for secret-sharing between processes/compartments. What is it?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the liberationtech