4 ms·

> you should have an external password necessary to unlock the drive; not a TPM. i thought the whole point of hardware oracles like TPMs was to avoid loading a

> you should have an external password necessary to unlock the drive; not a TPM. i thought the whole point of hardware oracles like TPMs was to avoid loading a PSK into RAM, making removable RAM sticks simple non-destructive attack vectors.

dathinab 5y ago
It's complicated. I.e. it's not uncommon for you password to be used to decrypt an encryption key which then lives in RAM and is used to decrypt data. So as long as you "just" have a TPM then it's not preventing that attack wrt. full disk encryption. For it to do so you need either a secure module on you hard-drive (and trust that module) or need to pipe all disk I/O through the TPM (and hope it's fast enough). Through there are (should be?) some hybrid models. Anyway you can combine both a TPM and a external password (in different ways depending on how the encryption is done). One additional common reason against using a TPM for full disk encryption is if you want to make data recoverable even if you TPM (motherboard/cpu) fires itself. I would say for most companies the benefits of requiring a password (or better HSK + PIN) for boot instead of only a TPM are outweighing the risk of a RAM removal attacks. Especially if combined with intrusion detection and short times between suspend and full (non hybrid) hibernation.
- azalemeth 5y ago
  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).
mjg59 5y ago
TPMs aren't fast enough to do disk encryption at anywhere near the speed of modern storage, so a TPM-based FDE key is simply something that the TPM decrypts and hands back to the OS.
- buildbot 5y ago
  You'd have to build something like the Apple T2 chip.

dathinab 5y ago

It's complicated. I.e. it's not uncommon for you password to be used to decrypt an encryption key which then lives in RAM and is used to decrypt data. So as long as you "just" have a TPM then it's not preventing that attack wrt. full disk encryption. For it to do so you need either a secure module on you hard-drive (and trust that module) or need to pipe all disk I/O through the TPM (and hope it's fast enough). Through there are (should be?) some hybrid models. Anyway you can combine both a TPM and a external password (in different ways depending on how the encryption is done). One additional common reason against using a TPM for full disk encryption is if you want to make data recoverable even if you TPM (motherboard/cpu) fires itself. I would say for most companies the benefits of requiring a password (or better HSK + PIN) for boot instead of only a TPM are outweighing the risk of a RAM removal attacks. Especially if combined with intrusion detection and short times between suspend and full (non hybrid) hibernation.

azalemeth 5y ago
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).

mjg59 5y ago

TPMs aren't fast enough to do disk encryption at anywhere near the speed of modern storage, so a TPM-based FDE key is simply something that the TPM decrypts and hands back to the OS.

buildbot 5y ago
You'd have to build something like the Apple T2 chip.