supermagnum/galdralag-firmwareКриптографическая платформа для Baochip-1x.
Этот проект зарегистрирован в Open Invention Network (OIN). OIN — это оборонительный патентный пул: участники перекрёстно лицензируют патенты, связанные с Linux, чтобы участники могли поставлять и использовать открытое программное обеспечение с меньшим патентным риском.
Статус: ожидание: https://github.com/betrusted-io/xous-core/pull/937
Прошивка для устройств 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 ведёт локальный каталог SQLite получателей (контактов). Каждая сохранённая личность включает материал открытого ключа плюс необязательные боковые метки (см. таблицу ниже). Эти теги хранятся в базе данных хоста и, для ключей Galdra, в хранилище контактов на чипе (crates/contact-store). Они не магически привязаны к идентификаторам пользователей OpenPGP, если вы не выровняете их самостоятельно, и они не подтверждаются криптографически, если вы не проверите их вне полосы. Необязательная команда galdra keyserver push может отправлять пересекающиеся поля в проектный реестр в виде JSON вместе с экспортированным открытым ключом. Происхождение каждого поля на токене использует SelfAttested, HostVerified, RegistrySync и OobVerified (см. Сравнение метаданных (GnuPG против 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 и функциями, специфичными для репозитория (профили шифров — вы можете накладывать до четырёх различных симметричных шифров в одном каскаде, каждый со своим производным ключом; см. Ключевые возможности), потоками, связанными с Shamir, аутентифицированным эфемерным ECDH там, где он реализован, и хост-инструментами Galdra). Основная цель совместимости — стиль GnuPG использования карты OpenPGP, а не каждый протокол токенов на рынке.
Эта прошивка не является:
Исключения на уровне крейтов, согласованные с теми же ограничениями, перечислены в разделе Крейты, явно исключённые в docs/future-todo.md.
CESS: Эта прошивка соответствует CESS для нормативных конструкций, реализованных в дереве (включая режим A внешний AEAD, HKDF-BLAKE3 для K_outer и побайтовое разделение Shamir в 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. Пробелы предпроизводственного этапа (UX операторского PIN, утверждение карты платформы): Известные ограничения / открытая работа.
Общая цель остаётся прежней — полная, протестированная прошивка аппаратного токена безопасности с открытым исходным кодом: поведение в стиле карты OpenPGP для GnuPG через CCID (см. Совместимость с OpenPGP и GnuPG), плюс дополнительные функции на устройстве, не определённые в настоящее время стандартом карты OpenPGP — эфемерный ECDH с прямой секретностью, Shamir K-of-N, агностические профили шифров, том-приманка microSD — как обобщено в Стандарты против функций, специфичных для прошивки. Всё на открытом RTL с воспроизводимым загрузчиком.
Для развёртываний, которым нужны два отдельных физических токена (или держатели долей K-of-N) перед разблокировкой серверов, межсетевых экранов, медицинских хранилищ или зашифрованных томов, см. Кворум из двух аппаратных ключей (паттерн интегратора) в разделе Ключевые возможности. Каждое устройство — это один источник учётных данных; обеспечение кворума — это ваш шлюз доступа, слой PAM или панель — не эта прошивка.
Поставляемая прошивка для Baochip-1x подписана с помощью Ed25519. Вы подписываете образ прошивки приватным ключом Ed25519; GnuPG может сделать это с помощью gpg --sign, используя подключ подписи Ed25519 (обычный рабочий процесс отсоединённой подписи OpenPGP, адаптированный к тому, что выдаёт ваша сборка). Неизменяемый ROM boot0 в SoC проверяет эту подпись на соответствие соответствующим открытым ключам, запрограммированным в устройство (и более широкому манифесту ключей для цепочки загрузки) до того, как следующему этапу — boot1 — будет разрешено запуститься. Затем boot1 загружает подписанные образы приложений (например, блобы UF2, доставляемые через USB mass storage в режиме загрузчика). Стандартные части несут четыре встроенных открытых ключа Ed25519 (роли, такие как развёртывание кода, бета и разработчик); boot0 / boot1 обеспечивают политику взаимного недоверия между ключами подписи Baochip и сторонних разработчиков. Полный поток загрузки, доставка UF2, консоль, обновления boot1 и модель безопасности: Getting Started with Baochip Targets в xous-core.
Не каждый тест запускается в каждой команде; это намеренно.
xtask не в тесте рабочего пространства по умолчанию: Обычный рецепт — cargo test --workspace --exclude xtask, потому что xtask — это крейт оркестрации сборки. Запустите cargo test -p xtask, когда хотите его тесты.#[ignore]: Они пропускаются, если вы не передадите --ignored (и любые необходимые фильтры крейтов). Причины включают: покрытие, которое уже проверяется в сфокусированных модульных тестах (например, затирание после удаления), медленные случаи (например, генерация ключей RSA) и зависящие от оборудования или токена потоки в хост-инструментах, таких как galdra, которым нужно подключённое устройство или фикстуры.test-all --no-fuzz: Пропускает шаг cargo-fuzz, чтобы сократить CI или быстрые запуски и избежать требования nightly toolchain для этого шага; запустите cargo run -p xtask -- test-all без --no-fuzz или вызовите fuzz-цели отдельно (см. ).Также можно проверить целостность крейтов с помощью этого, когда PR будет закрыт: https://github.com/rust-lang/cargo/issues/16850
Статус: Готов к тестированию людьми на реальном оборудовании — готового к производству релиза не существует. Он написан на Rust с использованием проверенных и аудированных криптографических крейтов. Криптографические примитивы взяты исключительно из аудированных зависимостей рабочего пространства. Постквантовые алгоритмы находятся за функциональными флагами и помечены ОЖИДАЕТ НЕЗАВИСИМОГО АУДИТА. См. Постквантовый статус.
Примечание: Части этого проекта были разработаны с помощью ИИ (Claude, Anthropic). Дизайн, криптографические выборы и решения по безопасности не были проверены профессиональным криптографом. Относитесь к этому как к экспериментальному проекту и применяйте собственное критическое суждение. Независимый экспертный обзор настоятельно рекомендуется перед любым производственным развёртыванием.
Он готов к тестированию людьми. Вы решаете, собирать или запускать любое из этого программного обеспечения; могут быть ошибки, которые модульные тесты, фаззинг и другие проверки не обнаружили. Использование необязательной виртуальной машины для экспериментов снижает риск для вашей хост-системы, но не устраняет его. Подробные результаты находятся в Результаты тестов (docs/TEST_RESULTS.md#run-metadata). Определения простым языком (А–Я) технических терминов: Глоссарий.
Основной разработчик имеет неврологическое состояние, связанное с дискалькулией. Дискалькулия влияет на чувство числа и связанную символьную обработку таким образом, что для него традиционное программирование — ручное редактирование кода как единственный рабочий процесс — не работает без вспомогательных инструментов (например, диалоговых ИИ-редакторов). Это ограничение отличается от корректности: рецензенты всё равно должны взвешивать тесты, фаззинг и независимый аудит, как документировано в другом месте этой страницы.
Криптограф или серьёзный разработчик, просматривающий Galdralag, обычно откроет crates/vault/tests/ и crates/cipher-profile/tests/, прежде чем читать прозу. Набор тестов — это доказательство работы: он кодирует предметные знания, которые нельзя заменить одним повествованием.
Это не причина скрывать суть от всех остальных. Люди, оценивающие проект для закупки, решающие, стоит ли вносить вклад, или поставляющие код без глубокой подготовки в методологии криптографического тестирования, всё равно заслуживают указатель на конкретные доказательства.На что смотреть: Материалы для проверки соответствия включают рабочие примеры из RFC 8439 для ChaCha20-Poly1305 в crates/vault/tests/rfc_vectors/, вендорные JSON-файлы Wycheproof для ChaCha20-Poly1305 и граничных случаев Brainpool ECDH/ECDSA в 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 (на основе разработок Дэниела Бернштейна) и включает конкретные рабочие примеры с заданными входными данными и ожидаемыми результатами, чтобы независимые реализации могли проверить точное соответствие стандарту байт в байт. Широко воспроизводимый открытый текст, начинающийся с Ladies and Gentlemen of the class of '99: wear sunscreen, присутствует в примерах приложения RFC: если ваш код воспроизводит выходные данные AEAD точно, это сильная проверка того, что вы правильно реализовали конструкцию. Это криптографический аналог официального ключа ответов. ChaCha20-Poly1305 — внутренний слой каждого многослойного каскадного профиля в этой прошивке, поэтому эта проверка лежит в основе всего стека шифров.
Wycheproof — тестовый корпус, выпущенный командой безопасности Google (2017). Название отсылает к горе Уайчепроф в Австралии — часто называемой самой маленькой горой в мире — потому что проект сосредоточен на устранении малых, но фатальных препятствий: переполнений целых чисел, граничных случаев, некорректных входных данных и подделанных тегов аутентификации; сбоев, которые регулярно проявляются в реально развёрнутой криптографии. Он дополняет векторы в стиле 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 — официальный тестовый корпус, опубликованный авторами вместе со спецификацией BLAKE3. Они охватывают 35 длин входных данных от 0 до 102400 байт, специально выбранных для проверки всех внутренних граничных условий хеширования чанков и деревьев, невидимых для тестов с короткими входными данными. Покрыты все три режима BLAKE3 — обычное хеширование, хеширование с ключом и вывод ключа. BLAKE3 используется по всей этой прошивке для вывода ключей HKDF и проверок целостности между слоями в каскадных профилях шифров; покрытие граничных случаев важно, потому что древовидная конструкция BLAKE3 активируется только выше 1024 байт.
Тестовый набор также является обнаружением вмешательства в цепочку поставок. Все криптографические примитивы в этой прошивке происходят из проверенных крейтов RustCrypto — никакая криптография не реализована внутри дерева исходников. Поскольку приведённые выше векторы соответствия выполняются против этих крейтов при каждом cargo test --workspace, любая зависимость, которая была подделана или заменена, вызовет сбой теста с известным ответом до того, как скомпрометированный код достигнет развёрнутой системы. python3 scripts/verify_cascade_kats.py добавляет второй независимый путь: реализация на Python проверяет те же промежуточные значения в KAT-фикстуре каскада, так что даже скомпрометированный инструментарий Rust, выдающий неверные результаты, будет обнаружен перекрёстной проверкой. Это значительно более сильная история целостности цепочки поставок, чем привязка к библиотеке на C, где эквивалентная проверка каждой внутренней операции требует значительно больше усилий и специализированных инструментов.
Теперь читателю предстоит судить, ложны ли эти утверждения.
Вы подключаете его в USB-порт. С точки зрения хоста прошивка может представлять крипто-режим или режим маскировки. В крипто-режиме ваш компьютер видит смарт-карту: вы используете GnuPG или совместимый стек OpenPGP (Что такое GnuPG?) так же, как любой другой аппаратный токен безопасности — токен выполняет чувствительные криптографические операции, поэтому ваши закрытые ключи никогда не существуют незащищёнными на вашем компьютере. В режиме маскировки он может определяться как обычный сменный накопитель с безобидными файлами, чтобы быстрый взгляд не раскрыл его настоящую роль; см. Маскировка хранилища ниже.
GnuPG расшифровывается как GNU Privacy Guard. Это реализация OpenPGP от проекта GNU — открытого стандарта для управления ключами и криптографически защищённых сообщений (того же концептуального семейства, что и PGP, но описанного в таких документах, как RFC 4880 и обновлениях сообщества). Обычно вы запускаете его как команду gpg в Linux, BSD, macOS или Windows; многие графические почтовые утилиты и утилиты управления ключами используют его внутри.
Люди используют GnuPG для:
gpg-agent предоставляет ключи аутентификации со смарт-карты или из локального хранилища ключей.GnuPG и зашифрованные диски (LUKS). В Linux есть встроенный способ шифрования всего диска или раздела, называемый LUKS. После шифрования диск выглядит как бессмысленный шум для любого без ключа, поэтому потерянный или украденный ноутбук не отдаст ваши файлы.
Обычно вы разблокируете такой диск, вводя пароль. GnuPG позволяет использовать вместо этого ваш токен. Идея проста: ключ разблокировки диска сам заперт ключом вашего токена. Когда вы хотите открыть диск, токен расшифровывает для вас этот ключ разблокировки, но только пока токен подключён и вы ввели свой PIN-код. Выньте токен — и диск нельзя открыть вообще, даже на том же компьютере.
Короче говоря, это превращает токен в физический ключ для вашего зашифрованного диска. Настройка (и добавление резервного способа входа на случай потери токена) выполняется штатными инструментами дисков Linux; токен просто хранит ключ. Если вы предпочитаете разделить возможность разблокировки диска между несколькими людьми, чтобы никто не мог сделать это в одиночку, см. Секрет Шамира и шифрование диска.
По умолчанию GnuPG хранит ключи в ~/.gnupg. С OpenPGP-смарт-картой чувствительные закрытые ключи живут на карте; scdaemon (часть набора GnuPG) общается с картой по CCID/USB, пока gpg по-прежнему собирает пакеты OpenPGP на хосте.
Для чего это можно использовать. В крипто-режиме токен предназначен для той же работы, что и другие OpenPGP-смарт-карты: подписание и расшифровка почты и файлов, аутентификация (например, SSH, когда вы используете gpg-agent как обычно), и хранение долгосрочных закрытых ключей вне машины, на которой вы печатаете. Организации могут сочетать это с долями Шамира на токене, чтобы ни один человек не владел всем секретом (описано ниже). GnuPG — основная цель совместимости на хосте: эта прошивка реализует карточное приложение OpenPGP поверх CCID, которым управляет scdaemon (gpg --card-status, gpg --card-edit и обычные операции шифрования/подписания/расшифровки с ключами на карте). Другое программное обеспечение, говорящее на тех же протоколах смарт-карт, тоже может работать; команды, слоты, алгоритмы и текущие ограничения интеграции — в Совместимость 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 и считыватели доступа в стиле дверей описаны в документации как цели интеграции, а не реализованное поведение. Биометрический третий фактор, описанный в документации, ещё не реализован. Некоторые тесты побочных каналов по времени, требующие реального оборудования, не могут быть завершены, пока не существует устройства.
Galdralag может одновременно работать с двумя разными видами асимметричных ключей. Они отвечают на разные вопросы на устройстве и на хосте, и они не взаимозаменяемы, даже когда принадлежат одному человеку. Разделы Совместимость OpenPGP и GnuPG, Сеть доверия и вечеринки подписания ключей, Метаданные контакта Galdra и Сравнение метаданных (GnuPG против Galdra) описывают каждый стек подробнее; вот чем они различаются в повседневных терминах.
Ключ OpenPGP в том смысле, в котором его генерирует и использует GnuPG, — это структурированный пакет, а не голый открытый номер. Он объединяет основной ключ, подключаемые ключи для подписания и шифрования, а также один или несколько User ID — обычно отображаемое имя и адрес электронной почты, например Alice Example <[email protected]>. Другие люди могут подписывать эти User ID, чтобы заявить, что они верят в подлинность заявления о личности; этот социальный граф — основа сети доверия, описанной в разделе Сеть доверия и вечеринки подписания ключей далее в этом README. Когда Galdralag действует как OpenPGP-смарткарта, он хранит закрытый ключевой материал на чипе и выполняет подписание и расшифровку там. Открытый ключ, User ID и подписи других людей живут на хосте и управляются GnuPG обычным способом. Токен не меняет формат сообщений OpenPGP в канале; GnuPG обращается с ним как с любой другой OpenPGP-картой.
Ключ Galdra — это голая асимметричная пара ключей — Ed25519, X25519 или одна из кривых Brainpool или NIST, поддерживаемых прошивкой. Сами байты ключа не несут никаких заявлений о личности: ни пакетов User ID, ни встроенной электронной почты, ни подписей сети доверия, прикреплённых к структуре ключа. Личность для ключа Galdra исходит из записи контакта, хранящейся рядом с ним в базе данных SQLite на хосте и в хранилище контактов на чипе, привязанной к ключу по его отпечатку.
Таблица ниже сравнивает метаданные личности и контакта поле за полем. Столбцы 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, принадлежность к радиосети — не имеет естественного места в OpenPGP User ID. User ID предназначен для имени и электронной почты. Запись чего-то вроде LA5XYZ <[email protected]> DMR:2345678 в строку User ID неформальна, неструктурирована и не является машиночитаемой каким-либо стандартным способом. Ключи Galdra сохраняют криптографический материал чистым и помещают операционную идентичность в формат записи, который хост-инструмент и встроенное хранилище понимают нативно.
На практике одно устройство может содержать оба типа ключей без конфликта. Приложение OpenPGP-карты обслуживает GnuPG через стандартные слоты SIG, DEC и AUT. Хранилище контактов содержит ключи Galdra для операционной работы — например, шифрование радиоконтакту по позывному, проверка сообщения по DMR-идентификатору абонента или поиск коллеги по номеру бейджа. Эти два пути не мешают друг другу.
Если у кого-то есть сертификат OpenPGP, управляемый GnuPG на хосте, и ключ Galdra во встроенном хранилище контактов, это два отдельных ключа с двумя отдельными отпечатками. Отпечаток Galdra — с префиксом G: и полученный с помощью BLAKE3 из сырых байтов открытого ключа — не является тем же значением, что и отпечаток OpenPGP v4 сертификата GnuPG этого человека. Хост-инструмент и устройство рассматривают их как независимые идентичности. Не предполагайте, что один отпечаток подразумевает другой, не проверив оба.
Ни один тип ключа автоматически не подтверждает метки вокруг него. OpenPGP User ID является самозаявленным, пока кто-то другой не подпишет его. Позывной или поле DMR в записи контакта Galdra настолько же надёжны, насколько надёжен их источник — получение с сервера ключей, ручной ввод или внеполосная проверка, выполненная вами самостоятельно. Метки происхождения (SelfAttested, HostVerified, RegistrySync, OobVerified) фиксируют, как появилось поле; они не заменяют работу по фактической проверке идентичности, которая вам важна.
Эта прошивка написана на Rust — системном языке программирования, разработанном для такой же скорости и низкоуровневости, как C или C++, но с принципиально иным подходом к безопасности.
Каждая зависимость классифицируется как неизменённая из апстрима (crates.io в опубликованном виде), изменённая или включённая в дерево (закреплённая копия или патч рабочего пространства) или созданная этим проектом (прошивка, хост и инструментальные крейты). Полный перечень, роли и граф зависимостей находятся в docs/CRATE_DEPENDENCIES.md.
Большая доля критичных для безопасности ошибок в промышленных кодовых базах возникает из-за небезопасности памяти (переполнения буфера, use-after-free, разыменования null и тому подобное). MSRC от Microsoft неоднократно сообщала, что примерно 70% CVE, устранённых в их собственных продуктах, попадают в эту категорию; команда Chrome публиковала аналогичные пропорции для Chrome. Эти цифры описывают продукты этих поставщиков, а не универсальный закон для всей прошивки, но они иллюстрируют, почему языки с безопасной памятью имеют значение.
В безопасном Rust (по умолчанию) проверка заимствований исключает гонки данных и обычные ошибки памяти с неопределённым поведением на этапе компиляции без опоры на сборку мусора. Небезопасный Rust и FFI к C всё ещё могут вносить ошибки памяти; они должны оставаться небольшими и проверяться.
Проверка границ Rust для срезов и его правила владения сокращают несколько классов режимов отказа, распространённых во встроенном коде на C/C++:
unsafe должны быть явными; MMIO и сырые указатели для регистров находятся там, поэтому рецензенты могут искать поверхность аудита (unsafe не делает некорректный MMIO невозможным, а лишь упрощает его локализацию).Rust сам по себе не останавливает логические ошибки, такие как плотный цикл, изнашивающий флеш-память, или выбор неверных значений регистров. Они остаются задачами инженерии и рецензирования.
Эта кодовая база применяет распространённые паттерны Rust для секретов; они не автоматичны для каждого типа:
zeroize::Zeroize / ZeroizeOnDrop очищают буферы при удалении; вызывающие стороны выбирают это явно.subtle::ConstantTimeEq (и аналогичные) там, где важна синхронизация по времени — обычный == не является магически константным по времени.Copy на обёртках секретов снижает случайное дублирование; разделение доменов использует отдельные типы и метки HKDF (Политика криптографических зависимостей).catch_unwind или abort там, где ваша платформа требует более строгих гарантий.unsafe должен быть явно указан в исходном коде, что сужает ручное рецензирование. Зависимости: криптографическая политика этого проекта отдаёт предпочтение аудированным крейтам Rust (RustCrypto и другим); см. таблицу в Политика криптографических зависимостей — не каждая зависимость происходит из одного зонтичного проекта. Полный список крейтов и то, является ли каждая зависимость неизменённой, изменённой/включённой в дерево или созданной проектом, см. в docs/CRATE_DEPENDENCIES.md.
Rust не устраняет взаимоблокировки (например, неправильно упорядоченные блокировки Mutex), логические ошибки, некорректные протоколы, износ флеш-памяти из-за плохих циклов, физические атаки (глитчинг, анализ энергопотребления) или риски от корректной сборки не того образа. Он также не гарантирует константное время выполнения на всём оборудовании без тщательного кодирования. Эти области зависят от проектирования, рецензирования, тестирования и практик проекта в области криптографии и цепочки поставок, описанных в другом месте этого README.
Верификация (тесты и фаззинг): Помимо языка, этот репозиторий использует модульные тесты, интеграционные тесты, тайминговые стенды dudect и цели libFuzzer (cargo-fuzz). Сводки и матрицы находятся в Результаты тестов; записанные метаданные запусков начинаются с docs/TEST_RESULTS.md#run-metadata. Прохождение тестов не доказывает готовность к производству или отсутствие уязвимостей — они сужают риск. Вы решаете, приемлемо ли запускать сборки или тесты в вашей среде; виртуальная машина необязательна, но ограничивает радиус поражения на вашей машине.
Подходит любая крупная платформа виртуальных машин — VirtualBox (бесплатная, с открытым исходным кодом), QEMU (бесплатная, с открытым исходным кодом, командная строка) или VMware. Гостевая система Linux рекомендуется, так как среда сборки лучше всего поддерживается там.
Быстрый старт с QEMU и Ubuntu:```bash
sudo apt install qemu-system-x86 # Debian/Ubuntu host
brew install qemu # macOS host
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/main/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/main/docs/GLOSSARY.md) — термины, объяснённые **простым языком** (отсортированы А–Я). Начните отсюда, если README или другие документы кажутся перегруженными жаргоном.
**Отладка:** [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DEBUG_INSTRUCTIONS.md) — бэктрейсы, сужение `cargo test`, сокращения `xtask`, тройная проверка прошивки, фаззинг и что собирать перед сообщением о проблеме.
**ИИ-ассистенты (Claude, Cursor):** [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/CLAUDE.md) — инструкции проекта для агентов кодирования. Правила для Cursor: [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/main/.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/main/Hardware/kicad-files-usb) — `dabao_v3c` (USB-A токен **без** micro-SD); и [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card) — `dabao_v3c_sdcard` (та же базовая компоновка **с** держателем micro-SD), герберы, BOM, производственные выходы и [документация по распиновке](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card/docs/pinout/README.md). Компоновка печатной платы USB-A брелока (минимальный токен против оценочной платы в формате Pico) описана в [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md).
| Документ | Описание |
|----------|-------------|
| [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-files-usb) | Проект KiCad **USB-брелока** `dabao_v3c` (без micro-SD); герберы, BOM, производственные выходы; дополняет [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) |
| [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card) | Проект KiCad **USB-брелока** `dabao_v3c_sdcard` (держатель micro-SD); герберы, BOM, распиновка в [docs/pinout](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card/docs/pinout/README.md); дополняет [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) |
| [docs/CODE_MAP.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CODE_MAP.md) | **Индекс функций и модулей** рабочей области (пофайловые `pub fn` / типы с привязками к строкам) |
| [docs/CRATE_DEPENDENCIES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CRATE_DEPENDENCIES.md) | **Внешние и проектные** Rust-крейты и как они зависят друг от друга |
| [docs/API_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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/main/docs/ARCHITECTURE.md) | Архитектура прошивки высокого уровня и основные подсистемы |
| [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/AUDIT_LOG.md) | Записи аудита профилей (`cipher-profile`), хук OpenPGP `OpenPgpAudit`; **не** реализован журнал append-only RRAM |
| [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_API.md) | Биометрический предварительный шлюз: архитектура, формат провода, структура хранилища; интеграция частично реализована |
| [docs/BIOMETRIC_DEVICE_GUIDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_DEVICE_GUIDE.md) | Как добавить поддержку нового биометрического аппаратного бэкенда |
| [docs/BIOMETRIC_TESTING.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_TESTING.md) | Методология тестирования: метрики PAD ISO/IEC 30107-3, наборы данных, как запускать |
| [docs/FINGERVEIN_DEVICE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/FINGERVEIN_DEVICE.md) | Открытое устройство сканирования вен пальца на ESP32-CAM: аппаратное обеспечение, эскиз протокола, определение живости |
| [docs/SWEET_PLATFORM_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/SWEET_PLATFORM_INTEGRATION.md) | Сканер ладони платформы sweet: аппаратное обеспечение, интеграция, определение живости, набор данных |
| [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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 и вечеринки подписания ключей](#web-of-trust-and-key-signing-parties). Дополнительные проектные заметки остаются в [docs/server.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/server.md). |
| [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md) | **Глоссарий простым языком** (А–Я) для нетехнических читателей; технические детали остаются в связанных документах |
| [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/CLAUDE.md) | Инструкции для **Claude** / ИИ-агентов кодирования; указывает на [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/main/.cursor/rules) для **Cursor** |
| [docs/GALDRALAG_DEV_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRALAG_DEV_REFERENCE.md) | Инструментарий, команды `xtask`, точки входа для фаззинга и криптотестов |
| [docs/dev-ref.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/dev-ref.md) | Структура рабочей области, крейты, HAL-трейты, поведение USB/PSRAM, инварианты безопасности |
| [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DEBUG_INSTRUCTIONS.md) | Отладка: `RUST_BACKTRACE`, подробные сборки, ограниченные тесты, рецепты `xtask`, проверки встроенных целей, указатели по фаззингу, проверки хоста OpenPGP |
| [docs/KEY_LIFECYCLE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/KEY_LIFECYCLE.md) | Генерация ключей, импорт, политика экспорта, ротация, обнуление, Shamir (как отражено в `vault` / OpenPGP) |
| [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md) | Приложение карты OpenPGP, настройка хоста GnuPG/CCID, слоты ключей, алгоритмы, udev |
| [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md) | Система профилей шифров и конфигурация |
| [docs/DUAL_KEY_QUORUM.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DUAL_KEY_QUORUM.md) | Кворум из двух (или N) аппаратных ключей как паттерн расширения интегратора на основе Shamir и OpenPGP; не обеспечивается прошивкой |
| [docs/CIPHER_PROFILE_SECURITY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILE_SECURITY.md) | Соображения безопасности: идентификаторы профилей в открытом виде, анализ трафика, обоснование внешней обёртки BrainpoolP384r1, зашифрованные идентификаторы, свойство подстановочных знаков |
| [docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md) | Соответствие [CESS](https://github.com/Supermagnum/CESS/tree/main): компоновка провода Mode 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/main/crates/cess) | CESS Mode A: HKDF-BLAKE3 (`derive_k_outer`, `hkdf_blake3`), внешняя печать/раскрытие ChaCha, компоновка `suite_id \|\| inner_blob`; см. [CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md) |
| [docs/EPHEMERAL_SESSION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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/main/docs/PQ_SIGNATURES.md) | Постквантовые подписи с состоянием (XMSS, LMS/HSS), управление функциями |
| [docs/Psram.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/Psram.md) | Необязательный том-приманка microSD и связанное поведение |
| [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md) | **4 194 304 байта** встроенной RRAM: смещения хранилища из исходного кода, сопоставление HAL, заметки об износе / обнулении |
| [docs/TEST_RESULTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/TEST_RESULTS.md#run-metadata) | Открывается на **Run metadata**; сводка конвейера, векторы, dudect, cargo-fuzz ([Раздел 6](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/TEST_RESULTS.md#6-cargo-fuzz-libfuzzer)), жизненный цикл ключей |
| [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREE_FACTOR_AUTH.md) | Токен + PIN + необязательная биометрия: что реализует этот репозиторий против заглушки; эскиз угроз |
| [docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREAT_MODEL.md) | Модель угроз: активы, угрозы T1–T14, что защищается и что нет, непроверенные пункты в ожидании аппаратного обеспечения Q2, статус аудита |
| [docs/PERFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/PERFORMANCE.md) | Заметки о производительности |
| [docs/HARDWARE_BRINGUP_TEST_PLAN.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_BRINGUP_TEST_PLAN.md) | Первичный запуск аппаратного обеспечения Q2: образ с `galdralag-service`, libccid `1D50:6197`, ATR → APDU `gpg --card-status`, лабораторные PIN-коды Dabao (не CDC на `dabao-ccid`) |
| [docs/XOUS_CORE_UPSTREAM_REQUESTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/XOUS_CORE_UPSTREAM_REQUESTS.md) | Изменения, которые принадлежат xous-core (документы Persona A, политика ATR, заметки cratespec); Galdralag не патчит это дерево |
| [docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_VERIFICATION.md) | Аппаратное обнуление: симуляция против верификации на кремнии |
| [docs/HARDWARE_TEST.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_TEST.md) | Заметки по аппаратно-ориентированному тестированию |
| [docs/NFC_PN532_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/NFC_PN532_INTEGRATION.md) | PN532 / NFC: libnfc, варианты Rust, пассивная дверь против USB-панели, кворум с Shamir и PIN |
| [docs/SDMMC_STORAGE_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/SDMMC_STORAGE_INTEGRATION.md) | `embedded-sdmmc` + SPI microSD как необязательное массовое хранилище; альтернатива PSRAM в BOM |
| [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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** (документировано как версия **3.4.1** в [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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 можно сохранить через PUT DATA, но GENERATE, PSO:CDS и PSO:DECIPHER завершаются ошибкой для слотов, настроенных на RSA. Полная таблица и поведение `key-attr` приведены в [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md).
**Что здесь не покрывается картой OpenPGP / GnuPG:** **WebAuthn / FIDO2** — это другой протокол и выходит за рамки этого приложения карты (см. тот же документ).
**Карта OpenPGP против сообщений 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** на ветке **`feature/usb-bao1x-ccid-openpgp`**). Необязательная **`galdralag-service`** (`services/galdralag`) подключается к **`usb-bao1x`** для IPC **CCID** и отвечает на APDU **XfrBlock**; образам Dabao она нужна через cratespec (`scripts/build_dabao_ccid_image.sh`). BaoSec может по-прежнему мостить **PDDB** в **RRAM**. Подробности: [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/main/services/galdralag/README.md). Компоновка памяти: [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md). **Сквозной GnuPG на реальном аппаратном обеспечении** по-прежнему требует полного образа с Galdralag, распознавания **`1D50:6197`** хост-библиотекой **libccid** и пунктов из [Известные ограничения / открытая работа](#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/main/docs/GALDRA-TOOL.md) по мере созревания интеграции.
---
## Web of Trust и вечеринки подписания ключей
OpenPGP и **GnuPG** используют децентрализованную модель доверия — **web of trust** — для помощи в проверке того, кому принадлежат какие ключи и стоит ли полагаться на данный **открытый ключ**. Эта модель полностью **на стороне хоста**. Там, где аттестации на основе чипов, такие как [немецкий eID и 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`**, поэтому для рабочих процессов, которым нужен этот идентификатор наряду с подписью хоста в стиле **WoT**, вы обычно добавляете пользовательский профиль с помощью **`galdra profile add ... --no-ephemeral-ecdh`**. Определение простым языком и спецификация формата: [Отпечаток Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md#g). Жизненный цикл, политика ротации и шлюз эфемерного ECDH: [KEY_LIFECYCLE.md — Отпечаток Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/KEY_LIFECYCLE.md#galdralag-fingerprint-host).
### Получение вашего отпечатка Galdralag
Хост печатает строку, которая **всегда начинается с `G:`** (BLAKE3-160 по байтам открытого ключа SIG, **40 строчных шестнадцатеричных символов** после префикса в канонической форме).
1. Установите **[Galdra](https://github.com/supermagnum/galdralag-firmware/blob/main/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 (один или несколько открытых ключей плюс данные владельца/идентификатора пользователя) могут быть цифрово подписаны другими пользователями, которые тем самым подтверждают связь между этим открытым ключом и лицом или организацией, указанными в сертификате.
gpg --full-generate-key на хосте или хранящийся на токене с поддержкой OpenPGP).Вечеринка подписания ключей — это личная встреча, на которой участники обмениваются отпечатками ключей и проверяют личность друг друга перед последующим подписанием сертификатов.
Типичные характеристики:
Это создаёт социальный граф: если Алиса доверяет Бобу, а Боб подписал ключ Чарли, Алиса может решить доверять ключу Чарли в зависимости от глубины доверия и политики.
Почему такие мероприятия важны:
Участники обычно избегают компьютеров во время обмена идентификационными данными, чтобы у злоумышленников было меньше шансов подсунуть подменённые ключи или вредоносное ПО на общих машинах.
До мероприятия. Вычислите и запишите свой отпечаток (дайджест на основе хеша от открытого ключа — достаточно короткий для надёжного сравнения). Не полагайтесь на обмен полными ключами на бумаге на этом этапе, если организаторы не указали иное.```bash
gpg --fingerprint YOUR_KEY_ID
Принесите отпечаток на бумаге или другом долговечном носителе (пример формата: `ABCD 1234 EFGH 5678 90AB CDEF 1234 5678 90AB CDEF`).
**На мероприятии (только отпечатки).** Обменяйтесь **отпечатками**, проверьте удостоверения личности и отметьте, какие отпечатки принадлежат какому проверенному лицу. Подтвердите, что заявленная личность каждого участника соответствует проверенным документам.
**После мероприятия.** Получите полные **открытые ключи** с **серверов ключей** или при прямой раздаче; убедитесь, что загруженные ключи соответствуют **отпечаткам**, записанным на бумаге; **подпишите** проверенные ключи; при желании **загрузите** подписи, чтобы ими могли воспользоваться другие.
### Отпечатки вместо полных ключей на мероприятии
- **Операционная безопасность.** Связывает атаки подмены с проверенными отпечатками, а не доверяет произвольным машинам в разгар мероприятия.
- **Простота.** Отпечатки помещаются на бумаге и их легко зачитать вслух или сравнить.
- **Проверка.** После загрузки повторное вычисление отпечатка проверяет целостность по всей цепочке.
### Серверы ключей
**Серверы ключей** — это сетевые репозитории, которые хранят и реплицируют **открытые** ключи OpenPGP (а также обновления, такие как подписи и сертификаты отзыва). Они делают ключи доступными для поиска по **идентификатору пользователя**, **идентификатору ключа** или **отпечатку** и обеспечивают широкомасштабное распространение для сети доверия.
Как они ведут себя в принципе:
- **Распределённая репликация.** Загрузка на один сервер, участвующий в синхронизационной сети, часто распространяется на другие узлы (классические пулы в стиле **SKS** работали именно так).
- **Синхронизация.** Новые ключи, подписи и сертификаты отзыва распространяются в соответствии с политикой и связностью каждого сервера.
- **Открытый доступ на чтение.** Для публикации предназначен только **открытый** материал; **закрытые ключи** никогда не должны загружаться.
**Конфиденциальность.** Опубликованные ключи раскрывают **идентификаторы пользователей** (часто включая адреса электронной почты). Относитесь к загрузкам как к **публичным и долговечным** на многих серверах; загружайте **сертификаты отзыва**, когда ключ необходимо вывести из обращения. Политика зависит от оператора ([keys.openpgp.org](https://keys.openpgp.org/) отличается от устаревших пулов).
**Топология узлов.** Графики связей между серверами доступны на [spider.pgpkeys.eu/graphs/](https://spider.pgpkeys.eu/graphs/); списки узлов, ориентированных на SKS, — на [spider.pgpkeys.eu/sks-peers](https://spider.pgpkeys.eu/sks-peers).
### Использование серверов ключей```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
| Сервер | Примечания |
|---|---|
| keys.openpgp.org | Широко используется; проверка с согласия владельца для User ID, связанных с почтой |
| pgp.mit.edu | Сервер, размещённый в MIT, исторически связан с сетями эпохи SKS |
| pool.sks-keyservers.net | Устаревшее имя пула, связанное с бывшей экосистемой SKS; доступность сегодня варьируется |
gpg --refresh-keys, чтобы отзывы и новые подписи распространялись локально.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 с картой.
Для повседневного поведения карты полагайтесь на docs/OPENPGP_CARD.md. Для функций только хранилища или уникальных для токена используйте прошивку этого репозитория и документацию инструмента Galdra.
Стеки карты OpenPGP и GnuPG не определяют разделение секрета Шамира (SSS) для ключей или разблокировки диска. SSS всё равно полезен наряду с обычным шифрованием: он почти никогда не заменяет симметричный шифр на диске — он защищает маленький секрет (мастер-ключ или парольную фразу), который разблокирует это шифрование.
Шаблон (всегда одна и та же идея):
1. LUKS (Linux) и внешний SSS
LUKS шифрует том мастер-ключом. Вы можете извлечь этот ключ (или секрет слота ключа, в зависимости от вашей процедуры), разделить его инструментом SSS и хранить доли отдельно. При разблокировке объедините K долей, восстановите ключевой материал и передайте его в cryptsetup (см. документацию вашего дистрибутива; неправильное обращение с ключами может заблокировать доступ).
Пример формы с использованием утилит ssss («Shamir's Secret Sharing Scheme») (имена и упаковка различаются в зависимости от ОС):```bash
ssss-split -t 3 -n 5 < luks_master.key
ssss-combine -t 3 | cryptsetup luksOpen /dev/sdX vault
**2. HashiCorp Vault**
| Поле | Назначение | Хост (SQLite galdra) | Хранилище контактов на чипе | Формат / ограничение |
|---|
| Идентификатор контакта | Стабильный первичный ключ хоста | Да | Нет | Текст (id в SQLite) |
| Отображаемое имя | Понятная человеку метка | Да | Да | Строка UTF-8; максимум 240 байт на поле кучи на чипе |
| Электронная почта | Основной почтовый адрес | Да | Да | Строка UTF-8; поиск на чипе по сканированию почты |
| Позывной | Радиолюбительский позывной | Да | Да | 12 байт, дополнено NUL; поиск на чипе |
| Идентификатор абонента DMR | Радио-ID DMR | Да | Да | Беззнаковое 32-битное (0 = отсутствует); поиск на чипе |
| Номер бейджа | Идентификатор сотрудника или бейджа | Да | Да | Строка UTF-8 |
| Организация | Агентство или работодатель | Да | Да | Строка UTF-8 |
| Отдел | Команда или подразделение | Да | Да | Строка UTF-8 |
| Роль | Метка должности или функции | Да | Да | Строка UTF-8 |
| Заметка | Свободный комментарий | Да | Да | Строка UTF-8 |
| Радиопринадлежность | Метка клуба, сети или альянса | Да | Да | Строка UTF-8 |
| Улица | Строка почтового адреса | Да | Да | Строка UTF-8 |
| Страна | Название или код страны | Да | Да | Строка UTF-8 |
| Почтовый индекс | ZIP или почтовый индекс | Да | Да | Строка UTF-8 |
| Регион | Штат, округ или регион | Да | Да | Строка UTF-8 |
| Идентификатор Fluxer | Псевдоним или идентификатор Fluxer | Да | Да | Строка UTF-8 |
| Идентификатор Discord | Идентификатор пользователя Discord | Да | Да | Строка UTF-8 |
| Идентификатор IRC | Ник IRC или подобное | Да | Да | Строка UTF-8 |
| Номер телефона | Контактный номер для звонков или SMS | Да | Нет | Строка UTF-8; максимум 32 символа на хосте; заявлено отправителем, не проверено |
| Отпечаток | Якорь ключа (поиск, синхронизация) | Да (pgp_fingerprint) | Да | 32 байта; стиль OpenPGP v4 на проводе; не то же самое, что отпечаток устройства G: |
| Открытый ключ | Материал для шифрования / проверки | Да (pgp_pubkey) | Да (область ключей) | Алгоритм: Ed25519, X25519, Brainpool P-256/P-384/P-512, NIST P-256/P-384, RSA-2048/3072/4096; до 768 байт блоба на чипе |
| Ключ, защищённый PIN | Ключ требует разблокировки PIN | Хост хранит ключи OpenPGP отдельно | Да | Дайджест проверки PIN + метаданные обёртки AES-GCM на чипе |
| Последнее получение | Когда материал ключа был обновлён | Да (fetched_at) | Да (last_fetched) | UTC на хосте; 32-битная метка времени на чипе |
| Истекает | Время истечения ключа | Да | Нет | Дата-время UTC только в SQLite |
| Источник ключа | Как была создана запись хоста | Да (source) | Нет | например, вручную, keyserver, WKD, LDAP, файл, peer |
| Происхождение поля | Метка доверия для каждого поля метаданных | Нет | Да (source_map) | Два бита на поле: SelfAttested, HostVerified, RegistrySync, OobVerified |
| Флаги записи | Активна, устарела, собственная личность, отозвана | Частично (логика хоста) | Да | например, STALE, SELF_KEY на чипе |
fuzz/README.mdtest-all --no-dudect: Пропускает набор тестов времени dudect (~15–20 минут). CI для pull-request использует этот флаг. Запустите cargo run -p xtask -- timing-test или test-all без --no-dudect для проверки времени. Еженедельный CI (test-all-full) по-прежнему запускает dudect.docs/TEST_RESULTS.md для того, что входит в область охвата.| Поле метаданных | OpenPGP / GnuPG | Ключ Galdra (хост + хранилище контактов) |
|---|
| Контакт / ID записи | Нет (используйте ID ключа или отпечаток) | Да (id в SQLite на хосте; не на чипе) |
| Отображаемое имя | Только внутри текста User ID (Имя <email>) | Да (отдельное поле UTF-8) |
| Электронная почта | Только внутри текста User ID | Да (отдельное поле; поиск по e-mail на чипе) |
| Почтовый адрес | Нет стандартного поля | Да |
| Страна | Нет стандартного поля | Да |
| Почтовый / ZIP-код | Нет стандартного поля | Да |
| Регион / штат | Нет стандартного поля | Да |
| Организация | Нет стандартного поля | Да |
| Отдел | Нет стандартного поля | Да |
| Роль / должность | Нет стандартного поля | Да |
| Бейдж / ID сотрудника | Нет стандартного поля | Да |
| Позывной | Нет стандартного поля | Да (12 байт, дополнено NUL на чипе) |
| ID абонента DMR | Нет стандартного поля | Да (32-бит; поиск на чипе) |
| Радиопринадлежность | Нет стандартного поля | Да |
| ID Fluxer | Нет стандартного поля | Да |
| ID Discord | Нет стандартного поля | Да |
| ID IRC | Нет стандартного поля | Да |
| Номер телефона | Нет стандартного поля | Да (только SQLite на хосте) |
| Произвольная заметка | Нет стандартного поля | Да |
| Отпечаток OpenPGP v4 | Да (40 шестнадцатеричных символов) | Необязательно в строке хоста при привязке сертификата (pgp_fingerprint); 32 байта на чипе для ключей Galdra |
Отпечаток устройства G: | Нет | Да (BLAKE3-160 по открытому ключу SIG; инструмент хоста; не значение OpenPGP v4) |
| ID ключа OpenPGP | Да (короткая / длинная форма) | Нет |
| Доверие / происхождение | Подписи WoT на User ID | Пометки по полям: SelfAttested, HostVerified, RegistrySync, OobVerified (на чипе) |
| Срок действия ключа | Да (сертификат / подключаемый ключ) | Только хост (expires_at в SQLite) |
| Время последнего получения ключа | Зависит от инструментов хоста | Да (fetched_at / last_fetched) |
| Закрытый ключ на токене | Слоты карты SIG, DEC, AUT | Отдельная область ключей Galdra (не пакеты User ID) |
| PIN-код для использования закрытого ключа | PW1 / PW3 (карта OpenPGP) | Необязательная PIN-обёртка для каждой записи контакта Galdra |
| Объект карты OpenPGP (не в таблице выше) | Хост (GnuPG) | На токене |
|---|
| Основной + подключаемые ключи SIG / DEC / AUT | Открытый в связке ключей | Закрытый в запечатанных слотах |
| Сертификационные подписи (WoT) | Да | Нет |
| Сертификат отзыва | Да | Нет |
| Атрибуты алгоритма (DO 0xC1 / 0xC2 / 0xC3) | gpg --card-edit | Да |
galdragaldra-core-host| Область | Типичный стандарт / документ | Доступно как стандартная карта OpenPGP + GnuPG? |
|---|
| Карточное приложение OpenPGP — APDU, PIN-коды, слоты SIG/DEC/AUT, генерация/подпись/расшифровка на карте | Спецификация карты OpenPGP (см. docs/OPENPGP_CARD.md) | Да — тот же хост-стек, что и для других смарт-карт OpenPGP (gpg, scdaemon, CCID) |
| USB CCID — взаимодействие с устройством как с устройством чтения смарт-карт | Класс устройств USB CCID | Да — драйверы классов |
| Формат сообщений OpenPGP — зашифрованные файлы, почта, пакеты ключей | RFC 4880 (и обновления) | Да на хосте — GnuPG использует это; карта не разбирает почту |
| Shamir K-of-N — разделение / восстановление долгосрочного ключевого материала в хранилище | Не в спецификации карты OpenPGP; не в GnuPG | Нет — только прошивка и инструменты подготовки; не операция gpg --card-edit (см. Shamir и шифрование всего диска) |
| Двойной аппаратный ключ / авторизация кворума — два (или N) токена требуются до того, как потребитель действует (разблокировка диска, открытие двери, привилегированные операции) | Не в спецификации карты OpenPGP | Нет — поддерживаемый шаблон расширения для интеграторов, использующих Shamir и/или несколько авторизаций OpenPGP; обеспечение соблюдения принадлежит нижестоящей системе (docs/DUAL_KEY_QUORUM.md) |
| Аутентифицированный эфемерный ECDH — протокол сеанса с прямой секретностью на токене | Не в спецификации карты OpenPGP | Нет — специфично для токена; не команда карты GnuPG |
| Система профилей шифров — именованные симметричные каскады (независимые шифры, наложенные друг на друга; до четырёх слоёв, три — поддерживаемая глубина) и связанная политика | Не в спецификации карты OpenPGP | Нет — прошивка / хост-инструменты токена |
| microSD-приманка / массовые хранилища-персоны — USB-поведение для неинформированного хоста | Не в спецификации карты OpenPGP | Нет — отдельные пути кода USB-персон |
| WebAuthn / FIDO2 | CTAP / WebAuthn | Не реализовано — другой стандарт, отличный от карты OpenPGP |
| Слой | Роль |
|---|
| Диск | Зашифрован мастер-ключом (например, AES-256 через LUKS, VeraCrypt или сырой блочный слой) |
| Мастер-ключ | Разделён с помощью SSS на N долей, порог K-of-N |
| Доли | Хранятся у людей, устройств или в офлайн-хранилище; K долей вместе восстанавливают мастер-ключ |
| Разблокировка | Восстановить ключ, затем передать его в cryptsetup, veracrypt или ваш стек |