Entwicklerhandbuch für TEE

Autoren: Prateek, Roshan, Siddhartha & Linguine (Marlin), Krane (Asula) Übersetzung: Shew, GodRealmX

Seit Apple die Einführung von privaten Clouds und NVIDIA die Bereitstellung von vertraulichen Berechnungen in GPUs angekündigt haben, wird die Trusted Execution Environment (TEE) immer beliebter. Die Gewährleistung der Vertraulichkeit trägt dazu bei, Benutzerdaten (einschließlich möglicherweise privater Schlüssel) zu schützen, während die Isolierung sicherstellt, dass die Ausführung der darauf bereitgestellten Programme nicht manipuliert wird - sei es durch Menschen, andere Programme oder Betriebssysteme. Daher ist es nicht überraschend, dass im Bereich Crypto x AI eine Vielzahl von Produkten auf TEE basiert.

Wie bei jeder neuen Technologie durchläuft TEE eine optimistische Experimentierphase. Dieser Artikel soll Entwicklern und allgemeinen Lesern einen grundlegenden Leitfaden bieten, um zu verstehen, was TEE ist, das Sicherheitsmodell von TEE, häufige Schwachstellen und bewährte Sicherheitspraktiken bei der Verwendung von TEE. (Hinweis: Um den Text verständlicher zu machen, haben wir die TEE-Begriffe absichtlich durch einfachere gleichwertige Begriffe ersetzt).

Was ist TEE

TEE ist eine isolierte Umgebung in Prozessoren oder Rechenzentren, in der Programme ausgeführt werden können, ohne von anderen Teilen des Systems beeinträchtigt zu werden. Um sicherzustellen, dass TEE nicht von anderen Teilen beeinträchtigt wird, benötigen wir eine Reihe von Designs, hauptsächlich streng kontrollierten Zugriff, um den Zugriff anderer Teile des Systems auf Programme und Daten in TEE zu kontrollieren. TEE ist derzeit weit verbreitet in Mobiltelefonen, Servern, PCs und Cloud-Umgebungen, daher ist es sehr zugänglich und preiswert.

Der obige Inhalt kann vage und abstrakt klingen, aber die Implementierung von TEE unterscheidet sich tatsächlich je nach Server und Cloud-Anbieter. Das grundlegende Ziel besteht jedoch darin, zu vermeiden, dass TEE von anderen Programmen beeinträchtigt wird.

Die meisten Leser verwenden wahrscheinlich biometrische Informationen, um sich bei Geräten anzumelden, z. B. durch das Entsperren eines Telefons mit dem Fingerabdruck. Aber wie können wir sicherstellen, dass bösartige Anwendungen, Websites oder Jailbreak-Betriebssysteme nicht auf diese biometrischen Informationen zugreifen und sie stehlen können? Tatsächlich erlaubt der Schaltkreis in TEE-Geräten neben der Verschlüsselung der Daten keinen Programmen den Zugriff auf den Speicher- und Prozessorbereich, in dem sensible Daten gespeichert sind.

Die Hardware-Wallet ist ein weiteres Beispiel für Anwendungsszenarien von TEE. Die Hardware-Wallet ist mit dem Computer verbunden und kommuniziert mit ihm in einer Sandbox, aber der Computer kann nicht direkt auf das in der Hardware-Wallet gespeicherte Mnemonic zugreifen. In beiden oben genannten Fällen vertrauen die Benutzer darauf, dass der Gerätehersteller in der Lage ist, den Chip richtig zu entwerfen und angemessene Firmware-Updates bereitzustellen, um zu verhindern, dass vertrauliche Daten in TEE exportiert oder angezeigt werden.

Sicherheitsmodell

Leider gibt es viele verschiedene Arten von TEE-Implementierungen (Intel SGX, Intel TDX, AMD SEV, AWS Nitro Enclaves, ARM TrustZone), die jeweils ein eigenes Sicherheitsmodell erfordern. In diesem Artikel werden wir hauptsächlich über Intel SGX, TDX und AWS Nitro sprechen, da diese TEE-Systeme über eine größere Benutzerbasis und vollständige Entwicklertools verfügen. Diese Systeme sind auch die am häufigsten verwendeten TEE-Systeme in Web3.

Im Allgemeinen sieht der Arbeitsablauf einer in TEE bereitgestellten Anwendung wie folgt aus:

1. Die “Entwickler” haben einige Codes geschrieben, die möglicherweise quelloffen oder auch nicht sein könnten
2. Anschließend packt der Entwickler den Code in eine Enclave-Abbilddatei (EIF), die im TEE ausgeführt werden kann.
3. EIF wird auf einem Server mit TEE-System gehostet. In einigen Fällen können Entwickler EIF direkt auf einem persönlichen Computer mit TEE hosten, um Dienste nach außen anzubieten.
4. Benutzer können mit vordefinierten Benutzeroberflächen mit Anwendungen interagieren.

Offensichtlich gibt es hier drei potenzielle Risiken:

• Entwickler: Was ist der Zweck des Codes zur Vorbereitung von EIF? Der EIF-Code entspricht möglicherweise nicht der Geschäftslogik, die das Projektteam nach außen hin bewirbt, und könnte Benutzerdaten stehlen.
• Server: Läuft der TEE-Server mit der erwarteten EIF-Datei? Oder wird die EIF tatsächlich im TEE ausgeführt? Der Server könnte auch andere Programme im TEE ausführen.
• Lieferant: Ist das Design von TEE sicher? Gibt es Hintertüren, die alle Daten im TEE an den Lieferanten weitergeben?

Glücklicherweise gibt es jetzt Lösungen für die oben genannten Risiken in TEE, nämlich reproduzierbare Builds(Reproducible Builds) und Remote-Attestationen(Remote Atteststations).

Was ist also Replizierbarkeit? Moderne Softwareentwicklung erfordert oft den Import von vielen Abhängigkeiten wie externen Tools, Bibliotheken oder Frameworks. Diese Abhängigkeitsdateien können auch Sicherheitsrisiken aufweisen. Lösungen wie npm verwenden jetzt den Code-Hash der Abhängigkeitsdateien als eindeutigen Identifikator. Wenn npm feststellt, dass eine Abhängigkeitsdatei nicht mit dem aufgezeichneten Hash-Wert übereinstimmt, kann davon ausgegangen werden, dass die Datei geändert wurde.

Wiederholbare Builds können als eine Gruppe von Standards angesehen werden, deren Ziel es ist, dass bei der Ausführung von beliebigem Code auf beliebigen Geräten nur dann einheitliche Hash-Werte erzeugt werden, wenn der Build gemäß den zuvor festgelegten Prozessen durchgeführt wird. Natürlich können wir in der Praxis auch Produkte außerhalb des Hash als Identifikatoren verwenden, die wir hier als Code-Messung ( bezeichnen.

Nix ist ein gängiges Tool für wiederholbare Builds. Wenn der Quellcode des Programms offengelegt wird, kann jeder den Code überprüfen, um sicherzustellen, dass der Entwickler nichts Ungewöhnliches eingefügt hat, und jeder kann den Code mit Nix erstellen, um zu überprüfen, ob das erstellte Produkt die gleichen Codemetriken/Hash aufweist wie das Produkt, das vom Projektteam in der Produktion bereitgestellt wird. Aber woher kennen wir die Code-Metriken für ein Programm im TEE? Dies bringt uns zu dem Konzept, das als “Remote Proof” bezeichnet wird. **

![])https://img.gateio.im/social/moments-de22e99c8194fa04f29ee5416aebcd03(

Remote Attestation ist eine signierte Nachricht von der TEE-Plattform (vertrauenswürdige Entität), die Informationen wie Code-Metriken und TEE-Plattformversionen enthält. Die Remote Attestation informiert externe Beobachter darüber, dass ein Programm in einer sicheren Umgebung (mit der tatsächlichen TEE-Version xx) ausgeführt wird, auf die niemand zugreifen kann.

![])https://img.gateio.im/social/moments-e4900d340dd1c812355c38739632d2a6(

Durch die Möglichkeit des wiederholten Aufbaus und des Remote-Proofs kann jeder Benutzer den tatsächlichen Code, der in TEE ausgeführt wird, und Informationen zur TEE-Plattformversion kennen, um Entwickler oder Server-Missbrauch zu verhindern.

Aber in dem Fall von TEE ist es immer notwendig, dem Lieferanten zu vertrauen. Wenn der TEE-Lieferant betrügt, kann er direkt Remote-Beweise fälschen. Wenn also der Lieferant als potenzielles Angriffsmedium betrachtet wird, sollte man sich nicht nur auf TEE verlassen, sondern es ist am besten, sie mit ZK oder Konsensprotokollen zu kombinieren.

Die Faszination von TEE

Aus unserer Sicht sind die TEE-Funktionen besonders beliebt, insbesondere für die Bereitstellung von AI-Agenten, aufgrund der folgenden Aspekte:

• Leistung: TEE kann das LLM-Modell ausführen und hat eine ähnliche Leistung und Kosteneffizienz wie herkömmliche Server. **ZkML hingegen erfordert eine erhebliche Rechenleistung zur Generierung des zk-Beweises für LLM.
• GPU-Unterstützung: NVIDIA bietet in seiner neuesten GPU-Serie (Hopper, Blackwell, etc.) TEE-Berechnungsunterstützung
• Richtigkeit: LLMs sind nichtdeterministisch; bei mehrfacher Eingabe desselben Stichworts ergeben sich unterschiedliche Ergebnisse. Daher können mehrere Knoten (einschließlich Beobachter, die versuchen, einen Betrugsnachweis zu erstellen) möglicherweise niemals zu einer Einigung über das Betriebsergebnis des LLMs gelangen. In einem solchen Szenario können wir jedoch darauf vertrauen, dass das in der TEE ausgeführte LLM nicht von böswilligen Akteuren manipuliert werden kann. Das Programm in der TEE wird immer so ausgeführt, wie es geschrieben wurde, was die TEE besser geeignet macht, die Zuverlässigkeit der LLM-Schlussfolgerungsergebnisse zu gewährleisten als opML oder Konsens.
• Vertraulichkeit: Die Daten in TEE sind für externe Programme nicht sichtbar. Daher sind die in TEE generierten oder empfangenen privaten Schlüssel immer sicher. Diese Funktion kann verwendet werden, um dem Benutzer zu versichern, dass alle mit diesem Schlüssel signierten Nachrichten von internen Programmen in TEE stammen. Benutzer können sicher sein, ihre privaten Schlüssel an TEE zu übergeben und einige Signaturbedingungen festzulegen und die Signatur von TEE gemäß den vordefinierten Signaturbedingungen zu bestätigen
• Vernetzung: Durch einige Werkzeuge kann das in TEE ausgeführte Programm sicher auf das Internet zugreifen (ohne Abfrage oder Antwort an den Server, auf dem TEE ausgeführt wird, offen zu legen und gleichzeitig Dritten die Gewährleistung der korrekten Datenabfrage zu bieten). Dies ist sehr nützlich für die Abfrage von Informationen von Drittanbieter-APIs und kann verwendet werden, um die Berechnung an vertrauenswürdige, aber proprietäre Modellanbieter auszulagern.
• Schreibberechtigung: Im Gegensatz zum zk-Plan kann der Code, der in TEE ausgeführt wird, Nachrichten (sowohl Tweets als auch Transaktionen) erstellen und sie über API- und RPC-Netzwerke senden.
• Entwicklerfreundlich: Rahmen und SDKs im Zusammenhang mit TEE ermöglichen es den Menschen, Code in jeder Sprache zu schreiben und Programme wie in einem Cloud-Server problemlos in TEE bereitzustellen.

Gute oder schlechte, es ist derzeit schwer, alternative Lösungen für viele Anwendungsfälle von TEE zu finden. Wir glauben, dass die Einführung von TEE den Entwicklungsraum für On-Chain-Anwendungen weiter ausdehnt und möglicherweise neue Anwendungsszenarien fördert.

TEE is not a silver bullet

Programme, die in TEE ausgeführt werden, sind immer noch anfällig für eine Reihe von Angriffen und Fehlern. Genau wie Smart Contracts sind sie anfällig für eine Reihe von Problemen. Zur Vereinfachung gliedern wir mögliche Schwachstellen wie folgt ein:

• Entwickler vernachlässigt
• Laufzeitfehler
• Architekturdesignfehler
• Betriebsprobleme

Entwickler-Fehler

Ob absichtlich oder unbeabsichtigt, Entwickler können die Sicherheitsgarantien von TEE-Programmen durch absichtlichen oder unbeabsichtigten Code schwächen. Dazu gehören:

• Opaker Code: Das Sicherheitsmodell von TEE basiert auf externer Verifizierbarkeit. Die Transparenz des Codes ist für die Verifikation durch externe Dritte von entscheidender Bedeutung.
• Probleme bei der Code-Messung: Selbst wenn der Code öffentlich ist, müssen Dritte den Code neu aufbauen und die Code-Messwerte in der Remote-Attestation überprüfen und anhand der bereitgestellten Code-Messwerte in der Remote-Attestation überprüfen. Dies ist ähnlich wie der Empfang eines zk-Beweises, aber ohne dessen Überprüfung.
• Unsicherer Code: Selbst wenn Sie sorgfältig Schlüssel in TEE generieren und verwalten, kann die Logik des Codes Ihre TEE-Schlüssel während des Aufrufs von Außenstehenden offenlegen. Darüber hinaus kann der Code Backdoors oder Schwachstellen enthalten. Im Vergleich zur herkömmlichen Backend-Entwicklung erfordert dies einen Softwareentwicklungs- und Auditierungsprozess mit hohen Standards, ähnlich der Entwicklung von Smart Contracts.
• Supply-Chain-Angriffe: Die moderne Softwareentwicklung verwendet eine große Menge an Drittanbietercode. Supply-Chain-Angriffe stellen eine erhebliche Bedrohung für die Integrität von TEE dar.

Laufzeitfehler

Selbst vorsichtige Entwickler können Opfer von Laufzeitfehlern werden. Entwickler müssen sorgfältig prüfen, ob eine der folgenden Optionen die Sicherheitsgarantien ihres Projekts beeinträchtigt:

• Dynamischer Code: Es ist möglicherweise nicht immer möglich, alle Codes transparent zu halten. Manchmal muss das Anwendungsbeispiel selbst undurchsichtigen Code dynamisch zur Laufzeit in die TEE laden. Solcher Code kann leicht vertrauliche Informationen preisgeben oder die Unveränderlichkeit beeinträchtigen, daher muss dieser Fall äußerst sorgfältig vermieden werden.
• Dynamische Daten: Die meisten Anwendungen verwenden während ihrer Ausführung externe APIs und andere Datenquellen. Das Sicherheitsmodell erweitert sich auf diese Datenquellen, die sich auf derselben Ebene wie Oracles in DeFi befinden. Falsche oder veraltete Daten können zu Katastrophen führen. Zum Beispiel kann eine übermäßige Abhängigkeit von LLM-Diensten wie Claude im Anwendungsfall von AI-Agenten dazu führen.
• Unsichere und instabile Kommunikation: TEE muss auf einem Server mit TEE-Komponenten ausgeführt werden. Aus Sicherheitsgründen ist der Server, auf dem TEE ausgeführt wird, tatsächlich der perfekte Mittelsmann (MitM) zwischen TEE und externer Interaktion. Der Server kann nicht nur die Verbindung von TEE nach außen ausspionieren und den Inhalt sehen, der gesendet wird, sondern er kann auch bestimmte IP-Adressen überprüfen, Verbindungen einschränken und Datenpakete in Verbindungen einspritzen, die darauf abzielen, eine Partei zu täuschen, damit diese denkt, dass sie von xx stammen.

Zum Beispiel kann ein Matching-Engine, der in TEE läuft und verschlüsselte Transaktionen verarbeitet, keine faire Bestellgarantie (MEV-Resistenz) bieten, da der Router/Gateways/Host immer noch Pakete basierend auf der IP-Adresse des Absenders verwerfen, verzögern oder priorisieren kann.

Architekturfehler

Die Technologie-Stacks, die von TEE-Anwendungen verwendet werden, sollten sorgfältig betrachtet werden. Bei der Entwicklung von TEE-Anwendungen können folgende Probleme auftreten:

• Anwendungen mit einem großen Angriffsfläche: Die Angriffsfläche einer Anwendung bezieht sich auf die Anzahl der Code-Module, für die vollständige Sicherheit gewährleistet werden muss. Code mit einer großen Angriffsfläche ist äußerst schwer zu überprüfen und kann versteckte Fehler oder ausnutzbare Schwachstellen enthalten. Dies steht in der Regel im Widerspruch zur Erfahrung der Entwickler. Zum Beispiel hat eine TEE-Anwendung, die Docker nicht benötigt, im Vergleich zu einer TEE-Anwendung, die Docker benötigt, eine viel größere Angriffsfläche. Im Vergleich zu TEE-Anwendungen, die das leichteste Betriebssystem verwenden, haben Enclaves, die auf einem ausgereiften Betriebssystem basieren, eine größere Angriffsfläche.
• Portabilität und Aktivität: In Web3 müssen Anwendungen gegen Zensur resistent sein. Jeder kann eine TEE starten und inaktive Systemteilnehmer übernehmen und die Anwendungen innerhalb der TEE portabel machen. Die größte Herausforderung liegt hierbei in der Portabilität der Schlüssel. Einige TEE-Systeme haben Schlüsselableitungsmechanismen, aber sobald der Schlüsselableitungsmechanismus innerhalb der TEE verwendet wird, können andere Server keine Schlüssel innerhalb externer TEE-Programme lokal generieren. Dadurch sind TEE-Programme normalerweise auf die gleiche Maschine beschränkt, was nicht ausreichend für die Portabilität ist.
• Unsicherer Vertrauensanker beispielsweise bei der Ausführung eines AI-Agenten im TEE, wie kann die Zugehörigkeit einer bestimmten Adresse zu diesem Agenten überprüft werden? Eine mangelhafte Konzeption in diesem Bereich könnte dazu führen, dass der tatsächliche Vertrauensanker möglicherweise eine externe Drittpartei oder eine Schlüsselverwaltungsplattform ist, anstatt der TEE selbst.

Betriebsproblem

Ein weiterer, aber nicht weniger wichtiger Punkt ist, dass es einige praktische Überlegungen gibt, wie man einen Server betreibt, der ein TEE-Programm tatsächlich ausführt:

• Unsichere Plattformversion: Die TEE-Plattform erhält gelegentlich Sicherheitsupdates, die in Form von Plattformversionen im Remote-Attestation-Protokoll reflektiert werden. Wenn Ihre TEE nicht auf einer sicheren Plattformversion läuft, können Hacker bekannte Angriffsvektoren nutzen, um Schlüssel aus der TEE zu stehlen. Noch schlimmer ist, dass Ihre TEE heute auf einer sicheren Plattformversion laufen kann, aber morgen unsicher sein könnte.
• Keine physische Sicherheit: Trotz Ihrer besten Bemühungen könnte TEE anfällig für Seitenkanalangriffe sein, die normalerweise physischen Zugriff und Kontrolle auf den Server, auf dem TEE läuft, erfordern. Daher ist physische Sicherheit eine wichtige Schutzschicht. Ein verwandtes Konzept ist der Cloud-Proof, bei dem Sie nachweisen können, dass TEE in einem Cloud-Rechenzentrum läuft und diese Cloud-Plattform physische Sicherheitsgarantien bietet.

Erstellen Sie sichere TEE-Programme

Wir teilen unsere Vorschläge wie folgt auf:

• Die sicherste Lösung
• Erforderliche Vorsichtsmaßnahmen ergreifen
• Abhängig von den Anwendungsfällen vorgeschlagen

1. Sicherste Option: Keine externen Abhängigkeiten

Das Erstellen von hochsicheren Anwendungen kann das Eliminieren von externen Abhängigkeiten wie externen Eingaben, APIs oder Diensten umfassen, um die Angriffsfläche zu reduzieren. Diese Methode gewährleistet, dass die Anwendung unabhängig betrieben wird und keine externen Interaktionen vorliegen, die ihre Integrität oder Sicherheit beeinträchtigen könnten. Obwohl diese Strategie die Vielfalt der Funktionen der Anwendung einschränken kann, bietet sie ein hohes Maß an Sicherheit.

Wenn das Modell lokal ausgeführt wird, kann für die meisten CryptoxAI-Anwendungsfälle dieses Sicherheitsniveau erreicht werden.

2. Erforderliche Vorsichtsmaßnahmen

Egal ob die Anwendung externe Abhängigkeiten hat oder nicht, folgende Inhalte sind erforderlich!

Betrachten Sie die TEE-Anwendung als Smart Contract, nicht als Backend-Anwendung; halten Sie die Aktualisierungsfrequenz niedrig und führen Sie strenge Tests durch.

Das Erstellen von TEE-Programmen sollte genauso sorgfältig sein wie das Schreiben, Testen und Aktualisieren von Smart Contracts. Ähnlich wie Smart Contracts läuft TEE in einer hochsensiblen und unveränderlichen Umgebung, in der Fehler oder unerwartetes Verhalten schwerwiegende Folgen haben können, einschließlich des vollständigen Verlusts von Geldern. Eine gründliche Prüfung, umfangreiche Tests und minimale, sorgfältig geprüfte Aktualisierungen sind entscheidend, um die Integrität und Zuverlässigkeit von TEE-basierten Anwendungen zu gewährleisten.

Auditieren Sie den Code und überprüfen Sie die Build-Pipeline

Die Sicherheit einer Anwendung hängt nicht nur vom Code selbst ab, sondern auch von den während des Build-Prozesses verwendeten Tools. Ein sicherer Build-Pipeline ist entscheidend, um Schwachstellen zu verhindern. TEE garantiert lediglich, dass der bereitgestellte Code gemäß dem erwarteten Ablauf ausgeführt wird, kann jedoch Mängel, die während des Build-Prozesses eingeführt wurden, nicht beheben.

Um das Risiko zu minimieren, muss der Code streng getestet und überprüft werden, um Fehler zu beseitigen und unnötige Informationslecks zu verhindern. Darüber hinaus spielt die reproduzierbare Erstellung eine entscheidende Rolle, insbesondere wenn der Code von einer Partei entwickelt und von einer anderen Partei verwendet wird. Die reproduzierbare Erstellung ermöglicht es jedem, zu überprüfen, ob das in TEE ausgeführte Programm mit dem ursprünglichen Quellcode übereinstimmt, um Transparenz und Vertrauen zu gewährleisten. Ohne die reproduzierbare Erstellung ist es nahezu unmöglich, den genauen Inhalt des in TEE ausgeführten Programms zu bestimmen, was die Sicherheit der Anwendung gefährdet.

Beispielsweise ist der Quellcode von DeepWorm (ein Projekt, bei dem das Wurm-Gehirn-Simulationsmodell in TEE ausgeführt wird) vollständig offen. Die Ausführung des Programms in TEE erfolgt auf eine reproduzierbare Weise mit Hilfe von Nix-Pipelines.

Verwendung von auditierten oder überprüften Bibliotheken

Bei der Verarbeitung sensibler Daten in TEE-Programmen verwenden Sie bitte nur geprüfte Bibliotheken für das Schlüsselmanagement und die Verarbeitung privater Daten. Nicht geprüfte Bibliotheken können Schlüssel offenzulegen und die Sicherheit der Anwendung beeinträchtigen. Priorisieren Sie sicherheitszentrierte Abhängigkeiten, die gründlich geprüft wurden, um die Vertraulichkeit und Integrität der Daten zu gewährleisten.

Immer die Bestätigung des Nachweises von TEE überprüfen

Benutzer, die mit TEE interagieren, müssen die von TEE generierten Remote-Proofs oder -Verifikationsmechanismen überprüfen, um eine sichere und vertrauenswürdige Interaktion zu gewährleisten. Ohne diese Überprüfungen kann der Server die Antwort manipulieren, und es ist nicht möglich, echte TEE-Ausgaben von manipulierten Daten zu unterscheiden. Remote-Proofs bieten einen wichtigen Nachweis für die Codebibliothek und Konfigurationen, die in TEE ausgeführt werden, damit wir beurteilen können, ob die in TEE ausgeführten Programme den Erwartungen entsprechen.

Die spezifische Zertifizierung kann entweder on-chain (IntelSGX, AWSNitro) verifiziert werden, indem ZK-Beweise (IntelSGX, AWSNitro) off-chain verwendet werden, oder sie kann vom Benutzer selbst oder von einem gehosteten Dienst (wie t16z oder MarlinHub) verifiziert werden.

3. Empfehlungen basierend auf Use Cases

Basierend auf den Anwendungsfall und deren Struktur können die folgenden Hinweise dazu beitragen, Ihre Anwendung sicherer zu machen.

Stellen Sie sicher, dass die Interaktion zwischen Benutzern und TEE immer über einen sicheren Kanal erfolgt

Der Server, auf dem TEE ausgeführt wird, ist im Wesentlichen nicht vertrauenswürdig. Der Server kann die Kommunikation abfangen und ändern. In einigen Fällen ist es akzeptabel, dass der Server Daten lesen, aber nicht ändern kann, während es in anderen Fällen selbst das Lesen von Daten nicht wünschenswert ist. Um diese Risiken zu minimieren, ist es wichtig, einen sicheren end-to-end verschlüsselten Kanal zwischen dem Benutzer und TEE aufzubauen. Stellen Sie sicher, dass die Nachricht zumindest eine Signatur enthält, um ihre Echtheit und Herkunft zu überprüfen. Darüber hinaus muss der Benutzer immer die Remote-Attestation des TEE überprüfen, um sicherzustellen, dass er mit dem richtigen TEE kommuniziert. Dies gewährleistet die Integrität und Vertraulichkeit der Kommunikation.

Oyster kann beispielsweise durch Verwendung von CAA-Einträgen und RFC8657 eine sichere TLS-Ausstellung unterstützen. Darüber hinaus bietet es ein TEE-natives TLS-Protokoll namens Scallop, das nicht von WebPKI abhängt.

Wissen, dass der TEE-Speicher transient ist

TEE-Speicher ist flüchtig, was bedeutet, dass der Inhalt (einschließlich der verschlüsselten Schlüssel) verloren geht, wenn das TEE geschlossen wird. Ohne einen sicheren Mechanismus zur Speicherung dieser Informationen können wichtige Daten dauerhaft unzugänglich werden, was zu finanziellen oder betrieblichen Schwierigkeiten führen kann.

**Multifaktor-Berechnungsnetzwerke (MPC) mit dezentralen Speichersystemen wie IPFS können als Lösung für dieses Problem dienen. Das MPC-Netzwerk teilt den Schlüssel auf mehrere Knoten auf, um sicherzustellen, dass kein einzelner Knoten den vollständigen Schlüssel besitzt, und ermöglicht es dem Netzwerk gleichzeitig, den Schlüssel bei Bedarf wiederherzustellen. Die mit diesem Schlüssel verschlüsselten Daten können sicher auf IPFS gespeichert werden.

Wenn nötig, kann das MPC-Netzwerk einem neuen TEE-Server, der das gleiche Image ausführt, Schlüssel zur Verfügung stellen, vorausgesetzt, bestimmte Bedingungen sind erfüllt. Diese Methode gewährleistet Flexibilität und starke Sicherheit, sodass Daten auch in einer nicht vertrauenswürdigen Umgebung zugänglich und vertraulich bleiben.

![])https://img.gateio.im/social/moments-429ced8c56f3dff6c933327cf8963516(

Es gibt eine andere Lösung, bei der TEE die entsprechenden Transaktionen jeweils verschiedenen MPC-Servern übergibt, die Transaktionen signieren und dann die aggregierte Signatur auf die Kette bringen. Diese Methode ist viel weniger flexibel und kann nicht zur Speicherung von API-Schlüsseln, Passwörtern oder beliebigen Daten (ohne vertrauenswürdigen Drittanbieter-Speicherdienst) verwendet werden.

![])https://img.gateio.im/social/moments-37203038abc830a2f70f702c7eeb0e7b(

Reduzierung der Angriffsfläche

Für sicherheitskritische Anwendungsfälle lohnt es sich, die Entwicklererfahrung zu opfern, um die Abhängigkeiten so weit wie möglich zu reduzieren. Zum Beispiel wird Dstack mit einem auf Yocto basierenden minimalen Kernel geliefert, der nur die Module enthält, die für das Funktionieren von Dstack erforderlich sind. Es könnte sogar lohnenswert sein, veraltete Technologien wie SGX (über TDX hinaus) zu verwenden, da diese Technologien keinen Bootloader oder ein Betriebssystem benötigen, um Teil eines TEE zu sein.

Physische Trennung

Durch die physische Isolierung von TEE vor möglichen menschlichen Eingriffen kann die Sicherheit von TEE weiter verbessert werden. Obwohl wir glauben, dass Data Center physische Sicherheit bieten können, indem wir TEE-Server in Data Centern und Cloud-Providern hosten, erkundet Projekte wie Spacecoin eine ziemlich interessante Alternative - den Weltraum. Das SpaceTEE-Papier stützt sich auf Sicherheitsmaßnahmen wie die Messung des Trägheitsmoments nach dem Start, um zu überprüfen, ob der Satellit während des Eintritts in die Umlaufbahn von der erwarteten Bahn abweicht.

Mehrere Beweiser

Ähnlich wie Ethereum auf mehrere Client-Implementierungen angewiesen ist, um das Risiko von Netzwerkfehlern zu verringern, verwenden multiprovers verschiedene TEE-Implementierungsschemata, um die Sicherheit und Flexibilität zu erhöhen. Durch die Ausführung desselben Berechnungsschritts auf mehreren TEE-Plattformen gewährleistet die Multi-Validation, dass ein Fehler in einer TEE-Implementierung die gesamte Anwendung nicht gefährdet. Obwohl dieser Ansatz erfordert, dass der Berechnungsprozess deterministisch ist oder in nicht deterministischen Fällen Konsens zwischen verschiedenen TEE-Implementierungsschemata definiert ist, bietet er signifikante Vorteile wie Fehlerisolierung, Redundanz und Cross-Validation, was ihn zu einer guten Wahl für Anwendungen macht, die Zuverlässigkeit erfordern.

![])https://img.gateio.im/social/moments-da3100eaa6119891428bb2346de3f57e(

Blick in die Zukunft

TEE hat sich zweifellos zu einem äußerst aufregenden Bereich entwickelt. Wie bereits erwähnt, ist KI allgegenwärtig und der kontinuierliche Zugriff auf sensible Benutzerdaten bedeutet, dass große Technologieunternehmen wie Apple und NVIDIA TEE in ihren Produkten verwenden und TEE als integralen Bestandteil ihrer Produkte anbieten.

Auf der anderen Seite hat die Krypto-Community immer großen Wert auf Sicherheit gelegt. Mit Entwicklern, die versuchen, Anwendungen und Anwendungsfälle auf der Chain zu erweitern, haben wir gesehen, dass TEE als eine Lösung, die ein angemessenes Gleichgewicht zwischen Funktionalität und Vertrauensannahmen bietet, populär geworden ist. Obwohl TEE nicht so vertrauensminimierend ist wie eine vollständige ZK-Lösung, erwarten wir, dass TEE allmählich zu einem Weg wird, um Web3-Unternehmen und Produkte großer Technologieunternehmen zu integrieren.