5 ms·

Ext4 encryption

105 points by rubikscube 11y ago

click170 11y ago
> The developers note, though, that if an attacker can make changes to an encrypted filesystem that is subsequently mounted by the user, all bets are off. Did this line stand out to anyone else? I would expect modification of an encrypted directory to cause the loss of any modified files, but I'm surprised at the specific wording of that statement. From that, I'm reading that it could be possible to modify an encrypted directory so as to cause key or plaintext content leakage if the directory is accessed again or the volume is re-mounted. Does Full Disk Encryption have this problem as well (mounting a maliciously modified full disk encrypted filesystem could result in disclosure)?
- TD-Linux 11y ago
  Yes, in all of these cases you can modify the initrd to steal credentials.
  - paulfurtado 11y ago
    That's not totally a given anymore with so many UEFI laptops capable of Secure Boot. They additionally mentioned android as a use case for this which also generally comes with a locked bootloader among other boot chain security features. You can build the kernel as an EFI module (using EFISTUB) and have EFI verify its signature. Most new laptops do support this and an increasing number of desktops and servers do too. In this case, some users may be surprised to find that even though they used ext4's encryption on /, someone can still modify the inode table since it remains unencrypted (though I could be reading the article wrong).
  - nodata 11y ago
    No, you boot from trusted boot media. A usb stick that's always on you, for example.
- paulfurtado 11y ago
  I think a better use case for this might be for the full partition to be encrypted with dm-crypt and then applications or users encrypt their data directories with ext4 directory encryption, though I could be wrong.
- nodata 11y ago
  > So ext4 encryption can protect a lost or stolen device, but protecting a device that has been covertly modified is beyond its threat model. Yeah, this is beyond worrying. If someone edits my disk and I mount it, I want a BIG RED WARNING thanks.
- _wmd 11y ago
  This has been a problem with disk encryption since the dawn of time: there is no (at least AFAIK) scheme that allows efficiently hosting the MAC for an encrypted block in a way that meets various efficiency and robustness requirements. Emulating an unencrypted disk means allowing updates at (traditionally) 512-byte sector granularity. Assuming we store a SHA256 MAC for the sector's ciphertext, for a 1TiB drive that means storing 64GiB of hashes. In order to preserve alignment (required by various layers of the hardware and software stack), it's not possible to locate these hashes inline with the sectors they represent. In traditional media that meant adding an extra seek to every read or flush, or in other words at least halving the throughput of your drive. This situation doesn't magically disappear with SSDs, the same performance problem just exhibits in a different way. There's a bunch of other reasons full disk encryption isn't authenticated, but the above is a good starting point edit: I have no idea how hardware disk encryption (e.g. TCG OPAL) functions, I guess it's at least vendor-dependent, but at least there is a possibility within traditional spinning rust drives to interleave authentication data more efficiently. In any case at that point, the attacker would need to physically disassemble the drive in order to perform an attack, so OPAL is probably a step up from plain software encryption if you're paranoid enough, yet somehow still trust your drive firmware
  - qrmn 11y ago
    But this isn't disk encryption! Filesystems have metadata: which is where a MAC can go, next to the filename. There's just no way this should be unauthenticated XTS, this is simply the wrong mode to use, you should use an AEAD. ChaCha20_Poly1305 - RFC7539: https://datatracker.ietf.org/doc/rfc7539/ https://datatracker.ietf.org/doc/rfc7539/ - makes much more sense. Faster, too, on the target mobile devices which have poor crypt performance. I don't think this should be merged early or as-is. Unauthenticated encryption is against good advice and a bad idea. Standardising that is an even worse idea. Edit: I do see that they're intending this as a minimum viable patch for Android 'M' and they intend to add GCM support later (again, I'd point to CC20 as a newer, better alternative), they're just waiting on a transactional update first. I do question whether shipping it broadly with this design as-is should happen in the vanilla kernel, however: Android uses its own patches anyway. Maybe let this one mature a bit first before merging upstream?
- caf 11y ago
  It might be an oblique reference to the fact that the filesystem code hasn't been specifically hardened with respect to a maliciously-crafted filesystem image. Traditionally this was not seen as an attack vector, because only root could mount filesystems anyway (and without filesystem encryption, someone who could modify your filesystem image could just modify any binary to add a backdoor). This is why only specifically whitelisted filesystem types can be mounted in unprivileged containers.
- kentonv 11y ago
  _wmd explains pretty well why FDE with authentication is technically challenging. To be clear, the reason unauthenticated encryption is considered reasonable here is because the threat model is: Someone steals your laptop, you don't expect you'll ever get it back, but you don't want them to be able to extract any data. On the other hand, if your threat model were "Someone secretly grabs your laptop when you're not looking, pulls out the hard drive, flips some bits, then puts it back, without you ever noticing.", then FDE can't protect you. For a laptop or phone, the latter case seems reasonably implausible and so FDE is worthwhile. OTOH, for cloud storage use cases where you don't necessarily trust the storage machines, FDE as-is is basically worthless.
  - deleted 11y ago
    [deleted]
wfunction 11y ago
Could someone please give or link to a comparison of Ext4 encryption and NTFS encryption?
pmontra 11y ago
A related question: what's the best practice to encrypt the FS of a server and allow unattended reboots? One doesn't want to have to type in a password at each reboot (no unattended reboots and impractical for large number of servers) but the password can't be left attached to the server. So how is it done, if it is done? Thanks.
- cynix 11y ago
  Doesn't this defeat the purpose of encryption? If someone steals your server, they can just reboot it and get access to everything.
  - pmontra 11y ago
    Exactly, that's why the password shouldn't be on the server, but having to type it in every time is inconvenient. Nothing I've been able to think about is secure so I was asking. I also understand that any attacker gaining access to the server while it's running (the usual scenario) gets access to the unencrypted file system so maybe it doesn't make much sense to encrypt servers. Still I'm curious.
    - teddyh 11y ago
      > Exactly, that's why the password shouldn't be on the server, but having to type it in every time is inconvenient. Nothing I've been able to think about is secure That’s what I said to a friend of mine when we had numerous servers with encrypted disks and frequent power outages requiring us to type in passwords. He then suggested many different schemes to fix this, each of which I shot down as being insecure. Then he came up with something which I couldn’t shoot down, and he made a first proof-of-concept implementation, which is how Mandos¹ got started. This was many years ago; Mandos has since become available in Debian and Ubuntu; just do "apt-get install mandos". ① https://www.recompile.se/mandos https://www.recompile.se/mandos
  - deleted 11y ago
    [deleted]
- 11y ago
kijin 11y ago
According to the comments, the primary benefits of filesystem-level encryption over full-disk (block-level) encryption are claimed to be: 1) The filesystem can be configured to expose different parts of the tree to different users, whereas FDE is all-or-nothing. 2) The filesystem can make room for more metadata than a block device, so it would be easier to implement authenticated encryption. 3) More fine-tuned control over caching. But are these really significant advantages? 1) Most devices nowadays, including Chromesbooks and Android phones, are only ever used by one person. 2) We could modify dm-crypt to set aside a certain amount of space for MAC, and just expose a smaller block device to the next layer. Besides, the proposed changes to ext4 don't use authenticated encryption, either. 3) Can't this be addressed at a lower level?
- caf 11y ago
  For point 2, you can't just expose a smaller block to the next layer - everything is designed to work with 512-byte logical blocks. You could possibly do it if you were willing to sacrifice half your disk space by pairing every 512-byte data block with a 512-byte authenticator block, but... ...the other issue is that you need a way to atomically update the data block and authenticator together. This is a similar problem to the "RAID write hole", and doing this at the block layer requires even more overhead - something equivalent to RAID write intent bitmaps. The filesystem, on the other hand, already tends to have a journal, log-structure or COW rules that allows some form of atomic transactional updates. The encryption authenticator can piggy-back on this.
  - Dylan16807 11y ago
    Well if you use atomic 4K writes to the drive, and expose each one as 7 512-byte blocks to the next layer...
    - kijin 11y ago
      That's exactly what I was thinking. SSDs have fairly large page sizes and erase block sizes, so you're often reading and writing a lot more than necessary, anyway. A clever implementation might be able to take advantage of that to scatter the MAC throughout the drive without too much impact on performance or longevity.
angelortega 11y ago
Don't miss the comments in the linked page for more insightful information.
caf 11y ago
I'm not sure how this is supposed to work in the mobile device (Android / Chrome OS) scenario. These devices are typically on (but suspended) when they're lost. If this means the master key is still in memory, then the attacker has it. If, on the other hand, the master key is wiped when the device suspends and is reloaded when you unlock the device, how does your SMS application write your messages (that come in while the device is suspended) to disk? How does the phone lookup your contacts to display the incoming caller name if the device was suspended when the call came in?
- aenum 11y ago
  If the device is locked and does not allow ADB or MTP, 99% of perpetrators would not be able to access its data.
- pwnna 11y ago
  You can wipe the master key when you suspend. However it will just mean that there needs to be some unencrypted storage to write down things like incoming text messages. Caller ID will also not work (or be stored in the unencrypted storage). There are ways to do it, but you will lose security/convenience. It all depend on your threat model and how inconvenient you're willing to make your phone.
  - caf 11y ago
    If your text messages and contacts have to be stored in unencrypted storage, then what exactly are we protecting here - your 2048 high score?
edwintorok 11y ago
I noticed that ecryptfs + ext4 doesn't support sparse files efficiently (it takes a long time to write to a large sparse file, as if it actually writes/encrypts all the zeroes). Having encryption directly in ext4 should solve that, but I haven't tested the patchset yet.
throwaway12357 11y ago
For those who missed it there is a relevant comment by user abatters against the use of per-directory encryption: https://lwn.net/Articles/639766/ https://lwn.net/Articles/639766/ edit: how can I quote a block of text that preserves newlines?

105 points by rubikscube 11y ago

> The developers note, though, that if an attacker can make changes to an encrypted filesystem that is subsequently mounted by the user, all bets are off. Did this line stand out to anyone else? I would expect modification of an encrypted directory to cause the loss of any modified files, but I'm surprised at the specific wording of that statement. From that, I'm reading that it could be possible to modify an encrypted directory so as to cause key or plaintext content leakage if the directory is accessed again or the volume is re-mounted. Does Full Disk Encryption have this problem as well (mounting a maliciously modified full disk encrypted filesystem could result in disclosure)?

TD-Linux 11y ago
Yes, in all of these cases you can modify the initrd to steal credentials.
- paulfurtado 11y ago
  That's not totally a given anymore with so many UEFI laptops capable of Secure Boot. They additionally mentioned android as a use case for this which also generally comes with a locked bootloader among other boot chain security features. You can build the kernel as an EFI module (using EFISTUB) and have EFI verify its signature. Most new laptops do support this and an increasing number of desktops and servers do too. In this case, some users may be surprised to find that even though they used ext4's encryption on /, someone can still modify the inode table since it remains unencrypted (though I could be reading the article wrong).
- nodata 11y ago
  No, you boot from trusted boot media. A usb stick that's always on you, for example.
paulfurtado 11y ago
I think a better use case for this might be for the full partition to be encrypted with dm-crypt and then applications or users encrypt their data directories with ext4 directory encryption, though I could be wrong.
nodata 11y ago
> So ext4 encryption can protect a lost or stolen device, but protecting a device that has been covertly modified is beyond its threat model. Yeah, this is beyond worrying. If someone edits my disk and I mount it, I want a BIG RED WARNING thanks.
_wmd 11y ago
This has been a problem with disk encryption since the dawn of time: there is no (at least AFAIK) scheme that allows efficiently hosting the MAC for an encrypted block in a way that meets various efficiency and robustness requirements. Emulating an unencrypted disk means allowing updates at (traditionally) 512-byte sector granularity. Assuming we store a SHA256 MAC for the sector's ciphertext, for a 1TiB drive that means storing 64GiB of hashes. In order to preserve alignment (required by various layers of the hardware and software stack), it's not possible to locate these hashes inline with the sectors they represent. In traditional media that meant adding an extra seek to every read or flush, or in other words at least halving the throughput of your drive. This situation doesn't magically disappear with SSDs, the same performance problem just exhibits in a different way. There's a bunch of other reasons full disk encryption isn't authenticated, but the above is a good starting point edit: I have no idea how hardware disk encryption (e.g. TCG OPAL) functions, I guess it's at least vendor-dependent, but at least there is a possibility within traditional spinning rust drives to interleave authentication data more efficiently. In any case at that point, the attacker would need to physically disassemble the drive in order to perform an attack, so OPAL is probably a step up from plain software encryption if you're paranoid enough, yet somehow still trust your drive firmware
- qrmn 11y ago
  But this isn't disk encryption! Filesystems have metadata: which is where a MAC can go, next to the filename. There's just no way this should be unauthenticated XTS, this is simply the wrong mode to use, you should use an AEAD. ChaCha20_Poly1305 - RFC7539: https://datatracker.ietf.org/doc/rfc7539/ https://datatracker.ietf.org/doc/rfc7539/ - makes much more sense. Faster, too, on the target mobile devices which have poor crypt performance. I don't think this should be merged early or as-is. Unauthenticated encryption is against good advice and a bad idea. Standardising that is an even worse idea. Edit: I do see that they're intending this as a minimum viable patch for Android 'M' and they intend to add GCM support later (again, I'd point to CC20 as a newer, better alternative), they're just waiting on a transactional update first. I do question whether shipping it broadly with this design as-is should happen in the vanilla kernel, however: Android uses its own patches anyway. Maybe let this one mature a bit first before merging upstream?
caf 11y ago
It might be an oblique reference to the fact that the filesystem code hasn't been specifically hardened with respect to a maliciously-crafted filesystem image. Traditionally this was not seen as an attack vector, because only root could mount filesystems anyway (and without filesystem encryption, someone who could modify your filesystem image could just modify any binary to add a backdoor). This is why only specifically whitelisted filesystem types can be mounted in unprivileged containers.
kentonv 11y ago
_wmd explains pretty well why FDE with authentication is technically challenging. To be clear, the reason unauthenticated encryption is considered reasonable here is because the threat model is: Someone steals your laptop, you don't expect you'll ever get it back, but you don't want them to be able to extract any data. On the other hand, if your threat model were "Someone secretly grabs your laptop when you're not looking, pulls out the hard drive, flips some bits, then puts it back, without you ever noticing.", then FDE can't protect you. For a laptop or phone, the latter case seems reasonably implausible and so FDE is worthwhile. OTOH, for cloud storage use cases where you don't necessarily trust the storage machines, FDE as-is is basically worthless.
- deleted 11y ago
  [deleted]

wfunction 11y ago

Could someone please give or link to a comparison of Ext4 encryption and NTFS encryption?

pmontra 11y ago

A related question: what's the best practice to encrypt the FS of a server and allow unattended reboots? One doesn't want to have to type in a password at each reboot (no unattended reboots and impractical for large number of servers) but the password can't be left attached to the server. So how is it done, if it is done? Thanks.

cynix 11y ago
Doesn't this defeat the purpose of encryption? If someone steals your server, they can just reboot it and get access to everything.
- pmontra 11y ago
  Exactly, that's why the password shouldn't be on the server, but having to type it in every time is inconvenient. Nothing I've been able to think about is secure so I was asking. I also understand that any attacker gaining access to the server while it's running (the usual scenario) gets access to the unencrypted file system so maybe it doesn't make much sense to encrypt servers. Still I'm curious.
  - teddyh 11y ago
    > Exactly, that's why the password shouldn't be on the server, but having to type it in every time is inconvenient. Nothing I've been able to think about is secure That’s what I said to a friend of mine when we had numerous servers with encrypted disks and frequent power outages requiring us to type in passwords. He then suggested many different schemes to fix this, each of which I shot down as being insecure. Then he came up with something which I couldn’t shoot down, and he made a first proof-of-concept implementation, which is how Mandos¹ got started. This was many years ago; Mandos has since become available in Debian and Ubuntu; just do "apt-get install mandos". ① https://www.recompile.se/mandos https://www.recompile.se/mandos
- deleted 11y ago
  [deleted]
11y ago

kijin 11y ago

According to the comments, the primary benefits of filesystem-level encryption over full-disk (block-level) encryption are claimed to be: 1) The filesystem can be configured to expose different parts of the tree to different users, whereas FDE is all-or-nothing. 2) The filesystem can make room for more metadata than a block device, so it would be easier to implement authenticated encryption. 3) More fine-tuned control over caching. But are these really significant advantages? 1) Most devices nowadays, including Chromesbooks and Android phones, are only ever used by one person. 2) We could modify dm-crypt to set aside a certain amount of space for MAC, and just expose a smaller block device to the next layer. Besides, the proposed changes to ext4 don't use authenticated encryption, either. 3) Can't this be addressed at a lower level?

caf 11y ago
For point 2, you can't just expose a smaller block to the next layer - everything is designed to work with 512-byte logical blocks. You could possibly do it if you were willing to sacrifice half your disk space by pairing every 512-byte data block with a 512-byte authenticator block, but... ...the other issue is that you need a way to atomically update the data block and authenticator together. This is a similar problem to the "RAID write hole", and doing this at the block layer requires even more overhead - something equivalent to RAID write intent bitmaps. The filesystem, on the other hand, already tends to have a journal, log-structure or COW rules that allows some form of atomic transactional updates. The encryption authenticator can piggy-back on this.
- Dylan16807 11y ago
  Well if you use atomic 4K writes to the drive, and expose each one as 7 512-byte blocks to the next layer...
  - kijin 11y ago
    That's exactly what I was thinking. SSDs have fairly large page sizes and erase block sizes, so you're often reading and writing a lot more than necessary, anyway. A clever implementation might be able to take advantage of that to scatter the MAC throughout the drive without too much impact on performance or longevity.

angelortega 11y ago

Don't miss the comments in the linked page for more insightful information.

caf 11y ago

I'm not sure how this is supposed to work in the mobile device (Android / Chrome OS) scenario. These devices are typically on (but suspended) when they're lost. If this means the master key is still in memory, then the attacker has it. If, on the other hand, the master key is wiped when the device suspends and is reloaded when you unlock the device, how does your SMS application write your messages (that come in while the device is suspended) to disk? How does the phone lookup your contacts to display the incoming caller name if the device was suspended when the call came in?

aenum 11y ago
If the device is locked and does not allow ADB or MTP, 99% of perpetrators would not be able to access its data.
pwnna 11y ago
You can wipe the master key when you suspend. However it will just mean that there needs to be some unencrypted storage to write down things like incoming text messages. Caller ID will also not work (or be stored in the unencrypted storage). There are ways to do it, but you will lose security/convenience. It all depend on your threat model and how inconvenient you're willing to make your phone.
- caf 11y ago
  If your text messages and contacts have to be stored in unencrypted storage, then what exactly are we protecting here - your 2048 high score?

edwintorok 11y ago

I noticed that ecryptfs + ext4 doesn't support sparse files efficiently (it takes a long time to write to a large sparse file, as if it actually writes/encrypts all the zeroes). Having encryption directly in ext4 should solve that, but I haven't tested the patchset yet.

throwaway12357 11y ago

For those who missed it there is a relevant comment by user abatters against the use of per-directory encryption: https://lwn.net/Articles/639766/ https://lwn.net/Articles/639766/ edit: how can I quote a block of text that preserves newlines?