Core Logic: Tokentagged.sol

Tokentagged.sol ist das Herzstück des Systems. Es implementiert die Logik zur Verifizierung der hochsicheren NXP P71D321 (EAL 6+) Chips und definiert die Struktur der Token.

Abstrakter Contract

Dieser Contract wird nicht direkt deployed, sondern von TokentaggedAssets und TokentaggedCollection geerbt. Er stellt die Sicherheitsfunktionen für alle Collections bereit.

Token ID Bit-Splitting

Um Speicherplatz (Gas) zu sparen und maximale Flexibilität zu bieten, nutzen wir eine Bit-Splitting-Methode. Eine einzelne uint256 Token ID enthält mehrere Informationen gleichzeitig.

Bit Range	Länge	Name	Beschreibung
256 - 177	80 Bit	Semi Fungible ID	ID für Editionen oder Seriennummern.
176 - 161	16 Bit	Flags	Definiert den Token-Typ (NFT, FT, SFT).
160 - 1	160 Bit	Tokentag ID	Die eindeutige Adresse (abgeleitet vom Public Key) des Chips.

Typ-Definitionen (Flags)

Bitmask	Typ	Beschreibung
0	NFT	Unikat (1:1 mit physischem Objekt). Amount ist immer 1.
1 << 161	SFT	Semi-Fungible Token (z.B. limitierte Editionen).
1 << 162	VFT	Versatile Fungible Token.
1 << 163	FT	Fungible Token (z.B. Loyalty Points pro Tag).

Sicherheitskonzept: The Verification Chain

Die Sicherheit von Tokentagged basiert auf einem mehrstufigen Hardware-Sicherheitsmodell ("Trust Chain"). Ein entscheidendes Merkmal ist, dass der Card-Private-Key dem Hersteller nicht bekannt ist, da er erst durch die User-Aktivierung abgeleitet wird.

Um dennoch die Echtheit der Hardware zu garantieren, prüft der Smart Contract (TokentaggedSignerRegistry) eine Kette von Zertifikaten.

Key Hierarchie

Das folgende Diagramm zeigt die Abhängigkeiten. Beachte: Der Master Key entsteht im Chip (On-Chip Generated) und wird nicht vom Hersteller erzeugt, sondern nur signiert.

Der Verifikations-Prozess (On-Chain)

Bei jeder Transaktion (mintTokentag oder verifyTokentag) werden drei kryptografische Beweise validiert. Nur wenn alle drei Prüfungen erfolgreich sind, gilt der Chip als echt und sicher.

1. Challenge Signature (User Action)

Beweist, dass der physisch anwesende Chip den Card-Private-Key besitzt und die Transaktion autorisiert hat.

• Prüfung: ecrecover(TxHash, Signature) == Card-Address
• Ort: Tokentagged.sol

2. Card Attestation (Integrity Check)

Beweist, dass der verwendete Card-Key legitim vom Master-Key des Chips abgeleitet wurde. Dies verhindert, dass jemand einen beliebigen Key generiert und behauptet, er gehöre zum Chip.

• Prüfung: ecrecover(Card-Address, Card-Attestation) == Master-Address
• Ort: TokentaggedSignerRegistry.sol
• Zusatz-Check: Ist die Master-Address auf der Blacklist? (Falls ein Chip physisch kompromittiert wurde).

3. Root Attestation (Authenticity Check)

Beweist, dass der Master-Key von Tokentagged in einen originalen NXP-Chip programmiert wurde.

• Prüfung: ecrecover(Master-Address, Root-Attestation) == Trusted-Issuer-Address
• Ort: TokentaggedSignerRegistry.sol

Code-Logik (Vereinfacht)

Der folgende Pseudocode zeigt die Logik innerhalb der verifyTokentagAuthenticity Funktion in der Registry:

function verifyTokentagAuthenticity(address cardId, bytes cardAtstSig, bytes rootAtstSig) external view returns (bool) {
    
    // Schritt 1: Master Address aus der Card Attestation wiederherstellen
    // Beweist: Dieser Card-Key gehört zu diesem Master-Key
    address masterAddr = ecrecover(cardId, cardAtstSig);
    
    // Schritt 2: Sicherheits-Check
    // Wurde dieser Master-Key als kompromittiert gemeldet?
    require(!blacklistedMasters[masterAddr], "Master is blacklisted");

    // Schritt 3: Issuer Address aus der Root Attestation wiederherstellen
    // Beweist: Dieser Master-Key ist ein echter Tokentagged Chip
    address issuerAddr = ecrecover(masterAddr, rootAtstSig);
    
    // Schritt 4: Whitelist Check
    // Ist der Unterzeichner ein autorisierter Tokentagged-Issuer?
    return trustedSigners[issuerAddr];
}