La UEFI hizo una pequeña presentación que describe por qué necesitamos llegar al TPM 2.0 y olvídate del 1.2.
Primero, el algoritmo SHA-1 se considera inseguro y, como se suele decir, el simple hecho de saltar a SHA-2 no es eficiente a largo plazo. Así que TPM 2.0 soporta en teoría todo tipo de algoritmo hash. Aquí está la la política de NIST sobre la función de hash . SHA-1 no debe usarse para ningún uso criptográfico. (como dice el bosque, sha-1 solo es débil contra la colisión, el uso de SHA-1 con HMAC no está realmente afectado)
Teniendo en cuenta la criptografía asimétrica, el RSA no es tan obsoleto (mientras que nos quedamos con claves de longitud decente), pero quizás algún día, el problema de la factorización de enteros ya no sea un problema gracias a algoritmo de Shor . Necesitamos tener cualquier tipo de criptografía de clave pública. Así que hay todos los algoritmos de criptografía de curva elíptica, los algoritmos de logaritmos discretos y, obviamente, la factorización de enteros. > más vulnerable al algoritmo de Shor ). Antes del TPM 2.0, la única opción que teníamos era la RSA. Los algoritmos disponibles dependen de lo que el proveedor quería implementar.
Finalmente, considerando la criptografía simétrica, con TPM 1.2 tenemos el XOR y especialmente AES. No se conoce ningún ataque contra AES, pero tener la opción es bueno. Hay alternativas a AES como Blowfish. Y debe haber algún tipo de opciones políticas (AES es aprobado por la NSA, algunas personas / países pueden pensar que este es un mal indicador: «Si la NSA lo aprueba, debe saber cómo descifrarlo»)
Se supone que es más fácil de usar. Citaré la presentación de la UEFI:
Eliminado el confuso
habilitado / activado / deshabilitado / desactivado
estados
-
Está ahí o no allí (tabla ACPI)
-
Si está presente, puede ser utilizado por el firmware incluso
si no está expuesto al sistema operativo
Finalmente, TPM 2.0 contiene 3 claves de jerarquía permanentes (Plataforma, Almacenamiento, Privacidad) contra solo una para TPM 1.2.
La jerarquía de privacidad utiliza endorsementAuth y puede usarse para generar EK (Clave de aprobación al igual que en TPM 1.2), y así generar fácilmente AIK (Clave de identidad de certificación), que se puede usar en < a href="https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation"> Certificado Anónimo Directo (Autenticación con una Prueba de Conocimiento Cero)
La jerarquía de seguridad utiliza ownerAuth y se usa para cifrar / descifrar datos.
La jerarquía de la plataforma utiliza PlatformAuth y se puede usar para inicializar el TPM, y habilitar / deshabilitar el uso de las otras jerarquías.
Básicamente, con 3 jerarquías en lugar de 1, puedes hacer lo mismo, pero las autorizaciones son más inteligentes.