It's state of the art block level encryption, however file system level encryption such as what will be offered by the upcoming APFS is fundamentally better.
In a block level encryption each sector is encrypted below the file system. Doing the naïve thing of encrypting each sector with the encryption key is fundamentally insecure. This is called the EBC mode of operation. There's a nice picture of a penguin on wikipedia encrypted with ECB which demonstrates this:
Secure mode of operations generally try to propagate the result of previously encrypted blocks to the next ones. But this approach is not really suitable for mass storage devices. You cannot re-encrypt all the sectors behind the one you just changed. That's just impractical, since writing to sector #0 amounts to rewrite the entire disk.
So in practice schemes like AES-XTS are used. They work by having some kind of way of "tweaking" the encryption, so that it is different for each block (avoiding the pitfalls of ECB), but in a way which allows random access to sectors (i.e. in a way that is predictable). AES-XTS is a tradeoff for this special use case but it is not as robust as more classical modes of operations which would typically be used in an encrypted filesystem.
If encryption is moved from the block layer to the file layer (on a per-file basis), isn't there a risk of exposing unencrypted metadata such as filenames, file sizes, file modification times etc? Or applications accidentally making temporary (unencrypted) copies of files (perhaps in /tmp)? Or just by accidentally cat > 'ing a sensitive file into the wrong directory, thus accidentally leaving a plaintext copy around on the disk sectors? Am I wrong in thinking block level encryption is a comfortable safety net for preventing infoleaks for lost/stolen devices, since cleartext never hits the disk?
It really depends on the details of what the file system does. It is true that older file systems did not encrypt metadata but that's not the case for newer ones like ZFS or APFS.
The way I understand the scarce documentation about APFS is that all the metadata is encrypted with a disk key. But on top of that the file system encrypts user's files with a separate key.
So just like block level encryption plaintext never hits the disk.
If you've ever used Microsoft Windows Encrypting File System (EFS), you'd know that it's pretty much useless. The file table is not encrypted, exposing valuable details about user activity.
Sure, you can't read the contents of a file, but you sure do know a lot about what someone's been up to, by booting up your own system, while mounting their disk as a read-only slave.
You will see highly informative file names, file sizes, and all dates denoting creation, last access, last change, and owner. In a work environment, this means your boss can see a file like:
A disadvantage of doing whole-level encryption is that you have to decrypt the entire file, even if all you want to do is read a few bytes near the end of the file. Similarly, you would have to re-encrypt most of the file if you wanted to write a few bytes near the start of the file.
For large files, the difference can be huge. That's why APFS supports both; it does block-level encryption by default, and users can choose to additionally encrypt files, at least that's what I make of https://developer.apple.com/library/content/documentation/Fi...:
"Encryption
Security and privacy are fundamental in the design of Apple File System. That's why Apple File System implements strong full-disk encryption, encrypting files and all sensitive metadata.
Which encryption methods are available depends on hardware and operating system support, and can vary for Mac, iPhone, iPad, Apple TV, and Apple Watch.
Apple File System supports the following encryption models for each volume in a container:
- No encryption
- Single-key encryption
- Multi-key encryption with per-file keys for file data and a separate key for sensitive metadata
Multi-key encryption ensures the integrity of user data. Even if someone were to compromise the physical security of the device and gain access to the device key, they still couldn't decrypt the user's files.
Apple File System uses AES-XTS or AES-CBC encryption modes, depending on hardware."
AES-XTS or any other mechanism that uses the location on the disk to seed the IV for encryption is susceptible to penguins over time instead of over space.
AES-CTR can be used instead. AES-CTR generates a pseudo-random sequence of bits which is xored with the data to encrypt. The pseudo random bit sequence is generated by encrypting a counter that is incremented. This allows to encrypt or decrypt any randomly chose segment of data by using the data offset as encrypted counter value.
Is it a realistic threat though? You're not supposed to use your device after it has been compromised. If you don't _know_ your device has been compromised you are totally fucked anyway.
What if you're using a hosting provider and using full-disk encryption to stop the hosting provider from having access to your data by yanking the drives?
In a block level encryption each sector is encrypted below the file system. Doing the naïve thing of encrypting each sector with the encryption key is fundamentally insecure. This is called the EBC mode of operation. There's a nice picture of a penguin on wikipedia encrypted with ECB which demonstrates this:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...
Secure mode of operations generally try to propagate the result of previously encrypted blocks to the next ones. But this approach is not really suitable for mass storage devices. You cannot re-encrypt all the sectors behind the one you just changed. That's just impractical, since writing to sector #0 amounts to rewrite the entire disk.
So in practice schemes like AES-XTS are used. They work by having some kind of way of "tweaking" the encryption, so that it is different for each block (avoiding the pitfalls of ECB), but in a way which allows random access to sectors (i.e. in a way that is predictable). AES-XTS is a tradeoff for this special use case but it is not as robust as more classical modes of operations which would typically be used in an encrypted filesystem.
Details about AES-XTS issues: https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/