Иногда я ищу тему, о которой можно написать, и понимаю, что есть одна, которую, как я полагаю, я охватил, но при поиске обнаруживаю, что нет. Существуют определенные процедуры, в которых эти термины используются с заглавными буквами (например, безопасная загрузка), и я постараюсь не обсуждать их в этой статье. Меня больше интересуют общие процессы – и главный потенциальный провал – чем попытки вдаваться в подробности специфики.
Чтобы понять, чего достичь измеренная загрузка и надежная загрузка, взгляните на стек виртуализации Linux: компоненты, которые вы запускаете, если хотите использовать виртуальные машины (ВМ) на машине Linux. Это описание, возможно, слишком упрощено, но (как я отмечал выше) меня интересуют не детали, а то, чего я пытаюсь достичь. Я сосредоточусь на четырех нижних уровнях (на довольно простом уровне абстракции): ЦП / механизм управления; BIOS / EFI; прошивка; и гипервизор, но я также рассмотрю уровень чуть выше процессора / механизма управления, который включает доверенный платформенный модуль (TPM) и некоторые инструкции по выполнению одного из двух процессов ( измеренная загрузка и надежная загрузка). Как только система начинает загружаться, TPM запускается и начинает свою работу. Альтернативные источники доверия, такие как аппаратные модули безопасности (HSM), также могут использоваться, но в моем примере я буду использовать TPM, наиболее распространенный пример в этом контексте.
В обоих случаях (доверенная загрузка и измеренная загрузка) основной поток начинается с TPM, выполняющего измерение уровня BIOS / EFI. Это измерение включает проверку двоичных инструкций, которые должны выполняться этим уровнем, и создание криптографического хэша двоичного изображения. Созданный хэш затем сохраняется в одном из нескольких «слотов» регистра конфигурации платформы (PCR) в TPM. Их можно рассматривать как части памяти, которые могут быть прочитаны позже – либо TPM для его целей, либо объектами, внешними по отношению к TPM, – но это не может быть изменено после того, как они были записаны. Эти фрагменты памяти защищены целостностью с момента их первоначальной записи. Это обеспечивает гарантии того, что после того, как TPM записывает значение в PCR,его можно считать постоянным на протяжении всего срока службы системы до отключения питания или перезагрузки.
После измерения уровня BIOS / EFI измеряется следующий уровень (прошивка). В этом случае полученный хеш объединяется с предыдущим хешем (который был сохранен в слоте PCR), а затем также сохраняется в слоте PCR. Процесс продолжается до тех пор, пока все уровни, участвующие в процессе, не будут измерены и результаты хеширования не будут сохранены. Существуют (иногда довольно сложные) процессы для установки исходных значений TPM (я пропустил некоторые из более низкоуровневых шагов в процессе для простоты) и для разрешения (надеюсь, санкционированного) изменения уровней для обновления или исправления безопасности. , например. Этот процесс «измеряемой загрузки» позволяет объектам запрашивать TPM после завершения процесса и проверять, соответствуют ли значения в слотах PCR ожидаемым значениям, предварительно рассчитанным с помощью «заведомо исправного».версии различных уровней, то есть предварительно проверенные версии, происхождение и целостность которых уже установлены.
Существуют различные протоколы, позволяющие сторонам, внешним по отношению к системе, проверять значения (например, через сетевое соединение), правильность которых подтверждает TPM: процесс получения и проверки таких значений из внешней системы известен как «удаленная аттестация».
Этот процесс – измеряемая загрузка – позволяет выяснить, являются ли основы вашей системы – нижние уровни – тем, чем вы думаете. Но что, если это не так? Измеренная загрузка (что неудивительно, учитывая название) измеряет, но не выполняет никаких других действий.
Альтернатива, «надежная загрузка», идет еще дальше. Когда выполняется доверенный процесс загрузки, этот процесс не только измеряет каждое значение, но также одновременно выполняет проверку известного (и ожидаемого!) Хорошего значения. Если проверка не удалась, процесс остановится, а загрузка системы завершится ошибкой. Это может показаться довольно экстремальным подходом к работе с системой, но иногда это абсолютно правильный подход. Если рассматриваемая система могла быть скомпрометирована – что, вероятно, можно сделать на основании сбоя надежного процесса загрузки – лучше вообще не быть доступной, чем работать на основе ошибочных ожиданий.
Это все очень хорошо, если я являюсь владельцем измеряемой системы, проверил все различные измеряемые компоненты (и измерения) и счастлив, что то, что загружается, – это то, что я хочу. Но что, если я использую систему в облаке, например, или любую систему, которой владеет и управляет кто-то другой? В этом случае я доверяю поставщику облачных услуг (или владельцу / менеджеру) две вещи:
Это проблема с терминологией «надежная загрузка» и, что еще хуже, «безопасная загрузка». Оба предполагают, что установлено абсолютное объективное свойство системы – она «надежная» или «безопасная», хотя это явно не так. Очевидно, было бы несправедливо ожидать, что разработчики таких процессов назовут их после состояний сбоя – «ненадежная загрузка» или «небезопасная загрузка», но если я не могу быть очень уверен, что доверяю владельцу системы выполнение шага два совершенно правильно (и в моих интересах как пользователя системы, а не их как владельца), то я не могу сделать более сильных утверждений.
Существует огромное искушение взять систему, которая прошла через процесс надежной загрузки, и обозначить ее как «надежную систему», когда самое лучшее утверждение, которое вы можете сделать, это то, что определенные уровни, измеренные в измеренном и / или надежном процессе загрузки, были предполагается, что процесс должен присутствовать. Такой процесс вообще ничего не говорит ни о способности слоев обеспечивать гарантии поведения, ни о правильности (или способности обеспечивать гарантии поведения) любых последующих слоев поверх них.
Важно отметить, что разработчики доверенных платформенных модулей четко понимают, что утверждается, и что утверждения о доверии следует делать осторожно и осторожно. К сожалению, однако, сложность систем, общий низкий уровень понимания доверия, а также сложность контекста и транзитивного доверия позволяют разработчикам и разработчикам систем легко ошибаться и предполагать, что любая система, которая успешно выполнила доверенный процесс загрузки можно считать «доверенным». Также чрезвычайно важно помнить, что TPM как аппаратные корни доверия предлагают один из лучших доступных механизмов для установления цепочки доверия в системах, которые вы можете проектировать или внедрять.
Продолжая использовать данный сайт вы принимаете политику конфиденциальности и cookies
