Kryptografie

Lucas Dohmen: Hallo und herzlich Willkommen zur ersten Folge vom INNOQ Security Podcast. Heute ist das Thema Kryptografie mit dem Christoph. Hallo Christoph!

Christoph Iserlohn: Hallo Lucas!

Lucas Dohmen: Falls ihr euch wundert: Was ist denn der INNOQ Security Podcast? Ich habe doch den INNOQ Podcast abonniert? Das hier ist ein kleiner Appetithappen aus unserem neuen Podcast. Wenn ihr mehr über diesen Podcast wissen wollt und ihn abonnieren wollt findet ihr mehr in den Shownotes. Aber nun sprechen wir über Kryptografie. Damit wir damit starten können, müssen wir erst einmal sagen, was ist denn eigentlich Kryptografie?

Christoph Iserlohn: Kryptografie, das ist die Entwicklung und Anwendung von Verschlüsselungsverfahren. Vielleicht sollten wir da einmal vier Begriffe unterscheiden: Das ist einmal die Kryptologie, das ist halt die Wissenschaft, die sich mit Ver- und Entschlüsselung von Informationen beschäftigt. Neuerdings fallen darunter auch so ein paar Sachen, die jetzt nicht direkt Verschlüsselung und Entschlüsselung sind, so wie digitale Signaturen oder Hashfunktionen. Und die Kryptografie selber ist dann – wie ich schon sagte – die Entwicklung dieser Verfahren. Dann gibt es noch die Kryptoanalyse. Das ist sozusagen der böse Part. Da analysiert man die Verfahren und versucht dann, Informationen daraus zu gewinnen. Beziehungsweise wenn man es mal im Klartext sagt, man versucht diese Verfahren zu brechen. Und der letzte Begriff, dem man noch häufiger begegnet, ist das Kryptosystem. Das ist etwas mehrdeutig definiert. Also im Allgemeinen wird damit ein System bezeichnet, das irgendwie mit Kryptografie zu tun hat. Das ist jetzt eine Definition, mit der man relativ wenig anfangen kann. Wenn wir man ein konkretes Beispiel nehmen: Es gibt das RSA-Kryptosystem und das beinhaltet dann zum Beispiel den Algorithmus, mit dem man verschlüsselt, den Algorithmus, mit dem man entschlüsselt und einen Algorithmus, mit dem man einen Schlüssel erzeugt. Das gehört alles zusammen, um dieses Verfahren anzuwenden. Diese geschlossene Einheit dieser drei Sachen nennt man dann Kryptosystem.

Lucas Dohmen: Okay, gut. Du hast schon gesagt, es geht um Verschlüsseln und Entschlüsseln. Kannst du noch einmal kurz sagen, was sind die Ziele der Kryptografie, weil ich glaube, dass das dann ja doch noch ein bisschen spezieller ist?

Christoph Iserlohn: Ja, es gibt eigentlich vier Ziele, die man so unterscheiden kann. Das ist einmal halt, dass nicht jeder darauf zugreifen kann, auf Informationen. Also das ist die eigentliche Verschlüsselung. Das fällt unter den Begriff der Vertraulichkeit: Nur jemand, der berechtigt ist, soll Informationen lesen können. Dann gibt es das zweite Ziel, das ist die Integrität, der Änderungsschutz. Das heißt, die Daten sollen vollständig und unverändert sein, beziehungsweise ich muss merken können, wenn Daten verändert wurden. Das dritte ist die Authentizität und der Fälschungsschutz und das fällt so ein bisschen rein mit dem vierten Punkt, der Verbindlichkeit oder Nicht-Abstreitbarkeit. Und das heißt, der Urheber der Daten oder auch der Absender, den muss man eindeutig identifizieren können, und auch die Urheberschaft sollte dafür nachprüfbar sein. Und er sollte das auch nicht abstreiten können, seine Urheberschaft. Das ist der vierte Punkt, die Nicht-Abstreitbarkeit. Und so etwas erreicht man dann z.B. über digitale Signaturverfahren. Also digitale Signaturen bilden sozusagen Integrität, Authentizität und die Verbindlichkeit ab. Damit kann ich halt feststellen, mit einer digitalen Signatur: Ein Dokument wurde nicht verändert und von wem das signiert wurde, kann ich auch feststellen, und dann kann ich halt die Zertifikatskette weiter hochgehen und dann gibt es irgendein Zertifikat, dem ich vertraue, und dann kann derjenige das auch nicht abstreiten. Aber das sind Details, die wir jetzt alle nicht im Kleinklein besprechen brauchen. Auf jeden Fall gibt es die vier Ziele Vertraulichkeit, Integrität, Authentizität und Verbindlichkeit.

Lucas Dohmen: Also wir müssen das nicht im Kleinklein besprechen, aber ich glaube, es ist schon wichtig, noch einmal hervorzuheben, dass man manchmal nur Teile der Ziele haben möchte. Also du hast jetzt gerade Signieren genannt als Beispiel, da muss man beispielweise nicht die Vertraulichkeit haben. Es kann jeder lesen, man möchte nur wissen, das es von einem bestimmten Urheber kommt. Richtig?

Christoph Iserlohn: Ganz genau. Also so ein Kryptosystem kann mehrere Ziele davon abbilden oder nur eins. Vorhin hatte ich RSA genannt, damit wird erst einmal nur die Vertraulichkeit gewährleistet. Mit RSA kann man auch Signaturen erstellen, dann kann man noch mehr machen, aber die beiden Systeme sind erst einmal voneinander unabhängig. Und dann muss man schauen, welches Kryptosystem man wann einsetzt, um welches Ziel zu erreichen und welches Ziel man auch braucht. Man braucht nicht immer alles. Also wenn ich zum Beispiel einen Cookie schützen will gegen Veränderungen, dann reicht ein Integritätsschutz, aber der User kann vielleicht ruhig darin lesen, den Inhalt. Wenn ich das nicht möchte, dann muss ich auch gleichzeitig noch die Vertraulichkeit noch sicherstellen, dann müsste ich den auch noch verschlüsseln.

Lucas Dohmen: Alles klar, okay. Wenn ich mich so ein bisschen an die Schulzeit erinnere, erinnere ich mich noch daran, dass es da irgendwie so Sachen gab wie Caesar-Verschlüsselung usw. Wie lange gibt es denn schon Kryptografie? Ist das ein altes Thema, ein neues Thema?

Christoph Iserlohn: Kryptografie ist schon sehr alt. Verschlüsselungsverfahren gibt es schon sehr, sehr lange, schon bestimmt zwei-, dreitausend Jahre. Und da gibt es ganz viele Verfahren. Und diese ganzen alten Verfahren nennt man halt die klassische Kryptografie. Mit der wollen wir uns heute nicht so auseinandersetzen, weil das nicht das ist, was wir jetzt in der Informationstechnik einsetzen heutzutage. Aber wer daran interessiert ist, da schreiben wir in die Shownotes ein sehr gutes Buch, dass sich sozusagen von der Antike bis zur Gegenwart mit Verschlüsselung beschäftigt und in dem man die ganzen Sachen dann nachlesen kann. Auch wenn man nicht viel Ahnung von Mathematik hat, geht das ganz leicht.

Lucas Dohmen: Okay.

Christoph Iserlohn: Wir werden uns mit der modernen Kryptografie beschäftigen. Das kann man so ungefähr abgrenzen ab Ende des zweiten Weltkriegs. Da gab es ein Paper von Claude Shannon und der hat eigentlich die moderne Kryptografie begründet, weil er zum ersten Mal die mathematischen Prinzipien und auch so etwas, wie dass Sicherheit beweisbar sein muss und dass man da mathematisch rangeht, das erste Mal ins Spiel gebracht hat.

Lucas Dohmen: Was zeichnet denn die moderne Kryptografie aus? Was macht sie zur Moderne im Gegensatz zur klassischen Kryptografie?

Christoph Iserlohn: Ein besonderer Punkt ist das Kerkhoffsche Prinzip. Das ist von Herrn Kerkhoff, Auguste Kerkhoff, schon 1883 formuliert worden. Das war ein niederländischer Linguist. Man könnte auch sagen Kryptologe, obwohl es den Begriff da wohl noch nicht so in der Form gab. Und der hat einen wichtigen Grundsatz formuliert und zwar, dass die Sicherheit eines Kryptosystems nicht von der Geheimhaltung des Algorithmus oder der Maschine abhängen darf, sondern einzig und allein auf deren Eingabeparametern, also heutzutage dem Verschlüsselungskey, beruhen soll. Dieses Prinzip wurde eigentlich erst, wie gesagt, nach dem Zweiten Weltkrieg wirklich angewandt. Wenn man zum Beispiel an die berühmte Enigmamaschine denkt, die Verschlüsselungmaschine, die die Deutschen im Zweiten Weltkrieg benutzt haben, da wollten ja auch die Allierte. Die waren ja da sehr hinterher, eine dieser Maschinen in die Hand zu bekommen um zu verstehen, wie die funktioniert. Um daraus Rückschlüsse auf die Verschlüsselung und damit wichtige Informationen zur Entschlüsselung zu erfahren. Und heutzutage, Moderne Algorithmen wie zum Beispiel AES oder RSA, die kann man überall nachlesen. Also braucht die braucht man nicht geheim halten, sondern da ist es einfach nur wichtig, dass, wenn man die anwendet, der Schlüssel geheim bleibt. Und das hat ein paar Vorteile, wenn man diesem Grundsatz folgt. Denn zum Einen ist es viel schwieriger, den Algorithmus geheim zu halten als den Schlüssel zum Beispiel. Einen Algorithmus müssen halt dann alle kennen, die dieses Verfahren anwenden. Den Schlüssel müssen nur die Parteien, die wirklich miteinander kommunizieren wollen, geheimhalten. Das sind also auch viel weniger. Und genauso ist es auch viel schwieriger, den Algorithmus auszutauschen. Wenn ich das jetzt in irgendwelchen Maschinen verdrahtet habe oder auch in Software, das alles auszutauschen, das alles zu erneuern, als einfach den Schlüssel zu rotieren, also einen neuen Schlüssel zu benutzen, falls der mal kompromittiert wurde. Und das Dritte ist, dass, wenn ich das natürlich öffentlich mache, so ein Verfahren viel mehr Aufmerksamkeit bekommt von Kryptologen, die dann auch eine vernünftige Kryptoanalyse erstellen können. Das heißt, das ist wahrscheinlich sicherer als irgendetwas, was ich irgendwie geheim halten. Wenn darauf viele Leute geschaut haben, so ein bisschen das Open Source-Prinzip, dann werden auch viel mehr Bugs gefunden. Und so moderne Verfahren wie AES wurden zum Beispiel auch genauso entwickelt. Da gab es einen Wettbewerb der amerikanischen Standardisierungbehörde NIST. Der lief von 1997 bis 2000 und das war öffentlich. Dann konnten viele Leute auch darauf schauen. Das ist halt die moderne Kryptografie.

Lucas Dohmen: Das heißt, wenn jetzt die Enigmamaschine nach den modernen Prinzipien erfunden wäre, dann wäre es gar kein Drama gewesen, wenn die irgendjemand geklaut hätte, weil die nichts genutzt hätte, im Prinzip. Richtig?

Christoph Iserlohn: Ganz genau. Wobei bei der Enigma so ein bisschen Grauzone is. Nur die Enigma hieß jetzt auch nicht sofort, dass man dann sozusagen alles damit entschlüsseln konnte. Das ist halt nicht komplett schwarz und weiß. Aber es ist so, würde man das konsequent anwenden und hätte man moderne Kryptografie wie heute, dann könnte man die sozusagen einfach irgendwo kaufen, die Enigma, und es würde einem nichts nützen.

Lucas Dohmen: Okay, verstanden. Und bei der modernen Kryptografie gab es dann ja auch wahrscheinlich so ein paar Evolutionsstufe. Was gab es denn da für Umbrüche in der Geschichte?

Christoph Iserlohn: Der wichtigste Umbruch war wahrscheinlich die Erfindung von asymmetrischen Kryptografieverfahren. Das ist in den 1970er Jahren passiert. Bei der asymmetrischen Kryptografie hat man ein großes Problem der symmetrischen Kryptografie gelöst und zwar das Problem des Schlüsselaustauschs. Also symmetrische Kryptografie heißt, zum Entschlüsseln und zum Verschlüsseln benutze ich denselben geheimen Schlüssel. Und den geheimen Schlüssel, den muss ich ja irgendwie an die Leute bringen, die das mal entschlüsseln sollen. Das heißt, da habe ich so ein Henne-Ei-Problem, weil dann müsste ich den ja vielleicht wieder verschlüsseln dahinschicken und wieder entschlüsseln und so. Das funktioniert halt nicht. Das wäre irgendwie so eine endlose Rekursion. Also muss ich das über irgendeinen anderen Kanal den Menschen zugänglich machen. Zum Beispiel, indem ich vorher den Schlüssel irgendwo auf einem Blatt Papier schreibe und ihnen mitgebe. Aber wenn ich mich mit denen jetzt nicht persönlich treffen kann, wenn die am anderen Ende der Welt sind, ist es halt schwierig, denen so ein Schlüssel irgendwie sicher zu übertragen, ohne dass den irgendeiner mitlesen könnte oder mithören könnte. Und im Gegensatz dazu sind die asymmetrischen Verschlüsselungsverfahren, die zwei Schlüssel besitzen, einen öffentlichen und einen geheimen Schlüssel. Und der öffentliche Schlüssel – das hört man vielleicht ja schon am Namen – ist öffentlich für alle zugänglich. Und wenn ich mit dem öffentlichen Schlüssel etwas verschlüssele, dann kann ich das nur mit dem geheimen Schlüssel wieder entschlüsseln. Das heißt, wenn ich jetzt zum Beispiel gerne möchte, dass mir jemand verschlüsselte Nachrichten schreibt, dann kann ich einfach diesen Schlüssel veröffentlichen und alle können damit die Nachrichten verschlüsseln. Und ich bin der Einzige, der die entschlüsseln kann, weil ich den geheimen Schlüssel besitze.

Lucas Dohmen: Verstanden. Also das löst das Problem, dass wir beide sonst irgendwie erst einmal einen sicheren Kanal finden müssten, damit wir ein Passwort miteinander ausmachen können.

Christoph Iserlohn: Ganz genau.

Lucas Dohmen: Und bedeutet das, dass asymmetrische Kryptografie einfach besser ist als symmetrische Kryptografie oder hat auch symmetrische Kryptografie irgendwelche Vorteile?

Christoph Iserlohn: Also symmetrische Kryptografie hat ganz viele Vorteile. Zum Beispiel ist das deutlich schneller als asymmetrische Kryptografie. Und es kann auch weniger Speicher verbrauchen. Wenn man sich zum Beispiel vorstellt, dass ich eine E-Mail schreibe an fünf Empfänger und da ist ein PDF dran, das ist 20 Megabyte groß. Dann müsste ich, wenn ich das symmetrisch verschlüssele, für jeden Empfänger mit einem geheimen Schlüssel (Anmerkung: den öffentlichen Schlüsselen der jeweiligen Empfänger) jeweils neu verschlüsseln, also hätte ich dann fünf mal 20 Megabyte daran. Wenn ich jetzt einen asymmetrischen Schlüssel habe, dann kann ich den zum Beispiel nutzen, um den Schlüssel, mit dem ich das verschlüssele, das eigentliche Dokument verschlüssele, nochmal zu verschlüsseln. Dann brauche ich nur einen kleinen Schlüssel von 32, 64 Byte und den muss ich fünfmal verschlüsseln mit dem asymmetrischen Verfahren. Dann spare ich jede Menge Speicherplatz. So ein Verfahren ist dann eine hybride, weil die eigentliche Verschlüsselung symmetrisch passiert, aber den Schlüssel des symmetrischen Verfahren habe ich asymmetrisch verschlüsselt.

Lucas Dohmen: Okay, also du erzeugst quasi einen temporären oder einen Einmalschlüssel und den teilst du allen über asymmetrische Kryptografie mit?

Christoph Iserlohn: Ganz genau, so mache ich das. So machen, dass auch die etablierten Verfahren, also PGP oder S/MIME. Die haben jeweils den, du hast das gerade temporären Schlüssel genannt, der wird verschlüsselt. Und damit ist der eigentliche Payload, der Inhalt der E-Mail, dann verschlüsselt. Und dann kann ich halt beliebig vielen Sendern das zugänglich machen.

Lucas Dohmen: Okay, wenn man jetzt diese drei Kategorien betrachtet, also asymmetrisch, symmetrisch und hybrid. Hast du da Beispiele für Anwendungsgebiete oder Verfahren, die das verwenden?

Christoph Iserlohn: Ja, da gibt es eine ganze Reihe von Sachen, die das verwenden. Man denkt jetzt bei uns im Bereich zum Beispiel an TLS, also an verschlüsselte Verbindungen im Internet. Es gibt WPA. Das ist das Verfahren, womit ich mein WLAN verschlüsseln kann, Es gibt wie genannt PGP, es gibt S/MIME, die ganzen Messenger machen das. Es ist ganz verschieden, wer welches Verschlüsselungsverfahren einsetzt. Wir hatten jetzt gerade bei den E-Mailverfahren: Die nehmen ein Hybridverfahren. Bei TLS ist es auch ein Hybridverfahren. Aber zum Beispiel bei WPA, also der Verschlüsselung von deinem WLAN, da gibt es das PSK-Verfahren, pre-shared key. Und da muss man dann die entsprechenden Verschlüsselungskeys eingeben an seinen Endgeräten und an dem Router. Das ist dann ein symmetrisches Schlüsselverfahren, das diese Keys benutzen. Was bei WLAN ja auch ok ist, weil ich wahrscheinlich, wenn ich so ein WLAN einrichte, ja auch entsprechend vor Ort bin, um diese Schlüssel einzurichten an meinem WLAN-Router und an meinem Endgerät, dieser Schlüsselaustausch halt nicht um die halbe Welt gehen muss.

Lucas Dohmen: Ja, verstehe. Okay, das ist jetzt eine Kategorisierungen zwischen symmetrisch, asymmetrisch und hybrid. Ein anderer Teil, über den man nachdenken muss, ist: Wo wird verschlüsselt? Es gibt so Begriffe wie Ende-zu-Ende-Verschlüsselung. Kannst du das mal einordnen, was das bedeutet und was es da für Varianten gibt?

Christoph Iserlohn: Die Frage ist, wann und wo werden die Daten verschlüsselt? Da würde man jetzt drei Kategorien unterscheiden. Das eine ist die Ende-zu-Ende-Verschlüsselung. Das zweite ist die Transport-Verschlüsselung. Und das Dritte ist Encryption-at-rest. Bei der Ende-zu-Ende-Verschlüsselung ist es so, dass sozusagen jeweils bei dem endgültigen Empfänger und beim Sender verschlüsselt wird. Das heißt – das ist zum Beispiel bei E-Mail der Fall, bei PGP oder S/MIME – ich verschlüssele das auf meinem Rechner. Dann läuft das durchs Internet, durch was weiß ich wieviele Mail-Server und kommt dann irgendwann bei dir an und erst du entschlüsselt die Nachricht, die ich dir geschickt habe. Das heißt dann, auch wenn sie durch viele Zwischenstationen gehen, kann niemand auf die Daten zugreifen. Das ist natürlich für die Privatsphäre das Sicherste, um Daten zu übermitteln.

Lucas Dohmen: Das bedeutet explizit, dass, wenn jetzt beispielsweise meine Mail-Account geknackt wird, dass man trotzdem diese Mail nicht lesen könnte?

Christoph Iserlohn: Ja, wenn du die noch auf dem Server gespeichert hast und die liegen da noch in der verschlüsselten Form vor, dann kann damit niemand etwas anfangen, sondern erst, wenn du die auf deinem Client entschlüsselt hast. Dann gibt es die Transport-Verschlüsselung. Das heißt, das sind nur Daten, die im Transit sind, das ist zum Beispiel bei TLS so. Wenn wir eine sichere Verbindung im Internet aufmachen, zum Beispiel zum Webserver. Dann werden die Daten während des Transports verschlüsselt. Das heißt, dein Client verschlüsselt die Daten, und beim Server werden sie entschlüsselt. Aber was der Server damit (macht), der könnte die zum Beispiel weiterleiten an weitere Backend-Systeme, dann sind die oft nicht mehr verschlüsselt, sondern man hat eine – man nennt das dann TLS-Terminierung. Das heißt, der vorderste Server, der durchs Internet erreichbar, der spricht noch TLS. Und die Daten werden dahinter, wenn ein Server dann mit drei, vier Microservices spricht oder SCS-Systemen, dann kann der dabei auch unverschlüsselt mit denen reden.

Lucas Dohmen: Okay.

Christoph Iserlohn: Das Dritte ist die Encryption-at-rest. Wenn ich Daten irgendwo speichere, dann sollten die vielleicht auch verschlüsselt gespeichert sein. Das habe ich zum Beispiel, wenn ich sensitive Informationen in einer Datenbank speichern. Da möchte ich mich ja davor schützen, falls jemand in meine Systeme einbricht und zum Beispiel ein Datenbank-Dump machen kann oder das File-System irgendwie kopiert oder ganz einfach die Festplatte aus dem Server nimmt, dass die Daten dann auch noch geschützt sind. Das ist Encryption-at-rest. Das heißt, das sind dann zum Beispiel verschlüsselte Dateisysteme oder verschlüsselte Datenbanken. Oder auch, wenn ich nur bestimmte Daten verschlüsselt in einer normalen Datenbank ablege, wenn ich die selber verschlüssele. Dann kann keiner damit etwas anfangen, ohne den Schlüssel zu haben, wenn er die Datenbankfiles irgendwie kopieren kann oder die Festplatte.

Lucas Dohmen: Und wo liegt dann der Schlüssel?

Christoph Iserlohn: Der Schlüssel sollte dann… Das kommt auf den Use Case an. Wenn ich ein verschlüsseltes Dateisystem habe, dann liegt der auch irgendwo auf dem Dateisystem und normalerweise, wenn ich das System hochfahren, muss ich einmal das Passwort eingeben, um diesen Schlüssel zu entschlüsseln. Der ist dann mit meinem Passwort verschlüsselt. Und dann hat der laufende Computer, das laufende Betriebssystem Zugriff auf diesen Schlüssel. Das heißt, wenn ich dann gehackt werde, ich habe irgendeinen einen Trojaner auf meinem Rechner, dann nützt mir die verschlüsselte Festplatte relativ wenig, weil das laufende System kann die Daten entschlüsselt und hat Zugriff auf den Schlüssel. Wenn mir jetzt aber mein zugeklappter Laptop geklaut wird, dann kommt keiner mehr daran. Auch nicht, wenn er die Festplatte ausbaut, weil die Daten darauf verschlüsselt vorliegen und derjenige, der den Laptop geklaut hat, nicht mehr an den Schlüssel herankommen kann.

Lucas Dohmen: Das heißt, diese Festplattenverschlüsselung, die man in den meisten Betriebssystemen mittlerweile eingebaut hat, ist ein Beispiel für Encryption-at-rest?

Christoph Iserlohn: Genau. Das ist ein Beispiel dafür. Ein anderes Beispiel aus dem Entwickleranteil, das heißt git-crypt. Damit kann man bestimmte Geheimnisse innerhalb eines Git-Repositories verschlüsseln. Und die werden entschlüsselt beim Checkout lokal auf der Platte. Da gibt bei Git Filter, die auf Dateiebene arbeiten, wenn ein Checkout gemacht wird. Dann werden sie entschlüsselt und wenn der Checkin kommt, dann wird ein Filter angewendet, der die Daten verschlüsselt. Das heißt, die liegen dann auf der Platte nochmal extra verschlüsselt vor. Wenn ich es dann irgendwohin pushe, zum Beispiel nach Github öffentlich, kann man damit auch erst einmal nichts anfangen, wenn sich darin Secrets befinden, weil die dann verschlüsselt werden.

Lucas Dohmen: Okay. Kommen wir nochmal zurück zu Ende-zu-Ende-Verschlüsselung und Transport-Verschlüsselung. Ist das jetzt wünschenswert immer Ende-zu-Ende-Verschlüsselung zu haben oder ist manchmal Transport-Verschlüsselung die richtige Wahl. Ist das ein Trade-off? Wie siehst du das?

Christoph Iserlohn: Das ist ein Trade-off. Man muss sich dann entscheiden. Aus welcher Sicht man auch daran geht. Also wenn ich jetzt aus einer Privacy-Sicht darangehe, dann würde ich sagen, Ende-zu-Ende-Verschlüsselung ist das Beste. Aber es gibt so bestimmte Use Cases, bei denen das dann halt nicht so gut funktioniert. Nehmen wir mal so ein Videokonferenz-System, Zoom. Das hat ja im Moment in der Corona-Krise einen gewaltigen Schub gemacht. Es hat ja auch mit Ende-zu-Ende-Verschlüsselung geworben. Und dann hat sich herausgestellt, das machen sie halt doch nicht, sondern sie nehmen eigentlich nur Transport-Verschlüsselung. Aber das ermöglicht ihnen dann auch bestimmte Features zu machen, die bei Ende-zu-Ende-Verschlüsselung nicht möglich sind. Zum Beispiel können Sie sich dann den Video-Stream und den Audio-Stream auf ihrem Server anschauen bzw. untersuchen. Und dann können Sie sagen ok, derjenige spricht gerade nicht, ich rechne das einfach mal runter, in ein Format, dass weniger Bandbreite verbraucht, weil der jetzt auch nicht groß im Bild ist und auch keinen Ton hat. Oder ich schalte den Ton-Stream komplett ab und spare dadurch Bandbreite. Dann kann man solche Features, wenn die Ende-zu-Ende verschlüsselt wären, dann würde der Stream sozusagen über den Server gehen und aussehen wie weißes Rauschen. Darauf kann ich halt nicht arbeiten, dann kann ich solche Comfort-Features, die Bandbreite sparen, nicht ermöglichen. Oder ein anderes Beispiel wäre, in Slack kann ich ja über alle Daten in allen Kanälen suchen, eine Volltextsuche machen. Das geht auch nur, wenn die Daten unverschlüsselt vorliegen. Das heißt, die kommen bei Slack, bei den Servern dann halt auch irgendwie unverschlüsselt an. Trotzdem will ich halt nicht auf eine Transport-Verschlüsselung verzichten, weil ich nicht möchte, dass das irgendwie einer abhört, während die Daten transportiert werden. Es würde ja schon reichen, wenn ich hier meinen Rechner aufmache, und dann sehe ich jede Menge WLANs, die ich nicht kenne, die hier von den Nachbarn sind oder sonstiges. Wenn das alles während des Transports unverschlüsselt wäre, dann könnte ich das alles mitlesen. Das will man natürlich auch nicht.

Lucas Dohmen: Okay, das heißt, wir könnten also zum Beispiel auch sagen, bestimmte Features müssten sonst auf dem Client werden, denn der kennt die Sachen. Wenn man jetzt eine Volltextsuche auf dem Client baut, würde das ja dann funktionieren. Aber das ist der Trade-off, den man eingeht, dann muss man solche Sachen auf der Client-Seite lösen können. Richtig?

Christoph Iserlohn: Ganz genau. Aber das ist halt oft unrealistisch. Also bei Slack würdest du ja alle Kanäle, alles, was da jemals an Daten war, lokal herunterladen müssen und da indizieren. Das ist sehr unwahrscheinlich, dass es irgendwie funktionabel wäre. Oder auch gewollt.

Lucas Dohmen: Auf jedem deiner Clients vielleicht.

Christoph Iserlohn: Dann auf jedem deiner Clients, genau. Da muss man sehen, welchen Trade-off man eingehen will, wie schützenswert die Daten sind. Zum Beispiel würde ich jetzt über Slack keine Passwörter verteilen. Wenn wir sagen, okay, wir müssen jetzt einen Schlüsselaustausch machen, das ist schwierig. Ich kann sagen, Slack ist ja transportgesichert, das kann keiner abhören, aber trotzdem landen dann die Daten irgendwo unverschlüsselt, zum Beispiel in der Suche bei Slack. Das will ich dann nicht. Dann will ich eine Ende-zu-Ende-Verschlüsselung haben. Wenn ich aber jetzt einfach Smalltalk mache, dann ist das wahrscheinlich nicht so schlimm, wenn auch Slack irgendwie eine Suchmaschine bei sich hat, also intern. Das muss man halt abwägen.

Lucas Dohmen: Aber man muss ja auch Vertrauen gegenüber dem Server haben, dass diese Daten nicht vielleicht vollständig frei in der Öffentlichkeit zugänglich wären.

Christoph Iserlohn: Das ist ein Risiko, das muss man auch immer abwägen. Es ist ja nicht nur so, dass die das absichtlich veröffentlichen würden, sondern oft ist es ja so, dass es entweder irgendeine Fehlkonfiguration gibt. Das hat man ja auch schon öfter gehört, dass irgendwelche MongoDBs, Elasticsearch-Stacks oder Sonstiges ohne Passwort am Netz hingen und sich darauf jeder verbinden kann. Oder wenn Slack halt auch Opfer von einem Hackerangriff wird und da zum Beispiel auch Elasticsearch-Datenbank kopiert würde, dann sind die Daten halt auch verloren. Das muss man sich halt vorher überlegen, ob das ein Risiko ist, das ich eingehen kann oder nicht.

Lucas Dohmen: Alles klar. Okay, wollen wir jetzt ein bisschen in diesen „Was wähle ich für welchen Use Case“-Teil übergehen? Also eine Sache, die man vielleicht schon mal gehört hat: Irgendwie RSA und ECC. Welches davon besser und was bedeutet das überhaupt?

Christoph Iserlohn: Das ist etwas ganz Wichtiges, mit dem man sich beschäftigen sollte, auch wenn man so die Verschlüsselung in Grundzügen kennt. Also wir haben jetzt schon mehrmals AES erwähnt, und wenn man weiß, das ist ein symmetrisches Verschlüsselungsverfahren, das wohl ganz gut ist, oder RSA, das ist auch ganz gut, dann heißt das noch nicht, dass man das so einfach einsetzen kann. Das Problem, diese ganzen Sachen haben verschiedene Vor- und Nachteile. Und dann haben wir noch verschiedene Betriebsmodi, in denen man sie einsetzen muss. Das muss man alles unterscheiden. Wenn ich zum Beispiel bei OpenSSL schaue, dann kann ich zum Beispiel, dann kann ich beispielsweise sagen, gib mir mal raus, wieviele Verschlüsselungsverfahren du so kennst. Allein wenn ich für AES suche, dann hat das 40 verschiedene. Und bei symmetrischen Verfahren habe ich dann irgendwie über 150. Und dann hab ich noch nochmal 80 verschiedene elliptische Kurven, da kommen wir gleich zu. Da ist es halt sehr schwierig zu sagen, was nehmen wir denn jetzt da, und wofür nehmen wir das? Man muss das entsprechend ein bisschen auseinander dividieren. Da muss dann erst einmal klar sein, okay, welchen Use Case habe ich, brauche ich eine symmetrische Verschlüsselung oder eine asymmetrische Verschlüsselung oder eine hybride. Da muss ich halt schauen, nehme ich jetzt RSA, ECC, AES und so weiter. Und dann würde ich sagen, fangen wir mal so an mit den asymmetrischen Verfahren. Da gibt es eigentlich nur zwei, die man benutzt. Das ist RSA und ECC. ECC steht für eliptic curve cryptography und das ist ein Verfahren, das auf sogenannten elliptischen Kurven arbeitet. Elliptische Kurven sind ein mathematisches Konstrukt. Den Namen haben sie dafür bekommen, wenn man die aufplottet, dann sehen sie aus wie eine Kurve, die so ein bisschen die Form einer Ellipse hat. Das hat aber noch ganz viele andere mathematische Eigenschaften, die man sich zunutze macht, um darauf Verschlüsselung zu machen. Aber das brauchen wir jetzt wahrscheinlich nicht im Detail zu machen. Das ist für einen Podcast auch wenig geeignet, weil das sehr viel Mathematik ist. Aber das ist so das asymmetrische Verfahren, was ich jetzt, wenn ich etwas neu entwickele, wahrscheinlich einsetzen würde gegenüber RSA. RSA ist das ältere Verfahren. Das sind die Initialen der Entwickler, das sind Ron Rivest, der Herr Shamir und der Herr Adleman. Das funktioniert auch noch gut, das kann man heute auch noch einsetzen. Aber das Problem dabei ist: Die Sicherheit hängt von der Schlüssellänge ab. Und wenn man jetzt eine Sicherheit von 128 Bit haben wil, das heißt, ich hätte jetzt ein Verfahren und der Schlüssel ist 128 Bit groß und ich müsste alle Schlüssel ausprobieren. Das ist Sicherheit 128 Bit. Es gibt kein Verfahren, wie man das irgendwie verkürzen kann. Bei 128 Bit bräuchte man wahrscheinlich länger, als das Universum existiert, also ist man gut geschützt. Jetzt gibt es bei RSA so ein paar Möglichkeiten, das Verfahren abzukürzen. Um eine Sicherheit von 128 Bit zu erreichen, bräuchte ich bei RSA 3072 Bit. Da müsste der Schlüssel 3072 Bit sein. Und bei ECC, also bei elliptischen Kurven, bräuchte ich aber nur eine Schlüssellänge von 256 Bit. RSA wächst da auch viel schneller. Wenn ich jetzt die Schlüssellänge verdoppele auf 256, dann bräuchte ich bei RSA ca. 15360 und bei ECC nur 512. Und umso länger dieser Schlüssel ist, desto aufwendiger ist das Rechenverfahren. Wir haben jetzt Rechner, die sind im Moment 64 Bit. Das heißt, die können nativ mit Zahlen, die 64 Bit lang sind, umgehen. Wenn ich jetzt jede Menge Operationen mache auf Zahlen die mehr als 64 Bit haben, dauert das sehr, sehr lange. Man kann sich vorstellen, wenn wir Zahlen haben mit 15360 Bit, dann ist das Verfahren unendlich langsam gegenüber anderen Verfahren, die kürzere Schlüssellängen haben. Und deshalb nimmt man eigentlich heutzutage elliptische Kurven, weil das deutlich schneller geht als das alte RSA-Verfahren.

Lucas Dohmen: Okay, du hast das jetzt schon so ein bisschen angesprochen, aber selbst wenn ich mich jetzt für das entschieden habe, habe ich in OpenSSL immer noch sehr viele Wahlmöglichkeiten vor mir. Wie grenze ich das denn weiter ein?

Christoph Iserlohn: Wie gesagt, ich hatte ja gerade gesagt, man kriegt zum Beispiel 40 verschiedene elliptische Kurven, auf denen man da arbeiten kann, raus. Da sollte man halt am besten nicht einfach raten, wir nehmen jetzt irgendeine, sondern sich an bestimmte Empfehlungen halten. Diese Kurven sind standardisiert. Meine Empfehlung wäre die Curve 25519. Das ist so der aktuelle Stansard, den man benutzen würde. Da brauche ich jetzt nicht unbedingt in die Details eingehen, warum man das nimmt, das ist aber von der Sicherheit her wahrscheinlich die Beste. Was man meiden sollte, wären zum Beispiel Kurven, die mit ANSI beginnen oder von NIST, das ist das amerikanische Standardisierungsinstitut für Technologie, das ist so ähnlich wie DIN, und die Kurven wurden zum Beispiel von der NSA entwickelt für ANSI und für NIST. Und man kann da jetzt nicht unbedingt ausschließen, dass sich darin nicht irgendwo eine Hintertür versteckt, die noch nicht gefunden wurde. Da ist das Vertrauen vielleicht nicht so hoch, während die Curve 25519 von Dan Bernstein entwickelt wurde und das ist ein hoch angesehener Kartograf, der arbeitet halt an der Universität und nicht bei der NSA. Er hat schon sehr viele gute kryptografische Algorithmen erfunden. Die Kurve ist ausgetestet, da haben schon andere Kryptologen ihre Kryptoanalyse drüber gefahren. Und das ist jetzt sozusagen… Wenn man elliptische Kurven nimmt, dann nimmt man die.

Lucas Dohmen: Okay. Und das wäre jetzt auch eine von den Optionen, die man beispielsweise hat, wenn man so einen SSH-Schlüssel generiert, richtig? Ganz genau. Bei SSH-keygen kann man RSA nehmen oder DSA und es gibt auch elliptische Kurven. Da gibt es dann auch eine, die auf dieser Kurve aufbaut. Es gibt auch Signaturverfahren, die darauf aufbauen, die heißt dann ed25519. Man sollte auf das 25519 im Namen schauen. Je nachdem, brauche ich jetzt eine asymmetrische Verschlüsselung, brauche ich eine Signatur oder brauche ich einen SSH-Key. Und dann muss ich schauen, dass ich das am besten darin habe und dann bekomme ich etwas Sicheres. Wobei man sagen muss, RSA ist auch noch sicher. Also für heutige Schlüssellängen ist die Empfehlung 4096. Das ist auch noch sicher. Das Problem ist halt zum Beispiel bei SSH, dass manche Server solche Keys mit elliptischen Kurven noch gar nicht unterstützen. Und dann muss ich RSA nehmen.

Lucas Dohmen: Wann würde ich das herausfinden, wenn ich versuche, den da abzulegen, oder …?

Christoph Iserlohn: Es kommt drauf an, ob man den unter Kontrolle hat, den Server, oder nicht. Also wenn ich ihn ablege und es mein eigener SSH-Server ist, dann bekomme ich das mit, wenn ich den hochfahre, oder kann das mitkriegen. Aber dann kann ich ja auch selber updaten. Aber wenn ich zum Beispiel so eine Gitlab-Installation habe, dann kann es passieren, dass das erst herauskommt, wenn ich versuche mich zu verbinden. Dann kann ich den über die Weboberfläche da ablegen und das funktioniert dann einfach nicht, weil der den erst zur Laufzeit raussucht. Da muss man dann leider probieren. Wenn der nicht funktioniert, macht man halt einen RSA-Key.

Lucas Dohmen: Okay. Das heißt, ich könnte auch einen super sicheren Schlüssel und einen nicht ganz so sicheren haben und ich versuche immer erst einmal meinen super sicheren abzulegen. Und wenn das nicht geht, dann nehme ich den etwas weniger sicheren, der ja immer noch sicher ist?

Christoph Iserlohn: Nein, so würde ich das nicht sagen, denn die sind beide sicher. Aber du nimmst den, der schneller geht und kürzer ist, also speicherplatzsparend ist.

Lucas Dohmen: Okay, verstanden. Gut, nachdem wir da so ein bisschen reingeschaut haben, ein Thema, das glaube ich viele Leute beschäftigt, mich zum Beispiel auch, ist die Zukunft von diesen ganzen Sachen. Es gibt ja viel, über das man hört: Quantencomputer, dass das irgendwie die Kryptografie maßgeblich verändert oder vielleicht alle Verfahren unsicher macht. Kannst du das mal einordnen? Ist das so oder ist das Quatsch?

Christoph Iserlohn: Das ist schon so, dass, wenn wir jetzt Quantencomputern hätten in der entsprechenden Größe, also mit entsprechend vielen Qubits, dann hätten wir bei den asymmetrischen Verfahren ein ziemlich großes Problem. Es ist so, dass die Sicherheit von den asymmetrischen Verfahren nicht bewiesen ist, sondern sie beruht auf der Annahme von P ungleich NP. Das ist ein berühmtes Problem der Informatik, wenn man das löst, dann hat man jede Menge Ruhm und ich glaube, auch eine Million Dollar gewonnen. Bis jetzt ist die Annahme, dass das so ist. Quantencomputer würden dieses P ungleich NP in Frage stellen, weil sie dadurch, dass sie so viele Zustände gleichzeitig berechnen können, dafür auch eine Lösung finden würden. Das ist jetzt alles sehr vereinfacht. Aber da gibt es ein großes Problem für die jetzigen Verfahren. Es gibt auch schon Sachen, zum Beispiel für RSA, deren Sicherheit darauf beruht, dass man große Zahlen keine Primfaktor-Zerlegung machen kann, dass es da Algorithmen gibt, die das angreifen können. Algorithmen, die nur auf Quantencomputer laufen können. Von daher ist da schon eine konkrete Gefahr, aber es wird viel daran geforscht. Das ist das Thema Post-Quantum-Cryptographie, dass man Verfahren entwickelt, die gegen so etwas nicht anfällig sind, gegen solche Angriffe. Aber das ist schon sehr aktives Forschungsfeld, heutzutage. Kryptologen beschäftigen sich im Moment damit. Denn es gibt sichere Verfahren und wenn die in die Zukunft schauen, müssen die an so etwas denken. Das dauert ja auch immer sehr lange. So ein AES-Algorithmus, der Wettbewerb, bei dem der entwickelt wurde, hat drei Jahre gedauert, um das zu machen. Oder wenn man andere… So für Verschlüsselung, scrypt oder bcrypt (Anmerkung: in diesem Fall für Passwort-Hashing), das dauert halt viele Jahre, bis man die als sicher ansieht und bis genügend Kryptoanalysen darüber gemacht werden. Das heißt, man muss in viel längeren Zeiträumen denken. Das heißt, man muss sich jetzt auch schon mit solchen Sachen wie Quantencomputer beschäftigen.

Lucas Dohmen: Das heißt aber, definitiv sind die aktuellen Verfahren dafür anfällig?

Christoph Iserlohn: Definitiv ja.

Lucas Dohmen: Alles klar. Gibt es denn sonst noch interessante Zukunftsentwicklungen, an denen vielleicht gerade die Forscher forschen, was in Zukunft kommt im Kryptografiebereich.

Christoph Iserlohn: Ja, es gibt noch den Bereich homomorphe Verschlüsselung, woran viel geforscht wird. Da ist das Prinzip, das ich eine Operation, die ich sonst auf den Klartext vornehmen würde, auf dem verschlüsselten Text vornehmen kann und dann ein verschlüsseltes Ergebnis bekomme. Das ist jetzt ein bisschen abstrakt, aber ein konkreter Use Case dafür wäre zum Beispiel die Suche, die wir gerade bei dem Slack-Beispiel hatten. Wenn ich eine Suche implementieren möchte, muss ich den Klartext haben. Sonst kann ich nicht mein Suchwort eingeben und daraus etwas herausbekommen. Aber wenn ich jetzt diese Operation der Suche, die da stattfindet, irgendwie so eine Indexsuche, auf verschlüsselten Daten machen könnte, dann könnte ich das Problem lösen, dass ich das unverschlüsselt irgendwo vorliegen haben muss. Dann kann alles verschlüsselt irgendwo vorliegen und ich kann trotzdem so eine Operation wie eine Suche darauf ausführen. Gerade jetzt, wo viel auch in der Cloud gemacht wird, kann ich die Daten immer einfach verschlüsselt ablegen und Operationen darauf ausführen, wofür ich sonst eine Entschlüsselung bräuchte. Aber das befindet sich noch ein bisschen in den Kinderschuhen, dieses ganze Thema. Da gibt es jetzt noch keine Sachen, die man praktisch anwenden kann. Aber das ist ein Gegenstand, an dem ich auch sehr aktiv geforscht wird, weil das eine ganze Reihe von Problemen lösen würde. Zoom könnte dann auch zum Beispiel vielleicht erkennen oder Sachen machen darauf um Bitraten herunter zu rechnen, ohne selbst in den Klartext schauen zu können.

Lucas Dohmen: Das klingt auf jeden Fall abgefahren, ich kann es mir noch nicht so richtig vorstellen, dass das geht. Ist ja noch ein bisschen Zukunftsmusik. Okay. Ja, dann danke ich dir sehr, Christoph, für diesen tollen Überblick. Ich bin mir sicher, du wirst auch noch bei einigen weiteren Folgen in dieser Serie nochmal zu Gast sein. Ich glaube, wir haben auf jeden Fall vor, noch mal über TLS zu sprechen, richtig?

Christoph Iserlohn: Ja, TLS steht noch auf dem Plan und auch Zertifikate. Das ist ein bisschen so eine Serie, eine Reihenfolge: Erst mal ein bisschen Kryptografie, dann kann man Zertifikate besser verstehen. Und wenn man Zertifikate und Kryptografie einigermaßen verstanden hat, kann man TLS super verstehen.

Lucas Dohmen: Super, darauf freue ich mich schon. Dann danke ich dir und den Hörerinnen und Hörern: Bis zum nächsten Mal! Tschüss!

Christoph Iserlohn: Tschüss!