¿Cómo puedo saber qué relleno se usó en una suite de cifrado?

5

Estoy intentando escribir un programa java que descifra los paquetes tls. Quiero usar la clase Cipher. Por el apretón de manos sé que, por ejemplo, mi CipherSuite es 0x00 0x2f que es TLS_RSA_WITH_AES_128_CBC_SHA . Entonces, cuando llamo a Cipher.getInstance(); , se me dice " AES/CBC/???? ", pero ¿qué es el relleno?

Leí en ¿Cómo funciona SSL / TLS? , que:

  

... luego algunos rellenos (dependiendo del algoritmo de cifrado) ...

Y de Uso de Padding in Encryption en www.di-mgt.com.au Sé que hay Hay al menos 5 métodos de relleno.

A mi entender, hay más de una posibilidad para un algoritmo de cifrado.

Entonces, ¿cómo puedo saber cuál fue utilizado? ¿O puedo sacarlo del apretón de manos?

    
pregunta michaelfreeman 11.03.2016 - 14:51
fuente

1 respuesta

2

El relleno en TLS es casi el mismo que el relleno PKCS # 7, pero con algunas diferencias sutiles.

Al usar el cifrado CBC, en TLS, las cosas van de la siguiente manera:

  • El MAC se calcula sobre el texto sin formato y se adjunta al texto sin formato. En el caso de TLS_RSA_WITH_AES_128_CBC_SHA, eso es HMAC / SHA-1, por lo que 20 bytes adicionales.

  • Lo que se cifrará es la concatenación del texto plano, el MAC y el relleno. La longitud total debe ser un múltiplo del tamaño del cifrado del bloque, es decir, 16 en el caso de AES. El relleno consiste en agregar n +1 bytes, de manera que 0 ≤ n ≤ 255. Por lo tanto, hay al menos 1 byte adicional, como máximo 256, todos tienen el mismo valor , y ese valor es uno menos que la longitud de relleno.

    (En el verdadero relleno PKCS # 7, habría n +1 bytes que todos tienen el valor n +1, no n . )

  • Tras el descifrado, DEBEN verificarse los contenidos de los bytes de relleno, así como el MAC. Hacerlo de manera segura es difícil de hacer pero si está escribiendo una herramienta de inspección, entonces usted es el atacante y, por lo tanto, puede permitirse hacer las cosas de manera más insegura.

En la versión anterior de SSL 3.0, solo el último byte de relleno tenía que tener el valor n , los otros bytes eran aleatorios (y esto es una debilidad en el protocolo). A la inversa, en SSL 3.0, no se permitió que la longitud total del relleno excediera la longitud del cifrado del bloque, mientras que en TLS puede ser más larga (hasta 256 bytes), siempre que la longitud total del mensaje rellenado sea un múltiplo de la longitud del bloque.

Para una herramienta de inspección, el método de implementación más simple sería descifrar con el relleno "ninguno", y luego inspeccionar y eliminar el relleno y el MAC con el código explícito que usted mismo escribe. No hay un método de relleno "estándar" implementado en Java que coincida con la variante utilizada en TLS.

Si está interesado en descifrar el protocolo de enlace de SSL / TLS, puede ser una buena idea escribir primero su propia biblioteca de SSL / TLS, no para uso de producción (estas cosas son muy difíciles de entender con respecto a ataques de canal lateral ), pero más para ganar experiencia en los detalles finos del protocolo. Cuando su propia biblioteca logra completar un apretón de manos, sabe que los obtuvo todos correctamente. Además, los elementos del código serán reutilizables para su herramienta de inspección. Por lo tanto, escribir su propia biblioteca es una buena inversión pedagógica (siempre que recuerde la condición: ¡no para uso de producción!).

Es posible que desee leer esta respuesta como introducción al protocolo.

    
respondido por el Thomas Pornin 11.03.2016 - 15:26
fuente

Lea otras preguntas en las etiquetas