dm-crypt смена пароля


При установке Debian 5 всё, кроме /boot, было зашифровано dm-crypt. Возникла необходимость сменить пароль. Как это сделать?

Комментарии
— unknown (24/04/2009 14:09)   
посмотрите все разделы и тома, прописаные в fstab, которые зашифрованы с помощью dm-crypt LUKS с помощью luksDump:



Там скорее всего будет только один слот с паролем.

Добавьте второй пароль:



Теперь вы можете загружаться с двумя паролями – старым и новым.

Когда вы как следует выучите новый пароль, можете удалить старый пароль из первого слота:

— SATtva (24/04/2009 14:12)   
Добавьте во второй слот новый пароль, а первый слот удалите:



Для подробностей man cryptsetup.
— unknown (24/04/2009 15:25, исправлен 24/04/2009 15:25)   
Точно, в примере при удалении слота с паролем я забыл указать раздел перед ним
— Гость (24/04/2009 15:48)   
Спасибо за помощь. А как работает luksDelKey? В смысле как затирает ключ? И чем отличается от luksRemoveKey и luksKillSlot?
— unknown (24/04/2009 16:40)   
в последней версии вроде бы хотели отказаться от luksRemoveKey и luksKillSlot, сделав так, чтобы luksDelKey затирал слот по умолчанию.

Принцип такой, что мастер-ключ зашифрован в своих слотах своими паролями. причём зашифрован с дополнительной информацией, с распределением данных по специальному алгоритму "antiforensic information splitter", предназначенным против восстановления информации с винчестеров и носителей с избыточной информацией (типа RAID), так чтобы с каждым нечитаемым/повреждённым/затёртым битом даже при знании пароля восстановить ключ было бы экспоненциально сложнее.

Соответственно удаление данных из слота не требует особо долгого многократного затирания, так как данные сами по себе представлены в "хрупком" виде. Но по этой же причине нежелательно делать копии контейнеров, хранить их в виде отдельных файлов, записывать на болванку. Лучше создать для копии второй контейнер, пусть с таким же паролем, но чтобы ключи в нём сгенерились другие и синхронизировать данные с ним.
— spinore (24/04/2009 22:03)   
Вот это – хороший топик, правильный. Мне нравится. А то развели тут соплей с PGP Holy Disk на весь форум...
— unknown (25/04/2009 12:16)   




В общем, как написано в man, для удаления старого пароля из слота нужно использовать luksKillSlot, luksDelKey – это тоже самое, но только устаревшее название опции, которым надо отучаться пользоваться.
А вот что такое luksRemoveKey подробно не описано, могу предположить – это чтобы не стирать пароли из всех слотов по одиночке, а убить ключ от контейнера разом.

Экспериментировать со всем этим надо поосторожнее, хотя cryptsetup-LUKS предупреждает, когда остаётся только один единственный последний слот с ключом.
— SATtva (25/04/2009 12:29)   
Занятно, в моей Генте man cryptsetup содержит только luksDelKey. Версия актуальная — 1.0.6.
— unknown (26/04/2009 15:01, исправлен 26/04/2009 15:06)   
Не знаю, как там в вашей Генте, а вот в Debian Lenny тот же cryptsetup 1.0.6 наверное какой-то особенный и ман и пишут одно и тоже. наверное дебиановцы опять всё пропатчили по своему, так же как когда-то OpenSSL[link1].

Кстати, список крипторазделов после установки, которые поднимаются автоматически, лучше смотреть не в /etc/fstab, а в /etc/cryptab.
— Гость (08/04/2013 04:51)   

Ещё поглядел на /comment45783[link2]. Стало ли вам что-то с тех пор понятней?
Что именно делает luksRemoveKey? Фразу (из man) про него
remove supplied key or key file from LUKS device
можно как угодно понимать.

Точно ли luksClose удаляет ключи из памяти? В man написано, что он
removes an existing mapping <name>
и всё. Понимать это можно, как угодно. В интернетах всякое пишут, но стоит ли доверять непонятно чьим разъяснениям в рассылках... Где можно почитать о luksClose в официальной документации?

Зато про luksSuspend написано явно:
wipes encryption key from kernel
Чем он отличается от luksClose? Удаляет ключ, но оставляет ассоциацию «дисковый раздел ↔ метка»? В man пишут, что после него можно сделать luksClose, хотя ключи к тому моменту уже могут быть удалены. Или luksClose делает luksSuspend, если ключ в памяти не завайплен, а потом собственно диассоциирует раздел с меткой?

Как связаны между собой эти три команды (luksRemoveKey, luksClose и luksSuspend) — не понятно. C deprecated-опциями всё ясно, но в моём man (версия 1.1.0-rc2) все эти три не отмечены, как deprecated.
— SATtva (08/04/2013 07:35)   
Точно ли luksClose удаляет ключи из памяти?



Где можно почитать о luksClose в официальной документации?

https://code.google.com/p/cryptsetup/
— Гость (08/04/2013 08:42)   
В моей версии фразы «wipes the key from kernel memory» нету:

— SATtva (08/04/2013 08:56)   
Обновите версию. Или читайте исходники.
— Гость (30/11/2013 11:51)   
при установке debian диск был полностью зашифрован, а /boot размещен на другом носителе. теперь вопрос: слот с паролем находится на зашифрованном диске? ибо dev нужно правильно указать.
— Гость (30/11/2013 18:21)   
Cлот с паролем находится в заголовке шифрованного раздела, /boot тут ни при чём, он только указывает, откуда грузиться и с какими опциями.
— Гость (30/11/2013 19:07)   
Спасибо.
cryptsetup luksAddKey /dev/раздел
cryptsetup luksDelKey /dev/раздел 1


а почему в этом примере при удалении указаны разные разделы? "1" – это опечатка?
— Гость (30/11/2013 21:09)   
1 — это номер слота. Всего есть 8 слотов (0-7), из которых обычно используется только часть, и, чаще всего, если вы не делалили никаких манипуляций, то только один — с нулевым номером. Вывод команды
# cryptsetup luksDump /dev/раздел
показывает, что к чему, выполните её. Как правило, 1 — первый свободный слот после занятого (т.е. нулевого), поэтому указано 1.
— Гость (14/02/2014 11:05)   

Делаю по рекомендации:
# cryptsetup luksAddKey <device>
Убеждаюсь, что теперь обе пассфразы работают, и старая и новая:
# cryptsetup luksOpen <device> name
luksDump показывает, что заняты 2 слота, т.е. всё как положено. Завершающий этап, стираем старую пассфразу:
# cryptsetup luksKillSlot <device> 0
Команда просит ввести any passphrase (т.е. должна работать и старая и новая пассфразы), однако затереть старой пассфразой нельзя, она её не примнимает. Новой пассфразой затирается успешно. Почему так? Ведь по легенеде ввод какой-то пассфразы для luksKillSlot — не более, чем защита от дурака[link5].

P.S.
$ cryptsetup --version
cryptsetup 1.4.3
— SATtva (14/02/2014 11:29)   
Вероятно, логика та же: защита от дурака надо убедиться, что пользователь знает какую-нибудь пассфразу, помимо удаляемой.
— Гость (23/02/2014 04:24)   

Шифрпанк во всей красе А что, трудно было об этом написать в информационном сообщении, сопутствующем запросу пассфразы? Если понимать вопроc так, как он задан, то LUKS лжёт: написано «любая», а «любая» не работает. Только не надо писать про багрепорты.
— SATtva (23/02/2014 09:42)   

Okayface.jpg
— Гость (24/02/2014 20:32)   
# cryptsetup luksAddKey /dev/раздел
Enter any passphrase:
<123>
No key availabe with this passphrase
Any — это любая (например та, которую я хочу добавить), а старые, уже существующие, было бы более уместно назвать any valid, что точнее намекает на суть.
— Гость (03/03/2014 05:41)   

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

P.S. После такой логики LUKS трудно привыкнуть к тому, что вводить старую пассфразу для смены пароля рута вообще не надо.
— Гость (13/05/2014 10:37)   

Если заголовок LUKS-тома случайно попадает на bad-блоки на диске, то что будет? Пароли съедятся, информация запишется, но потом её будет не расшифровать. По-моему, у меня сейчас уже второй раз такой глюк происходит с одним и тем же LUKS-разделом.
— unknown (13/05/2014 11:09)   
Разработчики вроде планировали дать возможность и на ёлку залезть, и ничего при этом не ободрать: заголовок хотели делать и в начале, и в конце шифротома с функцией аварийного восстановления. Но в своей версии ничего такого пока не видел.
— Гость (29/05/2014 07:22)   
Перефразируя известное правило, можно сказать, что «люди делятся на 2 типа: тех, которые делают бэкапы LUKS-хидеров и и тех, у кого не было в них bad-блоков».

К одному разделу сколько ни вводил пароль, он не подходил. Перезагрузился, попробовал в другой день — подошёл. Стёр пот с лица. К другому разделу (для него бэкапы уже были) как ни вводил пароль, всё не получалось. И раздел такой, что редко монтируется, не должны там быть bad-блоки. В итоге решил попробовать модификации пассфраз и выяснил, что пароль стоял там не тот, какой должен был быть и какой я думал. Тоже открылось. Но с тех пор я бэкаплю хидеры.

Кстати, странно, что LUKS'у нельзя указать внешний хидер параметром. Надо восстаналивать хидер, как я понял, на самом разделе, а потом пробовать его открыть. А что толку, если там bad-блок будет? Он же по сути не сможет в это место что-то записать. Записываться будет одно, а читаться другое.

Вообще, с bad-блоками, наверное, можно побороться брутфорсом, но с учётом того, что там в LUKS стоит соль и много итераций для замедления, перебор тысяч вариантов (допустим, поменялся один-два байта из сотен байт, содержащих хидер) может растянуться на непозволительно длительный срок...
— Гость (10/06/2014 06:34)   

Те, кто знают, что они делают, могут существенно упростить[link7] себе жизнь:
# cryptsetup -q luksKillSlot /dev/DEVICE 0
И никаких пассфраз вводить не надо. Для быстрого уничтожения информации такая штука — самое то.
— Гость (07/08/2014 21:28)   

В новых версиях можно — опция --header.

Ссылки
[link1] https://www.pgpru.com/novosti/2008/predskazuemyjjgschinebezopasnyekljuchivdebianubuntu

[link2] https://www.pgpru.com/comment45783

[link3] https://www.pgpru.com/comment29957

[link4] https://www.pgpru.com/comment29988

[link5] https://www.pgpru.com/comment62765

[link6] https://www.pgpru.com/comment29963

[link7] https://www.pgpru.com/comment80575