Comments 26
Глупый вопрос.
А на реальном железе и прошивках та же атака по питанию возможна за приемлемое время?
Когда кода нет и он не так прост.
Читал когда-то статью о методе сильного снижения эффективности аппаратного шифрования путем криогенной заморозки контроллера — встроенному генератору случайных чисел становилось не откуда брать «случайность». Было бы интересно посмотреть на эффективность комбинированной атаки
Сами атаки на пропуск инструкции кажутся мне крайне серьезными, а защита от атаки крайне слабой — без использования случайных задержек в голову приходят только проверки паролей с поэтапным вычислением хеша так, чтобы пропуск любого этапа делал хеш не валидным.
Сами атаки на пропуск инструкции кажутся мне крайне серьезными, а защита от атаки крайне слабой — без использования случайных задержек в голову приходят только проверки паролей с поэтапным вычислением хеша так, чтобы пропуск любого этапа делал хеш не валидным.
Сложность в проведении Vcc-glitch-атаки заключается в подборе верных параметров импульса. Реализация этой атаки заняла больше всего времени по сравнению с остальными, поскольку успешное проведение Vcc-glitch-атак зависит от факторов, описанных выше.
Это да, но иногда можно просто вслепую фигачить много glitch'ей подряд и в итоге получается обойти защиту. Часто код так беззащитен, что можно и инструкцию проскочить или поменять её на другую или данные подменить с помощью glitch атаки.
Vcc-glitch
И как это всё поможет, если проставлен BODLEVEL и BODEN? :)
CLK-glitch
Так же бесполезен, если используется RC МК.
Помню как в детстве развлекались, через катушку+усилитель, можно было послушать переходные процессы в калькуляторе, но если много слушать, то не факт, что можно обнаружить нужные данные, ибо рисковая архитектура очень шумит (т.к. много процессов выполняется параллельно).
Я так полагаю, тут рассмотрены частные случаи, ибо порой имея код — х ногу сломит, а тут сгусток сигналов.
И как это всё поможет, если проставлен BODLEVEL и BODEN? :)
Не все, к сожалению, используют фичи безопасности МК (STM32, например, имеет Clock Security System (CSS) и PowerSupply integrity monitoring (POR/PDR/BOR/PVD)). Масочный загрузчик МК, о котором пойдет речь в следующей статье, эти механизмы не использует. В итоге VCC glitch отлично работает для обхода проверки запрета считывания основной прошивки. :)
Наша цель – обойти инструкцию if в строке 103 при введении неверного пароля и попасть в случай else на строке 106
Статья, насколько я понимаю, предназначена не для популярного журнала. Поэтому, наверное, стоило оговориться, что в реальности МК выполняет не инструкции C, а машинный код, в который они откомпилированы. При этом в современных МК используется конвейер команд, поэтому связь между их выборкой из памяти и выполнением нежёсткая. Соответственно, использование glitch-методов должно быть тщательно рассчитано с учетом особенностей компиляции и аппаратуры, иначе оно напоминает стук кулаком по корпусу компьютера, в надежде обойти пароль…
Отличный комментарий! Вы абсолютно правы, здесь нарушается работа инструкции jmp. Мы решили опустить данные подробности в статье.
Особенности компиляции и аппаратуры конечно же влияют на параметры успешной glitch атаки. Но не обязательно тщательно рассчитывать все параметры glitch импульса, т.к. можно задать их автоматическое изменение в приблизительных диапазонах и ждать события, сигнализирующего об успешной атаке (например, сообщение о вводе верного пароля).
Особенности компиляции и аппаратуры конечно же влияют на параметры успешной glitch атаки. Но не обязательно тщательно рассчитывать все параметры glitch импульса, т.к. можно задать их автоматическое изменение в приблизительных диапазонах и ждать события, сигнализирующего об успешной атаке (например, сообщение о вводе верного пароля).
Поясните пжлст. непонятливому. Какая цель данных атак? Есть, например, МК с зашитым ПО и некоторой защитой. Что мы можем узнать описанными методами? Алгоритмы работы? Какие-то пароли? Или возможность сбить МК так, чтобы войти в сервисный режим? Ведь управлять железкой такими способами как-то затруднительно.
Всё зависит от конкретного устройства. Но по простому вот: иногда можно выудить ключ шифрования, можно заставить устройство стартануть с неподписаным firmware (в котором мы можем творить что угодно), можно ваторизироваться в системе не имея на то права, и так далее.
Цель glitch-атак — обойти какую-либо инструкцию МК, которая относится, например, к вводу пароля, запросу на доступ, проверке лицензионного соглашения, условию входа в сервисный режим и т.д. Все зависит от Ваших задач и исследуемых устройств.
К примеру, обойдя бит защиты прошивки, можно считать ее из МК, что позволит в дальнейшем и определить интересующие алгоритмы работы устройства (в том числе алгоритм проверки пароля), и внести вредоносный код в прошивку МК (в результате чего открывается возможность управления устройством).
К примеру, обойдя бит защиты прошивки, можно считать ее из МК, что позволит в дальнейшем и определить интересующие алгоритмы работы устройства (в том числе алгоритм проверки пароля), и внести вредоносный код в прошивку МК (в результате чего открывается возможность управления устройством).
Цель glitch-атак — обойти какую-либо инструкцию
Не всегда, если вы можете при помощи glitch-атаки поменять бит ключа шифрования (никак не меняя и не пропуская интсрукций), то потом можно сравнив результаты шифрования с правильным и изменённым ключом этот самый ключ вычислить.
Это уже напоминает Differential fault analysis :) Там как раз вносят с помощью гличей ошибки и на больших выборках анализируют, что позволяет получить какую-то информацию. Так сказать смежный тип атаки: что-то от пассивных side channel attacks, что-то от активных (fault injection).
Да, я описал «differential fault analysis», верно.
Но glitch — это способ внести ошибку в устройтво, а не полное описание атаки. Все glitch-атаки это активные атаки, так как над устройством совершают «непотребности», а не просто пассивно «смотрят и записывают» что оно делает. Glitch-атаки это подкатегория fault injection, так как glitch — только один из способов внести ошибку во время исполнения программы (можно ещё физически повредить часть микроконтроллера, например). В статье описаны несколько конкретных примеров glitch атак и способов устроить glitch, но не вся категория и не все способы. Можно glitch'и ещё устраивать при помощи лазера.
Но glitch — это способ внести ошибку в устройтво, а не полное описание атаки. Все glitch-атаки это активные атаки, так как над устройством совершают «непотребности», а не просто пассивно «смотрят и записывают» что оно делает. Glitch-атаки это подкатегория fault injection, так как glitch — только один из способов внести ошибку во время исполнения программы (можно ещё физически повредить часть микроконтроллера, например). В статье описаны несколько конкретных примеров glitch атак и способов устроить glitch, но не вся категория и не все способы. Можно glitch'и ещё устраивать при помощи лазера.
Согласен, можно еще излучением и перегревом. Но физическое повреждение — это уже инвазивная атака, все таки fault injection (glitch в статье и то, что Вы добавили) относятся к неинвазивным атакам, разве нет? Ну и, мне кажется, glitch является самым дешёвым способом (ну, может, дороже температурного воздействия).
Кстати, у chipwhisperer есть брат, который использует электромагнитное излучение для внесения ошибки — называется ChipShouter. На embedded world conference в Германии в 2019 году был их стенд, достаточно быстро вызывался сбой jmp в цикле.
Атаки можно делить по многим типам: активные — пассивные, простые — дифференциальные, инвазивные — неинвазивные (ещё иногда различают полуинвазивные), а ещё может быть с профилированием или без (profiled/non-profiled) а теперь ещё появились разные виды в смысле дистанции (remote / close proximity side-channel attacks). Дак вот, атака может быть активной, инвазивной, с моделью и дифференциальной одновременно. Может быть вообще любая другая комбинация. Пожалуй почти на любую комбинацию существует несколько атак.
Дак вот как только атака glitch, то это сразу активная, но не факт что инвазивная или неинвазивная итд.
Дак вот как только атака glitch, то это сразу активная, но не факт что инвазивная или неинвазивная итд.
А не пробовали на чём-то более быстром? На высоких частотах клока гораздо сложнее сформировать короткий импульс глитча, особенно по питанию.
Нам удавалось успешно проводить glitch-атаку при работе STM32 на 24 МГц. Конечно же все зависит от обвязки и многих других условий, но сформировать Vcc-glitch с 3,3 В до 1,7 В с длительностью около 25 нс вполне возможно. С аппаратной точки зрения — внутри ChipWhisperer стоит ПЛИС, которая имеет возможность выставлять параметры импульса с оценочным рассчитанным разрешением не хуже 0,1 нс
А зачем более быстрое железо, когда можно наоборот тактировать с меньшей частотой к примеру STM32 может даже от часового кварца работать. скорость UART тоже соотвественно нужно будет уменьшить.
А не знаете, есть ли практика уменьшения тактовой частоты для SCA-атак?
По идее если меньше частота то графики потребления мощности будут менее зашумленные
А не знаете, есть ли практика уменьшения тактовой частоты для SCA-атак?
По идее если меньше частота то графики потребления мощности будут менее зашумленные
Да, снижение частоты позволит упростить атаку. Однако, при тактировании от внутреннего генератора МК такой подход становится невозможным. Также, если у МК есть времязависимая периферия, это может привести к нарушению обмена данными между ними. Поэтому такой подход не является универсальным решением, а более частным.
Мы не пробовали понижение частоты при SCA атаках, но это интересный вопрос который стоит проработать. По нашим наблюдениям, на уровень шума влияет номинал шунтирующего резистора. При увеличении резистора с 10 Ом до 24 Ом мы получили более «красивые» графики сигнатур.
Мы не пробовали понижение частоты при SCA атаках, но это интересный вопрос который стоит проработать. По нашим наблюдениям, на уровень шума влияет номинал шунтирующего резистора. При увеличении резистора с 10 Ом до 24 Ом мы получили более «красивые» графики сигнатур.
Таким способом недавно ESP32 взломали https://limitedresults.com/2019/11/pwn-the-esp32-forever-flash-encryption-and-sec-boot-keys-extraction/
Интересно, а вычитать flash таким методом можно из Motorola Coldfire V1 MCF51JM128 (MCF51JM128VQH, MCF51JM128VLH)?
Добрый день!
Атаки такого рода очень индивидуальны. Например, в Вашем процессоре внутренняя флеш-память. Теоретически, можно детальным анализом шины питания определить моменты чтения ПЗУ и побитно восстановить образ прошивки. А может удастся импульсом в нужный момент заставить процессор «думать», что защита от чтения не установлена, и считать всё программатором.
Здесь возникает вопрос, стоит ли результат затраченных усилий. Считать можно практически всё, вопрос времени и средств.
Атаки такого рода очень индивидуальны. Например, в Вашем процессоре внутренняя флеш-память. Теоретически, можно детальным анализом шины питания определить моменты чтения ПЗУ и побитно восстановить образ прошивки. А может удастся импульсом в нужный момент заставить процессор «думать», что защита от чтения не установлена, и считать всё программатором.
Здесь возникает вопрос, стоит ли результат затраченных усилий. Считать можно практически всё, вопрос времени и средств.
Sign up to leave a comment.
Аппаратные атаки на микроконтроллеры с использованием ChipWhisperer и методы защиты от них