Sicherheitsprotokolle

Wozu brauche ich den Internetzertifikate?

Darauf sind wir grob schon weiter oben eingegangen. Im Internet kommen verschiedene Protokollformen für die sichere Übertragung zum Einsatz. Du musst dabei zwischen folgenden Einsatzgebieten unterscheiden:

• WWW (WorldWideWeb)
• EMail (Private Nachrichten)
• ECash (Bezahlen im Internet)

Jeden dieser Kommunikationsprotokolle (z. B. HTTP, SMTP, etc.) überträgt die Daten unverschlüsselt. D.h., dass die Daten auf dem Weg vom Punkt A zu Punkt B abgehört oder sogar verändert werden können. Damit dies nicht passiert, müssen die Datenkanäle verschlüsselt sein. Auf die verschiedenen Verschlüsselungsverfahren gehen wir auf der Seite Verschlüsselung ein. Für die heutigen Signatur- und Verschlüsselungsverfahren benötigst Du i. d. R. ein Zertifikat.

Welche Protokolle kommen für eine verschlüsselte Übertragung zum Einsatz? (SSL)

Es gibt zum Glück eine überschaubare Menge an Protokollen, die für einen oder mehrere Einsatzgebiete möglich sind. Im Bereich WWW, EMail und ECash und auch alle anderen Sockets (z. B. FTP), dient das SSL-Protokoll (SecuritySocketLayer). SSL baut eine sichere Kommunikationsleitung zwischen Client (Dir) und einem Server (z. B. Deine Bank) auf. Dabei wird in der Regel zur Verschlüsselung des DatenStreams die RC4-Kodierung eingesetzt. Es ist jedoch auch eine DES bzw. 3DES-Verschlüsselung möglich. SSL wird von den heutigen Browsern (u. a. Firefox, Opera oder Internet Explorer) auf der Clientseite standardmäßig unterstütz. Selbstverständlich muss auch der Webserver (Serverseite) die SSL-Verbindung anbieten. Dies ist aber bei den handelsüblichen Modellen (Apache Webserver, MS Information Server, JavaWebserver, uvm.) heute fast immer der Fall.

Du wirst bestimmt schon mal bewusst oder unbewusst eine SSL (z. B. beim Internetbanking oder beim Internetshoping) genutzt haben.

Für die Entwickler unter euch wird sicher auch interessant sein, dass SSL bei Inprise Corba (verteilte Systeme) unterstützt wird. Dies ermöglichst eine sehr leichte und sichere Implementation von verteilten Systemen.

Achtung:

Die USA haben eine Exportbeschränkung auf die Schlüsselalgorithmen gelegt. D.h., dass z. B. die Browser bzw. Windows in anderen Staaten nur max. eine 40bit-Verschlüsselung unterstützen. Dies ist z. B. einigen Banken (Sparkassen) zu wendig und sie bieten einen extra SSL-Client an, der die 128bit-Verschlüsselung unterstützt.

Wie läuft das bei SSL nun ab?

Wenn Du z. B. mit Deinem Browser auf eine sichere Internetseite gehst, fordert dieser beim Server ein X.509-Zertifikat an. Dieses Zertifikat beinhaltet u.a. den PublicKey des Servers und die von ihm unterstützen Verschlüsselungsverfahren. Wenn das Serverzertifikat von einer eingetragenen CA unterschrieben ist, informiert Dich der Server kurz in einem Dialog davon, dass Du im Begriff bist eine sichere HTTPs-Verbindung aufzubauen. (der Präfix s steht für security) Sofern das Webserverzertifikat nicht von einer eingetragenen CA unterschrieben ist, wird Dich der Browser mit einer sehr umfangreichen Sicherheitswarnung informieren. Dann musst Du selber entscheiden, ob Du das Zertifikat und damit den Anbieter akzeptierst oder nicht.

Nachdem Du alles akzeptiert hast, erzeugt Dein Browser einen SessionKey für den Verschlüsselungsalgorithmus. Auf unserer WebserverAufbauPage (ITBeispiele) zeigen wir ein SSL-Beispiel von der Serverseite aus betrachtet.

Gibt es noch andere SecurityProtokolle?

Ja! - Nur haben die sich und werden sich vermutlich auch nicht durchsetzen. Die Entwicklung von SHEN ist zum Beispiel schon eingestellt worden. Auch SHTTP (Terisa Systems) wird auf der Clientseite (Browsern) kaum unterstütz. Es ist im Gegensatz zu SSL auch nur im HTTP-Protokoll verwendbar. Auch Microsoft versuchte sich an einem neuen Modell Namens STLP, dass PCT (PrivateCommunicationsTechnology) und SSL (SecuritySocketLayer) zusammenführen soll. Die Working Group für Transport Layer Security hat sich aber am 6. März auf SSL 3.0 geeinigt.

Wie läuft das nun mit der Sicherung bei EMails?

Bei E-Mails hat sich das S/MIME-Verfahren (auch mit einem X.509-Zertifikat) durchgesetzt. In diesem Fall wird die gesamte E-Mail incl. der Attachments vor der Übertragung verschlüsselt und ggf. signiert. Weiter oben haben wir bereits schon das Beispiel E-Mail erwähnt.

Alternativ zum S/MIME-Verfahren gibt es hier noch folgende weitere Protokolle:

• Das relativ weit verbreitete PGP (Pretty Good Privacy)
• PEM (Privacy Enhanced Mail)
• MailTrusT (von TeleTrusT Deutschland )

Bei MailTrustT (MTT) handelt es sich sicherlich auch um ein recht gut spezifiziertes und durchdachtes System. Genauso wie S/MIME arbeitet MTT auf der Basis von X.509-Zertifikaten. Die Spezifikationen sind frei verfügbar und im Gegensatz zu S/MIME sehr gut dokumentiert.

Neben dem S/MIME im geschäftlichen Verkehr hat sich im Privatbereich PGP einen guten Namen gemacht. Dies rührt sichererlich daher, dass es einige Open Source-Projekte in diesem Bereich gibt. PGP selber ist mitlerweile in Symantec aufgegangen. Als Alternative sei an dieser Stelle jedoch GnuPG erwähnt, welches weiterhin als Open Source angeboten wird. Zum Erstellen eines PGP-Zertifikates möchten wir auf die Krypto-Kampagne von Heise verweisen.

Wie ist es nun mit dem Bezahlen im Internet - Was steht mir da zur Verfügung? (ECash)

Auch hier stehen uns mehrere Protokolle zur Verfügung. Ein sehr vielversprechender Ansatz ist das SET-Protokoll (Secure Encryption Transaction-Protokoll), dass eine Verbindung zwischen STT (Visa/Microsoft) und SEPP Mastercard/IBM/Netscape/GTE/CyberCash) ist. Die Unternehmen verfolgen mit diesem Ansatz eine sicheres Verfahren zur Identifizierung zwischen Kunde und Händler sowie eine abhörsichere Übertragung der Kreditkartennummer bzw. der Zahlungsdaten. Wie bei SSL, S/MIME wird auch bei SET das X.509-Zertifikat verwendet. Leider sind die Zertifikate in ihren Inhalten unterschiedlich, so dass nicht unbedingt eine SSL Zertifikat z. B. für S/MIME verwendet werden kann. Jedoch ist eine Integration aller Zertifikatsdaten möglich. In diesem Fall kann der USER mit einem Zertifikat alle wichtigen SecurityTransaktionen im Internet durchführen.

SET ist bereits im Internet Explorer 5.0 fest integriert (Start->Systemsteuerung->Internetoptionen->Inhalt->Wallet) und vermutlich auch in Netscape/Firefox! Sofern Dein Browser SET nicht unterstützt, kannst Du Dir ein Plug-IN runterladen.

Gibt es auch im ECash neben SET noch andere Techniken?

Ja!

Es gibt z. B. das CAFE-Projekt, indem verschiedene Länder das Ziel einer elektronischen Geldbörse verfolgen oder das PMTP-Verfahren (elektronisches Online Cash System) zum Schluss sei noch das MPTP -Verfahrengenannt. Ob sich eines dieser Verfahren durchsetzen wird, ist äußerst zweifelhaft und auch nicht unbedingt wünschendwert. Schließlich ist es für den Endverbraucher (User) immer von Vorteil, wenn er nach einem einheitlichen Verfahren Weltweit bezahlen kann.

Fazit!

Gemeinsame Schnittstelle in allen drei großen Bereichen ist das X.509-Zertifikat, welches sich wohl auch mit großer Wahrscheinlichkeit durchsetzen wird. Aus diesem Grund wollen wir auch noch etwas Näher auf dieses Zertifikatsformat eingehen.