Прозрачная криптография от AMD

Наше первое знакомство с криптографическими спо­соб­нос­тями про­цес­со­ров AMD состоялось в прошлом году. Объектом ис­сле­до­ваний стала сер­вер­ная платформа ASUS RS700A-E9-RS4, оснащенная сис­темной пла­той KNPP-D32 под процессоры AMD EPYC. Ком­пью­те­ры та­ко­го клас­са вряд ли станут когда-нибудь «на­род­ны­ми». Новый вал эн­ту­зи­аз­ма воз­ник с по­яв­ле­ни­ем у нас «де­мо­кра­тич­ной» платы MSI MS-7A31 с про­цес­со­ром AMD Ryzen 5 1600 на борту. По­ста­ра­ем­ся оценить защищенность это­­го семейства про­цес­со­ров AMD с ее помощью.

Дифференциация архитектур защиты

Из официальной презентации спикера AMD Девида Каплана, ведущего специалиста по разработке процессорных архитектур, следует, что…

• во-первых, архитектур защиты памяти две: Secure Memory Encryption и Secure Encrypted Virtualization;
• во-вторых, они аппаратно реализованы AMD Platform Security Processor и используют технологию Trusted­Zone встроенного в кристалл Ryzen ядра 32-битного про­цес­со­ра ARM Cortex-A5.

Исходя из общности аппаратного базиса, попробуем сравнить программную надстройку защиты памяти — SME и SEV. Но сначала определим, для каких нужд существует каждая из них и почему, собственно, в AMD Ryzen 5 их две?

Для начала рассмотрим, как представлена функциональность SME и SEV в самом процессоре. Поможет нам в этом функция 8000001Fh инструкции CPUID. Бит 0 регистра EAX индицирует поддержку SME, бит 1 — SEV. Исходя из по­лу­чен­ных результатов, оба криптографических расширения есть в исследуемом процессоре AMD Ryzen 5 1600.

SME (Secure Memory Encryption) позиционируется как метод защиты от атак, основанных на физическом под­клю­че­нии к шине оперативной памяти — DRAM. Акцент этой архитектуры — на защите от физического вмешательства в ра­бо­ту плат­фор­мы с подключением логических анализаторов к сигнальным цепям DIMM-модулей. Мониторинг bus-master уст­ройств, подключенных к PCIe-шине и взаимодействующих с оперативной памятью посредством ле­галь­ной сис­те­мы арбитража, не входит в круг обязанностей SME.

SEV (Secure Encrypted Virtualization) также защищает от физических атак, но в контексте аппаратной вир­ту­а­ли­за­ции. Эта архитектура декларирует защиту гостевых задач от зловредного программного обеспечения, рас­по­ла­га­ю­ще­го пол­но­мо­чи­я­ми гипервизора виртуализации.

Верифицировать возможности SEV в среде виртуализации также можно силами инструкции CPUID. После вы­пол­не­ния ее функции 8000001Fh регистр ECX содержит информацию о максимально поддерживаемом количестве од­новременно работающих зашифрованных гостевых ОС. Для исследуемого процессора оно равно 15 (иден­ти­фи­ка­то­ры гостевых задач ASID — Address Space Identifier — нумеруются натуральными числами от 1 до 15).

Чем богаты архитектуры SME и SEV?

Представление о богатстве возможностей обеих архитектур дает один из слайдов презентации «AMD x86 Memory Encryption Technology»:

Разобравшись с назначением криптоархитектур, нетрудно пояснить смысл строки Keys. Технология SME использует единственный защитный ключ, в то время как для защиты виртуальных машин (согласно модели SEV), каждая вир­ту­аль­ная машина, охраняя собственные секреты, должна иметь собственный ключ.

Строка Encryption enabled by поясняет метод управления защитой с учетом того, что в данном процессе за­дей­ство­ва­на подсистема виртуальной памяти и трансляции страниц, а разрешает шифрование добавленный бит C (en­Crypt­ed) дескриптора страницы PTE (Page Table Entry).

Управление оперативной памятью в защищенном режиме процессора имеет свои особенности в каждой из ар­хи­тек­тур:

• SME, как функциональность физической платформы, использует дескрипторы страниц подсистемы вир­ту­аль­ной памяти хостовой ОС, что обозначено термином Native page tables;
• SEV, как функциональность виртуальной машины, использует дескрипторы страниц подсистемы вир­ту­аль­ной памяти гостевой ОС, что обозначено термином Guest page tables.

Строка DMA иллюстрирует принципы организации прямого доступа к памяти и работы bus master устройств. Как было сказано выше, SME не препятствует работе bus master устройств в рамках легального арбитража доступа к контроллеру DRAM, входящего в состав микросхемы CPU. Доступ возможен к любой странице — Any page. SEV, на­про­тив, дает гостевой ОС возможность управления доступностью своих страниц, что обозначено комментарием Only to shared pages.

Критерий Default page behavior when CR 4. PAE=0 отражает особенности шифрования в переходных со­сто­я­ни­ях, ког­да 64-битная трансляция страниц отключена. SME в этом случае отключается (Unencrypted), SEV де­ле­ги­ру­ет пол­но­мо­чия управления виртуальной машине, о чем говорит комментарий Private ( encrypted with guest key).

Примечание Режим PAE (Physical Address Extension) увеличивает размер дескрипторов страниц с 4 до 8 байт, что необходимо при 64-битной адресации. Использование PAE обязательно в 64-битном и опционально в 32-битном Protected Mode.

Критерий Requires AMD Secure Processor x86 Driver уточняет, что для технологии SME не требуется драйвер, осу­ще­ствля­ю­щий коммуникацию между программным обеспечением хост-платформы и специализированным крип­то­гра­фи­че­ским процессором. Для технологии SEV, передающей важные полномочия гостевой ОС, коммуникация с криптографическим процессором, в частности управление ключами шифрования, а следовательно и указанный драйвер, требуются. Документ «Secure Encrypted Virtualization API Specification» стандартизует API такого драй­ве­ра, со­глас­но модели «черного ящика», определяя программный интерфейс и оставляя ряд аппаратных осо­бен­но­с­тей в ста­ту­се проприетарных.

И наконец, последний критерий Software impacted можно назвать «критерием прозрачности». Он показывает, ка­кое программное обеспечение требует модификации для поддержки рассматриваемых технологий защиты. Как вид­но из таблицы, технология SME требует поддержки со стороны хост-ОС и гипервизоров виртуализации. При­ме­не­ние SEV невозможно без участия гостевых ОС виртуальных машин, о чем говорит комментарий guest OS.

К вопросу об AMD Platform Security Processor

Шифрование данных, записываемых в DRAM, а равно расшифровка читаемых данных, основываются на при­ме­не­нии специализированного криптографического сопроцессора с собственным защищенным набором ресурсов вне адресного пространства хост-платформы. Такой шаг мотивирован двумя соображениями:

1. Аппаратная поддержка криптографических операций позволяет повысить скорость их выполнения, а следовательно минимизировать потери производительности, обусловленные применением защиты.
2. Критические с точки зрения безопасности ресурсы, вынесенные за пределы адресного пространства центрального процессора, становятся недоступными для атакующей стороны.

Низкоуровневый аппаратный интерфейс между CPU и AMD Platform Security Processor официально не до­ку­мен­ти­ро­ван, вместо этого системным программистам предоставляется набор сервисных вызовов (API). Позволим себе предположить, что продиктовано это не только соображениями интеллектуальной собственности и желанием под­нять уровень защищенности. Открывая аппаратные спецификации и разрешая непосредственный доступ к пор­т­ам и регистрам, как это было во времена IBM PC, производитель платформы связывает себя требованиями сов­мес­ти­мос­ти, поскольку внесение изменений в программную модель, ставшую стандартом, превращается в весь­ма бо­лез­нен­ный процесс.

Резюмируем

Сильной стороной решения AMD является «прозрачность» обеих технологий для приложений. Теоретически, в соответствии с последним из рассмотренных критериев, пользовательские программы не требуют модификации. В обоих случаях, требуется поддержка со стороны UEFI, данная особенность не отражена в сравнительной таблице в силу своей очевидности.

Технология SEV предполагает отход от канонов, дающих гипервизору виртуализации возможность доступа к приватным данным гостевых задач. Решение аргументируется необходимостью защиты виртуальных машин в облачных средах от злонамеренных действий руткитов — лиц или программ, имеющих полномочия сис­тем­но­го администратора.