kudelskisecurity/cdfHerramienta automatizada de fuzzing diferencial para software criptográfico que detecta errores de implementación, fallos de cumplimiento y filtraciones por canales laterales mediante pruebas inteligentes y paralelizadas en múltiples lenguajes y plataformas.
CDF es una herramienta para probar automáticamente la corrección y seguridad del software criptográfico. CDF puede detectar errores de implementación, fallos de cumplimiento, fugas de canales laterales, etc.
CDF implementa una combinación de pruebas unitarias con 'fuzzing diferencial', un enfoque que compara el comportamiento de diferentes implementaciones de las mismas primitivas cuando se les proporcionan casos extremos y valores que maximizan la cobertura de código.
A diferencia de los fuzzers y software de pruebas de propósito general, CDF es:
Inteligente: CDF sabe qué tipo de algoritmo está probando y se adapta a las funciones probadas
Rápido: CDF solo prueba lo que necesita ser probado y paraleliza sus pruebas tanto como sea posible
Polivalente: CDF no es específico de ningún lenguaje o API, sino que admite programas ejecutables o scripts arbitrarios
Portátil: CDF se ejecutará en cualquier plataforma Unix o Windows, ya que está escrito en Go sin ninguna dependencia específica de la plataforma
El propósito de CDF es proporcionar una herramienta de pruebas más eficiente a desarrolladores e investigadores de seguridad, siendo más efectivo que los vectores de prueba y más barato que la auditoría manual de verificación formal.
CDF se presentó por primera vez en Black Hat USA 2017. Puede ver las diapositivas de nuestra presentación, que contienen información general sobre la lógica detrás y el diseño de CDF.
CDF está codificado en Go, la versión actual se ha desarrollado usando Go 1.8. No tiene dependencias fuera de la de Go.
Sin embargo, proporcionamos programas de ejemplo para probar con CDF, los cuales están en C, Python, C++, Java y Go y requieren bibliotecas criptográficas específicas para ejecutarse. Actualmente las bibliotecas requeridas son:
make compilará el binario cdf.
Hay varios programas de ejemplo disponibles en example: make examples-all compilará todos los ejemplos, mientras que make examples-go solo compilará los ejemplos de Go.
make test ejecutará las pruebas unitarias (de CDF).
Para empezar, quizás desee ver la información de uso ejecutando cdf -h.
Luego puede probar un ejemplo como la interfaz rsaenc contra los ejemplos RSA OAEP Go y CryptoPP. Considerando CryptoPP como nuestra referencia, puede probar la implementación Go haciendo:
cdf rsaenc /examples/oaep_rsa2048_go /examples/oaep_rsa2048_cryptopp
Este comando realizará varias pruebas específicas de la interfaz rsaenc.
En este ejemplo, CDF debería quejarse del tamaño máximo del exponente público que soporta la implementación Go: si revisamos su código podemos ver que el exponente público se almacena como un entero normal, mientras que en CryptoPP (y la mayoría de las otras implementaciones), se almacena como un entero grande. Sin embargo, esto es por diseño y probablemente no se cambiará.
Los parámetros se definen en config.json. La mayoría de los parámetros se explican por sí mismos. Es posible que desee establecer otras claves privadas para rsaenc y ecdsa (estas interfaces se prueban con claves fijas, aunque algunos parámetros de clave, como los exponentes, se cambian en algunas de las pruebas).
El parámetro seed le permite cambiar la semilla utilizada en los generadores pseudoaleatorios de CDF. (Sin embargo, el programa probado puede estar usando algún PRNG con otra semilla, como los ejemplos OAEP.) El parámetro concurrency le permite establecer el número de goroutines concurrentes que CDF debe generar al bifurcar los programas. Tenga en cuenta que es mejor mantener este número por debajo del número real de núcleos. El parámetro verboseLog, si se establece en true, escribirá todas las entradas y salidas de los programas, incluso para las pruebas exitosas, en un archivo log.txt.
Para probar su software usando CDF, debe crear un programa que lea la entrada y escriba la salida de acuerdo con las interfaces de CDF, y que internamente llame al programa probado. Las interfaces de CDF son abstracciones de una funcionalidad criptográfica, para permitir pruebas de caja negra de implementaciones arbitrarias.
Por ejemplo, si implementó el esquema de firma ECDSA, su programa debe satisfacer la interfaz ecdsa y, como tal, aceptar como entradas 4 o 5 argumentos, respectivamente para firmar un mensaje o verificar una firma. Estos argumentos son la coordenada X pública, la coordenada Y pública, el entero grande D privado y el mensaje que desea firmar, y luego debe generar solo los enteros grandes R y S, cada uno en una nueva línea. O, para verificar un mensaje, debe aceptar X, Y, R, S y el mensaje, y luego debe generar solo Verdadero o Falso. Las especificaciones de las interfaces se detallan a continuación.
Nuestros ejemplos de implementaciones de interfaz le ayudarán a crear las suyas propias.
El manejo de errores queda a cargo del programa probado; sin embargo, para tener errores significativos en CDF, es mejor salir en caso de fallo, devolver un código de error e imprimir un mensaje de error.
El programa de interfaz puede estar escrito en cualquier lenguaje, solo necesita ser un archivo ejecutable conforme a una interfaz de CDF. Un programa de interfaz típicamente está escrito en el mismo lenguaje que el programa probado, pero no es obligatorio (puede ser un envoltorio en otro lenguaje, por ejemplo para programas en Java).
CDF actualmente soporta las siguientes interfaces, en las cuales los parámetros se codifican como cadenas ASCII hexadecimales, a menos que se describa lo contrario:
La interfaz dsa prueba implementaciones del Algoritmo de Firma Digital (DSA). Debe soportar las operaciones de firma y verificación:
| Operation | Input | Output |
|---|---|---|
| Firma | p q g y x m | r s |
| Verificación | p q g y r s m | truth value |
Aquí p, q, g son parámetros DSA, y es una clave pública, x es una clave privada, m es un mensaje, r y s forman la firma, que debe devolverse separada por una nueva línea. El valor de verdad, ya sea “true” o “false”, se representa como una cadena.
La interfaz dsa soporta una prueba opcional: la -h permite omitir el proceso de hash y proporcionar directamente el valor hash a firmar. Esto permite a CDF realizar más pruebas, como verificar desbordamientos o truncamiento de hash.
La interfaz ecdsa prueba implementaciones del Algoritmo de Firma Digital de Curva Elíptica (ECDSA). Debe soportar las operaciones de firma y verificación:
| Operation | Input | Output |
|---|---|---|
| Firma | x y d m | r s |
| Verificación | x y r s m | truth value |
Aquí x e y son las coordenadas de una clave pública ECDSA, d es una clave privada, m es un mensaje, y r y s forman la firma, que debe devolverse separada por una nueva línea. El valor de verdad, ya sea “true” o “false”, se representa mediante una cadena.
La bandera -h tiene el mismo propósito que con dsa.
Tenga en cuenta que nuestro diseño actual asume una curva fija, definida en el programa probado.
Para obtener resultados reproducibles con esas pruebas y aprovechar todas las capacidades de detección de CDF, debe sembrar su generador aleatorio con una semilla fija o usar una variante ECDSA determinista, de lo contrario CDF no puede detectar problemas como problemas de etiquetas iguales automáticamente.
La interfaz enc prueba operaciones de cifrado y descifrado simétrico, típicamente cuando se realizan con un cifrado de bloque (los cifrados de flujo se pueden probar con la interfaz prf). Debe soportar cifrado y descifrado:
| Operation | Input | Output |
|---|---|---|
| Cifrado | k m | c |
| Descifrado | k c | r |
Aquí k es una clave, m es un mensaje, c es un texto cifrado c y r es un texto plano recuperado.
La interfaz prf prueba hashing claveado (funciones pseudoaleatorias, MACs), así como cifrados de flujo:
| Operation | Input | Output |
|---|---|---|
| Cómputo | k m | h |
Aquí k es una clave, m es un mensaje (o nonce en caso de un cifrado de flujo), y h es el resultado del cómputo PRF. Nuestra interfaz asume un tamaño de clave fijo y longitudes de entrada variables. Si se debe especificar una clave específica, es responsabilidad del programa probado ignorar la entrada de clave o la interfaz xof puede ser una mejor opción.
| Operation | Input | Output |
|---|---|---|
| Cifrado | n e m | c |
| Descifrado | p q e d c | r |
Aquí n es un módulo, e es un exponente público (para compatibilidad con ciertas bibliotecas, e también se necesita para el descifrado), m es un mensaje m, p y q son factores de n (tales que p > q, ya que las bibliotecas comúnmente lo requieren), d es un exponente privado, y r es un texto plano recuperado.
La interfaz xof prueba funciones hash, funciones de salida extensible (XOFs), generadores deterministas de bits aleatorios (DRBGs):
| Operation | Input | Output |
|---|---|---|
| Cómputo | m | h |
Aquí m es el mensaje y h es el resultado h.
CDF se basa en ideas iniciales de JP Aumasson, divulgado por primera vez en WarCon 2016, y la mayor parte del código fue escrito por Yolan Romailler.
CDF tiene derechos de autor (c) 2016-2017 Nagravision SA, todos los derechos reservados.
CDF se publica bajo GPLv3.