서명 키

IronFlock은 디바이스와 어플라이언스가 설치하는 모든 것에 서명합니다. 각 디바이스와 각 어플라이언스는 다운로드한 것을 실행하거나 사용하기 전에, 이미 보유한 키로 그 서명을 확인합니다. 이 페이지는 그 키들과 각 키가 서명하는 대상, 그리고 디바이스나 어플라이언스가 다음 업데이트를 확인할 수 없게 되는 일 없이 키를 교체(로테이션)하는 방법을 설명합니다.

키 목록

두 OpenPGP 키는 수동으로 확인할 수 있도록 다운로드할 수 있습니다. 어플라이언스 키는 https://instance-registry.ironflock.com/dl/appliance/appliance-release.asc에서(첫 설치 전 설치 프로그램 검증 참조), 부트스트랩 키는 https://instance-registry.ironflock.com/dl/device-init/ironflock-bootstrap.asc에서(선택 사항: 설치 프로그램 먼저 검증하기 참조) 받을 수 있습니다. gpg가 보고하는 지문을 이 페이지의 지문과 비교하십시오. 디바이스 에이전트의 키는 에이전트에 내장되어 있으므로 수동으로 확인할 것이 없습니다.

Windows에서는 디바이스 에이전트가 다운로드하는 모든 업데이트와 모든 frpc.exe를 에이전트에 내장된 코드 서명 루트로 확인합니다. 파일에는 이 루트가 발급한 서명자 인증서의 유효한 서명이 있어야 합니다. 버전 1.5.6부터는 확인에 실패한 파일이 삭제되며 실행되지 않습니다. 버전 1.5.4와 1.5.5는 실패를 로그에 남기기만 했습니다. 서명자 인증서는 확인하는 시점을 기준으로 검사되므로, 시계가 인증서의 유효 기간을 벗어난 Windows 디바이스는 시계가 맞을 때까지 업데이트되지 않습니다. 또한 에이전트는 시작할 때마다 자신의 실행 파일을 확인하고, 로그 C:\ProgramData\IronFlock\DeviceAgent\device-agent.log에 codesign: self-check passed 또는 codesign: self-check FAILED를 기록합니다. FAILED를 기록하는 디바이스는 자신이 실행하는 에이전트와 같은 방식으로 서명된 업데이트를 거부합니다.

에이전트 설치 프로그램은 코드 서명 루트를 컴퓨터의 신뢰할 수 있는 루트 인증서에도 추가합니다. 에이전트의 확인에는 그곳의 루트가 필요하지 않으므로, 설치 프로그램이 이 작업을 하기 전에 설치된 디바이스도 같은 방식으로 업데이트를 확인합니다. 그것이 이 페이지의 루트인지 확인하려면 PowerShell에서 Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like '*IronFlock Code Signing Root*' | Format-List Subject, Thumbprint, NotAfter를 실행하십시오. 지문(Thumbprint)은 6083E7E2446B8C95A6F6B2E3CFE354AE02859196이어야 합니다. 루트가 그곳에 있으면 Get-AuthenticodeSignature "$env:ProgramData\IronFlock\DeviceAgent\device-agent.exe" | Select-Object Status, @{ n = 'Serial'; e = { $_.SignerCertificate.SerialNumber } }가 Valid를 표시합니다. Windows는 일련 번호 앞에 00을 붙여 00D137272B35F0ED5211219674E8B052B4로 표시합니다. 버전 1.5.4 이전의 디바이스 에이전트와 frp 버전 0.71.1까지의 frpc.exe에는 같은 루트가 발급한 이전 Windows 서명자 인증서(일련 번호 481360741E254378C38A5236940BFFA44CFDD809)가 붙어 있습니다. 이 인증서로는 더 이상 새로 서명하지 않으며, 에이전트는 인증서가 2028년 10월에 만료될 때까지 그 서명을 받아들입니다.

2026년 11월 6일부터 릴리스되는 IronFlock 플랫폼의 모든 서비스 이미지는 빌드 출처 증명을 서명된 증명(attestation)으로 가지고 있습니다. 증명은 이미지의 플랫폼마다 하나씩, SLSA v1 provenance 형식으로, 소스 저장소, 커밋, 빌드, 그리고 이미지를 빌드한 기반 이미지를 담고 있습니다. 증명은 레지스트리에 이미지와 함께 저장되며 공개 투명성 로그에는 기록되지 않습니다. 가져올(pull) 수 있는 이미지를 확인하려면 아래 공개 키를 image-provenance.pub로 저장하고, 그 지문을 표의 지문과 비교한 뒤(첫 번째 명령), cosign 3 이상으로 이미지를 다이제스트로 검증하십시오(두 번째 명령).

-----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는 투명성 로그 항목을 찾지 말라고 cosign에 알릴 뿐이며, 서명은 여전히 키로 확인됩니다. 각 증명은 predicate.buildDefinition.internalParameters.targetPlatform에 자신의 플랫폼을 표시합니다. 그 전에 릴리스된 이미지에는 서명된 출처 증명이 없으므로, 각 서비스가 다시 릴리스될 때까지 하나의 IronFlock 버전에 출처 증명이 있는 이미지와 없는 이미지가 함께 있을 수 있습니다.

이 출처 증명은 SLSA Build Level 3을 충족합니다. 각 이미지는 호스팅된 빌드 서비스의 새 머신에서, 다른 모든 빌드와 분리되어, 다른 빌드와 공유하는 빌드 캐시 없이 빌드됩니다. 출처 증명은 다른 머신에서 별도의 단계로 서명되며, 이 단계는 빌드되는 코드를 전혀 실행하지 않고 출처 증명이 명시하는 소스 저장소, 커밋, 빌드를 확인합니다. 키를 사용할 수 있는 것은 이 단계뿐입니다. 이미지에는 같은 릴리스의 이전 단계에서 준비한 데이터(예: 검색 인덱스)가 포함될 수도 있습니다. 출처 증명은 그러한 입력을 명시할 뿐, 그 내용은 명시하지 않습니다. 2026년 11월 5일에 릴리스된 일부 이미지는 이미 서명된 출처 증명을 가지고 있습니다. 이는 Level 2를 충족하는데, 당시에는 키가 아직 서명 단계로 제한되지 않았기 때문입니다.

키 보관 방식

• 이 페이지의 키는 코드 서명 루트를 제외하고 내보낼 수 없습니다. 개인 키는 IronFlock의 키 관리 시스템에 보관되며, 서명도 그곳에서 이루어집니다. 코드 서명 루트는 소프트웨어에 서명하지 않고 Windows 서명자의 인증서에만 서명합니다. 그 키는 그 인증서를 교체할 때만 사용됩니다.
• 릴리스는 해당 릴리스 파이프라인이 서명합니다. 한 제품의 릴리스에 서명하는 키는 그 제품의 자동화된 릴리스만 사용할 수 있으며, 그것도 검사와 테스트를 통과한 후에만 가능합니다.
• 디바이스 에이전트는 서로 독립된 두 개의 키를 신뢰합니다. 새 릴리스는 첫 번째 키로 서명됩니다. 두 번째 키는 이전 릴리스에 서명했던 키로, 이 키만 신뢰하는 이전 에이전트와 이전 버전의 ironflock-init을 위한 업데이트에는 지금도 수동으로 이 키로 서명합니다. 또한 첫 번째 키를 더 이상 사용할 수 없는 경우에 대비해 보관됩니다. 그런 경우에는 두 번째 키로 업데이트에 서명하므로, 디바이스는 확인을 건너뛰는 설정 없이도 계속 업데이트됩니다.

키 교체

키는 계획된 수명이 끝나면 교체되며, 유출이 의심되면 즉시 교체됩니다. 이 섹션은 위의 서명 키에 관한 것입니다. 어플라이언스 자체의 내부 시크릿은 ironflock-update --rotate로 교체합니다. 호스트의 시크릿을 참조하십시오. 교체는 항상 세 단계로 진행되므로, 모든 디바이스와 어플라이언스가 그 과정의 각 업데이트를 확인할 수 있습니다:

1. 새 키가 추가됩니다. 한 릴리스가 디바이스나 어플라이언스가 신뢰하는 키에 새 키를 추가합니다. 이 릴리스는 아직 현재 키로 서명되어 있으므로, 이 릴리스로 업데이트하는 모든 대상이 이를 받아들입니다.
2. 서명이 새 키로 넘어갑니다. 현장의 디바이스와 어플라이언스가 두 키를 모두 신뢰하는 릴리스를 실행하게 되면, IronFlock은 새 키로 서명합니다. 이 기간 동안에도 이전 키는 계속 신뢰됩니다.
3. 이전 키가 사용 종료됩니다. 이후의 릴리스가 이전 키를 제거합니다. 그때부터 이전 키로 된 서명은 거부되며, 그 키는 사용 종료된 키에 기재됩니다.

각 키에 대해 이것이 의미하는 바는 다음과 같습니다:

• 어플라이언스 릴리스 키. 어플라이언스는 자신의 ironflock-update에 포함된 키를 신뢰하므로, 2단계에서 서명된 업데이트를 확인하려면 먼저 1단계의 릴리스를 설치해야 합니다. 중첩 기간 내내 업데이트되지 않은 어플라이언스는 아무것도 변경되기 전에 업데이트를 중단합니다. 이 경우 첫 설치 전 설치 프로그램 검증에 설명된 대로, 새 키로 확인한 설치 프로그램을 한 번 수동으로 실행하십시오.
• 디바이스 에이전트 업데이트 키. 디바이스는 자신이 실행하는 에이전트에 내장된 키를 신뢰합니다. 중첩 기간 내내 오프라인이었던 디바이스는 새 키로 서명된 업데이트를 확인할 수 없습니다. 이 경우 새 키를 신뢰하는 디바이스 설치 프로그램으로 에이전트를 다시 설치하십시오.
• 부트스트랩 키. install.sh는 설치할 때마다 새로 다운로드되며 확인에 사용할 키를 직접 담고 있으므로, 새 키는 중첩 기간 없이 다음 설치 프로그램 릴리스부터 적용됩니다. 달라지는 것은 수동 확인뿐입니다. 이 페이지의 지문과 비교하십시오.
• Windows 코드 서명. Windows 디바이스는 서명자가 아니라 코드 서명 루트를 신뢰합니다. 같은 루트가 발급한 새 서명자 인증서는 중첩 기간 없이 다음 릴리스부터 적용되며, 디바이스에서 할 일은 없습니다. 에이전트는 확인하는 시점을 기준으로 서명자 인증서를 검사하므로, 만료된 인증서로 서명된 파일은 거부됩니다. 따라서 서명자 인증서는 만료되기 훨씬 전에 교체됩니다. 루트 자체는 2036년 7월에 만료되기 훨씬 전에 위의 세 단계로 교체됩니다. 중첩 기간 내내 오프라인이었던 Windows 디바이스는 에이전트를 다시 설치해야 합니다. 컴퓨터의 신뢰할 수 있는 루트 인증서에는 설치 프로그램이 추가한 루트가 그대로 남아 있으므로, 루트 교체 후에는 위의 PowerShell 확인에 이전 루트만 표시될 수 있습니다. 에이전트는 자신에 내장된 루트로 확인합니다.
• 이미지 출처 증명 키. 이 키를 확인하는 디바이스나 어플라이언스가 없으므로, 새 키는 중첩 기간 없이 다음 이미지 릴리스부터 적용됩니다. 이미지는 릴리스될 때의 증명을 그대로 유지합니다. 릴리스 당시 사용되던 키(이 페이지 또는 사용 종료된 키에 기재)로 확인하십시오.

중첩 기간 동안 이 페이지에는 두 키가 각각의 지문과 함께 기재되며, 릴리스 노트가 각 단계를 알립니다. 최신 상태로 유지되는 어플라이언스나 디바이스에서는 아무것도 할 필요가 없습니다.

키가 유출된 경우 IronFlock은 즉시 그 키로 서명하는 것을 중단하고, 위와 같은 방식으로 짧은 일정에 따라 키를 교체하며, 보안 권고를 게시합니다.

사용 종료된 키

아직 없습니다.