Gemeinsam mit Felix Schuster spreche ich über Confidential Computing. Hallo und herzlich willkommen zu Ein Geek kommt selten allein, dem Podcast für mehr Konkretheit in der Digitalisierung. Mein Name ist Stephan und gemeinsam mit meinen Gästen mache ich eine Bestandsaufnahme, wohin uns die letzten 40 Jahre Digitalisierung in Deutschland gebracht haben. Und wie es von hier aus weitergehen kann. In dieser Folge spricht der Geek mit Felix Schuster. Ich bin Geschäftsführer und Gründer von Edgeless Systems, einem Cyber Security Unternehmen aus Bochum. Wie bist du dazu gekommen? Ich mache das schon sehr lange. Ich bin jetzt 38 Jahre alt, knapp 38. Und ich mache das schon seit, ich würde sagen, 25 Jahren. Also seit Teenagerjahren mache ich Cyber Security. Wie ist das damals schon so überhaupt? Also ich glaube, in Deutschland sagt man eh eher IT-Security oder IT-Sicherheit. Weil das dann Freaking mit so Rainbow-Boxen und so und so ist. Ich glaube, über so eine Ecke kommen viele Leute. Ich bin damals über die Spiele-Kopier-Szene da reingerutscht. Also bin ich natürlich nicht stolz drauf, aber kennt vielleicht jeder. Man hat früher auch mal ein Spiel gekopiert. So wie Tristan in The Red Sector. So ähnlich. Klar, irgendwer muss da den Kopierschutz umgehen und mit Kumpels aus dem Internet haben wir damals Kopierschützer uns angeschaut, haben die umgangen und so bin ich dann wie viele andere auch tatsächlich in der Cybersecurity oder IT-Security-Ecke gelandet. Der direkte Weg ist eigentlich üblicherweise von Kopierschutzanalysieren zu Virenanalysieren. Viren sind ein super heißes Thema immer noch, waren damals relevanter als heute. Und ja, viele von den Virenanalysten haben sich früher mit Kopierschutzmaßnahmen beschäftigt und die Technik niemals brauchte, um sich einen Kopierschutz anzuschauen und auszuhebeln. Sind sehr ähnlich zu den Techniken oder fast identisch, die man braucht, um sich ein Virus anzuschauen und entsprechend Signaturen zu schreiben und das zu verhindern. Und das ist so die Einflugschneise von mir gewesen, wie vielen anderen auch in die Cyber Security oder IT Security Szene. Ja, sehr spannend, sehr spannend. Ja, die alte Hexeditor-Zeit mit Signaturen gucken. Genau, genau. Hexeditor, Disassembler, das sind die Tools, die wir damals benutzt haben, die ich schon lange nicht mehr benutzt habe, aber die, wenn man jetzt zum Beispiel Beispiel in Bochum haben wir auch G-Data-Antivirus. Wenn man da die Analysten fragt, dann nutzen die die Tools, ja, Hexeditor, Disassembler, die man auch für Kopierschutz etc. Analyse damals benutzt hat. Kommen wir zum Thema des Tages. Der Begriff Confidential Computing begegnet einem immer wieder. Mir persönlich ist er jetzt ein paar Mal in letzter Zeit über den Weg gelaufen. Ich glaube, die wenigsten Leute können tatsächlich was damit anfangen. Die meisten erschließen sich das sehr wahrscheinlich darüber, dass sie sagen, ja gut, Confidential ist irgendwie vertraulich, Computing verstehe ich auch noch irgendwie. Aber dass das ein feststehender Begriff ist oder dass das ein Themenbereich ist, der langsam immer mehr im Kommen ist, korrigiere mich, wenn ich falsch bin, aber der ist, glaube ich, noch nicht so alt, Confidential Computing. Ja, der Begriff ist, würde ich sagen, relativ genau zehn Jahre alt. Ich weiß das gut, weil ich habe vor zehn Jahren ein Praktikum an Microsoft Research gemacht. Microsoft Research ist die Forschungsabteilung von Microsoft. Das war damals dann das Lab in Cambridge in England. Und da haben wir uns mit der Technologie beschäftigt, die man heute als Confidential Computing bezeichnet. Und wir haben damals ein Paper geschrieben, ein wissenschaftliches Papier, betitelt Verifiable Confidential Cloud Computing. Meines Wissens nach hat das Paper den Namen Confidential Computing geprägt. Aber du hast recht, ja, der Begriff ist mittlerweile nicht mehr ganz so nischig, wie er mal war. Und man begegnet ihm auch immer mehr eher im Mainstream-Bereich, zumindest was Cloud-Thema betrifft. Hat der nur mit Cloud zu tun? Also wenn wir über Confidential Computing sprechen, sind wir dann immer bei der Cloud auch oder ist Confidential Computing auch weiterzufassen, dass es auch um Dinge geht, die nicht in einem fremden Rechenzentrum stehen. Confidential Computing ist nicht beschränkt auf die Cloud tatsächlich. Ursprünglich ging es bei Confidential Computing auch eher um Consumer-Geräte und Edge-Devices. Und vielleicht einmal erklärt, was Confidential Computing macht. Dabei geht es darum, dass man Daten auch während der Verarbeitung verschlüsselt hält. Das wird möglich gemacht durch die Hardware, nämlich den Intel-Prozessor oder den AMD-Prozessor oder auch seit kurzem die NVIDIA-GPU. Da kann ich als Anwendung sagen, Prozessor, bitte verschlüssel mich jetzt und dann macht der Prozessor das, nimmt die Anwendung, packt die in einen besonders sicheren Ausführungskontext und hält dann Programmcode und Daten während der Ausführung verschlüsselt im Arbeitsspeicher. Die Daten und der Programmcode werden dann nicht verschlüsselt ausgeführt, das geht natürlich nicht. Der Prozessor entschlüsselt die Daten intern, seine internen Strukturen wieder während der Laufzeit. Aber das ist von außen nicht sichtbar. Die Klartextdaten sind nur während der Verarbeitung innerhalb des Prozessors vorliegend. Und von außen wirkt es so, als würde der Prozessor auf verschüsselten Daten arbeiten. Und der Hypervisor, das Betriebssystem, andere Hardwarekomponenten, für die sind die Daten nicht zugreifbar. Und wenn dann dort direkt auf dem Arbeitsspeicher zugegriffen wird, sieht man bloß verschüsselte Daten. Das einmal zur Technik. und du hast gefragt, ist es nur Cloud? Und ja, das Thema ist super spannend für die Cloud. Klar kann man sich vorstellen, wenn man Daten verschlüsselt halten kann während der Verarbeitung, hilft das viel mit Vertrauen in der Cloud. Aber ursprünglich war das Thema ein Endgerätethema. Die ersten Intel-Prozessoren, die das konnten, waren Consumer-Prozessoren, also eher die Low-Power-Celerons und so weiter. Und da war Intels Plan, dass man mit der Technologie besseren Kopierschutz lustigerweise, haben wir gerade schon drüber gesprochen, implementieren könnte und Leute daran hindern könnte, DVDs zu bringen. Also die ersten Anwendungen, die Confidential Computing verwendet haben, waren auf Low-Powered Intel-Prozessoren Decoder für DVDs. Ich erinnere mich, ich hatte irgend so ein Thinkpad und da war auch so ein Trusted Computing Module drin oder sowas. Wie spielen die damit rein? Das ist ja quasi dann so der Anfang gewesen, hardwaretechnisch zu überprüfen, dass nur bestimmte Dinge passieren auf dem Gerät. Ja, das ist interessant. Also das TPM ist ja schon schon lange bekannt, das Trusted-Platform-Module. Da gibt es viele Verbindungen zu Confidential Computing. Das TPM ist ein extra Chip auf deinem Mainboard. Das TPM kann Schlüssel speichern, kryptografische Schlüssel, und kann diese Schlüssel abhängig vom Zustand deines Systems freigeben oder nicht. Und was dann üblicherweise gemacht wird beim TPM ist. Ich starte meinen Laptop, das TPM hasht dann die Abfolge der Software, die geladen wird auf dem Laptop, also zuerst irgendeine Firmware, Dann der Bootloader, dann das Betriebssystem und dann vielleicht nochmal eine VM obendrauf. Diese Software wird gehasht, das nennt man dann Trusted Boot oder Measured Boot. Und nur wenn die Hashes der Software dementsprechend, was erwartet wird und dann auch der Hash dann des Passworts dementspricht, was erwartet wird, dann gibt das TPM seinen Schlüssel frei. Und der Schlüssel ist dann zum Beispiel der, der verwendet wird, um deine Festplatte zu ver- und entschlüsseln. So ist das dann, wenn du bei Linux oder bei Windows Festplattenverschlüsselungen mit TPM aktivierst, dann hast du dieses Hashing und den Abgleich der Hashes während des Boot-Vorgangs und das TPM überwacht das und wenn das alles in Ordnung ist, dann gibt das TPM den Schlüssel frei. Und das TPM kann das dann auch nochmal extern belegen. Das nennt man Remote Assistation. Also ein Laptop mit TPM kann ein Zertifikat darüber ausstellen, welche Hashes im Boot-Vorgang beteiligt waren und dann kann von außen festgestellt werden, okay, wahrscheinlich ist dieser Laptop in einem guten Zustand. Das sind die beiden großen Features eines TPMs, Speicherung von Schlüssel und Freigabe in Abhängigkeit vom Zustand und dann Attestierung des Zustands nach außen. Und da gibt es viele Überschneidungen mit Confidential Computing, aber es ist schon noch was anderes. Ja, ich merke schon, das ist alles so ein bisschen ähnlich. Wir kennen es ja aus HTTPS, wo du dann auch so eine Certificate Authority hast. Also du hast hier jemanden mit dem TPM-Modul, dem du ja vertraust offensichtlich. Der hat den Schlüssel und der gibt dir den wieder frei, wenn du ihm das richtige Hash zurufst. Und wir müssen in dem Kontext ja gucken, wem vertraut man da eigentlich? Also wenn ich mir halt überlege, wir lassen die Cloud nochmal raus, ich kaufe mir einen Computer und ich mache dann darauf meinen Lebenslauf und ich mache da vielleicht auch Babyfotos hin und andere Sachen, die ich persönlich vertrauenswürdig finde. An welchen Stellen habe ich denn potenziell, also warum würde ich es denn verschlüsseln wollen? Ist es immer nur, wenn mir jemand anderes das wegnimmt? Also dass ich es dagegen absichern möchte? Dann würde es mir erreichen, ich verschlüssele eigentlich meine Festplatte und wenn er aus ist, ist es weg. Wo kommt quasi dieser Confidential-Teil ins Spiel? Du sagtest, auch der Prozessor verschlüsselt das und holt es auch gar nicht richtig raus. An welchen Stellen hilft mir das, wenn ich jetzt noch nicht nicht die Cloud habe. Wir holen die Leute alle später rein, aber erstmal sind wir nur in dem Kontext. Habe ich da schon einen Vorteil oder da noch nicht? Also auf Endgeräten habe ich nicht so den Riesenvorteil durch Confidential Computing. Also was Confidential Computing erreicht, ist eine sichere Datenverarbeitung auf vielleicht nicht komplett vertrauenswürdigen Systemen. Wenn jetzt mein Computer, wenn ich den als vertrauenswürdig einschätze, dann habe ich wenig Bedarf an Confidential Computing. Der einzige Grund wäre vielleicht, mein Laptop wird geklaut, aber dann reicht eigentlich auch die Festplattenverschlüsselung. Mein Laptop wird geklaut, die Festplatte ist verschlüsselt, keiner kommt an meine Daten heran. Der große Use Case auf meinem Laptop wäre das, was ich vorhin schon beschrieben habe, nämlich der Schutz gegen den Nutzer des Laptops selbst. Also du betrachtest deinen Laptop vielleicht als vertrauenswürdig, aber Sony Motion Pictures betrachtet deinen Rechner nicht als vertrauenswürdig, weil du ihn kontrollierst. Und daher kommt dann auch dieses Konzept. Das ursprüngliche Konzept war, ich habe den Nutzer-Laptop, der gehört dir und jetzt habe ich als Sony Motion Pictures einen Film, der auf deinem Laptop abgespielt werden soll, aber ich möchte nicht, dass du die Daten in Rohform bekommst, obwohl der auf deinem Laptop abgespielt wird. Das ist das Problem, wo ich meinen Bildschirminhalt quasi nicht mitschneiden kann, weil irgendwelche Treiber verhindern, dass ich das mitsehen kann. In die Richtung Das kann man. Glaube ich, nicht verhindern. Was confidential computing verhindert, ist, dass du Daten aus dem Arbeitsspeicher auslesen kannst, obwohl du Admin bist auf dem System. Das heißt, du hast jede... Eine DVD gekauft, du schiebst sie in deinen Laptop rein und wenn du jetzt ganz normal dann diese DVD abspielst, weil DVD ist ein schlechtes Beispiel. Es ist schon ein bisschen her, dass man DVDs geguckt hat. Vielleicht Netflix ist ein besseres Beispiel. Sagen wir Netflix. Die Daten werden gestreamt von irgendwoher. Sie kommen entweder aus einem DVD-Laufwerk oder sie kommen von einem Netflix-Server und dann werden sie bei dir verarbeitet auf dem Laptop. Jetzt könntest du theoretisch einfach den Arbeitsspeicher des Dekodierprozesses auslesen und hättest dann die Videodaten in Rohform. So hat man früher DVDs kopiert oder vielleicht auch heutzutage Netflix-Serien und Computing verhindert das jetzt. Wie ich vorhin beschrieben habe, hält der Prozessor die Daten im Arbeitsspeicher verstüsselt. Das heißt, wenn du jetzt auf diesen Arbeitsspeicher zugreifst, auch vielleicht sogar mit Hardwaremitteln auf den Arbeitsspeicher zugreifst, würdest du immer bloß verschlüsselte Daten bekommen, obwohl eigentlich du komplett die Kontrolle über das System hast. Und die Dekodierung würde in der sicheren sogenannten Enklave stattfinden. Die vom Prozessor aufgespannt wird und Daten bleiben verschlüsselt im Arbeitsspeicher. Und da kann man jetzt auch den Case zur Cloud ganz gut aufspannen. Nämlich in der Cloud ist jemand anderes im Fahrersitz. Das ist vielleicht eine Cloud-Subscription, aber die Cloud wird betrieben von vielen tausend Mitarbeitern von Microsoft, Google, AWS. Und genauso wie Netflix oder Sony auf deinem Laptop gerne eine sichere Ausführung ihres DVD-Dekoders haben möchten, hättest du gerne eine sichere Ausführung deiner Firmendatenbank in der Cloud. Und so kann man das Konzept, das ursprünglich mal für ein Endgerät war, kann man sehr schön auf die Cloud projizieren. Es sind andere Akteure, aber es ist ein sehr ähnliches Setting. Ich möchte meine Daten in der Cloud verarbeiten, wobei ich der Cloud nicht komplett traue. Dann hält der Prozessor in der Cloud die Daten verstüsselt und, Der Cloud-Admin sieht die Daten nie im Klartext. Ich glaube, wir müssten noch gar nicht in die Cloud gehen. Das Szenario haben wir ja auch schon in einem normalen Unternehmen, wo wir sagen, wir haben eine HR-Abteilung und wir haben eine IT-Abteilung und die IT-Abteilung stellt die Systeme bereit. Und das ist ja das uralte Problem, dass die IT-Leute alle Passwörter kennen, die können überall drauf und die HR-Abteilung sagt, aber die sollen sich doch nicht die Gehälter angucken von allen Leuten. Und trotzdem könnten die halt theoretisch jederzeit da ran, weil sie ja für die Wartung zuständig sind und dergleichen. Also du hast ja eh schon das System, auf einem fremden Computer laufen meine Daten, die ich aber irgendwie schützenswerter finde. Oder die Szenarien, was ich auch schon bei unseren Kunden erlebt habe, du hast halt in der Telematik-Infrastruktur, du hast in einem Krankenhaus, hast du ein System, das ist noch gar nicht in der Cloud, sondern du hast einen Connector und dieser Connector, der soll einfach dafür sorgen, dass darüber Patientendaten laufen, aber der, der den Schlüssel zum Serverraum hat, soll trotzdem nicht in die Patientendaten gucken können. das möchte man auch verhindern. Das heißt, Cloud ist, glaube ich, noch die höchste Form davon. Aber wenn immer du in fremden Systemen unterwegs bist und Daten hast, die du nicht da haben möchtest, müsstest du ja irgendwie verhindern, dass man drankommt. Das stimmt. Das ist jedes Mal, glaube ich, ein schöner Use Case für Confidential Computing. Wenn ich eine Datenverarbeitung auf System habe, wo der System am Illustrator, nicht komplett die Daten sehen soll, kann man sagen. Wenn ich eine Abschirmung der Datenverarbeitung von der Infrastruktur haben möchte. Ich hatte das tatsächlich schon mal. Du möchtest gerne deinen IT-Administrator kündigen in der HR-Abteilung. Wo dokumentierst du das jetzt? Wie bereitest du das vor? Der weiß es halt dann schon im Falle und deswegen kannst du es nicht machen. Und ja klar, in der Cloud wird es dann nochmal potenziert, weil du hast noch weniger Ahnung. Du kannst nicht mehr über einen Arbeitsvertrag regeln, bitte guck dir nicht Laufwerk D an, sondern das ist nochmal komplexer. Aber ich glaube, dieses Confidential-Thema begegnet uns überall und es mag zwar über Cloud nochmal verstärkt sein, aber eigentlich, solange ich meinen Rechner nicht alleine benutze und irgendwer anders dafür zuständig ist und da auch während der Laufzeit drauf gucken kann. Habe ich das Problem ja eigentlich immer. Also, dass ich vertrauen muss. Da wird schon keiner was mitmachen. Und ich glaube, das ist so ein Effekt, den sehen wir überall in der IT. Du hast immer so eine Jugendforscht-Phase. Man freut sich, dass es klappt und dass man es irgendwie hinkriegt und dass man elektronisch Daten verarbeiten kann. Und dann kommst du so ein bisschen weiter in den Prozess und stellst fest, okay, jetzt kommen die Passwortknacker dieser Welt, jetzt kommen die Leute, die mal gucken, was geht mit dem System. Und die reizen die Grenzen aus und jetzt muss ich auf einmal anfangen abzusichern und es wird einfach ein bisschen reifer insgesamt. Und da kommen dann diese, ja, von TPM über Enclave, was auch immer, kommen jetzt neue Konzepte mit hinzu, die man, glaube ich, einmal sortieren muss und verstehen muss, was ist eigentlich was dabei. Also, woraus besteht es eigentlich? Weil Computer versteht heutzutage, glaube ich, jeder. Hier hast du eine CPU, da hast du ein bisschen RAM, Kurzzeitgedächtnis, hat man immer so schön in den alten Bilderbüchern gesagt, dann hast du eine Festplatte, Langzeitgedächtnis und die drei Dinge, die kennt eigentlich, glaube ich, jeder. Und dann noch ein bisschen Input mit Keyboard und Maus, ein bisschen Output mit Monitor und Drucker und schon hast du da dein 1970 IT-Handbuch. Und was kommt jetzt im Rahmen von Confidential Computing dazu? Weil wir hatten ja gerade schon darüber geredet, das TPM war ja etwas, das hat vor Confidential Computing schon angefangen. Und da gibt es irgendwie einen Schlüssel drin, den gibt es irgendwann frei. Die Frage, spielt das eine Rolle? Die CPU end- und verschlüsselt Dinge. Das heißt, sie muss ja auch irgendwo einen Schlüssel herkriegen. Eine Enklave muss irgendwie zustande kommen. Lass uns mal versuchen, das so ein bisschen zu sortieren. Wir haben es schon ein bisschen angerissen hier und da, aber ich glaube, es ist gut, wenn wir es nochmal systematisch von vorne erklären. Bei Confidential Computing kann die Anwendung, sagen wir, wir haben dort eine. Datenbankanwendung, theoretisch. Die Anwendung kann dem Prozessor dynamisch zur Laufzeit sagen, bitte schütze mich jetzt gegen den Rest des Systems. Und das sagt die Anwendung über eine ganz normale CPU-Instruktion oder eine Reihe von CPU-Instruktionen, genauso wie die Anwendung über eine CPU-Instruktion den Prozessor bittet, zwei Zahlen zu addieren oder eine virtuelle Maschine zu erstellen. Was der Prozessor dann macht, ist, er nimmt dann die Anwendung, behält sie vielleicht dort im Arbeitsspeicher, wo sie liegt, aber man markiert die Arbeitsspeicherbereiche als Teil einer sogenannten Enklave. Diese Arbeitsspeicherbereiche sind dann speziell geschützt durch die Speicherverschlüsselung. Also alles, was dann in diesen markierten Speicherbereichen liegt, wird im Arbeitsspeicher im Kurzzeitgedächtnis verschüsselt abgelegt und dann nur dynamisch on demand in den Prozessor reingezogen, so wie es normal ist, und dann innerhalb des Prozessors entschlüsselt erst. Das liegt dann für den Experten innerhalb des Level-3-Caches schon entschlüsselt vor, ist aber logisch nicht zugreifbar für andere Komponenten. Der Prozessor trägt dafür Sorge, dass alles, was innerhalb der Enklave liegt, auch nur von innerhalb der Enklave zugegriffen werden kann. Der Level-3-Cache ist nicht direkt zugreifbar. Das wird logisch vom Prozessor verhindert. Man müsste theoretisch entweder einen Fehler in der Implementierung des Prozessors finden, dass man doch auf diesen Cache zugreifen kann oder auf die Register zugreifen kann. Oder man müsste den Prozessor physikalisch öffnen und diese Strukturen z.B. In einem Elektronenmikroskop beobachten oder man müsste einen Seitenkanalangriff erfahren gegen den Prozessor z.B. Stromverbrauch messen, elektromagnetische Abstrahlung messen etc. Da kann man dann auch Rückschlüsse ziehen. Aber wenn man in keinen dieser drei Angriffe erfolgreich fährt, dann sind die Daten nicht zugreifbar und diese Angriffe sind in der Praxis schwierig. Man kann sich vorstellen, einen Prozessor physikalisch zu öffnen und mit einem Elektronenmikroskop zu beobachten, ist komplex. Genauso ist es komplex, einen Seitenkanalangriff durchzuführen. Gerade wenn es at scale geht, stell dir vor, nimmst du halt irgendwie AWS Region West, machst bei jedem Einzelnen dieser Prozessoren, weil da potenziell irgendwie Load drauf kommen könnte, mal so ein Seitenkanal auf. Du musst ja physisch tatsächlich dann da dran. Ich glaube, das könnte etwas kompliziert werden. Das stimmt, das ist kompliziert, genau. Aber wenn wir jetzt, oder vielleicht um die Erklärung abzuschließen, also wir haben diese Enklave, die kann der Prozessor, die erstelle Prozessor. Lass noch kurz ein Stück zurückgehen, weil der Prozessor hat das jetzt gemacht, aber womit, Also der muss es ja irgendwie symmetrisch, asymmetrisch irgendwie vereinschlüsseln. Ah, genau, genau, ja. Und woher kommt das eigentlich? Weil wenn der hinter mir auf dem Post-it steht, dieses Passwort, dann ist das ja auch nicht mehr ganz so spannend, weil dann lese ich einfach aus, was der gerade da verschlüsselt in seinem Cache hat oder im L3 und dann nehme ich einfach den Schlüssel, den ich kenne. Also woher kenne ich den? Also der Prozessor generiert zur Bootzeit einen Schlüssel, den er verwendet für die Speicherverschlüsselung. Das ist ein symmetrischer Schlüssel und dort wird dann in verschiedenen Flavors, je nachdem ob Intel oder AMD, für die Speicherverschlüsselung wird AIS verwendet, wenig überraschenderweise. Für den Experten, das ist dann im Counter-Modus, also als Stream-Cypher, mit einem sogenannten Message Authentication Code versehen. Das heißt, die Verschlüsselung ist auch integritätswahrend, liefert nicht nur Vertraulichkeit, sondern verhindert auch die Manipulation der Speicherbereiche. Das ist auch wichtig. Könnte ich Speicherbereiche manipulieren, könnte ich einzelne Bits flippen und könnte dann verschiedene Angriffe starten, die so verhindert werden. Ich weiß nicht, ob man das damit adressieren kann, aber am Wochenende bin ich im Internet falsch abgebogen und bin irgendwie bei Cloudflare gelandet, die ja mit 1000 Lava-Lampen, oder es sind 64 Lava-Lampen, ein Bild generieren, um die Entropie zu haben, damit sie nämlich genug zufällige Daten haben, um quasi Schlüssel zu erzeugen. Ich fand es super witzig, dass sie Lava-Lampen dafür verwenden. Das hört sich sehr lustig an, ja. Weil tatsächlich ist jetzt die Frage, wenn er at boot time den Schlüssel erzeugt, muss er ja seine eigene Entropie verwenden, irgendwoher. Und da ist die Frage, vermutlich gibt es da irgendwie eine Lösung für. Also ich wüsste jetzt nicht genau was, aber ist das... Schwierig ist die Frage. Also Zufallszahlengenerierung ist ein eigenes wissenschaftliches Feld. Moderne Prozessoren haben in der Hardware einen Zufallszahlengenerator, die auch als sehr gut gelten, auch als kryptografisch sicher gelten. Das heißt, wenn ich zum Beispiel mir eine Zufallszahl generieren möchte, einfach so auf meinem Prozessor, dann gibt es die Instruktion adirand. Genauso wie ich den Prozessor fragen kann, mir zwei Zahlen zu generieren, kann ich mit adirand mir eine wohl sehr gute Zufallszahl geben lassen. Das geht vielleicht zu weit. Meines Wissens nach werden da Ströme irgendwo gemessen. Es wird physikalisches Rauschen erzeugt und gemessen und daraus wird dann ein Schlüssel generiert. Und genau so generiert der Prozessor zur Bootzeit seinen Schlüssel. Und das gilt allgemein als sicher, wie das die Prozessoren machen. Ob das jetzt für jede militärische Anwendung genügt, vermutlich nicht. Aber es ist schon sehr, sehr gut. Ja, sehr wahrscheinlich kannst du dann noch irgendwie hergehen als Serverhersteller. Ich denke mal fünf Jahre weiter für Confidential Computing. Dann hast du noch irgendein Modul da drauf, was eben für die Randomness irgendwas mitgeneriert. Machst du vielleicht noch eine Röhre da drauf, alte Analoge oder so und sagst, die macht das jetzt noch. Definitiv. Aber lass uns in dem klassisch-kommerziellen Bereich bleiben. Ich glaube, das ist secure enough, damit der IT-Leiter Ingo jetzt seine Kündigung nicht sehen kann, die dann irgendwo bei uns in den HR-Systemen existiert, die wir in der Cloud hosten. Das heißt, wir haben im Level 3 Cache, hatten wir alles verschlüsselt? Entschlüsselt. Es ist im Arbeitsplatz verschlüsselt und es wird dann ab dem Level 3 Cache entschlüsselt. Und in der CPU ist es dann eben entschlüsselt. Und bestenfalls programmierst du natürlich deine Anwendung dann so, dass du dann die Verarbeitung da stattfinden lässt und nicht die Verarbeitungsdaten schon exposed nach außen wieder. Richtig. Also man kann da verschiedene Ansätze haben. Man kann jetzt seine Anwendung aufteilen in sicher und unsicher. Wenn wir uns vielleicht einen Webservice anschauen, könnte ich sagen, okay, der meiste Teil ist eigentlich jetzt nicht so relevant, aber ich möchte jetzt das Management meiner TLS Private Keys möchte ich gerne besonders schützen. Dann könnte ich das in einem Enklave auslagern und den Rest außerhalb haben und dann ein Interface zwischen sicherer und unsicherer Welt erzeugen. Die unsichere Welt kann dann mit der sicheren Welt über bestimmte Call-Gates kommunizieren, so ähnlich wie ein Programm mit dem Kernel kommuniziert. Syscall ist ja wahrscheinlich vielen deiner Hörer ein Begriff. Und ähnlich wie ein User-Mode-Programm per Syscall mit einem Kernel-Treiber kommunizieren kann, kann der unsichere Teil einer Anwendung mit dem Teil einer Anwendung kommunizieren, der innerhalb einer Enklave läuft. Üblicherweise verschieden aber ganze Anwendungen in Enklaven weil, das Aufteilen relativ aufwendig ist, man muss sich Gedanken darüber machen was ist ein sicherer, was ist ein unsicherer Teil und oft kommt man dann dazu okay, einiges ist ja alles irgendwie schützenswürdig, weil selten ist es so, dass das ein Teil nur, unsichere oder unwichtige Sachen macht und den anderen Teil dann mit sensiblen Daten hantiert. Der einzige Fall ist da vielleicht, wenn man sich wirklich nur auf kryptografische Schlüssel fokussiert. Deswegen ist es heute meistens so, ich schütze ganze Anwendungen, verschiebe die ganze Anwendung in die Enklave und dann gibt es jetzt sogar die Tendenz, nicht nur ganze Anwendungen, sondern ganze Container oder ganze virtuelle Maschinen zu schützen, um das Ganze noch einfacher zu machen. Weil häufig häufig, ja, Deployment von Anwendungen ist jetzt als Container und nicht mehr als einzelne Binärdatei. Und deswegen ist jetzt der Trend, ich schütze meinen Container komplett mit confidential computing. Wenn wir Cloud sagen, betrachten wir Cloud auch mehr so als fremder Computer, also im Sinne als Infrastructure as a Service und nicht die hochwertigeren Dienste. Also dass du sagst, ich nehme jetzt hier einen S3-Bucket, sondern eher ich würde mir ein Kubernetes hochziehen und sagen, ich skaliere auf einer fremden Hardware und kann eben den Effekt nutzen, dass ich mir nicht selber 20 Server in den Keller stellen muss oder 24 oder 80, wenn ich dann hochskalieren muss und das übernimmt dann eben mein Infrastructure-as-a-Service-Provider? Ja, das ist die richtige Frage. Ich kann mit Confidential Computing sehr schön Infrastructure-as-a-Service sicher nutzen. Ich erstelle mir eine Anwendung oder ich stelle mir eine Enklave auf der Cloud XY. Ich habe quasi so ein Bootstrapper-Programm, das sagt, okay, bitte erstelle mir eine Enklave Dann stellt der Prozessor eine Enklave. Dann kommt jetzt erstmal nochmal ein wichtiger Schritt, den habe ich bisher ausgelassen, nämlich die Remote Attestation. Und jetzt ist, glaube ich, der richtige Zeitpunkt, um kurz Remote Attestation zu sprechen. Stell dir vor, du hast jetzt diese Enklave in der Cloud. Die ist vielleicht leer, abstrakt gesprochen. Und jetzt ist die Frage, bevor ich meine Daten da dorthin schicke oder da ein Programm starte, das ich dann sicher ausführen möchte, woher weiß ich denn, dass diese Enklave vertrauenswürdig ist? Woher weiß ich, dass da wirklich eine Enklave läuft? Da kommt jetzt Remote Station ins Spiel. Den Begriff Remote Assistation vorhin schon mal kurz im Kontext vom TPM verwendet. Und das ist ein sehr ähnliches Konzept und das hat sich, ich glaube, da wurde Confidential Computing auch sehr stark beeinflusst von den existierenden TPM-Lösungen. Was dann nämlich passiert ist, jeder Prozessor, der Confidential Computing fähig ist, oder auch jede GPU neuerdings, hat einen privaten Langzeitschlüssel. Den sie über den Boot-Prozess beibehält. Genau, genau. In einen ROM eingebrannt irgendwo. Genau, genau. Also das heißt, der Schlüssel zur Verschlüsselung des Arbeitsspeichers, der wird beim Bootprozess jeweils neu generiert. Der Schlüssel für Remote Addition, der asymmetrische Schlüssel, der ist Langzeit und der ist eingebrannt. Ja, weil man spricht davon, dass er in sogenannten Fuses vorliegen würde. Jeder Prozessor bekommt dann bei der Herstellung in den Fuses eine eigene Zufallszahl und daraus leitet sich der Langzeit private Schlüssel ab. So wie ein Salt quasi an der Stelle? Ja, oder eher wie so ein Seed. Wie ein Seed, okay. Genau, das sind dann vielleicht 128-Bit oder 64-Bit-Zufallszahl, also eine ausreichend große Zufallszahl. Daraus kann man dann einen privaten RSA-Schlüssel ableiten, das macht die CPU. Und dann auch korrespondierend einen öffentlichen Schlüssel. Wenn man sich ganz ein bisschen mit Kryptografie auskennt, dann weiß man ja, digitale Signaturen werden mit asymmetrischen Schlüsseln, privaten, öffentlichen Schlüsseln erstellt. Das ist das ganze Alice-und-Bob-Thema, wo Alice Bob dann die Nachricht schickt. Genau, genau, genau. Einführen in die Kryptografie. An der Ruhr-Uni zum Beispiel, da kann man sowas hören. Jede TLS-Verbindung im Internet. Wenn oben links das Schloss im Browser ist, dann ist das eine... Irgendwo, dann basiert das auf einer asymmetrischen Krypto. Und da sind dann Zertifikate mit im Spiel. Aber genau, jeder Prozessor hat einen eigenen... Geheimen Schlüssel für Remote Distribution und einen öffentlichen Schlüssel, wie das dann üblich ist. Woher kennt man den? Genau, das ist jetzt spannend. Der öffentliche Schlüssel, dafür gibt es ein Zertifikat vom Prozessorhersteller. Das heißt NVIDIA, AMD, Intel betreiben eigene Certificate Authorities, mit denen sie Zertifikate für ihre Prozessoren ausstellen. Man kann sich das so vorstellen, Intel, da wird ein neuer Prozessor erstellt in der Fabrik, dann gibt der Prozessor den Public Key aus und der Public Key wird notiert und dann erstellt Intel ein Zertifikat dafür, für den Public Key. Was jetzt passiert ist, ich habe jetzt meine Enklave, das Bild, das wir vorhin hatten, meine leere Enklave und der Prozessor nutzt jetzt seinen privaten Schlüssel, seinen privaten Langzeitschlüssel, um ein Zertifikat für diese Enklave zu erstellen. Dieses Zertifikat sieht sehr ähnlich aus wie ein TLS-Zertifikat, also das, was dafür zuständig ist, dass deine Verbindung zu Sparkasse.de sicher ist. Das ist das gleiche Verfahren, TLS. Und der Prozessor erstellt ein Zertifikat, ein TLS-Zertifikat oder TLS-artiges Zertifikat für die Enklave. Und ich kann mir dieses Zertifikat jetzt anschauen und kann daraus lernen, okay, dort ist ein echter, zum Beispiel Intel-Prozessor, der hat eine Enklave erstellt mit den und den Einstellungen, mit der und der Größe und mit der und der initialen Software oder Datenbefüllung. Könnte alles Nullen sein, aber da könnte auch schon was drin sein. Und dann kann ich entscheiden, okay, das sieht gut für mich aus. Genauso wollte ich es haben. Oder das sieht nicht gut für mich aus. Da hat irgendwer fünf Bits geflippt, deswegen möchte ich das lieber nicht haben. Dann kann ich auch basierend auf einer positiven Einschätzung einen sicheren Kanal in die Enklave herstellen, zum Beispiel einen TLS-Kanal, genauso wie gerade ja schon genannt zur Sparkasse.de, dein Browser das macht, kannst du dann mit unterschiedlicher kleinen Software einen sicheren Kanal herstellen und kannst dann deine Daten teilen mit dieser Enklave. Und dann ist es auch schon fertig. Und das muss ich jedes Mal machen, wenn die Enklave neu hochfährt, nehme ich an? Nicht unbedingt. Es könnte, so machen wir es mal konkret, Es könnte wie folgt aussehen. Du möchtest eine Datenbank, sagen wir eine MongoDB, gerne sicher in der Cloud betreiben oder auf Hardware Dritter, der du nicht ganz vertraust. Das heißt, du würdest ein MongoDB-Paket, vielleicht eine Binärdatei oder einen Container, hochladen, dann mittels einer Software den Prozessor sagen, bitte erstellen wir jetzt eine Enklave um dieses Paket. Was wäre das für eine Software? Das könnte zum Beispiel eine Software von uns, von Edge Systems sein. Wir handeln verschiedene Software, aber im einfachsten Fall ist das dann, hast du eins unserer Tools benutzt, um ein Software-Paket für SGX zu erstellen. Du könntest MongoDB nehmen und sagen, okay, jetzt bauen wir bitte mal das für die Intel-Plattform, die SGX-Enklave. Und dann könntest du das einfach so ausführen und dann würde da Bootstrapper-Code laufen, der die Enklave erstellt und dann deine ursprüngliche Software dort lädt. Heißt das, ich würde mir das einmal kompilieren für das System dann? oder... Ja, das kommt drauf an, welche Technologie dort genau drunter liegt. Wenn das so die ursprüngliche Enklaven-Technologie ist, Intel SGX, das ist das, was es schon seit zehn Jahren gibt, dann muss es einmal cross-kompiliert werden. Wenn... Oder in den meisten Fällen musst du das mal neu kompilieren. Wenn du aber eine der anderen Technologien verwendest, nämlich zum Beispiel ARM BSEV oder das neuere Intel TDX oder von ARM das CCA, dann musst du es nicht neu kompilieren. Dann ist es meistens auf VM-Ebene und das kann dann ja, am Ende wird dann meistens in einer extra VM dein Container gestartet. Das sieht dann ja am Ende, ob es eine VM mit Confidential Computing Features oder eine Enklave ist, die um eine Anwendung herumgeht, ist relativ egal. Das sieht alles sehr, sehr ähnlich aus. Ich glaube, wichtig ist hier, für manche Technologien muss man das nochmal neu verpacken oder neu kompilieren. Für andere nicht unbedingt. Kommt drauf an, an was das für ein Prozessor ist. Der häufigste Fall wird ja tatsächlich sein, dass du eher in einem Docker- oder Containerumfeld bist, dass da Kubernetes existiert und dass man sagt, man hat nicht das Mongo-Image per se oder die Mongo-Binaries. Genau, wir können das Beispiel vereinfachen. Sagen wir, du hast einen MongoDB-Docker-Container. Ich nehme den offiziellen, weil der ist ja offiziell. Genau, du nimmst den offiziellen, genau. Dann könntest du hingehen und sagen, okay, wir starten jetzt mal eine VM, VM, eine Confidential Computing VM mit einem bestimmten, Linux-Umgebung. Wenn du sagst VM, also was abstrahiert ist, weil normalerweise in meinem Verständnis habe ich keine VMs, sondern ich brauche irgendwas, was VMs dann verwaltet, startet und macht. Wäre das quasi so eine Docker-VM oder was bezeichnest du als VM in dem Kontext? Also das ist eine klassische virtuelle Maschine. Du kannst dir bei den Cloud-Anbietern Confidential Computing virtuell Maschinen geben lassen. Genauso wie du dir eine normale virtuelle Maschine geben lassen kannst. Also die haben so ein Web-Interface, da kann ich ja sagen, erstelle mir eine virtuelle Maschine. Genau, du kannst auch programmatisch über eine API machen. Nehmen wir mal das Beispiel. Du erstellst dir eine Confidential Computing VM. Dann wird in dieser VM-Initial auch natürlich Software geladen, nämlich ein Bootloader, ein Kernel und dann im nächsten Schritt wird dann vielleicht ein Container geladen. Jetzt ist die Remote Registration dafür da, um dir zu signalisieren, dass diese Confidential VM oder auch Enclave gut ist und dass sie dem entspricht, was du erwartest. Das heißt, du bekommst vom Prozessor ein Zertifikat, in dem dann, wie ähnlich vorhin beim TPM beschrieben, die Hashes der Software drinstehen, die in dieser Confidential VM geladen worden sind und auch die Konfiguration der Confidential VM. Und dann, wenn du das für gut empfindest, ist, kannst du einen Kanal herstellen zu dieser VM basierend auf dem Zertifikat des Prozessors und kannst dann mit dieser Confidential VM arbeiten. Und theoretisch oder auch praktisch besser gesagt, kann dann dort dein MongoDB Container laufen. Du hast gesehen, okay, das ist genau der MongoDB Container, den ich haben wollte. Und der läuft wiederum auf genau dem Kernel, den ich haben wollte und genau dem Bootloader, den ich haben wollte. Den vertraue ich und dann sprichst du direkt schon mit deiner MongoDB und von da an ist eigentlich alles genauso wie bisher. Der einzige Unterschied oder eigentlich der einzige Extraschritt war, dass du dir einmal auf der Client-Seite das Remote Assistation Zertifikat angeschaut hast, das der Prozessor ausgestellt hat. Das schaust du dir natürlich meistens nicht von Hand an. Genauso wie dein Browser sich automatisch für dich das Zertifikat von der Sparkasse D anschaut, macht das in den meisten Fällen dann eine Software, die sich anschaut, was sind da für Hashes in dem Zertifikat drin und welche Partei hat denn dieses Zertifikat am Ende zu verantworten. Da geht es dann hoch vom Prozessor nach Intel und das kann man dann nachvollziehen. Beim Browser haben wir ja schon so Standardsoftwares. Gibt es da auch schon Standardsoftwares, dass die das quasi überprüfen, weil ich glaube, der Teil ist relativ einfach. Ich fahre mir eine VM hoch, programmatisch, über Webinterface, wie auch immer. Das heißt, ich habe jetzt eine, dann lasse ich meinen Mongo da drin laufen und jetzt will ich nur noch mal wissen, bevor ich die Kündigung als Dokument da ablege in dem Speicher, will ich einmal kurz überprüfen, passt das eigentlich? Und ich würde ja erhoffen, dass da irgendetwas Standardisiertes schon existiert, dass es machen kann. Ansonsten müsste ich ja regelmäßig mal irgendwie mit Curl, Weget, sonst was einmal schauen, was da zurückkommt und das irgendwie intellektuell prüfen. Also da gibt es keinen richtigen Standard für, was auch daran liegt, dass es relativ komplex ist, was in diesen Zertifikaten drinstehen kann. Ich bin mir sicher, dass sich dabei die Zeit noch ein Standard rausbilden wird, aber aktuell ist es eher so, dass der Client dann anwendungsspezifisch ist. Ich würde mir also quasi eine Komponente bauen. Also wenn ich das mache, würde ich mir immer so ein Verifier-Skript Programmlännen schreiben. Genau. Und dann würdest du da rein reinschreiben, folgende Hashes sind in Ordnung und dann überprüft dein Skript das und dann, wenn das sagt, ja, passt, dann kannst du von da an alles machen, wie bisher. Remote Station ist super wichtig. Ohne Remote Station funktioniert das Ganze oder macht das Confidential Computing wenig Sinn, weil ansonsten die Infrastruktur natürlich einfach lügen könnte. Und bei Edgeless Systems liegt auch ein großer Teil des Fokus auf der Remote Station. Das das sinnvoll und einfach nutzbar zu machen. Und da beschäftigen wir uns genau mit dem Thema, oder der Frage, die du gerade hattest, wo weiß ich denn, dass das ein gutes Zertifikat ist, mit guten Hashes und so weiter. Da haben wir Client-Side-Tools für und auch Server-seitige Tools, die zum Beispiel in einem Cluster von Confidential VMs die Remote Attestation übernehmen, die jeden neuen Knoten, der dazukommt, jeden neuen Container einmal mittels Remote Assistation verifizieren und dann nach außen ein gebündeltes Zertifikat quasi präsentieren. Und zur Verifizierung dieses gebündelten Zertifikats haben wir dann, auf der Client-Seite eine Library und Tools, mit denen man das dann in seinen Workflow einbauen kann. Aber ja, das ist dann, wo es ein bisschen komplexer wird, aber wenn man das schon gekapselt hat und weiß, was man möchte, was man nicht erreichen möchte, dann kann man das ähnlich handeln, wie man auch sonst Public-Key Dinge handelt. Remote Attestation habe ich jetzt, ich habe mich ein bisschen vorbereitet auf die Folge und ein paar Sachen gelesen und nicht viel verstanden. Und bei Remote Attestation bin ich dann auch irgendwann über NVIDIA gestolpert und über über Training von Modellen und dergleichen. Ich verstehe noch nicht ganz, wenn ich über Remote Attestation und Grafikkarten zum Beispiel spreche, wie das zusammenhängt, weil da habe ich ja, da verstehe ich das Konzept der Enclave noch nicht so ganz, weil da habe ich ja nicht so sehr das Konzept von, ich fahre eine VM hoch, sondern ich kenne Grafikkarten mehr so als, die kriegen Aufgaben von der CPU oder von irgendwas zugewiesen, dann sollen die mal machen. Die haben auch keine Festplatte, also auch keinen Langzeitspeicher. Das heißt, die unterscheiden sich so ein bisschen. Wie verhält sich das jetzt mit Remote Attestation und Confidential Computing im GPU-Bereich? Ja, spannende Frage. Da geht es darum, dass man einen sicheren Kanal von einer Confidential VM, also sagen wir, du hast innerhalb einer Confidential VM dein AI-Framework geladen, dein TensorFlow oder PyTorch oder so. Und du hast das jetzt mit Remote Assistation schon überprüft und weißt, okay, da läuft jetzt mein PyTorch. Und dann hast du deine Trainingsdaten da hochgeladen und willst jetzt dein Modell trainieren. Dann ist jetzt die Frage, wie erstelle ich jetzt einen sicheren Kanal zur GPU? Das ging bisher nicht. Wie du vielleicht weißt, der GPU spricht man dann meistens über CUDA, über den NVIDIA-Treiber. Und der spricht dann direkt über Hardware, über den Bus mit der Grafikkarte. Und diese Kommunikation von Treiber, der innerhalb der Confidential VM läuft, zur Grafikkarte, Das konnte man bisher nicht sicher machen. Da konnte einfach dann der Hypervisor ein, wir stellen uns vor, wir haben jetzt unsere Confidential VM mit PyTorch etc., läuft in der Cloud oder auf einem anderen nicht vertrauenswürdigen System bei dir im Keller. Da konnte bisher mit normalen Grafikkarten, konnte der Hypervisor zum Beispiel eine Grafikkarte simulieren und die Confidential VM hatte keine Möglichkeit zu überprüfen, ob das jetzt eine echte Grafikkarte ist und konnte auch keinen sicheren Kanal bootstrappen zu dieser Grafikkarte. Das heißt, man musste die Daten quasi im Plaintext irgendwie an eine PCI-Stellstelle geben und wusste nicht, was passiert mit den Daten. Und dieses Problem ist jetzt behoben mit der neuen Nvidia H100-Grafikkarte. Aber das ist ja schon die alte. Das stimmt, das ist schon die alte. Oder die aktuelle. Man könnte sagen, das ist die aktuelle. Die neue ist angekündigt, aber das ist die aktuelle. Nämlich, die kann jetzt auch remote to the station. Und da hat auch wieder jede Grafikkarte ein Public-Private-Key, also ein Zertifikat, das von Nvidia ausgestellt worden ist. Dieses Zertifikat wird jetzt innerhalb der Confidential VM überprüft. Aus dem Zertifikat kann man rauslesen, okay, es ist eine echte NVIDIA H100 GPU, weil es ein Zertifikat von NVIDIA ist. Und ich kann auch die Firmware-Version der Grafikkarte herauslesen. Da kann ich dann abschätzen, okay, du könntest eine Policy haben, ich vertraue keiner Grafikkarte unter Version 1.15, weil unter der Versionsnummer gab es eine Schwachstelle, die bekannt war. Das heißt, ich weiß genau, okay, das ist eine echte H100 mit der und der Firmware-Version. Und wenn ich das überprüft habe und das gut finde, dann kann ich genau wie vorhin beschrieben aus meiner Confidential VM einen sicheren Kanal bootstrappen zu der H100 GPU und kann dann über diesen sicheren Kanal meine Daten auf die Grafikkarte laden. Und das wäre dann zuerst das KI-Modell und dann meine Daten im zweiten Schritt und dann im dritten Schritt die Kernelfunktion, so nennt man das, die da ausgeführt werden soll und dann im vierten Schritt würde ich dann die Funktion aufrufen. Das heißt, bei der H100 wird die ganze Grafikkarte quasi zu einer großen Enklave und das große Feature ist, dass ich einen sicheren Kanal von meiner Confidential VM zur Grafikkarte aufbauen kann. Das heißt, ich habe da jetzt verschiedene Hops. Ich habe von mir einen sicheren Kanal in die Confidential VM und von der Confidential VM einen sicheren Kanal in die GPU. Und der Treiber in der Confidential VM hat per Remote Assistation die GPU überprüft und ich habe per Remote Assistation meine Confidential VM überprüft. Zwei wesentliche Fragen, die mir im Kopf rumgehen. Das eine ist, wie überprüfe ich de facto dann das Zertifikat? Also gibt es da wieder Software von euch, die man zum Beispiel nehmen könnte oder ich müsste mir was selber schreiben? Von der GPU? Genau, das H100 Zertifikat. Da bringt Nvidia Software für mit. Wenn ich jetzt innerhalb meiner confidential VM die aktuellsten CUDA-Treiber laufen habe oder Tools, dann ist da schon automatisch Software für die Verifizierung des Zertifikats der H100 dabei. Ich könnte das auch selber schreiben. Ich glaube, da hat auch Nvidia Spezifikationen für. Aber der einfachste Weg ist, okay, ich habe da einfach die Software von Nvidia installiert. Dann kann ich die Software einfach nehmen und jetzt stelle ich mir die Frage, ich sitze da in dem Rechenzentrum, es gibt hier mehrere Clients, die auf einer Maschine sitzen mit einer H100 drin und mein Kanal zur H100 ist secure, aber jetzt kommt der Felix Schuster vorbei und der holt sich auch eine Enklave, die auch mit von dem Host-System, mit der GPU sprechen möchte. möchte. Sprechen wir quasi mit derselben Enklave und sind sozusagen im selben verschlüsselten Bereich? Oder kann ich alleine dann nur die Enklave nutzen? Du kannst sie nicht mehr nutzen, weil ich sie irgendwie blockiere. Da begebe ich mich jetzt auf dünnes Eis. Es kann sein, dass in der aktuellen, Version kein Teilen möglich ist. Es wird aber in Zukunft definitiv möglich sein. Also die Feature-Ankündigung ist schon da. Ich bin mir nicht sicher, ob das in der aktuellen Firma-Version der Nvidia H100 schon implementiert ist. Das heißt, der Podcast muss einfach zwei Wochen später sein. Genau, genau. Was definitiv so ist, du teilst ja nicht den Club mit anderen. Wenn der Handshake erfolgt ist, dann hast du dort deine eigene. Okay, dann ist die auch nur für mich und dann kann ich in meinem Worldgarden spielen und niemand anderes kommt rein. Genau, genau. Genau. Was ich nicht genau weiß, was aber in Zukunft definitiv kommt, ist, dass du mehrere Instanzen gleichzeitig auf dieser H100 haben kannst. Also, dass du ein H100 in acht Mini-H100s aufteilst virtuell und dass jede wiederum dann eine Enklave laufen lässt oder sich im Enklavenmodus befindet. Das kann sein oder das wird so kommen. Ob es in der aktuellen Firmware funktioniert, das weiß ich nicht genau. Ich kann mir vorstellen, mein Training ist ja irgendwann vorbei und dann muss ich entweder einen guten seriellen Modus haben, dass der Nächste, der gerade trainieren möchte, das bekommt. Ja, auf jeden Fall. Oder dass es irgendwie partitioniert wird, sinnvoll, dass ich dann parallel trainieren kann. Also das Nachhinein ist gar kein Problem. Du bist fertig, die Session wird beendet. Der Nächste kann, ob es ja, dass parallel die Karte aufteilen. Ich glaube, das geht schon, aber definitiv in Zukunft. Wir sind sehr technisch gewesen, Wir haben über viele der Details schon gesprochen, aber wir haben noch nicht so über den, also außer MongoDB natürlich und über die Kündigung der HR-Abteilung gesprochen. Aber was für Leute nutzen zum Beispiel eure Lösungen? Wo sehen wir Confidential Computing heute schon im Einsatz? Wo macht es heute schon Sinn oder macht es nur für bestimmte Teilbereiche Sinn? Was ist so deine Einschätzung? Also man kann sagen, etwas überspitzt, dass confidential computing aktuell vor allem da eingesetzt wird, wo es Regulierung oder Paranoia gibt. Also in Deutschland. Genau. Paranoia auch positiv besetzt in dem Fall vielleicht. Im Security-Bereich ist natürlich auch eine gewisse Paranoia nicht verkehrt manchmal. Es gibt wenig Regulierung, die es speziell fordert, aber es gibt sie. Für Dinge wie zum Beispiel, vielleicht ist ja auch Hardware Security Module ein Begriff, das ist etwas, das weit verbreitet ist im Markt, damit sichert man Schlüssel ab und der Grund, warum HSMs so weit verbreitet sind, ist Regulierung. Also im Finanzsektor etc. Werden HSMs gefordert und das hat ein bisschen gedauert, aber mittlerweile ist das ein Standardprodukt, was man braucht, wenn man bestimmte Dinge machen möchte. Zum Beispiel, wenn man jetzt Kreditkartendaten verarbeiten möchte, muss man bestimmte Daten und Schlüssel in einem HSM speichern. Wir sehen, dass es bei Computer Computing in eine ähnliche Richtung geht, aber dass wir da noch früher dran sind. Und die Regulierung, die bisher existiert, das ist hier und da, poppt da was auf. Vielleicht das populärste Beispiel ist in der Telematik-Infrastruktur in Deutschland. Da gibt es Anforderungen der Gematik, das ist die Bundesagentur, glaube ich, die sich um die technischen Vorgaben für Dinge wie das E-Rezept und die E-Patientenaktik kümmert. Die Gematik hat in ihren Anforderungen für diese Anwendungen Dinge gefordert, die sehr schön auf Confidential Computing mappen. Da wird immer davon gesprochen, dass es einen Betreiberausschluss geben soll, also eine Abstimmung der Anwendung gegen die Infrastruktur und ihre Betreiber. Da sind wir wieder bei dem Krankenhausbeispiel, wo dann die Krankenhaus-ITler und die Ärzte unterschiedliche Arten von Zugang haben sollten. Ja, oder insgesamt das Beispiel, ich möchte meine Daten auf einem System verarbeiten, dem ich nicht komplett vertraue. Das ist, glaube ich, genau die Sichtweise der Gematik da drauf. Und dazu ist auch immer von einer sogenannten vertrauenswürdigen Ausführungsumgebung die Rede, nämlich einer VAU, wie das die Gematik nennt, kurz. Kurz, das Konzept dieser VAU passt auch sehr schön zum Konzept der Enklave oder entspricht eigentlich eins zu eins dem Konzept der Enklave oder der Confidential VM. Die Gematik hat in ihrer Anforderung nicht gesagt, oder nutzt das Wort Confidential Computing nicht, aber man kann sagen, es wird umschrieben durch die technischen Eigenschaften. Das heißt, man kann schon sagen, dass in der deutschen Telematik-Infrastruktur Confidential Computing eigentlich gefordert ist. Und was wir sehen oder im Markt ist, dass confidential computing dort auch breit eingesetzt wird. Also das E-Rezept ist ja seit, ich glaube seit mindestens 12, 18, 24 Monaten im Produktiveinsatz. Die E-Patientenakte auch schon länger. länger. Und die Anbieter von E-Rezept und E-Patientenakte nutzen Confidential Computing, um den Anforderungen der Gematik gerecht zu werden. Und dort wird auch Software von Azure Systems eingesetzt. Und unsere Software kümmert sich da vor allem um die Tücken der Remote Attestation. Dass ich dann so eine E-Patienten Anwendung oder E-Rezept. Etc. bestehen häufig aus vielen Knoten, weil es natürlich auch viele Nutzer gibt und unsere Software kümmert sich darum, dass die vielen Hundert oder Tausende von Enklaven, dass die alle mittels Remote Attestation überprüft werden, dass dort eine Schlüsselverwaltung stattfindet und so weiter. Das Schöne ist jetzt, dass es ja völlig unabhängig davon ist, ob die bei irgendeinem Dienstleister im Keller stehen, die Server, oder ob die bei irgendjemandem, der als großer Cloud-Anbieter unterwegs ist, Das ist, wenn das einmal confidential ist, ist es ja in jedem Kontext confidential. Korrekt. Ich erinnere mich da an diese wunderbaren T-Systems-Bemühungen, irgendwann mal die Microsoft Cloud nach Deutschland zu bringen, aber abgespeckt und immer mit schlechteren Versionen und dergleichen. Und das ist ja eine der, wir sprachen gerade über Paranoia und über Deutschland, scherzhaft, das ist ja, was in Deutschland auch immer wieder ein Problem ist, dass amerikanische Cloud-Provider bestimmte Daten nicht haben sollen, weil man da nicht speichern kann, was immer die Regularien sein mögen oder die Paranoia einfach nur hergibt. Und wenn man jetzt sagt, wir haben eine Lösung gefunden, die erlaubt es uns entweder im Keller in Stuttgart, in einem Rechenzentrum, was eh Deutschland niemals verlässt, das secure zu haben. Aber dasselbe Konzept, dasselbe technologische Konzept könntest du auch auf irgendwas anderes anwenden und sagen, das kannst du nur knacken, wenn du da irgendwie ein Elektronenmikroskop draufstellst. Das wird vermutlich keiner tun, es sei denn, das sind irgendwelche wirklichen staatskritischen Geheimnisse. Korrekt. Also ich glaube, man sollte aufgrund dieser Problematik, dass es immer noch angreifbar ist physikalisch mit Elektronenmikroskop oder auch mit Seitenkanalüberwachung, dass es dadurch angreifbar ist, sollte man wahrscheinlich keine Staatsgeheimnisse in chinesischen Rechenzentren hosten oder so. Aber ein sehr schöner Fall ist, wie du sagst, Ich muss jetzt nicht immer unbedingt das On-Prem haben, sondern ich kann jetzt auch rechtssensible Anwendungen, wie vielleicht eine E-Patientenakte, auf flexibler Infrastruktur hosten. Das ist einer der großen Use Cases. ist. Das kann ja vielleicht auch helfen. Wir haben auch mal viel mit Versicherungen zu tun, die ja sehr lange, sehr viele Jahre in On-Prem-Systeme investiert haben. Und wenn du jetzt anfängst zu gucken, Kubernetes war ja immer schon eine ganz gute Idee, weil du kannst es relativ flexibel skalieren, aber jetzt könntest du sogar den Confidentiality- Aspekt skalieren und sagen, lassen wir doch das meiste Zeug mal bei uns laufen, lassen wir einen Teil davon in einer Cloud laufen und dann finden wir mal raus, wie Cloud generell funktioniert. Und das eröffnet ja diese Möglichkeiten jetzt, dass du sagen kannst, die ganze Zeit schwebt mir so ein bisschen Blockchain im Kopf herum, wo du so Trustless-Environments sind, ich will nicht an Blockchain denken, aber es ist ja so, dass du die Trust im System einfach nicht mehr brauchst, du hast andere Möglichkeiten gefunden, wie du damit umgehen kannst. In diesem Fall ist es halt nicht so, dass du alles offen machst und sagst, prüf doch nach. In diesem Fall ist es, du machst es zu, kannst nicht reingucken. Genau. Das ist halt der Unterschied hier. Genau, also es gibt ein paar Überschneidungen mit Blockchain, da kann ich gleich noch was zu sagen, Aber ich glaube, das zentrale Stichwort ist Zero Trust. Also Zero Trust beschäftigt sich ja, Traditionell damit, wie ich in einem Netzwerk Systeme authentifiziere und der Gedanke von Zero Trust ist ja, ich habe zwar mein Unternehmensnetzwerk, aber ich betrachte es so, als ob es eigentlich unter Kontrolle des Angreifers wäre. Und deswegen überprüfe ich bei jeder neuen Session, ist die andere Partei, mit der ich spreche, die richtige und dann setze ich verschüsselte Kanäle auf. Das heißt, ich vertraue meinem eigenen Unternehmensnetzwerk eigentlich nicht mehr oder ich vertraue meinem Cloud-gehosteten Netzwerk nicht. Das ist Zero Trust klassischerweise. Und Confidential Computing erweitert das jetzt schön auf die Compute-Infrastruktur. Da vertraue ich nicht nur jetzt meinem Netzwerk nicht mehr, sondern ich vertraue auch meinen Knoten im Netzwerk nicht mehr und starte deswegen auf den Knoten dynamisch sichere Ausführungsumgebungen, die sich dann auch wieder ausweisen können. Ich habe vor einer Zeit einen Blogpost geschrieben, da habe ich die Analogie bedient, dass Zero Trust eigentlich sich darum dreht, dass man sein Unternehmensnetzwerk so wie Hotel-Wi-Fi betrachtet. Also da kann alles drin sein. Jedes Bit kann gefälscht sein oder mitgehört werden. Und die Analogie dann zu confidential computing ist, dass ich zusätzlich dazu meine Comput-Infrastruktur so betrachte, als ob ich auf jedem Knoten ungepatchtes Windows 95 laufen hätte. Und wenn ich das kombiniere, ungepatchtes Windows 95 auf Hotel-Wi-Fi, dann habe ich ein sehr pessimistisches Bild meiner Infrastruktur, was aber, glaube ich, auch der richtige Ansatz ist und dann mit confidential computing und existierenden Zero-Trust-Ansätzen kann ich dann trotzdem eine sichere und, überprüfbare Datenverarbeitung haben. Zero Trust klingt immer so fies, finde ich, aber eigentlich ist es ja genau, das Umgekehrte, weil du kannst jedes Gerät mitbringen, was du möchtest, diese Bring-Your-Own-Device-Policies und was nicht alles da dran hängt. Ich kann mit meinem eigenen Laptop arbeiten, weil ich das gewohnt bin, und du hast nicht mehr dieses, ich weiß nicht, ob es heute noch aktuell ist, aber ich kann mich erinnern, ich war mal bei Kunden und wenn du da das LAN-Kabel in die Dose gesteckt hast mit deinem Laptop, der nicht vom System war, ist das gesamte Netzsegment runtergefahren, weil es eben eben nicht Zero Trust war. Für denjenigen, der sich nicht damit auskennt, klingt es ja völlig schizophren, weil wenn es Zero Trust ist, dann muss man es doch runterfahren, wenn da kein Vertrauen mehr ist. Im Gegenteil, es ist ja genau andersrum. Es ist so, dadurch, dass ich so tue, dass jeder wie auf dem Marktplatz alles an Absichten haben kann, gehe ich halt in jeder einzelnen Interaktion hin und sage, jetzt weist sich doch nochmal kurz aus, dass wir wirklich über dieses Thema sprechen können, gemeinsam. Und ich gehe nicht davon aus, wer im Unternehmensnetzwerk ist, der kann schon alles lesen. Da muss man nicht mehr aufpassen. Ja, definitiv. Genau so ist es. Vielleicht das Thema Regulierung noch kurz abzuschließen. Wir haben das gerade über Gematik und E-Patientenakte gesprochen. Es kommt jetzt auch eine neue Regulierung namens DORA. Das ist der Digital Operational Resiliency Act der EU. Da geht es um IT in der Bankenlandschaft und dort gibt es einen Absatz der Encryption in Use und oder Trusted Execution Environments, also das Englische, die englische Entsprechung der gerade genannten vertrauenswürdigen Ausführungsumgebung fordert. Das heißt, das ist so der, das könnte der Startschuss für breiteres Confidential Computing im Banken- und Finanzsektor sein. Nein. Lass uns da nochmal ganz kurz sortieren. Ich hatte mir fest vorgenommen, das am Anfang zu machen, aber diese Unterscheidung, Addressed, in use, in transit, noch mal kurz zu klären. Wir haben ja drei Gegenden. Also wir sprachen eben über das 1970er IT-Handbuch, wo man sagt, es gibt eine CPU, es gibt einen Kurzzeitspeicher, es gibt einen Langzeitspeicher. Wenn ich den Computer ausmache, dann sind die Daten addressed. Und wenn ich dann aus meinem Rechner die Festplatte ausbaue und in einen anderen Rechner einbaue und die dann lesen möchte, wäre es ganz gut, wenn das nicht ginge. Dafür gibt es Festplattenverschlüsselung. Korrekt. Das ist ja der ganze Addressed-Tag. At rest, richtig, im Ruhezustand. Und dann kann das Ganze jetzt passieren, dass es in Transit ist. Ich habe zwei Computer, ich habe einen Datenbank-Server und ich nehme einen Web-Server, auf dem läuft meine Web-Anwendung. Und jetzt schiebe ich die Daten hin und her. Wenn jemand abfragt, ich möchte bei Ebay eine E-Gitarre kaufen, dann fragt er in die Datenbank, habe ich gerade E-Gitarren oder so. Damit das verschlüsselt ist, was dazwischen ist, haben wir den ganzen HTTPS-Teil. Wir haben alles, hatten wir gerade schon viel darüber gesprochen, über TLS-Verschlüsselung, das Asymmetrische und dergleichen. Damit sind wir in Transit. kennen wir Ewigkeiten schon. Also das grüne Symbol, inzwischen hat, glaube ich, kein Browser mehr die Möglichkeit, dass du wirklich HTTP-Seiten sinnvoll aufrufen kannst. Da kommen drei Warnungen und der macht sich selber aus. Also hat sich auch im Laufe der Zeit einfach eingeschlichen. Weiß nicht, ob BitLocker jetzt auch für Festplatten schon Standard ist, aber wir wissen, wir haben da schon etabliert was. Und InUse war ja sozusagen die letzte Bastion. Also während der Computer läuft und dann passt es natürlich, wenn du mehrere Nutzer auf einem Computer hast. Das macht ja keinen Sinn an demselben Rechner, an derselben Tastatur, weil dann kannst du es schwierig schützen, weil dann ist ja schon entsperrt sozusagen der Rechner. Aber wenn du einen Rechner hast, da können sich zwei Menschen dran anmelden, kann der eine Mensch jetzt sehen, was der andere macht, indem er zum Beispiel sich eine Speicherseite ausliest aus dem RAM. Oder ein Rootkit oder ein Virus kann die Daten sehen, theoretisch. Und da kommt Comfort Edge, weil wir Dinge spielen, nämlich dass dann während der Verarbeitung die Daten trotzdem verschüsselt und geschützt sind. Und dass dort trotzdem das Rootkit im Arbeitsspeicher rumverwerten kann und trotzdem immer nur Verschleißdaten sieht. Damit haben wir eigentlich den gesamten Bereich schon abgedeckt, wie Confidential Computing ist. In welchen Bereichen findest du es am spannendsten im Moment? Wir hatten kurz über DORA gesprochen, wir hatten über Patientenakten gesprochen. Was sind so deine Lieblings-Usage-Szenarien? Wo würdest du am liebsten mehr Confidential Computing sehen oder wo freust du dich, dass es heute eingesetzt wird? Ja, also da gibt es so zwei, drei Themen. Zum einen natürlich AI. AI ist gerade super spannend, auch ohne Confident Computing. Ich glaube, jeder, der ChatGPT schon mal benutzt hat, hat erstmal einen kleinen Schock bekommen. Ich kenne es auch aus meinem beruflichen Kontext. Ich würde gerne ChatGPT für viele Dinge verwenden. Zum Beispiel, ich bekomme viele Verträge vorgelegt, jetzt nicht immer die wichtigsten Verträge, es könnten dann Non-Disclosure-Agreements sein über zehn Seiten und da ist es zum Beispiel praktisch, wenn man den Vertrag einmal bei ChatGBT hochlädt und fragt, ist das ein Standardvertrag oder wo müsste ich mal genauer reinschauen? Weicht der von der Norm ab oder kann ich das vielleicht auch einfach nur mal überfliegen, diesen NDA? Natürlich sind das dann häufig auch schon Daten, die vielleicht doch relevant sind, weil da auch Vertragspartner drinstehen, weil dort vielleicht auch schon sensible Daten oder sensible Punkte besprochen werden. Und da hat man dann oft die Hemmnis oder vielleicht auch gar nicht die Erlaubnis, solche Daten mit Angeboten wie ChatGPT zu teilen. Mit Confidential Computing kann man jetzt Dienste erstellen, Chat-GPT-artige Dienste erstellen, bei denen die Daten, die in den Dienst reingehen, durchgehend verschüsselt bleiben. Bleiben in einer Enklave und dann in der nächsten Enklave. Genau, sie gehen quasi von meinem Computer, werden sie verschüttet, hochgeladen, bleiben dann innerhalb der Enklave, werden dann auf die Enklave in der GPU geladen und dort verarbeitet. Und wenn man das jetzt richtig zusammenzurrt, dann kann man nicht nur einen Schutz gegen die Infrastruktur haben. Also, wie du vielleicht weißt, ChatGPT läuft auf Azure-Infrastruktur. Mit Computing kann ich einen ChatGPT-Art-in-Games bauen, bei dem die Daten gegenüber der Infrastruktur, wie zum Beispiel Azure, abgeschirmt sind. Aber ich kann auch einen Schritt weiter gehen, wenn ich es besonders clever mache, kann ich auch OpenAI ausschließen, den Betreiber des Services. ist. Da muss man ein bisschen mehr an Gehirnschmalz investieren, also es ist dann nicht nur Lift & Shift, so wie wir es gerade mit der MongoDB beschrieben haben, sondern man muss sich da tiefer Gedanken drüber machen, aber es ist technisch möglich, ein, Chat-GPT-artigen Dienst zu erstellen, bei dem der Prompt, meine Eingabe, meine Anfrage an Chat-GPT durchgehend geschützt bleibt und niemand außer mir weiß, was ich gerade mit diesem AI-Modell bespreche. Das ist, glaube ich, super für viele Kontexte, also Behörden, Gesundheit, man kann sich vorstellen, Experten-System, dass das Hausärzten hilft und so weiter. Das finde ich sehr, sehr spannend und. Dann noch mal konkret, man kann viele spannende Anwendungen implementieren mit Confidential Computing, die über den reinen Schutz gegen die Infrastruktur hinausgehen. Man kann die Technologie zum Beispiel nutzen, um einen sicheren Datenaustausch zwischen Parteien herzustellen. Also sagen wir, wir haben Partei A, B, C und die möchten gerne Daten tauschen, ohne sich die gegenseitig zu zeigen. Dann kann man das mit Confidential Computing implementieren. Das ist dann quasi eine neue Art von Anwendung, die durch confidential computing möglich wird. Das ist wieder dann nicht Lift und Shift, sondern ich baue etwas Neues und nutze diese Runtime Encryption und die Remote Addition zusammen, um eine gemeinsame Datenverarbeitung zu realisieren, in die von außen keiner reinschauen kann. Wo aber jeder genau weiß, was dort drinnen passiert durch die Remote Addition. Und am Ende ein Datenstrom herauskommt, der dann interessant sein kann in verschiedener Art und Weise. Und ein konkretes Beispiel ist, wir haben mit einer Firma oder mit einer NGO namens Hope for Justice jetzt ein Projekt gehabt. Hope for Justice kümmert sich um die Bekämpfung von Menschenhandel und die haben viele Daten zu Vorfällen in dem Bereich und wollten die gerne mit anderen NGOs austauschen. Hope for Justice ist vor allem in England tätig. Die wollten dann gerne mit ähnlichen Organisationen in Südamerika oder in Osteuropa oder in Deutschland Daten austauschen, um die Menschenhandelsnetzwerke besser nachvollziehen zu können und Täter, Opfer besser identifizieren zu können. Da haben wir denen mit der Hilfe der Firma Intel eine Plattform gebaut, wo genau das möglich ist. Sie können selektiv Daten hochladen. Andere können dann auch selektiv Daten hochladen. Und dann wird innerhalb der Plattform. Wird dann geguckt, okay, folgende Personen kommen in euren beiden Datenbanken vor und dann kommt als Signal nur raus, schaut euch doch mal Datenbank Eintrag 53 an. Die andere NGO müsste zu der mehr wissen. Und so bleibt dann quasi die Privatsphäre der Menschen in der Datenbank gewahrt und es wird nur ein Signal herausgegeben, zu welcher Person beide Organisationen oder mehrere Organisationen Informationen haben. Das ist zum einen ein sehr schöner Case und zum anderen auch ein gutes Beispiel für das, was noch mehr mit Confidential Computing möglich ist, außerhalb von reiner Datensicherheit. Ich stelle mir vor, dass gerade Datenprodukte, also wir kennen das ja auch über diese Data Spaces, die es so gibt, das heißt Gaia-X und Co. Genau, da gibt es viele Überschneidungen. Also das wäre dann quasi ein Data Space, genau, definitiv. Und da geht es auch, ich habe vorhin, haben wir ganz kurz mal über Blockchain und Krypto gesprochen, das ist auch die Überschneidung mit Blockchain und Krypto. Krypto hast du jetzt gesagt. Ich habe nur Blockchain gesagt. Okay. Nämlich, da geht es, ich meine, Ethereum, da geht es um Smart Contracts. Ein Problem, das Smart Contracts manchmal haben oder generell haben, ist, dass alles, was dort passiert, öffentlich ist. Und mit Confidential Computing kann ich sozusagen Smart Contracts erstellen, bei denen, die von außen nicht einbar sind, so ähnlich, wie ich es gerade beschrieben habe. Also Confidential Contracts. Confidential Contracts könnte man es nennen, genau. Von außen kann ich sehen, was dort drin passiert oder welche Logik dort läuft, aber ich kann nicht sehen, welche Daten verarbeitet werden. Das ist ja... Ich bin skeptisch, ob das dem ganzen Thema zum Durchbruch verhelfen wird. Ich glaube, die Datensicherheit ist deutlich spannender, aber aus Nerd-Sicht ist das auch ein interessantes Thema. Ich habe verstanden, was Confidential Computing so macht. Ich bin gespannt, wo es hingeht. Hast du so einen Tipp, wie sich die nächsten Jahre in dem Bereich entwickeln werden? Also ich bin natürlich optimistisch, klar, auch schon aus Berufsgründen. Man hört häufig, dass man annimmt, dass Confidential Computing so ähnlich sich entwickeln wird wie TLS. Vor zehn Jahren war TLS auch eher was Esoterisches, eher was für Online-Banking, eher was für große Enterprises. Mittlerweile ist ja jeder Blog, jede Party-Pick-Seite mit TLS geschützt. Und der Browser lässt sich eigentlich kaum noch eine Seite aufmachen, die nicht mit TLS geschützt ist. Wir haben bei TLS, weil wir es noch gar nicht angesprochen haben, schiebe ich das noch schnell nach. Bei TLS haben wir ja auch immer so ein Performance-Penalty, wenn wir über Confidential Computing sprechen. Was sind die Kosten für Confidential Computing außer erhöhter Komplexität? Man kann vielleicht sagen, Performance-Impact von 10%. Das ist natürlich ganz grob. Es gibt natürlich auch verschiedene Arten von Performance, Latency, Throughput etc. etc. Aber ja, 10% ist vielleicht ein guter Pi mal Daumen. Ich glaube, TLS liegt auch so in dem Bereich. Und ich glaube, das ist schon ein Rahmen, wo es sich für viele Anwendungen lohnen kann. Und ja, was von vielen Experten erwartet wird, ist, dass Confidential Computing irgendwann zu so einem Hygienefaktor wird wie TLS, weil es recht günstig ist. Und wenn es überall verfügbar ist und auch die Software soweit ist, dann ja, warum nicht anschalten, wenn ich dadurch die ganzen Vorteile erhalte. Von daher glaube ich, dass es so ähnlich den Weg gehen wird wie TLS, und dass in ein paar Jahren große Teile der Cloud confidential sind und ich genau vom ersten Bit nachvollziehen kann, was auf meinen Daten läuft und niemand auf meine Daten zugreifen kann. Du hast gesagt, zehn Jahre haben wir das jetzt schon. Die meisten CPU-Generationen, die jetzt aktuell sind, können das oder können das alle? Oder muss man noch so ein bisschen warten, bis einmal das Rechenzentrum durchgewischt wird von irgendwem? Es können alle Server-Prozessoren von Intel und AMD. Und die aktuelle ARM-Server-Prozessoren-Architektur kann es auch. Aber es wird noch nicht implementiert im breiten Feld. Weil, wie du vielleicht weißt, ARM ist ja nur die Spezifikation. Ist ja Blueprint, genau. Genau, und dann müssen das Firmware... Huawei oder Ampera nehmen und in Prozessoren umsetzen. Da ist es noch ein bisschen, da ist es glaube ich, hat es wenig Verbreitung bisher, aber man kann auch sagen, dass ARM-Server-Prozessoren auch relativ wenig Verbreitung haben. Auch eher esoterisch, ja. Genau, also ich weiß natürlich, ich glaube, der größte Batzen da ist wahrscheinlich AWS Graviton. Das läuft auf ARM-Prozessoren von AWS, glaube ich. Das ist schon relevant, aber klar, ich sage mal 90, 95 Prozent, ganz grob geschätzt, würde ich sagen, läuft auf Intel- und AMD-Prozessoren. Und da können es alle, es kommt mal darauf an, was man genau haben möchte, es kommen die letzten drei AMD Prozessor-Generationen, können es also schon ein paar Jahre zurück. Für die sicheren Enklaven können es auch die Intel-Prozessoren schon mehrere Generationen zurück. Für Confidential VMs, also eher so das Neuere mit auch Containern, da kann es nur die aktuellste Intel-Prozessor-Generation. Das wäre dann Emerald oder Sapphire Rapids. Wenn jetzt jemand dazugehört hat, Lust hat, sich da einzuarbeiten, da mal ein bisschen mit rumzuspielen, wohin würdest du sie schicken? Was ist der beste Ort, um einzutauchen in Confidential Computing? Da gibt es verschiedene Möglichkeiten. Es gibt vom Confidential Computing Konsortium eine Reihe von ganz guten White Papers und Präsentationen. Da kann man gut starten. Es gibt von uns organisiert die Open Confidential Computing Conference mit hochkarätigen Speakern, wie zum Beispiel dem Azure CTO, Intel CTO, AMD CTO. Die letzte Iteration lief im März diesen Jahres, nicht zu lange her. Da gibt es sowohl Vorträge, die einzelne Anwendungen vorstellen, die einen Überblick geben über das Thema, aber auch dann Spezialistenvorträge. Ja, das findet man gut auf YouTube. Wenn man mehr so der YouTube-Typ ist, ist, glaube ich, OC3 oder Open Computing Conferences kann das ein guter Startpunkt sein. Das war ein Geek kommt selten allein. ein. Vielen Dank fürs Zuhören und großen Dank an dich, Felix. Ja, vielen Dank. Hat Spaß gemacht. Gerne wieder. Wenn unsere Hörer jetzt mehr von dir wissen wollen, wo finden sie dich im Netz? Sie finden mich auf LinkedIn und per Mail bin ich auch erreichbar. Das wäre FS, zwei Buchstaben, Vorname, Nachname, jeweils der erste Buchstabe, at edgeless.systems. Wenn ihr Feedback zu dieser Folge habt, könnt ihr es gerne unter www.eingiekommseltenerlein.de eintippen. Macht es gut. Bis zur nächsten Folge. Wir hören uns.