Dtls #18
Dtls #18
Conversation
reference to gcoap: add DTLS integration #12104
| url = [email protected]:seojeongmoon/RIOT.git | ||
| branch = dtls |
There was a problem hiding this comment.
You verified, that the changes you made in this RIOT fork, are merged into the RIOT upstream; do I remember this correctly? So we wouldn’t need to change this submodule, correct?
There was a problem hiding this comment.
Yes, as long as the upstream is updated it is fine.
| * @brief tlsman test application (PSK and ECC keys) | ||
| * | ||
| * Small test for TLSMAN. Many definitions defined here are also available at | ||
| * sock_secure (and are intended to be used in standard applications) |
There was a problem hiding this comment.
This file is originally meant to be a test. What do we use it for? To define the constants below?
There was a problem hiding this comment.
Yes, the keys are defined.
| 0x43, 0x21, 0x43, 0x5B, 0x7A, 0x80, 0xE7, 0x14, | ||
| 0x89, 0x6A, 0x33, 0xBB, 0xAD, 0x72, 0x94, 0xCA, | ||
| 0x40, 0x14, 0x55, 0xA1, 0x94, 0xA9, 0x49, 0xFA | ||
| }; |
There was a problem hiding this comment.
Maybe I don’t know / understand enough about DTLS in RIOT. But it doesn’t feel secure to hard code a private key in a public repository. Is this meant to be used that way?
There was a problem hiding this comment.
You are right. This is an example code. When we use it, we should replace with our own keys. (using special random generator for cryptography)
| extern const unsigned char ecdsa_pub_key_y[]; | ||
| #endif /* DTLS_ECC */ | ||
| #endif /* MODULE_SOCK_DTLS */ | ||
|
|
There was a problem hiding this comment.
Just some minor code ordering issue: It suggest to move this up a bit. So that all included files are visible in the same spot.
There was a problem hiding this comment.
I think that won't be a problem
|
|
||
| /* tell gcoap with tag to use */ | ||
| gcoap_set_credential_tag(SOCK_DTLS_GCOAP_TAG); | ||
| #endif |
There was a problem hiding this comment.
Thinking about the usage of this repository, I have some thoughts:
-
We would need a bit of documentation, to explain at least, how
DTLS_PSKandDTLS_ECCdiffer. Maybe pointing to different resources. -
Securing the network communication would be great. But in our context, I would prioritize compatibility with other groups (the web application or other nodes). Could you find out, what they would need to do, to support DTLS on their side? Maybe point to some documentation, as well.
-
More fundamental question: should we do this in our repository? I imagine, that this is part of a bigger system and is combined with other projects. What if this system combines two coap projects with DTLS configuration? Would this work? Or should the systems
main.chandle the encryption on its own?
There was a problem hiding this comment.
-
I asked the guy(pokgak), he said ECC is too slow on hardware so we should use PSK.
-
If they use the latest RIOT version that merged the pull request of pokgak, then it wouldn't be a problem. If not, that would be impossible because both communicators must have dtls.
-
Yes that is a good point. I was thinking about it too. I think we can have two branches, one with DTLS and one without and use one without first. It is good but I would prioritize everything working over security right now :)
There was a problem hiding this comment.
If you create a dtls branch, then I will pull request to that branch.
There was a problem hiding this comment.
There it is: https://github.com/rosetree/riot-saul-coap/tree/dtls
update RIOT submodule to include DTLS patches
I changed the code to encrypt the messages, but my version saul_coap is behind yours.