7 ms·

Ask HN: How secure is the encryption offered by OS X's Disk Utility?

98 points by whitepoplar 9y ago

purple-dragon 9y ago
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 http://eprint.iacr.org/2012/374.pdf
- iDemonix 9y ago
  As above, it uses known standards. The weakest link is your password, relevant XKCD: https://xkcd.com/538/ https://xkcd.com/538/
  - dogma1138 9y ago
    If your adversaries are not shy on using rubber hose cryptanalysis you are screwed to begin with.
    - yborg 9y ago
      If your adversary finds the password on the post-it on your display, you are also screwed, none of this has any bearing on the OP's question.
coolio2657 9y ago
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.
- jackjeff 9y ago
  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.
  - yoz-y 9y ago
    > 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. 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.
    - Terribledactyl 9y ago
      That might be, but the main point here was that it's way faster. Do you want to destroy a few MBs per drive or a few TBs?
- duskwuff 9y ago
  > 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 9y ago
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: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_.28ECB.29 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/ https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
- 0x0 9y ago
  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?
  - jackjeff 9y ago
    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.
netheril96 9y ago
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 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.
- _qbxp 9y ago
  How does this compare to something like VeraCrypt?
  - netheril96 9y ago
    VeraCrypt is similar to the disk utility created volume. It uses AES-XTS at block level and the size of a container is fixed at creation time.
Heliosmaster 9y ago
Another (related) question: how much slower is MacOS with FDE enabled?
- karlshea 9y ago
  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.
- kristofferR 9y ago
  It's basically as fast as long as your processor has AES-NI support.
mherrmann 9y ago
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.
- gaving 9y ago
  Nothing to hide; nothing to fear, right?
  - glumpyfish 9y ago
    Identity theft would be my biggest concern.
- ja27 9y ago
  I didn't care until my SSD died and I had to decide whether to exchange it or not.

98 points by whitepoplar 9y ago

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 http://eprint.iacr.org/2012/374.pdf

iDemonix 9y ago
As above, it uses known standards. The weakest link is your password, relevant XKCD: https://xkcd.com/538/ https://xkcd.com/538/
- dogma1138 9y ago
  If your adversaries are not shy on using rubber hose cryptanalysis you are screwed to begin with.
  - yborg 9y ago
    If your adversary finds the password on the post-it on your display, you are also screwed, none of this has any bearing on the OP's question.

coolio2657 9y ago

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.

jackjeff 9y ago
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.
- yoz-y 9y ago
  > 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. 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.
  - Terribledactyl 9y ago
    That might be, but the main point here was that it's way faster. Do you want to destroy a few MBs per drive or a few TBs?
duskwuff 9y ago
> 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 9y ago

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: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_.28ECB.29 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/ https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

0x0 9y ago
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?
- jackjeff 9y ago
  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.

netheril96 9y ago

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

_qbxp 9y ago
How does this compare to something like VeraCrypt?
- netheril96 9y ago
  VeraCrypt is similar to the disk utility created volume. It uses AES-XTS at block level and the size of a container is fixed at creation time.

Heliosmaster 9y ago

Another (related) question: how much slower is MacOS with FDE enabled?

karlshea 9y ago
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.
kristofferR 9y ago
It's basically as fast as long as your processor has AES-NI support.

mherrmann 9y ago

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.

gaving 9y ago
Nothing to hide; nothing to fear, right?
- glumpyfish 9y ago
  Identity theft would be my biggest concern.
ja27 9y ago
I didn't care until my SSD died and I had to decide whether to exchange it or not.