Trust Chain & Schlüsselerzeugung

Ein zentrales Sicherheitsmerkmal der Tokentagged-Architektur ist, dass wir (der Hersteller) den privaten Schlüssel des Nutzers nicht kennen. Der Verifizierungsablauf ist vollständig dezentral aufgebaut und kann ohne Tokentagged-Server überprüft werden.

Um dies zu erreichen und gleichzeitig die Echtheit der Hardware sicherzustellen (Anti-Counterfeiting), setzen wir einen zweistufigen Schlüsselerzeugungsprozess ein, der eine „Trust Chain“ und nutzerseitige Entropie (Chain Code) nutzt.

1. Manufacturing Process (Root of Trust)

Während der sicheren Produktionsphase wird der Chip initialisiert. In diesem Stadium hat die Karte noch keine für den Nutzer verwendbare Wallet-Adresse.

Master-Key-Erzeugung

• Der Chip erzeugt intern ein einzigartiges Master-Key-Paar (Priv_Master / Pub_Master).
• Priv_Master verlässt den Chip niemals.

Root Attestation (Factory Signing)

Um zu beweisen, dass dieser Chip von Tokentagged stammt, signieren wir die Chip-Identität.

1. Der Hersteller verwendet den offline gespeicherten Tokentagged Root Key (Priv_Issuer).
2. Es wird ein Datenblock aufgebaut: 12 Bytes Padding (0x00) + Last 20 Bytes of Keccak256(Pub_Master).
3. Der Hersteller signiert diesen Block und erzeugt die Root Attestation Signature.
4. Diese Signatur wird dauerhaft im Flash-Speicher der Karte abgelegt.

Zustand nach der Produktion

Die Karte enthält eine eindeutige Identität (Priv_Master) und ein Echtheitszertifikat (Root Attestation). Ein abgeleiteter Wallet-Key ist zu diesem Zeitpunkt noch nicht vorhanden.

2. Kartenaktivierung (User Key Derivation)

Die Aktivierung stellt sicher, dass der finale Wallet-Key mathematisch aus einem Geheimnis abgeleitet wird, das nur der Nutzer kennt (Chain Code).

Chain Code

Der Nutzer gibt in der Web App eine Passphrase (oder zufällige Entropie) ein. Die App berechnet daraus einen 32-Byte-Chain Code (Keccak256-Hash der Passphrase).

On-Chip Key Derivation

Der Chain Code wird per NFC an die Karte gesendet. Die Karte führt anschließend eine deterministische Schlüsselableitung durch (BIP-32-Standard):

Priv_Card = Derive(Priv_Master, ChainCode, Index_0)

1. Card Private Key (Priv_Card): Abgeleitet aus dem on-chip erzeugten Master Key und dem Chain Code des Nutzers. Da der Chain Code vom Nutzer stammt und uns unbekannt ist, ist mathematisch bewiesen, dass wir den finalen Key nicht ableiten können – selbst unter der theoretischen Annahme, wir würden den Master Key kennen.
2. Card Public Key (Pub_Card): Wird aus Priv_Card berechnet.
3. Card Address: Die aus Pub_Card abgeleitete Ethereum-Adresse.

Usability vs. Verifizierbarkeit

Aus Usability-Gründen nutzt die Web App bei der Aktivierung eine zufällige Passphrase. Wenn du den kryptografischen Beweis prüfen möchtest, öffne vor der Aktivierung die Browser-Konsole. Dort findest du Anweisungen, wie du eine eigene Passphrase eingeben kannst. Anschließend erhältst du hier alle erzeugten Public Keys und kannst den Beweis prüfen. Eine direkte Passphrase-Eingabe in der Web App wird zukünftig ergänzt.

Card Attestation (Internal Signing)

Um zu beweisen, dass der erzeugte Priv_Card zu dieser spezifisch authentischen Hardware gehört, erzeugt der Chip eine zweite Verbindung in der Trust Chain:

1. Der Chip verwendet Priv_Master, um den neuen Pub_Card zu signieren (konkret: 12 Bytes Padding + Address).
2. Dadurch entsteht die Card Attestation Signature.

Alle abgeleiteten Keys und Signaturen werden im sicheren Speicher abgelegt. Die Karte ist nun aktiviert.

Verifizierungsablauf

Wenn ein Nutzer die Karte antippt, um eine Transaktion zu signieren, validiert der Client (Web App) die komplette Chain, um sicherzustellen:

1. Die Signatur ist gültig.
2. Der Key gehört zu dieser Hardware.
3. Die Hardware ist authentisch.

Dezentrale Verifizierung

Der Pub_Issuer-Key kann ebenfalls vollständig dezentral geprüft werden, da alle Pub_Issuer-Keys in einem SignerRegistry-Smart-Contract verifizierbar sind. Der gesamte Workflow kann theoretisch ohne Tokentagged-Server durchgeführt werden. Siehe Smart Contract Docs für Details.

Zusammenfassung der Keys

Key Name	Ort	Kenntnis	Zweck
Issuer Key	Offline (HSM)	Nur Hersteller	Signiert die Root Attestation zur Echtheitsbestätigung.
Master Key	Secure Element	Nur Chip (intern)	Unveränderliche Hardware-Identität. Signiert den Card Key.
Chain Code	Eingabe bei Aktivierung	Nur Nutzer	Fügt Nutzer-Entropie hinzu, damit der Hersteller den finalen Wallet-Key nicht kennt.
Card Key	Secure Element	Nur Chip (intern)	Der eigentliche Wallet-Key für Ethereum-Transaktionen.