Número de secuencia AES_GCM y TLS

1

¿Tengo razón acerca de que el cifrado / descifrado AEAD utiliza un número de secuencia TLS dos veces, la primera vez en el nonce y una segunda en datos adicionales?

¿Y por qué hicieron el número de secuencia de TLS 1.2 2 veces más grande que el número de secuencia de TSP? ¿Por qué necesitan esta sobrecarga?

Acerca de los datos adicionales de rfc5246 # page-25

  

Los datos autenticados adicionales, que denotamos como datos_adicionales, se definen de la siguiente manera:

additional_data = seq_num + TLSCompressed.type +
                        TLSCompressed.version + TLSCompressed.length;

Acerca de nonce de rfc5288 # page-2

        struct {
            opaque salt[4];
            opaque nonce_explicit[8];
         } GCMNonce;
     

La sal es la parte "implícita" del nonce y no se envía en el paquete. En su lugar, el salt se genera como parte del proceso de intercambio: es el client_write_IV (cuando el cliente está enviando) o el server_write_IV (cuando el servidor está enviando). La longitud de la sal (SecurityParameters.fixed_iv_length) es de 4 octetos.

     

El nonce_explicit es la parte "explícita" del nonce. Es elegido por el remitente y se transporta en cada registro TLS en el campo GenericAEADCipher.nonce_explicit. La longitud nonce_explicit (SecurityParameters.record_iv_length) es de 8 octetos.

     

Cada valor de nonce_explicit DEBE ser distinto para cada invocación distinta de la función de cifrado GCM para cualquier clave fija. El incumplimiento de este requisito de singularidad puede degradar significativamente la seguridad. El nonce_explicit PUEDE ser el número de secuencia de 64 bits.

    
pregunta Ark 22.10.2015 - 20:53
fuente

1 respuesta

2

El número de secuencia PUEDE se usa dos veces.

Primero está, de hecho, el número de secuencia, que es el número de registros enviados desde el último saludo. Ese valor es el que se utiliza en los "datos adicionales" para los conjuntos de cifrado AEAD (en los conjuntos de cifrado CBC + HMAC, el número de secuencia es parte de la entrada al HMAC).

Luego está también el IV por registro, que debe tener una longitud de 12 bytes; en TLS 1.2, estos 12 bytes son la concatenación de un valor implícito de 4 bytes (el que se calcula a partir del intercambio de claves) y un campo explícito de 8 bytes por registro. El remitente es responsable de elegir ese valor de 8 bytes, con la advertencia de que cualquier valor dado NO DEBE reutilizarse (con la misma clave). Sin embargo, GCM no es exigente con ese IV, siempre que se respete la regla de "no reutilización". Por lo tanto, muchas implementaciones encuentran conveniente utilizar un contador simple, y la consecuencia es que el contador se sincronizará con el número de secuencia, ya que ambas se incrementarán para cada registro saliente. Esto no es un problema.

TLS 1.2 podría haber sido definido para usar el número de secuencia directamente para el GCM por registro IV; Esto habría guardado 8 bytes en cada registro. Habría estado bien. Sin embargo, el ahorro no es grande: desea guardar bytes cuando envía una gran cantidad de datos, y entonces probablemente esté usando registros grandes (16384 bytes de texto sin formato por registro), por lo que 8 bytes adicionales no son un gran problema comparativamente. / p>

La razón por la que se definió TLS 1.2 de esa manera no está clara; uno tendría que revisar las actas de las reuniones del comité para ver si había alguna razón para eso. Sin embargo, es una apuesta bastante segura que si hubiera una "razón", entonces probablemente fue una vaga afirmación semi-dogmática como "debemos incluir un campo explícito porque puede ayudar a contrarrestar un futuro ataque desconocido en algunos aún no especificados". manera ".

    
respondido por el Tom Leek 22.10.2015 - 21:11
fuente

Lea otras preguntas en las etiquetas