Sicherheitsrahmen

Sicherheitslage in einem Absatz

Der Referenz-Token hat einen zentralen Durchgangspunkt (_update), eine feste Auswertungsreihenfolge, eine Reentrancy-Sperre um die gesamte Hook-Sequenz, rollenbasierte Befugnisse, die nie aus Salden abgeleitet werden, ERC-7201-Speicher und eine kleine Angriffsfläche: acht externe zustandsändernde Funktionen jenseits von ERC-1155. Die mächtigsten Fähigkeiten – Einfrieren, erzwungener Transfer, Hook-Administration, Upgrades – sind getrennte Rollen, die für Multisigs und Timelocks vorgesehen sind, und jede Nutzung ist ein Ereignis.

Invarianten

Bedrohungsmodell

Akteure und Fähigkeiten

Szenarien

Bösartiger oder fehlerhafter Hook (Denial of Service). Ein Hook, der stets ablehnt, blockiert alle Transfers des Tokens; ein Hook, der in check revertiert, bewirkt dasselbe. Gegenmaßnahme: HOOK_ADMIN_ROLE kann jeden Hook jederzeit entfernen (Reihenfolge bleibt erhalten); PAUSER_ROLE kann während der Untersuchung anhalten; erzwungene Transfers laufen weiterhin, sodass die Durchsetzung nicht verloren geht. Die Registrierung prüft die ERC-165-Unterstützung und Flags ungleich null und weist EOAs zurück. Empfehlung: Hooks vor der Registrierung auditieren; die Anzahl klein halten; den Administrator hinter einen Timelock legen, damit Hook-Änderungen sichtbar sind, bevor sie wirksam werden.

Reentrancy durch einen Hook. onExecuted eines Hooks ruft safeTransferFrom zurück auf. Gegenmaßnahme: die Sperre; der Aufruf revertiert mit ARexReentrantCall. Zu beachten ist, dass der Empfänger-Callback von ERC-1155 (onERC1155Received) wie bei jedem ERC-1155-Token nach der Freigabe der Sperre läuft; der Zustand des Tokens ist dann bereits endgültig.

Kompromittierter Durchsetzungsschlüssel. Wer ENFORCER_ROLE hält, kann beliebige Token bewegen. Gegenmaßnahme: Multisig mit einem dokumentierten Verfahren (Gerichtsbeschluss, Pfandvertrag, Sanktionsmitteilung); jede Aktion emittiert ForcedTransfer/Frozen; Hooks können eine Anordnungsreferenz in den Transferdaten verlangen (OP_FORCED_TRANSFER ist nicht von den Hooks ausgenommen). Für nicht dringliche Durchsetzungsmaßnahmen ist ein Timelock in Erwägung zu ziehen.

Kompromittierter Upgrader. Totale Kompromittierung. Gegenmaßnahme: Multisig plus Timelock; OpenZeppelin-Upgrade-Validierungen in der CI; ERC-7201-Speicher, um Layout-Unfälle zu vermeiden.

Missbrauch des Status. STATUS_ROLE kann eine Charge stilllegen, die von anderen gehalten wird. Das ist beabsichtigt – ein Lager, ein Prüfer oder eine Aufsichtsbehörde erklärt eine Charge für untauglich – und muss den Inhabern offengelegt werden. Gegenmaßnahme: einer rechenschaftspflichtigen Institution zuweisen; jede Änderung ist ein Ereignis mit einem Grund.

Betrug durch den Aussteller. ISSUER_ROLE kann eine Charge erstellen, die physisch nicht existiert. Der Token kann dies nicht verhindern; er macht es zuordenbar (issuer, originRef, metadataHash) und ermöglicht es, über AttestationHook Attestierungen unabhängiger Parteien (Lager, Prüfer, Register) vor dem Transfer vorauszusetzen.

Austausch der Metadaten. setBatchMetadata ändert Hash und URI. Gegenmaßnahme: rollengesteuert; die Ereignisse BatchMetadataUpdated und URI bewahren die Historie; frühere Dokumente bleiben anhand früherer Hashes überprüfbar.

Front-Running von transferCheck. Eine Vorabprüfung kann veralten, bevor die Transaktion ausgeführt wird (der Zustand eines Hooks ändert sich). Die Transaktion wertet erneut aus; im schlimmsten Fall kommt es zu einem Revert mit einem präzisen Code.

Gas-Griefing durch Hooks. Jeder Hook fügt pro betroffener ID und Phase einen externen Aufruf hinzu. Ein Hook mit unbegrenzten Schleifen macht Transfers unbezahlbar. Gegenmaßnahme: Regeln für die Hook-Entwicklung (begrenztes check), Prüfung vor der Registrierung.

Vertrauen in upgradefähige Hooks. Ein hinter einem Proxy ausgerollter Hook kann die Transferrichtlinie ändern, ohne dass sich am Token etwas ändert. Gegenmaßnahme: Administratorschlüssel von Hooks mit derselben Sorgfalt behandeln wie HOOK_ADMIN_ROLE; im Produktivbetrieb unveränderliche Hooks bevorzugen.

Zugriffskontrollmodell

OpenZeppelin AccessControl mit acht Rollen am Token und einer am Attestierungsregister; DEFAULT_ADMIN_ROLE verwaltet sie alle. Empfohlene Aufteilung im Produktivbetrieb:

initialize überträgt aus Bequemlichkeit alles an einen Administrator; die Deployment-Checkliste verlangt vor dem Produktivbetrieb eine Neuverteilung.

Semantik von Durchsetzung und Pause

• Die Pause blockiert Mints, Transfers, Burns und Transformationen; sie blockiert erzwungene Transfers nicht, sodass eine rechtmäßige Anordnung während eines Störfalls ausgeführt werden kann.
• Erzwungene Transfers überspringen canSend/canReceive und die Prüfung des eingefrorenen Saldos, senken den eingefrorenen Betrag auf den verbleibenden Rest und führen die Hooks weiterhin mit OP_FORCED_TRANSFER aus. Referenz-Hooks liefern für diese Operation OK; ein Hook, der die Durchsetzung regelt, kann Anordnungsreferenzen in data verlangen.
• Das Einfrieren darf den Saldo übersteigen (ERC-7943), sodass ein Pfandrecht auch künftige Zugänge erfassen kann.

Upgrade-Sicherheit

• UUPS; _authorizeUpgrade durch UPGRADER_ROLE abgesichert.
• ERC-7201-Speicher-Struct mit Namensraum; nur Anhängen erlaubt.
• Die Validierungen des OpenZeppelin-Upgrades-Plugins laufen in den Tests und sollten vor jeder Upgrade-Transaktion in der CI laufen.
• Die dateibezogene Einstellung optimizer.runs = 1 hält die Implementierung unter EIP-170; eine Änderung, die sie darüber hebt, schlägt beim Kompilieren mit einer Warnung und beim Deployment mit einem Revert fehl.

Sicherheit von Abhängigkeiten und Build

• OpenZeppelin Contracts und Contracts-Upgradeable auf 5.3.0 fixiert; Lockfile eingecheckt; die CI verwendet npm ci.
• Solidity 0.8.22, viaIR, EVM paris (keine Abhängigkeit von Transient Storage, auf Chains einsetzbar, die Cancun nicht übernommen haben).
• Keine externen Bibliotheken gelinkt; kein delegatecall außerhalb des UUPS-Proxys.

Audit-Lage

• 46 Tests für die Referenzimplementierung, die Hooks und die Erweiterungen decken jede der oben genannten Invarianten ab, einschließlich eines mit festem Seed randomisierten Invariantenlaufs.
• Gas und Größe werden durch Skripte im Repository gemessen.
• Ein Audit von ARexToken, ARexAttestations und den Referenz-Hooks durch Dritte ist eine erklärte Voraussetzung für einen Anker im Produktivbetrieb und für die Einreichung des ERC (siehe Zukünftige Entwicklungen).
• Die formale Verifikation der Pipeline-Invarianten steht auf der Roadmap; die Invarianten sind klein genug, um als Eigenschaften formuliert zu werden.

Restrisiken, die der Standard nicht beseitigt

• Die physische Existenz und die Qualität einer Charge werden attestiert, nicht bewiesen; der Token macht Aussagen zuordenbar, nicht wahr.
• Die Verfügbarkeit von Off-Chain-Metadaten hängt vom gewählten Speicher ab; der Hash garantiert Integrität, nicht Verfügbarkeit.
• Die Governance von Hooks und Modulen ist nur so gut wie die Schlüssel, die sie kontrollieren.