ESP32 как аппаратный кошелёк (device-сессия)

Суть фичи

ESP32 становится аппаратным HSM (hardware security module): хранит ключи, постоянно подключён к SHiNE-серверу как device-сессия, подтверждает операции нажатием на экране. Другие устройства (браузер, телефон) взаимодействуют с ESP32 через сервер — без прямого соединения.

Два ключевых сценария

Сценарий 1 — Создание делегированной сессии

Браузер/телефон → сервер: «хочу делегированную сессию от имени пользователя X»
Сервер → ESP32 (device-сессия): «запрос на одобрение»
Пользователь нажимает «Да» на сенсорном экране ESP32
ESP32 → сервер: одобрено → сервер создаёт делегированную сессию для браузера

Сценарий 2 — Подпись транзакции / блока

Браузер (через делегированную сессию) → сервер → ESP32: «подпиши вот это»
ESP32 показывает запрос на экране, пользователь подтверждает
ESP32 подписывает нужным ключом → ответ через сервер → браузер

Что нужно сделать

ESP32 (основная работа)

Инициализация WiFi (SSID/пароль в NVS)
WebSocket-клиент (WebSocketsClient) — постоянное соединение с сервером
Авторизация на сервере: AuthChallenge → CreateAuthSession через clientKey (уже есть в NVS), сохранить sessionId в NVS
Обработчик входящих WebSocket-событий: JSON-парсинг, диспетчер по типу
Новые UI-экраны: «Разрешить сессию?» и «Подписать?» с кнопками Да/Нет
Расширенное хранилище ключей в NVS (произвольные именованные ключи сверх базовых трёх)
Переподключение при разрыве (reconnect loop)

Сервер (минимальные изменения)

Добавить поле sessionType (USER / DEVICE) в таблицу active_sessions
Новая операция DeviceApprovalRequest — браузер запрашивает одобрение у device-сессии
Новая операция DeviceApprovalResponse — ESP32 отвечает (одобрено/отклонено)
Новые операции SignRequest / SignResponse — запрос подписи и ответ
Роутинг: при получении запроса найти device-сессию через ActiveConnectionsRegistry.getByLogin(login) + фильтр по sessionType=DEVICE, переслать туда

Клиент (отдельный этап)

Браузерное расширение или UI: создание делегированной сессии, отправка SignRequest

Что уже готово (переиспользуем)

Роутинг сообщений — SendDirectMessage с TARGET_ONE_SESSION и CallSignalToSession уже умеют точечно доставлять в конкретный sessionId. Механизм готов, нужно добавить только новые op-коды поверх него.
Ed25519 на ESP32 — библиотека <Ed25519.h> уже используется в скетче. Подписи работают.
NVS — уже хранит логин, мастер-секрет, 3 пары ключей. Расширяется легко.
ActiveConnectionsRegistry — поиск по login и sessionId уже есть на сервере.
Аутентификация — схема AuthChallenge → CreateAuthSession через Ed25519 уже полностью реализована.

Оценка сложности

Компонент	Сложность
ESP32: WiFi + WebSocket-клиент + авторизация	Средняя
ESP32: обработчик входящих + UI подтверждений	Средняя
Сервер: флаг sessionType + 4 новых op-а + роутинг	Низкая–средняя
Браузерное расширение	Высокая (отдельный этап)

Итого фазы ESP32 + сервер: ~1–1.5 недели.

С чего начинать

Серверная часть проще и быстрее — начать с добавления sessionType и DeviceApprovalRequest/Response.
Затем ESP32: WiFi → WebSocket → авторизация → обработчик входящих → UI.
Браузерное расширение — отдельная итерация после того как ESP32 + сервер работают.

5.3 KiB Raw Blame History Unescape Escape