1999 << Back To criptograma nº 14

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 14 15 de Junio de 1999 ------------------- SUMARIO: 1. Virus de e-mail, Gusanos y Caballos de Troya 2. Counterpane Systems: investigaci≤n documentada 3. Noticias 4. Noticias de Counterpane Systems 5. En la ratonera: Shopping.com 6. En la ratonera (2): ChecksNet 7. Archivos sobre Hacking en la Web 8. Polφtica internacional de cifrado 9. Productos Internacionales de cifrado 10. 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 ---------------------------------------------------------------- 1. Virus de e-mail, Gusanos y Caballos de Troya ----------------------------------------------- Por Bruce Schneier Traducci≤n: Isidre Marques Serret Mirando hacia atrßs desde el futuro, 1999 habrß sido un a±o clave para el software malicioso: los virus, gusanos, y caballos de Troya, colectivamente conocidos como "malware" (N.T: de "malicious software"). No ha sido simplemente mßs cantidad de "malware"; hemos visto ya miles. No es el "malware" en Internet; tambiΘn lo hemos visto antes. Pero este es el primer a±o en que hemos visto "malware" que usa el e-mail para propagarse sobre Internet y atravesar los cortafuegos. Y eso es un asunto serio. Los virus y los gusanos sobreviven reproduciΘndose sobre nuevos ordenadores. Antes de Internet, los ordenadores se comunicaban principalmente mediante discos flexibles. Por lo tanto, la mayorφa de los virus se propagaban sobre discos flexibles, y a veces sobre sistemas de BBS. Hay algunos problemas obvios al usar discos flexibles como medio de transmisi≤n. Primero, el "malware" se propaga lentamente. Un usuario comparte un disco con otro que lo comparte con cinco mßs, y en semanas o meses el virus se convierte en una epidemia. O quizß alguien pone un programa infectado con el virus en una BBS, y consigue infectar millares de ordenadores en una semana o dos. Segundo, es fßcil bloquear el "malware" transmitido a travΘs de discos. La mayorφa de programas antivirus pueden repasar automßticamente todos los discos flexibles. El "malware" se encuentra la puerta cerrada. Las BBS puede todavφa representar un problema, pero la mayorφa de usuarios de ordenadores se habit·an a no bajar nunca software desde una BBS. A·n asφ, los programas antivirus puede repasar automßticamente los nuevos archivos para detectar el "malware". Y tercero, el software antivirus puede tratar fßcilmente con el problema. Es fßcil escribir software para bloquear "malware" si se le conoce. Simplemente el antivirus debe buscar las cadenas de bits que identifican al virus (conocidas como la "firma") y entonces ejecutar el programa automßtico para borrar el virus y restaurar normalidad. Esta rutina de eliminaci≤n es ·nica para cada virus, pero no es difφcil de desarrollar. El software antivirus contiene decenas de miles de firmas, cada una para un virus en particular. Las compa±φas los lanzan en un dφa despuΘs de identificar el nuevo virus. Y mientras los virus se propagan lentamente, esto es suficiente. Mi software se actualiza automßticamente una vez al mes. Hasta 1999, era suficiente. La novedad en 1999 es la propagaci≤n del "malware" a travΘs del e-mail. Estos programas -el virus Melissa y sus variantes, el gusano Worm.ExploreZip y sus inevitables variantes, etc.- llegan por medio del e-mail y utilizan las capacidades de e-mail de muchos programas modernos para autorreplicarse a travΘs de la red. Se envφan a los conocidos de la vφctima infectada, convenciendo a los receptores para abrir o ejecutar el archivo. No se propagan en semanas o meses; se propagan en segundos. El software antivirus no puede mantenerse a su nivel. Y el e-mail estß en todos lados. Corre sobre conexiones de Internet que bloquean todo lo demßs. Atraviesa todos los cortafuegos. Todo el mundo lo usa. Es fßcil se±alar con el dedo a Microsoft. Melissa se aprovecha de las posibilidades de Microsoft Word (y algunas variantes de las de Excel) para enviarse automßticamente por e-mail a otros, y Melissa y Worm.ExploreZip tambiΘn se aprovechan de las capacidades de automatizaci≤n de correo de Microsoft Outlook. Microsoft es seguramente culpable de crear las poderosas capacidades de las macros de Word y Excel, dificultando la distinci≤n entre archivos ejecutables (que pueden ser peligrosos) y los archivos de datos (que, hasta ahora, eran seguros). Se les podrß echar la culpa cuando Outlook 2000, que soporta HTML, haga posible ser atacado por "malware" basado en HTML simplemente abriendo un e-mail. Microsoft estableci≤ el nivel estßndar de seguridad hace 25 a±os con el DOS, y ha continuado ese legado hasta ahora. Seguramente tienen un mucho por lo que responder, pero el problema es mucho mßs sutil. Uno de los problemas es la naturaleza permisiva de Internet y los ordenadores conectados a ella. Mientras un programa tenga la capacidad para hacer cualquier cosa sobre el ordenador en que se ejecuta, el "malware" serß increφblemente peligroso. Asφ como los cortafuegos protegen a los distintos ordenadores de una misma red, vamos a necesitar que algo parecido proteja a los diferentes procesos que se ejecutan sobre el mismo ordenador. Este problema no puede detenerse con el cortafuegos. Este tipo de "malware" atraviesa los cortafuegos usando el e-mail, y aparece inesperadamente en el interior y hace da±o. Hasta ahora los ejemplos han sido leves, pero representan una prueba del concepto. Y la eficacia de los cortafuegos disminuirß al abrir mßs servicios (e-mail, Web, etc.), al agregar aplicaciones cada vez mßs complejas ejecutßndose sobre la red interna, y al ser los crackers cada vez mßs hßbiles. Esta tΘcnica de "meterse dentro y actuar" solo va a empeorar. Y el software antivirus no puede hacer mucho. Si un virus puede infectar 1,2 millones de ordenadores (una estimaci≤n de las infecciones de Melissa) en las horas anteriores a que se publique una soluci≤n, esto es mucho da±o. ┐QuΘ pasarφa si el programa se hubiera preocupado de ocultarse, para no ser descubierto en un par de dφas? ┐QuΘ pasarφa si un gusano estuviera dirigido a un ·nico individuo, borrßndose de los ordenadores cuya identificaci≤n de usuario no fuera la deseada? ┐Cußnto tiempo pasarφa antes de que se descubriese? ┐QuΘ pasarφa si enviara por e-mail una copia del script de login del usuario (la mayorφa contienen contrase±as) a un e-mail an≤nimo antes de borrarse? ┐QuΘ pasarφa si automßticamente cifrara las copias salientes de sφ mismo con PGP o S/MIME? O se firmara a sφ mismo; la claves de firma se suelen dejar tranquilamente en el sistema. Simplemente plantearse estas posibilidades nos ofrece unas perspectivas terribles. Es imposible transmitir el problema a los usuarios con mensajes del tipo "┐confφa en este mensaje/macro/aplicaci≤n?" Seguro, es imprudente ejecutar software de extra±os, pero Melissa y Worm.ExploreZip llegan pretendiendo proceder de amigos y socios del receptor. Worm.ExploreZip incluso contesta a autΘnticas lφneas de asunto. Si los usuarios no pueden tomar buenas decisiones de seguridad bajo condiciones ideales, no tienen ninguna posibilidad contra un virus capaz de practicar la ingenierφa social. Lo que vemos aquφ es la uni≤n de varios problemas: la permisividad de las redes, las interconexiones entre aplicaciones en los modernos sistemas operativos, el e-mail como un medio de atravesar las defensas de red y para extenderse muy rßpidamente, y la candidez tradicional de los usuarios. Los simples parches no solucionarßn esto. Hay algunas tecnologφas interesantes en estudio que tratan de imitar el sistema inmunitario de los seres vivos para enfrentarse automßticamente al "malware" desconocido, pero no soy muy optimista con respecto a ellas. Seguro que detendrßn a algunos programas, pero siempre serß posible dise±ar "malware" especφficamente para derrotar a los sistemas inmunes. Un gran sistema distribuido que se comunica a la velocidad de la luz tendrß que aceptar la posibilidad de infecciones vφricas a la velocidad de la luz. A menos que el sistema se dise±e con la seguridad como objetivo prioritario de principio a fin, vamos a tener que enfrentarnos continuamente a estos ataques. Melissa: http://www.zdnet.com/zdnn/stories/news/0,4586,2233116,00.html http://www.zdnet.com/zdnn/stories/news/0,4586,2234121,00.html Worm.ExploreZip: http://www.zdnet.com/zdnn/stories/news/0,4586,2274306,00.html http://www.wired.com/news/news/politics/story/20160.html http://www.symantec.com/press/1999/n990614d.html 2. Counterpane Systems: investigaci≤n documentada ------------------------------------------------- Por Bruce Schneier Traducci≤n: Antoni Muntaner "Proteger Claves Secretas mediante Entropφa Personal" C. Ellison, C. Hall, R. Milbert, y B. Schneier, LA FUTURA GENERACION DE SISTEMAS INFORMATICOS, de pr≤xima aparici≤n. La tecnologφa convencional de cifrado requiere a menudo de los usuarios la protecci≤n de una clave secreta mediante una contrase±a (palabra o frase). Aunque una buena contrase±a serß conocida s≤lo por el usuario, tiene como defecto que debe ser recordada con total exactitud para poder recuperar la clave secreta. A medida que pasa el tiempo, la capacidad de recordar esta frase se desvanece y uno puede, de esta forma, llegar a perder el acceso a la clave secreta. Aquφ proponemos un esquema mediante el cual un usuario puede proteger una clave con una "entropφa personal" basada en su propia vida, cifrando la frase secreta en base a las respuestas a una serie de cuestiones de φndole personal. Hemos dise±ado el esquema de forma que el usuario pueda olvidar las respuestas a una parte de las preguntas y a·n asφ recuperar la clave secreta, mientras que un atacante tendrφa que aprenderse la respuesta a una gran parte de las preguntas para poder ganar acceso la clave secreta. http://www.counterpane.com/personal-entropy.html 3. Noticias --------------------------- Por Bruce Schneier Traducci≤n: Antoni Muntaner Husmail es como Hotmail, pero cifrado. Implementan SSL desde el navegador al servidor y utilizan Blowfish para cifrar los mensajes. Correo electr≤nico seguro y gratis para las masas. Su c≤digo fuente puede descargarse gratuitamente. Ademßs, el producto se ha desarrollado fuera del paφs, por lo que no le afectan las restricciones a la exportaci≤n. No he visto ninguna evaluaci≤n del c≤digo, pero es una buena idea. En las noticias: http://www.wired.com/news/news/email/explode-infobeat/technology/story/19804.html Hushmail: http://www.hushmail.com Resumen tΘcnico: https://www.hushmail.com/tech_description.htm C≤digo fuente: http://www.cypherpunks.ai/~hush/hush-src.103.zip Y ZipLip es un servicio competidor de e-mail seguro vφa Web: http://www.techweb.com/wire/story/TWB19990526S0002 EscribirΘ mßs sobre ambos productos el mes pr≤ximo. La agencia francesa de datos CNIL estß investigando a Microsoft e Intel, para determinar si sus payasadas anti-privacidad estßn violando alguna ley europea de protecci≤n de datos. http://www.europa.eu.int/comm/dg15/en/media/dataprot/wpdocs/wp16en.htm http://www.europa.eu.int/comm/dg15/en/media/dataprot/wpdocs/wp17en.htm Un informe sobre c≤mo se ha liberalizado en Francia la criptografφa de 128 bits: http://jya.com/jospin-coup.htm Estados Unidos ha sido acusado de utilizar el dep≤sito obligatorio de claves para robar informaciones secretas. http://www.techweb.com/wire/story/TWB19990518S0004 http://www.nytimes.com/techweb/ TW_Report_U_S_Uses_Key_Escrow_To_Steal_Secrets.html C≤mo discutir acerca de Blowfish con sus hijos. http://www.hcs.harvard.edu/~demon/issues/apr_26_1999/blowfish/blowfish.html Existen rumores de que la CIA estß utilizando ordenadores para atacar las cuentas de Banco extranjeras del lφder yugoslavo Milosevich. http://www.techweb.com/wire/story/reuters/REU19990524S0001 "┌ltimamente hemos tenido motivos para preguntarnos si la polφtica de nuestra naci≤n sobre criptografφa estß siendo llevada a cabo por idiotas. Es una ventaja a medias enterarnos de que estas personas son simplemente unos mentirosos". Un buen editorial. http://www.zdnet.com/pcweek/stories/columns/0,4351,403283,00.html Ha sido publicado OpenSSL, una herramienta de c≤digo abierto para SSL y TLS, versi≤n 0.9.3. http://www.openssl.org He aquφ una Web que proporciona primitivas aleatorias y polinomios irreducibles, ·tiles para la construcci≤n de cifrados de flujo. http://www.dmi.ens.fr/~chabaud/Poly/polyform.html Los Bancos USA estßn abriendo laboratorios para analizar los productos de seguridad informßtica. http://www.news.com/News/Item/0,4,36923,00.html Electronic Telegraph tiene un interesante artφculo sobre la seguridad de las cajas fuertes: c≤mo estßn hechas, c≤mo pueden ser violentadas. Nunca imaginΘ que las cajas fuertes se clasificaran seg·n el importe del seguro que protege el efectivo que contienen. http://www.telegraph.co.uk:80/et?ac=000647321007942&rtmo= Q9QwSezR&atmo=99999999&pg=/et/99/5/13/ecfsafe13.html Secci≤n de buenas noticias: el Reino Unido ha invertido su postura con respecto al dep≤sito obligatorio de claves. El gobierno de Blair ha rechazado una propuesta que lo hubiera requerido. http://www.infoworld.com/cgi-bin/displayStory.pl?990527.icblair.htm Alguien ha escrito un simulador de mßquina Enigma que funciona con iButton. Asφ que cualquiera puede tener una Enigma para descifrar c≤digos. http://www.javaworld.com/jw-08-1998/jw-08-indepth.html El Grupo de Estudio de la Seguridad Nacional (alguna otra agencia del gobierno) ha lanzado un sitio web (http://www.nssg.gov) para promover el debate p·blico sobre la seguridad nacional en el siglo XXI. Sean buenos y no les jaqueen al menos durante una semana. http://www.fcw.com/pubs/fcw/1999/0531/fcw-agsitesurv-05-31-99.html Enviar mensajes secretos en DNA. http://news.bbc.co.uk/hi/english/sci/tech/newsid_365000/365183.stm http://news.excite.com/news/r/990610/02/science-dna-microdot http://www.cnn.com/NATURE/9906/10/top.secret.dna.ap/ CGHQ, el equivalente britßnico de la NSA, se estß trasladando. Su nuevo emplazamiento albergarß a 4.500 personas, y deberφa estar finalizado hacia el 2002. http://www.guardianunlimited.co.uk/Archive/Article/0,4273,3862710,00.html Alemania se adhiere a la corriente de promover la criptografφa potente. No parecen estar muy convencidos de que los Estados Unidos no les espφen. http://www.wired.com/news/news/politics/story/20023.html 4. Noticias de Counterpane Systems ---------------------------------- Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez Black Hat Briefings '99 es una conferencia de seguridad informßtica prevista para los dφas 7 y 8 de Julio en Las Vegas, Nevada. DefCon es un congreso de hackers que tendrß lugar al siguiente fin de semana. Bruce Schneier hablarß en ambas. http://www.blackhat.com http://www.defcon.org 5. En la ratonera: Shopping.com ------------------------------- Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez Para comprar sin tener que preocuparse de la seguridad, esto es imbatible: "Shopping.com utiliza cifrado comercial de los laboratorios RSA, autorizado para exportar (RC4-Export, 128 bit, 40 secretos). ┐En quΘ le afecta eso a usted? RSA protege sus comunicaciones sensibles en Internet (como su n·mero de tarjeta de crΘdito) transformando los datos a un formato ilegible. A·n mßs: Shopping.com asegura la intimidad de la informaci≤n no s≤lo en lφnea, sino tambiΘn en nuestros propios sistemas." íGuau! estoy impresionado. http://www.shopping.com/store/INFO/INFO_SECURE.ASP?nav=|-1|-1|-1|-1|-1&x=cgi -bin 6. En la ratonera (2): ChecksNet -------------------------------- Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez TambiΘn pueden enviarse sin proteger los datos de su cuenta bancaria por Internet. Pida los cheques a esta gente. Su pßgina web lo dice claramente: "ChecksNet protege su informaci≤n personal y bancaria del robo o uso fraudulento, a base de codificar los datos cuando son transmitidos desde este sitio web a nosotros." Sin embargo, el formulario de pedido es enviado en claro; no utilizan SSL. http://www.checksnet.com/order.htm 7. Archivos sobre Hacking en la Web ----------------------------------- Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez Existe un mont≤n de informaci≤n sobre hacking en la Red, pero hay que dedicar tiempo a buscarla. Teclear "hacker archive" en Altavista produce mßs de tres millones de referencias. La informaci≤n de Yahoo estß mucho mejor organizada, pero tambiΘn son demasiadas pßginas por las que navegar. Un gran sitio para empezar es http://www.infoworld.com/cgi-bin/displayNew.pl?/security/links/security_corner.htm. Estos chicos escriben una columna semanal sobre seguridad en InfoWorld y su sitio estß lleno de enlaces recomendables sobre seguridad. Cuando ando buscando algo, suelo ir primero allφ. El sitio donde pasaba la mayor parte del tiempo era http://www.genocide2600.com/~tattooman/main.shtml, porque parecφa bien organizado. No obstante, estaba claro que se trataba de un archivo, no de un directorio. Si estß intentando encontrar un truco concreto para alg·n programa en particular, y en un sistema operativo concreto, hßgase a la idea de pasar mucho tiempo buscando. El material estß clasificado por categorφas generales, pero las descripciones son escasas. Sin embargo, si estß buscando avisos sobre recientes agujeros de seguridad y formas de explotarlos, estßn claramente ordenados por fechas. Para un no-hacker como yo, la mayorφa de este material supera con creces mi nivel de conocimientos. A·n asφ, hay una buena cantidad de material ·til e impactante. Basta con leer las descripciones de los ficheros para que cualquiera pierda su fe en cualquier tipo de seguridad en redes. Ademßs de vulnerabilidades y formas de aprovecharlas, hay herramientas de seguridad para Windows, Novell y Unix, reventadores de contrase±as, herramientas variadas para jaquear, utilidades genΘricas y (por si acaso habφa usted olvidado que el hacking es una subcultura) ficheros humorφsticos. Existen tambiΘn enlaces a archivos de listas de discusi≤n de hackers. Otros archivos pueden ser: El archivo sobre hackers de la EFF: http://www.eff.org/pub/Net_culture/Hackers/ Los archivos de 2600 Magazine y Phrack Magazine: http://www.2600.com http://www.phrack.com Y la pßgina sobre hackers de Netscape, con enlaces a los principales sitios de hackers de la Web: http://excite.netscape.com/computing_and_internet/programming/hacking La ·ltima es la pßgina web que me ha parecido mßs interesante de toda la selecci≤n. El Hacking adquiere carta de naturaleza si Netscape lista abiertamente los enlaces en lugar de intentar aparentar que no existen. En general, los hackers (al menos en su faceta p·blica) estßn mßs interesados en entrar en sistemas y desvelar vulnerabilidades que en causar da±o o robar dinero. Pero la mayorφa de los sitios ostentan todavφa descargos de responsabilidad alegando que su informaci≤n es s≤lo para fines educativos y no para cometer delitos que pudieran ser atribuidos a la informaci≤n proporcionada. Con la Primera Enmienda o sin ella, mucho de esto no estß nada claro. 8. Polφtica internacional de cifrado ------------------------------------ Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mas EPIC ha presentado su "Cryptography & Liberty 1999: An International Survey of Encryption Policy" ("Criptografφa y Libertad 1999: Un Estudio Internacional sobre Polφtica relacionada con la Criptografφa"). Es una excelente investigaci≤n sobre polφtica internacional relacionada con la criptografφa (tiene unas 130 pßginas) producida por el Electronic Privacy Information Center (EPIC). ╔ste es el resumen introductorio: "La mayorφa de los paφses del mundo hoy en dφa no imponen controles al uso de criptografφa. En la gran mayorφa de los paφses, la criptografφa puede usarse, fabricarse y venderse libremente y sin restricciones. Esto es cierto tanto en los paφses mßs industrializados como en los paφses en vφas de desarrollo. Hay una tendencia hacia la reducci≤n internacional de las regulaciones que vigilan a los productos criptogrßficos, acompa±ada de un rechazo a los sistemas de almacenamiento centralizado de claves. Muchos paφses han adoptado recientemente leyes que prohiben expresamente la obligatoriedad del uso de sistemas de almacenamiento centralizado de claves, destacando en este grupo Francia, que ha decidido eliminar sus sistemas centralizados. Hay un peque±o n·mero de paφses en los que existen fuertes controles al uso de criptografφa dentro del paφs. Son en su mayorφa paφses donde apenas se tienen en cuenta los derechos humanos". "Las ·ltimas tendencias en la legislaci≤n internacional apuntan hacia una continua reducci≤n de los controles sobre la criptografφa. Las Recomendaciones de la Organizaci≤n para la Cooperaci≤n y el Desarrollo Econ≤mico (OCDE) y la Declaraci≤n Ministerial de la Uni≤n Europea, ambas presentadas en 1997, piden la liberalizaci≤n de los controles sobre la criptografφa y el desarrollo de productos y servicios criptogrßficos comerciales para los usuarios. Hay una creciente conciencia en todo el mundo sobre la importancia de la criptografφa y un n·mero cada vez mayor de paφses han desarrollado leyes que aplican las Recomendaciones de la OCDE". "Los controles a la exportaci≤n siguen siendo el mayor obstßculo que se interpone en el libre desarrollo y circulaci≤n de la criptografφa. La revisi≤n de diciembre de 1998 del Acuerdo de Wassenaar puede hacer retroceder en parte la liberalizaci≤n impulsada por la OCDE, en particular al restringir el tama±o de las claves de los productos criptogrßficos que pueden ser exportados sin requerir licencia. Sin embargo, algunos de los paφses mßs importantes han anunciado ya que no estß en sus planes introducir nuevas restricciones". "El gobierno de Estados Unidos sigue llevando adelante sus esfuerzos para conseguir controlar la criptografφa en todo el mundo. El gobierno americano ha ejercido presiones econ≤micas y diplomßticas sobre otros paφses en un intento de forzarles a adoptar polφticas restrictivas. La postura de Estados Unidos puede explicarse, en parte, por el papel dominante que tienen las agencias de inteligencia y de seguridad en el desarrollo de leyes sobre criptografφa". http://www2.epic.org/reports/crypto1999.html 9. Productos Internacionales de cifrado --------------------------------------- Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mas La ACP ha presentado un estudio sobre la disponibilidad de productos criptogrßficos internacionales. Se titula "Growing Development of Foreign Encryption Products in the Face of U.S. Export Regulations" ("El Creciente Desarrollo de Productos Criptogrßficos en el Extranjero debido a las Leyes de Exportaci≤n de Estados Unidos"). Extractos del resumen introductorio: "El desarrollo de productos criptogrßficos fuera de Estados Unidos no s≤lo contin·a, sino que se estß expandiendo en mßs paφses; con el rßpido crecimiento de Internet, la criptografφa relacionada con comunicaciones es la que especialmente experimenta un alto crecimiento, sobre todo en las ßreas del correo electr≤nico, las redes privadas virtuales y los productos IPsec. Este informe investiga los productos criptogrßficos desarrollados fuera de Estados Unidos y proporciona cierta informaci≤n sobre el efecto que tiene la legislaci≤n de controles de exportaci≤n de Estados Unidos sobre los fabricantes americanos y extranjeros". "Hemos identificado 805 productos, tanto hardware como software, que incluyen criptografφa fabricados en 35 paφses distintos de Estados Unidos. La mayorφa de estos productos se fabrican en el Reino Unido, seguido de Alemania, Canadß, Australia, Suiza, Suecia, Holanda e Israel. Otros paφses engloban un poco mßs de la cuarta parte del total mundial de productos criptogrßficos". "Estos 805 productos criptogrßficos representan un incremento de 149 productos (el 22%) respecto el anterior estudio de diciembre de 1997. En estos nuevos productos criptogrßficos extranjeros predomina el software sobre el hardware. Asimismo, la mayorφa de estos nuevos productos estßn orientados mßs hacia la comunicaci≤n que hacia el almacenamiento de datos; tienden fuertemente hacia las ßreas de correo electr≤nico seguro, seguridad en IP (IPsec), y Redes Privadas Virtuales". "Identificamos al menos 167 productos criptogrßficos extranjeros que usan criptografφa fuerte con estos algoritmos: DES Triple , IDEA, Blowfish, RC5, o CAST-128. A pesar del creciente uso de estas superiores alternativas a DES, todavφa DES contin·a ofreciΘndose en un gran n·mero de productos, aunque esperamos ver una disminuci≤n en los pr≤ximos a±os". "Normalmente, se puede considerar comparable la calidad de los productos extranjeros con la de los de Estados Unidos. Hay un cierto n·mero de productos criptogrßficos extranjeros de gran calidad que son muy competitivos en fuerza, seguimiento de estßndars y funcionalidad". http://www.seas.gwu.edu/seas/institutes/cpi/library/docs/cpi-1999-02.pdf 10. Comentarios de los lectores ------------------------------- Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna y Angel Galindo Sßnchez [1. Traducciones de Juan Cruz Ruiz de Gauna] De: "John C. Kennedy" transmog@worldnet.att.net Asunto: Novell ----------------------------------------------- Habiendo trabajado estrechamente con el grupo de seguridad de Novell durante los ·ltimos tres a±os y medio en criptografφa y temas de seguridad en red, quisiera se±alar un par de cosas que no son demasiado obvias acerca del ataque a la consola remota de cifrado de passwords sobre el que informaste en tu ·ltimo boletφn. (Descargo de responsabilidad: Esto no constituye una respuesta oficial de Novell, simplemente es un comentario constructivo por parte de un miembro bien informado). El uso de la caracterφstica de consola remota para gestionar servidores NetWare es algo que Novell no ha recomendado durante bastante tiempo. El acceso a servidores a travΘs de la consola es algo que Novell recomienda encarecidamente proteger a travΘs de restricciones fφsicas de acceso: http://developer.novell.com/research/appnotes/1997/november/06/04.htm Los expertos de seguridad de Novell *siempre* han considerado el uso de las capacidades de la consola remota como un riesgo fundamental. El acceso a la consola permite acceso directo a la base de datos de seguridad de Novell. Sin embargo, cuando los clientes piden una caracterφstica de este tipo y estßn dispuestos a asumir los riesgos, es difφcil para una compa±φa negarse a ello. Si alguien eval·a la seguridad de la red desde la perspectiva del "eslab≤n mßs dΘbil de la cadena", es un hecho que el que el acceso a los servicios de consola estΘ disponible de forma remota *por completo* es probablemente un riesgo mayor que el uso de una tΘcnica de cifrado de passwords dΘbil. El acceso a la consola no es algo que debiera concederse a partir de un simple factor de autenticaci≤n, pero en muchos entornos de "bajo riesgo" consituye un equilibrio aceptable de riesgo/conveniencia. La tΘcnica de confusi≤n de passwords puede parecer poco seria a primera vista, pero es mßs probable que su uso se deba a alg·n tema de exportabilidad que a falta de experiencia o conocimiento dentro del grupo de seguridad de Novell. El dise±o es anterior en un par de a±os a mi relaci≤n con Novell, pero estoy seguro de que no es algo debido a la falta de conocimientos dentro del personal de seguridad. Las tΘcnicas de confusi≤n no son algo por lo que uno apostarφa su casa, y Novell advierte seriamente acerca de que el uso de la consola remota refleja esto. Novell ha estado trabajando durante los dos ·ltimos a±os en una arquitectura que permita una cifrado robusta para prop≤sitos de autenticaci≤n sin permitir que la misma capacidad sea explotada como un mΘtodo descontrolado para confidencialidad. Este no es un problema fßcil de abordar, pero de hecho la nueva arquitectura de servicios criptogrßficos internacionales de Novell resuelve este problema de "criptografφa con un agujero" tanto para Novell como para sus clientes (http://www.novell.com/corp/security/). Sin importar la posici≤n que ocupemos en el asunto de la exportaci≤n de criptografφa, todos sabemos que Θste ha sido un autΘntico problema para los vendedores de software y hardware durante bastante tiempo. Es un problema especialmente difφcil de resolver para compa±φas que trabajan con tan diferentes jurisdicciones referentes a importaci≤n/exportaci≤n. Las leyes de exportaci≤n de Estados Unidos encuentran su correspondencia en leyes de importaci≤n igualmente restrictivas en bastantes paφses. La habilidad para sortear las polφticas de control de criptografφa permitirß a Novell ofrecer nuevos mecanismos de seguridad al mercado global basados en criptografφa que sea "robusta" a travΘs de cualquier medida. Pienso que tu reprimenda hacia Novell es bien intencionada, pero te falta admitir que, (1) la criptografφa dΘbil *no es* siempre el eslab≤n mßs dΘbil en la cadena de la seguridad y (2), que las leyes de importaci≤n/exportaci≤n han tenido, hasta la fecha, resultados predecibles e inevitables en el dise±o de software destinado a mercados globales. Lo que llamamos "criptografφa robusta" puede producir un falso sentido de seguridad o, si no, ser contraproducente cuando se observa desde el amplio contexto al que muchos vendedores tienen que dirigirse. Un contexto al que, de hecho, los observadores mßs casuales no tienen la paciencia o el conocimiento necesarios para dirigirse. De: "Robert A. Lerche" ral@msbit.com Asunto: Microsoft Internet Explorer (MS IE) --------------------------------------------- MS IE no ofrece un medio para encriptar certificados personales descargados. Netscape solicita una contrase±a y encripta el almacenamiento local (aunque creo que se permite especificar una contrase±a en blanco), pero MS IE no lo hace. De: "Jack Hewlett" jackhewlett@hotmail.com Asunto: ┐QuiΘn estß expuesto al riesgo? -------------------------------------------- Continuamente publicas artφculos diciendo lo malos que son varios productos de seguridad. Por tanto, la pregunta evidente es, "┐QuiΘn estß expuesto al riesgo, el comerciante o el consumidor?" Yo nunca he entendido la necesidad de mantener en secreto el m·mero de mis tarjetas de crΘdito. A mi me parece que podrφa publicar el n·mero de mi tarjeta de crΘdito en el peri≤dico y "Yo" íno estarφa expuesto a ning·n riesgo!. Si aparece un cargo en mi extracto mensual y puedo demostrar alguna de las siguientes caracterφsticas: 1.- La mercancφa no fue enviada a mi direcci≤n. 2.- El comerciante no dispone de un trozo de papel que contenga mi firma. 3.- El comerciante no dispone de una grabaci≤n que contenga mi voz. Entonces a mφ me parece que no tengo ninguna obligaci≤n legal de pagar esta parte de la factura. Esto es algo muy importante para los compradores. Si todo el riesgo asociado con la debilidad en la seguridad del software recae sobre el comerciante, entonces yo no tengo por quΘ preocuparme sobre este asunto. Si mis suposiciones son incorrectas, entonces ┐c≤mo me protejo contra todos los cajeros que ven el n·mero de mi tarjeta de crΘdito cuando hago uso de ella en un comercio? Yo entiendo que tengo obligaciones legales respecto a informar del robo de una tarjeta cuando ya no tengo posesi≤n fφsica sobre ella. Pero, desde el momento en que es imposible para mφ controlar el conocimiento del n·mero (y fecha de caducidad), ┐puede la "letra peque±a" del contrato de aceptaci≤n de la tarjeta de crΘdito que yo firmΘ convertirme en responsable fiscal de algo que yo no puedo controlar? incluso si yo firmΘ esos tΘrminos, ┐pueden ganarme en un juicio, cuando yo argumente que no hice nada mal y actuΘ de manera prudente?. [2. Traducci≤n: Angel Galindo Sßnchez] De: Geoff Thorpe geoff@raas.co.nz Asunto: Pirateo de CAs de raφz en Internet Explorer --------------------------------------------------- Quiero hacer algunas anotaciones al correo electr≤nico de mi colega Peter Gutmann sobre la sustituci≤n de CAs de raiz en el "almacΘn de certificados" ["certificate store"] de IE. Creo que ya le avisΘ de Θsto, pero el problema persiste en las versiones mßs recientes. IE versi≤n 4 tambiΘn almacena las extensiones ".der" de forma que un certificado X509 CA codificado ASN y auto-firmadoguardado como cert.der, sobre el que se haga doble click lanzarß automßticamente el cuadro de dißlogo "┐Aceptar nuevo certificado CA?" de IE. Por defecto, todas las opciones estßn habilitadas (marcadas), incluyendo la autentificaci≤n de certificados de clientes y servidores (https), autentificaci≤n de certificados de correo electr≤nico (S/MIME), y firma de software (Authenticode). Incluso el bot≤n por defecto es "OK", asφ que es suficiente con pulsar "Enter". Han incluido un nuevo cuadro de dißlogo, por lo que al seleccionar "OK" aparece un breve mensaje de advertencia, muestra en pantalla toda la informaci≤n sobre el certificado (componentes principales del nombre, fechas de expiraci≤n, etcΘtera) y el bot≤n por defecto es "No" (hay que pulsar "Yes" para aceptarlo). Esto no afecta al hecho de que la mayorφa de los usuarios no comprenderßn realmente el agujero de seguridad que este hecho crea para ellos - aunque por lo menos Netscape Communicator permite en cierta manera que sepan que VERDADERAMENTE deberφan comprobar la autenticidad del certificado antes de concederle demasiada confianza - y tienen una fantßstica opci≤n de dar siempre mensajes de advertencia cuando se utilicen certificados firmados por el nuevo certificado CA en cuesti≤n. Existe un ataque muy peligroso que se permite mediante esta actitud tan laxa hacia la aceptaci≤n de certificados CA. Si puedes conseguir que alguien con una llave de firma Authenticode (tal vez alg·n programador tiene un certificado firmado por Verisign o cualquiera otra empresa) acepte un certificado CA firmado por una compa±φa famosa, entonces puedes estropearlo todo. Puedes introducir un c≤digo fuente en un fichero con firma .cab (firmado con un certificado que estß firmado por esa compa±φa famosa) en la mßquina del programador (se confφa en Θl, por lo que no aparecerßn mensajes de error - y, dependiendo de su configuraci≤n, podrφa no advertir nada en absoluto). Ese c≤digo fuente puede utilizar el CryptoAPI de MS para conseguir la llave privada Authenticode del programador (normalmente, el API no pide ninguna contrase±a para facilitar la llave) y enviarla por correo al hacker. Entonces, ese hacker tendrφa la llave y el certificado para firmar c≤digo de otra persona. Utilizßndolos, podrφa distribuir virus firmados, y facilitar versiones pirateadas de software (quizßs proporcionando una imitaci≤n de alg·n software popular que simplemente consista en algunas modificaciones elegantes y creativas variaciones) - y si las fuerzas de la ley se interesan por el tema alguna vez, la ·nica pista que tendrφan serφa el certificado Authenticode del desafortunado programador. Por supuesto, si el hacker puede colocar certificados CA de empresas conocidas en cualquier sitio, Θl/ella podrφa simplemente crear su propia compa±φa de certificaci≤n falsa, utilizando alg·n nombre familiar (tal vez llamado "Microsoft Corp."), y utilizarlos. El aspecto realmente importante aquφ es que el hacker s≤lo necesita introducir el CA familiar en la mßquina de un ·nico programador (no de todos aquellos a los que quiera hackear). Al final, Θl/ella tiene el certificado digital de alguna otra persona, con el que hacer estragos. Esto me lleva a otro aspecto que deseo mencionar, y que estß relacionado con un antiguo proyecto en el que participΘ. Microsoft tiene su propia configuraci≤n, almacenamiento y APIs para otorgar confianza a los certificados; lo mismo ocurre con Netscape, lo mismo ocurre con cualquier gestor de correo que incluya S/MIME, lo mismo ocurre con cualquier herramienta de "tunelizaci≤n" segura, etcΘtera, etcΘtera. Esto no s≤lo ha llevado a una completa descentralizaci≤n (prßcticamente en cada aplicaci≤n) en el sistema del usuario de sus configuraciones sobre el otorgamiento de confianza, sino que ademßs ha llevado a los inevitables problemas de compatibilidad entre los estßndares - simplemente pregunte a cualquiera que estΘ trabajando para alguna autoridad de certificaci≤n sobre el procesamiento de peticiones de certificados para IE (en sus diferentes versiones), Navigator y los mßs populares servidores de web. Todos ellos son mutaciones y modificaciones de ASN, X509, PEM y MIME que dan grandes quebradeos de cabeza a cualquiera que quiera so±ar en la intercompatibilidad. Hasta ahora, no conozco a nadie que haya sido capaz de hacer un ·nico certificado de usuario (con llave privada) que funcione simultßneamente en el Communicator y en el IE. Mi idea ha sido denominada como "PKI kernel" - una librerφa e interface que supuestamente estßn presentes y son utilizables en todos los sistemas que se estßn compilando y desarrollando. A pesar de la proliferaci≤n de varios recursos PKI que utilizan diferentes estßndares (PKIX, etcΘtera) e interfaces, quise poner la mφnima cantidad de c≤digo necesaria para permitir la centralizaci≤n - y para asegurar que no impone restricciones funcionales a las aplicaciones que lo utilizan. Por ejemplo, pensΘ que no deberφa tener una arquitectura de plugins de proveedor, ya que sus ventajas vendrφan del hecho de que fuera singular y ubicuota en cualquier sistema. No tendrφa ninguna herramienta de cifrado (cifrado, cifrado PKC, etcΘtera), ni ning·n servicio (tunelizaci≤n SSL, SSH, etcΘtera) - serφa simplemente una forma de centralizar los certificados de raφz, certificados de usuario, peticiones de certificado pendientes y llaves privadas. En su forma mßs rudimentaria, serφa como un dep≤sito de certificados multiuso. En su forma mßs refinada, serφa una red estricta donde el usuario raφz ha estipulado que los procedimientos se hereden de otro sistema, y que s≤lo ciertos certificados puedan ser utilizados para ciertas cosas. Por ejemplo, si una aplicaci≤n pidiera al sistema la lista de certificados de usuario para utilizar con los "https" o quisiera comprobar si se puede confiar en un determinado certificado CA para una tarea dada, el procedimiento podrφa estipular que cualquier certificado de usuario firmado que quiera utilizarse con S/MIME deberφa tener al menos 1024 bits y estar firmado por la autoridad de certificaci≤n "X", etcΘtera. Parece como si cada sistema operativo tuviera un concepto de "gesti≤n de firmas", e incluso cada programa con opciones de cifrado parece tener su propio concepto de asignaci≤n de confianza a certificados de raiz, polφticas de certificaci≤n, utilizaci≤n de claves, y de todas las incompatibilidades asociadas a ellos. Todos utilizan los mismos "protocolos" (SSL/TLS, S/MIME, etcΘtera), y todos usan los mismos "algoritmos" (RC4, RSA, etcΘtera), porque todo el mundo estß sensiblemente de acuerdo que es mejor tener un ·nico estßndar que varios simultßneamente, aunque a menudo no se tiene en cuenta que la autenticidad y la identificaci≤n dependen mucho del cuidado en el manejo coordinado de la certificaci≤n, donde cada aplicaci≤n parece querer tener su propio criterio. ----------------------------------------------------------------- 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: * Isidre MarquΘs Serret <ismase@mx3.redestb.es> * Juan Ruiz de Gauna Gorostiza <juancruz.ruiz@unavarra.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> ------------------------------------------------------------------