Introduction d'OpenPubKey, un protocole de vérification cryptographique des objets

La Linux Foundation, BastionZero et Docker présentent un nouveau projet ouvert, OpenPubKey, qui développe un protocole cryptographique du même nom pour la certification de signatures numériques d'objets variés. La technologie a été conçue comme un projet commun entre BastionZero et Docker, visant à simplifier la certification des images de conteneurs Docker par des signatures numériques pour éviter leur substitution et confirmer leur construction par le créateur déclaré. Le projet sera développé sur une plateforme neutre sous l'égide de la Linux Foundation, ce qui exclut la dépendance à des entreprises commerciales spécifiques et facilite la collaboration avec des participants externes. L'implémentation de référence d'OpenPubKey est écrite en Go et publiée sous la licence Apache 2.0.

Les capacités d'OpenPubKey ne se limitent pas seulement aux images de conteneurs. La technologie peut être utilisée pour certifier l'origine de tout type de ressource, prévenir la substitution de dépendances et améliorer la sécurité des canaux de distribution de jeux de données. Par exemple, la technologie est applicable à la certification de constructions de logiciels, de messages individuels et de commits. Les créateurs de signatures n'ont besoin que d'un compte sur un service supportant OpenID, tandis que les consommateurs ont la possibilité de vérifier les signatures jointes et de confirmer leur lien avec l'identifiant OpenID déclaré.

En termes de fonction, OpenPubKey ressemble à la solution Sigstore créée par Google et précédemment transférée à la Linux Foundation, mais elle se distingue par une simplification substantielle de l'implémentation, de l'utilisation et de la maintenance, grâce à l'élimination des composants serveurs centralisés chargés de gérer un registre public confirmant l'authenticité des modifications (transparency log) et à la fourniture des services des autorités de certification.

Au lieu de déployer ses propres autorités de certification, OpenPubKey utilise l'authentification basée sur la technologie OpenID et associe les signatures créées à des fournisseurs existants d'OpenID Connect. En d'autres termes, OpenPubKey permet d'associer des clés cryptographiques à des utilisateurs spécifiques en utilisant des fournisseurs d'OpenID Connect (IdP) au lieu d'autorités de certification. La technologie est entièrement compatible avec les fournisseurs existants d'OpenID, tels que GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak et Google, et ne nécessite aucune modification de leur part (le type de ID Token standard fourni par le fournisseur est utilisé, permettant ainsi d'implémenter OpenPubKey uniquement par des modifications du côté du client OpenID Connect).

Le token délivré par le fournisseur OpenID est transformé en certificat, qui lie cryptographiquement l'identifiant dans OpenID Connect à la clé publique. Ensuite, l'utilisateur utilise la clé générée pour signer toutes données, et ces signatures peuvent ensuite être vérifiées pour leur relation avec l'identifiant dans OpenID Connect. OpenPubKey utilise des clés éphémères dont la durée de vie est limitée — les clés sont générées lors de la connexion via OpenID et sont supprimées à la fin de la session avec le fournisseur OpenID.

L'algorithme approximatif de création de signature en utilisant OpenPubKey :

• Connexion via un fournisseur OpenID (Google, GitHub, Microsoft, etc.).
• Demande de token d'identification auprès du fournisseur OpenID.
• Retour du token, signé par la clé du fournisseur et incluant un champ « nonce » avec des données aléatoires transmises lors de la demande (un hachage SHA3 de la clé publique est transmis).
• Utilisation du token reçu côté utilisateur comme certificat, incluant des informations sur la clé.
• Attachement du token à la signature, similaire à un certificat.

La vérification consiste à vérifier si le jeton joint a été signé par le fournisseur OpenID et à confirmer la validité de la signature numérique pour la ressource à l'aide de la clé publique. Cela permet de s'assurer que la ressource a été signée avec l'identifiant présent dans le certificat et que cela est confirmé par la signature du fournisseur OpenID. Par exemple, une entité signante peut obtenir un jeton signé par le fournisseur OpenID Google, contenant des informations que l'identité a été vérifiée comme étant bob@gmail.com et utilise la clé publique 0x54A5…FF. Ensuite, lors de la réception d'un message signé avec la même clé, l'entité peut utiliser le jeton signé par le fournisseur pour vérifier que la clé bob@gmail.com — 0x54A5…FF appartient bien à bob@gmail.com et que le message a effectivement été signé par bob@gmail.com.

La simplification de l'architecture a été réalisée grâce à certains compromis (par exemple, dépendance à des fournisseurs OpenID externes et absence de journal des modifications avec hachage hiérarchique), qui peuvent être acceptables dans certaines situations et inacceptables dans d'autres. Pour réduire la dépendance aux fournisseurs OpenID, dont la compromission ou les actions du personnel peuvent discréditer le système (par exemple, un fournisseur piraté pourrait délivrer une clé fictive à un tiers), il est proposé d'utiliser un maillon supplémentaire, mais non obligatoire, MFA-Cosigner (Multi-Factor Authentication Cosigner) pour une authentification multifactorielle (le jeton doit être signé non seulement par le fournisseur principal, mais également par un service d'authentification indépendant confirmant l'utilisateur).

Parmi les points faibles d'OpenPubKey, on note également la présence d'informations externes pouvant être utilisées pour suivre l'activité pendant une longue période, et ce, indépendamment des renommements (réutilisation d'un jeton d'identification au lieu d'un nouveau certificat). L'association directe aux clés OpenID Connect lors de la vérification exclut la partie serveur, mais complique considérablement la mise en œuvre côté client et laisse plus d'espace de manœuvre pour réaliser des attaques (surface d'attaque) sur le client, par exemple, en raison de la nécessité pour le client d'effectuer la rotation des clés. L'absence de journal des modifications ne permet pas au client de suivre d'éventuelles fuites de clés.

Source : opennet.ru