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.
Comments
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.