Действительно ли невозможно сказать, что делает процессор? [закрыто]


24

Программисты часто повторяют мантру о том, что инструкции x86 совершенно непрозрачны: Intel говорит нам, что они что-то делают, но нет надежды, что кто-нибудь сможет проверить, что происходит, поэтому, если АНБ скажет им, чтобы они замаскировали свои ГСЧ, то мы не можем на самом деле сделать что-нибудь с этим.

Ну, я считаю, что программисты ничего не могут сделать с этой проблемой. Но как на это напал бы инженер-электрик? Существуют ли методы, которые инженер-электрик мог бы использовать для проверки того, что схема действительно выполняет операции, описанные в ее спецификации, и никаких других операций?


5
Вы должны сделать что-то вроде рентгеновского снимка и проанализировать все, чтобы увидеть, что он на самом деле делает. По сути, перепроектировать чип и учесть функции каждой цепи. Совершенно непрактично.
Нгуен

7
Ни одна электрическая цепь не соответствует точным характеристикам из-за шума и небольшой вероятности того, что однажды произойдет сбой, который будет «достаточно большим».
Энди ака

5
Интересная информация: Это неопределенно связано с демоном Лапласа .
Гарри Свенссон

6
Похищать внутренние документы из базы данных контента Intel будет проще, чем реконструировать даже один современный сложный процессор Intel.
лес

14
@ Более жесткое ваше отношение неконструктивно, и ваше утверждение о том, что бэкдор не может быть скрыт аппаратно, не соответствует действительности.
pjc50

Ответы:


14

Лучшая статья, которую я прочитал на эту тему, - «Скрытые аппаратные трояны уровня допанта» (Becker et al) от 2014 года.

Поскольку модифицированная схема выглядит законной на всех слоях проводки (включая весь металл и поликремний), наше семейство троянов устойчиво к большинству методов обнаружения, включая детальный оптический контроль и проверку на «золотые фишки». Мы демонстрируем эффективность нашего подхода вставляя трояны в два проекта - цифровую постобработку, основанную на криптографически защищенном проекте RNG Intel, используемом в процессорах Ivy Bridge, и реализацию SBox, устойчивую к побочным каналам, - и исследуя их обнаруживаемость и влияние на безопасность.

В документе описывается, как вносятся изменения, как чрезвычайно трудно обнаружить при проверке кремния, способы скрытия его от производственного теста и как это можно сделать, чтобы снизить безопасность аппаратного крипто-ГСЧ или утечь ключевую информацию. через боковой канал силовой шины реализации AES.

Побочные каналы представляют собой новую область интересов. Intel страдает от проблем, связанных со спекулятивным исполнением утечки информации из памяти, которая даже не использовалась программой. Может ли это быть преднамеренным недостатком дизайна? Это почти невозможно сказать.


Разве боковому каналу не понадобится какой-то передатчик для отправки информации в АНБ? В противном случае я наверняка заметил бы, что кто-то измеряет ток шины питания на моем ноутбуке, пока я над ним работаю.
Дмитрий Григорьев

24

Существуют ли методы, которые инженер-электрик мог бы использовать для проверки того, что схема действительно выполняет операции, описанные в ее спецификации, и никаких других операций?

В теории да, я думаю, что это возможно. Однако для сложного процессора это займет много времени и денег. Кроме того, если вы не в полной мере знаете и не понимаете дизайн, вы не сможете судить, является ли какое-либо действие «законным» или нет.

Процессор - это просто сложная цифровая схема, состоящая из множества логических ячеек.

Можно перепроектировать чип и реконструировать конструкцию путем наблюдения металлических соединений. Таких соединительных слоев может быть много, например, до 8 или более слоев.

Вам понадобятся эксперты в этой области, чтобы распознать логические ячейки, а затем, возможно, какое-то программное обеспечение сможет выяснить, как они все связаны, чтобы вы могли восстановить список соединений.

Как только у вас есть список соединений, вы «знаете» дизайн. Это не значит, что вы теперь также знаете, как это работает!

Может случиться так, что определенная функция активирует 2 раздела проекта, в то время как вы думаете, что этого должно быть достаточно, чтобы потом подозревать, что происходит какая-то подозрительная деятельность. Тем не менее, дизайн делает некоторые хитрые трюки, о которых вы не знаете, для ускорения операций.

Не зная и не понимая дизайн, любой вывод, который вы сделаете, все равно может быть неправильным. Только инженеры, спроектировавшие ЦП, имеют всю информацию о конструкции и имеют наилучшие шансы на то, чтобы выяснить или угадать, что на самом деле происходит или должно происходить в ЦП.


77
Все, что происходит, знают только инженеры, спроектировавшие ЦП. Я являюсь инженером, работающим в этой отрасли, и позвольте мне оценить это утверждение как очень оптимистичное :)
Евгений Ш.

18
Нет, разработчики ЦП не знали бы всего, что происходит - проектирование на этом уровне зависит от инструментов синтеза, и они могут внедрить поведение, выходящее за рамки дизайна HDL. Возьмем несерьезный пример: многие инструменты FPGA позволят вам скомпилировать в логическом анализаторе.
Крис Страттон

9
Обратный инжиниринг чипа с «миллиардами транзисторов» был бы проблемой. spectrum.ieee.org/semiconductors/processors/…
Пик напряжения

4
@Wilson Потому что сложные схемы (включая ЦП) будут содержать множество запатентованных (и секретных, торговых марок / даже запатентованных) конструкций, которые не доступны широкой публике, потому что компании, владеющие этими конструкциями, хотят получать от них прибыль (зарабатывать деньги). 6502 - это старый дизайн , он больше не имеет ценной информации о дизайне, так что да, он полностью открыт и доступен для всех.
Bimpelrekkie

3
@Bimpelrekkie: Если они запатентованы, они по определению не секрет. В этом смысл патента. Вы торгуете секретом для временной монополии.
MSalters

9

Ну, я считаю, что программисты ничего не могут сделать с этой проблемой. Но как на это напал бы инженер-электрик?

Не существует хороших способов найти задние двери, один из способов найти аппаратный черный ход - это проверить комбинации или недокументированные инструкции. Вот хороший разговор о ком-то, кто на самом деле делает это и проводит аудит на оборудовании x86 . Это можно сделать без взлома чипа. Одна из проблем с Intel (я не уверен насчет других чипов) состоит в том, что на самом деле на нем работает процессор с linux, поэтому на некоторых процессорах также работает программное обеспечение, и у вас, возможно, нет доступа к нему.

Существуют ли методы, которые инженер-электрик мог бы использовать для проверки того, что схема действительно выполняет операции, описанные в ее спецификации, и никаких других операций?

Есть способы протестировать использование самого оборудования для тестирования функциональности. Поскольку x86 имеет недокументированную часть своего набора инструкций, было бы необычно вводить бэкдоры в обычные инструкции, потому что это представляло бы возможность ошибок (например, если у вас был бэкдор в инструкции add или mult), поэтому первое место, на которое следует обратить внимание будет в недокументированных инструкциях.

Если вам нужно было проверить функциональность обычных инструкций, вы могли бы наблюдать за временем, которое требуется для выполнения инструкций, посмотрите, сколько энергии требуется для выполнения инструкций, чтобы увидеть, есть ли отличия от того, что вы ожидаете.


3
Я бы не согласился, не исключено, что кто-то сделает это, но вряд ли. Допустим, вы замаскировали обычную инструкцию, такую ​​как инструкция добавления, и если вы выполнили дополнительную инструкцию, допустим, она открыла бэкдор. Затем клиент разрабатывает программу, которая имеет именно эту комбинацию, он изучает ее, находит черный ход, и все злятся, а вам предъявляют иск. Гораздо безопаснее поставить бэкдор в недокументированных инструкциях (или на компьютере с Linux, встроенным в ЦП)
скачок напряжения

4
IME работает на Minix, который не является Linux, и намного меньше и проще. Linux был вдохновлен существованием Minix и первоначально использовал свою файловую систему и был анонсирован в своей группе новостей, но тогда они были совершенно другими и сейчас чрезвычайно.
Крис Страттон

5
@ user14717 - неприятная возможность - последовательность триггеров в собственном исполняемом файле, что-то вроде собственного клиента. Но нет причин, чтобы это был код, а не данные .
Крис Страттон

5
@ laptop2d Ошибки, когда центральные процессоры не выполняют то, что, как говорится в теоретической документации набора команд, происходят постоянно ; как правило, никто не получает иск: прочтите, например, раздел об ошибках в обновлении doc для Intel 7-го поколения семейства i7. Использование недокументированной инструкции немедленно вызовет тревогу у любого исследователя вредоносного ПО. Использование необычной комбинации ритмичных ADD с правильными межрегистровыми MOV с меньшей вероятностью вызовет какую-либо тревогу.
Маркус Мюллер

6
@ laptop2d Я был ошеломлен заявлением «встроенный Linux в CPU». Итак, я провел небольшое исследование, думаю, вы говорите о движке Intel ME. Ну, он работает не на самом процессоре, а на чипсете северного моста. Кажется, было много дезинформации об этом, см. Itsfoss.com/fact-intel-minix-case
dim

6

Единственный способ состоит в том, чтобы разделять микросхему слой за слоем и записывать каждый транзистор с помощью электронного микроскопа, а затем вводить это в какую-то программу моделирования и затем наблюдать за ее работой.

По сути, это проблема «черного ящика», в которой вы пытаетесь восстановить внутреннее устройство по измерениям входов и выходов. Как только сложность внутренних элементов или количество операций ввода / вывода выходит за рамки тривиального, возникает комбинаторный взрыв, в котором число возможных внутренних состояний становится астрономическим. Где номера , как Googol вышвырнут о.


2
... а дизайн с помощью социальной инженерии легче украсть :)
Евгений Ш.

8
Нет. Явной ошибкой здесь является то, что симуляции будет недостаточно. Даже если бы вы дали в точную модель моделирования, вы все равно не смогли бы найти тщательно скрываемое поведение, потому что вы понятия не имеете , как вызвать его.
Крис Страттон

4
@ChrisStratton Я бы не назвал эту ошибку вопиющей . Разумно предположить, что дизайн был основан на выполнении упрощений, которые являются физически обычными, например, что вы не помещаете два следа металлизации настолько близко друг к другу, что они соединяются достаточно индуктивно, чтобы изменить состояние затвора MOSFET. Это только ошибка, если а) ваши упрощения не соответствуют физической модели того, что использовал дизайнер, или б) дизайнер намеренно что-то скрывает, намеренно нарушая требования к этим упрощениям неочевидными способами.
Маркус Мюллер

7
@ChrisStratton ах, извини, хорошо, я думаю, теперь я понял твою точку зрения. Вы говорите, что даже цифровые / поведенческие тактовые модели процессора достаточно сложны, чтобы скрыть случаи, когда понимание / предположения программиста просто не применимы. Это правда. Можно было задокументировать эффекты, приводящие к SPECTER, в мучительных деталях, и большинство людей никогда бы не подумали о кешировании, имеющем побочные эффекты, связанные с потоком данных или программ. Верно!
Маркус Мюллер

3
Спасибо :) Ваш аргумент возвращает всю тему формальной проверки правильности ISA («действительно ли этот ISA гарантирует, что совместимый ЦП не предоставляет привилегии RING 0 непривилегированному коду?») И формальной проверки HDL / RTL против таких спецификаций ISA (мне особенно нравится этот проект верификации RISC-V CPU Core )
Маркус Мюллер

5

Доказать, что процессор не делает ничего хитрого, чрезвычайно сложно. Классический пример - машина для голосования. Если в нем есть хоть один бит, который берет копию вашего голоса, а затем передает его какому-то диктатору, в некоторых местах это может стать для вас жизнью или смертью. И доказать, что среди миллиардов нет ни единого подобного, довольно сложно.

Вы можете подумать об изоляции чипа физически, поэтому практично убедиться, что к нему нет неправильных проводных соединений. И добавление другого чипа или нескольких последовательных чипов (из разных источников) в сетевое соединение, которое гарантирует, что он подключается только в нужном месте. Затем включите его после того, как он проголосует. И надеясь, что там нет энергонезависимых битов. Или подлый беспроводной связи. Но ты бы доверил свою жизнь этому?


5

Передача любых данных в АНБ потребует доступа к сети, поэтому будет очень легко обнаружить такой черный ход, запустив ОС с отключенными сетевыми службами и проверив сетевые интерфейсы на наличие трафика. Для ОС с открытым исходным кодом даже можно работать с полной поддержкой сети и определять мошенническое соединение по IP-адресу назначения, который не будет совпадать ни с одним адресом, к которому ОС может иметь законный доступ.

Бэкдор на основе ГСЧ без передачи данных будет иметь очень ограниченную полезность. Если только процессорный ГСЧ не является единственным источником энтропии, шансы на то, что такой бэкдор предоставит атакующему какое-либо преимущество, хотя и не будучи очевидными в то же время, практически равны нулю . Если вы не настаиваете на том, что чайник Рассела существует, несмотря на то, что у него нет веских причин для существования, вы должны иметь возможность применить тот же аргумент к аппаратным черным дверям ГСЧ.


5
Итак, вы предполагаете, что у противника есть время, деньги и навыки, чтобы создавать и скрывать аппаратного троянского коня, но первое, что он делает, - это telnet www.nsa.gov? Это кажется очень наивной точкой зрения.
Эллиот Олдерсон

1
Если бы АНБ скрыло уязвимость, то да, они бы надеялись, что люди использовали rdrandили rdseedкак предложила Intel: в качестве единственного источника энтропии для семян PRNG. Linux (ядро) решил не делать для /dev/random, но Glibc / libstdc ++ s тока std::random_device делает использование только rdrandесли он доступен во время выполнения вместо открытия /dev/random. Войдите в стандартный библиотечный звонок с Годболтом
Питер Кордес

@ElliotAlderson Какая у тебя тогда точка зрения? Как кто-то может украсть ценные данные, не передавая их куда-либо?
Дмитрий Григорьев

@PeterCordes std::random_deviceне является криптографически сильным ГСЧ. Стандарт C ++ позволяет реализовать его с помощью PRNG, эффективно возвращая одну и ту же последовательность каждый раз , поэтому совершенно очевидно, что никто не должен использовать его для шифрования.
Дмитрий Григорьев

Ах да, я забыл, что нет никаких гарантий, что это хорошо, xD. Это является хорошим во многих реализациях, но MinGW является исключением безусловного победителя в концепции конструкции , что дает вам как хорошее качество случайных чисел , как платформа способна, разгромив основную цель библиотеки. (Как вы говорите, это не крипто, а посев PRNG для других целей). ( Почему я получаю одинаковую последовательность для каждого запуска с std :: random_device с mingw gcc4.8.1? ). Это было бы приемлемо на платформе без энтропии (минимальное встроенное устройство), но не на x86 Windows!
Питер Кордес
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.