Errores del código criptográfico

Question

Estoy modificando el código de seguridad existente. Las especificaciones son bastante claras, hay un código de ejemplo, pero no soy un experto en criptografía. De hecho, el código de ejemplo tiene un descargo de responsabilidad que dice, en efecto, & Quot; No use este código literalmente. & Quot;

Al auditar el código que voy a modificar (que supuestamente está completo), me encontré con esta pequeña joya que se utiliza para generar el desafío:

static uint16 randomSeed;

...

uint16 GetRandomValue(void)
{
  return randomSeed++;/* This is not a good example of very random generation :o) */
}

Por supuesto, lo primero que hice inmediatamente fue pasarlo por la oficina para que todos pudiéramos reírnos.

El programador que produjo este código sabía que no era un buen algoritmo (como lo indica el comentario), pero no creo que entendieran las implicaciones de seguridad. Ni siquiera se molestaron en llamarlo en el bucle principal, por lo que al menos se convertiría en un contador de funcionamiento libre, todavía no es ideal, pero hay mundos más allá de esto.

Sin embargo, sé que el código que produzco hará que un verdadero gurú de la seguridad se ría o temblara de manera similar.

• ¿Cuáles son los problemas de seguridad más comunes, específicos de la criptografía, que necesito entender?
• ¿Cuáles son algunos buenos recursos que me darán un conocimiento adecuado sobre lo que debo saber más allá de los errores comunes?

-Adam

Answer 1

Criptografía aplicada es un excelente libro para ayudarlo a comprender el cifrado y el código. Repasa muchos aspectos fundamentales, como cómo funcionan los cifrados de bloque y por qué elegir un modo de cifrado deficiente hará que su código sea inútil incluso si está utilizando una versión perfectamente implementada de AES.

Algunas cosas a tener en cuenta:

• Pobres fuentes de aleatoriedad
• Intenta diseñar tu propio algoritmo o protocolo, no lo hagas nunca.
• No se revisa el código. Preferiblemente publicándolo en línea.
• No usar una biblioteca bien establecida e intentar escribirla usted mismo.
• Crypto como panacea: el cifrado de datos no lo hace mágicamente seguro
• Gestión de claves. En estos días, a menudo es más fácil robar la clave con un ataque de canal lateral que atacar la criptografía.

Answer 2

No intentes rodar la tuya: usa una biblioteca estándar si es posible. Los cambios sutiles en el código de seguridad pueden tener un gran impacto que no son fáciles de detectar, pero pueden abrir agujeros de seguridad. Por ejemplo, dos líneas modificadas a una biblioteca abrieron un agujero que no era t evidente desde hace bastante tiempo.

Answer 3

Su pregunta muestra una de las más comunes: pobres fuentes de aleatoriedad. No importa si usa una clave de 256 bits si estos bits no son lo suficientemente aleatorios.

El número 2 probablemente asume que puedes diseñar un sistema mejor que los expertos. Esta es un área donde una implementación de calidad de un estándar seguramente será mejor que la innovación. Recuerde, tomó 3 versiones principales antes de que SSL fuera realmente seguro. Nosotros pensamos.

Answer 4

En mi humilde opinión, hay cuatro niveles de ataques que debe tener en cuenta:

1. ataques de ingeniería social. Debe capacitar a sus usuarios para que no hagan cosas estúpidas y escribir su software de modo que sea difícil para los usuarios hacer cosas estúpidas. No conozco ninguna buena referencia sobre estas cosas.

2. no ejecute código arbitrario (desbordamientos de búfer, exploits xss, inyección sql, todos están agrupados aquí). Lo mínimo para aprender sobre esto es leer Escribir código seguro de alguien en MS y ver la charla de tecnología de Google Cómo romper el software web. Esto también debería enseñarle un poco sobre la defensa en profundidad.

3. ataques lógicos. Si su código está manipulando texto plano, certificados, firmas, textos cifrados, claves públicas o cualquier otro objeto criptográfico, debe tener en cuenta que manejarlos de manera incorrecta puede conducir a cosas malas. Entre las cosas mínimas que debe tener en cuenta se incluyen el amplificador fuera de línea &; Los ataques de diccionario en línea, los ataques de repetición, los ataques de hombre en el medio. El punto de partida para aprender sobre esto y generalmente una muy buena referencia para usted es http://www.soe.ucsc.edu/~abadi/Papers/gep-ieee.ps

4. ataques criptográficos. Las vulnerabilidades criptográficas incluyen:

   • cosas que puede evitar: mala generación de números aleatorios, uso de una función hash rota, implementación rota de la primitiva de seguridad (por ejemplo, el ingeniero olvida un -1 en algún lugar del código, lo que hace que la función de cifrado sea reversible)
   • cosas que no puede evitar, excepto estar tan actualizado como sea posible: nuevo ataque contra una función hash o una función de cifrado (ver, por ejemplo, reciente MD5 talk), nueva técnica de ataque (ver, por ejemplo, ataques recientes contra protocolos que envían cifrado voz sobre la red)

Una buena referencia en general debería ser la Criptografía Aplicada.

Además, es muy preocupante para mí que las cosas que van en un dispositivo móvil que probablemente estén bloqueadas y sean difíciles de actualizar están escritas por alguien que pregunta sobre seguridad en stackoverflow. Creo que su caso sería uno de los pocos casos en los que necesita un consultor externo (bueno) que lo ayude a obtener los detalles correctos. Incluso si contrata a un consultor de seguridad, lo que le recomiendo que haga, lea también las referencias (minimalistas) anteriores.

Answer 5

  

¿Cuáles son los problemas de seguridad más comunes, específicos de la criptografía, que necesito entender?

Fácil: usted (1) no es lo suficientemente inteligente como para crear su propio algoritmo.

(1) Y por usted, me refiero a usted, a mí y a todos los que leen este sitio ... excepto posiblemente Alan Kay y Jon Skeet .

Answer 6

Tampoco soy un tipo de criptografía, pero los S-boxes pueden ser problemáticos cuando se meten con ellos (y hacen la diferencia). También necesita una fuente real de entropía, no solo un PRNG (no importa cuán aleatorio se vea). Los PRNG son inútiles. A continuación, debe asegurarse de que la fuente de entropía no sea determinista y que no pueda ser manipulada.

Mi humilde consejo es: quédate con algoritmos criptográficos conocidos, a menos que seas un experto y entiendas los riesgos. Podría estar mejor usando un código de dominio público / de código abierto probado y disponible públicamente.