Zum Inhalt springen

Elektronische Signatur

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 4. Januar 2006 um 03:44 Uhr durch Millbart (Diskussion | Beiträge) (Signierte Dokumententypen und Form der Signaturspeicherung). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Bei einer elektronischen Signatur handelt es sich um elektronische Daten, die die Authentizität und Integrität von elektronischen Informationen, meist elektronische Dokumente, sicherstellen sollen. Darüber hinaus soll eine elektronische Signatur die Identität des Signierenden gewährleisten. Diese Merkmale sollen wiederum mit Hilfe der elektronischen Signatur verifizierbar (d.h. überprüfbar) sein. Mit diesen Eigenschaften soll die elektronische Signatur das elektronische Äquivalent zur eigenhändigen Unterschrift darstellen. Je nach angewendeter Signaturtechnologie, vorhandenem Einsatzszenario sowie der gegebenen Rechtslage werden diese angestrebten Eigenschaften der elektronischen Signatur erreicht.

Begriffsbestimmung

Der Begriff elektronische Signatur ist Oberbegriff für sämtliche Signaturtechnologien. Er wird meist synonym mit den Begriff elektronische Unterschrift verwendet, was begrifflich gesehen nicht ganz korrekt ist. Der Begriff elektronische Unterschrift impliziert, dass es sich i.w.S. um eine Schrift (bspw. die eingescannte eigenhändige Unterschrift) handelt, was aber nicht notwendigerweise der Fall sein muss. Häufiger ist auch eine synonyme Verwendung mit dem Begriff digitale Signatur vorzufinden, was im deutschen Sprachgebrauch als begrifflich inkorrekt angesehen wird. Zumeist wird die Meinung vertreten, dass sich der Begriff digitale Signatur nur auf elektronische Signaturen, basierend auf Zertifikaten mit Public-Key-Infrastruktur (PKI) vom (inzwischen überarbeiteten) deutschen Signaturgesetz (SigG) von 1997 bezieht. Andererseits gibt es Meinungen, der Begriff digitale Signatur beziehe sich auf sog. qualifizierte Signaturen nach deutschem Signaturgesetz von 2001. Die Verwirrung kann dadurch entstanden sein, dass im SigG von 1997 noch von digitalen Signaturen die Rede war, seit dem 2001er SigG aber von elektronischen Signaturen gesprochen wird.

Problematik

Einer auf einem elektronischen Zertifikat und einer Signaturkarte basierenden elektronischen Signatur ist nicht anzusehen, ob sie möglicherweise von einer nichtautorisierten Person stammt.

Daher hat der Signator die Pflicht die Signaturerstellungsdaten sorgfältig zu verwahren, soweit zumutbar Zugriffe auf Signaturerstellungsdaten zu verhindern und deren Weitergabe zu unterlassen. Er hat den Widerruf des Zertifikats zu verlangen, wenn die Signaturerstellungsdaten abhanden kommen, wenn Anhaltspunkte für eine Kompromittierung der Signaturerstellungsdaten bestehen oder wenn sich die im Zertifikat bescheinigten Umstände geändert haben.

Für die Erzeugung und Speicherung von Signaturerstellungsdaten sowie für die Erstellung sicherer Signaturen sind solche technische Komponenten und Verfahren einzusetzen, die die Fälschung von Signaturen sowie die Verfälschung signierter Daten zuverlässig erkennbar machen und die die unbefugte Verwendung von Signaturerstellungsdaten verläßlich verhindern.

Die bei der Erstellung einer sicheren Signatur verwendeten technischen Komponenten und Verfahren müssen zudem sicherstellen, daß die zu signierenden Daten nicht verändert werden; sie müssen es außerdem ermöglichen, daß dem Signator die zu signierenden Daten vor Auslösung des Signaturvorgangs dargestellt werden.

Die elektronische Signatur ist ein elektronisches Siegel: sie bürgt für die Unversehrtheit des Dokumenteninhalts. Der Signator hat die Pflicht Dritten keinen Zugang zum "Siegelring" zu gewähren.

Prinzip

Die elektronische Signatur basiert meist auf asymmetrischen Kryptoverfahren. Der bekannte öffentliche Schlüssel (public key) eines Unterzeichners erlaubt die Überprüfung seiner Signatur, die mit seinem geheimen Schlüssel (private key) erzeugt wurde. Es bleibt das Problem zu zeigen, ob der öffentliche Schlüssel wirklich dem Unterzeichner gehört. Das Verfahren nach PGP (Pretty Good Privacy) vertraut einem Netz von Freunden, S/MIME (Secure / Multipurpose Internet Mail Extension) einer hierarchischen Authentisierungsstruktur, was u.a. Voraussetzung ist für eine hohe Beweiskraft der elektronischen Signatur.

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

Alices öffentlicher Schlüssel
Alices geheimer Schlüssel
Verschlüsselung von x mit dem Schlüssel K
eine Nachricht
Hashwert der Nachricht
Hash-Funktion
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 eine 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 mit einem geheimen Schlüssel geht es nicht darum, den Inhalt des Hashwertes zu verbergen, sondern es soll sichergestellt werden, dass ausschließlich Alice den Hashwert verschlüsseln kann und Bob (jeder) den Hashwert der 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 ebenfalls den Hashwert aus der Nachricht . Außerdem wendet er Alices öffentlichen Schlüssel auf die Signatur bzw. den Hashwert an

und entschlüsselt damit den Hashwert der Signatur. Nun muss Bob nur noch vergleichen ob

um zu wissen, ob die Nachricht von Alice unverändert bei Bob angekommen ist. Sollte nämlich ungleich sein, so ist die von Alice signierte Nachricht unterwegs verfälscht worden (Nachweis der Daten-Integrität).

Sollte Bob den Hashwert von Alices Nachricht nicht mit dem öffentlichen Schlüssel von Alice entschlüsseln können, weiß Bob, dass die Nachricht nicht von Alice signiert wurde (Nachweis der Authentizität des Signaturerstellers).

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 asymmetrische 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 basieren 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 Vertrauensbeziehungen hergestellt werden können. Der Vorteil dieses Verfahrens besteht in den geringen Voraussetzungen an den einzelnen Benutzer.

Verbreitete Implementierungen sind PGP (kommerziell) und GnuPG (GNU-GPL). Das Gnu Privacy Projekt kümmerte sich um ein auf GnuPG basierendes graphisches Frontend für alle gängigen Betriebssysteme. Seit 2003 scheint das Projekt nicht besonders viel Aktivität zu zeigen. Das Programm WinPT (Windows Privacy Tools), das auch auf GnuPG aufsetzt, bietet unter Windows ebenfalls eine grafische Oberfläche zur komfortableren Bedienung digitaler Signierungen. Für die Mailclients Mozilla Thunderbird, Mozilla Mail und Netscape Mail gibt es das komfortable Plugin Enigmail, das es dem Benutzer erlaubt, die von GnuPG bereitgestellten Funktionen der Verschlüsselung und Signatur direkt im Mailprogramm zu nutzen. Das Plugin ist Open Source und unter die GNU-GPL sowie unter die Mozilla Public License gestellt.

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. Nachteilig 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 geheimem 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 Inhaltsformat fest, der Standard X.509 (genauer: ITU x.509 v3 nach RFC 3280, basierend auf ASN.1 Format) beschreibt das Binär-Datenformat, oftmals als DER bzw. als DER - Base-64 kodiert.

PKCS #7 wird für den Austausch des öffentlichen Schlüssels genutzt. PKCS #12 enthält zusätzlich den – kennwortgeschützten – geheimen 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. Certification 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 geheime Schlüssel ist in einem Server-Zertifikat nicht enthalten. Client-Zertifikate benötigen ihn, um ihre Authentizität gegenüber dem Server bestätigen zu können. Der geheime Schlüssel sollte immer 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 er dort das Zertifikat, startet er eine verschlüsselte Datenübertragung. Ansonsten wird der Benutzer über einen Dialog gefragt, ob er das Zertifikat überprüfen und akzeptieren will.

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.

Zertifikatsfreie Systeme

Zertifikatsfreie Systeme basieren zumindest bei fortgeschrittenen Signaturen gemäß § 2 Abs. 4 des deutschen Signaturgesetzes, ebenfalls auf kryptographische Verfahren mit einmaligen Schlüsseln, also asymmetrischen Schlüsseln.

Im Gegensatz zu qualifizierten Signaturen müssen jedoch bei fortgeschrittenen Signaturen, geheimer und öffentlicher Schlüssel dem Signaturersteller nicht zugeordnet sein. Somit kann zwar die Authentizität / Integrität der signierten Daten geprüft werden, jedoch ist eine Identifizierung des Unterzeichners über ein Zertifikat nicht möglich.

In diesem Fall können biometrische Verfahren, wie z.B. die eigenhängige Unterschrift, die während des Signierens erfasst und verschlüsselt in das Dokument eingebettet wird, zur Identifizierung beitragen. Zur Sicherung der biometrischen Daten werden diese zusätzlich in den Hashwert (Prüfsumme) einbezogen. Bei einer Signaturprüfung wird dann neben den signierten Daten auch die Authentizität / Integrität des Identifizierungsmerkmals geprüft.

Rechtliche Rahmenbedingungen

Rechtliche Rahmenbedingungen Deutschland

Die elektronische Signatur ist durch mehrere Rechtsvorschriften geregelt:

Das bürgerliche Gesetzbuch erlaubt den Ersatz der per Gesetz vorgeschriebenen – also nicht freiwilligen – schriftlichen Form durch die elektronische Form, soweit durch Gesetz nichts anderes bestimmt ist (§ 126 BGB). Die elektronische Form ist gewahrt, wenn dem elektronischen Dokument der Name des Unterzeichners / Signierenden hinzugefügt und mit einer qualifizierten elektronischen Signatur versehen wird (§ 126a BGB). Die qualifizierte elektronische Signatur stellt zusätzliche Anforderungen, z.B. die Zuweisung des zur Verschlüsselung der Prüfsumme (Hashwert) genutzten asymmetrischen Schlüsselpaares (geheimer und öffentlicher Schlüssel) zu einer Person, die mit einem elektronischen Zertifikat bestätigt wird.

Für formfreie Vereinbarungen, die nicht per Gesetz der Schriftform benötigen, jedoch aus Beweisgründen freiwillig schriftlich verfasst und unterzeichnet bzw. signiert werden, können die Vertragspartner für elektronische Dokumente eine andere Signaturform vereinbaren, also entweder eine "einfache" oder fortgeschrittene elektronische Signatur wählen (§ 127 BGB). Seit Inkrafttreten des 1. Gesetzes zur Änderung des Signaturgesetzes (Januar 2005) muss das zur Verschlüsselung des Hashwertes genutzte asymmetrische Schlüsselpaar dem Signierenden nicht mehr zugewiesen sein. Damit können für fortgeschrittene Signaturen auch andere Identifizierungsverfahren, z.B. aufbauend auf biometrischen Daten, genutzt werden.

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 sicheren Signaturerstellungseinheit (SSEE). Das ist im Regelfall der Chip der Chipkarte, auf dem einerseits das Matching (Überprüfung der PIN) für die Authentifizierung stattfindet und auch der Hashwert mit dem auf dem Chip gespeicherten geheimen Schlüssel verschlüsselt wird. Allerdings können auch andere tokenbasierte Devices wie USB-Sticks eingesetzt werden. Die Anforderungen an Chipkarten mit Signaturfunktionalität werden durch DIN V 66291-1 bestimmt. Die Zertifikate werden im Bundesamt für Sicherheit in der Informationstechnik (BSI) gesammelt.

Die für qualifizierte elektronische Signaturen zugelassenen Kryptoalgorithmen werden von der Bundesnetzagentur 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.

Rechtliche Rahmenbedingungen Schweiz

Die elektronische Signatur ist durch das Bundesgesetz über Zertifizierungsdienste im Bereich der elektronischen Signatur (ZertES) sowie durch die Verordnung über Zertifizierungsdienste im Bereich der elektronischen Signatur (VZertES) geregelt. Das Obligationenrecht (OR) sieht in Art. 14 Abs. 2bis bzw. Art. 59a eine Gleichstellung von ZertES-konformer elektronischer Signatur und Handunterschrift im Bereich gesetzlicher Formvorschriften sowie eine Haftung des Inhabers des Signierschlüssels für den sorgfältigen Umgang mit dem Schlüssel vor. ZertES, VZertES und die entsprechende OR-Novelle sind am 1. Januar 2005 in Kraft getreten.

Ein wesentlicher Unterschied zur Regelung in der deutschen Gesetzgebung (und in der EU-Signaturrichtlinie) liegt darin, dass für eine Rechtswirkung der erwähnten obligationenrechtlichen Normen jeweils die Anerkennung (EU-Termnologie: Akkreditierung) des jeweiligen Zertifizierungsdienstes durch eine Anerkennungsstelle vorausgesetzt wird. Es braucht also in der Schweiz die gesetzeskonforme elektronische Signatur eines anerkannten Zertifizierungsdienstes, während in der EU nur eine gesetzeskonforme Signatur vorausgesetzt wird und die Akkreditierung damit freiwillig bleibt. Die Anerkennung bzw. Akkreditierung ist eine Bestätigung dafür, dass der Zertifizierungsdienst die Anforderungen des Gesetzes erfüllt.

Das Bundesamt für Metrologie und Akkreditierung publiziert eine Liste der anerkannten Zertifizierungsdienste. Derzeit (Oktober 2005) befinden sich mit der Swisscom Solutions AG, der Schweizerischen Post Die Post mit ihrer Lösung SwissSign, der Ofac Group und der QuoVadis Trustlink Schweiz AG vier Kandidaten im Anerkennungsprozedere.

Rechtliche Rahmenbedingungen Österreich

Österreich war das erste Land, das die Richtlinie 1999/93/EG des Europäischen Parlaments und des Rates über gemeinschaftliche Rahmenbedingungen für elektronische Signaturen umgesetzt hat.

Die Grundlage für die Anerkennung elektronischer Signaturen im österreichischen Recht bildet das Bundesgesetz über elektronische Signaturen (Signaturgesetz – SigG), BGBl I 1999/190. Das Signaturgesetz wird durch die Signaturverordnung näher ausgeführt.

Die Bestätigungsstellenverordnung legt Kriterien für die Feststellung der Eignung von Bestätigungsstellen fest. Mit der Verordnung BGBl II 2000/31 wurde die Eignung des Vereins "Zentrum für sichere Informationstechnologie – Austria (A-SIT)" als Bestätigungsstelle festgestellt.

Die rechtlichen Grundlagen können im Detail unter folgenden Verweisen gefunden werden:

A-SIT - Rechtsrahmen elektronische Signatur

Rundfunk und Telekom Regulierungs GmbH - Signaturrecht

A-Trust derzeit (11/2005) einziger akkreditierter Zertifizierungsdiensteanbieter in Österreich

Einsatz in der Praxis

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 Fingerabdruck)
  3. Der Absender verschlüsselt den Hashwert mit Hilfe des geheimen Schlüssels und bildet damit die elektronische Signatur
  4. Der Absender verschickt die Nutzdatei und die Signaturdatei (Alternativen sind: a) Dateien getrennt; b) Containerdatei mit beiden Dateien; c) Signatur in Nutzdatei enthalten (z.B. bei PDF oder XML))
  5. Der Empfänger erhält die Nutzdatei und die Signaturdatei
  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 geheimen Schlüssels ist).

Hinweis: Der Inhalt einer Datei wird durch eine Signatur nicht verschlüsselt. Die signierte Datei ist weiter lesbar und auch veränderbar. Eine elektronische Signatur, zumindest wenn dafür entsprechende Verfahren wie asymmetrische Verschlüsselung eingesetzt werden, dient lediglich zur Erkennung, ob die Datei nach der Signierung verändert wurde.

Soweit die Signatur ein Zertifikat enthält und somit der öffentliche Schlüssel dem Signaturersteller zugeordnet ist, kann zusätzlich die Identität des Signaturerstellers ermittelt werden.

Signierte Dokumententypen und Form der Signaturspeicherung

Es lassen sich beliebige Dokumententypen signieren, jedoch unterscheidet sich dabei die Art und Weise der Signaturerrechnung und Speicherung der elektronischen Signatur.

  • Dokument-externe Signaturdatei: Beispielsweise werden TIFF-Grafikdateien (z.B. aus Scanning) am besten durch eine externe Signatur gesichert. Die Signaturdatei wird getrennt vom Dokument verwaltet. Dieses Verfahren ist von der Signaturverwaltung her etwas aufwendig. In diesem Fall spricht man auch von File-Signatur
  • Dokument-interne Signaturablage: Dieses Verfahren kann z.B. bei PDF-Dokumenten angewendet werden. Die Signatur wird in das PDF-Dokument in einen dafür vorgesehenen Bereich eingebettet und kann bei Bedarf angezeigt werden. Mehrfachsignaturen liegen ebenfalls im PDF-Dokument. Der Vorteil liegt darin, dass die Signaturen, die ja selbst auch Dateien sind, nicht separat gehalten und verwaltet werden müssen. Es werden nur die relevanten Teile des Dokumentinhalts signiert, dieser Fall wird daher auch als Content-Signatur bezeichnet.
  • Es muss bei beiden Formen der Signaturspeicherung geprüft werden, ob die Signatur den rechtlichen Anforderungen, die für den jeweiligen Einsatzzweck gelten, genügen. Eine Content-Signierung eines PDF Dokuments durch Acrobat oder Adobe Reader Plug-Ins ist zur Zeit (Juli 2005) für qualifizierte elektronische Signaturen zwar technisch aber rechtlich nicht möglich, da der interne Viewer von Acrobat und Adobe Reader noch nicht als sichere Anwendungskomponente im Sinne des Signaturgesetzes zertifiziert wurde. Damit ist auch die elektronische Übermittlung von Rechnungen im PDF Format mit einer Content-Signatur im Sinne des Umsatzsteuergesetzes (UStG §14) derzeit noch nicht möglich, aber sicherlich bald zu erwarten.

Gem. Bestätigungsurkunde des Bundesamts für die Sicherheit in der Informationstechnik (BSI) vom 24.11.2005 gibt es inzwischen ein PDF-Plugin, das die Anforderungen des Signaturgesetzes (SigG) erfüllt.

Nachprüfbarkeit von Zertifikaten

Für qualifizierte Signaturen ohne Anbieterakkreditierung gilt für den ZDA die Anforderung für fünf Jahre die Zertifikate vorzuhalten und somit eine Identitätsermittlung des Signaturerstellers zu ermöglichen.

Für Dokumente, die über fünf Jahre aufbewahrt werden müssen (z.B. Rechnungen), sollten qualifizierte Zertifikate mit Anbieterakkreditierung genutzt werden. Dort besteht die rechtliche Anforderung, dass der ZDA die Zertifikate für 30 Jahre vorhalten und bereitstellen muss.

Gültigkeit von Zertifikaten, Verschlüsselungsalgorithmen und erstellter Signaturen

Die heute ausgestellten Zertifikate sind in der Regel nicht länger als 3 Jahre gültig, was lediglich bedeutet, dass der zugewiesene Signaturschlüssel nach Ablauf des Zertifikats nicht mehr benutzt werden darf. Dies wird damit begründet, dass danach der geheime Schlüssel des Zertifikats aus dem öffentlichen Schlüssel eventuell berechenbar sein könnte.

Mit dem dann verfügbaren geheimen Schlüssel könnte man den Inhalt eines Dokuments ändern und – zwar zu einem späteren Zeitpunkt – mit dem originären geheimen Schlüssel den veränderten, also gefälschten Inhalt erneut signieren. Aus diesem Grund ist neben dem Zertifikat auch die Anwendung der Verschlüsselungsalgorithmen zur Sicherung des Hashwertes zeitlich beschränkt.

Auch wenn ein Zertifikat ungültig wird bzw. der damit verknüpfte Signaturschlüssel nicht mehr verwendet werden darf, also nach Ablauf der oben genannten 3 Jahre, sind die innerhalb des Gültigkeitszeitraums mit dem Signaturschlüssel erzeugten Signaturen nach wie vor rechtsgültig.

Beispiel:

Wenn jemand den Kauf eines Hauses mit seiner handschriftlichen Unterschrift bestätigt und er im weiteren Verlauf seines Lebens seine Schreibhand nicht mehr benutzen kann (der Signaturschlüssel also nicht mehr nutzbar ist), muss der Kaufvertrag des Hauses ja auch nicht neu signiert werden.

Nachsignierung

Unter Nachsignierung versteht man die erneute Signierung elektronischer Dokumente, allerdings unter Einschluss der bereits vorhandenen ursprünglichen Signaturen, die ebenfalls in den Hashwert (Prüfsumme) der Nachsignierung einbezogen werden. Eine Nachsignierung ist wie ein Umschlag um die elektronischen Dokumente, sowie der bereits vorhandenen Signaturen, zu verstehen.

Eine Prüfung der Signaturen erfolgt somit "von außen nach innen". Zuerst wird die zuletzt erstellte Signatur geprüft, dann die vorherige Nachsignierung und am Ende die originären Signaturen des Dokuments selbst.

Zweck einer Nachsignierung ist die Sicherstellung, dass Dokumente und deren Signaturen mittels eines neuen Hashwertes vor dem Gültigkeitsablauf der für die ursprünglichen Signaturen verwendeten Verschlüsselungsalgorithmen, mit den jeweils neuesten Verschlüsselungsalgorithmen eingefroren werden. Selbst wenn also die geheimen Schlüssel der ursprünglichen Signaturen aus den öffentlichen Schlüsseln nach einer Nachsignierung berechnet werden könnten, wird mit der Nachsignierung bzw. deren Prüfung nachgewiesen, dass die ursprünglichen Signaturen aus der Zeit vor der Berechnungsmöglichkeit stammen, seit der Nachsignierung unverändert sind und somit keine nachträglichen Fälschungen sind.

In wie weit bereits signierte Dokumente nachsigniert werden müssen, hängt von den jeweiligen Einsatz- und Verwendungsbedingungen ab.

Für den Fall elektronischer Rechnungen und anderer Unternehmensdokumente gilt gemäß der Grundsätze ordnungsgemäßer Buchhaltung (GoB) die Verpflichtung, Rechnungen für 10 Jahre revisionssicher zu archivieren. Wenn diese Bedingung durch ein entsprechendes elektronisches Archiv sichergestellt ist, ist eine erneute Signierung der einzelnen Dokumente nicht notwendig, da das revisionssichere Archiv die Unveränderbarkeit der im Archiv gehaltenen Dokumente garantiert.

Sofern ein revisionssicheres Archiv nicht vorhanden und eine Nachsignierung notwendig sein sollte, muss diese nicht durch den ursprünglichen Signaturersteller erfolgen. Beliebige Personen können die archivierten Dokumente nachsignieren. In der Regel werden für Nachsignierungen sogenannte Zeitstempel genutzt, die unabhängig von einer Person den Nachweis ermöglichen, dass der Inhalt einer Datei (und bereits vorhandener Signaturen) zu einem bestimmten Zeitpunkt vorlag.

Im Fall archivierter, signierter Dokumente kann die Signierung auch das Archiv selbst oder Teile davon umfassen und somit die darin enthaltenen Dokumente absichern. Die Verwendung von revisionssicheren Archiven kann eine Nachsignierung auch vollständig überflüssig machen. Dies ist jedoch im Einzelfall zu prüfen.

Literatur