Достаточно ли безопасно использовать PIN-код для шифрования?

На Android 4.0 (Samsung Galaxy Nexus) есть возможность зашифровать телефон. Я нашел это о шифровании на Android 3.0, те же алгоритмы используются в Android 4? http://source.android.com/tech/encryption/android_crypto_implementation.html

Мой главный вопрос касается использования PIN-кода для расшифровки вашего телефона. Почему я вынужден использовать один и тот же пароль для разблокировки экрана и дешифрования телефона? Это ограничение позволит мне использовать только пароль низкой сложности (например, PIN-код), так как будет сложно ввести, например, 17 символов, чтобы разблокировать телефон для простого телефонного звонка.

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

Я говорю, что вы должны использовать PIN-код или пароль блокировки экрана . Пароль может иметь длину до 17 символов и может содержать любые буквы, цифры или символы (по результатам быстрого теста). Это гораздо больше энтропии. Конечно, было бы более безопасно без максимального ограничения, но все же.
Да, но если я использую пароль, мне нужно будет использовать его, чтобы просто разблокировать экран. Не очень удобно набирать 17 символов для быстрого вызова. Таким образом, большинство пользователей будут использовать PIN-коды, и это будет первое, что попытается сделать злоумышленник. Возможно, лучшим подходом было бы разрешить использовать парольные фразы для шифрования диска и разрешить использование простых PIN-кодов на экране блокировки. Чтобы избежать попыток брутфорса на экране блокировки, может быть принудительная перезагрузка после 3 неудачных попыток, приводящих к запросу пароля.
Значит, то, что вы ищете, просто не существует.
Что ж, я ищу ответ на вопрос, есть ли за этим какая-то причина. Если кто-нибудь знает способ обойти это. Если нет, то куда можно обратиться, чтобы оставить запрос функции. Команда Google Android или Samsung (выполняет чистую установку Android 4.0.1)?
К сожалению, я не знаю, чтобы кто-то, кроме Google, мог рассказать вам об этом. Возможно, вы могли бы попробовать средство отслеживания ошибок Android , чтобы подать запрос на добавление функции. Это кажется разумным, чтобы подать туда.
ну, текущее поведение при разблокировке экрана (на android gingerbread 2.3.6) таково, что каждые пять попыток приходится ждать 30 секунд. Это как бы отложило любую атаку грубой силы, тебе не кажется?
Да, против попытки входа в систему на экране разблокировки, но не против расшифровки жесткого диска. Это то, что я пытаюсь сказать, разблокировка экрана не должна быть такой же длинной, как шифрование жесткого диска (которое должно быть намного длиннее 4 цифр), и поэтому не следует заставлять использовать одно и то же для обоих.
+1, я полностью с вами @ChristopherKäck Это решение не имеет смысла, инженеры Google должны были знать лучше, надеюсь, они скоро это исправят.
Вы спрашиваете не по адресу, это вопрос к информационной безопасности . Большинство экспертов по Android здесь не будут квалифицированы, чтобы ответить или сделать информированное голосование по ответам на этот вопрос.
@lie_ryan Что ж, вопрос, который я искал, был скорее причиной android-y/software-dev, по которой они делились паролями для разных задач. Я знаю, что использовать 4 цифры в качестве пароля для шифрования диска небезопасно.
@Christopher: но вы основываете свое решение на неверной предпосылке, шифрование на диске было 128-битным AES, а не 4-значным PIN-кодом. Определение того, является ли эта схема безопасной или ошибочной по своей сути, не входит в компетенцию Android.SE.
@LieRyan Они по-прежнему используют общий пароль независимо от схемы шифрования, используемой для шифрования диска. Проблема в том, что пользователи не будут выбирать длинную фразу-пароль, если им также нужно использовать ту же длинную фразу-пароль, чтобы просто разблокировать экран. Что, я очень убежден, небезопасно. Так в чем может быть причина того, что пользователь вынужден использовать один и тот же пароль для обеих функций? Какое-то ограничение в ОС?
@Christopher: Нет ограничений на то, что можно сделать с помощью программного обеспечения. Вы должны задать контрольный вопрос в информационной безопасности . Может оказаться, что использование разных ключей на самом деле не будет более безопасным, или это может быть просто недосмотр или практический компромисс. В любом случае, вы получите гораздо лучшие ответы там, а не здесь. Как я вижу здесь, есть 5 посредственных ответов; Ответ GAThrawn наиболее близок к тому, чтобы быть наиболее информированным ответом, но это не полный ответ.

Ответы (6)

Я думаю, что нашел решение. Проверьте эту ссылку . Это взлом, и он требует, чтобы телефон был рутирован, но он позволяет вам использовать буквенно-цифровой пароль для шифрования и PIN-код для разблокировки экрана.

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

su -c vdc cryptfs changepw <new_password>

Где <new_password>должен быть заменен ваш пароль.

Источник: http://nelenkov.blogspot.be/2012/08/change-androids-disk-encryption.html

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

  • Вы увеличили количество доступных персонажей.
  • Вы лишили злоумышленников информации о вашей длине pw.

Если злоумышленник знает, что ваш пароль состоит из 14 символов, он более надежен, чем пароль из четырех или восьми символов, но в типичной статистике используются диапазоны (1-4, 1-8, 1-14), а не реальность (что было бы простым вычислением). доступные комбинации одной длины).

В настоящее время просто ОЧЕНЬ ЛЕГКО получить доступ к данным вашего телефона. У вашей бабушки есть такая возможность (не в обиду вам и вашей семье :P). Итак, хотя вы правы в том, что у этого шифрования есть ограничения, «сломанная» версия работает НАМНОГО лучше, чем незашифрованные данные, используемые в настоящее время.

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

Да, но я чувствую, что было бы простым решением проблемы иметь разные пароли для разблокировки экрана и для расшифровки устройства (как я упоминал здесь android.stackexchange.com/questions/17086/… ), поскольку они используются в разных senarios и должны иметь разные атрибуты.

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

Если вы атакуете диск напрямую, то в этом случае вы не атакуете 4-значный PIN-код или пароль пользователя, который шифрует устройство, вы атакуете 128-битный ключ AES:

Мастер-ключ — это 128-битное число, созданное чтением из /dev/urandom. Он зашифрован хэшем пароля пользователя, созданного с помощью функции PBKDF2 из библиотеки SSL. Нижний колонтитул также содержит случайную соль (также считанную из /dev/urandom), используемую для добавления энтропии к хешу из PBKDF2 и предотвращения атак радужной таблицы на пароль.

Из пункта 4 раздела " Включение шифрования на устройстве " Замечаний по реализации шифрования в Android 3.0 , на которые вы ссылались.

(должен был быть комментарий, но получилось слишком длинно)

Спасибо за этот приятный комментарий! Одна вещь, хотя; я не ищу пароль пользователя (который, скорее всего, будет 4-значным PIN-кодом, потому что вы вынуждены делиться ключом с разблокировкой экрана, и что-либо еще будет хлопотно вводить, чтобы сделать телефонный звонок) для расшифровки 128-битного ключ AES? (вместо прямого поиска ключа). Если я хеширую все 10 000 пинов с помощью функции PBKDF2 + соль, не будет ли у меня всего 10 000 попыток расшифровки?
@Melpomene « Атака радужной таблицы », о которой они говорят, - это когда вы предварительно шифруете все 10 000 комбинаций, чтобы увидеть, как они выглядят зашифрованными, а затем просто сравниваете то, что на диске, с тем, что в вашей радужной таблице. « Случайная соль » — это то, что помогает предотвратить это, создавая более 10 000 комбинаций, которые вам придется угадывать (если только вам не удастся сначала определить «соль»).
Радуга — это умный способ хранения зашифрованных паролей, да. И если используется соль, ее, вероятно, нужно будет специально сконструировать только для взлома паролей с помощью этой соли. Это не очень сложная операция, когда на выбор всего 10 000 паролей. Обратите внимание, что соль всегда считается известной злоумышленнику (поскольку кажется, что она читается из /dev/urandom в документах, скорее всего, она хранится либо в открытом тексте, либо в зашифрованном виде с помощью пароля пользователя). В любом случае пароль пользователя является слабым звеном.
Но мне даже не нужно было бы создавать радужную таблицу, поскольку хранение (или вычисление) 10 000 хэшей не так сложно для моей памяти (процессора).
Использование функции получения ключа, такой как PBKDF2, кажется хорошей новостью, но типичный 4-значный PIN-код по-прежнему содержит только 10000 возможных комбинаций.
Чтобы прояснить некоторую путаницу: соль хранится в незашифрованном виде в нижнем колонтитуле размером 16 КБ зашифрованного раздела. nelenkov.blogspot.be/2012/08/…

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

Я также заполнил запрос функции на странице проекта Android .

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

Проблема в том, что короткий PIN-код может защитить устройство, только когда оно включено. Таким образом, выключение украденного устройства предотвращает очистку устройства, и, кроме того, ПИН-код может быть взломан в ходе офлайн-атаки методом грубой силы. Следовательно, короткий PIN-код не поможет вам в этой ситуации.
@ Роберт, я не слишком хорошо знаком с тем, как работает удаленная очистка. Если это делается через Exchange, должен ли телефон находиться в тот же момент, когда выдается команда удаленной очистки? Я думаю, что если я могу выполнить удаленную очистку в течение 30 минут или около того после потери телефона, этого достаточно для меня, но у меня нет никаких финансовых данных, моя главная забота — моя рабочая электронная почта GMail.
Телефон должен быть включен и подключен к сети через некоторое время после того, как вы выполнили команду удаленной очистки. Если телефон был выключен (и остается выключенным), команда очистки бесполезна.
Достаточно ли безопасно использовать PIN-код для шифрования?
СпросиСетьПолитика конфиденциальности1y, 0v