A Linux Foundation, a BastionZero és a Docker bemutatta az OpenPubKey nevű új nyílt projektet, amely a hasonló nevű kriptográfiai protokollt fejleszti a digitális aláírás által bármilyen objektum hitelesítésére. A technológiát a BastionZero és a Docker cégek közös projektjeként alakították ki, célja a Docker konténerek digitális aláírással történő hitelesítésének egyszerűsítése, hogy megakadályozza azok hamisítását és megerősítse a gyártó által megadott összeállítást. A projekt a Linux Foundation szervezet védnöksége alatt semleges platformon fog fejlődni, ezáltal kizárva a függőséget egyes kereskedelmi cégektől és megkönnyítve a külső résztvevők bevonását. Az OpenPubKey referenciakivitelezése Go nyelven íródott, és Apache 2.0 licenc alatt terjesztik.
Az OpenPubKey képességei nemcsak a konténerek képeire korlátozódnak, hanem a források hitelesítésére is alkalmazható, megakadályozva a függőségek hamisítását és növelve az adatcsomagok terjesztési csatornáinak biztonságát. Például a technológia alkalmazható programok, külön üzenetek és commitok összeállításának hitelesítésére. Az aláírás készítője számára elegendő, ha rendelkezik egy OpenID-t támogató szolgáltatásban lévő fiókkal, míg a felhasználók lehetőséget kapnak a csatolt aláírások ellenőrzésére és azok megállapított OpenID azonosítóhoz való kapcsolódásának megerősítésére.
Funkcióját tekintve az OpenPubKey hasonlít a Google által létrehozott és korábban a Linux Foundation-nek átadott Sigstore rendszerhez, de lényegesen egyszerűsíti a bevezetést, a használatot és a karbantartást azáltal, hogy megszabadít a központosított szerver komponensektől, amelyek a változások hitelességét megerősítő nyilvános napló (transparency log) vezetéséért és az igazolási központok (Certificate Authority) működtetéséért felelnek.
Az OpenPubKey nem saját tanúsítványi központok kiépítését alkalmazza, hanem az OpenID technológia alapú hitelesítést, és a létrehozott aláírásokat létező OpenID Connect szolgáltatókhoz köti. Más szóval, az OpenPubKey lehetővé teszi a kriptográfiai kulcsok konkrét felhasználókhoz való hozzárendelését az OpenID Connect szolgáltatók (IdP) használatával a tanúsítványi központok helyett. A technológia teljes mértékben kompatibilis a meglévő OpenID szolgáltatókkal, mint például a GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak és Google, és nem igényel módosításokat részükről (a szolgáltató által biztosított alapértelmezett ID Token használatával az OpenPubKey megvalósítható kizárólag az OpenID Connect kliens oldali módosításaival).
A szolgáltató által kiadott OpenID token egy tanúsítvánnyá alakul, amely kriptográfiai módon köti az OpenID Connect azonosítót a nyílt kulcshoz. Ezt követően a felhasználó a generált kulcsot használja bármilyen adat aláírására, és ezek az aláírások később ellenőrizhetők az OpenID Connect azonosítóval való kapcsolatra. Az OpenPubKey efemer kulcsokat alkalmaz, amelyek élettartama korlátozott — a kulcsok az OpenID segítségével való belépéskor generálódnak, és a OpenID szolgáltatóval való kapcsolat végén törlődnek.
Az OpenPubKey használatával történő aláírás létrehozásának példás algoritmusai:
- Bejelentkezés OpenID szolgáltatóval (Google, GitHub, Microsoft stb.).
- Az OpenID szolgáltatótól az azonosító token lekérése.
- A szolgáltató által aláírt token visszaküldése, amely tartalmaz egy 'nonce' mezőt az előző kérés során átadott véletlenszerű adatokkal (az nyílt kulcs SHA3-hash-e kerül átadásra).
- A felhasználó oldalán kapott token felhasználása tanúsítványként, amely tartalmazza a kulcról szóló adatokat.
- A token csatolása az aláíráshoz, hasonlóan a tanúsítványhoz.
A hitelesítés lényege, hogy ellenőrizzük, a csatolt token aláírását az OpenID szolgáltató végezte-e, és hogy a digitális aláírás helyes-e, az nyílt kulcs alapján, ami biztosítja, hogy az erőforrás azonosítónak a tanúsítványból származik, és ezt az OpenID szolgáltató aláírása megerősíti. Például, aki az aláírást létrehozza, kaphat egy Google által aláírt OpenID token-t, amely információt tartalmaz arról, hogy őt a bob@gmail.com címéről hitelesítették, és az nyílt kulcs 0x54A5…FF. Továbbá, amikor egy ugyanazzal a kulccsal aláírt üzenet érkezik, a címzett felhasználhatja a szolgáltató által aláírt tokent, hogy hitelesítse, hogy a kulcs bob@gmail.com - 0x54A5…FF, és az üzenetet valóban bob@gmail.com írta alá.
Az architektúra egyszerűsítése bizonyos kompromisszumok árán valósult meg (például a külső OpenID szolgáltatókra való támaszkodás és a hierarchikus hash-elés nélküli naplózás), amelyek bizonyos esetekben elfogadhatók, míg másokban nem. Az OpenID szolgáltatóktól való függőség csökkentése érdekében, akinek kompromittálódása vagy a személyzet tettei diszkreditálhatják a rendszert (például ha a szolgáltató feltörésre kerül, akkor hamis kulcsot adhat meg egy harmadik félnek), javasolt egy kiegészítő, de nem kötelező, MFA-Cosigner (Többfaktoros Hitelesítés Közjegyző) tag használata a többfaktoros hitelesítéshez (a tokent nemcsak a fő szolgáltatónak, hanem egy független hitelesítési szolgáltatásnak is alá kell írásnia, amely megerősíti a felhasználót).
Az OpenPubKey gyengeségei között említést nyer, hogy idegen információk állnak rendelkezésre, amelyek hosszú távon és átnevezésektől függetlenül használhatók az aktivitás nyomon követésére (az azonosító token újrafelhasználása új tanúsítvány helyett). Az OpenID Connect kulcsokkal való közvetlen kapcsolódás a hitelesítés során kizárja a szerveroldali részt, de jelentősen megnehezíti a kliensoldali megvalósítást, és több mozgási teret hagy a kliens elleni támadások számára (támadási felület), például mert a kulcsok forgatása a kliens feladata. A naplózás hiánya megakadályozza a kliens számára a kulcsok lehetséges szivárgásának nyomon követését.
Forrás: opennet.ru
