Verifizierungsprozess

Die Sicherstellung der Authentizität eines physischen Objekts ist die Hauptfunktion von Tokentagged. Unsere Architektur unterstützt zwei Ebenen der Verifizierung:

1. Lokale Verifizierung (Off-chain): Sofortige kryptografische Prüfung der Hardware-Echtheit und Herkunft über die Web App.
2. On-chain Verifizierung: Eine Blockchain-Transaktion, die die Anwesenheit des physischen Tags zu einem bestimmten Zeitpunkt und Block kryptografisch beweist und ein dauerhaftes Event emittiert.

1. Lokale Verifizierung (Trust Chain Check)

Wenn ein Nutzer ein Tokentag oder eine Swap Card scannt, führt die Web App eine sofortige Validierung der „Trust Chain“ durch, die im Abschnitt Schlüsselerzeugung beschrieben ist.

Dieser Prozess beinhaltet die Überprüfung von drei verschiedenen Signaturen, die vom Chip bereitgestellt werden:

1. Attestation Signature: Bestätigt, dass der Master Key vom Hersteller (Issuer) autorisiert wurde.
2. Card Attestation Signature: Bestätigt, dass der Card/Wallet Key von diesem gültigen Master Key abgeleitet wurde.
3. Challenge Signature: Bestätigt, dass der physisch anwesende Chip den privaten Card/Wallet Key hält.

Wenn alle drei Signaturen gültig sind, bestätigt die Web App: „Dies ist ein echtes Tokentag und es entspricht dem angezeigten digitalen Asset.“

2. On-chain Verifizierung (Proof of Presence)

Für höhere Sicherheitsanforderungen, Historien-Tracking oder DApp-Integration bietet Tokentagged eine On-chain-Verifizierungsmethode an. Dies ermöglicht einem Nutzer, einen Beweis an die Ethereum-Blockchain zu senden, dass er das physische Tag erfolgreich gescannt hat.

Der Mechanismus

Um Replay-Attacken zu verhindern (z. B. das Kopieren einer Signatur zur späteren Nutzung oder auf einer anderen Chain), muss die vom Tokentag für die On-chain-Verifizierung generierte Signatur spezifische dynamische Kontextdaten enthalten.

Die Smart-Contract-Funktion verifyTokentag führt die Prüfung mittels ecrecover durch.

Datenschema für die Signatur

Der Chip muss einen Hash signieren, der aus den folgenden Datenpunkten konstruiert wird:

Datenpunkt	Typ	Beschreibung
Token ID	uint256	Die vollständige ID des Tokens (die die Tag-Adresse enthält).
Operator	address	Die Adresse des Nutzers, der die Transaktion sendet (msg.sender).
Collection	address	Die Adresse des NFT Smart Contracts (Collection), in dem das Item gemintet ist.
Blockhash	bytes32	Der Hash eines kürzlichen Blocks (zur zeitlichen Begrenzung).
Chain ID	uint256	Die ID der Blockchain (z. B. 1 für Mainnet), um Cross-Chain-Replays zu verhindern.

Die Hashing-Logik (Solidity):

bytes32 messageHash = keccak256(
    abi.encodePacked(id, operator, address(this), blockhash, block.chainid)
);
bytes32 ethSignedMessageHash = keccak256(
    abi.encodePacked("\x19Ethereum Signed Message:\n32", messageHash)
);

Zeitlich begrenzte Gültigkeit

Um sicherzustellen, dass der Beweis aktuell ist, erzwingt der Smart Contract ein Zeitlimit basierend auf dem blockhash.

• Die Signatur muss eine Blocknummer referenzieren, die nicht in der Zukunft liegt.
• Der Block muss innerhalb der letzten 80 Blöcke liegen (ca. 16 Minuten auf Ethereum).

Ablaufzeit

Wenn die Transaktion zu lange im Pending-Status verbleibt (z. B. wegen zu geringer Gas-Gebühren), läuft die Signatur ab, da der referenzierte blockhash zu alt wird oder für die EVM nicht mehr erreichbar ist (blockhash funktioniert nur für die letzten 256 Blöcke).

Das Event: TokentagVerified

Wenn die Signatur gültig ist und zur im Token ID eingebetteten Tag-ID passt, emittiert der Contract ein Event. Externe Systeme (Indexer, die Web App) hören auf dieses Event, um den Status des Assets zu aktualisieren (z. B. „Physisch verifiziert am [Datum]“).

event TokentagVerified(
    uint256 indexed id, 
    address indexed operator, 
    uint256 timestamp, 
    bytes data
);

Ablaufdiagramm

Das folgende Diagramm illustriert den Datenfluss für die On-chain-Verifizierung.