¿Cómo definir los requisitos de seguridad para garantizar que los desarrolladores ... no brinden seguridad por oscuridad?

10

Traté de explicar que la seguridad por oscuridad no debe usarse, ¡pero digamos que fui desafiado!

Recibí la respuesta para enumerar la seguridad conocida por la oscuridad que conozco, como una especie de mala práctica y que no se debe seguir. De hecho, es bastante difícil definir Seguridad por Oscuridad, pero no estoy convencido de que enumerar una mala práctica sea la forma correcta tampoco.

Por lo tanto mis preguntas:

  • ¿Alguien tiene una lista de soluciones de seguridad por oscuridad que puedo enumerar?
  • ¿No sería mejor definir los requisitos que detienen la seguridad por oscuridad? ¿Pero cómo definir esos requisitos? Me preguntaba si alguien sabría cuáles serían los requisitos correctos de configuración para no permitir la seguridad por oscuridad
pregunta Phoenician-Eagle 12.01.2011 - 15:40
fuente

4 respuestas

8

Un ejemplo es el sistema de codificación de contenido para evitar que se copien los DVD. Si bien el sistema de aleatorización era desconocido, esto funcionó. Luego, un adolescente llamado Jon Lech Johansen lo descubrió, escribió DeCSS y se rompió.

Como señala @GrahamLee, los mecanismos de seguridad en los que se debe confiar deben seguir funcionando, incluso cuando los malhechores los conocen.

En estos días, la criptografía proporciona seguridad en tantas aplicaciones, por lo que es fundamental que se implemente correctamente. Debido a que las matemáticas están más allá de la mayoría de las personas, hay una escuela de pensamiento que aboga por la publicación de algoritmos y permite que las personas de todo el mundo traten de encontrar fallas. El alza - muchos ojos. El inconveniente: si el algoritmo ya está implementado, un atacante puede encontrar una falla y ser capaz de usarlo, por lo que hacerlo antes de la implementación es muy útil.

El otro punto de vista es ocultar el algoritmo para evitar que los atacantes sepan cómo funciona. El problema con la oscuridad es que se ha demostrado una y otra vez que la confianza en la seguridad y la oscuridad falla porque en algún momento los malos descubren el secreto. .

Vale la pena leer este post de Bruce Schneier: un conocido oponente de la seguridad a través de Darkness, y el autor de varios algoritmos de cifrado que han sido probados por la comunidad, como un ejemplo de dónde ha funcionado la oscuridad, pero solo porque los delincuentes no se enteraron del plan.

No sé si es posible responder realmente la última parte de su pregunta sin más contexto. Por ejemplo, si esto es para el código desarrollado por terceros, podría solicitar una revisión del código, pero lo que realmente podría buscar es un tercero que publique sus algoritmos / código, etc. como fuente abierta.

    
respondido por el Rory Alsop 12.01.2011 - 16:10
fuente
7

El contraejemplo canónico de la seguridad a través de la oscuridad es el Principio de Kirchkoffs: los diseñadores de criptografía deben asumir que el sistema capturará el sistema criptográfico, por lo que aún debería ser seguro si todo lo demás, excepto la clave es conocido.

Sin embargo, tenga en cuenta que esto no dice que la oscuridad sea mala y que no se debe confiar en ella: dice que la oscuridad no puede ser la única defensa . Eso es porque es frágil. Pero la oscuridad todavía puede ralentizar o disuadir a los atacantes no calificados.

    
respondido por el user185 12.01.2011 - 15:58
fuente
5

La oscuridad es lo que no se puede cuantificar.

La seguridad adecuada viene con estimaciones de costos. Decimos que una clave de cifrado de 128 bits es segura porque podemos estimar cuánto costaría (en procesadores dedicados y energía eléctrica, y en última instancia en dólares) encontrar la clave mediante una búsqueda exhaustiva (probando todas las claves de 128 bits posibles). Cuando el costo es mucho más alto de lo que un atacante estaría dispuesto a gastar y, en particular, cuando es mucho más alto que lo que cualquier atacante con tecnología terrestre podría gastar, entonces hemos alcanzado la seguridad.

Cuando tal estimación no es posible, entonces es seguridad por oscuridad. Por ejemplo, suponga que tiene algún tipo de sistema de cifrado en un software que mantiene en secreto. ¿Cuánto secreto es ese software? Está escrito en algunos discos duros. Se ha desarrollado en algún lugar, el código fuente para él existe, se almacena en algún lugar ¿Qué tan difícil es para un atacante recuperar el algoritmo? Los archivos almacenados se filtran en muchos lugares, por ejemplo, computadoras viejas desechadas, computadoras portátiles robadas, indiscreciones de subcontratistas (el código fuente del software está en archivos, pero también en el cerebro de algunos programadores) ... si el atacante puede obtener el binario, puede desmontarlo, un proceso que es No es inmediato sino limitado solo por el ingenio del atacante.

El punto de todo esto es que, al tiempo que hace que un código sea secreto, hace que la tarea sea más difícil para el atacante, es muy difícil decir cuánto se vuelve más difícil cuando se quiere expresar. dólares.

Así que aquí está mi respuesta a su pregunta: para evitar que los implementadores utilicen la seguridad por oscuridad, el mandato es que produzcan estimaciones de costos justificadas detalladas para los ataques.

    
respondido por el Thomas Pornin 12.01.2011 - 16:37
fuente
1

Si estás tratando de construir pautas de codificación seguras para los desarrolladores internos, esa rueda ya se ha inventado. OWASP , por ejemplo, tiene una visión general amplia que incluye acciones contra la confianza en la seguridad a través de la oscuridad. y CERT tiene estándares altamente detallados para C y C ++.

    
respondido por el user502 12.01.2011 - 16:37
fuente

Lea otras preguntas en las etiquetas