SGX는 CPU가 메모리 일부(인클레이브)를 암호화하는 것을 포함한다. 인클레이브에서 생성된 데이터와 코드는 CPU 내에서 실시간으로 복호화되어[4] 다른 코드, 즉 운영체제 및 기본 하이퍼바이저와 같은 더 높은 권한 수준에서 실행되는 코드에 의해 검사되거나 읽히는 것을 방지한다.[1][4][2] 이는 많은 종류의 공격을 완화할 수 있지만, 부채널 공격으로부터는 보호하지 못한다.[5]
2021년 인텔의 정책 변경으로 11세대 및 12세대 인텔 코어 프로세서에서 SGX가 사용 중단되었지만, 클라우드 및 엔터프라이즈용 인텔 제온에서는 계속 개발되고 있다.[6][7]
CPU의 SGX 지원은 CPUID "구조화 확장 기능 리프(Structured Extended feature Leaf)", EBX 비트 02에 표시되지만,[8] 애플리케이션에서 사용하려면 바이오스/통합 확장 펌웨어 인터페이스 지원 및 선택적 활성화가 필요하며 이는 CPUID 비트에 반영되지 않는다. 이로 인해 애플리케이션의 기능 감지 로직이 복잡해진다.[9]
SGX 에뮬레이션은 2014년에 QEMU 시스템 에뮬레이터의 실험 버전에서 추가되었다.[10] 2015년 조지아 공과대학교 연구원들은 "OpenSGX"라는 오픈 소스 시뮬레이터를 발표했다.[11]
SGX가 보안에 사용된 한 가지 예는 울프SSL의[12] 암호화 알고리즘을 위한 데모 애플리케이션이었다.
2017년 3월 27일, 오스트리아 그라츠 공과대학교의 연구원들은 세분화된 타이머 대신 특정 CPU 명령어를 사용하여 캐시DRAM 부채널을 악용함으로써 동일 시스템에서 실행되는 SGX 인클레이브로부터 RSA 키를 5분 이내에 획득할 수 있는 개념 증명을 개발했다.[19][20] 이 유형의 공격에 대한 한 가지 대응책은 2017년 USENIX 보안 심포지엄에서 다니엘 그루스 등이 발표했다.[21] 다른 공개된 대응책 중 하나로, 2017년 9월 28일에 컴파일러 기반 도구인 DR.SGX가 발표되었는데,[22] 이는 다른 제안된 솔루션의 구현 복잡성을 제거하면서도 우수한 성능을 제공한다고 주장한다.
임페리얼 칼리지 런던의 LSDS 그룹은 스펙터 투기적 실행 보안 취약점을 안전한 인클레이브 공격에 적용할 수 있다는 개념 증명을 제시했다.[23] 2018년 8월에 공개된 포어섀도 공격은 투기적 실행과 버퍼 오버플로를 결합하여 SGX를 우회한다.[24] L1 터미널 폴트라고도 불리는 이 공격에 대한 보안 권고 및 완화책은 원래 2018년 8월 14일에 발표되었고 2021년 5월 11일에 업데이트되었다.[25]
인클레이브 공격
2019년 2월 8일, 오스트리아 그라츠 공과대학교 연구원들은 일부 경우 인클레이브 자체 내에서 악성 코드를 실행할 수 있음을 보여주는 연구 결과를 발표했다.[26] 이 익스플로잇은 페이로드를 재구성하기 위해 프로세스 메모리를 스캔한 다음 시스템에서 코드를 실행할 수 있다. 논문은 인클레이브의 기밀하고 보호된 특성 때문에 바이러스 백신 소프트웨어가 그 안에 있는 악성 코드를 탐지하고 제거하는 것이 불가능하다고 주장한다. 인텔은 이 공격이 SGX의 위협 모델 범위를 벗어났으며, 사용자가 실행하는 코드가 신뢰할 수 있는 소스에서 온 것임을 보장할 수 없으며, 소비자에게 신뢰할 수 있는 코드만 실행하도록 촉구한다는 성명을 발표했다.[27]
마이크로스코프 리플레이 공격
최신 컴퓨터 아키텍처를 괴롭히는 부채널 공격이 확산되고 있다. 이러한 공격 중 다수는 코드 실행의 미세하고 비결정적인 변동을 측정하므로, 공격자는 비밀을 알아내기 위해 많은 측정값(수만 개일 수도 있음)이 필요하다. 그러나 마이크로스코프 공격은 악성 OS가 프로그램의 실제 구조와 상관없이 코드를 임의의 횟수만큼 재생할 수 있게 하여 수십 가지의 부채널 공격을 가능하게 한다.[28] 2022년 7월, 인텔은 SGX 인클레이브 프로그래머가 이러한 유형의 이벤트를 처리할 핸들러를 작성할 수 있도록 AEX-Notify라는 리눅스 패치를 제출했다.[29]
플런더볼트
보안 연구원들은 인클레이브 내 실행에 타이밍 특정 결함을 주입하여 정보 유출을 초래할 수 있었다. 이 공격은 원격으로 실행될 수 있지만, 프로세서의 전압과 주파수에 대한 특권 제어에 접근해야 한다.[30] 이 공격에 대한 보안 권고 및 완화책은 원래 2018년 8월 14일에 발표되었고 2020년 3월 20일에 업데이트되었다.[31]
로드 값 주입(Load Value Injection)[32][33]은 메모리에서 로드된 값을 대체하기 위해 프로그램에 데이터를 주입하는 것을 목표로 한다. 이 값은 오류가 발견되고 롤백되기 전까지 잠시 사용되며, 그 동안 LVI는 데이터 및 제어 흐름을 제어한다. 이 공격에 대한 보안 권고 및 완화책은 원래 2020년 3월 10일에 발표되었고 2021년 5월 11일에 업데이트되었다.[34]
SGAxe
2020년에 발표된 SGX 취약점인 SGAxe[35]는 캐시에 대한 투기적 실행 공격을 확장하여[36] 인클레이브의 내용을 유출한다. 이를 통해 공격자는 원격 인증에 사용되는 개인 CPU 키에 접근할 수 있다.[37] 다시 말해, 위협 행위자는 인텔의 대응책을 우회하여 SGX 인클레이브의 기밀성을 침해할 수 있다. SGAxe 공격은 인텔이 서명한 SGX의 개인 인용 인클레이브에서 인증 키를 추출하여 수행된다. 공격자는 그 다음 임의의 SGX 인증 인용에 서명함으로써 합법적인 인텔 기계로 위장할 수 있다.[38] 프로세서 데이터 유출 또는 캐시 이빅션(Cache Eviction)이라고도 불리는 이 공격에 대한 보안 권고 및 완화책은 원래 2020년 1월 27일에 발표되었고 2021년 5월 11일에 업데이트되었다.[39]
ÆPIC 누출
2022년 보안 연구원들은 고급 프로그래머블 인터럽트 컨트롤러(APIC)에서 취약점을 발견했는데, 이는 루트/관리자 권한을 가진 공격자가 L1 및 L2 캐시의 데이터 전송을 검사하여 APIC를 통해 암호화 키에 접근할 수 있도록 한다.[40] 이 취약점은 X86 CPU에서 발견된 최초의 아키텍처 공격이다. 이는 시끄러운 부채널을 사용하는 스펙터 및 멜트다운과는 다르다. 이 익스플로잇은 현재 인텔 코어 10세대, 11세대, 12세대 및 제온 아이스 레이크 마이크로프로세서에 영향을 미친다.[41][42]
개인 키 추출
코드 서명은 인클레이브에만 있는 개인 키로 생성된다. 개인 키는 칩의 "퓨즈" 요소를 통해 인코딩된다. 이 과정에서 비트가 타버려 이진 값 0이 된다. 이 개인 키는 하드웨어에 인코딩되어 추출할 수 없다. 마크 에르몰로프(Mark Ermolov), 막심 고랴치(Maxim Goryachy), 드미트리 스클랴로프(Dmitry Sklyarov)는 https://github.com/chip-red-pill/glm-ucode#에서 SGX 개념의 신뢰성에 대한 주장을 반박했다.
SGX 악성 코드 주장
SGX가 우수한 악성 코드 생성을 가능하게 하는지에 대한 오랜 논쟁이 있었다. 옥스퍼드 대학교 연구원들은 2022년 10월에 발표한 논문에서[43] 악성 코드 개발을 위해 SGX를 오용할 경우 공격자에게 잠재적인 장단점을 고려했다. 연구원들은 SGX 생태계에서 악용될 수 있는 일시적인 제로데이 취약점이 있을 수 있지만, 신뢰 실행 환경(TEE)의 핵심 원칙과 설계 특징은 악성 코드를 야생의 악성 코드보다 약하게 만들며, TEE는 그렇지 않은 경우 악성 코드에 크게 기여하지 않는다고 결론 내렸다.
↑Schwarz, Michael; Weiser, Samuel; Gruss, Daniel (2019년 2월 8일). “Practical Enclave Malware with Intel SGX”. arXiv:1902.03256 [cs.CR].더 이상 지원되지 않는 변수를 사용함 (도움말)
이 부분의 본문은 스펙터 (버그)입니다.
