2000 << Back To criptograma nº 22

-----BEGIN PGP SIGNED MESSAGE----- _______________________________________________________________ C R I P T O G R A M A _______________________________________________________________ N·mero 22 15 de Febrero del 2000 ________________________________________________________________ SUMARIO: 1. Ataques distribuidos de denegaci≤n de servicio 2. Nuevas regulaciones sobre criptografφa en China 3. Noticias desde Counterpane 4. Publicar vulnerabilidades 5. Counterpane: investigaci≤n documentada 6. Noticias 7. El caso Mitnick da un nuevo giro a la criptografφa 8. En la ratonera: X.com 9. Cookies 10. Comentarios de los lectores -- Ejemplar gratuito distribuido a mßs de 18.000 suscriptores - -- ________________________________________________________________ * Suscripci≤n gratuita: http://www.kriptopolis.com/subs.html * N·meros anteriores: http://www.kriptopolis.com/criptograma/cg.html _______________________________________________________________ 1. Ataques distribuidos de denegaci≤n de servicio ================================================= Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mßs http://www.kriptopolis.com/criptograma/0022_1.html De repente, los ataques distribuidos de denegaci≤n de servicio (DSD) son una gran noticia. El a±o pasado se presentaron las primeras herramientas automßticas para estos ataques, y el CERT envi≤ un aviso en noviembre. Pero la ola de ataques importantes de mediados de febrero ha hecho que salten a las portadas de todos los peri≤dicos. No hay grandes novedades. Los ataques de denegaci≤n de servicio existen desde hace a±os. Los recientes ataques son lo mismo, s≤lo que esta vez no hay una ·nica fuente del ataque. TambiΘn hemos visto esto desde hace a±os. En primer lugar, el atacante se introduce en cientos o miles de distintos ordenadores inseguros (llamados "zombies") a travΘs de Internet e instala un programa de ataque. DespuΘs los coordina para que ataquen el objetivo al mismo tiempo. El objetivo recibe ataques de muy distintos lugares de un golpe; sus defensas tradicionales no sirven, y cae. Es muy similar al ataque del repartidor de pizzas: A Alice no le cae bien Bob, asφ que llama a un centenar de pizzerφas y encarga en cada una de ellas una pizza para que la lleven a la casa de Bob a las 11 de la noche. A las 11, en el portal de Bob hay cien repartidores de pizzas pidiendo su dinero. Bob se piensa que la mafia de la pizza va a por Θl, pero las pizzerφas tambiΘn son vφctimas. El atacante real permanece en la sombra. Esto parece un ataque complicado en Internet, y de hecho lo es. Pero por desgracia, s≤lo hace falta un programador con talento y poca Θtica para automatizar y distribuir los ataques. Una vez que se publica una herramienta DSD, el atacante no necesita tener ciertos conocimientos; puede utilizar una interfaz simple para infectar las mßquinas que lanzarßn el ataque y coordinarlo y lanzarlo. Esto es lo que es nuevo: herramientas DSD fßciles de utilizar, como Trin00 y Tribal Flood Network. Es increφblemente difφcil, si no imposible, defenderse de estos ataques. En un ataque de denegaci≤n de servicio tradicional, el ordenador vφctima puede acabar averiguando de d≤nde viene el ataque y cerrar la conexi≤n con el atacante. Pero en un ataque distribuido no hay una ·nica fuente. El ordenador deberφa cerrar todas las conexiones excepto aquellas en las que confφa, pero esto es in·til si se trata de un servidor de Internet. Otros sistemas de defensa tambiΘn tienen problemas. He visto propuestas de sistemas que fuerzan al cliente a realizar un cßlculo complicado para conectarse (RSA ha hecho un pre-anuncio de una "soluci≤n" de este tipo). Esto funciona con ataques de denegaci≤n de servicio tradicionales, pero no contra uno distribuido. El filtrado a gran escala en los proveedores de acceso a Internet podrφa ayudar, pero requiere un gran esfuerzo y reducirφa el ancho de banda de la Red notablemente. En al menos un informe se ha sugerido que se puede echar la culpa a la nula utilizaci≤n de autenticaci≤n en Internet. Esto no tiene sentido. Los paquetes causaron da±os simplemente por el intento de entregarlos; el que estuvieran o no autenticados es completamente irrelevante. La autenticaci≤n obligatoria no servirφa para prevenir estos ataques o para seguir el rastro de los atacantes. Ha habido dos conferencias acadΘmicas sobre los ataques DSD en las ·ltimas semanas, y el consenso general dice que no hay forma de defenderse de estos ataques. En algunos casos se pueden corregir los bugs concretos que se han aprovechado en los ataques DSD, pero hay muchos que no pueden corregirse. No se dise±≤ Internet para que pudiera hacer frente a ataques DSD. Seguir el rastro del atacante es tambiΘn increφblemente difφcil. Volviendo al ejemplo del repartidor de pizza, la ·nica cosa que puede hacer la vφctima es pedirle a las pizzerφas que le ayuden a coger al atacante. Si todas las pizzerφas compartieran la informaci≤n de sus registros de llamadas, quizßs podrφan averiguar quiΘn pidi≤ todas las pizzas. Se puede conseguir algo parecido en Internet, pero es poco probable que los ordenadores usados para el ataque conserven buenos logs. Ademßs, es fßcil ocultar la procedencia en Internet. Y si el atacante es de alg·n paφs del Este con pocas leyes sobre delitos informßticos, una policφa sobornable y ning·n tratado de extradici≤n, no se podrß hacer nada. Hasta ahora, estos ataques han sido tan s≤lo de denegaci≤n de servicio. No afectan a los datos de los servidores web. Con estos ataques no se puede obtener n·meros de tarjetas de crΘdito ni informaci≤n reservada. No se puede transferir dinero de su cuenta bancaria a la Bolsa en su nombre. Los atacantes no pueden obtener beneficios econ≤micos de estos ataques. Pero son muy serios. Y es ciertamente posible que un atacante use la denegaci≤n de servicio como herramienta para un ataque mßs complicado dise±ado para robar algo. Esto no quiere decir que los ataques de denegaci≤n de servicio no sean reales ni importantes. Para la mayorφa de las grandes empresas, el mayor riesgo de un agujero de seguridad es la pΘrdida de ingresos o prestigio, dos cosas que se pueden conseguir con un ataque de denegaci≤n de servicio que llame la atenci≤n. Y en el caso de compa±φas con datos crφticos, un ataque de denegaci≤n de servicio puede poner en peligro vidas de personas. El problema real es que hay cientos de miles, quizßs millones, de ingenuos usuarios de ordenadores que son vulnerables a estos ataques. Usan conexiones DSL o por cable, siempre estßn conectados a Internet con direcciones IP estßticas, y sus equipos se pueden utilizar para lanzar ataques como estos, o de otros tipos. Los medios se centran en las grandes corporaciones del mundo electr≤nico que estßn siendo atacadas, pero el asunto verdaderamente importante se centra en los sistemas individuales. Asimismo, las verdaderas soluciones pasan por la "higiene cφvica". Al igual que se erradic≤ la malaria de Washington, DC al secar todos los pantanos, la ·nica forma real de prevenir estos ataques serφa proteger esos millones de ordenadores individuales que se conectan a Internet. Por desgracia, estamos creando pantanos con una rapidez increφble, y hacer que todo sea seguro es imposible. Incluso aunque los firewalls personales tuvieran una penetraci≤n de mercado del 95%, e incluso aunque estuvieran todos instalados y funcionando a la perfecci≤n, todavφa habrφa suficientes equipos desprotegios en Internet que se podrφan usar para estos ataques. Creo que cualquier soluci≤n a largo plazo implicarß redise±ar por completo Internet. En los '60, alguna gente descubri≤ que se podφa silbar, hacer chasquidos y otros ruidos en un telΘfono y conseguir que el sistema hiciera cosas. Fue la era del phreaking: cajas negras, cajas azules, silbatos del Capitßn Crunch. Las compa±φas telef≤nicas se esforzaron al mßximo para defenderse de estos ataques, pero el problema bßsico era que el sistema telef≤nico estaba construido empleando "se±alizaci≤n en banda": la se±al de control y la de datos viajaban por los mismos cables. En los '80, las compa±φas telef≤nicas redise±aron completamente sus sistemas. Por ejemplo, se cre≤ SS7, Sistema de Se±alizaci≤n 7, que trabajaba fuera de banda. Se separaron los cables de voz y los de datos. Ahora ya no importa lo fuerte que se le silbe al telΘfono: el conmutador no estß escuchando. Los ataques no funcionan. (las cajas rojas todavφa funcionan en las cabinas telef≤nicas, imitando los tonos en banda que cuentan las monedas que se han echado). A largo plazo, la se±alizaci≤n fuera de banda es la ·nica forma de enfrentarse a muchas de las vulnerabilidades de Internet, entre otras los DSD. Por desgracia, no hay planes destinados a redise±ar Internet en este sentido, y un plan asφ podrφa ser demasiado complicado como para siquiera considerarlo. Estudio de los ataques DSD: http://staff.washington.edu/dittrich/talks/cert/ Aviso del CERT: http://www.cert.org/incident_notes/IN-99-07.html Herramienta para comprobar si Tribal Flood Network o Trin00 estßn instalados en tu ordenador: http://www.nfr.net/updates/ Tutorial sobre ataques de denegaci≤n de servicio: http://www.hackernews.com/bufferoverflow /00/dosattack/dosattack.html Anßlisis de Trin00: http://staff.washington.edu/dittrich/misc/trinoo.analysis Anßlisis de Tribal Flood Network: http://staff.washington.edu/dittrich/misc/tfn.analysis Anßlisis de Stacheldraht: http://staff.washington.edu/dittrich/ misc/stacheldraht.analysis Ensayo sobre el tema de Declan McCullagh: http://www.wired.com/news/ politics/0,1283,34294,00.html 2. Nuevas regulaciones sobre criptografφa en China ================================================== Traducido por Sergio Pozo Hidalgo http://www.kriptopolis.com/criptograma/0022_2.html Argumentando que estßn intentando prevenir el robo de secretos de estado, China ha instaurado algunos controles estrictos sobre criptografφa en Internet. Primero, todo aquel que use cifrado tiene que registrarse en el gobierno y darle los detalles de quΘ software estß usando y el algoritmo, nombres de usuarios, direcciones de e-mail y localizaci≤n de sus ordenadores. Segundo, las compa±φas chinas tienen prohibido comprar productos que contengan software de cifrado que haya sido dise±ado en el extranjero. (Por tanto, si una compa±φa de los EEUU quiere vender cifrado en su producto, necesita retirar todo lo que incluya ahora mismo e instalar algo hecho en China.) Esto es extra±o, y tengo algunas observaciones. Una, China tiene probablemente miedo de que los productos de seguridad extranjeros tengan puertas traseras. Esto es posible, y algo que los EEUU han hecho anteriormente. Pero no veo c≤mo reforzar los requisitos en los algoritmos de cifrado puede ayudar aquφ. Las puertas traseras suelen ser mucho mßs sutiles que un algoritmo de cifrado roto. Dos, esto podrφa fßcilmente ser un preludio de dep≤sito de claves. Ciertamente, el primer paso hacia obligar a la gente dar una copia de sus llaves de cifrado al Gobierno es averiguar quiΘn estß usando cifrado y de quΘ tipo. Tres, incluso por sφ misma, esta informaci≤n es ·til para el espionaje chino. El anßlisis de trßfico es un problema muy difφcil, y conocer quiΘn estß usando software de cifrado (y d≤nde estß fφsicamente localizado) hace mucho mßs fßcil saber a quiΘn espiar. Gente con mucha mßs pericia polφtica que yo, ha dicho que esto no es realmente nada. China ya exigi≤ que todas las mßquinas de fax fueran registradas hace una dΘcada, y muchos no se preocuparon de obedecer. http://www.wired.com/news/print/0,1294,33910,00.html http://www.usatoday.com/life/cyber/tech/cth217.htm http://www.currents.net/newstoday/00/01/27/news6.html 3. Noticias desde Counterpane =================================== Traducido por Sergio Pozo Hidalgo http://www.kriptopolis.com/criptograma/0022_3.html Mucho entusiasmo; todavφa mucha discrecci≤n. Somos mßs de 45 empleados y seguimos creciendo. Si alguien sabe de alg·n buen responsable de Marketing al que le gustarφa cambiar a San Jose, pongßle en contacto conmigo. La Web de Counterpane tiene un nuevo aspecto. Visφtela: http://www.counterpane.com Bruce Schneier hablarß en el PC Forum, el 15 de Marzo: http://www.edventure.com/PC2000/ 4. Publicar vulnerabilidades =============================================== Traducido por Juan Cruz Ruiz de Gauna Gorostiza http://www.kriptopolis.com/criptograma/0022_4.html El mes pasado hablΘ de ataques publicitarios, y de la tendencia de los vendedores a exhibir a bombo y platillo vulnerabilidades de seguridad como publicidad para sus productos y servicios. Mi trabajo gener≤ muchos comentarios (mirar al final de este artφculo algunas URLs). Este es un tema complicado, con ßreas grises, zonas resbalosas y mucho espacio para la discusi≤n. Mi posici≤n ha ido cambiando a lo largo del tiempo. Me gustarφa revisarla. Realmente aquφ hay dos cuestiones entrelazadas. Si alguien descubre una vulnerabilidad en un producto, ┐deberφa alertar silenciosamente al vendedor o deberφa hacerla p·blica? y ┐Cußndo una vulnerabilidad es importante y cußndo es trivial?. La primera cuesti≤n implica cierta historia. En 1988, El gusano Morris mostr≤ lo susceptible a ataques que es Internet. La Agencia de Proyectos Avanzados de Investigaci≤n de Defensa (DARPA) fund≤ un grupo para coordinar las respuestas a este tipo de ataques, incrementar la concienciaci≤n respecto a la seguridad y, en general, mejorar la seguridad de Internet. El grupo es conocido como CERT -- o mßs formalmente El Equipo de de Respuesta ante Emergencias Informßticas (Computer Emergency Response Team) -- y su centro de respuesta estß en la Universidad Carnegie Mellon en Pittsburgh. A lo largo de los a±os ha servido como una especie de centro de intercambio de informaci≤n para vulnerabilidades de seguridad. Se espera que la gente envφe a CERT las vulnerabilidades que descubren. CERT verifica que la vulnerabilidad es cierta, advierte discretamente al vendedor y publica los detalles (y la soluci≤n) una vez que el vendedor haya eliminado dicha vulnerabilidad. Esto suena muy bien en teorφa, pero no funciona tan bien en la prßctica. Hay tres quejas principales. Primera, a CERT se envφan muchas vulnerabilidades y hay quejas respecto a la lentitud de CERT a la hora de verificar dichas vulnerabilidades. Segunda, los vendedores son lentos a la hora de solucionar estas vulnerabilidades una vez que CERT se las comunica. Como CERT no publicarß nada hasta que exista una soluci≤n no hay una urgencia real para solucionar nada. Y tercera, CERT es lenta a la hora de publicar informes uncluso despuΘs de que las soluciones hayan sido implementadas. El movimiento "revelaci≤n total" naci≤ a causa de la frustraci≤n de este proceso. Las listas de Internet como Bugtraq (iniciada en 1993) y NT Bugtraq (iniciada en 1997) se han convertido en forums para la gente que cree que el ·nico camino para mejorar la seguridad es entender y hacer p·blicos los problemas. Esto fue una reacci≤n contra la actitud de torre de marfil de CERT. Como escribi≤ un hacker: "Los detalles de problemas de seguridad ya no estarßn limitados a listas de correo cerradas de esos llamados expertos en seguridad o detallados largamente en recargados documentos acadΘmicos. Por el contrario, la informaci≤n se harß disponible a las masas para que hagan con ella lo que les parezca mejor". Hoy dφa, muchos investigadores publican en estas listas de correo vulnerabilidades que han descubierto, a veces acompa±adas por informaciones de prensa y el tφpico chaparr≤n de sucesos. La prensa analiza estas listas de correo y escribe sobre las vulnerabilidades en las revistas de informßtica: tanto en las de papel como en las disponibles en lφnea. (Este es el motivo por el que ha habido tantas historias en prensa acerca de vulnerabilidades informßticas en los ·ltimos a±os). Los vendedores se apresuran a corregir estas vulnerabilidades tan pronto como son hechas p·blicas, de tal forma que ellos mismos puedan escribir sus propias noticias de prensa sobre lo rßpida y concienzudamente que arreglan las cosas. El movimiento revelaci≤n total estß mejorando la seguridad en Internet. Al mismo tiempo, los hackers utilizan estas listas de correo para aprender sobre estas vulnerabilidades y escribir programas de ataque (llamados "exploits"). Algunas veces los propios investigadores escriben sus propios programas "exploits" de demostraci≤n. Algunas veces lo hacen otros. Algunos de estos ataques son complicados; pero tan pronto como alguien escribe un exploit del estilo "apuntar y hacer clic", cualquiera puede explotar la vulnerabilidad. Aquellos que estßn en contra del movimiento revelaci≤n total argumentan que hacer p·blicos detalles de vulnerabilidades hace mßs da±o que bien, al ofrecer a los hackers criminales herramientas que pueden usar para romper sistemas. Se sirve mejor a la seguridad, seg·n dicen ellos, no publicando las vulnerabilidades con todos los detalles. Los defensores de la revelaci≤n total argumentan que esto asume que el investigador que publicita la vulnerabildiad es el primero en descubrirla, lo que simplemente no es cierto. A veces, las vulnerabilidades son conocidas por los atacantes (a veces transmitidas discretamente en los ambientes de hackers) durante meses o a±os antes de que el vendedor pueda localizarla. Cuanto antes sea publicada y corregida una vulnerabilidad, mejor para todos. Este es el debate en pocas palabras: ┐El beneficio de publicitar un ataque vale la pena frente a la creciente amenaza de un enemigo aprendiendo sobre ese ataque? (En el lenguaje de la comunidad de inteligencia esto se conoce como el "asunto de la equidad"). Si las vulnerabilidades no se publican, entonces los vendedores serßn lentos en solucionarlas (o incluso puede que no se ocupen de ello). Pero si las vulnerabilidades son hechas p·blicas, entonces los hackers escriben "exploits" para aprovecharse de ellas. En general yo estoy a favor del movimiento de revelaci≤n total, y creo que ha hecho mucho mßs para aumentar la seguridad que para disminuirla. Dar publicidad a una vulnerabilidad no hace que aparezca; de hecho existφa antes de haber sido hecha p·blica. Dando por hecho que la mayor parte de los vendedores no se preocuparφan en solucionar vulnerabilidades que no fuesen publicadas, el hacerlas p·blicas es el primer paso para ir eliminßndolas. Castigar al que las hace p·blicas se parece bastante a matar al mensajero; la autΘntica culpa es del vendedor que ha puesto en circulaci≤n un software que tenφa dicha vulnerabilidad. El segundo asunto -el que mßs polΘmica ha generado durante el ·ltimo mes- implica la agenda del investigador. Publicar una vulnerabilidad de seguridad es entrar en juego en busca de publicidad; el investigador busca que su nombre aparezca en la prensa al atrapando exitosamente a su presa. El publicista a menudo tiene su propio orden del dφa: es un consultor de seguridad, o un empleado de una compa±φa que ofrece servicios o productos de seguridad. Esto suele ser cierto especialmente cuando la vulnerabilidad se publica en una informaci≤n de prensa. Servicios como "PR NewsWire" y "Business NewsWire" son caros y nadie los utilizarφa si no esperase obtener algo a cambio. Todos los investigadores son culpables de cortejar a la publicidad. Yo soy culpable de ello. Fue divertido cuando mi ruptura del protocolo PPTP (Point to Point Tuneling Protocol) de Microsoft salt≤ a la prensa. Llamar al protocolo "criptografφa de guarderφa" fue un abucheo por mi parte. Por otro lado, yo puse objeciones sobre la publicaci≤n el mes pasado del ataque de b·squeda de clave de nCipher. Las diferencias son sutiles y hay mucha zona gris, pero aquφ estßn mis reglas. Primera, me opongo a los ataques que fundamentalmente siembran temor. Publicar vulnerabilidades sobre las que no hay evidencia real es malo. Publicar vulnerabilidades que son mßs humo que fuego es malo. Publicar vulnerabilidades en sistemas crφticos para las que no existe una soluci≤n sencilla y cuya explotaci≤n puede provocar da±os importantes (Por ejemplo el sistema de control de trßfico aereo) es malo. Segunda, yo creo en dar primero la noticia al vendedor. CERT ha llevado esto al extremo, dando a veces al vendedor a±os para solucionar el problema. A mφ me gustarφa que los investigadores dijeran al vendedor que publicarßn la vulnerabilidad en un mes o en tres semanas (no serφa justo dar al vendedor s≤lo siete dφas para solucionar el problema). Con suerte el anuncio de la vulnerabilidad podrφa coincidir al mismo tiempo que el anuncio del parche que la corrija. Esto beneficiarφa a todos. (Lo admito, yo no hice esto con el PPTP de Microsoft). Tercera, yo creo que es irresponsable, y probablemente criminal, distribuir "exploits". La ingenierφa inversa de sistemas de seguridad, para descubrir vulnerabilidades y escribir documentos de investigaci≤n sobre ellas beneficia a la investigaci≤n; nos hace mßs inteligentes a la hora de dise±ar sistemas seguros. Distribuir "exploits" s≤lo nos hace mßs vulnerables. Por ejemplo, Mixter es un hacker alemßn que escribi≤ la herramienta Tribal Flood Network (Inundaci≤n Tribal de Red), usada en algunos de los ataques de denegaci≤n de servicio. Yo creo que esta persona tiene mucho de lo que responder. Su herramienta de ataque no ha servido para nada bueno. Sirvi≤ a los criminales y cost≤ a muchas compa±φas un mont≤n de dinero. Su existencia hace las redes menos seguras. No hay una frontera clara: hay herramientas que hacen tanto cosas buenas como malas. Las herramientas de evaluaci≤n de vulnerabilidades pueden ser usadas para incrementar la seguridad, pero tambiΘn para romper sistemas. Las herramientas de administraci≤n remota se parecen mucho a Back Orifice. Publicar las herramientas tambiΘn puede ayudar; Microsoft ha mentido a la prensa y ha negado la existencia de una vulnerabilidad publicada hasta que ha aparecido un programa que explotaba dicha vulnerabilidad. A mφ me gusta la premisa de Marcus Ranum "Ser parte de la soluci≤n, no parte del problema". El movimiento de revelaci≤n total es parte de la soluci≤n. Convencer a los vendedores para solucionar los problemas es parte de la soluci≤n. Sembrar temor es parte del problema. Dar armas informßticas a adolescentes sin conocimientos es parte del problema. Estas son mis opiniones; han cambiado a lo largo del tiempo, y probablemente a·n vuelvan a cambiar. Yo lleguΘ a este campo a travΘs de la criptografφa. La criptografφa es por naturaleza un campo de confrontaci≤n, incluso en las torres de marfil acadΘmicas. Alguien propone un nuevo esquema: un algoritmo, un protocolo, una tΘcnica. Alguna otra persona lo rompe. Una tercera persona soluciona dicha ruptura. Y asφ continuamente. Es parte de la diversi≤n, y asφ es como yo aprendφ. Yo lleguΘ al campo de la seguridad de la red con esta filosofφa. Pero cuando se aplica a sistemas de producci≤n esto puede tener muchas mßs trampas. Publicar vulnerabilidades puede producir un da±o significante a las redes, y un considerable dolor y sufrimiento a los administradores de redes. Si un anuncio, producto o "exploit" hace que las cosas empeoren, entonces es malo. Si hace que las cosas mejoren, entonces es bueno. Mi trabajo original: http://www.counterpane.com/crypto-gram-0001.html# KeyFindingAttacksandPublicityAttacks Una respuesta: http://www.securityfocus.com/templates/forum_message.html? forum=2&head=754%20&id=754 Una respuesta a esta respuesta: http://www.securityfocus.com/templates/forum_message.html? forum=2&head=754%20&id=789 El debate en SlashDot: http://slashdot.org/articles/00/01/17/0839211.shtml Trabajo de Marcus Ranum sobre el tema: http://www.clark.net/pub/mjr/pubs/dark/ Ver tambiΘn los comentarios de los lectores de este mismo n·mero. 5. Counterpane: Investigaci≤n documentada ========================================= Traducido por Sergio Pozo Hidalgo http://www.kriptopolis.com/criptograma/0022_5.html "Una retractaci≤n en Twofish: ataques de claves relacionadas contra Twofish de ciclo reducido" (Niels Ferguson, John Kelsey, Bruce Schneier, Doug Whiting) El documento de candidatura de Twofish al AES contiene un ataque parcial de clave escogida y un ataque de clave relacionada contra Twofish de diez vueltas sin blanqueo, usando llaves de 256-bit. Este ataque no funciona; hace uso de un tipo conocido de pares de claves dΘbiles en que coinciden las claves de las cajas-S con claves de ocho vueltas sucesivas, pero tales pares no existen. En este informe analizamos las apariciones de este tipo de par de clave dΘbil y describimos c≤mo estos pares pueden ser utilizados tanto para realizar ataques sobre Twofish de ciclo reducido, como para encontrar propiedades de Twofish de ciclo reducido que no estßn presentes en un cifrador ideal. Encontramos que los ataques de clave relacionada y clave escogida son considerablemente menos potentes frente a Twofish de lo que antes se pensaba. http://www.counterpane.com/twofish-related.html 6. Noticias =========================== Traducido por Antonio Sanz http://www.kriptopolis.com/criptograma/0022_6.html * Una de las cosas mßs agradables de vivir en Minneapolis: http://www.ag.state.mn.us/home/files/news/pr_conspriv_011300.html * El GHCQ (el equivalente britßnico a la NSA) estß buscando reclutas. Haz la prueba en su pßgina Web: http://www.gchq.gov.uk/ * Varios sabihondos han dicho que el gobierno todavφa estarß ganando la batalla de la criptografφa mientras Windows se distribuya sin criptografφa fuerte. ┐Y sabe quΘ? Microsoft ha dicho que publicarß el Windows 2000 en todo el mundo con criptografφa fuerte: http://www.wired.com/news/technology/0,1282,33745,00.html * Una mßquina que emplea tΘcnicas de fuerza bruta para abrir cerraduras de combinaci≤n: http://vv.carleton.ca/~neil/robotics/locraker.html * ┐Contratarφa hackers?. Un poco de cinismo para con la declaraci≤n de @stake, la consultora del grupo hacker LOpht: http://www.zdnet.com/enterprise/stories/security/news/0,7922,2420340,0 .html * Por quΘ fallan las polφticas de seguridad: http://www.cdc.com/solutions/whitepapers/Why_Security_Policies_Fail.pd * Otro ataque distribuφdo contra un cifrado de 56 bits llamado CS-Cipher. En este caso tard≤ 62 dφas en 38.000 mßquinas, y result≤ requerir la b·squeda del 98% del espacio de claves: http://www.wired.com/news/print/0,1294,33695,00.html * Un interesante artφculo acerca de lo fßcil que es hackear pßginas Web: http://www.pcworld.com/current_issue/article/0,1212,14415,00.html * La NSA ha formalizado un contrato con Secure Computing Corp. para realizar una versi≤n segura de Linux. No sΘ si la licencia de Linux le permite a la NSA hacer una versi≤n segura del sistema operativo, si luego no distribuyen libremente los resultados: http://www.fcw.com/fcw/articles/web-nsalinux-01-17-00.asp * El gobierno de los EE.UU. y el crimen cibernΘtico: http://www.currents.net/newstoday/00/01/17/news4.html http://www.fcw.com/fcw/articles/web-fbi-01-14-00.asp http://www.computerworld.com/home/print.nsf/all/000111DBFE http://washingtonpost.com/wp-srv/business/feed/a39572-2000jan13.htm * Las nuevas normas de exportaci≤n y el caso Bernstein: http://www.wired.com/news/print/0,1294,33651,00.html * Ir≤nicamente, las nuevas regulaciones de los EE.UU. con respecto a la criptografφa beneficiarßn a las agencias federales: http://www.fcw.com/fcw/articles/web-export-01-14-00.asp * Otros comentarios sobre las nuevas reglas en criptografφa: http://www.computerworld.com/home/print.nsf/all/000113DD42 http://www.usatoday.com/life/cyber/tech/cth136.htm * Un nuevo servicio que monitoriza la emisora de radio que se estß escuchando: http://www.wired.com/news/technology/0,1282,33799,00.html?tw=wn2000012 * Windows 2000 ya tiene su primer virus: http://www.computerworld.com/home/print.nsf/all/000113DD52 y sus primeros agujeros de seguridad: http://dailynews.yahoo.com/h/zd/20000130/tc/20000130748.html Recuerde, todavφa no ha sido presentado... * No soy el ·nico que piensa que votar por Internet es una idea est·pida. El "Grupo de Trabajo para el Voto por Internet de California" estß de acuerdo: http://www.ss.ca.gov/executive/ivote/ * Esta es la historia de fraude con tarjetas de crΘdito mßs hßbil que he visto en mucho tiempo: http://www.zdnet.com/zdnn/stories/news/0,4586,2427490,00.html?chkpt=zd pnews01 * Mßs informaci≤n acerca del hack de la tarjetas inteligentes francesas: http://www.msnbc.com/news/361936.asp http://www.theregister.co.uk/000123-000005.html http://www.parodie.com/english/smartcard.htm * Alguien estß demandando a Yahoo por violar la ley anti-vigilancia de Texas al usar cookies para rastrear cada movimiento de los usuarios sin su consentimiento: http://news.cnet.com/category/0-1005-200-1533164.html * Twofish para AS/400: http://www.news400.com/features/newmf/Article.cfm?ArticleID=13333 * Alerta "aceite de serpiente" : recuerde, es posible -aunque poco probable - que sea tan bueno como el departamento de Relaciones P·blicas de NEC afirma. Pero llevarß a±os averiguarlo. http://www.theregister.co.uk/000127-000025.html http://www.cnn.com/2000/TECH/computing/01/24/nec.strong.encrypt/index. tml * Buenos res·menes de la rotura del DVD y el deCSS. Un razonamiento importante es que los DVDs pueden ser copiados y pirateados sin usar deCSS ni cualquier otro tipo de descifrado, lo que ciertamente hace que las demandas originales de "prevenci≤n de la piraterφa" parezcan tremendamente ignorantes o descaradamente enga±osas: http://www.fool.com/portfolios/rulemaker/rulemaker000127.htm http://www.latimes.com/news/comment/20000207/t000012301.html http://linuxtoday.com/stories/16556.html * Documentos recientemente desclasificados de la NSA. El 9 y el 12 mencionan a ECHELON: http://www.gwu.edu/~nsarchiv/NSAEBB/NSAEBB23/index2.html Informaci≤n general: http://www.gwu.edu/~nsarchiv/NSAEBB/NSAEBB23/index.html * De merecida lectura. El testimonio de EPIC sobre la protecci≤n de la infraestructura digital: http://www.epic.org/security/EPIC_testimony_0200.pdf * La Casa Blanca aprueba la legislaci≤n sobre la firma digital: http://www.cnn.com/2000/TECH/computing/01/31/esignatures/ * Francia demanda a los EE.UU. e Inglaterra por ECHELON: http://www.the-times.co.uk/news/pages/tim/2000/02/10/timfgneur01007.ht l?999 * El antiguo director de la CIA John Deutch se llev≤ a casa informaci≤n clasificada en su portßtil desprotegido: http://www.fcw.com/fcw/articles/2000/0131/web-security-02-04-00.asp http://www.wired.com/news/print/0,1294,34105,00.html * Nuevas vulnerabilidades del comercio electr≤nico. Algunos programas de "carrito de la compra" permiten a los compradores alterar formularios HTML y URLs para cambiar los precios de los artφculos que compran: http://www.computerworld.com/home/print.nsf/all/000202E636 http://www.usatoday.com/life/cyber/nb/nb2.htm http://www.theregister.co.uk/000203-000006.html 7. El caso Mitnick da un nuevo giro a la criptografφa ===================================================== Traducido por Isidre MarquΘs Serret http://www.kriptopolis.com/criptograma/0022_7.html Cuando Kevin Mitnick fue capturado, los agentes federales requisaron dos de sus ordenadores portßtiles. Muchos de los archivos en esos ordenadores estaban cifrados. Durante los procedimientos previos al juicio, la fiscalφa se neg≤ a dar a la defensa copias de los archivos cifrados, a menos que Mitnick les diera la clave. La defensa arguy≤ que la Constituci≤n le exigφa al gobierno que presentara cualquier documento que pudiera ayudar a la defensa de Mitnick. La fiscalφa dijo que puesto que no tenφan ninguna idea de lo que habφa en los archivos, estos podrφan ser potencialmente peligrosos. Desgraciadamente, el juez estuvo de acuerdo con la fiscalφa. http://www.nytimes.com/library/tech/00/01/cyber/cyberlaw/28law.html 8. En la ratonera: X.com ==================================== Traducido por Isidre MarquΘs Serret http://www.kriptopolis.com/criptograma/0022_8.html Un banco donde usted puede retirar dinero no s≤lo de su cuenta, sino de cualquier otra. Mi cita favorita del CEO de X.com: "No creo que se cometiera un error." Por desgracia, le creo. http://www.zdnet.com/zdnn/stories/news/0,4586,2429999,00.html http://www.currents.net/newstoday/00/01/31/news4.html http://www.nytimes.com/library/tech/00/01/biztech/articles/28secure.ht l 9. Cookies ==================================== Traducido por Isidre MarquΘs Serret http://www.kriptopolis.com/criptograma/0022_9.html Las cookies son un hßbil truco de programaci≤n incluido en los navegadores de Internet. Bßsicamente, una cookie es un peque±o archivo de datos que el servidor WEB da al navegador. El navegador guarda los datos en el ordenador del usuario, y los devuelve al servidor siempre que vuelve allφ. Las cookies pueden hacer toda clase de cosas ·tiles y buenas. Desgraciadamente, tambiΘn pueden hacer toda clase de cosas malas. Primero explicarΘ c≤mo trabajan; luego hablarΘ sobre los problemas. Internet es bßsicamente un protocolo sin memoria. Esto significa que el servidor no recuerda quiΘnes somos de un click al siguiente. Todo lo que el servidor hace es mostrar pßginas WEB. Un navegador pide una pßgina WEB, el servidor se la muestra. El servidor no tiene ni idea de si es el mismo navegador que antes o uno diferente, ni le preocupa. Esto funciona perfectamente para pßginas WEB simples y estßticas que ·nicamente contienen pßginas informativas. Las pßginas WEB mßs complejas son dinßmicas. Las pßginas WEB comerciales a menudo tienen carros de compra que viajan con usted cuando las hojea. Las pßginas WEB de pago necesitan nombres de usuario y contrase±as que deben viajar con usted cuando las recorre. (Encontrarφa molesto tener que teclear mi nombre de usuario y contrase±a cada vez quisiera ver otro artφculo del New York Times.) Las cookies son una forma de manejar esto. Recuerde que los protocolos de Internet no tienen memoria; no hay nada que le permita al servidor recordar quiΘn es usted de una pulsaci≤n del rat≤n a la siguiente. Dando una cookie al navegador y pidiΘndosela luego, el servidor puede recordar quiΘn es usted. "Oh sφ, usted es el usuario 12345657; este es su carro de la compra." Las cookies permiten el navegador agregar memoria a los protocolos de Internet. Usted puede pensar en ellas como un gran banco de datos distribuido, con informaci≤n guardada en millones de navegadores a lo largo del mundo de los usuarios. Hasta ahora todo es bueno. Y mayoritariamente las cookies son buenas, si el servidor que usa la cookie trabaja de acuerdo con las reglas. El servidor puede establecer cußnto tiempo dura la cookie antes de expirar: unos dφas parece suficiente. Un servidor puede poner restricciones ante quiΘn puede acceder a la cookie. Normalmente se limita el acceso a los servidores en el mismo dominio; esto significa que si su cookie viene de azar-merchant.com, s≤lo azar-merchant.com puede acceder la cookie. Los problemas vienen cuando se abusa de ellas. Algunos servidores usan cookies para rastrear a los usuarios de sitio en sitio, y alguno las usa para descubrir la identidad del usuario. He aquφ un ejemplo fßcil: hay compa±φas que revenden espacio de publicidad en servidores populares. DoubleClick es una de esas compa±φas; a menudo los anuncios que usted ve los ha puesto DoubleClick de acuerdo con los propietarios de la pßgina. Si estß navegando por sex-site.com, va a ver algunas partes de la ventana que vienen de DoubleClick.com. DoubleClick.com le da una cookie. DespuΘs (ese dφa, o quizß otro dφa), cuando usted estß navegando por CDNow.com, podrφa haber otro anuncio puesto por DoubleClick. DoubleClick puede pedir la cookie de su navegador y, como la cookie dice que fue creada mientras usted estaba visitando una pßgina de sexo, le envφa anuncios enfocados mientras usted estß navegando por CDNow. Como DoubleClick estß en una gran cantidad de pßginas comerciales, sus cookies pueden usarse para rastrearle por todos esas pßginas. Aun peor, si usted teclea su direcci≤n de e-mail en cualquiera de esas pßginas y DoubleClick la consigue, puede unir una direcci≤n de e-mail a sus hßbitos de navegaci≤n. Todos lo que se necesita para hacerlo es que usted teclee esa direcci≤n una ·nica vez -es decir, que pida s≤lo una cosa- y la tiene para siempre. (O, hasta que esa cookie haya expirado, que pueden ser a±os.) DoubleClick admite abiertamente que recoge datos y usa esos datos para mostrar anuncios concretos a los usuarios, pero hasta hace poco neg≤ estar creando un banco de datos de identidad. Hace dos semanas, USA Today descubri≤ su doblez. Desde entonces han admitido que intentan recoger nombres y relacionar las cookies con identidades reales. Las implicaciones para la privacidad de la navegaci≤n por Internet son profundas. Aun hay mßs. Los servidores pueden enviarle una cookie por e-mail que pueden utilizar para identificarlo si usted visita mßs tarde la pßgina con su navegador. Asφ es c≤mo funciona: el servidor le envφa un mensaje de e-mail en formato HTML. (Esto implica que usted estß utilizando un programa de e-mail que admite mensajes en formato HTML, como Microsoft Outlook y Outlook Expres, Messenger de Netscape, o Eudora.) El mensaje contiene un enlace a un grßfico que el servidor puede utilizar para enviarle una cookie. Ahora, cuando usted visita el servidor alg·n tiempo mßs tarde, el servidor puede utilizar la cookie para relacionar la navegaci≤n con el e-mail, y la direcci≤n de e-mail. Supuestamente este mΘtodo ha sido utilizado por algunos servidores para rastrear a los navegantes en Internet. Algunas las cosas que las cookies no pueden hacer: no pueden robar informaci≤n de su ordenador. Una cookie simplemente es un conjunto de datos que el servidor entrega al navegador, y este devuelve mßs tarde. Una cookie no puede conseguir sus contrase±as o archivos. (ActiveX, Java, y JavaScript son mucho mßs peligrosos en este aspecto.) Las cookies no pueden robar sus n·meros de tarjeta de crΘdito. La lecci≤n aquφ es que las cookies no son malas, pero hay algunos usos de ellas muy malΘvolos. En la mayorφa de los navegadores hay alguna forma de anular completamente las cookies, y programas de otros fabricantes que ayudan a controlarlas mejor. Controlarlas es una soluci≤n mejor, puesto que algunos sitios de Internet niegan el acceso a las personas que no aceptan cookies. ôElige marcharte de DoubleClickö. No pueden conservar tu informaci≤n personal si t· se lo prohibes. HAZLO AHORA. http://www.cdt.org/action/doubleclick.shtml Programas para bloquear las cookies: http://www.junkbusters.com/ht/en/cookies.html http://www.ecst.csuchico.edu/~atman/spam/adblock.shtml Navegaci≤n an≤nima en Internet: http://www.zeroknowledge.com Historias sobre la doblez de DoubleClick: http://www.usatoday.com/life/cyber/tech/cth211.htm http://www.hackernews.com/arch.html?012600#1 http://news.cnet.com/news/0-1005-200-1531929.html?dtn.head Pleito contra DoubleClick: http://www.wired.com/news/print/0,1294,33964,00.html Testimonio de CDT sobre la recogida de datos durante la navegaci≤n: http://www.cdt.org/testimony/ftc/mulliganFTC.11.30.99.shtml 10. Comentarios de los lectores =============================== http://www.kriptopolis.com/criptograma/0022_10.html De: Andrew D. Fernandes (andrew@cryptonym.com) Asunto: Ataques publicitarios Traducido por David G≤mez ---------------------------------------------- Tengo un par de comentarios en relaci≤n a tu articulo sobre "ataques publicitarios" en el Criptograma de Enero. Primero, insinuaste que mi compa±φa, Cryptonym, siendo un distribuidor PKI, de alguna manera se habφa beneficiado publicando el asunto Microsoft/NSA. De hecho, no hicimos ni un solo penique a partir de la informaci≤n. Rayos, yo no podrφa venderles nada aunque quisiera. Estamos como poco a un a±o de lanzar cualquier tipo de productos -productos que serßn totalmente de c≤digo abierto- y s≤lo aceptamos una cantidad muy limitada de consultorφas. Pensßbamos que estßbamos adoptando la "Decisi≤n Correcta" publicando el hecho de que todas las compa±φas estadounidenses que querφan exportar software criptogrßfico tenφan que relacionarse de alguna manera con la NSA. No fue nunca nuestra intenci≤n hacer dinero con nuestro descubrimiento y, pasado el tiempo, no lo hemos hecho. Segundo, discutes los ataques publicitarios. Aparentemente, no podemos confiar en nCipher o en eEye para discutir la seguridad porque venden productos de seguridad y consultorφa. De hecho, al final del Criptograma hay una nota indicando que deberφamos ser cautos ante las afirmaciones sobre curvas elφpticas hechas por Alfred Menezes, ya que Θl tiene intereses financieros en Certicom. Creo que eso ya es ir demasiado lejos. Sφ, quizas nCipher y eEye (y quizßs incluso Cryptonym) hicieron un mal trabajo haciendo publicidad de los agujeros de seguridad. Quizas Alfred quiera enga±ar a todo el mundo acerca de la seguridad de las curvas elφpticas para su vil beneficio. íSed realistas! Todo el mundo en este campo -incluyΘndote a ti y a Counterpane- tiene fuertes vφnculos monetarios con la industria, por lo tanto todo lo que digan todos tiene que ser puesto en su contexto. Estos lazos financieros no significan que el aviso de una compa±ia o extractos de prensa no puedan ser fiables. Seguir un consejo acerca de la criptografφa no es diferente de seguir el consejo de tu abogado. Tendrßs que saber c≤mo tu abogado se beneficiarß de que t· sigas sus consejos. Pero pienso que es presuntuoso dar a entender que carecemos de integridad profesional si estßs en desacuerdo con nosotros. Por ejemplo, ┐por quΘ estßis vosotros aconsejando a la gente usar RSA en vez de ECC (Curvas Elφpticas)? ┐Por quΘ no ElGamal o autenticaci≤n Diffie-Hellman? DespuΘs de todo, RSA estß patentado, mientras ElGamal y ADH no lo estßn... íEspera! ┐Tiene Counterpane acciones de RSA? ┐Podrφa Counterpane hacer dinero advirtiendo a la gente de que las ECC no son tan buenas como RSA? Ciertamente espero que no. No estoy de acuerdo con vuestro consejo sobre ECC contra RSA (y tampoco lo estß Alfred Menezes). Sin embargo, creo en tu integridad profesional y en la de tu compa±φa. De: Geoff Thorpe (geoff@eu.c2.net) Asunto: Ataque de b·squeda de claves de nCypher Traducido por Oscar Esteban ----------------------------------------------- Me result≤ interesante leer tus pensamientos sobre los ataques de b·squeda de claves anunciados por nCypher. Como empleado de una compa±φa que desarrolla un servidor web seguro basado en c≤digo abierto tendrφa tantas tentaciones como cualquiera de desestimar la importancia de tales ataques, especialmente debido a que la inferencia que se busca parece ser que el servidor web no puede ser seguro a menos que uno se gaste mßs dinero en hardware criptogrßfico. Sin embargo, considero que es peligroso ignorar lo que el trabajo subyacente puede tener que decirnos sobre nuestra seguridad y configuraciones, sin importar si implica o no llegar a los extremos que las notas de prensa pueden desear (que es considerar que el hardware criptogrßfico es la soluci≤n al problema). Suelo coincidir con el sentimiento de que estos ataques de b·squeda de claves no son ni de cerca tan sensacionalistas como la prensa podrφa (o serφa inducida a) desear; la exploraci≤n de claves no es nada nuevo y este trabajo simplemente la acelera un poco, y s≤lo hay algunos tipos de uso muy especializados de servidores web en que estos ataques se pueden plantear contra un servidor que se haya configurado de forma competente. Sin embargo son los servidores web mal configurados de los que mßs probablemente se habla para ilustrar y justificar ataques, asφ que mejor miraremos bajo la cubierta para ver con quΘ podemos quedarnos y quΘ podemos desechar de todo esto. En mi humilde opini≤n, la investigaci≤n que respalda el anuncio es legφtima y merece que le echemos un vistazo, aunque s≤lo sea para incrementar nuestro saludable respeto a la protecci≤n de claves. En particular, la investigaci≤n emplea algunas ideas interesantes para explorar grandes bloques de datos en busca de ßreas de elevada entropφa, antes de recurrir a tΘcnicas mßs refinadas para localizar las claves en sφ dentro del "mont≤n de paja". Ilustra de un modo bastante efectivo por quΘ hay que tener muchφsimo ojo con los escenarios en los que hay claves privadas sin cifrar en cualquier medio expuesto a exploraci≤n por fuerza bruta, sin importar lo imposible que pueda parecer en principio la exigencia de recursos necesarios. La investigaci≤n en cuesti≤n muestra c≤mo un disco duro grande podrφa ser explorado bastante rßpido para localizar una clave privada que pudiera estar en Θl (por ejemplo, en una partici≤n de intercambio, un volcado de memoria, etc). Cualquiera sabe que una clave privada no cifrada siempre es un objetivo, pero la investigaci≤n da un aviso considerable a los que podrφan haber pensado que una clave privada en 2 Gb de datos serφa algo demasiado difφcil de encontrar. Ademßs, el ataque nos ha llevado al menos a considerar situaciones en las que este tipo de ataque es o no es problemßtico, en lugar de permitir que los hackers lo hagan por nosotros. La verdad es que esta familia de ataques, al menos en el caso de servidores web, s≤lo representa una amenaza seria para servidores que alberguen m·ltiples hosts virtuales mediante la misma aplicaci≤n de servicio de web empleada para albergar un host virtual seguro (y no utilice ning·n setuid en los procesos hijos del servidor de web). En esa situaci≤n, un administrador que pueda cargar y activar programas nativos (por ejemplo, CGI) en su host virtual no s≤lo puede buscar y encontrar su propia clave privada (si la tiene), sino tambiΘn las claves privadas de cualquier otro host virtual cargado ejecutßndose en los mismos procesos (o como el mismo usuario). Conectßndose a un proceso en ejecuci≤n (como hacen los depuradores) o utilizando alg·n mecanismo similar al "/proc" para obtener acceso directo a la memoria virtual de un proceso, se podrφa comenzar la exploraci≤n como en cualquier fichero regular. No hay muchos servidores funcionando en escenarios como este (donde un "administrador" puede comprometer a cualquiera excepto a Θl/ella mismo/a), pero la investigaci≤n nos ha permitido al menos considerar quiΘn es y quiΘn no es vulnerable (ayudando a los primeros, y proporcionando cierta paz interior a los segundos) antes de que haya que aprenderlo de la peor manera. De: Nicko van Someren (nicko@ncipher.com) Tema: Re: Encontrar claves Traducido por JosΘ Manuel G≤mez ----------------------------------------- En primer lugar, me gustarφa destacar una significativa inexactitud en su artφculo. Usted afirma en el pen·ltimo pßrrafo que "la publicaci≤n de nCipher incluφa una herramienta hacker". Esto es incorrecto. Nosotros hemos construido una herramienta que localiza eficientemente claves de servidores SSL y se lo hemos mostrado a un n·mero limitado de fabricantes de servidores web, pero NUNCA hemos publicado el c≤digo; ni tenemos intenci≤n alguna de hacerlo. En cuanto al tema mßs amplio de lo que usted denomina "ataques publicitarios", creo que debo defender la nota de prensa de nCipher. Un aspecto fundamental cuando se desarrollan soluciones de seguridad es encontrar las debilidades de sistemas ya existentes, y cuando se hallan, es razonable hacΘrselo saber a los afectados. DespuΘs de dar a conocer los ataques te≤ricos en febrero del 99, nos encontramos con que muchos fabricantes de servidores web consideraron impracticables los ataques y pasaron del tema. Asφ que tuvimos que demostrar la practicabilidad de tales ataques y dar los detalles de los nuevos resultados a los fabricantes. DespuΘs de eso lo comunicamos a todo el mundo. Aunque usted estß en lo cierto al afirmar que nCipher tiene alg·n interΘs en los resultados de esta investigaci≤n, serφa extra±o que cualquier empresa corriera con los costes de una investigaci≤n si no tuviera alg·n interΘs en los resultados. Nos mantenemos en nuestra posici≤n de que publicar potenciales formas de ataque es preferible a ocultarlas y permitir que sean utilizadas contra un mundo desprevenido. De: ruth@innocent.com Tema: Radio Piratas Traducido por JosΘ Manuel G≤mez --------------------------------- La historia de los "Radio Piratas" parti≤ del New Scientist, donde por lo que sΘ todo se trat≤ de una forma mßs equilibrada y probablemente publicaron incluso alg·n tipo de informaci≤n adicional sobre la tecnologφa RDS y la causa de esta vulnerabilidad. RDS (Radio Data System) permite a los receptores comunes de radio decodificar una se±al digital de bit bajo a partir de emisiones de FM compatibles. Esta se±al puede incluir un identificativo de la emisora (como BBC R4 o KISS FM), y algunas otras informaciones, pero existe una caracterφstica adicional que los conductores pueden activar, denominada TP (Traffic Programme), que conmuta a emisoras locales cuando estßn emitiendo informes de trßfico. ┐Por quΘ representa esto un "buen ejemplo de las vulnerabilidades ocultas en los sistemas digitales"? Aunque se creyera los disparatados artφculos de la BBC cuando dice que "la radio contin·a sintonizada hasta que... el conductor apaga la caracterφstica RDS", a·n se darφa cuenta de que este sistema desaparece c≤modamente hasta convertir el aparato en una radio de FM normal, con s≤lo pulsar un bot≤n. En realidad, esos artφculos son una exageraci≤n; todas las radios de coche RDS que he visto, tenφan un bot≤n etiquetado como "TP", que al pulsarlo activa o desactiva s≤lo el servicio de programa de trßfico. Esto no afecta al resto de los beneficios de RDS. No puedo imaginarme un mecanismo que permitiese a las radios identificar e ignorar las se±ales TP piratas, si no llegamos a un completo DAB (┐como al que llegarß el Reino Unido en la pr≤xima dΘcada inevitablemente?) Ofrecer un servicio optativo adicional que puede ser objeto de posibles ataques DOS, no me parece una vulnerabilidad. De: an≤nimo Tema: Rotura de tarjetas inteligentes francesas Traducido por Francisco Leal Vßzquez --------------------------------------------------- En el criptograma del 15 de Diciembre de 1999, escribi≤: "un ingeniero francΘs consigui≤ factorizar la clave RSA de 640 bits almacenada en el chip de la tarjeta (todas las tarjetas de crΘdito "CB" francesas tienen un chip desde 1990) " Lo que estß claramente probado (acordado en los tribunales por Serge Humpich y el Groupement des Cartes Bancaires) es que Humpich hizo algunas tarjetas inteligentes falsas, con n·meros de cuenta incrementales, y las us≤ despuΘs para comprar billetes de metro en mßquinas automßticas, como una demostraci≤n al Groupement. Por esto es principalmente por lo que se le acus≤. Se espera que el juez emita un veredicto en el 25 de Febrero del 2000. Un resumen de la audiencia (en francΘs) se encuentra en: http://www.legalis.net/legalnet/actualite/affairehumpish/pagehumpish.h m "Desde diversas fuentes, incluyendo al mismo Humpich en un programa de televisi≤n y este informe de la audiencia, estaba intentando vender sus aptitudes al Groupement a travΘs de un abogado en un intento de mantener el anonimato." La reclamaci≤n sobre la clave de 640-bit se origin≤ en la revista "Pirate Mag" (tambiΘn conocida por promocionar la idea de que el PGP tiene una puerta trasera). Ellos poseen una entrevista de Serge Humpich donde dice que: - - Rompi≤ un "c≤digo bastante s≤lido de 96 dφgitos" ([p.ej. 320 bits] utilizado por el Groupement para las tarjetas de crΘdito "CB", con detalles compatibles con un esquema de firma RSA de redundancia simple. - - Hizo una demostraci≤n espectacular a los expertos, factorizando algunos m≤dulos p·blicos de 640-bit con formato especial, adivinando que los factores se habφan escogido cerca de la raφz cuadrada del m≤dulo y con unas propiedades especiales. ╔l tiene claro que su mΘtodo no funciona en el caso general. No dice de forma explφcita que las firmas de 640 bits se usen en las Tarjetas Inteligentes falsas. No logrΘ encontrar ninguna confirmaci≤n independiente de la factorizaci≤n de la firma de 640-bit por parte de Humpich, y ni siquiera de cualquier otra declaraci≤n atribuida a Humpich sobre que Θl hubiera factorizado alguna vez la clave RSA de 640 bits. Basßndose en la prueba innegable de que el Groupement des Cartes Bancaires originalmente utiliz≤ una clave p·blica multisistema de 321 bits, y la falta de pruebas de que se utilizaran claves mayores en 1999, algunos creen que el fraude que demostr≤ Humpich es una combinaci≤n de: - - Factorizar el m≤dulo p·blico multisistema de 321 bits, cuya clave secreta correspondiente se usa al emitir la tarjeta para producir una firma RSA estßtica de 320 bits contenida en la misma, certificando el n·mero de 16 bits de la tarjeta y su fecha de caducidad; esta firma estßtica es chequeada por los POSTs como una simple validaci≤n de la tarjeta. - - Conseguir Tarjetas Inteligentes que funcionen y que contengan un n·mero de tarjeta falso, la fecha de caducidad y de ahφ la firma. http://humpich.com/, un sitio Web reciente sobre el caso, con fuentes aparentemente cercanas a Sergei Humpich, describe c≤mo factoriz≤ una clave de 321 bits en 1997, citando el clßsico algoritmo MPQS de factorizaci≤n, con pocos recursos en cuanto a mßquina, y un programa japonΘs. Ellos presentan la clave de 640-bit como ua elecci≤n razonable que podφa haber hecho el Groupement des Cartes Bancaires, pero que Θste no hizo. Ese mismo sitio Web contiene escaneados on-line de algunas publicaciones donde el experto francΘs Louis C. Guillou, conocido por su involucraci≤n en el dise±o del sistema de Tarjetas Inteligentes utilizado por el Groupement des Cartes Bancaires, ya advierte en 1988 [en francΘs] y de nuevo en 1990 [en inglΘs] que la clave de 320-bit a·n en uso experimental por el CB era obsoleta. http://humpich.com/LCguillou_AnnTelecom_No43_1988.jpg http://humpich.com/SmartCard19900810-2.jpg Poudiera ser que Humpich hubiera demostrado que podφa romper un sistema obsoleto para poder hacer dinero de eso y, como represalia, estuviera siendo demandado mediante todos los medios legales disponibles. F≤rmese su propia opini≤n. _____________________________________________________________________ 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 * Antonio Sanz * JosΘ Luis Martφn Mßs * Juan Cruz Ruiz de Gauna * Sergio Pozo Hidalgo * David G≤mez * Oscar Esteban * Francisco Leal Vßzquez Si usted tambiΘn desea colaborar en la traducci≤n de pr≤ximos ejemplares, dirφjase a colab@kriptopolis.com. _____________________________________________________________________ -- 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. _____________________________________________________________________ Este ejemplar se ha distribuido gratuitamente a mßs de 18.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). _____________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: Clave en http://www.kriptopolis.com/claves/jmg.asc iQEVAwUBOLL9KxiK3dCT8TvxAQEmjwf9G1nSivlZIUrDFG+4BOb4W0s6Crld++kk WZH9M5WPismPPOem51+FE+tjpt9Xg0UdqsaJKJly9rGsxBD1AaAePBSLVT6Enh5i 6FFzCWiuIS96AdXcE44slS2GBps494Ape8RKVCqbm1rsQkd5WfBgCOF0dPazIPka 0z+qUapH8+gLe18urUsk3h+1eFW4aFmIjBaDHevrc4odnKpx+kij2IXFKg9eEboT MwVjVPhVNO9hp3QKznVlm6X+wQRj9u8ojlbotU8YVWwncmclN9hezU6YfZTMVxr2 SnOcCr17Y0R9kF7XBjX/uEILg8O36lA+oeBriJQNTvV8nMWy9ojJZA== =HPlC -----END PGP SIGNATURE-----