Comments 14
Весь современный ландшафт информационной безопасности усеян дырами и кривыми заплатками в рандомных местах. И никакого выхода из этой глобальной проблемы не просматривается.
Мне одному кажется, что в балансе безопасно vs быстро индустрия сворачивает куда-то не туда?
Давайте шагать дальше, господа! Скажем, есть вектора атаки на чтение памяти по энергопотреблению БП, да, для успешной атаки необходимо 10 000 часов и прямой доступ к железу, но мы же параноики, так что теперь в комплекте с каждой планкой памяти давайте делать неотключаемый встроенный утюг. Есть атака по тональности свиста дросселей? Не вопрос! Добавим в каждый чипсет постояннодействующую сирену на 130 децибел. Можно залезть на шкаф и, пригнувшись, через бинокль в женской бане напротив рассмотреть пароль на экране администратора? Правильно! Сжечь все мониторы, только звуковой ввод/вывод через имплантируемые гарнитуры в массы и на все устройства!
Правильным, но сложнореализуемым решением было бы разделить на аппаратном и софтверном уровне задачи криптографии+безопасности и общеприкладные. Тогда в первых можно было бы постоянно патчиться и апдейтиться, пусть и с потерей в скорости, но при этом не затрагивая производительности вторых. Но это очень серьезный сдвиг в текущей парадигме архитектуры железа и софта, который практически невыполним.
Где же проходит граница между стремлением сохранить 100% контроль над сверхсекретными данными и желанием смотреть на котиков в 8к 120fps?
Давайте шагать дальше, господа! Скажем, есть вектора атаки на чтение памяти по энергопотреблению БП, да, для успешной атаки необходимо 10 000 часов и прямой доступ к железу, но мы же параноики, так что теперь в комплекте с каждой планкой памяти давайте делать неотключаемый встроенный утюг. Есть атака по тональности свиста дросселей? Не вопрос! Добавим в каждый чипсет постояннодействующую сирену на 130 децибел. Можно залезть на шкаф и, пригнувшись, через бинокль в женской бане напротив рассмотреть пароль на экране администратора? Правильно! Сжечь все мониторы, только звуковой ввод/вывод через имплантируемые гарнитуры в массы и на все устройства!
Правильным, но сложнореализуемым решением было бы разделить на аппаратном и софтверном уровне задачи криптографии+безопасности и общеприкладные. Тогда в первых можно было бы постоянно патчиться и апдейтиться, пусть и с потерей в скорости, но при этом не затрагивая производительности вторых. Но это очень серьезный сдвиг в текущей парадигме архитектуры железа и софта, который практически невыполним.
Где же проходит граница между стремлением сохранить 100% контроль над сверхсекретными данными и желанием смотреть на котиков в 8к 120fps?
чтобы эксплуатировать хардварную уязвимость проца нужно выполнить зловредный код на целевом компьютере. В подавляющем большинстве случаев вас взломали уже на этом этапе
Какая выгода от того, что отделят безопасность от прикладных задач, когда дыра в том, что прикладная фишка процессора по предсказанию ветвления имеет дыру через которую можно стащить всё?
Я бы посмотрел, как «прикладная фишка» стащила бы все из специализированного криптографического сопроцессора, расположенного отдельным чипом на, возможно, отдельной защищенной шине.
Ок! Есть отдельная микросхема с криптографией. Но Спектре использует уязвимость микрокода процессора. Когда данные уже расшифрованы или ещё не зашифрованы. И эти данные лежат «условно» в процессоре. Дело не в наличии специальной аппаратной штуковине связанной с криптографией. А с тем, что безопасность кода нельзя отделить от кода. Если программист использует обычный текстовый файл, в котором хранятся логины и пароли, то наличие или отсутствие некоей аппаратной криптографии не спасёт от просто копирования файла на уровне ОС.
И да: криптография <> безопасность.
И да: криптография <> безопасность.
> И эти данные лежат «условно» в процессоре.
Так я же и говорю, что в этом и проблема. Они не должны лежать ни условно, ни буквально в процессоре. И методы соответствующие есть, но для их применения необходима существенная переработка архитектуры как железа, так и софта.
Ну и дальше вы пытаетесь спорить с соображениями, полностью противоречащими моему исходному коментарию. Будем вместе спорить с воображаемым оппонентом?
Если вы прочитали моё:
> Правильным, но сложнореализуемым решением было бы разделить на аппаратном и софтверном уровне задачи криптографии+безопасности и общеприкладные.
После чего представили себе конкретную реализацию данного утверждения, причем реализацию плохую и дырявую, а затем, почему-то, аксиоматизировали, что именно эту реализацию я и имел ввиду. То, извините, но это изъян не моего мнения, а вашей фантазии на его счёт.
Так я же и говорю, что в этом и проблема. Они не должны лежать ни условно, ни буквально в процессоре. И методы соответствующие есть, но для их применения необходима существенная переработка архитектуры как железа, так и софта.
Ну и дальше вы пытаетесь спорить с соображениями, полностью противоречащими моему исходному коментарию. Будем вместе спорить с воображаемым оппонентом?
Если вы прочитали моё:
> Правильным, но сложнореализуемым решением было бы разделить на аппаратном и софтверном уровне задачи криптографии+безопасности и общеприкладные.
После чего представили себе конкретную реализацию данного утверждения, причем реализацию плохую и дырявую, а затем, почему-то, аксиоматизировали, что именно эту реализацию я и имел ввиду. То, извините, но это изъян не моего мнения, а вашей фантазии на его счёт.
Так я же и говорю, что в этом и проблема. Они не должны лежать ни условно, ни буквально в процессоре. И методы соответствующие есть, но для их применения необходима существенная переработка архитектуры как железа, так и софта.
Можно по-подробнее об этих методах? А то я, видимо, не так всё понял из ваших комментариев.
Два примера на поверхности:
1. Шифрование.
Данные шифруются/дешифруются в физическом анклаве. Ключ не уходит за пределы сопроцессора. Да, остается возможной атака на дешифрованные данные, но их объем существенно больше размера ключа, и все атаки, скорость которых не позволяет поспевать за объемом протекающих в открытом виде данных, обламываются. Кроме того, у злоумышленника нет возможности ретроспективной и перспективной атаки, он может увидеть только то, что дешифровано вот прямо сейчас.
2. Аторизация.
Банальная токен авторизация. Ключ не уходит за пределы анклава, токен, генерируемый на основе ключа, одноразовый.
И это то, что решается прямо вот на коленке, защищенным хранилищем ключей с отдельным от основного процессора специализированным АЛУ. В случае нахождения атаки на данный анклав достаточно пропатчить только его, пусть и с потерей в его производительности. А котики как крутились себе на основном процессоре, так и крутятся на полной производительности.
1. Шифрование.
Данные шифруются/дешифруются в физическом анклаве. Ключ не уходит за пределы сопроцессора. Да, остается возможной атака на дешифрованные данные, но их объем существенно больше размера ключа, и все атаки, скорость которых не позволяет поспевать за объемом протекающих в открытом виде данных, обламываются. Кроме того, у злоумышленника нет возможности ретроспективной и перспективной атаки, он может увидеть только то, что дешифровано вот прямо сейчас.
2. Аторизация.
Банальная токен авторизация. Ключ не уходит за пределы анклава, токен, генерируемый на основе ключа, одноразовый.
И это то, что решается прямо вот на коленке, защищенным хранилищем ключей с отдельным от основного процессора специализированным АЛУ. В случае нахождения атаки на данный анклав достаточно пропатчить только его, пусть и с потерей в его производительности. А котики как крутились себе на основном процессоре, так и крутятся на полной производительности.
Безопасность — это комплексное понятие, но вот такие дыры низводят весь комплекс мер в ничто и требуют принципиально нового подхода к разработке софта — будем считать, что софт работает на изначально скомпроментированном компьютере, ваши действия?
Sign up to leave a comment.
SWAPGSAttack: уязвимость в процессорах Intel на Windows позволяет обойти защиту от Spectre и Meltdown