WKL TrustBridge – Überblick

Zusammenfassung. WKL TrustBridge ist eine private, föderierte Infrastruktur für gegenseitiges kryptographisches Vertrauen zwischen unabhängigen Organisationen einer Lieferkette. Jede Organisation behält ihre eigenen Identitäten, Schlüssel und Regeln. Zwei Organisationen vereinbaren eine begrenzte, zweckgebundene und jederzeit widerrufliche Vertrauensbeziehung; ihre Systeme prüfen sich danach gegenseitig über Zertifikate und bauen eine TLS-1.3-Verbindung auf, die zusätzlich durch ein unabhängig erzeugtes Post-Quanten-Geheimnis geschützt ist. Ein Zertifikat ist dabei keine Berechtigung: Was ein Partner tatsächlich tun darf, entscheidet weiterhin die Anwendung, auf die er zugreift, etwa der WKL Database Gateway. Das Sicherheitsmodell beruht auf einer kleinen, ausdrücklich abgegrenzten Vertrauensbasis: Nur ein einziger Dienst signiert, nur mit Schlüsseln in einem Hardware-Sicherheitsmodul und nur für Aufträge, die eine berechtigte Person kryptographisch freigegeben hat.

Einsatzszenario wählen → Betriebsmodell festlegen → Beziehung vereinbaren → Lieferanten anbinden

Den ganzen Weg an einem Beispiel, mit der Verantwortung jedes Beteiligten, zeigt die Fallstudie: Anbindung eines Lieferanten.

• Wie binde ich einen Lieferanten an den Database Gateway an?
• Wie gebe ich einen Zertifikatsauftrag frei?
• Wie sperre ich ein Zertifikat, auch ohne Datenbank?
• Wie beende ich die Zusammenarbeit mit einem Partner?
• Wie weise ich einem Prüfer nach, wer eine Ausstellung freigegeben hat?
• Was tue ich, wenn ein CA-Schlüssel kompromittiert ist?

Alle Aufgaben stehen unter Anleitungen.

graph TD
  subgraph ORGA [Organisation A, Auftraggeber]
    APA[Database Gateway<br/>oder andere Anwendung]
    ADA[TLS-Adapter A]
    KAA[Schlüsselagent A<br/>mit Schlüsselvermittler]
    CAA[Zertifizierungsstelle A<br/>CA-Worker, Sicherheitsmodul]
    RLA[Beziehungsrichtlinie A]
  end
  subgraph ORGB [Organisation B, Lieferant]
    APB[Anwendung des Lieferanten]
    ADB[TLS-Adapter B]
    KAB[Schlüsselagent B<br/>mit Schlüsselvermittler]
    CAB[Zertifizierungsstelle B<br/>CA-Worker, Sicherheitsmodul]
    RLB[Beziehungsrichtlinie B]
  end
  CAA -.->|Vertrauensanker A| RLB
  CAB -.->|Vertrauensanker B| RLA
  KAB ==>|zusätzliches PQ-Geheimnis| KAA
  KAA ==>|externer PSK| ADA
  KAB ==>|externer PSK| ADB
  APB --> ADB
  ADB -->|TLS 1.3, gegenseitig authentisiert| ADA
  ADA -->|geprüfte Identität| APA
  classDef tcb fill:#fde7e9,stroke:#a4262c,color:#201f1e
  classDef onl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
  classDef pq fill:#dff6dd,stroke:#107c10,color:#201f1e
  classDef auth fill:#fff4ce,stroke:#8a6d00,color:#201f1e
  class CAA,CAB tcb
  class ADA,ADB,RLA,RLB onl
  class KAA,KAB pq
  class APB par
  class APA auth
  style ORGA fill:#ffffff,stroke:#8a8886,color:#201f1e
  style ORGB fill:#ffffff,stroke:#8a8886,color:#201f1e

Eine Zusammenarbeit entsteht in vier Schritten:

1. Beziehung vereinbaren. A und B tauschen ihre Vertrauensanker aus und legen jede für ihre Richtung fest, welchen Diensten der anderen Seite sie zu welchem Zweck, unter welchen kryptographischen Anforderungen und wie lange vertrauen.
2. Identität ausstellen. Jede Organisation stellt ihren eigenen Systemen Zertifikate aus, automatisch über ACME oder EST oder nach Freigabe durch eine berechtigte Person.
3. Verbindung schützen. Die Schlüsselagenten beider Seiten vereinbaren ein zusätzliches Post-Quanten-Geheimnis. Die TLS-Adapter bauen damit eine gegenseitig authentisierte TLS-1.3-Verbindung auf, in die dieses Geheimnis als externer Pre-Shared Key eingeht.
4. Operation berechtigen. Die Zielanwendung erhält die geprüfte Identität des Partners und entscheidet nach ihren eigenen Rechten, ob die gewünschte Operation erlaubt ist, und protokolliert sie.

Jede Verbindung durchläuft damit sechs Schutzschichten, und jede prüft etwas anderes:

Wie ein Zertifikat innerhalb einer Organisation entsteht, beschreibt PKI und Zertifikatslebenszyklus; wie zwei Organisationen einander vertrauen, beschreibt Föderation und bilaterales Vertrauen.

Farben und Pfeile aller Diagramme erklären die Darstellungskonventionen.

Jede Organisation betreibt ihre eigene Zertifizierungsstelle. Signiert wird nur im CA-Worker, mit Schlüsseln im Sicherheitsmodul, und nur für Aufträge, die eine berechtigte Person freigegeben oder das Enrollment bestätigt hat; Datenbank und Verwaltung liegen außerhalb dieser Vertrauensbasis. Zwei Organisationen vertrauen einander über eine Beziehung mit einer Richtlinie je Richtung, die der CA-Worker als signiertes Vertrauensbündel an die TLS-Adapter gibt. Die Schlüsselagenten ergänzen jede Verbindung um ein zusätzliches Post-Quanten-Geheimnis. Warum das so gebaut ist, erklären Vertrauensmodell, Systemarchitektur und PQ-Schlüsselaustausch für TLS.

• Personen und Zugriff – Einladung, Rollen, Sperre, Benachrichtigungen
• So heben Sie die Sperre einer Person auf
• So setzen Sie den zweiten Faktor einer Person zurück
• So prüfen Sie die Anmeldungen
• Betrieb und Notfall – Ausfallbereiche, Wiederanlauf, Vorgabewerte

• Zu einem Partner entstehen keine neuen Verbindungen
• Der Verbindungsaufbau bricht ab, weil der Server den externen PSK nicht bestätigt
• Bestehende Verbindungen zu einem Partner enden plötzlich
• Ein Zertifikatsantrag wird mit 400 abgewiesen
• Ein Befehl wird mit 409 abgewiesen

Alle Symptome stehen unter Fehlerbehebung.

• Schnittstellen und Integration – ACME, EST, CMP, Verwaltungs-API, TLS-Adapter
• Systemarchitektur – Komponenten, Netzrichtungen, Sicherheitsprofile
• Architekturableitung – von den Anforderungen zu den Entscheidungen

Die Seiten in der Reihenfolge, in der sie aufeinander aufbauen: zuerst wofür und in welchem Modell, dann warum und wie es gebaut ist, dann die Aufgaben, zuletzt die Nachschlageseiten.