Существует масса вариантов для шифрования дисков, разделов и отдельных документов. На случай компрометации одного устройства есть даже федеративное распределение ключа, где для доступа требуется участие нескольких сторон (см. схему разделения секрета Шамира). Опции шифрования файловой системы предлагают широкий выбор возможностей, которые можно считать стандартной практикой для защиты статичных данных.Другое дело — данные в оперативной памяти. Они хранятся в открытом виде и так же открыто передаются между памятью и 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.
Возможно, в этих опасениях есть рациональное зерно. Наверняка правообладатели увидят в этой технологии вариант защиты лицензионного контента от копирования. Получится это у них или нет? Многое зависит от конкретной реализации программных интерфейсов.
*П-с-с, читатель, статья закончилась, но у нас есть выгодное для тебя предложение:
* — Мы решили не делать целый рекламный пост про скидки, а просто оставили тут небольшой баннер :)
Комментарии (32)
vsb
29.11.2019 14:45+1Не представляю, как эту технологию можно использовать для DRM. По крайней мере в ОС, которую контролирует пользователь. Хотя можно представить её дальнейшее развитие, которые приведёт к DRM на уровне "сервер передал клиенту зашифрованный код, клиент его выполнил и получил результаты, причём ни код, ни промежуточные значения невозможно получить".
Xitsa
29.11.2019 17:35+2Шифрование памяти один из основных предусловий для Intel SGX — технологии, которая предназначена для безопасного от пользователя выполнения удалённого кода на компьютере пользователя.
grishkaa
01.12.2019 18:30Что в итоге мешает мне запустить такой код на эмуляторе процессора (например, qemu) и ничего не шифровать, или шифровать известным мне ключом? Что мешает пропатчить этот код и заменить инструкции, инициализирующие режим за-shit-ы памяти, на nop? Кажется, что от пользователя код защитить невозможно в принципе.
creker
01.12.2019 18:35Кажется, что от пользователя код защитить невозможно в принципе.
На консолях и телефонах вот защитили. У xbox one вон до сих пор нет ниодного публичного взлома. Если код подписан, то ничего там не поменяешь. А если еще и шифрован, то и эмулятор не поможет.grishkaa
01.12.2019 18:41Это верно. Но мы говорим о десктопных ОС и десктопном железе, где априори есть возможность запускать произвольный неподписанный код, в том числе загружать его в ядро (через модули ядра или патчи) или даже запускать до ядра, подсунув в загрузчик.
creker
01.12.2019 18:43Пока есть. Статья как раз клонит, что движение идет именно к закрытию лазеек.
grishkaa
01.12.2019 18:45Запретят загружаться в линукс, только в одобренную, зашифрованную, подписанную и не модифицируемую винду?)
Gutt
02.12.2019 10:02Нет, просто будет в процессоре зашит закрытый ключ асимметричного алгоритма шифрования, а всем роздан открытый ключ этой пары. И всё, никакая ОС этот код не рашифрует, а сможет только загрузить в память и выполнить.
trolley813
02.12.2019 13:28всем роздан открытый ключ этой пары
Если действительно всем, то это атас. Потому что, как уже ниже написали, начнется нашествие вирусов, с которыми ничего не сможет сделать ни один антивирус.
Xitsa
02.12.2019 10:22Потому что механизмы SGX как раз и предусматривают аппаратную защиту от таких действий: (я давно читал, поэтому могу слегка обманывать, лучше уточнить в оригинальной документации интел) код загружается в специальный домен, защищённый от всех, включая гипервизоры и аналогичные программы в соседних доменах, причём туда можно загрузить не любой код, а только от лицензированных партнёров (скорее всего подписанный зашитым в CPU ключом), этот код может получить слепок окружения и отправить на удалённую сторону.
Ни к коду, ни к стеку, ни к данным из других программ получить доступ нельзя (на самом деле есть дыры, но это детали конкретных реализаций, которые исследовали, в принципе, довольно суровая защита).
Соответственно удалённая сторона может определить, что у пользователя нужная ОС, что она не пропатчена, версии биоса, что загруженная программа совпадает с эталонной, что в памяти нет инжектированного кода и т. п.
proninyaroslav
30.11.2019 00:13Про "ОС, которую контролирует пользователь": может он её и контролирует, только вот она не может контролировать многие вещи на железном уровне. Те же ME, PSP, TrustZone, которые сами являются ОС и имеют доступ абсолютно ко всему в обход гостевой "пользовательской" ОС. Ну а шифрование памяти это как изюминка на торте всех этих ME и TtustZone. Хотя уже сейчас пользователь может хранить и проигрывать DRM-видео, при этом даже ядро не может получить доступ к памяти где хранятся разжатые и расшифрованные видео фреймы. Но при этом андроид может, к примеру, рисовать элементы управления поверх видео.
grishkaa
01.12.2019 18:35В андроиде это реализовано на уровне оконного сервера, при этом шифрование и декодирование отделены от, собственно, вывода. При выводе можно поставить окну флаг FLAG_SECURE. И есть особый пермишен, который разрешает приложению захватывать видео с экрана, включая защищённые окна, выдаётся только системным приложениям. Про TrustZone знаю, но предположу, что сама ОС всё равно имеет какой-то доступ к разжатым кадрам.
proninyaroslav
01.12.2019 18:41Вероятно зависит только от реализации TrustZone. Насколько слышал в Motorola было именно так.
Viceroyalty
29.11.2019 15:59+1Стесняюсь спросить: а какая прямая сторона? Зачем на пользовательской машине шифрование данных в оперативной памяти, да и на сервере тоже. Кроме особо защищённых токенов или какого-нибудь хитрого DRM вообще не вижу применения, это же не бесплатные вычислительных мощности — да и энергопотребление с теплопакетом не следует забывать. Ну ещё военные и госзаказ, но это совсем другая история.
Alexey2005
29.11.2019 16:08+1Например, позволит хостить всякую запрещёнку без боязни, что маски-шоу сделают дамп и используют его в качестве доказательства в суде.
romanetz_omsk
30.11.2019 08:41Для басманного суда такие сложные доказательства не нужны, достаточно будет "нотариально заверенного скриншота" и банковской транзакции за хостинг
Psychosynthesis
30.11.2019 07:10Когда читаю о защитах от атак на таком низком уровне мне становятся несколько вопросов интересны:
1. Сколько вообще взломов (ну хотя бы примерно, а?) было сделано с использованием дыр на таком низком уровне?
2. Кто-нибудь вообще думает о производительности? Читаем:
«Шифрование по алгоритму AES-XTS-128 выполняет движок AES-XTS, который физически находится около шины памяти.»
Даже DDR3 это десятки гигабайт в секунду. Даже допуская, что «движок» это некий ASIC (ну или что, например?), всё равно какую-то задержку это да принесёт.Brak0del
30.11.2019 08:51Даже DDR3 это десятки гигабайт в секунду. Даже допуская, что «движок» это некий ASIC (ну или что, например?), всё равно какую-то задержку это да принесёт.
Пренебрежимую? Ваш второй вопрос заинтересовал, попробую грубо прикинуть. В их доках на AES-XTS engine написано, что производительность 18 Гбит/с на частоте 3.2 ГГц (это не слишком много, сейчас ядра aes для плис умеют 100-400 Гбит/с на скромных частотах до 400 МГц). Далее, на шифрование 128-битного блока данных AES-ом надо порядка 30-50 тактов, при этом если задействована конвейеризация (режим вроде позволяет, зависимостей сходу не увидел), тогда за эти 30-50 тактов можно обработать несколько блоков по 128 бит. Итого, на обработку одного блока уйдет порядка 50*(1/3.2 ГГц) = 15.7 нс. С режимом XTS особо не знаком, судя по кратким описаниям, он позволяет работу с произвольными блоками без расшифровки всей страницы памяти. Мне кажется, эти задержки во-первых сопоставимы с задержками выборки данных из DDR, во-вторых, могут быть замаскированы конвейеризацией контроллером памяти и контроллером кэша. Но поправьте, если не прав, мне тоже интересно.DrunkBear
30.11.2019 14:10А стоит этот быстрый Плис сколько будет? теплоотвод нужен? Места на плате много займёт?
Brak0del
30.11.2019 15:13+1Уточню, не предлагаю использовать плис, стоить она будет дорого, да и незачем это делать. Однако привожу в пример то, что на плис (которые имеют сравнительно низкие тактовые частоты) уже давно делают быстрое шифрование. Следовательно, ASIC-реализация, врожденно допускающая более высокие тактовые частоты, может быть гораздо быстрее/экономнее/компактнее и т.д. Значит специализированное hardened-ядрышко шифрования (AES-XTS engine) внутри процессора проблем с производительностью вызвать не должно.
Psychosynthesis
30.11.2019 16:41Так вот именно что это с таймингами сопоставимо.
То есть такая память в среднем будет в два раза медленнее по таймингам.Brak0del
30.11.2019 17:27К сожалению моих знаний недостаточно, чтобы про это компетентно спорить. C вами согласен, что для выборки одиночного слова задержка возрастет где-то вдвое. Однако в контексте системы в контроллере памяти наверняка организована конвейеризация (хотя бы для тех же блочных режимов доступа), кроме того, там есть планировщик, который переставляет команды обращения к памяти для минимизации конфликтов по банкам. В результате, когда мы имеем выборку не одного слова, а нескольких, то ожидание в очередях до и после обработки запросов к памяти как раз может замаскировать задержку, вносимую шифрованием, для остальной системы.
creker
30.11.2019 18:47+1Совсем недавно был отличный доклад про безопасность xbox one www.youtube.com/watch?v=U7VwtOrwceo Там как раз используется аппаратное шифрование памяти и вообще кучи разных аппаратных защит. Насколько помню, xbox 360 тоже в каком-то виде это делал, чтобы предотвратить атаку по снифингу шины, которой взломали xbox. Тут как раз пример, когда это используется для DRM, защиты от пиратства, запуска неподписанного кода.
azatfr
02.12.2019 12:13Дополнительное шифрование ведет к дополнительным энергозатратам, дополнительные энергозатраты ведут к дополнительным финансовым затратам.
x86v
02.12.2019 12:13DRM, да… Сплю и вижу, как у тех же издателей (или кто там с DRM работает) утекут сертификаты/ключи, и тут же появятся вирусы, защищённые так же, как этот самый DRM, и ни один антивирус не сможет не то что дамп кода снять… возможно даже вообще узнать, выполняется что то постороннее, или это просто видео с бОльшим битрейтом и кастомными настройками декодера. А как быть, например, с недокументированными инструкциями процессора в этом самом DRM коде?
Да и вообще… маскировка аппаратной виртуализации? (А кстати, а её можно замаскировать? Ну например сделать так, чтобы все данные и код гипервизора, и вообще его присутствие, никак не отражалось в физической памяти (если гипервизор сам не хочет ничего менять)? В принципе, один мегабайт кэша из четырёх не очень заметно будет, если будет отсутствовать… ну то есть если гипервизор будет полностью находится в «кэше» процессора ...) А вот если гипервизор большой — то зашифровать физическую память — самое то для его маскировки.
infrapro
Это таким способом Intel борется с уязвимостью спекулятивного выполнения команд?
vibornoff
Так не поможет же, данные через кеш утекают. Это скорее защита от cold boot.
Duss
Почему не поможет? Через кеш утекут как раз шифрованные данные (если я правильно все понял, конечно) причем данные зашифрованы разными ключами и расшифровать их как «свои» зловред не смодет.
Gumanoid
В кэше и регистрах уже расшифрованные данные.
Psychosynthesis
Речь о кэше процессора.
ahdenchik
Это защита от Row hammer