Около года назад широко разошлась информация о том, что Apple отказалась от планов шифрования облачных резервных копий после претензий ФБР. Новость вызвала неоднозначную реакцию в англоязычном сообществе пользователей; обсуждения не утихают до сих пор, время от времени вспыхивая с новой силой. Что на самом деле изменилось в политике шифрования резервных копий, каковы причины и последствия отказа от шифрования? Попробуем разобраться.

Шифрование данных в iCloud

Вся информация, которая хранится в iCloud, по умолчанию зашифрована и останется зашифрованной. На физическом уровне данные в iCloud в распределённом виде хранятся на множестве серверов, которые принадлежат сторонним компаниям — Amazon, Microsoft, AT&T, а данные пользователей из континентального Китая — на серверах, которые контролируются китайским правительством. Впрочем, большого смысла в таком контроле нет: ключи шифрования на сторонние серверы не попадают; соответственно, даже получив полный доступ к соответствующему серверу, узнать содержимое зашифрованных данных физически невозможно.

А что же ключи шифрования? Они хранятся на серверах Apple в Купертино. Из этого вытекает сразу несколько интересных последствий. Во-первых, доступ к данным пользователя, включая большую часть содержимого резервных копий (за исключением, к примеру, паролей из Связки ключей, которые шифруются аппаратным ключом), имеет сама компания Apple — чем активно пользуется, например, при сканировании закачанных пользователями фотографий на предмет поиска нелегальных материалов. Во-вторых, доступ могут получить сотрудники правоохранительных органов и спецслужб, предоставив компании соответствующим образом оформленный запрос. Наконец, данные может расшифровать любой пользователь Elcomsoft Phone Breaker, которому известны логин и пароль пользователя iCloud, а также есть доступ ко второму фактору аутентификации.

Ещё раз подчеркнём: этот тип шифрования остаётся в неизменном виде; отказ от сквозного шифрования никак не повлияет на шифрование данных в iCloud.

Сквозное шифрование

Некоторые типы данных в облаке могут быть дополнительно зашифрованы способом, известным как «сквозное шифрование». В отношении того способа, который фактически использует Apple, это название технически некорректно, но термин стал общеупотребимым, поэтому будем его использовать и мы.

Данные, защищённые «сквозным шифрованием», дополнительно шифруются ключом, который генерируется на основе кода блокировки экрана iPhone или iPad. У пользователей компьютеров Mac в таком качестве выступает системный пароль. Не зная кода или пароля, данные расшифровать невозможно. Разумеется, подобрать типичный код блокировки в считанные минуты (у подавляющего большинства пользователей это ровно 6 цифр) не составило бы для Apple ни малейшего труда, но компания принципиально отказывается это делать. До тех пор, пока принципиальная позиция Apple остаётся неизменной, защищённые сквозным шифрованием данные остаются недоступными для злоумышленников и для полиции (насчёт спецслужб такой уверенности нет). Даже по запросу от правоохранительных органов данные поступят в зашифрованном виде; при этом Apple принципиально не создаёт и не выдаёт программного обеспечения, которое могло бы использоваться для подбора пароля.

Какие типы данных защищены сквозным шифрованием? Связка ключей — это пароли пользователя, которые он сохраняет в браузере Safari и приложениях. Данные приложения Здоровье, сообщения в iCloud (SMS и iMessage), данные Экранного времени, приложения Home, голосовые заметки, данные Карт Apple (поисковые запросы, маршруты и регулярные местоположения) также используют для защиты сквозное шифрование. Наконец, в iOS 14 появилась защита и таких данных, как история открытых в браузере Safari страниц.

Казалось бы, добавить сквозное шифрование и к резервным копиям — вопрос технический и легко решаемый. Вступая в область слухов: компании пришлось столкнуться с противодействием со стороны ФБР.

Что планировала сделать Apple?

В отличие от журналистов, опубликовавших оригинальную статью, у нас нет «источников» в компании Apple, поэтому мы можем только предполагать, что именно планировалось сделать. Мы полагаем, что в Apple пытались использовать для резервных копий iPhone в iCloud ровно ту же схему «сквозного шифрования», которая успешно используется для защиты паролей, данных Здоровья и прочих типов данных, которые в компании считают особо важными. Иными словами, для расшифровки резервной копии пользователю потребовалось бы ввести код блокировки от оригинального устройства (или любого устройства, зарегистрированного в учётной записи iCloud — здесь мы не можем говорить с уверенностью, поскольку планы Apple не осуществились)..

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

С точки зрения представителей правоохранительных органов изменилось бы слишком многое. В Apple и без того постепенно переводят данные под в защищённые «сквозным шифрованием» контейнеры; попадание туда ещё и резервных копий с большой вероятностью привело бы к возникновению очередной точки напряжения между Apple и ФБР.

Шифрование резервных копий у Google

С выходом Android 9 в августе 2018 Google шифрует резервные копии устройств, которые создаются в облаке. Шифрование основано на ключе, который генерируется на основе кода блокировки экрана устройства. Резервные копии шифруются, но ФБР относится к этому спокойно. Почему так?

Разница здесь в количестве и качестве данных, которые хранятся в резервных копиях. В статье Data backup overview говорится об ограничениях на объём данных, которые каждое приложение может сохранять в резервных копиях: это всего 5МБ в составе резервной копии и 25МБ в сервисе Google Drive. В сравнении с объёмом резервных копий iOS, объём которых часто превышает несколько гигабайт, такой скромный объём данных не вызывает большого интереса у правоохранительных органов ещё и потому, что Google собирает, обрабатывает и хранит на несколько порядков большие объёмы информации в виде синхронизированных данных. Синхронизируются фотографии, файлы, пароли, история браузера и данные местоположения — при этом никакого «сквозного шифрования» не используется, все данные свободно доступны любому, указавшему корректные логин и пароль. Разумеется, вся эта информация доступна по запросу от правоохранительных органов. Шифрование резервных копий здесь выглядит мерой достаточно слабой.

Заключение

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