Die Grundlagen der asymmetrischen Verschlüsselung

Aus LinuxUser 04/2009

Die Grundlagen der asymmetrischen Verschlüsselung

© Gernot Krautberger, Fotolia

Geheimniskrämerei

Was steckt eigentlich dahinter, wenn der Browser eine Zertifikatwarnung anzeigt, und was bedeutet es für die Sicherheit? Nur wer die Prinzipien der asymmetrischen Verschlüsselung versteht, kann das richtig einschätzen.

Das Internet ist systembedingt unsicher: Per Mail oder mit einem Formular im Browser verschickte Daten durchlaufen bis zum Ziel gewöhnlich etliche Server – welche, das kann sich der Sender nicht aussuchen. Der Befehl traceroute macht die Zwischenstationen auf dem Übertragungsweg sichtbar (Abbildung 1). Entscheidend für die Sicherheit: Jeder, der Zugriff auf einen dieser Rechner hat, kann unverschlüsselt verschickte Daten mitlesen oder manipulieren.

Abbildung 1: In dreizehn Sprüngen zu Google: Beim Öffnen einer Webseite im Browser durchlaufen die Daten stets mehrere Server. Welche, das kann der Seitenbesucher nicht beeinflussen.

Abbildung 1: In dreizehn Sprüngen zu Google: Beim Öffnen einer Webseite im Browser durchlaufen die Daten stets mehrere Server. Welche, das kann der Seitenbesucher nicht beeinflussen.

Nun scheint es vielleicht nicht allzu wahrscheinlich, dass Ihre Daten ausgerechnet den Rechner eines “Bösewichts” durchlaufen, wenn Sie Ihrem Freund eine E-Mail schicken oder in einem Onlineshop Waren bestellen. Konkrete Bedrohungen lauern im Internet aber genug: Betrüger versuchen Kreditkartendaten abzuschöpfen; in welchem Umfang staatliche Dienste den Mailverkehr abhören und was sie mit den gewonnenen Informationen anstellen, weiß niemand so genau. Vielleicht möchten Sie auch einfach vermeiden, dass Ihre privaten Mails wie unverschlossene Briefe durch das Netz wandern.

Sicherheit gibt es im Internet daher nur, wenn Sie die Daten verschlüsselt übertragen. Programme wie Firefox oder GnuPG [1] sorgen dafür, dass dies ohne tiefgehende Fachkenntnisse gelingt. Wer bei diesem sicherheitsrelevanten Themen keine Fehler machen möchte, sollte trotz grafischer Konfigurationsoberflächen zumindest Grundlagenwissen mitbringen.

Abbildung 2: Bei Online-Banking geht es nicht ohne: Firefox färbt die Adressleiste grün, wenn die Verschlüsselung technisch einwandfrei verläuft.

Abbildung 2: Bei Online-Banking geht es nicht ohne: Firefox färbt die Adressleiste grün, wenn die Verschlüsselung technisch einwandfrei verläuft.

Detektiv spielen

Wahrscheinlich haben Sie selbst schon einmal ein Verschlüsselungsverfahren entworfen – die meisten Kinder tun das. Bei solchen Codes handelt es sich um einfache Ersetzungsschemata für Buchstaben: A wird zu E, X zu U und so weiter. So entsteht unlesbares Kauderwelsch, ein verschlüsselter Text.

Es gibt 4!26 (4×1026) Möglichkeiten, die Buchstaben des Alphabets zu verwürfeln. Einer Analyse mit dem Computer hält eine solche so genannte monoalphabetische Ersetzung dennoch nicht stand: Kennt der Angreifer die Sprache, in der die Geheimbotschaft verfasst wurde, dann ergeben sich bereits aus der Häufigkeitsanalyse der Buchstaben wichtige Hinweise. Kommt im Code zum Beispiel der Buchstabe Y am häufigsten vor, so repräsentiert er bei deutschen Texten mit an Sicherheit grenzender Wahrscheinlichkeit das E.

Für weitere Klarheit sorgt eine so genannte Mustersuche, bei der der Codeknacker im Text vermutete Wörter über wechselnde Stellen im Code legt und die sich daraus ergebende Buchstabenersetzung für den restlichen Text fortschreibt. Fördert dies sinnvolle Textfragmente zu Tage, so ist ein Teil des Codes gefunden.

Vielgestaltig

Im zweiten Weltkrieg benutzten die Deutschen die mechanische Verschlüsselungsmaschine Enigma [2], die die monoalphabetische Codierung durch eine polyalphabetische ersetzte. Dies bedeutet, das der Übersetzungsschlüssel mit jedem Buchstaben wechselt. Die Enigma schaltete dazu drei, später vier drehbare Metallzylinder mit außen liegenden Kontaktplättchen hintereinander, die nach einem geheimen Schema verdrahtet waren. Die Verdrahtung der Kontakte entsprach für sich genommen dem Geheimcode zehnjähriger Detektive, der Buchstaben nach einem festen Schema durch andere ersetzt. Ein Rotieren der Zylinder veränderte den Übersetzungsschlüssel jedoch ständig, was statistische Verteilungen und Textmuster verdeckte.

Abbildung 3: Wegen der hintereinandergeschalteten rotierendenen Walzen wechselte das Schema der Verschlüsselungsmaschine Enigma aus dem 2. Weltkrieg mit jedem Buchstaben.

Abbildung 3: Wegen der hintereinandergeschalteten rotierendenen Walzen wechselte das Schema der Verschlüsselungsmaschine Enigma aus dem 2. Weltkrieg mit jedem Buchstaben.

Dennoch gelang es dem polnischen Kryptoanalytiker Marian Rejewski bereits 1932 den Enigma-Code zu knacken. Rejewski kannte von vor dem Krieg frei erhältlichen kommerziellen Varianten der Verschlüsselungsmaschine das Prinzip der rotierenden Walzen: Sie drehten sich wie die Ziffernrädchen eines Wasserzählers mit jedem Buchstaben um eine Einheit weiter. Das Schema des Wechsels blieb bei Enigma also leicht durchschaubar. Wer es bei der Mustersuche im codierten Text mit einrechnet, wird genauso fündig wie bei der kindlichen Geheimschrift.

Aus den Erfahrung mit der monoalphabetischen Verschlüsselung und der geknackten Enigma lassen sich zwei Lehren ziehen.

  • Schlüssel fest zu verdrahten, wie in den Kontaktwalzen der Enigma, ist eine schlechte Idee. Sie müssen vielmehr klar vom Verfahren getrennt bleiben. Das Verfahren selbst lässt sich nämlich, sobald es vielfach genutzt wird, auf Dauer nicht verlässlich geheimhalten. Der Schlüssel sollte sich also im Fall einer Kompromittierung oder – noch besser – regelmäßig einfach austauschen lassen.
  • Die Designer eines Verschlüsselungsverfahrens erweisen sich oft als schlechte Ansprechpartner, wenn es darum geht, dessen Sicherheit zu beurteilen. Hätten die Deutschen die Verfahren der Alliierten beim Knacken des Enigma-Codes gekannt, so wäre es nicht besonders schwer gewesen, die Lücken zu schließen.

Flucht nach vorn

Ein schlüsselbasiertes Krytografieverfahren darf nicht nur öffentlich bekannt sein, es sollte dies sogar: Man kann davon ausgehen, dass sich viele Angreifer daran versuchen, ein verbreitetes Verschlüsselungsverfahren auszuhebeln und dabei auf eine Menge Ideen kommen, die jeden erdenklichen Schwachpunkt ausnutzen. Die Entwickler einer sicheren Verschlüsselung müssen daher möglichst alle denkbaren Angriffsszenarien antizipieren.

Handelt es sich bei den Entwicklern um eine kleine Truppe, die hinter verschlossenen Firmentüren arbeiten, stehen ihre Chancen, alle Codeknacker der Welt zu überlisten, schlecht. Bei der Kryptografie liegen die Vorteile von Open-Source-Software auf der Hand: Viele Entwickler, viele darauf spezialisierte Fachleute durchforsten quelloffene Sicherheitssoftware auf Lücken und Schwächen. Die Chancen, dass sie böswilligen Codeknackern zuvorkommen und sich die Lücken per Software-Update beseitigen lassen, ehe sie Schaden verursachen, stehen besser als bei proprietären Techniken.

Paarweise

Kodierungsverfahren, die auf Schlüsseln statt auf Geheimniskrämerei beim Verfahren basieren, gibt es in zwei Spielarten: der symmetrischen und asymmetrischen Verschlüsselung. Mit asymmetrischer Verschlüsselung arbeitet zum Beispiel die EC-Karte. Ist die PIN, nach der Sie der Geldautomat fragt, auf der Karte gespeichert? Keineswegs, das wäre ein großes Sicherheitsrisiko. Um die Richtigkeit der eingegebenen Geheimzahl zu prüfen, kommt ein so genannter Hash der PIN zum Einsatz.

Dieser Hash lässt sich nach einem festgelegten Rechenschema aus der Geheimzahl erzeugen. Den umkehrten Weg, das Errechnen der PIN aus dem Hash, schließt das zugrundeliegende mathematische Verfahren aber aus. Als Basis dazu dienen Rechenoperationen, die in eine Richtung nur geringen Aufwand erfordern, in die umgekehrte jedoch hohen. Ein typisches Beispiel ist die Multiplikation von Primzahlen und ihre Umkehrung, die Primfaktorzerlegung.

Das Produkt aus den Primzahlen 3, 11, 13, 19, 31, 47, 53, 67, 79, 97, 107, 131, 157 und 173 errechnet ein moderner Computer in Mikrosekunden. Das Zerlegen des Ergebnisses 123032761410459704284767 in die Primfaktoren dauert jedoch auch bei Nutzung der besten bekannten Rechenverfahren viel länger. Wählt man die Primfaktoren groß genug, so lassen sie sich auch mit den schnellsten Großrechnern nicht mehr in erträglicher Zeit aus dem Ergebnis des Produkts zurückgewinnen. Das Produkt selbst aber kann jeder PC errechnen. Auf dieser mathematischen Asymmetrie baut das verbreitete asymmetrische Verschlüsselungsverfahren RSA [3] auf.

Nicht die ganze Wahrheit

Sichere Kryptografie trennt also zwischen dem öffentlich bekannten Verschlüsselungsverfahren und dem geheimen Schlüssel. Es bleibt allerdings noch die Frage, wie der Empfänger einer verschlüsselten Nachricht in den Besitz des Schlüssels kommt.

Eine Möglichkeit wäre, ihn auf einem alternativen sicheren Übertragungsweg zu übermitteln, etwa per Post. Das ist jedoch mühsam und dauert lang. Asymmetrische Verschlüsselung überträgt das Geheimnis daher gar nicht – oder besser gesagt nicht vollständig. Es gibt nämlich nicht nur einen Schlüssel, sondern ein Paar aus öffentlichem und privatem Schlüssel.

Abbildung 4: Bei der asymmetrischen Verschlüsselung gibt es zwei Keys: Den geheimen, den nur der Empfänger kennt, entschlüsselt Nachrichten. Der öffentlich bekannte verschlüsselt Nachrichten, kann sie aber nicht entschlüsseln.

Abbildung 4: Bei der asymmetrischen Verschlüsselung gibt es zwei Keys: Den geheimen, den nur der Empfänger kennt, entschlüsselt Nachrichten. Der öffentlich bekannte verschlüsselt Nachrichten, kann sie aber nicht entschlüsseln.

Wie schon der Name sagt, ist der öffentlicher Schlüssel kein Geheimnis: GnuPG [3] veröffentlicht ihn auf Wunsch sogar auf Key-Servern im Internet, so dass alle, die das möchten, ihn dort abrufen können. Der private Schlüssel darf dagegen auf keinen Fall Dritten in die Hände fallen, sonst ist die Chiffrierung mit dem zugehörigen öffentlichen Schlüssel nicht mehr sicher.

Der Schlüssel zum Verständnis des Public/Private-Key-Verfahren liegt im Schlagwort Asymmetrie: Möchten Sie jemandem eine kodierte Nachricht senden, so brauchen Sie zunächst seinen öffentlichen Schlüssel. Damit chiffrieren Sie den Text. Entschlüsseln lässt sich die Nachricht mit dem öffentlichen Key nicht mehr. Dazu braucht man vielmehr den privaten Schlüssel. Den hat nur einer, der Empfänger selbst – also genau die Person, die Ihre Nachricht lesen soll. Alle anderen, einschließlich Sie selbst, sehen nur noch Buchstabensalat.

Hinter der Public/Private-Key-Architektur verbirgt sich eine ähnliche Mathematik wie bei der EC-Karte, bei der sich ein eindeutiger Hash aus der PIN errechnen lässt, aber nicht umgekehrt die nur Ihnen bekannte PIN aus dem Hash. Für alle, die sich vor etwas Mathematik nicht fürchten, erläutert ein Online-Artikel [4] die Details.

Eine Frage der Identität

Haben Sie den privaten Schlüssel ihres Kommunikationspartners, kann also bei der verschlüsselten Datenübertragung auf den ersten Blick nichts schiefgehen: Fängt jemand ihre verschlüsselten Daten auf, bleibt ihm deren tieferer Sinn verborgen.

Doch Vorsicht: Im Internet können Angreifer übertragene Daten nicht nur belauschen, sondern auch manipulieren. Das ermöglicht folgendes Szenario: Sie schicken die Bitte, den öffentlichen Schlüssel zu senden, an einen Kommunikationspartner. Ein Angreifer schnappt das auf und fängt anschließend die Antwort mit dem privaten Schlüssel ab. In der Antwort, die er statt des Originals an Sie weiterleitet, ersetzt er den angefragten Schlüssel aber durch seinen eigenen.

Nun ergibt sich die Dreieckssituation aus Abbildung 5: Sie haben als Antwort auf ihre Anfrage einen öffentlichen Schlüssel erhalten (schwarz-grün in Abbildung 5), von dem sie guten Glaubens annehmen, es sei der gewünschte. Der Angreifer hat ihnen aber seinen eigenen Schlüssel untergeschoben. Zusätzlich ist er auch im Besitz des öffentlichen Schlüssels ihres Kommunikationsparters (grün).

Abbildung 5: Bei einem Man-in-the-Middle-Angriff gibt es neben dem echten Schlüsselpaar (rot und grün) ein gefälschtes Paar (schwarz-rot und schwarz-grün), mit dem der Angreifer die Daten entschlüsselt und, um sich zu tarnen, sofort wieder verschlüsselt.

Abbildung 5: Bei einem Man-in-the-Middle-Angriff gibt es neben dem echten Schlüsselpaar (rot und grün) ein gefälschtes Paar (schwarz-rot und schwarz-grün), mit dem der Angreifer die Daten entschlüsselt und, um sich zu tarnen, sofort wieder verschlüsselt.

Das Belauschen der Kommunikation zwischen Ihnen (Sender) und dem Empfänger durch den zwischengeschalteten Angreifer funktioniert so: Sie senden verschlüsselte Daten. Der Angreifer entschlüsselt die Daten nun mit seinem eigenen geheimen Schlüssel (schwarz-rot), da sie ja mit seinem privaten Schlüssel chiffriert sind. Damit der Kommunikationspartner nichts von dem Betrug bemerkt, verschlüsselt der Angreifer die abgefangenen Daten nun mit dem Key ihres Partners (grün) und übermittelt sie an diesen.

Dieses Zwischenschalten in der chiffrierten Kommunikation heißt Man-in-the-Middle-Angriff. Solche Attacken lassen sich nur verhindern, indem Sie sicherstellen, dass Sie den richtigen, nicht einen untergeschobenen Key in Händen haben.

Zertifizierte Sicherheit

Hier kommt die so genannte Schlüsselsignierung ins Spiel. Dazu benötigen Sie die Dienste vertrauenswürdiger Dritter, so genannter Certification-Authorities (CAs), die die Identität von Schlüssel und Versender garantieren. Jeder Browser bringt eine Liste solcher Stellen eingebaut mit, die als vertrauenswürdig gelten (Abbildung 6).

Abbildung 6: Der Browser bringt die Schlüssel vertrauenswürdiger Zertifizierungsstellen fest eingebaut mit, so dass eine Übertragung über das unsichere Internet entfällt.

Abbildung 6: Der Browser bringt die Schlüssel vertrauenswürdiger Zertifizierungsstellen fest eingebaut mit, so dass eine Übertragung über das unsichere Internet entfällt.

Der Betreiber eines Webservers, der Webseiten verschlüsselt via HTTPS anbieten möchte, reicht dabei seine Daten, im Wesentlichen seinen privaten Schlüssel zusammen mit der Domain seines Webservers und seinem Firmennamen, schriftlich bei einer Zertifizierungsstelle ein. Diese verschlüsselt das eingereichte Gesamtpaket mit ihrem eigenen öffentlichen Schlüssel. So entsteht ein unterschriebenes Zertifikat, das der Administrator auf seinem Webserver ablegt und das der Webserver bei der Übertragung der verschlüsselten Seiten mitschickt.

Müsste der Browser den Schlüssel des Zertifikatsausstellers über das Internet abfragen, so wäre bei der Sicherheit gegenüber Man-in-the-Middle-Attacken nichts gewonnen. Doch der Browser bringt die Schlüssel der Zertifizierungsstellen, denen er vertraut, ja bereits fest eingebaut mit. Der Angriffspunkt, der das unbemerkte Einklinken in die Kommunikation erlaubt, entfällt damit.

Sicher bleibt die verschlüsselte Kommunikation über HTTPS allerdings nur, wenn der Anwender die Warnungen des Browsers nicht ignoriert (Abbildung 7). Ältere Browser reagierten meist nur einem einfachen Popup, wenn das Zertifikat einer Website von einer dem Browser unbekannten Zertifizierungsstelle unterschrieben war, nicht zur Domain passte oder sonstwie fehlerhaft war. Firefox 3 mahnt da etwas nachdrücklicher: Er zeigt die Warnung nicht in einem Dialogfeld an, sondern direkt im Browserfenster, im Zentrum der Aufmerksamkeit des Benutzers. Statt eines Klicks sind drei nötig, bis der Anwender die problematische Webseite zu sehen bekommt.

Abbildung 7: Zeigt der Browser bei HTTPS-Transaktionen einen Zertifikatfehler an, dann ist die Abhörsicherheit trotz Verschlüsselung nicht mehr garantiert.

Abbildung 7: Zeigt der Browser bei HTTPS-Transaktionen einen Zertifikatfehler an, dann ist die Abhörsicherheit trotz Verschlüsselung nicht mehr garantiert.

Ein ungültiges Zertifikat deutet nicht notwendigerweise darauf hin, dass Betrügereien oder Abhören im Spiel sind. Oft liegt es nur daran, dass ein (stets zeitlich begrenzt gültiges) Zertifikat abgelaufen ist, weil der Administrator es nicht rechtzeitig erneuert hat. Der Schutz der Daten, ohne den es bei sicherheitskritischen Transaktionen wie Online-Banking nicht geht, ist dann allerdings nicht mehr gewährleistet.

Die Mischung macht’s

Aus der Perspektive der Sicherheit stellt asymmetrische Verschlüsselung im Zusammenspiel mit vertrauenswürdigen Zertifizierungsstellen das ideale Verfahren für die sichere Datenübertragung im Internet dar. Insbesondere gibt es hier eine Lösung für den kniffeligsten Part, den Schlüsseltausch über unsichere Kanäle. Das Geheimnis, der private Schlüssel, ist niemals dem unsicheren Internet ausgesetzt.

Ein Manko haftet asymmetrischer Verschlüsselung jedoch an: Sie verbraucht viel Rechenleistung. Symmetrische Verschlüsselung begnügt sich mit wesentlich weniger CPU-Power. Jedoch bereitet symmetrische Chiffrierung im Internet bezüglich der Sicherheit Probleme: Hier gibt es nur einen Schlüssel, der Nachrichten ver- und entschlüsselt. Hat den ein Lauscher einmal in die Hände bekommen, so kann er in beide Richtungen kommunizieren, ohne dass der Betrug auffällt.

Surfen Sie über HTTPS im Internet, surfen daher ein Hybridverfahren zum Einsatz. Dabei wird lediglich der Schlüssel asymmetrisch chiffriert übertragen. Für die eigentliche Datenübertragung steht dann sowohl Sender als auch Empfänger ein gemeinsamer, sicher übertragener Schlüssel zur Verfügung. Die rechenintensive asymmetrische Verschlüsselung kommt dabei nur in einer kurzen Initialisierungsphase zum Einsatz, nicht beim eigentlichen Datentransfer.

Glossar

Hash

Eindeutige Prüfsumme, die über ein Streuwertfunktion aus einer Eingabe beliebiger Länge erzeugt wird.

Infos

[1] GnuPG: http://www.gnupg.org

[2] Enigma-Verschlüsselungsmaschine: http://de.wikipedia.org/wiki/Enigma_(Maschine)

[3] Mails verschlüsseln mit GnuPG: René Gäbler, “Schlüsselerlebnis”, LinuxUser 11/2007, S. 42, https://www.linux-community.de/artikel/14307/

[4] RSA-Verschlüsselung: http://www.regenechsen.de/phpwcms/index.php?krypto_asym_rsa

LinuxUser 04/2009 KAUFEN
EINZELNE AUSGABE
ABONNEMENTS
TABLET & SMARTPHONE APPS
E-Mail Benachrichtigung
Benachrichtige mich zu:

Hinweis: Dieser Artikel ist älter als ein Jahr, enthaltene Informationen sind möglicherweise veraltet.

1 Kommentar
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
LinuxNoob
17 Jahre her

In dem Artikel heisst es:

“Der Betreiber eines Webservers, der Webseiten verschlüsselt via HTTPS anbieten möchte, reicht dabei seine Daten, im Wesentlichen seinen privaten Schlüssel zusammen mit der Domain seines Webservers und seinem Firmennamen, schriftlich bei einer Zertifizierungsstelle ein.”

es müsste aber der öffentliche Schlüssel sein, den der Betreiber bei der CA einreicht, oder?

Nach oben