miércoles, 9 de julio de 2008

La firma digital y la seguridad

En el ámbito comercial actual, la determinación de un marco adecuado para obtener la autenticación de información basada en un sistema de computación requiere familiarizarse con conceptos y adelantos pertenecientes tanto al campo legal como de la seguridad informática ('Computer Security', 'Network Security' o 'Information Security'). La combinación de estas dos disciplinas no resulta fácil de lograr. Conceptos que entran dentro del ámbito de la Information Security no siempre se corresponden con conceptos del ámbito jurídico, aun en aquellos casos en los que la terminología es la misma. Por ejemplo, desde el punto de vista de la Information Security, firma digital significa el resultado de aplicar un determinado proceso técnico específico a una determinada información.
El concepto jurídico tradicional de firma es mucho más amplio, reconociendo cualquier signo realizado con la intención de autenticar el documento firmado. Incluso en algunos países se incluyen en el concepto de firma otros signos, como por ejemplo la imagen digitalizada de una firma realizada en papel.
Desde el punto de vista de la Information Security, estas firmas electrónicas son totalmente diferentes a las firmas digitales que se describen en este trabajo y en la literatura técnica, sin perjuicio que el término 'firma digital' sea algunas veces utilizado para significar cualquier forma de firma realizada con la intervención de una computadora. En el presente trabajo hablamos de firma digital con el sentido dado por la terminología de la Information Security.
Las firmas digitales son creadas y verificadas por medio de la criptografía . Se valen de lo que se conoce con el nombre de criptografía de clave pública, que emplea un algoritmo que contiene dos claves diferentes pero matemáticamente relacionadas, una clave para la creación de la firma digital o para la transformación de datos a una forma ininteligible, y otra clave para la verificación de la firma digital o volver el mensaje a su forma original. Al equipo y software que utiliza dichas claves se les designa colectivamente con el término Criptosistema Asimétrico.
Las claves complementarias de un criptosistema asimétrico para firma digital reciben arbitrariamente el nombre de clave privada, sólo conocida por el que firma y utilizada para la creación de la firma, y la clave pública, que puede ser conocida por los terceros, y que se utiliza para la verificación de la firma digital. En el caso que muchas personas necesiten verificar una firma digital, la clave pública debe estar al alcance o ser distribuida a todos ellos, generalmente mediante las publicación en un directorio de fácil acceso o asentada en un Registro especial. Sin perjuicio que las claves que constituyen el par se encuentran matemáticamente relacionadas, si el criptosistema asimétrico ha sido diseñado e implementado correctamente en términos de seguridad, resulta computacionalmente imposible obtener la clave privada por el hecho de conocer la clave pública. Por lo tanto, el hecho de que distintas personas conozcan la clave pública de una determinada persona y la utilicen para verificar su firma no significa que puedan descubrir la clave privada y la utilicen para firmar por su propietario. Esta circunstancia recibe el nombre de principio de irreversibilidad.
Otro proceso fundamental, denominado hash function, es utilizado tanto en la creación como en la verificación de la firma digital. Una hash function consiste en un algoritmo que, aplicado a un mensaje determinado, crea una representación digital o 'huella dactilar' denominado hash result o hash value, de una longitud fija, mucho menor que el mensaje original, pero substancialmente único a él. Cualquier modificación del mensaje produce inevitablemente un diferente hash result, cuando se utiliza la misma hash function. En el caso de una 'hash function segura', resulta computacionalmente imposible obtener el mensaje original partiendo de su hash value. Las hash functions, por lo tanto, permiten al software crear firmas digitales para operar en pequeñas cantidades de datos, a las vez que continuar proveyendo una robusta correlación con el contenido del mensaje original, asegurando que este no ha sido modificado desde que fuera digitalmente firmado.
Como se ha adelantado, la utilización de las firmas digitales comprende dos procesos, uno llevado a cabo por el firmante y el otro por el que recibe el mensaje firmado digitalmente:
La creación de la firma digital utiliza un hash result derivado y único tanto a mensaje firmado como a la clave privada.
La verificación de la firma digital consiste en la constatación de la firma relacionándola con el mensaje original y la clave pública dada, para determinar si la misma fue creada para ese mensaje utilizando la clave privada correspondiente a la referida clave pública.
Para firmar un documento o cualquier otro tipo de información a transmitir electrónicamente, el firmante debe determinar precisamente los límites de aquello que va a ser firmado. Esta información precisamente delimitada recibe el nombre de mensaje. Luego, una hash function contenida en el software utilizado produce un 'hash result', único a dicho mensaje. El software luego transforma el hash result en la firma digital, utilizando la clave privada del firmante. La firma digital resultante es única tanto para el mensaje como para la clave privada utilizada para su creación. La transformación del digesto de mensaje o hash result en la firma digital mediante la aplicación de la clave privada del firmante es descripta muchas veces como encriptado. Dicha terminología no es del todo correcta, ya que en el sistema de firma digital el mensaje no necesita ser confidencial. De hecho se transmite el mensaje original (plain text) con la firma digital (digesto de mensaje o hash result + clave privada del firmante). De esta forma la firma digital, luego de su verificación, permite que el receptor del mensaje tenga la seguridad que el mensaje proviene del que dice ser su originador y que no ha sufrido alteraciones durante su transmisión. La confidencialidad puede ser provista como un servicio adicional de las tecnologías de firma digital.
La verificación de la firma digital consiste en computar un nuevo digesto de mensaje o hash result partiendo del mensaje original (plain text), mediante la aplicación de la misma "hash function" utilizada por el originador para la creación de la firma. De allí que utilizando la clave pública del originador y el nuevo digesto de mensaje, el receptor del mensaje verifica: 1) si la firma digital fue creada utilizando la correspondiente clave privada; y 2) si el nuevo digesto de mensaje computado coincide con el digesto de mensaje original que fue transformado en firma digital durante el proceso de firma.
Distintos criptosistemas asimétricos crean y verifican firmas digitales utilizando diferentes algoritmos y procedimientos, pero comparten los principios básicos explicados.
Los procesos de creación y verificación de firmas digitales cumplen los efectos legales esenciales requeridos de una firma:
Autenticación del suscriptor: Si un par de claves pública y privada es asociada con una persona determinada, la firma digital atribuye el mensaje a dicha persona. La firma digital no puede ser adulterada, salvo que el suscriptor haya perdido el control de la clave privada.
Autenticación del mensaje: La firma digital identifica el mensaje firmado, con mayor certeza y precisión que las firmas basadas en papel. La verificación revela cualquier intento de adulteración, desde que la comparación del digesto de mensaje (uno obtenido en el proceso de firma y otro en el proceso de verificación) nos muestra si el mensaje recibido es igual al mensaje firmado.
Acto afirmativo: La creación de una firma digital requiere que el suscriptor utilice su clave privada. Este acto puede ser considerado como la función formal o ceremonial de alertar al suscriptor acerca de que está realizando una transacción con consecuencias legales.
Eficacia: El proceso de creación y verificación de una firma digital provee un alto grado de certeza acerca de que la firma digital proviene del suscriptor

martes, 24 de junio de 2008

Diferentes Niveles de Seguridad en los Archivos PDF

Hace más de quince años, Adobe Systems Incorporation introdujo en el mercado mundial el concepto del documento electrónico ubicuo, logrando posicionar un formato que ha sido adoptado como estándar “de facto” para el intercambio de documentos electrónicos; me refiero al formato PDF, por sus siglas en inglés Portable Document Format (Formato de Documento Portable), un PDF puede ser visualizado en casi cualquier computadora o dispositivo móvil utilizando un producto gratuito llamado Adobe Reader (antes conocido como Acrobat Reader). En la actualidad, PDF es un formato reconocido por la organización de estándares internacionales (ISO, International Standards Organization).
Este formato PDF es el complemento ideal para trabajar con documentos electrónicos firmados digitalmente, dado que entre otras propiedades puede proteger su contenido, puede evitar que sea modificado y mantiene todas sus propiedades independientemente de la computadora que se use para visualizarlo.

Es muy importante que todas las empresas, grandes y pequeñas, evalúen el impacto que tendrá el uso de documentos electrónicos con validez oficial y que definan una estrategia a seguir en el corto y mediano plazo.

El tener un documento electrónico o un formato electrónico trae muchas ventajas a una organización, por ejemplo, una orden de compra electrónica puede tener catálogos que ayuden a la persona que está llenándola, reduciendo los errores típicos de la captura, agregando validaciones de la información; incluso se puede tener un documento “inteligente”, capaz de mostrar y ocultar información de acuerdo como sea necesario.

Con la evolución de la tecnología hemos observado grandes cambios en la forma de operar de los negocios, en la calidad del servicio que ofrecen empresas de todos los ramos y en la creciente necesidad de tener acceso a servicios “en línea” para poder realizar trámites personales; sin embargo, con todos estos avances, hoy dependemos más que nunca de grandes cantidades de papel, con sellos y firmas que le dan autenticidad y que, en ocasiones, estamos obligados a conservar por muchos años.

Por supuesto, el gran reto para estos documentos es el garantizar su autenticidad, para lo cual se ha acuñado el concepto de “firma electrónica”, que es una analogía digital de la firma autógrafa que usamos cotidianamente. Esta firma electrónica se vale de mecanismos de cifrado de información (también llamado encripción) que garantizan la autenticidad del documento; de tal forma que se puede asegurar que el documento no ha sido alterado desde que fue firmado, además de identificar plenamente a la persona que firmó el documento.
  • Seguridad Básica.
El nivel de seguridad más básico que se puede aplicar a un archivo PDF se consigue mediante una contraseña de administrador que bloquea algunas características del archivo, por ejemplo, pedir una clave para abrir el documento, prevenir que se modifique el contenido del documento, evitar que se pueda copiar el contenido y pegarlo en otra aplicación e incluso no permitir la impresión del mismo.

Este nivel de seguridad existe en un PDF desde hace mucho tiempo y ha permitido proteger parcialmente la información, sin embargo, la contraseña reside dentro del PDF y, por lo tanto, es susceptible de ataques conocidos como “fuerza bruta”, en los cuales un programa intenta posibles combinaciones de letras y palabras hasta que se logre “adivinar” la clave.

La ventaja de este mecanismo de seguridad es que no requiere de ningún componente adicional para ser implementado y es adecuado para documentos con información pública o información de bajo nivel de sensibilidad.

Para la implementación de esta funcionalidad Adobe utiliza algoritmos de cifrado con llave simétrica como AES (128 y 256 bits) y RC4 (128 bits).
  • Seguridad por cifrado (encripción)
Mediante el uso de certificados digitales es posible tener un mayor nivel de seguridad en un documento PDF, para lo cual es necesario contar con certificados digitales con llave asimétrica, es decir, un una pareja de llaves pública y privada.

En este caso, no hay suficiente información dentro del documento PDF que permita romper la seguridad con un ataque de fuerza bruta, solamente mediante el uso de la llave pública correspondiente a la llave privada utilizada para encriptar (cifrar) el documento, se podría abrir o modificar la configuración de seguridad. Para este tipo de implementación Adobe utiliza el algoritmo RSA (512, 1024 y 2048 bits).
  • Seguridad máxima
El mayor nivel de seguridad que se puede lograr actualmente en un documento PDF está relacionado con un concepto que se utiliza en la actualidad llamado “administración digital de derechos” (DRM, Digital Rights Management), en este caso, además de poder controlar la modificación o la impresión de un documento, se puede controlar la autorización de quien puede hacer qué con un documento PDF e incluso la vigencia del mismo.

En resumen, se puede tener el control de acceso a un PDF, sin importar el lugar donde se encuentre el mismo, es decir, puede estar en un repositorio, en un disco portátil, en un disco óptico, incluso en la computadora de la casa de una persona y se sigue teniendo el control del documento.

¿Cómo se puede lograr esto?, en realidad, se utiliza un servidor (Adobe LiveCycle Policy Server) que encripta un documento cuando se le aplica una política y cada vez que alguien intenta abrirlo, se establece una conexión hacia el servidor para identificar el documento, autenticar a la persona (via una conexión con el directorio corporativo LDAP) y, en caso de que todo sea válido y la apertura este permitida, se envía una llave temporal para desencriptar y abrir el documento.

Con esta solución se puede tener incluso una historia de los eventos relacionados con el documento, por ejemplo, se puede saber quién abrió un documento, quién lo mandó a impresión, desde qué computadora lo hizo, entre otras cosas.

Este nivel de seguridad es ideal para documentos confidenciales que deben ser preservados en todo momento.
  • Conclusión
Existen diferentes niveles de seguridad que deben ir relacionados con el contenido de cada archivo PDF, en algunos casos es suficiente con la seguridad básica, en otros casos es necesario utilizar una firma electrónica o encriptar el contenido; y para la información confidencial se puede utilizar la seguridad máxima; pero siempre bajo el entendido que el documento sigue siendo un PDF y puede ser abierto en cualquier plataforma donde está disponible el Adobe Reader gratuito.

Por Luis Carselle Gerente de Cuentas Corporativas en Adobe Systems Latino América
Fuente: http://www.tynmagazine.com/notas.php?id=734

Los Ataques Internos, un gran peligro

Secure Computing Corporation, un a empresa de seguridad informática empresarial ha realizado una encuesta a 103 directores de tecnología y ha sacado unas conclusiones interesantes:
El 80% creen que tiene un gran problema con los ataques internos a la seguridad.
El 37% ha detectado fugas de información sensible en el último año.
El correo electrónico es la vía de apertura de la brecha de seguridad en la mayor parte de los casos las mayores inversiones en seguridad pasan por reforzar la seguridad interna de la empresa.
Respecto a los problemas de seguridad externos, las respuestas de la encuesta dicen lo siguiente el malware preocupa más que los hackers, los virus y el spam siguen manteniéndose como elementos degran preocupación.
Fuente: http://www.blogantivirus.com/los-ataques-internos-un-gran-peligro

jueves, 19 de junio de 2008

ISO 27005:2008: Gestión de Riesgos



Desde el día 4 de Julio se dispone de la nueva norma ISO 27005:2008,"Information security risk management".Esta norma ISO/IEC 27005:2008 proporciona directrices para la gestión de riesgos de seguridad de la información.
Esto apoya los conceptos generales especificados en ISO/IEC 27001 y ha sido diseñada para ayudar a la puesta en práctica satisfactoria del análisis y la gestión del riesgo, fase principal del diseño de todo buen sistema de gestión de la seguridad de la información (SGSI).
El conocimiento de los conceptos, modelos, procesos y terminologías descritas en ISO/IEC 27001 e ISO/IEC 27002 es importante para lograr el entendimiento completo de la ISO/IEC 27005:2008.ISO/IEC 27005:2008 es aplicable a todos los tipos de organizaciones (p.ej. sociedades mercantiles, administraciones públicas, organizaciones no lucrativas) que tengan la intención de manejar los riesgos que podrían comprometer la seguridad de la información de la organización.Esta norma actualiza a la antigua ISO 13335, partes 3 y 4.



La legislación suele pecar de ambigua a la hora de hablar de seguridad. En general se venía diciendo que los procesos telemáticos deben garantizar la disponibilidad, integridad y confidencialidad de la información, sin establecer mínimos (A excepción de la legislación en materia de protección de datos de carácter personal que lo regula vía reglamentaria).
Como mucho aparece que las medidas de seguridad serán proporcionales a los "riesgos y el estado de la tecnología".
Adopción de las medidas de seguridad, organizativas o técnicas, de los dispositivos y aplicaciones de registro, notificación y de la prestación del servicio de dirección electrónica única.
1. Con carácter general se aplicarán a los dispositivos y aplicaciones de registro, notificación y de la prestación del servicio de dirección electrónica única las medidas de seguridad, conservación y normalización que se detallan en los Criterios de seguridad, normalización y conservación de las aplicaciones utilizadas para el ejercicio de potestades aprobados por el Consejo Superior de Informática y para el impulso de la Administración Electrónica y accesibles en su sitio web.
Dichas medidas de seguridad, conservación y normalización vendrán determinadas por el resultado del análisis y gestión de riesgos que se realice, recomendándose a estos efectos la utilización de la metodología Magerit.
2. Lo dispuesto en esta Orden Ministerial se aplicará en todo caso de conformidad con lo previsto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal y demás normativa aplicable en esta materia.
Lo significativo que merece ser destacado es la exigencia de la realización de un análisis y gestión de riesgos previo a determinar las medidas de seguridad necesarias y además, establecido mediante una Orden Ministerial.
Me inicié en esto de la seguridad de la información ya hace casi 10 años justo en un proyecto piloto de valoración de la metodología MAGERIT (En aquella época, versión 1.0) y aunque siempre he considerado, pese a detractores, que el análisis y gestión de los riesgos es el criterio de diseño del conjunto de medidas, el reconocimiento que realiza esta nueva redacción de los requisitos de seguridad va a forzar a las instituciones a pasar forzosamente por el proceso.
Se discute mucho sobre la rigurosidad de esta disciplina, basada en estimaciones y valoraciones subjetivas pero lo importante al final es que obliga a determinar qué elementos son importantes, cual es su valor y qué podría pasarles respecto a potenciales incidentes de seguridad.
Este mínimo ejercicio de reflexión es necesario para que la seguridad no se base en la percepción del riesgo. Debe ocurrir que la sensación de seguridad sea igual que la seguridad real de la que se dispone.
En cuanto a la metodología MAGERIT 2.0, no creo que se diferencie en su esencia de lo contenido en esta norma ISO 27005:2008 porque básicamente todo análisis y gestión de riesgos pasa por las siguientes fases:
Fase de análisis de riesgos:

Determinación de activos
Determinación de amenazas
Estimación de impactos
Estimación de vulnerabilidad de las amenazas sobre los activos

Cálculo del nivel de riesgo.

Fase de gestión de riesgos:
Determinación de los criterios de aceptación del riesgo
Determinación de las medidas de seguridad necesarias
Estimación del nivel de riesgo residual

La documentación de MAGERIT 2.0 puede obtenerse en el Consejo Superior de Informática en la siguiente ficha descriptiva y en la propia página del Centro Nacional de Inteligencia en la urlhttp://www.ccn.cni.es/series.html hay un documento titulado CCN-STIC-410 Análisis de Riesgos Sistemas de la Administración v1.0.pdf con un ejemplo de su aplicación.
Fuente: http://seguridad-de-la-informacion.blogspot.com/2008/06/publicada-la-iso-270052008.html

miércoles, 18 de junio de 2008

Problema Grave de SSL

Debian fallo seguridad SSL.

Hoy he recibido por correo de Hispasec esta estupenda descripción del fallo de seguridad SSL que se ha descubierto en Debian recientemente.

Copio y pego.Hispasec - una-al-día 16/05/2008.

El problema encontrado en OpenSSL de Debian puede ser considerado, lamentablemente, un verdadero acontecimiento criptográfico. La criptografía es una ciencia compleja, y con el ánimo de aclarar las graves y extensas consecuencias del fallo, hemos redactado una serie de preguntas frecuentas para intentar, aun tratándose de un tema tan complejo, arrojar algo de luz. ¿Qué ha pasado exactamente? Alguien (por error) del equipo de Debian eliminó una línea de código en el paquete OpenSSL de Debian que ayudaba a generar la entropía al calcular el par de claves pública y privada. Las claves sólo se calculaban tomando como semilla el PID del proceso. Al estar limitado a 32.768 semillas (tantos como PIDs de proceso son posibles) para la generación de números seudoaleatorios, el número de claves posibles es pequeño. Se han estado generando las mismas claves dentro de este número limitado de posibilidades desde septiembre de 2006. Como son pocas y de entropía pobre, se puede deducir la clave privada a partir de la pública porque el espacio de primos es muy pequeño y está precalculado. Ya se han generado listas disponibles para todos con la clave pública (del espacio a que han quedado limitado después del fallo) y su correspondiente privada. Para los usuarios de este OpenSSL de Debian sin entropía suficiente, se han roto las reglas de la criptografía asimétrica en la que por ahora confiamos todos y que sustentan las bases de la (poca) seguridad y confianza que pueda existir en Internet. ¿Es tan grave como parece? Es más grave. Mucho más grave. Podríamos considerar que la criptografía de Debian en los últimos dos años ha sido una pantomima. Y es grave además porque no se resuelve por completo parcheando. Esa no es la solución definitiva. Hay que regenerar claves, revocar las antiguas, certificarlas en el caso de SSL, comprobar dónde fueron a parar claves generadas con Debian... No es un bug en un programa que eventualmente quedará obsoleto porque todo el mundo estará parcheado. Habrá administradores que no comprueben la debilidad sus claves, servidores SSL que jamás certifiquen de nuevo sus claves, claves perdidas de usuarios que dejen la puerta abierta a servidores SSH... También es grave porque arrastra a decenas de programas y sistemas que se valen de claves generadas con OpenSSL. SSL, SSH, OpenVPN, DNSSEC... Alguien lo ha calificado de "apocalipsis criptográfico". Además los principales perjudicados son los servidores que precisamente hayan buscado más seguridad con la criptografía de clave pública, porque contenían información crítica. El SANS Internet Storm Center ha elevado el nivel de alerta general a 'amarillo'. No ocurre a menudo. ¿Cómo ha podido ocurrir? Ha sido todo un desafortunado error. Aunque surgirán las teorías conspiratorias porque el código abierto ha estado ahí durante dos años, no ha sido hasta que Luciano Bello se ha dado cuenta que se ha corregido el fallo y se ha dado la voz de alarma. Pero el daño ya está hecho. Dos años de claves débiles generándose en cientos de miles de sistemas. Ha pasado desapercibido porque en general cualquier programa es complejo, pero la criptografía lo es aún más. Además, Bruce Schneier dijo algo así como 'Good security looks the same as bad security' ('La buena seguridad se ve igual que la mala', frase aplicable aún más a la criptografía). Kurt Roeckx fue quien planteó en un principio borrar líneas que consideraba problemáticas. Existe un correo de 2006 en una lista pública, en el que Roeckx plantea en una lista de OpenSSL qué pasaría si las eliminara. Pregunta si resultaría en una posible pérdida de aleatoriedad. La respuesta no oficial desde OpenSSL es que "no mucho" y que es partidario de borrarlas si ayuda en la depuración. Y era cierto, esas líneas no suponían problema: el problema es que en Debian se borraron más líneas de la cuenta, de las habladas en la conversación y para colmo los cambios no se enviaron a OpenSSL para que fueran revisados.
¿Se soluciona parcheando? No. No se trata de un fallo de seguridad al uso. Ha existido una fuente de claves inseguras que se han esparcido durante dos años. Hay que comprobar y regenerar claves. El fallo fue anunciado a la vez que el parche, pero hay que tener en cuenta, que las primeras versiones de los parches para Debian y Ubuntu contenían regresiones. Han publicado nuevas actualizaciones para los propios parches que es necesario aplicar también.
¿Qué pasa si tengo un servidor web con acceso por HTTPS? Si las claves han sido generadas con la versión de OpenSSL con el problema, las consecuencias son que alguien se puede hacer pasar por el servidor porque tendrá la privada de forma instantánea a partir de la pública. Además, cualquiera que haya tenido acceso a una conversación cifrada con el servidor, podría también descifrarla. Esto es así porque la clave simétrica que se utiliza para el cifrado ha sido intercambiada con la ayuda de claves asimétricas débiles. Un administrador debe además revocar la clave, generar una nueva, enviarla a la Autoridad Certificadora (que cobra por certificar) e instalarla. La catástrofe hubiese sito total, si una Autoridad Certficadora, hubiese generado claves y firmado certificados con estas claves débiles, pues el problema se extendería hacia abajo a todos sus clientes, en cuyos certificados ya no se podría confiar. Al parecer han comprobado que las principales Autoridades no se ven afectadas.
¿Qué pasa con SSH? Los administradores que controlan sus sistemas a través de SSH se suelen autenticar a través de su clave privada y el servidor de SSH almacena la pública correspondiente. Esto es más seguro que usar una sola contraseña simétrica para autenticarse. El servidor cifra una cadena con la clave pública del que pretende autenticarse y se la envía, si puede descifrarla le deja pasar. En este caso puede que la clave pública sea realmente pública o no. En el primer caso, deducir la privada es instantáneo, y en el segundo caso, si no se conoce la pública, se debe hacer un ataque de fuerza bruta sobre un espacio de claves muy pequeño, algo que tarda unos 20 minutos con un ordenador de hoy día. Se ha creado un exploit para esto.Todos los administradores que permitan a sus usuarios utilizar la clave privada para acceder a sus sistemas a través de SSH, deben auditar las claves para saber si son de las "débiles". Los administradores de SSH también se encuentran ante una tarea concienzuda, peligrosa, (y que deben emprender ya) incluso si no utilizan Debian, porque puede que sus claves hayan sido generadas en una distribución Debian y exportadas. Los administradores de SSH comprobarán, con total seguridad, como los intentos de acceso ilegítimo se multiplican en estos días.
¿A Windows le pasó lo mismo? No. Se demostró que el generador de números aleatorios de Windows era débil, pero la diferencia es que según el estudio, había que conocer el estado previo del generador para saber el siguiente cálculo. Esto podría permitir descifrar conversaciones SSL entre dos sistemas. Pero para poder llegar a tener acceso a esa información inicial de la que se deducirían el resto de "estados del algoritmo", un atacante necesitaría poder tener acceso como administrador en el sistema. Digamos que para poder aprovechar el problema del algoritmo y poder descifrar la información, necesitaría tener el total control de la máquina para llegar a conocer un estado, con lo que el sistema ya estaría comprometido en sí.
Conclusiones
Lo peor no está ocurriendo ahora. Lo verdaderamente grave ha podido ocurrir antes (en los últimos dos años si alguien ha conocido este error y lo hubiese mantenido en secreto) y después (lo que nos espera a medida que se vaya descubriendo que sistemas importantes ha generado claves débiles).
Random number generator, uninitialised data and valgrind http://marc.info/?l=openssl-dev&m=114651085826293&w=2
Debian and Ubuntu users: fix your keys/certificates NOW http://isc.sans.org/diary.html?storyid=4420