Seminar BBS Data Integrity – W3C VC Cryptosuites implementieren

Seminarprofil

Das Seminar behandelt die Implementierung BBS-basierter Data-Integrity-Nachweise im Umfeld von Verifiable Credentials. Der vollständige Ablauf von kanonisierten RDF-Daten über Base Proofs bis zu abgeleiteten, selektiv offengelegten Proofs wird praktisch umgesetzt und sicher validiert.

Lernziele

• Data-Integrity-Proofs, Kryptosuites und BBS-bezogene Datenstrukturen korrekt zusammensetzen
• Kanonisierung, Hashing und Nachrichtenzuordnung reproduzierbar durchführen
• Base Proofs erzeugen und daraus datensparsame Derived Proofs ableiten
• Verifier-Prüfungen für Kontext, Proof Purpose, Schlüssel, Nonce und Offenlegung implementieren
• Interoperabilitäts-, Canonicalization- und Negative-Tests automatisieren

Inhaltsübersicht

1. VC Data Model und Data Integrity
2. RDF-Daten und Kanonisierung
3. Schlüssel und Multikey-Repräsentation
4. Base Proof Configuration
5. BBS-Signatur über Aussagen
6. Selektionsrahmen für Offenlegung
7. Derived Proof und Unlinkability
8. Verifier-Verarbeitung
9. Kontext- und Datenmodellangriffe
10. Interoperabilitätstests
11. End-to-End-Labor

Seminarinhalte

Schritt 1: VC Data Model und Data Integrity

Credential-Inhalt, Context, Typen, Issuer, Subject und Proof werden getrennt betrachtet. Die Validierung beginnt mit dem Datenmodell, bevor kryptografische Aussagen akzeptiert werden.

Schritt 2: RDF-Daten und Kanonisierung

BBS-basierte Suites arbeiten mit deterministisch aufbereiteten Aussagen. Übungen zeigen, wie Kontexte, Blank Nodes, Datentypen und unterschiedliche Serialisierungen das kanonische Ergebnis beeinflussen.

Schritt 3: Schlüssel und Multikey-Repräsentation

Öffentliche und private BBS-Schlüssel werden erzeugt, gespeichert und eindeutig referenziert. Key Resolution, Controller-Bezug, Rotation und die Abwehr unerlaubter Schlüsselersetzung werden berücksichtigt.

Schritt 4: Base Proof Configuration

Proof Type, Cryptosuite, Created, Verification Method und Proof Purpose werden als gesicherte Konfiguration aufgebaut. Fehlerhafte oder zusätzliche Felder werden bewusst getestet.

Schritt 5: BBS-Signatur über Aussagen

Kanonisierte Aussagen werden auf Nachrichten abgebildet und signiert. Die Implementierung kontrolliert Reihenfolge, Domänentrennung, Header-Daten und die Bindung der Signatur an die Proof-Konfiguration.

Schritt 6: Selektionsrahmen für Offenlegung

Der Holder bestimmt mit einem Disclosure Frame, welche Aussagen sichtbar bleiben. Abhängige Aussagen, notwendige Typinformationen und Kontextbestandteile werden so ausgewählt, dass das abgeleitete Dokument weiterhin eindeutig interpretierbar ist.

Schritt 7: Derived Proof und Unlinkability

Aus Base Proof und selektierten Aussagen wird ein neuer Präsentationsnachweis erzeugt. Nonce und randomisierte Proof-Erzeugung werden genutzt, um wiederholte Präsentationen nicht allein über den kryptografischen Proof verkettbar zu machen.

Schritt 8: Verifier-Verarbeitung

Der Verifier rekonstruiert die zu prüfenden Aussagen, validiert Proof-Konfiguration und kryptografischen Nachweis und wendet danach fachliche Regeln an. Fehler werden granular, aber ohne Offenlegung sensibler Zwischendaten behandelt.

Schritt 9: Kontext- und Datenmodellangriffe

Remote Contexts, manipulierte Term-Definitionen, unerwartete Datentypen und mehrdeutige Aussagen werden untersucht. Zulässige Kontexte und Schemas werden in einer lokalen Policy fixiert.

Schritt 10: Interoperabilitätstests

Testvektoren vergleichen Implementierungen über Sprach- und Bibliotheksgrenzen hinweg. Kanonische Ausgaben, Base-Proof-Validierung und Derived-Proof-Ergebnisse werden reproduzierbar protokolliert.

Schritt 11: End-to-End-Labor

Issuer, Holder und Verifier werden zu einem vollständigen Flow verbunden. Das Labor umfasst Ausstellung, Ableitung zweier unterschiedlich minimierter Präsentationen, Verifikation und Fehlerfälle.

Praxisanteil

• BBS-Schlüssel und Base Proof für ein Beispiel-Credential erzeugen
• Zwei Derived Proofs mit unterschiedlicher Attributauswahl ableiten
• Manipulierte Kontexte und Proof-Konfigurationen in Negativtests erkennen
• Interoperabilitäts-Testvektoren für Kanonisierung und Verifikation aufbauen

Zielgruppe

Entwickler von Issuern, Wallets und Verifiern, Kryptografie-nahe Engineers, SSI-Architekten und technische Tester

Voraussetzungen

Gute Kenntnisse von JSON, Verifiable Credentials und Public-Key-Kryptografie; Grundverständnis von RDF ist hilfreich