Apple Platform Security Guide (February 2021)
Apple (PDF, via mikeymikey):
This documentation provides details about how security technology and features are implemented within Apple platforms. It also helps organizations combine Apple platform security technology and features with their own policies and procedures to meet their specific security needs.
The future of cybersecurity is vertical integration. By vertical integration, I mean the combination of hardware, software, and cloud-based services to build a comprehensive ecosystem. Vertical integration for increased security isn’t merely a trend at Apple, it’s one we see in wide swaths of the industry, including such key players as Amazon Web Services. When security really matters, it’s hard to compete if you don’t have complete control of the stack: hardware, software, and services.
All of this makes me wonder whatever happened to Project McQueen, Apple’s effort to eliminate its reliance on third-party data centres for iCloud. Surely this project did not die when some of the engineers responsible for it left the company, but Apple still depends on others for hosting.
Apple modified the C compiler toolchain used to build the iBoot bootloader to improve its security. The modified toolchain implements code to prevent memory- and type-safety issues that are typically encountered in C programs.
In macOS 11, equivalent at-rest protection for system content is provided by the SSV, and therefore the system volume no longer needs to be encrypted. Any modifications made to the file system while it’s at rest will be detected by the file system when they’re read. If the user has enabled FileVault, the user’s content on the data volume is still encrypted with a user-provided secret.
If the user chooses to disable the SSV, the system at rest becomes vulnerable to tampering, and this tampering could enable an attacker to extract encrypted user data when the system next starts up. Therefore the system won’t permit the user to disable the SSV if FileVault is enabled. Protection while at rest must be enabled or disabled for both volumes in a consistent manner.
In macOS 10.15 or earlier, FileVault protects operating system software while at rest by encrypting user and system content with a key protected by a user-provided secret. This protects against an attacker with physical access to the device from accessing or effectively modifying the file system containing system software.
The idea here is that with neither FileVault nor the signing protecting the system volume, someone with physical access to the Mac could tamper with the system, e.g. to exfiltrate your password when you log in.
Ever wonder how iCloud Keychain’s Password Monitoring feature works?
tl;dr: Apple servers. 1.5 billion passwords. On-device matching against the most common. Cryptographic private set intersection after that.
Previously:
- Is Big Sur’s System Volume Sealed?
- Apple Platform Security Guide (Fall 2019)
- GrayKey iPhone Unlocker
2 Comments RSS · Twitter
The purpose of FileVault has always been to protect against theft, not against so-called "evil maid" attacks. This is indisputable, because Macs had been vulnerable for many years to evil maid attacks at the hardware/firmware level. In the case of laptop theft, there is no danger, because the laptop owner will likely never boot the machine again, and even if the owner happens to get the stolen device back, it would prudent for them to erase the system volume and restore it to a known good version before unlocking FileVault. For the vast majority of Mac users, the danger of theft is vastly greater than the danger of evil maid attacks.
Thus, the inability to modify the system volume with FileVault enabled seems like a cynical ploy by Apple to prevent people from modifying their system. It's true that if you don't use a signed system volume, then you open up the possibility of an evil maid attack — but again, this had always been the situation before SSV. Let's not pretend that FileVault prevented evil maid attacks. Also, it takes a significant degree of effort and technical expertise to modify the Big Sur system volume, so this is not even a possibility for unsophisticated users. You have to know what you're doing, and you knowingly make a decision to take the "risk". Why don't you have the choice, if you reasonably believe that an evil maid attack on your Mac is extremely unlikely?
This is the general form of Mac lockdown lately. Apple can claim that they're not locking down the Mac, technically speaking, because it's still "possible" for you to run whatever code you like. But then Apple makes the tradeoffs so abhorrent that nobody would want to go to the trouble of removing the new restrictions Apple adds. In this case, Apple forces you to disable FileVault in order to modify your system volume. That's not security, it's lockdown masquerading as security. In other words, security theater.
Is that memory-safe C compiler public, and if not why not?