A Linux Foundation, a BastionZero és a Docker bemutatott egy új nyílt projektet, az OpenPubKey-t, amely az azonos nevű kriptográfiai protokollt fejleszti tetszőleges objektumok digitális aláírására. A technológiát a BastionZero és a Docker közös projektjeként fejlesztették ki azzal a céllal, hogy leegyszerűsítsék a Docker konténerképek digitális aláírását, hogy megakadályozzák azok helyettesítését, és megerősítsék a bejelentett alkotó általi összeállítást. A projektet semleges platformon, a Linux Foundation égisze alatt fejlesztik, ami megszünteti az egyes kereskedelmi társaságoktól való függőséget, és leegyszerűsíti az együttműködést harmadik felek bevonásával. Az OpenPubKey referencia-megvalósítása Go nyelven íródott, és az Apache 2.0 licenc alatt kerül terjesztésre.
Az OpenPubKey képességei nem korlátozódnak a konténerképekre, és a technológia felhasználható bármely erőforrás forrásának megerősítésére, a függőségek helyettesítésének megakadályozására és az adatkészlet-terjesztési csatornák biztonságának javítására. Például a technológia alkalmazható programösszeállítások, egyedi üzenetek és véglegesítések ellenőrzésére. Az aláírás-készítőknek csak egy OpenID-t támogató szolgáltatásban kell fiókkal rendelkezniük, a fogyasztók pedig lehetőséget kapnak a csatolt aláírások ellenőrzésére és a deklarált OpenID azonosítóval való kapcsolatuk megerősítésére.
Az OpenPubKey rendeltetését tekintve hasonlít a Google-nál létrehozott és korábban a Linux Foundationhez átadott Sigstore rendszerre, de különbözik attól, hogy jelentősen leegyszerűsíti a megvalósítást, a használatot és a karbantartást azáltal, hogy megszabadul a hitelességet igazoló nyilvános napló vezetéséért felelős központi szerverkomponensektől. változások (átláthatósági napló), valamint a hitelesítés-szolgáltatók (hitelesítési hatóság) működésének biztosítása.
Ahelyett, hogy saját tanúsító hatóságokat telepítene, az OpenPubKey OpenID hitelesítési technológiát használ, és összekapcsolja a létrehozott aláírásokat a meglévő OpenID Connect szolgáltatókkal. Más szóval, az OpenPubkey lehetővé teszi, hogy titkosítási kulcsokat rendeljen bizonyos felhasználókhoz OpenID Connect szolgáltatók (IdP) használatával a tanúsító hatóságok helyett. A technológia teljes mértékben kompatibilis a meglévő OpenID szolgáltatókkal, mint például a GitHub, az Azure/Microsoft, az Okta, a OneLogin, a Keycloak és a Google, és nem igényel változtatásokat az oldalukon (a szolgáltató által biztosított szabványos ID Token használatos, amely lehetővé teszi a az OpenPubKey-t csak az ügyféloldali OpenID Connect módosításaival valósítsa meg).
Az OpenID szolgáltató által kibocsátott token olyan tanúsítvánnyal alakul át, amely kriptográfiailag köti össze az OpenID Connect azonosítóját a nyilvános kulccsal. A felhasználó ezután a generált kulccsal aláírja az adatokat, és ezek az aláírások ezt követően ellenőrizhetők az OpenID Connect azonosítójával. Az OpenPubKey efemer kulcsokat használ, amelyek élettartama korlátozott – a kulcsok az OpenID bejelentkezés során jönnek létre, és törlődnek, amikor az OpenID-szolgáltatóval folytatott munkamenet véget ér.
Egy példa algoritmus aláírás létrehozására OpenPubKey használatával:
- Jelentkezzen be OpenID szolgáltatóval (Google, GitHub, Microsoft stb.).
- Kérjen azonosító tokent az OpenID szolgáltatótól.
- A szolgáltatói kulcs által aláírt token visszaküldése, és a kérés során továbbított tetszőleges adatot tartalmazó „nonce” mező is (a nyilvános kulcs SHA3 hash-je kerül továbbításra).
- Használja a kapott token felhasználói oldalán tanúsítványként, beleértve a kulcsadatokat.
- Token csatolása egy aláíráshoz, hasonló a tanúsítványhoz.
Az ellenőrzés lényege, hogy ellenőrizzük, hogy a csatolt tokent aláírta-e az OpenID-szolgáltató, valamint hogy a nyilvános kulcs segítségével ellenőrizzük az erőforrás digitális aláírásának helyességét, ami lehetővé teszi annak biztosítását, hogy az erőforrás a tanúsítványban szereplő azonosító használatával legyen aláírva, és ezt az OpenID-szolgáltató aláírása is megerősítse. Például az aláírás létrehozója kaphat egy, a Google OpenID-szolgáltató által aláírt tokent, amely tartalmazza, hogy a token bob@gmail.com-ként van ellenőrizve, és a 0x54A5…FF nyilvános kulcsot használja. Ezután, amikor ugyanazzal a kulccsal aláírt üzenetet kap, a címzett a szolgáltató által aláírt token segítségével ellenőrizheti, hogy a bob@gmail.com kulcs valóban 0x54A5…FF, és az üzenetet valóban bob@gmail.com írta alá.
Az architektúra egyszerűsítése bizonyos kompromisszumok révén érhető el (például a külső OpenID szolgáltatóktól való függés és a hierarchikus kivonatolású változásnapló hiánya), amelyek bizonyos helyzetekben elfogadhatók, más esetekben nem. Az OpenID szolgáltatóktól való függés csökkentése érdekében, akiknek a kompromittálása vagy tevékenysége hiteltelenné teheti a rendszert (például a feltört szolgáltatók fiktív kulcsot adhatnak ki harmadik félnek), javasoljuk egy további, de nem kötelező MFA-Cosigner használatát. (Multi-Factor Authentication Cosigner) link a többtényezős hitelesítéshez (a tokent nemcsak a fő szolgáltatónak kell aláírnia, hanem egy független hitelesítési szolgáltatásnak is, amely megerősíti a felhasználót).
Az OpenPubKey egyik gyenge pontja az is, hogy olyan külső információk jelennek meg, amelyek segítségével hosszú időn keresztül nyomon követhető a tevékenység, függetlenül az átnevezéstől (új tanúsítvány helyett azonosító token újrahasználata). Az OpenID Connect kulcsokhoz való közvetlen kötődés az ellenőrzés során kiküszöböli a szerverrészt, de jelentősen megnehezíti a megvalósítást kliens oldalon, és több mozgásteret hagy például a kliens elleni támadások (támadási felület) elkövetésekor, mivel a feladat a kulcsforgatás az ügyfélre esik. A változásnapló hiánya nem teszi lehetővé az ügyfél számára, hogy nyomon kövesse a lehetséges kulcsszivárgásokat.
Forrás: opennet.ru
