WKL TrustBridge – pregled

Povzetek. WKL TrustBridge je zasebna, federativna infrastruktura za vzajemno kriptografsko zaupanje med samostojnimi organizacijami v dobavni verigi. Vsaka organizacija obdrži svoje identitete, ključe in pravila. Dve organizaciji se dogovorita za razmerje zaupanja, ki je omejeno po obsegu, vezano na namen in ga je mogoče kadar koli preklicati. Njuni sistemi se nato medsebojno overijo s certifikati in vzpostavijo povezavo TLS 1.3, ki jo dodatno ščiti neodvisno ustvarjena postkvantna skrivnost. Certifikat ni pooblastilo: kaj partner dejansko sme, še vedno odloči aplikacija, s katero se poveže, na primer WKL Database Gateway. Varnostni model temelji na majhni, natančno zamejeni zaupanja vredni računalniški osnovi. Podpisuje ena sama storitev, samo s ključi v strojnem varnostnem modulu in samo naročila, ki jih je pooblaščena oseba kriptografsko odobrila.

Izberite scenarij uporabe → Izberite model delovanja → Dogovorite se za razmerje → Povežite dobavitelja

Celotno pot na enem primeru, z odgovornostmi vsake strani, prikazuje Primer: vključitev dobavitelja.

• Kako povežem dobavitelja z Database Gateway?
• Kako odobrim naročilo za certifikat?
• Kako prekličem certifikat, tudi brez podatkovne baze?
• Kako končam sodelovanje s partnerjem?
• Kako revizorju pokažem, kdo je odobril izdajo?
• Kaj storim, če je ključ CA kompromitiran?

Vse naloge so zbrane v Navodilih.

graph TD
  subgraph ORGA [Organizacija A, naročnik]
    APA[Database Gateway<br/>ali druga aplikacija]
    ADA[Adapter TLS A]
    KAA[Agent ključev A<br/>s posrednikom ključev]
    CAA[Certifikatna agencija A<br/>delavec CA, HSM]
    RLA[Politika razmerja A]
  end
  subgraph ORGB [Organizacija B, dobavitelj]
    APB[Aplikacija dobavitelja]
    ADB[Adapter TLS B]
    KAB[Agent ključev B<br/>s posrednikom ključev]
    CAB[Certifikatna agencija B<br/>delavec CA, HSM]
    RLB[Politika razmerja B]
  end
  CAA -.->|sidro zaupanja A| RLB
  CAB -.->|sidro zaupanja B| RLA
  KAB ==>|dodatna skrivnost PQ| KAA
  KAA ==>|zunanji PSK| ADA
  KAB ==>|zunanji PSK| ADB
  APB --> ADB
  ADB -->|TLS 1.3, vzajemno overjeno| ADA
  ADA -->|preverjena identiteta| 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

Sodelovanje poteka v štirih korakih:

1. Dogovor o razmerju. A in B si izmenjata sidri zaupanja. Vsaka stran za svojo smer določi, katerim storitvam druge strani zaupa, za kakšen namen, ob katerih kriptografskih zahtevah in za koliko časa.
2. Izdaja identitet. Vsaka organizacija izda certifikate svojim sistemom, samodejno prek ACME ali EST ali potem, ko naročilo odobri pooblaščena oseba.
3. Zaščita povezave. Agenta ključev na obeh straneh se dogovorita za dodatno postkvantno skrivnost. Adapterja TLS z njo vzpostavita vzajemno overjeno povezavo TLS 1.3, v kateri skrivnost vstopi v razpored ključev kot zunanji vnaprej deljeni ključ.
4. Pooblastitev operacije. Ciljna aplikacija prejme preverjeno identiteto partnerja, glede na lastna dovoljenja odloči, ali je zahtevana operacija dovoljena, in jo zabeleži.

Vsaka povezava zato gre skozi šest plasti zaščite in vsaka preverja nekaj drugega:

Kako nastane certifikat znotraj ene organizacije, opisuje stran PKI in življenjski cikel certifikatov. Kako si dve organizaciji začneta zaupati, opisuje stran Federacija in dvostransko zaupanje.

Pomen barv in puščic v vseh diagramih je pojasnjen v razdelku Dogovori v diagramih.

Vsaka organizacija upravlja svojo certifikatno agencijo. Podpisuje samo delavec CA s ključi v HSM in samo naročila, ki jih je odobrila pooblaščena oseba ali potrdila storitev za vpis; podatkovna baza in upravljanje sta zunaj zaupanja vredne osnove. Dve organizaciji si zaupata prek razmerja s politiko za vsako smer, ki jo delavec CA adapterjem TLS preda kot podpisan sveženj zaupanja. Agenti ključev vsaki povezavi dodajo postkvantno skrivnost. Zakaj je zgradba takšna, pojasnjujejo Model zaupanja, Sistemska arhitektura in Postkvantna izmenjava ključev za TLS.

• Osebe in dostop – vabila, vloge, zaklepi, obvestila
• Odprava zaklepa osebe
• Ponastavitev drugega faktorja
• Pregled in analiza prijav
• Delovanje in izredne razmere – domene izpada, obnova, privzete vrednosti

• Do partnerja ne nastanejo nove povezave
• Vzpostavitev povezave se prekine, ker strežnik ne potrdi zunanjega PSK
• Povezave s partnerjem se nenadoma končajo
• Zahtevek za certifikat je zavrnjen s 400
• Ukaz je zavrnjen s 409

Vsi simptomi so zbrani na strani Odpravljanje težav.

• Vmesniki in integracija – ACME, EST, CMP, upravljalni API, adapter TLS
• Sistemska arhitektura – komponente, smeri omrežja, varnostni profili
• Izpeljava arhitekture – od zahtev do odločitev

Strani v vrstnem redu, v katerem gradijo druga na drugi: najprej čemu služi in v katerem modelu, nato zakaj in kako je zgrajen, nato naloge in na koncu referenčne strani.