Credman_credential_t in DTLS sock API Documentaion and DTLS-SOCK example

Help
1

Hi,… I have been trying to understand the dtls_sock api and i want to use ecc keys for credentials.In the following section, credential0 and credetintial1 refers to credentials after enabling CONFIG_DTLS_ECC in DTLS-SOCK example.

a.) In the DTLS sock API Documentaion in Adding credentials section,I could see that ecc_credential contains key pair of server as well as public key of the client in .client_keys . So the credman_credential_t ecc_credential contains public keys if both server and client .

b.) But in the DTLS Sock example,client uses credman_credential_t credential0 and server uses credman_credential_t credential1 . For eg, credential1 in server code contains key pair of the server and the same public key of server is again stored in client_key.Similarly in client code, credential0 contains key pair of client and client_key contains public key of the client itself.

  1. Could someone please explain why there is this difference in storing credentials in documentation and example ?

  2. As per my understanding(please correct if I am wrong),after the dtls handshake,public keys are exchanged between peers.I could see the key exchange after enabling CONFIG_DTLS_DEBUG.So do we even need to store/hardcode client_key (public key of the other peer) in the credman_credential_t structure in code ?

2

Hi @ad6sh,

  1. The example originally had only one key pair, and that pair was used for both the server and the client (I’m guessing just for simplicity, this should of course not be done). The difference you point out, why the server registers two RPK keys is to show the functionality of the RPK callback function, which forces -as you pointed out- to use credential1 (SOCK_DTLS_SERVER_TAG_1). I agree that having different credentials in credential1->client_keys than the ones in the client is a bit off. It would be clearer to just use the sames as in credential0, so we can change this. It actually does not change the behaviour though, because of what I explain bellow.

  2. In the current implementation it is a bit nonsense, but just because the contrib code for tinydtls package is actually not verifying the peer public key (see here). IMO this should be extended (perhaps via callbacks as well) to actually verify that the public key received during the handshake is actually the one that we have stored in credman.

1 Like
3

Hi @leandrolanzieri ,thanks for the heads up :grinning: . Now I understand it properly.

  1. Could you also tell me,if the CONFIG_DTLS_PSK works properly if I enable it in DTLS_SOCK example ? Or is it also missing some implementation ?

  2. If I want to use ecc for encryption,should I go for something like DTLS-WolfSSL ?

  3. I could see GCOAP_DTLS using DTLS for encryption. Both ecc and psk parameters are defined in tinydtls_keys.h.But the sample uses only PSK. Is this also because public key verification is not yet implemented in tinydtls ?

4

Hi @ad6sh,

  1. Using both (Raw Public Keys and Pre-Shared Keys) work on the dtls-sock example application. If you do not set a cipher suite PSK is used by default. But setting CONFIG_DTLS_PSK should have the same effect.

  2. Do you mean for something else than DTLS? For ECC keys you can still use tinyDTLS, you will just not have the verification of the peer public key. If you want to go with WolfSSL, there was a PR that started implementing SockDTLS with the package https://github.com/RIOT-OS/RIOT/pull/15698. I’m not sure whether key verification was implemented on that one.

    If you mean performing ECC operations in general, RIOT supports some crypto libraries, including micro-ECC.

  3. I was not deeply involved in the addition of DTLS to gcoap, but I believe it should work the same with RPK. tinydtls_keys.h was just copied around for simplicity probably.

    Gcoap documentation does not mention any limitation as to the type of keys to use, it just requires that it is registered in credman.

1 Like
5

Thanks for the quick reply…I will try to use tinyDTLS for my application

6

Hello, nobody has integrated this feature yet? I think it would be interesting to add it and explain that ‘not verifying the peer public key’ is not recommended. I did it on my project, maybe I can open a PR?

7

Hi @LizzieDE110, here’s the PR that implements the verification if you wanna take a look: net/sock_dtls: add public key verification by leandrolanzieri · Pull Request #20048 · RIOT-OS/RIOT · GitHub