 Hallo nochmal und willkommen zum R3S, zur R3S Bühne des RC3 und zum Vortrag, hoffentlich die letzte Remote Konferenz und jetzt geht es um Verschlüsselung in militärischer Stärke in Anführungszeichen, also mit 1024-Bit Verschlüsselung von Silver und Boy, dieser Talk wird auf Englisch gehalten und wenn ihr das hier hören könnt, dann habt ihr schon die deutsche Übersetzung gefunden und dann wisst ihr auch schon, dass man im Webplayer oder in der Software die Soundspur richtig aussuchen könnt und heute Abend gibt es wieder eine Lightning-Grunde mit kurzen Vorträgen etwa so 5 Minuten und wenn ihr teilnehmen wollt, es sind noch Plätze frei, bitte geht zu dem entsprechenden Blogpost über die Information und bitte, bitte, bitte, wenn ihr teilnehmen wollt, tragt eure Telefonnummer ein, die Event-Telefonnummer ist wunderbar. Dann die Herald News Show, wir suchen auch da noch für Beiträge und Leute auf dem Laufenden zu halten, was passiert? Wir können das nicht alles wissen, deswegen sind wir auf eure Mithilfe eingewiesen, schickt uns das, die Adresse habe ich leider gerade nicht mitbekommen. Nach dem Vortrag wird es noch Fragen und Antworten geben und da könnt ihr gerne in den ganzen Plattformen, Mastodon und Twitter mit dem Hashtag r3s oder rc3r3s und so weiter oder einfach hier im Chat, hier werdet sicher ein Weg finden. Jetzt muss ich noch meinen Telefon kurz entsperren. Last but not least, Silver arbeitet beruflich mit Krypto, er macht das sehr gerne. Und er verbringt auch gerne seine Zeit da mit Krypto und Security Angriffe durchzuführen oder und er spielt auch gerne CDS. Das passt jetzt nicht so richtig. Und Boy ist auch ein Forscher für Security Themen, macht das auch beruflich, mag natürlich auch Kryptografie, Hacking und Salsa. Warum auch nicht? Okay, also eine Runde Applaus für die zwei. Hallo. Danke, dass ihr eingeschaltet habt. Ich bin Silver. Ich werde euch zeigen, wie man ein IS 1024 Verschlüsselung bricht in militärischer Stärke. Und ich werde euch ein paar Probleme zeigen, die ich in meiner Forschung gefunden habe. Also, das Projekt hat angefangen mit einem parenzischen Problem. Also, ein Freund von mir hat ein USB-Stick gefunden mit einem Vault, der mit dieser Software Secure Access von Zendesk verschüsselt wurde und der hat um Hilfe gebeten, das zu knacken. Und wir haben es versucht, aber in der Zwischenzeit wurde dann einfach das Passort gefunden, auf einem Post-It. Das hätte jetzt auch schon das Ende sehen können. Aber während ich diese Software mir genau angesehen habe, habe ich gemerkt, das ist mit jedem Gerät, also jedem Speichermedium von Zendesk, das man kauft, mitgeliefert wird. Und wenn man das benutzt und startet und das Passort eingibt und das Passort ist richtig, dann kriegt man Zugang zu den Daten. Und kann sie nun anzeigen, exportieren, also jetzt nichts Weltbewegendes. Eine ganz normale Verschlüsselungslösung, eine Vault-Lösung, eine Tresor-Lösung, wenn man so will. Und man kann jetzt hier auch die Verschlüsselungsmethode aussuchen. Standardmäßig ist hier 128 Bit eingestellt, aber mit der Premium-Version kann man auf IS 1024 hochgehen. Das hat mich etwas überrascht und dann hat es mich interessiert. Und wie ihr es vielleicht wisst, ist IS nicht standardisiert für Schlüsselgröße als 256 Bit. Und daher wollte ich wissen, wie sie das hier implementiert haben. Also habe ich mir ein bisschen genauer angesehen und habe gemerkt, dass diese Lösung von einer Firma namens ENC Security entwickelt wurde. Und auf ihrer Website haben sie sehr, sehr starke Behauptungen aufgestellt. Er behauptet, dass das ganze militärische Level erreicht. Besonders, weil jedes Mal, wenn ich diese Behauptungen sehe, dann muss ich an diesen Tweet denken, von Crypto-Dictionary. Und jetzt muss man sich genau ansehen, wie es implementiert ist. Also der Tweet war Militär, Kryptografie oder Verschlüsselung ist oft zu echter Verschlüsselung wie Militärmusik zu echter Musik. Es wird per Default von Lexar, Sony und Western Digital verwendet und ausgeliefert. Und obwohl es sehr weit verbreitet ist, aber es ist noch nicht von Hashcat oder John The Ripper unterstützt. Also forensisch ist es sehr interessant für uns, weil wir gerne eine Proofforce-Methode dafür hätten. Also falls wir das noch mal sehen. Und ich wollte jetzt wissen, ob ich AES 1024 über Proofforcen kann. Also habe ich das umkehrend den Reverse angefangen. Es ist ein PE BitBinary mit etwa 10 MB verpackt mit UPX. Also konnte ich es mit PE Explorer auch entpacken. Es gab keinen Debugschutz. Es war einfach in C++ geschrieben und mit Visual Studio kompiliert. Es war also etwas schmerzhaft, das zu reverse engineerieren. Aber ich habe GITRA benutzt. Und es benutzt einfach QT für das User-Interface und OpenSSL für die Krypto. Das erste Problem, das ich hatte, wenn man das Programm ausführt, auf einem anderen Ort als dem Speichermedium, dann kriegt man eine Fehlermeldung. Die besagt, dass die Applikation nur auf diesem Speichermedium von zum Beispiel Sony läuft. Bei Sandisk war es okay, da hatte ich einen USB Stick, aber bei Sony hatte ich keinen SSD. Also habe ich den String in Programm gesucht, im Binary. Und ich dachte, dass wahrscheinlich nur eine Gabelung ist. Und dann habe ich das einfach mal blind gewechselt. Und dann hat das Binary einfach gestartet, ohne weitere Überprüfungen. Also von da an konnte ich es überall ausführen, wo ich wollte, was sehr bequem war. Und ein weiteres Feature, das ich benutzt habe, sehr viel benutzt habe, ist GITRA Function ID. Und weil OpenSSL und Qt verwendet wurde, habe ich die Signatur von der komplierten Version der Library erstellt. Und dann konnte ich diese Signatur im Binary suchen. Und sobald es in GITRA gefunden wurde, hat es die Information direkt vor der Funktion eingefügt. Und das hilft sehr mit der Identifikation der Funktion. Und so konnte ich eben die Krypto-Funktion auch finden. Und das war unglaublich hilfreich. Und dadurch ging das Reverse Engineering natürlich viel, viel schneller. Dann habe ich beobachtet, wie das Binary, also das Programm, sich verhält. Dann habe ich erst mal das falsche Password eingegeben und bemerkt, dass nur ein Datei in diesem gesamten Einstellungsordner offen ist während diesem Vorgang. Das ist file-system.dat. Das wird geöffnet und wenn es passwortlich, der Fall ist wieder geschlossen. Das ist irgendein Vergleich mit etwas in dieser Datei stattfindet. Jetzt gehen wir mal kurz einen Schritt zurück. Das allgemeine Problem, dass wir hier versuchen zu machen, ist, dass wir ein Password-Hash-Algorithmus umkehren wollen. Wir haben also den Schlüssel, der vom Passwort abgeleitet ist. Und wir wollen das umkehren. Wir haben einen eindeutigen und zufälligen Salt-Wert, um ein Wörterbuch-Attacke oder auch eine Rainbow-Table-Attacke zu verhindern. Und heute werden hauptsächlich Algorithmen wie PBK.DF2, Ballon-Hashing, Skript und Argon-2. Das war der Gewinner der Password-Hashing-Competition. Wenn euch dieses Thema über Password-Hashing besonders interessiert, würde ich euch empfehlen, dass ihr die Literatur mit diesen Stichworten und insbesondere die Password-Hashing-Competition euch genau ansieht. Das ist sehr interessant. In diesem Projekt habe ich mich besonders mit PBK-DF2 angesehen. Der Algorithmus ist sehr einfach. Man hat den Salt-Wert und hängt den an das Passwort ran, beziehungsweise kombiniert das und das Passwort ist als Schlüssel benutzt für diese Funktion. Das macht man C mal, also C ist die Anzahl, wie oft man es macht. Und dann verknüpft man all die Ergebnisse mit XOR. Das erste Problem hier ist, okay, aber was, wenn ich ein Schlüssel wird, der größer ist, heißt dieser HMAC Output, zum Beispiel 1024 Schlüssel. Wenn ich nur diesen HMAC Wert habe, und das war jetzt ein Problem der ersten Version dieser Algorithmus. Und das lösen Sie hier, indem Sie das einfach als ersten Schlüssel sehen. Und dann lassen Sie den Algorithmus ein zweites Mal ablaufen mit einer zweiten Zahl und das einfach konkateniert und lassen das mit dem zweiten Key durchlaufen. Und jedes Mal, wenn wir so ein Key-Bite haben, wird das konkateniert, solange, bis ich ein Gesamtschlüssel habe, der lang genug ist. Und hier in dem Beispiel machen wir das acht Mal, dann haben wir den finalen Schlüssel. Das ist okay. Aber was ist im Programm, das ich jetzt hier vor mir hatte? Ich habe gemerkt, dass die Iteration hart einprogrammiert ist. Und dann haben wir eine Schleife mit der Haschfunktion drin. Und wir haben jetzt diese Hauptschleife. Und das ist fast wie in der richtigen Funktion umgesetzt. Aber es ist nicht die Hasch-MAC, sondern MD5, also eine Hasch-Funktion. Und das Passwort ist einmal gehascht und dann in MD5 wieder und wieder eingegeben. Tausendmal. Und dann ist der Schlüssel genauso ausgegeben. Ein anderer Unterschied ist, dass der Salt-Wert und die Konstante einmal durch MD5 gejagt wird, und dann X-Ort wird mit dem Output. Und das führt jetzt zu ein paar Unterschieden. Das erste Problem war, okay, ich konnte den Algorithmus sehen, aber ich weiß nicht, woher der Salt-Wert kam, oder der Salz-Wert. Ich habe diesen String gefunden, oder die Funktion, die danach sucht. Aber ja, das ist hart kodiert. Ja, und dieses String ist dann einfach der Salt-Wert. Es war zufällig, aber nicht mehr einzigartig. Also ein zufälliger Wert, aber nicht einzigartig. Also nicht mehr wirklich zufällig. Da ist natürlich gleich eine Attacke relativ offensichtlich. Man kann dann wieder eine Wörterbuchattacke fahren. Und ich habe das dann verglichen mit anderen Herstellern. Und der gleiche Wert wurde von all diesen Herstellern verwendet. Also man musste es nur für einen, eine Firma schreiben, und das wird dann überall funktionieren. Das war der erste Fehler, den ich wirklich gefunden habe, der erste große Fehler. Ein weiteres Problem ist die Anzahl der Iteration. Heute werden 310 Iterationen oder mehr für diesen Algorithmus empfohlen. Also diese Zahl von Iterationen sollte wirklich höher sein oder man sollte es updaten können in einer guten Software-Lösung. Aber es gibt ein anderes größeres Problem. Und das ist ein Konstruktionsproblem. Wenn ihr euch den blauen Teil anseht, dann seht ihr, dass es nicht wirklich mit dem Salt abhängt, vom Salt abhängt. Also da nehmen wir dann jetzt also 1000 mal den MD5 und den Wert benutzen wir dann, um den zweiten Key zu berechnen. Und dieser Faktor ist hier wirklich relevant, weil wir müssen das nicht nur einmal berechnen, sondern und wir benutzen das auch für alle Schlüssel, die wir benutzt haben, die wir generiert haben vorher. Also das ist wirklich ein Designproblem. So, und hier können wir jetzt wirklich sehen, dass zwischen dem 128-Bit und dem 1024-Bit Schlüssel ist hauptsächlich wirklich nur der unterschiedende extra Operation. Und zusätzlich können wir diese Vorberechnung benutzen, um einen Dictionary zu bauen, also eine Bibliothek. Und selbst wenn das Salt zufällig generiert wurde, können wir darüber vorgenerieren, einen Dictionary, diese Bibliothek, indem wir diese extra Werte benutzen, solange der hash konstant ist. Und das heißt selbst, wenn wir sehr nah an PBKDF2 sind, erreicht es nicht das gleiche Level an Sicherheit, weil diese Sicherheitsprobleme existieren. Okay, also das war jetzt die Schlüsselderivationsfunktion. Und jetzt kommen wir zur Schlüsselverifizierung. Und sicherzustellen, dass das Passwort von einem Nutzer korrekt ist, lesen wir diese Datei-Systemdatei, wie ich vorhin erklärt habe. Und wir entschlüsseln die Werte. Und wenn das Klartext-Passwort gleich dem Werte hier angegeben ist, dann gehen wir davon aus, dass das Passwort korrekt ist. So, das erste, was ich jetzt aber wissen musste, ist, was ist der Verschlüsselungseigerung, das hier. Wie wird diese Fast-System-Point-Date entschlüsselt? Und dieser Teil vom Code hier war, konnte nicht dekoklet werden von Gidra. Da waren ganz viele SSI-Instruktionen, die sehr schwer zu Requetszerechnen sind, zu dekompilieren. Und auch die Dekompilation hier hat nicht viel geholfen. Aber so konnte ich wenigstens irgendwie ein bisschen das mit OpenSSL vergleichen. Und habe also im Quake-Code von OpenSSL rumgeguckt und habe tatsächlich dort einen Teil gefunden, der SSI-Instruktion findet, um die IS zu implementieren. Und die waren in genau der gleichen Reihenfolge, wie das, was ich hier gefunden hatte. Also konnte ich so herausfinden, dass wahrscheinlich IS für die Verschlüsselung und Entschließung dort benutzt wurde. Und es stellt sich heraus, es war IS im Counter-Modus, im Zähler-Modus. Also für IS 128 war es ein IS im Zähler-Modus. Also relativ einfach. Also guck ich mir jetzt IS 128 an. Dafür muss es ein 256-Bit-Block sein im Zähler-Counter-Modus. Aber es waren tatsächlich zwei Interaktionen von IS 128. Aber die 9. wurde mit dem zweiten Schlüssel vor X-Rot bei der Schlüsseltelefation. Und so wird der Schlüssel-Stream dann wieder mit dem Klartext. Und so können wir jetzt bei IS 512 und IS 128 muss ich jetzt gar nicht wissen, wie das funktioniert, sondern wir machen genau das Gleiche. Wir machen mehr Interaktionen hier für IS 128 und IS 1024. Und wir benutzen nämlich diese Schlüsselderivationsfunktion. Und das können wir jetzt immer nur für die ersten 8 Bytes machen. So wurde der Counter immer schön unange- nicht mehr bearbeitet. Das musste nicht geendet werden. So, hier ist der Unterschied zwischen IS 128 und IS 1024. Es ist nur die Anzahl der IS-Verschlüsselung. Und zusätzlich war tatsächlich nur die Hälfte der generierten Schlüssel-Bits tatsächlich benutzt, obwohl wir 1024-Bits benutzt haben, wurden immer nur die Teil der Nausee benutzt. Am Ende ist das Level der Sicherheit nicht höher als das Level der Sicherheit von Passwort. Wenn das Passwort eine niedrige Antropie hat, dann kann die Sicherheit nicht höher sein als diese Antropie. Trotzdem muss man sagen, dass die Nausee generiert wurden mit dieser zufälligen Bytes-Funktion. Und daraus kamen diese Nausee. So, und jetzt in diesem Zustand des Projekts hatte ich mehr oder weniger alles, um den BruteForce zu bauen. Also habe ich ein Pathenscript geschrieben, um die Daten zu extrahieren, die ganzen Nauseen und so. Und alles, was ich für das BruteForcing brauchte. Ich habe außerdem herausgefunden, dass man falsche Positive haben kann, nach ungefähr zwei hoch 32 Kandidaten, die man durchtestet, weil man das Passwort gegen nur ein 32-Bit-World testet. Allerdings für Sandisk und Sony gibt es eine Version, wo noch ein magisches Raum dabei ist, dass diese falsche Positive dann wieder ausfiltert. Das heißt, meine Implementierung ist übrigens verfügbar hier auf meinem Github und wird bald auch noch vervollständigt. So damit jeder Fähig ist, diese IES 1024 Sachen zu brechen. Und ich hoffe, dass ihr auch meine Implementierung testet und mir erzählt, was ihr denkt. Okay, dann lass uns mal gucken, wie das funktioniert in der Praxis. Wenn wir jetzt John hier jetzt ausführen auf dem Hash mit meinem Skript, dann wird das dieses Passwort BruteForcing. Das Passwort kam hier relativ schnell, weil es in meiner Liste war. Und John the Ripper war fähig, ungefähr 7000 Passwörter zu testen und einer Sekunde. Und wenn wir das vergleichen mit PBKDF2 mit 310.000 Interaktionen, dann wird John das Passwort auch rausfinden, weil es in der gleichen Liste ist. Aber es wird das erst nach 2 Minuten finden, was wesentlich länger ist. Und das kann nur ungefähr 30 Passwörter pro Sekunde testen, was wirklich sehr langsam ist. Und das zeigt, wie der Algorithmus und die Anzahl der Iterationen, das Ergebnis hier stark beeinflusst. So, das war es für die Schlüsseldirrivation und das Passwortknacken. Das einzige, was jetzt noch fehlt für die Entschlüsselung, ist, wie funktioniert tatsächlich die tatsächliche Dateinschlüssel-Element-Effekt. Und da gibt es noch eine Datei mit all den Schlüsseln für die verschiedenen Dateien. Und die wird entschlüsselt mit den Schlüsseln, die wir gerade rausgefunden haben. Und dann werden diese Schlüssel, alle benutzen, um die Dateien einzeln zu entschlüsseln. Und wenn der Nutzer das Passwort geändert hat, dann muss man nicht den kompletten Volt entschlüsseln. Zum Glück. Wenn der Nutzer ein Passwort ändert, sondern man muss es halt immer nur für die Datei machen, das ist halt eine gute Idee. Und die Verschlüsselungssicherheit bleibt gleich. So, und jetzt noch eine Sache. Was ist jetzt aber halt der Datei-Verschlüsselungsalgorithmus tatsächlich? Es ist der gleiche, wie der, der benutzt wird, um das Nutzer Passwort zu verifizieren. Und da wird also benutzt, genau das gleiche IES 128-Bit-Modus. Und eben das Counter-Modus, im Cellermodus. Und als ich es dann aber in mein Skript ausgeführt habe um dieses IES 200, 512 oder 124-Bits zu testen, habe ich festgestellt, dass es nicht funktioniert hat. Also habe ich das Ganze nochmal ausprobiert und angeguckt. Und habe gesehen, es gibt ein paar kleine Änderungen. Der zweite Schlüssel zum Beispiel ist jetzt tatsächlich komplett gexort mit der gesamten Nause. Das heißt, die 16-Bytes von dem Schlüssel werden gexort vor der Verschlüsselung. Und es wird dann benutzt, um den zweiten Schlüsselstream zu generieren. Und das Output dann als Planetarium zu exorben. Das heißt, dann habe ich das so in meinem Skript implementiert. Aber dann hat sich rausgestellt, dass auch mit IES 500-12, wie das Däche war, mit der Schlüsselverifizierung, also habe ich es nochmal dekompiliert und rausgefunden. Und habe rausgefunden für das IES 500-12 nur zweite Ration von IES 128 benutzt worden, außer dass der letzte Schlüssel dann benutzt wird. Und das fand ich ganz interessant. Das war natürlich das gleiche auch dann für IES 1024, außer dass da nicht das achte Teil, die letzten acht von dem Verschlüsselungslüssel benutzt wurden. Und so konnte ich jetzt final die fünf Formate dekodieren. Und so jetzt quasi das IV, also die Nosse in Klartext finden. Wir haben ein Parameter, der sagt, welchen Algorithmus wir benutzen. IV bedeutet hier IES 1024. Und dann haben wir die Dateilänge. Und dann in Verschlüsselt haben wir den Dateinamen. Wir haben ein paar Nullen. Und wir haben noch ein Aufset. Und danach kommt der ganze Klartext. Und das nächste Problem, was ich festgestellt hatte, war, dass dieses CTR-Design, wenn man diese Interaktion hat, zwar mehr oder weniger das gleiche wie eine CTR-Reinfolge. Und das bedeutet, man kann Dateien immer noch bearbeiten. Das heißt, wenn jemand die Datei bearbeitet, dann wird sie komplett dekodiert mit exakt den gleichen Modifikationen. Und das wird nicht, man kann es nicht wirklich erkennen mit dieser Lösung. Das heißt, wenn man jetzt also den, diesen Tresor irgendwo in der Cloud speichern will, dann kann man nicht garantieren, dass er nicht geändert wurde. Die Nosses sind alle zufällig generiert mit OpenSSL. Das heißt, da gab es nicht wirklich ein Problem. Das war wunderbar. Aber da es auch nur zweite Rationen von IES gibt, haben wir auch allerhöchstens eine Sicherheit von 256 Bit Level quasi. Und tatsächlich ist es so, dass wenn wir sogar noch ein bisschen tiefer gehen, dann, wenn wir jetzt nur diesen verschlüsselten Datei haben, dann müssen wir nur 128 Bit Brute Forcen für den ersten Schlüssel, und dann für den letzten Schlüssel müssen wir das halt mit der AVX an. Und das heißt, wir haben nur ein Sicherheitslevel von 256 Bit. Aber wenn wir jetzt hier ein bisschen Kryptografie machen, und wir gehen davon aus, dass wir zwei Klartextblöcke haben, die 0 sind, und wir haben den Ziffertext C1 und C2, dann können wir schreiben diese Gleichung für die Verschlüsselung, und wir wissen, dass C1, IES, beziehungsweise der erste Teil, der erste Schlüssel und die erste AV gesort sind, ist von der ersten AV mit dem letzten Verschlüsselungsschlüssel. Und hier ist der Klartext relativ klar, weil er null ist, und wir können das Gleiche schreiben für den zweiten Ziffertext. Dann, wenn es so ist, dass wenn wir das dann umbauen, und dann kriegen wir diese Gleichung, die wiederum nur auf den ersten Verschlüsselungsschlüssel ankommt und nicht auf den letzten den Arten, weil es das tatsächlich sich rauskanzelt und sich rausstreicht aus der Rechnung. Und so können wir quasi alles dekodieren mit nur dem ersten Teil des IES-Schlüssel. Und so wird daraus dann am Ende GX-Vort mit AV2. Und das ist alles, was man dann braucht für das Entschlussende der Datei. Wir wissen, dass wir den korrekten Schlüssel geraten haben und das gibt uns also eine Reduktion auf nur 128 Bit Sicherheit. Das ist natürlich etwas theoretisch. Aber wir müssen davon ausgehen, dass wir das natürlich so verschlüsselt haben. Aber in der Tat ist es so, dass wenn wir jetzt einen Dateinamen unverschlüsselt haben, dann können wir diese Information nutzen, um ein Nullblock zu haben und diese Reduktion für unsere Lösung verwenden. Sobald ich meine Ergebnisse hatte, habe ich ANC Security auch kontaktiert, dieses Jahr im Mai. Sie haben das dann auch bestätigt, also die Schwächen in der Herleitung des Schlüssel. Dann wurde das an die Western Digital und anderen weitergegeben. Ich habe die dann auch getroffen, um abzusprechen, bis wann das veröffentlicht werden kann oder abwandt. Dann habe ich auch zwei Bug-Bezeichnungen bekommen dafür. Und im September hat sich herausgestellt, dass das in anderen Applikationen von Western Digital auch verwendet wird. Also haben wir die Deadline erweitert bis zum 22. Dezember. Das war jetzt alles, was ich hier gefunden habe. Und jetzt kann Boy bitte das andere zeigen, präsentieren. So, ich möchte das jetzt aus der anderen Sicht halten, von ANC Security. Also die andere Sicht der Story. Interessante Beeignisse, die noch kamen. Und vielleicht für dieses Publikum auch interessant, wie sind wir eigentlich das Design für die Fixe gefunden? Ein bisschen Hintergrund. Also die Firma wurde 2009 gegründet. Wir haben Millionen von Nutzern für unsere Software. Teilweise ist das, weil wir OEM-Version haben. Wir haben dieses Produkt also mit USB-Sticks verkauft. Oder auch anderen USB-Speicher-Medien. Zum Beispiel Sandisk, was heutzutage zu Western Digital gehört. Sony ist auch ein Grund. Und die haben das mit einer SSD verkauft. Und Lexa hat auch USB-Sticks verkauft. Genau. Also mit unserer Software. Und nur Western Digital und Sony haben überhaupt reagiert, als wir sie kontaktiert haben. Lexa hat uns nie geantwortet. Aber Sony und Lexa sind eigentlich nicht mehr unsere Kunden. Also die Timeline aus unserer Sicht war etwas anders. Also ich bin erst März, April 2021 dazu gekommen, weil sie ein internes Security Assessment machen wollten. Ich habe nicht all die schönen Sachen gemacht, die ihr gerade gesehen habt, mit Decompiling und Debugging etc. Was ich gemacht habe, sind einige einfache Tests, die ich machen kann, zum Beispiel Dateien mit Hex-Editorn anschauen und sie modifizieren. Und ich habe ganz ähnliche Sachen gefunden. Und ich habe auch einfach nur Fragen gestellt. Also woleitet ihr die Schlüssel? Wir benutzen MD5 mit 1.000 Runden. Ich habe meinen Bericht im April abgegeben und dann war ich an sich fertig. Ich bin Freelancer, also ich habe nur für sie gearbeitet. Und dann kam im Mai Silver. GNC hat das dann auch akzeptiert, hat aber erstmal nichts weiter damit gemacht. Und dann hat im Juni Silver das auch den Kunden mitgeteilt und dann haben die angefangen, Fragen zu stellen. Und dann hat GNC erstmal angefangen, das wirklich zu untersuchen. Dann haben wir von Juni bis November damit verbracht, unser Team zu vergrößern, es zu diskutieren, die Implementierung und Designs zu diskutieren, zu testen. Vorhin haben wir noch Zeit damit verbracht. Und deswegen wurde ich gebeten, auch hier wieder auszuhelfen. Am Ende haben sie es tatsächlich geschafft, eine neue Version zu veröffentlichen, die das KDF-Problem löst. Und geplant für die Zukunft ist, die Probleme mit dem Ciphertext zu lösen. Also was ist das Erste, was passiert ist? Mein Vorgesetz hat dann erstmal gemeint, wir haben hier diesen Bericht gekriegt vor dem Typen, den ich nicht kenne. Ist das überhaupt echt? Ist es, ja, etwas... Und er hatte Angst, dass es echt ist. Und weil es natürlich die gleichen Fehler sind, die vorher schon gefunden wurden. Und dann habe ich ihn gegoogelt, ja, sieht echt aus. Der Bericht ist sehr gut geschrieben. Und wenn das jetzt bezahlte Arbeit gewesen wäre, dann wäre dieser Bericht Geld wert. Also wirklich gute Arbeit. Und vielleicht sogar ein bisschen zu viel für eine Software, die es eigentlich gratis gibt. Und es war jetzt sehr spezifisch zum Produkt. Es war auch nur jemand, der gehofft hat, um sich werfen von Schlüsselwörtern ein Buck Report zu bekommen, oder eine Erwähnung zu bekommen. Also es war schon echt auch die Begriffe und die Beweise, die er geliefert hat. Die haben schon gezeigt, dass er weiß, wovon er redet. Und dann habe ich auch gemeint, Entschuldigung Leute, das ist echt, da müssen wir wirklich was machen. Und das klingt jetzt einfach. Man muss einfach nur ein neues KDF, also man muss die Schlüssel neu ableiten. Es ist schon gelöstes Problem eigentlich. Und das andere Problem, naja, authentifizierte Verschlüsselung. Aber alles ist einfach, wenn man es nicht selber machen muss. Also schauen wir uns mal an, was dann weiter passiert ist. Jemand hat uns der Bomber geschickt und wir müssen sie entschärfen. Die Firma, also das Produkt war nur im Wartungsmodus. Wir hatten also nicht sehr viele Ressourcen, mit denen wir arbeiten konnten. Wir mussten also als Allererstes das Team größer machen und mehr Leute kriegen. Und dann mussten wir überlegen, was machen wir, wie dringend sind die Probleme, können wir offensichtliche Prioritäten festlegen. Und wir mussten sehr eng mit unseren OEM-Kunden zusammenarbeiten. Also Western Digital ist auch noch ein aktiver Kunde von uns. Aber das hat mehr Aufmerksamkeit von ihnen gebraucht. Und sie wollten sich auch die Lösungen ansehen, die wir vorgeschlagen haben. Sie wollten sicher gehen, dass das Problem auch gelöst wird. Und wir haben enge mit ihnen zusammengearbeitet als vorher. Und wir mussten sehr, sehr schnell arbeiten. Also begrüßt dann. Wir brauchen mehr Leute. Wir brauchen mehr Hände. Woher nehmen wir diese Leute? Es gibt schon so viel Nachfrage für Tech-Fähigkeiten und Verschlüsselung. Es ist sehr schwer zu finden. Das außerdem werden Sommerferien passiert. Wir sind zu diesen Zeiten einfach nicht erreichbar oder reagieren nicht so schnell. Also ich war selbst im Urlaub. Es war geplant, es war gebucht, also sind wir im Urlaub. Wir mussten also alles sehr kurzfristig machen. Wir haben extra Leute bekommen, die aber alle Teilzeit gearbeitet haben. Und Teilzeit ist nicht das Beste, wenn man schnelle Lösungen will. Aber das, was wir gemacht haben, ist natürlich eine Triage. Wir haben die Ableitung des Schlüssel, also Keyderivation, angesehen. Und das ist natürlich ein bisschen riskant. Das hängt natürlich vom Use Case ab. Aber es war ziemlich klar, dass das ein großes Risiko für die Nutzer ist. Wir wollten das als erstes fixen. Und wir haben auch gemerkt, dass es eigentlich relativ einfach gehen sollte. Das andere Problem, das gefunden wurde, das Formungs- oder Meliability-Problem, das ist wahrscheinlich nicht ganz so einfach auszunutzen. Es ist natürlich ein theoretischer Angreif. Man kann also Dateien manipulieren. Aber es ist schwer zu... Aber es ist schwierig, eine gezielte Veränderung in einer Datei zu machen. Also, darauf komme ich später noch mal zurück. Und wir haben damit gerechnet, dass das sehr viel schwerer zu lösen ist. Wir haben also einen mehrstufigen Ansatz gewählt. Erst die Schlüsselprobleme und dann den Rest. Wir mussten also eine neue Funktion für die Ableitung der Schlüssel finden. Und es musste einige Kriterien erfüllen. Es muss natürlich kompatibel sein, weil wir ein fertiges Produkt haben. Und wir wollen, dass immer noch öffnen, dass damit verschlüsselt wurde. Wenn unsere User das also nicht mehr können, dann hat uns das Support ein großes Problem. Und sie würden wahrscheinlich unser Produkt nie wieder verwenden. Das ist wahrscheinlich ein großes Thema. Die Leute wollen natürlich Sicherheit, aber sie wollen auch eine gute Performance. Viele unserer Nutzer sind wahrscheinlich nicht die fähigsten oder die Menschen mit den meisten technischen Wissen. Also ist Performance schon ein Thema. Dann natürlich Security. Das war natürlich die Hauptprobleme. Also die verschiedenen Optionen, die wir dann noch hatten, waren Argon 2, Balloonhershing, Escript. Und dann ist natürlich die Frage, wie viele Literationen wollen wir machen. Die ersten drei Optionen hier, die haben da eine andere Funktion. Sie sind basierend auf Speicherplatz. Das heißt, sie brauchen sehr viel Speicherplatz, um zu funktionieren, was sie sehr gut gegen Angriffe mit Grafikkarten z.B. schützt. BDKDF2 mit Hamek und Schad 256 lässt sich viel besser parallelisieren. Allerdings. Von der Implementierung her ist diese letzte Funktion sehr viel einfacher für uns, weil wir schon OpenSSL verwenden. Und da ist es schon dabei. Die anderen Optionen nicht. Man kann die anderen Sachen wahrscheinlich mit OpenSSL kompetent zusammenbauen, aber es ist schwieriger. Und eine Sache, die hier wirklich schief gelaufen ist, ist, dass jemand etwas selber bauen wollte. Also der hat versucht, PBKDF2 selber zu bauen. Und da ist etwas entstanden, was er aussieht, wie PBKDF2 aber nicht so ist. Also haben wir uns überlegt, dass einfach zu benutzen ist. Mag war wahrscheinlich die sinnvollere Variante, weil es auch schon etabliert ist. Die anderen sind neuer. Die Frage ist, wie viel Iteration? Wir sind nämlich auf älteren Plattformen, neueren Plattformen, mobilen Plattformen. Und wir hatten ein bisschen Angst, dass es bei zu vielen Iterationen, dass es einfach sehr lange dauern würde, wenn sie ihre Partner oder ihre Volts öffnen wollen. Und sie bewölten auch nicht, dass sie dann den Support anfragen. Also wir haben dann PBKDF2 mit 100.000 Iterationen zu machen. Was ne ein überschaubare Anzahl ist. So, jetzt die großen Challenges, das zu implementieren. Wir hatten ein limitiertes Team. Und das Team war sehr schnell geformt, aber wir mussten einander kennenlernen. Und viele von uns waren halt auch, wie gesagt, nur in Teilzeit. Das heißt, wir mussten immer gucken, wer jetzt gerade verfügbar ist und wer nicht. Wir mussten erst mal ein Rhythmus finden, das funktioniert. Und das heißt, die von uns, die bei den Iterationen, wie gesagt, hauptsächlich alle Teilzeit, haben alle sehr zusammengearbeitet mit dem Testteam von West Inditutil. Und die waren tatsächlich in Indien. Das heißt, wir hatten auch noch unterschiedliche Zeitzonen. Wir mussten auch noch einige Sachen diskutieren mit Leuten aus den USA. Und noch mehr Zeitzonen. Also dann hatten wir noch die Feiertage und Festivitäten. Wir haben, wie gesagt, im Sommer angefangen. Da waren ein paar Sommerfeiertage. Und selbst während Covid waren manche Leute halt im Urlaub und so weiter und so fort. Und dann gab es noch ein Festival in Indien, das sich Fibali nennt und da super wichtig ist. Und das heißt, Leute hatten da halt eine Woche frei, weil das ist was man da macht in Indien. Und dann ein paar Wochen später war es Thanksgiving in den USA. Was wieder bedeutet, dass manche Leute nicht da waren. Dann hatten wir jede Menge Leute, die krank geworden sind. Zwei Leute haben noch Covid gekriegt. Eine Person war tatsächlich offline für zwei Wochen komplett. Und hat sie dann immer noch Zeit zum wieder über den Berg kommen gebraucht. Die andere Person hatte nicht so lange gebraucht. Wir brauchten auch eine ganze Weile, um offizielle Statements öffentliche zu veröffentlichen Webseiten zu aktualisieren, solche Sachen. Das dauert auch alles immer länger, als man denkt. Wir mussten Scopecreep verhindern. Also den Umfang des Problems eingrenzen. Weil software hat natürlich immer Probleme. Und das erste, was man, wenn man uns ein Problem findet, ist natürlich, dass man es erst mal beheben will. Aber manchmal, wenn man eine harte Deadline hat, dann muss man vielleicht sagen, ist das jetzt wirklich was, was wir jetzt gerade fixen müssen? Oder können wir das vielleicht doch einfach später machen? Wir kann auch zu ein paar Problemen, wo Apple entschieden hat, dass sie ein paar Updates machen, was einiges von unserem Code kaputtgemacht haben. Das ist natürlich auch super, dass wir halt einen neuen Release machen wollen. Aber wir mussten jetzt auch noch das Problem beheben, weil, an einem Fall Z nutzen, unsere Anwendung gar nicht mehr benutzen können. Western Digital benutzt auch noch mobile Applikationen. Und der Google Play Store hatte noch neue Anforderungen, dass wir jetzt eine neue SDK benutzen müssen. Die hat nicht gut funktioniert mit unserer Base auch zuerst. Dann hatten wir eine begrenzte Testkapazität. Da werde ich später noch was zu zeigen. Und ein Teil des Problems war, dass wir nicht nur, dass wir als EDS Security nicht die Mobile Apps testen konnten, weil wir den Code dafür nicht hatten. Wir hatten auch keine Umgebung, um sie zu testen, weil das waren alles Sachen, die bei Western Digital entwickelt wurden. Und gleichzeitig haben wir auch eine API zur Verfügung gestellt, die tatsächlich von Dingen genutzt wurde. Das heißt, wenn es Probleme in der API-Bibliothek gab, dann mussten wir das angucken, uns auch. Aber wenn es in der Applikation war, dann mussten die sich das angucken. Und unsere API funktioniert übrigens auch auf Android und IOS. Und das unterliegende Data System ist aber natürlich ein bisschen unterschiedlich. Das heißt, unsere API war also quasi zwischen einem Application Layer und dem Data System Layer. Und das hat auch nicht alles einfacher gemacht. Im Debug. Und ja, wir hatten viele, viele unterschiedliche Betriebssystems und Produktkombinationen zu testen. Und ja, ich werde jetzt mal ein bisschen versuchen zu zeigen, worum es geht. So, das Produkt heißt Data Vault. Und da gibt es die Version 6. Es gibt eine neue Iteration namens Data Vault Version 7. Das ist eine etwas andere Codebase, ein bisschen anderes, sonst ist der Interface hauptsächlich. Aber Data Vault 6 ist auch die Basis für Data Vault Lite, was die Sony Version ist, das Secure Access, was die alte Western Digital Version ist, Private Access, was die neuere Western Digital Version ist. Und das ist auch die Basis für die Vault API. Und diese Vault API ist auch wieder für nochmal drei unterschiedliche Mobilapplikationen. Und wenn wir jetzt hier an die Update-Pfade gucken, und das sind die, die wir sehen, für die Desktop-Applikation nur, weil die Software läuft ja unter Windows und Mac OS, und es muss auch auf unterschiedlichen Versionen von Windows und Mac OS laufen. Dann wollen wir zum, halt die, die alteren Versionen von Software wollen wir, dass immer noch upgradebar sind auf die neueren Versionen. Und wir wollen auch, dass Nutzer noch upgradeen können auf unserer bezahlten Version, weil das ist ja unsere Einkommensquelle. Das heißt, es sind eine Menge Upgrade-Pfade zu testen. Und es sind nicht nur Upgrades von Software zu Software, sondern auch von Dateiformaten zu einem neuen Dateiformat, das sich vielleicht ändert. So, da hatten wir auch ein paar Limitationen bei der Nutzung der Software, weil wir tatsächlich Begrenzung in den Gratis-Versionen in der Software haben, in welchen Applikaten Geräten sie laufen können. Die volle Version kann auf jedem USB-Stick oder einer Festplatte laufen. Aber die alte Version, die alte Secure Access-Version zum Beispiel, die von Bustin Digital oder Sandisk, die läuft zum Beispiel nur auf Sandisk USB-Sticks. Dann gibt es Private Access, was auf Sandisk USB-Sticks läuft, aber auch auf etwas, das sich die IExpand Charger App nennt. Und das ist ein Gerät, das sich verbindet und drahtlos ein Telefon laden und als Backup kann gleichzeitig. Das heißt, es gibt da eine App auf dem Telefon, auch für die dieses Backup machen kann. Und die Nutz ist die IExpand Charger App. Und offensichtlich funktioniert das nur, wenn man ein von dieses, eines von diesen Ladegeräten hat. So ähnlich auf der Sony-Seite, funktioniert Date About Lights auch nur, wenn man das mit einem Sony SSD verbindet. Das ist also schon alles ganz schön. Aber so, ja gut, das eine Gerät, das könnte ich jetzt bauen. Das andere Gerät hat mir mein Manager gegeben. Das dritte, das konnte ich tatsächlich nicht kaufen, das von Sony. Aber, ja, dann hackt man halt ein bisschen rum, wie in den 20ern. Ich habe früher auch ein bisschen gehackt in den 90ern, früher und in den 80ern mit alten Computerspielen auf meinem MSX. Und das Ding ist halt, dass damals ich, ja gut, ich konnte zwar die binären Dateien auf den geräten Flaschen, aber das ist tatsächlich nicht das, was wir testen wollen, weil das, was uns limitiert, ist ja eine funktionale Anforderung. Wir wollen außerdem, dass es auf allen Geräten läuft. Und das ist natürlich eine Anforderung an, dass die Skripte jetzt ganz alles bauen. Das heißt, was ich also gemacht habe, ist, ich habe mir einen Pi Zero gekauft, Raspberry Pi 0. Ich habe da einen Ambient drauf. Und ich habe ein Skript gemacht, dass das Data-System Sachen aus dem Kernel-Lad und die Vendor-Edis ausliest. Und so konnte ich zum Beispiel einen Expand Festplatte und solche Sachen haben und virtuell darstellen. Okay. Also wie vorhin gesagt, wir hatten auf jeden Fall einiges an Herausforderungen zu überwinden. Und jetzt könnte man sagen, dass die Änderung der Stiftung der Reparationsfunktion ist relativ kompliziert. Aber, und da wir die Deadline auf jeden Fall nicht erweitern durften, weil Sylvain seine Lücke veröffentlichen wollte, war es dann so, dass wir dann irgendwann am 2. Dezember geschafft haben, die neue Werte umzuveröffentlichen. Und das ist der Teil, wo die Schlüssel-Arbeitungsfunktion geändert wurde. Dann haben wir noch eine andere Sache zu ändern. Und das ist die Ziffertext-Liesbarkeit beziehungsweise Veränderbarkeit. Nicht-Liesbarkeit. Und was man hier jetzt sieht, ist der IS im Zähler-Modus. Und wie gesagt, wenn wir mehr als IS128 haben, dann machen wir mehrere Runden von dem Counter. Aber tatsächlich ist es im Endeffekt das Gleiche, wenn man sich mal mit dem Counter-Mod beschäftigt hat. Es ist nicht groß anders als ein Keystream einfach mit einem X-Ore auf dem Plaintext. Das heißt, man macht einen etwas komplizierteren Schlüsselstream mit quasi zwei Schichten. Aber im Endeffekt ist es das Gleiche. Das heißt, was ist hier also das Problem mit der Ziffertext-Veränderbarkeit? Also, wenn das jetzt hier der Klartext ist, und das ist das Wort Test in Litcrime-Bestaben, und wenn wir jetzt da den Keystream drüber legen, dann kriegen wir diesen Ziffertext. Was man jetzt natürlich sieht, weil es X-O ist, also einfach nur zwei Nullen, und wenn es Eins sind, dann ist es ein Eins, und dann ist es auch nur Nullen, wenn sie unterschiedlich sind, dann wird es ein Eins. Aber was, wenn ich etwas über einen Teil der Daten schon weiß, zum Beispiel über den Klartext, und ich möchte das ändern, wie zum Beispiel, ich weiß, dass der Klartext Test ist, dann kann ich zum Beispiel dieses kleine T zu einem großen T machen möchte, dann kann ich das machen, indem ich einfach dieses Bit, eine Sekunde, ich versuche es gerade anzuwählen, irgendwie will ich es gerade nicht in der Präsentation. Wenn ich dieses Bit zu Null ändere, dann wird es ein großes T. Und das kann ich mal handeln, indem ich dieses Bit ändere, zu Eins. Und dazu muss ich einfach nur das Bit flippen im Ziffertext, und dann flippe ich das auch im Klartext. Das ist jetzt okay für manche Applikationen, aber es geht auch noch schlimmer. Wenn man jetzt also zum Beispiel eine ausführbare Datei hat und ein Angeifer weiß genau, was die Datei ist, die verschlüsselt ist für jedes Bit, ja genau, dann können sie ja quasi diese Datei manuell ersetzen durch eine andere Datei von der gleichen Größe oder auch kleiner, aber man am Ende noch abschleiden kann. Größer kann man es nicht machen, wenn man ein Schlüsselstream nicht hat. Aber in dem Fall könnte man eine ausführbare Datei ersetzen. Es ist nicht unbedingt einfach, das zu auszunutzen. Aber wenn man es kriegt, dann ist es sehr, sehr schlecht. Also, die Lösung hierfür ist, dass wir irgendeinen Schlüsselautentisierungskord benutzen. Da gibt es unterschiedliche Möglichkeiten. Da gibt es Ziffermodi, die authentisiert sind, wie zum Beispiel GMAC oder HMAC. Und dann gibt es noch andere Lösungen. Aber ja, das klingt ungefähr ganz gut, weil es löst das Problem komplett. Weil jetzt ist es so, dass wenn nur jemand authentisiert ist und wenn jemand nicht authentisiert ist, dann versucht Dinge zu ändern, dann wird es einfach nicht zusammenpassen und dann hat man festgestellt, dass jemand das geändert hat. Allerdings gibt es zwei Methoden, wie man diese Walls benutzen kann. Wir haben Reinkopieren und Rauskopieren-Modus, was man in manchen von den Screenshots von Sylvain gesehen hat. Und das ist, wo man eine Datei einfach in den Vault reinkopiert oder einfach rauskopiert, mit zum Beispiel Drag&Top oder mit verschiedenen Klappen. Und in dem Modus muss man immer der komplette Datei lesen oder schreiben. Und dann gibt es Mounting. Also, was macht, dass der Vault reingeladen wird in der Datei-System, zum Beispiel als eine Datei-Systembuchstabe oder ein Ort in den Favoriten in MacOS. Und das gibt es zwar nur in dem vollen bezahlten Produkt, aber macht tatsächlich ein paar interessante Seiteneffekte in diesem Kontext. Weil, wenn man jetzt mal annimmt, wir haben eine Datei und die enthält den kompletten Ziffertext, weil es ist die verschiedenen Datei. Und die Mac hat das jetzt auch noch irgendwo gespeichert, wahrscheinlich im Datei-Header. Dann nehmen wir an, du würdest die Datei bearbeiten und öffnen mit einer kompletten Verifikation der Datei. Wenn das jetzt eine große Datei ist, dann wird das eine ganze Beide dauern. Wenn wir nur ein Teil der Datei ändern zu nur klein oder groß, müssen wir so oder so diese Mac neu berechnen für die komplette Datei, bei jedem Ausschreiben. Wenn wir die jetzt annehmen, wir öffnen ein paar Videodateien oder so. Dann hat man jetzt irgendwie 256 Gigabyte Filme in 4K. Und in diesen Videodateien ist normalerweise ein kleines Symbol drin, damit man direkt sehen kann, im Thumbnail, wie das Video aussieht. Und wenn wir jetzt den Vault öffnen und das Anzeigeprogramm möchte, diese Bild anzeigen, dann muss die komplette Datei überprüft werden. Von vorne bis hinten. Und das ist natürlich eine sehr komplizierte und rechnintensive Operation. Das könnte in ein Minute dauern, oder mehrere Minuten. Das wäre sehr nervig. Und wenn wir jetzt irgendeine Applikation haben, die nur ein paar Bytes in der Datei endet, dann müsste man auch wieder eine Menge Zeit aufwenden, um diese Mac 0 zu berechnen bei jeder einzelnen Änderung. Und das ist also, von einem Performance-Sichtpunkt, ist das natürlich nicht schön. Eine offensichtliche Lösung wäre, also die Datei in einzelne Blocks aufzuteilen und dann eine Mac für jeden einzelnen Block zu haben, ist das Ganze etwas verwaltbarer. Weil wenn wir jetzt nur einen bestimmten Block lesen müssen, zum Beispiel, wenn man jetzt hier guckt, okay, dann muss man jetzt hier den anderen überprüfen, um sicherzustellen, dass die ganze Datei richtig ist. Weil eventuell, wenn jetzt hier was geändert wurde, dann ist es woanders. Dann ist die Latence auf jeden Fall wesentlich leichter zu erkennen. Und es gibt einen besseren Lese- und Schreibeperformance, aber man hat natürlich auch wieder einen höheren Overhead, weil man alle diese Mac-Berechnungen für jeden einzelnen Block unterschiedlich machen muss. Und dann muss man eventuell ein Merkle Tree bauen, um gemächt zu vergleichen und so weiter. Man braucht mehr Overhead auf der Festlatte, mehr ... Und das sind meistens so bis zu 12 Prozent, manchmal vielleicht auch weniger, je nachdem, wie groß die Blöcke sind. Man hat wesentlich mehr Komplexität, mehr Fehler und Brandfälle. Und es passt auch nicht so richtig in unser Aktuellis-Software-Design. Also es wäre wirklich eine Menge Arbeit. Also, was sonst noch? Gibt es Alternativen? Ja, gibt es. Man kann einen Verstüßlungsmodus benutzen, der resistenter ist gegen diese Änderungsattacken. Da gibt es zum Beispiel CBC oder XTS. XTS ist ein gutes Beispiel, weil es wirklich sehr hart ist, da mit Dinge zu beeinflussen. Man kann es mit bestimmt irgendwie teilweise kaputt machen, einzelne Dateien, wenn man ein Schreibzugift hat. Aber man kann natürlich auch immer einfach die ganze Datei zerstören. Wenn so lange das Schreibzugift da ist, ist natürlich eh schon vorbei. Und CBC hat noch ein paar andere Optionen, da man auch einzelne Bits flippen kann. Aber der nächste Block ist dann natürlich kaputt. Es hat ein paar Melimitationen als der Counter-Modus, aber es gibt ein paar Optionen. Dann gibt es noch andere Optionen, wie zum Beispiel große Blockgrößen. Das hilft tatsächlich auch. Damit kann man immer noch halbwegs erkennen, wo in der Datei Dinge bearbeitet wurden. Das sind aber alles Mitigations und nicht wirklich ernsthafte Lösungen, weil es nicht eine komplett authentisierte Verschlüsselung ist. Es ist eine Mitigation. Es reduziert das Risiko aber absolut. Und das können wir tatsächlich jetzt noch kombinieren mit der authentisierten Verschlüsselung und den Kopflöcken der Dateien. Weil diese Kopflöcke sind natürlich das Wichtigste an Metadaten, was es gibt. Und das hat dann auch nicht so einen hohen Performance-Impact. Und das ist tatsächlich dann, was wir machen wollen, um die Veränderbarkeitsprobleme zu beheben mit diesen Headern und authentisierter Verschlüsselung. So, eine letzte Sache noch. Als ich angefangen habe mit meiner Aufgabe für dieses Ding, für EDC, war ich okay, IS 1024. Was ist das? Das gibt es doch gar nicht. Und ich habe ein bisschen diskutiert mit den Leuten von EDC, die schon ein bisschen länger dabei waren. Und es stellt sich heraus, dass das Produkt schon an viele verschiedene Firmen verkauft wurde. Und manche davon sind nicht Teil von einem bestimmten, von einem Handelsabkommen, wo das, wo bedeutet, die bestimmte Verschlüsselung tatsächlich nicht geliefert bekommen durften. Und es gibt tatsächlich Exportrestriktionen auf IS 128. Und das ist natürlich ziemlich verrückt. Das ist ja nicht so, als ob Leute nicht einfach open source Software benutzen könnten. Es ist wahrscheinlich nicht wirklich eine sinnvolle Strategie. Aber wenn deine Firma dafür verklagt werden kann es zu benutzen, dann ist das natürlich ein Problem. Aber ja, also fürs Marketing wollten wir natürlich etwas wesentlich stärkeres. Und weil Leute denken natürlich, dass 128 ein Jahr gibt, können wir das nicht irgendwie stärker machen und irgendwie nach Militärstand machen. Und Leute außerhalb der Kryptografieindustrie haben tatsächlich irgendwie einen positiveren Ausblick auf Militärstatusverschlüsselung als wir vielleicht. Und deswegen dachten wir, wir machen einfach mehrere Runden von IS 128 und nennen es 256, 512,024. Weil Leute verstehen einfach, was höhere Zahlen sind. Man kann einfach sagen, ja, wir haben jetzt acht Runden gemacht. Aber na gut, das ist natürlich was ich jetzt hier sage. Das stand jetzt nicht drauf. Aber wir machen auch nicht wirklich acht Runden. Wir machen das tatsächlich nur für das initiale Keywrapping vom Schlüssel. Aber ja, das ist im Endeffekt, das wollte ich einmal erklären, warum zur Helle diese Entscheidung gemacht wurde. Weil jeder, der sich irgendwie mit Vollschlüschen auskennt und guckt sich dieses 1024 an und denkt, was diese Leute haben, doch keine Ahnung, wovon sie sprechen. Aber ja, es ist einfach nur Marketing. Ja, damit gebe ich jetzt mal das Mikrofon zurück zu Silvan. Ja, also wie wir gesehen haben während der Präsentation, um das mal zusammenzufassen, das Level an Sicherheit ist sehr schwierig zu erkennen manchmal. Für die Lösung kommt es auf sehr viele verschiedene Dinge an. Die Algorithmen, die genutzt werden, der Arbeitsfaktor, also die No-An-Iterationen für das Hashing und natürlich die Größe der Schlüssel, die benutzt wird. Dieses Projekt war eine wirklich spannende Kollaboration zwischen uns und zwischen ANC Security und mir. Und die haben die Probleme so gut behandelt, wie sie konnten. Und ich hatte viel Kontakt mit dem Team und wir haben viel zusammengearbeitet. Und die Ergebnisse auch an den Ergebnissen, die ich gefunden haben, was nicht immer der Fall ist. Und ich bin froh, dass ich diese Präsentation teilen konnte, weil aus meiner Sicht, aus unserer Sicht, es ist immer so, dass von der Angreifersicht, es ist immer schön zu sehen, all die Dinge und Probleme, die passieren, zwischendurch bei den Leuten, die dann tatsächlich präparieren müssen, was wir kaputtmachen. Und es ist spannend zu verstehen, was deren Probleme sind. So, das ist jetzt alles von uns erst mal. Wenn ihr noch Fragen habt, werden wir die gerne beantworten in der Frage-Antwort-Session. Und ihr könnt uns aber auch kontaktieren auf Twitter und GitHub und per E-Mail. Vielen Dank. Ich möchte noch hinzufügen, dass wir auch die Zusammenarbeit sehr angenehm fanden. Wir sind sehr froh, dass du dir die Zeit genommen hast und damit du zusammengearbeitet hast, obwohl du nicht machst das. Also vielen, vielen Dank. Okay, danke vielmals. Es war ein sehr interessanter Vortrag, wobei ich zugeben muss, ich kenne mich nicht so gut mit Kryptografie aus, aber trotzdem vielen, vielen Dank. Und es haben sich auch viele Leute dafür interessiert. Und ja, Glückwunsch dazu. Kleine Erinnerung an die Zuschauer, wenn ihr Fragen habt, schickt die bitte rein über Twitter, Mastodon oder direkt im ISC mit dem Hashtag R3S, oder im Channel R3S, im ISC. So, wir haben auch schon Fragen, was alle erst ist, bevor ich es vergesse. Von Leuten hier, direkt hier im Saal. Wie anstrengend oder wie schmerzhaft war es, das zu entdecken und dann wieder zu reparieren. Also, ich bin es nicht gewohnt, das zu reversieren. Es war nicht so anstrengend. Ich wollte mir ansehen, ob es mir anschaut, aber es war anstrengend. Ansonsten ziemlich angenehm. Es gab keine Debugging-Schutz. Und Function ID hat ganz gut funktioniert. Also, es war auch ganz angenehm. Vielen Dank. Erste Frage aus dem Publikum. Sind die Anzeichen, gibt es Anzeichen, dass das wirklich benutzt wird oder habt das nur ihr? Es wird verwendet von vielen Personen, hauptsächlich die Sandisk USB 6, aber ich kann keinen tatsächlich in Zahlen nehmen. Aber es ist eine ordentliche Anzahl an Leuten. Also, das Setup habt ihr nur mit genau den Kunden oder den Geräten gesehen, wie ihr beschrieben habt. Das ist jetzt nicht außerhalb benutzt. Also, das wird jetzt nicht in der Industrie benutzt. Nein, das ist kein Industriestandard. Sicherlich nicht. Aber was wir sehen können, ist das Update-Request zu reinkommen. Die Software hat eingebaute Update-Funktionalität und wir können sehen, dass da Anfragen kommen auf dem Server nach neuen Versionen, aufs neue Version gibt. Und das meldet auch die Versionsnummer, die im Moment verwendet wird von der Software. Aber da können wir schätzen, wie viele Leute das verwenden. Vielen Dank. Würde ein fähiger Endnutzer das benutzen wollen dieses Software oder würde er eher besser verbreitetes Software nutzen? Oder die eingebaute Betriebssysteme? Es ist ein bisschen anders als Full-Disk Encryption. Es ist Verschlossung auf der Datei-Ebene und es ist eine ziemlich einfache Lösung. Es ist dann auch auf der Festplatte eingerichtet und wenn man sich nicht besonders auskennt oder sich in diese Art Software auskennt und dann kann man es verwenden, ist es ziemlich einfach. Okay. Aber ich muss jetzt die Frage ein bisschen interpretieren. Ich bin nicht ganz sicher, ob das die Intention war. Aber ich würde das so verstehen, würdet ihr empfehlen, dass der Software benutzt, wenn der Nutzer sich schon ein bisschen auskennt, dass der Nutzer damit wirklich seine Dateien schützt oder benutzt ordentliche Softwareverschlüsselung und lasst das Programm hier? Also die Beispiele, die wir in der Frage bekommen haben, sind alle Verschlüsselungen auf der Block-Ebene. Das funktioniert nicht für alle Szenaris. Also wenn man Datei-Verschlüsselung braucht, dann muss man etwas anderes verwenden. Und da gibt es auch andere Alternativen, selbst Open Source Alternativen. Aber was ich glaube, ist sehr interessant, besonders in der Kommunikation mit Sandisk, ist, dass man es auch auf dem iPhone verwenden kann. Man kann nicht unbedingt alle US-Basics auf dem iPhone verwenden. Da muss etwas besonders passieren, dass es als Hersteller funktioniert. Und die Software von Sandisk hat eine verständliche Solution drin. Und ich mag das. Okay, danke. Habt ihr euch angesehen, eine spezielle Programme? Okay, bitte. Nein, das haben wir uns nicht angeschaut. Und nicht in dem Sinne, dass wir, aber wir können nicht den Device mehr von Linux verwenden, weil das Windows oder Mac OS ist. Und es geht um Datei-Verschlüsselung und nicht Block-Verschlüsselung. Okay. Wie hat die Migration bestehender Vaults für den Endnutzer funktioniert, also alte Dateien? Ja, es ist eigentlich ziemlich einfach. Sobald man eine neue Version startet, öffnet man ein Vault und es sagt dir, das Vault wurde aktualisiert, das war es. Man muss es öffnen, man muss das Passwort eingeben und dann wird das automatisch gemacht. Das heißt, der Verschlüsselungsschlüssel wird noch mal neu verschlüsselt und wir schreiben auch den Vault neu, weil die vorherige Version eine Staffel in Vault hatte, wie es sozusagen korrekt herausgefunden hat. Also müssen wir einen neuen Vault schreiben für jedes Vault, und das tun wir auch. Und natürlich muss der Verschlüsselungsschlüssel neu verschlüsselt werden. Oh, danke. Und jetzt erst mal die letzte Frage. Was denkt ihr über ECC in militärischem Level von Verschlüsselung? Ich habe noch nie von ECC military grade Verschlüsselung gehört, aber ECC sind Fehlabregende Codes, glaube ich. Aber, ja. Okay, vielen Dank. Dann sehe ich jetzt erstmal keine weiteren Fragen. Nein? Okay, dann danke nochmal viermal für den Vortrag. Es war wirklich interessant. Und nochmal das Interesse aus der Community war definitiv vier. Also vielen Dank. Ich habe nur noch eine Anmerkung. Also mein Pro-Request zu dem Repository wurde gemerkt. Also muss man das jetzt einfach aktualisieren und muss nicht meine Version verwenden für John the Ripper. Sehr schön. Das ist doch gut. Wir haben doch eine letzte Frage noch. Und ich denke, wir haben so viel Zeit. Habt ihr mal probiert, kompatibel zu anderen Datei Verschlüsselungen zu sein, zum Beispiel ANG-FS? Nein. Okay, danke. Damit würde ich hier schließen und gebe euch an die Backstabler.