CPU가 무엇을하고 있는지 말하는 것이 정말로 불가능합니까? [닫은]


24

컴퓨터 프로그래머들은 종종 x86 명령어가 완전히 불투명하다는 만트라를 암송합니다. 인텔은 우리에게 무언가를하고 있다고 말하지만, 어떤 일이 일어나고 있는지 확인할 수있는 희망은 없습니다. 그것에 대해 무엇이든하십시오.

글쎄, 나는 컴퓨터 프로그래머 가이 문제에 대해 아무것도 할 수 없다고 생각합니다. 그러나 전기 기술자는 어떻게 그것을 공격할까요? 전기 엔지니어가 회로가 실제로 사양에 설명 된 작업을 수행하고 다른 작업은 수행하지 않는지 확인하는 데 사용할 수있는 기술이 있습니까?


5
당신은 주사위를 xray하고 무언가를 실제로 분석하기 위해 모든 것을 분석해야합니다. 기본적으로 칩을 리버스 엔지니어링하고 모든 회로의 기능을 설명합니다. 완전히 비현실적입니다.
DKNguyen

7
노이즈와 언젠가는 "충분히 큰"글리치가 발생할 가능성으로 인해 전기 회로가 정확한 스펙을 수행하지 않습니다.
앤디 일명

5
재미있는 정보 : 이것은 Laplace의 악마 와 모호 합니다.
해리 스벤손

6
하나의 현대적이고 복잡한 인텔 CPU조차 리버스 엔지니어링하는 것보다 인텔의 컨텐츠 데이터베이스에서 내부 문서를 훔치는 것이 더 쉬울 것입니다.

14
@ 태도가 좋지 않다면 백도어를 하드웨어에 숨길 수 없다는 주장은 사실이 아닙니다.
pjc50

답변:


14

이 주제에 관해 읽은 최고의 논문 은 2014 년의 "Stealthy Dopant-Level Hardware Trojans" (Becker et al)입니다.

수정 된 회로는 모든 배선층 (모든 금속 및 폴리 실리콘 포함)에 합법적으로 표시되므로 트로이 목마 제품군은 미세 광학 검사 및 "골든 칩"에 대한 검사를 포함한 대부분의 탐지 기술에 내성을 갖습니다. 트로이 목마를 두 가지 디자인 (Ivy Bridge 프로세서에 사용 된 Intel의 암호화 된 보안 RNG 디자인과 부 채널 저항 SBox 구현에서 파생 된 디지털 후 처리)에 삽입하고 탐지 가능성과 보안에 미치는 영향을 조사합니다.

이 백서에서는 변경 방법, 실리콘 검사에서 감지하기가 매우 어려우며, 생산 테스트에서 숨기는 기술 및 하드웨어 암호화 RNG의 보안을 낮추거나 주요 정보를 유출하는 방법에 대해 설명합니다. AES 구현의 파워 레일 사이드 채널을 통해

사이드 채널은 새로운 관심 분야입니다. 인텔은 프로그램에서 사용되지 않은 메모리에서 정보를 유출하는 추측 실행과 관련된 문제로 어려움을 겪었습니다. 의도적 인 디자인 결함 일 수 있습니까? 말하기는 거의 불가능합니다.


사이드 채널에 정보를 NSA에 보내기 위해 일종의 송신기가 필요하지 않습니까? 그렇지 않으면 필자가 작업하는 동안 랩톱에서 파워 레일 전류를 측정하는 사람이있을 것입니다.
Dmitry Grigoryev

24

전기 엔지니어가 회로가 실제로 사양에 설명 된 작업을 수행하고 다른 작업은 수행하지 않는지 확인하는 데 사용할 수있는 기술이 있습니까?

이론적으로는 가능하다고 생각합니다. 그러나 복잡한 CPU의 경우 많은 시간과 비용이 소요됩니다. 또한 디자인을 완전히 이해하고 이해하지 못하면 활동이 "합법적"인지 여부를 판단 할 수 없습니다.

CPU는 많은 논리 셀로 구성된 복잡한 디지털 회로의 "단지"입니다.

금속 연결을 관찰하여 칩 을 리버스 엔지니어링 하고 설계를 재구성 할 수 있습니다. 이러한 연결 레이어는 최대 8 개 이상의 레이어가있을 수 있습니다.

로직 셀을 인식하려면 해당 분야의 전문가가 필요합니다. 그러면 일부 소프트웨어가 어떻게 연결되어 있는지 파악하여 넷리스트를 재구성 할 수 있습니다.

넷리스트가 있으면 디자인을 "알고"있습니다. 그렇다고 이제 그것이 어떻게 작동하는지 아는 것은 아닙니다!

특정 기능은 디자인의 2 개 섹션을 활성화시키는 반면 하나는 충분해야한다고 생각하여 의심스러운 활동이 진행되고 있다고 의심 될 수 있습니다. 그러나 디자인은 작업 속도를 높이기 위해 모르는 영리한 트릭을 수행합니다.

디자인을 이해하고 이해하지 못하면 도출 한 결론이 여전히 잘못되었을 수 있습니다. CPU를 설계 한 엔지니어 만이 모든 설계 정보를 가지고 있으며 실제로 CPU에서 무슨 일이 일어나고 있는지 또는 무엇을해야하는지 파악하거나 추측 할 수있는 최상의 기회입니다.


77
CPU를 설계 한 엔지니어 만이 진행되는 모든 것을 알고 있습니다. 저는이 업계에서 일하는 엔지니어가되어이 진술을 매우 낙관적 인 것으로 평가하겠습니다
.

18
CPU 설계자 들은 진행되는 모든 것을 알지 못합니다. 그 수준의 디자인은 합성 툴에 의존하며 HDL 디자인의 것 이상으로 행동을 주입 할 수 있습니다. 비 필요한 예를 들어, 많은 FPGA 도구를 사용하면 로직 분석기에서 컴파일 할 수 있습니다.
Chris Stratton

9
"수십억 개의 트랜지스터"로 칩을 리버스 엔지니어링하면 문제가 발생합니다. spectrum.ieee.org/semiconductors/processors/…
전압 스파이크

4
@ 윌슨 (Wilson) 복잡한 회로 (CPU 포함)에는 많은 독점적 (비밀, 상표권 / 특허조차도) 디자인이 포함되어 있기 때문에 일반인이 이용할 수없는 독점적 (비밀, 상표권 / 특허조차도) 디자인이 포함되어 있기 때문에 설계를 소유 한 회사는 이익을 얻고 싶어하기 때문입니다. 6502는 오래된 디자인 이며 더 이상 귀중한 디자인 정보가 없으므로 모든 사람이 사용할 수 있습니다.
Bimpelrekkie

3
@Bimpelrekkie : 특허를받은 경우에는 비밀이 아닙니다. 그것이 특허의 요점입니다. 당신은 임시 독점에 대한 비밀을 거래합니다.
MSalters

9

글쎄, 나는 컴퓨터 프로그래머 가이 문제에 대해 아무것도 할 수 없다고 생각합니다. 그러나 전기 기술자는 어떻게 그것을 공격할까요?

백도어를 찾는 좋은 방법 은 없지만 하드웨어 백도어를 찾는 한 가지 방법은 조합 또는 문서화되지 않은 지침을 테스트하는 것입니다. 실제로이 작업을 수행하고 x86 하드웨어에서 감사를 수행하는 사람에 대한 좋은 이야기입니다 . 이것은 칩을 크래킹하지 않고 수행 할 수 있습니다. 인텔의 한 가지 문제 (다른 칩에 대해서는 잘 모르겠습니다)는 실제로 Linux가 실행되는 프로세서가 있으므로 일부 프로세서에서 소프트웨어가 실행되고 있으며 아마도 그에 액세스 할 수 없다는 것입니다.

전기 엔지니어가 회로가 실제로 사양에 설명 된 작업을 수행하고 다른 작업은 수행하지 않는지 확인하는 데 사용할 수있는 기술이 있습니까?

기능 자체를 테스트하기 위해 하드웨어 자체를 사용하도록 테스트하는 방법이 있습니다. x86에는 명령 세트의 문서화되지 않은 부분이 있기 때문에 버그가 발생할 가능성이 있기 때문에 일반적인 명령어로 백도어를 도입하는 것은 일반적이지 않습니다. 문서화되지 않은 지침에 있습니다.

일반 명령어의 기능을 테스트해야하는 경우 명령어를 실행하는 데 걸리는 시간을보고, 명령어를 실행하는 데 걸리는 전력량을 확인하여 예상과 다른지 확인하십시오.


3
나는 누군가가 이것을 할 수는 없지만 불가능한 것에 동의하지 않습니다. add 명령어와 같은 일반 명령어를 백도어라고 말하고 추가 명령어를 실행하면 백도어를 열었다 고 말할 수 있습니다. 그런 다음 고객은 정확히 그 조합을 가진 프로그램을 개발하고, 조사하고, 뒷문을 찾아 모든 사람이 화를 내고 고소 당하게됩니다. 문서화되지 않은 지침 (또는 CPU에 내장 된 리눅스 컴퓨터)에 백도어를 설치하는 것이 훨씬 안전합니다.
Voltage Spike

4
IME는 Linux가 아닌 Minix를 실행하며 훨씬 작고 간단합니다. 리눅스는 Minix의 존재에서 영감을 얻어 원래 파일 시스템을 사용했고 뉴스 그룹에 발표되었지만, 당시와는 상당히 달랐고 지금도 매우 다릅니다.
Chris Stratton

5
@ user14717- 불쾌한 가능성은 네이티브 클라이언트와 같은 탈옥 원시 실행 파일의 트리거 시퀀스입니다. 그러나 데이터가 아닌 코드 여야 할 이유가 없습니다 .
Chris Stratton

5
@ laptop2d CPU가 명령어 세트의 이론적 문서가 항상하는 일을하지 않는 버그 ; 아무도 고소 당하지 않습니다 . 예를 들어 인텔 7 세대 Core i7 제품군 문서 업데이트에서 정오표 섹션 을 읽으십시오 . 문서화되지 않은 지침을 사용하면 즉시 모든 맬웨어 연구원의 경보를 울립니다. 적절한 인터 레지스터 MOV와 함께 리듬 ADD의 특이한 조합을 사용하면 경보가 발생할 가능성이 줄어 듭니다.
Marcus Müller

6
@ laptop2d 나는 "CPU에 내장 된 리눅스"문장에 기절했다. 약간의 연구를 해본 결과 인텔 ME 엔진에 대해 이야기 한 것 같습니다. 글쎄, 그것은 CPU 자체가 아니라 노스 브리지 칩셋에서 실행됩니다. 그것은 그것에 대해 잘못된 정보가 많이있어왔다 보인다 참조 itsfoss.com/fact-intel-minix-case을
어두운

6

유일한 방법은 칩을 한 층씩 벗겨 내고 전자 현미경으로 모든 트랜지스터를 기록한 다음 어떤 종류의 시뮬레이션 프로그램에 입력 한 다음 실행되는지 확인하는 것입니다.

이것은 본질적으로 입력 및 출력 측정에서 내부를 재구성하려고 시도하는 블랙 박스 문제입니다. 내부의 복잡성 또는 I / O 수가 사소한 수준을 넘어 서면 가능한 내부 상태의 수가 천문학적으로되는 조합 폭발이 발생합니다. 구골 과 같은 숫자가 나오는 곳 .


2
... 그리고 사회 공학을 사용하여 디자인을 훔치는 것이 더 쉽습니다
.

8
아닙니다. 여기서 눈에 띄는 실수는 시뮬레이션 이 충분하지 않다는 것입니다. 당신이 경우에도 주어진 정확한 시뮬레이션 모델을 당신이하는 방법을 모르고이 없기 때문에, 당신은 여전히 신중하게 숨겨진 행동을 찾을 수 없을 것 트리거 를.
Chris Stratton

4
@ChrisStratton 나는 그 실수를 눈부신 이라고 부르지 않을 것이다 . 설계가 물리적으로 일반적인 단순화를 기반으로 한 것이 합리적이라고 가정합니다. 예를 들어 두 개의 금속 화 트레이스를 너무 가깝게 배치하지 않으면 서로 유도 적으로 결합되어 MOSFET 게이트의 상태를 변경할 수 있습니다. a) 단순화가 디자이너가 사용한 실제 모델과 일치하지 않거나 b) 디자이너가 의도하지 않은 방식으로 이러한 단순화 요구 사항을 의도적으로 위반하여 의도적으로 무언가를 숨기고있는 경우에만 실수입니다.
Marcus Müller

7
@ChrisStratton 아, 미안, 알았어, 이제는 내가 너의 요점을 얻는 것 같아 CPU의 디지털 / 행동 적 클럭 모델조차도 프로그래머의 이해 / 가정이 단순히 적용되지 않는 경우를 숨길 정도로 복잡하다고 말합니다. 사실입니다. SPECTER로 이어지는 영향을 극도로 세밀하게 문서화 할 수 있었으며, 대부분의 사람들은 데이터 또는 프로그램 흐름 관련 부작용에 대해 캐싱을 생각하지 않았을 것입니다. 과연!
Marcus Müller

3
감사합니다 :) 귀하의 주장은 ISA의 정확성에 대한 공식적인 검증에 대한 전체 주제를 다시 고려하게합니다 ( "이 ISA는 실제로 호환 CPU가 특권이없는 코드에 RING 0 권한을 부여하지 않습니까?") 및 HDL / 이러한 ISA 사양에 대한 RTL ( 특히 RISC-V CPU 코어 확인 프로젝트가 마음에 듭니다 )
Marcus Müller

5

CPU가 부적절한 작업을하지 않는다는 것을 증명하는 것은 매우 어렵습니다. 전형적인 예는 투표 기계입니다. 투표에 1 비트가 포함되어 투표권을 가져와 나중에 독재자에게 몰래 가져 가면 일부 지역에서 사망 또는 사망 할 수 있습니다. 그리고 수십억의 사람들과 같은 단일 비트가 없다는 것을 증명하는 것은 다소 어렵습니다.

칩을 물리적으로 분리하는 방법에 대해 생각할 수 있으므로 와이어 연결이 잘못되어 있는지 확인하는 것이 실용적입니다. 또한 네트워크 연결에 다른 칩 또는 하나 이상의 칩을 직렬로 연결하여 올바른 위치에만 연결되도록 보장합니다. 그런 다음 투표가 완료된 후 전원을 껐다 켜십시오. 그리고 거기에 비 휘발성 비트가 없기를 바라고 있습니다. 또는 부적절한 무선 연결. 그러나 당신은 그것에 당신의 인생을 믿을 것입니까?


5

NSA로 데이터를 전송하려면 네트워크 액세스가 필요하므로 네트워크 서비스가 비활성화 된 상태에서 OS를 실행하고 네트워크 인터페이스에서 트래픽을 확인하면 이러한 백도어를 쉽게 찾을 수 있습니다. 오픈 소스 OS의 경우 전체 네트워크 지원으로 실행하고 대상 IP로 스폿 로그 연결을 수행하여 OS가 합법적으로 액세스 할 수있는 주소와 일치하지 않을 수도 있습니다.

데이터 전송이없는 RNG 기반 백도어는 유용성이 매우 제한적입니다. CPU RNG가 유일한 엔트로피 소스가 아닌 한, 그러한 백도어가 공격자에게 어떤 이점을 제공하면서 동시에 명백하지는 않지만 실제로는 0 입니다. 타당한 이유가 없지만 Russel의 주전자가 있다고 주장하지 않는 한 동일한 인수를 하드웨어 RNG 백도어에 적용 할 수 있어야합니다.


5
따라서 당신은 적에게 하드웨어 트로이 목마를 생성하고 숨길 시간과 돈, 기술이 있다고 가정하지만, 가장 먼저하는 일은 telnet www.nsa.gov? 이것은 매우 순진한 관점처럼 보입니다.
엘리엇 앨더 슨

1
NSA에 취약점이 숨겨져 있다면 사람들 은 PRNG 시드의 유일한 엔트로피 소스로 사람들이 사용 rdrand했거나 rdseed인텔이 제안한대로 사용하길 바랄 것 입니다. 리눅스 (커널)는이 작업을 수행하지 않기로 선택 /dev/random했지만 glibc / libstdc ++의 현재 std::random_device rdrand 실행하는 대신 런타임에 사용 가능한 경우에만 사용 /dev/random합니다. Godbolt와 함께 표준 라이브러리 호출을 시작하십시오
Peter Cordes

@ElliotAlderson 그때 당신의 관점은 무엇입니까? 어딘가에서 데이터를 전송하지 않고 어떻게 귀중한 데이터를 훔칠 수 있습니까?
Dmitry Grigoryev

@PeterCordes std::random_device는 암호화 적으로 강력한 RNG가 아닙니다. C ++ 표준을 사용하면 매번 동일한 시퀀스를 효과적으로 반환 하여 PRNG로이를 구현할 수 있으므로 아무도 암호화에 사용하지 않아야합니다.
Dmitry Grigoryev

아 맞다, 나는 그것이 xD라는 것이 확실하지 않다는 것을 잊었다. 그것은 이다 많은 구현에 좋은,하지만는 MinGW는 플랫폼이 할 수있는대로 라이브러리의 주요 목적을 물리 치고, 좋은 품질의 임의의 숫자로 당신을 제공하는 설계 의도에 뛰어난 예외입니다. (당신이 말한대로 어느 하지 암호화하지만, 다른 목적을 위해 심는 PRNG도). ( mingw gcc4.8.1을 사용하는 std :: random_device를 실행할 때마다 동일한 시퀀스를 얻는 이유는 무엇입니까? ) 엔트로피 (최소 임베디드 장치)가없는 플랫폼에서는 허용되지만 x86 Windows에서는 허용되지 않습니다!
Peter Cordes
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.