Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать —

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать - Без рубрики

Android

C Android ситуация несколько сложнее. Чем современнее смартфон, тем лучше защищены хранящиеся на нем данные. Пользователям устройств из «эталонной» линейки Nexus, Galaxy S7 и других под управлением Android 6.0 достаточно активировать пароль в настройках, как говорилось выше.

Для старых смартфонов шифрование необходимо включать вручную. В данном контексте даже Galaxy S6 и Moto X Pure считаются устаревшими. Перейдите в Настройки -> Безопасность и выберите опцию Зашифровать телефон. Из этого же меню можно зашифровать карту памяти, после чего необходимо обязательно установить пароль для экрана блокировки.

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

С выходом iOS 8 компания Apple стала использовать шифрование, которое при условии установленного пароля не позволяет сторонним лицам получить доступ к данным на iPhone и iPad. В настоящий момент, согласно исследованиям, на 95% «яблочных» гаджетов данные шифруются. На Android ситуация обратная – только 10% из 1,4 млрд реализованных «гуглофонов» имеют надежное шифрование данных.

Iphone

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

Если вы не используете пароль на экране блокировки, то обязательно установите его. Для этого нужно перейти в меню Настройки -> Touch ID и пароль и включить запрос на ввод пароля.

Pgptools для iphone и ipad — надежное шифрование личной переписки | яблык

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

PGPTools для iPhone и iPad - надежное шифрование личной переписки

Разработчик / Издатель: SJ Software Development Group Limited
Скачать PGPTools для iOS (App Store);
Скачать PGPTools для Android (Play Store);
Скачать PGPTools для Mac (Mac App Store);
Скачать PGPTools для для Windows (Windows Store).
Официальный сайт PGPTools.

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

Как и следует из названия программы, в ее основе лежит система шифрования с нескромным, но многообещающим названием PGP, что расшифровывается как Pretty Good Protect. Разработана она была почти 15 лет назад и считается одной из самых надежных в своем роде. Упрощенно, принцип работы отчетного приложения выглядит следующим образом — двое пользователей имеют PGP-ключ шифрования, при помощи которого могут как распознавать, так и создавать закодированные сообщения.

При этом PGPTools позволяет отправлять зашифрованные послания не только на электронную почту, но и через любой другой сервис, поддерживающий текстовые сообщения — Skype, ICQ, SMS, WhatsApp и т.д. Для этого нужно лишь скопировать код из приложения и вставить в сообщение, после чего получатель произведет обратную процедуру — скопирует код из мессенджера, а затем введет его в PGPTools, где он и будет расшифрован.

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

PGPTools для iPhone и iPad - надежное шифрование личной переписки

Итак, нажав « » в верхнем левом углу в разделе «Список ключей» (скриншот выше), необходимо ввести его имя, электронный адрес получателя, пароль и выбрать длину ключа в битах (1024, 2048 или 4096). Имеется также возможность импорта уже созданных ранее PGP-ключей.

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

PGPTools для iPhone и iPad - надежное шифрование личной переписки

Простота, удобство и эффективность PGPTools делают данную программу весьма привлекательной для широкой массы пользователей. При этом приложение можно использовать практически на любом устройстве — под управлением iOS, Android, Windows Phone, а также десктопных платформах.

Смотрите также:

Безопасность ios (часть ii)

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

Автор: Понуровский Иван

В прошлой статье шла речь о базовых механизмах безопасности операционной системы iOS. Базовые механизмы включают в себя цепочку доверенной загрузки, персонализацию системного ПО, подписание кода сообщений, выполнение приложений в песочнице и с правами непривилегированного пользователя, права доступа (entitlements), ASLR и ARM’s Execute Never. Но, допустим, что случилось страшное: нарушителю удалось каким-то образом обойти базовые механизмы безопасности, и конфиденциальная информация пользователя теперь находится под угрозой. Но и тогда нарушителю может помешать последний, практически нерушимый, оплот безопасности – механизмы шифрования и защиты данных.

Аппаратный уровень

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

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

Каждое устройство с iOS имеет встроенный чип, в котором реализован алгоритм AES-256. Расположение чипа на пути от флеш-памяти к оперативной памяти заметно снижает энергозатраты на шифрование/дешифрование. На аппаратном уровне также реализован алгоритм SHA-1.

При производстве в процессор зашиваются два 256-битных ключа AES: UID (уникальный идентификатор устройства) и GID (групповой идентификатор устройства). Никакое программно-аппаратное обеспечение не может напрямую прочитать ключи AES; можно только прочитать результаты шифрования/дешифрования на этих ключах. Ключ UID уникален для каждого устройства, и он неизвестен даже Apple.Не стоит путать UID и ECID; ECID – это тоже уникальный и тоже идентификатор, который имеет вид 00000XXXXXXXXXXX, где X – шестнадцатеричная цифра; а UID, как уже говорилось выше, 256-битный ключ. Ключ GID одинаков для всех процессоров одного семейства (например, у всех процессоров A5 GID одинаковый).

При загрузке ядра служба IOAESAccelerator вычисляет еще пять ключей на основе UID и GID:

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

Рисунок 1. Ключи, генерируемые на основе UID и GID

  • Ключ 0x835 генерируется путем шифрования величины 01010101010101010101010101010101 на ключе UID;
  • Ключ 0х899 генерируется путем шифрования величины D1E8FCB53937BF8DEFC74CD1D0F1D4B0 на ключе UID, назначение ключа 0x899 неизвестно;
  • Ключ 0x89Aгенерируется путем шифрования величины DB1F5B33606C5F1C1934AA66589C0661 на ключе UID и используется для шифрования SHSH-сертификата;
  • Ключ 0x89Bгенерируется путем шифрования величины 183E99676BB03C546FA468F51C0CBD49 на ключе UID и используется для шифрования ключа раздела данных (ключ EMF);
  • Ключ 0x837 генерируется путем шифрования величины 345A2D6C5050D058780DA431F0710E15 на ключе GID, ключ использовался в ранних версиях iOS и в современных версиях не используется.

В дальнейшем нас будут интересовать только ключи x835, x89A и x89B.

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

Быстрое и безопасное удаление ключей настолько же важно, как и их генерация. Для решения подобной проблемы на устройствах под управлением iOS существует специальная область под названием Effaceable Storage. Область занимает 1 блок (~ 1Мб) во flash-памяти и содержит три ключа: зашифрованный ключ EMF, зашифрованный ключ DKey и ключ BAG1 (подробнее об этих ключах чуть ниже). Технология Effaceable Storage позволяет при необходимости быстро стереть все ключи, сделав всю информацию на устройстве пользователя недоступной.

Механизм защиты данных

Наряду с технологиями аппаратного уровня, для защиты данных пользователя во flash-памяти также используется механизм Data Protection. Механизм ориентирован на мобильные устройства и позволяет пользователю, например, отвечать на входящие звонки без расшифровки конфиденциальных данных, или в фоновом режиме скачивать информацию даже когда устройство заблокировано. Контроль доступа к каждому фалу осуществляется на основе класса защиты, то есть каждому файлу присваивается определенный класс защиты, в зависимости от того, когда может потребоваться доступ к этому файлу (например, только после разблокировки устройства, или даже если устройство заблокировано). У каждого класса защиты есть отдельный ключ, на котором шифруется ключ файла, принадлежащего конкретному классу защиты.

Рассмотрим теперь подробнее, какие действия происходят при создании файла, и как организована его защита. Все очень просто.

  • Каждый раз при создании файла система генерирует новый 256-битный ключ FileKey (файловый ключ);
  • Следующим шагом вычисляется вектор инициализации (IV). Сначала вычисляется так называемый IVkey. IVkeyполучается путем хеширования файлового ключа, причем хеш берется не весь, а только 16 байтов. Затем, чтобы вычислить окончательное значение IVнужно взять выход регистра сдвига с линейной обратной связью (LFSR), на вход которого подается блок из файла с определенного смещения, и зашифровать выход на ключе IVkey. Другими словами, IV= AES_ENC(SHA1(FileKey), LFSR(offset)).
  • Файл зашифровывается алгоритмом AES на ключе FileKey и векторе инициализации IVв режиме CBC и записывается во flash-память.
  • Файловый ключ FileKey зашифровывается соответствующим ключом класса защиты и записывается в метаданные файла.
  • Метаданные файла зашифровываются ключом EMF. EMF — это специальный ключ, который генерируется при установке iOS или после того, как пользователь стер все данные с устройства. Ключ EMF шифруется ключом x89B и сохраняется в области Effaceable Storage, т.е. EMF! = AES_ENC(0x89B, EMF). Опция “Удалить все содержимое и настройки” (“Erase all content and settings”) позволяет в мгновение ока сделать все данные на устройстве недоступными. Действительно, если стереть ключ EMF в Effaceable Storage, никакой файл расшифровать не получится.
Читайте также:  Разбираем iPad Air 2 ⚙️ [Инструкция с фото]

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

Итак, на данный момент иерархия криптографических ключей iOS выглядит следующим образом:

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

Рисунок 2. Первоначальный вариант иерархии ключей

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

Пароль пользователя

На своем устройстве пользователь может установить пароль (Passcode). Всего возможно три вида паролей:

  • четырехзначный числовой пароль;
  • числовой пароль произвольной длины;
  • алфавитный пароль произвольной длины.

На основе UID устройства и пароля пользователя с помощью специальной функции (PBKDF2) вычисляется парольный ключ (Passkey):

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

Рисунок 3. Вычисление парольного ключа

Чтобы усложнить нарушителю атаку перебором, вычисление парольного ключа намеренно замедляется и в среднем занимает около 80 миллисекунд, причем после каждой неудачной попытке ввода пароля временная задержка до следующей попытки увеличивается. Кроме того, пользователь может включить опцию, благодаря которой после определенного числа неправильных попыток ввода пароля вся информация с устройства будет стерта. Заметим еще, что благодаря тому, что в вычислении парольного ключа участвует UID, парольный ключ для разных устройств с одинаковым паролем все равно будет различаться. Вообще, парольный ключ играет одну очень важную функцию, о которой будет рассказано чуть позже. Известно также, что, начиная с iOS 5, в процессе вычисления парольного ключа участвует еще один аппаратный ключ UID , но, к сожалению, более подробной информации об этом ключе мне найти не удалось

Ключи классов защиты

Всего в iOS существует 11 классов защиты, причем 5 классов используются для защиты данных (ключи классов защиты данных), а 6 для защиты элементов связок ключей (ключи классов защиты элементов связки ключей). Сначала рассмотрим ключи классов защиты данных.

Таблица 1. Ключи классов защиты данных

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

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

  • Помимо файлового ключа для файла генерируется пара открытый (pkf) закрытый ключ (skf):

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

  • У класса защиты NSFileProtectionCompleteUnlessOpen также есть открытый (pkc) / закрытый ключи (skc):

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

  • На основе закрытого ключа файла и открытого ключа класса защиты вычисляется разделяемый секрет:

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

  • Файловый ключ зашифровывается на хеше разделяемого секрета и вместе с открытым ключом файла сохраняется в метаданных. Закрытый ключ файла стирается из памяти:

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

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

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать - 

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

Данные недоступны только до первой аутентификации пользователя (NSFileProtectionCompleteUntilFirstUserAuthentication, ClassC): В отличие от класса полной защиты ключ класса защиты NSFileProtectionCompleteUntilFirstUserAuthentication не удаляется из памяти после блокировки устройства, следовательно пользователь будет иметь доступ к данным класса С, начиная с момента первой разблокировки устройства и ввода пароля вплоть до перезагрузки устройства.

Защита отсутствует (NSFileProtectionNone, ClassD): Этот класс по умолчанию присваивается данным, если им не присваивается какой-либо другой класс. На самом деле ключ NSFileProtectionNone хранится в Effaceable Storage: это и есть тот самый ключ Dkey, зашифрованный ключом x835, т.е. Dkey! = AES_ENC(0x835, DKey). Таким образом, даже если файлу не присвоен какой-либо класс защиты, файл все равно шифруется.

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

Многие приложения должны хранить собственные данные (например, пароли приложения, Wi-Fi пароли, почтовые аккаунты, сертификаты и.т.п.) в безопасности. Безопасность конфиденциальных данных приложений достигается за счет так называемой “связки ключей” (Keychain). По своей сути связка ключей – это база данных SQLite, хранящаяся в файловой системе устройства и имеющая класс защиты NoProtection. Доступ к базе осуществляется при помощи демона securityd, именно этот демон решает какое приложение или процесс к какому элементу связки ключей (записи в базе данных) может обратиться.

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

ID ключа

Название

Назначение

6

kSecAttrAccessibleWhenUnlocked

Элемент связки ключей доступен только после разблокировки

7

kSecAttrAccessibleAfterFirstUnlock

Элемент связки ключей недоступен только до первой аутентификации

8

kSecAttrAccessibleAlways

Элемент связки ключей доступен, даже если устройство заблокировано

9

kSecAttrAccessibleWhenUnlockedThisDeviceOnly

Элемент связки ключей доступен только после разблокировки, и элемент нельзя перемещать между устройствами

10

kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly

Элемент связки ключей недоступен только до первой аутентификации, и элемент нельзя перемещать между устройствами

11

kSecAttrAccessibleAlwaysThisDeviceOnly

Элемент связки ключей доступен, даже если устройство заблокировано, и элемент нельзя перемещать между устройствами

Таблица 2. Ключи классов защиты элементов связки ключей

Заметим, что половина ключей классов защиты связки ключей имеет постфикс “ThisDeviceOnly”. Дело в том, что в iOS 5 появилась возможность перемещать элементы связки ключей с одного устройства на другое. Элементы, которые имеют класс защиты с постфиксом “ThisDeviceOnly” дополнительно защищаются UID устройства, и поэтому на другом устройстве их просто не получится расшифровать.

Каждый элемент связки ключей имеет следующую структуру (начиная с iOS 5):

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

Рисунок 4. Структура элемента связки ключей

access group: группа доступа, т.е. приложения, процессы, которые могут получить доступ к элементу связки ключей;

Сумки с ключами

(Слева от абзаца 5_dollars.png) Все ключи классов защиты объединяются в еще одну сущность под названием “сумка с ключами” (Keybag). Всего существует 4 разновидности сумок с ключами: Системная сумка с ключами (System Keybag), Резервная сумка с ключами (Backup Keybag), Депонированная сумка с ключами (Escrow Keybag), Резервная сумка с ключами iCloud (iCloud Backup Keybag). Все сумки имеют одинаковую структуру, которая представлена на Рисунке 5:

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

Рисунок 5. Структура сумки с ключами

Теперь рассмотрим, какие функции выполняет каждая сумка в отдельности.

Системная сумка с ключами. Системная сумка хранится непосредственно на устройстве в файле /private/var/keybags/systembag.kb. Файл системной сумки зашифрован на ключе BAG1, который, как уже известно, находится в Effaceable Storage. Нужно отметить, что после каждой смены пароля меняется и ключ BAG1. После расшифровки файла мы получим системную сумку с ключами, но она будет находиться в заблокированном состоянии, то есть все ключи классов защиты в сумке по-прежнему будут зашифрованы. Каждый ключ зашифрован одним из трех способов: либо только на ключе UID, либо только на парольном ключе, либо одновременно на парольном ключи и на UID. За конкретный тип шифрования отвечает поле Wrappingtype.

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

Рисунок 6. Разблокировка системной сумки с ключами

В шифровании ключей классов защиты элементов связки ключей “…ThisDeviceOnlyвсегда участвует ключ UID, для того чтобы на другом устройстве эти ключи расшифровать бы не получилось.

Резервная сумка с ключами. Каждый раз, когда пользователь делает резервную копию устройства в iTunes, на компьютере пользователя создается резервная сумка с ключами. Ключи классов защиты в резервной сумке отличаются от ключей классов защиты в системной сумке, поэтому все файлы бэкапа перешифровываются на новых ключах. Файлы бэкапа шифруются, конечно же, алгоритмом AES 256 в режиме CBC на уникальном ключе и нулевом IV.

Всего возможно два вида бэкапов: обычный и зашифрованный. Различия между ними следующие:

  • в простых бэкапах ключи элементов связки ключей всех классов защиты зашифрованы на ключе x835, и, следовательно, восстановить их можно только на оригинальном устройстве;
  • в зашифрованных бэкапах пользователь при резервном копировании вводит специальный пароль. Этот пароль 10 000 раз прогоняется через функцию PBKDF2 (заметим, что в отличие от вычисления обычного пароля UID здесь не используется) в результате чего получается парольный ключ резервной копии. Все ключи классов защиты перемещаемых элементов связки ключей (с идентификаторами с 6 по 8) зашифровываются только на парольном ключе резервной копии, а ключи классов защиты элементов связки ключей “…ThisDeviceOnly” (идентификаторы с 9 по 11) зашифровываются одновременно на ключе x835 и на парольном ключе резервной копии.
Читайте также:  Как полностью убрать функцию Частный доступ в Safari для iOS - IT-HERE.RU

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

Депонированная сумка с ключами. Депонированнаясумка позволяет синхронизированному устройству (например, компьютеру, на котором установлен iTunes) разблокировать устройство с iOS, не требуя каждый раз пароля от пользователя. Когда устройство подключается к компьютеру, iTunes просит пользователя ввести пароль. После правильного ввода пароля создается депонированная сумка (ключи классов защиты в ней точно такие же, как и в системной сумке) и сохраняется на компьютере. Депонированная сумка зашифрована на 256-битном случайно сгенерированном ключе. Ключ, в свою очередь, хранится в файле на устройстве в папке /private/var/root/Library/Lockdown/escrow_records. Файл имеет класс защиты NSFileProtectionCompleteUntilFirstUserAuthentication.

Резервная сумка с ключами iCloud. Эта сумка во многом схожа с простой резервной сумкой, но в iCloud-сумке все ключи ассиметричные, благодаря чему резервное копирование в iCloud может производиться в фоновом режиме. Закрытые ключи классов защиты данных шифруются ключами облачного хранилища, а закрытые ключи классов защиты элементов связки ключей, как и в обычном бэкапе, зашифрованы на ключе x835.

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

Как зашифровать данные на iPhone и Android-устройстве и почему это нужно сделать -

Рисунок 7. Иерархия ключей

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

В заключение статьи опишем возможные атаки на механизм защиты данных

Атаки на механизм защиты данных

Допустим, нарушитель все-таки хочет извлечь конфиденциальную информацию из устройства пользователя. Нарушителю может потребоваться файл целиком (например, какой-нибудь сверхсекретный документ), или какие-либо атрибуты безопасности приложений (Wi-Fi пароль, сертификаты, закрытые ключи приложений и.т.п.). В первом случае необходимо знать ключ EMF, а также соответствующий ключ класса защиты данных. Ключ EMF зашифрован на ключе x89B, который, в свою очередь, вычислен на основеUID. Для шифрования ключей классов защиты данных используются ключи BAG1, UID и/или парольный ключ. Во втором случае элементы связки ключей зашифрованы на соответствующих ключах классов защиты элементов связки ключей, и для их (ключей классов защиты) расшифровки также необходимо знать ключи BAG1, UID и/или парольный ключ.

Следует сказать, что на данный момент известных способов извлечь аппаратные ключи UID и GIDне существует. Но не все так плохо. Специально для программно-технической экспертизы устройств с iOS компания Sogeti Labs выпустила пакет утилит, позволяющих извлечь практически все ключи (кроме аппаратных) из устройства. Ключи можно прочитать, благодаря пропатчиванию службы ядра IOAESAccelerator. Именно эта служба при загрузке ядра вычисляет ключи x835, x89A и x89B (см. Рисунок 1), а зная их, можно получить ключи Dkey, EMF и BAG1 (BAG1 вообще хранится незашифрованным). Для пропатчивания на устройстве, безусловно, должен быть сделан jailbreak. Код утилит от Sogeti Labs открыт, и при желании их легко можно найти в Интернете.

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

Случай 1: Нарушитель имеет физический доступ к устройству с паролем. В таком случае, если пароль состоит из 4 цифр, то можно за разумное время перебрать все возможные пароли, разблокировать устройство и получить полный доступ к информации пользователя.

Меры противодействия:

  • Установить более сложный пароль;
  • Использовать опцию ”Стереть содержимое и настройки устройства после N неудачных попыток ввода пароля” (стереть ключ EMF).

Случай 2: Эксплуатация Депонированной сумки с ключами. Как известно ключи классов защиты из депонированной сумки ничем не отличаются от ключей в системной сумке. Если нарушитель будет иметь доступ к устройству и компьютеру пользователя, то он сможет извлечь из устройства ключ, на котором зашифрована депонированная сумка (подбор 256-битного ключа займет достаточно много времени), расшифровать сумку и извлечь все ключи классов защиты. В результате нарушитель получит доступ некоторым данным и атрибутам безопасности.

Меры противодействия:

  • Ограничить доступ к компьютеру, на котором хранится Депонированная сумка с ключами.

Случай 3: Эксплуатация обычного бэкапа. В обычных бэкапах все ключи классов защиты элементов связки ключей зашифрованы на ключе x835. Следовательно, имея доступ к компьютеру с бэкапом и устройству пользователя, можно с помощью утилит Sogeti Labs извлечь ключ 0x835 и расшифровать все элементы связки ключей из бэкапа.

Меры противодействия:

  • Ограничить доступ к компьютеру c бэкапами устройства;
  • Использовать зашифрованные бэкапы.

Случай 4: Эксплуатация зашифрованного бэкапа. В отличие от предыдущего способа часть ключей сейчас (с 6 по 8) зашифровано на парольном ключе резервной копии, а другая часть (с 9 по 11) на парольном ключе резервной копии и ключе x835. Если пароль резервной копии достаточно слабый, то его можно подобрать, а дальнейшие действия ничем не отличаются от предыдущего способа.

Меры противодействия:

  • Ограничить доступ к компьютеру c бэкапами устройства;
  • Использовать более сложный пароль.

Но не стоит думать, что достаточно сложный пароль будет панацеей от всех атак. Даже самый стойкий пароль не устоит перед социальной инженерией или внедрением вируса в устройства (при условии, что на устройстве сделан jailbreak).

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

Основные источники

1. http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf
2. http://theiphonewiki.com/wiki/
3.http://ensiwiki.ensimag.fr/images/4/4d/4MMSR-2021-2021-student_seminar-iPhone_data_protection_in_depth_-_Jean-Baptiste_Bedrune,_Jean_Sigwald_-_HITB_Amsterdam_2021.pdf
4. http://www.slideshare.net/andrey.belenko/ios-forensics-overcoming-iphone-data-protection
5. http://code.google.com/p/iphone-dataprotection/wiki/EncryptionKeys
6. www.exploit-db.com/download_pdf/19767/
7. http://code.google.com/p/iphone-dataprotection/wiki/iTunesBackups

Вторая рекурсия: защищаемся от попыток сброса пароля на резервную копию

Лёгкость, с которой злоумышленник может обойти ваш самый сложный и длинный пароль, всего лишь введя код блокировки экрана, неприятно поражает. Однако и от этой напасти можно попробовать уберечься. Механизмом защиты здесь станут Ограничения родительского контроля (iOS 11) или пароль Экранного времени (iOS 12 и 13). Для простоты я буду описывать именно iOS 12.

Допустим, ваш iPhone попал в руки злоумышленника. Предположим, злоумышленнику удалось подсмотреть ваш код блокировки; теперь он пытается отвязать телефон от облака, а заодно слить копию данных, получив доступ к паролям из Связки ключей. Защититься от такого развития событий можно при помощи пароля Экранного времени.

Подробно о возможностях контроля Экранного времени можно почитать в статье Apple Использование родительского контроля на устройствах iPhone, iPad и iPod touch ребенка. Нас же сейчас интересует другая возможность этой системы: защитить телефон от сброса пароля на резервную копию.

Как ни странно, ограничить возможность сброса пароля к локальной резервной копии iOS достаточно просто: всё, что нужно сделать, это установить пароль Экранного времени как таковой. Сложность такого пароля невелика: единственный доступный вариант – это PIN-код из 4 цифр.

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

Что произойдёт, если теперь попытаться сбросить пароль на резервную копию? На первом шаге – никаких отличий: система запросит пароль блокировки устройства. А вот сразу после этого будет запрошен дополнительный 4-значный пароль Экранного времени. Эта мера безопасности вполне способна не только отвадить любопытных, но и защитить iPhone от вполне серьёзных попыток взлома.

Защита резервных копий: пока всё просто

Система резервного копирования iOS – воистину вне конкуренции. Нечто подобное в плане локальных бэкапов мы видели в BlackBerry 10, но эта система мертва, а до «облака» дело у BlackBerry так и не дошло. (Кстати, в ОС BlackBerry 10 резервные копии шифровались всегда, а ключ – всегда хранился в облаке – или в BlackBerry ID пользователя, или в корпоративной сети).

Единственный конкурент iOS – система Android, резервные копии которой создаются исключительно в облаке (команду adb backup мы проигнорируем: реально сохраняемых этой командой данных даже меньше, чем попадает в облако). Да, определённые ухищрения помогут вытащить больше данных, но именно резервные копии в Android далеки от идеала.

В рамках же этой статьи нас интересуют в первую очередь локальные резервные копии; об их содержимом я ранее писал в нашем блоге. Их можно создавать, например, в приложении iTunes, но не только в нём: существует множество сторонних приложений (в том числе и наш собственный iOS Forensic Toolkit), которые, подключившись к iPhone, создадут его резервную копию.

Рекурсия третья: как узнать пароль экранного времени

Пароль Экранного времени сохраняется на самом устройстве. Подобрать его за разумное время невозможно: невеликое пространство из 10,000 комбинаций защищается системой прогрессирующими задержками между попытками ввода. После нескольких неудачных попыток система ограничит скорость перебора паролей Экранного времени, вводя прогрессивные задержки в 1, 5, 15 и 60 минут.

Читайте также:  iPadOS 14 – Функции – Apple (RU)

Однако есть более интересные способы. Сразу оговорюсь: первый из них работает только тогда, когда пароль на резервную копию не установлен или известен, а второй – если на iPhone можно установить джейлбрейк (т.е. версия iOS на нём не новее iOS 12.2). Для iPhone с неизвестным паролем к резервной копии, работающего на самой последней версии iOS (сегодня это 12.4) работающего способа узнать пароль Экранного времени (пока) нет.

Способ 1: извлечь из резервной копии

В iOS 7-11 этот пароль (там он носит название Restrictions) хранится в виде хэша. Алгоритм относительно стойкий (pbkdf2-hmac-sha1, но количество итераций относительно невелико). С учётом того, что пароль этот состоит всегда и только из 4 цифр, полный перебор хэша на компьютере занимает несколько секунд.

В iOS 12 (здесь это пароль Экранного времени, или Screen Time) хранится в открытом виде. Нет, безопасность от этого хуже не стала: пароль переместили в Связку ключей. Тем не менее, класс защиты паролю Экранного времени назначили минимальный: он не привязан к устройству.

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

Чтобы достать пароль Экранного времени, нужно:

Способ 2: через джейлбрейк

Очевидно, что первый способ сработает лишь тогда, когда пароль на резервную копию не установлен или известен. Если же пароль на резервную копию установлен, но неизвестен, то единственный оставшийся способ узнать пароль Экранного времени – получить доступ к Связке ключей (keychain). Для старых версий iOS нужна копия файловой системы.

Для iOS 7-11 нужно:

Для iOS 12:

Нужно ли это делать? Не уверен: если удалось установить джейлбрейк, то, во-первых, все пароли можно извлечь и так, без посредника в виде резервной копии. Во-вторых, пароль на резервную копию можно узнать, расшифровав Связку ключей: пароль на резервную копию (так же, как и пароль Экранного времени) хранится там в открытом виде. Впрочем, если цель – снять ограничения Экранного времени, то такой подход вполне годится.

One more thing

Что интересно, пароль Экранного времени хранится также и в облаке iCloud, но только в том случае, если вы включили двухфакторную аутентификацию и активировали опцию Screen Time “Share across devices”. Сам ключ при этом не попадает в Облачную связку ключей, а хранится отдельно (примерно в том же виде, что и ключ восстановления доступа к зашифрованным томам FileVault 2).

На сегодня нет механизмов, чтобы извлечь его из iCloud и просмотреть. Мы над этим работаем; осенью планируется выход свежей версии Elcomsoft Phone Breaker, которая будет обладать этой возможностью (если с выходом iOS 13 ничего не изменится в механизме его хранения; такая вероятность есть: в самом телефоне iOS 13 уже изменила место хранения этого пароля).

В любом случае, чтобы вытащить пароль Screen Time из iCloud, вам понадобится всё перечисленное ниже:

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

Рекурсия четвёртая, последняя: как защитить доступ к паролю экранного времени

Вот мы и подошли к последнему пункту. Если ваша цель – максимально обезопасить устройство, то в ваших интересах сделать так, чтобы пароль Экранного времени ни сбросить, ни узнать было нельзя. Так же, как и в предыдущей части, новостей у меня две: хорошая и плохая.

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

Опасаться можно сценария, когда украденное устройство (с известным злоумышленнику кодом блокировки) будет положено на полку в ожидании появления джейлбрейка. Здесь, однако, может помочь стандартная «Стереть [устройство]», выполненное в портале Find my iPhone.

Дело в том, что для установки джейлбрейка требуется сначала подписать IPA-файл, а потом и подтвердить цифровую подпись непосредственно на самом iPhone. Подтверждение цифровой подписи происходит на сервере Apple; то есть, злоумышленнику придётся разрешить украденному у вас iPhone выйти в интернет. В этот момент с большой вероятностью сработает команда на стирание устройства.

Злоумышленники могут решить эту проблему, используя специальные конфигурации роутера, в которых будет запрещён доступ к узлам, ответственным за функционал Find My iPhone. Кроме того, вместо обычного сертификата для подписи джейлбрейка могут использовать сертификат разработчика, который не требует выхода iPhone в сеть для подтверждения цифровой подписи.

Плохая же новость в том, что как ни старайся, но защитить iPhone от доступа через системы GrayKey или UFED Premium не получится: их разработчики смогли обойти большую часть защитных механизмов iPhone. Если известен код блокировки экрана, то получить доступ к файловой системе и расшифровать Связку ключей пользователи этих комплексов смогут без особых проблем.

С другой стороны, доступны эти комплексы только и исключительно правоохранительным органам, причём далеко не в любой стране (в Россию, например, они не поставляются). Попадание их в руки злоумышленников практически исключено. Таким образом, этой опасности вы вряд ли подвергнетесь.

Руководство пользователя ipad

  • Добро пожаловать!

    • Поддерживаемые модели

    • 12,9‑дюймовый iPad Pro (5‑го поколения)

    • iPad Pro (12,9 дюйма, 4-го поколения)

    • iPad Pro (12,9 дюйма, 3-го поколения)

    • iPad Pro (11 дюймов, 3-го поколения)

    • iPad Pro (11 дюймов, 2-го поколения)

    • iPad Pro (11 дюймов, 1-го поколения)

    • iPad Pro (12,9 дюйма, 1-го и 2-го поколения)

    • iPad Pro (10,5 дюйма)

    • iPad Pro (9,7 дюйма)

    • iPad Air (4-го поколения)

    • iPad Air (3-го поколения)

    • iPad Air 2

    • iPad (9‑го поколения)

    • iPad (8-го поколения)

    • iPad (7-го поколения)

    • iPad (6-го поколения)

    • iPad (5-го поколения)

    • iPad mini (6‑го поколения)

    • iPad mini (5-го поколения)

    • iPad mini 4

  • Что нового в iPadOS 15

    • Быстрые команды

    • Акции

    • Советы

  • Авторские права

Установка код‑пароля на ipad

Если код-пароль неправильно введен 6 раз подряд, устройство блокируется, а на экране появляется сообщение о том, что iPad отключен. Если Вы не помните свой код-пароль, можно стереть iPad, используя компьютер или режим восстановления, а затем задать новый код-пароль. (Если перед тем, как Вы забыли код-пароль, была создана резервная копия в iCloud или на компьютере, данные и настройки можно будет восстановить из этой резервной копии.)

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

Шифрования файлов на ios

С проблемой шифрования и дешифрования файлов на IOS я столкнулся достаточно давно, Огромное количество людей постоянно интересовались у меня что же делать если «Я нахожусь в поездке и не имею доступа к компьютеру». Именно поэтому хотелось бы рассказать Вам шифровании файлов для IOS.

Итак, существует большое количество алгоритмов шифрования, такие как.

Систем шифрования достаточно много на данный момент и перечислять их нет особо никакого смысла ввиду их огромного количества и надёжности.

Для IOS приложений которые шифруют и дешифруют файлы AES достаточно много все они разного качества и надёжности, а вот систем который шифруют и дешифруют PGP практически нет! Если вы привыкли как я использовать в своей работе PGP, то задача зашифровать файл на IOS и дешифровать его станет настоящим испытанием -).

Можно пойти простым путём и использовать бесплатные приложения, которые работают с системами AES 128, 256 RSA! Можно потратить пару минут и использовать PGP который привычен и очень надёжен!

Представляю Вашему вниманию PGPFiles от SJ Software который решает полностью задачу по шифрованию дешифрованию файлов для IOS и работает с системой шифрования PGP!

PGPFiles – Уникальное приложение которое создано для работы с файлами для IOS, Android, Windows, Windows 8.1, 10 что обеспечивает полную кроссплатформенность приложения!

Зашифровать файл мы можете на любом устройстве, которое доступно у вас под рукой при этом Вы не ограничены каким то конкретным форматом файла допустим .txt Вы можете зашифровать и дешифровать любой файл (.pdf .png .doc .jpg .txt и т.д.).

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

Вы всегда будете уверены, что файл получил именно тот человек, которому он предназначен!

Так же хотел обратить Ваше внимание, что приложение доступно под все ОС на момент написание статьи на проверке находилась утилита для Mac OS.

Прекрасное приложение по очень малой цене всего 0,99$ уже доступно на AppStore для IOS!

Подробнее на сайте приложения PGPFiles

Ссылка на AppStore!

Спасибо за внимание!

По любым вопросам обращайтесь в службу поддержки.

Использование этого обзора только с обратной ссылкой на сайт ipad-mobile.ru.

Оцените статью
iPad Мобайл
Добавить комментарий