 Ja, wir kommen beim Vortrag über Krypto. Die Zielgruppe ist alles, was irgendwie so ein bisschen mehr Technik zu tun hat, entweder in der Umsetzung oder auch in der Entscheidung. Der Vortrag besteht aus zwei Teilen. Grob einmal die Frage, warum sollte ich überhaupt kryptografische Maßnahmen umsetzen? Und der zweite ist, was gibt es denn da für Möglichkeiten? Das wird ein relativ dichter Talk sein. Im Sinne von, ich werde viele einzelne Punkte beleuchten, wer jetzt aber nirgendwo ein Diebdive machen können. Das heißt, wenn ihr irgendwie Fragen habt, dann vielleicht auch im Nachgang nochmal. Wir haben auch ein bisschen Zeit für Q&A nachher. Vielen Dank übrigens hier an die ganze Orga. Ich glaube, das war eine Menge Arbeit und da kann man eigentlich nur besten Dank sagen. Okay, ganz kurz zu mir. Das photo ist schon ein bisschen älter, aber das ist das Letzte, wo ich noch nicht so alt aussehe, wie ich bin. Ich mache seit eigentlich Ewigkeiten IT in verschiedenen Formen, Farben und Rollen. Und meine liebste Position ist eigentlich so genau die zwischen Hardcore-IT und wo IT benötigt wird, also irgendwo im Business. Wenn man die Quick Summary, wenn ihr irgendwas mitnimmt, dann sollte das sein. Nummer eins, alles, was ihr tut, ist reguliert. Spätestens durch Gesetze. Meistens noch durch ganz, ganz viele andere Sachen. Krypto ist ein Mittel, um viele dieser regulatorischen Anforderungen zu erfüllen. Klingt alles total langweilig, ist es aber nicht, aber es ist nicht umsonst. Allerdings, keine Krypto kann vielleicht noch viel teurer werden, also muss man da genau reingucken. Und extrem wichtig, Krypto und kryptografische Maßnahmen sind immer Last Line of Defense. Also, wenn die Daten das Unternehmen verlassen haben, dann sollte ich trotzdem noch halbwegs gut schlafen können. Aber sie sollten erst gar nicht das Unternehmen verlassen. Okay, vielleicht Warnung, eine Stunde, ihr seid danach weder die Experten noch Kryptografen. Erstaunlicherweise bin ich auch keiner von beiden. Das macht aber nix. Fangen wir an, ihr habt Daten, mit ihr ist irgendjemand, der euch Geld gibt, gemeint. Die Daten werden gesammelt, sie werden verarbeitet, im Sinne von wertschöpfend eingesetzt. Im Regelfall gammeln sie dann relativ lange irgendwo rum, weil man könnte sie noch mal brauchen. Irgendwann werden sie gelöscht, das ist optional in den meisten Unternehmen. Was ist das Problem dabei? Daten haben so ein Business Value, das ist der grüne links. Also ich sammel und verarbeitete Daten, weil irgendwo nach einer ganz, ganz langen Kette irgendwo Geld rausfällt. Das ist die Hoffnung. Und Daten haben aber auch immer ein gewisses Potenzial Schmerzen zu verursachen. Das können Kosten sein für Storage, für Backup. Das können regulatorische Anforderungen sein, die man plötzlich nicht mehr erfüllt. Das können einfach nur die Frage sein, wenn die Daten weg sind, stehe ich auf der dritten oder auf der ersten Seite. Wenn man sich das so klassisch anguckt, stellt man fest, der Business Value nimmt über die Zeit ab. Leider tut das die Liability, also das Problem mit den Daten nimmt überhaupt nicht ab. Und irgendwann hat man den Punkt erreicht, dass man mit den Daten weniger Gewinn macht, als man Risiken eingeht. Also, die allererste Maßnahme, die man treffen sollte, wenn man sowas sieht, also erstmal sowas aufmalen und dann sollte man aber früher löschen. Was weg ist, muss nicht geschützt werden. Das klingt total verrückt, aber was ist so? Also es ist schwierig, Leute davon zu überzeugen. Gerade Leute, die dafür bezahlt werden, möglichst viele Daten zu haben. Ich sag nur irgendwie, dass der klassische Produktmanager danach vorhanden in Registrierungen bezahlt wird und nicht nach aktiven Benutzern. Der hat natürlich einen Incentiv zu sagen, ich möchte eine Registrierung behalten, ob sie gibt oder nicht. Und ob das Mickey Mouse ist oder Teotest ist mir egal. Aber letzten Endes ist ja das Ziel, dass ich Geld verdiene und das kriege ich nicht durch Daten, die rumliegen. Es ist also nicht nur ein technisches Problem, es ist größtenteils ein Management-Thema. Was meine ich mit Inhaltsverschlüsselung? Also A, Airbag, sage ich gerade schon mal. Und B, das ist, so wie die meisten von euch wahrscheinlich gelernt haben, Software zu schreiben, eine Datenbank, da drüber hätten Applikationen, unten ist irgend so ein Kleint. Ihr seid total super, ihr habt TLS selbst bis zur Datenbank. Wie läuft das ab, Herr Kleint, der macht irgendwas und schickt es zum Server. Der Server massiert die Daten ein bisschen und irgendwann landen in der Datenbank. Die Daten sind mit TLS geschützt, also super, Problem gelöst, ihr könnt nach Hause gehen, das war ein kurzer Talk, es gibt kein Problem. Also es gibt fast kein Problem, außer da, da und da auch noch. Das Problem ist das folgende. Angenommen, die Daten werden zehn Sekunden verarbeitet und werden zwei Jahre irgendwo gespeichert. Dann sind sie, ich muss kurz lesen, 99 und ganz viel 9% der Zeit nicht geschützt, also zumindest nicht kriptografisch geschützt, das ist relativ viel. TLS ist auch super, das Problem mit TLS ist, es ist super, wenn man es richtig konfiguriert und die Aktuellste Version hat und nicht IE6 unterstützen muss und und und. Ihr habt auch gar nicht hier Backups geredet, also jedes Bit, was ihr irgendeiner Datenbank stehen habt, habt ihr im Schnitt ungefähr 14 Mal auf irgendwelchen Backup-Medien. Also um was geht es, die Daten kriptografisch schützen. Da steht überall encryption, aber das ist noch viel mehr. Das heißt, eigentlich ist der Weg, ich will von dieser komischen roten Welt in die grüne Welt. Wenn ihr jetzt genau hinguckt, stellt fest, dass der Kleint irgendwie noch ungeschützt ist aus Gründen, weil das ist im Regelfall komplexer und das will ich jetzt gar nicht beleuchten. Zumal da die Daten herkommen und nicht im Regelfall in der Verantwortung des Verarbeitenden sind. Warum sollte ich überhaupt was tun? Ein kurzer Tipp, am Ende von dem Teil holen meistens irgendwelche Leute Zettel raus und schreiben was auf. Warum seht ihr gleich? Das Gesetz, also jetzt nur Deutschland, aber das ist völlig irrelevant, wo ihr seid, hat ganz lustige Vorstellungen davon, was mit den Daten der Bürger passieren soll. Im Regelfall sollen sie gut geschützt werden. Und in ganz vielen Gesetzen stellt Kriptografie als ein wirksames Mittel zum Schutz der Daten dran. Was heißt denn das? Bitte nicht lesen. Also das ist jetzt im Bundesdatenschutzgesetz, das ja bald erneuert wird, stehen so hässliche Sachen drin, wie wenn besondere personenbezogene Daten, also das wie sexuelle Ausrichtungen, politische Meinungen, wenn die verloren gehen, dann müsst ihr die Leute informieren. Das ist schon eklig. Wenn ihr das nicht könnt, weil es zu viele sind oder ihr es nicht genau wisst, dann müsst ihr sie trotzdem informieren. Und der Text heißt überregionale Tageszeitungen, mindestens zwei Stück halbseitige Anzeige. Also ich möchte die nicht aufgeben. Telemediengesetz betrifft alle, die eine Webseite haben, for profit. For profit heißt so viel wie, da ist ein Affiliate link drauf oder Werbung. Also die for profit Schranke ist sehr weit unten. Die Bußgeldvorschrift mit bis zu 50.000 Euro. Da muss man schon mit Vorsatz und Nachdruck mehrfach machen. Für das klassische Unternehmen sind 50.000 Euro jetzt so kein Drohpotenzial. Trotzdem sagt auch das Telemediengesetz. Eine Maßnahme nach Satz 1 ist insbesondere die Anwendung eines als sicher anerkannten Verschlüsselungsverfahrens. Ich merke, das zieht es ein bisschen durch. Das TKG, e-mail-Server, mehr als 10.000 Kunden, ihr hängt dem TKG. Viel Spaß. Hat ähnliche Anforderungen, nur dass sie noch einen ganzen Tick höher sind. Strafgesetzbuch, okay, wie kommt das Strafgesetzbuch zu Krypto? Okay, das ist jetzt irgendwie ein bisschen länglich. Fangen wir damit an, ihr seid ein Anwalt. Und ihr schickt irgendwelche Rechnungen oder irgendwas anderes an Klienten und der Klient davor nicht gesagt, tu das. Dann hängt ja da drin, Strafgesetzbuch, Verletzten von Privatgeheimnissen. Weil der ISP ist witzigerweise auch ein Dritter. Sind die Daten verschlüsselt, dann sind die Daten für den ISP nicht lesbar und von daher auch keine Verletzungen des Strafgesetzbuches. Sozialgesetzbuch will ich jetzt gar nicht darauf eingehen. Ist mir so kompliziert, kenn ich ihn nicht aus. Aber wenn man nach Steuerung F nach Krypto sucht, dann findet man was. Der Elefant, Datenschutz-Grundverordnung, auch die Datenschutz-Grundverordnung, Säulenumisierung und Verschlüsselung, personenbezogener Daten, sind Maßnahmen, die gefordert werden. Insbesondere müssen Vertraulichkeit und Integrität der Systeme sichergestellt werden. Und ja, die EU-Datenschutz-Grundverordnung hat im Gegensatz zu den anderen Gesetzen wirklich wirklich Zähne. Also Wiederholungstäter, die es mit Absicht machen und mehrfach erwischt werden können, bis zu 4% des Jahresumsatzes an Strafe zahlen. Wird das passieren? Nein, natürlich nicht. Wir haben alle Angst vor, aber das ist schon Serienmord mit Ansage. Man kann das tun, aber nichtsdestotrotz, das Potenzial ist da. Wenn ich mal so einen großen Konzern angucke, welchen auch immer, 4% des Jahresumsatzes vom Konzern, das ist eine Menge. Und so ein Konzern hat viele, viele kleine Unterstrukturen. Okay, ich sage gerade Konzern. Jeder Konzern und so ziemlich jede größte Firma hat Richtlinien, interne Richtlinien, die mit Daten umzugehen ist. Tipp, wenn ihr eine Firma seid, die das nicht hat, wäre ich vorsichtig, weil das auch Richtlinien sind, die sich zum Beispiel auf den Schutz eurer Personalakte beziehen können. Andere Vorschriften, die PCI DSS, also Kreditkartenverarbeitung, ISO 27.1, alles hat irgendwo kriptografische Maßnahmen drinstehen. Ihr seid nicht überzeugt, ich kann es verstehen, also Drüge, langweilig. Wir fragen Leute, die sich auskennen, also die Frau zum Beispiel. Das ist Dito Harding zu dem Zeitpunkt CEO von Talk Talk. Also jetzt nicht verwechseln, also ich will die nicht basten. Also die jetzt nur ein bisschen. Aber grundsätzlich shit happens, man kann es nicht verhindern. Wenn man jetzt mal kurz hinguckt, die sieht nicht glücklich aus. Aber es könnte euer CEO sein. Aber ihr wollt, also ihr wollt eigentlich einen glücklichen CEO haben. Bei letzten Endes ist der CEO verantwortlich, wird irgendwo Dinge passieren. Also euer Chef soll nicht so in den Nachrichten sein. Und wenn er das ist, dann solltet ihr dir versorgen, dass der Blitz nicht bei euch einschlägt. Der Punkt da vorne, das ist der Moment, in dem Talk Talk gesagt hat, dass die ein kleines Problem den Kundendaten haben. Der Aktienkurs ist nicht wesentlich besser geworden. Und das war, bevor die 400.000 Pfund Strafe kamen. Genau, die Strafe, was haben wir noch? Ach Gott, der CEO ist weg. Und Kurs, nachdem der CEO weg ist, hat sie den nächsten Vorfall. Also ja, das hat also real-world implications, wenn so was passiert. Kennt einer Ashley Madison? Ich hab's nicht gewusst, aber die wollten in die Börse gehen. Er hat nicht funktioniert. Übrigens, die Besitzerfirma von Ashley Madison hat wegen dem Vorfall auch noch einen reingedruckt bekommen. Der war nicht klein. Okay, das ist von Tripwire. Sie verdienen der Geld damit, dass ihr Angst habt oder eure Firmen Angst haben. Nichtsdestotrotz sagen die Fortune and 100 Companies, eine ordentliche Data Breach hat langfristig 1,8% Börsenverlust zur Folge. Bei so einer Firma, die ein paar Milliarden wert, ist es 1,8% echtiel. Okay, Twitter, auch da, die sind super umgegangen damit. Das war perfektes Umgehen mit einem Sicherheitsvorfall. Leute, eure Passwörter sind in Logs aufgetaucht. Ich glaube, es ist nichts passiert, erinnert euer Passwort. Also, vom Vorgehen her, die meisten Firmen würden sagen, es ist nie passiert. Das haben sie gut gemacht, aber dem Aktienkurs hat es nicht gefallen. Der Strich da unten ist jetzt kein Darstellungsfehler. Die Liste kann man weiterführen. Das ist jetzt irgendwie müßig, das irgendwie weiterzuführen. Die Aussage ist unabhängig von Compliance und Legalforderungen. Sicherheitsvorfälle kosten richtig, also echtes Geld und echte Jobs. Nächste Frage, okay, jetzt habe ich gesagt, mach doch Krypto. Das hilft euch. Wie mache ich denn das? Fangen wir mal ganz einfach an. Was ist das Problem? Welche Daten habe ich? Und wie sind die zu betrachten? Wie muss ich diese Daten behandeln? Und wie tue ich das dann am Ende? Also, ganz am Anfang, ihr nehmt euch irgendein Experten, also ein Legalexperten. Muss kein Rechtsanwalt sein, aber einer, der die Fachtormäne versteht. Dann listet ihr alle Daten auf und dann klassifiziert ihr diese Daten. Und dann nehmt ihr euch ein Manager und der Manager muss euch sagen, was ist das Problem? Also, wie hoch ist das Risiko, was mit diesen Daten einhergeht und welches ihr vielleicht bereit zu tragen? Dann listet ihr, könnt ihr dann so aussehen. Ich habe einen Kunden, ich habe eine Marketing-E-Mail. Es gibt bestimmte regulatorische Anforderungen, zum Beispiel an den Namen und an die Kontonummer. Dann geht euch noch ein bisschen weiter ins Detail. Besonderes, personenbezogenes Datum bei der Kontonummer. BDSG, Paragraph, was war es, 240. Das Problem ist, die Klassifikation, das ist jetzt nicht so 0815, das hängt mal vom Kontext ab. Also, E-Mail-Verteiler, AIDS-Test, hat die E-Mail-Adresse, die da drauf ist, eine andere Aussagekraft als von Aldi oder Fitnessclub oder Diele. Das muss man im Detail betragen. Ja, es ist, ich mag jetzt überraschen, aber es ist so. Wenn ihr eure Daten habt und wisst, was die gesetzlichen Anforderungen sind, dann müsst ihr als Nächstes gucken, wie leid ich diese gesetzlichen Anforderungen so ab, dass ich die umsetzen kann. Also, wie speichere ich die Daten, wie übermittel ich die Daten, wie protoriere ich die Daten, wie sichere ich die und vielleicht auch noch wie lösche ich die Daten? Oder wann sieht dann so aus? Der Name darf im Plain Text gespeichert werden, aber nur verschlüsselt übermittelt werden. Im Blog darf man obsidianalisiert auftauchen, im Backup nur verschlüsselt und löschen nach, wo es Datenschutz gesetzt. Sobald die Nutzung der Daten wegfällt. Also, das muss man auch mit Liegel so ein bisschen besprechen, aber das ist primär dann, dass ihr einen Vorschlag macht und Liegel muss sagen, ah, verstehe ich. Und dann muss es umgesetzt werden und eingeplant werden. Pro Tipp, wenn ich sage, ich mache Volltextverschlüsselung für alles, wird suchen schwieriger. Also, das gibt man so ein Trade-off zwischen Schutz und welche Auswirkungen hat der Schutz. Was ist das Problem und wie gehe ich damit um und letzten Endes umsetzen. Jetzt gehen wir ein bisschen ins Detail rein. Das war jetzt alles ein bisschen High-Level, bla, bla, bla, vorab. Also, Krypto ist irgendwie Power-Tool. Wenn man das irgendwie falsch benutzt, dann kann das mal ein Auge kosten. Also, nachdrücklichen Auge kosten. Das heißt, man sollte sich in jedem Projekt, dass ich damit beschäftigt, jemanden reinholen, der sich damit auskennt. Man kann so viel falsch machen, das ist unglaublich. Man merkt es gar nicht, das ist das Schlimme. So sieht alles super aus. Und dann steht man in der Zeitung mit, die Idioten haben es falsch gemacht. Kein Vorkommen, missvorgekommen. Das war ja ganz vorne an. Ich habe gesagt, man muss was tun, aber man kann ja auch Panomid sein. Also, irgendwo muss man sagen, hier ist die Diskussion zu Ende. Das ist vertrauenswürdig und das andere vielleicht nicht mehr. Trust Anchor. Also, ich habe eigentlich zwei Sachen. Das ist mein Bedrohungsszenario und quasi die Kehrseite davon, wie vertraue ich eigentlich bedingungslos. Ein Beispiel. Ich habe irgendetwas, wo ich sage, das ist wahr. Man kann nicht so ganz induktiv sagen, wenn das eine wahr ist und bestimmte andere Bedingungen auch wahr sind, dann kann ich diesen Trust erweitern. Andere Sachen auch wahr. Das heißt das, ich vertraue meinen Club Provider. Dann glaube ich auch, dass der kryptografische Schlüssel sicher verwalten kann. Wenn das geht, dann können die Daten mit diesen Schlüsseln verschüsseln und diese Daten sind ebenfalls sicher. Wenn das so ist, dann kann ich meine sensitiven Daten in der Cloud speichern. Wenn irgendetwas da vorne ist, die nicht mehr stimmt, dann stimmt das hinten auch nicht mehr. Das muss halt jeder für sich selber wissen. Fangen wir andersrum an. Ich benutze eine Cloud. Wenn ich eine Cloud benutze, dann muss ich auch hoffen, dass die Umsetzung des Cloud Acts nicht dazu führt, dass meine Daten plötzlich weg sind. Das heißt, ich muss hoffen, dass der Typ da rationaler Entscheidungen fällt. Auch das kann jeder für sich selber entscheiden. Jetzt habe ich gerade gesagt, wem ich kann nicht vertrauen. Trustenker, drehen wir es mal andersrum. Bedrohungsanalyse. So klassisch kennt man ja Thread Modeling nach Stride oder technische Analyse. Ich habe eine Verbindung, wenn die einer angreift, injected, abhört, was passiert da an. Aber viel interessanter ist die Business-Zeit. Auf der Business-Zeit gibt es ja auch Bedrohungen, und das sind eigentlich die, wo das Geld drin ist. Also was meine ich damit so was? Was ist so eine Bedrohung? Die Attacker-Horden von außen? Nicht subtil, aber vielleicht effektiv. Dann gibt es die Schlauerinnen, die bei euch im Support anrufen und sagen, Hallo, ich bin da, ich habe ein Passwort vergessen. Ja, das geht auch. Jedes System hat irgendwo Lücken und die schlauen Leute genutzen diese Lücken aus. Dann gibt es Spionage. Ich mag es gar nicht glauben, aber wenn das Unternehmen irgendetwas kann, dann gibt es da Begehrlichkeiten. Und dann gibt es so was wie legale Beweggründe, Beschlagnahmungen, ich sage nur Cloud-Act. Das sind die Richter, also die relevanten Bedrohungen, also von der Business-Zeit her. Ob TLS sicher ist oder nicht, das ist Mittel zum Zweck, das TLS zu haben, sondern das Ziel ist, was auch immer da nicht passiert. Also eure Firma, solche Firma, ich habe eine Anwendung, die ist gehostet irgendwo in der Cloud. Bei einer Firma, die irgendwo Dependants in den USA hat. Eure Daten sind verschlüsselt. Der Schlüssel ist beim Cloud-Provider. Die erste Frage, wenn man sich stellt, muss das so sein? Das Schlüssel des Cloud-Providers oder sollte das euer Schlüssel sein? Sagen wir, das ist euer Schlüssel, dann kann der Cloud-Provider trotzdem noch gezwungen werden, den rauszurücken. Also die nächste Frage, wer hat denn den Schlüssel? Sinnigerweise habt ihr den. Das Problem ist jetzt, jeder dieser Schritte kostet Geld. Und kryptographische Schlüssel außerhalb der Cloud zu lagern, um sie dann in der Cloud zu verwenden, das ist jetzt irgendwie kein dünnes Brett mehr. Aber nachdem welche Bedrohungslage ihr habt, irgendwie hoch eurer Schutzbedarf ist, kann das ein oder andere richtig sein. Das war jetzt alles irgendwie so oberflächlich und von oben herab, im Sinne von so 3000 Fuß. Gehen wir ein bisschen ins Detail rein. Ganz oft gibt es die Herausforderung, dass Daten verglichen werden müssen. Schere ich vor, ihr seid, ihr habt ein Adresspool, eine andere Firma habt ein Adresspool und ihr wollt gemeinsam Kunden anschreiben. Weil es wollt ihr natürlich nicht euren Adresspool in der anderen Firma geben. Das sind eure Adressen ja weg. Und die andere Firma wird dasselbe Problem haben. Das heißt, ihr wollt einen Abgleich machen und ihr wollt wissen, wie hoch denn die Schnittmenge ist, also das Union der beiden. So, Plantex-Daten, man hat festgestellt, Dove-Idee, bessere Idee, man hasht die Daten vorher. Also haschigen, wer ist noch nicht kennt. Die Texte gleich sind. Die Haschwerte gleich. Und der Kicker ist, wie die Haschwerte gleich sind, sind auch mit extrem hoher Wahrscheinlichkeit die Texte gleich. Nur dass die Haschwerte sehr klein sind. Und man aus dem Haschwert den Text nicht zurückrechnen kann. Nicht einfach. Wenn ich jetzt sowas für Adress-Daten vergleiche, dann haben wir J.Edgar Hoover. Dann wird man feststellen, dass man den Namen verschieden schreiben kann. J.Edgar Hoover, Edgar J. Hoover, John Edgar, was auch immer. Was auch normalisiert ist. Jedes Bit-Abweichung im Plaintext führt zu einem völlig anderen Hasch. Also normalisiert man die Daten. Und dann kann man vielleicht noch ein Schritt weitergehen, weil vielleicht schreibt der andere Edgar anders als der andere, dann nimmt man sowas wie Soundakes oder Kölner Notation oder was auch immer, um die Daten noch ein bisschen weicher zu machen. Und dann kann ich die Daten vergleichen. Apropos Hashing, wenn man es richtig macht, wie ein Großantosteo, die haben es wirklich gut gemacht, sind gehäschte Daten keine personenbezogenen Daten mehr. Und vor allem dementsprechend noch nicht mehr unter das Telekommunikationsgesetz mit den Ausleitungsbestimmungen. Also abgesehen davon, dass man das als Bürger vielleicht ganz gut finden kann, kann man das sozusagen daneben noch viel besser finden, weil diese ganze Ausleitung personenbezogener Daten im TKG, es ist ein echt immenser Kostenfaktor, weil er glaubt ja nicht, dass er BNSA die Kosten trägt. Und die erste Antwort ist immer hey, klar, Datenbankverschlüsselung oder Festplattenverschlüsselung. Also transparente Verschlüsselung. Das Hauptproblem mit transparenter Verschlüsselung ist, die ist für jeden transparent. Also auch für den Angreifer. Also es sei denn der cloudy Festplatten. Aber wenn das euer Problem ist, dann müsst ihr woanders anfangen. Was sind Alternativen? Das ist ja aber so ein System aufgemalt. Das System ist irgendwie aus, das Erteilsystem wird entschlüsselt, die Anwendung macht eine Einzelsatzverschlüsselung und mit einem Master Key der wird entsperrt und dann wird ein Datensatz entsperrt. Rechner aus, das Erteilsystem ist sicher. Rechner an, der Teilsystem ist nicht mehr sicher, weil er entschlüsselt. Aus Sicht des Angreifers. Bei der Datenbank das Erbe spielen. Wenn ich jetzt einen Datensatz habe, der mit einem Master Key verschlüsselt ist, dann ist der sicher, bis das der Master Key unverfügbar ist. Und selbst dann muss ich den Master Key erstmal noch mal nehmen und den Datensatz zu entschlüsseln. Also irgendwie mit einem normalen SQL Injection oder sowas, komme ich immer noch nicht weiter. Irgendwann wird der Datensatz entschlüsselt und dann ist noch plaintext im Arbeitsspeicher und dann kann ich ihn irgendwie abgreifen. Wenn ich einen Record habe, der gar nicht erst entschlüsselt wird, dann ist der trotzdem noch verhältnismäßig sicher. Wenn ich das mal anguckt, je nachdem wann angegriffen wird, habe ich halt immer verschiedene Sachen sind, sicher oder nicht. Hier ist alles in der Datenbank erstmal unsicher. Das, was schon entschlüsselt ist, ist angreifbar und das, was noch entschlüsselbar ist, weil der Master Key befreundet ist, der ist halt potenziell angreifbar. Warum erzähle ich das? Also transparente Verschlüsselung ist doof. Ich habe gerade gesagt, Inderzverschlüsselung ist viel besser. Wie mache ich das Speicher im Regelfall mit die metrische Verschlüsselung? Ich habe einen Datensatz, das ist ein plaintext-Datensatz. Ich verschlüssel den mit einem Schlüssel und ich verschlüssel den Datensatz. Ich bin denselben Schlüssel und habe einen entschlüsselten Datensatz. Deswegen symmetrisch. Ich brauche aber nicht einen Schlüssel. Ich brauche auch noch so etwas wie Initialisierungsvektor, eine nonz, das hinkt nur vom Verfahren ein bisschen ab. Also take away ist einfach nur, nicht nur den Schlüssel nehmen, sondern der Algorithm, dass wir noch einen anderen Parameter haben und eine neue Lizifikation. Und die sollte man bitte lesen und verstehen. Denn nonz, zweimal verwenden, ist Disaster. Das ist eine komplette Kompromotion des Sicherheitsversprechens. Dann gibt es noch sowas wie im Kett wissenschaftlich jeder schon hier, im Blockzweifer, also AIS zum Beispiel, wird in bestimmten Modi betrieben. Klassisch ist so was wie CBC, aber wenn man ECB, also quasi den Standardmonus, nehmt jeden Block einzeln Verschlüssel, dann ist die Krypto ungefähr so gut. Die Farbe ist weg, aber man kann noch gut erkennen, was die Daten waren. Wenn ich Daten verschlüssel mit einem Master Key, dann muss der irgendwie geschützt sein, sonst ist es ja ein bisschen sinnlos. Und jetzt aber von oben nach unten runter. Ich sollte mindestens gucken, dass der Master Key nicht in derselben Storage ist, wie die Daten. Wenn ich die Daten dann sollte ich für den Master Key eine Remote-File-Inclusion benutzen müssen. Oder andersherum. Woanders. Das Zweite ist, der Master Key sollte verschlüsselt sein. Und wenn es irgendwo nur so ein Baked-in-Secret in eurer Anwendung ist, also mal nur Obfuscation, aber kostet nichts und kann im schlimmsten Fall doch noch was helfen, weil jetzt muss der Angreifer auch noch den Quelltext haben. Noch besser ist, für jeden Daten einen Schlüssel nehmen. Den könnt ihr ableiten vom Master Key. Ich zeige gleich, wie das geht. Und wenn ihr richtig gut seid, dann kommt zu diese grüne Linie, dann macht ihr alle Krypto-Operationen in einem Krypto-Host. Also ein eigenes System, das nichts anderes macht als Schlüsselverwaltung. Wenn ihr noch Asche habt oder für eine Bank gearbeitet, dann nehmt ihr den HSM. Also ein Hardware-Security-Modio, das sind quasi Tempor-Proof-Devices, also leider ist es so, dass gerade das Thema Krypto-Host, das kriegt ihr noch relativ einfach hin, HSM, da brauchen 100 Leute, die wissen, wie es geht. Ich habe mich jetzt an Ableitung erzählt und Schlüssel und Tasse nicht gesehen. Fangen wir mal an. Ich habe ein Passwort, wie komme ich zum Schlüssel. Also ich will 128-Bitschlüssel haben. Wie lang muss das Passwort sein? Ziemlich lang. Also bei so einem Standard-Character-Set sollte man mal über 20 Zeichen rechnen. Jetzt mal ganz kurz nachgedacht. Wessen Passwörter sind so lang? Ach, komm, ihr lückt doch alle. Ich persönlich kenne die Diskussion, dass 8 Zeichen Passwörter doch so unglaublich lang sind und die kann sich ja keiner merken. Die Aussage ist, sichere Passwörter sind extrem lang. Das ist ein gutes Passwort, das andere nicht. Ich weiß nicht, wie es euch geht. Ich kann mir das nicht merken. Als Benutzer würde ich ein Passwort-Safe nehmen. Klar, aber wenn ich jetzt irgendwo in der Software arbeite, dann werde ich das nicht merken. Wenn ich nicht so lange Passwörter nehmen kann, also wenn ich die Entropie aus dem Passwort, das Chaos, wenn ich das nicht so hochsetzen kann, dann muss ich halt gucken, dass es länger dauert, das Passwort abzuleiten aus. Also den Key abzuleiten aus dem Passwort. Da kann ich so was nehmen, wie S-Crips, B-Crips, PB-GD, PB-KD-F2 oder andere Argon, dann gibt es das viele. Das ist das, Argon, dann gibt es das viele. Für einfache Sachen könnt ihr einfach HKDF nehmen. Das ist eigentlich nur ein Hash mit ein bisschen drumherum. Jetzt haben wir rausgefunden, wir haben irgendwo ein Master Passwort in der Konfiguration. Wir können aus diesem Master Passwort jetzt sicher ein Schlüssel ableiten. Wir wollen aber für jeden Datensatz ein Schlüssel haben. Also was mache ich? Ich nehme den Master Schlüssel. Ich nehme die Record ID und die Version des Datensatzes. Das ist total wichtig. Ganz viele kryptografische Algorithmen finden das total doof, wenn man die selben Daten mit dem selben Schlüssel verschlüsselt. Je nachdem, was man hat. Auch bei AES. StreamCypher ist es ganz klar. StreamCypher zweimal mit dem selben Schlüssel verschiedene Daten verschlüsselt. Dann kannst du gleich den Plaintext übermitteln. Da musst du nämlich nur die beiden X-Orten Plaintext. Das ist doof. AES in bestimmten Modi, also XTR zum Beispiel, funktioniert als StreamCypher. Also lesen, was man tut. Und dann erst umsetzen. Und ganz wichtig deswegen die Version mit reinnehmen. Und wenn ich das mache, dann kann ich aus dieser Kombination auch den Initialisierungsvekt oder den Nonce ablesen. Weil ich für jeden Datensatz, für jede Version mit einem Schlüssel und eine andere Nonce kriege. Also Reuse ist statistisch ausgeschlossen. Wie siehst du was aus? Also eigentlich total simpel. Ich klebe den Master Key, die Record ID, die Record Version hintereinander. Machen HKDF oder was auch immer dahinten. Mit 256 Bit, die ich daraus ziehen möchte. Und dann teile ich die auf einmal in Key und einmal in Nonce EV und was auch immer. Das ist einfach. Man muss halt mal lesen. Man muss gerade schon gesagt Schlüssel bitte nicht wieder verwenden. Das kann echt böse nach hinten losgehen. Ich empfehle immer so was zu lesen hier unten, wie NIST. Die kann man gut finden oder nicht. Aber wenn es darum geht Government Secrets zu schützen haben die im Regelfall ein recht hohes Eigeninteresse. Zufallsender Generatoren würde ich bei den jetzt aber nicht einkaufen. Ich habe gesagt Keys. Sollte man Keys nicht beliebig oft nehmen. Also der Schutz eines Schlüssels sinkt tendenziell mit der Anzahl der Daten, die man damit verschlüsselt. Das heißt, ich möchte hierhin wieder ein Schlüssel wechseln. Eigentlich möchte ich vor allem den Master Key hin und wieder mal wechseln. So ein Key Roll Over. Wenn ich das mache muss ich quasi vorletzte Spalte für jeden Datensatz den ich verschlüsseln natürlich irgendwie hinterlegen, was der Master Key war. Das ist eine Referenz auf den Master Key. Also Foreign Key. Das klingt jetzt irgendwie total banal bis zu dem Zeitpunkt, wo man es nicht hat und versucht in die Daten wieder anzukommen. Das selbe gilt für Algorithmen. Fangen wir mal an. DES, das war früher mal der heiße Scheiß. Dann stellte man fest die Schlüssellänge sind ein bisschen optimierungswürdig. Ich nehme alle Blowfish und dann stellte man fest 64 Bit Blocklänge, das ist auch nicht so optimal. Nehmt AES. Bei den Hässchen ist genau derselbe Kram. Bei asymmetrischen Sachen genau dasselbe. Also Kernhofsage ist einfach Algorithmenfang anzugammeln. Das heißt auch die Algorithmen, die man verwendet, um Daten abzuspeichern und die Schlüssel abzuleiten sollte man einfach mitspeichern. Das hat schicke Nebeneffekt. Jetzt zeige ich gleich mal. Nimm ich hier den. Passwort überprüfen. Ich will da gar nicht in Detail drauf eingehen. Wie und wo und was. Mir geht es um sie den Klassiker. Und der Klassiker ist ich habe in der Datenbank Benutzernamen und den MD5 des Passwords. Noch keiner gesehen, ne? Das ist völlig neu. Ich gebe das Passwort und den Namen Benutzernamen Passwort ein. Passwort ist gehasht. Und dann guckt man in der Datenbank nach. Find ich Benutzername mit dem Hasch? 3 ist super. Ich kann mich anmelden. Also 2 Probleme, MD5 ist broken. Das ist schlimmer. Das 2. Problem ist, wenn ich mich gegen einen Offline-Eingriff, also jemand hat in der Datenbank schon in der Hand, schütze, dann ist ein einfacher Hasch absolut einfach zu brechen. Selbst Consumer-Grade-Grafikarten kriegen irgendwie Giga-Hashes in der Sekunde hin. Das kombiniert mit diversen Corpus und Copy, jeweils auch immer, an bekannten Passwörtern. Man kann so ziemlich jedes Passwort brechen. Auch da gibt es wieder nur 2 Möglichkeiten. Entropie erhöhen. Das geht trivial mit dem Salt, also ein Wert, den ich quasi neben der Passwortspeichere und den Hasch mit einbeziehe. Da kann ich zumindest Dictionary Attacks verhindern, aber trotzdem kann ich mit der Grafikarte noch sehr viel ausprobieren. Oder ich nehme Pepper, also quasi ein Salt, das geheim ist, weil es sich zum Beispiel aus dem Master Key ableitet. Dann sind auch Dictionary Angriffe und Angriffe mit der Grafikarte deutlich erhöht. Oder erschwert, weil ich die Entropie, die in diesem Hasch darin ist, deutlich erhöhe. Wenn das nicht geht, dann gucke ich, dass ich irgendwie langsame Verfahren nehme, wie PBKD, F2. Oder noch besser. Genau. Jetzt habe ich ein Thema, ich habe irgendwie eine Datenbank, das sind die gammeligen MD5 drin und ich habe den Job bekommen, macht, dass es weggeht. Die naive Annahme ist die folgende. Den Nutzer meldet sich an, nein. Super, dann migriert das Passwort, dann habt ihr das Passwort am plaintext, dann haste ihr das mit den neuen Verfahren, macht ein Pepper rein, alles super, speichert das Passwort weiter im Text. Das ist super, also Scott hat jetzt irgendwie ein sicheres Passwort, also im Sinne von gut gespeichert. Alle anderen nicht. Das ist doof. Denn die sind das Problem. Scott nicht. Die sind das Problem. Alle anderen. Ich habe einen Job, der guckt sich jedes Passwort an, ist das migriert? Nein. Da nehme ich den Hashtag drin, steht, und nehme den als Eingabeparameter für den neuen Algorithmus. Speichert das? Fertig. Sieht das aus? Das sieht dann so aus. Der Scott hat immer noch PBKDF2 von dem Passwort und die anderen haben PBKDF2 vom MD5 von dem Passwort. Funktioniert. Deutlich besser als die Daten mit MD5. Und lässt sich vor allem irgendwie über Nacht laufen. Das ist mein Lieblings. Der lenkt nämlich keiner dran. Integritätsschutz. Wir haben Eif. Eif verdient mehr als Eif. Eif findet das doof. Und Eif hat Datenbankzugriff. Ihr seht wo es hin. Super. Instant Promotion. Das wird wahrscheinlich auffallen. Irgendwann wird sich fragen, ob es plötzlich da Gehalt abgeht, was irgendwo verbucht ist. Nichtsdestotrotz der erste, die erste Idee ist, ok, dann schütze ich halt das Salary in der Checksumme. Der kriptografischen, in dem Secretin so, dass Eif die nicht nachberechnen kann. Jetzt kann man feststellen, dass Eif diese 10.000 nicht verdient hat, weil die Checksumme nicht stimmt. Also fast gut, weil jetzt kann Eif einfach das Gehalt von Alice runterkopieren und die Checksumme runterkopieren und weniger, aber immer noch mehr. Das ist aber nicht so schlimm. Weil ich kann die Checksumme jetzt auch so machen, dass ich den Benutzernamen mit einbeziehen. Weil die RecordID oder was auch immer. Und dann ist das teilweise rüberkopieren von Daten nicht mehr möglich. Weil ich dann eine Manipulation definitiv erkennen kann. Das funktioniert natürlich nur dann, dass die Eif die Checksumme nicht berechnen kann. Also muss da irgendein Secretin sein. Es geht auch andersrum. Wenn ich den Passwort her schochkopiere, dann kenne ich das Passwort. Das ist auch doof. Das ist ganz besonders doof. Weil jetzt kann nämlich Eif etwas tun und Alice steht in den Locks drin. Und die Wahrscheinlichkeit, dass Alice nachweisen kann, dass sie das nicht war, tendiert gegen Null. Weil das eine Benutzernamen zu binden. Zack, zack. Okay. Ganz viele IT-Systeme haben eigentlich so einen einen großen Eingangskanal für Batchverarbeitung. Da kommen irgendwie große Datenpakete an. Die werden von verschiedenen einen Lieferern eingeliefert und dann irgendwie weitergeschoben. Meistens das so eine Art Store & Forward Server. Diese rote in der Mitte. Das ist eure Verantwortung, das Ding. Das ist nämlich das, dass da Plantax-Daten von Kunden drauf liegen. Das Ding hängt im Internet. Da hängen alle Kunden drauf. Also jede Schwachde, die das Ding hat, setzt nicht nur euch, sondern auch eure Kunden einer großen Gefahr aus. Das wollt ihr nicht. Symmetrische Krypto ist eine schlechte Idee. Zum einen, die Kunden kriegen sich implementiert. Und zum anderen ist das ein Albtraum, was das Schlüsselmanagement betrifft. Weil für jeden Kunden ihr habt ein Public Key mit dem verschlüsselt der Kunde, liefert das ein und ihr künst bei euch wieder entschlüsseln. Auf dem roten Ding ist nur verschlüsselt und im besten Fall noch signiertes Material. Wenn einer den Server mitnimmt, außen da, dass er ihn da raus trägt, dann kommt er nicht an die Daten dran. Das ist grundsätzlich eine gute Idee. Jetzt ist das Problem nicht technisch, sondern häufiger der Entwickler, der auf der rechten Seite ist und sagt, das kostet mindestens 30 Sprints. Zumindest mit Java. Das ist ein schämenes Pluck. Ich habe das Ding da geschrieben. Relativ einfach. Mit ordentlichen Libraries kann man auch Krypto einfacher machen. Was er an Lust hat. Das ist ja irgendwie PGP Stream, Entschlüsseln und die Signatur prüfen. Und ihn dann irgendwo in anderen Stream reinpipen. Kryptografisches Material. Ihr lacht. Andere finden es nicht komisch. Kryptografisches Material braucht immer Zufall. Immer, immer, immer. Das ist jetzt, egal wie zufällig der ausgewöhnelt wurde, das ist keine Entropie. Ich will ja gar nicht auf eingehen. Wichtig ist nur, benutzt Sie Mechanismen, die euch das Betriebssystem oder die Libraries hergehen. In Java ist es secure-random. Nicht random. Random heißt, so ist es aber nicht. Secure-random, das ist random. Wenn ihr wirklich viele Daten braucht, dann guckt man in die modernen Prozessoren rein. Die haben Hardware, Krypto, Zufallsgeneratoren. Wie haben wir das? Oh Gott, viel zu schnell, Leute. War gar nicht so schlimm? Ja, ja, genau. Sorry. Wir haben noch Ende des Zeit. Denn nur ein spannendes Thema. Zugriffskontrolle. Man kann Passwörter haschen. Das ist alles gut und schön für 0815. Manchmal, und das wird sehr selten vorkommen. Aber manchmal wird die Situation kommen, dass ihr nachweisbaren Zugriff braucht. Mit einem extrem hoher Wahrscheinlichkeit, dass ihr nachweisen könnt, dass der Zugriff eben nicht passiert ist, weil Alice irgendwie den Passwörter drüber kopiert hat. Oder was auch immer. Wo ihr Daten vielleicht auch am Benutzerkonton binden wollt. Also wenn ich zum Beispiel ein E-Mail, also Posteo macht das, das ist keine Werbung, aber da kann man ein Public Key hochladen und die verschlüsseln alle eingehende E-Mails. Wenn ich jetzt ein geschlossene System habe, dann ist das mit dem Public Key so ein bisschen schwierig, weil wo kommt der Private Key her, aber jetzt kann ich jetzt sagen, das ist eure Anwendung. Ihr habt drei User, Alice, Bob und Eve, ihr habt eine API, ihr habt eine Access-Control-List oder irgendwelche Daten. Also ihr habt nur ein Datum. Einfach Anwendung. Alice will auf die AP zugreifen, auf die Statue, die AP prüft die ACL und Alice kriegt die Daten. Super, das soll sein. Bob will auf die Daten zugreifen, die AP prüft die ACL, Bob kriegt keine Daten. Läuft. Das ist der Standard. Das auch. Eve exploitet die Anwendung. Hab die K2 und sagt, nix, die Daten sind weg. Das ist ungünstig. Also nicht wie Eve, aber Verleihannahmen. Okay, jetzt gucken wir mal, wie wir diese Daten mal so ganz theoretisch schützen könnten. Also wie könnten wir verhindern, dass Eve an diese Daten drankommt, selbst wenn sie direkt auf die Platte zugreifen kann? Und wie kann ich vielleicht auch kriptografisch eine ACL umsetzen? Okay, fangen wir an. Die Daten sind verschlüsselt mit irgendeinem Schlüssel. Der Schlüssel wiederum ist mit einem anderen Schlüssel verschlüsselt. Ihr seht schon, es gibt kein Problem, dass man nicht durch die Direktion lösen kann. Der Schlüssel da vorne ist jetzt mit Alice Schlüssel verschlüsselt und die ACL prüft sozusagen den Zug auf diesen Schlüssel. Und Alice hat ihr Schlüssel irgendwo bei sich. Wie genau, das machen wir gleich. So, wenn jetzt Alice darauf zugreift, wird hier ACL geprüft, schadet ihr eh nicht, dann kriegt ihr Alice die Daten. Alice kann den Data Key entkripten, weil sie hat ja den grünen Schlüssel. Super. Und damit kann sie die Daten wieder umsetzen. Wenn Eve jetzt das hier macht, dann kann Eve wieder die Daten schüsseln, weil sie den weißen Schlüssel nicht hat, noch kann sie Alice Schlüsseln schüsseln, weil sie den grünen Schlüssel nicht hat. Problem solved. Sollten wir überall so machen. Einzige Haken ist, das macht den Zug auf relativ aufwendig, das will ich nicht machen, wenn ich in einem Wettstop tausend von Daten setzen, und vor allem möchte ich das nicht machen, wenn Alice hier Passwort vergisst. Da kommen wir gleich drauf. Aber wie kommt Alice eigentlich an diesen komischen grünen Schlüssel? Am sinnvollsten Alice gibt es Passwort ein, der grüne Schlüssel ist nochmal verschlüsselt mit dem Passwort und abgelegt nochmal auf den Server. Und dann kriegt Alice den entschlüsselten grünen Schlüsseln. Das hat Alice den grünen Schlüsseln, ihr könnt alle folgen, hervorragend nicht. Jetzt zur folgende Situation. Wenn Alice ihr Passwort ändert, dann verschlüsselt sie ihren grünen Schlüssel mit dem neuen Passwort. Haken dran. Der Schlüssel hat mir gesehen, schützt die Daten, also die beiden Sachen sind super. Was nicht funktioniert ist das hier. Also wenn Alice ihr Passwort vergisst, dann hat Alice ein Problem. Die klassische Lösung für das ist. Es gibt irgendwo einen vertrauenswürdigem dritten Kieskrow und dem gebe ich eine Kopie von den grünen Schlüssel oder dem gebe ich eine Kopie von den weißen Schlüssel oder was auch immer. Kann man so machen? Ist durchlassen wie dieses valide Szenario? Hat aber diverse Nachteile. Hat insbesondere den Nachteil, dass die Prozesskosten extrem hoch sind. Also gar nicht technisch. Wenn ich mir so ein Kundendienst angucke, die Frage, die mit Abstand am häufigsten kriegen ist. Ich habe mein Passwort vergessen. Und dass obwohl es Prozesse gibt, um das Passwort manuell zurückzusetzen über irgendwie einfach mein Passwort link. Das ist ein ganz reales Problem. Das ist ein ganz reale Kostenvorsacht und nicht im geringen Umfang. Wenn ich so was habe, dann muss ich sicherstellen, dass der Kundendienst, also der darf gar nicht erst dann die Sachen dran kommen, weil sonst ist der irgendwie in Täter Nummer 1. Und das Zweite ist, ich muss mit einem extrem hohen Aufwand den Anrufer identifizieren. Weil wenn ich da anrufe und sage, hallo, ich hätte gerne den Firmen-Safe und die sagen, ja, bitte schön, hier ist der Schlüssel, das funktioniert nicht. Wenn ich das mit meinem privaten Konto mache, dann mag das irgendwie noch gehen, aber wenn das wirklich sensitive Daten sind und sonst würde ich den Scheiß da nicht machen, dann ist das kein Weg. Also, was ist eine Möglichkeit? Die Zauber der Kryptografie. Secret sharing. Also, Alice, die Farbe ist jetzt falsch, aber Alice hat ein Schlüssel. Das ist Ira, die ist geheim, den darf kein anderer wissen. Alice hat vier Freunde. Im optimalen Fall können sich alle Gegend nicht gegenseitig ausstehen, damit die nicht zusammenarbeiten. Und aber Alice sagt, also zwei würden sich vielleicht noch zusammen tun, um mir einen reinzuwirken, aber drei würden niemals sich zusammenfinden, um mir irgendwie einen reinzuwirken. Ich weiß aber nicht, ob ich immer drei Zugriff habe, ich habe aber garantiert, wenn ich vier Leute habe, kriege ich immer drei zusammen. Ob die Zahl 3 und 4 ist jetzt völlig aus dem Ärmel geschüttelt, das kann auch 17 und 32 sein, das ist egal. Was Alice jetzt macht, sie teilt ihren Schlüssel auf mit einem Kryptografischen Verfahren. Hier zum Beispiel, so der Klassiker, gibt es aber auch noch andere. Jeder von den drei kriegt ein Teil des Schlüsseles. Und weil das Verfahren so konfiguriert ist, dass drei von vier Schlüssel wiederherstellen können, wenn Alice ihr Passwort vergießt, wenn ein Schlüssel nicht mehr dran kommt, können drei der Leute zusammen den Schlüssel wiederherstellen. Irgendwelche drei. Das ist ein Tier Out of N Secret Sharing. Als ich eben HSM erwähnt hatte, haben einige Wissen genickt. So ein HSM, das schützt man mit einem Operator-Card-Set, also einem Kryptografischen Karten. Und da sind im Regifall auch so, dass man sagt, ich habe irgendwie fünf Karten und ich brauche mindestens drei, um das Ding irgendwie ganz laufen zu kriegen. Das könnte man theoretisch auch, weil das relativ aufwandsam ist, im Vergleich zu allen anderen Methoden. Weil das die Last der Identitätsprüfung zum Beispiel, Alice aufwürdet. Und nicht irgendein Hub-Dienst oder Support-Service, der Alice noch nicht mehr kennt. Wahrscheinlich 100.000er von Kunden hat. Das wird selten eingesetzt. Ihr habt keine Ahnung, warum. Ich finde das ziemlich elegantes Schema. Gerade dann, wenn es darum geht, dass man, das ist vielleicht noch ein bisschen eine Hintergedanke, dass man als Firma nachweisbar auch gar nicht so schnell haben möchte. Wenn ich diese Schlüssel nicht habe als Firma, denn die Daten sind verschlüsselt, dann kann ich diese Daten als Datenmüll behandeln. Also nicht im Sinne von, ich kann die löschen, aber im Sinne von das Schutzniveau dieser verschlüsselten Daten ist unglaublich geringer, als das Schutzniveau von Plaintext-Daten. Hohe Schutzniveau heißt hohe Kosten. Beispiel, ich habe eine Datenbank, ich habe 30 Leute, die auf Rumtouren da kann schnell mal was schiefgehen. Da habe ich irgendwie einen, der nicht weiß, was er tut, oder schnell mal ein Problem lösen muss. Das hat Kunden angerufen, ich muss hier die Daten ran, sonst kriege ich das ein Problem nicht gelöst. Ups, die Plaintext-Daten weg. Das kann man verhindern, wenn der gar nicht erst da dran kommt. Also nichts gegen DevOps-Lauten, eine super Sache, aber wenn meine Hauptaufgabe Deaf ist und nicht die Gileg-Experte, dann tue ich manchmal Sachen, die ich gleich nicht tun sollte. Das ist überhaupt nicht böse gemeint. Okay. Ich habe ganz viele Sachen erzählt, aber irgendwo bin ich so wirklich tief eingestiegen. Warum? Herr Vorhand, oh Gott, viel früher fertig. Vielleicht ist da noch Gulasch da. Gehe so eine Crypto-Checklist. Da sollte man in jedem Fall durchgehen. Guckt euch die Daten an. Wir müssen nie behandelt werden im Sinne von was sagt das Gesetz, was sagen die Vorschriften, was sagt der Chef, was ist das Risiko mit den Daten. Und klärt das mit einem Manager. Und wie ihr sich mit einem Manager klären könnt, dann findet einen, der es klären kann. Alles, was ihr tut, alles, was da drunter steht, kostet Geld. Wenn ihr für jeden Fennig diskutieren müsst, dann könnt ihr es doch sein lassen. Ihr müsst irgendwann erklären, das ist in deinem eigenen Interesse, dass ich dir helfe, dass die Daten sicher sind. Alles andere kannst du knicken. Wird nicht funktionieren. Ihr müsst wissen, wann ihr aufhört, zu diskutieren. Also was sind eure Trustenker? Vertraue ich meinem Cloud-Diensteanbieter? Ja oder nein. Oder wie weit vertraue ich ihm? Das klärt man einmal und dann ist gut. Wenn ich das ändere, habe ich wahrscheinlich große Folgeraufwände. Man kann es übertreiben. Man kann jetzt hingehen wie Apple und sagen, ich baue meine eigenen Prozessoren. Kann man alles machen. Ist im Regelfall aber nicht das, was unser Unternehmen weiterbringt. Wenn ich sensitive Operation habe, Verschlüsseln, Signieren, dann muss der Zufuhr auf diese sensitiven Operationen, ob es das HSM ist, ob es jetzt ein Kryptohost ist oder ob ich jetzt Daten signieren kann und die App hier jetzt mal ganz platt und die unauthentifiziertes Netzstelle, dann kann ich auch gleich die Schlüsse liegen. Das bringt überhaupt nichts. Also die Stinstellen, kriptografische Stinstellen müssen geschwützt werden. Nicht selber ausdenken. rfc4880 ist OpenPGP. Lest euch irgendwie Empfehlung vom BSI durch, vom NIST. Also man kann viel von den Leuten erhalten. Oder auch wenig ist. Aber wir haben ein extrem ureigenes Interesse daran, dass das, was sie herausgeben, auch sicher ist. Und sie können es im Regelfall deutlich besser beurteilen als ihr. Ja, es gibt Ausnahmen. Nonstens nur einmal verwenden. Wissen, wann ein Modus ein Streamserver ist und was dann passiert, wenn man den zweimal verwendet. Etc. Ganz, ganz wichtig, alles aufschreiben. Ihr braucht ein Kryptokonzept. Also eine aufgeschriebene Version, was er tut, warum er es tut und wie er es tut. Und dann muss da irgendwann drüber gehen und sagen, ja, das stimmt so. Und dann muss einer drüber gehen, der weiß, wie es geht. Also der kriptografische Expertise hat. Wenn das Konzept schon grütze ist, dann könnt ihr mal raten, wie gut die Implementierung wird. Auch jetzt einen Master Key habt, der soll dir gesichert werden. Auch Offsite gesichert werden. Am besten im Save. Am besten in 2 Saves. Am besten auf einer Karte und ausgedruckt. In 2 verschiedene Ländern. Wenn der weg ist, ist weg. Also alles ist weg. Und ich sage alles, mal nicht alles. Das ist der Fall. Flugzeug fällt auf Datacenter. Auf jedes gleichzeitig. Der Master Key ist halt wichtig. Wo ich dabei bin, dass ich mich immer wieder versichern kann. Also regelmäßig austauschen. Und hier auch der Pro-Tipp. Wenn es weh tut, und es tut weh, macht es häufiger. Also nicht sagen, das können wir in 2 Jahren und es implementieren. Not gonna happen. Algorithmen roll over. Nicht nur implementieren, sondern auch testen. Also zumindest mal. Der 1. ist immer einfach. Der 2. ist schwierig. Ihr braucht ordentlich Entropie. Egal, was ihr tut, macht Testfälle. Zum Beispiel, ich spiele das Backup von letztem Monat rein. Funktioniert das noch? Oder sind plötzlich irgendwelche Keys weg? Also das muss man wirklich ausprobieren. Sonst kann es echt böse nach hinten losgehen. Ich habe 4 Minuten. Und wir sind fast durch. Also regulatorische Anforderungen hat man gerade, wo ist ein Mittel, aber es muss nicht immer das primäre Mittel sein. Im Regelfall sind organisatorische Mittel deutlich wirkungsvoller. Weil sie einfach weniger kosten in der Umsetzung nachher. Aber wenn es notwendig ist, Krypto zu machen und wenn es sinnvoll ist, da muss man es ordentlich machen. Hat man schon Q&A? Habt ihr Fragen? Anmerkungen? Ervorragend. Wenn ich ein Key Rollover mache, also einen neuen Master Key oder auch einen neuen Symmetischen Schüssel nehme, dann sagst du, brauche ich ja irgendein, der das Ganze verwaltet, also der auch 2 Master Keys zum Beispiel verwaltet und den auch wieder ausfischen kann. Ich hätte gerne so ein 1, 2 oder 42 des Master Keys. War das die, die ... Ja, das ist schon neun Key. Wie merkt ihr jetzt mal, dass man die Key Rollover macht? Ja, das ist schon neun Key. Genau. Wie merkt ihr jetzt mein Server? Für diesen Datenmengen habe ich Key Appings und für Mengewäld habe ich Key 2 gegrüßt und drüber reden. Also vom Verwalten her ist es nicht so einfach. Genau. Also die Frage ist, wenn ich sage, ich will Algorithmen wechseln dann habe ich ja plötzlich nicht nur einen Schlüssel, sondern ganz viele, potenzielle Schlüssel. Wie finde ich den jetzt raus, wenn ich auf den Daten dazu greife, was der richtige Schlüssel ist? Und da ist halt genau der Punkt, ich schreibe daneben, was der Schlüssel ist. Also ich schreibe nicht ein Schlüssel daneben, sondern ich schreibe eine Key-ID, also ein Firing Key in der Datenbank wäre es daneben. Genauso mit den Algorithmen. Ja? Das ist der Fall, dass ihr erwähnt, dass das Hashen-Daten bedauerlich machen kann. Jetzt sollte man halt sehr, sehr vorsichtig sein. Gerade bei den Beispielen Intellenzion-Nomand ein Hasch kann am Ende nicht die Entropie vergrößern. Wenn wir jetzt Telefon-Nomand haben, die irgendwie 10 Ziffern haben, dann sind wir bei 10 Milliarden Möglichkeiten. Wir hatten das Stichwort, um ihr Hashes pro Sekunde. Das heißt, nach 10 Sekunden hat man die Grafik haben, und die Entropie erhören. Deswegen wäre ich sehr, sehr vorsichtig in der Empfehlung der Hasche. Guter Punkt. Das geht so ein bisschen auf das Teil zurück, was ich gerade sagte. Man kann entweder langsamer machen oder die Entropie erhöhen. Entropie erhöhen ist im Regelfall der bessere Weg. Eine Möglichkeit wäre, mit Telefon-Nomand ist ein gutes Beispiel, in Zollt, also irgendetwas, was ich davor schreibe, was öffentlich bekannt ist, die Entropie erhöhen. Weil die Entropie immer noch genau das ist, was die Telefon-Nomand hergibt, und wenn ich den Zollt kenne, dann kann ich in 10 Sekunden das Ding durchrechnen. Wenn ich bei der Berechnung des Hashes etwas davor schreibe, was der Angreifer nicht kennen kann, weil es zum Beispiel abgeleitet ist aus einem Secret, dann habe ich die Entropie damit erhöht, und damit habe ich auch das ganze Thema Bootforce sicherer gemacht. Das ist genau ein richtiger Punkt. Was ich das richtig verstanden habe macht, ist zum Beispiel, dass der Kleint ein Zollt wird generiert und den übermittelt. Ich habe es in den Teilen nicht angeguckt, ich habe es in der Tat auch nur zufällig gesehen auf der Seite von denen, dass das quasi von BFD abgesignet wurde und auch von der B-Netz A. Ich habe es nicht gelesen, aber das richtige Antwort. Krypto kann ich zaubern. Wenn ich irgendwie die Zahl wenig habe, wenig Möglichkeiten, dann wirft Krypto auch nur wenig. Noch mehr? Beispiel, mit dem Access Control Entries über Kryptografie, findest du eigentlich ein Beispiel dafür, so ein System, wie du es umsetzen? Also ich kenne keine, sagen wir mal so. Ich sage ja, also es ist eigentlich relativ, also von der Idee her, man wird es nicht überall einsetzen, aber ich kenne keine Systeme, die es wirklich umsetzen. Die Schlüssel müssten, ne, also letzten Endes genau das Thema, wenn ich irgendwie Änderungen habe, die da unten ACL-mäßig irgendwie abgefragt werden müssen, dann wird es schnell eklig. Also da muss man mit anderen Mechanismen vorgehen. Wenn das ein relativ stabiles System ist, dann ist das mit Sicherheit eine Möglichkeit. Noch was? Ansonsten händ ich noch den hier. Ich habe es gerade schon mal gesagt, was ist schlimmer, als im langweiligen Talk zu sitzen, in die nächste Gruppe, oder zu verdammen den selben langweiligen Talk zu sehen. Also, das betrifft nicht nur mich, das betrifft alle. Ich habe gerade gesehen, es gibt eine Feedbackmöglichkeit zu den Talks hier im Ding ins Tool. Man kann es auch da machen, man kann es auch persönlich machen. Wenn ihr Talks seht, gibt den Leuten Feedback. Im besten Falle konstruktives und nachvollziehbares Feedback. Also, du bist der beste, hört man gerne. Super, hilft mir aber nicht weiter. Das ist eine persönliche Entwicklung. Und das betrifft eigentlich jeden, der den Vortrag hält. Und von daher, wenn die Leute sich so viel Mühe machen, den Vortrag zu halten, und das ist viel Aufwand, dann honoree das auch. War das eine Frage oder ist es ein Timeout? Kryptografie ist nicht eingesetzt wie normale Standard-Leben aus Kunden-Sicherheit. In Kommunikation-E-Mails. Angst, Angst und andere Fragen und so weiter. Also, die Frage war, warum wird Kryptografie im normalen Leben so selten eingesetzt? Und die Antwort ist eigentlich, es gibt zwei Antworten da drauf. Die eine Antwort ist, es wird extrem viel eingesetzt. Also, HTTPS, also das grüne Schloss bei Webseiten, wenn man die besucht, das ist ganz viel Krypto. Die große Schwierigkeit mit Krypto ist nicht die Krypto selber, sondern die Organisation dahinter. Was meine ich damit? Es ist zu aufwendig, ist noch viel schlimmer. Wenn ich dir jetzt eine verschlüsselte E-Mail schicken möchte, dann müssen wir uns vorher irgendwie mal austauschen, weil ich muss ja deinen Schlüssel kennen. Das ist das Problem. Wir müssen erst mal gucken, was ist der Schlüssel, ich muss diesen Schlüssel prüfen, dann könnten wir eine sichere Kommunikation aufbauen. Wenn wir das nicht persönlich treffen, dann brauchen wir irgendein Dritten, der das macht. Also, bei Webseiten macht das eine CA. Mit IIDAS gibt es jetzt auch die Möglichkeit, das organisatorisch und rechtssicher zu machen durch Dritte. Aber das Hauptproblem ist in der Tat das Management, also Key-Management. Das ist ganz, ganz oft die zentrale Schwierigkeit. Eine wirkliche Lösung hat noch keiner gefunden. Es gibt nur wieder Ansätze, dass alle Leute sagen, ich habe eine super Idee. Ja, doch nicht. Aber es ist genau die richtige Frage. Das ist die zentrale Frage bei dem ganzen Kryptogramm. Frage beantwortet, teilweise, also können wir gleich weiter machen, aber es ist einfach, die Technik sind die Leute, muss man so sagen. Also auch nicht persönlich gemeint. Noch weitere Fragen? Damit danke ich mich. Trotz irgendwie Gulasch und Starbucks nebenan sind echt viele Leute da gewesen. Ich bin überrascht. Ich finde es aber nicht schlimm. Vielen Dank.