supermagnum/galdralag-firmwareUn framework crittografico per Baochip-1x.
Questo progetto è registrato presso l'Open Invention Network (OIN). OIN è un pool di brevetti difensivo: i membri si concedono in licenza incrociata i brevetti relativi a Linux, così i partecipanti possono distribuire e utilizzare software open source con una minore esposizione ai brevetti.
Stato: In attesa di: https://github.com/betrusted-io/xous-core/pull/937
Firmware per dispositivi Baochip-1x (scheda di valutazione Dabao) che eseguono il
microkernel Xous, compilato
per riscv32imac-unknown-none-elf.
Si trova qui: https://www.baochip.com/
Il dispositivo è un token di sicurezza hardware nella stessa categoria dei dispositivi di classe Nitrokey, con comportamento da smartcard OpenPGP e un vault crittografato. L'intero stack hardware — RTL, schemi, bootloader, OS — è open source e sottoponibile ad audit.
Le specifiche hardware, il modello di boot, le tabelle dei requisiti e l'uso di ComboHash/PKE sono documentati in Supermagnum/Baochip-1x-firmware. La scheda di valutazione Dabao (KiCad, schemi, interruttori, pinout) è baochip/dabao. Per entrare in modalità bootloader per il flashing, premere SW2 per attivarla (vedere lo schema in quel repository). Note sull'architettura di questo repository: docs/ARCHITECTURE.md.
Lo strumento host Galdra mantiene una directory SQLite locale dei destinatari (contatti). Ogni identità memorizzata include il materiale della chiave pubblica più etichette sidecar opzionali (vedere la tabella seguente). Questi tag risiedono nel database host e, per le chiavi Galdra, nello store dei contatti on-chip (crates/contact-store). Non sono magicamente legati agli User ID OpenPGP a meno che non li allineiate voi stessi, e non sono asseriti crittograficamente a meno che non li verifichiate fuori banda. L'opzionale galdra keyserver push può inviare campi sovrapposti a un registro di progetto come JSON insieme alla chiave pubblica esportata. La provenienza per campo sul token usa SelfAttested, HostVerified, RegistrySync e OobVerified (vedere Confronto dei metadati (GnuPG vs Galdra) e il layout del contact store in docs/RRAM_LAYOUT.md).
Dettagli lato host e comportamento CLI: docs/GALDRA-TOOL.md. Layout del wire e conteggi degli slot: crates/contact-store/src/layout.rs e docs/RRAM_LAYOUT.md.
Questo firmware è un token di sicurezza hardware per Baochip-1x: un'applicazione smartcard OpenPGP su USB CCID, con un vault sul dispositivo, policy PIN e funzionalità specifiche del repository (profili cipher — potete impilare fino a quattro cipher simmetrici diversi in una singola cascata, ciascuno con la propria chiave derivata; vedere Capacità principali), flussi correlati a Shamir, ECDH effimero autenticato dove implementato, e strumenti host Galdra). L'obiettivo primario di interoperabilità è l'uso di smartcard OpenPGP in stile GnuPG, non ogni protocollo token sul mercato.
Questo firmware non è:
Le esclusioni a livello di crate allineate con gli stessi vincoli sono elencate in Crates Esplicitamente Esclusi in docs/future-todo.md.
CESS: Questo firmware è conforme a CESS per le costruzioni normative implementate nell'albero (inclusi Mode A AEAD esterno, HKDF-BLAKE3 per K_outer e splitting Shamir GF(2^8) byte-wise). La dichiarazione completa di allineamento, il registro delle deviazioni e il livello di certificazione (ad esempio CESS-CORE per l'intero layer fisso) sono documentati in docs/CESS_CONFORMANCE.md e CESS (standard aperto correlato) più sotto.
La logica applicativa OpenPGP / CCID è in crates/usb-personality. Su Xous, il servizio USB che espone CCID è usb-bao1x (nel vostro checkout xous-core), compilato con la feature ccid-openpgp, usando crates/baochip-openpgp per la finestra RRAM OpenPGP e il provisioning. Layout: docs/RRAM_LAYOUT.md. Lacune pre-produzione (UX PIN operatore, firma della mappa piattaforma): Limitazioni note / lavoro aperto.
L'obiettivo generale rimane un firmware completo, testato e open source di token di sicurezza hardware: comportamento in stile smartcard OpenPGP per GnuPG su CCID (vedere Compatibilità OpenPGP e GnuPG), più funzionalità aggiuntive sul dispositivo non attualmente definite dallo standard smartcard OpenPGP — ECDH effimero con forward secrecy, Shamir K-of-N, profili agnostici rispetto al cipher, volume decoy microSD — come riassunto in Standard vs. funzionalità specifiche del firmware. Tutto su RTL aperto con un bootloader riproducibile.
Per distribuzioni che richiedono due token fisici separati (o detentori di quote K-of-N) prima di sbloccare server, firewall, vault farmaceutici o volumi crittografati, vedere Quorum a doppia chiave hardware (pattern integratore) in Capacità principali. Ogni dispositivo è una sorgente di credenziali; l'applicazione del quorum è il vostro gateway di accesso, layer PAM o pannello — non questo firmware.
Il firmware distribuibile per Baochip-1x è firmato con Ed25519. Firmate l'immagine del firmware con una chiave privata Ed25519; GnuPG può farlo con gpg --sign usando una subkey di firma Ed25519 (il consueto flusso di lavoro OpenPGP con firma distaccata, adattato a qualunque packaging emetta la vostra build). La ROM immutabile boot0 nel SoC verifica quella firma contro le chiavi pubbliche corrispondenti bruciate nel dispositivo (e il più ampio manifest delle chiavi per la catena di boot) prima che la fase successiva — boot1 — possa essere eseguita. boot1 carica quindi le immagini applicative firmate (ad esempio blob UF2 consegnati tramite USB mass storage in modalità bootloader). Le parti predefinite portano quattro chiavi pubbliche Ed25519 on-chip (ruoli come distribuzione del codice, beta e sviluppatore); boot0 / boot1 applicano una policy di mutua sfiducia tra le chiavi di firma di Baochip e quelle di terze parti. Flusso di boot completo, consegna UF2, console, aggiornamenti boot1 e modello di sicurezza: Getting Started with Baochip Targets in xous-core.
Non tutti i test vengono eseguiti in ogni comando; è intenzionale.
xtask non nel test del workspace predefinito: La ricetta comune è cargo test --workspace --exclude xtask perché xtask è un crate di orchestrazione della build. Eseguite cargo test -p xtask quando volete i suoi test.#[ignore]: Questi vengono saltati a meno che non passiate --ignored (e gli eventuali filtri per crate necessari). Le ragioni includono: copertura già esercitata in unit test mirati (es. zeroizzazione post-drop), casi lenti (es. generazione di chiavi RSA) e flussi dipendenti da hardware o token negli strumenti host come galdra che richiedono un dispositivo collegato o fixture.test-all --no-fuzz: Salta il passaggio cargo-fuzz per mantenere brevi CI o esecuzioni rapide ed evitare di richiedere una toolchain nightly per quel passaggio; eseguite cargo run -p xtask -- test-all senza --no-fuzz, oppure invocate i target fuzz separatamente (vedere ).Si può anche verificare l'integrità dei crate con questo quando la PR viene chiusa: https://github.com/rust-lang/cargo/issues/16850
Stato: Pronto per test da parte di esseri umani, su hardware reale — non esiste alcuna release pronta per la produzione. È scritto in Rust usando crate crittografici validati e sottoposti ad audit. Le primitive crittografiche provengono esclusivamente da dipendenze del workspace sottoposte ad audit. Gli algoritmi post-quantistici sono feature-gated e marcati IN ATTESA DI AUDIT INDIPENDENTE. Vedere Stato post-quantistico.
Nota: Parti di questo progetto sono state sviluppate con assistenza IA (Claude, Anthropic). La progettazione, le scelte crittografiche e le decisioni di sicurezza non sono state riviste da un crittografo professionista. Trattatelo come un progetto sperimentale e applicate il vostro giudizio critico. Una revisione indipendente da parte di esperti è fortemente raccomandata prima di qualsiasi distribuzione in produzione.
È pronto per test da parte di esseri umani. Voi decidete se compilare o eseguire qualsiasi parte di questo software; potrebbero esserci bug che unit test, fuzzing e altri controlli non hanno trovato. L'uso di una macchina virtuale opzionale per la sperimentazione riduce il rischio per il vostro sistema host ma non lo elimina. I risultati dettagliati sono in Risultati dei test (docs/TEST_RESULTS.md#run-metadata). Definizioni in linguaggio semplice (A–Z) dei termini tecnici: Glossario.
Lo sviluppatore principale ha una condizione neurologica correlata alla discalculia. La discalculia influisce sul senso dei numeri e sull'elaborazione simbolica correlata in modi che, per lui, rendono la programmazione tradizionale — la modifica del codice scritto a mano come unico flusso di lavoro — non praticabile senza strumenti assistiti (ad esempio editor conversazionali basati su IA). Quel vincolo è distinto dalla correttezza: i revisori dovrebbero comunque valutare test, fuzzing e audit indipendente come documentato altrove in questa pagina.
Un crittografo o un implementatore serio che esamina Galdralag aprirà tipicamente crates/vault/tests/ e crates/cipher-profile/tests/ prima di leggere la prosa. La suite di test è la prova del lavoro: codifica conoscenza di dominio che non può essere sostituita con la sola narrazione.
Questo non è un motivo per nascondere il punto a tutti gli altri. Le persone che valutano il progetto per l'approvvigionamento, che decidono se contribuire o che distribuiscono codice senza una formazione approfondita nella metodologia di test crittografico meritano comunque un puntatore alle prove concrete.Cosa guardare: Il materiale di conformità include gli esempi pratici RFC 8439 per ChaCha20-Poly1305 in crates/vault/tests/rfc_vectors/, i JSON Wycheproof forniti per ChaCha20-Poly1305 e i casi limite ECDH/ECDSA Brainpool in crates/vault/tests/data/wycheproof/, i vettori BSI TR-03111 per BrainpoolP256r1 e P384r1 in crates/vault/tests/bsi_vectors/, i vettori di riferimento ufficiali BLAKE3 (tutte le 35 lunghezze di input, tutte e tre le modalità) in crates/vault/tests/blake3_vectors.json, i vettori di specifica Twofish (1203 casi inclusi Monte Carlo) in crates/vault/tests/twofish_vectors.json, e il fixture KAT della cascata CESS del progetto con intermedi verificati in modo indipendente in crates/cipher-profile/tests/fixtures/cascade_cess_kat.json. Insieme, questi rappresentano la verità di base che l'esecutore e i revisori possono esercitare con cargo test --workspace e python3 scripts/verify_cascade_kats.py.
RFC 8439 è pubblicato dalla Internet Engineering Task Force (IETF), l'organizzazione che standardizza gran parte di come internet interoperi. Gli RFC (Request for Comments) sono la forma usuale per le specifiche di protocollo e molte specifiche crittografiche. L'RFC 8439 definisce la crittografia autenticata ChaCha20-Poly1305 (basandosi sui progetti di Daniel Bernstein) e include esempi pratici concreti con input e output attesi specifici, così che implementazioni indipendenti possano verificare di corrispondere allo standard byte per byte. Il testo in chiaro ampiamente riprodotto che inizia con Ladies and Gentlemen of the class of '99: wear sunscreen appare negli esempi in appendice dell'RFC: se il tuo codice riproduce esattamente l'output AEAD, hai una forte verifica di aver implementato correttamente la costruzione. È l'analogo crittografico di una chiave di risposta ufficiale. ChaCha20-Poly1305 è lo strato interno di ogni profilo di cascata multilivello in questo firmware, quindi questa verifica si trova alla base dell'intero stack di cifrari.
Wycheproof è un corpus di test rilasciato dal team di sicurezza di Google (2017). Il nome si riferisce al Monte Wycheproof in Australia — spesso citato come la montagna più piccola del mondo — perché il progetto si concentra sul superare ostacoli piccoli ma fatali: overflow di interi, casi limite, input malformati e tag di autenticazione manomessi; fallimenti che si ripresentano ripetutamente nella crittografia reale distribuita. Completa i vettori in stile RFC: gli esempi in stile RFC 8439 dimostrano la correttezza rispetto all'AEAD pubblicato; Wycheproof sollecita la robustezza dove le implementazioni storicamente si rompono. In questo repository, i JSON Wycheproof coprono ChaCha20-Poly1305, AES-GCM, HMAC, HKDF, X25519, Ed25519, RSA e varianti ECDH/ECDSA Brainpool.
BSI TR-03111 è la linea guida tecnica per la crittografia a curva ellittica pubblicata dall'Ufficio Federale Tedesco per la Sicurezza delle Informazioni (Bundesamt für Sicherheit in der Informationstechnik). La versione 2.10 è la revisione corrente. Le curve Brainpool utilizzate in questo firmware — P256r1 e P384r1 — sono specificate negli standard BSI, rendendo TR-03111 il riferimento naturale per i loro vettori di test. Ogni curva ha copertura ECDH ed ECDSA; le firme ECDSA sono state inoltre verificate in modo incrociato contro un'implementazione Python indipendente che utilizza la libreria cryptography.
Vettori di riferimento BLAKE3 sono il corpus di test ufficiale pubblicato insieme alla specifica BLAKE3 dai suoi autori. Coprono 35 lunghezze di input da 0 a 102400 byte, scelte specificamente per esercitare tutte le condizioni limite interne di chunk e hashing ad albero che sono invisibili ai test con input brevi. Tutte e tre le modalità BLAKE3 — hash predefinito, hash con chiave e derive-key — sono coperte. BLAKE3 è utilizzato in tutto questo firmware per la derivazione delle chiavi HKDF e i controlli di integrità tra gli strati nei profili di cifrario a cascata; la copertura dei limiti è importante perché la costruzione ad albero di BLAKE3 si attiva solo sopra i 1024 byte.
La suite di test è anche rilevamento di manomissione per la supply chain. Tutte le primitive crittografiche in questo firmware provengono da crate RustCrypto sottoposte ad audit — nessuna crittografia è implementata in-tree. Poiché i vettori di conformità sopra vengono eseguiti contro quelle crate a ogni cargo test --workspace, qualsiasi dipendenza che sia stata manomessa o sostituita produrrà un fallimento del test a risposta nota prima che il codice compromesso raggiunga un sistema distribuito. python3 scripts/verify_cascade_kats.py aggiunge un secondo percorso indipendente: un'implementazione Python verifica gli stessi valori intermedi nel fixture KAT della cascata, così anche una toolchain Rust compromessa che produce output errati viene intercettata dalla verifica incrociata. Questa è una storia di integrità della supply chain significativamente più forte rispetto al collegamento a una libreria C, dove la verifica equivalente di ogni operazione interna richiede uno sforzo notevolmente maggiore e strumentazione specialistica.
Spetta ora al lettore giudicare se queste affermazioni siano false o meno.
Lo colleghi a una porta USB. Dal punto di vista dell'host, il firmware può presentare modalità crypto o modalità mimetizzazione. In modalità crypto il tuo computer vede una smart card: usi GnuPG o uno stack OpenPGP compatibile (Cos'è GnuPG?) nello stesso modo in cui useresti qualsiasi altro token di sicurezza hardware — il token gestisce le operazioni crittografiche sensibili così che le tue chiavi private non esistano mai non protette sul tuo computer. In modalità mimetizzazione può enumerarsi come normale memoria rimovibile con file dall'aspetto innocuo, così che un'occhiata rapida non riveli il suo vero ruolo; vedi Mimetizzazione dello storage più sotto.
GnuPG sta per GNU Privacy Guard. È l'implementazione del progetto GNU di OpenPGP, lo standard aperto per la gestione delle chiavi e i messaggi protetti crittograficamente (la stessa famiglia concettuale di PGP, ma specificato in documenti come RFC 4880 e aggiornamenti della comunità). Normalmente lo esegui come comando gpg su Linux, BSD, macOS o Windows; molti strumenti grafici di posta e gestione chiavi lo avvolgono internamente.
Le persone usano GnuPG per:
gpg-agent espone chiavi di autenticazione da una smart card o da un keystore locale.GnuPG e dischi crittografati (LUKS). Linux ha un modo integrato per crittografare un intero disco o partizione, chiamato LUKS. Una volta che un disco è crittografato, appare come rumore privo di significato a chiunque non abbia la chiave, quindi un laptop perso o rubato non consegna i tuoi file.
Normalmente sblocchi un disco del genere digitando una password. GnuPG ti permette di usare invece il tuo token. L'idea è semplice: la chiave di sblocco del disco è essa stessa bloccata con la chiave del tuo token. Quando vuoi aprire il disco, il token decifra quella chiave di sblocco per te, ma solo mentre il token è collegato e hai inserito il tuo PIN. Estrai il token e il disco non può essere aperto affatto, nemmeno sullo stesso computer.
In breve, questo trasforma il token in una chiave fisica per il tuo disco crittografato. La configurazione (e l'aggiunta di un modo di backup, nel caso il token vada perso) si fa con gli strumenti disco nativi di Linux; il token semplicemente detiene la chiave. Se preferisci condividere la capacità di sbloccare un disco tra più persone, così che nessuna singola persona possa farlo da sola, vedi Condivisione segreta di Shamir e crittografia del disco.
Per impostazione predefinita GnuPG memorizza le chiavi in ~/.gnupg. Con una smart card OpenPGP, le chiavi private sensibili vivono sulla carta; scdaemon (parte della suite GnuPG) parla CCID/USB con la carta mentre gpg assembla comunque i pacchetti OpenPGP sull'host.
A cosa puoi usarlo. In modalità crypto il token è destinato allo stesso lavoro di altre smart card OpenPGP: firmare e decrittografare posta e file, autenticarsi (per esempio SSH quando usi gpg-agent come al solito) e tenere chiavi private a lungo termine lontane dalla macchina su cui digiti. Le organizzazioni possono combinare questo con quote Shamir sul token così che nessuna singola persona detenga l'intero segreto (descritto più avanti). GnuPG è l'obiettivo primario di interoperabilità sull'host: questo firmware implementa l'applicazione carta OpenPGP su CCID, che scdaemon pilota (gpg --card-status, gpg --card-edit e normali operazioni di crittografia/firma/decrittografia con chiavi sulla carta). Altri software che parlano gli stessi protocolli di smart card potrebbero funzionare anch'essi; comandi, slot, algoritmi e limiti di integrazione attuali sono in Compatibilità OpenPGP e GnuPG. Quando NFC verrà attivato sull'hardware (integrazione pianificata — non ancora nel firmware), la stessa classe di dispositivo potrà supportare accesso fisico: toccare un lettore NFC a una porta, cancello o pannello di chiusura può partecipare a una policy che rilascia la serratura solo dopo controlli crittografici (spesso combinati con PIN, biometria o quorum in stile Shamir a seconda della distribuzione). Lo schizzo orientato a PN532 per lettori e pannelli è in docs/NFC_PN532_INTEGRATION.md.
Questa è la versione breve. Ecco cosa lo rende diverso da altri token che potresti aver incontrato.
Mimetizzazione dello storage. Il dispositivo può agire come normale memoria rimovibile così che il suo vero ruolo non sia ovvio da un'occhiata rapida. Quando lo colleghi a un computer tipico, può apparire come una normale unità USB o un volume basato su SD; puoi riempire il filesystem visibile con file quotidiani plausibili (per esempio foto di vacanza) così che la navigazione casuale rafforzi l'impressione che sia solo storage. Questo frustra l'ispezione superficiale a una scrivania o a un checkpoint. Capire che è in realtà un token di sicurezza di solito significa smontare l'involucro, non solo collegarlo.
Le tue chiavi restano sul dispositivo. Quando firmi un'email o decrittografi un file, la chiave privata non lascia mai il token. Il computer invia i dati, il token fa il lavoro, il risultato torna fuori. Un attaccante che compromette il tuo computer non ottiene nulla di utile.
Le sessioni passate restano al sicuro anche se il token viene rubato. La maggior parte dei token hardware usa una chiave privata a lungo termine direttamente per l'accordo di chiave. Questo genera una nuova coppia di chiavi usa e getta per ogni sessione, la firma con la chiave a lungo termine per dimostrare che è autentica, e poi usa la coppia usa e getta per lo scambio effettivo. Se qualcuno ruba il token tra anni e in qualche modo estrae la chiave a lungo termine, non può comunque decrittografare nulla dalle sessioni passate. Questa proprietà è chiamata segretezza in avanti, ed è insolita nei token hardware.
Puoi dividere la chiave tra più persone. Il token può dividere la chiave a lungo termine in N quote così che qualsiasi K di quelle quote siano necessarie per ricostruirla — ma nessun singolo detentore di quota può fare nulla da solo. Questo è chiamato condivisione segreta di Shamir. È utile per chiavi organizzative dove nessuna singola persona dovrebbe avere accesso unilaterale, o come strategia di backup dove le quote sono memorizzate in posizioni separate. Anche questo è insolito nei token hardware.
La crittografia è a strati. Piuttosto che crittografare i tuoi dati con un singolo cifrario, il token può farli passare attraverso più cifrari indipendenti in sequenza — per esempio ChaCha20, poi Serpent, poi Twofish — ciascuno usando una chiave derivata separatamente. Una futura scoperta che rompe un cifrario non rompe gli altri. La combinazione specifica è chiamata profilo di cifrario, e puoi scegliere tra diversi profili integrati a seconda di quanta cautela richiede la tua situazione.
La mia raccomandazione personale è BrainpoolP256r1 + ChaCha20-Poly1305 + BLAKE3. Questo è il profilo standard integrato. Usa la curva BSI Brainpool P-256 per l'accordo di chiave effimero, ChaCha20-Poly1305 per la crittografia simmetrica e BLAKE3 per la derivazione delle chiavi e l'integrità tra gli strati. È veloce, ben testato, efficiente dal punto di vista della batteria (ChaCha20-Poly1305 è stato progettato per essere efficiente su hardware senza accelerazione AES, riducendo il tempo CPU e il consumo di energia dell'host; P-256 è la più piccola delle tre curve Brainpool in questo firmware) e non dipende da alcuna primitiva progettata dal NIST. Se hai bisogno di un margine maggiore contro una futura rottura crittanalitica di un singolo cifrario, il profilo conservative aggiunge uno strato Serpent-256 sopra.
Le scelte algoritmiche sono deliberate. I cifrari usati — ChaCha20-Poly1305, Serpent, Twofish, Camellia — sono stati tutti progettati indipendentemente dagli organismi di standardizzazione governativi. AES e la suite NIST sono intenzionalmente esclusi. Questa è una scelta consapevole per utenti e organizzazioni che vogliono indipendenza crittografica dal processo di standardizzazione di un singolo paese. Camellia è stato valutato indipendentemente dal progetto EU NESSIE e dal programma CRYPTREC del Giappone, ed è specificato in RFC 3713 e ISO/IEC 18033-3.
Un PIN errato ti blocca correttamente. Il token conta i tentativi PIN falliti prima di verificare se il PIN è corretto, non dopo. Questo significa che un crash o una perdita di alimentazione a metà tentativo non può essere sfruttato per resettare il contatore. Dopo troppi tentativi errati, il token azzera il materiale sensibile.
Cosa non fa ancora. Non c'è ancora hardware disponibile — questo è firmware in sviluppo attivo. Il test end-to-end con hardware USB reale e GnuPG è una pietra miliare futura. Il trasporto NFC e i lettori di accesso in stile porta sono descritti nella documentazione come obiettivi di integrazione, non comportamento distribuito. Il terzo fattore biometrico descritto nella documentazione non è ancora implementato. Alcuni test sui canali laterali temporali che richiedono hardware reale non possono essere completati finché non esiste un dispositivo.
Galdralag può lavorare con due diversi tipi di chiave asimmetrica contemporaneamente. Rispondono a domande diverse sul dispositivo e sull'host, e non sono intercambiabili anche quando appartengono alla stessa persona. Le sezioni Compatibilità OpenPGP e GnuPG, Web of Trust e Key Signing Parties, Metadati di contatto Galdra e Confronto dei metadati (GnuPG vs Galdra) descrivono ciascuno stack in maggior dettaglio; ecco come differiscono in termini quotidiani.
Una chiave OpenPGP, nel senso in cui GnuPG la genera e la usa, è un pacchetto strutturato, non un numero pubblico nudo. Raggruppa la chiave primaria, le sottochiavi per firma e crittografia e uno o più User ID — di solito un nome visualizzato e un indirizzo email come Alice Example <[email protected]>. Altre persone possono firmare quegli User ID per dire che credono che la rivendicazione di identità sia autentica; quel grafo sociale è la base della web of trust descritta in Web of Trust e Key Signing Parties più avanti in questo README. Quando Galdralag agisce come smartcard OpenPGP, detiene il materiale della chiave privata sul chip ed esegue lì firma e decrittografia. La chiave pubblica, gli User ID e le firme degli altri vivono sull'host e sono gestiti da GnuPG nel modo usuale. Il token non cambia il formato del messaggio OpenPGP sul filo; GnuPG lo tratta come qualsiasi altra carta OpenPGP.
Una chiave Galdra è una coppia di chiavi asimmetriche nuda — Ed25519, X25519 o una delle curve Brainpool o NIST che il firmware supporta. I byte della chiave stessa non portano alcuna rivendicazione di identità: nessun pacchetto User ID, nessuna email incorporata, nessuna firma web-of-trust allegata alla struttura della chiave. L'identità per una chiave Galdra deriva dal record di contatto memorizzato accanto ad essa nel database SQLite dell'host e nel contact store sul chip, legato alla chiave tramite la sua impronta.
La tabella seguente confronta metadati di identità e contatto campo per campo. Le colonne OpenPGP / GnuPG descrivono ciò che ottieni da un certificato e User ID normali (più righe di contatto opzionali lato host in Galdra quando memorizzi una chiave pubblica OpenPGP nella stessa directory). Le colonne chiave Galdra descrivono campi sidecar strutturati per contatti operativi (dettaglio completo su host e chip in Metadati di contatto Galdra). Un trattino significa che quello stack non ha un campo standard e separato per quell'elemento.
OpenPGP mette nome ed e-mail in una singola stringa User ID; non ti dà campi separati e leggibili dalla macchina per callsign, DMR o postali. Galdra li mantiene come colonne nominate così che i team radio e operativi possano cercarli e visualizzarli senza analizzare il testo del certificato.
I token aggiornati da firmware che offriva BrainpoolP512r1 potrebbero ancora restituire attributi P-512 su GET DATA; le operazioni GnuPG su quegli slot falliscono quindi con errori generici di carta. Esegui galdra device status (o vedi docs/OPENPGP_CARD.md) per identificare slot obsoleti; il contesto della rimozione è in CHANGELOG.md.
| PW1 / PW3 | Mai memorizzati | Verificatore sul chip (min 5 caratteri, 3 tentativi predefiniti) |
| DO del titolare (login, lingua, URL, …) | Memorizzati nella cache da GnuPG | Opzionali (254 byte max per DO) |
Applicazione carta 3.4.1, CCID e flussi di lavoro GnuPG: docs/OPENPGP_CARD.md e Compatibilità OpenPGP e GnuPG.La suddivisione esiste perché le informazioni di identità che contano nelle comunità a cui Galdralag si rivolge — nominativo, ID DMR, affiliazione alla rete radio — non hanno una collocazione naturale in un OpenPGP User ID. Un User ID è pensato per nome ed email. Scrivere qualcosa come LA5XYZ <[email protected]> DMR:2345678 in una stringa User ID è informale, non strutturato e non leggibile da macchina in alcun modo standard. Le chiavi Galdra mantengono il materiale crittografico pulito e collocano l'identità operativa in un formato di record che lo strumento host e lo store on-chip comprendono nativamente.
In pratica, un singolo dispositivo può contenere entrambi i tipi di chiave senza conflitti. L'applicazione della smart card OpenPGP serve GnuPG tramite gli slot standard SIG, DEC e AUT. Lo store dei contatti contiene le chiavi Galdra per il lavoro operativo — ad esempio cifrare verso un contatto radio tramite nominativo, verificare un messaggio rispetto a un ID abbonato DMR o cercare un collega tramite numero di badge. I due percorsi non si sovrappongono.
Se qualcuno ha un certificato OpenPGP gestito da GnuPG sull'host e una chiave Galdra nello store dei contatti on-chip, si tratta di due chiavi separate con due impronte digitali separate. L'impronta Galdra — con prefisso G: e derivata con BLAKE3 dai byte grezzi della chiave pubblica — non è lo stesso valore dell'impronta OpenPGP v4 del certificato GnuPG di quella persona. Lo strumento host e il dispositivo le trattano come identità indipendenti. Non dare per scontato che un'impronta implichi l'altra senza verificare entrambe.
Nessuno dei due tipi di chiave garantisce automaticamente le etichette che li circondano. Un OpenPGP User ID è auto-dichiarato finché qualcun altro non lo firma. Un campo nominativo o DMR in un record di contatto Galdra è affidabile solo quanto la sua fonte — un recupero da keyserver, un inserimento manuale o una verifica out-of-band eseguita da te stesso. Le etichette di provenienza (SelfAttested, HostVerified, RegistrySync, OobVerified) registrano come è arrivato un campo; non sostituiscono il lavoro di verifica effettiva dell'identità che ti interessa.
Questo firmware è scritto in Rust, un linguaggio di programmazione di sistema progettato per essere veloce e di basso livello come C o C++, ma con un approccio fondamentalmente diverso alla sicurezza.
Ogni dipendenza è classificata come upstream invariata (crates.io come pubblicata), modificata o venduta in-tree (copia pinnata o patch del workspace) o creata da questo progetto (crate di firmware, host e tooling). L'inventario completo, i ruoli e il grafo delle dipendenze sono in docs/CRATE_DEPENDENCIES.md.
Una grande parte dei bug rilevanti per la sicurezza nei codebase industriali deriva da insicurezza della memoria (buffer overflow, use-after-free, dereferenziazioni di null e simili). L'MSRC di Microsoft ha riportato ripetutamente che circa il 70% dei CVE affrontati nei propri prodotti rientra in questa categoria; il team di Chrome ha pubblicato proporzioni simili per Chrome. Queste cifre descrivono i prodotti di quei vendor, non una legge universale per tutti i firmware, ma illustrano perché i linguaggi memory-safe contano.
In Rust safe (l'impostazione predefinita), il borrow checker esclude le data race e i consueti errori di memoria da comportamento indefinito in fase di compilazione senza fare affidamento sulla garbage collection. Rust unsafe e FFI verso C possono ancora introdurre bug di memoria; devono essere mantenuti limitati e revisionati.
Il bounds checking di Rust su slice e le sue regole di ownership riducono diverse classi di modalità di guasto comuni nel codice embedded C/C++:
unsafe devono essere espliciti; MMIO e puntatori grezzi per i registri vivono lì, così i revisori possono fare grep sulla superficie di audit (unsafe non rende impossibile un MMIO errato, solo più facile da localizzare).Rust non ferma da solo i bug logici come un loop stretto che consuma la flash o la scelta di valori di registro errati. Questi restano questioni di ingegneria e revisione.
Questo codebase applica pattern Rust comuni per i segreti; non sono automatici per ogni tipo:
zeroize::Zeroize / ZeroizeOnDrop cancellano i buffer al drop; i chiamanti vi aderiscono esplicitamente.subtle::ConstantTimeEq (e simili) dove il timing conta — un normale == non è magicamente a tempo costante.Copy sui wrapper dei segreti riduce la duplicazione accidentale; la separazione dei domini usa tipi distinti e etichette HKDF (Politica delle dipendenze crittografiche).catch_unwind o abort dove la tua piattaforma richiede garanzie più forti.unsafe deve essere scritto esplicitamente nel sorgente, il che restringe la revisione manuale. Dipendenze: la politica crittografica di questo progetto favorisce crate Rust sottoposti ad audit (RustCrypto e altri); vedi la tabella in Politica delle dipendenze crittografiche — non ogni dipendenza proviene da un singolo progetto ombrello. Per l'elenco completo dei crate e se ogni dipendenza è invariata, modificata/venduta o scritta dal progetto, vedi docs/CRATE_DEPENDENCIES.md.
Rust non elimina i deadlock (ad es. lock Mutex in ordine errato), i bug logici, i protocolli errati, l'usura della flash da loop errati, gli attacchi fisici (glitching, analisi dei consumi) o i rischi derivanti da una build corretta dell'immagine sbagliata. Inoltre non garantisce l'esecuzione a tempo costante su tutto l'hardware senza una codifica attenta. Queste aree si affidano a progettazione, revisione, test e alle pratiche crittografiche e di supply-chain del progetto descritte altrove in questo README.
Verifica (test e fuzzing): Oltre al linguaggio, questo repository usa unit test, test di integrazione, harness di timing dudect e target libFuzzer (cargo-fuzz). Riepiloghi e matrici sono in Risultati dei test; i metadati registrati delle esecuzioni iniziano in docs/TEST_RESULTS.md#run-metadata. Il superamento dei test non dimostra la prontezza per la produzione o l'assenza di vulnerabilità — restringono il rischio. Tu giudichi se eseguire build o test è accettabile per il tuo ambiente; una macchina virtuale è opzionale ma limita il raggio d'azione sulla tua macchina.
Qualsiasi piattaforma VM importante è adatta — VirtualBox (gratuito, open source), QEMU (gratuito, open source, da riga di comando) o VMware. Un guest Linux è consigliato poiché l'ambiente di build è supportato al meglio lì.
Avvio rapido con QEMU e 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
All'interno della VM si applicano le istruzioni di build standard. La VM può
essere **sottoposta a snapshot** prima di ogni esperimento e **ripristinata** in modo pulito se
qualcosa va storto.
### Valutazione del rischio e distribuzione
**In definitiva, se questo firmware sia sicuro da distribuire nel tuo
ambiente è una decisione che solo tu puoi prendere**, in base alla tua
valutazione del rischio, alla sensibilità di ciò che stai proteggendo e
alla scelta se attendere un audit indipendente di terze parti
prima della distribuzione. Questo progetto mira a darti tutte le
informazioni necessarie per prendere quella decisione da solo.
Un elenco strutturato di asset, minacce **T1–T14**, non-obiettivi espliciti e lacune di verifica Q2 è in **[docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREAT_MODEL.md)**.
---
## Sul nome
**Galdr** è la pratica norrena di magia parlata o cantata: incantesimi
usati per legare, proteggere o rivelare. Nelle saghe nomina l'atto di lanciare
l'incantesimo stesso, non solo le parole. A volte è usato anche per attivare
iscrizioni runiche magiche, come sull'[asta di lancia Kragehul I](https://en.wikipedia.org/wiki/Kragehul_I),
l'[amuleto di Lindholm](https://en.wikipedia.org/wiki/Lindholm_amulet),
il [bracteato di Vadstena](https://en.wikipedia.org/wiki/Vadstena_bracteate),
e altri ritrovamenti in Fuþark antico.
**Galdralag** è la forma metrica usata per il galdr: versi strutturati, precisi,
regolati da norme in cui il pattern fa parte della forza dell'incantesimo.
Il suffisso *lag* è affine a "legge" o "pattern".
**Le rune** erano letteralmente conoscenza segreta e codificata — l'uso sciamanico
era noto solo a chi le comprendeva.
---
## Documentazione
**Glossario:** [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md) — termini spiegati in **linguaggio semplice** (ordinati A–Z). Inizia da qui se il README o altri documenti sembrano pieni di gergo.
**Debug:** [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DEBUG_INSTRUCTIONS.md) — backtrace, restringimento di `cargo test`, scorciatoie `xtask`, controlli tripli del firmware, fuzzing e cosa raccogliere prima di segnalare un problema.
**Assistenti AI (Claude, Cursor):** [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/CLAUDE.md) — istruzioni di progetto per agenti di codifica. Regole specifiche per Cursor: [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/main/.cursor/rules).
**Sfoglia tutti i file:** [github.com/Supermagnum/Galdralag-firmware — `docs/`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs)
**Hardware (dongle USB e correlato):** Due alberi KiCad: [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-files-usb) — `dabao_v3c` (token USB-A **senza** micro-SD); e [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card) — `dabao_v3c_sdcard` (stesso layout di base **con** supporto micro-SD), gerber, BOM, output di produzione e [documentazione pinout](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card/docs/pinout/README.md). Il layout PCB del dongle USB-A (token minimale vs eval in formato Pico) è descritto in [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md).
| Documento | Descrizione |
|----------|-------------|
| [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-files-usb) | Progetto KiCad **dongle USB** `dabao_v3c` (senza micro-SD); gerber, BOM, output di produzione; complementa [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) |
| [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card) | Progetto KiCad **dongle USB** `dabao_v3c_sdcard` (supporto micro-SD); gerber, BOM, pinout in [docs/pinout](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card/docs/pinout/README.md); complementa [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) |
| [docs/CODE_MAP.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CODE_MAP.md) | **Indice di funzioni e moduli** del workspace (`pub fn` / tipi per file con ancoraggi di riga) |
| [docs/CRATE_DEPENDENCIES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CRATE_DEPENDENCIES.md) | Crate Rust **upstream vs progetto** e come dipendono tra loro |
| [docs/API_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/API_REFERENCE.md) | Mappa del codice + **appendice** per IETF/I-D/GnuPG/Sequoia: costruzione Shamir GF(256), armour GALDRA SHARE, formato wire ECDH effimero, etichette HKDF, preimmagini; route `galdrad`; suggerimenti rustdoc |
| [docs/ARCHITECTURE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/ARCHITECTURE.md) | Architettura firmware di alto livello e sottosistemi principali |
| [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/AUDIT_LOG.md) | Record di audit dei profili (`cipher-profile`), hook OpenPGP `OpenPgpAudit`; **nessun** log RRAM append-only implementato finora |
| [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_API.md) | Pre-gate biometrico: architettura, formato wire, layout vault; integrazione parzialmente implementata |
| [docs/BIOMETRIC_DEVICE_GUIDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_DEVICE_GUIDE.md) | Come aggiungere il supporto per un nuovo backend hardware biometrico |
| [docs/BIOMETRIC_TESTING.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_TESTING.md) | Metodologia di test: metriche PAD ISO/IEC 30107-3, dataset, come eseguire |
| [docs/FINGERVEIN_DEVICE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/FINGERVEIN_DEVICE.md) | Dispositivo open finger vein ESP32-CAM: hardware, bozza di protocollo, liveness |
| [docs/SWEET_PLATFORM_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/SWEET_PLATFORM_INTEGRATION.md) | Scanner palmare sweet platform: hardware, integrazione, liveness, dataset |
| [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRA-TOOL.md) | Strumenti host (`galdra`, `galdrad`, `galdra-gtk`): flussi di lavoro, provisioning, policy PIN, comportamento operativo |
| [Supermagnum/Fulla](https://github.com/Supermagnum/Fulla) | **Fulla**: registro di chiavi pubbliche OpenPGP orientato al WoT (repository server e implementazione). **Nessuna istanza pubblica del registro è ancora in esecuzione**; una è pianificata. **`galdra keyserver push`** / **`galdra keyserver fetch`** e la configurazione opzionale **`[keyserver]`** puntano a questo ecosistema—vedi anche [Web of Trust e Key Signing Parties](#web-of-trust-and-key-signing-parties). Note di progettazione supplementari restano in [docs/server.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/server.md). |
| [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md) | **Glossario in linguaggio semplice** (A–Z) per lettori non tecnici; il dettaglio tecnico resta nei documenti collegati |
| [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/CLAUDE.md) | Istruzioni per **Claude** / agenti di codifica AI; rimanda a [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/main/.cursor/rules) per **Cursor** |
| [docs/GALDRALAG_DEV_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRALAG_DEV_REFERENCE.md) | Toolchain, comandi `xtask`, punti di ingresso per fuzzing e test crittografici |
| [docs/dev-ref.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/dev-ref.md) | Layout del workspace, crate, trait HAL, comportamento USB/PSRAM, invarianti di sicurezza |
| [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DEBUG_INSTRUCTIONS.md) | Debug: `RUST_BACKTRACE`, build verbose, test mirati, ricette `xtask`, controlli target embedded, indicazioni fuzzing, controlli host OpenPGP |
| [docs/KEY_LIFECYCLE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/KEY_LIFECYCLE.md) | Generazione chiavi, import, policy di export, rotazione, zeroizzazione, Shamir (come riflesso in `vault` / OpenPGP) |
| [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md) | Applicazione carta OpenPGP, configurazione host GnuPG/CCID, slot chiavi, algoritmi, udev |
| [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md) | Sistema dei profili cifrari e configurazione |
| [docs/DUAL_KEY_QUORUM.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DUAL_KEY_QUORUM.md) | Quorum a due (o N) chiavi hardware come pattern di estensione per integratori su Shamir e OpenPGP; non imposto dal firmware |
| [docs/CIPHER_PROFILE_SECURITY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILE_SECURITY.md) | Considerazioni di sicurezza: identificatori profilo in chiaro, analisi del traffico, razionale del wrapper esterno BrainpoolP384r1, identificatori cifrati, proprietà wildcard |
| [docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md) | Allineamento [CESS](https://github.com/Supermagnum/CESS/tree/main): layout wire Mode A, `suite_id` da [ALGORITHM-REGISTRY.md — tabella di lookup](https://github.com/Supermagnum/CESS/blob/main/ALGORITHM-REGISTRY.md#cipher-suite-identifier-lookup-table), registro delle deviazioni (AES/SHA-2 mantenuti vs CESS-CORE), roadmap |
| [crates/cess](https://github.com/supermagnum/galdralag-firmware/blob/main/crates/cess) | CESS Mode A: HKDF-BLAKE3 (`derive_k_outer`, `hkdf_blake3`), seal/open esterno ChaCha, layout `suite_id \|\| inner_blob`; vedi [CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md) |
| [docs/EPHEMERAL_SESSION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/EPHEMERAL_SESSION.md) | Protocollo di sessione ECDH effimera autenticata |
| [Supermagnum/CESS](https://github.com/Supermagnum/CESS) | **CESS** (*Cryptologically Enchanted Shamir's Secret*) — specifica aperta (testo normativo e vettori di test) per la condivisione di segreti a soglia con crittografia autenticata, wrapping di condivisioni basato su password e scambio di chiavi ibrido post-quantum opzionale; separato da questo firmware ma nello stesso spazio di progettazione di Shamir e dei profili cifrari qui |
| [docs/PQ_SIGNATURES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/PQ_SIGNATURES.md) | Firme stateful post-quantum (XMSS, LMS/HSS), gating delle funzionalità |
| [docs/Psram.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/Psram.md) | Volume esca microSD opzionale e comportamento correlato |
| [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md) | RRAM on-chip da **4.194.304 byte**: offset vault dal sorgente, mapping HAL, note su usura / zeroizzazione |
| [docs/TEST_RESULTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/TEST_RESULTS.md#run-metadata) | Si apre su **Run metadata**; riepilogo pipeline, vettori, dudect, cargo-fuzz ([Sezione 6](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/TEST_RESULTS.md#6-cargo-fuzz-libfuzzer)), ciclo di vita delle chiavi |
| [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREE_FACTOR_AUTH.md) | Token + PIN + biometrico opzionale: cosa implementa questo repo vs segnaposto; bozza di minaccia |
| [docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREAT_MODEL.md) | Modello di minaccia: asset, minacce T1–T14, cosa è e non è difeso, elementi non verificati in attesa dell'hardware Q2, stato dell'audit |
| [docs/PERFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/PERFORMANCE.md) | Note sulle prestazioni |
| [docs/HARDWARE_BRINGUP_TEST_PLAN.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_BRINGUP_TEST_PLAN.md) | Bring-up del primo hardware Q2: immagine con `galdralag-service`, libccid `1D50:6197`, ATR → APDU `gpg --card-status`, PIN di laboratorio Dabao (non CDC su `dabao-ccid`) |
| [docs/XOUS_CORE_UPSTREAM_REQUESTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/XOUS_CORE_UPSTREAM_REQUESTS.md) | Modifiche che appartengono a xous-core (documenti Persona A, policy ATR, note cratespec); Galdralag non applica patch a quell'albero |
| [docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_VERIFICATION.md) | Zeroizzazione hardware: verifica di simulazione vs silicio |
| [docs/HARDWARE_TEST.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_TEST.md) | Note di test orientate all'hardware |
| [docs/NFC_PN532_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/NFC_PN532_INTEGRATION.md) | PN532 / NFC: libnfc, opzioni Rust, porta passiva vs pannello USB, quorum con Shamir e PIN |
| [docs/SDMMC_STORAGE_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/SDMMC_STORAGE_INTEGRATION.md) | `embedded-sdmmc` + microSD SPI come storage bulk opzionale; alternativa BOM a PSRAM |
| [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) | Come realizzare un PCB dongle USB-A dal riferimento Dabao: l'eval in formato Pico è per il bring-up del firmware; questo rimuove l'header GPIO per un token minimale; KiCad, FreeCAD, 5 V / 500 mA vs USB-C PD, routing QSPI PSRAM |
Gli stessi percorsi si risolvono su GitHub sotto [`tree/main/docs`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs) e [`tree/main/Hardware`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/Hardware).
---
## Compatibilità OpenPGP e GnuPG
Il firmware implementa l'**applicazione carta OpenPGP** (documentata come versione **3.4.1** in [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md)). È la stessa classe di dispositivo che GnuPG gestisce per le **smart card OpenPGP** su **CCID/USB**: l'host necessita di uno stack smart card normale (`pcscd`, driver `ccid`, `scdaemon` di GnuPG). **Nessun driver crittografico host personalizzato** è richiesto oltre a quello che useresti per qualsiasi carta OpenPGP.
**Cosa questo abilita sull'host (una volta che il dispositivo è visibile come lettore CCID):**
| Area | Note |
|------|--------|
| **Flussi di lavoro GnuPG** | `gpg --card-status`, `gpg --card-edit`, cifratura/decifratura e firma usando le chiavi sulla carta |
| **SSH** | `gpg-agent` con `enable-ssh-support` e la consueta configurazione `SSH_AUTH_SOCK` |
| **Posta e file** | Client che usano GnuPG (es. Thunderbird, Evolution, Kleopatra) e cifratura file standard `gpg` |
| **Altri strumenti** | Qualsiasi cosa che parli con carta OpenPGP + CCID nello stesso modo di GnuPG |
**Slot chiavi (default tipici):** **SIG** (firma), **DEC** (decifratura / ECDH), **AUT** (autenticazione, es. SSH). Gli algoritmi operativi per slot sono curve Brainpool, NIST P-256/P-384 ed Ed25519 / X25519. Gli attributi algoritmo RSA possono essere memorizzati tramite PUT DATA, ma GENERATE, PSO:CDS e PSO:DECIPHER falliscono tutti per slot configurati RSA. La tabella completa e il comportamento `key-attr` sono in [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md).
**Non coperto da carta OpenPGP / GnuPG qui:** **WebAuthn / FIDO2** è un protocollo diverso ed è fuori scope per questa applicazione carta (vedi lo stesso documento).
**Carta OpenPGP vs. messaggi OpenPGP:** La specifica della **carta** definisce come il token espone PIN, slot chiavi e operazioni on-card su CCID. **GnuPG** la usa tramite `scdaemon`. Il **formato messaggio OpenPGP** per file e posta (RFC 4880 e successori) è un livello **host-side**: la carta fornisce le chiavi; GnuPG applica comunque il formato messaggio sul PC. Né la specifica carta né RFC 4880 definiscono lo **splitting Shamir**, le **sessioni ECDH effimere** o i **profili cifrari** — quelli sono [specifici del firmware](#standards-vs-firmware-specific-features).
**Stato dell'integrazione:** La logica OpenPGP e CCID vive in **`usb-personality`**, **`baochip-openpgp`** e nel servizio **Xous** **`usb-bao1x`** (vedi **xous-core** su **`feature/usb-bao1x-ccid-openpgp`**). L'opzionale **`galdralag-service`** (`services/galdralag`) si collega a **`usb-bao1x`** per IPC **CCID** e risponde alle APDU **XfrBlock**; le immagini Dabao ne hanno bisogno tramite cratespec (`scripts/build_dabao_ccid_image.sh`). BaoSec può ancora collegare **PDDB** a **RRAM**. Dettagli: [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/main/services/galdralag/README.md). Layout di memoria: [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md). **GnuPG end-to-end su hardware reale** richiede ancora un'immagine completa con Galdralag, riconoscimento host **libccid** di **`1D50:6197`** e gli elementi in [Limitazioni note / lavoro aperto](#known-limitations--open-work).
## Sessione token ed export delle chiavi
**Disconnessione fisica (scollegamento):** L'host perde il dispositivo USB; qualsiasi operazione in corso fallisce finché il token non viene ricollegato e ri-enumerato. Sul dispositivo, la **sessione carta** OpenPGP viene cancellata: lo **stato di verifica PIN** non sopravvive a spegnimento o rimozione, quindi **firma, decifratura e altre operazioni protette richiedono VERIFY PIN di nuovo** dopo la riconnessione, come altre smart card OpenPGP. **Il materiale della chiave privata resta memorizzato sul token** in storage vault sigillato; lo scollegamento non lo cancella a meno che non venga eseguito un percorso separato di **zeroizzazione** o wipe.
**Cosa può lasciare il dispositivo:** Per progettazione, **solo materiale di chiave pubblica** è consentito attraversare il collegamento USB (ad esempio pacchetti di chiave **pubblica** OpenPGP e dati correlati che la specifica carta espone all'host). Le chiavi **private**, gli scalari segreti grezzi e i blob di chiave sigillati **non** lasciano il dispositivo attraverso i normali percorsi firmware; le operazioni con chiave privata vengono eseguite **sul token**. L'host riceve **risultati crittografici** (firme, testo in chiaro decifrato per flussi di lavoro di decifratura assistita dalla carta) dove i comandi standard lo richiedono, non una copia portabile della chiave privata.
**Importazione di chiavi sul dispositivo:** È anche possibile **importare chiavi pubbliche** nel token (ad esempio anchor di fiducia, certificati peer o pacchetti pubblici OpenPGP per verifica on-device). Il **vault** del firmware fornisce **slot per chiavi pubbliche** per materiale non segreto (`crates/vault/src/public_key_vault.rs`). Gli strumenti host per caricare quegli slot sono descritti in [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRA-TOOL.md) man mano che l'integrazione matura.
---
## Web of Trust e Key Signing Parties
OpenPGP e **GnuPG** usano un modello di fiducia decentralizzato—il **web of trust**—per aiutare a verificare chi possiede quali chiavi e se fare affidamento su una data **chiave pubblica**. Quel modello è interamente **host-side**. Dove attestazioni supportate da chip come [eID tedesco e Governikus](#german-eid-and-governikus-as-a-trust-anchor-for-public-keys) non sono disponibili o appropriate, è la soluzione decentralizzata usuale (**key signing parties**, firme su certificati); dove **sono** disponibili, entrambi gli approcci possono coesistere come percorsi complementari.
**Impronta Galdralag (`G:`):** Per flussi di lavoro di verifica in persona, **Galdra** può mostrare un'impronta **legata al dispositivo** derivata dalla chiave pubblica **SIG** del token (**BLAKE3-160**, prefisso `G:`). **Non** è un'impronta di certificato OpenPGP v4. È **disponibile solo** quando il **profilo cifrario** attivo ha **`ephemeral_ecdh: false`**; i profili integrati hanno per default **`ephemeral_ecdh: true`**, quindi in genere aggiungi un profilo utente con **`galdra profile add ... --no-ephemeral-ecdh`** per flussi di lavoro che necessitano di questo identificatore insieme alla firma host in stile **WoT**. Definizione in linguaggio semplice e specifica del formato: [Impronta Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md#g). Ciclo di vita, policy di rotazione e gate ECDH effimero: [KEY_LIFECYCLE.md — Impronta Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/KEY_LIFECYCLE.md#galdralag-fingerprint-host).
### Ottenere la tua impronta Galdralag
L'host stampa una stringa che **inizia sempre con `G:`** (BLAKE3-160 sui byte della chiave pubblica SIG, **40 caratteri esadecimali minuscoli** dopo il prefisso in forma canonica).
1. Installa **[Galdra](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRA-TOOL.md)** sull'host e assicurati che **PC/SC** funzioni (**`pcscd`**, **`libpcsclite`**) così lo strumento può parlare CCID al token (vedi [Compilare e installare gli strumenti host](#compile-and-install-host-tools-galdra-galdrad-galdra-gtk)).
2. Collega il token (sbloccalo se il tuo flusso di lavoro lo richiede).
3. Seleziona un **profilo cifrario** con **`ephemeral_ecdh: false`**. Conferma con **`galdra profile show <name>`** (`ephemeral_ecdh: off`). Il nome profilo predefinito **`standard`** di solito ha **`ephemeral_ecdh: on`**; creane uno con **`galdra profile add <name> ... --no-ephemeral-ecdh`** se necessario.
4. Esegui:```bash
galdra identity fingerprint
# If you use a non-default profile:
galdra identity fingerprint --profile <name>
Output leggibile da macchina: galdra --emit json identity fingerprint (opzionalmente --profile <nome>).
Le implementazioni conformi a OpenPGP includono uno schema di verifica dei certificati per assistere nella verifica della proprietà delle chiavi; il suo funzionamento è stato definito rete di fiducia. I certificati OpenPGP (una o più chiavi pubbliche più materiale relativo a proprietario/ID utente) possono essere firmati digitalmente da altri utenti che, così facendo, avallano l'associazione tra quella chiave pubblica e la persona o entità indicata sul certificato.
gpg --full-generate-key sull'host, o trasportata su un token compatibile con OpenPGP).Un key signing party è un incontro di persona in cui i partecipanti si scambiano le impronte delle chiavi e verificano l'identità reciproca prima di firmare i certificati in un secondo momento.
Caratteristiche tipiche:
Ne risulta un grafo sociale: se Alice si fida di Bob e Bob ha firmato la chiave di Charlie, Alice può scegliere di fidarsi della chiave di Charlie a seconda della profondità di fiducia e della policy.
Perché questi eventi sono importanti:
Di solito i party evitano l'uso di computer durante lo scambio di identità, così gli attaccanti hanno meno possibilità di introdurre chiavi sostituite o malware su macchine condivise.
Prima dell'evento. Calcola e annota la tua impronta (un digest derivato da hash della chiave pubblica, abbastanza corto da essere confrontato in modo affidabile). Non affidarti allo scambio di chiavi complete su carta in questa fase, a meno che gli organizzatori non specifichino diversamente.```bash
gpg --fingerprint YOUR_KEY_ID
Porta l'impronta su carta o su un altro supporto durevole (forma di esempio: `ABCD 1234 EFGH 5678 90AB CDEF 1234 5678 90AB CDEF`).
**Durante l'evento (solo impronte).** Scambia le **impronte**, verifica gli ID e annota quali impronte appartengono a quale persona verificata. Conferma che l'identità dichiarata di ciascun partecipante corrisponda ai documenti controllati.
**Dopo l'evento.** Recupera le **chiavi pubbliche** complete dai **keyserver** o tramite distribuzione diretta; conferma che le chiavi scaricate corrispondano alle **impronte** registrate su carta; **firma** le chiavi che hai verificato; facoltativamente **carica** le firme così che altri possano usarle.
### Impronte invece di chiavi complete durante l'evento
- **Sicurezza operativa.** Mantiene gli attacchi di sostituzione legati a impronte verificate piuttosto che fidarsi di macchine arbitrarie a metà evento.
- **Semplicità.** Le impronte stanno su carta e sono rapide da leggere ad alta voce o da confrontare.
- **Verifica.** Dopo il download, ricalcolare l'impronta controlla l'integrità end-to-end.
### Keyserver
I **keyserver** sono repository in rete che memorizzano e replicano chiavi OpenPGP **pubbliche** (e aggiornamenti come firme e revoche). Rendono le chiavi individuabili tramite **User ID**, **key ID** o **impronta** e sostengono la distribuzione su larga scala per la rete di fiducia.
Come si comportano in linea di principio:
- **Replica distribuita.** Il caricamento su un server che partecipa a una mesh di sincronizzazione spesso si propaga ai peer (i pool classici in stile **SKS** funzionavano così).
- **Sincronizzazione.** Nuove chiavi, firme e certificati di revoca si diffondono secondo le policy e la connettività di ciascun server.
- **Accesso in lettura pubblico.** Solo il materiale **pubblico** è destinato alla pubblicazione; le **chiavi private** non devono mai essere caricate.
**Privacy.** Le chiavi pubblicate espongono gli **User ID** (spesso includendo indirizzi email). Tratta i caricamenti come **pubblici e di lunga durata** su molti server; carica i **certificati di revoca** quando una chiave deve essere ritirata. Le policy variano in base all'operatore ([keys.openpgp.org](https://keys.openpgp.org/) differisce dai pool legacy).
**Topologia dei peer.** I grafici delle relazioni tra server appaiono su [spider.pgpkeys.eu/graphs/](https://spider.pgpkeys.eu/graphs/); gli elenchi di peer orientati a SKS su [spider.pgpkeys.eu/sks-peers](https://spider.pgpkeys.eu/sks-peers).
### Uso dei keyserver```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
| Server | Note |
|---|---|
| keys.openpgp.org | Ampiamente utilizzato; verifica orientata al consenso per gli User ID collegati alla posta elettronica |
| pgp.mit.edu | Server ospitato dal MIT, storicamente legato alle mesh dell'era SKS |
| pool.sks-keyservers.net | Hostname legacy del pool associato al vecchio ecosistema SKS; la connettività oggi varia |
gpg --refresh-keys periodicamente così che revoche e nuove firme si propaghino localmente.ephemeral_ecdh: false con galdra profile show <name>.Per il comportamento autorevole di gpg, i modelli di fiducia e le opzioni di distribuzione, consulta il manuale di GnuPG e la documentazione a monte.
Il progetto Fulla (Supermagnum/Fulla su GitHub) ospita il lavoro sul server di registro allineato al WoT: implementazione e specifica in evoluzione per memorizzare le chiavi pubbliche dei contributori più etichette radioamatoriali opzionali, suggerimenti postali, organisation (ortografia JSON), role, note, badge_number, phone_number e colonne correlate allineate ai metadati di contatto Galdra. galdra keyserver push invia JSON POST /api/v1/keys (inclusi armored_public_key, email e quei campi opzionali quando passi i flag CLI); galdra keyserver fetch e la sezione di configurazione [keyserver] sono implementati in / in quella direzione. ; un servizio gestito pubblicamente è previsto in futuro. Ulteriore prosa di progettazione storica si trova in .
Diverse parti di questo progetto si allineano a standard diversi. L'interoperabilità con GnuPG è limitata a ciò che definiscono l'applicazione card OpenPGP e CCID. Altre funzionalità sono implementate nel firmware (e talvolta negli strumenti host Galdra) ma non sono invocabili tramite i flussi di lavoro standard gpg per le card.
Per il comportamento quotidiano della card, fai affidamento su docs/OPENPGP_CARD.md. Per le funzionalità solo vault o uniche del token, usa il firmware di questo repository e la documentazione dello strumento Galdra.
Gli stack OpenPGP card e GnuPG non definiscono la condivisione segreta di Shamir (SSS) per le chiavi o per lo sblocco del disco. SSS è comunque utile insieme alla crittografia normale: non sostituisce quasi mai il cifrario simmetrico sul disco — protegge il piccolo segreto (chiave master o passphrase) che sblocca quella crittografia.
Pattern (sempre la stessa idea):
1. LUKS (Linux) e SSS esterno
LUKS cifra il volume con una chiave master. Puoi estrarre quella chiave (o un segreto di key-slot, a seconda della procedura), dividerla con uno strumento SSS e memorizzare le parti separatamente. Al momento dello sblocco, combina K parti, ricostruisci il materiale di chiave e fornisci a cryptsetup (vedi la documentazione della tua distribuzione; una gestione errata delle chiavi può bloccare l'accesso).
Esempio di forma usando le utility ssss ("Shamir's Secret Sharing Scheme") (nomi e pacchettizzazione variano per sistema operativo):```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) utilizza Shamir per l'**unseal**: la chiave di crittografia dello storage viene suddivisa in fase di init (ad es. 3 operatori su 5 detengono ciascuno una parte). Dopo un riavvio, devono essere inserite **K** parti per eseguire l'unseal. Lo stesso schema **K-of-N su un segreto master** di LUKS, applicato a un secrets engine anziché a un block device.
**3. Firmware Galdralag (`vsss-rs`)**
Questo repository utilizza [`vsss-rs`](https://crates.io/crates/vsss-rs) (ecosistema RustCrypto) per Shamir on-device. Lo stesso **layering** si applica se lo si allinea alla crittografia bulk:
- Generare una chiave master casuale a 256 bit (o di dimensione appropriata).
- Crittografare il drive o lo storage bulk con **AES-GCM** o **ChaCha20-Poly1305** usando quella chiave (questo corrisponde alle crate simmetriche sottoposte ad audit del workspace).
- Usare `vsss-rs` per suddividere la chiave master in **N** parti con soglia **K**.
- Conservare le parti negli slot del vault, su altri dispositivi o presso i detentori delle chiavi.
- All'avvio o in fase di recovery, raccogliere **K** parti, ricostruire, quindi usare **HKDF** (o la propria policy) per sottochiavi domain-separated se necessario.
**4. VeraCrypt**
VeraCrypt non implementa SSS internamente. Lo stesso schema **esterno** si applica: suddividere la **passphrase o il materiale dei keyfile** con uno strumento SSS; non tentare di fare Shamir-split del ciphertext del volume.
### Schema ibrido (dati di grandi dimensioni)
SSS è pensato per **piccoli segreti** (dimensione della chiave). **Non** si applica Shamir a ciphertext di molti gigabyte. Il layering usuale:```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)
Questo si allinea con ciò che questo progetto già impila: aes-gcm / chacha20poly1305 per i dati a riposo, vsss-rs per la suddivisione del segreto master, hkdf per la derivazione dopo la ricostruzione.
| Decisione | Opzioni tipiche |
|---|
La gestione operativa delle chiavi per LUKS e la crittografia completa del disco è sensibile dal punto di vista della sicurezza; seguire le linee guida del fornitore e della distribuzione e i modelli di minaccia per il proprio ambiente.
Autorizzazione a due chiavi hardware / quorum (che richiede due token fisici separati
o detentori di parti prima di un'operazione critica) è un pattern di estensione supportato,
non una funzionalità del firmware. Galdralag fornisce primitive Shamir K-di-N
(vault::shamir, galdra shamir)
e autenticazione OpenPGP a token singolo; un wrapper LUKS a valle, un pannello
di accesso o un demone personalizzato deve imporre il quorum, le finestre di sessione e la
ricostruzione sicura. Quel confine, i flussi di lavoro di riferimento 2-di-N e le note di sicurezza per
gli integratori sono in docs/DUAL_KEY_QUORUM.md. Questo è
possibile con le primitive esistenti oggi; l'orchestrazione è intenzionalmente lasciata al
consumatore — non un impegno di roadmap da parte di questo repository.
Un pattern concreto è un drive o volume crittografato utilizzando curve Brainpool dove il proprio stack le richiede (ad esempio ECDH/ECDSA attorno a un segreto master), combinato con Shamir's Secret Sharing sul materiale chiave che sblocca quella crittografia (lo stesso layering di piccoli segreti di cui sopra: SSS protegge la chiave, non il ciphertext multi-gigabyte). Se e quando firmware e software host che implementano questo flusso di lavoro sono stati sottoposti a audit indipendente, tale combinazione può essere preziosa per le organizzazioni che devono soddisfare policy di quorum e profili crittografici nazionali allo stesso tempo.
Perché le curve Brainpool (ad es. BrainpoolP256r1, BrainpoolP384r1) sono spesso discusse in quel contesto:
Scenari in cui la combinazione di SSS con crittografia di classe Brainpool risponde a esigenze istituzionali (illustrativo; non consulenza legale o di conformità):
Se la firma OpenPGP in stile Governikus o l'attestazione eID nazionale supportata da chip comparabile non è disponibile o pratica per la propria giurisdizione o flusso di lavoro, Web of Trust e Key Signing Parties descrive un approccio alternativo lato host basato su verifica di persona e firme di terze parti sui certificati.
Autenticazione della chiave pubblica OpenPGP di Governikus è un servizio online gestito per conto del BSI (Ufficio federale tedesco per la sicurezza delle informazioni). Dopo che il mittente si autentica con una carta d'identità abilitata eID tedesca, una carta eID UE per cittadini UE o un permesso di soggiorno elettronico, il servizio verifica che il nome legale autenticato corrisponda allo User ID OpenPGP sulla chiave pubblica caricata. Se corrisponde, Governikus firma quella chiave pubblica con la chiave di firma del servizio così che terze parti possano verificare l'attestazione.
Un flusso di lavoro pratico con questo firmware: generare una chiave asimmetrica Brainpool sul token (generazione della carta OpenPGP come al solito), esportare la chiave pubblica o il certificato sull'host, completare il flusso di invio a Governikus inclusa l'autenticazione eID (tipicamente AusweisApp e lettura NFC della carta) e utilizzare la chiave pubblica firmata restituita dal servizio (ad esempio dalla distribuzione via e-mail). La chiave privata rimane su Galdralag per tutto il tempo.
Nessun percorso sostituisce l'altro. eID e il passaggio Governikus legano la chiave pubblica all'identità verificata tramite il chip al momento dell'invio; non forniscono forward secrecy, Shamir K-di-N per il materiale chiave a lungo termine o profili cipher per dati in blocco — queste sono funzionalità specifiche del firmware descritte altrove in questo README. Il chip eID e il processo di emissione circostante inoltre non implementano, da soli, il comportamento ECDH effimero e a cascata del token. Al contrario, una chiave OpenPGP Brainpool generata sul dispositivo si allinea con il contesto di implementazione BSI/UE già discusso per uso istituzionale di Brainpool, ma senza un passaggio di attestazione esterno i corrispondenti devono fare affidamento su altri mezzi per collegare un'impronta digitale a una persona giuridica.
| Livello | Ruolo |
|---|---|
| Chiave pubblica OpenPGP (ad es. Brainpool su Galdralag) | Struttura crittografica e controllo della chiave privata sul token; le scelte delle curve seguono le aspettative di classe BSI TR-03111 (vedere le e la discussione TR-03111 in ) |
Limitazione: La verifica è basata sul nome. Se due persone condividono lo stesso nome legale nei campi che il servizio confronta, l'attestazione non le distingue; conferma il collegamento dell'identità a quel nome al momento dell'attestazione, non l'unicità globale. Le preoccupazioni OpenPGP di routine (associazione e-mail, rotazione delle chiavi, revoca) rimangono in vigore.
Allineamento delle policy: lo stesso BSI che definisce le linee guida tecniche relative a Brainpool (BSI TR-03111; vettori di conformità sotto crates/vault/tests/bsi_vectors/) sostiene anche il processo di firma eID di Governikus, il che spesso è rilevante in contesti tedeschi e UE dove Brainpool è già richiesto o preferito — vedere Shamir più Brainpool: esempio e adattamento istituzionale.
Ambito più ampio (nota di ricerca, non un'indagine completa): Lo stesso pattern — legare una chiave pubblica OpenPGP a un'identità verificata dal chip — è applicabile in linea di principio ovunque esista eID nazionale; quali fornitori offrono un passaggio di firma simile a Governikus e con quali regole è una questione separata che vale la pena indagare man mano che le implementazioni si espandono. Altri stati membri UE gestiscono ecosistemi eID basati su carta sotto eIDAS che potrebbero supportare ancore di fiducia comparabili o più forti del solo percorso tedesco; questo README non le cataloga.
Estonia e Belgio hanno entrambi adottato NIST P-384 sul chip piuttosto che Brainpool, mentre il profilo BSI del settore pubblico tedesco è incentrato su Brainpool (vedere sopra). Galdralag supporta già Brainpool e NIST P-256/P-384 sulla carta OpenPGP (docs/OPENPGP_CARD.md); RSA in questo repository è un helper di libreria galdr-vault, non uno slot di carta funzionante (Asymmetric / key agreement). Lo stesso pattern di ancora di fiducia non dipende solo dall'abbinamento della preferenza di curva tedesca.
Fuori dall'UE/SEE, il pattern di ancora di fiducia basato su carta è più difficile da applicare: gli USA hanno una carta con chip (PIV) ma è limitata al personale federale e si trova in X.509/FPKI, non integrata con OpenPGP; il Canada non ha una carta di firma nazionale sul chip nel senso usato sopra. Ciò limita il pattern principalmente alle giurisdizioni con credenziali governative su chip emesse universalmente — l'area eIDAS UE è dove il modello è attualmente più forte.
Quando e se l'hardware raggiunge uno stato pronto per il consumatore, le persone che vogliono che Shamir's Secret Sharing e lo scambio di chiavi effimero autenticato diventino parte del comportamento interoperabile OpenPGP / GnuPG (invece di sole funzionalità specifiche del firmware) dovrebbero guidare il cambiamento di standard e implementazione altrove. Questo repository non parla a nome dell'IETF o di GnuPG; i luoghi sotto sono dove tali emendamenti vengono normalmente perseguiti.
CESS — Cryptologically Enchanted Shamir's Secret — è uno standard crittografico aperto per la condivisione di segreti a soglia insieme a crittografia autenticata indipendente dal cipher, avvolgimento delle parti basato su password e scambio di chiavi ibrido post-quantum opzionale. Il repository CESS contiene la specifica normativa, il registro degli algoritmi, i vettori di test e il runner di conformità.
Questo firmware è conforme a CESS per le costruzioni implementate qui: le regole interoperabili di condivisione e involucro della specifica si affiancano agli stessi temi Shamir, Brainpool e profilo cipher descritti altrove in questo README. Il testo normativo è separato da questo repository; postura di conformità (cosa corrisponde alla specifica, cosa differisce mantenendo algoritmi come AES e SHA-256 nei profili e la roadmap verso una interoperabilità più forte): docs/CESS_CONFORMANCE.md.
Se i manutentori di questo repository GitHub non rispondono a issue, pull request o e-mail, puoi comunque far avanzare nuovi cipher, comportamento OpenPGP e lavoro relativo agli standard nell'ecosistema più ampio. Sequoia PGP è uno stack OpenPGP indipendente basato su Rust (sicurezza della memoria, design library-first, partecipazione attiva a IETF/ecosistema) dove avviene gran parte dello sviluppo pubblico. Non è questo progetto; è documentato qui come percorso alternativo pratico quando l'upstream qui è silenzioso.
La pagina Contribute descrive la licenza (LGPL 2.0 o successiva per la maggior parte dei progetti), il Developer Certificate of Origin e che funzionalità commerciali più grandi possono richiedere un accordo precedente e accordi di manutenzione a lungo termine — leggere quella pagina prima di investire uno sforzo significativo.
Vale anche la pena tenere d'occhio https://autocrypt2.org/#/
Questo codebase e le app rilevanti non saranno compilati per macOS o Windows. Gli strumenti host (galdra, galdrad, galdra-gtk) e il tooling di supporto hanno come target Linux. Questa è una decisione deliberata basata sul modello di minaccia del progetto e sui requisiti di verificabilità dichiarati in tutto questo documento.
_NSAKEY scoperta in Windows NT nel 1999 ha causato notevoli controversie. Microsoft ha dichiarato che era una chiave di backup; questo non è mai stato completamente dimostrato in un senso o nell'altro.Sospettato ma non provato:
main, restricted, universe e multiverse sono firmati con la chiave GPG di Canonical.security.ubuntu.com, anch'esso firmato.I gestori di pacchetti sono generalmente sicuri, ma le installazioni di terze parti .deb / .rpm / AppImage possono essere non sicure. Preferire pacchetti firmati da repository fidati e verificare le firme prima di installare qualsiasi cosa ottenuta al di fuori di essi.
Usare una toolchain Rust stabile come pinnata in rust-toolchain.toml. Il firmware usa il target riscv32imac-unknown-none-elf; gli strumenti host usano la tripletta host.
test-hal finirebbe nelle build di produzione): ```bash
cargo run -p xtask -- check-fw
Il codice oggetto e gli archivi finiscono in target/riscv32imac-unknown-none-elf/release/. Un'immagine di sistema Xous completa e avviabile per una scheda specifica viene prodotta dal flusso di integrazione più ampio Baochip / Xous quando segui la build di quel prodotto; xtask qui esegue cargo build per le crate della libreria firmware elencate in xtask (non un singolo file pronto da flashare di per sé).
Daemon Xous CCID (galdralag-service) — richiede la toolchain Xous riscv32imac-unknown-xous-elf (non il triple firmware bare riscv32imac-unknown-none-elf di cui sopra).
Albero xous-core richiesto: le dipendenze di percorso si risolvono tramite Galdralag-firmware/xous-core/. Le build delle immagini dovrebbero usare un checkout sibling (o XOUS_CORE=) sul branch feature/usb-bao1x-ccid-openpgp (PR #937). Gli alberi annidati e sibling possono divergere; cargo run -p xtask -- check-xous-core fallisce
con codice non zero e stampa un ln -sfn <sibling> ./xous-core copiabile e incollabile (rinomina prima un checkout annidato reale se ./xous-core non è già un symlink): ```bash
ln -sfn ../xous-core ./xous-core
cargo run -p xtask -- check-xous-core
Immagine Dabao CCID che include Galdralag (il semplice dabao-ccid da solo è solo trasporto): ```bash
scripts/build_dabao_ccid_image.sh
**BaoSec + PDDB:** **`cargo run -p xtask -- build-and-register release --xous-core /path/to/xous-core`**. Dettagli: [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/main/services/galdralag/README.md). Lacune solo upstream: [docs/XOUS_CORE_UPSTREAM_REQUESTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/XOUS_CORE_UPSTREAM_REQUESTS.md).
### Flashing
Questo repository **non** include ancora un flasher con un singolo comando. La programmazione del **Baochip-1x** (JTAG, boot ROM/USB o strumenti del fornitore) segue la documentazione della scheda e del silicio. Inizia da **[Supermagnum/Baochip-1x-firmware](https://github.com/Supermagnum/Baochip-1x-firmware)**; **l'hardware della scheda di valutazione** è in **[baochip/dabao](https://github.com/baochip/dabao)** — sulla scheda Dabao, **SW2** commuta la **modalità bootloader** (vedi quello schema).
**Commit di UF2 senza il pulsante fisico di boot:** Dopo aver copiato **`loader.uf2`**, **`xous.uf2`** e **`apps.uf2`** sul volume **BAOCHIP**, puoi premere il pulsante fisico **boot** **oppure** digitare **`boot`** nella console seriale USB **boot1** (1 000 000 baud, ad es. `screen /dev/ttyACM0 1000000`). Questo evita di fare affidamento sul pulsante **boot** solo per questo passaggio. La console **si disconnette** quando digiti **`boot`**; è **previsto** (il sistema si riavvia nello stadio successivo). Su Linux, `dmesg --follow` aiuta a confermare la ri-enumerazione USB. Questo è distinto da **PROG** (tieni premuto mentre colleghi la USB per entrare nel bootloader di massa **BAOCHIP**). Vedi **[baochip/dabao#2](https://github.com/baochip/dabao/issues/2)** (chiuso).
**Flusso Xous / Baochip:** Le immagini sono **firmate Ed25519** e verificate da **boot0** prima dell'esecuzione; vedi [Firmware firmato (Ed25519, boot0)](#signed-firmware-ed25519-boot0). Per **dabao**, il layout **UF2**, tenere premuto **PROG** mentre si collega la USB per entrare in modalità di massa, e i passaggi di aggiornamento **boot1**, vedi **[Getting Started with Baochip Targets](https://github.com/betrusted-io/xous-core/blob/dev/README-baochip.md)**.
### Compilare e installare gli strumenti host (`galdra`, `galdrad`, `galdra-gtk`)
Le crate host si trovano alla radice del workspace: `galdra/`, `galdrad/`, `galdra-gtk/`.
**Ubuntu / Debian** (installare prima di `cargo build` / `cargo install`):```bash
sudo apt update
sudo apt install build-essential pkg-config libpcsclite-dev pcscd libssl-dev
# required only for `galdra-gtk`:
sudo apt install libgtk-4-dev
libpcsclite-dev soddisfa il percorso di collegamento PC/SC predefinito di galdra; pcscd è il demone che serve i lettori di smart card in fase di esecuzione. libssl-dev è richiesto affinché openssl-sys possa collegarsi (le ricerche keyserver di sequoia-net e TLS di ldap3 usano oggi native-tls). Ometti libgtk-4-dev se non compili mai galdra-gtk.
GTK 4 (solo galdra-gtk): pkg-config deve risolvere gtk4 (crate workspace gtk 0.9.x, pacchetto gtk4). Su Fedora usa gtk4-devel; su Arch gtk4.
Compila i binari di release dalla radice del repository:```bash cargo build --release -p galdra -p galdrad -p galdra-gtk
Executables: `target/release/galdra`, `target/release/galdrad`, `target/release/galdra-gtk`.
**Installazione** in `~/.cargo/bin` (regola `--path` se non sei nella root del repository):```bash
cargo install --locked --path galdra
cargo install --locked --path galdrad
cargo install --locked --path galdra-gtk
Puoi invece copiare quei tre binari in qualsiasi directory presente nel tuo PATH.
galdrad e la GUI desktop (galdra-gtk)galdra-gtk è il binario desktop GTK4 (pacchetto Cargo galdra-gtk; non esiste galdra-gui). È un front-end per l'API REST galdrad — esegui prima galdrad.
Daemon — galdrad ascolta su 127.0.0.1:8742 per impostazione predefinita (--listen lo sovrascrive); vedi galdrad/src/main.rs.```bash
galdrad
Controllo rapido: `curl -s http://127.0.0.1:8742/health` (documentazione API interattiva: **`http://127.0.0.1:8742/swagger-ui/`**.)
**GUI desktop** — **`galdra-gtk`** utilizza **`http://127.0.0.1:8742`** per impostazione predefinita (`--base-url` o **`GALDRAD_URL`**); vedere [`galdra-gtk/src/main.rs`](https://github.com/supermagnum/galdralag-firmware/blob/main/galdra-gtk/src/main.rs).```bash
galdra-gtk
galdra-gtk --base-url http://127.0.0.1:8742
GALDRAD_URL=http://127.0.0.1:8742 galdra-gtk
Da una cargo build --release fresca, senza installare: ./target/release/galdrad e poi ./target/release/galdra-gtk dalla radice del repository.
Host vs token: galdra-gtk rispecchia tutto ciò che galdrad espone via HTTP; lo sblocco del token, il provisioning e gli altri flussi CCID restano sulla CLI galdra (vedi galdra device in docs/GALDRA-TOOL.md e Tier 2c).
Rubrica contatti (galdra contact, galdrad /contacts): la creazione di un contatto richiede un'e-mail (CLI: --email; HTTP: campo JSON email). I campi opzionali includono nome visualizzato (--name / name), organizzazione (--org / org), ruolo, badge (--badge / badge), nota, nominativo radio, Fluxer, Discord e IRC id, numero di telefono (--phone-number / phone_number), oltre a (, , , ), per radioamatori e . Questi valori sono memorizzati solo nei metadati SQLite locali (non sono contro servizi esterni). di un contatto (ad esempio , percorsi /, di , id dei membri del gruppo o di ) accetta lo della riga, il , l', un (gli spazi vengono ignorati), quegli id sociali o un in quando fornito come token decimale. può rispecchiare molte delle stesse etichette su un registro in stile Fulla (, , , , , campi radio/sociali/postali e nomi — vedi ). I comandi e i limiti dei campi sono riepilogati in nelle sezioni e .
Se hai usato cargo install --path come sopra:```bash
cargo uninstall galdra
cargo uninstall galdrad
cargo uninstall galdra-gtk
Se hai copiato manualmente i binari, rimuovi i file che hai aggiunto. Il firmware non viene "installato" sull'host; la cancellazione o il reflash del dispositivo è coperto dalla documentazione hardware.
---
## Funzionalità principali
### Cosa rende unico questo token
Gli elementi seguenti sono **funzionalità del firmware Galdralag**, non requisiti dell'[applicazione OpenPGP card](#standards-vs-firmware-specific-features) o di GnuPG.
- **Modello di sicurezza pronto per tre fattori** — Il **possesso** del token USB e la **conoscenza** del PIN sono applicati nel firmware oggi; un terzo fattore **biometrico** opzionale **non** è implementato in questo repository (segnaposto: [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_API.md)). Vedi [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREE_FACTOR_AUTH.md) per ambito e limiti.
- **ECDH effimero autenticato sul dispositivo** — vera segretezza in avanti crittografica.
Ogni sessione genera una nuova coppia di chiavi effimere sul TRNG hardware del token.
La chiave a lungo termine firma l'offerta effimera ma non partecipa mai
allo scambio di chiavi. Le sessioni passate non possono essere decifrate nemmeno
con una chiave a lungo termine completamente compromessa. A conoscenza degli autori del progetto,
nessun token di sicurezza hardware commerciale offre questa funzionalità di prima classe.
- **Condivisione segreta Shamir K-of-N sul dispositivo** — la chiave a lungo termine può essere
suddivisa in N parti che richiedono K per la ricostruzione, senza che un singolo detentore possa
recuperare la chiave da solo. A conoscenza degli autori del progetto, nemmeno
un token commerciale offre questa funzionalità di prima classe. **Doppio controllo** (due
token richiesti prima che una porta si apra o un volume venga montato) **non** è applicato
qui; vedi [Quorum a doppia chiave hardware (pattern per integratori)](#dual-hardware-key-quorum-integrator-pattern).
- **Sistema di profili indipendente dal cifrario** — cifrari simmetrici, curve ECDHE e
configurazione Shamir sono combinati in profili nominati e verificabili. Per dati
bulk sotto un profilo, il testo in chiaro viene cifrato **dall'interno verso l'esterno**: puoi
impilare **fino a quattro** **diversi** AEAD simmetrici uno sopra l'altro — quindi
puoi usare **tre** cifrari indipendenti in un profilo (ad esempio
ChaCha20-Poly1305, poi Serpent-256, poi Twofish-256), o un quarto livello distinto
dove la policy lo consente — con **nessun cifrario ripetuto** nello stesso profilo
e materiale di chiave e nonce **indipendente** derivato da HKDF per ogni livello. I nomi
integrati come `standard`, `conservative` e `conservative-shamir` includono **uno
o due** livelli; stack più profondi sono per profili avanzati o personalizzati.
Regole complete e layout del wire: [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md).
Ogni selezione di profilo viene registrata nel registro di controllo.
- **BLAKE3 con chiave tra i livelli della cascata (CESS)** — Oltre al tag AEAD di ogni
livello e all'involucro esterno ChaCha20-Poly1305 **Mode A**, **CESS**
definisce integrità **BLAKE3 con chiave**-style **tra** gli stadi interni della cascata. Per
profili **mappati al registro** (`suite_id` tramite nomi integrati), **`cipher-profile`**
aggiunge un **HMAC-BLAKE3 da 32 byte** sull'output AEAD di ogni livello interno prima che
il livello successivo cifri; le chiavi sono derivate con **HKDF-BLAKE3** usando
`cess::cess_blake3_integrity_gap_info` ([`inner_info.rs`](https://github.com/supermagnum/galdralag-firmware/blob/main/crates/cess/src/inner_info.rs)).
I profili integrati **a livello singolo** saltano i tag extra; i profili **personalizzati** (senza `suite_id`)
mantengono la cascata legacy senza MAC inter-livello. Vedi
[docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md) e
[docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md). **Conteggi di combinazioni**
sotto le regole dei cifrari `cipher-profile` (**cinque** primitive AEAD, **nessun cifrario
ripetuto** in un profilo, l'ordine conta); la colonna BLAKE3 è il conteggio dello **spazio di progettazione**
CESS (on/off indipendente per ogni intervallo), non un toggle host per messaggio:
| Lunghezza cascata | Stack di cifrari distinti ordinati | × BLAKE3 opzionale on/off in ciascuno dei **length−1** intervalli tra i livelli |
|:--------------:|--------------------------------:|---------------------------------------------------------------------------:|
| 1 livello | 5 | 5 × 2^0 = **5** |
| 2 livelli | 20 | 20 × 2^1 = **40** |
| 3 livelli | 60 | 60 × 2^2 = **240** |
| 4 livelli | 120 | 120 × 2^3 = **960** |
| **Totale** | **205** | **1245** |
La cifra **205** conta **solo gli stack di cifrari** (permutazioni di 1–4 scelte
distinte tra AES-256-GCM, ChaCha20-Poly1305, Twofish-256, Serpent-256, Camellia-256). La
cifra **1245** è la stessa moltiplicata per ogni pattern **indipendente**
on/off per il BLAKE3 inter-livello opzionale (**2^(k−1)** pattern per **k**
livelli). **Questo firmware** applica MAC inter-livello per **tutti** gli intervalli quando un
profilo integrato con **`suite_id`** ha **≥ 2** livelli (non un toggle per intervallo).
I nomi dei profili integrati usano un **piccolo** sottoinsieme dei 205.
- **Volume decoy microSD opzionale** — se è montato un chip PSRAM, un LUN bulk decoy
extra può apparire dopo lo sblocco. **Se non è montata alcuna microSD, il dispositivo è
comunque un token di sicurezza hardware** (vault, policy PIN, OpenPGP/CCID e altre
funzioni del token sono invariate); solo quel volume bulk opzionale è assente. Per
host non informati, il dispositivo presenta comunque la consueta persona decoy di
mass-storage on-chip dove configurata. Il contenuto della microSD, quando presente, è intenzionalmente
non cifrato e insignificante. Il materiale chiave reale vive nella RRAM on-chip dietro
il vault e la policy PIN.
- **Stack completamente aperto** — RTL CERN-OHL-W-2.0, schemi aperti, bootloader
riproducibile, OS Rust/Xous, silicio ispezionabile con IRIS.
### Quorum a doppia chiave hardware (pattern per integratori)
**Cos'è:** Un modo per le organizzazioni di richiedere **due (o K-of-N) token fisici
separati o detentori di parti** prima che un **sistema a valle** sblocchi qualcosa
di critico — dischi cifrati, sessioni di amministrazione **firewall o server**, **vault
medicinali**, porte sicure o altre azioni privilegiate.
**Cosa fornisce Galdralag:** Ogni token è **una credenziale indipendente**:
autenticazione OpenPGP card (token + PIN) e, tramite tooling host, **esportazione di parti
Shamir** del materiale chiave a lungo termine ([`vault::shamir`](https://github.com/supermagnum/galdralag-firmware/blob/main/crates/vault/src/shamir.rs),
[`galdra shamir`](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md)). **Identità pubbliche** stabili (impronte
OpenPGP, seriali del token) supportano registri di controllo di **quale chiave è stata usata, quando**.
**Cosa Galdralag non fornisce:** Il firmware e gli strumenti host **non bloccano**
firma, decifratura o sblocco finché due token non sono presenti insieme. **Applicazione del
quorum**, finestre temporali di sessione, ambiente di ricostruzione sicuro e
**registri di accesso** a prova di manomissione sono compito dell'**integratore** — demone di sblocco LUKS,
gestione degli accessi privilegiati (PAM), software per porte/pannelli o gateway di policy personalizzato.
**Pattern tipico:** Suddividi un segreto master di sblocco **2-of-3** (o simile); il custode
A detiene la parte 1 sul token A, il custode B detiene la parte 2 sul token B; al momento dello sblocco
il gateway raccoglie **K** parti o **K** firme del token, ricostruisce o autorizza
**una volta**, poi azzera il segreto. Alternativa: due operazioni OpenPGP **SIGN**
su una sfida entro una finestra temporale, senza ricostruzione Shamir.
Questo è un **pattern di estensione supportato** che usa primitive esistenti — **non** una
funzionalità di prodotto fornita e **non** un impegno di roadmap. Progettazione, confini
di responsabilità, note di sicurezza e registrazione della responsabilità: [docs/DUAL_KEY_QUORUM.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DUAL_KEY_QUORUM.md).
Vedi anche [Condivisione segreta Shamir e cifratura del drive](#shamir-secret-sharing-and-drive-encryption)
e [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/AUDIT_LOG.md).
### Funzionalità crittografiche
Tutte le primitive provengono da dipendenze del workspace sottoposte a audit indipendente.
Nulla è implementato in-tree.
#### Asimmetrico / scambio di chiavi
| Algoritmo | Standard | Note |
|-----------|----------|-------|
| BrainpoolP256r1 ECDH + ECDSA | RFC 5639, BSI TR-03111 | Standardizzato BSI, nessun coinvolgimento NSA |
| BrainpoolP384r1 ECDH + ECDSA | RFC 5639, BSI TR-03111 | Sicurezza ~192-bit |
| X25519 ECDH | RFC 7748 | |
| Ed25519 firma / verifica | RFC 8032 | |
| RSA-2048 / 3072 / 4096 OAEP, PSS, PKCS#1 v1.5 firma/verifica | RFC 8017 | Solo libreria `galdr-vault` (minimo 2048-bit). Cifratura/decifratura OAEP-SHA256; firma/verifica PSS SHA-256/SHA-512; firma/verifica PKCS#1 v1.5 dietro un marcatore `Pkcs1v15` in-source (solo interoperabilità legacy, non per nuovi progetti di protocollo). **Non** raggiungibile tramite l'applicazione OpenPGP card — SIG/DEC/AUT non operano su RSA; vedi [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md). |
| P-256, P-384 | NIST | Tramite dipendenze workspace `p256` / `p384` |
#### Simmetrico / AEAD
| Algoritmo | Standard | Note |
|-----------|----------|-------|
| AES-256-GCM | FIPS 197, NIST SP 800-38D | AES hardware su Baochip-1x |
| ChaCha20-Poly1305 | RFC 8439 | Nessun coinvolgimento NSA |
| Twofish-256 | Schneier et al. 1998 | Finalista AES, nessun coinvolgimento NSA |
| Serpent-256 | Anderson / Biham / Knudsen 1998 | Finalista AES, 32 round, margine conservativo |
#### Derivazione chiave / MAC / digest
| Algoritmo | Standard |
|-----------|----------|
| 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 |
| Famiglia SHA-3 | FIPS 202 |
| BLAKE2b / BLAKE2s | RFC 7693 |
| BLAKE3 | Specifica BLAKE3 |
#### Gestione delle chiavi
| Funzionalità | Note |
|---------|-------|
| Condivisione segreta Shamir K-of-N | `vsss-rs` — suddivisione e recupero sul dispositivo |
| ECDH effimero autenticato | Protocollo di sessione con segretezza in avanti — crate `ephemeral-session` |
| Sistema di profili di cifrario | **Cascata** simmetrica: **fino a quattro** AEAD diversi impilati (ad es. **tre** livelli indipendenti); chiavi per livello — `cipher-profile` — [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md) |
### Proprietà di sicurezza
| Proprietà | Implementazione |
|----------|---------------|
| Segretezza in avanti | ECDH effimero: la chiave a lungo termine firma solo, non concorda mai |
| Contatore PIN prima del confronto | Contatore scaricato in RRAM prima di `subtle::ConstantTimeEq` — nessuna eccezione |
| Zeroizzazione hardware | Sovrascrittura multi-pass da TRNG; boot0 azzera prima dell'enumerazione USB |
| Nessun segreto sul bus USB | L'host non informato vede solo mass-storage standard; nessuna impronta possibile |
| Evidenza di manomissione monotona | Contatori hardware unidirezionali nel dominio always-on |
| Autenticazione a tre fattori | **Possesso:** token USB; **conoscenza:** PIN sul dispositivo (`pin-policy`); **biometrico** opzionale non implementato — [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREE_FACTOR_AUTH.md) |
| Contatori RRAM e registro di controllo | HAL monotono per PIN (e future firme PQ con stato); record di audit dei profili e hook di audit OpenPGP in-RAM — registro di audit NV append-only **non** implementato — [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/AUDIT_LOG.md), [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md) |
| Operazioni a tempo costante | Tutti i confronti di segreti tramite `subtle`; verificati da harness dudect |
| test-hal mai in produzione | Applicato da `check-fw` (firmware) e `check-host` (binari host di release) |
### Policy PIN
- Lunghezza minima: **5 caratteri alfanumerici** — applicata al confine del parser,
prima che venga chiamato `pin-policy`. Input brevi non incrementano il contatore.
- Soglia di tentativi predefinita: **3** (configurabile **3–10** al provisioning).
Corrisponde allo standard industriale dei token hardware (Nitrokey, YubiKey, ISO 7816).
- Al raggiungimento della soglia: zeroizzazione hardware completa attivata.
- Passphrase challenge/response (percorso host informato USB): minimo 5 caratteri,
trasmessa solo come `HMAC-SHA256(HostChallengeKey, nonce || passphrase)`.
**Impostazione o regolazione della soglia di tentativi:** Il limite del contatore viene scritto quando il token viene **provisionato per la prima volta**; **non** è un'impostazione `gpg` a runtime. Usa lo strumento host **`galdra`** dopo averlo [compilato](#compile-and-install-host-tools-galdra-galdrad-galdra-gtk):```bash
galdra device provision --pin-attempts 5
| Flag | Intervallo | Predefinito | Significato |
|---|---|---|---|
--pin-attempts |
Ometti entrambi i flag per mantenere i valori predefiniti (3 tentativi, minimo 5 caratteri). Esempio con entrambi: galdra device provision --pin-attempts 7 --min-pin-length 8.
La policy è memorizzata sul token (vault policy). Lo strumento host non può aumentare o ridurre la soglia dopo il provisioning senza passare dal flusso di gestione autenticato del dispositivo stesso; considera il provisioning come il momento per scegliere 3–10 in base al tuo modello di minaccia. La motivazione (predefiniti vs limiti più alti) è spiegata in dettaglio in docs/GALDRA-TOOL.md nella sezione sulla policy PIN.
XMSS (RFC 8391, NIST SP 800-208) e LMS/HSS (RFC 8554, NIST SP 800-208)
sono implementati dietro --features pq-signatures. I crate Rust sottostanti
non sono stati sottoposti ad audit indipendente. Vedi
docs/PQ_SIGNATURES.md e
docs/STATEFUL_SIG_STATE.md.
Questi algoritmi sono standardizzati dal NIST. L'implementazione è bloccata in attesa
che un crate Rust no_std sottoposto ad audit indipendente diventi disponibile.
Nota su libcrux: Un articolo accademico del 2026 ha identificato bug a livello di specifica nelle implementazioni ML-KEM e ML-DSA formalmente verificate di libcrux, incluse dimostrazioni rese non valide. Controlla il changelog di libcrux prima di valutarlo.
BIKE è stato eliminato dalla standardizzazione NIST a marzo 2025 a favore di HQC. La crittografia NTRU è stata eliminata a luglio 2022. Nessuno dei due ha un percorso verso uno standard NIST.
L'implementazione dell'azzeramento è corretta a livello software ma non verificata a livello hardware.
È stata testata solo tramite simulazione test-hal. La verifica fisica su
silicio Baochip-1x (ispezione della memoria JTAG, resilienza ai cicli di alimentazione, conferma
tramite canali laterali) non è stata ancora eseguita. Vedi
docs/HARDWARE_VERIFICATION.md. L'ordine delle regioni e gli ancoraggi di layout previsti
per i sottosistemi del vault sono riassunti in
docs/RRAM_LAYOUT.md; l'ordine di cancellazione fisica rimane
un lavoro di integrazione specifico della piattaforma e di boot0.
| Campo | Scopo | Host (SQLite galdra) | Store contatti on-chip | Formato / limite |
|---|
| ID contatto | Chiave primaria host stabile | Sì | No | Testo (id in SQLite) |
| Nome visualizzato | Etichetta leggibile dall'uomo | Sì | Sì | Stringa UTF-8; 240 byte max per campo heap su chip |
| Indirizzo di posta principale | Sì | Sì | Stringa UTF-8; ricerca su chip tramite scansione e-mail | |
| Indicativo | Indicativo radioamatoriale | Sì | Sì | 12 byte, riempito con NUL; ricerca su chip |
| ID abbonato DMR | ID radio DMR | Sì | Sì | 32 bit senza segno (0 = assente); ricerca su chip |
| Numero badge | ID dipendente o badge | Sì | Sì | Stringa UTF-8 |
| Organizzazione | Agenzia o datore di lavoro | Sì | Sì | Stringa UTF-8 |
| Dipartimento | Team o unità | Sì | Sì | Stringa UTF-8 |
| Ruolo | Etichetta di lavoro o funzione | Sì | Sì | Stringa UTF-8 |
| Nota | Commento libero | Sì | Sì | Stringa UTF-8 |
| Affiliazione radio | Etichetta di club, rete o alleanza | Sì | Sì | Stringa UTF-8 |
| Via | Riga dell'indirizzo stradale | Sì | Sì | Stringa UTF-8 |
| Paese | Nome o codice del paese | Sì | Sì | Stringa UTF-8 |
| Codice postale | CAP o codice postale | Sì | Sì | Stringa UTF-8 |
| Regione | Stato, contea o regione | Sì | Sì | Stringa UTF-8 |
| ID Fluxer | Handle o ID Fluxer | Sì | Sì | Stringa UTF-8 |
| ID Discord | ID utente Discord | Sì | Sì | Stringa UTF-8 |
| ID IRC | Nick IRC o simile | Sì | Sì | Stringa UTF-8 |
| Numero di telefono | Numero di contatto vocale o SMS | Sì | No | Stringa UTF-8; max 32 caratteri su host; dichiarato dal mittente, non verificato |
| Impronta | Ancoraggio della chiave (ricerca, sincronizzazione) | Sì (pgp_fingerprint) | Sì | 32 byte; stile OpenPGP v4 sul wire; non è la stessa cosa di un'impronta dispositivo G: |
| Chiave pubblica | Materiale di crittografia / verifica | Sì (pgp_pubkey) | Sì (regione chiavi) | Algoritmo: Ed25519, X25519, Brainpool P-256/P-384/P-512, NIST P-256/P-384, RSA-2048/3072/4096; blob fino a 768 byte su chip |
| Chiave protetta da PIN | La chiave richiede sblocco PIN | L'host memorizza le chiavi OpenPGP separatamente | Sì | Digest del verificatore PIN + metadati di wrapping AES-GCM su chip |
| Ultimo recupero | Quando il materiale della chiave è stato aggiornato | Sì (fetched_at) | Sì (last_fetched) | UTC su host; timestamp 32 bit su chip |
| Scadenza | Tempo di scadenza della chiave | Sì | No | Datetime UTC solo in SQLite |
| Sorgente chiave | Come è stato creato il record host | Sì (source) | No | es. manuale, keyserver, WKD, LDAP, file, peer |
| Provenienza campo | Etichetta di fiducia per campo di metadati | No | Sì (source_map) | Due bit per campo: SelfAttested, HostVerified, RegistrySync, OobVerified |
| Flag record | Attivo, obsoleto, identità propria, revocato | Parzialmente (logica host) | Sì | es. STALE, SELF_KEY su chip |
fuzz/README.mdtest-all --no-dudect: Salta la suite di timing dudect (~15–20 minuti). La CI delle pull request usa questo flag. Eseguite cargo run -p xtask -- timing-test o test-all senza --no-dudect per il gate di timing. La CI settimanale (test-all-full) esegue comunque dudect.docs/TEST_RESULTS.md per ciò che è in ambito.| Campo metadati | OpenPGP / GnuPG | Chiave Galdra (host + contact store) |
|---|
| ID contatto / record | No (usa ID chiave o impronta) | Sì (SQLite id sull'host; non sul chip) |
| Nome visualizzato | Solo dentro il testo User ID (Nome <email>) | Sì (campo UTF-8 separato) |
| Solo dentro il testo User ID | Sì (campo separato; ricerca per e-mail sul chip) | |
| Indirizzo | Nessun campo standard | Sì |
| Paese | Nessun campo standard | Sì |
| CAP / codice postale | Nessun campo standard | Sì |
| Regione / stato | Nessun campo standard | Sì |
| Organizzazione | Nessun campo standard | Sì |
| Dipartimento | Nessun campo standard | Sì |
| Ruolo / titolo di lavoro | Nessun campo standard | Sì |
| Badge / ID dipendente | Nessun campo standard | Sì |
| Callsign | Nessun campo standard | Sì (12 byte, riempito con NUL sul chip) |
| ID abbonato DMR | Nessun campo standard | Sì (32-bit; ricerca sul chip) |
| Affiliazione radio | Nessun campo standard | Sì |
| ID Fluxer | Nessun campo standard | Sì |
| ID Discord | Nessun campo standard | Sì |
| ID IRC | Nessun campo standard | Sì |
| Numero di telefono | Nessun campo standard | Sì (solo SQLite host) |
| Nota libera | Nessun campo standard | Sì |
| Impronta OpenPGP v4 | Sì (40 caratteri esadecimali) | Opzionale sulla riga host quando si collega un certificato (pgp_fingerprint); 32 byte sul chip per chiavi Galdra |
Impronta dispositivo G: | No | Sì (BLAKE3-160 sulla chiave pubblica SIG; strumento host; non il valore OpenPGP v4) |
| ID chiave OpenPGP | Sì (forma breve / lunga) | No |
| Fiducia / provenienza | Firme WoT sugli User ID | Etichette per campo: SelfAttested, HostVerified, RegistrySync, OobVerified (sul chip) |
| Scadenza chiave | Sì (certificato / sottochiave) | Solo host (expires_at in SQLite) |
| Ultimo tempo di recupero chiave | Dipende dagli strumenti host | Sì (fetched_at / last_fetched) |
| Chiave privata sul token | Slot carta SIG, DEC, AUT | Regione chiave Galdra separata (non pacchetti User ID) |
| PIN per usare la chiave privata | PW1 / PW3 (carta OpenPGP) | Avvolgimento PIN opzionale per record di contatto Galdra |
| Oggetto carta OpenPGP (non nella tabella sopra) | Host (GnuPG) | Sul token |
|---|
| Chiave primaria + sottochiavi SIG / DEC / AUT | Pubblica nel keyring | Privata in slot sigillati |
| Firme di certificazione (WoT) | Sì | No |
| Certificato di revoca | Sì | No |
| Attributi algoritmo (DO 0xC1 / 0xC2 / 0xC3) | gpg --card-edit | Sì |
galdragaldra-core-host| Ambito | Standard / documento tipico | Esposto come card OpenPGP standard + GnuPG? |
|---|
| Applicazione card OpenPGP — APDU, PIN, slot SIG/DEC/AUT, generazione/firma/decifratura sulla card | Specifica della card OpenPGP (vedi docs/OPENPGP_CARD.md) | Sì — stesso stack host delle altre smart card OpenPGP (gpg, scdaemon, CCID) |
| USB CCID — comunicazione con il dispositivo come lettore di smart card | Classe di dispositivo USB CCID | Sì — driver di classe |
| Formato messaggio OpenPGP — file cifrati, posta, pacchetti di chiavi | RFC 4880 (e aggiornamenti) | Sì sull'host — GnuPG lo usa; la card non analizza la posta |
| Shamir K-of-N — divisione / recupero del materiale di chiave a lungo termine nel vault | Non nella specifica della card OpenPGP; non in GnuPG | No — solo firmware e strumenti di provisioning; non un'operazione gpg --card-edit (vedi Shamir e crittografia dell'intero disco) |
| Doppia chiave hardware / autorizzazione a quorum — due (o N) token richiesti prima che un consumer agisca (sblocco disco, apertura porta, operazioni privilegiate) | Non nella specifica della card OpenPGP | No — pattern di estensione supportato per integratori che usano Shamir e/o più autenticazioni OpenPGP; l'applicazione spetta al sistema a valle (docs/DUAL_KEY_QUORUM.md) |
| ECDH effimero autenticato — protocollo di sessione a segreto in avanti sul token | Non nella specifica della card OpenPGP | No — specifico del token; non un comando card GnuPG |
| Sistema di profili cifrari — cascate simmetriche con nome (cifrari indipendenti impilati uno sull'altro; fino a quattro livelli, tre è una profondità supportata) e policy correlate | Non nella specifica della card OpenPGP | No — firmware / strumenti token host |
| Decoy microSD / personaggi mass-storage — comportamento USB su host non informati | Non nella specifica della card OpenPGP | No — percorsi di codice separati per la personalità USB |
| WebAuthn / FIDO2 | CTAP / WebAuthn | Non implementato — standard diverso dalla card OpenPGP |
| Livello | Ruolo |
|---|
| Disco | Cifrato con una chiave master (es. AES-256 tramite LUKS, VeraCrypt o un livello a blocchi grezzo) |
| Chiave master | Divisa con SSS in N parti, soglia K-of-N |
| Parti | Detenute da persone, dispositivi o archivi offline; K parti insieme ricostruiscono la chiave master |
| Sblocco | Ricostruisci la chiave, poi passala a cryptsetup, veracrypt o al tuo stack |
| Soglia | 2-di-3 (piccolo team, una certa ridondanza); 3-di-5 (comune nelle organizzazioni) |
| Archiviazione delle parti | Token hardware, macchine separate, carta, siti geograficamente separati |
| Protezione delle parti | Crittografare ogni parte per un destinatario specifico (ad es. con la sua chiave OpenPGP) prima della distribuzione |
| Dove ricostruire | Macchina air-gapped, policy HSM, o ambiente controllato — non su host condivisi non fidati |
| Scenario | Perché SSS più curve forti e allineate alle policy sono importanti |
|---|
| Un dipendente se ne va o muore | Il recupero rimane possibile senza il segreto esclusivo di quella persona |
| Accesso legale dovuto processo | Può essere richiesto un quorum — nessuna singola parte detiene il segreto di sblocco completo |
| Escrow aziendale delle chiavi | Suddivisione verificabile; nessun singolo amministratore ha accesso completo |
| Sequestro hardware | I supporti possono essere catturati senza catturare K delle N parti |
| Allineamento normativo (UE / BSI) | Brainpool soddisfa molti requisiti crittografici governativi tedeschi e UE |
| Firma Governikus | Conferma che il nome sul certificato corrispondeva all'identità autenticata dal chip quando l'utente ha completato il flusso |
| Giurisdizione | Stato toccato in questo documento |
|---|
| Germania | Flusso Governikus/BSI descritto sopra |
| Estonia | eID basata su chip. Migrata da RSA a ECDSA NIST P-384 (secp384r1) nel 2017–2018 dopo che la vulnerabilità ROCA ha costretto all'abbandono completo di RSA (il chip non poteva generare chiavi RSA sicure e non aveva un percorso verso dimensioni di chiave maggiori). La chiave privata è vincolata all'hardware e non può essere letta dalla carta. Nessun servizio di firma OpenPGP in stile Governikus trovato. |
| Belgio | eID basata su chip. Le carte più vecchie usavano RSA a 1024 bit; le carte più recenti (applet 1.8 in poi) usano ECDSA NIST P-384. Ecosistema middleware open source attivo (eid-mw, OpenSC). Nessun servizio di firma OpenPGP in stile Governikus trovato. |
| Norvegia | Il chip della carta d'identità nazionale (emessa dal 2020) è compatibile ICAO 9303 e implementa solo un chip documento di viaggio; non porta alcuna funzione di firma eID. La firma eID è separata: fornitori privati accreditati (Buypass, Commfides) sotto SEID, storicamente RSA a 2048 bit, in transizione a RSA a 3072 bit con ECC introdotto in SEID 2.0. Nessun servizio di firma OpenPGP in stile Governikus. Il chip di viaggio e la eID di firma sono distinti — rilevante se qualcuno cerca di usare solo il chip della carta direttamente. |
| Austria | Parzialmente indagato. eID usa ECC (confermato); la curva specifica non confermata nelle fonti disponibili. Modello multi-token Bürgerkarte piuttosto che una singola carta; in gran parte migrato a un'app mobile. Necessaria ulteriore indagine sui dettagli della curva e su qualsiasi servizio di firma OpenPGP. |
| USA | Carta PIV (Personal Identity Verification, FIPS 201 / NIST SP 800-78): emessa solo a dipendenti e appaltatori federali — non una carta civile universale. Algoritmi: NIST P-256 obbligatoria per le chiavi di autenticazione; P-256 o P-384 per firma/gestione chiavi; RSA 2048/3072 anche consentito; solo curve NIST, nessuna Brainpool. La radice di fiducia è la Federal Common Policy CA (FCPCAG2), non inclusa nei trust store commerciali standard. Nessun servizio di firma OpenPGP in stile Governikus trovato; FPKI è un'infrastruttura X.509 separata da OpenPGP. PIV essendo solo federale significa che non è un'ancora di fiducia civile come la eID tedesca. |
| Canada | Nessuna carta d'identità nazionale basata su chip con chiavi di firma sul chip. L'identità digitale è frammentata tra schemi provinciali (ad esempio BC Services Card), app mobili (ad esempio eID-Me) e un quadro federale in evoluzione di credenziali digitali. Nessuna singola carta paragonabile al modello tedesco, estone o belga. Nessuna infrastruttura di carta equivalente trovata — non un'ancora di fiducia praticabile in questo senso. |
| Altri paesi | Non indagati |
| Obiettivo | Da dove iniziare |
|---|
| Panoramica del progetto, notizie, community | sequoia-pgp.org |
| Contribuire (issue, correzioni, funzionalità, documentazione); contattare prima di lavori di grandi dimensioni | Contribute, Contact |
Documentazione per sviluppatori — superficie API per estendere l'implementazione (sequoia-openpgp e crate correlate) | Docs — ad es. sequoia-openpgp su docs.rs |
| Codice sorgente e tracker | gitlab.com/sequoia-pgp (libreria core e strumenti); github.com/sequoia-pgp (mirror / repository selezionati); Projects |
| Nuovi algoritmi nello standard OpenPGP | Passano ancora attraverso il gruppo di lavoro IETF OpenPGP. Sequoia e altre implementazioni implementano draft e RFC; proporre modifiche al protocollo lì e coordinarsi con gli implementatori (incluso Sequoia) affinché il comportamento corrisponda alla specifica. |
streetcountrypostal_coderegiondmr_idradio_affiliationgaldra contact showPATCHDELETEGET /contacts/{id}galdradrecipientPOST /decryptgaldra keyserver pushorganisationrolenotebadge_numberphone_numbergaldra keyserver push --help| 3–10 |
| 3 |
| Tentativi PIN errati consentiti prima del blocco / azzeramento |
--min-pin-length | 5–32 | 5 | Lunghezza minima del PIN utente (alfanumerico) memorizzata nella policy |
| Algoritmo | Standard | In attesa di |
|---|
| ML-KEM | FIPS 203 | Crate Rust no_std sottoposto ad audit |
| ML-DSA | FIPS 204 | Crate Rust no_std sottoposto ad audit |
| SLH-DSA | FIPS 205 | Crate Rust no_std sottoposto ad audit |
| FN-DSA (FALCON) | Bozza FIPS 206 | Finalizzazione dello standard + crate sottoposto ad audit |
| HQC | Bozza ~2027 | Finalizzazione dello standard + crate sottoposto ad audit |