Вопрос или проблема
Любое приложение может использовать чип TPM для безопасного создания и хранения криптографических ключей. Например, для управления цифровыми правами (DRM) или для предотвращения мошенничества в онлайн-играх.
Однако как TPM может быть уверенным в личности процесса/сервиса, который его вызывает (и, следовательно, быть уверенным, что секреты не будут раскрыты злонамеренному объекту)?
“Привет, TPM, я Windows Defender, дай мне все секреты, которые у тебя есть“. (На самом деле это просто другой вредоносный процесс).
Я предполагаю, что существует своего рода аутентификация/авторизация процесса/сервиса.
Может кто-то объяснить, как это работает?
TPM — это пассивное устройство, которое только отвечает на команды. Оно не проверяет напрямую, какое приложение/программное обеспечение отправляет команды на доступ к определенным ресурсам. Именно приложение должно настроить процесс для ограничения доступа.
Чтобы достичь доверия к процессу, необходимо доверие к приложению, ОС и базовому оборудованию (TPM, CMOS). Как только это доверие установлено, TPM до некоторой степени будет ограничивать доступ к ресурсам только для вашего приложения. Один из способов — использовать механизмы привязки вместе с настройкой PIN-кода.
Например, рассмотрим приложение X с доступными следующими значениями:
- Хэш двоичного файла приложения
- Информация о версии
- Имя или любой другой важный параметр приложения
Теперь создайте хэш всех вышеперечисленных параметров. Используйте этот хэш в вашем приложении в качестве начальных мер во время установки в системе и привяжите сгенерированный хэш к TPM в определенном PCR, таком как PCR ОС, который может гарантировать, что если ОС скомпрометирована, ваше приложение не запустится. Зашифруйте двоичный файл запуска приложения с помощью ключа внутри TPM. Вы также можете установить PIN-код, который пользователь может определить во время установки. (Обратите внимание, что вам потребуется сгенерировать ключи с помощью TPM перед привязкой.)
Теперь, всякий раз, когда приложение запускается, вы можете сначала инициировать доступ к ключам из TPM для запуска приложения и предоставить хэш для отвязки, который освободит ключи для расшифровки.
ПРИМЕЧАНИЕ: Вышеуказанный процесс является примером, а не надежной мерой. Также, даже с этой мерой, если конечный пользователь имеет права root/администратора, он может получить доступ к ресурсам.
Ответ или решение
TPM (Trusted Platform Module) — это специализированный чип, который обеспечивает безопасное хранение ключей шифрования и выполнения криптографических операций. Однако, так как TPM является пассивным устройством и не обладает способностями напрямую проверять идентичность вызывающего процесса или службы, это задача лежит на уровне операционной системы и приложения, которые взаимодействуют с TPM.
Для подтверждения идентичности процесса, который вызывает команды TPM, важно учесть несколько аспектов:
-
Доверие к окружению: Первоначально требуется обеспечить доверие к операционной системе, аппаратному обеспечению и приложению, использующему TPM. Это означает, что операционная система и приложение должны быть установлены и функционировать в безопасной среде.
-
Использование механизмов привязки: Для повышения уровня безопасности приложение может использовать механизмы привязки (binding mechanisms). Приложение при установке может создать хэш (SHA256, например) своего исполняемого файла и другой метаинформации (версии, имени и т.д.) и сохранить этот хэш в конкретном регистре конфигурации платформы (PCR – Platform Configuration Register) TPM.
-
Шифрование данных приложения: После создания хэша приложение может зашифровать свой исполняемый файл с использованием ключа, сгенерированного TPM. В этом случае TPM предоставит доступ к криптографическим ключам только в том случае, если хэш, полученный при запуске приложения, совпадает с предварительно сохранённым хэшем.
-
Проверка целостности: При каждом запуске приложения оно должно вычислять свой хэш и проверять его с сохранённым значением в TP, что позволяет убедиться, что приложение не было изменено и символизирует, что это именно то приложение, которое ожидалось.
-
ПИН-код или другие аутентификации: В некоторых случаях полезно использовать дополнительные методы аутентификации, такие как PIN-код. Пользователь, устанавливающий приложение, может задать ПИН-код, который будет использоваться для получения доступа к ключам TPM.
Важно понимать, что даже с вышеуказанными мерами, злоумышленник с полномочиями администратора может обойти эти механизмы и получить доступ к ресурсам. Поэтому, чем более сложная и безопасная архитектура на уровне приложений и ОС, тем ниже риск доступа к TPM со стороны недоверенных процессов.
Таким образом, основная задача по обеспечению безопасности и подтверждению идентичности процесса, взаимодействующего с TPM, лежит на слое операционной системы и самого приложения, которое должно внедрять надежные механизмы аутентификации и контроля доступа.