supermagnum/galdralag-firmwareUne tentative de cadre 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 concèdent sous licence croisée 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 matériel pour les tests. https://www.crowdsupply.com/baochip/dabao/updates/our-campaign-has-launched
Firmware pour les appareils Baochip-1x (carte d'évaluation Dabao) exécutant le
micro-noyau Xous , construit
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 type 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, OS — est open source et vérifiable.
Les spécifications matérielles, 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) est 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 des destinataires (contacts). Chaque identité stockée comprend le matériel de clé publique ainsi que des étiquettes sidecar facultatives (voir le tableau ci-dessous). Ces étiquettes résident 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 de manière magique aux ID utilisateur OpenPGP à moins que vous ne les aligniez vous-même, et elles ne sont pas attestées cryptographiquement à moins que vous ne les vérifiiez hors bande. Une commande galdra keyserver push facultative peut envoyer des champs qui se chevauchent à un registre de projet sous forme de JSON parallèlement à 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 en ligne de commande : docs/GALDRA-TOOL.md. Disposition filaire et nombres 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 clé dérivée propre ; voir Capacités des clés), des flux liés à Shamir, un ECDH éphémère authentifié là où implémenté, et des outils hôtes Galdra). La cible d'interopérabilité principale est l'utilisation de carte 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 dans Crates Explicitement Exclus dans docs/future-todo.md.
CESS : Ce firmware est conforme à CESS pour les constructions normatives implémentées dans l'arbre (y compris le Mode A AEAD externe, HKDF-BLAKE3 pour K_outer , et le partage Shamir dans GF(2^8) par octet). La déclaration d'alignement complète, 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 répertoire xous-core), construit avec la fonctionnalité ccid-openpgp , utilisant crates/baochip-openpgp pour la fenêtre RRAM OpenPGP et le provisionnement. Disposition : docs/RRAM_LAYOUT.md. Lacunes pré-production (UX du code PIN de l'opérateur, validation de la carte de plateforme) : Limites connues / travaux en cours.
L'objectif global reste un firmware de jeton de sécurité matériel complet, testé et open source : comportement de type 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 le standard de carte OpenPGP — ECDH éphémère avec secret parfait, Shamir K-of-N, profils agnostiques aux chiffrements, 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.
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 de signature détachée OpenPGP habituel, adapté à ce que votre build émet). La ROM boot0 immuable 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 méfiance mutuelle entre les clés de signature Baochip et tierces. Le flux d'amorçage complet, la livraison UF2, la console, les mises à jour boot1 et le modèle de sécurité : Démarrer avec les cibles Baochip dans xous-core.
Tous les tests ne s'exécutent pas dans chaque commande ; c'est intentionnel.
xtask pas dans le test de l'espace de travail par défaut : La recette courante est cargo test --workspace --exclude xtask car xtask est une crate d'orchestration de build. Exécutez cargo test -p xtask lorsque vous voulez ses tests.#[ignore] : Ceux-ci sont ignorés sauf si vous passez --ignored (et tous les filtres de crate nécessaires). Les raisons incluent : une couverture déjà exercée dans des tests unitaires ciblés (par exemple, mise à zéro après suppression), des cas lents (par exemple, génération de clé RSA) et des flux dépendants du matériel ou du jeton dans les outils hôtes comme galdra qui nécessitent un appareil connecté ou des supports de test.test-all --no-fuzz : Saute l'étape cargo-fuzz pour garder les 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 invoquez les cibles de fuzz séparément (voir ).On peut également 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 les tests par des humains, sur du matériel réel — aucune version prête pour la production n'existe. Il est écrit en Rust utilisant des crates cryptographiques validées et auditées. Les primitives cryptographiques sont tirées exclusivement des dépendances auditées de l'espace de travail. Les algorithmes post-quantiques sont masqués par des fonctionnalités et marqués EN ATTENTE D'AUDIT INDÉPENDANT. Voir Statut post-quantique.
Remarque : Des parties de ce projet ont été développées avec l'aide 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 un expert est fortement recommandé avant tout déploiement en production.
Il est prêt pour les tests par des humains. Vous décidez si vous construisez ou exécutez un de ces logiciels ; il peut y avoir des bogues que les tests unitaires, le fuzzing et 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 sont 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 a une condition neurologique liée à la dyscalculie. La dyscalculie affecte le sens des nombres et le traitement symbolique connexe d'une manière qui, pour lui, rend la programmation traditionnelle — l'édition manuelle du code comme seul flux de travail — non praticable sans un outillage assisté (par exemple des éditeurs conversationnels basés sur l'IA). Cette contrainte est distincte de l'exactitude : les examinateurs devraient 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 une connaissance du domaine qui ne peut pas être remplacée par la seule narration.
Ce n'est pas une raison pour cacher le 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 la preuve concrète.
Que regarder : Le matériel de conformité comprend les exemples travaillés de la RFC 8439 pour ChaCha20-Poly1305 dans crates/vault/tests/rfc_vectors/, les fichiers JSON Wycheproof vendus pour ChaCha20-Poly1305 et les cas limites ECDH/ECDSA Brainpool dans crates/vault/tests/data/wycheproof/, les vecteurs BSI TR-03111 pour BrainpoolP256r1 et P384r1 dans crates/vault/tests/bsi_vectors/, les vecteurs de référence officiels BLAKE3 (toutes les 35 longueurs d'entrée, les trois modes) dans crates/vault/tests/blake3_vectors.json, les vecteurs de spécification Twofish (1203 cas incluant Monte Carlo) dans crates/vault/tests/twofish_vectors.json, et le propre fixture KAT de cascade CESS du projet avec des intermédiaires vérifiés indépendamment dans crates/cipher-profile/tests/fixtures/cascade_cess_kat.json. Ensemble, ce sont la vérité de base que l'exécuteur et les examinateurs peuvent exercer avec cargo test --workspace et python3 scripts/verify_cascade_kats.py.RFC 8439 est publié par l'Internet Engineering Task Force (IETF), l'organisation qui standardise une grande partie de l'interopérabilité sur Internet. Les RFC (Request for Comments) sont la forme habituelle pour les protocoles et de nombreuses spécifications cryptographiques. La RFC 8439 définit le chiffrement authentifié ChaCha20-Poly1305 (basé sur les conceptions de Daniel Bernstein) et inclut des exemples concrets avec des entrées spécifiques et des sorties attendues afin que les implémentations indépendantes puissent vérifier qu'elles correspondent octet par octet à la norme. Le texte en clair largement reproduit commençant par apparaît dans les exemples en annexe de la RFC : si votre code reproduit exactement la sortie AEAD, vous avez une vérification solide que vous avez implémenté correctement la construction. C'est l'analogue cryptographique d'un corrigé officiel. ChaCha20-Poly1305 constitue la couche interne de chaque profil de cascade multicouche de ce firmware, donc cette vérification se trouve à la base de l'ensemble de la pile de chiffrement.
Wycheproof est un corpus de test 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 — car le projet se concentre sur l'élimination des obstacles petits mais fatals : débordements d'entiers, cas limites, entrées malformées et étiquettes d'authentification trafiquées ; des défaillances qui apparaissent régulièrement dans la cryptographie réelle déployée. Il complète les vecteurs de type RFC : les exemples de style RFC 8439 démontrent l'exactitude par rapport à l'AEAD publié ; Wycheproof teste la robustesse là où les implémentations échouent historiquement. Dans ce dépôt, les fichiers JSON Wycheproof couvrent ChaCha20-Poly1305, AES-GCM, HMAC, HKDF, X25519, Ed25519, RSA et les variantes Brainpool ECDH/ECDSA.
BSI TR-03111 est la directive technique pour la cryptographie à courbe elliptique publiée par l'Office fédéral allemand de la sécurité des technologies 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 est couverte pour ECDH et ECDSA ; les signatures ECDSA ont été en outre recoupées avec une implémentation Python indépendante utilisant la bibliothèque cryptography.
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, choisies spécifiquement pour exercer toutes les conditions limites internes de découpage en morceaux et de construction arborescente qui sont invisibles pour les tests sur des entrées courtes. Les trois modes de 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-dessus 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 des crates RustCrypto auditées — aucune cryptographie n'est implémentée dans l'arborescence. Étant donné que 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 deuxième chemin indépendant : une implémentation Python vérifie les mêmes valeurs intermédiaires dans le fixture KAT de la cascade, de sorte qu'une chaîne d'outils Rust compromise produisant des résultats erronés soit également détectée par le recoupement. Il s'agit d'une garantie d'intégrité de la chaîne d'approvisionnement nettement plus solide que de se lier à une bibliothèque C, où la vérification équivalente de chaque opération interne nécessite beaucoup plus d'efforts et d'outils spécialisés.
Il appartient maintenant 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 un mode crypto ou un 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 tout 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 non protégées sur votre ordinateur. En mode camouflage, il peut s'énumérer comme un stockage amovible ordinaire avec des fichiers anodins, de sorte 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 du projet GNU d'OpenPGP, le standard ouvert pour la gestion de clés et les messages cryptographiquement protégés (la même famille conceptuelle que PGP, mais spécifié dans des documents tels que RFC 4880 et les mises à jour de la communauté). Vous l'exécutez normalement en tant que commande gpg sous Linux, BSD, macOS ou Windows ; de nombreux utilitaires graphiques de courrier et de clés l'encapsulent en dessous.
Les gens utilisent GnuPG pour :
gpg-agent expose les clés d'authentification d'une carte à puce ou d'un magasin de clés local.GnuPG et les disques chiffrés (LUKS). Linux dispose d'un moyen intégré de chiffrer un disque ou une partition entier, appelé LUKS. Une fois un disque chiffré, il ressemble à un bruit insignifiant pour quiconque n'a pas la clé, de sorte qu'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 seulement tant que le jeton est branché et que vous avez saisi votre code PIN. Retirez le jeton, et le disque ne peut pas être ouvert du tout, même sur le même ordinateur.
En bref, cela transforme le jeton en une clé physique pour votre disque chiffré. Sa mise en place (et l'ajout d'un moyen de secours, au cas où le jeton serait perdu) se fait avec les outils de disque de Linux ; le jeton ne fait que détenir la clé. Si vous préférez partager la possibilité de déverrouiller un disque entre plusieurs personnes, de sorte qu'aucune personne seule ne puisse le faire, voir Partage secret de Shamir et chiffrement de disque.
Par défaut, GnuPG stocke les clés dans ~/.gnupg. Avec une carte à puce OpenPGP, les clés privées sensibles vivent sur la carte ; scdaemon (partie de la suite GnuPG) parle CCID/USB à la carte tandis que gpg assemble toujours les paquets OpenPGP sur l'hôte.
À quoi ça sert. En mode crypto, le jeton est destiné au même travail que les autres cartes à puce OpenPGP : signer et déchiffrer les courriels et fichiers, 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 ne détienne l'intégralité du secret (décrit plus loin). GnuPG est la principale cible d'interopérabilité sur l'hôte : ce firmware implémente l'application carte OpenPGP via CCID, que scdaemon pilote (gpg --card-status, gpg --card-edit, et les opérations normales de chiffrement/signature/déchiffrement 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 NFC sera activé sur le matériel (intégration prévue — pas encore dans le firmware), la même classe de périphérique peut prendre en charge l'accès physique : le fait de tapoter 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 code 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 différencie des autres jetons que vous avez peut-être rencontrés.
Camouflage de stockage. Le périphérique peut agir comme un stockage amovible ordinaire afin que son véritable rôle ne soit pas évident lors d'un rapide coup d'œil. Lorsque vous le branchez sur un ordinateur typique, il peut apparaître comme un lecteur USB normal ou un volume basé sur 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 une inspection superficielle à un bureau ou à un point de contrôle. Déterminer qu'il s'agit en fait d'un jeton de sécurité nécessite généralement de démonter le boîtier, pas simplement de le brancher.
Vos clés restent sur le périphérique. Lorsque vous signez un courriel 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'échange de clés. Celui-ci génère une nouvelle paire de clés jetable pour chaque session, la signe avec la clé à long terme pour prouver qu'elle est authentique, puis utilise la paire jetable pour l'échange réel. Si quelqu'un vole le jeton dans des années et parvient d'une manière ou d'une autre à extraire la clé à long terme, il ne pourra toujours pas déchiffrer quoi que ce soit des sessions passées. Cette propriété est appelée secret parfait, 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 de sorte que K de ces parts soient nécessaires pour la reconstruire — mais aucun détenteur individuel ne peut rien faire seul. C'est ce qu'on appelle le partage secret de Shamir. Cela est utile pour les clés organisationnelles où aucune personne 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 percée future 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 en fonction du degré de prudence requis par votre situation.
Ma recommandation personnelle est BrainpoolP256r1 + ChaCha20-Poly1305 + BLAKE3. C'est le profil standard intégré. Il utilise la courbe P-256 Brainpool du BSI pour l'échange de clés éphémères, ChaCha20-Poly1305 pour le chiffrement symétrique, et BLAKE3 pour la dérivation de clés et l'intégrité inter-couches. C'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 RFC 3713 et ISO/IEC 18033-3.
Un mauvais code PIN vous verrouille correctement. Le jeton compte les tentatives de code PIN infructueuses avant de vérifier si le code PIN est correct, et non après. Cela signifie qu'un crash ou une perte de courant en cours de tentative ne peut pas être exploité pour réinitialiser le compteur. Après trop de mauvaises tentatives, le jeton efface le matériel sensible.
Ce qu'il ne fait pas encore. Aucun matériel n'est encore disponible — il s'agit d'un firmware en développement actif. Les tests de bout en bout avec du matériel USB réel 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 des comportements livrés. 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 matériel réel ne peuvent être effectués tant qu'un dispositif n'existe pas.
Galdralag peut fonctionner avec deux types différents de clés asymétriques en même temps. Elles répondent à des questions différentes sur le périphérique 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 comment elles diffèrent en termes quotidiens.
Une clé OpenPGP, au sens où GnuPG génère et utilise, est un paquet structuré, pas un simple numéro public nu. Elle regroupe la clé primaire, les sous-clés pour la signature et le chiffrement, et un ou plusieurs identifiants utilisateur — généralement un nom d'affichage et une adresse électronique comme Alice Example <[email protected]>. D'autres personnes peuvent signer ces identifiants utilisateur 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 plus loin dans Toile de confiance et fêtes de signature de clés. Lorsque Galdralag agit comme une carte à puce OpenPGP, il conserve le matériel de clé privée sur la puce et effectue la signature et le déchiffrement là-bas. La clé publique, les identifiants utilisateur 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 paire de clés asymétriques nue — Ed25519, X25519 ou l'une des courbes Brainpool ou NIST prises en charge par le firmware. Les octets de la clé eux-mêmes ne portent aucune revendication d'identité : pas de paquets d'identifiant utilisateur, pas de courriel 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é dans la base de données SQLite de l'hôte et dans le 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 normal et d'un identifiant utilisateur (plus les lignes de contact optionnelles côté hôte 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étails complets 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 met le nom et l'e-mail dans une seule chaîne User ID ; il ne fournit pas de champs séparés lisibles par machine pour l'indicatif, DMR ou les adresses postales. Galdra conserve ceux-ci 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 à jour 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 se trouve dans CHANGELOG.md.
| PW1 / PW3 | Jamais stocké | Vérificateur sur la puce (min 5 caractères, 3 tentatives par défaut) |
| DO du titulaire (login, langue, URL, …) | Mis en cache par GnuPG | Optionnel (254 octets max par DO) |
Application carte 3.4.1, CCID et workflows GnuPG : docs/OPENPGP_CARD.md et Compatibilité OpenPGP et GnuPG.
La séparation existe parce que les informations d'identité qui importent dans les communautés ciblées par Galdralag — indicatif, ID DMR, affiliation au réseau radio — n'ont pas de place naturelle dans un User ID OpenPGP. Un User ID est destiné au nom et à l'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 magasin sur la puce comprennent nativement.
En pratique, un seul périphérique peut détenir les deux types de clés sans conflit. L'application carte OpenPGP sert GnuPG via les emplacements standard SIG, DEC et AUT. Le magasin de contacts conserve les clés Galdra pour le travail opérationnel — par exemple chiffrer pour un contact radio par indicatif, vérifier un message par rapport à un ID abonné DMR, ou rechercher un collègue par numéro de badge. Les deux chemins ne se marchent pas sur les pieds.Si quelqu'un possède un certificat OpenPGP géré par GnuPG sur l'hôte et une clé Galdra dans le store 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 le périphérique 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 garantit automatiquement les étiquettes qui l'entourent. Un ID utilisateur OpenPGP est auto-déclaré jusqu'à ce que quelqu'un d'autre le signe. Un indicatif ou un champ 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é.
Une grande partie des bugs liés à la sécurité dans les bases de code industrielles proviennent de l'insécurité mémoire (dépassements de tampon, use-after-free, déréférencements null, etc.). Le MSRC de Microsoft a rapporté à plusieurs reprises qu'environ 70% des CVE traitées 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 pour la mémoire sont importants.
En Rust safe (le mode par défaut), le borrow checker élimine les data races et les erreurs mémoire habituelles de comportement indéfini à la compilation sans recourir au ramasse-miettes. Unsafe Rust et les FFI vers C peuvent encore introduire des bugs mémoire ; ils doivent être réduits au minimum et révisés.
Les vérifications de bornes de Rust sur les slices et ses règles de possession réduisent plusieurs classes de modes de défaillance courants dans le code embarqué C/C++ :
unsafe doivent être explicites ; les MMIO et les pointeurs bruts pour les registres y résident, afin que les réviseurs puissent grep la surface d'audit (unsafe ne rend pas les MMIO incorrects impossibles, seulement plus faciles à localiser).Rust n'empêche pas par lui-même les bugs logiques comme une boucle serrée qui use la flash, ou le choix de mauvaises valeurs de registre. Ceux-ci restent des préoccupations d'ingénierie et de révision.
Ce codebase applique des motifs Rust courants pour les secrets ; ils ne sont pas automatiques pour chaque type :
zeroize::Zeroize / ZeroizeOnDrop effacent les tampons au drop ; les appelants doivent y adhérer.subtle::ConstantTimeEq (et similaires) là où le timing est important — le == 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épendance cryptographique).catch_unwind ou abort là où votre plateforme exige des garanties plus fortes.unsafe doit être explicitement mentionné dans le source, ce qui réduit la portée de la révision manuelle. Dépendances : la politique cryptographique de ce projet favorise les crates Rust auditées (RustCrypto et d'autres) ; voir le tableau dans Politique de dépendance cryptographique — toutes les dépendances ne proviennent pas d'un seul projet parapluie.
Rust n'élimine pas les deadlocks (par exemple des verrous Mutex mal ordonnés), les bugs logiques, les protocoles incorrects, l'usure de la flash due à des boucles défectueuses, les attaques physiques (glitching, analyse de puissance), ou les risques liés à une construction correcte de la mauvaise image. Il ne garantit pas non plus une exécution à temps constant sur tout matériel sans un codage soigneux. Ces domaines reposent sur la conception, la révision, les tests et les pratiques de cryptographie 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 bancs 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. Le fait que les tests réussissent ne prouve pas la préparation à la production ou 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 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 supporté.
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
Dans la VM, les instructions de construction standard s'appliquent. La VM peut être **instantanée** avant chaque expérience et **restaurée** proprement si quelque chose se passe 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 si vous choisissez d'attendre un audit tiers indépendant avant le déploiement. Ce projet vise à vous donner toutes les informations nécessaires pour prendre cette décision par 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/HEAD/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, pas seulement les mots. Parfois aussi utilisé pour activer des inscriptions runiques magiques, comme sur la [hampe de lance 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 du vieux Futhark.
**Galdralag** est la forme métrique utilisée pour le galdr : un vers structuré, précis, lié par des règles où le motif fait partie de la force du sort. Le suffixe *lag* est apparenté à « loi » ou « motif ».
**Les runes** étaient littéralement une connaissance secrète et encodée — l'usage chamanique n'était connu que de ceux qui comprenaient.
---
## Documentation
**Glossaire :** [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md) — termes expliqués en **langage simple** (triés A–Z). Commencez ici si le README ou d'autres docs semblent pleins de jargon.
**Débogage :** [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/DEBUG_INSTRUCTIONS.md) — backtraces, réduction de `cargo test`, raccourcis `xtask`, triple vérification du firmware, fuzzing, et quoi collecter avant de signaler un problème.
**Assistants IA (Claude, Cursor) :** [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/CLAUDE.md) — instructions du projet pour les agents de codage. Règles spécifiques à Cursor : [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/.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 connexe) :** Deux arbres KiCad : [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-files-usb/) — `dabao_v3c` (jeton USB **sans** micro-SD) ; et [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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/HEAD/Hardware/kicad-sd-card/docs/pinout/README.md). La disposition du PCB du dongle USB (jeton minimal vs évaluation format Pico) est décrite dans [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md).
| Document | Description |
|----------|-------------|
| [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-files-usb/) | **Projet KiCad** de 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/HEAD/docs/USB_DONGLE_PCB.md) |
| [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/) | **Projet KiCad** de dongle USB `dabao_v3c_sdcard` (support micro-SD) ; gerbers, BOM, brochage sous [docs/pinout](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/docs/pinout/README.md) ; complète [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) |
| [docs/CODE_MAP.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CODE_MAP.md) | **Index des fonctions et modules** de l'espace de travail (`pub fn` par fichier / types avec ancres de ligne) |
| [docs/CRATE_DEPENDENCIES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CRATE_DEPENDENCIES.md) | **Crêtes Rust amont vs projet** et comment elles dépendent les unes des autres |
| [docs/API_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/API_REFERENCE.md) | Code map + **annexe** pour IETF/I-D/GnuPG/Sequoia : construction de Shamir GF(256), armure GALDRA SHARE, format filaire ECDH éphémère, étiquettes HKDF, préimages ; routes `galdrad` ; indications rustdoc |
| [docs/ARCHITECTURE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/ARCHITECTURE.md) | Architecture haut niveau du firmware et sous-systèmes majeurs |
| [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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/HEAD/docs/BIOMETRIC_API.md) | Pré-porte biométrique : architecture, format filaire, disposition du coffre ; intégration partiellement implémentée |
| [docs/BIOMETRIC_DEVICE_GUIDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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/HEAD/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/HEAD/docs/FINGERVEIN_DEVICE.md) | Appareil ouvert de veine digitale ESP32-CAM : matériel, ébauche de protocole, vivacité |
| [docs/SWEET_PLATFORM_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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/HEAD/docs/GALDRA-TOOL.md) | Outils hôtes (`galdra`, `galdrad`, `galdra-gtk`) : workflows, 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-et-key-signing-parties). Des notes de conception supplémentaires restent dans [docs/server.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/server.md). |
| [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md) | **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/HEAD/CLAUDE.md) | Instructions pour **Claude** / agents de codage IA ; pointe vers [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/.cursor/rules/) pour **Cursor** |
| [docs/GALDRALAG_DEV_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRALAG_DEV_REFERENCE.md) | Chaîne d'outils, commandes `xtask`, points d'entrée pour le fuzzing et les tests cryptographiques |
| [docs/dev-ref.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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/HEAD/docs/DEBUG_INSTRUCTIONS.md) | Débogage : `RUST_BACKTRACE`, builds verbeux, tests ciblés, recettes `xtask`, vérifications des cibles embarquées, pointeurs de fuzzing, vérifications hôte OpenPGP |
| [docs/KEY_LIFECYCLE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/KEY_LIFECYCLE.md) | Génération de clés, politique d'import/export, rotation, zéroïsation, Shamir (tel que reflété dans `vault` / OpenPGP) |
| [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md) | Application de carte OpenPGP, configuration hôte GnuPG/CCID, emplacements de clés, algorithmes, udev |
| [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CIPHER_PROFILES.md) | Système et configuration des profils de chiffrement |
| [docs/CIPHER_PROFILE_SECURITY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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 caractère générique |
| [docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CESS_CONFORMANCE.md) | Alignement [CESS](https://github.com/Supermagnum/CESS/tree/main) : disposition filaire 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/HEAD/crates/cess) | Mode A CESS : HKDF-BLAKE3 (`derive_k_outer`, `hkdf_blake3`), scellement/ouverture externe ChaCha, disposition `suite_id \|\| inner_blob` ; voir [CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CESS_CONFORMANCE.md) |
| [docs/EPHEMERAL_SESSION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/EPHEMERAL_SESSION.md) | 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 parts basé sur mot de passe, et échange de clé hybride post-quantique optionnel ; séparé 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/HEAD/docs/PQ_SIGNATURES.md) | Signatures avec état post-quantiques (XMSS, LMS/HSS), activation de fonctionnalités |
| [docs/Psram.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/Psram.md) | Volume leurre microSD optionnel et comportement associé |
| [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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éroïsation |
| [docs/TEST_RESULTS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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/HEAD/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/HEAD/docs/THREE_FACTOR_AUTH.md) | Jeton + PIN + biométrique optionnel : ce que ce dépôt implémente vs placeholder ; ébauche de menace |
| [docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/THREAT_MODEL.md) | Modèle de menace : actifs, menaces T1–T14, ce qui est défendu et ce qui ne l'est pas, é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/HEAD/docs/PERFORMANCE.md) | Notes sur les performances |
| [docs/HARDWARE_BRINGUP_TEST_PLAN.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_BRINGUP_TEST_PLAN.md) | Mise en service du premier matériel Q2 : énumération CCID, `gpg --card-status`, USB CDC `galdralag-provision` pour les PIN de premier démarrage, puis `gpg --card-edit` / tests de fumée cryptographiques |
| [docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_VERIFICATION.md) | Zéroïsation matérielle : simulation vs vérification sur silicium |
| [docs/HARDWARE_TEST.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_TEST.md) | Notes de test orientées matériel |
| [docs/NFC_PN532_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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/HEAD/docs/SDMMC_STORAGE_INTEGRATION.md) | `embedded-sdmmc` + SPI microSD comme stockage en vrac optionnel ; alternative BOM au PSRAM |
| [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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 supprime le connecteur 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 de carte OpenPGP** (documentée comme version **3.4.1** dans [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md)). C'est la même classe de périphérique que GnuPG utilise pour les **cartes à puce OpenPGP** sur **CCID/USB** : l'hôte a besoin d'une pile de carte à puce normale (`pcscd`, pilotes `ccid`, `scdaemon` de GnuPG). **Aucun pilote cryptographique côté 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 que le périphérique est visible comme lecteur CCID) :**
| Domaine | Notes |
|--------|--------|
| **Workflows GnuPG** | `gpg --card-status`, `gpg --card-edit`, chiffrer/déchiffrer et signer en utilisant les clés sur la carte |
| **SSH** | `gpg-agent` avec `enable-ssh-support` et la configuration habituelle `SSH_AUTH_SOCK` |
| **Courrier et fichiers** | Clients qui utilisent GnuPG (ex. Thunderbird, Evolution, Kleopatra) et chiffrement de fichiers standard `gpg` |
| **Autres outils** | Tout ce qui parle à une carte OpenPGP + CCID de la même manière que GnuPG |
**Emplacements de clés (par défaut typiques) :** **SIG** (signature), **DEC** (déchiffrement / ECDH), **AUT** (authentification, ex. SSH). Les algorithmes sont sélectionnables par emplacement (courbes Brainpool, NIST P-256/P-384, Ed25519 / X25519, RSA). Le tableau complet et le comportement de `key-attr` se trouvent dans [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md).
**Non couvert par la carte OpenPGP / GnuPG ici :** **WebAuthn / FIDO2** est un protocole différent et hors du champ de cette application de 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** utilise cela via `scdaemon`. Le **format de message OpenPGP** pour les fichiers et les courriels (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 **split de Shamir**, les **sessions ECDH éphémères**, ou les **profils de chiffrement** — ceux-ci sont [spécifiques au firmware](#standards-vs-firmware-specific-features).
**Statut d'intégration :** La logique OpenPGP et CCID réside dans **`usb-personality`**, **`baochip-openpgp`**, et le service **Xous** **`usb-bao1x`** (voir **xous-core**). Le **`galdralag-service`** optionnel (`services/galdralag`) s'exécute comme un processus Xous séparé, se connecte à **`usb-bao1x`** pour l'IPC **CCID**, et ponte les données de provisionnement **PDDB** dans la **RRAM** ; construction et enregistrement **`baosec`** : [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/services/galdralag/README.md) et **`cargo run -p xtask -- build-and-register`**. Disposition mémoire : [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/RRAM_LAYOUT.md). **Le GnuPG de bout en bout sur matériel réel** nécessite encore une image Xous complète (avec **`ccid-openpgp`**), une pile CCID hôte fonctionnelle (`pcscd`, pilote), et les éléments sous [Limitations connues / travaux en cours](#known-limitations--open-work) traités là où ils s'appliquent à votre cible de livraison.
## Session du jeton et exportation de clés
**Déconnexion physique (débranchement) :** L'hôte perd le périphérique USB ; toute opération en cours échoue jusqu'à ce que le jeton soit reconnecté et ré-énuméré. Sur le périphérique, la **session de carte** OpenPGP est effacée : **l'état de vérification du PIN** ne survit pas à la mise hors tension ou au retrait, donc **la signature, le déchiffrement et 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 un stockage de coffre scellé ; le débranchement ne l'efface pas à moins qu'un chemin de **zéroïsation** ou d'effacement séparé ne s'exécute.
**Ce qui peut quitter le périphérique :** 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 connexes que la spécification de la carte expose à l'hôte). Les clés **privées**, les scalaires secrets bruts et les blobs de clé scellés **ne** quittent **pas** le périphérique 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 clair déchiffré pour les workflows de déchiffrement assisté par carte) là où les commandes standard l'exigent, pas une copie portable de la clé privée.
**Importation de clés sur le périphérique :** 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 vérification sur l'appareil). Le **coffre** du firmware fournit des **emplacements de clés publiques** pour le matériel non secret (`crates/vault/src/public_key_vault.rs`). Les outils hôtes pour charger ces emplacements sont décrits dans [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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 de confiance** — 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ù des attestations basées sur puce comme [eID allemande et Governikus](#german-eid-and-governikus-as-a-trust-anchor-for-public-keys) 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 workflows de vérification en personne, **Galdra** peut afficher une empreinte **liée à l'appareil** 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 est **uniquement** disponible lorsque le **profil de chiffrement** actif a **`ephemeral_ecdh: false`** ; les profils intégrés ont par défaut **`ephemeral_ecdh: true`**, donc vous ajoutez généralement un profil utilisateur avec **`galdra profile add ... --no-ephemeral-ecdh`** pour les workflows 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/HEAD/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/HEAD/docs/KEY_LIFECYCLE.md#galdralag-fingerprint-host).
### Obtenir votre empreinte Galdralag
L'hôte affiche 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/HEAD/docs/GALDRA-TOOL.md)** sur l'hôte et assurez-vous que **PC/SC** fonctionne (**`pcscd`**, **`libpcsclite`**) afin que l'outil puisse parler CCID au jeton (voir [Compiler et installer les outils hôtes](#compile-and-install-host-tools-galdra-galdrad-galdra-gtk)).
2. Connectez le jeton (déverrouillez-le si votre workflow 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>
Machine-readable output: galdra --emit json identity fingerprint (optionally --profile <name>).
Les implémentations conformes à OpenPGP incluent un schéma de vérification des certificats pour aider à vérifier la propriété des clés ; son fonctionnement est appelé une toile de confiance. Les certificats OpenPGP (une ou plusieurs clés publiques plus le matériel propriétaire/ID 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 la machine, ou portée sur un jeton compatible OpenPGP).Une cérémonie de signature de clés est une réunion en personne où les participants échangent des empreintes de clés et vérifient l'identité de chacun avant de signer les certificats plus tard.
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 en fonction de la profondeur de la confiance et de la politique.
Pourquoi ces événements sont importants :
Les cérémonies évitent généralement les ordinateurs pendant l'échange d'identité, afin que les attaquants aient moins de chances d'introduire des clés substituées ou des logiciels malveillants sur des machines partagées.
Avant l'événement. Calculez et enregistrez votre empreinte (un condensé dérivé d'un hachage de la clé publique — suffisamment court pour être comparé de manière fiable). Ne pas compter sur l'échange de clés complètes sur papier à ce stade, sauf si vos organisateurs précisent le contraire.```bash
gpg --fingerprint YOUR_KEY_ID
Apportez l’empreinte sur papier ou 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 identifications 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 les **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 **publiez** les signatures pour 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 qu’à la confiance en des machines arbitraires pendant l’événement.
- **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** publiques OpenPGP (ainsi que les mises à jour telles que signatures et révocations). Ils rendent les clés découvrables par **User ID**, **key ID** ou **empreinte** et soutiennent la distribution à large échelle pour la toile de confiance.
Leur comportement en principe :
- **Réplication distribuée.** L’envoi 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 envoyées.
**Confidentialité.** Les clés publiées exposent les **User IDs** (incluant souvent des adresses mail). Traitez les envois comme **publics et durables** sur de nombreux serveurs ; envoyez les **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 de relations entre serveurs apparaissent sur [spider.pgpkeys.eu/graphs/](https://spider.pgpkeys.eu/graphs/) ; des listes de pairs orientés 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 | Notes |
|---|---|
| keys.openpgp.org | Largement utilisé ; vérification orientée consentement pour les identifiants utilisateur liés à un e-mail |
| pgp.mit.edu | Serveur hébergé par MIT, historiquement lié aux maillages de l'ère SKS |
| pool.sks-keyservers.net | Nom d'hôte de pool legacy associé à l'ancien écosystème SKS ; la connectivité varie aujourd'hui |
gpg --refresh-keys périodiquement pour que les révocations et les nouvelles signatures se propagent localement.ephemeral_ecdh: false avec galdra profile show <name>.Pour un comportement faisant autorité de gpg, des modèles de confiance et des options de distribution, consultez le manuel GnuPG et la documentation en amont.
Le projet Fulla (Supermagnum/Fulla sur GitHub) héberge le travail du serveur de registre aligné sur le WoT : implémentation et spécification évolutive pour stocker les clés publiques des contributeurs ainsi que des étiquettes radio-amateur optionnelles, indications postales, organisation (orthographe JSON), role, note, badge_number, phone_number, et colonnes connexes alignées avec les métadonnées de contact Galdra. galdra keyserver push soumet du JSON POST /api/v1/keys (incluant armored_public_key, email, et ces champs optionnels lorsque vous passez des drapeaux CLI) ; galdra keyserver fetch et la strophe de configuration [keyserver] sont implémentés dans / dans cette direction. ; un service géré publiquement est attendu dans le futur. Un texte de conception historique supplémentaire se trouve dans .
Différentes parties de ce projet s'alignent sur différentes normes. L'interopérabilité avec GnuPG est limitée à 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 accessibles via les workflows standards de carte gpg.
Pour le comportement carte quotidien, référez-vous à docs/OPENPGP_CARD.md. Pour les fonctionnalités uniquement dans le coffre ou propres 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.
Motif (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 clé, et fournissez-le à cryptsetup (consultez la documentation de votre distribution ; une mauvaise manipulation des clés peut bloquer l'accès).
Exemple de forme utilisant les utilitaires ssss ("Shamir's Secret Sharing Scheme") (les noms et les paquets 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. Même motif **K-of-N sur un secret maître** que LUKS, appliqué à un moteur de secrets plutôt qu'à un périphérique bloc.
**3. Galdralag firmware (`vsss-rs`)**
Ce dépôt utilise [`vsss-rs`](https://crates.io/crates/vsss-rs) (écosystème RustCrypto) pour le Shamir sur appareil. La même **superposition** s'applique si vous l'alignez avec le chiffrement en masse :
- Générer une clé maîtresse aléatoire de 256 bits (ou appropriée).
- Chiffrer le disque ou le stockage en masse avec **AES-GCM** ou **ChaCha20-Poly1305** en utilisant cette clé (cela correspond aux crate symétriques audités de l'espace de travail).
- Utiliser `vsss-rs` pour diviser la clé maîtresse en **N** parts avec un seuil **K**.
- Stocker les parts dans des emplacements de coffre, d'autres appareils, ou chez des détenteurs de clés.
- Au démarrage ou lors de la récupération, collecter **K** parts, reconstruire, puis utiliser **HKDF** (ou votre politique) pour des sous-clés séparées par domaine si nécessaire.
**4. VeraCrypt**
VeraCrypt n'implémente pas le SSS en interne. Le même motif **externe** s'applique : diviser la **phrase de passe ou le matériel de fichier de clé** avec un outil SSS ; n'essayez pas de diviser Shamir le texte chiffré du volume.
### Motif hybride (grandes données)
Le SSS est destiné aux **petits secrets** (taille de clé). Vous **n'appliquez pas** Shamir à un texte chiffré de plusieurs gigaoctets. La superposition 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 assemble déjà : aes-gcm / chacha20poly1305 pour les données au repos, vsss-rs pour fractionner le secret maître, hkdf pour la dérivation après reconstruction.
| Décision | Options typiques |
|---|
La manipulation opérationnelle des clés pour LUKS et le chiffrement intégral de disque est sensible du point de vue de la sécurité ; suivez les recommandations du fournisseur et de la distribution ainsi que les modèles de menace adaptés à votre environnement.
Un cas 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é au partage de secret de Shamir sur le matériel de clé qui déverrouille ce chiffrement (le même schéma à petit secret pour grandes données que ci-dessus : le SSS protège la clé, pas le texte chiffré de plusieurs gigaoctets). Si, et seulement si, le micrologiciel 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 des politiques de quorum et des profils cryptographiques nationaux.
Pourquoi les courbes Brainpool (par exemple BrainpoolP256r1, BrainpoolP384r1) sont souvent évoquées dans ce contexte :
Scénarios où combiner SSS avec une cryptographie de type Brainpool répond à des besoins institutionnels (illustratifs ; ne constituent pas un avis juridique ou de conformité) :
Si la signature OpenPGP de style Governikus ou une attestation nationale eID comparable adossée à une puce n'est pas disponible ou pratique dans votre juridiction ou flux de travail, la section 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 tierces sur les certificats.
L'authentification de clé OpenPGP par Governikus est un service en ligne géré pour le compte du BSI (Office fédéral allemand de la sécurité des informations). Après que le demandeur s'est authentifié avec une carte d'identité dotée d'une 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'identifiant utilisateur OpenPGP sur la clé publique téléchargée. Si c'est le cas, 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 micrologiciel : 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, effectuer le flux de soumission Governikus comprenant l'authentification eID (généralement AusweisApp et lecture NFC de la carte), et utiliser la clé publique signée retournée par le service (par exemple par distribution par courriel). La clé privée reste sur Galdralag durant tout le processus.
Aucune voie ne remplace l'autre. L'eID et l'étape Governikus lient la clé publique à une identité vérifiée par la puce au moment de la soumission ; elles ne fournissent ni secret parfait, ni Shamir K-sur-N pour le matériel de clé à long terme, ni profils de chiffrement pour les données en bloc — ce sont des fonctionnalités spécifiques au micrologiciel décrites ailleurs dans ce README. La puce eID et le processus de délivrance qui l'entoure 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à évoqué pour l'utilisation institutionnelle de Brainpool, mais sans étape d'attestation externe, les correspondants doivent se fier à d'autres moyens pour relier une empreinte à une personne morale.
| Couche | Rôle |
|---|---|
| Clé publique OpenPGP (par exemple Brainpool sur Galdralag) | Structure cryptographique et contrôle de la clé privée sur le jeton ; les choix de courbes suivent les attentes de type (voir les et la discussion sur 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é avec ce nom au moment de l'attestation, et non l'unicité globale. Les préoccupations habituelles d'OpenPGP (liaison avec l'email, rotation des clés, 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/) est aussi derrière le processus de signature eID de Governikus, ce qui compte souvent dans les contextes allemands et européens où Brainpool est déjà requis ou préféré — voir Shamir plus Brainpool : exemple et adéquation institutionnelle.
Portée plus large (note de recherche, pas une enquête exhaustive) : Le même schéma — lier une clé publique OpenPGP à une identité vérifiée par puce — est en principe applicable partout où il existe une eID nationale ; 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 des cartes dans le cadre d'eIDAS qui pourraient prendre en charge des ancrages de confiance comparables ou plus forts que la seule voie allemande ; ce README ne les catalogue pas.
L'Estonie et la Belgique ont toutes deux adopté NIST P-384 sur la puce plutôt que Brainpool, alors que le profil BSI du secteur public allemand est centré sur Brainpool (voir ci-dessus). Galdralag prend déjà en charge Brainpool, NIST P-256/P-384 et RSA pour une utilisation OpenPGP (Asymétrique / accord de clé), de sorte que le même schéma d'ancrage de confiance ne dépend pas uniquement de la préférence de courbe de l'Allemagne.
Hors de l'UE/EEE, le schéma d'ancrage de confiance basé sur une carte est plus difficile à appliquer : les États-Unis ont une carte à puce (PIV) mais elle est réservée 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 schéma principalement aux juridictions disposant de justificatifs gouvernementaux sur puce délivrés universellement — la zone eIDAS de l'UE est l'endroit où le modèle est actuellement le plus solide.
Lorsque, et si, le matériel atteint un état prêt pour le consommateur, les personnes qui souhaitent que le partage de secret de Shamir et l'échange de clés éphémères authentifié devienne partie intégrante du comportement interopérable OpenPGP / GnuPG (au lieu de fonctionnalités propres au micrologiciel) devraient conduire les modifications 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 ceux 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é agnostique au chiffrement, enrobage de parts par mot de passe et échange de clés hybrides post-quantique optionnel. Le dépôt CESS contient la spécification normative, le registre des algorithmes, les vecteurs de test et l'exécuteur de conformité.
Ce micrologiciel 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 ; position 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é renforcée) : docs/CESS_CONFORMANCE.md.
Si les mainteneurs de ce dépôt GitHub ne répondent pas aux tickets, demandes de tirage ou courriels, vous pouvez toujours faire progresser 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 centrée sur les bibliothèques, participation active à l'IETF/à l'écosystème) où se déroule une grande partie du développement public. 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 les licences (LGPL 2.0 ou ultérieure pour la plupart des projets), le Certificat d'origine du développeur, et que les fonctionnalités commerciales de plus grande envergure peuvent nécessiter un accord préalable et des arrangements de maintenance à long terme — lisez cette page avant d'investir un effort important.
Il vaut aussi la peine de garder un œil sur https://autocrypt2.org/#/
Ce code et les applications pertinentes ne seront pas compilés pour macOS ou Windows. Les outils hôte (galdra, galdrad, galdra-gtk) et les outils de support ciblent Linux. Il s'agit d'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é totalement 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ée.Les gestionnaires de packages sont généralement sûrs, mais les installations tierces de .deb / .rpm / AppImage peuvent être dangereuses. Privilégiez les packages 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 chaîne d'outils Rust stable telle qu'épinglée dans rust-toolchain.toml. Le micrologiciel utilise la cible riscv32imac-unknown-none-elf ; les outils hôte utilisent le triplet de l'hôte.
test-hal fuirait dans les builds de production) : ```bash
cargo run -p xtask -- check-fw
Le code objet et les archives se trouvent 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 construction de ce produit ; xtask exécute ici cargo build pour les crates de bibliothèque du firmware listés dans xtask (pas un fichier prêt à flasher en soi).
galdralag-service) — nécessite la chaîne d'outils Xous riscv32imac-unknown-xous-elf (pas le triplet firmware nu riscv32imac-unknown-none-elf ci-dessus). Depuis la racine du dépôt : cargo run -p xtask -- build-and-register release. Cela reconstruit l'ELF, le vérifie sur le disque, imprime le cratespec baosec, et exécute éventuellement cargo xtask baosec lorsqu'on fournit --xous-core /path/to/xous-core. Détails : services/galdralag/README.md.Ce dépôt ne fournit pas encore de script de flashage en une commande. La programmation du Baochip-1x (JTAG, amorçage ROM/USB, ou outils du fabricant) suit la documentation de la puce et de la carte. Commencez par Supermagnum/Baochip-1x-firmware ; le matériel de la carte d'évaluation se trouve dans baochip/dabao — sur la carte Dabao, SW2 bascule en mode bootloader (voir ce schéma).
Envoi de UF2 sans appuyer sur le bouton physique : Après avoir copié loader.uf2, xous.uf2 et apps.uf2 sur le volume BAOCHIP, vous pouvez soit appuyer sur le bouton physique boot , soit 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 est distinct de PROG (maintenir enfoncé tout en connectant l'USB pour entrer dans le chargeur de démarrage de stockage de masse BAOCHIP). Voir baochip/dabao#2 (fermé).
Flux Xous / Baochip : Les images sont signées Ed25519 et vérifiées par boot0 avant exécution ; voir Firmware signé (Ed25519, boot0). Pour dabao, la disposition UF2, le fait de maintenir PROG tout en branchant l'USB pour entrer en mode stockage de masse, et les étapes de mise à jour de boot1, voir Getting Started with Baochip Targets.
galdra, galdrad, galdra-gtk)Les crates hôtes 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
galdra-gtk:sudo apt install libgtk-4-dev
`libpcsclite-dev` satisfait le chemin de liaison **par défaut** **`galdra`** **PC/SC** ; **`pcscd`** est le démon qui sert les lecteurs de cartes à puce au moment de l'exécution. **`libssl-dev`** est requis pour que **openssl-sys** puisse se lier (les recherches de clés **sequoia-net** et le TLS **ldap3** utilisent **native-tls** actuellement). Omettez **`libgtk-4-dev`** si vous ne construisez jamais **`galdra-gtk`**.
**GTK 4 (`galdra-gtk` seulement) :** `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`**.
Construisez les binaires de release depuis la racine du dépôt :```bash
cargo build --release -p galdra -p galdrad -p galdra-gtk
Exécutables: target/release/galdra, target/release/galdrad, target/release/galdra-gtk.
Installer dans ~/.cargo/bin (ajustez --path si vous n'êtes pas dans 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 plutôt copier ces trois binaires dans n'importe quel répertoire de votre `PATH`.
### Exécuter `galdrad` et l'interface graphique de bureau (`galdra-gtk`)
**`galdra-gtk`** est le binaire de bureau GTK4 (paquet Cargo **`galdra-gtk`** ; il n'y a pas de **`galdra-gui`**). C'est une interface frontale pour l'API REST **`galdrad`** — exécutez d'abord **`galdrad`**.
**Daemon** — **`galdrad`** écoute par défaut sur **`127.0.0.1:8742`** (`--listen` permet de remplacer) ; voir [`galdrad/src/main.rs`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/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.```bash
galdra-gtk
galdra-gtk --base-url http://127.0.0.1:8742
GALDRAD_URL=http://127.0.0.1:8742 galdra-gtk
Depuis 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 ; les flux de déverrouillage, de provisionnement et autres CCID restent sur la CLI **`galdra`** (voir **`galdra device`** dans **[docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md)** et le niveau **2c**).
**Répertoire de contacts (`galdra contact`, `galdrad` `/contacts`):** la création d'un contact **nécessite un e-mail** (CLI : `--email` ; HTTP : champ JSON `email`). Les champs optionnels incluent **nom d'affichage** (`--name` / `name`), **organisation** (**`--org`** / `org`), **rôle**, **badge** (**`--badge`** / `badge`), **note**, **indicatif**, identifiants **Fluxer**, **Discord** et **IRC**, **numéro de téléphone** (`--phone-number` / `phone_number`), ainsi que des **indications postales** (`street`, `country`, `postal_code`, `region`), **`dmr_id`** radioamateur, et **`radio_affiliation`**. Ces valeurs sont stockées uniquement dans les métadonnées SQLite locales (elles ne sont **pas vérifiées** auprès de services externes). **La recherche** d'un contact (par exemple `galdra contact show`, les chemins `PATCH`/`DELETE`, `galdrad` **`GET /contacts/{id}`**, les identifiants de membres de groupe, ou **`POST /decrypt`** `recipient`) accepte **l'UUID** de la ligne, l'**indicatif**, l'**e-mail**, une **empreinte OpenPGP v4 de 40 hex** complète (espaces ignorés), ces identifiants sociaux, ou un **identifiant d'abonné DMR** dans **1..16777215** lorsqu'il est donné comme jeton décimal. **`galdra keyserver push`** peut refléter plusieurs des mêmes étiquettes vers un registre de style Fulla (**`organisation`**, **`role`**, **`note`**, **`badge_number`**, **`phone_number`**, les champs radio/sociaux/postaux, et les noms — voir **`galdra keyserver push --help`**). Les commandes et les limites des champs sont résumées dans **[docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md)** sous **Contacts** et **Modèle d'identité**.
### Désinstaller les outils hôtes
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 micrologiciel n'est pas "installé" sur l'hôte ; l'effacement ou le reflashage du périphérique relève de la documentation de votre matériel.
Les éléments ci-dessous sont des capacités du micrologiciel Galdralag, et non des exigences de l'application OpenPGP sur carte ou de GnuPG.
Modèle de sécurité prêt pour trois facteurs — Possession du jeton USB et connaissance du code PIN sont appliquées dans le micrologiciel aujourd'hui ; un troisième facteur biométrique optionnel n'est pas implémenté dans ce dépôt (espace réservé : docs/BIOMETRIC_API.md). Voir docs/THREE_FACTOR_AUTH.md pour le périmètre et les limites.
ECDH éphémère authentifié sur l'appareil — véritable secret de transmission futur. Chaque session génère une nouvelle paire de clés éphémères à partir du TRNG matériel du jeton. La clé à long terme signe l'offre éphémère mais ne participe jamais à l'accord de clé. 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 n'offre cette fonctionnalité comme caractéristique de premier ordre.
Partage de secret Shamir K-of-N sur l'appareil — la clé à long terme peut être divisée en N parts nécessitant K parts pour la reconstruction, sans qu'un seul détenteur ne puisse récupérer la clé seul. À la connaissance des auteurs du projet, aucun jeton commercial n'offre non plus cette fonctionnalité comme caractéristique de premier ordre.
Système de profils agnostique vis-à-vis du chiffrement — les chiffrements symétriques,
les courbes ECDHE et la configuration Shamir sont combinés dans des profils nommés
et audités. Pour les données en vrac sous un profil, le texte en clair est chiffré
de l'intérieur vers l'extérieur : vous pouvez empiler jusqu'à quatre
AEAD différents les uns sur les autres — donc vous pouvez utiliser trois
chiffrements indépendants dans un profil (par exemple ChaCha20-Poly1305, puis
Serpent-256, puis Twofish-256), ou une quatrième couche distincte là où la politique
le permet — sans chiffrement répété dans le même profil et avec du matériau de
clé et de nonce indépendant dérivé de HKDF par couche. Les noms intégrés comme
standard, conservative et sont livrés avec
couches ; les empilements plus profonds sont destinés aux profils avancés ou
personnalisés. Règles complètes et disposition filaire : .
Chaque sélection de profil est enregistrée dans la piste d'audit.
Toutes les primitives proviennent de dépendances d'espace de travail auditées indépendamment. Rien n'est implémenté dans l'arborescence.
pin-policy ne soit appelé. Les entrées courtes n'incrémentent pas le compteur.HMAC-SHA256(HostChallengeKey, nonce || passphrase).Définition ou ajustement du seuil de tentatives : La limite du compteur est écrite lorsque le jeton est approvisionné pour la première fois ; ce n'est pas un paramètre d'exécution gpg. Utilisez l'outil hôte galdra après compilation :```bash
galdra device provision --pin-attempts 5
| Drapeau | Plage | Défaut | Signification |
|------|--------|---------|---------|
| `--pin-attempts` | 3–10 | **3** | Tentatives de code PIN échouées autorisées avant verrouillage / zéroisation |
| `--min-pin-length` | 5–32 | **5** | Longueur minimale du code PIN utilisateur (alphanumérique) stockée dans la politique |
Omettez les deux drapeaux pour conserver les valeurs par défaut (`3` tentatives, `5` caractères minimum). Exemple avec les deux : `galdra device provision --pin-attempts 7 --min-pin-length 8`.
La politique est **stockée sur le jeton** (politique du coffre). L'outil hôte ne peut pas augmenter ou diminuer le seuil **après** le provisionnement sans passer par le flux de gestion authentifié propre au dispositif ; considérez le provisionnement comme le moment de choisir une valeur **entre 3 et 10** pour votre modèle de menace. La justification (valeurs par défaut vs limites supérieures) est détaillée dans [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md) sous la section politique de code PIN.
---
## Statut post-quantique
### Implémenté — crate non audité (derrière une fonctionnalité)
---
[Read more](https://github.com/supermagnum/galdralag-firmware)
| Champ | Objectif | Hôte (SQLite galdra) | Magasin de contacts sur puce | Format / limite |
|---|
| Identifiant de contact | Clé primaire stable de l'hôte | 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 balayage d'e-mail | |
| Indicatif | Indicatif radio amateur | Oui | Oui | 12 octets, complété par NUL ; recherche sur puce |
| Identifiant abonné DMR | ID radio DMR | Oui | Oui | Non signé 32 bits (0 = absent) ; recherche sur puce |
| Numéro de badge | Identifiant 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 fonction ou de travail | 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 du 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 d'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é) | Algorithmes : Ed25519, X25519, Brainpool P-256/P-384/P-512, NIST P-256/P-384, RSA-2048/3072/4096 ; blob jusqu'à 768 octets sur puce |
| Clé protégée par code PIN | La clé nécessite un déverrouillage par code PIN | L'hôte stocke les clés OpenPGP séparément | Oui | Condensé du vérificateur de code PIN + métadonnées d'encapsulage AES-GCM sur puce |
| Dernière récupération | Quand le matériel de clé a été actualisé | Oui (fetched_at) | Oui (last_fetched) | UTC sur l'hôte ; horodatage 32 bits sur puce |
| Expire le | Date d'expiration de la clé | Oui | Non | Datetime 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 |
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) |
|---|
| Identifiant de contact / enregistrement | Non (utilisez 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 |
| Service | Aucun champ standard | Oui |
| Rôle / titre de poste | Aucun champ standard | Oui |
| Badge / ID employé | Aucun champ standard | Oui |
| Indicatif | Aucun champ standard | Oui (12 octets, complété par NUL sur la puce) |
| ID 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 v4 OpenPGP | Oui (40 caractères hex) | 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 périphérique G: | Non | Oui (BLAKE3-160 sur la clé publique SIG ; outil hôte ; pas la valeur v4 OpenPGP) |
| ID de clé OpenPGP | Oui (forme courte / longue) | Non |
| Confiance / provenance | Signatures WoT sur les User ID | É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 des outils hôtes | Oui (fetched_at / last_fetched) |
| Clé privée sur le jeton | Emplacements carte SIG, DEC, AUT | Région de clé Galdra séparée (pas de paquets User ID) |
| Code PIN pour utiliser la clé privée | PW1 / PW3 (carte OpenPGP) | Optionnel, enveloppé par PIN 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 — APDUs, PINs, emplacements SIG/DEC/AUT, génération/signature/déchiffrement sur la 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 le périphérique 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 n'analyse pas le courrier |
| Shamir K-of-N — diviser / récupérer le matériel clé à long terme dans le coffre | Pas dans la spécification de la carte OpenPGP ; pas dans GnuPG | Non — firmware et outils de provisionnement uniquement ; pas une opération gpg --card-edit (voir Shamir et chiffrement de disque complet) |
| ECDH éphémère authentifié — protocole de session à secret parfait sur le jeton | Pas dans la spécification de la carte OpenPGP | Non — spécifique au jeton ; pas une commande de carte GnuPG |
| Système de profil de chiffrement — cascades symétriques nommées (empiler des 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 la carte OpenPGP | Non — firmware / outils hôte du jeton |
| microSD leurre / personnalités de stockage de masse — comportement USB sur hôte non informé | Pas dans la spécification de la carte OpenPGP | Non — chemins de code de personnalité USB séparés |
| WebAuthn / FIDO2 | CTAP / WebAuthn | Non implémenté — norme différente de celle 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 exemple avec sa clé OpenPGP) avant distribution |
| Où reconstruire | Machine déconnectée, 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 sont importantes |
|---|
| Départ ou décès d'un employé | 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 la totalité du secret de déverrouillage |
| Dépôt de clés d'entreprise | Fractionnement auditable ; aucun administrateur unique n'a un accès complet |
| Saisie de matériel | Les supports peuvent être saisis sans capturer K parts parmi N |
| Alignement réglementaire (UE / BSI) | Brainpool satisfait de nombreuses exigences cryptographiques allemandes et européennes |
| Signature Governikus | Confirme que le nom sur le certificat correspondait à l'identité authentifiée par puce lorsque l'utilisateur a effectué le flux |
| Juridiction | Statut abordé dans ce document |
|---|
| Allemagne | Flux Governikus/BSI décrit ci-dessus |
| Estonie | eID basée sur une puce. Migration du RSA au NIST P-384 (secp384r1) ECDSA en 2017–2018 après que la vulnérabilité ROCA a forcé l'abandon complet du RSA (la puce ne pouvait pas générer de clés RSA sûres et n'avait pas de 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 trouvé. |
| Belgique | eID basée sur une puce. Les cartes plus anciennes utilisaient du RSA 1024 bits ; les cartes plus récentes (applet 1.8 et suivantes) utilisent NIST P-384 ECDSA. Écosystème de middleware open source actif (eid-mw, OpenSC). Aucun service de signature OpenPGP de style Governikus trouvé. |
| Norvège | La puce de la carte d'identité nationale (délivrée depuis 2020) est compatible ICAO 9303 et n'implémente qu'une puce de document de voyage ; elle ne comporte aucune fonction de signature eID. La signature eID est séparée : des fournisseurs privés agréés (Buypass, Commfides) sous SEID, historiquement du RSA 2048 bits, passant au RSA 3072 bits avec introduction de l'ECC dans SEID 2.0. Aucun service de signature OpenPGP de style Governikus trouvé. La puce de voyage et l'eID de signature sont distinctes — pertinent si quelqu'un tente d'utiliser uniquement la puce de la carte directement. |
| Autriche | Partiellement étudié. L'eID utilise l'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 des courbes 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 fédéraux et aux contractuels — 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. L'autorité racine de confiance est l'Autorité de certification commune fédérale (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. Le fait que PIV soit réservé au fédéral signifie qu'il ne s'agit pas d'un ancrage de confiance civil comme l'eID allemande. |
| Canada | Pas de carte d'identité nationale dotée d'une puce avec clés de signature sur la puce. L'identité numérique est fragmentée entre les systèmes provinciaux (par exemple BC Services Card), les applications mobiles (par exemple eID-Me) et un cadre fédéral émergent de justificatifs numériques. Aucune carte unique comparable au modèle allemand, estonien ou belge. Aucune infrastructure de carte équivalente trouvée — pas un ancrage de confiance viable en ce sens. |
| Autres pays | Non étudié |
| Objectif | Par où commencer |
|---|
| Présentation du projet, actualités, communauté | sequoia-pgp.org |
| Contribuer (tickets, correctifs, fonctionnalités, documentation) ; contacter avant un travail important | Contribute, Contact |
Documentation développeur — surface API pour étendre l'implémentation (sequoia-openpgp et crates associées) | Docs — par exemple sequoia-openpgp sur docs.rs |
| Code source et traqueurs | gitlab.com/sequoia-pgp (bibliothèque centrale et outils) ; github.com/sequoia-pgp (miroirs / dépôts sélectionnés) ; Projects |
| Nouveaux algorithmes dans la norme OpenPGP | Passent encore par le groupe de travail IETF OpenPGP. Sequoia et d'autres implémentations implémentent les brouillons et les RFC ; proposez des modifications de protocole là-bas, et coordonnez-vous avec les implémenteurs (y compris Sequoia) pour que le comportement corresponde à la spécification. |
conservative-shamirBLAKE3 à clé entre les couches de cascade (CESS) — En plus du tag AEAD propre à
chaque couche et de l'enveloppe extérieure ChaCha20-Poly1305 Mode A, le 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).
Les profils intégrés à une seule couche sautent les tags supplémentaires ; les
profils personnalisés (pas de suite_id) conservent la cascade héritée sans MAC
inter-couches. Voir docs/CIPHER_PROFILES.md et
docs/CESS_CONFORMANCE.md. Dénombrements des 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 nombre d'espace de
conception CESS (marche/arrêt indépendant par intervalle), ce n'est pas une bascule
hôte par message :
Le chiffre 205 ne compte que les empilements 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 empilements multipliés par chaque motif
indépendant marche/arrêt pour le BLAKE3 inter-couche optionnel (2^(k−1) motifs pour k
couches). Ce micrologiciel applique les MAC inter-couches pour tous les intervalles quand un
profil intégré avec suite_id a ≥ 2 couches (pas une bascule par intervalle).
Les noms de profils intégrés utilisent un petit sous-ensemble des 205.
Volume leurre microSD optionnel — si une puce PSRAM est installée, un volume leurre supplémentaire en bloc peut apparaître après le déverrouillage. S'il n'y a pas de microSD installée, le périphérique reste un jeton de sécurité matériel (coffre-fort, politique de code PIN, OpenPGP/CCID et autres fonctions de jeton sont inchangées) ; seul ce volume optionnel est absent. Pour les hôtes non informés, le périphérique présente toujours le personnage de stockage de masse sur puce habituel là où il est configuré. Le contenu de la microSD, lorsqu'il est présent, est intentionnellement non chiffré et banal. Le véritable matériel de clé réside dans la RRAM sur puce derrière le coffre-fort et la politique de code PIN.
Pile entièrement ouverte — RTL CERN-OHL-W-2.0, schémas ouverts, chargeur d'amorce reproductible, OS Rust/Xous, silicium inspectable par IRIS.
| Algorithme | Norme | Remarques |
|---|
| BrainpoolP256r1 ECDH + ECDSA | RFC 5639, BSI TR-03111 | Normalisé par le BSI, sans implication NSA |
| BrainpoolP384r1 ECDH + ECDSA | RFC 5639, BSI TR-03111 | Sécurité d'environ 192 bits |
| X25519 ECDH | RFC 7748 | |
| Ed25519 signature / vérification | RFC 8032 | |
| RSA-2048 / 3072 / 4096 OAEP, PSS | RFC 8017 | Minimum 2048 bits imposé |
| P-256, P-384 | NIST | Via les dépendances d'espace de travail p256 / p384 |
| Algorithme | Norme | Remarques |
|---|
| AES-256-GCM | FIPS 197, NIST SP 800-38D | AES matériel sur Baochip-1x |
| ChaCha20-Poly1305 | RFC 8439 | Sans implication NSA |
| Twofish-256 | Schneier et al. 1998 | Finaliste AES, sans implication NSA |
| Serpent-256 | Anderson / Biham / Knudsen 1998 | Finaliste AES, 32 tours, marge conservatrice |
| Algorithme | Norme |
|---|
| HKDF (SHA-256 / SHA-512) | RFC 5869 |
| HMAC (SHA-256 / SHA-512) | RFC 2104 |
| PBKDF2 | RFC 8018 |
| SHA-2 (224 / 256 / 384 / 512) | FIPS 180-4 |
| Famille SHA-3 | FIPS 202 |
| BLAKE2b / BLAKE2s | RFC 7693 |
| BLAKE3 | Spécification BLAKE3 |
| Fonctionnalité | Remarques |
|---|
| Partage de secret Shamir K-of-N | vsss-rs — division et récupération sur l'appareil |
| ECDH éphémère authentifié | Protocole de session à secret de transmission futur — crate ephemeral-session |
| Système de profil de chiffrement | Cascade symétrique : jusqu'à quatre AEAD différents empilés (par ex. trois couches indépendantes) ; clés par couche — cipher-profile — docs/CIPHER_PROFILES.md |
| Propriété | Implémentation |
|---|
| Secret de transmission futur | ECDH éphémère : la clé à long terme ne fait que signer, jamais d'accord |
| Compteur de code PIN avant comparaison | Compteur vidé dans la RRAM avant subtle::ConstantTimeEq — aucune exception |
| Zérotisation matérielle | Réécriture multi-passes à partir du TRNG ; boot0 zérotise avant énumération USB |
| Aucun secret sur le bus USB | L'hôte non informé ne voit qu'un stockage de masse standard ; aucune empreinte possible |
| Preuve d'altération monotone | Compteurs matériels unidirectionnels dans le domaine toujours allumé |
| Authentification à trois facteurs | Possession : jeton USB ; connaissance : code PIN sur l'appareil (pin-policy) ; biométrique optionnel non implémenté — docs/THREE_FACTOR_AUTH.md |
| Compteurs RRAM et piste d'audit | HAL monotone pour le code PIN (et futures signatures PQ avec état) ; enregistrements d'audit de profil et accroche d'audit OpenPGP en RAM — journal d'audit NV en mode ajout non implémenté — docs/AUDIT_LOG.md, docs/RRAM_LAYOUT.md |
| Opérations en temps constant | Toutes les comparaisons secrètes via subtle ; vérifiées par des harnais dudect |
| test-hal jamais en production | Imposé par la tâche check-fw xtask |
| Longueur de cascade | Empilements ordonnés de chiffrements distincts | × BLAKE3 optionnel marche/arrêt à chacun des length−1 intervalles entre 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 |