DTLS PSK Handshake Failure on nRF9151 DK

[JOEBRE]

7762.wireshark_trace_clienthello_only_scsv.pcapng

Summary

We are trying to perform a DTLS 1.2 handshake using PSK (Pre-Shared Key)
from an **nRF9151 module running NCS v3.0.2, using modem-offloaded DTLS (IPPROTO_DTLS_1_2).

• LTE connects successfully
• PSK Identity + Key are provisioned to security tag 42
• The socket is configured with `TLS_SEC_TAG_LIST` and `TLS_PEER_VERIFY_NONE`
• DTLS handshake always fails with `errno = 111` (`ECONNREFUSED`)
• Wireshark trace shows the modem sends a DTLS ClientHello containing only: that means no usable cipher suites get advertised.

Expected Behavior

The client should send a DTLS ClientHello advertising PSK cipher suites such as:

• - `TLS_PSK_WITH_AES_128_CCM_8`
• - `TLS_PSK_WITH_AES_128_CCM`

And the server should reply with ServerHello → PSK Key Exchange.

This works correctly using:
 OpenSSL-based client  
 Go client (Pion/dtls)  
 Fails only with the nRF91 modem-based DTLS client

Actual Behavior

• Although PSK identity and key are provisioned correctly inside the modem, the ClientHello sent by the nRF9151 does not include any PSK cipher suite (e.g., TLS_PSK_WITH_AES_128_CCM_8). Instead, it offers only ECDHE-based certificate cipher suites followed by TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00FF). As a result, the DTLS handshake fails with no shared cipher suite.
• Server (Go or OpenSSL) rejects handshake
• Client receives errno=111.

Files Included

| File | Description |
|------|-------------|
| `main.c` | Full C source used on nRF9151 |
| `prj.conf` | Project configuration |
| `wireshark_trace_clienthello_only_scsv.pcapng` | Modem trace export |
| `server_log.txt` | Output from Go/openssl servers (no shared cipher) |


Test with OpenSSL

> openssl s_server -dtls -accept 5684 -nocert -psk 73757065727365637265746b6579313233 -psk_identity device001 -cipher "PSK-AES128-CCM8:PSK-AES128-CCM:PSK-AES128-CBC-HA"
Returns:

Using default temp DH parameters
ACCEPT
ERROR
4057EA2E827B0000:error:0A0000C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2220:
shutting down SSL
CONNECTION CLOSED

PSK Used

Identity: device001
Key: supersecretkey123
Confirmed stored under SEC_TAG=42.

Questions to Nordic

Why does modem DTLS not include PSK ciphers in ClientHello?

Is IPPROTO_DTLS_1_2 + TLS_SEC_TAG_LIST enough to enable PSK?

Do we need to explicitly set TLS_DTLS_VERSION, TLS_CIPHERSUITE_LIST, or something undocumented?

Is this a known issue in nRF9151 modem firmware v1.x?

Can you help me to get the DTLS handshake complete with success?

In the final product, the DTLS stuff must coexist with the LwM2M (which I already successfully tested 0m nRF9161 platform using Eclipse Leshan together with lwm2m client sample) one on nRF9151.

Thank you in advance for your support!

[Achim Kraus]

Cannot connect to LwM2M server with X509 DTLS. Wireshark shows empty client certificate.

That's the vice versa. It doesn't work, if certificate and PSK credentials are mixed into one sec_tag.

You may check, if that applies with

AT%CMNG=1,42

If that show's more than your PSK credentials, remove the others.

[JOEBRE]

Hello,  AT%%CMNG=1,42 returned:

42,3,"A4E05CEFA49CFFE2BB25E5E0793625C1199CB4ED83FF1B155BD6591EB043E9F1"

42,4,"54CCD4B043ECEC38BFB890596F7BD99FC8E6058517882A75F3BF37B9475972A1"

Which are the result of:

    modem_key_mgmt_write(SEC_TAG, MODEM_KEY_MGMT_CRED_TYPE_IDENTITY,

                         PSK_ID, strlen(PSK_ID));

    modem_key_mgmt_write(SEC_TAG, MODEM_KEY_MGMT_CRED_TYPE_PSK,

                         PSK_KEY, strlen(PSK_KEY));

So no other credentials than PSK ID and KEY. To be 100% sure the right stuff is injected into the modem now always delete all credentials for tag 42 and then re-enter them using modem_key_mgmt_write.

*** Booting nRF Connect SDK v3.0.2-89ba1294ac9b ***
*** Using Zephyr OS v4.0.99-f791c49f492c ***
[00:00:00.388,000] <inf> main: === LTE + DTLS Handshake Test ===
[00:00:00.388,000] <inf> main: Client PSK Key (ASCII) hex:
73 75 70 65 72 73 65 63 72 65 74 6B 65 79 31 32 33 
[00:00:00.388,336] <inf> main: Initializing modem...
[00:00:00.646,270] <inf> nrf_modem_lib_trace: Trace thread ready
[00:00:00.648,071] <inf> nrf_modem_lib_trace: Trace level override: 2
[00:00:00.792,694] <inf> main: Set CFUN to 0 to reset the SIM: OK

[00:00:03.031,860] <inf> main: Cleared credentials type 3 fotr Tag 42
[00:00:03.136,932] <inf> main: Cleared credentials type 4 fotr Tag 42
[00:00:03.260,986] <inf> main: Credentials of Tag 42 are wiped
[00:00:03.261,016] <inf> main: Provisioning  Tag 42 with new credentials
[00:00:03.474,914] <inf> main: New credentials for Tag 42 -> ID:1 PSK:1
[00:00:06.546,813] <inf> main: Connecting LTE...
+CEREG: 1,"057D","01017406",7,,,"00001111","00101101"
[00:00:07.181,976] main:  LTE connected!
[00:00:07.375,427] <inf> main: Connecting to GIMSServer.mooo.com (84.55.253.71):5684
[00:00:07.375,732] <inf> main: Performing DTLS handshake with GIMSServer.mooo.com:5684...
[00:00:07.527,954] main:  DTLS handshake failed, errno=111

Nothing changed I still get errno=111.

[Achim Kraus]

Strange.

mbed_tls uses hex to pass in the secret to their demo-server, so that should work.

But the MAC error in the Finish indicates, that somehow different psk are used. At least, that's one of the sources for MAC errors of the Finish, and in my experience as committer in Eclipse/Californium, it's the very most common one. Anyway, agreed, here the cause may be different.

In general, I'm not aware of some interoperability issues in mbed_tls. In Eclipse/Californium I'm tracking that now for a couple of years. I use the ssl_server2, but I don't think, this makes a difference, If you like, provide your capture.

But though you're using other one's implementation, I think, also others may be more helpful ;-).

Edited: I had a short look at mbed_tls/programs/ssl/ssl_server, and now I have the feeling, that using ssl_server2 may make sense. But overall, that are questions to mbed_tls. 

[JOEBRE]

Same problem also with gnutls. Because of this, I think the problem is on nRF side... isn't it ?

The wiresark capture:

7870.dtls_handshake_capture.pcapng

Joel

[Achim Kraus]

The difference to using Californium seems to be the selected cipher suite. 

I'm currently too short at time, maybe I can spend some time next week to check it also with TLS-PSK-WITH-AES-128-CCM-8. 

(In my apps I don't use the DTLS support of the modem. I use Eclipse/tinydtls on the client and Eclipse/Californium on the server. Both are proactively developed by me and so I'm not aware of such issues.)

But maybe it's anyway time, that someone from Nordic jumps in.

[JOEBRE]

The problem has been resolved! The root cause of the problem was that  we entered the key in clear text on nRF9151.

We were using:  err = modem_key_mgmt_write(SEC_TAG, MODEM_KEY_MGMT_CRED_TYPE_PSK, "supersecretkey", //supersecretkey
strlen("supersecretkey"));

instead of:

err = modem_key_mgmt_write(SEC_TAG, MODEM_KEY_MGMT_CRED_TYPE_PSK, "73757065727365637265746B6579",
strlen("73757065727365637265746B6579"));

As soon as we entered the key in hex the DTLS handshake succeeded.

Thanks for the precious help!

Joel

[Achim Kraus]

Once more, in a decade, that it's the psk encoding ;-).