요약

  • 코드 서명 인증서를 교체하거나 갱신하면 이후 릴리스에 서명하는 키가 바뀌지만, 그것만으로 구(舊) 인증서 만료 전에 서명되고 유효하게 타임스탬프된 바이너리가 무효화되는 것은 아닙니다.
  • 전환을 아티팩트-권한 대조 작업으로 다루어야 합니다. 모든 바이너리 해시를 서명자, RFC 3161 토큰, 실효 폐기 시각, 배포 위치, 관측된 검증 결과와 결합하는 것입니다.

정오에 어떤 소프트웨어 퍼블리셔가 릴리스 파이프라인을 대체 코드 서명 인증서로 전환합니다. 첫 새 빌드는 정상적으로 서명됩니다. 대시보드는 초록불입니다. 그러나 전날 저녁에 만들어진 바이너리가 지역 미러에 그대로 남아 있고, 유효한 타임스탬프를 갖고 있으며, 고객 머신에서 여전히 검증을 통과합니다.

이 과정에서 반드시 무언가가 고장 난 것은 아닙니다. 오류는 인증서 교체를 완료된 신뢰 전환으로 부르는 데 있습니다.

코드 서명은 소프트웨어가 특정 서명 신원과 연결되어 있는지, 서명된 바이트가 변경되었는지를 답합니다. 타임스탬프는 또 하나의 진술을 더합니다. 신뢰할 수 있는 타임스탬프 기관(Timestamp Authority)이 특정 시점에 어떤 해시가 존재했음을 증명하는 것입니다. 이 두 기록이 함께 있으면 검증자는 서명자 인증서의 통상적 만료 이후에도 서명을 수용할 수 있습니다. 또한 침해된 인증서의 산출물을 실효 폐기 시각 전후의 코드로 나눌 수도 있습니다.

그래서 코드 서명 인증서에는 두 개의 운영상 종료 시점이 있습니다. 하나는 만료입니다. 그 경계 이후 새로 만들어진 서명은, 개인 키로 서명 바이트를 여전히 계산할 수 있더라도, 통상적으로는 인증서가 유효했던 시기에 만들어진 서명으로 검증되지 않습니다. 다른 하나는 검증자가 그 인증서의 서명 권한을 더 이상 수용해서는 안 되는 시점입니다. 두 날짜가 동일할 수도 있지만, 신뢰 모델은 그렇기를 요구하지 않습니다.

타임스탬프가 실제로 증명하는 것

RFC 3161은MessageImprint, 즉 타임스탬프 기관에 제출된 데이터의 해시 알고리즘 식별자와 해시 값을 중심으로 하는 타임스탬프 프로토콜을 정의합니다. 기관은 알고리즘과 길이를 확인하지만 그 아래의 프로그램을 검사하지는 않습니다. 토큰에는 정책, 고유 일련번호,genTime이 담기며, 타임스탬프 전용 키로 서명됩니다.

따라서 이 토큰은 단순한 "서명 시각" 레이블보다 덜—그리고 더—증명합니다. 특정 인쇄물(imprint)이 명시된 타임스탬프 정책 하에 제출되었다는 것은 증명합니다. 그러나 코드가 안전했는지, 퍼블리셔가 모든 서명 경로를 통제했는지, 미러가 의도한 버전을 제공하고 있는지는 증명하지 않습니다.

검증은 여전히 능동적인 작업입니다. RFC 3161은 요청자가 응답, 타임스탬프 기관 인증서, 데이터 인쇄물, 해시 알고리즘, 서명, 시각을 확인하도록 요구합니다. Microsoft는 SignTool에서도 같은 분리를 드러냅니다.sign,timestamp,verify는 서로 다른 명령입니다. RFC 3161 경로에서는 타임스탬프 서버에/tr을, 타임스탬프 다이제스트에/td를 사용합니다. 검증은 서명 블롭이 존재한다는 사실만 보고하는 대신 서명자 체인과 폐기 상태를 확인할 수 있습니다.

Microsoft의 ClickOnce 문서는 실무적 결과를 직접적으로 제시합니다. 유효한 타임스탬프가 있으면 서명 인증서가 만료된 뒤에도 애플리케이션이 수용 상태를 유지할 수 있습니다. 이는 유용합니다. 인증서가 계획된 종료 시점에 도달할 때마다 건전한 과거 패키지를 모두 다시 서명해야 해서는 안 되기 때문입니다. 그러나 같은 내구성은 인증서 교체를 다음 릴리스가 새 키를 사용하는지만으로 측정할 수 없다는 뜻이기도 합니다.

폐기는 시간 경계를 만든다

CA/Browser Forum의 코드 서명 기본 요구사항(Code Signing Baseline Requirements)은 공개 신뢰 코드 서명 인증서와 그에 딸린 타임스탬프 기관을 다룹니다. 이 요구사항은 이러한 인증서를 발급하는 CA가 RFC 3161 호환 타임스탬프 서비스를 운영하도록 요구하고, 타임스탬프 사용을 권고하며, SHA-1 메시지 인쇄물을 거부하도록 합니다.

요구사항은 또한 폐기가 단순한 삭제 작업이 아닌 이유를 설명합니다. 하나의 인증서가 객체 하나를 서명했을 수도 있고 수천 개를 서명했을 수도 있습니다. 폐기하면 의심스러운 코드와 함께 건전한 코드도 무효화될 수 있습니다. CA는 타당성 있는 인증서 문제 신고를 24시간 이내에 조사를 시작해야 하고, 키 침해의 경우 실효 폐기일은 가장 이른 의심 침해 시점이어야 합니다.

그 날짜는 영향받은 소프트웨어를 시간으로 묶을 수 있습니다. 요구사항에 따르면 소프트웨어는 폐기일 이전의 타임스탬프를 가진 객체를 유효한 것으로 계속 취급해야 합니다. 이는 모든 플랫폼이 동일하게 동작한다는 보장이 아닙니다. 파일명이나 릴리스 채널이 아니라 근거로 아티팩트 집단을 분리하는 규칙입니다.

타임스탬프 기관에도 고유한 실패 경계가 있습니다. RFC 3161은 통상적 은퇴와 키 침해를 구분합니다. 타임스탬프 키가 침해 없이 은퇴하고 폐기 사유가 올바르게 표현되었다면 이전 토큰은 유효할 수 있습니다. 키 자체가 침해되었다면 그 키가 만든 토큰은 단순히 신뢰할 수 없으며, 감사 기록이나 독립적인 두 번째 타임스탬프가 중요할 수 있습니다.

운영상 분모는 배포된 모든 아티팩트

인증서 목록만으로는 부족합니다. 퍼블리셔는 어떤 아티팩트가 서명되었는지, 어떤 타임스탬프 토큰이 붙어 있는지, 각 아티팩트가 어디서 여전히 구할 수 있는지, 대상 검증자가 그것을 어떻게 취급하는지 알아야 합니다.

그 분모에는 기본 다운로드, 패키지 저장소, 콘텐츠 전송 캐시, 기업용 소프트웨어 스토어, 업데이트 채널, 오프라인 설치 프로그램, 복구 이미지가 포함됩니다. 최신 다운로드 페이지에서 바이너리를 제거하는 것은 나머지 어디에서도 그것을 회수하지 못합니다. 반대로, 건전한 과거 패키지를 찾지 않은 채 인증서를 폐기하면 보안 대응을 피할 수 있는 연속성 실패로 만들 수 있습니다.

최소한의 통제는 아티팩트-권한 전환 장부(ledger)입니다. 각 암호학적 아티팩트 해시에 대해 빌드와 릴리스, 서명자 인증서 지문과 일련번호, 서명 다이제스트, 타임스탬프 토큰과 기관,genTime, 인증서 만료, 폐기 상태와 실효 폐기 시각을 기록합니다. 이 필드들을 모든 배포 위치, 철회 또는 교체 상태, 검증자 정책, 관측된 수용 또는 거부 결과와 결합합니다.

이 장부는 완료 판정을 반증 가능하게 만듭니다. 전환이 완료되는 것은, 이후 생산이 의도한 서명자를 사용하고, 보존된 모든 과거 아티팩트에 명시적인 신뢰 결정이 내려지고, 철회된 모든 아티팩트가 통제된 배포 표면에서 사라지며, 대표 검증자들이 기대한 결과를 낼 때뿐입니다.

근거 경계

RFC 3161은 토큰과 검증 메커니즘을 규정하며, 특정 타임스탬프 기관을 인증하지는 않습니다. CA/Browser Forum의 요구사항은 공개 코드 서명 기준선을 다룰 뿐, 모든 운영체제나 패키지 관리자가 동일하다고 만들지 않습니다. Microsoft 문서는 문서화된 SignTool, Authenticode, ClickOnce 동작을 확립할 뿐, 모든 소프트웨어 생태계의 동작을 확립하지 않습니다.

이 글에서는 어떤 침해도 주장하지 않습니다. 요점은 더 좁습니다. 인증서 만료, 인증서 교체, 인증서 폐기, 타임스탬프 기관 실패는 서로 다른 사건입니다. 방어 가능한 전환은 근거와 결정 양쪽에서 이 차이를 유지합니다.

출처