Комментарии 61
Лично меня, как пользователя, очень возмущает ситуация, что какое-либо ПО создаёт области памяти к которым я не имею права доступа.
И я вижу в этом очередную попытку пропихнуть DRM на мой компьютер за мой счёт.
Спасибо, не надо.
Если же каким-то образом её сделают неотключаемой, то добротная виртуализация с pci-passthrough наше всё. Включаем эмуляцию процессора предыдущего поколения — и живём с этим.
В опенсорсе её, ествественно, сделают опциональной. Что будут делать пользователи проприетарных систем, когда windows 10 в 2025 году скажет, что после нового принудительного апдейта старые процы не поддерживаются — не знаю.
Что будут делать пользователи проприетарных систем, когда windows 10 в 2025 году скажет, что после нового принудительного апдейта старые процы не поддерживаются — не знаю.Выстроятся в ряд под названием «я первый».
Собственно, Windows 11 из 2021 года передаёт привет. Пока что апдейт не обязателен, но и Windows 11 сейчас только на стадии Preview.
Раньше была возможность прошить вместо BIOS что-то свободное (тот же Coreboot/Libreboot), но после 2008 года требуется подсовывать бинарный блоб для работы ME. При отсутствии оного чипсет принудительно выполняет перезагрузку. Именно по этой причине, кстати, все «свободные» компьютеры, одобренные Фондом СПО (Столлманом и компанией) обладают материнками и процессорами того самого 2008 года, поскольку на более новом железе Libreboot не заработает, а блоб грузить им не позволяют убеждения.
На базе этой же технологии работает удалённое администрирование Intel vPro. Вся разница там в том, что рычаги доступа к vPro доступны пользователю (на соответствующих чипсетах), а ME, хоть и есть абсолютно везде, пользователю совершенно не подконтролен.
У AMD всё аналогично, только хуже изучено и документировано. Если вам захочется свалить из этого ада — придётся попрощаться с архитектурой x86. И с ARM заодно, у них уже давно есть TrustZone.
Теперь решили дать эти возможности более широкому кругу разработчиков.
тем не менее, это возможность защиты на аппаратном уровне от вредоносного ПО и да, защита своего контента
1. SMM, на центральном процессоре
2. ME, на отдельном процессоре в чипсете
3. довольно мощное ядро в wifi карточке
4. хиленькое ядро в ряде ethernet карточек
5. код, запущенный на GPU
Ещё 5 лет назад один мужик смог сделать firmware для карточки marvell (если я не ошибаюсь), которая могла форвардить пакеты в другие интерфейсы и запускать небольшой шелл на GPU, с доступом ко всей оперативной памяти через DMA.
Да (устройства часто обычно сами и инициируют DMA транзакции).
When the device attempts to access system memory, the DMA-remapping hardware intercepts the access and utilizes the page tables to determine whether the access can be permitted; it also determines the actual location to access.
Отображение работает даже для устройств без PASID — "Second-level translation applies to requests-without-PASID" (3.7).
DMA remapping использует source-id (PCI Bus/Device/Function number) для идентификации устройств и выбора таблиц трансляции (раздел 3.9). (Есть предположения о попытках подделать source-id — [11] = doi:10.1109/MALWARE.2010.5665798 — "3.2.2 I/O controller source-id theft"). Не думаю, что root-complex пропустит запрос с левым для данного порта source-id, т.е. атака возможна только из-за дальних мостов, можно представиться другим устройством из-за того же моста.
Даже p2p запросы между двумя pci-e устройствами могут быть оттранслированы, если прошли через Root-complex (а они пройдут, если pcie switch умеет ACS и был настроен).
Сможет ли автор трояна/шифратора воспользоваться SGX для скрытия своего кода/ключей от "враждебного" антивируса?
https://www.virusbulletin.com/virusbulletin/2014/01/sgx-good-bad-and-downright-ugly — "Scenario 1, the botnet creator:… With SGX, the attacker could create an enclave, perform remote attestation with their C&C (command and control) server from inside the enclave, set up some private-public key encryption based on their SGX keys, and receive a payload to execute inside the enclave or any other commands from the C&C server."
Будет ли вводится "белый список" для компаний желающих воспользоваться SGX? Ожидается ли выдача авторам отдельных антивирусов возможности обхода SGX? (Возможен ли обход из ME?)
J. Rutkowska. Thoughts on Intel’s upcoming Software Guard Extensions (Part
2), Sept. 2013. http://theinvisiblethings.blogspot.com/2013/09/thoughts-on-intels-upcoming-software.html "Unless there was a way for “Certified Antivirus companies” to get around SGX protection..."
Возможно ли отключение возможностей SGX в BIOS?
В работе
"Intel SGX Explained", Cryptology ePrint Archive: Report 2016/086, Jan 2016 https://eprint.iacr.org/2016/086.pdf
действительно подробно описана известная информация об SGX — инициализация привилегированная (потребуется разрешение от ОС, она же может и отключить весь SGX), при инициализации работает Launch Enclave, в которой заложена возможность проверки создаваемого Enclave, вероятно для запуска потребуется сертификат, подписанный Intel:
5.9.2 Licensing "SGX patents… Launch Enclave is intended to be an enclave licensing mechanism that allows Intel to force itself as an intermediary in the distribution of all enclave software."
5.9.3 System Software Can Enforce a Launch Policy "SGX instructions used to load and
initialize enclaves (ECREATE, EADD, EINIT) can only be issued by privileged system software"
5.9.4 Enclaves Cannot Damage the Host Computer "In SGX, the system software can always evict an enclave’s EPC pages to non-EPC memory, and then to disk. The system software can also outright deallocate an enclave’s EPC pages"
5.9.5 Interaction with Anti-Virus Software "Enclave code always executes at the lowest privilege mode (ring 3 / user mode), so it cannot perform any I/O without invoking the services of system software.… SGX’s enclave loading model allows the possibility of performing static analysis on the enclave’s software."
Документация по SGX от Intel:
Intel Software Guard Extensions Programming Reference, 329298-002US, OCTOBER 2014
https://software.intel.com/sites/default/files/managed/48/88/329298-002.pdf
В идеале — будет ли доступна широкая линейка процессоров без поддержки SGX?
Зато сразу ясно где искать интересные данные. И если пропатчить тот сошник, то защиту можно обойти?
1. Оформляется so-шник в виде небольшой программы с кодом, стеком и данными и к нему дописывается публичный ключ
2. Обычный код загружает этот so-шник вместе с ключем в специальный раздел памяти.
3. После того как загрузка завершена раздел блокируется для любого доступа
4. Процессор аппаратно генерит на все загруженное уникальный хэш (надо полагать с участием соли, хотя в доках про это я не нашел) по которому можно проверить что загруженное соответствует ожидаемому
5. Хэш отсылается обычным же кодом по интернету «владельцу» кода
6. Владелец проверяет что хэш верный и генерирует на основе известного только ему секретного ключа подпись «разблокировки» которую отправляет обратно
7. Программа получив код разблокировки использует его для того чтобы получить доступ к созданному ранее защищенному разделу. Процессор проверяет валидность подписи по публичному ключу.
8. «Доступ» означает что софт может начать выполнять код расположенный в этом разделе. Этот код проверен через хэш разработчиком и его уже невозможно модифицировать «извне».
Таким образом сошник можно пропатчить, но запустить его без разрешения того кто знает секретный ключ уже не получится. Но конечно без интернета и хранения секретного ключа отдельно эта схема не работает. Правда, очевидно, тот кто загружал .so-шник знает о его содержимом. Но это легко поправимо:
9. Помещаем в защищенный подобным образом раздел специальный «загрузчик» который устанавливает зашифрованное безопасное соединение с серваком разработчика
10. Качаем по зашифрованному каналу любой желаемый код либо просто ключ расшифровки к тому что уже лежит в памяти и выполняем полученное в контексте уже созданного «безопасного раздела»
И всё. К тому что таким образом скачано доступ получить без отмычки на уровне процессора будет невозможно.
Хорошее описание SGX здесь
https://eprint.iacr.org/2016/086.pdf
И там куча всего интересного о чем интел не очень-то спешит распространяться. Например о Launch Enclave.
Но вообще, несмотря на якобы благие намерения, это откровенный DRM. Как по мне, если вредоносный код уже проник в ядро ОС, то у него есть тысячи способов нанести ущерб. Одним больше, одним меньше — не суть важно (так что чистое ядро — единственный способ гарантировать безопасность). Тем более, что данная технология точно также хорошо будет играть и на стороне злоумышленника (защита от антивирусов и просто исследования кода антивирусными компаниями).
Да и мы с вами перейдём, а обычный пользователь? В бенчмарках попугаев больше, в играх FPS выше, угадайте, что он возьмёт?
https://eprint.iacr.org/2016/086.pdf
любая процедура инициализации нового secure enclave проходит через специальный защищенный анклав Launch Enclave который предоставляется исключительно самой компанией Intel.
1) Верно ли что любая инициализация Secure Enclave должна проходить проверку в Launch Enclave доступном сугубо от компании Intel?
2) Верно ли что из этого следует что для того чтобы запустить что-либо в Secure Enclave код кроме как в «debug» или «prerelease» версии придется код подписывать у Intel дабы LE авторизовал его инициализацию?
3) Верно ли что процедура аутентификации проводится Launch Enclave через серверы Intel и Intel может в любой момент отозвать авторизацию для ранее подписанного SE?
4) Верно ли что все остальные процедуры аутентификации доступные коду работающему в Secure Enclave базируются на ключе генерируемом в ходе авторизации запуска SE на серверах Intel?
Теперь еще эта ваша новая «фича», крутимся как можем?
Мало вам денег за процессоры?
Я тоже опасаюсь за будущее SGX, но по несколько другим причинам: технология банально слишком сложная для реализации даже очень опытным разработчиком, поэтому (даже если, по счастливой случайности, в ее реализации не окажется дыр, и твой способ атаки не сработает по каким-то гипотетическим причинам) большая часть софта просто не будет его использовать, плюс еще доступна она буквально на двух с половиной процессорах, требует поддержки со стороны прошивки (но там только память под кэши выделить, ничего сложного), имеет мутный лицензионный статус (так до конца и непонятно, кто кому какие ключи подписывает) и так далее.
Много вы видели софта, который использовал бы AVX2? Я видел полторы оптимизированные вручную опенсорсные утилиты и дорогущий интеловский компилятор. А ведь набору инструкций уже больше трех лет, и он простой как валенок.
Не могу сказать, что SGX вот прямо совсем мертворожденая фигня, как TXT, но в истории с ним очень четко прослеживается тенденция, которую я называю «много развожу, и много вешаю»: на каждом новом поколении Intel пробует какие-то новые технологии, часть которых «выстреливает» и их начинают поддерживать и использовать все (NX bit, SMEP, SMAP те же), а другая тихо уходит в небытие после 2-3 поколений. При этом презентуют их все с максимальной помпой, т.к. Инновации и Технологическое Лидерство. А потом приходят ребята вроде тебя или Рафаля и портят маркетингу всю малину. :)
4) Дабы избежать MITM код работающий внутри анклава (и только внутри) получает возможность подписывать сообщения секретным ключем зависящим от хэша анклава сделанного на момент запуска. На основе этой подписи сторонний код / сервер может проверить что общается со строго определенным (на момент запуска) кодом работающем в защищенном анклаве
С другой стороны SGX не защищает от ошибок в коде защищенного анклава, плюс довольно проблематично защитить все каналы ввода-вывода. Например безопасный ввод данных с клавиатуры в приложение SGX возможен будет только со специальной клавиатурой с которой можно будет установить зашифрованный канал связи — иначе тот же пароль будет просто перехвачен в драйвере клавиатуры или на уровне передачи символов от ОСи к приложению SGX.
Основная защита строится на основании того что код запущенный в контейнере может подписывать сообщения с использованием секретного ключа хранящегося в процессоре. В эти сообщения принудительно дописывается хэш контейнера который сообщение генерирует. Получаем подписанный секретным ключом хранящимся в процессоре мессадж вида «запущенный на процессоре в безопасном анклаве код с хэшем таким-то сообщает X». То есть процессор гарантирует (своим секретным ключем) что сообщение сгенерировал код идентифицируемый этим хэшем. Для эмуляции этого нужно знать секретный ключ, так что в QEMU скорее всего он просто задан от балды и известен, позволяя отлаживать код, однако подписанные этим кодом мессаджи будут однозначно идентифицированы как сгенерированные не на интеловском процессоре, а QEMU.
Кроме этого в текущей реализации вроде запуск нового анклава возможен только через специальный «стартовый» анклав от самого интела. Стартовый анклав, вероятно, не запустится если его хэш не совпадет с прописанным непосредственно в процессоре (ну или не будет подписан ЭЦП от интела с публичным ключем опять же прошитым в процессоре). А дальше у стартового анклава есть куча возможностей типа, к примеру, отправки хэша контейнера который планируем запускать на сервер к интелу на «одобрение» по списку разрешенных хэшей.
У Apple в SoC Ax зашиты два ключа — GID и UID. GID — в самой схеме для данной модели чипа (как GWK у Интела, см чуть ниже); уникальный для каждого чипа UID — в eFuse. Как показал недавний спор
https://en.wikipedia.org/wiki/FBI-Apple_encryption_dispute и слухи о попытках CIA — https://www.theiphonewiki.com/wiki/GID_Key, ни тот, ни другой дешевыми способами не вытаскиваются. Серийные номера чипа в eFuse уже прошивают при изготовлении, прошить еще несколько десятков байт — не слишком сложно. Сохранять в базе уникальные ключи всех выпущенных чипов не обязательно, если есть общий GWK (GID) ключ, в который можно обернуть все что угодно (а развернуть — только зная GWK ключ). Еще предлагали какую-то магию с записью ключей, обернутых в PUF — http://www.google.com/patents/US20140270177 "sending, by a key server, a global key… encrypting, by the integrated circuit, the global key using a physically unclonable function (PUF) key; and burning ...in fuses in the integrated circuit."
В процессорах, вероятно, будут ключи: https://eprint.iacr.org/2016/086.pdf "original SGX patents [108, 136] disclose that the Fused Seal Key and the Provisioning Key, which are stored in e-fuses (§ 5.8.2), are encrypted with a global wrapping logic key (GWK). The GWK is a 128-bit AES key that is hard-coded in the processor’s circuitry… Newer Intel patents [67, 68] describe SGX-enabled processors that employ a Physical Unclonable Function (PUF)".
https://software.intel.com/sites/default/files/managed/48/88/329298-002.pdf 3.4 INTEL SGX KEY AND ATTESTATION "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 EGETKEY instruction."
Можно построить такие схемы, в которых без знания ключа не получится полной эмуляции SGX.
Ссылка на qemu-симулятор с SGX — https://github.com/sslab-gatech/opensgx https://taesoo.gtisc.gatech.edu/pubs/2016/jain:opensgx.pdf (в нем нет реального ключа от Intel, произвольный ключ подается как опция при запуске)
Контекст SGX не сохраняется в SMRAM при SMI. Сначала регистры SGX сохраняются внутри Enclave, затем регистры заполняются синтетическим состоянием (4.3.1), после чего начинает работать SMI обработчик
https://software.intel.com/sites/default/files/managed/48/88/329298-002.pdf
Chapter 4. For that reason, such events are called an enclave-exiting events (EEE);
EEEs include external interrupts, non-maskable interrupts, system-management interrupts, exceptions, and VM exits. The process of leaving an enclave in response to an EEE is called an asynchronous enclave exit (AEX). To protect the secrecy of the enclave, an AEX saves the state of certain registers within enclave memory and then loads those registers with fixed values called synthetic state.
6.8.2 SMI while Inside an Enclave
If the logical processor executing inside an enclave receives an SMI when dual-monitor treatment is not enabled, the logical processor exits the enclave asynchronously, and transfers the control to the SMM handler
If the logical processor executing inside an enclave receives an SMI when dual-monitor treatment is enabled, the logical processor exits the enclave asynchronously, and transfers the control to the SMM monitor via SMM VM exit.
All processor registers saved in the SMRAM have the same synthetic values listed in Section 4.3.
Технология Intel Software Guard Extensions в картинках