Recientemente hay un poco de preocupación sobre las puertas traseras de cifrado en IPsec y Si bien el estado de esto no se ha confirmado, no sé qué impacto podría tener algo como este podría .
Por ejemplo, ¿esto significa que, dado que el cifrado en esta capa puede verse comprometido, tenemos vulnerabilidades en varias plataformas de tecnología de Internet (por ejemplo, SSL)?
¿Qué permite una puerta trasera de trabajo aquí en términos de los ataques de Eve y Mallory?
Creo que los mayores impactos estarán en el lado de las relaciones públicas.
En el lado positivo (desde el punto de vista de los mantenedores de OpenBSD), la idea de que el FBI consideraba a OpenBSD lo suficientemente importante, en el año 2000, para justificar la inserción de puertas traseras respaldadas con dinero, es un inflador seguro del ego. Esto solo podría ser un motivo para las denuncias públicas de puertas traseras, existan o no. Además, la revelación aparente inmediata y completa es un buen trabajo de relaciones públicas.
En el lado negativo, la comunicación con OpenBSD ha sido durante mucho tiempo acerca de cuán más seguro era OpenBSD que cualquier otro sistema, gracias a la auditoría de seguridad proactiva y numerosas revisiones internas de códigos. Encontrar una puerta trasera de diez años en medio de un código de red criptográfico desinflaría un poco el mito.
Ahora, en el lado técnico ...
Hay muchas formas en que una alteración sutil del código podría constituir una "puerta trasera". Si yo mismo implementara una puerta trasera, intentaría manipular el generador de números pseudoaleatorios. Es relativamente fácil hacer que un PRNG parezca que produce resultados de calidad criptográfica, pero con, en realidad, baja entropía interna (por ejemplo, 40 bits). Esto haría que las comunicaciones protegidas por IPsec sean vulnerables al descifrado con un hardware común y un atacante solo pasivo (por lo tanto, indetectable). Además, un PRNG defectuoso puede atribuirse a la incompetencia (porque hacer un PRNG malo es fácil, pero no lo es hacer un buen), abriendo el camino a negación plausible .
Otro método de backdooring es la fuga de datos. Por ejemplo, siempre que tenga algunos bits aleatorios en algún paquete de red, puede hacer que estos bits contengan datos sobre el estado interno del sistema. Por lo tanto, una buena puerta trasera puede filtrar claves secretas de encriptación, para que las recoja alguien que tenga conocimiento de la existencia de la fuga.
Los posibles desbordamientos de búferes son burdos de puertas traseras, ya que solo pueden ser explotados por atacantes activos, lo que es riesgoso. Las agencias de espionaje suelen aborrecer los riesgos. Si tales errores se encuentran en el código de OpenBSD, creo que es seguro afirmar que son errores "verdaderos", no agujeros maliciosos.
Como señalé en el comentario, esta es una pregunta muy amplia. Hay una gran variedad de ramificaciones potenciales. Sin embargo, una cosa está clara: Theo acaba de obtener un montón de revisiones de código gratuitas ;-).
Tal vez el FBI logró conseguir una puerta trasera en el código IPSec openbsd de la era 2001. Si lo hicieron, significa que ha habido redes privadas virtuales (VPN, por sus siglas en inglés) que la policía de EE. UU. Podría investigar. Ahora, si lo hicieron depende de si alguien implementó la VPN en su configuración de búsqueda, si el FBI detectó esa implementación y si les importó.
Tal vez la puerta trasera todavía está allí. Todo lo que esto significa es que puede aumentar el recuento de instalaciones en riesgo. Especialmente si algún otro sistema operativo tomó su código IPSec de OpenBSD ... FreeBSD, Mac OS X e iOS, todos lo hicieron.
Ahora, independientemente de que la historia sea cierta o no, es interesante observar que nadie, incluido el líder del proyecto OpenBSD, puede negarlo rápidamente. Esto, junto con las puertas traseras de Linux que han existido a lo largo del tiempo, me lleva a cuestionar la Ley de Torvalds: muchos ojos hacen que los insectos se vuelvan superficiales. Al parecer, también es posible ocultar vulnerabilidades a simple vista.
La respuesta a su pregunta es fácil: si alguien ocultara un código desagradable en subsistemas privilegiados, las personas equivocadas podrían tener un control arbitrario sobre los sistemas que ejecutan el código.
Pero tenga en cuenta que no se han presentado pruebas (y Perry debería tener mucho de eso), y no se disculpa.
Para más información vea
y los comentarios cómicos y conspirativos sobre las respuestas de los acusados: enlace enlace
Esto realmente no responde a su pregunta, pero el código de alrededor de 2001 pudo haber tenido cambios importantes en la última década, por lo que es difícil decir si el código seguirá existiendo de todos modos (si existiera en primer lugar) .
Un poco más cerca de una respuesta útil: Graham tiene una lista de unos pocos. La siguiente pregunta es ¿cuándo empezaron a consumir ese código? ¿Antes o después de la introducción de la puerta trasera potencial? Si después, ¿hubo una revisión del código por parte de la empresa? Si es así, ¿lo encontraron? Si es así, ¿lo arreglaron? Si es así, ¿lo fusionaron de nuevo con el proyecto original?
La mejor evidencia, según lo leí, es que las acusaciones de una puerta trasera en OpenBSD son mucho aire caliente. A mí me parece una mancha burlona e injustificada de OpenBSD, en un intento de propagar FUD (miedo, incertidumbre y duda).
En mi opinión, las alegaciones de Gregory Perry tienen poca credibilidad en este momento. Enumeraré algunas de las pruebas en contra de sus alegatos:
Creo que es posible que NETSEC llevó a cabo estudios internos para ver cómo modificar OpenBSD para agregue una puerta trasera para su propio uso interno , pero no hay razón para creer que alguna puerta trasera se haya introducido alguna vez en la distribución oficial de OpenBSD.
En pocas palabras: considero que la carta de Perry, que usted citó, es una prueba infundada contra OpenBSD. OpenBSD ha sido muy respetado por su dedicación a la seguridad. Le sugiero que trate de evitar la redistribución de las acusaciones de Perry.
Revelación completa: no tengo ninguna asociación con OpenBSD ni con ninguna de las partes en este pequeño intercambio. No tengo intereses financieros en este asunto. Heck, ni siquiera ejecuto OpenBSD en mis servidores. Solo odio ver un buen producto sujeto a acusaciones sin fundamento.
Lea otras preguntas en las etiquetas operating-systems cryptography exploit ipsec openbsd