4 ms·

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 the

by codex 13y ago

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?

EthanHeilman 13y ago
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-reveal-nsa-campaign-against-encryption.html?_r=0 http://www.nytimes.com/interactive/2013/09/05/us/documents-r... 2: http://www.techweekeurope.co.uk/news/microsoft-seeks-calm-on-german-security-panic-over-windows-8-125702 http://www.techweekeurope.co.uk/news/microsoft-seeks-calm-on...
- codex 13y ago
  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.
  - andyjohnson0 13y ago
    A couple of interesting articles on SGX: http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-on-intels-upcoming-software.html http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-on... http://theinvisiblethings.blogspot.co.uk/2013/09/thoughts-on-intels-upcoming-software.html http://theinvisiblethings.blogspot.co.uk/2013/09/thoughts-on...
    - codex 13y ago
      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.

4 ms·

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 the

by codex 13y ago

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?

EthanHeilman 13y ago
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-reveal-nsa-campaign-against-encryption.html?_r=0 http://www.nytimes.com/interactive/2013/09/05/us/documents-r... 2: http://www.techweekeurope.co.uk/news/microsoft-seeks-calm-on-german-security-panic-over-windows-8-125702 http://www.techweekeurope.co.uk/news/microsoft-seeks-calm-on...
- codex 13y ago
  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.
  - andyjohnson0 13y ago
    A couple of interesting articles on SGX: http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-on-intels-upcoming-software.html http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-on... http://theinvisiblethings.blogspot.co.uk/2013/09/thoughts-on-intels-upcoming-software.html http://theinvisiblethings.blogspot.co.uk/2013/09/thoughts-on...
    - codex 13y ago
      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.