TRESOR Runs Encryption Securely Outside RAM

Re:TRESOR Runs Encryption Securely Outside RAM by codex on Friday September 27, 2013 @11:41AM (#6457538)

Why not keep the keys in a TPM and pull them into "real" registers whenever the kernel context switches into a specially flagged AES decode thread, and zero them when context switching away?

[ Parent | on HN ]

Re:TRESOR Runs Encryption Securely Outside RAM by EthanHeilman on Friday September 27, 2013 @12:35PM (#6457837)

Here is an NSA slide where the NSA talks about exploiting Trusted Computing Platforms for intelligence[1].

The German government believes that the TPM is backdoored and a danger to security[2].

1: http://www.nytimes.com/interactive/2013/09/05/us/documents-r...

2: http://www.techweekeurope.co.uk/news/microsoft-seeks-calm-on...

[ Parent | on HN ]

Re:TRESOR Runs Encryption Securely Outside RAM by codex on Friday September 27, 2013 @02:37PM (#6458694)

If you can't trust the TPM, can you trust Intel's debug registers to be secure?

Long term I suspect that this kind of thing will use Intel's Software Guard Extensions (SGX), which creates a trusted enclave of code and data that not even the kernel nor the hypervisor can access.

[ Parent | on HN ]

Re:TRESOR Runs Encryption Securely Outside RAM by andyjohnson0 on Friday September 27, 2013 @02:57PM (#6458815)

A couple of interesting articles on SGX:

http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-on...

http://theinvisiblethings.blogspot.co.uk/2013/09/thoughts-on...

[ Parent | on HN ]

Re:TRESOR Runs Encryption Securely Outside RAM by codex on Friday September 27, 2013 @04:51PM (#6459487)

The second article is quite alarming. Don't run any code in an enclave which you didn't compile yourself! One may not even be able to use a virtual machine to peer inside an enclave by emulating SGX: the software could demand a valid public key stored uniquely in every Intel chip and signed by Intel's private key, which a hypervisor would not have.

[ Parent | on HN ]