Все, что следует знать о безопасности ваших данных. Как защитить свой аккаунт iCloud от взлома

Шифрование

Шифрование ежедневно защищает триллионы онлайн-транзакций. Каждый раз, когда вы что‑то покупаете или оплачиваете счёт, переписываетесь в iMessage или разговариваете по FaceTime, ваше устройство шифрует данные. Они превращаются в закодированный набор символов, который невозможно прочитать без специального ключа. Выпустив FileVault для macOS и средства защиты данных для iOS, мы стали одной из первых компаний, включивших шифрование дисков в базовую поставку нативных операционных систем. Кроме того, мы никогда не станем встраивать в свои продукты средства несанкционированного доступа (backdoor), позволяющие расшифровывать данные без вашего ведома.

iMessage и FaceTime

Ваша переписка в iMessage и разговоры по FaceTime защищены технологией сквозного шифрования. Все сообщения с устройств watchOS и iOS отправляются в закодированном виде, поэтому их невозможно прочитать без вашего пароля. Протоколы iMessage и FaceTime разработаны таким образом, чтобы их нельзя было расшифровать в момент передачи данных между устройствами. Вы можете настроить автоматическое удаление вашей переписки через 30 дней или год, а можете хранить её на устройстве постоянно.

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

Здоровье и фитнес

Разработчики всех приложений в App Store обязаны информировать пользователей о своей политике конфиденциальности. Это касается и приложений, работающих с HealthKit. Ваши данные в приложении «Здоровье» и данные активности на Apple Watch зашифрованы специальными ключами, защищёнными вашим паролем.

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

Аналитика

Ваше устройство iOS может собирать аналитические данные о своей работе и работе Apple Watch и отправлять эти данные в Apple для анализа. Эта информация обезличена и раскрывается только с вашего явно выраженного согласия. Аналитические данные могут включать информацию о спецификациях оборудования и операционной системы, статистику производительности и сведения о том, как вы используете устройства и приложения. При этом личные данные либо не записываются, либо удаляются из отчётов перед отправкой в Apple и защищаются такими технологиями, как Differential Privacy.

Данные Differential Privacy помогают улучшать наши службы, не нарушая конфиденциальность ваших персональных данных. Например, эта технология улучшает работу QuickType и предложения эмодзи, а также подсказки при поиске по Заметкам.

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

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

iCloud

Все ваши данные в iCloud - фотографии, контакты, напоминания и многое другое - шифруются во время передачи и при хранении на наших серверах. Мы также шифруем информацию, которая передаётся между вашим почтовым приложением и почтовыми серверами iCloud.

Данные, которые шифруются в iCloud

• Документы
• Календари
• Контакты
• Связка ключей iCloud
• Резервное копирование
• Закладки
• Напоминания
• Найти iPhone
• Мои друзья
• Почта (при передаче)
• Заметки

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

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

А в iOS 11, macOS High Sierra и более новых системах, благодаря сквозному шифрованию в iCloud, определённые личные данные (например, данные Siri) синхронизируются на всех устройствах таким образом, что Apple не имеет к ним доступа.

CarPlay

Всё, что мы рассказывали о механизмах безопасности, встроенных в iPhone и приложения, относится и к CarPlay. Мы используем только самую необходимую информацию о вашем автомобиле, которая помогает улучшить ваше взаимодействие с CarPlay. Например, данные о геопозиции вашего автомобиля могут помочь iPhone точнее прокладывать маршруты в Картах. А от сторонних приложений мы всегда требуем представлять вам для ознакомления политику конфиденциальности.

Apple начинает новую компанию по уговариванию пользователей о частичном отказе от конфиденциальности. В частности, службы такие как Siri работают куда лучше, если компания может проанализировать реальные данные.
И все же речи об отказе от конфиденциальности всё-таки нет. По крайней мере так декларируется. Данные (якобы) анонимно собираются. Подробнее http://www.apple.com/ru/privacy/
Но конечно, никто не знает, как на самом деле собираются данные, как и сколько хранятся, как зашифрованы и прочее. В принципе, о том, что хранится в самом iCloud и что/как зашифровано, специалисты Apple описывают относительно подробно: https://support.apple.com/ru-ru/HT202303
Но, во-первых, тут явно не всё -- вот недавно специалисты российской компании Elcomsoft раскопали, что хранится (среди прочего) журнал звонков, а он тут не упомянут (хотя возможно, скрывается под "iCloud Drive").
Во-вторых, уже давно известно, что ключи шифрования (ко всему кроме "связки ключей") хранятся вместе с данными, и соответственно доступ к ним (и возможность расшифровки) есть у всех, у кого есть физический доступ.
Наконец, нет чёткого описания, что именно они будут делать в плане улучшения Siri. Сами обрабатывать? А может, сторонними сервисами? Какими? Можно ли им доверять?
Да, ну и ещё один вопрос -- а спецслужбам по запросу будут эти данные выдавать? Скорее всего да (тут можно вспомнить недавний случай с Amazon Alexa).
Второй важный момент. Apple не первый, кто наши данные читает Google давно это делает -- например, сканируя почту. Да и поисковые запросы анализирует, чтобы потом нужную рекламу подсунуть.
Apple долго спорил, что необходимо отстаивать конфиденциальность клиента, однако компания хочет сделать такие службы как Siri более умными. Как?
Новая опция в ее программном обеспечении iOS 10.3, выпущенной для тестирования, просит чтобы пользователи iPhone и iPad совместно использовали учетные данные iCloud. Службы iCloud включают хранилище файлов, электронную почту, календари, фото управление, синхронизацию пароля, музыку и видео.
Конфиденциальность – щекотливый и весьма технически сложный вопрос для технологических компаний.
По утверждению Apple, можно иметь и хорошие службы, и приемлемый уровень конфиденциальности. Ведь Apple рекламировало конфиденциальность даже с более ранними версиями iOS, которые уже собирали данные по использованию пользователями iPad и iPhone.
Конфиденциальность всегда была темой для гордости Apple и попыткой выделить его продукты.
В 2015 году исполнительный директор Тим Кук подверг критике компанию Google, заявив что она «пожирает все, что может узнать о вас и пытается превратить в деньги личные данные пользователей».,
Но ведь сегодня, в эру искусственного интеллекта, службы виртуальных помощников, все более и более важны, а раз так, то следует приучить пользователей к мысли, что все это делается для их пользы, что их конфиденциальность - значит куда меньше, чем новые возможности и новые удобства.
Таким образом, пользователей постепенно приучают к мысли, что для удобства необходимо пожертвовать конфиденциальностью.
"Сервисы типа Apple iCloud плотно вошли в нашу жизнь ", - отмечает Владимир Каталов, генеральный директор компании "Элкомсофт", занимающейся криминалистической экспертизой мобильных устройств и облачных сервисов. "Трудно себе представить современные бизнес-процессы без использования "облаков", они действительно предоставляют новый уровень удобства, недоступный ранее. Однако, за это приходится платить. Вендоры уверяют нас в строгом соблюдении конфиденциальности и использовании сильного шифрования, но достаточно ли у вас квалификации, чтобы в этом убедиться? Впрочем, это и не всегда возможно. Мы не говорим, что безопасность ваших данных теперь под угрозой. Но риски безусловно надо осознавать. Безопасность -- это постоянный процесс, и вам придётся не только внимательно изучать соглашения о конфиденциальности (которые, кстати, не всегда просты и требуют определённой квалификации для понимания), но и оценивать, насколько вы доверяете компании, предоставляющей тот или иной сервис. Но и в этом случае гарантий вам никто не даст."

Безопасное хранение паролей и их синхронизация между устройствами - задача непростая. Около года назад 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, а также устройств и сервисов других компаний очень актуален. Скандал, вызванный разблокировать iPhone и нежеланием подчиниться со стороны Apple, заставил более пристально взглянуть на проблему. В этой статье мы постараемся рассказать все о ваших данных, которые вы доверяете Apple, и их безопасности.

Что мы пытаемся защитить?

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

• Местоположение вашей семьи и детей
• Контактная информация
• Личные фотографии и видео
• Информация о состоянии здоровья
• Информация о банковских счетах, кредитных картах и финансах
• Пароли и учетные записи
• Информация о покупках
• Личная и рабочая переписка
• Голосовые сообщения и многое другое

Смартфоны и компьютеры также могут стать жертвами атаки хакеров. С их помощью злоумышленники могут:

• Следить за вами с помощью встроенной камеры
• Прослушивать вас с помощью встроенного микрофона
• Отслеживать ваше местоположение с помощью встроенного GPS-приемника
• Отслеживать вашу активность в Сети
• Прослушивать ваши телефонные разговоры и многое другое

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

Как Apple защищает данные в iCloud

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

• Календари
• Контакты
• Закладки
• Заметки
• Документы в облаке
• iCloud Drive
• Резервные копии
• Найти iPhone
• Найти друзей
• Связка ключей iCloud
• Почта
• iCloud.com
• iTunes в облаке

Доступ к iCloud.com с вашего компьютера и доступ приложений к iCloud защищен при помощи SSL-соединения.

Как защищены данные в iPhone

В iPhone Apple использует 256-битное шифрование AES, которое не позволяет приложениям получить доступ к данным, не предназначенным для их работы. Ключи шифрования хранятся в отдельном участке памяти, как и данные об отпечатках ваших пальцев. У приложений нет доступа к этой информации, к тому же смартфон постоянно обновляет ключи. Другими словами, если ФБР желает получить информацию с iPhone злоумышленника, лучше им нацелить свои усилия на iCloud. iPhone , пока не введен пароль, а после 10 неверных попыток ввести пароль он и вовсе их удалит. iPhone не отдаст ваши данные, если он защищен паролем.

Как защищены данные в компьютерах Mac

Компьютеры Mac оснащены программным инструментом шифрования под названием FileVault 2, настроить который вы можете в системных настройках. FileVault 2 использует 128-битное шифрование AES. Есть все необходимые инструменты для того, чтобы все ваши данные и ключи шифрования были в нужный момент удалены. Разумеется, вы заметили, что метод шифрования данных в iPhone значительно более серьезный. Это связано с тем, что ваш Mac не знает ничего об отпечатках пальцев и многом другом.

Как защищены данные в Apple Watch

Немногие знают, что данные в Apple Watch защищены не хуже. Apple говорит, что в часах используется метод шифрования, схожий с тем, что используется в iOS. Apple Watch также используют шифрование IDS для обмена данными с iPhone. При попытке соединить Apple Watch с другим iPhone придется помучиться и проститься с данными. Другими словами, о безопасности данных на ваших часах переживать не стоит.

Вывод

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

По материалам iDownloadBlog

Которая позволяет сохранять информацию об учетных записях и номера кредитных карт.

Вконтакте

Вследствие, все данные можно синхронизировать с доверенными устройствами Mac , iPhone , iPad и iPod Touch , которые связаны одним .

Такое развитие событий еще раз доказывает зависимость Apple от iCloud , и повышает ответственность администраторов облачного сервиса компании, которые обязаны предоставить сохранность личных данных пользователей.

Apple опубликовала специальный материал об осуществлении безопасности и приватности пользователей в сервисе iCloud . С выходом OS X Mavericks правила были несколько обновлены.

Рассмотрим работу в iCloud более подробно. Если пользователь заходит в свою учетную запись на сайте iCloud.com через браузер, то все его сессии защищены SSL-сертификатом, включая трафик, циркулирующий между устройствами и сервисами iCloud . Любые данные в web-приложениях iCloud , доступ к которым осуществляется через web-интерфейс или другие базовые приложения iOS / OS X , шифруются на сервере. Единственным исключением являются почтовые серверы IMAP. Для того чтобы зашифровать данные, хранящиеся на IMAP серверах, следует использовать дополнительное S/MIME-шифрование, которое поддерживается всеми почтовыми клиентами Apple .

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

«Даже если вы решили использовать сторонние приложения для получения доступа к iCloud , ваши логин и пароль пересылаются через зашифрованное SSL-соединение», — говорится в уведомлении от Apple .

По поводу функций и Найти моих друзей в яблочной компании уверяют, что координаты местоположения фиксируются только по запросу пользователя. Эти функции используют как минимум 128-битное шифрование AES. Последние зафиксированные данные о местоположении хранятся на серверах Apple : для Найти моих друзей период хранения составляет 2 часа, а для – 24 часа. Затем вся информация удаляется.

Для хранения паролей и номеров кредитных карт на серверах iCloud Apple использует 256-битное AES шифрование и «асимметричную криптографию на эллиптических кривых и симметричные ключи» для обеспечения безопасности личных данных. Эти стандартные методы шифрования используются как при передаче, так и при хранении данных в облаке.

Что касается номеров кредитных карт, сохраняющихся при помощи Связки ключей , то в iCloud хранятся только номера и сроки действия карт, но не коды безопасности (cvv), которые вручную вводятся в web-формах. Помимо этого, данные из Связки ключей не являются частью резервного копирования в iCloud .

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

В компании подчеркивают, что они не могут получить доступ к ключам шифрования для Связки ключей , так как они создаются локально на устройствах пользователей.

Для того чтобы использовать Связку ключей на iPhone , iPod touch и iPad , все устройства должны работать на базе , а на компьютерах Mac должна быть установлена OS X Mavericks . Использование функции зависит от региона, в котором проживает пользователь.