La criptografía rara vez falla porque un algoritmo esté roto. Falla en los detalles que lo rodean: un nonce que se repite, un generador aleatorio inicializado con la hora, una firma que se verifica pero no está vinculada a su contexto, una clave que se deriva correctamente y después se escribe en un registro.
Estos fallos son silenciosos. El sistema funciona, las pruebas pasan y una clave privada se puede recuperar a partir de las firmas que ya ha publicado. Revisamos el diseño en busca de lo que da por supuesto y la implementación para ver si esos supuestos se cumplen, y probamos la salida allí donde las matemáticas permiten un veredicto: firmas, valores aleatorios y textos cifrados.
01Alcance
Qué ponemos a prueba
Diseño de protocolos: autenticación, intercambio de claves, establecimiento de sesiones
Esquemas de firma: generación de nonces en ECDSA y EdDSA, maleabilidad, repetición
Generación, derivación, almacenamiento, rotación y destrucción de claves
Generación de números aleatorios y fuentes de entropía
Modos de cifrado, relleno, autenticación del texto cifrado
Monederos y custodia: gestión de semillas, rutas de derivación, flujos de firma
Esquemas de umbral y multiparte, configuraciones multifirma
Integración con módulos de seguridad de hardware y servicios de gestión de claves
Canales laterales en software: tiempos, comportamiento ante errores, gestión de la memoria
02Enfoque
Cómo se realiza el trabajo
01
Revisión del diseño
Leemos la especificación y enunciamos las propiedades de seguridad que el diseño afirma tener y los supuestos de los que depende.
02
Revisión de la implementación
El código se compara con el diseño. Observamos cómo se usan las bibliotecas y dónde la implementación se aparta de lo que exige el diseño.
03
Análisis de las salidas
Las firmas, los nonces y los valores aleatorios que produce el sistema se analizan en busca de sesgos, reutilización y estructura, con métodos basados en retículos y métodos estadísticos.
04
Demostración del ataque
Cuando una debilidad es explotable, la demostramos con claves de prueba generadas para ello. Las claves que protegen activos reales nunca son el objetivo de una demostración.
Usamos una biblioteca conocida. ¿Hay algo que revisar?
Sí. La biblioteca rara vez es el problema. Los errores están en la forma en que se llama, en los parámetros que recibe y en lo que les ocurre a las claves antes y después de la llamada.
¿Trabajarán con nuestras claves de producción?
No. Trabajamos con claves de prueba y con salidas públicas, como las firmas. Si el análisis de datos públicos muestra que una clave de producción está en riesgo, se le informa de inmediato y la clave no se reconstruye.
¿Pueden revisar un protocolo que solo existe sobre el papel?
Sí, y es el momento más barato para hacerlo. Un fallo de diseño encontrado antes de la implementación cuesta un cambio en un documento.
Auditoría línea a línea de contratos inteligentes y de la lógica del protocolo antes del despliegue: revisión manual, pruebas de invariantes y revisión de las correcciones.