`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Александр Пацай

Apple и шифрование бэкапов iCloud

+13
голоса

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

Вот и вчера у Reuters вышел материал, что Apple якобы отказалась от шифрования iCloud после жалоб ФБР о том, что это может помешать расследованиям. (А до этого еще была новость про сканирование фотографий в iCloud на предмет содержания сцен насилия над детьми. А совсем недавно – про разблокировку iPhone). Материал изобилует цитатами источников, пожелавших остаться неизвестными, которые знакомы с темой, хотя никто прямо не связывает события (требования ФБР) и результат (отсутствие шифрования у бэкапов iCloud). По ссылке есть хороший разбор Джона Грубера именно о тексте, цитировании и выводах в статье Reuters. Чего стоит только цитата одного из источников “Можете себе представить причины”. Да, я, например, могу, и там необязательно будет фигурировать требование ФБР. Поэтому одной из ключевых цитат материала я бы назвал эту:

Reuters could not determine why exactly Apple dropped the plan.

(Reuters не смогли определить точную причину, по которой Apple отказалась от плана (шифровать бэкапы))

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

Во-первых, самое основное заблуждение, с которым я столкнулся в процессе обсуждения этого материала — это путаница в понятии “шифрование”. Важно понимать, что сам бэкап устройства (iPhone или iPad) хранится в iCloud зашифрованным. Другое дело, что к этому бэкапу у Apple есть ключ, которым компания может расшифровать этот бэкап и передать его правоохранительным органам по запросу суда (что компания и делает очень часто). Часть данных с телефона хранится в iCloud (не в бэкапе) немного в другом виде; эти данные зашифрованы сквозным шифрованием – end2end encryption (далее e2e), где ключ к расшифровке этих данных создается на базе информации об устройстве и пароля пользователя к устройству. Таким образом, эти данные Apple расшифровать не может:
– Данные о доме
– Медданные
– Связка ключей iCloud (включая все сохраненные учетные записи и пароли)
– Платежная информация
– Набранный словарный запас клавиатуры QuickType
– Функция «Экранное время»
– Информация Siri
– Пароли Wi-Fi

Кроме этого, переписка Messages тоже шифруется e2e, но есть нюансы:

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

Если вам интересно, у компании Элкомсофт есть хороший разбор того, какие данные могут получить правоохранительные органы по запросу с решением суда. Так что если для вас это все стало сюрпризом, хочу напомнить крылатую фразу о том, что “”облако” — это модный термин для определения “чужой компьютер””. Да и ничего модного в компьютерных “облаках” тоже нет. Просто это всё означает, что формально вы не контролируете то, что происходит с вашими данными на чужом компьютере, если речь не идет о полноценном сквозном e2e шифровании.

Все мы видели эту прошлогоднюю фотографию из Лас Вегаса:
Apple и шифрование бэкапов iCloud

На ней просто не видно мелкого текста “*только если вы ничего не отправляете в iCloud”. Что, в принципе, возможно — можно отключить резервное копирование iPhone или iPad в iCloud, и либо рисковать потерей данных, либо создавать зашифрованную резервную копию на компьютере. Можно даже попытаться пользоваться iPhone, не заводя там Apple ID — это тоже возможно, но очень неудобно и, по сути, убивает все прелести (и недостатки) экосистемы Apple. Но вообще это разделение телефона как физического объекта, который требует максимальной защиты, насколько это возможно, и резервной копии, цель которой — восстановление пользовательских данных, о чем писал Уолт Моссберг в 2016 году, по сути, является ключевым моментом всей этой истории с бэкапами и их шифрованием.

Резервная копия устройства в iCloud служит для того, чтобы пользователь мог восстановить свои данные в случае “нештатной” ситуации — потери или замены телефона. Подозреваю, что среди миллиарда пользователей iOS-устройств каждый день находится достаточное количество людей, которые забывают свой пароль, и приходят в Apple с просьбой помочь им восстановить данные — им Apple может помочь. Заодно Apple может помочь и ФБР, которая приходит за бекапами преступников, и вот тут возникает противостояние тех самых “конфиденциальность” и “безопасность”, битва между которыми периодически приводит к требованиям вставить во все приборы по бэкдору.

Я последние пару лет пребывал в уверенности, что отсутствие полноценного шифрования без доступа третьих сторон для бэкапов iCloud было связано со сложностью восстановления данных на новые устройства. А оказалось, что это не так и речь больше идёт об удобстве для пользователей. Поэтому новость о том, что Apple сознательно отказалась от этой функциональности под давлением ФБР (что это вообще за мир, в котором ФБР может давить на независимую организацию?), вызвала у меня разочарование. Я ожидал, что Apple все-таки сможет найти решение для этой технической проблемы, и таким образом закроет брешь в своем маркетинговом месседже про защиту пользовательских данных. Да и с ФБР, стучащими в дверь, было бы проще разговаривать: “ну нет у нас ключей для этих архивов, нету! Отстаньте!”. С одной стороны, я могу понять это решение с учетом вышеописанных запросов пользователей; с другой стороны, как сторонник защиты персональных данных, не могу с ним согласиться. Я понимаю прагматичность подхода Apple, в том числе и тот момент, что давление на Apple для создания бэкдора в случае громких расследований было бы гораздо выше, если бы компания не могла предоставить резервные копии с телефонов. Но Google, например, шифрует резервные копии Android с помощью PIN-кода устройства без всяких согласований. Я очень надеюсь, что Apple тоже изменит свое решение, и не важно, каким было обоснование для этого решения ранее. Как минимум, полноценное сквозное шифрование резервной копии iCloud должно быть опцией для тех, кто сознательно нажмет кнопку “Да, я готов потерять свои данные, если я забуду пароль”. Раз уж мы говорим о том, что “Неприкосновенность частной жизни — фундаментальное право человека.

PS А требование генпрокурора США помочь в разблокировке iPhone, как и предыдущее требование о создании бэкдора в iOS — это вообще отдельная параллельная история аппаратных игр в кошки-мышки. В ней замешаны iOS, уязвимости в ней, процессор Secure Enclave, перебор паролей и специалисты Cellebrite и Grayshift:

Tools like those from Cellebrite and Grayshift don’t actually break iPhones’ encryption; they guess the password. To do so, they exploit flaws in the software, like Checkm8, to remove the limit of 10 password attempts. (After about 10 failed attempts, an iPhone erases its data.) The tools then use a so-called brute-force attack, which automatically tries thousands of passcodes until one works.

That approach means the wild card in the Pensacola case is the length of the suspect’s passcode. If it’s six numbers — the default on iPhones — authorities almost certainly can break it. If it’s longer, it might be impossible.

A four-number passcode, the previous default length, would take on average about seven minutes to guess. If it’s six digits, it would take on average about 11 hours. Eight digits: 46 days. Ten digits: 12.5 years.

If the passcode uses both numbers and letters, there are far more possible passcodes — and thus cracking it takes much longer. A six-character alphanumeric passcode would take on average 72 years to guess.
It takes 80 milliseconds for an iPhone to compute each guess. While that may seem small, consider that software can theoretically try thousands of passcodes a second. With the delay, it can try only about 12 a second.

The Secure Enclave processor in the iPhone 7 Plus also adds additional delays between passcode attempts, which could make guessing even a four- or six-digit passcode take weeks. But researchers believe Cellebrite and Grayshift have figured out how to disable that delay, because their tools routinely hack into newer phones with the feature.

Такие дела.

Apple и шифрование бэкапов iCloud

Дізнайтесь більше про мікро-ЦОД EcoStruxure висотою 6U

+13
голоса

Напечатать Отправить другу

Читайте также

 

Slack подает жалобу на Microsoft и требует антимонопольного расследования от ЕС

 
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT