Cómo protegerse contra los "ataques oracle de relleno".

El padding oracle es una mezcla de una falla de protocolo y una falla de implementación. A saber, un "oráculo de relleno" filtra información sobre datos secretos a través de cómo reacciona a una entrada inválida creada con fines malintencionados. Un protocolo bueno primero validará los datos de entrada a través de un MAC antes de considerando el descifrado y su corolario, el procesamiento del relleno. De eso se trata la construcción de "cifrar, entonces, MAC". Un protocolo malo hará las cosas en el orden incorrecto y puede sufrir una fuga al aplicar primero el descifrado; eso es lo que sucede en SSL con modos de cifrado CBC.

Si el protocolo es incorrecto, entonces la implementación debe estar especialmente protegida contra el tipo de mensajes no válidos que los atacantes intentarán realizar a mano para convertir alguna implementación (por ejemplo, un servidor) en un oráculo de relleno. Tal blindaje es difícil (por ejemplo, el ataque Lucky Thirteen demuestra, en condiciones de laboratorio, la posibilidad teórica de fugas incluso con implementaciones completamente protegidas).

La función PHP que vinculas también tiene que ver con el cifrado; Por definición, no puede hacer nada contra el relleno de los oráculos. La protección contra los oráculos de relleno está más a nivel de protocolo . Como es típico con PHP, la funcionalidad peligrosa se proporciona con poca advertencia y una API subóptima.

Diseñar tu propio protocolo seguro es incluso más difícil que protegerte contra ataques de canal lateral, así que no hagas eso. E incluso si haces , no hagas eso en PHP.

Para protegerse contra los oráculos de relleno, debe asegurarse de que su aplicación no devuelva un error diferente cuando el relleno sea incorrecto. La mejor manera de hacer esto es un Encrypt-then- Construcción de MAC , donde se aplica un código de autenticación de mensaje (MAC) al texto cifrado. Si el MAC falla, ni siquiera necesita mirar el relleno. Si el MAC es correcto, es criptográficamente improbable que el relleno haya sido manipulado.

El Padding Oracle Attack es un ataque de canal lateral que se puede usar para descifrar cifrados simétricos de ECB o CBC. Este ataque funciona filtrando información sobre el relleno durante el descifrado del texto cifrado. Para evitar esto, puede agregar autenticación al texto cifrado, por ejemplo, utilizando HMAC. La técnica más utilizada es Encrypt-then-MAC .

En PHP, puede usar Zend \ Crypt \ BlockCipher componente de Zend Framework 2, que implementa Encrypt-then-MAC usando HMAC, proporcionando una API muy simple:

use Zend\Crypt\BlockCipher;

$blockCipher = BlockCipher::factory('mcrypt', array('algo' => 'aes'));
$blockCipher->setKey('encryption key');
$ciphertext = $blockCipher->encrypt('this is a secret message');
echo "Ciphertext: $ciphertext \n";
$plaintext = $blockCipher->decrypt($ciphertext);
echo "Plaintext: $plaintext \n";

Solo para decirlo a mi manera, primero, un "oráculo" en criptografía se basa en el concepto de un oráculo mitológico; una persona con una línea directa a una deidad, y por lo tanto con acceso a información que los simples mortales no tienen. En la criptografía, los oráculos son "cajas negras" que pueden realizar tareas que serían difíciles para el atacante y, por lo tanto, pueden proporcionar información a un atacante que normalmente es difícil de obtener.

Un oráculo de relleno, específicamente, puede decirle al atacante si un mensaje que ingresa está correctamente rellenado (la mayoría de los modos de cifrado de bloque utilizan algún tipo de relleno de datos extraíble para garantizar que la longitud del mensaje sea un múltiplo exacto del tamaño del bloque del cifrado ). Para ello, intenta descifrar el mensaje y se comporta de manera diferente cuando un bloque se rellena o no se rellena correctamente, tales diferencias de comportamiento son visibles para el atacante. El oráculo de relleno suele ser un participante involuntario; el atacante normalmente secuestra una implementación de cifrado inicializada, alimentándolo con mensajes especialmente diseñados de su elección en lo que se conoce como un ataque de texto cifrado elegido.

Un tipo de ataque relacionado es un ataque de tiempo; es una forma en que una implementación de descifrado se puede convertir en un oráculo de relleno, midiendo el tiempo que lleva determinar si el bloque está correctamente rellenado. Algunos modos de cifrado, como CBC, se pueden descifrar en cualquier orden, por lo que algunas implementaciones descifran el último bloque primero para verificar el relleno del mensaje, en un intento de "fallar rápido" en los mensajes dañados. Sin embargo, un atacante puede usar la diferencia entre el tiempo que tarda en verificar el relleno y en intentar descifrar el mensaje completo para determinar cuál de los dos sucedió, incluso si el error que se le muestra al atacante es el mismo en ambos casos.

Para protegerse contra estos tipos de ataques, no debe haber una diferencia discernible en el comportamiento entre un intento de descifrar un mensaje que no esté correctamente rellenado en comparación con uno que sí lo está. La forma más conocida de hacerlo es incorporar una suma de comprobación segura conocida como Código de autenticación de mensaje. Este MAC se produce normalmente mediante un "hash con clave" seguro, que utiliza la misma clave que cifró el mensaje. El mensaje se cifra primero, y luego el texto cifrado, junto con la información sobre cómo se cifró, como el algoritmo de cifrado, el modo de cifrado, el tamaño de la clave, el tamaño del bloque y el IV, se procesa mediante el uso del algoritmo MAC y la misma clave.

Para descifrar, el algoritmo primero vuelve a calcular el MAC dado el texto cifrado y la información de cifrado compartida entre las dos computadoras. Si el MAC computado no coincide con el que se incluye con el texto cifrado, el descifrado falla; o el mensaje, el MAC o ambos se han cambiado en el tránsito por algún medio, ya sea benigno (corrupción de datos) o malévolo (intento de ataque).

Se cree que las posibilidades de que un atacante, al no saber la clave, sea capaz de cambiar el texto cifrado y su MAC de manera consistente sean difíciles, y con eso me refiero a aproximadamente 1 en 2 ^ (tamaño de clave) posibilidad, por lo que la estrategia de cambiar sistemáticamente el mensaje se vuelve menos eficiente que simplemente intentar cada clave posible. Además, debido a que la misma operación, que casi siempre lleva el mismo tiempo, puede detectar cualquier problema de datos posteriores al cifrado que haría que el mensaje no fuera válido, un atacante no puede distinguir la diferencia hecha por cualquier cambio sistemático en el texto cifrado y MAC ; o coincide (es extremadamente improbable; vea arriba) o no ( mucho es más probable).