OS X Mavericks принесла нам нечто под название iCloud Keychain (Связка ключей iCloud). Это облачный сейф с паролями от ваших любимых сайтов, которые автоматически синхронизируются между Mac, iPhone и iPad через общий . На практике iCloud Keychain это действительно удобная и бесплатная альтернатива популярному . Но можно ли доверять ему свои пароли? И да и нет.

Настройка iCloud Keychain

Любопытные наверняка уже разобрались, как все работает и сами настроили синхронизацию. Проблемы могли возникнуть только у жителей Украины, Белоруссии или других стран, чей номер телефона нельзя ввести во время настройки. К счастью, есть хитрый способ обойти это ситуацию. Но перед тем как начать, убедитесь, что у вас стоит и iOS 7.0.3+.

1. Обойти отправку кода подтверждения на мобильный телефон можно, начав настройку не с Mac, а с iPhone/iPad . Для этого зайдите в Настройки → iCloud и активируйте там Связку ключей . Вам предложат использовать ваш пароль на iPhone/iPad в качестве кода безопасности для iCloud. Нажмите Создать другой код и затем выберите Дополнительные параметры .

2. Теперь выберите пункт Не создавать код безопасности и подтвердите своё решение. Это грозит лишь тем, что если вы потеряете Mac, iPhone и iPad то не сможете получить доступ к своим паролям в iCloud. Не беда, у нас же есть бэкапы? ;)

Дело в том, что без этого кода ваши пароли не попадут в iCloud, а будут просто синхронизироваться между авторизированными устройствами. Во всяком случае, так утверждает Apple у себя на сайте. А вот Джон Бродкин (Jon Brodkin) с Ars Technica доказал небольшим экспериментом, что это не так. Пароли все же где-то хранятся в iCloud, но восстановить их оттуда без кода не получится.

3. Окей, теперь откройте Системные настройки → iCloud на Maс и активируйте Связку ключей . Mac предложит отправить запрос на первое активированное устройство. Соглашайтесь.

4. Через мгновение на ваш iPhone придет запрос на разрешение вашему Mac использовать iCloud Keychain. Здесь нужно ввести пароль от iCloud. Каждая следующая активация будет отправлять запрос на предыдущее устройство. Такая себе карусель.

5. Чтобы автозаполнение паролей заработало в мобильном Safari, зайдите в Настройки → Safari → Пароли и автозаполнение и включите Имена и пароли . В меню Сохраненные пароли можно посмотреть список всего, что есть в Связке ключей.

Со скучной частью мы закончили. Теперь отправляйтесь в мобильный Safari и наслаждайтесь автозаполнением паролей.

Безопасность iCloud Keychain

Теперь посмотрим, насколько безопасен iCloud Keychain. Оказывается, здесь полный караул! Если вы ранее активировали автозаполнение на iOS, то любой, кто возьмёт в руки телефон, может свободно залогинитьься под вашими аккаунтами из Safari. Да, так же происходит и на Mac, но незаметно «пошарить» на компьютере и телефоне - разные вещи.

Ещё опаснее, когда в вашем телефоне нет кода на разблокировку. В этом случае, любой желающий увидит все пароли в настройках Safari. Оказывается, они хранятся в открытом виде.

Да, многие ставят пароль на включение iPhone, но подсмотреть его через плечо - раз плюнуть. Этот четырёхзначный код легко узнает любой смышлёный официант, просмотрев записи с камер наблюдений вашего любимого кафе.

Проблема с паролем на телефоне частично отсутствует разве что у владельцев iPhone 5S с их сенсором отпечатков пальцев. Если подсмотреть пароль легко, то вот так заморачиваться будут не многие:

Возможно, скоро Apple также разрешит создавать произвольный пароль (отличный от кода разблокировки) для доступа к мобильной Связке ключей. Это тоже сделает Связку ключей безопаснее. Если вы думаете, что для этого и предназначен код безопасности , от которого мы отказались выше, то это не так. Код безопасности нужен лишь при «вытягивании» паролей из iCloud.

Учитывая все вышесказанное, на Связку ключей iCloud можно «берегись», особенно при неправильной настройке. Пока же iCloud Keychain даёт злоумышленникам дополнительное пространство для маневра.

Как я использую iCloud Keychain

Разумеется, я не храню никакие пароли в iCloud Keychain. Все мои пароли надёжно спрятаны в и . Да, это не так удобно, но . При таком раскладе потеря телефона или планшета уже не грозит потерей очень важной информации. Даже если вор знает мой код разблокировки.

В то же время, iCloud Keychain у меня включён. Включён он потому, что кроме всего прочего, синхронизирует пароли от беспроводных сетей. Например, когда вы пришли в кафе и подключились к WiFi с Mac, то ваши iPad и iPhone подключатся к нему автоматически. Очень удобно!

От остальных паролей я избавился. Для этого зайдите в Связку ключей на Mac и удалите все, что считаете нужным. В идеале, ваш список паролей в настройках Safari на iOS должен остаться пустым. Разумеется, перед этим вы должны сохранить все важное в 1Password.

Если пароли сразу не пропадут с мобильных устройств, то выключите и снова включите Связку ключей в настройках iCloud Mac и обновление «протолкнётся» на все устройства.

Чтобы там больше ничего не появлялось, научитесь игнорировать предложения OS X и iOS сохранять что-либо в Связку ключей из Safari. Для большей надёжности можете и там и там отключить опции автозаполнения паролей.

Для меня единственная польза iCloud Keychain лишь в синхронизации паролей от беспроводных точек доступа. В остальном я отдаю предпочтение .

Твитнуть

Безопасное хранение паролей и их синхронизация между устройствами - задача непростая. Около года назад Apple представила миру iCloud Keychain, свое централизованного хранилище паролей в OS X и iOS. Давай попробуем разобраться, где и как хранятся пароли пользователей, какие потенциальные риски это несет и имеет ли Apple техническую возможность получить доступ к расшифрованным данным, хранящимся на ее серверах. Компания утверждает, что такой доступ невозможен, но, чтобы это подтвердить или опровергнуть, необходимо разобраться, как работает iCloud Keychain.

iCloud 101

На самом деле iCloud - это не один сервис, это общее маркетинговое название для целого ряда облачных сервисов от Apple. Это и синхронизация настроек, документов и фотографий, и Find My Phone для поиска потерянных или похищенных устройств, и iCloud Backup для резервного копирования в облако, и теперь вот iCloud Keychain для безопасной синхронизации паролей и номеров кредитных карт между устройствами на базе iOS и OS X.

Каждая служба iCloud расположена на собственном домене третьего уровня, таком как pXX-keyvalueservice.icloud.com, где XX - номер группы серверов, отвечающих за обработку запросов текущего пользователя; для различных Apple ID этот номер может быть разным; более новые учетные записи обычно имеют большее значение этого счетчика.

Код безопасности iCloud

Прежде чем погружаться в анализ iCloud Keychain, обратим внимание на то, каким образом эта служба конфигурируется. При включении iCloud Keychain пользователю предлагается придумать и ввести код безопасности iCloud (iCloud Security Code, далее - iCSC). По умолчанию форма ввода позволяет использовать четырехзначный цифровой код, но, перейдя по ссылке «Дополнительные параметры», все же можно использовать более сложный код или вовсе позволить устройству сгенерировать стойкий случайный код.

Теперь мы знаем, что данные в iCloud Keychain защищены с помощью iCSC. Ну что же, попробуем разобраться, как именно эта защита реализована!

Перехват трафика или man-in-the-middle

Первым шагом при анализе сетевых сервисов зачастую является получение доступа к сетевому трафику между клиентом и сервером. В случае с iCloud для нас есть две новости: плохая и хорошая. Плохая состоит в том, что весь (ну или по крайней мере подавляющая его часть) трафик защищен TLS/SSL, то есть он зашифрован и обычной пассивной атакой «прочитать» его не удастся. Хорошая же новость заключается в том, что Apple сделала всем желающим поисследовать iCloud подарок и не использует фиксацию сертификата (certificate pinning), что позволяет достаточно просто организовать атаку «человек посередине» (man-in-the-middle) и расшифровывать перехваченный трафик. Для этого достаточно:

1. Поместить подопытное iOS-устройство в одну Wi-Fi-сеть с компьютером, осуществляющим перехват.

1. Установить на компьютере перехватывающий прокси-сервер (такой как Burp, Charles Proxy или любой аналогичный).

1. Импортировать на iOS-устройство TLS/SSL-сертификат установленного прокси-сервера (подробности в справке конкретного прокси).

1. В настройках Wi-Fi-сети на iOS-устройстве (Настройки → Wi-Fi → Имя сети → HTTP Прокси) указать IP-адрес перехватывающего компьютера в Wi-Fi-сети и порт, на котором слушает прокси-сервер.

Если все сделано правильно, то весь трафик между устройством и iCloud’ом будет как на ладони. И из перехвата этого трафика будет отчетливо видно, что iCloud Keychain построен на базе двух сервисов iCloud: com.apple.Dataclass.KeyValue и com.apple.Dataclass.KeychainSync - и при первоначальном, и при повторном включениях на других устройствах iOS обменивается данными с этими сервисами.

Первый сервис не нов и был в числе первых возможностей iCloud; он широко используется приложениями для синхронизации настроек. Второй же является новым и разработан, очевидно, специально для iCloud Keychain (хотя его функционал теоретически позволяет использовать его и для других целей). Рассмотрим эти сервисы подробнее.

com.apple.Dataclass.KeyValue

Как было отмечено выше, это один из сервисов, используемых iCloud Keychain. Многие существующие приложения используют его для синхронизации небольших объемов данных (настройки, закладки и тому подобное). Каждая сохраняемая этой службой запись ассоциируется с идентификатором приложения (Bundle ID) и именем хранилища (store). Соответственно, для получения сохраненных данных от сервиса также необходимо предоставить эти идентификаторы. В рамках iCloud Keychain данный сервис используется для синхронизации записей Keychain в зашифрованном виде. Достаточно подробно этот процесс описан в документе iOS Security в разделах Keychain syncing и How keychain syncing works.

Синхронизация Keychain

Когда пользователь впервые включает iCloud Keychain, устройство создает «круг доверия» (circle of trust) и ключи синхронизации (syncing identity, состоит из открытого и закрытого ключей) для текущего устройства. Открытый ключ этой пары помещается в «круг доверия», и этот «круг» дважды подписывается: сперва закрытым ключом синхронизации устройства, а затем асимметричным ключом (основанным на эллиптической криптографии), полученным из пароля пользователя на iCloud. Также в «круге» сохраняются параметры для вычисления ключа из пароля, такие как соль и количество итераций.

Подписанный «круг» сохраняется в Key/Value-хранилище. Он не может быть прочитан без знания пользовательского пароля iCloud и не может быть изменен без знания закрытого ключа одного из устройств, добавленных в «круг».

Когда пользователь включает iCloud Keychain на другом устройстве, это устройство обращается к Key/Value-хранилищу в iCloud и замечает, что у пользователя уже есть «круг доверия» и что новое устройство в него не входит. Устройство генерирует ключи синхронизации и квитанцию для запроса членства в «круге». Квитанция содержит открытый ключ синхронизации устройства и подписана ключом, полученным из пользовательского пароля iCloud с использованием параметров генерации ключа, полученных из Key/Value-хранилища. Подписанная квитанция затем помещается в Key/Value-хранилище.

Первое устройство видит новую квитанцию и показывает пользователю сообщение о том, что новое устройство запрашивает добавление в «круг доверия». Пользователь вводит пароль iCloud, и подпись квитанции проверяется на корректность. Это доказывает, что пользователь, генерировавший запрос на добавление устройства, ввел верный пароль при создании квитанции.

После того как пользователь подтвердит добавление устройства к «кругу», первое устройство добавляет открытый ключ синхронизации нового устройства в «круг» и вновь дважды подписывает его при помощи своего закрытого ключа синхронизации и при помощи ключа, полученного из пароля iCloud-пользователя. Новый «круг» сохраняется в iCloud, и новое устройство аналогичным образом подписывает его.

Как работает синхронизация Keychain

Теперь в «круге доверия» два устройства, и каждое из них знает открытые ключи синхронизации других устройств. Они начинают обмениваться записями Keychain через Key/Value-хранилище iCloud. В случае если одна и та же запись присутствует на обоих устройствах, то приоритет будет отдан имеющей более позднее время модификации. Если время модификации записи в iCloud и на устройстве совпадают, то запись не синхронизируется. Каждая синхронизируемая запись зашифровывается специально для целевого устройства; она не может быть расшифрована другими устройствами или Apple. Кроме того, запись не хранится в iCloud постоянно - она перезаписывается новыми синхронизируемыми записями.

Этот процесс повторяется для каждого нового устройства, добавляемого в «круг доверия». Например, если к «кругу» добавляется третье устройство, то запрос подтверждения будет показан на двух других устройствах. Пользователь может подтвердить добавление на любом из них. По мере добавления новых устройств каждое устройство из «круга» синхронизируется с новыми, чтобы убедиться, что набор записей на всех устройствах одинаков.

Необходимо заметить, что синхронизируется не весь Keychain. Некоторые записи привязаны к устройству (например, учетные записи VPN) и не должны покидать устройство. Синхронизируются только записи, имеющие атрибут kSecAttrSynchronizable. Apple установила этот атрибут для пользовательских данных Safari (включая имена пользователей, пароли и номера кредитных карт) и для паролей Wi-Fi.

Кроме того, по умолчанию записи сторонних приложений также не синхронизируются. Для их синхронизации разработчики должны явным образом установить атрибут kSecAttrSynchronizable при добавлении записи в Keychain.

iCloud Keychain оперирует двумя хранилищами:

• com.apple.security.cloudkeychainproxy3

• com.apple.sbd3

Первое хранилище предположительно используется для поддержания списка доверенных устройств (устройств в «круге доверия», между которыми разрешена синхронизация паролей), для добавления новых устройств в этот список и для синхронизации записей между устройствами (в соответствии с механизмом, описанным выше).

Второе же хранилище предназначено для резервного копирования и восстановления записей Keychain на новые устройства (например, когда в «круге доверия» нет других устройств) и содержит зашифрованные записи Keychain и сопутствующую информацию.

Таким образом, записи Keychain хранятся в обычном Key/Value-хранилище (com.apple.securebackup.record). Эти записи зашифрованы с помощью набора ключей, хранящегося там же (BackupKeybag). Но этот набор ключей защищен паролем. Откуда берется этот пароль? Что это за служба депонирования паролей Apple? Далее постараемся разобраться.

apple.Dataclass.KeychainSync

Это новый сервис, возник он относительно недавно: впервые его поддержка появилась в бета-версиях iOS 7, затем она отсутствовала в iOS 7.0–7.0.2 и была вновь добавлена в iOS 7.0.3, вышедшей одновременно с релизом OS X Mavericks. Это и есть упомянутая выше служба депонирования паролей (адрес службы - pXX-escrowproxy.icloud.com).

Служба предназначена для безопасного хранения пользовательских секретов и позволяет пользователю после успешной аутентификации восстановить эти секреты. Для успешной аутентификации необходимо следующее:

• токен аутентификации iCloud, получаемый в обмен на Apple ID и пароль при первичной аутентификации в iCloud (стандартный способ аутентификации для большинства сервисов iCloud);

• код безопасности iCloud (iCSC);

• шестизначный цифровой код, передаваемый серверами Apple на номер сотового телефона, ассоциированный с пользователем.

В теории все выглядит хорошо, но, чтобы определить, совпадает ли теория с практикой, нам потребуется провести аудит программы-клиента службы депонирования. В ОС iOS и OS X эта программа носит название com.apple.lakitu . Описание процесса ее реверсинга и аудита выходит за рамки статьи, поэтому сразу переходим к результатам.

Доступные команды

Аудит com.apple.lakitu позволяет определить список команд, реализуемых службой депонирования. На соответствующем скриншоте представлены команды и их описание. Особо хотелось бы остановиться на последней команде - с ее помощью возможно изменить номер телефона, ассоциированный с текущей учетной записью. Наличие этой команды делает многофакторную аутентификацию, используемую при восстановлении iCloud Keychain (пароль Apple ID + iCSC + устройство), заметно менее надежной, так как позволяет исключить один из факторов. Интересно и то, что пользовательский интерфейс iOS не позволяет выполнить эту команду - в нем просто нет такой опции (по крайней мере я ее не нашел).

Особенность данной команды, отличающая ее от всех прочих, в том, что она требует аутентификации с паролем Apple ID и не будет работать, если для аутентификации используется токен iCloud (прочие команды работают при аутентификации по токену). Это служит дополнительной защитой данной команды и показывает, что проектировщики системы предприняли шаги для повышения ее безопасности. Тем не менее не до конца ясно, зачем эта команда вообще присутствует в системе.

Восстановление депонированных данных

Для получения депонированных данных выполняется следующий протокол:

1. Клиент запрашивает список депонированных записей (/get_records).

1. Клиент запрашивает ассоциированный телефонный номер, на который сервером будет направлен код подтверждения (/get_sms_targets).

1. Клиент инициирует генерацию и доставку кода подтверждения (/generate_sms_challenge).

1. После того как пользователь ввел iCSC и код подтверждения из SMS, клиент инициирует попытку аутентификации с использованием протокола SRP-6a (/srp_init).

1. После получения ответа от сервера клиент производит вычисления, предписанные протоколом SRP-6a, и запрашивает депонированные данные (/recover).

1. В случае если клиент успешно аутентифицировался, сервер возвращает депонированные данные, предварительно зашифровав их на ключе, выработанном в процессе работы протокола SRP-6a (если протокол отработал успешно, то и сервер, и клиент вычислили этот общий ключ).

Важно отметить, что номер телефона, полученный на шаге 2, используется исключительно для нужд пользовательского интерфейса, то есть чтобы показать пользователю номер, на который будет отправлен код подтверждения, и на шаге 3 клиент не передает серверу номер, на который следует отправлять код подтверждения.

Secure Remote Password

На шаге 4 клиент начинает выполнение протокола SRP-6a. Протокол SRP (Secure Remote Password) - это протокол парольной аутентификации, защищенный от прослушивания и man-in-the-middle атак. Таким образом, например, при использовании этого протокола невозможно перехватить хеш пароля и затем пытаться восстановить его, просто потому, что никакой хеш не передается.

Apple использует наиболее совершенный вариант протокола, SRP-6a. Этот вариант предписывает разрывать соединение при неудачной аутентификации. Кроме того, Apple позволяет лишь десять неудачных попыток аутентификации для данного сервиса, после чего все последующие попытки блокируются.

Подробное описание протокола SRP и его математических основ выходит за рамки статьи, но для полноты изложения ниже представлен частный вариант, используемый службой com.apple.Dataclass.KeychainSync .

В качестве хеш-функции H используется SHA-256 , а в качестве группы (N , g) - 2048-битная группа из RFC 5054 «Using the Secure Remote Password (SRP) Protocol for TLS Authentication». Протокол выполняется следующим образом:

1. Устройство генерирует случайное значение a , вычисляет A=g^a mod N , где N и g - параметры 2048-битной группы из RFC 5054 , и отправляет на сервер сообщение, содержащее идентификатор пользователя ID , вычисленное значение A и код подтверждения из SMS. В качестве идентификатора пользователя используется значение DsID - уникальный числовой идентификатор пользователя.
2. Получив сообщение, сервер генерирует случайное значение b и вычисляет B=k*v + g^b mod N , где k - множитель, определенный в SRP-6a как k=H(N, g) , v=g^H(Salt, iCSC) mod N - верификатор пароля, хранящийся на сервере (аналог хеша пароля), Salt - случайная соль, сгенерированная при создании учетной записи. Сервер отправляет клиенту сообщение, содержащее B и Salt .
3. Путем несложных математических преобразований клиент и сервер вычисляют общий сессионный ключ K . На этом первая часть протокола - выработка ключа - завершена, и теперь клиент и сервер должны убедиться, что они получили одно и то же значение K .
4. Клиент вычисляет M=H(H(N) XOR H(g) | H(ID) | Salt | A | B | K) , доказательство того, что он знает K , и отправляет на сервер M и код подтверждения из SMS. Сервер также вычисляет M и сравнивает полученное от клиента и вычисленное значения; если они не совпадают, то сервер прекращает выполнение протокола и разрывает соединение.
5. Сервер доказывает клиенту знание K путем вычисления и отправки H(A, M, K) . Теперь оба участника протокола не только выработали общий ключ, но и убедились, что этот ключ одинаков у обоих участников. В случае со службой депонирования сервер также возвращает случайный вектор инициализации IV и депонированную запись, зашифрованную на общем ключе K с использованием алгоритма AES в режиме CBC .

Использование SRP для дополнительной защиты пользовательских данных, на мой взгляд, существенно улучшает безопасность системы от внешних атак хотя бы потому, что позволяет эффективно противостоять попыткам перебора iCSC: за одно подключение к сервису можно попробовать только один пароль. После нескольких неудачных попыток учетная запись (в рамках работы со службой депонирования) переводится в состояние soft lock и временно блокируется, а после десяти неудачных попыток учетная запись блокируется окончательно и дальнейшая работа со службой депонирования возможна только после сброса iCSC для учетной записи.

В то же время использование SRP никак не защищает от внутренних угроз. Депонированный пароль хранится на серверах Apple, соответственно, можно предположить, что Apple может при необходимости получить к нему доступ. В таком случае, если пароль не был защищен (например, зашифрован) до депонирования, это может привести к полной компрометации записей Keychain, сохраненных в iCloud, так как депонированный пароль позволит расшифровать ключи шифрования, а они - записи Keychain (обрати внимание на com.apple.Dataclass.KeyValue).

Однако в документе «iOS Security» Apple утверждает, что для хранения депонированных записей используются специализированные аппаратные модули безопасности (Hardware Security Module, HSM) и что доступ к депонированным данным невозможен.

Безопасность депонирования

iCloud предоставляет защищенную инфраструктуру для депонирования Keychain, обеспечивающую восстановление Keychain только авторизованными пользователями и устройствами. Кластеры HSM защищают депонированные записи. Каждый кластер имеет собственный ключ шифрования, использующийся для защиты записей.

Для восстановления Keychain пользователь должен аутентифицироваться, используя имя пользователя и пароль iCloud, и ответить на присланное SMS. Когда это выполнено, пользователь должен ввести код безопасности iCloud (iCSC). Кластер HSM проверяет корректность iCSC, используя протокол SRP; при этом iCSC не передается на серверы Apple. Каждый узел кластера, независимо от других, проверяет, не превысил ли пользователь максимально допустимое количество попыток получения данных. Если на большей части узлов проверка завершается успешно, то кластер расшифровывает депонированную запись и возвращает ее пользователю.

Далее устройство использует iCSC, чтобы расшифровать депонированную запись и получить пароль, использованный для шифрования записей Keychain. При помощи этого пароля Keychain, полученная из Key/Value-хранилища, расшифровывается и восстанавливается на устройство. Допускается лишь десять попыток аутентификации и получения депонированных данных. После нескольких неудачных попыток запись блокируется, и пользователь должен обратиться в службу поддержки для разблокировки. После десятой неудачной попытки кластер HSM уничтожает депонированную запись. Это обеспечивает защиту от брутфорс-атак, направленных на получение записи.

К сожалению, проверить, используются ли HSM на самом деле, не представляется возможным. Если все действительно так и HSM не позволяют прочитать хранящиеся в них данные, то можно утверждать, что данные iCloud Keychain защищены и от внутренних угроз. Но, повторюсь, к сожалению, доказать или опровергнуть использование HSM и невозможность чтения данных из них нельзя.

Остается еще один способ защиты данных от внутренней угрозы - защита депонируемых данных на устройстве перед передачей на серверы Apple. Из описания Apple следует (и реверсинг это подтверждает), что такая защита применяется - депонируемый пароль предварительно зашифровывается при помощи iCSC. Очевидно, что в этом случае уровень безопасности (от внутренней угрозы) напрямую зависит от сложности iCSC и четырехсимвольный iCSC, используемый по умолчанию, не обеспечивает достаточной защиты.

Итак, мы выяснили, как работают отдельные элементы системы, и теперь самое время посмотреть на систему целиком.

Putting it all Together

На схеме представлена работа iCloud Keychain в части депонирования и восстановления записей Keychain. Система работает следующим образом:

1. Устройство генерирует набор случайных ключей (в терминологии Apple - keybag) для шифрования записей Keychain.
2. Устройство зашифровывает записи Keychain (имеющие установленный атрибут kSecAttrSynchronizable) с помощью набора ключей, сгенерированного на предыдущем шаге, и сохраняет зашифрованные записи в Key/Value-хранилище com.apple.sbd3 (ключ com.apple.securebackup.record).
3. Устройство генерирует случайный пароль, состоящий из шести групп по четыре символа (энтропия такого пароля - около 124 бит), зашифровывает набор ключей, сгенерированный на шаге 1, при помощи этого пароля и сохраняет зашифрованный набор ключей в Key/Value-хранилище com.apple.sbd3 (ключ BackupKeybag).
4. Устройство зашифровывает случайный пароль, сгенерированный на предыдущем шаге, с помощью ключа, полученного из кода безопасности iCloud пользователя, и депонирует зашифрованный пароль службе com.apple.Dataclass.KeychainSync .

При настройке iCloud Keychain пользователь может применять сложный или случайный iCSC вместо предлагаемого по умолчанию четырехзначного кода. В случае использования сложного кода механизм работы системы депонирования не меняется; отличие лишь в том, что ключ для шифрования случайного пароля будет вычислен не из четырехзначного iCSC, а из более сложного, введенного пользователем.

При случайном коде подсистема депонирования пароля не используется вообще. При этом случайный пароль, сгенерированный системой, и является iCSC, и задача пользователя его запомнить и безопасно хранить. Записи Keychain все так же зашифровываются и сохраняются в Key/Value-хранилище com.apple.sbd3 , но служба com.apple.Dataclass.KeychainSync не используется.

Выводы

Можно смело утверждать, что с технической точки зрения (то есть social engineering не рассматриваем) и по отношению к внешним угрозам (то есть не Apple) безопасность службы депонирования iCloud Keychain находится на достаточном уровне: благодаря использованию протокола SRP даже при компрометации пароля iCloud злоумышленник не сможет получить доступ к записям Keychain, так как для этого дополнительно необходим код безопасности iCloud, а перебор этого кода существенно затруднен.

В то же время, используя другой механизм iCloud Keychain - синхронизацию паролей, злоумышленник, скомпрометировавший пароль iCloud и имеющий непродолжительный физический доступ к одному из устройств пользователя, может полностью скомпрометировать и iCloud Keychain: для этого достаточно добавить устройство злоумышленника в «круг доверия» устройств пользователя, а для этого достаточно знать пароль iCloud и иметь кратковременный доступ к устройству пользователя, чтобы подтвердить запрос на добавление нового устройства к «кругу».

Если же рассматривать защиту от внутренних угроз (то есть Apple или кто-либо с доступом к серверам Apple), то в этом случае безопасность службы депонирования выглядит не так радужно. Утверждения Apple об использовании HSM и невозможности чтения данных из них не имеют неопровержимых доказательств, а криптографическая защита депонируемых данных завязана на код безопасности iCloud, при настройках по умолчанию является крайне слабой и позволяет любому, кто в состоянии извлечь с серверов (или из HSM) Apple депонированные записи, практически моментально восстановить четырехзначный код безопасности iCloud.

В случае использования сложного алфавитно-цифрового кода эта атака становится сложнее, так как возрастает количество возможных паролей. Если же iCloud Keychain сконфигурирован использовать случайный код, то служба депонирования вообще не привлекается, что фактически делает этот вектор атаки невозможным.

Максимальный уровень безопасности (не считая полного отключения iCloud Keychain, конечно) обеспечивается при использовании случайного кода - и не столько потому, что такой код сложнее подобрать, сколько потому, что при этом не задействована подсистема депонирования паролей, а следовательно, уменьшается и attack surface. Но удобство этого варианта, конечно, оставляет желать лучшего.

Как много людей сегодня доверяют компьютерам и смартфонам? Практически все в них хранят фотографии, сведения о местоположении, нередко данные и коды с кредитных карт и бесчисленное количество паролей.

Последние являются основным механизмом защиты в интернете, за ними хранится доступ ко всему тому, что пользователь наверняка хотел бы скрыть, а значит, они должны быть продвинутыми и трудноподбираемыми. Количество таких паролей накапливается, переваливает за сотню, и вот никто уже не в силах вспомнить их.

Для защиты и надежного хранения всей этой информации компанией Apple был придуман инструмент под названием Keychain ("Связка ключей").

Что такое "Связка ключей"?

По своей сути это менеджер паролей, разработанный компанией Apple специально для своей операционной системы. Данный инструмент был представлен вместе с релизом Mac OS 8-й итерации, вышедшей в 1998 году. После данная утилита была частью каждого релиза Apple, в том числе OS X и iOS (с 2013 года именуется как “Связка ключей iCloud”).

Она на Mac способна хранить данные различного характера, например: пароли от веб-сайтов, FTP-серверов, SSH-аккаунтов, общих сетей, беспроводных сетей, скрытых заметок, общего программного обеспечения и оборудования, а также для сертификатов и зашифрованных образов диска.

История продукта

Изначально похожий механизм использовался в приложении PowerTalk, которое представляло собой почтовый клиент от Apple. Приложение было создано еще в ранних 90-х, а Keychain помогала контролировать все пользовательские данные из различных почтовых служб, к которым мог подключить PowerTalk.

В связи с использованием шифрования пароли было трудно запомнить и восстановить. Посему был необходим механизм, который позволял бы вводить пользователю лишь один пароль (мастер-пароль), открывающий доступ ко всем почтовым службам (у каждой из которых свои входные данные и пароли).

Данная идея, несмотря на свою очевидность и полезность, практически умерла в тот момент, когда в Apple решили прекратить поддержку PowerTalk. Но с возвращением Стива Джобса данная функция вернулась в и работала не только в одной программе, но и в системе целиком.

Хранилище и доступ

В операционных системах Mac 10-го поколения и старше все Keychain-файлы хранятся в специальной директории системы, также эти данные можно найти в специальном приложении, которое расположено в папке “Утилиты”.

«Связка ключей» представляет собой бесплатное и свободное ПО (исходный код утилиты имеется в свободном доступе), которое распространяется по публичной лицензии компании Apple.

Keychain-файл хранит в себе массу информации, из нее зашифроваными являются лишь заметки и пароли, все остальное (названия, ссылки) доступно всем.

Блокировка и разблокировка

По умолчанию, Keychain-файл защищен тем же паролем, что и поэтому функция становится доступна сразу после входа под своим логином и паролем. При необходимости его для этой функции можно установить отдельно.

Также для большей безопасности можно установить интервал блокировки, например, в 15 минут. В таком случае, если компьютер не использовался в течение 15 минут, при попытке воспользоваться "Связкой ключей" он затребует пароль.

"Связка ключей

Данный продукт компания Apple анонсировала спустя 15 лет после появления оригинальной "Связки ключей". В 2013 году на конференции WWDC вместе с iOS 7 версии и OS X Mavericks была представлена технология, позволяющая синхронизировать все засекреченные данные пользователя и надежно сохранить их.

Данная опция является неким онлайн-хранилищем, в котором находятся все пользовательские данные, в число которых входят: пароли от веб-страниц, пароли от беспроводных сетей, информация об учетных записях и платежные данные кредитных карт (за исключением кодов безопасности - CVV).

Все эти данные зашифрованы по стандарту AES 256-bit и доступны лишь конкретному пользователю и только в и приложенях, адаптированных для работы с этой утилитой (они отправляют запрос в Safari, браузер проверяет соответствие ссылок и предлагает приложению пароль, ранее сохраненный в системе).

Также в возможности сервиса входит составление длинных, сложных и безопасных паролей для сайтов, на которых регистрируется пользователь.

"Связка ключей

Начать работать со «Связкой ключей iCloud» совсем нетрудно, но в первую очередь нужно убедиться, что на гаджете (смартфоне или планшете) установлена iOS 7.0.3 и новее, а на компьютере - OS X 10.9 и новее.

Настройка «Связки ключей iCloud» (инструкция для Mac):

• Для начала необходимо запустить “Настройки” (либо из меню Apple, которое кроется за иконкой яблока в верхнем левом углу, либо из Dock).
• Выбрать подменю iCloud.
• Ввести пароль для разблокировки компьютера.
• Ввести данные Apple ID.

Как добавить в «Связку ключей» кредитную карту (инструкция для Mac):

• Необходимо запустить программу Safari.
• Затем зайти в настройки этой программы.
• В настройках выбрать подменю Autofill (автозаполнение).
• Рядом с подпунктом “Кредитные карты” найти кнопку “Редактировать”.
• Нажать на кнопку “Добавить” и ввести данные кредитной карты.

Как настроить «Связку ключей iCloud» (инструкция для iOS):

• Выбрать подменю iCloud.
• Затем подпункт "Связка ключей".
• Переместить тумблер "Связка ключей iCloud" в положение ON (Вкл.). Соответственно для выключения нужно провести обратное действие, переключить тумблер в положение OFF (Выкл.).
• После этого будет предложено придумать новый пароль или ввести существующий (код безопасности «Связки ключей iCloud» для активации), а также прикрепить сторонние гаджеты для подтверждения.

• Необходимо запустить “Настройки” с экрана “Домой”.
• Выбрать подменю Safari.
• Затем подпункт Password & AutoFill (Пароли и автозаполнение).
• Ввести код-пароль.
• Выбрать подменю Saved Credit Cards (Сохраненные кредитные карты).
• Добавить кредитную карту (ввести нужную информацию и нажать “Готово”).

Синхронизация паролей

Синхронизация данных в Связке ключей не является необходимой опцией. Более того, синхронизировать данные можно минуя iCloud (только на компьютерах Mac).

Чтобы избежать синхронизации данных с облаком и их последующего там хранения, во время активации "Связки ключей" нужно пропустить этап с созданием проверочного шестизначного кода. В этом случае все данные будут храниться лишь на физическом носителе, локально.

Также возможна синхронизация данных с помощью файлов, хранящихся в /Library/Keychains/. Обычно подобное используется в корпоративных сетях и при наличии нескольких общих компьютеров Mac. К сожалению, синхронизация нередко пропадает при смене пароля в системе на одном из устройств (в том числе Windows).

Доступ к "Связке ключей"

Перед тем как получить всю информацию, хранящуюся в облаке, следует подтвердить «Связку ключей iCloud». Это можно делать с помощью SMS или второго устройства.

В первом случае пользователь получит случайно сгенерированный код-пароль для подтверждения личности или полноценной активации функции "Связка ключей iCloud". Подтвердить с другого устройства можно в том случае, если у пользователя имеется гаджет, на котором уже работает данная функция.

Код безопасности

Это специальный шифр, состоящий из 6 цифр, либо из усложненной буквенно-числовой комбинации, который необходим для того, чтобы получить доступ к паролям и картам, хранящимся в "Связке ключей", а также в случае потери доступа к ней.

Возможные проблемы

Ничто не идеально, даже «Связка ключей iCloud». Нет, речь идет не о дырах в безопасности или потере данных, но существует немало проблем, связанных с подключением данной функции и возвращением доступа после обновления, сброса и настройки нового устройства. Список самых распространенных вопросов и проблем представлен ниже.

«Связку ключей iCloud» не удалось настроить в связи с отсутствием СМС-кода? Если по какой-то причине СМС-сообщение с кодом-паролем не приходит, необходимо:

• Проверить соединение с сотовой сетью.
• Убедиться в том, что телефон способен получать СМС (тарифный план и установленная СИМ-карта поддерживают эту возможность).
• Проверить, тот ли номер указан для получения СМС-кода. Для этого в настройках "Связки ключей" найти подпункт “Дополнительно” и указать верный номер в пункте “Проверочный номер”.

«Связка ключей iCloud» не синхронизирует данные между устройствами. В этом случае почти всегда помогает полное отключение и включение функции. Сделать это необходимо на всех устройствах. После повторного включения все они получат наиболее актуальные данные с сервера и продолжат работать в обычном режиме.

Не получается найти пароли, сохраненные в «Связку ключей iCloud»? Данные о них и кредитных картах, сохраненных в облаке, можно найти следующим образом:

• Перейти в “Настройки” с экрана “Домой”.
• Выбрать подменю Safari.
• Затем подпункт Passwords (Пароли).
• Система потребует ввести пароль или воспользоваться Touch ID (дактилоскопическим сенсором) для подтверждения личности.
• После проверки можно выбрать любой сайт и посмотреть пароль к нему.

Safari не сохраняет данные в «Связку ключей» и не предлагает подстановку паролей. Данную проблему можно решить, активировав тумблер “Имена и пароли” в подменю “Автозаполнение” в настройках Safari.

Поддерживаемые устройства

«Связка ключей iCloud» поддерживается на всех актуальных устройствах Apple. В их число входят все компьютеры, которые работают на базе операционной системы macOS поколения Mavericks и новее (почти все ПК 2007 года выпуска и более современные).

Также данная функция работает на ряде мобильных устройств (всех, на которые можно установить мобильную операционную систему версии 7.0.3). В их число входят: iPhone с 4-го поколения и более современные, iPad со 2-го поколения и более современные, с 5-го поколения и более современные.

• Перевод

Компания Apple выпустила серьезное обновление к своей официальной документации по безопасности iOS для ИТ-профессионалов. Оно содержит намного больше информации по безопасности iOS, чем компания когда-либо разглашала общественности ранее, включая расширенное описание Touch ID, защиты данных, безопасности сетей, безопасности приложений и почти всех связанных с безопасностью функций, опций и protective controls.

Впервые мы получили расширенное описание безопасности iCloud. Для профессионалов в вопросах безопасности, к которым я отношусь, это сродни тому, чтобы проснуться и увидеть мешок золота на клавиатуре. Помимо одного из наиболее впечатляющих отчетов по безопасности из когда-либо мне доступных, Apple снабдила документацию информацией о том, как сделать невозможным доступ к связке ключей iCloud таких организаций, как АНБ.

Документация невероятно информативная, уровень детализации иногда доходит до описания того, какие особенности конкретных алгоритмов шифрования используются в указанных security controls. Я, по всей вероятности, буду изучать ее несколько месяцев, однако прямо сейчас стоит обратить внимание на одну секцию, которая содержит крайне ценную и важную информацию, которая объясняет, почему АНБ не может шпионить за вами, используя ваши пароли из связки ключей iCloud.

Базовая информация о связке ключей iCloud – связка ключей имеет три важные особенности, а именно, способности:

• Создавать сильные, составленные случайным образом пароли для веб-сайтов прямо внутри Safari
• Синхронизировать вашу связку ключей (то есть хранимые в ней пароли) на разных устройствах
• Создавать и хранить резервную копию связки ключей на серверах Apple

Это значит, что Apple нужно хранить резервную копию вашей связки ключей. В свете недавно появившейся боязни оказаться «под колпаком» государственной слежки, перспектива доверить ключи от вашей цифровой жизни крупной компании становится пугающей.

Apple использует пусть и похожие, но все же несколько иные методы обеспечения безопасности для защиты как синхронизации, так и временного хранения и восстановления (из резервной копии) связки ключей. По словам самой компании:

Компания Apple спроектировала iCloud Keychain и Keychain Recovery, что позволяет защищать пароли пользователей в следующих условиях:

• Когда скомпрометирован аккаунт пользователя в iCloud
• Когда iCloud скомпрометирован под воздействием внешней атаки или действий сотрудников компании
• Когда доступ к аккаунту пользователя получают третьи лица

К этому моменту у iCloud уже есть открытый ключ с вашего устройства, зашифрованный вашим паролем от iCloud и подписанный (так, чтобы никто не мог подделать или изменить его) закрытым ключом с вашего устройства, однако ваша связка ключей находится не в iCloud.

Когда подтверждается наличие нового устройства, тот же процесс происходит на нем и подтвержденный открытый ключ подписывается и добавляется в круг доверия на каждом устройстве и в iCloud (с использованием еще большего количества процедур шифрования). Это связано с уведомлениями, которые отправляются на устройства, уже находящиеся в круге доверия, и с увеличением количества криптографических подписей, для того, чтобы убедиться, что никто другой не может обойти процедуру и зарегистрировать собственное устройство.

Когда пароли добавлены или изменены, Apple синхронизирует только отдельные элементы связки ключей с другими устройствами, которым нужны обновления, по одному в единицу времени. Другими словами, каждый элемент связки ключей посылается на каждое устройство, которому он необходим, при этом элемент связки ключей зашифрован так, что только это конкретное устройство может его прочесть, и только один элемент связки ключей проходит через iCloud в единицу времени.

Чтобы прочесть его, атакующему понадобится скомпрометировать одновременно ключ устройства-получателя и ваш пароль в iCloud. Или изменить архитектуру всего процесса так, чтобы пользователь об этом ничего не узнал. Даже злонамеренным сотрудникам Apple понадобилось бы скомпрометировать фундаментальную архитектуру iCloud в нескольких местах для тайного доступа к элементам вашей связки ключей. Даже заполучив ваше имя пользователя и пароль от iCloud, атакующий не сможет получить доступ к вашей связке ключей: ему понадобится устройство, находящееся в круге доверия, чтобы одобрить вхождение в круг еще одного девайса, кроме того, ему необходимо будет сделать так, чтобы вы не заметили уведомлений о новом устройстве, которые придут на все ваши девайсы из круга доверия.

Технически Apple может нарушить процедуры по злому умыслу или под давлением серьезной госструктуры, но все окажется не так-то просто: компания не сможет обойтись без внесения изменений в архитектуру (в части уведомлений и подтверждения устройств), кроме того теперь, когда детали процесса обнародованы, компании в таких условиях не удастся избежать юридической ответственности.

Secure Recovery – в отличие от синхронизации, во время которой в единицу времени задействован только один элемент из связки ключей, iCloud Keychain Recovery создает резервную копию всей связки ключей на iCloud.

Apple создала безопасный эскроу-сервис для работы над этим сложным процессом в условиях соблюдения повышенного уровня безопасности. Ваша цепочка ключей зашифрована сильным ключом и хранится в iCloud. Сильный ключ, необходимый для дешифровки, затем сам шифруется с помощью нового кода безопасности iCloud Security Code и открытого ключа специального аппарата шифрования, известного как HSM (Hardware Security Module, аппаратный модуль безопасности). В рамках работы в качестве аналитика по вопросам безопасности я много писал о модулях HSM – это прочные, высокобезопасные устройства, которые используются в банках, правительственных учреждениях и крупных корпорациях для управления шифрованием и ключами.

Это все довольно запутанно, но если упростить, то суть будет в следующем: только модуль HSM может прочесть ключ, зашифрованный с помощью iCloud Security Code, но поскольку модуль не содержит iCloud Security Code, он не может прочесть реальный ключ, использующийся для защиты связки ключей. Если все условия выполнены, HSM (а точнее кластер модулей HSM, на случай, если один из них выйдет из строя) выдаст ключ, который затем будет дешифрован с помощью iCloud Security Code. Только после этого ключ может быть использован, чтобы получить доступ к вашей цепочке ключей.

Не расстраиваетесь, если вам это показалось слишком сложным. Мне потребовалось время, чтобы все это уложить в голове, несмотря на четкую и понятную документацию от Apple и тот факт, что я зарабатываю на жизнь в том числе и консультируя HSM-вендоров.

В процессе восстановления потребуется еще и ваш номер телефона, поскольку в этом случае Apple присылает вам текстовое сообщение, на которое вы должны ответить. Кроме того, вам понадобятся ваш логин и пароль от iCloud для запроса восстановления и ваш iCloud Security Code для разблокировки ключей. Это три компонента, которые необходимы для доступа к связке ключей. Если кто-то попытается скомпрометировать ваш аккаунт и несколько раз потерпит неудачу, аккаунт будет заблокирован и разблокировать его можно будет только по звонку в службу поддержки Apple. Если после этого произойдет еще 10 попыток неудачного доступа, HSM уничтожит вашу эскроу-запись, навсегда скрывая доступ к вашим ключам.

Из соображений безопасности Apple уничтожила карты доступа администраторов к HSM и настроила модули на удаление всех ключей при обнаружении несанкционированного доступа. Все пользователи должны получить уведомление о повторной регистрации прежде, чем потеряют все свои ключи, а повторная регистрация переместит их в другой HSM-кластер.

Как я уже упоминал, в мою работу входит консультирование крупных компаний и вендоров продуктов, обеспечивающих безопасность. Я редко сталкивают с таким уровнем обеспечения безопасности, и особенно редко – с уничтожением смарт-карт администраторов, необходимых для доступа к HSM.

АНБ-непробиваемый сервис Keychain Recovery – несмотря на все это, существует вероятность того, что Apple может по приказу правоохранительных органов изменить процесс или скомпрометировать HSM-модули и использовать это для доступа к связкам ключей и всем хранимым в системе паролям. Однако, благодаря уничтожению карт доступа администраторов, это приведет только к перерегистрации пользователей.

Причина, по которой используются HSM-модули, заключается в том, что ни четырехзначное значение iCloud Security Code (по умолчанию), ни длинный пользовательский код (вторая опция) недостаточно хороши для генерации криптографически сильного ключа, потому, что в них недостаточно энтропии. Компания Apple была обеспокоена тем, что кто-либо мог угадать ваш iCloud Security Code, а HSM-модули и эскроу-процесс могут этому противостоять.

Поэтому Apple добавила третью опцию, чтобы позволить вашему устройству генерировать криптографически безопасный iCloud Security Code. Если вы выберете эту опцию при установке кода безопасности iCloud в процессе активации связки ключей iCloud (Настройки > iCloud > Связка ключей, активируйте связку ключей, а затем следуйте шагам со скриншотов), iCloud Keychain Recovery задействует совершенно другой процесс для защиты вашей связки ключей.

В этом случае ваше устройство будет генерировать абсолютно случайный код безопасности iCloud Security Code, который будет содержать так много энтропии, что вам не понадобятся модули HSM, поскольку его теоретически невозможно взломать методом грубой силы, используя текущие технику и технологии (а также технику и технологии, появление которых прогнозируется в ближайшем будущем). Выберите эту опцию, и исходный созданный случайным образом ключ, защищающий вашу связку ключей, будет зашифрован с помощью ключа, сгенерированного с использованием этого случайного кода безопасности iCloud Security Code – он не отсылается в Apple и не может быть перехвачен.

Без этого сгенерированного случайным образом кода безопасности iCloud Security Code (храните его в сервисе по управлению паролями, таком как

Связка ключей iCloud — незаменимый помощник в хранении важной и секретной информации. Все пароли сохраняться из приложения Safari в облачном хранилище. Не надо самими записывать или запоминать сложные пароли, связка ключей поможет все вспомнить и открыть.

При использовании приложения » связка ключей iCloud » введите код безопасности iCloud. Код может быть: шестизначный, численный или буквенно-цифровой, либо созданный автоматически. Этот код позволяет восстановить данные при потере устройства, а также выполнять определенные действия при идентификации пользователя. Это дополнительная защита, но код должен быть таким, чтобы вы его не забыли и запомнили. Если неправильно указать код, да ещё несколько раз, то произойдёт блокировка связки ключей на этом устройстве. Для возобновления работы обращайтесь в техническую службу Apple для установления личности и разблокировки.

При активации ключей можно не вводить код безопасности и пропустить этот шаг, тогда информация не будет храниться в облаке.

Настройка связки

При невозможности подтверждения входа из другого устройства в приложение на новом устройстве используйте код безопасности, после ввода которого, подтвердите по SMS подключение. На любом устройстве Apple для настройки приложения зайдите в меню «Настройка», выберете «iCloud», ищите приложение с ключами. При нажатии на иконку приложения появится переключатель, передвиньте его на включение. Введите пароль ID и продолжайте дальнейшие действия по инструкции. Теперь Вам доступна самая главная функция — автоматизация вводы любых паролей и кодов. Легко оплачивайте покупки, заходите на сайты, на почту не задумываясь.

Безопасность кредитных карт

В хранилище содержатся номера кредитных карт и сроки их действия. Цифры безопасности не остаются в памяти. При отключении приложения данные не стираются.

Некоторые проблемы при использовании приложения и пути их решения

Не получен код по SMS

• Убедитесь, что к учетной записи прикреплен именно этот номер телефона.
• Проверьте тарифный план, узнайте нет ли запрета SMS оповещения.

Проверить номер, который привязан к учетной записи зайдите в «Настройка» , выберите «связка ключей iCloud», зайдите во вкладку «Дополнительно» . В разделе «Проверочный номер» вписан телефонный номер.

Пароли от социальных сетей не отображаются на устройствах

В разделе «Настройки» откройте «Safari» и зайдите в «Автозаполнение». Проверьте работоспособность учетной записи «Имена и пароли». При выключении этой функции пароли не запоминаются. Затем нажмите «Домой» и проверьте «Safari». Если окно программы черное, то отключите режим «Частный доступ».

Иногда популярные веб — сайты не дают разрешение на сохранение пароля их посетителям, поэтому от них пароли не сохранятся.

При потере доступа к одному из устройств

При потере доступа к одному из устройств необходимо создать другой код безопасности. Зайдите в «Настройка», выберите приложение, зайдите во вкладку «Дополнительно». Выберите «Подтвердить с кодом безопасности» и выберите вкладку «Забыли код». Активируйте «Сбросить связку ключей». Подтверждайте свои действия и создавайте новый пароль.

Сообщение о смене кода

При появлении сообщения о смене кода безопасности, не игнорируйте его. Обновлять код безопасности не обязательно, но систему обновить надо. Если не выполнить этих действий, сообщение появится вновь. Если игнорировать это сообщение и не реагировать, отмечая «не сейчас», то после третьего отказа связка ключей будет выключена. Не будет происходить синхронизация на других устройствах, и восстановить через сайт работу приложения будет невозможно.

При появлении этого сообщения возможно провести обновление. Нажмите «создать» и выполняйте предложенные действия.

Введен неправильный код много раз

При введении несколько раз неправильного кода, связка будет отключена. Связка ключей в облаке просто удалится. Подтвердите это устройство через другое или сбросьте приложение.

Выключение службы на всех устройствах

Если выключить эту службу со всех устройств, то Ваша связка будет удалена из облака. Для возобновления работы, настройте службу заново.

При обновлении программного обеспечения любого устройства Apple необходимо перенастроить и программу связки. Для этого войдите в настройки iCloud и включите ключи, переместив бегунок. После этого следуйте инструкции и настройте своё устройство заново.

Безопасность

Компания Apple выполняет условие конфиденциальности и информация, полученная от пользователей их продукции не разглашается. Информация передается в зашифрованном виде, ключи не могут быть переданы кому-то другому. Информация о месте нахождения гаджета будет храниться не более суток в облаке, а потом безвозвратно удалится.

При возникновении проблем со связкой, проверьте настройки в устройстве.

Как снять пароль Apple ID?

Важно: всем владельцам техники Apple! Взлом Apple ID.

Основы работы с Mac: связка ключей iCloud для Mac

iOS 7: как посмотреть пароли, сохраненные в Связке ключей iCloud?

Как избавиться от окна разблокировки связки ключей в Ubuntu.

Избавляемся от назойливого окна о связке ключей в Chrome

Set up iCloud Keycain / Настройка связи ключей iCloud.

Setup iCloud Keychain in iOS 7.1 / Настройки Связки Ключей в iCloud на iOS 7.1

Set Up iCloud Keychain on iPad / Настройка связки ключей iCloud на iPad

RB140908 018 Apple латает дыры в облаках компания усилит безопасность iCloud РБК daily