Galdr — Galdralag Firmware

Open Invention Network

Этот проект зарегистрирован в Open Invention Network (OIN). OIN — это оборонительный патентный пул: участники перекрестно лицензируют патенты, связанные с Linux, чтобы участники могли распространять и использовать открытое программное обеспечение с меньшим риском патентных претензий.

Статус: Ожидание поступления оборудования для тестирования. https://www.crowdsupply.com/baochip/dabao/updates/our-campaign-has-launched

Содержание

• Open Invention Network
• Что это такое
  • Метаданные контакта Galdra
  • Что такое эта прошивка (и чем она не является)
  • Подписанная прошивка (Ed25519, boot0)
• Это AI-халтура?
• Результаты тестов
• Почему Rust?
  • Безопасность памяти
  • Надёжность на уровне системы (с ограничениями)
  • Защита ключевого материала (шаблоны проекта)
  • Проектирование с возможностью аудита
  • Что Rust не предотвращает
  • Настройка виртуальной машины для оценки
  • Оценка рисков и развёртывание
• Galdralag для чайников
  • Что такое GnuPG?
• Ключи GnuPG / OpenPGP и ключи Galdra
  • Сравнение метаданных (GnuPG vs Galdra)
• Пропущенные и игнорируемые тесты
• О названии
• Документация
• Карта кода (индекс функций и модулей)
• Зависимости крейтов (вышестоящие vs проект)
• Инструкции по отладке
• docs/AUDIT_LOG.md
• docs/BIOMETRIC_API.md
• docs/HARDWARE_BRINGUP_TEST_PLAN.md
• docs/KEY_LIFECYCLE.md
• docs/RRAM_LAYOUT.md
• docs/THREE_FACTOR_AUTH.md
• docs/THREAT_MODEL.md
• Глоссарий (простым языком)
• Совместимость с OpenPGP и GnuPG
• Сессия токена и экспорт ключей
• Сеть доверия и вечеринки подписания ключей
  • Получение отпечатка Galdralag
  • Что такое сеть доверия?
  • Как это работает
  • Вечеринки подписания ключей
  • Типичный рабочий процесс на вечеринке подписания ключей
  • Отпечатки вместо полных ключей на мероприятии
  • Серверы ключей
  • Использование серверов ключей
  • Распространённые серверы ключей
  • Лучшие практики и предостережения
  • Fulla (сервер реестра WoT)
• Стандарты vs специфические функции прошивки
• Совместное использование секрета Шамира и шифрование диска
• Немецкое eID и Governikus как доверенный якорь для открытых ключей
• Процесс стандартизации: Шамир и эфемерный обмен ключами
  • CESS (связанный открытый стандарт)
• Sequoia PGP (если этот репозиторий недоступен)
• Поддержка платформ (только Linux)
• Сборка, установка и удаление
  • Компиляция прошивки
  • Прошивка
  • Компиляция и установка инструментов хоста (galdra, galdrad, galdra-gtk)
  • Запуск galdrad и графического интерфейса рабочего стола (galdra-gtk)
  • Удаление инструментов хоста
• Возможности ключей
  • Что делает этот токен необычным
  • Криптографические возможности
    • Асимметричное / согласование ключей
    • Симметричное / AEAD
    • Вывод ключей / MAC / дайджест
    • Управление ключами
  • Свойства безопасности
  • Политика PIN
• Постквантовый статус
  • Реализовано — неаудированный крейт (за функциональным флагом)
  • Ожидается независимый аудит — ещё не реализовано
  • Не будет реализовано
• Обнуление — аппаратное предостережение
• Структура рабочего пространства
• Политика криптографических зависимостей
• Быстрый старт
• Известные ограничения / открытые работы
  • CCID начальный PIN: первая загрузка (USB CDC)
• Лицензия

Что это такое

Прошивка для устройств Baochip-1x (плата оценки Dabao) под управлением микроядра Xous, собранная для riscv32imac-unknown-none-elf.

Расположена здесь: https://www.baochip.com/

Устройство представляет собой аппаратный токен безопасности той же категории, что и устройства класса Nitrokey, с поведением смарт-карты OpenPGP и зашифрованным хранилищем. Полный стек оборудования — RTL, схемы, загрузчик, ОС — является открытым и поддаётся аудиту.

Спецификация оборудования, модель загрузки, таблицы требований и использование ComboHash/PKE документированы в Supermagnum/Baochip-1x-firmware. Плата оценки Dabao (KiCad, схемы, переключатели, распиновка) находится в baochip/dabao. Для входа в режим загрузчика для прошивки нажмите SW2 чтобы переключить его (см. схему в том репозитории). Архитектурные заметки для этого репозитория: docs/ARCHITECTURE.md.

Метаданные контакта Galdra

Инструмент хоста Galdra хранит локальный каталог SQLite получателей (контактов). Каждая сохранённая личность включает материал открытого ключа плюс необязательные дополнительные метки (см. таблицу ниже). Эти теги хранятся в базе данных хоста и, для ключей Galdra, в хранилище контактов на чипе (crates/contact-store). Они не магически привязаны к идентификаторам пользователей OpenPGP, если вы сами их не согласуете, и не криптографически подтверждены, если вы не проверите их внеполосно. Опциональная команда galdra keyserver push может отправлять перекрывающиеся поля в реестр проекта в формате JSON вместе с экспортированным открытым ключом. Происхождение каждого поля на токене использует SelfAttested, HostVerified, RegistrySync и OobVerified (см. Сравнение метаданных (GnuPG vs Galdra) и структуру хранилища контактов в docs/RRAM_LAYOUT.md).

Подробности на стороне хоста и поведение CLI: docs/GALDRA-TOOL.md. Схема проводов и количество слотов: crates/contact-store/src/layout.rs и docs/RRAM_LAYOUT.md.

Что такое эта прошивка (и чем она не является)

Эта прошивка — это аппаратный токен безопасности для Baochip-1x: приложение смарт-карты OpenPGP через USB CCID, с хранилищем на устройстве, политикой PIN и функциями, специфичными для репозитория (профили шифров — вы можете накладывать до четырёх различных симметричных шифров в один каскад, каждый со своим производным ключом; см. Возможности ключей), потоками, связанными с Шамиром, аутентифицированным эфемерным ECDH, где реализовано, и инструментами хоста Galdra). Основная цель совместимости — использование смарт-карт OpenPGP в стиле GnuPG, а не каждый протокол токенов на рынке.

Эта прошивка не является:

• FIDO2 / CTAP2 / WebAuthn — другие стандарты; нет модели кнопки присутствия пользователя CTAP и не планируется стек CTAP. Используйте ключ безопасности FIDO, если вам нужен WebAuthn. (См. также Совместимость с OpenPGP и GnuPG и таблицу стандартов в Стандарты vs специфические функции прошивки.)
• TOTP / HOTP (одноразовые пароли OATH) — эти протоколы ожидают часы реального времени (TOTP) или ориентированный на OATH счётчик рабочих процессов и UX; это устройство не предназначено как выделенный OTP-токен.
• USB HID клавиатурный "ввод пароля" — нет личности USB-клавиатуры для внедрения нажатий клавиш в хост. Планируемое хранение учётных данных (см. docs/future-todo.md) описано как получение через аутентифицированные инструменты хоста, а не ввод через HID.
• Общая многоприложная платформа Java Card — область ограничена этой прошивкой Galdr и её документированными поверхностями, а не произвольными сторонними апплетами смарт-карт.

Исключения на уровне крейтов, соответствующие тем же ограничениям, перечислены в Явно исключённые крейты в docs/future-todo.md.

CESS: Эта прошивка соответствует CESS для нормативных конструкций, реализованных в дереве (включая внешнюю AEAD Mode A, HKDF-BLAKE3 для K_outer и побайтовое разделение Шамира GF(2^8)). Полное заявление о соответствии, реестр отклонений и уровень сертификации (например, CESS-CORE для полного фиксированного слоя) задокументированы в docs/CESS_CONFORMANCE.md и CESS (связанный открытый стандарт) ниже.

Логика приложения OpenPGP / CCID находится в crates/usb-personality. На Xous служба USB, предоставляющая CCID, — это usb-bao1x (в вашей копии xous-core), собранная с флагом ccid-openpgp и использующая crates/baochip-openpgp для окна RRAM OpenPGP и подготовки. Схема: docs/RRAM_LAYOUT.md. Пробелы предпроизводственного этапа (операторский PIN UX, подпись карты платформы): Известные ограничения / открытые работы.

Общая цель остаётся полной, протестированной прошивкой аппаратного токена безопасности с открытым исходным кодом: поведение смарт-карты OpenPGP для GnuPG через CCID (см. Совместимость с OpenPGP и GnuPG), плюс дополнительные функции на устройстве, которые в настоящее время не определены стандартом смарт-карт OpenPGP — эфемерный ECDH с прямой секретностью, Шамир K-of-N, профили, не зависящие от шифра, зашифрованный том microSD — как резюмировано в Стандарты vs специфические функции прошивки. Всё на открытом RTL с воспроизводимым загрузчиком.

Подписанная прошивка (Ed25519, boot0)

Поставляемая прошивка для Baochip-1x подписывается с помощью Ed25519. Вы подписываете образ прошивки закрытым ключом Ed25519; GnuPG может сделать это с помощью gpg --sign, используя подключ подписи Ed25519 (обычный рабочий процесс отделённой подписи OpenPGP, адаптированный к тому, что генерирует ваша сборка). Неизменяемое ПЗУ boot0 в SoC проверяет эту подпись относительно соответствующих открытых ключей, записанных в устройство (и более широкого манифеста ключей для цепочки загрузки) перед тем, как позволить запустить следующий этап — boot1. Затем boot1 загружает подписанные образы приложений (например, блобы UF2, доставляемые через USB-накопитель в режиме загрузчика). Части по умолчанию содержат четыре открытых ключа Ed25519 на чипе (роли: развёртывание кода, бета, разработчик); boot0 / boot1 обеспечивают политику взаимного недоверия между Baochip и сторонними ключами подписи. Полный процесс загрузки, доставка UF2, консоль, обновления boot1 и модель безопасности: Начало работы с целями Baochip в xous-core.

Пропущенные и игнорируемые тесты

Не каждый тест выполняется в каждой команде; это намеренно.

• xtask не в тесте рабочего пространства по умолчанию: Обычная инструкция — cargo test --workspace --exclude xtask, потому что xtask — это крейт сборки-оркестрации. Запустите cargo test -p xtask, когда захотите его тесты.
• Тесты, отмеченные #[ignore]: Они пропускаются, если вы не передадите --ignored (и любые необходимые фильтры крейтов). Причины включают: покрытие, которое уже проверяется в целенаправленных модульных тестах (например, обнуление после удаления), медленные случаи (например, генерация ключей RSA), и зависимые от оборудования или токенов потоки в инструментах хоста, таких как galdra, которым требуется подключённое устройство или фикстуры.
• test-all --no-fuzz: Пропускает шаг cargo-fuzz, чтобы сократить время CI или быстрых запусков и избежать необходимости ночного набора инструментов для этого шага; запустите cargo run -p xtask -- test-all без --no-fuzz или вызовите цели фаззинга отдельно (см. ).

Также можно проверить целостность крейтов с помощью этого, когда PR закрыт: https://github.com/rust-lang/cargo/issues/16850

Статус: Готово к тестированию людьми на реальном оборудовании — релиза для производства не существует. Он написан на Rust с использованием проверенных и прошедших аудит криптографических крейтов. Криптографические примитивы взяты исключительно из проверенных зависимостей рабочего пространства. Постквантовые алгоритмы скрыты за функциональными флагами и помечены ОЖИДАЕТ НЕЗАВИСИМОГО АУДИТА. См. Постквантовый статус.

Примечание: Части этого проекта были разработаны с помощью ИИ (Claude, Anthropic). Дизайн, криптографические решения и решения по безопасности не были проверены профессиональным криптографом. Относитесь к этому как к экспериментальному проекту и применяйте собственное критическое суждение. Настоятельно рекомендуется независимая экспертная проверка перед любым развёртыванием в производстве.

Он готов к тестированию людьми. Вы решаете, собирать или запускать какое-либо из этого программного обеспечения; могут быть ошибки, которые модульные тесты, фаззинг и другие проверки не нашли. Использование опциональной виртуальной машины для экспериментов снижает риск для вашей хост-системы, но не устраняет его. Подробные результаты находятся в Результаты тестов (docs/TEST_RESULTS.md#run-metadata). Определения простым языком (A–Z) технических терминов: Глоссарий.

Это AI-халтура?

Основной разработчик имеет неврологическое состояние, связанное с дискалькулией. Дискалькулия влияет на чувство числа и связанные символические процессы таким образом, что для данного разработчика традиционное программирование — самостоятельное редактирование кода как единственный рабочий процесс — не работает без вспомогательных инструментов (например, диалоговых редакторов ИИ). Это ограничение отличается от корректности: рецензенты всё равно должны оценивать тесты, фаззинг и независимый аудит, как документировано на этой странице.

Криптограф или серьёзный разработчик, изучающий Galdralag, обычно открывает crates/vault/tests/ и crates/cipher-profile/tests/ до чтения прозы. Набор тестов — это доказательство работы: он кодирует знания предметной области, которые нельзя заменить одним повествованием.

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

На что смотреть: Материалы соответствия включают рабочие примеры RFC 8439 для ChaCha20-Poly1305 в crates/vault/tests/rfc_vectors/, приобретённый JSON Wycheproof для ChaCha20-Poly1305 и граничных случаев ECDH/ECDSA Brainpool в crates/vault/tests/data/wycheproof/, векторы BSI TR-03111 для BrainpoolP256r1 и P384r1 в crates/vault/tests/bsi_vectors/, эталонные векторы BLAKE3 (все 35 длин входных данных, все три режима) в crates/vault/tests/blake3_vectors.json, векторы спецификации Twofish (1203 случая, включая Монте-Карло) в crates/vault/tests/twofish_vectors.json, и собственные KAT-фикстуры каскада CESS проекта с независимо проверенными промежуточными значениями в crates/cipher-profile/tests/fixtures/cascade_cess_kat.json. Вместе они являются истиной, которую исполнитель и рецензенты могут проверить с помощью cargo test --workspace и python3 scripts/verify_cascade_kats.py.RFC 8439 опубликован Инженерным советом Интернета (IETF) — организацией, стандартизирующей многие аспекты работы интернета. RFC (Request for Comments) — обычная форма для протоколов и многих криптографических спецификаций. RFC 8439 определяет аутентифицированное шифрование ChaCha20-Poly1305 (на основе разработок Дэниела Бернстайна) и включает конкретные рабочие примеры с заданными входными данными и ожидаемыми выходными, чтобы независимые реализации могли проверить их по байтам. Широко воспроизводимый открытый текст, начинающийся с , встречается в примерах приложения RFC: если ваш код воспроизводит выходной AEAD точно, это надёжная проверка правильности реализации. Это криптографический аналог официального ключа ответов. ChaCha20-Poly1305 — внутренний слой каждого многослойного каскадного профиля в этой прошивке, поэтому данная проверка находится в основе всего стека шифров.

Wycheproof — тестовый корпус, выпущенный группой безопасности Google (2017). Название отсылает к горе Wycheproof в Австралии — часто называемой самой маленькой горой в мире — потому что проект сосредоточен на устранении мелких, но фатальных препятствий: переполнения целых чисел, граничных случаев, некорректных входных данных и подделанных тегов аутентификации; ошибки, которые постоянно проявляются в реальном развёрнутом крипто. Он дополняет векторы в стиле RFC: примеры в стиле RFC 8439 демонстрируют корректность по отношению к опубликованному AEAD; Wycheproof проверяет устойчивость там, где реализации исторически ломаются. В этом репозитории JSON Wycheproof покрывает ChaCha20-Poly1305, AES-GCM, HMAC, HKDF, X25519, Ed25519, RSA и варианты Brainpool ECDH/ECDSA.

BSI TR-03111 — техническое руководство по криптографии на эллиптических кривых, опубликованное Федеральным ведомством по информационной безопасности Германии (Bundesamt für Sicherheit in der Informationstechnik). Версия 2.10 — текущая редакция. Кривые Brainpool, используемые в этой прошивке — P256r1 и P384r1 — заданы в стандартах BSI, что делает TR-03111 естественным справочником для их тестовых векторов. Для каждой кривой есть покрытие ECDH и ECDSA; подписи ECDSA дополнительно перепроверены с помощью независимой реализации на Python с использованием библиотеки cryptography.

BLAKE3 reference vectors — официальный тестовый корпус, опубликованный вместе со спецификацией BLAKE3 её авторами. Они охватывают 35 длин входных данных от 0 до 102400 байт, специально выбранных для отработки всех внутренних граничных условий (размер чанка, структура дерева), которые не видны при тестах с короткими входными данными. Все три режима BLAKE3 — хеш по умолчанию, ключевой хеш и derive-key — покрыты. BLAKE3 используется по всей прошивке для вывода ключей HKDF и проверок целостности между слоями в каскадных профилях шифров; покрытие граничных условий важно, потому что древовидная конструкция BLAKE3 активируется только при длине более 1024 байт.

Тестовый набор также служит обнаружением подделки для цепочки поставок. Все криптографические примитивы в этой прошивке взяты из проверенных крейтов RustCrypto — никакая криптография не реализована внутри дерева. Поскольку приведённые выше векторы соответствия запускаются для этих крейтов при каждом cargo test --workspace, любая зависимость, которая была подделана или заменена, вызовет сбой теста с известным ответом до того, как скомпрометированный код попадёт в развёрнутую систему. python3 scripts/verify_cascade_kats.py добавляет второй независимый путь: реализация на Python проверяет те же промежуточные значения в фикстуре KAT каскада, поэтому даже скомпрометированный инструментарий Rust, выдающий неверные результаты, будет зафиксирован перекрёстной проверкой. Это значительно более надёжная история для целостности цепочки поставок, чем привязка к библиотеке на C, где эквивалентная проверка каждой внутренней операции требует значительно больше усилий и специализированного инструментария.

Теперь читателю предстоит решить, являются ли эти утверждения ложными или нет.

Galdralag для чайников

Вы подключаете его к USB-порту. С точки зрения хоста прошивка может представлять крипто-режим или режим маскировки. В крипто-режиме ваш компьютер видит смарт-карту: вы используете GnuPG или совместимый стек OpenPGP (Что такое GnuPG?) так же, как и любой другой аппаратный токен безопасности — токен выполняет криптографические операции, так что ваши приватные ключи никогда не существуют незащищёнными на вашем компьютере. В режиме маскировки он может определяться как обычное съёмное хранилище с безобидными файлами, чтобы беглый взгляд не раскрыл его реальное предназначение; см. Маскировка хранилища ниже.

Что такое GnuPG?

GnuPG расшифровывается как GNU Privacy Guard. Это реализация OpenPGP проекта GNU — открытого стандарта для управления ключами и криптографически защищённых сообщений (той же концептуальной семьи, что и PGP, но описанного в документах, таких как RFC 4880 и обновления сообщества). Обычно вы запускаете его как команду gpg в Linux, BSD, macOS или Windows; многие графические почтовые клиенты и утилиты для управления ключами используют его под капотом.

Люди используют GnuPG для:

• Шифрования и дешифрования файлов или резервных копий, чтобы только выбранные получатели могли их прочитать.
• Подписания данных, чтобы другие могли проверить подлинность и целостность — часто используется для релизов ПО, зеркал дистрибутивов и личных документов.
• Защиты электронной почты End-to-End в паре с подходящим почтовым клиентом (GnuPG отвечает за криптографию; формат сообщения в сети — OpenPGP).
• Аутентификации, в частности SSH-логинов, когда gpg-agent предоставляет ключи аутентификации со смарт-карты или локального хранилища ключей.
• Блокировки и разблокировки зашифрованного жёсткого диска. Linux может зашифровать целый диск так, что он становится нечитаемым без правильного ключа. GnuPG может хранить этот ключ на вашем токене, поэтому диск открывается только тогда, когда токен подключён.

GnuPG и зашифрованные диски (LUKS). В Linux есть встроенный способ шифрования целого диска или раздела, называемый LUKS. Как только диск зашифрован, он выглядит как бессмысленный шум для всех без ключа, поэтому потерянный или украденный ноутбук не отдаст ваши файлы.

Обычно вы разблокируете такой диск, вводя пароль. GnuPG позволяет использовать вместо этого ваш токен. Идея проста: ключ разблокировки диска сам заперт ключом вашего токена. Когда вы хотите открыть диск, токен расшифровывает для вас этот ключ разблокировки, но только пока токен подключён и вы ввели свой PIN. Вытащите токен — и диск невозможно открыть, даже на том же компьютере.

Короче говоря, это превращает токен в физический ключ для вашего зашифрованного диска. Настройка (и добавление резервного способа входа на случай потери токена) выполняется с помощью встроенных дисковых инструментов Linux; токен просто хранит ключ. Если вы хотите разделить возможность разблокировки диска между несколькими людьми, чтобы ни один человек не мог сделать это в одиночку, см. Схема Шамира и шифрование диска.

По умолчанию GnuPG хранит ключи в ~/.gnupg. Со смарт-картой OpenPGP конфиденциальные приватные ключи живут на карте; scdaemon (часть набора GnuPG) общается с картой по CCID/USB, а gpg по-прежнему собирает пакеты OpenPGP на хосте.

Для чего это можно использовать. В крипто-режиме токен предназначен для той же работы, что и другие смарт-карты OpenPGP: подписывание и дешифрование почты и файлов, аутентификация (например, SSH при использовании gpg-agent как обычно), и хранение долгосрочных приватных ключей вдали от машины, на которой вы работаете. Организации могут комбинировать это с долями Шамира на токене, чтобы ни один человек не владел полным секретом (описано ниже). GnuPG является основной целью совместимости на хосте: эта прошивка реализует приложение OpenPGP card через CCID, которое использует scdaemon (gpg --card-status, gpg --card-edit и обычные encrypt/sign/decrypt с ключами на карте). Другое ПО, говорящее на тех же протоколах смарт-карт, также может работать; команды, слоты, алгоритмы и текущие ограничения интеграции описаны в Совместимость с OpenPGP и GnuPG. Когда NFC будет реализован на аппаратном уровне (планируемая интеграция — пока не в прошивке), то же устройство сможет поддерживать физический доступ: считывание NFC-ридером на двери, воротах или замковой панели может участвовать в политике, которая отпускает замок только после криптографических проверок (часто в сочетании с PIN, биометрией или кворумом Шамира в зависимости от развёртывания). Эскиз для ридеров и панелей на основе PN532 — в docs/NFC_PN532_INTEGRATION.md.

Это краткая версия. Вот что делает его отличным от других токенов, которые вы могли встречать.

Маскировка хранилища. Устройство может работать как обычное съёмное хранилище, чтобы его реальное назначение не было очевидным при беглом осмотре. При подключении к типичному компьютеру оно может отображаться как обычный USB-накопитель или том на SD-карте; вы можете заполнить видимую файловую систему правдоподобными повседневными файлами (например, фотографиями с отдыха), чтобы случайный просмотр усиливал впечатление, что это просто хранилище. Это затрудняет поверхностную проверку на рабочем столе или контрольно-пропускном пункте. Понять, что это на самом деле токен безопасности, обычно можно только разобрав корпус, а не просто подключив его.

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

Прошлые сеансы остаются в безопасности, даже если токен украден. Большинство аппаратных токенов используют долгосрочный приватный ключ напрямую для установления ключа. Этот генерирует новую одноразовую пару ключей для каждого сеанса, подписывает её долгосрочным ключом, чтобы доказать подлинность, а затем использует одноразовую пару для фактического обмена. Если кто-то украдёт токен через несколько лет и каким-то образом извлечёт долгосрочный ключ, он всё равно не сможет расшифровать ничего из прошлых сеансов. Это свойство называется совершенной прямой секретностью, и оно необычно для аппаратных токенов.

Вы можете разделить ключ между несколькими людьми. Токен может разделить долгосрочный ключ на N долей так, что для восстановления потребуется любые K из этих долей — но ни один держатель доли не может сделать ничего в одиночку. Это называется схемой разделения секрета Шамира. Это полезно для организационных ключей, где ни один человек не должен иметь одностороннего доступа, или как стратегия резервного копирования, когда доли хранятся в разных местах. Это также необычно для аппаратных токенов.

Шифрование слоёное. Вместо шифрования ваших данных одним шифром, токен может прогнать их через несколько независимых шифров последовательно — например, ChaCha20, затем Serpent, затем Twofish — каждый с отдельно выведенным ключом. Будущий прорыв, который взломает один шифр, не взломает остальные. Конкретная комбинация называется профилем шифра, и вы можете выбрать один из нескольких встроенных в зависимости от того, насколько осторожной должна быть ваша ситуация.

Моя личная рекомендация — BrainpoolP256r1 + ChaCha20-Poly1305 + BLAKE3. Это встроенный профиль standard. Он использует кривую BSI Brainpool P-256 для эфемерного согласования ключа, ChaCha20-Poly1305 для симметричного шифрования и BLAKE3 для вывода ключа и проверки целостности между слоями. Он быстрый, хорошо протестирован, экономичен для батареи (ChaCha20-Poly1305 был спроектирован для эффективной работы на оборудовании без аппаратного ускорения AES, снижая загрузку CPU и энергопотребление хоста; P-256 — наименьшая из трёх кривых Brainpool в этой прошивке) и не зависит ни от одного примитива, разработанного NIST. Если вам нужен больший запас прочности против будущего криптоаналитического прорыва против одного шифра, профиль conservative добавляет поверх слой Serpent-256.

Выбор алгоритмов не случаен. Используемые шифры — ChaCha20-Poly1305, Serpent, Twofish, Camellia — все были разработаны независимо от государственных органов стандартизации. AES и набор NIST намеренно исключены. Это осознанный выбор для пользователей и организаций, которые хотят криптографической независимости от процесса стандартизации какой-либо одной страны. Camellia был независимо оценён проектом EU NESSIE и программой CRYPTREC Японии и описан в RFC 3713 и ISO/IEC 18033-3.

Неправильный PIN блокирует вас по-настоящему. Токен считает неудачные попытки ввода PIN перед тем, как проверить, правилен ли PIN, а не после. Это означает, что сбой или потеря питания во время попытки не могут быть использованы для сброса счётчика. После слишком большого количества неудачных попыток токен обнуляет конфиденциальные материалы.

Что он пока не делает. Аппаратное обеспечение пока недоступно — это прошивка в активной разработке. Сквозное тестирование с реальным USB-оборудованием и GnuPG — будущая веха. Транспорт NFC и считыватели доступа типа дверных описаны в документации как цели интеграции, а не как реализованное поведение сейчас. Биометрический третий фактор, описанный в документации, ещё не реализован. Некоторые тесты на побочные каналы по времени, требующие реального оборудования, не могут быть завершены, пока не существует устройство.

Ключи GnuPG / OpenPGP и ключи Galdra

Galdralag может одновременно работать с двумя разными видами асимметричных ключей. Они отвечают на разные вопросы на устройстве и на хосте и не взаимозаменяемы, даже если принадлежат одному человеку. Разделы Совместимость с OpenPGP и GnuPG, Web of Trust и вечеринки подписания ключей, Метаданные контакта Galdra и Сравнение метаданных (GnuPG vs Galdra) описывают каждый стек подробнее; вот как они различаются в повседневных терминах.

Ключ OpenPGP, в том смысле, в котором GnuPG генерирует и использует его, — это структурированный пакет, а не голое открытое число. Он объединяет основной ключ, подключаем для подписи и шифрования и один или несколько User ID — обычно отображаемое имя и адрес электронной почты, например Alice Example <[email protected]>. Другие люди могут подписывать эти User ID, чтобы подтвердить, что они считают идентификационное заявление подлинным; этот социальный граф является основой web of trust, описанного в разделе Web of Trust и вечеринки подписания ключей далее в этом README. Когда Galdralag действует как смарт-карта OpenPGP, он хранит приватный ключевой материал на чипе и выполняет там подписание и расшифровку. Открытый ключ, User ID и подписи других людей живут на хосте и управляются GnuPG обычным образом. Токен не меняет формат сообщений OpenPGP на проводе; GnuPG обращается с ним как с любой другой картой OpenPGP.

Ключ Galdra — это голая асимметричная пара ключей — Ed25519, X25519 или одна из кривых Brainpool или NIST, которые поддерживает эта прошивка. Сами байты ключа не несут никаких заявлений об идентичности: нет пакетов User ID, нет встроенного email, нет подписей web of trust, прикреплённых к структуре ключа. Идентичность для ключа Galdra происходит из записи контакта, хранящейся рядом с ним в базе данных SQLite на хосте и хранилище контактов на чипе, привязанной к ключу по его отпечатку.

Сравнение метаданных (GnuPG vs Galdra)

В таблице ниже сравниваются метаданные идентичности и контакта поле за полем. Столбцы OpenPGP / GnuPG описывают, что вы получаете от обычного сертификата и User ID (плюс опциональные строки контактов на стороне хоста в Galdra, когда вы храните открытый ключ OpenPGP в том же каталоге). Столбцы Ключ Galdra описывают структурированные поля-спутники для операционных контактов (полные детали на хосте и чипе в Метаданные контакта Galdra). Прочерк означает, что у данного стека нет стандартного отдельного поля для этого элемента.

OpenPGP помещает имя и e-mail в одну строку User ID; он не предоставляет отдельных машиночитаемых полей для позывного, DMR или почтового адреса. Galdra хранит их в именованных столбцах, чтобы радио- и операционные команды могли искать и отображать их без разбора текста сертификата.

Токены, обновлённые с прошивки, предлагавшей BrainpoolP512r1, могут по-прежнему возвращать атрибуты P-512 на GET DATA; операции GnuPG на этих слотах затем завершаются с общей ошибкой карты. Запустите galdra device status (или см. docs/OPENPGP_CARD.md), чтобы определить устаревшие слоты; описание удаления см. в CHANGELOG.md. | PW1 / PW3 | Никогда не хранится | Верификатор на чипе (мин 5 символов, 3 попытки по умолчанию) | | DO владельца карты (логин, язык, URL, …) | Кэшируются GnuPG | Опционально (254 байта максимум на DO) |

Приложение карты 3.4.1, CCID и рабочие процессы GnuPG: docs/OPENPGP_CARD.md и Совместимость с OpenPGP и GnuPG.

Разделение существует, потому что информация об идентичности, которая важна в сообществах, на которые нацелен Galdralag — позывной, DMR ID, принадлежность к радиосети — не имеет естественного места в User ID OpenPGP. User ID предназначен для имени и email. Запись чего-то вроде LA5XYZ <[email protected]> DMR:2345678 в строку User ID неформальна, неструктурирована и машиночитаема только нестандартным образом. Ключи Galdra сохраняют криптографический материал чистым и помещают операционную идентичность в формат записи, который хост-инструмент и хранилище на чипе понимают нативно.

На практике одно устройство может содержать оба вида ключей без конфликтов. Приложение карты OpenPGP обслуживает GnuPG через стандартные слоты SIG, DEC и AUT. Хранилище контактов содержит ключи Galdra для операционной работы — например, шифрование для радиоконтакта по позывному, проверка сообщения по DMR-абонентскому ID или поиск коллеги по номеру бейджа. Эти два пути не пересекаются.Если у кого-то есть сертификат OpenPGP, управляемый GnuPG на хосте, и ключ Galdra в контактном хранилище на чипе, это два отдельных ключа с двумя разными отпечатками. Отпечаток Galdra — с префиксом G:, полученный с помощью BLAKE3 из сырых байтов открытого ключа — не является тем же значением, что и отпечаток OpenPGP v4 сертификата GnuPG этого человека. Инструмент на хосте и устройство обрабатывают их как независимые идентичности. Не предполагайте, что один отпечаток подразумевает другой, не проверив оба.

Ни один тип ключа автоматически не подтверждает достоверность связанных с ним меток. Идентификатор пользователя OpenPGP самодекларируем, пока кто-то другой не подпишет его. Позывной или поле DMR в контактной записи Galdra настолько же надежны, насколько надежен их источник — получение с сервера ключей, ручной ввод или проверка вне канала, выполненная вами лично. Метки происхождения (SelfAttested, HostVerified, RegistrySync, OobVerified) фиксируют как было получено поле; они не заменяют работу по фактической проверке интересующей вас личности.

Зачем Rust?

Эта прошивка написана на Rust, системном языке программирования, спроектированном быть таким же быстрым и низкоуровневым, как C или C++, но с принципиально другим подходом к безопасности.

Безопасность памяти

Большая часть критических для безопасности ошибок в промышленных кодовых базах проистекает из небезопасности памяти (переполнение буфера, использование после освобождения, разыменование null и тому подобное). MSRC от Microsoft неоднократно сообщал, что примерно 70% CVE, устранённых в их собственных продуктах, попадают в эту категорию; команда Chrome публиковала аналогичные доли для Chrome. Эти цифры описывают продукты этих поставщиков, а не универсальный закон для всей прошивки, но они иллюстрируют, почему языки с безопасной памятью имеют значение.

В безопасном Rust (по умолчанию) проверщик заимствований исключает гонки данных и обычные неопределённые ошибки памяти на этапе компиляции без использования сборки мусора. Небезопасный Rust и FFI к C всё ещё могут приводить к ошибкам памяти; они должны быть небольшими и проверяться.

Системная надёжность (с ограничениями)

Проверка границ Rust для срезов и его правила владения уменьшают несколько классов сбоев, распространённых во встраиваемом коде на C/C++:

• Разрушение стека и буфера, которые искажают поток управления, перехватываются на этапе компиляции в безопасном коде или через проверку индексации во время выполнения вместо молчаливого неопределённого поведения.
• Гонки данных в параллельном безопасном Rust отвергаются компилятором (взаимные блокировки не устраняются — см. ниже).
• Блоки unsafe должны быть явными; MMIO и сырые указатели для регистров находятся там, поэтому рецензенты могут выполнить grep по поверхности аудита (unsafe не делает некорректный MMIO невозможным, только упрощает его локализацию).

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

Защита ключевого материала (образцы проекта)

Эта кодовая база применяет распространённые образцы Rust для секретов; они не автоматически применяются к каждому типу:

• Типы, такие как zeroize::Zeroize / ZeroizeOnDrop, очищают буферы при удалении; вызывающий код должен явно их использовать.
• Сравнение секретов использует subtle::ConstantTimeEq (и подобное), когда важна синхронизация по времени — обычное == не является магически постоянным по времени.
• Отсутствие Copy на обёртках секретов уменьшает случайное дублирование; разделение областей действия использует отдельные типы и метки HKDF (Политика криптографических зависимостей).
• Поведение при панике и порядок удаления следуют правилам Rust; используйте стратегии catch_unwind или abort, если ваша платформа требует более строгих гарантий.

Проектирование для аудита

unsafe должно быть явно указано в исходном коде, что сужает область ручной проверки. Зависимости: криптографическая политика этого проекта отдаёт предпочтение аудированным крейтам Rust (RustCrypto и другим); см. таблицу в Политика криптографических зависимостей — не каждая зависимость происходит из одного зонтичного проекта.

Что Rust не предотвращает

Rust не устраняет взаимные блокировки (например, неправильный порядок захвата мьютексов Mutex), логические ошибки, некорректные протоколы, износ флеша из-за плохих циклов, физические атаки (сбои, анализ питания) или риски, связанные с корректной сборкой неправильного образа. Он также не гарантирует выполнение за постоянное время на любом оборудовании без тщательного программирования. Эти области полагаются на проектирование, рецензирование, тестирование и практики проекта в области криптографии и цепочки поставок, описанные в другом месте этого README.

Верификация (тесты и фаззинг): Помимо языка, этот репозиторий использует модульные тесты, интеграционные тесты, среды синхронизации dudect и мишени libFuzzer (cargo-fuzz). Краткие сводки и матрицы находятся в Результаты тестов; записанные метаданные запусков начинаются с docs/TEST_RESULTS.md#run-metadata. Успешные тесты не доказывают готовность к производству или отсутствие уязвимостей — они снижают риск. Вы решаете, приемлем ли запуск сборок или тестов в вашей среде; виртуальная машина не является обязательной, но ограничивает радиус поражения на вашей машине.

Настройка виртуальной машины для оценки

Подходит любая крупная платформа виртуальных машин — VirtualBox (бесплатно, с открытым исходным кодом), QEMU (бесплатно, с открытым исходным кодом, командная строка) или VMware. Рекомендуется гостевая ОС Linux, так как там среда сборки поддерживается наилучшим образом.

Быстрый старт с QEMU и Ubuntu:```bash

Install QEMU

sudo apt install qemu-system-x86 # Debian/Ubuntu host

or

brew install qemu # macOS host

Download an Ubuntu Server ISO and boot it

qemu-system-x86_64 -m 2G -cdrom ubuntu-24.04-live-server-amd64.iso

Внутри ВМ применяются стандартные инструкции по сборке. ВМ можно **снэпшотить** перед каждым экспериментом и **откатывать** обратно, если что-то пошло не так.

### Оценка рисков и развёртывание

**В конечном счёте, решение о том, безопасно ли развёртывать эту прошивку в вашей среде, можете принять только вы сами**, основываясь на собственной оценке рисков, чувствительности того, что вы защищаете, и на том, решите ли вы дождаться независимой сторонней аудиторской проверки перед развёртыванием. Этот проект стремится предоставить вам всю необходимую информацию для самостоятельного принятия этого решения.

Структурированный список активов, угроз **T1–T14**, явные нецели и пробелы проверки Q2 находятся в **[docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/THREAT_MODEL.md)**.

---

## О названии

**Galdr** — это древнескандинавская практика произнесённой или пропетой магии: заклинания, используемые для связывания, защиты или раскрытия. В сагах этим словом называют само действие произнесения заклинания, а не только слова. Иногда также используется для активации магических рунических надписей, как на [древке копья Крагехюль I](https://en.wikipedia.org/wiki/Kragehul_I), [амулете из Линдхольма](https://en.wikipedia.org/wiki/Lindholm_amulet), [брактеате из Вадстены](https://en.wikipedia.org/wiki/Vadstena_bracteate) и других находках старшего футарка.

**Galdralag** — это стихотворный размер, используемый для гальдра: структурированный, точный, следующий правилам стих, в котором шаблон является частью силы заклинания. Суффикс *lag* родственен слову «закон» или «шаблон».

**Руны** были буквально тайным, закодированным знанием — шаманское использование было известно только тем, кто понимал.

---

## Документация

**Глоссарий:** [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md) — термины, объяснённые **простым языком** (отсортированы А–Я). Начните здесь, если README или другие документы кажутся перегруженными жаргоном.

**Отладка:** [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/DEBUG_INSTRUCTIONS.md) — бэктрейсы, сужение `cargo test`, сокращения `xtask`, тройная проверка прошивки, фаззинг и что собрать перед сообщением о проблеме.

**ИИ-ассистенты (Claude, Cursor):** [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/CLAUDE.md) — инструкции по проекту для агентов кодирования. Специфичные для Cursor правила: [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/.cursor/rules/).

**Просмотр всех файлов:** [github.com/Supermagnum/Galdralag-firmware — `docs/`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs)

**Аппаратное обеспечение (USB-ключ и связанное):** Два дерева KiCad: [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-files-usb/) — `dabao_v3c` (USB-A токен **без** micro-SD); и [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/) — `dabao_v3c_sdcard` (та же базовая компоновка **с** micro-SD держателем), герберы, BOM, выходные файлы производства и [документация по выводам](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/docs/pinout/README.md). Компоновка печатной платы USB-A ключа (минимальный токен против Pico-формата для отладки) описана в [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md).

| Документ | Описание |
|----------|----------|
| [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-files-usb/) | **USB-ключ** проект KiCad `dabao_v3c` (без micro-SD); герберы, BOM, выходные файлы производства; дополняет [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) |
| [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/) | **USB-ключ** проект KiCad `dabao_v3c_sdcard` (держатель micro-SD); герберы, BOM, распиновка в [docs/pinout](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/docs/pinout/README.md); дополняет [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) |
| [docs/CODE_MAP.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CODE_MAP.md) | **Индекс функций и модулей** рабочего пространства (пофайлово `pub fn` / типы с привязкой к строкам) |
| [docs/CRATE_DEPENDENCIES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CRATE_DEPENDENCIES.md) | **Внешние и внутренние** Rust-крейты и их взаимозависимости |
| [docs/API_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/API_REFERENCE.md) | Карта кода + **приложение** для IETF/I-D/GnuPG/Sequoia: построение Shamir GF(256), броня GALDRA SHARE, формат эфемерного ECDH, метки HKDF, праобразы; маршруты `galdrad`; подсказки rustdoc |
| [docs/ARCHITECTURE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/ARCHITECTURE.md) | Высокоуровневая архитектура прошивки и основные подсистемы |
| [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/AUDIT_LOG.md) | Записи аудита профиля (`cipher-profile`), хук OpenPGP `OpenPgpAudit`; **журнал append-only RRAM пока не реализован** |
| [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/BIOMETRIC_API.md) | Биометрический предварительный шлюз: архитектура, формат данных, структура хранилища; интеграция частично реализована |
| [docs/BIOMETRIC_DEVICE_GUIDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/BIOMETRIC_DEVICE_GUIDE.md) | Как добавить поддержку нового биометрического аппаратного бэкенда |
| [docs/BIOMETRIC_TESTING.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/BIOMETRIC_TESTING.md) | Методология тестирования: метрики PAD ISO/IEC 30107-3, наборы данных, как запускать |
| [docs/FINGERVEIN_DEVICE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/FINGERVEIN_DEVICE.md) | ESP32-CAM открытое устройство сканирования вен пальца: аппаратное обеспечение, набросок протокола, определение живости |
| [docs/SWEET_PLATFORM_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/SWEET_PLATFORM_INTEGRATION.md) | Сканер руки sweet platform: аппаратное обеспечение, интеграция, определение живости, набор данных |
| [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md) | Инструменты хоста (`galdra`, `galdrad`, `galdra-gtk`): рабочие процессы, инициализация, политика PIN, поведение при эксплуатации |
| [Supermagnum/Fulla](https://github.com/Supermagnum/Fulla) | **Fulla**: WoT-ориентированный реестр открытых ключей OpenPGP (репозиторий и реализация сервера). **Публичный экземпляр реестра пока не запущен**; планируется один. **`galdra keyserver push`** / **`galdra keyserver fetch`** и необязательная конфигурация **`[keyserver]`** нацелены на эту экосистему — см. также [Web of Trust and Key Signing Parties](#web-of-trust-and-key-signing-parties). Дополнительные заметки по проектированию остаются в [docs/server.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/server.md). |
| [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md) | **Глоссарий простым языком** (А–Я) для нетехнических читателей; технические детали остаются в связанных документах |
| [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/CLAUDE.md) | Инструкции для **Claude** / ИИ-агентов кодирования; указывает на [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/.cursor/rules/) для **Cursor** |
| [docs/GALDRALAG_DEV_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRALAG_DEV_REFERENCE.md) | Инструментарий, команды `xtask`, точки входа для фаззинга и тестов криптографии |
| [docs/dev-ref.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/dev-ref.md) | Компоновка рабочего пространства, крейты, HAL-трейты, поведение USB/PSRAM, инварианты безопасности |
| [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/DEBUG_INSTRUCTIONS.md) | Отладка: `RUST_BACKTRACE`, подробные сборки, ограниченные тесты, рецепты `xtask`, проверки встроенных целей, указатели по фаззингу, проверки хоста OpenPGP |
| [docs/KEY_LIFECYCLE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/KEY_LIFECYCLE.md) | Генерация ключей, импорт, политика экспорта, ротация, обнуление, Shamir (как отражено в `vault` / OpenPGP) |
| [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md) | Приложение OpenPGP card, настройка хоста GnuPG/CCID, слоты ключей, алгоритмы, udev |
| [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CIPHER_PROFILES.md) | Система и конфигурация шифровальных профилей |
| [docs/CIPHER_PROFILE_SECURITY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CIPHER_PROFILE_SECURITY.md) | Соображения безопасности: идентификаторы профилей в открытом виде, анализ трафика, обоснование внешней обёртки BrainpoolP384r1, зашифрованные идентификаторы, свойство подстановочного знака |
| [docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CESS_CONFORMANCE.md) | Соответствие [CESS](https://github.com/Supermagnum/CESS/tree/main): проводная компоновка режима A, `suite_id` из [ALGORITHM-REGISTRY.md — таблица поиска](https://github.com/Supermagnum/CESS/blob/main/ALGORITHM-REGISTRY.md#cipher-suite-identifier-lookup-table), журнал отклонений (сохранённые AES/SHA-2 против CESS-CORE), дорожная карта |
| [crates/cess](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/crates/cess) | Режим A CESS: HKDF-BLAKE3 (`derive_k_outer`, `hkdf_blake3`), внешняя запаковка/распаковка ChaCha, компоновка `suite_id \|\| inner_blob`; см. [CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CESS_CONFORMANCE.md) |
| [docs/EPHEMERAL_SESSION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/EPHEMERAL_SESSION.md) | Аутентифицированный протокол эфемерной сессии ECDH |
| [Supermagnum/CESS](https://github.com/Supermagnum/CESS) | **CESS** (*Cryptologically Enchanted Shamir's Secret*) — открытая спецификация (нормативный текст и тестовые векторы) для порогового разделения секрета с аутентифицированным шифрованием, защитой долей паролем и дополнительным пост-квантовым гибридным обменом ключами; отдельно от этой прошивки, но в той же области проектирования, что и Shamir и шифровальные профили здесь |
| [docs/PQ_SIGNATURES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/PQ_SIGNATURES.md) | Пост-квантовые подписи с сохранением состояния (XMSS, LMS/HSS), управление функциями |
| [docs/Psram.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/Psram.md) | Необязательный том-приманка microSD и связанное поведение |
| [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/RRAM_LAYOUT.md) | **4 194 304 байта** встроенной RRAM: смещения хранилища из исходного кода, отображение HAL, заметки по износу / обнулению |
| [docs/TEST_RESULTS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/TEST_RESULTS.md#run-metadata) | Открывается на **Метаданные запуска**; сводка конвейера, векторы, dudect, cargo-fuzz ([Раздел 6](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/TEST_RESULTS.md#6-cargo-fuzz-libfuzzer)), жизненный цикл ключей |
| [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/THREE_FACTOR_AUTH.md) | Токен + PIN + необязательная биометрия: что реализовано в этом репозитории против заглушки; набросок угрозы |
| [docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/THREAT_MODEL.md) | Модель угроз: активы, угрозы T1–T14, что защищается и не защищается, непроверенные позиции в ожидании аппаратного обеспечения Q2, статус аудита |
| [docs/PERFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/PERFORMANCE.md) | Заметки о производительности |
| [docs/HARDWARE_BRINGUP_TEST_PLAN.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_BRINGUP_TEST_PLAN.md) | План первого запуска аппаратного обеспечения Q2: перечисление CCID, `gpg --card-status`, USB CDC `galdralag-provision` для первых PIN-кодов при загрузке, затем `gpg --card-edit` / криптографические тесты |
| [docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_VERIFICATION.md) | Аппаратное обнуление: симуляция против верификации на кремнии |
| [docs/HARDWARE_TEST.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_TEST.md) | Заметки по аппаратно-ориентированному тестированию |
| [docs/NFC_PN532_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/NFC_PN532_INTEGRATION.md) | PN532 / NFC: libnfc, опции Rust, пассивная дверь против USB-панели, кворум с Shamir и PIN |
| [docs/SDMMC_STORAGE_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/SDMMC_STORAGE_INTEGRATION.md) | `embedded-sdmmc` + SPI microSD как дополнительное массовое хранилище; альтернатива BOM вместо PSRAM |
| [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) | Как сделать печатную плату USB-A ключа из эталонного проекта Dabao: Pico-формат оценки предназначен для отладки прошивки; здесь убран разъём GPIO для минимального токена; KiCad, FreeCAD, 5 В / 500 мА против USB-C PD, разводка QSPI PSRAM |

Те же пути разрешаются на GitHub по адресу [`tree/main/docs`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs) и [`tree/main/Hardware`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/Hardware).

---

## Совместимость с OpenPGP и GnuPG

Прошивка реализует **приложение OpenPGP card** (документировано как версия **3.4.1** в [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md)). Это тот же класс устройств, которыми GnuPG управляет для **смарт-карт OpenPGP** через **CCID/USB**: хосту нужен обычный стек смарт-карт (`pcscd`, драйверы `ccid`, `scdaemon` от GnuPG). **Не требуется пользовательский хост-драйвер криптографии** помимо того, который вы бы использовали для любой карты OpenPGP.

**Что это позволяет на хосте (как только устройство станет видимо как считыватель CCID):**

| Область | Примечания |
|---------|------------|
| **Рабочие процессы GnuPG** | `gpg --card-status`, `gpg --card-edit`, шифрование/дешифрование и подпись с использованием ключей на карте |
| **SSH** | `gpg-agent` с `enable-ssh-support` и обычной настройкой `SSH_AUTH_SOCK` |
| **Почта и файлы** | Клиенты, использующие GnuPG (например, Thunderbird, Evolution, Kleopatra) и стандартное файловое шифрование `gpg` |
| **Другие инструменты** | Всё, что общается с картой OpenPGP + CCID так же, как GnuPG |

**Слоты ключей (типичные значения по умолчанию):** **SIG** (подпись), **DEC** (дешифрование / ECDH), **AUT** (аутентификация, например SSH). Алгоритмы выбираются для каждого слота (кривые Brainpool, NIST P-256/P-384, Ed25519 / X25519, RSA). Полная таблица и поведение `key-attr` — в [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md).

**Что здесь не покрывается OpenPGP card / GnuPG:** **WebAuthn / FIDO2** — это другой протокол и выходит за рамки этого приложения карты (см. тот же документ).

**OpenPGP card против сообщений OpenPGP:** Спецификация **карты** определяет, как токен раскрывает PIN-коды, слоты ключей и операции на карте через CCID. **GnuPG** использует это через `scdaemon`. **Формат сообщений OpenPGP** для файлов и почты (RFC 4880 и последующие) — это **хост-уровень**: карта предоставляет ключи; GnuPG всё равно применяет формат сообщений на ПК. Ни спецификация карты, ни RFC 4880 не определяют **разделение Shamir**, **эфемерные сессии ECDH** или **шифровальные профили** — это [специфичные для прошивки](#standards-vs-firmware-specific-features).

**Статус интеграции:** Логика OpenPGP и CCID находится в **`usb-personality`**, **`baochip-openpgp`** и **Xous** **`usb-bao1x`** сервисе (см. **xous-core**). Опциональный **`galdralag-service`** (`services/galdralag`) работает как отдельный процесс Xous, подключается к **`usb-bao1x`** для **CCID** IPC и перенаправляет данные инициализации **PDDB** в **RRAM**; сборка и регистрация **`baosec`**: [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/services/galdralag/README.md) и **`cargo run -p xtask -- build-and-register`**. Расположение памяти: [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/RRAM_LAYOUT.md). **Для сквозной работы GnuPG на реальном оборудовании** всё ещё нужен полный образ Xous (с **`ccid-openpgp`**), работающий стек CCID хоста (`pcscd`, драйвер) и элементы из [Известные ограничения / открытые работы](#known-limitations--open-work), решённые в той мере, в какой они применимы к вашей целевой поставке.

## Сессия токена и экспорт ключей

**Физическое отключение (извлечение):** Хост теряет USB-устройство; любая выполняемая операция прерывается до повторного подключения и перечисления токена. На устройстве **сессия карты OpenPGP** очищается: **состояние верификации PIN** не сохраняется после выключения питания или извлечения, поэтому **подпись, дешифрование и другие защищённые операции требуют VERIFY PIN снова** после повторного подключения, как и другие смарт-карты OpenPGP. **Материал закрытых ключей остаётся на токене** в защищённом хранилище; извлечение не стирает его, если не запущен отдельный путь **обнуления** или очистки.

**Что может покинуть устройство:** По замыслу, **только материал открытых ключей** может пересекать USB-соединение (например, **открытые** пакеты ключей OpenPGP и связанные данные, которые спецификация карты раскрывает хосту). **Закрытые** ключи, сырые секретные скаляры и запечатанные блоки ключей **не покидают** устройство через обычные пути прошивки; операции с закрытыми ключами выполняются **на токене**. Хост получает **криптографические результаты** (подписи, расшифрованный открытый текст для рабочих процессов дешифрования с поддержкой карты) там, где это требуют стандартные команды, а не портативную копию закрытого ключа.

**Импорт ключей на устройство:** Также возможно **импортировать открытые ключи** в токен (например, доверенные центры, сертификаты пиров или открытые пакеты OpenPGP для верификации на устройстве). **Хранилище** прошивки предоставляет **слоты для открытых ключей** для несекретного материала (`crates/vault/src/public_key_vault.rs`). Инструменты хоста для загрузки этих слотов описаны в [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md) по мере созревания интеграции.

---

## Web of Trust и вечеринки по подписанию ключей

OpenPGP и **GnuPG** используют децентрализованную модель доверия — **сеть доверия** — для помощи в проверке того, кто владеет какими ключами и стоит ли полагаться на данный **открытый ключ**. Эта модель полностью **на стороне хоста**. Там, где заверения на основе чипа, такие как [German eID and Governikus](#german-eid-and-governikus-as-a-trust-anchor-for-public-keys), недоступны или неуместны, это обычная децентрализованная альтернатива (**вечеринки по подписанию ключей**, подписи на сертификатах); где они **доступны**, оба подхода могут сосуществовать как взаимодополняющие пути.

**Отпечаток Galdralag (`G:`):** Для рабочих процессов верификации лицом к лицу **Galdra** может показать **привязанный к устройству** отпечаток, полученный из открытого ключа **SIG** токена (**BLAKE3-160**, префикс `G:`). Это **не** отпечаток сертификата OpenPGP v4. Он **доступен только** когда активный **шифровальный профиль** имеет **`ephemeral_ecdh: false`**; встроенные профили по умолчанию имеют **`ephemeral_ecdh: true`**, поэтому обычно добавляют пользовательский профиль с **`galdra profile add ... --no-ephemeral-ecdh`** для рабочих процессов, которым нужен этот идентификатор наряду с подписью хоста в стиле **WoT**. Определение простым языком и спецификация формата: [Отпечаток Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md#g). Жизненный цикл, политика ротации и шлюз эфемерного ECDH: [KEY_LIFECYCLE.md — Отпечаток Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/KEY_LIFECYCLE.md#galdralag-fingerprint-host).

### Получение вашего отпечатка Galdralag

Хост выводит строку, которая **всегда начинается с `G:`** (BLAKE3-160 от байтов открытого ключа SIG, **40 шестнадцатеричных символов нижнего регистра** после префикса в канонической форме).

1. Установите **[Galdra](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md)** на хост и убедитесь, что **PC/SC** работает (**`pcscd`**, **`libpcsclite`**), чтобы инструмент мог общаться с токеном по CCID (см. [Сборка и установка инструментов хоста](#compile-and-install-host-tools-galdra-galdrad-galdra-gtk)).
2. Подключите токен (разблокируйте, если ваш рабочий процесс это требует).
3. Выберите **шифровальный профиль** с **`ephemeral_ecdh: false`**. Подтвердите с помощью **`galdra profile show <name>`** (`ephemeral_ecdh: off`). Имя профиля по умолчанию **`standard`** обычно имеет **`ephemeral_ecdh: on`**; при необходимости создайте профиль с **`galdra profile add <name> ... --no-ephemeral-ecdh`**.
4. Выполните:```bash
galdra identity fingerprint
# If you use a non-default profile:
galdra identity fingerprint --profile <name>

Машиночитаемый вывод: galdra --emit json identity fingerprint (опционально --profile <name>).

Что такое сеть доверия?

Реализации, совместимые с OpenPGP, включают схему проверки сертификатов для помощи в подтверждении принадлежности ключа; её работу называют сетью доверия. Сертификаты OpenPGP (один или несколько открытых ключей плюс данные владельца/идентификатора пользователя) могут быть цифрово подписаны другими пользователями, которые тем самым подтверждают связь между этим открытым ключом и лицом или организацией, указанными в сертификате.

Как это работает

1. Распространение ключей. Вы публикуете или отправляете свой открытый ключ (например, созданный с помощью gpg --full-generate-key на хосте или хранящийся на токене, поддерживающем OpenPGP).
2. Проверка личности. Другие проверяют, что открытый ключ действительно принадлежит вам — обычно лично или через каналы, которым они уже доверяют.
3. Подписание ключа. Убедившись, они подписывают ваш сертификат своим собственным закрытым ключом.
4. Распространение доверия. Каждая подпись добавляет подтверждение в сеть; люди, доверяющие подписывающему, могут распространить частичное доверие на ваш ключ в соответствии с настройками доверия GnuPG.

Вечеринки подписания ключей

Вечеринка подписания ключей — это личная встреча, на которой участники обмениваются отпечатками ключей и проверяют личности друг друга перед последующим подписанием сертификатов.

Характерные особенности:

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

Это создаёт социальный граф: если Алиса доверяет Бобу, а Боб подписал ключ Чарли, Алиса может решить доверять ключу Чарли в зависимости от глубины доверия и политики.

Почему такие мероприятия важны:

• Личная проверка может быть надёжнее чисто удалённого подтверждения привязки ключа к человеку.
• Сеть доверия. Доказательства распространяются за пределы парных встреч для тех, кто использует собственное доверие и цепочки подписей.
• Норма сообщества. Используется в кругах радиолюбителей, проектах с открытым исходным кодом и криптографических конференциях.
• Операционная гигиена. Снижает вероятность использования неправильных или подменённых ключей при соблюдении процедур.

Типичный рабочий процесс на вечеринке подписания ключей

На вечеринках обычно избегают использования компьютеров во время обмена личностями, чтобы у злоумышленников было меньше шансов подсунуть подменённые ключи или вредоносное ПО на общие машины.

До мероприятия. Вычислите и запишите свой отпечаток (полученный из хеша дайджест открытого ключа — достаточно короткий для надёжного сравнения). Не полагайтесь на обмен полными ключами на бумаге на этом этапе, если только организаторы не укажут иное.```bash

Key fingerprint for YOUR_KEY_ID (example)

gpg --fingerprint YOUR_KEY_ID

Bring the fingerprint on paper or another durable medium (example shape: `ABCD 1234 EFGH 5678 90AB CDEF 1234 5678 90AB CDEF`).

**At the event (fingerprints only).** Exchange **fingerprints**, verify IDs, and note which fingerprints belong to which verified person. Confirm each participant's claimed identity matches the documents checked.

**After the event.** Fetch full **public keys** from **keyservers** or direct distribution; confirm downloaded keys match the **fingerprints** recorded on paper; **sign** the keys you verified; optionally **upload** signatures so others can use them.

### Fingerprints instead of full keys at the event

- **Operational security.** Keeps substitution attacks tied to verified fingerprints rather than trusting arbitrary machines mid-event.
- **Simplicity.** Fingerprints fit on paper and are quick to read aloud or compare.
- **Verification.** After download, recomputing the fingerprint checks integrity end-to-end.

### Keyservers

**Keyservers** are networked repositories that store and replicate **public** OpenPGP keys (and updates such as signatures and revocations). They make keys discoverable by **User ID**, **key ID**, or **fingerprint** and underpin wide-area distribution for the web of trust.

How they behave in principle:

- **Distributed replication.** Uploading to one server participating in a sync mesh often propagates to peers (classic **SKS**-style pools worked this way).
- **Synchronisation.** New keys, signatures, and revocation certificates spread according to each server's policy and connectivity.
- **Public read access.** Only **public** material is intended for publication; **private keys** must never be uploaded.

**Privacy.** Published keys expose **User IDs** (often including mail addresses). Treat uploads as **public and long-lived** on many servers; upload **revocation certificates** when a key must be retired. Policy varies by operator ([keys.openpgp.org](https://keys.openpgp.org/) differs from legacy pools).

**Peer topology.** Graphs of server relationships appear at [spider.pgpkeys.eu/graphs/](https://spider.pgpkeys.eu/graphs/); SKS-oriented peer listings at [spider.pgpkeys.eu/sks-peers](https://spider.pgpkeys.eu/sks-peers).

### Using keyservers```bash
# Upload your signed key (after local signing)
gpg --send-keys YOUR_KEY_ID

# Search by mail or name (behaviour depends on keyserver configured in gpg.conf)
gpg --search-keys [email protected]

# Refresh imported keys from configured keyservers
gpg --refresh-keys

Общие серверы ключей

Лучшие практики и предостережения

• Публикуйте свой открытый ключ (или подписи на ключах других), если ваша политика допускает более широкое обнаружение.
• Периодически запускайте gpg --refresh-keys, чтобы отзывы и новые подписи распространились локально.
• Подпись ключа подтверждает связь с личностью, а не криптостойкость — подписывайте только после соразмерной проверки.
• Подпись означает: вы удостоверяете, что этот открытый ключ на момент подписи принадлежал проверенной личности; остальные всё равно выбирают пути доверия самостоятельно.
• Перед публикацией отпечатка Galdralag убедитесь, что в активном профиле установлено ephemeral_ecdh: false с помощью galdra profile show <name>.

За авторитетным поведением gpg, моделями доверия и параметрами распространения обращайтесь к руководству GnuPG и вышестоящей документации.

Проект Fulla (Supermagnum/Fulla на GitHub) содержит работу над сервером реестра, ориентированным на WoT: реализацию и развивающуюся спецификацию для хранения открытых ключей участников, а также опциональных любительских радиометок, почтовых подсказок, полей organisation (JSON-написание), role, note, badge_number, phone_number и сопутствующих колонок, согласованных с контактными метаданными Galdra. galdra keyserver push отправляет JSON-запрос POST /api/v1/keys (включая armored_public_key, email и те опциональные поля, если вы передаёте флаги CLI); galdra keyserver fetch и раздел конфигурации [keyserver] реализованы в / в этом направлении. ; в будущем ожидается общедоступный сервис. Дополнительный исторический текст проекта находится в .

Стандарты против специфичных для прошивки возможностей

Разные части этого проекта соответствуют разным стандартам. Совместимость с GnuPG ограничена тем, что определяют приложение OpenPGP-карты и CCID. Другие возможности реализованы в прошивке (а иногда и в хост-инструментах Galdra), но не могут быть вызваны через стандартные рабочие процессы gpg --card-edit.

Для повседневного поведения карты обращайтесь к docs/OPENPGP_CARD.md. Для только хранилища или уникальных для токена возможностей используйте прошивку этого репозитория и документацию по инструменту Galdra.

Схема Шамира (Shamir secret sharing) и шифрование диска

Стеки OpenPGP-карты и GnuPG не определяют разделение секрета Шамира (SSS) для ключей или для разблокировки диска. SSS всё же полезен совместно с обычным шифрованием: он почти никогда не заменяет симметричный шифр на диске — он защищает маленький секрет (мастер-ключ или парольную фразу), который разблокирует это шифрование.

Схема (всегда одна и та же идея):

Распространённые реальные подходы

1. LUKS (Linux) и внешний SSS

LUKS шифрует том мастер-ключом. Вы можете извлечь этот ключ (или секрет ключевого слота, в зависимости от процедуры), разделить его с помощью SSS-инструмента и сохранить доли отдельно. При разблокировке объедините K долей, восстановите ключевой материал и передайте его в cryptsetup (см. документацию вашего дистрибутива; неправильное обращение с ключами может заблокировать доступ).

Примерная схема с использованием утилит ssss ("Shamir's Secret Sharing Scheme") (имена и пакетизация различаются в зависимости от ОС):```bash

Example: 3-of-5 split of a file containing key material (illustrative only)

ssss-split -t 3 -n 5 < luks_master.key

Later: combine shares, then unlock (adapt device path and cryptsetup flow)

ssss-combine -t 3 | cryptsetup luksOpen /dev/sdX vault

**2. HashiCorp Vault**

[Vault](https://www.hashicorp.com/products/vault) использует Shamir для **распечатывания (unseal)**: ключ шифрования хранилища разделяется при инициализации (например, 3 из 5 операторов держат по доле). После перезапуска необходимо ввести **K** долей для распечатывания. Та же схема **K из N для главного секрета**, что и в LUKS, но применяется к механизму секретов, а не к блочному устройству.

**3. Прошивка Galdralag (`vsss-rs`)**

Этот репозиторий использует [`vsss-rs`](https://crates.io/crates/vsss-rs) (экосистема RustCrypto) для встроенного Shamir. Такое же **многоуровневое** применение применимо, если совместить его с массовым шифрованием:

- Сгенерировать случайный 256-битный (или соответствующий) мастер-ключ.
- Зашифровать диск или массовое хранилище с помощью **AES-GCM** или **ChaCha20-Poly1305**, используя этот ключ (это соответствует проверенным симметричным крейтам рабочей области).
- Использовать `vsss-rs` для разделения мастер-ключа на **N** долей с порогом **K**.
- Хранить доли в слотах хранилища, на других устройствах или у держателей ключей.
- При загрузке или восстановлении собрать **K** долей, восстановить, затем использовать **HKDF** (или вашу политику) для разделения на доменные подключа при необходимости.

**4. VeraCrypt**

VeraCrypt не реализует SSS внутренне. Применяется тот же **внешний** подход: разделите **парольную фразу или материал ключевого файла** с помощью SSS-инструмента; не пытайтесь разделить по Шамиру зашифрованный текст тома.

### Гибридный подход (большие данные)

SSS предназначен для **маленьких секретов** (размер ключа). Вы **не** применяете Shamir к многогигабайтному зашифрованному тексту. Обычное многоуровневое применение:```text
[Drive data]
    encrypted by
[Symmetric master key, e.g. 32-byte AES-256]
    split by SSS into
[Share 1] [Share 2] ... [Share N]
    (each share may be wrapped with a recipient's PGP key, HSM, or offline media)

Это согласуется с тем, что уже использует этот проект: aes-gcm / chacha20poly1305 для данных в состоянии покоя, vsss-rs для разделения мастер-секрета, hkdf для вывода после восстановления.

Ключевые практические решения

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

Shamir плюс Brainpool: пример и институциональная применимость

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

Почему кривые Brainpool (например, BrainpoolP256r1, BrainpoolP384r1) часто обсуждаются в этом контексте:

• BSI (федеральное ведомство по кибербезопасности Германии) требует Brainpool во многих профилях развёртывания; требования появляются в политиках закупок и регулирования ЕС и НАТО.
• Параметры полностью специфицированы и проверяемы в RFC 5639, что снижает опасения по поводу "ничего не подозрительного" по сравнению со старыми спорами о методах генерации некоторых кривых NIST.
• Прецедент IETF: RFC 5639 уже находится на пути стандартизации для этих кривых.

Read more