Elektronische Siegel Urkunden: Difference between revisions
Abertoglia (talk | contribs) |
Abertoglia (talk | contribs) |
||
Line 160: | Line 160: | ||
Beispiel 2: Hier vereinfacht sehen wir, wie Alice ihre Nachricht an Bob mit ihrem privaten Schlüssel signiert und dann Bob die Signatur der Nachricht mit Alices öffentlichem Schlüssel verifiziert. |
Beispiel 2: Hier vereinfacht sehen wir, wie Alice ihre Nachricht an Bob mit ihrem privaten Schlüssel signiert und dann Bob die Signatur der Nachricht mit Alices öffentlichem Schlüssel verifiziert. |
||
=== |
===Design Schwächen=== |
||
* Die Verwendung |
* Die Verwendung von schwarzen Listen ungültiger Zertifikate (wie CRLs und OCSP) kann zu Problemen führen, insbesondere wenn CRLs nicht verfügbar sind. |
||
* CRLs haben Nachteile aufgrund ihrer Größe und komplizierten Verteilungsmuster. |
* CRLs haben Nachteile aufgrund ihrer Größe und komplizierten Verteilungsmuster. |
||
* OCSP hat mehrdeutige Semantik und bietet keine historischen Widerrufsstatusinformationen. |
* OCSP hat mehrdeutige Semantik und bietet keine historischen Widerrufsstatusinformationen. |
||
* Die Widerrufung von Stammzertifikaten wird nicht behandelt. |
* Die Widerrufung von Stammzertifikaten wird nicht behandelt. |
||
* Probleme mit der Aggregation von Identitäts-, Attribut- und Richtlinienansprüchen in einem einzigen Container. |
|||
* Delegationsprobleme treten auf, da CAs die Ausstellung von Zertifikaten nicht auf bestimmte Namensräume oder Attribute beschränken können. |
* Delegationsprobleme treten auf, da CAs die Ausstellung von Zertifikaten nicht auf bestimmte Namensräume oder Attribute beschränken können. |
||
* Probleme mit föderierten Zertifikatsketten und dem Fehlen von bilateralen Vertrauensbeziehungen. |
* Probleme mit föderierten Zertifikatsketten und dem Fehlen von bilateralen Vertrauensbeziehungen. |
||
Line 171: | Line 170: | ||
===Probleme mit Zertifizierungsstellen=== |
===Probleme mit Zertifizierungsstellen=== |
||
* CAs senken oft ihre Preise und entfernen teure Validierungsprüfungen, um wettbewerbsfähig zu bleiben, was als "Race to the Bottom" bezeichnet wird. |
* CAs senken oft ihre Preise und entfernen teure Validierungsprüfungen, um wettbewerbsfähig zu bleiben, was als "Race to the Bottom" bezeichnet wird. |
||
* Extended Validation (EV) Zertifikate können das Vertrauen von Sicherheitsexperten nicht vollständig wiederherstellen. |
|||
* CAs lehnen in ihren Zertifikatspraxiserklärungen oft fast alle Garantien für Benutzer und vertrauende Parteien ab. |
* CAs lehnen in ihren Zertifikatspraxiserklärungen oft fast alle Garantien für Benutzer und vertrauende Parteien ab. |
||
* CA's unterliegen die rechtlichen Zuständigkeiten deren Geschäftssitz und können gesetzlich verpflichtet sein, die Interessen ihrer Kunden und Benutzer zu beeinträchtigen. |
|||
===Umsetzungsprobleme=== |
===Umsetzungsprobleme=== |
||
* Viele Implementierungen schalten die Überprüfung von Widerrufsinformationen aus, was die Einhaltung von Richtlinien erschwert. |
* Viele Implementierungen schalten die Überprüfung von Widerrufsinformationen aus, was die Einhaltung von Richtlinien erschwert. |
||
* Es gibt Schwierigkeiten mit |
* Es gibt allgemein Schwierigkeiten mit Notationen, einheitlichen internationalen Standards und mehrdeutigen Attributen. |
||
⚫ | |||
* Die Durchsetzung benutzerdefinierter OIDs ist schwierig. |
|||
⚫ | |||
* Implementierungsfehler ermöglichen falsche Subjektnamen und Codeinjektionsangriffe. |
* Implementierungsfehler ermöglichen falsche Subjektnamen und Codeinjektionsangriffe. |
||
===Kryptografische Schwächen=== |
===Kryptografische Schwächen=== |
||
* |
* Elektronische Siegelsysteme sind grundsätzlich auf sichere kryptografische Hashfunktionen angewiesen. Falls die PKI unsichere Hashfunktionen zulässt oder einem Angreifer eine Kollision gelingt, könnten Siegel verfälscht werden. |
||
* Zum Beispiel, MD2-basierte Zertifikate wurden lange Zeit verwendet und waren anfällig für Preimage-Angriffe. Da das Stammzertifikat bereits eine Selbstsignatur hatte, konnten Angreifer diese Signatur nutzen und für ein Zwischenzertifikat verwenden. |
|||
* Schwache Hashfunktionen können es Angreifern ermöglichen, gefälschte Zertifikate zu erstellen. |
|||
* MD2-basierte Zertifikate waren lange Zeit anfällig für Preimage-Angriffe. |
|||
* MD5-basierte Zertifikate wurden durch Kollisionen verwundbar. |
|||
* Forscher haben gezeigt, dass selbst SHA-1 Schwächen aufweist, was zu gefälschten Zertifikaten führen kann. |
|||
== Angriffe == |
== Angriffe == |
Revision as of 12:00, 3 December 2023
Aufbau eines PDFs
Um elektronische Signaturen und auch Siegel zu verstehen, sind zu aller erst Grundlagen notwendig wie überhaupt ein PDF (Portable Document Format) aufgebaut ist und wie es gelesen wird. Um dies zu verstehen wird ein PDF im Texteditor geöffnet.
Als Beispiel haben wir das PDF "Hallo Welt":
%PDF-1.7
1 0 obj
<< /Title (Hallo Welt) >>
endobj
2 0 obj
<< /Type /Catalog
/Pages 3 0 R
>>
endobj
3 0 obj
<< /Type /Pages
/MediaBox [0 0 595 842]
/Resources
<< /Font << /F1 4 0 R >>
/ProcSet [/PDF /Text]
>>
/Kids [5 0 R]
/Count 1
>>
endobj
4 0 obj
<< /Type /Font
/Subtype /Type1
/BaseFont /Helvetica
/Encoding /WinAnsiEncoding
>>
endobj
5 0 obj
<< /Type /Page
/Parent 3 0 R
/Contents 6 0 R
>>
endobj
6 0 obj
<< /Length 41
>>
stream
/F1 48 Tf
BT
72 746 Td
(Hallo Welt) Tj
ET
endstream
endobj
xref
0 7
0000000000 65535 f
0000000009 00000 n
0000000050 00000 n
0000000102 00000 n
0000000268 00000 n
0000000374 00000 n
0000000443 00000 n
trailer
<< /Size 7
/Root 2 0 R
>>
startxref
534
%%EOF
Dabei lesen wir ein PDF von unten nach oben beginnend mit dem Trailer
trailer
<< /Size 7
/Root 2 0 R
>>
startxref
534
%%EOF
Dabei erkennt der PDF-Reader unter Root, dass 2 0 das erste bearbeitete Objekt ist und unter startxref, dass er die xref-Tabelle beim Byte 534 findet.
Von dort aus greift das Programm dann auf die xref-Tabelle zu:
xref
0 7
0000000000 65535 f
0000000009 00000 n
0000000050 00000 n
0000000102 00000 n
0000000268 00000 n
0000000374 00000 n
0000000443 00000 n
Hier sieht man zuerst die Anzahl der Objekte im Dokument und anschließend das Byteoffset. Das f am Ende der Zeile steht dafür, dass es nicht angezeigt wird und das n, dass das Objekt sichtbar ist.
2 0 obj
<< /Type /Catalog
/Pages 3 0 R
>>
endobj
Die Objekte bestehen aus den tatsächlichen Inhalten des PDFs und referenzieren auf spätere Objekte.
Allgemeines zu elektronische Siegel und Signaturen
Elektronische Siegel und Signaturen sind Sicherheitsverfahren, die dazu verwendet werden, die Integrität, Authentizität und Unveränderlichkeit von elektronischen Dokumenten oder Informationen zu gewährleisten. Im Gegensatz zu herkömmlichen physischen Siegeln, die auf Papier aufgedruckt oder angebracht werden, nutzen elektronische Siegel kryptografische Verfahren, um sicherzustellen, dass ein Dokument nicht unbefugt geändert wurde und die Identität des Absenders authentisch ist.
Elektronische Siegel und Signaturen benötigen eine Sicherheitsinfrastruktur um implementiert zu werden. Die Gültigkeit der erstellten Zertifikate ist zeitlich begrenzt und wird durch einen Zeitstempel kontrolliert.
Elektronische Signaturen basieren auf die X.509 Standard und werden sowohl in online Protokolle wie TLS/SSl als auch in offline Bereich für elektronische Signaturen benutzt.
Darüber hinaus existiert der Advanced Electronic Signature (AES) Standard basieren auf die EU Verordnung Nr. 910/2014 (eIDAS) mit folgenden Anforderungen:
- Der Unterzeichner kann eindeutig identifiziert und mit der Unterschrift verknüpft werden.
- Der Unterzeichner muss die alleinige Kontrolle über die zur Erstellung der elektronischen Unterschrift verwendeten Daten haben (in der Regel ein privater Schlüssel).
- Die Unterschrift muss in der Lage sein, festzustellen, ob die begleitenden Daten nach der Unterzeichnung des Dokuments manipuliert wurden.
- Falls die begleitenden Daten geändert wurden, muss die Unterschrift ungültig werden.
Dadurch wird auch zwischen verschiedenen formen von elektronischen Signaturen unterschieden wie der (normale) Signatur, der Fortgeschrittene Signatur und der Qualifizierte Signatur, jede mit unterschiedlichen Zwecken und Befugnissen.
Versiegelung durch QR-Code
Als Beispiel sehen wir uns die Studienbescheinigung der HU Berlin an. Dort gibt es eine Möglichkeit per QR-Code auf die Verifizierungsseite zu kommen. Die Verifizierungsseite wird dabei auf dem Dokument selbst angegeben.
Die Vorteile davon sind die einfache Einführung des Systems und die vielfältige Einsetzbarkeit. Allerdings ist es auch anfällig für:
- Sybil-Angriffe
- Verifizierungsprozess ist umständlich und erfordert externe Ressourcen
- Verifizierung erfolgt online
Versiegelung durch elektronische Signatur
In der Praxis werden die Richtlinien für elektronische Siegel und Signaturen mithilfe von Public-Key-Kryptographie im Rahmen einer Public-Key-Infrastruktur (PKI) umgesetzt.
Beispiel 1: Cross-Zertifizierung auf Root-Zertifizierungsstellen-Ebene zwischen zwei PKIs Um sicherzustellen, dass Benutzerzertifikate in PKI 2 (wie "Benutzer 2") von PKI 1 als vertrauenswürdig eingestuft werden, erstellt CA1 ein Zertifikat (cert2.1), das den öffentlichen Schlüssel von CA2 enthält.
Nun haben sowohl "cert2" als auch "cert2.1" (in grün) denselben Betreff und öffentlichen Schlüssel, daher gibt es zwei gültige Zertifikatsketten für cert2.2 (Benutzer 2): "cert2.2 → cert2" und "cert2.2 → cert2.1 → cert1".
Ebenso kann CA2 ein Zertifikat (cert1.1) generieren, das den öffentlichen Schlüssel von CA1 enthält, damit Benutzerzertifikate in PKI 1 (wie "Benutzer 1") von PKI 2 als vertrauenswürdig eingestuft werden.
Um die PKI effektiv zu nutzen, ist eine Online-Verbindung erforderlich, trotz ihrer Selbstauthentifizierungsfähigkeit:
- CRL - Certificate Revocation List (X.509, alle 24 Stunden)
- OCSP - Online Certificate Status Protocol (Echtzeit, geringerer Bandbreitenverbrauch)
Diese Aufzeichnungen werden aktiv erneuert, was zu einer kurzen Lebensdauer (2-5 Jahre) führt, um elektronische Siegel und Signaturen online zu authentifizieren.
Beispiel 2: Hier vereinfacht sehen wir, wie Alice ihre Nachricht an Bob mit ihrem privaten Schlüssel signiert und dann Bob die Signatur der Nachricht mit Alices öffentlichem Schlüssel verifiziert.
Design Schwächen
- Die Verwendung von schwarzen Listen ungültiger Zertifikate (wie CRLs und OCSP) kann zu Problemen führen, insbesondere wenn CRLs nicht verfügbar sind.
- CRLs haben Nachteile aufgrund ihrer Größe und komplizierten Verteilungsmuster.
- OCSP hat mehrdeutige Semantik und bietet keine historischen Widerrufsstatusinformationen.
- Die Widerrufung von Stammzertifikaten wird nicht behandelt.
- Delegationsprobleme treten auf, da CAs die Ausstellung von Zertifikaten nicht auf bestimmte Namensräume oder Attribute beschränken können.
- Probleme mit föderierten Zertifikatsketten und dem Fehlen von bilateralen Vertrauensbeziehungen.
Probleme mit Zertifizierungsstellen
- CAs senken oft ihre Preise und entfernen teure Validierungsprüfungen, um wettbewerbsfähig zu bleiben, was als "Race to the Bottom" bezeichnet wird.
- CAs lehnen in ihren Zertifikatspraxiserklärungen oft fast alle Garantien für Benutzer und vertrauende Parteien ab.
- CA's unterliegen die rechtlichen Zuständigkeiten deren Geschäftssitz und können gesetzlich verpflichtet sein, die Interessen ihrer Kunden und Benutzer zu beeinträchtigen.
Umsetzungsprobleme
- Viele Implementierungen schalten die Überprüfung von Widerrufsinformationen aus, was die Einhaltung von Richtlinien erschwert.
- Es gibt allgemein Schwierigkeiten mit Notationen, einheitlichen internationalen Standards und mehrdeutigen Attributen.
- Die Länge von Attributen ist nicht eindeutig definiert
- Implementierungsfehler ermöglichen falsche Subjektnamen und Codeinjektionsangriffe.
Kryptografische Schwächen
- Elektronische Siegelsysteme sind grundsätzlich auf sichere kryptografische Hashfunktionen angewiesen. Falls die PKI unsichere Hashfunktionen zulässt oder einem Angreifer eine Kollision gelingt, könnten Siegel verfälscht werden.
- Zum Beispiel, MD2-basierte Zertifikate wurden lange Zeit verwendet und waren anfällig für Preimage-Angriffe. Da das Stammzertifikat bereits eine Selbstsignatur hatte, konnten Angreifer diese Signatur nutzen und für ein Zwischenzertifikat verwenden.
Angriffe
QR-Code Hijacking
Wir führen eine Sybil-Attacke, indem wir ein fiktives Dokument im Namen der Humboldt Universität erstellen die uns unwahre Leistungen akkreditiert. Dafür erstellen wir zuerst ein Dokument, das einer Bescheinigung der Humboldt Universität entspricht, mit einen QR-Code die zu unserer Webseite hinführt. Unsere Webseite ähnelt dem Aussehen der Humboldt Verifizierungsseite und ist durch ausgeklügelte URL-Gestaltung schwer von einer echte Webseite der Humboldt zu unterscheiden. Zum Ausprobieren dürfen Sie gerne folgende PDF öffnen:
File:StudienbescheinigungDruck.pdf
Incremental Saving Angriff
PDFs haben eine Funktion des Inkrementellen Updates, wobei die PDF am Ende der Datei ein Body Update, eine neue XRef Tabelle und einen neuen Trailer erhält. Leider haben wir es nicht geschafft, ein solches Update nachzubauen. Dennoch teilen wir hier unseren Versuch:
%PDF-1.7
1 0 obj
<< /Title (Hallo Welt) >>
endobj
2 0 obj
<< /Type /Catalog
/Pages 3 0 R
>>
endobj
3 0 obj
<< /Type /Pages
/MediaBox [0 0 595 842]
/Resources
<< /Font << /F1 4 0 R >>
/ProcSet [/PDF /Text]
>>
/Kids [5 0 R]
/Count 1
>>
endobj
4 0 obj
<< /Type /Font
/Subtype /Type1
/BaseFont /Helvetica
/Encoding /WinAnsiEncoding
>>
endobj
5 0 obj
<< /Type /Page
/Parent 3 0 R
/Contents 6 0 R
>>
endobj
6 0 obj
<< /Length 41
>>
stream
/F1 48 Tf
BT
72 746 Td
(Hallo Welt) Tj
ET
endstream
endobj
xref
0 7
0000000000 65535 f
0000000009 00000 n
0000000050 00000 n
0000000102 00000 n
0000000268 00000 n
0000000374 00000 n
0000000443 00000 n
trailer
<< /Size 7
/Info 1 0 R
/Root 2 0 R
>>
startxref
534
%%EOF
8 0 obj
<<
/Length 41
>>
stream
/F1 48 Tf
BT
72 746 Td
(Hello World) Tj
ET
endstream
endobj
xref
0 8
0000000000 65535 f
0000000009 00000 n
0000000050 00000 n
0000000102 00000 n
0000000268 00000 n
0000000374 00000 n
0000000443 00000 n
0000000535 00000 n
trailer
<< /Size 9
/Info 8 0 R
/Root 2 0 R
>>
startxref
923
%%EOF
Diese Funktion ermöglicht es, das Dokument zu ändern. Es gibt PDF-Reader die nicht erkennen, dass nicht das ganze Dokument signiert ist.
Signature Wrapping Angriff
Durch diese Funktion ist es möglich ein signiertes PDF zu verändern, ohne die Signatur zu zerstören.
Hier wird zuerst die Byte-Range c geändert. Danach wird eine neue xref-Tabelle mit den neuen Objekten erstellt. Dabei wichtig ist, dass die Tabelle das gleiche ByteOffset behält. Am Ende fügt man die bösartigen Objekte am Ende der Datei ein.
Universal Signature Forging
Direkter Angriff auf der Signatur, sein Inhalt und seine Byte Range. Dabei werden Werte geändert oder wegelassen.
Langzeit Archivierung von elektronische Siegel und Signaturen
Blanchette (2006) erörtert drei Möglichen Wege für digitale Archive:
- Digitale Signaturen/Siegel aufbewahren
- Digitale Signaturen/Siegel zu entfernen
- Die Spuren der digitale Signaturen/Siegel als Metadaten aufbewahren.
Blockchain Technologie erlaubt uns eine vierte Möglichkeit für digitale Archive mit Trustchain.
Forward Secure Seals & Signatures
Forward-Security erfasst die Idee, dass es selbst im Falle einer Offenlegung des aktuellen geheimen Schlüssels für jeden Angreifer rechnerisch unmöglich sein sollte, eine Signatur für einen vergangenen Zeitraum zu fälschen. Die erste formelle Forward-Secure Signatur Verfahren wurde von Bellare and Miner in 1999 präsentiert.
Itkins und Reyzin (2001) stellen ein Verfahren vor die Forward-Security auf digitalen Signaturen garantiert.
Keyless Digital Seals & Signatures
Schlüssellose Signaturen sind eine alternative Lösung zu traditionellen PKI-Signaturen. Das Wort 'schlüssellos' bedeutet nicht, dass bei der Erstellung der Signatur keine kryptografischen Schlüssel verwendet werden.
Schlüssel sind nach wie vor für die Authentifizierung erforderlich, aber die Signaturen können zuverlässig überprüft werden, ohne die fortgesetzte Geheimhaltung der Schlüssel vorauszusetzen.
Wünsche für einen digitalen Siegel
Wir hätten gerne eine automatische Verifizierung, Schutz vor Sybil Angriffen und eine unabhängige Verifizierung wie TLS/SSL Zertifikate.
Wir haben uns dabei ein Siegel ausgedacht: Unser Siegel besteht aus einer Datenbank, in welcher die Namen der Institutionen mit deren Verifikationswebseiten verknüpft sind, und einer elektronischen Signatur, welche den Namen der Institution, des Empfängers, der Dokumentart und einen Verfikationscode beinhaltet.
META-Daten: - Empfänger - Institution - Dokumentenart
Ein Beispiel: