Уже есть какие-то туториалы по созданию защищенных систем с SecureBoot?

зарегистрируйся как разработчик TPM у них есть доки для членов, там всё написано. Нужно быть юр. лицом и иметь пару тысяч баксов.

что-то ты набросал.

secureboot гарантирует проверку целостности первичного (efi) загрузчика. Этим efi-загрузчиком тебе нужно делать проверку загружаемого граба или ядра. Вангую, что придется писать такой загрузчик самостоятельно или подписывать ядро и грузить его из BDS. Подписания ядра можно свести к добавлению хеша в доверенную базу.

Вангую, что придется писать такой загрузчик самостоятельно или подписывать ядро и грузить его из BDS.

Я выше про GRUB-IMA писал. Или имелось в виду другое?

зарегистрируйся как разработчик TPM у них есть доки для членов, там всё написано. Нужно быть юр. лицом и иметь пару тысяч баксов.
доки для членов

https://ru.wikipedia.org/wiki/Док_(программа) За 2000$ и на юр лицо можно и получше док купить, чем TPM предлагает.

Берешь EDK2 (Tianocore), и конпеляешь. Там есть и SecurityPkg, который должен реализовывать Secure Boot. Впрочем, не знаю. Сей аспект меня не интересовал, я ограничился компиляцией под BeagleBoard и запуском бутлодера Windows/RT в Qemu

кто такой ima и как он связан с секурбут?

А Grub-IMA это не то же самое, что Trusted GRUB? Последний, как раз, работает с TPM, т.е. кидает в PCR-регистры свой stage1, stage2, grub.cfg и может кидать любые файлы, например, ядро и initrd. А уже в initrd вы можете написать скрипты для считывания ключей из TPM NVRAM для распаковки rootfs, например, которые будут зависеть от значений PCR. А если еще и накатить на ядро TRESOR, то вы будете защищены от дампа оперативки и нахождения в ней ключа для rootfs. Только все это никак не связано с SecureBoot, но защищает от распаковки вашей rootfs гораздо лучше.

UPD: да, Grub-IMA это Trusted GRUB. А есть еще Trusted Boot: http://sourceforge.net/projects/tboot/, он новее, вроде как.

Вы весьма интересная личность, но ожидал на ЛОРе такого ответа. Про TRESOR читал, однако, если брать вариант атаки с перезагрузкой и последующим дампом ключей, а не использования спец оборудования и охлаждающего газа, то ECC-память должна решить эту проблему, верно? (она же при ребуте будет реинициализована (а значит обнулена). Я вообще сомневаюсь, что даже при помощи спец оборудования можно без инициализации начать с ней работать. Но вот вопрос дампа изнутри ОС может быть интересным. :)

Кстати, как я понял, trusted boot помещает себя в защищенную TXT-область перед тем, как начать проверку ядра? Или зачем тут TXT?

не везде есть tpm=( токен годится для его замены?

не везде есть tpm=( токен годится для его замены?

Почти на всех системах. Про какую часть работы идет речь? Если их него надо получить ключ для расшифровки LUKS, то не вижу проблем. Если мы говорим про безопасную загрузку с самого начала, то токен тут не поможет: нужно, чтобы BIOS (UEFI) поддерживал проверку загрузчика. Если загрузчик можно подменить, то токен тебя не спасет.

то ECC-память должна решить эту проблему, верно?

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

Кстати, как я понял, trusted boot помещает себя в защищенную TXT-область перед тем, как начать проверку ядра? Или зачем тут TXT?

Не подскажу, к сожалению, не изучал.

А в Россию TPM уже официально поставляется?

А в Россию TPM уже официально поставляется?

У меня 4 компа точно его поддерживает. Покупал 1-3 года назад.

А учитывая Win8 с UEFI SecureBoot требованием, получается, что всё современное.

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

Вы уверены в этом?

Ага

Какие технологии защиты сами используете?

Да никаких, если честно, как-то не вижу в этом необходимости пока. Такие машинки с защитой мне приходится по работе копать.

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

Советую, кстати, посмотреть в сторону современных жестких дисков и SSD. Они умеют шифровать сами себя рандомным ключом, ключ к которому можно задать в биосе (пароль для доступа к диску)

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

Разве хардварный отладчик можно использовать как-то иначе, кроме как на спец платах, да из ОСи на уровне ядра?

Советую, кстати, посмотреть в сторону современных жестких дисков и SSD. Они умеют шифровать сами себя рандомным ключом, ключ к которому можно задать в биосе (пароль для доступа к диску)

Вам не кажется, что доверять подобным проприеритарным технологиям - не тру? И в чём (кроме простоты внедрения) преимущество перед тем же LUKS?

Да никаких, если честно, как-то не вижу в этом необходимости пока. Такие машинки с защитой мне приходится по работе копать.

Можно поподробнее? :)

Вам не кажется, что доверять подобным проприеритарным технологиям - не тру? И в чём (кроме простоты внедрения) преимущество перед тем же LUKS?

Автоматически защищает от дампа памяти, например, т.к. ключа для диска в памяти не будет. Да и шифрует не CPU, а микроконтроллер на винчестере.

Можно поподробнее? :)

Нет :)

Хм. Я тут подумал, что весьма интересно их использовать вместе с програмным шифрованием. Поскольку просто доверять их проприетарной прошивке нельзя, то это должно решить вопрос. Все-таки получить доступ к закладкам прошивки и сделать дамп оперативки одновременно будет сложно. А в случае использования IMA, TRESOR, trusted boot, UEFI Secureboot такой взлом почти нереален.

UEFI Secure Boot, к сожалению, не дает никакой устойчивости от взлома, если есть доступ к компьютеру. По сути, эта штука сделана для того, чтобы извне интерфейса UEFI (т.е. не в самом нем, а, например, посредством запуска вредоносного кода в ОС) нельзя было незаметно подменить файлы. Если же доступ к компьютеру, а, соответственно, и к UEFI есть, то ничто не мешает добавить свои ключи и заменить загрузчик. И никакой пароль на изменение настроек UEFI не поможет, т.к. решается сбросом CMOS.

Я прочитал про Intel TXT, оказывается, я думал, что это реализует сам TPM, т.е. кидает в регистры биос, параметры биоса и прочее, а это, оказывается, именно Intel TXT делает. Я сталкивался только с безпарольными реализациями, т.е. есть зашифрованная ФС, есть ключик к ней в TPM NVRAM, все грузится без всяких паролей, и если меняешь настройки Trusted Grub — не монтируется, меняешь ядро — не монтируется, меняешь initramfs — не монтируется, т.к. регистры просто не совпадают, а из ОС выпилено все, даже ctrl+c в консоли не работает обычно.

Варианты, когда нужно именно обычное десктопное/лаптопное решение, мне не встречались, но, думаю, их реализовать действительно сложнее, т.к. после запуска будет запущена уже полноценная ОС, из нее можно при определенных условиях вытащить данные, и можно, например, подделать initramfs, чтобы она делала вид, что пароль введен неверный, когда его вводят верный, и отправляла данные куда-нибудь на удаленный сервер. В этом случае, ну и что, что регистры в tpm не совпадают, ведь пароль же у нас, можем загрузить уже оригинальный initramfs и все распаковать. А вот вариант с шифрованием именно винчестера средствами ATA кажется мне наименее геморройным, хоть и, конечно, немного боязно, фиг знает, что там производитель понаделал.

UEFI Secure Boot, к сожалению, не дает никакой устойчивости от взлома, если есть доступ к компьютеру. По сути, эта штука сделана для того, чтобы извне интерфейса UEFI (т.е. не в самом нем, а, например, посредством запуска вредоносного кода в ОС) нельзя было незаметно подменить файлы. Если же доступ к компьютеру, а, соответственно, и к UEFI есть, то ничто не мешает добавить свои ключи и заменить загрузчик. И никакой пароль на изменение настроек UEFI не поможет, т.к. решается сбросом CMOS.

Я как-то забыл про момент со сбросом CMOS.

Я прочитал про Intel TXT, оказывается, я думал, что это реализует сам TPM, т.е. кидает в регистры биос, параметры биоса и прочее, а это, оказывается, именно Intel TXT делает. Я сталкивался только с безпарольными реализациями, т.е. есть зашифрованная ФС, есть ключик к ней в TPM NVRAM, все грузится без всяких паролей, и если меняешь настройки Trusted Grub — не монтируется, меняешь ядро — не монтируется, меняешь initramfs — не монтируется, т.к. регистры просто не совпадают, а из ОС выпилено все, даже ctrl+c в консоли не работает обычно.

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

Варианты, когда нужно именно обычное десктопное/лаптопное решение, мне не встречались, но, думаю, их реализовать действительно сложнее, т.к. после запуска будет запущена уже полноценная ОС, из нее можно при определенных условиях вытащить данные, и можно, например, подделать initramfs, чтобы она делала вид, что пароль введен неверный, когда его вводят верный, и отправляла данные куда-нибудь на удаленный сервер.

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

А вот вариант с шифрованием именно винчестера средствами ATA кажется мне наименее геморройным, хоть и, конечно, немного боязно, фиг знает, что там производитель понаделал.

Самое ужасное, что в случае физического доступа к серверу можно добавить туда, скажем, флешку, которая будет запускать буткит/гипервизор, UEFI Secureboot отключается или добавляется новый ключ. Далее злоумышленник получает пароль при вводе. Пароли на hdd вообще не важны, т.к. в данном случае неважно есть прослойка аппаратного шифрования или нет.

Неужели никак нельзя заблокировать возможно clearcmos/вшить пароли или что-нибудь в этом духе? Отсутствие доступа к настройкам биоса легко решило бы все проблемы безопасной загрузки.

особенно, если мать не может (обычно, это проблема обладателей говнонетбуков) грузить ОСь в старом стиле (MBR-загрузчик)

Ещё остались дистрибутивы, в которых нет grub-efi?

Во многих не-мейнстримовых он либо автоматом не ставится, либо его вообще нет в основном репозитории (гента, слака).

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

В генте он в основных репах, только при сборке надо выставить use-флаг efiemu. А так даже ругаемый всеми за слоупочность дебиановский инсталлятор сам определяет в каком режиме загрузился и в зависимости от этого подтягивает grub-efi или grub-mbr. Я думал, что в других дистрах это давно уже.

В случае обычной установки намного проще переключить мать в режим совместимой загрузки и использовать дедовский MBR.

Честно говоря, не вижу смысла. Ты точно не путаешь просто uefi и uefi с включённым SecureBoot. Я говорю про первый вариант. SecureBoot я не пробовал и не собираюсь. Не вижу смысла в этом извращении.

Нет, не путаю. Переформулирую: я не вижу преимуществ в использовании EFI-загрузчика с UEFI-биосом перед MBR-загрузчиком с UEFI-биосом с совместимом режиме, если только не использовать расширение UEFI Secure boot (соответственно уже с совсем другим загрузчиком) для организации доверенной загрузки.

Блин, написал вам большое сообщение, да браузер тупанул и не отправил.

Можно ссылку на манул по подобной работе intel TXT?

Я на википедии смотрел, там «измеряются» BIOS, CMOS, MBR, Lan Boot Rom даже может, и кидается в регистры, или регистры дополняются (sha1(новые данные + старый sha1)), конкретно задать значение регистра нельзя. Есть TPM NVRAM, который можно привязать к определенным значениям регистра.

А почему на Ваших устройствах так нельзя сделать? Только из-за минимизации окружения?

Грубо говоря, да. В моих устройствах нужно защитить данные от вытаскивания, а не запретить выполнять неподписанный код.

Но, вдруг, там есть брешь для эксплойта?

Это чуть ли ни единственная уязвимость

Кстати, в Ваших устройствах как реализована невозможность доступа к биосу (они вообще x86-процессоры используют)?

Часто биос либо кастомный, либо вообще невероятно кастомный (грузит кастомные ISO файлы с FAT32 раздела, загрузчик линукса встроен в биос) Там, где он не кастомный и используется TPM, обычно боязно заходить в настройки, т.к. при изменении настроек могут поменяться значения регистров PCR и загрузка не удастся.

они вообще x86-процессоры используют

Обычно да.

И как, в общем, выглядит их полный алгоритм доверенной загрузки?

Есть, например, LUKS, есть ключ к нему в TPM NVRAM, привязанный к PCR, и есть Trusted GRUB. Меняем ядро — ключ не достается, меняем initramfs — ключ не достается, меняем stage1, stage2 или просто menu.lst — ключ не достается. Ну и изнутри ОС никаких файлов не достать, никаких программ не запустить, обычно там полноэкранное приложение и нет других консолей.

Самое ужасное, что в случае физического доступа к серверу

На сервере точно не нужен пароль на HDD, там подойдет технологая, как в моих девайсах. И даже никакой secure boot не нужен.