백업이 상태를 되감을 때: 한 번만 써야 하는 값
RFC 10033 이 정리한 상태 기반 해시 서명의 상태·백업 관리 지침을 따라, 한 번만 써야 하는 값을 다루는 시스템에서 백업과 캐시가 상태를 되감는 위험과 그것을 막는 설계를 법률 데이터 운영에 옮겨 봅니다.
초록 양자내성 서명으로 주목받는 상태 기반 해시 서명(LMS·HSS·XMSS)은 일회용 서명 키를 묶어 쓰고, 어느 키를 이미 썼는지를 상태라는 카운터로 기록합니다. 같은 일회용 키로 다른 두 메시지에 서명하면 위조가 계산상 가능해지므로 상태는 절대 되돌아가면 안 됩니다. 지난달 나온 RFC 10033 은 이 상태와 그 백업을 어떻게 관리할지를 정리한 정보성 문서입니다. 문서가 가장 경계하는 것은 저장 장치의 고장이 아니라 사본입니다. 디스크와 메모리, 캐시, 복제된 가상 머신, 그리고 복원한 백업이 각자 상태를 들고 있으면 이미 쓴 키가 다시 쓸 수 있는 것처럼 보이게 됩니다. 이 칼럼은 문서가 제시한 원자적 갱신·사전 할당·예약 구간·백업 설계를 읽고, 같은 구조의 위험이 법률 데이터의 사본 관리에서 어떻게 나타나는지 살핍니다.
백업은 보통 안전장치로 여겨집니다. 장비가 망가지면 사본으로 되살리면 되고, 사본이 많을수록 든든하다고 생각합니다. RFC 10033 은 이 직관이 통하지 않는 시스템을 다룹니다. 상태 기반 해시 서명의 비밀키는 정해진 개수의 일회용 서명 키 묶음이고, 서명할 때마다 몇 번째 키까지 썼는지를 나타내는 상태가 올라갑니다. 어제 찍어 둔 백업을 오늘 복원하면 그 상태는 어제의 숫자로 돌아가고, 어제 이후에 쓴 키들이 다시 쓸 수 있는 것처럼 보입니다. 문서는 그래서 백업 관리를 가용성을 보장하되 이미 쓴 키가 다시 쓸 수 있는 상태로 되감지 않는 일로 정의합니다. 사본이 많을수록 든든한 것이 아니라, 사본이 많을수록 되감길 길이 많아지는 셈입니다.
핵심 기술 개념
상태(State)
상태 기반 해시 서명에서 어느 일회용 서명(OTS) 키를 이미 썼는지 기록하는 자료 구조로, 대개 단순한 카운터입니다. RFC 10033 은 변하지 않는 비밀키와 서명할 때마다 바뀌는 상태를 개념적으로 구분해 다루라고 권합니다. 상태는 성공한 서명마다 반드시 바뀌어야 합니다.
상태 재사용(State Reuse)
같은 상태, 곧 같은 일회용 키로 두 번 서명하는 일입니다. 공격자가 같은 OTS 키로 만든 서로 다른 두 메시지의 서명을 얻으면 위조를 만드는 것이 계산상 가능해집니다. 백업 복원, 프로세스 복제, 가상 머신 복제가 대표적인 경로입니다.
예약 구간(Reservation Interval)
서명 공간의 한 구간을 미리 사용 처리해 비휘발 저장에 기록한 뒤, 그 구간의 키를 하나씩 쓰는 방식입니다. 장치가 재시작되면 메모리에 있던 남은 구간은 잃지만, 잃는 것은 서명 개수이지 안전이 아닙니다. 키마다 상태를 갱신하지 않아도 되어 갱신 실패로 인한 재사용 가능성이 줄어듭니다.
기술 심층 분석
서명보다 상태가 먼저다
문서 4장은 요구사항을 한 문장으로 압축합니다. 같은 상태에서 두 서명 작업이 나올 수 없어야 하고, 서명 생성과 상태 갱신은 하나의 원자적 트랜잭션처럼 보여야 하며, 시스템은 상태를 되돌릴 수 없게 정확히 갱신하기 전에는 서명을 내보내서는 안 됩니다. 문서는 상태 관리가 원자성·일관성·격리성·지속성이라는 데이터베이스의 네 성질을 모두 갖추라고 요구합니다. 순서가 핵심입니다. 서명을 먼저 내보내고 상태를 나중에 쓰면, 그 사이에 전원이 나가거나 프로세스가 죽었을 때 밖에는 서명이 나갔는데 안에는 그 키가 아직 안 쓴 것으로 남습니다. 다음 서명은 같은 키를 다시 집습니다. 실패는 오류로 드러나지 않고, 나중에 누군가 두 서명을 나란히 놓았을 때에야 드러납니다.
캐시와 복제가 만드는 두 번째 판
같은 장에서 문서는 현대 시스템의 추상화 계층이 같은 상태의 두 판이 공존하지 않도록 보장하기를 특히 어렵게 만든다고 적습니다. 비밀키는 디스크에 있고 처리할 때 메모리로 올라오는데, 둘은 언제나 완벽히 동기화돼야 하며 적재·기록·수정이 진행되는 동안 다른 부분이 어떤 판도 읽어서는 안 됩니다. 중간에 캐시가 끼어 있으면 상태가 여러 곳에 존재할 수 있습니다. 복제도 같은 위험입니다. 서명 작업을 하던 프로세스가 동기화 없이 fork 되면 두 프로세스가 같은 상태를 들고 나가고, 가상 머신을 비휘발 저장으로 백업하거나 실행 중에 복제해도 같은 일이 생깁니다. 문서는 작업이 클라우드로 옮겨 갈수록 이 문제가 흔해질 수 있다고 내다보며, 소프트웨어만으로는 어려운 되감김 방지 카운터를 위해 전용 암호 하드웨어를 권합니다.
상태를 바깥에 맡기는 방법들
5장은 상태를 관리하는 여러 방식을 장단과 함께 늘어놓습니다. 사전 할당은 서명할 대상에 번호가 있을 때 그 번호와 서명 상태를 일대일로 묶는 방식입니다. 소프트웨어 버전 1, 2, 3 이 각각 정해진 일회용 키를 쓰게 하면 상태 관리가 서명 대상 쪽으로 넘어가고, 운영자는 버전이 단 한 번만 발행되도록 보장하면 됩니다. 문서는 릴리스 과정이 실패했다면 이중 서명을 피하려고 버전 번호를 건너뛰어야 할 수 있다고 덧붙입니다. 시간 기반 방식은 시간 창마다 쓸 수 있는 키 묶음을 나누는데, 장치의 시계가 절대 뒤로 가면 안 되고 지난 창에서 안 쓴 키는 버려야 하며 교체 장치의 시각은 원래 장치와 같거나 앞서야 합니다. 예약 구간 방식은 구간을 먼저 사용 처리해 기록하고 쓰므로, 재시작하면 남은 키를 잃을 뿐 재사용은 일어나지 않습니다. 세 방식의 공통점은 모호할 때 잃는 쪽을 택한다는 것입니다.
복원할 때 사본을 지운다
6장의 백업 설계는 이 원칙을 끝까지 밀고 갑니다. 하위 트리를 추가로 만들어 그 루트를 상위 트리로 서명해 두고, 하위 트리를 만든 시드를 안전하게 내보낸 뒤 하드웨어 모듈에서 되돌릴 수 없게 지웁니다. 모든 모듈이 한꺼번에 망가진 최악의 경우에만 새 모듈에 시드 하나를 들여오고, 들여온 즉시 백업 매체에서 그 시드를 지운 다음 시드의 해시를 출력하게 해 정확성을 확인합니다. 백업이 있는 동안에는 그 백업이 아직 쓰지 않은 서명 공간만 담고 있고, 한 번 꺼내 쓴 것은 다시 꺼낼 수 없게 됩니다. 문서는 상태 기반 방식이 범용 서명이 아니라는 점도 분명히 합니다. 서명 개수에 제한이 없어야 하는 대부분의 응용은 같은 가정 위의 무상태 방식인 SLH-DSA 나 ML-DSA 를 써야 한다는 것입니다. 상태를 관리할 자신이 없으면 상태가 없는 도구를 고르는 것도 설계입니다.
기술적 트레이드오프
긴장 관계 사본을 많이 둘수록 장애에서 빨리 되살아나지만, 사본마다 상태의 한 시점을 들고 있어 되감김의 길이 늘어난다. 반대로 사본을 줄이고 복원 절차를 엄격하게 하면 되감김은 막지만, 장애 때 멈춰 있는 시간이 길어지고 잃는 용량이 생긴다.
실무적 해소 정본을 하나로 정하고, 사본은 정본에서 다시 만들 수 있는 파생물로만 둡니다. 사본을 써야 할 때는 정본보다 낡지 않았는지를 먼저 확인하고, 확인할 수 없으면 사본을 쓰기보다 멈추거나 정본에서 다시 만듭니다. RFC 10033 의 예약 구간처럼, 모호할 때는 재사용보다 손실을 택합니다.
이 주장이 틀리는 조건
반증 조건 정본 하나에서 사본을 다시 만들고 모호하면 멈추자는 이 판단은 운영에서 깨질 수 있습니다. 사본을 정본에서 다시 만드는 비용 때문에 멈춘 시간이 되감김으로 생긴 결함보다 사용자에게 더 큰 피해를 준다는 것이 관측되면, 멈춤 대신 사본을 쓰고 사후에 대조하는 쪽이 낫습니다. 또 사본이 정본보다 낡아 있던 사례가 장기간 한 번도 관측되지 않는다면, 그 자리의 사본은 애초에 상태를 들고 있지 않았던 것이고 확인 절차는 덜어 내도 됩니다.
법마디 OS에 적용한다면
법마디 OS 는 전자서명을 발급하지 않습니다. 그래도 같은 구조의 위험은 법률 데이터의 사본에서 나타났습니다. 법마디의 판례 자료는 검증 자산이 정본이고, 매일 콘텐츠를 만드는 작업과 서비스 빌드, 자산 점검은 그 정본에서 투영한 판례 캐시를 씁니다. 이달 20일 점검에서 그 작업들이 받아 쓰던 캐시 사본이 9월 중순의 투영 그대로 남아 있어, 그 뒤에 정본에서 바로잡은 판시사항과 새로 더한 판례가 사본을 쓰는 경로에 닿지 않았다는 것이 드러났습니다. 백업을 복원하면 상태가 되감기는 것과 같은 모양입니다. 지금은 세 경로 모두 실행할 때마다 정본에서 캐시를 다시 투영하고, 보관된 사본은 그 투영이 실패할 때만 대체로 씁니다. 사전 할당과 닮은 교훈도 있습니다. 법률상식은 날짜마다 담당 리더가 정해지고 차례를 넘긴 리더는 이월 대기열에 오르는데, 빠진 날을 수기로 메우는 스크립트를 두 번 실행하자 대기열이 한 번 더 소모돼 글이 다른 리더 이름으로 다시 나간 일이 있었습니다. 그 뒤로 수기 스크립트는 리더를 다시 뽑지 않고 그날 판정된 값을 상수로 박아, 차례를 그 날짜에 묶어 둡니다. 남은 과제는 사본을 쓰는 다른 자리에서도 정본보다 낡았는지를 먼저 재는 일입니다.
기술적 함의
- 한 번만 써야 하는 값을 다루는 시스템에서 사본은 안전장치이기 전에 위험원이다. 백업·캐시·복제는 저마다 상태의 한 시점을 들고 있다.
- 결과를 내보내는 일보다 상태를 기록하는 일이 먼저 끝나야 한다. 순서가 뒤집히면 실패는 오류가 아니라 나중의 중복으로 드러난다.
- 상태가 모호할 때는 재사용보다 손실을 택한다. 건너뛴 번호, 버린 시간 창, 잃은 예약 구간은 비용이지 결함이 아니다.
"백업은 과거를 보존하는 장치입니다. 한 번만 써야 하는 값을 다루는 시스템에서는 바로 그 성질이 위험이 됩니다. 좋은 설계는 사본을 정본의 파생물로만 두고, 상태를 먼저 기록한 뒤 결과를 내보내며, 모호할 때는 다시 쓰기보다 잃는 쪽을 고릅니다."
