Mbed forum

Decryption fails with 0x7180 (Verification of the message MAC failed)


(Kartik Inani) #1

Hi,

mbedTLS version used is 2.14.0.
mbedTLS worked fine on i386 based 64-bit linux machine out of the box. Also, we could port same on a 32-bit processor, little endian arm (EABI5 v1) based linux machine.

With same configuration used in above machines, while trying to port mbedTLS on iRTOS, ARM9 based processor, 32-bit big endian RISC architecture, it fails in write certificate verify after calc verify sha256 stage in client state:9.

The error logs logged are:

ssl_cli.c:3500: |2| client state: 9
ssl_tls.c:2754: |2| => flush output
ssl_tls.c:2766: |2| <= flush output
ssl_cli.c:3214: |2| => write certificate verify
ssl_tls.c:0628: |2| => derive keys
ssl_tls.c:0705: |3| dumping ‘premaster secret’ (48 bytes)
ssl_tls.c:0705: |3| 0000: 03 03 c5 33 78 f9 34 ed a4 57 3b 03 9a dd 86 cd …3x.4…W;…
ssl_tls.c:0705: |3| 0010: 50 7b c0 67 b9 26 11 ef ad 0f 33 e1 ce 16 86 ee P{.g.&…3…
ssl_tls.c:0705: |3| 0020: b5 4a cc 6b 98 1b 9e fc 2c fc 25 75 6a f4 43 51 .J.k…,.%uj.CQ
ssl_tls.c:0714: |3| using extended master secret
ssl_tls.c:1205: |2| => calc verify sha256
ssl_tls.c:1210: |3| dumping ‘calculated verify result’ (32 bytes)
ssl_tls.c:1210: |3| 0000: 96 d8 56 74 51 6e a0 79 fd c8 60 b7 8d e6 37 a4 …VtQn.y…...7. ssl_tls.c:1210: |3| 0010: 00 6a c7 8e 75 0a 17 a6 3a 6d 9f b9 8b 64 8b 5d .j..u...:m...d.] ssl_tls.c:1211: |2| <= calc verify ssl_tls.c:0735: |3| dumping 'session hash' (32 bytes) ssl_tls.c:0735: |3| 0000: 96 d8 56 74 51 6e a0 79 fd c8 60 b7 8d e6 37 a4 ..VtQn.y..…7.
ssl_tls.c:0735: |3| 0010: 00 6a c7 8e 75 0a 17 a6 3a 6d 9f b9 8b 64 8b 5d .j…u…:m…d.]
ssl_tls.c:0794: |3| ciphersuite = TLS-RSA-WITH-AES-128-CBC-SHA
ssl_tls.c:0796: |3| dumping ‘master secret’ (48 bytes)
ssl_tls.c:0796: |3| 0000: ed 60 c7 11 c3 f5 ea ee 1c 70 da 16 9b c1 59 a3 ........p....Y. ssl_tls.c:0796: |3| 0010: 30 7b c6 4a a4 e0 fd 54 41 e2 e3 95 ce a3 6f 42 0{.J...TA.....oB ssl_tls.c:0796: |3| 0020: 98 3f 7f a0 fb d1 d5 cd e1 39 8d b9 2f 75 1a 65 .?.......9../u.e ssl_tls.c:0797: |4| dumping 'random bytes' (64 bytes) ssl_tls.c:0797: |4| 0000: 5c 0a 91 d6 f5 03 2c fd de dd f2 24 1c 8f 2e 53 \.....,....$...S ssl_tls.c:0797: |4| 0010: 4d 45 6d be 9c d4 e4 12 f4 41 68 43 c8 1c fd 76 MEm......AhC...v ssl_tls.c:0797: |4| 0020: 72 a8 b8 48 72 6e 0e 83 ac 00 fe 0d 93 ad 1b 08 r..Hrn.......... ssl_tls.c:0797: |4| 0030: ae 14 85 a1 71 23 c1 2c 06 ab 4e ef cf fd f0 bf ....q#.,..N..... ssl_tls.c:0798: |4| dumping 'key block' (256 bytes) ssl_tls.c:0798: |4| 0000: 32 76 00 78 f3 d4 57 38 42 c7 fe a2 f9 19 3c 82 2v.x..W8B.....<. ssl_tls.c:0798: |4| 0010: a2 31 11 a4 cc a2 e4 2e e5 37 75 ee 6f 49 df 19 .1.......7u.oI.. ssl_tls.c:0798: |4| 0020: 9a a4 9f df 35 d8 e9 ab 9b a0 c0 a7 f9 94 21 03 ....5.........!. ssl_tls.c:0798: |4| 0030: 42 22 19 b6 52 ad 9d 47 e0 c3 bf 1b 35 01 b3 77 B"..R..G....5..w ssl_tls.c:0798: |4| 0040: 5a 41 30 65 57 e7 17 e9 85 1f 27 2a 60 7d 9e ea ZA0eW.....'*}…
ssl_tls.c:0798: |4| 0050: 3f 91 4b 76 ae d8 96 a1 e3 fe 83 f5 c1 dd e8 d5 ?.Kv…
ssl_tls.c:0798: |4| 0060: 10 f9 98 ec ee 91 51 b4 7e 82 91 db 91 df 1f 0f …Q.~…
ssl_tls.c:0798: |4| 0070: 6a 87 a6 1e 12 b7 78 0d b4 66 d3 ee 73 1c 40 7e j…x…f…s.@~
ssl_tls.c:0798: |4| 0080: 58 d7 3c 9a 61 9a 54 a1 8b 34 64 06 8c 2d 1c 85 X.<.a.T…4d…-…
ssl_tls.c:0798: |4| 0090: 9f 47 13 f8 dc 30 6f 7e ea ba fb 71 71 88 2d 6c .G…0o~…qq.-l
ssl_tls.c:0798: |4| 00a0: 36 bf a1 76 30 75 f2 a8 a5 0b 80 1b 80 68 a7 f2 6…v0u…h…
ssl_tls.c:0798: |4| 00b0: 62 ed c2 92 03 0e 7b 43 27 3d 6e 77 00 b8 2a 60 b…{C’=nw…*ssl_tls.c:0798: |4| 00c0: 0c 68 af 10 c9 47 ca a4 57 d4 a5 80 ca 6c 6e 2f .h...G..W....ln/ ssl_tls.c:0798: |4| 00d0: d7 65 bb 77 48 71 51 33 66 fb 5a 91 ad 68 60 e7 .e.wHqQ3f.Z..h.
ssl_tls.c:0798: |4| 00e0: cb 8b b1 93 da a8 39 fe 7a 4b 94 ca 8b 0e e3 11 …9.zK…
ssl_tls.c:0798: |4| 00f0: f0 a8 d4 35 2e 0e 8c c5 23 c9 63 59 36 a1 73 74 …5…#.cY6.st
ssl_tls.c:0919: |3| keylen: 16, minlen: 48, ivlen: 16, maclen: 20
ssl_tls.c:1116: |2| <= derive keys
ssl_tls.c:1205: |2| => calc verify sha256
ssl_tls.c:1210: |3| dumping ‘calculated verify result’ (32 bytes)
ssl_tls.c:1210: |3| 0000: 96 d8 56 74 51 6e a0 79 fd c8 60 b7 8d e6 37 a4 …VtQn.y…`…7.
ssl_tls.c:1210: |3| 0010: 00 6a c7 8e 75 0a 17 a6 3a 6d 9f b9 8b 64 8b 5d .j…u…:m…d.]
ssl_tls.c:1211: |2| <= calc verify
ssl_cli.c:3350: |1| mbedtls_pk_sign() returned -34432 (-0x8680)
ssl_tls.c:8091: |2| <= handshake

We also used to get problem after client state:3, where alert with error 48 i.e. unknown_ca was being generated, but we could overcome it by setting hs_authmode as VERIFY_OPTIONAL.

Please access the config file here:
Config File

Any help in this regard will be highly appreciated.

Regards,
Kartik


Verification of the message MAC failed
(Ron Eldor) #2

Hi @kinani
Thank you fro reporting this!
From your description, it sounds to me that there is some sort of issue in 32-bit Big Endian architecture, probably in the rsa module.
This obviously requires further investigation.

We also used to get problem after client state:3, where alert with error 48 i.e. unknown_ca was being generated, but we could overcome it by setting hs_authmode as VERIFY_OPTIONAL.

This should be done for debug purposes only. This is not secure, as you are ignoring the certificate verification result.

Note that we aim to be multi platform and multi architecture, but issues may arise.

Does this reproduce with older versions of Mbed TLS, such as 2.7 LTS branch?
Does this reproduce with ECC based certificates?
Regards,
Mbed TLS Team member
Ron


(Kartik Inani) #3

Hi Ron,

Appreciate your quick response!
With some more debugging we figured some memory related problem in our OS Adaptation layer for the platform. Fixing that did complete the handshake without even setting hs_authmode to VERIFY_OPTIONAL. Thanks for the info.

Because of some performance concerns, we accept out of order packets from transport layer, which seems to generate a fatal alert saying bad_record_mac (20).
If we don’t do changes, system runs fine, but we need those changes to perform better. So, my question is whether we need MAC verification or can it be skipped. If yes, can you please guide how to go ahead.

Thanks,
Kartik


(Ron Eldor) #4

Hi Kartik,
In order to have a secure transport, the messages are encrypted and authenticated ( Depending on the ciphersuite negotiated )
Since the negotiated ciphersuite is TLS-RSA-WITH-AES-128-CBC-SHA, have you considered using an AEAD based ciphersuite?
Does your platform have HW acceleration?

Regards,
Ron


(Kartik Inani) #5

Ron,

We forced this ciphersuite thinking it will take lesser processing (due to machine’s performance constraints).
So what we want is a ciphersuite which allows us to have out-of-order transport packets and still be low on computations. Also, our platform doesn’t support hardware accelerations. Can we configure mbedtls to do this?

Thanks,
Kartik


(Ron Eldor) #6

Hi Kartik,

AEAD based ciphersuites are better in terms of security. Have you tried other ciphersuites?
Have you tried ECP based ciphersuites instead of RSA ones, as this reduces the key size with similar security strength?

Also, our platform doesn’t support hardware accelerations. Can we configure mbedtls to do this?

You can configure Mbed TLS to use alternative implementations, as described in this article, however you will need a hw accelerator in your target.
Regards


(Kartik Inani) #7

Hi Ron,

Thanks for the quick response.
We did try TLS_RSA_WITH_AES_128_GCM_SHA256 but to no avail.
We don’t have much option but to use TLS-RSA-WITH-AES-128-CBC-SHA
ciphersuite.
For experimental purpose, can you please guide to disable the MAC verification through config or code.?


(Ron Eldor) #8

Hi Kartik,
Unfortunately, that is not really possible…
Part of the TLS ciphersuites is having the packets authinticated in some way, either by MAC or AEAD.
Even if we disbale on your peer the mac processing, the remote peer will still verify, and have MAC failed, sending you a fatal alert.

I should have asked this earlier, but are you negotiating a TLS or DTLS handshake?
Regards


(Kartik Inani) #9

Hi Ron,
Thanks for the insight.

We are negotiating a TLS handshake.

The handshake is successful but after some packets are successfully decrypted, we get -29056 (0x7180) i.e. Verification of the message MAC failed.
Let the remote peer verify the MAC, we just want to disable the MAC check at our end i.e. client end. Can you please let us know which part of code is responsible for MAC verification, disabling which could skip MAC verification.

Regards,
Kartik


(Ron Eldor) #10

Hi Martik,
For the benefit of the community, it is better to start a new thread if there is a new issue. Please don’t change subject, as it might confuse other users.

As you can see n ssl_tls.c in the function ssl_decrypt_buf, you will see the MAC calculated for your ciphersuite, however, if you want to disable MAC, you can disable TLS altogether, as you lose security.
If you are using TLS, you shouldn’t be getting out of order messages, and there is probably some internal issue causing you this error.
Have you tried looking at other related posts, for example:

Have you changed value of MBEDTLS_SSL_MAX_CONTENT_LEN or MBEDTLS_SSL_IN_CONTENT_LEN ?
If so, when the server sends you a message bigger than the value, and you are reading only the modified value, the calulated mac would differ between the two peers as well.

Please share the log of your client

Regards,
Mbed TLS Team member
Ron


(Kartik Inani) #11

Hi Ron,

Thanks for your timely help.

We were getting in-order packets from transport but we were splitting them in two threads and then giving to mbedTLS, may be that caused the issue. Sending them in single thread context works fine.

Thanks,
Kartik


(Ron Eldor) #12

Hi Kartik,
I am glad you resolved your issue.
If you are considering multi-threading, I suggest you read https://tls.mbed.org/kb/development/thread-safety-and-multi-threading and define MBEDTLS_THREADING_C in your platform.
Regards,
Ron