Tutvustatakse OpenPubKey-d, krüptograafiliste objektide valideerimise protokolli.

Linux Foundation, BastionZero ja Docker esitlesid uut avatud projekti OpenPubKey, mis arendab välja sama nime kandnud krüptograafilise protokolli, et tõendada digitaalset allkirja mis tahes objektide puhul. Tehnoloogia on välja töötatud BastionZero ja Dockeri ettevõtete koostööprojektina, et lihtsustada digitaalsete allkirjade tõendamist Docker konteineripiltidel, vältides nende manipulatsiooni ja kinnitades koostamise nõutava autori poolt. Projekt areneb neutraalses keskkonnas Linux Foundationi kaitse all, mis välistab sõltuvuse üksikutest kommertsettevõtetest ja lihtsustab koostööd teiste osaliste kaasamisel. OpenPubKey põhiimplementatsioon on kirjutatud Go keeles ja selle levitamine toimub Apache 2.0 litsentsi alusel.

OpenPubKey'i võimalused ei piirdu ainult konteineripiltidega; tehnoloogiat saab rakendada mis tahes ressursi allika tõendamiseks, sõltuvuste vahetamise vältimiseks ja andmekogumite levikanalite turvalisuse suurendamiseks. Näiteks on tehnoloogia rakendatav programmide kogumite, üksikute teadete ja commitide allkirjastamiseks. Allkirjade loojatel on piisav, et neil oleks konto OpenID toetavas teenuses, samas kui tarbijatel on võimalus kinnitada lisatud allkirju ja kontrollida nende seotust väidetava OpenID identifikaatoriga.

Eesmärgilt sarnaneb OpenPubKey Google'is loodud ja hiljem Linux Foundation'ile edastatud Sigstore süsteemiga, kuid erineb sellest oluliselt lihtsustatud rakendamise, kasutamise ja hooldamise poolest, vabastades tsentraliseeritud serverikomponentidest, mis vastutavad avaliku tegevuslogi (transparency log) pidamise eest, mis kinnitab muudatuste autentsust, ja sertifitseerimisteenuste (Certificate Authority) toimimise tagamise eest.

OpenPubKey kasutab autentimist OpenID tehnoloogia abil, mitte eraldi väljastatud tunnistuste keskuste loomist, ning seob loodud allkirjad olemasolevate OpenID Connect pakkujatega. Teisisõnu, OpenPubKey võimaldab siduda krüptograafilised võtmed konkreetsete kasutajatega, kasutades OpenID Connect pakkujad (IdP), mitte tunnistuste keskusi. Tehnoloogia on täielikult ühilduv olemasolevate OpenID pakkujatega, nagu GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak ja Google, ning ei nõua nende poolt muudatusi (kasutatakse pakkuja poolt antud standardset ID Tokenit, mis võimaldab OpenPubKeyd rakendada vaid OpenID Connect klientide poole muudatustega).

OpenID pakkuja poolt välja antud token muudetakse sertifikaadiks, mis krüptograafiliselt seob OpenID Connecti identifikaatori avaliku võtmega. Edasi kasutab kasutaja genereeritud võtit andmete allkirjastamiseks, ja neid allkirju saab hiljem kontrollida seose osas OpenID Connecti identifikaatoriga. OpenPubKey-s kasutatakse ajutisi võtmeid, mille eluaeg on piiratud — võtmed genereeritakse sisenemise ajal OpenID kaudu ja kustutatakse sessiooni lõppedes.

Umbkaudne allkirjastamise loomise algoritm OpenPubKey'i kasutamisega:

• Sisenemine OpenID pakkuja kaudu (nt Google, GitHub, Microsoft jne).
• Identifikaatori tokeni taotlemine OpenID pakkujalt.
• Tokeni tagastamine, mis on allkirjastatud pakkuja võtmega ja sisaldab "nonce" välja, kus on anekdootsed andmed, mis on edastatud taotluse käigus (edastatakse SHA3-hash avalikust võtmes).
• Kasutaja poolt saadud tokeni kasutamine sertifikaadina, mis sisaldab teavet võtme kohta.
• Tokeni kinnitamine allkirjale, sarnaselt sertifikaadiga.

Kinnitus hõlmab kontrollimist, kas lisatud token on OpenID pakkuja poolt allkirjastatud ja digitaalallkirja õigsuse kontrollimist ressursside suhtes avatud võtme abil, mis kinnitab, et ressurss on allkirjastatud sertifikaadi identifikaatori ja selle OpenID pakkuja allkirjaga. Näiteks võib allkirja loov kasutada Google'i OpenID pakkuja poolt allkirjastatud tokenit, mis sisaldab teavet, et ta on kinnitatud kui bob@gmail.com ja kasutab avatud võtme 0x54A5…FF. Seetõttu, kui saabub sama võtmega allkirjastatud sõnum, võib kasutaja kasutada allkirjastatud tokenit selleks, et kinnitada, et bob@gmail.com — 0x54A5…FF ja sõnumi on tõepoolest allkirjastanud bob@gmail.com.

Arhitektuuri lihtsustamine on saavutatud teatud kompromisside arvelt (näiteks sõltuvus välisest OpenID pakkujst ja muudatuste logi puudumine hierarhilise räsi kasutamisega), mis on mõnes olukorras vastuvõetavad, teistes aga mitte. OpenID pakkujatest sõltuvuse vähendamiseks, kelle kompromiteerimine või töötajate tegevus võib süsteemi diskrediteerida (näiteks häkitud pakkuja võib kolmandale osapoolele vale võtme anda), soovitatakse kasutada täiendavat, kuid mitte kohustuslikku MFA-Cosigner (Mitme-Faktori Autentimise Kooskõlastaja) kihti mitme-faktori autentimiseks (token peab olema allkirjastatud mitte ainult peamise pakkuja, vaid ka sõltumatu autentimisteenuse poolt, mis kinnitab kasutajat).

OpenPubKey nõrkustena tuuakse välja ka kolmandate isikute andmed, mida saab kasutada aktiivsuse jälgimiseks pikka aega ja sõltumatult ümbernimetamisest (tuvastustokeni taaskasutamine uue sertifikaadi asemel). Otsene seos OpenID Connecti võtmetega välistab serveripoolse komponenti, kuid muudab kliendi poolse rakendamise oluliselt keerulisemaks ja jätab rohkem ruumi klientide rünnakuteks (attack surface), näiteks seetõttu, et kliendile lasub võtmete vahetamise kohustus. Muudatuste logi puudumine ei võimalda kliendil jälgida võimalikke võtmelekkeid.

Allikas: opennet.ru