How to use keychain on ipad. Go to the iCloud section. Code not received via SMS

Chapter 3

Basic information

Usage touch sensor ID for unlocking 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.
Using 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. Detailed information see section

Bunch iCloud keys

iCloud Keychain stores your 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" for automatic input 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 text field and tap AutoFill.

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

iCloud Keychain is a technology for storing and synchronizing confidential data on iPhone, iPad, iPod Touch and Mac computers. The following items fall into the category of stored information: logins and passwords for news and entertainment resources, social networks; added credit cards for payment, keys for authorization in secure Wi-Fi points.

Recently, Apple developers have been transferring between different devices and data from third party applications– “Calendars”, “Contacts”, “Mail” and “iMassage” messages. The main idea of iCloud Keychain is to provide users with a secure (256-bit AES encryption) password manager that works with any data and allows them not to remember information, but to agree to automatic filling available text forms for authorization or payment.

How to set up and use?

Technology - iCloud Keychain - available on the iOS operating system? starting from version 7.0.3 and on MacOS with Mavericks 10.9, and is open in almost all regions of the world (the developers write more about the restrictions in a special section on the official Apple website). If the conditions converge, all that remains is to go through the initial setup steps:

If there are no problems repeating the described steps, and there is a desire to try out the data storage and synchronization system, then all that remains is to understand the details.

And one more thing – the function works smoothly with all third-party applications. Same browser from Google Chrome, calls “Keychain Access” and calmly takes the necessary data. In the same way, it is easy to log in to the App Store, iTunes and iCloud services.

Questions and answers

How to speed up the data entry process?

Check the box in “Settings” in the “Passwords and Accounts” section next to the “Autofill” item. If the system encounters an already familiar resource, it will immediately try to fill out the “login and password” field. On smartphones starting from version 5S, you will have to place your finger on the scanner fingerprint Touch ID, up to 5S – enter verification code. On iPhone X, everything will work instantly - the face is scanned automatically.

Is Keychain Safe?

As Apple developers suggest, it is almost impossible to break through 256-bit encryption, because the data for encryption is generated for each device separately, in accordance with the selected settings and entered passwords. More information about security protocols can be found at.

What happens if you disable iCloud Keychain?

The system will offer two options - delete the saved data or archive it for further use, if the technology is needed again.

How to set up automatic filling of bank card information in Safari?

The procedure is simple:

How to restore access to iCloud?

The best way is to contact support. Professional consultants will tell you how to use standard function recovery, and at the same time they will direct you in the right direction if nothing works out.

For Apple technology users, it marked the appearance of another excellent service V iCloud– password synchronization using iCloud Keychain. Apple has done everything possible to make this feature easier to set up and use, but our readers still have a lot of questions about this new product.

What can iCloud Keychain do?

iCloud Keychain offers:

synchronization of logins, passwords and data from Safari forms
credit card data synchronization
Wi-Fi password synchronization

Synchronization works on Macs with OS X 10.9, iPhone, iPod touch and iPad with iOS 7.0.3. When you activate Keychain in iCloud, a single cloud storage, which collects ALL your passwords. All of them are simultaneously available from all your devices connected to the same iCloud account.

Please note that on Macs, iCloud Keychain only works with Safari! New for Chrome, Firefox or Opera users Apple function will be of little use, because there are no plugins that add support for these browsers and there will not be any. Alternatives to Safari on iOS in this case also no.

Initial setup of iCloud Keychain on Mac

Let’s say right away that for residents of Ukraine, Belarus and other CIS countries not listed in this list, activating Keychain Access from a Mac is the only way to properly configure this function.

Open your Mac settings, go to the iCloud remote, turn on the “Keychain” checkbox:

The Mac will prompt you to enable a password request for your user account immediately after waking up from sleep mode or removing the screen lock - of course, for additional security purposes. This suggestion can be ignored.

You will then be asked to create a Keychain PIN. By default, this is a four-digit number that you need to remember and enter when connecting each new device to your Keychain:

But this is not necessary either. Pay attention to the "Advanced" button. It opens several options regarding the PIN code:

The first will allow paranoiacs to set a code of any length using any characters, not just numbers. The second will generate the code automatically. The third will allow you to completely abandon the security code. But how will new devices be confirmed in this case? It's very simple - using your other devices.

Once you create or reject a PIN, setup is complete.

The initial setup of Keychain on iOS is similar - go to the “Settings-iCloud” menu and turn on the “Keychain” checkbox, after which you create a PIN. The problem is that you will be forced to enter a mobile phone number, and only Russia is supported from the CIS countries.

Now let's talk about connecting new devices to iCloud Keychain.

Connecting a new iOS device to iCloud Keychain

Go to the “Settings-iCloud” menu mentioned above and select “Keychain Access”:

Agree to enable the feature:

You will definitely need to enter your iCloud account password:

After this, the Keychain will go into activation standby mode.

As we said, when adding a new device to your iCloud Keychain, you have two alternatives:

enter PIN code
confirm connection from another device

On your iOS device, you will see a “Verify with code” button, clicking on which you can enter your PIN and immediately activate the function:

The backup option is confirmation from another device. As soon as you try to enable iCloud Keychain on one of your devices, all other gadgets connected to the same iCloud account and the same Keychain will receive notifications:

But this is not just a notification. By clicking on the banner, you will be taken to iCloud settings, where you will be asked to enter your account password as confirmation of your consent to add a new device to your Keychain. After entering your password on any of your other devices new gadget is considered finally connected, password synchronization via iCloud Keychain will begin.

Connecting your new Mac to iCloud Keychain

The process is identical to that described in the previous chapter of the review. You go to OS X settings, iCloud remote and turn on Keychain. Enter your iCloud account password.

Entering the PIN code does not require any special explanation:

If you don't want to enter your PIN, your Mac will remain in activation mode:

It’s quite difficult to miss the notification about the need to confirm a new device - in both OS X and iOS it will be visible:

Storing passwords securely and synchronizing them across devices is no easy task. About a year ago, Apple introduced the world iCloud Keychain, your centralized password storage 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 technical feasibility gain access to 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; For various Apple ID this number may be different; newer accounts usually have higher value 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 four-digit digital code, but by clicking on the link “ Extra options", you can still use 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 network traffic between 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 normal passive attack it will not be possible to “read” it. 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:

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

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

Import a TLS/SSL certificate to an iOS device installed proxy server(details in the specific proxy help).

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 during the initial and when re-enabled on others iOS devices exchanges data with these services.

The first service is not new and was among the first iCloud features; 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 for synchronization small volumes 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 iOS document Security in 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 knowledge user password iCloud 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.” User enters iCloud password, and the receipt signature is checked for correctness. This proves that the user who generated the request to add a device entered correct password when creating a 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 permanently stored in iCloud - 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 custom Safari 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 synchronize them, 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 new service, it arose relatively recently: its support first appeared in beta versions of iOS 7, then it was absent from iOS 7.0–7.0.2 and was reintroduced 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:

token iCloud authentication, 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 digital code sent by Apple servers to the number cell phone, 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 software. 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).

The peculiarity of this command, which distinguishes it from all others, is that it requires authentication with Apple password ID and will not work if an iCloud token is used for authentication (other commands work when authenticating with a token). 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:

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

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

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

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).

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

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, 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 of this 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:

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.
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 .
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.
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.
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 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 Account(as part of working with the escrow service) is transferred to the soft lock state and is temporarily blocked, and after ten unsuccessful attempts the account is permanently blocked and further work with the escrow service is only possible 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 cluster node, independently of the others, checks whether the user has exceeded the maximum permissible quantity attempts to obtain 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 everything is really like this and HSMs do not allow you to read the data stored in them, then we can say that iCloud data Keychain 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 descriptions it follows (and reversing 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 figured 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:

The device generates a set of random keys (in Apple terminology - a keybag) to encrypt Keychain records.
The device encrypts Keychain records (those with the kSecAttrSynchronizable attribute set) using a key set generated on previous step, and saves encrypted records in the Key/Value storage com.apple.sbd3 (key com.apple.securebackup.record).
The device generates 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 Key/Value storage com.apple.sbd3 (BackupKeybag key ).
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.

At iCloud setup Keychain user can use 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 do not consider 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, an attacker will not be able to access Keychain records, since this additionally requires the iCloud security code, and brute force 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 against insider threats (i.e. Apple or anyone with access to Apple servers), then in this case 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 conclusive evidence, and cryptographic protection escrow data is tied to the iCloud security code, in default settings is extremely weak and allows anyone who is able to retrieve escrow records from Apple servers (or from the HSM) to almost instantly recover the four-digit iCloud security code.

If a complex alphanumeric code is used, this attack becomes more difficult as the number of possible passwords. 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.

Maximum level of security (not including full iCloud shutdown Keychain, of course) is ensured by using a random code - and not so much because such a code is more difficult to find, 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.

Life modern man closely related to high technology and electronic gadgets. Each of us uses computers, tablets and smartphones every day, which we not only use for work and entertainment, but also store a large amount of confidential information, for example, photos, passwords from various online services and social networks, as well as credit card information.

However, how safe is it, since passwords are the only means of protection and access to online accounts? Yes, and modern security requirements require the user to use large quantity passwords consisting of complex combinations of letters and numbers that are quite difficult to remember.

And if the owners electronic devices Since most modern manufacturers have to struggle with remembering passwords, owners of phones, tablets and laptops do not have to worry about this, since the manufacturer has developed modern system protection of passwords and confidential information high level reliability, which is called Keychain or “Keychain”.

general information

A bunch of keys is a kind of manager designed for the operating room. iOS systems and responsible for storing and accessing passwords. For the first time, this tool appeared in the eighth version of iOS, which appeared on the market in 1998. Since that time, Keychain has been an integral part of Apple's proprietary OS.

On Macintosh laptops and all-in-one computers, this protection system is responsible for storing various types of confidential information, for example, passwords for accounts of various Internet services, Wi-Fi networks, hidden records, as well as various utilities, devices and encrypted hard drives.

A little history

For the first time, the keychain algorithm was implemented back in the early 90s in mail client PowerTalk, developed by Apple programmers specifically for their operating system. The main task of this service was to control all data entering the client from various sources. However, the first implementation of the keychain algorithm was not entirely successful because it used encryption of passwords that took on a form that was difficult to remember. Thus, the developers were faced with the task of creating single password, which would provide access to the remaining passwords.

However, this idea was initially rejected due to complex implementation and was brought to life only after the return to the position of CEO Steve Jobs, who was not only able to see its innovativeness, but also implement it at the level of the entire OS, and not in a separate application.

Storage and Access

In the tenth generation of MacOS, a separate area on the hard drive was allocated for the operation of the Keychain protection system, which functioned separately from the system partition in which it was located. operating system. And to work with this system it was developed special utility, which is included in the set standard tools iOS. This utility is located in open access and is free, and its operating principle is based on special Keychain files, which contain not only encrypted passwords, but also open data.

Locking and Unlocking

According to standard iOS settings, you can access Keychain files using the same login and password that the user uses to authorize in the system. Therefore, you can start working with them immediately after downloading iOS. If desired, the standard login and password can be changed to a more complex one to increase the level of security. In addition, in the utility settings you can set the blocking interval from at certain intervals, after which the keychain system will prompt you to enter your login and password after this time interval has expired.

iCloud Keychain: Definition

Although this tool was implemented in iOS back in the early 90s, Apple company publicly announced it only in 2013 during the presentation of the seventh version of iOS and the tenth release of MacOS. This was a revolutionary solution to increase the level of security for storing personal user data and ensuring access to it from all electronic gadgets.

However, this security service has also undergone significant changes, the main one being the transfer of the algorithm to work through a cloud data storage service. Thus, all passwords, credit card information and other personal data are now stored not on the hard drive, but on a dedicated company server, which significantly increases their safety. In addition, data encryption has been transferred to the AES 256-bit standard, which provides access to the cloud to only one user through the Safari Internet browser and some other applications that are adapted for it.

The last key innovation was automatic generation complex passwords when registering a user on any sites and online services, which completely eliminates the need to come up with a password yourself and remember it.

How to work with this technology?

Absolutely any phone owner can start using iCloud Keychain tablet computer, on which the seventh is installed iOS version or higher, or owners of ultrabooks or all-in-one Macintoshes running the tenth build of MacOS or higher, as well as those who have completed initial setup services.

Setting up iCloud Keychain on MacOS

So, if you want to increase the level of security for your passwords and other sensitive information on your Ultrabook or Apple All-in-One PC, you need to set up the Keychain service. This is done as follows:

Go to the OS settings.
Expand the iCloud tab.
Start the Keychain Access service.
Enter authorization data.
We indicate the Apple ID.

After completing these steps, the service will be activated.

Adding a credit card to Keychain on MacOS:

Open the Safari browser.
Go to the utility settings.
Go to the Autofill section.
Click on the “Edit” button, which is located next to the “Credit Cards” subsection.
Add a new credit card and indicate its details.

Setting up Keychain on iOS gadgets:

Go to the device settings.
Go to the iCloud section.
Go to the “Keychain” submenu.
We activate or deactivate the Keychain Access service using the slide switch.

After this all you have to do is enter Current Password or set a new one, as well as link other gadgets to the current device that need to be synchronized with it, as well as from which confidential data will be accessed.

Adding a credit card in iOS:

Launch the settings of your smartphone or tablet PC.
Go to the Safari section, then go to the “Passwords and Autofill” submenu.
We indicate the security code.
We go to the section for working with credit cards.
Add a new credit card by clicking on the appropriate button and specifying all the necessary data about it.

Password synchronization

This feature is optional, however, it can significantly increase the security of passwords and other personal information stored in Keychain files when accessed from various gadgets. If you do not want to synchronize data stored on your smartphone, tablet or PC with the cloud, then when you enable Keychain, simply do not set a security code for the service. In this case, all information will be stored only on the device’s hard drive.

If you later want to synchronize cloud storage with your HDD, you can do this using the files located in the /Library/Keychains/ directory. However, it is necessary to take into account that every time you change the password on any of the devices, synchronization will have to be configured again.

How to access information stored in the cloud?

Any user can special problems view information and work with documents stored in cloud service iCloud, however, for this, the system will first ask you to log in using a text message or any other device. If authorization occurs via SMS, a one-time security code will be sent to your phone, which you will need to enter in the appropriate field. As for another electronic gadget, the “Keychain Chain” service must be activated on it.

Problems activating and configuring Keychain Access

The programmers did a very good job creating this technology, as evidenced by its reliability and complete absence any defects or holes in the security system. However, as practice shows, many users encounter various problems when activating, setting up or restoring access to this service, as well as when connecting new gadgets to it.

Very often, when trying to activate a service or gain access to the cloud, the user is faced with the fact that the verification code simply does not arrive.

What to do in such a situation?

The first thing you need to do is check the signal quality of your mobile operator. If no problems are found with the connection, then you need to make sure that the number to which the message with the code should be sent was correctly specified in the system. This can be done in the “Verification Number” section, located in the additional settings of the KeyChain system.

Another common problem is the inability to synchronize Keychain between different gadgets. Deactivation and reactivation services on all devices using Keychain Access.

In addition, many users who have little experience working with Apple products, it is not always possible to access passwords, credit cards and other confidential data stored on the cloud service. To view the information you are interested in, you must perform the following steps:

Go to the gadget settings.
Go to the browser settings section.
Go to the “Passwords” subsection.
Verify your identity using a password or fingerprint.

Next, all you have to do is select any site or online service and look at the password that was specified during registration. If the function of saving passwords in the “Keychain Access” is not enabled in your browser, then to activate it you need to go to the utility settings, go to the “Autofill” subsection and drag the “Names and Passwords” switch to active position. After this there should be no problems with passwords.

And finally, the last common problem is resynchronization, in which the gadget constantly produces an error about inconsistency security code. In this case, the device must be sent to a service center for repair.