Linux Foundation, BastionZero ja Docker esitlesid uut avatud projekti OpenPubKey, mis arendab sama nime kandvat krüptograafilist protokolli, et kinnitada digiallkirjadega suvalisi objekte. Tehnoloogia on välja töötatud koostööprojektina ettevõtete BastionZero ja Docker vahel, et lihtsustada Docker'i konteineripiltide digiallkirjadega kinnitamist, vältides nende vahetamist ja kinnitades, et pildi koostas nimetatud autor. Projekt areneb neutraalses keskkonnas Linux Foundationi toetusel, mis välistab sõltuvuse üksikutest kaubanduslikest ettevõtetest ja lihtsustab koostööd kolmandate osaliste kaasamisega. OpenPubKey viidatud rakendus on kirjutatud Go keeles ja levitatakse Apache 2.0 litsentsi alusel.
OpenPubKey võimalused ei piirdu ainult konteineripiltidega ning tehnoloogiat saab kasutada igasuguste ressursside päritolu kinnitamiseks, sõltuvuste vahetamise vältimiseks ja andmefluxi turvalisuse suurendamiseks. Näiteks on tehnoloogia rakendatav programmide versioonide, üksikteadete ja commitide kinnitamiseks. Allkiri loojatel peab olema piisavalt konto teenuses, mis toetab OpenID-d, ning tarbijatele antakse võimalus kinnitatud allkirjade kontrollimiseks ja nende seose tõendamiseks nimelise OpenID-ga.
Oma otstarbelt sarnaneb OpenPubKey Google'is loodud ning hiljem Linux Foundationile üle antud süsteemiga Sigstore, kuid eristub sellest märkimisväärse lihtsustamisega rakendamisel, kasutamisel ja hooldamisel, eemaldades tsentraliseeritud serverikomponendid, mis hooldavad avalikku logi, mis tõendab muudatuste autentsust (transparency log) ja tagavad tunnustuskeskuste (Certificate Authority) töö.
OpenPubKey ei kasuta enesetunnustamiseks OpenID-tehnoloogiat ning seondub loodud allkiri olemasolevate OpenID Connect pakkujatega. Teisisõnu, OpenPubKey võimaldab siduda krüptograafilisi võtmeid konkreetsete kasutajatega, kasutades OpenID Connect pakkujat (IdP) usalduspunktide asemel. Tehnoloogia on täiesti ühilduv olemasolevate OpenID pakkujatega, nagu GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak ja Google, ning ei nõua nende poole muudatusi (kasutatakse pakkuja poolt esitatud standardset ID-tokenit, mis võimaldab OpenPubKey rakendamist ainult OpenID Connect kliendi poole muudatustega).
OpenID poolt väljastatud token muudetakse sertifikaadiks, mis krüptograafiliselt seondab OpenID Connectis идентификаatori avatud võtmega. Seejärel kasutab kasutaja genereeritud võtit, et allkirjastada mis tahes andmeid ning neid allkirju saab hiljem kontrollida seose leidmiseks OpenID Connectis oleva идентификаatoriga. OpenPubKey kasutab ajutisi ключи, mille eluea on piiratud — võtmed genereeritakse sisenemise ajal OpenID kaudu ja kustutatakse sessiooni lõppedes OpenID pakkujaga.
Umbes OpenPubKey allkirja loomise algoritm:
- Sisenemine OpenID pakkuja (Google, GitHub, Microsoft jne) kaudu.
- Identifitseerimise tokeni küsimine OpenID pakkujalt.
- Tagasi saadetud token, mille on allkirjastanud pakkuja võti ja mis sisaldab "nonce" välja juhuslike andmetega, mis edastati päringus (edastatakse avaliku võtme SHA3-hash).
- Kasutaja poolel saadud tokeni kasutamine sertifikaadina, mis sisaldab teavet võtme kohta.
- Tokeni kinnitamine allkirjaga, analoogiliselt sertifikaadiga.
Verifitseerimine seisneb kontrollimises, kas manustatud token on OpenID pakkuja poolt allkirjastatud ja digitaalse allkirja õigsuse kontrollimises ressursile avatud võtme järgi, mis võimaldab veenduda, et ressurss on allkirjastatud sertifikaadi identifikaatori järgi ja see on OpenID pakkuja allkirjaga kinnitatud. Näiteks võib allkirja loomine saada Google'i poolt allkirjastatud OpenID paketiga tokeni, milles on teave, et ta on kinnitatud kui bob@gmail.com ja kasutab avatud võtit 0x54A5…FF. Edasi, kui saabub sõnum, mis on allkirjastatud sama võtmega, võib saadaja kasutada allkirjastatud pakkuja tokenit, et kinnitada, et võtme bob@gmail.com — 0x54A5…FF ja sõnumi on tõeliselt allkirjastanud bob@gmail.com.
Arhitektuuri lihtsustamine on saavutatud teatud kompromisside kaudu (näiteks sõltuvus välistest OpenID pakkujatest ja muudatuste logi puudumine hierarhilise räsimisega), mis on mõnes olukorras vastuvõetavad, aga teistes mitte. OpenID pakkujatest sõltuvuse vähendamiseks, kelle kompromiteerimine või töötajate tegevus võib süsteemi diskrediteerida (näiteks häkkinud pakkuja võib anda vale võtme kolmandale osapoolele), soovitatakse kasutada täiendavat, kuid mitte kohustuslikku jaotust MFA-Cosigner (Multi-Factor Authentication Cosigner) multi-faktorilise autentimise jaoks (token peab olema allkirjastatud mitte ainult peamise pakkuja, vaid ka sõltumatu autentimisteenuse poolt, mis kinnitab kasutajat).
OpenPubKey nõrkustest on välja toodud ka kolmandate isikute info olemasolu, mida saab kasutada tegevuse jälgimiseks pikka aega ja sõltumatult ümbernimetamisest (tuvastava tokeni korduv rakendamine uue sertifikaadi asemel). Otsene seotus OpenID Connecti võtmetega verifitseerimise ajal välistab serveripoolse osa, kuid liialt keerukaks kliendi poolelt rakendamise ja jätab rohkem manööverdusruumi rünnakute (attack surface) läbiviimiseks kliendi suunas, näiteks seetõttu, et kliendi ülesanne on võtmete rotatsioon. Muudatuste logi puudumine ei võimalda kliendil jälgida võimalikke võtmete lekkeid.
Allikas: opennet.ru
