The iCloud Keychain is the primary storage for all Sentinel app. In this article we will deep-dive into how the iCloud Keychain works.
1. Focus: iCloud Keychain
iCloud Keychain operates two stores: "com.apple.security.cloudkeychainproxy3" and "com.apple.sbd3" (SBD stands for "Secure Backup Daemon"). The first store is used to maintain a list of trusted devices and to sync records between devices. The second store is used for backing up and restoring Keychain records on new devices. The Keychain records are stored in a regular Key/Value store, encrypted with a set of keys that are protected by a password.
When a user activates for the first time iCloud Keychain on their device, the following steps are taken to ensure the security and accessibility of the data.
First, the device creates a unique public-private key pair that represents the device's syncing identity. This key pair is used to establish a secure "circle of trust" for syncing data between devices. The public key is added to this circle and the circle is signed twice: first, with the private key of the device's syncing identity and second, with an asymmetric key that is derived from the user's iCloud password. The circle also stores additional information, such as the parameters for key generation (salt and the number of iterations).
The signed circle is then stored in iCloud's Key/Value store, which can only be accessed with the correct iCloud password and can only be modified with the private key of one of the devices included in the circle. When a user activates iCloud Keychain on another device (recovery), the new device communicates with iCloud's Key/Value store and establishes that the user already has a circle of trust, but the new device is not yet a member. The device generates new synchronization keys and creates a receipt to request membership to the circle. The receipt contains the public key for syncing the device and is signed with a key that is derived from the user's iCloud password. The signed receipt is then stored in the Key/Value store.
The first device can detect the new receipt and prompts the user to approve the addition of the new device to their circle of trust. The user must enter their iCloud password, which is used to verify the validity of the receipt's signature. This confirms that the person requesting the addition of the new device has entered the correct password.
Once the user confirms the addition of the new device to the circle, the first device adds the new device's public key for syncing to the circle and signs it again, using both the first device's private synchronization key and the key derived from the user's iCloud password. The updated circle is then stored in iCloud and the new device also signs it. This way all devices are connected in a secure and private way, and the user can access their data from any device.
From now on, Keychain records are then shared via iCloud's Key/Value store. If the same record is present on both devices, priority is given to the record with the most recent modification time. If the record modification time in iCloud and on the device is the same, the record is not synced.
2. Deep dive into Keychain Recovery
As we have seen, once a device is in the circle of trust it will sync with the Keychain, so it’s important to keep any external party out, preventing unauthorized Keychain Recovery.
The Keychain records are stored in a regular Key/Value store, encrypted with a set of keys that are protected by a password. Such a password can be derived from an escrow service provided by Apple.
This escrow service (apple.Dataclass.KeychainSync) was first introduced in iOS 7 and allows the secure storage and recovery of user secrets after successful authentication.
The service is hosted at pXX-escrowproxy.icloud.com and requires the following for successful authentication:
- iCloud authentication token obtained in exchange for an Apple ID and password during initial authentication in iCloud;
- iCloud Security Code - iCSC (or registered device passcode if 2FA is enabled);
- A six-digit numeric code is communicated by the Apple servers via SMS (only if 2FA is not enabled).
3. Escrow data extraction
The details of the process are out of the scope of this article, what is interesting for us at the moment is how Apple verifies the legitimacy of the request and protects us from different attack vectors. Apple does it implementing the SRP-6a protocol.
SRP, or Secure Remote Password, is a type of password authentication protocol that is designed to protect against eavesdropping and man-in-the-middle attacks. This means that even if an attacker intercepts the communication, they would not be able to intercept the password hash and restore it, as no hash is transmitted. Apple is currently using the most advanced version SPR-6a, which is instructed to disconnect and block permanently any further work with the escrow service after 10 failed attempts of authentication. In this way, the system is designed for resisting any attempted brute force attacks against iCSC.
So far so good, the design is pretty sound against external attacks, but what about internal ones (i.e. Apple)? For example, what if the password has not been encrypted before escrow? An attacker may be able to compromise Keychain records stored in iCloud.
Apple has provided an answer to this question in its “iOS Security” document, claiming that specialized Hardware Security Modules (HSM) are used to store the escrowed records and that access to escrowed data is impossible.
4. Step-by-step Keychain data recovery
With this information in mind, we can recreate step-by-step the process to recover data from the Keychain (from a technical perspective):
- user should authenticate to iCloud and provide an SMS code (if 2FA is not enabled);
- user should enter iCSC code or registered device passcode, if 2FA is enabled;
- HSM cluster verifies iCSC code via SRP protocol;
- the device uses iCSC/passcode to decrypt the escrowed record;
- the device uses escrowed record (i.e. password) to decrypt Key/Value store data.