1999 << Back To criptograma nº 12

C R I P T O - G R A M A ⌐ Bruce Schneier ⌐ Kriptopolis (versi≤n en Espa±ol). http://www.kriptopolis.com/criptograma/cg.html ----------------------------------------------------- N·mero 12 15 de Abril de 1999 ----------------------------------------------------- SUMARIO: * Criptografφa: la importancia de no ser diferente * Noticias * Counterpane Systems: investigaci≤n documentada * Amenazas contra las tarjetas inteligentes * Atacar certificados mediante virus informßticos * Novedades en Counterpane Systems * Comentarios de los lectores -------------------------------------------------------------- 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. Nuevos ejemplares de CriptoGRAMA estarßn disponibles cada mes en: Cripto-GRAMA: http://www.kriptopolis.com/criptograma/cg.html 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. Crypto-GRAM: http://www.counterpane.com/crypto-gram.html ---------------------------------------------------------------- Criptografφa: la importancia de no ser diferente ________________________________________________ Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna e Isidre Marques Serret Supongamos que su mΘdico le dice: "Ya sΘ que disponemos de antibi≤ticos que son buenos para tratar el tipo de infecci≤n que usted tiene sin efectos secundarios, y que hay dΘcadas de investigaci≤n que apoyan este tratamiento. Pero yo sin embargo voy a darle una tortilla de levadura de patata, porque, bueno, puede funcionar." Sin duda se buscarφa otro mΘdico. Practicar la medicina es difφcil. Esta profesi≤n no se da prisa para adoptar nuevos fßrmacos; antes de poder probar sus beneficios son necesarios a±os de pruebas, hay que establecer las dosis y catalogar los efectos secundarios. Un buen mΘdico no tratarß una infecci≤n vφrica con una medicina que acaba de inventar cuando dispone de antibi≤ticos probados. Y los pacientes inteligentes quieren la misma medicina que ha curado a la ·ltima persona, no algo diferente. La criptografφa tambiΘn es difφcil. Combina matemßticas, informßtica, a veces ingenierφa elΘctrica y una forma de pensar retorcida para entender c≤mo completar reglas, romper sistemas y trastocar las intenciones de los dise±adores. Incluso la gente muy inteligente, con conocimientos y experimentados, inventan mala criptografφa. En la comunidad criptogrßfica, la gente no se averguenza demasiado cuando sus algoritmos y protocolos son rotos. Asφ de duro es. Reutilizando Componentes Seguros Contruir criptografφa dentro de productos tambiΘn es duro. La mayor parte de productos de criptografφa del mercado son inseguros. Algunos no funcionan tal y como anuncian. Algunos contienen errores obvios. Otros contienen errores mßs sutiles. A veces la gente descubre los errores rßpidamente, mientras que otras lleva a±os (normalmente porque nadie se preocup≤ por buscar los errores). A veces pasa una dΘcada antes de que alguien invente nuevas matemßticas para romper alg·n algoritmo. La dificultad se ha hecho incluso mßs seria por varias razones. Primero, los errores pueden aparecer en cualquier parte. Puede ser en el modelo de confianza, en el dise±o del sistema, en los algoritmos y protocolos, las implementaciones, el c≤digo fuente, el interfaz ordenador-persona, los procedimientos, el sistema informßtico subyacente... En cualquier parte. Segundo, estos errores no pueden ser detectados a travΘs de pruebas beta normales. La seguridad no tiene nada que ver con la funcionalidad. Un producto criptogrßfico puede funcionar normalmente y ser completamente inseguro. Los errores permanecen sin descubrir hasta que alguien los busca explφcitamente. Tercero, y el mßs importante, un solo error rompe la seguridad de todo el sistema. Si pensamos en la criptografφa como si fuese una cadena, el sistema es tan seguro como pueda serlo su eslab≤n mßs dΘbil. Esto significa que todo debe ser seguro. No basta con hacer los algoritmos y los protocolos perfectos si la implementaci≤n tiene problemas. Y un gran producto con un algoritmo roto no sirve de nada. Y un gran algoritmo, protocolo e implementaci≤n pueden ser arruinados por un generador de n·meros aleatorios err≤neo. Y si hay un error de seguridad en el c≤digo, el resto del producto ya no tiene la mßs mφnima importancia. Dada esta dura realidad, La decisi≤n de dise±o mßs razonable es usar el menor n·mero de eslabones posible y el mßs alto porcentaje de eslabones fuertes posible. Partiendo de que es impracticable para un dise±ador de sistemas (o incluso para un equipo de dise±o) analizar por completo un sistema nuevo, un dise±ador inteligente reutiliza componentes cuya seguridad se supone lo suficientemente comprobada, y s≤lo inventa nueva criptografφa cuando es absolutamente necesario. Confiar en lo conocido Consideremos IPSec, el protocolo de seguridad de Internet. A principios de 1992 fue dise±ado de forma abierta mediante una comisi≤n y estuvo sujeto a un considerable escrutinio p·blico desde sus comienzos. Todo el mundo sabφa que era un protocolo importante y la gente emple≤ un gran esfuerzo tratando de hacerlo bien. La tecnologφas de seguridad fueron propuestas, rotas y, entonces, modificadas. Las versiones fueron codificadas y analizadas. El primer borrador del estßndar fue publicado en 1995. Se debatieron aspectos basados en sus mΘritos en cuanto a seguridad y rendimiento, facilidad de implementaci≤n, escalabilidad y uso. En Noviembre de 1998, el comitΘ public≤ una serie de RFCs (el primero de una serie de pasos para convertir a IPSec en un estßndar Internet). Y a·n sigue siendo estudiado. Los cript≤grafos del Laboratorio de Investigaci≤n Naval han descubierto recientemente un error menor de implementaci≤n. El trabajo contin·a, en p·blico, por parte de cualquiera que estΘ interesado. En el otro lado, Microsoft desarroll≤ su propio Protocolo de Tunelizaci≤n Punto-A-Punto (PPTP, Point-To-Point Protocol) para hacer exactamente lo mismo. Inventaron su propio protocolo de autenticaci≤n, sus propias funciones hash y su propio algoritmo de generaci≤n de claves. Cada uno de estos elementos ha tenido sus errores. Usaron un algoritmo de cifrado conocido, pero lo hicieron de tal manera que comprometφa su seguridad. Cometieron errores de implementaci≤n que debilitaban el sistema a·n mßs. Pero como este trabajo fue hecho internamente, nadie supo que su PPTP era dΘbil. Microsoft persent≤ PPTP en Windows NT y 95, y lo us≤ en sus productos de Red Virtual Privada (VPN Virtual Private Network). No fue hasta el verano de 1998 cuando Counterpane Systems public≤ un documento describiendo los errores que encontramos. Microsoft rßpidamente envi≤ una serie de parches, que nosotros hemos evaluado y encontrado insuficientes. Microsoft no ha corregido las cosas tan bien como intenta hacer creer a la gente. TambiΘn hay una compa±φa como TriStrata, que proclama tener una soluci≤n de seguridad propietaria sin decir a nadie c≤mo funciona (porque estß pendiente de patente). Tenemos que confiar en ellos. Ellos proclaman tener un nuevo algoritmo y un nuevo conjunto de protocolos que son mucho mejores que los actualmente existentes. E incluso si hiciesen p·blico su sistema, el hecho de haberlo patentado y retener el control de su propiedad significa que muchos cript≤grafos no se molestarßn en analizar las reclamaciones. Dando apoyo a la fuerza del colectivo Usted puede escoger cualquier de estos tres de sistemas para proteger su red privada virtual. Aunque es posible que cualquier de ellos pueda ser superado, usted quiere minimizar su riesgo. Si usted elige IPSec, tiene una seguridad mucho mayor de que los algoritmos y los protocolos son fuertes. Por supuesto, el producto todavφa podrφa se superado -puede haber una implementaci≤n err≤nea o un fallo en cualquier de los lugares no cubiertos por el protocolo IPSec- pero por lo menos sabe que los algoritmos y los protocolos han resistido un nivel de anßlisis y revisi≤n que las opciones de Microsoft y TriStrata no ha soportado. Elegir el sistema de TriStrata es como ir a un mΘdico que no tiene ninguna titulaci≤n y cuyos novedosos tratamientos (que reh·sa explicar) no tienen ning·n apoyo del AMA (American Medicine Asociation). Seguramente es posible (aunque altamente improbable) que haya descubierto un tipo totalmente nuevo de medicamento, pero ┐Quiere usted ser el conejillo de indias? La cuesti≤n aquφ es que los mejores mΘtodos de seguridad dan soporte a la capacidad de anßlisis de la comunidad criptogrßfica. Ninguna compa±φa (aparte de los militares) tiene, por si sola, los recursos financieros necesarios para evaluar un nuevo algoritmo criptogrßfico o eliminar los errores de dise±o de un protocolo complejo. La misma afirmaci≤n mantiene su fuerza en las bibliotecas criptogrßficas. Si escribe las suyas propias, probablemente cometerß equivocaciones. Si usa una que es p·blica y ha estado disponible durante alg·n tiempo, algunas de las equivocaciones se habrßn encontrado y corregido. Si ya es suficientemente duro implementar un sistema de criptografφa potente en un sistema nuevo, intentar emplear un sistema de criptografφa nuevo, cuando existen alternativas viables y largamente estudiadas, es simplemente una tonterφa. Pero la mayorφa de las compa±φas de seguridad, y la gente normal, por otro lado inteligente y sensata, sufren de una aguda "neofilia" y quedan cegadas fßcilmente por el brillo de las novedades en la criptografφa. Seguir a la multitud En Counterpane Systems, analizamos docenas de productos en un a±o. Revisamos todos los tipos de criptografφa, desde nuevos algoritmos a nuevas implementaciones. Nosotros rompemos la gran mayorφa de los sistemas patentados y, sin excepci≤n, los mejores productos son los que hacen uso de la criptografφa existente en un grado tan alto como les resulta posible. No s≤lo las elecciones conservadoras son generalmente mßs inteligentes, sino que significan que realmente podemos analizar el sistema. Podemos revisar un producto simple de criptografφa en un par de dφas si emplea protocolos y algoritmos existentes, en una semana o dos si usa protocolos nuevos y algoritmos ya existentes. Si usa nuevos algoritmos, una semana es, apenas, tiempo suficiente para comenzar. Esto no significa que todo lo nuevo sea malo. Significa que todo lo nuevo es sospechoso. Las novedades en criptografφa pertenecen a los documentos acadΘmicos, y posteriormente a sistemas de demostraci≤n. Si realmente es mejor, quizßs entonces los cript≤grafos llegarßn a confiar en Θl. Y s≤lo entonces tiene sentido utilizarlo en productos comerciales. Este proceso puede tardar de cinco a diez a±os para un algoritmo, menos para protocolos o c≤digos de bibliotecas. Observen el tiempo que han necesitado los sistemas de curva elφptica para ser aceptados, e incluso ahora s≤lo son utilizados cuando las alternativas de mßs confianza no pueden alcanzar las prestaciones requeridas. En la criptografφa, hay seguridad en seguir a la muchedumbre. Un algoritmo propio, seguramente, no puede someterse a los centenares de millares de horas de cripotanßlisis que DES y RSA han soportado. Una compa±φa, o incluso un grupo de compa±φas, no pueden comenzar a movilizar los recursos que se han usado contra el protocolo Kerberos de autenticaci≤n, por ejemplo. Nadie puede igualar la confianza que ofrece PGP, despuΘs de que durante a±os haya habido gente analizando el c≤digo, lφnea por lφnea, buscando defectos de implementaci≤n. Siguiendo a la muchedumbre, usted se beneficia de la pericia de la comunidad criptogrßfica de todo el mundo y no de, simplemente, unas semanas de trabajo de un analista. Y cuidado con el doctor que dice, "Yo he inventado y patentado este tratamiento totalmente nuevo que consiste en polvo de tortilla de patatas. No se ha probado antes, pero simplemente sΘ es mucho mejor y voy a dßrselo a usted." Esta es una buena raz≤n para que nosotros llamemos a la criptografφa novedosa "aceite de serpiente". Reconocimientos Gracias a Matt Blaze por la analogφa usada para abrir esta columna. Originalmente apareci≤ en el ejemplar de Marzo 1999 de IEEE Computer. Noticias ___________________________ Por Bruce Schneier Traducci≤n: Antoni Muntaner Un reciente estudio del Pentßgono reconoce que los ordenadores del Departamento de Defensa son altamente vulnerables a los ataques. !QuΘ sorpresa!. http://abcnews.go.com/sections/tech/dailyNews/hackerspentagon990322.html El Acta (H.R. 850) sobre Seguridad y Libertad a travΘs del Cifrado (SAFE) pas≤ el ComitΘ Jurφdico del Congreso a finales de Marzo. Fue una victoria, puesto que una enmienda (propuesta por el republicano McCollum (R-Fl) que hubiera impuesto el dep≤stio de claves como condici≤n para exportar, fue bloqueada por el republicano Goodlatte (R-VA) en el terreno jurisdiccional. El republicano Lofgren (D-CA), uno de los autores del proyecto de ley, compar≤ la enmienda con el fallido "Clipper Chip" de la Administraci≤n. Las cosas se pondrßn mßs difφciles para el proyecto en otros comitΘs: ahora le toca al ComitΘ de Relaciones Internacionales, donde se espera un intenso debate sobre la disponibilidad en el extranjero de los productos de cifrado. http://abcnews.go.com/sections/tech/CNET/cnet_cryptobill990324.html http://www.wired.com/news/news/politics/story/18708.html Materiales en torno al proyecto SAFE: http://www.cdt.org/crypto/legis_106/SAFE/ Enmienda propuesta por McCollum: http://www.cdt.org/legislation/106th/encryption/McCollum.html Testimonio de CDT apoyando el SAFE: http://www.cdt.org/crypto/alantestimony.shtml El acuerdo de Wassenaar es un intento para implantar en otros paφses la misma clase de lφmites que hay en EEUU en cuanto al cifrado potente. Esto s≤lo tiene sentido si los Estados Unidos son la ·nica fuente de cifrado potente. Pero Θste no es el caso (el software de seguridad de otros paφses es actualmente tan bueno como el de los programadores norteamericanos). Y algunos de los firmantes se estßn aprovechando del rφo revuelto para liberalizar sus planes de acci≤n. http://www.wired.com/news/news/politics/story/19018.html Counterpane Systems: investigaci≤n documentada ______________________________________________ Por Bruce Schneier Traducci≤n: Antoni Muntaner El algoritmo de cifrado "Solitario" Bruce Schneier, apΘndice de CRYPTONOMICON, por Neal Stephenson, Avon Books, 1999. Los ordenadores han revolucionado el campo de la criptografφa. Es relativamente fßcil dise±ar un algoritmo informßtico que sea seguro frente a adversarios con un inimaginable poder informßtico. Menos importancia se le di≤ a los algoritmos de papel y lßpiz, a disposici≤n de personas que no tienen acceso a un ordenador pero que tambiΘn desean intercambiar mensajes secretos. "Solitario" es un cifrado de flujo OFB que cifra y descifra a travΘs de una baraja de cartas. A·n asφ, es seguro contra un criptoanßlisis computerizado. http://www.counterpane.com/solitaire.html Amenazas contra las tarjetas inteligentes _________________________________________ Por Bruce Schneier y Adam Shostack Traducci≤n: Juan De Miguel Hernßndez Las tarjetas inteligentes son vistas por algunos como las "armas mßgicas" de la seguridad informßtica: herramientes con m·ltiples fines que pueden ser usadas para controlar accesos, comercio electr≤nico, autentificaci≤n, protecci≤n de la privacidad y una gran variedad de aplicaciones. Mientras la flexibilidad de las tarjetas inteligentes las hace una opci≤n muy atractiva para muchos negocios, eso tambiΘn multiplica los peligros de su seguridad de conjunto. Hasta la fecha, ha habido poco anßlisis sobre estos riesgos en su seguridad. Debido al gran n·mero de partes involucradas en cualquier sistema basado en tarjetas inteligentes, existen muchas clases de ataques a los cuales son supceptibles. La mayorφa de estos ataques no son posibles en sistemas convencionales e independientes porque tienen que tener lugar en la frontera con los sistemas informßticos tradicionales. Pero en el mundo de las tarjetas inteligentes los ataques que se mencionan a continuaci≤n tienen un peligro real. Ataques desde el terminal contra el poseedor de la tarjeta o el propietario de los datos Es el ataque mßs fßcil de entender. Cuando el due±o de la tarjeta inteligente la coloca en el terminal, confφa en el terminal para realizar entradas y salidas correctas desde la tarjeta. Los mecanismos de prevenci≤n en la mayorφa de los sistemas de tarjetas inteligentes dan por hecho que el terminal s≤lo tiene acceso a la tarjeta por un corto periodo de tiempo. Los mecanismos de protecci≤n reales, sin embargo, no tienen nada que ver con la interacci≤n entre tarjeta inteligente y terminal: son sistemas de proceso que monitorizan las tarjetas y el terminal, se±alando las conductas sospechosas. Ataques del Poseedor de la Tarjeta contra el Terminal Mßs sutiles son los ataques del Poseedor de la Tarjeta contra el Terminal. Estos precisan el uso de tarjetas falsas o modificadas ejecutando programas especiales con la intenci≤n de enga±ar al protocolo de comunicaci≤n entre la tarjeta y el terminal. Los protocolos bien dise±ados reducen el riesgo de este tipo de ataques. La amenaza se reduce a·n mßs cuando la tarjeta posee caracterφsticas fφsicas difφciles de falsificar (como el holograma de una tarjeta VISA) que pueden ser revisados manualmente por el poseedor del terminal. Ataques del Poseedor de la Tarjeta contra el propietario de los datos En muchos sistemas de comercio basados en tarjetas inteligentes, la informaci≤n grabada en la tarjeta debe ser protegida del propietario de la misma. En algunos casos, Θste no debe conocer esa informaci≤n. Si la tarjeta guarda un valor y este puede ser modificado por el due±o, Θste puede conseguir dinero extra muy facilmente. Ha habido muchos ataques con Θxito de este tipo, como anßlisis de fallos, ingenieria inversa y ataques por canales colaterales, como los anßlisis de tiempo y energφa. Ataques del Poseedor de la Tarjeta contra el Emisor Hay muchos ataques financieros que parecen ir dirigidos contra el emisor, pero de hecho estßn atacando a la integridad y autenticidad de la informaci≤n o programas grabados en la tarjeta. Si los emisores de tarjetas deciden poner bits que autorizan el uso del sistema en una tarjeta, no se deberφan sorprender cuando esos bits son atacados. Estos sistemas descansan sobre la cuestionable suposici≤n de que el margen de seguridad de una tarjeta inteligente es suficientemente grande para sus prop≤sitos. Ataques del Poseedor de la tarjeta contra el Fabricante del programa Generalmente, en sistemas donde la tarjeta es emitida a un presunto usuario hostil, lo l≤gico es que la tarjeta no tenga ningun programa nuevo cargado en ella. La presunci≤n fundamental puede ser que la separaci≤n entre el due±o de la tarjeta y el propietario del software es imposible de restablecer. Sin embargo, los atacantes han demostrado una habilidad increible en conseguir que los aparatos necesarios les sean enviados, a veces gratis, para ayudarles a lanzar un ataque. Ataques del Poseedor del Terminal contra el Emisor En algunos sistemas, el propietario del terminal y el emisor de las tarjetas son partes totalmente distintas. Esta separaci≤n introduce muchas nuevas posibilidades de ataque. El terminal controla toda la comunicaci≤n entre la tarjeta y el emisor de la misma, y siempre puede siempre falsificar registros o fallar al completar uno o mßs pasos de la transacci≤n, en un intento de facilitar el fraude o crear dificultades al servicio de atenci≤n al cliente del emisor. Ataques del Emisor contra el Poseedor de la Tarjeta En general, la mayorφa de los sistemas presuponen que los emisores de las tarjetas act·an de buena fe. Pero este no es precisamente el caso. Estos ataques son generalmente invasiones de la privacidad, de uno u otro tipo. Los sistemas de tarjetas inteligentes que sirven como sustitutos del dinero en efectivo deben ser dise±ados muy cuidadosamente para poder mantener las mismas propiedades del dinero en efectivo: anonimato y ausencia de vinculaci≤n. Ataques del fabricante contra el propietario de los datos Ciertos dise±os de los fabricantes pueden tener efectos perjudiciales para los propietarios de los datos en un sistema. Dise±ando un sistema operativo que permita (o incluso recomiende) que m·ltiples usuarios ejecuten programas en la misma tarjeta, aparecen nuevos temas en cuanto a seguridad, como la subversi≤n del sistema operativo, generadores de n·meros aleatorios intenciondamente dΘbiles o una aplicaci≤n en una tarjeta inteligente que altere a otra que se ejecute en la misma tarjeta. Garantizar la seguridad de los sistemas de tarjetas inteligentes significa reconocer estos ataques y dise±arlos en un sistema. En los mejores sistemas, no importa si (por ejemplo) el usuario puede alterar la tarjeta. Es muy simple: trabajan con el modelo de seguridad, no contra Θl. Adam Shostack es Director de Tecnologia en Netect Inc. Artφculo completo en: http://www.counterpane.com/smart-card-threats.html Atacar certificados mediante virus informßticos _______________________________________________ Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez ┐C≤mo se puede saber que un correo electr≤nico es autΘntico? Se verifica la firma digital, por supuesto. Esto viene a significar que se verifica que el mensaje fue correctamente firmado, utilizando para ello la clave p·blica del emisor. ┐Y c≤mo puede saberse que la clave p·blica del remitente (llamem≤sle Alice) es vßlida? Comprobando la firma de esa clave p·blica. Lo que se estß comprobando se llama certificado. Alguien (llamem≤sle Bob), firma la clave p·blica de Alice y confirma su validez. Asφ que basta verificar la firma de Bob en el certificado de Alice, para poder verificar la firma de Alice en su propio correo. De acuerdo: ┐c≤mo se sabe que la firma de Bob es vßlida? Puede ocurrir que Carol firme su clave (creando otro certificado). En realidad, eso no resuelve el problema, sino que s≤lo cambia su planteamiento. O tal vez Bob firm≤ la clave de usted, lo que le hace fiable para usted. O quizßs Carol firm≤ la clave de alg·n otro que firm≤ la clave de usted. Al fin y a la postre, usted tiene que confiar en alguien. Este concepto de cadena de certificados es uno de los mayores problemas de la criptografφa de clave p·blica, y del que se hablado mucho. PGP emplea el concepto de "presentadores de confianza"; Bob firma la clave de Alice porque Bob conoce a Alice y es su amigo. Por idΘntica raz≤n, usted firm≤ la clave de Bob. Gracias a esto, cuando Alice le envφa a usted un correo, usted puede ver que la clave de Alicia estß firmada por Bob, y usted confφa en Bob a la hora de presentarle gente (es como si Bob viniera con Alice a una fiesta en su casa). Otros protocolos de Internet (S/MIME, SSL, etc.) utilizan una aproximaci≤n mßs jerarquizada. Probablemente, la clave p·blica de usted estΘ firmada por una compa±φa como Verisign. La clave p·blica de un sitio web podrφa haber sido firmada por Netscape. Microsoft firma las claves p·blicas utilizadas a su vez para firmar fragmentos de c≤digo Active X que se pueden descargar de la Red. Estos llamados "certificados de nivel raφz" vienen muy acoplados a su navegador. De esta forma, cuando usted intenta establecer una conexi≤n SSL con un sitio web, ese sitio le envφa su certificado de clave p·blica. Usted mira a ver si ese certificado estß firmado (utilizando la clave p·blica de su navegador); si lo estß, perfecto. Las claves p·blicas del tipo "usted-debe-confiar-en-alguien" son las ·nicas que incorpora su software. Usted las cree por definici≤n, sin ninguna posibilidad de comprobaci≤n externa. Por tanto, si usted es un profesional de la seguridad informßtica un tanto paranoide, se le ocurrirß una pregunta obvia: ┐puede un programa falso reemplazar los certificados de primer nivel en mi software y enga±arme a la hora de confiar en alguien? Por supuesto que sφ. Incluso es mßs retorcido que eso. Los investigadores Adi Shamir y Nico van Someren se dedicaron a escribir programas que automßticamente buscaran los certificados de claves p·blicas y los reemplazaran por certificados falsos. Parece claro que las caracterφsticas de aleatoriedad de una clave p·blica las hace tan evidentes como un dedo hinchado, por lo que son fßciles de encontrar. Este ataque tiene sus dificultades. Si un virus reemplaza el certificado raφz de Netscape con uno falso, puede enga±arle a usted y hacerle tomar como vßlido un certificado falso. Pero ese certificado que se ha reemplazado no puede verificar ning·n certificado real, por lo que usted pensarß tambiΘn que todos los certificados autΘnticos no son vßlidos. (Esperemos que se dΘ cuenta de esto). Pero funciona bien con el Authenticode de Microsoft. Microsoft tuvo la previsi≤n de incluir dos certificados raφz de Authenticode, presumiblemente por si uno de ellos se veφs comprometido. Pero el software estß dise±ado para autenticar el c≤digo si uno s≤lo de ellos encaja. Por tanto, un virus puede reemplazar el certificado sobrante. A partir de entonces, el software firmado con este certificado falso verifica como vßlido, y el software autΘntico firmado por compa±φas aprobadas por Microsoft tambiΘn sigue verificando como vßlido. El virus no existe a·n, pero pudiera escribirse. Un buen artφculo sobre el tema: http://www.techweb.com/wire/story/TWB19990315S0001 El trabajo de investigaci≤n original: http://www.ncipher.com/products/files/papers/anguilla/keyhide2.pdf Novedades en Counterpane Systems ________________________________ Por Bruce Schneier Traducci≤n: Antoni Muntaner John Wiley & Sons ha publicado un libro sobre el algoritmo de cifrado Twofish. El libro contiene toda la informaci≤n de la candidatura inicial de Twofish y sus tres primeros informes tΘcnicos, ampliados y corregidos. Su precio de venta es de $50, pero os lo ofrezco con un 20% de descuento. http://www.counterpane.com/twofish-book.html CardTech/SecureTech'99. Bruce Schneier patrocinarß e intervendrß en la charla Tecnologφa criptogrßfica de CardTech/SecureTech, el miΘrcoles por la tarde, 14 de Mayo, en Chicago. http://www.ctst.com NetSec'99. Bruce Schneier pronunciarß el discurso principal en NetSec'99, una conferencia sobre seguridad informßtica (dφas 14-16 de Junio en St. Louis). Aunque el discurso de Bruce serß a las 8 de la ma±ana del martes, serß interesante. Schneier hablarß tambiΘn sobre seguridad en aplicaciones legales a las 2 de la tarde. http://www.gocsi.com/conf.htm El Black Hat Briefings '99 es una Conferencia de Seguridad Informßtica programada para el 7 y 8 de Julio en Las Vegas, Nevada. Defcon es una convenci≤n de hackers celebrada el fin de semana siguiente. Bruce Schneier hablarß en ambas. http://www.blackhat.com/ http://www.defcon.org/ Comentarios de los lectores ___________________________ Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mas De: Paul Shields shields@passport.ca Asunto: Algoritmos criptogrßficos caseros ----------------------------------------- Pero no es el "intento de desarrollar nuevos algoritmos" el peligro, sino el creer que es seguro distribuir esos algoritmos; y dado que los dise±adores no son siempre los que deciden, mientras que el dise±ador de un algoritmo puede ver el valor acadΘmico de hacerlo, el que toma las decisiones puede que s≤lo vea que es algo que vender. Desgraciadamente, esta gente que toma decisiones son empresarios que no comprenden del todo una prueba matemßtica y se centran en riesgos y beneficios. Si nadie intenta romperlo, el algoritmo puede no ser seguro; pero si se da el caso de que incluso despuΘs de una distribuci≤n limitada ninguna persona competente trata de romperlo, entonces, para una mente empresarial, los riesgos estßn cubiertos. Tengo que admitir que en mi juventud creΘ una aplicaci≤n criptogrßfica que, aunque era terriblemente insegura incluso ante mis inexpertos ojos, fue por desgracia puesta en servicio por una de estas personas que toman decisiones. Fue empleada para proteger informaci≤n muy delicada y super≤ un intento de romperla; pero no esto no me ayudaba a dormir tranquilo. Para convencer a estas personas de lo que puede ocurrir, creo que es necesario narrarles historias de sistemas asφ que han caφdo, provocando enormes pΘrdidas a los que confiaron en ellos. De: George Stults Asunto: Algoritmos probados frente al Secreto ---------------------------------------------- He estado pensando acerca de un tema del que usted ha hablado muchas veces, el que si no se usa un mΘtodo criptogrßfico publicado, revisado y analizado, se estß corriendo un riesgo; puede ser un buen mΘtodo, pero lo mßs probable es que no sea asφ. Se me ocurre que habrφa que tener en cuenta otro aspecto, el que un mΘtodo bien conocido y ampliamente adoptado como DES es algo en lo que interesa invertir esfuerzo para romperlo. Tanto incluso como para dise±ar hardware especial que lo rompa, como la mßquina de la que se ha hablado tanto dise±ada para romper DES (┐con clave de 40 bits?). Y lo opuesto podrφa ser cierto para los mΘtodos desconocidos. Cualquier agencia que deba enfrentarse a un gran volumen de material criptogrßfico, sin duda establecerß unas prioridades. Un mΘtodo desconocido que requiera un tiempo y esfuerzo extra para atacarlo serß menos interesante. En efecto, seguridad a travΘs de la oscuridad. Los autores del documento sobre seguridad del Reino Unido (del que se habla en un n·mero anterior) parecφan plantear tambiΘn esto. De: Dave Emery Asunto: Comunicaciones m≤viles inseguras ---------------------------------------- Algunos de los que nos gusta husmear por el espectro de radiofrecuencias para explorar lo que hay ahφ fuera hemos estado intentando conseguir esto en varios enlaces de radiofrecuencia muy utilizados durante muchos, muchos a±os. Estß bien ver que el asunto estß teniendo algo mßs de repercusi≤n. La mayorφa de los MDTs (Mobile Data Terminals, terminales m≤viles de datos) utilizados por los departamentos de policφa no se cifran de ninguna manera correcta; toda la complejidad del formato de sus se±ales se centra en proporcionar correci≤n y detecci≤n de errores y un uso eficiente de la banda de frecuencias de la radio. Los enlaces VHF y UHF con vehφculos m≤viles estßn expuestos a altas tasas de error y a cortes, y los protocolos de los MDT y los buscas fueron dise±ados para usar una correci≤n de errores anticipada (tasas de error de la mitad o mßs) y sistemas de intercalaci≤n muy potentes para solucionar esto. Esto, y el modo de transmisi≤n sφncrona usada para reducir el ancho de banda total hace que las se±ales de MDT sean complejas y no estΘn estandarizadas, en comparaci≤n con los tφpicos sistemas asφncronos arranque/parada con caracteres ASCII. Y algunos de los fabricantes fueron lo suficientemente est·pidos como para vender a sus clientes la "seguridad" de sus sistemas tratando de convencerles de que las se±ales con correci≤n de errores, intercalaci≤n y randomizaci≤n (con scrambling para mejorar los valores de la se±al, no con fines de seguridad) eran tan complejas que nadie podrφa descifrarlas. Pero si creen que los MDTs de la policφa que funcionan sin cifrado son algo sorprendente, deberφan darse cuenta de que casi todo el trßfico de los 'buscas', incluyendo el correo electr≤nico enviado a travΘs de estos sistemas, va tambiΘn sin cifrado y se transmite usando protocolos dise±ados para ser robustos en entornos con altas tasas de error y no para ser seguros. Y desde hace a±os hay software circulando por la Red que puede monitorizar 'buscas' con un scanner de frecuencias. Se incluye la capacidad de rastrear determinados 'buscas' o monitorizar todo lo que haya en el canal y buscar trßfico interesante. Y el protocolo Mobitex usado por ARDIS y RAM mobile para correo electr≤nico inalßmbrico es otro ejemplo de algo que es complejo debido a su correci≤n de errores y su robustez, pero que carece de seguridad. Y tambiΘn hay software para monitorizar esto. ARDIS usa un XOR con una constante de 32 bits para cada dφa para tratar de proporcionar alguna apariencia de seguridad, pero obviamente determinar la constante es trivial... Y esto es s≤lo una peque±a parte de lo que se puede encontrar en las ondas y de lo que se puede interceptar con equipos relativamente simples y aprovechando la ingenuidad de cierto software... ----------------------------------------------------------------- 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. CriptoGRAMA s≤lo puede ser redistribuida de forma completa (esta nota incluida). KRIPT╙POLIS http://www.kriptopolis.com Equipo de Traductores de Kript≤polis: * Juan De Miguel Hernßndez <chili@vuelta-al-mundo.org> * Isidre MarquΘs Serret <ismase@mx3.redestb.es> * Juan Ruiz de Gauna Gorostiza <juancruz.ruiz@si.upna.es> * JosΘ Luis Martφn Mas <jlmartin@lander.es> * Antonio Muntaner <mmg@balears.net> * Angel Galindo <agalindo@lacaja.net> * Jaime Millßn de Castro <us_jaime@svalero.es> ------------------------------------------------------------------