Clés de signature

IronFlock signe tout ce que les appareils et les appliances installent. Chaque appareil et chaque appliance vérifie la signature avec des clés qu’il détient déjà, avant d’exécuter ou d’utiliser ce qu’il a téléchargé. Cette page présente ces clés, ce que chacune signe, et la manière dont une clé est remplacée (rotation) sans qu’un appareil ou une appliance ne se retrouve dans l’impossibilité de vérifier sa prochaine mise à jour.

Les clés

Les deux clés OpenPGP peuvent être téléchargées pour une vérification manuelle : la clé de l’appliance depuis https://instance-registry.ironflock.com/dl/appliance/appliance-release.asc (voir Vérifier l’installateur avant la première installation), la clé d’amorçage depuis https://instance-registry.ironflock.com/dl/device-init/ironflock-bootstrap.asc (voir Facultatif : vérifier d’abord l’installateur). Comparez l’empreinte signalée par gpg avec celle indiquée sur cette page. Les clés de l’agent d’appareil sont intégrées à l’agent ; il n’y a rien à vérifier manuellement.

Sous Windows, l’agent d’appareil vérifie chaque mise à jour et chaque frpc.exe qu’il télécharge avec la racine de signature de code intégrée à l’agent : le fichier doit porter une signature valide d’un certificat de signataire émis par cette racine. À partir de la version 1.5.6, un fichier qui échoue à la vérification est supprimé et n’est pas exécuté ; les versions 1.5.4 et 1.5.5 se contentaient de consigner l’échec. Le certificat du signataire est contrôlé au moment de la vérification, de sorte qu’un appareil Windows dont l’horloge est en dehors de la période de validité du certificat ne se met pas à jour tant que son horloge n’est pas correcte. À chaque démarrage, l’agent vérifie également son propre exécutable et écrit codesign: self-check passed ou codesign: self-check FAILED dans son journal, C:\ProgramData\IronFlock\DeviceAgent\device-agent.log ; un appareil qui consigne FAILED refuse les mises à jour signées comme l’agent qu’il exécute.

L’installateur de l’agent ajoute en outre la racine de signature de code aux certificats racines de confiance de l’ordinateur. La vérification de l’agent n’en a pas besoin à cet endroit ; un appareil installé avant que l’installateur ne le fasse vérifie donc ses mises à jour de la même manière. Pour vérifier qu’il s’agit bien de la racine indiquée sur cette page, exécutez Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like '*IronFlock Code Signing Root*' | Format-List Subject, Thumbprint, NotAfter dans PowerShell ; l’empreinte numérique (Thumbprint) doit être 6083E7E2446B8C95A6F6B2E3CFE354AE02859196. Lorsque la racine s’y trouve, Get-AuthenticodeSignature "$env:ProgramData\IronFlock\DeviceAgent\device-agent.exe" | Select-Object Status, @{ n = 'Serial'; e = { $_.SignerCertificate.SerialNumber } } affiche Valid ; Windows écrit le numéro de série précédé de 00, soit 00D137272B35F0ED5211219674E8B052B4. Les agents d’appareil antérieurs à la version 1.5.4, ainsi que frpc.exe jusqu’à la version 0.71.1 de frp, portent le certificat précédent du signataire Windows, numéro de série 481360741E254378C38A5236940BFFA44CFDD809, émis par la même racine. Plus rien de nouveau n’est signé avec lui ; l’agent accepte ses signatures jusqu’à l’expiration du certificat en octobre 2028.

Chaque image de service de la plateforme IronFlock publiée à partir du 6 novembre 2026 porte sa provenance de build sous forme d’attestations signées, une pour chaque plateforme de l’image, au format SLSA v1 provenance : le dépôt source, le commit, le build et les images de base à partir desquelles elle a été construite. Les attestations sont stockées avec l’image dans le registre et ne sont inscrites dans aucun journal de transparence public. Pour vérifier une image que vous pouvez récupérer, enregistrez la clé publique ci-dessous sous image-provenance.pub, comparez son empreinte avec celle du tableau (première commande) et vérifiez l’image par son digest avec cosign 3 ou ultérieur (deuxième commande) :

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEjyfZEmjD3ErGVqBO5fsNl+aPy+oO
vDGv410tK7HUUZgD+EMbmXYq/qhXuJ0QhjYi/zDEozRRhLT3AnsgIOabrQ==
-----END PUBLIC KEY-----

openssl pkey -pubin -in image-provenance.pub -outform DER | openssl dgst -sha256
cosign verify-attestation --key image-provenance.pub --type slsaprovenance1 --insecure-ignore-tlog <image>@sha256:<digest>

--insecure-ignore-tlog indique seulement à cosign de ne pas chercher d’entrée dans un journal de transparence ; la signature est tout de même vérifiée avec la clé. Chaque attestation indique sa plateforme dans predicate.buildDefinition.internalParameters.targetPlatform. Une image publiée auparavant ne porte pas de provenance signée, de sorte qu’une version d’IronFlock peut contenir des images avec et sans elle jusqu’à ce que chacun de ses services ait été publié à nouveau.

La provenance satisfait à SLSA Build Level 3. Chaque image est construite sur une machine neuve d’un service de build hébergé, à l’écart de tout autre build et sans cache de build partagé avec d’autres builds. La provenance est signée dans une étape distincte, sur une autre machine, qui n’exécute rien du code construit et vérifie le dépôt source, le commit et le build que nomme la provenance ; seule cette étape peut utiliser la clé. Une image peut aussi contenir des données qu’une étape antérieure de la même publication a préparées, par exemple un index de recherche ; la provenance nomme une telle entrée, pas son contenu. Certaines images publiées le 5 novembre 2026 portent déjà une provenance signée ; elle satisfait au niveau 2, car la clé n’était pas encore réservée à l’étape de signature.

Comment les clés sont conservées

• Les clés de cette page ne peuvent pas être exportées, sauf la racine de signature de code. Leurs clés privées sont conservées dans la gestion des clés d’IronFlock, et c’est là que la signature a lieu. La racine de signature de code ne signe aucun logiciel, seulement le certificat du signataire Windows, et n’est utilisée que lorsque ce certificat est remplacé.
• Les versions sont signées par leur pipeline de publication. La clé avec laquelle les versions d’un produit sont signées ne peut être utilisée que par la publication automatisée de ce produit, une fois ses vérifications et ses tests réussis.
• L’agent d’appareil fait confiance à deux clés indépendantes. Les nouvelles versions sont signées avec la première. La seconde a signé les versions précédentes et signe encore, manuellement, les mises à jour destinées aux anciens agents et aux anciennes versions d’ironflock-init, qui ne font confiance qu’à cette clé. Elle est en outre conservée pour le cas où la première ne pourrait plus être utilisée ; les mises à jour sont alors signées avec elle, de sorte que les appareils continuent de se mettre à jour sans aucun paramètre qui contournerait la vérification.

Rotation d’une clé

Une clé est remplacée lorsqu’elle atteint la fin de sa durée de vie prévue, ou immédiatement lorsqu’on la soupçonne d’être compromise. Cette section concerne les clés de signature ci-dessus ; les secrets internes propres à l’appliance sont remplacés avec ironflock-update --rotate, voir Secrets sur l’hôte. Une rotation se déroule toujours en trois étapes, afin que chaque appareil et chaque appliance puisse vérifier chaque mise à jour tout au long du processus :

1. La nouvelle clé est ajoutée. Une version ajoute la nouvelle clé aux clés auxquelles un appareil ou une appliance fait confiance. Cette version est encore signée avec la clé actuelle, de sorte que tout ce qui se met à jour vers elle l’accepte.
2. La signature passe à la nouvelle clé. Dès que les appareils et les appliances sur le terrain exécutent une version qui fait confiance aux deux clés, IronFlock signe avec la nouvelle clé. L’ancienne clé reste approuvée pendant cette période.
3. L’ancienne clé est retirée. Une version ultérieure supprime l’ancienne clé. Dès lors, une signature faite avec l’ancienne clé est refusée, et la clé est listée sous Clés retirées.

Ce que cela signifie pour chaque clé :

• Clé de publication de l’appliance. Une appliance fait confiance aux clés avec lesquelles son ironflock-update a été écrit ; l’appliance doit donc installer la version de l’étape 1 avant de pouvoir vérifier les mises à jour signées à l’étape 2. Une appliance qui n’a pas été mise à jour pendant toute la période de chevauchement arrête sa mise à jour avant que quoi que ce soit ne change ; exécutez une fois l’installateur manuellement, en le vérifiant avec la nouvelle clé, comme décrit dans Vérifier l’installateur avant la première installation.
• Clés de mise à jour de l’agent d’appareil. Un appareil fait confiance aux clés intégrées à l’agent qu’il exécute. Un appareil resté hors ligne pendant toute la période de chevauchement ne peut pas vérifier les mises à jour signées avec la nouvelle clé ; réinstallez son agent avec l’installateur d’appareil, qui fait confiance à la nouvelle clé.
• Clé d’amorçage. install.sh est téléchargé à nouveau pour chaque installation et embarque la clé avec laquelle il vérifie, de sorte qu’une nouvelle clé prend effet avec la prochaine version de l’installateur, sans période de chevauchement. Seule la vérification manuelle change : comparez avec l’empreinte indiquée sur cette page.
• Signature de code Windows. Un appareil Windows fait confiance à la racine de signature de code, et non au signataire. Un nouveau certificat de signataire émis par la même racine prend effet avec la version suivante, sans période de chevauchement, et il n’y a rien à faire sur l’appareil. Comme l’agent contrôle le certificat du signataire au moment de la vérification, un fichier signé avec un certificat expiré est refusé ; un certificat de signataire est donc remplacé bien avant son expiration. La racine elle-même est remplacée selon les trois étapes ci-dessus, bien avant son expiration en juillet 2036 ; un appareil Windows resté hors ligne pendant toute la période de chevauchement nécessite une réinstallation de son agent. Les certificats racines de confiance de l’ordinateur conservent la racine que l’installateur a ajoutée : après une rotation de la racine, la vérification PowerShell ci-dessus peut donc n’afficher que l’ancienne racine. L’agent, lui, vérifie avec les racines intégrées à l’agent.
• Clé de provenance des images. Aucun appareil ni aucune appliance ne vérifie cette clé, de sorte qu’une nouvelle clé prend effet avec la prochaine publication d’image, sans période de chevauchement. Une image conserve les attestations avec lesquelles elle a été publiée : vérifiez-la avec la clé en usage lors de sa publication, listée sur cette page ou sous Clés retirées.

Pendant une période de chevauchement, cette page liste les deux clés avec leurs empreintes, et les notes de publication annoncent chaque étape. Il n’y a rien à faire sur une appliance ou un appareil maintenu à jour.

Si une clé est compromise, IronFlock cesse immédiatement de signer avec elle, effectue sa rotation comme décrit ci-dessus dans un délai court et publie un avis de sécurité.

Clés retirées

Aucune pour l’instant.