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

Use plain Mermaid diagrams again and drop the SVG images

Browse Source 
The preview problems were caused by the diagram text, which is now fixed in
every copy, so the pre-rendered SVGs (white background, harder to keep in
sync) are no longer needed. Also updates docker/docs with the fixed text.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This commit is contained in:
Ryan
2026-10-25 11:31:29 +03:30
co-authored by Claude Sonnet 5.5
parent c1fcfb7b73
commit 20d69b93b7
10 changed files with 30 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/enrollment-and-activation.md
-18
View File
@@ -39,10 +39,6 @@ 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
@@ -61,8 +57,6 @@ 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.
@@ -94,10 +88,6 @@ 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
@@ -113,8 +103,6 @@ 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.
@@ -124,10 +112,6 @@ 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
@@ -146,8 +130,6 @@ 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`.