1999 << Back To criptograma nº 15

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 15 15 de Julio de 1999 ------------------- SUMARIO: 1. El futuro del cripto-hacking 2. Noticias 3. Noticias de Counterpane Systems 4. En la ratonera: SSL chapucero 5. 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. El futuro del cripto-hacking ------------------------------- Por Bruce Schneier Traducci≤n: Angel Galindo Sßnchez ┐QuΘ es el cripto-hacking?. Al ser la primera persona que utiliza este tΘrmino, voy a definirlo. El cripto-hacking consiste en 'hackear' las matemßticas de la criptografφa; consiste en forzar a la criptografφa a hacer algo nuevo, algo diferente, algo inesperado. Consiste en expandir las fronteras de la criptografφa. Y ha estado ocurriendo regularmente durante los ·ltimos a±os. Utilizando la informaci≤n sobre tiempo de ejecuci≤n, consumo energΘtico y radiaci≤n de un dispositivo cuando ejecuta un algoritmo criptogrßfico, los cripto-hackers han sido capaces de "romper" tarjetas inteligentes y otros entornos "seguros". Es a lo que se denomina "ataques indirectos". Forzando la aparici≤n de fallos durante las operaciones, los cripto-hackers han sido capaces de romper todavφa mßs tarjetas inteligentes. Es a lo que se denomina "anßlisis de fallos". En una bonita muestra de cripto-hacking, un investigador fue capaz de romper RSA en su formato PKCS. La "rotura" no fue tanto de RSA, como de la forma en que se habφa implementado. Piense en la belleza de Θsto: no sabemos c≤mo factorizar n·meros y no sabemos c≤mo romper RSA, pero si se utiliza RSA de una determinada manera, que ademßs es bastante com·n, entonces es posible romper la seguridad de RSA en algunos sistemas...sin romper RSA. Los cripto-hackers han analizado muchos sistemas rompiendo el generador de n·meros aleatorios que se utiliza para la obtenci≤n de llaves criptogrßficas. Los algoritmos criptogrßficos podφan ser seguros, pero los procedimientos de generaci≤n de llaves no lo eran. De nuevo, fφjese en la belleza: el algoritmo es seguro, pero el mΘtodo de producir llaves para el algoritmo tiene un punto dΘbil, lo que significa que en realidad no hay tantas llaves posibles como deberφa haber. Los investigadores han roto sistemas criptogrßficos analizando la forma en la que diferentes llaves estßn relacionadas entre sφ. Cada llave puede ser segura, pero la combinaci≤n de varias claves relacionadas puede ser suficiente para criptoanalizar el sistema. Lo que tienen en com·n todos estos ataques es que han aumentado el ßmbito de alcance del criptoanßlisis. Antes de los ataques indirectos, los cript≤grafos nunca pensaron en utilizar otra informaci≤n que el texto plano y el texto cifrado para atacar algoritmos. DespuΘs de la primera publicaci≤n en este sentido, los investigadores comenzaron a analizar diferentes ataques indirectos, ataques invasivos, ataques basados en la introducci≤n de errores transitorios o permanentes, etcΘtera. De repente, habφa toda una nueva forma de hacer criptoanßlisis. Cripto-hacking = hacer trampas Hace algunos a±os estaba yo hablando con un empleado de la NSA sobre un ataque en concreto. ╔l me cont≤ la historia de c≤mo se rompi≤ un determinado sistema; era un ataque rastrero, que nunca hubiera pensado que fuese significativo. "Eso es hacer trampas", dije. Me mir≤ como si yo acabase de llegar de Neptuno. Hacer trampas es uno de los principios bßsicos de la ingenierφa de seguridad. La ingenierφa convencional trata de que las cosas funcionen. ╔sa es la gΘnesis del tΘrmino "jaquear", como en "Trabaj≤ toda la noche y logr≤ jaquear el c≤digo". El c≤digo funciona, y no importa su aspecto. La seguridad es diferente; es hacer que las cosas seguras no dejen de funcionar. Es hacer que no se rompa la seguridad, incluso aunque exista un adversario malicioso que hace todo lo que estß en su mano para asegurarse de que las cosas no funcionen, en el peor momento y de la peor forma posible. Un buen ataque es aquel sobre el que los ingenieros nunca han pensado. Los buenos atacantes hacen trampas. Y el futuro del cripto-hacking es el futuro de las trampas. La gente inteligente continuarß inventando nuevas formas de atacar a las matemßticas de la criptografφa. Como cualquier otra clase de hacking, el cripto-hacking requiere unas capacidades especφficas. La capacidad criptogrßfica mßs importante son las matemßticas avanzadas; no puedes criptoanalizar sistemas sin ellas. No puedes hacer trampas sin ellas. Puedes romper sistemas que utilizan la criptografφa esquivando la criptografφa, pero eso no es cripto-hacking. Cripto-hacking significa jaquear la criptografφa, lo que implica matemßticas avanzadas. Y esa es la raz≤n por la que no se ven muchos cripto-hackers por ahφ: las matemßticas son duras. La mayorφa del cripto-hacking que hemos visto no proviene de individuos marginales ajenos al sistema establecido, sino de gente que trabaja dentro de ßmbitos convencionales: estudiantes y algunos investigadores acadΘmicos o empresariales. No recuerdo ning·n ataque de cripto-hacking de alguien con una palanca. De hecho, la mayorφa de los cripto-hackers consiguen una publicidad positiva increible de sus ataques: artφculos en peri≤dicos, publicaciones acadΘmicas, galardones. No hay mucho cripto-hacking marginal tras ellos. Hay algunas herramientas de cripto-hacking, pero no muchas. Algunos programas que se aprovechan de contrase±as muy dΘbiles en UNIX y NT o PGP, para romper el cifrado. Hay un programa que trata de romper el cifrado de PKZip, basßndose nuevamente en la elecci≤n de malas contrase±as. Pero no existen herramientas prßcticas que permitan hacer un cripto-hacking serio, simplemente porque se necesitarφan muchos conocimientos matemßticos para utilizarlas. No creo que esto vaya a cambiar en el futuro. La criptografφa continuarß siendo una ciencia matemßtica, y el cripto-hacking serß exactamente lo mismo. Habrß toda clase de ataques de cripto-hacking ingeniosos, pero nunca serß algo a lo que puedan dedicarse las masas. 2. Noticias ------------ Por Bruce Schneier Traducci≤n: Antoni Muntaner El mensaje cifrado de la escultura de la CIA en Langley: http://www.abcnews.go.com/onair/WorldNewsTonight/wnt9990615_ciacode.html He aquφ una versi≤n gratis en Java de TLS (el sucesor de SSL): http://www.rtfm.com/puretls/ EntΘrese de la postura del Gobierno USA en cuanto a la criptografφa en "Cifrado: impacto en el cumplimiento de la Ley". El informe de 17 pßginas trata sobre el uso y el beneficio del cifrado, sus inconvenientes para de la aplicaci≤n de la Ley, el concepto de cifrado recuperable (GAK), la postura de la administraci≤n Clinton sobre cifrado y la legislaci≤n actual sobre el tema. Nada nuevo. http://sion.quickie.net/en60399.pdf Alguien del Reino Unido escribi≤ un documento: "Posibles capacidades de descifrado de la NSA", que esboza una mßquina de craqueado que la NSA podrφa construir. http://jya.com/nsa-study.htm Gran alerta. Hay gente en el Pentßgono dispuesta a renunciar a la seguridad informßtica y desconectarse de Internet. http://sun.soci.niu.edu/~crypt/other/jdripper.htm Para un buen anßlisis de esta est·pida idea, leer: http://kumite.com/myths/opinion/discnect.htm Seg·n funcionarios federales, las webs federales y sus sistemas informßticos son particularmente vulnerables a ataques externos porque carecen de dos elementos importantes: asunci≤n de planes de seguridad y personal cualificado para mantener las medidas de seguridad. http://www.newspage.com/cgi-bin/NA.GetStory?story=h0624132.500 &date=19990625&level1=46510&level2=46515&level3=821 http://www.mercurycenter.com/svtech/news/breaking/merc/docs/001859.htm Ha sido aprobado por el ComitΘ de Comercio del Senado, un proyecto para otrogar a las firmas digitales validez legal. http://www.news.com/News/Item/0,4,38262,00.html Aquφ hay un excelente estudio sobre logaritmos discretos. "Logaritmos discretos: el pasado y el futuro". http://www.research.att.com/~amo/doc/crypto.html China ve una amenaza para la Seguridad Nacional en P3. Demasido c≤mico para describirlo con palabras: http://jya.com/cn-p3-peril.htm Los planes del gobierno britßnico para dotar a su policφa y agencias de inteligencia con nuevos poderes para forzar la revelaci≤n del material cifrado utilizado en el comercio electr≤nico: http://www.techserver.com/noframes/story/0,2294,66202-104800-744684-0,00.html Documento del CERT sobre temas de seguridad de los cortafuegos y mejores prßcticas: http://www.cert.org/security-improvement/modules/m08.html íTodos se echan sobre Microsoft! http://www.zdnet.com/zdnn/stories/news/0,4586,2290399,00.html Un buen ejemplo de la clase de fraude que uno puede perpetrar cuando se pueden robar peniques (bueno, digamos 19┤95 d≤lares) a un mont≤n de gente: http://www.sciam.com/1999/0899issue/0899cyber.html Hay muchas opiniones sobre la imparcialidad de los protocolos. http://www.newscientist.com/ns/19990717/newsstory9.html La web de DefCon fue atacada por un grupo de hackers alemanes que no pudieron pagarse el billete de avi≤n para asistir. http://www.news.com/News/Item/0,4,38970,00.html Ordenadores con m≤dems de alta velocidad (cable o DSL) y direcciones estßticas IP son vulnerables a los ataques exploratorios de los hackers. (Este podrφa ser un potencial nuevo mercado para comercializadores de cortafuegos). http://www.nytimes.com/library/tech/99/07/circuits/articles/08hack.html En la secci≤n de noticias del mes pasado, prometφ escribir mßs sobre el cifrado de correo electr≤nico vφa web. Ese artφculo serß postergado al mes que viene, ya que todavφa estoy recogiendo informaci≤n. 3. Noticias de Counterpane Systems ---------------------------------- Por Bruce Schneier Traducci≤n: Antoni Muntaner Bruce Schneier impartirß un curso de un dφa sobre criptografφa en las dos conferencias de SANS. Ver http://www.sans.org/newlook/home.htm para los detalles de dichas conferencias: SANS Network Security '99 5 de Octubre 1999, New Orleans, LA SANS Security San Francisco '99 12 de Diciembre 1999, San Francisco, CA John Kelsey hablarß en el Sexto Taller Anual sobre Areas Seleccionadas en Criptografφa (SAC). el 8 y 10 de Agosto en Ontario. Los detalles en http://www.engr.mun.ca/~sac99/: Criptoanßlisis de DEAL Yarrow-160: Notas sobre anßlisis y dise±o de su generador de n·meros seudoaleatorios. Un artφculo sobre la charla de Bruce Schneier en el BlackHat de Las Vegas: http://www.computerworld.com/home/news.nsf/all/9907095crypto 4. En la ratonera: SSL chapucero -------------------------------- Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez Para la mayorφa de la gente, SSL es la varita mßgica de la seguridad, que automßticamente vuelve segura la navegaci≤n Web. Pero las cosas no son tan fßciles. En onsale.com, es necesario registrarse antes de poder comprar cosas. El formulario estß en https://www.onsale.com/atcost/custserv/atregister.htm. De acuerdo; utilizan IIS, y al menos han activado SSL. DΘles sus datos personales y su n·mero de tarjeta de crΘdito y enviΘlo. Pero si observa el c≤digo fuente HTML, verß: FORM METHOD="POST" ACTION="http://pecos.onsale.com/...". Emplean SSL para proporcionar el formulario, pero vuelven a texto en claro para recibir los datos. Verisign utiliza SSL, pero olvidaron proteger por lo menos una parte de su sitio web: http://www.verisign.com/developers/index.html. Puede pulsar sobre varias opciones, de las cuales aquellas que permiten obtener un Authenticode o un Identificador de firma de objetos son seguras, pero pulse sobre los enlaces para la "Guφa Gratis" de Authenticode o Firma de Objetos y estarß introduciendo (y enviando) su informaci≤n personal en claro, incluyendo el obligatorio n·mero de telΘfono. Spree.com , que recientemente se asoci≤ con Barnes and Noble para vender libros en lφnea, emplea s≤lo SSL de 40-bit. Debido a la forma en que utilizan los marcos en su pßgina web, no aparece en pantalla el icono del candado para indicar si se estß empleando alg·n tipo de cifrado. BizTravel (http://www.biztravel.com) es el caso mßs ofensivo. Todas las entradas bajo identificador de usuario y contrase±a estßn sin cifrar. Cualquiera que intercepte esa entrada puede adquirir billetes de viaje en nombre del usuario con la informaci≤n de su tarjeta que estß archivada en BizTravel. Muchos de esos billetes son electr≤nicos, por lo que el envφo de papeles a una direcci≤n del registro importa poco aquφ. Una consulta al equipo de apoyo de BizTravel proporciona esta respuesta: "Su contrase±a estß cifrada. De hecho, ni siquiera nosotros podemos acceder a ella. Si usted perdiera su contrase±a tendrφamos que proporcionarle otra provisional. Tenemos la posibilidad de utilizar el sitio bajo la opci≤n "servidor seguro" del men· principal. Confφamos en que esto elimine sus preocupaciones respecto a utilizar BizTravel.com." No pude encontrar el enlace al servidor seguro por ning·n sitio. 5. Comentarios de los lectores ------------------------------ Por Bruce Schneier Traducci≤n: Isidre Marques Serret y Jaime Millßn de Castro De: John Kelsey kelsey@counterpane.com Tema: Malware (Software malicioso) en Internet - - - - - - - - - - - - - - - - - - - - - - - - La velocidad de propagaci≤n es una de las amenazas. El otro es que estos virus de macro pueden ser mucho mßs complejos que sus parientes ejecutables, porque si solo infectan documentos grandes, el cambio en el tama±o serß mucho menos perceptible. ┐Por quΘ no incluir un buen motor de mutaci≤n dentro del documento, cifrado y guardado para parecer datos vßlidos? ┐O un programa para probar varios de los agujeros de seguridad conocidos en la red interna, y explotarlos para propagarse? Si un virus puede permitirse tener un tama±o de 500 KB se le abre un amplio abanico de posibilidades, malas para nosotros. Si debe propagarse sobre disquetes de 1.44 MB simplemente estß mucho mßs limitado. Una cosa interesante sobre estos virus es que generalmente no necesitan hacer nada obviamente da±ino en el sistema sobre el que funcionan. Simplemente tienen que ser capaces de hacer uso del e-mail del sistema. Asφ que los esquemas de permisos para archivos no sirven de nada en este caso. El usuario que lee un e-mail casi siempre estß, tambiΘn, autorizado a enviarlo. Incluso en sistemas como Unix y Windows NT con una autΘntica seguridad implementada, los virus se pueden extender perfectamente. Pienso que el problema fundamental es que la gente emplea el e-mail para intercambiar datos (y macros) de programas que no incluyen ning·n control de seguridad. ┐Por quΘ alguien que estß dise±ando un programa freeware para visualizar archivos PostScript, un compilador LaTeX, un visor de JPEG, un descompresor de archivos, etc., debe perder demasiado tiempo preocupßndose de los agujeros de seguridad? Pero un atacante puede, razonablemente, inspeccionar estos programas para buscar agujeros de seguridad. Hay un tipo concreto de ataques a redes que son bßsicamente intentos de utilizar los servicios proporcionados por esa misma red al mundo exterior, para comprometer la integridad de las mßquinas que proporcionan estos mismos servicios. Pienso que los ataques usando el e-mail son un tipo muy relacionado con estos. El problema es que permitiendo la entrada de archivos de Excel adjuntos al e-mail, estamos convirtiendo a Excel en un servicio mßs de la red, como NFS o FTP. Se pueden enviar datos desde fuera de la mßquina objetivo; esta actuarß de acuerdo con estos datos y puede enviar una respuesta. No importa si los datos se envφan en forma de paquetes de datos o en forma de e-mail. Por supuesto, esto es desastroso para la seguridad, porque Excel, Word y un mill≤n de otros programas mono-usuario no estßn preparados para ser seguros cuando se les pide que ejecuten un c≤digo maligno. Los virus de macro no son tan difφciles de resistir; simplemente haciendo que los programas pidieran una confirmaci≤n al usuario antes de ejecutar cualquier macro se darφa un gran paso en esta direcci≤n. Una cosa mßs preocupante es que casi seguro que hay fallos en Excel y Word que permiten dar un formato incorrecto al archivo causando un error de desbordamiento de buffer, o causar cualquier otro comportamiento maligno. En los sistemas operativos con alg·n tipo de seguridad incorporado (es decir, NO Windows 95 o 98), serφa ideal capacitarlos para abrir los archivos adjuntos, por defecto, en un entorno similar al chroot de Unix. Esto no solamente restringirφa los cambios a un directorio especφfico, sino que ademßs permitirφa prohibir cualquier comunicaci≤n con el mundo exterior. Seguramente, esto no serφa difφcil de incluir en un sistema operativo con permisos de usuario y demßs. Los archivos adjuntos a un e-mail, esencialmente, crean un nuevo conjunto servicios de Internet corriendo sobre las mßquinas de los usuarios. Los archivos adjuntos al e-mail son mensajes directos a programas (como Excel, Word o la lφnea de comandos de DOS/Windows en los que nadie piensa como un servicio de red; nadie ôpiensaö en ellos como en un servicio de red, pero si aceptan datos de fuentes inseguras en la red, act·an de acuerdo con ellos, e incluso a veces responden de acuerdo con los mismos, ôsonö un servicio de la red, por lo menos en lo que a seguridad concierne) los atacantes pueden estar planteßndoselos como un posible punto de ataque, buscando provocar errores de desbordamiento de buffer y similares. El hecho de que el usuario deba abrir el archivo adjunto ayuda a evitarlo, pero se le puede enga±ar fßcilmente. Cada aplicaci≤n que funciona en su mßquina y puede ser ejecutada abriendo un archivo adjunto, ahora, se ha convertido en un servicio de red. Una primera lφnea de defensa estß en limitar los tipos de archivos adjuntos que pueden enviarse a travΘs del cortafuegos, o que pueden ser abiertos por el programa de e-mail. Si ·nicamente pueden usarse para abrir archivos adjuntos las aplicaciones sin capacidades de macro, puede representar una cierta protecci≤n. (Eventualmente se podrφan incluir opciones de lφnea de comandos en programas como Word y Excel que anularan enteramente la ejecuci≤n de macros; estas opciones podrφan incluirse en la llamada del sistema de correo a esos programas, otros de estos "servicios de red" se desconectarφan completamente.) De: Peter Low peterlow@fletcherspaght.com Tema: Microsoft y la seguridad - - - - - - - - - - - - - - - - - - - - - Asistφ a una presentaci≤n a bombo y platillo de Microsoft (para promocionar su ôconceptoö de DNS) en Boston poco despuΘs de la aparici≤n de Melissa. Al final de la presentaci≤n, Bill Gates respondi≤ a algunas preguntas de los asistentes. Al llegar mi turno, resaltΘ que Microsoft ha simplificado el uso de los ordenadores hasta el punto en que las masas podφan hacer uso de ellos, pero a la vez, Microsoft ha depositado en estas masas la responsabilidad de protegerse a sφ mismas del malware. Se estß pidiendo a los usuarios (quienes en muchos casos no saben c≤mo funcionan las mßquinas), que decidan al abrirlos si los archivos con macros pueden ejecutarse. PreguntΘ al Sr. Gates quΘ compromiso iba a tomar Microsoft para mejorar la seguridad de sus productos para sus usuarios. Su respuesta fue menos que satisfactoria. ╔l afirm≤ que la opci≤n de pedir a los usuarios la autorizaci≤n para ejecutar las macros al abrir un archivo es una buena primera lφnea de defensa, porque ellos pueden decidir si confφan en la persona que les dio el archivo. (Caray, no he recibido nunca un archivo infectado de alguien de confianza; por otro lado tambiΘn podemos desactivar directamente esta posibilidad; ademßs, muchos usuarios novatos permitirßn la ejecuci≤n de las macros porque, simplemente, no comprenden el peligro que representan). Luego habl≤ de la posibilidad de automatizar este proceso mediante el uso de firmas digitales (Caray, apuesto que serφa mucho mßs efectivo...). Me quedΘ con la impresi≤n de que las cosas empeorarßn mucho antes de que comiencen a mejorar. Quizß Microsoft podrφa incluir campos en su base de datos de informaci≤n de los usuarios, ligados a su direcci≤n Ethernet, mostrando si estßn afectados o no por distintos tipos de virus, o cualquier otro tipo de malware, permitiendo a los usuarios verificar la base de datos antes de aceptar archivos de otros usuarios - - Apuesto a que podrφan hacer mucho dinero con este servicio. Trabajo para una firma de consultorφa, y, desgraciadamente, debo utilizar Microsoft Office para poder compartir los archivos, normalmente conteniendo macros, con nuestros clientes. No tengo ninguna manera de saber quΘ precauciones toman mis clientes con respecto al malware, y tengo la impresi≤n de que los pongo en peligro debido al pobre dise±o de los programas de Microsoft. Caray, por lo menos no tengo que usar Outlook. De: Bruce McNair bmcnair@research.att.com Asunto: Varios - - - - - - - - - - - - - - - - - - - - - En relaci≤n a los males ligados a los datos: en realidad, y por mucho que me gustara recriminar a Microsoft, ellos no fueron los primeros. Cuando el gusano de internet de Bob Morris andaba haciendo de las suyas hace ya diez a±os y cuando el punto y coma ausente provoc≤ la caφda del Signalling System 7, ya hacφamos conjeturas sobre la posibilidad de virus ligados a datos. EncontrΘ una caracterφstica de troff que te permite invocar el shell de UNIX, lo que facilitarφa a·n mßs la creaci≤n de un virus o un gusano. No sΘ cußnto hace que descubrimos que esta caracterφstica existφa, pero podemos decir que fue hace un rato. En relaci≤n a los aut≤matas modelando sistemas de inmunidad natural: yo no contarφa con esto. El sistema de inmunidad natural es efectivo a largo plazo porque protege el grupo a expensas del individuo. Sφ, mala suerte si le toca morir de neumonφa, pero si le toca sobrevivir usted y sus descendientes pueden tener mejores posibilidades a largo plazo. Es un poco difφcil imaginar el uso de un sistema informßtico distribuido y seguro que permita a los sistemas individuales (por ejemplo los terminales de los usuarios) resultar comprometidos sin fastidiar al propio usuario cuyo sistema se ha ido abajo. Ademßs, los virus sigilosos son capaces de reproducirse en el sistema inmune del paciente, incluso tras millones de a±os de desarrollo. ApostarΘ por los virus :-) En relaci≤n a los comentarios de Mr. Hewlett sobre la fiabilidad de las tarjetas de crΘdito de los consumidores: las leyes sobre tarjetas de crΘdito en Estados Unidos son muy favorables al consumidor, pero existen limitaciones (por ejemplo, estas regulaciones no se aplican a los "cheques virtuales" o a las operaciones con tarjetas de dΘbito). En general, los comerciantes soportan el mayor peso del fraude con tarjetas de crΘdito. Los consumidores son generalmente responsables de los primeros 50 d≤lares del fraude, pero los expendedores de tarjetas entienden esto de forma muy diferente. Dado que Novus (DiscoverCard) y American Express controlan directamente las relaciones entre los comerciantes y los propietarios de las tarjetas, son mßs proclives a encontrar vφas de resoluci≤n. American Express ha resuelto invariablemente cada queja que le he presentado sin alegar mi responsabilidad por los 50 primeros d≤lares. Las asociaciones de tarjetas como Visa y MasterCard estßn peor acopladas, con diferentes empresas encargadas de usuarios, comerciantes y procesado de las tarjetas. Se requiere un mayor esfuerzo por su parte para resolver estas disputas y por mi experiencia son mßs proclives a insistir en la responsabilidad de los 50 d≤lares. Curiosamente, esto puede llevar a no reclamar en el caso de un fraude esporßdico. SΘ de alguien que se vi≤ obligado a reclamar al comerciante un fraude repetido por valor de 49,95 d≤lares (justo por debajo del lφmite de los 50). En el lado del comerciante, el riesgo es enorme si se acepta una tarjeta fraudulenta. Ademßs de entregar el producto a los ladrones, se pierde la operaci≤n (menos la tasa pagada al banco), y el comerciante es penalizado con una tasa de devoluci≤n de unos 20 d≤lares o mßs. Habitualmente el comerciante dispone de dos semanas para responder a una reclamaci≤n; si su φndice de reclamaciones es lo bastante alto, pierde su presunci≤n de raz≤n y se le considera equivocado hasta que haya alguna prueba en contrario (por ejemplo, los costes son inmediatamente deducidos de su cuenta). Los comerciantes disponen de algunas defensas, pero no son grandes. Deben obtener un c≤digo de autorizaci≤n de tarjeta de crΘdito y realizar una (dura) verificaci≤n de direcci≤n. Idealmente, el envφo requerirφa una firma para ponerse en marcha, proporcionßndose la documentaci≤n necesaria para la operaci≤n (pero incluso esto podrφa no ser suficiente para apoyar una reclamaci≤n por parte del comerciante, puesto que cualquiera puede firmar el pedido). Ultimamente, se deja al propio criterio de los comerciantes de Internet la incorporaci≤n de otros instrumentos para detectar comportamientos anormales o fraudulentos. Por supuesto, estos hechos pasan por alto lo que preocupa al "p·blico general": el cifrado de datos entre cliente y servidor. Curiosamente, esto es probablemente lo que menos interesa al ladr≤n (una funci≤n muy valiosa de SSL es el asunto de la identificaci≤n, que garantiza que el sitio tiene cierto grado de legitimidad y que la URL no ha sido intervenida). En mi opini≤n, cifrar la transferencia de datos entre cliente y servidor es posiblemente la menor de las preocupaciones de seguridad, debido al acceso a la tecnologφa necesaria para robar los datos. El mayor riesgo estß en c≤mo el comerciante asegura los datos una vez que estßn ya almacenados en el ordenador de destino. Los piratas han robado decenas de miles de n·meros de tarjetas de crΘdito en casos muy bien documentados, sin mßs que entrar en los servidores de Internet; esto es mucho mßs fßcil, considerando el n·mero de servidores y los agujeros de seguridad de los sistemas operativos. En resumen, los consumidores estßn protegidos legalmente, mucho mßs de lo que la mayorφa piensa. Los comerciantes afrontan un riesgo mucho mayor de lo que muchos imaginan. SSL es muy valioso, pero no por las razones que la gente suele pensar. Y el p·blico en general no estß prestando atenci≤n a la autΘntica amenaza: c≤mo los comerciantes protegen sus ficheros de datos. De: Paul Holman pablos@fortnocs.com Asunto: ┐QuiΘn estß en peligro? - - - - - - - - - - - - - - - - - - Aunque tΘcnicamente es correcto lo que usted afirma, usted no debe haber experimentado el fraude de tarjeta de crΘdito en sus propias carnes. Para la mayorφa de la gente, el inconveniente que esto produce merece tenerse en cuenta. Se tiene que dar aviso al expendedor de la tarjeta, dar sus datos, destruir la tarjeta y esperar una nueva. Sφ, usted s≤lo es responsable de un mßximo de 50 d≤lares, pero gastarß cientos en tΘrminos de pΘrdidas de tiempo. El fraude con tarjetas de crΘdito se estima en diez mil millones de d≤lares anuales. Los bancos no alardean de esto y prefieren mantenerlo oculto para que parezca que no existe riesgo al usar su tarjeta de crΘdito. Ese dinero tiene que salir de alg·n sitio. Directa o indirectamente, las pΘrdidas le estßn siendo repercutidas a usted. Por desgracia, implementar protocolos seguros requiere la cooperaci≤n de todos los implicados. Esto quiere decir tanto el comerciante como el consumidor. Nuestra labor en la industria de la seguridad es intentar hacer las comunicaciones tan seguras como sea posible, y una parte de ese trabajo consiste en hacerlas c≤modas de usar. ----------------------------------------------------------------- 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> ------------------------------------------------------------------