Подписываем TLS-рукопожатия внутри TPM: ключ никогда не покидает чип
Signing TLS handshakes inside a TPM
Автор, занимаясь удалённой аттестацией конфиденциальных VM, делится решением: как использовать TPM для подписи TLS-рукопожатий, чтобы приватный ключ никогда не попадал в память процесса и не мог быть украден через дампы, core-файлы или снапшоты. Он объясняет, почему файловые права, короткоживущие сертификаты и KMS не дают такого же уровня защиты, и показывает библиотеку go-tpm-tls, которая позволяет использовать TPM-ключ как обычный tls.Certificate в Go. Код находит нужный ключ по публичному ключу из сертификата, а не по хендлу, что упрощает ротацию. Автор также разбирает требования TLS 1.3 к подписи и предостерегает от излишних ожиданий: TPM защищает от кражи ключа, но не от атак, когда злоумышленник уже имеет код внутри гостевой ОС.
Ключ в файле — это не настоящая идентичность машины. Это предъявительский документ, который случайно хранится на машине, и кто его прочитал, тот и становится этой машиной — где угодно, пока кто-нибудь не заметит и не отзовёт сертификат.
- bob1029
Я полагаю, что ценность этого зависит от вашей модели угроз. TPM даст вам более сильную гарантию того, что машина владеет ключом, но, вероятно, выделенный HSM будет гораздо сложнее вскрыть для извлечения ключевого материала. Нахождение TPM внутри машины — палка о двух концах. С одной стороны, это делает аттестацию возможной, но с другой — теперь у вас есть черный ящик безопасности внутри того же физического домена, что и машина, которая его использует. Риск извлечения через побочные каналы резко возрастает, когда эти системы сосуществуют. Гораздо сложнее инструментировать HSM через сеть.
- KaiserPro
Для одной компании, на которую я работаю, мне нужно было отправить машину через неизвестные каналы и иметь некоторую уверенность, что с ней не возились. Моя модель угроз была достаточно техническим инженером, меняющим диски по какой-то причине, или кем-то, кто утверждает, что машина "другая" (никакого уровня государства). После того как машина была образцована, она подключалась к нашему центральному серверу конфигурации, получала свое имя хоста и обменивалась ключами, которые были встроены в TPM. Как только машина отправлена и загружена, она проверяется и подписывает вызов. Любое действие в центральном API может иметь вызов. Каждая машина аттестуется как минимум раз в час. Я не уверен, насколько это "безопасно", но, похоже, работает.
- duk3luk3
Звучит интересно; жаль, что нам достается только текст, сгенерированный LLM, а не идеи автора.
- ted_dunning
Связь между аттестацией и ключом хорошо показана с TAS. TAS дает вам сертификат, а Spiffe затем требует такой сертификат, чтобы выдать SVID, который вы используете как сертификат для mTLS. Это означает, что корень доверия проходит через программное обеспечение (TAS), которое проверяет, что ваши доказательства аттестации соответствуют действующей политике. Это работает без изменений в Spiffe. Это не совсем соответствует вашим требованиям держать ключ вне памяти, поскольку полученный SVID живет в памяти несколько минут, но это удовлетворяет потребности большинства людей. https://github.com/TEE-Attestation/tas
- yusufmotiwala
Разве это не уже хорошо обсуждаемая проблема, и не специфичная для TPM? Мы столкнулись с похожей проблемой (мы используем OpenSSL). В OpenSSL есть OPENSSL_secure_malloc(), который предотвращает сброс чувствительной памяти. Однако проблема в том, что не все пути используют безопасный аллокатор. Например, эта проблема: https://github.com/openssl/openssl/issues/27603. Не уверен, изменилось ли это в OpenSSL 4.x, но это определенно желательно.