PolarSSL is now part of ARM Official announcement and rebranded as mbed TLS.

Bad MAC - Debug Help


Sep 11, 2017 11:05
Doru

Hello,

I use mbedtls in my application but the DTLS handshake is not successful. More accurate, the server reports that the encrypted "Finished" message received from the client has a bad MAC. During a debug session I noticed that the function "ltc_aes_received_mac_compare" returns with error.

The cypersuite that I use is MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 together with a self-signed certificate generated using the instructions from [1]. Both the client and the server are loaded with the same certificate.

How could I easily debug this issue?

[1] https://tls.mbed.org/kb/how-to/generate-a-self-signed-certificate

 
Sep 11, 2017 14:28
Ron Eldor

Hi Doru,
This error is most likely happening because the key or IV that is used by your client and server is different, causing the MAC output of the AES CCM to be different. It is also possible that the message itself is different ( e.g. some bytes were lost\overwritten ), but it's more likely that the key has been changed \ wrongfully exchanged.
I would recommend you run your server and client with full debug level, and check your key and iv that are used on both sides.
Regards,
Mbed TLS Team member
Ron

 
Sep 12, 2017 16:01
Doru

Hello,

Server debug messages can be found at [1] while the client debug messages can be found at [2]. Do you rapidly spot a problem?

[1] https://ufile.io/34bsm [2] https://ufile.io/3yyu0

Thanks, Doru

 
Sep 13, 2017 07:37
Ron Eldor

Hi Doru,
In the server logs:

 8:1661 dumping 'IV used' (12 bytes)

 8:1661 0000:  b0 a4 5d 94 00 01 00 00 00 00 00 00

In the Client logs:

8:1388 dumping 'IV used' (8 bytes)

8:1388 0000:  00 01 00 00 00 00 00 00

So the used IV is different.
But there is an earlier error in the client log that might cause the issue:

 8:4454 x509_verify_cert() returned -9984 (-0x2700)

Unfortunately, there aren't enough logs to identify reason for certificate verification to fail, probably because of debug level used, so I can only assume that you haven't set the ca_chain in the client side, for the correct root certificate, using the mbedtls_ssl_conf_ca_chain API. In addition, it is not advised to use same certificate for both sides.
Regards,
Mbed TLS Team member
Ron

 
Sep 13, 2017 15:20
Doru

Hello, Ron

Thanks for your help. I managed to solve the certification verification. The problem was caused by the incorrect usage of mbedtls_ssl_set_hostname on the client with a wrong hostname.

Still, the second problem related to the bad MAC still persists. From the debug messages it seems that the there is a problem with the IV length, which has 8 bytes on the client and 12 bytes on the server. On the server side, the last 8 bytes from the IV are identical with the IV from the client. Is this correct or is it a bug?

The debug level is set to 4 (maximum) and I for debugging reasons I used the same certificates both on the client and on the server.

I attached a client log [1] and a server log [2] gathered after I solved the certification verification issue.

[1] https://ufile.io/ni87o [2] https://ufile.io/qc7jp

 
Sep 13, 2017 16:20
Doru

Sorry for double posting. It seems that the root of the error comes from the fact that the master secret is not the same on the client and server.

 
Sep 14, 2017 13:14
Ron Eldor

Hi Doru,
Thank you for your infomration. I am glad you managed to resolve your issue. As for the wrong IV length, it's only a matter of different log in the encrypt and decrypt of the payload.
Regards,
Mbed TLS Team member
Ron

 
Sep 14, 2017 14:25
Doru

Hi, Ron

Actually, I didn't solve the issue, I just noticed that the master secret is different on the client and server.

According to the DTLS specification the pre-master secret is used to generate the master-secret and the session-key [1]. Logs shows that the pre-master secret is the same but in the function mbedtls_ssl_derive_keys() the generated session hash and master key are different on client and server side.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380513(v=vs.85).aspx

Regards, Doru

 
Sep 17, 2017 11:10
Ron Eldor

Hi Doru,
Note that the master key has a random element in its derivation, so I wouldn't focus on this, at the moment.
I would like to understand if the difference is in the key or IV, or another issue.
in ssl_tls.c , function ssl_encrypt_buf change the following line:

        MBEDTLS_SSL_DEBUG_BUF( 4, "IV used", ssl->out_iv,
                ssl->transform_out->ivlen - ssl->transform_out->fixed_ivlen );

to

        MBEDTLS_SSL_DEBUG_BUF( 4, "IV used", ssl->out_iv,
                ssl->transform_out->ivlen );

This will let you know if the IV is the same on both peers.
I also suggest you check all the parameters that are given to mbedtls_cipher_auth_encrypt and mbedtls_cipher_auth_decrypt , including the key, so you could check the differences and see what has changed.
Regards,
Mbed TLS Team member
Ron

 
Sep 17, 2017 14:40
Ron Eldor

HI Doru,
I am sorry for confusion.
Even though the master secret contains randomness, it should obviously be derived the same way on both sides. Since the session hash is different on both peers, I would start investigating the input given for the hash function. Check configuration on both peers, to see what could cause the issue.
Also, check the buffer given to update_checksum on your flow.
Regards,
Mbed TLS Team member
Ron

 
Oct 4, 2017 07:55
Doru

Hello, Ron

Your indications related to session hash were valuable and helped me to find the problem: the session hash computed on the server was different by the one computed on the client. This was due to the fact that that, on the server side, the session hash covered also the first Client Hello without the cookie.

The solution was to reset the session (mbedtls_ssl_session_reset) on the server side in case MBEDTLS_ERR_SSL_HELLO_VERIFY_REQUIRED is received.

Sorry for the delayed answer.

Thanks, Doru