Boletín ENIGMA - nº 61
1 de Junio de 2008
Boletín del Taller de Criptografía
de Arturo Quirantes Sierra
Dirección original: http://www.cripto.es/enigma/boletin_enigma_62.htm
TEMAS DE ACTUALIDAD - Reto criptográfico en Fermilab
TEMAS DE ACTUALIDAD - Bletchley Park te necesita
TEMAS DE ACTUALIDAD - HASHBuilder, otro paquete hash
CRIPTOGRAFÍA IMPRESENTABLE - Inseguridad por defecto: los certificados digitales
CRIPTO 101 - Shannon y la teoría de la codificación (II) -
CORRECCIÓN
CRIPTO 101 - Shannon y la teoría de la codificación (III)
LIBERTAD VIGILADA - España autoriza el uso de Rota "caso por caso"
Si
hay algo que estoy dándome cuenta al hacer el Boletín ENIGMA, es la falta de
uniformidad en su longitud, contenido y temática. Lo que resulta inevitable,
pues además de los típicos problemas de tiempo me veo limitado por el atractivo
informativo del mes, criptográficamente hablando. Es decir, un mes viene
prácticamente árido, y al siguiente las noticias se agolpan, y por supuesto se
esperan a última hora para llamar a la puerta. El boletín del mes pasado, sin ir
más lejos, no tenía ni editorial.
Este mes, la verdad, hemos tenido bastante movida. Y algunos asuntos ni
siquieran han podido entrar en el Boletín de este mes. Permítanme dar ejemplos.
¿Recuerdan aquella incursión del Ejército colombiano en busca de guerrilleros de
las FARC en Colombia, que casi provoca una guerra? Pues por lo visto, la
información capturada en los ordenadores de los guerrilleros ha revelado
información sobre futuros planes de las FARC, incluyendo los de encargar a la
ETA española atentar contra altos cargos colombianos. Dicha información fue
recuperada por la Interpol, y estaba originalmente cifrada. No se sabe nada
acerca de qué sistemas o programas de cifrado utilizaron, ni siquiera cómo
lograron recuperar la información (Bruce Schneier, en correo privado, me apunta
a la posibilidad de que adivinasen la contraseña). Resulta cuando menos extraño
que nadie haya aprovechado la ocasión para vendernos la moto de "los terroristas
usan criptografía, así que hay que regularla". Quizá interese más acallar el
hecho de que se puede acceder a la información y saltarse las protecciones.
Aquí vamos con un recordatorio de por qué necesitamos protegernos con
criptografía. Blackberry ofrece, entre otras cosas, un servicio de correo
electrónico protegido con un cifrado que utiliza nada menos que el estándar AES,
de 256 bits. El gobierno indio quiere husmear dichos mensajes, así que le exigió
a RIM, la empresa canadiense que comercializa Blackberry, que le diese una copia
de las claves usadas por todas las Blackberry que se usasen en India. El motivo
es el que se usa siempre en estos casos "por defecto" (y nunca mejor dicho):
luchar contra el terrorismo. RIM, como podemos imaginar, se negó, ya que una
cosa es una orden judicial para descifrar una comunicación en concreto, y otra
muy distintar darle a nadie opciones de caza libre. Afirmaron que la
infraestructura de su red no les permitía acceder a los mensajes descifrados ni
siquiera a ellos. Más aún, si debilitaban las claves para permitir al gobierno
indio leer las comunicaciones de las Blackberry, ¿qué impediría a otros países
hacer lo mismo cuando los datos viajan de las Blackberry indias a los servidores
centrales canadienses?
La respuesta del gobierno indio fue: muy bien, entonces vamos a prohibir las
Blackberry en nuestro país. El pasado 15 de Mayo, The Economic Times afirmó que
RIM cedería y permitiría al gobierno indio acceder a las claves de los usuarios
no comerciales. Hace cuatro días, el India Times afirmó que, por el contrario,
RIM se lo ha pensado mejor y ha decidido que no suelta las claves. Sin embargo,
¿cómo creerles ahora? ¿No es posible que hayan cedido ocultamente para salvar su
negocio en la India, y al mismo tiempo pretendan mantener la confianza de sus
clientes? Cuando el gobierno se mete a buscar nuestras claves, la única
conclusión segura es que no será para nada bueno. A no ser que nos queramos
creer que un gobierno jamás abusaría de su poder, faltaría más.
Y esto en lo que respecta a noticias serias. La tontería que dijo el fundador de
Atari recientemente sobre un chip llamado TPM que acabaría con la piratería de
una vez por todas, mejor que la lean ustedes directamente, que a mí me da la
risa tonta:
http://www.schneier.com/blog/archives/2008/05/tpm_to_end_pira.html
Suma y sigue, así que mejor nos centramos en el Boletín de este mes. Hoy
cerramos el -creo- interesante artículo sobre Claude Shannon y sus aplicaciones
de la Teoría de la Codificación a la criptografía. Incluyo también una
corrección al artículo del mes pasado, que quien tiene boca, se equivoca. Para
compensaros, os recuerdo que ya tenemos los dos artículos de Shannon en el
Taller de Criptografía, a disposición de todos vosotros. Tenemos también dos
retos muy distintos: por un lado, veremos cómo se descifra un mensaje recibido
por el Fermilab norteamericano, y por otro, asistiremos al "reto" de salvar
Bletchley Park, la "cámara negra" de Churchill. También tenemos el habitual
capítulo de "Libertad Vigilada" (insisto, estamos a punto de terminárnoslo, así
que a ver qué libro fusilamos, er, digo, comentamos ahora).
En el apartado de colaboraciones, tenemos un nuevo programa para calcular
funciones hash, cortesía de su autor LordHASH, que espero sea de vuestro
interés. Y, por último, un artículo sobre la criptografía de clave pública, su
uso diario, y la forma en que pequeños detalles pueden echar por tierra la
seguridad de un sistema complejo. Lo he redactado a partir del artículo de una
nueva web sobre seguridad informática y criptografía que aprovecho para
presentaros y recomendaros. Se llama "Security By Default"
http://www.securitybydefault.com/,
y acaba de ser
inaugurado por tres lumbreras del ramo: Alejandro Ramos, José A. Guasch y Yago
Jesús (quien creo que se dejó los apellidos en casa :-). Según la presentación
hecha por este último, parece que el trío son de lo más rompedor desde Rivest,
Shamir y Adleman, o no tienen abuela, o ambas cosas. Apuntad su dirección en
vuestros marcadores, porque vale la pena. Mi única queja es que hayan convocado
a unirse al equipo Kriptópolis en el reto SHA-1, en lugar de fichar por el
Taller. Vale, sí, envidia cochina. Y ahora, a seguir leyendo se ha dicho.
Saludos.
TEMAS DE ACTUALIDAD - Reto criptográfico en Fermilab
El
Laboratorio Nacional del Acelerador de Fermi (Fermilab para los amigos) es uno
de los centros de investigación más excepcionales del mundo. Presume de tener el
acelerador de partículas más potente del mundo (con permiso del CERN europeo), y
también puede estar orgulloso de su plantel de científicos. Resulta, por tanto
curioso, que los descubridores del quark top sean incapaces de descifrar un
criptograma.
Efectivamente, Fermilab no tiene nada que ver con la creación o ruptura de
códigos. Pero el año pasado, su oficina de relaciones públicas recibió una carta
en clave. Incapaces de descifrarla, decidieron publicar el caso en la revista de
Fermilab, "Symmetry Breaking". Se trata de un criptograma en tres partes. La
primera y la tercera son una ristra de barras verticales espaciadas. Vean por
ejemplo, el comienzo de la primera parte:
|||
|| ||| || ||| ||| ||| ...
El lector interesado puede ver el mensaje completo aquí:
http://www.symmetrymagazine.org/breaking/wp-content/uploads/2008/05/fnalcodeletter.jpg La noticia llegó a diversos foros como Slashdot, y pronto aparecieron soluciones. Vamos a ver cómo lo resolvió Geoff, un estudiante del Real Colegio Militar de Canadá. Para él, y para nosotros, es obvio que el mensaje es una sucesión de tres elementos: |, || y ||| (| no aparece en la sección que he reproducido arriba, pero sí más adelante). Haciendo la transformación |=1, ||=2, |||=0 tendríamos el siguiente mensaje:
020 200 001 112 102 000 201 ...
¿Por qué agrupar los números en ternas? Pues porque así tenemos un total de 27
posibles ternas (desde 000 hasta 222), lo que nos permitiría codificar las
letras del alfabeto (incluyendo el espacio), algo muy conveniente. Por supuesto,
podemos hacer otras transformaciones (por ejemplo, |=1, ||=2, |||=0). Pero Geoff
escogió esta posibilidad (tras probarlas todas, imagino) porque así el mensaje
tiene sentido. Haciendo la siguiente correspondencia:
000=Espacio, 001=A, 002=B, 010=C, 011=D, 012=E,
020=F, ...
el mensaje de la primera parte del criptograma adopta una forma legible en
inglés: "FRANK SHOEMAKER WOULD CALL THIS NOISE" (Frank Shoemaker llamaría a esto
ruido). Por lo visto un tal Frank Shoemaker trabajó en los anillos del
acelerador Fermilab. Según un colega, era un tipo genial y muy divertido.
Construyó diversas cámaras de detección de partículas, en las una detección de
partícula puede deberse a una coincidencia aleatoria, y quizá de ahí venga la
referencia al "ruido" Ahora está retirado, y por lo visto no tiene nada que ver
con el criptograma. Claro que eso es lo que él dice, y como somos tan
desconfiados ¿por qué deberíamos creerle?
La tercera parte es parecida, pero parece diferente en forma. He aquí algunos
caracteres:
| | |
|| | || | | || ...
La hipótesis de Geoff es que sigue siendo un código ternario. En este caso, |=1,
| |=2, | | |=0, y || actúa como elemento separador. De esta forma obtendríamos:
012
111 121 110 120 ...
Sometido a una transformación igual a la que hemos visto antes, obtendríamos el
siguiente resultado: "EMPLOYEE NUMBER BASSE SIXTEEN" (Número de Empleado Basse
Dieciséis). No parece tener mucho sentido. Pero quizá ayude echarle un vistazo a
la segunda parte del criptograma. Se trata de lo que aparentemente es un sistema
de sustitución monoalfabética simple. Algunas letras y números se transforman en
símbolos. Justo debajo aparecen tres símbolos: una letra s, un triángulo y lo
que parece ser una letra griega lambda. Según la sustitución monoalfabética, el
triángulo es la letra F, la letra lambda es la letra C ... y la letra s no
aparece. Podríamos, por tanto, "traducir" la segunda parte del criptograma como
"sFC"
Aquí entramos en el terreno de las conjeturas. FC, en notación hexadecimal (es
decir, en base 16) es igual al número decimal 262. Aplicando la "recomendación"
de la tercera parte del criptograma, obtenemos el número de empleado S-252.
¿Tiene este sentido este galimatías? Sorprendentemente, parece que sí. Desde
1967, todos los empleados de Fermilab tienen un número de identificación. Así
que el identificador S-00252 nos lleva a ... un tal Pierre Piroue. Él ya ha sido
contactado, y niega ser el autor del criptograma. Pero tanto Piroue como
Shoemaker se conocían, pues ambos eran miembros del departamento de Física de
Princeton.
También hay quien se ha fijado en la palabra "Basse" en lugar de "Base". Parece
un sencillo error, aunque podría argumentarse que la "s" extra es precisamente
"lo que Frank Shoemaker llamaría ruido". Sería, por tanto, una forma sutil de
decirnos "enhorabuena, habéis descifrado bien la primera parte". O podría ser
algo más profundo. Basse, en francés, significa "baja". Hay quien dice que el
tercer criptograma lo que dice es "Número de empleada bajo 16". ¿Hay alguna
trabajadora francesa de Fermilab con un número de identificación menor que 16?
No lo sé; pero ¿es casualidad que Pierre Piroue sea un nombre francés? Puestos a
rizar el rizo, "Basse" es el nombre en francés de un instrumento musical, y
resulta que Piroue !es también profesor de música!
Puestos a echarle imaginación, hay quien apunta a que Shoemaker trabajaba en un
edificio de Fermilab cuyo estilo arquitectónico recibe el nombre de "Basse
oeuvre". Vale, a lo mejor sí sea casualidad, y "sFC" significa "signed FC", es
decir, "Firmado: FC" Puede que incluso signifique "Shoemaker, F.C." Podríamos
estar dándole vueltas durante mucho tiempo ... y probablemente lo haremos.
Porque, como veis, eso de tomar lápiz y papel, menear un poco las neuronas y
obtener la solución única y correcta es la excepción más que la regla. Para
llegar a la solución de un criptograma hay mil y un caminos que hay que
explorar, y no siempre se atina a la primera. Ni siquiera a la décima.
TEMAS DE ACTUALIDAD - Bletchley Park te necesita
Hemos hablado largo y tendido en este boletín de Bletchley Park, el centro
británico de desciframiento durante la Segunda Guerra Mundial. Probablemente sea
la "cámara negra" más famosa de la historia. Hace unos años, tuve la oportunidad
de caminar por entre sus calles, ya que "BP" sigue abierto, aunque ya no como
centro de criptoanálisis sino como museo. En el Boletín ENIGMA 7 incluí una
breve reseña de mi visita, en un artículo llamado "De vuelta a Bletchley Park,
primera parte".
En realidad, nunca hubo una segunda parte. Y la verdad es que lo merece. En
estos años ha habido diversas mejoras y novedades del museo BP, incluyendo un
museo de computación y la reconstrucción de Colossus, el primer ordenador del
mundo ("Colossus, el proyecto redivivo", Boletín ENIGMA nº 56). En sus
instalaciones se ha inaugurado un restaurante, la tienda de recuerdos vende
libros y folletos muy interesantes, se hacen conferencias e incluso puede usted
celebrar su boda allí. Según todos los indicios, BP nunca ha tenido mejor
aspecto desde el final de la Gran Guerra.
Y sin embargo, no es así. Bletchley Park se muere. El motivo es el mismo de
siempre: el dinero, el maldito dinero. Los ingresos (en forma de entradas,
principalmente) no son suficientes para mantener el museo funcionando. Bueno,
quizá sí para eso, pero para poco más. Algunos de los famosos barracones ("Huts")
donde los criptoanalistas aliados derrotaron a la Enigma permanecen en un estado
próximo a la ruina, y el tejado de la mansión necesita reparaciones al toque de
ya. En realidad, si consideramos el reto a que ha tenido que enfrentarse
Bletchley, ya es difícil que sigan abiertos. Se salvaron por los pelos de la
especulación urbanística, carecen de subvenciones estatales y casi de
patrocinadores privados, y cuando pidieron ayuda a la fundación Bill y Melinda
Gates, se les respondió que no podía ser ... porque no se trata de un proyecto
basado en Internet. Casi nada. Allí se inventó el ordenador, se pusieron los
cimientos de la actual GCHQ (que, ahora sabemos, inventó la criptografía de
clave pública antes que los norteamericanos), pero no parece ser suficiente para
entrar en el pastel de 40.000 millones de dólares del tito Bill. Cosas veredes.
El problema recibió atención informativa a mediados de Mayo en ZDNet, y ayer
mismo nos lo recordó una nota de prensa del Bletchley Park Trust (http://www.bletchleypark.org.uk/news/docview.rhtm/516816).
Aunque este humilde Boletín no tiene tanta audiencia como el blog de Bruce
Schneier (todavía), no por ello vamos a inhibirnos y mirar hacia otro lado.
!Hemos de salvar Bletchley Park! Si las negociaciones que están teniendo con la
Lotería Nacional inglesa dan fruto, obtendrán una buena inyección económica,
pero no pongamos nuestras esperanzas en ello. Así que os sugiero dos formas de
ayudarles.
Una de ellas es mandándoles dinero. Lo curioso es que en su web ni siquiera nos
dicen cómo podemos enviarles pasta: ni paypal, ni tarjetas, ni nada por el
estilo. Así que ¿por qué no meterles unas libras en el bolsillo pasando por su
tienda virtual? Tienen libros estupendos (algunos de los cuales hemos revisado
aquí), tazas, polos, y hasta una Enigma electrónica. Puede ser una buena
oportunidad de comprar un regalo especial a alguien (y me refiero a algo que no
encontrarás en Harrods ni en el Duty Free del aeropuerto).
Y si no, ¿por qué no plantarse allí? Está a tiro de piedra de Londres, y para
los aficionados a la cripto es un destino que no podéis perderos. Total, ya
tenemos muy visto el British Museum, y eso del cambio de la guardia tampoco es
para tanto. Así que la próxima vez que os plantéis en Inglaterra -que para eso
están los vuelos baratos-, no dejéis pasar la oportunidad. Yo, si todo va bien,
espero volver en Septiembre de este año. Tengo allí una reunión científica (nada
relacionado con cripto), y me agradó ver que ponían a Bletchley Park como uno de
los destinos recomendados.
Por supuesto, espero que los que os paséis por allí tengáis el detalle de
compartirlo con nosotros. Enviadme un e-mail con vuestra experiencia, y también
fotos. Las mejores irán a nuestro Museo para solaz y deleite de todos. Corred la
voz, y a ver hasta dónde podemos llegar. Tengo la impresión de que BP
sobrevivirá una vez más. Pero necesitará apoyo. Ya está corriendo la voz en los
foros, y esperemos tener buenas noticias que contaros en el futuro. De lo
contrario, Colossus volverá a desaparecer y una parte de nuestra criptohistoria
desaparecerá de forma irreversible.
TEMAS DE ACTUALIDAD - HASHBuilder, otro paquete hash
Si
en el boletín 59 Antonio Villena nos regaló un paquete para calcular función
hash MD5, hoy es el turno de otro amigo del Taller: LordHASH. Con ese apodo, no
podemos menos que esperarnos una aplicación de funciones resumen (hash). Y así
es. HASHBuider, su última creación, calcula códigos hash tanto para ficheros
como para texto llano. El programa, en Java, está disponible en la web del
Taller de Criptografía:
http://www.cripto.es/herramientas/HASHBuilder.jar
y listo para ser usado. En un ejercicio de coherencia, se ha aplicado su propia
medicina y nos incluye los resultados de aplicar funciones hash a su propio
fichero (lo que viene muy bien como comprobación de integridad):
MD2:
D01F88142A80D0DBBB1A3DBE229286D7
MD5:
C7EC1484F76AAD3A66034C87F3DE210B
SHA-1:
9795B2B4FA822F7441E1FD78852D3A5CC040C908
El autor os espera en su web
http://lordhash.blogspot.com/. Esperemos que siga en la misma línea, y
que nos asombre con lo que venga en el futuro. De alguien cuyo apodo parece
robado al primo de Darth Vader, nos esperamos lo mejor.
CRIPTOGRAFÍA IMPRESENTABLE - Inseguridad por defecto: los certificados digitales
Hace mucho, pero que mucho tiempo, cuando Internet llegaba a todos los sectores
de la población, se planteó el problema de dotar de seguridad las transacciones
electrónicas. Apareció entonces el protocolo SSL que utilizan los navegadores.
De hecho, uno de mis primeros escritos sobre criptografía trataba el tema de los
servidores seguros. Todavía podéis acceder a ellos (www.cripto.es/informes.htm,
Informes 1, 4 y 5). Son "los viejos tiempos", nada menos que 1997.
El problema a resolver es el siguiente. Dos partes, el usuario (U) y el banco
(B) tienen que comunicarse de forma segura. Vale, marchando una de cifrado
simétrico. Pero además han de asegurarse que nadie usa la clave común. Entra
entonces la criptografía simétrica. El procedimiento es prácticamente idéntico
al de PGP (programa para correo electrónico), y viene a consistir en los
siguientes pasos:
1) El navegador de U solicita al servidor de B una clave
2) B envía un certificado electrónico (es decir, la clave pública del banco
firmada por un "tercero de confianza" llamado Autoridad de Certificación o AC)
3) El navegador de U comprueba el certificado de B. Para ello, rebusca en su
interior, saca la clave pública de la AC correspondiente y la usa para comprobar
que la firma que ha hecho la AC en el certificado de B es correcta
4) Una vez U ha quedado satisfecho con la comprobación de identidad de B, genera
una "clave de sesión" simétrica y la cifra con la clave pública de B.
5) B, usando su clave privada, descifra el mensaje de U y recupera la clave de
sesión. Ahora tanto U como B tienen la misma clave de sesión, que utilizarán
para comunicarse de forma segura.
6) Una vez finalizada la transacción, B y U borran la clave de sesión, se dan
las buenas tardes y a otra cosa, mariposa.
Este esquema se ha venido usando desde hace más de una década. Ya en 1999 este
que firma lo utilizó para pagar sus impuestos ante la Agencia Tributaria ("Pague
sus impuestos ... digitalmente", Informe nº 10, http://cripto.es/informes/info010.htm).
Por supuesto, no es un sistema impenetrable, sino tan sólo lo mejor que tenemos.
Uno de los problemas subyacentes consiste en que la autenticación ha sido
incompleta. Es decir, U se queda tranquilo porque ha comprobado que B es B, pero
¿cómo sabe B que U es realmente U? ¿Y si es otro usuario el que está intentando
acceder a la cuenta de U? Para ello, los bancos y comercios electrónicos hacen
introducir al usuario información adicional: números de tarjeta, de DNI, claves
de acceso, tarjetas de coordenadas, etc. Claro que un PIN de ocho cifras no es
lo mismo que una clave simétrica de 128 bits, pero lo que hay es lo que hay.
Una segunda solución, impulsada por el gobierno, consiste en dotar a todos los
ciudadanos de un conjunto de claves criptográficas, insertas en una tarjeta, que
les permite demostrar quiénes son en Internet: son los DNI electrónicos. El
gobierno está deseando que la gente lo use con profusión en Internet, ya que eso
permitiría, según ellos, que el comercio electrónico despegase, la gente
respirase tranquila frente a fraudes, etc, etc (también podrían rastrear
eficazmente los movimientos de todo el mundo si consiguen que vayamos por la Red
con el DNI electrónico en la boca, pero obviemos esa nimiedad). Sin embargo,
estamos hablando de millones de DNIs, por no hablar de convencer a todo el mundo
para que se compren lectores de tarjetas, así que la solución SSL sigue siendo
muy utilizada.
Una forma relativamente sencilla de autenticar al usuario es hacer lo mismo que
en su momento hizo el banco con su clave pública. Para ello, U crea un par de
claves (pública y privada), envía la clave privada a una AC, ésta la firma y se
la devuelve al usuario. Esto sería el "certificado digital" para el usuario.
Ahora el usuario tiene una clave pública firmada por una AC de confianza, igual
que un documento autenticado ante notario. A partir de aquí, si el banco o
cualquier entidad electrónica desea comprobar que la clave que le ha llegado es
la del usuario U, actuaría de la misma forma que hemos descrito anteriormente.
Por supuesto, esto significa que el usuario ha de custodiar muy bien su clave
privada, ya que es la "clave" para hacer todo tipo de compras o trámites
electrónicos. Si alguien se la roba, sería lo mismo que si le robase el DNI;
peor, en realidad, puesto que el DNI tiene foro y la clave privada, no.
El problema es que, en el mundo real, y por mucho protocolo criptográfico que
metamos por medio, tales transacciones se llevarían a cabo en ordenadores
reales, esto es, lugares electrónicos infestados de virus, troyanos,
vulnerabilidades, agujeros de seguridad y todo tipo de entes hostiles. Los
ingenieros electrónico trabajan duro para minimizar estos problemas (sí, incluso
los de Windows), pero dada la complejidad del software actual y el ingenio de
los hackers (bienintencionados o no) convierten el proceso en una interminable
batalla de ingenio.
Veamos, como ejemplo, la estocada que nos plantea Yago Jesús, de
www.securitybydefault.com. En el
segundo artículo de esta interesante web, se dedica a darle vueltas al modo en
que Windows almacena la clave privada del usuario. Vamos a hacerlo paso a paso.
Como autoridad de certificación, escogeremos el de la Fábrica Nacional de Moneda
y Timbre (FNMT), a través de su organismo Ceres. Abrimos el navegador, tecleamos
http://www.cert.fnmt.es/index.php?cha=cit&sec=obtain_cert&lang=es, y al
turrón. El primer paso, por supuesto, es solicitar el certificado, el paso 1.
Para ello, introducimos nuestro número de DNI, escogemos la longitud de la clave
asimétrica de 1024 bits (podemos hacernos una de 2048 bits, pero nos advierten
que no todos los servicios telemáticos la admiten), y pulsamos "Enviar
petición". El navegador genera el par de claves, envía la clave pública a Ceres,
y se acabó el primer paso.
En un segundo paso, tenemos que acreditar que nosotros somos nosotros. ¿Cómo?
Pues con tecnología antigua: nos plantamos en una oficina del FNMT con el DNI en
la mano. Finalmente, una vez los hayamos dejado satisfechos, ellos crearán el
certificado (vamos, que firmarán nuestra clave pública), y no tendremos más que
volver a la web de la FNMT para descargárnoslo. Ahora tenemos nuestra clave
pública certificada por la FNMT.
Puesto que la clave pública es, por definición, pública, no hay problema en
diseminarla a los cuatro vientos, si así lo deseamos. Pero con la clave privada
... ah, amigo, esa es otra cuestión. Debemos protegerla con uñas y dientes. Los
usuarios de PGP saben que sus claves privadas están protegidas con una frase de
contraseña, lo que puede plantear problemas si tenemos un keylogger metido en el
ordenador. Lo que hace el navegador es guardar la clave privada internamente.
Las claves está protegidas mediante una contraseña que está derivada a partir de
la contraseña que introducimos al iniciar la sesión en Windows. Sí, ya sé,
también existen Linux, Mac y tu sistema operativo favorito, pero vamos a seguir
con Windows. Porque el problema está precisamente en Windows.
Verán ustedes. Por lo visto, Windows almacena los certificados mediante un
sistema que tiene tres niveles de seguridad: bajo, medio y alto. Los rasgos
fundamentales de dichos niveles son los siguientes:
NIVEL BAJO. La clave privada se usará en cualquier momento en el que cualquier
función de cualquier programa así lo solicite (una especie de "pase y sírvase").
NIVEL MEDIO. Antes de usar la clave, aparecerá una pantalla "pup-up" que informa
del hecho (el típico "vamos a usar la clave, ¿desea continuar' si/no/cancelar")
NIVEL ALTO. Para usar la clave, es necesario introducir una contraseña.
Ahora imaginen que son ustedes los técnicos de Ceres y han de determinar el
nivel de seguridad con el que se guardará la clave privada del usuario. ¿Qué
decisión tomarían? Bien, todos los que hayan pensado "nivel bajo" que levanten
la mano. Quedan expulsados del Boletín ENIGMA ignominiosa y fulminantemente. Los
demás, espero que os hayáis ido al nivel alto, que sería lo lógico para algo tan
sensible como una clave privada que se va a usar en transacciones bancarias,
pagos de impuestos y cosas así. Entre medias de los dos grupos, situaremos a la
gente de Ceres.
En efecto, lo que Yago descubrió (con la boca abierta, imagino) es que, cuando
su copia de Internet Explorer pedía el certificado digital, apareció un pop-up
con el aviso siguiente:
"Creando una nueva clave de intercambio RSA. Una aplicación está creando un
elemento Protegido. El nivel de seguridad es Medio"
¿Como? ¿Nivel de seguridad medio? Pues sí. Por supuesto, al lado aparecía el
típico botón "ajuste el nivel de seguridad", por si queremos subirlo o bajarlo.
Pero ¿cuántos usuarios no lectores de boletines como éste se molestarán en
hacerlo? El sistema ha escogido nivel medio, bueno, sabrá lo que se hace, pulso
Enter y adelante.
Peor todavía: si, durante la generación del par de claves, deseamos hacer una
copia de seguridad, tanto el certificado (clave pública formada por la AC) como
LA CLAVE PRIVADA son marcadas como exportables. De no ser así, claro, no
podríamos copiarlas. Pero imaginen un programa spyware que quisiera extraer la
copia privada. Como está marcada como exportable, podría acceder a ella. Con un
nivel de seguridad medio, aparecería la ventana pop-up, sí, pero de nuevo nos
encontraremos con usuario que solamente quiere que las cosas funcionen. ¿Que
haría frente a un pop-up con algo escrito como "realizando copia de seguridad
compatible con estándar HRLTT12, pulse continuar"? Eso mismo.
No contento con la "prueba de concepto", Yago ha escrito un programa (CertDump)
que actúa como lo haría un atacante exterior. Dicho programa permite exportar
las claves pública y privada sin que el usuario intervenga para nada. Respecto
al pop-up, CertDump lo "puentea" y envía una señal Enter por su cuenta.
Yago propone, para protegernos, el siguiente proceso. Primero, pedir los
certificados tal como lo hemos descrito antes. Acto seguido, exporten el
certificado y la clave privada (a un CD-ROM o un pendrive) y borren el
certificado del navegador. Después, vuelvan a re-importarlo (a partir de la
copia exportada), teniendo mucho cuidado de a) no marcar ya la opción de "clave
exportable" y b) escoger el nivel de seguridad máximo. Y es que, como de
costumbre, las cosas pequeñas son las que nos llevan a la ruina. Sin un reino se
perdió por un caballo, una identidad puede perderse por un pop-up; o por una
elección de nivel de seguridad poco acertada.
CRIPTO 101 - Shannon y la teoría de la codificación (II) - CORRECCIÓN
Por un error humano (estaba ya de números hasta la coronilla), la última columna
de una de las tablas estaba equivocada. Decía:
a b
P(ai) P(bj) P(ai,bj) P(bj|ai)
0 0 0.75 0.75 0.5625
0.75
0 1 0.75 0.25 0.1875
0.25
1 0 0.25 0.75 0.1875
0.25
1 1 0.25 0.25 0.0625
0.75
cuando debía ser:
a b P(ai) P(bj) P(ai,bj)
P(bj|ai)
0 0 0.75 0.75 0.5625
0.75
0 1 0.75 0.25 0.1875
0.75
1 0 0.25 0.75 0.1875
0.25
1 1 0.25 0.25 0.0625
0.25
Y encima lo arreglé diciendo que las columnas 4 y 6 eran idénticas. Lo más
curioso es que ni uno de los lectores me apercibió sobre el fallo. Una de dos: o
no me lee ni mi madre, o tenéis tanta fé en mí que os creéis todo lo que digo
sin pensar. Por supuesto, escojo la opción dos.
CRIPTO 101 - Shannon y la teoría de la codificación (III)
El
uso de la probabilidad condicional nos da una forma de establecer hasta qué
punto sabemos algo de una variable cuando ésta está relacionada con otra
variable. Como vimos en la parte II de esta serie, al aplicarlo a las variables
"texto llano" y "texto cifrado", obteníamos un curioso resultado: para que un
sistema de cifra nos proporcione un secreto perfecto, el número de claves ha de
ser tan alto como el de posibles mensajes. Por eso las cifras simétricas se
consideran tanto más seguras cuantos más bits tengan.
Como se vio anteriormente, podemos usar la entropía como medida de la
incertidumbre, esto es, de la información que tenemos sobre el sistema. Bien,
sigamos usándola para cuantificar. Si hacemos la suma
H(A)=-Suma [P(ai)*Log(P(ai))]
tenemos la entropía correspondiente a la variable A. También se llama "entropía
a priori", y nos cuantifica la incertidumbre que tenemos acerca del valor de ai.
También podríamos hacer lo mismo con la variable B y obtener su entropía H(B).
Si tenemos dos variables (a,b), podemos extender el concepto y hablar de la
entropía de las dos variables:
H(A,B)=-Suma [P(ai,bj)*Log(P(ai,bj))]
donde aquí p(ai,bj) es la probabilidad de que A tome el valor ai y B tome el
valor bj. Esta entropía nos indica la incertidumbre que tenemos tanto en A como
en B, suponiendo que ambas variables sean independientes. Puede demostrarse que
la entropía H(A,B) cumple esta
relación:
H(A,B)<=H(A)+H(B)
es decir, la entropía de dos variables es menor o igual que la suma de ambas
entropías por separado. La igualdad sólo se da cuando X,Y son variables
independientes.
¿Pero qué pasa si ai, bj guardan alguna relación? Pues en ese caso, nos interesa
obtener la "entropía a posteriori", en la que la probabilidad de obtener ai
depende de lo que valga la otra variable bj. Recordemos el concepto de
"probabilidad condicional" P(ai|bj), que no es sino la probabilidad de que
obtengamos ai cuando ha salido bj. Usando la probabilidad condicional P(ai|bj)
obtenemos la entropía a posteriori, o
ENTROPÍA CONDICIONAL:
H(A|B)=-Suma [P(ai,bj)*Log(P(ai|bj))]
=-Suma [P(bj)*P(ai|bj)*Log(P(ai|bj))]
[Nota del Taller de Criptografía: en la versión texto, el signo = de la segunda línea no aparecía]
donde sumamos para todos los valores de i,j. H(A|B) nos viene a dar idea de cuán
incierta es la información que tenemos sobre A cuando conocemos B. En el caso
que hemos puesto como ejemplo, A,B son respectivamente la entrada y la salida de
información por un canal de comunicaciones. Esto tiene, evidentemente, mucha
importancia para los expertos en teleco, donde han de bregar con problemas de
ancho de banda, ruido, corrección de errores, etc. Pero por apasionante que
pudiera ser el tema (y que nos daría para muchos boletines), volvamos a nuestro
interés criptográfico. Podemos interpretar A como el texto llano, B como el
texto cifrado y el "canal" como el sistema de cifra. Es decir, ai serían los
posibles textos llanos y bj los textos cifrados.
Si el sistema de cifrado fuese perfecto, no habría forma de "ordeñar"
información del mensaje cifrado. No es que no podamos descifrarlo, es que ni
siquiera podríamos determinar si algunos mensajes en llano son más probables que
otros. Conocer el texto cifrado hasta el último bit no nos daría la menor pista
sobre el texto llano.
Pero si el sistema es imperfecto, habrá alguna información oculta en el texto
cifrado, como que (por ejemplo) los mensajes en llano que comiencen por vocal
son más probables que correspondan con el texto cifrado. Que quede bien claro
que aquí no estamos hablando de obtener el texto llano, ya que la cifra no suele
ser tan mala, sino de obtener cualquier pista sobre lo que el mensaje puede o no
ser. Si podemos concluir que el mensaje no puede tener un número impar de
consonantes, eso ya nos sirve. Cualquier bit de información vale.
Matemáticamente, usamos la entropía condicional para cuantificar esta
información. Recordemos una vez más (y perdonen si sueno demasiado repetido) que
la entropía condicional nos mide el conocimiento que tenemos de A cuando
conocemos B, esto es, hasta qué punto ver los mensajes cifrados nos da alguna
pista acerca de los mensajes llanos. A esta entropía condicional Shannon le dio
el descriptivo nombre de EQUIVOCACIÓN. Recordemos la expresión:
H(A,B)<=H(A)+H(B)
Puede demostrarse que la entropía H(A,B) también puede ponerse de la siguiente
forma:
H(A,B)=H(B)+H(A|B)
Lo que significa que podemos obtener esto:
H(A)>=H(A|B)
Es decir, la incertidumbre que tenemos de conocer A disminuirá si conocemos B, y
dicho conocimiento pasa de H(A) (la entropía de los mensajes en llano) a H(A|B)
(la entropía de los mensajes en llano condicionado por lo que conocemos de los
mensajes cifrados B). O dicho en román paladino: conocer textos cifrados B nos
aumenta la información que tenemos de los mensajes en llano A. Esto no sucedería
si el cifrado fuese perfecto. Pero si no lo es, si el mensaje en llano está
condicionado por el mensaje cifrado, la equivocación H(A|B) nos cuantifica
cuánto hemos ganado en información.
La idea general es que un símbolo ai de un mensaje en texto llano requiere en
promedio H(A) bits para definirlo. Si supiésemos qué símbolo cifrado bj
corresponde a dicho símbolo ai, solamente necesitaríamos H(A|B) bits para
definirlo. Así que, como media, la observación de un símbolo de salida
proporciona H(A)-H(A|B) bits de información. A esta información se le llama
INFORMACIÓN MUTUA del sistema:
I(A,B)=H(A)-H(A|B)
Por supuesto, si el sistema es impenetrable no ganamos nada con conocer B, por
lo que H(A|B)=H(A) y la información mutua es nula. Si el sistema es imperfecto,
H(A|B)<H(A) y, por tanto, I(A,B)>0. Algunos autores, como Manuel Lucena, usan
una definición opuesta a la nuestra:
I(A,B)=H(B)-H(B|A)
pero ambas son válidas, ya que la información mutua es simétrica, esto es, I(A,b)=I(B,A).
En cualquier caso, una información cero indica que todas las "traducciones"
posibles a texto llano sin igualmente probables, el criptoanalista no gana
absolutamente nada si conoce un mensaje cifrado, o un millón, y el cifrador de
mensajes puede dormir tranquilo.
Muy bien, vayamos un paso más allá. Por lo que hemos visto hasta ahora, cuantos
más mensajes cifrados obtengamos, más nos acercaremos al objetivo de "reventar"
el mensaje y obtener el texto llano. La pregunta ahora es ¿llegaremos el algún
momento al punto en que podemos descifrar el mensaje? Y si es así, ¿cuántos
mensajes cifrados necesitaremos husmear? Para eso tendremos que definir más
cantidades. Pero si hemos sobrevivido a la entropía condicionada, la
equivocación y todo lo demás, esto será pan comido.
En primer lugar, definamos la entropía de un sistema de cifra. Es,
sencillamente, una medida binaria del tamaño del "espacio de claves". Si un
sistema de cifra tiene K posibles claves, su entropía es el logaritmo en base 2
del número de claves:
H(K)=Log2(K)
lo que nos da un número de posibles claves igual a 2^H(K)
Por ejemplo, el sistema de cifra de César tiene 27 posibles claves, de modo que
si entropía será de 4.09. Esto significa que hay 2^4.09 posibles claves. Muchas
veces, la entropía es igual al número de bits que tienen las claves, pero eso no
es siempre así. Por ejemplo, el sistema de cifra DES usa claves de 64 bits, pero
ocho de dichos bits están determinados por los otros 56 (son los llamados bits
de paridad), de forma que el "espacio de claves" es 2^56 y la entropía del
sistema es de 56 bits. Cuanto mayor la entropía, tanto más difícil es reventar
el sistema.
En un sistema perfecto necesitaríamos probar las 2^H(K) posibles claves. Pero si
el texto llano es un mensaje en español, dicho texto será redundante. ¿Recuerdan
eso de la redundancia? Pues podemos aprovecharlo, tanto si el idioma del texto
llano es español, inglés, ASCII o lo que sea. Podemos, de hecho definir la
REDUNDANCIA D como D=R-r, donde R es el número de bits máximo por letra y r es
el número real de bits de información que no da un carácter. Como vimos en el
ejemplo de la parte II de esta serie, el idioma inglés usa 26 letras, lo que nos
da R=Log2(26)=4.7 bits por letra de promedio; la cantidad de información real de
una letra en el lenguaje inglés es, según diversas estimaciones, de entre 1 y
1.5 bits de información. Tomando un valor razonable de r=1.3, esto nos da una
redundancia D=3.4. Es decir, de cada 100 bits de información en un texto inglés,
el 72% es redundante.
Asociado al concepto de redundancia está el de DISTANCIA DE UNICIDAD (U). Este
bicho es la cantidad de texto cifrado tal que la suma de la entropía real del
texto llano, más la entropía de la clave de cifrado, es igual al número de bits
de texto cifrado usado. Vale, no os asustéis. Lo diré de otro modo. Si la
entropía del criptosistema es H(K) y la redundancia del lenguaje es D, la
distancia de unicidad es:
U=H(K)/D
En realidad, sólo sería válido para lo que Shannon denomina "cifra aleatoria",
pero obviaremos ese pequeño detalle ya que incluso para cifras no aleatorias la
ecuación anterior nos da una cota inferior. En general, cuanto más texto cifrado
tenemos, tanto más nos acercamos al objetivo de descifrar del mensaje. El
problema es que, para un mensaje corto, hay muchas posibles soluciones. Si yo
las pruebo todas, usando todas las claves posibles, ¿cómo sé cuál es el
descifrado correcto? Bien, se puede demostrar que cuando el mensaje es de
longitud menor que la distancia de unicidad, hay múltiples soluciones posibles.
Por el contrario, si tenemos un cantidad de texto cifrado igual o superior a la
distancia de unicidad, tenemos la garantía de un descifrado único.
Eso no significa, ojo, que la cifra es atacable por métodos criptoanalíticos;
pero si lo es, necesitaremos al menos una cantidad de texto cifrado igual a U.
Es decir, U es un límite teórico para un criptoanalista al que supondremos con
una provisión prácticamente ilimitada de tiempo, ordenadores y paciencia. Cuanto
mayor sea U, mejor el sistema de cifra. En el caso límite, un sistema con
redundancia D cero tendría una distancia de unicidad infinita; es decir, un
atacante no podría sacar nada en claro de un mensaje cifrado, sea cual fuese su
longitud.
Es curioso considerar que incluso un sistema de cifrado imperfecto, con claves
cortas y al que no nos dignaríamos de saludar por la calle puede resultar
indescifrable si la redundancia D es cero. Volvamos a nuestra clave de César. Si
yo escribo un texto en español y lo cifro, no será difícil para un
criptoanalista tomar todas las posibles claves y escoger de entre todos los
textos descifrados el correcto. Pero supongamos que yo tomo un texto totalmente
aleatorio, digamos AODTWNSSXYZ, y lo cifro con una cifra de César. Eso no es
español, ni inglés, ni klingon, sino un batiburrillo totalmente aleatorio. La
redundancia del "idioma" usado por el mensaje es cero, así que la distancia de
unicidad es infinita. El criptoanalista podrá tomar mi mensaje, probar todos los
descifrados posibles, y aún así no tendrá idee de cuál es el texto correcto.
En general, comprimir el mensaje reduce ya redundancia. Por eso es mejor usar
compresión (zip, rar, la que más nos guste) antes de cifrar el mensaje: no
solamente el tamaño del texto será menor, sino que le damos menos información al
enemigo. Y también hay otra cosa que podemos hacer: usar un sistema de cifra en
el que la entropía sea igual al tamaño en bits de la clave. Si un criptosistema
tiene claves de 1000 bits de longitud, pero su entropía es de tan sólo 100, es
como si las otras 900 claves estuviesen de adorno. Demasiados sistemas de cifra
se anuncian como estupendos y maravillosos porque tienen claves de gran
longitud. Pero lo importante no es el número de claves teóricas, sino la
longitud del "espacio de claves" real, es decir, la entropía del criptosistema.
Veamos algunos ejemplos de distancias de unicidad. C.A. Deavours publicó algunos
en Cryptologia (Enero 1977), suponiendo un idioma inglés con una redundancia
D=1.11. Para una cifra Vigenère con una clave de longitud P, la distancia de
unicidad es de 1.27P. Es decir, usando como clave "boletinenigma", bastan
1.27*5=17 letras para, al menos en teoría, montar un ataque criptoanalítico con
éxito ... a no ser que la usemos para transmitir mensajes de longitud muy
pequeña.
Si en lugar de Vigenère (que no es más que una sucesión de P cifras de César)
usásemos una sustitución polialfabética con N alfabetos diferentes usados en
sucesión, obtendríamos U=23.97N+1.27P. Es decir, usar 10 alfabetos y la misma
clave de antes requeriría interceptar al menos 23.97*10+1.27*5=246 caracteres
cifrados. La clave es de igual longitud que antes, pero el sistema es mucho más
difícil de resolver.
No quiero aburrirles, pero ahí van otros ejemplos. La cifra Playfair (de la que
hablaremos un día de estos) tiene una distancia de unicidad de U=22.69. Una
sustitución digráfica aleatoria (es decir, cifrar letras en grupos de dos) tiene
U=1461. Una cifra de sustitución homofónica con N posibles signos cifrados por
letra nos da una distancia de unicidad de 33.14N.
Como el lector ha podido ver a lo largo de esta serie de artículos, las
contribuciones de Claude Shannon a la criptología matemática son profundas. Sus
dos artículos más conocidos (y que hemos usado aquí para documentación fueron
escritos en 1948 ("A mathematical theory of communication") y 1949 ("Communication
theory of secrecy systems") en la revista "Bell System Technical Journal" El
segundo de ellos, casualmente el que trata de aplicaciones criptográficas, ha
estado ausente de la Red durante mucho tiempo, salvo en forma de imágenes jpg
difíciles de manejar. Felizmente, Jiejun Kong decidió resolver esta injusticia,
y ahora el segundo artículo está disponible en un cómodo pdf. Ni que decir
quiere que los fieles del Taller de Criptografía podrán encontrarlos allí para
su disfrute:
http://www.cripto.es/museo/shannon1948.pdf
http://www.cripto.es/museo/shannon1949.pdf
LIBERTAD VIGILADA - España autoriza el uso de Rota "caso por caso"
[Extraído del libro "Libertad Vigilada", de Nacho García Mostazo, con permiso
del autor]
Segunda parte, capítulo 8:
Como hemos visto, no cabe duda de que el Grupo de Seguridad Naval de la base de
Rota lleva a cabo operaciones de espionaje de las comunicaciones desde mediados
de los años 60. En esa fecha, las bases militares estadounidenses en España eran
aún de su entera propiedad, pero, tras la firma del Convenio
hispano-norteamericano de "Amistad y Cooperación" de 1970, pasaron a ser del
Estado español, que autorizaba a Estados Unidos el uso de ciertas facilidades en
ellas. En 1982, con España ya en la OTAN, se firmó el nuevo Convenio, que
regulaba el uso de las instalaciones y de las autorizaciones que se conceden a
las Fuerzas Armadas de EE.UU. Así pues, toda actividad que lleve a cabo el
Ejército norteamericano en las bases españolas ha de estar autorizada por el
Estado español. De todo ello se desprende que España ha dado permiso a los
estadounidenses para que utilicen sus instalaciones con fines de espionaje.
El propio Gobierno español lo reconoció oficialmente el 10 de marzo de 1999,
durante la comparecencia del entonces ministro de Defensa, Eduardo Serra Rexach,
ante la Comisión de Defensa del Congreso de los Diputados. El ministro respondía
a una serie de cuestiones sobre la petición del Gobierno estadounidense para
iniciar unas obras de ampliación y mejora de las instalaciones de Rota, pero el
Grupo Parlamentario de Izquierda Unida también hizo una pregunta sobre el papel
que juega la base en relación a la guerra electrónica. Según el Diario de
Sesiones del Congreso, Serra respondió a dicha cuestión afirmando que "entre las
instalaciones de apoyo con que cuentan las fuerzas de Estados Unidos en la base
naval de Rota [...] están una instalación naval de comunicaciones y una
instalación para información y vigilancia oceánica de la flota, tal y como viene
recogido en el anejo 2 del Convenio de Cooperación para la Defensa. Estas
instalaciones -continuó el ministro- son de uso norteamericano y están bajo la
responsabilidad del jefe de las fuerzas de Estados Unidos en la base naval de
Rota". [1]
Según dijo Serra, el citado Convenio también especifica que "las fuerzas de
EE.UU. [...] utilizan y mantienen esas instalaciones de apoyo con el objeto de
posibilitar las comunicaciones precisas para el funcionamiento operativo y
administrativo de sus fuerzas navales, el enlace con la red de
telecomunicaciones del Departamento de Defensa de Estados Unidos y el acopio y
distribución de información en apoyo a la flota. Asimismo, las fuerzas de Ee.UU.
están autorizadas a la utilización de códigos, sistemas criptográficos y otros
medios de seguridad". Para concluir su intervención, el ministro afirmó que lo
que se hace en Rota es "recopilar y distribuir la información que necesita la
Marina de Estados Unidos para sus operaciones, algo que evidentemente no tiene
nada que ver con la guerra electrónica. Pero es que, además, de acuerdo con el
artículo 18 del Convenio, la información, que es de carácter puramente militar,
que sea de interés para España y que se obtenga en las instalaciones de apoyo,
es compartida entre ambos países, e incluso el personal español puede participar
conjuntamente con el norteamericano en dichas instalaciones cuando las
autoridades españolas lo consideren conveniente".
En el turno de réplica, Willy Meyer, entonces diputado de Izquierda Unida y
miembro de la Comisión de Defensa del Congreso, afirmó dirigiéndose al ministro
que "a nadie se le escapa [...] que detrás de la expresión 'acopio de
información', se esconde, lisa y llanamente, lo que significa el espionaje
electrónico". Asimismo, Meyer dijo estar convencido de que la base de Rota está
implicada en la red "Echelon" de espionaje global de las comunicaciones. En su
respuesta, el ministro dijo que "en la base de Rota hay unas instalaciones de
comunicación y, como Su Señoría sabe, cualquier instalación de comunicaciones
permite hacer acopio de información a través de satélite, a través de antenas de
radar o a través de teléfono móvil, y una vez evaluada y analizada esa
información se puede hacer inteligencia". Eduardo Serra reconocía así que las
instalaciones de comunicaciones de Rota sirven, en efecto, para fines de
espionaje, contradiciéndose además a sí mismo.
Seguidamente, siguió dirigiéndose a Willy Meyer para pedirle que "no polarice Su
Señoría en Estados Unidos [...] porque hay no menos de media docena de países en
el mundo que tienen capacidad de interceptación de comunicaciones vía satélite".
El ministro finalizó su respuesta pidiéndole al diputado en Izquierda Unida que
"no mezcle Rota en singular con la capacidad de comunicación de satélites. Cada
seis semanas manda un satélite al espacio profundo la NASA, cada seis semanas.
Hay miles de satélites en el mundo, hay miles de centrales en el mundo donde se
está obteniendo esa información [...] digital, analógica, de datos, de voces,
para conocer información de todo tipo, militar, política, económica. Ése es un
problema que, cuando menos, me concederá Su Señoría que excede al tratamiento de
la base de Rota".
La controversia sobre la ampliación de la base hispanonorteamericana continuó
dos años después, cuando el Gobierno español autorizó definitivamente las obras
al Ejército estadounidense. La Comisión de Defensa del Congreso de los Diputados
celebró una nueva reunión para discutir este asunto el 14 de marzo de 2001. Como
titular de la cartera de Defensa y sucesor de Eduardo Serra, Federico
Trillo-Figueroa contestó a las preguntas de los parlamentarios e, igual que le
ocurrió a su antecesor, también se enzarzó en un intenso debate con otro
diputado de Izquierda Unida, en este caso José Luis Centella, quien se oponía a
las obras afirmando que los ciudadanos no quieren "vender su soberanía y su
dignidad" a Estados Unidos. Trillo calificó de "antiguo" el discurso de Centella
y le recordó que en Rota ondea la bandera española y que para la utilización de
la base se requiere la autorización previa de España "caso por caso". En esta
ocasión no se habló sobre el espionaje de las comunicaciones, pero las palabras
del ministro sobre las autorizaciones que se dan al Ejército norteamericano,
unidas a las que pronunció Eduardo Serra dos años antes, vendrían a confirmar
que el Gobierno español está al tanto de las operaciones de espionaje que se
llevan a cabo desde Rota. [2]
[1]. Diario de Sesiones del Congreso de los Diputados. Comisión de Defensa.
Sesión número 36, celebrada el miércoles, 10 de marzo de 1999. VI Legislatura.
Número 640.
[2]. Agencia EFE. "AMPLIACIÓN ROTA / Trillo defiende ampliación Rota y destaca
fuerte inversión en la zona." Teletipo. Madrid, 14 de marzo de 2001.
El boletín ENIGMA es una publicación gratuita del Taller de
Criptografía, y se rige por las normas de la licencia de Creative Commons
Reconocimiento-NoComercial-CompartirIgual. Se permite su libre copia,
distribución y comunicación para fines no lucrativos, citando nombre y
referencia.
Para más información, véase la licencia Creative Commons en sus formas reducida
y completa:
http://www.cripto.es/licencia/deed.es.htm
http://creativecommons.org/licenses/by-nc-sa/2.5/es/legalcode.es
PARA DARSE DE ALTA: envíe un mensaje a la dirección alta arroba cripto.es
añadiendo las palabras alta_enigma en el asunto (subject).
PARA DARSE DE BAJA, envíe un mensaje a la dirección baja arroba cripto.es
añadiendo las palabras baja_enigma en el asunto (subject)
Para comentarios a este boletín (dudas, preguntas, consultas, críticas,
noticias, colaboraciones, etc.), estoy a su disposición en la dirección
noticias arroba cripto.es
Página del Boletín Enigma (incluyendo números atrasados):
http://www.cripto.es/enigma.htm
(c) Arturo Quirantes 2007
Vuelta a la Página principal del Boletín ENIGMA
