Кольца защищенного режима разделяют привилегированный код ядра и код приложений, а также отделяют приложения друг от друга. Однако при этом приложения не защищены от атак со стороны привилегированного кода. Зловредное приложение может проникнуть в него с помощью эксплойта и затем внедриться в беззащитную жертву. При этом участок для атаки очень широк: нападать можно и на компоненты ОС, и на само приложение, и даже на аппаратную подсистему.
Смысл SGX состоит в том, чтобы сузить периметр защиты, разместив все критически важные данные в отдельных областях-анклавах, недоступные даже из кода ядра. При этом, однако, не должен коренным образом изменяться процесс разработки и среда, где исполняется приложение.
Приложение состоит из двух частей: доверенного и общего. При запуске оно создает анклав в защищенной части памяти, состоящий из страниц размером 4 Кб. При вызове доверенной функции она видит данные анклава, любой другой внешний доступ (в том числе и со стороны ОС) запрещен. После окончания работы функции анклав остается в защищенной области.
Среда защищенного исполнения встроена в пользовательский процесс, у нее собственные код и данные. Она обеспечивает безопасность, целостность данных, контроль входных точек, поддерживает многопоточность.
При попытке доступа к анклаву проверяется, находятся ли по данному адресу данные вызывающего процесса (EPC, Enclave Page Cache). Далее подвергаются контролю полномочия функции (EPCM, Enclave Page Cache Metadata), и только потом предоставляется требуемый доступ.
Аттестация происходит следующим образом. Анклав запрашивает аппаратно подписанный отчет, содержащий, в том числе информацию о целостности анклава. Этот отчет отсылается на аттестующий сервер, где происходит его верификация. Анклаву высылается ключ приложения (открытая часть ключа), где генерируется подписывающий (приватный) ключ, зависящий от анклава и платформы. Ключ приложения шифруется подписывающим ключом и сохраняется для дальнейшего использования.
Функционал Intel Software Guard Extensions реализуется с помощью комбинации SGX инструкций, поддерживающих локальную аттестацию и предоставляемого Intel аттестационного анклава для поддержки удаленной аттестации.
Разработчики SGX предусмотрели защиту от различного рода атак на данные и код: угрозы со стороны пользовательского и системного ПО, а также загрузчика. Заметим, что средствами SGX невозможно защититься от side-channel уязвимостей, когда злоумышленники собирают статистику использования ЦПУ для определения характеристик исполняемого на нем кода. Для решения подобного рода задач предназначены средства динамического анализа программ, такие, например, как Pin.
Для предотвращения перехвата данных при обмене между процессором и памятью используется Memory Encryption Engine (MEE), работающий как расширение контроллера памяти и поддерживающий технологию SGX. Для определенных областей памяти осуществляется шифрование данных, передающихся по шине. MEE использует специальные комбинации криптографических примитивов для эффективного шифрования при очень жестких требованиях по задержкам.
Как выглядит разработка приложений, поддерживающих SGX? Чувствительные фрагменты кода и данных размещаются в отдельном shared object (.so). Далее определяются интерфейса анклава и генерируются заглушки. Библиотеки SGX взаимодействуют с кодом через API, для разработки используются обычные, привычные для разработчика тулчейны. Для облегчения процесса обработки уже имеется Intel SGX SDK.
Что обещает нам технология Intel SGX? Прежде всего то, что требования к техническим навыкам пользователя, работающего с конфиденциальной информацией, могут быть сильно сокращены. Ей больше не страшны вирусы, трояны и странные программы, которые могут иметься на его компьютере. Далее, повысится доверие к облачным платформам – им можно будет доверять свои приложения, поскольку они будут защищены от любого кода хоста. Конечно, все это дело довольно далекого будущего, ведь процессоры Skylake еще только появились. Но использовать SGX можно уже сейчас. Мы готовы углубляться в эту тему и отвечать на любые вопросы, с ней связанные.
