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.