@eystein Sry for the late answer but I had to work on other projects last month.
This will be based on our C-based mender client, yes.(We just did final reviews and cleanups, so you can expect the release soon)
We thought a lot about doing OTA over WiFi-Mesh and how this can be done both secure and efficient at the same time.
We also don’t want to trust the root node anymore because the risk of that getting compromised is too high(also, anyone in the mesh can become root node, there’s no dedicated hardware).
This is our new concept-draft:
We’re planning to use a DTLS-encrypted MQTT-SN connection for our cloud-connection which allows us to have end-to-end encryption between the mesh-nodes and a mqtt-sn gateway which decrypts and forwards all traffic to our mqtt-broker. This means that the root-node acts as a proxy and never sees plain text traffic.
This means that the only thing that has to be changed in the mender-server is adding support for a MQTT device API which would also make this change apply to more use-cases.
Mender would connect to a MQTT-broker and create a /mender topic with the sub-topics reflecting the existing API-URLs. e.g:
Besides of normal request data each request additionally will receive the client-id(e.g. the mac or a CN) and a response-topic where it has to send the result of the request to, e.g.:
each client would subscribe to “/mender/responses/DEVICEID/*” to receive responses.
So there are two things that have to be done in the mender-server:
- there needs to be a mqtt-client which connects to a broker to wait for and answer client requests. There doesn’t have to be any device-authentication because the broker can and should be trusted and the devices already authenticated themselves to the broker. Since the communication between mender and the broker should be secured(either through TLS or because they’re the same server and use local-only communication) it’s still safe and doesn’t require additional device-permissions like the previous concept
- I didn’t take a close look at the code of menders device API implementation yet but ideally we’d be able have both HTTP and MQTT APIs end up in the same request handlers(that’s why we chose to use the existing URL structure as our MQTT topics). In case the request handlers currently are too HTTP-specific we need more abstraction there. Also the device-authentication would have to be HTTP-only. MQTT devices will never make the auth call or request a token.
About the combined-update optimization, this is our current idea:
- the mesh nodes will receive an update URL via the usual API.
- they tell the root node that they want to receive an update from that URL
- the root node waits some time(e.g. 1h) to collect as many clients who want an update as possible
- the root-node creates groups of devices with the same URL and starts downloading and streaming them to the devices.
At that point the clients can keep using the mqtt-api to update their deployment status.
This way is only safe for devices with secure-boot. A root node could still stream modified updates, but the clients would never boot them due to invalid secure-boot signatures.