TPM (Trusted Platform Module) — это международный стандарт, обеспечивающий доверенную работу с вычислительными платформами в целом и предоставляющий ряд возможностей обеспечения безопасности в компьютерных системах, в частности: хеширование, шифрование, подписывание, генерацию случайных чисел и т.д.
Он был разработан консорциумом TCG (группа по доверенным вычислениям) и стандартизирован в 2009 году Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC), получив номер ISO/IEC 11889:2009.
В 2011 году была выпущена версия 1.2 главной спецификации TPM. В TPM 1.2 для вычисления хеша поддерживается только технология SHA-1, а поскольку в настоящее время технология SHA-1 уже признана слабой и не рекомендуется к использованию NIST (Национальным институтом стандартов и технологий) при криптографических операциях с 2014 года, устройства с поддержкой TPM 1.2 теперь можно считать бесполезными по части обеспечения безопасности!
В 2014 году Trusted Computing Group анонсировала серьёзное обновление своей спецификации, получившей название «спецификация библиотеки TPM 2.0», и эта спецификация продолжает развиваться (на момент подготовки оригинала статьи новейшая версия датировалась 2019 годом).
Спецификация библиотеки TPM 2.0 получила номер ISO/IEC 11889:2015. В ней гораздо больше возможностей по сравнению с TPM 1.2, в частности, новые криптографические алгоритмы и хеш-функции, поддержка более длинных ключей и дополнительная гибкость при управлении внутренними регистрами и безопасным хранилищем данных.
В этой статье рассказано о спецификации TPM 2.0, которую можно скачать с сайта TCG.
Поскольку TPM — это просто спецификация, у неё могут быть разные реализации, от программных решений до специализированных чипов.
Но, прежде, чем поговорить о реализациях TPM, давайте познакомимся с её главными возможностями и распространёнными вариантами использования.
TPM предоставляет инфраструктуру для выполнения функций, касающихся обеспечения безопасности, в частности, защищённого хранения данных и выполнения криптографических операций, в соответствии с тем, как они определены в спецификации:
Вот некоторые из основных возможностей спецификации TPM 2.0:
Здесь возникает вопрос: зачем нам для этой цели нужен TPM? Не решается ли эта задача при помощи специального софта (например, OpenSSL), который бы выполнял эти криптографические операции? Да, решается! Но делать всё программными средствами не слишком безопасно, поскольку секреты могут попасть в руки злоумышленников, будучи во время выполнения на диске или в оперативной памяти.
В TPM предоставляется защищённое хранилище, в котором безопасно выполняются крипто-операции, а секреты (например, ключи) при этом не раскрываются ни в памяти, ни на диске, ни в шинах передачи данных. Степень безопасности таких операций зависит от конкретной реализации TPM).
Кроме того, TPM защищен от взлома, поэтому злоумышленнику сравнительно сложно добраться до данных, которые там хранятся, либо до генерируемых в нём криптографических ключей (опять же, степень безопасности этого механизма зависит от конкретной реализации).
Можно ли считать TPM средствами крипто-ускорения? Нет, нельзя. Хотя, криптографические операции в TPM и выполняются быстрее, чем на миниатюрном микроконтроллере, в большинстве случаев TPM будут работать гораздо медленнее. Смысл TPM не в ускорении работы, а в обеспечении безопасности!
Также важно упомянуть, что сверх всех этих традиционных криптографических операций реализация TPM предлагает ещё несколько интересных возможностей:
Как же все эти возможности используются на практике?
Прежде всего, TPM может использоваться для типичных криптографических операций – например, шифрования, дешифрования, подписывания, хеширования и т.д. Поскольку эти криптографические операции выполняются внутри TPM без раскрытия секретов – это уже хороший повод воспользоваться данным протоколом.
Чаще всего ссылаются на такой вариант практического применения TPM – обеспечить целостность при загрузке (также говорят об «измеряемой» или «доверенной» загрузке).
В системе, поддерживающей измеренную загрузку, в PCR-регистрах из TPM хранятся результаты измерений (т.е., хеши) каждого из компонентов операционной системы (прошивка, загрузчик, ядро т.д.). Этими измеренными данными позже можно воспользоваться для проверки целостности операционной системы и её конфигурации.
Кроме того, TPM может применяться для удалённой аттестации. Это процесс, в рамках которого проверяется и оценивается, насколько заслуживает доверия удалённое вычислительное устройство или платформа. TPM позволяет доверенной сущности (верификатору) удалённо подтвердить целостность программных, аппаратных компонентов и прошивки, действующих на интересующем нас устройстве, не полагаясь исключительно на информацию, декларируемую самим этим устройством.
Поскольку мы измерили показатели операционной системы (и располагаем их хешами), записав их в PCR-регистры, механизм TPM может подписать сообщение и отправить его на удалённую машину, чтобы сертифицировать и валидировать эти измерения. Даже существует протокол под названием Trusted Attestation Protocol Information Model, опубликованный Trusted Computing Group, и при помощи этого протокола как раз можно реализовать такой функционал.
Механизм TPM также обычно ассоциирован с некоторыми реализациями полнодискового шифрования.
При работе с малыми данными TPM может непосредственно выполнять как шифрование, так и дешифрование. При работе с большими данными TPM позволяет зашифровать и дешифровать симметричный ключ, который затем может применяться для шифрования. В спецификации TPM процесс шифрования ключей также называется обёртыванием (wrapping) или связыванием (binding) ключа.
Обертывание ключа можно дополнить запечатыванием. В данном случае обёрнутый (зашифрованный) ключ привязывается к определённым замерам показателей платформы (в спецификации TPM такая операция называется «запечатывание»). Запечатанный ключ можно только развернуть (дешифровать) в случае, когда значения измерений платформы совпадают со значениями, которые были актуальны при создании ключа.
В полной мере воспользоваться этой очень интересной фичей можно при помощи полнодискового шифрования. Для этого предназначены утилиты dm-crypt (Linux) и BitLocker (Windows), при работе с которыми TPM распечатывает (то есть, выпускает и дешифрует) ключ, при помощи которого был зашифрован диск. Но это делается лишь в случае, если в регистрах PCR содержатся правильные значения измерений (т.e., целостность операционной системы гарантируется до выпуска ключа).
При других вариантах использования TPM могут выполняться, в частности, идентификация устройств, защита и обязательство соблюдать софтверные лицензии, управление цифровыми правами (DRM) и даже предотвращение жульничества в онлайновых играх!
Давайте обсудим, как реализуется TPM…
Спецификацию TPM можно реализовать программно (опираясь на имеющиеся аппаратные возможности) или аппаратно (при помощи выделенных чипов).
Также спецификацию TPM можно программно эмулировать. Реализация такого рода защищена не сильнее, чем обычная программа защищена со стороны операционной системы. Всё целиком зависит от того окружения, в котором работает софт, и можно рассчитывать только на тот уровень безопасности, который гарантирует это окружение.
Реализация на программной основе может пригодиться только для целей разработки. См., например, проект SWTPM, программный эмулятор TPM с сокетом, символьное устройство и интерфейс Linux CUSE.
Более рациональный программный подход таков: выполнять код TPM именно тогда, когда процессор действует в особом режиме исполнения (напр. TrustZone на ARM). Обычно такой режим называется прошивочной TPM.
При таком подходе доверенная среда выполнения (TEE) могла бы реализовывать спецификацию TPM в доверенном приложении и предоставлять доступ к возможностям TPM недоверенным приложениям. Такой подход не столь безопасен, как работа с выделенным чипом, реализующим функционал TPM, зато он даёт достаточную безопасность без необходимости прибегать к внешнему аппаратному обеспечению functionality.
Официальная справочная реализация TCG для спецификации TPM 2.0 разработана Microsoft, её исходный код выложен на GitHub. Данную справочную реализацию можно использовать в качестве прошивочного варианта TPM, и он уже включён в некоторые реализации TEE, в том числе, в OP-TEE.
Но ничего не заменит аппаратную реализацию!
Наиболее безопасные реализации TPM выполняются аппаратно. Они также называются дискретными TPM и используют выделенные чипы, реализующие функционал TPM на базе собственного взломоустойчивого пакета на основе полупроводников, подключаемого к системе через шину связи, например, I2C или SPI.
В дискретной TPM есть процессор, ОЗУ и флэш-память, а также предоставляется шина и протокол связи для взаимодействия с хост-системой. Взаимодействие с дискретной TPM возможно только через шину связи. Приведу два примера: ST33TPHF20SPI от STMicroelectronics и ATTPM20P от Microchip.
Возможно, кроме TPM вам доводилось слышать о безопасных элементах и смарт-картах. Чем они отличаются?
Безопасный элемент — это безопасная вычислительная система. В сущности, это защищённое хранилище данных, для которого предусмотрены собственные варианты защищённого применения. Очевидно, какие задачи решает безопасный элемент, пусть конкретика и зависит от реализации. Большинство из них реализуют PKCS#11 (Стандарт криптографии с открытым ключом, версия 11).
В качестве примеров безопасных элементов можно привести аппаратные модули безопасности (HSM), SIM-карты и… смарт-карты!
Итак, смарт-карты – лишь один из примеров безопасных элементов. Это физические электронные устройства для аутентификации, с их помощью контролируется доступ к некоторому ресурсу. По размеру они обычно сравнимы с банковской картой, в них встроена интегральная цифровая схема.
Не забывайте, что TPM – это просто спецификация и международный стандарт. TPM не является безопасным элементом, хотя и может быть реализована на основе такого элемента.
Резюмирую: область применения безопасного элемента шире, чем у TPM, а его функционал зависит от реализации. В свою очередь, у TPM ограниченная и строго определённая область применения.
Преимущество работы с TPM в том, что TPM предоставляет стандартизированный набор возможностей, поэтому её легче интегрировать с программной частью. Отчасти именно поэтому TPM так популярна в случаях, когда требуется повысить безопасность вычислительной системы.
Но подождите, в самом ли деле безопасны TPM?
Ни одна технология не безопасна на 100%. Располагая достаточным временем и ресурсами, под любую технологию можно подобрать эксплойт.
Поэтому, если вам интересно, удалось ли уже взломать TPM, просто зайдите в поисковик и спросите “Attacks on TPM devices”. Давайте же, я подожду… :-)
Да, TPM уже ломали, и многократно!
В 2010 году Кристофер Тарновски представил на конференции Black Hat Briefings пример атаки на TPM. Внедрив шпионскую программу в шину связи TPM-устройства производства Infineon, он смог вытянуть секреты с чипа! К сожалению, этого доклада нет в свободном доступе. Но есть более новый под названием “Attacking TPM Part 2 — A Look at the ST19WP18 TPM Device” – его запись можно посмотреть на YouTube.
В 2018 году была найдена уязвимость, допущенная в TPM 2.0 при проектировании (CVE-2018-6622), позволяющая злоумышленнику сбросить и подделать содержимое PCR-регистров.
В 2021 году компания Dolos Group, занимающая консультированием в области безопасности, взломала компьютер Lenovo, заполучив доступ к ключу, которым был зашифрован диск. Для этого они прослушали шину SPI, через которую идёт связь с TPM (подробная статья об этом размещена на портале Ars Technica).
Также известно несколько примеров успешных аппаратных атак, большинство из них выполнялось по сторонним каналам.
Например, известна атака TPM—Fail, при которой исследователям удалось извлечь ключи при помощи атак по времени: «Мы смогли уловить разницу во времени (timing leakage) в TPM, реализованной на прошивке Intel (fTPM), а также на TPM-чипе от STMicroelectronics. На обоих компонентах в период генерации криптографической подписи время выполнения зависит от содержания секрета. Притом, что данный ключ должен безопасно храниться внутри аппаратной части TPM, показано, как с помощью этой информации злоумышленник может выудить 256-разрядные приватные ключи из схем цифровой подписи, основанных на эллиптических кривых.
Об этом есть очень интересная статья!
Возможно, захочется почитать и это:
Он был разработан консорциумом TCG (группа по доверенным вычислениям) и стандартизирован в 2009 году Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC), получив номер ISO/IEC 11889:2009.
В 2011 году была выпущена версия 1.2 главной спецификации TPM. В TPM 1.2 для вычисления хеша поддерживается только технология SHA-1, а поскольку в настоящее время технология SHA-1 уже признана слабой и не рекомендуется к использованию NIST (Национальным институтом стандартов и технологий) при криптографических операциях с 2014 года, устройства с поддержкой TPM 1.2 теперь можно считать бесполезными по части обеспечения безопасности!
В 2014 году Trusted Computing Group анонсировала серьёзное обновление своей спецификации, получившей название «спецификация библиотеки TPM 2.0», и эта спецификация продолжает развиваться (на момент подготовки оригинала статьи новейшая версия датировалась 2019 годом).
Спецификация библиотеки TPM 2.0 получила номер ISO/IEC 11889:2015. В ней гораздо больше возможностей по сравнению с TPM 1.2, в частности, новые криптографические алгоритмы и хеш-функции, поддержка более длинных ключей и дополнительная гибкость при управлении внутренними регистрами и безопасным хранилищем данных.
В этой статье рассказано о спецификации TPM 2.0, которую можно скачать с сайта TCG.
Поскольку TPM — это просто спецификация, у неё могут быть разные реализации, от программных решений до специализированных чипов.
Но, прежде, чем поговорить о реализациях TPM, давайте познакомимся с её главными возможностями и распространёнными вариантами использования.
❯ Возможности TPM
TPM предоставляет инфраструктуру для выполнения функций, касающихся обеспечения безопасности, в частности, защищённого хранения данных и выполнения криптографических операций, в соответствии с тем, как они определены в спецификации:
Описание
I/O // Ввод/вывод
Data communication path // Путь сообщения данных
Asymmetric Engine(s) // Асимметричный движок
Hash Engine(s) // Движок хеша
Key Generation // Генерация ключей
Symmetric engine(s) // Симметричный движок
RNG // Генератор случайных чисел
Management // Управление
Power Detection // Обнаружение питания
Authorization // Авторизация
Execution Engine (Parts 3 & 4) // Движок выполнения (части 3 и 4)
Non-Volatile Memory // Энергонезависимая память
Platform Seed // Начальное число платформы
Endorsement Seed // Начальное число подтверждения
Storage Seed // Начальное число хранилища
Volatile Memory // Энергозависимая память
PCR Banks // Банки регистров конфигурации платформы
Keys in use // Используемые ключи
Sessions // Сеансы
Etc. // Т.д.
Энергонезависимая память может предоставляться на системном чипе, откуда данные поступают в энергонезависимую память и обратно в защищённой форме. В таком случае в TPM хранится кэшированная копия содержимого энергонезависимой памяти.
Data communication path // Путь сообщения данных
Asymmetric Engine(s) // Асимметричный движок
Hash Engine(s) // Движок хеша
Key Generation // Генерация ключей
Symmetric engine(s) // Симметричный движок
RNG // Генератор случайных чисел
Management // Управление
Power Detection // Обнаружение питания
Authorization // Авторизация
Execution Engine (Parts 3 & 4) // Движок выполнения (части 3 и 4)
Non-Volatile Memory // Энергонезависимая память
Platform Seed // Начальное число платформы
Endorsement Seed // Начальное число подтверждения
Storage Seed // Начальное число хранилища
Volatile Memory // Энергозависимая память
PCR Banks // Банки регистров конфигурации платформы
Keys in use // Используемые ключи
Sessions // Сеансы
Etc. // Т.д.
Энергонезависимая память может предоставляться на системном чипе, откуда данные поступают в энергонезависимую память и обратно в защищённой форме. В таком случае в TPM хранится кэшированная копия содержимого энергонезависимой памяти.
Вот некоторые из основных возможностей спецификации TPM 2.0:
- Вычисление хешей (SHA-1, SHA-256)
- Генерация случайных чисел
- Генерация криптографических ключей
- Защищённое хранилище криптографических ключей и контрольных сумм сообщений
- Симметричное шифрование и дешифрование (AES)
- Асимметричное шифрование и дешифрование (RSA, ECC)
- Проверка цифровой подписи (HMAC, SMAC)
Здесь возникает вопрос: зачем нам для этой цели нужен TPM? Не решается ли эта задача при помощи специального софта (например, OpenSSL), который бы выполнял эти криптографические операции? Да, решается! Но делать всё программными средствами не слишком безопасно, поскольку секреты могут попасть в руки злоумышленников, будучи во время выполнения на диске или в оперативной памяти.
В TPM предоставляется защищённое хранилище, в котором безопасно выполняются крипто-операции, а секреты (например, ключи) при этом не раскрываются ни в памяти, ни на диске, ни в шинах передачи данных. Степень безопасности таких операций зависит от конкретной реализации TPM).
Кроме того, TPM защищен от взлома, поэтому злоумышленнику сравнительно сложно добраться до данных, которые там хранятся, либо до генерируемых в нём криптографических ключей (опять же, степень безопасности этого механизма зависит от конкретной реализации).
Можно ли считать TPM средствами крипто-ускорения? Нет, нельзя. Хотя, криптографические операции в TPM и выполняются быстрее, чем на миниатюрном микроконтроллере, в большинстве случаев TPM будут работать гораздо медленнее. Смысл TPM не в ускорении работы, а в обеспечении безопасности!
Также важно упомянуть, что сверх всех этих традиционных криптографических операций реализация TPM предлагает ещё несколько интересных возможностей:
- PCR (регистры конфигурации платформы): специальные и защищённые регистры, в которых обычно хранится информация об измеренных параметрах операционной системы – например, хеши различных компонентов системного ПО и прошивки.
- Обёртывание или связывание: это возможность зашифровать данные ключом, который хранится в самом TPM. Эта возможность используется, например, для шифрования ключей, хранимых на незащищённых носителях данных, таких, как жёсткие диски или флэш-память, так, чтобы расшифровать их можно было только при помощи самого TPM.
- Запечатывание: возможность ассоциировать некоторые зашифрованные данные с результатом измерения, сохранённом в регистре PCR. В таком случае данные могут быть дешифрованы (распечатаны), только если актуальное содержимое PCR совпадает с указанным значением.
- Ключ подтверждения (EK): уникальный ключ, создаваемый на этапе формирования TPM. В нём могут быть записаны различные свойства, как то проверка устройств (device attestation), верификация личности, верификация целостности платформы.
- Шифрование на основе сеансов: возможность зашифровать конфиденциальные данные при передаче их по TPM.
Как же все эти возможности используются на практике?
❯ Варианты использования TPM
Прежде всего, TPM может использоваться для типичных криптографических операций – например, шифрования, дешифрования, подписывания, хеширования и т.д. Поскольку эти криптографические операции выполняются внутри TPM без раскрытия секретов – это уже хороший повод воспользоваться данным протоколом.
Чаще всего ссылаются на такой вариант практического применения TPM – обеспечить целостность при загрузке (также говорят об «измеряемой» или «доверенной» загрузке).
В системе, поддерживающей измеренную загрузку, в PCR-регистрах из TPM хранятся результаты измерений (т.е., хеши) каждого из компонентов операционной системы (прошивка, загрузчик, ядро т.д.). Этими измеренными данными позже можно воспользоваться для проверки целостности операционной системы и её конфигурации.
Кроме того, TPM может применяться для удалённой аттестации. Это процесс, в рамках которого проверяется и оценивается, насколько заслуживает доверия удалённое вычислительное устройство или платформа. TPM позволяет доверенной сущности (верификатору) удалённо подтвердить целостность программных, аппаратных компонентов и прошивки, действующих на интересующем нас устройстве, не полагаясь исключительно на информацию, декларируемую самим этим устройством.
Поскольку мы измерили показатели операционной системы (и располагаем их хешами), записав их в PCR-регистры, механизм TPM может подписать сообщение и отправить его на удалённую машину, чтобы сертифицировать и валидировать эти измерения. Даже существует протокол под названием Trusted Attestation Protocol Information Model, опубликованный Trusted Computing Group, и при помощи этого протокола как раз можно реализовать такой функционал.
Механизм TPM также обычно ассоциирован с некоторыми реализациями полнодискового шифрования.
При работе с малыми данными TPM может непосредственно выполнять как шифрование, так и дешифрование. При работе с большими данными TPM позволяет зашифровать и дешифровать симметричный ключ, который затем может применяться для шифрования. В спецификации TPM процесс шифрования ключей также называется обёртыванием (wrapping) или связыванием (binding) ключа.
Обертывание ключа можно дополнить запечатыванием. В данном случае обёрнутый (зашифрованный) ключ привязывается к определённым замерам показателей платформы (в спецификации TPM такая операция называется «запечатывание»). Запечатанный ключ можно только развернуть (дешифровать) в случае, когда значения измерений платформы совпадают со значениями, которые были актуальны при создании ключа.
В полной мере воспользоваться этой очень интересной фичей можно при помощи полнодискового шифрования. Для этого предназначены утилиты dm-crypt (Linux) и BitLocker (Windows), при работе с которыми TPM распечатывает (то есть, выпускает и дешифрует) ключ, при помощи которого был зашифрован диск. Но это делается лишь в случае, если в регистрах PCR содержатся правильные значения измерений (т.e., целостность операционной системы гарантируется до выпуска ключа).
При других вариантах использования TPM могут выполняться, в частности, идентификация устройств, защита и обязательство соблюдать софтверные лицензии, управление цифровыми правами (DRM) и даже предотвращение жульничества в онлайновых играх!
Давайте обсудим, как реализуется TPM…
❯ Как реализуется TPM?
Спецификацию TPM можно реализовать программно (опираясь на имеющиеся аппаратные возможности) или аппаратно (при помощи выделенных чипов).
Также спецификацию TPM можно программно эмулировать. Реализация такого рода защищена не сильнее, чем обычная программа защищена со стороны операционной системы. Всё целиком зависит от того окружения, в котором работает софт, и можно рассчитывать только на тот уровень безопасности, который гарантирует это окружение.
Реализация на программной основе может пригодиться только для целей разработки. См., например, проект SWTPM, программный эмулятор TPM с сокетом, символьное устройство и интерфейс Linux CUSE.
Более рациональный программный подход таков: выполнять код TPM именно тогда, когда процессор действует в особом режиме исполнения (напр. TrustZone на ARM). Обычно такой режим называется прошивочной TPM.
При таком подходе доверенная среда выполнения (TEE) могла бы реализовывать спецификацию TPM в доверенном приложении и предоставлять доступ к возможностям TPM недоверенным приложениям. Такой подход не столь безопасен, как работа с выделенным чипом, реализующим функционал TPM, зато он даёт достаточную безопасность без необходимости прибегать к внешнему аппаратному обеспечению functionality.
Официальная справочная реализация TCG для спецификации TPM 2.0 разработана Microsoft, её исходный код выложен на GitHub. Данную справочную реализацию можно использовать в качестве прошивочного варианта TPM, и он уже включён в некоторые реализации TEE, в том числе, в OP-TEE.
Но ничего не заменит аппаратную реализацию!
Наиболее безопасные реализации TPM выполняются аппаратно. Они также называются дискретными TPM и используют выделенные чипы, реализующие функционал TPM на базе собственного взломоустойчивого пакета на основе полупроводников, подключаемого к системе через шину связи, например, I2C или SPI.
В дискретной TPM есть процессор, ОЗУ и флэш-память, а также предоставляется шина и протокол связи для взаимодействия с хост-системой. Взаимодействие с дискретной TPM возможно только через шину связи. Приведу два примера: ST33TPHF20SPI от STMicroelectronics и ATTPM20P от Microchip.
Возможно, кроме TPM вам доводилось слышать о безопасных элементах и смарт-картах. Чем они отличаются?
❯ Сравним безопасные элементы и смарт-карты с TPM
Безопасный элемент — это безопасная вычислительная система. В сущности, это защищённое хранилище данных, для которого предусмотрены собственные варианты защищённого применения. Очевидно, какие задачи решает безопасный элемент, пусть конкретика и зависит от реализации. Большинство из них реализуют PKCS#11 (Стандарт криптографии с открытым ключом, версия 11).
В качестве примеров безопасных элементов можно привести аппаратные модули безопасности (HSM), SIM-карты и… смарт-карты!
Итак, смарт-карты – лишь один из примеров безопасных элементов. Это физические электронные устройства для аутентификации, с их помощью контролируется доступ к некоторому ресурсу. По размеру они обычно сравнимы с банковской картой, в них встроена интегральная цифровая схема.
Не забывайте, что TPM – это просто спецификация и международный стандарт. TPM не является безопасным элементом, хотя и может быть реализована на основе такого элемента.
Резюмирую: область применения безопасного элемента шире, чем у TPM, а его функционал зависит от реализации. В свою очередь, у TPM ограниченная и строго определённая область применения.
Преимущество работы с TPM в том, что TPM предоставляет стандартизированный набор возможностей, поэтому её легче интегрировать с программной частью. Отчасти именно поэтому TPM так популярна в случаях, когда требуется повысить безопасность вычислительной системы.
Но подождите, в самом ли деле безопасны TPM?
❯ Атаки на устройства с TPM
Ни одна технология не безопасна на 100%. Располагая достаточным временем и ресурсами, под любую технологию можно подобрать эксплойт.
Поэтому, если вам интересно, удалось ли уже взломать TPM, просто зайдите в поисковик и спросите “Attacks on TPM devices”. Давайте же, я подожду… :-)
Да, TPM уже ломали, и многократно!
В 2010 году Кристофер Тарновски представил на конференции Black Hat Briefings пример атаки на TPM. Внедрив шпионскую программу в шину связи TPM-устройства производства Infineon, он смог вытянуть секреты с чипа! К сожалению, этого доклада нет в свободном доступе. Но есть более новый под названием “Attacking TPM Part 2 — A Look at the ST19WP18 TPM Device” – его запись можно посмотреть на YouTube.
В 2018 году была найдена уязвимость, допущенная в TPM 2.0 при проектировании (CVE-2018-6622), позволяющая злоумышленнику сбросить и подделать содержимое PCR-регистров.
В 2021 году компания Dolos Group, занимающая консультированием в области безопасности, взломала компьютер Lenovo, заполучив доступ к ключу, которым был зашифрован диск. Для этого они прослушали шину SPI, через которую идёт связь с TPM (подробная статья об этом размещена на портале Ars Technica).
Также известно несколько примеров успешных аппаратных атак, большинство из них выполнялось по сторонним каналам.
Например, известна атака TPM—Fail, при которой исследователям удалось извлечь ключи при помощи атак по времени: «Мы смогли уловить разницу во времени (timing leakage) в TPM, реализованной на прошивке Intel (fTPM), а также на TPM-чипе от STMicroelectronics. На обоих компонентах в период генерации криптографической подписи время выполнения зависит от содержания секрета. Притом, что данный ключ должен безопасно храниться внутри аппаратной части TPM, показано, как с помощью этой информации злоумышленник может выудить 256-разрядные приватные ключи из схем цифровой подписи, основанных на эллиптических кривых.
Об этом есть очень интересная статья!
Возможно, захочется почитать и это:
- ➤ SQL в качестве API
- ➤ В моих жилах течет моддерская кровь: как и зачем я променял оригинальный айфон на нерабочую подделку за 1500 рублей?
- ➤ 6 прекрасных и 6 упоротых идей в промышленном дизайне: чем был интересен прошлый год
- ➤ Уходящий в историю стандарт. Запускаем базовую станцию 3G (UMTS)
- ➤ «Поздравляем с терабитом». Та самая статья про DDoS-2023 — без цензуры
Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩
Комментарии (10)
AlexanderS
23.03.2024 18:36+6В полной мере воспользоваться этой очень интересной фичей можно при помощи полнодискового шифрования. Для этого предназначены утилиты dm-crypt (Linux) и BitLocker (Windows), при работе с которыми TPM распечатывает (то есть, выпускает и дешифрует) ключ, при помощи которого был зашифрован диск. Но это делается лишь в случае, если в регистрах PCR содержатся правильные значения измерений (т.e., целостность операционной системы гарантируется до выпуска ключа).
Всё это хорошо и удобно, но что делать если ПК сломался и всё это дело перенесли на другой комп платформа которого отличается от запомненной в PCR? Весь смысл же в том, что ключ шифрования как родился в TPM так его и не покидал. Или предусмотрена возможность его экспорта для бэкапа в укромном месте?
P.S.
Уровень статьи предлагаю перевести со "сложный" на "средний". В ней нет формул, алгоритмов, сложных схем и читается как общее введение в тему.
navion
23.03.2024 18:36+2Или предусмотрена возможность его экспорта для бэкапа в укромном месте?
При шифрованием диска создаётся длинный ключ для восстановления, который попросит ввести загрузчик при невозможности распечатать TPM.
topright007
Привет!
а почему windows 11 требует TPM? он же вроде не навязывает нам full disk encryption и face recognition
CodeRush
Если совсем коротко, то требование это не функциональное, а политическое. Дело в том, что 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 это теперь не только нежелательная, но и неподдерживаемая конфигурация.
RichardMerlock
А ведь можно всего лишь обеспечить физически контролируемый загрузочный носитель с read-only перемычкой и так же защищённый биос с настройками. Всё! Ничего кроме доверенного не загрузится.
CodeRush
Это очень, очень, очень дорогое "всего лишь", в основном тому, что абсолютное большинство пользователей и покупателей ПК и ОС для ПК ничего не знают и не хотят знать ни про какие "прошивки", "БИОСы", "загрузки", "переключатели", "рид-онли" и тому подобное, им нужно чтобы крышку открыл - через полсекунды у тебя приглашение ко входу на мониторе, крышку закрыл - компьютер перестал батарею жрать. Представьте себе ситуацию, при которой этот переключатель включили в РО во время обновления ОС, и обновление не смогло продолжиться, как ОС должна рассказывать пользователю о том, что произошло, если она исполняется фиг пойми на чем, от кофеварок до боевых человекоподобных роботов, или наоборот пользователь забыл этот тумблер щелкнуть обратно, и теперь у нас опять жопа голая, а сделать мы не можем с этим ничего.
Нельзя считать пользователя совсем уж дураком стоеросовым, конечно, но и переоценивать его умение и желание разбираться в непонятном тоже не следует, и индустрия давно уже это поняла, а кто не понял - обанкротился уже вполне успешно.
RichardMerlock
Ну так и пользователь, который не разбирается в условных биосах, он и его и обновлять не лезет. А кто лезет на удачу, тот становится клиентом сервисного центра. Защиту от обновления и изменения конфигурации можно сделать элегантнее, но она должна быть железная и должна быть. Против соц инженерии и хакера с отвёрткой не работает. Но зато железно работает во всех остальных случаях. Вот есть же предупреждение про обновление на свой страх и риск и об опасности потери питания в процессе, и ничего, народ смело жмёт ДА. Так и тут, жми кнопку под крышкой и обновляй первичный загрузчик.
CodeRush
Защита от автоматических обновлений автоматически означает отсутствие обновлений у подавляющего большинства пользователей, а на такое теперь ни в коем случае нельзя пойти, потому что это опять же очень дорого - выпускать материнские платы с нормально работающей прошивкой прямо в первый же день, которые работали бы нормально без обновлений этой самом прошивки потом годами. ОЕМы никогда снова не пойдут на такое, потому что это увеличит им затраты на прошивки минимум десятикратно, а у них и так маржа 5% хорошо если.
Для UEFI пришлось выдумать стандартный механизм ESRT (EFI System Resources Table) и буквально заставить производителей поставлять свои обновления через Windows Update и Linux Vendor Firmware Service, потому что иначе заставить пользователя обновляться просто решительно невозможно, и он сидит с заранее сломанными прошивками с годами неисправленными уязвимостями, на которые в смысле безопасности надеяться - себя не уважать. Понятно, что там и на последние версии надежда такая-же, примерно, но отдать обновления в руки пользователя при нынешней культуре и стоимости разработки ПО (а прошивки - это ПО такое же, как и все остальное) - это ошибка.
msuhanov
Загрузка с накопителя в режиме "read-only" может "перепрыгнуть" на исполнение кода с другого накопителя, который в режиме "read-write".
Вот есть, например, CVE-2023-4001 (GRUB пытается исполнить конфигурационный файл с другого накопителя, а если не находит этот файл — выдает шелл: это в текущем виде есть обход пароля на GRUB при наличии физического доступа, но можно "докрутить" и до исполнения кода при наличии локального, привилегированного доступа — если подложить нужный конфигурационный файл на второй накопитель, перечисляемый до загрузочного). И таких сценариев еще много.
assad77
Сомневаюсь, что цель мс -- борьба с буткитом. Скорее с линуксом. Я что-то не слышал, что буткиты является бичом сейчас. Хотя работаю в ав компании. Я конечно не вирусный аналитик, но всеж.