Linux Foundation, BastionZero dhe Docker prezantuan projektin e ri të hapur OpenPubKey, i cili zhvillon protokollin kriptografik të së njëjtës emër për verifikimin e objektiveve të rastit me nënshkrim digjital. Teknologjia është zhvilluar si një projekt i përbashkët i kompanive BastionZero dhe Docker me qëllimin për të thjeshtuar verifikimin e nënshkrimeve digjitale të imazheve të kontejnerëve Docker për të përjashtuar manipulimin e tyre dhe për të konfirmuar ndërtimin nga krijuesi i shpallur. Projekti do të zhvillohet në një platformë neutrale nën mbështetje të organizatës Linux Foundation, duke eliminuar varësinë nga kompanitë e veçanta tregtare dhe duke thjeshtuar bashkëpunimin me angazhimin e palëve të treta. Implementimi referues i OpenPubKey është shkruar në gjuhën Go dhe shpërndahet nën licencën Apache 2.0.
Aftësitë e OpenPubKey nuk kufizohen vetëm në imazhet e kontejnerëve dhe teknologjia mund të përdoret për të konfirmuar burimin e marrjes së çdo burimi, për të parandaluar manipulimin e varësive dhe për të përmirësuar sigurinë e kanaleve të shpërndarjes së grupeve të dhënash. Për shembull, teknologjia është e aplikueshme për verifikimin e ndërtimeve të programeve, mesazheve të veçanta 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ët kanë mundësinë të verifikojnë nënshkrimet e ngjitura dhe të konfirmojnë lidhjen e tyre me identifikuesin e shpallur OpenID.
Në funksionin e saj, OpenPubKey i ngjan sistemit Sigstore të krijuar nga Google dhe më parë e kaluar në Linux Foundation, por dallohet nga ajo për thjeshtësimin e rëndësishëm të implementimit, përdorimit dhe mbështetjes për shkak të eliminimit të komponentëve serverë të centralizuar, të cilët janë përgjegjës për mbajtjen e një logu publik që konfirmon origjinalitetin e ndryshimeve (transparency log) dhe për sigurimin e funksionit të autoriteteve të nënshkrimit (Certificate Authority).
Në vend të zhvillimit të qendrave të certifikimit të vetë-përmbajtura, OpenPubKey përdor autentifikimin me teknologjinë OpenID dhe lidhjen e nënshkrimeve të krijuara me ofruesit ekzistues të OpenID Connect. Në të tjera fjalë, 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ë certifikimit. Teknologjia është plotësisht e përputhshme 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 ID Token tipik i ofruar nga ofruesi, çka lejon që OpenPubKey të realizohet vetëm përmes ndryshimeve në anën e klientit të OpenID Connect).
Token-i i lĂ«shuar nga ofruesi OpenID transformohet nĂ« njĂ« certifikat, e cila lidh kriptografikisht identifikuesin nĂ« OpenID Connect me çelĂ«sin publik. MĂ« pas, pĂ«rdoruesi pĂ«rdor çelĂ«sin e gjeneruar pĂ«r tĂ« nĂ«nshkruar tĂ« dhĂ«na tĂ« ndryshme dhe kĂ«to nĂ«nshkrime mund tĂ« verifikohen pĂ«r lidhjen 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 krijohen gjatĂ« hyrjes pĂ«rmes OpenID dhe fshihen nĂ« pĂ«rfundim tĂ« sesionit me ofruesin OpenID.
Algoritmi i përafërt për krijimin e nënshkrimit duke përdorur OpenPubKey:
- Hyrje duke përdorur ofruesin OpenID (Google, GitHub, Microsoft etj.).
- Kërkesa për token-in e identifikimit nga ofruesi OpenID.
- Kthimi i token-it, i nënshkruar me çelësin e ofruesit dhe përfshirja e fushës "nonce" me të dhëna të rastësishme të kaluar gjatë kërkesës (dërgohet një hash SHA3 i çelësit publik).
- Përdorimi nga ana e përdoruesit i token-it të marrë si një certifikatë, që përmban të dhëna mbi çelësin.
- Prishtja e token-it me nënshkrimin, në mënyrë të ngjashme me një certifikatë.
Verifikimi pĂ«rfshin kontrollin nĂ«se tokeni i bashkangjitur Ă«shtĂ« nĂ«nshkruar nga ofruesi OpenID dhe verifikimin e saktĂ«sisĂ« sĂ« nĂ«nshkrimit digjital nĂ« burim pĂ«rmes çelĂ«sit publik, gjĂ« qĂ« lejon verifikimin se burimi Ă«shtĂ« nĂ«nshkruar duke pĂ«rdorur identifikuesin nga certifikata dhe se kjo konfirmohet 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 i Google me informacion se ai Ă«shtĂ« verifikuar si bob@gmail.com dhe pĂ«rdor çelĂ«sin publik 0x54A5âŠFF. MĂ« pas, kur merr njĂ« mesazh 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 Ă«shtĂ« vĂ«rtet nĂ«nshkruar nga bob@gmail.com.
Thjeshtimi i arkitekturës është realizuar përmes disa kompromisive (për shembull, varësia nga ofruesit e jashtëm OpenID dhe mungesa e një regjistri të ndryshimeve me hash hierarkik), të cilat në disa raste janë të pranueshme, ndërsa në të tjera jo. Për të reduktuar varësinë nga ofruesit OpenID, kompremitimi ose veprimet e stafit të cilëve mund të diskreditojnë sistemin (për shembull, një ofrues i hackuar mund të lëshojë një çelës fiktiv për një palë të tretë) propozohet përdorimi i një lidhjeje shtesë, por jo të domosdoshme, MFA-Cosigner (Multi-Factor Authentication Cosigner) për autentifikimin me shumë faktorë (tokeni duhet të jetë i nënshkruar jo vetëm nga ofruesi kryesor, por edhe nga një shërbim autentifikimi të pavaruara që konfirmon përdoruesin).
Disa nga dobësitë e OpenPubKey gjithashtu përfshijnë praninë e informacionit të huaj, i cili mund të përdoret për të ndjekur aktivitetin gjatë një periudhe të gjatë dhe pavarësisht emrave të rinj (përdorimi i përsëritur të tokenit identifikues në vend të një certifikate të re). Lidhja e drejtpërdrejtë me çelësat OpenID Connect gjatë verifikimit e përjashton anën e serverit, por e komplikon në mënyrë të konsiderueshme zbatimin në anën e klientit dhe lë më shumë hapësirë për manovra gjatë kryerjes së sulmeve (attack surface) ndaj klientit, për shembull, për shkak se klienti ka detyrën e rotacionit të çelësave. Mungesa e një regjistri të ndryshimeve nuk lejon që klienti të ndjekë ngjarjet e mundshme të rrjedhjes së çelësave.
Burimi: opennet.ru
