 Liebe Leute, willkommen zum Vortrag Secure Boot vom Christian Biedl. Christian ist alter Internet-Hase, GPN-Hase und auch Debian-Developer und wird uns ein bisschen was erzählen über Secure Boot. Secure Boot, das war doch das alte Ding, das sonst immer dran gehindert hat, die Kernel-Versionen zu installieren, die wir wollten, das hat man dann schnell ausgeschaltet. Inzwischen ist es essentieller Teil der Chain of Trust, wenn ich meinem Kernel vertrauen will, dann muss ich auch dem Ding vertrauen, dass mein Kernel lädt. Und wie das mit UEFI Secure Boot jetzt im Konkreten funktioniert, das wird uns der Christian erzählen. Danke, bitte. Danke schön, kurz runterkommen. Wenn ich einen Vortrag halte, dann gibt es da meistens immer eine Geschichte dazu, die zu diesem Vortrag geführt hat. Das ist diesmal nicht anders. Ich arbeite hier in Karlsruhe bei einer Firma. Den Namen kann man keineswegs irgendwo lesen. Wir stellen neben einigen anderen Dingen nichts weniger her als eine Linux-Distribution. E-Lux hat man nie gehört, wir sind keine Allzwecks-Distributionen, so wie die Großen bekannten, sondern wir haben einen ganz speziellen Einsatzzweck, nämlich ein Find-Client. Find-Client, kleine, meistens auch tatsächlich wirklich sehr kleine Rechner, die in großen Verwaltungen und Betrieben zum Einsatz kommen, mit vielen, vielen Arbeitsplätzen. Da hat man immer das Problem 100.000 Rechner, wie soll man die alle administrieren. Und die typische Antwort mit dem Find-Client ist, die Leute, die an dort arbeiten, verwenden sich, ohne dass sie es wirklich merken, zu einigen wenigen zentralen Maschinen über irgendein Remote-Protokoll. Und die Geräte, die auf dem Tisch stehen, die können nicht allzu viel mehr, brauchen natürlich auch ein Betriebssystem. Dafür nimmt man aus guten Gründen gerne ein Linux. Und genau das liefern wir. Bei der Weiterentwicklung unseres Produkts sind wir ziemlich Kunden getrieben. Wenn die Kunden zu uns kommen und sagen, wir hätten gern dies oder jenes, dann kommt da irgendjemand, ich glaube, das heißt aktuell Product Manager. Und wenn der dann sagt, ja, das wollen wir gerne haben, dann schaut als nächstes der Chef in die Runde und fragt so, wer macht das. Und das war natürlich pandemiebedingt ein Videokonferenz. Und dann gilt das alte Spiel, wer also nicht bei drei einem bedauerlichen Netzwerkausfall erleidet, der hat den Job und ich war halt gerade in der Küche und habe mir ein Tee gemacht. Also ist das bei mir gelandet. Und naja, also ich übertreibe es. Natürlich kannte ich das Thema Secure Boot schon. Ich habe das auch schon benutzt, war aber auch immer so mit Vorbehalten. Ja, das hattest du eben schon angedeutet, dass als das damals herauskam, waren sehr große Vorbehalte, würde Microsoft das benutzen, um alles aus der Windows auf seinen Rechnern zu verbieten und so weiter. Vielleicht kommen wir dann nochmal darauf hin in der Diskussion, aber grundsätzlich kann ich sagen, es ist bislang nicht passiert und im Gegenteil, Microsoft hat gerade für Linux Distributionen einen Wecker eröffnet, dass die mit aktivierten Secure Boot funktionieren. Das werde ich auch vorstellen. Ansonsten bin ich auch sehr dankbar. Also aus einem Thema einen Vortrag zu machen, heißt auch immer noch mal ganz, ganz tief hineinzutauchen, sich ganz viele Fragen zu stellen, Antworten dafür zu finden. Und ich gestiehe mal, ich habe bis gestern Abend eine deutlich andere Vorstellung von dem Thema gehabt. Die Nacht war also ein bisschen kürzer, weil ich nochmal einen sehr interessanten Artikel gefunden hatte und auch das Fazit sieht jetzt völlig anders aus, als es gestern Abend um die Zeit noch war. Aber das sind so die Erfahrungen, die passieren. Worum geht es also Secure Boot, wer wo da holen ist. Die Frage natürlich, was ist Secure Boot, wie funktioniert das eigentlich und da wir es ja auch nicht nur einfach verwenden, sondern auch selber in die Hand nehmen wollen, wie kann man es für sich selber nutzen. Ich beschränke mich jetzt mal, das kommt direkt aus der Anforderung vom Arbeitsplatz auf Linux und auf die 64-Bit Variante der üblichen PC Hardware. Secure Boot gibt es im Prinzip auch für andere Plattformen. Ein paar Sachen dürften völlig gleich sein, ein paar Sachen wahrscheinlich sehr anders. Ist hier nicht mit drin. Secure Boot, was ist eigentlich das Problem? Das Problem ist, dass auf die ein oder andere Weise irgendwelcher Code auf die Festplatte kommt, der da besser nicht sein sollte. Man kennt das als Computerviren und es gibt eine besonders gemeine Variante davon, die sich in den Bootprozess mit einklinken, die also zusammen mit dem Betriebssystem sogar vor dem Betriebssystem gestartet werden und auf die Art und Weise sich sehr, sehr tief einlisten können, sich sehr, sehr gut verstecken können und auf die Art und Weise auch vor sehr vielen Erkennungen verborgen bleiben. Und dafür braucht man irgendwie ein Problem, dafür braucht man eine Lösung und Secure Boot versucht hier eine zwei wesentliche Dinge zu machen. Das eine kennt man relativ gut, das heißt eigentlich habe ich jetzt gelernt, sage ich mal Trusted Boot oder Verified Boot, wenn ein Rechner bootet. Gibt es das BIOS? Man sagt wohl heute firm wäre das Lernlich nicht mehr so, ich sage immer BIOS. Das sucht, wie konfiguriert wahrscheinlich auf der Festplatte nach ein Stück Code, den es laden und ausführen kann. Und wenn dieser Code bösartig ist, hat man schon verloren und deswegen macht man es deutlich schwieriger. Dieser Code muss in irgendeiner Form erfolgreich validiert werden und nur wenn das klappt, wird er dann auch wirklich ausgefügt. Die zweite Komponente, die für mein Eindruck viel weniger bekannt ist, ist Measured Boot. Da komme ich am Schluss nochmal deutlicher drauf. Die Komponenten, die zu einem Beinem Boot beigetragen haben, werden protokolliert und am Schluss muss das Ergebnis ein bekanntes sein. Detail ist dazu später. Ich bleibe jetzt mal relativ ausführlich bei dieser, beim ersten Punkt, bei dem Trusted Boot. Und ich habe den Eindruck, die allermeisten Leute da draußen, wenn sie von secure boot reden, meinen sie genau das. Und wenn ich die allermeisten Leute sage, dann geht das durchaus auch bis in Dokumentation und irgendwelche BIOS-Konfiguration. Bei Trusted Boot, wie gesagt, es geht darum, der Kernel oder was auch immer als erstes geladen wird, muss irgendwie validiert werden, sonst wird es nichts. Und es geht wirklich nur um diesen Kernel. Aus Linux Sicht fragt man nämlich sofort, da ist doch noch mehr. Kernel ist ja heikel, weil er die erste Komponente ist, die läuft mit den vollen Rechten, Ring 0 und so Sachen. Dasselbe gilt aber auch für die Kernelmodule. Was ist mit denen? Die sind eigentlich kein Thema von Trusted Boot. Aber da gibt es auch was dafür. Und genauso das ganze sonstige Userland, insbesondere auch das Early Userland oder Inlet RAM, sind nicht Bestandteil von diesem Trusted Boot. Das heißt, wenn man weiterhin irgendwelchen komischen Code auf das System eingeschmuggelt bekommt, der kann schon mal mit Rot leichten laufen, aber nicht unbedingt mit Kernel rechten. Das ist nicht das Gelbe vom Ei, aber schon mal besser als nichts. So, wenn ich sage Validierung, da hat man keine Gefangenen gemacht. Man greift auf kryptografische Methoden zurück, und zwar auf solche, die schon seit vielen Jahren unterwegs sind, die also gut in den Fingern liegen. Und auch die Werkzeuge recht vertraut sind. Also die Public Tree Cryptography Standards und die X539 Zertifikate. Wenn man damit handieren will, ist das letztlich alles irgendwelche OpenSSL-Kommandos, die man alle schon mal lieben gelernt hat. Bei der Frage Validierung ist das gut oder ist das nicht gut? Ist damit das Problem erst mal nur verschoben? Denn jetzt muss man eben fragen, wir haben irgendwo ein Code. Da ist eine Signatur dran. Ist die Signatur gut oder nicht? Fragen wir, wer hat die Signatur ausgestellt? Kenne ich den, vertraue ich dem. Das ist dieser Trust Store. Die Computer ist heutzutage so ein Trust Store mit eingebacken. In einem nichtflüchtigen Speicher, der kommt aus dem EFI-Konzept. EFI-Variablen kann man zur Laufzeit in einem heutigen Linux irgendwo im Parteisystem sichtbar machen und dann auch weiter untersuchen. Jetzt die Frage, wer ist denn so drin? Das entscheidet letztlich der Hersteller des Geräts. Aber in der Praxis, zumindest in der PC-Welt, sind zwei Keys drin. Die beide von Microsoft kommen. Der eine für die Microsoft-eigenen Produkte, der andere für andere Dinge. Konkret der Schimm, von dem noch viele Rede sein wird. Und wenn einem das nicht gefällt, kann man auch noch weitere Keys hinzufügen oder auch die bestehenden rausschneißen. Ich mache mal einen kleinen Exkurs. Wo ist das Ganze eingebettet? Und wo kommt es hier? Also das ganze Kind heißt offiziell UEFI Secure Boot. Hat auch schon zehn Jahre auf dem Buckel, ging schnell. Und erweitert UEFI. Was ist UEFI? Ich sag mal so die Leute, wo das Haar schon ein bisschen grau und schütter wird, die haben noch so diese alte Art wie im PC bootet kennengelernt. Und das ist konzeptionell aus den 70ern gewesen und die Welt hat sich weiter gedreht. Die Möglichkeiten sind gestiegen, die Anforderungen auch. Und man hat also vor auch schon bald 20 Jahren hier mal gründlich aufgeräumt und dabei insbesondere auch wie bootet eigentlich so ein System mal neu untersucht. Um das also mal wieder aufzurufen, man hat bei diesem Aufräumen das Partitionierungsschema erneuert, dieses GPT GUID Partition Table eingeführt, dabei so nebenbei noch die 2TB Grenze überwunden. Man hat neue Partitionstypen ermöglicht und einen eigenen speziellen eingeführt, mit dem Namen UEFI System Partition oder auch kurz ESP. Das ist sozusagen der Ersatz des alten Bootsektors, nur sehr viel besser. Also die Teile, denn man kann dort nicht nur einen Code ablegen, es ist einfach ein echtes Dateisystem, das gute alte MS-DOS oder FED-Dateisystem. Dort kann man einen oder aber auch mehrere Programme hineinlegen. Das heißt, man ist automatisch multibootfähig. Und das sind vom Format her MS-DOS Executables. Das tut aus Lehnungssicht alles so ein bisschen weh, weil das MS-DOS ist, aber es funktioniert. Und sie haben per Konvention die Endung UEFI. Hier gibt es, wie in der alten BIOS-Welt, es gibt einen Defrault von dem, wenn man nichts tut, davon wird gebutet, das ist ein bestimmter Pfad da drin. Wenn an das nicht gefällt, wenn man das ändern will, kann man im BIOS an der Bootreihenfolge arbeiten, die Einträge ändern, umsortieren und so weiter. Und auch eine hübsche Neuerung. Auch das sind wieder diese UEFI Variablen. Man kann das auch in einem laufenden System manipulieren und sehen. Auch wieder eines der Probleme, die in der damals alten PC BIOS-Welt entständig wiegetan haben, weil jeder Rechner irgendwie anders war und keine Möglichkeit hat, bei sich anzuschauen. Wie passt das jetzt hier rein? Wenn man also heutzutage UEFI basiert bootet, ist das so ein MS-DOS Executable, was da liegt. Man kann da im Prinzip direkt ein Kernel-Image booten. Der Kernel hat irgendwann gelernt, solche Images zu bauen, sodass sie alles so entsprechend erkannt werden. Eine entsprechende Option muss man dann natürlich setzen. Das mit dem Kernel ist sehr unhandlich. Man hat keine Kontrollmöglichkeiten und so weiter. Man kann wieder eine Bootloader dazwischen tun. Der Klassiker in der Stelle ist Grubb. Auch Grubb hat gelernt, entsprechend UEFI Executables zu erzeugen, die man dann dort entsprechend hinlegt oder hinlegen lässt. Und das dritte Typische ist der Shim, den ich schon einmal erwähnt habe, wo ich jetzt nochmal einen Verweis nach vorne mache. Der wesentliche Unterschied, wenn man jetzt mit Trusted Boot kommt, ist an diesen Programmen muss eine kryptografische Signatur mit dranhängen. Und was BIOS prüft, ist diese Signatur vorhanden, ist sie gültig, vertraue ich dem Herausgeber und dann erst geht es weiter. Wenn man das benutzen will, gibt es jetzt zwei Möglichkeiten. Also, nein, erstens, man muss es einschalten, wobei heutzutage etliche Rechner, neue Rechner, das meistens schon per Default eingeschaltet haben. Und wenn man sagt, der Karnel, den mir meine Linux-Distribution liefert, alle großen Distributionen haben inzwischen in Support nachgelegt, dann installiert man diesen. Das Paket heißt dann meistens irgendwie hinten mit Signed. ProTip, auch gleich den Grubbsign mitinstallieren. Und dann sollte es einfach funktionieren. Sollte, also das sieht dann so aus, meistens, das hängt jetzt ein bisschen von anderen Einstellungen ab, ich habe immer gesehen, dass dann so mitten beim Booten, ganz alleine so ein Text auf dem Bildschirm steht. If you stop, you if you secure boot is enabled. Oder wenn dann der Rechner hochgebooted ist und man in die Körnel-Meldungen reinguckt, auch der Körnel prüft nochmal seine Parameter ab und sagt in gleicher Weise, ja, ich habe hier ein Secure Boot gefunden und das ist soweit alles sauber hochgelaufen. Was macht man, wenn man seinen eigenen Körnel backen will? Und ich meine, wir machen unsere eigenen Körnel, ich mache übrigens auch privat meine, also dann komme ich hier nicht weiter, weil ein Körnel, der irgendwie selbst gebacken sonst woher kommt, der ist halt von einer Schadsoftware technisch nicht zu unterscheiden. Also ich komme nicht drum herum, ich muss dieses Spiel mitspielen, ich muss also selber meinen Körnel dazu bringen, dass das UE-Physicure Boot den akzeptiert. Und immer, wenn ich den Körnel sage, ist gemeint die erste Komponente, die geladen wird. Das heißt, ich muss mich mit OpenSSL-Kommandos auseinandersetzen, eigenes Schlüsselmaterial erzeugen. Ist dokumentiert, nicht, ist ein bisschen lästig, aber keine große Sache. Ich muss eine entsprechende Signatur an mein Körnel-Image dranhängen, dafür gibt es fertiges Userland, kriegt man auch hin. Und ich muss natürlich meinem System sagen, du dieser Schlüssel da drüben, der ist auch gut. Und das ist der Haaregetall. Gibt grundsätzlich zwei Möglichkeiten. Das klassische Konzept sieht so aus, dass man, ich sage das vorhin, man kann diesen Keystore, diesen Truststore erweitern. Das heißt als erstes mal viel Spaß, die gesamten Konzepte dahinter zu verstehen, denn natürlich, wenn man sie nicht verstanden hat, bedient man sie vermutlich falsch. Ich werfe mal einfach die Begriffe kurz hin. Es gibt einen sogenannten Database Key, eigentlich mehrere davon. Das sind genau das, was man erwarten würde, die Schlüssel, den vertraut wird. Es gibt eine Revocation, also eine Sperrliste. Keys, die irgendwie vermutlich mal kompromittiert wurden, die man also bitte ausdrücklich nicht haben will. Dann hat man noch vorgesehen, das sind so die üblichen Späße mit Keymanagement, dass jemand den Key vielleicht mal austauschen will. Dafür gibt es einen eigenen Key zum den Key exchange zu koordinieren. Und ganz obendrauf ist das Ganze nochmal vom Hersteller des Mainboards, des Rechners. Der hat nochmal seine eigene Key, um darüber die Trustchain zu beginnen. Wenn man das manipulieren will, erstens, wie gesagt, man muss es verstehen und zum zweiten, man muss bei einem Rechner ins BIOS gehen und dem sagen, da drüben hier auf dem USB-Stick oder da drüben in der Partition, da liegt was. Das nimmt bitte mal mit dazu. Kann man machen. Vorteil von diesem Ansatz, man hat wirklich die volle Kontrolle über alles, was auf diesem System vertraut wird. Nachteil ist, es ist komplex. Ich zeigte es schon, vor allem aber es skaliert überhaupt nicht. Jetzt komme ich ein bisschen aus nicht mal der privaten Welt, wo ich ein paar Dutzend Rechner habe, wenn es hochkommt, sondern aus der Firmenwelt. Wir wollen unseren Kunden etwas geben, dass die auf 300 oder auch 3.000 Rechnern installieren können. Wenn wir denen sagen, geht mal zu jedem Rechner hin und macht noch dieses Kommando, dann zeigen die uns zu rechten Vogeln. Also diesen Weg können wir bei uns nicht gehen. Ich sage auch gleich, die Diskussionen haben die natürlich auch nicht genommen. Nicht zuletzt, ich habe es natürlich ein bisschen mal probiert, mich um nicht damit vertraut zu machen. Man hat sehr, sehr viel Spaß. Jedes Bios ist immer noch ein bisschen anders vom Äußeren her und vom Federverhalten her. Wenn man irgendetwas Ungültiges hinlegt, ärgern sie alle einen sehr gründlich. Also so von wegen, ich habe hier eine Signatur. Dieser Signatur vertraue ich nicht. Ich habe es einmal gesehen, aber das übliche ist, der Rechner friert einfach ein, der Rechner rebootet und der Rechner fällt zurück irgendwie in irgendein Bootmenü und sagt dann überhaupt nicht, was mit es war. Wer solche UEFI-Bootmenüs schon mal sich ein bisschen angeschaut hat, die Bios meistens erlauben einem, dass irgendein kleiner Dateibrowser dritten. Man kann durch die UEFI-Partition durchwandern und sagen, dass das da drüben, das hätte ich gerne. Wäre irgendwie total praktisch, wenn er dann auch noch sagen könnte, ja, das hat eine gültige Signatur, nein, das wird nichts werden. Ist mir nie begegnet. Also viel ärger und von daher denke ich, wenn man nichts sehr hoch im Paraneuermodus ist, macht man sich keinen Spaß damit, macht man sich keine Freude. Die Alternative gibt es zum Glück und jetzt kommt der Schimm, von dem schon so viele Rede war. Schimm, das ist so ein englisches Wort, was ich auch immer gerne erst mal nachschauen wollte. Das ist aus Kontrast der Technik, also hier Abstandsscheibe oder Zwischenringen. Das ist, was irgendwo dazwischenlegt, wenn man ein bisschen mehr Platz braucht oder sich ein bisschen verbreitern wedelt, was auch immer. Und genau das ist es auch, es wird in den Bootprozess noch dazwischengeklemmt und zwar ist das die erste Komponente, die das BIOS laden soll und der Schimm ist so konfiguriert, dass er dann einen Grab sucht, lädt und dann seinerseits ausführt. Was bringt diese Indirektion nun? Dieses Schimm executable hat eine gültige Signatur von Microsoft. Das ist der am Anfang erwähnte zweite Key. Das heißt, ein BIOS wird den Schimm einfach akzeptieren und keinen Stress machen mit, wer ist das, ich kenne dich nicht. Und übrigens, bevor jemand fragt, das Ding ist open source, man kann also durchaus studieren, was es tut, es ist eh nicht furchtbar viel. Denn wie gesagt, es hat zwei Funktionen. Die eine ist, wie gesagt, den Grab zu finden und nachzustarten und die zweite viel wichtigere. Es schürt eine weitere Liste von vertrauenswürdigen Schlüsseln ein. Auf die dann die folgenden Stufen im Bootprozess ebenfalls zurückgreifen können. Das heißt, man muss nicht mehr irgendwo im BIOS herumpokunden, wenn man ein neues Schlüsselmaterial vertraut bekannt machen will, sondern man tauscht nur das Schimm executable aus, also eine Kopieoperation im Dateisystem deutlich angenehmer und deswegen machen es die Distributionen auch alle so. Und wir werden es auch so machen. Um es nochmal zusammenzustellen, das BIOS, wenn entsprechend der Bootloader konfiguriert, lädt den Schimm, validiert ihn und startet ihn. Das sollte immer klappen. Schimm lädt jetzt den Grab, der da irgendwo daneben liegt. Der Grab wird validiert und jetzt eben auch gegen den Store, den der Schimm mitgebracht hat. Und der Grab lädt dann über seine Konfiguration den eigentlichen Kernel und greift jetzt zur Validierung. Ist das ein gültiges signiertes executable? Halt nicht nur auf das BIOS zurück, sondern auch noch auf den Schimm. Und so wird es was. Was man gewinnt, man, die Verwaltung ist deutlich einfacher. Ich zeig noch gleich ein Beispiel. Und ich habe mich vorhin etwas ausgeranted. Fehlermeldungen, die bekommen man jetzt nur noch vom Schimm und vom Grab und die sind relativ konkret und hilfreich. Nachteile. Ich komme später noch ein bisschen auf Angriffenmöglichkeiten. Die Angriffsfläche wird natürlich jetzt ein bisschen größer, wenn man's Trusted Boot aushebeln will. Ist da ein Problemfeld mehr, an das man denken muss. Und ein zweites, ich war sehr überrascht, es gibt tatsächlich Hardware, wo dieser zweite Key von Microsoft im BIOS per Default aus ist. Bekannter von mir. Hat also sich ein bestimmtes Gerät gekauft. Wollte da Debian Secure Boot draufbringen, mit Secure Boot draufbringen, wunderte sich, dass es nicht geht. Und er hat das schon oft genug gemacht, bis er irgendwann im BIOS nochmal nachgeschaut hat und festgestellt, der Key ist deaktiviert. Dann aktiviert man den wieder und es tut, aber es war halt schon etwas unerwartet. So, ich sagte, das wird deutlich bequemer in der Verwendung. Ist es auch, man hat jetzt den nächsten Keybegriff, das ist der sogenannte Machine Owner Key. Und den macht man dem Schimm bekannt. Und ab dann wird der Schimm damit funktionieren. Das ist jetzt eben wieder so ganz analog, wenn ich mein eigenes Schlüsselmaterial einführe und erst mal mich überhaupt damit vertraut machen will. Gibt's ein User-Land, heißt Mocutil. Und das funktioniert nicht unmittelbar, denn ich meine, hier ist ein Problem. Wenn ich es zu einfach mache, dann muss ich immer befürchten, dass irgendwann eine Schadsoftware vorbeikommt und auf die gleiche Art und Weise versucht sich in das Secure Boot das Secure Boot auszuhebeln oder einen maliziösen Kernel irgendwie reinzuschmuggeln. Es ist also ganz bewusst ein bisschen schwieriger gemacht. Die Operation, die man macht, also hier ist ein Machine Owner Key, arbeitet ihn bitte ein. Die muss nach dem nächsten Reboot manuell bestätigt werden. So, hier hatte ich jetzt eigentlich eine Demo vorgesehen. Ich habe mir allerdings heute früh erfolgreich das Test-Setup soweit beschädigt, dass ich dachte, ich muss reparieren und da war die Zeit nicht da. Der Mensch von Welt hat für den Fall irgendwelche Screenshots vorbereitet. Also deswegen zeige ich mal die. Es ist natürlich nicht ganz so eindrucksvoll, ich weiß. Also hier nochmal das Kommando. Man sagt hier, mach bitte dem Schimm diesen Machine Owner Key bekannt. Das ist nur ein Zertifikat in einer bestimmten Form. Dann macht man ein, legt man ein Passwort fest. Das ist ein Einmal Passwort. Da muss man also nicht besonders hohe Ansprüche machen. Vielleicht trotzdem nicht 1, 2, 3, 4. Und dann passiert erst mal gar nichts bis zum nächsten Reboot. Und dann kommt man plötzlich so eine schöne blauen Bildschirm und die MS Source Experience aus den 80ern. Das ist der Schimm, der eben festgestellt hat, hier sollten wir was neues bekannt gemacht werden. Und das ist hier so ein hübsches Konsolenbasiertes Menü, wo dann, das ist hier der zweite Punkt, wo man dann eben gestätigt kann, ja, ich will da einen Key Enrollen, das ist der Name dafür. Den kann man sich hier nochmal anschauen. Streng genommen sollte man hier nochmal ganz genau gucken, ob es wirklich der Key ist, den man gerade da einsetzen wollte. Dann bekommt man eine Rückfrage, soll es der wirklich sein. Hier ist der wesentliche manuelle Schritt, man muss das Passwort nochmal eingeben als Bestätigung, ja, ich bin kein Roboter, keine Captures. Und dann hat man es endlich geschafft und ist im Spiel. So, und dann, ab dem nächsten Boot wird der eigene Körner, wenn man alles richtig gemacht hat, vom Schimm mit erkannt und läuft also sauber hoch. Nun haben wir als Firma jetzt an einem Ziel, wir wollen ja unseren Kunden unser Linux geben und zwar so, dass es einfach funktioniert. Und bei unseren Kunden ist immer das Thema große Zahlen. Also, wir können unseren Kunden nie sagen, nehmt da 3000 Rechner und arbeitet euch da mal von Hand durch. Die Kunden würden also, wenn sie sich mal die nächste Charge von 1000 Rechnern bestellen, möchten die aus dem Karton nehmen, irgendwo vermutlich Pixibooten und dann unsere Sachen drauf installieren und das soll natürlich bitte vom ersten Schritt an mit Secure Boot alles möglich sein. Man würde dem Hersteller sagen, wir wollen euch viele Rechner abkaufen, aber wir wollen, dass Secure Boot per Default gleich mal an ist, so was scheint zu funktionieren. Und das heißt, wir müssen dafür sorgen, wenn wir mit dem Schimm arbeiten, dass unser Signing Key im Schimm mit drin ist und das ist möglich, dann muss man zu den Leuten gehen, die hinter diesem Schimmprojekt stehen und sagen, wir wären da gerne mit dabei. Der Prozess heißt Schimmreview und ist, ich muss gestehen, ich hätte ihn gerne endlich mal angestoßen, aber man kommt natürlich zu nix für uns. Das ist aus meiner Sicht ein relativ offenes und ehrliches Verfahren, also man muss natürlich erklären, wer bin ich, was machen wir, warum wollen wir das tun und so weiter. Ich habe den Eindruck, wenn man an einer Organisation ist, ist das kein großes Thema. Als Einzelperson nehme ich an, werden Sie einem sagen, nette Idee und wenn man, jetzt wollte ich diesen alten Witz machen, ich lasse mal den Namen weg, also ich bin ein ehrlicher Gebrauchtwagenhändler und jetzt möchte ich auch Zertifikate machen. Wer den noch kennt, das war ein Mozilla Bug Tracker für elf Jahren. Das wird vermutlich eher ein bisschen schwieriger werden. Aber wie gesagt, es ist aus meiner Sicht ein sehr ehrliches Verfahren, keine besonderen Gemeinheiten. Man muss natürlich offenlegen, was machen wir, wie arbeiten wir und ansonsten verteilt, dass man den Schimm einmal selber übersetzt und dann übrigens auch den Grab. Den Grab signiert man mit dem eigenen Material, dann gibt man das alles dorthin und die melden sich früher oder später zurück. Das hat Zeit, weil ich etliche Monate gedauert, ich weiß nicht wie schlimmste Moment ist, ich hoffe es ist wieder deutlich besser geworden, damals waren ein paar technische Schwierigkeiten. Da wollen wir hin, da sind wir noch nicht, aber das wäre, wenn man eine Linus Distribution verteilen will mit Secure Boot aus meiner Sicht der einzig gangbare Weg. So, ein bisschen anderes Thema, ich hatte vorhin die Körnelmodule angesprochen. Wie gesagt, auch die Körnelmodule werden in ausgeführt mit höchsten Rechten. Das heißt, man muss unbedingt darauf achten, dass auch die Körnelmodule sauber sind und nicht jemand versucht auf diesem Weg sich in ein System irgendwie hineinzulisten. Das ist jetzt nicht bestandhaft von Trusted Boot, aber man hat trotzdem natürlich das Problem gesehen und Lösungen dafür gefunden. Ist zum Glück im Großen und Ganzen recht einfach, wenn man ausschließlich Körnelmodule in Körnelmodule verwendet, der Körnel hat eine Option, wo man einfach sagt, macht eine Signatur an die Module dran, man kann Material hinlegen, sonst dürfe sich der Körnel auch einfach ein eigenes. Wenn man Out of Tree Körnelmodule hat, also zum Beispiel noch NVIDIA, muss man die von Hand signieren, dafür gibt es fertiges Userland, ist alles kein Hexenwerk, muss man sagen. Und nicht zuletzt muss man dem Körnel sagen, wenn du ein Modul lässt, prüf bitte die Signatur. Netterweise gibt es auch noch den Testmodus, so prüfe die Signatur, aber wenn es nicht passt, meckern wir rum, macht trotzdem weiter. Ich kann aus Erfahrung sagen, hat sich sehr bewährt, wenn man mit den Sachen sich erstmal vertraut macht. Und kleiner Hinweis, es gibt mehr als eine Möglichkeit das zu prüfen. Also ich habe Körnel gesehen, wo diese Option ist und sie wollten Secure Boot sein. Man kann das wohl auch über irgendwelche Sachen aus der Secure Boot-Ecke entforschen. Ich gestehe, ich habe nicht weiter nachgesucht. Kommen wir zu einem anderen Feld. Richtig. Just with Boot, schön und gut. Und ich habe länger darüber nachgedacht und irgendwann beschlossen, das sieht eigentlich so aus, als könnte man das alles erschreckend schnell kaputt machen. Also, gut, wir sind alle Hacker, wir spielen zumindest gedanklich auf der anderen Seite. Hoffentlich nur gedanklich. Also, ich habe hier einen Rechner, der hat ein Linux mit Secure Boot. Wie komme ich da rein? Also, das Ziel sollte sein, ich will da meinen eigenen Körnel installieren und den damit erfolgreich das System hoch bekommen. Wie viel Aufwand brauche ich? Und ich sage gleich, wahrscheinlich werde ich Gutrechte brauchen, zumindest im laufenden System, wenn ich den Körnel austauschen will, denn die Boot-Pardition ist natürlich nur für Route schreibbar. Vielleicht muss ich gar nicht so viel machen. Erster Trick, oder nein, vorher der Satz noch, es gibt diese alte Böseansage, wenn jemand den Rechner in deiner Hand hat, dann ist es sein Rechner. Das wird mit Trusted Boot leider kaum besser. Also, wenn ich so eine Rechner habe, dann schaue ich, vielleicht mal ist das BIOS noch erreichbar, dann gehe ich ins BIOS rein, finde dort irgendwo die Secure-Beduktion, und bin schon fertig. Das war langweilig. Die Abwehr jetzt auf der anderen Seite ist ganz klar, wenn ich mit Secure-Bedukt irgendetwas machen will, muss ich ein BIOS-Passwort setzen und zur Erinnerung klassischer Password Policy 101, also jedes Passwort genau nur einmal an einem Ort und nur einmal in der Zeit. Wenn man 3.000 Systeme hat, muss man 3.000 verschiedene Passworder setzen. Aber ja, man hat vermutlich hoffentlich eh schon die Management-Lösung dafür. Zweiter Punkt, da werde ich jetzt ein bisschen vage, weil ich sagen muss, gestehen muss, ich habe es nicht nachpolziehen können. In früheren Zeiten gab es sehr oft, dass die Hersteller Default-Passwörter hatten für ein BIOS. Klarer Fall, wenn das im Support, wenn da jemand sagt, ich habe ein BIOS-Passwort gesetzt, ich habe es vergessen, was mache ich denn jetzt, und dann konnten die halt irgendein so magische Buchstabenfolge eintippen und dann war das wieder offen. Passwörter sind natürlich, also nennen wir das Kind beim Namen, das ist eine Hintertür. Diese Passwörter sichern natürlich irgendwann jetzt Netz. Ich habe ein paar Listen gefunden, wir haben in der Firma natürlich viele Rechner, ich habe mal etliche durchprobiert. Es ist mir bei keinem mehr gelungen, auf die Art und Weise, ein Passwort geschütztes BIOS noch zu erreichen. Vielleicht ist das also alles etwas aus der Vergangenheit. Punkt natürlich trotzdem, wenn der Hersteller eine Hintertür implementiert, der Hersteller des BIOS und sei es ein bester Absicht, dann kann ich nichts dagegen tun. Und können eigentlich nur hoffen, dass es nicht vorhanden ist, denn wir wissen es erst, wenn sie jemand gefunden hat. Das war jetzt ein bisschen fott, für ein Zeichen sie dauert, aber ich denke auch, es ist wichtig zu wissen, wo sind eigentlich immer noch Grenzen, an denen selbst wir scheitern. Lustigere Teile, Darks, hatten wir alle schon, wie ich habe hier die C4enomon mitgebracht. Das BIOS, also gemeint ist eigentlich die Referenzimplementation für Secure Boot, hatte Bugs, dann konnte Manuel in irgendeiner Art und Weise die Validierung über Tricks, über Listen und einen unsignierten, ungültig signierten Kernel booten. Es gab eine zweite Geschichte, das war vor zwei Jahren, das sogenannte Boothole im Grab Bootloader, das war ein ziemliches Drama, also da war der Bug im Grab mit dem gleichen Ziel. Das hat ziemlich viel Unruhe erzeugt, vor allem, es hat wohl mal niemand nachgezählt, es waren wohl 150 verschiedene, von den verschiedenen Distributoren signierte Grab Executables unterwegs, die man jetzt alle irgendwie aus dem Verkehr ziehen muss. Ich sagte vorhin, es gibt diese Sperrliste, da genau für diesen Zweck. Nur niemand hat gedacht, dass man die so intensiv brauchen würde, also die Sperrliste hat grob geschätzt Platz für vielleicht 300 Einträge und man hat, das war auch der Grund, warum der Shimji wie ohne Zeit lang wohl ziemlich blockiert war, man hat da jetzt ein bisschen umgeräumt, hat die Sperrliste etwas woanders untergebracht, so dass, wenn es, was wir hoffen wollen, nicht wieder passiert, aber wenn es passiert, dass man damit dann weiterhin noch zurecht kommt. Antwort darauf ist, dass man nicht um ein Bios-Update bemühen sollte oder natürlich auch, dass man sich bemühen sollte, dass der Grab aktuell ist, aber wer ein Unterstützter Distribution verwendet hat natürlich längstes Update bekommen. Wenn der Hersteller das Bios nicht mal unterstützt, ist man eigentlich in einem Zustand, wo man sagt, diesen Rechner sollte man nicht mehr dafür verwenden und dann hat man ein Stück Schrott. Ich schulde. Wenn man jetzt noch den Shim dazu nimmt, wie gesagt, es gibt noch ein bisschen auch in gleicher Weise, wenn man am Gerät dran sein kann, kann man es gewinnen. Also, hier kommt jetzt der vorhin erwähnte Wut, Zugriff ins Spiel, dann kannte ich also einen eigenen Kernel installieren. Das würde natürlich beim nächsten Boot hängen bleiben, aber wenn ich da jetzt noch den Shim sage, diese Signatur passt oder ganz analog kann ich auch sagen, dem Shim-Nee passt schon, frei verscheinend, alles grün, mach einfach keine Validierung. Kann ich dieses Kommando auslösen. Und dann natürlich beim nächsten Boot nochmal dafür sorgen, dass das auch bestätigt wird. Entweder ich sitze sowieso vor dem Gerät oder ich denke an der Stelle könnte man sehr schönes Social Engineering machen. Irgendwo in der Verwaltung, vierter Stopp ganz hinten, wenn man da so anruft und sagt, dein Rechner wird sich gleich rebooten und nicht wundern über diese komischen blauen Bildschirme. Und wenn da ein Kennwort eingefragt, ich nutze dich dadurch und wenn da so ein Kennwort eingefragt wird, gib einfach 1, 2, 3, 4, 5 ein und passt schon. Und jetzt würde erschreckend gut funktionieren. Und natürlich will ich keinesfalls empfehlen, das auch mal auszuprobieren. Ich bin der Meinung und das war jetzt der Fazit am Stand von gestern Abend, dass man über diese Probleme diese Schwachstellen nicht grundsätzlich flicken kann mit diesen Sachen hier. Man kann natürlich wie üblich versuchen, die Latte ein bisschen höher zu legen. Also insbesondere vermeiden, dass zum Beispiel, dass die Leute einfach so ohne Weitere Brutrechte haben können. Irgendwelchen Exploits gegen den Code auf der Maschine gibt es dann natürlich immer noch. Festplattenverschlüsselung ist für mich so selbstverständlich, dass ich eigentlich überhaupt nicht drüber reden mag. Aber ich sage jetzt nicht, dass irgendwas ein konkreten Stiller ist, hilft, aber es macht auf jeden Fall im Angreif schwieriger, wenn er jetzt so Sachen spielt, wie Festplatte ausbauen, kopieren, zurück wieder einbauen, ohne dass ich es merke. Das ist eine Schwierigkeit, nachzuvollziehen, was da drauf ist. Und ähnliche Sachen, die, wenn man nachdenkt, eigentlich auch selbstverständlich sind, boot in der Konfiguration einschränken wirklich nur auf diese eine Festplatte und nicht vom Netz und erst recht nicht von irgendwelchen USB. Und dazu gehört dann ein gleicherweise, dass man die Grabkonfiguration vernagelt. Also dass man was sehr hübsches, dass man die Kommandozeile bearbeiten kann. Das ist für die Bugging sehr nett, aber wer es nicht weiß, verrate ich es mal ohne Beleg. Natürlich kann man sich damit sofort eine Rutschelle auf dem Zielsystem holen und dann weiter einbrechen. Oder man macht jetzt noch etwas ganz was anderes und das ist dieses Measured Boot. Measured Boot, komischer Name, geht so. Wir haben ein Lockfile, das technisch durchgesetzt nur hinten etwas angehängt werden kann. Und wenn es unten steht, wird nicht mehr verändert. Das Lockfile, wenn der Rechner eingeschaltet wird, wird es gelöscht. Und ab dann, alle Komponenten, die in den Bootprozess mit drin sind, werden nacheinander in diesem Lockfile protokolliert. Komponenten sind so Sachen wie der Bootloader selber. Also das, was als AJA erstes von der Festplatte heruntergeladen wurde. Das wird der Schimm sein, das wird das Kernel-Image sein, das wird die Inniter-Design und übrigens auch die Bootparameter des Betriebssystems. Die Liste geht noch um einiges weiter, ist letztlich egal, das Ergebnis ist jedenfalls, wenn die Komponenten alle identisch gleich sind, dann ist dieses Protokoll, das davon geschrieben wird, auch gleich. Und auf die Art und Weise kann man mindestens feststellen, okay, die Komponenten haben sich gegenüber dem letzten Mal nicht verändert. Und wenn jetzt also jemand das Kernel-Image gegen irgendwas Bösartiges austauscht, dann ändert sich das Protokoll, ich habe es gesagt, es wird protokolliert üblicherweise die Haschsumme von den Dateien. Dann ändert sich natürlich das Protokoll bzw. mein Hasch, das Protokoll, man sieht dann einfach nur noch eine Haschsumme, ist dann anders und dann kann man erkennen, hier ist irgendetwas nicht in Ordnung und das ist ein Furchtbar schlechter. Das ist vorhanden, also Biosse und auch der Grab haben entsprechenden Support. Bleibt noch noch die Frage, wo hat man so ein schönes Lockfile und siehe da, jetzt kommt der nächste Bekannte, der so einen furchtbar schlechten Ruf hat, es ist das Trusted Platform Module. Da drin gibt es die sogenannten Platform Configuration Registers und per Konvention schreibt man an der einen oder anderen Stelle hinein die Ergebnisse wiederum auslesen und daraus Konsequenzen ziehen. Jetzt gebe ich zu schöne Idee Code, der so ein Protokolleintrag erzeugt, den gibt es reichlich, den gibt es im Grab, den gibt es im System Debo, den gibt es auch sonst wo. Was ich praktisch nicht gefunden habe ist Code, der diese Validierung dann auch tatsächlich durchführt und entsprechend Aktion entgleist. Ich nehme ihn gerne. Ich habe nur eine Sache gesehen, es gibt hier ein bisschen ein Problem, es gibt den erwarteten Wert und den tatsächlichen Wert. Man kann natürlich aus den erwarteten Wert irgendwo ins Dateisystem schreiben und dann nachgucken. Man muss halt nur befürchten, dass der Angreifer den Trick auch kennt und dann vielleicht diesen erwarteten Wert manipuliert und hat es ausgehebelt. Man könnte versuchen den Code zu manipulieren, der das validiert, das ist nicht ganz einfach, denn es ist vielleicht gar nicht so einfach. Ich erzähle mal eine Implementation, die ich gesehen habe, dass dieser Hash, also über das Protokoll am Schluss verwendet wird, als Passphrase für eine Festplattenverschlüssung mit Lux. Das ist sehr geschickt, weil dann nämlich der State in dem Lux drin steckt und sich nicht verrät, sondern einfach nur wenn der Lux, wenn Lux das aufentschlüsseln kann, dann war er richtig. Man hat die Daten unerreichbar und die erkennen, es ist wohl kaputt. Es ist wohl irgendwas schiefgegnt. So, Measured Root ist also sehr schön robust gegen viele, viele Angriffe, auch gegen diese Klasse, die da immer heißt Evil Maid, also das böse Zimmermädchen, das also im Hotel während ich irgendwie unter der Dusche bin oder beim Essen meinen Notebook aufeinander nimmt. Aber es macht es deutlich, deutlich schwieriger, denn man kann ja jetzt anfangen, in meinem System herum zu manipulieren, versuchen Dateien auszutauschen und so weiter, aber gut, dann bootet mein Rechner nicht mehr, ist auch nicht das Schönste, aber es ist zumindest keine Kompromittierung. Nachteile, deswegen habe ich das jetzt hier so ein bisschen ausgebreitet, es macht einen guten Knoten im Kopf zumindest am Anfang, bis man das vielleicht durch mehrfaches machen begriffen hat, ja, es funktioniert wirklich so. Und aus Erfahrung möchte ich warnen, das Ganze ist bei Design, sehr robust sehr fragil gegen irgendwelche Änderungen. Also Kernel Kommandozeile irgendwo noch eine Debackoption eingeschaltet, Bums das System steht. Neuer Kernel eingespielt, natürlich ist Recht, System steht. Man muss also bei jeder bewussten Änderung einen Fahrt haben und implementieren der dafür sorgt, dass dann also dieser Erwartungswert entsprechend neu eingestellt wird. Und wenn es wirklich eine verschlüsselte Festplatte ist, empfehle ich ganz dringend einen Plan B zu haben, dass man, wenn man der Gute ist, immer noch rankommt, auch wenn man sich vorne alles komplett zerschlossen hat. So damit komme auch schon so ziemlich zum Ende. Also ich habe vorgestellt, Trusted Boot Trusted Boot ist ein ganz guter Schutz gegen irgendwelche Viren, die gerne auch automatisch installiert werden und ich nenne jetzt keine Namen. Ich denke, es ist eine sehr gute Idee auf Betriebssystemen, wo üblicherweise alles als gut gemacht wird, auch im Jahr 2022. Auch wenn es nicht perfekt ist. Trusted Boot alleine schützt halt nicht vor böswilligen lokalen Zugriffen, das ist die erwähnte Evil Maid und es schützt halt auch nicht wirklich vor. Und diesen Begriff sollte man dringend häufiger verwenden, angewandte Sozialwissenschaft, also die Eindeutschung des Social Engineering. Wenn man auf einem hohen Paranoia Level spielt wird man um Measured Boot nicht herumkommen aber es legt die Latte für einen erfolgreichen Angriff sehr, sehr hoch. Also ich glaube, wenn man das noch aushebeln will, Modulobarcs muss man dann schon eine Regierungsorganisation mit 3 Buchstaben sein und großes Budget haben. Man widerlege mich gerne. Aber es ist ich denke, nach dem jetzigen Allgemeinen Stand der Technik wirklich etwas, was nicht so ohne weiteres zu knacken ist. Bleibt natürlich unterm Strich will man sich das wirklich alles antun. Ich bin so ein bisschen hin und her gerissen worden in der Vorbereitung des Vortrags. Ich habe ja hier einfach jetzt vorgestellt was bringt, was kostet's und bleibt letztlich die eigene Entscheidung. Beziehungsweise manchmal wird einem auch die Entscheidung abgenommen und kommt halt jemand mit diesem schönen Zettel, wo draufsteht Compliance und wenn die Compliance Anforderung sagt du musst secure boot machen, dann muss man es halt machen. Auch wenn man mehr oder weniger sicher ist, dass es im gegebenen Fall eigentlich nur Zeit- und Geldverschwendung ist. Aber so ist das Leben. Also bekanntlich security is hard. Let's go shopping. Danke für den großartigen Vortrag. Das war wirklich eine ganz tolle Einführung in secure boot. Und wir haben jetzt noch 15 Minuten für Q&A. Das heißt, wenn ihr eine Frage habt, bitte zeig's auf und ich bringe euch das Mikro, das mir sicher das Wok geben wird, das zu euch zu sagen. Danke. So. Glaubt du warst der erste dahin? Danke für die coole Übersicht. Jetzt hab ich auch ein paar Sachen mehr verstanden. Am Ende dieses measured boot, das ist so ein bisschen was wahrscheinlich am meisten jetzt die Leute so Lust drauf kriegen, dass man es wirklich so richtig sicher machen will. Und ich glaub das, aber der vorgestellte Ansatz nicht wirklich so gut, weil du hast da eigentlich kein Geheimnis in dem Schlüssel. Der Kernel ausgetauscht hat durch den eigenen Kernel. Nur noch den hash vom alten Kernel wissen, das Ding nachrechnen, was der hash, also das Testment ist und hat den neuen, hat den Schlüssel. Nee, der hash, also aus diesem Protokoll, der hash wird über das gesamte Protokoll gebildet. Genau. Und kann das da nicht einfach nachrechnen, wenn er weiß, was warten der Kernel bevor rausgetauscht wurde? Er weiß vielleicht den Kernel, aber weiß ja alle anderen Komponenten? Oder die du aufgezählt hast, ja, im EFI Partitionen finde ich doch den... Also mein Kenntnisstand, aber das ist jetzt auch nur gelesen, ist, dass noch deutlich mehr reingeht, zum Beispiel auch der Bios eigene Code im Uploader. Was bleibt Security through Obscurity, oder? Also ich glaube nicht, dass du so einfach nachrechnen kannst, wie der es aussieht. Ich habe drei Rechner mal nebeneinander gehalten und alle drei hatten einen verschiedenen hash, obwohl sie mit dem selben Kernel gebotet wurden und derselben Konfiguration. Also da gehen noch mehr Bits rein. Die Frage ist natürlich, was sind das für Bits und kann man die extrahieren und dann tatsächlich nachrechnen? Ich hatte so eine Erinnerung, dass man, wenn man eh schon dieses TPM-Modul hat, dass man das dazu bringen kann, den Schlüssel nur dann herauszurücken, wenn eine gewisse Konfiguration gerade läuft, dann wäre es ja nicht mehr sozusagen nur, die es nicht wissen, wie es berechnet wird und dann hätte man ja wirklich nur in der Konfiguration den Schlüssel. Hast du das bewusst, gibt es das oder habe ich es falsch im Kopf? So was habe ich auch im Kopf. Ich habe das hier mit Verwendung als Lux-Pass-Phrase, da steckte das mit drin, ohne dass ich es ausgesprochen habe. Und ich sehe hier ein paar Leute entnicken, vielleicht können die das einfach mal bestätigen. Vielen Dank, ich glaube, ich gehe weiter. Vielen Dank, es war wirklich sehr umfangreich. Ich stecke da auch ein bisschen tiefer drin. Nicht, weil ich die Kochen war, sondern die richtigen Freunde habe. Und zu den Geschichten gerade, die PCRs, die im TPM liegen, die haben unter anderem deshalb auch, was du auch gerade schon gesagt hattest, verschiedene Werte, wenn man dich mal drinstehen, weil einfach die Firma unterschiedlich implementiert ist. Und ja, es gibt halt so ein paar von diesen Registern, diese PCRs, was du auch schon gesagt hattest, die haben verschiedene Kombinationen, was wo am Ende landet als Messung. Das kann man sich jetzt so vorstellen. In einem von diesem Register steht erstmal ein Hash und per Konvention landen aber in einem Register mehrere Messungen. Wenn es das nächste kommt, dann wird der vorherige Hash mit eingebunden, plus die neue Informationen dazu und dann geht das so ein bisschen so weiter. So ein bisschen ähnlich wie CBC-Modus bei Verschlüsselung, wenn das jetzt so im Kopf hat. Ja, ansonsten vielleicht so zwei, drei weitere Hinweise für Leute interessiert sind. Was du gerade noch vermisst hast, was man mal machen müsste für die Prüfung, das kann in den Bereich Remote Attestation fallen. Remote Attestation heißt, man hat halt eine externe Partei noch, die mit involviert werden kann. Blockchain. Ja, Blockchain natürlich und mit Bitcoin kann man das dann bezahlen. Klassischerweise, was das klassisch ist, zeigt mir noch Richtung, wenn man jetzt in so einem Unternehmen mit 3000 Rechtern ist oder so, irgendwo ein Attestation-Server, der sich dann die ganzen Messungen sammeln kann von den ganzen Geräten. Also ähnlich, wie wenn man so Remote Logging hat oder so in die Richtung geht das so ein bisschen. Ansonsten, es gibt natürlich auch, wenn man nicht nur 3000 Rechner hat, sondern eher so ein bisschen mehr, dann kann man auch überlegen, einfach eigene Firmen zu machen und in dem Fall ist es einfach, weil man, wenn man bei der Zeit angekommen ist, wo ich jetzt gerade eher so drüber nachdenke, auch das Budget dafür vielleicht hat Ansonsten, was noch interessant ist, einmal ein Safeboot, was Trommel-Hatzen gemacht hat als Projekt, beziehungsweise das Hats-Projekt, was auch damit zu tun hat, eigene Firmen auszurollen und für mehr sprechen wir, glaube ich, nachher mal. Danke. Excellent Idee. Dankeschön. Zeigts nochmal auf. Ja, eine Frage, zwei Fragen. Gut, zwei Fragen, dann kriegt sie vielleicht doch auch noch mehr Zeit. Sonst machen wir eine Übung, wie überlege ich mal kurz, eine Frage, die auch anderen Leuten noch Zeit lassen, wo warst du? Bast, bitte. Ja, ich frage mich so ein bisschen, was ist denn jetzt der praktische Anwendenzweck von Safeboot? Also ich glaube, in der Wirtschaft wird das unter anderem mehr oder weniger erfolgreich genutzt, um DRM durchzusetzen, aber ich frage mich jetzt als Privatperson, wenn man jetzt festgestellt, wenn es mehr oder weniger physischen Zugriff auf mein Gerät hat, dann habe ich sowieso mehr oder weniger verloren, aber wenn ich jetzt annehme, wenn man gebraucht, um irgendwie einen neuen Connel zu installieren, dann kann er das jetzt durch Safeboot zwar nicht, aber dann hat er ja immer noch irgendwie, kann alle meine Daten lesen, modifizieren und so. Also welches Attacks-Szenario unterbindet man jetzt dadurch, dass der Angreffer keinen Connelcode ausführen kann? Er kann zumindest nicht sich über ein, das hieß mal Rootkit, ich weiß nicht, ob man das immer noch so nennt, er könnte sich zumindest nicht so einnisten, dass man nur noch mit sehr großen Schwierigkeiten in der Fälle identifiziert. Okay, ich denke mir halt nur normalerweise unter Linux ist das alles sowieso, ob der Usus-Bass so schlecht voneinander geschützt, dass man sowieso dann über X oder so alles mitschneiden kann. Aber... Also ich glaube, ihr habt es nachher noch genug Möglichkeiten, dass wir wahrscheinlich einfach irgendwann in den Flur hinausgehen und... Es war grüntlich auf die Wiese und bespricht das im kleinen Rahmen, das ist glaube ich so was der Nächste. Bitte. wurden eigentlich schon mal im Bereich von APTs Angriffe gegen measured boot beobachtet. Gibt es dazu jetzt, ich sag's mal, öffentliche fübere Frage? Ich hab die Frage nur teilweise verstanden, Akustisch, tut mir leid. Entschuldigung. Ist es also fortgeschrittener Angreif von beobachtet oder gibt es dazu noch keine Aufzeichnungen? Keine von denen, ich weiß, aber ich glaube, du hast irgendwie von dem Thema etwas mehr Ahnung, oder? Ja, ich komm. Also wenn die Kamera aus ist, gibt's die blutigen Details. So, wir haben noch Fragen. Hände rauf, wir haben noch Zeit. Jetzt hab ich, ja super. Ja, mich würde interessieren, inwiefern muss ich denn kommen oder was wäre die mögliche Attacke, wenn jetzt ein böse Aktor da durchkommt und sich da eintragen lässt. Ich muss gestehen, du erwischst wieder einen Punkt, den ich recherchieren wollte und nicht recherchiert habe. Wenn ich's richtig verstehe, schicke ich zum Shim-Review einen selbst übersetzten Shim mit meiner mit dem Zertifikat mit meinem Zertifikat drinnen. Und die validieren den Boot, im Sinne von können sie den Bit identisch reproduzieren. Dann machen die eine Signatur dran und schicken es zurück. Und dann habe ich ein Shimexecutable, das meinen Schlüssel versteht. Und wenn ich verstehe den Angriff so, dann würde ich jetzt dieses Shimexecutable einen bösen Kernel bauen, den damit signieren und das bei irgendeinem Opfer einschmuggeln. Das ist die Stelle, wo ich eigentlich nur hoffen kann, dass die Shim-Review vorher sehr genau hinschauen, wer das ist. Und natürlich, das ist ein Szenario, vor dem ich ein bisschen Angst habe. Denn wenn das passiert, ich möchte mal sagen, es wird passieren, man muss es merken. Im Moment, bis es wo es bemerkt wird, bis diese Zertifikate, dieses Shimex-Zertifikat wirklich in den Sperrlisten drin ist, aus dem Verkehr gezogen ist, in der Zeit hat man ein Problem. Das ist letztlich genauso wie wenn in der Welt der bekannten TLS-Zertifikate eine vertrauenswürdige CA ein böses Zertifikat ausstellt, so Google.Stern oder so was, egal. Nur, dass der Revocation-Mechanismus dort inzwischen deutlich besser funktioniert. Also, da mache ich mir ein bisschen Sorgen und ich habe keine Antwort dafür. Danke. Noch weitere Fragen. Wir haben noch ungefähr fünf Minuten oder so. Sonst habe ich vielleicht noch eine Frage. Bei der Verifikation nachträglich, wer schreibt denn in den TPN den Verifikationscode, schreibt das die Executable selbst, die da ausgeführt hat und kann die den ursprünglichen korrekten Wert hineinschreiben? Ich weiß nicht, ob ich die Frage verstanden habe. Also, der Punkt, also die Idee ist wohl, es kommt das BIOS und will, sagen wir, den Schimmladen, validiert den und dann schreibt das BIOS in das Protokoll, ich lade gerade den Schimm mit dieser Halssummer. Also, es ist die vorige Stufe dafür verantwortlich, dass der nächste Eintrag sauber erzeugt wird. Okay, das beantworte eine Frage perfekt. Sonst doch jemand. Ja, gut. Dann, vielen Dank. Dann machen wir jetzt das nach Glühendrausen auf den Gang. Ganz genau, ja. Vielen Dank. Vielen Dank. Vielen Dank. Ganz genau, ja.