> 1) значение константное, уже утекло знание, что input или равен меньше этой константыАтакующий чаще всего знает лимиты. И даже если это новое знание, круто, знаете что надо угадать из 256^100. Сильно помогло?
> 2) это значит, необходимо "расширять" как input1, так и input2, чтобы не
> было всяких "выходов за границы"
Можно просто зарубать ввод длиннее оговоренного максимума. А если это ключи какие, они могут быть фиксированой длины by design. Иллюстрация не о том.
> 3) параллельно надо "думать", чем же заполнять расширенное "пространство",
Нужность этого зависит от того что это было, к затыканию таймингов не относится.
> if (flag != 0) { FAIL! } такая конструкция порождает новый вид bypass атак,
> когда можно всякими манипуляциями воздействовать на ячейку памяти и изменить
> ее значение, подобно этой:
1) ЭТОТ код относительно устойчив к rowhammer, до кучи. Лучше чем if (flag != 0) {AUTH OK!} у тех позорников, где любой бит сбить и в дамках. А тут удачи подогнать flag в именно ноль, любое иное == FAIL.
2) Это локальная временная "горячая" переменная, скорее всего в регистре. Его rowhammer-ом, как бы это... а в сях так то можно и "register" захинтить.
3) Если кто гасит систему rowhammer, он много чего еще сможет.
4) На допустим MCU вообще DRAM нет :P
> ок, ну так давайте разберем все плюсы и минусы данных решений.
Очевидный трабл - менее эффективно, но за ту оптимизацию - воздается вулном.
> частичто соглашусь, если он собран из универсального гейта,
У ALU логика обычно шириной с регистр и ему похрен что за биты.
> но где гарантии, что оба "инпута" на элемент приходят "одновременно",
Это от структуры системы очень зависит. Даже если cache hit vs cache miss сделает джиттер - это вроде бы не привязано к содержимому input1 или input2, т.е. нового инфо о их содержимом атакующий с этого не получает.
Ключевой вопрос: "что это дает атакуюшему?".
> будет всегда, ибо процесс 0 -> 1 и 1 -> 0 > "разный".
Регистровые операции как правило за 1 такт современными процами молотятся и там пофиг какие биты куда. На электрическом уровне, конечно, разницу бывает видно но это уже иной класс атак.
> в случае с тайминг атаками опасность предоставляют переходы,
Не только. В примере который я привел трабл в том что алго срубается за разное время в зависимости от (не)совпадений (==зависимость от содержимого). Это не столько про переходы сколько про неудачную логическую структуру алго. Он будет уязвим даже на проце где бранчи за постоянное время и не были проблемой. Логично что я для илллюстрации проблемы взял злой пример, уязвимый везде, плюс-минус :).
> тем самым делая тайминг атаки логическими атаками.
Тайминг атаки - это атаки накопления информации о пароле/ключе по сторонним каналам. Переходы и связанные утечки и проблемы - частный случай. Subset.
> принцип один, найти кореляцию между "входом и выходом"
В чем-то да, НО детали и применимость здорово отличаются. Электрические измерения требуют очень плотный физический доступ к атакуемой системе. Надолго. А тайминг атаки можно зачастую эксплуатировать ремотно по сети/RF или с соседней виртуалки. Куда более слабое требование.
> по миганию светодиода восстанавливали
Это тоже требует физический доступ, надолго и атака глючная.
> там вообще беда, в софтверных реализациях можно как-то закрывать вектора атак.
Вон то - одна из ипостасей. Я иллюстрировал ее, а не что-нибудь иное. Разумеется это не гарантирует решения всех проблем человечества и информационной безопасности.
Версия для распечатки
