Kryptografie und Authentifizierung/Sicherheit läßt sich nicht pauschal gestalten

Security-Strategien für Electronic Commerce am Tatort Internet

10.07.1998

Verfolgt man die Berichterstattung von Tagespresse und Fernsehen, könnte man zu dem Schluß kommen, daß die neue "Wirtschaftsplattform Internet" aufgrund unsicherer Technologie jede Menge kriminelle Energie anzieht. So wird berichtet, daß das Internet und damit auch Electronic Commerce (EC) völlig neue Formen von Industriespionage, Überwachung, Selbstbereicherung, Zerstörungswut hervorbringen und dem Zeitvertreib halbwüchsiger Hobbyhacker, siehe T-Online, dienen. Richtig daran ist, daß das EC-Business analog zur klassischen Geschäftsabwicklung in der Tat ein hohes Maß an Sicherheit voraussetzt, was bislang aufgrund technischer und strategischer Probleme allzu häufig noch in den Hintergrund gedrängt wird.

Sicherheit in diesem Umfeld bedeutet:

-daß der Geschäftspartner der ist, der er vorgibt zu sein (Authentifikation),

-daß elektronische Geschäftsnachrichten ihr Ziel ohne Verzögerung erreichen und rechtsverbindlich sind (Rechtssicherheit),

-daß Daten weder auf ihrem Weg manipuliert noch ausspioniert werden (Integrität, Vertraulichkeit).

Sicherheitsproblemlösungen bieten elektronische Unterschriften, Firewalls, diverse Verschlüsselungsverfahren für E-Mails (zum Beispiel PGP/Mime, S/Mime), Kommunikationsverbindungen (etwa SSL, S-HTTP, PPTP) und Daten (zum Beispiel RSA, IDEA, DES) sowie Trust-Center zur Sicherstellung der Identität.

EC-Sicherheit ist immer prozeßbasiert

EC-Prozesse lassen sich nicht pauschal mit einer Technologie (etwa Kryptographie) sicher gestalten. Erforderlich sind sichere und dynamische Prozeßstrukturen. Sie umfassen neben dem Schutz der Daten (Verschlüsselung) auch die Bereiche der Nachvollziehbarkeit und Rechtsverbindlichkeit elektronischer Geschäftsabläufe (Audit Trail). Hinzu kommen die Sicherstellung der Identität aller Beteiligten mittels elektronischer (Identitäts-)Zertifikate und die elektronische Unterschrift (Authentifikation). Bislang noch vernachlässigt wird die semantische Prozeßsicherheit (sPs), die den korrekten Verlauf einer Prozeßkette, bestehend aus verschiedenen Geschäftstransaktionen, garantiert. Zum Einsatz kommen hierbei unter anderem (signierte) Empfangsbestätigungen, Zeitstempel und intelligente EC-Systeme, die Alarm schlagen, wenn beispielsweise Just-in-time-Lieferabrufe nicht innerhalb einer bestimmten Zeit bestätigt werden, oder automatisch die Nachricht nochmals versenden. Ergebnis sind Secure Transaction Loops, die sich ausschließlich mit der Interaktion von Geschäftspartnern auseinandersetzen. Der Schutz unternehmensinterner Ressourcen durch Firewalls ist hiervon strikt zu trennen.

Standardisierte Secure Transaction Loops existieren bislang für die elektronische Bezahlabwicklung (etwa SET) und werden für EDI von der International Engineering ausgearbeitet (Mime-based Secure EDI). Was sich bei genannten Beispielen als komplex und aufwendig erweist, gestaltet sich bei den anderen EC-Anwendungen wie Händlerinforma- tions-, Helpdesk- oder Shopping-Systemen deutlich einfacher.

Je nach EC-Prozeß werden verschiedene Internet-Technologien eingesetzt, was auch verschiedene Sicherheitsmechanismen bedingt. Es lassen sich fünf EC-Prozeßtypen unterscheiden, die auf dem Austausch von E-Mails und/oder dem Zugriff auf Web-basierte EC-Systeme aufbauen.

Ovum, London, prognostiziert für 2003 für Messaging-Services ein Marktvolumen von mehr als zehn Milliarden Mark, was gemessen an 1996 einer Steigerung um 500 Prozent entspricht. EDI per E-Mail übersteigt hierbei deutlich den interpersonellen Nachrichtenaustausch.

Als alternative Sicherheitsverfahren konkurrieren hierbei das im privaten Sektor sehr verbreitete und kostenfreie PGP/Mime (Network Associates) und S/Mime (RSA). Beide unterstützen sowohl Datenverschlüsselung als auch die elektronische Unterschrift zur Authentifikation. Die Nutzung ist denkbar einfach. Gängige E-Mail-Clients wie Eudora, Outlook oder Messenger unterstützen S/Mime oder PGP/ Mime via Plug-in. Nach Erfassen der E-Mail wird angegeben, ob die Nachricht signiert und/oder verschlüsselt werden soll. Die Codierung erfolgt mit hybriden Kryptosystemen (symmetrische und asymmetrische Verschlüsselung). Der Inhalt wird mit einem dynamisch generierten symmetrischen Schlüssel codiert. Nach der Chiffrierung dieses Schlüssels mit dem Public Key des Empfängers wird er zusammen mit der eigentlichen Nachricht versandt. Der Empfänger dechiffriert mit seinem Private Key den symmetrischen Schlüssel und kann die Nachricht decodieren.

Für die elektronische Unterschrift wird mittels eines bekannten Hash-Verfahrens (zum Beispiel MD5, SHA-1) eine Prüfsumme über die Nachricht/Datei gebildet und mit dem Private Key des Senders verschlüsselt - entweder durch Eingabe eines Paßworts, mittels Chipkarte oder durch biometrische Merkmale (zum Beispiel Fingerabdruck oder Stimme).

Der Empfänger erzeugt seinerseits eine Prüfsumme über die empfangene Nachricht und vergleicht diese mit der elektronischen Unterschrift des Absenders.

Bei EDI erfolgt das Signieren und Verschlüsseln automatisiert anhand eines Partnerprofils. Da bestehende EDI-Systeme vielfach weder das Internet noch die Sicherheitsverfahren unterstützen, muß auf Zusatzpakete ê la "Tempelar" (von Premenos) zurückgegriffen werden.

Was geschieht, wenn elektronisch bestelltes Material nicht oder falsch geliefert wird und der Lieferant behauptet, nie oder zu spät eine Bestellung erhalten zu haben? Sehr schnell können sich Schäden in Millionenhöhe ergeben. Das gängige Sicherheitsverständnis muß hierzu um das Konzept der semantischen Prozeßsicherheit (sPs) erweitert werden, deren Aufgabe es ist, einzelne Transaktionen entsprechend ihrer wirtschaftlichen Bedeutung vor Verlust, Duplizierung und/oder Verzögerung zu schützen. Ferner müssen der zeitliche Ablauf für eventuelle Streitfälle geschäftsprozeßkonform protokolliert und Unregelmäßigkeiten während einer Transaktion rechtzeitig angezeigt werden. Eine Aufgabe, die aufgrund ihrer Individualität zusammen mit erfahrenen EC-Beratern erledigt werden sollte.

Beim EDI-Nachrichtenaustausch durchläuft ein Secure Transmission Loop im Idealfall vier Phasen:

Die Senderorganisation verschlüsselt die EDI-/EC-Daten und ergänzt diese mit ihrer elektronischen Unterschrift, wobei alternativ PGP/Mime oder S/Mime zum Einsatz kommen. Gleichzeitig fordert sie eine signierte Empfangsbestätigung an.

Der Empfänger entschlüsselt die Nachricht und überprüft die Weiterverarbeitbarkeit sowie die elektronische Unterschrift. Ergebnis ist die Sicherstellung der Senderauthentizität und der Datenintegrität (Non-reputation of Origin).

Der Empfänger sendet eine signierte Empfangsbestätigung inklusive einer aus der empfangenen Nachricht erzeugten Prüfsumme.

Der Sender kontrolliert die Prüfsumme mit der der Ursprungsnachricht sowie die elektronische Unterschrift des Empfängers. Ergebnis ist die Sicherstellung der Empfängerauthentizität und der Datenintegrität (Non-reputation of Receipt).

Web-basierte EC-Prozesse

Das Web bildet die Grundlage für Shopping-Systeme, Produktkataloge, Buchungs-, Informationssysteme, Intranet-Anwendungen sowie Web-EDI. Andere Prozeßabläufe und andere Internet-Technologien bedingen auch andere Sicherheitsvorkehrungen.

Bei der elektronischen Bezahlabwicklung existieren ebenfalls Lösungen. Je nach Verfahren kommen unterschiedlichste Sicherheitsverfahren, Sicherheitsinstanzen und Secure Transaction Loops zum Einsatz. Die Analyse bestehender EC-Web-Angebote ist jedoch selbst bei sensiblen Systemen eher ernüchternd. Eine einfache Paßwortabfrage ist unzureichend, um Vertraulichkeit, Authentizität und die Nachvollziehbarkeit der Geschäftstransaktionen zu garantieren.

Mittels signierter E-Mail-Bestätigung läßt sich auch für den Partner ein akzeptables Maß an Rechtssicherheit erreichen. Vertraulichkeit und Authentizität werden zunehmend mit Hilfe von SSL realisiert. Vorteile des Secure-Socket-Layer-Protokolls sind seine einfache Implementierung, und die standardmäßige Unterstützung durch gängige Web-Server und Browser. Auch SSL nutzt hybride Kryptoverfahren, das heißt eine asymmetrische Verschlüsselung zur Authentifikation (Zertifikate) und die schnellen symmetrischen zur Verschlüsselung des Datenstroms. Zu beachten sind die US-Exportbeschränkungen, die die Ausfuhr von Software nur mit einer schwächeren Verschlüsselung (kürzere Schlüssel) zuläßt. Alternativen bieten zum einen Produkte aus anderen Ländern oder die Wahl anderer Kryptoverfahren wie Idea aus der Schweiz.

Nur anhand eines Symbols im Browser (Schlüssel bei Netscape) sowie gegebenenfalls einer Browser-Meldung merkt der Anwender, daß die Kommunikation nunmehr verschlüsselt erfolgt. Das Verfahren ist einfach: Wird auf einen SSL-gesicherten Server zugegriffen, fordert dieser den Browser auf, einen symmetrischen Session Key zu erzeugen, und übermittelt gleichzeitig ein elektronisches Zertifikat mit seiner Identität und seinem Public Key. Der Session Key wird mit dem Public Key des Servers verschlüsselt und übertragen.

Zur Authentifikation des Servers dient das Zertifikat, das eine durch einen Trust-Center beziehungsweise eine Certification Authority (CA) signierte Beglaubigung mit der Identität des Inhabers enthält, inklusive Gültigkeitsdauer, Public Key und Namen des Trust-Center. Im Browser sind die öffentlichen Schlüssel verschiedener (amerikanischer) CAs hinterlegt, so daß die Integrität des Zertifikats und die Authentizität des Servers geprüft werden können. Bei unbekannten CAs fragt der Browser, ob er diese in sein Trust-Center-Verzeichnis übernehmen soll.

Trust-Center sind vertrauenswürdige Instanzen im Internet. Gegen eine Gebühr können sowohl die Public Keys für den Gebrauch von E-Mails als auch die für SSL erforderlichen Server-Zertifikate nach dem X.509-Standard oder PGP-Public-Key hinterlegt und beglaubigt werden. Je nach gewünschter Sicherheitsstufe ist eine einfache E-Mail-Registrierung oder die Vorlage von Personalausweis beziehungsweise Handelsregistereintragungen erforderlich. Bekanntester Vertreter ist der US-Trust-Center Verisign, aber auch in Deutschland wittern immer mehr Unternehmen ein lukratives Geschäft mit der Sicherheit, wobei zunehmend auch Chipkartenlösungen offeriert werden.

Bislang arbeitet noch kein Trust-Center nach dem 1997 verabschiedeten Informations- und Kommunikationsdienstegesetz (IuKDG), das die Anforderungen an offizielle Trust-Center detailliert festlegt. Derzeit laufen mehr als 20 Antragsverfahren. Mit der Betriebsaufnahme erster IuKDG-konformer Trust-Center ist im Herbst dieses Jahres zu rechnen. Ebenfalls strittig ist noch, inwieweit auch die Private Keys im Trust-Center hinterlegt sein müssen (Key Recovery), damit diese bei Bedarf von offiziellen Stellen zur Überwachung herangezogen werden können. Eine staatlich verordnete Zwangshinterlegung ist zumindest im Moment nicht im Gespräch, eine freiwillige Hinterlegung jedoch erwünscht.

EC-Sicherheit ist weder eine Imagefrage noch unnötiger Luxus, sondern existentieller Bestandteil elektronischer Geschäftsabwicklung. Eine Erkenntnis, die sich spätestens im Schadensfall bei den Betroffenen durchsetzt. EC-Sicherheit beschränkt sich nicht auf Technologien, sondern umfaßt zusammenhängende Tansaktionen (Secure Transaction Loops) innerhalb einer Geschäftsabwicklung. Mit unterschiedlichem Erfolg versuchen sich Techniker, Betriebswirtschaftler, Juristen und zunehmend auch Politiker in diesem neuen Terrain, was allerdings häufig unkoordiniert erfolgt.

Es bleibt dem einzelnen Unternehmen überlassen, nicht nur die richtige EC-Strategie auszuwählen, sondern diese mit den bestehenden Möglichkeiten auch sicher zu gestalten. Eine zwingende Notwendigkeit und durchaus realisierbar.

Glossar

Certification Autority (CA): Eine CA Internet-Standard RFC 1422 zertifiziert unter anderem öffentliche Schlüssel von registrierten Benutzern. Das Prinzip: Schlüssel, die verteilt werden sollen, werden zusammen mit Kontrollangaben von der CA mit Hilfe ihres geheimen Schlüssels unterschrieben und in dieser Form als sogenanntes Zertifikat verteilt. Wer einen öffentlichen Schlüssel erfahren will, beschafft sich das Zertifikat, prüft dessen Gültigkeit mit dem öffentlichen Schlüssel der CA, prüft die Kontrollangaben und entnimmt dem Zertifikat den gesuchten Schlüssel.

DES: Data Encryption Inter- change

EDI: Electronic Data Inter- change

Idea: International Data Exchange Association

PGP: Pretty Good Privacy

Policy Certification Autority (PCA): Die Policy Certification Authority gemäß RFC 1422 ist eine Instanz, die mehreren CAs übergeordnet ist und diesen ähnliche Dienste bereitstellt wie CAs für Benutzer.

Revoking: Widerrufen eines Zertifikats. Bevor der Kunde seine Kreditkartendaten übermittelt, muß er via Button auf der Händler-WWW-Page die Gültigkeit des Zertifikats überprüfen. Monatlich werden Revoke-Listen von den TCs/CAs ausgestellt. Revoking bei PGP nur über Web of Trust (Schlüssel-Server) möglich.

RSA: Rivest-Shamir-Adleman, ein Public-Key-Verschlüsselungsalgorithmus

SET: Standard d'Echange et de Transfer

S-HTTP: Secure Hypertext Transfer Protocol

SSL: Secure Socket Layer

Top Level Certification Au- thorities (TLCA): Diese Institutionen zertifizieren die öffentlichen Schlüssel der direkt nachgeordneten CAs und der übergeordneten internationalen beziehungsweise weltweiten Instanzen. Für Europa ist die Interworking Public Key Certification for Europe (ICE) geplant, für das Internet in Betrieb die Internet PCA Registration Authority (IPRA).

Trust-Center: Ein Trust-Center (TC) im EU-Sinne verlangt die Hinterlegung des Private Key beim TC. Eine Certification Authority (CA) verlangt dies nicht.

Asymmetrie

Bei symmetrischen Verschlüsselungsverfahren wie DES, Triple DES, Idea benötigen Sender und Empfänger den gleichen Schlüssel. Als kritisch erweist sich hierbei die Übermittlung der Schlüssel an den Partner, die gesichert erfolgen muß.

Demgegenüber werden bei der asymmetrischen Verschlüsselung mit RSA, Diffie/Hellmann, DSA oder El Gamal für das Ver- und Entschlüsseln unterschiedliche Keys benötigt, das heißt kein Schlüssel ist in der Lage, sowohl eine Nachricht zu ver- als auch zu entschlüsseln, hierzu wird immer der korrespondierende zweite Schlüssel benötigt. Ein Schlüssel (Public Key) wird der Öffentlichkeit frei zur Verfügung gestellt und der andere streng vertraulich behandelt. Die asymmetrische Verschlüsselung wird bei der elektronischen Unterschrift ebenso verwendet wie bei SSL zum Austausch des Session Keys. Gegenüber der symmetrischen ist die asymmetrische Verschlüsselung sehr rechenintensiv und nicht für große Datenvolumen geeignet.

Hybride Kryptosysteme (zum Beispiel SSL, S/Mime, PGP/Mime) bedienen sich der Vorteile beider Verfahren. Die Daten werden mit einem zufällig erzeugten symmetrischen Schlüssel codiert. Er wiederum wird asymmetrisch verschlüsselt zusammen mit der Datei zum Empfänger übertragen.

ANGEKLICKT

EC-Prozesse lassen sich nicht pauschal mit einer Technologie, zum Beispiel Kryptographie, sicher gestalten. Erforderlich sind sichere und dynamische Prozeßstrukturen. Sie umfassen neben dem Schutz der Daten durch Verschlüsselung auch die Nachvollziehbarkeit und Rechtsverbindlichkeit elektronischer Geschäftsprozesse. Hinzu kommen die Sicherstellung der Identität der Beteiligten mittels elektronischer Zertifikate und die elektronische Unterschrift, die den korrekten Verlauf einer Prozeßkette garantiert. Je nach EC-Prozeß kommen unterschiedliche Internet- und Sicherheitstechnologien zum Einsatz.

Rainer Scheckenbach ist Geschäftsführer der Integratio, Gesellschaft für zwischenbetriebliche Integration und Electronic Commerce mbH, in Würzburg.