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\u010dki projekt kompanija BastionZero i Docker s ciljem pojednostavljenja potpisivanja digitalnim potpisima Docker slika za isklju\u010divanje njihove zamjene i potvr\u0111ivanje izrade od strane navedenog kreatora. Projekt \u0107e se razvijati na neutralnoj platformi pod pokroviteljstvom organizacije Linux Foundation, \u0161to \u0107e isklju\u010diti ovisnost o pojedinim komercijalnim kompanijama i pojednostaviti suradnju uz uklju\u010divanje vanjskih sudionika. Referentna implementacija OpenPubKey napisana je na jeziku Go i distribuira se pod Apache 2.0 licencom. <\/p>\n
Mogu\u0107nosti OpenPubKey ne ograni\u010davaju se samo na Docker slike, a tehnologija se mo\u017ee primijeniti za potvrdu izvora dobivanja bilo kojeg resursa, spre\u010davanje zamjene zavisnosti i pove\u0107anje sigurnosti kanala distribucije skupova podataka. Na primjer, tehnologija se mo\u017ee koristiti za potpisivanje programskih buildova, pojedina\u010dnih poruka i commitova. Kreatorima potpisa dovoljna je registracija u servisu koji podr\u017eava OpenID, a potro\u0161a\u010dima se pru\u017ea mogu\u0107nost provjere priklju\u010denih potpisa i potvr\u0111ivanja njihove povezanosti s navedenim OpenID identifikatorom. <\/p>\n
Po svojoj namjeni, OpenPubKey podsje\u0107a na sustav Sigstore koji je stvoren u Googleu i ranije predan Linux Foundationu, ali se razlikuje od njega zna\u010dajnim pojednostavljenjem implementacije, kori\u0161tenja i odr\u017eavanja, budu\u0107i da se oslobodio centraliziranih server komponenti, odgovornih za vo\u0111enje javnog loga koji potvr\u0111uje autenti\u010dnost promjena (transparency log), te osiguranje rada certifikacijskih centara (Certificate Authority). <\/p>\n
Umjesto postavljanja vlastitih certifikacijskih centara, OpenPubKey koristi autentifikaciju putem OpenID tehnologije i vezivanje kreiranih potpisa uz postoje\u0107e OpenID Connect pru\u017eatelje. Drugim rije\u010dima, OpenPubkey omogu\u0107ava vezanje kriptografskih klju\u010deva uz specifi\u010dne korisnike pomo\u0107u OpenID Connect pru\u017eatelja (IdP) umjesto certifikacijskih centara. Tehnologija je potpuno kompatibilna s postoje\u0107im OpenID pru\u017eateljima kao \u0161to su GitHub, Azure\/Microsoft, Okta, OneLogin, Keycloak i Google, i ne zahtijeva promjene s njihove strane (koristi se pru\u017eateljem definirani standardni ID token, \u0161to omogu\u0107ava implementaciju OpenPubKey samo putem promjena na strani OpenID Connect klijenta). <\/p>\n
Izdan OpenID token se pretvara u certifikat koji kriptografski povezuje identifikator u OpenID Connect s javnim klju\u010dem. Korisnik zatim koristi generirani klju\u010d za potpisivanje bilo kojih podataka, a ti potpisi se naknadno mogu provjeriti s obzirom na vezu s identifikatorom u OpenID Connect. U OpenPubKey se koriste efemerni klju\u010devi \u010diji je vijek trajanja ograni\u010den \u2014 klju\u010devi se generiraju tijekom prijave putem OpenID i bri\u0161u se na kraju sesije s OpenID pru\u017eateljem. <\/p>\n
Primjer algoritma za stvaranje potpisa koriste\u0107i OpenPubKey: <\/p>\n
Verifikacija se svodi na provjeru je li prilo\u017eeni token potpisan od strane OpenID pru\u017eatelja i provjeru ispravnosti digitalnog potpisa za resurs pomo\u0107u javnog klju\u010da, \u010dime se osigurava da je resurs potpisan koriste\u0107i identifikator iz certifikata i da je to potvr\u0111eno potpisom OpenID pru\u017eatelja. Na primjer, osoba koja potpisuje mo\u017ee dobiti potpisani OpenID token od Google-a s informacijom da je verifikovan kao bob@gmail.com i koristi javni klju\u010d 0x54A5\u2026FF. Zatim, kada primi poruku potpisanu istim klju\u010dem, mo\u017ee koristiti potpisani token od strane pru\u017eatelja za verifikaciju da je klju\u010d bob@gmail.com \u2014 0x54A5\u2026FF i da je poruku zaista potpisao bob@gmail.com. <\/p>\n
Pojednostavljenje arhitekture ostvareno je kroz odre\u0111ene kompromise (npr. ovisnost o vanjskim OpenID pru\u017eateljima i nedostatak loga promjena s hijerarhijskim he\u0161iranjem), koji su u nekim situacijama prihvatljivi, a u drugima nisu. Kako bi se smanjila ovisnost o OpenID pru\u017eateljima, \u010dija kompromitacija ili postupci osoblja mogu diskreditirati sustav (npr. hakirani pru\u017eatelj mo\u017ee izdati la\u017eni klju\u010d tre\u0107oj strani), predla\u017ee se kori\u0161tenje dodatnog, ali neobaveznog, sloja MFA-Cosigner (Multi-Factor Authentication Cosigner) za vi\u0161efaktorsku autentifikaciju (token treba biti potpisan ne samo od glavnog pru\u017eatelja, ve\u0107 i od neovisne usluge autentifikacije koja potvr\u0111uje korisnika). <\/p>\n