Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Apple devices (both Mac and iOS) use something in between those two approaches. To oversimplify a bit, they store a record on disk that contains the full-disk encryption key, encrypted with the user account password on macOS, or passcode on iOS. So the password serves as both an OS authentication mechanism and the equivalent of a BitLocker password.

As a result, it's not vulnerable to this type of attack: even if you get code execution on the login screen, you can't decrypt the user's data without their password. (If there are multiple users, any user's password will work.)

Traditionally, this meant that if you enabled FileVault on Mac, the first login screen you'd see when booting was actually part of the EFI firmware rather than the OS itself. It couldn't boot the OS until it knew some user's password in order to decrypt the main partition. On iOS, and on macOS as of Big Sur, the immutable OS is separated from user data, so the login screen is part of the OS proper.

Caveats:

- On macOS, this only protects the first login screen. Once you log in, the key stays in memory until the system shuts down, even if you log out or change users. On iOS, some files are like that, but other files are encrypted under a different key which is thrown away whenever the device is locked. [1] Hopefully that comes to macOS in the future.

- If you're using a weak password, such as the default six-digit passcodes on iOS (there's an option to use a stronger password), it would be trivial to brute force the password, so security effectively degrades to what you call the second approach. The security coprocessor will limit the maximum number of attempts, so attacks like this one won't work, but if you compromise the coprocessor then it's game over. And people have.

[1] https://support.apple.com/guide/security/data-protection-cla...



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: