Chaves de Assinatura

A IronFlock assina tudo o que os dispositivos e os appliances instalam. Cada dispositivo e cada appliance verifica a assinatura com chaves que já possui, antes de executar ou usar o que baixou. Esta página lista essas chaves, o que cada uma assina e como uma chave é substituída (rotacionada) sem deixar nenhum dispositivo ou appliance incapaz de verificar a sua próxima atualização.

As Chaves

As duas chaves OpenPGP podem ser baixadas para uma verificação manual: a chave do appliance em https://instance-registry.ironflock.com/dl/appliance/appliance-release.asc (veja Verificar o instalador antes da primeira instalação) e a chave bootstrap em https://instance-registry.ironflock.com/dl/device-init/ironflock-bootstrap.asc (veja Opcional: verifique o instalador antes). Compare a impressão digital informada pelo gpg com a desta página. As chaves do agente de dispositivo vêm embutidas no agente; não há nada para verificar manualmente.

No Windows, o agente de dispositivo verifica cada atualização e cada frpc.exe que baixa com a raiz de assinatura de código embutida nele: o arquivo precisa ter uma assinatura válida de um certificado de assinante emitido por essa raiz. A partir da versão 1.5.6, um arquivo que não passa na verificação é excluído e não é executado; as versões 1.5.4 e 1.5.5 apenas registravam a falha. O certificado do assinante é verificado no momento da verificação, então um dispositivo Windows cujo relógio está fora do período de validade do certificado não se atualiza até que o relógio esteja certo. A cada inicialização, o agente também verifica o seu próprio executável e escreve codesign: self-check passed ou codesign: self-check FAILED no seu log, C:\ProgramData\IronFlock\DeviceAgent\device-agent.log; um dispositivo que registra FAILED recusa as atualizações assinadas da mesma forma que o agente que ele roda.

O instalador do agente também adiciona a raiz de assinatura de código aos certificados raiz confiáveis do computador. A verificação do agente não precisa dela ali, então um dispositivo instalado antes de o instalador passar a fazer isso verifica as suas atualizações da mesma forma. Para verificar que é a raiz desta página, execute Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like '*IronFlock Code Signing Root*' | Format-List Subject, Thumbprint, NotAfter no PowerShell; a impressão digital (Thumbprint) deve ser 6083E7E2446B8C95A6F6B2E3CFE354AE02859196. Com a raiz ali, Get-AuthenticodeSignature "$env:ProgramData\IronFlock\DeviceAgent\device-agent.exe" | Select-Object Status, @{ n = 'Serial'; e = { $_.SignerCertificate.SerialNumber } } mostra Valid; o Windows escreve o número de série com 00 no início, como 00D137272B35F0ED5211219674E8B052B4. Os agentes de dispositivo anteriores à versão 1.5.4, e o frpc.exe até a versão 0.71.1 do frp, trazem o certificado anterior do assinante do Windows, número de série 481360741E254378C38A5236940BFFA44CFDD809, emitido pela mesma raiz. Nada de novo é assinado com ele; o agente aceita as suas assinaturas até o certificado expirar em outubro de 2028.

Toda imagem de serviço da plataforma IronFlock lançada a partir de 6 de novembro de 2026 traz a sua proveniência de build como atestações assinadas, uma para cada plataforma da imagem, no formato SLSA v1 provenance: o repositório de origem, o commit, o build e as imagens base a partir das quais foi construída. As atestações ficam guardadas junto com a imagem no registro e não são gravadas em nenhum log público de transparência. Para verificar uma imagem que você pode baixar, salve a chave pública abaixo como image-provenance.pub, compare a sua impressão digital com a da tabela (primeiro comando) e verifique a imagem pelo seu digest com o cosign 3 ou 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 apenas diz ao cosign para não procurar uma entrada em um log de transparência; a assinatura continua sendo verificada com a chave. Cada atestação indica a sua plataforma em predicate.buildDefinition.internalParameters.targetPlatform. Uma imagem lançada antes não traz proveniência assinada, então uma versão do IronFlock pode conter imagens com e sem ela até que cada um dos seus serviços tenha sido lançado novamente.

A proveniência atende ao SLSA Build Level 3. Cada imagem é construída em uma máquina nova de um serviço de build hospedado, separada de qualquer outro build e sem um cache de build compartilhado com outros builds. A proveniência é assinada em uma etapa separada, em outra máquina, que não executa nada do código que está sendo construído e verifica o repositório de origem, o commit e o build que a proveniência indica; só essa etapa pode usar a chave. Uma imagem também pode conter dados que uma etapa anterior do mesmo lançamento preparou, por exemplo um índice de busca; a proveniência indica essa entrada, não o seu conteúdo. Algumas imagens lançadas em 5 de novembro de 2026 já trazem proveniência assinada; ela atende ao nível 2, porque a chave ainda não estava limitada à etapa de assinatura.

Como as Chaves São Guardadas

• As chaves desta página não podem ser exportadas, exceto a raiz de assinatura de código. Suas chaves privadas ficam no gerenciamento de chaves da IronFlock, e a assinatura acontece lá. A raiz de assinatura de código não assina software, apenas o certificado do assinante do Windows, e só é usada quando esse certificado é substituído.
• As releases são assinadas pelo seu pipeline de release. A chave com que as releases de um produto são assinadas só pode ser usada pelo processo de release automatizado desse produto, depois que as verificações e os testes dele forem aprovados.
• O agente de dispositivo confia em duas chaves independentes. As novas releases são assinadas com a primeira. A segunda assinou as releases anteriores e ainda assina, manualmente, as atualizações para agentes mais antigos e versões mais antigas do ironflock-init, que confiam apenas nessa chave. Além disso, fica reservada para o caso de a primeira não poder mais ser usada; então as atualizações são assinadas com ela, de modo que os dispositivos continuam se atualizando sem nenhuma configuração que pule a verificação.

Rotação de uma Chave

Uma chave é substituída quando chega ao fim da sua vida útil planejada ou, imediatamente, quando há suspeita de que foi comprometida. Esta seção trata das chaves de assinatura acima; os segredos internos do próprio appliance são substituídos com ironflock-update --rotate, veja Segredos no host. Uma rotação sempre ocorre em três etapas, para que cada dispositivo e cada appliance consiga verificar cada atualização ao longo de todo o processo:

1. A nova chave é adicionada. Uma release adiciona a nova chave às chaves em que um dispositivo ou um appliance confia. Essa release ainda é assinada com a chave atual, então tudo o que é atualizado para ela a aceita.
2. A assinatura passa para a nova chave. Assim que os dispositivos e appliances em campo rodam uma release que confia nas duas chaves, a IronFlock assina com a nova chave. A chave antiga continua confiável durante esse período.
3. A chave antiga é retirada. Uma release posterior remove a chave antiga. A partir daí, uma assinatura com a chave antiga é recusada, e a chave passa a constar em Chaves Retiradas.

O que isso significa para cada chave:

• Chave de release do appliance. Um appliance confia nas chaves com que o seu ironflock-update foi escrito, então o appliance precisa instalar a release da etapa 1 antes de conseguir verificar as atualizações assinadas na etapa 2. Um appliance que não foi atualizado em nenhum momento do período de transição interrompe a atualização antes que algo mude; execute o instalador uma vez manualmente, verificado com a nova chave, conforme descrito em Verificar o instalador antes da primeira instalação.
• Chaves de atualização do agente de dispositivo. Um dispositivo confia nas chaves embutidas no agente que ele roda. Um dispositivo que ficou offline durante todo o período de transição não consegue verificar as atualizações assinadas com a nova chave; reinstale o agente dele com o instalador de dispositivos, que confia na nova chave.
• Chave bootstrap. O install.sh é baixado novamente a cada instalação e traz consigo a chave com que faz as suas verificações, então uma nova chave entra em vigor com a próxima release do instalador, sem período de transição. Só a verificação manual muda: compare com a impressão digital desta página.
• Assinatura de código do Windows. Um dispositivo Windows confia na raiz de assinatura de código, não no assinante. Um novo certificado de assinante emitido pela mesma raiz entra em vigor com a próxima release, sem período de transição, e não é preciso fazer nada no dispositivo. Como o agente verifica o certificado do assinante no momento da verificação, um arquivo assinado com um certificado que já expirou é recusado; por isso, um certificado de assinante é substituído bem antes de expirar. A própria raiz é substituída nas três etapas acima, bem antes de expirar em julho de 2036; um dispositivo Windows que ficou offline durante todo o período de transição precisa ter o agente reinstalado. Os certificados raiz confiáveis do computador mantêm a raiz que o instalador adicionou, então, depois de uma rotação da raiz, a verificação no PowerShell acima pode mostrar apenas a raiz anterior; o agente verifica com as raízes embutidas nele.
• Chave de proveniência de imagens. Nenhum dispositivo nem appliance verifica esta chave, então uma nova chave entra em vigor com a próxima release de imagem, sem período de transição. Uma imagem mantém as atestações com que foi lançada: verifique-a com a chave em uso quando ela foi lançada, que consta nesta página ou em Chaves Retiradas.

Durante um período de transição, esta página lista as duas chaves com as suas impressões digitais, e as notas da release anunciam cada etapa. Nada precisa ser feito em um appliance ou dispositivo que é mantido atualizado.

Se uma chave for comprometida, a IronFlock para de assinar com ela imediatamente, faz a rotação como descrito acima em um prazo curto e publica um aviso de segurança.

Chaves Retiradas

Nenhuma até o momento.