RDRAND

RDRAND("read random"의 약자)는 인텔 온칩 하드웨어 난수 생성기에서 난수를 반환하는 명령어로, 온칩 엔트로피 소스에 의해 시드된다. 또한 인텔 시큐어 키 기술로도 알려져 있으며, 코드명은 불 마운틴이다. 인텔은 2012년경 이 기능을 도입했으며, AMD는 2015년 6월에 이 명령어에 대한 지원을 추가했다. (RDRAND는 아이비브리지 프로세서에서 사용할 수 있으며 인텔 64 및 IA-32 명령어 집합 아키텍처의 일부이다.)

이 난수 생성기는 NIST SP 800-90A, FIPS 140-2, ANSI X9.82와 같은 보안 및 암호화 표준을 준수한다. 인텔은 또한 2012년 암호화 연구소(Cryptography Research Inc.)에 난수 생성기 검토를 요청했으며, 그 결과 "인텔 아이비브리지 디지털 난수 생성기 분석"이라는 논문이 나왔다.

RDSEED는 RDRAND와 유사하며 엔트로피 생성 하드웨어에 대한 하위 수준 액세스를 제공한다. RDSEED 생성기 및 프로세서 명령어 rdseed는 인텔 브로드웰 CPU 및 AMD 젠 CPU에서 사용할 수 있다.

개요

CPUID 명령어는 AMD 및 인텔 CPU에서 RDRAND 명령어 지원 여부를 확인하는 데 사용할 수 있다. 지원되는 경우 CPUID 표준 함수 01H 호출 후 ECX 레지스터의 비트 30이 설정된다. AMD 프로세서는 동일한 테스트를 사용하여 이 기능을 확인한다. RDSEED 가용성은 인텔 CPU에서 비슷한 방식으로 확인할 수 있다. RDSEED가 지원되는 경우 CPUID 표준 함수 07H 호출 후 EBX 레지스터의 비트 18이 설정된다.

RDRAND의 연산 코드는 0x0F 0xC7이며, 그 뒤에 대상 레지스터를 지정하고 64비트 모드에서 REX 접두사와 선택적으로 결합되는 ModRM 바이트가 온다.

인텔 시큐어 키는 RDRAND 명령어와 기본 난수 생성기 (RNG) 하드웨어 구현에 대한 인텔의 명칭으로, 개발 중에는 "불 마운틴"이라는 코드명을 가졌다. 인텔은 그들의 RNG를 "디지털 난수 생성기" 또는 DRNG라고 부른다. 이 생성기는 하드웨어 엔트로피 소스에서 생성된 256비트 원시 엔트로피 샘플 쌍을 가져와 고급 암호화 표준 (AES) (CBC-MAC 모드) 조건자에 적용하여 단일 256비트 조건화된 엔트로피 샘플로 줄인다. NIST SP 800-90A에 정의된 CTR DRBG라는 결정론적 난수 생성기는 조건자의 출력으로 시드되어 RDRAND 명령어를 통해 요청하는 응용 프로그램에 암호학적으로 안전한 난수를 제공한다. 하드웨어는 시드 값을 변경하기 전에 최대 511개의 128비트 샘플을 발행한다. RDSEED 연산을 사용하면 AES-CBC-MAC에서 조건화된 256비트 샘플에 액세스할 수 있다.

RDSEED 명령어는 브로드웰 CPU에서 사용 가능한 다른 유사 난수 생성기를 시드하기 위해 인텔 시큐어 키에 추가되었다. RDSEED 명령어의 엔트로피 소스는 자체 타이밍 회로에서 비동기적으로 실행되며 실리콘 내의 열 잡음을 사용하여 초당 3 GHz의 속도로 임의의 비트 스트림을 출력한다. 이는 RDRAND에서 얻을 수 있는 유효 초당 6.4 기가비트보다 느리다(두 속도 모두 모든 코어와 스레드 간에 공유된다). RDSEED 명령어는 임의의 너비의 소프트웨어 유사난수 생성기를 시드하는 데 사용되는 반면, RDRAND는 단순히 고품질 난수를 요구하는 응용 프로그램에 사용된다. 암호화 보안이 필요하지 않은 경우 Xorshift와 같은 소프트웨어 PRNG가 일반적으로 더 빠르다.

성능

인텔 코어 i7-7700K, 4500 MHz (45 × 100 MHz) 프로세서(카비레이크 마이크로아키텍처)에서 단일 RDRAND 또는 RDSEED 명령어는 피연산자 크기(16/32/64 비트)에 관계없이 110 ns, 즉 463 클럭 사이클이 소요된다. 이 클럭 사이클 수는 스카이레이크 또는 카비레이크 마이크로아키텍처를 사용하는 모든 프로세서에 적용된다. 실버몬트 마이크로아키텍처 프로세서에서는 각 명령어가 피연산자 크기에 관계없이 약 1472 클럭 사이클이 소요되며, 아이비브리지 프로세서에서는 RDRAND가 최대 117 클럭 사이클이 소요된다.

AMD 라이젠 CPU에서 각 명령어는 16비트 또는 32비트 피연산자의 경우 약 1200 클럭 사이클, 64비트 피연산자의 경우 약 2500 클럭 사이클이 소요된다.

천체 물리학 몬테카를로 시뮬레이터는 쿼드 코어 인텔 i7-3740 QM 프로세서에서 RDRAND를 사용하여 107개의 64비트 난수를 생성하는 시간을 조사했다. 그들은 RDRAND의 C 구현이 C의 기본 난수 생성기보다 약 2배 느리고, 메르센 트위스터보다 약 20배 느리게 실행된다는 것을 발견했다. RDRAND의 파이썬 모듈이 구축되었지만, 파이썬의 기본 난수 생성기보다 20배 느리다는 것이 밝혀졌다. 단, 유사난수와 CSPRNG 사이의 성능 비교는 할 수 없다.

2020년 6월 인텔이 발표한 마이크로코드 업데이트는 CrossTalk 취약점(아래 보안 문제 섹션 참조)을 완화하기 위해 설계되었으며, 추가 보안 제어로 인해 RDRAND 및 RDSEED의 성능에 부정적인 영향을 미친다. 완화 조치가 적용된 프로세서에서는 각 영향을 받는 명령어에 추가 지연 시간이 발생하고 코어 간 RDRAND 또는 RDSEED의 동시 실행이 효과적으로 직렬화된다. 인텔은 이러한 보안 검사를 완화하여 대부분의 시나리오에서 성능 영향을 줄이는 메커니즘을 도입했지만, 인텔 프로세서는 기본적으로 이 보안 완화를 적용하지 않는다.

컴파일러

비주얼 C++ 2015는 RDRAND 및 RDSEED 함수에 대한 내재적 래퍼 지원을 제공한다. GCC 4.6+ 및 클랭 3.2+는 플래그에 -mrdrnd가 지정되었을 때 RDRAND에 대한 내장 함수를 제공하며, 또한 __RDRND__를 설정하여 조건부 컴파일을 허용한다. 최신 버전은 immintrin.h를 추가로 제공하여 이러한 내장 함수를 인텔 C 컴파일러 버전 12.1+와 호환되는 함수로 래핑한다. 이 함수들은 매개변수가 가리키는 위치에 임의의 데이터를 쓰고 성공 시 1을 반환한다.

응용 프로그램

OpenSSL에서 RDRAND 및 RDSEED를 사용하여 암호학적으로 안전한 난수를 생성하는 것은 통신 보안을 돕는 하나의 옵션이다.

몬테카를로 시뮬레이터에서 RDRAND의 과학적 적용이 성능 및 재현성을 중심으로 다른 난수 생성기와 비교하여 평가되었다. 그 결과 메르센 트위스터 대신 RDRAND를 사용하는 것이 다른 결과를 제공하지 않지만 성능 및 재현성 측면에서 더 나쁘다는 결론이 나왔다.

반응

2013년 9월, 뉴욕 타임스의 NSA가 암호화를 약화시키려는 노력을 폭로하는 기사에 대한 응답으로, 시어도어 초는 리눅스 커널의 /dev/random에 RDRAND를 사용하는 것에 대해 다음과 같이 공개적으로 게시했다.

나는 인텔 엔지니어들이 /dev/random이 RDRAND 명령어에만 의존하도록 압력을 가했을 때 저항했던 것이 정말 기쁘다. [뉴욕 타임스 기사]에서 인용하자면: "올해까지 SIGINT 이네이블링 프로젝트는 칩 제조사와 협력하여 백도어를 삽입하는 방식으로 기업 및 정부를 위한 정보 암호화 칩 내부에 침투할 방법을 찾았다..." 감사 불가능한 칩 내부에 봉인된 구현을 사용하는 하드웨어 난수 생성기에만 의존하는 것은 나쁜 생각이다.

리누스 토르발스는 리눅스 커널에서 RDRAND 사용에 대한 우려를 일축하며, /dev/random의 유일한 엔트로피 소스로 사용되지 않고, RDRAND에서 받은 값과 다른 무작위성 소스를 결합하여 엔트로피를 향상시키는 데 사용된다고 지적했다. 그러나 디퓨즈 시큐리티의 테일러 혼비는 RDRAND 명령어에 백도어가 도입되어 이를 사용하는 코드를 특별히 표적으로 삼는 경우 리눅스 난수 생성기가 불안정해질 수 있음을 입증했다. 혼비의 개념 증명 구현은 버전 3.13 이전의 수정되지 않은 리눅스 커널에서 작동한다. 이 문제는 2013년 리눅스 커널에서 완화되었다.

개발자들은 FreeBSD 커널을 RDRAND와 VIA PadLock을 직접 사용하는 방식에서 다음과 같은 주석과 함께 변경했다. "FreeBSD 10의 경우, RDRAND와 Padlock 백엔드를 되돌리고 제거하여 그 출력을 /dev/random으로 직접 전달하는 대신 야로우에 공급할 것이다. 필요한 경우 인라인 어셈블리 또는 사용자 공간에서 OpenSSL을 사용하여 하드웨어 난수 생성기, 즉 RDRAND, Padlock 등에 직접 액세스하는 것은 여전히 가능하지만, 우리는 더 이상 그들을 신뢰할 수 없다." FreeBSD /dev/random은 포르투나를 사용하며 RDRAND는 FreeBSD 11부터 시작되었다.

보안 문제

2020년 6월 9일, 암스테르담 자유 대학교 연구원들은 여러 인텔 프로세서의 RDRAND에 영향을 미치는 CrossTalk(CVE-2020-0543)라는 부채널 공격을 발표했다. 그들은 하드웨어 디지털 난수 생성기(DRNG)의 출력이 모든 코어에서 공유되는 스테이징 버퍼에 저장된다는 것을 발견했다. 이 취약점은 영향을 받는 프로세서에서 실행되는 악성 코드가 동일한 프로세서의 다른 코어에서 실행되는 피해 응용 프로그램(인텔 SGX 엔클레이브 내에서 실행되는 응용 프로그램 포함)에서 RDRAND 및 RDSEED 명령어 결과를 읽을 수 있도록 허용했다. 연구원들은 단 한 번의 서명 작업 후에 별도의 CPU 코어에서 실행되는 SGX 엔클레이브에서 완전한 ECDSA 키를 추출하는 개념 증명 익스플로잇을 개발했다. 이 취약점은 공유 호스팅 환경과 같이 신뢰할 수 없는 코드가 신뢰할 수 있는 코드와 동일한 프로세서에서 함께 실행되는 시나리오에 영향을 미친다.

인텔은 CrossTalk 취약점을 특별 레지스터 버퍼 데이터 샘플링(SRBDS)이라고 부른다. 연구 결과에 따라 인텔은 이 문제를 완화하기 위한 마이크로코드 업데이트를 발표했다. 업데이트된 마이크로코드는 민감한 작업(특히 RDRAND, RDSEED, EGETKEY 명령어)이 완료되고 스테이징 버퍼가 덮어씌워질 때까지 코어 외부 액세스가 지연되도록 보장한다. SRBDS 공격은 MSR을 읽는 것과 같은 다른 명령어에도 영향을 미치지만, 인텔은 성능 문제와 해당 명령어 결과의 기밀성 필요성이 적다는 이유로 추가 보안 보호를 적용하지 않았다. 2012년에서 2019년 사이에 출시된 광범위한 인텔 프로세서(데스크탑, 모바일, 서버 프로세서 포함)가 영향을 받았다. 완화 자체는 영향을 받는 명령어 사용 시 성능에 부정적인 영향을 미쳤는데, 특히 멀티 스레드 응용 프로그램에서 병렬로 실행될 때 보안 검사로 인한 지연 시간 증가와 코어 간 영향을 받는 명령어의 효과적인 직렬화로 인해 더욱 그러했다. 인텔은 각 논리 프로세서의 IA32_MCU_OPT_CTRL MSR을 통해 구성할 수 있는 옵트아웃 옵션을 도입하여 SGX 엔클레이브 외부에서 실행되는 명령에 대한 추가 보안 검사를 비활성화함으로써 성능을 향상시켰다.

같이 보기

내용주

  1. ↑ 일부 아이비브리지 버전에서는 버그로 인해 RDRAND 명령어가 잘못된 명령어 예외를 발생시킨다.

각주

  1. 1 2 3 4 “Intel Digital Random Number Generator (DRNG): Software Implementation Guide, Revision 1.1” (PDF). 인텔 코퍼레이션. 2012년 8월 7일. 2012년 11월 25일에 확인함.
  2. ↑ “What is Intel® Secure Key Technology?” (영어). 《Intel》. 2020년 9월 23일에 확인함.
  3. ↑ Hofemeier, Gael (2011년 6월 22일). “Find out about Intel's new RDRAND Instruction.”. 《Intel Developer Zone Blogs》. 2013년 12월 30일에 확인함.
  4. ↑ 《Desktop 3rd Generation Intel Core Processor Family, Specification Update》 (PDF). Intel Corporation. January 2013.
  5. ↑ “AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions” (PDF). 《AMD Developer Guides, Manuals & ISA Documents》. June 2015. 2015년 10월 16일에 확인함.
  6. ↑ Barker, Elaine; Kelsey, John (January 2012). 《Recommendation for Random Number Generation Using Deterministic Random Bit Generators》 (PDF). 미국 국립표준기술연구소. doi:10.6028/NIST.SP.800-90A. 2013년 9월 16일에 확인함.
  7. ↑ Hamburg, Mike; Kocher, Paul; Marson, Mark (2012년 3월 12일). “Analysis of Intel's Ivy Bridge Digital Random Number Generator” (PDF). 《Cryptography Research, Inc.》. 2014년 12월 30일에 원본 문서 (PDF)에서 보존된 문서. 2015년 8월 21일에 확인함.
  8. ↑ Hofemeier, Gael (2012년 7월 26일). “Introduction to Intel AES-NI and Intel SecureKey Instructions”. 《Intel Developer Zone》. Intel. 2015년 10월 24일에 확인함.
  9. ↑ “AMD Starts Linux Enablement On Next-Gen "Zen" Architecture - Phoronix”. 《www.phoronix.com》. 2015년 10월 25일에 확인함.
  10. ↑ “Volume 1, Section 7.3.17, 'Random Number Generator Instruction'” (PDF). 《Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B and 3C》. Intel Corporation. June 2013. 177쪽. 2013년 6월 24일에 확인함. All Intel processors that support the RDRAND instruction indicate the availability of the RDRAND instruction via reporting CPUID.01H:ECX.RDRAND[bit 30] = 1
  11. ↑ “AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions” (PDF). AMD. June 2015. 278쪽. 2015년 10월 15일에 확인함. Support for the RDRAND instruction is optional. On processors that support the instruction, CPUID Fn0000_0001_ECX[RDRAND] = 1
  12. ↑ “Volume 1, Section 7.3.17, 'Random Number Generator Instruction'” (PDF). 《Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B and 3C》. Intel Corporation. June 2013. 177쪽. 2015년 10월 25일에 확인함. 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
  13. ↑ “Intel® Digital Random Number Generator (DRNG) Software Implementation Guide”. Software.intel.com. 2014년 1월 30일에 확인함.
  14. 1 2 Taylor, Greg; Cox, George (September 2011). 《Behind Intel's New Random-Number Generator》. 《IEEE 스펙트럼》. 2011년 9월 6일에 원본 문서에서 보존된 문서.
  15. ↑ John Mechalas (November 2012). “The Difference Between RDRAND and RDSEED”. 《software.intel.com》. Intel Corporation. 2014년 1월 1일에 확인함.
  16. ↑ Mechalas, John. “Intel Digital Random Number Generator (DRNG) Software Implementation Guide, Section 3.2.1 Entropy Source (ES)”. 《Intel Software》. Intel. 2015년 2월 18일에 확인함.
  17. ↑ 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.
  18. ↑ 가장 간단한 64비트 Xorshift 구현은 3개의 XOR과 3개의 시프트를 가지고 있다. 만약 이것들이 2 GHz에서 4개의 코어에서 긴 루프로 실행된다면, 처리량은 80 Gb/s가 된다. 실제로는 로드/스토어 오버헤드 등으로 인해 더 적겠지만, 여전히 RDRAND의 6.4 Gb/s를 초과할 가능성이 높다. 반면에, RDRAND의 숫자 품질은 Xorshift와 같은 소프트웨어 PRNG보다 높을 것이다.
  19. 1 2 “Instruction tables - Lists of instruction latencies, throughputs and micro-operation breakdown for Intel and AMD CPU's” (PDF). 2006년 8월 8일에 원본 문서 (PDF)에서 보존된 문서.
  20. 1 2 Route, Matthew (2017년 8월 10일). 《Radio-flaring Ultracool Dwarf Population Synthesis》. 《The Astrophysical Journal》 845. 66쪽. arXiv:1707.02212. Bibcode:2017ApJ...845...66R. doi:10.3847/1538-4357/aa7ede. S2CID 118895524.
  21. 1 2 3 4 “Special Register Buffer Data Sampling”. 《Intel》. 2020년 12월 26일에 확인함.
  22. ↑ “x86 intrinsics list”. 《docs.microsoft.com》. 2020년 2월 28일. 2020년 5월 7일에 확인함.
  23. ↑ “X86 Built-in Functions - Using the GNU Compiler Collection (GCC)”.
  24. ↑ “Intel® C++ Compiler 19.1 Developer Guide and Reference”. 2019년 12월 23일.
  25. ↑ Route, Matthew (2019). 《Intel Secure Key-Powered Radio-flaring Ultracool Dwarf Population Synthesis》. 《American Astronomical Society Meeting Abstracts #234》 234 (American Astronomical Society Meeting #234, id. 207.01. Bulletin of the American Astronomical Society, Vol. 51, No. 4). Bibcode:2019AAS...23420701R.
  26. 1 2 Perlroth, Nicole; Larson, Jeff; Shane, Scott (2013년 9월 5일). “N.S.A. Able to Foil Basic Safeguards of Privacy on Web”. 《The New York Times》. 2017년 11월 15일에 확인함.
  27. ↑ Ts'o, Theodore (2013년 9월 6일). “I am so glad I resisted pressure from Intel engineers to let /dev/random rely...”. 2018년 6월 11일에 원본 문서에서 보존된 문서.
  28. 1 2 Richard Chirgwin (2013년 12월 9일). “FreeBSD abandoning hardware randomness”. 《The Register》.
  29. ↑ Gavin Clarke (2013년 9월 10일). “Torvalds shoots down call to yank 'backdoored' Intel RDRAND in Linux crypto”. theregister.co.uk. 2014년 3월 12일에 확인함.
  30. ↑ Taylor Hornby (2013년 12월 6일). “RDRAND backdoor proof of concept is working! Stock kernel (3.8.13), only the RDRAND instruction is modified.” |url= 값 확인 필요 (도움말). 2015년 4월 9일에 확인함.
  31. ↑ Taylor Hornby [DefuseSec] (2013년 9월 10일). “I wrote a short dialogue explaining why Linux's use of RDRAND is problematic. http://pastebin.com/A07q3nL3 /cc @kaepora @voodooKobra” (트윗). 2016년 1월 11일에 확인함.
  32. ↑ Daniel J. Bernstein; Tanja Lange (2014년 5월 16일). “Randomness generation” (PDF). 2015년 4월 9일에 확인함.
  33. ↑ Ts'o, Theodore (2013년 10월 10일). “random: mix in architectural randomness earlier in extract_buf()” (영어). 《GitHub》. 2021년 7월 30일에 확인함.
  34. ↑ “FreeBSD Quarterly Status Report”. Freebsd.org. 2014년 1월 30일에 확인함.
  35. ↑ “random(4)”. 《www.freebsd.org》. 2020년 9월 25일에 확인함.
  36. 1 2 3 Ragab, Hany; Milburn, Alyssa; Razavi, Kaveh; Bos, Herbert; Giuffrida, Cristiano. “CrossTalk: Speculative Data Leaks Across Cores Are Real” (PDF). 《Systems and Network Security Group, Vrije Universiteit Amsterdam (VUSec)》. 2020년 12월 26일에 확인함.
  37. ↑ “VUSec RIDL cpuid_leak PoC, modified to leak rdrand output”. 《GitHub》. 2020년 12월 26일에 확인함.
  38. ↑ “Processors Affected: Special Register Buffer Data Sampling”. 《Intel Developer Zone》. 인텔. 2021년 3월 4일에 원본 문서에서 보존된 문서. 2020년 12월 26일에 확인함.
  39. ↑ “Processors Affected: Special Register Buffer Data Sampling” (영어). 《Intel》. 2025년 5월 18일에 원본 문서에서 보존된 문서. 2025년 5월 18일에 확인함.

외부 링크