1999 << Back To criptograma nº 17

C R I P T O G R A M A _______________________________________________________________ N·mero 17 15 de Septiembre de 1999 ________________________________________________________________ SUMARIO: C≤digo abierto y seguridad ┐Clave de la NSA en Microsoft Crypto API? Counterpane Systems: Investigaci≤n documentada Noticias Noticias extremadamente preocupantes Noticias desde Counterpane En la ratonera: E*Trade Factorizar un n·mero de 512 bit Comentarios de los lectores _______________________________________________________________ 1. C╙DIGO ABIERTO Y SEGURIDAD _____________________________ Por Bruce Schneier Traducci≤n: Angel Galindo Sßnchez Como cript≤grafo y experto en seguridad informßtica, nunca he comprendido el alboroto actual sobre el movimiento de software de c≤digo abierto. En el mundo de la criptografφa se considera que el c≤digo abierto es necesario para tener un buen nivel de seguridad; y se ha considerado asφ durante dΘcadas. La seguridad p·blica es siempre mßs segura que la seguridad privada. Esto es cierto para los algoritmos criptogrßficos, para los protocolos de seguridad y para el c≤digo fuente de seguridad. Para nosotros, el c≤digo abierto no es s≤lo un modelo de negocio, sino una prßctica de ingenierφa adecuada. * Criptografφa de c≤digo abierto La criptografφa ha adoptado los ideales del c≤digo abierto durante dΘcadas, aunque lo llamemos "utilizar algoritmos y protocolos p·blicos". La idea es simple: la criptografφa es difφcil de hacer correctamente, y la ·nica forma de saber si algo estß bien hecho es ser capaz de comprobarlo. Esto es vital en criptografφa, porque la criptografφa no tiene nada que ver con la funcionalidad. Puedes tener dos algoritmos, uno seguro y el otro inseguro, y ambos pueden funcionar perfectamente. Ambos pueden cifrar y descifrar, son eficientes, tienen un bonito interfaz de usuario y nunca se cuelgan. La ·nica forma de distinguir la buena de la mala criptografφa es examinßndola. A·n peor, no se consigue nada teniendo un mont≤n de gente cualquiera examinando el c≤digo; la ·nica forma de distinguir la buena criptografφa de la mala es examinßndola por expertos. Analizar criptografφa es duro, y hay pocas personas en el mundo que puedan hacerlo de forma competente. Antes de que un algoritmo pueda considerarse realmente seguro, necesita ser examinado por muchos expertos a lo largo de muchos a±os. Este es un fuerte argumento en favor de los algoritmos de c≤digo abierto. Dado que la ·nica forma de tener confianza en un algoritmo es tener expertos que lo examinen, y la ·nica forma en que ellos emplearßn el tiempo necesario para examinarlo adecuadamente es permitirles que publiquen documentos tΘcnicos de investigaci≤n sobre Θl, el algoritmo debe ser p·blico. Un algoritmo privado, no importa quiΘn lo haya dise±ado o a quiΘn se haya pagado para examinarlo, es mucho mßs arriesgado que un algoritmo p·blico. El contra-argumento que a veces se oye es que la criptografφa secreta es mßs fuerte porque es secreta, y que los algoritmos p·blicos son mßs arriesgados porque son p·blicos. Esto suena bastante l≤gico, hasta que te paras a pensar un momento sobre ello. Los algoritmos p·blicos estßn dise±ados para ser seguros incluso aunque sean p·blicos; asφ es como estßn hechos. Por tanto, no hay ning·n riesgo en hacerlos p·blicos. Si un algoritmo s≤lo es seguro si permanece secreto, solamente lo serß hasta que alguien utilice ingenierφa inversa contra Θl y lo publique. Una gran variedad de algoritmos secretos para telefonφa m≤vil digital han sido hechos p·blicos y rotos rßpidamente, ilustrando la futilidad de este argumento. En lugar de utilizar algoritmos p·blicos, las compa±φas norteamericanas de telefonφa m≤vil decidieron crear su propia criptografφa privada. Durante los ·ltimos a±os, diferentes algoritmos de estos se han hecho p·blicos. (No, las compa±φas telef≤nicas no querφan que se hicieran p·blicos; lo que generalmente ocurre es que alg·n cript≤grafo recibe sus especificaciones en un paquete an≤nimo). Una vez que se ha hecho p·blico, ya estß roto. Ahora la industria de telefonφa m≤vil americana estß considerando el utilizar algoritmos p·blicos para reemplazar a sus rotos algoritmos privados. Por otro lado, el popular programa de encriptaci≤n de correo electr≤nico PGP siempre ha utilizado algoritmos p·blicos. Y ninguno de esos algoritmos ha sido roto jamßs. Esto mismo puede decirse de otros protocolos de Internet: SSL, S/MIME, IPSec, SSH, etcΘtera. * La mejor evaluaci≤n no se compra con dinero Actualmente el gobierno norteamericano estß eligiendo un algoritmo de encriptaci≤n para sustituir a DES, llamado AES (Advanced Encryption Standard, Norma de Cifrado Avanzada). Hay cinco candidatos a la norma, y, antes de elegir el definitivo, los mejores cript≤grafos del mundo pasarßn horas evalußndolos. Ninguna empresa, no importa lo rica que sea, puede permitirse este tipo de evaluaci≤n. Y dado que AES es gratuito para cualquier utilizaci≤n, no hay ninguna raz≤n para que otra empresa ni siquiera se plantee crear su propio algoritmo. La criptografφa abierta no es s≤lo la mejor, sino que ademßs es la mßs barata. El mismo razonamiento que lleva a las empresas inteligentes a utilizar criptografφa p·blica tambiΘn les lleva a utilizar protocolos de seguridad p·blicos: cualquiera que cree su propio protocolo de seguridad, es un genio o un loco. Dado que hay mßs de los ·ltimos que de los primeros, utilizar protocolos p·blicos es mßs inteligente. Consideremos IPSec, el protocolo de seguridad de Internet. A principios de 1992, fue dise±ado abiertamente por un comitΘ y fue objeto de numerosos escrutinios p·blicos desde sus inicios. Todo el mundo sabφa que era un protocolo importante y la gente puso mucho esfuerzo tratando de hacer las cosas bien. Diferentes tecnologφas de seguridad fueron propuestas, rotas y despuΘs modificadas. Se codificaron y analizaron varias versiones. El primer boceto de la norma se public≤ en 1995. Se debatieron diferentes aspectos de IPSec, como sus mΘritos en seguridad, comportamiento, facilidad de implementaci≤n, capacidad de ampliaci≤n y uso. En noviembre de 1998, el comitΘ public≤ una serie de documentos - el primer paso de todo un proceso para hacer de IPSec un estßndar en Internet. Y todavφa sigue estudißndose. Los cript≤grafos del Laboratorio de Investigaci≤n Naval recientemente descubrieron un peque±o error de implementaci≤n. El trabajo contin·a, en p·blico, para y por cualquiera que estΘ interesado. El resultado, basado en a±os de anßlisis p·blico, es un protocolo fuerte en el que confφa la mayorφa de la gente. Por otro lado, Microsoft desarroll≤ su propio protocolo PPTP para hacer lo mismo. Inventaron su propio protocolo de autenticaci≤n, su propia funci≤n hash, y su propio algoritmo de generaci≤n de llaves. Todas y cada una de estas implementaciones resultaron ser defectuosas. Utilizaron su propio algoritmo de cifrado, pero lo utilizaron de una manera que impedφa su propia seguridad. Tuvieron errores de implementaci≤n que debilitaron todo el sistema a·n mßs. Pero como hicieron todo este trabajo internamente, nadie sabφa que PPTP era dΘbil. Microsoft instal≤ PPTP en Windows NT y Windows 95, y lo utilizaron en los productos de su red privada virtual (VPN). A veces publicaron sus protocolos y, en el verano de 1998, la compa±φa para la que trabajo, Counterpane Systems, public≤ un documento tΘcnico describiendo los errores que encontramos. Una vez mßs, el escrutinio p·blico mostr≤ su valor. Microsoft rßpidamente sac≤ una serie de parches que evaluamos ese verano y vimos que eran buenas mejoras, pero a·n encontramos fallos. Como en los algoritmos, la ·nica forma de distinguir un protocolo de seguridad bueno de uno que estß roto, es tener expertos que lo examinen. Por tanto, si necesita utilizar un protocolo de seguridad, serß mucho mßs inteligente utilizar uno que ya haya sido evaluado. Puede crearse el suyo propio, pero, ┐cußles son la probabilidades de que sea tan seguro como otro que ya ha sido probado por expertos en los ·ltimos a±os?. * Asegurando su c≤digo Exactamente el mismo razonamiento lleva a cualquier ingeniero de seguridad inteligente a demandar c≤digo abierto para cualquier aspecto relacionado con la seguridad. Repasemos: la seguridad no tiene nada que ver con la funcionalidad. Por tanto, ning·n nivel de pruebas de versiones beta podrß nunca descubrir un fallo de seguridad. La ·nica forma de encontrar fallos de seguridad en un segmento de c≤digo -como un algoritmo criptogrßfico o un protocolo de seguridad- es evaluarlo. Esto es cierto para cualquier c≤digo, tanto si es abierto como privado. Y no puedes hacer que cualquiera te eval·e el c≤digo, sino que necesitas que lo hagan expertos en software de seguridad. Necesitas que lo eval·en varias veces y desde diferentes perspectivas, durante el transcurso de varios a±os. Se puede conseguir contratar a esta clase de expertos, pero es mucho mßs barato y efectivo dejar que toda una comunidad lo haga. Y la mejor forma de conseguirlo es hacer p·blico el c≤digo. Pero si quieres que tu c≤digo sea realmente seguro, necesitarß hacer algo mßs que simplemente publicarlo bajo una licencia de c≤digo p·blico. Hay dos cuestiones que deberß tener siempre presentes. Primero, la simple publicaci≤n del c≤digo no significa que la gente lo examinarß para buscar sus fallos. Los investigadores de seguridad son personas inconstantes y ocupadas. No tienen tiempo de examinar todas las muestras de c≤digo que se publican. Por tanto, aunque hacer p·blico el c≤digo es bueno, no es una garantφa de seguridad. Podrφa nombrar una docena de librerφas de seguridad de c≤digo abierto de las que nunca nadie ha oφdo hablar jamßs o que nunca han sido evaluadas. Por contra, el c≤digo de seguridad de Linux ha sido comprobado por un mont≤n de excelentes ingenieros de seguridad. Segundo, necesita asegurarse de que los fallos de seguridad sean corregidos tan pronto como se hagan p·blicos. La gente encontrarß errores en el c≤digo. Esto es bueno. No hay raz≤n para pensar que el c≤digo abierto, en el momento de escribirlo, es mßs seguro que el c≤digo privado. El objetivo de hacer que sea abierto es conseguir que mucha, mucha gente analice el c≤digo buscando sus fallos, y los encuentre. Rßpido. Hay que corregir los errores encontrados. Un c≤digo p·blico con dos a±os de antigⁿedad tendrß muchos menos fallos de seguridad que un c≤digo privado, simplemente porque ya se habrßn encontrado y corregido muchos. Los fallos de seguridad tambiΘn se descubrirßn en c≤digos privados, pero a un ritmo mucho menor. Comparar la seguridad de Linux con la de Microsoft Windows no es muy instructivo. Microsoft ha hecho un trabajo tan malo con la seguridad que no es en realidad una comparaci≤n justa. Pero comparar Linux con Solaris, por ejemplo, es mßs instructivo. La gente estß encontrando problemas de seguridad mßs rßpidamente en Linux, y se estßn corrigiendo a un ritmo mucho mayor. El resultado es un sistema operativo que, incluso aunque s≤lo tiene unos pocos a±os de antigⁿedad, es mucho mßs robusto de lo que Solaris era a su edad. * Programas seguros Uno de los grandes beneficios del movimiento de c≤digo abierto es el efecto de realimentaci≤n positiva que tiene la publicidad. Entre en un gran almacΘn de ordenadores es estos dφas, y verß estanterφas enteras de productos basados en Linux. La gente los compra, porque el uso de Linux ya no estß limitado a los expertos; es una herramienta ·til en muchas aplicaciones. El mismo bucle de realimentaci≤n funciona en seguridad: los algoritmos y protocolos p·blicos ganan credibilidad porque se conocen y se utilizan, y por tanto se convierten en la moda. No es un modelo perfecto, pero es mejor que la alternativa. 2. ┐CLAVE DE LA NSA EN MICROSOFT CRYPTO API? ____________________________________________ Por Bruce Schneier Traducci≤n: Isidre Marques Serret Hace unos meses, hablΘ del sistema de Microsoft para firmar digitalmente las librerφas criptogrßficas que se incluyen en su sistema operativo. El detalle importante es que solo podrßn utilizarse las librerφas criptogrßficas firmadas, lo cual hace que cosas como el control de la exportaci≤n sean mßs fßciles. Molesto como es, es el mercado actual. Microsoft tiene dos de claves, una primaria y una de reserva. El artφculo de CriptoGrama hablaba de ataques basados en el hecho de que una librerφa criptogrßfica se considera firmada si estß firmada por CUALQUIERA de las claves, y que no hay ning·n mecanismo concreto para pasar desde la clave primaria a la de reserva. Es criptografφa est·pida, pero es el tipo de cosas que podrφamos esperar de Microsoft. De repente hay un estallido de actividad de la prensa porque alguien se da cuenta que la segunda clave en la API criptogrßfica de Microsoft en el Service Pack 5 de Windows NT tiene el nombre de "NSAKEY" en el c≤digo. íAjß! La NSA puede firmar librerφas criptogrßficas. Puede usar esta capacidad para instalar una librerφa criptogrßfica Troyana en nuestro ordenador. Asφ la teorφa de la conspiraci≤n esta en marcha. No me lo trago. Primero, si la NSA quisiera comprometer la API criptogrßfica de Microsoft, le resultarφa mucho mßs fßcil 1) convencer a MS para que les proporcionara la clave secreta correspondiente a la clave de firmado, 2) conseguir que MS firmara un m≤dulo ama±ado para la NSA, o 3) instalar un m≤dulo diferente a la API criptogrßfica para romper el cifrado (ninguna otra de las librerφas necesita firma). Siempre es mßs fßcil romper un buen cifrado atacando el generador de n·meros aleatorios que realizando un ataque del tipo fuerza-bruta a la clave. Segundo, la NSA no necesita una clave para comprometer la seguridad en Windows. Los programas como el Back Orifice puede hacerlo sin ninguna clave. Para atacar la API criptogrßfica todavφa se necesita que la vφctima ejecute un programa (o una macro de Word) en su ordenador. Si puede convencerse a la vφctima para que ejecute un programa que no sea de confianza, hay un bill≤n de maneras mßs inteligentes para comprometer seguridad. Tercero, ┐por quΘ llamarφa alguien a una clave secreta de la NSA "NSAKEY"? Una gran cantidad de gente tiene acceso al c≤digo original dentro de Microsoft; una conspiraci≤n como esta solo deberφa ser conocida por muy poca gente. Alguien con un debugger podrφa encontrar esta "NSAKEY." Si esto pretende ser un mecanismo secreto, no es muy secreto. Veo dos posibilidades. Uno, que la clave es lo que Microsoft dice, una clave de reserva. Se llama "NSAKEY" por alguna est·pida raz≤n, y eso es todo. Dos, que sea realmente un clave de la NSA. Si la NSA pretende utilizar productos Microsoft para sus comunicaciones secretas, van a instalar sus propias librerφas criptogrßficas. No van a querer mostrßrselas a nadie, ni siquiera a Microsoft. Querrßn firmar sus propias librerφas. Asφ que la clave de reserva podrφa ser una clave interna de la NSA, para poder instalar sistemas fuertes de criptografφa sobre los productos de Microsoft para su propio uso interno. Pero no es una clave de la NSA para que puedan debilitar en secreto la criptografφa de las masas desprevenidas. Simplemente hay demasiadas cosas mßs inteligentes que pueden hacer a las desprevenidas masas. Mi artφculo original: http://www.kriptopolis.com/criptograma/cg0012.html#5 Anuncio: http://www.cryptonym.com/hottopics/msft-nsa.html Un buen anßlisis: http://ntbugtraq.ntadvice.com/default.asp?sid=1&pid=47&aid=52 Un artφculo interesante en las news: http://www.wired.com/news/news/technology/story/21577.html 3. COUNTERPANE SYSTEMS: INVESTIGACI╙N DOCUMENTADA _________________________________________________ Por Bruce Schneier Traducci≤n: Miguel Camacho "Criptoanalisis sobre las extensiones Microsoft de autentificaci≤n PPTP (MS-CHAPv2)" Por Bruce Schneier y Mudge, CQRE, Duesseldorf, (en preparaci≤n) Oct 1999. El protocolo de direccionamiento punto a punto [Point-to-Point Tunneling Protocol (PPTP)] es usado para conexiones PPP seguras sobre enlaces basados en TCP/IP. En respuesta a [SM98], Microsoft public≤ extensiones al mecanismo de autenticaci≤n de PPTP (MS-CHAP), llamadas MS-CHAPv2. Ofrecemos una visi≤n general de los cambios en la autenticaci≤n y generaci≤n de claves de MS-CHAPv2, y evaluamos las mejoras y las debilidades que permanecen en la implementaci≤n Microsoft del PPTP. Mientras se arreglan algunos de los mßs notorios errores de MS-CHAPv1, el nuevo protocolo todavφa adolece de algunas de las mismas debilidades. http://www.counterpane.com/pptpv2-paper.html 4. NOTICIAS __________________________ Por Bruce Schneier Traducci≤n: Miguel Camacho * El proyecto de auditoria de Internet. Es realmente interesante. Un grupo realiz≤ una auditoria de seguridad de bajo nivel sobre 36 millones de hosts en internet. ┐De manera imparcial, c≤mo de segura es en realidad Internet? http://www.securityfocus.com/templates/forum_message.html?forum=2&head=32&id =32 http://www.internetnews.com/intl-news/print/0,1089,6_184381,00.html Y si eso no es suficiente espeluznante, aqui hay una mßs detallada auditorφa sobre 2200 sitios de Internet: http://www.fish.com/survey/ * Mi siempre favorita declaraci≤n de conformidad con el 2000 (Y2K): http://www.hartscientific.com/y2k.htm * Si necesita mßs pruebas de que la seguridad de formato propietario no funciona, el formato de seguridad Microsoft de musica digital ha sido reventado durante los dias de su presentaci≤n. http://www.wired.com/news/news/technology/story/21325.html http://www.news.com/News/Item/0,4,0-40672,00.html?st.ne.lh..ni http://www.msnbc.com/news/302195.asp * Chantaje de patentes: Abogados de alguien llamado Leon Stambler han estado enviando cartas amenazantes a compa±ias de seguridad, reclamando que SSL, PCK, FIPS 196, SET, Microsoft PPTP, Authenticode, etc. infringen su patente. CompruΘbelo por sφ mismo; los n·meros de patente son 5,793,302 y 5,646,998. http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1& u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1= '5,793,302'.WKU.&OS=PN/5,793,302&RS= PN/5,793,302 http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1& u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1= '5,646,998'.WKU.&OS=PN/5,646,998&RS= PN/5,646,998 * Tras todo lo hablado sobre voto electr≤nico, es agradable comprobar que algunos reconocen que existen algunos serios problemas de seguridad. El mßs grave, al menos para mφ, es el votante coaccionado. Cuando usted entra en una cabina privada de votaci≤n puede votar a quien usted desee. Nadie puede hacer nada contra esto. Si puede votar desde su ordenador, en su propia casa, con alg·n tipo de medida de seguridad electr≤nica, entonces es posible para alguien comprar su voto y asegurarse su entrega en su beneficio. http://www.nytimes.com/library/tech/99/08/cyber/articles/14vote.html * Algunos me preguntan sobre mi comentario en el ultimo n·mero referente a la necesidad para Windows NT de realizar alrededor de 300 cambios de seguridad para convertirlo en seguro. Yo interroguΘ al grupo de noticias de Usenet comp.os.ms-windows.nt.admin.security preguntßndoles si era exagerado o cierto y conseguφ varias respuestas. El consenso parece apuntar que el n·mero estaba entre 50 y 3000 y que 300 no fue una estimaci≤n disparatada. Una buena lista de comprobaci≤n esta disponible aqui: http://people.hp.se/stnor/ Mire tambiΘn: http://www.trustedsystems.com/NSAGuide.htm * Las regulaciones de Estados Unidos sobre exportaci≤n criptogrßfica han conducido al desarrollo de excelentes productos por compa±ias no americanas. Juzguen con este artφculo, aunque no sea el ·nico sobre ello. http://www.rediff.com/computer/1999/jul/09suri.htm * Dos documentos sobre seguridad de Microsoft. No son gran cosa, pero nos esclarecen la lφnea que sigue Microsoft. Fundamentos en seguridad: http://www.microsoft.com/security/resources/security101wp.asp Seguridad de macros en Office 2000: http://officeupdate.microsoft.com/2000/downloadDetails/o2ksec.htm * Un fallo en Hotmail permite a cualquiera leer el correo de cualquier usuario, sin ninguna clave de acceso. Para mφ, lo realmente interesante de esta historia no es que el fallo fuera descubierto, sino que quizßs haya sido conocido por la comunidad underground mucho antes de que fuera p·blico. Algunas historias nuevas que aluden a ello: http://www.wired.com/news/news/technology/story/21503.html http://www.msnbc.com:80/news/306093.asp http://www.zdnet.com.au:80/zdnn/stories/zdnn_display/0,3440,2324361,00.html http://news.excite.com/news/zd/990901/10/the-bug-syndrome http://news.excite.com/news/zd/990901/06/how-hotmail-blew http://www.salon.com/tech/log/1999/09/02/hotmail_hack/print.html * Escultura cifrada en el cuartel general de la CIA en Langley, Virginia. http://www.npr.org/programs/atc/990826.kryptos.html * ┌nete a los militares y visita los s≤tanos de Ft. Meade. La Agencia de Seguridad Nacional ofrece alojamiento, manutenci≤n e intrucci≤n acadΘmica gratis a los hackers que deseen trabajar para ellos durante cinco a±os tras su graduaci≤n. http://www.currents.net/newstoday/99/08/27/news3.html http://www.cnn.com/TECH/computing/9908/26/t_t/teen.hacker/index.html * Ameno artφculo de la BBC sobre el debate del cifrado en EEUU: http://news.bbc.co.uk/hi/english/world/americas/newsid_430000/430384.stm * Divertido tema: la historia real de Alice y Bob: http://www.conceptlabs.co.uk/alicebob.html * Este fue realmente un muy buen artφculo -- claro, completo, comprensible -- publicado recientemente en _The Sciences_ sobre cßlculo cußntico. Cryptome ha colocado el artφculo en lφnea, con el permiso del autor. http://cryptome.org/qc-grover.htm 5. NOTICIAS EXTREMEDAMENTE PREOCUPANTE ______________________________________ Por Bruce Schneier Traducci≤n: Sergio Pozo Hidalgo El Departamento de Justicia estß planeando solicitar al Congreso una licencia para permitir a los agentes federales provistos de ≤rdenes de registro, entrar de forma secreta en casas y oficinas para obtener llaves de descifrado o claves, para implantar "dispositivos de recuperaci≤n", o si no, para modificar ordenadores para asegurar que cualquier mensaje o fichero cifrado pueda ser leφdo por el gobierno. Con esta dramßtica propuesta, la Administraci≤n Clinton estß diciendo bßsicamente: "si no se apresura a darle su llave a un tercero, entraremos de forma encubierta en su casa para conseguirla si tenemos sospechas de una conducta criminal". El texto completo de la propuesta del Departamento de Justicia, un anßlisis secci≤n a secci≤n preparado por los abogados del DOJ (Department Of Justice - Departamento de Justicia) y material relacionado estß disponible en: http://www.epic.org/crypto/legislation/cesa_release.html http://www.cdt.org/crypto/CESA http://www.washingtonpost.com/wp-srv/business/daily/aug99/encryption20.htm http://www.zdnet.com/zdnn/stories/news/0,4586,2317907,00.html http://www.techweb.com/wire/story/TWB19990820S0012 6. NOTICIAS DE COUNTERPANE __________________________ Por Bruce Schneier Traducci≤n: Sergio Pozo Hidalgo Bruce Schneier hablarß en SANS Network Security 99, del 3 al 10 de Octubre en Nueva Orleans. Mire en http://www.sans.org/ns99/ns99.htm para mßs detalles sobre la conferencia. ┴rboles de ataque: MiΘrcoles, 6 de Octubre, 10:30 - 12:30 Criptografφa en Internet: Martes, 5 de Octubre, 9:00 - 5:00 Bruce Schneier escribi≤ la columna "Riesgos internos" de las ediciones de Agosto, SepTiembre y Octubre de "Comunicaciones de la ACM". Biometrφa: usos y abusos: http://www.counterpane.com/insiderisks1.html La carrera del caballo de Troya: http://www.counterpane.com/insiderisks2.html Riesgos de confiar en la Criptografφa: http://www.counterpane.com/insiderisks3.html 7. EN LA RATONERA: E-TRADE __________________________ Por Bruce Schneier Traducci≤n: Angel Galindo Sßnchez La seguridad de clave de E*Trade no es tal. Limitan la clave de entrada a un mßximo de 6 caracteres, y las ·nicas elecciones son letras (se distingue entre may·sculas y min·sculas), n·meros, $, y _. ┐Con quΘ cartera quiere negociar hoy? 8. FACTORIZAR UN N┌MERO DE 512 BIT __________________________________ Por Bruce Schneier Traducci≤n: Sergio Pozo Hidalgo Un record de factorizaci≤n fue roto el 22 de Agosto pasado. Un grupo liderado por Herman te Riele de CWI en Amsterdam factoriz≤ un difφcil n·mero de 512-bit (155 dφgitos). Con "difφcil" quiero decir que era el producto de dos primos de 78 dφgitos... el tipo de n·meros usado por el algoritmo RSA. Alrededor de 300 estaciones de trabajo SGI y PCs Pentium hicieron el trabajo, mayoritariamente en noches y fines de semana, en el transcurso de siete meses. El algoritmo usado fue el de siembra en campo numΘrico. Tiene dos partes: la etapa del tamiz y la etapa de reducci≤n de la matriz. La primera fue en la que trabajaron los 300 ordenadores: sobre 8000 MIPS-a±os en 3,7 meses (esta es la parte que el dispositivo TWINKLE de Shamir puede acelerar). La etapa de reducci≤n de la matriz requiri≤ 224 horas de CPU (y al rededor de 3,2Gb de memoria) en el Cray C916 en el Centro AcadΘmico de Cmputaci≤n de Amsterdam SARA. El esfuerzo completo fue 50 veces mßs fßcil que romper DES. Factorizar llaves de comercio electr≤nico es, definitivamente, muy prßctico, y llegarß a serlo mucho mßs en unos pocos a±os. Ciertamente es razonable esperar que n·meros de 768-bit sean factorizados en unos pocos a±os, luego los comentarios de los laboratorios RSA sobre que las llaves RSA sean de un mφnimo de 768 bits son muy optimistas. Certicom us≤ el evento para ganar votos sobre los beneficios de la criptografφa de llave p·blica de curva elφptica. Los algoritmos de curva elφptica, al contrario que los algoritmos como RSA, ElGamal y DSA, no son vulnerables a las tΘcnicas matemßticas que pueden factorizar estos grandes n·meros. Por consiguiente, razonan, los algoritmos de curva elφptica son mßs seguros que los RSA y demßs. Hay algo de cierto aquφ, pero s≤lo si acepta la premisa de que los algoritmos de curva elφptica tienen matemßticas fundamentalmente diferentes. Escribφ sobre Θsto anteriormente; en resumen, debe usar criptografφa de curva elφptica si las consideraciones de memoria lo demandan, pero RSA con llaves largas es probablemente mßs seguro. Este evento es significativo por dos razones. Una, la mayorφa de los protocolos de Internet utiliza RSA de 512-bit. Esto significa que los no cript≤grafos tomarßn nota de ello y probablemetne les entrarß un poco de pßnico. Y dos, al contrario que otros esfuerzos de factorizaci≤n, este fue realizado por una organizaci≤n en secreto. La mayorφa de los cript≤grafos no supieron que este esfuerzo se estaba llevando a cabo. Esto demuestra que otras organizaciones podrφan estar rompiendo llaves de comercio electr≤nico regularmente y no contßndoselo a nadie. Como de costumbre, la prensa estß tomando este argumento de forma err≤nea. Dicen cosas como: "las llaves de 512-bit ya no son seguras". Esto estß completamente fuera de lugar. Como muchos de estos argumentos de criptoanßlisis, las noticias reales son que no hay noticias. La complejidad del esfuerzo de factorizaci≤n no fue una sorpresa; no hubo avances matemßticos en el trabajo. Factorizar un n·mero de 512-bit requiri≤ mßs o menos el mismo poder de computaci≤n que la gente predijo. Si las llaves de 512-bit son inseguras hoy, eran igual de inseguras el mes pasado. Cualquiera que implemente RSA deberφa haber cambiado a claves de 1024-bit hace algunos a±os, y deberφa estar pensando en llaves de 2048-bit hoy. Es agotador comprobar como no se escucha a los cript≤grafos cuando dicen que algo es inseguro, esperando en cambio que alguien demuestre palpablemente la inseguridad. http://www.cwi.nl/~kik/persb-UK.html http://www.msnbc.com/news/305553.asp Anßlisis de RSA http://www.rsa.com/rsalabs/html/rsa155.html Refutaci≤n de Certicom http://www.certicom.com/press/RSA-155.htm Webs notables que usan todavφa RSA de 512-bit: Travelocity Tienda en lφnea Microsoft Tienda en lφnea Compaq Tienda en lφnea Godiva Dr. Koop.com Flowers N More Hay muchos mßs. Puede comprobarlo usted mismo conectando con una web con una versi≤n domΘstica (EEUU) segura de Internet Explorer 4.0. 9. COMENTARIOS DE LOS LECTORES ______________________________ Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna (artφculos 1 y 2) y David G≤mez (artφculos 3, 4, 5 y 6) De: Gene Spafford spaf@cs.purdue.edu Asunto: Re: Comentarios sobre la clave "NSA" en Windows NT ---------------------------------------------------------- Bien, siempre es mßs fßcil creer en una teorφa de la conspiraci≤n o en dise±os oscuros. Sin embargo, puede haber explicaciones alternativas. Por ejemplo, da la casualidad de que sΘ que varias agencias de 3 letras usan un mont≤n de mßquinas Windows (en cualquier caso, este hecho debiera producir terror por si solo). Supongamos que dichas agencias desean cargar versiones propias de sus rutinas de cifrado altamente clasificadas. ┐Pensßis que enviarφan copias de su c≤digo a Redmond para que se lo firmen de forma que pueda ser cargado? ┐o lo firmarßn ellos mismos, con su propia clave, haciΘndolo en la propia empresa, donde es "seguro? Si van a hacerlo en su propia empresa, entonces o bien Microsoft comparte su clave privada con ellos (mala idea), o el c≤digo debe permitir acomodar una segunda clave generada por la agencia. Ummm, esto suena familiar ┐no crΘeis?. Otra explicaci≤n que leφ aquφ (este tema se ha discutido en varias listas) es que para obtener la aprobaci≤n para la exportaci≤n, los chicos de Microsoft necesitaban incluir una clave de "respaldo" en caso de que la primera se viese comprometida de alguna manera. Necesitarφan cambiarla para usar la clave alternativa en todos los sistemas. ┐Pero c≤mo lo harφan a menos que la segunda clave ya estuviese instalada, de forma que pudiesen realizar el cambio usando esta segunda clave?. Por lo tanto, si fueseis Microsoft y la NSA os solicitase instalar una clave de respaldo como Θsta, ┐c≤mo la llamarißis?. Por supuesto, tambiΘn puede suceder que Microsoft quisiese usar una segunda clave por decisi≤n propia, y que el programador envuelto en el c≤digo decidiese nombrarla de una forma bastante tonta. TambiΘn hay una historia sobre c≤digo de Microsoft que se pone en circulaci≤n con elementos de c≤digo no documentados y cosas que los gestores de Microsoft ignoran que estßn presentes. Supongamos que el c≤digo (nos referimos tan solo a unas pocas lφneas de c≤digo) fue puesto ahφ por un agente de los servicios de inteligencia de alg·n otro paφs (no debiera ser tan difφcil corromper a alg·n empleado o incluso introducir uno en Microsoft con buenas capacidades para desarrollar c≤digo que pudiese conseguir acceso eventualmente al c≤digo apropiado). El/ella nombra las variables introducidas con las siglas "NSA" para prevenir revisiones del c≤digo e incluye un bloque de comentarios que dice "La NSA nos ha solicitado que esto estΘ aquφ -- no cambiar o realizar preguntas". El "siniestro prop≤sito" es cierto, pero estamos culpando a la entidad equivocada. íQuΘ diablos!, puede incluso que Θste sea un prop≤sito del propio Sr. Gates: DespuΘs de todo estß teniendo una fuerte disputa con el Departamento de Justicia de los Estados Unidos. Hay otras posibles razones para el nombre. Estas posibles explicaciones no quieren decir que la clave extra no tenga efectos laterales (como instalaciones clandestinas y sortear los obstßculos de los controles de exportaci≤n). Y, por supuesto, probablemente nunca sepamos cußl es el prop≤sito principal de esta clave ni quΘ papel juegan estos efectos laterales en la decisi≤n de usar dicha clave, a pesar de las eventuales quejas de la gente. El pensamiento principal es que puede haber posibles escenarios para el nombre de la clave que no impliquen actividad perjudicial, o que no impliquen dicha actividad a cargo de la NSA. Esa no debiera ser la conclusi≤n inmediata a la que llegue la gente. Y, a·n a riesgo de comenzar una diatriba, permitidme realizar una pregunta (ret≤rica): Incluso si la clave fue puesta ahφ con prop≤sitos de monitorizaci≤n clandestina, ┐quΘ hay de malo en ello? si se usa para controlar a terroristas, cßrteles de droga o laboratorios de armas en Iraq?; ┐no es eso lo que deseamos que suceda?. En este caso, ídeberiamos ser conscientes de que este control ha sido descubierto y, posiblemente, ya no tiene valor!. La historia de la criptografφa muestra -- repetidamente -- que tener ventajas criptogrßficas supone una diferencia enorme en tiempos de conflicto, y que poner esas ventajas en su sitio y funcionando lleva tiempo. Serφa ingenuo creer que estas amenazas no se ciernen sobre nosotros, o que no hay probabilidades de que eso suceda en el futuro. Debieramos tener claro en nuestras discusiones si el asunto a tratar es la presencia del c≤digo o quiΘn puede tener el control de dicho c≤digo. El tema principal es ┐QuΘ controles se ponen para asegurar que el c≤digo no sea usado contra objetivos inapropiados (Por ej., personas respetuosas de la ley, negocios legales y ciudadanos)?. Desafortunadamente carecemos de garantφas seguras en este campo, y ha habido abusos en el pasado (o presuntos abusos). Pero esto debieramos planteßrnoslo si el c≤digo fue puesto para los oscuros prop≤sitos de alg·n otro grupo. De: "Lucky Green" shamrock@cypherpunks.to Asunto: Mßs cavilaciones sobre la NSAKEY ----------------------------------------- Me gustarφa comentar alguna de tus opiniones p·blicas acerca de la NSAKEY. El objetivo de este email es ofrecer algunos datos acerca del modo de pensar de las agencias de inteligencia cuando intentar poner en peligro (desestabilizar) sistemas. En primer lugar, estoy de acuerdo con tu afirmaci≤n de que la NSA no necesita desproteger la CAPI para desproteger a los ordenadores que ejecutan Windows. Lo que no es lo mismo que afirmar que la NSA no busca comprometer la CAPI obligando a Microsoft a instalar la clave NSA. Para los cript≤grafos acadΘmicos, una vez que un fallo catastr≤fico ha sido hallado en un cifrado, el trabajo ya estß terminado. "Tenemos un ataque 2^16. El trabajo ha sido realizado. Vßmonos a casa". Las agencias de inteligencia no funcionan de esta manera. Mi trabajo con GSM ha revelado que las agencias de inteligencia, que como todos sabemos ·ltimamente estßn detrßs de los cifrados GSM, realizan una aproximaci≤n muy diferente. Las agencias de inteligencia intentarßn comprometer cada componente individual de un sistema de cifrado que permita ser comprometido. Las agencias de inteligencia comprometerßn, si tienen la oportunidad, un componente simplemente porque pueden hacerlo, no porque lo necesiten. Esto puede parecer una manifestaci≤n extra±a de implementar redundancia m·ltiple en un sistema. Lo que, estoy seguro de que en esto todos estamos de acuerdo, es generalmente una buena idea. En el caso del GSM, hemos descubierto las siguientes desestabilizaciones (o compromisos): o Desestabilizaci≤n de generaci≤n de clave. Las claves de 64 bits tienen los ·ltimos 10 bits puestos a cero. (He oido rumores acerca de que algunas implementaciones s≤lo ponen a cero los ·ltimos 8 bits, pero en cualquier caso es innegable que la entropφa de la clave queda comprometida). o Desestabilizaci≤n del sistema de autenticaci≤n y algoritmo de generaci≤n de claves. El GSM MoU fue avisado formalmente en 1989 (o 1990 como muy tarde) sobre los fallos que habiamos descubierto el a±o anterior en COMP128. Mucho antes de que GSM fuese ampliamente interceptado. El Grupo de Expertos en Algoritmos de Seguridad del MoU (SAGE Security Algorithm Group of Experts), compuesto por personas cuyas identidades son desconocidas hasta ahora, mantuvo este descubrimiento en secreto y no informo sobre Θl ni siquiera a los propios miembros del MoU. Como resultado, las agencias de inteligencia pudieron clonar telΘfonos y calcular las claves privadas de voz usadas durante una llamada. o Desestabilizaci≤n del algoritmo robusto de privacidad de voz A5/1. Este cifrado de 64 bits tiene numerosos "fallos" de dise±o, dando como resultado una resistencia de como mucho 40 bits. Es inconcebible para mφ, y virtualmente para todos aquellos con los que he hablado de este tema, que estos fallos obvios fueran pasados por alto por sus dise±adores militares franceses. o Desestabilizaci≤n del algoritmo dΘbil de privacidad A5/2. El MoU admite que la fragilidad fue la meta del dise±o del A5/2, incluso sabiendo que el SAGE indic≤ en sus anßlisis oficiales que no eran conscientes de ning·n fallo criptogrßfico en el A5/2. Para permitir intercepci≤n y descifrado en el trßfico GSM, bastarφa con comprometer la longitud efectiva de la clave. Bastarφa con comprometer la generaci≤n de la clave. Habrφa sido suficiente con comprometer los cifrados. La NSA/GCHQ hizo las tres cosas. Dados estos hechos, no serφa inusual que la NSA instalase por sφ misma puertas traseras en el sistema operativo Windows *y* obtuviese una copia de la clave de firmas de Microsoft *y* obligase a Microsoft a instalar la propia clave de la NSA. Pensemos en ello como un buen dise±o de desestabilizaci≤n redundante. De: "Kevin F. Quinn" kevq@banana.demon.co.uk Tema: Criptograma de Abril y el reciente debate sobre la clave de repuesto NSA ----------------------------------------------------------------- En el CriptoGrama del 15 de Abril de 1999, mencionaste el enfoque de las dos claves de Microsoft en referencia a sus claves principales para Authenticode, y que ellos incluφan las dos claves "presumiblemente por si una de ellas alguna vez es comprometida". Ahora sabemos que el mismo enfoque fue empleado por los CSP (proveedores de servicios criptogrßficos). El propio comunicado de Microsoft sobre el asunto es interesante; las dos claves estan presentes "en caso de que la clave principal sea destruida" (literalmente). Creo que en tu CriptoGrama querφas decir "destruida" mas que "comprometida" -- Microsoft parece estar intentando protegerse contra la posibilidad de que la clave principal secreta se queme en un incendio o algo asi; no se estan protegiendo contra copias no autorizadas de la clave hecha con el enfoque de las dos claves. Creo que es una distinci≤n importante a tener en cuenta. La ·nica buena raz≤n que puedo ver para tener dos claves, es proporcionar seguridad contra el compromiso -- en cuyo caso necesitaras validar las firmas contra ambas claves (i.e., AND en vez de OR). De esa manera si una clave es comprometida, la validaci≤n todavia fallarß ya que la segunda firma no serß valida. Si ambas claves son almacenadas en lugares seguros separados, el atacante tendrß que romper la seguridad de ambos lugares para obtener ambas claves, esperarando t· poder darte cuenta de la primera intrusi≤n antes de que ocurra la segunda. La manera sensata de protegerse contra la posibilidad de destrucci≤n (incendio, catastrofe, etc...) es tener varias copias, cada una almacenada con seguridad y monitorizada (de la misma manera que son controlados los documentos clasificados. Microsoft reclama que el enfoque de las dos claves fue sugerido por la NSA -- Yo encuentro dificil de creer que la NSA sugiriera incluir dos claves principales, para protegerse contra la destrucci≤n de una de ellas. Mi teorφa favorita es que habφa un problema de comunicaci≤n; el consejo de la NSA seguφa mßs o menos las lineas de, "tener dos claves principales protegidas contra pΘrdidas", queriendo decir compromiso, y Microsoft lo interpret≤ como destrucci≤n. De: Greg Guerin glguerin@amug.org Asunto: ┐Nuevo giro del asunto de la NSA-key/NT? ------------------------------------------------ En tu artφculo en CriptoGrama, acabas diciendo: "Este virus no existe todavφa, pero podrφa ser escrito." [Este es un virus que sustituirφa la clave de backup en NT con una clave falsa, y podrφa enga±ar al usuario para aceptar c≤digo malicioso como firmado.] DespuΘs de escribir http://amug.org/~glguerin/opinion/win-nsa-key.html, se me ocurri≤ que el virus ya existe, o al menos todas sus partes existen. Solo necesita "transformarse al Lado Oscuro" y ser ensamblado. El "kit de construcci≤n" para este virus no es otro que el "programa de reparaci≤n" en: http://www.cryptonym.com/hottopics/msft-nsa/ReplaceNsaKey.zip Todas las partes estßn ahi. El programa "AddDelCsp.exe" (no se proporcionan las fuentes) es el agente de infecci≤n activo. "nsarplce.dll" y otras DLL's son las "toxinas". El kit incluye incluso "TestReplacement.exe" (con las fuentes) para comprobar si alg·n joven emprendedor constructor de kits ha realizado sus cambios con Θxitos o no. Estoy s≤lo suponiendo, pero alguien con habilidad en programaci≤n sobre Wintel podrφa probablemente construir un virus o Caballo de Troya con este kit en cuesti≤n de horas. Probablemente la ·nica habilidad que tendrφan que pulir es la criptografφa, pero hay alguna informaci≤n buena para comenzar en el mismo informe de Fernandes. Un poco de lectura, un poco de tiempo de generaci≤n de claves, quizas unas pocas correciones, y listo. Se prueba en un sistema NT local, y entonces se publica al mundo haciendo un mirror del informe de Fernandes. O simplemente se envφa a algunos "amigos" via Hotmail. Ciertamente parecerφa autΘntica, e incluso como el programa de "reparaci≤n" estaba sin firmar, y el informe original no dice nada acerca de autentificar la descarga antes de ejecutarla, podrφa ser un Caballo de Troya bien preparado. Si este virulento "programa de reparaci≤n" se escribe de forma silenciosa, puede extenderse MUY lejos antes de que nadie se de cuenta. Podrφa incluso camuflarse a si mismo y nombrar su clave toxica como "NSAKEY", justo como la original de Microsoft. Es decir, despuΘs de "borrarse" a si mismo, esta todavφa presente. ┐Con que frecuencia a la gente se le ocurrirφa pensar en comprobar esa clave? Si conoces a alguien con experiencia de programaci≤n en NT, puede ser interesante darles a leer el informe de Fernandes, bajarse el kit de construcci≤n del virus, ehem, quiero decir, programa de "reparaci≤n" y entonces intentar hacer esto. Supongo que no serφan necesarias habilidades previas en la escritura de virus, solo habilidades de programaci≤n en NT por encima de la media. Apuesto a que tendrφas una versi≤n virulenta en menos de una tarde. Un proyecto interesante para la perezosa fiesta del Dia del Trabajo, ┐eh? De: Sam Kissetner Asunto: Meganet ------------------ PensΘ que esto podφa distraerte. El boletφn de Febrero de CriptoGrama se rie de la pagina web de Meganet por decir: Claves simΘtricas de 1 mill≤n de bits -- La oferta del mercado tiene s≤lo 40-160 bits!! VisitΘ la pagina hoy. (La URL cambi≤; estß en http://www.meganet.com/index.htm). Quizßs lean CriptoGrama, porque intentaron arreglar el error gramatical. Pero era parte de un grßfico, asi que simplemente pegaron una peque±a caja blanca sobre el ap≤strofe y la s, dejando: Claves simΘtricas de 1 mill≤n de bits -- El mercado oferta s≤lo 40-160 bits!! Vaya, eso estß *mucho* mejor. (N. del T: Las frases originales son: -1 million bit symmetric keys -- The market offer's [sic] 40-160 bit only!! -1 million bit symmetric keys -- The market offer 40-160 bit only!!! ) De: Marcus Leech mleech@nortelnetworks.com Asunto: Descripci≤n de crypt(1) de HP ------------------------------------------ Siendo sinceros con HP, y crypt(1) -- HP simplemente ha reproducido con fidelidad la pagina MAN original de crypt(1). Crypt(1) apareci≤ por primera vez en Unix V7, volviendo la vista a 1978 -- en un tiempo en que DES estaba comenzando a ser usado en ciertas ßreas limitadas. Que un sistema operativo tuviera cualquier tipo de facilidad de cifrado de ficheros era como un milagro en aquella Θpoca. Sun obviamente ha modificado ligeramente la documentaci≤n para reflejar la realidad actual, mientras HP ha elegido el enfoque de permanecer fiel a la documentaci≤n original. _____________________________________________________________________ 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: * Angel Galindo Sßnchez * Isidre Marques Serret * Miguel Camacho * Sergio Pozo Hidalgo * Juan Cruz Ruiz de Gauna * David G≤mez _____________________________________________________________________ -- AVISO IMPORTANTE -- Kript≤polis dispone de la pertinente autorizaci≤n de Bruce Schneier para traducir, elaborar y publicar la versi≤n espa±ola de su boletφn Crypto-GRAM. La informaci≤n contenida en CriptoGRAMA s≤lo puede ser redistribuida siempre que se haga de forma completa y con expresa menci≤n de Bruce Schneier como autor de Crypto-GRAM y de Kript≤polis como responsable de CriptoGRAMA. Crypto-GRAM es un boletφn mensual gratuito dedicado a res·menes, anßlisis, comentarios e ideas sobre criptografφa y seguridad informßtica. Crypto-GRAM es elaborado por Bruce Schneier, presidente de Counterpane Systems, autor de "Applied Cryptography" y creador de los algoritmos Blowfish, Twofish y Yarrow. Schneier ha pertenecido a la direcci≤n de la International Association for Cryptologic Research, EPIC y VTW, y es asiduo escritor y conferenciante sobre criptografφa. Versi≤n Web de este ejemplar: http://www.kriptopolis.com/criptograma/cg0017.html ⌐ Bruce Schneier ⌐ Kriptopolis (versi≤n en Espa±ol). _____________________________________________________________________