Authenticated and encrypted radio communications (Non-Internet or TCP/IP) 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:


Authenticated. Only the owner of the system should be able to control the lights. 
Confidential. Someone listening should not be able to deduce usage patterns such as when people turn the lights off when leaving the building. 
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:


There is one server "hub" with several client "nodes". 
Peer-to-peer is not necessary, nodes talk only to the hub. 
Connections are unreliable. I plan to use the RadioHead library which does offer "reliable datagrams", but this may not be appropriate for all cases. 
The server is configured to "know" the nodes, so can have a pre-shared public key for each. 
Each node is configured to "know" the server, so likewise can have a pre-shared public key for the server. 
There is no mesh or routing, the nodes can and must always be one hop from the hub. 
Packets will never be fragmented. I don't know yet what the size limit will be, but I do not plan to support fragmentation. 
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.
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.