Аппаратное шифрование DRAM уже близко. Чем оно грозит простым пользователям?
Существует масса вариантов для шифрования дисков, разделов и отдельных документов. На случай компрометации одного устройства есть даже федеративное распределение ключа, где для доступа требуется участие нескольких сторон (см. схему разделения секрета Шамира). Опции шифрования файловой системы предлагают широкий выбор возможностей, которые можно считать стандартной практикой для защиты статичных данных.
Другое дело — данные в оперативной памяти. Они хранятся в открытом виде и так же открыто передаются между памятью и CPU. В виртуализированной среде, если злоумышленник нашёл способ считать память с соседних виртуальных машин, он может получить доступ к данным других VM на сервере. Физические атаки возможны путём копирования чипов памяти или перехвата данных на шине. Угроза ещё более серьёзная в случае постоянной памяти, где данные сохраняются даже после отключения питания.
Технологии шифрования RAM направлены на устранение некоторых из этих атак. Хотя есть опасения, что на персональных компьютерах проявятся неожиданные «побочные эффекты» — например, невзламываемый DRM.
Intel и AMD предлагают свои схемы аппаратного шифрования данных в памяти.
Шифрование Intel
В конце 2017 года Intel предложила расширение набора инструкций x86 под названием Total Memory Encryption (TME) для полного шифрования физической памяти DRAM и NVRAM одним эфемерным ключом. В ближайшее время TME планируется дополнить расширением Multi-Key Total Memory Encryption (MKTME) с поддержкой нескольких ключей и возможностью постраничного шифрования памяти разными ключами и разными приложениями.
Чтобы сохранить совместимость с текущим программным обеспечением, внутри процессора данные остаются в открытом виде, также как и в кэшах CPU. Они шифруются на уровне контроллера памяти и поступают в DRAM уже в зашифрованном виде.
Шифрование по алгоритму AES-XTS-128 выполняет движок AES-XTS, который физически находится около шины памяти.
Схема TME предусматривает генерацию ключа процессором и полное шифрование всей памяти. Это шифрование включается и выключается в BIOS, оно прозрачно для ОС и приложений.
MKTME вводит отдельные ключи для шифрования разных страниц памяти. Разработана специальная схема адресации памяти с помощью keyID (15 бит физического адреса). Для работы MKTME по-прежнему требуется активация TME в BIOS, однако с помощью MKTME можно отключить шифрование отдельных регионов памяти, сделанное TME.
Одна из главных задач раздельного шифрования памяти — более надёжная изоляция виртуальных машин в дата-центре. С помощью keyID отдельным ключом можно зашифровать память каждой виртуальной машины в рантайме. Для разных виртуальных машин — разные keyID. Ключи шифрования теперь можно генерировать не на аппаратном, а на программном уровне.
Поддержка MKTME в ядре Linux
Поскольку Intel планирует реализовать MKTME в своих будущих процессорах, компания в сентябре 2018 года позаботилась о поддержке MKTME на уровне ядра Linux, а спустя несколько месяцев представила обновлённый RFC для API с поддержкой MKTME. Один из основных разработчиков обоих патчей — белорусский хакер Кирилл Шутемов, см. его комментарии в обсуждении патча для ядра Linux.
Новые программные интерфейсы поддерживают пользовательский интерфейс для настройки шифрования и ключей, назначения keyID для областей памяти и хранилища ключей на случай «горячей» замены CPU.
Патч для ядра Linux включает примеры использования новых функций API:
// Add a 'user' type key::
char \*options_USER = "type=user
algorithm=aes-xts-128
key=12345678912345671234567891234567
tweak=12345678912345671234567891234567";
key = add_key("mktme", "name", options_USER, strlen(options_USER),
KEY_SPEC_THREAD_KEYRING);
// Add a 'cpu' type key::
char \*options_USER = "type=cpu algorithm=aes-xts-128";
key = add_key("mktme", "name", options_CPU, strlen(options_CPU),
KEY_SPEC_THREAD_KEYRING);
// Update a key to 'Clear' type::
ret = keyctl(KEYCTL_UPDATE, key, "type=clear", strlen(options_CLEAR);
// Add a "no-encrypt' type key::
key = add_key("mktme", "name", "no-encrypt", strlen(options_CPU),
KEY_SPEC_THREAD_KEYRING);
Несколько разработчиков ядра Linux высказали возражения против предложенных изменений в API, указывая на проблемы с когерентностью кэша и на угрозу утечки ключей из-за «холодного» хранилища, которое вводят на случай замены CPU.
Кто-то усомнился, что MKTME вообще помогает изоляции виртуальных машин, поскольку контроллер памяти не знает, откуда поступает каждый конкретный запрос на доступ к памяти. В самом деле, если вредоносный код исполняется внутри гипервизора, то MKTME ничем не может помочь.
Вероятно, разработчики сделают изменения в этом патче перед коммитом в основную ветку.
Альтернатива от AMD
Аналогичная TME технология шифрования памяти от AMD называется Secure Memory Encryption (SME). Как и TME, её нужно включить в BIOS, после чего процессор генерирует единственный ключ, которым шифруется вся память прозрачно для любой операционной системы и приложений.
Расширение Secure Encrypted Virtualization (SEV) предусматривает выделение отдельных ключей для каждой виртуальной машины. Каждая VM указывает, какие страницы памяти зашифровать. Управлением ключами занимается AMD Secure Processor.
Перечисленные компоненты реализованы в серверных процессорах AMD EPYC. Судя по описанию, технология SEV очень похожа на MKTME. Точно так же технология SEV бессильна, если вредоносный код запускается из гипервизора (см. описание атаки SEVered).
В июне 2019 года полная поддержка технологии SEV была реализована в SUSE Linux Enterprise 15 Service Pack 1.
Обратная сторона шифрования
Обратная сторона шифрования — когда информацию защищаем не мы, а её защищают от нас. Неприятно, если такие манипуляции производят посторонние лица (правообладатели) на вашем собственном компьютере.
Аппаратное шифрование данных в памяти немного пугает некоторых пользователей. Они согласны, что это полезная технология для серверов с виртуальными машинами, но видят угрозу для обычных людей, особенно при наличии соответствующих API: «У шифрования памяти есть очевидные ниши использования, но оно кажется немного за пределами общей модели угроз для большинства людей (пользователей). Для обычного человека более вероятный вариант использования, вероятно, враждебен: это DRM, защита от несанкционированного доступа в стиле Denuvo», — пишет один из участников обсуждения на HN.
Возможно, в этих опасениях есть рациональное зерно. Наверняка правообладатели увидят в этой технологии вариант защиты лицензионного контента от копирования. Получится это у них или нет? Многое зависит от конкретной реализации программных интерфейсов.
