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.
Details about AES-XTS issues:
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.
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:
C:\Users\User\Documents\i_hate_my_boss_but_my_boss_has_a_daughter_too_hot_to_give_up.txt (12KB, 2017-06-17 13:04:47)
1) your name is 'User'
2) you actually do use underscores instead of spaces
3) any pics?
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...:
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."
Question: can you discover something about ciphertext which allows you to guess plaintext? If so, what?
Completing this homework will introduce you to disk encryption theory and will help understand the need for XTS-like modes.
CTR mode is also malleable at bit level, while XTS is less so (this matters when an attacker can modify the encrypted contents).
The weakest link is your password, relevant XKCD: https://xkcd.com/538/
I also have it enabled on a 2016 MBP, but I turned it on right when I got it so I don't have a comparison.
From what I understand it's hardware-accelerated, but I don't know the specifics.
The encryption standards it uses are pretty good, but that is not where blanket whole-disk encryption (which I assume you're talking about) fail. For example, hackers could analyze the preboot environment of an encrypted mac and sniff out the password using a variety of methods. Simply put, whole-disk encryption is too complicated and bug-prone process to really trust to closed-source software.
As for single-file encryption, which is relatively neat and simple, Disk Utility would probably do a pretty good job.
- My computer/phone was lost and it was powered off. If my password is good and secure, then I can be assured the data contained on the disk will not fall into the wrong hands.
- I need to securely wipe data off the disk, because I'm selling the computer or something. Just deleting the master encryption key contained on the disk is probably enough to render the whole thing unreadable. I don't need to spend days using special software to overwrite all sectors multiple times.
Once the system is booted, the decryption key for the disk will be made available to the OS, and all files will be made available to root processes. At this stage, having a encrypted disk offers no more protection than having a non-encrypted one.
From what I have read, on any reasonably recent drive (made in last two decades or so) a one time random pass is plenty fine.
The password is not available in the preboot environment. The disk encryption key is encrypted with the user's password, which must be entered to boot the machine.
While Apple hasn't open-sourced the implementation, they've explained how it operates in considerable detail. By all accounts, it's a rather good design.
$30 gets you the equipment needed to dump, modify, and re-write the firmware, clearing any firmware password.
And it doesn't matter, even if they did, you could modify the firmware on flash to bypass the checks.
There is nothing stopping someone with physical access from removing the firmware password via SPI flash.
It is a fundamental flaw of x86, IMHO, that there is no Boot ROM (BROM) which can perform signature/integrity checks on the UEFI firmware. ARM has this, x86 does not.