Elektronische Siegel Urkunden

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:

1. Der Unterzeichner kann eindeutig identifiziert und mit der Unterschrift verknüpft werden.
2. Der Unterzeichner muss die alleinige Kontrolle über die zur Erstellung der elektronischen Unterschrift verwendeten Daten haben (in der Regel ein privater Schlüssel).
3. Die Unterschrift muss in der Lage sein, festzustellen, ob die begleitenden Daten nach der Unterzeichnung des Dokuments manipuliert wurden.
4. 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. Damit werden Datenbanken geladen die uns die Verifizierung der Signatur ermöglichen:

• 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 bis 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:

1. Digitale Signaturen/Siegel aufbewahren
2. Digitale Signaturen/Siegel zu entfernen
3. Die Spuren der digitale Signaturen/Siegel als Metadaten aufbewahren.

Blockchain Technologie erlaubt uns eine vierte Möglichkeit für digitale Archive mit Trustchain.

Trustchain zielt darauf ab, die Herausforderungen der langfristigen Aufbewahrung digital signierter Dokumente zu bewältigen, insbesondere wenn Zertifikate ablaufen oder Zertifizierungsstellen ihre Funktion einstellen. Durch die Verwendung von Blockchain-Technologie schlagen die Autoren ein halb offenes System vor, in dem bestimmte Institutionen neue Einträge erstellen können, während jede interessierte Partei die Aufzeichnungen anzeigen und ihre Echtheit bestätigen kann. Das Modell bietet zeitunabhängige Bestätigung durch den Hash-Vergleich des Dokuments in der digitalen Signatur, während es die zeitabhängigen Herausforderungen durch die Zusammenarbeit mehrerer unabhängiger Institutionen und die Nutzung einer Blockchain angeht.

Die Lösung basiert auf einer Fusion der Blockchain-Technologie, wie im Bitcoin-Whitepaper beschrieben, und den Prinzipien der ursprünglichen Haber- und Stornetta-Zeitstempelverknüpfungs- und Zufallszeugenlösungen. TrustChain, entwickelt als Teil des TRUSTER Preservation Model (EU31) im InterPARES Trust internationalen Projekt, garantiert, dass Dokumente und Signaturen unverändert bleiben, seit der TrustChain-Eintrag erstellt wurde. Diese Herangehensweise schafft Vertrauen durch die Zusammenarbeit mehrerer Institutionen und bietet eine innovative Lösung für die langfristige Sicherung digital signierter Dokumente.

Die Autoren betonen, dass TrustChain zwar nicht die Lebensdauer digitaler Zertifikate verlängern kann, jedoch eine zuverlässige Sicherheit bietet, selbst wenn Zertifikate abgelaufen sind. Das Modell adressiert somit eine wichtige Lücke in der Sicherung digitaler Signaturen und wird als eine von mehreren Lösungen im Rahmen des InterPares Trust-Projekts betrachtet, das verschiedene Fallstudien, einschließlich digital signierter Rentenunterlagen und medizinischer Aufzeichnungen, umfasst.

Die TrustChain-Blockchain ist frei zugänglich, jedoch dürfen nur autorisierte Mitglieder neue Daten schreiben. Dies erfolgt zur Erfüllung archivarischer Anforderungen oder auf Anfrage interessierter Parteien. Die Kommunikation erfolgt über spezialisierte Software oder eine Web-Schnittstelle. Der Prozess zur Hinzufügung eines Dokuments beginnt mit der Auswahl eines digital signierten Dokuments, dessen Signatur durch eine Zertifizierungsstelle validiert wird. Das eigentliche Dokument wird außerhalb gespeichert, während TrustChain einen Kontroll-Hash speichert. Die Technologie wird in Anwendungen wie Siemens TrustChain und Deloitte TrustChain verwendet. Auch EU-Projekte wie TrustChain fokussieren auf vertrauenswürdige digitale Identitäten und Daten, mit Schwerpunkten wie dezentralem Identitätsmanagement und Protokollen zur Bewertung der Vertrauenswürdigkeit von Entitäten.

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.

Gewöhnliche digitale Signaturen haben eine grundlegende Einschränkung: Wenn der geheime Schlüssel eines Unterzeichners kompromittiert wird, werden alle Signaturen (vergangene und zukünftige) dieses Unterzeichners wertlos. Diese Einschränkung untergräbt insbesondere die Nichtabstreitbarkeit, die digitale Signaturen häufig bieten sollen. Tatsächlich ist eine der einfachsten Möglichkeiten für Alice, ihre Signaturen abzulehnen, das anonyme Veröffentlichen ihres geheimen Schlüssels irgendwo im Internet und die Behauptung, Opfer eines Computer-Einbruchs zu sein.

Vorwärtssicherheit erfasst die Vorstellung, dass es selbst im Falle einer Offenlegung des aktuellen geheimen Schlüssels für jeden Angreifer rechnerisch unpraktikabel sein sollte, eine Signatur für einen vergangenen Zeitraum zu fälschen.

Es gibt zwei Hauptansätze:

1. Diejenigen, die willkürliche Signaturschemata auf eine Black-Box-Art verwenden
2. Diejenigen, die bestimmte Signaturschemata modifiziere

Schlüsselevolution

Der Ansatz von vorwärtssicheren Schemata besteht darin, den geheimen Schlüssel regelmäßig zu ändern (und den Besitzer dazu zu verpflichten, den alten geheimen Schlüssel ordnungsgemäß zu zerstören). Die Zeit wird in Zeiträume unterteilt; am Ende jedes Zeitraums wird ein neuer geheimer Schlüssel erstellt und der alte wird zerstört. Die Nummer des Zeitraums, in dem eine Signatur generiert wurde, ist Teil der Signatur und wird dem Verifikationsalgorithmus zugeführt; Signaturen mit falschen Zeiträumen sollten nicht verifiziert werden.

Guillou-Quisquater Signaturverfahren

Das Guillou-Quisquater Signaturverfahren ist eine kryptografische Methode, die es ermöglicht, eine Nachricht zu signieren, um deren Authentizität zu beweisen, ähnlich wie Sie Ihre Unterschrift auf einem physischen Dokument setzen würden. Es wurde entwickelt, um sicher und effizient zu sein.

In einfachen Worten funktioniert es folgendermaßen:

1. Schlüsselgenerierung: Zunächst generieren Sie ein Schlüsselpaar - einen privaten Schlüssel und einen öffentlichen Schlüssel. Der private Schlüssel bleibt geheim, und der öffentliche Schlüssel wird mit anderen geteilt.
2. Nachrichten-Signierung: Wenn Sie eine Nachricht signieren möchten, verwenden Sie Ihren privaten Schlüssel, um eine eindeutige Signatur für diese Nachricht zu erstellen. Diese Signatur ist vergleichbar mit Ihrer "digitalen Unterschrift" auf der Nachricht.
3. Nachrichten-Verifikation: Andere können Ihren öffentlichen Schlüssel verwenden, um die Authentizität der Nachricht zu überprüfen. Wenn die Signatur mit der Nachricht und dem öffentlichen Schlüssel übereinstimmt, bedeutet dies, dass die Nachricht nicht manipuliert wurde und tatsächlich von Ihnen signiert wurde.

Das Guillou-Quisquater Signature Scheme basiert auf komplexen mathematischen Operationen, aber die Grundidee besteht darin, Ihren privaten Schlüssel zu verwenden, um einen eindeutigen Code (die Signatur) zu erstellen, der von anderen mithilfe Ihres öffentlichen Schlüssels überprüft werden kann. Wenn der Code übereinstimmt, können sie darauf vertrauen, dass die Nachricht echt ist und von niemand anderem verändert wurde.

Itkins and Reyzin Signaturverfahren

Die Hauptidee des vorwärts-sicheren Schemas von Itkins und Reyzin besteht darin, das GQ-Schema mit Shamirs Beobachtung (Lemma 1) zu kombinieren.

Konkret werden e1, e2, ..., eT als verschiedene Ganzzahlen gewählt, alle größer als 2l, alle paarweise relativ prim und relativ prim zu φ(n). Es gelte s1, s2, ..., sT, wobei sei i ≡ 1/v (mod n) für 1 ≤ i ≤ T. In der Zeitperiode i wird der Unterzeichner einfach das GQ-Schema mit dem geheimen Schlüssel (n, si, ei) verwenden, und der Verifizierer wird das GQ-Schema mit dem öffentlichen Schlüssel (n, v, ei) verwenden. Intuitiv wird dies vorwärts-sicher sein, aufgrund der relativen Primzahligkeit der ei's: Wenn ein Fälscher während der Zeitperiode b einbricht und die eb-te, eb+1-te, ..., eT-te Wurzeln von v erlernt, wird ihm dies nicht helfen, die ej-te Wurzel von v für j < b zu berechnen (noch allgemeiner die r-te Wurzel von v, wobei r|ej).

Keyless Digital Seals & Signatures

Schlüssellose Signaturen sind eine alternative Lösung zu herkömmlichen PKI-Signaturen. Das Wort "schlüssellos" bedeutet nicht, dass bei der Erstellung der Signatur keine kryptografischen Schlüssel verwendet werden. Schlüssel sind weiterhin für die Authentifizierung erforderlich, aber die Signaturen können zuverlässig überprüft werden, ohne die fortgesetzte Geheimhaltung der Schlüssel vorauszusetzen. Schlüssellose Signaturen sind nicht anfällig für Schlüsselkompromittierung und bieten somit eine Lösung für das Problem der Langzeitgültigkeit von digitalen Signaturen. Traditionelle PKI-Signaturen können zwar durch Zeitstempel geschützt werden, aber solange die Zeitstempeltechnologie selbst auf PKI basiert, ist das Problem der Schlüsselkompromittierung immer noch nicht gelöst.

Schlüssellose Signaturen werden in der Praxis als Multi-Signaturen umgesetzt, d.h., viele Dokumente werden gleichzeitig signiert. Der Signierungsprozess umfasst die folgenden Schritte:

1. Hashing: Die zu signierenden Dokumente werden gehasht, und die Hash-Werte repräsentieren die Dokumente im weiteren Verlauf des Prozesses.
2. Aggregation: Es wird ein globaler temporärer Hash-Baum pro Runde erstellt, um alle während einer Runde signierten Dokumente zu repräsentieren. Die Dauer der Runden kann variieren, ist jedoch in der beschriebenen Implementierung auf eine Sekunde festgelegt.
3. Veröffentlichung: Die Top-3-Hash-Werte der pro Runde aggregierten Bäume werden in einen dauerhaften Hash-Baum (sogenannter Hash-Kalender) übernommen, und der Top-Hash-Wert dieses Baums wird als Vertrauensanker veröffentlicht.

Merkle-Hash-Bäume

Die Aggregationstechnik von Hash-Bäumen wurde erstmals von Merkle vorgeschlagen und erstmals für digitale Zeitstempel von Haber et al. verwendet. Die Zeitstempelung mittels Hash-Bäumen verwendet eine Einweg-Hash-Funktion, um eine Liste von Dokumenten in eine Digest mit fester Länge umzuwandeln, die mit der Zeit in Verbindung gebracht wird. Der Benutzer sendet einen Hash eines Dokuments an den Dienst und erhält einen Signatur-Token - den Nachweis, dass die Daten zu einem bestimmten Zeitpunkt existierten und dass die Anfrage über einen bestimmten Zugangspunkt empfangen wurde. Alle empfangenen Anfragen werden zu einem großen Hash-Baum zusammengefasst, und die Spitze des Baums wird für jede Sekunde beibehalten (Abbildung 1).

Signatur-Token enthalten Daten zum Rekonstruieren eines Pfads durch den Hash-Baum - beginnend von einem signierten Hash-Wert (einem Blatt) bis zum Top-Hash-Wert. Zum Beispiel, um ein Token y an der Stelle x2 zu überprüfen, verknüpfen wir zunächst y mit x1 (als Teil des Signatur-Tokens beibehalten) und berechnen einen Hash-Wert y2 = h(x1 | y), der als Eingabe für den nächsten Hash-Schritt verwendet wird, bis wir den Top-Hash-Wert erreichen, d.h. y3 = h(y2 | x34) im vorliegenden Beispiel. Wenn y3 = xtop ist, kann davon ausgegangen werden, dass y im ursprünglichen Hash-Baum vorhanden war.

Trotz der konzeptuellen Einfachheit eines Merkle-Hash-Baums ist der Aufbau eines globalen Netzwerks von Servern für einen solchen Baum komplex. Einfache baumförmige Service-Architekturen sind unerwünscht, da jeder Knoten ein potenzieller Single Point of Failure ist. Daher muss der Aggregationsbaum von redundanten Serverclustern aufgebaut werden. Wir müssen auch Redundanz in der Behandlung des eindeutigen Tops des Baums haben, sodass potenziell unterschiedliche Top-Hash-Werte, Cluster-Partitionen usw. auftreten können.

In jedem Aggregationszeitraum wird der oberste Teil des Aggregationsbaums in einer Kalenderdatenbank gespeichert. Um sich unwiderruflich zur geordneten Sequenz von Werten in der Kalenderdatenbank zu verpflichten, werden sie zu einem binären Hash-Baum verknüpft - sodass die Blätter nur auf einer Seite hinzugefügt werden, ähnlich wie die Markierungen auf der Zeitleiste (siehe t in Abbildung 2).

Übersicht Architektur

Die Architektur des Hochleistungssystems ist in Abbildung 3 dargestellt. Das Hashing von Dokumenten erfolgt in der Anwendung, die eine Anfrage zur Signierung (oder Zeitstempelung) bildet - unter Verwendung bereitgestellter Software-Tools. Die Anfrage wird an ein Gateway gesendet - das Systemkomponente, das den Service an Endbenutzer liefert. Das Gateway führt eine anfängliche Aggregation der in seinem Aggregationszyklus erhaltenen Anfragen durch und sendet dann seine aggregierte Anfrage an den übergeordneten Aggregationscluster.

Anfragen werden durch mehrere Ebenen von Aggregator-Servern aggregiert, und ein global eindeutiger Top-Hash-Wert wird vom Kerncluster ausgewählt. Eine Antwort wird unmittelbar durch die Aggregationsebenen zurückgesendet. Top-Hash-Werte für jeden Aggregationszeitraum werden in der "Kalenderdatenbank" gesammelt und durch die "Kalendercache"-Ebene an den Erweiterungsdienst verteilt, der normalerweise am selben Ort wie der Gateway-Host ist. Client-Anwendungen verwenden den Erweiterungsdienst für Überprüfungszwecke.

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:

Quellen

• https://pdf-insecurity.org/
• Bralić, V., Kuleš, M., & Stančić, H. (2017). A model for long-term preservation of digital signature validity: TrustChain. INFuture2017 Proceedings: The Future of Information Sciences/Atanassova, I., Zaghouani, W., Kragić, B., Aas, K., Stančić, H., Seljan, S.(eds.). Zagreb: Department of Information and Communication Sciences, Faculty of Humanities and Social Sciences, University of Zagreb, Croatia, 89-103.
• Buldas, A., Kroonmaa, A., & Laanoja, R. (2013, October). Keyless signatures’ infrastructure: How to build global distributed hash-trees. In Nordic Conference on Secure IT Systems (pp. 313-320). Berlin, Heidelberg: Springer Berlin Heidelberg.
• Itkis, G., & Reyzin, L. (2001). Forward-secure signatures with optimal signing and verifying. In Advances in Cryptology—CRYPTO 2001: 21st Annual International Cryptology Conference, Santa Barbara, California, USA, August 19–23, 2001 Proceedings 21 (pp. 332-354). Springer Berlin Heidelberg.