Alles was heutzutage an Verschlüsselung im EDV Bereich genutzt wird, wie etwa SSL, SSH, VPN's, PGP oder GnuPG beruht auf bestimmten kryptographischen Verfahren. Kennt man die grundsätzlichen Prinzipien kryptographischer Verfahren, lassen sich diese Techniken besser verstehen.
Allgemein beschreibt die Kryptographie Verfahren um aus einem gegebenen Klartext einen Chiffre zu erzeugen. Dabei wird zur Erzeugung des Chiffres heutzutage immer ein mathematischen Verfahren angewendet. Die Steganographie gehört nicht zur Kryptographie. Sie beschreibt Möglichkeiten eine Nachricht über versteckte Kanäle, wie etwa über eine andere (unverfängliche) Nachricht zu übermitteln. Üblicherweise wird dazu eine Datei in einer anderen Datei versteckt (zum Beispiel eine Textdatei die in den Bitfolgen einer Bilddatei versteckt wird). Steganographie und Kryptographie können miteinander kombiniert werden.
Für ein kryptographisches Verfahren kommt meist sowohl ein Schlüssel, als auch ein Chiffrieralgorithmus zum Einsatz. Der Algorithmus ist das angewandte mathematische Verfahren, der Schlüssel dient der konkreten Ver-, bzw. Entschlüsselung der Nachricht.
Grundsätzlich lassen sich 3 verschiedene kryptographische Verfahren unterscheiden: Die symmetrische Kryptographie, die asymmetrische Kryptographie und sogenannte Hash- oder Fingerprintverfahren.
Unkundige glauben oft, die Sicherheit einer Verschlüsselung hängt nur von der Länge eines Schlüssels (gemessen in Bit) ab. Tatsächlich ist die Schlüssellänge im allgemeinen nur der geringere Teil dessen was eine Verschlüsselung sicher macht. Der wesentliche Teil der Sicherheit hängt vom verwendeten Algorithmus ab. Kryptographische Algorithmen beruhen auf extrem schwer zu lösenden mathematischen Problemen. Ein Algorithmus gilt dann als hinreichend sicher, wenn der Aufwand zum errechnen des Schlüssels mit heutiger oder wahrscheinlich in den nächsten Jahren verfügbarer Rechenleistung so groß ist, daß ein nicht mehr überschaubarer Zeitraum (zum Beispiel Jahrtausende) notwendig wäre, um den Schlüssel zu errechnen. Dies bedeutet natürlich auch das größere Durchbrüche in der Leistungsfähigkeit von Computern, ebenso wie Fortschritte in der Mathematik bisher als sicher geltende Verfahren unsicher werden lassen können.
Um die Sicherheit eines Algorithmus zu beweisen ist es daher üblich einen Algorithmus zu veröffentlichen und durch möglichst viele Mathematiker und Kryptologen eine Schwachstelle zu finden. Algorithmen die auf Geheimhaltung beruhen, können niemals so sicher sein, wie ein Algorithmus der veröffentlicht wurde und dennoch von keinen Mathematiker als zu schwach entlarvt wurde. Sollen neue kryptographische Algorithmen als Standard eingeführt werden, werden daher meist Wettbewerbe unter Kryptologen ausgetragen, bei denen jeder Beitrag den kritischen Augen der anderen standhalten muß. Durch solch einen Wettbewerb wurden zum Beispiel AES zum Nachfolgestandard von DES. Derzeit (2011) läuft auch ein Wettbewerb für einen Nachfolger des SHA1 Standards, der als SHA3 standardisiert werden soll.
Das Veröffentlichen von Verschlüsselungsalgorithmen zur allgemeinen Begutachtung verhindert auch die Möglichkeit eine Hintertür in einen Verschlüsselungsalgorithmus einzubauen, damit diejenigen die von der Hintertür wissen, dennoch an die Inhalte einer verschlüsselten Kommunikation kommen. Beim veröffentlichen eines Algorithmus würde eine Hintertür früher oder später entdeckt werden.
Selbstverständlich ist es auch möglich (jedoch eher unwahrscheinlich), daß ein Kryptologe eine Schwäche in einem als sicher geltendenden Algorithmus entdeckt, aber nicht veröffentlicht hat, den alle seine Kollegen übersehen haben. Daher ist es durchaus denkbar, das Organisationen, die ein beträchtliches Interesse am knacken von Verschlüsselungen haben und denen zusätzlich beträchtliche Ressourcen, wie auch erfahrene Kryptologen zur Seite stehen, Schwächen in Verschlüsselungen finden, bevor diese allgemein bekannt werden. Eine Organisation auf die dies zutrifft ist etwa die NSA.
DES (Data Encryption Standard) war der erste standardisierte Algorithmus für symmetrische Verschlüsselungen. Er benutzt einen 56 Bit langen Schlüssel. DES wurde in Zusammenarbeit von IBM und NSA entwickelt. Die Beteiligung der NSA sowie das Design des Algorithmus, welches einige prinzipielle Schwächen zusammen mit der Schlüssellänge von nur 56 Bit zeigte, gab bereits von Anfang an Raum für Spekulationen, das die NSA absichtlich einen durch sie selbst knackbaren Verschlüsselungstandard etablieren wollte. DES gilt heutzutage als veraltet und mehr oder weniger knackbar. Ein mit DES verschlüsselter Datenstrom ist zwar weiterhin nicht in Echtzeit zu knacken, aber mit genügend Rechenleistung heutzutage in einem vertretbaren Zeitrahmen zu entschlüsseln. 1998 wurde erstmals eine Entschlüsselung von DES in weniger als 3 Tagen demonstriert. Dennoch wird in der Praxis auch heute noch oft ein auf DES beruhender Algorithmus namens 3DES (oder auch Triple-DES) verwendet. Bei 3DES wird die DES Verschlüsselung dreifach angewendet was auch zu einem dreifach so langen Schlüssel führt (damit aber nicht automatisch zur dreifachen Sicherheit).
AES (Advanced Encryption Standard) wurde daher zum Nachfolger von DES gewählt. AES wurde durch einen Wettbewerb von Kryptologen ermittelt. Das heute als AES bekannte Verfahren hieß vor seiner Einführung als Standard Rijndael. Ein weiterer aussichtsreicher Finalkandidat im AES Wettbewerb war auch Twofish (eine Weiterentwicklung von Blowfish). AES gilt bis heute allgemein als unknackbar (dies gilt auch für Twofish und Blowfish). AES kann wahlweise mit Schlüssellängen von 128, 192 oder 256 Bit verwendet werden.
Im knacken der Hashverfahren MD5 und SHA1 sind in den letzten Jahren größere Erfolge erzielt worden. Diese Verfahren gelten daher nicht mehr als hinreichend sicher und sollen zukünftig durch andere ersetzt werden. Zu diesem Zweck läuft derzeit (2011) ein Wettbewerb um einen Algorithmus für den neuen Standard SHA3 (SHA2 existiert, wurde aber nie standardisiert) zu ermitteln. Generell kann SHA1 derzeit noch als etwas sicherer als MD5 eingestuft werden.
Die heute üblichen asymmetrischen Verfahren, wie RSA und DSA und auch die Elliptic Curve Cryptography gelten derzeit noch als hinreichend sicher und unknackbar. Zukünftig könnte sich dies jedoch mit der Entwicklung sogenannter Quantencomputer verändern, die die zugrundeliegenden Rechenoperationen um ein vielfaches schneller ausführen könnten. Derzeit existieren jedoch noch keine funktionstüchtigen Quantencomputer.
Generell gilt für alle Sicherheitsmassnahmen: Die Sicherheit des schwächsten Punktes bestimmt die Gesamtsicherheit. Dies gilt auch für die Kryptographie und hat zur Folge, daß selbst bei Verwendung von als sicher geltenden Algorithmen, Angreifer über andere Kanäle als die Verschlüsselung selbst an ihr Ziel kommen könnten. Werden zum Beispiel Daten zwischen 2 Systemen mit sicheren Algorithmen übers Netzwerk per SSL ausgetauscht, ist es zwar praktisch aussichtslos, das ein Angreifer die per SSL übertragenen Daten abfangen kann, aber für den Angreifer verspricht zum Beispiel der Einsatz eines Trojaners auf einem der beiden beteiligten Rechnern eine viel größere Erfolgschance. Auf dem Zielrechner liegen die Daten entschlüsselt vor, so daß ein Trojaner diese einfach mitlesen kann. Statt des sinnlosen Versuchs eine nicht knackbare Verschlüsselung zu knacken, hat der Angreifer eine viel einfachere Möglichkeit gefunden, sein Ziel zu erreichen.
Verschlüsselung kann in Computersystemen an sehr unterschiedlichen Punkten benutzt werden. Um zu sehen wie eine konkrete Anwendung der Kryptographie aussehen kann, werden hier vier Anwendungsbeispiele erklärt: SSL, Emailverschlüsselung, Emailsignierung und Passwortverschlüsselung.
SSL (Secure Sockets Layer) ist eine Netzwerkverschlüsselung. Klartextdaten werden auf einem System verschlüsselt bevor diese durch die Leitung gesendet werden und auf einem anderen System wieder entschlüsselt. SSL verwendet dazu ein hybrides Verfahren, welches asymmetrische und symmetrische Kryptographie kombiniert. Symmetrische Kryptographie hat den Vorteil schnell und einfach zu sein. Wenn 2 Systeme per Netzwerk kommunizieren wollen und dabei eine symmetrische Verschlüsselung nutzen wollen, müssen jedoch beide einen gemeinsamen Schlüssel nutzen. Nun entsteht das Problem, daß jeder Schlüssel der vorher im Klartext ausgetauscht wird, auch durch einen Mitlauscher abgefangen werden kann. Dieses Problem löst die asymmetrische Kryptographie: Beim Verbindungsaufbau wird asymmetrische Kryptographie benutzt um einen Schlüssel für die symmetrische Verschlüsselung auszutauschen. Anschließend wird auf symmetrische Verschlüsselung umgeschaltet, die schneller ist und weniger Rechenleistung benötigt als asymmetrische Kryptographie. Um den anfänglichen Schlüsseltausch per asymmetrischer Kryptographie zu ermöglichen, verfügt mindestens eine von beiden Seiten (im Normallfall der Server zu dem die Verbindung aufgebaut werden soll) über ein Schlüsselpaar aus privaten und öffentlichen Schlüssel. Der Server sendet den öffentlichen Schlüssel an den Client. Dieser kann nun einen Sitzungsschlüssel für die symmetrische Verschlüsselung erzeugen und diesen mit dem öffentlichen Schlüssel verschlüsseln. Anschließend sendet er das Ergebnis an den Server. Da nur der Besitzer des zugehörigen privaten Schlüssels einen Text der mit dem öffentlichen Schlüssel verschlüsselt wurde, entschlüsseln kann, kann nur der Server den vom Client verschlüsselten Sitzungsschlüssel ermitteln. Server und Client verfügen nun über einen gemeinsamen Sitzungsschlüssel den niemand anderes kennen kann und mit dem eine symmetrische Verbindung aufgebaut werden kann. Das tatsächlich verwendete Verfahren ist noch etwas komplizierter, aber hier wird nur das Prinzip erklärt.
Bei der Emailverschlüsselung wird auf asymmetrische Kryptographie zurück gegriffen. Die Person, die verschlüsselte Emails erhalten möchte, muß vorab ein Schlüsselpaar generieren. Der öffentliche Schlüssel wird anschließend veröffentlicht. Hierfür können zum Beispiel Schlüsselserver verwendet werden, die öffentlich zugänglich sind und öffentliche Schlüssel zu Emailadressen enthalten. Ebenso ist es möglich den öffentlichen Schlüssel per unverschlüsselter Email an alle Bekannten zu versenden. Jemand der nun diesem Mailempfänger eine verschlüsselte Email zukommen lassen möchte, muß den öffentlichen Schlüssel nutzen um seine Email zu verschlüsseln. Der Mailempfänger kann dann mit seinem privaten Schlüssel die Nachricht öffnen. Da nur er in Besitz des privaten Schlüssels ist, kann niemand anderes die Nachricht entschlüsseln, dies gilt natürlich auch für den ursprünglichen Absender, der sich jedoch stattdessen eine unverschlüsselte Kopie der Nachricht aufheben kann. Möchte der Empfänger verschlüsselt Antworten, muß er den öffentlichen Schlüssel des ursprünglichen Mailschreibers verwenden.
Eine Signatur ist eine Art elektronische Unterschrift. Sie bestätigt, daß die Nachricht vom Autor tatsächlich verfaßt wurde. Signierung funktioniert auf ähnliche Weise wie Verschlüsselung mit asymmetrischen Schlüsseln. Bei der Signierung wird der Umstand ausgenutzt, daß der private Schlüssel nur dem Schlüsselersteller bekannt ist. Um eine signierte Email zu schreiben, verschlüsselt der Absender die Email mit seinem privaten Schlüssel. Da alles was mit einem Schlüssel eines Schlüsselpaars verschlüsselt wurde, nur mit dem anderen zugehörigen Schlüssel entschlüsselt werden kann, kann der Mailtext danach nur mit dem öffentlichen Schlüssel wieder entschlüsselt werden. Da aber der öffentliche Schlüssel nun mal Öffentlich ist, erscheint es sonderbar, warum etwas mit dem privaten Schlüssel verschlüsselt werden sollte. Der Sinn liegt jedoch in der Überprüfbarkeit des Besitzes des privaten Schlüssels. Abgesendet wird die Email als Datei mit 2 Versionen: Zum einen der unverschlüsselte Mailtext und zum anderen der mit dem privaten Schlüssel verschlüsselte Mailtext. Der Empfänger kann nun mit dem öffentlichen Schlüssel den verschlüsselten Mailtext entschlüsseln und diesen Text mit der unverschlüsselten Variante vergleichen. Stimmen beide überein, muß der Absender in Besitz des zugehörigen privaten Schlüssels sein, da sonst der Mailtext nicht mit dem öffentlichen Schlüssel korrekt entschlüsselt werden könnte. Da der private Schlüssel geheim ist bestätigt damit der Absender seine Identität.
Um Passwörter bei der Eingabe zu überprüfen, müssen diese abgespeichert auf einem System vorhanden sein. Da ein solcher Passwortspeicher ein primäres Ziel für Angreifer ist, muß die Passwortdatei möglichst gut geschützt werden. Neben dem restriktiven Setzen von Rechten auf die Passwortdatei, dient auch die Verschlüsselung der Passwörter in dieser Datei diesem Ziel. Für die Passwortverschlüsselung werden meist Hashalgorithmen verwendet. Da Hashalgorithemen nicht umkehrbar sind, woher weiß dann das System das Passwort um Eingaben überprüfen zu können? Die Antwort ist einfach: Es weiß sie auch gar nicht, aber wenn ein Passwort überprüft werden soll, wird das selbe Hashverfahren auch auf das zu überprüfende Passwort angewendet. Ist der resultierende Hash des Passwortes identisch mit dem abgespeicherten, dann ist das eingebene Passwort korrekt.
Trotz der Verschlüsselung von Passwortdateien, sollten diese niemals öffentlich zugänglich sein, da auch verschlüsselte Passwörter über sogenannte Wörterbuchangriffe ermittelt werden können. Zwar stellt die Passwortverschlüsselung eine zusätzliche Hürde zum knacken der Passwörter dar, aber das Haupthindernis für einen Angreifer ist es immer an die Datei heran zu kommen. Hat der Angreifer die Datei vorliegen, kann er vorrausberechnete Hashes von oft benutzten Passwörtern verwenden um diese schneller zu ermitteln. Um dies zu verhindern werden oft sogenannte salted Hashes eingesetzt. Ein gesalzener Hash enthält eine zusätzliche zufällige Komponente (das Salz) und verhindert damit die Verwendung vorrausberechneter Hashes. Die zufällige Komponente wird dabei ebenfalls in der Passwortdatei gespeichert. Der abgespeicherte Passworthash ist dann der Hashwert aus der Kombination des zufälligen Wertes und dem eigentlichen Passwort. Bei der Überprüfung eines Passwortes wird der Zufallswert aus der Passwortdatei gelesen und wiederrum mit dem Passwort kombiniert. Der daraus gewonnene Hash kann wieder mit dem gespeicherten Hash verglichen werden. Wichtig ist das der Zufallswert für jeden Benutzer ein anderer ist. Dadurch führt das selbe Passwort bei unterschiedlichen Benutzern zu einem anderen Hashwert. Ein Angreifer kann keine vorrausberechneten Hashes verwenden, sondern muß für jeden Benutzer einzeln, alle Möglichkeiten durchgehen.
Da die üblichen Hashverfahren MD5 und SHA1 als nicht mehr sicher genug gelten, finden inzwischen auf manchen Systemen auch symmetrische Verschlüsselungsverfahren wie etwa Blowfish Verwendung als Passwortverschlüsselung. Dabei wird das Passowrt nicht als Schlüssel, sondern als zu verschlüsselnder Klartext benutzt. Der Schlüssel ist dann üblicherweise ein Satz, der immer gleich ist und auch allgemein bekannt ist. Auf diese Weise entsteht aus einem symmetrischen Verfahren ein Hashverfahren.
Bei der Übertragung von Passwörtern über das Netzwerk können ebenfalls Hashverfahren angewendet werden um das Passwort nicht im Klartext zu übertragen. Für diesen Zweck gibt es sogenannte Challenge/Response Verfahren. Bei einem Challenge/Response Verfahren (zum Beispiel CRAM-MD5) sendet der Server eine Zufallszahl (die sogenannte Challenge) an den Client der sich authentifizieren möchte. Der Client kombiniert die Zufallszahl mit dem Passwort und ermittelt daraus einen Hashwert. Der Hashwert wird an den Server übertragen. Der Server hat seinerseits ebenfalls den Hashwert aus der Zufallszahl und dem ihm bekannten Passwort ermittelt. Stimmen der vom Server ermittelte Wert, mit dem vom Client übermittelten Wert überein, hat sich der Client erfolgreich authentifiziert. Auf diese Weise muß das Passwort niemals im Klartext durch die Leitung gesendet werden. Außerdem ist es auch nicht möglich den gleichen Hashwert noch einmal zu senden, da bei der nächsten Clientauthentifizierung die Zufallszahl wieder eine andere ist. Nachteilig bei diesem Verfahren ist der Umstand , daß dem Server das Passwort des Clients im Klartext bekannt sein muß, was vorraussetzt, daß das Passwort auch im Klartext auf dem Server gespeichert wurde.
Netzwerkverschlüsselungen wie SSL müssen stets 2 Probleme lösen: Die eigentliche Transportverschlüsselung und die Sicherstellung, daß mit dem richtigen Kommunikationspartner kommuniziert wird (Authentifizierung). Warum ist das so?
Der Sinn einer Netzwerk-Verschlüsselung besteht darin, die übertragenen Daten gegen fremde Blicke zu schützen. Wenn ein potentieller Angreifer die Daten im Netzwerk nicht abgreifen kann, kann er jedoch versuchen, die Daten zu sich kommen zu lassen. Er könnte etwa versuchen sich selbst als den Zielserver auszugeben. Der Client würde in diesem Fall die Verbindung zum Angreifer, statt zum eigentlichen Ziel aufbauen. Da SSL am Zielpunkt die Daten entschlüsselt, hilft in diesem Fall die Verschlüsselung nichts. Der Angreifer kann die Daten im Klartext lesen. Um keinen Verdacht zu erwecken, kann er zusätzlich die Daten auch auf den eigentlichen Zielserver weiterleiten. Dieses Szenario wird als Man-in-the-Middle Angriff bezeichnet, da der Angreifer wie ein Proxy zwischen dem Client und dem Server sitzt und alle Daten im Klartext trotz Verschlüsselung mitlesen kann.
Um dies zu verhindern, wird die asymmetrische Kryptographie während eines SSL Verbindungsaufbaus auch benutzt, um die Identität des Servers zu überprüfen. Der vom Server verwendete öffentliche Schlüssel dient dabei als Identitätsnachweis. Der öffentliche Schlüssel des Servers wird dazu von einem vertrauenswürdigen Dritten der Certificate Authority, kurz CA, signiert. Die CA besitzt zu diesem Zweck selbst ein Schlüsselpaar. Der öffentliche Schlüssel der CA wird allgemein bekannt gegeben, so das ihn jeder nutzen kann. Möchte ein Serverbetreiber seinen öffentlichen Schlüssel signieren, wendet er sich an die CA. Die CA überprüft seine Identität. Diese Überprüfung kann unterschiedlich ausfallen, ist aber ein wesentlicher Punkt der die Sicherheit des Systems garantiert. Hat sich die CA davon überzeugt, daß der öffentliche Schlüssel des Servers wirklich zur Domain gehört, für die das Zertifikat ausgestellt werden soll, signiert die CA den öffentlichen Schlüssel des Servers mit ihrem eigenen privaten Schlüssel. Dadurch wird aus dem öffentlichen Schlüssel des Servers ein sogenanntes Zertifikat. Ein Client kann das Zertifikat überprüfen indem er die Signierung mit dem öffentlichen Schlüssel der CA überprüft. Ist die Signierung korrekt, sagt dies aus, daß die CA die Identität des Servers bestätigt.
Damit ein Client dies durchführen kann muß er die öffentlichen Schlüssel aller CAs kennen. In Webbrowsern etwa befinden sich diese im Zertifikatsspeicher. Unter Firefox ist dieser über die Einstellungen des Firefox unter Erweitert -> Reiter Verschlüsselung -> Button Zertifikate anzeigen -> Reiter Zertifizierungsstellen zu finden. Dies bedeutet auch, das der Browserhersteller für mich bereits die Entscheidung getroffen hat, welchen CAs ich vertraue und welchen nicht.
Dieses komplette System wird als Public Key Infrastructure, kurz PKI bezeichnet.
Der schwächste Teil einer PKI Lösung ist immer die CA. Bei den CAs handelt es sich meistens um Wirtschaftsunternehmen, die Zertifikate gegen Geld ausstellen. Diese wollen es ihren Kunden natürlich möglichst leicht machen, sich zu identifizieren. Wie genau eine CA die Identität eines Kunden prüft ist jedoch von großer Wichtigkeit für das Vertrauen in das Zertifikat. Der private Schlüssel der CA ist ein Schlüssel der besonders gut geschützt werden muß. Sollte ein Unbefugter an diesen Schlüssel heran kommen, könnte er beliebige Zertifikate ausstellen, die von jedem Client als gültige und vertrauenswürdige Zertifikate akzeptiert werden würden.
Natürlich ist es auch möglich für eine interne Struktur innerhalb eines Intranets eine eigene CA zu betreiben. Die Zertifikate dieser CA würden zwar von externen Clients nicht erkannt werden, aber in einem Intranet spielt dies keine Rolle. Der öffentliche Schlüssel der internen CA könnte an allen internen Clients verteilt werden, wodurch diese, den Schlüssel als vertrauenswürdig ansehen.
Meldet ein Clientprogramm ein unbekanntes Zertifikat, bzw. eine unbekannte Zertifizierungsstelle, kann dies heißen, daß entweder die ausstellende Zertifizierungsstelle dem Client nicht bekannt ist, oder das Zertifikat eventuell vom Serverbetreiber selbst signiert wurde. Die Verbindung ist trotzdem verschlüsselt, die Warnmeldung sagt nur aus, daß die Identität des Servers nicht zweifelsfrei ermittelt werden konnte. Weiß man daß das Zertifikat korrekt ist, kann das Serverzertifikat dem Zertifikatsspeicher des Clients hinzu gefügt werden, wodurch alle zukünftigen Verbindungen auf dieses Zertifikat hin überprüft werden und zusätzlich die Warnmeldung entfällt.
Eine Alternative zu einer PKI stellt das Web of Trust dar. Das Web of Trust wird etwa von den Mailverschlüsselungen PGP und GnuPG verwendet. Bei einem Web of Trust, treffen sich Kommunikationspartner gelegentlich persönlich. Findet ein persönliches Treffen statt, dann signieren sich die Kommunikationspartner gegenseitig ihre öffentlichen Schlüssel. Hat nun zum Beispiel Alice den Schlüssel von Bob signiert, und Conrad hat den Schlüssel von Alice signiert, kann Conrad aufgrund des Vertrauens in den Schlüssel von Alice auch Bobs Schlüssel vertrauen. Auf diese Weise entsteht mit der Zeit ein Web of Trust, wobei das Vertrauen mit der Entfernung des Kommunikationspartners im Web of Trust geringer wird.