1999 << Back To criptograma nº 19

_______________________________________________________________ C R I P T O G R A M A _______________________________________________________________ N·mero 19 15 de Noviembre de 1999 ________________________________________________________________ SUMARIO: 1. Por quΘ son inseguros los ordenadores. 2. Counterpane: Investigaci≤n documentada. 3. Noticias. 4. Roto el cifrado de DVD. 5. En la ratonera: Microsoft Windows CE. 6. Puesta al dφa de la legislaci≤n en Estados Unidos. 7. Criptografφa de Clave P·blica de Curvas Elφpticas. 8. Comentarios de los lectores -- Ejemplar gratuito distribuido a mßs de 14.000 suscriptores -- ________________________________________________________________ * Versi≤n Web de este ejemplar: http://www.kriptopolis.com/criptograma/cg0019.html * Suscripci≤n gratuita: http://www.kriptopolis.com/subs.html * N·meros anteriores: http://www.kriptopolis.com/criptograma/cg.html _______________________________________________________________ 1. POR QU╔ SON INSEGUROS LOS ORDENADORES ________________________________________________ Por Bruce Schneier Traducci≤n: Isidre Marques Serret Casi cada semana la prensa informßtica habla de otro fallo de seguridad: un virus que se aprovecha del Office de Microsoft, una vulnerabilidad en Windows o UNIX, un problema de Java, un agujero de seguridad en una de las pßginas principales de Internet, un ataque contra un popular cortafuegos. ┐Por quΘ no pueden conseguir los dise±adores que esto funcione?, nos preguntamos. ┐Cußndo mejorarß? Yo no creo que lo haga nunca. He aquφ el por quΘ: La ingenierφa de la seguridad es diferente de cualquier otro tipo de ingenierφa. La mayorφa de los productos, como procesadores de textos o telΘfonos celulares, son ·tiles por lo que hacen. Los productos de seguridad, o las caracterφsticas de seguridad ofrecidas dentro de estos productos, son ·tiles precisamente por lo que no permiten que se haga. La mayor parte del dise±o implica hacer que las cosas funcionen. Piense en la definici≤n original de un hacker: alguien que se las ingenia para hacer que pasen cosas ôdiferentesö. El dise±o de seguridad implica evitar que sucedan estas cosas. Implica deducir c≤mo fallan las cosas, y a partir de ahφ prevenir estos fallos. En muchos aspectos esto es similar a la ingenierφa de seguridad. La seguridad es otro requisito de la ingenierφa que no es simplemente una "caracterφstica". Pero el dise±o de la seguridad implica asegurarse de que las cosas no fallarßn en presencia de fallos aleatorios: es programar el ordenador de Murphy, si usted quiere. El dise±o de la seguridad implica lograr que las cosas seguras no fallen en presencia de un adversario inteligente y malΘvolo que fuerza estos fallos precisamente en el peor momento y de la peor manera. El dise±o de la seguridad implica programar el ordenador de Satanßs. Y el ordenador de Satanßs es difφcil de probar. Prßcticamente todo el software se desarrolla a travΘs de un sistema de "prueba-y-error". Se programan peque±os fragmentos, se prueban, se arreglan, y se prueban de nuevo. Varios de estos peque±os fragmentos se combinan en un m≤dulo, y entonces este m≤dulo se prueba, se arregla, y se prueba de nuevo. Luego se combinan varios de estos peque±os m≤dulos en m≤dulos mßs grandes, y asφ sucesivamente. El resultado final es un software que mßs o menos funciona como se esperaba, aunque en programas complejos siempre se escapa alg·n error. El mΘtodo de "prueba-y-error" simplemente no sirve para comprobar la seguridad. Ninguna cantidad de pruebas es suficiente para poder descubrir un fallo de seguridad, por lo que el proceso de la comprobaci≤n no descubrirß nada. Recuerde que seguridad no tiene nada que ver con funcionalidad. Si usted tiene un telΘfono cifrado, puede probarlo. Puede hacer y puede recibir llamadas. Puede intentar, y no lograr, interceptarlo. Pero no tiene ninguna forma de averiguar si el telΘfono es seguro o no. La ·nica manera razonable de "probar" la seguridad es realizar revisiones de seguridad. Esto es un proceso manual caro y largo. No es suficiente comprobar los protocolos de seguridad y los algoritmos de cifrado. Una revisi≤n debe cubrir especificaci≤n, dise±o, aplicaci≤n, c≤digo fuente, funcionamiento, y todo la demßs. Asφ como la prueba funcional no puede demostrar la ausencia de errores, una revisi≤n de seguridad no puede demostrar que el producto es realmente seguro. Y todavφa peor. Una revisi≤n de seguridad de la versi≤n 1.0 dice poco sobre la seguridad de versi≤n 1.1. Una revisi≤n de seguridad de un producto del software aislado no sirve necesariamente para el mismo producto en un ambiente operacional. Y cuanto mßs complejo es el sistema, mßs dura se vuelve una evaluaci≤n de seguridad y mßs fallos de seguridad habrß. Supongamos que un producto de software se desarrolla sin ninguna comprobaci≤n funcional en absoluto. Ninguna comprobaci≤n funcional de las versiones alfa o beta. Se escribe el c≤digo, se compila, y se envφa. Las posibilidades de que este programa simplemente funcione ûincluso dejando de lado que estΘ libre de errores- es cero. A medida que aumenta la complejidad del producto, aumentarß el n·mero de errores. Todos sabemos que las pruebas son esenciales. Desgraciadamente, este es el estado actual, en la prßctica, de la seguridad. Estßn distribuyΘndose productos sin ninguna, o con mφnimas comprobaciones de seguridad. No me sorprende que los errores de seguridad se presenten una y otra vez. No puedo creer que nadie espere otra cosa. A·n peor; los productos se vuelven mßs complejos cada a±o: los sistemas operativos son mßs grandes, tiene mßs caracterφsticas, mßs interacciones entre los diferentes programas en Internet. Windows NT ha estado funcionando durante algunos a±os, y todavφa se descubren errores de seguridad. Podemos esperar muchos mßs errores en Windows 2000; el c≤digo es significativamente mßs grande. Podemos suponer que lo mismo serß cierto para cualquier otro producto de software. Esto no cambiarß. El incremento en el uso de los ordenadores y la convergencia en Internet, estßn aumentando a un ritmo creciente. Los sistemas se estßn convirtiendo en mßs y mßs complejos, y necesariamente mßs inseguros, mßs rßpido de lo que podemos arreglarlos (e incluso mßs rßpidamente de lo que podemos aprender a arreglarlos). Reconocimientos: La frase "programando el ordenador de Satanßs" era originalmente de Ross Anderson. Pero es demasiado buena como para evitar usarla. Una versi≤n acortada de este ensayo aparecφa originalmente en n·mero del 15 de noviembre de la revista _Computerworld_. 2. COUNTERPANE: INVESTIGACION DOCUMENTADA ________________________________________________ Por Bruce Schneier Traducci≤n: David G≤mez "Autentificar items seguros utilizando acceso lento a memoria" John Kelsey y Bruce Scheneier, Primer Simposio en USENIX sobre las tarjetas inteligentes, USENIX Press, por aparecer. Presentamos un protocolo de autentificaci≤n que permite que un item, como una tarjeta inteligente, se autentifique en un sistema informßtico seguro en el otro extremo a traves de un lector inseguro. Este protocolo se basa en el hecho de que el item respondera a las consultas de forma lenta, y que el propietario del objeto no se sentara pacientemente mientras el lector parece que no funciona. Este protocolo puede ser usado de forma independiente, con items de memoria "tontos", o con items basados en procesadores. http://www.counterpane.com/slow-memory.html 3. NOTICIAS _________________________________________________ Por Bruce Schneier Traducci≤n: David G≤mez Una compa±φa ha desarrollado un paquete de cifrado de correo que permite al remitente elegir durante cußnto estarß disponible la clave de descifrado, convirtiendo cualquier copia de ese correo en ilegible despuΘs de la fecha elegida. Es un buen sistema para prevenir que la gente accidentalmente olvide borrar su correo (a la vista del juicio de Microsoft, muchas compa±φas tienen ya polφticas de borrar todo el correo antiguo a partir de una cierta fecha.) No es nada bueno, sin embargo, como una medida de seguridad para *prevenir* a alguien de grabar su correo pasada esa fecha. Alguien puede grabar siempre el correo descifrado en un fichero, incluir el correo en un mensaje saliente sin la restricci≤n, o incluso hacer una captura de pantalla y grabar una copia del correo de esa manera. Este puede ser un buen producto, pero no se enga±e a si mismo pensando que sirve como una medida de seguridad: http://www.technologypost.com/internet/DAILY/ 19991011102015158.asp?Section=Main El idioma como criptografφa. Estas historias hablan acerca de un lenguaje secreto utilizado en China. La segunda historia menciona que el castigo en la China Imperial por inventar un lenguaje secreto era la muerte: http://www.smh.com.au:80/news/9910/12/text/world5.html http://www.foxnews.com/scitech/101899/chinese_lingo.sml Arjen Lenstra y Eric Verheul han escrito un excelente documento sobre las longitudes de las claves: simΘtricas, claves publicas (incluyendo curvas elipticas), etc. Comparan las longitudes de las claves de diferentes sistemas, y efect·an predicciones sobre el futuro. Bßjese esto: http://www.cryptosavvy.com El Departamento de Policφa de Los Angeles ha sido acusado de efectuar cientos de escuchas ilegales durante varios a±os. Tenga esta historia a mano la pr≤xima vez que alguien le diga que las escuchas de la policφa son algo bueno, y que por supuesto se puede confiar en la policφa: http://www.zdnet.com/zdnn/stories/news/ 0,4586,2378149,00.html?chkpt=hpqsnewst Falsa alarma: Jaws Technologies estß aprovechando una ocasi≤n para sus adquisiciones: http://www.nationalpost.com/network.asp?f=991103/117402 Departamento de malas ideas: la Internet Engineering Task Force (IETF) estaba considerando introducir posibilidades de escucha en futuras versiones de Internet. Cualquiera que tenga voz deberφa presentarse en los encuentros del IETF para oponerse a esto: http://www.wired.com/news/print/1,1294,31895,00.html El Congresista Bob Barr se pronuncia contra esta idea: http://www.wired.com/news/print/1,1294,32100,00.html El sentido com·n prevaleci≤, y en el reciente encuentro de la IETF en D.C, decidieron no llevarlo a efecto. http://www.wired.com/news/politics/0,1283,32455,00.html Una compa±φa llamada SecureLogix estß construyendo un firewall para los PBXs. Esto es una buena idea. http://www.securelogix.com La administraci≤n Clinton estß pensando en relajar los controles de exportaci≤n sobre el c≤digo fuente criptogrßfico: http://www.wired.com/news/print/1,1294,32006,00.html http://www.computerworld.com/home/news.nsf/all/9910225source Los analistas del grupo Gartner estßn haciendo mucho ruido acerca de los virus del a±o 2000: http://www.computerworld.com/home/news.nsf/all/9910122gartner2 Y el FBI dice que ha recogido 30,000 amenazas de virus relacionados con el a±o 2000. Aunque esto se parece un poco a la lista McCarthy's de los 500 comunistas conocidos, tiene sentido el ser extremadamente cuidadoso al abrir adjuntos de los correos y bajarse nuevo software hacia el cambio de a±o: http://www.zdnet.com/zdnn/stories/news/0,4586,2386686,00.html?chkpt=zdnnstop Microsoft ha respondido ofreciendo software anti-virus gratuito, olvidando aparentemente que el software obtenido hoy no ayudarß contra virus que no darßn la cara hasta el a±o que viene: http://www.computerworld.com/home/news.nsf/all/9911011msy2k http://www.infoworld.com/cgi-bin/displayStory.pl?99111.hnmsy2k.htm La Agencia Nacional de Seguridad valorarß ahora la seguridad de las redes para agencias de defensa y civiles. Intentarßn incluso romper los sistemas de las agencias para se±alar vulnerabilidades: http://www.fcw.com/pubs/fcw/1999/1101/fcw-agnsa-11-01-99.html Excelente entrevista con Ross Anderson de la revista New Scientist: http://www.newscientist.com/ns/19991106/confidenti.html TEMPEST es el nombre en c≤digo de la NSA para la habilidad de espiar los equipos electr≤nicos interceptando y decodificando sus se±ales electromagnΘticas. Un archivero piensa publicar en su sitio Web documentos, obtenidos de la NSA a travΘs del Acta para la Libertad de Informaci≤n, que nos proporcionan mßs detalles: http://www.wired.com/news/print/0,1294,32097,00.html Vea tambiΘn: http://www.newscientist.com/ns/19991106/newsstory6.html La informaci≤n sobre Echelon sale lentamente a la luz: http://www.wired.com/news/print/0,1294,32302,00.html http://washingtonpost.com/wp-srv/WPcap/1999-11/14/019r-111499-idx.html http://www.independent.co.uk/news/Digital/Features/spies151199.shtml Lo inevitable ha sucedido finalmente. Alguien invent≤ un virus de correo que puede infectar su sistema cuando usted lea su correo; no tiene que ejecutar nada. El virus Bubbleboy necesita que el usuario estΘ ejecutando los programas de correo Microsoft Outlook o Outlook Express; Windows 95, 98, o 2000; y Internet Explorer 5.0 o superior. Su blanco es un agujero de seguridad para el cual Microsoft ya ha creado un parche, pero que muchos usuarios todavφa tienen que actualizar: http://www.wired.com/news/story/0,1240,32434,00.html http://www.wired.com/news/technology/0,1282,32529,00.html El parche de Microsoft: http://www.microsoft.com/security/Bulletins/ms99-032.asp Mi comentario en Comunicaciones de la ACM sobre el futuro del software malicioso: http://www.counterpane.com/insiderisks2.html 4. ROTO EL CIFRADO DE DVD _________________________________________________ Por Bruce Schneier Traducci≤n: Daniel Cabezas El sistema de protecci≤n de los DVDs ha sido roto. Ahora hay programas freeware en la red que eliminan la protecci≤n de copia en los DVDs, permitiendo que sean reproducidos, editados y copiados sin restricci≤n alguna. Esto no deberφa ser una sorpresa para nadie, y menos a·n para la industria del ocio. El esquema de protecci≤n es gravemente defectuoso en varios aspectos. Cada DVD estß cifrado con algo llamado "Content Scrambling System (CCS)" - Sistema de embrollo de contenido. Tiene una clave de 40 bits. (No tengo idea de por quΘ. La NSA y el FBI no deberφan preocuparse del cifrado DVD. No hay pelφculas terroristas cifradas que necesiten observar). Ni tan siquiera es un algoritmo muy bueno. Pero incluso aunque el cifrado fuese triple-DES, este sistema serφa defectuoso. Cada reproductor de DVD, incluyendo las consolas hardware que se enchufan al televisor, y los reproductores de software que se pueden descargar al ordenador, tienen su propia y ·nica clave de acceso. (En realidad, cada uno tiene varias, no se por quΘ). Esta clave es usada para dar acceso a la clave de cifrado en cada DVD. Un DVD tiene 400 copias de la misma clave ·nica de descifrado, cada una cifrada con cada c≤digo de acceso. N≤tese el secreto a voces: si se las arregla para conseguir una clave de acceso para un reproductor, puede descifrar todos y cada uno de los DVD. Pero incluso si esto fuese completamente perfecto, el sistema nunca podrφa funcionar. El defecto se encuentra en el modelo de seguridad. El reproductor de software, finalmente, consigue la clave de descifrado, descifra el DVD y lo muestra por pantalla. Esa informaci≤n descifrada del DVD estß en el ordenador. Tiene que estar, no hay otra manera de mostrarla por pantalla. No importa lo bueno que sea el sistema de cifrado, la informaci≤n del DVD estß disponible en texto en claro (tal cual), para cualquiera capaz de escribir un programa de ordenador para obtenerla. Otro tanto ocurre con la clave de descifrado. El ordenador debe descifrar el DVD. La clave de descifrado debe estar en el ordenador. Asφ que la lave de descifrado estß disponible, de forma transparente, para cualquiera que sepa d≤nde buscar. Estß protegida por una clave de acceso, pero el lector tiene que darnos acceso a ella. Se suponφa que los fabricantes de software para DVD encubrirφan el funcionamiento del programa de descifrado, y posiblemente el programa reproductor, empleando alg·n tipo de tΘcnicas de ocultamiento del software. Estas tΘcnicas nunca han demostrado funcionar mucho tiempo; solo parecen obligar a los hackers a gastar un par de semanas extra haciΘndose una idea de como funciona el software. Ya he escrito sobre esto anteriormente en relaci≤n a la protecci≤n de copia de software: no se puede ofuscar el software. Puede que sea un mal trago que aceptar para la industria del ocio, pero la protecci≤n de contenidos de software no funciona. No puede funcionar. Se pueden distribuir contenidos cifrados, pero para poder permitir que sean leφdos, vistos o escuchados, deberßn ser pasados a texto en claro. Un hacker lo suficientemente inteligente, con herramientas de depuraci≤n de programas lo bastante buenas, siempre serß capaz de invertir el funcionamiento del algoritmo, obtener la clave, o simplemente capturar el texto en claro tras el descifrado. Y puede escribir un programa de software que permita a otros realizar estas tareas automßticamente. Y esto no puede ser impedido. Si en cambio asumimos hardware seguro, el sistema funciona. (De hecho, la industria quiere extender el sistema por todo el camino hasta llegar al monitor, y finalmente realizar ahφ el descifrado). El ataque funciona porque el hacker puede ejecutar un depurador y otras herramientas de programaci≤n. Si el dispositivo de descifrado y el de visionado (deben ser ambos) estßn dentro de una pieza de hardware a prueba de intromisiones, el hacker se queda atascado en su intento. No puede aplicar ingenierφa inversa a nada. Pero el hardware a prueba de intromisiones es en gran manera un mito, asφ que en la realidad este caso tan s≤lo serφa otra barrera que alguien finalmente superarφa. La protecci≤n de contenidos digitales simplemente no funciona; pregunte a cualquiera que haya intentado proteger software contra copias. Una lecci≤n mßs y una observaci≤n: La lecci≤n: este es un ejemplo mßs de una empresa, reunida en secreto para dise±ar un algoritmo de cifrado propietario, que termina siendo desconcertantemente dΘbil. Nunca he entendido por quΘ la gente no emplea algoritmos y protocolos ya publicados, en los que se pueda confiar. Siempre son mejores. La observaci≤n: la ôsoluci≤nö por la que la industria del ocio ha estado pugnando es ilegalizar la ingenierφa inversa. Lo han conseguido en los Estados Unidos: el acta de Copyright Milenio Digital incluye disposiciones al efecto, a pesar de las protestas de comunidades cientφficas y de derechos civiles. (Sφ, se podrφa ir a la cßrcel por tener un depurador de c≤digo). Han conseguido hacer pasar una ley semejante en el Reino Unido, y estßn trabajando para lograrlo en la Uni≤n Europea. Esta ôsoluci≤nö no funciona y no tiene ning·n sentido. Primero, a menos que la ingenierφa inversa sea ilegal en todo el planeta, siempre habrß alguien capaz de aplicarla en alg·n lugar. Y una persona es todo lo que se necesita, porque puede escribir software que usen todos los demßs. Segundo, la ingenierφa inversa puede, como en este caso, funcionar an≤nimamente. Las leyes no habrφan ayudado en este caso. Y tercero, las leyes no pueden ômeter de nuevo al gato en la bolsaö. Incluso aunque puedas atrapar y encausar a los hackers que lo hicieron, no afectarφa a las herramientas de los hackers que ya han sido -y contin·an siendo- escritas. Lo que la industria del ocio sφ puede hacer, y han hecho en este caso, es emplear amenazas legales para enlentecer la difusi≤n de estas herramientas. Hasta ahora, la industria ha amenazado con acciones legales contra la gente que ha puesto estas herramientas de software en sus sitios web. El resultado es que estas herramientas existirßn en las pßginas web hackers, pero nunca estarßn en software de dominio p·blico (Linux, por ejemplo). El tremendo fallo de todo esto es que la industria del ocio es perezosa, y estß intentando encontrar un soluci≤n tecnol≤gica a lo que es un problema legal. Es ilegal robar copyrights o marcas comerciales, tanto si es una pelφcula DVD, una camisa de Ralph Lauren o un bolso Louis Vitton. Esta protecci≤n legal todavφa existe, y todavφa es fuerte. Por alguna raz≤n la industria del ocio ha decidido que tiene un derecho legal a la protecci≤n de su tecnologφa, y eso no tiene sentido alguno. Por otra parte, estßn presionando a las parlamentos para aprobar leyes que afiancen esta protecci≤n tecnol≤gica defectuosa. En los Estados Unidos y Reino Unido (y posiblemente, pronto en la Uni≤n Europea), es ilegal saltarse su tecnologφa, incluso cuando nunca se haga para violar un copyright. Es ilegal iniciar investigaciones cientφficas sobre el cifrado utilizado en esos sistemas. Es ilegal intentar mirar dentro de algo que se adquirido legalmente. Asφ que no s≤lo el sistema no funciona, sino que ademßs crea un mercado negro donde no lo habφa anteriormente, y sin hacer ning·n bien a la sociedad durante el proceso. La rotura de la protecci≤n del DVD es algo bueno. No servφa al interΘs de nadie que la industria del ocio depositara su confianza en un mal sistema de seguridad. Es una buena investigaci≤n la que lleva a mostrar lo malo que es el algoritmo de cifrado y lo mal concebido que estß el modelo de seguridad en si. Lo aprendido en esta ocasi≤n puede ser aplicado a hacer los sistemas futuros mßs resistentes. http://www.wired.com/news/technology/0,1282,32263,00.html http://www.ntk.net/index.cgi?back=archive99/now1029.txt Resumen del modelo de encriptaci≤n DVD: http://crypto.gq.nu Material para expertos: http://livid.on.openprojects.net/pipermail/livid-dev/1999-October/00058.html http://livid.on.openprojects.net/pipermail/livid-dev/1999-October/00059.html http://livid.on.openprojects.net/pipermail/livid-dev/1999-October/00069.html http://livid.on.openprojects.net/pipermail/livid-dev/1999-October/00061.html Mi ensayo sobre protecci≤n de copia de software: http://www.counterpane.com/crypto-gram-9811.html#copy Mis comentarios sobre el Acta de Copyrights Digital Milenio: http://www.zdnet.com/pcweek/news/0622/22wipo.html Nuevas tΘcnicas de ofuscaci≤n de software de Intel que, pronostico, serßn pronto rotas: http://www.intel.com/pressroom/archive/releases/in110999.htm/ 5. EN LA RATONERA: MICROSOFT WINDOWS CE _________________________________________________ Por Bruce Schneier Traducci≤n: Miguel Camacho Microsoft cifra su contrase±a Windows NT cuando se guarda en una unidad Windows CE. Pero si uno mira cuidadosamente el algoritmo de cifrado, simplemente realizan una operaci≤n XOR con "susageP" (Pegasus escrito al revΘs). Pegasus es el nombre clave de Windows CE. Es tan patΘtico que resulta asombroso. http://www.cegadgets.com/artsusageP.htm 6. PUESTA AL D═A DE LA LEGISLACI╙N EN ESTADOS UNIDOS _______________________________________________________ Por Bruce Schneier Traducci≤n: Miguel Camacho A veces parece que nunca cambia nada. Los proyectos para relajar los controles de exportaci≤n en materia criptogrßfica estßn avanzando a rastras tanto a travßs del Congreso como del Senado. Pero nunca se llega a votar nada. En el parlamento, mßs de 250 miembros del Congreso han copatrocinado H.R 850, el acta sobre seguridad y libertad mediante cifrado (SAFE) presentado por los Republicanos Bob Goodlatte (R-VA) y Zoe Lofgren (D-CA). El proyecto de ley permite para la libre exportaci≤n de dispositivos criptograficos (tanto en hardware como en software) si un producto equiparable estß disponible desde una compa±φa extranjera, y suprime la obligatoriedad de la custodia de claves. Por otra parte, tambiΘn incluye una controvertida clßusula que crea un nuevo delito federal al usar criptografia para "favorecer actuaciones criminales". Este proyecto ha sido aprobado por cinco comisiones, lo que llevarφa a pensar que ya existirφa suficiente como para emitir una decision. Sin embargo, en dos de los comitΘs (Inteligencia y Servicios Armados) los proyectos fueron enmendados para mantener en la prßctica los controles de exportaci≤n. El ComitΘ de reglamentacion parlamentaria tendra que decidir sobre cußl de las versiones serß sometida a votaci≤n. Por parte del Senado, el presidente de la Comisi≤n de Comercio y candidato presidencial John McCain (R-AZ), dio marcha atrßs en sus posiciones iniciales oponiΘndose a la criptografia e introdujo S. 798, el acta de 1999 que promueve las transacciones en lφnea seguras para estimular el comercio y negocios (PROTECT). El proyecto de ley permite la libre exportaci≤n de productos de 64 bits o inferiores. El cifrado mßs potente puede ser exportado a comerciantes en lφnea, grandes empresas de administraci≤n p·blica, industrias controladas por el gobierno, filiales o subsidiarias de empresas americanas y gobiernos pertenecientes a la NATO, OECD y ASEAN. (Es de destacar esto ·ltimo; ┐Quieren vender cifrado fuerte a Vietnam y Birmania, pero no a Brasil o Argentina?) Un departamento de consejo de exportaci≤n criptogrßfica puede aconsejar relajar las restricciones. Finalmente, sobre Enero del 2002 los productos que adopten el AES o su equivalente serßn libremente exportables. El proyecto de ley fue aprobado por la Comisi≤n de Comercio en junio y espera actualmente la votaci≤n del Senado. Mas informaci≤n: http://www.epic.org/privacy/bill_track.html 7. CRIPTOGRAF═A DE CLAVE P┌BLICA DE CURVAS EL═PTICAS _____________________________________________________ Por Bruce Schneier Traducci≤n: Angel Galindo Sßnchez En septiembre de este a±o, alrededor de 700 personas, utilizando 740 ordenadores, fueron capaces de romper un mensaje cifrado con criptografφa de curva elφptica de 97 bits. El proceso necesit≤ 16.000 MIPS-a±os de cßlculos, aproximadamente el doble de lo que necesit≤ otro equipo que recientemente rompi≤ una llave de cifrado RSA de 512 bits. Certicom, la empresa que patrocin≤ este concurso, ha ofrecido estos resultados como evidencia de que la criptografφa de curva elφptica es mßs fuerte que RSA. Analicemos esta afirmaci≤n un poco mßs despacio. Todos los algoritmos de llave p·blica, ya sean para intercambio de claves, cifrado o firma digital, estßn basados en uno de estos dos problemas: el problema de factorizaci≤n o el problema del logaritmo discreto. (Hay otros algoritmos en cφrculos acadΘmicos, pero son demasiado difφciles de manejar como para ser utilizados en el mundo real). La seguridad de RSA proviene de la dificultad de factorizar n·meros grandes. Los sistemas fuertes basados en RSA utilizan n·meros de 1024 bits, e incluso mayores. La seguridad de la mayorφa del resto de los algoritmos de clave p·blica -ElGamal, DSA, etcΘtera- se basa en el problema del logaritmo discreto. Los dos problemas son muy similares, y todos los algoritmos de factorizaci≤n modernos pueden utilizarse para calcular logaritmos discretos en un grupo multiplicativo de dimensi≤n finita. De forma aproximada, factorizar un n·mero de un cierto tama±o y calcular el logaritmo discreto de otro n·mero del mismo tama±o, supone la misma cantidad de trabajo. Esto significa que, para un tama±o de clave dado, RSA, ElGamal, DSA, etcΘtera, son aproximadamente igual de seguros. (Esto no es estrictamente cierto, pero es una aproximaci≤n suficientemente buena para este artφculo). Todos estos algoritmos requieren el uso de algo llamado "grupo algebraico". Cuando se invent≤ la criptografφa de llave p·blica, todos los algoritmos se implementaron en el grupo algebraico mßs sencillo: los n·meros de m≤dulo n. Por ejemplo, la cifrado RSA es m^e mod n, y una llave p·blica Diffie-Hellman es g^y mod n. De hecho, cualquier grupo algebraico valdrφa. Las curvas elφpticas son, simplemente, otro grupo algebraico. En criptografφa de curva elφptica, las llaves p·blicas y privadas se definen como puntos situados sobre un objeto matemßtico llamado curva elφptica. (No se preocupe: en realidad no importa quΘ es lo que significa Θsto). La suma es una operaci≤n que combina dos puntos y produce un tercero. El algoritmo parece lo mismo, pero las operaciones concretas son muy distintas. Pero si sirve cualquier grupo algebraico, ┐por quΘ hay gente que se preocupa por las curvas elφpticas?. Parece que para algoritmos de curva elφptica de logaritmos discretos, tal vez podamos utilizar llaves mßs peque±as. (Esto no es cierto para RSA, y por ello nunca verß una variante RSA de curva elφptica). Todos los algoritmos mßs rßpidos para calcular logaritmos discretos - el filtro del campo numΘrico y el filtro cuadrßtico - utilizan algo llamado φndice de cßlculo y una propiedad de los n·meros de m≤dulo n llamada uniformidad [smoothness], y, por tanto, para romper algoritmos de curva elφptica hay que utilizar mΘtodos antiguos: la rho de Pollard, por ejemplo. Entonces, s≤lo tenemos que utilizar claves lo suficientemente largas como para que sean seguras frente a estos viejos y lentos mΘtodos. De ahφ que las claves puedan ser mßs cortas. Y pueden ser significativamente mßs cortas. Debido a la rotura de la que hablßbamos, Certicom recomienda llaves de 163 bits. Compare Θsto con la longitud de clave recomendada para algoritmos convencionales de algoritmo discreto, que es como mφnimo de 1024 bits. El hecho de que esta recomendaci≤n tenga sentido depende de lo rßpido que puede hacerse que los algoritmos trabajen con las curvas elφpticas. La cuesti≤n a preguntarse es: "┐Esta falta de uniformidad es una propiedad fundamental de las curvas elφpticas, o simplemente es un vacφo en nuestros conocimientos sobre ellas?". O, mßs en general: "┐Es inherentemente mßs difφcil calcular logaritmos discretos en las curvas elφpticas, o podremos tal vez encontrar alg·n mΘtodo para hacerlo de forma tan eficiente como con los n·meros de m≤dulo n?". Si creemos en lo primero, las curvas elφpticas serßn siempre mßs seguras -para la misma longitud de clave- que los n·meros de m≤dulo n. Si creemos lo segundo, s≤lo es cuesti≤n de tiempo que se consiga romperlas. Certicom desea fervientemente creer en lo primero. Dicen cosas como: "Las curvas elφpticas como entidades algebraicas/geomΘtricas han sido estudiadas de forma extensiva durante los ·ltimos 150 a±os, y de estos estudios ha surgido una rica y profunda teorφa". Concluyen que, debido a Θsto, podemos confiar que los nuevos avances algorφtmicos no sean demasiado devastadores. Para mφ, esto es una mont≤n de buenos deseos. Serφa maravilloso si dispusiΘramos de 150 a±os de investigaciones en las propiedades criptogrßficas de las curvas elφpticas. Pero no es asφ; por el contrario, tenemos 150 a±os de trabajos en las propiedades de las curvas elφpticas que interesan a los matemßticos, y la mayorφa de ellas s≤lo se relacionan accidentalmente con las que interesan a los cript≤grafos. La criptografφa de curva elφptica fue inventada apenas en 1985, y s≤lo se ha estudiado seriamente durante unos pocos a±os. Incluso hoy, la mayorφa del trabajo sobre curvas elφpticas en un tφpico departamento universitario de matemßticas es bastante irrelevante para nosotros, los cript≤grafos. Seguramente, algunos de sus resultados podrφan ocasionalmente ayudarnos a comprender la fortaleza de los algoritmos de curva elφptica; pero Θste no ha sido casi nunca el objetivo de las investigaciones en matemßticas. Esta situaci≤n estß cambiando ahora, pero muy lentamente. Mßs a·n, la investigaci≤n en algoritmos eficientes para curvas elφpticas es muy nuevo. La propia noci≤n de algoritmo eficiente, incluso, no apareci≤ hasta los 60 o 70, y la teorφa algorφtmica de n·meros s≤lo se ha popularizado en las pasadas dos dΘcadas. Antes de los ordenadores, ni siquiera era relevante. La respuesta real a la pregunta es "No lo sabemos". No sabemos si hay formas eficientes de calcular logaritmos discretos en grupos de curvas elφpticas. No sabemos si hay una definici≤n de uniformidad que nos permita aplicar el filtro del campo numΘrico a las curvas elφpticas. No sabemos si, a largo plazo, pueden utilizarse claves mßs cortas con algoritmos de curva elφptica. A corto plazo, las recomendaciones de Certicom son razonables. Hoy, no podemos calcular logaritmos discretos en curvas elφpticas de forma tan eficiente como con los n·meros de m≤dulo n. Los sistemas pueden utilizar claves mßs cortas con curvas elφpticas. Pero, a largo plazo, no lo sabemos. Hay otras diferencias que tambiΘn es necesario considerar. Comprobar firmas de curva elφptica es a·n complicado, comparado con la comprobaci≤n de las firmas RSA. Y todos los usuarios de un sistema de curva elφptica tienen que utilizar la misma curva. (Si no se hace Θsto, se pierden la mayor parte de los beneficios de tama±o en las claves de curva elφptica). Esto tiene implicaciones en seguridad: es mßs fßcil romper la clave de un usuario al azar de un sistema, que romper la clave de un usuario concreto. Me gustarφa ver mßs anßlisis sobre este aspecto para los sistemas de curva elφptica. Mi recomendaci≤n es que si estß usted trabajando en un sistema con limitaciones en el tama±o de clave -tarjetas inteligentes, algunos telΘfonos m≤viles o receptores de mensajes, etcΘtera-, considere la utilizaci≤n de curvas elφpticas. Si no tiene restricciones de tama±o, utilice RSA. Si necesita seguridad durante varias dΘcadas (casi ning·n sistema lo necesita), utilice RSA. Tenga en cuenta que alg·n dφa -el pr≤ximo a±o, en diez a±os, en un siglo-, alguien puede encontrar una forma de definir la uniformidad, o algo incluso mßs ·til, en curvas elφpticas. Si ocurre Θsto, tendrß que utilizar la misma longitud de clave que se emplearφa en algoritmos de logaritmo discreto, y entonces ya no habrß ninguna raz≤n para utilizar algoritmos de curva elφptica. Postdata: Este anßlisis puede aplicarse tambiΘn a la factorizaci≤n. A la gente de RSA Security, Inc. les gusta hablar de la larga historia del problema de factorizaci≤n, y de c≤mo nos da confianza sobre la seguridad de RSA. Sφ, se ha estudiado durante siglos, pero s≤lo recientemente esos estudios han estado remotamente relacionados con la criptografφa. Mßs a·n, el trabajo en factorizaci≤n no ha sido considerada como un ßrea respetable de estudio hasta recientemente; antes de eso, se consideraba como un hobby excΘntrico. Y los algoritmos eficientes para la factorizaci≤n s≤lo se han estudiado en el ·ltimo par de dΘcadas. Realmente no tenemos ni idea de la fortaleza de la factorizaci≤n fuerte. La verdad es que las empresas tienen tendencia a exagerar sus productos. Antes de tomar una decisi≤n sobre algoritmos criptogrßficos, los clientes deberφan recabar una amplia variedad de opiniones independientes (de personas no involucradas econ≤micamente en los resultados de la decisi≤n que se tome) sobre quΘ estßn comprando. Noticias sobre los recientes esfuerzos de craqueo de las curvas elφpticas: http://www.computerworld.com/home/news.nsf/all/9909282ellip http://www.certicom.com/press/99/sept2899.htm Una excelente introducci≤n matemßtica a las curvas elφpticas: http://www.certicom.com/ecc/enter/index.htm Una excelente comparaci≤n sobre las longitudes de claves, incluyendo RSA y curvas elφpticas: http://www.cryptosavvy.com 8. COMENTARIOS DE LOS LECTORES _________________________________________________ Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna y Oscar Esteban De: Reinhard Wobst Tema: El problema del c≤digo abierto ------------------------------------- Hoy, durante el congreso ISSE en Berlin, hemos tenido un debate acerca del siguiente tema "┐Ayuda el c≤digo abierto a aumentar la seguridad?". Por supuesto, hablßbamos acerca de la seguridad general de las tecnologφas de informaci≤n, no s≤lo acerca de criptografφa. Lo que escribi≤ en Criptograma acerca de los algoritmos de cifrado de c≤digo abierto es totalmente cierto. El ejemplo de las mßquinas de cifrado AG, donde la clave secreta era cifrada por una clave NSA y despuΘs probablemente colocada en la cabecera del mensaje, es un ejemplo ilustrativo. En contraste con esto, estamos de acuerdo en que el c≤digo abierto en sistemas operativos o aplicaciones generalmente no incrementa la seguridad, sino que se limita a hacer que la localizaci≤n de errores, asφ como su correcci≤n, sean mßs rapidas. En ambientes comerciales no es posible realizar parches con la misma frecuencia con que se localizan agujeros de seguridad y estos son cerrados. Algunas veces los usuarios se dan cuenta de estos problemas y escriben un parche para sus aplicaciones que fallarß con la siguiente versi≤n. Su teorφa sobre localizar los errores mßs importantes en el menor tiempo posible suena bien. Sin embargo, personas de organizaciones como DFN-CERT argumentan que la cadena no tiene fin, e incluso "errores sin importancia" pueden ser usados fßcilmente para ataques automatizados. Por lo tanto, estamos de acuerdo al decir: el c≤digo abierto no necesariamente incrementa la seguridad considerablemente, pero incrementa la FIABILIDAD. Y esto es, por supuesto, muy importante para implementaciones criptogrßficas. De: Larry Nathanson Tema: Re: E*Trade -------------------- Dwight Arthur (dwight@bestweb.net) dijo: "Me gusta E*Trade, yo comercio allφ. E*Trade nunca me ha pedido que estΘ de acuerdo con ser responsable de cualquiera de los negocios hechos con mi password, por tanto mi opini≤n es que estßn poniendo en riesgo sus propios recursos (no los mφos) con esta seguridad dΘbil". Me gustaria reconsiderar esta postura. De la aceptaci≤n de clßusulas del cliente E*TRADE (etiquetada como ET100/0798 en la ·ltima pßgina): "Este documento contiene los tΘrminos y condiciones que gobiernan su cuenta E*TRADE. Por favor, lΘalos cuidadosamente y consΘrvelos para su informaci≤n." "Aceptaci≤n del cliente", Item 28, Pßrrafo 2 (pßgina 6): Usted debiera ser el ·nico usuario autorizado del servicio al que afecta esta aceptaci≤n de tΘrminos. Usted debiera ser responsable de la confidencialidad y uso de su identificaci≤n de usuario, clave de contrataci≤n, clave de comercio y PIN. Usted debe comprender que es el ·nico responsable de todos los pedidos introducidos a travΘs del servicio usando su identificador de usuario, clave de contrataci≤n, clave de comercio y PIN.... Usted acepta que E*TRADE y sus afiliados no serßn responsables de ninguna pΘrdida resultante a partir de una causa de la que E*TRADE o sus afiliados no tengan control directo, incluyendo, pero no limitandose a, ...accesos no autorizados...". Tambien en linea en: https://trading.etrade.com/cgi-bin/gx.cgi/ AppLogic+AcctDefault?gxml=etrade_info/customer_agreement.html (requiere login). De: Estes, Danal Tema: El "Paquete Mßgico" de AMD -------------------------------- El ·ltimo Criptograma contenφa una referencia al "Paquete Mßgico" de AMD que podrφa encender un PC a travΘs de la red. Su expresi≤n acerca del asunto de la seguridad es acertada en su objetivo, pero asociar este tema con un vendedor o tecnologφa concretos no lo es. Esto afecta a cualquiera que soporte "Wake-On-Lan" (Activaci≤n a TravΘs de la Red) en su placa madre/tarjeta de red, y no s≤lo a AMD: http://www.microsoft.com/hwdev/specs/PMref/PMnetwork.htm#details Desde hace alg·n tiempo, los fabricantes de placas madre y tarjetas de red han estado soportando un estßndar conocido como "Wake On Lan". Esto inicialmente requerφa un cable especial desde la tarjeta de red hasta un peque±o cabezal de 2 pines en la placa madre. En conjunci≤n con los estßndares de suministro de energφa ATX, que mantienen una peque±a porci≤n de la placa madre con energφa (lo que permite "pulse la barra espaciadora para encender", etc), la tarjeta de red podrφa tambiΘn permanecer con energφa y enviar la se±al de "energφa total" a la placa madre a travΘs de este cable. Creo recordar haber visto una referencia a permitir esta misma idea vφa el bus PCI (sin requerir ning·n cable especial) en alg·n nivel de revisi≤n. IBM, Compaq, Dell, etc, han estado promocionando esta tecnologφa en sus presentaciones durante al menos los dos ·ltimos a±os. Por tanto, no es s≤lo AMD; es toda una completa variedad de fabricantes de componentes y sistemas acabados. De nuevo, los problemas de seguridad son reales. El formato del paquete para producir un "despertar" estß estandarizado y bien difundido. Necesitamos conocer la direcci≤n hardware (capa MAC) de la tarjeta de red, pero Θsta se obtiene fßcilmente en el momento en que el ordenador estß activo y comunicßndose. Etc, etc. "Wake On Lan" precisa ciertas configuraciones para funcionar, que no son generalmente las caracterφsticas por defecto de la combinaci≤n placa madre/tarjeta de red. ┐QuiΘnes son mßs proclives a permitir esto? Grandes compa±φas que tienen iniciativas de "Gesti≤n de Sistemas Empresariales". Mientras este estßndar gana empuje, mientras se convierte en parte del bus(es) en lugar de cables especiales, si/cuando se convierta en permitido por defecto... Ya he dicho bastante. Mantengßmonos alerta. De: Gary Ellison Tema: Nueva polφtica sobre criptografφa en los EE.UU. ----------------------------------------------------- Algunos comentarios acerca de la nueva polφtica sobre criptografφa de la administraci≤n Clinton que creo merece la pena destacar. Primero, las nuevas reglas no cambian nada con respecto a la "criptografφa no de serie". En otras palabras, los kits de herramientas, como BSafe o Java Cryptographic Extensions, seguirßn sufriendo las mismas restricciones que sufren hoy. Tampoco estß claro cußl serß el destino de los aceleradores criptogrßficos hardware (ASIC u otros componentes). En el caso de kits software, la NSA no permitirß la exportaci≤n de criptografφa fuerte a menos que el kit sea cerrado (como son los casos de CAPI o CDSA). De acuerdo con la nueva polφtica, los productos criptogrßficos "finales" pasarßn una "revisi≤n ·nica". Supongo que la revisi≤n de la NSA serß algo mßs detallada en el futuro que hasta ahora. Dicho esto, ┐quΘ queda para impedir a la NSA decir que estos productos "finales" son "criptografφa no de serie" y denegar la licencia de exportaci≤n? Por ejemplo, Eudora podrφa no cumplir en lo sucesivo los criterios de exportaci≤n de la NSA dada la arquitectura de su api de plugins. Otra cuesti≤n es que el plan de la administraci≤n Clinton abarca aproximadamente el 80% del Acta SAFE y es poco probable que llegue a haber nunca el tipo de apoyo necesario para eliminar las restricciones del 20% restante. Por ·ltimo, las nuevas reglas de la administraci≤n Clinton no estßn escritas como ley y cualquier administraci≤n posterior podrφa cepillßrselas con igual facilidad. Tal vez la CESA deberφa ser llamada Acta de Instalaci≤n de Micr≤fonos Ocultos de 1999. De: Greg Weiss Tema: ┐Son los votos electr≤nicos mßs proclives a la coacci≤n del votante? ------------------------------------------------ Con toda la charla sobre votaci≤n electr≤nica, estß bien que alguien reconozca que hay algunos problemas de seguridad serios. El mßs importante, al menos para mφ, es la coacci≤n del votante... Yo solφa compartir esa misma opini≤n al respecto. Pero hablando con alguien sobre el voto por correo esta semana, me temo que este problema estß igualmente presente en este escenario actual no virtual. ┐C≤mo? Bueno; el voto por correo permite la coacci≤n de los votantes en la privacidad de los lugares de sondeo no p·blicos. Los votos electr≤nicos no son particularmente mßs subvertibles que los votos por correo, al menos en relaci≤n con la amenaza de la coacci≤n del votante. Es cierto que con el voto por correo hay una protecci≤n adicional. Parece ser que es posible a·n votar en persona en la sala electoral, y ese voto tiene prioridad sobre el voto por correo. Pero este mismo enfoque podrφa valer para los votos electr≤nicos, ┐no?. La gente coaccionada, o cuyo voto fuera comprado, podrφa a·n votar en el lugar p·blico y ese voto tendrφa prioridad. Asφ que la coacci≤n del votante me parece una minucia, sea el voto electr≤nico o no. _____________________________________________________________________ CriptoGRAMA es la versi≤n espa±ola de Crypto-GRAM, elaborada por el equipo de traductores de Kript≤polis, con autorizaci≤n expresa de Bruce Schneier. Este ejemplar nunca hubiera sido posible sin la colaboraci≤n desinteresada de las siguientes personas: * Isidre Marques Serret * Miguel Camacho * Angel Galindo Sßnchez * Juan Cruz Ruiz de Gauna * David G≤mez * Daniel Cabezas * Oscar Esteban _____________________________________________________________________ -- AVISO IMPORTANTE -- Kript≤polis dispone de la pertinente autorizaci≤n de Bruce Schneier para traducir, elaborar y publicar la versi≤n espa±ola de su boletφn Crypto-GRAM. La informaci≤n contenida en CriptoGRAMA s≤lo puede ser redistribuida siempre que se haga de forma completa y con expresa menci≤n de Bruce Schneier como autor de Crypto-GRAM y de Kript≤polis como responsable de CriptoGRAMA. Crypto-GRAM es un boletφn mensual gratuito dedicado a res·menes, anßlisis, comentarios e ideas sobre criptografφa y seguridad informßtica. Crypto-GRAM es elaborado por Bruce Schneier, presidente de Counterpane Systems, autor de "Applied Cryptography" y creador de los algoritmos Blowfish, Twofish y Yarrow. Schneier ha pertenecido a la direcci≤n de la International Association for Cryptologic Research, EPIC y VTW, y es asiduo escritor y conferenciante sobre criptografφa. _____________________________________________________________________ Versi≤n Web de este ejemplar: http://www.kriptopolis.com/criptograma/cg0019.html Este ejemplar se ha distribuido gratuitamente a mßs de 14.000 personas. Si desea recibir la edici≤n mensual de CriptoGrama y la edici≤n semanal del Boletφn de Kript≤polis, inscrφbase gratis en: http://www.kriptopolis.com/subs.html ⌐ Bruce Schneier ⌐ Kriptopolis (versi≤n en Espa±ol). _____________________________________________________________________