True Random Number Generator

회로는 작은 전기적 변동을 측정해 숫자로 바꿀 수 있습니다. 중요한 것은 측정 결과 중 공격자가 예측할 수 없는 부분이 얼마나 되는지입니다. 많은 데이터를 빠르게 만드는 것만으로는 부족합니다. 그래서 NIST SP 800-90B는 구체적인 잡음 원천, 샘플링, 필요한 처리, 동작 검사를 평가합니다. 물리 현상의 이름만으로 이 평가를 대신할 수는 없습니다. [1]

어떤 원천은 1보다 0을 더 자주 내놓을 수 있습니다. conditioning이라는 처리는 이런 치우침을 줄이고, 이미 있는 엔트로피, 즉 공격자가 알 수 없는 정도를 더 짧은 출력에 모으는 데 쓰입니다. 없는 불확실성을 만들어 내지는 못합니다. 그래서 NIST SP 800-90B는 출력에서 인정할 수 있는 엔트로피를 입력과 처리 방식에 연결합니다. 데이터의 지문처럼 계산하는 값인 해시도 원래 값이 예측 불가능했다는 증거는 아닙니다. 입력을 알면 같은 지문을 다시 계산할 수 있기 때문입니다. [1]

원천이 같은 값만 반환하기 시작하면 장치는 이를 놓쳐서는 안 됩니다. NIST SP 800-90B는 Repetition Count Test로 반복을, Adaptive Proportion Test로 비정상적인 빈도를 감시합니다. 이 검사는 특정 고장을 찾으며, 모든 공격이나 결함을 자동으로 감지하지는 않습니다. 지속적인 고장을 발견하면 정상 작동할 때처럼 계속 출력을 제공해서는 안 됩니다. [1]

TRNG가 있다는 사실만으로 지갑이 안전하다고 할 수는 없습니다. 해당 버전이 데이터를 어떻게 쓰고 오류에 어떻게 대응하는지도 중요합니다. 그래서 NIST SP 800-90C는 원천과 그 뒤의 생성기를 함께 다룹니다. 부품 하나를 평가하는 것은 지갑 전체를 평가하는 것과 다릅니다. 훌륭한 난수 원천도 나중에 공개한 백업을 보호해 주지는 못합니다. [4]

작동 중인 장치를 오래 기록하는 것과 전원을 반복해서 껐다 켜는 것은 서로 다른 동작 특성을 보여 줍니다. 그래서 NIST SP 800-90B에는 재시작 시험도 있습니다. 평가는 해당 원천과 실제 작동 조건에 맞아야 합니다. 한 표본의 결과가 모든 장치나 환경에 자동으로 적용되는 것은 아닙니다. 장치 내부에서 실행되는 프로그램인 펌웨어를 바꿔도 재평가가 필요할 수 있습니다. [1]

기술 문서에는 RDRAND와 RDSEED라는 명령어가 나옵니다. Intel은 하드웨어 난수 생성기 DRNG의 안내서에서 이를 설명합니다. RDRAND는 내부 상태를 바탕으로 다음 값을 계산하는 결정론적 생성기의 결과를 제공합니다. RDSEED는 초기화, 즉 생성기의 시작 상태를 만드는 데 쓰도록 처리한 엔트로피를 제공합니다. 둘 다 물리적 원천에서 출발할 수 있지만, 가공하지 않은 잡음을 그대로 읽을 수 있다는 뜻은 아닙니다. [2]

프로세서가 요청마다 결과를 준비해 두는 것은 아닙니다. 따라서 Intel은 RDRAND와 RDSEED 모두 상태 플래그 CF를 확인하도록 요구합니다. 1이면 결과를 쓸 수 있고 0이면 아직 결과가 없습니다. 프로세서 안의 작은 저장 공간인 목적지 레지스터에 숫자 0이 있는지만 봐서는 충분하지 않습니다. 프로그램은 성공 여부를 나타내는 플래그를 읽어야 합니다. 프로세서가 명령어를 지원한다는 사실만으로 개별 요청의 성공이 보장되지는 않습니다. [2]

Linux의 hw_random 인터페이스에서는 /dev/hwrng를 통해 파일을 읽듯 하드웨어 원천의 데이터를 읽을 수 있습니다. 하지만 문서는 이 인터페이스 자체가 데이터의 품질 시험을 수행하지 않는다고 분명히 경고합니다. 고장 나거나 변조된 하드웨어가 잘못된 데이터를 반환해도 애플리케이션은 이를 읽을 수 있습니다. 읽기에 성공했다고 엔트로피가 충분한 것은 아닙니다. 원천과 프로그램이 그 출력을 사용하는 방식 모두를 평가해야 합니다. [3]