1

We are working on connecting mesh nodes to Amazon Web Services. Mesh nodes are by nature constrained devices and we can't afford to run MQTT on those nodes directly (TCP is too expensive)

Our approach would be to use CoAP for the mesh but it would be ideal if we could connect those nodes directly to AWS for security reasons and nodes management from the cloud.

AWS supports HTTP but not CoAP directly. From what we have gathered, CoAP is very similar to HTTP. It also uses similar security mechanism (DTLS vs TLS).

Has anyone tried this? Is it possible that a simple CoAP to HTTP proxy would be capable of maintaining a securied session between CoAP device and HTTP broker on AWS?

radaudio
  • 35
  • 1
  • 8

2 Answers2

3

Unfortunately I can't tell anything about proxies (except that the approach seems somewhat clunky at first view).

But before that, can you afford DTLS on your mesh nodes?
For example, you will need a good and fast random source. Every handshake will require to generate a 32-byte random "cookie".

Assume we use pre-shared keys and AES128 with CCM8 (since where could be no point to use something more simple):
Every CoAP packet will be encrypted and extended to:
DTLS header: 13 bytes
Nonce: 16 bytes

Also you will need to store a few packets during a handshake (I can't tell the exact size but I suppose it is hundreds of bytes).

Anyway, it depends on that security level do you want to get.

eugene-nikolaev
  • 1,290
  • 1
  • 13
  • 21
  • Thanks. We will have to check if that overhead is acceptable. In the meantime - can you maybe suggest a good approach to approach this? Ideally there would be End to End security based on a pre-shared keys. I guess that means running encryption on the mesh node, but it should be OK. Are there any protocols better suited for this application? – radaudio Jan 03 '18 at 12:52
  • Unfortunately, I guess this is the main reason that we have no strong crypto in IoT products out there at most. I, personally, would like to know any suitable approach which is more lightweight but strong enough too :). I saw some efforts to make it but they didn't go too far from a paper. There are some relatively cheap ARMs though which have enough memory and true RNG. https://stackoverflow.com/a/26306497/3323777 Though I didn't manage to start digging it yet. – eugene-nikolaev Jan 04 '18 at 12:10
  • This is very interesting. Few radio chips suitable support hardware TRNG (like TI CC1350 or Nordic nrf52840, etc.). – radaudio Jan 05 '18 at 15:04
  • @radaudio, How are you going to connect those devices to web? I’ve heard there are some cell modems/operators which could provide operating via VPN. Though I can’t tell which exactly. And it depends on country, etc. It could eliminate a DTLS requirement if you have control over that. Also, there are some other ways to get random at MCU (different time shifts via multiple timers, reading uninitialized memory and using it as a random seed, etc). But I don’t realle like them apriori. Also please feel free to vote up an answer if you found it interesting ;) – eugene-nikolaev Jan 06 '18 at 09:23
  • Devices would go through a gateway but to simplify and make the solution more robust it would be great if it could be just a simple router. This implies no secrets stored on the gateway. As far as I understand using VPN would require decrypting mesh payload and putting in on the VPN. – radaudio Jan 09 '18 at 10:02
1

A cross-proxy definition already exists in the CoAP specification CoAP specification, RFC7252, Section 10

The open source project Eclipse/Californium contains such a proxy implementation. See Proxy 2, README, for more details.

Community
  • 1
  • 1
Achim Kraus
  • 729
  • 1
  • 7
  • 11