[liberationtech] PrivateCore and secure hosting

[Steve Weis]

Hi Eleanor. I am a co-founder of PrivateCore and happy to answer questions.
I'll keep it non-commercial and focus on the technical answers for this
mailing list:

"[We] were talking about secure hosting"

PrivateCore's technology is currently packaged as a hypervisor, so is
targeted at environments where you control the OS, like co-location or in a
bare metal cloud. If you're talking about a hosting provider where you
bring a virtual machine, then the service provider would need to be
involved. But, unlike today, you would be able to remotely attest that the
service provider cannot see your data while in use.

"PrivateCore came up as a tool that might be interesting when you're
looking at aggressive malware"

PrivateCore protects data in-use from physical threats, which includes
physical boot-integrity vectors. So, while it's not anti-malware, the
threat model includes bootkits and rootkits. We also deal with backdoored
hardware, non-volatile memory, bus analyzers, etc.

"[It isn't] clear how the initial keying is performed"

Keys to encrypt memory are generated entirely within the CPU and stay
resident in cache. These are ephemeral keys, so live and die within the
CPU. The method to generate the random bits will differ on different
processors.

"How do they guarantee a trusted path to the chip during initialization,
and if the former, how do they ensure that the secret is actually secret to
all parties but the initializer?"

The entire boot process is measured and can be remotely attested. There are
no secrets embedded in the software or transmitted to a host; as I said,
they're all generated within the CPU.

...Please let me know if you have more questions.


On Thu, Jun 20, 2013 at 6:50 PM, Eleanor Saitta <ella at dymaxion.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> So, a bunch of us were talking about secure hosting in Tunis.  At one
> point in a side conversation, PrivateCore came up as a tool that might
> be interesting when you're looking at aggressive malware.  It's
> designed to allow you to perform certain kinds of secure computations
> in a context where you can't trust anything off the CPU die, including
> your north bridge or main memory, while still allowing you to use
> commodity x86 hardware.  This is interesting, as CPU packages are
> relatively more expensive to tamper with than complete boards are, and
> represent a smaller (the smallest possible?) target when looking at
> issues like firmware rootkits.  Sadly, their available online
> documentation doesn't make it clear how the initial keying is
> performed; e.g., are they relying on secrets already baked into the
> chip or using some initialization process?  If the latter, how do they
> guarantee a trusted path to the chip during initialization, and if the
> former, how do they ensure that the secret is actually secret to all
> parties but the initializer?  If anyone knows more about them, I'd be
> quite interested to hear it.
>
> (There's a larger issue of their technology not being open source, for
> our context, but that's a separate issue.)
>
> E.
>
> - --
> Ideas are my favorite toys.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iF4EAREIAAYFAlHDsWwACgkQQwkE2RkM0wovOwD+NFxHfUuR5KPfbYpxzTMXVNZX
> jnYSrl2YEHQBzmKUFIEA/1GHlD8jm3Zw13LSJQC0MrlZ0Ev4cpnBT4B59KAm7DVL
> =oQCa
> -----END PGP SIGNATURE-----
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130620/6a73e0ee/attachment.html>