Комментарии 36
Это таким способом Intel борется с уязвимостью спекулятивного выполнения команд?
НЛО прилетело и опубликовало эту надпись здесь
Шифрование памяти один из основных предусловий для Intel SGX — технологии, которая предназначена для безопасного от пользователя выполнения удалённого кода на компьютере пользователя.
Что в итоге мешает мне запустить такой код на эмуляторе процессора (например, qemu) и ничего не шифровать, или шифровать известным мне ключом? Что мешает пропатчить этот код и заменить инструкции, инициализирующие режим за-shit-ы памяти, на nop? Кажется, что от пользователя код защитить невозможно в принципе.
Кажется, что от пользователя код защитить невозможно в принципе.
На консолях и телефонах вот защитили. У xbox one вон до сих пор нет ниодного публичного взлома. Если код подписан, то ничего там не поменяешь. А если еще и шифрован, то и эмулятор не поможет.
Это верно. Но мы говорим о десктопных ОС и десктопном железе, где априори есть возможность запускать произвольный неподписанный код, в том числе загружать его в ядро (через модули ядра или патчи) или даже запускать до ядра, подсунув в загрузчик.
Пока есть. Статья как раз клонит, что движение идет именно к закрытию лазеек.
Запретят загружаться в линукс, только в одобренную, зашифрованную, подписанную и не модифицируемую винду?)
Нет, просто будет в процессоре зашит закрытый ключ асимметричного алгоритма шифрования, а всем роздан открытый ключ этой пары. И всё, никакая ОС этот код не рашифрует, а сможет только загрузить в память и выполнить.
всем роздан открытый ключ этой пары
Если действительно всем, то это атас. Потому что, как уже ниже написали, начнется нашествие вирусов, с которыми ничего не сможет сделать ни один антивирус.
Закрытый получат ещё разработчики антивирусов, сертифицированные (отвалившие миллион нефти) интел. Остальные производители антивирусов вымрут и уйдут с рынка. Через пару лет и закрытый ключ утечет с чьей-нибудь флешки и попадёт в даркнет.
Интел придумает ещё одну более новую инструкцию, чтобы бороться с вирусами, использующими эту инструкцию и утекший ключ. А пока все не внедрили эту новую инструкцию, вот вам новая партия процессоров, с другим ключём. Покупайте пожалуйста.
Весь этот страшный сон я уже где-то видел.
Интел придумает ещё одну более новую инструкцию, чтобы бороться с вирусами, использующими эту инструкцию и утекший ключ. А пока все не внедрили эту новую инструкцию, вот вам новая партия процессоров, с другим ключём. Покупайте пожалуйста.
Весь этот страшный сон я уже где-то видел.
Рассказ 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.
Потому что механизмы SGX как раз и предусматривают аппаратную защиту от таких действий: (я давно читал, поэтому могу слегка обманывать, лучше уточнить в оригинальной документации интел) код загружается в специальный домен, защищённый от всех, включая гипервизоры и аналогичные программы в соседних доменах, причём туда можно загрузить не любой код, а только от лицензированных партнёров (скорее всего подписанный зашитым в CPU ключом), этот код может получить слепок окружения и отправить на удалённую сторону.
Ни к коду, ни к стеку, ни к данным из других программ получить доступ нельзя (на самом деле есть дыры, но это детали конкретных реализаций, которые исследовали, в принципе, довольно суровая защита).
Соответственно удалённая сторона может определить, что у пользователя нужная ОС, что она не пропатчена, версии биоса, что загруженная программа совпадает с эталонной, что в памяти нет инжектированного кода и т. п.
Ни к коду, ни к стеку, ни к данным из других программ получить доступ нельзя (на самом деле есть дыры, но это детали конкретных реализаций, которые исследовали, в принципе, довольно суровая защита).
Соответственно удалённая сторона может определить, что у пользователя нужная ОС, что она не пропатчена, версии биоса, что загруженная программа совпадает с эталонной, что в памяти нет инжектированного кода и т. п.
Про "ОС, которую контролирует пользователь": может он её и контролирует, только вот она не может контролировать многие вещи на железном уровне. Те же ME, PSP, TrustZone, которые сами являются ОС и имеют доступ абсолютно ко всему в обход гостевой "пользовательской" ОС. Ну а шифрование памяти это как изюминка на торте всех этих ME и TtustZone. Хотя уже сейчас пользователь может хранить и проигрывать DRM-видео, при этом даже ядро не может получить доступ к памяти где хранятся разжатые и расшифрованные видео фреймы. Но при этом андроид может, к примеру, рисовать элементы управления поверх видео.
В андроиде это реализовано на уровне оконного сервера, при этом шифрование и декодирование отделены от, собственно, вывода. При выводе можно поставить окну флаг FLAG_SECURE. И есть особый пермишен, который разрешает приложению захватывать видео с экрана, включая защищённые окна, выдаётся только системным приложениям. Про TrustZone знаю, но предположу, что сама ОС всё равно имеет какой-то доступ к разжатым кадрам.
Стесняюсь спросить: а какая прямая сторона? Зачем на пользовательской машине шифрование данных в оперативной памяти, да и на сервере тоже. Кроме особо защищённых токенов или какого-нибудь хитрого DRM вообще не вижу применения, это же не бесплатные вычислительных мощности — да и энергопотребление с теплопакетом не следует забывать. Ну ещё военные и госзаказ, но это совсем другая история.
Когда читаю о защитах от атак на таком низком уровне мне становятся несколько вопросов интересны:
1. Сколько вообще взломов (ну хотя бы примерно, а?) было сделано с использованием дыр на таком низком уровне?
2. Кто-нибудь вообще думает о производительности? Читаем:
Даже DDR3 это десятки гигабайт в секунду. Даже допуская, что «движок» это некий ASIC (ну или что, например?), всё равно какую-то задержку это да принесёт.
1. Сколько вообще взломов (ну хотя бы примерно, а?) было сделано с использованием дыр на таком низком уровне?
2. Кто-нибудь вообще думает о производительности? Читаем:
«Шифрование по алгоритму AES-XTS-128 выполняет движок AES-XTS, который физически находится около шины памяти.»
Даже DDR3 это десятки гигабайт в секунду. Даже допуская, что «движок» это некий ASIC (ну или что, например?), всё равно какую-то задержку это да принесёт.
Даже 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, во-вторых, могут быть замаскированы конвейеризацией контроллером памяти и контроллером кэша. Но поправьте, если не прав, мне тоже интересно.
А стоит этот быстрый Плис сколько будет? теплоотвод нужен? Места на плате много займёт?
Уточню, не предлагаю использовать плис, стоить она будет дорого, да и незачем это делать. Однако привожу в пример то, что на плис (которые имеют сравнительно низкие тактовые частоты) уже давно делают быстрое шифрование. Следовательно, ASIC-реализация, врожденно допускающая более высокие тактовые частоты, может быть гораздо быстрее/экономнее/компактнее и т.д. Значит специализированное hardened-ядрышко шифрования (AES-XTS engine) внутри процессора проблем с производительностью вызвать не должно.
Так вот именно что это с таймингами сопоставимо.
То есть такая память в среднем будет в два раза медленнее по таймингам.
То есть такая память в среднем будет в два раза медленнее по таймингам.
К сожалению моих знаний недостаточно, чтобы про это компетентно спорить. C вами согласен, что для выборки одиночного слова задержка возрастет где-то вдвое. Однако в контексте системы в контроллере памяти наверняка организована конвейеризация (хотя бы для тех же блочных режимов доступа), кроме того, там есть планировщик, который переставляет команды обращения к памяти для минимизации конфликтов по банкам. В результате, когда мы имеем выборку не одного слова, а нескольких, то ожидание в очередях до и после обработки запросов к памяти как раз может замаскировать задержку, вносимую шифрованием, для остальной системы.
Совсем недавно был отличный доклад про безопасность xbox one www.youtube.com/watch?v=U7VwtOrwceo Там как раз используется аппаратное шифрование памяти и вообще кучи разных аппаратных защит. Насколько помню, xbox 360 тоже в каком-то виде это делал, чтобы предотвратить атаку по снифингу шины, которой взломали xbox. Тут как раз пример, когда это используется для DRM, защиты от пиратства, запуска неподписанного кода.
НЛО прилетело и опубликовало эту надпись здесь
DRM, да… Сплю и вижу, как у тех же издателей (или кто там с DRM работает) утекут сертификаты/ключи, и тут же появятся вирусы, защищённые так же, как этот самый DRM, и ни один антивирус не сможет не то что дамп кода снять… возможно даже вообще узнать, выполняется что то постороннее, или это просто видео с бОльшим битрейтом и кастомными настройками декодера. А как быть, например, с недокументированными инструкциями процессора в этом самом DRM коде?
Да и вообще… маскировка аппаратной виртуализации? (А кстати, а её можно замаскировать? Ну например сделать так, чтобы все данные и код гипервизора, и вообще его присутствие, никак не отражалось в физической памяти (если гипервизор сам не хочет ничего менять)? В принципе, один мегабайт кэша из четырёх не очень заметно будет, если будет отсутствовать… ну то есть если гипервизор будет полностью находится в «кэше» процессора ...) А вот если гипервизор большой — то зашифровать физическую память — самое то для его маскировки.
Да и вообще… маскировка аппаратной виртуализации? (А кстати, а её можно замаскировать? Ну например сделать так, чтобы все данные и код гипервизора, и вообще его присутствие, никак не отражалось в физической памяти (если гипервизор сам не хочет ничего менять)? В принципе, один мегабайт кэша из четырёх не очень заметно будет, если будет отсутствовать… ну то есть если гипервизор будет полностью находится в «кэше» процессора ...) А вот если гипервизор большой — то зашифровать физическую память — самое то для его маскировки.
любое вычислительное устройство как услуга — к этому всё идёт. Хотите исполнять свой код — делайте своё устройство, а на выданном Вам гаджете извольте исполнять только зашифрованный оговоренный в "ограниченной лицензии на исполнение кода" код в рамках потребляемой услуги. Эпоха универсальных вычислительных устройств под названием "персональный компьютер" постепенно, но неотвратимо уходит. Наступает эра максимально персонализированных абонентских устройств, включённых в единый административный домен с раздачей жестко определённых прав. Тут и IP v6 во всей красе раскроется и шифрование и медицинские достижения по имплантации подтянутся.
Сорри за многАбукв — я так вижу :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Аппаратное шифрование DRAM уже близко. Чем оно грозит простым пользователям?