Autenticación de la Unidad y el host mediante acuerdo de clave

Para diseñar un esquema de protección de los medios de información que sea capaz de ejecutarse en plataformas abiertas como PCs, los diseñadores tienen que asegurarse de que no sea susceptible al ataque de "virtualización del dispositivo". Un dispositivo virtual puede simular un dispositivo físico en todos los aspectos a fin de que la CPU sea engañada y crea que existe un dispositivo cuando en realidad no lo hay. Para implementar un ataque de dispositivo virtual a un sistema de medios de información, tales como los sistemas de reproducción de DVD, el atacante puede construir software que implementa una unidad de DVD virtual. El contenido de los discos ópticos se traslada al disco duro del ordenador como una imagen del disco. El atacante puede entonces reproducir este "disco DVD" a través de la unidad de DVD virtual en un software reproductor de DVD legítimo.

El atacante puede duplicar la imagen del disco en múltiples copias y difundirlas ilegalmente, a pesar de que él nunca conozca el contenido del DVD. Con el fin de defenderse contra este ataque, la unidad tiene que tener la capacidad de demostrar que el host (por ejemplo, el software de reproducción) es una unidad legítima. Esto se puede conseguir por medio de un protocolo criptográfico de autenticación.

El esquema de autenticación AACS unidad-host realiza una autenticación mutua, que significa que no sólo la unidad demuestra su identidad legítima al host, sino que también el host tiene que demostrar su identidad a la unidad. Después de que la unidad y el host completan con éxito el período de sesiones de protocolo de autenticación, se establece entre ellos una clave secreta compartida. Por lo tanto, el protocolo de autenticación mutua del

AACS unidad-host se combina con un protocolo de acuerdo de clave. La clave secreta compartida se utiliza para propósitos de autenticación de mensaje.

5.3.1 Protocolo de autenticación mutua y protocolo de acuerdo de clave

En un protocolo de autenticación mutua, las dos entidades participantes necesitan demostrar sus identidades los unos a los otros. Si una entidad ha demostrado con éxito su identidad a la otra entidad, la otra entidad está obligada a "aceptarle". Un período de sesiones de protocolo de autenticación mutua se completa con éxito si ambos participantes se aceptan hasta el final del período de sesiones. Los Protocolos de autenticación mutua se pueden diseñar utilizando ya sea esquemas criptográficos de clave simétrica o asimétrica.

Después de que las dos entidades se hayan autenticado la una a la otra, lo más normal es que quieran comunicarse entre ellas. Por lo que tiene sentido combinar un protocolo de acuerdo de clave o protocolo de intercambio de claves con uno de autenticación mutua, porque una clave secreta compartida proporciona confidencialidad y / o integridad de los datos a ambas entidades. En un protocolo de acuerdo de clave, ambas entidades contribuyen con información que se utiliza para obtener una clave secreta compartida. Un protocolo de acuerdo clave utiliza la mayoría de las veces un esquema de clave asimétrica. En un protocolo de intercambio de claves, la clave secreta compartida no es necesariamente producto de la información aportada por las entidades participantes, y es difícil de conseguir un protocolo de intercambio de claves seguro.

5.3.2 Descripción del esquema de autenticación del AACS Unidad-Host

Cuando se usa el AACS en un sistema basado en PC, la unidad y el host son entidades separadas, tanto la unidad y el host poseen certificados expedidos por parte de la AACS LA. Estos certificados, denominados certificado de la unidad y certificado del host, contienen campos donde se indica la capacidad del dispositivo, un identificador único, la clave pública del dispositivo y una firma de la AACS LA, que verifica la integridad del certificado firmado con una clave privada de la AACS LA. Tanto la unidad como el host tienen la correspondiente clave pública de la AACS LA para la verificación de la firma. Se puede

Cada vez que se coloca un nuevo medio en la unidad, se produce el proceso de autenticación entre la unidad y el host. Esto es necesario porque el nuevo disco puede contener listas de revocación actualizadas. Cada disco compatible contiene unaestructura de datos llamada Media Key Block (MKB), que posee la información necesaria para obtener las claves para descifrar el contenido. También contiene la última lista de revocación de la unidad (DRL) y lista de revocación de host (HRL), que respectivamente, contienen una lista de identificadores de las unidades revocadas y una lista de identificadores de los hosts revocados. Una unidad sólo puede comunicarse con un host que no haya sido revocado, y del mismo modo un host sólo podrá comunicarse con una unidad que no haya sido revocada.

En el Anexo 9.5 se puede consultar el flujo del esquema de autenticación de la AACS unidad-host.

Después de completar con éxito el algoritmo de autenticación de la unidad y el host, ambas establecen una clave de bus compartida basada en el protocolo de acuerdo clave de Diffie - Hellman de curva elíptica. Es interesante observar que, si bien esta clave podría ser utilizada para cifrar los mensajes entre la unidad y el host, no se utiliza realmente para este fin. En lugar de ello, la clave de bus se utiliza únicamente para la autenticación de mensajes mediante la inclusión de un MAC para cualquier mensaje que viaje entre la unidad y el host.

5.3.3 Análisis del esquema de autenticación del AACS unidad-host

En este esquema, se pueden destacar principalmente dos debilidades. La primera de ellas se encuentra en los primeros cuatro pasos del esquema de autenticación. Supongamos que la DRL en el MKB es más reciente que la almacenada en la DRL host. Un usuario malicioso, puede cambiar el número de versión MKB a un una edad avanzada, y enviar la modificación de MKB’ al host. Esta modificación podría no ser detectada durante el procedimiento de autenticación, ya que, según las especificaciones, el host primero comprueba el número de versión de la MKB, y si el número de la versión es más antiguo que su DRL, salta al paso 2, que implica la verificación de la firma de la DRL en el MKB.

Si la unidad ya ha sido revocada, se podría alterar maliciosamente el número de la versión del MKB, con el fin de no dejar que el receptor actualice su DRL, de modo que pueda mantener la interacción con el host.

La segunda debilidad es la siguiente: Supongamos que A y B son dos entidades participantes honestas tratando de establecer una clave secreta a través de un protocolo de acuerdo de clave y X es una entidad maliciosa. En este ataque, X suplanta a las entidades honestas, es decir, A cree estar compartiendo una clave con X, cuando en realidad lo está haciendo con la otra entidad honesta B y ésta, cree que está compartiendo la clave con A. Por lo tanto, al final del protocolo, X puede actuar en el nombre de B para interactuar con A. Este ataque podría ser explotado en la práctica. Por ejemplo, supongamos que se revoca a la unidad A. A continuación, se puede emplear este ataque preguntando a la unidad B, que no está revocada, para suplantarla. Dado que el host sólo ve el certificado de la unidad B, el procedimiento de la autenticación debería concluir con éxito. De esta manera, la unidad A todavía puede interactuar con el host después del procedimiento de autenticación.