My company is working on the problem of how to compute on untrusted platforms. We gave a technical talk earlier in the year about privilege escalation through physical attacks: http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.pdf
>From a practical perspective on x86 platforms, we can deal with compromised boot integrity, malicious PCI devices, or non-volatile memory, but still need to rely on a trusted CPU and TPM. There are potential issues with the LPC bus and QPI. JTAG is an open question on some platforms. Side channel attacks and fault injection are also an open issue in general. I think the high-value target in the ecosystem are microcode update signing keys. There was some interesting fault injection research into Intel's microcode updates recently: http://inertiawar.com/microcode/ >From a theoretical crypto perspective, there are protocols to safely compute on malicious parties, although you'd still need some trusted party to receive the results. Fully homomorphic encryption is an example that could "efficiently" implement some secure computation protocols. Efficient here means a trillion times slowdown -- although that has been reduced a couple orders of magnitude in the last few years. These crypto approaches also require redesigning or recompiling most applications. So, to answer your question: Today we need to trust at least the CPU. Organizations that care about this tightly control their supply chain or build their own hardware. Here are some general links to physical attack references that my company posted: Physical memory attacks: http://privatecore.com/resources-overview/physical-memory-attacks/ Trusted execution and server attestation: http://privatecore.com/resources-overview/server-attestation/ On Sat, Jun 15, 2013 at 3:19 PM, Anthony Papillion <[email protected]> wrote: > So we know the NSA is spying on the word. We know pretty much how they > do it and we know that at least part of that spying and data collection > is likely done by exploiting holes in software. We can fix that. We can > move people to better software, not rely on software from companies who > routinely turn over data, push open software, etc. > > But how do we handle hardware attacks? For example, what happens when a > chip maker, say Intel, collaborates with the government to allow access > to users systems from the chip level? How can we defend against this? > -- 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
