MQTT remote control

[ckuethe]

So I'm deploying a network of TTGOs (if you can call a few of these things at friends' places a network) and I'd like to use MQTT for telemetry and control since they're all behind NAT. I've got a few thoughts about this and before I get too far I figured I'd start a discussion about requirements and stuff.

Requirements

• MQTT commands SHALL be ignored unless a verifier key is set
• MQTT commands MUST have a valid ECDSA signature
• ECDSA keys MAY be initially provisioned over HTTP
• ECDSA keys SHALL NOT be modified over HTTP, only over USB (authorized by physical access) or MQTT (authorized by signed message).
• MQTT TLS client SHOULD validate the TLS certificate of the broker
• MQTT TLS client MUST support multiple valid certificate fingerprints to allow for broker certificate updates

Features

• command: reboot device
• command: trigger OTA update
• command: switch between scanner and spectrum analyzer
• command: fetch a full RF spectrum report, all however many bins are reported
• command: add/remove QRG entry
• command: add/remove wifi entry
• command: set arbitrary configuration element (eg. sondehub.antenna=J-Pole)
• command: download config file
• command: upload config file
• an example tool for generating keys and sending signed commands.

Prereqs

• Add TLS support to the MQTT subsystem. async-mqtt-client already supports this, so I need to add a control to use TLS
• Certificate verification. async-mqtt-client supports this too, so I need to add a control to verify certificates or allow any.
• Add other necessary dependencies to rdzttgosonde build. I think async-mqtt-client depends on axtls and I was thinking about using https://github.com/kmackay/micro-ecc to handle the ECDSA verification
• Add UI/config elements for the TLS fingerprint and ECDSA verifier key

[ckuethe]

tag @analogic because you added MQTT support in the first place.

[dl9rdz]

This sounds like a very interesting project.

TLS should be somewhat feasible in the new environment. In the past there simply was no space for a TLS library (with the default partitioning scheme) but after switching to the tasmoto version of the arduino-espressif environment (and moving the fonts out of the OTA code partitions) there is a bit of space left.

For a start I would suggest to keep this as an optional feature (in features.h) and maybe not (at least not initially) include it in the default build (We can discuss this later depending on how many users there are and the code size).

I am planning to add TLS based on mbed-tls (this might mean I will replace the current web server with a task running the default espressif web server, and mbed-tls is the default library used for that) for the integrated web server and possibly also for other parts, but have not specifically looked at the MQTT part for that. But surely using the same TLS library everywhere would be best.

I am not too optimistic that async-mqtt-client will work out nicely. Briefly looking at the code it seems that it does not support certificates at all, and some comments in the "limitations" are also not encouraging. "not supporting TLS 1.2" probably means that it supports only TLS 1.1 (see also marvinroger/async-mqtt-client#126), but that might be outdated (axtls suppurts v1.2 nowadays). But seems like axtls does not support anything beyond basic RSA, i.e. no ECDSA
Based in this discussion at https://forum.arduino.cc/t/mqtt-library-for-esp32-with-tls-non-blocking/1225427 I would assume that using the native espressif mqtt client (https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/protocols/mqtt.html) might be the better option (and a bit of more low level programming to run this in a separate RTOS task...)

But ECDSA is a rather hard challenge for the ESP32. The ESP32-H2 would have dedicated hardware for this task, but the usual ESP32 do not, a any EC calculation (signature verification) will easily take several 100ms, possibly > 1s...

[ckuethe]

While looking into ECDSA it appeared that https://github.com/kmackay/micro-ecc would be a good choice precisely because of the lack of dedicated EC accelerators devices like the TTGO. I'll have to benchmark the various PKI routines and if it's not too painful to check signatures using the RSA accelerator I'd switch to that.