Linux Foundation, BastionZero in Docker so sprostili nov novi odprti projekt OpenPubKey, ki razvija istoimenski kriptografski protokol za overjanje digitalnih podpisov poljubnih objektov. Tehnologija je bila razvita kot skupni projekt podjetij BastionZero in Docker z namenom poenostavitve overjanja digitalnih podpisov slik Docker kontejnerjev za preprečevanje njihove zamenjave in potrjevanje sestave s strani deklariranega ustvarjalca. Projekt se bo razvijal na nevtralni platformi pod okriljem organizacije Linux Foundation, kar bo izključilo odvisnost od posameznih komercialnih podjetij in poenostavilo sodelovanje z vključevanjem zunanjih udeležencev. Referenčna izvedba OpenPubKey je napisana v jeziku Go in se distribuira pod licenco Apache 2.0.
Možnosti OpenPubKey niso omejene le na slike kontejnerjev, temveč se lahko tehnologija uporablja za potrditev vira pridobivanja kateregakoli vira, preprečevanje zamenjave odvisnosti in povečanje varnosti kanalov za distribucijo nizov podatkov. Na primer, tehnologija je uporabna za overjanje sestavkov programov, posameznih sporočil in commitov. Ustvarjalcem podpisov zadostuje imeti račun v storitvi, ki podpira OpenID, medtem ko uporabnikom omogoča preverjanje pripetih podpisov in potrjevanje njihove povezave z deklariranim identifikatorjem OpenID.
Po svoji namembnosti OpenPubKey spominja na sistem Sigstore, ki je bil ustvarjen v Googlu in predan Linux Foundation, vendar se razlikuje od njega s pomembnim poenostavljenjem uvedbe, uporabe in vzdrževanja s tem, da se odreče centraliziranim strežniškim komponentam, ki so odgovorne za vodenje javnega dnevnika, ki dokazuje pristnost sprememb (transparency log), in zagotavljanje delovanja overitvenih centrov (Certificate Authority).
Namesto uvajanja lastnih overitvenih centrov v OpenPubKey se uporablja avtentikacija s tehnologijo OpenID in povezovanje ustvarjenih podpisov z obstoječimi ponudniki OpenID Connect. Drugače povedano, OpenPubkey omogoča, da se kriptografski ključi povežejo s specifičnimi uporabniki, pri čemer se uporabljajo ponudniki OpenID Connect (IdP) namesto overitvenih centrov. Tehnologija je popolnoma združljiva z obstoječimi ponudniki OpenID, kot so GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak in Google, in ne zahteva sprememb na njihovi strani (uporablja se standardni ID Token, ki ga ponudi ponudnik, kar omogoča implementacijo OpenPubKey le s spremembami na strani stranke OpenID Connect).
Tokon, ki ga izda ponudnik OpenID, se preoblikuje v certifikat, ki kriptografsko povezuje identifikator v OpenID Connect z javnim ključem. Nato uporabnik uporablja generirani ključ za podpis kakršnih koli podatkov, ti podpisi pa se lahko kasneje preverjajo glede na povezavo z identifikatorjem v OpenID Connect. V OpenPubKey se uporabljajo efemerne ključne, katere življenjska doba je omejena — ključi se generirajo ob prijavi s pomočjo OpenID in se odstranijo ob zaključku seje s ponudnikom OpenID.
Približni algoritem za ustvarjanje podpisa z uporabo OpenPubKey:
- Prijava z uporabo ponudnika OpenID (Google, GitHub, Microsoft itd.).
- Zahteva za identifikacijski token pri ponudniku OpenID.
- Vračilo tokena, podpisanega s ključem ponudnika in vključujočega polje „nonce“ s poljubnimi podatki, poslanimi ob zahtevi (posreduje se SHA3-Hash javnega ključa).
- Uporaba na strani uporabnika prejetega tokena kot certifikata, ki vključuje podatke o ključu.
- Pripenjanje tokena k podpisu, podobno kot pri certifikatu.
Verifikacija se svodi na provjeru je li priloženi token potpisan od strane OpenID providera i provjeru valjanosti digitalnog potpisa resursa putem javnog ključa, što omogućava uvjeravanje da je resurs potpisan korištenjem identifikatora iz certifikata, a to potvrđuje potpis OpenID providera. Na primjer, potpisnik može dobiti token potpisan od Google-ovog OpenID providera s informacijama da je verificiran kao bob@gmail.com i koristi javni ključ 0x54A5…FF. Kada primi poruku potpisanu istim ključem, može koristiti potpisani token od providera za verifikaciju da ključ bob@gmail.com — 0x54A5…FF i da je poruku zaista potpisao bob@gmail.com.
Pojednostavljenje arhitekture realizirano je kroz određene kompromise (na primjer, ovisnost o vanjskim OpenID providerima i nedostatak loga promjena s hijerarhijskim heširanjem), koji su u nekim situacijama prihvatljivi, a u nekima nisu. Kako bi se smanjila ovisnost o OpenID providerima, čija kompromitacija ili postupci osoblja mogu diskreditirati sustav (na primjer, hakeri koji kompromitiraju providera mogu izdati lažni ključ trećoj strani), predlaže se korištenje dodatnog, ali neobaveznog, povezivanja MFA-Cosigner (Višefaktorska autentifikacija Cosigner) za višefaktorsku autentifikaciju (token treba biti potpisan ne samo od glavnog providera, već i od neovisne autentifikacijske usluge koja potvrđuje korisnika).
Među slabostima OpenPubKey također se ističe postojanje vanjskih informacija koje se mogu koristiti za praćenje aktivnosti dugoročno i neovisno o promjenama imena (ponovno korištenje identifikacijskog tokena umjesto novog certifikata). Direktna vezanost uz ključeve OpenID Connect prilikom verifikacije isključuje serverski dio, ali značajno otežava implementaciju na strani klijenta i ostavlja više prostora za manevarske napade (attack surface) na klijenta, na primjer, zbog toga što je klijent odgovoran za rotaciju ključeva. Nedostatak loga promjena ne omogućava klijentu praćenje mogućih curenja ključeva.
Izvor: opennet.ru
