Аппаратное шифрование 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.

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



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



    * — Мы решили не делать целый рекламный пост про скидки, а просто оставили тут небольшой баннер :)
    Дата-центр «Миран»
    Решения для аренды и размещения ИТ-инфраструктуры

    Комментарии 36

      +1
      Это таким способом Intel борется с уязвимостью спекулятивного выполнения команд?
        0
        Так не поможет же, данные через кеш утекают. Это скорее защита от cold boot.
          –1
          Почему не поможет? Через кеш утекут как раз шифрованные данные (если я правильно все понял, конечно) причем данные зашифрованы разными ключами и расшифровать их как «свои» зловред не смодет.
            +2
            В кэше и регистрах уже расшифрованные данные.
              0
              Речь о кэше процессора.
            +1
            Это защита от Row hammer
            +1

            Не представляю, как эту технологию можно использовать для DRM. По крайней мере в ОС, которую контролирует пользователь. Хотя можно представить её дальнейшее развитие, которые приведёт к DRM на уровне "сервер передал клиенту зашифрованный код, клиент его выполнил и получил результаты, причём ни код, ни промежуточные значения невозможно получить".

              +3
              Шифрование памяти один из основных предусловий для Intel SGX — технологии, которая предназначена для безопасного от пользователя выполнения удалённого кода на компьютере пользователя.
                0
                Что в итоге мешает мне запустить такой код на эмуляторе процессора (например, qemu) и ничего не шифровать, или шифровать известным мне ключом? Что мешает пропатчить этот код и заменить инструкции, инициализирующие режим за-shit-ы памяти, на nop? Кажется, что от пользователя код защитить невозможно в принципе.
                  +1
                  Кажется, что от пользователя код защитить невозможно в принципе.

                  На консолях и телефонах вот защитили. У xbox one вон до сих пор нет ниодного публичного взлома. Если код подписан, то ничего там не поменяешь. А если еще и шифрован, то и эмулятор не поможет.
                    0
                    Это верно. Но мы говорим о десктопных ОС и десктопном железе, где априори есть возможность запускать произвольный неподписанный код, в том числе загружать его в ядро (через модули ядра или патчи) или даже запускать до ядра, подсунув в загрузчик.
                      +2
                      Пока есть. Статья как раз клонит, что движение идет именно к закрытию лазеек.
                        0
                        Запретят загружаться в линукс, только в одобренную, зашифрованную, подписанную и не модифицируемую винду?)
                          +1
                          Нет, просто будет в процессоре зашит закрытый ключ асимметричного алгоритма шифрования, а всем роздан открытый ключ этой пары. И всё, никакая ОС этот код не рашифрует, а сможет только загрузить в память и выполнить.
                            0
                            всем роздан открытый ключ этой пары

                            Если действительно всем, то это атас. Потому что, как уже ниже написали, начнется нашествие вирусов, с которыми ничего не сможет сделать ни один антивирус.

                              0
                              Закрытый получат ещё разработчики антивирусов, сертифицированные (отвалившие миллион нефти) интел. Остальные производители антивирусов вымрут и уйдут с рынка. Через пару лет и закрытый ключ утечет с чьей-нибудь флешки и попадёт в даркнет.
                              Интел придумает ещё одну более новую инструкцию, чтобы бороться с вирусами, использующими эту инструкцию и утекший ключ. А пока все не внедрили эту новую инструкцию, вот вам новая партия процессоров, с другим ключём. Покупайте пожалуйста.
                              Весь этот страшный сон я уже где-то видел.
                      0

                      Рассказ Tony Chen (Microsoft) (development lead responsible for Xbox One security) о защитах в Xbox one — https://www.youtube.com/watch?v=U7VwtOrwceo "Guarding Against Physical Attacks: The Xbox One Story", Platform Security Summit, 2019-10-21


                      We will first describe the Xbox security design goals and why it needs to guard against hardware attacks, followed by descriptions of the hardware and software architecture to keep the Xbox secure. This includes details about the custom SoC we built with AMD and how we addressed the fact that all data read from flash, the hard drive, and even DRAM cannot be trusted. We will also discuss the corresponding software changes we made to keep the system and the games secure.
                      +2
                      Потому что механизмы SGX как раз и предусматривают аппаратную защиту от таких действий: (я давно читал, поэтому могу слегка обманывать, лучше уточнить в оригинальной документации интел) код загружается в специальный домен, защищённый от всех, включая гипервизоры и аналогичные программы в соседних доменах, причём туда можно загрузить не любой код, а только от лицензированных партнёров (скорее всего подписанный зашитым в CPU ключом), этот код может получить слепок окружения и отправить на удалённую сторону.
                      Ни к коду, ни к стеку, ни к данным из других программ получить доступ нельзя (на самом деле есть дыры, но это детали конкретных реализаций, которые исследовали, в принципе, довольно суровая защита).
                      Соответственно удалённая сторона может определить, что у пользователя нужная ОС, что она не пропатчена, версии биоса, что загруженная программа совпадает с эталонной, что в памяти нет инжектированного кода и т. п.
                    0

                    Про "ОС, которую контролирует пользователь": может он её и контролирует, только вот она не может контролировать многие вещи на железном уровне. Те же ME, PSP, TrustZone, которые сами являются ОС и имеют доступ абсолютно ко всему в обход гостевой "пользовательской" ОС. Ну а шифрование памяти это как изюминка на торте всех этих ME и TtustZone. Хотя уже сейчас пользователь может хранить и проигрывать DRM-видео, при этом даже ядро не может получить доступ к памяти где хранятся разжатые и расшифрованные видео фреймы. Но при этом андроид может, к примеру, рисовать элементы управления поверх видео.

                      0
                      В андроиде это реализовано на уровне оконного сервера, при этом шифрование и декодирование отделены от, собственно, вывода. При выводе можно поставить окну флаг FLAG_SECURE. И есть особый пермишен, который разрешает приложению захватывать видео с экрана, включая защищённые окна, выдаётся только системным приложениям. Про TrustZone знаю, но предположу, что сама ОС всё равно имеет какой-то доступ к разжатым кадрам.
                        0
                        Вероятно зависит только от реализации TrustZone. Насколько слышал в Motorola было именно так.
                    +1

                    Стесняюсь спросить: а какая прямая сторона? Зачем на пользовательской машине шифрование данных в оперативной памяти, да и на сервере тоже. Кроме особо защищённых токенов или какого-нибудь хитрого DRM вообще не вижу применения, это же не бесплатные вычислительных мощности — да и энергопотребление с теплопакетом не следует забывать. Ну ещё военные и госзаказ, но это совсем другая история.

                      +1
                      Например, позволит хостить всякую запрещёнку без боязни, что маски-шоу сделают дамп и используют его в качестве доказательства в суде.
                        +1

                        Для басманного суда такие сложные доказательства не нужны, достаточно будет "нотариально заверенного скриншота" и банковской транзакции за хостинг

                        0
                        .
                        0
                        Когда читаю о защитах от атак на таком низком уровне мне становятся несколько вопросов интересны:
                        1. Сколько вообще взломов (ну хотя бы примерно, а?) было сделано с использованием дыр на таком низком уровне?
                        2. Кто-нибудь вообще думает о производительности? Читаем:
                        «Шифрование по алгоритму AES-XTS-128 выполняет движок AES-XTS, который физически находится около шины памяти.»

                        Даже DDR3 это десятки гигабайт в секунду. Даже допуская, что «движок» это некий ASIC (ну или что, например?), всё равно какую-то задержку это да принесёт.
                          0
                          Даже 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, во-вторых, могут быть замаскированы конвейеризацией контроллером памяти и контроллером кэша. Но поправьте, если не прав, мне тоже интересно.
                            0
                            А стоит этот быстрый Плис сколько будет? теплоотвод нужен? Места на плате много займёт?
                              +1
                              Уточню, не предлагаю использовать плис, стоить она будет дорого, да и незачем это делать. Однако привожу в пример то, что на плис (которые имеют сравнительно низкие тактовые частоты) уже давно делают быстрое шифрование. Следовательно, ASIC-реализация, врожденно допускающая более высокие тактовые частоты, может быть гораздо быстрее/экономнее/компактнее и т.д. Значит специализированное hardened-ядрышко шифрования (AES-XTS engine) внутри процессора проблем с производительностью вызвать не должно.
                              0
                              Так вот именно что это с таймингами сопоставимо.

                              То есть такая память в среднем будет в два раза медленнее по таймингам.
                                0
                                К сожалению моих знаний недостаточно, чтобы про это компетентно спорить. C вами согласен, что для выборки одиночного слова задержка возрастет где-то вдвое. Однако в контексте системы в контроллере памяти наверняка организована конвейеризация (хотя бы для тех же блочных режимов доступа), кроме того, там есть планировщик, который переставляет команды обращения к памяти для минимизации конфликтов по банкам. В результате, когда мы имеем выборку не одного слова, а нескольких, то ожидание в очередях до и после обработки запросов к памяти как раз может замаскировать задержку, вносимую шифрованием, для остальной системы.
                            +1
                            Совсем недавно был отличный доклад про безопасность xbox one www.youtube.com/watch?v=U7VwtOrwceo Там как раз используется аппаратное шифрование памяти и вообще кучи разных аппаратных защит. Насколько помню, xbox 360 тоже в каком-то виде это делал, чтобы предотвратить атаку по снифингу шины, которой взломали xbox. Тут как раз пример, когда это используется для DRM, защиты от пиратства, запуска неподписанного кода.
                              –1
                              Дополнительное шифрование ведет к дополнительным энергозатратам, дополнительные энергозатраты ведут к дополнительным финансовым затратам.
                                0
                                DRM, да… Сплю и вижу, как у тех же издателей (или кто там с DRM работает) утекут сертификаты/ключи, и тут же появятся вирусы, защищённые так же, как этот самый DRM, и ни один антивирус не сможет не то что дамп кода снять… возможно даже вообще узнать, выполняется что то постороннее, или это просто видео с бОльшим битрейтом и кастомными настройками декодера. А как быть, например, с недокументированными инструкциями процессора в этом самом DRM коде?

                                Да и вообще… маскировка аппаратной виртуализации? (А кстати, а её можно замаскировать? Ну например сделать так, чтобы все данные и код гипервизора, и вообще его присутствие, никак не отражалось в физической памяти (если гипервизор сам не хочет ничего менять)? В принципе, один мегабайт кэша из четырёх не очень заметно будет, если будет отсутствовать… ну то есть если гипервизор будет полностью находится в «кэше» процессора ...) А вот если гипервизор большой — то зашифровать физическую память — самое то для его маскировки.
                                  0

                                  любое вычислительное устройство как услуга — к этому всё идёт. Хотите исполнять свой код — делайте своё устройство, а на выданном Вам гаджете извольте исполнять только зашифрованный оговоренный в "ограниченной лицензии на исполнение кода" код в рамках потребляемой услуги. Эпоха универсальных вычислительных устройств под названием "персональный компьютер" постепенно, но неотвратимо уходит. Наступает эра максимально персонализированных абонентских устройств, включённых в единый административный домен с раздачей жестко определённых прав. Тут и IP v6 во всей красе раскроется и шифрование и медицинские достижения по имплантации подтянутся.
                                  Сорри за многАбукв — я так вижу :)

                                    +1
                                    Мне почему-то кажется, что программирование вообще станет лицензированным занятием и код можно будет запустить, только подписав корректным сертификатом программиста/организации.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое