Связка ключей iCloud. Настройка и использование

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

7 мин


Рассказал про свою пуленепробиваемую систему резервного копирования Mac’а. Фишка в том, что данные всегда существуют минимум в трех актуальных копиях.

11 мин


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

15 мин


В этой статье я расскажу, как протестировать производительность разных компонентов своего Mac: процессора, видеокарты и SSD. Результаты тестов помогут вам понять, что компьютер пора обслужить.

11 мин


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

11 мин


DaisyDisk - это визуализатор дискового пространства, который помогает быстро выявить проблемные зона на накопителе и парой кликов удалить все лишнее. Я использую его для ручной чистки дисков, сразу после автоматический чистки CleanMyMac X.

2 мин


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

8 мин


MobiMover - бесплатный файловый менеджер для Mac, который позволяет управлять контентом на iPhone и iPad без участия iTunes.

3 мин



3 мин


С середины лета 2018-го, Хакинтош стал моей основной рабочей машиной. Он быстрее любого iMac и MacBook Pro, а обошёлся в несколько раз дешевле. Хакинтошем я доволен. Но стоит ли вам делать что-то подобное? Вряд ли. И сейчас я расскажу почему.

5 мин


Раз в неделю я создаю загрузочный клон диска macOS. Это часть моей системы резервного копирования.

4 мин


Загрузочная флешка с macOS Mojave пригодится, если вы хотите переустановить систему с нуля, либо обновить сразу несколько домашних компьютеров.

3 мин


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

4 мин


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

5 мин


Рассказал, как лучше оптимизировать скриншоты в формате PNG, чтобы статьи в блоге весили меньше и загружались быстрее.

3 мин


Связка ключей — это функция Mac OS X, которая хранит пароли от различных приложений и других сервисов, использующихся на компьютере. Обычно, когда недавно установленная программа впервые обращается к Связке ключей , появляется диалоговое окно с просьбой ввести от неё пароль, и, после его ввода, повторно появляться оно уже не должно. Однако, случается так, что пароль требуется при каждом обращении программы к связке, что может сильно мешать комфортной работе. К счастью, есть несколько способов решить эту проблему.

Отключаем автоматическое закрытие связки ключей

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


Также может оказаться полезным включить отображение Связки ключей на вашей панели меню. Для этого откройте меню Связка ключей - Настройка - Основные и поставьте галочку напротив пункта «Показывать статус связки ключей в строке меню». После этого на панели меню у вас отобразится новый значок в виде замка, который будет открыт, если открыта связка ключей, и, соответственно, закрыт, если она заблокирована.

Проверяем и исправляем связку ключей

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


Отключаем и повторно подключаем Cвязку ключей в iCloud

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

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

Сброс связки ключей.

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

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

Огромное спасибо Кристоферу Кесслеру за материал , послуживший основой для написания этой статьи.

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

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

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

Общая информация

Связка ключей - это своеобразный менеджер, разработанный для операционной системы iOS и отвечающий за хранение паролей и доступ к ним. Впервые, этот инструмент появился в восьмой версии iOS, которая появилась на рынке в 1998 году. С того времени, Keychain является неотъемлемой частью фирменной ОС от компании Apple.

На лаптопах и моноблоках Macintosh эта система защиты отвечает за хранение конфиденциальной информации различного рода, например, пароли от аккаунтов различных интернет-сервисов, сетей Wi-Fi, скрытых записей, а также от различных утилит, устройств и зашифрованных жестких дисков.

Немного истории

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

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

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

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

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

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

Связка ключей iCloud: определение

Несмотря на то что этот инструмент был реализован в iOS еще в начале 90-х годов, компания Apple публично анонсировала его только в 2013 году при презентации седьмой версии iOS и десятого релиза MacOS. Это было революционное решение для повышения уровня безопасности хранения личных пользовательских данных и обеспечения доступа к ним со всех электронных гаджетов.

Однако эта служба безопасности претерпела и существенных изменений, основным среди которых стал перевод алгоритма на работу через облачный сервис хранения данных. Таким образом, все пароли, информация о кредитных картах и другие личные данные теперь хранятся не на винчестере, а на выделенном сервере компании, что существенно повышает их сохранность. Помимо этого, шифрование данных было переведено на стандарт AES 256-bit, который обеспечивает доступ к облаку только одному юзеру через интернет-браузер Safari и некоторые другие приложения, которые адаптированы под него.

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

Как работать с этой технологией?

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

Настройка «Связки ключей iCloud» на MacOS

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

  1. Заходим в настройки ОС.
  2. Раскрываем вкладку iCloud.
  3. Запускаем службу «Связка ключей».
  4. Вводим авторизационные данные.
  5. Указываем Apple ID.

После выполнения этих действий, служба будет активирована.

Добавление в «Связку ключей» кредитной карты на MacOS:

  1. Открываем браузер Safari.
  2. Заходим в настройки утилиты.
  3. Переходим в раздел Autofill.
  4. Нажимаем на кнопку «Редактировать», которая расположена возле подраздела «Кредитные карты».
  5. Добавляем новую кредитку и указываем ее данные.

Настройка Keychain на iOS-гаджетах:

  1. Заходим в настройки девайса.
  2. Переходим в раздел iCloud.
  3. Заходим в подменю «Связка ключей».
  4. Активируем или деактиввируем службу «Связка ключей» при помощи ползункового переключателя.

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

Добавление кредитной карты в iOS:

  1. Запускаем настройки смартфона или планшетного ПК.
  2. Заходим в раздел Safari, после чего переходим в подменю «Пароли и автозаполнение».
  3. Указываем защитный код.
  4. Заходим в раздел работы с кредитными картами.
  5. Добавляем новую кредитку, нажав на соответствующую кнопку и указав все необходимые данные о ней.

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

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

Если впоследствии вы захотите синхронизировать облачное хранилище с вашим HDD, то сделать это можно при помощи файлов, которые находятся в директории /Library/Keychains/. Однако при этом необходимо учитывать, что при каждой смене пароля на любом из устройств, синхронизацию придется настраивать заново.

Как получить доступ к информации, хранящейся в облаке?

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

Проблемы при активации и настройке «Связки ключей»

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

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

Как быть в такой ситуации?

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

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

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

  1. Зайти в настройки гаджета.
  2. Перейти в раздел настроек браузера.
  3. Перейти в подраздел «Пароли».
  4. Подтвердить личность при помощи пароля или отпечатка пальца.

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

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

Безопасное хранение паролей и их синхронизация между устройствами - задача непростая. Около года назад 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
- Bundle ID: com.apple.security.cloudkeychainproxy3;
  • com.apple.sbd3
- Bundle ID: com.apple.sbd (SBD - акроним Secure Backup Daemon).

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

Второе же хранилище предназначено для резервного копирования и восстановления записей 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. Но удобство этого варианта, конечно, оставляет желать лучшего.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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