Encrypted multicast

[anyc]

Hello,

I have a network with multiple nodes and I have to send the same data or file to each of them, e.g., a firmware update. I am currently evaluating CoAP (+DTLS) for the "regular" data exchange and I wonder how I could transfer also short data or files using multicast. I understand that DTLS and multicast is not possible. Do you have an idea how (lib)CoAP could help here or would I have to simply handle all the encryption/signatures myself in the CoAP payload?

Simply encrypting CoAP packets using an own session PSK (that is distributed, e.g., using regular CoAP+DTLS at startup) would already help here, I think. Would the CoAP message id already suffice as replay protection in such a case? Is this something libcoap could do in the future or do you think this would be out of scope or a bad idea in general?

Thank you!

[mrdeep1]

Interesting question, not sure that it has properly been solved.

Part of the challenge here is that if the data / file information does not fit into a single packet, then following the current CoAP RFCs, the second and subsequent packets needed to transfer the remainder of the data have to be done using Unicast.

It maybe that you need to consider using Group OSCORE to do the encryption rather than DTLS. This is not currently supported by libcoap (no plans) see I-D.ietf-core-oscore-groupcomm possibly using a mechanism as described in I-D.ietf-core-observe-multicast-notification

[boaks]

For DTLS:
The handshake is used to authenticate each peer and to setup the keys to be used for the application data records. For two peers that results in in two "read/write" keys (peer 1: write key a / read key b, peer 2: write key b, read key a), used for symmetric encryption and decryption of application data records. If one peer decrypts an application data records with it's read key successfully (MAC is valid, e.g. peer 2 with key a), then the peer knows, that the message was crafted by a peer (peer 1 with key a), which used the other key for "writing". Assuming two peers, that's then the other peer (normal), or the same peer (not normal, but you will only able the cozenage yourself), or someone, who successfully hacked one of the peers.
If you now try to setup something similar (with symmetric encryption) for a group, one upcoming topic will be, the receiver will be able to decrypt the message with it's read key, but the scope of the verification has changed: it's now not only the other peer, which know that key, all other members of the group will also know that key in order to decrypt that message. If an other peer of the group misuse its read key and writes a message to the group, then a receiver will not be able to verify the sender using the MAC. You may then rely on the ip address or other data, but the original trust in the communication of DTLS used with two peers doesn't apply.
So, at least, when the same encryption schemes of (D)TLS are used, in a group you will not longer be sure, which group member has sent the message.