 Und jetzt, unser erstes Gespräch hier heute, wird über Anti-Evil-Mate sein, dass wir uns herausfinden, wie wir es eigentlich machen können. Natürlich absurden Zeit in der Früh hier erscheinen können. Das freut mich sehr. Also mein Name ist Matthew Gareth. Ich bin ein Sicherheitsentwickler bei CoreOS. Und ich bin auch im Vorstand der Free Software Foundation. Und das interessiert mich sehr, also Sicherheit interessiert mich sehr, auch Low-Level Security, also wie es um die Plattform steht, bevor wir überhaupt Applikationen ausführen. Und ich möchte betonen, dass der Besitzer eines Computers immer in der Lage ist, sicherstellen zu können, dass er die Richtlinien, nach der ihr Software auf seinem Rechner ausgeführt werden, selbst entscheiden kann. Also Leute sollen freie Kontrolle über ihre eigenen Systeme haben. Ja, danke. Also es gibt hier von meiner Firma einen Büro in Berlin. Meldet euch bei mir, wenn ihr an solchen Sachen arbeiten wollt. Und die Frage, die wir heute bearbeiten wollten, ist, wie kann man wissen, dass der Computer vertrauenswürdig ist? Und in dem Fall meine ich, der Computer wird euch nicht verraten. Der Computer wird in der Art und Weise arbeiten, dass er euch nicht umgehen, eure Entscheidungen nicht imgehen kann. Und das Leben nicht für Leute leichter macht, die nicht ihr seid. Und wir haben gesehen, dass DRM dazu führt, dass Computer nicht das machen lassen, was ihr wollt, dass sie machen. Aber von einer Sicherheitsperfektive ist es wichtig, dass ein Computer eure Geheimnisse aufnimmt und auch in einer vertrauenswürdigen Art und Weise verarbeitet. Dass er also die Geheimnisse nicht irgendwie speichert und dann benutzt, um Daten über euch zu verteilen. Also wie entscheiden wir denn überhaupt ein Computer vertrauenswürdig ist? Und bis zu einem Zeitpunkt, wo ihr Geheimnisse im Computer tut, ist es im Prinzip unerheblich, ob er vertrauenswürdig ist. Da hat er keine Möglichkeit, euch zu schaden. Und Geheimnisse sind offensichtlich Sachen wie Passwörter, aber eben auch so Sachen wie eure History im Browser. Und im Wesentlichen alles, das ihr nicht komplett veröffentlichen wollt. Und ich werde über eine ganze Menge Sachen reden, aber eine komplett vertrauenswürdige Plattform zu bauen, dafür müsst ihr komplett am Anfang des Bootprozesses Vertrauen aufbauen, bevor irgendwelche Sicherheiten, bevor ihr irgendwelche Geheimnisse eingebt, muss der Computer in einem vertrauenswürdigen Zustand sein. Ihr müsst in der Lage sein zu sagen, ich vertraue diesem Computer. Und wenn das nicht wahr ist, wie kann man denn wissen, dass die Software, in die ihr eure Passwort eingebt, in eurem besten Interesse handelt? Und wenn es um freie Software geht, da können wir den Source Code anschauen, da können Leute den Source Code angucken, viele. Und das bedeutet, die Chance ist höher, dass viele Leute sich das angucken und sagen, ja, die Software ist vertrauenswürdig. Aber sobald es kompiliert ist, sobald es auf der Festplatte liegt, wenn jemand da die Software manipulieren kann, dann geht der Computer eben von vertrauenswürdig zu nicht vertrauenswürdig über. Also wenn jemand euer System auf euer System zugreifen kann und Daten verändern kann, dann seid ihr in dieser unglücklichen Position. Aber es ist sogar noch schlimmer, denn die Software läuft auf einem Kernel von einem Betriebssystem. Und woher wisst ihr denn, dass der Kernel vom Betriebssystem selber nicht modifiziert, die Software nicht selber modifiziert hat? Ein Kernel, der eine Backdoor enthält, kann das Verhalten von allen Programmen, die im Userspace laufen, verändern. Selbst wenn ihr sicherstellen könnt, dass eure Software selbst unverändert ist, dann kann der sich in der richtigen Art und Weise verhält, dann kann der Kernel, wenn er verändert ist, immer noch dieses Verhalten unterwandern. Und jetzt sagen wir mal, okay, ihr seid in der Lage, auch den Kernel zu verifizieren, zu überprüfen, dass der auf die Festplatte geschrieben hat. Wollt ihr wissen, dass der Bootloader nicht manipuliert wurde und der Bootloader kann dann alles beeinflussen, kann die Passphrase wegspeichern ohne euer Wissen. Der Bootloader, sagen wir mal, wir haben die Möglichkeit, den Bootloader zu verifizieren. Aber was ist mit der Firmware? Diese Firmware, die startet den Rechner, die kontrolliert so viele Low-Level-Sachen, wie den Kernel zu starten. Okay, und wenn wir jetzt alles gelöst haben, was dann ... Und dann haben wir natürlich noch die CPU, die den ganzen Code ausführt. Und wenn die CPU nicht vertrauenswürdig ist, dann ist dann natürlich auch keine Möglichkeit, die Firmware, den Kernel und auch der Passworteingabe nicht zu vertrauen. Wie man herauszufinden, wie man der CPU vertrauen kann, ist ein hartes Problem. Also ich ignoriere das jetzt in diesem Vortrag. Aber die Vertrauenswürdigkeit vom Rest des Systems herauszufinden, ist mehr praktikabel oder ... Und man kann es halt zu einem vernünftigen Umfang machen. Und Trusted Computant ist vor einigen Jahren auf der Bildfläche erschienen. Und es war klar, dass dies eine Infrastruktur ist, um sicherzustellen, dass ... Okay. Ich muss noch mal springen. Es ist eine Infrastruktur, die sicherstellen kann, dass Media Companies, also andere Firmen in der Lage sind, eurem Computer zu vertrauen. Das heißt, diese Firmen waren dann in der Lage, diese Technologie zu benutzen, sicherzustellen, dass sie eurem Computer vertrauen können. Aber Gott sei Dank ist nichts davon wirklich passiert. Es gibt politische und auch technologische Gründe, warum das heutzutage so nicht umgesetzt wird. Und das zentrale Teil bei Trusted Computing ist ein sogenanntes TPM, ein vertrauenswürdiges Plattformmodul. Und das ist ein Chip, der auf dem Motherboard ist. Das ist normalerweise auf dem LPC-Bus. Und das hat keine Möglichkeit, direkt auf Systemspeicher zuzugreifen. Das kann nur Befehle ausführen. Das kann also nicht unabhängig irgendwie den Zustand des Systems modifizieren. Das hat keine Möglichkeit, sich den Inhalt von Arbeitsspeicher anzugucken und anzuschauen, was ihr gerade ausführt. Das kann also nur machen, was man sagt, dass es tun soll. Wenn man ihm explizit, also es kann nur Dinge wissen, die man ihm explizit mitgeteilt hat. Wenn ihr niemals Code ausführt, der auf das TPM zugreift, dann weiß das TPM nichts und kann auch nichts tun. Das kann ich nach Hause telefonieren, das kann ich mit eurer Software irgendwie Veränderungen durchführen. Und in der freien Softwarewelt haben wir das TPM im Wesentlichen ignoriert. Denn die meisten Sachen waren nicht vorteilhaft für uns, die wir damit machen können. Aber das TPM hat ein großartiges Feature, was man in diesem trusted Computing Goal, also in dem Ziel, den Computer vertrauenswürdig zu machen. Und das nennt man Measurement, also Ausmessungen. Und die Idee ist, dass jeder Komponente eine kryptografische Signatur prüft für die nächsten Komponenten und verhindert, dass du bootest, wenn die Signatur nicht stimmt. Und die Möglichkeit, beliebige Software auszuführen, ist bei trusted Computing nicht eingeschränkt. Aber stattdessen kann jede Komponente die nächste Komponente eben messen und speichert diesen Wert im TPM. Und Messungen, in dem Fall, sind einfach nur SHA-1-Hashes. Und nun, das mal kurz klarzustellen, dass die TPM-Spezifikation 1.2, das darüber rede ich heute, 2.0 ist jetzt verfügbar. Und das gibt auch Geräte mittlerweile dafür. Aber fast alle Geräte, die ihr jetzt in der Wirklichkeit antrefft, sind noch 1.2 Geräte. Und TPM 2.0 Geräte können beliebige Hash-Algorithmen benutzen, also zum Beispiel auch welche, die tatsächlich gut sind. Also in einem gemessenen Bootprozess wird der erste Prozess an den zweiten Prozess anschauen. Und bevor er den ausführt, macht er eine SHA-1-Check-Summe davon und schreibt die in ein Plattform-Konfigurationsregel. Ein sogenanntes PCR. Und wenn wir von Schreiben reden, dann heißt Extent ist das wichtige Wort hier, also erweitern. Er setzt nicht den bisherigen Wert, man kann nicht einfach bisherige Werte überschreiben, sondern was man macht, ist, der vorhandene Inhalt von dem PCR wird an den neuen Wert angehängt. Das heißt, man hatte da 20 bytes, man hat einen 20-byte SHA-1-Hash draufgeschrieben, und jetzt hat man einen 40-byte Wert. Und dieser 40-byte Wert wird dann wieder gehashed, auch wieder mit SHA-1, und das PCR wird auf diesen Wert gesetzt. Das bedeutet, dass der neue Wert nicht nur auf den neuen Wert ist, sondern auch vom alten Wert abhängt. Das heißt, es gibt also drei Möglichkeiten, einen speziellen PCR-Wert zu bekommen. Und das sind die SHA-1 zu brechen. Also wenn du in der Lage seid, eine Möglichkeit rauszufinden, 20 bytes zu einem vorhandenen Wert hinzuzufügen, sodass ihr dann den SHA-1-Hash von dem neuen Wert, also von dieser kombinierten Zeichenkette kontrolliert. Und wenn irgendeiner von euch weiß, wie man SHA-1 bricht, dann werde ich also auch ein bisschen unglücklich sein, und andere Leute werden sehr, sehr unglücklich sein. Und es wird also schlechte Tage für uns alle geben. Und ich werde auch diese Möglichkeit jetzt auch erstmal ignorieren, denn das macht viel zu viel Angst, und wir können auch nicht wirklich was dagegen tun. Und der andere Möglichkeit ist, beliebigen Code auszuführen durch Daten, die nicht gemessert werden, also die nicht gemessen werden. Und üblicherweise wird also nur Code geprüft gemessen. Und dieser Code muss eben auch mit Daten arbeiten. Und also als Spezies sind wir ziemlich schlecht, Code zu schreiben. Und wir sind sogar richtig schlecht, Code zu schreiben, der mit Daten arbeitet. Und wir sind also überragend schlecht, Code zu schreiben, der mit beliebigen Daten umgehen kann. Und eine Möglichkeit, den Trusted Computing-Prozess zu stören, wurde demonstriert, in dem die Firmware, der Firmware einen Bild geben konnte, was beim Buten angezeigt wurde. Und das bedeutet, dass Leute bei Intel den Bootbildschirmen austauschen konnten durch ein anderes Logo, was zum Beispiel das Intel-Logo war. Aber das Problem war, das war Bitmap, also BMP, das alte Microsoft-Bitmap-Format. Und da kann man Run-Length-Encoding, also RLE mit benutzen. Da kann man also sagen, der nächste Wert entspricht 256 von diesen Werten. Das ist also ein verlustfreier Kompressionsalgorithmus. Und es gab keine Möglichkeit in dem Code, die überprüft hat, ob das Run-Length-Encoding, also das RLE, nicht irgendwie dazu geführt hat, dass man den Puffer, der dafür reserviert war, noch reingepasst hat. Und das bedeutet, man konnte also beliebigen Code in der Firmware überschreiben. Und nachdem die Bitmap eben nicht geprüft wurde, konnte man beliebigen Code ausführen. Das heißt, es wurde nach wie vor die nächste Komponente überprüft mit char1, aber man konnte eben seinen char1-Wert, den man haben wollte, an die entsprechende Stelle schreiben. Und wenn also die Firmware nicht kompetent ist, wenn die Firmware nicht schlau ist in dem Fall, dann kann sie auch nicht vertrauenswürdig sein. Und wir haben jetzt den Sourcecode natürlich, also den Quelltext für unsere Firmware nicht. Und das ist schon auch ein kleineres Problem. Und letztendlich kann man genau dasselbe zweimal hintereinander machen. Also das ist genau das, was bei einem normalen Boot passiert. Der char1 von jedem Komponente stimmt über ein. Und dann macht man dieselben Updates auf das PCR und kriegt am Ende auch denselben PCR-Wert. Und wenn das System also normal bootet, dann werden die PCR-Werte immer dieselben sein, solange also keine von diesen Komponenten modifiziert wurde. Aber es gibt noch mal ein kleines Problem hier. Wie greifen wir denn lesend auf diese Werte zu? Und die Antwort ist, naja, erstmal ganz einfach. Wir fragen einfach nach dem, das TPM, wie sind denn die Werte? Es gibt dann Kommando, da kann man sagen, hier, wie sind denn die Werte in dem PCR? Und dann kriegt man dann eine Antwort. Aber das TPM ist ein Stück Hardware. Wir reden mit Hardware über den Kernel. Und jetzt könnte ein Kernel uns einfach anlügen. Ein Kernel können uns einfach irgendwelche Werte zurückgeben, die der Kernel eben gerade zurückgeben möchte. Und das ist ein Problem. Der ganze Punkt ist, um rauszufinden, können wir dem Kernel überhaupt vertrauen. Und wenn der Kernel aber nicht vertrauenswürdig ist, dann haben wir keine Möglichkeit, rauszufinden, ob die Antwort stimmt oder nicht. Wenn wir falsche Werte zurückbekommen, dann, also wenn wir halt richtige Werte kriegen, dann heißt das natürlich nicht, dass alles okay ist. Es ist der Standardprozedur. Und das war der Teil, wo wir uns am meisten Sorgen drüber gemacht haben. Anfang der 2000er, also dieses Protokoll, ist ein, wo der TPM eine Unterhaltung hat, mit dem Server hat und der Endorsement. Ja, also es gibt da ein Schlüssel, da kann man überprüfen, ob der, die der Antwort tatsächlich bestätigt wurde von einem, von einem Server woanders, zum Beispiel vom Hersteller von dem Rechner. Und man kann dann sicherstellen, dass das TPM irgendwas unterschreibt mit diesem Schlüssel der eingebranntes im TPM. Und nur dieses, der Hersteller hat über, hat Kontrolle über die, die so ein, so ein Schlüssel mit dem das signiert ist. Und dann weiß ich an dem Zeitpunkt, na gut, das TPM ist wahrscheinlich das, von dem sich es ausgibt. Das heißt, hier habe ich wieder ein entferntes System, das wird mit dem Betriebssystem irgendwie, also da bin ich natürlich auf das Betriebssystem angewiesen, dass das funktioniert, wenn das Betriebssystem verhindern will, dass ich mit diesem Server, der diesen Schlüssel überprüft, reden kann, dann kann es das natürlich. Und das, das Betriebssystem auf meinem, auf meinem Rechner kann ich eingreifen in diesen Remote Attestation Prozess. Denn es weiß nicht, also es kann nur in der Lage, es kann nur die Unterhaltung komplett unterbinden, aber es kann eben nicht diesen Wert anders signieren. Und das, der Server auf der anderen Seite kann dann überprüfen, ob das System in irgendeinem, in einem vertrauenswürdigen Zustand ist. Und das hängt halt von irgendeiner Vorstellung davon ab, was vertrauenswürdig davon bedeutet. Also ich erkenne zum Beispiel die Firmware-Version daran, dass der PCR-Wert da richtig ist. Und ich erkenne diesen Bootloader, und das ist mir zum Beispiel egal, was für ein Körner gebutet wird. Das kann man dann zum Beispiel machen. Und das bedeutet, ich muss jetzt diesem entfernten Rechner vertrauen. Und das gibt also keinen Grund, warum ich nicht glauben sollte, warum dieser Server auf der anderen Seite nicht auch irgendwie kompromittiert wurde. Warum der nicht vielleicht andere Entscheidungen über Vertrauen trifft, als die, die ich eigentlich machen möchte. Wenn jemand dieses Gerät kompromittiert, dann kann es sein, dass mein Computer, die anfrägt bei diesem Rechner, ist mein Computer in einem guten Zustand und der andere Server antwortet, wenn man mit einem Rechner ist gerade in einem guten oder schlechten Zustand, aber wenn jemand diese Maschine kompromittiert, dann kann er einfach sagen, ja, dein Rechner ist in einem guten Zustand. Naja, und der zweite Problem ist, du brauchst auch Netzwerkzugriff. Es gibt keine Möglichkeit, als lokaler Benutzer rauszufinden, ob mein System vertrauenswürdig ist. Also wenn du in einem Flugzeug bist, ohne WLAN, irgendwo auf dem Land, wo es keinen Netzwerk gibt, oder du bist einfach sonst irgendwie nicht an den Netzwerk angeschlossen, dann kann man dieses Remote Attestation Protokoll nicht benutzen. Das ist also nicht ideal. Wie kommuniziert die Maschine überhaupt mit dir? Also per SMS vielleicht, aber dann könnt ihr jemand einfach eine gefälschte SMS schicken, denn wir wissen, dass die Telefonnetzwerke nicht so sicher sind, wie wir das gerne hätten. Und wenn der Angreifer oder der Feind in dem Fall irgendwie in der Regierung ist, dann stimmt das in besonderem Maße. Also woher kriegen wir jetzt eine sichere Verbindung? Naja, wenn das auf meinem lokalen System läuft, dann mache ich ein Browser auf und dann sagt der Browser, ja, alles ist ok, aber der Browser wird eben möglicherweise vom Kernel kompromittiert verändert. Und dann kann ich dem also nicht vertrauen, was der Browser mir sagt, aber es sieht eben alles ganz gut aus. Das heißt, Remote Attestation ist, bedeutet, ich habe ein Problem, denn ich muss mich auf ein System verlassen, die nicht unter meiner Kontrolle sind. Und das ist nicht die Situation, die wir haben wollen. Und was wir im Prinzip überprüfen, ist, ob das TPM vertrauenswürdig ist. Und alles ist sinnlos, wenn das TPM nicht vertrauenswürdig ist. Also wenn ihr dem TPM nicht vertraut, dann könnt ihr das hier irgendwie als Übung sehen. Das kann ich voll verstehen, wenn das eure Meinung ist. Aber wenn man das TPM als vertrauenswürdig sieht, dann kann ich alle Features benutzen, die dieses TPM anbietet, um Geheimnisse zu kontrollieren. Denn was TPM machen kann, ist, dass das Daten nur freigegeben wird, je nachdem, wie der Zustand von diesen PCRs ist. Das heißt, ich kann so einen TPM bitten, zu sagen, hier, generiere mir mal einen RSA-Schlüssel. Und dann sage ich dem TPM, na, verschlüssel mal hier diese Daten mit diesem RSA-Schlüssel. Und das coole daran ist, ich kann das TPM bitten, diese Daten zusammen mit Informationen über diese PCR-Werte zu verschlüsseln. Und der Schlüssel, den man benutzen kann, um diese Daten zu entschlüsseln, liegt nur im TPM. Es ist niemals im Arbeitsspeicher. Es ist niemals auf der Festplatte. Es ist verschlüsselt mit einem Schlüssel, der in dem TPM existiert. Das heißt, es gibt keine einfache Möglichkeit, dass jemand diesen privaten Schlüssel kriegen kann, um die Daten zu entschlüsseln. Wenn man also diese PCR-Werte hat, wenn ich die Daten in den TPM reintuhe, dann verschlüsselt er das und schaut die PCR-Werte an. Und wenn überprüft die Werte und wenn die übereinstimmen, dann kann er natürlich die entschlüsselten Daten zurückliefern. Und wenn die nicht übereinstimmen, dann gibt es einfach ein Fehlercode. Und das bedeutet, dass es möglich ist, ein Geheimnis zu kennen, dass nur rausgegeben wird, wenn die Messungen gut sind. Und was dann möglicherweise bedeuten sollte, dass dein System vertrauenswürdig ist. Also, das kann man benutzen, um den Encryption Key von der Festplattenverschlüsselung zu speichern. Wenn der Prozessor das beeinflusst, dann passt die Signatur nicht mehr und dann wird auch der Encryption Key nicht freigegeben. Und dadurch wird der Bootloader auch nicht die Festplatte entschlüsseln, eben weil da irgendwas komisch ist. Aber das verhindert nicht, das schützt einem nicht vor den Fall, wenn jemand den Laptop klaut. Denn man muss einfach nur den Laptop umdrehen. Man muss den Laptop nur anschalten, dann bootet er, denn der Zustand ist ja unverändert. Und das System überprüft, dass der Bootzustand nicht beeinflusst wurde. Also, man gibt einen Passwort ein, das System startet, das TPM entschlüsselt den Schlüssel. Wenn das TPM dabei erfolgreich ist, dann haben wir bald die Hälfte des Prozesses, aber wir brauchen immer noch die Passphrase, um den Schlüssel in einem zweiten Zustand oder in einer zweiten Phase zu entschlüsseln. Das sieht sicher aus, denn wenn jemand die Maschine klaut, dann können sie halt immer noch nicht auf euer System zugreifen. Und wenn man das System beeinflusst, dann scheidet das bereits am ersten Schritt. Da ist aber ein Problem mit dieser Art zu denken, dass das System in einem secure State ist. Ihr bootet euer System, und ihr kriegt ein Passwortabfrage, und ihr denkt, okay, euer System ist jetzt in einem sicheren Zustand, und ihr gebt euer Passwort ein, und das sieht so aus, als würde das System boot, und dann geht irgendwas schief, weil Linux in dem Fall schlecht ist. Das kann passieren, ihr macht den Rechner aus und wieder an, und ihr macht den aus und wieder an, und ihr kriegt wieder den Passwort prompt, und das System bootet. Also alles sieht gut aus, und Software funktioniert nicht, das passiert manchmal, das seid ihr gewöhnt. Wie viele von euch haben noch nie eine Kernelpanik gesehen? Also es melden sich jetzt etwa zwei Leute im Publikum. Er behauptet, es hätten sich niemand gemeldet. Also das sind Sachen, die könnten einfach mal passieren. Aber das Problem ist, woher wissen wir denn, welches Programm diese Ausgabe hier erzeugt? Ihr habt keine Ahnung, ob diese Passwortabfrage legitim ist. Also ihr wisst nur, dass, wenn der Bootprozess verändert wurde, dass das TPM das Geheimnis nicht freigeben wird. Das heißt, die Passphrase allein ist total sinnlos. Aber ihr wisst immer noch nicht, dass das tatsächlich der echte Passwortabfrage ist. Also jemand könnte euer System infiziert haben mit Code, der den Bootprozess so modifiziert hat, dass er eine falsche Passwortabfrage anzeigt, also eine gefälschte. Dann wartet das darauf, dass ihr euer Passwort eingibt, speichert das irgendwo, gibt eine falsche Kernelpanik aus und hat sich dann selbst deinstalliert. Und ihr bootet neu, und jetzt funktioniert alles, denn der Bootprozess ist jetzt vertrauenswürdig. Aber das Problem ist, jetzt gibt es irgendwo auf eurem System eine Kopie eurer Passphrase. Jetzt kann ein Angreifer einfach euren Laptop klauen, die haben euer Geheimnis, die haben eure Passphrase. Und das ist nicht ideal. Das Problem ist, ihr gebt immer noch das Passwort ein, bevor ihr wisst, ob das System vertrauenswürdig ist. Und die Idee ist, die Evil-Mate-Attacker, also die Zimmermädchen-Attacke, die auf der Laptop steht in einem Hotelzimmer, der Angreifer kommt in den Hotelraum, modifiziert euer System und geht dann wieder, bevor ihr wieder zurückkommt. Das heißt, das System ist jetzt nicht mehr vertrauenswürdig. Und Anti-Evil-Mate ist eine Technologie, die von Joanna Rutkowska entwickelt wurde, die sicherstellen sollte, dass es weniger praktikabel ist für einen Angreifer. Also statt, dass ihr einfach nur blinden Geheimnis eintippt, dass das System euch beweist, dass es sicher ist, und zwar vorher. Und statt, dass man einfach nur einen Festplattenverschlüsselungsgeheimnis verschlüsselt, verschlüsseln wir ein System, also ein Geheimnis, das nur ihr kennt. Das heißt, bevor ihr euer System bootet, verschlüsselt ihr einen Satz, den niemand raten kann. Der wird dann mit spezifischen PCR-Werten verschlüsselt. Das heißt, das System bootet. Und dann, wenn das System in vertrauenswürdigen Zustand ist, dann wird dieses Geheimnis entschlüsselt und angezeigt. Und wenn ihr dieses Satz seht, dann wisst ihr, dass euer System in einem vertrauenswürdigen Zustand ist. Und wenn ihr den Satz nicht seht, dann wird eure Passphrase nicht ein. Und wenn es immer angezeigt wird, dann ist das erste Problem, naja, dann ist es ganz einfach, dass jemand hingeht, euer System bootet, den Satz abliest, und dann seine bösartige Software installiert, die den selben Satz ausgibt, auch wenn das System nicht in einem vertrauenswürdigen Zustand ist. Das heißt, der Weg, ist, wir speichern dieses Geheimnis auf einem USB-Stick. Das heißt, wenn wir das mit dem USB-Stick booten, dann kann das Geheimnis jetzt entschlüsselt werden und angezeigt werden. Aber das bedeutet, der Benutzer muss die ganze Zeit einen USB-Stick mit sich rumtragen. Und der muss die entsprechende Disziplin haben, dass der USB-Stick immer eingesteckt ist, wenn er Angst hat, dass sein System modifiziert werden sollte. Und dann wurde das System kompromittiert und ihr merkt das nicht. Und ein Geheimnis auszugeben, ein statisches Geheimnis auszugeben, das ist suboptimal. Optimalerweise hatten wir kein statisches Geheimnis, sondern irgendeine Art dynamische Anzeige. Also irgendwas, das sich ändert über die verschiedene Zeitraum. Also wo ich in einer Session nur einen so, also wo ich quasi, wenn ich einen so ein Secret mir anschaue, dann erlaubt es mir nicht, das Secret auch in der Zukunft anzuzeigen. Also irgendwas mit einem dynamischen, mit einer dynamischen Komponente. Und ich hoffe, dass alle von euch so was in der Art schon benutzen. Also, falls ihr das nicht macht, dann sollt ihr euch schlecht fühlen und das gleich einmal anschalten. Das Designziel von TOTP, also einmal Passwörter, zeitbasierte einmal Passwörter, das benutzt wird für zwei Faktor Autorisierung. Ihr habt ein, es gibt, wenn ihr euch bei einer Webseite anmeldet und ihr macht zwei Faktor Autorisierung an, dann erzeugt die Webseite ein Geheimnis und speichert das. Und die Webseite gibt euch üblicherweise ein QR-Code und ihr scant den ein auf eurem Telefon und jetzt hat auch das Telefon eine Kopie von dem Geheimnis. Aber bei der Authentifizierung basiert es eben nicht nur auf dem Geheimnis, sondern eben auch auf der aktuellen Zeit. Das heißt, es gibt einen Algorithmus, da nehmt ihr das Geheimnis, die Zeit und daraus kommt dann eine sechsstellige Zahl und die gibt ihr der Webseite und die Webseite überprüft dann, dass das die korrekte Nummer ist, denn die Webseite kennt ja auch das Geheimnis und die Uhrzeit. Also mit etwas Glück weiß es auch die richtige Uhrzeit. Das löst also im Wesentlichen dieses Problem. Und das ist großartig, denn das gibt es schon. Es gibt eine ganze Menge Apps für zwei Faktor Autorisierung, die sind kostenlos, ihr könnt die, sind auch freie Software, ihr könnt ihr auf einem Betriebssystem das freie Software ist, ihr könnt das auch auf freie Software, die auch auf freier Firmware läuft. Das heißt, das ist großartig, denn Benutzer wurden auch schon trainiert, dass sie das System gut verstehen. Viele Leute benutzen das und die Welt ist trotzdem noch nicht zu Ende. Das heißt, wir können davon ausgehen, dass viele Nutzer irgendwie verstehen, wie das mit diesen sechs Zeichen, also sechsstelligen Zahlen funktioniert, auch wenn sie die Technologie dahinter nicht verstehen. Und was wir jetzt machen können, ist, wir können das Geheimnis, das TOTP Geheimnis, mit dem TPM verbinden. Also wir drucken einen, also wir zeigen einen QR-Code an und denen können die Benutzer dann mit ihrem Phone, also mit ihrem Telefon einscannen. Und beim Buten gibt es eine sechsstellige Nummer und der Benutzer prüft dann, ist das dieselbe sechsstellige Nummer, die ich habe. Und wenn die Nummer dieselbe ist, dann ist das System vertrauenswürdig. Oder es gibt eine Eins in einer Million Chance, dass der Angreifer einfach die falsche, die richtige Zahl geraten hat. Aber ihr könnt natürlich auch längere Zahlen benutzen, wenn ihr wollt. Und wir schauen jetzt eine kurze Demonstration an dazu. Wie ihr sehen könnt, ich habe wundervolle Quellkontrolle. Oder Codekontrolle. Ich renne es, lass das Programm jetzt einfach laufen. Ich lasse das jetzt als Route laufen, weil das direkt über den Kernelspace mit dem TPM spricht. Und hier ist der QR-Code. Ist das nicht toll? Ist das ansie-terminal-toll? Und jeder im Publikum kann jetzt diesen QR-Code missbrauchen, um bei mir einzubrechen. Also sollte man das Geheimnis nicht für irgendwas Wichtiges benutzen. Und wenn ich jetzt das hier laufen lasse, wo, dann kriege ich eine sechsstellige Zahl. Wenn ich das QR-Code auf dem Telefon verwendet hätte, hätte ich die gleiche sechsstellige Nummer bekommen. Ich überlasse es euch, das zu verifizieren. Nur als Erinnerung, wenn ihr versucht das zu machen, während ihr das Video zuschaut später, dann wird es natürlich nicht mehr funktionieren. Das ist natürlich die Idee des Ganzen. Also zurück zu diesem, also es gibt einige Probleme. Also ein Problem ist, dass das Geheimnis im RAM liegen muss. Und wir haben deswegen das TPM erlauben müssen, das Geheimnis zu entflüsseln und dann im RAM abzulegen. Und das bedeutet natürlich, dass ein Angreifer, der, ein Angreifer, der auf den RAM zugreifen kann, kann auch das Geheimnis abgreifen. Aber es gibt auch... Es gibt Arbeitsspeicher-Angriffe, die auch in einem vertrauenswürdigen Zustand funktionieren. Also zum Beispiel, wenn man ein Bus-System hat, die DMR Zugriff erlauben, dann kann man einfach das per DMR das Geheimnis aus dem RAM auslesen kann. Das heißt, man möchte das IOMMU aktialisiert ist. Aber leider ist es bei vielen Betriebssystemen immer noch deaktiviert, speziell bei freier Software, weil wir schlecht sind, was Software angeht. Und Naja, Intel hat auch irgendwie Probleme beim Design, aber das ist eine andere Geschichte. Also wir müssen nochmal drüber nachdenken. Eine Möglichkeit ist, dass die TPM Schlüssel, wenn wir sie erzeugen, dann können wir dem TPM sagen, es muss eingeschränkt sein auf einem speziellen PCR-Zustand. Also das TPM wird nicht Verschlüsselung durchführen oder Signatur und Operationen außer der Zustand, das TPMs stimmt eben mit dem überein, den wir vorgegeben haben. Also wir können Schlüssel generieren, den in dem TPM einschließen und dann können wir dem TPM sagen, signiere mal bitte die aktuelle Uhrzeit. Und dann kann das TPM dieses signierte Objekt uns zurückgeben, zum Beispiel über einen QR-Code und dann kann ich überprüfen, dass die Signatur stimmt. Das heißt, ich habe möglicherweise eine Applikation, da kann ich den öffentlichen Schlüssel auf das Telefon kopieren und das TPM signiert die Zeit und dann scanne ich den QR-Code und die Applikation überprüft dann, ob der QR-Code tatsächlich korrekt unterschrieben ist. Und das bedeutet, wir müssen neue Software schreiben und das mag ich einfach nicht und das ist wirklich schade, dass ich das als für den Lebensunterhalt machen muss und außerdem kennen die Nutzer, das ist nicht so gut und eines der Probleme ist, wir müssen es am einfachsten machen für den Nutzer wie möglich und das bedeutet, dieses System ist auch nicht ideal. Wir können irgendetwas anderes machen. Wir könnten einen Schlüssel außerhalb des TPM skenarieren, wir können das in den TPM importieren, das heißt, das ist jetzt unter Kontrolle des TPM und statt, dass wir jetzt die Uhrzeit signieren, verschlüsseln wir die, machen ein Hash und extrahieren sechs Zahlen und das sieht so ähnlich aus wie TOTP, aber es ist incompatibel. Das heißt, wenn wir jetzt eine neue Applikation für das Telefon schreiben, dann ist es vielleicht einfacher, den Nutzer in das Beizubringen. Aber jetzt braucht das Telefon den selben privaten Schlüssel und deswegen müssen wir den privaten Schlüssel außerhalb des TPM skenarieren und das Problem, wenn wir den außerhalb vom TPM generieren, ist aufgrund von ungünstigen Designentscheidungen kann man jetzt dem TPM sagen, exportier mal diesen Schlüssel wieder. Jeder Key, der extern generiert wurde, kann man auch wieder exportieren. Das heißt, der Angreifer könnte einfach sagen, gib mir doch mal eine Kopie von dem Schlüssel. Also, wenn jemand Software ausführen kann auf eurem System, dann könnte er einfach den privaten Schlüssel extrahieren und dann diese Zahlen fälschen. Und vielleicht ist es auch schon viel zu kompliziert. Vielleicht wäre es besser, es wäre einfacher, denn na ja, scheinbar ist Einfachheit ja auch einen Wert an sich. Das wird zumindest von Betriebssystemenherstellern immer wieder wiederholt und die verstehen scheinbar weder Einfachheit noch Werte. Und TPMs haben eine ganze Menge GPIO-Pins, denn das heißt, man kann jetzt Hardware anschließen an die TPMs und das ist erstmal nicht klar, warum man das machen möchte, weil man da kein Code ausführen kann. Aber man kann den Zugriff auf diese Pins einschränken, je nachdem, in welchem Zustand das TPM ist. Man kann es also so einstellen, dass man GPIO nur dann beschreiben kann, wenn der Zustand der PCRs richtig ist. Das heißt, ich könnte zum Beispiel eine kleine LED anschließen und dann beim Buten versucht das Betriebssystem auf diese LED zu schreiben und wenn die PCR-Werte stimmt, dann funktioniert es, dann geht das LED an und das System ist in einem guten Zustand. Also klasse, das sieht ziemlich gut aus. Es sind ganz einfache Modifikationen. Wir müssen einfach nur eine zusätzliche LED an diesen GPIO anschließen, an das Motherboard anschließen. Es ist natürlich ganz einfach, dann irgendwas an den LED anzuschließen, sodass es angeht. Das heißt, die Hardware, die man braucht, um das anzugreifen, ist nicht besonders kompliziert. Das ist also eine nette Idee, aber es ist halt auch nicht ideal. Eine andere Idee ist, wir haben über den Bildschirm oder den LED zu benutzen für Kommunikation, aber wir könnten stattdessen auch ein anderes Interface benutzen und eines von diesen Möglichkeiten ist NFC, also Near Field Communication. Also man könnte Remote Attestation machen über NFC, das heißt, wo wir vorher ein Netzwerk gebraucht haben. Das System bootet zu einem bestimmten Punkt und ich laufe dann hin und leg meinen Objekt, was ich habe, auf den NFC-Sensor und dann passiert Kommunikation. Das TPM erzeugt irgendwas Signiertes, gibt es an das Gerät weiter, das Gerät überprüft, dass das stimmt und das eine schöne Eigenschaft davon ist, dass wir jetzt auch einfach eine Passphrase ignorieren können, denn wir können ein Geheimnis haben, was in dem Gerät ist und wenn wir das Gerät nicht an so einen Laptop halten, dann bekommt das dieses Geheimnis nicht und das System wird nicht booten. Und einer von den hübschen Eigenschaften hier ist, wir können nicht einfach nur die Eingabe ignorieren, wir können die Anzeige nicht einfach ignorieren. Wenn ich so eine sechsstellige Zahl kriege, das kann ich einfach ignorieren und einfach meine Passphrase eingeben. Wenn ich immer mein Telefon oder irgendetwas anderes gegen das an den Laptop halten muss und das nicht dazu führt, dass das System dann automatisch bootet komplett, dann gibt es keinem, also ich kann das nicht vergessen, wenn ich das nicht mache, dann bootet das System einfach nicht. Das heißt, ich kann jetzt das korrekte Verhalten von den Nutzern erzwingen. Es ist viel einfacher, den Nutzern zu trainieren, wenn es einfach keine Möglichkeit gibt, es falsch zu machen. Also ich war früher mal Sysadmin und das hat also mit persönlicher Erfahrung zu tun. Das Problem hier ist, nun ja, ihr habt immer noch begrenzte Hardwareunterstützung. Die meisten Letztes haben keine near field communication Fähigkeiten, aber wenn man diese Hardware hat, dann ist das eine interessante Möglichkeit, sich das anzuschauen. Es wäre natürlich schön, wenn jemand tatsächlich diesen Code schreiben würde, der das unterstützt. Das ist mein gewöhnlicher, meine gewöhnliche Rangehensweise, neue Software zu bekommen. Aber selbst mit all diesen Maßnahmen immer noch gefährdet durch verschiedene Angriffe Wenn man kein IOMMU hat, dann hat man keine Möglichkeit, die M basierte Angriffe. Also da muss man leider aufgeben, weil das geht einfach nicht. Leider gibt es ein Gerät, das immer DMA machen kann und das es in jedem System drin ist. Das ist die AMD hat, also Intel hat das schon, AMD wird es bald ebenfalls einbauen. In der X86 Welt sind wir leider, damit, ja, wir müssen es damit abfinden, dass es diese MMA-Systeme immer noch mit hergestellt werden und deswegen können unsere Systeme auch nicht 100%ig sicher sein und vertrauenswürdig sein. Es könnte jemand Code in eure Management Engine eingeführt haben, z.B. jemand, der für so eine drei Buchstaben, Agency, NSA, CIA usw. arbeitet und ihr könnt also nicht sicherstellen, dass euer System zu irgendeinem Zeitpunkt in einem komplett vertrauenswürdigen Zustand steht. Es gibt einfach aktuell keine gute Antwort auf dieses Problem. Es ist ein Problem, was darum geht. Wir haben vertrauenswürdige Firmen, wir haben vertrauenswürdiges Betriebssystem, aber wir wissen nicht, zumindest nicht mit Sicherheit, wie gut der Zugriff auf der Management Engine kontrolliert wird. Wir wissen nicht, wie sicher die ist, wir wissen nicht, wie kompetent die Entwickler waren. Alles, was wir wissen, ist, dass Intel uns sagt, die Management Engine wird von Topman, also von hervorragenden Leuten, das ist eine Indiana Jones Referenz, entwickelt. Ich habe eine ganze Menge Code gesehen von Intel und ich möchte jetzt nicht sagen, dass Intel immer großartige Software schreibt und man kann natürlich auch einfach das TPM selbst angreifen. TPMs sind selbst nicht dafür gemacht, dass sie nicht medifiziert werden können. Die Spezifikation überlässt es komplett, ist es komplett der Plattformspezifikation oder für die einzelnen Hersteller, dass die da Wettbewerb machen können. Und das ist auch nicht ideal. Eine ganze Menge von denen definieren, dass man sehen kann, dass es modifiziert ist. Und eine ganze Menge Hersteller sagen, naja, schaut euch das Motherboard an, ist das TPM noch da. Und wenn ja, dann ist es wohl nicht modifiziert worden. Und das ist wieder mal nicht ideal. TPMs sollen nicht besonders widerstandsfähig sein gegenüber Attacken. Also wenn jemand so ein TPM rauslötet, dann kann man fast mit Sicherheit vermuten, dass jemand die Daten auslesen kann und Regierungen können so was mit Sicherheit machen. Und vielleicht auch ein Amateur, wenn er genug Ahnung hat, ohne besonders viel Geld oder Zeit da einzusetzen. Das ist auch nicht wirklich ideal. Aber es ist okay, wir haben eine gute Lösung dafür. Denn Intel hatte die Idee, dass wir statt einem TPM im Motherboard haben, können wir einen TPM, das auf der Management Engine läuft, als Software. Ja, das ist sicher großartig. Und das basiert natürlich auch immer noch darauf, dass wir jetzt einen TPM haben müssen. Und im Juli diesen Jahres waren, also wurde verlangt, dass alle neue Systeme, die für Windows 10 zertifiziert sind, auch ein TPM haben müssen. Also das ist eigentlich eine ganz feine Sache. Danke Microsoft. Und wenn ihr ein Apple-System habt, na ja, dann habt ihr halt Pech gehabt. Wenn jemand von euch irgendwas Vertrauliches auf einem Apple-System tut, dann hört damit bitte auf. Auf jeden Fall, hört damit auf. Es gibt keinerlei Bootsicherheit, die irgendwie glaubwürdig ist. Es gibt eine Secure-Boot. Es gibt keine Möglichkeit, dass der Boot sich messen lässt wie dem TPM. Selbst wenn ihr Verschlüsselung benutzt, die Passwortanzeige könnte von allem geschrieben sein, es könnte ein man in der Mitte sein, der könnte einfach euer Geheimnis gespeichert haben, der könnte hinterher auf euer System zugreifen, benutzt keine Apple-Laptops, wenn ihr irgendwelche Geheimnisse aufbewahren müsst. Offensichtlich, wenn man also hardware nicht vertrauen für keine Möglichkeit, irgendwas zu vertrauen. Wenn wir der CPU nicht vertrauen können, dann können wir keinen vertrauenswürdigen Laptop bauen. Wenn die Hardware von einem Hersteller nicht vertrauenswürdig, also als nicht vertrauenswürdig designt wurde, dann gibt es keinen Fortschritt. Da haben wir am Ende höchstens vielleicht die Möglichkeit, über diesen Prozess zu kontrollieren. Aber die einzige Möglichkeit am Ende wäre, dass wir komplett Open Source CPUs haben. Wenn wir jeden einzelnen Transistor beim Design schon prüfen können und prüfen können, dass alles vertrauenswürdig ist, wenn das schnell ist, dann kann es immer noch Probleme geben, was es eine Backdoor gibt. Und das ist ein sehr, sehr schwieriges Problem. Ich muss zugeben, ich habe keine Ahnung, wie man das lösen soll. Aber schrittweise Verbesserungen in Sicherheit, die sind immer noch Verbesserungen. Also wir können nicht einfach sitzen bleiben und sagen, er will die wirklich schweren Probleme, können wir ihn nicht lösen. Und deswegen ignorieren wir jetzt alle anderen Probleme. Wir können auch noch machen, also so viel machen wie wir können. Leute müssen immer noch in der Lage sein, so weit wie möglich sicherstellen, dass ihr System vertrauenswürdig ist. Ich übernehme. Hier ist ein Code, also einige Programmcode, die ihr verwenden könnt, um vertrauenswürdige Boots zu machen. Ihr braucht ein Boot oder der volle TPN Messung machen kann. Und zum Beispiel der Shim Bootloader, der kann das. Ich habe einige Patches für Grab, der Measurements zulässt. Und dann hat man halt einen komplett gemessenen Bootprozess bis hin zum Kernel Start. Ich messe sogar die Kommandos, die man in Grab rein gibt. Und der Code, den ich demonstriert habe für die TPM Secrets, also den Code, den ich gezeigt habe, die Programme, der es ebenfalls auf GitHub. Und das sollte eigentlich ziemlich straightforward sein für Benutzer diese Sachen zu aktivieren. Es gibt einige zusätzliche Komplexitäten, über die ich gerne reden würde. Aber das will ich jetzt nicht hier im Talk machen. Wir haben ungefähr 10 Minuten über. Also wenn wir zu einigen Fragen kommen wollen, können wir das jetzt machen. Wir beginnen mit dem Internet. Vielen Dank. Wir hatten einige Diskussion auf dem IRC. Wäre es möglich, den NFC-Ansatz mit QR-Code verwenden, also nicht NFC verwenden, sondern QR-Code verwenden, sodass man dann den QR-Code verwenden würde, um halt sechs Ziffern zu erzeugen, die da eingegeben werden müssen. Ja, also ich sehe keinen Grund, warum das nicht funktionieren soll. Klar, man kann statt NFC einfach QR-Codes benutzen. Ja, also ihr müsst jetzt sicherstellen, dass die App nicht einfach nur die sechsstellige Zahl anzeigt, sondern dass die App auch gleich anzeigt, ob das Zertifikat überprüft wird. Aber klar, ich kann mir vorstellen, dass das funktioniert. Mikrofon 2, 8. Vielen Dank für diesen Vortrag. Ich würde gerne wissen, wie man das TPM an dieses PCR anbindet. Wie kann das überhaupt funktionieren? Naja, und ich wollte eigentlich diese Subsidität mal weglassen. Es gibt ein paar Möglichkeiten, das zu machen. Also ich könnte zum Beispiel, wenn ihr ein Update macht auf dem PCR, wenn ihr also wisst, dass die Messung sich ändert, dann könnt ihr einen Mechanismus haben, der die Information zurückgibt an den Bootloader, sodass dann der Bootloader nicht einfach den Kernel load, könnt ihr einfach dieselbe Messung machen. Aber statt den Kernel zu laden, könnt ihr einfach das Secret rauspacken, wieder neu reinschreiben und dann mit dem veränderten PCR-Wert neu einpacken. Und dann gelbt es halt quasi in einem sicheren Kanal zwischen dem Betriebssystem und dem Bootloader. Und es gibt vielleicht eine Möglichkeit über UEFI-Werte, aber die meisten Implementierungen machen das so, dass wenn man ein Update macht, dann wird das Geheimnis ausgepackt und dann auf das, den die Festplatte gespeichert. Ihr bootet ohne Verifizierung und dann wird es wieder zurück in das TPM gespeichert. Und das ist nicht ideal, denn das führt dazu, dass man Benutzer motiviert, sich unverantwortlich zu verhalten. Und was wir, es gibt verschiedene Ansätze, auch proprietäre Ansätze, machen das nicht großartig. Ich denke, wir könnten was Besseres machen, aber da gibt es noch eine Menge Arbeit zu tun. Es ist möglich, aber es ist nicht bequem. Hi. Entschuldigung, wenn du das bereits beantwortet hast, hast du schon die Chrome OS-Sicherheit Infrastruktur angeschaut, also von den Chrome-Box? Ja, Chrome OS ist in dem Zustand, dass das TPM benutzt wird als ursprüngliche Vertrauensstelle. Also wenn man den TPM vertraut, dann kann man allem anderen vertrauen. Das heißt, es stellt sicher, dass das Betriebssystem vertrauenswürdig ist, aber es ist immer noch möglich, dass das System eine falsche Passwortanzeige anzeigt und sich dann selbst neu bootet. Das heißt, Chrome OS macht sehr viele Dinge richtig, aber es ist immer noch gegen verschiedene Angreife. Das heißt, der Laptop zeigt dir nicht gut an, dass er in einem vertrauenswürdigen Zustand ist. Er behauptet es einfach. Okay, ich bin mir nicht sicher, ob das funktionieren wird, aber ich werde drüber nachdenken. Ich habe zwei kleine Fragen. Warum ist das TPM auf dem Matterboard und nicht in der CPU integriert, sodass man es nicht so einfach entfernen kann? Wäre es nicht eine sehr einfache Lösung, den Computer neu zu starten, wenn das TPM meint, man ist nicht Trustworthy? Ja, zur ersten Frage. Die kurze Antwort ist, das hat mit internationaler Geopolitik zu tun. Die längere Antwort ist, dass TPMs in eine Kategorie von Hardware fallen, die in manche Länder schwer zu exportieren ist. Wenn Intel TPMs in ihre Hardware einbauen würde, dann könnte Intel diese CPUs in manchen Ländern nicht mehr verkaufen. Es gibt auch eine ganze Menge Leute, die von TPMs abhängig sind, aber US-Firmen nicht vertrauen. Die sind im Wesentlichen alle kompatibel. Man kann sie einfach austauschen. Wenn man sich die ACPI-Tabellen von Lenovo anschaut, dann sieht man, dass Lenovo von vier verschiedenen Herstellern auf dem selben System unterstützt. Teilweise ist es einfach nur aus Praktikabilitätsgründen, weil man sich einfach aussucht, was gerade die billigsten sind. Aber manchen Kunden wollen eben auch spezielle TPMs von speziellen Herstellern, weil sie diesem Land vertrauen. Manche wollen TPMs von verschiedenen Ländern, weil man gesetzlich verpflichtet ist. In China will man zum Beispiel ein chinesisches TPM. Das heißt, es ist ein bisschen komplizierter, als man sich das vielleicht vorstellt. Aber der Vorteil ist, wenn die CPU unvertrauenswürdig ist, dann müsste irgendjemand immer noch das TPM kompromitieren. Wenn das TPM von Infinien ist, also ein Deutsches ist, und die CPU ist von Intel, dann braucht man entweder jemanden, der sowohl in den Vereinigten Staaten als auch in Deutschland die Herstellung manipuliert. Oder du musst dich so heftig mit der NSA und dem BND angelegt haben, dass beide dich bedroht finden. Und die zweite Frage ist, dass TPM einfach die Möglichkeit hat, das System neu zu bauen, neu zu buden. Das ist mit vorhandener Hardware einfach nicht möglich. Fragen aus dem IAC? Gibt es Betriebssystemprojekte, die planen, diesen Standard zu implementieren? Also ich sehe keinen Grund, warum das Betriebssystem nicht einbauen könnten. Also es ist einfach nur Arbeit, die man halt gemacht werden muss. Ich bin noch nicht dazugekommen, aber ich bin auch extrem faul. Ein Tool, das Evil Abigail heißt, das wurde kurzlicht freigegeben. Und es hat, hast du dir dieses Tool bereit angeschaut und hast du eigentlich einen Kommentarer dazu? Ja, also das ist im Wesentlichen so eine Attacke, die hier verhindert werden soll. Also wenn der In-IT-RD verändert wird, dann wäre die Messung des In-IT-RD sich verändern und der Bootprozess wird einfach nicht funktionieren. Das TPM-Implementierung. Also es gab einige Probleme. Also du hast die Probleme beschrieben, um das TPM-Modulversuch zu berechnen. Aber kann das TPM-Modul selber SHA-1 berechnen? Nein, dieses TOTP kann man nicht HMAC SHA-1 was für TOTP benutzt wird, damit kann das TPM nicht. Okay. Was ist, wenn ein Angreifer ein Laptop klaut, ihn klont und dann den Original Laptop vergleicht misst? Das war zu schnell. Also die Frage war, ich kopiere einen kompletten Laptop und der Laptop sieht komplett aus wie meiner und der Attacker hat meinen Laptop geklaut und gibt mir einfach den selbe Wert, was der Laptop, der Live-Laptop quasi ausgibt und naja, das sieht aus, als wäre das total absurd. Wenn ihr damit Probleme habt, dann macht vielleicht, bootet euren Laptop vielleicht nur in einem fahrrad-deischen Käfig. Oder verwird ihr eine Menge Stickers auf eurem Laptop? Gibt es diese Features auch oft nicht? X86 Features? Also TPMs hängen nicht unmittelbar von X86 ab. Also es gibt auch Arm-Systeme, die TPM-basierte Funktionalitäten anbieten. In manchen Fällen Hardware-TPM, in manchen Fällen Software-TPM, das in der Arm-Trust-Zone läuft, was also ganz, ganz schrecklich ist. Und in dem Fall kann man genau dieselben Operationen durchführen. Und ob es Komplett, also Implementierungen basierend auf komplett anderer Implementierungen gibt, das weiß ich nicht. Ich glaube nicht, also wenn ihr das Problem lösen wollt, dann ist der einfachste Weg, einfach so ein TPM auf dem System zu installieren. Es gibt keine X86 spezifischen Features, die man da braucht. Könnte das auf jedem System installieren. Fragen aus dem Internet bitte. Thank you. What is the difference between your code and SecureGrab2? SecureGrab2 ist nicht von dieser französischen Organisation. Na gut, also wie dem auch sein. So weil mich meine Erinnerung nicht täuscht, war die andere Implementierung nur für TPMs, die auf Biosystemen läuft. Und meine Implementierung funktioniert auch mit UEFI. Das heißt, man kann das mit UEFI SecureBoot kombinieren. Also eines von den hübschen Sachen bei SecureBoot ist, dass wenn die Schlüsseldatenbank mit dem PCR, innen PCR gespeichert wird, also der Hashwert davon, das heißt, man kann auch sicherstellen, dass niemand mit dieser Schlüsseldatenbank Manipulation vorgenommen hat. Und das kann man für praktische Vorschriften benutzen. Also man kann zum Beispiel sagen, okay, es wird nur die Firmware und die Schlüsseldatenbank überprüft. Und dann kann man einfach sicherstellen, dass der SecureBoot für alles andere sorgt, für die Sicherheit von allem anderen. Das heißt, signierte Sachen buten dann einfach, ohne dass man da zusätzliche Arbeit machen muss. Ich denke, das ist der Hauptunterschied.