Elektronische Unterschrift

Glossar
· Hauptseite · Zufälliger Artikel · Portal liste
Diskussion
· Diskussion : Elektronische Unterschrift
Webkatalog
· Übersicht · Eigene Artikel · Seite vorschlagen
Aktuelles
· Seite der Woche · Newsletter · Today in History · Kreuzworträtsel
Weitere Inhalte
· Einkaufsmeile · Begriffslexikon · Multimedia
Suche
· Geschi.de · nach Jahren · Weltchronik.de · Geschichtsreferate
Interna
· Seitenneuigkeiten · Hilfe zur Seite · Impressum

Jahres-Sprung
Jahreszahl eingeben: >Chronik2000-Homepage<

Stichpunkte

Allgemein
	Bei der digitale Signatur genannten elektronischen Unterschrift handelt es sich um den Nachweis von IntegritÃ¤t und AuthentizitÃ¤t einer Nachricht
	ZusÃ¤tzlich wird Nicht-Anfechtbarkeit erreicht
	Sie basiert meist auf asymmetrischen Kryptosystemen
	Der bekannte Ã¶ffentliche SchlÃ¼ssel (auch als (digitales) Zertifikat bezeichnet) eines Unterzeichners erlaubt die ÃœberprÃ¼fung seiner Unterschrift
	die mit seinem geheimen persÃ¶nlichen SchlÃ¼ssel erzeugt wurde
	S/MIME einer hierarchischen Authentisierungsstruktur
	Usenet
	Es bleibt das Problem zu zeigen
	was Voraussetzung ist fÃ¼r die RechtsgÃ¼ltigkeit einer digitalen Unterschrift
	etc.) vertraut einem Netz von Freunden
	ob der Ã¶ffentliche SchlÃ¼ssel wirklich dem Unterzeichner gehÃ¶rt. Das Verfahren nach PGP (E-Mail
	S/MIME steht fÃ¼r Secure / Multipurpose Internet Mail Extension. Inhaltsverzeichnis showTocToggle("Anzeigen"
	"Verbergen") 1 Etwas Mathematik 2 Technische Umsetzung 2.1 Algorithmen 2.2 PGP-Systeme 2.3 Zertifikatsbasierte Systeme 3 Rechtliche Rahmenbedingungen 3.1 Rechtliche Rahmenbedingungen Deutschland 3.2 Rechtliche Rahmenbedingungen Schweiz 4 Einsatz in der Praxis 4.1 Workflow - Ablauf einer elektronischen Signierung 4.2 Signierte Dokumententypen + Form der Signaturspeicherung 4.3 Nachsignierung 5 Literatur und weitere Informationen 6 Weblinks [Bearbeiten]
Etwas Mathematik
	die mathematisch voneinander abhÃ¤ngen. <math> K_A <math> Alices Ã¶ffentlicher SchlÃ¼ssel <math> K^{-1}_A <math> Alices geheimer SchlÃ¼ssel <math> left{ x right}_K <math> VerschlÃ¼sselung von x mit dem SchlÃ¼ssel K N eine Nachricht h(N) Hashwert der Nachricht h() ??? S Signatur Im Vorfeld lÃ¤sst Alice Bob ihren Ã¶ffentlichen SchlÃ¼ssel <math>K_A<math> zukommen
	Alice besitzt ein SchlÃ¼sselpaar K bestehend aus einem Ã¶ffentlichen und einem privaten SchlÃ¼ssel
	Dies kann auch durch einen unsicheren Kanal geschehen
	dass der SchlÃ¼ssel zweifelsfrei zu Alice gehÃ¶rt
	dass Bob weiÃŸ
	Wichtig ist nur
	bildet sie den Hashwert <math>h(N)<math> der Nachricht
	MÃ¶chte Alice nun einen Nachricht <math>N<math> fÃ¼r Bob unterschreiben
	so ist mit extrem hoher Wahrscheinlichkeit der Hashwert ein anderer
	Dieser ist eine Art PrÃ¼fsumme Ã¼ber die Nachricht; Ã¤ndert sich ein Bit der Nachricht
	dass Bob die Signatur mit dem Ã¶ffentlichen SchlÃ¼ssel von Alice (und zwar nur mit dem von Alice) wieder entschlÃ¼sseln kann
	Um eine Signatur <math>S<math> zu erhalten
	den Inhalt des Hashwertes zu verbergen
	verschlÃ¼sselt Alice diesen Hashwert mit ihrem geheimen (!) SchlÃ¼ssel. <math> S = left{ h(N) right}_{K^{-1}_A} <math> Bei der VerschlÃ¼sselung geht es nicht darum
	sondern es soll sichergestellt werden
	Nun sendet Alice die Nachricht <math>N<math> und die Signatur <math>S<math> an Bob
	Dieser berechnet nun seinerseits den Hashwert <math>h(N)<math> aus der Nachricht <math>N<math>
	Nun wendet er Alices Ã¶ffentlichen SchlÃ¼ssel auf die Signatur an <math>h' = left{ S right}_{K_A}<math> und macht somit Alices VerschlÃ¼sselung rÃ¼ckgÃ¤ngig
	Nun muss Bob nur noch vergleichen ob <math>h' = h(N)<math> um zu wissen
	dass Alice das Dokument unterschrieben hat
	Bob Ã¼berlegt sich dafÃ¼r
	den nur Alice kennen konnte
	dass der Hashwert korrekt mit einem SchlÃ¼ssel verschlÃ¼sselt wurde
	Darum glaubt er
	dass das Dokument von Alice signiert wurde
	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)
	Sollte <math>h'<math> ungleich <math>h(N)<math> sein
	Diese AblÃ¤ufe und Berechnungen werden von entsprechenden Programmen (z
	TE
	-Mail-Clients) automatisch vorgenommen. [Bearbeiten]
Technische Umsetzung
	[Bearbeiten]
Algorithmen
	Als Algorithmen zur Umsetzung eignen sich asymmetrische VerschlÃ¼sselungsverfahren
	wie RSA
	die als sicher bekannt sind
	Es gibt aber auch spezielle Signaturalgorithmen
	der auf dem Verfahren von El-Gamal basiert und auch das HerzstÃ¼ck des amerikanischen Digital Signature Standard (DSS) bildet. [Bearbeiten]
	wie DSA
PGP-Systeme
	PGP steht fÃ¼r Pretty good Privacy und wurde 1986 von Phil Zimmermann initiiert
	PGP ist selbst kein VerschlÃ¼sselungsalgorithmus
	das die z
	sondern ein Programm
	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
	Ã¼ber das auch transitive Vertrauenbeziehungen hergestellt werden kÃ¶nnen
	Dadurch entsteht ein Web of Trust
	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 (http://www.gnupp.org)) pflegt ein auf GnuPG basierendes graphisches Frontend fÃ¼r alle gÃ¤ngigen Betriebssysteme
	Das Programm WinPT (Windows Privacy Tools)
	bietet unter Windows ebenfalls eine grafische OberflÃ¤che zur komfortableren Bedienung digtaler Signierungen
	das auch auf GnuPG aufsetzt
	Mozilla Mail und Netscape Mail gibt es das komfortable Plugin Enigmail (http://enigmail.mozdev.org/)
	die von GnuPG bereitgestellten Funktionen der VerschlÃ¼sselung und Signatur direkt im Mailprogramm zu nutzen
	das es dem Benutzer erlaubt
	FÃ¼r die Mailclients Thunderbird
	Das Plugin ist OpenSource und unter die GNU Licence sowie unter die Mozilla Public Licence gestellt. [Bearbeiten]
Zertifikatsbasierte Systeme
	welches seine IdentitÃ¤t beschreibt und die Ã¶ffentlichen SchlÃ¼ssel enthÃ¤lt
	In zertifikatsbasierten Systemen erhÃ¤lt jeder Benutzer ein digitales Zertifikat
	die ihrerseits wieder von hÃ¶heren Stellen beglaubigt sein kann
	Jedes Zertifikat ist von einer ausgebenden Stelle beglaubigt
	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
	GÃ¼ltigkeitsdauer
	Verwendungszweck und Fingerprint
	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
	Die Definitionen nach PKCS legen das Inhaltsformat fest
	der Standard X.509 (genauer: ITU x.509 v3 nach RFC3280
	oftmals als Base-64 oder DER kodiert
	basierend auf ASN.1 Format) beschreibt das BinÃ¤r-Datenformat
	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
	DE emailAddress: certificate@trustcenter.de Issuer TC TrustCenter for Security in Data Networks GmbH TC TrustCenter Class 0 CA Hamburg Hamburg
	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
	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
	Certificate Authority (CA)): Certificate name TC TrustCenter for Security in Data Networks GmbH TC TrustCenter Class 0 CA Hamburg Hamburg
	S/MIME CA
	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
	um ihre die AuthentizitÃ¤t gegenÃ¼ber dem Server bestÃ¤tigen zu kÃ¶nnen
	Client-Zertifikate benÃ¶tigen ihn
	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
	d.i. der Webbrowser des Nutzers
	Ã¼berlegt
	Der Client
	ob er dem Ã¶ffentlichen SchlÃ¼ssel trauen kann
	die ihm bei der Installation mitgegeben wurden bzw. der Benutzer selbst installiert hat
	Dazu schaut er in die Liste seiner Zertifikate
	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
	kann auch die Daten entschlÃ¼sseln
	die der Client mit diesem SchlÃ¼ssel verschlÃ¼sselt zu ihm Ã¼bertrÃ¤gt
	Nur der Server
	der den Ã¶ffentlichen SchlÃ¼ssel ausgegeben hat
	wenn einem Zertifikat aus Leichtsinn VertrauenswÃ¼rdigkeit ausgesprochen wurde
	Fatal ist es
	die Hausbank zu sein
	Beispiel: Ein betrÃ¼gerischer Server gibt vor
	Der Webbrowser stellt beim ersten Besuch fest
	dass er das Zertifikat des BetrÃ¼gers nicht kennt
	Der Benutzer des Webbrowsers
	klickt auf Zertifikat annehmen
	weil er es nicht besser weiÃŸ
	Daraufhin kommunizieren der Server des BetrÃ¼gers und der Client des Benutzers Ã¼ber eine sichere Web-Verbindung
	dass Dritte die DatenÃ¼bertragung nicht abhÃ¶ren kÃ¶nnen
	Sicher in diesem Zusammenhang bedeutet
	ist durch die Leichtfertigkeit des Nutzers
	das unbekannte Zertifikat anzunehmen
	mit dem richtigen Partner zu kommunizieren
	nicht mehr gegeben
	Die Gewissheit
	sondern auch Zertifikate
	werden nicht nur spÃ¤tere Besuche des BetrÃ¼ger-Servers als sicher eingestuft
	Schlimmer noch: dadurch
	die der BetrÃ¼ger-Server signiert hat. [Bearbeiten]
	dass der Browser das Zertifikat speichert
Rechtliche Rahmenbedingungen
	[Bearbeiten]
Rechtliche Rahmenbedingungen Deutschland
	hier vor allem die Paragraphen 125 ff. Ã¼ber die Formen von RechtsgeschÃ¤ften Verwaltungsverfahrensgesetz (VwVfG)
	die 2001 durch das Formanpassungsgesetz geÃ¤ndert wurden. Daneben gelten Vorschriften der EuropÃ¤ischen Union. Das bÃ¼rgerliche Gesetzbuch erlaubt den Ersatz der schriftlichen Form durch die elektronische Form
	hier vor allem die Paragraphen 3a zur elektronischen Kommunikation und 37 zum elektronischen Verwaltungsakt. UnzÃ¤hlige weitere Rechtsvorschriften
	soweit durch Gesetz nichts anderes bestimmt ist (Â§ 126 BGB)
	Die elektronische Signatur ist durch mehrere Rechtsvorschriften geregelt: Signaturgesetz (SigG) Signaturverordnung (SigV) BÃ¼rgerliches Gesetzbuch (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)
	der fortgeschrittenen elektronischen Signatur und der qualifizierten elektronischen Signatur
	die daher hÃ¤ufig als einfache elektronische Signatur bezeichnet wird
	Das Signaturgesetz unterscheidet zwischen der elektronischen Signatur an sich
	Letztere erfordert ein gÃ¼ltiges Zertifikat und die Erzeugung mit einer Signaturerstellungseinheit
	ergÃ¤nzt um geeignete VerschlÃ¼sselungssoftware
	Das ist im Regelfall ein LesegerÃ¤t fÃ¼r Chipkarten
	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 (http://www.bsi.de) gesammelt. Die fÃ¼r qualifizierte elektronische Signaturen zugelassenen Kryptoalgorithmen werden von der RegulierungsbehÃ¶rde fÃ¼r Telekommunikation und Post (http://www.regtp.de) genehmigt und verÃ¶ffentlicht
	Dort sind auch die fÃ¼r eine qualifizierte elektronische Signatur zugelassenen Produkte aufgelistet
	aber anzeigepflichtig
	Zertifizierungsdienste sind genehmigungsfrei
	Fachkunde) erfÃ¼llt sind. [Bearbeiten]
	dass und wie die gesetzlichen Anforderungen (finanzielle Deckungsvorsorge
	ZuverlÃ¤ssigkeit
	Bei der Anzeige ist darzulegen
Rechtliche Rahmenbedingungen Schweiz
	Die elektronische Signatur ist durch das Bundesgesetz Ã¼ber Zertifizierungsdienste im Bereich der elektronischen Signatur (ZertES (http://www.admin.ch/ch/d/sr/c943_03.html)) sowie durch die Verordnung Ã¼ber Zertifizierungsdienste im Bereich der elektronischen Signatur (VZertES (http://www.admin.ch/ch/d/sr/c943_032.html)) geregelt. [Bearbeiten]
Einsatz in der Praxis
	[Bearbeiten]
Workflow - Ablauf einer elektronischen Signierung
	digitaler Fingerprint) Der Absender verschlÃ¼sselt den Hashwert mit Hilfe des privaten SchlÃ¼ssels und bildet damit die digitale Signatur 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)) Der EmpfÃ¤nger erhÃ¤lt die Nutzdatei und die Signaturdatei Der EmpfÃ¤nger dechiffriert die Signatur mit Hilfe des Ã¶ffentlichen SchlÃ¼ssels und erhÃ¤lt damit den vom Absender erzeugten Hashwert 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
	AuthentizitÃ¤t) und nicht verÃ¤ndert (IntegritÃ¤t) (Dies setzt voraus
	teils auch Online-PrÃ¼fung via Internet) Der EmpfÃ¤nger vergleicht die beiden Hashwerte: sind diese identisch
	dann wurde die Datei vom richtigen Absender verschickt (Authentifizierung
	Der Absender wÃ¤hlt die zu signierende Nutzdatei aus Die Signatur-Software bildet Ã¼ber die Nutzdatei einen Hashwert (PrÃ¼fsumme
	dass nur der gewÃ¼nschte Absender im Besitz des privaten SchlÃ¼ssels ist). Hinweis: Die signierte Datei ist nicht verschlÃ¼sselt
	Sie ist weiter lesbar
	Die Signatur dient nur zur PrÃ¼fung des richtigen Absenders und der Erkennung mÃ¶glicher DateiverÃ¤nderungen. [Bearbeiten]
Signierte Dokumententypen + Form der Signaturspeicherung
	jedoch unterscheidet sich dabei die Art und Weise der Signaturerrechnung und Speicherung der digitalen Signatur. Dokument-externe Signaturdatei: Beispielsweise werden TIFF-Grafikdateien (z.B. aus Scanning) am besten durch eine externe Signatur gesichert
	Es lassen sich beliebige Dokumententypen signieren
	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 eingearbeitet und kann vom PDF-Reader bei Bedarf angezeigt werden
	Mehrfachsignaturen liegen ebenfalls im PDF-Dokument
	Der Vorteil besteht in der vereinfachten Handhabung der Signatur
	Es werden nur Teile des Dokumentinhalts signiert
	dieser Fall wird daher auch als Content-Signatur bezeichnet. Es muÃŸ bei beiden Formen der Signaturspeicherung geprÃ¼ft werden
	genÃ¼gen
	die fÃ¼r den jeweiligen Einsatzzweck gelten
	ob die Signatur den rechtlichen Anforderungen
	Eine Integration in das PDF und die Verifikation durch den PDF - Reader ist zur Zeit (FrÃ¼hjahr 2005) nicht fÃ¼r qualifizierte elektronische Signaturen mÃ¶glich
	die fÃ¼r Rechnungen im Sinne des Umsatzsteuergesetzes (UStG Â§14) vorgeschrieben sind. [Bearbeiten]
Nachsignierung
	Die heute ausgestellten Zertifikate sind nicht lÃ¤nger als 5 Jahre gÃ¼ltig
	Dies wird damit begrÃ¼ndet
	dass dann das Zertifikat berechenbar sein kÃ¶nnte
	Aus diesem Grund kÃ¶nnen Dokumente nur in diesen Zeitraum mit dem jeweiligen Zertifikat gÃ¼ltig signiert werden. In wie weit bereits signierte Dokumente nachsigniert werden mÃ¼ssen
	hÃ¤ngt von den jeweiligen Einsatzbedingungen ab
	Rechnungen fÃ¼r 10 Jahre revisionssicher zu archivieren
	FÃ¼r den Fall elektronischer Rechnungen gilt gemÃ¤ÃŸ der GrundsÃ¤tze ordnungsgemÃ¤ÃŸer Buchhaltung (GoB) die Verpflichtung
	ist eine erneute Signierung von einzelnen Dokumenten nicht notwendig
	Wenn diese Bedingung durch ein entsprechendes elektronisches Archiv sichergestellt ist
	FÃ¼r eine Verifikation der Signatur wird jedoch der Ã¶ffentliche SchlÃ¼ssel des Signaturzertifikates benÃ¶tigt
	Dieses wird bei dem Signaturaussteller (ZDA fÃ¼r Zertifizierungsdiensteanbieter) aufbewahrt
	FÃ¼r qualifizierte Signaturen ohne Anbieterakkreditierung gilt fÃ¼r den ZDA die Anforderung fÃ¼r fÃ¼nf Jahre die Zertifikate vorzuhalten und somit eine SignaturprÃ¼fung zu ermÃ¶glichen
	die Ã¼ber zehn Jahre aufbewahrt werden mÃ¼ssen
	FÃ¼r Rechnungsdokumente
	sollten also qualifizierte Zertifikate mit Anbieterakkreditierung genutzt werden
	dass der ZDA die Zertifikate fÃ¼r 30 Jahre vorhalten und bereitstellen muÃŸ
	Dort besteht die rechtliche Anforderung
	muss diese nicht durch den bisherigen Zertifikatsinhaber erfolgen
	Sofern eine Nachsignierung notwendig sein sollte
	es kann auch ein anderes Zertifikat benutzt werden
	Im Fall archivierter
	signierter Dokumente kann die Signierung auch das Archiv 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
	also nach Ablauf der oben genannten 5 Jahre
	sind die damit erzeugten Signaturen jedoch nach wie vor gÃ¼ltig
	Wenn ein SignaturschlÃ¼ssel ungÃ¼ltig wird
	Wenn jemand den Kauf eines Hauses mit seiner handschriftlichen Unterschrift bestÃ¤tigt und er im weiteren Verlauf seines Lebens durch einen Unfall die rechte Hand verliert (das Signaturzertifikat also ungÃ¼ltig wird) muÃŸ der Kaufvertrag des Hauses ja auch nicht neu signiert werden. [Bearbeiten]
Literatur und weitere Informationen
	Lenz / Schmidt; Elektronische Signatur - eine Analogie zur eigenhÃ¤ndigen Unterschrift? Fachbuch
	Oktober 2004 (http://www.siglab.de/siglab/sigtheorie/elektronische_signatur_lenz_schmidt.html) [Bearbeiten]
Weblinks
	Kompetenzzentrum fÃ¼r Elektronische Signaturen (SigLab) (http://www.siglab.de) Leitfaden des Siglab (http://www.siglab.de/siglab/sigbus/doc/leitfaden_elektronische_signaturen_version_2.pdf) SignaturbÃ¼ndnis - Initiative von Staat und Wirtschaft in Deutschland (http://www.signaturbuendnis.de/) BSI (Bundesamt fÃ¼r Sicherheit in der Informationstechnik) (http://www.bsi.de/) Verweise zu Rechtsgrundlagen in Deutschland/Europa (http://www.iid.de/iukdg/) Simon Schlauri
	Diss
	Elektronische Signaturen
	ZÃ¼rich 2002 (Juristische Dissertation zum Thema; PDF 3.8 MB) (http://www.rwi.unizh.ch/oberassi_schlauris/Dissertation.pdf) Fachwissen rund um die Signatur
	Verfahren
	AblÃ¤ufe
	Hard- und Software (http://www.seccommerce.com/de/fachwissen/fachwissen.html) Liste mit zertifizierten Signaturanwendungskomponten fÃ¼r qualifizierte digitale Signaturen (TÃœV-IT) (http://www.tuvit.de/XS/c.020400&zerttyp=2/r.020400/sprache.DE/SX/) Bildhafte ErlÃ¤uterung und Beschreibung von Signaturarten (edulab) (http://www.digitale-signatur.edulab.de/thema.html) Kostenfreie VerifikationsmÃ¶glichkeit im Internet fÃ¼r Signaturen gem
	SigG. (http://www.sig-check.de) Bitte beachten Sie auch den Hinweis zu Rechtsthemen! Vorlage:Deutschlandlastig en:Digital signature fr:Signature numÃ©rique he:×—×ª×™×ž×” ×?×œ×§×˜×¨×•× ×™×ª it:Firma digitale pl:Podpis cyfrowy pt:Assinatura digital ru:ÐÐ»ÐµÐºÑ‚Ñ€Ð¾Ð½Ð½Ð°Ñ? Ñ†Ð¸Ñ„Ñ€Ð¾Ð²Ð°Ñ? Ð¿Ð¾Ð´Ð¿Ð¸Ñ?ÑŒ

[X] Schliessen

Dieser Artikel basiert auf dem Artikel Elektronische Unterschrift aus der freien Enzyklopädie wikipedia und steht unter der GNU Lizenz für freie Dokumentation. In der wikipedia ist eine Liste der Autoren verfügbar.

Wald (BegriffsklÃ¤rung) Irrtumswahrscheinlichkeit Konzern Gerhard Seyfried Kapitalismus BÃ¼rgermeister

[Zurück ]

Inhalt Glossar:

Diese Seite einem Freund, Kollegen oder Bekannten weiterempfehlen? Hier klicken!

Allgemein

Etwas Mathematik

Technische Umsetzung

Algorithmen

PGP-Systeme

Zertifikatsbasierte Systeme

Rechtliche Rahmenbedingungen

Rechtliche Rahmenbedingungen Deutschland

Rechtliche Rahmenbedingungen Schweiz

Einsatz in der Praxis

Workflow - Ablauf einer elektronischen Signierung

Signierte Dokumententypen + Form der Signaturspeicherung

Nachsignierung

Literatur und weitere Informationen

Weblinks