Very ParaNoid (2) - Mythos Sicherheit

von Jörg Frühbrodt, IT-Consultant

erschienen in LinuxEnterprise 2/2002, Software & Support Verlag, Frankfurt a.M.

Dieser zweite Teil beschreibt die wichtigsten in VPNs eingesetzten Verschlüsselungs- und Authentisierungs-Technologien. Auch die kritische Beurteilung ihrer Vor- und Nachteile kommt nicht zu kurz.

Die Kryptografie kennt zwei Verschlüsselungsverfahren: symmetrische und asymmetrische. Im symmetrischen Verfahren wird für die Ver- und Entschlüsselung nur ein einziger Schlüssel verwendet. Für seinen Austausch mit dem Kommunikationspartner müssen besondere Sicherheitsvorkehrungen getroffen werden, da er Dritten keinesfalls bekannt werden darf. Bekannte symmetrische Verschlüsselungsverfahren sind DES, 3DES, IDEA, Blowfish und AES. Ohne besondere Vorkehrungen ist das symmetrische Verfahren für VPNs ungeeignet. Der über das öffentliche Netz übertragene geheime Schlüssel könnte ohne großen Aufwand abgehört werden.

Dieses Problem gibt es bei der asymmetrischen Verschlüsselung durch Diffie-Hellman und RSA nicht. Sie arbeitet mit einem Schlüsselpaar, bei dem der erste, öffentliche Schlüssel den Kommunikationspartnern auf beliebige Weise zugänglich gemacht werden kann. Er dient ausschließlich der Verschlüsselung, während der zweite, private Schlüssel nur entschlüsselt. Er muss in jedem Fall geheim bleiben. Die bis zu 2048 Bit langen Schlüssel verlangen sehr viel Rechenleistung, weshalb das Verfahren für VPNs nur teilweise geeignet ist. Nach der asymmetrischen Methode oder Public-Key-Verfahren arbeitet die bekannte Verschlüsselungssoftware Pretty Good Privacy (PGP) und ihre Open Source-Variante GNU Privacy Guard (GnuPG).

Tatsächlich werden symmetrische und asymmetrische Verschlüsselung in der VPN-Praxis kombiniert. Ein geheimer, symmetrischer Schlüssel wird mit einem öffentlichen, asymmetrischen Schlüssel verschlüsselt an den Empfänger geschickt. Dieser entschlüsselt seinerseits mit dem öffentlichen Schlüssel, um den geheimen Schlüssel zurück zu erhalten. Die Kommunikationspartner besitzen nun beide den gleichen symmetrischen Schlüssel für die sichere Kommunikation. Wird der geheime Schlüssel softwaregesteuert im Minutenabstand neu berechnet und ausgetauscht, kann die Abhörsicherheit weiter erhöht werden.

Beim asymmetrischen Verfahren muss man sich davon überzeugen, dass der öffentliche Schlüssel tatsächlich dem Empfänger gehört. Erleichtert wird dies durch die Fähigkeit der asymmetrischen Verfahren, Daten digital zu signieren. Die mit Hilfe des privaten Schlüssels erzeugte digitale Signatur garantiert die Integrität der Daten und erleichtert die Identifizierung des Absenders. Sie wird vom Empfänger mit dem öffentlichen Schlüssel überprüft. Auch hier muss wieder sichergestellt werden, dass die Signatur tatsächlich dem Absender gehört.

Ebenfalls für die Authentifizierung finden Hash-Algorithmen wie SHA und MD5 Anwendung. Sie erzeugen aus beliebigen Daten eine Prüfsumme mit einer definierten Länge. Aus der Prüfsumme lassen sich die ursprünglichen Daten nicht mehr berechnen. Hash-Funktionen werden deshalb als One-Way- oder Falltüralgorithmen bezeichnet. Jede noch so kleine Veränderung der Originaldaten hätte auch eine Veränderung der Prüfsumme zur Folge und würde vom Empfänger entdeckt. Wird die Prüfsumme zusätzlich signiert, kann nicht nur die Integrität der Daten, sondern zusätzlich ihr Absender nachvollziehbar überprüft werden. SHA ist der Vorzug zu geben, weil MD5 seit einiger Zeit als nicht mehr sicher gilt.

Standards

Ein Industriestandard für die Verschlüsselung garantiert die Kompatibililät von Hard- und Software. Da allein schon seine Durchsetzung einige Jahre dauern kann, muss er technologisch in jeder Hinsicht auf dem aktuellsten Stand sein. Davon kann zumindest bei DES (Data Encryption Standard) nicht mehr die Rede sein. Er wurde in den 70er Jahren nach einer Ausschreibung durch das amerikanische National Bureau of Standards and Technology (NIST) von einer IBM-Forschungsgruppe entwickelt. Für die Bewertung von DES zog das NIST den Geheimdienst National Security Agency (NSA) hinzu, der Änderungen an wesentlichen Teilen des Algorithmus durchsetzte. So wurde die Schlüssellänge von ursprünglich 128 Bit auf nur 56 Bit herabgesetzt und Tabellen für die Schlüsselberechnung den Wünschen der Schlapphüte angepasst. Zu Recht werden deshalb noch immer Hintertüren in DES vermutet. Einen Beweis dafür gibt es allerdings bis heute nicht. Der eigentliche Schwachpunkt bei DES liegt in der mit 56 Bit sehr kurzen Schlüssellänge. Mit der Brute-Force-Angriffsmethode, die auf dem simplen Ausprobieren aller möglichen Schlüsselkombinationen beruht, knackte die Electronic Frontier Foundation (EFF) bereits 1998 den DES-Algorithmus[1]. In VPNs sollte DES deshalb nicht mehr eingesetzt werden.

Als Verlegenheitslösung wurde 3DES entwickelt, der mit drei DES-Verschlüsselungsdurchgängen und zwei verschiedenen Schlüsseln arbeitet. Mit Brute-Force kann 3DES bei einer effektiven Schlüssellänge von 112 Bit derzeit nicht effektiv angegriffen werden. Ein möglicher Schwachpunkt ist die so genannte Blocklänge in 3DES, die mit nur 64 Bit zum zukünftigen Sicherheitsrisiko werden könnte. Hinzu kommt die extreme Langsamkeit des Algorithmus, die seinen praktischen Nutzen sehr einschränkt.

Diese Schwächen haben zur Entwicklung des AES (Advanced Encryption Standard) geführt. Im Oktober 2000 entschied sich das amerikanische NIST überraschend für den belgischen Rijndael-Algorithmus. Um möglichen Gerüchten über Hintertüren für die NSA frühzeitig vorzubeugen, ist der gesamte Sourcecode jedermann frei zugänglich[2]. Er umfasst erstaunlicherweise nur ca. 500 Zeilen C-Quellcode. Dies ist keineswegs ein Indiz für sicherheitstechnische Schwächen. AES/Rijndaels Schlüssel sind zwischen 128 und 256 Bit, die Blöcke 128 Bit lang. Trotz seiner Einfachheit ist der als Software oder Hardware implementierbare Algorithmus sehr schnell. Zudem ist Rijndael patentfrei und seine Nutzung unentgeltlich. Seiner Verwendung in Open Source-VPNs wie FreeSWAN[3] oder kommerziellen Produkten steht damit nichts im Wege.

Digitaler Fingerabdruck

Nicht nur der Datenstrom in VPNs muss durch eine wirksame Verschlüsselung gesichert werden. Beim Public-Key-Verfahren muss - wie bereits weiter oben erwähnt - durch zusätzliche Maßnahmen festgestellt werden können, ob der Kommunikationspartner wirklich der ist, für den er sich ausgibt. Aus dieser Anforderung haben sich drei Vertrauensmodelle entwickelt.

Das erste und einfachste Modell wird als Direct Trustbezeichnet. Zur Erläuterung zitiert die Kryptographie an dieser Stelle traditionell das theoretische Beispiel von Alice und Bob: Alice möchte Bob eine vertrauliche Nachricht schicken, die verschlüsselt und signiert sein soll. Dazu benötigt sie Bobs öffentlichen Schlüssel und die Gewissheit, dass dieser wirklich Bob und nicht etwa einem Dritten gehört, der dann die nicht für ihn bestimmte Nachricht entschlüsseln könnte. Eine mögliche Lösung dieses grundsätzlichen Problems sind digitale Zertifikate. Sie enthalten den öffentlichen Schlüssel und den Namen seines Besitzers. Mit seiner Hilfe kann Alice nun leicht feststellen, ob der öffentliche Schlüssel tatsächlich Bob gehört. Alice ist nämlich im Besitz des öffentlichen Schlüssels der signierenden Instanz, mit dem sie Bobs Zertifikat überprüft. Sein Wert hängt also wesentlich von der Vertrauenswürdigkeit des Ausstellenden ab. So könnte Bob das digitale Zertifikat einfach selbst erzeugt haben. Dies stellt kein Problem dar, wenn sich Alice und Bob persönlich kennen. Er würde sein Zertifikat einfach per Email an Alice schicken, und ein Vergleich des so genannten Fingerprint per Telefon würde Manipulationen am Zertifikat ausschließen. Gegenüber unbekannten Dritten hätte Bobs Zertifikat natürlich gerade einmal den Wert eines selbst ausgestellten Personalausweises. Auch im Rechtsverkehr wäre es vollkommen unverbindlich, da keine dritte Instanz seine Zugehörigkeit zu Bobs Person bezeugen könnte.

Im überschaubaren, persönlichen Umfeld eines kleinen Kreises von Beteiligten funktioniert dieses Modell jedoch recht einfach und zuverlässig. Wegen des zusätzlichen Aufwands für die Verwaltung der Zertifikate werden im Direct-Trust-Modell meist nur die öffentlichen Schlüssel ausgetauscht und die Signaturen verglichen. Programme wie GnuPG erlauben den einfachen Import und Export von öffentlichen Schlüsseln aus einem ``Schlüsselbund''. Schwierig wird es hingegen, wenn ein im Umlauf befindlicher öffentlicher Schlüssel gesperrt werden soll. Alle Beteiligten müssen diesen Schlüssel manuell löschen und durch seinen neu generierten Nachfolger ersetzen.

Das zweite, flexiblere Modell ist das Web of Trust. Jedes Mitglied des Netzes signiert die digitalen Zertifikate einer anderen, ihm entweder persönlich bekannten oder vertrauenswürdigen Person. Da sich Alice und Bob persönlich kennen, signiert einer des anderen Zertifikat. Von nun an kann Alice allen Mitgliedern vertrauen, deren Zertifikate von Bob signiert wurden. Auf diese Weise bildet sich sehr schnell ein großes Netz von Vertrauensbeziehungen. Die von der Zeitschrift c't initiierte Krypto-Kampagne ist ein lebendes Beispiel für ein Web of Trust. Auf Messen werden gegen Vorlage des Personalausweises digitale Zertifikate verteilt: c't tritt sozusagen als Certification Authority (CA) auf. Genau wieDirect Trust benötigt dieses Modell keine spezielle Infrastruktur. Die Zertifikate bzw. öffentlichen Schlüssel aller Teilnehmer werden auf den öffentlichen PGP-Servern bereit gestellt. Alice könnte nun jedem Schlüssel vertrauen, der von c't zertifiziert wurde. Eine Richtlinie für die Vergabe, Zurückziehung und Löschung von Schlüsseln ist in einem solchen dezentralen Netz nicht durchsetzbar. Für die juristische Seite gilt das bereits zum Direct-Trust-Modell Gesagte.

Die leistungsfähigste, aber auch komplizierteste Variante ist das hierarchische Vertrauensmodell. Als zentrale Zertifizierungsinstanz oder Certification Authority (CA) kann eine Behörde, ein externer Dienstleister oder eine unternehmensinterne Einrichtung fungieren. Signiert sie ein Zertifikat, erhält es eine einem Ausweis ähnliche Stellung. Eine CA kann eine oder mehrere hierarchisch angeordnete Zertifizierungsinstanzen besitzen. Daneben gibt es die Registrierungsstelle (RA), bei der sich die Benutzer anmelden und ausweisen. Ist die Identität eines Antragstellers zweifelsfrei festgestellt, generiert die CA ein komplementäres Schlüsselpaar. Der geheime Schlüssel dient der Erzeugung der digitalen Signatur, der öffentliche ihrer Überprüfung. Eine Identitätsüberprüfung unter Zehntausenden von Zertifikatsinhabern wäre viel zu aufwändig, weshalb die Daten des Inhabers und seine öffentlichen Schlüssel im Zertifikat verpackt und mit dem Signaturschlüssel der Instanz unterzeichnet werden. Nun stellt es die CA allen anderen Benutzern auf eigenen Zertifikate-Servern zur Verfügung. Damit alle Benutzer ein digitales Zertifikat überprüfen können, müssen sie im Besitz des öffentlichen Schlüssels der Instanz sein. Ihre gesamte Infrastruktur wird als Trust Center bezeichnet. Tätigt Bob mit dem Zertifikat eines Trust Centers eine Transaktion, kann er diese später nur schwer bestreiten, da sie sich seinem Zertifikat und damit seiner Person zuordnen lässt.

X.509

Der wichtigste Standard für digitale Zertifikate ist X.509. Seit seiner Veröffentlichung 1988 wurde er zweimal erweitert, - die aktuelle Version ist X.509v3. Besonderer Wert wurde auf seine proprietäre Erweiterbarkeit gelegt, die mit Profilen realisiert wird. Von diesen Möglichkeiten machte auch das Bundesamt für die Sicherheit in der Informationstechnik (BSI) Gebrauch, um seine Anforderungen für das deutsche Signaturgesetz umzusetzen. Das wichtigste Profil wurde von der Internet-Standardisierungsbehörde IETF im Rahmen des PKIX-Standards entwickelt.

Tatsächlich ist jeder Benutzer eines Webbrowsers schon einmal mit diesem Standard in Berührung gekommen. Er wird im SSL-Protokoll für die Server-Authentisierung verwendet. Es überlässt dem Anwender selbst die Entscheidung, ob er ein digitales Zertifikat annehmen oder ablehnen möchte. Selbst ungültige und selbst ausgestellte Zertifikate können benutzt werden. Letzteres ist aus Kostengründen besonders für große Unternehmen mit umfangreichen Intranets interessant, zumal X.509-Zertifikate auch von den meisten Emailprogrammen unterstützt werden.

Theorie und Praxis

In der Praxis hängt die Glaubwürdigkeit eines von einem Trust Center ausgegebenen Zertifikats nicht nur von der Wirksamkeit der eingesetzten kryptographischen Verfahren ab. Zwar muss ein Trust Center in Deutschland den Anforderungen des Signaturgesetzes von 1997 bzw. der EU-Signaturrichtlinie genügen. Eine regelmäßige Überprüfung der Trust Center auf die Einhaltung der Richtlinien vor Ort findet jedoch nicht statt. Auch die Haftungsregelung für einfache Zertifikate bietet nur eine trügerische Sicherheit: ``Verletzt ein Zertifizierungsdiensteanbieter die Anforderungen dieses Gesetzes ... oder versagen seine Produkte ... so hat er einem Dritten den Schaden zu ersetzen, den dieser dadurch erleidet, dass er auf die Angaben in einem ... Zertifikat ... vertraut.'' Die Beweislast dafür liegt jedoch beim rechtmäßigen Zertifikatsbesitzer. Praktisch wird ihm dies in den seltensten Fällen gelingen, da die komplexen Infrastrukturen und Technologien der Trust Center für ihn nicht transparent sind.

Gerade dieser große Aufwand ist es auch, der für eine beträchtliche Anzahl von möglichen Fehlerquellen und damit auch von Angreifern nutzbare Schwachstellen sorgt. Ist es ihm erst einmal gelungen, auf einen digitale Zertifikate erzeugenden Rechner vorzudringen, kann er sie massenhaft fälschen. Der Anreiz ist offensichtlich sehr hoch und das Entdeckungsrisiko vergleichsweise gering. Ein noch leichterer Weg ist ein Angriff auf das schwächste Glied der Kette, - den meist ungesicherten PC des arglosen Verbrauchers. Dass dies möglich ist, bewiesen im Frühjahr Bonner Wissenschaftler, die die Software des Trust Centers der Deutschen Post AG mit Hilfe eines Trojaners aushebelten[4]. Für den rechtmäßigen Besitzer hat der mögliche Missbrauch seiner persönlichen Zertifikate weitreichende Konsequenzen. Mit der Umsetzung der EU-Richtlinie für elektronische Signaturen am 1.8.2001 wurden diese der eigenhändigen Unterschrift gleich gestellt.

Nicht immer muss der Angreifer einen so hohen technischen Aufwand betreiben, um in den Besitz von Zertifikaten zu kommen. Im Januar des Jahres gab sich ein Unbekannter bei dem Trust Center-Unternehmen Verisign als Mitarbeiter von Microsoft aus und erhielt ohne weitere Identitätsüberprüfung zwei echte Zertifikate zugeteilt[5]. Drei Monate später wurde der Lapsus öffentlich bekannt und Verisign trug die erschwindelten Zertifikate in eine Sperrliste oder Certificate Revocation List (CRL) ein. Jedoch ist in Verisigns Zertifikaten keine Information über deren Speicherort (CRL Distribution Point CDP) enthalten. Ohne diesen kann eine Software, etwa ein Webbrowser, die Sperrliste aber nicht finden und durchsuchen. Als Folge konnten Microsofts Kunden beispielsweise ActiveX-Controls oder Office-Makros benutzen, die nur scheinbar von Microsoft stammten, aber tatsächlich einen Trojaner des Betrügers enthielten.

Eine weitere mögliche Fehlerquelle im Rückrufprozess ist die zur Schadensminimierung notwendige, möglichst zeitnahe und fehlerfreie Ausführung. Dies funktioniert innerhalb eines Trust Centers vielleicht noch zuverlässig. Tatsächlich ist der Rückrufprozess jedoch sehr viel komplexer, da die Zertifikate hierarchisch strukturiert sind und ein Rückruf deshalb auch alle abhängigen Zertifikate betrifft. Hinzu kommt, dass die Trust Center verschiedener Anbieter ihre Zertifikate untereinander anerkennen. Diese Cross-Zertifizierung bedarf eines enormen technischen und organisatorischen Aufwands. Verwenden die beteiligten Trust Center nicht gerade die Software desselben Herstellers, sind Probleme trotz existierender Standards nicht auszuschließen.

Literatur & Links

[1] Electronic Frontier Foundation, Cracking DES, O'Reilly Verlag, 1998

[2] AES Souce-Code,http://www.nist.gov/aes

[3] FreeSWAN VPN, http://www.freeswan.org

[4] Digitales Signieren unsicher, Heise Ticker,http://www.heise.de/newsticker/data/js-11.06.01-000/

[5] Microsoft warnt vor Cracker-Zerifikat, Heise Ticker, http://www.heise.de/newsticker/data/jo-24.03.01-001/

Jörg Frühbrodt ist freiberuflicher IT-Consultant und Trainer in Berlin. Er war zuletzt Leiter der Berliner Niederlassung der ID-PRO AG und zuvor Senior Consultant für die GE CompuNet AG, Sun Microsystems sowie die Britischen Streitkräfte.