Descargo de responsabilidad: no soy un experto en TPM: la mayor parte de esto proviene de una investigación de media hora. Me las arreglé para improvisar una comprensión razonable del proceso y los detalles de la especificación TCG TPM, la documentación de la API de TPM en MSDN y varios documentos sobre el tema.
El SRK es un par de claves RSA (de al menos 2048 bits de tamaño) que se usa como la raíz de una cadena de confianza dentro del TPM. Actúa como la máxima autoridad de la confianza. Si se carga una clave RSA secundaria en el TPM y se firma con el SRK, esa clave se clasifica como confiable y otros materiales firmados con esa clave se pueden cargar a través de esa cadena de confianza. El SRK no se deriva de una contraseña, es una clave RSA generada en hardware.
Cuando se toma posesión del TPM, el proceso implica dos cosas: una está generando el SRK, la otra está almacenando el secreto de autenticación del propietario . Una vez establecido, este secreto se utiliza para autenticar usuarios propietarios en sesiones futuras, generalmente a través de un intercambio basado en HMAC.
La especificación de Trusted Computing Group (TCG) para TPM no especifica cómo se creará este secreto, pero Windows usa un hash SHA1 de la contraseña codificada en UTF-16LE, con el terminador nulo de la cadena excluida ( source ). Si pudiera recuperar el secreto de autenticación del propietario del TPM, podría descifrarlo tan rápido como pudiera con cualquier otra contraseña hash SHA1, por ejemplo. a través de oclHashcat. La simple captura de un intercambio de autenticación (HMAC de un valor de desafío con el secreto como clave) no es suficiente para descifrar el secreto de autenticación, ya que el valor del desafío es generado por el TPM.
El SRK se almacena en el TPM en un formato cifrado, utilizando uno de los dos métodos de cifrado diferentes. Si se utiliza el Protocolo de inserción de datos de autorización (ADIP), el SRK se puede cifrar con AES-128-CTR o XOR simple. Si no se usa ADIP, XOR es el único método definido por la especificación. Por lo tanto, se espera que el sistema calcule su propia clave y almacene información secundaria como la IV dentro de las áreas no protegidas del TPM. La creación de la clave para el cifrado es, nuevamente, completamente dependiente del sistema operativo.
Es lógico que se puedan usar diferentes claves para la propiedad del cifrado interno y , es decir, una clave SRK y una clave de propietario. Sin embargo, parece que Windows simplifica la situación usando la misma clave para ambos.
