So why can't we authenticate all the sectors? Is the performance really that bad, even with AES-NI and such? Chrome OS and Android devices that use dm-verity already do this (albeit for read only), so that's hard to believe...
With SSDs, seek time shouldn't be an issue. You can argue that if an attacker can modify your disk, they can probably run code to steal your password, but this does not apply to Dropbox-stored disk images, and AFAIK you can try to secure a PC against modified code seeing the keys using TXT.
* If you're working with 512 byte sectors, the cost of individual MAC tags gets high.
* No matter what your sector size, reserving space for the MAC tag gets you odd-sized sectors.
* Most importantly, what does it mean to have a sector with a bad MAC? How does that get reported back to the filesystem? Filesystems aren't designed to cooperate with the disk to track cryptographic attacks.
By the time you solve that last problem, you've already gotten yourself pretty far down the track of just providing crypto in the filesystem layer. Which, because the filesystem layer is format-aware, you might as well just keep going and make a proper cryptographic filesystem.
Is there anything wrong with reporting a sector with a bad MAC as an unrecoverable read error, just as the hardware would do if the CRC failed?
Reserving the space is the real killer - either you end up with non-512-byte sectors (and what is more problematic, sectors that don't divide the system memory page size) or you stash the MACs elsewhere in which case every write to a sector also requires a read-modify-write of the sector that holds the MAC.
Does an "unrecoverable read error" mean that the file is read with a big zeroed out chunk (and an error somewhere)? Does it mean that the whole file becomes unreadable? Can the user recover any part of the file? How do they know what to do? Do all filesystems handle those read errors the same way?
It's clearly not impossible to get the level of cooperation between the fileystem and the encrypted device that you need, but that's effort, and it's effort perhaps better spent on simply encrypting at the filesystem layer.
I think you're right though that the alignment issue is dispositive.
Speaking in terms of UNIX-style operating systems...
No serious filesystem will return a zeroed out chunk. Apart from that, it obviously depends on where the read error hit - it might cause just one block in the file to return EIO from read(); it might cause a large part of a file to return EIO from read(); it might make the entire file inaccessible (EIO from open()); it might make entire parts of the directory tree inaccessible (EIO from open() or readdir()) or it might make the entire filesystem fail to mount.
Files that are mmap()ed rather than read() will SIGBUS the process on an IO error - this includes executables and libraries.
I think I see what you're driving at, though - application code isn't designed with the idea that EIO might be maliciously-induced, so you could do things like induce a database to rollback to an earlier point in time by corrupting its journal, or make a badly-designed firewall fail-open when its configuration files fail to load?
I'm not sure it's solved by encrypting at the filesystem layer either, though - the problem is that the smarts need to move all the way up to the applications themselves. That's likely impossible, so your next best option is to just hard-fail the entire system on a MAC failure, which is just as easy for dm-crypt to do as ZFS, for example.
Arguably, you should have enough redundancy at a lower level (either through RAID or similar or trusting Dropbox to do it) that unrecoverable read errors should never happen, so it's worth halting the entire system with a big warning to the user if it does.
My problem with just encrypting at the filesystem level is that it doesn't address files like databases that are large and frequently partially updated, i.e. they act like filesystems in their own right. edit: oh, and as mentioned elsewhere, handing untrusted data to filesystem drivers is a pretty big, avoidable risk.
Sure, but there's no reason filesystem encryption has to be sequential. The problem isn't with tweakable ciphers; the problem is with ECB-like tweakable ciphers with no authentication.
The LRW paper has some starting points for tweakable ciphers with random access properties. Note that if you're doing filesystem encryption, you have a place you can put a nonce to do randomization. For that matter, you could divide files up into 4k pages and use OCB for the pages.
I don't think I understand your point about handing filesystem drivers untrusted data.
If you encrypt at a block level then the pre-authentication parsing code is relatively simple. If you encrypt on top of a filesystem, it's more complicated and relatively likely to have vulnerabilities (seen in practice in iOS at least). It may not be that important, but it's a factor.
Sure, but it's also the case that encrypting at the block level means that upper-layer filesystem code needs to be prepared to deal with corrupted metadata, which is stored in encrypted sectors that attackers can randomize.
For the last question, couldn't a sector with a bad MAC get reported the same way that a hardware failure reading the sector would be? (Maybe that would produce misleading error messages to the user?)
Comments
So why can't we authenticate all the sectors? Is the performance really that bad, even with AES-NI and such? Chrome OS and Android devices that use dm-verity already do this (albeit for read only), so that's hard to believe...
With SSDs, seek time shouldn't be an issue. You can argue that if an attacker can modify your disk, they can probably run code to steal your password, but this does not apply to Dropbox-stored disk images, and AFAIK you can try to secure a PC against modified code seeing the keys using TXT.
This is a good question. Here are some reasons:
* If you're working with 512 byte sectors, the cost of individual MAC tags gets high.
* No matter what your sector size, reserving space for the MAC tag gets you odd-sized sectors.
* Most importantly, what does it mean to have a sector with a bad MAC? How does that get reported back to the filesystem? Filesystems aren't designed to cooperate with the disk to track cryptographic attacks.
By the time you solve that last problem, you've already gotten yourself pretty far down the track of just providing crypto in the filesystem layer. Which, because the filesystem layer is format-aware, you might as well just keep going and make a proper cryptographic filesystem.
Is there anything wrong with reporting a sector with a bad MAC as an unrecoverable read error, just as the hardware would do if the CRC failed?
Reserving the space is the real killer - either you end up with non-512-byte sectors (and what is more problematic, sectors that don't divide the system memory page size) or you stash the MACs elsewhere in which case every write to a sector also requires a read-modify-write of the sector that holds the MAC.
Does an "unrecoverable read error" mean that the file is read with a big zeroed out chunk (and an error somewhere)? Does it mean that the whole file becomes unreadable? Can the user recover any part of the file? How do they know what to do? Do all filesystems handle those read errors the same way?
It's clearly not impossible to get the level of cooperation between the fileystem and the encrypted device that you need, but that's effort, and it's effort perhaps better spent on simply encrypting at the filesystem layer.
I think you're right though that the alignment issue is dispositive.
Speaking in terms of UNIX-style operating systems...
No serious filesystem will return a zeroed out chunk. Apart from that, it obviously depends on where the read error hit - it might cause just one block in the file to return EIO from read(); it might cause a large part of a file to return EIO from read(); it might make the entire file inaccessible (EIO from open()); it might make entire parts of the directory tree inaccessible (EIO from open() or readdir()) or it might make the entire filesystem fail to mount.
Files that are mmap()ed rather than read() will SIGBUS the process on an IO error - this includes executables and libraries.
I think I see what you're driving at, though - application code isn't designed with the idea that EIO might be maliciously-induced, so you could do things like induce a database to rollback to an earlier point in time by corrupting its journal, or make a badly-designed firewall fail-open when its configuration files fail to load?
Yep. If your cryptosystem is designed properly, none of that should be possible.
I'm not sure it's solved by encrypting at the filesystem layer either, though - the problem is that the smarts need to move all the way up to the applications themselves. That's likely impossible, so your next best option is to just hard-fail the entire system on a MAC failure, which is just as easy for dm-crypt to do as ZFS, for example.
Arguably, you should have enough redundancy at a lower level (either through RAID or similar or trusting Dropbox to do it) that unrecoverable read errors should never happen, so it's worth halting the entire system with a big warning to the user if it does.
My problem with just encrypting at the filesystem level is that it doesn't address files like databases that are large and frequently partially updated, i.e. they act like filesystems in their own right. edit: oh, and as mentioned elsewhere, handing untrusted data to filesystem drivers is a pretty big, avoidable risk.
Sure, but there's no reason filesystem encryption has to be sequential. The problem isn't with tweakable ciphers; the problem is with ECB-like tweakable ciphers with no authentication.
The LRW paper has some starting points for tweakable ciphers with random access properties. Note that if you're doing filesystem encryption, you have a place you can put a nonce to do randomization. For that matter, you could divide files up into 4k pages and use OCB for the pages.
I don't think I understand your point about handing filesystem drivers untrusted data.
If you encrypt at a block level then the pre-authentication parsing code is relatively simple. If you encrypt on top of a filesystem, it's more complicated and relatively likely to have vulnerabilities (seen in practice in iOS at least). It may not be that important, but it's a factor.
Sure, but it's also the case that encrypting at the block level means that upper-layer filesystem code needs to be prepared to deal with corrupted metadata, which is stored in encrypted sectors that attackers can randomize.
For the last question, couldn't a sector with a bad MAC get reported the same way that a hardware failure reading the sector would be? (Maybe that would produce misleading error messages to the user?)