DTLS Grabe con un texto de cifrado extraño

1

Estoy usando mbed TLS para implementar cada servidor DTLS y una aplicación de cliente DTLS. Después del protocolo de enlace DTLS, el cliente envía "Hola, servidor" y luego el servidor responde "Hola cliente". La conexión está funcionando bien y funcionando. (La suite de cifrado negociada es TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 )

Sin embargo, cuando analizo los paquetes de datos de aplicación encriptados usando Wireshark, veo un texto de cifrado extraño. Los datos de la aplicación cifrados siempre parecen comenzar con 00 01 00 00 00 00 00 01 . ¿No debería ser pseudoaleatorio? ¿Podría ser esto un relleno (y si, por qué esta secuencia)?

Primer mensaje ("Hola servidor"):

0000 17 fe fd 00 01 00 00 00 00 00 01 00 21 00 01 00 ............!...
0010 00 00 00 00 01 f3 5f 8c 78 0f cf 25 08 54 ed 1c ......_.x..%.T..
0020 60 ec b2 fe 05 bc ce e9 fe b5 f6 28 e6 e4 '..........(..

       17                    Content Type:    Application Data
       fe fd                 Version:         DTLS 1.2
       00 01                 Epoch:           1
       00 00 00 00 00 01     Sequence Number: 1
       00 21                 Length:          33
       00 ... e4             Encrypted Application Data

Segundo mensaje ("Hola cliente"):

0000 17 fe fd 00 01 00 00 00 00 00 01 00 21 00 01 00 ............!...
0010 00 00 00 00 01 74 9d 2b 3f f4 6d 75 f1 47 a6 12 .....t.+?.mu.G..
0020 7c c1 7d 5e 49 13 69 c9 57 72 60 df 90 56 |.}^I.i.Wr'..V

       17                    Content Type:    Application Data
       fe fd                 Version:         DTLS 1.2
       00 01                 Epoch:           1
       00 00 00 00 00 01     Sequence Number: 1
       00 21                 Length:          33
       00 ... 56             Encrypted Application Data
    
pregunta MemAllox 27.02.2018 - 13:48
fuente

1 respuesta

2

Como sugirió dave_thompson_085, la secuencia al comienzo de los datos de aplicación cifrados es el nonce explícito utilizado por el GCM (Modo de contador de Galois). Aparentemente, este es un tipo de vector de inicialización compartido con el par. Tenga en cuenta que puede haber una parte implícita del nonce que no se envía por cable.

El Protocolo de Seguridad de la capa de transporte (TLS) (RFC5246), 6.2.3.3. Cifras AEAD :

  

Para los cifrados AEAD [...] (como [CCM] o [GCM]), la función AEAD
  convierte las estructuras TLSCompressed.fragment hacia y desde AEAD
  Estructuras TLSCiphertext.fragment.

  struct {
     opaque nonce_explicit[SecurityParameters.record_iv_length];
     aead-ciphered struct {
         opaque content[TLSCompressed.length];
     };
  } GenericAEADCipher;

Puede ver claramente aquí, que el texto cifrado está precedido por nonce_explicit .

Después de algunas pruebas, noté que estos bytes parecen involucrar un contador que se incrementa con cada mensaje enviado. Ahora me pregunté qué tipo de información se envía allí.

RFC5246, 6.2.3.3. Cifras AEAD :

  

Cada AEAD    el conjunto de cifrado DEBE especificar cómo se suministró el nonce a la AEAD    se construye la operación, y cuál es la longitud de la parte GenericAEADCipher.nonce_explicit

Esto significa que tengo que encontrar el RFC donde se especifica el AES con GCM para TLS. Nuevamente, dave_thompson_085 también me llevó a esta respuesta.

Conjuntos de cifrado AES Galois Counter (GCM) para TLS (RFC5288), 3. Conjuntos de cifrado AES-GCM :

  

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

Entonces, estos bytes son la parte explícita del nonce como se especifica en TLS. La implementación (mbedTLS) usó el número de secuencia para ello. Gracias de nuevo a dave_thompson_085!

    
respondido por el MemAllox 01.03.2018 - 13:08
fuente

Lea otras preguntas en las etiquetas