Cómo usar TPM para generar un par de claves de forma segura

Inicio » Hardware » Cómo usar TPM para generar un par de claves de forma segura

Si trabajas con seguridad en sistemas Windows o Linux, tarde o temprano te vas a cruzar con el instalación y configuración de TPM y la generación de pares de claves protegidas por hardware. No es solo un requisito molesto para ciertos sistemas operativos, sino una pieza crítica para cifrado, arranque seguro, autenticación fuerte y gestión de certificados.

En este artículo vamos a ver, con calma pero en detalle, cómo usar TPM para generar un par de claves, qué tipos de claves entran en juego, cómo se integran con servicios como FAS de Citrix, BitLocker o Windows Hello y qué implicaciones tiene todo esto en cuanto a privacidad, rendimiento y despliegue en entornos reales (incluidos virtualizados).

Qué es exactamente un TPM y qué hace con las claves

Un módulo de plataforma segura (TPM) es, simplificando mucho, un microchip criptográfico soldado a la placa base (o emulado en firmware/CPU) que ofrece funciones de seguridad ligadas al hardware: generación de claves, almacenamiento seguro y operaciones criptográficas aisladas del sistema operativo.

Este chip incorpora una serie de registros internos llamados PCR (Platform Configuration Registers) donde se van guardando medidas de integridad del arranque y la configuración. Cada medición se encadena mediante hashes, de forma que si se altera el firmware, el gestor de arranque, el arranque seguro o ciertos parámetros críticos, los valores cambian y el TPM puede negarse a liberar ciertas claves.

Además, los TPM modernos (1.2 y, sobre todo, 2.0) están pensados para que las claves privadas críticas nunca abandonen el propio chip. Se sellan internamente y el sistema operativo solo puede pedirle al TPM que firme, descifre o genere material criptográfico, pero no extraer la clave.

Este aislamiento hace que el TPM sea perfecto para proteger credenciales, claves RSA usadas en certificados, PIN de Windows Hello, claves de BitLocker, tarjetas inteligentes virtuales y, por supuesto, para generar y custodiar pares de claves usados por servicios corporativos como el Citrix Federated Authentication Service (FAS).

Tipos de claves que maneja el TPM (y cómo se relacionan)

Dentro del ecosistema TPM se manejan distintos tipos de pares de claves RSA, cada uno con un propósito muy concreto y con diferentes políticas de uso y visibilidad. Es importante entenderlos para saber qué estamos generando y dónde se almacena la parte privada.

En primer lugar está la Endorsement Key (EK), un par de claves que normalmente viene de fábrica. La parte privada permanece siempre dentro del TPM y el fabricante puede emitir un certificado para la parte pública, probando que ese chip es auténtico. Esta EK no se usa para firmar tráfico de aplicación, sino como ancla de confianza para atestación y provisión de otras claves.

Sobre la EK se genera la Storage Root Key (SRK), o clave raíz de almacenamiento. Esta se crea cuando se “toma posesión” del TPM (take ownership), proceso en el que se establece una contraseña de propietario. La SRK custodia otras claves de aplicación (selladas, cifradas), y su parte privada tampoco abandona el chip.

Para atestación (es decir, para poder demostrar remotamente que una clave está protegida por un TPM concreto y que el estado del sistema es el esperado) se utilizan las Attestation Identity Keys (AIK). Estas claves se generan dentro del TPM, se certifican a partir de la EK mediante una CA de identidad y sirven para firmar hashes de PCR u otras claves, evitando usar directamente la EK por motivos de privacidad.

A partir de la SRK y las capacidades del TPM se crean también claves de usuario, claves de certificados, claves de tarjetas inteligentes virtuales, claves de BitLocker o claves de autoridad de registro (RA) en el caso de FAS. En todos estos casos podemos controlar si son exportables, no exportables o expresamente protegidas por TPM.

Uso del TPM en Citrix FAS para generar pares de claves RA y de usuario

En un entorno Citrix con Federated Authentication Service (FAS), los certificados y sus claves privadas no se guardan en el almacén clásico de Windows, sino en una base de datos integrada en el propio servidor FAS. Aun así, el material de clave debe residir en algún proveedor criptográfico (software, TPM o HSM).

FAS maneja principalmente dos tipos de claves privadas críticas: la clave de la autoridad de registro (RA) y las claves de certificados de usuario. La RA se basa en certificados emitidos a partir de plantillas como Citrix_RegistrationAuthority y Citrix_RegistrationAuthority_ManualAuthorization, mientras que los usuarios consumen certificados derivados de plantillas como Citrix_SmartcardLogon.

Durante la instalación inicial de FAS, al pulsar “Authorize” en el paso 3, el servidor genera un par de claves nuevo para la RA temporal (Citrix_RegistrationAuthority_ManualAuthorization) y lanza una solicitud de firma a la CA. Un administrador tiene que aprobarla manualmente. Ese certificado de RA temporal, con su par de claves, se usa después para obtener un certificado de RA de larga duración (Citrix_RegistrationAuthority). Una vez conseguido el definitivo, FAS elimina el certificado y la clave temporal.

La clave privada asociada a la RA es muy sensible, porque la directiva ligada a la plantilla le permite emitir certificados en nombre de los usuarios especificados. Quien la controle puede suplantar identidades y entrar al entorno como cualquiera de los usuarios de ese conjunto.

Por eso FAS permite elegir cómo se protegen las claves privadas, tanto de RA como de usuario: proveedores de software de Microsoft (CAPI/CNG), TPM a través del Microsoft Platform Key Storage Provider, o un HSM externo. Dependiendo de los requisitos de seguridad y del rendimiento buscado, se puede combinar TPM solo para la RA y software para claves de usuario, o bien llevarlo todo a un HSM.

Configuración del proveedor de claves y uso de TPM en FAS

El comportamiento de FAS respecto a cómo y dónde se generan los pares de claves se controla en el archivo Citrix.Authentication.FederatedAuthenticationService.exe.config, que se encuentra, por defecto, en la ruta Archivos de programa\Citrix\Federated Authentication Service del servidor.

FAS solo lee este archivo al iniciar el servicio, así que cada vez que se cambian parámetros como el proveedor o la protección de clave hay que reiniciar el servicio de autenticación federada para que apliquen los nuevos valores. Dentro del archivo hay varios parámetros relevantes:

Por un lado está ProviderLegacyCsp, que permite alternar entre usar las APIs criptográficas clásicas de CAPI (valor true) o las de CNG (valor false, opción por defecto). Dependiendo de si se trabaja con un CSP antiguo o un KSP moderno (incluido el TPM), habrá que ajustar este flag.

El parámetro ProviderName define el nombre del proveedor criptográfico que va a generar y custodiar las claves. Entre los valores más habituales están “Microsoft Enhanced RSA and AES Cryptographic Provider” como CSP de CAPI clásico, “Microsoft Software Key Storage Provider” como KSP por defecto en CNG, “Microsoft Platform Key Storage Provider” como KSP propio de TPM, y los nombres específicos de proveedores de HSM de terceros.

Si se opta por CAPI, además hay que fijar ProviderType, que normalmente se deja a 24 (PROV_RSA_AES) salvo que el fabricante de HSM indique lo contrario. Con CNG y TPM este campo no es necesario.

Y llegamos a la clave del asunto: KeyProtection. Este parámetro especifica cómo deben generarse las claves privadas cuando FAS ordena una operación: sin protección (exportables), como no exportables o protegidas explícitamente por TPM usando GenerateTPMProtectedKey. En este último caso, la generación y almacenamiento de la parte privada se delegan en el TPM, usando el proveedor configurado (p. ej. Microsoft Platform Key Storage Provider).

Finalmente, KeyLength marca el tamaño en bits de las claves generadas (2048 por defecto, con posibilidad de 1024 o 4096). Conviene comprobar que el TPM o el HSM soportan la longitud elegida, porque algunos chips tienen límites y podrían rechazar la operación.

Ejemplos prácticos de configuración: software, TPM e HSM

En un despliegue típico, tras crear las plantillas de certificado y configurar la CA, FAS arranca con la configuración por defecto: tanto la clave de RA como las claves de usuario se generan con el proveedor de software de Microsoft, almacenándose como claves no exportables. Esta opción tiene buen rendimiento y es sencilla de gestionar.

Si la política de seguridad de la empresa es más estricta, se suele dar un paso más y forzar que la clave de la RA resida en el TPM de la placa base del servidor FAS, mientras que las claves de usuario siguen usando el KSP de software. Para ello hay que habilitar e inicializar el TPM en BIOS y en Windows, asignarlo al proveedor Microsoft Platform Key Storage Provider y ajustar el archivo de configuración antes de autorizar el servicio o, alternativamente, usar PowerShell para generar la solicitud de RA directamente en el TPM.

Con la consola de FAS, el flujo consiste en modificar el ProviderName y KeyProtection para que la generación de la clave de RA se haga contra el TPM, reiniciar el servicio, autorizar el servidor y, después de que la CA emita el certificado, volver a cambiar la configuración para que las futuras claves de usuario usen de nuevo el KSP de software. De este modo, solo la RA queda anclada al TPM, evitando cuellos de botella con miles de certificados de usuario.

También se puede hacer el proceso fuera de línea con PowerShell usando cmdlets como New-FasAuthorizationCertificateRequest -UseTPM $true, que genera el par RSA en el TPM y construye la CSR asociada. Esta CSR se envía a la CA mediante certreq, se emite, se exporta y se vuelve a importar en FAS con los cmdlets correspondientes. Durante todo el proceso, la clave privada nunca abandona el TPM y se puede verificar el proveedor de la PrivateKey en PowerShell para asegurarlo.

En entornos que requieren máxima segregación y certificaciones de seguridad (por ejemplo, ciertos organismos públicos o sectores regulados), se opta por almacenar tanto la clave de RA como las de usuario en un HSM dedicado. Se configura el ProviderName con el KSP o CSP del HSM (dependiendo de si expone CNG o CAPI), se ajusta ProviderLegacyCsp y KeyLength según la documentación del fabricante, se reinicia FAS y se genera la clave de RA desde la consola. El log de eventos de Windows confirmará que el proveedor usado es el del HSM.

Almacenamiento interno de certificados FAS y relación con el TPM

FAS no depende del almacén de certificados estándar de Windows para guardar los certificados emitidos, sino que emplea una base de datos embebida propia. Sin embargo, las claves privadas asociadas a esos certificados sí viven en los proveedores criptográficos configurados (software, TPM u HSM).

Para consultar qué certificados de RA maneja FAS y cómo están vinculados a las claves subyacentes, se usan cmdlets de PowerShell como Get-FasAuthorizationCertificate -address <FAS_FQDN>, que devuelven los GUID relevantes. Del mismo modo, Get-FasUserCertificate lista los certificados de usuario conocidos por el servicio.

Cuando se trabaja con HSM, cada contenedor de clave suele estar identificado también por un GUID propio en el dispositivo. FAS puede mostrar esa información usando Get-FasUserCertificate -KeyInfo $true, muy útil para trazar problemas entre lo que ve FAS y lo que registra el HSM.

Cómo funciona internamente un TPM: PCR, sellado y números aleatorios

De cara a entender bien cómo y por qué generamos pares de claves en un TPM, ayuda asomarse brevemente al funcionamiento interno. Un TPM es, como decíamos, un chip criptográfico con registros, lógica y firmware propios, que no dependen del sistema operativo.

Los registros PCR se van “extendiendo” con hashes SHA-1 o de otro algoritmo, combinando el valor anterior con nuevos datos de arranque o configuración. No se pueden reiniciar arbitrariamente (salvo algunos específicos en ciertos estados), de modo que para volver a un conjunto de valores PCR concreto hace falta reproducir exactamente la misma secuencia de arranque. Esto permite ligar secretos (como claves de cifrado) a un estado muy específico del sistema.

También ofrece funciones básicas como TPM_ORD_GetRandom, que devuelve bytes aleatorios generados por su propio generador interno. Estos valores pueden usarse para semillas criptográficas, generación de claves simétricas o como nonces en protocolos de atestación.

Por otro lado, el chip permite sellar datos: se cifra un secreto con una clave simétrica que, a su vez, queda protegida por la SRK, y se registra qué PCR deben tener qué valores para poder desenlazarlo. Si las PCR cambian, desencriptar falla. Este mecanismo es la base de soluciones como BitLocker o el almacenamiento de claves de SSH condicionadas al estado del sistema.

Finalmente, la atestación consiste en pedirle al TPM que firme (con una AIK) una estructura que contiene el resumen de ciertas PCR y un valor aleatorio conocido como nonce. El resultado es una “cita” firmada que otro sistema puede verificar para decidir si confía o no en el equipo que se está presentando.

Estados del TPM, inicialización y anti-martilleo (ataques de diccionario)

Antes de poder generar pares de claves en el TPM o usarlo para proteger certificados, el chip pasa por varios estados: deshabilitado, habilitado, activado, sin propietario y con propietario. En muchos equipos modernos, Windows inicializa automáticamente el TPM hasta dejarlo habilitado, activado y con una clave de aprobación generada.

En implementaciones antiguas o en emuladores software en Linux (como ibmswtpm), hay que simular la secuencia que haría la BIOS o UEFI: enviar comandos TPM_Init y TPM_Startup, habilitar el chip mediante presencia física (real o simulada), activarlo, crear la Endorsement Key y, finalmente, tomar posesión generando la SRK y estableciendo una contraseña de propietario.

Uno de los mecanismos más importantes de un TPM es su protección frente a ataques de diccionario o de fuerza bruta sobre valores de autorización (PIN, contraseñas). El chip lleva la cuenta de errores y, a partir de cierto umbral, entra en un estado de bloqueo en el que deja de aceptar intentos durante un tiempo.

Con TPM 2.0, Windows suele configurar este umbral en torno a 32 intentos fallidos, olvidando errores de uno en uno cada 10 minutos. De esta forma, un usuario que se equivoque unas cuantas veces no queda bloqueado de por vida, pero alguien que intente forzar un PIN sistemáticamente necesitaría años para cubrir todo el espacio, sobre todo si hablamos de PIN de 6 dígitos o más.

La lógica de anti-martilleo se puede restablecer con comandos especiales y, en ciertos escenarios, requiere la contraseña de propietario de TPM, que Windows puede guardar localmente o en Active Directory. Esto afecta directamente a tarjetas inteligentes virtuales, Windows Hello, BitLocker con PIN y cualquier clave protegida por TPM basada en PIN.

Casos de uso en Windows: BitLocker, Windows Hello, VSC, arranque medido y Credential Guard

La mayoría de usuarios se topan con el TPM por culpa de requisitos de sistema como los de Windows 11, pero en realidad el chip lleva tiempo sirviendo como base para muchas funciones de seguridad en Windows 7, 8, 10 y 11. Varias de ellas implican directamente uso de pares de claves generados o protegidos por el TPM.

En el caso de BitLocker, el volumen del sistema se cifra con una clave simétrica que queda protegida por una clave de protector que el TPM solo libera si el arranque sigue un camino esperado (según las PCR). Es posible añadir un PIN o una USB para reforzar la autenticación, pero en el modo más cómodo (“solo TPM”) el usuario no nota nada: el chip decide si el sistema puede arrancar o no descifrando el volumen.

Las tarjetas inteligentes virtuales basadas en TPM emulan tarjetas físicas: el certificado y la clave privada residen en el TPM en lugar de en una tarjeta plástica, y el usuario introduce un PIN. El anti-martilleo del TPM protege esos PIN mucho mejor que cualquier mecanismo puramente software.

El arranque medido y la atestación de estado explotan las PCR para registrar qué se ha cargado durante el arranque, y luego generan “citas” firmadas en las que una AIK certifica que el equipo ha iniciado con una configuración segura. Servicios de MDM o soluciones de acceso condicional pueden decidir si permiten o no que el dispositivo se conecte a redes corporativas o a servicios en la nube.

Por último, Credential Guard utiliza virtualización y TPM para aislar las credenciales hash de Windows (NTLM, Kerberos) en un entorno aislado. Incluso aunque un malware logre permisos de administrador o kernel, le resulta mucho más difícil robar esos secretos y hacer ataques “pass-the-hash”. El TPM se encarga de custodiar las claves de ese entorno aislado y de asegurar que solo se acceda a ellas si las medidas de arranque son correctas.

TPM en Linux, GPG y consideraciones sobre privacidad

En el mundo Linux, la historia es un poco distinta. Aunque existen capas como TSS (TrouSerS) y herramientas que permiten usar un TPM software o hardware para gestionar claves, la configuración por defecto de la mayoría de distribuciones no envía tus claves GPG al TPM a menos que lo hayas configurado explícitamente.

Importar una clave GPG a tu llavero normal no la almacena mágicamente en el chip: sigue en el disco, protegida por tu passphrase. Solo si usas módulos específicos (por ejemplo, backends que integren GnuPG con TPM o con tarjetas inteligentes virtuales) puedes delegar la generación y el uso de la clave privada al chip.

Respecto a la preocupación de privacidad y rastreo por parte de fabricantes o sistemas operativos, la realidad es que el TPM está más orientado a proteger al usuario que a espiarlo, aunque, como todo componente de seguridad, la confianza final depende de quién controle el hardware y el software. Las EK pueden, en teoría, identificar un TPM concreto, pero se han diseñado mecanismos como las AIK y las CAs de identidad para minimizar la exposición de identificadores únicos en escenarios de atestación.

Si desactivas el TPM en BIOS mientras usas Linux sin haberlo configurado para nada (ni cifrado de disco, ni integración con GPG, ni arranque medido), en la práctica lo más probable es que no notes absolutamente ningún cambio, más allá de que ya no podrás aprovechar las protecciones que el chip ofrece si en el futuro quieres activarlas. Eso sí, si tienes BitLocker activo en una instalación Windows en otro disco o partición, desactivar el TPM puede dejar ese sistema sin poder desbloquear el volumen salvo con la clave de recuperación (consulta cómo resolver el error de Trusted Platform Module al iniciar BitLocker).

El TPM se ha convertido en una pieza central de la seguridad moderna: desde la generación de pares de claves resistentes a extracción para servicios corporativos como FAS, hasta la protección de credenciales locales, cifrado de disco y atestación del estado del dispositivo, su papel va mucho más allá de un mero requisito para instalar un sistema operativo, y entender cómo usarlo bien marca la diferencia entre un entorno simplemente funcional y uno realmente robusto frente a ataques actuales.