Apple Platform Security

May 2022

I personally understand that particular details about Apple device security are somewhat unknown to the regular user, and out of the box protection is great within the Apple ecosystem. I wanted to break down some key aspects, and briefly outline them. As the linked document is fairly technical, I will outline only some key points, you as a regular user maybe unaware of.

The following excerpts are taken in summary form from the following official Apple security document Apple Platform Security

Introduction

Apple designs security into the core of its platforms.

Every Apple device combines hardware, software, and services designed to work together for maximum security and a transparent user experience of keeping personal information safe.

Apple is committed to helping protect customers with leading privacy and security technologies. Apple rewards researchers by Security Bounty. Details of the program are available at security-bounty

We will briefly discuss some technologies offered by Apple in the following categories.

Hardware security and biometrics

For software to be secure, it must rest on hardware that has security built in

Apple devices have security capabilities designed into silicon components including a boot ROM, which forms a hardware root of trust for secure boot, dedicated AES engines for secure encryption and decryption, and a Secure Enclave.

The Secure Enclave is a dedicated secure subsystem integrated into Apple systems on chip (SoCs).

Storage encryption must be fast and efficient. The AES hardware engine performs fast in-line encryption and decryption as files are written or read.

Securing memory, the Secure Enclave operates from a dedicated region of the device’s DRAM memory.

When a device starts up, the Secure Enclave Boot ROM generates a random ephemeral memory protection key for the Memory Protection Engine. Whenever the Secure Enclave writes to its dedicated memory region, the Memory Protection Engine encrypts the block of memory using AES in Mac XEX (xor-encrypt-xor) mode, and calculates a Cipher-based Message Authentication Code (CMAC) authentication tag for the memory.

In the event of a memory authentication error, the Secure Enclave stops accepting requests until the system is rebooted.

Excellent.

Root Cryptographic Keys

The Secure Enclave includes a unique ID (UID) root cryptographic key. The UID is unique to each individual device and isn’t related to any other identifier on the device.

A randomly generated UID is fused into the SoC at manufacturing time.

Secure Enclave AES Engine

The AES Engine is designed to resist leaking information by using timing and Static Power Analysis

The AES Engine supports hardware and software keys.

These keys stay within the AES Engine and aren’t made visible even to sepOS software. Although software can request encryption and decryption operations with hardware keys, it can’t extract the keys.

The Secure Enclave is equipped with a dedicated secure nonvolatile storage device

Devices first released in Fall 2020 or later are equipped with a 2nd-generation Secure Storage Component.

The 2nd-generation Secure Storage Component adds counter lock-boxes. Each counter lock box stores a 128-bit salt, a 128-bit passcode verifier, an 8-bit counter, and an 8-bit maximum attempt value

Counter lock-boxes hold the entropy needed to unlock passcode-protected user data.

To access the user data, the paired Secure Enclave must derive the correct passcode entropy value from the user’s passcode and the Secure Enclave’s UID

The user’s passcode can’t be learned using unlock attempts sent from a source other than the paired Secure Enclave.

If the passcode attempt limit is exceeded, the passcode-protected data is erased completely by the Secure Storage Component

The secure nonvolatile storage is also used for all anti-replay services in the Secure Enclave

System security

System security is responsible for controlling access to system resources in Apple devices without compromising usability.

Secure Boot

The startup process contains components that are cryptographically signed by Apple to enable integrity checking so that boot proceeds only after verifying the chain of trust.

The components included are the bootloaders, the kernel, kernel extensions, and cellular base-band firmware.

Memory safe boot implementation

Apple modified the C compiler toolchain used to build the iBoot bootloader to improve its security. The modified toolchain implements code designed to prevent memory- and type-safety issues that are typically encountered in C programs.

Preventing vulnerabilities in the following classes:

• Buffer overflows

• Heap exploitation

• Type confusion

• Type confusion caused by use after free errors

Bot process for Apple Silicon

The chip executes code from the Boot ROM in the first step in the chain of trust. macOS secure boot on a Mac with Apple Silicon verifies not only the operating system code itself, but also the security policies and even kexts.

Signed system volume security

In macOS 10.15, Apple introduced the read-only system volume, a dedicated, isolated volume for system content.

In addition, macOS 11 or later adds strong cryptographic protections to system content with a signed system volume (SSV).

SSV not only helps prevent tampering with any Apple software that’s part of the operating system, it also makes macOS software update more reliable and much safer.

SSV uses APFS (Apple File System) snapshots, if an update can’t be performed, the old system version can be restored without re-installation.

Each SSV SHA256 hash is stored in the main file-system metadata tree, which is itself hashed. And because each node of the tree recursively verifies the integrity of the hashes of its children—similar to a binary hash (Merkle) tree—the root node’s hash value, called a seal, therefore encompasses every byte of data in the SSV, which means the cryptographic signature covers the entire system volume.

Personalized update process

The boot-time chain-of-trust evaluation verifies that the signature comes from Apple and that the measurement of the item loaded from the storage device, combined with the device’s ECID, matches what was covered by the signature.

The personalization process is why a network connection to Apple is always required to update any device with Apple-designed silicon

Finally, the user’s data volume is never mounted during a software update, to help prevent anything being read from or written to that volume during updates

Additional macOS system security capabilities

The following capabilities support and help secure the varied needs of macOS users. They include:

• Signed system volume security
• System Integrity Protection
• Trust caches
• Protection for peripherals
• Rosetta 2 (automatic translation) support and security for a Mac with Apple Silicon
• DMA support and protections
• Kernel extension (kext) support and security
• Option ROM support and security
• UEFI firmware security for Intel-based Mac computers

Unsigned x86_64 code

A Mac with Apple Silicon does not permit native arm64 code to execute unless a valid signature is attached.

OROM sandbox security

In macOS 10.15, UEFI firmware was updated to contain a mechanism for sandboxing OROMs and for stripping privileges from them

The sandbox further significantly restricts both the interfaces that the OROMs can call (much like system call filtering in kernels) and the type of device that an OROM can register as (much like app approval.)

Encryption and Data Protection

Encryption and Data Protection overview

The secure boot chain, system security, and app security capabilities all help to verify that only trusted code and apps run on a device. Apple devices have additional encryption features to safeguard user data.

iOS and iPadOS devices use a file encryption methodology called Data Protection, Intel-based Mac is protected with a volume encryption technology called FileVault. A Mac with Apple Silicon uses a hybrid model that supports Data Protection, where The lowest protection level Class (D) isn’t supported, and the default level (Class C) uses a volume key.

Key management hierarchies are rooted in the dedicated silicon of the Secure Enclave

Data Protection overview

Data Protection is implemented by constructing and managing a hierarchy of keys and builds on the hardware encryption technologies.

Every time a file on the data volume is created, Data Protection creates a new 256-bit key (the per-file key) and gives it to the hardware AES Engine, which uses the key to encrypt the file as it’s written to flash storage.

On A14, A15, and M1 family devices, the encryption uses AES-256 in XTS mode, where the 256-bit per-file-key goes through a Key Derivation Function (NIST Special Publication 800-108) to derive a 256-bit tweak and a 256-bit cipher key

With Data Protection, each file is protected with a unique per-file (or perextent) key. The key, wrapped using the NIST AED key wrap algorithm.

Data Protection classes

Class A: Complete Protection, Class B: Protected Unless Open, Class C: Protected Until First User Authentication, * Class D: No Protection Note: Not supported in macOS.*

Complete Protection

The class key is protected with a key derived from the user passcode or password and the device UID. Shortly after the user locks a device (10 seconds, if the Require Password setting is Immediately), the decrypted class key is discarded, rendering all data in this class inaccessible until the user enters the passcode again or unlocks (logs in to) the device using Face ID or Touch ID.

Protected Unless Open

Some files may need to be written while the device is locked or the user is logged out, an example of this is a mail attachment downloading in the background.

This behavior is achieved by using asymmetric elliptic curve cryptography (ECDH over Curve25519). The usual per-file key is protected by a key derived using One-Pass Diffie-Hellman Key Agreement as described in NIST SP 800-56A.

The KDF is Concatenation Key Derivation Function (Approved Alternative 1) as described in 5.8.1 of NIST SP 800-56A AlgorithmID is omitted. PartyUInfo and PartyVInfo are the ephemeral and static public keys, respectively. SHA256 is used as the hashing function

As soon as the file is closed, the per-file key is wiped from memory.

Protected Until First User Authentication

This class behaves in the same way as Complete Protection, except that the decrypted class key isn’t removed from memory when the device is locked or the user logged out.

This is the default class for all third-party app data not otherwise assigned to a Data Protection class.

iCloud Backup key-bag

The iCloud Backup key-bag is similar to the backup key-bag. All the class keys in this key-bag are asymmetric (using Curve25519, like the Protected Unless Open Data Protection class).

Protecting user data in the face of attack

Attackers attempting to extract user data often try a number of techniques: extracting the encrypted data to another medium for brute-force attack, manipulating the operating system version, or otherwise changing or weakening the security policy of the device to facilitate attack.

Apple devices support a technology called Sealed Key Protection (SKP) that’s designed to ensure that cryptographic material is rendered unavailable off device. This feature is not provided by the Secure Enclave; instead, it’s supported by hardware registers that exist at a lower layer.

Sealed Key Protection (SKP)

On Apple devices that support Data Protection, the key encryption key (KEK) is protected (or sealed), being tied to the UID available only from the Secure Enclave.

The key that results from entangling the user password, long-term SKP key, and Hardware key 1 (the UID from Secure Enclave) is called the password-derived key. This key is used to protect the user key-bag (on all supported platforms) and KEK (in macOS only), and then enable biometric unlock or auto unlock with other devices such as Apple Watch.

The Secure Enclave Boot Monitor captures the measurement of the Secure Enclave OS that is loaded. When the Application Processor Boot ROM measures the Image4 manifest attached to LLB, that manifest contains a measurement of all other system-paired firmware that is loaded as well.

The LocalPolicy also contains the nsih field which is a hash of the macOS Image4 manifest. The macOS Image4 manifest contains measurements of all the macOS-paired firmware and core macOS boot objects such as the Boot Kernel Collection or signed system volume (SSV) root hash.

If an attacker is able to unexpectedly change any of the above measured firmware, software, or security configuration components, it modifies the measurements stored in the hardware registers. The modification of the measurements causes the crypto hardware-derived system measurement root key (SMRK) to derive to a different value, effectively breaking the seal on the key hierarchy. That causes the system measurement device key (SMDK) to be inaccessible, which in turn causes the KEK, and thus the data, to be inaccessible.

Role of Apple File System

Apple File System (APFS) is a proprietary file system that was designed with encryption in mind.

Optimized for Flash/SSD storage, it features strong encryption, copy-on-write metadata, space sharing, cloning for files and directories, snapshots, fast directory sizing, atomic safe-save primitives, and improved file system fundamentals, as well as a unique copy-on-write design.

Keychain data protection

Many apps need to handle passwords and other short but sensitive bits of data, such as keys and login tokens. The keychain provides a secure way to store these items.

Keychain items are encrypted using two different AES-256-GCM keys: a table key (metadata) and a per-row key (secret key). Keychain metadata (all attributes other than kSecValue) is encrypted with the metadata key to speed searches, and the secret value (kSecValueData) is encrypted with the secret key.

The metadata key is protected by the Secure Enclave but is cached in the Application Processor to allow fast queries of the keychain. The secret key always requires a round trip through the Secure Enclave.

The keychain is implemented as a SQLite database, stored on the file system. There is only one database, and the securityd daemon determines which keychain items each process or app can access.

Keychain data is protected using a class structure similar to the one used in file Data Protection.

Keychains can use access control lists (ACLs) to set policies for accessibility and authentication requirements.

FileVault

Mac computers offer FileVault, a built-in encryption capability, to secure all data at rest. FileVault uses the AES-XTS data encryption algorithm to protect full volumes on internal and removable storage devices.

FileVault on a Mac with Apple Silicon is implemented using Data Protection Class C with a volume key.

Internal storage with FileVault turned on

Without valid login credentials or a cryptographic recovery key, the internal APFS volumes remain encrypted and are protected from unauthorized access even if the physical storage device is removed and connected to another computer.

On a Mac with Apple Silicon and those with the T2 chip, all FileVault key handling occurs in the Secure Enclave; encryption keys are never directly exposed to the Intel CPU.

Internal storage with FileVault turned off

If FileVault isn’t turned on in a Mac with Apple Silicon or a Mac with the T2 chip during the initial Setup Assistant process, the volume is still encrypted but the volume encryption key is protected only by the hardware UID in the Secure Enclave.

Protecting app access to user data

In addition to encrypting data at rest, Apple devices help prevent apps from accessing a user’s personal information without permission using various technologies including Data Vault.

As this section is fairly vast, you can refer back to the documentation for more information.

App security

App security overview

Apps are among the most critical elements of a security architecture. Apps also have the potential to negatively impact system security, stability, and user data if they’re not handled properly.

Apple provides layers of protection to help ensure that apps are free of known malware and haven’t been tampered with.

On iPhone, iPad, and iPod touch, all apps are obtained from the App Store—and all apps are sandboxed.

On Mac, many apps are obtained from the App Store, but Mac users also download and use apps from the internet.

To safely support internet downloading, macOS layers additional controls. First, by default in macOS 10.15 or later, all Mac apps need to be notarized by Apple to launch.

This requirement helps to ensure that these apps are free of known malware, without requiring that the apps be provided through the App Store. In addition, macOS includes state-of-the-art antivirus protection to block—and if necessary remove— malware.

As an additional control across platforms, sandboxing helps protect user data from unauthorized access by apps.

Some protections are as follows, Plug-in unapproved list, Safari extension unapproved list, File Quarantine, XProtect/YARA signatures, Gatekeeper, efi-check, Application firewall, Packet Filter, System Integrity Protection, Mandatory Access Controls, Kext exclude list, Mandatory app code signing, App notarization.

You can research each of these technologies for further study.

How developers sign their apps?

Developers can sign their apps through certificate validation (through the Apple Developer Program).

Certificate validation: To develop and install apps in iOS or iPadOS devices, developers must register with Apple and join the Apple Developer Program. The real-world identity of each developer, whether an individual or a business, is verified by Apple before their certificate is issued.

Protecting against malware in macOS

Three layers of defense,

1. (1.) Prevent launch or execution of malware: App Store, or Gatekeeper combined with Notarization
2. (2.) Block malware from running on customer systems: Gatekeeper, Notarization, and XProtect
3. (3.) Remediate malware that has executed: XProtect

This section is also very detailed, please refer to the original documentation.

Services security

Services security overview

This chapter covers security technologies used in iCloud, Sign in with Apple, Apple Pay, iMessage, Apple Messages for Business, FaceTime, Find My, and Continuity. We will only post on iCloud in this section.

iCloud's security overview

iCloud secures the user’s information by encrypting it when it's in transit, storing it in an encrypted format, and securing their encryption keys in Apple data centers.

Apple services use end-to-end encryption, only the user can access their information, and only on trusted devices where the user is signed in with their Apple ID.

iCloud Drive security

iCloud Drive adds account-based keys to protect documents stored in iCloud.

iCloud Drive chunks and encrypts file contents and stores the encrypted chunks as described in iCloud security overview.

The file content keys are wrapped by record keys stored with the iCloud Drive metadata.

These record keys are in turn protected by the user’s iCloud Drive service key.

iCloud backup

iCloud secures the content by encrypting it when it’s sent over the internet, storing it in an encrypted format and using secure tokens for authentication. iCloud Backup occurs only when the device is locked, connected to a power source, and has Wi-Fi access to the internet.

When files are created in Data Protection classes that aren’t accessible when the device is locked, their per-file keys are encrypted, using the class keys from the iCloud Backup key-bag.

The iCloud Backup key-bag contains asymmetric (Curve25519) keys for Data Protection classes that aren’t accessible when the device is locked.

While the user’s keychain database is backed up to iCloud, it remains protected by a UIDtangled key. This allows the keychain to be restored only to the same device from which it originated, and it means no one else, including Apple, can read the user’s keychain items.

Other iCloud security features can be referred in the original document.

iCloud Private Relay

iCloud Private Relay helps protect users primarily when browsing the web with Safari, but it also includes all DNS name resolution requests.

This helps ensure that no single party, not even Apple, can correlate your IP address and your browsing activity.

This process uses different proxies, an ingress proxy, managed by Apple and an egress proxy, managed by a content provider.

This is still in beta, we don't use it (yet), We use ProtonVPN

Network security

Network security overview

iOS, iPadOS, and macOS support Transport Layer Security (TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3) and Datagram Transport Layer Security (DTLS). The TLS protocol supports both AES128 and AES256, and prefers cipher suites with forward secrecy.

Internet apps such as Safari, Calendar, and Mail automatically use this protocol to enable an encrypted communication channel between the device and network services.

In iOS 11 or later and macOS 10.13 or later, SHA-1 certificates are no longer allowed for TLS connections unless trusted by the user. Certificates with RSA keys shorter than 2048 bits are also disallowed.

App Transport Security

Transport Security limits cipher selection to include only suites that provide forward secrecy, specifically: ECDHE_ECDSA_AES and ECDHE_RSA_AES in Galois/Counter Mode (GCM), Cipher Block Chaining (CBC) mode.

Servers must support TLS 1.2 and forward secrecy, and certificates must be valid and signed using SHA256 or stronger with a minimum 2048-bit RSA key or 256-bit elliptic curve key.

Network connections that don’t meet these requirements will fail.

IPv6 security

All Apple operating systems support IPv6, implementing several mechanisms to protect the privacy of users and the stability of the networking stack.

To protect against attacks based on IPv6 extension headers and fragmentation, Apple devices implement protection measures specified in RFC 6980, RFC 7112, and RFC 8021.

Please refer to the documentation for a more detailed study.

Wi-Fi security

All Apple platforms support industry-standard Wi-Fi authentication and encryption protocols, WPA2 and WPA3 authenticate each connection and provide 128-bit AES encryption.

Newer devices support authentication with WPA3 Enterprise 192-bit security, including support for 256-bit AES encryption when connecting to compatible wireless access points (APs).

MAC address randomization

Apple platforms use a randomized media access control address (MAC address) when performing Wi-Fi scans when not associated with a Wi-Fi network.

For more information, see the Apple Support article Use private Wi-Fi addresses

The bluetooth security is also quite vast, and out of scope for this article, please refer to the original for more information on Bluetooth connectivity.

Firewall security in macOS

macOS includes a built-in firewall to protect the Mac from network access and denial-of service attacks.

Don't forget to turn it on!

This concludes our post highlighting some of Apple's cutting edge security technologies and out of the box protections. If you would like a post comparing a Linux ecosystem let me know on Twitter! @ryd3v