Comments 29
TPM 2.0 только сейчас начинает появляться в железе, зачастую вместе с обновлениями BIOS.
Да уже скоро 4 года, как оно есть у Intel (начиная с H110), а у AMD, если не изменяет память, начиная с Ryzen.

И это лучше, чем ничего, поскольку колодка для подключения внешнего TPM даже на дешевых платах с топовым Z-чипсетом (например, ASUS Z170-P) в целях экономии не распаиваивается (хоть посалочное место есть, и то хорошо), а на самых бюджетных платах и того нет.

Secure Boot с установленными сертификатами Microsoft эквивалентен его отсутствию
А как вы без сертификата Microsoft решаете проблему с запуском GOP-драйверов внешних видеокарт, PXE-драйверов внешних сетевых карточек, NVME-накопителей? Если с видеокартами ещё можно слить из них прошивку и подписать с помощью какого-нибудь GOPUpdater, то о существовании инструментов для NVME-дисков мне неизвестно.
Мне на ASUS B150M-C и на Dell Inspiron 3552 пришёл TPM 2.0 только с обновлением BIOS где-то в конце прошлого года. До этого TPM 1.2 просто никак не получалось завести на линуксе.
Как раз в конце 2018 для этой платы вышла новая мажорная версия прошивки (3xxx -> 4xxx). Интересно, с чем связано отсутствие до этого. На моей Z170-P поддержка PTT присутствует, как минимум, с 2016 года (более ранние прошивки я просто не проверял).
С secure boot ещё не все опции ядра работают. Например на некоторых моделях Lenovo невозможно включить турборежим процессора из-за неверных таблиц acpi.

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

Ну а если Linux убил прошивку (как уже бывало из-за рукожопости инженеров Lenovo), то уже всё равно, какие там были ключи, и такое убиение может случится вообще независимо от состояния Secure Boot.
Кстати, все рецепты, которые я привёл в статье (ссылка на рецепт для федоры и мой репозиторий) предусматривают резервное копирование ключей первым делом.

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

Да, всё верно, если известно, что техника скомпрометирована — остаётся только зачистить под ноль. Если полагаться только на это, то нужно заменять компьютер после похода на обед/в туалет более чем на полчаса; после сдачи в багаж в аэропорту; после потери питания в датацентре, если это сервер; после сдачи в сервис и так далее.

Я проще сделал, у меня загрузчик с luks header'ом на флэшке. Но full chain, конечно, лучше.

Я конечно не спец в шифрованиях, но выходит без этих танцев с security boot и загрузчиками, весь этот LUKS безтолку? Реально все так просто разшифровывается.
Если технику просто украдут, то шифрование поможет. Если незаметно такое провернут и владелец воспользуется компьютером — да, проблема. Secure Boot настроить не так трудно — пару раз в BIOS зайти и несколько команд прогнать.
Тут по сути ситуация похожа на фишинг паролей через сайты-подделки. Только по адресу сайта-подделки обычно видно, что это не тот сайт, а тут нет.
Так ещё надо настроить переподписывание ядра и initrd при обновлении, как-то организовать offline хранение корневого сертификата. И при любой ошибке иметь риск остаться без компьютера.
Решение в статье предусматривает переподписывание. Сертификат не представляет из себя особой ценности — при необходимости заходите в BIOS, вводите пароль администратора и сбрасываете платформу в режим установки. В статье этот момент оговорен.
Если вы неуловимый Джо (в 99.99% так и есть) LUKS спасёт от очень любопытных глаз тех, кто может получить получить доступ к вашему компу/жесткому диску. Если кто-то собирается провести против вас операцию по подмене загрузочных файлов, то у вас уже неприятности.
без этих танцев с security boot и загрузчиками, весь этот LUKS безтолку?

Каждый из этих «танцев» защищает от своего сценария атаки.

1) Шифрование данных защищает от «воткнули любой LiveCD/воткнули диск в другой ПК, наплевали на авторизацию в системе и полезли смотреть содержимое диска». Это самое актуальное для большинства пользователей, поскольку накопитель можно потерять (вместе с ноутбуком), либо туда могут попытаться сунуть нос любопытные враги в погонах.

2) SecureBoot защищает от «в отсутствие владельца подменили его загрузчик GRUB на собранный злоумышленником кастомный GRUB, который логгирует введённый пароль и куда-то его сохраняет, чтобы потом можно было его заполучить» (атака EvilMaid). Если против вас такое организовали, то вы уже явно не рядовой пользователь.

3) Пароль на вход в настройки BIOS защищает от «зашли в биос, отключили SecureBoot и провернули п.2».

4) Использование TPM при шифровании защищает от «вытащили батарейку, сбросили пароль на биос, провернули п.3 и п.2» и от «прошили изменённую прошивку со встроенным UEFI-руткитом».

Безопасность — это комплекс мер. Например, использование лишь SecureBoot с собственными ключами защитит от подмены аагрузчика, но не защитит от банального «втыкаем диск в другую машину и смотрим содержимое».

Плюс ещё и разработчики операционных систем должны не зевать. Например, шины Thunderbolt и FireWire позволяют получить прямой доступ к оперативной памяти (откуда можно выудить ключ шифрования системного накопителя). Поэтому, разумно сделать так, чтобы устройства, вставленные при заблокированном сеансе (когда пользователь отошёл), не подключались. В Windows 10, например, это реализовано с помощью групповых политик, начиная с 1607 (а в 1803 добавили автоматически включаемую Kernel DMA Protection for Thunderbolt 3, правда, только при использовании процессоров Intel).
Почему вы выбрали путь с отдельным загрузчиком, initramfs и т.д., а не шифрование /boot и установку подписанного загрузчика?
Главная причина — это было бы полумерой. Шифрование LUKS1 (LUKS2 c integrity GRUB не поддерживает) не гарантирует целостность данных. Действительно, подмену сформировать трудно, но не невозможно: см. слабые стороны XTS. Вместо этого я предпочёл иметь криптографические гарантии, что ядро подписано, конфиг GRUB подписан, инитрамдрайв подписан. О сомнительной пользе шифрования /boot я упоминал в статье.

В дополнение к этому такая схема легка во внедрении и сохраняет возможность воспользоваться оригинальным загрузчиком, отключив Secure Boot. То есть пользователь такого рецепта особо ничем не рискует, развёртывая это у себя на копьютере.
Ссылку на запрос на поддержку LUKS2 для GRUB оставлю здесь: savannah.gnu.org/bugs/?55093.
В случае btrfs подмена легко выявляется ввиду сохранения контрольных сумм файлов в ФС.

Но разве подмена выяснится не после ввода пароля?
или сразу вывалится ошибка с несоответствием контрольных сумм?

При каждом монтировании проверяться все файлы не могут. Насколько мне известно, btrfs проверяет данные при их чтении. Для проверки всего диска можно использовать btrfs scrub start.
Ноутбуки как правило подключаются к сети Интернет через WiFi и соотвественно в момент загрузки ноутбука после ввода пароля к сети с помощью вашего скрипта ноутбук подключиться не сможет, если только не подключится к какой-либо открытой точки доступа без пароля(которых сейчас практически нет, используется авторизация через смс), а уже после загрузки самой системы ваши скрипты не будут работать. Получается, что ноутбуки уязвимы только если подключены к ethernet?
Нет, можно дождаться появления интернета для отправки пароля, спрятать ключ где-то на диске, добавить свой пароль на диск в кейслот LUKS, всё что угодно. Скрипты в моей демонстрации написаны для образовательных целей, а не для нужд практикующих злоумышленников.
Не пользовался им, но принципиальных отличий тут нет. Проблема не в самом способе шифрования, а в том, что можно вмешаться в работу компьютера до разблокировки и направить дальше действия компьютера в нужное для извлечения данных русло.
Получается из коробки даже упомянутые в статье Fedora и OpenSuSE не дают достаточной защиты при включенном Secure Boot? Так же любой вариант может быть скомпрометиррован при отсутствии пароля на bios?
А насколько пароль на биос надежная штука? То есть разве он не сбрасывается елси там батарейку вытащить? Или чето подпаять. Просто не сильно шарю в этом.
Ненадёжная, но придётся корпус точно вскрывать. Ну и если видно, что корпус вскрывался и Secure Boot сброшен, то как бы всё понятно.

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

  • Встроить аппаратный кейлоггер между клавиатурой и устройством, позже забрать его или получить беспроводным методом. Это никак не определить без дополнительных мер защиты конкретно против такого способа получения пароля.
  • Полностью подменить биос/чипсет и накопитель, чтобы процесс загрузки визуально соответствовал привычному. После ввода пароля не важно, что система не загрузится, пароль-то уже будет отправлен по сети. Даже если на биосе при включении стоит пароль, можно сделать так, чтобы он принимал любой пароль, всё равно никто не вводит сначала неправильный, чтобы убедиться в корректности алгоритмов.

Only those users with full accounts are able to leave comments. Log in, please.