Logs and rules backend plan

Participants

Broker

a MQTT broker using SSL. A good candidate is rmqtt, since it has:

• webhooks to autid who connects to the broker
• HTTP auth support to dynamically enable gates

Device

the gate

Web UI

the web backend to see logs and update rules

Auth Backend

a backend (which may or may not be the same as Web UI) to handle gate MQTT authentication

Connection

sequenceDiagram
    participant D as Device
    participant B as Broker
    participant S as Web UI
    participant A as Auth Backend
    S->>B: Subscribe to /announce for new announcements
    S->>B: Subscribe to /logs
    D->>B: Publish to /announce/gate
    S->>A: Create account for new gate
    critical Reconnect to Broker with credentials
    D->>B: Login
    B->>A: Check credentials
    A->>D: Auth success
    end
    activate D
    D->>B: Publish logs to topic
    D->>B: Subscribe to rules update
    S->>B: Publish new rules
    deactivate D

Use DNS discovery to find broker

TODO Should we save the mqtt broker address to flash?

IMO yes, we should.

Connect without credentials, publish to topic /announce/gate

Announce new gate payload

    {
        "id": 1,
        "key": "base64 encoded public key"
    }

Backend creates new account deriving password from key

We could mix the current timestamp in the password to have a “rolling” password, but it may be more trouble than it’s worth.

Device does the same and authenticates to MQTT Broker

Device publishes logs

    {
        "id": 1,
        "log": "Something happened"
        "severity": "info"
    }
    {
        "signature": "base64 signature of previous object"
    }

Open points

TODO We need sNTP on the gates

TODO SSL Certificate pinning of broker

TODO should we structure logging more?

TODO How should we do rules signing?

Option A: rules get passed to the keymaker, which signs them and return the signature

this makes updating the rules cumbersome

Option B: keymaker delegates rules signing to the backend

This implies we have some kind of CA-like structure, but this can get complex really fast

Option C: compromise between the two

We specify another key during gate rollout (or even during the first registration) which will be used to check rules signature

Option D: Just use MQTT

assume MQTT will not get breached and trust that only the backend can publish to the rules topic (of course the proper ACL needs to be set up)