Robot-Market/mqtt-security-test
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Show the sequence diagrams as pre-rendered SVG images

Browse Source 
GoLand and Typora fail to draw the Mermaid sequence diagrams even though
the same text renders on the Mermaid versions they bundle. Embed SVGs
rendered with Mermaid 11.16.1 (white background) and keep the Mermaid
source in a collapsed section under each image.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This commit is contained in:
Ryan
2026-10-25 11:12:44 +03:30
co-authored by Claude Sonnet 5.5
parent 914e156b62
commit d408e53755
7 changed files with 35 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/enrollment-and-activation.md
+18
View File
@@ -39,6 +39,10 @@ Mosquitto does **not** require passwords: with `allow_anonymous true` on a dedic
Only the backend may subscribe to `enroll/request/+`. Devices cannot publish to response topics.
![Stage 0 enrollment sequence diagram](diagrams/stage0-enrollment.svg)
<details><summary>Mermaid source of this diagram</summary>
```mermaid
sequenceDiagram
participant B as Board
@@ -57,6 +61,8 @@ sequenceDiagram
B->>M: reconnect as FN / pw
```
</details>
- `sig` = Ed25519 signature by the backend over `S`, `B`, `n1`, and the Client ID. It stops a man in the middle from substituting their own key.
- The password is never transmitted. First successful FN login is the enrollment acknowledgement.
- Plaintext passwords are never stored; Dynamic Security keeps a hash, so re-issue means rotate.
@@ -88,6 +94,10 @@ The database is authoritative for ownership. A successful broker command alone d
The board's credential is created once at enrollment and never changes. Activation only changes which roles the FN client holds.
![Model A activation sequence diagram](diagrams/model-a-activation.svg)
<details><summary>Mermaid source of this diagram</summary>
```mermaid
sequenceDiagram
participant O as Operator
@@ -103,6 +113,8 @@ sequenceDiagram
B->>M: use device/[SN]/... topics
```
</details>
- **Roles:** one assignment role per machine, `machine-<SN>`, with **literal** topics such as `device/SN000123/sales/report`. `%u` cannot express the SN here because the username is the FN. Plus shared capability roles (`vending`, `news`, `updates`).
- **Backend** subscribes with wildcards (`device/+/...`), takes the SN from the topic, and checks in the database that this SN is assigned to the publishing board.
- **Replacing a board for SN000123:** disable and kick `FN-old`, remove its roles; the new board enrolls as a new FN; activation attaches `machine-SN000123` to the new FN. The role's ACL text is unchanged; only which client holds it changes.
@@ -112,6 +124,10 @@ sequenceDiagram
At activation the board gets a second, machine-level broker identity. The same X25519 exchange is reused.
![Model B activation sequence diagram](diagrams/model-b-activation.svg)
<details><summary>Mermaid source of this diagram</summary>
```mermaid
sequenceDiagram
participant O as Operator
@@ -130,6 +146,8 @@ sequenceDiagram
G->>M: disable FN client (or keep for rescue / re-enrollment)
```
</details>
- **One shared role** `vending-device` with `device/%u/...`, because the username equals the SN in the topic.
- Use a **fresh** keypair on the board at each activation, not the enrollment one.
- **Bind the SN client's Client ID** to the current board (for example its FN) with `setClientId`, if the deployed version supports it. A copied SN password is then useless from any other device, and the binding is readable with `getClient`.