Комментарии 12
Привет!
а почему windows 11 требует TPM? он же вроде не навязывает нам full disk encryption и face recognition
Если совсем коротко, то требование это не функциональное, а политическое. Дело в том, что Microsoft с 2012 года безуспешно пытается заставить производителей ПК сделать им нормальные корень и цепочку доверия, без которых все системы безопасности Windows, в том числе защита ядра при помощи виртуализации (Virtualization-Based Security) и другие подобные полезные (без дураков полезные не только майкрософту, но и пользователю конечному тоже) технологии защиты обходятся престейшими буткитами, доступными любому школьнику.
В итоге сначала попытались внедрить UEFI SecureBoot повсеместно, получилась фигня полная, потому что пользователю он мешал, и отключить его до сих пор проще, чем нормально настроить, и потому он отключен практически у всех, но даже с работающим SB сама прошивка (которую поставляет ОЕМ, а не MS) должна быть нормально защищена, а ОЕМы этого не умеют, и не хотят учиться.
Через 10 лет попыток наладить статический корень доверия (т.е. цепочку подписей у каждого следующего звена в цепочке загрузки, которые проверяли бы предыдущие звенья) в MS решили, что дело - труба, и обратили свой взор к динамическому корню доверия (DRTM - Dynamic Root of Trust for Measurement), который как раз и требует наличия TPM (а точнее, его PCR-подсистемы, либо аналога вроде DICE). Фишка DRTM в том, что там нет никаких подписей, а вместо них система отправляет в TPM т.н. "измерения" (measurements) каждого звена цепочки загрузки, и "запечатывает" (seal) набором этих измерений пользовательские секреты, т.е. если вдруг в загрузке что-то заметно поменяется, то пользователя попросят разобраться с этим, не прекращая при этом зашгрузку, но и не распечатывая секреты. Реализовать такую защиту проще, а в сочетании с технологиями вроде Intel TXT, они в пределе позволяют вообще выкинуть прошивку из цепочки доверия, т.е. пофигу какая там творилась вакханалия, измерения совпали, secure reboot выполнился - значит все нормально, можно дальше грузить ядро ОС и не переживать за то, что оно уже все в хуках как ёлка в иголках.
Вторым способом, который МС пробует сейчас, является поставка своего собственного корня доверия\сопроцессора безопасности - Microsoft Pluton, который они ставят на SoC партнеров - AMD и Qualcomm. Он тоже может работать как TPM, но там кроме ТПМа есть еще масса всего.
У Apple на системах с M-чипами статическим корнем доверия является SecureROM, а динамическим - SEPROM и SEPOS. Т.е. при загрузке система не только проверяет подписи каждого компонента, но и кладет хеши их манифестов (файлов с подписями) в специальные аппаратные регистры SEAL_DATA_A и SEAL_DATA_B, которые потом на каждом этапе загрузке сверяются с текущим состоянием, и если не сошлись - SEPOS откажет в доступе к ключам, а вместо загрузки macOS произойдет загрузка recoveryOS в режиме Key Recovery Assistant.
Итого: MS надоело бороться с буткитами, а без TPM или другого подобного железа бороться с ними невозможно, поэтому в Windows 11 они потребовали от производителей железа установку TPM на все совместимые системы. Работает ли ядро ОС без него - конечно, только оно получается "с голой жопой", а для MS это теперь не только нежелательная, но и неподдерживаемая конфигурация.
А ведь можно всего лишь обеспечить физически контролируемый загрузочный носитель с read-only перемычкой и так же защищённый биос с настройками. Всё! Ничего кроме доверенного не загрузится.
Это очень, очень, очень дорогое "всего лишь", в основном тому, что абсолютное большинство пользователей и покупателей ПК и ОС для ПК ничего не знают и не хотят знать ни про какие "прошивки", "БИОСы", "загрузки", "переключатели", "рид-онли" и тому подобное, им нужно чтобы крышку открыл - через полсекунды у тебя приглашение ко входу на мониторе, крышку закрыл - компьютер перестал батарею жрать. Представьте себе ситуацию, при которой этот переключатель включили в РО во время обновления ОС, и обновление не смогло продолжиться, как ОС должна рассказывать пользователю о том, что произошло, если она исполняется фиг пойми на чем, от кофеварок до боевых человекоподобных роботов, или наоборот пользователь забыл этот тумблер щелкнуть обратно, и теперь у нас опять жопа голая, а сделать мы не можем с этим ничего.
Нельзя считать пользователя совсем уж дураком стоеросовым, конечно, но и переоценивать его умение и желание разбираться в непонятном тоже не следует, и индустрия давно уже это поняла, а кто не понял - обанкротился уже вполне успешно.
Ну так и пользователь, который не разбирается в условных биосах, он и его и обновлять не лезет. А кто лезет на удачу, тот становится клиентом сервисного центра. Защиту от обновления и изменения конфигурации можно сделать элегантнее, но она должна быть железная и должна быть. Против соц инженерии и хакера с отвёрткой не работает. Но зато железно работает во всех остальных случаях. Вот есть же предупреждение про обновление на свой страх и риск и об опасности потери питания в процессе, и ничего, народ смело жмёт ДА. Так и тут, жми кнопку под крышкой и обновляй первичный загрузчик.
Защита от автоматических обновлений автоматически означает отсутствие обновлений у подавляющего большинства пользователей, а на такое теперь ни в коем случае нельзя пойти, потому что это опять же очень дорого - выпускать материнские платы с нормально работающей прошивкой прямо в первый же день, которые работали бы нормально без обновлений этой самом прошивки потом годами. ОЕМы никогда снова не пойдут на такое, потому что это увеличит им затраты на прошивки минимум десятикратно, а у них и так маржа 5% хорошо если.
Для UEFI пришлось выдумать стандартный механизм ESRT (EFI System Resources Table) и буквально заставить производителей поставлять свои обновления через Windows Update и Linux Vendor Firmware Service, потому что иначе заставить пользователя обновляться просто решительно невозможно, и он сидит с заранее сломанными прошивками с годами неисправленными уязвимостями, на которые в смысле безопасности надеяться - себя не уважать. Понятно, что там и на последние версии надежда такая-же, примерно, но отдать обновления в руки пользователя при нынешней культуре и стоимости разработки ПО (а прошивки - это ПО такое же, как и все остальное) - это ошибка.
Загрузка с накопителя в режиме "read-only" может "перепрыгнуть" на исполнение кода с другого накопителя, который в режиме "read-write".
Вот есть, например, CVE-2023-4001 (GRUB пытается исполнить конфигурационный файл с другого накопителя, а если не находит этот файл — выдает шелл: это в текущем виде есть обход пароля на GRUB при наличии физического доступа, но можно "докрутить" и до исполнения кода при наличии локального, привилегированного доступа — если подложить нужный конфигурационный файл на второй накопитель, перечисляемый до загрузочного). И таких сценариев еще много.
Сомневаюсь, что цель мс -- борьба с буткитом. Скорее с линуксом. Я что-то не слышал, что буткиты является бичом сейчас. Хотя работаю в ав компании. Я конечно не вирусный аналитик, но всеж.
Скорее с линуксом.
Никто не мешает использовать TPM с LUKS.
Но пользователи Linux, вместо распространения знаний, как защитить себя с помощью Secure Boot (используя свои ключи) и TPM (его можно использовать не только для шифрования, но и даже, например, хранить в нём SSH-ключи) предпочитают распространять мифы о том, что это клятая MS придумала для борбы с линуксом.
Подскажите, пожалуйста, изменилось ли ситуация с ИБ на рынке PC UEFI за 2 года с вашего старого комментария на эту тему?
И вопрос про хромбуки - они все на coreboot, но на актуальном железе и поддерживаются вендорами, в том числе Google. Имеет ли смысл с точки зрения ИБ купить хромбук и поставить на него обычный дистрибутив Linux, получив и безопасность и современное железо?
В полной мере воспользоваться этой очень интересной фичей можно при помощи полнодискового шифрования. Для этого предназначены утилиты dm-crypt (Linux) и BitLocker (Windows), при работе с которыми TPM распечатывает (то есть, выпускает и дешифрует) ключ, при помощи которого был зашифрован диск. Но это делается лишь в случае, если в регистрах PCR содержатся правильные значения измерений (т.e., целостность операционной системы гарантируется до выпуска ключа).
Всё это хорошо и удобно, но что делать если ПК сломался и всё это дело перенесли на другой комп платформа которого отличается от запомненной в PCR? Весь смысл же в том, что ключ шифрования как родился в TPM так его и не покидал. Или предусмотрена возможность его экспорта для бэкапа в укромном месте?
P.S.
Уровень статьи предлагаю перевести со "сложный" на "средний". В ней нет формул, алгоритмов, сложных схем и читается как общее введение в тему.
Знакомство с TPM (доверенным вычислительным модулем)