4 ms·

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 s

by caf 13y ago

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.

tptacek 13y ago
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.
- caf 13y ago
  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?
  - tptacek 13y ago
    Yep. If your cryptosystem is designed properly, none of that should be possible.
    - caf 13y ago
      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.
- comex 13y ago
  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.
  - tptacek 13y ago
    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.
    - comex 13y ago
      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.
      - tptacek 13y ago
        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.

by caf 13y ago

tptacek 13y ago

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.

caf 13y ago
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?
- tptacek 13y ago
  Yep. If your cryptosystem is designed properly, none of that should be possible.
  - caf 13y ago
    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.
comex 13y ago
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.
- tptacek 13y ago
  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.
  - comex 13y ago
    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.
    - tptacek 13y ago
      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.