RDRAND

**`RDRAND`**("read random"의 약자)는 인텔 온칩 하드웨어 난수 생성기에서 난수를 반환하는 명령어로, 온칩 엔트로피 소스에 의해 시드된다.access-date=2012-11-25 또한 **인텔 시큐어 키 기술**로도 알려져 있으며,language=en 코드명은 **불 마운틴**이다. access-date = 30 December 2013 인텔은 2012년경 이 기능을 도입했으며, AMD는 2015년 6월에 이 명령어에 대한 지원을 추가했다. (`RDRAND`는 아이비브리지 프로세서에서 사용할 수 있으며group="note" 인텔 64 및 IA-32 명령어 집합 아키텍처의 일부이다.) access-date = 16 October 2015 이 난수 생성기는 NIST SP 800-90A,access-date=September 16, 2013 FIPS 140-2, ANSI X9.82와 같은 보안 및 암호화 표준을 준수한다. 인텔은 또한 2012년 암호화 연구소(Cryptography Research Inc.)에 난수 생성기 검토를 요청했으며, 그 결과 "인텔 아이비브리지 디지털 난수 생성기 분석"이라는 논문이 나왔다. archive-date = 2014-12-30 **`RDSEED`**는 `RDRAND`와 유사하며 엔트로피 생성 하드웨어에 대한 하위 수준 액세스를 제공한다. `RDSEED` 생성기 및 프로세서 명령어 `rdseed`는 인텔 브로드웰 CPU access-date= 2015-10-24 및 AMD 젠 CPU에서 사용할 수 있다.access-date = 2015-10-25
# 개요
`CPUID` 명령어는 AMD 및 인텔 CPU에서 `RDRAND` 명령어 지원 여부를 확인하는 데 사용할 수 있다. 지원되는 경우 CPUID 표준 함수 `01H` 호출 후 ECX 레지스터의 비트 30이 설정된다.quote=All Intel processors that support the RDRAND instruction indicate the availability of the RDRAND instruction via reporting CPUID.01H:ECX.RDRAND[bit 30] = 1 AMD 프로세서는 동일한 테스트를 사용하여 이 기능을 확인한다.quote=Support for the RDRAND instruction is optional. On processors that support the instruction, CPUID Fn0000_0001_ECX[RDRAND] = 1 `RDSEED` 가용성은 인텔 CPU에서 비슷한 방식으로 확인할 수 있다. `RDSEED`가 지원되는 경우 CPUID 표준 함수 `07H` 호출 후 EBX 레지스터의 비트 18이 설정된다.quote=All Intel processors that support the RDSEED instruction indicate the availability of the RDSEED instruction via reporting CPUID.(EAX=07H, ECX=0H):EBX.RDSEED[bit 18] = 1 `RDRAND`의 연산 코드는 `0x0F 0xC7`이며, 그 뒤에 대상 레지스터를 지정하고 64비트 모드에서 REX 접두사와 선택적으로 결합되는 ModRM 바이트가 온다.access-date=2014-01-30 인텔 시큐어 키는 `RDRAND` 명령어와 기본 난수 생성기 (RNG) 하드웨어 구현에 대한 인텔의 명칭으로, 개발 중에는 "불 마운틴"이라는 코드명을 가졌다. 인텔은 그들의 RNG를 "디지털 난수 생성기" 또는 DRNG라고 부른다. 이 생성기는 하드웨어 엔트로피 소스에서 생성된 256비트 원시 엔트로피 샘플 쌍을 가져와 고급 암호화 표준 (AES) (CBC-MAC 모드) 조건자에 적용하여 단일 256비트 조건화된 엔트로피 샘플로 줄인다. NIST SP 800-90A에 정의된 CTR DRBG라는 결정론적 난수 생성기는 조건자의 출력으로 시드되어 `RDRAND` 명령어를 통해 요청하는 응용 프로그램에 암호학적으로 안전한 난수를 제공한다.date=September 2011 하드웨어는 시드 값을 변경하기 전에 최대 511개의 128비트 샘플을 발행한다. `RDSEED` 연산을 사용하면 AES-CBC-MAC에서 조건화된 256비트 샘플에 액세스할 수 있다. `RDSEED` 명령어는 브로드웰 CPU에서 사용 가능한 다른 유사 난수 생성기를 시드하기 위해 인텔 시큐어 키에 추가되었다.date=November 2012 `RDSEED` 명령어의 엔트로피 소스는 자체 타이밍 회로에서 비동기적으로 실행되며 실리콘 내의 열 잡음을 사용하여 초당 3 GHz의 속도로 임의의 비트 스트림을 출력한다.access-date=18 February 2015 이는 `RDRAND`에서 얻을 수 있는 유효 초당 6.4 기가비트보다 느리다(두 속도 모두 모든 코어와 스레드 간에 공유된다).https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide says 800 megabytes, which is 6.4 gigabits per second. `RDSEED` 명령어는 임의의 너비의 소프트웨어 유사난수 생성기를 시드하는 데 사용되는 반면, `RDRAND`는 단순히 고품질 난수를 요구하는 응용 프로그램에 사용된다. 암호화 보안이 필요하지 않은 경우 Xorshift와 같은 소프트웨어 PRNG가 일반적으로 더 빠르다.가장 간단한 64비트 Xorshift 구현은 3개의 XOR과 3개의 시프트를 가지고 있다. 만약 이것들이 2 GHz에서 4개의 코어에서 긴 루프로 실행된다면, 처리량은 80 Gb/s가 된다. 실제로는 로드/스토어 오버헤드 등으로 인해 더 적겠지만, 여전히 `RDRAND`의 6.4 Gb/s를 초과할 가능성이 높다. 반면에, `RDRAND`의 숫자 품질은 Xorshift와 같은 소프트웨어 PRNG보다 높을 것이다.
## 성능
인텔 코어 i7-7700K, 4500 MHz (45 × 100 MHz) 프로세서(카비레이크 마이크로아키텍처)에서 단일 `RDRAND` 또는 `RDSEED` 명령어는 피연산자 크기(16/32/64 비트)에 관계없이 110 ns, 즉 463 클럭 사이클이 소요된다. 이 클럭 사이클 수는 스카이레이크 또는 카비레이크 마이크로아키텍처를 사용하는 모든 프로세서에 적용된다. 실버몬트 마이크로아키텍처 프로세서에서는 각 명령어가 피연산자 크기에 관계없이 약 1472 클럭 사이클이 소요되며, 아이비브리지 프로세서에서는 `RDRAND`가 최대 117 클럭 사이클이 소요된다.archive-date=2006-08-08 AMD 라이젠 CPU에서 각 명령어는 16비트 또는 32비트 피연산자의 경우 약 1200 클럭 사이클, 64비트 피연산자의 경우 약 2500 클럭 사이클이 소요된다. 천체 물리학 몬테카를로 시뮬레이터는 쿼드 코어 인텔 i7-3740 QM 프로세서에서 `RDRAND`를 사용하여 107개의 64비트 난수를 생성하는 시간을 조사했다. 그들은 `RDRAND`의 C 구현이 C의 기본 난수 생성기보다 약 2배 느리고, 메르센 트위스터보다 약 20배 느리게 실행된다는 것을 발견했다. `RDRAND`의 파이썬 모듈이 구축되었지만, 파이썬의 기본 난수 생성기보다 20배 느리다는 것이 밝혀졌다.doi-access=free 단, 유사난수와 CSPRNG 사이의 성능 비교는 할 수 없다. 2020년 6월 인텔이 발표한 마이크로코드 업데이트는 CrossTalk 취약점(아래 보안 문제 섹션 참조)을 완화하기 위해 설계되었으며, 추가 보안 제어로 인해 `RDRAND` 및 `RDSEED`의 성능에 부정적인 영향을 미친다. 완화 조치가 적용된 프로세서에서는 각 영향을 받는 명령어에 추가 지연 시간이 발생하고 코어 간 `RDRAND` 또는 `RDSEED`의 동시 실행이 효과적으로 직렬화된다. 인텔은 이러한 보안 검사를 완화하여 대부분의 시나리오에서 성능 영향을 줄이는 메커니즘을 도입했지만, 인텔 프로세서는 기본적으로 이 보안 완화를 적용하지 않는다.
## 컴파일러
비주얼 C++ 2015는 `RDRAND` 및 `RDSEED` 함수에 대한 내재적 래퍼 지원을 제공한다.title=x86 intrinsics list GCC 4.6+ 및 클랭 3.2+는 플래그에 `-mrdrnd`가 지정되었을 때 `RDRAND`에 대한 내장 함수를 제공하며,title=X86 Built-in Functions - Using the GNU Compiler Collection (GCC) 또한 `__RDRND__`를 설정하여 조건부 컴파일을 허용한다. 최신 버전은 `immintrin.h`를 추가로 제공하여 이러한 내장 함수를 인텔 C 컴파일러 버전 12.1+와 호환되는 함수로 래핑한다. 이 함수들은 매개변수가 가리키는 위치에 임의의 데이터를 쓰고 성공 시 1을 반환한다.date = 2019-12-23
# 응용 프로그램
OpenSSL에서 `RDRAND` 및 `RDSEED`를 사용하여 암호학적으로 안전한 난수를 생성하는 것은 통신 보안을 돕는 하나의 옵션이다. 몬테카를로 시뮬레이터에서 `RDRAND`의 과학적 적용이 성능 및 재현성을 중심으로 다른 난수 생성기와 비교하여 평가되었다. 그 결과 메르센 트위스터 대신 `RDRAND`를 사용하는 것이 다른 결과를 제공하지 않지만 성능 및 재현성 측면에서 더 나쁘다는 결론이 나왔다.volume = 234
# 반응
2013년 9월, 뉴욕 타임스의 NSA가 암호화를 약화시키려는 노력을 폭로하는 기사access-date = November 15, 2017에 대한 응답으로, 시어도어 초는 리눅스 커널의 `/dev/random`에 `RDRAND`를 사용하는 것에 대해 다음과 같이 공개적으로 게시했다.archive-date=2018-06-11 나는 인텔 엔지니어들이 `/dev/random`이 `RDRAND` 명령어에만 의존하도록 압력을 가했을 때 저항했던 것이 정말 기쁘다. [뉴욕 타임스 기사]에서 인용하자면: "올해까지 SIGINT 이네이블링 프로젝트는 칩 제조사와 협력하여 백도어를 삽입하는 방식으로 기업 및 정부를 위한 정보 암호화 칩 내부에 침투할 방법을 찾았다..." 감사 불가능한 칩 내부에 봉인된 구현을 사용하는 하드웨어 난수 생성기에만 의존하는 것은 나쁜 생각이다. 리누스 토르발스는 리눅스 커널에서 `RDRAND` 사용에 대한 우려를 일축하며, `/dev/random`의 유일한 엔트로피 소스로 사용되지 않고, `RDRAND`에서 받은 값과 다른 무작위성 소스를 결합하여 엔트로피를 향상시키는 데 사용된다고 지적했다.publisher=theregister.co.uk 그러나 디퓨즈 시큐리티의 테일러 혼비는 `RDRAND` 명령어에 백도어가 도입되어 이를 사용하는 코드를 특별히 표적으로 삼는 경우 리눅스 난수 생성기가 불안정해질 수 있음을 입증했다. 혼비의 개념 증명 구현은 버전 3.13 이전의 수정되지 않은 리눅스 커널에서 작동한다.author=Taylor Hornbyaccess-date=11 January 2016author2-link=Tanja Lange 이 문제는 2013년 리눅스 커널에서 완화되었다.access-date=30 July 2021 개발자들은 FreeBSD 커널을 `RDRAND`와 VIA PadLock을 직접 사용하는 방식에서 다음과 같은 주석과 함께 변경했다. "FreeBSD 10의 경우, `RDRAND`와 Padlock 백엔드를 되돌리고 제거하여 그 출력을 `/dev/random`으로 직접 전달하는 대신 야로우에 공급할 것이다. 필요한 경우 인라인 어셈블리 또는 사용자 공간에서 OpenSSL을 사용하여 하드웨어 난수 생성기, 즉 `RDRAND`, Padlock 등에 직접 액세스하는 것은 여전히 가능하지만, 우리는 더 이상 그들을 신뢰할 수 없다."work=The Registeraccess-date=2014-01-30 FreeBSD /dev/random은 포르투나를 사용하며 RDRAND는 FreeBSD 11부터 시작되었다.website=www.freebsd.org
# 보안 문제
2020년 6월 9일, 암스테르담 자유 대학교 연구원들은 여러 인텔 프로세서의 `RDRAND`에 영향을 미치는 CrossTalk(CVE-2020-0543)라는 부채널 공격을 발표했다.access-date=26 December 2020 그들은 하드웨어 디지털 난수 생성기(DRNG)의 출력이 모든 코어에서 공유되는 스테이징 버퍼에 저장된다는 것을 발견했다. 이 취약점은 영향을 받는 프로세서에서 실행되는 악성 코드가 동일한 프로세서의 다른 코어에서 실행되는 피해 응용 프로그램(인텔 SGX 엔클레이브 내에서 실행되는 응용 프로그램 포함)에서 `RDRAND` 및 `RDSEED` 명령어 결과를 읽을 수 있도록 허용했다. 연구원들은 단 한 번의 서명 작업 후에 별도의 CPU 코어에서 실행되는 SGX 엔클레이브에서 완전한 ECDSA 키를 추출하는 개념 증명 익스플로잇access-date=26 December 2020을 개발했다. 이 취약점은 공유 호스팅 환경과 같이 신뢰할 수 없는 코드가 신뢰할 수 있는 코드와 동일한 프로세서에서 함께 실행되는 시나리오에 영향을 미친다. 인텔은 CrossTalk 취약점을 특별 레지스터 버퍼 데이터 샘플링(SRBDS)이라고 부른다. 연구 결과에 따라 인텔은 이 문제를 완화하기 위한 마이크로코드 업데이트를 발표했다. 업데이트된 마이크로코드는 민감한 작업(특히 `RDRAND`, `RDSEED`, `EGETKEY` 명령어)이 완료되고 스테이징 버퍼가 덮어씌워질 때까지 코어 외부 액세스가 지연되도록 보장한다.access-date=26 December 2020 SRBDS 공격은 MSR을 읽는 것과 같은 다른 명령어에도 영향을 미치지만, 인텔은 성능 문제와 해당 명령어 결과의 기밀성 필요성이 적다는 이유로 추가 보안 보호를 적용하지 않았다. 2012년에서 2019년 사이에 출시된 광범위한 인텔 프로세서(데스크탑, 모바일, 서버 프로세서 포함)가 영향을 받았다.publisher=인텔language=en 완화 자체는 영향을 받는 명령어 사용 시 성능에 부정적인 영향을 미쳤는데, 특히 멀티 스레드 응용 프로그램에서 병렬로 실행될 때 보안 검사로 인한 지연 시간 증가와 코어 간 영향을 받는 명령어의 효과적인 직렬화로 인해 더욱 그러했다. 인텔은 각 논리 프로세서의 `IA32_MCU_OPT_CTRL` MSR을 통해 구성할 수 있는 옵트아웃 옵션을 도입하여 SGX 엔클레이브 외부에서 실행되는 명령에 대한 추가 보안 검사를 비활성화함으로써 성능을 향상시켰다.
# 내용주
Notelist