Wenn es um die Kommerzialisierung des Internet geht, ist das am meisten zitierte Beispiel das Bezahlen per Kreditkarte. Das sei höchst unsicher und folglich nicht einsetzbar, da die Kreditkartennummer und die übrigen Details unverschlüsselt und für jedermann lesbar über das Netz geschickt würden.
Nur ist gerade die Kreditkartentransaktion eher ein Antibeispiel: Bezahlen per Kreditkarte im Internet ist nicht unsicherer als im italienischen Restaurant, im Kaufhaus oder sonstwo. Hier nutzen die Kreditkartenbesitzer fleißig die bequeme Zahlungsfunktion und kümmern sich nicht weiter darum, was der freundliche Kellner oder die Kassiererin mit den Belegen anstellen. Im Internet aber schreit man Zeter und Mordio, weil die Zahlungsdaten im Klartext übertragen werden. Das Problem, das hier deutlich wird, ist eher ein Problem des Kreditkartensystems, nicht des Internet. Mißbrauch ist in beiden Fällen möglich.
Dennoch ändert die Tatsache, daß das Kreditkartenbeispiel eigentlich keins ist, nichts daran, daß ein Bedarf nach vertraulicher und verbindlicher Datenkommunikation besteht - auch wenn im Internet durchaus nicht "jedermann" die übertragenen Daten abhören kann. Übrigens sind die Kreditkartenunternehmen keineswegs untätig. So haben VISA und Microsoft Ende September die Spezifikation ihrer 'Secure Transaction Technology' (STT) [[#literatur 2]] veröffentlicht. Drei Tage später zogen Mastercard, IBM, Netscape, GTE und CyberCash mit ihrem Vorschlag 'Secure Electronic Payment Protocol Specification' (SEPP) [[#literatur 3]] nach. Beides ohne die sonst übliche Geheimniskrämerei, sondern als offene Spezifikationen, die jeder implementieren kann.
Bevor nun jeder darangeht, Hals über Kopf Firewall-Hard- oder -Software zu installieren, den Datenverkehr bis aufs letzte Bit zu verschlüsseln und womöglich in letzter Konsequenz den oder die eigenen Rechner ganz vom Internet abzukoppeln: Don't panic! Zunächst gilt es, eine nüchterne Analyse durchzuführen und zu fragen, wozu Security (was immer sich hinter diesem schillernden Begriff verbirgt) eigentlich gut ist, woher mögliche Gefahren drohen und wie man ihrer Herr werden kann. Außerdem können Unternehmen mit Stand-alone-Rechnern nur schwerlich Online-Geschäfte tätigen.
Zunächst sei unterschieden zwischen Sicherheitskonzepten auf zwei Ebenen:
Erstere beschäftigen sich mit dem Zugang zum Netz (beziehungsweise dessen Verhinderung) auf TCP/IP-Ebene. Fragestellungen sind hier, wie man bestimmte Dienste wie Telnet oder FTP nur für bestimmte Clients (Rechner) zulassen und andere Maschinen ausschließen kann. Die Stichworte in diesem Bereich heißen Firewall, Paketfilter, Router-Konfiguration und so weiter. Um die Netzebene soll es hier nicht gehen; diese Thematik wurde bereits an anderen Stellen ausführlich behandelt, etwa in Michael Kienles [#literatur iX-Artikel].
Vielmehr beschäftigt sich der vorliegende Artikel mit Sicherheitskonzepten auf der Anwendungsebene. Diese setzen den grundsätzlichen Zugang eines Clients zu einem bestimmten Dienst voraus. Beispiel WWW: Wer als Anbieter am Online-Business interessiert ist, muß den Zugriff zu seinem WWW-Server selbstredend für jeden potentiellen Kunden freischalten und nicht nur für einen erlauchten Kreis. (Letzteres entspräche einer geschlossenen Benutzergruppe, deren Mitglieder mit Name, Kennwort und/oder Rechneradresse beim Unternehmen registriert sind - eine Anwendung übrigens, die sich durchaus sinnvoll mit einem öffentlichen System kombinieren läßt.)
Sicherheitsfragen sind hier nicht bestimmte Netzeigenschaften, sondern sie stellen sich auf der Ebene von Objekten, Benutzern, Servern und Clients: Wie kann ich verbindliche Transaktionen über das Netz abwickeln? Wie kann ich mich vergewissern, daß mein Kommunikationspartner tatsächlich derjenige ist, für den er sich ausgibt? Wie kann ich Dokumente nur für ganz bestimmte Clients freigeben, etwa solche, die dafür bezahlt haben? Wie kann ich diese Dokumente übertragen, ohne daß sie auf dem Weg zum Kunden in einer der vielen Internet-Zwischenstationen einem Unbefugten in die Hände fallen? Diese und andere Probleme werden im folgenden betrachtet. Der Fokus richtet sich speziell auf das World Wide Web und beleuchtet die wichtigsten gegenwärtig verfügbaren Antworten auf die gerade gestellten Fragen.
Nicht behandelt werden Aspekte der Ablaufsicherheit von WWW-Servern und CGI-Skripts, ebenfalls nicht Probleme, die mit nicht ordnungsgemäß funktionierenden externen Viewern auftreten können. (Wenn etwa der PostScript-Viewer dank einer maliziösen PS-Datei die Dateien des arglosen Netsurfers radiert, ist das schon ärgerlich. Bei einer vorsintflutlichen Ghostscript-Version konnte das durchaus passieren, heute muß der Anwender oder Systemverwalter schon explizit eine Voreinstellung ändern, um sich selbst oder die ihm anvertrauten Benutzer dieser Gefahr auszusetzen.)
Der bequeme weltweite Zugriff auf frei verfügbare Dokumente ist eine tolle Sache. Das WWW mit seinen grafischen Browsern hat das Internet explodieren lassen - und die Explosion dauert an. Allerdings möchten manche Informationsanbieter ihre Dokumente nicht für jedermann ins Web stellen, sondern nur für eine ganz bestimmte Gruppe. Beispiel sei eine internationale Arbeitsgruppe: die internen Diskussions'papiere' auf einem vom Netz abgeschotteten Rechner zu verwahren hilft niemandem weiter, denn die Gruppenmitglieder sollen von ihrem jeweiligen Arbeitsplatz darauf zugreifen können. Die Internet-Anbindung ist also durchaus sinnvoll. Das erfordert bei jeder Anfrage, den Zugreifer sicher zu identifizieren und in Abhängigkeit von dieser Authentifizierung den Zugriff zu gestatten oder zu verweigern (Autorisierung). So wie sich der Server von der Authentizität des Clients überzeugt, muß auch die umgekehrte Richtung möglich sein. Der Nutzer will sich sicher sein, daß eine bestimmte Information tatsächlich vom gewünschten Anbieter stammt und ihm nicht jemand anders gefälschte Daten unterschiebt.
Nicht nur beim elektronischen Handel, aber dort besonders, ist Verbindlichkeit von Bedeutung. Im Streitfall muß der Verkäufer dem Käufer nachweisen können, daß dieser tatsächlich einen verbindlichen Auftrag über das Netz getätigt hat. Der Käufer hätte ein Angebot oder eine Lieferzusage ebenfalls gern in verbindlicher Form, so daß er den Verkäufer, falls nötig, darauf festnageln kann. Vertrauliche Daten müssen vertraulich bleiben. Die Übertragung der Daten über ein öffentliches Netz muß verschlüsselt erfolgen, damit sie kein Unbefugter ausspähen kann. Nicht einmal die Existenz der Daten sollte verraten werden, weshalb die komplette HTTP-Transaktion (Hypertext Transfer Protocol), in denen die Dokumentnamen vorkommen, ebenfalls zu verschlüsseln ist. Und sollte jemand die übertragenen Daten unterwegs manipulieren - unabhängig davon, ob dieser Jemand die Originaldaten entziffern kann oder nicht -, muß der Empfänger diese Verletzung der Integrität sofort feststellen können. Die vier wesentlichen Stichworte lauten deshalb:
Besondere Anforderungen gelten beim elektronischen Geld, dem ECash, Cybermoney - wie immer es heißen mag. Wer elektronisch bezahlt, will nicht auf die Vorzüge verzichten, die Bargeld auszeichnet: es wird von jedermann akzeptiert, und man sieht der Banknote nicht an, durch welche Hände sie gegangen ist. Zur Verbindlichkeit kommt die Anforderung nach Anonymität hinzu - es sei denn, man verläßt sich auf eine zentrale Instanz, die alle Geldtransaktionen abwickelt, sie gegenüber Dritten geheimhält und auch selbst nicht für irgendwelche finsteren Zwecke ausnutzt.
Für alle diese und andere Problemstellungen gibt es kryptographische Lösungen. Es würde entschieden zu weit führen, sie in diesem Zusammenhang zu erläutern und die mathematischen Grundlagen zu klären. Der interessierte Leser sei auf das ausgezeichnete Buch von Schneier verwiesen ([#literatur "The book the National Security Agency never wanted to be published"]). Einige grundlegende Ideen finden sich auch weiter unten.
Im World Wide Web werden derzeit in größerem Stil drei verschiedene Verfahren eingesetzt, von denen allerdings nur ein einziges standardisiert (besser: im HTTP-Internet-Draft [[#literatur 5]] vorgesehen) ist: 'Basic Authentication' implementiert jeder HTTP-konforme Client. Leider erfüllt Basic Authentication von den vier oben genannten Anforderungen nur die der Authentizität - und selbst die ist keineswegs als sicher anzusehen, da Basic Authentication keine kryptographische Lösung ist.
|
Vertrauliche und verbindliche Übertragung mit dem Hypertext Transfer Protocol |
Kryptographische Protokolle implementieren Secure HTTP (S-HTTP) und Secure Socket Layer (SSL), die in eigenen Internet-Drafts spezifiziert und unten kurz skizziert sind.
Schützt ein WWW-Server ein Dokument mittels Basic Authentication, läuft der HTTP-Zugriff in vier Schritten ab:
'Unauthorized to access the document'). Gleichzeitig teilt er dem Client über den HTTP-Header 'WWW-Authenticate' mit, durch welches Authentifizierungsverfahren das Dokument geschützt ist, hier Basic Authentication. HTTP ist offen für beliebige Authentifizierungsverfahren, so daß weitere je nach Bedarf ergänzt werden können. Der erste Nachteil der Basic-Authentifizierung liegt darin, daß User-ID und Paßwort praktisch im Klartext vom WWW-Client zum Server übertragen werden, und zwar im Header des HTTP-Requests:
Authorization: Basic bWVpZXI6c2llcnRlbjEwMg==
Diese Angaben werden vom Client lediglich nach dem Base64-Verfahren eingepackt, was aber einem gezielten Lauschangriff keinerlei ernsthaften Widerstand entgegenzusetzen vermag. Ein Hacker, der den obigen Authorization-Header mitschneidet, braucht lediglich die Base64-Kodierung rückgängig zu machen, was er bequem etwa mit dem zum Metamail-Paket gehörenden Kommando mmencode (ftp://ftp.informatik.uni-hildesheim.de/pub/X11/contrib/lib/auis-6.3/overhead/mail/metamail/metamail/mmcode.c) erledigt:
echo 'bWVpZXI6c2llcnRlbjEwMg=='\ | mmencode -b -u
Und schon ist der User-ID/Paßwort-String 'entschlüsselt', die Zeichenfolge meier:sierten102 steht als Ergebnis auf der Standardausgabe und verrät die User-ID meier und das Paßwort sierten102.
Alle, die physikalischen Zugriff auf das Übertragungsmedium besitzen, können diese Daten abhören: die Internet-Provider und sonstigen Instanzen, durch deren Knotenrechner die Datenpakete laufen. Außerdem hat jeder Proxy-Server, durch den ein HTTP-Request läuft, zumindest die Möglichkeit, Benutzerkennungen und Paßworte mitzuschneiden. Normale Proxy-Server wie der CERN-Server tun so etwas natürlich nicht, aber da die Sourcen frei verfügbar sind, ist es für einen versierten Programmierer kein großes Problem, die Software ein wenig zu erweitern.
Zweiter Nachteil: Basic Authentication bietet keinerlei Verschlüsselung der übertragenen Dokumente selbst. Hat der Zugreifer seine Berechtigung nachgewiesen, sendet der Server das angeforderte Dokument im Klartext - wie jedes andere auch.
In der Praxis ist das Basic-Verfahren dennoch durchaus zu gebrauchen, solange es nicht gerade hochsensible Informationen zu schützen gilt. Der Informationsanbieter muß sich eben darüber im klaren sein, daß diese Authentifizierungsmethode zwar den weitaus meisten Anwendern keine Zugriffsmöglichkeit bietet, einem ernsthaften Hack-Versuch jedoch kaum standhalten kann, sofern der Hacker Zugang zu den zwischen Client und Server transferierten HTTP-Nachrichten besitzt.
Wer Daten mittels 'Basic' schützt, muß abschätzen, wie groß der Schaden maximal werden kann, wenn ein Unberechtigter geschützte Daten abruft. Dieses Risiko gilt es zu dem angestrebten Gewinn ins Verhältnis zu setzen. Für einen Verlag beispielsweise kann Basic Authentication ein durchaus praktikables Verfahren sein, um eine kostenpflichtige Publikation nur registrierten Abonnenten zugänglich zu machen. Selbst wenn ein Hacker ein User-ID/Paßwort-Paar ermitteln und kostenlos Artikel abrufen sollte, hält sich der dadurch entstehende finanzielle Verlust in recht engen Grenzen. Ähnlich sieht es aus bei Softwaredistribution über das Netz. Bei zu schützenden personenbezogenen Daten oder strategischen internen Unternehmenspapieren ist Basic Authentication natürlich indiskutabel.
Was sind die Voraussetzungen für ein erfolgreiches Hacking? Wenn ein berechtigter Benutzer über einen Proxy auf den Original-Server zugreift, kann der Proxy die Protokollpakete mitschneiden und URIs (Universal Resource Identifier) zusammen mit den Authentifizierungsdaten speichern. Gefahr besteht auch dann, wenn der Daten-Einbrecher auf unterer Ebene über Zugriffsmöglichkeiten auf die IP-Pakete verfügt, also etwa einen 'Sniffer' an das lokale Netz anschließt. Die Internet-Provider, durch deren Equipment die IP-Pakete geroutet werden, können ebenfalls die Daten analysieren.
Minimieren läßt sich das Risiko, wenn User-ID und Paßwort allein noch nicht für den Zugang zum Dokument ausreichen, sondern der Benutzer darüber hinaus nur von bestimmten Maschinen aus zugreifen darf. Das ist insbesondere nützlich, wenn die Datenpakete das lokale Netz nicht verlassen. Diese Methode kombiniert das Basic-Verfahren mit der aus dem Eingangsbeispiel bekannten Zugriffsautorisierung auf Grund der Rechneradresse. Man verlasse sich aber nicht darauf, daß die Absenderadressen in IP-Paketen immer korrekt sind: ein versierter Hacker kann sie fälschen und versuchen, auf diese Weise Zugang zu einem Dienst zu erlangen. Aber dies ist eher ein Thema für die Firewall-Ebene.
Die schon aus der Antike bekannte Kunst der Kryptographie vermag - unterstützt durch schnelle Rechner und ausgefeilte Konzepte - Abhilfe zu schaffen. Diese Konzepte basieren auf sogenannten symmetrischen und asymmetrischen Verfahren
Doch zurück zum WWW. [[bild_url9] Diese Abbildung] skizziert die Anforderungen an eine vertrauliche und verbindliche Datenübertragung mittels HTTP. Der Request des Clients an den Server sollte signiert und chiffriert erfolgen. Nicht immer ist beides erforderlich, doch sollte die Möglichkeit dazu bestehen. Die Signatur vermittelt dem Server Sicherheit über die Identität des Clients und kann auf Grundlage dieser Information den Zugriff gestatten - oder nicht. Ein GET-Request, in dem der URI (Universal Resource Identifier) nicht chiffriert ist, verrät einem Lauscher, daß dieses Dokument existiert (genauer: daß der Client diesen URI abruft und der möglicherweise existiert). Diese Information allein kann schon sensibel sein.
|
SSL: zusätzliche Schicht über der Socket-Ebene, die beliebige TCP/IP-basierte höhere Protokolle 'fahren' kann. |
Außerdem kann der Hacker mit diesen Kenntnissen möglicherweise gezieltere Maßnahmen ergreifen, um an das Dokument selbst heranzukommen. Wenn der Client ein Dokument per PUT oder POST zum Server schickt, liegt die Notwendigkeit der Chiffrierung auf der Hand. Entsprechendes gilt für die HTTP-Response des Servers an den Client. Die Signatur ist hier ebenfalls sehr nützlich, da der Client sicher sein kann, daß es tatsächlich der Originalserver ist, der ihm das Dokument liefert, und nicht etwa ein übelwollender Zeitgenosse, der die Identität des Servers anzunehmen versuchte.
Wenn das Ganze durch einen Proxy-Server läuft, darf dieser Dokumente, bei denen der Originalserver eine Authentifizierung des Clients verlangt und die er unverschlüsselt abschickt, nicht in den Cache aufnehmen, da er nicht über die Autorisierungsinformationen und -mechanismen des Originalservers verfügt. Ein braver Proxy-Server reicht daher alle Dokumente, die ein Client mit dem HTTP-Header 'Authorization' im Request angefordert hat, an den Client durch, ohne sie lokal zu speichern. Allerdings können sich im allgemeinen weder Client noch Server darauf verlassen, daß ein Proxy sich tatsächlich so verhält. Dies ist eine Sicherheitslücke, da der Proxy die fälschlicherweise gespeicherten Dokumente auch an solche Clients ausliefert, die auf dem Originalserver keine Zugriffsrechte besitzen.
Bei chiffrierten Dokumenten sieht das ganz anders aus. Zwar bringt das Caching dem zugriffsberechtigten Client bei wiederholtem Zugriff keinen Vorteil - die Autorisierung muß stets der Originalserver durchführen -, aber es schadet auch nichts, da ein Unbefugter das gespeichertete vertrauliche Dokument nicht dechiffrieren kann.
Client und Server benötigen eingebaute Security-Funktionalität, um von kryptographischen Verfahren profitieren zu können. Für einen Proxy-Server ist das nicht erforderlich. Er reicht Requests und Responses unbesehen durch.
Das am lautstärksten promotete und daher bekannteste und am weitesten verbreitete kryptographische Verfahren im WWW heißt Secure Socket Layer (SSL) und wurde von Netscape Communications Corporation entwickelt, die auch gleich den passenden Server und Client dazu anbieten. Das Protokoll [[#literatur 10]] liegt offen, für nichtkommerzielle Anwendungen ist eine frei verfügbare Implementierung erhältlich. In letzter Zeit ist die Sicherheit, die Netscapes SSL-Implementierung bietet, allerdings ziemlich ins Gerede gekommen.
SSL legt, wie der Name andeutet, eine zusätzliche Schicht über die Socket-Ebene, die nach oben, sprich zur Anwendung hin, wie die üblichen Sockets aussieht. Gegenüber den wirklichen Sockets erscheint sie als die Anwendung. Der Vorteil dieses Verfahrens liegt darin, daß es nicht allein auf HTTP als Übertragungsprotokoll beschränkt ist. Vielmehr kann darüber jedes beliebige TCP-basierte höhere Protokoll gefahren werden, etwa FTP, WAIS, Telnet und so weiter. Allerdings können die vorhandenen Anwendungen nicht automatisch von SSL profitieren. Nötig sind spezielle Clients und Server, die SSL beherrschen.
Secure Socket Layer bietet dem Client immer eine Authentifizierung des Servers. Sie spielt sich komplett innerhalb der SSL-Ebene ab, die Anwendung bekommt deshalb nichts davon mit. Die Authentifizierung der Client-Seite erfolgt optional. Ist die SSL-Verbindung zwischen Client und Server hergestellt, werden alle Daten verschlüsselt und damit für Außenstehende unlesbar übertragen. Selbst wenn ein Lauscher die Daten nicht zu entziffern in der Lage ist, könnte er sie dennoch verfälschen. Dem beugt eine Integritätsprüfung in SSL vor. Die mit dieser Schicht aufgepeppten Internet-Protokolle laufen über andere Standardports ab als die regulären. So ist 443 statt 80 der Standardport für SSL-HTTP. Ein Client, der einen SSL-Request auf den URI http://host.domain/foo/bar absetzen will, muß sich folglich an den Port 443 des Rechners host.domain wenden. Explizite Portangaben im URI gehen aber immer vor.
Der Verbindungsaufbau läuft in vier Schritten ab:
Netscape Inc. hat SSL in ihren Browser namens Navigator eingebaut und vertreibt mit dem Netscape Secure Server das entsprechende Gegenstück. 'Secure' ist die Übertragung allerdings nur mit der in den USA vertriebenen Variante der Software. Um eine Exportlizenz zu erhalten, darf Netscape den Sitzungsschlüssel nicht in voller Länge chiffriert übertragen. Lediglich eine Chiffrierung von mageren 40 Bit des Schlüssels ist erlaubt. Von Sicherheit kann da natürlich keine Rede mehr sein. Auch in den USA ist die 40-Bit-Version des Client sehr verbreitet, da man sie sich bequem per Anonymous FTP besorgen kann.
Am 14. Juli 1995 forderte Hal Finney (hfinney@shell.portal.com) die Internet-Gemeinde dazu heraus, einen Sitzungsmitschnitt zwischen dem Netscape-Client und Netscapes Secure Server zu knacken. Damien Doligez aus Frankreich war der erste, der am 15. August die Lösung bekanntgab; unabhängig von ihm hatte eine weitere Gruppe zwei Stunden zuvor ebenfalls die als sicher geltende Sitzung geknackt. In beiden Fällen wurde ein Cluster vernetzter Workstations eingesetzt, die den gesamten Schlüsselraum per 'brute force' (http://www.brute.cl.cam.uk/brute/) absuchten und so nach ein bis zwei Wochen zum Ergebnis kamen. Eine zweite Herausforderung von Hal Finney knackten die 'Cyberpunks' innerhalb von knapp zweiunddreißig Stunden mit einem 'Key cracking ring'. Dieses Verfahren beruht ebenfalls auf brute force, verteilt die Aufgabe aber auf beliebig viele Maschinen im Internet, die dazu lediglich ihre freie CPU-Zeit zur Verfügung stellen müssen.
War diese Verletzlichkeit einer vermeintlichen Sicherheit auf die unverständlichen amerikanischen Exportbestimmungen zurückzuführen, so zeigt eine weitere Schwachstelle im Netscape Navigator, daß es schon genauerer Kenntnis der Materie und einiger Erfahrung bedarf, um kryptographische Verfahren auch korrekt zu implementieren. So hätte Doligez noch wesentlich früher zum Ziel kommen können, hätte er gewußt, daß der Netscape Navigator die Sitzungsschlüssel nicht zufällig, sondern lediglich pseudozufällig erzeugt. Pseudozufallszahlen liefern die auf Rechnern normalerweise verfügbaren Zufallsfunktionen.
Für kryptographische Anwendungen sind sie aber nicht hinreichend zufällig. Mit dieser Kenntnis läßt sich der abzusuchende Schlüsselraum dramatisch einschränken, und selbst die als sicher geltende und nicht exportfähige 128-Bit-Variante erscheint verletzlich. Inzwischen hat Netscape korrigierte Versionen der Softwareprodukte freigegeben. (Übrigens bietet Linux ab Version 1.3.30 echte Zufallsfunktionen im Kernel. Darin gehen zufällige externe Ereignisse ein wie etwa der zeitliche Abstand zwischen Tastatur- und anderen Interrupts. Der Timer-Interrupt eignet sich für diesen Zweck nicht.)
Einen zu SSL alternativen Ansatz bietet Secure HTTP (S-HTTP), das in [[#literatur 11]] detailliert beschrieben ist. Hier sind die kryptographischen Verfahren nicht auf der Verbindungs-, sondern auf der Anwendungsebene realisiert. Eine Beispielimplementierung stellen Secure Mosaic [[#literatur 12]] und Secure NCSA httpd [[#literatur 13]] dar, die über CommerceNet verfügbar sind, allerdings aus den oben genannten Gründen nur innerhalb der USA. Vom NCSA verlautet, das Institut wolle Secure Mosaic für den nichtkommerziellen Gebrauch kostenlos verfügbar machen. Über das Wann und Wie ist allerdings noch nichts bekannt.
Secure HTTP ist ein neues Protokoll, das ähnlich wie HTTP aufgebaut ist und als Inhalt gewöhnliche HTTP-Nachrichten kapselt. Die eingeschlossenen Requests und Responses sind entweder chiffriert oder signiert, chiffriert und signiert oder auch keins von beidem. Zusätzlich kann der Absender jeder der genannten Kombinationen per Hash-Funktion einen Message-Digest mitgeben, der die Datenintegrität gewährleistet. Enthält der Message-Digest einen Zeitstempel, schützen sich die Kommunikationspartner vor 'Replay-Attacken'. Darunter versteht man, daß ein Angreifer eine Nachricht - etwa einen Request - mitschneidet und sie, ohne daß er den Nachrichteninhalt hätte entziffern können, zu einem späteren Zeitpunkt an den Server sendet. Enthält die Nachricht den Zeitstempel des Original-Requests, erkennt der Server den gefälschten Zugriff anhand der Zeitüberschreitung und lehnt ihn ab, statt ihn auszuführen.
Im Unterschied zu SSL, wo sich alles im Hintergrund abspielt, macht Secure Mosaic die verschiedenen Sicherheitsstufen eines Dokuments dem Benutzer mit Icons sichtbar: eine unverschlüsselte und unsignierte Nachricht erscheint als einfache Textseite, eine digitale Unterschrift führt zu einem Siegel auf der Seite. Verschlüsselter Text steckt in einem Umschlag, gegebenenfalls mit einem Siegel versehen.
S-HTTP unterstützt eine ganze Reihe verschiedener symmetrischer und asymmetrischer Verfahren für das initiale Handshake, für Chiffrierung und digitale Unterschriften sowie diverse Hash-Funktionen zur Berechnung des Message-Digest. Die tatsächlich zur Anwendung kommenden Verfahren handeln Client und Server miteinander aus. Es ist auch möglich, Schlüssel für symmetrische Chiffrierung auf einem externen Weg (Briefpost, Telefax et cetera) und für die spätere S-HTTP-Kommunikation einzusetzen.
Der Vorteil von Secure HTTP gegenüber SLL liegt in der wesentlich breiteren Vielfalt von Anwendungsmöglichkeiten. Das rührt daher, daß die kryptographischen Verfahren auf der Anwendungsebene liegen und damit dem Benutzer - Informationskunden wie -anbieter - zugänglich sind. Mit Secure HTTP lassen sich nicht nur Dokumente vertraulich austauschen. Dem Benutzer steht zusätzlich das Feature 'digitale Unterschrift' zur Verfügung, mit dessen Hilfe sich signierte Dokumente austauschen lassen. Die Kommunikationspartner können Verträge abschließen, verbindliche öffentliche Mitteilungen machen und so weiter.
Künftig werden neue WWW-Clients und -Server mit erweiterten Security-Features verfügbar sein. Die veröffentlichten Spezifikationen der Kreditkartengesellschaften [[#literatur 2], [#literatur 3]] zeigen, daß sie sich des Themas angenommen haben. Abgesehen von der vertraulichen Datenübertragung, von der alle Beteiligten profitieren, bringt dies folgende Vorteile für den Online-Händler: Er kann die Kreditkartentransaktion komplett über das Netz ausführen, der Vorgang ist automatisierbar, und die Abbuchung von Kleinstbeträgen (den sogenannten 'Micro Payments') wird möglich. Der Netsurfer wird im Internet kostenpflichtige Informationsangebote finden, die er mit seiner Kreditkarte bezahlen kann. Auf den ersten Blick ist die Kostenpflichtigkeit vielleicht ein Nachteil, doch wird das Internet so durch Angebote bereichert werden, die man dort sonst vergeblich suchen würde.
Erfreulich ist die Tatsache, daß die Spezifikationen offen sind und von jedermann ohne Einschränkungen in Produkten genutzt werden können. Die Gruppe um Mastercard strebt gar an, ihren Entwurf zu einem Internet-RFC zu machen. Der Ende September von Microsoft veröffentlichte Alternativentwurf zu Netscapes SSL, Private Communication Technology Protocol (PCT, siehe [[#literatur 14]]), ist als Internet-Draft verfügbar. Das alles läßt auf Hersteller- und Plattformunabhängigkeit hoffen. Möglicherweise wird es in bester Internet-Tradition frei verfügbare Referenzimplementierungen im Quellcode als 'Proof of concept' geben, vielleicht sogar (darf man träumen?) von Microsoft.
Netscape kann man angesichts solcher Kontrahenten und der jüngsten Sicherheitspannen nur raten, sich der Unterstützung kompetenter Kryptographen zu versichern und eine Produktvariante mit starker Verschlüsselung für den außeramerikanischen Markt zu erstellen. Es sollte doch nicht allzu schwer sein, einen europäischen Partner zu finden, der die nicht exportfähigen Module selbst entwickelt, in die Produkte einbringt und sich um die Vermarktung kümmert.
Im Gerangel der Großen bleibt der Endbenutzer nicht auf der Strecke; im Gegenteil. Konkurrenz belebt das Geschäft, und solange nicht ein einziger Anbieter - mag er Netscape oder Microsoft heißen - die Szene beherrscht, darf sich der Kunde über günstige Preise freuen. Die Wahrung der Privatsphäre innerhalb der vernetzten Gesellschaft scheint ebenfalls gesichert zu sein. Sah sich Krypto-Experte und DigiCash-Chef David Chaum auf der ersten internationalen WWW-Konferenz 1994 in Genf noch genötigt, einen flammenden Appell für die Privatsphäre im Netz zu halten - für Public-Key-Verfahren und gegen den alle Transaktionen registrierenden Großen Bruder -, geht der Trend jetzt klar in die richtige Richtung. Und das nicht trotz, sondern wegen der Kommerzialisierung des Internet. Vertraulichkeit ist eine wichtige Voraussetzung dafür, daß Geschäfte im Netz abgewickelt werden, daß das Internet für interne Kommunikation genutzt wird und weiter wächst.
Rein technisch ist also alles kein Problem (von fehlerhaften Implementierungen - siehe Netscape - einmal abgesehen), und mathematisch ist alles gut begründet. Vertraulichkeit, Verbindlichkeit und so weiter lassen sich aus technischer Sicht durchaus realisieren. Allerdings: Massive Bedenken kommen von der juristischen Seite. Prof. Dr. T. Hoeren formulierte es in einem Vortrag drastisch so: 'Vergessen Sie, was Sie über Online-Dienste gehört haben: Es ist alles verboten.' Das deutsche Recht sieht eine digitale Unterzeichnung von Vertragsdokumenten nicht vor. Welcher Richter wird im Streitfall eine digitale Unterschrift verstehen, geschweige denn anerkennen? Geschäfte elektronisch tätigen? Wo sind die Rechtsgrundlagen? Digitales Geld? Undenkbar. Recht und Gesetz hinken der Technik weit hinterher. Der Gesetzgeber ist gefordert (und hoffentlich nicht überfordert), hier Leitlinien und neues Recht zu schaffen. Bis jetzt bewegen sich die Beteiligten zwangsläufig in einer Grauzone. Funktionieren wird das trotzdem. Ein Unternehmen, das Bestellungen telefonisch oder per Fax entgegennimmt, wird wenig Probleme mit Bestellungen aus dem Internet haben. Es wird wie zuvor das Risiko minimieren, etwa durch den Versand per Nachnahme oder durch Kreditkartenabbuchung. Nur auf die allgemeine Akzeptanz von Cyberdollars werden wir wohl noch etwas warten müssen.
Rainer Klute
ist Dipl.-Informatiker und geschäftsführender Gesellschafter der NADS GmbH in Dortmund.
Literatur
[1] Bruce Schneier; Applied cryptography: protocols, algorithms and source code in C; New York (John Wiley and Sons) 1994
[2] VISA International Service Association und Microsoft Corporation; Secure Transaction Technology Specifications (http://www.visa.com/visa-stt/index.html); Version 1.0; 26. September 1995
[3] IBM, Netscape, GTE, CyberCash und MasterCard; Secure Electronic Payment Protocol Specification (http://www.mastercard.com/Sepp/sepptoc.htm); Draft Version 1.1; 29. September 1995
[4] Michael Kienle; Firewall-Konzepte; Standhafte Mauern; Sicherheit für lokale Netze ohne Diensteinschränkung; iX7/94, S. 130 ff.
[5] Tim Berners-Lee, Roy T. Fielding, Henrik Frystyk Nielsen; Hypertext Transfer Protocol - HTTP/1.0; Internet-Draft draft-ietf-http-v10-spec-02. txt; 13. August 1995
[6] Ronald L. Rivest; The RC5 Encryption Algorithm (ftp://rsa.com/pub/rc5); RSA Data Security and MIT Laboratory for Computer Science; April 1995
[7] B. Kaliski; The MD2 Message-Digest Algorithm (RFC 1319, http://www.lau.aetc.af.mil/rfc/rfc1319.txt); April 1992
[8] R. Rivest; The MD4 Message-Digest Algorithm (RFC 1320, http://www.lau.aetc.af.mil/rfc/rfc1320.txt); April 1992
[9] R. Rivest; The MD5 Message-Digest Algorithm (RFC 1321, http://www.lau.aetc.af.mil/rfc/rfc1321.txt); April 1992
[10] Kipp E.B. Hickman, Taher Elgamal; [gopher://ds.internic.net:70/00/internet-drafts/draft-hickman-netscape-ssl-01.txt The SSL Protocol]; Internet-Draft; Juni 1995
[11] E. Rescorla, A. Schiffman; The Secure HyperText Transfer Protocol (ftp://ds.internic.net/internet-drafts/draft-ietf-wts-shttp-00.txt); Internet-Draft; Juli 1995
[12] William T. Wong; Secure NCSA Mosaic Manual (http://www.commerce.net/software/SMosaic/Docs/manual.html); Februar 1995
[13] William T. Wong; Secure NCSA httpd Manual (http://www.commerce.net/software/Shttpd/Docs/manual.html); Februar 1995
[14] Josh Benaloh, Butler Lampson, Daniel Simon, Terence Spies, Bennet Yee; Private Communication Technology Protocol (http://www.microsoft.com/windows/ie/pct.htm); September 1995
[15] Adam Cain; An Introduction to Security on the Web; Third International World Wide Web Conference, 1995, 132
| iX-TRACT |
|
Dieser Text ist der Zeitschriften-Ausgabe 12/1995 von iX entnommen.
Parallelprogrammierung - die Kunst der Multi-Core-Nutzung
Agile ALM - agile Praktiken im Application Lifecycle Management
Webentwicklung - Applikationen für mobile Clients
