Digitale Signaturen
Vortrag zum Oberseminar
Datenmanagement
Übersicht
Prinzip
Technische Infrastruktur
Standards
Recht
Quellen
Anwendung an der HTWK
Prinzip
Verschlüsselung mit öffentlichem Schlüssel
Prinzip
Unterschreiben mit privatem Schlüssel
Prinzip
Problem: Wem gehört der öffentliche Schlüssel?
Lösung: Benutzung digitaler Zertifikate!
Zertifikat enthält
Öffentlichen Schlüssel
Namen des Besitzers
Zusätzliche Informationen
Zertifikat ist von unabhängiger Instanz signiert Schutz vor unbemerkten Änderungen
Wer darf Zertifikate signieren?
Technische Infrastruktur
Vertrauensmodelle:
Direktes Vertrauen
Netz des Vertrauens
Hierarchisches Vertrauen
Technische Infrastruktur
Direktes Vetrauen
Jeder signiert sein eigenes Zertifikat meistens Verzicht auf digitale Zertifikate
Jeder vertraut nur den Schlüsseln, die er persönlich erhalten hat
So gut wie keine Infrastruktur nötig, jeder benötigt eine Signatur- und/oder Verschlüsselungslösung
Policies nicht durchsetzbar, Schlüsselsperrung nahezu unmöglich
Rechtlich nicht beweiskräftig
Technische Infrastruktur
Netz des Vertrauens:
Jeder darf Zertifikate für jeden anderen signieren
Jeder vertraut nur den Schlüsseln, die jemand signiert hat, dem er vertraut (Beispiel c't-Kryptokampagne oder Policy Certification Authority des DFN)
Prinzipiell keine Infrastruktur nötig, meistens Nutzung eines Zertifikatservers (z.B. PGP-Keyserver)
Policies schwierig durchsetzbar, Schlüsselsperrung nahezu unmöglich
Rechtlich nicht beweiskräftig, Zugehörigkeit des öffentlichen Schlüssels kann abgestritten werden
Technische Infrastruktur
Hierarchisches Vertrauen:
Zertifikate werden nur von einer Zertifizierungsinstanz (CA) signiert Vorraussetzung: der öffentliche Schlüssel der CA ist jedem bekannt
Zertifikatserver, Zertifizierungs- und Registrierungsinstanz meist zusammen in geschützter Umgebung (Trust Center)
Policies leicht durchsetzbar, Schlüsselsperrung zentral
Unterschiedliche Trust Level je nach Überprüfung der Person
Rechtlich beweiskräftig
Kostenintensiv
Technische Infrastruktur
Einfache einstufige
Zertifizierungshierarchie
Technische Infrastruktur
Zweistufige Hierarchie nach deutschem
Signaturgesetz
Strikt hierarchisches Modell
Alle Zertifikate auf Wurzelzertifikat zurückführbar
Technische Infrastruktur
Realität
Technische Infrastruktur
Identrus:
1999 von acht der weltweit größten Finanzinstitute gegründet Ziel: globale PKI für den B2B – Bereich
dreistufiges Modell, Wurzel-CA ist ein Trust Center von Identrus, mehrere auf militärischem Niveau gesicherte Datenzentren in Kanada und den Niederlanden
beteiligte Banken betreiben CAs (Level 1), die digitale Zertifikate für die CAs ihrer Firmenkunden ausstellen (Level 2)
Endanwender sind autorisierte Mitarbeiter der Level-2-
Unternehmen oder von den Banken direkt zertifizierte Personen
z.Z. sind 60 Finanzinstitutionen Mitglied
Technische Infrastruktur
Technische Infrastruktur
Speicherung der Signaturen
dokument-extern: z.B. bei Grafiken, Signaturdatei getrennt gespeichert und verwaltet, Dokument wird komplett
signiert, Handhabung aufwendig
dokument-intern: z.B. bei PDF-Dateien, Signatur in der Datei enthalten, auch Merhfachsignaturen im Dokument möglich, nur Teile des Dokuments werden signiert, einfach Handhabung
Verwendbarkeit im Sinne des Signaturgesetzes ist immer zu prüfen (Adobe Reader unterstützt noch keine
qualifizierten elektronischen Signaturen)
Standards - OpenPGP
Standardisiert von der IETF
Zertifikate mit mehreren digitalen Signaturen möglich
Grad des Vertrauens wählbar
OpenPGP auch von CAs für digitale Zertifikate verwendbar tauglich für hierarchisches Modell
Möglichkeit zum Festlegen der Tiefe fehlt hat sich bei CAs nicht durchgesetzt
Vorherrschender Standard für das Web of Trust
Inhalt und Anhänge einer Mail müssen getrennt verschlüsselt werden
Kostenlos
Standards – X.509 (S/MIME)
Format für digitale Zertifikate
Enthält Name des Besitzers, Name der CA, den öffentlichen Schlüssel, Gültigkeitsdauer u.a.
Profile (Einschränkungen) definierbar (z.B. PKIX-Standard vom IETF, SigI vom BSI)
Auch eingesetzt bei Webservern für SSL
Standardmäßige Unterstützung durch viele Mailprogramme, Outlook, Mozilla
bis jetzt keine Unterstützung durch Opera (Stand September 2004)
Standards – X.509 (S/MIME)
Gemäß Version 3 des X.509-Standards muss ein digitales Zertifikat folgende Angaben (Felder) enthalten:
Version: Versionsnummer (hier v3)
Seriennummer: Diese ist für jedes Zertifikat eines Herausgebers eindeutig, das heißt, ein Zertifikat ist durch diese Nummer und den Herausgeber eindeutig bestimmt.
Signatur: Bezeichnung des Algorithmus, mit dem der Herausgeber das Zertifikat signiert.
Herausgeber: eindeutiger Name des Herausgebers.
Gültigkeit: Gültigkeitszeitraum des Zertifikates.
Inhaber: eindeutiger Name des Zertifikatsinhabers.
Öffentlicher Schlüssel: öffentlicher Schlüssel des Inhabers und Bezeichnung des Algorithmus, mit dem der Schlüssel verwendet wird.
Zudem gibt es noch eine Reihe optionaler Felder (Erweiterungen), beispielsweise folgende:
Verwendungszweck: Dieser gibt an, wofür das Schlüsselpaar genutzt werden darf (Signieren, Verschlüsseln, Zertifikate Signieren, ...).
Pfadlänge: gibt die maximal erlaubte Tiefe einer Zertifizierungshierarchie an (nur bei CA-Zertifikaten).
CRL Distribution Point: gibt an, wo die Sperrliste verfügbar ist.
Certificate Policies: eine Adresse (beispielsweise eine URL), unter welcher die Richtlinien für die Generierung und Verwaltung dieser Zertifikate schriftlich festgehalten sind.
Alternative Namen für Herausgeber und Inhaber: Dies können zum Beispiel E-Mail-Adressen sein.
Standards – X.509 (S/MIME)
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
Standards – X.509 (S/MIME)
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
…………
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
…………
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
Standards
Was setzt sich durch?
Wenige PGP-Implementierungen verfügbar verglichen zu X.509
X.509-Infrastruktur ist aufwending Aufbau von Trust Centern dauerte
PGP wurde sehr beliebt, Web of Trust bei Privatanwendern sehr beliebt
In Unternehmen ist ein Hierarchisches Modell unabdingbar Nutzung von X.509
Vorerst parallele Existenz von OpenPGP und X.509
Recht - Gesetze
Signaturgesetz 1997
EU-Richtlinie aus dem Jahr 1999, umgesetzt in Deutschland 2001
Regelung in mehreren Rechtsvorschriften:
Signaturgesetz (SigG)
Signaturverordnung (SigV)
Bürgerliches Gesetzbuch (BGB), vor allem §§125 ff.
Verwaltungsverfahrensgesetz (VwVfG)
Recht - Gesetze
Unterscheidung zwischen einer "einfachen" und einer "fortgeschrittenen" (auch "qualifizierten") elektronischen Signatur
Einfache elektronische Signatur
Einfache Signatur bekannt von PGP
Schlüssel kann selbst erzeugt werden
Verwendung basierend auf dem Haftungsprinzip
Recht - Gesetze
Fortgeschrittene digitale Signatur
Signatur darf ausschließlich dem Unterzeichner zugewiesen sein
sie kann den Unterzeichner identifizieren (Zertifikat)
sie wird mit Mitteln erstellt, die der Unterzeichner unter seiner alleinigen Kontrolle halten kann
sie ist so mit den Daten, auf die sie sich bezieht,
verknüpft, das eine nachträgliche Änderung der Daten erkannt werden kann
Recht - Gesetze
Zertifizierungsdienste sind genehmigungsfrei, aber anzeigepflichtig
Anzeige beinhaltet Angaben zur finanziellen
Deckungsvorsorge, Zuverlässigkeit, Fachkunde…
unangemeldete Kontrollen zur Durchsetzung der Gesetze
auch nicht-gesetzeskonforme Verfahren und Zertifizierungsinstanzen erlaubt
Recht - Beweiskraft
Signaturen heute nur 5 Jahre gültig
Nach Ablauf Zertifikate speichern oder Nachsignieren der Dokumente, Signatur bleibt weiterhin gültig!!!
Bei wichtigen Dokumenten Nutzung eines Akkreditierten Anbieters Zertifikate müssen 30 Jahre vorgehalten werden
Recht - Beweiskraft
Langfristige Aufbewahrung elektronisch signierter Dokumente ist ein bisher ungelöstes Problem!
Kryptographieverfahren verlieren an Sicherheit Neuversiegelung nötig
Ablauf der Fristen von Wurzel-, Aussteller- und Nutzerzertifikat muss ständig überprüft werden
Nachweis nötig, dass ein Dokument immer sicher verschlüsselt war
Automatische Verfahren nötig ArchiSig, Projekt des
Bundeswirtschaftsministeriums, geeignet für große Archive, Erprobung im Universitätsklinikum Heidelberg (Ende 2003)
Quellen
c't – Artikel aus den Jahren 2001 – 2004
Bundesamt für Sicherheit in der Informationstechnik - www.bsi.de
DFN-PKI Policy Certification Authority – www.pca.dfn.de
Wikipedia – www.wikipedia.org
Signaturbündnis - www.signaturbuendnis.de
www.identrus.com
Anwendung an der HTWK
Wo?
E-Mail (Outlook, Mozilla, Netscape…)
PDF (Adobe Acrobat)
(Noten-) Aushänge
Wer?
Nur Angestellte oder auch Studenten?
Wie?
Wie lange sollen die Zertifikate gültig sein?
Welche Vertrauenstufe wird benötigt?
Wo werden die Zertifikate gespeichert? (LDAP?)
