GhostNet

gna_ca_server: Архитектура и Принципы Работы

gna_ca_server — это криптографическое ядро и "банк доверия" всей сети GhostNet. Он реализован как изолированный микросервис, единственная задача которого — управление жизненным циклом цифровых идентификаторов (сертификатов) и инвайт-токенов.

Принцип безопасности №1: Изоляция. Сервер gna_ca_server спроектирован так, чтобы никогда не быть доступным извне. Он слушает только локальный интерфейс (127.0.0.1:9100), и единственным его "клиентом" является gna_lighthouse. Это радикально снижает поверхность атаки.

1. Философия и Роль в Экосистеме

В отличие от монолитных VPN-решений, GhostNet разделяет управление (Lighthouse) и доверие (CA).

  • Lighthouse знает "где" и "когда": Он отслеживает онлайн-статус и реальные IP-адреса узлов.
  • CA Server знает "кто" и "что может": Он определяет, является ли узел легитимным участником сети и какими правами он обладает.

Такое разделение позволяет gna_ca_server сосредоточиться исключительно на криптографических операциях, не отвлекаясь на сетевую логику (P2P, NAT, реле).

2. Основной Функционал

2.1. Управление Жизненным Циклом Сертификатов (PKI)

gna_ca_server реализует полноценную инфраструктуру публичных ключей (Public Key Infrastructure).

Выпуск Сертификатов (/sign)

Сервер умеет генерировать сертификаты для разных нужд, используя разные криптографические алгоритмы:

  • Ed25519 (для VPN Агентов): Выбирается по умолчанию для агентов. Обеспечивает максимальную производительность и современный уровень безопасности для UDP-трафика.
  • ECDSA P-256 (для HTTPS): Используется для веб-сервисов, например, для HTTPS-панели самого Lighthouse. Обеспечивает широкую совместимость с браузерами.
  • Ролевая модель (OU): Права доступа встраиваются прямо в сертификат через поле OrganizationalUnit (OU). Например, OU=Admins дает право доступа к панели управления, а OU=Users — только к VPN.
  • SAN (Subject Alternative Name): Сертификаты содержат SAN-поля, что позволяет им быть валидными для конкретных IP-адресов или DNS-имен (base.ghost), что является стандартом для TLS.

Верификация и Аутентификация (/verify)

Это самая частая операция. Когда агент отправляет Handshake на Lighthouse, тот проксирует запрос на верификацию в CA. Процесс многоступенчатый:

  1. Криптографическая проверка подписи: gna_ca_server использует ring и x509-parser для проверки, что AgentReport действительно был подписан приватным ключом, соответствующим публичному ключу в сертификате.
  2. Проверка цепочки доверия: Сертификат агента проверяется на то, что он был подписан корневым ключом нашего CA (ca_key.pem).
  3. Проверка статуса отзыва (CRL): Сервер обращается к своей базе данных (ca_database.db) и проверяет, не помечен ли серийный номер сертификата как отозванный (revoked = 1).
  4. Проверка срока действия: Анализируются поля not_before и not_after.

Отзыв Сертификатов (/certificates/revoke/:serial)

При компрометации ключа администратор может мгновенно отозвать сертификат. Сервер помечает соответствующую запись в базе данных. gna_lighthouse периодически запрашивает обновленный список отозванных сертификатов (CRL) и прекращает обслуживать узлы с недействительными сертификатами.

2.2. Система Онбординга (Invites)

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

  1. Создание (/invite): Администратор запрашивает токен. CA генерирует UUID, сохраняет его в таблицу invites вместе с TTL (сроком жизни), назначенной ролью (group_name) и будущим VIP (assign_cn).
  2. Погашение (/join): Агент отправляет токен, свой временный node_id и Hardware Fingerprint.
  3. Валидация и Выпуск: CA проверяет токен в базе, генерирует постоянную пару ключей и сертификат, а затем привязывает этот сертификат к Hardware Fingerprint в таблице certificates.
  4. Деактивация: Токен помечается как is_used = 1 и больше не может быть использован.

2.3. Anti-Theft: Привязка к Аппаратному Обеспечению (/verify_binding)

Это ключевая функция Zero Trust, которая защищает от кражи ключей.

  • Принцип: Во время онбординга (на шаге 2.2), hw_fingerprint агента сохраняется в базе данных вместе с его node_id и virtual_ip.
  • Применение: При каждой попытке админского доступа к панели, gna_lighthouse вызывает эндпоинт /verify_binding. CA сервер выполняет SQL-запрос: SELECT * FROM certificates WHERE node_id = ? AND hw_fingerprint = ? AND virtual_ip = ?.
  • Результат: Если злоумышленник скопирует node.key и cert.pem с вашего ноутбука на другую машину, hw_fingerprint не совпадет, и CA вернет отказ. Доступ будет заблокирован.

3. Техническая Реализация

  • API Сервер: Написан на axum — современном веб-фреймворке для Rust, работающем поверх tokio. Вся логика асинхронна, что обеспечивает высокую производительность.

  • База Данных: Используется SQLite через крейт rusqlite. Выбор обусловлен простотой развертывания (один файл, не требует отдельного сервера) и надежностью для однопользовательской записи. Схема данных:

    • certificates: Реестр всех выданных сертификатов, их статус, сроки действия, и привязка к node_id и hw_fingerprint.
    • invites: Список одноразовых токенов, их сроки действия и статус.

  • Криптография: Используется набор проверенных библиотек:

    • rcgen: Для генерации ключей и сертификатов X.509.
    • x509-parser: Для парсинга и анализа PEM/DER сертификатов.
    • ring: Для высокопроизводительной криптографической верификации подписей Ed25519.

    4. Запуск и Управление

4.1. Инициализация

Первый и единственный раз сервер запускается с флагом --init-ca.

sudo ./gna_ca_server --init-ca

Эта команда создает три артефакта в текущей папке: ca_cert.pem: Публичная часть корневого сертификата. Его можно безопасно распространять. ca_key.pem: Секретный ключ. Его компрометация = компрометация всей сети. ca_database.db: Файл базы данных SQLite. 4.2. Режимы Запуска gna_ca_server поддерживает два режима: Интерактивный (по умолчанию): Запускается командой sudo ./gna_ca_server. Отображает консольное меню для прямого администрирования базы данных и PKI. В этом режиме API-сервер также запускается в фоновом потоке. Служба (--headless): Запускается командой sudo ./gna_ca_server --headless. В этом режиме запускается только API-сервер без интерактивного меню. Идеально для работы под управлением systemd. 4.3. Консольное Меню (Интерактивный Режим) Меню предоставляет прямой доступ к основным операциям CA, что полезно для отладки или ручного управления.

=== GHOST-NET CA AUTHORITY v1.0 ===
Статус сервера: ONLINE (Port 9100)

Выберите действие:

  1. Список активных инвайтов
  2. Создать новый инвайт (CLI)
  3. Список выданных сертификатов
  4. Отозвать сертификат (Revoke)
  5. Полное удаление сертификата (Purge)
  6. Перегенерация Root CA (Опасно!)
  7. Установка службы (Systemd/Windows)
  8. Остановка/Запуск API
  9. Выход
  • Пункты 1-5: Предоставляют CRUD-операции над таблицами invites и certificates.
  • Пункт 6 (Перегенерация Root CA): КРАЙНЕ ОПАСНАЯ ОПЕРАЦИЯ. Полностью уничтожает старый корень доверия. Все ранее выданные сертификаты станут недействительными. Используйте только в случае компрометации ca_key.pem или для полного сброса сети.
  • Пункт 7 (Установка службы): Создает и активирует systemd сервис (ghost_ca.service), прописывая в него правильный WorkingDirectory и флаг --headless, что обеспечивает корректный запуск после перезагрузки сервера.

5. Полный список API Эндпоинтов

Сервер предоставляет RESTful API для gna_lighthouse.

МетодЭндпоинтОписание
POST/sign(Устаревшее) Ручной выпуск сертификата.
POST/verifyКлючевой: Проверка подписи и статуса сертификата.
POST/verify_bindingКлючевой: Проверка привязки к железу (Anti-Theft).
GET/root_caПолучение публичного корневого сертификата.
POST/inviteСоздание нового инвайт-токена.
GET/invitesПолучение списка активных инвайтов.
DELETE/invites/:tokenУдаление (отмена) инвайт-токена.
POST/joinКлючевой: Обмен токена на сертификат.
GET/crlПолучение списка отозванных сертификатов (CRL).
GET/certificatesПолучение полного реестра сертификатов.
POST/certificates/revoke/:serialОтзыв сертификата по серийному номеру.
DELETE/certificates/:serialПолное удаление сертификата из базы.

6. Экспериментальные Идеи и Будущее Развитие

Хотя текущая архитектура централизована вокруг одного CA, она закладывает основу для более сложных топологий.

  • Федерация и Промежуточные CA (Intermediate CAs): В будущем возможно создание нескольких CA для разных отделов или регионов. Корневой gna_ca_server мог бы подписывать промежуточные CA, которые, в свою очередь, выпускали бы сертификаты для своих агентов. Это позволило бы делегировать полномочия и строить более масштабные иерархии доверия.

  • Автономная Работа Lighthouse: Если gna_ca_server временно недоступен, gna_lighthouse может продолжать работу, используя кэшированные данные о статусе отзыва. Он не сможет провести онбординг новых узлов, но уже подключенные агенты продолжат функционировать, так как их сертификаты уже выпущены.

  • Аппаратные Модули Безопасности (HSM): Для максимальной безопасности, приватный ключ Root CA (ca_key.pem) может храниться не на диске, а внутри аппаратного модуля (HSM) или YubiKey. gna_ca_server будет обращаться к устройству для выполнения операций подписи, ключ при этом никогда не покинет защищенное хранилище.

Текущая реализация gna_ca_server является прочным фундаментом, готовым к дальнейшему расширению и усилению безопасности.