 Für uns alle jetzt Festplatten, sicher verschlüsselnd Tresor, hier ist Tilo ganz herzlich willkommen. Ja, hallo, mein Name ist Tilo Müller. Erstmal bitte entschuldigen Sie, dass das jetzt verzogen ist, das Bild, aber das haben wir gerade nicht besser hinbekommen. Ja, also ich habe in Aachen studiert Informatik, bin dann nach Erlangen gegangen, um jetzt bei Professor Freiling am Lehrstuhl zu promovieren, bin der Assistent und der Lehrstuhl dort wurde Ende letzten Jahres, Anfang diesen Jahres neu gegründet, ist also noch ganz neu. Ja, und da haben wir zusammen Tresor entwickelt. Tresor ist ein System, um Festplatten sicherer zu verschlüsseln, als das bisherige, gängige Festplattenverschlüsselung wie DMCrip, wie BitLocker usw. machen. Wir gehen da nicht auf Krypto ein oder so, wir machen auch ganz normal, ist das besser mit dem Licht? Nein. Wir machen auf jeden Fall auch ganz normal AES. Das, was wir sicherer machen, ist gegen bestimmte Seitenkanalangriffe, die ich jetzt im ersten Kapitel, das Angreifermodell nochmal genau erläutern will, warum mein wir überhaupt sicherer zu sein als andere Festplattenverschlüsselung, was genau ist das Szenario? Gegen das wir uns versuchen zu schützen. Erstmal ganz allgemein Festplattenverschlüsselung, alle gängigen wie gesagt BitLocker unter Windows, FileFold unter MacCos und DMCrip unter Linux oder das Plattformübergreifend TrueCrypt. Die basieren alle darauf, dass der Key, der zum Entschlüsseln der Festplatte ja nötig ist, der muss ja irgendwo vorhanden sein, der liegt eigentlich im Ramm bei allen vorhandenen Festplattenverschlüsselungssystemen. Ja, und so Festplattenverschlüsselungssysteme, die sind ja eigentlich dafür da halt gegen physische Angriffe auch zu sichern, also gegen Remote Angriffe, ja, wie Spionage Software, Remote Zugriff und so weiter. Da hilft Festplattenverschlüsselung nicht, sondern Festplattenverschlüsselung ist ja ganz klar für den Fall da, dass wenn ich die Festplatte verliere oder jemand anderes mein Laptop in die Hand bekommt, dass dann meine Daten noch sicher sind. Und wenn der Key im Ramm ist, werden wir gleich zeigen, dass das halt nicht immer gegeben ist. Wir werden eben zeigen, wie unten steht, dass der Hauptspeicher im Moment kein sicherer Ort zum Ablegen des Keys ist, unter bestimmten Voraussetzungen. Und einige, also der bekannteste dieser Angriffe gegen Hauptspeicher in den letzten Jahren waren halt die ColdBoot Angriffe, die auf der USNIX 2008 vorgestellt wurden von Haldermann und seinen Kollegen. Ja, die meisten hier werden, sie wahrscheinlich ganz gut kennen die ColdBoot Angriffe, ich werde es trotzdem mal kurz erläutern, also es geht im Prinzip um die Datenremanenz von so Ramm-Modulen, die da heißt, dass man auch ohne Strom die Ramm-Module noch bis zu 30 Sekunden auslesen kann. Also wenn ich bei meinem Computer kurz Strom ausmache, Neuboot zum Beispiel, dann verlieren die Ramm-Module nicht direkt die Daten, sondern die sind danach auch noch auszulesen. Man kann das sogar noch verzögern bis zu einigen Minuten, indem man die kühlt mit einem besonderen Spray. Ja, der Angriff ist jetzt halt so, dass ich den Computer, der gerade die Festplatte am Pferd oder Entschließend ist und deswegen den Key im Ramm hat, neu starte, mit irgendeinem kleinen Betriebssystem, das nix anderes tut als den Ramm zu dampen, also den Ramm auszulesen und nachher nach dem Key sucht. Genau das haben halt vor drei Jahren Haldermann und die anderen gemacht und auf der USNIX vorgestellt. Sie konnten sowohl bei BitLocker als auch bei dmCrypt, auch bei anderen Verschlüsselungssystemen den Key wirklich wieder herstellen. Die haben das für ein kleines Tool geschrieben, AS Key-Find, das basiert darauf, dass man den Key-Schedule im Ramm sucht. Der hat ja eine bestimmte Struktur, im Gegensatz zum Key. Der Key ist ja einfach nur eine zufällige Folge von Bits, deswegen haben die sich um AS Key-Schedule verlassen. Gut, also Schlüssel sind im Ramm auslesbar mit diesem Angriff. Weitere Angriffe sind DMA-Angriffe. Wie über die Firewire-Schnittstelle wurde von Dornsife vor etlichen Jahren schon mal vorgestellt. Da hatte er mit einem iPod, konnte er Ramm Inhalte lesen, aber auch manipulieren. Wenn man in System Mode schreiben kann, wird es noch komplizierter, sich vorzuschützen. Aber was ich hier jetzt hauptsächlich zeigen will, ist, Ramm ist halt aus mehreren Gründen unsicher. Und zwar bis Windows 7 zum Beispiel noch, also auch in Windows 7 funktioniert diese Firewire-Attacke, dass ich einfach einen Firewire-Anschluss, einen büßwilligen Computersteck und per DMA kritische Daten ziehe. Das funktioniert halt immer noch unter Linux, wurde das mittlerweile gepatched. Das ist treibabhängig, aber unter Windows eben nicht. Ja, und das Ganze ist halt nicht nur Firewire beschränkt, sondern kann man sich vorstellen, auch mit Expresscard ist ja im Prinzip alles eine PCI-Implementierung, halt nur per Pluck and Play und vielleicht auch Thunderbolt, ist auch noch nicht ganz klar, ob das da funktioniert. Okay, Angriffsszenarien. Das heißt, wie kann ich das jetzt ausnutzen, in welchen Fällen? Einmal habe ich gesagt, Festplattenverschlüsselung ist gerade für physische Zugriffe beide Angriffe, sowohl der DMA-Angriff mit dem Firewire als auch der Coldwood-Angriff, brauchen physischen Zugriff auf den Rechner, ist aber keine Einschränkung, weil Festplattenverschlüsselung ist offensichtlich eigentlich gegen physische Zugriff gedacht. Die andere Einschränkung ist aber schon eine, nämlich in beiden Angriffen muss der Rechner laufen. Das heißt, wenn ich mein Computer, mein Laptop ausmache, runterfahre, mindestens 30 Sekunden Ruhe lasse, bis der Rahmen wirklich leer ist, dann passiert auch nichts, wenn er geklaut wird. Allerdings gibt es zwei wichtige Szenarien, in denen der Laptop halt dennoch läuft oder zumindest in Standby ist. Zum Beispiel, also ich bin einer, ich mache mal mein Laptop, ich mache den ungen aus, ich mache den auf Standby. Und in dem Fall im Standby sind die auch noch angreifbar, die Rechner. Ja, und wenn man so einen Rechner verliert, am Flughafen oder am Bahnhof oder auch immer, dann kann halt durch die Coldwood-Attacke zum Beispiel der Key ausgelesen werden. Dasselbe wüggelt für große Surfer, zum Beispiel für Analysierungsdienste wie Tor und Annen, wird ja öfter mal eine Durchsuchung, eine Beschlagnahmung veranlasst. In den Fällen laufen die Teilen in den meisten Fällen auch. Und die Polizei könnte durch eine Coldwood-Attacke oder durch eine DMA-Attacke den Rahmen auslesen. Den Key muss man ja meistens nicht rausgeben, aber die Polizei könnte ja selber rausfinden. Das heißt, wenn man so einstellt mit unserem System, was gleich kommt, könnte man halt so machen, dass die Polizei nicht gehen könnte oder der Verbrecher bei Laptops. Ja, das war das Angriffsszenario, also RAM. Als Speicher für Keys ist definitiv unsicher wegen mehreren Angriffen. Und jetzt wollen wir kurz zwei Lösungen anschneiden, dass einmal die hartwerbbasierte Festplattenverschlüßung, dann noch Frozen Cash, was letztes Jahr vom Jürgen Papel hier vorgestellt wurde. Ja, und im Endeffekt kommen wir dann auf Tresor, dass das System, was von uns entwickelt wurde. Also, kurzer Überblick, was es für Lösungen gibt. Also, die Grundidee hinter allen Lösungen ist eben, den Key aus dem Rahmen wegzubewegen und irgendwo anders hinzutun. Jetzt die Hardware-Festplattenverschlüßung, die macht es so. Die tut den Key direkt in die Festplatte selber. Natürlich nicht da, wo es jeder auslesen kann, sondern ein extra Kryptomodul. Frozen Cash, wie der Name vermuten lässt, tut es halt schon näher zur CPU in den Cash-Dekeys. Ja, und Tresor schließt sich direkt in die CPU-Dekeys und zwar in die Register. Auf die einzelnen drei Lösungen will ich kurz im Einzelnen eingehen. Einmal die Festplattenbasierte Verschlüßung. Hardware-basierte Festplattenverschlüßung wird jetzt immer häufiger unterstützt. Ja, da wird der Key halt. Das ist ein Zusammenarbeit zwischen der Festplatte und dem BIOS. Beim Starten muss man ein Passwort eingeben. Im BIOS wird dann an die Festplatte weitergeleitet, dort gespeichert und ist dann in dieser Festplatte. Also, das auch transparent fürs Betriebssystem. Die Festplattenverschlüßung geschieht direkt durch ein Krypto-Ship auf der Festplatte und die Schlüsselverwaltung ist auch auf der Festplatte. Ist im Prinzip sicher, ist aber halt eine Hardware-Lösung. Wir wollen uns hier mal auf Software-Lösungen beschränken, weil die sind konfigurierbar offen, man sind direkt verteilbar, kostengünstiger. Aber das ist auf jeden Fall auch eine Lösung gegen diese Attacken. Das andere, was letztes Jahr hier vorgestellt wurde, sind die Frozen-Cache-Ansatz. Das ist der Ansatz, dass der Key im Cache der CPU neu ist. Eigentlich eine super Idee ist auch im Gegensatz zu Tresor. Wie wir gleich sehen, hat man den Vorteil, dass man sehr viel Platz hat im Cache. Wir registrieren sehr wenig Platz, macht also einen vielversprechenden Eindruck. Das Problem ist hier, das ist ineffizient im Endeffekt, weil eigentlich wurde der Cache halt so von Intel entworfen, dass er halt transparent für den Programmierer ist. Normalerweise sollen Programmierer, auch die Systemprogrammierer, nicht selber am Cache rumfummeln, sondern das wird eigentlich automatisch alles gehandhabt. Und das ist sehr schwierig da, müsste man im Endeffekt den Cache ganz disablen. Also Jürgen Pabel weiß da genaueres in Detail zu, auf jeden Fall, im Endeffekt ist es ineffizient. Und jetzt hatte ich gestern Abend noch mein Netzgespräch mit ihm und er meinte auch, er hätte die Entwicklung jetzt erstmal eingestellt und zugunsten von Tresor dann halt aufgegeben. Ja, jetzt Tresor selber. Die Idee bei Tresor ist, wir holen den Key in die Register und führen den AES-Algorithmus derart aus, dass nie irgendwas ins Rahmen gelangt. Also es geht hier nicht nur um den Key, sondern auch jeder Zwischenzustand von AES. Zum Beispiel der offensichtlichste Fall wäre der Key-Schedule, also AES basiert auf Rundenkeys. Auch diese Rundenkeys, sie kommen auch alle niemals ins Rahmen, weil das wird die Kryptoanalysen natürlich erheblich vereinfachen, dass man da auf den richtigen Key kommt. Und wir gehen halt soweit, dass gar nichts ins Rahmen kommt. Also auch eine Zählervariable i, die über die Runden geht oder so. Da kann man sich jetzt überstreiten, ob das vielleicht zu paranoid ist, aber dann einfach gesagt, okay, einfach gar nichts ins Rahmen. Ja, das Ganze aus mehreren Gründen nicht im Userland möglich. Das werden wir gleich noch dann im Detail sehen, im nächsten Kapitel. Weil wir müssen zum Beispiel die Register, in denen das gespeichert wird, der Key, müssten wir vor Context-Switching im Scheduling schützen. Das soll ja nicht zurück ins Rahmen geschrieben werden, zu einem Zeitpunkt oder gar durch Swapping auf die Festplatte. Und beim Suspend to Run soll es halt auch in der CPU bleiben. Normalerweise wird bei Suspend to Run die CPU ausgeschaltet und alle Register ins Rahmen geschrieben. Also was müssen wir halt verhindern. Und deswegen ist die Aufgabe nur im Kernel, es ist vielleicht möglich, nicht im Userland. Und dann haben wir jetzt so ein Tresor Kernel-Patch für Linux gemacht. Das haben wir ausprobiert zu den Linux-Diskumventionen kompatibel und zu allen Verschlüsselungssystemen, die auf der Kernel-Crypto-AP basieren. Das ist also DM-Crypt im Wesentlichen oder andere Frontends wie Cryptsetup und Cryptmount. Aber im Endeffekt basieren ja alle auf der Kernel-Crypto-API. Und ja, andere Sachen wie TrueCrypt, also so drittanbieter, Plattformübergreifende Lösungen, die unterstützen wir jetzt tatsächlich nicht. Ja, jetzt wollen wir also im nächsten Kapitel darauf eingehen, wie Tresor etwas technischer funktioniert, bevor wir dann im letzten Kapitel nochmal zur Weiterentwicklung kommen. Da unten Punkt 4 Trevisor. Also die Idee von Tresor, die ist jetzt auch schon ein bisschen älter. Ich hatte einen ähnlichen Talk auch schon mal gehalten dieses Jahr. Und ich wollte auch nochmal was Neues präsentieren und deswegen Punkt 4 danach ist die Weiterentwicklung von Tresor. Das sind wir auch schon relativ weit, die hatte ich bis jetzt noch nicht präsentiert. Das werden heute auch zum ersten Mal. Ja, kommen wir aber trotzdem erstmal zum klassischen Tresor, wie wir es bis jetzt hatten. Also Tresor, ich hatte gesagt, Tresor speichert die Schlüssel im Register. Die erste Frage ist, welche Register nimmt ihr denn da? Da gibt es nämlich mehrere Einschränkungen, die man beachten muss. Erstmal die Kompatibilität zu anderen Programmen. Wir können einfach sagen, ich nehme irgendwie die General Purpose Registers, ERX oder EBX, weil die braucht jedes Programm. Ich müsste ja quasi die Register für den Key explizit reservieren, dass kein anderes Programm auf die Register zugreifen kann, als eben eine Verschlüsselung. Zweitens soll es auch gewisse Sicherheit im, wir sind es eigentlich gegen physische Angriffe, trotzdem möchte ich es ja nicht unsicherer machen als nötig. Das heißt, ich brauche auch eine gewisse Sicherheit gegen Böse Nutzer, gegen remote Angriffe. Ich brauche einen Key schützen, und zwar so, dass er nur vom Kern-Level zugreifbar ist, also nur von Ring 0. Und außerdem brauche ich für IES 256, brauche ich halt auch meine 256-Bit. Und alle diese Forderungen, die erfüllen halt die D-Bugging-Register. Die D-Bugging-Register werden vom Endverbraucher zumindest höchstselten benutzt. Klar, ein Reverse-Engineer oder andere Entwickler, aber selbst viele Entwickler nicht, die könnten es gebrauchen, aber der normale Automationalverbraucher, der braucht es halt keine D-Bugging-Register. Die Kompatibilität ist hier meistens gegeben. Sicherheit ist dadurch gegeben, dass die D-Bugging-Register sind nur durch System Call zugreifbar. Die sind für Ring 0 erstmal explizit reserviert. Da muss man diesen P-Trace-System-Call-Unterlinung ausführen, um die zuzugreifen. Und wir haben halt genug Speicher. Wie man hier nochmal sieht. Also wir nehmen genau genommen die Breakpoint-Register. Davon haben wir vier Stück, DR0 bis DR3. Das ist ein A64-Bit, das haben wir genau 256-Bit, genug für die starke IES-Variante 256. Und zusätzlich benutzen wir die SSE-Register und die General Purpose-Register, aber nicht die belegen wir nicht ständig. Die benutzen wir, wie wir gleich sehen werden, in einem atomaren Bereich zu temporären Berechnungen und geben die dann nach wieder frei. Das heißt, Prozesse können weiterhin alle Register benutzen, außer die D-Bugging-Register. Die D-Bugging-Register sind die einzigen Register, die ständig belegt werden. Um die halt vor dem User-Land zu schützen, haben wir einfach im Linux-Gurnal diesen P-Trace-System-Call, die D-Bugging-Register irgendwie zu setzen, so gepatched, dass das halt nicht erlaubt. Und jetzt die erste Frage ist, wie kommt eigentlich der Key in die D-Bugging-Register rein? Und dafür geht der Key ganz kurz einmal durchs Ramm. Also beim Buten, sehr früh im Buteprozess, man sieht hier diesen Screenshot, dass der Screenshot, der wird dann das Bild, was ihr erleben werdet, wenn ihr mit Resort bootet. Eine der ersten Aktionen, die der Linux-Gurnal macht, ist dann, einen nach dem Passwort zu fragen, aus dem Passwort wird per Schad 256 ein Key abgeleitet, der dann in die D-Bugging-Register geschrieben wird. In dem Moment geht das alles einmal kurz durchs Ramm, weil die Tastatur-Eingaben gehen irgendwie ins Ramm, dann aus dem Passwort den Key berechnen, das geht irgendwie ins Ramm, aber das machen wir danach wieder sauber. Also wir haben Schad 256 selber implementiert, sodass alle Memory-Stellen, die irgendwie benutzt werden, nachher wieder auf jeden Fall ausgenullt werden und so weiter. Also für wenige Sekunden am Anfang geht das Ganze durchs Ramm, ist halt in dem Moment, wo man selber das Passwort eingibt und ist davon auszugehen, dass in dem Moment schnappt einem keiner ein Laptop weg und läuft dann weg. Ja, in des Weiteren erlauben wir aus Sicherheitsgrund zur Laufzeit den Key dann nicht mehr zu ändern, sondern halt nur einmal beim Starten. Und man wird denselbe Eingabeaufforderung nach einem Suspend-Rum sehen, weil da muss man den Key auch neu eingeben, weil beim Suspend-Rum wird halt die CPU ausgeschaltet und was wir verhindern ist, dass die D-Baggregister in dem Moment wie beim Kontext zwischen ins Ramm gelangen, sondern nach dem Aufwachen muss man den Key halt neu eingeben. Ja, der AES-Algorithmus selber, also jetzt können wir davon ausgehen, okay, wir haben den Key irgendwie in die D-Baggregister bekommen und der Algorithmus selber, da standen wir auch vor einigen Problemen, wir wollten ja halt keine Zwischenzustände von AES ins Ramm gelangen lassen und wir wollten keine anderen Variablen ins Ramm gelangen lassen. Deswegen können wir eigentlich keinen Compiler verwenden, der einfach den AES-Algorithmus kompiliert, weil wir wollen weder den Stack benutzen, noch den Heap, noch ein anderes Datensegment, das heißt, wir müssen das Ganze auf jeden Fall in der Sampler schreiben und können das nicht einfach in der normalen C-Spreche schreiben. Ja, und zu Glück, es gibt für die neuen Prozessoren, gibt es den AES Instruction Set und also der ist gerade bei Core i5 und Core i7 sind die vorhanden, da können wir einfach mit diesen Befehlen, die hier aufgeführt sind, ist eigentlich schon eine komplette AES 128 Verschlüsselung. Am Anfang lesen wir den Key aus den D-Baggregister in ein SSR-Register rein, führen dann im Wesentlichen hier die Verschlüsselung aus und schreiben dann den verschlüsselten Text zurück. Das Problem, also das Ganze führen wir noch automat aus, deswegen müssen wir auch den Kernel patchen, weil man kann Programme im User-Land nicht automat ausführen. Das würde ja dazu führen, dass jedes beliebige Programm alle anderen Programme lahmen legen könnte, deswegen führen wir das Ganze im User-Land, im Kernelspace aus. So, das Problem hier bei AES noch, dass wir in den D-Baggregistern nicht genug Speicher haben, um den ganzen Key-Schedule zu speichern. Also AES basiert nicht nur auf einem Key, AES hat pro Runde einen anderen Key. Und normalerweise wird aus Effizienz gründen, dieser Key-Schedule einmal für neun Key berechnet. Das macht TrueCrips so, das macht BitLocker so, das machen alle so. Also pro Key berechnet einmal mal ein Key-Schedule, die runden Keys und kann die dann effizient jedes Mal aus dem Rahmen abfragen und einsetzen. Problem ist, wir haben hier keinen Platz dafür. Wir haben nur die D-Baggregister, um den Key zu speichern und in denen es schlichtweg keinen Platz für weitere Keys, vor allen Dingen halt nicht für 10 bis 14 Runden Keys. Und deswegen haben wir den sogenannten unser Fly-Key-Schedule eingeführt. Das heißt, wir müssen die runden Schlüssel immer wieder neu berechnen. Für jeden Input-Block, den wir bekommen. Also wir verschlüsseln ja auf die Atomahnbasis von einem Block, 128 Bit. Und jedes Mal, wenn ein neuer Block verschlüsselt wird, müssen wir den runden Key, der gerade gebraucht wird, neu berechnen. Das wäre zu erwarten, dass das sehr ineffizient ist. Es müsste im Endeffekt eigentlich auch sehr viel langsamer sein, aber wir haben dann Performance-Messungen gemacht und erstaunlicherweise ist es auf Augenhöhe doch noch mit normalem AES. Also wir haben ja einmal Festsplatten ohne Festsplattenverschlüsselung und dann haben wir mit DD große Dateien, halbis Gigabyte oder mehr von einem Ort an den anderen kopiert, also auf die verschlüsselte Festsplatte. Das sind jetzt sehr geringe Zahlen. Die kommen, wer sich ein bisschen mit Festsplatten auskennt, dann denken wir, die haben noch eigentlich größeren Durchsatz. Das kommt mit dem Sync-Option von Mounton noch zustande, weil dann wird halt nix im Rahmen zwischengespeichert. Es wird immer direkt auf Festsplatte geschrieben, um halt zu verhindern, dass wir unrealistische oder nicht verliebte Testergebnisse haben. Schreiben wir halt direkt auf die Festsplatte immer. Ja und wie man sieht, sind die Ergebnisse doch auf Augenhöhe mit dem normalen AES und zusätzlich, das Tresor läuft mit diesem S&E, mit der Abschleunigung. Das Generik AES, nee, das läuft dann ohne die AES-Beschleunigung. Ja, wir haben es auch mit der AES, also der Vergleich sollte so sein, dass früher gab es ja auch dieses S&E nicht und die Leute kommen damit leben. Also ich will nur die Praxistauglichkeit zeigen. Also man kann gut damit leben, man kann damit auf Festsplatte schreiben, ohne dass man quasi eine Verzögerung merkt, die sehr viel schlimmer wäre, als vorher noch war. Also die Praxistauglichkeit ist halt gegeben, was ich zeigen wollte. Normalerweise sollte Tresor langsamer sein als AES Instruction Set wegen dem unser Fly Key Schedule, das ist richtig. Aber Sicherheit geht halt immer zu Lasten von Performance und so ist es auch hier. Wir suchen nach wegen, noch mehr Speicher irgendwo herzubekommen, um einen ganzen Key Schedule abzulegen, aber im Moment ist halt nicht möglich. Also im Endeffekt, es ist praxistauglich, es ist auch auf meinem Laptop aber Performance, im Endeffekt, vor allem wenn man in der Remdes geht, sollte sie geringer sein. Also wenn man auf Festsplatte geht, wird halt noch sehr viel davon geschluckt, dass das Festsplatten schreiben an sich schon langsam ist. Wenn man jetzt in der Remdes verschlüsselt, ähnliche Tests durchführt, dann merkt man auch einen sehr viel schlimmeren Performance-Tropec. Ja, das ist auch schon das beschleunigte AES, aber ich trau den Ergebnissen selber nicht 100%, weil wir haben das mit der Remdes nochmal gemacht und da waren sehr viel Dataman-Performsverlust gesehen. Hier sieht man einfach keinen, ich gehe davon aus, ich liege daran an diesem Sync-Option, also diese Mount-Option, und dass direkt auf Festsplatte geschrieben wird, dass Festsplatten schreiben an sich so langsam ist. Aber das eigentlich, wir haben Testergebnisse gemacht mit dem anderen Instruction Set, komischerweise konnten wir da keinen Performance-Tropec sehen und das wollte ich jetzt nicht so rauspursauen von wegen, wir sind schneller als das Normale, weil ich das glaube, aber ich konnte es halt auch nicht widerlegen. Ja, und das Weitere haben wir noch die Reaktivität im Multitasking-Betrieb getestet, also wie schnell andere Prozesse nach wie vor reagieren können. Die Sache ist nämlich die, dass wir große atomare Bereiche einführen, immer in dem ganzen Block encrypted wird, weil in diesem atomaren Bereich findet halt kein Scheduling statt, das heißt, es kann kein Context-Switch, die Register ins Ramm schreiben. Deswegen ist die Frage, wie reagiert denn der Multitasking-Betrieb darauf. Und ja, da gibt es einen Tool-Interbench, wir haben im Hintergrund eine halt schwere Verschlüsselung stattfinden lassen, große Dateien wieder hin und her geschoben, auf diese Festsplatten-Verschlüsselungspartition-Tresor, und Interbench gleichzeitig laufen lassen. Und Interbench ist so ein Tool, das testet einfach, nachdem ich CPU anfrage, wie lange dauert das, bis ich die wirklich bekomme. Und also eigentlich basiert das so auf die Idee von einem Videoplayer, also wie viele Frames per second kann ich wirklich darstellen und so. Und ja, auch hier sehen wir wieder, dass im Vergleich zum normalen IS, ja, ist ja die Relation so, dass man damit entweder leben kann oder eigentlich ist es wieder auf Augenhöhe. Ich denke mal, hier die 79 gegen über den 64 Millisekunden als Maximum ist eher so ein Ausreißer, weil das Average ist sogar leicht darunter. Also im Prinzip, nachdem die CPU angefordert wird, ist sie auch direkt da wie im normalen Betrieb. Und das haben wir noch mal belegt dadurch, dass wir gemessen haben, wie lange braucht denn wirklich ein Block zum Verschlüsseln und er braucht halt nur 500 Nanosekunden etwa. Und die Scheduling Slices von Linux, die liegen halt zwischen 50 Millisekunden und 200 Millisekunden. Also die Blockverschlüsselung ist weit unter so einem Scheduling Slices und deswegen sollte auch halt keine Auswirkungen haben. Ja, und jetzt habe ich noch fünf Minuten hoffentlich, ich habe wie versprochen, noch Neuerungen hatten uns überlegt und die sind wir eigentlich schon relativ weit mit der Implementierung jetzt und zwar geht es darum, dass Trisor im Moment noch einige Einschränkungen hat. Und zwar bei lokalen Privatescalations, also wenn irgendwer Routrechte bekommt, kann er den Key auslesen, entweder lettet sich ein Kernel-Modul, dass die D-Baggenregister ausliest, also da wäre er dann, er ist erst im Kernelspace drin, oder er schreibt nach DefkMem, das ist eine andere Option, wie man auch in den Kernelspeicher schreiben kann. Die zweite Problematik ist das Festplattenvollverschlüsselung, zumindest dahingehend etwas schwierig ist, dass der Kernel, der gepatched wurde, das heißt zumindest der Kernel muss in irgendeinem Zeitpunkt mal im Klartext vorliegen und das ist das Bootcerping-Problem. Und zusätzlich noch, wir haben keine Windows-Unterstützung, also offensichtlich, wir müssen in Kernelspace gehen und das ist halt nur mit Open Source Betriebssystem möglich, man kann auch ein BSD nehmen oder so, aber halt ein Windows, wenn nur sehr schwer, wenn man das nicht gerade binary patchen will. Ja, und dann haben wir uns überlegt, wir gehen einfach eine Ebene tiefer, wir gehen in den Hypervisor und hugen da die Festplatzzugriffe und dann haben wir nämlich alle die drei Einschränkungen schon mal weg, nämlich einmal liegt dann das D-Baggenregister in der Macht des Hypervisors, das heißt, wenn das Betriebssystem auf D-Baggenregister zugreifen will, verhindern wir das schon und damit kann auch Ruth, auch nach einer Privileged Escalation, die der D-Baggenregister nicht auslesen. Ein zweiter Vorteil ist, wir unterstützen im Prinzip relativ schnell festplattenvolle Verschlüsselung, weil nur der Hypervisor muss unverschlüsselt vorliegen. Der Kernel kann weiterhin verschlüsselt vorliegen von Linux und die ganze Systempartition und alles. Und zu guter Letzt können wir halt prinzipiell jedes OS, jedes Betriebssystem damit buten, also ein Windows oder sogar was, ein DOS oder ein Minix oder was halt normalerweise keine festplatten Verschlüsselung unterstützen würde. Das Ganze habe ich nochmal hier grafisch aufbereitet, wie wir uns das vorgestellt hatten. Also, der Hypervisor ist ein Zinnhypervisor, das heißt, er unterstützt nur einen einzigen Gast. Und dieser eine Gast ist halt das Betriebssystem, von dem die festplatten Zugriffe gehuckt werden und alle anderen Hardware-Zugriffe werden auch direkt durchgereicht. Dadurch bleibt halt der Gast effizient, nur die festplatten Zugriffe werden abgefangen und damit ist eigentlich jedes Betriebssystem zu unterstützen und das haben wir auch implementiert. Oder sind ziemlich weit damit, sagen wir uns so. Also, das Ganze ist jetzt, da programmiere ich nur noch ich dran, bzw. das Programm ist hauptsächlich, der Benjamin Taubmann, der ist auch bei uns an der Uni Erlangen. Wir haben einfach den Tresorcode übernommen und den jetzt zusätzlich halt für die Hardware-Virtualisierung von Intel erstmal, VTX und VTD, genommen. Und ja, im Moment haben wir es halt soweit, der Linux wurde erfolgreich gebotet mit einer zur Runde liegenden Tresorverschlüsselung, aber auch Windows schon. Probleme sind immerhin. Probleme, die jetzt noch zu beheben sind, ist zum Beispiel Suspender-Run, da wacht der Moment noch nicht wieder auf. Bei Windows gibt es Treiber, zum Beispiel ATI-Grafik-Kartentreiber, die wollen aus Ordnung im Grund selber D-Bange-Register schreiben. Da weiß man auch nicht, warum, aber kann man einerseits sagen, okay, ich kriege keine ATI-Treiber, ich habe noch einen anderen Platz. Es gibt auch MSR-Register, machine-specific Registers, die werden noch selten benutzt als die D-Bange-Register, vielleicht können wir da was ablegen. Und im Moment benutzt erfreundliche Installationen, das sind wir auch noch weit von entfernt, zum Beispiel, muss man im Moment halt erstmal in Hyperweise aufsetzen, Windows auf eine andere Platte und dann mit D-D darüber kopieren und schließlich das Windows-Datrum guten. Also, es sind nur ein paar kleine Ecken und Baustellen. Am Prinzip, das wird irgendwann im Frühjahr hoffentlich veröffentlicht, und das ist das, was wir hier in der OPL genau wie Tresor selber was hier zu sehen. Okay, Fragen aus dem Publikum? Vielleicht fangen wir hinten diesmal an, sonst sind wir vorne. Meldet euch bitte. Da haben wir einen. Habt ihr euch mal überlegt, mal den Key-Scheduling zu blinden mit irgendwelchen Zufallszahlen, dann könntet ihr einfach nur diese Zufallszahlen in dem D-Bag-Register abliegen. Aber für die Zufallszahlen kannst du dann auch höchstens 256 Bit in den D-Bag-Register. Ja klar, man muss ein bisschen rumtricksen, aber man könnte vielleicht einige Sachen... Ja, also im Moment hat mir einfach gar nichts frei für Zufallszahlen nicht. Aber die Idee ist gut, ja schon gar nicht, werde ich mal auf jeden Fall merken. Man könnte das jetzt zusammenarbeiten mit diesen MSAs, die ich gerade eben angesprochen habe, da vielleicht schon gucken, dass man da was ablegt und dann solche Zufallszahlen ablegen, ja. Das ist gut, danke. Dann haben wir noch eine Frage von dir voran. Ja, hallo. Und zwar mich interessiert, wie das aussieht mit VRC7. Der VRC7 hat eine hardware-IS-Einheit und habt ihr dort mal Versuche gemacht, beispielsweise, der hat ja auch ein entsprechender Register, wo man den Key abladen kann. Also wir haben im Moment uns komplett auf die X86-Struktur beschränkt. Im Moment geht es sogar soweit, dass wir... X86, ja. Das ist ein X86 und VRC7. Okay, was hat der genau? Der hat eine pätlok oder sowas nennen, das ist eine X86-IS-Einheit mit und hat noch ein Hardware-Randomgenerator drauf. Okay. Und da gibt es so schön mit Loop-IS, gibt es extra ein Patch, was das Ding so schön benutzt. Nein, also wir wollten halt standard Hardware sozusagen, also das, was jeder irgendwie hat. Das sollte eine reine Softwarelösung sein, damit haben wir uns nicht beschäftigt. Könnten wir da noch tun, ja. Okay, weitere. Du hast noch eine? Ja, genau. Habt ihr irgendwas auf Git oder sowas? Wäre mal interessant, euch einen Zwischenstand anzuschauen ob man da vielleicht diesen VR-Kram unterbringt. Mit diesem Treffisorzeug? Ja, genau, dass man das vielleicht irgendwie anarbeitet. Also wir wollten es halt erst mal soweit fertig kriegen, dass es um VR-Kram kommt. Ja, das ist schlecht Release-Often. Schmeißt das einfach auf Git und wenn es scheiße ist, ist es egal, man kann es angucken. Weitere Fragen. Bitte melden für Fragen. Aus dem Internet haben wir keine, habe ich gerade gehört. Ja, Moment, Mikro kommt. Gibt schon Statistiken zur Performance von dem Hypervisor? Ja, die waren ähnlich. Aber das haben wir noch nicht gut gemacht. Da haben wir nun mal auch wieder die Idee drüberlaufen lassen. Sobald ich im Kopf war, war es ein bisschen langsamer. Aber da kann ich jetzt gerade nichts genaues zu sagen. Muss man mal angucken. Okay, noch weitere Fragen. Ach, da vorne. Okay. Wenn ich das richtig verstanden habe, habt ihr als Problemausgangslage, dass es in der Schlüssel im Klartext irgendwo zu lesen ist? Genau, das ist im Klartext im Rahmen. Das könnte man doch mit steganographischen Methoden einfach hinkriegen, dass man den nicht mehr lesen kann. Oder man macht Chef-Hingern Winnering. Also man streut ähnlich aus den Daten im Rahmen, dass dem Anreifer quasi nichts mehr übrig bleibt, als alle durchzuziehen. Aber ich meine du, du kannst vielleicht im Rahmen irgendwie mit Office-Caching oder Steganographie sprechen, aber irgendwie ist er dann halt doch da. Und sobald du veröffentlicht was du da gemacht hast, ist es auch relativ einfach, den dann wieder zurückzubilden. Also wir wollten halt wirklich, kann man da sagen, wir machen so, es geht gar nichts ins Rahmen, dass sie beim Sichasten. Wir haben es auch ausprobiert, ob Register selber gegen Cold-Blood-Attacken anfällig sind, sind sie nicht. Also wenn einfach Neustarte sind, die natürlich gesetted und haben uns mal Gedanken gemacht, wie kann man eigentlich so Register auslesen, wenn man da irgendwie mit dem Lötkolb an die CPU geht, das ist ja ganz schwierig, was man eventuell irgendwie machen könnte, aber wir sind auch kein Elektrotechniker, wäre vielleicht auf dem Bass Code-Injecten, also auf dem Code, der eigentlich aus dem Rahmen kommt, zur CPU, irgendwie auf dem Bass Bösencode-Injecten, der halt dann doch die D-Wagen-Register wieder ausliest. Also da, im Moment haben wir keinen Rechter mit JTAG-Interface genommen. Gut, dann haben wir noch eine Frage hier hinten aus dem Raum. Entschuldigung. Habt ihr euch mal Gedanken drüber gemacht, einfach eine komplette Core von der CPU dafür bereitzustellen, durch den Hypervisor dann zu stellen? Ach so, also bei mehreren Cores haben wir es im Moment so gemacht, weil es einfach auch von der Implimentierung einfacher war, der Key wird in die D-Bagen-Register jedes Core ausgeschrieben. Das heißt, wir müssen uns nachher nicht mehr darum kümmern, passiert die Verschlüsselung jetzt auf Core 1 oder Core 2, da müssen wir nichts migrieren. Wir haben einfach auf jedem Core die D-Wagen-Register vollgeschrieben. Wie du sagst, es wäre eine Option, einfach einen ganzen Core dafür zu nehmen und die anderen drei Cores dem Rest zur Verfügung zu stellen, wäre eine Möglichkeit von der Implimentierung, vom Linux-Colonel-Patch war es so am einfachsten, wie es jetzt im Moment war. Was dann im Endeffekt performanter ist, muss man gucken, weil eigentlich, denke ich mal, liegt der eine CPU, der eine Core dann auch relativ lange brach, wahrscheinlich. Na gut, es löst halt die Speicherprobleme. Bitte? Weil du alle Register nutzen kannst. Genau, und gleichzeitig löst das die Probleme, das andere... Das ist nur eine gute Idee. Prozesse, die... Ja, das merke ich mir, ja. Schön, da können wir den ganzen Key-Scalier speichern. Okay, soweit erstmal. Jetzt haben wir eine Pause. Wir sagen ganz herzlichen Dank an Tilo für diesen spannenden Talk.