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?
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.
It's as secure/strong as the standards' based cryptographic method used, i.e., AES-128 or AES-256. If you're curious about the strength of FileVault, some academics published a paper detailing their analysis (spoiler: they thought it was pretty good): http://eprint.iacr.org/2012/374.pdf
I never cared about encrypting local disks until my MacBook was stolen three days ago. I have backups but the thought of someone having all my data is very scary.
If you are using disk utility to create an encrypted container file (as opposed to an on-disk encrypted volume), you may want to check my open source project https://github.com/netheril96/securefs. It encrypts at file level with AES-GCM, rather than AES-XTS at block level, and the size is not fixed at creation.
I'm sure there's some penalty you would see using a benchmark, but I enabled FileVault on a 2011 MacBook Pro with an SSD in it a couple of years ago and I didn't notice any difference at all with day-to-day usage.
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.
It is standard security, nothing out of the blue for a default functionality included in an OS, meaning it is of solid average quality, which, however, unfortunately in the world of security means it is probably not up to par and worth using.
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.
Full disk encryption only really offers security for the following 2 scenarios:
- 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.
> For example, hackers could analyze the preboot environment of an encrypted mac and sniff out the password using a variety of methods.
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.
[+] [-] jackjeff|8 years ago|reply
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/
[+] [-] 0x0|8 years ago|reply
[+] [-] Someone|8 years ago|reply
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."
[+] [-] barrkel|8 years ago|reply
[+] [-] chmike|8 years ago|reply
[+] [-] codewritinfool|8 years ago|reply
[+] [-] purple-dragon|8 years ago|reply
[+] [-] iDemonix|8 years ago|reply
The weakest link is your password, relevant XKCD: https://xkcd.com/538/
[+] [-] mherrmann|8 years ago|reply
[+] [-] ja27|8 years ago|reply
[+] [-] gaving|8 years ago|reply
[+] [-] netheril96|8 years ago|reply
[+] [-] _qbxp|8 years ago|reply
[+] [-] Heliosmaster|8 years ago|reply
[+] [-] karlshea|8 years ago|reply
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.
[+] [-] kristofferR|8 years ago|reply
[+] [-] coolio2657|8 years ago|reply
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.
[+] [-] jackjeff|8 years ago|reply
- 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.
[+] [-] duskwuff|8 years ago|reply
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.