Comments 60
Что за глупости.
Ядро ОС (и те кому оно дало доступы к настройке железа) может прочитать память? Всё в порядке.
Не в порядке сама идея прятать пользовательский процесс в памяти от ядра, затея заведомо провальная, даже без этих "уязвимостей". Потому как всю эту чушь можно просто виртуализировать (вплоть до эмуляции нужных узлов проца, отвечающих за эту "защиту") и запустить исследуемое приложение в такой песочнице. Очередное security through obscurity.
Сэмулируйте выполнение этого приложения и подпись нужных контейнеров ключами, зашитыми в процессор?
Достаточно один раз отреверсить проц чтобы вытащить из него этот самый ключ и дальше использовать везде. Да, это совсем не дёшево, но суть не меняется — security through obsurity. Ключ просто спрятан в чипе с надеждой что его там никто не сможет подсмотреть.
Причем какой-то реверсинг уже делали, если верить этой статье, значит были близко к правильной нейтрализации этой фигни.
PS. Да, они умеют обновляться)))
Я и не собирался. Но теоретическая возможность имеется. Повторюсь, безопасность, построенная на "они не смогут разобраться в устройстве" называется security through obsurity и это общепризнанно плохой подход.
Какой ещё сертификат? Речь идёт о приватном ключе шифрования. Обновление прошивки, скачиваемое с сайта, тут не поможет — из него точно так же (даже ещё намного проще) вытащат этот приватный ключ (если надо — сэмулируют проц, качающий себе обновление, хотя по-моему до этого ещё не дошли и скачивается оно средствами ОС).
Или они всем покупателям предложат бесплатно заменить чипы на новые? А всем поставщикам зашифрованного софта придётся его перешифровывать и изымать с жёстких дисков клиентов старые версии?
Я вообще не пойму кому пришла в голову идиотская идея что можно доверять железу, полностью находящемуся в руках предполагаемого злоумышленника. Точнее, для производителя то резон понятен: "впарим ка ещё и это, заодно цену повысим". А вот те, кто этому верит — странные.
Это как раз пример хорошей уязвимости.
Единственное назначение таких "анклавов" — это запуск кода, неконтролируемого администратором системы. Например, код DRM для генерации ключей, проверка подлинности игр, "закладки", итд. Соответственно, эта уязвимость лишь возвращает администратору машины потерянную власть и позволяет "заглянуть" внутрь анклава. Что тут плохого?
Воспользоваться уявзимостью можно только из режима ядра, с высокими привилегиями. Таким образом, риск она создает только для правоторговцев, что их алгоритмы защиты вытащат на белый свет.
Мне кажется, с этой фичей надо бороться. На процессоре не должно быть неподконтрольного администратору кода, как бы правообладатели и правительства этого не хотели.
На процессоре не должно быть неподконтрольного администратору кода, как бы правообладатели и правительства этого не хотели.
Т.е. клиенты облачного провайдера не должны иметь права на приватность в своих виртуалках?
Это же, кстати, применимо и d банальных собственных ДЦ — чтобы слишком любопытные не совали нос куда не следует, даже если получили где-то админские права.
PCI DSS — это в первую очередь про процессы и регламенты, а уж только потом про архитектуру и инфраструктуру.
Так же, массовые серверные интелловские процы архитектуры x86/x86_64 никогда не будут использованы в HSM, которые поставляются для организаций попадающих под требования PCI DSS Level 1 и 2, потому что такие HSM не пройдут аудит.
Если вы хотите приватности, дешевле поставить дома старый компьютер и купить белый IP.
Приватность, знаете-ли, не ограничивается бытовыми потребностями, и не всегда речь о своей собственной, к тому же.
SGX не защищает всю память или диск вашей виртуалки, а только анклав (в котором алгоритм с каким-то ключом и данными). Хостер по-прежнему может ковыряться в памяти и на диске. Зачем вам такая псевдозащита?
Для того, чтобы убедиться, что вы работаете с реальным анклавом, а не с эмулятором, процессор умеет делать подпись, которую можно проверить через Intel — но это стоит денег.
Так что давайте подумаем еще раз, для каких целей он придуман?
Я, впрочем, читал, что его можно как-то использовать для удаленной верификации машины, что например в ней не подменили ядро ОС или что-то такое.
Хостер по-прежнему может ковыряться в памяти и на диске.
Только если диск не защищен ключом который как раз можно спрятать в анклаве, как и прочие ненужные любопытным вещи, благо туда влезет как минимум 90M (и это явно временное ограничение).
Самое очевидное применение — это загрузка системы с полным шифрованием, без SGX (или SME/SEV от AMD) трудно гарантировать что ключи не будут перехвачены.
Впрочем, если уж хостер настроен на целевую атаку, то бороться с ним будет сложно, но с другой стороны, тот у кого действительно остро стоит вопрос с доверием вряд ли будет хостится в облаке, и уж тем более у провайдера который потенциально может оказаться слишком любопытным.
На самом деле высказывания против таких технологий (в духе «админ должен иметь возможность...») чем-то напоминают телодвижения некоторых властей, которые против шифрования и приватности, не находите?
Только если диск не защищен ключом который как раз можно спрятать в анклаве,
А как ключ попадет в анклав при загрузке? Анклав это же RAM. Также, анклав не защищает всю память, где хранятся данные в открытом виде.
Это явно сделано для DRM. Если у вас настолько важные и секретные данные, то вы можете позволить себе свой сервер.
На самом деле высказывания против таких технологий (в духе «админ должен иметь возможность...») чем-то напоминают телодвижения некоторых властей, которые против шифрования и приватности, не находите?
Нет. Надо быть айтишником, чтобы на полном серьезе сравнивать компьютер и государство. А то вас начнет совесть мучать при "убийстве" зависшего процесса. Мой компьютер это вещь, в котором находятся бездушные байты, а в государстве живые люди с правами.
И, если уж на то пошло, SGX скорее удобен государству — внедрить вам "анклав" и следить за вами оттуда.
А как ключ попадет в анклав при загрузке?
Я не сильно углублялся в детали, но принцип такой же как и в случае TPM — есть код (без секретов) который аттестируется и привязывается к CPU (каждый имеет свой уникальный ключ), а имея код которому можно доверять уже можно и приватными ключами заняться, например, путём передачи этому коду другого кода или секретного/приватного ключа посредством публичного ключа в изначальном коде.
Это явно сделано для DRM.
DRM — это всего лишь частный случай применения. Эдак можно сказать что некоторые кухонные ножи явно сделаны для убийств, с учётом их размеров и остроты.
Мой компьютер это вещь, в котором находятся бездушные байты, а в государстве живые люди с правами.
Наверное, именно так рассуждают в Facebook & co, приторговывая данными пользователей — это ведь всего лишь бездушные байты.
Как-то страшновато доверять свою информацию и даже процессы хостеру если он считает что всё что хранится и выполняется в его компе — всего лишь «бездушные байты». В конце концов, тот процесс который он может захотеть убить может быть для меня (или моего бизнеса) жизненно важным, не говоря уже о моих данных в которые он лезть не должен, а я ведь вполне живой человек с правами.
Но правды нет — и выше…
SGX также позволял скрыть ключи от соседнего админа на машине, который, к слову, мог получить право неправомерное, т.е. через другую уязвимость.
SGX предназначен в первую очередь не для настольных ПК, а в тех местах, где данные могут быть скомпроментированы.
Я не сотрудник Интел, но использовал SGX в своей практике много раз. Считаю — отличное решение для многих бизнес задач.
А можно конкретные примеры этих "многих бизнес задач"?
А насчёт "не для настольных ПК" — так что тогда эта фича делает в настольных линейках процессоров? Как по мне, версия с DRM звучит довольно логично.
Потоковая дешифрация и обработка траффика
Кассовые аппараты с генерацией заказа прямо на кассе без необходимости связываться с сервером.
Печать защищённых изображений с расшифровкой прямо на принтере и т.д.
Что касается настольного ПК — от привязываться к компьютеру по ключу проца? Не очень удобно, но тоже годный кейс.
Я не до конца понимаю эти кейсы. Речь ведь о том, что владельцу устройства нельзя доверять, верно?
Потоковая дешифрация и обработка траффика
Как конкретно получилось так, что устройство, занимающееся не просто потоковой передачей, а именно обработкой трафика, находится во владении человека, который не должен иметь доступ к результатам обработки?
Кассовые аппараты с генерацией заказа прямо на кассе без необходимости связываться с сервером.
Если этот кассовый аппарат принимает оплату картой, то ему всё-равно связь с сервером нужна. Если же в него человек купюры засовывает, а кассовый аппарат печает некий 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 защитите каналы между принтерами и пользовательскими машинами, с которых печатают что угодно в корпоративной сети?
нужно нормальное шифрование — вставляйте SMART карты.
Я у себя эту дрять SGX вырубил как в BIOS заметил.
Но имейте ввиду. в новых BIOS на ноутах HP потихоньку закручивают гайки!!! там нельзя уже много чего отключить.
На первый взгляд понижение напряжения должно дать случайный сбой, а здесь сбой четко предсказуемый. Была проделана огромная работа, чтобы это выявить. Для разработчиков дополнительный стимул для устранения этой ошибки.
у процессоров появился свой аналог «терморектального криптоанализа»
радикального повышения напряжения
Так все же снижения?
А вот если при этом после снижения напряжения и нагрузку скинуть — мгновенно зависнет, да. Похоже, на низких частотах «запас прочности» по питанию существенно меньше, и с андервольтингом на -225mV «на минималках» проц уже не тянет.
Процессоры Intel выплёвывают приватный ключ, если поиграть с напряжением