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
