2) LAS GUERRAS DEL DVD

A finales de los años 70, la tecnología del vídeo doméstico comenzó a erosionar el control que los estudios de cine tenían sobre sus productos. Hasta entonces, la única forma que el usuario tenía de ver una película era ir al cine o esperar a que hubiese un pase por televisión. La popularización de las tecnologías de video (VHS, Beta) hizo que cualquiera pudiese comprar una cinta y verla en su casa cómo y cuando quisiese. Eso vino muy bien a Hollywood, que prontamente se apuntó a este nuevo modelo de negocio. El inconveniente surgió cuando se dieron cuenta de que un video también servía para grabar películas desde el televisor, e incluso hacer copias de cintas originales. La industria lo aceptó como un mal menor, convencida de que los beneficios potenciales de vender millones de títulos superaría el perjuicio de algunas copias pirata de baja calidad.

La situación cambió radicalmente con el advenimiento de las películas en DVD. Ahora la industria corría un peligro mayor, puesto que era potencialmente más fácil copiar películas mediante un ordenador, y la copia tendría la misma calidad que el original. Pronto se cayó en la cuenta de que la criptografía podía ayudarles, no solamente restringiendo la copia de películas sino permitiendo a un estudio el control de sus productos hasta límites insospechados. Las películas podrían en principio estar protegidas con controles de acceso ajustables hasta límites marcados por la imaginación, y los precios de venta podrían variar en función del número de visionados por semana, la frecuencia de acceso, cualquier cosa. Si el usuario quiere ver la película en dos reproductores distintos, se ajusta una tarifa; si ve la película con poca frecuencia, se puede conceder un descuento; si lo que se desea es solamente ver la película durante un máximo de un mes, el disco puede programarse para “autodestrucción” y se inhabilitaría pasado el plazo convenido.

Parece ciencia ficción, pero corresponde a la filosofía del mundo audiovisual. Un detalle que el comprador de un DVD no suele saber es que realmente no está comprando la película. Lo que en realidad adquiere es el derecho a ver el contenido. La compra no implica la posesión, sino la transferencia de unos derechos. Imagínese un mundo en el que el vendedor de un coche pudiese imponer al comprador limitaciones sobre el kilometraje que puede hacer al año o cuántas veces puede salir de la provincia con el coche.

La industria cinematográfica no ha podido llegar tan lejos, pero no ha sido por falta de ganas de intentarlo. Un DVD actual tiene operaciones prohibidas para el usuario, y a pesar de haber pagado por el disco (perdón, por el derecho a disfrutar el contenido del disco) sigue obligado a tragarse los anuncios del FBI o del estudio de cine sobre lo ilegal y peligroso que es hacer copias. Otras operaciones prohibidas al usuario pueden incluir la imposibilidad de saltarse anuncios o promociones de otras películas, así como la obligación de reproducir el disco en una región del mundo determinada. Y las protecciones que incluye el DVD impiden su copia en un ordenador. Esto último implica, como puede imaginarse, criptografía a diversos niveles. De eso trataremos en este tema.

Las técnicas originales para controlar el acceso a los contenidos de un DVD llevaron a la adopción de un estándar internacional denominado CSS (Content Scrambling System). Se trata de un sistema de cifrado empleado en prácticamente todos los DVD con material cinematográfico, cuyo propósito es evitar tanto la copia como la reproducción en dispositivos no autorizados. Para conseguir dicha autorización, el fabricante de reproductores de DVD ha de solicitar la correspondiente licencia, y pagar cierta cantidad por ello a la entidad designada para ello, la DVD Copy Control Association o DVD-CCA^[30]. De ese modo, CSS ayudó a crear un estándar controlado y protegido por la industrial.

La industria de contenidos cinematográficos (en adelante, “la industria”) tenía frente a sí una tarea ímproba. Debía asegurar la protección de miles de películas distintas, que podrían ser reproducidas en aparatos hechos por centenares de fabricantes distintos. Y, por encima de todo, tenía que evitar los errores cometidos por sus primos de la industria discográfica. El aviso que aparece en la web de la DVD-CCA es una alusión a Sony y sus fracasos, tan sutil como una patada en el ojo:

CSS, la tecnología de protección de contenidos usada en muchos títulos DVD, no interfiere en modo alguno en el manejo del ordenador. CSS ha sido diseñado para ser completamente transparente y no invasivo durante la reproducción normal, y no instala ningún programa de software, o archivo de ninguna clase, cuando se utilizan en ordenadores o en cualquier otro dispositivo de reproducción.

El primer elemento del sistema CSS es un dispositivo llamado “módulo de descifrado”. Este es, por así decirlo, el motor criptográfico. El módulo se encargará de todas las tareas de autenticación y cifrado, permitiendo o prohibiendo la reproducción al reproductor DVD, y almacenará en forma segura todas las claves que se requieran.

Lo primero que hace el módulo de descifrado es autenticar el reproductor de DVD. Es decir, debe asegurarse de que el aparato está autorizado para reproducir discos en formato DVD. Este paso permitirá establecer una “relación de confianza” entre el disco y el reproductor.

A continuación, comienza un proceso que al lector puede parecerle complejo, pero que es necesario para poder garantizar la seguridad del proceso. Para poder descifrar el disco, hay una jerarquía de claves. Tenemos en primer lugar la llamada “Clave de Disco (DK)”. Si un atacante la consiguiera podría usarla para reproducir el DVD en cualquier sistema sin necesidad de módulo de descifrado. Hay que protegerla bien. No podemos dejar la clave del disco en cualquier sitio, del mismo modo que no dejamos las llaves del coche colgando de la cerradura.

La clave de disco, necesaria para leer los contenidos del DVD estará a su vez cifrada con una clave maestra, denominada “Clave de Reproductor (PK)”. Cada fabricante tiene una clave de reproductor distinta: Toshiba tiene una, Siemens tiene otra, LG otra, y así una para cada fabricante hasta un total de 409. Es decir, hay un total de 409 claves de reproductor.

Por su parte, el fabricante se asegurará de que sus reproductores tengan incorporada la correspondiente clave PK. Ni que decir tiene que esa clave ha de ser custodiada y protegida fuertemente en todo momento. Lo que hacen habitualmente los fabricantes es “incrustarla” en un chip de hardware, que si está bien diseñado resulta prácticamente inexpugnable. Por su parte, los fabricantes de discos toman la clave de disco, y la cifran con las 409 claves.

Cuando la autenticación ha concluido con éxito, el reproductor de DVD toma su clave de reproductor, y con ella descifra y obtiene la clave de disco DK. Lo que hacemos con ella es utilizarla para descifrar un paquete de datos que contiene las Claves de Título (TK), que son las que finalmente descifrarán los contenidos del DVD. De ese modo, las claves secretas del reproductor (PK) y del disco (DK) se combinan para desbloquear los códigos necesarios para descifrar y ver la película (TK).

En el caso de reproductores software, la cuestión es similar, pero aquí hay problemas adicionales de seguridad. Si una empresa de software quiere diseñar un programa para ver películas DVD, necesita toda la información cifrada que hemos comentado. El problema es que la protección software es mucho más débil que la de hardware. Un atacante tiene, en principio, acceso a toda la información en su propio ordenador, de forma que mantener la seguridad es más difícil.

Aquí es donde comenzaron los problemas para los fabricantes de DVD. Hacia 1996, el sistema de protección CSS estaba en vigor y protegía los discos de los estudios de cine del todo el mundo. Los usuarios podían utilizar cualquier reproductor o programa de software que tuviese la licencia correspondiente.

Había una excepción: los entornos informáticos basados en Linux. Este sistema operativo funciona bajo los principios de software libre, y una de sus premisas es que cualquier elemento de software ha de ser revisable por cualquier programador. Por supuesto, la DVD-CCA no estaba dispuesta a permitir que sus claves criptográficas, piedra angular de la seguridad de todo el sistema, acabasen en el código fuente de un programa Linux, y rehusaron dar licencias a programas basados en ese sistema operativo.

Mala idea. Aunque el porcentaje de usuarios de Linux era entonces muy pequeño, constituían (entonces como ahora) una comunidad intelectualmente muy ágil y activa. Al contrario que un usuario de Windows o Mac, un “linuxero” avanzado considera normal el hacer sus propios programas, y la filosofía de software abierto asegura que cualquier programa hecho por un miembro será rápidamente diseminado por la comunidad.

Visto en retrospectiva, resulta irónico que en la actualidad la DVD-CCA sí conceda licencias a fabricantes de software en Linux^[31]. Seguro que desearon haberlo hecho antes. Negar un reproductor a la comunidad Linux era la mejor receta para asegurarse el enojo de un gran grupo de personas con talento, conocimientos técnicos y voluntad. Y no solamente el enojo, sino también una respuesta contundente.

Entre esos linuxeros enfadados se encontraba un noruego llamado Jon Lech Johansen, quien se hizo mundialmente conocido por haber roto el cifrado CSS. La historia es algo más confusa, ya que al parecer se trató de un trabajo conjunto de dos grupos de hackers. Johansen codificó los resultados de otros en un programa de software para reproducir discos DVD llamado DeCSS^[32], y se hizo muy famoso por ello, hasta el punto de que desde entonces le apodan “DVD Jon”.

El cracking del sistema CSS es un buen ejemplo de las principales técnicas de seguridad informática, desde la criptografía hasta la ingeniería inversa. Por ello, le propongo que dediquemos algún tiempo a examinar el sistema; después veremos cómo puede vencerse.

Lo primero que hemos de mencionar es el modo en que se consiguió obtener la descripción de CSS. Hay una rama de la seguridad informática conocida como “seguridad mediante oscuridad,” de la que ya hemos hablado en este libro, que básicamente viene a decir que la mejor forma de dificultar la tarea del atacante es ocultarle los detalles de los medios de defensa. Según esta filosofía, un ladrón de cajas fuertes tendrá más problemas si no conoce el mecanismo de funcionamiento de la caja.

Este es un mal modo de implementar la seguridad. La experiencia con siglos de uso de la criptografía muestra una y otra vez que la seguridad mediante oscuridad no funciona. ¿Por qué? Muy fácil: porque los atacantes son muy ingeniosos. Un ladrón de cajas fuertes puede obtener información de múltiples fuentes. Puede usar desde ultrasonidos hasta sobornos a empleados de la empresa constructora. Puede recurrir a imágenes térmicas, utilizar un estetoscopio para analizar los sonidos que hace el mecanismo al girar, comprar una caja fuerte para estudiarla y despedazarla. Las posibilidades son muy amplias.

Para evitar este tipo de ataques, la seguridad del sistema no debe depender de ocultar los detalles del mecanismo. El ladrón puede tener los planos completos de la caja fuerte, puede desmontar diez cajas iguales, puede preguntar a los diseñadores hasta el más mínimo detalle; y si a pesar de ello es incapaz de abrir la caja, entonces sí la consideraremos segura. Mantener los detalles secretos puede ayudar en la seguridad, pero no garantizarla a largo plazo.

Los criptoanalistas utilizan desde hace más de un siglo uno de los llamados principios de Kerckhoffs: la efectividad del sistema no debe depender de que su diseño permanezca en secreto. La seguridad mediante oscuridad es una violación flagrante de este principio de Kerckhoffs. Hay muchos ejemplos en los libros de historia. Como mucho, uno puede utilizar la seguridad mediante oscuridad para dificultar la tarea del atacante, pero nunca como elemento esencial de la seguridad integral.

El sistema CSS tiene en la práctica un talón de Aquiles: las implementaciones en software. Como ya hemos dicho, los fabricantes de reproductores de DVD pueden almacenar claves en hardware, un proceso muy seguro. Sin embargo, con un programa de software, la cosa cambia. Existen técnicas de ingeniería inversa que permiten obtener gran cantidad de información sobre la forma en que un programa informático funciona; y es mucho más difícil esconder una clave en un programa informático.

Se cree que fueron los desarrolladores de un grupo llamado MoRE (Masters of Reverse Engineering) los que consiguieron obtener unas de las 409 claves de reproductor, concretamente la correspondiente al programa de software XingDVD^[33]. A partir de ahí, y usando ingeniería inversa, consiguieron averiguar cómo funcionan los algoritmos criptográficos en CSS. Esto nos da una oportunidad de descubrir cómo funciona un sistema de cifrado en el mundo real, así que vamos a aprovecharlo.

El corazón de CSS es un algoritmo conocido como LFSR, siglas en inglés que podemos traducir como Registro de Cambio por Retroalimentación Lineal. Hola, ¿sigue usted aquí? Espero que no se haya ido, asustado por lo que acaba de leer. Reconozco que el nombre impresiona, aunque se queda algo mejor en inglés (Lineal Feedback Shift Register), pero cuando vea en qué consiste se le irá el miedo. La verdad es que se trata de un truquito muy ingenioso.

La idea es la siguiente. Queremos construir un algoritmo de cifra que tome la clave, la combine con el archivo sin cifrar y nos de un archivo cifrado; y que a la inversa, con la clave y el archivo cifrado nos vuelva a dar el archivo original. Más concretamente, vamos a utilizar lo que se denomina un algoritmo en flujo, que realiza la operaciones de cifrado bit a bit. Es decir, combinamos un bit de la clave con uno del archivo, y nos da un bit cifrado.

Para cifrar, utilizaremos una operación parecida a la suma, denominada XOR (⊕). Se trata de algo parecido a una suma, pero con la propiedad de que es su propia operación inversa; es decir. Eso significa que podemos utilizar la misma operación para cifrar que para descifrar, lo que la hace muy útil en aplicaciones criptográficas. La operación de cifrado consiste simplemente en una operación xor de cada uno de los bits de esas variables; igualmente sucede con la operación de descifrado.

El proceso es idéntico al que vimos en el tema “Los códigos de Dan Brown” en relación a la llamada Libreta de Uso Único (OTP). El problema aquí consiste en que la clave K y el mensaje M han de tener la misma longitud, lo que lo convierte en un método poco práctico. En nuestro caso, tendríamos que comprar dos DVDs, uno con la película y otro con la clave. No solamente resultaría muy ineficiente, sino que en principio bastaría con conseguir un disco con la clave para poder descifrar cualquier película; a no ser que los vendedores hicieran una clave distinta para cada disco puesto en el mercado, una idea muy poco práctica. La segunda mejor opción es generar un flujo de bits que no sean realmente aleatorios, pero que lo parezcan a primera vista. Es lo que se llama pseudoaleatoriedad.

La forma más habitual de conseguir largas cadenas de bits pseudoaleatorios es mediante un FSR (Feedback Shift Register) o Registro de Cambio por Retroalimentación; dejaremos lo de lineal para más adelante. Un Registro funciona mediante un conjunto de n bits. En un principio, proporcionamos al sistema n bits iniciales, lo que se llama “semilla” (seed). A continuación el Registro calculará el bit n+1 como función de los n bits iniciales, eliminará el bit número uno y guardará el nuevo bit. Hacemos lo mismo otra vez: calcular un bit nuevo y tirar a la basura uno antiguo. Y otra vez. Y otra vez. Eso nos da un flujo de bits que, si hemos hecho bien los deberes, se asemejará mucho a una cadena de unos y ceros tomados totalmente al azar. Esa será nuestra clave K.

En principio, un Registro que utiliza n bits podrá darnos una cadena pseudoaleatoria de cómo mucho 2^n bits. Después volverá a repetirse una y otra vez, con lo que serán perfectamente predecibles, pero si n es grande, nos dará una clave muy larga.

Vamos a inventarnos un FSR para ilustrar el concepto. Para mayor comodidad, haremos n=4, es decir, será un registro de cuatro bits. Nuestra “semilla” será 1111. Mi función será la siguiente: si el número de cuatro bits, pasado a notación decimal, es primo, entonces añadiremos un uno, y si no, un cero.

Como 1111 es el número 15, y no es primo, voy a añadir un cero a la izquierda, y borraré el bit de la derecha. De esa forma, nuestro 1111 se transforma en 0111. Ahora tenemos el número once, que sí es primo, de forma que introducimos un uno, borramos un uno, y obtenemos 1011. De esa forma, iríamos obteniendo la siguiente secuencia:

La columna “bit nuevo” nos dará nuestro flujo pseudoaleatorio. Pero esperen, ¿no notan algo raro? El estado segundo (0111) se repite en la línea sexta. De hecho, si seguimos dando vueltas a la manivela, este es el resultado:

011101110111011101110111…

Si este fuese un buen FSR, el flujo no se repetiría hasta después de 2^4 = 16 bits, pero aquí se me repite ya en el quinto bit. Aunque hubiese introducido otro valor de semilla, el problema aparecería igualmente. Esto no es un buen generador de números pseudoaleatorios. Por supuesto, este registro no se usa en la práctica, y el motivo por el que aparece aquí es porque sencillamente es el primero que me ha pasado por la mente. Como ven, no soy un buen criptógrafo. Pero otros pueden hacerlo mucho mejor.

Dependiendo de cómo calculemos el bit nuevo, los Registros tienen diferentes nombres. Si las operaciones que realizamos entre los bits del Registro son sumas xor, el registro se llama lineal, es decir, tenemos un LFSR. Si lo hacemos bien, podemos obtener LFSR que nos den cadenas de hasta 2^n bits. He aquí un ejemplo sencillo: produzcamos un bit nuevo como resultado de sumar los bits 1 y 4. Es decir, los cuatro bits (b4, b3, b2, b1) se convierten en estos otros cuatro:

(b4, b3, b2, b1) → (b1⊕b4, b4, b3, b2)

Si partimos de la semilla (valor inicial) 1111, obtendremos la siguiente cadena de bits.

101011001000111101011001000111…

que, como ven, tiene un período de quince, muy próximo al máximo teórico de 16. Una “semilla” inicial 0111 nos da esto:

100011110101100100011110101100…

es decir, la misma repetición que antes, pero con un comienzo diferente. Con un LFSR podemos obtener un buen montón de bits que, aunque no son realmente aleatorios, lo parecen. Un registro con 40 bits nos daría un total de 128 gigabytes, suficiente para cifrar una docena de DVDs. Un LFSR es sencillo de construir, ocupa poca memoria, es rápido y eficiente. Por esos y otros motivos, es una pieza clave en muchos sistemas de cifrado, entre ellos el CSS.

Concretamente, el sistema CSS utiliza no un LFSR, sino dos. El primero, de 17 bits, funciona haciendo xor entre los bits 1 y 15. Es decir, su estado cambia así:

(b17, b16, b12…, b2, b1) → (b1⊕b15, b17, b16…, b3, b2)

El segundo LFSR utiliza 25 bits, y por si les interesa, obtiene un nuevo bit mediante un xor de los bits 11, 19, 20 y 23. La semilla de los LFSR proviene de la clave de título (TK) que vimos antes. En lo que respecta a la elección de ese tipo de registros en particular, podemos imaginarnos que hicieron múltiples pruebas y esa resultó adecuada en términos de rapidez y seguridad, produciendo el equivalente de un solo LFSR con 25+17 = 42 bits. En la práctica son solamente 40 bits, ya que dos de los bits de la semilla se introducen al principio y no forman parte de la clave. En cualquier caso, los dos flujos se combinan en uno para producir la clave que descifrará los contenidos del disco.

Ahora veamos las cosas desde el punto de vista del atacante. Lo primero que hay que tener en cuenta es que, como cabe esperar, un atacante conocerá todos los detalles del sistema, incluyendo el funcionamiento de los LFSR. Lo primero que puede hacer es dejarse de sutilezas criptoanalíticas y limitarse a probar todas las claves, lo que se conoce como ataque de fuerza bruta. Si el número de claves es lo bastante grande, esto resultará inviable en la práctica. ¿Es el caso del sistema CSS? La verdad es que no. Las claves de título o de reproductor tienen una longitud máxima de 40 bits. Esto nos da un total de 1,1 billones de posibilidades. A finales de los noventa, resultaba una tarea ímproba y tediosa (habría que hacerlo para cada título por separado, ya que cada uno tiene su propia clave de título), y un ordenador personal típico tardaría aproximadamente una semana en probar las 2^40 claves posibles.

Una semana parece mucho para poder ver un DVD, pero basta con que el esfuerzo lo haga una sola persona y que luego comparta la película descifrada en una red p2p. La pregunta que surge de modo inevitable es: ¿por qué utilizar claves de sólo 40 bits? Seguro que pueden utilizarse registros mayores que esas birrias de 25 y 17 bits ¿no?

Técnicamente, no hay problema. El conflicto aquí está en el campo legal. Para evitar el uso de tecnologías occidentales por parte de la Unión Soviética y otros países considerados hostiles durante la Guerra Fría, Estados Unidos y sus aliados firmaron en 1976 los acuerdos ITAR (International Traffic in Arms Regulations). Su propósito era controlar la exportación de material de guerra, incluidas las llamadas “tecnologías de doble uso,” que aunque destinadas al mercado civil puedieran ser reconvertidas para uso militar.

Encontrar los productos criptográficos en la lista de prohibiciones ITAR no es extraño puesto que tienen multitud de aplicaciones militares, y por eso ocupan un lugar prominente en la llamada Categoría XIII sobre Equipo Militar Auxiliar^[34]. Lo que ya no resulta tan lógico es que, desaparecida la URSS y acabada la Guerra Fría, las restricciones ITAR permaneciesen en vigor. Ciertamente Estados Unidos tenía enemigos (y los sigue teniendo ahora), pero restringir categorías enteras de productos porque un día pudieran ser utilizados por un enemigo con capacidad destructiva limitada no tiene mucho sentido.

Como dijo una vez el experto en seguridad Bruce Schneier en 1999, no hay muchas películas cifradas que los terroristas necesiten ver^[35]. Las restricciones criptográficas eran tan ineficaces como absurdas. Yo mismo tengo en mi despacho una copia de uno de sus libros más celebrados, Applied Cryptography, edición de 1996. Un amigo me lo compró en Londres a finales de 1998. Se supone que incluía un CD con algunos de los programas criptográficos que describía el libro, pero por las normas ITAR nunca me llegó. Sin embargo, un apéndice del libro contiene cincuenta páginas de código fuente correspondiente a varios algoritmos de cifra. No tengo más que compilarlos y ya está. Lo mejor del caso es que el gobierno norteamericano no podía restringir la exportación del código fuente porque, al estar impreso en papel, se consideraba protegido por la libertad de expresión.

¿Absurdo? Por supuesto. Pero, con independencia de la lógica que contuviesen estas normas, cualquier usuario legítimo de productos criptográficos tenía que atenerse a ellas si quería vender sus productos fuera de Estados Unidos. Las normas norteamericanas permitían la exportación, pero solamente con la condición de que las claves de cifrado utilizadas fuesen de una longitud máxima de 40 bits. Este límite estuvo vigente hasta finales de los años noventa, cuando la explosión de Internet y el auge del comercio electrónico hicieron ver al Tío Sam que continuar con la prohibición perjudicaría fuertemente a su industria. En junio de 1997, el fabricante del navegador Netscape recibió autorización para exportar un navegador con claves de 128 bits^[36]. Microsoft obtuvo un permiso similar para su navegador Internet Explorer.

Para comienzos de 2000, y con ciertas condiciones, se permitía ya la exportación de sistemas con cualquier longitud de clave a casi todos los países del mundo. Pero en 1996, cuando la industria cinematográfica acordó el formato DVD, las restricciones estaban en vigor. Eso les forzó a utilizar claves de 40 bits. Esto no es lo ideal, pero representaba un buen nivel de seguridad contra un usuario individual. Para desgracia de la industria, Internet permitía a un gran número de usuarios beneficiarse del trabajo de unos pocos. Algún linuxero con tiempo libre y ganas de enfrentarse a un reto, unas cuantas neuronas en acción, y ya tenemos una película descifrada lista para subir a una red p2p. O mejor aún, podemos disponer del programa de descifrado directamente, como sucedió con DeCSS.

Veamos cómo las mentes inquietas de la Red vencieron el sistema CSS. Comencemos por los LFSR. Un detalle que no les he comentado hasta ahora es que su carácter lineal los hace altamente vulnerables a un ataque criptoanalítico particular. Imaginemos un registro de n bits cuyos detalles internos no conocemos. De algún modo, el fabricante ha conseguido ocultarnos esa información. Pero no le servirá de nada, porque un atacante puede reproducir el registro (o bien construir otro registro distinto pero equivalente) sin más que examinar 2n bits de salida. Este resultado, que aprovecha el carácter lineal del registro, se conoce con el nombre de algoritmo de Berlekamp-Massey.

Los diseñadores de CSS probablemente tuvieron eso en cuenta, y es por eso que utilizan dos registros LFSR. El resultado de los dos se suma para dar lugar al flujo de bits que formará la clave de descifrado de la película, y eso previene el uso del algoritmo de Berlekamp-Massey. Ese debe de ser el principal motivo por el que no se utiliza un solo registro, sino dos en combinación.

Pero los registros lineales usados en CSS tienen otras vulnerabilidades. Para describirlas, usaremos el concepto de complejidad. Diremos que un algoritmo de cifra tiene una complejidad m si reventar el sistema nos requiere el mismo trabajo que probar m claves distintas. En un sistema perfecto con clave de n bits de longitud, la complejidad del sistema es exactamente 2^n, lo que significa que no hay atajos. Cuando más vulnerable sea, menor será la complejidad y más fácil será obtener la clave y descifrar el texto protegido.

En ocasiones, la complejidad de un sistema disminuye si conocemos algo sobre él, y este es el caso de los LFSR de CSS. Supongamos, por ejemplo, que conocemos los primeros cinco bytes de salida del LFSR combinado (es decir, la suma de los dos que estamos usando). En ese caso, existe una táctica que permite recuperar la clave inicial de 40 bits, que recordemos se usa como semilla inicial de los registros.

En circunstancias normales, obtener esos cinco bytes no sería nada fácil. Sin embargo, en este caso es factible. Resulta que, cuando CSS está descifrando la claves de título, utiliza una operación denominada “exprimido” (mangling). Esa operación tiene un fallo, de tal forma que si conocemos el mensaje llano y el mensaje cifrado podemos obtener exactamente cinco bytes de la clave generada por el LFSR. Ambos fallos, el del LFSR y el del “exprimidor,” se combinan para crear una vulnerabilidad crítica. Como resultado, la complejidad del sistema se reduce a tan sólo 2^16. O dicho de otro modo, la seguridad de todo el esquema es equivalente a la de un sistema de cifrado con clave de 16 bits.

Otro ataque criptoanalítico, igualmente devastador, nos permite obtener la clave de disco DK. Este ataque fue descrito por Frank A. Stevenson en 1999^[37] y no entraremos aquí en detalles. Solamente le diré que podemos obtener dicha clave con una complejidad de 2^25. Lo que llevaba una semana ahora puede conseguirse en apenas unos segundos.

Los esfuerzos de Johansen y otros permitieron hacer programas para visualizar discos DVD en entornos Linux. Cualquiera podría tomar un DVD original y hacer una copia saneada (sin cifrado, operaciones prohibidas o códigos de zona) mediante programas como DVD Decrypter. A todos los efectos, la seguridad de CSS estaba totalmente rota antes de terminar la década de los noventa.

Eso dejó a la industria del video con una sola opción: el frente legal. DVD Jon fue llevado ante los tribunales noruegos por hacking informático en 2002, a petición de la DVD-CCA. Puesto que no había violado ninguna ley de su país, el juez emitió una sentencia absolutoria. El programa que redactó para ver videos en entornos Linux sigue en la red, y otros desarrolladores de software lo imitaron.

Una de las respuestas de la industria fue instar al gobierno norteamericano a cambiar la ley. El resultado fue la DMCA (Digital Millennium Copyright Act), que entre otras cosas prohíbe la producción y distribución de programas o sistemas diseñados para sobrepasar medidas anticopia. También limita el uso de los métodos de ingeniería inversa. Como resultado de ello, los creadores de DVD Decrypter tuvieron que retirar su programa en 2005, si bien existen copias en Internet^[38].

La DVD-CCA intentó en diversas ocasiones mejorar el sistema CCS, lo que no es tarea fácil en absoluto. Cualquier solución deberá pasar no solamente por mejorar el sistema existente, sino también por asegurar su compatibilidad con los discos y reproductores ya existentes. En al menos tres ocasiones (1999, 2001 y 2005) intentaron evaluar sistemas de “marca de agua” (watermarking) para “marcar contenido audiovisual para transmitir cierta información de control de copia… con el objeto de mejorar el sistema de protección de copia CSS con respecto a información audiovisual”.

A tenor de los requisitos descritos, la idea parece ser que los contenidos originales lleven una especie de marca digital, que no pueda ser borrada en caso de alteraciones del archivo original, y que incorporen códigos especiales capaces de identificar a) si se ha usado CSS como protección y b) si la copia está autorizada. Los reproductores de DVD futuros incorporarían dispositivos para impedir la reproducción de copias no autorizadas^[39]. En los tres casos, el concurso para encontrar una solución viable quedó desierto.

Algunas empresas cinematográficas desarrollaron sus propios esquemas de protección adicionales en sus DVDs. La solución de Sony fue un sistema presentado en 2007 y denominado ARccOS (Advanced Regional Copy Control Operating Solution). Considerando el historial de Sony a la hora de proteger los discos con música, deberíamos creer que aprendieron del error. No parece ser el caso. ARccOS funciona creando sectores corruptos (por tanto, ilegibles) en ciertos lugares del DVD. De ese modo, los programas anticopia producen errores de copia y no pueden funcionar. Por desgracia, esto causaba que algunos reproductores de DVD no funcionasen correctamente^[40]. Poco tardaron en aparecer programas copiadores que se saltaban esa protección.

Un segundo método, utilizado por Disney, Paramount y Warner, se conoce como Disney Fake o Disney X-Project. Reconozco mi incompetencia a la hora de encontrar información sobre este sistema. Sí puedo confirmar que la copia en DVD de Piratas del Caribe 4: en Mareas misteriosas no puede ser copiado con los “dvd rippers” habituales, si bien se anuncian en Internet programas que pueden hacerlo.

Sin embargo, no hay un estándar acordado para su uso por toda la industria. Un consorcio llamado 4C Entity, formado por cuatro empresas de electrónica (IBM, Intel, Matsushita e Hitachi) propuso en 1999 un sustituto a CSS llamado CSS2, pero la propuesta fue rápidamente retirada. La solución pasaría por comenzar a diseñar desde cero un buen esquema de cifrado. El resultado, publicado en 2005, fue el sistema AACS (Advanced Access Content System). Pero nunca fue utilizado en discos o reproductores DVD. Los problemas de compatibilidad con los sistemas existentes lo impedían.

No, el AACS tenía otros destinatarios en mente: los nuevos formatos de alta definición HD DVD y Blu-ray. La industria subía el listón para asegurar la protección del sistema sucesor al DVD, haciendo todos los esfuerzos imaginables para corregir y evitar los errores del pasado. Por su parte, la comunidad internauta, vencedora de la batalla del DVD, estaba lista para afrontar los nuevos retos. La guerra de los medios digitales entraba en una nueva fase.