Linux Foundation, BastionZero dhe Docker prezantuan një projekt të ri të hapur OpenPubKey, i cili zhvillon protokollin e kriptografisë me të njëjtin emër për të vërtetuar nënshkrimin digjital të objekteve të rastit. Teknologjia është zhvilluar si një projekt i përbashkët i kompanive BastionZero dhe Docker me qëllim të lehtësimit të vërtetimit me nënshkrim digjital të imazheve të kontejnerëve Docker për të parandaluar manipulimin e tyre dhe për të konfirmuar ndërtimin nga krijuesi i deklaruar. Projekti do të zhvillohet në një platformë neutrale nën mbikëqyrjen e organizatës Linux Foundation, e cila do të eliminojë varësinë nga kompanitë komerciale dhe do të thjeshtojë bashkëpunimin me përfshirjen e palëve të treta. Implementimi referencë i OpenPubKey është shkruar në gjuhën Go dhe shpërndahet me licencën Apache 2.0.
Mundësitë e OpenPubKey nuk kufizohen vetëm në imazhet e kontejnerëve dhe teknologjia mund të përdoret për të konfirmuar burimin e çdo resursi, për të parandaluar manipulimin e varësive dhe për të rritur sigurinë e kanaleve të shpërndarjes së grupeve të të dhënave. Për shembull, teknologjia është e aplikueshme për vërtetimin e ndërtimeve të programeve, mesazheve individuale dhe komiteteve. Krijuesit e nënshkrimit kanë nevojë vetëm për një llogari në një shërbim që mbështet OpenID, ndërsa konsumatorëve u ofrohet mundësia për të verifikuar nënshkrimet e bashkëngjitura dhe për të konfirmuar lidhjen e tyre me identifikuesin e deklaruar OpenID.
Për qëllimet e saj, OpenPubKey ngjason me sistemin Sigstore të krijuar në Google dhe më pas kaluar në Linux Foundation, por dallon prej saj me një thjeshtësi të rëndësishme në implementim, përdorim dhe mbështetje duke hequr komponentët qendrorë, që janë përgjegjës për mbajtjen e një regjistri publik (transparency log) për të konfirmuar autenticitetin e ndryshimeve, dhe për sigurimin e funksionit të qendrave të besimit (Certificate Authority).
Në vend të zhvillimit të qendrave të besimit të veta, në OpenPubKey aplikohet autentifikimi duke përdorur teknologjinë OpenID dhe lidhja e nënshkrimeve të krijuara me ofruesit ekzistues të OpenID Connect. Në fjalë të tjera, OpenPubKey lejon lidhjen e çelësave kriptografikë me përdorues të caktuar duke përdorur ofruesit e OpenID Connect (IdP) në vend të qendrave të besimit. Teknologjia është plotësisht e kompatibilshme me ofruesit ekzistues të OpenID, si GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak dhe Google, dhe nuk kërkon ndryshime nga ana e tyre (përdoret një ID Token standarde e ofruesit, duke lejuar implementimin e OpenPubKey vetëm përmes ndryshimeve nga ana e klientit OpenID Connect).
Tokeni i lëshuar nga ofruesi OpenID transformohet në një certifikatë, e cila lidh kriptografikisht identifikuesin në OpenID Connect me çelësin publik. Pastaj, përdoruesi përdor çelësin e gjeneruar për të nënshkruar çdo të dhënë dhe këto nënshkrime mund të kontrollohen më vonë për lidhje me identifikuesin në OpenID Connect. Në OpenPubKey përdoren çelësa efemerë, koha e jetës së të cilëve është e kufizuar — çelësat gjenerohen gjatë hyrjes me OpenID dhe fshihen kur seanca përfundon me ofruesin OpenID.
Algoritmi i përafërt për krijimin e një nënshkrimi duke përdorur OpenPubKey:
- Hyrje me ofruesin OpenID (Google, GitHub, Microsoft etj.).
- Kërkesa për tokenin identifikues nga ofruesi OpenID.
- Kthimi i tokenit, i nënshkruar me çelësin e ofruesit dhe duke përfshirë fushën "nonce" me të dhëna të rastit të dhëna gjatë kërkesës (shtë e dhënë SHA3-heshi i çelësit publik).
- Përdorimi nga ana e përdoruesit i tokenit të marrë si certifikatë, që përfshin të dhëna për çelësin.
- Kërcënimi i tokenit me nënshkrimin, në mënyrë të ngjashme me certifikatën.
Verifikimi reduktohet në kontrollin nëse tokeni i bashkëngjitur është nënshkruar nga ofruesi OpenID, dhe kontrollin e korrektësisë së nënshkrimit digjital për burimin përmes çelësit publik, që lejon të sigurohemi se burimi është nënshkruar duke përdorur identifikuesin nga certifikata dhe kjo është konfirmuar nga nënshkrimi i ofruesit OpenID. Për shembull, ai që krijon nënshkrimin mund të marrë një token të nënshkruar nga ofruesi OpenID të Google me informacionin se është verifikuar si bob@gmail.com dhe përdor çelësin publik 0x54A5…FF. Më pas, gjatë marrjes së një mesazhi të nënshkruar me të njëjtin çelës, ai mund të përdorë tokenin e nënshkruar nga ofruesi për të verifikuar se çelësi bob@gmail.com — 0x54A5…FF dhe mesazhi vërtetë është nënshkruar nga bob@gmail.com.
Thjeshtimi i arkitekturës është realizuar përmes disa kompromisesh (p.sh., varësia nga ofruesit e jashtëm OpenID dhe mungesa e regjistrit të ndryshimeve me hash të hierarkisë), të cilat në disa situata janë të pranueshme, ndërsa në disa të tjera jo. Për të reduktuar varësinë nga ofruesit e OpenID, të cilët mund të komprometojnë ose veprojnë në mënyrë që të diskreditojnë sistemin (p.sh., një ofrues i hakuar mund të lëshojë një çelës të rremë për një palë të tretë), sugjerohet përdorimi i një lidhjeje shtesë, por jo të detyrueshme, MFA-Cosigner (Cosigner i Autentifikimit me Faktorë të Shumëfishtë) për autentifikimin me shumë faktorë (tokeni duhet të nënshkruhet jo vetëm nga ofruesi kryesor, por edhe nga një shërbim të pavarur autentifikimi që konfirmon përdoruesin).
Si një dobësi e OpenPubKey, gjithashtu do të theksohej përhapja e të dhënave të huaja, të cilat mund të përdoren për të ndjekur aktivitetin për një periudhë të gjatë dhe pavarësisht nga riemërimet (përdorimi i përsëritur të një tokeni identifikues në vend të një certifikate të re). Koshja direkte me çelësat OpenID Connect gjatë verifikimit përjashton pjesën serverike, por e komplikon ndjeshëm realizimin në anën e klientit dhe lë më shumë hapësirë për manovrime gjatë sulmeve (sipërfaqja e sulmeve) ndaj klientit, p.sh., për shkak se bie mbi klient detyra e rotacionit të çelësave. Mungesa e regjistrit të ndryshimeve nuk lejon klientin të ndjekë rrjedhjet e mundshme të çelësave.
Burimi: opennet.ru
