2000 << Back To criptograma nº 24

-----BEGIN PGP SIGNED MESSAGE----- _______________________________________________________________ C R I P T O G R A M A _______________________________________________________________ N·mero 24 15 de Abril del 2000 ________________________________________________________________ SUMARIO: 1. Novedades sobre AES. 2. El 'hack' a la tarjeta bancaria francesa. 3. Counterpane: investigaci≤n documentada. 4. Noticias. 5. Noticias de Counterpane. 6. En la ratonera: Ley de informaci≤n sobre ciberseguridad. 7. Puerta trasera en Microsoft Active Setup. 8. La Ley sobre uniformidad en las transacciones de informaci≤n por ordenador (UCITA) 9. Comentarios de los lectores -- Ejemplar gratuito distribuido a mßs de 20.000 suscriptores -- ________________________________________________________________ * Suscripci≤n gratuita: http://www.kriptopolis.com/subs.html * N·meros anteriores: http://www.kriptopolis.com/criptograma/cg.html _______________________________________________________________ 1. Novedades sobre AES ================================================= Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez http://www.kriptopolis.com/criptograma/0024_1.html El Estßndar de Cifrado Avanzado (AES) es la especificaci≤n que sustituirß al veterano DES. En 1996 el Instituto Nacional de Estßndares y Tecnologφa(NIST) inici≤ este programa. En 1997, se realiz≤ una convocatoria para la presentaci≤n de algoritmos. Quince candidatos fueron aceptados en 1998, que se redujeron a cinco en 1999. Esta pasada semana se celebr≤ la Tercera Conferencia de Candidatos AES en Nueva York. Los asistentes presentaron 23 documentos (que se a±aden a los 7 documentos relativos a AES presentandos en Cifrado Rßpido de Software -Fast Software Encryption, FSE- a principios de semana) y 12 charlas informales (mßs documentos pueden encontrarse en el sitio web de AES), mientras el NIST se prepara para tomar una decisi≤n definitiva a finales de este mismo a±o. Varios de los algoritmos recibieron un varapalo criptogrßfico. RC6 fue quien result≤ mßs afectado: dos grupos se las ingeniaron para romper 15 de 20 ciclos mßs rßpidamente que con fuerza bruta. Rijndael resisti≤ algo mejor: 7 ciclos rotos de 10/12/14 ciclos. Se presentaron varios ataques contra MARS; el mßs interesante rompi≤ 11 de 16 ciclos del n·cleo criptogrßfico. Serpent y Twofish se comportaron mejor: el ataque mßs fuerte contra Serpent rompi≤ 9 de 32 ciclos, y no se presentaron nuevos ataques contra Twofish. (Lars Knudsen present≤ un ataque en la sesi≤n postrera de FSE, que Θl mismo desestim≤ por irrealizable dos dφas despuΘs. Nuestro equipo mostr≤ tambiΘn que un ataque sobre Twofish de ciclo reducido que presentamos anteriormente en realidad tampoco funcionaba). Es importante contemplar estos resultados en su contexto. Ninguno de estos ataques contra variantes de ciclo reducido de los algoritmos son realistas, en el sentido de que pudieran emplearse para recuperar texto en claro en un perφodo de tiempo razonable. En todos los casos se trata de ataques "acadΘmicos", puesto que s≤lo muestran debilidades en el dise±o de los esquemas de cifrado. Si estuviera empleando estos algoritmos para proteger secretos, ninguno de estos ataques podrφa quitarle el sue±o. Pero si se estß intentando seleccionar un algoritmo entre cinco como estßndar, todos estos ataques sφ que resultan muy interesantes. Como la NSA acostumbra a decir: "los ataques cada vez son mejores; nunca peores". Al elegir entre algoritmos distintos, es mßs inteligente seleccionar al que tiene menos ataques y menos serios. (Esto asume, por supuesto, igualdad en el resto de aspectos). La preocupaci≤n no estriba en que alguien descubra otro ataque poco realista sobre uno de los algoritmos de cifrado, sino que alguien convierta uno de ellos en un ataque practicable. Resulta inteligente darse el mayor margen de seguridad posible). Muchos documentos discutφan el comportamiento de cada algoritmo. Si algo he aprendido es que se puede definir el "comportamiento" de muchas formas diferentes para demostrar todo tipo de cosas. Las tendencias eran las siguientes: En software, Rijndael y Twofish son mßs rßpidos. RC6 y MARS son tambiΘn veloces sobre las pocas plataformas que disponen de multiplicaci≤n rßpida y rotaciones dependientes de los datos. Resultan lentos en tarjetas inteligentes, chips ARM y los nuevos chips de Intel (Itanium y siguientes). Son rßpidos sobre Pentium Pro, Pentium II y Pentium III. Serpent es muy lento sobre cualquiera. En hardware, Rijndael y Serpent son los mßs rßpidos. Twofish va bien. RC6 resulta pobre y MARS un desastre. Los ·nicos dos algoritmos que manifestaron tales problemas de implementaci≤n que yo los eliminarφa sin contemplaciones fueron MARS y RC6. MARS es tan malo en hardware que resultarφa un desastre para aplicaciones de Internet, y RC6 por un estilo. Y ambos algoritmos sencillamente no caben en tarjetas inteligentes peque±as. (El equipo de RC6 hizo un comentario sobre estar disponible en tarjetas baratas - -5 d≤lares-, pero yo estoy hablando de tarjetas de 25 centavos). Personalmente, incrementarφa el n·mero de ciclos de Rijndael para dotarle de un margen de seguridad similar al del resto. Entre Serpent, Twofish y Rijndael con 18 ciclos, cualquiera de ellos constituirφa un buen estßndar, pero considero que Twofish proporciona la mejor seguridad para funcionar en cualquier condici≤n y dispone de mayor flexibilidad de implementaci≤n. Por tanto, apoyo a Twofish para el AES. El plazo de recepci≤n de comentarios finaliza el 15 de Mayo. DΘse prisa, Como indican muchos de los documentos y comentarios, la decisi≤n tendrß mßs en cuenta la idoneidad que la seguridad. El NIST necesita saber quΘ es importante para usted: eficiencia sobre tarjetas inteligentes baratas de 8 bit, agilidad de claves en hardware, gran velocidad de cifrado, conteo de puertas en hardware, etc. Si le gusta la idea de m·ltiples algoritmos, dφgaselo. Si no, dφgaselo. Una vez el NIST elija un AES todos estaremos comprometidos con Θl; los clientes pedirßn que los productos sean "compatibles AES". Ahora tiene la oportunidad de influir sobre lo costosa que pueda resultar esa demanda. Sitio web del NIST sobre AES: http://www.nist.gov/aes Por cierto: soy uno de los creadores de Twofish: http://www.counterpane.com/twofish.html 2. El 'hack' a la tarjeta bancaria francesa ================================================= Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez http://www.kriptopolis.com/criptograma/0024_2.html Esta es una buena historia sobre seguridad, plagada de interesantes giros. Muchas de las moralejas son cosas que he estado predicando durante mucho tiempo. Lea sobre ello. El artφculo del Irish Times es el mejor: http://www.ireland.com:80/newspaper/finance/2000/0315/fin18.htm Un artφculo de Reuters: http://abcnews.go.com:80/sections/tech/ DailyNews/smartcard000315.html Y dos artφculos previos sobre Humpich: http://www.zdnet.com/zdnn/stories/news/0,4586,2428429,00.html http://www.zdnet.com/zdnn/stories/bursts/0,7407,2452848,00.html Mßs sobre este asunto: http://interactive.wsj.com/articles/SB953062647293931073.htm (se necesita suscripci≤n) http://www.currents.net/newstoday/00/03/11/news4.html http://www.wired.com/news/technology/0,1282,34897,00.html 3. Counterpane: investigaci≤n documentada ================================================= Por Bruce Schneier Traducci≤n: Isaac Carreras http://www.kriptopolis.com/criptograma/0024_3.html "íMARS Ataca! Criptoanßlisis preliminares de las variantes de ciclos reducidos de MARS " (J.Kesley y B.Schneier, Tercera Conferencia de Candidatos de AES, 2000, por aparecer). En este documento, discutimos algunas maneras de atacar diversas variantes de ciclos reducidos de MARS. Consideramos el criptoanßlisis de dos de estas variantes: MARS con todas las capas de mezclado pero menos ciclos centrales, y MARS con cada uno de los cuatro tipos de ciclos reducidos en igual cuantφa. Desarrollamos algunas nuevas tΘcnicas para el ataque de ambas variantes de MARS. Nuestros mejores ataques rompen MARS con mezclado total y cinco ciclos centrales (21 ciclos en total) y Mars simΘtricamente reducido a doce ciclos (3 de cada tipo). http://www.counterpane.com/mars-attacks.html 4. Noticias ================================================= Por Bruce Schneier Traducci≤n: Isaac Carreras http://www.kriptopolis.com/criptograma/0024_4.html Algunos hackers emprendedores rompieron la seguridad en Cyber Patrol. Debido a su buen trabajo, fueron demandados por el creador de la aplicaci≤n por el uso ilegal de la ingenierφa inversa seg·n la Ley de Copyright Digital Milenio (DMCA): http://www.wired.com/news/politics/0,1283,35038,00.html DespuΘs de eso, acordaron renunciar a sus derechos sobre su acci≤n y nunca mßs hablar sobre ello: http://www.computerworld.com/home/print.nsf/all/000331D072 http://www.zdnet.com/zdnn/stories/news/0,4586,2487024,00.html El juez dict≤ que cualquiera que reflejara dicha acci≤n en un sitio web tendrφa que quitar dicha informaci≤n: http://www.wired.com/news/politics/0,1283,35244,00.html http://www.wired.com/news/business/0,1367,35258,00.html http://www.politechbot.com/cyberpatrol/final-injunction.html ACLU apela: http://www.wired.com/news/business/0,1367,35464,00.html El profesor Lawrence Lessig de la escuela de derecho de Harvard discute el asunto: http://www.thestandard.com/article/display/0,1151,13533,00.html --------------------------------------------------- La U.E. estß investigando ECHELON: http://www.wired.com/news/politics/0,1283,35048,00.html ---------------------------------------------------- Si alguna vez se ha preguntado c≤mo funcionan las etiquetas especiales antirrobo que se ven en las tiendas, este artφculo es una autΘntica revelaci≤n. http://www.howstuffworks.com/anti-shoplifting-device.htm ----------------------------------------------------- Desde la secci≤n de gente que no se entera: un artφculo que afirma que Linux es inseguro porque es de c≤digo abierto. La frase mßs divertida es: "La seguridad necesita ser construida dentro de la arquitectura de un sistema operativo. Esto no puede ocurrir si el acceso al c≤digo fuente es p·blico". http://www.silicon.com/public/door?REQUNIQ=953519311&6004REQEVENT=&REQ NT1=36413&REQSTR1=newsnow ----------------------------------------------------- Un artφculo algo mßs mßs equilibrado sobre la seguridad del c≤digo abierto vs. c≤digo cerrado: http://www.zdnet.com/pcweek/stories/news/0,4153,2473335,00.html ----------------------------------------------------- ┐L0phtcrack como una herramienta para robar? Comentario de Jennifer Granick, quien estß verdaderamente cualificada para dar una opini≤n sobre el asunto: http://www.securityfocus.com/commentary/7 ----------------------------------------------------- Plug-in gratuito para bloquear las cookies en los buscadores: http://www.cnn.com/2000/TECH/computing/03/21/idcide/index.html ----------------------------------------------------- Utilizando Firewall-1 como un sistema de detecci≤n de intrusos: http://www.enteract.com/~lspitz/intrusion.html ----------------------------------------------------- El Instituto de Seguridad en Computadores (CSI) ha publicado su "Temas y Tendencias: Encuesta 2000 del CSI/FBI sobre seguridad y delito informßtico". Vale la pena leerlo; consiga su copia: http://www.gocsi.com/prelea_000321.htm ----------------------------------------------------- Alguien ha construido un ordenador cußntico de 7-qubit. Ning·n m≤dulo de RSA menor de tres bits deberφa tener problemas. http://www.wired.com/news/technology/0,1282,35121,00.html ----------------------------------------------------- Un virus de HTML que infecta WebTV: http://www.zdnet.com/enterprise/stories/security/news/0,7922,2470827,0 .html http://www.wired.com/news/technology/0,1282,35045,00.html ------------------------------------------------------ Robado un ordenador portßtil del MI5 (con secretos gubernamentales): http://www.zdnet.co.uk/news/2000/11/ns-14318.html Y pocos dφas despuΘs... un ordenador portßtil del MI6 robado (tambiΘn con secretos gubernamentales): http://news2.thls.bbc.co.uk/hi/english/uk/newsid_693000/693011.stm ┐QuΘ ocurre con con el servicio britßnico de inteligencia?. Espero que, por lo menos, cifren sus discos duros. ------------------------------------------------------- Stephen King public≤ su ·ltima novela electr≤nicamente. Las protecciones de seguridad fueron rotas en dos dφas y copias desprotegidas fueron puestas en Internet a disposici≤n de cualquiera. Esto no deberφa sorprender a nadie (el otro hecho interesante es que al parecer, a pesar de la difusi≤n de la publicaci≤n no autorizada, el experimento puede haber resultado un Θxito clamoroso. El autor podφa haber obtenido 10.000 $ vendiΘndoselo a PlayBoy; los primeros informes hablan de 450.000 $ en ventas de la edici≤n electr≤nica del libro.) http://www.ebooknet.com/story.jsp?id=1671 http://www.computerworld.com/home/print.nsf/all/000331D076 http://www.zdnet.com/zdnn/stories/news/0,4586,2487101,00.html ------------------------------------------------------- Herramientas de hacking de L0pht para los Palm Pilots: http://www.l0pht.com/~kingpin/pilot.html ------------------------------------------------------- Tinta invisible: http://ruddick.com/tim/RAP/rap.html ------------------------------------------------------- Una buena visi≤n general sobre Sarah Flannery y el ascenso y descenso del algoritmo Cayley-Purser, incluyendo sus reacciones ante la desaparici≤n del mismo y comentando quΘ esta haciendo ahora: http://www.ireland.com/newspaper/features/2000/0318/fea13.htm ------------------------------------------------------- El FBI dice que el cibercrimen se ha duplicado. A mφ me parece que lo que se han duplicado son las denuncias, ya que los administradores de redes son mßs conscientes de los peligros. Parece que el FBI estß inmerso en una carrera para conseguir mßs dinero y mßs poder: http://www.zdnet.com/zdnn/stories/news/0,4586,2486464,00.html ------------------------------------------------------- Los efectos de la complejidad en la seguridad: este es un buen ejemplo de las interacciones ocultas entre sistemas. Parece que la seguridad en Internet Explorer 5.0 puede interactuar con Windows 2000 para bloquear por completo el sistema. http://www.zdnet.com/zdnn/stories/news/0,4586,2462008,00.html?chkpt=zd ntop ------------------------------------------------------- La demanda de servicios de seguridad a tiempo completo: http://www.zdnet.com/pcweek/stories/news/0,4153,2471184,00.html ------------------------------------------------------- Un desafφo sobre clave p·blica basada en curvas elφpticas ha sido vencido. Certicom estß alardeando de que esto muestra que las curvas elφpticas son mucho mßs fuertes que RSA. Honestamente, no sΘ c≤mo se come eso. http://cristal.inria.fr/~harley/ecdl/ ------------------------------------------------------- Riesgos en las firmas digitales: http://www.zdnet.com/zdnn/stories/news/0,4586,2523596,00.htm ------------------------------------------------------- El Juzgado de Apelaci≤n del Sexto Distrito da marcha atrßs en la decisi≤n æJunger', afirmando que el c≤digo fuente ha de considerarse texto*. Ahora tenemos dos juzgados que dicen esto. (*NT: se refiere a que se encuentra protegido por la libertad de expresi≤n y su circulaci≤n-exportaci≤n no puede obstaculizarse). http://www.wired.com/news/politics/0,1283,35425,00.html http://dailynews.yahoo.com/h/ap/20000404/tc/encryption_lawsuit_1.html Opini≤n actual: http://pacer.ca6.uscourts.gov/cgi-bin/getopn.pl?OPINION=00a0117p.06 ------------------------------------------------------- Una mßquina Enigma ha sido robada: http://www.wired.com/news/politics/0,1283,35409,00.html http://www.wired.com/news/politics/0,1283,35433,00.html Algunas noticias apuntan a que fue una de las tres que hay en el mundo. Es incorrecto; fue una de las tres en Bletchley Park. -------------------------------------------------------- Canadß estß pensando endurecer los controles de exportaci≤n criptogrßfica para ponerlos mßs en la lφnea de los de los EE.UU: http://www.ottawacitizen.com/national/000405/3877481.html -------------------------------------------------------- Herramientas y metodologφas de aficionados a la programaci≤n. Buen artφculo sobre la importancia de leer e interpretar los ficheros de registro en auditorφas. http://rootprompt.org/article.php3?article=159 http://rootprompt.org/article.php3?article=167 http://rootprompt.org/article.php3?article=186 http://rootprompt.org/article.php3?article=210 -------------------------------------------------------- Un buen comentario de David Banisar sobre los planes del FBI para vigilarnos a todos: http://www.securityfocus.com/templates/article.html?id=13 -------------------------------------------------------- Una vi±eta c≤mica: http://metalab.unc.edu/Dave/Dr-Fun/df200004/df20000411.jpg -------------------------------------------------------- Intel estß abriendo el c≤digo de su programa CDSA (Arquitectura Com·n de Seguridad de Datos): http://www.zdnet.com/enterprise/stories/main/0,10228,2523586,00.html 5. Noticias de Counterpane ================================================= Por Bruce Schneier Traducci≤n: Francisco Leal Vßzquez http://www.kriptopolis.com/criptograma/0024_5.html Bruce Schneier hablarß en el TISC (Conferencia sobre seguridad en intenet) en San Jose, California (EE.UU.) el 27 de Abril del 2000: http://tisc.corecom.com/ Bruce Schneier "hablarß" en la conferencia on-line ForBusiness 2000: http://www.forbusiness2000.com/ Bruce Schneier hablarß en Network World + Interop en Las Vegas el 9 de Mayo del 2000: http://www.zdevents.com/interop/ Counterpane estß contratando; mire nuestra lista de empleos en: http://www.counterpane.com/jobs.html 6. En la ratonera: Ley de informaci≤n sobre ciberseguridad ========================================================== Por Bruce Schneier Traducci≤n: Francisco Leal Vßzquez http://www.kriptopolis.com/criptograma/0024_6.html Este proyecto -HR4246- protege la informaci≤n sobre fallos de seguridad en las redes (transferida desde la industria al gobierno), de las exigencias que impone la Ley de libertad de informaci≤n. Esta forma de pensar choca con el movimiento de revelaci≤n total que ha llevado al arreglo de miles de bugs de seguridad a lo largo de los ·ltimos a±os, y nos devuelve a un mundo de fabricantes que mantienen en secreto las vulnerabilidades y no se preocupan de arreglarlas. TambiΘn facilita la existencia de una base de datos gubernamental sobre vulnerabilidades de seguridad, que pudiera utilizarse para invadir la privacidad de los ciudadanos. TambiΘn hace mucho mßs difφcil el dise±o de estßndares de seguridad abiertos; las agencias del gobierno tenderßn mucho mßs a decir cosas como: "Se deberφa dise±ar asφ, pero no podemos decirle por quΘ". Hist≤ricamente, se ha demostrado que la revelaci≤n p·blica es la mejor manera de incrementar la seguridad. Las leyes que inviertan esa tendencia son una mala idea. Ensayo sobre el tema: http://www.securityfocus.com/news/17 El proyecto en sφ: http://www.cdt.org/legislation/106th/access/daviva_058.pdf 7. Puerta trasera en Microsoft Active Setup ==================================================== Por Gregory Guerin Traducci≤n: JosΘ Manuel G≤mez http://www.kriptopolis.com/criptograma/0024_7.html Al instalar el navegador Internet Explorer de Microsoft para Windows (versi≤n 4.0 o superior), se obtiene automßticamente algo denominado "Active Setup", un control ActiveX firmado por Microsoft. Este control se ha dise±ado para instalar y actualizar software automßticamente, incluyendo al propio Internet Explorer. Esto se realiza a base de leer las instrucciones de instalaci≤n y los componentes instalables desde un fichero CAB firmado. Una opci≤n definible por el usuario decide si aparece un cuadro de dißlogo de confirmaci≤n en cada instalaci≤n Active Setup iniciada de forma remota. En otras palabras: si usted asφ lo decide, siempre se le avisa antes de que Active Setup haga algo. Esto es algo preocupante, pero parece claro. Sin embargo, Juan Carlos Garcφa Cuartango descubri≤ algo extra±o. Si el CAB estß firmado por la propia Microsoft (en lugar de por un tercero certificado por Microsoft), entonces la especificaci≤n relativa a la confirmaci≤n por el usuario resulta ignorada. Ese tipo de CABs no muestran dißlogo de confirmaci≤n, por lo que el software es SIEMPRE instalado. Es decir, las instalaciones mediante Active Setup firmados por Microsoft no pueden ser rechazadas ni aceptadas, y pueden ocurrir silenciosamente y en secreto. Esto resulta muy preocupante, pero es incluso peor. Cualquier firmante puede indicar a Active Setup que instale componentes de CABs firmados por Microsoft, lo que ocurrirß alegremente, con independencia de quien procedan esas instrucciones. Cualquiera puede instruir a Active Setup para mezclar componentes (datos, ejecutables, incluso DLLs) de cualquier CAB previamente firmado por Microsoft. S≤lo parece importar que los componentes y las instrucciones de instalaci≤n estΘn firmadas, y no que pueden proceder de orφgenes diferentes o que estΘn firmadas por diferentes sujetos. Es como si usted redactara un nuevo mensaje a base de poner juntas palabras y frases de una serie de mensajes firmados y el resultado pareciera estar firmado porque todos sus componentes originales lo fueron. Dada la investigaci≤n existente sobre c≤mo applets Java seguras si se consideran por separado, pueden interactuar hasta conducir a resultados inseguros, esto constituye un problema. Soluciones: no es suficiente que los componentes instalados estΘn firmados. Ni siquiera es suficiente que estΘn firmadas las instrucciones que controlan la instalaci≤n. Es la combinaci≤n lo que importa. Pero ni siquiera eso basta. El control Active Setup s≤lo deberφa instalar cosas para las que disponga de permiso firmado DESDE EL ORIGEN. Por ejemplo, si alg·n firmante pretende instalar un componente Microsoft desde otro CAB, entonces ese firmante debiera tener certificado de Microsoft donde se establezca que el componente puede ser instalado independientemente por ese firmante en concreto y para ese prop≤stio especφfico. En pocas palabras: instalar cualquier componente desde otro CAB necesita un permiso especφfico por parte del firmante de ese CAB. Pßgina web de Juan Carlos Garcia Cuartango: http://www.angelfire.com/ab/juan123/iengine.html El descubrimiento de Cuartango en las noticias: http://www.wired.com/news/print/0,1294,34474,00.html http://www.zdnet.com/pcweek/stories/news/0,4153,2448411,00.html http://www.computerworld.com/home/print.nsf/all/000224EF5A Un arreglo de noviembre del 99 para el control Active Setup: http://www.microsoft.com/technet/security/bulletin/ms99-048.asp http://www.microsoft.com/technet/security/bulletin/fq99-048.asp Algo sobre Active Setup, en parte desfasado: http://msdn.microsoft.com/library/periodic/period98/vbpj0798.htm http://msdn.microsoft.com/workshop/components/downcode.asp http://msdn.microsoft.com/library/techart/msdn_signmark.htm Mi cita favorita procede de la tercera URL: "Si la seguridad se pone a cero, entonces todo funciona". Es bueno saberlo. C≤mo crear una instalaci≤n mφnima de Explorer 5: http://www.helpfulsolutions.com/Silent_IE5_Install.htm Este artφculo fue elaborado por Gregory Guerin. ----------------------------------------------------- NOTA DE KRIPTOPOLIS: Recordamos a nuestros lectores que el primer artφculo publicado por nuestro colaborador Juan Carlos Garcφa Cuartango respecto a este tema apareci≤ -precisamente- en nuestro web el 15 de febrero del 2000 bajo el tφtulo "Firmado de software y puertas traseras". 8. La Ley sobre uniformidad en las transacciones de informaci≤n por ordenador (UCITA) ==================================================== Por Bruce Schneier Traducci≤n: Francisco Leal Vßzquez http://www.kriptopolis.com/criptograma/0024_8.html El gobernador de Virginia James S. Gilmore III firm≤ la UCITA, que ahora es una ley en Virginia. La legislatura de Maryland aprob≤ de manera abrumadora el proyecto, que va camino de convertirse en una ley en ese estado. Yo puse este horrible fragmento de legislaci≤n en la ratonera el mes pasado, pero merece la pena revisar una parte de la ley que afecta particularmente a la seguridad informßtica. Seg·n una parte de la UCITA, los fabricantes de software tienen el derecho a desactivar el software de forma remota si los usuarios no acatan el acuerdo de licencia. (Si no pagan por el software, por ejemplo). Como un profesional de seguridad en ordenadores, pienso que esto es una locura. Lo que significa es que los fabricantes pueden poner una puerta trasera en sus productos. Enviando alg·n tipo de c≤digo por Internet, ellos pueden "apagar" sus productos (o, presumiblemente, ciertas caracterφsticas de sus productos). Lo ingenuo y arrogante de esto es pensar que s≤lo los fabricantes conocerßn siempre el c≤digo de inhabilitaci≤n, y que los hackers nunca podrßn obtenerlos y ponerlos en Internet. Esto es, por supuesto, ridφculo. Las herramientas serßn escritas y divulgadas. Una vez ocurra esto, serß fßcil para los hackers maliciosos inhabilitar los ordenadores de la gente, s≤lo por diversi≤n. Este tipo de hacking harß que el Back Orifice parezca "suave". La criptografφa puede proteger de este tipo de ataques -los c≤digos pueden ser firmados digitalmente por los fabricantes, y el software no contendrφa asφ la clave de seguridad- pero para que esto funcione, el sistema al completo debe ser implementado perfectamente. Dado el camino que llevan las industrias en cuanto a la implementaci≤n de criptografφa, no tengo demasiadas esperanzas. Poner una puerta trasera en los productos software es buscarse problemas, no importa quΘ tipo de controles se traten de llevar a cabo. La UCITA es una mala ley, y esta es s≤lo su peor parte, pero no la ·nica. Anda rondando las asambleas legislativas de la mayorφa de los estados. Recomiendo encarecidamente a todo el mundo a que inste a las personas implicadas, o que tengan algo que ver con ella, a que no la aprueben. Virginia: http://www.washingtonpost.com/wp-dyn/articles/A6866-2000Mar14.html Maryland: http://www.idg.net/idgns/2000/03/29/UCITAPassesMarylandHouse.shtml 9. Comentarios de los lectores ==================================================== http://www.kriptopolis.com/criptograma/0024_9.html De: "John J. Adelsberger III" (jja@wallace.lusars.net) Asunto: Seguridad y complejidad ------------------------------------------------------- Traducido por David G≤mez > Los sistemas reales no muestran signos de hacerse > menos complejos. De hecho, estßn volviendose mßs > complejos rßpidamente. Microsoft Windows es un ejemplo > caracterφstico de esta tendencia a la complejidad. Es habitual tomarla con Microsoft, pero serφa mßs justo tomarla con el mundo comercial al completo. La seguridad, para una compa±φa que estß intentando hacer dinero, es una cuesti≤n de Relaciones P·blicas, y s≤lo se convierte en un asunto tΘcnico siempre y cuando las malas RP sean la alternativa. La raz≤n es obvia; tratar bien la seguridad cuesta dinero, y para la mayorφa de los clientes, la apariencia es tan vßlida como el artφculo genuino, y no porque de verdad no les importe, sino porque no tienen manera alguna de saber la diferencia. No puedo culpar a las compa±φas por lo que intentan hacer; el hecho de que tanta gente rechace admitir estos hechos es mßs problemßtico. > La otra elecci≤n es ir mas despacio, simplificar, > e intentar a±adir seguridad. OpenBSD hace esto. No estoy al tanto de alg·n otro grupo, cuyos trabajos sean p·blicamente visibles, que haga algo asi, lo que lamento, porque preferirφa que esto no pareciera un anuncio de OpenBSD; de hecho, mi prop≤sito es se±alar que no s≤lo es viable esta aproximaci≤n, sino que ademßs esta siendo realizada. Destacar tambiΘn que la actitud es mucho mßs frecuente en la prßctica que las habilidades o la energφa para trabajar en ello. Hay grupos de seguridad asociados con todos los productos de cierta importancia, pero la mayorφa de ellos, tan bien intencionados e impacientes como suelen ser, hablan mucho y no hacen demasiado. Esto es bastante malo, porque si un n·mero mayor de ellos hicieran algo, los consumidores no tardarφan tanto en comprender el valor que esto puede proporcionar, a·n sin existir uan comprensi≤n real de los medios por los cuales se ha conseguido. Por cierto, la comprensi≤n por parte del consumidor no es algo tan importante. Comprender un producto es distinto de comprender lo que hace, c≤mo, y c≤mo de bien. Los consumidores no tienen que ser expertos en seguridad o fiabilidad; lo que se necesita es informaci≤n de una tercera parte razonablemente objetiva sobre estos temas, que gente como usted puede proporcionar. Destacar que los coches conocidos por su seguridad, fiabilidad y consumo de combustible son los mßs vendidos, a pesar del hecho de que la mayorφa de los clientes no prestan mucha atenci≤n al kilometraje que tienen y no disponen de una manera certera de evaluar por sφ mismos la seguridad o fiabilidad de un producto tan complejo. Por supuesto, la infraestructura necesaria tarda tiempo en desarrollarse y a·n mßs tiempo en deshacerse de los incompetentes, pero esta es la direcci≤n en la que hay que moverse. De: "Andrew D. Fernandes" (andrew@cryptonym.com) Asunto: Simple contra Complejo ------------------------------------------------- Traducido por David G≤mez Mis conocimientos matemßticos pertenecen al ßrea de los "sistemas dinßmicos", mßs popularmente conocidos como la "teorφa del caos". Uno de los principios de la investigaci≤n en los sistemas dinßmicos es que "los sistemas simples pueden tener dinßmicas muy complejas". ┐Como afecta este principio a las conclusiones de su artφculo? Digamos simplemente, que usted estß confundiendo un sistema 'simple' (un sistema que es fßcil de describir), con el comportamiento dinßmico 'simple' del sistema. En otras palabras, el sistema puede ser fßcil de describir, pero el comportamiento puede ser muy difφcil de describir. Lo contrario tambiΘn es verdad: un sistema con una descripci≤n muy compleja puede tener un comportamiento dinßmico muy simple. Por ejemplo, el tφpico caso es el mapa iterativo x[n+1] = - -alpha*x[n]*(x[n]-1), para 0 <= x <= 1, 0 <= alpha <= 4. Este es un sistema "simple", que es fßcil de describir. Pero las dinßmicas del sistema son muy complejas. Cientos de trabajos de investigaci≤n han sido escritos para describir y comprender la secuencia de x[0], x[1], x[2], ... y salen mßs cada dia. De hecho, el comportamiento de este mapa cuadrßtico es lo suficientemente complicado como para ser la piedra angular de la moderna "teorφa del caos"! En el contexto de la seguridad, nuestro "sistema" es un applet de Java, un control ActiveX, una macro de Word, una configuraci≤n SSL, o una sesi≤n IPSec. Entonces nuestro "comportamiento dinßmico" es una medida de la seguridad del sistema. Podemos simplificar las propiedades de la seguridad del sistema tanto como queramos, pero las dinßmicas totales de la seguridad pueden ser, y probablemente serßn, muy complejas. Entonces, aunque estoy de acuerdo en que s≤lo los sistemas simples pueden ser seguros, no estoy de acuerdo en que se pueden construir sistemas con un comportamiento simple usando sistemas que son fßciles de describir. Se estß enga±ando a sφ mismo: el mßs peque±o cambio a un sistema simple puede hacer sus dinßmicas horriblemente complicadas. En el mapa cuadrßtico, cambios muy peque±os en alpha derivan en enormes cambios sobre c≤mo se comporta el sistema. En realidad, se pueden construir sistemas complejos seguros asegurßndose de que las dinßmicas de las propiedades de seguridad del sistema permanecen simples. Este objetivo estß relacionado, pero definitivamente no es idΘntico, al objetivo de construir un sistema con una descripci≤n simple. Para construir sistemas complejos con un comportamiento simple, necesitas modularizar no s≤lo el sistema, sino tambiΘn el comportamiento del sistema... pero discutir c≤mo hacer esto, desde un punto de vista de matemßtica abstracta o de programaci≤n prßctica, estß mßs allß de las pretensiones de este mensaje. De: Clifford Neuman (bcn@isi.edu) Asunto: Microsoft Kerberos ---------------------------------- Traducido por Sergio Pozo Hidalgo Ha habido muchos artφculos y comentarios reprochando a Microsoft el haber extendido el estßndar Kerberos de formas que son supuestamente incompatibles con las implementaciones existentes. Estos comentarios tambiΘn atribuyen a Microsoft los motivos para forzar a utilizar su implementaci≤n de Kerberos por cualquiera que quiera interoperar con Windows 2000. Aunque Microsoft se ha tomado mucho tiempo para publicar los detalles de los contenidos de la autorizaci≤n de datos y c≤mo los estßn usando, en mi opini≤n, sus extensiones son consistentes con el borrador de Internet de Kerberos, y el uso que han hecho del campo de autorizaci≤n de datos es consistente con su objetivo original. No hay actualmente ning·n estßndar para representar la informaci≤n de grupo en el campo de autorizaci≤n de datos de los tickets de Kerberos, luego no puedo reprochar a Microsoft el haber desarrollado el suyo. Como parte del dise±o y puesta en circulaci≤n de los componentes de seguridad de Windows 2000, registraron identificadores para sus elementos de autorizaci≤n de datos, y discutieron los asuntos del uso de su arquitectura de alto nivel conmigo y con otros en la comunidad Kerberos. Esto estß resaltado por el hecho de que su antigⁿo dise±o invitaba a una interpretaci≤n de campo de autorizaci≤n de datos que era inconsistente con su uso definido e intenci≤n. DespuΘs de discutir (y antes de que inplementaran), trabajamos en una extensi≤n que 1) preservaba el objetivo original, 2) mejoraba significativamente la funcionalidad del campo de autorizaci≤n de datos para la autorizaci≤n por cualquiera, no s≤lo Microsoft, y 3) estß especificada en el actual borrador de Internet de Kerberos que revisa la especificaci≤n. Respecto a la seguridad de la implementaci≤n de Kerberos de Microsoft, no sΘ de ning·n cambio realizado sobre el protocolo que haya afectado a la seguridad del mismo. Tengo algunas inquietudes sobre el almacenamiento de llaves de KDC en el Directorio Activo, pero es una implementaci≤n y no un asunto del procolo, y Microsoft afirma haber tomado medidas en el dise±o para prevenir el acceso a las llaves por otro que no sea KDC. No obstante, no he revisado estos pasos al detalle. Respecto a algunos de los asuntos de nombres, pienso que hubo algunos problemas de interoperabilidad causados por las diferencias en los nombres, pero tambiΘn mantengo la opini≤n de que Microsfot public≤ parches para solucionar esta incompatiblidad. Se originan problemas similares con la interoperabilidad entre DCE y Kerberos en bruto, y no me sorprende que alcanzar la interoperabilidad total en los nombres en otras partes del sistema y a la luz de las diferencias inherentes, pudiera requerir varias revisiones en las que trabajar. Respecto a la canonizaci≤n de los nombres, los cambios que estß realizando Microsoft se dirigen hacia limitaciones relevantes de seguridad que ha tenido Kerberos respecto al mapeo de los nombres de servidores a nombres principales (esto es algo que Kerberos originalmente nunca tuvo la intenci≤n de tener en cuenta). Las propuestas de Microsoft en este ßrea han sido sometidas en el contexto del IETF, y confφo en que los cambios se vean reflejados en los documentos de seguimiento de los estßndares. Mßs genΘricamente, en el frente de la interoperabilidad, Microsoft ha trabajado muy de cerca con CyberSafe para demostrar la interoperabilidad de la autenticaci≤n con los clientes de CyberSafe, utilizando KDCs existentes en CyberSafe en plataformas que no son Windows 2000. He comprobado que los indivφduos de Microsoft que han estado trabajando en Kerberos han contribuido positivamente al proceso de estßndares del IETF. Estos individuos quieren interoperabilidad autΘntica, y han actuado de buena fe. El uso del campo de autorizaci≤n de datos *ES* consistente con la letra y la intenci≤n de la especificaci≤n de Kerberos, y estoy contento de ver algunas de las ideas de autorizaci≤n para las que el campo de autorizaci≤n de datos fue concebido, ganando extensi≤n en su uso. Sin embargo, reprocho a Microsoft no haber publicado a·n los detalles de su uso del campo de autorizaci≤n de datos tal y como ha prometido repetidamente, y espero que la comunidad y la prensa contin·en presionßndolos para que publiquen la especificaci≤n como un RFC informativo. De: Martin Rex (martin.rex@sap-ag.de) Asunto: Microsoft Kerberos ------------------------------------- Traducido por Sergio Pozo Hidalgo No estoy de acuerdo con la mayorφa de las quejas sobre la implementaci≤n de Kerberos realizada por Microsoft en Windows 2000. He estado mirando y probando Kerberos con Microsoft Windows 2000 un poco y estas son mis conclusiones: - - No he apreciado problemas de interoperabilidad con MIT Kerberos 5 v1.0.5. No se podrφa acceder a los archivos compartidos o servicios de Windows 2000 con tickets de un KDC que no sea de Microsoft, pero eso no es problema de la autenticaci≤n, sino de los ACLs que los servicios de Microsfot utilizan para conceder el acceso a esos recursos. Las aplicaciones que dependan de autenticaci≤n basada en nombres funcionarßn en Windows 2000 como uno esperarφa, y los clientes basados en Windows 2000 pueden acceder a aplicaciones en Unix que conceden acceso vφa autenticaci≤n basada en nombres. - - Kerberos de Microsoft Windows 2000 *ES* conforme al RFC1964 (el mecanismo gssapi de Kerberos5). Con una capa o envoltorio SSPI adecuado (el cual he escrito y mi compa±φa lo entregarß de forma gratuita), una aplicaci≤n portable y respetuosa con API GSS no notarß diferencia alguna entre Kerberos de Windows 2000 y Kerberos5 del MIT. Pueden existir min·sculos asuntos cosmΘticos respecto a los "nombres de servicio". Sin embargo, estos son confusos y no estßndar en todos los Kerberos existentes. - - La autenticaci≤n normal basada en nombres funcionarß bien en clientes Windows 2000 cuando estΘn comunicßndose con aplicaciones en Unix, siempre que una de ellas estΘ usando la API GSS. Escribφ la envoltura SSP de Kerberos para Windows 2000 con este prop≤sito exactamente. - - La (reconocidamente a·n indocumentada) extensi≤n con la autorizaci≤n de datos es necesaria para permitir la ejecuci≤n de todos los ACLs de POSIX por el TCB, que es como las aplicaciones en plataformas Microsoft Windows NT deben realizar la autorizaci≤n de acuerdo con Microsoft (palabra clave: personificaci≤n). Microsoft no es la primera en implementar los ACLs de POSIX; DCE lo hizo un tiempo atrßs. Aunque usaron un ticket adicional (un PTGT), el efecto es el mismo. Ambos Kerberos, el de DCE y el de Windows 2000, a·n soportan la autenticaci≤n tradicional basada en nombres. Personalmente, no me gusta esta personificaci≤n, porque eso significa que un servidor con pocos privilegios conseguirφa una amplificaci≤n de permisos sencillamente cuando se conectara un administrador (de dominios). Combine esto con una delegaci≤n automßtica (que podrφa haber ocurrido con Windows 2000) y conectarse a otras mßquinas en la red se convertirφa en un serio problema de seguridad. - - El problema mßs serio de Kerberos con la autenticaci≤n basada en nombres de Windows 2000 es que en las herramientas administrativas, cuando un nombre de logon concreto desconecta, no impiden al administrador reutilizar este nombre de logon para un nuevo usuario. Esto puede causar problemas con los ACLs de aplicaciones que realizan autenticaci≤n basada en nombres. En las plataformas Microsoft Windows NT, los ACLs contienen UUIDs y/o SIDs, no nombres. Esto parece ser la tradici≤n en los ACLs de POSIX, que dejan huΘrfanas entradas ACL de forma habitual y no se preocupan de ellas. De: Joe_Otway@ampbanking.com.a Asunto: Seguridad mediante oscuridad ------------------------------------- Traducido por Oscar Esteban SΘ que usted es un gran admirador del enfoque de seguridad mediante oscuridad, asφ que considerΘ que podrφa ser de tu interΘs esta referencia al PIX de Cisco que he encontrado en http://208.201.97.5/ref/hottopics/security/firewalls.html. El artφculo de Brian Robinson trata sobre cortafuegos y dice cosas como... "A diferencia de Windows NT o los cortafuegos basados en UNIX, el PIX estß construido desde cero, y las fuentes estßn celosamente guardadas", dijo Eric Woznysmith, ingeniero de sistemas consultor en gesti≤n de redes de seguridad en operaciones federales de Cisco. "S≤lo una decena de personas aproximadamente en todo el mundo lo ha visto. No ha habido ninguna intrusi≤n conocida a travΘs de un cortafuegos PIX". El cortafuegos PIX es utilizado por el gobierno, particularmente en agencias de inteligencia y cuerpos policiales, dijo Woznysmith, y es "empleado con profusi≤n" en el DOD (Ministerio de Defensa de los EE.UU.). Dado su Θxito, dijo, Cisco espera que mßs fabricantes ofrezcan sus propios equipos no abiertos. De: selune@hushmail.com Asunto: Publicaci≤n de 'exploits' - ---------------------------------- Traducido por Oscar Esteban En CriptoGrama, Brian Bartholomew (bb@wv.com) escribφa: Prefiero el siguiente enfoque: anunciar la existencia de una vulnerabilidad y prometer un script en un mes; esperar un mes a que el fabricante reaccione; publicar el script. Estoy de acuerdo con la primera parte del mensaje; un mes parece un buen plazo antes de publicar el script y da bastante tiempo al fabricante a reaccionar. Con lo que no puedo estar de acuerdo es con esto: Publicar es *muy importante* en estos casos para que los afectados puedan reducir su confianza en estos sistemas. íSi el control de trßfico aΘreo es vulnerable, que me lo digan para dejar de usar los aviones! Primero, hay gente que no dispone de informaci≤n por distintas causas (no tiene ordenador, estß de vacaciones...), o que estßn obligados a usar el avi≤n (viaje de negocios intercontinental). Asφ que t· evitarßs los aviones, pero algunos no (y no por la falta de publicidad) y a·n correrßn ese riesgo. Si el trßfico aΘreo es vulnerable no se trata de parar a todos los aviones que utilicen ese sistema, porque esto serφa imposible. Se trata de dejar tiempo a los administradores/proveedores del sistema para que desarrollen una soluci≤n. Aquφ estarφas jugando con la vida de la gente, debido a TUS acciones. El ejemplo del que hablas no tiene mucho en com·n con este, salvo que es un fallo de tecnologφa. Pero tu ejemplo, como decφas, es una versi≤n de seguridad-no-vital. Si yo compro un coche y hay un problema crφtico con el sistema de frenos, me gustarφa saberlo, porque es un problema de seguridad vital, lo sepan otros o no. Pero con el control de trßfico aΘreo, al publicar esta vulnerabilidad, asumes el riesgo sobre las vidas de otras personas. Sφ, estoy a favor de publicar las vulnerabilidades, pero s≤lo si se dan dos condiciones: - - No son de seguridad vital - - He avisado primero al fabricante, y le he dejado tiempo para arreglarla (digamos, dos semanas antes de avisar a mßs gente) y, si el vendedor no presta atenci≤n, incluso despuΘs de publicarla, estarφa bien publicar un script (digamos, un mes despuΘs). Ademßs, escribφas esto: Esto es el control sobre armas: "íNo castigues el homicidio, prohibe las armas en su lugar! íLos 'exploits' son un instrumento del diablo! íLos 'exploits' convierten a los chicos buenos en malos!" La respuesta correcta es: "Los humanos son responsables de sus actos. Armas, ladrillos y 'exploits' son simplemente herramientas". Aquφ, de nuevo, estoy en total desacuerdo. La bomba H puede ser simplemente una herramienta, pero no se distribuye libremente. ┐Por quΘ? Porque alguna gente simplemente estß demasiado loca como para dejarles jugar con ella. No queremos correr el riesgo de que esta gente la tenga, asφ que intentamos con todas nuestras fuerzas prohibir esta arma; por ello es una ofensa criminal poseer una bomba H. Como en el campo de la seguridad informßtica, se trata de sopesar riesgos frente a beneficios. _____________________________________________________________________ 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: * Isaac Carreras * Francisco Leal Vßzquez * Sergio Pozo Hidalgo * David G≤mez * Oscar Esteban _____________________________________________________________________ -- AVISO IMPORTANTE -- Kript≤polis dispone de la pertinente autorizaci≤n de Bruce Schneier para traducir, elaborar y publicar la versi≤n espa±ola de su boletφn Crypto-GRAM. La informaci≤n contenida en CriptoGRAMA s≤lo puede ser redistribuida siempre que se haga de forma completa y con expresa menci≤n de Bruce Schneier como autor de Crypto-GRAM y de Kript≤polis como responsable de CriptoGRAMA. Crypto-GRAM es un boletφn mensual gratuito dedicado a res·menes, anßlisis, comentarios e ideas sobre criptografφa y seguridad informßtica. Crypto-GRAM es elaborado por Bruce Schneier, presidente de Counterpane Systems, autor de "Applied Cryptography" y creador de los algoritmos Blowfish, Twofish y Yarrow. Schneier ha pertenecido a la direcci≤n de la International Association for Cryptologic Research, EPIC y VTW, y es asiduo escritor y conferenciante sobre criptografφa. _____________________________________________________________________ Este ejemplar se ha distribuido gratuitamente a mßs de 20.000 personas. Si desea recibir la edici≤n mensual de CriptoGrama y la edici≤n semanal del Boletφn de Kript≤polis, inscrφbase gratis en: http://www.kriptopolis.com/subs.html ⌐ Bruce Schneier ⌐ Kriptopolis (versi≤n en Espa±ol). _____________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: Clave en http://www.kriptopolis.com/claves/jmg.asc iQEVAwUBOQv/1xiK3dCT8TvxAQF0Wwf/cHKOWwkhERr6svL6cPfG7GfLXxj8YOw9 w28Y5V8JiU/+6v0VsyiixVnphPBw/1AfKe3MjBLZD+Pmvc37yWUizmYbcAnIEUkD wUqE/P9sC2yVmXjVZat9+2u8Er9Dl3a4qx/uVekar9FrMpUd0iPJc9KaIxKZo2o1 a4Jr/9jXEAMY4DmbK8/fJeGRj82Bss+yBLIJXZbnkuuldevk6eGNFJb+Q8x38nl+ N475oQDGE18siTDheQ5h9KHaRPLyvevzh+olJfpsPmyPEXcl+y9kGhXjyUZYrFBq 9UqRHIea112qbBct00p2n4YAmxkJWAv6+B6b/uDMPxd96R363jaBTw== =kIV+ -----END PGP SIGNATURE-----