Ce message est rédigé par Hayden Blauzvern et est apparu à l’origine sur Le blog de Sigstore. Sigstore est une nouvelle norme pour la signature, la vérification et la protection des logiciels. C’est un projet de la Fondation Linux.
Développeurs, mainteneurs de packages et entreprises souhaitant adopter Sigstore peuvent déjà signer des artefacts publiés. Les signataires peuvent disposer de procédures existantes pour stocker et utiliser en toute sécurité les clés de signature. Sigstore peut être utilisé pour signer des artefacts avec des clés de signature autogérées et durables existantes. Sigstore offre une expérience utilisateur simple pour la signature, la vérification et la génération de métadonnées de signature structurées pour les artefacts et les signatures de conteneur. Sigstore propose également un journal de transparence géré par la communauté et gratuit pour l’audit de la génération de signatures.
Sigstore a en outre la possibilité d’utiliser des certificats de signature de code avec des clés de signature de courte durée liées aux identités OpenID Connect. Cette approche de signature offre une simplicité en raison de l’absence de gestion des clés ; cependant, cela peut être un changement trop radical pour les entreprises qui disposent d’une infrastructure existante pour la signature. Cet article de blog décrit des stratégies pour faciliter l’adoption de Sigstore tout en utilisant les approches de signature existantes.
Signature avec des clés autogérées à longue durée de vie
Les développeurs qui conservent leurs propres clés de signature mais qui souhaitent migrer vers Sigstore peuvent d’abord passer à l’utilisation cosigner pour générer une signature sur un artefact. Cosign prend en charge l’importation d’une clé PKCS#1 ou PKCS#8 codée RSA, ECDSA ou ED25519 PEM existante avec cosign import-key-pair –key key.pemet peut signer et vérifier avec cosign sign-blob –key cosign.key chemin d’artefact et cosign verify-blob –key cosign.pub chemin de l’artefact.
Avantages
Les développeurs peuvent s’habituer aux outils Sigstore pour signer et vérifier les artefacts.
Les outils Sigstore peuvent être intégrés dans les pipelines CI/CD.
Pour les conteneurs de signature, les métadonnées de signature sont publiées avec l’image OCI dans un registre OCI.
Signature avec des clés autogérées avec auditabilité
Tout en conservant leurs propres clés de signature, les développeurs peuvent augmenter la vérifiabilité des événements de signature en publiant des signatures dans le journal de transparence Sigstore, Rekor. Cela permet aux développeurs de vérifier quand les signatures sont générées pour les artefacts qu’ils gèrent, et également de surveiller quand leur clé de signature est utilisée pour créer une signature.
Les développeurs peuvent télécharger une signature dans le journal de transparence lors de la signature avec COSIGN_EXPERIMENTAL=1 cosign sign-blob –key cosign.key chemin d’artefact. Si les développeurs souhaitent utiliser leur propre infrastructure de signature tout en continuant à publier dans un journal de transparence, les développeurs peuvent utiliser le Rekor CLI ou API. Pour télécharger un artefact et vérifier cryptographiquement son inclusion dans le journal à l’aide de la CLI Rekor :
téléchargement rekor-cli –rekor_server https://rekor.sigstore.dev
-Signature
-Clé publique
–artefact vérification rekor-cli –rekor_server https://rekor.sigstore.dev
-Signature
-Clé publique
–artefact
En plus des certificats et des clés publiques codés PEM, Sigstore prend en charge le téléchargement de nombreux formats de clé différents, y compris PGP, MinisignSSH, PKCS#7 et TUF. Lors du téléchargement à l’aide de la CLI Rekor, spécifiez le –format-pki drapeau. Par exemple, pour importer un artefact signé avec une clé PGP :
gpg –armor -u user@example.com –output signature.asc –detach-sig package.tar.gzgpg –export –armor « user@example.com » > public.keytéléchargement rekor-cli –rekor_server https://rekor.sigstore.dev
–signature signature.asc
–clé publique clé.publique
–pki-format=pgp
–paquet d’artefacts.tar.gz
Avantages
Les développeurs commencent à publier des événements de signature à des fins d’auditabilité.
Les consommateurs d’artefacts peuvent créer une politique de vérification qui exige qu’une signature soit publiée dans un journal de transparence.
Clés autogérées dans un certificat de signature de code basé sur l’identité avec possibilité d’audit
Lors de la demande d’un certificat de signature de code auprès de l’autorité de certification Sigstore Fulcio, Fulcio lie une identité OpenID Connect à une clé, permettant une politique de vérification basée sur l’identité plutôt que sur une clé. Les développeurs peuvent demander un certificat de signature de code à Fulcio avec une clé longue durée autogérée, signer un artefact avec Cosign et télécharger la signature de l’artefact dans le journal de transparence.
Cependant, les consommateurs d’artefacts peuvent toujours s’ouvrir en cas d’échec avec vérification (autoriser l’artefact, tout en enregistrant l’échec) s’ils ne veulent pas dépendre fortement de Sigstore (exiger que les services Sigstore soient utilisés pour la génération de signature). Un développeur peut utiliser sa clé autogérée pour générer une signature. Un vérificateur peut simplement extraire la clé de vérification du certificat sans vérifier la signature du certificat. (Notez que la vérification peut se produire hors ligne, car l’inclusion dans un journal de transparence peut être vérifiée à l’aide d’un Bundle signé persistant de Rekor et les certificats de signature de code peuvent être vérifiés avec le certificat racine de l’autorité de certification. Voir Code de vérification de Cosign pour un exemple de vérification du bundle Rekor.)
Une fois qu’un consommateur dépend fortement de Sigstore, un pipeline CI/CD peut passer à la fermeture en cas d’échec (interdire l’artefact si la vérification échoue).
Avantages
Une politique de vérification plus forte qui applique à la fois la présence de la signature dans un journal de transparence et l’identité du signataire.
Les règles de vérification peuvent être appliquées en cas d’échec.
Signature basée sur l’identité (« sans clé »)
Cette dernière étape est ajoutée par souci d’exhaustivité. La signature est effectuée à l’aide de certificats de signature de code et les signatures doivent être publiées dans un journal de transparence pour vérification. Avec la signature basée sur l’identité, la fermeture en cas d’échec est la seule option, car les services Sigstore doivent être en ligne pour récupérer les certificats de signature de code et ajouter des entrées au journal de transparence. Les développeurs n’auront plus besoin de conserver les clés de signature.
Conclusion
L’outillage et l’infrastructure Sigstore peuvent être utilisés dans leur ensemble ou de manière modulaire. Chaque intégration distincte peut contribuer à améliorer la sécurité de la distribution des artefacts tout en permettant des mises à jour incrémentielles et en vérifiant chaque étape de l’intégration.
