 So, the last speaker for this morning is Tramel. He is doing awesome research on bootstrapping more secure laptops or servers. And he's doing that basically by moving the RutoStraps into the right protected ground. Ich bin Ploy, und bei mir sitzt Heller Bade. Und gleich geht's los. Hallo, ich bin Tramel Hudson und ich habe zwei SignalInvestments. Und ich bin am Box zu untersuchen. Vor zwei Jahren habe ich meine Arbeit über ThunderStrike vorgestellt. Und das war die erste Firma-Attacke gegen MacBooks. Und das Jahr später war ich zusammen mit Sino Kowa. Diese beiden sind jetzt bei Apple und arbeiten in der Entwicklung. Und wir haben mit Phelan by Mac gearbeitet. Und diese Wavy Software-Plattform erlaubt es, uns sehr portable Angriffe zu machen gegen die Firma und auch Remote Angriffe. Also Remote Code Execution. Aber mehr als nur Zeugs kaputt zu machen, interessiert es uns, Zeugs auseinanderzunehmen und rauszufinden, wie es funktioniert und zu dokumentieren. Also, ich würde jetzt gerne über mein Projekt Heads sprechen. Das ist eine freie Firma. Und ein Bootloader für Laptops und Server. Ein Name ist eine Anspielung auf die Distribution Tails, also ein Stateless Linux, wenn man nicht will, dass man Spuren hinterlässt auf einer Maschine, auf der man was macht. Und hier geht es um das Vertrauen in die Maschine. Also, man will, dass die Daten, die man auf einer Maschine speichert, unverändert und sind. Also, man kürzt einen Schritt zurück. Wieso ist firmware Sicherheit so wichtig? Also, das ist der Code, der von der CPU ausgeführt wird, wenn man den Computer einschalten. Also, die erste Instruktion, die die CPU ausführt. Also, es ist eine sehr, sehr privilegierte Funktion, bei der man als Betriebssystem kompromittieren könnte. Es gibt eine Vielzahl von Talks, über interessante Angriffsvektoren auf Firmware. Also, ein, der mir besonders gefallen hat, war dieser hier letztes Jahr von DEVCON, von Intel Threat Research. Also, dort hat man gezeigt, dass firmware kann ein Hypervisor umgehen. Und sie haben gezeigt, dass fehlerhafte Firmware konnte ohne Brechtigung aus einer virtuellen Maschine den Hypervisor kompromittieren. Also, deshalb ist es sehr wichtig, dass Firmware-Fehler auch gepflegt werden. Also, nicht bloß theoretische Lücken. Also, man weiß, dass es bösartige Organisationen gibt, oder Hacker, die Firmware-Route-Kits verkaufen an alle die Zahlen, also inklusive staatliche Akteure. Und also, das sind wirklich realistische Gefahren. Und die sind im Boot-Rom eines Mainboards. Also, selbst wenn man das Betriebssystem neu installiert, oder die Festplatte tauscht, sind diese Bugs immer noch vorhanden. Und gewisse Hersteller tun sogar diese Route-Kits offiziell mit ihrem Firmware ausliefern. Also, es gibt welche, die Bloatware oder Erdware die das Betriebssystem installieren wollen, um machen das über Route-Kits in der Firmware. Also heißt, die Firmware installiert dann Zusätze zum Betriebssystem. Und diese Dinge haben halt Lücken, die auch von Angreifern ausgenutzt werden können. Also, ja, gewisse Hersteller haben genug schlechte Presse erhalten, dass sie ein Update veröffentlicht haben, dass diese Lücke schließt. Also, dass Benutzer selbst machen können, die können nicht die Firmware-Updaten genau wie zum Beispiel ihr das Betriebssystem oder eine Anwendung. Also, tatsächlich gibt es für die meisten Vulnerabilities in Firmware gar keine Patches. Ein Teil des Grundes dafür ist, dass die Firmware etwa 4 oder 5 Firmen weg ist vom End-User. Also, es gibt eine Referenzimplementierung von Intel, die heißt Tiano Core oder EDK2. Wenn da ein Backe fix wird, dann muss der von den Independent Bios vendors übernommen werden, den IBVs. Und diese verkaufen es dann an den Gerätehersteller. Also, sie müssen Release paketieren, der dann weitergegeben wird an den OEM, dann machte Hersteller Q&A gegen zig Motherboards und dann muss es noch vom Virtual Equipment Manufacturer rebrandet werden und dann zum Teil muss es durch den Betriebssystemhersteller noch, um überhaupt zum Endnutzer zu kommen. Und das heißt, oft erhalten solche Produkte gar keine Updates. Ja, hier gibt es eine Ausnahme, ich sehe das auf dem Bild da, Apple baut eigene Firmware. Und also in meiner Arbeit mit denen war ich sehr zufrieden, also dass die wirklich Patches für die letzten acht Jahre Hardware gemacht haben, dass es deutlich über dem, was alle anderen machen. Als EFI eingeführt wurde, machte es viel Komplexität. Und die Linux Community war eher skeptisch. Es war unklar, was genau der Wert dieser zusätzlichen Komplexität war. Es ist im Prinzip ein ganzes Betriebssystem, großen Code. Es ist nicht so, dass das Bios je besser war, das hatte auch seine Probleme. Aber es war klein, es war einfach, es hat eine Aufgabe, die hat es okay gelöst und es hat lange gedauert, bis UEFI überhaupt sinnvolle Unterstützung hatte. Und heute ist es so, dass Hardware ausgeliefert wird mit Bios und UEFI-Kompatibilitätsmodus. Das heißt, ihr habt eigentlich die Angriffsfläche verdoppelt. Und der Zustand der Welt heute ist, die Updates sind selten. Patches, wenn es überhaupt gibt, brauchen sehr lange, um durch den Prozess durchzukommen. User können selber nichts reparieren. Und wir können nicht reinschauen, was da passiert, weil das mit properter Software gemacht wird. Das ist ein ganz schlechter Zustand im Moment. Also firmware muss mit freier Software gebaut werden. Es muss flexibel sein, dass wir auf unser Systeme anpassen können. Es muss mit Software gebaut werden, die wir verstehen, dessen Komponenten wir wieder verwenden können, dass es breit getestet wird. Es muss reproducible sein, dass wir sicher sind vor Bild-Chain-Attacks und es muss measured sein. Also wir müssen sicherstellen können, dass das, was wir auf den Firmah-Chip flashen, das ist, was gebudet wird. Und das sind die Projekte hinter hats. Es baut auf Coreboot auf und ein Linux-Kernel in Rom. Und dazu noch ein Haufen Security-Research und Werkzeuge. Linux als Bootloader zu verwenden, ist nicht wirklich eine neue Idee. In den 90er Jahren, als es darum ging, die ersten großen Linux-Cluster zu bauen, waren wir sehr unzufrieden mit der Inflexibilität von DHCP und PXE-Booting. Also mit diesen Problemen, die wir da hatten, haben wir diesen Supercomputer gebaut, der auf Platz 30, der Top 500 war. Mein Kollege war auch am Bauen von großen Clusters da und er hat die folgende Beobachtung gemacht. Das BIOS listet die ganze Hardware auf und am Ende findet es den Linux-Kernel. Und wenn man den Linux-Kernel nimmt, macht das nochmal eine ganze Inventarisierung der Hardware. Er fragte sich, wieso machen wir das zweimal? Und seine Idee war, eine Version von Linux zu bauen, die aus dem Rom läuft. Er hat das ganze Projekt Linux BIOS genannt. Und das wurde dann eingesetzt an diesem Eincluster, der drittschnellste Cluster 2003. In 2008, das Linux BIOS wurde grübe refactored und wurde zu Coreboot umbenannt. Und Google hat Coreboot auf den Chromebooks eingesetzt. Und zu diesem Zeitpunkt, das einzige, weiß das einzige, x86-basierte, nicht UEFI Notebook, das man kaufen konnte. Und sie wollten die Konfiguration auf den Chromebooks verschließen. Und Ron ist dann zu Google gegangen in 2007 und hat an diesem Coreboot-Projekt gearbeitet. Coreboot hat drei Stufen, durch die es geht, wenn es die Maschine startet. Und DSS ist ein kleiner Stück Assembly. Und ein moderner Laptop butet immer noch im Real Mode mit diesen Assembly Instruktionen. Und das ist ein ganz kleines bisschen Stück Code. Und das stößt dann eine C-basierte Umgebung an. Und das geht in die ROM-Stage. Und das sind etwa 70 Kilobyte. Und das startet auch das TPM. Und das stellt eine statische Vertrauensbasis dar. Und das zusammen ist quasi die Trusted Computing Base. Also die vertrauenswürdige Stufe des Bootprozesses. Und das ist ein kleiner Bruchteil eines UEFI-Firmware-Teils. Und das stößt dann wieder um die RAM-Stage an. Und das enumeriert die ganzen Busse und findet die ganzen Geräte. Und es installiert auch den SMM-Händler für das System Management. Und das springt dann in die sogenannte Payload. Und das Ganze geht höchstens eine Sekunde. Und so kommen wir in die Payload, also den Benutzergenerierten Code. Auf dem X230 geht das relativ schnell, also in etwa zwei Sekunden. Und das bedeutet, den TPM-Staaten kryptografische Messungen machen. Und weil wir jetzt Linux haben, dann zu diesem Zeitpunkt haben wir die ganze Flexibilität, die mit dem mitkommt. Wir können da BootScripts implementieren und mit der Shell oder mit der C-Sprache-Laufzeit. Und Linux unterstützt natürlich ein Haufen Data-Systeme, Verschlüsselungsmethoden. Und das gibt uns die Flexibilität, all diese zu benutzen oder irgendwelche davon zu benutzen. Im Vergleich zu UEFI, was nur unverschlüsselte Data-Systeme unterstützt für den ersten Teil. Und es ist sehr, sehr beschränkt auf diese Einschränkungen. Es gibt ein Sprichwort in der Open Source Community, das genügend Leute schauen und alle Bugs einfach zu finden. Und Linux hat extrem viele Leute, die zuschauen, im Vergleich zu Edeka. Und da schauen sowohl gute als auch böse Leute drauf und finden Bugs. Und wenn wir sowohl die UEFI-Treiber als auch Software benutzen, die obendrauf läuft, verdoppeln wir die Angriffsfläche. Und wenn wir Coreboot bzw. Linux verwenden, haben wir unsere Angriffsfläche stark verringert. Dazu kommt noch, dass Coreboot und Linux natürlich Open Source sind. Das bedeutet, es ist möglich, die nötigen Treiber zu schreiben, die für die spezifischen Geräte, die man verwenden will. Und da kann man die ganzen Geräte selber unterstützen, muss sich immer auf die Verkäufer warten, auf die Hersteller warten. Und das dritte Teil von Hats ist ein System Call namens KXX, und das wurde von Eric Biedermann entwickelt. Das lässt den Kernel runterfahren und kann einen separaten, anderen Kernel starten. Und das bedeutet, man kann hier sehr, sehr schnell neu starten, wenn man einen neuen Kernel installiert hat. Und hier bedeutet das aber für uns, dass wir aus dem kleinen Anfangskernel den endgültigen Kernel starten können, ohne dass wir großen Overhead haben hier. Und das bedeutet, dass wir unser tägliches Operating System Betriebssystem hier laufen lassen können. Weil wir diese Bornshell haben hier, sind die ganzen Regeln in Shellscripts implementiert. In diesem Fall werden wir neue Kommandozeilenparameter reingeben, und hier werden wir sogar ein Hypervisor starten. Und all das kann sehr, sehr schnell passieren. Und das ist immer noch sehr sicher. Also, das sind die Teile von Hats, aus dem es gebaut ist. Und es gibt uns jetzt diese Plattform, auf der wir jetzt weitere Sicherheitsmassnahmen nehmen können. Und bevor wir jetzt dazu tief eintauchen in Sicherheit und Angriffsmodelle, ich muss jetzt hier sozusagen sagen, euer Angriffsmodell ist nicht mein Bedrohungsmodell. Und es gibt natürlich verschiedene Angreifer mit verschiedenen Levels von Effort, die sie reinstecken wollen, um uns anzugreifen. Und euer Sicherheitsmodell muss natürlich auf euer Bedrohungsmodell angepasst sein. Aber dass wir überhaupt solche Systeme bauen können, ist schon sehr, sehr toll. Letztes Jahr hat Johanna ein Vortrag gehalten über Firmware-Probleme in verschiedenen Geräten. Das sind fast allen Geräten, eigentlich jetzt weitere Firmware-Blobs drin sind. Und dass die alle mit dem Bootprozess zu tun haben, im Prinzip. Und man kann jetzt natürlich Peters Duchess Advice nehmen oder anwenden und einfach alles rausnehmen, was nicht unter unserer Kontrolle ist. Aber das ist halt, das schränkt einem natürlich stark ein. Und wenn ihr jetzt Hats installieren wollt, dann müsst ihr den Laptop aufschrauben, weil wir müssen das neue BIOS reinflächen. Und wer wir da drin sind, können wir natürlich auch Features verwenden, die kein ORFI-System verwendet bisher. Und da können wir ein Bit setzen auf dem Chip, was ein Teil des Chips zu einem Read-Only Teil umfunktioniert. Und das bedeutet, wir können da etwas hinterlegen. Und wir würden auch vorschlagen, dass man den Write Protect Pin vom Mainboard abtrennt. Und das bedeutet, dass man weitere Adapter da reinstecken kann. Und je nachher im Bedrohungsmodell kann man den Chip auch in Epoxy eingießen, um persistente Angreifer ein bisschen zu nerven. Und man kann den Chip vor anderen Geräten schützen, wie z.B. die Intel Management Engine. Und das ist halt eine sehr, sehr bedrohliche Prozesse erinnert hat des Prozessers. Und da haben wir ja auch schon Sachen darüber gehört. Und Igor Skocinski hat die Fähigkeiten von dieser Management Engine detailliert. Da drin läuft quasi ein oparkerproprieter Blockcode, den eigentlich nur Intel kennt. Und das kann überall in den Speicher schreiben. Es kann von Video lesen. Und es hört auf dem Netzwerk mit, selbst wenn das System ausgeschaltet ist. Also das im Prinzip ein Rootkit im Chipset. So nennen es gewisse Leute. Also ja, das hat mich natürlich nachdenklich gestimmt. Und wie baut denn Intel seine Firma Engine? Also wir können eigentlich für diese Management Engine Firma schreiben mit eingeschränkter Funktionalität und die ganzen Rootkits Funktionalität entfernen. Und so kommen wir von den 5 Megabyte-Firma auf 40k runter. Und dann ist nur noch die CPU Initialisierungsroutine da drin. Also wir wissen nicht genau, was das macht, aber wir wissen jetzt, dass auch keine Java-Virtual-Machine mehr, viele Geräte-Trieber sind weg. Also wir haben das erfolgreich gemacht mit X220-Think-Pads, also in den Skylake-CPUs zum Beispiel. Und wir haben das auch mit modernen Geräten gemacht, wie mit dem Chromebook. Also das ist natürlich toll. Es erlaubt uns von diesen alten Think-Pads wegzukommen zu neuerer Hardware. Also die Management Engine ist nicht das einzige Gerät, das den Buu-Prozess stören will. Also wieder Johannes hat uns gezeigt, da gibt es noch weiteres, das uns Sorgen machen wollen. Es gibt diese UEFI Protection und es gibt diese IOMMU in der VTT-Erweiterung. Und seit sie diesen Guide geschrieben haben, gibt es keine UEFI-Firmware, die von der IOMMU nutzen macht. Aber man hat diese Firma und die wird geladen, wenn man die Maschine einschaltet. Und bei Linux wird das verwendet. Also man hält diesen DMA-Schutz gratis dazu, wenn man Linux im Rom verwendet. Eine andere Möglichkeit, wie Geräte mit dem Buu-Prozess stören, ist mit Option-ROMs. Also man hat Geräte, ein Gerätetreiber. Und dieser Code hier kann zum Beispiel Passwort auslesen, weil die Tastatur abhören kann, die Tassenanschläge. Im 2007 wurde das zum ersten Mal dokumentiert bei Black Hat, dann von Snare im 2012. Und dann nochmal bei meiner Arbeit mit Thunder Strike. Und seit letzter Woche ist endlich ein offizieller Fix für diese Lücke veröffentlicht worden. Also Leute, die Core Boot verwenden, haben das als Option. Also man kann sagen, ich bin besorgt über diesen Angriff und lass mich diese Funktion abschalten. Also es kann sein, dass das natürlich die Funktionalität irgendwo nützlich in Ort einschreckt, aber das kann man halt testen. Also das kann man rausfinden. Und wenn man jetzt Linux bootet, dann hat man keine Option-ROM. Alles funktioniert mit Linux einen Gerätetreibern. Also man hängt nicht ab von den eingeschränkten Funktionalität, die Option-ROMs möglicherweise bereitstellen. Also wir haben jetzt unsere Bausteine, haben hoffentlich den Boot-Prozess geschützt. Der Kernel, der jetzt läuft, ist hoffentlich der, den wir meinen, den wir leuchten. Und wie können wir jetzt die Geheimnisse schützen, die auf der Maschine sind? Also ich bin Fan vom TPM. In der Freien Software-Community ist das aber nicht so gerne gehört. Den TPM-Chip haben wir nicht wirklich gerne, weil ja, eine Hauptfunktion der Chips ist halt DRM oder andere Dinge, die der Benutzer eigentlich nicht will. Aber wir können den verwenden für etwas, das wir wollen. Also wir müssen nicht DRM damit machen. Aber wir können unsere Secrets schützen. Und das funktioniert so. Also es überwacht, was für Code ausgeführt wird, während das System boot. Und es gibt diese PCR-Register. Und da werden Hashes abgespeichert, vom Code ausgeführt wird. Und das kann man erweitern, indem man diese Hashes Stück um Stück erweitert. Ein neues Zeug dazu herrscht. Und dann kann man sicherstellen, dass nur der Code, den wir ausführen wollen, tatsächlich läuft. Und der TPM wird dann zum Beispiel nur die Festplatten-Verschlüsselungskie öffnen, wenn bisher Code gelaufen ist, denn wir da haben wollen. Also man kann zum Beispiel, selbst wenn jetzt jemand, die nicht schreibgeschützten Stellen des Roms überschreiben kann, dann wird das Festplatten, die Festplattenverschlüsselung, nicht anlockt, weil sich der Hashes geändert hat. Und also hier sehen wir noch, dass wir da auch ein Passwort eingeben können. Und es ist limitiert, dass man nicht belebigt, viele Versuche das Passwort zu erraten machen kann. Irgendwann wird die Firma einfach gelöscht. Und das heißt natürlich, es gibt auch eine Möglichkeit, den Schlüssel zu löschen. Also es gibt diesen Mits. Es gibt zwei Gruppen von Leuten, die Festplattenverschlüsselung verwenden, die den Kieferlorn haben und die, die ihn noch verlieren werden. Also was jetzt hier passiert ist, der Kieferl wird in mehrere Teile aufgeteilt. Also man kann die Schlüssel an seine Freunde vergeben, jedes Stück einzeln. Und wenn man alle Stücke hat, kann man sich den Schlüssel wiederherstellen. Also einfach so kann man den Kieferl packen. Das wären jetzt so Best Practices. Also jetzt die Header der Festplattenverschlüsselung im PCR sind auch Teil der Prüfsumme. Und wenn man das so macht, dann verhindert das gewisse Varianten des Evil-Made-Angriffs mit diesem Shellscript hier. Also wer trauen jetzt das System, der Code ausführt, denn wir denken, aber wie können wir sicherstellen, dass diese Maschine tatsächlich unsere Maschine ist? Also wie können wir sicherstellen, dass nicht jemand in mein Hotelzimmer eingestiegen ist und einfach mein ganzen Computer ausgetauscht hat? Das ist nur so aussieht, als wäre das mein, es gibt ein paar dieser Anti-Evil-Mades-Tool-Kits. Also man verschlüsselt ein Geheimnis und zeigt das nur an, wenn es noch die richtigen PCR-Registers sind. Aber da gibt es natürlich einen offensichtlich Replay-Angriff. Eine Variante war das Time-Based-One-Time-Password zu verwenden, um die Firma zu verwenden. Also man hat einen Test, der der User ausführt, um festzustellen, dass die Firma nicht modifiziert wurde. Also während dem Buten, beim Vermessen der ganzen Hardware-Komponenten, wird das TPM das Geheimnis nur freigeben, wenn die PCRs übereinstimmen. Also das heißt, der Kernel generiert den Zeitstempel und generiert dann diese Prüfsumme und diese vergleiche man dann mit, was man zum Beispiel auf einem Telefon mitbringt. Das ist eine gute Idee. Und erneut hier seht ihr die Implementation als kleines Shell Script. Also das heißt, dem TPM rauslesen, das anzusehlen und dann den Hash auszugeben. Das erlaubt uns auch einen Übergang zu machen vom TPM Statischen Trust-Pfad zu einem TPM-Key mit GPG signiert. Also das hier ist, der Key ist hier auf einer separaten Hardware, der nicht irgendwie abhängig ist von der hauern eines zufälligen Herstellers, der ein Chip in den Computer steckt. Also dann kann man sich sicher sein, dass diese Hersteller nicht die Boot Scripts umgehen können. Also hier in diesem Script seht ihr, wie wir GPG verwenden, um zu verifizieren, dass das In-it-Erde und der Kernel wirklich nicht modifiziert wurden. Es benutzt dazu die TPM Counter, um zu verhindern, dass man ein Rollback macht. Also zum Beispiel, dass man den Kernel auf eine alte Version zurückrollt aus der Vergangenheit, die möglicherweise ein Fehler hat. Also das stellt sicher, dass wirklich das OS läuft, dass wir am Laufen haben wollen und stellt auch sicher, dass da niemand das durch eine verletzliche Version ersetzt hat. Der PGP Key erlaubt uns auch, diese Idee zu nutzen, die wir in Android finden. Das heißt DM-Verity, also ein nur erlesbares Rootfall-System. Also man herrscht die ganzen Blöcke, dann herrscht man die ganzen Hashes alles zusammen bis zu einem Root-Hash. Und dieser wird dann signiert. Und das stellt, kann der Kernel sicherstellen, bei einem Lesezugriff in logitmischer Zeit sicherzustellen, dass diese Daten signiert sind. Das heißt, es ist nicht nur ein Read-Only-Datei-System, sondern gibt uns die Zuversicht, dass da nichts manipuliert wurde. Wenn man so ein Betriebssystem ausführt, hat es sich vor allem konzentriert, wie man vom Bootprozess in ein sicheres OS übergehen kann. Cubes macht etwas Ähnliches. Und es gibt Leute, die sich um solche Security-Sachen kümmern, die kennen das vielleicht schon. Und für das in Ihrem nächsten Release werden Sie, werden Sie, das wird es erforderlich sein, dass die Maschine ein Open Source, also ein Core Boot zum Beispiel, Bootloader hat. Und ich habe, die haben etwas genommen und haben das modifiziert, dass mit diesem DM-Verity-System funktioniert. Und so kann man dann diese Konfiguration festhalten, sodass niemand mit der Konfiguration rumspielen kann und diese verändern kann. Und das erlaubt einem dann, diese Sachen im Betriebssystem zu flicken. Und so kann man, hier kann man dann auch verifizieren, dass man die richtige Version hat. Und für das braucht man diese reproducible Bild. Und daran sind wir jetzt gerade am Arbeiten. Wir haben auch ein paar Werkzeuge gebaut, die einem erlauben, die Initial RAM-Disk richtig zu bauen. Und wir hoffen, dass andere Linungsdistributionen das jetzt dann auch anfangen zu benutzen. Alle unsere Commit-Sync kryptografisch signiert. Und wir hoffen, dass GitHub da nicht irgendwie anfängt, etwas reinzuschieben, das nicht signiert ist. Gut, das ist, wo wir jetzt im Moment sind. Und das ist eigentlich noch sehr, sehr im Beta, aber man kann es schon verwenden. Es gibt noch ein Haufen Sachen, wo man noch Research machen kann. Und zum Beispiel bei den Chromebooks kann man, wir müssen Coreboot auch noch zu weiteren Plattformen portieren. Ich arbeite auch daran, Coreboot zu Server-Plattformen zu migrieren, portieren, damit man Cloud-Hosting sicher machen kann. Und Server-Motherboards haben ein ganz anderes Bedrohungsmodell als Laptops, die haben zum Beispiel ganz viele solche Chips, die weitere Firmen darin haben, zum Beispiel das Open-BMC-Projekt, was ein Open-Source-Management-Controller-System bauen will für Server-Mainboards. Und das Open-Cloud-Projekt versucht Bare-Metal-Clouds zu bauen. Und ich bin da vorsichtig, aber optimistisch, was eine Umgebung bedeutet, die es einem erlaubt, mehr zu kontrollieren. Es gibt ein Haufen Issues auf GitHub, und bitte helft doch mit, wer kann und fühlt euch inspiriert dazu, da auch zu helfen mit dieser ganzen Sache. Und wenn ihr euch dafür interessiert, dann werde ich heute später und später in der Woche auch noch beim Coreboot-Assembly zu finden zu sein. Und die könnten euch zum Beispiel helfen, Coreboot auf einem Laptop zu installieren. Das Source Code für Hats ist auf GitHub, seht ihr hier die URL. Und eine Version von diesem Vortrag ist bei dieser URL zu finden hier. Und da ist der Text quasi auch noch mit drin. Und ich hoffe, ihr könnt euch begeistern für Open-Source-Firmen, wie ich das habe. Wenn jetzt noch jemand Fragen hat, dann stellt diese jetzt. Vielen Dank für diesen spannenden Vortrag. Haben Sie Tipps für uns, die keine Coreboot-Kompativen kaufen? Ja, kauft ihr ein Chromebook. Es ist natürlich schwer, der Publisher ein Firma zu trauen. Also es gibt halt Leute, in Situationen, in denen wir trauen müssen. Wir müssen Intel zu einem gewissen Grad trauen. Intel ist verantwortlich für die CPUs und Großteile Firmware. Je nach deinem Angreifermodell ist halt unter Umständen die Firma ein großes Risiko. Also unter Umständen reicht es halt, einige Dinge zu tun, die Peter Studger vorgeschlagen hat. Also zum Beispiel den Schreibschutzpin abknipsen oder vielleicht Dinge zu entfernen, die möglicherweise gefährlich sind. Also ja, schau dir sein Guide an für Hardware-Sicherheit. Ich habe mich gefragt, ob du auch ARM unterstützen wirst oder ist es nur für Intel Laptops? Bei ARM gibt es viele Vorteile, wenn man die als CPU hat. Man hat da nur 20 Jahre Legacy und die Präposition ist viel einfacher. Also man muss sich irgendwie Real Mode und Long Mode und Paging und so weiter, diese ganzen Schritte durchmachen. Der Nachteil bei ARM ist, dass der Bootcode auf dem Chip ist und nicht unter der Kontrolle des Users. Aber viel dieses Bootcode ist zum Glück relativ simpel und bei einigen kann man eine Hardware-Route-of-Trust sicherstellen. Aber ja, so auch so, dass man den Chip neu starten kann, das scheint greifbar zu sein. Die Frage ist, kann man da das Boot nersetzen durch den Linux-Rom? Ja, ich nehme an, ich werde da in Zukunft noch weiter drüber sprechen. Und wenn jetzt Coreboot oder Libreboot eine Plattform unterstützt, wird dann Heads auch automatisch funktionieren? Ja, genau. Also Heads ist ein Payload für Coreboot. Also wenn Coreboot läuft, dann ja. Thank you. Coreboot hat Blobs drinnen, zum Beispiel binary Blobs von Intel mit den ganzen Firma Support-Paketen. Wie können wir Coreboot sichern mit all diesen Sachen? Intel FSP ist natürlich Sicherheitsbedingung. Das ist das Firmware Support Package. Wir benötigen den Speicherkontroller zu initialisieren bei modernen Intel CPUs. Auf älteren CPUs, wie zum Beispiel Sandy Bridge und Ivy Bridge, bei den Coreboot und Libreboot funktionieren, da kann man das den Speich initialisieren ohne diesen FSB. Wenn man sich jetzt aber anschaut, was Coreboot macht, eine neuen Plattform, dann scheint es einfach, ein paar Register mit bestimmten Werden zu überschreiben auf diesem Plattform. Moderne Speicherkontroller sind so kompliziert, dass Intel ist nicht gewillt, diese zu dokumentieren, also ohne NDAs. Es ist also sehr schwer, Speich initialisieren zu schreiben für die. Das ist 100% freie Software erst, aber wir können sicherstellen, dass der FSB measured ist und nicht manipuliert wurde. Wir können auch anschauen, was der Zustand der Dinge ist, die es einrichtet und das in unserem measured Boot mitenterieren. Obwohl es nicht komplett frei ist, das einzige komplett frei System, das ich kenne ist Banis Novena Laptop. Auf all diesen anderen kann man immerhin feststellen, dass es nicht manipuliert wurde vom ursprünglich installierten Zustand ausgehen. Das ist ein tolles Projekt und ich möchte fragen, warum du gewisse architektonische Entscheidungen getroffen hast. Spezifisch, warum hast du kein BST-Colonel gewählt, was ich normalerweise als sicherer oder qualitativ hochstehender anschaue und warum hast du nicht zum Beispiel Python oder Haskell als Sprache gewählt? Es gibt natürlich den Wunsch, Python zu unterstützen, aber das Problem ist, man ist sehr platzengeschränkt. Man hat mir üblicherweise nie vier Megawatt Platz und der Python-Interpreter ist halt schon alleine ein paar Megabytes. Und zu deiner Linux-Gegen-BSD ja, der KXX System Call ist ein zentralen Teil aus dieser Unterfahren eines Kernels und des Staaten eines anderen Kernels oder halt irgendeinem Multi-Boot kompatibel Kern ein notwendiges Feature wenn BST diese Funktionalität hätte, dann wäre es auch eine gute Wahl für dieses interne Programm des Bootloaders. Vielen Dank für den tollen Talk. Wie kann man hier Updates fahren bei Core Boot, wenn die Bineries die Ecription-Key messen müssen und diese Messungen dann ja anders sind und das System nicht mehr budden kann? Also mein Schlüssel in der TPM erfordert einen expliziten Schritt den Key aus dem TPM zu holen aktuellen Konfiguration und dann diesen wieder einzufügen mit der neuen Konfiguration. Also ein Vorteil eines Reproducible-Builds ist die Hashes aller Stufen der firmware können vorberechnet und veröffentlicht werden und die PCR-Werte können auch vorberechnet werden. Also man kann diese Schlüssel da ablegen mit den neuen Werten während des Updates. Also der Hats-Payload selbst sind wir noch dran am arbeiten also die Idee ist, noch eingeschränktes Hats zu haben also dass zum Beispiel nur ein USB-Tribe hat sodass man die neue Payload reinladen kann und an einem anderen Ort auf dem Chip zu installieren. Also ein Teil der noch fehlt ist das wieder einschließen der neuen Keys. Wie kann man diese ganze Hetsache auch auf Nicht-Think-Pads-Laptops implementieren? Think-Pads sind sehr verbreitet. Also ich meine, wenn ich mir jetzt hier die Halle anschaue sieht man sehr viele Think-Pads. Und ja, die Corebook-Community hat sich sehr stark auf Think-Pads fokussiert. Neben Think-Pads hat man auch noch die Hetsache dass es nicht wirklich viele Geräte die Corebook unterstützen. Also ich hoffe, dass sich das ändern wird in Zukunft, also dass auch die OEMs merken dass es wertvoll ist, wenn man das unterstützt. Also ich meine, das ist auch eine Spalmaßnahme für die und eben es geht auch um Freiheit. Also die Schwierigkeiten Coreboot auf einem Plattform zu tun, also ich selbst habe das nicht gemacht, aber ich nehme an die Leute an der Coreboot, dass sie mir noch das sicher gerne Auskunft geben. Planst du? Das Schuldige, das habe ich nicht verstanden. Wie geht es dir? Wie geht es dir? Wie geht es dir? Wie geht es dir? Das Schuldige, das habe ich nicht verstanden. Also ich habe die Frage nicht verstanden, wie können wir die PCI ersetzen? Das Corebook hat open source easy. Also Teil davon, das Corebook zu bauen, Coreboot zu bauen, heißt man muss den ARM-Cross-Compiler installieren um die easy zu bauen. Also Corebook hat ein sehr elegantes Protokoll und das easy, der CPU sagt, dass tatsächlich die Firma laufen soll. Auf einem Plattform müsste man da noch deutlich mehr Zeug rausfinden. Also viel der easy Chipsets, Datenblätter, also man kann da durchlesen und rausfinden, wie die funktioniert. Und viele davon haben updatebare firmware, also zum Beispiel, wenn es ein Modul im ThinkPad Bios gibt, dann muss man rausfinden, wie das genau funktioniert, damit wir das machen können. Wenn man, also ihr habt jetzt ein funktionierender Prototyp auf einem ThinkPad. Okay, wir können jetzt ein open source easy auf den ThinkPad machen. Sorry, I don't understand your follow up. Okay. So, wenn man einen funktionierenden Prototypen auf ThinkPad hat, wirst du die momentanen open source easy oder planst du deine Arbeit auf anderen Plattformen zu erweiten? Also im Moment habe ich selbst keine Fortschritte beim ThinkPad easy gemacht. Ich habe mir das angeschaut, weil ich eine angepasste Tastatur habe, die halt ein anderes easy benötigt, aber ich meine da im Sinne von offener Forschung habe ich da noch nichts wirklich gemacht. Zwei Fragen aus dem IRC. Planst du systemd zu benutzen im Bootprozess? Und das andere ist, so, wenn man jetzt ein Laptop-Neuflash mit dem Hardwareflasher, kann man das dann auch softwaremäßig updaten? Also im Moment kann man nachher updaten mit großem Risiko, weil man das Flash mit Schreibmöglichkeit belassen muss. Also man kann dann später das auch noch umflaschen. Also wir sind immer noch am entwickeln eine Möglichkeit für Software-only firmware-Updates. Zu anderen Fragen, also ich habe gesagt, wir sind ziemlich knapp mit Platz dran. Wir wollen keine großen Anwendungen da reintun, wie zum Beispiel SystemD.