 Das ist euer Besetzer-Team, ihr spricht André und wir besetzen euch die Artikatur von sicheren IoT Devices, das soll euch helfen, ein sicheres System oder ein sicheres IoT Devices zu bauen. Er ist ein wichtiger Freelancer mit einiger Erfahrung im Bereich der Security und einen kleinen Applaus. Grüß Gott, also Grüß euch. Moin zu sicherer Artikatur von IoT Devices, das wurde schon erklärt bei der M-Gangern. Die Internetgemeinschaft verwendet jetzt Raspberry Pies und könnte sich überlegen, wie könnte ich damit ein sicheres IoT System bauen und was ist notwendig, um zum nächsten Level zu bekommen. Das Erste, was ihr machen müsst, tut mir leid, ihr müsst die Hardware wechseln. Diese Funktionalität werdet ihr mit einem Raspberry Pi nicht zusammenkriegen. Was ihr braucht, ist ein NXP, ein IMX, in der neuen Version, in deinem Amkord XR7, die übliche Features, ein Endes mit 100 Megabit per Sekunden, ein Netzwerk Anschluss, serielle IOTC, er hat ein Secure JTEC, das ist das, was wir wollen. Das sind die Dinge, die wir brauchen, damit wir ein sicheres IoT Device machen können. Wir werden uns anschauen, was ist ein Secure IoT Device. Wir werden zuerst einmal grundsätzlich in den Partizkussionen hineingehen. Wir werden ein bisschen über die Risiken und die Bedrohungen sprechen, die Secure Boot verstehen, wie wir Partizionen verschlüsseln, wie wir kritische Ressourcen voneinander isolieren, wie wir ein bisschen über die Organisation reden, wie wir das in einem Unternehmen aufsetzen und wie man ein sicheres IT System aufsetzt. Es ist immer die Frage, wer das manischt und es wird nicht der Developer sein. In diesem Gedanken gibt es ein paar organisatorische Aspekte, die sollten wir uns auch noch anschauen. Wir haben ein ganz einfaches Beispiel von einer Ladestation. Das hier ist die Charging Station. Jetzt wird ein Auto aufgeladen mit einer NFC-Karte freigeschalten. Das ist verbunden mit dem Datacenter des Operators, das bekommt und kontrollt Messages und schickt welche weg und kriegt Updates. Ganz wichtig, dass es genau aufschreibt, was passiert, denn das muss auch verrichtet werden. Vorher können wir jetzt aufteilen in verschiedene Infektionen. Es gibt die Sensoren, die Internet-Gateways, die Sachen, die am Rande unseres Netzwerks sind und dann natürlich das Datenzentrum, bzw. sieglaut. Das hier ist unser Gerät, das zum Auto verbunden ist, oder mit Sensoren, welches die Daten verschüsselt und es zum Datenzentrum sendet. Aus dem haben wir hier Techniker, die direkt dort vor Ort sind und das System konfigurieren. Also brauchen wir irgendwie eine Art von sicherer Verbindung zu unserem Gerät. Wir brauchen einen sicheren Transport-Algorithmus für die System-Updates. Dafür nehmen wir einfach HTTPS, dann brauchen wir Fernzugriff über HTTPS oder SSH und dann brauchen wir noch Datenupload über HTTPS oder HTTPS. Dann haben wir eine lokale Datenbank, welche die lokale Daten speichert und dann haben wir noch eine Visualisierung, die auch zum Datenzentrum ein Abbruch geladen wird. Beim Datacenter gibt es einen Update-Server, irgendeine Einrichtung, die die Daten empfängt, PKI und natürlich irgendein DNS-Service. Wenn wir jetzt die Risikoanalyse machen, dann gibt es so ein paar Methoden, die wir dafür benutzen können. Zum Beispiel gibt es den BSI 100 Standard oder den ISO EC 27005. Ein wichtiger Fakt diesbezüglich ist, dass sie ein Prozess definieren, wie man Risiko, Risiken und Gefahren bewertet. Es definieren die Grundwerte, Vertraulichkeitsintegrität und Verfügbarkeit. Dies werden unsere Ziele sein, die wir hier erreichen wollen. Es gibt hier ein Idee, die sich hier durchzieht. Sicherheit kann nicht einfach am Ende drauf gehauen werden. Es muss direkt von Anfang an mit Reindesign werden. Es hat Einfluss auf die Bootzeiten, die Dateisystemen, Performance usw. Wenn wir jetzt zurück zu unserem Beispiel gehen, dann sehen wir hier das System Update, was von dem Datenzentrum zu unserem Gerät geht. Da brauchen wir natürlich irgendeine Form von Authentifizierung. Das heißt, wir brauchen hier Client oder Server Certificat. Hier bei Remote Zugriff, da brauchen wir, wenn wir zum Gerät uns verbinden, ein Server Certificat auf dem Gerät. Für einen Daten Upload brauchen wir vielleicht einen VPN. Da brauchen wir die übliche Authentifizierung, eine Client Certificat und einen Server Certificat. Da haben wir so eine Datenbank, dann sollte die Datenbank natürlich verschisselt sein. Wenn man das hier sieht, dann sieht es voll mit Sicherheitsanforderungen für kryptographische Sachen, Zugangstaten usw. Wir werden ein bisschen über Sicherungsbits reden und über Secure Boot und Kurzsignierung, vielleicht auch ein bisschen über DNS-Sech reden. Wenn wir jetzt hier die Organisation unserer Firma anschauen, das sieht jetzt hier nicht so gut aus, wie es aussah, bevor ich skupiert habe, dann haben wir hier am Anfang die Entwicklung, die ein bisschen Code entwickelt. Um jetzt Secure Boot hinzubekommen, brauchen wir irgendein Mechanismus, den Code zu signieren. Das könnte man direkt im Development Team machen, aber wenn wir das machen, dann ist das Development Team dafür zuständig, diesen Schlüsselkompon zu sichern, aber dann, wenn das Development Team das verliert, dann könnte jeder einfach kurz signieren und das quasi der wichtigste Part unseres sicheren Systems. Das heißt, es ist wichtig, dass diese Zugangstaten sehr gesichert sind. Das heißt, man braucht innerhalb der Firma einen Verfahren zum signieren von Code. Das heißt, wir haben hier irgendwie so ein Service, der mit Benutzernahme und Passwort entgegen nimmt, um Code zu signieren. Aus dem brauchen wir irgendwelche Zugangstaten, die auf dem Ziel gespeichert sind. Wenn wir irgendwelche Geräte zum Kunden liefern, dann haben wir die Support Team oder das Team, das sich um Probleme kümmert. All diese müsste brauchen auch irgendwie Zugriff auf das System. Das heißt, man braucht innerhalb der Firma irgendwie so eine Art Verständnis für diese Sachen, um diese Sicherheitssachen von der IT-Serviceabteilung zu bekommen. Es ist auch wichtig, die richtige Hardware zu auszuwählen, zum Beispiel hier NXP IMX6 Ultraleiten am Core. Das ist 500 MHz. Es hat 100 MW Fleisch. Es kann auf vielen Temperaturen arbeiten. Es wird von Karo hergestellt. Karo hat auch mehr performante Geräte, wie ich schon gesagt habe. Es hat übliche Features, zum Beispiel Internet, USB, GBIO und die wichtigen Sachen sind der Sicherer JTEC, den E-Fuse und CAM, Kryptografischer Beschleuniger und Schauen wir uns einmal an, wie diese Funktionalität miteinander zusammenhängen. Wir wollen einen Secure Boot etablieren. Wir wollen also sicher gehen, dass dieser Device hier nur mit unserer Boot-Segrenz gestartet werden kann und mit keiner anderen. Das zu erzwiegeln. Hier nennen wir ein paar Safe-Speeds, also Sicherheits-Speeds in unseren Codes einbauen. Das nennt man One-Time Programmen, weil wenn man die MR-Sets sind in dem Prozess festgebrannt, kann man nicht mehr verändern. In dem Prozess ist der Hash-Value, ihr eures Public Keys eingebrannt. Der bleibt dann da drinnen. Diese Hash-Values sind die Trust-Anchoes deines Public Keys und dieser Public Key wird dazu verwendet, die Signature, die deinem Code beiliegt, zu verifizieren. Das ist der Bootloader. Das ist der wichtige Punkt ist, der Public Key ist auch zum Code verbunden. Der Initial Bootloader, also der Bootstrap-Loader, ladet aber das ganze Image. Es wird den Public Key hashen, es wird den verifizieren. Es wird sicherstellen, ob der Hash-Value gleich ist mit dem, was in der CPU eingebrannt ist. Wenn das Duali ist, also in Ordnung ist, dann wird mit dem Public Key die Signature, die entschlüsselt, Computed Signature of the Bootloader Image, of Bootloader execution code, executable code, von Bootloader damit freigeschalten. Wenn der Public Key oder die Signature nicht übereinstimmen, wird die CPU nicht starten. Der Prozess, um das zu erzeugen, um diesen Bootloader zu signieren, du startest deinen Bootloader, du komputierst den Hash, du nimmst deinen Private Key, der Private Key wird den Hash signieren und dann schiebst du die Software, die mit dem Bootloader verbunden ist. So wird ein Secure Boot oder High Insurance Boot installiert. Das ist ein Beispiel, wie wir diesen Mechanismus dazu einsetzen können und einen Chain of Trust in der Bootphase zu etablieren. Einen sekundären Programmloader macht genau dasselbe, wie wir vorhin uns schon angeschaut haben, also liest das Boot Image, verifiziert die Signature, wenn die Signature in Ordnung ist, wird jetzt macht der U-Bootloader, der Bootstraploader wird das noch einmal machen, wenn er den Kernel hochladet. Also auch bevor der Kernel geladen wird, wird wieder verifiziert. Diese Schritte sind an ihre Keys gebunden, lassen sich keine anderen Keys unterschieben. Gut, und wenn dann der Kernel verifiziert ist, dann können wir auch das Route-File-System freischalten. Also Minimum 10 MB, aber das meist es mehr. Wenn du ein kleines Debian Set verwendest, bist du mit 20 MB ganz perfekt unterwegs. Ein ziemlich schneller Prozess, wichtig dabei ist, der Bootloader muss externe Elemente unterstützen. Also ein Environment ist als Textfile auf das Disk gestohlt. Das heißt, diesen Environment Textfile muss man auch nochmal separat absichern, damit keiner dort hineinschreiben kann. Und das tut man in dem man diesen Environment-File als Textfile in das U-Bootloader ins Image integriert. Das ist mit dem Image im verschlüsselten und signierten Image integriert. Damit garantiert werden kann, dass da nicht hineingeschieben werden kann. Der Device-Tree wird anschließend an den Kernel überreicht, weitergegeben. Das ist also wichtig, dass das niemand modifizieren konnte. Das baut so eine Trusted Chain auf, bis das System gebotet ist. Und solange niemand Zugriff auf die Code-Signing-Key sagt, im Image des Bootloaders wird auf diesem Deweis nicht gebotet werden, das wir nicht freigeben. Und das ist wichtig, weil wir jetzt das File-System verschlüsseln. Und das passiert natürlich auf dem Bootloader. Ihr müsst euch jetzt, ihr müsst jetzt euch erinnern, das Routetail-System ist verschlüsselt. Das heißt, wir können unser Routetail-System nie verändern, weil das den Hash verändern würde. Das heißt, in unserem Routetail-System kann nichts geändert werden. Und das kann nichts dort gespeichert werden, weil das würde sonst den Hash verändern. Da kann also nichts rein, was beim Reboot, weil es den Reboot überlegen kann. Das Problem ist, manche Anwendungen erwarten, dass sie in Slash IDC schreiben können. Das heißt, dafür machen wir jetzt ein Overlay für unser Routetail-System. Mit diesem Overlay können die Applikationen jetzt irgendwelche Daten im IDC verzeichnensspeichern. Aber weil die Daten wichtig sind, werden sie nach dem nächsten Reboot weg sein. Jetzt brauchen wir noch irgendwelche verschüsselten Storage, wo wir Konfigurationsdaten oder andere Daten speichern können. Hier kommt jetzt ein anderes Feature von IMX6 ins Spiel. Das ist der Master Key, der CAM Master Key. Der Kernel hat ein Adapter für, mit diesem Master Schlüssel zu interagieren. Und damit können wir jetzt Daten verschlüsseln. Nämlich den Schlüsselblop, da könnten die Schlüssel drin liegen, mit dem man dann die verschlüsselte Storage benutzen kann. Seht ihr, es gibt hier zwei wichtige Aspekte diesbezüglich. Einmal gibt es die Kette des Vertrauens im Bootloader und dann den verschüsselten Speicher und den Overlay über das Datei-System. Alles startet mit den Fuse-Bits, die wir in der CDU haben. Diese Fuse-Bits werden sehr früh im Produktionsprozess gesetzt. Wenn wir diese Boards einkaufen, dann sind die Fuse-Bits schon gesetzt. Diese Fuse-Bits, die aktivieren J-Tech, die aktivieren Boots von anderen Sachen. Da werden viele Sicherungen beschrieben. Und dann gibt es natürlich Fuses auch für die Hashes. Das heißt, über den kompletten Produktionszyklus ist es so, dass man nur signierte Bootloader starten kann. Das heißt, in jeder Phase müssen wir darüber nachdenken, wie man den richtigen Bootloader für den Produktionsprozess findet. Wir fügen nicht nur Sicherheit hinzu, bevor wir unser Produkt schippen, sondern wir machen das schon während des Produktionszyklus. Das heißt, von einem ganzen Anfang, wenn wir das zusammenbauen und wenn wir die Batterie hinzufügen, die Sensoren hinzufügen, andere Dinge tun, die Seriennummer setzen und das verteilen und während des Betriebs es auch wichtig, über Software-Updates zu reden. Es ist nicht möglich, Abt oder so zu benutzen wie Indibien. Wir müssen nämlich unsere Update, unsere Image ist komplett updaten. Ich habe über die, dass PKI benötigt ist, also für Code-Signing, Remote-Zugriff, Update-Signieren von Update-Paketen. Für all das braucht man irgendwelche PKI Zugangsdaten. Es gibt da mehrere Möglichkeiten, wie ihr das machen könnt, nämlich man könnte z.B. Letzend-Crypt benutzen, aber Letzend-Crypt kann man mit Letzend-Crypt keinen Code-Signing machen. Wenn man sich Code-Signing anschaut, dann ist es in diesen Tools, dann sieht es so aus, dass sie OpenSSL benutzen, um Schlüssel zu generieren, aber dann werden sie danach modifiziert. Sie werden gebündelt und verändert, sodass Letzend-Crypt das nicht machen kann. Letzend-Crypt ist nicht die richtige Wahl für IoT-Geräte in irgendwelchen Geräte bei dir zu Hause, weil Letzend-Crypt nie signieren wird für irgendwelche Geräte aus dem Heimbereich, also Dinge, die hinter dem Router stehen. Letzend-Crypt kann halt nicht nachprüfen, ob diese Domain zu dem User gehört. Das heißt, Letzend-Crypt ist hier nicht so nützlich. Man könnte selber PKI hosten, z.B. OpenSSL kann sowas tun, kann Zertifikate generieren und man kann es so machen, um einen Komplettent-CA zu bauen. Den kann man dann in einer Firma benutzen. Das Problem ist, man braucht Verständnis dafür, wie man das macht und so weiter. Und die meisten Firmen haben das wahrscheinlich intern nicht. Man könnte ein self-hosted PKI benutzen, z.B. MS Server, Microsoft Server, aber das ist sehr teuer. In diesem Bereich kann dann jeder MS Server bloß mit einem CA umgehen. Das heißt, wenn man mehrere CAs haben möchte, dann braucht man viele MS Server. Da muss man mit Online-Zertifikaten umgehen und so weiter. Es ist jedenfalls relativ kompliziert. Was ich jetzt neulich gesehen habe, es gibt PKI SS Service, z.B. von Nexus Group. Ich weiß nicht, ob es schon öffentlich ist, aber ich denke, es ist ein guter Art und Weise. Es ist so ein bisschen daneben zwischen self-hosted PKI und self-hosted scripted PKI, aber man hat trotzdem die komplette Kontrolle über die CA. Wo wir jetzt gerade über PKI reden, man braucht OCSP, Online-Zertifikats, Status-Protokoll. Das wird benutzt, damit die IoT-Devices schauen können, ob Zertifikate noch valide sind. Es gibt CRS, dann gibt es EST, dann gibt es nur eine Modifikation dieses EST-Protokolls und dann gibt es andere Protokolle, diesbezüglich. Beside all diesen PKI-Services müssen wir uns mit dem Update-Service auseinandersetzen. Es ist ganz wichtig, wenn wir etwas verhindern wollen, müssen wir ja updating. Und ein Update ist immer in der Risiko. Wir haben ein Update-Service und wir müssen dieses Update-Service zum Ziel bringen. Was ich manchmal sehe, ist, dass es falsch gemacht wird. Man macht einen TAR-File, dass das Image hat und drinnen hat und irgendeine Art von Signature, dann wird das Ent ausgepackt und dann verifizieren die Signature und das ist der falsche Weg. Man sollte zuerst, wenn du ähnliche Data bekommst, als erstes immer die Signature verifizieren und erst dann erst entpacken. Das könnte eine TAR oder eine SIP-Pompe sein und man kann das nicht mehr. Also es muss der erste Schritt immer die Verifizierung der beigelegten Schlüssel sein. Wenn ich das nicht kann, dann ist der Prozess falsch designt. Wenn einmal das Update-Package angekommen ist und du willst ein bestehendes System mit dem neuen Image ersetzen, immer noch ein paar Slides zurück, wir haben über Vertraulichkeit und Verlässlichkeit, wir müssen auch sicher sein, dass irgendein Update-Mechanismus, also es darf nicht wirklich sein, auch wenn das Update korrumpiert ist, dass das System gebrickt wird, also freezed, es muss immer funktionsfähig bleiben. Und wenn das Aktivsystem geschossen wird, muss es immer zum vorherigen System automatisch zurückkehren, es darf nicht gebrickt sein, das ist also der ganz wichtige Punkt. Also wenn wir den Bootloader anschauen, ich denke, es wäre möglich, auch mit Uboot zu kreieren, ich denke, es wäre möglich mit dem Bootloader möglich, seinen Mechanismus zu installieren. Ich denke, es wäre möglich, ich denke mehr, dass wir den Boot, also Uboot, so zu konfigurieren. Of course you see here a variable, this would be necessary to sign this data as well. Das sollte diesen Datenblock ebenfalls signieren. Und das sollte über ein Skripter folgen, auch dieses Skript sollte signiert sein und auch wenn wir ein Skript austauschen. Wenn einer von euch sich mit Skripten gut auskennt, kann man nachher noch darüber reden, das würde ich gerne machen. Sie solltet mal alle Interpreter von euren Devices wegtun. Keine Bash, kein Biden, kein JavaScript, nothing. Also auch den Zugiff auf GPIO, die eigentlich auch an der Weise ist, es kann definiert und dann kann festgelegt werden, wer darf schreiben, wer ist darf lesen, machen wir eine Firewall, machen wir Cell-Boxing oder irgendwelches, für das Cell-Phone. USB 3, modernen days, is using DNA. USB 3 verwendet DNA heute. Die Frage ist, wird Direct Memory Access, wenn wir eine USB 3-Device anhängen, kann es sein, dass die direkt eingreift, ohne dass er beneficiert werden kann. Firewall hat ein ähnliches Problem, also die 15, 23 Sachen. Irgendwas, was DMA verwendet, das kann alles überprüft und sichergestellt. Da gibt es eine Reihe von Mechanismus, die beachtet werden sein, die man verwenden kann, um dein Device zu isolieren. Du könntest Unix Group machen, du könntest irgendwelche Namespaces verwenden, du könntest eine VirtualBox oder einen Docker verwenden, eine Trust Zone mit einem U-Kernel oder auch einen L4 Micro-Kernel. Das ist Unix System, das gibt man mal drüber. Unix Groups Namespaces. To establish or manage C Groups is using SystemD on your System. Gute Methode ist dazu, SystemD zu verwenden auf deinem Device. Da kann man Zugiff auf Tipps in einzelnen Netzwerken definieren, C Groups zu definieren, sehr handy, sehr praktisch. KVM oder Docker, die verwenden auch Namespaces und C Groups einen Level drüber, um auch Isolierungen zu erreichen. Aber es geht nicht nur, dass man den DMA-Axis isoliert. Man muss auch den Zugiff vom Top-System. Es sind Anti-60-Millionen mit Zeichen von Code, das muss man auch isolieren, das ist gar nicht so einfach. Da muss man vorsichtig sein, bevor man das System verifiziert. Opti wird das nächste Level, an Komplexität und Sicherheit. Das ist in Wirklichkeit eine Art Micro-Kernel, mit einer Trust Zone, das RIDGE OS, ein Call in die Trust Zone, die dort gewisse kryptografische und sichere Operationen triggert. Das ist ein gut eingefilter Mechanismus, mit dem ein sicheren Input-Prozess relativ gut steuern kann. Was noch schöner wäre, wenn die hardware bereits integriert wäre, dass die hardware direkt und nur aus der Trust Zone z.B. erreichbar wäre, in Trust and Execution. Aber ich kenne keine hardware, die das kann. Wenn es hardware hat auf dem Board, dann kann man das nicht, aber das gibt es halt nicht. Bis jetzt haben wir das noch nicht realisiert. Da können wir jetzt die Opti-Putssequenz machen. Eine weitere sehr interessante Variante, um einzelne Tasks zu identifizieren, ist, wenn man das auf dem Board ist, eine sehr interessante Variante, um einzelne Tasks zu isolieren, ist eine Familie von Micro-Kernels, gelangt zu Wil Fiasco, während des Startups definierst du, wer weh was schickt auf, an Nachrichten, das ist eine Micro-Kernel hier, dieser Micro-Kernel hat nur 60.000 Lines, dieser Micro-Kernel hat nur 60.000 Zeichen, Lines von Code, ist relativ sicher zu halten, und der definiert Kommunikations- Kennzeichnungen, wie von einem Task auf den nächsten Task Informationen weitergerecht werden, wenn die Erlaubnisse dazu da sind. Da setzt du so eigene Kommunikations-Channels durch dann einzelne Apps frei, wenn du also dann dynamisch einen Linux-Kernel startest, dann haben dir gewisse Dinge, die dann da definiert sind, auf Memory-Zugreifen, auf Output-Zugreifen, also da kannst du den Zugriff hier einschränken, die wir festlegen. Dieser Kernel ist spezifisch für deine Hardware zugeschnitten in diesem Fall. Also, du solltest L4 auf deiner eigenen L4-Hardware hochbringen. Ah ja, und der Interrupt hat nur einen einzelnen Interrupt, und der wird eventuell Modem und USB bedienen, und das ist sehr schwer auseinanderzuhalten. Auf einem anderen Brett hatten wir irgendeine 3D-Beschleunigungsprobleme, die wir irgendeiner von meinen Kollegen konnte, einen mit 4D-Beschleuniger implementieren. Und hat zwei Partitionen dafür freigeschaltet. Das war wirklich cool. Wir sind schon fast am Ende. Wir haben über Ladestationen geredet, die auf einem Parkplatz sind, die zugreifbar sind, mit einer öffentlichen IP. Es gibt eine öffentliche IP, was passiert, wenn wir jetzt in unserem Haus so eine Ladestation haben? Jetzt haben wir ein Problem mit Let's Encrypt. Wir kriegen nämlich keinen Zertifikat, weil kein öffentlicher C.A. ein... ein Zertifikat ausstellen wird. Das ist ein Problem, falls wir ein User-Interface haben. Und wenn der User jetzt die Ladestationen managen möchte, dann hat der Nutzer jetzt die Wahl zwischen... dazwischen den... den Benutzernamen und Passort im Klartext weiterzugeben oder irgendeine selbstsignierte Zertifikat gegeben. Aber wenn man das macht, dann gibt das so eine Warnung. Möchtest du wirklich diese Seite mit HTTPS verbinden, weil der Browser warn dich davor, dass es ein selbstsigniertes Zertifikat ist? Also fragt der Browser, ob der Server getrusted ist. Das ist ziemlich nervig. Wenn man jetzt hier Sicherheit aufbauen möchte, für IoT-Geräte, die im Heimnetz weglaufen, dann hat man ein Problem hier. Und das andere Problem ist, wenn man dieses IoT-Gerät jetzt ins Heimnetz benutzt, dann gibt es vielleicht Dinge, die man nicht benutzen kann, zum Beispiel DNS-Sack vielleicht, weil es vom Router benutzt wird oder vielleicht funktioniert im VPN-Verbindung nicht mehr. In einem Heimnetz gibt es ziemlich viele Limitationen. Bezüglich HTTPS Problems habe ich ein paar Leute von Chrome gefragt. Dann haben sie mir gesagt, dafür haben wir eigentlich keine Lösung. Das ist ein bisschen nervig, weil so eine Webseite wäre ein gutes User-Interface. Wenn es irgendeine Lösung dafür gibt, dann würde ich mich freuen, davon zu hören. Das ist jetzt das Ende meines Vortrags. Wir hatten uns die Architektur eines solchen IoT-Gerätes angeschaut, die unterliegende Hardware, wie man die Vertrauenskette machen kann während der Bootphase, während nach dem Boot, wie man den Fischerselte, den Fischerselten-Speicher lesen kann, wie man mit dem Read-Only-Speicher umgeht. Und ja, vielen Dank. Vielen Dank für den Vortrag. Falls ihr irgendwelche Fragen habt, dann haben wir ungefähr zwei Fragen. Vielen Dank für den Vortrag. Ein kleiner Hinweis. Vielleicht ist es hilfreich, ein bisschen Kernel-Hardening zu machen und Userspace zu schützen durch irgendwelche Software. Es kommt darauf an, wie du deine Software baust. Und eine kleine Frage. Ich habe nicht verstanden, wie die Fischerselte wie die Fischerselte hilft im Threat-Modell. Welches meinst du? Die letzte Frage. Ich habe nicht verstanden, wie die Fischerselte ist. Welches meinst du? Die letzte Folie. Die letzte Folie. Weiter, weiter, weiter. Das war die Zusammenfassung. Hier gibt es die Fischerselte-Speicher. Wie hilft das hier? Was ist der Zweck davon? Also, Fischerselte-Speicher heißt, dass es verschisselt ist. Weil das andere Read-Only ist, können wir keine Daten speichern. Also für IP-Adressen, Benutzernahmen oder so, für IoT-Geräte, für Konfigurationen halt. Das müsste halt irgendwo speichern. Dafür ist der Fischerselte-Speicher gut. Also gibt es startische IP-Adressen, und was ist denn das? Aber warum ist es verschisselt? Warum nicht unverschisselt? Es stimmt, das ist nicht nur die IP-Adresse. Wir haben viel über HTTPS-Zugangstaten geredet. Klein-Zertifikat, VPN-Schlüssel. Wir brauchen es, um eine VPN-Sitzung zu establishen. Diese Sachen sollen nicht konfigurierbar sein. Sollen konfigurierbar sein. Verschüßungen sollen das Schlüsselmaterial beschützen, die niemand anders lesen soll. Das habe ich jetzt. Vielen Dank für die Antwort. Ich glaube, wir sind jetzt leider durch mit der Zeit. Vielen Dank. Vielen Dank. Wir sind IPFIN. Wir sind IPFIN.