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.
>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.
охуенный (но с несколькими ошибками) гайд по архитектуре и микроархитектуре x86-64 и по SGX особенно. Читать строго всем. https://eprint.iacr.org/2016/086.pdf
TL;DR
1 все поставщики программ, использующих Intel SGX, скорее всего будут обязаны заключить соглашение с Intel, иначе их код не заработает. Для этого в системе есть бекдор.
2 Системы, использующие SGX, должны связываться с интелом и сообщать ему выведенный из прошитого в процессор идентификатора и строки из nvram токен.
Второй прошитый в процессор токен
3 Интел сможет тырить данные из SGX благодаря бекдору.
4 АНБ скорее всего тоже.
5 Память якобы шифруется :( Не поможет ни DMA, ни колдбут, ни чтение физической памяти аппаратно. Как можно хранить и обрабатывать зашифрованные данные без штрафа к производительности - не знаю.
6 Необнаруживаемых руткитов/троянов не будет - из SGX нельзя делать системные вызовы, а привелегии SGX-кода ограничены третьим кольцом.
1 все поставщики программ, использующих Intel SGX, скорее всего будут обязаны заключить соглашение с Intel, иначе их код не заработает. Для этого в системе есть бекдор.
2 Системы, использующие SGX, должны связываться с интелом и сообщать ему выведенный из прошитого в процессор идентификатора и строки из nvram токен.
Второй прошитый в процессор токен
3 Интел сможет тырить данные из SGX благодаря бекдору.
4 АНБ скорее всего тоже.
5 Память якобы шифруется :( Не поможет ни DMA, ни колдбут, ни чтение физической памяти аппаратно. Как можно хранить и обрабатывать зашифрованные данные без штрафа к производительности - не знаю.
6 Необнаруживаемых руткитов/троянов не будет - из SGX нельзя делать системные вызовы, а привелегии SGX-кода ограничены третьим кольцом.
>*Второй прошитый в процессор идентификатор в интел якобы не передаётся, но доступен их анклавам. Может анклав его передать, используя канал скрытый?
7 будет невзламываемое DRM, из-за чего прогнозируется повальное распространение технологии: вспомните, почему под айфоны программы пишут.
Но айфоны можно джейлбрякнуть же, сосноли с зашитым дрм тоже рано или поздно ломали.
Потенциально это опасная технология, если используется централизованная аттестация, но из материалов, которые удалось нагуглить, нихрена не понятно.
Нужно ответить на вопросы
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). Программу же сделать нельзя, так как она не будет знать приватный ключ, из чипа не передаваемый. В случае утечки можно будет определить, какому чипу соответствует экземпляр спираченного кода, поместить ид этого чипа в реестр пиратов, после чего у него перестают работать все дрмнутые программы, а ещ стучат на него и к нему приезжают из фбр. Интел же может следить, на каком чипе исполняется программа какого вендора, отслеживая запросы к своей БД. Впрочем ничто не мешает хранить публичные ключи чипов в блокчейне биткоина.