„Linux Foundation“, „BastionZero“ ir „Docker“ pristatė naują atvirą projektą „OpenPubKey“, kuris kuria to paties pavadinimo kriptografinį protokolą savavališkų objektų skaitmeniniam pasirašymui. Ši technologija buvo sukurta kaip bendras „BastionZero“ ir „Docker“ projektas, siekiant supaprastinti „Docker“ konteinerių vaizdų skaitmeninį parašą, kad būtų išvengta jų pakeitimo ir patvirtintų deklaruoto kūrėjo kūrimą. Projektas bus plėtojamas neutralioje platformoje, globojamoje „Linux Foundation“, kuri pašalins priklausomybę nuo atskirų komercinių įmonių ir supaprastins bendradarbiavimą įtraukiant trečiąsias šalis. „OpenPubKey“ nuorodos įgyvendinimas yra parašytas „Go“ ir platinamas pagal „Apache 2.0“ licenciją.
„OpenPubKey“ galimybės neapsiriboja konteinerio vaizdais, o technologija gali būti naudojama patvirtinti bet kokio šaltinio šaltinį, užkirsti kelią priklausomybės pakeitimui ir pagerinti duomenų rinkinių platinimo kanalų saugumą. Pavyzdžiui, ši technologija taikoma tikrinant programų rinkinius, atskirus pranešimus ir įsipareigojimus. Parašų kūrėjams tereikia turėti paskyrą OpenID palaikančioje tarnyboje, o vartotojams suteikiama galimybė patikrinti pridėtus parašus ir patvirtinti savo ryšį su deklaruotu OpenID identifikatoriumi.
Pagal paskirtį „OpenPubKey“ primena „Google“ sukurtą ir anksčiau „Linux Foundation“ perduotą „Sigstore“ sistemą, tačiau nuo jos skiriasi tuo, kad žymiai supaprastina diegimą, naudojimą ir priežiūrą, nes atsikrato centralizuotų serverio komponentų, atsakingų už autentiškumą patvirtinančio viešojo žurnalo palaikymą. pakeitimų (skaidrumo žurnalas) ir sertifikavimo institucijų (Sertifikavimo institucijos) veiklos užtikrinimas.
Užuot įdiegę savo sertifikatų institucijas, „OpenPubKey“ naudoja „OpenID“ autentifikavimo technologiją ir susieja sukurtus parašus su esamais „OpenID Connect“ teikėjais. Kitaip tariant, „OpenPubkey“ leidžia susieti kriptografinius raktus su konkretiems vartotojams, naudojant „OpenID Connect“ teikėjus (IdP), o ne sertifikatų institucijas. Technologija yra visiškai suderinama su esamais OpenID teikėjais, tokiais kaip „GitHub“, „Azure/Microsoft“, „Okta“, „OneLogin“, „Keycloak“ ir „Google“, ir nereikalauja pakeitimų iš jų pusės (naudojamas standartinis teikėjo pateiktas ID prieigos raktas, leidžiantis įgyvendinti OpenPubKey tik atlikus pakeitimus kliento pusėje OpenID Connect).
OpenID teikėjo išduotas prieigos raktas paverčiamas sertifikatu, kuris kriptografiškai susieja OpenID Connect identifikatorių su viešuoju raktu. Tada vartotojas naudoja sugeneruotą raktą bet kokiems duomenims pasirašyti ir vėliau šiuos parašus galima patikrinti pagal OpenID Connect identifikatorių. „OpenPubKey“ naudoja trumpalaikius raktus, kurių veikimo laikas yra ribotas – raktai generuojami prisijungiant prie „OpenID“ ir ištrinami, kai baigiasi sesija su „OpenID“ teikėju.
Parašo kūrimo naudojant OpenPubKey algoritmo pavyzdys:
- Prisijunkite naudodami OpenID teikėją („Google“, „GitHub“, „Microsoft“ ir kt.).
- Paprašykite ID prieigos rakto iš OpenID teikėjo.
- Teikėjo rakto pasirašyto prieigos rakto grąžinimas ir laukelio „nonce“ įtraukimas su savavališkais duomenimis, perduotais užklausos metu (persiunčiama viešojo rakto SHA3 maiša).
- Naudokite gauto prieigos rakto vartotojo pusėje kaip sertifikatą, įskaitant raktinius duomenis.
- Žetono pritvirtinimas prie parašo, panašus į sertifikatą.
Patikrinimas susideda iš patikrinimo, ar pridėtas prieigos raktas yra pasirašytas „OpenID“ teikėjo, ir ištekliaus skaitmeninio parašo teisingumo patikrinimo naudojant viešąjį raktą. Tai leidžia įsitikinti, kad išteklius yra pasirašytas naudojant sertifikate esantį identifikatorių ir kad tai patvirtina „OpenID“ teikėjo parašas. Pavyzdžiui, parašo kūrėjas gali gauti „Google OpenID“ teikėjo pasirašytą prieigos raktą su informacija, kad jis patvirtintas kaip bob@gmail.com ir naudoja viešąjį raktą 0x54A5…FF. Tada, gavęs tuo pačiu raktu pasirašytą pranešimą, gavėjas gali naudoti teikėjo pasirašytą prieigos raktą, kad patikrintų, ar raktas bob@gmail.com yra 0x54A5…FF ir ar pranešimą tikrai pasirašė bob@gmail.com.
Architektūros supaprastinimas pasiekiamas taikant tam tikrus kompromisus (pavyzdžiui, priklausomybę nuo išorinių OpenID tiekėjų ir pakeitimų žurnalo su hierarchine maiša nebuvimą), kurie kai kuriose situacijose priimtini, o kitose – ne. Siekiant sumažinti priklausomybę nuo OpenID tiekėjų, kurių darbuotojų kompromisas ar veiksmai gali diskredituoti sistemą (pavyzdžiui, įsilaužti teikėjai gali išduoti fiktyvų raktą trečiajai šaliai), siūloma naudoti papildomą, bet neprivalomą MFA-Cosigner. (Multi-Factor Authentication Cosigner) nuoroda, skirta kelių veiksnių autentifikavimui (žetoną turi pasirašyti ne tik pagrindinis teikėjas, bet ir nepriklausoma autentifikavimo tarnyba, kuri patvirtina vartotoją).
Vienas iš OpenPubKey trūkumų taip pat yra pašalinės informacijos, kurią galima naudoti norint stebėti veiklą ilgą laiką ir neatsižvelgiant į pervadinimą (pakartotinis identifikavimo prieigos rakto naudojimas vietoj naujo sertifikato), buvimas. Tiesioginis prisijungimas prie OpenID Connect raktų tikrinimo metu pašalina serverio dalį, tačiau žymiai apsunkina diegimą kliento pusėje ir palieka daugiau veiksmų laisvės įvykdant atakas (atakos paviršių) prieš klientą, pavyzdžiui, dėl to, kad užduotis raktų sukimas tenka klientui. Pakeitimų žurnalo nebuvimas neleidžia klientui stebėti galimo rakto nutekėjimo.
Šaltinis: opennet.ru
