Steffen Tacke | Tübingen, den 31.01.97 |
Internet und andere Kommunikationsnetze -
ein rechtsfreier Raum?
zum Thema
Identifizierung und Authentifizierung
bei
Prof. H. Ketz
und
RAss. M. Gerblinger
WS 1996/97
von
Steffen Tacke
tacke@student.uni-tuebingen.de(tacke@student.uni-tuebingen.de)
Tübingen
Inhaltsverzeichnis
1. Methoden der Identifizierung und Authentifizierung bei den Standard-Internet-Diensten
1.1 FTP (File Transfer Protokoll)
1.2 UNIX-Login, Telnet und Rlogin
1.3 IRC - Internet Relay Chat
1.4 Electronic-Mail und News
1.5 WWW - World Wide Web
1.6 Zusammenfassung
2. Identifizierung und Authentifizierung aus juristischer Sicht
2.1 Notwendigkeit und gesetzliche Entwicklung der Identifizierung und Authentifizierung im Internet
2.2 Klassisches Einsatzgebiet der Identifikation und Authentifikation im Rechtsverkehr
2.3 Digitale Signaturen im Rechtsverkehr
2.4 Entwicklung des Signaturgesetzes (SigG) und der Signaturverordnung (SigV)
2.5 Kryptoregulierung
2.6 Zusammenfassung
3. Glossar
FTP ist ein Protokoll zur Übertragung von Dateien zwischen zwei Rechnern über das Internet (TCP/IP). Es ist die älteste Methode zur Datenübertragung im Netz(
1
).
Identifizierung
: Um eine Verbindung mit einem zweiten Rechner (Remote-Rechner) zur Datenübertragung aufzubauen, muß man den Namen des zweiten Rechners kennen (entweder die numerische Adresse (IP) wie etwa 134.2.141.10 oder den damit assoziierten Namen hp10.zdv.uni-tuebingen.de). Um eine Verbindung zu dem Rechner ftp.uni-tuebingen.de aufzubauen, gibt man z.B. am UNIX Shell-Prompt folgendes ein:
~
1. Methoden der Identifizierung und Authentifizierung bei den Standard-Internet-Diensten
1.1 FTP (File Transfer Protokoll)
Daraufhin verlangt der Remote-Rechner (FTP-Server) eine Identifizierung in Form einer Login Eingabe:
Connected to softserv.zdv.uni-tuebingen.de.
220-===========================================================
220- ____/__ __/ ____/
220- / / / _/ Eberhard-Karls-Universitaet Tuebingen
220- __/ / ____/ Zentrum fuer Datenverarbeitung
220- / / / Brunnenstr. 27, D-72074 Tuebingen
220-_/ _/ _/
220-
220. Welcome to the Software Server of the University of Tuebingen.
[...]
220 softserv FTP server (Version wu-2.4(8) Wed Feb 21 16:07:29 MET 1996) ready.
Name (ftp.uni-tuebingen.de:):
Hier muß man nun entweder einen eindeutigen Login-Namen eingeben, oder man gibt den (allgemein üblichen) Namen anonymous oder ftp ein und meldet sich somit zum Gastzugang mit, (z.T.) auf wenige Verzeichnisse beschränkten, meist nur leseberechtigten Befugnissen auf dem Remote-Rechner an.
Authentifizierung : Nach dem Login verlangt der Remote-Rechner eine Passworteingabe:
331 Guest login ok, send your complete e-mail address as password.
Password:
Sie dient beim Gast-Zugang nicht unbedingt der Authentifizierung des Login-Namen, da dieser sowieso nur sehr geringe Interaktion auf dem FTP-Server zuläßt (etwa nur den Zugriff auf gewisse Dateien und Verzeichnisse). Normalerweise wird beim Gast-Zugang (Guest-Login) die eigene E-Mail Adresse angegeben, die dann in einer Protokolldatei auf dem FTP-Server mitprotokolliert wird.
Bei einem „Nicht-Gast-Zugang" spielt das Paßwort die Rolle der Authentifikation des Login-Namens und der damit verbundenen Rechte (etwa den Zugriff auf ganz bestimmte Dateien und Verzeichnisse) auf dem FTP-Server. Ein unerlaubter Zugriff auf Daten könnte hier schon verheerenden Schaden anrichten, da man über FTP z.B. mit dem Befehl delete Dateien auf dem Remote-Server löschen, oder sich unberechtigterweise Dateien herunterladen könnte (beispielsweise /etc/passwd s.u.), die wichtige und geheime Daten enthalten. Insgesamt, bietet der FTP nur einen ausreichenden Schutz vor unerlaubtem Eindringen, der vor allem noch durch ein Falschkonfigurieren des FTP-Server oder Verwenden von fehlerhafter FTP-Server Software vermindert wird.
Der UNIX-Login-Mechanismus ist für ein Mehrbenutzersystem (Multi-User-System) unabdinglich, um den verschiedenen Benutzern einzelne Befugnisse, Dateien und Verzeichnisse zuzuweisen. Hinter der Login-Prozedur steckt ein Programm, das beim Starten des UNIX-Systems automatisch aufgerufen wird z.B. UNIX-Login an einem IBM PowerPC mit AIX(=IBM-UNIX) Version 3.2.5:
AIX Version 3
(C) Copyrights by IBM and by others 1982, 1993.
login: tacke
tacke's Password:
Welcome to AIX Version >3.2.5
Last login: Wed Dec 4 18:35:07 MET 1996 on pts/3 from hp10.zdv.uni-tuebingen.de
Identifizierung : Genauso wie bei FTP wird hier nach einem Login-Namen gefragt, allerdings gibt es in der Regel auf UNIX-Rechnern mit Internet Anschluß keinen Gast-Zugang, sondern nur eine begrenzte Zahl an Benutzern, die auf diesen Rechnern z.T. beschränkten Zugriff haben, d.h. eine Eingabe wie anonymous wäre hier sinnlos. Der Login-Name ist wie bei FTP einmalig für jeden User. Normalerweise Stimmen FTP-Login und UNIX-Login bei einem „Nicht-Gast-Zugang" für den selben Rechner überein, da der nonanonymous FTP-Zugang auf dieselbe Art und Weise wie der UNIX-Login intern abgehandelt wird. Der Login-Name ordnet einem Benutzer bestimmte Privilegien zu.
Authentifizierung : Sie spielt hier eine noch wichtigere Rolle wie beim File-Transfer-Protokoll, da man, nachdem man sich im System angemeldet, hat nicht nur Daten manipulieren kann, sondern auch Programme ausführen darf. Man könnte also z.B. bei einem Einbruch in ein UNIX-System, E-Mail in anderem Namen verschicken, wichtige Daten löschen oder unbrauchbar machen, mit einem Editor verändern oder Mithilfe andere Programme das ganze System sabotieren.
Bei der Auswahl des Paßwortes (im Regelfall 8 Zeichen) sollte man sich also auf jedenfall größere Gedanken machen. Die Realität zeigt aber, daß sehr viele Benutzer hier nur sehr wenig Sorgfalt walten lassen, wenn sie z.B. als Paßwort ihren Vornamen, den Nachnamen, das Geburtsdatum oder ähnlich leicht nachvollziehbare Paßwörter benutzten( 2 ). Das ausgesuchte Paßwort wird verschlüsselt und zusammen mit dem Login-Namen in der Datei /etc/passwd abgelegt, die folgendermaßen aussehen kann:
mike:CNjlEZIADBdP6:145:17817:Mike Allison:/home2/mike:/bin/csh
jason:NZErd3xZxPklPE:501:20:Jason Hendrix:/home/jason:/bin/tcsh
tacke:XDghFYD3G5Hx:350:20:Steffen Tacke:/home/tacke:/bin/tcsh
Diese Datei ist normalerweise für jedermann zugänglich und lesbar. Der erste Eintrag ist der Login-Name und nach dem ersten Doppelpunkt steht dann direkt das Paßwort in verschlüsselter Form.
Bei der Neueingabe eines Paßwortes wird dieses in einen 56-Bit langen Wert umgewandelt der als Schlüssel, zusammen mit einem Salt-Wert, in eine Verschlüsselungsroutine (Crypt(3) )eingegeben wird. Der Salt-Wert wird normalerweise von der Zeit, zu der das Paßwort zugewiesen wurde, bestimmt. Am Ende erhält man einen 64-Bit langen Code, der in eine elf-Zeichen lange Zeichenkette umgewandelt wird. Das so chiffrierte Paßwort, wird dann gemeinsam mit der User-ID abgelegt (s.o.). Bei einer Überprüfung eines User, wird wieder anhand seiner User-ID, der Eintrag mit dem verschlüsselten Paßwort gesucht. Aus dem gefunden Paßwort wird der ursprüngliche Salt-Wert gewonnen und mit der Paßwort Eingabe des Benutzers durch die Crypt(3)-Routine verschlüsselt und anschließend mit dem Eintrag in der /etc/passwd -Datei verglichen. Die Verschlüsselungsroutine basiert auf dem DES ( Data Encrytion Standard ( 3 ) ).
Es gibt Programme (z.B. Crack( 4 )) die anhand einer Paßwortdatei und einer größeren Datei mit Wörtern gerade obengenannte Paßwörter sehr effizient herausfinden können: Bei einem Test von ca. 14000 Paßwörtern wurde mit einem ähnlichem Programm wie Crack ca. 25% der Paßwörter erraten( 5 )(nach der Brute-Force Methode, d.h. ausprobieren aller möglichen Kombinationen).
Um diesen Mißbrauch der Paßwortdatei zu verhindern, gibt es die Möglichkeit den Zugriff auf die Datei mit den verschlüsselten Paßwörtern zu verweigern (nur privilegierte Benutzer z.B. Systemadministrator hat Zugriffsrechte), d.h. ein Dritter hat keine Möglichkeit an die verschlüsselten Paßwortdaten zu gelangen. Das erreicht man, indem die Paßwortdatei aufgeteilt wird, in eine Datei, die nur die Paßwort-Informationen enthält und nur für privilegierte Benutzter lesbar ist z.B.:
mike:CNjlEZIADBdP6
jason:NZErd3xZxPklPE
tacke:XDghFYD3G5Hx
und eine Datei ( /etc/passwd ), die restliche Informationen enthält und für alle zugänglich ist:
mike:*:145:17817:Mike Allison:/home2/mike:/bin/csh
jason:*:20:Jason Hendrix:/home/jason:/bin/tcsh
tacke:*:Steffen Tacke:/home/tacke:/bin/tcsh
Der ‘*’ steht als Platzhalter für das Paßwort, daß zum Zeitpunkt der Authentifizierung der User-ID, aus der geschützten Datei gelesen wird.
Telnet und Rlogin( 6 ) (Remote Login) sind 2 Programme für UNIX-Systeme (und andere) in Netzwerken (TCP/IP, Internet), die es einem Benutzer ermöglichen sich auf einem anderen, an das Netz angeschlossenen System einzuloggen. Grundsätzlich führen beide Programme dieselben Verfahren zur Identifikation (Eingabe eines Login-Namen) und zu dessen Authentifizierung (Paßworteingabe) wie die UNIX-Login Abfrage durch.
Ein Sicherheitsproblem das sowohl FTP-Login als auch Telnet und Rlogin Prozeduren haben ist, daß die Paßwörter im Klartext über das Internet übertragen werden, somit muß ein eventueller Angreifer nur das richtige Paket herausfiltern um an Paßwortinformationen heranzukommen.
Das IRC( 7 ) ist „interaktives-Echtzeit-Datenaustauschprogramm", indem Benutzter direkt miteinander kommunizieren können. D.h. man gibt in das Programm eine Zeile ein und diese erscheint dann mehr oder weniger schnell auf den Bildschirmen der angeschlossenen Benutzer. Im IRC gibt es sog. Kanäle (Channels), die themenorientiert sind. Z.B.
#OS/2ger = Channel mit dem Thema rund um das Betriebssystem OS/2
#Linuxger = Channel mit dem Thema rund um das Betriebssystem Linux
#germany - deutschsprachiger Channel ohne bestimmt Topicvorgabe
In diesen Channels befinden sich dann die Benutzer und diskutieren schriftlich (chatten) über alle möglichen Sorgen und Nöte. Es existieren mehrere verschiedene IRC-Netze, denen sich unterschiedliche Server angeschlossen haben z.B. Ef-Net, IRC-Net, Undernet usw.
Durchschnittlich befinden sich ca. 5000 Benutzter im IRC-Net:
Abbildung -1: IRC-Benutzerzahlen im IRC-Net
Und mehr als 12.000 Benutzter im Ef-Net:
Abbildung -2: IRC-Benutzerzahlen im Ef-Net
Identifizierung : Eigentlich gibt es keine sichere Methode um sich im IRC zu identifizieren, da man fast ausschließlich mit Pseudonymen arbeitet. Allerdings erhält man mit einem IRC-Befehl ( /whois <name> , /who <name/channel> , usw.) Informationen über ein jeweiliges Pseudonym. Diese ermöglicht aber keine eindeutige Identifizierung, da es bei den heute gängigen IRC-Software-Lösungen (IRC-Clients) kein Problem (selbst für Laien) darstellt, diese Informationen zu „fälschen". Ein Mechanismus, wie z.B. die Paßwortabfrage bei UNIX, existiert nicht. Dementsprechend gibt es keine Garantie für die Echtheit der übermittelten Daten, bzw. die Möglichkeit andere Personen eindeutig zu identifizieren( 8
1.4 Electronic-Mail und News
Seit der Gründung des Internet( 9 ) ist das Versenden elektronischer Nachrichten immer noch einer der am meisten genutzten Dienste( 10 ). Vor allem E-Mails mit privatem oder wissenschaftlichem Inhalt werden verschickt, aber auch Nachrichten mit kommerziellem Inhalt werden von immer größerer Relevanz. Daher wird es immer wichtiger, daß der E-Maildienst Möglichkeiten bietet um aktive Angriffe (z.B.: Unterbrechungen, Modifikationen und Erzeugung falscher Nachrichten) und passive Angriffe (z.B.: Abfrage von Nachrichteninhalten und Analyse des Nachrichtenverkehrs) abzuwehren.
Eine E-Mail besteht aus zwei Basiskomponenten: die Kontrollinformation (Header) und der Inhalt (Body, Text). Die Kontrollinformation enthält Daten über die Herkunft (From), das Ziel (To), den Transport (normal oder eilig/Priority), sowie einen Absenderverweis (Reply-to), ein Thema der Nachricht (Subject), und ein paar weitere, hier nicht behandelte Einträge:
From: John Doe <John.Doe@zdv.uni-tuebingen.de>
To: Jane Doe <Jane.Doe@zdv.uni-tuebingen.de>
Date: Fri, 06 Dec 96 16:06:17 +0200
Reply-To: John Doe <John.Doe@zdv.uni-tuebingen.de>
Priority: Normal
X-Mailer: John Doe´s Registered PMMail 1.53 For OS/2
Subject: Mensaessen
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable
Im Inhalt steht dann die eigentliche Nachricht.
Identifizierung : Die Identität des Empfängers und Absenders gehen beide aus dem Nachrichten-Header hervor ( From - und To -Feld) hervor. Das Format der Adressen( 11 )ist eindeutig festgelegt und dient der Identifizierung eines bestimmten Benutzers ( John.Doe ) einer bestimmten Organisation ( zdv.uni-tuebingen.de) . Da die Nachricht im Klartext normalerweise über das SMTP( 12 )verschickt wird und dabei u.U. etliche Rechner durchlaufen muß, auf denen die E-Mail zumindest kurz im Speicher oder auf der Festplatte liegt, besteht hier die Möglichkeit von Angriffen (entweder mutwillig oder durch Software/Hardware-Fehler). D.h. ein Dritter könnte z.B. eine E-Mail in einem anderen Namen schicken (z.B. kann man mit Netscape den Namen des Absenders eintragen, welcher später in der E-Mail erscheint) oder die ursprüngliche Absenderadresse verändern. Der Empfänger wäre dann ohne sehr genaue Kenntnisse über den Aufbau des Headers nicht in der Lage den wahren Absender eindeutig zu identifizieren.
Authentifizierung : Die eindeutige Zuordnung einer Nachricht zu einem Absender ist bei der Standard Nachrichtendienstimplementierung auf den Rechnern und der Übermittlung über das Internet aus den oben genannten Gründen nicht gegeben. Sehr häufig wird der E-Mailverkehr mit dem Versenden von Postkarten mit der normalen Post verglichen. Auch hier kann nicht davon ausgegangen werden, daß sie niemand ließt, bzw. verfälscht, oder gar ganz verschwinden läßt. Deshalb wurden zusätzliche Programme mit kryptografischen Verfahren entwickelt um einen sicheren Datenaustausch zu garantieren und gleichzeitig eine eindeutige und leicht nachvollziehbare Möglichkeit der Identifizierung und Authentifizierung des Absenders und der Nachricht zu gewährleisten.
Eines der am weitverbreitetsten Programm zur sicheren Übertragung von E-Mails und zur Erzeugung von digitalen Signaturen ist das von Philip Zimmermann entwickelte PGP. Das Programm ist für Privatpersonen und Bildungseinrichtungen kostenlos u.a. über FTP erhältlich( 13 ). Bei kommerzieller Nutzung außerhalb der USA muß das IDEA-Verfahren lizensiert werden( 14 ). PGP verwendet zur Verschlüsselung (encrypting) einer Nachricht den IDEA-Algorithmus mit einem einmaligen Sitzungschlüssel, für die Erzeugung einer Prüfsumme den MD5-Algorithmus und zur Verschlüsselung des IDEA-Sitzungsschlüssels und der Prüfsumme das Public-Key Verfahren nach RSA.
Der Algorithmus basiert auf dem symmetrischen Verschlüsselungsverfahren wie z.B. auch DES( 16 ). Eine Nachricht wird mit einem festen (128-bit langen) Schlüssel chiffriert und anschließend übermittelt, d.h. man müßte 2 128 Schlüssel (im Gegensatz zu „nur" 2 56 bei DES, der nach heutigem Stand als nicht mehr sicher gilt) ausprobieren um IDEA zu knacken. Der Empfänger kann jetzt Mithilfe desselben Schlüssels die Nachricht dechiffrieren und lesen. Beide (Absender und Empfänger) müssen sich zuvor über ein Schlüssel bzw. Schlüsselpaar geeinigt haben und die jeweiligen Schlüssel geheimhalten. Dies ermöglicht neben Abhör- und Manipulationssicherheit auch die Authentifizierung des Absenders und Empfängers, da nur er den jeweiligen Schlüssel zur Chiffrierung bzw. Dechiffrierung haben kann. Der IDEA-Algorithmus gilt i.A. als sehr sicher solange die Schlüssel geheim gehalten werden.
Abbildung -3: IDEA-Anwendung auf eine Nachricht
Der MD5-Algorithmus( 17 ) dient zur Erzeugung einer fälschungssicheren Textprüfsumme (auch MAC( 18 ) genannt). Aus einer Nachricht wird anhand der Hash-Funktion ein Hash-Code mit der Länge von 128 Bits bestimmt. Diese Einwegfunktion bildet eine große Menge von Funktionsargumenten möglichst gleichmäßig auf eine vergleichsweise kleine Menge von Funktionswerten ab. Der Hash-Code ist eine Zahl, die auch nur bei der kleinsten Veränderung des Ursprungstextes nicht mehr übereinstimmen würde, d.h. wenn der Empfänger den Hash-Code des Urpsrungstextes hat, kann er damit die Unversehrtheit des Inhaltes der Nachricht überprüfen. Da die Hauptgefahr der Manipulation an einer Nachricht gerade bei der Übermittlung besteht, kann man entweder den Hash-Code über einen sicheren bzw. vertrauenswürdigen dritten Weg übermitteln, was aber den Sinn eines solchen Codes in Frage stellt, da man ja sofort die ganze Nachricht über den dritten Weg transferieren könnte, oder man bedient sich hier Verschlüsselungsverfahren, um den Hash-Code mit der Nachricht fälschungssicher zu kombinieren.
Abbildung -4 MD5 Verwendung beim der Nachrichtenübermittlung
Das RSA-Verfahren( 19 ) ist das bekannteste asymmetrische Public-Key-Verfahren. Bei diesem Verfahren besitzt jeder Teilnehmer einen Public- und einen Secret-Key. Teilnehmer A kann nun Mithilfe des Public-Key des Empfängers B eine Nachricht so verschlüsseln, daß nur B sie mit Hilfe seines Secret-Key entschlüsseln kann. Dadurch wird sichergestellt, daß nur B die Nachricht lesen kann. Wichtig bei diesem Verfahren ist, daß sich der jeweilige Secret-Key nicht aus dem Public-Key erzeugen läßt. D.h. aber, hat A einmal seine Nachricht mit dem öffentlichen Schlüssel des Empfängers verschlüsselt kann selbst er sie nicht mehr entschlüsseln, weil ihm der nötige Private Schlüssel des Empfängers fehlt (darin liegt die Asymmetrie des Verfahrens). Die Sicherheit des Verfahrens basiert auf der relativ schweren Zerlegung einer großen Zahl in deren Primfaktoren. Letztendlich ergibt sich daher die Sicherheit aus der Schlüssellänge( 20 ):
Sporadisch |
426 Bits Schlüssellänge |
bekannt, als mit großem Aufwand entschlüsselbar( 21 ) |
Kommerziell |
512 Bits Schlüssellänge |
gilt als unentschlüsselbar, wobei es nicht sicher ist, in wie fern die verschiedenen Geheimdienste (CIA, FBI, BND, KGB usw.) diese Nachrichten bereits entschlüsseln können. |
Militärisch |
1024 Bits Schlüssellänge |
wird allgemein als unentschlüsselbar angesehen |
Randbemerkung: Im Vergleich: Um einen IDEA-Schlüssel der Länge von 128 Bit zu knacken (also durchprobieren aller 2 128 Möglichkeiten) benötigt man den selben Rechenaufwand wie beim Faktorisieren eines 3100 Bit Langen RSA-Schlüssel. Der Rechenaufwand um zwei Nachrichten mit dem selben Hash-Code zu erzeugen liegt bei ca. 2 64 Rechenoperationen und um zu einem gegebenem Hash-Code eine Nachricht herzustellen bei ca. 2 128 Operationen( 22 ). Bei DES werden durchschnittlich 2 55 Rechenschritte benötigt.
Zur Erzeugung einer digitalen Signatur gibt es bei dem RSA-Algorithmus die Möglichkeit eine Nachricht zu ‘unterschreiben’: Hierzu kann der Absender einer Nachricht diese mit seinem privaten Schlüssel codieren, und jeder Empfänger kann die Echtheit des Absenders dadurch prüfen, daß er versucht, die Nachricht mit dessen öffentlichen Schlüssel zu decodieren. Wenn dies gelingt, ist der Absender verifiziert, also die Nachricht eindeutig zugeordnet. Der Vorteil der digitalen Signatur gegenüber der herkömmlichen ‘handschriftlichen’ Signatur unter ein Dokument oder Brief ist, daß eine Verifizierung der Signatur schon fehlschlägt, wenn an dem elektronischen Dokument etwas verändert wurde. Die Kombination aus beidem (einsetzten der digitalen Signatur und der Verschlüsselung mit dem öffentlichen Schlüssel des Empfängers) bietet den zur Zeit besten, verfügbaren Schutzmechanismus für den elektronischen Nachrichtenverkehr.
Mit den beschriebenen Verfahren aus 1.-3. Läßt sich jetzt die Funktionsweise von PGP erklären( 23 ):
Erläuterung: Schritte b.) und m.) (jeweils korrespondierende Schritte) dienen dazu, die Unversehrtheit der Nachricht beim Empfänger zu garantieren. Hinter den Schritten c.) und l.) verbirgt sich die Erzeugung der digitalen Signatur bzw. deren Überprüfung beim Empfänger. Das digitale Signierungsverfahren nach RSA wird nur auf den Hash-Code angewandt, weil eine Verschlüsselung und anschließende Entschlüsselung Mithilfe des RSA-Verfahrens sehr zeitaufwendig ist. Aus dem selben Grund, wird auch in den Schritten d.), e.), f.) und g.) die eigentliche (komprimierte) Textnachricht ‘nur’ nach IDEA verschlüsselt und anschließend der IDEA-128 Bit Schlüssel nach dem RSA-Verfahren (mit dem Publik-Key des Empfängers) codiert. Durch die Benutzung aller Schritte a.) bis m.) garantiert PGP ein höchstmögliches Maß an Sicherheit beim Umgang mit der elektronischen Nachricht.
Die einzige Schwachstelle die jetzt noch auftauchen kann, ist die Übermittlung der Öffentlichen Schlüssel an den jeweiligen Partner. Problematisch ist hierbei, daß jemand diesen Schlüssel abfangen und fälschen kann, ohne daß es der jeweilige Kommunikationspartner herausfindet. Aber auch hierfür wurde in PGP ein Mechanismus eingebaut, mit dem man anhand eines sicheren Übertragungsmediums die Echtheit des jeweiligen Schlüssels überprüfen kann. PGP kann zu einem öffentlichen Schlüssel einen Fingerabdruck (Fingerprint) erzeugen, bestehend aus 16 zweistelligen Hexadezimal-Zahlen, der mit sehr hoher Wahrscheinlichkeit (ähnlich wie bei MD5) eindeutig ist. Beide Partner können nun anhand dieses Fingerabdrucks und eines sicheren Kanals (z.B. Telefon, persönliches Treffen usw.) die jeweiligen öffentlichen Schlüssel verifizieren.
PEM wurde entworfen und als Internet-Standard vom Internet Activities Board (IAB) vorgeschlagen. Es erlaubt den Einsatz von symmetrischen und asymmetrischen Kryptosystemen zur Verschlüsselung, Authentifizierung und zum Schlüsselmanagement. Die verwendeten Algorithmen und Formate sind u.a. DES, RSA und X.509 für Zertifikate.
Für jede E-Mail werden die Algorithmen zur Verschlüsselung und digitalen Unterschrift, sowie die verwendeten Einweg-Hashfunktionen im Nachrichtenkopf spezifiziert. Die Einzelheiten des PEM-Standards können in den Request for Comments (RFCs) 1421 bis 1424 gefunden werden. Hier soll nicht näher darauf eingegangen werden, da die benutzten Verfahren (bis auf die Verifizierung des öffentlichen Schlüssels) denen von PGP sehr ähnlich sind.
Das X.509 Format wird zur Zertifizierung des öffentlichen Schlüssels eines Public-Key-Kryptosystems wie RSA. Ein solches Zertifikat dient zur Absicherung, daß ein bestimmter öffentlicher Schlüssel tatsächlich zu einer gegebenen Person oder Behörde gehört und enthält folgende Komponenten: Zertifikatseriennummer, Name der unterschreibenden Autorität, Name des Besitzers des öffentlichen Schlüssels, Gültikeitszeitraum des öffentlichen Schlüssels, den öffentlichen Schlüssel selbst und die Unterschrift der ausstellenden Autorität. Konzeptionell läßt jeder Benutzter seinen öffentlichen Schlüssel von einer übergeordneten, vertrauenswürdigen Zertifizierungsinstanz mit deren privaten Schlüssel signieren (dazu gehören alle oben genannten Daten). Der so signierte Schlüssel kann nun von jedem anderen Benutzer verifiziert werden, welcher den öffentlichen Schlüssel der Zertifizierungsinstanz hat. Ein Zertifikat stellt also eine eindeutige Verbindung zwischen Identität des Benutzers und seinem öffentlichen Schlüssel dar. Die Instanzen sind hierarchisch (baumförmig) aufgebaut. Die Wurzel eines solchen Zertifizierungssystems bildet z.B. die IPRA (Internet Policy Regitration Authority( 25 )), welche von der Internet Society betrieben wird.
Für elektronische Mails, die in sog. Newsgroups im Usenet (ein Dienst des Internets, der sich mit der themenorientierten Verteilung von öffentlichen Nachrichten befaßt) veröffentlicht werden, gilt dasselbe, in Bezug auf Sicherheit und insbesondere Absenderidentifikation und Authentifikation, wie bei privaten E-Mails. Grundsätzlich lassen sich hier die gleichen Mechanismen zur Verbesserung der Sicherheitssituation wie bei den E-Mail-Systemen einsetzten (also etwa PGP), allerdings spielt die eigentliche Verschlüsselung eine kleinere Rolle. Die Möglichkeit zur Erzeugung einer digitale Signatur (RSA), zur Sicherstellung der Unverfälschtheit (MD5) und zur eindeutigen Identifizierung eines Absender sind hier maßgebend.
Das WWW ist eine verteilte Multimediaumgebung, die im Internet zu einem enormen Zuwachs an Benutzern geführt hat. Es beeinflußte die Entwicklung des Internet und verhalf ihm zu seiner jetzigen Popularität. Auch die wachsende Kommerzialisierung des Internet basiert zumeist auf dem WWW. Es besteht großes Interesse daran, die Sicherheit im Web zu erhöhen, um auch geschäftliche und firmeninterne Transaktionen zu ermöglichen.
Da über das WWW nicht nur reine Textnachrichten übermittelt werden und es vorrangig auf Just-in-Time Transaktionen angewiesen ist, sind Methoden wie sie bei den elektronischen Nachrichten zum Einsatz kommen hier nicht ohne weiteres einsetzbar. Die größte Bedeutung bei sicheren Transaktionen im WWW hat zur Zeit die Übermittlung von Kreditkartennummern bei Warenbestellungen (Shopping in the Net) und in naher Zukunft (bzw. jetzt schon von der Deutschen Bank( 26 ) realisiert) das Online-Banking wie man es aus dem T-Online-System (ehemals BTX, Datex-J) bisher kennt.
Das HTTP (Hyper Text Transfer Protocol) bildet seit 1990 die Basis für das World Wide Web. Es benutzt wie Telnet, Rlogin, FTP usw. (s.o.) eine TCP/IP-Verbindung (oder einen anderen verbindungsorientierten Netzwerkdienst) zum Austausch der Daten und wird daher im ISO/OSI (International Standards Organisation/Open System Interconnection)-Modell in der Anwendungsschicht (7) eingeordnet. In der Version 1.0 des HTTP-Standard gibt es bereits Passwort-Mechanismen zur Authentifizierung eines bestimmten Benutzers beim Zugriff auf bestimmte Dokumente. Jedoch wird (wie bei Telnet und Rlogin) auch hier das Paßwort (uuencoded) im Klartext übertragen.
Eine weitaus bessere Methode ist die Verwendung der SHTTP-Spezifikation( 27 ) (Secure HTTP). SHTTP erweitert das gängige HTTP um verschiedene Sicherheitsmechanismen, und um digitale Unterschriften, Authentifikation bzw. Zertifizierung und Verschlüsselung zu ermöglichen. Die Spezifikation legt sich nicht auf nur ein Verfahren fest, sondern vielmehr können die Client und Server-Implementierungen sich auf Verwendung gewisser Algorithmen einigen. SHTTP kann auf eine Zertifizierungsinfrastruktur verzichten, weil Client und Server nicht unbedingt auf ein Public-Key-Verfahren zurückgreifen müssen. Dies ermöglicht spontane private Transaktionen. Jede Nachricht kann unterschrieben, authentifiziert und/oder verschlüsselt sein, oder eine beliebige Kombination daraus. Wenn die digitale Unterschrift angewendet wird, kann diese mit den Bestätigungsinformationen entweder an das Dokument angehängt werden, oder es wird vom Empfänger erwartet, daß er sich die Informationen zur Überprüfung der Unterschrift selbst besorgt. Bei Verwendung von symmetrischen Verschlüsselungsverfahren ist der Austausch von Sessionkeys vorgesehen, die in einer voran gegangenen Transaktion ausgetauscht wurden.
Zur Unterstützung der Verschlüsselung definiert SHTTP u.a. Mechanismen die denen von PGP sehr ähnlich sind, d.h. z.B. wird ein symmetrischer Sessionkey zur Verschlüsselung großer Nachrichten verwendet. Der Key wird dann mit dem öffentlichen Schlüssel des Empfängers nach dem Public-Key-Verfahren verschlüsselt und mit der Botschaft übertragen. Auch die Überprüfung der Nachrichtenintegrität funktioniert ähnlich wie bei PGP und PEM: ein sogenannter Message Authentication Code (MAC) wird mit einem gemeinsamen Schlüssel chiffriert und übermittelt.
Ein anderes Sicherheitsverfahren im WWW stellt die Benutzung des SSL (Secure Socket Layer Protocol) dar. SSL ist im ISO/OSI-Modell auf Schicht 5 einzuordnen und ist damit unabhängig von der Applikationsschicht, d.h. es kann auch für andere Applikationen/Protokolle (z.B. Telnet, SMTP,FTP) verwendet werden.
SSL wurde von Netscape Communications Inc.( 28 ) als offener Standard entwickelt und bietet Unterstützung für Server Authentifizierung, Privatsphäre durch Verschlüsselung und Nachrichtenintegrität. Ein gesicherter Übertragungsweg wird durch den Protokolldesignator ‘HTTPS:’ angezeigt und ermöglicht z.B. die sichere Übermittlung von Kreditkarteninformationen. Zur Verschlüsselung werden zur Zeit die RC2, RC4( 29 ), DES und IDEA-Algorithmen eingesetzt und zur Überprüfung der Nachrichtenintegrität die Verfahren nach MD2( 30 ) und MD5.
Der Nachteil von SSL besteht in der bis jetzt noch sehr geringen Verbreitung, d.h. nur die Firma Netscape C. Inc. hat eine Unterstützung in ihre Produkte integriert. Das liegt unter anderem darin, daß die ursprüngliche in SSL vorgesehene Schlüssellänge von 128 Bit unter das Waffenexportgesetz der USA fällt und somit nicht exportiert werden darf. Allerdings existiert eine ‘40 Bit-Variante’ für den Internationalen Markt, die aber heute gängigen Sicherheitsmaßstäben nicht mehr gerecht wird (40 Bit lange Schlüssel wurden zu Demonstrationszwecken bereits gebrochen( 31 )).
Auf weitere technische Details( 32 ) soll hier nicht näher eingegangen werden, da sie den Rahmen der Arbeit sprengen würde.
Weder FTP, Telnet oder Rlogin noch der UNIX-Standard-Login bieten einen ausreichenden Schutz vor unerlaubtem Zugriff durch Unbefugte. Die eingesetzten Paßwortmechanismen und Algorithmen zur Benutzeridentifizierung und Authentifizierung sind in einer Netzwerkumgebung ein zu großes Sicherheitsrisiko und erfordern zusätzliche Mechanismen der Sicherung, z.B. durch Chipkarten, Gesichts- oder Stimmanalysen für den Computerzugang und Mechanismen für die sichere Übertragung von vertraulichen Informationen über ein Netzwerk.
Nachrichtendienste und das WWW bieten in ihren Standardimplementierungen (SMTP, NNTP, HTTP/1.0) keinen Schutz (mit Ausnahme von HTTP/1.0, das in seiner Anwendung eine Paßwortabfrage für bestimmte Dokumente vorsieht, dabei wird aber das Paßwort im Klartext über das Netz übertragen). Jedoch existieren Programme und Erweiterungen (PGP, PEM, SHTTP, SSL) basierend auf starken kryptographischen Verfahren, die einen annähernd sicheren Datenverkehr und eine eindeutige Identifizierung und Authentifizierung zulassen. Leider fehlt es z.T. noch an der weiten Verbreitung (PEM, SHTTP, SSL) bzw. am Bedienungskomfort (PGP - rein kommandozeilenorientiert) der Programme, um sie täglich einzusetzen.
Insgesamt bieten die z.T. seit mehr als 20 Jahren erprobten Verfahren der Kryptographie technisch ausgereifte Möglichkeiten der Identifizierung, der Authentifizierung und der sicheren Datenübertragung. Nur das Einbetten in bisherige Standardsoftware bzw. eine gelungene Benutzerführung bremsen z.Z. noch den großflächigen Einsatz zur kommerziellen Nutzung des Internet. Im weiteren ergeben sich aus den technischen Möglichkeiten juristische Probleme, die vor allem anhand von digitalen Signaturen hier verständlich gemacht werden sollen.
Zurück
zum Inhaltsverzeichnis
Der Bedarf an rechtlichen Grundlagen, um die Kommerzialisierung des Internet d.h. die Nutzung des Internet für kommerzielle Zwecke voranzutreiben steigt mit den enorm anwachsenden Benutzerzahlen. Es ist streitig und nicht auf alle rechtlichen Bereiche übertragbar, ob geltendes Gesetz auf die juristischen Fragestellungen die das Internet aufwirft ohne Veränderung angewandt werden kann, oder ob neue Regulierungen nötig sind. Im Bereich der Identifikation und Authentifikation spielen dabei die elektronischen Darstellungen von Dokumenten und ihre leichte, nicht nachvollziehbare Manipulationsmöglichkeit eine wichtige Rolle in der juristischen und politischen Diskussion der letzten zwei Jahre. Verbunden damit sind etwa das Eingehen und die Gültigkeit von Verträgen über das Internet, die Beweiskraft elektronischer Dokumente und die Sicherheit im Rechtsverkehr über ein elektronisches Medium wie das Internet. Weil digitale Signaturen sehr eng mit Verschlüsselungsmethoden verbunden sind, ist die Frage nach einer umfassenden Regulierung zur Anwendung von kryptographischen Algorithmen sehr nahestehend.
Die Rechtsordnung orientierte sich bis jetzt sehr stark an dem Medium Papier und geht nur sehr langsam und zögernd auf neue Informations- und Kommunikationstechniken ein(
33
). Identifizierung erfolgt zumeist (z.B. auf einem Vertrag) durch namentliche Erwähnung von Personen (der Vertragsparteien). Eine Authentifizierung der Identitäten geschieht dann mit der eigenhändigen Unterschrift eines Dokumentes. Zugleich kennzeichnet die Unterschrift den Abschluß eines Rechtsgeschäftes bzw. eine inhaltliche Zuordnung eines Dokumentes zu einer oder mehreren Personen. Die eigenhändige Unterschrift erfüllt folgende Funktionen(
34
):
-Die Abschlußfunktion, d.h. die Unterschrift bezeichnet den Abschluß einer Willenserklärung.
-Die Echtheits- und Identitätsfunktion, beweisen die Herkunft einer Erklärung und die Identität des Austellers.
-Die Warnfunktion, soll den Unterzeichner vor Übereilung schützen.
-Die Beweisfunktion, soll im Streitfall eine Beweisführung vor Gericht vereinfachen und resultiert aus den vier vorangegangenen Funktionen.
Diese Funktionen kennzeichnen einen über Jahrhunderte gewachsenen Unterschriftenbegriff, der in fast allen Rechtsgebieten zum Einsatz kommt.
Zwischen Banken und deren Großkunden erfolgen Geldtransfers schon seit längerem auf fast vollständigem elektronischen Weg unter der Verwendung des Standards „Electronic Data Interchange (EDI)(
35
)". Dort werden täglich millionenfach Bestellungen, Lieferscheine, Rechnungen, Mahnungen und standardisierte Geschäftsbriefe rein elektronisch ausgetauscht. In Zukunft sollen solche Transaktionen auch in Behörden und Unternehmen verwendet werden, um den Schriftverkehr maßgeblich zu beschleunigen und um einen Medienbruch(
36
) zu vermeiden. Die Hauptfrage die dabei auftritt ist, ob solche Transaktionen auch für den Rechtsverkehr genutzt werden können. Aufgrund der Beeinflussung von elektronischen Dokumenten können sie kaum Beweis für eine Willenserklärung sein und sind deshalb der Rechtsordnung nicht angepaßt und zu unsicher. Des weiteren fordert die Rechtsordnung aus unterschiedlichsten Gründen verschiedene Schriftformen. Die Schriftform nach §126 BGB kann nach h.M. von elektronischen Dokumenten nicht erfüllt werden(
37
).
Die Teilnehmer des EDI können sich notdürftig aus dieser Mißlage durch vertragliche oder organisatorische Vereinbarungen helfen. Allerdings drängt das Internet (und andere Formen der Nutzung moderner elektronischer Transaktionsmechanismen) mehr dazu, ein System für geschäftliche Gelegenheitskontakte für jedermann zu schaffen. Mithilfe von den oben beschriebenen Public-Key-Systemen wäre es denkbar ein elektronische Dokument mit Sicherheitsaspekten, Formäquivalenz und Beweisechtheit auszustatten. Die dadurch zum Einsatz kommenden digitalen Signaturen realisieren u.a. ein versiegeln des Textes und eine eindeutige Identifizierung des Signierenden und somit einen entscheidenden Sicherheitsgewinn. Um ausreichende Sicherheitsvorkehrungen bei dem Public-Key-Verfahren zu treffen wird ein Schlüsselpaar automatisch und geheim berechnet. Der öffentliche Schlüssel wird in einem öffentlichen Verzeichnis aufgenommen und der geheime Schlüssel auf einer Chipkarte gespeichert, die gegenüber Unberechtigten mit einer PIN (Personal Identification Number) geschützt ist. Weiterhin braucht man für eine funktionierende Infrastrukur auf diesem Gebiet einen sogenannten „vertrauenswürdigen Dritten" (Third Party Trust) , der durch ein Zertifikat (z.B. X.509 Format, s.o.) bestätigen kann, daß ein Schlüsselpaar zu einer bestimmten Person gehört. Darauf aufbauend bildet sich dann eine Zertifizierungshierarchie, wobei jede untergeordnete Instanz durch deren übergeordnete zertifiziert wird. Diese Sicherungsinfrastrukur garantiert den reibungsfreien Einsatz der digitalen Signaturen, auch bei Ausfall einzelner Zertifizierungsinstanzen. Eine solche Sicherungsinfrastruktur befindet sich z.B. beim Individual Network e.V.(
38
) und bei der Telekom Projektgruppe Telesec(
39
) in Vorbereitung.
Eine Studie über die „Verletzlichkeit und Verfassungsverträglichkeit rechtsverbindlicher Telekooperation" von PROVET e.V.(
40
) und dem Institut für Tele-Kooperations-Technik der Gesellschaft für Mathematik und Datenverarbeitung (GMD(
41
)) kommt zu dem Ergebnis(
42
), daß eine breite Einführung digitaler Signaturen im Rechtsverkehr nur dann zustande kommt, wenn:
Durch die technischen Voraussetzungen der digitalen Unterschrift ist unbemerktes verändern eines digital signierten Dokumentes nicht möglich. Dies erfüllt im Vergleich zur eigenhändigen Unterschrift die Abschluß- und Echtheitsfunktion. Das Zertifikat der Vertrauensinstanz, in dem der Name des Karteninhabers enthalten ist, garantiert die Identitätsfuntkion.
Bei der Warnfunktion kommt es sehr darauf an, wie das digitale Signieren in einem konkreten Programm umgesetzt wird. Dies steht vor allem im Konflikt mit der transparenten Benutzerführung vieler Programme, die den Benutzer in der Handhabung unterstützen sollen. Wenn ein Signieren etwa nur mit einem „Mausklick" erledigt wird, hat dies den Warncharakter vor einem übereiligen Abschließen einer Willenserklärung verfehlt(
43
). Es muß also eine deutliche Trennung zwischen einem schlichten Computerbefehl und dem Signieren einer Willenserklärung sein.
Die Beweisfunktion erfüllt die Signatur dadurch, daß ein elektronisch unterschriebener Text nicht unbemerkt verändert, der Karteninhaber über das Schlüsselverzeichnis identifiziert und die technische Sicherheit des Verschlüsselungsverfahrens nachgewiesen werden kann(
44
).
Ganz anderer Meinung ist Frank Ebbing(
45
), der von einer Identitätsfunktion der digitalen Signatur nicht überzeugt ist, da sie nicht den Namen des tatsächlichen Ausstellers wiedergibt, sondern nur Rückschlüsse auf die Person des Versenders zuläßt. Ebensowenig ist er von der Beweis- und Abschlußfunktion überzeugt, weil er der Ansicht ist, daß elektronische Signaturen unter jeder Art von Versendung einer Nachricht einhergeht und somit auch unter unvollständige Texte und Entwürfe geleistet wird. Weiterhin bezweifelt er ob mit der elektronischen Signatur das Bewußtsein der Abgabe einer rechtsgeschäftlichen Erklärung verbunden werden kann. Die von F. Ebbing genannten Gründe gegen die digitale Signatur hängen aber (wie er auch selbst andeutet) sehr stark von der technischen Umsetzung und der Benutzerpraxis ab. Den besonderen Wert der digitalen Signatur sieht er in der Erleichterung der Beweisführung über die Abgabe einer Willenserklärung.
Elektronische Dokumente verkörpern keine Gedankenerklärung, denn Dateien, in denen sie gespeichert werden, sind flüchtig. Ein Ausdruck von elektronischen Dokumenten ist nur deren Abbild. Weiterhin sind sie nicht aus sich selbst heraus verständlich, weil ein elektronischen Dokument nicht unmittelbar -ohne technische Geräte- wahrgenommen werden kann(
46
). Die Echtheit des Dokuments im Zusammenhang mit der digitalen Signatur kann nur von bestimmter Prüfsoftware nachgewiesen werden. Aus diesen Gründen folgt, daß elektronisch signierte Dokumente nicht als Urkunden im Sinn der Prozeßordnung (§416 ZPO) anerkannt werden können. Das bedeutet, daß der Beweiswert von elektronischen Dokumenten geringer ist, wie der von Papierdokumenten(
47
) bzw. handschriftlich unterzeichneten Urkunden, deren Funktion es sein soll, die Beweisführung vor Gericht zu vereinfachen.
Als Beweismöglichkeit bietet sich für elektronische Dokumente der Augenschein des Gerichts an, sich also durch die Betrachtung des Dokumentes und der Überprüfung der digitalen Unterschrift von dessen Echtheit und Herkunft ausreichend zu überzeugen. Dafür wird regelmäßig ein Sachverständiger erforderlich sein, der schon alleine wegen den hohen Kosten ein Hindernis für das Durchsetzen von elektronischen Unterschriften sein kann. Die Einbettung der Signaturen in technische und soziale Anwendungsbedingungen führen zu vielen Unsicherheiten im Umgang mit ihr und verhindern somit ein Anwenden des Urkundsbeweises bei elektronisch signierten Dokumenten. Unsicherheiten entstehen etwa im unbeaufsichtigten liegen lassen der Chipkarte. Auch die Verwendung einer PIN zur Sicherung der Chipkarte ist für sensitive Anwendungen ungenügend, da diese erspäht, entlockt oder entwendet werden kann. Manipulationen schwerwiegender Art wären, das Unterschieben von Dokumenten auf verschiedenste Art und Weise, was bei der elektronischen Datenverarbeitung um ein vielfaches leichter ist, als bei der Handhabung von Papierdokumenten. Ein anderer beweisrechtlich kritischer Punkt wäre das zurückdatieren eines elektronisch signierten Dokumentes. Dies kann nur verhindert werden, wenn die echte Zeit in gesicherter Weise in die Signatur mitversiegelt wird, jedoch erfordert dies einen enormen technischen Aufwand. Die genannten Gründe verhindern ein unmittelbares (de lege lata) Anwenden der Beweisregel für Urkunden auf elektronisch signierte Dokumente. Die Einführung eines elektronischen Dokumentenbeweises de lege ferenda würden gesetzliche Regelungen in Bezug auf die Voraussetzungen und Rechtsfolgen für eine an dem Stand der Technik orientierte Risikoverteilung nötig machen. D.h. durch technische Anforderungen müßte es ohne weiters möglich sein Manipulationen nachzuweisen und Beweiseinreden des Beklagten zu widerlegen(
48
).
H. Rüßmann führt in diesem Zusammenhang noch weiter aus(
49
), daß es unter beweisrechtlichen Gesichtspunkten keine Notwendigkeit für die Gleichstellung von elektronischen Dokumenten mit den Schriftdokumenten (Urkunden) gibt: "...die Rekonstruktion von Beweisregeln für private Dokumente [hat] ergeben, daß die in aller Regel entscheidenden Fragen nach der Echtheit, Unverfälschtheit und Vertrauenswürdigkeit eines Dokumentes schon jetzt der freien Beweiswürdigung unterliegt und von keiner Beweisregel erfaßt werden."(
50
) Als Begründung dafür, daß andere Staaten elektronische Dokumente und schriftliche Dokumente im Beweisrecht gleichstellen, führt Rüßmann aus, daß dies an den strengen Zulassungsbeschränkungen für Beweismittel der anderen Rechtsordnungen liegt. Im deutschen (österreichischen, schweizer) Recht kennt man allerdings derlei Beschränkungen nicht und regelt die Tauglichkeit der Beweismittel im Rahmen der freien Beweiswürdigung nach §286 ZPO. Allerdings gilt für handschriftliche Urkunden eine gesetzliche Echtheitsvermutung, wenn eine anerkannte Namensunterschrift vorliegt. Damit hat sie formellen Beweiswert und erlaubt einen schnellen Urkundenprozeß nach §§415 ff. ZPO. Somit ist die Frage nach der Gleichstellung von elektronischen Dokumenten mit digitaler Signatur und handschriftlich unterschriebenen Schriftdokumenten ein Problem, das die breite Akzeptanz der Signatur im Beweisrecht behindert.
F. Ebbing vertritt den Standpunkt(
51
) bezüglich der Beweiskraft von elektronischen Dokumenten im Zivilprozeß, daß durch noch weitere technischen Maßnahmen, wie etwa die Einführung einer dem Briefverkehr vergleichsweisen Funktion des Einschreibens/Rückscheins und der Einrichtung von Zertifizierungsinstanzen (Trust Centern), in Zukunft die Abgabe von Willenserklärungen mit Verwendung von digitalen Signaturen beweisbar werden. D.h. die Echtheit einer elektronisch übermittelten Urkunde kann im Zivilprozeß unterstellt werden, wenn deren Versendung durch den Erklärenden eletronisch signiert wurde. Problematisch sieht er den Beweis der inhaltlichen Authentizität der im Prozeß vorgelegten elektronischen Urkunde. Zwar lassen sich durch elektronische Signaturen Manipulationen feststellen, aber der Orginalinhalt läßt sich daraus nicht ermitteln. Als Lösung für dieses Problem sieht Ebbing vor, die Urkunde bei einer neutralen Stelle (z.B. den Trust Centern oder bei Notare) zu hinterlegen. Solange diese Möglichkeiten nicht bestehen kommt auch Ebbing zu dem Schluß, daß ein elektronisch signiertes Dokument nicht dem §416 ZPO gerecht wird und somit das Dokument/die Urkunde der freien Beweislast nach §286 ZPO unterliegt. In diesem Fall trifft die Beweislast denjenigen, der sich auf die Urkunde beruft, was ein nicht zu unterschätzendes Beweisrisiko birgt.
Im US Bundesstaat Utha trat am 1.5.1995 das erste umfassende Gesetz der Welt über das digitale Unterschriftenverfahren in Kraft. Kurz darauf wurden am 30.8.1995 ein Vorentwurf einer Verordnung des Bundesinnenministeriums über die Anerkennung von Verfahren zur elektronischen Unterschrift und am 20.9.1995 ein Entwurf der Bundesnotarkammer zur gesetzlichen Regelung des elektronischen Rechtsverkehrs veröffentlicht. Der Entwurf der Bundesnotarkammer sah einen neu eingefügten § 126 (a) zur gesetzlich geregelten elektronischen Form vor, der durch eine Verordnung über die elektronische Unterschrift (VEU) näher spezifiziert wurde. Ein weiterer Richtlinienentwurf zur Verwendung von digitalen Unterschriften wurde am 5.10.1995 von einem Sachverständigenausschuß der amerikanischen Anwaltskammer (Information Security Commitee, Sciencean and Technology Section of the American Bar Association (ABA)) bekanntgegeben (sog. ABA-Guidelines). Dieser Entwurf soll als Grundlage für ein US-Bundesweites Signaturgesetz dienen.
In den anfänglichen deutschen Entwürfen mußte die sichere und zuverlässige Ausgabe, Verwaltung und Überprüfung von Schlüsseln von ‘amtlichen Funktionsträgern’ wie z.B. einem Notar wahrgenommen werden. Weiterhin hatte der Notar die Aufgabe den Empfänger des Schlüssels über die Risiken der Verwendung von digitalen Unterschriften vor der Schlüsselausgabe zu belehren. Das in Utha verabschiedete Gesetz und die ABA-Guidelines sahen von Anfang an auch private Unternehmen vor, die zu diesem Zweck zugelassen werden sollen(
52
). Schon damals gab es in den USA Unternehmen die der Aufgabe als Zertifizierungsinstanz nachkamen bzw. dies planten (z.B. VeriSign(
53
) und die US-Bundespost).
Der aktuelle Stand eines Signaturgesetzes findet sich in dem am 11.12.1996 vom Bundeskabinett beschlossenen Entwurf zum Informations- und Telekommunikationsdienstgesetz (IuKdG(
54
), oft auch Multimediagesetz genannt). Der Entwurf besteht aus 11 Artikeln die teilweise nur punktuelle Regelungen aber auch vollständige Gesetzesentwürfe enthalten. In Artikel 3 wird das Signaturgesetz (SigG) aufgeführt. Der Zweck des SigG ist es, „...Rahmenbedingungen für digitale Signaturen zu schaffen, unter denen diese als sicher gelten und Fälschungen digitaler Signaturen oder Verfälschungen von signierten Daten zuverlässig festgestellt werden können"(
55
). Zentrale Themen des SigG sind die Lizenzerteilung für Zertifizierungsstellen nach §4 SigG-Entwurf , Vergabe von Zertifikaten nach §5 SigG-Entwurf , die näheren Regelungen in Verbindung mit einer Rechtsverordnung über §16 SigG-Entwurf. Diese Verordnung zum Signaturgesetz (SigV) liegt ebenfalls in einem Entwurf vom 20.12.1996 vor und regelt vor allem den genaueren Aufbau einer Zertifizierungsinfrastruktur bzw. der Zulassung von Zertifizierungsinstanzen. Das Signaturgesetz soll schon im ersten Halbjahr 1997 in Kraft treten(
57
).
Das SigG sieht in seinem Entwurf vier Akteure für die Sicherungsinfrastruktur vor:
Das SigG und die SigV weisen vor allem den Regulierungsbehörden und den Zertifizierungsstellen Funktionen zur Erfüllung ihrer Aufgaben zu. So ist die Regulierungsbehörde nach §4(
59
) Abs.1 dazu verpflichtet Lizenzierungen der Zertifizierungsstellen durchzuführen und diese zu kontrollieren nach §12. Weiterhin ist es deren Aufgabe, Prüfstellen anzuerkennen (§4 Abs. 3 und §13 Abs. 4) und die Führung einer Liste anerkannter Prüfstellen (§17 Abs. 4 SigV), sowie Verzeichnisse aller Signaturschlüssel-Zertifikate sämtlicher jemals lizensierter Zertifizierungstellen zu pflegen (§4 Abs. 5 SigG und §8 Abs. 2 SigV). Die Bewertung von mathematischen Verfahren zur Signaturerzeugung (§17 Abs. 2 SigV), die Führung einer Liste erfolgreich geprüfter technischer Komponenten (§17 Abs. 4 SigV) und die Erstellung von Empfehlungskatalogen (§12 Abs. 2 und §16 Abs. 5 SigV) werden ebenfalls der Regulierungsbehörde zugeschrieben.
Die Zertifizierungsstellen als Kernpunkt der im SigG und SigV aufgeführten Sicherungsinfrastruktur übernehmen die Überwachung sämtlicher kritischer Phasen eines Public-Key-Systems im Organisations- und Verantwortungsbereich. Zum einen kümmern sie sich um die Registrierung der Teilnehmeridentitäten (§5 SigG und §3 SigV), um die Schlüsselerzeugung (§5 SigG und §5 SigV), die Personalisierung und Pseudonymisierung (§5), die Zertifizierung (§5), die Ausgabe der Schlüssel an die Teilnehmer (§5 SigG, §6 SigV), die Pflege der Schlüsselverzeichnisse (§5 Abs. 1 SigG und §8 SigV) und um den Zeitstempel (§5). Weiterhin sind die Stellen verpflichtet den Verbraucher über das Verfahren allgemein zu unterrichten (§6 SigG und §4 SigV) und sie unterliegen einer umfassenden Dokumentationspflicht (§9 SigG und §13 SigV). Um eine Zertifizierungsstellen betreiben zu können verlangt das SigG, daß die Anforderungen an das Gesamtsystem der Stelle lückenlos dokumentiert sind, (§4 Abs. 2 SigG i.V.m. §12 SigV) und daß das eingesetzte Personal die fachliche Qualifikation und die Zuverlässigkeit zum Betrieb der Stelle hat (§ 4 Abs. 3).
Bei der Bewertung von Anforderungen von technischen Komponenten greift der Entwurf der Signaturverordnung in den §§16 und 17 auf die international anerkannten „Kriterien für die Berwertung der Sicherheit von Systemen der Informationstechnik"(
60
) zurück. Dies trifft insbesondere die Zertifizierungsstellen, an die sehr hohe Sicherheitsanforderungen gestellt werden (im Rahmen der ITSEC ist eine Evaluation nach E4 erforderlich) und es trifft die Hard- und Softwareanbieter die ihren technischen Komponenten einer E2-Evaluierung unterziehen müssen.
Weitere Regelungen im SigG und SigV die nicht unmittelbar mit den vier oben aufgeführten Akteuren in Verbindung stehen, sind die Feststellung der Indentität der Teilnehmer (§5), die zuverlässig „anhand des Bundespersonalausweises oder Reisepasses oder auf andere geeignete Weise"(
61
) erfolgen soll, die Vergabe eines Namenszusatzes bei Verwechslungsgefahr (§7 Abs. 1, 1.) und die persönliche Übergabe des privaten Signaturschlüssels (§6 SigV).
In einer Erklärung(
62
) vom 25.9.1996 (also noch zum Vor-Entwurf des IuKdG) begrüßen der Fachverband Informationtechnik VDMA und die German Information Technology Manufacturer’s Association ZVEI ausdrücklich die Initiative der Bundesregierung zur Einführung eines Gesetzes zur digitalen Signatur und betonen das erhebliche Rationalisierungspotential in Wirtschaft und Verwaltung, was dem Wirtschaftsstandort Deutschland zugute kommt. Des weiteren drängen sie auf das möglichst schnelle inkrafttreten der Regelung. Sie fordern weiterhin, daß in einem zweiten Schritt in diese Richtung elektronische Dokumente mit digitaler Signatur gesetzlich den gleichen Wert bekommen wie die herkömmlichen papiergebundenen Schriftformen, und daß elektronische Dokumente im Beweiswert der papiergebundenen Form gleichgestellt werden. Jedoch ergeben sich dabei wie oben dargestellt zur Zeit kaum überwindbare Probleme, bzw. bedarf es einer solchen Gleichstellung(
63
) nicht.
Abschließend ist zum SigG und SigV anzumerken, daß erst ein Praxiseinsatz die Tragweite des Gesetzes verdeutlicht. Zu begrüßen ist auf jedenfall, daß die Bundesregierung in ihrem derzeitigen Entwurf viele Punkte aus dem Gesetz von Utha und den ABA-Guidelines übernommen hat, wie etwa die Zulassung von privaten Zertifizierungsstellen. Der Schlußbemerkung von P. Mertes ist in sofern Recht zu geben, daß das Gesetz ein Schritt in die richtige Richtung ist aber, daß weiter Schritte noch folgen müssen um das mit dem Gesetz anvisierte Ziel einer Auflösung des Leidenstaus auf der Datenautobahn zu erreichen(
64
Oft wird mit der digitalen Signatur-Problematik die momentane Diskussion um eine Kryptoregulierung in Verbindung gebracht. Dabei geht es vor allem um die Einführung eines Gesetzes zur Beschränkung der freien Anwendbarkeit von kryptographischen Verfahren in elektronischen Netzen. Solche Beschränkgungen existieren bereits in verschiedenen Ländern wie etwa Frankreich und Russland(
65
).
VDMA und ZVEI (s.o.) fordern im Zusammenhang mit dem Signaturgesetz, im Interesse der Wirtschaft, Privatpersonen und den Sicherheitsbehörden eine Regulierung in Bezug auf starke kryptographische Verfahren zu unterlassen, mit der Begründung, daß dies zum einen weder durch eine realistische, wirtschaftlich tragbare Möglicheit machbar wäre, noch das es im Sinne der Exportchancen deutsche Sicherheitsprodukte liegt. Des weiteren führen sie auf, daß eine solche Regulierung aufgrund der weiten Verbreitung von kryptologischen Verfahren nur gesetzestreue Unternehmen und Bürger trifft.
Die Ausführungen in der Einleitung zur Begründung zum SigG weisen ausdrücklich darauf hin, daß die Funktion Signatur und Verschlüsselung technisch wie rechtlich völlig eigenständig zu betrachten sind. Tatsächlich gibt es nur eine gemeinsame Basis bei den verwendeten mathematischen Verfahren. Die Übermittlung digital signierter Dokumente erfolgt in der Regel im Klartext.
Im SigG selber weist die Formulierung in §5 Abs. 4 S. 3 ausdrücklich darauf hin, daß eine Speicherung privater Signaturschlüssel bei der Zertifizierungsstelle unzulässig ist(
66
). Dies ist ein weiterer Hinweis darauf, daß eine gesetzliche Regelung von Kryptographieverfahren nicht Gegenstand dieses Gesetzes ist.
Unter den momentan vorhanden Bedingungen ist ein Einsatz von elektronischen Dokumenten mit digitalen Signaturen im Internet für rechtsgeschäfte nur bedingt zu empfehlen. Die gesetzlichen Regelungen des Signaturgesetzes verhelfen ihr aber zu einer größeren Popularität und schaffen eine einheitliche Grunlage für den großflächigen Einsatz.Es muß sich aber erst noch herausstellen, in wie weit solche Signaturen in allen Bereichen des Rechtsverkehr verwendbar sind.
Weiterhin problematisch ist die Einrichtung der im SigG aufgeführten Instanzen, wie etwa der Regulierungsinstanz und einer flächendeckenden Versorgung mit Zertifizierungsinstanzen. Einiges deutet darauf hin, daß die Telekom AG als bisheriger Monopolist in Sachen Telekommunikation, durch die Fachgruppe Telesec bei der Einführung solcher Instanzen eine Vorreiterrolle einnimmt(
67
Asymmetrische Verschlüsselung
. Eine Form eines Schlüsselsystems, in dem Ver- und Entschlüsselung durch Verwendung zweier unterschiedlicher Schlüssel, Public- und Secret-Key, duchrgeführt wird.
DEA
. Data Encryption Algorithm, wurde von IBM entwickelt und basiert auf symmetrischer Verschlüsselung. 1977 von den USA als Standard verabschiedet. Es wird ein 56 Bit langer Schlüssel verwendet.
Dechiffrierung
. Die Übersetzung von verschlüsselten Texten oder Daten (chiffrierter Text) in ursprüngliche Texte oder Daten (Ausgangstext).
Dekodierung
. Siehe Dechiffrierung.
DES
. Data Encryption Standard. Siehe DEA.
Digitale Unterschrift
. Ein Mechanismus für die Freigabe der den Erzeuger einer Nachricht in die Lage versetzt einen Code anzufügen der wie eine Unterschrift wirkt. Die Unterschrift garantiert die Quelle und Integrität der Nachricht.
Einwegfunktion.
Eine leicht zu berechnende Funktion. Die Berechnung ihrer Umkehrung ist unmöglich.
Entschlüsselung.
Siehe Dechiffrierung.
Hash-Funktion.
Eine Funktion die einen Datenblock oder eine Nachricht variabler Länge in einen Wert mit fester Länge, als Hash-Code bezeichnet, umwandelt. Die Funktion wurde so ausgelegt, daß sie, wenn geschützt, eine Freigabeinformation für die Daten oder Nachrichten bereitstellt.
IDEA.
International Data Encryption Algorithm. Erstmals 1990 von Xueija Lai und James Massey am Swiss Ferderal Institute of Technology veröffentlicht. Es wird ein 128 Bit langer Schlüssel verwendet.
Kryptographie.
Der Zweig der Kryptologie, der sich mit dem Entwurf von Algorithmen für die Verschlüsselung und Entschlüsselung mit der Absicht befaßt, die Sicherheit und/oder die Echtheit von Nachrichten zu gewährleisten.
Kryptologie.
Die Lehre von der sicheren Kommunikation, die Kryptographie und Kryptoanalyse umfaßt.
MAC
. Message Authentication Code. Auf Kryptographischen Verfahren beruhende Prüfsumme für eine Nachricht oder Datei, anhand derer die Unversehrtheit der Daten geprüft werden kann.
MD5, MD2.
Message Digest-2 /-5. U.a. veröffentlicht in RFC 1321. Siehe auch Hash-Funktion.
Öffentlicher Schlüssel.
Einer der beiden Schlüssel, die in einem asymmetrischen Verschlüsselungssystem verwendet werden. Der Schlüssel wird bekanntgegeben, um in Verbindung mit einem entsprechenden privaten Schlüssel verwendet zu werden.
PEM.
Privacy Enhanced Mail. Wurde genau definiert in den RFC’s 1421-1424
PGP.Pretty Good Privacy.
Ein von Philip Zimmermann frei verfügbares Programm zur Verschlüsselung/Entschlüsselung und digitalem signieren von Electronic Mail. Eingesetzt werden der IDEA, das MD5-Verfahren und der RSA-Public-Key-System.
Privater Schlüssel.
Einer der beiden Schlüssel, die in einem asymmetrischen Verschlüsselungssystem verwendet werden. Für eine sichere Kommunikation darf der Private Schlüssel z.B. im Fall von PGP und PEM nur seinem Erzeuger bekannt sein.
Public-Key.
Siehe Öffentlicher Schlüssel.
RC4 und RC2.
Beides symmetrische Verschlüsselungsverfahren, die von der Firma RSA Data Security Inc. entwickelt wurden.
RFC.
Request for Comment. Veröffentlichung des Internet activities Board IAB zur Standardisierung von Im Internet eingesetzter Verfahren.
RSA-Algorithmus.
Ein Algorithmus basierend auf asymmterischer Verschlüssellung. Wurde von R. Rivest, A. Shamir und L. Adelman entwickelt und 1978 am MIT veröffentlicht. Gilt als der einzige allgemein anerkannte und implemetierte Ansatz für die Public-Key-Verschlüsselung.
Secret-Key.
Siehe Privater Schlüssel.
Sitzungsschlüssel.
Schlüssel eines symmetrischen Verschlüsselungssystems (IDEA, DEA).
Symmetrische Verschlüsselung.
Eine Form des Kryptosystems, bei der Ver- und Entschlüsselung duch Einsatz des gleichen Schlüssels erfolgen. Ebenso als konventionelle Verschlüsselung bekannt.
(Third Party) Trust Center.
Siehe Zertifizierungsinstanz.
X.509.
Format für die Zertifizierung von öffentlichen Schlüsseln.
Zertifikat.
Besteht in der Regel aus dem zu zertifizierendem öffentlichen Schlüssel, signiert mit dem Privaten Schlüssel der Zertifizierungsinstanz.
Zertifizierungsinstanz.
Regelt die Vergabe von Zertifikaten für öffentliche Schlüssel, um deren Echtheit zu garantieren.
2. Identifizierung und Authentifizierung aus juristischer Sicht
2.1 Notwendigkeit und gesetzliche Entwicklung der Identifizierung und Authentifizierung im Internet
2.2 Klassisches Einsatzgebiet der Identifikation und Authentifikation im Rechtsverkehr
2.3 Digitale Signaturen im Rechtsverkehr
2.3.1 Formqualität
2.3.2 Beweiswert elektronischer Dokumente
2.4 Entwicklung des Signaturgesetzes (SigG) und der Signaturverordnung (SigV)
2.5 Kryptoregulierung
2.6 Zusammenfassung
Zurück
zum Inhaltsverzeichnis
3. Glossar
Zurück
zum Inhaltsverzeichnis
Barron, Billy;
|
Internet für Insider SAMS, 1996 |
Crocked, David H. |
Standard for the format of ARPA Internet text messages RFC 822 - 13.8.1982 |
Fox, Dirk |
Automatische Autogramme C’T - Magazin für Computer Technik 10/95 S.278 ff |
Frank Ebbing |
Schriftform und E-Mail CR 5/96, S. 271 ff. |
Kaliski, B. |
The MD2 Message-Digest Algorithm RSA Laboratories, April 1992 RFC 1319 |
Kuner, Christoph |
Digitale Unterschriften im Internet-Zahlungsverkehr: Rechtliches in Deutschland und den USA NJW CoR 2/96, S.108 ff |
Linn, J.; |
Privacy Enhancement for Internet Electronic Mail IAB IRTF PSRG, IETF PEM February 1993 Part I - IV; RFC 1421-1424 |
Mertes, Paul |
Gesetz und Verordnung zur Digitalen Signatur - Bewegung auf der Datenautobahn ? CR 12/96, S. 769 ff |
Oikarinen, J. |
Internet Relay Chat Protocol S. Reed, May 1993 RFC 1459 |
Postel, Jonathan B. |
Simple Mail Transfer Protocol RFC 812 - August 1982 |
Rivest. Ronald |
The MD5 Message-Digest Algorithm MIT Laboratory for Computer Science and RSA Data Security, Inc. , April 1992 RFC 1321 |
Roßnagel, Alexander |
Digitale Signaturen im Rechtsverkehr NJW-CoR 2/94, S. 98 ff |
Rüßmann, Helmut |
Das Beweisrecht elektronischer Dokumente JurPC 7/95, S. 3212 ff |
Stallings, W. |
Sicherheit im Datennetz Prentice Hall’ 95 |
Wildhaber, Bruno |
Informationssicherheit, rechtliche Grundlagen und Anforderungen an die Praxis 1993 Schulthess Ploygraphischer Verlag AG, Zürich |
Williams, Martyn |
Netscape Encrypted Data Cracked Newsbyte News Network 18.8.1995 |
Weitere Verweise auf verwendete Quellen und Texte als URL-Angaben in den Fußnoten.
Zurück
zum Inhaltsverzeichnis