Сохранен 10
https://2ch.hk/crypt/res/11356.html
24 декабря 2023 г. Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!

Разбираемся с Intel Software Guard Extensions

 Аноним 14/10/15 Срд 23:48:02 #1 №11356 
14448556823590.png
14448556823611.jpg
На Швабре прочитал о технологии. Технология позволяет создавать "анклавы", внури которых будет зашифрован как код, так и данные, а доступ к которым будет разграничиваться контроллером памяти.

Потенциально это опасная технология, если используется централизованная аттестация, но из материалов, которые удалось нагуглить, нихрена не понятно.



Нужно ответить на вопросы
1 позволяет ли данная технология хранить код в зашифрованном виде так, чтобы никто кроме авторизованной стороны не мог его расшифровать?

Ответ на это вопрос зависит от того, что такое HW-based attestation.

Сейчас поясню.
Прочитал слайды, ничего не понял.

Позволяет ли данная технология хранить код в зашифрованном виде так, чтобы никто кроме авторизованной стороны не мог его расшифровать?

Ответ на это вопрос зависит от того, что такое HW-based attestation и что подразумевается под HW based Attestation provides remote platform assurance that “this is the right app executing in the right platform “

Сейчас поясню.
Допустим копирасты хотят сделать невзламываемый DRM. Для этого пишут программу, которая создаёт анклав, который делает следующее
в первоначальный запуск:
1) скачивает с сервера копирастов код по защищённому доверенному каналу
2) генерит ключ, шифрует код этим ключом, выводит зашифрованный код из анклава, недоверенная часть его сохраняет на диск
в последующие запуски:
3) загружает зашифрованный код, расшифровывает его и выполняет

Так как ключ для расшифровки кода (sealing-ключ, если я верно понял) каким-то образом хранится так, что его нельзя извлечь (возможно он выводится с помощью PUF из REPORTа), и он не доступен вне анклава, то расшифровать код нельзя.

Только все усилия копирастов летят насмарку, если можно написать программу, которая соединится с их сервером и получит бинарник их секретного алгоритма, и, по-видимому, предотвращение этого в интеле и реализовали.
Я вижу несколько способов сделать это, все из которых подрывают владение системой.
Во-первых, можно в каждый чип внедрить секретный ключ, наружу не передаваемый, а на сервере интела хранить пару <открытый, ид чипа>, выдаваемую копирастам, оплатившим подписку, через API, а в процессе аттестации заставлять клиента подписывать challenge (копираст его выбирает) xor REPORT (копираст его знает для своего кода) и проверять подпись. Подтверждением аутентичности является соблюдение клиентом протокола (это говорит о том, что он знает приватный ключ и имеет такое же значение REPORT и наличие публичного в хранилище Intel). Программу же сделать нельзя, так как она не будет знать приватный ключ, из чипа не передаваемый. В случае утечки можно будет определить, какому чипу соответствует экземпляр спираченного кода, поместить ид этого чипа в реестр пиратов, после чего у него перестают работать все дрмнутые программы, а ещ стучат на него и к нему приезжают из фбр. Интел же может следить, на каком чипе исполняется программа какого вендора, отслеживая запросы к своей БД. Впрочем ничто не мешает хранить публичные ключи чипов в блокчейне биткоина.

Аноним 15/10/15 Чтв 00:09:22 #2 №11359 
http://theinvisiblethings.blogspot.ru/2013/08/thoughts-on-intels-upcoming-software.html
https://software.intel.com/sites/default/files/332680-002.pdf
Аноним 15/10/15 Чтв 00:23:20 #3 №11360 
http://theinvisiblethings.blogspot.ru/2013/09/thoughts-on-intels-upcoming-software.html
Аноним 15/10/15 Чтв 01:09:58 #4 №11365 
https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/january/intel-software-guard-extensions-sgx-a-researchers-primer/
Аноним 15/10/15 Чтв 01:17:12 #5 №11367 
https://software.intel.com/sites/default/files/managed/48/88/329298-002.pdf

>Each processor is provisioned with a unique key as the root of the key hierarchy. This is done at manufacturing
time. This key is the basis for all keys derived in the EG
ETKEY instruction. Figure 3-2 shows the hierarchy used to
generate keys on the platform.
Аноним 15/10/15 Чтв 01:20:46 #6 №11368 
https://software.intel.com/sites/default/files/article/413939/hasp-2013-innovative-technology-for-attestation-and-sealing.pdf
Аноним 05/04/16 Втр 19:54:56 #7 №22334 
охуенный (но с несколькими ошибками) гайд по архитектуре и микроархитектуре x86-64 и по SGX особенно. Читать строго всем. https://eprint.iacr.org/2016/086.pdf
Аноним 05/04/16 Втр 20:04:56 #8 №22335 
TL;DR
1 все поставщики программ, использующих Intel SGX, скорее всего будут обязаны заключить соглашение с Intel, иначе их код не заработает. Для этого в системе есть бекдор.
2 Системы, использующие SGX, должны связываться с интелом и сообщать ему выведенный из прошитого в процессор идентификатора и строки из nvram токен.
Второй прошитый в процессор токен
3 Интел сможет тырить данные из SGX благодаря бекдору.
4 АНБ скорее всего тоже.
5 Память якобы шифруется :( Не поможет ни DMA, ни колдбут, ни чтение физической памяти аппаратно. Как можно хранить и обрабатывать зашифрованные данные без штрафа к производительности - не знаю.
6 Необнаруживаемых руткитов/троянов не будет - из SGX нельзя делать системные вызовы, а привелегии SGX-кода ограничены третьим кольцом.
Аноним 05/04/16 Втр 20:08:27 #9 №22336 
>>22335
>*Второй прошитый в процессор идентификатор в интел якобы не передаётся, но доступен их анклавам. Может анклав его передать, используя канал скрытый?
7 будет невзламываемое DRM, из-за чего прогнозируется повальное распространение технологии: вспомните, почему под айфоны программы пишут.
Аноним 09/04/16 Суб 08:23:03 #10 №22708 
>>22336
Но айфоны можно джейлбрякнуть же, сосноли с зашитым дрм тоже рано или поздно ломали.
comments powered by Disqus

Отзывы и предложения