Cómo firmar handshakes TLS dentro de un TPM
Signing TLS handshakes inside a TPM
En este artículo, el autor explora cómo usar un TPM para firmar handshakes TLS, manteniendo la clave privada fuera del alcance de la memoria y los archivos. Explica por qué un TPM es la opción correcta frente a permisos de archivo, certificados de corta duración o un KMS, y detalla la implementación en Go con la librería go-tpm-tls. El código se integra con crypto/tls sin exponer la clave, y el autor discute los supuestos de seguridad y las ventajas de TLS 1.3.
Una clave en un archivo no es realmente una identidad de máquina: es una credencial de portador que resulta estar almacenada en una máquina, y quien la lee se convierte en esa máquina, en cualquier lugar, hasta que alguien lo nota y revoca el certificado.
- bob1029
Supongo que el valor de esto depende de tu modelo de amenaza.
El TPM te dará una garantía más fuerte de que una máquina posee una clave, pero es probable que un HSM dedicado sea mucho más difícil de extraer el material de la clave.
Que el TPM esté dentro de la máquina es un arma de doble filo. Por un lado, hace factible la atestación, pero por otro, ahora tienes la caja negra de seguridad dentro del mismo dominio físico que la máquina que la utiliza. El riesgo de extracción por canal lateral aumenta drásticamente cuando estos sistemas coexisten. Es mucho más difícil instrumentar un HSM a través de la red.
- KaiserPro
Para una empresa para la que trabajo necesitaba enviar una máquina a través de canales desconocidos y tener cierta confianza de que no la habían manipulado.
Mi modelo de amenaza era un ingeniero razonablemente técnico que intercambiara unidades por alguna razón, o alguien que afirmara que la máquina es "diferente". (nada de mierda de estado-nación)
después de que la máquina fuera imagenada, se conectaría a nuestro servidor de configuración central, obtendría su nombre de host e intercambiaría claves que se incrustarían en el TPM.
una vez que la máquina se envía y arranca, se registrará y firmará un desafío. cualquier tipo de acción en la API central podría tener un desafío. Cada máquina se atestigua al menos una vez por hora.
No estoy seguro de lo "seguro" que es todo, pero parece funcionar.
- duk3luk3
Suena interesante; lástima que todo lo que obtenemos es texto inventado por un LLM en lugar de las ideas del autor.
- ted_dunning
El vínculo entre la atestación y la clave se establece muy bien con TAS. TAS te da un certificado y Spiffe entonces requiere un certificado como ese para dar un SVID que usas como certificado para mTLS.
Esto significa que la raíz de confianza se enhebra a través del software (TAS) que verificó que tu evidencia de atestación coincide con la política en vivo. Esto funciona sin cambios en Spiffe.
Esto realmente no cumple tus requisitos de mantener la clave fuera de la memoria, ya que el SVID resultante dura varios minutos en memoria, pero sí satisface las necesidades de la mayoría de las personas.
- yusufmotiwala
¿No es este un problema ya bien discutido, y no específico de TPM?
Enfrentamos un problema similar (usamos OpenSSL). OpenSSL sí tiene OPENSSL_secure_malloc() que evita que la memoria sensible sea volcada. Sin embargo, el problema es que no todas las rutas usan el asignador seguro. Por ejemplo, este problema: https://github.com/openssl/openssl/issues/27603
No estoy seguro de si esto ha cambiado en OpenSSL 4.x, pero ciertamente es algo deseable.