supermagnum/galdralag-firmwareUn framework cryptographique pour Baochip-1x.
Ce projet est enregistré auprès de l'Open Invention Network (OIN). L'OIN est un pool de brevets défensif : les membres s'accordent mutuellement des licences croisées sur les brevets liés à Linux afin que les participants puissent distribuer et utiliser des logiciels open source avec une exposition réduite aux brevets.
Statut : En attente de : https://github.com/betrusted-io/xous-core/pull/937
Firmware pour les appareils Baochip-1x (carte d'évaluation Dabao) exécutant le
micro-noyau Xous, compilé
pour riscv32imac-unknown-none-elf.
Il se trouve ici : https://www.baochip.com/
L'appareil est un jeton de sécurité matériel dans la même catégorie que les appareils de classe Nitrokey, avec un comportement de carte à puce OpenPGP et un coffre-fort chiffré. La pile matérielle complète — RTL, schémas, chargeur d'amorçage, système d'exploitation — est open source et auditable.
La spécification matérielle, le modèle d'amorçage, les tableaux d'exigences et l'utilisation de ComboHash/PKE sont documentés dans Supermagnum/Baochip-1x-firmware. La carte d'évaluation Dabao (KiCad, schémas, interrupteurs, brochage) se trouve dans baochip/dabao. Pour entrer en mode chargeur d'amorçage pour le flashage, appuyez sur SW2 pour l'activer (voir le schéma de ce dépôt). Notes d'architecture pour ce dépôt : docs/ARCHITECTURE.md.
L'outil hôte Galdra conserve un répertoire SQLite local de destinataires (contacts). Chaque identité stockée comprend le matériel de clé publique ainsi que des étiquettes latérales facultatives (voir le tableau ci-dessous). Ces balises vivent dans la base de données hôte et, pour les clés Galdra, dans le magasin de contacts sur puce (crates/contact-store). Elles ne sont pas liées magiquement aux identifiants utilisateur OpenPGP, sauf si vous les alignez vous-même, et elles ne sont pas attestées cryptographiquement, sauf si vous les vérifiez hors bande. La commande facultative galdra keyserver push peut envoyer des champs chevauchants à un registre de projet au format JSON, accompagnés de la clé publique exportée. La provenance par champ sur le jeton utilise SelfAttested, HostVerified, RegistrySync et OobVerified (voir Comparaison des métadonnées (GnuPG vs Galdra) et la disposition du magasin de contacts dans docs/RRAM_LAYOUT.md).
Détails côté hôte et comportement CLI : docs/GALDRA-TOOL.md. Disposition sur le fil et nombre d'emplacements : crates/contact-store/src/layout.rs et docs/RRAM_LAYOUT.md.
Ce firmware est un jeton de sécurité matériel pour Baochip-1x : une application de carte OpenPGP sur USB CCID, avec un coffre-fort sur l'appareil, une politique de code PIN et des fonctionnalités spécifiques au dépôt (profils de chiffrement — vous pouvez empiler jusqu'à quatre chiffrements symétriques différents en une seule cascade, chacun avec sa propre clé dérivée ; voir Capacités clés), des flux liés à Shamir, un ECDH éphémère authentifié là où il est implémenté, et des outils hôte Galdra). La cible d'interopérabilité principale est l'utilisation de cartes OpenPGP de style GnuPG, pas tous les protocoles de jetons du marché.
Ce firmware n'est pas :
Les exclusions au niveau des crates alignées sur les mêmes contraintes sont listées sous Crates Explicitement Exclus dans docs/future-todo.md.
CESS : Ce firmware est conforme à CESS pour les constructions normatives implémentées dans l'arborescence (y compris l'AEAD externe Mode A, HKDF-BLAKE3 pour K_outer, et la division Shamir par octets GF(2^8)). La déclaration complète d'alignement, le registre des écarts et le niveau de certification (par exemple CESS-CORE pour la couche fixe complète) sont documentés dans docs/CESS_CONFORMANCE.md et CESS (norme ouverte connexe) ci-dessous.
La logique d'application OpenPGP / CCID se trouve dans crates/usb-personality. Sur Xous, le service USB qui expose CCID est usb-bao1x (dans votre copie de xous-core), compilé avec la fonctionnalité ccid-openpgp, utilisant crates/baochip-openpgp pour la fenêtre RRAM OpenPGP et l'approvisionnement. Disposition : docs/RRAM_LAYOUT.md. Lacunes de pré-production (UX du PIN opérateur, validation de la carte de plateforme) : Limitations connues / travaux en cours.
L'objectif global reste un firmware complet, testé et open source de jeton de sécurité matériel : un comportement de style carte OpenPGP pour GnuPG sur CCID (voir Compatibilité OpenPGP et GnuPG), plus des fonctionnalités supplémentaires sur l'appareil non définies actuellement par la norme de carte OpenPGP — ECDH éphémère avec secret persistant, Shamir K-de-N, profils agnostiques au chiffrement, volume leurre microSD — comme résumé dans Normes vs fonctionnalités spécifiques au firmware. Le tout sur RTL ouvert avec un chargeur d'amorçage reproductible.
Pour les déploiements qui nécessitent deux jetons physiques distincts (ou des détenteurs de parts K-de-N) avant de déverrouiller des serveurs, des pare-feu, des coffres-forts de médicaments ou des volumes chiffrés, voir Quorum de double clé matérielle (modèle intégrateur) sous Capacités clés. Chaque appareil est une source d'identifiants ; l'application du quorum est votre passerelle d'accès, couche PAM ou panneau — pas ce firmware.
Le firmware livrable pour Baochip-1x est signé avec Ed25519. Vous signez l'image du firmware avec une clé privée Ed25519 ; GnuPG peut le faire avec gpg --sign en utilisant une sous-clé de signature Ed25519 (le flux de travail habituel de signature détachée OpenPGP, adapté à l'empaquetage émis par votre compilation). La ROM immuable boot0 dans le SoC vérifie cette signature par rapport aux clés publiques correspondantes gravées dans l'appareil (et au manifeste de clés plus large pour la chaîne d'amorçage) avant que l'étape suivante — boot1 — ne soit autorisée à s'exécuter. boot1 charge ensuite les images d'application signées (par exemple les blobs UF2 livrés via le stockage de masse USB en mode chargeur d'amorçage). Les pièces par défaut portent quatre clés publiques Ed25519 sur puce (rôles tels que déploiement de code, bêta et développeur) ; boot0 / boot1 appliquent une politique de défiance mutuelle entre Baochip et les clés de signature tierces. Flux d'amorçage complet, livraison UF2, console, mises à jour boot1 et modèle de sécurité : Getting Started with Baochip Targets dans xous-core.
Tous les tests ne s'exécutent pas dans chaque commande ; c'est intentionnel.
xtask pas dans le test d'espace de travail par défaut : La recette courante est cargo test --workspace --exclude xtask car xtask est une crate d'orchestration de compilation. Exécutez cargo test -p xtask lorsque vous voulez ses tests.#[ignore] : Ils sont sautés sauf si vous passez --ignored (et les filtres de crates nécessaires). Les raisons incluent : une couverture déjà exercée dans des tests unitaires ciblés (p. ex. zéroisation après libération), des cas lents (p. ex. génération de clés RSA) et des flux dépendants du matériel ou du jeton dans les outils hôte tels que galdra qui nécessitent un appareil connecté ou des fixtures.test-all --no-fuzz : Saute l'étape cargo-fuzz pour garder CI ou les exécutions rapides courtes et pour éviter d'exiger une chaîne d'outils nightly pour cette étape ; exécutez cargo run -p xtask -- test-all sans --no-fuzz, ou lancez les cibles fuzz séparément (voir ).On peut aussi vérifier l'intégrité des crates avec ceci lorsque la PR est fermée : https://github.com/rust-lang/cargo/issues/16850
Statut : Prêt pour des tests par des humains, sur du matériel réel — aucune version prête pour la production n'existe. Il est écrit en Rust en utilisant des crates cryptographiques validées et auditées. Les primitives cryptographiques proviennent exclusivement de dépendances auditées de l'espace de travail. Les algorithmes post-quantiques sont derrière des fonctionnalités et marqués AUDIT INDÉPENDANT EN ATTENTE. Voir Statut post-quantique.
Remarque : Certaines parties de ce projet ont été développées avec l'assistance de l'IA (Claude, Anthropic). La conception, les choix cryptographiques et les décisions de sécurité n'ont pas été examinés par un cryptographe professionnel. Traitez ce projet comme expérimental et appliquez votre propre jugement critique. Un examen indépendant par des experts est fortement recommandé avant tout déploiement en production.
Il est prêt pour des tests par des humains. Vous décidez de compiler ou d'exécuter tout ou partie de ce logiciel ; il peut y avoir des bogues que les tests unitaires, le fuzzing et d'autres vérifications n'ont pas trouvés. L'utilisation d'une machine virtuelle facultative pour l'expérimentation réduit le risque pour votre système hôte mais ne l'élimine pas. Les résultats détaillés se trouvent dans Résultats des tests (docs/TEST_RESULTS.md#run-metadata). Définitions en langage simple (A–Z) des termes techniques : Glossaire.
Le développeur principal souffre d'une affection neurologique liée à la dyscalculie. La dyscalculie affecte le sens des nombres et le traitement symbolique associé d'une manière qui, pour lui, rend la programmation traditionnelle — l'édition de code écrite à la main comme seul flux de travail — non réalisable sans outils assistés (par exemple des éditeurs conversationnels basés sur l'IA). Cette contrainte est distincte de l'exactitude : les réviseurs doivent toujours peser les tests, le fuzzing et l'audit indépendant comme documenté ailleurs sur cette page.
Un cryptographe ou un implémenteur sérieux examinant Galdralag ouvrira généralement crates/vault/tests/ et crates/cipher-profile/tests/ avant de lire la prose. La suite de tests est la preuve du travail : elle encode des connaissances de domaine qui ne peuvent pas être remplacées par la seule narration.
Ce n'est pas une raison pour cacher ce point à tout le monde. Les personnes évaluant le projet pour un achat, décidant de contribuer ou livrant du code sans formation approfondie en méthodologie de test cryptographique méritent toujours un pointeur vers les preuves concrètes.Ce qu'il faut examiner : Le matériel de conformité comprend les exemples de travail de la RFC 8439 pour ChaCha20-Poly1305 sous crates/vault/tests/rfc_vectors/, les JSON Wycheproof fournis pour ChaCha20-Poly1305 et les cas limites ECDH/ECDSA Brainpool sous crates/vault/tests/data/wycheproof/, les vecteurs BSI TR-03111 pour BrainpoolP256r1 et P384r1 sous crates/vault/tests/bsi_vectors/, les vecteurs de référence officiels BLAKE3 (les 35 longueurs d'entrée, les trois modes) sous crates/vault/tests/blake3_vectors.json, les vecteurs de spécification Twofish (1203 cas, y compris Monte Carlo) sous crates/vault/tests/twofish_vectors.json, et le propre fixture KAT en cascade CESS du projet avec des intermédiaires vérifiés indépendamment sous crates/cipher-profile/tests/fixtures/cascade_cess_kat.json. Ensemble, ils constituent la vérité de référence que l'exécuteur et les réviseurs peuvent exercer avec cargo test --workspace et python3 scripts/verify_cascade_kats.py.
La RFC 8439 est publiée par l'Internet Engineering Task Force (IETF), l'organisation qui normalise une grande partie de l'interopérabilité d'Internet. Les RFC (Request for Comments) sont la forme habituelle des spécifications de protocoles et de nombreuses spécifications cryptographiques. La RFC 8439 définit le chiffrement authentifié ChaCha20-Poly1305 (en s'appuyant sur les conceptions de Daniel Bernstein) et inclut des exemples de travail concrets avec des entrées et sorties attendues spécifiques afin que les implémentations indépendantes puissent vérifier qu'elles correspondent au standard octet pour octet. Le texte en clair largement reproduit commençant par Ladies and Gentlemen of the class of '99: wear sunscreen apparaît dans les exemples en annexe de la RFC : si votre code reproduit exactement la sortie AEAD, vous disposez d'une vérification solide que vous avez implémenté la construction correctement. C'est l'analogue cryptographique d'un corrigé officiel. ChaCha20-Poly1305 est la couche interne de chaque profil de cascade multicouche de ce firmware, donc cette vérification se trouve à la base de toute la pile de chiffrement.
Wycheproof est un corpus de tests publié par l'équipe de sécurité de Google (2017). Le nom fait référence au mont Wycheproof en Australie — souvent cité comme la plus petite montagne du monde — parce que le projet se concentre sur le franchissement de petits obstacles fatals : débordements d'entiers, cas limites, entrées malformées et étiquettes d'authentification falsifiées ; des défaillances qui apparaissent de manière répétée dans la cryptographie réellement déployée. Il complète les vecteurs de type RFC : les exemples de type RFC 8439 démontrent la conformité avec l'AEAD publié ; Wycheproof met l'accent sur la robustesse là où les implémentations échouent historiquement. Dans ce dépôt, les JSON Wycheproof couvrent ChaCha20-Poly1305, AES-GCM, HMAC, HKDF, X25519, Ed25519, RSA et les variantes ECDH/ECDSA Brainpool.
BSI TR-03111 est la directive technique pour la cryptographie sur courbes elliptiques publiée par l'Office fédéral allemand de la sécurité de l'information (Bundesamt für Sicherheit in der Informationstechnik). La version 2.10 est la révision actuelle. Les courbes Brainpool utilisées dans ce firmware — P256r1 et P384r1 — sont spécifiées dans les normes BSI, ce qui fait de TR-03111 la référence naturelle pour leurs vecteurs de test. Chaque courbe dispose d'une couverture ECDH et ECDSA ; les signatures ECDSA ont en outre été recoupées avec une implémentation Python indépendante utilisant la bibliothèque cryptography.
Les vecteurs de référence BLAKE3 sont le corpus de test officiel publié avec la spécification BLAKE3 par ses auteurs. Ils couvrent 35 longueurs d'entrée de 0 à 102400 octets, spécifiquement choisies pour exercer toutes les conditions limites internes de hachage par blocs et par arbre qui sont invisibles pour les tests sur entrées courtes. Les trois modes BLAKE3 — hachage par défaut, hachage avec clé et dérivation de clé — sont couverts. BLAKE3 est utilisé dans tout ce firmware pour la dérivation de clés HKDF et les vérifications d'intégrité inter-couches dans les profils de chiffrement en cascade ; la couverture des limites est importante car la construction arborescente de BLAKE3 ne s'active qu'au-delà de 1024 octets.
La suite de tests est également une détection de falsification pour la chaîne d'approvisionnement. Toutes les primitives cryptographiques de ce firmware proviennent de crates RustCrypto auditées — aucune cryptographie n'est implémentée dans l'arborescence. Comme les vecteurs de conformité ci-dessus sont exécutés contre ces crates à chaque cargo test --workspace, toute dépendance qui a été falsifiée ou substituée produira un échec de test à réponse connue avant que le code compromis n'atteigne un système déployé. python3 scripts/verify_cascade_kats.py ajoute un second chemin indépendant : une implémentation Python vérifie les mêmes valeurs intermédiaires dans le fixture KAT en cascade, de sorte que même une chaîne d'outils Rust compromise produisant une sortie erronée est détectée par le recoupement. C'est une histoire d'intégrité de chaîne d'approvisionnement nettement plus solide que la liaison à une bibliothèque C, où la vérification équivalente de chaque opération interne exige beaucoup plus d'efforts et d'outils spécialisés.
Il appartient désormais au lecteur de juger si ces affirmations sont fausses ou non.
Vous le branchez sur un port USB. Du point de vue de l'hôte, le firmware peut présenter le mode crypto ou le mode camouflage. En mode crypto, votre ordinateur voit une carte à puce : vous utilisez GnuPG ou une pile OpenPGP compatible (Qu'est-ce que GnuPG ?) de la même manière que n'importe quel autre jeton de sécurité matériel — le jeton gère les opérations cryptographiques sensibles afin que vos clés privées n'existent jamais sans protection sur votre ordinateur. En mode camouflage, il peut s'énumérer comme un stockage amovible ordinaire avec des fichiers d'apparence anodine afin qu'un coup d'œil rapide ne révèle pas son véritable rôle ; voir Camouflage de stockage ci-dessous.
GnuPG signifie GNU Privacy Guard. C'est l'implémentation par le projet GNU d'OpenPGP, la norme ouverte pour la gestion des clés et les messages protégés cryptographiquement (la même famille conceptuelle que PGP, mais spécifiée dans des documents tels que la RFC 4880 et les mises à jour communautaires). Vous l'exécutez normalement comme la commande gpg sous Linux, BSD, macOS ou Windows ; de nombreux utilitaires graphiques de messagerie et de gestion de clés l'utilisent en arrière-plan.
Les gens utilisent GnuPG pour :
gpg-agent expose les clés d'authentification depuis une carte à puce ou un trousseau local.GnuPG et les disques chiffrés (LUKS). Linux dispose d'un moyen intégré de chiffrer un disque entier ou une partition, appelé LUKS. Une fois un disque chiffré, il ressemble à un bruit dénué de sens pour quiconque n'a pas la clé, donc un ordinateur portable perdu ou volé ne livre pas vos fichiers.
Normalement, vous déverrouillez un tel disque en tapant un mot de passe. GnuPG vous permet d'utiliser votre jeton à la place. L'idée est simple : la clé de déverrouillage du disque est elle-même verrouillée avec la clé de votre jeton. Lorsque vous voulez ouvrir le disque, le jeton déchiffre cette clé de déverrouillage pour vous, mais uniquement pendant que le jeton est branché et que vous avez saisi votre PIN. Retirez le jeton, et le disque ne peut plus être ouvert du tout, même sur le même ordinateur.
En bref, cela transforme le jeton en clé physique pour votre disque chiffré. La configuration (et l'ajout d'un moyen de secours, au cas où le jeton serait perdu) se fait avec les outils de disque propres à Linux ; le jeton ne fait que conserver la clé. Si vous préférez partager la capacité de déverrouiller un disque entre plusieurs personnes, afin qu'aucune personne seule ne puisse le faire, voir Partage de secret de Shamir et chiffrement de disque.
Par défaut, GnuPG stocke les clés sous ~/.gnupg. Avec une carte à puce OpenPGP, les clés privées sensibles vivent sur la carte ; scdaemon (faisant partie de la suite GnuPG) communique en CCID/USB avec la carte tandis que gpg assemble toujours les paquets OpenPGP sur l'hôte.
Ce à quoi vous pouvez l'utiliser. En mode crypto, le jeton est destiné au même travail que les autres cartes à puce OpenPGP : signer et déchiffrer des e-mails et des fichiers, s'authentifier (par exemple SSH lorsque vous utilisez gpg-agent comme d'habitude), et garder les clés privées à long terme hors de la machine sur laquelle vous tapez. Les organisations peuvent combiner cela avec des parts Shamir sur le jeton afin qu'aucune personne seule ne détienne le secret entier (décrit plus loin). GnuPG est la cible d'interopérabilité principale sur l'hôte : ce firmware implémente l'application de carte OpenPGP sur CCID, que scdaemon pilote (gpg --card-status, gpg --card-edit, et chiffrement/signature/déchiffrement normaux avec les clés sur la carte). D'autres logiciels qui parlent les mêmes protocoles de carte à puce peuvent également fonctionner ; les commandes, les emplacements, les algorithmes et les limites d'intégration actuelles sont dans Compatibilité OpenPGP et GnuPG. Lorsque le NFC sera mis en place sur le matériel (intégration prévue — pas encore dans le firmware), la même classe d'appareils pourra prendre en charge l'accès physique : passer un lecteur NFC à une porte, un portail ou un panneau de verrouillage peut participer à une politique qui ne libère le verrou qu'après des vérifications cryptographiques (souvent combinées avec un PIN, des données biométriques ou un quorum de type Shamir selon le déploiement). L'esquisse orientée PN532 pour les lecteurs et les panneaux se trouve dans docs/NFC_PN532_INTEGRATION.md.
Voilà la version courte. Voici ce qui le distingue des autres jetons que vous avez peut-être rencontrés.
Camouflage de stockage. L'appareil peut agir comme un stockage amovible ordinaire afin que son véritable rôle ne soit pas évident au premier coup d'œil. Lorsque vous le branchez sur un ordinateur typique, il peut apparaître comme un lecteur USB normal ou un volume adossé à une carte SD ; vous pouvez remplir le système de fichiers visible avec des fichiers quotidiens plausibles (par exemple des photos de vacances) afin qu'une navigation occasionnelle renforce l'impression qu'il ne s'agit que d'un stockage. Cela décourage l'inspection superficielle à un bureau ou à un point de contrôle. Comprendre qu'il s'agit en réalité d'un jeton de sécurité implique généralement de démonter le boîtier, pas seulement de le brancher.
Vos clés restent sur l'appareil. Lorsque vous signez un e-mail ou déchiffrez un fichier, la clé privée ne quitte jamais le jeton. L'ordinateur envoie les données, le jeton fait le travail, le résultat revient. Un attaquant qui compromet votre ordinateur n'obtient rien d'utile.
Les sessions passées restent sûres même si le jeton est volé. La plupart des jetons matériels utilisent une clé privée à long terme directement pour l'accord de clé. Celui-ci génère une nouvelle paire de clés jetables pour chaque session, la signe avec la clé à long terme pour prouver son authenticité, puis utilise la paire jetable pour l'échange réel. Si quelqu'un vole le jeton dans des années et parvient à extraire la clé à long terme, il ne pourra toujours pas déchiffrer quoi que ce soit des sessions passées. Cette propriété s'appelle la confidentialité persistante (forward secrecy), et elle est inhabituelle dans les jetons matériels.
Vous pouvez diviser la clé entre plusieurs personnes. Le jeton peut diviser la clé à long terme en N parts afin que K de ces parts soient nécessaires pour la reconstruire — mais aucun détenteur d'une seule part ne peut rien faire seul. C'est ce qu'on appelle le partage de secret de Shamir. C'est utile pour les clés organisationnelles où aucune personne seule ne devrait avoir un accès unilatéral, ou comme stratégie de sauvegarde où les parts sont stockées dans des emplacements séparés. C'est également inhabituel dans les jetons matériels.
Le chiffrement est en couches. Plutôt que de chiffrer vos données avec un seul chiffrement, le jeton peut les faire passer par plusieurs chiffrements indépendants en séquence — par exemple ChaCha20, puis Serpent, puis Twofish — chacun utilisant une clé dérivée séparément. Une future percée qui casse un chiffrement ne casse pas les autres. La combinaison spécifique s'appelle un profil de chiffrement, et vous pouvez choisir parmi plusieurs profils intégrés selon le niveau de prudence que votre situation exige.
Ma recommandation personnelle est BrainpoolP256r1 + ChaCha20-Poly1305 + BLAKE3. C'est le profil standard intégré. Il utilise la courbe BSI Brainpool P-256 pour l'accord de clé éphémère, ChaCha20-Poly1305 pour le chiffrement symétrique et BLAKE3 pour la dérivation de clés et l'intégrité inter-couches. Il est rapide, bien testé, économe en batterie (ChaCha20-Poly1305 a été conçu pour être efficace sur du matériel sans accélération AES, réduisant le temps CPU et la consommation d'énergie de l'hôte ; P-256 est la plus petite des trois courbes Brainpool de ce firmware), et ne dépend d'aucune primitive conçue par le NIST. Si vous avez besoin d'une marge plus élevée contre une future rupture cryptanalytique d'un seul chiffrement, le profil conservative ajoute une couche Serpent-256 par-dessus.
Les choix d'algorithmes sont délibérés. Les chiffrements utilisés — ChaCha20-Poly1305, Serpent, Twofish, Camellia — ont tous été conçus indépendamment des organismes de normalisation gouvernementaux. AES et la suite NIST sont intentionnellement exclus. C'est un choix conscient pour les utilisateurs et les organisations qui souhaitent une indépendance cryptographique vis-à-vis du processus de normalisation d'un seul pays. Camellia a été évalué indépendamment par le projet européen NESSIE et le programme japonais CRYPTREC, et est spécifié dans la RFC 3713 et l'ISO/IEC 18033-3.
Un mauvais PIN vous verrouille correctement. Le jeton compte les tentatives de PIN échouées avant de vérifier si le PIN est correct, pas après. Cela signifie qu'un crash ou une perte de courant en pleine tentative ne peut pas être exploité pour réinitialiser le compteur. Après trop de tentatives erronées, le jeton efface le matériel sensible.
Ce qu'il ne fait pas encore. Il n'y a pas encore de matériel disponible — c'est un firmware en développement actif. Les tests de bout en bout avec du vrai matériel USB et GnuPG sont une étape future. Le transport NFC et les lecteurs d'accès de type porte sont décrits dans la documentation comme des cibles d'intégration, pas encore un comportement livré. Le troisième facteur biométrique décrit dans la documentation n'est pas encore implémenté. Certains tests de canaux auxiliaires temporels qui nécessitent du vrai matériel ne peuvent pas être terminés tant qu'un appareil n'existe pas.
Galdralag peut fonctionner avec deux types différents de clés asymétriques à la fois. Elles répondent à des questions différentes sur l'appareil et sur l'hôte, et elles ne sont pas interchangeables même lorsqu'elles appartiennent à la même personne. Les sections Compatibilité OpenPGP et GnuPG, Toile de confiance et fêtes de signature de clés, Métadonnées de contact Galdra et Comparaison des métadonnées (GnuPG vs Galdra) décrivent chaque pile plus en détail ; voici en quoi elles diffèrent en termes quotidiens.
Une clé OpenPGP, au sens où GnuPG la génère et l'utilise, est un paquet structuré, pas un simple nombre public. Elle regroupe la clé primaire, les sous-clés de signature et de chiffrement, et un ou plusieurs User IDs — généralement un nom d'affichage et une adresse e-mail tels que Alice Example <[email protected]>. D'autres personnes peuvent signer ces User IDs pour indiquer qu'elles croient que la revendication d'identité est authentique ; ce graphe social est la base de la toile de confiance décrite dans Toile de confiance et fêtes de signature de clés plus loin dans ce README. Lorsque Galdralag agit comme une carte à puce OpenPGP, il conserve le matériel de clé privé sur la puce et effectue la signature et le déchiffrement là-bas. La clé publique, les User IDs et les signatures des autres vivent sur l'hôte et sont gérés par GnuPG de la manière habituelle. Le jeton ne modifie pas le format de message OpenPGP sur le fil ; GnuPG le traite comme n'importe quelle autre carte OpenPGP.
Une clé Galdra est une simple paire de clés asymétriques — Ed25519, X25519, ou l'une des courbes Brainpool ou NIST que le firmware prend en charge. Les octets de la clé eux-mêmes ne portent aucune revendication d'identité : pas de paquets User ID, pas d'e-mail intégré, pas de signatures de toile de confiance attachées à la structure de la clé. L'identité d'une clé Galdra provient de l'enregistrement de contact stocké à côté d'elle dans la base de données SQLite de l'hôte et du magasin de contacts sur la puce, lié à la clé par son empreinte.
Le tableau ci-dessous compare les métadonnées d'identité et de contact champ par champ. Les colonnes OpenPGP / GnuPG décrivent ce que vous obtenez d'un certificat et d'un User ID normaux (plus les lignes de contact côté hôte optionnelles dans Galdra lorsque vous stockez une clé publique OpenPGP dans le même répertoire). Les colonnes clé Galdra décrivent les champs latéraux structurés pour les contacts opérationnels (détail complet sur l'hôte et sur la puce dans Métadonnées de contact Galdra). Un tiret signifie que cette pile n'a pas de champ standard et séparé pour cet élément.
OpenPGP place le nom et l'e-mail dans une seule chaîne User ID ; il ne vous donne pas de champs séparés et lisibles par machine pour l'indicatif, le DMR ou le postal. Galdra les conserve comme colonnes nommées afin que les équipes radio et opérationnelles puissent les rechercher et les afficher sans analyser le texte du certificat.
Les jetons mis à niveau depuis un firmware offrant BrainpoolP512r1 peuvent encore renvoyer des attributs P-512 sur GET DATA ; les opérations GnuPG sur ces emplacements échouent alors avec des erreurs de carte génériques. Exécutez galdra device status (ou consultez docs/OPENPGP_CARD.md) pour identifier les emplacements obsolètes ; le contexte de suppression est dans CHANGELOG.md.
| PW1 / PW3 | Jamais stockés | Vérificateur sur la puce (min 5 caractères, 3 tentatives par défaut) |
| DO du titulaire de carte (login, langue, URL, …) | Mis en cache par GnuPG | Optionnel (254 octets max par DO) |
Application de carte 3.4.1, CCID et flux de travail GnuPG : docs/OPENPGP_CARD.md et Compatibilité OpenPGP et GnuPG.La scission existe parce que les informations d'identité qui comptent dans les communautés ciblées par Galdralag — indicatif, ID DMR, affiliation à un réseau radio — n'ont pas de place naturelle dans un User ID OpenPGP. Un User ID est destiné à un nom et une adresse e-mail. Écrire quelque chose comme LA5XYZ <[email protected]> DMR:2345678 dans une chaîne User ID est informel, non structuré et non lisible par machine de manière standard. Les clés Galdra conservent le matériel cryptographique propre et placent l'identité opérationnelle dans un format d'enregistrement que l'outil hôte et le stockage sur puce comprennent nativement.
En pratique, un seul appareil peut contenir les deux types de clés sans conflit. L'application de carte OpenPGP sert GnuPG via les emplacements standard SIG, DEC et AUT. Le magasin de contacts contient les clés Galdra pour le travail opérationnel — par exemple, chiffrer vers un contact radio par indicatif, vérifier un message contre un ID d'abonné DMR, ou rechercher un collègue par numéro de badge. Les deux chemins ne se marchent pas dessus.
Si quelqu'un possède un certificat OpenPGP géré par GnuPG sur l'hôte et une clé Galdra dans le magasin de contacts sur puce, ce sont deux clés distinctes avec deux empreintes distinctes. L'empreinte Galdra — préfixée G: et dérivée avec BLAKE3 à partir des octets bruts de la clé publique — n'est pas la même valeur que l'empreinte OpenPGP v4 du certificat GnuPG de cette personne. L'outil hôte et l'appareil les traitent comme des identités indépendantes. Ne supposez pas qu'une empreinte implique l'autre sans vérifier les deux.
Aucun type de clé ne cautionne automatiquement les étiquettes qui l'entourent. Un User ID OpenPGP est auto-déclaré jusqu'à ce que quelqu'un d'autre le signe. Un champ indicatif ou DMR dans un enregistrement de contact Galdra n'est aussi fiable que sa source — une récupération depuis un serveur de clés, une saisie manuelle, ou une vérification hors bande que vous avez effectuée vous-même. Les étiquettes de provenance (SelfAttested, HostVerified, RegistrySync, OobVerified) enregistrent comment un champ est arrivé ; elles ne remplacent pas le travail de vérification réelle de l'identité qui vous importe.
Ce firmware est écrit en Rust, un langage de programmation système conçu pour être aussi rapide et bas niveau que C ou C++, mais avec une approche fondamentalement différente de la sécurité.
Chaque dépendance est classée comme inchangée en amont (crates.io tel que publié), modifiée ou vendue dans l'arborescence (copie épinglée ou correctif d'espace de travail), ou créée par ce projet (crates de firmware, d'hôte et d'outillage). L'inventaire complet, les rôles et le graphe de dépendances se trouvent dans docs/CRATE_DEPENDENCIES.md.
Une grande part des bogues liés à la sécurité dans les bases de code industrielles provient de l'insécurité mémoire (dépassements de tampon, utilisation après libération, déréférencements nuls, et similaires). Le MSRC de Microsoft a signalé à plusieurs reprises qu'environ 70 % des CVE traités dans leurs propres produits entrent dans cette catégorie ; l'équipe Chrome a publié des proportions similaires pour Chrome. Ces chiffres décrivent les produits de ces fournisseurs, pas une loi universelle pour tous les firmwares, mais ils illustrent pourquoi les langages sûrs en mémoire comptent.
Dans Rust sûr (par défaut), le vérificateur d'emprunts élimine les courses de données et les erreurs mémoire habituelles de comportement indéfini au moment de la compilation sans recourir au ramasse-miettes. Rust non sûr et FFI vers C peuvent encore introduire des bogues mémoire ; ils doivent rester limités et être revus.
Les vérifications de bornes de Rust sur les tranches et ses règles de propriété réduisent plusieurs classes de modes de défaillance courants dans le code embarqué C/C++ :
unsafe doivent être explicites ; MMIO et les pointeurs bruts pour les registres y vivent, afin que les réviseurs puissent grep la surface d'audit (unsafe ne rend pas un MMIO incorrect impossible, seulement plus facile à localiser).Rust ne stoppe pas par lui-même les bogues logiques tels qu'une boucle serrée qui use la flash, ou le choix de valeurs de registres erronées. Ceux-ci restent des préoccupations d'ingénierie et de revue.
Cette base de code applique des modèles Rust courants pour les secrets ; ils ne sont pas automatiques pour chaque type :
zeroize::Zeroize / ZeroizeOnDrop effacent les tampons à la libération ; les appelants y adhèrent.subtle::ConstantTimeEq (et similaires) lorsque le temps compte — un == ordinaire n'est pas magiquement à temps constant.Copy sur les wrappers de secrets réduit la duplication accidentelle ; la séparation de domaine utilise des types distincts et des étiquettes HKDF (Politique de dépendances cryptographiques).catch_unwind ou abort là où votre plateforme exige des garanties plus fortes.unsafe doit être explicitement écrit dans la source, ce qui réduit la revue manuelle. Dépendances : la politique cryptographique de ce projet privilégie les crates Rust audités (RustCrypto et autres) ; voir le tableau dans Politique de dépendances cryptographiques — toutes les dépendances ne proviennent pas d'un seul projet parapluie. Pour la liste complète des crates et si chaque dépendance est inchangée, modifiée/vendue, ou écrite par le projet, voir docs/CRATE_DEPENDENCIES.md.
Rust ne supprime pas les interblocages (par ex. verrous Mutex mal ordonnés), les bogues logiques, les protocoles incorrects, l'usure de la flash due à de mauvaises boucles, les attaques physiques (glitching, analyse de puissance), ni les risques d'une construction correcte de la mauvaise image. Il ne garantit pas non plus une exécution à temps constant sur tout matériel sans codage soigné. Ces domaines reposent sur la conception, la revue, les tests et les pratiques crypto et chaîne d'approvisionnement du projet décrites ailleurs dans ce README.
Vérification (tests et fuzzing) : Au-delà du langage, ce dépôt utilise des tests unitaires, des tests d'intégration, des harnais de timing dudect et des cibles libFuzzer (cargo-fuzz). Les résumés et matrices se trouvent dans Résultats des tests ; les métadonnées d'exécution enregistrées commencent à docs/TEST_RESULTS.md#run-metadata. Des tests réussis ne prouvent pas la préparation à la production ni l'absence de vulnérabilités — ils réduisent le risque. Vous jugez si l'exécution de builds ou de tests est acceptable pour votre environnement ; une machine virtuelle est facultative mais limite le rayon d'impact sur votre machine.
Toute plateforme de VM majeure convient — VirtualBox (gratuit, open source), QEMU (gratuit, open source, en ligne de commande), ou VMware. Un invité Linux est recommandé car l'environnement de build y est le mieux pris en charge.
Démarrage rapide avec QEMU et 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
À l’intérieur de la VM, les instructions de compilation standard s’appliquent. La VM peut
être **snapshottée** avant chaque expérience et **restaurée proprement** si
quoi que ce soit tourne mal.
### Évaluation des risques et déploiement
**En fin de compte, la décision de savoir si ce firmware est sûr à déployer dans votre
environnement ne peut être prise que par vous**, en fonction de votre propre
évaluation des risques, de la sensibilité de ce que vous protégez, et
de votre choix d’attendre ou non un audit tiers indépendant
avant le déploiement. Ce projet vise à vous donner toutes les
informations nécessaires pour prendre cette décision vous-même.
Une liste structurée des actifs, des menaces **T1–T14**, des non-objectifs explicites et des lacunes de vérification Q2 se trouve dans **[docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREAT_MODEL.md)**.
---
## À propos du nom
**Galdr** est la pratique en vieux norrois de la magie parlée ou chantée : des incantations
utilisées pour lier, protéger ou révéler. Dans les sagas, il désigne l’acte de lancer
le sort lui-même, et non seulement les mots. Il est parfois aussi utilisé pour activer des
inscriptions runiques magiques, comme sur la [hampe de lance de Kragehul I](https://en.wikipedia.org/wiki/Kragehul_I),
l’[amulette de Lindholm](https://en.wikipedia.org/wiki/Lindholm_amulet),
le [bractéate de Vadstena](https://en.wikipedia.org/wiki/Vadstena_bracteate),
et d’autres découvertes en vieux Futhark.
**Galdralag** est la forme métrique utilisée pour le galdr : un vers structuré, précis,
et régi par des règles dans lequel le motif fait partie de la force du sort.
Le suffixe *lag* est apparenté à « loi » ou « motif ».
**Les runes** étaient littéralement un savoir secret et encodé — l’usage chamanique
n’était connu que de ceux qui le comprenaient.
---
## Documentation
**Glossaire :** [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md) — termes expliqués en **langage simple** (triés de A à Z). Commencez ici si le README ou d’autres docs vous semblent trop techniques.
**Débogage :** [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DEBUG_INSTRUCTIONS.md) — backtraces, réduction de `cargo test`, raccourcis `xtask`, vérifications triples du firmware, fuzzing, et ce qu’il faut collecter avant de signaler un problème.
**Assistants IA (Claude, Cursor) :** [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/CLAUDE.md) — instructions de projet pour les agents de codage. Règles spécifiques à Cursor : [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/main/.cursor/rules).
**Parcourir tous les fichiers :** [github.com/Supermagnum/Galdralag-firmware — `docs/`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs)
**Matériel (dongle USB et associé) :** Deux arborescences KiCad : [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-files-usb) — `dabao_v3c` (jeton USB-A **sans** micro-SD) ; et [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card) — `dabao_v3c_sdcard` (même disposition de base **avec** support micro-SD), gerbers, BOM, sorties de production, et [docs de brochage](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card/docs/pinout/README.md). La disposition du PCB du dongle USB-A (jeton minimal vs évaluation au format Pico) est décrite dans [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md).
| Document | Description |
|----------|-------------|
| [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-files-usb) | Projet KiCad **dongle USB** `dabao_v3c` (sans micro-SD) ; gerbers, BOM, sorties de production ; complète [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) | Projet KiCad **dongle USB** `dabao_v3c_sdcard` (support micro-SD) ; gerbers, BOM, brochage sous [docs/pinout](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card/docs/pinout/README.md) ; complète [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) | **Index des fonctions et modules** de l’espace de travail (`pub fn` / types par fichier avec ancres de ligne) |
| [docs/CRATE_DEPENDENCIES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CRATE_DEPENDENCIES.md) | Crates Rust **amont vs projet** et leurs dépendances mutuelles |
| [docs/API_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/API_REFERENCE.md) | Carte du code + **annexe** pour IETF/I-D/GnuPG/Sequoia : construction Shamir GF(256), armure GALDRA SHARE, format fil ECDH éphémère, étiquettes HKDF, préimages ; routes `galdrad` ; indications rustdoc |
| [docs/ARCHITECTURE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/ARCHITECTURE.md) | Architecture du firmware de haut niveau et sous-systèmes principaux |
| [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/AUDIT_LOG.md) | Enregistrements d’audit de profil (`cipher-profile`), hook OpenPGP `OpenPgpAudit` ; **aucun** journal RRAM append-only implémenté pour l’instant |
| [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_API.md) | Pré-porte biométrique : architecture, format fil, disposition du coffre ; intégration partiellement implémentée |
| [docs/BIOMETRIC_DEVICE_GUIDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_DEVICE_GUIDE.md) | Comment ajouter la prise en charge d’un nouveau backend matériel biométrique |
| [docs/BIOMETRIC_TESTING.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_TESTING.md) | Méthodologie de test : métriques PAD ISO/IEC 30107-3, jeux de données, comment exécuter |
| [docs/FINGERVEIN_DEVICE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/FINGERVEIN_DEVICE.md) | Dispositif ouvert de veine du doigt ESP32-CAM : matériel, ébauche de protocole, vivacité |
| [docs/SWEET_PLATFORM_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/SWEET_PLATFORM_INTEGRATION.md) | Scanner de main sweet platform : matériel, intégration, vivacité, jeu de données |
| [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRA-TOOL.md) | Outils hôte (`galdra`, `galdrad`, `galdra-gtk`) : flux de travail, provisionnement, politique PIN, comportement opérationnel |
| [Supermagnum/Fulla](https://github.com/Supermagnum/Fulla) | **Fulla** : registre de clés publiques OpenPGP orienté WoT (dépôt serveur et implémentation). **Aucune instance de registre public n’est encore en cours d’exécution** ; une est prévue. **`galdra keyserver push`** / **`galdra keyserver fetch`** et la configuration optionnelle **`[keyserver]`** ciblent cet écosystème — voir aussi [Web of Trust et Key Signing Parties](#web-of-trust-and-key-signing-parties). Des notes de conception complémentaires restent dans [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) | **Glossaire en langage simple** (A–Z) pour les lecteurs non techniques ; les détails techniques restent dans les docs liées |
| [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/CLAUDE.md) | Instructions pour **Claude** / agents de codage IA ; renvoie à [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/main/.cursor/rules) pour **Cursor** |
| [docs/GALDRALAG_DEV_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRALAG_DEV_REFERENCE.md) | Chaîne d’outils, commandes `xtask`, points d’entrée de test fuzzing et crypto |
| [docs/dev-ref.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/dev-ref.md) | Disposition de l’espace de travail, crates, traits HAL, comportement USB/PSRAM, invariants de sécurité |
| [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DEBUG_INSTRUCTIONS.md) | Débogage : `RUST_BACKTRACE`, builds verbeux, tests ciblés, recettes `xtask`, vérifications cibles embarquées, pistes de fuzzing, vérifications hôte OpenPGP |
| [docs/KEY_LIFECYCLE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/KEY_LIFECYCLE.md) | Génération de clés, import, politique d’export, rotation, zéroisation, Shamir (tel que reflété dans `vault` / OpenPGP) |
| [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md) | Application carte OpenPGP, configuration hôte GnuPG/CCID, emplacements de clés, algorithmes, udev |
| [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md) | Système de profils de chiffrement et configuration |
| [docs/DUAL_KEY_QUORUM.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DUAL_KEY_QUORUM.md) | Quorum de deux (ou N) clés matérielles comme modèle d’extension d’intégrateur sur Shamir et OpenPGP ; non imposé par le firmware |
| [docs/CIPHER_PROFILE_SECURITY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILE_SECURITY.md) | Considérations de sécurité : identifiants de profil en clair, analyse de trafic, justification de l’enveloppe externe BrainpoolP384r1, identifiants chiffrés, propriété de wildcard |
| [docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md) | Alignement [CESS](https://github.com/Supermagnum/CESS/tree/main) : disposition fil Mode A, `suite_id` depuis [ALGORITHM-REGISTRY.md — table de correspondance](https://github.com/Supermagnum/CESS/blob/main/ALGORITHM-REGISTRY.md#cipher-suite-identifier-lookup-table), registre des écarts (AES/SHA-2 conservés vs CESS-CORE), feuille de route |
| [crates/cess](https://github.com/supermagnum/galdralag-firmware/blob/main/crates/cess) | CESS Mode A : HKDF-BLAKE3 (`derive_k_outer`, `hkdf_blake3`), scellement/ouverture ChaCha externe, disposition `suite_id \|\| inner_blob` ; voir [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) | Protocole de session ECDH éphémère authentifiée |
| [Supermagnum/CESS](https://github.com/Supermagnum/CESS) | **CESS** (*Cryptologically Enchanted Shamir's Secret*) — spécification ouverte (texte normatif et vecteurs de test) pour le partage de secret à seuil avec chiffrement authentifié, enveloppement de partage par mot de passe, et échange de clés hybride post-quantique optionnel ; distinct de ce firmware mais dans le même espace de conception que Shamir et les profils de chiffrement ici |
| [docs/PQ_SIGNATURES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/PQ_SIGNATURES.md) | Signatures à état post-quantiques (XMSS, LMS/HSS), activation par fonctionnalité |
| [docs/Psram.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/Psram.md) | Volume leurre microSD optionnel et comportement associé |
| [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md) | RRAM sur puce de **4 194 304 octets** : décalages du coffre depuis la source, mappage HAL, notes d’usure / zéroisation |
| [docs/TEST_RESULTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/TEST_RESULTS.md#run-metadata) | S’ouvre sur **Run metadata** ; résumé du pipeline, vecteurs, dudect, cargo-fuzz ([Section 6](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/TEST_RESULTS.md#6-cargo-fuzz-libfuzzer)), cycle de vie des clés |
| [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREE_FACTOR_AUTH.md) | Jeton + PIN + biométrie optionnelle : ce que ce dépôt implémente vs placeholder ; esquisse de menaces |
| [docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREAT_MODEL.md) | Modèle de menaces : actifs, menaces T1–T14, ce qui est et n’est pas défendu, éléments non vérifiés en attente du matériel Q2, statut d’audit |
| [docs/PERFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/PERFORMANCE.md) | Notes de performance |
| [docs/HARDWARE_BRINGUP_TEST_PLAN.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_BRINGUP_TEST_PLAN.md) | Mise en service du premier matériel Q2 : image avec `galdralag-service`, libccid `1D50:6197`, ATR → APDUs `gpg --card-status`, PIN de laboratoire Dabao (pas CDC sur `dabao-ccid`) |
| [docs/XOUS_CORE_UPSTREAM_REQUESTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/XOUS_CORE_UPSTREAM_REQUESTS.md) | Modifications qui appartiennent à xous-core (docs Persona A, politique ATR, notes cratespec) ; Galdralag ne patche pas cette arborescence |
| [docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_VERIFICATION.md) | Zéroisation matérielle : vérification par simulation vs silicium |
| [docs/HARDWARE_TEST.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_TEST.md) | Notes de test orientées matériel |
| [docs/NFC_PN532_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/NFC_PN532_INTEGRATION.md) | PN532 / NFC : libnfc, options Rust, porte passive vs panneau USB, quorum avec Shamir et PIN |
| [docs/SDMMC_STORAGE_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/SDMMC_STORAGE_INTEGRATION.md) | `embedded-sdmmc` + microSD SPI comme stockage de masse optionnel ; alternative BOM au PSRAM |
| [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) | Comment fabriquer un PCB de dongle USB-A à partir de la référence Dabao : l’évaluation au format Pico est pour la mise en service du firmware ; cela retire l’en-tête GPIO pour un jeton minimal ; KiCad, FreeCAD, 5 V / 500 mA vs USB-C PD, routage QSPI PSRAM |
Les mêmes chemins se résolvent sur GitHub sous [`tree/main/docs`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs) et [`tree/main/Hardware`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/Hardware).
---
## Compatibilité OpenPGP et GnuPG
Le firmware implémente l’**application carte OpenPGP** (documentée comme version **3.4.1** dans [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md)). C’est la même classe de dispositif que GnuPG pilote pour les **cartes à puce OpenPGP** sur **CCID/USB** : l’hôte a besoin d’une pile de cartes à puce normale (`pcscd`, pilotes `ccid`, `scdaemon` de GnuPG). **Aucun pilote cryptographique hôte personnalisé** n’est requis au-delà de ce que vous utiliseriez pour n’importe quelle carte OpenPGP.
**Ce que cela permet sur l’hôte (une fois le dispositif visible comme lecteur CCID) :**
| Domaine | Notes |
|------|--------|
| **Flux de travail GnuPG** | `gpg --card-status`, `gpg --card-edit`, chiffrement/déchiffrement et signature avec les clés de la carte |
| **SSH** | `gpg-agent` avec `enable-ssh-support` et la configuration habituelle `SSH_AUTH_SOCK` |
| **Courrier et fichiers** | Clients qui utilisent GnuPG (par ex. Thunderbird, Evolution, Kleopatra) et chiffrement de fichiers `gpg` standard |
| **Autres outils** | Tout ce qui parle carte OpenPGP + CCID de la même manière que GnuPG |
**Emplacements de clés (défauts typiques) :** **SIG** (signature), **DEC** (déchiffrement / ECDH), **AUT** (authentification, par ex. SSH). Les algorithmes opérationnels par emplacement sont les courbes Brainpool, NIST P-256/P-384, et Ed25519 / X25519. Les attributs d’algorithme RSA peuvent être stockés via PUT DATA, mais GENERATE, PSO:CDS et PSO:DECIPHER échouent tous pour les emplacements configurés RSA. Le tableau complet et le comportement `key-attr` se trouvent dans [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md).
**Non couvert par la carte OpenPGP / GnuPG ici :** **WebAuthn / FIDO2** est un protocole différent et hors de portée pour cette application carte (voir le même doc).
**Carte OpenPGP vs messages OpenPGP :** La spécification de **carte** définit comment le jeton expose les PIN, les emplacements de clés et les opérations sur carte via CCID. **GnuPG** l’utilise via `scdaemon`. Le **format de message OpenPGP** pour les fichiers et le courrier (RFC 4880 et successeurs) est une couche **côté hôte** : la carte fournit les clés ; GnuPG applique toujours le format de message sur le PC. Ni la spécification de carte ni la RFC 4880 ne définissent le **partage Shamir**, les **sessions ECDH éphémères** ou les **profils de chiffrement** — ce sont des [fonctionnalités spécifiques au firmware](#standards-vs-fonctionnalités-spécifiques-au-firmware).
**Statut d’intégration :** La logique OpenPGP et CCID vit dans **`usb-personality`**, **`baochip-openpgp`**, et le service **Xous** **`usb-bao1x`** (voir **xous-core** sur **`feature/usb-bao1x-ccid-openpgp`**). Le **`galdralag-service`** optionnel (`services/galdralag`) se connecte à **`usb-bao1x`** pour l’IPC **CCID** et répond aux APDUs **XfrBlock** ; les images Dabao en ont besoin via cratespec (`scripts/build_dabao_ccid_image.sh`). BaoSec peut encore relier **PDDB** dans **RRAM**. Détails : [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/main/services/galdralag/README.md). Disposition mémoire : [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md). **GnuPG de bout en bout sur matériel réel** nécessite encore une image complète avec Galdralag, la reconnaissance hôte **libccid** de **`1D50:6197`**, et les éléments sous [Limitations connues / travaux ouverts](#limitations-connues--travaux-ouverts).
## Session de jeton et export de clés
**Déconnexion physique (débranchement) :** L’hôte perd le dispositif USB ; toute opération en cours échoue jusqu’à ce que le jeton soit reconnecté et ré-énuméré. Sur le dispositif, la **session carte** OpenPGP est effacée : **l’état de vérification PIN** ne survit pas à la mise hors tension ou au retrait, donc **la signature, le déchiffrement et les autres opérations protégées nécessitent à nouveau VERIFY PIN** après reconnexion, comme les autres cartes à puce OpenPGP. **Le matériel de clé privée reste stocké sur le jeton** dans le stockage de coffre scellé ; le débranchement ne l’efface pas sauf si une **zéroisation** ou un chemin d’effacement séparé s’exécute.
**Ce qui peut quitter le dispositif :** Par conception, **seul le matériel de clé publique** est autorisé à traverser le lien USB (par exemple les paquets de clé **publique** OpenPGP et les données associées que la spécification de carte expose à l’hôte). Les clés **privées**, les scalaires secrets bruts et les blobs de clés scellés **ne** quittent **pas** le dispositif via les chemins normaux du firmware ; les opérations de clé privée s’exécutent **sur le jeton**. L’hôte reçoit des **résultats cryptographiques** (signatures, texte en clair déchiffré pour les flux de travail de déchiffrement assisté par carte) là où les commandes standard l’exigent, et non une copie portable de la clé privée.
**Importation de clés sur le dispositif :** Il est également possible d’**importer des clés publiques** dans le jeton (par exemple des ancres de confiance, des certificats pairs, ou des paquets publics OpenPGP pour la vérification sur dispositif). Le **coffre** du firmware fournit des **emplacements de clés publiques** pour le matériel non secret (`crates/vault/src/public_key_vault.rs`). L’outillage hôte pour charger ces emplacements est décrit dans [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRA-TOOL.md) à mesure que l’intégration mûrit.
---
## Web of Trust et Key Signing Parties
OpenPGP et **GnuPG** utilisent un modèle de confiance décentralisé — le **web of trust** — pour aider à vérifier qui possède quelles clés et s’il faut se fier à une **clé publique** donnée. Ce modèle est entièrement **côté hôte**. Là où les attestations adossées à une puce telles que [l’eID allemand et Governikus](#eid-allemand-et-governikus-comme-ancre-de-confiance-pour-les-clés-publiques) sont indisponibles ou inappropriées, c’est l’alternative décentralisée habituelle (**key signing parties**, signatures sur certificats) ; là où elles **sont** disponibles, les deux approches peuvent coexister comme chemins complémentaires.
**Empreinte Galdralag (`G:`) :** Pour les flux de travail de vérification en personne, **Galdra** peut afficher une empreinte **liée au dispositif** dérivée de la clé publique **SIG** du jeton (**BLAKE3-160**, préfixe `G:`). Ce **n’est pas** une empreinte de certificat OpenPGP v4. Elle n’est **disponible** que lorsque le **profil de chiffrement** actif a **`ephemeral_ecdh: false`** ; les profils intégrés par défaut ont **`ephemeral_ecdh: true`**, donc vous ajoutez généralement un profil utilisateur avec **`galdra profile add ... --no-ephemeral-ecdh`** pour les flux de travail qui nécessitent cet identifiant en plus de la signature hôte de style **WoT**. Définition en langage simple et spécification de format : [Empreinte Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md#g). Cycle de vie, politique de rotation et porte ECDH éphémère : [KEY_LIFECYCLE.md — Empreinte Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/KEY_LIFECYCLE.md#galdralag-fingerprint-host).
### Obtenir votre empreinte Galdralag
L’hôte imprime une chaîne qui **commence toujours par `G:`** (BLAKE3-160 sur les octets de la clé publique SIG, **40 caractères hexadécimaux minuscules** après le préfixe sous forme canonique).
1. Installez **[Galdra](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRA-TOOL.md)** sur l’hôte et assurez-vous que **PC/SC** fonctionne (**`pcscd`**, **`libpcsclite`**) pour que l’outil puisse parler CCID au jeton (voir [Compiler et installer les outils hôte](#compiler-et-installer-les-outils-hôte-galdra-galdrad-galdra-gtk)).
2. Connectez le jeton (déverrouillez-le si votre flux de travail l’exige).
3. Sélectionnez un **profil de chiffrement** avec **`ephemeral_ecdh: false`**. Confirmez avec **`galdra profile show <name>`** (`ephemeral_ecdh: off`). Le nom de profil par défaut **`standard`** a généralement **`ephemeral_ecdh: on`** ; créez-en un avec **`galdra profile add <name> ... --no-ephemeral-ecdh`** si nécessaire.
4. Exécutez :```bash
galdra identity fingerprint
# If you use a non-default profile:
galdra identity fingerprint --profile <name>
Sortie lisible par machine : galdra --emit json identity fingerprint (éventuellement --profile <name>).
Les implémentations conformes à OpenPGP incluent un mécanisme de vérification des certificats destiné à aider à vérifier la propriété des clés ; son fonctionnement a été qualifié de web de confiance. Les certificats OpenPGP (une ou plusieurs clés publiques plus des données d’identifiant de propriétaire/utilisateur) peuvent être signés numériquement par d’autres utilisateurs qui, ce faisant, approuvent l’association entre cette clé publique et la personne ou l’entité nommée sur le certificat.
gpg --full-generate-key sur l’hôte, ou portée sur un jeton compatible OpenPGP).Une réunion de signature de clés est une rencontre en personne où les participants échangent leurs empreintes de clés et vérifient l’identité de chacun avant de signer les certificats ultérieurement.
Caractéristiques typiques :
Cela produit un graphe social : si Alice fait confiance à Bob et que Bob a signé la clé de Charlie, Alice peut choisir de faire confiance à la clé de Charlie selon la profondeur de confiance et la politique.
Pourquoi ces événements comptent :
Les réunions évitent généralement les ordinateurs pendant l’échange d’identités, afin que les attaquants aient moins d’occasions d’introduire des clés substituées ou des logiciels malveillants sur des machines partagées.
Avant l’événement. Calculez et notez votre empreinte (un condensé dérivé par hachage de la clé publique—suffisamment court pour être comparé de manière fiable). Ne comptez pas sur l’échange de clés complètes sur papier à ce stade, sauf si vos organisateurs en décident autrement.```bash
gpg --fingerprint YOUR_KEY_ID
Apportez l’empreinte sur papier ou sur un autre support durable (exemple de forme : `ABCD 1234 EFGH 5678 90AB CDEF 1234 5678 90AB CDEF`).
**Lors de l’événement (empreintes uniquement).** Échangez les **empreintes**, vérifiez les pièces d’identité et notez quelles empreintes appartiennent à quelle personne vérifiée. Confirmez que l’identité revendiquée par chaque participant correspond aux documents contrôlés.
**Après l’événement.** Récupérez les **clés publiques** complètes depuis des **serveurs de clés** ou par distribution directe ; confirmez que les clés téléchargées correspondent aux **empreintes** notées sur papier ; **signez** les clés que vous avez vérifiées ; éventuellement **téléversez** les signatures afin que d’autres puissent les utiliser.
### Empreintes plutôt que clés complètes lors de l’événement
- **Sécurité opérationnelle.** Maintient les attaques par substitution liées aux empreintes vérifiées plutôt que de faire confiance à des machines arbitraires en pleine manifestation.
- **Simplicité.** Les empreintes tiennent sur papier et sont rapides à lire à voix haute ou à comparer.
- **Vérification.** Après le téléchargement, le recalcul de l’empreinte vérifie l’intégrité de bout en bout.
### Serveurs de clés
Les **serveurs de clés** sont des dépôts en réseau qui stockent et répliquent les clés OpenPGP **publiques** (ainsi que les mises à jour telles que les signatures et les révocations). Ils rendent les clés découvrables par **User ID**, **ID de clé** ou **empreinte** et soutiennent la distribution à grande échelle pour le réseau de confiance.
Leur comportement en principe :
- **Réplication distribuée.** Le téléversement vers un serveur participant à un maillage de synchronisation se propage souvent aux pairs (les pools classiques de type **SKS** fonctionnaient ainsi).
- **Synchronisation.** Les nouvelles clés, signatures et certificats de révocation se propagent selon la politique et la connectivité de chaque serveur.
- **Accès public en lecture.** Seul le matériel **public** est destiné à la publication ; les **clés privées** ne doivent jamais être téléversées.
**Confidentialité.** Les clés publiées exposent les **User IDs** (incluant souvent des adresses e-mail). Considérez les téléversements comme **publics et durables** sur de nombreux serveurs ; téléversez des **certificats de révocation** lorsqu’une clé doit être retirée. La politique varie selon l’opérateur ([keys.openpgp.org](https://keys.openpgp.org/) diffère des pools historiques).
**Topologie des pairs.** Des graphes des relations entre serveurs sont disponibles sur [spider.pgpkeys.eu/graphs/](https://spider.pgpkeys.eu/graphs/) ; les listes de pairs orientées SKS sur [spider.pgpkeys.eu/sks-peers](https://spider.pgpkeys.eu/sks-peers).
### Utilisation des serveurs de clés```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
| Serveur | Remarques |
|---|---|
| keys.openpgp.org | Largement utilisé ; vérification orientée consentement pour les identifiants d'utilisateur liés à un e-mail |
| pgp.mit.edu | Serveur hébergé par le MIT, historiquement lié aux maillages de l'ère SKS |
| pool.sks-keyservers.net | Nom d'hôte de pool hérité associé à l'ancien écosystème SKS ; la connectivité actuelle varie |
gpg --refresh-keys périodiquement afin que les révocations et les nouvelles signatures se propagent localement.ephemeral_ecdh: false avec galdra profile show <name>.Pour le comportement faisant autorité de gpg, les modèles de confiance et les options de distribution, consultez le manuel GnuPG et la documentation en amont.
Le projet Fulla (Supermagnum/Fulla sur GitHub) héberge le travail sur le serveur d'enregistrement aligné sur la toile de confiance (WoT) : l'implémentation et la spécification évolutive pour stocker les clés publiques des contributeurs ainsi que des étiquettes radio amateur facultatives, des indices postaux, organisation (orthographe JSON), role, note, badge_number, phone_number et des colonnes associées alignées sur les métadonnées de contact Galdra. galdra keyserver push soumet un JSON POST /api/v1/keys (incluant armored_public_key, email et ces champs facultatifs lorsque vous passez des drapeaux CLI) ; galdra keyserver fetch et la section de configuration [keyserver] sont implémentés dans / dans cette direction. ; un service exploité publiquement est attendu à l'avenir. Des textes de conception historique supplémentaires se trouvent dans .
Différentes parties de ce projet s'alignent sur différentes normes. L'interopérabilité GnuPG se limite à ce que définissent l'application de carte OpenPGP et CCID. D'autres fonctionnalités sont implémentées dans le firmware (et parfois dans les outils hôtes Galdra) mais ne sont pas invocables via les flux de travail standard de carte gpg.
Pour le comportement de carte au quotidien, fiez-vous à docs/OPENPGP_CARD.md. Pour les fonctionnalités uniquement coffre ou uniques au jeton, utilisez le firmware de ce dépôt et la documentation de l'outil Galdra.
Les piles OpenPGP card et GnuPG ne définissent pas le partage de secret de Shamir (SSS) pour les clés ou pour le déverrouillage de disque. SSS reste utile en complément du chiffrement normal : il ne remplace presque jamais le chiffrement symétrique sur le disque — il protège le petit secret (clé maîtresse ou phrase de passe) qui déverrouille ce chiffrement.
Modèle (toujours la même idée) :
1. LUKS (Linux) et SSS externe
LUKS chiffre le volume avec une clé maîtresse. Vous pouvez extraire cette clé (ou un secret d'emplacement de clé, selon votre procédure), la diviser avec un outil SSS et stocker les parts séparément. Au moment du déverrouillage, combinez K parts, reconstruisez le matériel de clé et fournissez-le à cryptsetup (consultez la documentation de votre distribution ; une mauvaise manipulation des clés peut rendre l'accès impossible).
Exemple de forme utilisant les utilitaires ssss (« Shamir's Secret Sharing Scheme ») (les noms et le packaging varient selon l'OS) :```bash
ssss-split -t 3 -n 5 < luks_master.key
ssss-combine -t 3 | cryptsetup luksOpen /dev/sdX vault
**2. HashiCorp Vault**
[Vault](https://www.hashicorp.com/products/vault) utilise Shamir pour le **déscellage** : la clé de chiffrement du stockage est divisée lors de l'initialisation (par exemple, 3 opérateurs sur 5 détiennent chacun une part). Après un redémarrage, **K** parts doivent être saisies pour désceller. Le même schéma **K-de-N sur un secret maître** que LUKS, appliqué à un moteur de secrets plutôt qu'à un périphérique de bloc.
**3. Firmware Galdralag (`vsss-rs`)**
Ce dépôt utilise [`vsss-rs`](https://crates.io/crates/vsss-rs) (écosystème RustCrypto) pour Shamir sur l'appareil. La même **stratification** s'applique si vous l'alignez avec le chiffrement en masse :
- Générez une clé maîtresse aléatoire de 256 bits (ou adaptée).
- Chiffrez le disque ou le stockage en masse avec **AES-GCM** ou **ChaCha20-Poly1305** en utilisant cette clé (cela correspond aux crates symétriques audités de l'espace de travail).
- Utilisez `vsss-rs` pour diviser la clé maîtresse en **N** parts avec un seuil **K**.
- Stockez les parts dans des emplacements de coffre, sur d'autres appareils, ou chez des détenteurs de clés.
- Au démarrage ou lors de la récupération, collectez **K** parts, reconstruisez, puis utilisez **HKDF** (ou votre politique) pour des sous-clés séparées par domaine si nécessaire.
**4. VeraCrypt**
VeraCrypt n'implémente pas SSS en interne. Le même schéma **externe** s'applique : divisez la **phrase de passe ou le matériel de fichier-clé** avec un outil SSS ; n'essayez pas de diviser le texte chiffré du volume avec Shamir.
### Schéma hybride (grandes données)
SSS est destiné aux **petits secrets** (taille de clé). Vous **n'appliquez pas** Shamir à un texte chiffré de plusieurs gigaoctets. La stratification habituelle :```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)
Cela correspond à ce que ce projet empile déjà : aes-gcm / chacha20poly1305 pour les données au repos, vsss-rs pour le partage du secret maître, hkdf pour la dérivation après reconstruction.
| Décision | Options typiques |
|---|
La gestion opérationnelle des clés pour LUKS et le chiffrement de disque complet est sensible en matière de sécurité ; suivez les recommandations du fournisseur et de la distribution ainsi que les modèles de menace pour votre environnement.
Autorisation à deux clés matérielles / quorum (exigeant deux jetons physiques séparés
ou détenteurs de parts avant une opération critique) est un modèle d'extension pris en charge,
pas une fonctionnalité du firmware. Galdralag fournit les primitives Shamir K-sur-N
(vault::shamir, galdra shamir)
et l'authentification OpenPGP à jeton unique ; un wrapper LUKS en aval, un panneau
d'accès, ou un démon personnalisé doit appliquer le quorum, les fenêtres de session, et la
reconstruction sécurisée. Cette limite, les flux de travail de référence 2-sur-N, et les notes de
sécurité pour les intégrateurs se trouvent dans docs/DUAL_KEY_QUORUM.md. C'est
possible avec les primitives existantes aujourd'hui ; l'orchestration est volontairement laissée au
consommateur — pas un engagement de feuille de route de ce dépôt.
Un modèle concret est un disque ou volume chiffré avec des courbes Brainpool lorsque votre pile les exige (par exemple ECDH/ECDSA autour d'un secret maître), combiné avec le partage de secret de Shamir sur le matériel de clé qui déverrouille ce chiffrement (le même cloisonnement de petits secrets que ci-dessus : SSS protège la clé, pas le texte chiffré de plusieurs gigaoctets). Si et quand le firmware et le logiciel hôte implémentant ce flux de travail ont été audités indépendamment, une telle combinaison peut être précieuse pour les organisations qui doivent satisfaire à la fois les politiques de quorum et les profils cryptographiques nationaux.
Pourquoi les courbes Brainpool (par ex. BrainpoolP256r1, BrainpoolP384r1) sont souvent discutées dans ce contexte :
Scénarios où la combinaison de SSS avec une cryptographie de classe Brainpool répond aux besoins institutionnels (illustratif ; pas un conseil juridique ou de conformité) :
Si la signature OpenPGP de style Governikus ou une attestation eID nationale comparable adossée à une puce n'est pas disponible ou pratique pour votre juridiction ou flux de travail, Web of Trust et Key Signing Parties décrit une approche alternative côté hôte basée sur la vérification en personne et les signatures de tiers sur les certificats.
Authentification de clé OpenPGP Governikus est un service en ligne géré au nom du BSI (Office fédéral allemand de la sécurité de l'information). Après que le soumissionnaire s'est authentifié avec une carte d'identité compatible eID allemande, une carte eID de l'UE pour les citoyens de l'UE, ou un titre de séjour électronique, le service vérifie que le nom légal authentifié correspond à l'ID utilisateur OpenPGP sur la clé publique téléchargée. Si cela correspond, Governikus signe cette clé publique avec la clé de signature du service afin que des tiers puissent vérifier l'attestation.
Un flux de travail pratique avec ce firmware : générer une clé asymétrique Brainpool sur le jeton (génération de carte OpenPGP comme d'habitude), exporter la clé publique ou le certificat vers l'hôte, compléter le flux de soumission Governikus y compris l'authentification eID (généralement AusweisApp et lecture de carte NFC), et utiliser la clé publique signée renvoyée par le service (par exemple à partir d'une distribution par e-mail). La clé privée reste sur Galdralag tout au long.
Aucune des deux voies ne remplace l'autre. eID et l'étape Governikus lient la clé publique à une identité vérifiée contre la puce au moment de la soumission ; elles ne fournissent pas la confidentialité persistante (forward secrecy), le Shamir K-sur-N pour le matériel de clé à long terme, ni les profils de chiffrement pour les données en masse — ce sont des fonctionnalités spécifiques au firmware décrites ailleurs dans ce README. La puce eID et le processus d'émission environnant n'implémentent pas non plus, par eux-mêmes, l'ECDH éphémère et le comportement en cascade du jeton. Inversement, une clé OpenPGP Brainpool générée sur l'appareil s'aligne sur le contexte de déploiement BSI/UE déjà discuté pour l'utilisation institutionnelle de Brainpool, mais sans étape d'attestation externe, les correspondants doivent s'appuyer sur d'autres moyens pour relier une empreinte à une personne morale.
| Couche | Rôle |
|---|---|
| Clé publique OpenPGP (par ex. Brainpool sur Galdralag) | Structure cryptographique et contrôle de la clé privée sur jeton ; les choix de courbes suivent les attentes de classe BSI TR-03111 (voir les et la discussion TR-03111 dans ) |
Limitation : La vérification est basée sur le nom. Si deux personnes partagent le même nom légal dans les champs que le service compare, l'attestation ne les distingue pas ; elle confirme le lien d'identité à ce nom au moment de l'attestation, pas l'unicité globale. Les préoccupations OpenPGP courantes (liaison d'e-mail, rotation de clé, révocation) restent en vigueur.
Alignement politique : le même BSI qui définit les orientations techniques liées à Brainpool (BSI TR-03111 ; vecteurs de conformité sous crates/vault/tests/bsi_vectors/) soutient également le processus de signature eID Governikus, ce qui importe souvent dans les contextes allemands et de l'UE où Brainpool est déjà exigé ou préféré — voir Shamir plus Brainpool : exemple et adéquation institutionnelle.
Portée plus large (note de recherche, pas une enquête terminée) : Le même modèle — lier une clé publique OpenPGP à une identité vérifiée par puce — est applicable en principe partout où une eID nationale existe ; quels fournisseurs offrent une étape de signature de type Governikus, et sous quelles règles, est une question distincte qui mérite d'être étudiée à mesure que les déploiements s'étendent. D'autres États membres de l'UE gèrent des écosystèmes eID basés sur cartes sous eIDAS qui pourraient soutenir des ancres de confiance comparables ou plus fortes que la seule voie allemande ; ce README ne les catalogue pas.
L'Estonie et la Belgique ont toutes deux adopté NIST P-384 sur puce plutôt que Brainpool, tandis que le profil BSI du secteur public allemand est centré sur Brainpool (voir ci-dessus). Galdralag prend déjà en charge Brainpool et NIST P-256/P-384 sur la carte OpenPGP (docs/OPENPGP_CARD.md) ; RSA dans ce dépôt est un helper de bibliothèque galdr-vault, pas un emplacement de carte fonctionnel (Asymétrique / accord de clé). Le même modèle d'ancre de confiance ne dépend pas uniquement de la correspondance avec la préférence de courbe allemande.
En dehors de l'UE/EEE, le modèle d'ancre de confiance basé sur carte est plus difficile à appliquer : les États-Unis ont une carte à puce (PIV) mais elle est restreinte au personnel fédéral et se situe dans X.509/FPKI, non intégrée à OpenPGP ; le Canada n'a pas de carte de signature nationale sur puce au sens utilisé ci-dessus. Cela limite le modèle principalement aux juridictions disposant d'identifiants gouvernementaux sur puce délivrés universellement — la zone eIDAS de l'UE est là où le modèle est actuellement le plus solide.
Si et quand le matériel atteint un état prêt pour le consommateur, les personnes qui veulent que le partage de secret de Shamir et l'échange de clés éphémère authentifié deviennent partie intégrante du comportement interopérable OpenPGP / GnuPG (au lieu de seulement des fonctionnalités spécifiques au firmware) devraient conduire le changement de normes et d'implémentation ailleurs. Ce dépôt ne parle pas au nom de l'IETF ou de GnuPG ; les lieux ci-dessous sont où de tels amendements sont normalement poursuivis.
CESS — Cryptologically Enchanted Shamir's Secret — est une norme cryptographique ouverte pour le partage de secret à seuil avec chiffrement authentifié indépendant du chiffrement, enveloppement de part basé sur mot de passe, et échange de clés hybride post-quantique optionnel. Le dépôt CESS contient la spécification normative, le registre d'algorithmes, les vecteurs de test, et l'exécuteur de conformité.
Ce firmware est conforme à CESS pour les constructions implémentées ici : les règles interopérables de part et d'enveloppe de la spécification côtoient les mêmes thèmes Shamir, Brainpool, et profil de chiffrement décrits ailleurs dans ce README. Le texte normatif est séparé de ce dépôt ; posture de conformité (ce qui correspond à la spécification, ce qui diffère tout en conservant des algorithmes tels que AES et SHA-256 dans les profils, et la feuille de route vers une interopérabilité plus forte) : docs/CESS_CONFORMANCE.md.
Si les mainteneurs de ce dépôt GitHub ne répondent pas aux problèmes, aux demandes de tirage, ou aux courriels, vous pouvez toujours faire avancer les nouveaux chiffrements, le comportement OpenPGP, et le travail lié aux normes dans l'écosystème plus large. Sequoia PGP est une pile OpenPGP indépendante basée sur Rust (sécurité mémoire, conception bibliothèque d'abord, participation active à l'IETF/écosystème) où une grande partie du développement public se produit. Ce n'est pas ce projet ; il est documenté ici comme une voie alternative pratique lorsque l'amont ici est silencieux.
La page Contribute décrit la licence (LGPL 2.0 ou ultérieure pour la plupart des projets), le Developer Certificate of Origin, et que les fonctionnalités commerciales plus importantes peuvent nécessiter un accord préalable et des arrangements de maintenance à long terme — lisez cette page avant d'investir un effort significatif.
Il vaut aussi la peine de garder un œil sur https://autocrypt2.org/#/
Cette base de code et les applications pertinentes ne seront pas compilées pour macOS ou Windows. Les outils hôtes (galdra, galdrad, galdra-gtk) et l'outillage de support ciblent Linux. C'est une décision délibérée basée sur le modèle de menace du projet et les exigences d'auditabilité énoncées tout au long de ce document.
_NSAKEY découverte dans Windows NT en 1999 a provoqué une controverse significative. Microsoft a déclaré qu'il s'agissait d'une clé de secours ; cela n'a jamais été entièrement prouvé dans un sens ou dans l'autre.Suspecté mais non prouvé :
main, restricted, universe, et multiverse sont signés par la clé GPG de Canonical.security.ubuntu.com, qui est également signé.Les gestionnaires de paquets sont généralement sûrs, mais les installations tierces .deb / .rpm / AppImage peuvent être dangereuses. Préférez les paquets signés provenant de dépôts de confiance, et vérifiez les signatures avant d'installer quoi que ce soit obtenu en dehors de ceux-ci.
Utilisez une toolchain Rust stable telle qu'épinglée dans rust-toolchain.toml. Le firmware utilise la cible riscv32imac-unknown-none-elf ; les outils hôtes utilisent le triplet hôte.
test-hal s'infiltre dans les builds de production) : ```bash
cargo run -p xtask -- check-fw
Les code objet et les archives sont placés sous target/riscv32imac-unknown-none-elf/release/. Une image système Xous complète et amorçable pour une carte spécifique est produite par le flux d'intégration plus large Baochip / Xous lorsque vous suivez la compilation de ce produit ; xtask exécute ici cargo build pour les crates de la bibliothèque firmware listées dans xtask (pas un fichier prêt à flasher en soi).
Démon Xous CCID (galdralag-service) — nécessite la chaîne d'outils Xous riscv32imac-unknown-xous-elf (pas le triple firmware nu riscv32imac-unknown-none-elf ci-dessus).
Arborescence xous-core requise : les dépendances de chemin se résolvent via Galdralag-firmware/xous-core/. Les compilations d'image doivent utiliser une arborescence sœur (ou XOUS_CORE=) extraite sur la branche feature/usb-bao1x-ccid-openpgp (PR #937). Les arborescences imbriquées et sœurs peuvent diverger ; cargo run -p xtask -- check-xous-core échoue
avec un code non nul et affiche une commande ln -sfn <sibling> ./xous-core copiable (renommez d'abord
une véritable arborescence imbriquée si ./xous-core n'est pas déjà un lien symbolique) : ```bash
ln -sfn ../xous-core ./xous-core
cargo run -p xtask -- check-xous-core
Image Dabao CCID incluant Galdralag (dabao-ccid seul est limité au transport) : ```bash
scripts/build_dabao_ccid_image.sh
**BaoSec + PDDB :** **`cargo run -p xtask -- build-and-register release --xous-core /path/to/xous-core`**. Détails : [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/main/services/galdralag/README.md). Écarts réservés à l’amont : [docs/XOUS_CORE_UPSTREAM_REQUESTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/XOUS_CORE_UPSTREAM_REQUESTS.md).
### Flashage
Ce dépôt ne fournit **pas** encore de script de flashage en une commande. La programmation de la **Baochip-1x** (JTAG, démarrage ROM/USB ou outils du fabricant) suit la documentation de la carte et du silicium. Commencez par **[Supermagnum/Baochip-1x-firmware](https://github.com/Supermagnum/Baochip-1x-firmware)** ; le **matériel de la carte d’évaluation** se trouve dans **[baochip/dabao](https://github.com/baochip/dabao)** — sur la carte Dabao, **SW2** bascule en **mode bootloader** (voir ce schéma).
**Envoi de l’UF2 sans le bouton physique de boot :** Après avoir copié **`loader.uf2`**, **`xous.uf2`** et **`apps.uf2`** sur le volume **BAOCHIP**, vous pouvez soit appuyer sur le bouton physique **boot**, **ou** taper **`boot`** dans la console série USB **boot1** (1 000 000 bauds, p. ex. `screen /dev/ttyACM0 1000000`). Cela évite de dépendre du bouton **boot** uniquement pour cette étape. La console **se déconnecte** lorsque vous tapez **`boot`** ; c’est **normal** (le système redémarre vers l’étape suivante). Sous Linux, `dmesg --follow` aide à confirmer la ré-énumération USB. Cela diffère de **PROG** (maintenir enfoncé tout en branchant l’USB pour entrer dans le bootloader de stockage de masse **BAOCHIP**). Voir **[baochip/dabao#2](https://github.com/baochip/dabao/issues/2)** (clos).
**Flux Xous / Baochip :** Les images sont **signées Ed25519** et vérifiées par **boot0** avant exécution ; voir [Firmware signé (Ed25519, boot0)](#signed-firmware-ed25519-boot0). Pour **dabao**, la disposition **UF2**, le maintien de **PROG** lors du branchement USB pour entrer en mode stockage de masse, et les étapes de mise à jour **boot1**, voir **[Getting Started with Baochip Targets](https://github.com/betrusted-io/xous-core/blob/dev/README-baochip.md)**.
### Compiler et installer les outils hôte (`galdra`, `galdrad`, `galdra-gtk`)
Les crates hôte se trouvent à la racine de l’espace de travail : `galdra/`, `galdrad/`, `galdra-gtk/`.
**Ubuntu / Debian** (installer avant `cargo build` / `cargo install`) :```bash
sudo apt update
sudo apt install build-essential pkg-config libpcsclite-dev pcscd libssl-dev
# required only for `galdra-gtk`:
sudo apt install libgtk-4-dev
libpcsclite-dev satisfait le chemin de liaison PC/SC par défaut de galdra ; pcscd est le démon qui dessert les lecteurs de cartes à puce à l'exécution. libssl-dev est requis pour que openssl-sys puisse effectuer la liaison (les recherches de serveurs de clés sequoia-net et le TLS de ldap3 utilisent native-tls aujourd'hui). Omettez libgtk-4-dev si vous ne compilez jamais galdra-gtk.
GTK 4 (galdra-gtk uniquement) : pkg-config doit résoudre gtk4 (crate d'espace de travail gtk 0.9.x, paquet gtk4). Sur Fedora, utilisez gtk4-devel ; sur Arch, gtk4.
Compilez les binaires de version depuis la racine du dépôt :```bash cargo build --release -p galdra -p galdrad -p galdra-gtk
Executables : `target/release/galdra`, `target/release/galdrad`, `target/release/galdra-gtk`.
**Installation** dans `~/.cargo/bin` (ajustez `--path` si vous n'êtes pas à la racine du dépôt) :```bash
cargo install --locked --path galdra
cargo install --locked --path galdrad
cargo install --locked --path galdra-gtk
Vous pouvez à la place copier ces trois binaires dans n'importe quel répertoire de votre PATH.
galdrad et l'interface graphique de bureau (galdra-gtk)galdra-gtk est le binaire de bureau GTK4 (paquet Cargo galdra-gtk ; il n'existe pas de galdra-gui). C'est une interface frontale pour l'API REST galdrad — exécutez galdrad en premier.
Daemon — galdrad écoute sur 127.0.0.1:8742 par défaut (--listen permet de le remplacer) ; voir galdrad/src/main.rs.```bash
galdrad
Vérification rapide : `curl -s http://127.0.0.1:8742/health` (documentation interactive de l’API : **`http://127.0.0.1:8742/swagger-ui/`**.)
**Interface graphique de bureau** — **`galdra-gtk`** utilise **`http://127.0.0.1:8742`** par défaut (`--base-url` ou **`GALDRAD_URL`**) ; voir [`galdra-gtk/src/main.rs`](https://github.com/supermagnum/galdralag-firmware/blob/main/galdra-gtk/src/main.rs).```bash
galdra-gtk
galdra-gtk --base-url http://127.0.0.1:8742
GALDRAD_URL=http://127.0.0.1:8742 galdra-gtk
À partir d’un cargo build --release frais, sans installation : ./target/release/galdrad puis ./target/release/galdra-gtk depuis la racine du dépôt.
Hôte vs jeton : galdra-gtk reflète ce que galdrad expose via HTTP ; le déverrouillage de jeton, la provision, et les autres flux CCID restent sur la CLI galdra (voir galdra device dans docs/GALDRA-TOOL.md et le niveau 2c).
Répertoire de contacts (galdra contact, galdrad /contacts): la création d’un contact exige une adresse e-mail (CLI : --email ; HTTP : champ JSON email). Les champs facultatifs incluent le nom d’affichage (--name / name), l’organisation (--org / org), le rôle, le badge (--badge / badge), la note, l’indicatif, les identifiants Fluxer, Discord et IRC, le numéro de téléphone (--phone-number / phone_number), ainsi que des (, , , ), le radioamateur et . Ces valeurs ne sont stockées que dans les métadonnées SQLite locales (elles auprès de services externes). d’un contact (par exemple , les chemins /, de , les identifiants de membres de groupe, ou le de ) accepte l’ de la ligne, l’, l’, une (espaces ignorés), ces identifiants sociaux, ou un dans lorsqu’il est fourni sous forme de jeton décimal. peut refléter bon nombre des mêmes libellés vers un registre de style Fulla (, , , , , champs radio/sociaux/postaux et noms — voir ). Les commandes et les limites de champs sont résumées dans sous et .
Si vous avez utilisé cargo install --path comme ci-dessus :```bash
cargo uninstall galdra
cargo uninstall galdrad
cargo uninstall galdra-gtk
Si vous avez copié les binaires manuellement, supprimez les fichiers que vous avez ajoutés. Le firmware n'est pas « installé » sur l'hôte ; l'effacement ou le reflashage de l'appareil relève de votre documentation matérielle.
---
## Capacités clés
### Ce qui rend ce jeton inhabituel
Les éléments ci-dessous sont des **capacités du firmware Galdralag**, et non des exigences de l'[application carte OpenPGP](#standards-vs-fonctionnalités-spécifiques-au-firmware) ou de GnuPG.
- **Modèle de sécurité prêt pour trois facteurs** — La **possession** du jeton USB et la **connaissance** du PIN sont appliquées dans le firmware aujourd'hui ; un troisième facteur **biométrique** facultatif **n'est pas** implémenté dans ce dépôt (espace réservé : [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_API.md)). Voir [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREE_FACTOR_AUTH.md) pour le périmètre et les limites.
- **ECDH éphémère authentifié sur l'appareil** — une véritable confidentialité persistante cryptographique.
Chaque session génère une nouvelle paire de clés éphémères sur le TRNG matériel du jeton.
La clé à long terme signe l'offre éphémère mais ne participe jamais à l'accord de clés.
Les sessions passées ne peuvent pas être déchiffrées, même à partir d'une clé à long terme entièrement compromise.
À la connaissance des auteurs du projet, aucun jeton de sécurité matériel commercial ne propose cette fonctionnalité de première classe.
- **Partage de secret Shamir K-de-N sur l'appareil** — la clé à long terme peut être
divisée en N parts nécessitant K pour la reconstruire, aucun détenteur unique ne pouvant
récupérer la clé seul. À la connaissance des auteurs du projet, aucun jeton
commercial ne propose non plus cette fonctionnalité de première classe. Le **double contrôle** (deux
jetons requis avant qu'une porte ne s'ouvre ou qu'un volume ne soit monté) **n'est pas** appliqué
ici ; voir [Quorum de clé matérielle double (modèle d'intégrateur)](#quorum-de-clé-matérielle-double-modèle-dintégrateur).
- **Système de profils indépendant du chiffrement** — les chiffrements symétriques, les courbes ECDHE et la
configuration Shamir sont combinés en profils nommés et audités. Pour les données
volumineuses sous un profil, le texte en clair est chiffré **de l'intérieur vers l'extérieur** : vous pouvez
empiler **jusqu'à quatre** AEAD symétriques **différents** les uns sur les autres — ainsi
vous pouvez utiliser **trois** chiffrements indépendants dans un seul profil (par exemple
ChaCha20-Poly1305, puis Serpent-256, puis Twofish-256), ou une quatrième couche distincte
là où la politique le permet — avec **aucun chiffrement répété** dans le même profil
et un matériau de clé et de nonce dérivé par HKDF **indépendant** par couche. Les noms
intégrés tels que `standard`, `conservative` et `conservative-shamir` sont livrés avec **une
ou deux** couches ; les piles plus profondes sont destinées aux profils avancés ou personnalisés.
Règles complètes et disposition filaire : [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md).
Chaque sélection de profil est journalisée dans la piste d'audit.
- **BLAKE3 à clé entre les couches en cascade (CESS)** — En plus de l'étiquette AEAD propre à chaque
couche et de l'enveloppe extérieure ChaCha20-Poly1305 du **Mode A**, **CESS**
définit une intégrité de type **BLAKE3 à clé** **entre** les étapes de cascade internes. Pour
les profils **mappés par registre** (`suite_id` via les noms intégrés), **`cipher-profile`**
ajoute un **HMAC-BLAKE3 de 32 octets** sur la sortie AEAD de chaque couche interne avant que la
couche suivante ne chiffre ; les clés sont dérivées avec **HKDF-BLAKE3** en utilisant
`cess::cess_blake3_integrity_gap_info` ([`inner_info.rs`](https://github.com/supermagnum/galdralag-firmware/blob/main/crates/cess/src/inner_info.rs)).
Les profils intégrés **à couche unique** omettent les étiquettes supplémentaires ; les profils **personnalisés** (sans `suite_id`)
conservent la cascade héritée sans MAC inter-couches. Voir
[docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md) et
[docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md). **Comptages de combinaisons**
sous les règles de chiffrement `cipher-profile` (**cinq** primitives AEAD, **aucun chiffrement
répété** dans un profil, l'ordre compte) ; la colonne BLAKE3 est le comptage de l'**espace de conception**
CESS (activation/désactivation indépendante par intervalle), et non une bascule hôte par message :
| Longueur de cascade | Piles de chiffrements distincts ordonnées | × BLAKE3 facultatif activé/désactivé à chacun des **length−1** intervalles entre les couches |
|:--------------:|--------------------------------:|---------------------------------------------------------------------------:|
| 1 couche | 5 | 5 × 2^0 = **5** |
| 2 couches | 20 | 20 × 2^1 = **40** |
| 3 couches | 60 | 60 × 2^2 = **240** |
| 4 couches | 120 | 120 × 2^3 = **960** |
| **Total** | **205** | **1245** |
Le chiffre **205** compte **uniquement les piles de chiffrements** (permutations de 1 à 4 choix
distincts parmi AES-256-GCM, ChaCha20-Poly1305, Twofish-256, Serpent-256, Camellia-256). Le
chiffre **1245** correspond aux mêmes piles multipliées par chaque motif
**indépendant** d'activation/désactivation pour le BLAKE3 inter-couches facultatif (**2^(k−1)** motifs pour **k**
couches). **Ce firmware** applique les MAC inter-couches pour **tous** les intervalles lorsqu'un
profil intégré avec **`suite_id`** possède **≥ 2** couches (et non une bascule par intervalle).
Les noms de profils intégrés utilisent un **petit** sous-ensemble des 205.
- **Volume leurre microSD facultatif** — si une puce PSRAM est installée, un LUN de volume
leurre supplémentaire peut apparaître après le déverrouillage. **Si aucune microSD n'est installée, l'appareil
reste un jeton de sécurité matériel** (coffre, politique PIN, OpenPGP/CCID et autres
fonctions de jeton inchangées) ; seul ce volume facultatif est absent. Pour les
hôtes non informés, l'appareil présente toujours la personnalité habituelle de stockage de masse leurre
sur puce là où elle est configurée. Le contenu de la microSD, lorsqu'il est présent, est intentionnellement
non chiffré et sans particularité. Le véritable matériau de clé réside dans la RRAM sur puce derrière
le coffre et la politique PIN.
- **Pile entièrement ouverte** — RTL CERN-OHL-W-2.0, schémas ouverts, chargeur
d'amorçage reproductible, OS Rust/Xous, silicium inspectable par IRIS.
### Quorum de clé matérielle double (modèle d'intégrateur)
**Ce que c'est :** Un moyen pour les organisations d'exiger **deux (ou K-de-N) jetons
physiques ou détenteurs de parts distincts** avant qu'un **système en aval** ne déverrouille quelque chose
de critique — disques chiffrés, sessions d'administration **pare-feu ou serveur**, **coffres
médicaux**, portes sécurisées ou autres actions privilégiées.
**Ce que Galdralag fournit :** Chaque jeton est **une identifiant indépendant** :
authentification de carte OpenPGP (jeton + PIN) et, via les outils hôte, **export de part Shamir**
du matériau de clé à long terme ([`vault::shamir`](https://github.com/supermagnum/galdralag-firmware/blob/main/crates/vault/src/shamir.rs),
[`galdra shamir`](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md)). Des **identités publiques** stables (empreintes
OpenPGP, numéros de série de jeton) prennent en charge les enregistrements d'audit de **quelle clé a été utilisée, quand**.
**Ce que Galdralag ne fournit pas :** Le firmware et les outils hôte **ne bloquent pas**
la signature, le déchiffrement ou le déverrouillage tant que deux jetons ne sont pas présents ensemble. **L'application du
quorum**, les fenêtres temporelles de session, l'environnement de reconstruction sécurisé et les
**journaux d'accès** inviolables relèvent de la responsabilité de **l'intégrateur** — démon de déverrouillage LUKS,
gestion des accès privilégiés (PAM), logiciel de porte/panneau ou passerelle de politique personnalisée.
**Modèle typique :** Diviser un secret de déverrouillage maître **2-de-3** (ou similaire) ; le dépositaire
A détient la part 1 sur le jeton A, le dépositaire B détient la part 2 sur le jeton B ; au moment du déverrouillage,
la passerelle collecte **K** parts ou **K** signatures de jeton, reconstruit ou autorise
**une fois**, puis zéroise le secret. Alternative : deux opérations OpenPGP **SIGN**
sur un défi dans une fenêtre temporelle, sans reconstruction Shamir.
Il s'agit d'un **modèle d'extension pris en charge** utilisant des primitives existantes — **pas** une
| Champ | Objectif | Hôte (SQLite galdra) | Magasin de contacts sur puce | Format / limite |
|---|
| Identifiant de contact | Clé primaire hôte stable | Oui | Non | Texte (id dans SQLite) |
| Nom d'affichage | Étiquette lisible par l'humain | Oui | Oui | Chaîne UTF-8 ; 240 octets max par champ de tas sur puce |
| Adresse e-mail principale | Oui | Oui | Chaîne UTF-8 ; recherche sur puce par analyse d'e-mail | |
| Indicatif | Indicatif radioamateur | Oui | Oui | 12 octets, complété par des NUL ; recherche sur puce |
| ID d'abonné DMR | ID radio DMR | Oui | Oui | 32 bits non signé (0 = absent) ; recherche sur puce |
| Numéro de badge | ID d'employé ou de badge | Oui | Oui | Chaîne UTF-8 |
| Organisation | Agence ou employeur | Oui | Oui | Chaîne UTF-8 |
| Département | Équipe ou unité | Oui | Oui | Chaîne UTF-8 |
| Rôle | Étiquette de poste ou de fonction | Oui | Oui | Chaîne UTF-8 |
| Note | Commentaire libre | Oui | Oui | Chaîne UTF-8 |
| Affiliation radio | Étiquette de club, de réseau ou d'alliance | Oui | Oui | Chaîne UTF-8 |
| Rue | Ligne d'adresse postale | Oui | Oui | Chaîne UTF-8 |
| Pays | Nom ou code de pays | Oui | Oui | Chaîne UTF-8 |
| Code postal | Code ZIP ou postal | Oui | Oui | Chaîne UTF-8 |
| Région | État, comté ou région | Oui | Oui | Chaîne UTF-8 |
| ID Fluxer | Identifiant ou pseudo Fluxer | Oui | Oui | Chaîne UTF-8 |
| ID Discord | Identifiant utilisateur Discord | Oui | Oui | Chaîne UTF-8 |
| ID IRC | Pseudo IRC ou similaire | Oui | Oui | Chaîne UTF-8 |
| Numéro de téléphone | Numéro de contact vocal ou SMS | Oui | Non | Chaîne UTF-8 ; 32 caractères max sur l'hôte ; déclaré par le soumetteur, non vérifié |
| Empreinte | Ancre de clé (recherche, synchronisation) | Oui (pgp_fingerprint) | Oui | 32 octets ; style OpenPGP v4 sur le fil ; pas la même chose qu'une empreinte d'appareil G: |
| Clé publique | Matériel de chiffrement / vérification | Oui (pgp_pubkey) | Oui (région de clés) | Algorithme : Ed25519, X25519, Brainpool P-256/P-384/P-512, NIST P-256/P-384, RSA-2048/3072/4096 ; jusqu'à 768 octets de blob sur puce |
| Clé protégée par PIN | La clé nécessite un déverrouillage par PIN | L'hôte stocke les clés OpenPGP séparément | Oui | Condensat de vérification du PIN + métadonnées d'enveloppement AES-GCM sur puce |
| Dernière récupération | Moment du rafraîchissement du matériel de clé | Oui (fetched_at) | Oui (last_fetched) | UTC sur l'hôte ; horodatage 32 bits sur puce |
| Expire le | Heure d'expiration de la clé | Oui | Non | Date-heure UTC dans SQLite uniquement |
| Source de la clé | Comment l'enregistrement hôte a été créé | Oui (source) | Non | p. ex. manuel, serveur de clés, WKD, LDAP, fichier, pair |
| Provenance du champ | Étiquette de confiance par champ de métadonnées | Non | Oui (source_map) | Deux bits par champ : SelfAttested, HostVerified, RegistrySync, OobVerified |
| Indicateurs d'enregistrement | Actif, obsolète, propre identité, révoqué | Partiellement (logique hôte) | Oui | p. ex. STALE, SELF_KEY sur puce |
fuzz/README.mdtest-all --no-dudect : Saute la suite de synchronisation dudect (~15–20 minutes). La CI des pull requests utilise cet indicateur. Exécutez cargo run -p xtask -- timing-test ou test-all sans --no-dudect pour la porte de synchronisation. La CI hebdomadaire (test-all-full) exécute toujours dudect.docs/TEST_RESULTS.md pour ce qui est dans le périmètre.| Champ de métadonnées | OpenPGP / GnuPG | Clé Galdra (hôte + magasin de contacts) |
|---|
| Contact / id d'enregistrement | Non (utiliser l'ID de clé ou l'empreinte) | Oui (id SQLite sur l'hôte ; pas sur la puce) |
| Nom d'affichage | Uniquement dans le texte User ID (Nom <email>) | Oui (champ UTF-8 séparé) |
| Uniquement dans le texte User ID | Oui (champ séparé ; recherche par e-mail sur la puce) | |
| Adresse postale | Aucun champ standard | Oui |
| Pays | Aucun champ standard | Oui |
| Code postal / ZIP | Aucun champ standard | Oui |
| Région / état | Aucun champ standard | Oui |
| Organisation | Aucun champ standard | Oui |
| Département | Aucun champ standard | Oui |
| Rôle / intitulé de poste | Aucun champ standard | Oui |
| Badge / id employé | Aucun champ standard | Oui |
| Indicatif | Aucun champ standard | Oui (12 octets, complétés par des zéros sur la puce) |
| ID d'abonné DMR | Aucun champ standard | Oui (32 bits ; recherche sur la puce) |
| Affiliation radio | Aucun champ standard | Oui |
| ID Fluxer | Aucun champ standard | Oui |
| ID Discord | Aucun champ standard | Oui |
| ID IRC | Aucun champ standard | Oui |
| Numéro de téléphone | Aucun champ standard | Oui (SQLite hôte uniquement) |
| Note libre | Aucun champ standard | Oui |
| Empreinte OpenPGP v4 | Oui (40 caractères hexadécimaux) | Optionnel sur la ligne hôte lors de la liaison d'un certificat (pgp_fingerprint) ; 32 octets sur la puce pour les clés Galdra |
Empreinte d'appareil G: | Non | Oui (BLAKE3-160 sur la clé publique SIG ; outil hôte ; pas la valeur OpenPGP v4) |
| ID de clé OpenPGP | Oui (forme courte / longue) | Non |
| Confiance / provenance | Signatures WoT sur les User IDs | Étiquettes par champ : SelfAttested, HostVerified, RegistrySync, OobVerified (sur la puce) |
| Expiration de la clé | Oui (certificat / sous-clé) | Hôte uniquement (expires_at dans SQLite) |
| Dernière heure de récupération de clé | Dépend de l'outillage hôte | Oui (fetched_at / last_fetched) |
| Clé privée sur le jeton | Emplacements de carte SIG, DEC, AUT | Région de clé Galdra séparée (pas de paquets User ID) |
| PIN pour utiliser la clé privée | PW1 / PW3 (carte OpenPGP) | Enveloppe PIN optionnelle par enregistrement de contact Galdra |
| Objet de carte OpenPGP (pas dans le tableau ci-dessus) | Hôte (GnuPG) | Sur le jeton |
|---|
| Sous-clés primaire + SIG / DEC / AUT | Publiques dans le trousseau | Privées dans des emplacements scellés |
| Signatures de certification (WoT) | Oui | Non |
| Certificat de révocation | Oui | Non |
| Attributs d'algorithme (DO 0xC1 / 0xC2 / 0xC3) | gpg --card-edit | Oui |
galdragaldra-core-host| Portée | Norme / document typique | Exposé comme carte OpenPGP standard + GnuPG ? |
|---|
| Application de carte OpenPGP — APDU, PIN, emplacements SIG/DEC/AUT, génération/signature/déchiffrement sur carte | Spécification de carte OpenPGP (voir docs/OPENPGP_CARD.md) | Oui — même pile hôte que les autres cartes à puce OpenPGP (gpg, scdaemon, CCID) |
| USB CCID — communication avec l'appareil en tant que lecteur de carte à puce | Classe de périphérique USB CCID | Oui — pilotes de classe |
| Format de message OpenPGP — fichiers chiffrés, courrier, paquets de clés | RFC 4880 (et mises à jour) | Oui sur l'hôte — GnuPG l'utilise ; la carte ne parse pas le courrier |
| Shamir K-of-N — division / récupération du matériel de clé à long terme dans le coffre | Pas dans la spécification de carte OpenPGP ; pas dans GnuPG | Non — uniquement firmware et outils de provisionnement ; pas une opération gpg --card-edit (voir Shamir et chiffrement de disque complet) |
| Double clé matérielle / autorisation par quorum — deux (ou N) jetons requis avant qu'un consommateur agisse (déverrouillage de disque, libération de porte, opérations privilégiées) | Pas dans la spécification de carte OpenPGP | Non — modèle d'extension pris en charge pour les intégrateurs utilisant Shamir et/ou plusieurs authentifications OpenPGP ; l'application de la politique appartient au système en aval (docs/DUAL_KEY_QUORUM.md) |
| ECDH éphémère authentifié — protocole de session à secret parfait (forward secrecy) sur le jeton | Pas dans la spécification de carte OpenPGP | Non — spécifique au jeton ; pas une commande de carte GnuPG |
| Système de profils de chiffrement — cascades symétriques nommées (empilement de chiffrements indépendants les uns sur les autres ; jusqu'à quatre couches, trois est une profondeur prise en charge) et politique associée | Pas dans la spécification de carte OpenPGP | Non — firmware / outils hôtes de jeton |
| Leurre microSD / personnalités de stockage de masse — comportement USB pour hôte non informé | Pas dans la spécification de carte OpenPGP | Non — chemins de code de personnalité USB séparés |
| WebAuthn / FIDO2 | CTAP / WebAuthn | Non implémenté — norme différente de la carte OpenPGP |
| Couche | Rôle |
|---|
| Disque | Chiffré avec une clé maîtresse (par ex. AES-256 via LUKS, VeraCrypt ou une couche de blocs brute) |
| Clé maîtresse | Divisée avec SSS en N parts, seuil K-of-N |
| Parts | Détenues par des personnes, des appareils ou un stockage hors ligne ; K parts ensemble reconstruisent la clé maîtresse |
| Déverrouillage | Reconstruire la clé, puis la passer à cryptsetup, veracrypt ou votre pile |
| Seuil | 2-sur-3 (petite équipe, une certaine redondance) ; 3-sur-5 (courant dans les organisations) |
| Stockage des parts | Jetons matériels, machines séparées, papier, sites géographiquement répartis |
| Protection des parts | Chiffrer chaque part pour un destinataire spécifique (par ex. avec sa clé OpenPGP) avant distribution |
| Où reconstruire | Machine isolée (air-gapped), politique HSM, ou environnement contrôlé — pas sur des hôtes partagés non fiables |
| Scénario | Pourquoi SSS plus des courbes fortes et alignées sur les politiques importent |
|---|
| Un employé part ou décède | La récupération reste possible sans le secret exclusif de cette personne |
| Accès légal dans le cadre d'une procédure régulière | Un quorum peut être exigé — aucune partie unique ne détient le secret de déverrouillage complet |
| Dépôt de clés d'entreprise | Partage auditable ; aucun administrateur unique n'a un accès complet |
| Saisie de matériel | Les supports peuvent être capturés sans capturer K des N parts |
| Alignement réglementaire (UE / BSI) | Brainpool satisfait de nombreuses exigences cryptographiques des gouvernements allemand et de l'UE |
| Signature Governikus | Confirme que le nom sur le certificat correspondait à l'identité authentifiée par puce lorsque l'utilisateur a complété le flux |
| Juridiction | Statut abordé dans ce document |
|---|
| Allemagne | Flux Governikus/BSI décrit ci-dessus |
| Estonie | eID basée sur puce. Migration de RSA vers NIST P-384 (secp384r1) ECDSA en 2017–2018 après que la vulnérabilité ROCA a forcé l'abandon complet de RSA (la puce ne pouvait pas générer de clés RSA sûres et n'avait aucun chemin vers des tailles de clé plus grandes). La clé privée est liée au matériel et ne peut pas être lue depuis la carte. Aucun service de signature OpenPGP de style Governikus connu trouvé. |
| Belgique | eID basée sur puce. Les cartes plus anciennes utilisaient RSA 1024 bits ; les cartes plus récentes (applet 1.8 et ultérieur) utilisent NIST P-384 ECDSA. Écosystème de middleware open source actif (eid-mw, OpenSC). Aucun service de signature OpenPGP de style Governikus connu trouvé. |
| Norvège | La puce de la carte d'identité nationale (délivrée depuis 2020) est compatible ICAO 9303 et implémente uniquement une puce de document de voyage ; elle ne porte aucune fonction de signature eID. La signature eID est séparée : fournisseurs privés accrédités (Buypass, Commfides) sous SEID, historiquement RSA 2048 bits, passant à RSA 3072 bits avec ECC introduit dans SEID 2.0. Aucun service de signature OpenPGP de style Governikus connu. La puce de voyage et l'eID de signature sont distinctes — pertinent si quelqu'un essaie d'utiliser uniquement la puce de la carte directement. |
| Autriche | Partiellement étudié. eID utilise ECC (confirmé) ; la courbe spécifique n'est pas confirmée dans les sources disponibles. Modèle multi-jetons Bürgerkarte plutôt qu'une carte unique ; largement migré vers une application mobile. Une enquête plus approfondie est nécessaire sur les détails de courbe et tout service de signature OpenPGP. |
| États-Unis | Carte PIV (Personal Identity Verification, FIPS 201 / NIST SP 800-78) : délivrée uniquement aux employés et sous-traitants fédéraux — pas une carte civile universelle. Algorithmes : NIST P-256 obligatoire pour les clés d'authentification ; P-256 ou P-384 pour la signature/gestion de clés ; RSA 2048/3072 également autorisé ; courbes NIST uniquement, pas de Brainpool. La racine de confiance est la Federal Common Policy CA (FCPCAG2), non incluse dans les magasins de confiance commerciaux standard. Aucun service de signature OpenPGP de style Governikus trouvé ; FPKI est une infrastructure X.509 distincte d'OpenPGP. PIV étant réservé au fédéral signifie qu'il ne s'agit pas d'une ancre de confiance civile comme l'eID allemande. |
| Canada | Aucune carte d'identité nationale basée sur puce avec clés de signature sur puce. L'identité numérique est fragmentée entre les régimes provinciaux (par exemple BC Services Card), les applications mobiles (par exemple eID-Me), et un cadre fédéral évolutif d'identifiants numériques. Aucune carte unique comparable au modèle allemand, estonien ou belge. Aucune infrastructure de carte équivalente trouvée — pas une ancre de confiance viable en ce sens. |
| Autres pays | Non étudié |
| Objectif | Où commencer |
|---|
| Aperçu du projet, actualités, communauté | sequoia-pgp.org |
| Contribuer (problèmes, correctifs, fonctionnalités, documentation) ; contacter avant un travail important | Contribute, Contact |
Docs développeur — surface API pour étendre l'implémentation (sequoia-openpgp et crates connexes) | Docs — par ex. sequoia-openpgp sur docs.rs |
| Source et suiveurs | gitlab.com/sequoia-pgp (bibliothèque principale et outils) ; github.com/sequoia-pgp (miroirs / dépôts sélectionnés) ; Projects |
| Nouveaux algorithmes dans la norme OpenPGP | Passent toujours par le groupe de travail IETF OpenPGP. Sequoia et d'autres implémentations implémentent les brouillons et RFC ; proposez des changements de protocole là-bas, et coordonnez-vous avec les implémenteurs (y compris Sequoia) pour que le comportement corresponde à la spécification. |
streetcountrypostal_coderegiondmr_idradio_affiliationgaldra contact showPATCHDELETEGET /contacts/{id}galdradrecipientPOST /decryptgaldra keyserver pushorganisationrolenotebadge_numberphone_numbergaldra keyserver push --help