Model zaupanja

Povzetek. Model zaupanja določa, komu TrustBridge zaupa, pred kom se varuje in kaj doseže napadalec, ki prevzame posamezno komponento. Jedro je v vsaki organizaciji majhna zaupanja vredna osnova iz delavca CA, HSM, korenske CA brez povezave in osebnih ključev za odobritev. Podatkovna baza, upravljanje, distribucija in spletne storitve so zunaj nje; njihova kompromitacija povzroči zamudo ali vpogled, ne pa nepooblaščenih certifikatov. Med organizacijami velja: zaupanje je dvostransko, določeno za vsako smer in se ne prenaša prek tretjih. In certifikat ni pooblastilo: dokazuje, kdo govori, ne pa, kaj je dovoljeno.

• Varovana dobrina – kar je treba zaščititi.
• Zaupanja vredna osnova – komponente, katerih kompromitacija omogoči nepooblaščeno izdajo ali trditev o stanju.
• Sidro zaupanja – certifikat, ki mu preverjevalec zaupa brez nadaljnjega preverjanja; v TrustBridge korenski certifikat organizacije ali certifikat izdajateljske CA, ki ga razmerje zaupanja izrecno dopušča.
• Omejitev imen – razširitev nameConstraints (RFC 5280, razdelek 4.2.1.10) v certifikatu CA, ki določa, katera imena so dovoljena v podrejenih certifikatih.
• Razmerje zaupanja – dogovor med natanko dvema organizacijama, da priznata sidra zaupanja druge strani za določene storitve in namene.
• Politika razmerja – določitve organizacije za eno smer razmerja zaupanja: storitve, namen, kriptografske zahteve, trajanje, pravica do spremembe, preklic.
• Pooblastilo – odločitev ciljne aplikacije, ali je določena operacija za preverjeno identiteto dovoljena.
• Pogodba preverjevalca – pravila, ki se jih mora preverjevalec držati, da varnostne zaveze pri njem učinkujejo.

Ni v modelu: zahteve spletne PKI, poljubni udeleženci interneta kot vlagatelji, obremenitveni napadi iz interneta na izdajo.

graph TD
  subgraph AUS [Zunaj zaupanja vredne osnove]
    ADM[Upravljalna aplikacija] --> VW[Upravljanje]
    EN[Protokolni adapterji]
    VW --> DB[(Podatkovna baza)]
    EN --> DB
    VT[Distribucija]
  end
  subgraph TCB [Zaupanja vredna osnova]
    RW[Pravilnik]
    FS[Osebni ključi<br/>za odobritev]
    EA[Atestacija vpisa<br/>samo samodejni razredi]
    RT[Korenska CA brez povezave]
    WK[Delavec CA<br/>gostitelj, račun, ura]
    REG[Register]
    HSM[HSM]
  end
  PRF[Preverjevalec<br/>zadnja črta]
  DB -->|nepreverjen vhod| WK
  RW --> WK
  FS ==>|odobritev| WK
  EA ==>|atestacija| WK
  RT -.->|certifikat CA| WK
  WK --> REG
  WK ==>|podpiše| HSM
  WK -->|seznam preklicanih| 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

Vsaka organizacija ima lastno zaupanja vredno osnovo. Osnova ene organizacije nikoli ni del osnove druge: razmerje priznava samo sidra zaupanja, ne deli pa ključev, odobriteljev ali registrov.

Preverjevalec je zadnja črta: omejitev imen v certifikatu CA učinkuje samo, če jo preverjevalec uveljavi. Adapter TLS v TrustBridge jo uveljavi sam.

graph TD
  G[Cilj napadalca:<br/>veljaven certifikat za tuje ime] --> P1[ustvari naročilo v podatkovni bazi]
  P1 --> C1{Podpis odobritve<br/>osebe, vpisane<br/>v pravilnik?}
  C1 -- ne --> X1[Delavec CA zavrne]
  C1 -- da, ukraden --> C2{Ime v imenskem prostoru<br/>izbrane CA?}
  C2 -- ne --> X2[Delavec CA zavrne]
  C2 -- ne, delavec CA obiden --> X3[Preverjevalec zavrne:<br/>nameConstraints]
  C2 -- da --> R[Certifikat samo v<br/>lastnem imenskem prostoru]
  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

Veriga argumentov v podrobnostih:

1. Certifikat nastane samo, če podpiše delavec CA. Delavec CA ni dosegljiv od zunaj; napadalec mu lahko naročila predloži samo prek podatkovne baze.
2. Delavec CA ne zaupa nobeni vsebini podatkovne baze. Podpis odobritve preveri z javnimi ključi iz svojega lokalnega pravilnika. Kdor obvladuje podatkovno bazo, ne more dodati odobritelja.
3. Odobritev velja za natanko eno zgoščeno vrednost naročila. Prenos stare odobritve na novo naročilo ne uspe, ker se zgoščena vrednost spremeni; vsako naročilo se izvede največ enkrat in ima rok.
4. Delavec CA preveri ime glede na imenski prostor CA. Tudi ob napaki v delavcu CA pri preverjevalcu učinkuje omejitev imen v certifikatu CA.
5. Preklici so v registru monotoni. Podatkovna baza, ki preklic „pozabi“, ne spremeni naslednjega seznama preklicanih; distribucija dostavi samo pravilno podpisane sezname z naraščajočo številko.

Meje te argumentacije. Ne zdrži proti: odobritelju, ki hkrati nadzoruje upravljanje ali podatkovno bazo, v razredih z eno samo odobritvijo; skrbniku gostitelja delavca CA, ki lahko spremeni pravilnik; preverjevalcu, ki nameConstraints ne uveljavlja. Ta preostala tveganja se omejijo organizacijsko (pravilo dveh oseb, načelo štirih oči na gostitelju delavca CA, pogodba preverjevalca s testnimi certifikati).

Veljaven certifikat odgovori na eno samo vprašanje: kdo govori? Ali je to, kar želi ta identiteta narediti, dovoljeno, TrustBridge ne odloča. Zato se ločuje šest stvari:

graph TD
  V[Povezava iz B] --> K1{Veriga do<br/>sidra razmerja?}
  K1 -- ne --> X1[Adapter TLS zavrne]
  K1 -- da --> K2{Storitev in namen<br/>v politiki A?}
  K2 -- ne --> X2[Adapter TLS zavrne]
  K2 -- da --> K3{Operacija za to<br/>identiteto pooblaščena?}
  K3 -- ne --> X3[Aplikacija zavrne]
  K3 -- da --> OK[Operacija se izvede<br/>in zabeleži]
  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

Šele tretje preverjanje odpre podatke. Kdor ukrade veljaven certifikat brez zasebnega ključa, obtiči pri podpisu v rokovanju; kdor ukrade certifikat skupaj s ključem, dobi samo to, kar ciljna aplikacija tej identiteti dovoli, in samo do preklica.

Naslednji scenariji preverjajo varnostne zaveze glede na napade, ki presegajo kompromitacijo posamezne komponente. Zaveze so opisane na strani Varnostne zaveze.

Vsak preverjevalec, ki preverja certifikate TrustBridge, mora:

1. preveriti celotno verigo do sidra zaupanja razmerja;
2. preveriti basicConstraints in pathLenConstraint;
3. dejansko uveljaviti nameConstraints vseh certifikatov CA;
4. partnerja identificirati izključno prek izdajateljske CA;
5. sistem identificirati izključno prek dNSName;
6. preveriti keyUsage in extendedKeyUsage;
7. preveriti veljavnost celotne verige;
8. ovrednotiti seznam preklicanih certifikatov izdajateljske CA in brez veljavnega seznama zavrniti;
9. ob dogovorjeni postkvantni zaščiti dodatno preveriti alternativni podpis ML-DSA vsakega certifikata v verigi in zavrniti verigo brez ustreznega alternativnega podpisa;
10. seznam preklicanih certifikatov prenesti znova v ritmu ustvarjanja (6 ur), ne šele ob njegovem poteku.

Adapter TLS v TrustBridge izpolnjuje vseh deset točk. Za preverjevalce brez adapterja TLS TrustBridge zagotovi testne certifikate, med njimi certifikate s prepovedanimi imeni, potečeno verigo, preklicanim stanjem in manjkajočim alternativnim podpisom, ki jih mora pravilno nastavljen preverjevalec zavrniti.

Ključi CA se uporabljajo izključno v HSM; TrustBridge sam ne izvaja nobene operacije s tajnimi ključi CA. Zaščita teh ključev pred časovnimi, predpomnilniškimi in tokovnimi stranskimi kanali je lastnost certificiranega modula in merilo za njegovo izbiro. Agenti ključev za ML-KEM in ML-DSA uporabljajo izvedbe s časom izvajanja, neodvisnim od podatkov.

TrustBridge pozna dva načina povezave partnerja. Oba vodita do enakega preverjanja v adapterju TLS.

graph TD
  subgraph A [Partnerska CA v hierarhiji naročnika]
    WA[Korenska CA naročnika] --> CA1[CA partnerja 1<br/>nameConstraints]
    WA --> CA2[CA partnerja 2<br/>nameConstraints]
  end
  subgraph B [Lastna hierarhija, dvostransko priznanje]
    W1[Korenska CA organizacije 1] --> CB1[CA organizacije 1]
    W2[Korenska CA organizacije 2] --> CB2[CA organizacije 2]
  end
  CB1 -.->|sidro v razmerju,<br/>omejeno na imenski prostor| 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

Partner lahko s prvega načina preide na drugega, ko postavi lastno namestitev; njegovi sistemi tedaj dobijo certifikate iz lastne hierarhije, razmerje pa zamenja sidro.

Preden sistem dobi prvi certifikat, mora TrustBridge prepoznati, da govori s pravim sistemom. Razred profila določa, kateri dokaz se zahteva:

Podpisan programski artefakt sam ne dokazuje varnega stanja med izvajanjem; vsak dokaz ima v pravilniku izrecno pravilo preverjanja.

• Pooblastil. Katero operacijo sme partner izvesti, določi ciljna aplikacija.
• Dokaza o izvoru in stanju partnerjeve programske opreme; to ni naloga PKI.
• Oskrbe kratkoživih delovnih obremenitev v podatkovnem centru z identitetami (na primer SPIFFE); TrustBridge identificira sisteme in storitve med organizacijami.
• Zaščite pri preverjevalcih, ki ne izvajajo pogodbe preverjevalca in ne uporabljajo adapterja TLS.