3 ms·

Out of curiosity and to ameliorate my ignorance -- does LUKS on Linux keep the keys in the processor's SME all the time? How easy is it to just encrypt everythi

Out of curiosity and to ameliorate my ignorance -- does LUKS on Linux keep the keys in the processor's SME all the time? How easy is it to just encrypt everything in ram?

dathinab 5y ago
> How easy is it to just encrypt everything in ram? It's a feature of modern server CPUs which have a AES-128 encryption engine directly embedded in the memory controller (and combine that feature with virtualization, i.e. different encryption keys for different VM). > does LUKS on Linux keep the keys in the processor's SME all the time? The LUKS mater key is kept in the Linux Kernel Keyring and while I'm 90% sure that at least when accessing a encrypted partition it's in RAM. I also would guess that the large majority (all?) of on-the-fly disk encryption software suites/libraries have this problem. The only way not to have this problems would be to pipe all disk (data) I/O through a fast encryption engine connected to the TPM. And as far as I know this is not part of the TPM feature set(1) (the fast, high throughput part). But then DRM has kinda similar requirements, so maybe I'm wrong. Through IMHO most companies and people in most situations don't have to worry about RAM extraction attacks as they are way to complicated and brittle, especially if combined with e.g. case intrusion detection and suspend-to-disk automatically after some time. Through as far as I remember it played a role in some "police extracts chats from locked iPhone" cases. (1): TPM is besides some features around attestation and early boot mainly a from of Hardware Key Store, so e.g. if you use it to sign a blob you don't pipe the blob through the TPM but you (cryptographically secure) hash the blob and then only sign the few bytes long hash by passing it through the TPM. Similar encryption is normally done by doing a AES encryption of a blob and then encrypt the few bytes long AES key using the TPM. But again, I'm not a expert in that area and thinks might have changed, but I guess they haven't (I would be surprised).

Out of curiosity and to ameliorate my ignorance -- does LUKS on Linux keep the keys in the processor's SME all the time? How easy is it to just encrypt everything in ram?

dathinab 5y ago

> How easy is it to just encrypt everything in ram? It's a feature of modern server CPUs which have a AES-128 encryption engine directly embedded in the memory controller (and combine that feature with virtualization, i.e. different encryption keys for different VM). > does LUKS on Linux keep the keys in the processor's SME all the time? The LUKS mater key is kept in the Linux Kernel Keyring and while I'm 90% sure that at least when accessing a encrypted partition it's in RAM. I also would guess that the large majority (all?) of on-the-fly disk encryption software suites/libraries have this problem. The only way not to have this problems would be to pipe all disk (data) I/O through a fast encryption engine connected to the TPM. And as far as I know this is not part of the TPM feature set(1) (the fast, high throughput part). But then DRM has kinda similar requirements, so maybe I'm wrong. Through IMHO most companies and people in most situations don't have to worry about RAM extraction attacks as they are way to complicated and brittle, especially if combined with e.g. case intrusion detection and suspend-to-disk automatically after some time. Through as far as I remember it played a role in some "police extracts chats from locked iPhone" cases. (1): TPM is besides some features around attestation and early boot mainly a from of Hardware Key Store, so e.g. if you use it to sign a blob you don't pipe the blob through the TPM but you (cryptographically secure) hash the blob and then only sign the few bytes long hash by passing it through the TPM. Similar encryption is normally done by doing a AES encryption of a blob and then encrypt the few bytes long AES key using the TPM. But again, I'm not a expert in that area and thinks might have changed, but I guess they haven't (I would be surprised).