Хабрахабр

Аппаратное шифрование DRAM уже близко. Чем оно грозит простым пользователям?

Существует масса вариантов для шифрования дисков, разделов и отдельных документов. На случай компрометации одного устройства есть даже федеративное распределение ключа, где для доступа требуется участие нескольких сторон (см. схему разделения секрета Шамира). Опции шифрования файловой системы предлагают широкий выбор возможностей, которые можно считать стандартной практикой для защиты статичных данных.

Они хранятся в открытом виде и так же открыто передаются между памятью и CPU. Другое дело — данные в оперативной памяти. Физические атаки возможны путём копирования чипов памяти или перехвата данных на шине. В виртуализированной среде, если злоумышленник нашёл способ считать память с соседних виртуальных машин, он может получить доступ к данным других VM на сервере. Угроза ещё более серьёзная в случае постоянной памяти, где данные сохраняются даже после отключения питания.

Хотя есть опасения, что на персональных компьютерах проявятся неожиданные «побочные эффекты» — например, невзламываемый DRM.
Intel и AMD предлагают свои схемы аппаратного шифрования данных в памяти. Технологии шифрования RAM направлены на устранение некоторых из этих атак.

Шифрование Intel

В конце 2017 года Intel предложила расширение набора инструкций x86 под названием Total Memory Encryption (TME) для полного шифрования физической памяти DRAM и NVRAM одним эфемерным ключом. В ближайшее время TME планируется дополнить расширением Multi-Key Total Memory Encryption (MKTME) с поддержкой нескольких ключей и возможностью постраничного шифрования памяти разными ключами и разными приложениями.

Они шифруются на уровне контроллера памяти и поступают в DRAM уже в зашифрованном виде. Чтобы сохранить совместимость с текущим программным обеспечением, внутри процессора данные остаются в открытом виде, также как и в кэшах CPU.

Шифрование по алгоритму AES-XTS-128 выполняет движок AES-XTS, который физически находится около шины памяти.

Это шифрование включается и выключается в BIOS, оно прозрачно для ОС и приложений. Схема TME предусматривает генерацию ключа процессором и полное шифрование всей памяти.

Разработана специальная схема адресации памяти с помощью keyID (15 бит физического адреса). MKTME вводит отдельные ключи для шифрования разных страниц памяти. Для работы 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, после чего процессор генерирует единственный ключ, которым шифруется вся память прозрачно для любой операционной системы и приложений.

Каждая VM указывает, какие страницы памяти зашифровать. Расширение Secure Encrypted Virtualization (SEV) предусматривает выделение отдельных ключей для каждой виртуальной машины. Управлением ключами занимается AMD Secure Processor.

Судя по описанию, технология SEV очень похожа на MKTME. Перечисленные компоненты реализованы в серверных процессорах AMD EPYC. описание атаки SEVered). Точно так же технология SEV бессильна, если вредоносный код запускается из гипервизора (см.

В июне 2019 года полная поддержка технологии SEV была реализована в SUSE Linux Enterprise 15 Service Pack 1.

Обратная сторона шифрования

Обратная сторона шифрования — когда информацию защищаем не мы, а её защищают от нас. Неприятно, если такие манипуляции производят посторонние лица (правообладатели) на вашем собственном компьютере.

Они согласны, что это полезная технология для серверов с виртуальными машинами, но видят угрозу для обычных людей, особенно при наличии соответствующих API: «У шифрования памяти есть очевидные ниши использования, но оно кажется немного за пределами общей модели угроз для большинства людей (пользователей). Аппаратное шифрование данных в памяти немного пугает некоторых пользователей. Для обычного человека более вероятный вариант использования, вероятно, враждебен: это DRM, защита от несанкционированного доступа в стиле Denuvo», — пишет один из участников обсуждения на HN.

Наверняка правообладатели увидят в этой технологии вариант защиты лицензионного контента от копирования. Возможно, в этих опасениях есть рациональное зерно. Многое зависит от конкретной реализации программных интерфейсов. Получится это у них или нет?

*П-с-с, читатель, статья закончилась, но у нас есть выгодное для тебя предложение:

* — Мы решили не делать целый рекламный пост про скидки, а просто оставили тут небольшой баннер 🙂

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть