id: Гость   вход   регистрация
текущее время 22:51 19/11/2017
Автор темы: Гость, тема открыта 08/03/2015 14:51 Печать
Категории: инфобезопасность, защита дисков
https://www.pgpru.com/Форум/ОбщиеВопросы/БолееКороткийПарольСОграничениемКоличестваПопытокВвода
создать
просмотр
ссылки

Более короткий пароль с ограничением количества попыток ввода


Добрый день. Предположим, у меня есть криптоконтейнер, который относительно часто нужен открытым. Допустим, он хранится у меня на телефоне, причём я [s]установил термитный заряд на датчики вскрытия и залил всё эпоксидкой[/s] исключил атаку "холодной загрузки" из модели безопасности.


В слоты LUKS я помещаю 2 ключевых фразы. Первая сама по себе криптостойкая, и я её ввожу при первом открытии контейнера. После этого программа считывает изнутри строку и помещает её в памяти. При следующем открытии контейнера я могу ввести другой, более короткий пароль, и программа попробует ввести в качестве ключевой фразы эту строку + только что введённый пароль. Результат сложения строки из криптоконтейнера и второго, короткого пароля – это второй ключ в слотах LUKS. Программа считает неправильные попытки ввода пароля и затирает в памяти часть второго ключа, если их сделано больше трёх.


Вопрос: насколько разумна эта схема для личных данных (того, что обычно хранится на телефоне) при условии, что он сам за мной не следит? Какого вменяемого размера можно делать хранящуюся в криптоконтейнере и короткую часть второго пароля?


 
Комментарии
— Гость (08/03/2015 20:58)   <#>

Напоминает иерархическое шифрование, про которое много раз писал unknown:

Без LUKS этого всего не достичь. Как, например и иерархического доступа: авторасшифровки одного контейнера при расшифровке пароля к другому (так чтобы сам ключ к другому контейнеру не лежал в открытом виде на ФС предыдущего), но с возможностью и расшифровки другим паролем по отдельности.

Считывание ключей из памяти штатной утилитой позволяет организовывать в Linux иерархическое шифрование, в т.ч. и безопасный гибернейт с шифрованием. ... Всё это может быть прописано в /etc/crypttab как производные от соответствующих ключей. Чаще всего от корневого ключа, так чтобы при входе в систему пользователю достаточно было один раз ввести пароль и всё это иерархически расшифровалось.

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

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


Я консервативно считаю, что не надо ничего хранить на телефоне такого, что стоило бы шифровать (т.е. такого, чего нет у ОПСОСа в биллинге).

Проблема слабых пассфраз в том, что они всегда слабые. Слуайную строку в памяти может похитить троян, она может утечь при хибернейте или ещё как... поэтому в итоге всё останется завязанным на ваш короткий пароль. На ПК нет проблем ввести 20-символьный пароль, чтобы получить стойкость хотя бы 128 бит, а как на телефоне — не знаю.


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

Вообще, ваш метод был бы безопаснее, если б вы делали как unknown: вместо двух паролей на один LUKS-контейнер сделали бы два LUKS-контейнера: один LUKS (со слабой пассфразой), вложенный в другой LUKS (со стойкой пассфразой). По крайней мере, тогда даже при самой фатальной утечке слабой пассфразы противник не получит доступа к данным, если ему достанется выключенный телефон.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3