5
$\begingroup$

I'm working on an IoT project that will control lights and eventually other devices (I know there's plenty of projects like this, but that's not the topic here).

Primarily communications will take place over a 900 MHz band radio, probably through an RFM69 type module, or perhaps LoRa. (The radio type shouldn't really matter, just that it will be low bitrate). The MCU will likely be an ESP8266, so only an 80 MHz clock.

Since I care about this being a useful and secure system, I clearly need some security protocol. If it were WiFi and IP based, of course this could be TCP - but that is not as suitable in this case.

I'm looking for something that will provide these features:

  1. Authenticated. Only the owner of the system should be able to control the lights.
  2. Confidential. Someone listening should not be able to deduce usage patterns such as when people turn the lights off when leaving the building.
  3. Replay protected. If someone does observe a control message they must not be able to use that again.

Given the nature of the system, it has these constraints and parameters:

  1. There is one server "hub" with several client "nodes".
  2. Peer-to-peer is not necessary, nodes talk only to the hub.
  3. Connections are unreliable. I plan to use the RadioHead library which does offer "reliable datagrams", but this may not be appropriate for all cases.
  4. The server is configured to "know" the nodes, so can have a pre-shared public key for each.
  5. Each node is configured to "know" the server, so likewise can have a pre-shared public key for the server.
  6. There is no mesh or routing, the nodes can and must always be one hop from the hub.
  7. Packets will never be fragmented. I don't know yet what the size limit will be, but I do not plan to support fragmentation.
  8. Broadcast messages from the hub must be received and decrypted by all nodes as close to the same time as possible (not individually sent).

I've done a fair bit of searching for something that would fit this bill, but so far have come up short. This is what I've considered so far:

  • PSK Ciphersuites for TLS (RFC 4279): PSK is better than X.509 for small processors, but it still uses RSA, AES and SHA algorithms. I would prefer something that could use something like Ed25519, Speck, Blake from the ArduinoLibs crypto library. Also, it's TLS so each client-server connection has a different key and so a true "broadcast" doesn't work.
  • Datagram Transport Layer Security (DTLS) (RFC 6347): Haven't read as much into this, but seems to be closer to what I'd need. But, still includes a lot of overhead like re-ordering etc that I won't need, no message can be out of order because there is no routing, only direct radio link.
  • CurveCP: Seems to be optimised to fit into a small processor, but aims to be like TLS which again includes overhead I don't need for a single hop link.

What else exists for what I'm trying to do? I have some ideas of how I might make my own solution to this, but "roll your own crypto" is always advised against and not something I'd like to take on if I don't have to.

Improve this question
$\endgroup$
9
  • 1
    $\begingroup$ You really shouldn't be asking on multiple sites. That is against SE policy. $\endgroup$
    – mikeazo
    Aug 10, 2017 at 12:29
  • $\begingroup$ It was suggested in the EE.SE question that I should ask here instead. Should I delete the other question? $\endgroup$
    – seanlano
    Aug 10, 2017 at 14:04
  • $\begingroup$ Typically the best thing to do when you want to move from one site to another is to flag a question for moderator attention and ask them to migrate it. That preserves a link between both sites. I'd just wait for a few days and see what happens at this point, though. $\endgroup$
    – mikeazo
    Aug 10, 2017 at 14:13
  • $\begingroup$ Ah, fair enough. I didn't realise that was the process. OK, well let's see what happens. $\endgroup$
    – seanlano
    Aug 10, 2017 at 14:19
  • 2
    $\begingroup$ Public-key cryptography has little advantage in this setup, but brings lots of performance issues. With ability to securely inject a key in slave devices, and slave devices tailored to a single central server, you could use secret-key cryptography. $\endgroup$
    – fgrieu ♦
    Aug 11, 2017 at 11:19

2 Answers 2

Reset to default
1
$\begingroup$

Public-key cryptography has only one advantage in the topology of the question (central server): it allows initial setup across a channel assumed secure from an integrity standpoint only (rather than also confidentiality). But public-key cryptography comes with complexity and performance issues; assuming ability to securely inject a secret key in slave devices, and the slave devices tailored to a single central server, plain old secret-key cryptography seems a good choice.

That would be with a master secret key in the central server, with each slave device assigned an ID and a "diversified" secret key derived from the master secret key and device ID, using some Key Derivation Function (HMAC will do nicely). These long-term keys can then be used to derive session keys, much like long-term public/private key pairs are used to derive session keys. Upon initiating communication with a device giving its ID, the central server can quickly find the slave device's secret key, by applying the KDF.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Yeah this sounds like the way to go. I don't suppose there's an existing algorithm or specification that does something like this? I obviously would be using existing primitives, but I'll try to avoid reinventing the wheel if there's something like this out there. $\endgroup$
    – seanlano
    Aug 12, 2017 at 2:44
0
$\begingroup$

If you want public key crypto to allow simpler provisioning of devices you should consider that this step has to be performed only once or very rarely.

In other words, even if public key crypto is expensive and calculating a shared secret takes a minute it might not be an issue because it is a one-time cost!

This should allow you to relax your constraints for that part of the communication.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.