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 <[email protected]> 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 [email protected] or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech >
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
