1

I am using mbed TLS to deploy each a DTLS Server and a DTLS Client application. After the DTLS Handshake, the Client sends "Hi, Server" and then the Server answers "Hi Client". The connection is working fine and running. (The negotiated Cipher Suite is TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384)

However, when I analyze the encrypted Application Data packets using Wireshark, I see a weird cipher text. The encrypted application data always seems to start with 00 01 00 00 00 00 00 01. Shouldn't it be pseudorandom? Might this be padding (and if, why this sequence)?

First Message ("Hi Server"):

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

Second Message ("Hi Client"):

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
9
  • I'm not sure you are asking the correct people about this. You are asking why a certain library does something. I think this is a question for the devs
    – schroeder
    Feb 27, 2018 at 13:06
  • @schroeder I actually don't know if this is due to the (D)TLS standard or the implementation.
    – MemAllox
    Feb 27, 2018 at 13:09
  • 2
    @MemAllox this is in the opaque fragment part of a DTLS frame according to the RFC: tools.ietf.org/html/rfc4347#section-4
    – Tensibai
    Feb 27, 2018 at 13:14
  • 1
    Because the way the opaque fragment is done is up to each library, That's more or less dependent on the cypher used than on DTLS I think.
    – Tensibai
    Feb 27, 2018 at 13:24
  • 1
    GCM suites in [D]TLS use AEAD format (rfc5246 6.2.3.3) which begins with explicit nonce (part) of length defined by the suite; GCM suites use 8 bytes (rfc5288 3) which 'MAY be [a copy of] the 64-bit sequence number' and this implementation does make it so. (This is not affected by the keyexchange used.) Feb 28, 2018 at 3:34

1 Answer 1

2

As dave_thompson_085 suggested, the sequence at the beginning of the encrypted application data is the explicit nonce used by the GCM (Galois Counter Mode). Apparently, this is some kind of initialisation vector shared with the peer. Note that there might be an implicit part of the nonce which is not sent over wire.

The Transport Layer Security (TLS) Protocol (RFC5246), 6.2.3.3. AEAD Ciphers:

For AEAD [...] ciphers (such as [CCM] or [GCM]), the AEAD function
converts TLSCompressed.fragment structures to and from AEAD
TLSCiphertext.fragment structures.

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

You can clearly see here, that the Ciphertext is preceded by nonce_explicit.


After some testing, i noticed that these bytes seems to involve a counter that increments with each sent message. Now I asked myself what sort of information is sent there?

RFC5246, 6.2.3.3. AEAD Ciphers:

Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the GenericAEADCipher.nonce_explicit part

This means that I have to find the RFC where the AES with GCM is specified for TLS. Again, dave_thompson_085 also led me to this answer.

AES Galois Counter Mode (GCM) Cipher Suites for TLS (RFC5288), 3. AES-GCM Cipher Suites:

Each value of the nonce_explicit MUST be distinct for each distinct
invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security.
The nonce_explicit MAY be the 64-bit sequence number.

So these bytes are the explicit part of the nonce as specified in TLS. The implemtation (mbedTLS) used the sequence number for it. Thanks again to dave_thompson_085!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .