¿Es razonable prevenir los ataques de tiempo usando un tiempo de procesamiento fijo?

El tiempo de procesamiento fijo es el método más básico y completo para defenderse de los ataques de temporización: para evitar la explotación de los datos que se filtran a través de la temporización, bueno, no se filtren. Sin embargo, es más fácil decirlo que hacerlo. El reciente "Lucky Thirteen" muestra que es posible detectar diferencias de tiempo con una precisión de microsegundos cuando el objetivo es "cerca" del atacante (en la misma LAN); los detalles del ataque aprovechan la pequeña fuga que quedaba en las implementaciones SSL que estaban parcheadas con respecto a los ataques de tiempo - estas implementaciones estaban calculando el MAC incluso cuando el descifrado no produjo un relleno adecuado, precisamente para obtener un tiempo de procesamiento que fue tan fijo como se pudo lograr; pero era difícil evitar una variabilidad de un microsegundo.

Si aplica un tiempo de procesamiento "general" fijo (por ejemplo, 1 segundo para cada solicitud), tendrá problemas con los sistemas operativos multitarea. Si la implementación es solo una llamada sleep() después del procesamiento principal, entonces la CPU es libre de manejar otras solicitudes, lo que se ve bien ... pero pierde datos, ya que el atacante podría enviar otras solicitudes simultáneamente y averiguar si su servidor está ocupado o no En general, al enviar muchas solicitudes a su servidor, el atacante puede hacer que el tiempo de procesamiento de cada solicitud sea arbitrariamente largo y exceda cualquier límite fijo. Si solo restringe el tiempo de procesamiento para que sea un múltiplo integral de una granularidad fija (por ejemplo, el tiempo de procesamiento siempre es n por 0.1 segundos, con n como un número entero), entonces simplemente tiene "umbrales" que hacen que la tarea sea un poco más difícil para el atacante, pero no imposible, e incluso podría ayudar al atacante. De hecho, el ataque "Lucky Thirteen" muestra cómo la explotación de dicho umbral (correspondiente a la forma en que SHA-1 y SHA-256 procesan los datos mediante bloques de 64 bytes) solo necesita un "phasing" y hace que la imagen estadística sea más clara.

En este momento, la mejor defensa parece ser la adición de un retraso aleatorio de unos pocos milisegundos, lo que desenfocará la imagen y evitará el análisis ... y, además, no permita que el atacante conecte el la misma LAN que el servidor . Lo que debería ser evidente.

La esencia básica de un ataque de tiempo es enviar a un servidor diferentes muestras de datos y ver si las diferentes entradas producen diferentes rutas de código observando cuánto tiempo se tardó en procesar la entrada. La mejor defensa contra los ataques de tiempo es mantener el código en la misma ruta de ejecución, independientemente de la entrada.

Esto es mucho más fácil decirlo que hacerlo. Una función simple como memcmp() no garantiza la misma ruta de código porque sale después de la primera falta de coincidencia de bytes; Las diferentes entradas harán que salga de diferentes puntos. Una respuesta natural es escribir una función personalizada memcmp() -esque, pero hacerlo es tampoco es sencillo .

El mayor problema es cómo se manejan los errores y la validación. Independientemente de los errores de preprocesamiento / validación / comprobación de validez, debe ejecutarse el mismo código incluso si se da cuenta de que la salida se desechará más adelante. Cuando observa ataques de tiempo prácticos , un ejemplo que aparece con frecuencia es tiempo variable para validaciones de MAC. El momento de las primitivas criptográficas en bruto no es realmente una preocupación; las operaciones de modificación de bits de algo como AES o SHA2 tomarán la misma cantidad de tiempo, independientemente de las cadenas de entrada que obtengan. El enfoque principal debe ser cómo se manejan los errores, los casos especiales y las comparaciones de datos.

Una cantidad fija de tiempo en la pared para una operación no es necesariamente la mejor defensa; el atacante puede evitarlo al crear la entrada para que el tiempo de operación sea el correcto en el umbral de los incrementos de tiempo de la pared constante y luego ver qué operaciones empujan la operación por encima del umbral. El enfoque ideal en la mayoría de las situaciones es ejecutar exactamente el mismo código independientemente de la entrada.

Sin embargo, no conocemos su situación exacta ni la información exacta que intenta mantener confidencial, por lo que lo anterior es genérico. Por ejemplo, el enfoque de mantener la ejecución del código de la misma manera filtrará información sobre la cantidad de datos que se procesan y no sabemos si eso es una preocupación para usted. En muchos casos, el atacante ya conoce el tamaño de los datos (porque los suministraron), pero no sabemos si eso es un problema aquí.