{"id":31803,"date":"2021-03-09T13:36:59","date_gmt":"2021-03-09T18:36:59","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=31803"},"modified":"2022-09-22T08:12:40","modified_gmt":"2022-09-22T12:12:40","slug":"apple-platform-security-february-2021","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/03\/09\/apple-platform-security-february-2021\/","title":{"rendered":"Apple Platform Security Guide (February 2021)"},"content":{"rendered":"

Apple<\/a> (PDF<\/a>, via mikeymikey<\/a>):<\/p>\n

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.<\/p><\/blockquote>\n\n

Rich Mogull<\/a>:<\/p>\n

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.<\/p><\/blockquote>\n\n

Nick Heer<\/a>:<\/p>\n

All of this makes me wonder whatever happened to Project McQueen<\/a>, 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<\/a>, but Apple still depends on others for hosting.<\/p><\/blockquote>\n\n

Rosyna Keller<\/a>:<\/p>\n

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.<\/p><\/blockquote>\n\n

Apple<\/a>:<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n<\/blockquote>\n

The idea here is that with neither FileVault nor the signing protecting the system volume, someone with physical access to the Mac could tamper<\/a> with the system, e.g. to exfiltrate your password when you log in.<\/p>\n\n

Ricky Mondello<\/a>:<\/p>\n

\n

Ever wonder how iCloud Keychain’s Password Monitoring feature works?<\/p>\n

tl;dr: Apple servers. 1.5 billion passwords. On-device matching against the most common. Cryptographic private set intersection after that.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n