Keychain in iOS. What you need to know! Icloud account verification

Keychain Access is a manager of account names, passwords, and credit card information that allows values ​​entered once on one device to be stored on another using iCloud. With its help, you can get rid of the need to enter the same thing to log in to websites or pay for goods and services through Safari on iPhone, iPad and Mac computers. Whether or not to trust your data to Apple’s cloud service is an individual matter for everyone. However, you must be aware that all of them are stored on the company’s servers in encrypted form and cannot be viewed by company employees.

So how do you set up and use Keychain on iPhone and iPad on iOS 7?

1. Go to the “Settings” application of the iOS 7 operating system:

2. Go to the iCloud section:

3. Go to the “Keychain Access” menu:

4. Move the function enable switch to the active position (you may need to enter your Apple ID account password):

5. Create, enter and repeat the iCloud security code to restrict access to the Keychain function:

6. Select your country of residence, enter your phone number and confirm the data by clicking the “Next” button:

7. Now, when entering account or credit card data on Internet pages in Safari, the user will be offered the opportunity to save them for later access from other devices:

Thus, by setting up the Keychain feature on all your devices, you can get rid of the need to enter your account information on numerous services over and over again, entering it only once on one of the devices linked to one Apple ID.

Chapter 3

Basic information

Use the Touch ID sensor to unlock your iPad. Press the Home button
finger whose fingerprint was added in Settings. You can unlock your iPad as follows:
from the lock screen and from the password entry screen.
Use Touch ID for purchases from the iTunes Store, App Store, and iBooks Store.
Follow the instructions for purchases from the iTunes Store, App Store, and iBooks Store
on using your fingerprint to make purchases. You can also choose
Go to Settings > Touch ID & Passcode, then turn on iTunes & App Store.
Use Touch ID to pay for purchases in apps that support Apple Pay.
Go to Settings > Touch ID & Passcode to check if the technology is turned on
Apple Pay for your Touch ID. See section for details

iCloud Keychain

iCloud Keychain stores the latest usernames and passwords
to visit websites in Safari, information about bank cards and Wi-Fi networks. Bunch
iCloud Keys can be used on all approved devices (with iOS 7 or later)
and Mac computers (with OS X Mavericks or later).

iCloud Keychain works with Password Generator and AutoFill
Safari programs. When creating a new account Safari Password Generator
offers a unique password that is difficult to guess. You can use the function
"AutoFill" to automatically enter names and passwords on iPad, which significantly
Makes it easier to log into various websites. Cm.

Note. Some websites do not support autocomplete.

iCloud Keychain is secure with 256-bit AES encryption
data storage and transmission; this information cannot be read by Apple.
Setting up iCloud Keychain. Go to Settings > iCloud > Keychain. Turn on
iCloud Keychain and follow the onscreen instructions. If you have configured
iCloud Keychain on other devices, you must confirm the use of this
features on one of these devices or use the iCloud security code.

Important!

Apple cannot receive your iCloud security code. If you forget

this code, you will have to set up iCloud Keychain again.
Setting up Autofill. Go to Settings > Safari > Passwords & AutoFill.
Make sure that the "Names and Passwords" and "Credit Cards" features are turned on (they are turned on
default). To add credit card information, tap Saved
credit cards".
The secret code for credit cards is not saved, it is required every time
enter manually.

To automatically enter names, passwords, and credit card information on sites that
support this feature, tap the text field and tap AutoFill.

If iCloud Keychain and AutoFill are turned on, set a password to protect
personal information.

Bunch of keys is a feature of Mac OS X that stores passwords for various applications and other services used on the computer. Typically, when a newly installed program first accesses Keychain, a dialog box appears asking you to enter a password for it, and after entering it, it should not appear again. However, it happens that a password is required every time the program accesses the link, which can greatly interfere with comfortable work. Fortunately, there are several ways to solve this problem.

Disable automatic keychain closure

For security, Bunch of keys may lock after a certain period of time without activity or when the Mac goes to sleep. It is worth distinguishing this function from closing the screen. When you close the keychain, you can work with the computer without entering a password, and when you close the screen, without the password the user will not be able to access the system again. Changing the settings for this feature is quite simple.

It may also be useful to enable the display Keychains on your menu bar. To do this, open the menu Keychain - Settings - General and check the box next to the item “Show keychain status in the menu bar”. After this, a new icon in the form of a lock will appear on the menu bar, which will be open if the keychain is open, and, accordingly, closed if it is locked.

Checking and correcting the keychain

If your keychains are not working properly, you can fix them using the First Aid feature. But before that, you should make sure that it is configured properly.

Disconnect and reconnect A bunch of keys in iCloud

If you use iCloud Keychain so you can access it across multiple devices, it's worth trying disabling the feature on your Mac and then re-enabling it. Before you do this, we strongly recommend that you ensure that you have a complete and current system backup!

Go to menu System Preferences - iCloud. Uncheck the Keychain option, confirm that you really want to disable this feature, and then check the box again. This way you will remove the keychain from your computer and then add it again, which will most likely fix the problem.

Resetting the keychain.

If none of the above helps, you can try resetting the keychain, resulting in a new, clean file. By doing this, you will still have access to the old link file, so your passwords will not be lost, but the system will not use them and you will have to enter them again. In order to reset the keychain, open the menu Keychain - Settings - General, click the "Restore default keychain" button, confirm your choice and wait for the process to complete.

After that, if you need the password saved in the old link, you can open it and move the item you need from the list to the new link, or open this item by double-clicking and view the password by checking the box next to “Show password”.

Many thanks to Christopher Kessler for the material that served as the basis for writing this article.

Today, login to many sites requires authorization, so it is quite difficult to remember various logins and passwords. With the release of the iOS 7.0.3 update, Apple proposed using the iCloud cloud service for this, which can save account names, passwords and credit card numbers.

iCloud Keychain can store your usernames and passwords for websites on iPhone, iPod touch, iPad, and Mac, protecting them with strong 256-bit AES encryption. At the same time, the data is transparently synchronized between all gadgets, so there is no longer any need to remember it.

How to set up Keychain Access in iOS 7:

Step 1: By default, iCloud Keychain is disabled, so before you can set up password synchronization, you need to enable it in the iOS 7 settings. Go to Settings -> iCloud and scroll down to the Keychain section.

Step 2: Turn the iCloud Keychain switch to On. Your iPhone or iPad will prompt you to use your iOS passcode as a security code. In this case, you can set up iCloud Keychain on all your devices using a secret code from the main gadget. Click Use a password or Create a different code.

Step 3: Enter your iCloud security code.

Step 4: In this step, you need to register a backup phone number. You can use your number or any other number you trust to receive SMS messages when you regain access to iCloud Keychain.

Step 5: Provide your account password to complete iCloud Keychain setup.

Step 6: Now, when you specify an account on websites, Safari will prompt you to save the password in the iDevice memory and in the iCloud Keychain. At the same time, the cloud service will keep the information up-to-date on each device. Passwords will be entered automatically at the right time.

You can view the data saved in iCloud Keychain in the Settings -> Safari -> Passwords and AutoFill -> Saved Passwords menu.

Storing passwords securely and synchronizing them across devices is no easy task. About a year ago, Apple introduced the world to iCloud Keychain, its centralized password store in OS X and iOS. Let's try to figure out where and how user passwords are stored, what potential risks this poses, and whether Apple has the technical ability to gain access to the decrypted data stored on its servers. The company claims that such access is impossible, but to confirm or deny this, you need to understand how iCloud Keychain works.

iCloud 101

In fact, iCloud is not just one service, it is a general marketing name for a number of cloud services from Apple. This includes synchronizing settings, documents and photos, Find My Phone for finding lost or stolen devices, iCloud Backup for cloud backup, and now iCloud Keychain for securely synchronizing passwords and credit card numbers between iOS and OS X devices .

Each iCloud service is located on its own third-level domain, such as pXX-keyvalueservice.icloud.com, where XX is the number of the group of servers responsible for processing the current user's requests; This number may be different for different Apple IDs; newer accounts usually have a higher value for this counter.

iCloud Security Code

Before diving into the iCloud Keychain analysis, let's take a look at how this service is configured. When enabling iCloud Keychain, the user is prompted to come up with and enter an iCloud Security Code (iCloud Security Code, hereinafter referred to as iCSC). By default, the input form allows you to use a four-digit numeric code, but by clicking on the "Advanced options" link, you can still use a more complex code or even allow the device to generate a strong random code.

We now know that data in iCloud Keychain is protected using iCSC. Well, let's try to figure out how exactly this protection is implemented!

Traffic interception or man-in-the-middle

The first step in analyzing network services is often to gain access to the network traffic between the client and server. In the case of iCloud, there are two news for us: bad and good. The bad news is that all (or at least the overwhelming majority of it) traffic is protected by TLS/SSL, that is, it is encrypted and cannot be “read” by a regular passive attack. The good news is that Apple has given everyone a gift to explore iCloud and does not use certificate pinning, which makes it quite easy to organize a man-in-the-middle attack and decrypt intercepted traffic. For this it is enough:

1. Place the experimental iOS device on the same Wi-Fi network as the computer performing the interception.

1. Install an intercepting proxy server on your computer (such as Burp, Charles Proxy or any similar one).

1. Import the TLS/SSL certificate of the installed proxy server to the iOS device (for details, see the help for the specific proxy).

1. In the Wi-Fi network settings on your iOS device (Settings → Wi-Fi → Network name → HTTP Proxy), specify the IP address of the intercepting computer in the Wi-Fi network and the port on which the proxy server is listening.

If everything is done correctly, then all traffic between the device and iCloud will be in full view. And from the interception of this traffic, it will be clearly visible that iCloud Keychain is built on the basis of two iCloud services: com.apple.Dataclass.KeyValue and com.apple.Dataclass.KeychainSync - both upon initial and repeated activation on other iOS devices, it exchanges data with these services.

The first service is not new and was among the first features of iCloud; it is widely used by applications to sync settings. The second one is new and was apparently developed specifically for iCloud Keychain (although its functionality theoretically allows it to be used for other purposes). Let's take a closer look at these services.

com.apple.Dataclass.KeyValue

As noted above, this is one of the services used by iCloud Keychain. Many existing applications use it to sync small amounts of data (settings, bookmarks, etc.). Each record stored by this service is associated with an application identifier (Bundle ID) and a store name (store). Accordingly, to receive stored data from the service, you must also provide these identifiers. As part of iCloud Keychain, this service is used to synchronize Keychain records in encrypted form. This process is described in sufficient detail in the iOS Security document in the sections Keychain syncing and How keychain syncing works.

Keychain synchronization

When a user first turns on iCloud Keychain, the device creates a circle of trust and a synchronization identity (consisting of a public and private key) for the current device. The pair's public key is placed in a "circle of trust", and this "circle" is signed twice: first with the device's private sync key, and then with an asymmetric key (based on elliptic cryptography) derived from the user's iCloud password. Also in the “circle” parameters for calculating the key from the password, such as salt and the number of iterations, are stored.

The signed “circle” is saved in the Key/Value storage. It cannot be read without knowing the user's iCloud password and cannot be changed without knowing the private key of one of the devices added to the circle.

When a user enables iCloud Keychain on another device, that device accesses the Key/Value store in iCloud and notices that the user already has a “circle of trust” and that the new device is not part of it. The device generates sync keys and a receipt to request circle membership. The receipt contains the device's public synchronization key and is signed with a key obtained from the user's iCloud password using key generation parameters obtained from the Key/Value store. The signed receipt is then placed in the Key/Value store.

The first device sees the new receipt and shows the user a message indicating that the new device is requesting to be added to the “circle of trust.” The user enters the iCloud password, and the receipt signature is verified to be correct. This proves that the user who generated the request to add the device entered the correct password when creating the receipt.

After the user confirms adding the device to the circle, the first device adds the new device's public sync key to the circle and double-signs it again with its private sync key and the key derived from the user's iCloud password. The new "circle" is saved to iCloud, and the new device signs it in the same way.

How Keychain Synchronization Works

Now there are two devices in the “circle of trust”, and each of them knows the public synchronization keys of other devices. They begin exchanging Keychain records via iCloud Key/Value storage. If the same entry is present on both devices, then priority will be given to the modification that has a later time. If the modification time of an entry in iCloud and on the device are the same, the entry is not synchronized. Each synchronized entry is encrypted specifically for the target device; it cannot be decrypted by other devices or Apple. In addition, the recording is not stored in iCloud permanently - it is overwritten by new synced recordings.

This process is repeated for each new device added to the circle of trust. For example, if a third device is added to the circle, a confirmation prompt will be shown on the other two devices. The user can confirm the addition on any of them. As new devices are added, each device in the circle is synced with the new ones to ensure that the set of records on all devices is the same.

It should be noted that not the entire Keychain is synchronized. Some records are tied to the device (such as VPN accounts) and should not leave the device. Only records that have the kSecAttrSynchronizable attribute are synchronized. Apple has set this attribute for Safari user data (including usernames, passwords, and credit card numbers) and for Wi-Fi passwords.

Additionally, third-party app recordings are also not synced by default. To keep them synchronized, developers must explicitly set the kSecAttrSynchronizable attribute when adding an entry to the Keychain.

iCloud Keychain operates with two storages:

• com.apple.security.cloudkeychainproxy3

- Bundle ID: com.apple.security.cloudkeychainproxy3;

• com.apple.sbd3

- Bundle ID: com.apple.sbd (SBD is an acronym for Secure Backup Daemon).

The first store is presumably used to maintain a list of trusted devices (devices in a "circle of trust" between which passwords are allowed to be synchronized), to add new devices to this list, and to synchronize records between devices (according to the mechanism described above).

The second storage is intended for backing up and restoring Keychain records to new devices (for example, when there are no other devices in the “circle of trust”) and contains encrypted Keychain records and related information.

Thus, Keychain records are stored in a regular Key/Value store (com.apple.securebackup.record). These records are encrypted using a set of keys stored there (BackupKeybag). But this set of keys is password protected. Where does this password come from? What is this Apple password escrow service? Next we will try to figure it out.

apple.Dataclass.KeychainSync

This is a new service, it appeared relatively recently: its support first appeared in beta versions of iOS 7, then it was absent in iOS 7.0–7.0.2 and was added again in iOS 7.0.3, which was released simultaneously with the release of OS X Mavericks. This is the password escrow service mentioned above (the service address is pXX-escrowproxy.icloud.com).

The service is designed to securely store user secrets and allow the user to recover those secrets after successful authentication. For successful authentication the following is required:

• iCloud authentication token, received in exchange for an Apple ID and password during initial authentication in iCloud (the standard authentication method for most iCloud services);

• iCloud Security Code (iCSC);

• a six-digit numeric code sent by Apple servers to the cell phone number associated with the user.

In theory, everything looks good, but to determine whether theory matches practice, we will need to audit the escrow service client program. On iOS and OS X, this program is called com.apple.lakitu. A description of the process of its reversing and audit is beyond the scope of the article, so let’s move straight to the results.

Available commands

Auditing com.apple.lakitu allows you to determine the list of commands implemented by the escrow service. The corresponding screenshot shows the commands and their descriptions. I would especially like to focus on the last command - with its help it is possible to change the phone number associated with the current account. The presence of this command makes the multi-factor authentication used in iCloud Keychain recovery (Apple ID password + iCSC + device) noticeably less secure, since it eliminates one of the factors. It is also interesting that the iOS user interface does not allow you to run this command - it simply does not have such an option (at least I did not find it).

What sets this command apart from all others is that it requires authentication with an Apple ID password and will not work if an iCloud token is used for authentication (other commands work with token authentication). This provides additional protection for this command and shows that the system designers have taken steps to improve its security. However, it is not entirely clear why this command is present in the system at all.

Recovering Escrow Data

To receive the deposited data, the following protocol is executed:

1. The client requests a list of deposited records (/get_records).

1. The client requests an associated telephone number to which the server will send a confirmation code (/get_sms_targets).

1. The client initiates the generation and delivery of a confirmation code (/generate_sms_challenge).

1. After the user has entered the iCSC and verification code from SMS, the client initiates an authentication attempt using the SRP-6a protocol (/srp_init).

1. After receiving a response from the server, the client performs the calculations prescribed by the SRP-6a protocol and requests the escrow data (/recover).

1. If the client has successfully authenticated, the server returns the deposited data, having previously encrypted it with a key generated during the operation of the SRP-6a protocol (if the protocol worked successfully, then both the server and the client calculated this shared key).

It is important to note that the phone number obtained in step 2 is used solely for user interface purposes, that is, to show the user the number to which the verification code will be sent, and in step 3, the client does not transmit to the server the number to which the verification code should be sent.

Secure Remote Password

In step 4, the client begins executing the SRP-6a protocol. The SRP (Secure Remote Password) protocol is a password authentication protocol that is protected from eavesdropping and man-in-the-middle attacks. Thus, for example, when using this protocol, it is impossible to intercept a password hash and then try to recover it, simply because no hash is transmitted.

Apple uses the most advanced version of the protocol, SRP-6a. This option instructs to close the connection if authentication fails. Additionally, Apple only allows ten failed authentication attempts for a given service, after which all subsequent attempts are blocked.

A detailed description of the SRP protocol and its mathematical foundations is beyond the scope of the article, but for completeness, a particular version used by the com.apple.Dataclass.KeychainSync service is presented below.

The hash function H is SHA-256, and the group (N, g) is the 2048-bit group from RFC 5054 "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". The protocol runs as follows:

1. The device generates a random value a, calculates A=g^a mod N, where N and g are the 2048-bit group parameters from RFC 5054, and sends a message to the server containing the user ID, the calculated value of A, and the confirmation code from the SMS. The value DsID is used as the user identifier - a unique numeric user identifier.
2. Upon receiving the message, the server generates a random value b and calculates B=k*v + g^b mod N , where k is the multiplier defined in SRP-6a as k=H(N, g) , v=g^H(Salt, iCSC) mod N - password verifier stored on the server (analogous to a password hash), Salt - random salt generated when creating an account. The server sends a message to the client containing B and Salt .
3. Through simple mathematical transformations, the client and server calculate a common session key K. This completes the first part of the protocol - key derivation - and now the client and server must ensure that they have received the same value for K.
4. The client calculates M=H(H(N) XOR H(g) | H(ID) | Salt | A | B | K) , a proof that it knows K , and sends M and the confirmation code from the SMS to the server. The server also calculates M and compares the value received from the client and the calculated value; if they do not match, the server stops executing the protocol and breaks the connection.
5. The server proves knowledge of K to the client by computing and sending H(A, M, K) . Now both participants in the protocol have not only developed a common key, but also made sure that this key is the same for both participants. In the case of the escrow service, the server also returns a random IV and an escrow record encrypted with a shared key K using the AES algorithm in CBC mode.

Using SRP for additional protection of user data, in my opinion, significantly improves the security of the system from external attacks, if only because it allows you to effectively resist brute force attempts at iCSC: you can try only one password per connection to the service. After several unsuccessful attempts, the account (as part of working with the escrow service) is transferred to the soft lock state and temporarily blocked, and after ten unsuccessful attempts, the account is permanently blocked and further work with the escrow service is possible only after resetting the iCSC for the account.

At the same time, the use of SRP does not protect against internal threats in any way. The deposited password is stored on Apple's servers, so it can be assumed that Apple can access it if necessary. In this case, if the password was not protected (e.g. encrypted) prior to escrow, this could result in a complete compromise of the Keychain records stored in iCloud, since the escrowed password would allow the encryption keys to be decrypted, which would decrypt the Keychain records (note com. apple.Dataclass.KeyValue).

However, in the "iOS Security" document, Apple claims that specialized hardware security modules (Hardware Security Modules (HSM)) are used to store escrowed records and that access to escrowed data is impossible.

Escrow Security

iCloud provides a secure infrastructure for Keychain escrow, ensuring that Keychain can only be recovered by authorized users and devices. HSM clusters protect escrow records. Each cluster has its own encryption key used to protect records.

To recover Keychain, the user must authenticate using the iCloud username and password and respond to the sent SMS. Once this is completed, the user must enter the iCloud Security Code (iCSC). The HSM cluster verifies the correctness of the iCSC using the SRP protocol; however, iCSC is not transmitted to Apple servers. Each node in the cluster, independently of the others, checks to see if the user has exceeded the maximum number of attempts to retrieve data. If the check is successful on most nodes, the cluster decrypts the escrow record and returns it to the user.

The device then uses iCSC to decrypt the escrow record and obtain the password used to encrypt the Keychain records. Using this password, the Keychain obtained from the Key/Value storage is decrypted and restored to the device. Only ten attempts are allowed to authenticate and retrieve deposited data. After several unsuccessful attempts, the entry is locked and the user must contact support to unblock it. After the tenth unsuccessful attempt, the HSM cluster destroys the escrowed record. This provides protection against brute force attacks aimed at obtaining a record.

Unfortunately, it is not possible to verify whether HSMs are actually used. If this is indeed the case and HSMs do not allow the data stored in them to be read, then it can be argued that iCloud Keychain data is also protected from internal threats. But, I repeat, unfortunately, it is impossible to prove or disprove the use of HSMs and the inability to read data from them.

There remains one more way to protect data from an insider threat - protecting the escrowed data on the device before transferring it to Apple servers. From Apple's description it follows (and the reversal confirms this) that such protection is applied - the deposited password is pre-encrypted using iCSC. Obviously, in this case, the level of security (from insider threat) directly depends on the complexity of the iCSC and the default four-character iCSC does not provide sufficient protection.

So, we have found out how the individual elements of the system work, and now it’s time to look at the system as a whole.

Putting it all together

The diagram shows how iCloud Keychain works in terms of depositing and restoring Keychain records. The system works as follows:

1. The device generates a set of random keys (in Apple terminology, a keybag) to encrypt Keychain records.
2. The device encrypts Keychain records (those with the kSecAttrSynchronizable attribute set) using the key set generated in the previous step and stores the encrypted records in the Key/Value store com.apple.sbd3 (key com.apple.securebackup.record).
3. The device generates a random password consisting of six groups of four characters (the entropy of such a password is about 124 bits), encrypts the set of keys generated in step 1 using this password, and stores the encrypted set of keys in the com.apple Key/Value store. sbd3 (BackupKeybag key).
4. The device encrypts the random password generated in the previous step with the key obtained from the user's iCloud security code and deposits the encrypted password into the com.apple.Dataclass.KeychainSync service.

When setting up iCloud Keychain, the user can use a complex or random iCSC instead of the default four-digit code. In the case of using complex code, the mechanism of operation of the deposit system does not change; the only difference is that the key for encrypting a random password will be calculated not from the four-digit iCSC, but from a more complex one entered by the user.

With random code, the password escrow subsystem is not used at all. In this case, the random password generated by the system is the iCSC, and the user’s task is to remember it and store it safely. Keychain entries are still encrypted and stored in the Key/Value store com.apple.sbd3 , but the com.apple.Dataclass.KeychainSync service is not used.

conclusions

We can safely say that from a technical point of view (that is, we are not considering social engineering) and in relation to external threats (that is, not Apple), the security of the iCloud Keychain escrow service is at a sufficient level: thanks to the use of the SRP protocol, even if the iCloud password is compromised, the attacker is not will be able to access Keychain records, since this additionally requires an iCloud security code, and brute-forcing this code is significantly difficult.

At the same time, using another mechanism of iCloud Keychain - password synchronization, an attacker who has compromised the iCloud password and has short-term physical access to one of the user’s devices can completely compromise iCloud Keychain: to do this, it is enough to add the attacker’s device to the “circle of trust” of the user’s devices , and for this it is enough to know the iCloud password and have short-term access to the user’s device in order to confirm the request to add a new device to the “circle”.

If we consider protection from internal threats (that is, Apple or anyone with access to Apple servers), then the security of the escrow service does not look so rosy. Apple's claims about the use of HSMs and the inability to read data from them do not have irrefutable evidence, and the cryptographic protection of deposited data is tied to the iCloud security code, is extremely weak with default settings and allows anyone who is able to extract it from Apple's servers (or from HSM) escrow records, recover your four-digit iCloud security code almost instantly.

If a complex alphanumeric code is used, this attack becomes more difficult because the number of possible passwords increases. If iCloud Keychain is configured to use a random code, then the escrow service is not involved at all, effectively making this attack vector impossible.

The maximum level of security (not counting the complete disabling of iCloud Keychain, of course) is ensured by using a random code - and not so much because such a code is more difficult to guess, but because the password escrow subsystem is not involved, and therefore the attack surface is reduced. But the convenience of this option, of course, leaves much to be desired.