Linux Foundation, BastionZero i Docker predstavili su novi otvoreni projekt OpenPubKey, koji razvija istoimeni kriptografski protokol za potpisivanje digitalnih objekata. Tehnologija je razvijena kao zajednički projekt kompanija BastionZero i Docker s ciljem pojednostavljenja potpisivanja digitalnim potpisima Docker slika za isključivanje njihove zamjene i potvrđivanje izrade od strane navedenog kreatora. Projekt će se razvijati na neutralnoj platformi pod pokroviteljstvom organizacije Linux Foundation, što će isključiti ovisnost o pojedinim komercijalnim kompanijama i pojednostaviti suradnju uz uključivanje vanjskih sudionika. Referentna implementacija OpenPubKey napisana je na jeziku Go i distribuira se pod Apache 2.0 licencom.
Mogućnosti OpenPubKey ne ograničavaju se samo na Docker slike, a tehnologija se može primijeniti za potvrdu izvora dobivanja bilo kojeg resursa, sprečavanje zamjene zavisnosti i povećanje sigurnosti kanala distribucije skupova podataka. Na primjer, tehnologija se može koristiti za potpisivanje programskih buildova, pojedinačnih poruka i commitova. Kreatorima potpisa dovoljna je registracija u servisu koji podržava OpenID, a potrošačima se pruža mogućnost provjere priključenih potpisa i potvrđivanja njihove povezanosti s navedenim OpenID identifikatorom.
Po svojoj namjeni, OpenPubKey podsjeća na sustav Sigstore koji je stvoren u Googleu i ranije predan Linux Foundationu, ali se razlikuje od njega značajnim pojednostavljenjem implementacije, korištenja i održavanja, budući da se oslobodio centraliziranih server komponenti, odgovornih za vođenje javnog loga koji potvrđuje autentičnost promjena (transparency log), te osiguranje rada certifikacijskih centara (Certificate Authority).
Umjesto postavljanja vlastitih certifikacijskih centara, OpenPubKey koristi autentifikaciju putem OpenID tehnologije i vezivanje kreiranih potpisa uz postojeće OpenID Connect pružatelje. Drugim riječima, OpenPubkey omogućava vezanje kriptografskih ključeva uz specifične korisnike pomoću OpenID Connect pružatelja (IdP) umjesto certifikacijskih centara. Tehnologija je potpuno kompatibilna s postojećim OpenID pružateljima kao što su GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak i Google, i ne zahtijeva promjene s njihove strane (koristi se pružateljem definirani standardni ID token, što omogućava implementaciju OpenPubKey samo putem promjena na strani OpenID Connect klijenta).
Token koji izda pružatelj OpenID pretvara se u certifikat koji kriptografski povezuje identifikator u OpenID Connect s javnim ključem. Nakon toga, korisnik koristi generirani ključ za potpisivanje bilo kojih podataka, a ti potpisi se kasnije mogu provjeriti u odnosu na identifikator u OpenID Connect. U OpenPubKey koriste se efemerni ključevi čiji je vijek trajanja ograničen — ključevi se generiraju tijekom prijave putem OpenID i brišu prilikom završetka sesije s pružateljem OpenID.
Primjer algoritma za stvaranje potpisa koristeći OpenPubKey:
- Prijava koristeći pružatelja OpenID (Google, GitHub, Microsoft itd.).
- Zahtjev za identifikacijski token od pružatelja OpenID.
- Vraćanje tokena, potpisanog ključem pružatelja i uključujući polje „nonce” s proizvoljnim podacima poslanim prilikom zahtjeva (prosljeđuje se SHA3-ključ od javnog ključa).
- Korištenje primljenog tokena s korisničke strane kao certifikata koji uključuje podatke o ključu.
- Priključivanje tokena na potpis, analogno certifikatu.
Verifikacija se svodi na provjeru je li priloženi token potpisan od strane OpenID davatelja i na provjeru ispravnosti digitalnog potpisa resursa putem javnog ključa, što omogućuje uvjeravanje da je resurs potpisan korištenjem identifikatora iz certifikata, a to je potvrđeno potpisom OpenID davatelja. Na primjer, potpisnik može dobiti token potpisan od Google OpenID davatelja s informacijama da je ovjeren kao bob@gmail.com i koristi javni ključ 0x54A5…FF. Kada zaprimi poruku potpisanu istim ključem, može koristiti potpisani token davatelja za verifikaciju da je ključ bob@gmail.com — 0x54A5…FF i da je poruku stvarno potpisao bob@gmail.com.
Pojednostavljenje arhitekture ostvareno je kroz određene kompromise (npr. oslanjanje na vanjske OpenID davatelje 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 davateljima, čija kompromitacija ili djelovanje osoblja mogu diskreditirati sustav (npr. hakirani davatelj može izdati lažni ključ trećoj strani), predlaže se korištenje dodatne, ali ne obavezne, karike MFA-Cosigner (Višefaktorski potpisnik) za višefaktorsku autentifikaciju (token bi trebao biti potpisan ne samo od glavnog davatelja, već i od neovisne usluge autentifikacije koja potvrđuje korisnika).
Među slabim stranama OpenPubKey također se ističe dostupnost informacija trećih strana koje se mogu koristiti za praćenje aktivnosti tijekom dužeg vremena i neovisno o preimenovanjima (ponovna upotreba identifikacijskog tokena umjesto novog certifikata). Izravna povezanost s OpenID Connect ključevima prilikom verifikacije isključuje poslužiteljski dio, ali značajno otežava implementaciju s klijentske strane i ostavlja više prostora za manevar u izvođenju napada (attack surface) na klijenta, primjerice, zato što na klijenta pada zadatak rotacije ključeva. Nedostatak loga promjena ne omogućava klijentu da prati moguće provale ključeva.
Izvor: opennet.ru
