https://opennet.dev/openforum/vsluhforumID3/135794.html Один из сопровождающих пакеты в NixOS представил технику атаки, позволяющую получить доступ к данным на зашифрованных дисковых разделах, в конфигурациях, не требующих ввода пароля разблокировки при загрузке, благодаря размещению в TPM2 (Trusted Platform Module) информации для расшифровки. Такие конфигурации часто используются на серверах или многопользовательских рабочих станциях, на которых проблематично после каждой перезагрузки вручную вводить пароль...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62574<br> https://opennet.dev/openforum/vsluhforumID3/135794.html#133 Tue, 21 Jan 2025 16:18:20 GMT Чем-то напомнило документацию, согласно которой идентификаторы мобилы должны записываться без возможности перезаписи. Но сименс вертела требования и ставила обычную в некоторые свои мобилы( потому что той памяти у них дофига было и кто будет проверять ? ). Их потом ещё долго даже бу-шные искали и весьма за дорого <br> https://opennet.dev/openforum/vsluhforumID3/135794.html#132 Mon, 20 Jan 2025 13:57:54 GMT BadUSB в помощь :)<br> https://opennet.dev/openforum/vsluhforumID3/135794.html#131 Mon, 20 Jan 2025 13:45:44 GMT &gt; Хранить на внешнем носителе<br><br>Вводить-то ты его как собрался? Бегать с внешним носителем?<br><br>Руками битовые ключи набирать - такое себе.<br><br> https://opennet.dev/openforum/vsluhforumID3/135794.html#130 Mon, 20 Jan 2025 10:17:18 GMT &gt; так устроен luks. Что в общем логично, где ж его еще хранить. Твой пароль - это НЕ ключ.<br><br>Хранить на внешнем носителе (бумаге, сейфе, юсб и т.д.), зачем давать атакующему инфу о ключе (даже пусть и зашифрованному). А в случае с паролем, ясно что не ключ, но можно через всякие KDF функции пропускать, при соблюдении длины пароля (в битах, 32 символа пароля поди пробрутфорсь)<br><br>&gt; Попутно это позволяет иметь запасной пароль или поменять засвеченный существующий,<br>&gt; Там аж 8 слотов для разными способами позашифрованного ключа.<br><br>А это вообще маразм, помимо того, что дали инфу о ключе (зашифровав и храня на носителе основной ключ шифрования данных), мы еще этот ключ (ключ шифрования данных) пошифровали разными ключами, и тем самым дали дополнительной инфы криптоаналитику.<br><br>&gt; (tpm'ом в качестве мастер-ключа воспользоваться не получится, потому что его производительность никакая)<br><br>ну эт понятно, он не для этого предназначен.<br><br>пс: LUKS, по мне, лучше не использовать в серьезных целях. А первый блок на дисках https://opennet.dev/openforum/vsluhforumID3/135794.html#129 Sun, 19 Jan 2025 21:03:59 GMT &gt; Так это нормальный механизм со стороны initrd, запросить ручного ввода ключа, фолбек<br>&gt; своего рода, мало ли что TPM перегрелся и не работает. <br><br>вот тут надо было сбросить регистры (не работает - хрен с ним, но хотя бы попытаться).<br>Т.е. просто вывести tpm из состояния когда он согласен что-то дешифровывать - все, мы стартуем с вручную введенным паролем, значит система ненадежна. Хз почему это не сделано.<br><br>&gt; Я вообще не понимаю зачем, в заголовке хранить второй ключ <br><br>так устроен luks. Что в общем логично, где ж его еще хранить. Твой пароль - это НЕ ключ.<br>(во-первых, сам ключ ты немного подза...шься набирать, во-вторых он bit aligned, в-третьих при про..бе пароля или отказе вон tpm ты все же наверное хочешь иметь какой-то запасной вариант)<br>Попутно это позволяет иметь запасной пароль или поменять засвеченный существующий, не перешифровывая заново все терабайты - очень так себе процедура, поскольку адски долгая да еще и при сбое можно ненароком лишиться пула. Там аж 8 слотов для разными способами позаши https://opennet.dev/openforum/vsluhforumID3/135794.html#128 Sun, 19 Jan 2025 19:32:31 GMT &gt; там надо было как минимум сбрасывать состояние в момент когда с ключом что-то явно пошло не так<br><br>Так это нормальный механизм со стороны initrd, запросить ручного ввода ключа, фолбек своего рода, мало ли что TPM перегрелся и не работает. Тут надо сделать так, чтобы initrd как-то понимал (был привязан) "родной" шифрованный раздел. А сделать это безопасно можно только через TMP (запихнуть какую-нибудь инфу о разделе в PCR регистры), но мы же выше говорим, что у нас TPM "перегрелся", тогда откуда эту инфу получить в итоге? И получается фолбек дает нам возможность вручную ввести ключ расшифровки, но при этом initrd не сможет верифицировать расшифрованный раздел. Вот тут и вся фишка с подменой раздела. Отсюда думаю, раз систему явно сконфигурировали на использования TPM, то никакого фолбека быть не должно, и должна быть верифицируема привязка ключа в TPM к шифрованному разделу.<br><br>&gt; действительно tpm'ом расшифровывается ключ люкса, а не хранится в tpm.<br><br>поэтому и нужно запустить свой инит, чтобы получить доступ https://opennet.dev/openforum/vsluhforumID3/135794.html#127 Sun, 19 Jan 2025 16:44:01 GMT там надо было как минимум сбрасывать состояние в момент когда с ключом что-то явно пошло не так (понадобилось бы модифицировать как минимум initrd, чтобы и это обойти, что уже может оказаться слишком сложно - он подписан).<br>Этого, как я понимаю, и нету. <br><br>Но как минимум вторая претензия снимается - тут "промтом переводили", действительно tpm'ом расшифровывается ключ люкса, а не хранится в tpm.<br><br>Ну ок, не все так печально как могло бы быть, но все равно как-то не айс.<br><br> https://opennet.dev/openforum/vsluhforumID3/135794.html#126 Sun, 19 Jan 2025 16:12:51 GMT &gt; нахрена же ж он вообще извлекаем в принципе<br><br>И собственно ответ: ключ извлекаем, то есть как мы поняли, требующийся дешифровки на устройстве TPM, первичный (КЕК, мастер-ключ) ключ LUKS-а, который необходим для дешифровки уже на CPU, вторичного ключа LUKS-а, ключа шифрования данных, потому-что это механизм автоматической разблокировки (расшифровки) шифрованного раздела, для которого необходимы все эти ключи.<br> https://opennet.dev/openforum/vsluhforumID3/135794.html#125 Sun, 19 Jan 2025 16:05:19 GMT добавочка:<br><br>--tpm2-seal-key-handle=HANDLE<br><br>"parent key" (SRK) - вот этот ключ не извлекаем.<br>