컨테이너나 VM snapshot 복원 뒤 사용자 공간 DRBG 상태가 복제되면 토큰 생성에 어떤 문제가 생기나요?

snapshot 복원으로 사용자 공간 DRBG 상태가 복제되면, 두 worker가 같은 상태에서 이어서 생성한 토큰이 같거나 예측 가능한 관계를 가질 수 있습니다. 이는 modulo bias와 다른 문제입니다. bias는 균등한 원천을 범위로 줄일 때 생기는 분포 오류이고, snapshot 문제는 원천의 내부 상태가 복제되는 상태·수명 문제입니다. 따라서 “편향이 작다”거나 PID와 시간을 섞는 것으로 해결하지 않겠습니다.

예를 들어 worker A와 B가 snapshot 시점에 같은 DRBG 상태 S를 가졌고 각각 다음 32바이트를 요청하면, 사용자 공간 생성기가 복원 이후 자동으로 독립 상태를 만들지 않는 한 같은 T(S)를 낼 수 있습니다. 이것은 계정별 token unique constraint가 충돌하는 수준을 넘어, 먼저 발급된 토큰이 다른 인스턴스에서 다시 발급되는 위험입니다. OS CSPRNG API와 런타임이 fork·restore 뒤 재시드 또는 상태 분리를 문서화하는지 확인하고, 보장이 불명확한 DRBG를 자격 생성기에 직접 쓰지 않습니다.

운영에서는 snapshot·fork·resume 경계를 금지하거나, 복원 뒤 신뢰 가능한 OS 난수원을 다시 읽고 상태를 재초기화하는 계약을 선택합니다. 그래도 시간·PID를 seed로 하는 fallback은 두 복제본에서 같고 공격자가 추정할 수 있으므로 보안 대체가 아닙니다. 이 환경에서 실제 VM 복원을 실행하지 않았다면 위 결과는 예상 trace이며, 대상 OS와 런타임 문서를 근거로 별도 시험을 추가해야 합니다.

상태를 단계로 적으면 분포 오류와 복제 오류가 갈립니다. snapshot 직전 DRBG 상태를 S라 하고 worker A와 B가 각각 복원된 뒤 첫 32바이트를 요청하면, 재시드 계약이 없는 사용자 공간 생성기는 둘 다 T(S)를 만들 수 있습니다. A가 먼저 token hash를 저장하고 B가 같은 값을 저장하려다 unique 제약에서 실패하면 충돌은 관측되지만, 목적·사용자 범위가 달라 unique 검사가 없으면 중복 자격이 발급될 수 있습니다. 0..7을 0..2로 %3하는 경우에는 0,1이 각각 세 번, 2가 두 번 나와 bias가 생기지만, snapshot 문제는 0..7이 균등해도 같은 상태가 같은 순열을 재생한다는 문제입니다. 복원 뒤 OS CSPRNG를 다시 읽는다는 대상 런타임 보장이 없으면 발급 endpoint를 차단하고, 시간·PID를 섞는 fallback은 복제본에서 같고 추정 가능하므로 쓰지 않습니다. 이 문서의 복원 결과는 실제 VM 실행이 아닌 예상 trace입니다.