RDRAND
RDRAND("read random"의 약자)는 인텔 온칩 하드웨어 난수 생성기에서 난수를 반환하는 명령어로, 온칩 엔트로피 소스에 의해 시드된다.[1] 또한 인텔 시큐어 키 기술로도 알려져 있으며,[2] 코드명은 불 마운틴이다.[3] 인텔은 2012년경 이 기능을 도입했으며, AMD는 2015년 6월에 이 명령어에 대한 지원을 추가했다. (RDRAND는 아이비브리지 프로세서에서 사용할 수 있으며[a] 인텔 64 및 IA-32 명령어 집합 아키텍처의 일부이다.) [5]
이 난수 생성기는 NIST SP 800-90A,[6] FIPS 140-2, ANSI X9.82와 같은 보안 및 암호화 표준을 준수한다.[1] 인텔은 또한 2012년 암호화 연구소(Cryptography Research Inc.)에 난수 생성기 검토를 요청했으며, 그 결과 "인텔 아이비브리지 디지털 난수 생성기 분석"이라는 논문이 나왔다.[7]
RDSEED는 RDRAND와 유사하며 엔트로피 생성 하드웨어에 대한 하위 수준 액세스를 제공한다. RDSEED 생성기 및 프로세서 명령어 rdseed는 인텔 브로드웰 CPU[8] 및 AMD 젠 CPU에서 사용할 수 있다.[9]
개요
[편집]CPUID 명령어는 AMD 및 인텔 CPU에서 RDRAND 명령어 지원 여부를 확인하는 데 사용할 수 있다. 지원되는 경우 CPUID 표준 함수 01H 호출 후 ECX 레지스터의 비트 30이 설정된다.[10] AMD 프로세서는 동일한 테스트를 사용하여 이 기능을 확인한다.[11] RDSEED 가용성은 인텔 CPU에서 비슷한 방식으로 확인할 수 있다. RDSEED가 지원되는 경우 CPUID 표준 함수 07H 호출 후 EBX 레지스터의 비트 18이 설정된다.[12]
RDRAND의 연산 코드는 0x0F 0xC7이며, 그 뒤에 대상 레지스터를 지정하고 64비트 모드에서 REX 접두사와 선택적으로 결합되는 ModRM 바이트가 온다.[13]
인텔 시큐어 키는 RDRAND 명령어와 기본 난수 생성기 (RNG) 하드웨어 구현[1]에 대한 인텔의 명칭으로, 개발 중에는 "불 마운틴"이라는 코드명을 가졌다.[14] 인텔은 그들의 RNG를 "디지털 난수 생성기" 또는 DRNG라고 부른다. 이 생성기는 하드웨어 엔트로피 소스에서 생성된 256비트 원시 엔트로피 샘플 쌍을 가져와 고급 암호화 표준 (AES) (CBC-MAC 모드) 조건자에 적용하여 단일 256비트 조건화된 엔트로피 샘플로 줄인다. NIST SP 800-90A에 정의된 CTR DRBG라는 결정론적 난수 생성기는 조건자의 출력으로 시드되어 RDRAND 명령어를 통해 요청하는 응용 프로그램에 암호학적으로 안전한 난수를 제공한다.[1][14] 하드웨어는 시드 값을 변경하기 전에 최대 511개의 128비트 샘플을 발행한다. RDSEED 연산을 사용하면 AES-CBC-MAC에서 조건화된 256비트 샘플에 액세스할 수 있다.
RDSEED 명령어는 브로드웰 CPU에서 사용 가능한 다른 유사 난수 생성기를 시드하기 위해 인텔 시큐어 키에 추가되었다.[15] RDSEED 명령어의 엔트로피 소스는 자체 타이밍 회로에서 비동기적으로 실행되며 실리콘 내의 열 잡음을 사용하여 초당 3 GHz의 속도로 임의의 비트 스트림을 출력한다.[16] 이는 RDRAND에서 얻을 수 있는 유효 초당 6.4 기가비트보다 느리다(두 속도 모두 모든 코어와 스레드 간에 공유된다).[17] RDSEED 명령어는 임의의 너비의 소프트웨어 유사난수 생성기를 시드하는 데 사용되는 반면, RDRAND는 단순히 고품질 난수를 요구하는 응용 프로그램에 사용된다. 암호화 보안이 필요하지 않은 경우 Xorshift와 같은 소프트웨어 PRNG가 일반적으로 더 빠르다.[18]
성능
[편집]인텔 코어 i7-7700K, 4500 MHz (45 × 100 MHz) 프로세서(카비레이크 마이크로아키텍처)에서 단일 RDRAND 또는 RDSEED 명령어는 피연산자 크기(16/32/64 비트)에 관계없이 110 ns, 즉 463 클럭 사이클이 소요된다. 이 클럭 사이클 수는 스카이레이크 또는 카비레이크 마이크로아키텍처를 사용하는 모든 프로세서에 적용된다. 실버몬트 마이크로아키텍처 프로세서에서는 각 명령어가 피연산자 크기에 관계없이 약 1472 클럭 사이클이 소요되며, 아이비브리지 프로세서에서는 RDRAND가 최대 117 클럭 사이클이 소요된다.[19]
AMD 라이젠 CPU에서 각 명령어는 16비트 또는 32비트 피연산자의 경우 약 1200 클럭 사이클, 64비트 피연산자의 경우 약 2500 클럭 사이클이 소요된다.[19]
천체 물리학 몬테카를로 시뮬레이터는 쿼드 코어 인텔 i7-3740 QM 프로세서에서 RDRAND를 사용하여 107개의 64비트 난수를 생성하는 시간을 조사했다. 그들은 RDRAND의 C 구현이 C의 기본 난수 생성기보다 약 2배 느리고, 메르센 트위스터보다 약 20배 느리게 실행된다는 것을 발견했다. RDRAND의 파이썬 모듈이 구축되었지만, 파이썬의 기본 난수 생성기보다 20배 느리다는 것이 밝혀졌다.[20] 단, 유사난수와 CSPRNG 사이의 성능 비교는 할 수 없다.
2020년 6월 인텔이 발표한 마이크로코드 업데이트는 CrossTalk 취약점(아래 보안 문제 섹션 참조)을 완화하기 위해 설계되었으며, 추가 보안 제어로 인해 RDRAND 및 RDSEED의 성능에 부정적인 영향을 미친다. 완화 조치가 적용된 프로세서에서는 각 영향을 받는 명령어에 추가 지연 시간이 발생하고 코어 간 RDRAND 또는 RDSEED의 동시 실행이 효과적으로 직렬화된다. 인텔은 이러한 보안 검사를 완화하여 대부분의 시나리오에서 성능 영향을 줄이는 메커니즘을 도입했지만, 인텔 프로세서는 기본적으로 이 보안 완화를 적용하지 않는다.[21]
컴파일러
[편집]비주얼 C++ 2015는 RDRAND 및 RDSEED 함수에 대한 내재적 래퍼 지원을 제공한다.[22] GCC 4.6+ 및 클랭 3.2+는 플래그에 -mrdrnd가 지정되었을 때 RDRAND에 대한 내장 함수를 제공하며,[23] 또한 __RDRND__를 설정하여 조건부 컴파일을 허용한다. 최신 버전은 immintrin.h를 추가로 제공하여 이러한 내장 함수를 인텔 C 컴파일러 버전 12.1+와 호환되는 함수로 래핑한다. 이 함수들은 매개변수가 가리키는 위치에 임의의 데이터를 쓰고 성공 시 1을 반환한다.[24]
응용 프로그램
[편집]OpenSSL에서 RDRAND 및 RDSEED를 사용하여 암호학적으로 안전한 난수를 생성하는 것은 통신 보안을 돕는 하나의 옵션이다.
몬테카를로 시뮬레이터에서 RDRAND의 과학적 적용이 성능 및 재현성을 중심으로 다른 난수 생성기와 비교하여 평가되었다. 그 결과 메르센 트위스터 대신 RDRAND를 사용하는 것이 다른 결과를 제공하지 않지만 성능 및 재현성 측면에서 더 나쁘다는 결론이 나왔다.[25][20]
반응
[편집]2013년 9월, 뉴욕 타임스의 NSA가 암호화를 약화시키려는 노력을 폭로하는 기사[26]에 대한 응답으로, 시어도어 초는 리눅스 커널의 /dev/random에 RDRAND를 사용하는 것에 대해 다음과 같이 공개적으로 게시했다.[27]
나는 인텔 엔지니어들이
/dev/random이RDRAND명령어에만 의존하도록 압력을 가했을 때 저항했던 것이 정말 기쁘다. [뉴욕 타임스 기사[26]]에서 인용하자면: "올해까지 SIGINT 이네이블링 프로젝트는 칩 제조사와 협력하여 백도어를 삽입하는 방식으로 기업 및 정부를 위한 정보 암호화 칩 내부에 침투할 방법을 찾았다..." 감사 불가능한 칩 내부에 봉인된 구현을 사용하는 하드웨어 난수 생성기에만 의존하는 것은 나쁜 생각이다.
리누스 토르발스는 리눅스 커널에서 RDRAND 사용에 대한 우려를 일축하며, /dev/random의 유일한 엔트로피 소스로 사용되지 않고, RDRAND에서 받은 값과 다른 무작위성 소스를 결합하여 엔트로피를 향상시키는 데 사용된다고 지적했다.[28][29] 그러나 디퓨즈 시큐리티의 테일러 혼비는 RDRAND 명령어에 백도어가 도입되어 이를 사용하는 코드를 특별히 표적으로 삼는 경우 리눅스 난수 생성기가 불안정해질 수 있음을 입증했다. 혼비의 개념 증명 구현은 버전 3.13 이전의 수정되지 않은 리눅스 커널에서 작동한다.[30][31][32] 이 문제는 2013년 리눅스 커널에서 완화되었다.[33]
개발자들은 FreeBSD 커널을 RDRAND와 VIA PadLock을 직접 사용하는 방식에서 다음과 같은 주석과 함께 변경했다. "FreeBSD 10의 경우, RDRAND와 Padlock 백엔드를 되돌리고 제거하여 그 출력을 /dev/random으로 직접 전달하는 대신 야로우에 공급할 것이다. 필요한 경우 인라인 어셈블리 또는 사용자 공간에서 OpenSSL을 사용하여 하드웨어 난수 생성기, 즉 RDRAND, Padlock 등에 직접 액세스하는 것은 여전히 가능하지만, 우리는 더 이상 그들을 신뢰할 수 없다."[28][34] FreeBSD /dev/random은 포르투나를 사용하며 RDRAND는 FreeBSD 11부터 시작되었다.[35]
보안 문제
[편집]2020년 6월 9일, 암스테르담 자유 대학교 연구원들은 여러 인텔 프로세서의 RDRAND에 영향을 미치는 CrossTalk(CVE-2020-0543)라는 부채널 공격을 발표했다.[36] 그들은 하드웨어 디지털 난수 생성기(DRNG)의 출력이 모든 코어에서 공유되는 스테이징 버퍼에 저장된다는 것을 발견했다. 이 취약점은 영향을 받는 프로세서에서 실행되는 악성 코드가 동일한 프로세서의 다른 코어에서 실행되는 피해 응용 프로그램(인텔 SGX 엔클레이브 내에서 실행되는 응용 프로그램 포함)에서 RDRAND 및 RDSEED 명령어 결과를 읽을 수 있도록 허용했다.[36] 연구원들은 단 한 번의 서명 작업 후에 별도의 CPU 코어에서 실행되는 SGX 엔클레이브에서 완전한 ECDSA 키를 추출하는 개념 증명 익스플로잇[37]을 개발했다.[36] 이 취약점은 공유 호스팅 환경과 같이 신뢰할 수 없는 코드가 신뢰할 수 있는 코드와 동일한 프로세서에서 함께 실행되는 시나리오에 영향을 미친다.
인텔은 CrossTalk 취약점을 특별 레지스터 버퍼 데이터 샘플링(SRBDS)이라고 부른다. 연구 결과에 따라 인텔은 이 문제를 완화하기 위한 마이크로코드 업데이트를 발표했다. 업데이트된 마이크로코드는 민감한 작업(특히 RDRAND, RDSEED, EGETKEY 명령어)이 완료되고 스테이징 버퍼가 덮어씌워질 때까지 코어 외부 액세스가 지연되도록 보장한다.[21] SRBDS 공격은 MSR을 읽는 것과 같은 다른 명령어에도 영향을 미치지만, 인텔은 성능 문제와 해당 명령어 결과의 기밀성 필요성이 적다는 이유로 추가 보안 보호를 적용하지 않았다.[21] 2012년에서 2019년 사이에 출시된 광범위한 인텔 프로세서(데스크탑, 모바일, 서버 프로세서 포함)가 영향을 받았다.[38][39] 완화 자체는 영향을 받는 명령어 사용 시 성능에 부정적인 영향을 미쳤는데, 특히 멀티 스레드 응용 프로그램에서 병렬로 실행될 때 보안 검사로 인한 지연 시간 증가와 코어 간 영향을 받는 명령어의 효과적인 직렬화로 인해 더욱 그러했다. 인텔은 각 논리 프로세서의 IA32_MCU_OPT_CTRL MSR을 통해 구성할 수 있는 옵트아웃 옵션을 도입하여 SGX 엔클레이브 외부에서 실행되는 명령에 대한 추가 보안 검사를 비활성화함으로써 성능을 향상시켰다.[21]
같이 보기
[편집]내용주
[편집]각주
[편집]- ↑ 가 나 다 라 “Intel Digital Random Number Generator (DRNG): Software Implementation Guide, Revision 1.1” (PDF). 인텔 코퍼레이션. 2012년 8월 7일. 2012년 11월 25일에 확인함.
- ↑ “What is Intel® Secure Key Technology?” (영어). 《Intel》. 2020년 9월 23일에 확인함.
- ↑ Hofemeier, Gael (2011년 6월 22일). “Find out about Intel's new RDRAND Instruction.”. 《Intel Developer Zone Blogs》. 2013년 12월 30일에 확인함.
- ↑ 《Desktop 3rd Generation Intel Core Processor Family, Specification Update》 (PDF). Intel Corporation. January 2013.
- ↑ “AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions” (PDF). 《AMD Developer Guides, Manuals & ISA Documents》. June 2015. 2015년 10월 16일에 확인함.
- ↑ 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일에 확인함.
- ↑ 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일에 확인함.
- ↑ Hofemeier, Gael (2012년 7월 26일). “Introduction to Intel AES-NI and Intel SecureKey Instructions”. 《Intel Developer Zone》. Intel. 2015년 10월 24일에 확인함.
- ↑ “AMD Starts Linux Enablement On Next-Gen "Zen" Architecture - Phoronix”. 《www.phoronix.com》. 2015년 10월 25일에 확인함.
- ↑ “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
- ↑ “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
- ↑ “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
- ↑ “Intel® Digital Random Number Generator (DRNG) Software Implementation Guide”. Software.intel.com. 2014년 1월 30일에 확인함.
- ↑ 가 나 Taylor, Greg; Cox, George (September 2011). 《Behind Intel's New Random-Number Generator》. 《IEEE 스펙트럼》. 2011년 9월 6일에 원본 문서에서 보존된 문서.
- ↑ John Mechalas (November 2012). “The Difference Between RDRAND and RDSEED”. 《software.intel.com》. Intel Corporation. 2014년 1월 1일에 확인함.
- ↑ Mechalas, John. “Intel Digital Random Number Generator (DRNG) Software Implementation Guide, Section 3.2.1 Entropy Source (ES)”. 《Intel Software》. Intel. 2015년 2월 18일에 확인함.
- ↑ 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.
- ↑ 가장 간단한 64비트 Xorshift 구현은 3개의 XOR과 3개의 시프트를 가지고 있다. 만약 이것들이 2 GHz에서 4개의 코어에서 긴 루프로 실행된다면, 처리량은 80 Gb/s가 된다. 실제로는 로드/스토어 오버헤드 등으로 인해 더 적겠지만, 여전히
RDRAND의 6.4 Gb/s를 초과할 가능성이 높다. 반면에,RDRAND의 숫자 품질은 Xorshift와 같은 소프트웨어 PRNG보다 높을 것이다. - ↑ 가 나 “Instruction tables - Lists of instruction latencies, throughputs and micro-operation breakdown for Intel and AMD CPU's” (PDF). 2006년 8월 8일에 원본 문서 (PDF)에서 보존된 문서.
- ↑ 가 나 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.
- ↑ 가 나 다 라 “Special Register Buffer Data Sampling”. 《Intel》. 2020년 12월 26일에 확인함.
- ↑ “x86 intrinsics list”. 《docs.microsoft.com》. 2020년 2월 28일. 2020년 5월 7일에 확인함.
- ↑ “X86 Built-in Functions - Using the GNU Compiler Collection (GCC)”.
- ↑ “Intel® C++ Compiler 19.1 Developer Guide and Reference”. 2019년 12월 23일.
- ↑ 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.
- ↑ 가 나 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일에 확인함.
- ↑ Ts'o, Theodore (2013년 9월 6일). “I am so glad I resisted pressure from Intel engineers to let /dev/random rely...”. 2018년 6월 11일에 원본 문서에서 보존된 문서.
- ↑ 가 나 Richard Chirgwin (2013년 12월 9일). “FreeBSD abandoning hardware randomness”. 《The Register》.
- ↑ Gavin Clarke (2013년 9월 10일). “Torvalds shoots down call to yank 'backdoored' Intel RDRAND in Linux crypto”. theregister.co.uk. 2014년 3월 12일에 확인함.
- ↑ 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일에 확인함. - ↑ 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일에 확인함.
- ↑ Daniel J. Bernstein; Tanja Lange (2014년 5월 16일). “Randomness generation” (PDF). 2015년 4월 9일에 확인함.
- ↑ Ts'o, Theodore (2013년 10월 10일). “random: mix in architectural randomness earlier in extract_buf()” (영어). 《GitHub》. 2021년 7월 30일에 확인함.
- ↑ “FreeBSD Quarterly Status Report”. Freebsd.org. 2014년 1월 30일에 확인함.
- ↑ “random(4)”. 《www.freebsd.org》. 2020년 9월 25일에 확인함.
- ↑ 가 나 다 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일에 확인함.
- ↑ “VUSec RIDL cpuid_leak PoC, modified to leak rdrand output”. 《GitHub》. 2020년 12월 26일에 확인함.
- ↑ “Processors Affected: Special Register Buffer Data Sampling”. 《Intel Developer Zone》. 인텔. 2021년 3월 4일에 원본 문서에서 보존된 문서. 2020년 12월 26일에 확인함.
- ↑ “Processors Affected: Special Register Buffer Data Sampling” (영어). 《Intel》. 2025년 5월 18일에 원본 문서에서 보존된 문서. 2025년 5월 18일에 확인함.