Zum Inhalt springen

Elektronische Signatur

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 29. Dezember 2004 um 16:59 Uhr durch Müsli (Diskussion | Beiträge) (PGP-Systeme). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Bei der digitale Signatur genannten elektronischen Unterschrift handelt es sich um den Nachweis von Integrität und Authentizität einer Nachricht.

Sie basiert meist auf asymmetrischen Kryptosystemen. Der bekannte öffentliche Schlüssel eines Unterzeichners erlaubt die Überprüfung seiner Unterschrift, die mit seinem geheimen persönlichen Schlüssel erzeugt wurde. Es bleibt das Problem zu zeigen, ob der öffentliche Schlüssel wirklich dem Unterzeichner gehört. Das Verfahren nach PGP (E-Mail, Usenet, etc.) vertraut einem Netz von Freunden, S/MIME einer hierarchischen Authentisierungsstruktur, was Voraussetzung ist für die Rechtsgültigkeit einer digitalen Unterschrift.

Alice besitzt ein Schlüsselpaar K bestehend aus einem öffentlichen und einem privaten Schlüssel, die mathematisch voneinander abhängen.

Alices öffentlicher Schlüssel
Alices geheimer Schlüssel
Verschlüsselung von x mit dem Schlüssel K
N eine Nachricht
h(N) Hashwert der Nachricht
S Signatur

Im Vorfeld lässt Alice Bob ihren öffentlichen Schlüssel zukommen. Dies kann auch durch einen unsicheren Kanal geschehen. Wichtig ist nur, dass Bob weiß, dass der Schlüssel zweifelsfrei zu Alice gehört.

Möchte Alice nun einen Nachricht für Bob unterschreiben, bildet sie den Hashwert der Nachricht. Dieser ist eine Art Prüfsumme über die Nachricht; ändert sich ein Bit der Nachricht, so ist mit extrem hoher Wahrscheinlichkeit der Hashwert ein anderer. Um eine Signatur zu erhalten, verschlüsselt Alice diesen Hashwert mit ihrem geheimen (!) Schlüssel.

Bei der Verschlüsselung geht es nicht darum, den Inhalt des Hashwertes zu verbergen, sondern es soll sichergestellt werden, dass Bob die Signatur mit dem öffentlichen Schlüssel von Alice (und zwar nur mit dem von Alice) wieder entschlüsseln kann.

Nun sendet Alice die Nachricht und die Signatur an Bob. Dieser berechnet nun seinerseits den Hashwert aus der Nachricht . Nun wendet er Alices öffentlichen Schlüssel auf die Signatur an

und macht somit Alices Verschlüsselung rückgängig. Nun muss Bob nur noch vergleichen ob

um zu wissen, dass Alice das Dokument unterschrieben hat. Bob überlegt sich dafür, dass der Hashwert korrekt mit einem Schlüssel verschlüsselt wurde, den nur Alice kennen konnte. Darum glaubt er, dass das Dokument von Alice signiert wurde. Sollte ungleich sein, so ist das Dokument entweder unterwegs verfälscht worden (Nachweis der Integrität) oder nicht mit dem Schlüssel von Alice signiert worden (Nachweis der Authentizität). Diese Abläufe und Berechnungen werden von entsprechenden Programmen (z. T. E-Mail-Clients) automatisch vorgenommen.

Technische Umsetzung

Algorithmen

Als Algorithmen zur Umsetzung eignen sich jegliche asymmetrischen Verschlüsselungsverfahren, die als sicher bekannt sind, wie RSA. Es gibt aber auch spezielle Signaturalgorithmen wie DSA, der auf dem Verfahren von El-Gamal basiert und auch das Herzstück des amerikanischen Digital Signature Standard (DSS) bildet.

PGP-Systeme

PGP steht für Pretty good Privacy und wurde 1986 von Phil Zimmermann initiiert. PGP ist selbst kein Verschlüsselungsalgorithmus, sondern ein Programm, das die z. T. komplizierten Verfahren unter einer einfach benutzbaren Oberfläche zusammenfasst.

PGP-Systeme basiert auf dem Gedanken, dass sich jeder Kommunikationspartner jederzeit ein Schlüsselpaar erzeugen kann. Das Vertrauen in die Zuordnung der Schlüssel zu einer Person wird durch gegenseitige Beglaubigungen realisiert. Dadurch entsteht ein Web of Trust, über das auch transitive Vertrauenbeziehungen hergestellt werden können. Der Vorteil dieses Verfahrens besteht in den geringen Voraussetzungen an den einzelnen Benutzer.

Die verbreiteten Implementierungen sind PGP und GnuPG. Das Gnu Privacy Projekt (GnuPP) pflegt ein auf GnuPG basierendes graphisches Frontend für alle gängigen Betriebssysteme.

Zertifikatsbasierte Systeme

In zertifikatsbasierten Systemen erhält jeder Benutzer ein digitales Zertifikat welches seine Identität beschreibt und die öffentlichen Schlüssel enthält. Jedes Zertifikat ist von einer ausgebenden Stelle beglaubigt, die ihrerseits wieder von höheren Stellen beglaubigt sein kann. Das Vertrauenssystem ist streng hierarchisch. Den gemeinsamen Vertrauensanker bildet ein sog. Wurzel-Zertifikat (Root Certificate).

Zertifikatsbasierte Systeme passen sich gut in Unternehmenshierarchien ein. Nachteil sind die hohen Kosten für Aufbau und Betrieb einer Public-Key-Infrastruktur (PKI).

Der Standard S/MIME baut auf digitalen Zertifikaten auf.

Ein Zertifikat verknüpft Daten eines kryptographischen Schlüssels (oder Schlüsselpaars, bestehend aus öffentlichem und privatem Schlüssel) mit Daten des Inhabers und einer Zertifizierungsstelle, sowie weitere Spezifikationen wie Version, Gültigkeitsdauer, Verwendungszweck und Fingerprint. Die Definitionen nach PKCS legen das Inhalts-Format fest, der Standard X.509 (genauer: ITU x.509 v3 nach RFC3280, basierend auf ASN.1 Format) beschreibt das Binär-Datenformat, oftmals als Base-64 oder DER kodiert.

PKCS #7 wird für den Austausch des öffentlichen Schlüssels genutzt. PKCS #12 enthält zusätzlich den -- kennwortgeschützten -- privaten Schlüssel.

Häufig verwendete Dateinamen-Erweiterungen:

PKCS #7 .p7b (Zertifikats-Datei)
PKCS #12 .pfx, p12
X.509 .cer

Das folgende Beispiel zeigt ein selbstsigniertes Wurzel-Zertifikat (root-certificate) einer Wurzel-Zertifizierungsstelle (sog. Certificate Authority (CA)):

Certificate name
 TC TrustCenter for Security in Data Networks GmbH
 TC TrustCenter Class 0 CA
 Hamburg
 Hamburg, DE
 emailAddress: certificate@trustcenter.de
Issuer
 TC TrustCenter for Security in Data Networks GmbH
 TC TrustCenter Class 0 CA
 Hamburg
 Hamburg, DE
 emailAddress: certificate@trustcenter.de
Details
 Certificate version: 3
 Serial number: 1
 Not valid before: Mar  9 13:54:48 1998 GMT
 Not valid after: Dec 31 13:54:48 2005 GMT
 Fingerprint: (MD5) 35 85 49 8E 6E 57 FE BD 97 F1 C9 46 23 3A B6 7D
 Fingerprint: (SHA-1) 44 81 A7 D6 C9 44 75 84 CF ED 8A 47 C9 AE 6A F0 1E 39 75 18
Public key algorithm: rsaEncryption
 Public-Key (1024 bit):
 Modulus:
    00: A3 CC 7E E4 FA 5F E5 D7 39 67 86 38 AA 5B 37 6D
    10: 0F 01 2B 08 01 FA A1 B4 6A F4 73 05 C3 18 B4 DC
    20: 8D F4 1E DE 5C AB 21 8A 3B 63 C8 23 8B D8 C1 3F
    30: 7C A2 74 99 67 19 71 9F CC 40 4E 18 2A 09 2B 27
    40: 6B DB DB 11 78 C4 A0 85 9C 34 C2 A1 2E 02 4B 0B
    50: 21 F4 B3 4B 1D B3 46 B2 B4 6B 12 54 4C 1A CA 27
    60: F5 27 33 B3 B9 C6 8A C5 28 9F B0 E2 8A E8 54 3B
    70: 7F 0B 8D E0 D1 0E 4E 6D 2F F0 D5 BF BE E6 7D DF
  Exponent:
     01 00 01
Public key algorithm: md5WithRSAEncryption
    00: 4D 07 7F 5F 09 30 19 92 AA 05 47 7A 94 75 54 2A
    10: AE CF FC D8 0C 42 E1 45 38 2B 24 95 B2 CA 87 CA
    20: 79 C4 C3 97 90 5E 62 18 C6 C9 38 61 4C 68 35 D3
    30: 4C 14 11 EB C4 CD A1 A9 D8 C5 9E 68 27 32 07 35
    40: 45 04 F8 5F 21 A0 60 1E 1C 00 48 04 58 D2 C5 CB
    50: AE 6D 32 6E 3D 77 95 8C 85 C7 E5 AE 50 9D 75 4A
    60: 7B FF 0B 27 79 EA 4D A4 59 FF EC 5A EA 26 A5 39
    70: 83 A4 D1 78 CE A7 A9 7E BC DD 2B CA 12 93 03 4A
Extensions:
  Netscape Revocation Url: https://www.trustcenter.de/cgi-bin/check-rev.cgi?
  Netscape CA Revocation Url: https://www.trustcenter.de/cgi-bin/check-rev.cgi?
  Netscape Renewal Url: https://www.trustcenter.de/cgi-bin/Renew.cgi?
  Netscape CA Policy Url: http://www.trustcenter.de/guidelines/index.html
  Netscape Comment: TC TrustCenter Class 0 CA
  Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA

Aufbau eines Server-Zertifikats mit öffentlichem Schlüssel:

  • Certificate name: Name des Zertifikat-Inhabers.
  • Issuer: CA oder untergeordnete Zertifizierungsstelle, die die Authentizität bestätigt.
  • Details: Gültigkeitsdauer und andere Daten. Digitale Signatur des Zertifikats durch die Zertifizierungsstelle (Issuer).
  • Public Key: Der öffentliche Schlüssel.
  • Der private Schlüssel ist in einem Server-Zertifikat nicht enthalten. Client-Zertifikate benötigen ihn, um ihre die Authentizität gegenüber dem Server bestätigen zu können. Immer sollte der private Schlüssel mit einem Kennwort geschützt sein.

Beim Web-Datenaustausch überträgt der Server seinen öffentlichen Schlüssel an den Client. Der Client, d.i. der Webbrowser des Nutzers, überlegt, ob er dem öffentlichen Schlüssel trauen kann. Dazu schaut er in die Liste seiner Zertifikate, die ihm bei der Installation mitgegeben wurden bzw. der Benutzer selbst installiert hat. Findet der dort das Zertifikat, startet er eine verschlüsselte Datenübertragung.

Technisch basiert die Verschlüsselung auf dem SSL-Protokoll (Secure Sockets Layer), die sich dem Web-Benutzer als https: statt http: Protokoll mitteilt.

Nur der Server, der den öffentlichen Schlüssel ausgegeben hat, kann auch die Daten entschlüsseln, die der Client mit diesem Schlüssel verschlüsselt zu ihm überträgt. Fatal ist es, wenn einem Zertifikat aus Leichtsinn Vertrauenswürdigkeit ausgesprochen wurde.

Beispiel: Ein betrügerischer Server gibt vor, die Hausbank zu sein. Der Webbrowser stellt beim ersten Besuch fest, dass er das Zertifikat des Betrügers nicht kennt. Der Benutzer des Webbrowsers, weil er es nicht besser weiß, klickt auf Zertifikat annehmen. Daraufhin kommunizieren der Server des Betrügers und der Client des Benutzers über eine sichere Web-Verbindung. Sicher in diesem Zusammenhang bedeutet, dass Dritte die Datenübertragung nicht abhören können. Die Gewissheit, mit dem richtigen Partner zu kommunizieren, ist durch die Leichtfertigkeit des Nutzers, das unbekannte Zertifikat anzunehmen, nicht mehr gegeben. Schlimmer noch: dadurch, dass der Browser das Zertifikat speichert, werden nicht nur spätere Besuche des Betrüger-Servers als sicher eingestuft, sondern auch Zertifikate, die der Betrüger-Server signiert hat.

Rechtliche Rahmenbedingungen

Die elektronische Signatur ist durch mehrere Rechtsvorschriften geregelt:

Das bürgerliche Gesetzbuch erlaubt den Ersatz der schriftlichen Form durch die elektronische Form, soweit durch Gesetz nichts anderes bestimmt ist (§ 126 BGB). Die elektronische Form ist gewahrt, wenn dem Dokument der Name hinzugefügt und mit einer qualifizierten elektronischen Signatur versehen wird (§ 126a BGB). Die qualifizierte elektronische Signatur stellt höhere Anforderungen. Stattdessen können die Vertragspartner eine andere Form vereinbaren, also insbesondere eine einfachere elektronische Signatur wählen (§ 127 BGB).

Das Signaturgesetz unterscheidet zwischen der elektronischen Signatur an sich, die daher häufig als einfache elektronische Signatur bezeichnet wird, der fortgeschrittenen elektronischen Signatur und der qualifizierten elektronischen Signatur. Letztere erfordert ein gültiges Zertifikat und die Erzeugung mit einer Signaturerstellungseinheit. Das ist im Regelfall ein Lesegerät für Chipkarten, ergänzt um geeignete Verschlüsselungssoftware. Die Anforderungen an Chipkarten mit Signaturfunktionalität werden durch DIN V 66291-1 bestimmt. Die Zertifikate werden im Bundesamt für die Sicherheit in der Informationstechnik gesammelt.

Die für qualifizierte elektronische Signaturen zugelassenen Kryptoalgorithmen werden von der Regulierungsbehörde für Telekommunikation und Post genehmigt und veröffentlicht. Dort sind auch die für eine qualifizierte elektronische Signatur zugelassenen Produkte aufgelistet.

Zertifizierungsdienste sind genehmigungsfrei, aber anzeigepflichtig. Bei der Anzeige ist darzulegen, dass und wie die gesetzlichen Anforderungen (finanzielle Deckungsvorsorge, Zuverlässigkeit, Fachkunde) erfüllt sind.

Workflow - Ablauf einer elektronischen Signierung

  1. Der Absender wählt die zu signierende Nutzdatei aus
  2. Die Signatur-Software bildet über die Nutzdatei einen Hashwert (Prüfsumme, digitaler Fingerprint)
  3. Der Absender verschlüsselt den Hashwert und bildet damit die digitale Signatur
  4. Der Absender verschickt die Nutzdatei und die Signaturdatei (alternativ verschickt er eine Containerdatei, in der die Nutzdatei und die Signatur enthalten sind)
  5. Der Empfänger erhält die Nutzdatei und die Signaturdatei (alternativ die Containerdatei)
  6. Der Empfänger dechiffriert die Signatur mit Hilfe des öffentlichen Schlüssels und erhält damit den vom Absender erzeugten Hashwert
  7. Der Empfänger berechnet mit Hilfe der Prüf-Version der Signatur-Software den Hashwert zur Nutzdatei erneut (viele Hersteller bieten hierfür kostenlose Prüf-Editionen an, teils auch Online-Prüfung via Internet)
  8. Der Empfänger vergleicht die beiden Hashwerte: sind diese identisch, dann wurde die Datei vom richtigen Absender verschickt (Authentifizierung, Authentizität) und nicht verändert (Integrität) (Dies setzt voraus, dass nur der gewünschte Absender im Besitz des privaten Schlüssels ist).