Signaturdatei dieser Seite und der CSS-Datei
Version 1.3, 06.06.2012
mein Projekt zur Förderung kostenloser OpenPGP-Schulungen:
Wichtige Grundbegriffe der Kryptografie sind:
Ausführlichere Anleitungen für GnuPG (freie OpenPGP-Implementierung) und darauf aufsetzende Software finden sich auf meiner Webseite (mit Schwerpunkt auf den Aspekten, die ich interessant finde) und noch viel ausführlicher hier.
Der Begriff Verschlüsselung dürfte klar sein. Er teilt sich technisch auf in symmetrische Verschlüsselung und asymmetrische Verschlüsselung. Symmetrische ist technisch einfacher. Bei dieser Variante wird derselbe Schlüssel (z.B. ein Passwort) zum Verschlüsseln und zum Entschlüsseln verwendet. Wenn man jemandem symmetrisch verschlüsselte Daten schickt, dann muss man ihm auch den Schlüssel zukommen lassen, damit er sie auspacken kann. Bei asymmetrischer Verschlüsselung ist es umgekehrt: Der Empfänger (und nur er) hat bereits den zum Entschlüsseln benötigten (den privaten) Schlüssel. Aber er muss erst den zum Verschlüsseln benötigten (den öffentlichen) Schlüssel dem Absender zukommen lassen, bevor verschlüsselte Kommunikation möglich ist.
Dass Ver- und Entschlüsselung mit unterschiedlichen Schlüsseln funktionieren, ist intuitiv nicht verständlich. Asymmetrische Verschlüsselung ist technisch insgesamt komplizierter, wovon der Anwender aber nichts mitbekommt (mit Ausnahme der Schlüsselhandhabung). Wegen dieser Kompliziertheit (d.h. der Langsamkeit in der Ausführung) werden normalerweise nur sehr kleine Datenmengen asymmetrisch verschlüsselt. Wenn eine Datei (oder E-Mail) verschlüsselt werden soll, dann erzeugt die Software einen zufälligen Schlüssel, mit dem die Daten symmetrisch verschlüsselt werden. Das hat nicht nur einen Vorteil bei der Geschwindigkeit, sondern erlaubt es, diese Daten für mehrere Empfänger gleichzeitig zu verschlüsseln (was im Gegensatz zu der grauen Theorie praxisrelevant ist). Für jeden Empfänger wird dann dieser zufällige Schlüssel asymmetrisch verschlüsselt, und jeder dieser verschlüsselten Codes wird den Daten beigelegt. Die Software des Empfängers entschlüsselt dann ihre Variante des Codes (der für alle Empfänger derselbe ist) asymmetrisch und wendet damit eine symmetrische Entschlüsselung auf die Daten an. Das nennt man eine hybride Verschlüsselung.
Die Basis asymmetrischer Kryptografie sind mathematische Operationen, die nur mit sehr großem Aufwand umkehrbar sind. Ein Beispiel:
Die Multiplikation
2791018331347145912514213322178741945516851 × 176048812362139203679547991634521134841023 = 491355462514624553457859427248831157229986980411707801280364474517791599873452578573
ist für einen Computer in Sekundenbruchteilen ausführbar. Wenn es sich bei den beiden Faktoren um Primzahlen handeln sollte, dann wäre es auch für einen Supercomputer in überschaubarer Zeit (das sind in diesem Zusammenhang Jahrzehnte) nicht möglich, diese beiden Faktoren zu bestimmen, wenn ihm nur das Produkt bekannt wäre.
Bei Verschlüsselung interessiert einen vor allem eins: Ist sie sicher? Sicher ist dabei ein relativer Begriff. Sicher vor dem Nachbarn
lässt sich mit weitaus geringerem technischen Aufwand realisieren als sicher vor der NSA
. Wenn man keinen Grund hat, seine Daten vor der NSA zu schützen (denn sie wird sie kaum dem Nachbarn verraten), sollte man sich den Mehraufwand sparen. Die Sicherheit einer Verschlüsselung an sich hängt von drei Faktoren ab:
der Länge des Schlüssels (genauer: die Größe des Schlüsselraums)
der Qualität des Verschlüsselungsalgorithmus (wenn dieser Schwächen aufweist, reduziert das die effektive Schlüssellänge)
der Zufälligkeit des Schlüssels (eine der größten Katastrophen der IT-Sicherheit wurde durch ein Problem dieser Art ausgelöst)
Und ganz wichtig: Die Sicherheit der Daten hängt meist nicht von der Sicherheit der Verschlüsselung ab, sondern ist viel niedriger. Siehe unten, praktische Grenzen der Sicherheit
.
Die Grenze für sichere symmetrische Schlüssel liegt heutzutage irgendwo zwischen 80 und 128 Bit. Da asymmetrische Schlüssel anders funktionieren, fangen die Schlüssellängen dort erst bei ca. 1024 Bit (RSA und DSA) bzw. 256 Bit (ECC) an. Was heißt das für Passwörter?
Wenn ein Passwort aus Groß- und Kleinbuchstaben, Ziffern und zwei sonstigen Symbolen bestehen kann, dann gibt es für jede Stelle 64 Möglichkeiten; das entspricht sechs Bit (26=64). Die wünschenswerte Größe von 80 Bit erreicht ein derart konstruiertes Passwort also ab einer Länge von 14 Zeichen (14×6=84). AfRe!OlQTqRe.9 ist also im Prinzip ein gutes Passwort (nein, bitte nicht dieses übernehmen).
Die 280-Untergrenze gilt natürlich nur für Offline-Angriffe, also solche, bei denen der Angreifer auf seinem eigenen Rechner versuchen kann, den Schlüssel zu erraten. Bei Internetpasswörtern reichen viel kürzere Schlüssel aus, weil – begrenzt durch die Geschwindigkeit der Internetanbindung des Servers – nur vergleichsweise wenige Versuche pro Sekunde stattfinden können. Mal ganz abgesehen davon, dass die meisten Anbieter nach der ersten "Million" Fehlversuche Gegenmaßnahmen ergreifen dürften.
Die "Sicherheit" eines Verschlüsselungsverfahrens meint den Aufwand, den ein Angreifer aufbringen muss, um an die Daten zu kommen. Die Dimension dieses Aufwands ist Rechenleistung. Wenn man also ein fünfstelliges Passwort hat, das an jeder Stelle 32 Möglichkeiten hat, dann gibt es 33554432 (225) unterschiedliche Passwörter. Nimmt man statt fünf Stellen sechs, fällt der 32fache Rechenaufwand an. Das Problem ist, dass der Anwender sich dann auch mehr Stellen merken muss. Man kann den Aufwand aber auch so verändern, dass es nicht den Anwender trifft.
Anstatt das Passwort direkt oder dessen normalen Hashwert zu verwenden, wiederholt man das Hashen der Eingabe einige Male. Für die Verschlüsselung ist das egal, man muss sich nur die Anzahl der Runden merken. Aber der Rechenaufwand (für das Testen eines Einzelnen Passworts) erhöht sich entsprechend. Wenn man die Sicherheit um den Faktor 1000 erhöhen will, kann man im Fall von 32 Möglichkeiten entweder zwei Stellen ergänzen oder aber die Rundenzahl der Passwortverarbeitung um diesen Faktor erhöhen. Das praktische Limit dafür ist die Wartezeit. Wenn man an einem sehr schnellen Rechner eine Sekunde warten muss, dann sind das bei einem langsamen Rechner auch mal zehn.
Zum Beispiel LUKS (Festplattenverschlüsselung: --iter-time) und gpg (GNU-Programm für OpenPGP: --s2k-count) bieten diese Möglichkeit an.
Verschlüsselungsalgorithmen können mathematisch und technisch geknackt werden. Das obige Beispiel der Multiplikation großer Primzahlen wird vermutlich in absehbarer Zeit dadurch gelöst, dass eine ganz neue Art von Computer, der Quantencomputer, die Faktorisierung auch sehr großer Zahlen schnell erledigen kann.
Wenn jemand an verschlüsselte Daten herankommen will, wird er nur dann auf die Verschlüsselung losgehen, wenn das der einfachste Weg ist. Das ist er fast nie. Der einfachste Weg (hinterher) ist es, den Schlüssel zu klauen. Wenn man schon im voraus weiß, an welche Daten man will, ist es meist am einfachsten, sie vor der Verschlüsselung zu klauen oder die Verschlüsselung zu manipulieren (z.B. dem Verschlüsselnden einen falschen Schlüssel unterschieben). Verschlüsselte Daten sind deshalb in der Regel nicht sicherer als die Systeme, die mit den entschlüsselten Daten oder den Schlüsseln in Berührung kommen. Virenscanner sind auf diesem Niveau kein relevanter Schutz.
Eine Hashfunktion ist eine (Einweg-)Funktion, die aus beliebigen Eingabedaten (meist dem Inhalt einer Datei) eine Zeichenkette (bzw. eine Zahl) fester Länge erzeugt; meist 128, 160 oder 256 Bit. Bei guten bzw. sicheren Hashfunktionen ist es nicht möglich ist, gezielt passende Eingabedaten zu einem gegebenen Hashwert zu konstruieren, so dass nur ein brute force
-Angriff (Ausprobieren aller Möglichkeiten) bleibt, was bei großer Länge des Hashwerts und einem fehlerfreien Hashalgorithmus aussichtslos ist. Theoretisch sind schon die 128 Bit von MD5 ausreichend, aber es werden immer wieder Fehler in Hashalgorithmen (z.B. MD5 (kryptografisch inzwischen völlig unbrauchbar) und SHA-1 (muss mittelfristig ersetzt werden)) gefunden, die die effektive Hashlänge reduzieren.
Die zu hashenden Daten sind der Text Testtext
.
Man kann einem Hash nicht ansehen, welcher Art die Eingabedaten sind.
Da bei guten Hashfunktionen schon minimale Änderungen der Eingabedaten (ein verändertes Bit bei einer Gigabyte großen Datei) den Hash komplett ändern und es (bei nicht "geknackten") Hashfunktionen nicht möglich ist, zu einem gegebenen Hashwert andere passende Eingabedaten zu finden, kann man einen Datensatz mit seinem Hashwert eindeutig identifizieren. Das nutzt man zu unterschiedlichen Zwecken:
Man kann Passwörter prüfen, ohne sie zu speichern. Man speichert einfach den Hashwert. Wenn das eingegebene Passwort den gespeicherten Hashwert hat, ist es korrekt. Wenn jemand die "Passwort"-Datenbank knackt, muss er immer noch zu jedem Hashwert ein passendes Passwort finden.
Man kann anhand des Hashwerts prüfen, dass Daten korrekt übertragen wurden (üblich bei CD- und DVD-Images).
Man kann, wenn man den Hashwert auf einem sicheren Weg erhalten hat, sicherstellen, dass man auf einem unsicheren Weg die korrekten Daten erhalten hat (vor allem bei öffentlichen Schlüsseln üblich).
In Filesharingsystemen werden Dateien über ihren Hash identifiziert, damit klar ist, dass alle Beteiligten exakt dieselbe Datei meinen.
Digitale Unterschriften beziehen sich strenggenommen nicht auf die unterschriebenen Daten, sondern auf den Hashwert dieser Daten. Deshalb hängt die Sicherheit einer elektronischen Signatur an einer Sicherheitskette aus zwei Gliedern: der Sicherheit des Signaturverfahrens (Algorithmus, Schlüssellänge) und der Sicherheit des Hashwerts. Egal wie sicher das Signaturverfahren ist: Wenn es gelingt, andere Eingabedaten zu konstruieren, die denselben Hashwert haben, dann können diese manipulierten Daten jemandem als signiert untergeschoben werden.
Man kann über den Hash einer Datei nachweisen, dass man im Besitz dieser Datei (v.a. der darin enthaltenen Informationen) ist, ohne die Datei selber offenlegen zu müssen. Dies ist nützlich bei urheberrechtlich geschützten Werken (deren Entstehungszeitpunkt man womöglich nachweisen muss) und Geschäftsgeheimnissen, die man nur gegen eine Geheimhaltungsvereinbarung erhält. So kann man belegen, dass Informationen für einen nicht neu waren.
Eine elektronischen Signatur ist eine Art Unterschrift, die auf einem asymmetrischen Kryptografiesystem beruht. Es handelt sich dabei um eine Zeichenkette, die man nur dann erzeugen kann, wenn man im Besitz des zugehörigen privaten Schlüssels ist. Mit dem öffentlichen Schlüssel kann dann überprüft werden, ob die Signatur von dem privaten Schlüssel erzeugt wurde.
Vergleichbar der hybriden Verschlüsselung funktioniert auch die Signierung von Daten in zwei Stufen. Zuerst wird der Hashwert der Daten gebildet. Dieser Hashwert wird dann mit dem privaten Schlüssel verschlüsselt. Welcher Hashalgorithmus verwendet wird, ist dabei wählbar. Man kann also unterschiedliche Signaturen mit demselben Schlüssel für dieselben Daten erzeugen, indem man nacheinander unterschiedliche Hashfunktionen verwendet. Grundsätzlich kann jeder Schlüsseltyp mit jedem Hashtyp arbeiten, es gibt allerdings Beschränkungen. So unterstützt die erste Version von DSA nur Hashwerte bis 160 Bit Länge, aber unabhängig vom Typ (ein längerer Hash wird dann bei 160 Bit abgeschnitten). Die Größe der Signatur hängt von der Hashfunktion, dem Schlüsseltyp und der Schlüssellänge ab.
Unterschreiben kann man quasi alles, neben Dateien aller Art insbesondere auch andere Schlüssel, um diese gegenüber Dritten zu autorisieren (als certification authority (CA) oder im Rahmen eines web of trust).
Eine Signatur ist immer nur so sicher wie der für sie verwendete Hashwert. Wenn Fehler in einer Hashfunktion entdeckt werden, kann es im nachhinein möglich sein, andere Daten zu erzeugen, auf die die Signatur passt. Dann sieht es so aus, als wären die anderen Daten signiert worden.
Es ist beim Einsatz von Kryptografie sehr wichtig, dass man sich immer klar macht, was eine Aktion nicht nur technisch, sondern auch organisatorisch zu bedeuten hat. Wenn man einen öffentlichen Schlüssel verwendet, um eine Nachricht zu authentifizieren oder eine eigene Nachricht zu verschlüsseln, dann hat man (unter der Annahme, dass er dem Besitzer nicht "entwendet" wurde) die technische Sicherheit, dass kein Dritter die gesendete Nachricht entschlüsseln kann oder die empfangene maipulieren konnte. Aber organisatorisch reicht einem dieser Aspekt nicht aus, was leider den wenigsten klar ist. Denn natürlich ist es wenig wert, Kryptografie mit irgendwelchen Schlüsseln zu betreiben. Es ist entscheidend, dass man nur die richtigen Schlüssel verwendet, dass man eine Nachricht mit genau dem Schlüssel des Empfängers verschlüsselt. Ein Schlüssel ist nahezu wertlos, solange nicht gesichert ist, dass es sich um genau den Schlüssel handelt, den man verwenden will.
Das ist deshalb so wichtig, weil es nach menschlichem Ermessen unmöglich ist, die Verschnlüsselung zu knacken, aber mit vergleichsweise geringem Aufwand möglich ist, eine Internetverbindung zu manipulieren und jemandem einen manipulierten Schlüssel unterzuschieben. Das Ergebnis nennt man einen "man in the middle"-Angriff (MitM).
Man muss also irgendwie die nötige Sicherheit der Echtheit eines Schlüssels erreichen. Dafür gibt es prinzipiell zwei Möglichkeiten (die allerdings nicht von jeden Kryptosystem direkt zur Verfügung gestellt werden):
direkte Authentifikation des vorliegenden Schlüssels
indirekte Authentifikation über
eine Public-Key-Infrastruktur (PKI)
ein Web of Trust (WOT)
Die direkte Authentifikation funktioniert so, dass man sich (typischerweise) beim (angenommenen) Besitzer des Schlüssels von der Echtheit überzeugt. Dafür könnte man sich den Schlüssel von ihm auf einen Datenträger kopieren lassen oder sich den Hashwert des Schlüssels geben lassen (auch telefonisch ist das noch halbwegs sicher). Es ist deshalb nützlich, sich den Hashwert des eigenen Schlüssels aufzuschreiben und immer dabei zu haben. So kann man auch ohne Computer und Datenträger anderen, die einem persönlich begegnen, auf sicherem Weg den eigenen Hashwert übermitteln (den müssen die sich dann abschreiben; Profis haben ein paar Ausdrucke dabei.). Den auf sicherem Weg erhaltenen Hashwert vergleicht man dann mit dem des (auf unsicherem Weg) erhaltenen Schlüssels. Stimmen die beiden überein, wurde der Schlüssel nicht manipuliert. Man unterschreibt als Zeichen der erfolgreichen Authentifikation den Schlüssel mit seinem eigenen. Dadurch weiß die eigene Software, dass diesem Schlüssel vertraut wird. Außerdem kann die Unterschrift für Dritte nützlich sein.
Die indirekte Variante zeichnet sich dadurch aus, dass man den Schlüssel nicht selber prüft, sondern der Überprüfung anderer vertraut. Auch hier muss man sich in jedem Fall klar sein, dass die Beglaubigung durch einen anderen technisch sicher, aber ohne das Wissen, was und wie derjenige beglaubigt, wenig wert ist.
In einem hierarchischen System (PKI) gibt es genau eine Person oder Organisation (certification authority, CA), die autorisiert ist, Schlüssel zu beglaubigen. Das geht bei manchen Implementierungen (X.509 – SSL/TLS) so weit, dass Schlüssel nur eine Beglaubigung enthalten können. Dieses Verfahren wird bei der Sicherung von Webservern verwendet. Die Gegenstelle muss dazu der certification authority (d.h. ihrem Root-Zertifikat) vertrauen. Die Browser enthalten, damit das in der Praxis funktioniert, einige Root-Zertifikate. Das ist bequem, aber nicht im Sinne der Sicherheit, denn diese Voreinstellung bedeutet, dass der Browserhersteller der CA vertraut. Der Anwender vertraut verständlicherweise dem Browserhersteller, wobei es aber zwei Paar Schuhe sind, ob jemand einen guten Browser entwickeln und die Vertrauenswürdigkeit einer CA überprüfen kann. Auch ohne tiefgehende Betrachtung ist klar, dass die voreingestellten CAs nicht gleichwertig sind. Andererseits ist es schwierig, ein Root-Zertifikat zu authentifizieren. Innerhalb des X.509-Modells geht das zwar theoretisch, wird aber wohl nicht praktiziert (denn das hieße, dass eine CA einen Wettbewerber zertifizieren müsste; sich ein eigenes CA-Zertifikat von vielen anderen CAs zertifizieren zu lassen, ist teuer).
Ein Web of Trust verfolgt den umgekehrten Ansatz: Nicht nur wenige Akteure (CAs) sind privilegiert und lediglich eine Unterschrift wird unter ein Zertifikat gesetzt, sondern jeder einzelne Teilnehmer kommt dafür in Frage, andere zu beglaubigen. Dabei legt jeder selber fest, wem er zutraut, andere Schlüssel mit der gebotenen Sorgfalt zu signieren. Außerdem kann man direkt in der verwendeten Software angeben, wie viele Unterschriften (der einzelnen Vertrauensstufen) man verlangt, damit ein Schlüssel (automatisch) akzeptiert wird.
Damit liegt ein wesentlicher Unterschied zur PKI vor: Man kann einen Schlüssel akzeptieren, ohne ihm die Beglaubigung anderer Schlüssel zu erlauben. Bei der SSL-PKI ist es mit erheblichem Aufwand verbunden, nur einzelne Schlüssel zu akzeptieren und das auch deutlich zu machen. Vor allem profitieren andere davon nicht.