Обзор дизайна: удаленная разблокировка Vaultwarden с помощью ntfy без раскрытия кодовой фразы .env на скомпрометированно ⇐ Linux

[Anonymous]

(Если вы хотите перейти к той части вопроса, которую я задаю, прокрутите вниз до последнего раздела с заголовком «Конкретный вопрос».)
Я работаю над домашним лабораторным/учебным проектом и буду признателен за обзор дизайна и идеи по улучшению одной конкретной его части.
Контекст/настройка
Я самостоятельно размещаю экземпляр Vaultwarden на Линуксовый ящик. Вместо установки Docker я извлек двоичный файл Vaultwarden и подключил его к использованию Postgres, чтобы позже попрактиковаться в репликах и резервном копировании.
Основы безопасности и работы в сети:

• Хост — Linux.
• Все входящие порты закрыты, кроме SSH на 22.
• SSH:
  
  Аутентификация только с использованием пароля.
• Вход в систему с правами root отключен.
• Я знаю, что могу дополнительно ограничивать IP-адреса, но явно не хочу (несколько клиентских компьютеров).
• Пожалуйста, не зацикливайтесь на том, насколько это небезопасно; Я понимаю и принимаю риски.

[*]Я использую ufw с poddmo/ufw-blocklist на уровне 2+ для блокировки IP.

[*]Исходящие:

• Используется Cloudflared, поэтому машине не нужны открытые входящие порты для
• Исходящие данные ограничены, за исключением:
  
  репозиториев пакетов,
• трафика Cloudflared,
• GitHub (для обновлений) и т. д.

[*]Стоимость Cloudflare ограничена 300 Requests/min/IP.




Как я обрабатываю секреты Vaultwarden
Vaultwarden считывает файл .env, содержащий ADMIN_TOKEN/

Код: Выделить всё

ROCKET_SECRET_KEY/DATABASE_URL

и т. д. Для простоты представьте себе один секретный_ключ, используемый для шифрования/дешифрования значений БД.
Мой план:

• Хранить этот .env в зашифрованном виде с помощью GPG.
• Во время «разблокировки»:
  • Расшифровать .env только в памяти.
  • Передавайте значения непосредственно в процесс Vaultwarden через интерфейс командной строки или среду (например, vaultwarden SECRET_KEY= ...).
  • Никогда не записывайте расшифрованный файл на диск.

I хочу, чтобы этот этап расшифровки/запуска был удаленно авторизован с моего телефона с помощью ntfy.
Поток авторизации на основе ntfy
При загрузке машины:

• Запускается собственный сценарий:
  • Небольшой HTTP-сервер Python, прослушивающий определенный маршрут (под управлением Cloudflared).
• Скрипт отправляет уведомление ntfy в секретную тему/канал.
• На телефоне я вижу уведомление и могу:
  • Одобрить → запустить расшифровку+запустить Vaultwarden.
  • Отклонить → сервер отключится.

Чтобы привязать это конкретно к мне, а не только к «любому, кто видит тему ntfy», я использую:

• Пару ключей Ed25519:
  
  Открытый ключ, хранящийся на хосте.
• Закрытый ключ, хранящийся только на моем телефоне.

[*]Хост отправляет запрос через ntfy.

[*]Телефон подписывает вызов, отвечает на него и возвращает ответ:

• Решение запроса (доказательство владения закрытым ключом).
• Плюс некоторые секретные материалы, используемые в процессе расшифровки.

Текущая идея разделения парольной фразы
Чтобы избежать хранения полной парольной фразы GPG на хосте, я разработал схему, состоящую из двух частей:

• Часть 1 (P1): хранится на хосте в виде случайной 32-байтовой шестнадцатеричной строки.
• Часть 2 (P2): хранится на моем телефоне.
• Полная парольная фраза GPG = некоторая комбинация P1 и P2 (например, конкатенация).

Последовательность действий:

• При перезагрузке хост отправляет запрос ntfy.
• Телефон:
  • Проверяет внешний вид запроса легитимно.
  • Подписывает запрос или отвечает на него своим закрытым ключом Ed25519.
  • Включает в ответ P2.
• Хост:
  • Проверяет запрос/подпись с помощью сохраненного открытого ключа.
  • Объединяет P1 (локальный) + P2 (удаленно) → полная парольная фраза.
  • Использует парольную фразу для расшифровки .env в памяти и запуска Vaultwarden.

Проблема/угроза, с которой я застрял
Если злоумышленник получит несанкционированный доступ к хосту (скажем, с помощью эксплойта или через SSH с украденными ключами, и т. д.) и могут отслеживать трафик/память процессов на хосте, а затем:

• Они могут видеть P1 (он находится на диске или в памяти).
• Когда я законно одобряю разблокировку со своего телефона, они могут:
  
  Увидеть P2 в пути или в памяти на хосте.
• Восстановить полную парольную фразу (P1 + P2).

[*]Как только они получат полную парольную фразу, они смогут расшифровать .env самостоятельно позже, даже без моего телефона.


Поэтому текущий дизайн уязвим для злоумышленника, который уже контролирует хост и может наблюдать за ntfy-основанным обмен.
Чего я пытаюсь достичь
Я ищу дизайн, который удовлетворяет:

• Удаленное утверждение через ntfy (или аналогичный)
  • Я хочу нажать кнопку на своем телефоне, чтобы авторизовать разблокировку Vaultwarden.
  • Эта часть уже обоснована. обрабатывается с помощью открытых/закрытых ключей и запроса-ответа.
• Хост в одиночку не должен быть в состоянии восстановить долгосрочный секрет
  • Даже если хост случайно скомпрометирован позже, злоумышленник не должен иметь возможности:
    
    Получить GPG парольную фразу (или эквивалентный долгосрочный секрет)
  • Или расшифровать .env без интерактивного подтверждения с моего телефона в режиме реального времени.
• Злоумышленник, который контролирует хост и отслеживает трафик, не должен знать основной долгосрочный секрет
  • Приемлемо, чтобы они могли:
    
    Увидеть, что разблокировка произошла,
  • Увидеть, что Vaultwarden работает и его можно запрашивать, пока он разблокирован.
• Чего бы я хотел избежать:
  • Они могут чтобы извлечь достаточно информации из этого единственного одобренного сеанса, чтобы позже расшифровать .env или повторно получить тот же ключ без моего телефона.

Конкретный вопрос
Существует ли практический способ (в рамках ограничений домашней установки):

• Использовать ntfy (или другой механизм уведомлений/веб-перехватчика) для удаленного «одобрения разблокировки» с моего телефона.
• Использовать аутентификацию с открытым/закрытым ключом, чтобы авторизоваться мог только мой телефон.
• Но структурировать криптографию так, чтобы:
  
  Хост никогда не узнает многоразовая, долговременная парольная фраза или полный ключ.
• И взлом хоста, даже с полной способностью перехватывать трафик и проверять память, не дает злоумышленнику достаточно средств для последующей расшифровки .env в автономном режиме?

Грубо говоря, я представляю себе что-то вроде:

• Мой телефон хранит долгосрочный главный секрет.
• Хост сохраняет некоторое статическое состояние.
• При каждой разблокировке используется новый эфемерный ключ или производный секрет, например:
  
  .env расшифровывается только в «сеансе», который зависит от обеих сторон,
  />
• Но базовый секрет телефона невозможно восстановить по тому, что видит хост.

Если это принципиально невозможно, учитывая предположения «хост полностью скомпрометирован», я хотел бы понять точные ограничения и то, что лучшее, что я могу реально сделать.

Подробнее здесь: https://stackoverflow.com/questions/798 ... ing-env-pa