Täglich erzeugen Menschen bis zu 402 Millionen TB sensibler Daten. Da Einzelpersonen immer weniger bereit sind, Daten umfassend zu teilen, wächst der Bedarf an privatem Rechnen mit diesen Daten stetig. Diese Lösungen basieren hauptsächlich auf der Infrastruktur von Amazon Web Services (AWS), die etwa 30% des globalen Cloud-Computing-Marktes ausmacht.
Allerdings weist AWS mehrere Nachteile auf, die hauptsächlich auf seine zentralisierte Architektur zurückzuführen sind. Selbst mit der Einführung von AWS Nitro Enclaves, die eine verbesserte sichere Berechnung bieten, stehen Entwickler weiterhin vor erheblichen Herausforderungen, die zudem tiefgreifende Hindernisse für die Sicherheit von Blockchain und Web3-Anwendungen darstellen.
Dieser Artikel wird den aktuellen Stand von AWS analysieren und eine dezentrale TEE-Cloud-Lösung vorstellen, die nicht nur die Mängel von AWS behebt, sondern auch die Einschränkungen bestehender TEE-Lösungen überwindet. Zuvor müssen wir jedoch untersuchen, warum AWS und sein Nitro Enclaves-Produkt so hohe Bekanntheit und Marktanteile erlangt haben und welche Probleme hinter diesen Fortschritten bestehen.
AWS Nitro und TEE
AWS ist derzeit die beliebteste Cloud-Computing-Plattform und bietet eine Reihe von umfangreichen Tools. Kurz gesagt, AWS ist im Wesentlichen die Cloud-Infrastruktur, die alle Rechenbedürfnisse von Entwicklern erfüllt, einschließlich Rechenleistung, Speicher und Datenbankdienste. Es ist bekannt, dass AWS etwa 30 % des Marktes für Cloud-Infrastruktur einnimmt, was einen erheblichen Anteil darstellt. Unter Software-Ingenieuren oder Entwicklern verwenden fast 48 % AWS in irgendeiner Form, sodass die Nachfrage enorm ist.
Mit der wachsenden Nachfrage und dem wachsenden Kundenstamm, einschließlich großer Finanzinstitute, Regierungsbehörden und Start-ups mit hochsensiblen Daten, werden Fragen zur Sicherheit von AWS und der Fähigkeit dieser Unternehmen aufgeworfen, diese Daten sicher zu speichern und für vertrauliches Computing zu verwenden.
In diesem Kontext entstand die Idee bei AWS, TEE auf seiner Plattform zu implementieren, um die Daten im Einsatz zu schützen und die Verschlüsselung von ruhenden und übertragenen Daten zu ergänzen.
Diese neue Lösung mit integriertem TEE wird als AWS Nitro Enclaves bezeichnet und bietet eine hardwaregestützte isolierte Ausführungsumgebung. TEE schafft eine sichere Umgebung innerhalb von Amazon EC2-Instanzen und beseitigt interaktiven Zugriff, persistenten Speicher und externe Netzwerkverbindungen. Diese Isolierung minimiert die Angriffsfläche, indem sie sensible Workloads von der übergeordneten EC2-Instanz, deren Betreibern und anderer Software trennt.
Allerdings werden Nitro Enclaves vollständig innerhalb des EC2-Dienstes von AWS erstellt und verwaltet und gehören zu einem hochgradig zentralisierten Rahmen. Von der Erstellung bis zur Beendigung werden alle Aspekte des Enclave-Managements von der Infrastruktur von AWS kontrolliert, was angesichts der Natur von AWS als zentralisiertem Cloud-Anbieter im Wesentlichen zentralisiert ist.
Kurz gesagt bietet AWS Nitro Enclaves durch eine hardwarebasierte vertrauenswürdige Ausführungsumgebung starke Isolation, um sensible Workloads zu schützen. Dennoch bringt seine zentralisierte Architektur bestimmte Einschränkungen und Abwägungen mit sich.
Einschränkungen außerhalb der AWS-Zentralisierung
Neben der Zentralisierung, bei der alle Komponenten und Daten auf ein einziges System angewiesen sind, bringt AWS Nitro Enclaves zusätzliche Herausforderungen und neue Sicherheitsüberlegungen mit sich. AWS verbindet mehrere Nitro-Karten (benutzerdefinierte Hardware) mit der CPU, um die TEE-Nutzlast auszuführen, was ein doppeltes Sicherheitsrisiko darstellt: Schwachstellen können sowohl in der zugrunde liegenden CPU als auch auf der Nitro-Karte auftreten.
Ein erhebliches Problem von Nitro Enclaves ist das Fehlen eines umfassenden Speicherverschlüsselungsmechanismus. Im Gegensatz zu Lösungen, bei denen die Speicherverschlüsselung direkt in die CPU integriert ist, macht die externe Natur der Nitro-Karte es schwierig, eine End-to-End-Verschlüsselung der Daten im Speicher zu gewährleisten. Diese Konfiguration könnte sensible Informationen während des Speicherzugriffs für Manipulationen offenlegen, da die Verschlüsselung von der Interaktion zwischen der CPU und externen Geräten abhängt.
Darüber hinaus müssen Entwickler weiterhin Docker verwenden, um Amazon Machine Images (AMIs) zu erstellen und zu konfigurieren, die die Enclave-Software enthalten, was für Personen, die mit der Containerisierung nicht vertraut sind, schwierig sein kann. Sie müssen auch die AWS CLI und die Nitro Enclaves CLI verwenden, um Instances zu starten und Enclaves zu verwalten, in der Nitro Enclaves API zu navigieren und in AWS-Schlüsselverwaltungsservices zu integrieren, was manchmal ein Verständnis des kryptografischen Nachweisprozesses erfordert.
Die Abhängigkeit von TEE vom Nitro-Chip führt zu nicht überprüfbaren Beweisen, da die Messung der Code-Integrität vom Nitro-Chip und nicht von der CPU selbst stammt.
AWS vertraut Entwicklern und Administratoren, Identitäts- und Zugriffsverwaltungsrichtlinien einzurichten, was ihnen möglicherweise den Zugriff auf sensible Daten ermöglicht. Ihre erweiterten Berechtigungen stellen ein internes Bedrohungsrisiko dar, da sie Daten einsehen oder manipulieren könnten.
Überprüfung der Vertrauensannahme von AWS Nitro
Die größte Einschränkung besteht jedoch darin, dass AWS nicht für dezentrale Anwendungen und Ökosysteme optimiert ist und es an nativer Unterstützung für Web3-Anwendungsfälle oder Governance-Systeme fehlt.
Zum Beispiel fehlt AWS Nitro Enclaves der persistente Speicher. Obwohl diese Isolation für die Sicherheit von Vorteil ist, schränkt sie Anwendungsfälle ein, bei denen ein KI-Agent Benutzerdaten in einer Vektordatenbank speichern muss.
Auch die Schlüsselverwaltung passt nicht in das “Zero Trust”-Szenario. AWS Key Management Service (KMS) ist zwar verfügbar, aber für Web2 konzipiert und ermöglicht Administratoren den Zugriff auf private Schlüssel. Dies steht im Widerspruch zu der Anforderung von Web3, dass Schlüssel vollständig codegesteuert sein müssen und niemandem, einschließlich Administratoren, zugänglich gemacht werden dürfen.
Nitro Enclaves löst das Misstrauen der Entwickler in die Cloud, aber Web3 erfordert vertrauenslose Lösungen zwischen Benutzern, Entwicklern und Anbietern. Sichere Code-Upgrades werden nicht unterstützt, erfordern dezentrales Eigentum, ähnlich wie bei der Smart Contract Governance, und Entwickler müssen von Grund auf neu erstellen, was Monate dauern kann, und wenn der Code nicht richtig implementiert wird, kann er anfällig sein.
Aufgrund des Mangels an Netzwerkzugang ist die Einrichtung von Webdiensten zeitaufwendig und mühsam, was die Entwickler zwingt, eine große Menge an Code zu schreiben, um die Anwendung anzupassen und die Sicherheit der Verschlüsselung zu gewährleisten, was oft nicht perfekt ist.
Warum benötigt Web3 TEE?
Wir verwenden TEE, weil wir Entwicklern oder Administratoren nicht vollständig vertrauen können. Web3-Teilnehmer haben unterschiedliche Philosophien und verfolgen vertrauenslose Systeme: Wenn man etwas vertrauen muss, sieht es nicht sehr zuverlässig aus. Aus diesem Grund verlassen sich Benutzer auf Hardware-Operatoren, um Anwendungen zu inspizieren und zu verwalten. Anwendungen können getrennt werden, um zu verhindern, dass sie während des Speicherzugriffs in sensible Daten eingreifen oder diese auskratzen oder ändern, da die Verschlüsselung auf einer reibungslosen Zusammenarbeit zwischen der CPU und externen Geräten beruht. Nutzer und Datenanbieter müssen über klare Garantien und Überprüfungen der mit ihren Daten durchgeführten Aktionen verfügen.
Bei der Entwicklung von Phala Network wurden wir darauf ausgelegt, die Vorteile von AWS mit der Sicherheit von TEE zu kombinieren, um die Komplexität durch Dezentralisierung zu beseitigen und gleichzeitig die Sicherheit zu erhöhen. Dieser Ansatz ist so konzipiert, dass er den Anforderungen von Web3-Anwendungsfällen gerecht wird. Als Ergebnis kamen wir auf das Konzept einer dezentralen TEE-Cloud, die Sicherheit und Integration für dezentrale Anwendungen bietet.
Dezentrale TEE-Cloud erstellen
Um das Konzept der dezentralen TEE-Cloud zu verstehen, muss zunächst definiert werden, was eine dezentrale Cloud ist. Was ist sie also?
Dezentrale Cloud ist eine Art von Recheninfrastruktur, bei der Datenspeicherung, -verarbeitung und -verwaltung über ein Netzwerk verteilt sind, das aus mehreren Knoten besteht, anstatt in einem einzigen zentralen Server oder Rechenzentrum konzentriert zu sein. Im Gegensatz zu traditionellen zentralisierten Cloud-Systemen wie AWS benötigt die dezentrale Cloud keine einzelne Kontrollinstanz, sondern basiert auf der Funktionsweise der Blockchain.
dezentrale TEE-Cloud
Dezentrale TEE-Cloud ist eine Art von Recheninfrastruktur, die TEE mit einem dezentralen Netzwerk von Knoten kombiniert, um sichere, private und überprüfbare Berechnungen bereitzustellen. Jeder Knoten ist mit TEE ausgestattet, um vertraulichen Code und Daten vor dem Zugriff oder der Manipulation durch Knotenbetreiber zu schützen.
Das Phala Network besteht aus einem dezentralen Netzwerk von Arbeitsknoten, von denen jeder mit einem TEE ausgestattet ist. Diese Knoten führen Berechnungsaufgaben für Benutzer basierend auf den Anforderungen der Kunden aus, wie z.B. das Ausführen von Smart Contracts oder das Verarbeiten sensibler Daten.
Der Prozess beginnt damit, dass der Benutzer seine Anwendung oder Aufgabe im Netzwerk bereitstellt. Die Berechnungsaufgaben werden innerhalb des TEE dieser Knoten ausgeführt, um sicherzustellen, dass Code und Daten vertraulich bleiben, selbst die Betreiber der Knoten können sie nicht einsehen oder manipulieren.
Phala verwendet kryptografische Beweise, um zu überprüfen, ob die Berechnungen innerhalb des TEE korrekt durchgeführt werden. Knotenbetreiber werden dafür belohnt, dass sie ehrliche und sichere Dienste erbringen und die Integrität des Netzes durch wirtschaftliche Anreize aufrechterhalten. Das hört sich zwar einfach an, aber die Implementierung dieser Lösung ist komplexer, als es scheint.
Warum ist es so schwierig, eine dezentralisierte TEE-Cloud zu erstellen?
TEE selbst ist weder zentralisiert noch dezentralisiert; der Grad der Zentralisierung hängt von der Implementierung und dem Einsatz innerhalb des Systems ab. TEE ist ein sicherer isolierter Bereich innerhalb des Prozessors, der darauf abzielt, sensible Codes und Daten vor unbefugtem Zugriff durch das Betriebssystem oder andere Prozesse auf demselben Gerät zu schützen. Ob TEE in einem zentralisierten oder dezentralisierten Modus betrieben wird, hängt von der Architektur des breiteren Systems ab, in dem es sich befindet.
In der Vergangenheit war die Schaffung eines zentralisierten Systems einfacher als die Erstellung eines dezentralen Systems, das in Bezug auf die Implementierung und die Kommunikation der Knoten vor Herausforderungen stand. Vor der Phala Cloud hatten wir erfolgreich das vollständig dezentrale Phala Network 1.0 (SGX) entwickelt. Phala Cloud wird jetzt mit der gleichen Philosophie entwickelt, auch wenn es einige Zeit dauern wird. Phala ist derzeit die einzige Plattform, die TEE mit vollständiger Dezentralisierung kombiniert, im Gegensatz zu zentralisierten Anbietern oder teilweise dezentralen Protokollen.
Die Vorteile von Dezentralisierung und TEE liegen auf der Hand, reichen aber in der Produktentwicklung noch nicht aus. Stellen Sie sich vor, Alibaba ist die weltweit größte E-Commerce-Plattform mit einem enormen Marktanteil. Wenn ein neues Produkt mit doppelter Leistung und niedrigerem Preis auf den Markt kommt, wird es dann den gesamten Markt erobern? Leider nein, denn die Menschen sind an bestehende Produkte gewöhnt und es gibt eine Voreingenommenheit gegenüber neuen Produkten, auch wenn sie besser sind.
Dies war eine der Herausforderungen, mit denen wir konfrontiert waren, aber anstatt doppelt so viele Verbesserungen anzustreben, stellten wir sicher, dass die Phala, die zehnmal besser war als die Konkurrenz, benutzerfreundlich war. Darüber hinaus ist AWS, wie bereits erwähnt, nicht für die Web3-Umgebung geeignet, und wir wollen diese Lücke für Web3-Anwendungen und -Entwickler schließen. Neben dem offensichtlichen Vorteil der Dezentralisierung möchten wir auch weitere Unterschiede zwischen Phala und AWS hervorheben.
Phala Cloud und AWS
Zunächst ist der Einrichtungsprozess von AWS für Nitro Enclaves komplex. Dies umfasst mehrere Schritte, einschließlich der Installation von Nitro CLI, der Umwandlung von Docker-Images in Enclave-Dateien und der Verarbeitung von Dateiübertragungen, die alle sehr zeitaufwendig sind.
Im Vergleich dazu ermöglicht Phala Entwicklern die “sofortige Migration und Anpassung” von Deployments und erleichtert die Migration bestehender Docker-Container in sichere TEEs. Mit dem Dstack SDK müssen Entwickler nur minimale Änderungen vornehmen, um Docker-Container in Confidential VMs (vertrauliche VMs) umzuwandeln und sie über die benutzerfreundliche Cloud-UI bereitzustellen, während Vorlagen und benutzerdefinierte Docker-Compose-Dateien weiterhin unterstützt werden.
Wenn es um Sicherheit geht, verlässt sich AWS darauf, Entwicklern und Administratoren zu vertrauen, wenn es darum geht, Zugriffskontrollen richtig zu konfigurieren und Ressourcen zu verwalten. Obwohl AWS TEE für isoliertes Computing verwendet, erfordert die zentralisierte Infrastruktur Personen, die AWS vertrauen und das System verwalten, was dazu führen kann, dass auf sensible Daten zugegriffen wird. Phala verwendet ein Zero-Trust-Modell und vertraut standardmäßig keiner Partei. Sensible Daten bleiben innerhalb des TEE sicher und sind selbst für Knotenbetreiber unzugänglich, wodurch sie für Web3-Anwendungen geeignet sind, die einen vertrauenslosen Betrieb erfordern.
Aus Produktsicht richtet sich AWS hauptsächlich an Unternehmenskunden, da die Anzahl der Unternehmen im traditionellen IT-Bereich sehr hoch ist. Daher entspricht es in Bezug auf Produkte und Technologie nicht vollständig dem Wertversprechen von Web3-Startups. Im Gegensatz dazu wurde Phala speziell für dezentrale Anwendungen entwickelt. Es unterstützt nativ KI-Agenten, die mit Blockchain-Smart-Contracts interagieren, sowie datenschutzorientierte DApps.
Darüber hinaus hat Phala durch Partnerschaften mit verschiedenen Protokollen und die Integration von DApps, die die Sicherheit von TEE nutzen möchten, tief in das Blockchain-Ökosystem eingetaucht.
Phala positioniert sich als Ausführungsschicht der Web3-KI und ermöglicht es Entwicklern, KI-Agenten zu erstellen, zu starten und zu monetarisieren, die Blockchain-Smart-Contracts sicher und privat verstehen und mit ihnen interagieren können. Wir unterstützen dezentrale KI-Plattformen wie NEAR AI und Sentient, indem wir NVIDIA GPU TEE nutzen, um große Sprachmodelle (LLMs) in einer sicheren, überprüfbaren und datenschutzorientierten Umgebung auszuführen. Unsere Partnerschaft mit NOTAI unterstreicht beispielsweise die Zero-Trust-Durchsetzung von KI-Agenten, bei denen wir durch TEE und RA Explorer Vertrauens- und Datenschutzschutz bieten.
Wir unterstützen auch die Integration von nicht KI-bezogenen Anwendungen durch Phat Contracts, dies sind kostengünstige, latenzarme Smart Contracts mit nativem HTTP-Anfragesupport.
Wie unterscheidet sich Phala jedoch von diesen Lösungen, angesichts der Tatsache, dass viele kryptonativen Teams ebenfalls TEE und andere sichere Berechnungsmethoden entwickeln?
Phala Cloud und TEE-Lösungen
Phala Network hebt sich als das einzige vollständig dezentralisierte TEE-Cloud hervor und bietet DApps sichere, private und überprüfbare Berechnungen. Im Gegensatz zu Oasis Protocol und Secret Network, die sich darauf konzentrieren, datenschutzfreundliche Smart Contracts in ihren jeweiligen Blockchains mithilfe von TEE zu implementieren, bietet Phala eine dezentrale Cloud-Computing-Plattform für Offline-Berechnungen über Netzwerke hinweg.
Phala ist flexibel und anpassbar und nutzt eine Vielzahl von TEE-Hardware, einschließlich Intel SGX, Intel TDX, AMD SEV und NVIDIA GPU TEE. Das Marlin-Protokoll verbessert die Netzwerkleistung von Web3, bietet jedoch keine Rechen- oder Datenschutzfunktionen, während Oasis und Secret in bestimmten Blockchain-Ökosystemen arbeiten. Phala hat als einzige dezentralisierte TEE-Cloud mit umfassender Hardwareunterstützung und Entwicklerwerkzeugen wie Dstack einen einzigartigen Vorteil.
Phala unterscheidet sich dadurch, dass es eine universelle, dezentrale TEE-Cloud bietet, im Gegensatz zu Oasis Protocol, Marlin und Secret Network, die sich auf bestimmte Anwendungsfälle konzentrieren. Phala ermöglicht es Entwicklern, jede Anwendung, wie z. B. ein KI-Modell, einen Webserver oder eine Datenbank, in einer sicheren Umgebung bereitzustellen. Möglich wird dies durch Phat Contracts und Phala Cloud, die Docker-Bereitstellungen unterstützen und mit einem Klick auf CPU- und GPU-TEE zugreifen können.
Darüber hinaus gibt es viele Vergleiche darüber, ob TEE oder Multi-Party-Computing (MPC) besser für bestimmte Anwendungsfälle geeignet ist. Unserer Meinung nach sind TEE und MPC keine Konkurrenten, sondern ergänzende Partner.
Phala integriert TEE mit MPC, um ein dezentrales Root of Trust (DeRoT)-Modell zu erstellen, einen fortschrittlichen Ansatz zur Sicherung von TEE-basierten Anwendungen. MPC arbeitet innerhalb des TEE, um das Risiko von Node-Kollusion zu verringern, während TEE-Blockproofs mit MPC-Proofs eingereicht werden, um Fehler in Zero-Knowledge-Proofs (ZKP)-Implementierungen zu mindern. Dieses System der Mehrfachbescheinigung wird durch die Anforderung an MPC-Knoten, innerhalb des TEE zu arbeiten, weiter verbessert. Das DeRoT-Modell verwendet TEE, MPC und ZKP, um die Vertrauensstellung im Netzwerk zu verteilen. Dieser Ansatz verbessert die Sicherheit von DApps mit TEEs, indem potenzielle Bedrohungen auf Hardware- oder Knotenebene adressiert werden.
Möglichkeiten der dezentralen TEE-Cloud
Wir werden einen speziellen Artikel schreiben, um dieses Thema zu erörtern, da bereits viele Anwendungen auf Phala laufen. Daher könnte dieser Abschnitt genauso lang sein wie der gesamte Artikel. Aber wir möchten die möglichen Anwendungsfälle der dezentralen TEE-Cloud umreißen.
Zunächst unterstützt Phala die Bereitstellung von KI-Modellen in TEE, um die Sicherheit und autonome Operationen bei der Interaktion mit dem Blockchain-Netzwerk zu gewährleisten. Dies umfasst KI-Agenten zur Verbesserung von Smart Contracts und zur Interaktion zwischen Agenten. Entwickler können GPU TEE für KI-Berechnungen nutzen, um echten Schutz vor Zensur und Datenschutz zu erreichen.
Entwickler können auch Legacy-Anwendungen in eine sichere und vertrauenswürdige Umgebung migrieren, um die Sicherheit zu verbessern. Die Plattform ermöglicht datenschutzfreundliche Datenanalysen durch Web3 und traditionelle Analysetools, die Daten analysieren können, ohne individuelle Benutzerinformationen preiszugeben. Darüber hinaus kann es die sicheren Berechnungen von DeFi mit Datenschutzfunktionen wie vertraulichen Handelspositionen oder Dark-Pool-Handel verbessern. Schließlich können dezentrale TEE-Clouds MEV-Schutz implementieren, indem sie Block-Builds in die TEE verschieben, um eine faire Reihenfolge und Ausführung zu gewährleisten.
Es gibt viele Produkte, die Phala als Teil ihrer Infrastruktur nutzen. In einem anderen Artikel werden wir genauer darauf eingehen, wie diese Produkte Phala verwenden und welche Vorteile sie aus dieser Integration ziehen.
Fazit
Es gibt grundlegende Unterschiede in den Vertrauensmodellen von Web3 und Web2, was zu Einschränkungen für Plattformen wie AWS führt. Im Web3 sind Daten, einschließlich Token, die im Wesentlichen Daten sind, wirklich im Besitz des Benutzers, und App-Entwickler sind standardmäßig nicht vertrauenswürdig. Dieses Misstrauen rührt von der Möglichkeit her, dass Entwickler versuchen könnten, ohne Genehmigung auf Benutzerdaten zuzugreifen, sie zu ändern oder zu stehlen.
Dieses Paradigma erklärt mehrere Schlüsselpraxis im Web3:
- Der Code von Smart Contracts muss einer strengen Überprüfung unterzogen werden, um Hintertüren oder Schwachstellen auszuschließen.
Das Eigentum (oder die Verwaltungskontrolle) von Smart Contracts ist ein Schlüsselproblem. Benutzer legen mehr Wert auf Transparenz als darauf, den Entwicklern uneingeschränkte Kontrolle zu gewähren.
- Im Idealfall sollten Entwickler im Web3-Umfeld Smart Contract-Code schreiben und bereitstellen und dann alle Kontrolle abgeben, ohne irgendwelche Privilegien über die Anwendung zu behalten.
Im Gegensatz zu Smart Contracts kann TEE ähnliche Prinzipien von Eigentum und Kontrolle in einem breiteren Programmbereich ausführen. AWS Nitro Enclaves laufen jedoch innerhalb des Web2-Rahmenwerks, in dem Entwickler die Fähigkeit behalten, Daten und Anwendungen zu anmelden, zuzugreifen und zu ändern. Das TEE von Phala ist nach den Prinzipien von Web3 entworfen und unterstützt nativ Smart Contracts zur Verwaltung von TEE-basierten Anwendungen, die mit dem dezentralen Vertrauensmodell übereinstimmen.
