supermagnum/galdralag-firmwareEin Versuch eines kryptografischen Frameworks für Baochip-1x.
Dieses Projekt ist beim Open Invention Network (OIN) registriert. OIN ist ein defensives Patent-Pool: Mitglieder lizenzieren Linux-bezogene Patente gegenseitig, sodass Teilnehmer Open-Source-Software mit reduziertem Patentrisiko ausliefern und nutzen können.
Status: Warte auf Hardware für Tests. https://www.crowdsupply.com/baochip/dabao/updates/our-campaign-has-launched
galdra, galdrad, galdra-gtk)galdrad und das Desktop-GUI (galdra-gtk) ausführen](#ausführen-von-galdrad-und-dem-desktop-gui-galdra-gtk)Firmware für Baochip-1x (Dabao-Evaluierungsboard)-Geräte, die auf dem
Xous-Mikrokernel läuft,
erstellt für riscv32imac-unknown-none-elf.
Sie befindet sich hier: https://www.baochip.com/
Das Gerät ist ein Hardware-Sicherheitstoken in derselben Kategorie wie Nitrokey-Geräte, mit OpenPGP-Smartcard-ähnlichem Verhalten und einem verschlüsselten Tresor. Der gesamte Hardware-Stack – RTL, Schaltpläne, Bootloader, Betriebssystem – ist Open Source und prüfbar.
Hardware-Spezifikation, Boot-Modell, Anforderungstabellen und ComboHash/PKE-Nutzung sind in Supermagnum/Baochip-1x-firmware dokumentiert. Das Dabao-Evaluierungsboard (KiCad, Schaltpläne, Schalter, Pinbelegung) ist unter baochip/dabao zu finden. Um für das Flashen in den Bootloader-Modus zu gelangen, drücken Sie SW2, um ihn umzuschalten (siehe Schaltplan dieses Repos). Architekturnotizen für dieses Repository: docs/ARCHITECTURE.md.
Das Galdra-Hosttool führt ein lokales SQLite-Verzeichnis von Empfängern (Kontakten). Jede gespeicherte Identität enthält öffentliches Schlüsselmaterial plus optionale Sidecar-Bezeichnungen (siehe Tabelle unten). Diese Tags leben in der Host-Datenbank und, für Galdra-Schlüssel, im Kontaktspeicher auf dem Chip (crates/contact-store). Sie sind nicht magisch an OpenPGP-Benutzer-IDs gebunden, es sei denn, Sie gleichen sie selbst ab, und sie sind nicht kryptografisch bestätigt, es sei denn, Sie überprüfen sie out of band. Ein optionales galdra keyserver push kann überlappende Felder zusammen mit dem exportierten öffentlichen Schlüssel als JSON an ein Projekt-Registry senden. Die Feldherkunft auf dem Token verwendet SelfAttested, HostVerified, RegistrySync und OobVerified (siehe Metadatenvergleich (GnuPG vs. Galdra) und das Kontaktspeicher-Layout in docs/RRAM_LAYOUT.md).
Host-seitige Details und CLI-Verhalten: docs/GALDRA-TOOL.md. Draht-Layout und Slot-Anzahlen: crates/contact-store/src/layout.rs und docs/RRAM_LAYOUT.md.
Diese Firmware ist ein Hardware-Sicherheitstoken für Baochip-1x: eine OpenPGP-Kartenanwendung über USB CCID, mit einem Tresor auf dem Gerät, einer PIN-Richtlinie und repository-spezifischen Funktionen (Chiffre-Profile – Sie können bis zu vier verschiedene symmetrische Chiffren in einer Kaskade stapeln, jede mit ihrem eigenen abgeleiteten Schlüssel; siehe Schlüsselfähigkeiten), Shamir-bezogenen Abläufen, authentifiziertem ephemerem ECDH (wo implementiert) und Galdra-Host-Tools). Das primäre Interoperabilitätsziel ist die GnuPG-artige OpenPGP-Kartennutzung, nicht jedes Token-Protokoll auf dem Markt.
Diese Firmware ist nicht:
Crate-Ebene-Ausschlüsse, die denselben Einschränkungen entsprechen, sind unter Crates Explizit Ausgeschlossen in docs/future-todo.md aufgeführt.
CESS: Diese Firmware erfüllt CESS für die im Tree implementierten normativen Konstruktionen (einschließlich Mode A äußeres AEAD, HKDF-BLAKE3 für K_outer und byteweise GF(2^8) Shamir-Aufteilung). Die vollständige Konformitätserklärung, Abweichungsliste und Zertifizierungsstufe (z.B. CESS-CORE für die vollständige feste Schicht) sind in docs/CESS_CONFORMANCE.md und CESS (verwandter offener Standard) unten dokumentiert.
Die OpenPGP / CCID-Anwendungslogik befindet sich in crates/usb-personality. Auf Xous ist der USB-Dienst, der CCID bereitstellt, usb-bao1x (in Ihrem xous-core-Checkout), erstellt mit dem Feature ccid-openpgp, unter Verwendung von crates/baochip-openpgp für das OpenPGP-RRAM-Fenster und die Bereitstellung. Layout: docs/RRAM_LAYOUT.md. Vorproduktionslücken (Operator-PIN-Benutzeroberfläche, Plattform-Map-Freigabe): Bekannte Einschränkungen / offene Arbeiten.
Das übergeordnete Ziel bleibt eine vollständige, getestete Open-Source-Hardware-Sicherheitstoken-Firmware: OpenPGP-Karten-ähnliches Verhalten für GnuPG über CCID (siehe OpenPGP- und GnuPG-Kompatibilität), plus zusätzliche Funktionen auf dem Gerät, die derzeit nicht durch den OpenPGP-Kartenstandard definiert sind – ephemeres ECDH mit Vorwärtssicherheit, Shamir K-of-N, chiffre-agnostische Profile, microSD-Decoy-Volume – wie in Standards vs. firmwarespezifische Funktionen zusammengefasst. Alles auf offenem RTL mit einem reproduzierbaren Bootloader.
Auslieferbare Firmware für Baochip-1x wird mit Ed25519 signiert. Sie signieren das Firmware-Image mit einem Ed25519-privaten Schlüssel; GnuPG kann dies mit gpg --sign unter Verwendung eines Ed25519-Signatur-Unterschlüssels durchführen (der übliche OpenPGP-Arbeitsablauf mit separater Signatur, angepasst an das, was Ihr Build ausgibt). Der unveränderliche boot0-ROM im SoC überprüft diese Signatur gegen die entsprechenden öffentlichen Schlüssel, die in das Gerät eingebrannt sind (und das breitere Schlüsselmanifest für die Boot-Kette) bevor die nächste Stufe – boot1 – ausgeführt werden darf. boot1 lädt dann signierte Anwendungsimages (z.B. UF2-Blobs, die über USB-Massenspeicher im Bootloader-Modus geliefert werden). Standardteile enthalten vier On-Chip-Ed25519-öffentliche Schlüssel (Rollen wie Code-Bereitstellung, Beta und Entwickler); boot0 / boot1 erzwingen eine gegenseitige Misstrauens-Richtlinie zwischen Baochip- und Drittanbieter-Signaturschlüsseln. Vollständiger Boot-Ablauf, UF2-Lieferung, Konsole, boot1-Updates und Sicherheitsmodell: Erste Schritte mit Baochip-Zielen in xous-core.
Nicht jeder Test läuft in jedem Befehl; das ist beabsichtigt.
xtask nicht im Standard-Workspace-Test: Das übliche Rezept ist cargo test --workspace --exclude xtask, weil xtask ein Build-Orchestrierungs-Crate ist. Führen Sie cargo test -p xtask aus, wenn Sie dessen Tests möchten.#[ignore] markiert: Diese werden übersprungen, es sei denn, Sie übergeben --ignored (und alle benötigten Crate-Filter). Gründe sind: Abdeckung, die bereits in fokussierten Unit-Tests abgedeckt ist (z.B. Zeroisierung nach Drop), langsame Fälle (z.B. RSA-Schlüsselgenerierung) und hardware- oder tokenabhängige Abläufe in Host-Tools wie galdra, die ein verbundenes Gerät oder Fixtures benötigen.test-all --no-fuzz: Überspringt den cargo-fuzz-Schritt, um CI oder schnelle Läufe kurz zu halten und keine Nightly-Toolchain für diesen Schritt zu benötigen; führen Sie cargo run -p xtask -- test-all ohne --no-fuzz aus, oder rufen Sie Fuzz-Ziele separat auf (siehe ).Die Integrität von Crates kann auch überprüft werden, wenn der PR geschlossen ist: https://github.com/rust-lang/cargo/issues/16850
Status: Bereit für Tests durch Menschen, auf echter Hardware – es existiert keine produktionsreife Version. Es ist in Rust geschrieben unter Verwendung validierter und auditierter Krypto-Crates. Kryptografische Primitive werden ausschließlich aus auditierten Workspace-Abhängigkeiten bezogen. Post-Quanten-Algorithmen sind feature-gated und als PENDING INDEPENDENT AUDIT gekennzeichnet. Siehe Post-Quanten-Status.
Hinweis: Teile dieses Projekts wurden mit KI-Unterstützung entwickelt (Claude, Anthropic). Das Design, die kryptografischen Entscheidungen und die Sicherheitsentscheidungen wurden nicht von einem professionellen Kryptografen überprüft. Behandeln Sie dies als experimentelles Projekt und wenden Sie Ihr eigenes kritisches Urteilsvermögen an. Eine unabhängige Expertenprüfung wird vor jedem Produktionseinsatz dringend empfohlen.
Es ist bereit für Tests durch Menschen. Sie entscheiden, ob Sie irgendeine dieser Software erstellen oder ausführen; es könnte Fehler geben, die Unit-Tests, Fuzzing und andere Prüfungen nicht gefunden haben. Die Verwendung einer optionalen virtuellen Maschine für Experimente reduziert das Risiko für Ihr Hostsystem, beseitigt es jedoch nicht. Detaillierte Ergebnisse befinden sich in Testergebnissen (docs/TEST_RESULTS.md#run-metadata). Einfache Definitionen (A–Z) technischer Begriffe: Glossar.
Der primäre Entwickler hat eine neurologische Erkrankung im Zusammenhang mit Dyskalkulie. Dyskalkulie beeinträchtigt das Zahlenverständnis und verwandte symbolische Verarbeitungsfähigkeiten in einer Weise, die für ihn traditionelle Programmierung – manuelle Code-Bearbeitung als alleinigen Workflow – nicht praktikabel macht ohne unterstützende Werkzeuge (z.B. konversationelle KI-Editoren). Diese Einschränkung ist von Korrektheit zu unterscheiden: Prüfer sollten dennoch Tests, Fuzzing und unabhängige Audits gewichten, wie an anderer Stelle auf dieser Seite dokumentiert.
Ein Kryptograf oder ernsthafter Implementierer, der Galdralag überprüft, wird typischerweise crates/vault/tests/ und crates/cipher-profile/tests/ öffnen, bevor er Prosa liest. Die Testsuite ist der Arbeitsnachweis: Sie kodiert Domänenwissen, das nicht allein durch narratives Erzählen ersetzt werden kann.
Das ist kein Grund, diesen Punkt vor allen anderen zu verbergen. Personen, die das Projekt für die Beschaffung evaluieren, entscheiden, ob sie beitragen, oder Code ohne tiefgehende Ausbildung in kryptografischer Testmethodik ausliefern, verdienen dennoch einen Hinweis auf die konkreten Beweise.
Was Sie sich ansehen sollten: Konformitätsmaterial umfasst RFC 8439 ausgearbeitete Beispiele für ChaCha20-Poly1305 unter crates/vault/tests/rfc_vectors/, eingelegte Wycheproof-JSON für ChaCha20-Poly1305 und Brainpool-ECDH/ECDSA-Grenzfälle unter crates/vault/tests/data/wycheproof/, BSI TR-03111-Vektoren für BrainpoolP256r1 und P384r1 unter crates/vault/tests/bsi_vectors/, offizielle BLAKE3-Referenzvektoren (alle 35 Eingabelängen, alle drei Modi) unter crates/vault/tests/blake3_vectors.json, Twofish-Spezifikationsvektoren (1203 Fälle inklusive Monte Carlo) unter crates/vault/tests/twofish_vectors.json und die projekteigene CESS-Kaskaden-KAT-Fixtur mit unabhängig verifizierten Zwischenergebnissen unter crates/cipher-profile/tests/fixtures/cascade_cess_kat.json. Zusammen sind dies die Grundwahrheiten, die der Ausführende und Prüfer mit cargo test --workspace und python3 scripts/verify_cascade_kats.py testen können.RFC 8439 wird von der Internet Engineering Task Force (IETF) veröffentlicht, der Organisation, die einen Großteil der Internet-Zusammenarbeit standardisiert. RFCs (Request for Comments) sind die übliche Form für Protokollspezifikationen und viele kryptografische Spezifikationen. RFC 8439 definiert die authentifizierte Verschlüsselung ChaCha20-Poly1305 (aufbauend auf den Entwürfen von Daniel Bernstein) und enthält konkrete, durchgerechnete Beispiele mit spezifischen Eingaben und erwarteten Ausgaben, damit unabhängige Implementierungen überprüfen können, ob sie Byte für Byte mit dem Standard übereinstimmen. Der weit verbreitete Klartext, der mit beginnt, erscheint in den Beispielen im Anhang des RFC: Wenn Ihr Code die AEAD-Ausgabe exakt reproduziert, haben Sie eine starke Bestätigung, dass Sie die Konstruktion korrekt implementiert haben. Es ist das kryptografische Äquivalent zu einem offiziellen Lösungsschlüssel. ChaCha20-Poly1305 ist die innere Schicht jedes mehrschichtigen Kaskadenprofils in dieser Firmware, daher sitzt diese Prüfung an der Basis des gesamten Chiffre-Stacks.
Wycheproof ist ein Testkorpus, der vom Google-Sicherheitsteam veröffentlicht wurde (2017). Der Name bezieht sich auf den Mount Wycheproof in Australien – oft als der kleinste Berg der Welt bezeichnet –, weil sich das Projekt auf die Beseitigung kleiner, aber tödlicher Hürden konzentriert: Integer-Überläufe, Grenzfälle, fehlerhafte Eingaben und manipulierte Authentifizierungs-Tags; Fehler, die in realen, eingesetzten Kryptosystemen immer wieder auftreten. Es ergänzt RFC-artige Vektoren: RFC 8439-artige Beispiele zeigen Korrektheit gegenüber dem veröffentlichten AEAD; Wycheproof testet die Robustheit dort, wo Implementierungen in der Vergangenheit versagen. In diesem Repository deckt das Wycheproof-JSON ChaCha20-Poly1305, AES-GCM, HMAC, HKDF, X25519, Ed25519, RSA und Brainpool-ECDH/ECDSA-Varianten ab.
BSI TR-03111 ist die technische Richtlinie für Elliptische-Kurven-Kryptografie, herausgegeben vom deutschen Bundesamt für Sicherheit in der Informationstechnik (BSI). Version 2.10 ist die aktuelle Revision. Die in dieser Firmware verwendeten Brainpool-Kurven – P256r1 und P384r1 – sind in BSI-Standards spezifiziert, was TR-03111 zur natürlichen Referenz für deren Testvektoren macht. Jede Kurve wird durch ECDH und ECDSA abgedeckt; ECDSA-Signaturen wurden zusätzlich mit einer unabhängigen Python-Implementierung unter Verwendung der Bibliothek cryptography gegengeprüft.
BLAKE3-Referenzvektoren sind der offizielle Testkorpus, der zusammen mit der BLAKE3-Spezifikation von ihren Autoren veröffentlicht wurde. Sie decken 35 Eingabelängen von 0 bis 102400 Bytes ab, die speziell ausgewählt wurden, um alle internen Block- und Baum-Hashing-Grenzbedingungen zu testen, die bei Kurzeingabetests unsichtbar bleiben. Alle drei BLAKE3-Modi – Standard-Hash, keyed Hash und derive-key – werden abgedeckt. BLAKE3 wird in dieser Firmware durchgängig für die HKDF-Schlüsselableitung und die Integritätsprüfungen zwischen den Schichten in den Kaskaden-Chiffre-Profilen verwendet; die Abdeckung von Grenzfällen ist wichtig, weil die Baumkonstruktion von BLAKE3 erst oberhalb von 1024 Bytes aktiviert wird.
Die Testsuite dient auch der Manipulationserkennung für die Lieferkette. Alle kryptografischen Primitiven in dieser Firmware stammen aus auditierten RustCrypto-Crates – keine Kryptografie wird im Verzeichnisbaum implementiert. Da die obigen Konformitätsvektoren bei jedem cargo test --workspace gegen diese Crates ausgeführt werden, führt jede manipulierte oder ausgetauschte Abhängigkeit zu einem Fehlschlag des Bekannte-Antwort-Tests, bevor der kompromittierte Code ein ausgeliefertes System erreicht. python3 scripts/verify_cascade_kats.py fügt einen zweiten unabhängigen Pfad hinzu: Eine Python-Implementierung prüft dieselben Zwischenwerte in der Kaskaden-KAT-Fixture, sodass selbst eine kompromittierte Rust-Toolchain, die falsche Ausgaben produziert, durch die Gegenprüfung erkannt wird. Dies ist eine deutlich stärkere Lieferketten-Integritätsgeschichte als die Bindung an eine C-Bibliothek, bei der eine gleichwertige Überprüfung jeder internen Operation deutlich mehr Aufwand und spezialisierte Werkzeuge erfordert.
Es liegt nun am Leser, zu beurteilen, ob diese Behauptungen falsch sind oder nicht.
Sie stecken es in einen USB-Anschluss. Aus Host-Sicht kann die Firmware entweder den Kryptomodus oder den Tarnmodus präsentieren. Im Kryptomodus sieht Ihr Computer eine Chipkarte: Sie verwenden GnuPG oder einen kompatiblen OpenPGP-Stack (Was ist GnuPG?) genauso wie jedes andere Hardware-Sicherheitstoken – das Token führt die sensiblen kryptografischen Operationen durch, sodass Ihre privaten Schlüssel nie ungeschützt auf Ihrem Computer existieren. Im Tarnmodus kann es sich als gewöhnlicher Wechseldatenträger mit harmlos aussehenden Dateien melden, sodass ein schneller Blick seine wahre Rolle nicht preisgibt; siehe Speicher-Tarnung unten.
GnuPG steht für GNU Privacy Guard. Es ist die Implementierung des GNU-Projekts von OpenPGP, dem offenen Standard für Schlüsselverwaltung und kryptografisch geschützte Nachrichten (derselbe konzeptionelle Familienzweig wie PGP, aber spezifiziert in Dokumenten wie RFC 4880 und Community-Updates). Normalerweise führen Sie es als Befehl gpg unter Linux, BSD, macOS oder Windows aus; viele grafische E-Mail- und Schlüsselverwaltungswerkzeuge verwenden es im Hintergrund.
Menschen verwenden GnuPG, um:
gpg-agent Authentifizierungsschlüssel von einer Chipkarte oder einem lokalen Schlüsselspeicher bereitstellt.GnuPG und verschlüsselte Laufwerke (LUKS). Linux hat eine integrierte Methode, ein gesamtes Laufwerk oder eine Partition zu verschlüsseln, genannt LUKS. Sobald ein Laufwerk verschlüsselt ist, sieht es für jeden ohne Schlüssel wie bedeutungsloses Rauschen aus, sodass ein verlorener oder gestohlener Laptop nicht Ihre Dateien herausgibt.
Normalerweise entsperren Sie ein solches Laufwerk durch Eingabe eines Passworts. GnuPG ermöglicht es Ihnen, stattdessen Ihr Token zu verwenden. Die Idee ist einfach: Der Entsperrschlüssel des Laufwerks ist selbst mit dem Schlüssel Ihres Tokens gesperrt. Wenn Sie das Laufwerk öffnen möchten, entschlüsselt das Token diesen Entsperrschlüssel für Sie, allerdings nur, solange das Token eingesteckt ist und Sie Ihre PIN eingegeben haben. Ziehen Sie das Token heraus, und das Laufwerk kann überhaupt nicht geöffnet werden, selbst auf demselben Computer.
Kurz gesagt, macht dies das Token zu einem physischen Schlüssel für Ihr verschlüsseltes Laufwerk. Die Einrichtung (und das Hinzufügen einer Backup-Methode für den Fall, dass das Token jemals verloren geht) erfolgt mit den eigenen Festplattenwerkzeugen von Linux; das Token hält lediglich den Schlüssel. Wenn Sie lieber die Fähigkeit, ein Laufwerk zu entsperren, auf mehrere Personen verteilen möchten, sodass keine Person allein dazu in der Lage ist, siehe Shamir Secret Sharing und Festplattenverschlüsselung.
Standardmäßig speichert GnuPG Schlüssel unter ~/.gnupg. Mit einer OpenPGP-Chipkarte befinden sich sensible private Schlüssel auf der Karte; scdaemon (Teil der GnuPG-Suite) kommuniziert über CCID/USB mit der Karte, während gpg weiterhin OpenPGP-Pakete auf dem Host zusammenstellt.
Wofür Sie es verwenden können. Im Kryptomodus ist das Token für die gleiche Arbeit wie andere OpenPGP-Chipkarten gedacht: Signieren und Entschlüsseln von E-Mails und Dateien, Authentifizieren (z. B. SSH, wenn Sie gpg-agent wie gewohnt verwenden) und die Aufbewahrung langfristiger privater Schlüssel außerhalb des von Ihnen benutzten Rechners. Organisationen können dies mit Shamir-Anteilen auf dem Token kombinieren, sodass keine einzelne Person das gesamte Geheimnis besitzt (weiter unten beschrieben). GnuPG ist das primäre Interoperabilitätsziel auf dem Host: Diese Firmware implementiert die OpenPGP-Kartenanwendung über CCID, die scdaemon ansteuert (gpg --card-status, gpg --card-edit sowie normales Ver-/Entschlüsseln und Signieren mit Schlüsseln auf der Karte). Andere Software, die dieselben Chipkartenprotokolle spricht, könnte ebenfalls funktionieren; Befehle, Slots, Algorithmen und aktuelle Integrationsgrenzen finden Sie unter OpenPGP- und GnuPG-Kompatibilität. Wenn NFC auf der Hardware bereitgestellt wird (geplante Integration – noch nicht in der Firmware), kann dieselbe Geräteklasse den physischen Zutritt unterstützen: Das Tippen an einen NFC-Leser an einer Tür, einem Tor oder einem Schließfeld kann an einer Richtlinie teilnehmen, die das Schloss erst nach kryptografischen Prüfungen freigibt (oft kombiniert mit PIN, Biometrie oder Shamir-artigem Quorum, je nach Einsatzumgebung). Der PN532-orientierte Entwurf für Leser und Schließfelder befindet sich in docs/NFC_PN532_INTEGRATION.md.
Das ist die Kurzversion. Hier ist, was es von anderen Tokens unterscheidet, die Sie vielleicht kennengelernt haben.
Speicher-Tarnung. Das Gerät kann als gewöhnlicher Wechseldatenträger fungieren, sodass seine wahre Rolle bei einem schnellen Blick nicht offensichtlich ist. Wenn Sie es an einen typischen Computer anschließen, kann es wie ein normales USB-Laufwerk oder ein SD-basiertes Volume erscheinen; Sie können das sichtbare Dateisystem mit plausiblen Alltagsdateien (z. B. Urlaubsfotos) füllen, sodass ein flüchtiger Blick den Eindruck verstärkt, dass es sich nur um Speicher handelt. Dies erschwert eine oberflächliche Inspektion am Schreibtisch oder an einem Kontrollpunkt. Herauszufinden, dass es sich tatsächlich um ein Sicherheitstoken handelt, erfordert normalerweise, das Gehäuse zu öffnen, nicht nur, es einzustecken.
Ihre Schlüssel bleiben auf dem Gerät. Wenn Sie eine E-Mail signieren oder eine Datei entschlüsseln, verlässt der private Schlüssel niemals das Token. Der Computer sendet die Daten hinein, das Token erledigt die Arbeit, das Ergebnis kommt heraus. Ein Angreifer, der Ihren Computer kompromittiert, erhält nichts Nützliches.
Vergangene Sitzungen bleiben sicher, selbst wenn das Token gestohlen wird. Die meisten Hardware-Tokens verwenden einen langfristigen privaten Schlüssel direkt für die Schlüsseleinigung. Dieses hier generiert für jede Sitzung ein neues temporäres Schlüsselpaar, signiert es mit dem langfristigen Schlüssel, um seine Echtheit zu beweisen, und verwendet dann das temporäre Paar für den eigentlichen Austausch. Wenn jemand das Token Jahre später stiehlt und irgendwie den langfristigen Schlüssel extrahiert, kann er dennoch nichts aus vergangenen Sitzungen entschlüsseln. Diese Eigenschaft nennt sich Vorwärtssicherheit, und sie ist bei Hardware-Tokens ungewöhnlich.
Sie können den Schlüssel auf mehrere Personen aufteilen. Das Token kann den langfristigen Schlüssel in N Anteile aufteilen, sodass beliebige K dieser Anteile benötigt werden, um ihn zu rekonstruieren – aber kein einzelner Anteilsinhaber allein etwas tun kann. Dies wird Shamir Secret Sharing genannt. Es ist nützlich für Organisationsschlüssel, bei denen keine einzelne Person alleinigen Zugriff haben sollte, oder als Backup-Strategie, bei der Anteile an verschiedenen Orten aufbewahrt werden. Auch dies ist bei Hardware-Tokens ungewöhnlich.
Die Verschlüsselung ist mehrschichtig. Anstatt Ihre Daten mit einer einzelnen Chiffre zu verschlüsseln, kann das Token sie nacheinander durch mehrere unabhängige Chiffren laufen lassen – zum Beispiel ChaCha20, dann Serpent, dann Twofish – jede mit einem separat abgeleiteten Schlüssel. Ein zukünftiger Durchbruch, der eine Chiffre bricht, bricht nicht die anderen. Die spezifische Kombination wird als Chiffre-Profil bezeichnet, und Sie können aus mehreren integrierten Profilen wählen, je nachdem, wie viel Vorsicht Ihre Situation erfordert.
Meine persönliche Empfehlung ist BrainpoolP256r1 + ChaCha20-Poly1305 + BLAKE3. Dies ist das integrierte standard-Profil. Es verwendet die BSI-Brainpool-P-256-Kurve für die flüchtige Schlüsseleinigung, ChaCha20-Poly1305 für die symmetrische Verschlüsselung und BLAKE3 für die Schlüsselableitung und die Integritätsprüfungen zwischen den Schichten. Es ist schnell, gut getestet, akkuschonend (ChaCha20-Poly1305 wurde entwickelt, um auf Hardware ohne AES-Beschleunigung effizient zu sein, was CPU-Zeit und Host-Stromverbrauch reduziert; P-256 ist die kleinste der drei Brainpool-Kurven in dieser Firmware) und hängt von keiner NIST-entwickelten Primitive ab. Wenn Sie eine höhere Sicherheitsmarge gegen einen zukünftigen kryptanalytischen Bruch einer einzelnen Chiffre benötigen, fügt das conservative-Profil eine Serpent-256-Schicht hinzu.
Die Algorithmusauswahl ist bewusst getroffen. Die verwendeten Chiffren – ChaCha20-Poly1305, Serpent, Twofish, Camellia – wurden alle unabhängig von staatlichen Normungsgremien entwickelt. AES und die NIST-Suite werden bewusst ausgeschlossen. Dies ist eine bewusste Entscheidung für Benutzer und Organisationen, die kryptografische Unabhängigkeit vom Standardsetzungsprozess eines einzelnen Landes wünschen. Camellia wurde unabhängig vom EU-Projekt NESSIE und dem japanischen Programm CRYPTREC evaluiert und ist in RFC 3713 und ISO/IEC 18033-3 spezifiziert.
Eine falsche PIN sperrt Sie richtig aus. Das Token zählt fehlgeschlagene PIN-Versuche, bevor es prüft, ob die PIN korrekt ist, nicht danach. Dies bedeutet, dass ein Absturz oder Stromausfall während eines Versuchs nicht ausgenutzt werden kann, um den Zähler zurückzusetzen. Nach zu vielen Fehlversuchen löscht das Token sensibles Material.
Was es noch nicht kann. Es gibt noch keine Hardware – dies ist Firmware in aktiver Entwicklung. End-to-End-Tests mit echter USB-Hardware und GnuPG sind ein zukünftiger Meilenstein. NFC-Transport und türartige Zutrittsleser werden in der Dokumentation als Integrationsziele beschrieben, nicht als ausgeliefertes Verhalten. Der in der Dokumentation beschriebene biometrische dritte Faktor ist noch nicht implementiert. Einige Timing-Seitenkanal-Tests, die echte Hardware erfordern, können erst abgeschlossen werden, wenn ein Gerät existiert.
Galdralag kann gleichzeitig mit zwei verschiedenen Arten asymmetrischer Schlüssel arbeiten. Sie beantworten unterschiedliche Fragen auf dem Gerät und auf dem Host und sind nicht austauschbar, selbst wenn sie derselben Person gehören. Die Abschnitte OpenPGP- und GnuPG-Kompatibilität, Web of Trust und Key-Signing-Partys, Galdra-Kontaktmetadaten und Metadatenvergleich (GnuPG vs. Galdra) beschreiben jeden Stack detaillierter; hier ist der Unterschied in alltäglichen Begriffen.
Ein OpenPGP-Schlüssel im Sinne von GnuPG ist ein strukturiertes Paket, keine bloße öffentliche Zahl. Er bündelt den primären Schlüssel, Unterschlüssel zum Signieren und Verschlüsseln sowie eine oder mehrere Benutzer-IDs – normalerweise einen Anzeigenamen und eine E-Mail-Adresse wie Alice Example <[email protected]>. Andere Personen können diese Benutzer-IDs signieren, um zu bestätigen, dass sie die Identitätsbehauptung für echt halten; dieser soziale Graph ist die Basis des Web of Trust, das später in diesem README unter Web of Trust und Key-Signing-Partys beschrieben wird. Wenn Galdralag als OpenPGP-Chipkarte fungiert, hält es das private Schlüsselmaterial auf dem Chip und führt dort die Signier- und Entschlüsselungsoperationen durch. Der öffentliche Schlüssel, die Benutzer-IDs und die Signaturen anderer befinden sich auf dem Host und werden von GnuPG auf die übliche Weise verwaltet. Das Token ändert das OpenPGP-Nachrichtenformat auf der Leitung nicht; GnuPG behandelt es wie jede andere OpenPGP-Karte.
Ein Galdra-Schlüssel ist ein reines asymmetrisches Schlüsselpaar – Ed25519, X25519 oder eine der Brainpool- oder NIST-Kurven, die die Firmware unterstützt. Die Schlüsselbytes selbst tragen keine Identitätsansprüche: keine Benutzer-ID-Pakete, keine eingebackene E-Mail, keine Web-of-Trust-Signaturen, die an die Schlüsselstruktur angehängt sind. Die Identität für einen Galdra-Schlüssel stammt aus dem Kontaktdatensatz, der neben ihm in der Host-SQLite-Datenbank und im Kontaktspeicher auf dem Chip gespeichert ist, verknüpft mit dem Schlüssel durch seinen Fingerabdruck.
Die folgende Tabelle vergleicht Identitäts- und Kontaktmetadaten Feld für Feld. Die Spalten OpenPGP / GnuPG beschreiben, was Sie von einem normalen Zertifikat und einer Benutzer-ID erhalten (plus optionale hostseitige Kontaktzeilen in Galdra, wenn Sie einen öffentlichen OpenPGP-Schlüssel im selben Verzeichnis speichern). Die Spalten Galdra-Schlüssel beschreiben strukturierte Sidecar-Felder für betriebliche Kontakte (vollständige Host- und Chip-Details in Galdra-Kontaktmetadaten). Ein Bindestrich bedeutet, dass dieser Stack kein standardmäßiges, separates Feld für diesen Eintrag hat.
OpenPGP packt Name und E-Mail in einen Benutzer-ID-String; es bietet keine separaten, maschinenlesbaren Felder für Rufzeichen, DMR oder Postanschrift. Galdra hält diese als benannte Spalten, sodass Funk- und Einsatzteams danach suchen und sie anzeigen können, ohne Zertifikatstext parsen zu müssen.
Tokens, die von Firmware aktualisiert wurden, die BrainpoolP512r1 anbot, können weiterhin P-512-Attribute auf GET DATA zurückgeben; GnuPG-Operationen auf diesen Slots schlagen dann mit generischen Kartenfehlern fehl. Führen Sie galdra device status aus (oder siehe docs/OPENPGP_CARD.md), um veraltete Slots zu identifizieren; Hintergrund zur Entfernung in CHANGELOG.md.
| PW1 / PW3 | Nie gespeichert | Verifizierer auf Chip (mind. 5 Zeichen, 3 Versuche Standard) |
| Karteninhaber-DOs (Login, Sprache, URL, …) | Von GnuPG zwischengespeichert | Optional (254 Bytes max. pro DO) |
Kartenanwendung 3.4.1, CCID und GnuPG-Workflows: docs/OPENPGP_CARD.md und OpenPGP- und GnuPG-Kompatibilität.
Die Trennung existiert, weil die Identitätsinformationen, die in den von Galdralag anvisierten Communities wichtig sind – Rufzeichen, DMR-ID, Funknetz-Zugehörigkeit – keinen natürlichen Platz in einer OpenPGP-Benutzer-ID haben. Eine Benutzer-ID ist für Name und E-Mail gedacht. Das Schreiben von etwas wie LA5XYZ <[email protected]> DMR:2345678 in einen Benutzer-ID-String ist informell, unstrukturiert und in keiner standardisierten Weise maschinenlesbar. Galdra-Schlüssel halten das kryptografische Material sauber und legen die betriebliche Identität in einem Datensatzformat ab, das das Host-Werkzeug und der On-Chip-Speicher nativ verstehen.
In der Praxis kann ein einzelnes Gerät beide Arten von Schlüsseln ohne Konflikt halten. Die OpenPGP-Kartenanwendung bedient GnuPG über die standardmäßigen SIG-, DEC- und AUT-Slots. Der Kontaktspeicher hält Galdra-Schlüssel für betriebliche Arbeit – zum Beispiel Verschlüsseln für einen Funkkontakt nach Rufzeichen, Überprüfen einer Nachricht gegen eine DMR-Teilnehmer-ID oder Nachschlagen eines Kollegen anhand der Ausweisnummer. Die beiden Pfade stören einander nicht.Wenn jemand ein OpenPGP-Zertifikat besitzt, das von GnuPG auf dem Host verwaltet wird, und einen Galdra-Schlüssel im Kontaktspeicher des Chips, dann sind das zwei separate Schlüssel mit zwei separaten Fingerabdrücken. Der Galdra-Fingerabdruck – mit dem Präfix G: und abgeleitet mit BLAKE3 aus den rohen öffentlichen Schlüsselbytes – ist nicht der gleiche Wert wie der OpenPGP v4-Fingerabdruck des GnuPG-Zertifikats dieser Person. Das Host-Tool und das Gerät behandeln sie als unabhängige Identitäten. Gehen Sie nicht davon aus, dass der eine Fingerabdruck den anderen impliziert, ohne beide zu überprüfen.
Keine Schlüsselart bürgt automatisch für die sie umgebenden Bezeichnungen. Eine OpenPGP-Benutzerkennung (User ID) ist eine Selbsterklärung, bis jemand anderes sie signiert. Ein Rufnamen- oder DMR-Feld in einem Galdra-Kontakteintrag ist nur so vertrauenswürdig wie seine Quelle – ein Abruf von einem Schlüsselserver, eine manuelle Eingabe oder eine außerbandige Überprüfung, die Sie selbst durchgeführt haben. Die Herkunftsetiketten (SelfAttested, HostVerified, RegistrySync, OobVerified) dokumentieren wie ein Feld angekommen ist; sie ersetzen nicht die tatsächliche Überprüfung der Identität, die Ihnen wichtig ist.
Diese Firmware ist in Rust geschrieben, einer Systemprogrammiersprache, die für ebenso schnelle und hardwarenahe Programme wie C oder C++ ausgelegt ist, aber mit einem grundlegend anderen Ansatz in Bezug auf Sicherheit.
Ein großer Teil der sicherheitsrelevanten Fehler in industriellen Codebasen geht auf Speicherunsicherheit zurück (Pufferüberläufe, Use-After-Free, Nullzeiger-Dereferenzierungen und Ähnliches). Das MSRC von Microsoft hat wiederholt berichtet, dass etwa 70% der in ihren eigenen Produkten adressierten CVEs in diese Kategorie fallen; das Chrome-Team hat ähnliche Anteile für Chrome veröffentlicht. Diese Zahlen beschreiben die Produkte dieser Anbieter, kein universelles Gesetz für alle Firmware, aber sie veranschaulichen, warum speichersichere Sprachen wichtig sind.
In sicherem Rust (der Standard) schließt der Borrow-Checker Datenrennen und die üblichen Speicherfehler mit undefiniertem Verhalten zur Kompilierzeit aus, ohne auf eine Garbage Collection angewiesen zu sein. Unsicherem Rust und FFI zu C können dennoch Speicherfehler einführen; sie müssen klein gehalten und überprüft werden.
Rusts Grenzprüfung bei Slices und seine Eigentumsregeln reduzieren mehrere Fehlerklassen, die in eingebettetem C/C++-Code üblich sind:
unsafe-Blöcke müssen explizit sein; MMIO und rohe Zeiger für Register leben dort, sodass Prüfer die Audit-Oberfläche durchsuchen können (unsafe macht nicht unmöglich, MMIO falsch zu machen, nur leichter lokalisierbar).Rust stoppt nicht von selbst logische Fehler wie eine Endlosschleife, die Flash verschleißt, oder die Wahl falscher Registerwerte. Diese bleiben Aufgaben der Entwicklung und Überprüfung.
Diese Codebasis verwendet gängige Rust-Muster für Geheimnisse; sie sind nicht automatisch für jeden Typ:
zeroize::Zeroize / ZeroizeOnDrop löschen Puffer beim Drop; Aufrufer müssen sie aktiv nutzen.subtle::ConstantTimeEq (und Ähnliches), wenn Timing von Bedeutung ist – gewöhnliches == ist nicht automatisch konstantzeit.Copy bei Geheimnis-Wrappern reduziert versehentliche Duplizierung; Bereichstrennung verwendet unterschiedliche Typen und HKDF-Bezeichnungen (Kryptografische Abhängigkeitsrichtlinie).catch_unwind oder abort-Strategien, wo Ihre Plattform stärkere Garantien erfordert.unsafe muss im Quelltext ausgeschrieben werden, was die manuelle Überprüfung eingrenzt. Abhängigkeiten: Die kryptografische Richtlinie dieses Projekts bevorzugt geprüfte Rust-Crates (RustCrypto und andere); siehe die Tabelle in Kryptografische Abhängigkeitsrichtlinie – nicht jede Abhängigkeit stammt von einem einzigen Dachprojekt.
Rust beseitigt nicht Deadlocks (z. B. falsch geordnete Mutex-Sperren), logische Fehler, fehlerhafte Protokolle, Flash-Verschleiß durch schlechte Schleifen, physische Angriffe (Glitching, Leistungsanalyse) oder Risiken aus einem korrekten Build des falschen Images. Es gewährleistet auch nicht die konstante Ausführungszeit auf jeder Hardware ohne sorgfältige Programmierung. Diese Bereiche beruhen auf Entwurf, Überprüfung, Tests und den Krypto- und Lieferkettenpraktiken des Projekts, die an anderer Stelle in dieser README beschrieben werden.
Verifikation (Tests und Fuzzing): Über die Sprache hinaus verwendet dieses Repository Unit-Tests, Integrationstests, dudect-Timing-Harness und libFuzzer (cargo-fuzz)-Ziele. Zusammenfassungen und Matrizen finden Sie unter Testergebnisse; die aufgezeichneten Laufmetadaten beginnen unter docs/TEST_RESULTS.md#run-metadata. Bestandene Tests beweisen nicht die Produktionsreife oder das Fehlen von Schwachstellen – sie verringern das Risiko. Sie entscheiden, ob die Ausführung von Builds oder Tests für Ihre Umgebung akzeptabel ist; eine virtuelle Maschine ist optional, begrenzt aber den Schadradius auf Ihrem Rechner.
Jede gängige VM-Plattform ist geeignet – VirtualBox (frei, Open Source), QEMU (frei, Open Source, Kommandozeile) oder VMware. Als Gast wird Linux empfohlen, da die Build-Umgebung dort am besten unterstützt wird.
Schnellstart mit QEMU und 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
Innerhalb der VM gelten die Standard-Build-Anweisungen. Die VM kann vor jedem Experiment **gesnapshotet** und bei Problemen sauber **zurückgesetzt** werden.
### Risikobewertung und Bereitstellung
**Letztendlich ist die Entscheidung, ob diese Firmware in Ihrer Umgebung sicher eingesetzt werden kann, nur von Ihnen zu treffen**, basierend auf Ihrer eigenen Risikobewertung, der Sensitivität dessen, was Sie schützen, und ob Sie vor der Bereitstellung auf ein unabhängiges Audit durch Dritte warten möchten. Dieses Projekt zielt darauf ab, Ihnen alle notwendigen Informationen zu geben, um diese Entscheidung selbst zu treffen.
Eine strukturierte Liste von Assets, Bedrohungen **T1–T14**, expliziten Nicht-Zielen und Verifikationslücken aus Q2 finden Sie in **[docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/THREAT_MODEL.md)**.
---
## Zum Namen
**Galdr** ist die altnordische Praxis gesprochener oder gesungener Magie: Beschwörungen, die verwendet werden, um zu binden, zu schützen oder zu enthüllen. In den Sagen bezeichnet es den Akt des Zauberwirkens selbst, nicht nur die Worte. Manchmal auch verwendet, um magische Runeninschriften zu aktivieren, wie auf dem [Kragehul-I-Lanzenschaft](https://en.wikipedia.org/wiki/Kragehul_I), dem [Lindholm-Amulett](https://en.wikipedia.org/wiki/Lindholm_amulet), dem [Vadstena-Brakteaten](https://en.wikipedia.org/wiki/Vadstena_bracteate) und anderen Funden des älteren Futhark.
**Galdralag** ist die metrische Form, die für Galdr verwendet wird: strukturierte, präzise, regelgebundene Verse, bei denen das Muster Teil der Kraft des Zaubers ist. Das Suffix *lag* ist verwandt mit „Gesetz“ oder „Muster“.
**Runen** waren buchstäblich geheimes, kodiertes Wissen – die schamanische Verwendung war nur denen bekannt, die es verstanden.
---
## Dokumentation
**Glossar:** [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md) — Begriffe in **einfacher Sprache** erklärt (alphabetisch sortiert). Hier beginnen, wenn das README oder andere Dokumente jargonlastig erscheinen.
**Fehlerbehebung:** [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/DEBUG_INSTRUCTIONS.md) — Backtraces, Eingrenzen von `cargo test`, `xtask`-Abkürzungen, Firmware-Dreifachprüfungen, Fuzzing und was vor der Meldung eines Problems zu sammeln ist.
**KI-Assistenten (Claude, Cursor):** [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/CLAUDE.md) — Projektanweisungen für Code-Agenten. Cursor-spezifische Regeln: [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/.cursor/rules/).
**Alle Dateien durchsuchen:** [github.com/Supermagnum/Galdralag-firmware — `docs/`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs)
**Hardware (USB-Dongle und Verwandtes):** Zwei KiCad-Bäume: [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-files-usb/) — `dabao_v3c` (USB-A-Token **ohne** micro-SD); und [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/) — `dabao_v3c_sdcard` (gleiches Grundlayout **mit** micro-SD-Halter), Gerber-Dateien, BOM, Produktionsausgaben und [Pinout-Dokumentation](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/docs/pinout/README.md). Das PCB-Layout des USB-A-Dongles (Minimal-Token vs. Pico-Format-Eval) wird in [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) beschrieben.
| Dokument | Beschreibung |
|----------|-------------|
| [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-files-usb/) | **USB-Dongle** KiCad-Projekt `dabao_v3c` (ohne micro-SD); Gerber-Dateien, BOM, Produktionsausgaben; ergänzt [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) |
| [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/) | **USB-Dongle** KiCad-Projekt `dabao_v3c_sdcard` (micro-SD-Halter); Gerber-Dateien, BOM, Pinout unter [docs/pinout](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/docs/pinout/README.md); ergänzt [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) |
| [docs/CODE_MAP.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CODE_MAP.md) | **Funktions- und Modulverzeichnis** des Workspace (pro Datei `pub fn` / Typen mit Zeilenankern) |
| [docs/CRATE_DEPENDENCIES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CRATE_DEPENDENCIES.md) | **Upstream- vs. Projekt-Rust-Crates** und deren Abhängigkeiten |
| [docs/API_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/API_REFERENCE.md) | Code-Map + **Anhang** zu IETF/I-D/GnuPG/Sequoia: Shamir-GF(256)-Konstruktion, GALDRA SHARE-Armour, ephemeres ECDH-Wire-Format, HKDF-Labels, Preimages; `galdrad`-Routen; rustdoc-Hinweise |
| [docs/ARCHITECTURE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/ARCHITECTURE.md) | Hochrangige Firmware-Architektur und Hauptsubsysteme |
| [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/AUDIT_LOG.md) | Profil-Audit-Einträge (`cipher-profile`), OpenPGP `OpenPgpAudit`-Hook; **kein** Append-Only-RRAM-Log bisher implementiert |
| [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/BIOMETRIC_API.md) | Biometrisches Vorgate: Architektur, Wire-Format, Tresor-Layout; Integration teilweise implementiert |
| [docs/BIOMETRIC_DEVICE_GUIDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/BIOMETRIC_DEVICE_GUIDE.md) | Wie man Unterstützung für ein neues biometrisches Hardware-Backend hinzufügt |
| [docs/BIOMETRIC_TESTING.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/BIOMETRIC_TESTING.md) | Testmethodik: ISO/IEC 30107-3 PAD-Metriken, Datensätze, Ausführungshinweise |
| [docs/FINGERVEIN_DEVICE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/FINGERVEIN_DEVICE.md) | ESP32-CAM offenes Fingervenen-Gerät: Hardware, Protokoll-Skizze, Lebenderkennung |
| [docs/SWEET_PLATFORM_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/SWEET_PLATFORM_INTEGRATION.md) | Sweet Platform-Handscanner: Hardware, Integration, Lebenderkennung, Datensatz |
| [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md) | Host-Tools (`galdra`, `galdrad`, `galdra-gtk`): Workflows, Provisionierung, PIN-Richtlinie, Betriebsverhalten |
| [Supermagnum/Fulla](https://github.com/Supermagnum/Fulla) | **Fulla**: WoT-orientiertes OpenPGP-Public-Key-Register (Server-Repository und Implementierung). **Es läuft noch keine öffentliche Registerinstanz**; eine ist geplant. **`galdra keyserver push`** / **`galdra keyserver fetch`** und die optionale **`[keyserver]`**-Konfiguration zielen auf dieses Ökosystem ab – siehe auch [Web of Trust und Key-Signing-Partys](#web-of-trust-and-key-signing-parties). Ergänzende Design-Notizen befinden sich in [docs/server.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/server.md). |
| [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md) | **Einfachsprachiges Glossar** (A–Z) für nicht-technische Leser; technische Details bleiben in den verlinkten Dokumenten |
| [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/CLAUDE.md) | Anweisungen für **Claude** / KI-Code-Agenten; verweist auf [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/.cursor/rules/) für **Cursor** |
| [docs/GALDRALAG_DEV_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRALAG_DEV_REFERENCE.md) | Toolchain, `xtask`-Befehle, Fuzzing- und Krypto-Test-Einstiegspunkte |
| [docs/dev-ref.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/dev-ref.md) | Workspace-Layout, Crates, HAL-Traits, USB/PSRAM-Verhalten, Sicherheitsinvarianten |
| [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/DEBUG_INSTRUCTIONS.md) | Fehlerbehebung: `RUST_BACKTRACE`, ausführliche Builds, eingegrenzte Tests, `xtask`-Rezepte, Embedded-Target-Prüfungen, Fuzzing-Hinweise, OpenPGP-Host-Prüfungen |
| [docs/KEY_LIFECYCLE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/KEY_LIFECYCLE.md) | Schlüsselerzeugung, -import, -export-Richtlinie, -rotation, Nullstellung, Shamir (wie in `vault` / OpenPGP abgebildet) |
| [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md) | OpenPGP-Card-Anwendung, GnuPG/CCID-Host-Einrichtung, Schlüsselslots, Algorithmen, udev |
| [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CIPHER_PROFILES.md) | Cipher-Profil-System und -Konfiguration |
| [docs/CIPHER_PROFILE_SECURITY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CIPHER_PROFILE_SECURITY.md) | Sicherheitsaspekte: Klartext-Profilkennungen, Verkehrsanalyse, BrainpoolP384r1-Außenwrapper-Begründung, verschlüsselte Kennungen, Wildcard-Eigenschaft |
| [docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CESS_CONFORMANCE.md) | [CESS](https://github.com/Supermagnum/CESS/tree/main)-Konformität: Mode-A-Wire-Layout, `suite_id` aus [ALGORITHM-REGISTRY.md – Nachschlagetabelle](https://github.com/Supermagnum/CESS/blob/main/ALGORITHM-REGISTRY.md#cipher-suite-identifier-lookup-table), Abweichungsregister (beibehaltene AES/SHA-2 vs. CESS-CORE), Fahrplan |
| [crates/cess](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/crates/cess) | CESS Mode A: HKDF-BLAKE3 (`derive_k_outer`, `hkdf_blake3`), ChaCha-äußeres Versiegeln/Öffnen, `suite_id \|\| inner_blob`-Layout; siehe [CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CESS_CONFORMANCE.md) |
| [docs/EPHEMERAL_SESSION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/EPHEMERAL_SESSION.md) | Authentifiziertes ephemeres ECDH-Sitzungsprotokoll |
| [Supermagnum/CESS](https://github.com/Supermagnum/CESS) | **CESS** (*Cryptologically Enchanted Shamir's Secret*) – offene Spezifikation (normativer Text und Testvektoren) für Threshold-Secret-Sharing mit authentifizierter Verschlüsselung, passwortgeschütztem Share-Wrapping und optionalem post-quantum-Hybridschlüsselaustausch; getrennt von dieser Firmware, aber im gleichen Designbereich wie Shamir und Cipher-Profile hier |
| [docs/PQ_SIGNATURES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/PQ_SIGNATURES.md) | Post-Quantum-zustandsbehaftete Signaturen (XMSS, LMS/HSS), Feature-Gating |
| [docs/Psram.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/Psram.md) | Optionales microSD-Täuschungsvolume und zugehöriges Verhalten |
| [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/RRAM_LAYOUT.md) | **4.194.304 Byte** On-Chip-RRAM: Vault-Offsets aus dem Quelltext, HAL-Mapping, Abnutzungs-/Nullstellungs-Notizen |
| [docs/TEST_RESULTS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/TEST_RESULTS.md#run-metadata) | Öffnet bei **Run metadata**; Pipeline-Zusammenfassung, Vektoren, dudect, cargo-fuzz ([Abschnitt 6](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/TEST_RESULTS.md#6-cargo-fuzz-libfuzzer)), Schlüssellebenszyklus |
| [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/THREE_FACTOR_AUTH.md) | Token + PIN + optionale Biometrie: was dieses Repository implementiert vs. Platzhalter; Bedrohungsskizze |
| [docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/THREAT_MODEL.md) | Bedrohungsmodell: Assets, Bedrohungen T1–T14, was verteidigt wird und was nicht, unverifizierte Elemente in Erwartung von Q2-Hardware, Audit-Status |
| [docs/PERFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/PERFORMANCE.md) | Leistungsnotizen |
| [docs/HARDWARE_BRINGUP_TEST_PLAN.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_BRINGUP_TEST_PLAN.md) | Q2-Ersthardware-Inbetriebnahme: CCID-Enumeration, `gpg --card-status`, USB CDC `galdralag-provision` für Erststart-PINs, dann `gpg --card-edit` / Krypto-Smoke-Tests |
| [docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_VERIFICATION.md) | Hardware-Nullstellung: Simulation vs. Silizium-Verifikation |
| [docs/HARDWARE_TEST.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_TEST.md) | Hardwareorientierte Testnotizen |
| [docs/NFC_PN532_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/NFC_PN532_INTEGRATION.md) | PN532 / NFC: libnfc, Rust-Optionen, passiv für Tür vs. USB-Panel, Quorum mit Shamir und PIN |
| [docs/SDMMC_STORAGE_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/SDMMC_STORAGE_INTEGRATION.md) | `embedded-sdmmc` + SPI microSD als optionaler Massenspeicher; BOM-Alternative zu PSRAM |
| [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) | Wie man ein USB-A-Dongle-PCB aus der Dabao-Referenz herstellt: Pico-Format-Eval ist für Firmware-Inbetriebnahme; dies entfernt den GPIO-Header für ein Minimal-Token; KiCad, FreeCAD, 5 V / 500 mA vs. USB-C PD, QSPI-PSRAM-Routing |
Die gleichen Pfade sind auf GitHub unter [`tree/main/docs`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs) und [`tree/main/Hardware`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/Hardware) verfügbar.
---
## OpenPGP- und GnuPG-Kompatibilität
Die Firmware implementiert die **OpenPGP-Card-Anwendung** (dokumentiert als Version **3.4.1** in [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md)). Dies ist dieselbe Geräteklasse, die GnuPG für **OpenPGP-Smartcards** über **CCID/USB** ansteuert: Der Host benötigt einen normalen Smartcard-Stack (`pcscd`, `ccid`-Treiber, GnuPGs `scdaemon`). **Kein benutzerdefinierter kryptografischer Host-Treiber** ist über das hinaus erforderlich, was Sie für jede OpenPGP-Card verwenden würden.
**Was dies auf dem Host ermöglicht (sobald das Gerät als CCID-Leser sichtbar ist):**
| Bereich | Anmerkungen |
|------|--------|
| **GnuPG-Workflows** | `gpg --card-status`, `gpg --card-edit`, Ver- und Entschlüsselung sowie Signatur mit Schlüsseln auf der Karte |
| **SSH** | `gpg-agent` mit `enable-ssh-support` und der üblichen `SSH_AUTH_SOCK`-Einrichtung |
| **Mail und Dateien** | Clients, die GnuPG verwenden (z. B. Thunderbird, Evolution, Kleopatra) und standardmäßige `gpg`-Dateiverschlüsselung |
| **Andere Werkzeuge** | Alles, was die OpenPGP-Card + CCID auf die gleiche Weise wie GnuPG anspricht |
**Schlüsselslots (typische Vorgaben):** **SIG** (Signatur), **DEC** (Entschlüsselung / ECDH), **AUT** (Authentifizierung, z. B. SSH). Algorithmen sind pro Slot wählbar (Brainpool-Kurven, NIST P-256/P-384, Ed25519 / X25519, RSA). Die vollständige Tabelle und das `key-attr`-Verhalten sind in [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md) beschrieben.
**Nicht von OpenPGP-Card / GnuPG abgedeckt:** **WebAuthn / FIDO2** ist ein anderes Protokoll und liegt außerhalb des Anwendungsbereichs dieser Card-Anwendung (siehe gleiches Dokument).
**OpenPGP-Card vs. OpenPGP-Nachrichten:** Die **Card**-Spezifikation definiert, wie das Token PINs, Schlüsselslots und Kartenoperationen über CCID bereitstellt. **GnuPG** nutzt dies über `scdaemon`. Das **OpenPGP-Nachrichtenformat** für Dateien und E-Mails (RFC 4880 und Nachfolger) ist eine **Host-Seite**: Die Karte liefert Schlüssel; GnuPG wendet das Nachrichtenformat auf dem PC an. Weder die Card-Spezifikation noch RFC 4880 definieren **Shamir-Splitting**, **ephemere ECDH-Sitzungen** oder **Cipher-Profile** – diese sind [firmwarespezifisch](#standards-vs-firmware-specific-features).
**Integrationsstatus:** Die OpenPGP- und CCID-Logik lebt in **`usb-personality`**, **`baochip-openpgp`** und dem **Xous**-Dienst **`usb-bao1x`** (siehe **xous-core**). Der optionale **`galdralag-service`** (`services/galdralag`) läuft als separater Xous-Prozess, verbindet sich mit **`usb-bao1x`** für **CCID**-IPC und überbrückt **PDDB**-Provisionierungsdaten in **RRAM**; Build und **`baosec`**-Registrierung: [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/services/galdralag/README.md) und **`cargo run -p xtask -- build-and-register`**. Speicherlayout: [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/RRAM_LAYOUT.md). **End-to-End-GnuPG auf echter Hardware** erfordert noch ein vollständiges Xous-Image (mit **`ccid-openpgp`**), einen funktionierenden Host-CCID-Stack (`pcscd`, Treiber) und Punkte unter [Bekannte Einschränkungen / offene Arbeiten](#known-limitations--open-work), die für Ihr Auslieferungsziel adressiert sind.
## Token-Sitzung und Schlüsselexport
**Physisches Trennen (Abziehen):** Der Host verliert das USB-Gerät; jeder laufende Vorgang schlägt fehl, bis der Token wieder angeschlossen und neu enumeriert wird. Auf dem Gerät wird die OpenPGP-**Card-Sitzung** gelöscht: Der **PIN-Verifikationszustand** überlebt das Ausschalten oder Entfernen nicht, sodass **Signieren, Entschlüsseln und andere geschützte Operationen nach erneuter Verbindung eine erneute PIN-Eingabe erfordern**, wie bei anderen OpenPGP-Smartcards. **Privates Schlüsselmaterial bleibt im versiegelten Tresorspeicher auf dem Token**; das Abziehen löscht es nicht, es sei denn, ein separater **Nullstellungs-** oder Löschpfad wird ausgeführt.
**Was das Gerät verlassen darf:** Konstruktionsbedingt ist nur **öffentliches Schlüsselmaterial** berechtigt, die USB-Verbindung zu überqueren (z. B. OpenPGP-**öffentliche** Schlüsselpakete und zugehörige Daten, die die Card-Spezifikation dem Host bereitstellt). **Private** Schlüssel, rohe geheime Skalare und versiegelte Schlüsselblobs **verlassen** das Gerät in normalen Firmware-Pfaden **nicht**; private Schlüsseloperationen laufen **auf dem Token**. Der Host erhält **kryptografische Ergebnisse** (Signaturen, entschlüsselten Klartext für Card-unterstützte Entschlüsselungsworkflows), wenn die Standardbefehle dies erfordern, jedoch keine portable Kopie des privaten Schlüssels.
**Importieren von Schlüsseln auf das Gerät:** Es ist auch möglich, **öffentliche Schlüssel** in den Token zu importieren (z. B. Vertrauensanker, Peers-Zertifikate oder OpenPGP-öffentliche Pakete für die On-Device-Verifikation). Der Firmware-**Tresor** bietet **Public-Key-Slots** für nicht geheimes Material (`crates/vault/src/public_key_vault.rs`). Host-Tooling zum Laden dieser Slots wird in [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md) beschrieben, sobald die Integration reift.
---
## Web of Trust und Key-Signing-Partys
OpenPGP und **GnuPG** verwenden ein dezentrales Vertrauensmodell – das **Web of Trust** – um zu helfen zu verifizieren, wem welche Schlüssel gehören und ob einem bestimmten **öffentlichen Schlüssel** vertraut werden soll. Dieses Modell ist vollständig **Host-seitig**. Wo Chip-gestützte Beglaubigungen wie [German eID and Governikus](#german-eid-and-governikus-as-a-trust-anchor-for-public-keys) nicht verfügbar oder ungeeignet sind, ist es die übliche dezentrale Alternative (**Key-Signing-Partys**, Signaturen auf Zertifikaten); wo sie **verfügbar** sind, können beide Ansätze als komplementäre Pfade koexistieren.
**Galdralag-Fingerabdruck (`G:`):** Für persönliche Verifikations-Workflows kann **Galdra** einen **gerätegebundenen** Fingerabdruck anzeigen, der vom **SIG**-Public-Key des Tokens abgeleitet ist (**BLAKE3-160**, `G:`-Präfix). Es ist **kein** OpenPGP-v4-Zertifikatsfingerabdruck. Es ist **nur** verfügbar, wenn das aktive **Cipher-Profil** **`ephemeral_ecdh: false`** hat; eingebaute Profile standardmäßig **`ephemeral_ecdh: true`**, daher fügen Sie für Workflows, die diese Kennung neben **WoT**-ähnlicher Host-Signatur benötigen, typischerweise ein Benutzerprofil mit **`galdra profile add ... --no-ephemeral-ecdh`** hinzu. Definition in einfacher Sprache und Formatspezifikation: [Galdralag-Fingerabdruck](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md#g). Lebenszyklus, Rotationsrichtlinie und das ephemere ECDH-Gate: [KEY_LIFECYCLE.md — Galdralag-Fingerabdruck](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/KEY_LIFECYCLE.md#galdralag-fingerprint-host).
### Abrufen Ihres Galdralag-Fingerabdrucks
Der Host gibt einen String aus, der **immer mit `G:` beginnt** (BLAKE3-160 über die SIG-öffentlichen Schlüsselbytes, **40 hexadezimale Kleinbuchstaben** nach dem Präfix in kanonischer Form).
1. Installieren Sie **[Galdra](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md)** auf dem Host und stellen Sie sicher, dass **PC/SC** funktioniert (**`pcscd`**, **`libpcsclite`**), damit das Tool CCID mit dem Token sprechen kann (siehe [Compile and install host tools](#compile-and-install-host-tools-galdra-galdrad-galdra-gtk)).
2. Verbinden Sie den Token (entsperren Sie ihn, wenn Ihr Workflow dies erfordert).
3. Wählen Sie ein **Cipher-Profil** mit **`ephemeral_ecdh: false`**. Bestätigen Sie mit **`galdra profile show <name>`** (`ephemeral_ecdh: off`). Der Standardprofilname **`standard`** hat normalerweise **`ephemeral_ecdh: on`**; erstellen Sie bei Bedarf eines mit **`galdra profile add <name> ... --no-ephemeral-ecdh`**.
4. Führen Sie aus:```bash
galdra identity fingerprint
# If you use a non-default profile:
galdra identity fingerprint --profile <name>
Maschinenlesbare Ausgabe: galdra --emit json identity fingerprint (optional --profile <name>).
OpenPGP-konforme Implementierungen enthalten ein Zertifikatsprüfungsschema, das bei der Überprüfung der Schlüsseleigentümerschaft hilft; sein Betrieb wird als Web of Trust bezeichnet. OpenPGP-Zertifikate (ein oder mehrere öffentliche Schlüssel plus Besitzer-/Benutzer-ID-Material) können von anderen Benutzern digital signiert werden, die dadurch die Verbindung zwischen diesem öffentlichen Schlüssel und der im Zertifikat genannten Person oder Entität bestätigen.
gpg --full-generate-key auf dem Host erstellt wurde, oder auf einem OpenPGP-fähigen Token).Eine Key-Signing-Party ist ein persönliches Treffen, bei dem die Teilnehmer Schlüsselfingerabdrücke austauschen und die Identität des jeweils anderen überprüfen, bevor sie später Zertifikate signieren.
Typische Merkmale:
Das ergibt einen sozialen Graphen: Wenn Alice Bob vertraut und Bob Charlies Schlüssel signiert hat, kann Alice sich entscheiden, Charlies Schlüssel zu vertrauen, abhängig von Vertrauenstiefe und -richtlinie.
Warum solche Veranstaltungen wichtig sind:
Partys vermeiden normalerweise Computer während des Identitätsaustauschs, sodass Angreifer weniger Chancen haben, ausgetauschte Schlüssel oder Malware auf gemeinsamen Rechnern einzuschleusen.
Vor der Veranstaltung. Berechnen und notieren Sie Ihren Fingerabdruck (einen aus dem Hash abgeleiteten Digest des öffentlichen Schlüssels – kurz genug, um zuverlässig zu vergleichen). Verlassen Sie sich nicht darauf, zu diesem Zeitpunkt vollständige Schlüssel auf Papier auszutauschen, es sei denn, Ihre Organisatoren geben etwas anderes vor.```bash
gpg --fingerprint YOUR_KEY_ID
Bringen Sie den Fingerabdruck auf Papier oder einem anderen dauerhaften Medium an (Beispielform: `ABCD 1234 EFGH 5678 90AB CDEF 1234 5678 90AB CDEF`).
**Während der Veranstaltung (nur Fingerabdrücke).** Tauschen Sie **Fingerabdrücke** aus, überprüfen Sie die IDs und notieren Sie, welche Fingerabdrücke zu welcher verifizierten Person gehören. Bestätigen Sie, dass die behauptete Identität jedes Teilnehmers mit den geprüften Dokumenten übereinstimmt.
**Nach der Veranstaltung.** Rufen Sie die vollständigen **öffentlichen Schlüssel** von **Keyservern** oder durch direkte Verteilung ab; bestätigen Sie, dass die heruntergeladenen Schlüssel mit den auf Papier notierten **Fingerabdrücken** übereinstimmen; **signieren** Sie die von Ihnen verifizierten Schlüssel; laden Sie die Signaturen optional **hoch**, damit andere sie nutzen können.
### Fingerabdrücke anstelle vollständiger Schlüssel bei der Veranstaltung
- **Operative Sicherheit.** Verhindert, dass Substitutionsangriffe mit verifizierten Fingerabdrücken verknüpft werden, anstatt während der Veranstaltung willkürlichen Maschinen zu vertrauen.
- **Einfachheit.** Fingerabdrücke passen auf Papier und lassen sich schnell vorlesen oder vergleichen.
- **Verifizierung.** Nach dem Herunterladen wird durch Neuberechnung des Fingerabdrucks die Integrität durchgehend geprüft.
### Keyserver
**Keyserver** sind vernetzte Repositorien, die **öffentliche** OpenPGP-Schlüssel (sowie Aktualisierungen wie Signaturen und Widerrufszertifikate) speichern und replizieren. Sie machen Schlüssel über **User ID**, **Key ID** oder **Fingerabdruck** auffindbar und ermöglichen eine breitflächige Verteilung für das Vertrauensnetz.
So verhalten sie sich im Prinzip:
- **Verteilte Replikation.** Das Hochladen auf einen Server, der an einem Sync-Mesh teilnimmt, verbreitet sich oft auf Peers (klassische **SKS**-ähnliche Pools funktionierten auf diese Weise).
- **Synchronisation.** Neue Schlüssel, Signaturen und Widerrufszertifikate verbreiten sich gemäß den Richtlinien und der Konnektivität jedes Servers.
- **Öffentlicher Lesezugriff.** Nur **öffentliches** Material ist zur Veröffentlichung bestimmt; **private Schlüssel** dürfen niemals hochgeladen werden.
**Datenschutz.** Veröffentlichte Schlüssel legen **User IDs** offen (häufig einschließlich E-Mail-Adressen). Behandeln Sie Uploads als **öffentlich und langlebig** auf vielen Servern; laden Sie **Widerrufszertifikate** hoch, wenn ein Schlüssel zurückgezogen werden muss. Die Richtlinie variiert je nach Betreiber ([keys.openpgp.org](https://keys.openpgp.org/) unterscheidet sich von Legacy-Pools).
**Peer-Topologie.** Graphen der Serverbeziehungen erscheinen unter [spider.pgpkeys.eu/graphs/](https://spider.pgpkeys.eu/graphs/); SKS-orientierte Peer-Listen unter [spider.pgpkeys.eu/sks-peers](https://spider.pgpkeys.eu/sks-peers).
### Keyserver verwenden```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 | Anmerkungen |
|---|---|
| keys.openpgp.org | Weit verbreitet; zustimmungsorientierte Verifizierung für E-Mail-verknüpfte Benutzer-IDs |
| pgp.mit.edu | Von MIT gehosteter Server, historisch mit SKS-Ära-Meshes verbunden |
| pool.sks-keyservers.net | Legacy-Pool-Hostname, verbunden mit dem ehemaligen SKS-Ökosystem; Erreichbarkeit variiert heute |
gpg --refresh-keys aus, damit Widerrufe und neue Signaturen lokal propagiert werden.galdra profile show <name>, dass das aktive Profil ephemeral_ecdh: false hat.Für das autoritative Verhalten von gpg, Vertrauensmodelle und Verteilungsoptionen siehe das GnuPG-Handbuch und die Upstream-Dokumentation.
Das Fulla-Projekt (Supermagnum/Fulla auf GitHub) beherbergt die WoT-konforme Registrierungsserver-Arbeit: Implementierung und sich entwickelnde Spezifikation zum Speichern öffentlicher Schlüssel von Mitwirkenden sowie optionaler Amateurfunk-Label, Post-Hinweise, organisation (JSON-Schreibweise), role, note, badge_number, phone_number und verwandte Spalten, die mit Galdra-Kontaktmetadaten abgestimmt sind. galdra keyserver push sendet POST /api/v1/keys JSON (einschließlich armored_public_key, email und dieser optionalen Felder, wenn Sie CLI-Flags übergeben); galdra keyserver fetch und die [keyserver]-Konfigurationsstanza sind in / entsprechend dieser Richtung implementiert. ; ein öffentlich betriebener Dienst wird in Zukunft erwartet. Zusätzlicher historischer Entwurfstext befindet sich in .
Verschiedene Teile dieses Projekts entsprechen unterschiedlichen Standards. GnuPG-Interoperabilität ist auf das beschränkt, was die OpenPGP-Kartenanwendung und CCID definieren. Andere Funktionen sind in der Firmware (und manchmal in Galdra-Host-Tools) implementiert, aber nicht etwas, das Sie über standardmäßige gpg-Karten-Workflows aufrufen können.
Für das tägliche Karten-Verhalten verlassen Sie sich auf docs/OPENPGP_CARD.md. Für tresor-exklusive oder token-spezifische Funktionen verwenden Sie die Firmware dieses Repositorys und die Galdra-Tool-Dokumentation.
Die OpenPGP-Karte und GnuPG-Stacks definieren kein Shamir's Secret Sharing (SSS) für Schlüssel oder zum Entsperren von Datenträgern. SSS ist dennoch neben der normalen Verschlüsselung nützlich: Es ersetzt fast nie die symmetrische Chiffre auf der Festplatte — es schützt das kleine Geheimnis (Master-Schlüssel oder Passphrase), das diese Verschlüsselung entsperrt.
Muster (immer die gleiche Idee):
1. LUKS (Linux) und externes SSS
LUKS verschlüsselt das Volume mit einem Master-Schlüssel. Sie können diesen Schlüssel (oder ein Key-Slot-Geheimnis, je nach Verfahren) extrahieren, mit einem SSS-Werkzeug aufteilen und die Anteile getrennt speichern. Zum Entsperren kombinieren Sie K Anteile, rekonstruieren das Schlüsselmaterial und übergeben es an cryptsetup (siehe Dokumentation Ihrer Distribution; falscher Umgang mit Schlüsseln kann den Zugriff blockieren).
Beispielhafte Verwendung der ssss-Dienstprogramme ("Shamir's Secret Sharing Scheme") (Namen und Paketierung variieren je nach Betriebssystem):```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) verwendet Shamir zum **Entsiegeln**: der Speicherverschlüsselungsschlüssel wird bei der Initialisierung aufgeteilt (z. B. 3-von-5 Operatoren haben jeweils einen Anteil). Nach einem Neustart müssen **K** Anteile eingegeben werden, um zu entsiegeln. Das gleiche **K-von-N auf einem Masterschlüssel**-Muster wie bei LUKS, angewendet auf eine Secrets-Engine statt auf ein Blockgerät.
**3. Galdralag firmware (`vsss-rs`)**
Dieses Repository verwendet [`vsss-rs`](https://crates.io/crates/vsss-rs) (RustCrypto-Ökosystem) für Shamir auf dem Gerät. Die gleiche **Schichtung** gilt, wenn Sie sie mit Bulk-Verschlüsselung kombinieren:
- Generieren Sie einen zufälligen 256-Bit (oder angemessenen) Masterschlüssel.
- Verschlüsseln Sie das Laufwerk oder den Bulk-Speicher mit **AES-GCM** oder **ChaCha20-Poly1305** unter Verwendung dieses Schlüssels (dies entspricht den geprüften symmetrischen crates des Arbeitsbereichs).
- Verwenden Sie `vsss-rs`, um den Masterschlüssel in **N** Anteile mit Schwellwert **K** aufzuteilen.
- Speichern Sie die Anteile in Vault-Slots, anderen Geräten oder bei Schlüsselinhabern.
- Sammeln Sie beim Booten oder Wiederherstellen **K** Anteile, rekonstruieren Sie, und verwenden Sie dann **HKDF** (oder Ihre Richtlinie) für domänengetrennte Unterschlüssel, falls erforderlich.
**4. VeraCrypt**
VeraCrypt implementiert SSS nicht intern. Das gleiche **externe** Muster gilt: Teilen Sie das **Passwort oder das Keyfile-Material** mit einem SSS-Werkzeug; versuchen Sie nicht, den Chiffretext des Volumes mit Shamir aufzuteilen.
### Hybridmuster (große Datenmengen)
SSS ist für **kleine Geheimnisse** (Schlüsselgröße). Sie wenden Shamir **nicht** auf Multi-Gigabyte-Chiffretext an. Die übliche Schichtung:```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)
Das deckt sich mit dem, was dieses Projekt bereits beinhaltet: aes-gcm / chacha20poly1305 für ruhende Daten, vsss-rs zur Aufteilung des Masterschlüssels, hkdf zur Ableitung nach der Rekonstruktion.
| Entscheidung | Typische Optionen |
|---|
Der operative Schlüsselumgang mit LUKS und vollständiger Festplattenverschlüsselung ist sicherheitskritisch; befolgen Sie die Anleitungen und Bedrohungsmodelle des Herstellers und der Distribution für Ihre Umgebung.
Ein konkretes Muster ist ein Laufwerk oder Volume, das mit Brainpool-Kurven verschlüsselt ist, wenn Ihr Stack diese benötigt (z. B. ECDH/ECDSA um einen Masterschlüssel), kombiniert mit Shamir's Secret Sharing auf dem Schlüsselmaterial, das diese Verschlüsselung entsperrt (das gleiche Small-Secret-Layering wie oben: SSS schützt den Schlüssel, nicht Multi-Gigabyte-Chiffretext). Wenn und sobald die Firmware und die Hostsoftware, die diesen Workflow implementieren, unabhängig auditiert wurden, kann eine solche Kombination für Organisationen wertvoll sein, die sowohl Quorum-Richtlinien als auch nationale Kryptoprofile gleichzeitig erfüllen müssen.
Warum Brainpool-Kurven (z. B. BrainpoolP256r1, BrainpoolP384r1) in diesem Zusammenhang oft diskutiert werden:
Szenarien, in denen die Kombination von SSS mit Brainpool-Kryptografie institutionelle Bedürfnisse adressiert (illustrativ; keine rechtliche oder Compliance-Beratung):
Falls eine Governikus-artige OpenPGP-Signierung oder eine vergleichbare chipbasierte nationale eID-Beglaubigung für Ihre Gerichtsbarkeit oder Ihren Workflow nicht verfügbar oder praktikabel ist, beschreibt Web of Trust und Key Signing Parties einen alternativen hostseitigen Ansatz basierend auf persönlicher Verifizierung und Drittsignaturen auf Zertifikaten.
Governikus OpenPGP-Key-Authentifizierung ist ein Online-Dienst, der im Auftrag des BSI (Bundesamt für Sicherheit in der Informationstechnik) betrieben wird. Nachdem der Einsender sich mit einer deutschen eID-fähigen ID-Karte, einer EU eID-Karte für EU-Bürger oder einem elektronischen Aufenthaltstitel authentifiziert hat, prüft der Dienst, ob der authentifizierte rechtliche Name mit der OpenPGP-User ID auf dem hochgeladenen öffentlichen Schlüssel übereinstimmt. Falls ja, signiert Governikus diesen öffentlichen Schlüssel mit dem Dienstsignierschlüssel, sodass Dritte die Beglaubigung überprüfen können.
Ein praktischer Workflow mit dieser Firmware: Generieren Sie einen Brainpool-asymmetrischen Schlüssel auf dem Token (OpenPGP-Kartengenerierung wie üblich), exportieren Sie den öffentlichen Schlüssel oder das Zertifikat auf den Host, führen Sie den Governikus-Übermittlungsablauf inklusive eID-Authentifizierung (typischerweise AusweisApp und NFC-Kartenlesen) durch und verwenden Sie den signierten öffentlichen Schlüssel, der vom Dienst zurückgegeben wird (z. B. aus E-Mail-Verteilung). Der private Schlüssel bleibt auf Galdralag.
Keiner der beiden Wege ersetzt den anderen. Die eID und der Governikus-Schritt binden den öffentlichen Schlüssel an eine gegenüber dem Chip verifizierte Identität zum Zeitpunkt der Übermittlung; sie liefern keine Perfect Forward Secrecy, kein Shamir K-of-N für langfristiges Schlüsselmaterial oder Chiffreprofile für Massendaten – dies sind firmwarespezifische Funktionen, die an anderer Stelle in dieser README beschrieben werden. Der eID-Chip und der umgebende Ausstellungsprozess implementieren ebenfalls nicht von sich aus das ephemere ECDH- und Kaskadenverhalten des Tokens. Umgekehrt passt ein auf dem Gerät generierter Brainpool-OpenPGP-Schlüssel zwar zum bereits für Brainpool-Institutionelle Nutzung diskutierten BSI/EU-Einsatzkontext, aber ohne einen externen Beglaubigungsschritt müssen Korrespondenten auf andere Mittel zurückgreifen, um einen Fingerabdruck mit einer natürlichen Person zu verknüpfen.
| Ebene | Rolle |
|---|---|
| Öffentlicher OpenPGP-Schlüssel (z. B. Brainpool auf Galdralag) | Kryptografische Struktur und On-Token-Private-Key-Kontrolle; Kurvenwahl folgt BSI TR-03111-klassen Erwartungen (siehe die und die TR-03111-Diskussion in ) |
Einschränkung: Die Verifizierung ist namenbasiert. Wenn zwei Personen den gleichen rechtlichen Namen in den vom Dienst verglichenen Feldern haben, unterscheidet die Beglaubigung sie nicht; sie bestätigt die Identitätsverknüpfung mit diesem Namen zum Zeitpunkt der Beglaubigung, nicht die globale Eindeutigkeit. Übliche OpenPGP-Bedenken (E-Mail-Bindung, Schlüsselrollover, Widerruf) bleiben bestehen.
Policy-Konformität: Dasselbe BSI, das Brainpool-bezogene technische Leitlinien definiert (BSI TR-03111; Konformitätsvektoren unter crates/vault/tests/bsi_vectors/), steht auch hinter dem Governikus-eID-Signierprozess, was in deutschen und EU-Umgebungen oft relevant ist, in denen Brainpool bereits erforderlich oder bevorzugt ist – siehe Shamir plus Brainpool: Beispiel und institutionelle Eignung.
Weiterer Rahmen (Forschungsnotiz, keine abgeschlossene Erhebung): Das gleiche Muster – Bindung eines öffentlichen OpenPGP-Schlüssels an eine chipverifizierte Identität – ist prinzipiell überall dort anwendbar, wo nationale eID existiert; welche Anbieter einen Governikus-ähnlichen Signierschritt anbieten und unter welchen Regeln, ist eine separate Frage, die es wert ist, bei Ausweitungen untersucht zu werden. Andere EU-Mitgliedstaaten betreiben kartenbasierte eID-Ökosysteme unter eIDAS, die vergleichbare oder stärkere Vertrauensanker als der deutsche Weg allein unterstützen könnten; diese README katalogisiert sie nicht.
Estland und Belgien haben beide NIST P-384 auf dem Chip übernommen, nicht Brainpool, während Deutschlands öffentliches BSI-Profil auf Brainpool zentriert ist (siehe oben). Galdralag unterstützt bereits Brainpool, NIST P-256/P-384 und RSA für OpenPGP-fähige Nutzung (Asymmetrisch / Schlüsselvereinbarung), sodass das gleiche Vertrauensankermuster nicht allein von der Übereinstimmung mit Deutschlands Kurvenpräferenz abhängt.
Außerhalb des EU/EWR ist das kartenbasierte Vertrauensankermuster schwieriger anzuwenden: die USA haben eine Chipkarte (PIV), aber sie ist auf Bundespersonal beschränkt und befindet sich in X.509/FPKI, nicht in OpenPGP integriert; Kanada hat keine nationale On-Chip-Signierkarte im oben verwendeten Sinne. Das schränkt das Muster hauptsächlich auf Rechtsräume mit universell ausgestellten staatlichen Chip-Ausweisen ein – der EU eIDAS-Raum ist derzeit das Gebiet, in dem das Modell am stärksten ist.
Wenn und sobald die Hardware einen verbraucherreifen Zustand erreicht, müssten Personen, die möchten, dass Shamir's Secret Sharing und authentifizierter ephemerer Schlüsselaustausch Teil des interoperablen OpenPGP / GnuPG-Verhaltens werden (anstatt nur firmwarespezifischer Funktionen), Standardisierungs- und Implementierungsänderungen anderweitig vorantreiben. Dieses Repository spricht nicht für die IETF oder GnuPG; die folgenden Orte sind die, an denen solche Änderungen normalerweise verfolgt werden.
CESS — Cryptologically Enchanted Shamir's Secret — ist ein offener kryptografischer Standard für Threshold Secret Sharing zusammen mit chiffreunabhängiger authentifizierter Verschlüsselung, passwortbasierter Aktienverpackung und optionalem Post-Quantum-Hybrid-Schlüsselaustausch. Das CESS-Repository enthält die normative Spezifikation, Algorithmen-Registry, Testvektoren und den Konformitätstester.
Diese Firmware ist konform zu CESS für die hier implementierten Konstruktionen: Die interoperablen Aktien- und Umschlagregeln der Spezifikation stehen neben den gleichen Shamir-, Brainpool- und Chiffreprofil-Themen, die an anderer Stelle in dieser README beschrieben werden. Der normative Text ist getrennt von diesem Repository; Konformitätsposition (was der Spezifikation entspricht, was abweicht, während Algorithmen wie AES und SHA-256 in Profilen beibehalten werden, und Fahrplan zu stärkerer Interoperabilität): docs/CESS_CONFORMANCE.md.
Falls die Maintainer dieses GitHub-Repositorys nicht auf Issues, Pull Requests oder E-Mails antworten, können Sie neue Chiffren, OpenPGP-Verhalten und standardsbezogene Arbeit dennoch im weiteren Ökosystem vorantreiben. Sequoia PGP ist ein unabhängiger, in Rust geschriebener OpenPGP-Stack (Speichersicherheit, bibliothekszentriertes Design, aktive IETF/Ökosystem-Teilnahme), in dem viel öffentliche Entwicklung stattfindet. Es ist nicht dieses Projekt; es wird hier als praktischer alternativer Weg dokumentiert, falls der Upstream hier schweigt.
Die Contributing-Seite beschreibt die Lizenzierung (LGPL 2.0 oder neuer für die meisten Projekte), die Developer Certificate of Origin und dass größere kommerzielle Funktionen möglicherweise vorherige Vereinbarung und langfristige Wartungsvereinbarungen erfordern – lesen Sie diese Seite, bevor Sie erheblichen Aufwand investieren.
Es lohnt sich auch, https://autocrypt2.org/#/ im Auge zu behalten.
Diese Codebasis und die zugehörigen Apps werden nicht für macOS oder Windows kompiliert. Die Host-Tools (galdra, galdrad, galdra-gtk) und die unterstützenden Werkzeuge zielen auf Linux. Dies ist eine bewusste Entscheidung basierend auf dem Bedrohungsmodell des Projekts und den in diesem Dokument dargelegten Überprüfbarkeitsanforderungen.
_NSAKEY, die 1999 in Windows NT entdeckt wurde, verursachte erhebliche Kontroversen. Microsoft gab an, es sei ein Ersatzschlüssel; dies wurde nie vollständig bewiesen oder widerlegt.Vermutet, aber unbewiesen:
main, restricted, universe und multiverse sind mit dem GPG-Schlüssel von Canonical signiert.security.ubuntu.com, das ebenfalls signiert ist.Paketmanager sind im Allgemeinen sicher, aber Drittanbieter-.deb/.rpm/AppImage-Installationen können unsicher sein. Bevorzugen Sie signierte Pakete aus vertrauenswürdigen Repositorys und überprüfen Sie Signaturen, bevor Sie etwas installieren, das außerhalb dieser bezogen wurde.
Verwenden Sie eine stabile Rust-Werkzeugkette, wie in rust-toolchain.toml festgelegt. Die Firmware verwendet das Ziel riscv32imac-unknown-none-elf; Host-Tools verwenden das Host-Tripel.
test-hal in Produktionsbuilds gelangen würde): ```bash
cargo run -p xtask -- check-fw
Object code and archives land under target/riscv32imac-unknown-none-elf/release/. A full bootable Xous system image for a specific board is produced by the wider Baochip / Xous integration flow when you follow that product's build; xtask here runs cargo build for the firmware library crates listed in xtask (not a single ready-to-flash file by itself).
galdralag-service) — needs the riscv32imac-unknown-xous-elf Xous toolchain (not the bare riscv32imac-unknown-none-elf firmware triple above). From repo root: cargo run -p xtask -- build-and-register release. That rebuilds the ELF, verifies it on disk, prints the baosec cratespec, and optionally runs cargo xtask baosec when given --xous-core /path/to/xous-core. Details: services/galdralag/README.md.This repository does not ship a one-command flasher yet. Programming the Baochip-1x (JTAG, ROM/USB boot, or vendor tools) follows the board and silicon documentation. Start from Supermagnum/Baochip-1x-firmware; eval board hardware is in baochip/dabao — on the Dabao board, SW2 toggles bootloader mode (see that schematic).
Committing UF2 without the physical boot button: After copying loader.uf2, xous.uf2, and apps.uf2 to the BAOCHIP volume, you can either press the physical boot button or type boot in the boot1 USB serial console (1 000 000 baud, e.g. screen /dev/ttyACM0 1000000). That avoids relying on the boot button for this step only. The console disconnects when you type boot; that is expected (the system reboots into the next stage). On Linux, dmesg --follow helps confirm USB re-enumeration. This is distinct from PROG (hold while connecting USB to enter the BAOCHIP mass-storage bootloader). See baochip/dabao#2 (closed).
Xous / Baochip flow: Images are Ed25519-signed and verified by boot0 before execution; see Signed firmware (Ed25519, boot0). For dabao, UF2 layout, holding PROG while plugging USB to enter mass-storage mode, and boot1 update steps, see Getting Started with Baochip Targets.
galdra, galdrad, galdra-gtk)Host crates live at the workspace root: galdra/, galdrad/, galdra-gtk/.
Ubuntu / Debian (install before cargo build / cargo install):```bash
sudo apt update
sudo apt install build-essential pkg-config libpcsclite-dev pcscd libssl-dev
galdra-gtk:sudo apt install libgtk-4-dev
`libpcsclite-dev` erfüllt den **Standard**-Link-Pfad für **`galdra`**/**PC/SC**; **`pcscd`** ist der Daemon, der Smartcard-Lesegeräte zur Laufzeit bedient. **`libssl-dev`** wird benötigt, damit **openssl-sys** linken kann (**sequoia-net**-Schlüsselserver-Abfragen und **ldap3**-TLS verwenden heute **native-tls**). Lassen Sie **`libgtk-4-dev`** weg, wenn Sie nie **`galdra-gtk`** bauen.
**GTK 4 (nur `galdra-gtk`):** `pkg-config` muss **gtk4** auflösen (Workspace-Crate **`gtk`** 0.9.x, Paket **`gtk4`**). Verwenden Sie auf Fedora **`gtk4-devel`**; auf Arch **`gtk4`**.
Erstellen Sie Release-Binärdateien aus dem Repository-Stammverzeichnis:```bash
cargo build --release -p galdra -p galdrad -p galdra-gtk
Ausführbare Dateien: target/release/galdra, target/release/galdrad, target/release/galdra-gtk.
Installieren in ~/.cargo/bin (passen Sie --path an, wenn Sie sich nicht im Repository-Root befinden):```bash
cargo install --locked --path galdra
cargo install --locked --path galdrad
cargo install --locked --path galdra-gtk
Sie können stattdessen diese drei Binärdateien in ein beliebiges Verzeichnis in Ihrem `PATH` kopieren.
### Ausführen von `galdrad` und der Desktop-GUI (`galdra-gtk`)
**`galdra-gtk`** ist die GTK4-Desktop-Binärdatei (Cargo-Paket **`galdra-gtk`**; es gibt kein **`galdra-gui`**). Es ist ein Frontend zur **`galdrad`** REST-API — führen Sie zuerst **`galdrad`** aus.
**Daemon** — **`galdrad`** hört standardmäßig auf **`127.0.0.1:8742`** (`--listen` überschreibt); siehe [`galdrad/src/main.rs`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/galdrad/src/main.rs).```bash
galdrad
Schnelltest: curl -s http://127.0.0.1:8742/health (interaktive API-Dokumentation: http://127.0.0.1:8742/swagger-ui/.)
Desktop-GUI — galdra-gtk verwendet standardmäßig http://127.0.0.1:8742 (--base-url oder GALDRAD_URL); siehe 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
Ab einem frischen **`cargo build --release`**, ohne Installation: **`./target/release/galdrad`** danach **`./target/release/galdra-gtk`** aus dem Repository-Stammverzeichnis.
**Host vs Token:** **`galdra-gtk`** spiegelt wider, was **`galdrad`** über HTTP bereitstellt; Token **unlock**, **provision** und andere CCID-Abläufe bleiben in der **`galdra`**-CLI (siehe **`galdra device`** in **[docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md)** und Ebene **2c**).
**Kontaktverzeichnis (`galdra contact`, `galdrad` `/contacts`):** das Erstellen eines Kontakts **erfordert eine E-Mail** (CLI: `--email`; HTTP: JSON-Feld `email`). Optionale Felder umfassen **Anzeigename** (`--name` / `name`), **Organisation** (**`--org`** / `org`), **Rolle**, **Abzeichen** (**`--badge`** / `badge`), **Notiz**, **Rufzeichen**, **Fluxer**, **Discord** und **IRC**-IDs, **Telefonnummer** (`--phone-number` / `phone_number`), plus **Posthinweise** (`street`, `country`, `postal_code`, `region`), Amateurfunk **`dmr_id`** und **`radio_affiliation`**. Diese Werte werden nur in lokalen SQLite-Metadaten gespeichert (sie werden **nicht** gegenüber externen Diensten **verifiziert**). **Das Nachschlagen** eines Kontakts (z.B. `galdra contact show`, `PATCH`/`DELETE`-Pfade, `galdrad` **`GET /contacts/{id}`**, Gruppenmitglieds-IDs oder **`POST /decrypt`** `recipient`) akzeptiert die Zeilen **UUID**, **Rufzeichen**, **E-Mail**, einen vollständigen **40-stelligen hexadezimalen OpenPGP v4-Fingerabdruck** (Leerzeichen werden ignoriert), diese sozialen IDs oder eine **DMR-Teilnehmer-ID** in **1..16777215** wenn als Dezimal-Token angegeben. **`galdra keyserver push`** kann viele der gleichen Bezeichnungen in ein Fulla-artiges Register spiegeln (**`organisation`**, **`role`**, **`note`**, **`badge_number`**, **`phone_number`**, Funk/Sozial/Post-Felder und Namen — siehe **`galdra keyserver push --help`**). Befehle und Feldbegrenzungen sind in **[docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md)** unter **Kontakte** und **Identitätsmodell** zusammengefasst.
### Uninstall host tools
Falls Sie `cargo install --path` wie oben verwendet haben:```bash
cargo uninstall galdra
cargo uninstall galdrad
cargo uninstall galdra-gtk
Wenn Sie Binärdateien manuell kopiert haben, entfernen Sie die von Ihnen hinzugefügten Dateien. Die Firmware wird nicht auf dem Host „installiert"; das Löschen oder Neuflashen des Geräts wird in Ihrer Hardwaredokumentation behandelt.
Die folgenden Punkte sind Galdralag-Firmware-Funktionen, keine Anforderungen der OpenPGP-Kartenanwendung oder von GnuPG.
Dreifaktor-sicherheitsbereites Modell — Besitz des USB-Tokens und Kenntnis der PIN werden in der Firmware heute erzwungen; ein optionaler biometrischer dritter Faktor ist nicht in diesem Repository implementiert (Platzhalter: docs/BIOMETRIC_API.md). Siehe docs/THREE_FACTOR_AUTH.md für Umfang und Grenzen.
Authentifiziertes flüchtiges ECDH auf dem Gerät — echte kryptografische Vorwärtssicherheit. Jede Sitzung erzeugt ein neues flüchtiges Schlüsselpaar auf dem Hardware-TRNG des Tokens. Der langfristige Schlüssel signiert das flüchtige Angebot, nimmt aber nie an der Schlüsselvereinbarung teil. Vergangene Sitzungen können nicht entschlüsselt werden, selbst wenn der langfristige Schlüssel vollständig kompromittiert ist. Nach Kenntnis der Projektautoren bietet kein kommerzielles Hardware-Sicherheitstoken dies als erstklassige Funktion.
Shamir K-von-N Geheimnisverteilung auf dem Gerät — der langfristige Schlüssel kann in N Anteile aufgeteilt werden, die K zur Wiederherstellung benötigen, wobei kein einzelner Inhaber den Schlüssel alleine wiederherstellen kann. Nach Kenntnis der Projektautoren bietet auch kein kommerzielles Token dies als erstklassige Funktion.
Chiffre-agnostisches Profilsystem — symmetrische Chiffren, ECDHE-Kurven und Shamir-Konfiguration werden zu benannten, prüfbaren Profilen kombiniert. Für Massendaten unter einem Profil wird der Klartext von innen nach außen verschlüsselt: Sie können bis zu vier verschiedene symmetrische AEADs übereinander stapeln — so können Sie drei unabhängige Chiffren in einem Profil verwenden (z.B. ChaCha20-Poly1305, dann Serpent-256, dann Twofish-256), oder eine vierte separate Schicht, wo die Richtlinie es erlaubt — mit keiner wiederholten Chiffre im selben Profil und unabhängigem HKDF-abgeleitetem Schlüssel- und Nonce-Material pro Schicht. Eingebaute Namen wie standard, conservative und conservative-shamir werden mit Schichten ausgeliefert; tiefere Stapel sind für fortgeschrittene oder benutzerdefinierte Profile. Vollständige Regeln und Drahtlayout: . Jede Profilauswahl wird im Prüfpfad protokolliert.
Alle Primitive stammen aus unabhängig geprüften Workspace-Abhängigkeiten. Nichts ist im Quellbaum implementiert.
pin-policy aufgerufen wird. Kurze Eingaben erhöhen den Zähler nicht.HMAC-SHA256(HostChallengeKey, nonce || passphrase) übertragen.Einstellen oder Anpassen des Versuchs-Schwellwerts: Das Zählerlimit wird geschrieben, wenn der Token erstmals bereitgestellt wird; es ist keine Laufzeit-gpg-Einstellung. Verwenden Sie das galdra-Host-Tool, nachdem Sie es erstellt haben:```bash
galdra device provision --pin-attempts 5
| Flag | Range | Default | Meaning |
|------|--------|---------|---------|
| `--pin-attempts` | 3–10 | **3** | Fehlgeschlagene PIN-Versuche erlaubt vor Sperrung / Nullstellung |
| `--min-pin-length` | 5–32 | **5** | Mindestlänge der Benutzer-PIN (alphanumerisch), in der Richtlinie gespeichert |
Lassen Sie beide Flags weg, um die Standardwerte zu verwenden (3 Versuche, mindestens 5 Zeichen). Beispiel mit beiden: `galdra device provision --pin-attempts 7 --min-pin-length 8`.
Die Richtlinie wird **auf dem Token gespeichert** (Vault-Richtlinie). Das Host-Tool kann den Schwellenwert **nach** der Bereitstellung nicht erhöhen oder senken, ohne den eigenen authentifizierten Verwaltungsablauf des Geräts zu durchlaufen; betrachten Sie die Bereitstellung als den Zeitpunkt, um für Ihr Bedrohungsmodell **3–10** zu wählen. Die Begründung (Standardwerte vs. höhere Grenzen) ist in [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md) im Abschnitt zur PIN-Richtlinie dargelegt.
---
## Post-Quanten-Status
### Implementiert – nicht geprüfte Crate (Feature-gated)
XMSS (RFC 8391, NIST SP 800-208) und LMS/HSS (RFC 8554, NIST SP 800-208)
sind hinter `--features pq-signatures` implementiert. Die zugrunde liegenden Rust-Crates
wurden nicht unabhängig geprüft. Siehe
[docs/PQ_SIGNATURES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/PQ_SIGNATURES.md) und
[docs/STATEFUL_SIG_STATE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/STATEFUL_SIG_STATE.md).
### Ausstehend unabhängige Prüfung – noch nicht implementiert
Diese Algorithmen sind NIST-standardisiert. Die Implementierung ist durch das Fehlen einer
unabhängig geprüften `no_std` Rust-Crate blockiert.
| Algorithmus | Standard | Wartet auf |
|-----------|----------|---------|
| ML-KEM | FIPS 203 | Geprüfte `no_std` Rust-Crate |
| ML-DSA | FIPS 204 | Geprüfte `no_std` Rust-Crate |
| SLH-DSA | FIPS 205 | Geprüfte `no_std` Rust-Crate |
| FN-DSA (FALCON) | FIPS 206 Entwurf | Standard-Finalisierung + geprüfte Crate |
| HQC | Entwurf ~2027 | Standard-Finalisierung + geprüfte Crate |
**Hinweis zu libcrux:** Ein wissenschaftlicher Artikel aus dem Jahr 2026 identifizierte spezifikationsbezogene Fehler in den formal verifizierten ML-KEM- und ML-DSA-Implementierungen von libcrux, einschließlich als unhaltbar erwiesener Beweise. Überprüfen Sie das libcrux-Änderungsprotokoll, bevor Sie es bewerten.
### Wird nicht implementiert
**BIKE** wurde im März 2025 zugunsten von HQC aus der NIST-Standardisierung ausgeschlossen. **NTRU**-Verschlüsselung wurde im Juli 2022 ausgeschlossen. Keines hat einen Weg zu einem NIST-Standard.
---
## Nullstellung – Hardware-Vorbehalt
Die Nullstellungsimplementierung ist **softwaremäßig korrekt, aber hardwaremäßig unverifiziert**. Sie wurde nur mit `test-hal`-Simulation getestet. Eine physikalische Verifikation auf Baochip-1x-Silizium (JTAG-Speicherinspektion, Ausfallsicherheit, Seitenkanalbestätigung) wurde noch nicht durchgeführt. Siehe [docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_VERIFICATION.md). Die beabsichtigte **Regionenreihenfolge** und **Layoutanker** für Vault-Subsysteme sind in [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/RRAM_LAYOUT.md) zusammengefasst; die **physikalische** Löschreihenfolge bleibt Plattform- und **boot0**-Integrationsarbeit.
---
## Testergebnisse
Maßgebliche Beschreibung: **[`docs/TEST_RESULTS.md#run-metadata`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/TEST_RESULTS.md#run-metadata)** (Commit, Umfang und wie Abschnitte organisiert sind). Diese Seite enthält die **Pipeline-Zusammenfassungstabelle**, Unit-Test-Summen, Vektorenabdeckung (Wycheproof, RFC, BSI TR-03111 ECDH + ECDSA, NIST CAVP, BLAKE3 Hash/Keyed-Hash/Derive-Key), **dudect**-Zeittabelle, Schlüssellebenszyklusprüfungen und **[Abschnitt 6 — cargo-fuzz](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/TEST_RESULTS.md#6-cargo-fuzz-libfuzzer)** (Matrizen, **`chacha_roundtrip`**, aufgezeichneter **`openpgp_dispatch`**-Lauf). **Sie** entscheiden, ob diese Ergebnisse ausreichen, um den Bau oder die Ausführung dieses Projekts zu versuchen; eine **virtuelle Maschine** bleibt optional, reduziert aber das Host-Risiko.```
cargo run -p xtask -- test-all
Firmware-orientierte Crates unter crates/ und Host-Binärdateien im Repository-Stammverzeichnis (siehe root Cargo.toml [workspace] für die autoritative Mitgliederliste):
Nicht in dieser Workspace-Tabelle als separate Crates: baochip-openpgp und services/galdralag werden über --manifest-path gebaut (siehe root Cargo.toml exclude und services/galdralag/README.md). Optionaler Massen-/Tarn-Block-Speicher (psram-store in Design-Dokumenten) ist noch kein Workspace-Mitglied; siehe docs/Psram.md, docs/dev-ref.md und docs/SDMMC_STORAGE_INTEGRATION.md.
Primitive werden nicht im Repository implementiert. Alle kryptografischen Arbeiten verwenden geprüfte Workspace-Abhängigkeiten des RustCrypto-Projekts (außer vsss-rs und der dalek-Familie, die unabhängig geprüft wurden):```
aes-gcm chacha20poly1305 ed25519-dalek x25519-dalek
hkdf pbkdf2 hmac sha2 sha3 blake2 blake3
vsss-rs zeroize subtle p256 p384
---
[Read more](https://github.com/supermagnum/galdralag-firmware)
| Feld | Zweck | Host (galdra SQLite) | Kontaktspeicher auf Chip | Format / Limit |
|---|
| Kontakt-ID | Stabile Host-Primärschlüssel | Ja | Nein | Text (id in SQLite) |
| Anzeigename | Menschenlesbare Bezeichnung | Ja | Ja | UTF-8-String; max. 240 Bytes pro Heap-Feld auf Chip |
| Primäre Mailadresse | Ja | Ja | UTF-8-String; Suche auf Chip per E-Mail-Scan | |
| Rufzeichen | Amateurfunk-Rufzeichen | Ja | Ja | 12 Bytes, NUL-aufgefüllt; Suche auf Chip |
| DMR-Teilnehmer-ID | DMR-Funk-ID | Ja | Ja | 32-Bit vorzeichenlos (0 = nicht vorhanden); Suche auf Chip |
| Badge-Nummer | Mitarbeiter- oder Ausweis-ID | Ja | Ja | UTF-8-String |
| Organisation | Behörde oder Arbeitgeber | Ja | Ja | UTF-8-String |
| Abteilung | Team oder Einheit | Ja | Ja | UTF-8-String |
| Rolle | Job- oder Funktionsbezeichnung | Ja | Ja | UTF-8-String |
| Notiz | Freitext-Kommentar | Ja | Ja | UTF-8-String |
| Funk-Zugehörigkeit | Club-, Netz- oder Allianz-Bezeichnung | Ja | Ja | UTF-8-String |
| Straße | Straßenanschrift | Ja | Ja | UTF-8-String |
| Land | Ländername oder -code | Ja | Ja | UTF-8-String |
| Postleitzahl | PLZ oder Postleitzahl | Ja | Ja | UTF-8-String |
| Region | Bundesland, Kreis oder Region | Ja | Ja | UTF-8-String |
| Fluxer-ID | Fluxer-Handle oder -ID | Ja | Ja | UTF-8-String |
| Discord-ID | Discord-Benutzer-ID | Ja | Ja | UTF-8-String |
| IRC-ID | IRC-Nick oder ähnliches | Ja | Ja | UTF-8-String |
| Telefonnummer | Sprach- oder SMS-Kontaktnummer | Ja | Nein | UTF-8-String; max. 32 Zeichen auf Host; vom Einreichender erklärt, nicht verifiziert |
| Fingerprint | Schlüsselanker (Suche, Sync) | Ja (pgp_fingerprint) | Ja | 32 Bytes; OpenPGP v4-Stil auf der Leitung; nicht identisch mit einem G:-Geräte-Fingerprint |
| Öffentlicher Schlüssel | Verschlüsselungs-/Verifikationsmaterial | Ja (pgp_pubkey) | Ja (Schlüsselbereich) | Algorithmus: Ed25519, X25519, Brainpool P-256/P-384/P-512, NIST P-256/P-384, RSA-2048/3072/4096; bis zu 768 Bytes Blob auf Chip |
| PIN-geschützter Schlüssel | Schlüssel erfordert PIN-Entsperrung | Host speichert OpenPGP-Schlüssel separat | Ja | PIN-Verifikator-Digest + AES-GCM-Wrap-Metadaten auf Chip |
| Zuletzt abgerufen | Wann Schlüsselmaterial aktualisiert wurde | Ja (fetched_at) | Ja (last_fetched) | UTC auf Host; 32-Bit-Zeitstempel auf Chip |
| Läuft ab am | Schlüsselablaufzeit | Ja | Nein | UTC-Datetime nur in SQLite |
| Schlüsselquelle | Wie der Host-Datensatz erstellt wurde | Ja (source) | Nein | z.B. manuell, Keyserver, WKD, LDAP, Datei, Peer |
| Feldherkunft | Vertrauenslabel pro Metadatenfeld | Nein | Ja (source_map) | Zwei Bits pro Feld: SelfAttested, HostVerified, RegistrySync, OobVerified |
| Datensatzflags | Aktiv, veraltet, eigene Identität, widerrufen | Teilweise (Host-Logik) | Ja | z.B. STALE, SELF_KEY auf Chip |
fuzz/README.mddocs/TEST_RESULTS.md für den Umfang.| Metadatenfeld | OpenPGP / GnuPG | Galdra-Schlüssel (Host + Kontaktspeicher) |
|---|
| Kontakt-/Datensatz-ID | Nein (Schlüssel-ID oder Fingerabdruck verwenden) | Ja (SQLite id auf Host; nicht auf Chip) |
| Anzeigename | Nur innerhalb des Benutzer-ID-Textes (Name <email>) | Ja (separates UTF-8-Feld) |
| Nur innerhalb des Benutzer-ID-Textes | Ja (separates Feld; Suche nach E-Mail auf Chip) | |
| Straßenadresse | Kein Standardfeld | Ja |
| Land | Kein Standardfeld | Ja |
| Postleitzahl | Kein Standardfeld | Ja |
| Region / Bundesland | Kein Standardfeld | Ja |
| Organisation | Kein Standardfeld | Ja |
| Abteilung | Kein Standardfeld | Ja |
| Rolle / Position | Kein Standardfeld | Ja |
| Ausweis-/Mitarbeiter-ID | Kein Standardfeld | Ja |
| Rufzeichen | Kein Standardfeld | Ja (12 Bytes, NUL-aufgefüllt auf Chip) |
| DMR-Teilnehmer-ID | Kein Standardfeld | Ja (32-Bit; Suche auf Chip) |
| Funk-Zugehörigkeit | Kein Standardfeld | Ja |
| Fluxer-ID | Kein Standardfeld | Ja |
| Discord-ID | Kein Standardfeld | Ja |
| IRC-ID | Kein Standardfeld | Ja |
| Telefonnummer | Kein Standardfeld | Ja (nur Host-SQLite) |
| Freitext-Notiz | Kein Standardfeld | Ja |
| OpenPGP-v4-Fingerabdruck | Ja (40 Hex-Zeichen) | Optional auf Host-Zeile beim Verknüpfen eines Zertifikats (pgp_fingerprint); 32 Bytes auf Chip für Galdra-Schlüssel |
G:-Geräte-Fingerabdruck | Nein | Ja (BLAKE3-160 über SIG-öffentlichem Schlüssel; Host-Werkzeug; Nicht der OpenPGP-v4-Wert) |
| OpenPGP-Schlüssel-ID | Ja (kurze / lange Form) | Nein |
| Vertrauen / Herkunft | WoT-Signaturen auf Benutzer-IDs | Feldspezifische Labels: SelfAttested, HostVerified, RegistrySync, OobVerified (auf Chip) |
| Schlüsselablauf | Ja (Zertifikat / Unterschlüssel) | Nur Host (expires_at in SQLite) |
| Letzte Schlüsselabrufzeit | Abhängig vom Host-Werkzeug | Ja (fetched_at / last_fetched) |
| Privater Schlüssel auf Token | SIG-, DEC-, AUT-Karten-Slots | Separater Galdra-Schlüsselbereich (keine Benutzer-ID-Pakete) |
| PIN zur Verwendung des privaten Schlüssels | PW1 / PW3 (OpenPGP-Karte) | Optionale PIN-Umhüllung pro Galdra-Kontaktdatensatz |
| OpenPGP-Kartenobjekt (nicht in obiger Tabelle) | Host (GnuPG) | Auf Token |
|---|
| Primärer + SIG- / DEC- / AUT-Unterschlüssel | Öffentlich im Schlüsselbund | Privat in versiegelten Slots |
| Zertifizierungssignaturen (WoT) | Ja | Nein |
| Widerrufszertifikat | Ja | Nein |
| Algorithmusattribute (DO 0xC1 / 0xC2 / 0xC3) | gpg --card-edit | Ja |
galdragaldra-core-host| Bereich | Typischer Standard / Dokument | Als standardmäßige OpenPGP-Karte + GnuPG verfügbar? |
|---|
| OpenPGP-Kartenanwendung — APDUs, PINs, SIG/DEC/AUT-Slots, Generieren/Signieren/Entschlüsseln auf der Karte | OpenPGP-Kartenspezifikation (siehe docs/OPENPGP_CARD.md) | Ja — gleicher Host-Stack wie andere OpenPGP-Smartcards (gpg, scdaemon, CCID) |
| USB CCID — Kommunikation mit dem Gerät als Smartcard-Leser | USB-CCID-Geräteklasse | Ja — Klassentreiber |
| OpenPGP-Nachrichtenformat — verschlüsselte Dateien, E-Mail, Schlüsselpakete | RFC 4880 (und Aktualisierungen) | Ja auf dem Host — GnuPG verwendet dies; die Karte analysiert keine E-Mails |
| Shamir K-of-N — Aufteilen/Wiederherstellen von langfristigem Schlüsselmaterial im Tresor | Nicht in OpenPGP-Kartenspezifikation; nicht in GnuPG | Nein — nur Firmware und Bereitstellungswerkzeuge; keine gpg --card-edit-Operation (siehe Shamir und vollständige Festplattenverschlüsselung) |
| Authentifiziertes ephemeres ECDH — Vorwärtsgeheimes Sitzungsprotokoll auf dem Token | Nicht in OpenPGP-Kartenspezifikation | Nein — token-spezifisch; kein GnuPG-Kartenbefehl |
| Chiffre-Profil-System — benannte symmetrische Kaskaden (übereinander gestapelte unabhängige Chiffren; bis zu vier Ebenen, drei ist eine unterstützte Tiefe) und zugehörige Richtlinie | Nicht in OpenPGP-Kartenspezifikation | Nein — Firmware/Host-Token-Tools |
| microSD-Ablenkung / Massenspeicher-Personas — USB-Verhalten eines nicht informierten Hosts | Nicht in OpenPGP-Kartenspezifikation | Nein — separate USB-Persönlichkeits-Codepfade |
| WebAuthn / FIDO2 | CTAP / WebAuthn | Nicht implementiert — anderer Standard als OpenPGP-Karte |
| Ebene | Rolle |
|---|
| Festplatte | Verschlüsselt mit einem Master-Schlüssel (z.B. AES-256 via LUKS, VeraCrypt oder einer rohen Blockebene) |
| Master-Schlüssel | Mit SSS in N Anteile aufgeteilt, Schwelle K-of-N |
| Anteile | Gehalten von Personen, Geräten oder Offline-Speicher; K Anteile zusammen rekonstruieren den Master-Schlüssel |
| Entsperren | Schlüssel rekonstruieren, dann an cryptsetup, veracrypt oder Ihren Stack übergeben |
| Schwellenwert | 2-aus-3 (kleines Team, etwas Redundanz); 3-aus-5 (häufig in Organisationen) |
| Aktienspeicher | Hardware-Token, separate Rechner, Papier, geografisch getrennte Standorte |
| Aktienschutz | Verschlüsselung jeder Aktie für einen bestimmten Empfänger (z. B. mit dessen OpenPGP-Schlüssel) vor der Verteilung |
| Wo rekonstruieren | Air-Gapped-Rechner, HSM-Richtlinie oder kontrollierte Umgebung – nicht auf nicht vertrauenswürdigen gemeinsam genutzten Hosts |
| Szenario | Warum SSS plus starke, policy-konforme Kurven wichtig sind |
|---|
| Mitarbeiter verlässt das Unternehmen oder stirbt | Wiederherstellung bleibt ohne das exklusive Geheimnis dieser Person möglich |
| Rechtmäßiger Zugriff im Rahmen eines ordentlichen Verfahrens | Ein Quorum kann erforderlich sein – keine einzelne Partei besitzt das vollständige Entsperrgeheimnis |
| Unternehmens-Schlüsselhinterlegung | Prüfbarer Split; kein einzelner Administrator hat vollständigen Zugriff |
| Hardware-Beschlagnahme | Medien können beschlagnahmt werden, ohne K von N Aktien zu erfassen |
| Regulatorische Konformität (EU / BSI) | Brainpool erfüllt viele deutsche und EU-Regierungskryptografieanforderungen |
| Governikus-Signatur | Bestätigt, dass der Name auf dem Zertifikat mit der chipauthentifizierten Identität übereinstimmte, als der Benutzer den Ablauf durchführte |
| Rechtsraum | In diesem Dokument behandelter Status |
|---|
| Deutschland | Governikus/BSI-Ablauf wie oben beschrieben |
| Estland | Chipbasierte eID. Von RSA zu NIST P-384 (secp384r1) ECDSA in 2017–2018 nach der ROCA-Sicherheitslücke, die eine vollständige Aufgabe von RSA erzwang (der Chip konnte keine sicheren RSA-Schlüssel erzeugen und hatte keinen Weg zu größeren Schlüssellängen). Der private Schlüssel ist hardwaregebunden und kann nicht von der Karte gelesen werden. Kein bekannter Governikus-artiger OpenPGP-Signierdienst gefunden. |
| Belgien | Chipbasierte eID. Ältere Karten verwendeten RSA 1024-Bit; neuere Karten (Applet 1.8 aufwärts) verwenden NIST P-384 ECDSA. Aktive Open-Source-Middleware-Ökosystem (eid-mw, OpenSC). Kein bekannter Governikus-artiger OpenPGP-Signierdienst gefunden. |
| Norwegen | Der nationale ID-Kartenchip (seit 2020 ausgegeben) ist ICAO 9303-konform und implementiert nur einen Reisedokument-Chip; er hat keine eID-Signierfunktion. Signierende eID ist getrennt: akkreditierte private Anbieter (Buypass, Commfides) unter SEID, historisch RSA 2048-Bit, Übergang zu RSA 3072-Bit mit ECC eingeführt in SEID 2.0. Kein bekannter Governikus-artiger OpenPGP-Signierdienst. Der Reisechip und die signierende eID sind unterschiedlich – relevant, falls jemand versucht, nur den Kartenchip direkt zu verwenden. |
| Österreich | Teilweise untersucht. eID verwendet ECC (bestätigt); spezifische Kurve nicht in verfügbaren Quellen bestätigt. Multi-Token-Bürgerkarte-Modell statt einer einzigen Karte; weitgehend zu einer mobilen App migriert. Weitere Untersuchung zu Kurvendetails und einem etwaigen OpenPGP-Signierdienst erforderlich. |
| USA | PIV-Karte (Personal Identity Verification, FIPS 201 / NIST SP 800-78): nur an Bundesangestellte und Auftragnehmer ausgegeben – keine universelle Zivilkarte. Algorithmen: NIST P-256 obligatorisch für Authentifizierungsschlüssel; P-256 oder P-384 für Signieren/Schlüsselverwaltung; RSA 2048/3072 ebenfalls erlaubt; nur NIST-Kurven, kein Brainpool. Vertrauensanker ist die Federal Common Policy CA (FCPCAG2), nicht in standardmäßigen kommerziellen Vertrauensspeichern enthalten. Kein Governikus-artiger OpenPGP-Signierdienst gefunden; FPKI ist X.509-Infrastruktur getrennt von OpenPGP. Dass PIV nur für Bundesbedienstete gilt, bedeutet, dass es kein ziviler Vertrauensanker wie die deutsche eID ist. |
| Kanada | Keine nationale chipbasierte Identitätskarte mit On-Chip-Signierschlüsseln. Digitale Identität ist fragmentiert über Provinzprogramme (z. B. BC Services Card), mobile Apps (z. B. eID-Me) und einen sich entwickelnden föderalen Rahmen für digitale Berechtigungsnachweise. Keine einzelne Karte vergleichbar mit dem deutschen, estnischen oder belgischen Modell. Keine gleichwertige Karteninfrastruktur gefunden – in diesem Sinne kein brauchbarer Vertrauensanker. |
| Andere Länder | Nicht untersucht |
| Ziel | Wo anfangen |
|---|
| Projektübersicht, Neuigkeiten, Gemeinschaft | sequoia-pgp.org |
| Beitragen (Issues, Fixes, Features, Dokumentation); Kontakt vor großen Arbeiten | Contributing, Kontakt |
Entwicklerdokumentation — API-Oberfläche zur Erweiterung der Implementierung (sequoia-openpgp und verwandte Crates) | Docs — z. B. sequoia-openpgp auf docs.rs |
| Quellcode und Tracker | gitlab.com/sequoia-pgp (Kernbibliothek und Tools); github.com/sequoia-pgp (Mirrors / ausgewählte Repos); Projekte |
| Neue Algorithmen im OpenPGP-Standard | Gehen immer noch über die IETF OpenPGP Working Group. Sequoia und andere Implementierungen setzen Entwürfe und RFCs um; schlagen Sie Protokolländerungen dort vor und koordinieren Sie sich mit Implementierern (einschließlich Sequoia), damit das Verhalten der Spezifikation entspricht. |
Keyed BLAKE3 zwischen Kaskadenschichten (CESS) — Zusätzlich zum eigenen AEAD-Tag jeder Schicht und zur äußeren Mode A ChaCha20-Poly1305-Hülle definiert CESS eine keyed BLAKE3-artige Integrität zwischen inneren Kaskadenstufen. Für registry-zugeordnete Profile (suite_id über eingebaute Namen) hängt cipher-profile ein 32-Byte HMAC-BLAKE3 über die AEAD-Ausgabe jeder inneren Schicht an, bevor die nächste Schicht verschlüsselt; Schlüssel werden mit HKDF-BLAKE3 unter Verwendung von cess::cess_blake3_integrity_gap_info (inner_info.rs) abgeleitet. Einzelschichtige eingebaute Profile überspringen zusätzliche Tags; benutzerdefinierte Profile (keine suite_id) behalten die Legacy-Kaskade ohne Zwischenschicht-MACs bei. Siehe docs/CIPHER_PROFILES.md und docs/CESS_CONFORMANCE.md. Kombinationsanzahlen unter cipher-profile-Chiffre-Regeln (fünf AEAD-Primitive, keine wiederholte Chiffre in einem Profil, Reihenfolge wichtig); die BLAKE3-Spalte ist die Design-Raum-Anzahl von CESS (unabhängig ein/aus pro Lücke), kein Umschalter pro Nachricht auf dem Host:
Die 205-Zahl zählt nur Chiffre-Stapel (Permutationen von 1–4 verschiedenen Auswahlen aus AES-256-GCM, ChaCha20-Poly1305, Twofish-256, Serpent-256, Camellia-256). Die 1245-Zahl sind dieselben Stapel multipliziert mit jedem unabhängigen Ein/Aus-Muster für optionales Zwischenschicht-BLAKE3 (2^(k−1) Muster für k Schichten). Diese Firmware wendet Zwischenschicht-MACs für alle Lücken an, wenn ein eingebautes suite_id-Profil ≥ 2 Schichten hat (kein Umschalter pro Lücke). Eingebaute Profilnamen verwenden eine kleine Teilmenge der 205.
Optionaler microSD-Täuschungsdatenträger — wenn ein PSRAM-Chip verbaut ist, kann nach dem Entsperren ein zusätzlicher Bulk-Täuschungs-LUN erscheinen. Wenn keine microSD verbaut ist, ist das Gerät dennoch ein Hardware-Sicherheitstoken (Tresor, PIN-Richtlinie, OpenPGP/CCID und andere Token-Funktionen bleiben unverändert); nur dieser optionale Bulk-Datenträger fehlt. Für uninformierte Hosts präsentiert das Gerät weiterhin die übliche On-Chip-Massenspeicher-Täuschungspersona, wo konfiguriert. microSD-Inhalt ist, wenn vorhanden, absichtlich unverschlüsselt und unauffällig. Echtes Schlüsselmaterial lebt im On-Chip-RRAM hinter dem Tresor und der PIN-Richtlinie.
Vollständig offener Stack — CERN-OHL-W-2.0 RTL, offene Schaltpläne, reproduzierbarer Bootloader, Rust/Xous-Betriebssystem, IRIS-prüfbarer Silizium.
| Algorithmus | Standard | Anmerkungen |
|---|
| BrainpoolP256r1 ECDH + ECDSA | RFC 5639, BSI TR-03111 | BSI-standardisiert, keine Beteiligung der NSA |
| BrainpoolP384r1 ECDH + ECDSA | RFC 5639, BSI TR-03111 | ~192-Bit-Sicherheit |
| X25519 ECDH | RFC 7748 | |
| Ed25519 sign / verify | RFC 8032 | |
| RSA-2048 / 3072 / 4096 OAEP, PSS | RFC 8017 | Mindestens 2048 Bit erzwungen |
| P-256, P-384 | NIST | Über p256 / p384 Workspace-Abhängigkeiten |
| Algorithmus | Standard | Anmerkungen |
|---|
| AES-256-GCM | FIPS 197, NIST SP 800-38D | Hardware-AES auf Baochip-1x |
| ChaCha20-Poly1305 | RFC 8439 | Keine Beteiligung der NSA |
| Twofish-256 | Schneier et al. 1998 | AES-Finalist, keine Beteiligung der NSA |
| Serpent-256 | Anderson / Biham / Knudsen 1998 | AES-Finalist, 32 Runden, konservativer Spielraum |
| Algorithmus | 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 |
| SHA-3 Familie | FIPS 202 |
| BLAKE2b / BLAKE2s | RFC 7693 |
| BLAKE3 | BLAKE3-Spezifikation |
| Merkmal | Anmerkungen |
|---|
| Shamir K-von-N Geheimnisverteilung | vsss-rs — Aufteilung und Wiederherstellung auf dem Gerät |
| Authentifiziertes flüchtiges ECDH | Vorwärtssicheres Sitzungsprotokoll — ephemeral-session-Crate |
| Chiffre-Profil-System | Symmetrische Kaskade: bis zu vier verschiedene AEADs gestapelt (z.B. drei unabhängige Schichten); schichtspezifische Schlüssel — cipher-profile — docs/CIPHER_PROFILES.md |
| Eigenschaft | Implementierung |
|---|
| Vorwärtssicherheit | Flüchtiges ECDH: Langzeitschlüssel signiert nur, stimmt nie zu |
| PIN-Zähler vor Vergleich | Zähler vor subtle::ConstantTimeEq in RRAM gespült — keine Ausnahmen |
| Hardware-Nullung (Zeroisation) | TRNG-basiertes mehrfaches Überschreiben; boot0 nullt vor USB-Enumeration |
| Kein Geheimnis auf dem USB-Bus | Uninformierter Host sieht nur Standard-Massenspeicher; kein Fingerabdruck möglich |
| Monotone Manipulationsnachweise | Hardware-Einwegzähler in immer eingeschalteter Domäne |
| Dreifaktor-Authentifizierung | Besitz: USB-Token; Wissen: PIN auf dem Gerät (pin-policy); optional biometrisch nicht implementiert — docs/THREE_FACTOR_AUTH.md |
| RRAM-Zähler und Prüfpfad | Monotones HAL für PIN (und zukünftige zustandsbehaftete PQ-Signaturen); Profil-Prüfdatensätze und In-RAM-OpenPGP-Prüf-Hook — append-only NV-Prüfprotokoll nicht implementiert — docs/AUDIT_LOG.md, docs/RRAM_LAYOUT.md |
| Konstante-Zeit-Operationen | Alle Geheimnisvergleiche über subtle; verifiziert durch dudect-Harnesse |
| test-hal niemals in Produktion | Erzwungen durch check-fw-Xtask |
| Crate | Rolle |
|---|
galdr-core | HAL-Traits (MonotonicCounter, HardwareTrng, ZeroiseController, VaultStorage), gemeinsame Fehler, test-hal-Fakes |
vault | RRAM-Vault-Verträge, HKDF-KeyPurpose-Labels, Schlüsselmaterialtypen (zeroize, kein Clone/Copy) |
pin-policy | PIN-Zustandsmaschine; Zählererhöhung vor subtle::ConstantTimeEq; Schwellenwert-Nullstellung |
usb-personality | Massenspeicher- vs. authentifizierte-Entsperr-Personas (einschließlich Tarn-Massenspeicher-Rolle); Challenge/Response; OpenPGP/CCID-Kartenanwendung; USB-Trennung bei Sperre |
ephemeral-session | Authentifiziertes flüchtiges ECDH-Sitzungsprotokoll; Vorwärtssicherheit |
cipher-profile | Benutzerkonfigurierbare Chiffre-Kaskaden-Profile; integrierte und benutzerdefinierte |
cess | HKDF-BLAKE3 K_outer, ChaCha äußeres AEAD, suite_id || inner_blob; siehe CESS_CONFORMANCE.md |
biometric-api | Biometrische Vor-Gate-Drahttypen (CBOR, SignedMatchResult), Sitzungstoken-Helfer |
biometric-vault | Template-Versiegelung und Vault-seitige Integrationsstücke |
biometric-fingervein / biometric-sweet | Steckbare biometrische Backend-Skizzen |
security-tests | Dudect-Zeitverhaltens-Testumgebungen für kryptografische Pfade |
host-tools | Host-Manifest-Hashing, Update-Verifikation, psram-unlock, galdralag-provision (Xous Two-Line-CDC-PIN-Bereitstellung) |
xtask | Build, Check, Test, Fuzz, build-and-register (Xous galdralag-service), Zeitverhaltenstest |
galdra-core-host | SQLite-Schema, Kontakte/Gruppen/Prüfung/Synchronisation, HKP/WKD/LDAP-Abruf, Geräte- und OpenPGP-Host-Helfer |
galdra | CLI über galdra-core-host |
galdrad | Lokaler REST-Daemon |
galdra-gtk | GTK4-Desktop-Oberfläche |
| Kaskadenlänge | Geordnete unterschiedliche Chiffre-Stapel | × optionales BLAKE3 ein/aus an jeder der Länge−1 Lücken zwischen den Schichten |
|---|
| 1 Schicht | 5 | 5 × 2^0 = 5 |
| 2 Schichten | 20 | 20 × 2^1 = 40 |
| 3 Schichten | 60 | 60 × 2^2 = 240 |
| 4 Schichten | 120 | 120 × 2^3 = 960 |
| Gesamt | 205 | 1245 |