tg-me.com/sterkin_ru/1617
Last Update:
🔒 Гадание по картинке: доступ из-под Linux к зашифрованному тому BitLocker
Обычно я гадаю по логам, но на сей раз участник чата Michael отправил только картинку с описанием:
UEFI, TPM2. Windows 10 21h2. При попытке читать раздел C: с Linuxа спрашивает пароль. Раздел определяется как "BitLocker". При этом винда утверждает, что битлокер для C: отключен (насколько я понял, т.к. там только надпись: "turn BitLocker on"). Что делать-то?
Я ничего не знал про поддержку BitLocker в Linux, но товарищ dartraiden сразу подтвердил ее наличие. Тогда происходящее вполне объяснимо, если поверить Linux.
А вот что там "винда утверждает" - вопрос. Поэтому я запросил состояние BitLocker:manage-bde -status c:
Michael с ответом не спешил, но вполне можно разобраться даже по имеющейся скудной информации. Важно сочетание трех фактов:
🔹 Linux требует пароль от BitLocker.
🔹 При запуске Windows этот пароль не запрашивается. Иначе бы автор вопроса знал его наизусть, а по факту...
🔹 Он вообще ничего не знает про это шифрование.
Отсюда мои предположения:
🔸 Включилось автоматическое шифрование устройства, раз человек не в курсе. TPM 2.0 сочетается с ПИН- кодом и аппаратным ключом, но не с паролем при запуске.
🔸 При таком раскладе Michael может предложить Linux только 48-значный пароль восстановления. Иногда его ошибочно называют ключом восстановления (это - другое).
🔸 Не покидая Linux, извлечь этот пароль он может из облачных настроек учетной записи Microsoft (MSA), если уже входил с ней в Windows. В любом случае в Windows можно посмотреть это командой
manage-bde -protectors -get c:
Всё это мы обсудили даже без автора вопроса :) А когда он наконец вернулся, оказалось, что шифрование таки есть:Volume C: []
[OS Volume]
Size: 138.17 GB
BitLocker Version: 2.0
1️⃣ Conversion Status: Encryption in Progress
Percentage Encrypted: 90.5%
Encryption Method: XTS-AES 128
2️⃣ Protection Status: Protection Off
Lock Status: Unlocked
Identification Field: Unknown
3️⃣ Key Protectors: None Found
Процитирую свою статью об автоматическом шифровании:
Во время чистой установки по окончании этапа OOBE шифрование раздела с ОС и прочих несъемных дисков инициализируется с незащищенным ключом и приостанавливается. Когда первый вход выполняет администратор с MSA, шифрование активируется и защищается TPM. Одновременно 48-значный пароль восстановления сохраняется в облачных настройках MSA.
Я почти угадал! 🎉
По пунктам:
1. Диск еще не полностью зашифрован, а значит система была установлена совсем недавно. О незавершенном шифровании догадаться по картинке было невозможно.
2. Защита отключена. Michael еще не входил с MSA. Еще бы - потом выяснилось, что у него LTSC N 🌈
3. Предохранителей нет. После входа с MSA в списке предохранителей появляются TPM и Recovery Password.
🐧 С Linux же получается зачетная нестыковка, которая вызвана именно автоматическим шифрованием Windows. Зашифрованный диск не защищен, потому что не имеет предохранителей. Однако для доступа к диску Linux требует один из них - пароль. Пользователь же о нем понятия не имеет :)
Оставался лишь вопрос, примет ли Linux 48-значный пароль восстановления. И дальнейший тест это подтвердил! Обе ОС работают штатно.
////
С осени подобных случаев будет множество. Причину я буду разбирать отдельно. Не переключайте каналы ✌️
BY Windows 11, 10, etc - Вадим Стеркин
Share with your friend now:
tg-me.com/sterkin_ru/1617