nRF9160 modem_key_mgmt_cmp returns -1

[Ron Segal]

Am currently trying to implement a client UDP socket application with Mbed DTLS using a Pre Shared Key.

PSK and PSK_ID array values are defined as:

static const unsigned char psk[] = {0x01, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06,

0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f};

static const char psk_id[] = "Client_identity";

These are written to the nRF9160 with: 

err = modem_key_mgmt_write(PSK_TAG, MODEM_KEY_MGMT_CRED_TYPE_PSK, psk, sizeof(psk));

err = modem_key_mgmt_write(PSK_TAG, MODEM_KEY_MGMT_CRED_TYPE_IDENTITY, psk_id,sizeof(psk_id)-1);

PSK_TAG has been set to 2;

Then checking the validity of what has been written with:

err = modem_key_mgmt_cmp(PSK_TAG, MODEM_KEY_MGMT_CRED_TYPE_PSK, psk, sizeof(psk));

err = modem_key_mgmt_cmp(PSK_TAG, MODEM_KEY_MGMT_CRED_TYPE_IDENTITY, psk_id, sizeof(psk_id)-1);

The psk_id comparison returns a match (err == 0) whereas the psk comparison returns -1 (err = -1)

It's unclear what error is -1 (match failure is supposed to be +1) and how it can be resolved.

Ideas appreciated. 

Thanks. Cheers Ron.

[Achim Kraus]

> err = modem_key_mgmt_write(PSK_TAG, MODEM_KEY_MGMT_CRED_TYPE_PSK, psk, sizeof(psk));

I guess, this is not the way it must be set.

See Californium - Issue: Failed to connect using PSK

[Ron Segal]

Thanks Achim,

err = modem_key_mgmt_write(PSK_TAG, MODEM_KEY_MGMT_CRED_TYPE_PSK, psk, sizeof(psk));

works ok with a psk of e.g. static const char psk[] = "010102030405060708090a0b0c0d0e0f";

but not when it is defined as:  static const unsigned char psk[] = {0x01, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f};

Or at least the above string definition is working with a remote openssl s_server e.g.

openssl s_server -psk "010102030405060708090a0b0c0d0e0f" -psk_identity "Client_identity" -nocert -dtls1_2 -accept 9009 -async -msg

which receives dtls messages from an nrf9160dk board via NB-IoT with no problem.

Whereas a different udp server based on python-mbedtls returns a message MAC match failure that so far I've been unable to successfully diagnose. Whereas that same server receives messages from a python-mbedtls client (running on Ubuntu) with ostensibly the same psk and psk_id.

These discrepancies are causing me a lot of grief right now as our preferred target is the python-mbedtls dtls, psk server, for which it is difficult to diagnose why the MAC failure is happening. Suggestions appreciated. Cheers Ron.

[Achim Kraus]

> "010102030405060708090a0b0c0d0e0f"

that string is then the hexadecimal encoding, mentioned at the AT cmd.

Though the "modem_key_mgmt_write" passes it directly to that AT cmd, the parameter must be hexadecimal not binary.

Incompatibilities are frequently too hard to fix for users. I had to spend a lot of time into getting that working for Eclipse/Californium.

It depends on the use-case, but (too) many dtls implementations comes "always" with some downsides. That's a little disappointing. In my opinion (OK, I'm also one of the developers), Eclipse/Californium and Eclipse/tinyDtls does a very good job, especially with DTLS CID.

[Ron Segal]

Thanks again Achim,

That's a useful heads up regarding tinyDTLS.  Could be worth having a look at that as an alternative for the Linux based server. Californium is clearly well respected, but I've never been much of a Java developer.  Generally there seems to be a shortage of simple, proven dtls psk C based server examples. 

[Achim Kraus]

> Suggestions appreciated.

Sorry, I missed that.

This is mainly a wrong secret. Some implementation reports that as MAC error of the Finish message, other are just run into a timeout.

The root cause is the same as here: unclear, what must be provided. With that, chose a ASCII secret, e.g. "secret". Load the nRF9160 with the hexadecimal encoded secret ("736563726574") and try to use "secret" for the python server. If that doesn't work, try the hexadecimal. Or consider the python server documentation. (Base64 would be "c2VjcmV0").

[Ron Segal]

Apologies, attempted to reply much earlier Achim but login timed out and I lost the reply.

Anyway, your above suggestion with nRF9160 modem psk = "736563726574", using ascii hex codes for the string "secret", with the psk at the python-mbedtls server end being entered as the byte string b"secret" was successful!

Problem gratefully solved, thanks. Cheers Ron. 

[Achim Kraus]

You're welcome :-).

Even after years, it seems, that to "root cause" for PSK issues is still bad documentation ;-).