Claves de firma

IronFlock firma todo lo que instalan los dispositivos y los appliances. Cada dispositivo y cada appliance comprueba la firma con claves que ya tiene, antes de ejecutar o usar lo que ha descargado. Esta página enumera esas claves, lo que firma cada una y cómo se sustituye una clave (rotación) sin que ningún dispositivo ni appliance deje de poder comprobar su próxima actualización.

Las claves

Las dos claves OpenPGP se pueden descargar para comprobarlas a mano: la clave del appliance desde https://instance-registry.ironflock.com/dl/appliance/appliance-release.asc (consulta Verificar el instalador antes de la primera instalación) y la clave de arranque desde https://instance-registry.ironflock.com/dl/device-init/ironflock-bootstrap.asc (consulta Opcional: verifica primero el instalador). Compara la huella que muestra gpg con la de esta página. Las claves del agente de dispositivo están integradas en el agente; no hay nada que comprobar a mano.

En Windows, el agente de dispositivo comprueba cada actualización y cada frpc.exe que descarga con la raíz de firma de código que lleva integrada: el archivo debe llevar una firma válida de un certificado de firmante emitido por esta raíz. A partir de la versión 1.5.6, un archivo que no supera la comprobación se elimina y no se ejecuta; las versiones 1.5.4 y 1.5.5 solo registraban el fallo. El certificado de firmante se comprueba en el momento de la comprobación, así que un dispositivo Windows cuyo reloj está fuera del periodo de validez del certificado no se actualiza hasta que su reloj sea correcto. En cada arranque, el agente también comprueba su propio ejecutable y escribe codesign: self-check passed o codesign: self-check FAILED en su registro, C:\ProgramData\IronFlock\DeviceAgent\device-agent.log; un dispositivo que registra FAILED rechaza las actualizaciones firmadas de la misma forma que el agente que ejecuta.

El instalador del agente también añade la raíz de firma de código a los certificados raíz de confianza del equipo. La comprobación del agente no la necesita ahí, así que un dispositivo instalado antes de que el instalador hiciera esto comprueba sus actualizaciones de la misma manera. Para comprobar que es la raíz de esta página, ejecuta Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like '*IronFlock Code Signing Root*' | Format-List Subject, Thumbprint, NotAfter en PowerShell; la huella digital (Thumbprint) debe ser 6083E7E2446B8C95A6F6B2E3CFE354AE02859196. Con la raíz presente, Get-AuthenticodeSignature "$env:ProgramData\IronFlock\DeviceAgent\device-agent.exe" | Select-Object Status, @{ n = 'Serial'; e = { $_.SignerCertificate.SerialNumber } } muestra Valid; Windows escribe el número de serie con un 00 delante, como 00D137272B35F0ED5211219674E8B052B4. Los agentes de dispositivo anteriores a la versión 1.5.4, y frpc.exe hasta la versión 0.71.1 de frp, llevan el certificado anterior del firmante de Windows, número de serie 481360741E254378C38A5236940BFFA44CFDD809, emitido por la misma raíz. Con él ya no se firma nada nuevo; el agente acepta sus firmas hasta que el certificado caduque en octubre de 2028.

Cada imagen de servicio de la plataforma IronFlock publicada a partir del 6 de noviembre de 2026 lleva su procedencia de compilación como atestaciones firmadas, una por cada plataforma de la imagen, en el formato SLSA v1 provenance: el repositorio de origen, el commit, la compilación y las imágenes base a partir de las que se construyó. Las atestaciones se guardan junto con la imagen en el registro y no se anotan en ningún registro público de transparencia. Para comprobar una imagen que puedes descargar, guarda la clave pública de abajo como image-provenance.pub, compara su huella con la de la tabla (primer comando) y verifica la imagen por su digest con cosign 3 o posterior (segundo comando):

-----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 solo le indica a cosign que no busque una entrada en un registro de transparencia; la firma se sigue comprobando con la clave. Cada atestación indica su plataforma en predicate.buildDefinition.internalParameters.targetPlatform. Una imagen publicada antes no lleva procedencia firmada, así que una versión de IronFlock puede contener imágenes con y sin ella hasta que cada uno de sus servicios se haya vuelto a publicar.

La procedencia cumple SLSA Build Level 3. Cada imagen se compila en una máquina nueva de un servicio de compilación alojado, separada de cualquier otra compilación y sin una caché de compilación compartida con otras compilaciones. La procedencia se firma en un paso aparte, en otra máquina, que no ejecuta nada del código que se compila y comprueba el repositorio de origen, el commit y la compilación que nombra la procedencia; solo este paso puede usar la clave. Una imagen también puede contener datos que preparó un paso anterior de la misma publicación, por ejemplo un índice de búsqueda; la procedencia nombra esa entrada, no su contenido. Algunas imágenes publicadas el 5 de noviembre de 2026 ya llevan procedencia firmada; cumple el nivel 2, porque la clave aún no estaba limitada al paso de firma.

Cómo se guardan las claves

• Las claves de esta página no se pueden exportar, salvo la raíz de firma de código. Sus claves privadas se guardan en la gestión de claves de IronFlock, y la firma se realiza allí. La raíz de firma de código no firma software, solo el certificado del firmante de Windows, y solo se usa cuando se sustituye ese certificado.
• Las versiones las firma su canalización de publicación. La clave con la que se firman las versiones de un producto solo puede usarla la publicación automatizada de ese producto, una vez superadas sus comprobaciones y pruebas.
• El agente de dispositivo confía en dos claves independientes. Las versiones nuevas se firman con la primera. La segunda firmó las versiones anteriores y sigue firmando, a mano, las actualizaciones para agentes antiguos y versiones antiguas de ironflock-init, que solo confían en esta clave. Además, se reserva para el caso de que la primera ya no pueda usarse; entonces las actualizaciones se firman con ella, de modo que los dispositivos siguen actualizándose sin ningún ajuste que omita la comprobación.

Rotación de una clave

Una clave se sustituye cuando llega al final de su vida útil prevista o, de inmediato, cuando se sospecha que está comprometida. Esta sección trata de las claves de firma anteriores; los secretos internos del propio appliance se sustituyen con ironflock-update --rotate, consulta Secretos en el host. Una rotación siempre se realiza en tres pasos, para que cada dispositivo y cada appliance pueda comprobar cada actualización a lo largo de todo el proceso:

1. Se añade la nueva clave. Una versión añade la nueva clave a las claves en las que confía un dispositivo o un appliance. Esa versión sigue firmada con la clave actual, así que todo lo que se actualiza a ella la acepta.
2. La firma pasa a la nueva clave. Cuando los dispositivos y appliances en campo ejecutan una versión que confía en ambas claves, IronFlock firma con la nueva clave. Durante este periodo, la clave antigua sigue siendo de confianza.
3. Se retira la clave antigua. Una versión posterior elimina la clave antigua. A partir de entonces, una firma con la clave antigua se rechaza, y la clave aparece en Claves retiradas.

Lo que esto significa para cada clave:

• Clave de release del appliance. Un appliance confía en las claves con las que se escribió su ironflock-update, así que el appliance tiene que instalar la versión del paso 1 antes de poder comprobar las actualizaciones firmadas en el paso 2. Un appliance que no se actualizó en ningún momento del periodo de transición detiene su actualización antes de que cambie nada; ejecuta el instalador una vez a mano, comprobado con la nueva clave, como se describe en Verificar el instalador antes de la primera instalación.
• Claves de actualización del agente de dispositivo. Un dispositivo confía en las claves integradas en el agente que ejecuta. Un dispositivo que estuvo sin conexión durante todo el periodo de transición no puede comprobar las actualizaciones firmadas con la nueva clave; reinstala su agente con el instalador de dispositivos, que confía en la nueva clave.
• Clave de arranque (bootstrap). install.sh se descarga de nuevo en cada instalación y lleva consigo la clave con la que hace sus comprobaciones, así que una nueva clave entra en vigor con la siguiente versión del instalador, sin periodo de transición. Solo cambia la comprobación a mano: compara con la huella de esta página.
• Firma de código de Windows. Un dispositivo Windows confía en la raíz de firma de código, no en el firmante. Un nuevo certificado de firmante emitido por la misma raíz entra en vigor con la siguiente versión, sin periodo de transición, y no hay que hacer nada en el dispositivo. Como el agente comprueba el certificado de firmante en el momento de la comprobación, se rechaza un archivo firmado con un certificado que ya ha caducado; por eso, un certificado de firmante se sustituye mucho antes de que caduque. La raíz en sí se sustituye en los tres pasos anteriores, mucho antes de que caduque en julio de 2036; un dispositivo Windows que estuvo sin conexión durante todo el periodo de transición necesita que se reinstale su agente. Los certificados raíz de confianza del equipo conservan la raíz que añadió el instalador, así que, tras una rotación de la raíz, la comprobación de PowerShell de arriba puede mostrar solo la raíz anterior; el agente comprueba con las raíces integradas en él.
• Clave de procedencia de imágenes. Ningún dispositivo ni appliance comprueba esta clave, así que una nueva clave entra en vigor con la siguiente publicación de imagen, sin periodo de transición. Una imagen conserva las atestaciones con las que se publicó: compruébala con la clave que estaba en uso cuando se publicó, que aparece en esta página o en Claves retiradas.

Durante un periodo de transición, esta página muestra ambas claves con sus huellas, y las notas de lanzamiento anuncian cada paso. No hay que hacer nada en un appliance o un dispositivo que se mantiene actualizado.

Si una clave está comprometida, IronFlock deja de firmar con ella de inmediato, la rota como se describe arriba en un plazo corto y publica un aviso de seguridad.

Claves retiradas

Ninguna por ahora.