Расширения Intel SGX

Расширения Intel Software Guard Extensions (Intel SGX) — набор инструкций центрального процессора, предоставляющих возможность приложению создавать анклавы — области в виртуальном адресном пространстве, защищённые от чтения и записи извне этой области другими процессами, включая ядро операционной системы. Intel SGX обеспечивают целостность и конфиденциальность вычислений с повышенными требованиями к безопасности, производимыми на системах, где привилегированные процессы (ядро операционной системы, гипервизор, и т. д.) считаются ненадёжными.

Intel SGX создан для применения в безопасных удалённых вычислениях, безопасного просмотра веб-страниц и защиты авторских прав. Другие практические применения данной технологии включают обеспечение конфиденциальности проприетарных алгоритмов и ключей шифрования.

История создания

Расширения Intel SGX появились в 2015 году с шестым поколением микропроцессоров Intel, основанным на микроархитектуре Skylake. Начиная со Skylake в процессоре появился новый аппаратный модуль под названием Memory Encryption Engine (MEE), позволяющий автоматически зашифровывать данные, передаваемые от процессора к области памяти анклава. Это позволило отказаться от допущения надёжности оперативной памяти и ограничить периметр безопасности одним центральным процессором, что и сделало возможным создание SGX[1].

В 2016 году была представлена вторая версия технологии SGX, названная SGX2. Она расширила набор инструкций SGX1 возможностью динамического управления памятью анклавов. SGX1 налагал ограничения, касающиеся выделения памяти и повторного использования памяти анклава — разработчик обязан был выделять всю память при создании экземпляра анклава. В SGX2 были представлены новые инструкции и модели программирования для расширения поддержки динамического управления памятью анклава[2].

Поддерживается только в процессорах Intel Core поколений 7000, 8000, 9000 и 10000 (в процессорах Core 11 и 12 поколений поддержка технологии SGX удалена), также серверными процессорами Intel Xeon Scalabale третьего поколения. Процессоры компании AMD не поддерживают SGX.[3]

Постановка проблемы

Прежде всего, технология SGX была создана для возможности безопасных удалённых вычислений — запуска программного обеспечения на удалённом компьютере, принадлежащем ненадёжной стороне, с некоторыми гарантиями целостности и конфиденциальности. В общем случае, безопасные удалённые вычисления — это нерешённая проблема. Полностью гомоморфное шифрование решает проблему для ограниченного семейства вычислений, но имеет непрактичные накладные расходы производительности[4].

Расширения Intel SGX решают проблему безопасных удалённых вычислений путём использования надёжного оборудования на удалённом компьютере. Подлинность оборудования устанавливается в процессе аттестации. Надёжное оборудование создаёт «безопасную область», и пользователь службы удалённых вычислений может загружать необходимый код и данные в эту «область». Надёжное оборудование защищает конфиденциальность и целостность данных во время выполнения вычислений на нём[5].

Цели

Разработка Intel SGX преследовала 8 основных целей[6]:

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

Детали устройства

SGX выделяет область памяти, называемую зарезервированной памятью процессора (Processor Reserved Memory, PRM). Процессор защищает PRM от всех неанклавных обращений к памяти, включая доступ ядра, гипервизора и режима системного управления (System Management Mode, SMM), а также доступ DMA от периферийных устройств[5][7].

PRM содержит Enclave Page Cache (EPC), который состоит из 4-килобайтных страниц, в которых хранятся код и данные анклавов. Ненадёжное системное программное обеспечение отвечает за назначение страниц EPC анклавам. Центральный процессор отслеживает состояние каждой страницы EPC в метаданных кэша страниц анклава (Enclave Page Cache Metadata, EPCM), чтобы гарантировать, что каждая страница EPC принадлежит только одному анклаву[7].

Исходный код и данные в анклаве загружаются ненадёжным системным программным обеспечением. На этапе загрузки системное программное обеспечение просит центральный процессор скопировать данные из незащищённой памяти (вне PRM) на страницы EPC и назначает страницы для устанавливаемого анклава. Отсюда следует, что начальное состояние анклава известно системному программному обеспечению[5][7].

После того, как все страницы анклава загружены в EPC, системное программное обеспечение просит центральный процессор пометить анклав как инициализированный, после чего прикладное программное обеспечение может выполнить код внутри анклава. После инициализации анклава запрещается способ загрузки, описанный выше[5][7].

Пока анклав загружается, на основе его содержимого вычисляется криптографический хэш. После инициализации анклава процесс хеширования завершается и полученный хэш становится проверочным хэшем анклава (measurement hash)[8].

Удалённая сторона может пройти процедуру аттестации, чтобы убедиться, что она обменивается данными с анклавом, который имеет определённый проверочный хэш и работает в защищённой среде[9].

Поток выполнения может войти в анклав только через специальные инструкции центрального процессора, которые аналогичны механизму переключения из режима пользователя в режим ядра. Выполнение анклава всегда происходит в защищённом режиме, на кольце 3, и использует трансляцию адресов, установленную ядром ОС и гипервизором[5][7].

Чтобы избежать утечки конфиденциальных данных, во время выполнения кода анклава центральный процессор не обслуживает прерывания (например, page fault) или выход виртуальной машины (vmexit). Вместо этого центральный процессор сначала выполняет Асинхронный выход из анклава (Asynchronous Enclave Exit, AEX), чтобы переключиться с кода анклава на код кольца 3, а затем обслуживает прерывание или выход виртуальной машины. Центральный процессор выполняет AEX, сохраняя своё состояние в предварительно определённой области внутри анклава, и передаёт управление предварительно определённой инструкции вне анклава, заменяя регистры центрального процессора синтетическими значениями[5][7].

Выделение страниц EPC для анклавов делегируется ядру операционной системы (или гипервизору). Операционная система сообщает о своих решениях о выделении памяти реализации SGX посредством специальных инструкций центрального процессора кольца 0. Операционная система также может выгружать страницы EPC в ненадёжную оперативную память, а затем загружать их обратно, используя специальные инструкции процессора[5].

SGX использует Memory Encryption Engine (MEE), чтобы обеспечить конфиденциальность, целостность и актуальность выгруженных страниц EPC, пока они хранятся в ненадёжной памяти[5]. MME работает как расширение блока управления памятью и автоматически зашифровывает все данные, передаваемые от процессора к памяти[10].

Дизайн приложений

Дизайн приложения с Intel SGX требует, чтобы приложение было разделено на два компонента[9]:

  • Доверенный компонент — это анклав, содержащий код оперирующий с секретами приложения. В приложении может быть более одного доверенного компонента/анклава.
  • Ненадёжный компонент — остальная часть приложения. Важно отметить, операционная система и гипервизор считаются ненадёжными компонентами.

Доверенный компонент должен быть ограничен только теми данными, которые нуждаются в наибольшей защите, и теми операциями, которые должны взаимодействовать с ними. Большой анклав со сложным интерфейсом не только потребляет больше защищённой памяти, он также увеличивает площадь атаки. Анклавы также должны иметь минимальное взаимодействие доверенных компонентов. Хотя анклавы и могут вызывать функции в ненадёжном компоненте (с помощью специальной инструкции), ограничение таких вызовов укрепит анклав от атак[8][9].

Аттестация

В архитектуре Intel SGX аттестацией называется процесс подтверждения подлинности анклава. Существует два механизма аттестации[9]:

  • Локальная аттестация происходит, когда два анклава на одной платформе выполняют взаимную проверку подлинности.
  • Удалённая аттестация происходит, когда анклав получает доверие удалённой стороны.

Локальная аттестация

Локальная аттестация полезна, когда приложение имеет более одного анклава, которые должны работать совместно, или когда два приложения должны обмениваться данными между анклавами[9].

В процессе аттестации между двумя анклавами каждый анклав сначала должен убедиться, что второй заслуживает доверия. Анклав подтверждает свою подлинность другому целевому анклаву с помощью инструкции EREPORT. Эта инструкция SGX создаёт отчёт об аттестации (REPORT), который криптографически связывает сообщение анклава с идентификационными данными, основанными на хэше анклава и на основе сертификатов. Криптографическое связывание выполняется с помощью специального тэга, вычисленного с использованием симметричного ключа, который доступен только целевому анклаву и реализации SGX[5].

После этого анклавы могут установить защищённый сеанс, используя протокол Диффи-Хеллмана для обмена сеансовым ключом. Этот сеансовый ключ может использоваться для шифрования данных, которые должны быть разделены между двумя анклавами[9].

Поскольку один анклав не может получить доступ к защищённому пространству памяти другого анклава, даже если они принадлежат одному приложению, все указатели должны быть разыменованы, и между анклавами должны передаваться непосредственно данные[9].

Удалённая аттестация

Процесс аттестации выглядит следующим образом. Процессор с поддержкой SGX вычисляет хэш кода и данных в каждом анклаве. Программное обеспечение внутри анклава запускает процесс вычисления подписи аттестации SGX, которая включает хэш анклава и сообщение анклава[8].

Криптографический примитив, используемый в подписи аттестации SGX, слишком сложен, чтобы его можно было реализовать на аппаратном уровне, поэтому процесс подписи выполняется привилегированным Quoting Enclave, предоставляемым Intel, и имеющим доступ к ключу аттестации SGX — уникальному для каждой платформы асимметричному ключу от аппаратного обеспечения. Ключ аттестации SGX не существует на момент создания процессора. Он выдаётся позже, с помощью Provisioning Enclave, предоставляемого Intel[5].

Так как подпись вычисляется в Quoting Enclave, существует необходимость в безопасном канале связи между анклавом, проходящим аттестацию программного обеспечения, и Quoting Enclave. Эта проблема решается с помощью механизма локальной аттестации[5].

Если удалённый сервер определяет, что анклав был должным образом создан и работает на подлинном процессоре с поддержкой Intel SGX, он теперь может доверять анклаву и передавать ему секреты по доверенному каналу[9].

Безопасность

При удалённых вычислениях содержимое анклава загружается системным программным обеспечением на компьютер и, следовательно, не должно содержать секреты в незашифрованном виде. После инициализации проходит процесс аттестации, когда анклав аутентифицируется на удалённом сервере. Ожидается, что после успешной аутентификации удалённый сервер раскроет некоторые секреты анклаву по безопасному каналу связи. Дизайн Intel SGX пытается гарантировать, что хэш, посчитанный во время процесса аттестации, точно отражает содержимое, загруженное в анклав[8].

SGX также предлагает систему идентификации на основе сертификатов. Её используют для обмена секретами между анклавами, которые имеют сертификаты, выданные одним и тем же центром сертификации. Процесс обмена включает в себя шифрование секретов перед передачей их ненадёжному системному программному обеспечению, которое осуществляет их передачу в другой анклав[5][8].

Этот же механизм можно использовать для кэширования секретов, полученных во время процесса аттестации, на ненадёжных носителях данных, управляемых системным программным обеспечением. Это кэширование может сократить число процессов аттестации в распределённой системе[5].

Атака Prime+Probe

27 марта 2017 года исследователи из Грацского технического университета разработали прототип, способный с помощью атаки по времени в течение пяти минут получать ключи RSA из анклавов SGX, работающих на той же системе[11][12]. Одна из мер противодействия этому типу атаки была представлена и опубликована Daniel Gruss et al. на симпозиуме по безопасности USENIX в 2017 году[13]. Среди других опубликованных контрмер 28 сентября 2017 г. была утилита DR.SGX. Утверждается, что DR.SGX обладает превосходной производительностью и при этом гораздо проще в реализации, чем другие предлагаемые решения[14].

Атаки типа Spectre

Группа LSDS в лондонском Имперском колледже продемонстрировала, что спекулятивная уязвимость безопасности Spectre может быть адаптирована для атаки на анклав[15]. Атака Foreshadow, раскрытая в августе 2018 года, сочетает спекулятивное выполнение и переполнение буфера для обхода SGX[16].

Атака анклава

8 февраля 2019 года исследователи из Грацского технического университета опубликовали результаты исследований, которые показали, что в некоторых случаях можно запускать вредоносный код из самого анклава[17]. В документе утверждается, что из-за конфиденциальной и защищённой природы анклава антивирусное программное обеспечение не может обнаружить и удалить находящиеся в нём вредоносные программы. Однако, поскольку современные антивирусные решения отслеживают системные вызовы и взаимодействие приложения с операционной системой, должна быть возможность идентифицировать вредоносные анклавы по их поведению. Корпорация Intel опубликовала заявление, в котором говорилось, что эта атака была за пределами модели угроз SGX, что они не могут гарантировать, что код, выполняемый пользователем, поступает из надёжных источников, и призвала потребителей использовать только доверенный код[18].

Атака «утконос»

Исследователи из Грацского университета в Австрии обнаружили новую опасную уязвимость, основанную на измерении напряжения процессора, которая позволяет извлекать AES- и RSA-ключи из защищённого анклава SGX. Такая возможность присутствует во всех процессорах Intel, начиная с Sandy Bridge, в которых функции северного моста были полностью заменены интегрированным в кристалл процессора системным агентом. Уязвимость эксплуатирует нетребующую привилегированного доступа возможность системы RAPL (Running Average Power Limit) получать подробные оценки энергопотребления ядром, системным агентом и DRAM[19]. Для борьбы с уязвимостью Intel выпустила микрокод с исправлением (INTEL-SA-0389[20]).

Извлечение закрытого ключа

Кодовая подпись генерируется с помощью закрытого ключа, который хранится только в анклаве. Закрытый ключ кодируется с помощью элементов «предохранителя» на чипе. При этом биты прожигаются, придавая им двоичное значение 0. Этот закрытый ключ невозможно извлечь, поскольку он закодирован в аппаратном обеспечении. Марк Ермолов, Максим Горячий и Дмитрий Скляров опровергли утверждение о том, что концепция SGX заслуживает доверия, на сайте https://github.com/chip-red-pill/glm-ucode#.

Примечания

  1. Simon Johnson. The Intel® SGX Memory Encryption Engine (англ.). software.intel.com (26 февраля 2016). Дата обращения: 7 декабря 2019. Архивировано 7 декабря 2019 года.
  2. McKeen, Frank & Alexandrovich, Ilya & Anati, Ittai & Caspi, Dror & Johnson, Simon & Leslie-Hurd, Rebekah & Rozas, Carlos. Intel® Software Guard Extensions (Intel® SGX) Support for Dynamic Memory Management Inside an Enclave. // Conference: the Hardware and Architectural Support for Security and Privacy. — 2016.
  3. Intel запретила владельцам своих новых процессоров смотреть лицензионные фильмы с дисков в 4K Архивная копия от 18 января 2022 на Wayback Machine // CNews, 17 Января 2022
  4. Michael Naehrig, Kristin Lauter, and Vinod Vaikun- tanathan. Can homomorphic encryption be practical? // Proceedings of the 3rd ACM workshop on Cloud computing security workshop. — 2011. — С. 113–124. Архивировано 22 сентября 2020 года.
  5. 1 2 3 4 5 6 7 8 9 10 11 12 13 Victor Costan and Srinivas Devadas. Intel SGX Explained // Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology. Архивировано 4 мая 2020 года.
  6. Matthew H. Intel® SGX for Dummies (Intel® SGX Design Objectives) (англ.). software.intel.com (2013-26-09). Дата обращения: 7 декабря 2019. Архивировано 29 апреля 2014 года.
  7. 1 2 3 4 5 6 Alexandre Adamski. Overview of Intel SGX - Part 1, SGX Internals (5 июля 2018). Дата обращения: 24 декабря 2019. Архивировано 24 декабря 2019 года.
  8. 1 2 3 4 5 Ittai Anati, Shay Gueron, Simon P Johnson, Vincent R Scarlata. Innovative Technology for CPU Based Attestation and Sealing // Intel Corporation. — 2013. Архивировано 24 декабря 2019 года.
  9. 1 2 3 4 5 6 7 8 John M., Benjamin O. Intel® Software Guard Extensions Tutorial Series: Part 1, Intel® SGX Foundation (англ.). software.intel.com (7 июля 2016). Дата обращения: 7 декабря 2019. Архивировано 7 декабря 2019 года.
  10. Shay Gueron. [https://eprint.iacr.org/2016/204.pdf A memory encryption engine suitable for general purpose processors] // Cryptology ePrint Archive. — 2016. Архивировано 15 июня 2020 года.
  11. Schwarz, Michael; Weiser, Samuel; Gruss, Daniel; Maurice, Clémentine; Mangard, Stefan (2017). "Malware Guard Extension: Using SGX to Conceal Cache Attacks". arXiv:1702.08719 [cs.CR].
  12. Chirgwin, Richard (2017-03-07). "Boffins show Intel's SGX can leak crypto keys". The Register. Архивировано 11 июля 2019. Дата обращения: 1 мая 2017. {{cite news}}: Указан более чем один параметр |author= and |last1= (справка)
  13. Daniel Gruss, Julian Lettner, Felix Schuster, Olya Ohrimenko, Istvan Haller, and Manuel Costa. Strong and Efficient Cache Side-Channel Protection using Hardware Transactional Memory. USENIX (16 августа 2017). Дата обращения: 7 декабря 2019. Архивировано 27 июля 2020 года.
  14. Brasser, Ferdinand; Capkun, Srdjan; Dmitrienko, Alexandra; Frassetto, Tommaso; Kostiainen, Kari; Müller, Urs; Sadeghi, Ahmad-Reza (2017-09-28). "DR.SGX: Hardening SGX Enclaves against Cache Attacks with Data Location Randomization". arXiv:1709.09917 [cs.CR].
  15. Dan O'Keeffe, Divya Muthukumaran, Pierre-Louis Aublin, Florian Kelbert, Christian Priebe, Josh Lind, Huanzhou Zhu and Peter Pietzuch. SGXSpectre. Дата обращения: 7 декабря 2019. Архивировано 7 мая 2020 года.
  16. Peter Bright - Jul 10, 2018 9:00 pm UTC. New Spectre-like attack uses speculative execution to overflow buffers. Ars Technica (10 июля 2018). Дата обращения: 2 ноября 2018. Архивировано 23 ноября 2018 года.
  17. Schwarz, Michael; Weiser, Samuel; Gruss, Daniel (2019-02-08). "Practical Enclave Malware with Intel SGX". arXiv:1902.03256 [cs.CR].
  18. Bright, Peter Researchers use Intel SGX to put malware beyond the reach of antivirus software (амер. англ.). Ars Technica (12 февраля 2019). Дата обращения: 15 февраля 2019. Архивировано 15 февраля 2019 года.
  19. Геннадий Детинич. Атака «утконос»: датчики потребления процессоров Intel оказались брешью в безопасности. 3dnews.ru (11 ноября 2020). Дата обращения: 11 ноября 2020. Архивировано 11 ноября 2020 года.
  20. 2020.2 IPU - Intel® RAPL Interface Advisory (англ.). ww.intel.com (10 ноября 2020). Дата обращения: 11 ноября 2020. Архивировано 10 ноября 2020 года.

Ссылки