De Linux Foundation, BastionZero en Docker hebben een nieuw open project OpenPubKey geĆÆntroduceerd, dat het gelijknamige cryptografische protocol ontwikkelt voor het bevestigen van digitale handtekeningen van willekeurige objecten. De technologie is ontwikkeld als een gezamenlijk project van BastionZero en Docker, met als doel het vereenvoudigen van het ondertekenen van Docker-containerimages met digitale handtekeningen om vervalsing te voorkomen en de bouw door de opgegeven maker te bevestigen. Het project zal worden ontwikkeld op een neutraal platform onder de bescherming van de Linux Foundation, waardoor afhankelijkheid van specifieke commerciĆ«le bedrijven wordt geĆ«limineerd en samenwerking met externe deelnemers wordt vergemakkelijkt. De referentie-implementatie van OpenPubKey is geschreven in de programmeertaal Go en wordt verspreid onder de Apache 2.0-licentie.
De mogelijkheden van OpenPubKey beperken zich niet alleen tot containerimages; de technologie kan ook worden toegepast voor het bevestigen van de bron van elke resource, het voorkomen van vervalsing van afhankelijkheden en het verhogen van de veiligheid van distributiekanalen voor datasets. Bijvoorbeeld, de technologie is toepasbaar voor het ondertekenen van software-builds, afzonderlijke berichten en commits. Handtekeningmakers hoeven alleen een account te hebben bij een dienst die OpenID ondersteunt, terwijl consumenten de mogelijkheid krijgen om bijgevoegde handtekeningen te verifiƫren en hun verbinding met de opgegeven OpenID-identificatie te bevestigen.
Qua functionaliteit lijkt OpenPubKey op het systeem Sigstore dat door Google is ontwikkeld en eerder is overgedragen aan de Linux Foundation, maar het verschilt van dat systeem door de aanzienlijke vereenvoudiging van implementatie, gebruik en onderhoud, doordat het geen gecentraliseerde servercomponenten bevat die verantwoordelijk zijn voor het bijhouden van een openbaar logboek, dat de authenticiteit van wijzigingen bevestigt (transparency log), en het functioneren van certificeringsinstellingen (Certificate Authority) verzekert.
In plaats van het opzetten van eigen certificeringsinstanties, maakt OpenPubKey gebruik van authenticatie met behulp van technologieƫn zoals OpenID en koppelt het de gegenereerde handtekeningen aan bestaande OpenID Connect-providers. Met andere woorden, OpenPubKey maakt het mogelijk om cryptografische sleutels aan specifieke gebruikers te koppelen, met behulp van OpenID Connect-providers (IdP) in plaats van certificeringsinstanties. De technologie is volledig compatibel met bestaande OpenID-providers zoals GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak en Google, en vereist geen wijzigingen aan hun kant (de niet-veranderde ID Token die door de provider wordt verstrekt, maakt het mogelijk om OpenPubKey uitsluitend via wijzigingen aan de kant van de OpenID Connect-cliƫnt te implementeren).
De door de OpenID-provider uitgegeven token wordt omgevormd tot een certificaat, dat de identificator in OpenID Connect cryptografisch koppelt aan de openbare sleutel. Vervolgens gebruikt de gebruiker de gegenereerde sleutel om gegevens te ondertekenen en kunnen deze handtekeningen later worden gecontroleerd op hun verbinding met de identificator in OpenID Connect. In OpenPubKey worden ephemerische sleutels gebruikt, waarvan de levensduur beperkt is ā sleutels worden gegenereerd tijdens het inloggen via OpenID en worden verwijderd zodra de sessie met de OpenID-provider is beĆ«indigd.
Een voorbeeldalgoritme voor het maken van een handtekening met OpenPubKey:
- Inloggen met behulp van een OpenID-provider (Google, GitHub, Microsoft, enz.).
- Aanvraag van een identificatietoken bij de OpenID-provider.
- Terugkeer van een token, ondertekend met de sleutel van de provider en inclusief het veld "nonce" met willekeurige gegevens die tijdens de aanvraag zijn verzonden (de SHA3-hash van de openbare sleutel wordt verzonden).
- Gebruik aan de gebruikerszijde van het verkregen token als een certificaat, inclusief gegevens over de sleutel.
- Het aan het handtekening koppelen van het token, vergelijkbaar met een certificaat.
De verificatie houdt in dat gecontroleerd wordt of de bijgevoegde token is ondertekend door de OpenID-provider en of de digitale handtekening van de bron correct is met de openbare sleutel. Dit stelt ons in staat om te bevestigen dat de bron is ondertekend met de identifier uit het certificaat en dat dit is bevestigd door de handtekening van de OpenID-provider. Bijvoorbeeld, degene die de handtekening maakt, kan een door de OpenID-provider Google ondertekende token ontvangen met de informatie dat hij is geverifieerd als bob@gmail.com en de openbare sleutel 0x54A5ā¦FF gebruikt. Vervolgens kan bij het ontvangen van een bericht, ondertekend met dezelfde sleutel, de ondertekende token van de provider worden gebruikt om te verifiĆ«ren dat de sleutel bob@gmail.com ā 0x54A5ā¦FF is en het bericht daadwerkelijk is ondertekend door bob@gmail.com.
De vereenvoudiging van de architectuur is bereikt door bepaalde compromissen (bijvoorbeeld afhankelijkheid van externe OpenID-providers en het ontbreken van een log van wijzigingen met hiƫrarchische hashing), die in sommige situaties acceptabel zijn en in andere niet. Om de afhankelijkheid van OpenID-providers te verminderen, wiens compromittering of acties van personeel de systeemcredibiliteit kunnen ondermijnen (bijvoorbeeld een gehackte provider kan een valse sleutel aan een derde partij geven), wordt voorgesteld om een extra, maar niet verplicht, MFA-Cosigner (Multi-Factor Authentication Cosigner) te gebruiken voor multi-factor authenticatie (de token moet niet alleen door de primaire provider zijn ondertekend, maar ook door een onafhankelijke authenticatieservice die de gebruiker bevestigt).
Onder de zwakke punten van OpenPubKey is er ook de beschikbaarheid van externe informatie die kan worden gebruikt om activiteiten gedurende lange tijd te volgen, ongeacht hernoemingen (herhaaldelijk gebruik van de identificerende token in plaats van een nieuw certificaat). De directe binding aan OpenID Connect-sleutels bij verificatie sluit de serverzijde uit, maar maakt de implementatie aan de klantzijde aanzienlijk complexer en laat meer ruimte voor manoeuvres bij het uitvoeren van aanvallen (attack surface) op de klant, bijvoorbeeld omdat de verantwoordelijkheid voor sleutelrotatie bij de klant ligt. Het gebrek aan een log van wijzigingen maakt het voor de klant onmogelijk om mogelijke sleutellekken te volgen.
Bron: opennet.ru
