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를 사용하여 10⁷개의 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]

보안 문제

 일시적 실행 CPU 취약점 문서를 참고하십시오.

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]

같이 보기

• AES-NI
• 불런 (암호화 프로그램)
• WolfSSL

내용주

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