Почему мы не храним ваш seed — и почему это фича, а не недоработка

Уровень: философия протокола. Механика деривации — в статье Me2eM: идентичность из seed-фразы; практика custody — в парольном менеджере, который ничего не хранит.

Каждый сервис, которым вы пользуетесь, предлагает вам «безопасное хранение» ваших данных. Сохраните контакты — мы синхронизируем. Загрузите фото — мы сделаем бэкап. Введите карту — мы запомним для удобства.

Me2eM делает противоположное: мы не храним ваш seed. Нигде. Ни в каком виде.

Не зашифрованным в облаке. Не зашифрованным в браузере. Не частично. Не «опционально с плашкой безопасности». Никогда и нигде.

Если вы потеряете телефон, переустановите браузер, очистите все данные, утонете в обновлении ОС — ваш seed не пострадает, потому что на устройстве его и не было. Он был на бумаге, в вашем сейфе, в вашей голове. И останется там.

Это статья о том, почему это осознанное архитектурное решение, какую цену вы за него платите, и почему эта цена — честнее альтернативы.

Что такое seed — в одном абзаце

Seed-фраза — это 12 или 24 слова из фиксированного словаря на 2048 элементов. Слова кодируют 128–256 бит энтропии плюс контрольную сумму.

Из seed-фразы детерминированно выводится всё дерево ключей пользователя: корневая идентичность, изолированные контексты (Handle), компоненты устройств (SubHandle), пароли для сервисов, ключи шифрования. Не хранятся — вычисляются за миллисекунды из одних и тех же слов.

12 слов (бумага)
  └─ 32 байта seed (транзиторно в RAM)
       └─ IdentityPrivateKey (HKDF)
            └─ HandlePrivateKey("work")     ← вычисляется по требованию
            └─ HandlePrivateKey("personal") ← вычисляется по требованию
                 └─ SubHandlePrivateKey(...) ← вычисляется по требованию

Один seed = вся вселенная ключей. Никакой другой носитель не нужен.

Почему мы не храним seed — четыре причины

Причина 1: хранилище становится мишенью

Где бы вы ни хранили seed — зашифрованным в облаке, в браузере, в защищённом enclave — это место становится высокоприоритетной целью. Не для вас лично — для оператора хранилища: конверты всех пользователей собраны в одном месте.

Медленный KDF (Argon2id) лишь повышает цену попытки — он не отменяет угрозу. Атакующий работает офлайн, неограниченно долго, над всеми конвертами параллельно. Слабый или средний пароль будет подобран — вопрос экономики, а не возможности.

И — главное — у конверта нет механизма отзыва. Украденный конверт нельзя «аннулировать». Он остаётся мишенью навсегда, пока существует.

Причина 2: нет отзыва без централизации

Отзыв в распределённой системе — это пересечение интересов:

• Хотите мгновенно отозвать украденный seed? Нужен центральный реестр, который все верификаторы проверяют. Центральный реестр = централизованная точка отказа и доверия. Против философии протокола.
• Хотите изменить seed? Пользователь должен опубликовать новый seed и уведомить всех контактов. Контактам нужно перепроверить. Без инфраструктуры — неосуществимо.

В классических системах (JWT, OAuth) отзыв возможен, потому что сервер контролирует выдачу токенов. В децентрализованной системе root-ключ существует у пользователя — и отозвать его некому: нет реестра, нет центра, нет кнопки.

Важно не спутать уровни. Seed неотзываем — но ветки отзываемы. Аттестационные цепочки позволяют владельцу мгновенно гасить ответвлённые ключи — хэндлы и субхэндлы — одним отзывом jti, во всех сервисах одновременно. Централизация при этом не возвращается: отзываются не корень, а подписанные им делегирования. Механика — в статье о мгновенном отзыве.

Причина 3: ложная безопасность хуже её отсутствия

Если хранилище seed предлагает «безопасный бэкап в облаке» — пользователь начинает думать, что seed больше не нужно записывать на бумагу. И правильно думает: зачем, если есть бэкап?

Но бэкап — не замена бумаге:

• Сервис может закрыться (стартапы закрываются).
• Сервис может быть взломан (никто не гарантирует вечную безопасность).
• Пароль пользователя может быть слабым.
• Устройство, с которого вводился пароль, может быть скомпрометировано.

Если бэкап исчезнет — пользователь потеряет seed вместе с бумажкой, которую он уже выбросил. Это худший исход: двойная точка отказа, где пользователь думает, что есть только одна.

Причина 4: прозрачность — свойство, не недоработка

Детерминированная деривация даёт свойство, которое не получить, если seed где-то хранится:

Пользователь всегда знает, где его ключ. Не «где-то в облаке нашего сервиса», не «в зашифрованном бэкапе», не «на устройстве» — а на бумаге. Если бумага в порядке — идентичность в порядке. Если бумага потеряна — идентичность потеряна. Ноль неопределённости.

Что пользователь получает

Свойство	Как работает
Никакой зависимости от сервиса	Сервис может исчезнуть — seed остаётся.
Никакой утечки данных	Нечего утекать — ключи вычисляются, а не хранятся.
Мультидевайсность без sync	Тот же seed на новом устройстве = то же дерево.
Никакого пароля для восстановления	Seed = пароль. Пароль = seed. Ноль сущностей для восстановления.
Полная анонимность	Ни email, ни телефона, ни карты — seed не привязан к личности.

Цена, которую вы платите

Честность требует перечислить и цену:

Цена	Почему
Потеря seed = потеря всего	Нет recovery, нет reset, нет «забыл пароль — отправьте SMS». Seed утерян — идентичность утеряна.
Ответственность на пользователе	Записать на бумагу, хранить безопасно, не фотографировать, не хранить в облаке заметок.
Seed нельзя поменять	Нет «сбросить пароль». Если seed скомпрометирован — нужна новая identity (новый seed), и все связи перестраиваются.

Сравнение с альтернативами

Модель	Восстановление	Уязвимость	Зависимость от сервиса
Пароль в сервисе	«Забыли пароль?» → email → SMS → новый пароль	SMS перехват, email взлом, insider	Полная
Seed зашифрован в облаке	Password → облако → decrypt	Облако скомпрометировано + брутфорс пароля	Частичная (нужен доступ к облаку)
Seed на бумаге (Me2eM)	Только физическая бумажка	Бумагу надо хранить	Ноль

Облачное восстановление — удобный вариант, но его безопасность упирается в пароль пользователя. Если пароль слабый — офлайн-брутфорс конверта — вопрос времени. Если пароль сильный — пользователю нужно помнить его так же тщательно, как seed-фразу. Это trade-off, а не решение.

Что делать пользователю

Практический чек-лист после создания seed-фразы:

✅ Обязательно:

• Запишите 12 слов ручкой на бумаге — и никогда в цифровом виде.
• Прочитайте записанное. Проверьте каждое слово дважды.
• Если запутались — возьмите чистый лист и запишите заново.
• Храните бумажку в месте, где она не погибнет от воды, огня, времени.
• Для критичной идентичности — гравировка на металлической пластине и вторая копия в другой геолокации.

❌ Никогда:

• Не фотографируйте seed-фразу.
• Не храните в облачных заметках.
• Не отправляйте себе в мессенджер.
• Не храните в менеджере паролей — vault-хранилище это ровно та модель, от которой мы уходим (Причина 1).
• Не показывайте никому — даже «поддержке» (она никогда не попросит).

Seed — не пароль. Seed — единственный носитель идентичности

Пароль можно сбросить. Seed-фразу — нет.

Пароль можно сменить. Seed-фразу — нет (но можно создать новую identity).

Пароль хранится у сервиса в хешированном виде. Seed-фраза нигде не хранится — ни у нас, ни у кого-либо ещё, кроме бумаги пользователя.

Разница фундаментальна. Пароль — это авторизационный секрет для доступа к аккаунту на сервере. Seed — это мастер-секрет, из которого выводится вся идентичность пользователя.

Кому этот подход подходит

✅ Подходит:

• Пользователи, ценящие суверенитет и не доверяющие централизованному хранению.
• IoT-сценарии, где устройство работает автономно без облака.
• Разработчики, которым нужен детерминизм (тот же seed на всех устройствах = те же ключи).
• Пользователи, которым нужна анонимность.

❌ Не подходит:

• Пользователи, которые потеряют бумажку и не смогут её восстановить.
• Сценарии, требующие централизованного отзыва и восстановления.

Что читать дальше

• Почему UX seed-фразы такой параноидальный — как пакет @me2em/react компенсирует человеческие ошибки
• Me2eM: идентичность из seed-фразы — детерминированное дерево ключей
• Парольный менеджер, который ничего не хранит — та же модель custody на практике
• Мгновенный отзыв: ревокация в stateless-мире — почему отзыв не требует хранить seed: ветки отзываемы, корень — нет
• @me2em/core на npm — реализация