Vertrauensmodell

Zusammenfassung. Das Vertrauensmodell legt fest, wem TrustBridge vertraut, gegen wen es sich schützt und was ein Angreifer erreicht, der eine einzelne Komponente übernimmt. Kern ist in jeder Organisation eine kleine Vertrauensbasis aus CA-Worker, Sicherheitsmodul, Offline-Wurzel und den persönlichen Freigabe-Schlüsseln. Datenbank, Verwaltung, Verteilung und Webdienste liegen außerhalb; ihre Kompromittierung führt zu Verzögerung oder Einsicht, nicht zu unberechtigten Zertifikaten. Zwischen Organisationen gilt: Vertrauen ist zweiseitig, je Richtung festgelegt und wird nicht über Dritte weitergegeben. Und ein Zertifikat ist keine Berechtigung: Es belegt, wer spricht, nicht, was erlaubt ist.

• Schutzgut – was zu schützen ist.
• Vertrauensbasis – Komponenten, deren Kompromittierung unberechtigte Ausstellung oder Statusaussage ermöglicht.
• Vertrauensanker – Zertifikat, dem eine prüfende Gegenstelle ohne weitere Prüfung vertraut; in TrustBridge das Wurzelzertifikat einer Organisation oder das Zertifikat einer ausstellenden CA, das eine Vertrauensbeziehung ausdrücklich zulässt.
• Namensbeschränkung – Erweiterung nameConstraints (RFC 5280, Abschnitt 4.2.1.10) in einem CA-Zertifikat, die festlegt, welche Namen in nachgeordneten Zertifikaten zulässig sind.
• Vertrauensbeziehung – Vereinbarung zwischen genau zwei Organisationen, die Vertrauensanker der anderen Seite für bestimmte Dienste und Zwecke anzuerkennen.
• Beziehungsrichtlinie – die Festlegungen einer Organisation für eine Richtung einer Vertrauensbeziehung: Dienste, Zweck, kryptographische Anforderungen, Dauer, Änderungsrecht, Widerruf.
• Berechtigung – die Entscheidung einer Zielanwendung, ob eine bestimmte Operation für eine geprüfte Identität erlaubt ist.
• Prüfer-Vertrag – die Regeln, die eine prüfende Gegenstelle einhalten muss, damit die Sicherheitszusagen bei ihr wirken.

Nicht im Modell: Anforderungen der Web-PKI, beliebige Teilnehmer des Internets als Antragsteller, Lastangriffe aus dem Internet auf die Ausstellung.

graph TD
  subgraph AUS [Außerhalb der Vertrauensbasis]
    ADM[Verwaltungsanwendung] --> VW[Verwaltung]
    EN[Protokolladapter]
    VW --> DB[(Datenbank)]
    EN --> DB
    VT[Verteilung]
  end
  subgraph TCB [Vertrauensbasis]
    RW[Regelwerk]
    FS[Persönliche<br/>Freigabe-Schlüssel]
    EA[Enrollment-Attestierung<br/>nur automatische Klassen]
    RT[Offline-Wurzel]
    WK[CA-Worker<br/>Host, Konto, Uhr]
    REG[Register]
    HSM[Sicherheitsmodul]
  end
  PRF[Prüfende Gegenstelle<br/>letzte Linie]
  DB -->|ungeprüfte Eingabe| WK
  RW --> WK
  FS ==>|Freigabe| WK
  EA ==>|Attestierung| WK
  RT -.->|CA-Zertifikat| WK
  WK --> REG
  WK ==>|signiert| HSM
  WK -->|Sperrliste| VT
  VT --> PRF
  classDef tcb fill:#fde7e9,stroke:#a4262c,color:#201f1e
  classDef aus fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
  class WK,RW,REG,HSM,FS,RT,EA tcb
  class DB,VW,EN,VT aus
  class ADM,PRF par
  style AUS fill:#ffffff,stroke:#8a8886,color:#201f1e
  style TCB fill:#ffffff,stroke:#8a8886,color:#201f1e

Jede Organisation hat ihre eigene Vertrauensbasis. Die Vertrauensbasis einer Organisation ist nie Teil der Vertrauensbasis einer anderen: Eine Beziehung erkennt nur Vertrauensanker an, sie teilt keine Schlüssel, Freigeber oder Register.

Die prüfende Gegenstelle ist die letzte Linie: Die Namensbeschränkung im CA-Zertifikat wirkt nur, wenn sie dort durchgesetzt wird. Der TLS-Adapter von TrustBridge setzt sie selbst durch.

graph TD
  G[Ziel des Angreifers:<br/>gültiges Zertifikat für fremden Namen] --> P1[Auftrag in der Datenbank anlegen]
  P1 --> C1{Freigabe-Signatur<br/>einer im Regelwerk<br/>eingetragenen Person?}
  C1 -- nein --> X1[Worker lehnt ab]
  C1 -- ja, gestohlen --> C2{Name im Namensraum<br/>der gewählten CA?}
  C2 -- nein --> X2[Worker lehnt ab]
  C2 -- nein, Worker umgangen --> X3[Gegenstelle lehnt ab:<br/>nameConstraints]
  C2 -- ja --> R[Zertifikat nur im<br/>eigenen Namensraum]
  classDef x fill:#dff6dd,stroke:#107c10,color:#201f1e
  classDef r fill:#fde7e9,stroke:#a4262c,color:#201f1e
  class X1,X2,X3 x
  class R r
  classDef neu fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  class C1,C2,G,P1 neu

Die Argumentationskette im Einzelnen:

1. Ein Zertifikat entsteht nur, wenn der Worker signiert. Der Worker ist von außen nicht erreichbar; ein Angreifer kann ihm nur Aufträge über die Datenbank vorlegen.
2. Der Worker vertraut keinem Inhalt der Datenbank. Er prüft die Freigabe-Signatur mit öffentlichen Schlüsseln aus seinem lokalen Regelwerk. Wer die Datenbank beherrscht, kann keinen Freigeber hinzufügen.
3. Die Freigabe gilt für genau einen Auftragshash. Eine alte Freigabe auf einen neuen Auftrag zu übertragen scheitert, weil sich der Hash ändert; jeder Auftrag wird höchstens einmal ausgeführt und hat eine Frist.
4. Der Worker prüft den Namen gegen den Namensraum der CA. Selbst bei einem Fehler im Worker greift die Namensbeschränkung im CA-Zertifikat bei der Gegenstelle.
5. Sperrungen sind im Register monoton. Eine Datenbank, die eine Sperrung „vergisst“, ändert die nächste Sperrliste nicht; die Verteilung liefert nur korrekt signierte Listen mit steigender Nummer.

Grenzen dieser Argumentation. Sie hält nicht stand gegen: einen Freigeber, der zugleich Verwaltung oder Datenbank kontrolliert, in Klassen mit nur einer Freigabe; den Administrator des Worker-Hosts, der das Regelwerk ändern kann; eine Gegenstelle, die nameConstraints nicht durchsetzt. Diese Restrisiken werden organisatorisch begrenzt (Zwei-Personen-Regel, Vier-Augen-Prinzip am Worker-Host, Prüfer-Vertrag mit Testzertifikaten).

Ein gültiges Zertifikat beantwortet eine einzige Frage: Wer spricht? Ob das, was diese Identität tun will, erlaubt ist, entscheidet TrustBridge nicht. Sechs Dinge werden deshalb auseinandergehalten:

graph TD
  V[Verbindung von B] --> K1{Kette bis zu einem<br/>Anker der Beziehung?}
  K1 -- nein --> X1[TLS-Adapter lehnt ab]
  K1 -- ja --> K2{Dienst und Zweck in<br/>der Richtlinie von A?}
  K2 -- nein --> X2[TLS-Adapter lehnt ab]
  K2 -- ja --> K3{Operation für diese<br/>Identität berechtigt?}
  K3 -- nein --> X3[Anwendung lehnt ab]
  K3 -- ja --> OK[Operation wird ausgeführt<br/>und protokolliert]
  classDef onl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef auth fill:#fff4ce,stroke:#8a6d00,color:#201f1e
  classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
  classDef x fill:#dff6dd,stroke:#107c10,color:#201f1e
  class V par
  class K1,K2 onl
  class K3,OK auth
  class X1,X2,X3 x

Erst die dritte Prüfung öffnet Daten. Wer ein gültiges Zertifikat stiehlt, ohne den privaten Schlüssel zu besitzen, scheitert an der Signatur im Handshake; wer ein Zertifikat samt Schlüssel stiehlt, erhält nur, was die Zielanwendung dieser Identität erlaubt, und nur bis zur Sperrung.

Die folgenden Szenarien prüfen die Sicherheitszusagen gegen Angriffe, die über die Kompromittierung einer einzelnen Komponente hinausgehen. Die Zusagen sind auf der Seite Sicherheitszusagen beschrieben.

Jede Gegenstelle, die Zertifikate von TrustBridge prüft, muss:

1. die vollständige Kette bis zu einem Vertrauensanker der Beziehung prüfen;
2. basicConstraints und pathLenConstraint prüfen;
3. nameConstraints aller CA-Zertifikate tatsächlich durchsetzen;
4. den Partner ausschließlich über die ausstellende CA identifizieren;
5. das System ausschließlich über den dNSName identifizieren;
6. keyUsage und extendedKeyUsage prüfen;
7. die Gültigkeit der gesamten Kette prüfen;
8. die Sperrliste der ausstellenden CA auswerten und ohne gültige Sperrliste ablehnen;
9. bei vereinbartem PQ-Schutz zusätzlich die ML-DSA-Alternativsignatur jedes Zertifikats der Kette prüfen und eine Kette ohne passende Alternativsignatur ablehnen;
10. die Sperrliste im Erzeugungstakt (6 Stunden) neu laden, nicht erst bei ihrem Ablauf.

Der TLS-Adapter von TrustBridge erfüllt alle zehn Punkte. Für Gegenstellen ohne TLS-Adapter liefert TrustBridge Testzertifikate, darunter Zertifikate mit verbotenen Namen, abgelaufener Kette, gesperrtem Status und fehlender Alternativsignatur, die eine korrekt konfigurierte Gegenstelle ablehnen muss.

CA-Schlüssel werden ausschließlich im Sicherheitsmodul genutzt; TrustBridge selbst führt keine Operation mit geheimen CA-Schlüsseln aus. Der Schutz dieser Schlüssel gegen Zeit-, Cache- und Stromseitenkanäle ist eine Eigenschaft des zertifizierten Moduls und ein Auswahlkriterium dafür. Die Schlüsselagenten verwenden für ML-KEM und ML-DSA Implementierungen mit datenunabhängiger Laufzeit.

TrustBridge kennt zwei Wege, einen Partner anzubinden. Beide führen zu derselben Prüfung beim TLS-Adapter.

graph TD
  subgraph A [Partner-CA in der Hierarchie des Auftraggebers]
    WA[Wurzel des Auftraggebers] --> CA1[CA Partner 1<br/>nameConstraints]
    WA --> CA2[CA Partner 2<br/>nameConstraints]
  end
  subgraph B [Eigene Hierarchie, bilaterale Anerkennung]
    W1[Wurzel Organisation 1] --> CB1[CA Organisation 1]
    W2[Wurzel Organisation 2] --> CB2[CA Organisation 2]
  end
  CB1 -.->|Anker in der Beziehung,<br/>beschränkt auf Namensraum| CB2
  classDef s fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  class WA,CA1,CA2,W1,W2,CB1,CB2 s
  style A fill:#ffffff,stroke:#8a8886,color:#201f1e
  style B fill:#ffffff,stroke:#8a8886,color:#201f1e

Ein Partner kann vom ersten Weg zum zweiten wechseln, wenn er eine eigene Installation aufbaut; seine Systeme erhalten dann Zertifikate aus der eigenen Hierarchie, und die Beziehung wechselt den Anker.

Bevor ein System sein erstes Zertifikat erhält, muss TrustBridge erkennen, dass es mit dem richtigen System spricht. Die Profilklasse legt fest, welcher Nachweis verlangt wird:

Ein signiertes Softwareartefakt allein belegt keinen sicheren Laufzeitzustand; jeder Nachweis hat eine ausdrückliche Prüfregel im Regelwerk.

• Keine Berechtigungen. Welche Operation ein Partner ausführen darf, legt die Zielanwendung fest.
• Kein Nachweis über Herkunft und Stand der Software eines Partners; das ist nicht Aufgabe einer PKI.
• Keine Identitätsversorgung kurzlebiger Workloads innerhalb eines Rechenzentrums (etwa SPIFFE); TrustBridge identifiziert Systeme und Dienste zwischen Organisationen.
• Kein Schutz bei Gegenstellen, die den Prüfer-Vertrag nicht umsetzen und keinen TLS-Adapter verwenden.