Im Oktober begann der Begriff "TEE (Trusted Execution Environment)" häufig in X-Feeds aufzutauchen. Das hat mich überrascht, da TEE traditionell ein Nischenthema ist, das hauptsächlich in der Systemsicherheitsakademie diskutiert wird. Als jemand, der in einem Systemsicherheitslabor geforscht hat, habe ich mich über diese Entwicklung gefreut. Allerdings war ich neugierig, warum TEE plötzlich Aufmerksamkeit im Web3-Bereich erhielt. Mir ist auch aufgefallen, dass es an zugänglichem Inhalt mangelt, der TEE-Konzepte für die breite Öffentlichkeit erklärt, was mich dazu motiviert hat, diesen Artikel zu schreiben.

TEE ist ein komplexes Konzept, das ohne Hintergrundwissen in Informatik schwer vollständig zu verstehen ist. Daher beginnt dieser Artikel mit grundlegenden TEE-Konzepten, erklärt, warum Web3 daran interessiert ist, TEE zu nutzen, und diskutiert dann aktuelle Web3-Projekte, die TEE implementieren, sowie deren Einschränkungen.

Zusammenfassend behandelt dieser Artikel die folgenden Themen:

• Eine Einführung in TEE-Konzepte und einen kurzen Überblick über moderne TEEs
• Verschiedene TEE-Implementierungsfälle innerhalb des Web3-Ökosystems
• Einschränkungen von TEE und persönliche Perspektiven zu diesen Einschränkungen
• Die Zukunft von TEE im Web3-Ökosystem

1. Was ist TEE?

Ich glaube, die meisten Leser verfügen möglicherweise nicht über das notwendige Hintergrundwissen, um genau zu verstehen, was TEE ist. Da TEE ein ziemlich komplexes Konzept ist, wenn man es tiefgehend erforscht, werde ich versuchen, es so einfach wie möglich zu erklären.

Grundlegende Konzepte

Die meisten Web2-Server verwalten den Datenzugriff über Autorisierungseinstellungen. Da dieser Ansatz jedoch rein softwarebasiert ist, wird er im Wesentlichen unwirksam, wenn höhere Privilegien erlangt werden. Wenn beispielsweise ein Angreifer Kernel-Level-Privilegien im Betriebssystem des Servers erlangt, kann er potenziell auf alle durch Berechtigungen kontrollierten Daten auf dem Server zugreifen, einschließlich Verschlüsselungsschlüssel. In solchen extremen Szenarien gibt es praktisch keine Möglichkeit, den Datendiebstahl allein durch softwarebasierte Methoden zu verhindern. TEE oder Trusted Execution Environment versucht, dieses Problem grundsätzlich durch hardwarebasierte Sicherheit anzugehen. TEEs werden oft als „vertrauliches Computing“ bezeichnet, aber dies ist ein breiteres Konzept, das Berechnungsmechanismen umfasst, die die Benutzerdatenschutz sicherstellen, wie ZK, MPC und FHE.

Quelle: Jujutsu Kaisen

Um eine einfache Analogie zu verwenden, fungiert TEE wie eine verschlüsselte Zone im Speicher. Alle Daten innerhalb des TEE sind verschlüsselt, was den Zugriff auf Rohdaten von außen unmöglich macht. Selbst der OS-Kernel kann sie nicht in ihrer ursprünglichen Form lesen oder ändern. Selbst wenn ein Angreifer Administratorrechte auf dem Server erlangt, kann er die Daten innerhalb des TEE nicht entschlüsseln. Dieser verschlüsselte Bereich wird oft als „Enklave“ bezeichnet.

Das Erstellen einer Enklave und das Verarbeiten von Daten darin erfordert bestimmte Befehlssätze, ähnlich wie bei Opcodes. In diesen Anweisungen werden Verschlüsselungsschlüssel verwendet, die in hardwaregeschützten Bereichen gespeichert sind, um Berechnungen für Daten innerhalb der Enklave durchzuführen. Da es sich bei TEE um ein Sicherheitsmodul auf Hardwareebene handelt, variiert seine Implementierung je nach CPU-Chip-Anbieter. Intel unterstützt beispielsweise SGX, AMD SEV und ARM TrustZone. Aus einer breiteren Perspektive teilen diese Implementierungen das Konzept des "Schutzes des Arbeitsspeichers durch Verschlüsselung auf Hardwareebene".

1.1. Wie TEEs Daten schützen

Lassen Sie uns zunächst untersuchen, wie die häufigsten TEEs - Intel SGX, AMD SEV und ARM TrustZone - arbeiten und dann neuere TEE-Implementierungen einführen.

1.1.1. OG TEEs

Intel SGX

SGX erstellt und greift auf Enklaven auf Prozessebene zu. Das folgende Bild stellt eine klare Darstellung dar, wie ein SGX-fähiges Programm funktioniert.

Quelle: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/enclave/interaction-between-pse-and-application-enclaves

Während der Entwicklung müssen Entwickler zwischen nicht vertrauenswürdigem und vertrauenswürdigem Code unterscheiden. Variablen oder Funktionen, die durch den Enklave geschützt werden müssen, werden als vertrauenswürdiger Code bezeichnet, während andere Operationen als nicht vertrauenswürdiger Code kategorisiert werden. Wenn nicht vertrauenswürdiger Code Daten in vertrauenswürdigen Code eingeben muss oder wenn vertrauenswürdiger Code mit nicht vertrauenswürdigem Code interagieren muss, werden spezielle Syscalls namens ECALL und OCALL verwendet.

Quelle: https://www.intel.com/content/www/us/de/developer/articles/training/intel-software-guard-extensions-tutorial-part-7-refining-the-enclave.html

Wenn Benutzer direkt mit Daten innerhalb der Enklave interagieren müssen – beispielsweise Eingabe bereitstellen oder Ausgabe empfangen – können sie über sichere Kanäle kommunizieren, die mithilfe von Protokollen wie SSL eingerichtet werden.

AMD SEV

Im Gegensatz zu SGX, das Enklaven auf Prozessebene erstellt, erstellt SEV sie auf der Ebene der virtuellen Maschine. Dem virtuellen Maschinen zugewiesener Speicher wird verschlüsselt und mit unabhängigen Schlüsseln verwaltet, um Daten vor dem Betriebssystem des Servers oder anderen virtuellen Maschinen zu schützen. Obwohl virtuelle Maschinen aufgrund ihrer isolierten Abgrenzung im Allgemeinen als sicher gelten, können Sicherheitslücken, die diese Isolierung beeinträchtigen, nicht vollständig ausgeschlossen werden. SEV ist darauf ausgelegt, in solchen Szenarien Sicherheit zu bieten.

SEV generiert Verschlüsselungsschlüssel durch einen Sicherheitsprozessor, der während der Erstellung der VM physisch vom CPU getrennt ist. Diese Schlüssel werden dann zur Verschlüsselung des VM-Speichers verwendet. Die folgende Abbildung veranschaulicht den Unterschied zwischen SGX und SEV.

Quelle: 10.1109/SRDS.2018.00042

SGX erfordert von Entwicklern, den Code explizit in unvertrauenswürdige und vertrauenswürdige Segmente zu unterteilen. Im Gegensatz dazu verschlüsselt SEV den gesamten Speicher des virtuellen Computers und erfordert von den Entwicklern in Bezug auf die Implementierung relativ weniger Aufwand.

ARM TrustZone

Im Gegensatz zu Intel und AMD, die hauptsächlich CPUs für Desktops und Server herstellen, entwirft ARM Chipsätze für leichte Systeme wie Mobilgeräte und eingebettete Geräte. Daher ist ihre Secure Enclave-Implementierung etwas anders als die SGX oder SEV, die in Architekturen höherer Ebene verwendet werden.

TrustZone teilt das System auf Hardwareebene in eine sichere Welt und eine normale Welt auf. Entwickler, die TrustZone verwenden, müssen sicherheitskritische Funktionen in der sicheren Welt implementieren, während allgemeine Funktionen in der normalen Welt ausgeführt werden. Übergänge zwischen diesen beiden Welten erfolgen über spezielle Systemaufrufe, die als Secure Monitor Calls bekannt sind und ähnlich wie SGX sind.

Ein wesentlicher Unterschied besteht darin, dass sich die Enklave von TrustZone über die CPU oder den Arbeitsspeicher hinaus erstreckt. Es umfasst das gesamte System, einschließlich des Systembusses, der Peripherie und der Interrupt-Controller. Apple verwendet in seinen Produkten auch eine TEE namens Secure Enclave, die TrustZone auf hohem Niveau sehr ähnlich ist.

1.1.2. Fortgeschrittene TEEs

Wie wir später besprechen werden, haben viele ursprüngliche TEEs, einschließlich Intel SGX, aufgrund struktureller Probleme Seitenkanal-Anfälligkeiten und Entwicklungsherausforderungen. Um diese Probleme zu lösen, haben die Hersteller verbesserte Versionen veröffentlicht. Mit der steigenden Nachfrage nach sicherem Cloud-Computing bieten Plattformen wie AWS/Azure/GCP nun auch ihre eigenen TEE-Dienste an. In letzter Zeit wurde das TEE-Konzept auch auf GPUs erweitert. Einige Web3-Anwendungsfälle setzen diese fortschrittlichen TEEs bereits ein, daher werde ich sie kurz erklären.

Cloud TEEs: AWS Nitro, Azure Vertrauliches Computing, Google Cloud Vertrauliches Computing

Mit der wachsenden Nachfrage nach Cloud-Computing-Diensten haben Anbieter begonnen, ihre eigenen TEE-Lösungen zu entwickeln. Nitro von AWS ist eine umschlossene Computing-Umgebung, die neben EC2-Instanzen arbeitet. Sie erreicht eine physische Trennung der Computing-Umgebung durch die Verwendung eines dedizierten Nitro-Sicherheitschips zur Beglaubigung und Schlüsselverwaltung. Der Nitro-Hypervisor schützt Enklavenspeicherbereiche durch Funktionen, die vom Chip bereitgestellt werden, und schützt so effektiv vor Angriffen sowohl von Benutzern als auch von Cloud-Anbietern.

Azure unterstützt verschiedene TEE-Spezifikationen, einschließlich Intel SGX, AMD SEV-SNP und seiner eigenen virtualisierungsbasierten Isolation. Diese Flexibilität bei der Auswahl der Hardwareumgebung bietet Benutzern mehr Optionen, kann jedoch die Angriffsfläche erhöhen, wenn der Benutzer mehrere TEEs verwendet.

Google Cloud bietet vertrauliche Computing-Dienste, die Vertrauensausführungsumgebungen (TEE) nutzen und sich auf KI-/ML-Workloads konzentrieren. Im Gegensatz zu AWS Nitro bietet Google Cloud ähnlich wie Azure eine virtualisierungsbasierte Isolierung unter Verwendung der vorhandenen TEE-Infrastruktur. Zu den wichtigsten Unterscheidungsmerkmalen zählen die Unterstützung von CPU-Beschleunigern wie Intel AMX zur Bewältigung intensiver KI-/ML-Aufgaben sowie die auf GPU basierende vertrauliche Datenverarbeitung durch NVIDIA, die später näher erläutert wird.

ARM CCA

ARM CCA, das Ende 2021 veröffentlicht wurde, ist speziell für Cloud-Umgebungen konzipiert, im Gegensatz zu TrustZone, das für einzelne eingebettete oder mobile Umgebungen entwickelt wurde. TrustZone verwaltet statisch vorab festgelegte sichere Speicherbereiche, während CCA die dynamische Erstellung von Realms (sichere Enklaven) ermöglicht. Dadurch sind mehrere isolierte Umgebungen in einem einzigen physischen Setup möglich.

CCA kann als eine ARM-Version von Intel SGX angesehen werden, jedoch mit bemerkenswerten Unterschieden. Während SGX Speicherbeschränkungen hat, bietet CCA eine flexible Speicherzuweisung. Darüber hinaus verwendet CCA einen grundsätzlich anderen Sicherheitsansatz, indem der gesamte physische Speicher verschlüsselt wird, nicht nur die dafür vorgesehenen Enklavenbereiche, wie es SGX tut.

Intel TDX

Intel stellte TDX vor, eine Technologie, die den Speicher auf VM-Ebene verschlüsselt, ähnlich wie AMD's SEV. Diese Version behebt Probleme mit den Einschränkungen von SGX (v1), einschließlich der Begrenzung der Enklavengröße auf 256 MB und der erhöhten Entwicklungskomplexität aufgrund der Erstellung von Enklaven auf Prozessebene. Der wesentliche Unterschied zu SEV besteht darin, dass TDX dem Betriebssystem, insbesondere dem Hypervisor, teilweise vertraut, um die Ressourcenverwaltung für VMs zu gewährleisten. Darüber hinaus gibt es Unterschiede in den Verschlüsselungsmechanismen für jede VM.

AMD SEV-SNP

SEV-SNP verbessert die Sicherheit des bestehenden SEV-Modells. Das ursprüngliche SEV stützte sich auf ein Vertrauensmodell, das Schwachstellen aufwies und es Hypervisoren ermöglichte, die Speicherzuordnung zu ändern. SEV-SNP behebt dieses Problem, indem ein Hardware-Manager hinzugefügt wird, um den Speicherzustand zu verfolgen und solche Änderungen zu verhindern.

Darüber hinaus ermöglicht es Benutzern, eine Remote-Attestation direkt durchzuführen und minimiert damit Vertrauensanker. SEV-SNP hat auch eine Reverse Map-Tabelle eingeführt, um den Speicherseitenzustand und die Eigentümerschaft zu überwachen und so Schutz vor bösartigen Hypervisor-Angriffsmodellen zu bieten.

GPU TEE: NVIDIA Vertrauliches Computing

Die TEE-Entwicklung hat sich traditionell auf CPUs konzentriert, da sie von Hardwareanbietern abhängig ist. Die Notwendigkeit der Verarbeitung komplexer Berechnungen wie des sicheren KI-Trainings und des Schutzes von Trainingsdaten hat jedoch die Notwendigkeit von GPU-TEE hervorgehoben. Als Reaktion darauf hat NVIDIA 2023 vertrauliche Rechenfunktionen auf die H100-GPU eingeführt.

NVIDIA Confidential Computing bietet unabhängig verschlüsselte und verwaltete GPU-Instanzen, die in Kombination mit CPU TEE eine durchgehende Sicherheit gewährleisten. Derzeit wird dies durch die Integration von AMD SEV-SNP oder Intel TDX erreicht, um vertrauliche Computing-Pipelines aufzubauen.

1.2. Wie vertrauen wir TEE?

Bei der Prüfung von Web3-Projekten sieht man oft Behauptungen der Gemeinschaftsverwaltung durch Code-Uploads auf GitHub. Aber wie kann man überprüfen, ob das auf dem Server bereitgestellte Programm tatsächlich dem GitHub-Code entspricht?

Die Blockchain bietet eine Umgebung, in der Smart Contracts aufgrund kontinuierlicher Konsensbildung immer öffentlich und unveränderlich sind. Im Gegensatz dazu ermöglichen typische Web2-Server Administratoren, Programme jederzeit zu aktualisieren. Um die Authentizität zu überprüfen, müssen Benutzer Hash-Werte von Binärdateien vergleichen, die aus Open-Source-Programmen auf Plattformen wie GitHub erstellt wurden, oder die Integrität über Entwicklersignaturen überprüfen.

Das gleiche Prinzip gilt für Programme innerhalb von TEE-Enklaven. Damit Benutzer serverbereitgestellten Programmen vollständig vertrauen können, müssen sie überprüfen (beglaubigen), dass der Code und die Daten innerhalb der Enklave unverändert bleiben. Im Falle von SGX kommuniziert es mit IAS (Intel Attestation Service) unter Verwendung eines in einer speziellen Enklave gespeicherten Schlüssels. IAS überprüft die Integrität der Enklave und ihrer internen Daten und gibt dann die Ergebnisse an Benutzer zurück. Zusammenfassend erfordert TEE die Kommunikation mit vom Hardware-Anbieter bereitgestellten Beglaubigungsservern, um die Integrität der Enklave zu gewährleisten.

2. TEE auf Web3

Warum TEE auf Web3?

TEE mag der breiten Öffentlichkeit unbekannt erscheinen, da sein Wissen in der Regel auf spezialisierte Bereiche beschränkt ist. Das Aufkommen von TEE passt jedoch gut zu den Prinzipien des Web3. Die grundlegende Prämisse bei der Verwendung von TEE lautet: "Vertraue niemandem." Bei ordnungsgemäßer Implementierung kann TEE Benutzerdaten vor dem Programmbereitsteller, dem Besitzer des physischen Servers und sogar vor dem Betriebssystem-Kernel schützen.

Während aktuelle Blockchain-Projekte eine bedeutende strukturelle Dezentralisierung erreicht haben, verlassen sich viele immer noch auf Off-Chain-Serverumgebungen wie Sequenzer, Off-Chain-Relayer und Keeper-Bots. Protokolle, die sensible Benutzerinformationen wie KYC oder biometrische Daten verarbeiten müssen oder solche, die private Transaktionen unterstützen wollen, sehen sich der Herausforderung gegenüber, Vertrauen in Dienstleister zu erfordern. Diese Probleme können wesentlich durch die Datenverarbeitung innerhalb von Enklaven gemildert werden.

Als Ergebnis hat TEE in der zweiten Hälfte dieses Jahres an Popularität gewonnen, im Einklang mit KI-bezogenen Themen wie Datenschutz und vertrauenswürdigen KI-Agenten. Versuche, TEE in das Web3-Ökosystem zu integrieren, gab es jedoch lange vorher. In diesem Artikel werden wir Projekte in verschiedenen Bereichen vorstellen, die TEE im Web3-Ökosystem angewendet haben, jenseits des AI-Sektors.

2.1. Vertraulicher Coprozessor

Marlin

Marlin ist ein überprüfbares Berechnungsprotokoll, das entwickelt wurde, um eine sichere Berechnungsumgebung unter Verwendung von TEE- oder ZK-Technologie anzubieten. Eines ihrer Hauptziele ist die Entwicklung eines dezentralen Webs. Marlin verwaltet zwei Subnetze: Oyster und Kalypso, wobei Oyster als das TEE-basierte Coprozessing-Protokoll fungiert.

1) Oyster CVM

Oyster CVM (Oyster for convenience) fungiert als P2P TEE-Marktplatz. Benutzer kaufen AWS Nitro Enclave-Computing-Umgebungen über den Off-Chain-Marktplatz von Oyster und implementieren dort ihre Programm-Images. Im Folgenden finden Sie eine abstrakte Struktur von Oyster:

Quelle: https://docs.marlin.org/oyster/protocol/cvm/workflow/

Oyster hat eine sehr ähnliche Struktur wie Akash. In Oyster besteht die Rolle der Blockchain darin, zu überprüfen, ob jede TEE-Berechnungsumgebung ordnungsgemäß funktioniert, und dies wird durch Beobachter namens Providers durchgeführt. Providers überprüfen kontinuierlich die Verfügbarkeit von Enclaves in Echtzeit und geben ihre Ergebnisse an das Oyster-Netzwerk weiter. Sie setzen ihr Kapital ein$PONDTokens, die gefährdet sind, gekürzt zu werden, wenn sie sich an bösartigen Aktivitäten beteiligen. Darüber hinaus existiert ein dezentrales Netzwerk von Entitäten, die als 'Prüfer' bezeichnet werden, um das Kürzen des Anbieters zu überwachen. Jede Epoche erhalten die Prüfer ihre Aufgaben und senden Prüfungsanfragen an Enklaven, die zufällig von einem in einer Enklave generierten Seed ausgewählt werden.

Allerdings hat Oyster einen Vertrag namens implementiertNitroProverdas die Remote-Attestationsergebnisse on-chain überprüft und Benutzern ermöglicht, die Integrität ihrer gekauften TEE on-chain zu überprüfen.

Benutzerbereitgestellte Instanzen können sowohl über Smart Contracts als auch über Web2-APIs erreicht werden. Die Berechnungsergebnisse können in Verträge integriert werden, indem sie als Oracles präsentiert werden. Wie im Dashboard gezeigt, ist diese Fähigkeit nicht nur für Smart Contracts, sondern auch zur Dezentralisierung von Web2-Diensten geeignet.

Ähnlich wie Akash ist Oyster anfällig für mögliche Instanzübernahmen durch Angreifer, wenn Schwachstellen im Off-Chain-Marktplatz vorhanden sind. In solchen Szenarien könnten zwar die Enklavendaten sicher bleiben, jedoch könnten Rohdaten, die außerhalb der Enklave gespeichert sind, sowie Betriebsberechtigungen des Dienstes kompromittiert werden. Im Falle sensibler Daten, die in nicht vertrauenswürdigem Speicher gespeichert sind, jedoch nicht freigegeben werden sollten, müssen Entwickler diese Daten verschlüsseln und separat speichern. Marlin bietet derzeit einen externen Speicher mit einem MPC-basierten persistenten Schlüssel, um diese Fälle zu behandeln.

2) Oyster Serverless

Während Oyster CVM als P2P TEE Marktplatz fungiert, ähnelt Oyster Serverless AWS Lambda (oder Function-as-a-Service) mit TEE. Mit Oyster Serverless können Benutzer Funktionen ohne Mieten von Instanzen ausführen und nach Bedarf bezahlen.

Der Ausführungsablauf von Oyster Serverless würde wie folgt aussehen:

1. Benutzer erstellen Anfragen an den Relay-Vertrag
2. Die Off-Chain-Gateway-Server beobachten Benutzeranfragen über Ereignisse
3. Der Gateway-Server leitet die Benutzeranfrage an das Gateway-Protokoll weiter.
4. Das Gateway-Protokoll erstellt und weist einen Job dem Serverless-Protokoll zu, basierend auf Benutzeranforderungen.
5. Executor-Server hören auf Jobs, die dem Serverless-Protokoll zugewiesen sind, führen den Job aus und senden die Antwort
6. Die Antwort - das Ergebnis der Benutzeranfrage - wird sequenziell an den Benutzer übermittelt

Mit Oyster Serverless können Benutzer Web2-API-Anfragen oder Smart-Vertragsaufrufe über einen Smart-Vertrag senden, während die Integrität der Ausführung durch TEE sichergestellt wird. Benutzer können auch Serverless für periodische Ausführung abonnieren, was insbesondere für Oracle-Abfrager nützlich wäre.

Phala Netzwerk

Phala, wie bereits in unserem Artikel AI X Crypto besprochen, hat seinen Fokus deutlich auf KI-Coprozessoren verlagert.

Das grundlegende Design des Phala-Netzwerks umfasst Arbeiter und Gatekeeper. Arbeiter fungieren als reguläre Knoten, die Berechnungen für Kunden ausführen. Gatekeeper hingegen verwalten Schlüssel, die es den Arbeitern ermöglichen, verschlüsselte Zustandswerte zu entschlüsseln und zu berechnen. Die Arbeiter verarbeiten Vertragszustandswerte, die über Intel SGX verschlüsselt sind und für das Lesen oder Schreiben dieser Werte Schlüssel von Gatekeepern erfordern.

Quelle: https://docs.phala.network/tech-specs/blockchain

Phala hat sein Angebot erweitert, indem es SDKs für vertrauliche VMs in Intel TDX-Umgebungen unterstützt. Kürzlich haben sie in Zusammenarbeit mit Flashbot Dstack eingeführt. Dieses Produkt verfügt über eine Remote-Attestation-API zur Überprüfung des Betriebsstatus mehrerer Docker-Containerbilder, die in vertraulichen VMs bereitgestellt sind. Die Remote-Attestation durch Dstack gewährleistet Transparenz über eine dedizierte Explorer.

Eine weitere bedeutende Entwicklung ist ihr Produkt für vertrauliche KI-Abfragen, das als Reaktion auf den jüngsten Anstieg von KI-Projekten eingeführt wurde. Phala Network unterstützt nun das relativ neue Nvidia vertrauliche Computing, um KI-Abfrage-Dienste mithilfe von ZK/FHE zu verbessern. Diese Technologie stand zuvor aufgrund hoher Overheadkosten vor Herausforderungen, die ihre Praktikabilität einschränkten.

Quelle: https://docs.phala.network/overview/phala-network/confidential-ai-inference

Das Bild veranschaulicht die Struktur des vertraulichen KI-Inferenzsystems von Phala Network. Dieses System nutzt vertrauenswürdige Ausführungsumgebungen (TEE) auf der virtuellen Maschinenebene wie Intel TDX und AMD SEV, um KI-Modelle bereitzustellen. Es führt KI-Inferenzen über Nvidia vertrauliches Computing durch und überträgt die Ergebnisse sicher zurück zum CPU-Enklave. Diese Methode kann im Vergleich zu regulären Modellen erhebliche Overheads verursachen, da sie zwei Runden der Enklaverechnung beinhaltet. Dennoch wird erwartet, dass sie wesentliche Leistungsverbesserungen gegenüber bestehenden TEE-basierten KI-Inferenzmethoden bietet, die ausschließlich auf die CPU-Leistung angewiesen sind. Laut PapierVeröffentlicht von Phala Network wurde der auf Llama3 basierende LLM-Abfrageoverhead auf etwa 6-8% gemessen.

Andere

Im AI X Crypto-Bereich gibt es weitere Beispiele für die Verwendung von TEEs als Coprozessoren, wie iExec RLC, PIN AI und Super Protocol. iExec RLC und PIN AI konzentrieren sich jeweils auf die Absicherung von KI-Modellen und Schulungsdaten durch TEEs. Super Protocol bereitet sich darauf vor, einen Marktplatz für den Handel mit TEE-Computing-Umgebungen ähnlich wie bei Marlin zu starten. Detaillierte technische Informationen zu diesen Projekten sind jedoch noch nicht öffentlich verfügbar. Wir werden nach dem Start ihrer Produkte Updates bereitstellen.

2.2. Sichere Smart Contracts

Oase (Prev. Rose)

Oasis, früher bekannt als Rose, ist eine Layer-1-Blockchain, die den Benutzerschutz während Transaktionen durch Ausführung ihres Execution-Clients innerhalb einer SGX-Enklave gewährleistet. Obwohl es sich um eine relativ reife Kette handelt, hat Oasis innovativ die Unterstützung für Multi-VM in ihrer Execution-Schicht implementiert.

Die Ausführungsebene, genannt Paratime, umfasst drei Komponenten: Cipher, eine auf WASM basierende vertrauliche VM; Sapphire, eine auf EVM basierende vertrauliche VM; und Emerald, eine standardmäßige EVM-kompatible VM. Oasis schützt smart contracts und ihre berechnungsprozesse grundsätzlich vor beliebigen änderungen durch Knotenpunkte und gewährleistet, dass der Ausführungsclient in einem TEE-Enklave ausgeführt wird. Diese Struktur ist in der begleitenden Diagramm dargestellt.

Quelle: https://docs.oasis.io/general/oasis-network/

Wenn Benutzer Transaktionen senden, verschlüsseln sie die Transaktionsdaten mit einem von der Schlüsselverwaltungseinheit des Oasis-Nodes generierten ephemeren Schlüssel und übertragen ihn an das Berechnungsmodul. Das Berechnungsmodul erhält den privaten Schlüssel für den ephemeren Schlüssel von der Schlüsselverwaltungseinheit, verwendet ihn zur Entschlüsselung der Daten innerhalb der Enklave, führt den Smart Contract aus und ändert die Zustandswerte des Knotens. Da die Ergebnisse der Transaktionsausführung ebenfalls in verschlüsselter Form an die Benutzer übermittelt werden, können weder der Server, der den Oasis-Node-Client betreibt, noch externe Entitäten den Inhalt der Transaktion beobachten.

Oasis betont seine Stärke bei der Erleichterung der Erstellung von DApps, die sensible persönliche Informationen auf öffentlichen Blockchains verarbeiten, unter Verwendung seiner vertraulichen Paratime. Diese Funktion ermöglicht die Entwicklung von Diensten, die eine Identitätsprüfung erfordern, wie z. B. SocialFi, Kreditvergabe, CEX-Integrationsservices und reputationsbasierte Dienste. Diese Anwendungen können Benutzerbiometrie oder KYC-Informationen sicher empfangen und verifizieren, die in einer sicheren Enklave gespeichert sind.

Secret Network

Secret Network ist eine Layer 1-Kette innerhalb des Cosmos-Ökosystems und gilt als eine der ältesten TEE-basierten Blockchains. Sie nutzt Intel SGX-Enklaven, um die Werte des Kettenzustands zu verschlüsseln und private Transaktionen für ihre Benutzer zu unterstützen.

In Secret Network verfügt jeder Vertrag über einen eindeutigen geheimen Schlüssel, der in der Enklave jedes Knotens gespeichert ist. Wenn Benutzer Verträge über Transaktionen aufrufen, die mit öffentlichen Schlüsseln verschlüsselt sind, entschlüsseln Knoten die Transaktionsdaten innerhalb des TEE, um mit den Zustandswerten des Vertrags zu interagieren. Diese geänderten Zustandswerte werden dann in Blöcken aufgezeichnet und bleiben verschlüsselt.

Der Vertrag selbst kann mit externen Entitäten in Bytecode- oder Quellcodeform geteilt werden. Das Netzwerk gewährleistet jedoch die Privatsphäre von Benutzertransaktionen, indem es eine direkte Beobachtung der vom Benutzer gesendeten Transaktionsdaten verhindert und eine externe Beobachtung oder Manipulation der aktuellen Vertragszustandswerte blockiert.

Da alle Smart-Contract-Statuswerte verschlüsselt sind, ist eine Entschlüsselung erforderlich, um sie anzuzeigen. Secret Network löst dieses Problem durch die Einführung von Anzeigeschlüsseln. Diese Schlüssel binden bestimmte Benutzerkennwörter an Verträge, sodass nur autorisierte Benutzer Vertragsstatuswerte beobachten können.

Clique, Quex-Protokoll

Im Gegensatz zu den zuvor eingeführten TEE-basierten L1s bieten Clique und Quex Protocol eine Infrastruktur, die es allgemeinen DApps ermöglicht, private Berechnungen an eine Off-Chain-TEE-Umgebung zu delegieren. Diese Ergebnisse können auf der Smart-Vertrags-Ebene genutzt werden. Sie werden insbesondere für verifizierbare Anreizverteilungsmechanismen, Off-Chain-Orderbücher, Orakel und den Schutz von KYC-Daten verwendet.

2.3. Gültigkeitsnachweissystem

Einige ZK L2-Ketten verwenden Multi-Proof-Systeme, um die inhärente Instabilität von Zero-Knowledge-Proofs zu adressieren, oft unter Einbeziehung von TEE-Proofs. Moderne Zero-Knowledge-Proof-Mechanismen haben noch nicht genügend Reife erlangt, um vollständig vertrauenswürdig für ihre Sicherheit zu sein, und Fehler im Zusammenhang mit Soundness in ZK-Schaltkreisen erfordern erhebliche Anstrengungen, um sie zu beheben, wenn Vorfälle auftreten. Als Vorsichtsmaßnahme verwenden Ketten, die ZK-Proofs oder ZK-EVMs verwenden, TEE-Proofs, um potenzielle Fehler zu erkennen, indem sie Blöcke durch lokale VMs innerhalb von Enklaven erneut ausführen. Derzeit verwenden L2s Multi-Proof-Systeme, einschließlich TEE, Taiko, Scroll und Ternoa. Lassen Sie uns kurz ihre Motivationen für die Verwendung von Multi-Proof-Systemen und ihre Strukturen untersuchen.

Taiko

Taiko ist derzeit die prominenteste (geplante) auf Rollup basierende Kette. Eine Rollup-Kette delegiert die Sequenzierung an die Ethereum-Block-Proposer, ohne einen separaten zentralisierten Sequenzer zu betreiben. Gemäß Taikos Diagramm des auf Rollup basierenden L2 suchen die L2-Searcher Transaktionsbündel zusammen und liefern sie als Chargen an L1. L1-Block-Proposer rekonstruieren diese dann zusammen mit L1-Transaktionen, um L1-Blöcke zu generieren und MEV zu erfassen.

Quelle: https://docs.taiko.xyz/core-concepts/multi-proofs/

In Taiko wird TEE nicht während der Blockzusammensetzungsphase verwendet, sondern in der Phase der Proof-Generierung, die wir erklären werden. Taiko mit seiner dezentralen Struktur erfordert keine Überprüfung von Sequenzer-Fehlfunktionen. Wenn es jedoch Fehler in der Codebasis des L2-Knoten-Clients gibt, kann ein vollständig dezentralisiertes Setup diese nicht schnell beheben. Dies erfordert Gültigkeitsnachweise auf hoher Ebene, um die Sicherheit zu gewährleisten, was im Vergleich zu anderen Rollups zu einem komplexeren Herausforderungsdesign führt.

Die Blöcke von Taiko durchlaufen drei Bestätigungsstufen: vorgeschlagen, bewiesen und verifiziert. Ein Block gilt als vorgeschlagen, wenn seine Gültigkeit vom L1-Vertrag (Rollup-Vertrag) von Taiko geprüft wird. Er erreicht den bewiesenen Zustand, wenn er von parallelen Beweisführern verifiziert wird, und den verifizierten Zustand, wenn sein übergeordneter Block bewiesen wurde. Um Blöcke zu verifizieren, verwendet Taiko drei Arten von Beweisen: SGX V2-basierter TEE-Beweis, Succinct/RiscZero-basierter ZK-Beweis und Guardian-Beweis, der auf zentralisiertem Multisig beruht.

Taiko verwendet ein Contestation-Modell zur Blockverifizierung und etabliert eine Sicherheitshierarchie unter den Provers: TEE, ZK, ZK+TEE und Guardian. Diese Konfiguration ermöglicht es Herausforderern, größere Belohnungen zu verdienen, wenn sie falsche Nachweise identifizieren, die von Modellen höherer Stufen generiert wurden. Für jeden Block werden Nachweise zufällig mit den folgenden Gewichtungen zugewiesen: 5% für SGX+ZKP, 20% für ZKP und der Rest unter Verwendung von SGX. Dadurch können ZK-Provers bei erfolgreichen Herausforderungen immer höhere Belohnungen verdienen.

Leser könnten sich fragen, wie SGX-Beweiser Beweise generieren und überprüfen. Die Hauptrolle der SGX-Beweiser besteht darin, nachzuweisen, dass die Blöcke von Taiko durch Standardberechnung generiert wurden. Diese Beweiser generieren Beweise für Zustandswertänderungen und überprüfen die Umgebung mithilfe von Ergebnissen aus der erneuten Ausführung von Blöcken über eine lokale VM innerhalb der TEE-Umgebung sowie Ergebnissen der Enklavenattestation.

Im Gegensatz zur ZK-Beweisgenerierung, die erhebliche Rechenkosten verursacht, überprüft die TEE-basierte Beweisgenerierung die Rechenintegrität bei ähnlichen Sicherheitsannahmen zu wesentlich geringeren Kosten. Die Überprüfung dieser Beweise umfasst einfache Checks wie die Überprüfung, ob die in dem Beweis verwendete ECDSA-Signatur mit der Signatur des Beweisers übereinstimmt.

Abschließend können TEE-basierte Gültigkeitsnachweise als eine Methode angesehen werden, um die Integrität der Kette zu überprüfen, indem Nachweise mit leicht niedrigeren Sicherheitsniveaus generiert werden, jedoch zu erheblich geringeren Kosten im Vergleich zu ZK-Nachweisen.

Bildlauf

Scroll ist ein bemerkenswerter Rollup, der ein Multi-Beweissystem übernimmt. Er arbeitet mit Automata, einer später eingeführten Attestationsschicht, zusammen, um sowohl ZK-Beweise als auch TEE-Beweise für alle Blöcke zu generieren. Diese Zusammenarbeit aktiviert ein Streitsystem zur Beilegung von Konflikten zwischen den beiden Beweisen.

Quelle: https://scroll.io/blog/scaling-security

Scroll plant, verschiedene Hardware-Umgebungen (derzeit nur SGX), einschließlich Intel SGX, AMD SEV und AWS Nitro, zu unterstützen, um Hardware-Abhängigkeiten zu minimieren. Sie adressieren potenzielle Sicherheitsprobleme in TEE, indem sie Beweise aus diversen Umgebungen sammeln, die Schwellensignaturen verwenden.

Ternoa

Ternoa priorisiert die Erkennung bösartiger Handlungen durch zentralisierte L2-Entitäten gegenüber der Behebung von Fehlern in der Ausführung selbst. Im Gegensatz zu Taiko oder Scroll, die TEE-Prover nutzen, um vorhandene ZK-Beweise zu ergänzen, verwendet Ternoa Beobachter in TEE-basierten Umgebungen. Diese Beobachter erkennen bösartige Handlungen durch L2-Sequencer und Validatoren und konzentrieren sich auf Bereiche, die allein anhand von Transaktionsdaten nicht bewertet werden können. Beispiele hierfür sind RPC-Knoten, die Transaktionen aufgrund von IP-Adressen zensieren, Sequencer, die Sequenzieralgorithmen verändern, oder absichtliches Unterlassen der Übermittlung von Stapeldaten.

Ternoa betreibt ein separates L2-Netzwerk namens Integrity Verification Chain (IVC) für Verifizierungsaufgaben im Zusammenhang mit Rollup-Entitäten. Der Rollup-Framework-Anbieter sendet das neueste Sequencer-Image an das IVC. Wenn ein neuer Rollup-Bereitstellungsantrag gestellt wird, gibt das IVC Service-Images zurück, die in TEE gespeichert sind. Nach der Bereitstellung überprüfen Observers regelmäßig, ob der bereitgestellte Rollup das Sequencer-Image wie beabsichtigt verwendet. Sie reichen dann Integritätsbeweise ein, die ihre Verifizierungsergebnisse und Attestationsberichte aus ihrer TEE-Umgebung enthalten, um die Kettenintegrität zu bestätigen.

2.3. Ethereum-Sicherheit

2.3.1. Block Builder Dezentralisierung

Flashbots BuilderNet

Flashbots, allgemein anerkannt als ein MEV-Lösungsanbieter, hat kontinuierlich die Anwendung von Trusted Execution Environments (TEE) in der Blockchain-Technologie erforscht. Bemerkenswerte Forschungsbemühungen umfassen:

• Untersuchung der Ausführung von Geth innerhalb einer SGX-Enklave und ihrer Einschränkungen
• Implementierung eines SGX-basierten Block-Builders
• Aufbau einer TEE-Coprozessorkette auf Basis der REVM-Ausführung innerhalb eines SGX-Enklaven, ergänzt durch eine Automata-Verifizierungsschicht

In diesem Artikel werden wir kurz die aktuelle Rolle von Flashbots umreißen und BuilderNet diskutieren, eine kürzlich gestartete Initiative zur Dezentralisierung des Blockaufbaus. Flashbots hat vollständige Migrationspläne für ihre bestehende Lösung durch BuilderNet angekündigt.

Ethereum verwendet ein Proposer-Builder-Trennungsmodell. Dieses System teilt die Blockerstellung in zwei Rollen auf - 1) Builder: Verantwortlich für die Blockerstellung und MEV-Extraktion 2) Proposer: Signieren und propagieren von Blöcken, die von den Buildern erstellt wurden, um die dezentralen MEV-Profite zu dezentralisieren. Diese Struktur hat dazu geführt, dass einige dezentrale Anwendungen off-chain mit Buildern zusammenarbeiten, um erhebliche MEV-Profite zu erzielen. Als Ergebnis erstellen einige Builder wie Beaverbuild und Titan Builder monopolistisch über 90% der Ethereum-Blöcke. In schweren Fällen können diese Builder willkürliche Transaktionen zensieren. Beispielsweise werden regulierte Transaktionen wie die von Tornado Cash aktiv von den größten Buildern zensiert.

BuilderNet adressiert diese Probleme, indem es die Transaktionsprivatsphäre verbessert und die Barrieren für die Teilnahme von Block-Builder reduziert. Seine Struktur kann grob wie folgt zusammengefasst werden:

Quelle: https://buildernet.org/docs/architecture

Builder-Knoten, die Benutzertransaktionen (Orderflow) empfangen, werden von verschiedenen Knotenbetreibern verwaltet. Jeder betreibt Open-Source-Builder-Instanzen innerhalb von Intel TDX-Umgebungen. Benutzer können die TEE-Umgebung jedes Betreibers frei überprüfen und verschlüsselte Transaktionen senden. Die Betreiber teilen dann ihren erhaltenen Orderflow, reichen Blöcke an das MEV-Boost-Relais ein und verteilen Blockbelohnungen an Suchende und andere, die an der Blockerstellung beteiligt sind, nach erfolgreicher Einreichung.

Diese Struktur bietet mehrere Dezentralisierungsvorteile:

• Überprüfbarkeit: Jede Builder-Instanz arbeitet innerhalb einer TEE und ermöglicht es Benutzern, zu überprüfen, dass Builder Transaktionen nicht zensiert oder Clients willkürlich modifiziert haben. Die Belohnungsverteilungspolitik für Blockerstellungsbeteiligte ist auch innerhalb der TEE transparent.
• Zensurresistenz: Im BuilderNet werden Builder-Nodes von mehreren Betreibern betrieben, von denen jeder unterschiedliche regulatorische Richtlinien hat. Diese Vielfalt bedeutet, dass sie sich für verschiedene Transaktionen entscheiden, die ausgeschlossen werden sollen. Selbst wenn einige Betreiber Transaktionen zensieren, können andere sie immer noch auswählen. Theoretisch können Benutzertransaktionen, wenn es mindestens einen nicht zensierenden Builder gibt, in Blöcke aufgenommen werden. BuilderNet bietet auch eine Lösung für L2-Zensurprobleme und zeigt, dass L2s durch Auslagerung des Blockaufbaus an BuilderNet eine höhere Zensurresistenz erreichen können als einzelne Sequenzer. (In diesem Fall kann der Grad der Zensurresistenz durch zusätzliche Komponenten, die die Transaktionen vor dem Sequenzer filtern, z. B. Firewall, beeinflusst werden)
• Dezentralisierung: Aktuelle Block-Builder werden durch ihre Abhängigkeit von zentralisierter Infrastruktur herausgefordert. BuilderNet zielt darauf ab, dies zu lösen, indem verschiedene Builder integriert werden, beginnend mit Beaverbuild. Mit dem Beitritt weiterer Block-Builder zu BuilderNet wird die Dezentralisierung der PBS-Struktur von Ethereum zunehmen. Derzeit gehören nur Beaverbuild, Flashbots und Nethermind zu BuilderNet. Andere Builder benötigen eine Erlaubnis, um beizutreten, aber es gibt Pläne, die Berechtigung für den Betrieb in Zukunft zu entfallen und die zentralisierte Infrastruktur vollständig zu beseitigen.

2.3.2. Validator-Schutz

Puffer Finanzen

Puffer Finance hat ein Secure Signer-Tool eingeführt, das entwickelt wurde, um das Risiko von Ethereum-Validatoren, die aufgrund von Client-Fehlern oder Fehlern in der Software gestutzt werden, zu reduzieren. Dieses Tool verwendet einen SGX-Enclave-basierten Signer für erhöhte Sicherheit.

Quelle: https://docs.puffer.fi/technology/secure-signer/

Der Secure Signer funktioniert, indem er BLS-Validierungsschlüssel im SGX-Enklaven generiert und speichert und diese nur bei Bedarf zugreift. Seine Logik ist einfach: Neben der Sicherheit, die die Trusted Execution Environment (TEE) bietet, kann er Validierungsfehler oder bösartige Aktionen erkennen. Dies wird erreicht, indem sichergestellt wird, dass die Slots streng erhöht werden, bevor Blöcke oder Beweise unterschrieben werden. Puffer Finance hebt hervor, dass diese Einrichtung es den Validierern erlaubt, Sicherheitsstufen zu erreichen, die mit Hardware-Wallets vergleichbar sind, und die typischen Schutzmaßnahmen übertreffen, die von Softwarelösungen angeboten werden.

2.4. Dezentralisierung des L2-Sequenzers

Unichain

Unichain, Ethereum Layer 2 (L2) Kette von Uniswap, die für das erste Quartal nächsten Jahres geplant ist, hat in ihrem Whitepaper Pläne zur Dezentralisierung der L2 Block-Building-Mechanismen mithilfe von Trusted Execution Environments (TEE) geteilt. Obwohl detaillierte technische Spezifikationen noch nicht veröffentlicht wurden, hier eine Zusammenfassung ihrer wichtigsten Vorschläge:

• Sequenzer-Builder-Trennung: Zur Verbesserung bestehender Rollup-Strukturen, bei denen die Sequenzierung und die L2-Blockgenerierung von zentralisierten Sequenzern durchgeführt werden, hat Unichain mit Flashbots zusammengearbeitet. Diese Partnerschaft zielt darauf ab, L2-Sequenzer von Block-Buildern zu trennen. Die Block-Builder von Unichain werden unter Verwendung von Open-Source-Code innerhalb von Intel TDX betrieben, um Transparenz zu gewährleisten, indem sie die Attestationsergebnisse für die Ausführung öffentlich veröffentlichen.
• Flashblock: Unichain identifiziert Einschränkungen in der Skalierbarkeit des aktuellen Vorbestätigungsprozesses, der von Rollup-Sequenzern bereitgestellt wird, wie Serialisierung und Zustands-Root-Generierung. Um diese zu lösen, planen sie, "Flashblocks" einzuführen, die es Benutzern ermöglichen, ausstehende Blöcke unmittelbar nach der Transaktionsreihenfolge durch TEE-Builder zu empfangen. Sie betonen, dass die Sequenzierung innerhalb von TEE sicherstellt, dass die Transaktionsreihenfolge ausschließlich auf Prioritätsgebühren und Einreichungszeit basiert, ohne Sequenzer-Interferenz, was eine schnellere Vorbestätigung ermöglicht.

Darüber hinaus beabsichtigt Unichain, verschiedene TEE-basierte Funktionen zu entwickeln, darunter einen verschlüsselten Mempool, geplante Transaktionen und TEE-geschützte Smart Contracts.

2.5. Private RPC

Automaten

Obwohl die Blockchain in architektonischer Hinsicht eine beträchtliche Dezentralisierung erreicht hat, weisen viele Elemente immer noch keine ausreichende Zensurbeständigkeit auf, da sie von Serverbetreibern abhängig sind. Automata zielt darauf ab, Lösungen anzubieten, die die Abhängigkeit von Serverbetreibern und die Datenexposition in der Blockchain-Architektur auf Basis von TEE minimieren. Zu den bemerkenswerten Implementierungen von Automata gehören Open Source ...SGX Proverund Verifier,TEE Kompilierenwelches Übereinstimmungen zwischen in TEE bereitgestellten ausführbaren Dateien und Quellcode überprüft undTEE BuilderAutomata fügt der Blockbau-Mechanismus-Privatsphäre hinzu, indem es TEE-basierten Mempool und Block-Builder verwendet. Darüber hinaus ermöglicht Automata die Veröffentlichung des Remote-Attestation-Ergebnisses von TEE onchain, was eine öffentliche Verifizierung und Integration in Smart Contracts ermöglicht.

Automata betreibt derzeit 1RPC, einen TEE-basierten RPC-Dienst, der entwickelt wurde, um Identifizierungsinformationen von Transaktionseinreichern wie IP- und Gerätedetails durch sichere Enklaven zu schützen. Automata weist darauf hin, dass mit der Kommerzialisierung von UserOp aufgrund der Account-Abstraktion durch die Integration von KI in RPC-Dienste UserOp-Muster für bestimmte Benutzer abgeleitet werden könnten, was die Privatsphäre beeinträchtigen könnte. Die Struktur von 1RPC ist unkompliziert. Es stellt sichere Verbindungen mit Benutzern her, empfängt Transaktionen (UserOp) in die TEE und verarbeitet sie mit dem in der Enklave bereitgestellten Code. Allerdings schützt 1RPC nur UserOp-Metadaten. Die tatsächlich beteiligten Parteien und Transaktionsinhalte bleiben während der Interaktion mit dem On-Chain Entrypoint offen. Ein grundlegenderer Ansatz zur Gewährleistung der Transaktionsprivatsphäre würde den Schutz der Mempool- und Blockbuilder-Schichten mit TEE erfordern. Dies könnte durch Integration mit Automatas TEE Builder erreicht werden.

2.6. KI-Agenten

Quelle:https://x.com/tee_hee_he

Was TEE letztendlich in Web3 in den Vordergrund brachte, war der auf TEE basierende Twitter AI-Agent. Viele Menschen sind wahrscheinlich zum ersten Mal auf TEE gestoßen, als ein KI-Agent namens @tee_hee_heerschien Ende Oktober auf X und startete seine Mememünze auf Ethereum.@tee_hee_heist ein KI-Agent, der gemeinsam von Nous Research und dem Teleport-Projekt von Flashbots entwickelt wurde. Er entstand als Reaktion auf Bedenken, dass damals beliebte KI-Agenten-Accounts nicht nachweisen konnten, dass sie tatsächlich Ergebnisse von KI-Modellen übermitteln. Die Entwickler entwarfen ein Modell, das den Eingriff zentralisierter Einrichtungen bei Prozessen wie der Einrichtung eines Twitter-Accounts, der Erstellung einer Kryptowallet und der Übermittlung von Ergebnissen von KI-Modellen minimierte.

Quelle: @tee_hee_he/setting-your-pet-rock-free-3e7895201f46">https://medium.com/@tee_hee_he/setting-your-pet-rock-free-3e7895201f46

Sie haben den KI-Agenten in einer Intel TDX-Umgebung bereitgestellt, der E-Mail, X-Kontopasswörter und OAuth-Token für den Zugriff auf Twitter durch Browser-Simulation generiert und dann alle Wiederherstellungsoptionen entfernt.

Kürzlich wurde TEE im ähnlichen Kontext für AI-Pool verwendet, wo @123skely erfolgreich durchgeführtes Fundraising. Derzeit sichern sich technisch überlegene Scharfschützen-Bots nach der Bereitstellung ihrer Verträge und der Veröffentlichung der Adressen der KI-Meme-Coins in der Regel den größten Teil der Liquidität und manipulieren die Preise. AI-Pool versucht, dieses Problem zu lösen, indem KI eine Art Vorverkauf durchführt.

Quelle: https://x.com/0xCygaar/status/1871421277832954055

Ein weiterer interessanter Fall ist DeepWorm, ein KI-Agent mit einem bio-neuronalen Netzwerk, das das Gehirn eines Wurms simuliert. Ähnlich wie die anderen KI-Agenten lädt DeepWorm das Enklavenbild seines Wurmgehirns in das Marlin Network hoch, um ihr Modell zu schützen und die Überprüfbarkeit ihres Betriebs zu gewährleisten.

Quelle: https://x.com/deepwormxyz/status/1867190794354078135

Seit @tee_hee_heNachdem der Quellcode für die Bereitstellung offen zugänglich gemacht wurde, ist es ziemlich einfach geworden, vertrauenswürdige, unruggable TEE-basierte KI-Agenten bereitzustellen. Kürzlich hat das Phala Network a16z's Eliza in TEE bereitgestellt. Wie a16z in ihrem Bericht zur Kryptowährungsmarktaussicht 2025 betont hat, wird erwartet, dass der TEE-basierte KI-Agentenmarkt in Zukunft als wesentliche Infrastruktur auf dem Markt für KI-Agenten-Mememünzen fungiert.

2.7. Soziales Spiel

Azuki Bobu

Azuki, ein renommiertes Ethereum NFT-Projekt, hat im vergangenen Oktober mit Flashbots zusammengearbeitet, um eine einzigartige soziale Veranstaltung zu veranstalten.

Quelle: https://x.com/Azuki/status/1841906534151864557

Dies umfasste die Delegation von Twitter-Kontoupladungsberechtigungen an Flashbots und Bobu, die dann gleichzeitig Tweets veröffentlichten, ähnlich wie bei einem Flashmob. Das Ereignis war ein Erfolg, wie auf dem folgenden Bild gezeigt.

Quelle: https://collective.flashbots.net/t/tee-enabled-social-games-an-experiment-with-bobu-s-magic-show/3963

Entworfen von Flashbots und Azuki, war die Ereignisstruktur wie folgt:

1. Generieren Sie TLS-Privatschlüssel und Zertifikate sowie Ethereum-Privatschlüssel innerhalb von Gramin-SGX.
2. Benutzer erstellten OAuth-Token mit eingeschränkten Berechtigungen, um einen einzelnen Tweet zu posten, und übermittelten sie über TLS an das TEE von Flashbots.
3. Auf Arbitrum wurde ein Vertrag erstellt, um Benutzerzertifikate zu verwalten, Doppelausgaben zu verhindern und Ereignisausgaben beim Hochladen von Benutzer-Tweets zu implementieren.

Azuki sicherte die Zuverlässigkeit des Ereignisprozesses, indem sie das Docker-Image von Enclave auf Docker Hub veröffentlichte. Sie luden auch Skripte zur Zertifikatstransparenzprotokoll-Überprüfung und Fernattestierungsergebnisse für die TEE-Umgebung auf GitHub hoch. Obwohl Flashbots Abhängigkeiten von RPC und Blockchain-Knoten als verbleibende Risiken identifiziert hat, können diese durch die Verwendung von TEE RPC oder TEE-basierten Rollups wie Unichain gemildert werden.

Obwohl das Projekt keinen technischen Durchbruch erzielte, ist es bemerkenswert, dass es ein vertrauenswürdiges gesellschaftliches Ereignis ausschließlich mit einem TEE-Stack durchführt.

3. Sicherheit des TEE

TEE bietet im Vergleich zu herkömmlichen Softwarelösungen eine wesentlich höhere Sicherheit, da es Sicherheit auf Hardware-Ebene bietet, die Software nicht direkt beeinträchtigen kann. Allerdings hat TEE aufgrund einiger Einschränkungen bisher nur langsam in konkreten Produkten Verwendung gefunden, die wir vorstellen werden.

1) Zentralisierte Attestationsmechanismus

Wie bereits erwähnt, können Benutzer Remote-Attestationsmechanismen nutzen, um die Integrität von TEE-Enklaven und die Unversehrtheit der Daten in den Enklaven zu überprüfen. Dieser Verifizierungsprozess hängt jedoch unweigerlich von den Servern des Chipsatzherstellers ab. Das Vertrauensniveau variiert geringfügig je nach Anbieter - SGX/TDX ist vollständig von Intels Attestationsserver abhängig, während SEV es den VM-Besitzern ermöglicht, die Attestation direkt durchzuführen. Dies ist ein inhärentes Problem in der TEE-Struktur, und TEE-Forscher arbeiten daran, dies durch die Entwicklung von Open-Source-TEE zu lösen, auf das wir später eingehen werden.

2) Seitenkanal-Angriffe

TEE darf niemals Daten offenlegen, die in Enklaven gespeichert sind. Da TEE jedoch nur Daten innerhalb von Enklaven verschlüsseln kann, können Schwachstellen durch Angriffe entstehen, die sekundäre Informationen und nicht die Originaldaten nutzen. Seit der Veröffentlichung von Intel SGX im Jahr 2015 wurden zahlreiche kritische Seitenkanalangriffe auf Top-Sicherheitskonferenzen hervorgehoben. Nachfolgend sind potenzielle Angriffsszenarien in TEE-Anwendungsfällen aufgeführt, die nach ihrem Auswirkungsbereich kategorisiert sind:

• Kontrollverlust: Bösartige Betriebssysteme oder Programme können Daten wiederherstellen, indem sie verfügbare Informationen ausnutzen. Sie können sich beispielsweise die Tatsache zunutze machen, dass der Zugriff auf CPU-Cache-Daten viel schneller ist als der auf DRAM-Daten. Auf diese Weise können sie Ausführungsmuster von Vorgangscode identifizieren und wichtige Programminformationen, wie z. B. RSA-Schlüssel, ableiten. Darüber hinaus kann ein Angriff auftreten, wenn ein böswilliges Betriebssystem den Zugriff auf Speicherseiten einschränkt, wodurch Seitenfehler im Enclave-Code verursacht werden, um Speicherzugriffsmuster offenzulegen. Durch das Bearbeiten des Verzweigungszielpuffers zum Vorhersagen und Verwalten von Codeverzweigungen kann auch der Codeausführungsfluss aufgedeckt werden. Darüber hinaus können Angreifer wiederholt Enklavencode in Mikroskopangriffen ausführen, um Informationen abzuleiten.
• Datenleckage: Schwachstellen, die Enklaven-Daten durchsickern lassen, können zu kritischen Angriffen führen und Remote-Attestation potenziell untergraben. Insbesondere wurden geheime Schlüssel innerhalb einer Enklave durch die Erstellung von Schatten-Apps, die Enklaven-Code und -Daten emulieren, und die Ausführung von ROP-Angriffen darauf (Dark-ROP) geleakt. Zusätzliche Schwachstellen ergeben sich aus der spekulativen Ausführung von Programmen auf Intel-CPUs zur Leistungssteigerung (Foreshadow). Obwohl der Enklavenspeicher durch Verschlüsselung geschützt ist, kann auf Daten zugegriffen werden, die von spekulativ ausgeführten Anweisungen kurzzeitig im Cache verbleiben. Dies kann ausgenutzt werden, um Enklavendaten über Cache-Seitenkanal-Angriffe zu lesen.
• DoS-Angriffe: Bei SGX wird das System angehalten, wenn Integritätsprüfungen des Speichers Manipulationen erkennen. Diese Schwachstelle wird bei DoS-Angriffen ausgenutzt, indem absichtlich Integritätsprüfungsscheitern verursacht wird. Angreifer können das System zum Stillstand bringen, indem sie wiederholt auf bestimmte DRAM-Reihen zugreifen, um Bit-Flips in benachbarten Reihen zu verursachen und potenziell den Enklavenspeicher zu beschädigen.

Obwohl TEE kein System ist, das alle Angriffsvektoren neutralisiert und aufgrund seiner grundlegenden Eigenschaften verschiedene Ebenen von Informationen preisgeben kann, erfordern diese Angriffe starke Voraussetzungen, wie z.B. dass Angreifer- und Opfercode auf demselben CPU-Kern ausgeführt werden. Dies hat dazu geführt, dass es als Sicherheitsmodell des „Mannes mit der Glock“ beschrieben wird.

Quelle: https://x.com/hdevalence/status/1613247598139428864

Da jedoch das grundlegende Prinzip von TEE „niemandem vertrauen“ ist, glaube ich, dass TEE Daten auch innerhalb dieses Modells schützen können sollte, um seine Rolle als Sicherheitsmodul vollständig zu erfüllen.

3) Echte Welt / Aktuelle Angriffe auf TEE

In TEE-Implementierungen, insbesondere in SGX, wurden zahlreiche Fehler entdeckt und die meisten wurden erfolgreich behoben. Die komplexe Hardwarearchitektur von TEE-Systemen bedeutet jedoch, dass mit jeder Hardwareversion neue Sicherheitslücken auftreten können. Neben der akademischen Forschung gab es auch reale Angriffe auf Web3-Projekte, die eine detaillierte Untersuchung erfordern.

• Geheimes Netzwerk: Als eines der wenigen Opfer echter TEE-Exploits erlag dieses SGX-basierte Projekt dem 2022 entdeckten ÆPIC Leakage-Angriff. Der Angriff zielte auf den AVX-Befehlssatz (Advanced Vector Extensions) in neueren Intel-CPUs ab. Es nutzte spekulative Ausführungsmuster während AVX-Vorgängen, um Verschlüsselungsschlüssel wiederherzustellen, die in Enklavenregionen gespeichert waren. Secret Network verwendete einen Konsens-Seed für Validatoren, um private Transaktionen zu entschlüsseln. Der Angreifer hat diesen Seed erfolgreich extrahiert und so die Entschlüsselung aller historischen privaten Transaktionen im Netzwerk ermöglicht. Weitere Details zu dieser Sicherheitsanfälligkeit finden Sie unter sgx.fail.
• SGX-Root-Schlüssel-Exposition: Im August kündigte der Sicherheitsforscher Mark Ermolov die erfolgreiche Entschlüsselung des Root-Bereitstellungs-Schlüssels und des Root-Versiegelungs-Schlüssels von SGX an, die wesentliche Bestandteile des kryptografischen Vertrauensmodells von SGX sind. Diese Schlüssel werden normalerweise durch komplexe Logik innerhalb eines physischen Fuse-Controller-Geräts geschützt. Es wurde jedoch eine kritische Sicherheitslücke gefunden, bei der Kopien dieser Schlüssel während der Operationen in internen Puffern verblieben. Obwohl allein der Besitz dieser beiden Schlüssel SGX nicht vollständig kompromittiert, könnte der Erhalt des Global Wrapping Key das gesamte SGX-System potenziell anfällig machen. Obwohl SGX in kommerziellen Intel-CPUs, die nach 2021 veröffentlicht wurden, veraltet ist, bleibt es ein realistischer Angriffsvektor, da mehrere Projekte es immer noch nutzen.
• AMD SEV-SNP-Schwachstelle: AMD SEV, eine relativ neue TEE-Implementierung mit einem breiten Schutzumfang auf der Ebene der virtuellen Maschine, hat historisch gesehen weniger Sicherheitslücken im Vergleich zu SGX gezeigt. Die Annahme eines Papiers auf der IEEE S&P 2025, das die Schwachstelle "BadRAM" bei AMD SEV-SNP behandelt, verdeutlicht jedoch, dass auch moderne TEE-Implementierungen nicht vor Sicherheitslücken gefeit sind. BadRAM nutzt DDR4- und DDR5-Speichermodule aus, um Adressraumaliasing im physischen Speicher zu erzeugen. Mit einem Raspberry Pi Pico, der etwa 10 US-Dollar kostet, können Angreifer Speicherchips modifizieren, um die CPU über die Größe des physischen Speichers zu täuschen. Dadurch umgeht AMD SEV-SNP den Schutzmechanismus RMP (Reverse Map Table) effektiv. Weitere Details zur Schwachstelle werden in badram.eu.

Diese Fälle zeigen, dass eine 'vollständig sichere TEE' unerreichbar ist und Benutzer potenzielle Sicherheitslücken bei neuen Hardware-Veröffentlichungen beachten sollten.

4. Fazit: Open Source ist die Zukunft

Im November skizzierte Georgios Konstantopoulos von Paradigm eine Frameworkzur vertraulichen Hardware-Entwicklung, die sichere Hardware in fünf verschiedene Stufen einteilt:

• Stufe 1: Bietet ausreichende Vertraulichkeit für Oracle- und Bridge-Anwendungen, wobei die Sicherheit von der Lieferkette abhängt. Beispiele sind SGX.
• Stufe 2: Behält die Sicherheit der Stufe 1 bei, verbessert jedoch die Entwicklererfahrung und unterstützt erweiterte Anwendungen wie die OAuth-Kontodelegation, wie sie bei Teleport zu sehen ist. Gramine SGX ist ein Beispiel für diese Stufe.
• Stufe 3: Erweitert die Sicherheit der Stufe 1 um GPU-Unterstützung und ermöglicht anspruchsvolle Anwendungen wie privates und überprüfbares maschinelles Lernen. Intel TDX + Nvidia Confidential Computing repräsentiert diese Stufe.
• Stufe 4: Verwendet Open-Source-Befehlssätze mit öffentlich überprüfbaren Fertigungsprozessen und beseitigt Abhängigkeiten von Hardwareherstellern, wie von OpenTEE demonstriert.
• Stufe 5: Erreicht einen idealen Zustand, in dem mehrere OpenTEEs durch FHE/MPC zusammenarbeiten und die Integrität erhalten, auch wenn einzelne Hardwareeinheiten kompromittiert sind.

Derzeit arbeiten Projekte wie Phala Network's Confidential AI Inference auf Level 3, während die meisten Dienste auf Level 2 mit Cloud TEE oder Intel TDX bleiben. Obwohl Web3 TEE-basierte Projekte letztendlich auf Hardware der Stufe 4 fortschreiten sollten, machen aktuelle Leistungsbeschränkungen dies unpraktisch. Mit renommierten Risikokapitalgebern wie Paradigm und Forschungsteams wie Flashbots und Nethermind, die sich für die Demokratisierung von TEE einsetzen, und angesichts der Übereinstimmung von TEE mit den Web3-Prinzipien wird es wahrscheinlich zu einer wesentlichen Infrastruktur für Web3-Projekte werden.

Über ChainLight

Ecosystem Explorer ist der Bericht von ChainLight, der interne Analysen zu Trendprojekten des Web3-Ökosystems aus einer Sicherheitsperspektive vorstellt, die von unseren Research-Analysten verfasst wurden. Mit der Mission, Sicherheitsforscher und -entwickler dabei zu unterstützen, gemeinsam zu lernen, zu wachsen und dazu beizutragen, Web3 zu einem sichereren Ort zu machen, veröffentlichen wir unseren Bericht regelmäßig und kostenlos.

Um die neuesten Forschungsberichte von preisgekrönten Experten zu erhalten:

👉 Folgen Sie @ ChainLight_io@C4LVIN

Die preisgekrönten Experten von ChainLight wurden 2016 gegründet und bieten maßgeschneiderte Sicherheitslösungen, um Ihren Smart Contract zu stärken und Ihnen zu helfen, auf der Blockchain erfolgreich zu sein.

Haftungsausschluss:

1. Dieser Artikel wurde aus [wiedergegebenChainlight]. Alle Urheberrechte gehören dem Originalautor [c4lvin*]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an den Gate LearnTeam und sie werden es schnell bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Das Gate Learn Team hat den Artikel in andere Sprachen übersetzt. Das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel ist untersagt, es sei denn, es wird erwähnt.