diff --git a/docs/roadmap.md b/docs/roadmap.md index 3141d5f..d1b4e19 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -38,11 +38,12 @@ These constraints apply across all phases: | 5B | Offline xterm.js WebSocket serial terminal | **Complete** | | 6 | Authenticated SSH serial transport | **Complete** | | 7 | Local display and button interface | **In progress (7E validation)** | -| 8 | Security and production hardening | **Planned** | -| 9 | Authenticated, rollback-capable OTA | **Planned** | -| 10 | BLE serial transport and provisioning evaluation | **Planned** | -| 11 | Advanced network integration | **Under evaluation** | -| 12 | Optional filesystem-backed features | **Under evaluation** | +| 8 | Role-based users and administrative access | **Planned** | +| 9 | Security and production hardening | **Planned** | +| 10 | Authenticated, rollback-capable OTA | **Planned** | +| 11 | BLE serial transport and provisioning evaluation | **Planned** | +| 12 | Advanced network integration | **Under evaluation** | +| 13 | Optional filesystem-backed features | **Under evaluation** | ## Completed foundation @@ -237,7 +238,34 @@ The persistent yellow strip uses fixed-position serial, Wi-Fi-strength, USB, Web Completion requires electrical validation on the selected module, correct operation with all current transports, bounded display/button failure behavior, safe action confirmation, no unexplained serial or broker loss, and documented UART0 recovery. -### Phase 8 — Security and production hardening +### Phase 8 — Role-based users and administrative access + +Replace the single shared network credential with a bounded, persistent user system. Accounts have one of two authorization roles: `user` receives the currently implemented authenticated serial/status experience, while `admin` additionally receives administrative command and user-management capabilities. UART0 remains the physical recovery and bootstrap authority. + +Implementation sequence: + +1. **Phase 8A — User database and UART0 administration — Planned** + - Add a versioned, fixed-capacity user database with at most eight accounts, unique lowercase usernames, `user`/`admin` roles, per-account generations, and an invariant that prevents deletion or demotion of the final administrator. + - Store salted password verifiers rather than recoverable passwords. Support bounded hidden password entry and one-time generated passwords through UART0 commands for add/delete, role changes, password changes, and account inspection. + - Permit up to three SSH public keys per account. UART0 imports bounded OpenSSH public-key lines and lists fingerprints without exposing password verifiers or raw secret material. + - Migrate the existing shared credential transactionally so network recovery is preserved across power loss; document that append-oriented unencrypted NVS cannot guarantee physical erasure of historical plaintext entries. +2. **Phase 8B — Role-aware HTTPS and SSH authentication — Planned** + - Authenticate HTTPS and SSH passwords through the common user database and retain a secret-free principal containing account ID, role, authentication method, and credential generation. + - Add SSH public-key authentication while retaining password authentication. wolfSSH authorizes the stored username/key pair and remains responsible for cryptographic signature verification; unsigned key probes never count as completed authentication. + - Bind WebSocket tickets and active SSH/WebSocket sessions to account generations so password, role, key, disable, or delete operations can revoke only the affected account. + - Preserve the current serial terminal, status, writer/observer behavior, and hidden administrative controls for normal `user` accounts. +3. **Phase 8C — SSH administrative shell — Planned** + - Route authenticated `admin` SSH shell sessions to the same registered administrative command set as UART0, without creating a broker client. Normal users continue to receive the existing broker-backed serial stream. + - Serialize command parsing safely because ESP-IDF console internals are process-global. Use bounded per-session input/output queues and a separate command worker; only the SSH owner task may call wolfSSH APIs. + - Keep SFTP, SCP, `exec`, forwarding, subsystems, and unauthenticated shells disabled. +4. **Phase 8D — Web user administration — Planned** + - Add an admin-only user-management interface and typed, bounded APIs for account CRUD, roles, password generation/change, SSH-key management, and revocation. Never expose a generic HTTP endpoint that executes arbitrary CLI text. + - Hide administrative navigation and controls for normal users, and enforce every authorization decision server-side so hidden UI is not treated as a security boundary. + - Preserve the existing normal terminal interface. Use strict origin/CSRF protections for mutations, secret-safe JSON encoding, one-time display of generated passwords, and no-store responses for administrative material. + +Completion requires migration and power-loss recovery tests, final-admin protection, malformed credential/key rejection, password and key login for both roles, targeted session revocation, concurrent normal/admin SSH operation, hidden and server-rejected user-level web administration, and continued UART0 recovery. + +### Phase 9 — Security and production hardening Harden stored credentials, boot integrity, update trust, failure diagnostics, and dependency maintenance. This phase must be staged carefully because some ESP32 eFuse operations are irreversible. @@ -257,7 +285,7 @@ Planned work: Security features must be validated first on expendable hardware before any irreversible production configuration is recommended. -### Phase 9 — Authenticated OTA and rollback +### Phase 10 — Authenticated OTA and rollback Use the existing dual 4 MiB application slots and `otadata` partition to add safe firmware updates. @@ -275,7 +303,7 @@ Planned work: OTA is complete only after successful update, interrupted-update, invalid-image, rollback, and configuration-persistence tests on hardware. -### Phase 10 — BLE +### Phase 11 — BLE Evaluate and, if resource limits permit, add BLE as another bounded transport or provisioning path. @@ -292,7 +320,7 @@ Planned work: BLE remains subordinate to stable Wi-Fi and serial operation; it should be omitted if coexistence or memory costs cannot be bounded acceptably. -### Phase 11 — Advanced network integration +### Phase 12 — Advanced network integration These features are candidates, not current commitments: @@ -303,7 +331,7 @@ These features are candidates, not current commitments: The device is not intended to become a general-purpose router. Captive-portal interception, unauthenticated DNS redirection, NAPT, and a plaintext serial listener remain out of scope unless the project requirements are explicitly revised. -### Phase 12 — Optional filesystem-backed features +### Phase 13 — Optional filesystem-backed features The `storage` partition is reserved but not currently mounted. Possible uses must be justified individually: @@ -338,7 +366,7 @@ The following are not implemented merely because flash partitions or library sup - OTA download, image confirmation, or rollback policy. - Core-dump collection or secret-safe core-dump processing. - Filesystem mounting. -- Public-key SSH user authentication. + - SFTP, SCP, SSH `exec`, forwarding, or subsystems. - General routing, NAPT, captive-portal interception, or unauthenticated serial access.