Pull to refresh

Comments 60

Что за глупости.
Ядро ОС (и те кому оно дало доступы к настройке железа) может прочитать память? Всё в порядке.
Не в порядке сама идея прятать пользовательский процесс в памяти от ядра, затея заведомо провальная, даже без этих "уязвимостей". Потому как всю эту чушь можно просто виртуализировать (вплоть до эмуляции нужных узлов проца, отвечающих за эту "защиту") и запустить исследуемое приложение в такой песочнице. Очередное security through obscurity.

Хорошо, вот я производитель процессоров и у меня есть приватный мастер ключ, который шифрует с помощью сессионного приложения во время компиляции.

Сэмулируйте выполнение этого приложения и подпись нужных контейнеров ключами, зашитыми в процессор?

Достаточно один раз отреверсить проц чтобы вытащить из него этот самый ключ и дальше использовать везде. Да, это совсем не дёшево, но суть не меняется — security through obsurity. Ключ просто спрятан в чипе с надеждой что его там никто не сможет подсмотреть.
Причем какой-то реверсинг уже делали, если верить этой статье, значит были близко к правильной нейтрализации этой фигни.

Отреверсить чип на 14нм и несколько миллиардов транзисторов — удачи вам, наберете когда получится.
У него не получится, Интел просто выпустит новый дочерний сертификат и обновит процы.
PS. Да, они умеют обновляться)))

Я и не собирался. Но теоретическая возможность имеется. Повторюсь, безопасность, построенная на "они не смогут разобраться в устройстве" называется security through obsurity и это общепризнанно плохой подход.


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


Или они всем покупателям предложат бесплатно заменить чипы на новые? А всем поставщикам зашифрованного софта придётся его перешифровывать и изымать с жёстких дисков клиентов старые версии?


Я вообще не пойму кому пришла в голову идиотская идея что можно доверять железу, полностью находящемуся в руках предполагаемого злоумышленника. Точнее, для производителя то резон понятен: "впарим ка ещё и это, заодно цену повысим". А вот те, кто этому верит — странные.

Это как раз пример хорошей уязвимости.


Единственное назначение таких "анклавов" — это запуск кода, неконтролируемого администратором системы. Например, код DRM для генерации ключей, проверка подлинности игр, "закладки", итд. Соответственно, эта уязвимость лишь возвращает администратору машины потерянную власть и позволяет "заглянуть" внутрь анклава. Что тут плохого?


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


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

На процессоре не должно быть неподконтрольного администратору кода, как бы правообладатели и правительства этого не хотели.

Т.е. клиенты облачного провайдера не должны иметь права на приватность в своих виртуалках?
Виртуалку можно легко эмулировать полностью, так что всё, что вы отдали в облако считается опубликованным на заборе в интернете, если только в вашем договоре с облаком явно не указаны классы защиты информации типа PSI DSS и конские штрафы за любые утечки по вине облака (ну и с конским ценником за услуги разумеется).
При наличии умысла со стороны провайдера — ясный пень, возможно обойти почти всё, но речь идёт хотя бы о том чтобы защитить виртуалки от чрезмерно любопытных или неадекватных админов (или кул-хацкеров) в нормальных ДЦ. Думаю, один админ из десятков не сможет такое замутить незаметно от остальных, да и полностью эмулированная виртуалка проявит себя как минимум в очень низкой производительности.

Это же, кстати, применимо и d банальных собственных ДЦ — чтобы слишком любопытные не совали нос куда не следует, даже если получили где-то админские права.
Ой, как обычно меня минусуют за недовольство тем, что многий промышленный софт хранит ключи в незашифрованном виде на диске… Мол все равно доступ к диску только у админов…
Это до тех пор, пока в этом самом промышленном софте не появляется уязвимость, для которой от публичного багрепорта до фикса проходит полгода.
Теоретически, если мой код или данные зашифрованы публичным ключем, подписанным Intel, приватный ключ которого доступен только из защищенного анклава целевого процессора, стоящего в стойке облачного провайдера, то как бы провайдер не эмулировал мою виртуалку, он не получит доступ к моим данным и коду. Теоретически.
PCI DSS накладывает ограничение на весь АПК, а не только одну его часть, даже если она сразу по мановению волшебной палочки делает всю систему «защищенной».

PCI DSS — это в первую очередь про процессы и регламенты, а уж только потом про архитектуру и инфраструктуру.

Так же, массовые серверные интелловские процы архитектуры x86/x86_64 никогда не будут использованы в HSM, которые поставляются для организаций попадающих под требования PCI DSS Level 1 и 2, потому что такие HSM не пройдут аудит.
Не могли бы вы пояснить мне и 99% остальных читателей, почему облачный провайдер не сможет внезапно эмулировать вашу виртуалку? Некий особо-секретный-ключ зашит прямо в процессор (чипсет)? Если он уникален, то как быть с оркестрацией? Если не уникален, то что мешает эмулировать или считать-кому-надо?

Если вы хотите приватности, дешевле поставить дома старый компьютер и купить белый IP.

Конечно. Только два компьютера, для резерва. А ещё купить пару независимых каналов минимум по гигабиту каждый (сервер же), мощную железную дверь и толстые стены из армированного бетона, решетки на окна (хотя лучше их вообще замуровать), сигнализацию и видеонаблюдение поставить, нанять круглосуточную охрану, и не забыть хороший дизельный генератор с батареей в качестве UPS — очень дешево, и правда, да и соседям нескучно будет.

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

SGX не защищает всю память или диск вашей виртуалки, а только анклав (в котором алгоритм с каким-то ключом и данными). Хостер по-прежнему может ковыряться в памяти и на диске. Зачем вам такая псевдозащита?


Для того, чтобы убедиться, что вы работаете с реальным анклавом, а не с эмулятором, процессор умеет делать подпись, которую можно проверить через Intel — но это стоит денег.


Так что давайте подумаем еще раз, для каких целей он придуман?


Я, впрочем, читал, что его можно как-то использовать для удаленной верификации машины, что например в ней не подменили ядро ОС или что-то такое.

Хостер по-прежнему может ковыряться в памяти и на диске.

Только если диск не защищен ключом который как раз можно спрятать в анклаве, как и прочие ненужные любопытным вещи, благо туда влезет как минимум 90M (и это явно временное ограничение).

Самое очевидное применение — это загрузка системы с полным шифрованием, без SGX (или SME/SEV от AMD) трудно гарантировать что ключи не будут перехвачены.

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

На самом деле высказывания против таких технологий (в духе «админ должен иметь возможность...») чем-то напоминают телодвижения некоторых властей, которые против шифрования и приватности, не находите?
Только если диск не защищен ключом который как раз можно спрятать в анклаве,

А как ключ попадет в анклав при загрузке? Анклав это же RAM. Также, анклав не защищает всю память, где хранятся данные в открытом виде.


Это явно сделано для DRM. Если у вас настолько важные и секретные данные, то вы можете позволить себе свой сервер.


На самом деле высказывания против таких технологий (в духе «админ должен иметь возможность...») чем-то напоминают телодвижения некоторых властей, которые против шифрования и приватности, не находите?

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


И, если уж на то пошло, SGX скорее удобен государству — внедрить вам "анклав" и следить за вами оттуда.

А как ключ попадет в анклав при загрузке?

Я не сильно углублялся в детали, но принцип такой же как и в случае TPM — есть код (без секретов) который аттестируется и привязывается к CPU (каждый имеет свой уникальный ключ), а имея код которому можно доверять уже можно и приватными ключами заняться, например, путём передачи этому коду другого кода или секретного/приватного ключа посредством публичного ключа в изначальном коде.

Это явно сделано для DRM.

DRM — это всего лишь частный случай применения. Эдак можно сказать что некоторые кухонные ножи явно сделаны для убийств, с учётом их размеров и остроты.

Мой компьютер это вещь, в котором находятся бездушные байты, а в государстве живые люди с правами.

Наверное, именно так рассуждают в Facebook & co, приторговывая данными пользователей — это ведь всего лишь бездушные байты.

Как-то страшновато доверять свою информацию и даже процессы хостеру если он считает что всё что хранится и выполняется в его компе — всего лишь «бездушные байты». В конце концов, тот процесс который он может захотеть убить может быть для меня (или моего бизнеса) жизненно важным, не говоря уже о моих данных в которые он лезть не должен, а я ведь вполне живой человек с правами.
UFO just landed and posted this here
… нет правды на земле.
Но правды нет — и выше…
SGX & co. позволяют эту приватность обеспечить, хотя бы в принципе. И да, пока ещё есть в мире страны и провайдеры, где «заплатки» в ДЦ ну очень маловероятны.
Ну еще есть разные математические технологии типа доказательств с нулевым разглашением. Но они имеею много ограничений и ньюансов.
По такой логике этот набор инструкций должен существовать только в серверных процессорах. Но те же i3 в сервера никто не ставит, насколько мне известно.
UFO just landed and posted this here

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

Дык, может поэтому и подняли бучу, чтобы люди повыкидывали невыгодные процессоры и побежали заносить в кассу за новые защищённые от пользователя?

ну, это если бы не было конкурента

А разве есть уверенность, что у конкурента безопаснее? Если ещё не нашли это не означает что нету. Хоть бери и сам делай свой процессор, но при этом нет уверенности даже в FPGA, т.к. они тоже у заинтересованных лиц производятся.
UFO just landed and posted this here
Извините за смежный пример, но вот та же атомная электростанция. Вы считаете, что оператор пульта должен иметь возможность ремонтировать ядро?

SGX предназначен в первую очередь не для настольных ПК, а в тех местах, где данные могут быть скомпроментированы.

Я не сотрудник Интел, но использовал SGX в своей практике много раз. Считаю — отличное решение для многих бизнес задач.

А можно конкретные примеры этих "многих бизнес задач"?


А насчёт "не для настольных ПК" — так что тогда эта фича делает в настольных линейках процессоров? Как по мне, версия с DRM звучит довольно логично.

UFO just landed and posted this here

И что с того? Оно ведь на практике есть, часть фич есть только в серверных процах. Так что вопрос почему данная фича есть не только в серверных вполне уместен.

UFO just landed and posted this here

Потоковая дешифрация и обработка траффика


Кассовые аппараты с генерацией заказа прямо на кассе без необходимости связываться с сервером.


Печать защищённых изображений с расшифровкой прямо на принтере и т.д.


Что касается настольного ПК — от привязываться к компьютеру по ключу проца? Не очень удобно, но тоже годный кейс.

Я не до конца понимаю эти кейсы. Речь ведь о том, что владельцу устройства нельзя доверять, верно?


Потоковая дешифрация и обработка траффика

Как конкретно получилось так, что устройство, занимающееся не просто потоковой передачей, а именно обработкой трафика, находится во владении человека, который не должен иметь доступ к результатам обработки?


Кассовые аппараты с генерацией заказа прямо на кассе без необходимости связываться с сервером.

Если этот кассовый аппарат принимает оплату картой, то ему всё-равно связь с сервером нужна. Если же в него человек купюры засовывает, а кассовый аппарат печает некий QR-код дающий возможность получить заказ, то у человека расхаживающего с таким кассовым аппаратом море возможностей его надурить даже если он не может выковырять из него ключ подписывающий заказы (сразу вспоминаются советские уличные телефоны, в которые монетку на верёвочке опускали :)).


Печать защищённых изображений с расшифровкой прямо на принтере и т.д.

Учитывая, что распечатанное изображение владелец принтера может без проблем отсканировать, мы снова упираемся в DRM — владелец изображения хочет контролировать кто, когда, с каким качеством и водяными знаками может его печатать.


привязываться к компьютеру по ключу проца

Есть способы и по-проще. Но история показала, что эти привязки опять же нарушают законы (напр. права пользователей на резервные копии) и создают проблем намного больше, чем решают. Плюс и без этого полно вариантов к чему привязываться в компе, если очень надо.

Ох, давайте кратко отвечу по пунктам, а то разрастается диалог)))) Хочу сразу сказать, что эти кейсы взяты из реальных заказов.

Как конкретно получилось так, что устройство, занимающееся не просто потоковой передачей, а именно обработкой трафика, находится во владении человека, который не должен иметь доступ к результатам обработки?

Сервер шифрования трафика для клиента с помощью ключа клиента. Чтобы не хранить N копий, хранится одна. Сервер, понятно дело, может быть чей угодно, просто как сервис.

Если этот кассовый аппарат принимает оплату картой, то ему всё-равно связь с сервером нужна.
Можно и без оплаты печатать промо коды. Новогодние, например. Но они будут все подписаны кассой и в дальнейшем отосланы на сервер.

Учитывая, что распечатанное изображение владелец принтера может без проблем отсканировать
Извините, там кейс по сканированию был, я неверно описал. Вы сканируете документ и он сразу уходит защищенным с железа.

Если же развить печать, то кейс с печатью документов защищает от перехвата документов посредине. Например, принтер стоит в Белом Доме и данные передаются по сети.

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

PS. По поводу SGX, подумайте о шикарной связке SGX+PKCS#7 — вот они отлично входят в эти кейсы.

Простите, но я всё ещё не понимаю. Не поймите неправильно, я не издеваюсь, а честно не вижу где в этих кейсах от данной защиты есть хоть какой-то толк, и хочу в этом разобраться.


Сервер шифрования трафика для клиента с помощью ключа клиента.

Если он шифрует трафик, значит трафик на него приходит с одной стороны не шифрованный. И чего ради тогда прятать ключ шифрования от админа этого сервера?


Можно и без оплаты печатать промо коды.

И зачем в этом случае прятать ключ от имеющего физический доступ к кассовому аппарату, если он и так может напечатать просто нажимая кнопку на аппарате сколько хочет этих кодов?


Вы сканируете документ и он сразу уходит защищенным с железа.

Вот именно. Я сканирую. Т.е. у меня в руках одновременно и сканер и оригинал документа. Смысл от меня же скрывать ключ шифрования?


Если же развить печать, то кейс с печатью документов защищает от перехвата документов посредине.

От MITM отлично помогает обычный https.

Если он шифрует трафик, значит трафик на него приходит с одной стороны не шифрованный. И чего ради тогда прятать ключ шифрования от админа этого сервера?
Нет, хранится одна шифрованная копия и поточно перешивровывается для пользователя.

И зачем в этом случае прятать ключ от имеющего физический доступ к кассовому аппарату, если он и так может напечатать просто нажимая кнопку на аппарате сколько хочет этих кодов?
Коды могут быть хэшем PKCS#7, которое содержит дополнительную инфу, такую как время, место, идентификационные данные и т.д. Все это можно легко в шифрованном виде хранить и передавать далее.
Отличие от нешифрованного вида в том, что данные защищены по всей цепочке.

Вот именно. Я сканирую. Т.е. у меня в руках одновременно и сканер и оригинал документа. Смысл от меня же скрывать ключ шифрования?
Даю вам подсказку: публичный сканнер, которым пользуется множество людей и который защищает ваши электронные документы, даже если к ним получили доступ злоумышлинники (взяли и похитили сканер с эшем данных).

От MITM отлично помогает обычный https.

Если на вашем компе вредоносное ПО заменит корневые сертификаты, это не поможет. А «ваш комп», например, комп бухгалтерии. SGX более надежный в этом плане.
Нет, хранится одна шифрованная копия и поточно перешивровывается для пользователя.

Что такое "перешифровывается"? Если с неё шифрование сначала снимается, то админ этого сервера в любом случае может получить доступ к данным в середине этого процесса. Или SGX содержит оба ключа, и у него шифротекст как на входе, так и на выходе, т.е. OS доступа к открытому тексту вообще не имеет ни на каком этапе?


Впрочем, даже в последнем случае, разве OS не может добавить в SGX новый ключ, и запросить перешифрование этим ключом (а дальше зная этот ключ расшифровать не проблема)? Или для внесения любых изменений такого рода в SGX нужно эти изменения подписывать ключом производителя SGX?


Отличие от нешифрованного вида в том, что данные защищены по всей цепочке.

Для защиты по всей цепочке достаточно данные подписать, шифровать их при этом не обязательно.


Ну и всё ещё неясно, каким именно действиям человека, желающего злоупотребить имеющимся у него в руках кассовым аппаратом, помешает наличие в нём SGX. Если он имеет возможность его использовать как угодно, плюс может даже разобрать и подключиться к нему с правами админа, то что в этих условиях он не сможет сделать полезного для себя из-за SGX? (Ключ из SGX он не достанет, но зачем он ему, если он и так может шифровать/подписывать этим ключом всё, что хочет?)


похитили сканер с эшем данных

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


Если на вашем компе вредоносное ПО заменит корневые сертификаты, это не поможет.

От этого придумали certificate pinning.

админ этого сервера в любом случае может получить доступ к данным в середине этого процесса
Не может. В этом суть SGX анклава.
он и так может шифровать/подписывать этим ключом всё, что хочет?
Только то, что позволит программа, выполняющаяся в анклаве.
От этого придумали certificate pinning.
Теперь расскажите как вы с помощью SSL и certificate pinning защитите каналы между принтерами и пользовательскими машинами, с которых печатают что угодно в корпоративной сети?
Все правильно. Это очередное DRM го… но которое пытаются воткнуть в систему.
нужно нормальное шифрование — вставляйте SMART карты.
Я у себя эту дрять SGX вырубил как в BIOS заметил.
Но имейте ввиду. в новых BIOS на ноутах HP потихоньку закручивают гайки!!! там нельзя уже много чего отключить.
Например, в процессоре Core i3-7100U при понижении напряжения на 118 мВ операция 0x80D36 * 0x21 = 0x109b3f6 даёт предсказуемо сбойное значение 0xffffffffe109b417 на частоте 2 ГГц.
На первый взгляд понижение напряжения должно дать случайный сбой, а здесь сбой четко предсказуемый. Была проделана огромная работа, чтобы это выявить. Для разработчиков дополнительный стимул для устранения этой ошибки.
Была проделана огромная работа, чтобы это выявить
Куда интереснее какая работа была чтобы это создать

у процессоров появился свой аналог «терморектального криптоанализа»

Процессоры всё умнее, и дырок в них всё больше.
А ведь при такой просадке проц должен уходить в reset
Как показывает практика — под полной нагрузкой можно и до -225mV скинуть, и машина продолжит работать как ни в чём ни бывало, без ошибок (mprime мне свидетель)).
А вот если при этом после снижения напряжения и нагрузку скинуть — мгновенно зависнет, да. Похоже, на низких частотах «запас прочности» по питанию существенно меньше, и с андервольтингом на -225mV «на минималках» проц уже не тянет.
В микроконтроллерах это как-то решается аппаратным brownout detector
BOD работает если есть запас в % на дроп. Т.е., 200mV на 3.3 или 5 вольтах это совсем не то же самое, что на 1.8в или даже 0.7в. А ядра процессоров нынче менее вольта напряжение хотят.
Если со мной поиграть напряжением, то я тоже все ключи выдам!
UFO just landed and posted this here
Паяльник с температурой 100 градусов и тепловой мощностью 95 Вт?
Всегда удивляло. Как такое находят без схемы нутрянки процессора.
Sign up to leave a comment.