3) LA ALTA DEFINICIÓN

A comienzos del siglo XXI, la industria videográfica se planteó seriamente la conveniencia de actualizar las especificaciones existentes para el video digital (DVD) y dar el salto a un nuevo formato. Las razones fueron fundamentalmente tres. En primer lugar (sin ningún orden en particular), se deseaba poder introducir más información en los discos, aumentando así la calidad y definición de las imágenes. En segundo lugar, se confiaba en que la alta definición digital conllevase una nueva revolución en el consumo de productos audiovisuales, similar a la que generó el paso del formato analógico (VHS, Beta) al digital (DVD), lo que sin duda contribuiría a revitalizar la industria del ocio. Finalmente, un nuevo conjunto de especificaciones de seguridad bien hechas sustituiría al sistema CSS, que como hemos visto tiene más agujeros que un colador.

De forma similar a como VHS y Beta compitieron por el mercado de vídeo analógico, dos estándares pugnaron durante años por imponerse: HD DVD, patrocinado por Toshiba, y Blu-ray, impulsado por un consorcio liderado por Sony. Tras una guerra de varios años, Toshiba acabó cediendo y retiró su sistema, dejando a Blu-ray como único formato de discos compactos de alta definición.

Desde nuestra óptica de seguridad, poco importa el resultado, ya que ambos sistemas estaban dotados del mismo sistema de seguridad llamado AACS (Advanced Access Content System). Este estándar fue publicado en 2005, y representa un salto cualitativo respecto a su predecesor CSS. La industria hizo un serio intento por superar los fallos anteriores, y un análisis de AACS muestra que realmente se tomaron la seguridad en serio, abandonando casi totalmente la “seguridad mediante oscuridad”.

La primera mejora se observa en los algoritmos básicos de cifrado y firma digital. En CSS, se utilizaron algoritmos hechos por la propia industria, en lugar de confiar en sistemas seguros y probados. Por el contrario, el cifrado y descifrado en AACS utiliza el algoritmo AES (Advanced Encryption Standard), que ha sido sometido a multitud de pruebas durante años y se considera uno de los mejores sistemas de cifra existentes en la actualidad. AES no sólo sirve para cifrar, sino que también es utilizado para otras aplicaciones seguras como generar números pseudoaleatorios. Primer punto a favor de los propietarios de AACS, que por cierto es un consorcio de empresas agrupadas en la entidad AACS Licensing Administratior (AACS-LA).

Tampoco bajaron la guardia en otros aspectos criptográficos igualmente importantes, a saber: funciones hash y firma digital. En el primer caso, se utiliza una función con propiedades especiales para poder representar grandes archivos mediante cadenas alfanuméricas pequeñas; es un paso especial para poder realizar operaciones de firma digital. AACS utiliza SHA-1 como función hash, y EDCSA para firma digital mediante criptografía de curva elíptica. Ambas funciones han sido ampliamente probadas y se las considera de lo mejorcito en sus respectivos campos. En todos esos casos, no hay seguridad mediante oscuridad que valga, ya que todos los detalles de estos algoritmos han sido hechos públicos y comprobados hasta la extenuación^[41].

Hasta este punto, todo indica que la industria ha echado la casa por la ventana. Nadie podrá encontrar fácilmente una vulnerabilidad o un fallo. Esto es lo que deberían haber hecho desde el principio, y aunque metieron la pata a lo grande en el caso de los DVD, por lo menos hemos de reconocerles que aprendieron de sus errores. Casi dan ganas de aplaudir.

Pero escoger buenos algoritmos criptográficos es un paso necesario, no suficiente. Es necesaria una jerarquía de claves para asegurarse de que las claves no sean fáciles de extraer por terceros no autorizados. Hay que implementar mecanismos para evitar la copia no autorizada. Finalmente, sería deseable establecer un sistema de revocación que permita bloquear un reproductor que haya sido comprometido de algún modo; de esa forma, si un aparato Blu-ray ha sido usado para piratear películas, podrá ser bloqueado en el futuro.

El sistema AACS permite ambas cosas. Para ello, juega con las claves como si fuesen un conjunto de muñecas rusas, guardando unas dentro de otras. El esquema puede parecer caprichoso, pero está diseñado para garantizar diversos aspectos dentro de la seguridad global.

La primera diferencia que nos encontramos es que ahora no hay una clave de reproductor para cada fabricante. En el caso de CSS, había un total de 409 claves de reproductor, una para cada fabricante. Si un hacker consigue obtener la clave de un fabricante (digamos, la de Toshiba), puede utilizarla para descifrar todas las películas que quiera. En su lugar, podemos pensar en insertar una clave distinta para cada aparato reproductor individual. Es decir, si Toshiba vende diez millones de copias de un modelo en particular, cada uno de esos diez millones de reproductores llevará una clave diferente, llamada Clave de Dispositivo (DK).

Eso permite a la industria algo muy útil: la revocación. Digamos que uno de los diez millones de reproductores Toshiba ha sido usado para descifrar películas, o para copiarlas sin permiso. Una vez se haya identificado el culpable, su clave de dispositivo puede ser revocada, es decir, inutilizada. De esa forma, ese reproductor en particular no podrá volver a ser usado para reproducir discos (ni aunque sean discos legítimos), y el hacker tendrá que tirar su Toshiba nuevo a la basura.

El problema es que puede haber mil millones de reproductores Blu-ray (y HD DVD, aunque de esos apenas quedan ya) en el mercado, y como un disco no sabe en qué reproductor va a ser insertado, en principio tendríamos que almacenar en cada disco mil millones de claves para poder descifrar las películas. Una cantidad tan grande de claves no cabría en el disco. Para evitar el problema, las especificaciones AACS utilizan un procedimiento denominado “árbol de diferencia de subconjuntos”. Los detalles son algo tediosos, pero se lo explicaré con un ejemplo.

Digamos que usted llega a vivir a una gran urbanización, donde cada puerta se abre mediante un código numérico de cuatro cifras, como el PIN de su tarjeta de crédito. En primer lugar, hay una puerta común para entrar en el complejo. A continuación, una segunda puerta guarda la entrada del edificio. Una tercera puerta impide la entrada a la planta. La cuarta puerta protege el pasillo, y la quinta es la entrada de su vivienda. Como ve, hay que atravesar cinco puertas, y por tanto usted necesitará cinco códigos PIN para llegar a su vivienda. Usted no paga las cuotas de la comunidad, y la junta ha decidido bloquearle el acceso. Para conseguirlo, ordena reprogramar el sistema, de forma que cuando se introduzcan los cinco códigos PIN de usted, la puerta no se abra. Cada uno de esos PIN abre una puerta de forma legítima, pero cuando está usted a punto de entrar en su vivienda, una pantalla cercana le indica “la combinación de códigos 1193, 9733, 0119, 6251, 8111 ha sido desactivada”. Esa combinación de cinco números PIN está en la “lista negra” y no se permite su uso, a pesar de que cada PIN individual abre perfectamente la puerta que se le ha asignado.

Un esquema algo similar sucede en AACS. Cada aparato reproductor recibe no una, sino un conjunto de Claves de Dispositivo, con las que se construye la llamada Clave de Procesamiento. A su vez, la Clave de Procesamiento descifra un bloque llamado MBK (Media Block Key), que contiene la información sobre los aparatos que están en la lista negra. Si en algún momento se detecta que un reproductor determinado “amenaza la integridad del sistema” (es decir, se ha usado para piratear o copiar una película), la información de ese aparato será incluido en el MBK y diseminado en las películas que se graben en el futuro. Más adelante, el dueño de ese aparato comprará una película original e intentará reproducirla, pero ese nuevo disco ya contendrá la información para revocar ese reproductor, y no permitirá el descifrado de la película. Es algo así como tratar con un tramposo que se va del bar sin pagar: hoy se sale con la suya, pero mañana todos los bares de la zona tendrán su descripción y no podrá repetir el truco.

Este esquema de revocación es algo que no se podía hacer en el sistema CSS de los DVD, donde todo lo más que se podía hacer era un “todo o nada”. Si se detecta que un reproductor Toshiba determinado ha participado en una actividad de copia no autorizada, lo único que se podía hacer era eliminar la clave de los reproductores Toshiba. El problema es que con ello estamos bloqueando todos los reproductores que Toshiba ha fabricado jamás, desde el primero al último. Dudo que los otros 9 999 999 propietarios se lo tomasen bien. Por el contrario, ahora podemos afinar la revocación hasta el punto de que podemos bloquear un aparato reproductor determinado sin que los demás se enteren siquiera. Este procedimiento también se puede aplicar en software, aunque como ya hemos mencionado en otras ocasiones la seguridad en software es menor que en hardware y se precisan mecanismos adicionales de autenticación.

El siguiente paso en la cadena de seguridad impide la copia no autorizada. Una vez que hemos insertado nuestro disco, y se ha comprobado que nuestro reproductor no está en ninguna lista negra, se genera una clave llamada Clave de Medio (Km). Un código numérico llamado Identificador de Volumen se extrae del disco, y ambos datos se procesan mediante el algoritmos AES. El resultado, si todo va bien, es una nueva clave llamada Clave Única de Volumen (Kvu). El truco consiste en que el identificador de volumen no puede reproducirse fácilmente. No está almacenado en el disco como si fuera un archivo normal y corriente, y solamente se puede acceder a él si se utiliza una clave especial que está oculta en el reproductor. De esa forma, ni siquiera una copia del disco bit a bit permitirá su reproducción.

Si el sistema está satisfecho con nuestra honradez, nos habrá permitido crear la Clave Única de Volumen, ya nos estamos acercando al final. El disco almacena la llamada Clave de Título (Tk), que es necesaria para ver la película. Esa clave está protegida mediante cifrado, y la clave de descifrado es precisamente la clave única de volumen; así que tomamos esa clave de volumen, la usamos para obtener la clave de título, y será dicha clave la que descifrará la película. Puede que una película tenga más de una clave de título, pero a estas alturas esos detalles no nos importan. Lo único que debe ya preocuparnos es que las palomitas no quemen y que nadie nos importune mientras nos recostamos en el sillón a ver nuestra estupenda película en alta definición.

Los grandes estudios de cine comenzaron a producir y vender discos en alta definición, confiados en que AACS proporcionaban por fin la seguridad que deseaban. Nadie podría sobrepasar las barreras de AES, no había forma posible de descifrar una película y colgar los resultados en Internet. Se acabó la tontería. Lo único que había que hacer era esperar a que los usuarios se convirtiesen en masa a la alta definición, inundando las tiendas y llenando de dólares las cajas fuertes de Hollywood.

Para su desgracia, eso nunca sucedió del todo. Para cuando la larga guerra de la alta definición entre HD DVD y Blu-ray se saldó con victoria de esta última, muchos usuarios ya se habían pasado a sistemas de descarga directa (streaming), o bien permanecieron fieles al formato DVD, que aunque de menor calidad era muy sencillo de copiar y compartir. Incluso hoy día, el futuro de Blu-ray permanece en entredicho, y no está claro hasta qué punto logrará arraigar. Pero por lo menos, no se trataba de una decisión basada en la inseguridad del formato de alta definición. AACS era sólido como la roca.

Aunque a veces aparecía alguna pequeña grieta que daba a los fabricantes un susto ocasional. En julio de 2006, la revista alemana c’t descubrió una forma de trampear el sistema. Uno de los reproductores de películas en Windows, un programa llamado WinDVD, permitía hacer una copia de la pantalla, es decir, extraía un fotograma en alta definición. Un hacker con mucha paciencia no tendría más que irlas guardando como archivos, uno tras otro, y luego agruparlos para recomponer el video. Un hacker con menos paciencia y más habilidad lograría automatizar esta tarea.

Aunque este tipo de actuación podía haber llevado a WinDVD a la lista negra, no fue necesario tomar una medida tan drástica. La AACS-LA reconoció que Intervideo, fabricante del programa WinDVD, había cumplido las especificaciones de seguridad AACS al pie de la letra. Una pequeña actualización al programa, y problema resuelto^[42].

Esta anécdota difícilmente constituye algo que pueda considerarse como romper la protección AACS, pero fue un recordatorio de dos cosas: primera, que ningún sistema de seguridad es completamente impenetrable; segundo, que hay millones de personas ahí fuera con tiempo e imaginación, y basta una de ellas para arruinarte el día.

Ese día llegó con las navidades. El 27 de diciembre de 2006, un hacker con el seudónimo muslix64 publicó en Internet un programa llamado BackupHDDVD, que pretendía nada menos que descifrar contenidos protegidos con AACS. El anuncio, publicado en el foro forum.doom9.org^[43], levantó una gran polvareda. Cuando se asentó el polvo, se supo la verdad: realmente AACS no había sido comprometido. El sistema seguía siendo sólido. Pero se descubrió algo casi igual de malo: una forma de obtener las claves de título.

El propio muslix64 lo explicó todo^[44]. Su motivación fue similar a la de DVD Jon cuando reventó el sistema CSS. Resulta que sus programas de software (en Windows) no podían reproducir contenido en alta definición. Se puso a pensar, y en un par de semanas descubrió una manera de obtener la clave de título Tk, que recordemos es la que, tras todos los pasos de verificación, utiliza el sistema para descifrar la película. Durante el proceso, la clave de título se encuentra en algún lugar de la memoria del ordenador. Así pues, ¿por qué no limitarse a reproducir el disco, hacer un volcado de memoria y buscar algo que se parezca a una clave?

Una vez conseguida la clave, lo único que había que hacer era confeccionar un programa que, al introducirle la clave, descifre y reproduzca los contenidos cifrados. Eso es lo que hace su programa BackupHDDVD^[45], puenteando todas las demás protecciones que hemos descrito anteriormente. El problema estriba en que hay que darle las claves, ya que el programa no las recupera; pero la ventaja es que cualquiera que sepa hurgar en la memoria de un ordenador puede recuperar la clave de un disco y colgarla en Internet. Un segundo programa para Blu-ray (BackupBluRay) fue liberado por el mismo autor en enero de 2007^[46].

Pronto se dio un paso más en esta escalada criptográfica. Recordemos que la Clave de Título Tk está (o están, si hay más de una en el disco) protegida con la Clave Única de Volumen Kvu. En algún momento el sistema tendrá que sacar la Kvu, y en ese momento estará almacenada en memoria. ¿Podemos repetir el truco y extraer la Kvu de la memoria? Pues resulta que sí se puede. Poco tardó muslix64 en modificar sus programas para utilizar directamente la Clave Única de Volumen.

Los esfuerzos de diversos grupos de internautas se agruparon en webs como aacskeys.com y hdkeys.com, donde se llegaron a acumular hasta trescientas claves de películas, la mayoría obtenidas de discos HD DVD. En la actualidad esas webs ya no existen, pero aún pueden encontrarse copias si se sabe dónde buscar. Por ejemplo: ^[47] para aacskeys.com y ^[48] para hdkeys.com. En forum.doom9.org, todavía se puede acceder al thread sobre claves HD DVD^[49], así como a un archivo que las contiene todas^[50]. Un archivo similar guarda las claves obtenidas, por procedimientos similares, para los discos en formato Blu-ray^[51].

Es importante reseñar que, en todos estos casos, no se trata de un ataque criptoanalítico en términos convencionales. Nadie saltó las protecciones criptográficas, nadie encontró una vulnerabilidad en AES o SHA-1. Tan sólo se trató de aprovechar el eterno talón de Aquiles: cómo usar claves sin que éstas puedan ser leídas y copiadas. En los reproductores de hardware, resulta relativamente sencillo proteger las claves contra lectura, pero en aplicaciones software, como hemos visto, es algo extraordinariamente difícil. Basta con que un solo vendedor de software lo haga mal para que el sistema se venga abajo poco a poco.

En el caso de los reproductores de software HD DVD, que fue donde comenzó el problema, se mencionó en primer lugar el programa PowerDVD; posteriormente se localizó el principal “culpable” de la filtración, o cuando menos, el programa que utilizaron hackers como muslix64 para extraer información sobre las claves. Este programa es el WinDVD, de Intervideo, el mismo programa donde se detectó el truco de “hagamos una película grabando los fotogramas uno a uno”. La pobre Corel Corporation tuvo que tragarse un sapo amargo, ya que acababa de adquirir Intervideo apenas dos semanas antes de que muslix64 hiciese público su primer ataque. Seguro que el CEO (consejero delegado) de Corel pensaba en otra cosa cuando anunciaba que “estamos centrados en presentar software que le inspire a usted, de modo que desee usarlo,” aunque el propio muslix64 puede suscribir esas palabras^[52].

También la AACS-LA tuvo que reconocer la gravedad de los ataques. El 24 de enero de 2007, una nota de prensa reconoció que “algunas Claves de Título de AACS han aparecido en webs públicas sin autorización,” al tiempo que le daba un tirón de orejas a los vendedores de WinDVD (sin nombrarlos explícitamente) y anunciaba el uso de “todos los remedios apropiados,” lo que sin duda significa notificaciones legales DMCA para detener la proliferación de claves. Puede pensarse que lograron un cierto éxito, ya que como resultado ahora no se encuentran accesibles las webs originales donde se ofrecían gratuitamente tanto las claves como los programas de reproducción, pero Internet es un animal con memoria. El mero hecho de que yo, varios años después, haya logrado encontrar copias de toda la información relevante, es una indicación de la futilidad de intentar ponerle puertas al campo.

Las cosas se pondrían peor para la industria. Mucho peor. En febrero, entró a escena un segundo hacker, apodado arnezami, cuyas hazañas harían palidecer a las del propio muslix64. Arnezami se dedicó a extraer toda la información posible de un disco de alta definición. Su idea, al parecer, es ir subiendo por el “árbol de jerarquías” del sistema criptográfico, obteniendo cada vez claves más importantes.

Arnezami comenzó con el Identificador de Volumen (VID, a partir de ahora), ese código que usa el sistema AACS para comprobar si una película es original o ha sido copiada. Estuvo probando suerte con la película King Kong, y este es el VID que consiguió encontrar^[53]:

40 00 09 18 20 06 08 41 00 20 20 20 20 20 00 00

Lo más curioso del caso es que, como comprobaron otros expertos, esta cadena numérica no es aleatoria. Muy por el contrario, tiene una estructura. Lo primero que llama la atención es el hecho de que, aunque el VID está escrito en formato hexadecimal, todos sus números son decimales. No es algo significativo, pero resulta llamativo. En segundo lugar, durante el proceso para descubrir la Clave de Volumen de esa película, se comprobó que estaba relacionada con la fecha en la que la película fue creada para ser estampada en los discos. En el caso de King Kong, la fecha era el 18 de septiembre de 2006, y la hora era las 8 y 41 minutos de la mañana.

Para que entiendan lo que ello implica, voy a poner la fecha en formato norteamericano, donde escriben primero el mes y luego el día: 09-18-2006. Ahora, la hora: 08:41. Y ahora fíjense de nuevo en la VID de King Kong. Si se dan cuenta, verán que comienza con 40 00 y acaba con 00 20 20 20 20 00 00. ¿Y qué hay entre medias? Pues la cadena numérica 09 18 20 06 08 41. ¿Lo captan? 09-18-2006 08-41? ¡El VID no es más que la fecha de fabricación del disco!

Un análisis de otros discos HD DVD reveló que no siempre el VID se construye a partir de una fecha y hora de fabricación, pero las alternativas son asimismo predecibles. El VID de la película Serenity contenía la cadena hexadecimal 53 45 52 45 4E 49 54 59, que cuando se pasa a código ASCII nos da la palabra SERENITY^[54]. De modo similar, el VID de La Chaqueta Metálica (Full Metal Jacket) no es más que la representación ASCII de FULLMETALJAC. Los VID de algunas películas incluían la cadena hexadecimal 57 47 48 44 56 4D, que en ASCII se convierte en la críptica cadena alfanumérica WGHDVM.

El propio Arnezami calificó este resultado como increíble, y no podemos menos que estar de acuerdo. Si hay algo que reduce la seguridad de un sistema, es el hecho de usar claves o códigos identificativos fácilmente predecibles. El VID fue creado con la intención de evitar la copia no autorizada, y en su arrogancia, la industria de Hollywood utilizó identificadores de volumen altamente predecibles, confiando en que la oscuridad que protege al VID sería suficiente. Por si no fuera suficiente, lo rodean siempre con las mismas cadenas numéricas, lo que para un programa que efectúe búsquedas en memoria es lo mismo que una gigantesca bandera que diga “estamos aquí, dispare cuando quiera”.

La ventaja de conocer el VID es que, si además tuviésemos acceso a la Clave de Medio, podríamos descifrar la Clave Única de Volumen Kvu. No tendríamos que ir buscándola en un título tras otro, sino que tendríamos una forma de calcularlo sin más que echar mano al VID. Por supuesto, eso es equivalente a afirmar que, si yo fuese millonario, estaría dándome la gran vida. Ese “si” es condicional, no afirmativo, y para mi desgracia resulta que yo no soy millonario, y el paisaje que veo por la ventana no es precisamente el de las playas paradisíacas de la Polinesia Francesa.

Soñar no cuesta nada. Salvo por el detalle de que hackers como muslix64 y arnezami ya habían realizado logros que supuestamente no eran posibles. Las claves de título no deberían ser accesibles, pero podemos acceder a ellas. La clave única de volumen está protegida mediante cifrado, pero podemos conseguir una copia. El identificador de volumen no debería ser visible, pero podemos verlo. ¿Hasta dónde podemos llegar siguiendo ese camino?

El siguiente gran paso sería, por tanto, conseguir la Clave de Medio, pero el proceso de “esnifar” en memoria ya no nos ayuda. El esquema de diferencia de subconjuntos, usado por el sistema para comprobar si un reproductor ha sido bloqueado, hace muy difícil la obtención de la Clave de Medio. Lo increíble del caso es que arnezami lo consiguió. El 11 de febrero de 2007, publicó la Clave de Medio para la película King Kong^[55]:

07 4E 1F C8 8F B9 B7 80 A2 25 CA A2 3B C3 DB 56

Se trataba de una gran noticia, pero arnezami apuntaba a lo más alto: quería las claves maestras, las que controlan la seguridad de todo el sistema. Recordemos el sistema de capas que conforman AACS: hay un conjunto de Claves de Dispositivo, con las que se podía construir una Clave de Procesamiento, la cual controla el MKB (Media Key Block), que a su vez construía la Clave de Medio, que a su vez produce la Clave Única de Volumen, que a su vez descifra la Clave de Título, que es la que descifra la película. Hasta ahora hemos visto que se puede acceder a todas salvo a las más importantes: las de Dispositivo y las de Procesamiento. Son las claves maestras, y su revelación podría echar abajo todo el sistema. Los creadores de las especificaciones AACS lo sabían, e hicieron todo lo posible por mantenerlas fuera del alcance de ojos fisgones.

El propio arnezami comparte con nosotros su experiencia^[56]. Sus intentos por obtener las claves de dispositivo fueron inútiles. Pero descubrió que la clave de medio se borraba de la memoria en cuanto ya no era necesaria. Pensando que lo mismo le sucedía a la clave de procesamiento, y puesto que había comprobado que todas las claves importantes se almacenaban en la misma zona de la memoria del ordenador, se dedicó a comprobar todos los cambios que se hacían en dicha zona. De esa forma, con un poco de paciencia, el 11 de febrero de 2007 logró encontrar y capturar la Clave de Procesamiento:

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Resulta difícil exagerar la importancia de este descubrimiento. La Clave de Procesamiento es la que, como he mencionado antes, controla el Media Key Block y sus listas de revocación. Está por encima del esquema de revocación, así que ella misma no puede ser revocada; de hecho, es ella la que decide qué claves son revocadas. Es lo más próximo al control total que existe. Y era un control en manos del usuario, ya que a mediados de marzo el propio arnezami hizo público un programa llamado aacskeys, que buscaba automáticamente todas las claves necesarias en el disco. Ya no hacía falta hackear el sistema a mano, ni buscar claves en segmentos de memoria. Era un sistema de “pulsar y usar,” que no requería conocimientos técnicos por parte del usuario^[57].

El 11 de febrero de 2007 fue un día negro para la industria del video digital. El día 15, la AACS-LA tuvo que emitir una nota de prensa en la que reconocía la publicación de la Clave de Procesamiento, pero la fraseología que usaron intentaba quitarle hierro al asunto: “es una variación de un ataque ya publicado… no representa un impacto adverso para la capacidad del ecosistema de AACS de responder al ataque”.

Lo cierto es que las reglas de juego habían cambiado radicalmente. El cambio de claves era inútil a estas alturas. El descubrimiento de la Clave de Procesamiento no podía arreglarse más que cambiándola, o bien modificando el Media Key Block. En cualquier caso, todos los discos de alta definición que habían sido puestos en circulación hasta la fecha podrían ser leídos y copiados impunemente. Cualquier solución solamente serviría para proteger los discos futuros, no los ya publicados.

Finalmente, el día 24 de febrero un hacker llamado ATARI Vampire dio el golpe final al sistema: buscando en la zona de memoria ya sugerida por arnezami, consiguió extraer la Clave de Dispositivo correspondiente al programa WinDVD8^[58]:

AA 85 6A 1B A8 14 AB 99 FF DE BA 6A EF BE 1C 04

Esto cambiaba totalmente las cosas para la industria. No solamente habría que modificar la Clave de Procesamiento, sino que las mismísimas Claves de Dispositivo estaban en peligro. Que solamente se hubiese extraído para el programa WinDVD8 no significaba que los demás reproductores en software no estuviesen en peligro, y cada uno de ellos era una fuente en potencia de claves reveladas y películas extraídas. De hecho, apenas diez días después otro hacker, llamado jx6bpm, publicó la Clave de Dispositivo del programa PowerDVD^[59]:

47 37 67 60 58 D7 02 94 52 51 4F 0A B1 86 DC 4C CA 8C 57 8F

Para empeorar las cosas, una empresa de software llamada SlySoft aprovechó para pescar en río revuelto. Esta compañía está radicada en una isla caribeña, fuera de la jurisdicción norteamericana, y desde allí comercializa diversos programas para… hmmm… realizar copias de seguridad. AnyDVD, uno de sus programas, fue actualizado el 15 de febrero de 2007 para poder realizar copias de discos HD DVD protegidos con AACS. El 5 de marzo ya podía reproducir discos Blu-Ray^[60]. Al no ser una empresa licenciada, no podía obtener legalmente ninguna clave, pero según jx6bpm AnyDVD incorporaba la Clave de Dispositivo de PowerDVD. Ya no se trataba de un entretenimiento para grupos de hackers con mucho tiempo libre, sino de un ataque en toda regla contra el modelo de negocio de la industria cinematográfica.

Fue la gota que colmó el vaso de la AACS-LA, que cambió a mediados de abril las claves de ambos reproductores. En principio deberían haberse revocado, pero eso hubiera afectado a todos los usuarios de esos programas impidiéndoles reproducir discos legítimos, así que se optó por un cambio de claves. En este caso, como se trataba de software, resultaba muy fácil de realizar: bastaba con proceder a una actualización online. Las dos empresas responsables, Corel^[61] y Cyberlink^[62], intentaron hacerlas pasar por actualizaciones rutinarias, pero por supuesto esta medida no cogía de sorpresa a los que sabían el verdadero motivo.

Los responsables de seguridad de la alianza AACS-LA tenían delante un ímprobo trabajo para intentar atajar los daños. Debían cambiar la Clave de Procesamiento en todos los aparatos reproductor y recuperar la confianza de los usuarios. En el intento, protagonizaron uno de los episodios más estrambóticos en la historia de la propiedad intelectual.

La AACS-LA utilizó la ley DMCA para detener, o al menos intentar frenar, la diseminación de información. Las webs que guardaban claves de volumen, y las que proporcionaban copia de los nuevos programas para reproducir y copiar discos, eran retiradas bajo amenaza de iniciar acciones legales contra los responsables. Hasta cierto punto, es algo que resulta razonable, toda vez que estaban intentando proteger su negocio contra un ataque.

Pero cuando intentaron prohibir la publicación de la Clave de Procesamiento (09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 en notación hexadecimal), los acontecimientos adquirieron un cariz que solamente puedo intentar describir como una mezcla entre Kafka y los Hermanos Marx. Clave o no clave, se trata de un número (en notación hexadecimal, pero número a fin de cuentas). Resulta absurdo pensar en patentar o prohibir un número, pero eso es exactamente lo que la AACS-LA intentó hacer. El 17 de abril, al tiempo que se anunciaban las “actualizaciones de seguridad” de los reproductores WinDVD y PowerDVD, se enviaron notificaciones a diversas páginas web donde se guardaba una copia de la “clave 09F9”.

Para los no-norteamericanos, nos resulta absurdo pensar siquiera que alguien se tome en serio una cosa tan boba como prohibir un número, pero en EEUU la ley DMCA establece penas muy serias para cualquier violación de propiedad intelectual, incluida la posesión de “herramientas para sortear ilegalmente medidas de protección”. Algunas páginas de gran tráfico, como la propia Wikipedia, cumplieron con el mandato.

A la postre, sin embargo, la sensatez se impuso. Prohibir un número no solamente es cuestionable desde el punto de vista de la ley, es que resulta imposible en la práctica. Una de las formas más originales de diseminarlo fue mediante códigos de colores. Un color viene representado mediante tres parejas de dígitos hexadecimales. Eso significa que la clave puede indicarse mediante cinco barras de colores (15 dígitos), mas el dígito “C0” añadido”. Si usted tiene una pantalla en color, podrá ver a continuación la Clave de Procesamiento codificada en esos cinco colores:

Esta representación cromática se hizo famosa con el nombre de “bandera del discurso libre”, donde el C0 final se incorporó como “+C0,” y representaba la idea de que publicar un número debería ser un “crimen cero”^[63]. Ahora el absurdo aumentaba, porque habría también que prohibir cinco colores de la paleta.

La rebelión prendió en la Red, y fue amplificada por digg.com, una web colaborativa donde los lectores pueden proponer noticias, y también votarlas. En un principio, los responsables de Digg decidieron, a pesar de lo absurdo de la medida, atenerse a la ley DMCA y retirar los mensajes y comentarios relacionados con la clave 09F9. Sin embargo, los usuarios no hacían más que enviar noticias sobre la clave, cada vez con mayor frecuencia e insistencia. Finalmente, el creador de Digg Kevin Rose cedió, y el 1 de mayo de 2007 le dio al público lo que quería:

“Vosotros preferís ver caer a Digg luchando, antes que arrodillarse ante una gran empresa. Os hemos oído, y con carácter inmediato dejaremos de borrar historias y comentarios que contengan el código… Si perdemos, qué demonios, al menos habremos muerto en el intento” ^[64].

Lo que la BBC describió como “una revuelta del siglo 21”^[65] adoptó tantas formas como cabían en la imaginación de la gente. La clave se diseminó en camisetas^[66], canciones^[67], obras de arte gráfico^[68], tatuajes^[69], gorras, tazas y un sinfín de objetos. La historia de la clave 09F9 ha quedado como ejemplo de cómo la lucha por proteger un derecho legítimo puede llegar a extremos de absurdo.

Mientras la rama de relaciones públicas de la AACS-LA intentaba bailar con la más fea, sus colegas del departamento técnico se pusieron manos a la obra e hicieron lo único que parecía resolver el problema: crear y distribuir una nueva Clave de Procesamiento. El resultado conllevó una modificación del Media Key Block a una nueva versión denominada MKBv3 (MKBv1 fue la que utilizaba la Clave de Procesamiento 09F9; hasta donde se sabe, nunca hubo una MKBv2). Esta solución no impediría el copiado y diseminación de las películas ya publicadas, pero podía impedir que los hackers extrajesen las Claves Únicas de Volumen de los futuros estrenos. Era el menor de dos males, comparado con no hacer nada. Eso también resolvería la pesadilla de relaciones públicas, ya que la clave 09F9 quedaría obsoleta.

Sin embargo, seguro que el lector avezado habrá llegado ya a la conclusión lógica: ¿qué impedirá que los hackers extraigan la nueva Clave de Procesamiento? Las técnicas de volcado de memoria y búsqueda paciente que tan buenos resultados les ha dado en el pasado seguían vigentes. Ed Felten, desde su blog Freedom to Tinker, profetizaba ya futilidad de la medida^[70]:

“Parece inevitable que los atacantes, en cosa de un mes, tendrán éxito al extraer las claves del nuevo software… yo diría que los atacantes extraerán las claves del nuevo software en unas tres semanas”.

Felten se refería a las nuevas claves insertadas en los programas WinDVD y PowerDVD. Aún faltaban cosa de un mes para que la clave de procesamiento 09F9 se hiciese pública. Pero sus palabras resultaron proféticas. En uno de sus artículos, un internauta apodado BtCB incluyó el día 23 de mayo un número hexadecimal y las palabras “¿cuál es la probabilidad de que se trate de la nueva clave de procesamiento?”^[71]. Una semana después, arnezami confirmó que la clave publicada por BtCB es realmente la nueva Clave de Procesamiento^[72]:

45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

No se sabe la fecha exacta del descubrimiento, ni quién lo realizó, pero el programa copiador AnyDVD lanzó una actualización el día 20 de mayo para ofrecer “soporte a la nueva versión de AACS”^[73].

Esta nueva derrota representaba un inconveniente catastrófico para la AACS-LA. Incluso una medida tan radical como cambiar la Clave de Procesamiento en todos los reproductores software (y los futuros reproductores hardware) del mundo se mostraba inútil frente a una comunidad de personas anónimas que parecen conocer el sistema mejor que sus propios diseñadores. Programas desprotectores como AnyDVD muestran que cualquiera puede extraer el contenido de una película de alta definición; o más cómodo aún, esperar a que otro lo haga y lo cuelgue en una red p2p.

Lo único que podía hacerse era volver a cambiar la Clave de Procesamiento, y cruzar los dedos esperando que los hackers se cansasen del asunto y se dedicasen a otra cosa. Vana ilusión. El nuevo Media Key Block versión (MBKv4) fue anunciado el 7 de septiembre de 2007, y apenas un mes después el programa AnyDVD ya ofrecía soporte para algunos discos protegidos con MBKv4^[74]. Un mes después, “algunos” se convirtieron en “todos”^[75].

Un nuevo cambio modificó de nuevo el MBK a la versión 8, que comenzó a funcionar en abril de 2008 (no sabemos qué pasó con las versiones 5-7); luego hubo más cambios en algún momento de 2009 (a estas alturas, la AACS-LA no se molestaba siquiera en anunciar sus “actualizaciones”), y como resultado apareció la versión MBK9, seguida prontamente por la MBK10. Todas fueron atacadas y sus Claves de Procesamiento fueron recuperadas. Las incluyo aquí todas, empezando por la primera:

A partir de este punto, la situación degenera en una carrera predecible y hasta cierto punto aburrida. La Clave de Procesamiento deja de renovarse, o al menos los hackers dejan de publicarla en Internet, así que podemos suponer que la AACS-LA se limita a cambiar el MKB por otros procedimientos Comienzan a aparecer nuevas versiones de MKB cada vez con mayor frecuencia, y no siempre consecutivas; y continúan apareciendo Claves Únicas de Volumen para todos los estrenos de cine.

A estas alturas, el campo de batalla del mercado había cambiado radicalmente. La guerra de los formatos de alta definición acabó con la derrota del sistema HD DVD. Toshiba, su principal valedor, abandonó en febrero de 2008, y el sistema Blu-ray quedaba como vencedor único en el panorama de la alta definición. Hace falta un nuevo paradigma de seguridad, y este es el momento en que aparece un nuevo esquema de seguridad. AACS seguirá siendo usado, pero será complementado por una capa adicional de seguridad.

El nombre de la nueva protección es BD+ y fue desarrollado por la empresa Cryptography Research. Diré simplemente que se trata de lo que los informáticos llaman una “máquina virtual,” una especie de sistema operativo dentro de otro sistema operativo. El concepto de máquina virtual es muy útil para poder, por ejemplo, desarrollar o ejecutar programas Windows en un ordenador que funcione bajo Linux. Es una forma de simular un sistema operativo sin tener que instalarlo.

Como recordará el lector, la vulnerabilidad fundamental del esquema AACS consistía en que se podían extraer las claves gracias a programas que realizan volcados de memoria. Eso ya no será posible, ya que BD+ crea algo parecido a un sistema operativo propio. Como un pelotón de comandos que asegura una playa antes de un desembarco, la máquina virtual creada por BD+ examina los alrededores, comprueba la integridad de las claves, ejecuta ciertos programas para asegurarse de que no hay enemigo a la vista y, cuando está satisfecho, da la luz verde a las fuerzas de invasión, en este caso al proceso de descifrado de audio y video. Esto funciona tanto en hardware como en software.

Los primeros títulos protegidos con BD+ salieron al mercado en octubre de 2007. En aquellos momentos, la AACS-LA pugnaba por intentar cerrar la brecha de seguridad, y ya había visto morder el polvo sus MKB v3 y v4. Eran los últimos meses del formato HD DVD, y aunque su caída no fue cosa de un día o de un solo factor, hay que resaltar el hecho: HD DVD no disponía del sistema BD+ y Blu-ray, sí.

La Blu-ray Disc Association no tuvo mucho tiempo para disfrutar mientras veía pasar el cadáver de su enemigo. El 19 de marzo de 2008, justamente un día después de la muerte oficial del formato HD DVD^[76], AnyDVD tenía ya capacidad completa para eliminar la protección de los discos Blu-ray, incluyendo la capa de BD+^[77]. En repetidas ocasiones, el formato DB+ fue modificado para adaptarse al último ataque, pero caía en el siguiente. Y había más fabricantes de software: en 2010 entraron en liza DVDFab^[78] y Pavtube^[79], con programas capaces de saltarse las protecciones AACS y BD+ Para resumir: una combinación de hackers, piratas e internautas diversos habían logrado obtener todas las claves necesarias para saltarse las protecciones AACS, y también para evitar los controles adicionales de BD+.

Había una protección adicional al final de la línea. Los críticos siempre habían señalado que, por muy buenas que sean las medidas de protección, al final el contenido de la película es enviado al televisor o monitor. Eso significa que, si elimino el televisor y lo sustituyo por una grabadora, puedo obtener una copia sin cifrar. Es una vulnerabilidad, en efecto, y para evitarla Intel Corporation diseñó un sistema de protección llamado HDCP (High-bandwidth Digital Content Protection). Se trata de una capa de cifrado que protege las comunicaciones entre el reproductor y el televisor. Ambos elementos tienen que estar diseñados con ese estándar si queremos disfrutar de contenido en alta definición.

Por supuesto, nada nos impide conectar nuestro reproductor Blu-ray a un televisor o monitor sin HDCP, pero solamente obtendremos calidad estándar similar a la de un DVD. En Europa, cualquier elemento de hardware que pretenda lucir la etiqueta “HD ready” deberá incorporar HDCP de forma obligatoria y, por supuesto, pagar la correspondiente cuota^[80]. Huyendo de la seguridad mediante oscuridad, las especificaciones HDCP se hicieron públicas^[81], y hay incluso código fuente libre para replicarlo^[82]. Si usted tiene un dispositivo con conexión HDMI o DVI, sepa que HDCP está ahí dentro, haciendo guardia en la garita.

HDCP tiene dos funciones: autenticación y cifrado. Como de costumbre, el primer paso es asegurarse de que ambas partes, a las que llamaremos desde ahora E (emisor, por ejemplo un reproductor Blu-ray) y R (receptor, por ejemplo un televisor) están autorizadas para intercambiar información; en caso afirmativo, el segundo paso consistirá en acordar una clave de cifrado. Los algoritmos son relativamente sencillos, así que vamos a examinarlos aquí.

En lo alto de la jerarquía de claves de HDCP tenemos la Clave Maestra, fuertemente protegida por la autoridad central. A partir de esa clave maestra se creará una clave privada y una pública para cada aparato, sea emisor o receptor. La clave privada es en realidad un “paquete” de 40 claves, de 56 bits de longitud cada una, y que colectivamente reciben el nombre de Claves Privadas de Dispositivo. A partir de ahí, cada aparato toma un bit de cada una de esas claves, y con ellos construye una clave pública que recibe el nombre de Vector de Selección de Clave (KSV). La KSV tiene la particularidad de que, de sus 40 bits, veinte son ceros y otros veinte son unos. Además de eso, cada aparato tiene su propia clave privada, también de 40 bits. A partir de ahora, llamaremos U a la clave privada y V a la clave pública, y le añadiremos una letra adicional para identificar al emisor e y al receptor r.

El mecanismo de autenticación comienza en el emisor, que tiene claves privada y pública Ue, Ve, respectivamente. Lo primero que hace el emisor es escoger un número aleatorio, digamos N, y se lo envía al receptor junto con su clave pública Ve. El receptor toma la clave pública que acaba de recibir y la multiplica por su propia clave privada, obteniendo la cantidad K’ = Ve*Ur. Puesto que cada clave tiene 40 bits, el producto Ve*Ur debería tener 1600 bits de longitud. En nuestro caso no es así, porque se desea que el producto tenga 56 bits, así que se utiliza una operación llamada “producto vectorial en el anillo Z/2^56 Z”.

En cualquier caso, cuando el receptor calcula K’, no se lo envía al emisor. En su lugar, efectúa una operación hash, que para nuestros propósitos es una función criptográficamente segura en la que introducimos dos números (Ve, N) y obtenemos un tercer número de 16 bits que llamaremos R’. Matemáticamente lo podemos escribir como R’= h(Ve, N). Ahora el receptor envía al emisor el paquete de dos números formado por R’ y Vr. Cuando el emisor recibe dicho paquete, calcula K=Vr*Ue y efectúa la operación R=h(K,N). Si R=R’ todo ha ido bien, y K=K’ es la clave que acaban de compartir.

Para que quede más claro:

El hecho de que R = R’ indica dos cosas. En primer lugar, que ambas partes han usado el mismo número aleatorio N. Ese número en sí no significa nada, pero indica que el proceso se ha llevado a cabo ahora. Sin él, un atacante podría grabar la comunicación que E y R mantuvieron la semana pasada. En segundo lugar, nos hemos asegurado de que K’ es igual a K, y esa será la clave compartida. A primera vista no parece evidente que ambas sean iguales, pero eso es porque me he callado un pequeño detalle: las claves de ambos dispositivos se calcularon de tal forma que siempre se cumpla que Ve*Ur=Vr*Ue. Si el emisor y el receptor fueran personas, ni siquiera bajo tortura podrían confesar por qué es así, ya que ellos mismo no lo sabrían. Basta con que los creadores originales de las claves lo sepan, y con eso basta. De ese modo, no solamente emisor y receptor han comprobado que quien está al otro lado es un interlocutor autorizada, sino que al mismo tiempo han acordado la clave K con la que cifrarán la información que a partir de ahora se intercambien.

El algoritmo de cifrado es una combinación de tres elementos. En primer lugar, tenemos un conjunto de cuatro Registros de Cambio por Retroalimentación Lineal (LFSR). Ya vimos el funcionamiento de los LFSR en el apartado de los DVD, así que no lo repetiremos aquí. Lo importante es que estos LFSR generan un flujo pseudoaleatorio, es decir, una cadena de bits que no son aleatorios pero lo parecen. Esa cadena de bits actuarán como clave en un algoritmo de cifra en bloque. Finalmente, el resultado es mezclado en una tercera fase para, finalmente, producir un flujo de datos cifrado.

Es una lástima que tanto trabajo al final no sirva para nada. Porque, como quizá habrán adivinado a estas alturas, del dicho teórico al hecho práctico hay mucho trecho. El esquema HDPC adolece de una grave vulnerabilidad, descubierta en 2001 por un grupo de criptoanalistas norteamericanos^[83]. Lo más curioso del caso es que no entraron en absoluto en los detalles técnicos del proceso de cifrado, nada de jugar con los LFSR o con la función de compresión. En lugar de eso, se centraron en el proceso de intercambio de claves y se dieron cuenta de que es lineal. Y eso es malo. Les explicaré por qué.

La idea básica en cualquier autenticación emisor-receptor es, recordarán, que los pares de claves cumplan la condición de que Ue*Vr=Ur*Ve=K, donde K es la clave compartida. Para entender el problema, vamos a imaginar que tengo dos aparatos emisores, a los que llamaré X e Y. Yo digo que puedo usarlos para “construir” otro aparato Z cuya clave sea la suma de las dos anteriores, esto es: Uz=Ux+Uy, Vz=Vx+Vy.

¿Qué pasará si intento comunicar Z con un receptor R? Veámoslo. Cada uno de los dos aparatos (Z, R) calculará sus claves respectivas K y K’ de la siguiente forma:

Ahora bien, como X y R tienen claves válidas, resulta que Vx*Ur =Vr*Ux, es decir, K1=K3. Por el mismo motivo, al tener Y y R claves válidas, tenemos que K2=K4. Conclusión: K=K’, lo que significa que cualquier combinación lineal de claves válidas será también una clave válida. Un atacante puede sacar partido inteligente de este hecho, ya que solamente necesita cuarenta pares de claves (pública-privada) para reconstruir la Clave Maestra, y a partir de ahí el atacante puede hacer lo que se le antoje: generar claves falsas, descifrar archivos, clonar reproductores.

¿Y de dónde sacará un atacante esos cuarenta pares de claves? Los autores sugieren técnicas como ingeniería inversa, pero hay una forma más fácil: comprándolas legalmente a la entidad que otorga las licencias.

No fue el único ataque de estas características. Un mes antes, un criptógrafo holandés llamado Neils Ferguson anunció que había conseguido romper el algoritmo HDPC, consiguiendo un nivel de control similar. Desafortunadamente, las consecuencias legales derivadas de la ley DMCA le impidieron publicar sus resultados^[84].

Los ataques de 2001 no parecen haber sido aprovechados por ningún hacker. De hecho, da la impresión de que fuesen ignorados. Quizá sea porque HDPC era un sistema de protección secundario, comparado con los pesos pesados del barrio BD+ y AACS. Pero cuando esos pesos pesados cayeron, HDPC se convirtió en una especie de última línea de defensa, y fue entonces cuando se ganó la atención del respetable. El propio Neils Ferguson lo profetizó en 2001:

[La DMCA] me impide publicar mi artículo ahora, pero algún día, alguien, en algún lugar, duplicará mis resultados. Esa persona podrá decidirse a publicar la clave maestra HDPC en Internet. En lugar de arreglar HDPC ahora antes de ser desplegado a gran escala, la industria se enfrentará a los gastos de insertar HDPC en cada dispositivo, sólo para que luego resulte inútil. La DMCA acabará costándole dinero a la industria. Adivinen quién acabará pagando al final.

Indudablemente, el pagano acabará siendo el consumidor. Durante los diez años que ha estado utilizándose el sistema HDPC, la entidad licenciadora ingresó incontables millones de euros gracias a una situación de monopolio de facto. Nadie que quiera vender un dispositivo de alta definición podrá dejar de pasar por caja.

Esa situación cambió radicalmente en 2010. El 13 de septiembre de ese año, apareció una página en pastebin.com con el título “¿Es auténtica la clave HDPC filtrada?” La web ya no existe, pero existen copias^[85]. En ella, se incluye nada menos que la Clave Maestra, el “anillo para controlarlos a todos”. Si esa clave fuese la auténtica, ahora cualquiera podría crear pares de clave pública/privada para cualquier dispositivo.

Por supuesto, el hecho de que alguien publique una ristra de números no significa que realmente sea la Clave Maestra. Pero en este punto la historia se repite. En el año 1917, los ingleses consiguieron descifrar el Telegrama Zimmermann, que contenía una información capaz de alterar el curso de la guerra. Surgió entonces la duda sobre si el telegrama era auténtico, o si se trataba de una hábil falsificación llevada a cabo por Inglaterra para arrastrar a los Estados Unidos a la guerra. Arthur Zimmermann, ministro alemán de Asuntos Exteriores, disipó las dudas de los incrédulos al reconocer en una rueda de prensa que el telegrama era cierto.

En este caso, el papel de Zimmerman fue representado por Tom Waldrop, portavoz de Intel, quien dos días después de la revelación confirmó que la clave era auténtica^[86]. Quizá fuese un intento por parte de Intel de paliar los daños, ya que cualquiera podría tomar la Clave Maestra filtrada y probarla. Un criptógrafo podría verse frenado por las consecuencias legales, pero en la Red hay mucha gente con menos escrúpulos. La identidad de la persona que filtró la Clave Maestra permanece desconocida a día de hoy.

La Clave Maestra es una matriz de 40*40=1600 elementos, y cada uno de ellos es un número de 56 bits (o, lo que es lo mismo, 16 caracteres hexadecimales). Como es bastante voluminosa, puede usted consultarla en la referencia^[85b], que también incluye las instrucciones de uso. Lo primero que hacemos es escoger un vector de selección de clave (KSV), que es como se llama aquí a la clave pública. Ese vector va a tener veinte unos y veinte ceros. A continuación, nos vamos la matriz que forma la Clave Maestra, y escoger las filas que nos indican los ceros del KSV. Para entenderlo con un ejemplo, supongamos que este es nuestro KSV:

1010001010111000100110101110000111010101

Tenemos que leer comenzando por el bit más bajo, es decir, de derecha a izquierda. Encontramos unos en las posiciones 1, 3, 5, 7, 8, 9… Eso significa que tenemos que tomar las filas 1, 3, 5, 7, 8, 9… de la matriz formada por la Clave Maestra, y sumarlas módulo 2^56 (eso significa que, si la suma nos da un número mayor que 2^56, le restamos 2^56 tantas veces como sea necesario para obtener un número menor que 2^56). El resultado es la clave privada. Así de sencillo. Bueno, salvo por un detalle. Lo que hemos construido así es la clave privada para un emisor, lo que en las especificaciones se llama una fuente. Para construir la clave privada de un sumidero (un receptor, como un monitor de TV), hacemos lo mismo, pero tomando la matriz traspuesta.

Hasta cierto punto puede parecer que romper HDCP no es relevante, ya que los ataques contra AACS y BD+ pusieron a disposición del público reproductores software libres, copiadores y películas libres de cifrado. Con todo, conlleva interesantes aplicaciones para el usuario. HDCP se utiliza también para proteger la señal de los dispositivos llamados “repetidores,” entre los que se incluyen los aparatos que reciben señales de video en descarga directa (streaming). Con el uso de la Clave Maestra filtrada, cualquier empresa puede en principio construir un dispositivo adaptador que, aplicado a la salida del reproductor (por ejemplo, un video Blu-ray o una PS3) permite visualizar el contenido en cualquier televisor, convertido así en un receptor “Full HD”.

La Digital Content Protection LLC (DCP), entidad que otorga las licencias HDCP, tomó medidas al respecto. Para no cometer los mismos errores de relaciones públicas que vimos en el caso AACS, se abstuvieron de perseguir a los difusores de la Clave Maestra. En su lugar, remodelaron el sistema de seguridad. La fase de autenticación está ahora basado en un sistema de criptografía de clave pública, con claves RSA de 1024. El protocolo SHA-1 fue escogido para las operaciones de firma digital. La generación de números aleatorios, parte importante en el proceso, se confió al algoritmo AES, que también sería utilizado para el cifrado de los contenidos. Como ven, copiaron a AACS en lo bueno: la elección de buenos algoritmos. Se acabó eso de utilizar criptografía hecha en casa.

Un hecho notable es que las contramedidas de protección del nuevo HDCP (versión 2.0 y posteriores) no fueron hechas precipitadamente, como suele ocurrir cuando alguien rompe el sistema. Las especificaciones 2.0 tienen fecha de octubre de 2008, dos años antes de que la Clave Maestra fuese filtrada y se hiciese necesaria una sustitución. Mi hipótesis es que los técnicos de la DCP tomaron buena nota del ataque de 2001, y a lo largo de varios años fueron diseñando un sistema más robusto, que entre otras cosas podía incluir opciones para proteger transmisiones inalámbricas (entre dos televisores ubicados en habitaciones distintas, por ejemplo, o las provenientes de un router que retransmita contenidos de televisión), así como comunicaciones por Internet.

A pesar de ello, existe un grave fallo de seguridad. Un grupo de investigadores de la Universidad Ruhr-Bochum alemana, dirigidos por Tim Güneysen, anunciaron en noviembre de 2011 que habían abierto brecha en la protección HDCP 1.3 mediante un sistema distinto. En lugar de utilizar la Clave Maestra, interpusieron un conjunto de chips especiales FPGA entre un reproductor Blu-ray y un monitor. Interceptando y modificando los mensajes que se intercambiaban, consiguieron descifrar las comunicaciones, en este caso una película^[87].

La principal aplicación del estudio de Güneysen era la protección de comunicaciones en el campo militar y otros entornos de alta seguridad. Pero resulta que el ataque puede ampliarse a los reproductores HDCP de todo tipo, incluidos los que cumplen las nuevas especificaciones 2.1 (sucesoras de las 2.0). El problema está en la compatibilidad. Si las especificaciones 2.1 se impusiesen tal cual, ningún dispositivo que utilizase las versiones anteriores podría funcionar. Nuestro nuevo reproductor Blu-ray con HDCP 2.1 no podría verse en un televisor de alta definición con HDCP 1.4. Por ese motivo, los nuevos sistemas han de ser compatibles con los algunos, lo que suele llamarse “compatibilidad hacia atrás”. Mientras exista esa compatibilidad los dispositivos antiguos y los nuevos podrán conectarse sin problemas, pero por el mismo motivo el sistema seguirá siendo vulnerable a los fallos que tumbaron la versión HDCP 1.4.

Las perspectivas de supervivencia de HDCP 2.0 (ahora 2.1) son, por el momento buenas. El sistema parece robusto, y lo será más cuando se resuelva el agujero de seguridad que representa la compatibilidad hacia atrás. Pero, visto lo visto sobre los demás sistemas de seguridad que han intentado proteger los contenidos de alta definición hasta el día de hoy, no me atrevería a asegurar nada.