¿Cómo verificar el motor criptográfico?

No. No hay una buena manera de detectar puertas traseras en hardware criptográfico. Hay demasiadas formas de ocultar las puertas traseras para que no se detecten.

Las pruebas no son una forma efectiva de detectar puertas traseras introducidas deliberadamente. Un atacante puede organizar fácilmente que la puerta trasera se active solo para un texto en particular, o solo después de recibir un "golpe críptico" especial. Por ejemplo, el motor de hardware puede tener un valor secreto de 64 bits oculto en él. Inicialmente, la puerta trasera está deshabilitada. Sin embargo, si recibe un texto cifrado que comienza con el secreto de 64 bits, entonces ese es el "golpe críptico"; cuando se recibe el "golpe críptico", el motor de hardware puede encender la puerta trasera. Esto permite a un atacante habilitar la puerta trasera algún tiempo después de que el sistema entre en producción. También se podrían utilizar medios similares para permitir que un atacante apunte dinámicamente comunicaciones específicas o evade la detección.

Hay muchas maneras en que un motor de cifrado malintencionado puede subvertir su seguridad. Si lo usa para generar números aleatorios o claves criptográficas, podría "aumentar" la fuente de números aleatorios y generar claves que serán adivinables para el atacante. Si lo usa para verificar la integridad del mensaje firmado, podría aceptar falsamente ciertos mensajes maliciosos cuando el atacante le indique que lo haga. Si lo usa para cifrar datos confidenciales, podría potencialmente filtrar los datos confidenciales al resto del mundo de diferentes maneras. Si tiene acceso directo a la red, podría filtrar datos y claves confidenciales simplemente enviándolos a través de la red. Si no tiene acceso directo a la red, aún podría ocultar datos confidenciales o secretos criptográficos en los textos cifrados y filtrar esta información a través de un canal subliminal (por ejemplo, aprovechando el grado de libertad en la elección de un nonce, IV , u otro valor aleatorio para ocultar datos secretos en ellos).

E incluso si no puede hacer nada de eso, un motor de criptografía malintencionado todavía podría filtrar datos confidenciales o material de clave criptográfica utilizando un canal de sincronización. Consulte Jitterbug para ver un ejemplo de una pieza de hardware malicioso que filtra datos confidenciales ajustando el tiempo de paquetes de red. Un motor criptográfico malintencionado podría usar un mecanismo similar: por ejemplo, cuando se le pide que cifre algo, demora la respuesta a la solicitud hasta que el bit de orden inferior de la hora actual en milisegundos coincida con el bit que desea enviar. Por lo tanto, la hora a la que se envían los paquetes de texto cifrado a través de la red filtrará información sobre la hora a la que respondió el motor criptográfico, que a su vez oculta un mensaje subliminal que el motor criptográfico malintencionado deseaba filtrar.

Conclusión: si no confías en el hardware criptográfico, básicamente no hay forma de ganar. Por lo tanto, solo debe usar hardware de cifrado en el que confíe.

Si desea verificar la funcionalidad básica de un motor de criptografía, agregue una buena selección de entradas y verifique que devuelva los resultados correctos en estas entradas. Si su muestra está bien elegida, puede confiar en que el motor es funcionalmente correcto.

Muchos algoritmos criptográficos basados en estructura matemática (típicamente, algoritmos de clave pública como RSA) tienen métodos para obtener cierta seguridad de que el resultado es correcto sin hacer todo el trabajo. Por ejemplo, si ejecuta un cómputo que se basa en operaciones de módulo con un entero grande, puede realizar el cómputo módulo con un pequeño entero y verificar que el resultado sea correcto en módulo ese pequeño entero - una generalización de la eliminación de nueves. Esta técnica se conoce como wooping . Dichas comprobaciones pueden funcionar contra bibliotecas bignum maliciosas si realiza pruebas con suficientes números pequeños aleatorios. Sin embargo, no siempre puedes hacer esto; por ejemplo, si hubiera una forma de verificar un resumen criptográfico que fuera más barato que calcularlo a la larga, el algoritmo de resumen se rompería seriamente. No conozco nada comparable con los algoritmos de cifrado simétrico.

Si desea saber si el motor criptográfico es seguro , es un asunto completamente diferente. El motor podría estar filtrando datos a través de canales laterales, y esto no se puede notar al realizar pruebas. Solo se puede notar esto por un estudio muy cuidadoso, preferiblemente caja abierta. De manera similar, la generación de números aleatorios no se puede probar, y es difícil hacerlo bien; puede obtener cierta medida de confianza con las pruebas estadísticas, pero no todos los generadores de números aleatorios estáticamente sólidos son lo suficientemente buenos para la criptografía, que requiere números aleatorios impredecibles. Aquí hay algunos ejemplos de vulnerabilidades que pueden ser muy difíciles de detectar, y son prácticamente imposibles de detectar si son deliberadas a puerta trasera:

• El generador aleatorio tiene una entropía baja: devuelve números aleatorios que son predecibles con una probabilidad inusualmente alta. Ejemplo (accidental): la vulnerabilidad de Debian OpenSSL .
• El motor pierde información confidencial, como la salida de RNG o el material clave a través de su tiempo de respuesta. (Este es un ejemplo de un canal lateral , existen canales laterales distintos del tiempo: consumo de energía, emisiones de radio, etc. )
• El motor filtra información confidencial a través de los canales normales de manera indetectable, gracias a un canal subliminal . Por ejemplo, cada vez que el motor genera un nonce aleatorio (un IV para los modos de cifrado de bloques, relleno RSA, el parámetro de firma k en DSA, etc.), el n - el valor aleatorio de bits es de hecho un valor aleatorio de ( n -1) bits más un bit de la clave cifrada con una clave secreta.

Los motores criptográficos pueden ser certificados para cumplir con los estándares de seguridad como Common Criteria y < a href="http://en.wikipedia.org/wiki/FIPS_140"> FIPS 140 . Excluyendo las certificaciones "triviales", como FIPS 140-2 nivel 1 que en realidad no dicen nada acerca de la seguridad, una certificación toma varios meses-hombre y es realizada por expertos. Incluso si su motor criptográfico está certificado, lea la certificación detenidamente: la mayoría de las certificaciones solo responden por el motor si se usa en condiciones muy precisas, y solo contra atacantes con medios limitados. Y, por supuesto, la certificación es solo la opinión de un profesional; Los productos certificados pueden y han sido rotos.

¹ _{Estoy simplificando un poco. Lea sobre esto en Notas de la conferencia de Sami Vaarala o en la de Bruce Schneier et al. Cryptography Engineering o en tesis deJurjen Bos .}

Suena como un trabajo para Pruebas de unidad . Creo que estas pruebas son muy específicas para su plataforma, pero se verían algo como esto .