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

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

98 pointswhitepoplar40 comments

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

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/

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.

That sounds great! Best of both worlds. Looking forward to see more details as the betas progress.

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:

  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)

Whoops! Forgot to delete that one!

interesting:

  1) your name is 'User'
  2) you actually do use underscores instead of spaces
  3) any pics?

On a serious note: using archived/compressed files might be fine when one is aware about the shortcomings.

I think every Filesystem entry is encrypted with its own random key and this is further encrypted with passphrase protected master key(s)

Typo: EBC should read ECB.

"Electronic Code Book"

"Europen Central Bank"

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.

Homework: after encrypting a file, I edit it, and the block is changed and re-encrypted with the same block number as a counter.

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.

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?

Yes, thread model for full disk encryption is defined for an attacker that has ability to read the encrypted contents of disk at any point in time.

CTR mode is also malleable at bit level, while XTS is less so (this matters when an attacker can modify the encrypted contents).

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.

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

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

As above, it uses known standards.

The weakest link is your password, relevant XKCD: https://xkcd.com/538/

If your adversaries are not shy on using rubber hose cryptanalysis you are screwed to begin with.

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.

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.

Nothing to hide; nothing to fear, right?

Identity theft would be my biggest concern.

I didn't care until my SSD died and I had to decide whether to exchange it or not.

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.

How does this compare to something like VeraCrypt?

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.

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

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's basically as fast as long as your processor has AES-NI support.

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.

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

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?

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

You can even set a firmware password on top of that to block any attempts to boot into target disk mode or single user or recovery

Firmware passwords are trivial to bypass if you have physical access and the proper tools. [0]

$30 gets you the equipment needed to dump, modify, and re-write the firmware, clearing any firmware password.

[0] https://trmm.net/SPI_flash

Granted I maybe missed it but this doesn't Specifically State that it was successfully used to by pass the firmware lock? Since 2010 Apple has worked hard to close these loopholes https://m.imore.com/how-set-your-macs-firmware-password-and-...

Apple still does not integrate a TPM into their laptops.

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.

Reply on news.ycombinator.com