Pull to refresh

Comments 21

Объясните кто-нибудь электронику, как работает TPM, чем он занимается и почему осциллографом ничего нельзя подсмотреть?

…не отвечает на заданный вопрос.

TPM это криптопроцессор. Он генерирует, хранит и управляет ключевым материалом. Это такой оооочен сжаты TLDR. Он есть практически во всех новых ноутбуках. Все что с биометрикой он там точно присутствует. Фактически Apple T2 но не совсем.

Все можно подсмотреть осциллографом, если TPM живет на шине LPC, но обсуждаемый в статье Intel fTPM находится внутри чипсета или SoC'а, а туда просто так осциллограф уже не подсунешь.
UFO just landed and posted this here
Простейший вариант атаки возможен, если используется стандартная функция сравнения строк типа strcmp, которая на х86 может являться обёрткой над инструкцией repe cmpsb, в свою очередь время исполнения которой зависит от номера байта (слова, ...), в котором строки не совпадают.
Дальше вы шифровали-хешировали-расшифровывали, но в конце вам надо сравнить результат вашего шифрования с тем, что прислала та сторона, чтобы убедиться, что она знает ключ или пароль. Если функция сравнения уязвима к атаке по времени и нет ограничений на число попыток, «та сторона» может перебирать присылаемый результат по 1 байту и замерять время — у правильного байта это время будет больше.
Графики с этой новости совсем не те, которые нужны, оригинальная статья намного лучше поясняет, в чем именно проблема.

А проблема в том, если в используемых для генерации ключей затравочных однократно используемых значений (nonce) оказывается много нулей в начале, то генерация такого ключа выполняется быстрее (т.к. при наивной реализации на 0 быстрее умножать, чем на число, и умножение на число с большим количеством ведущих нулей оказывается быстрее, чем с небольшим. Мозг человека тоже уязвим, т.к. умножать в уме на 0007 легче, чем на 0183, а на 0183 легче, чем на 2749.).

В результате авторы, замеряя время генерации ключа, и собирая сгенерированные ключи, смогли накопить достаточно материала для lattice-атаки. По сути атака сводится к решению большой СЛАУ, которую получается составить только если можно каким-то образом отличить «уязвимые» ключи от «обычных». Там где у авторов это получилось, они смогли достать приватные ключи из устройств, специально сделаных для того, чтобы ключи из них достать было максимально непросто.
Разница в таймингах при этом оказалась настолько заметная, что ее можно замерять даже с удаленной машины.

Вот графики зависимости времени генерации ключа от количества ведущих нулей в nonce на уязвимых реализациях:
Intel — зависимость ступенчатая.

STMicro — зависимость линейная.

Приведенный тут график для Infinion — это то, как выглядит неуязвимая к данной атаке реализация.

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

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

Сложно сделать эти случайности достаточно непредсказуемыми, чтобы их нельзя было отфильтровать статистикой. Намного лучше будет использовать вычисления, устойчивые к этой атаке, т.е. такие, в котором секретное значение (nonce) не влияет на скорость вычисления результата. Таких "устойчивых к тайминг-атакам" крипто-библиотек уже разработано немало, но сама по себе задача написания такого кода очень нетривиальная, и зачастую практически невозможная без активной поддержки со стороны разработчиков и процессора, и компилятора. Пока что дальше предложений дело не пошло, поэтому так и приходится очень осторожно писать на ассемблере и тестировать непрерывно.
UFO just landed and posted this here
Вот это максимальное время может быть очень сложным концептом. Как его вычислить, не перебирая всех возможных nonce? Как гарантировать, что это время именно максимальное? Как замерять время, если источника качественных часов у тебя нет? Пробовали задержки, и где-то они даже работают относительно как-то, но консенсус у авторов крипто-библиотек сейчас в том, что задержки — это только малая часть общего решения, и смысл в них если и есть, то не очень много.
UFO just landed and posted this here
Если вносить неправильно, то толку от них в смысле безопасности не будет, только производительность упадет.

Вычислять, понятно, все равно придется, но нужно делать это так, чтобы количество (а значит и время) вычислений не зависело от значения байтов секрета (точнее, не было заметно, потому что совсем убрать эту зависимость сложно). Вот отличная подборка техник от известного криптолога, автора книги Serious Cryptography Жана-Филлипа Омассона.
UFO just landed and posted this here
Про задержку написал выше, идея эта крайне плохая, т.к. внесение случайной задержки требует наличия источника и очень хорошей случайности, и «хороших» в некотором смысле задержек (слишком маленькая задержка удаляется из данных статистикой, за слишком большую не пропустят, т.к. она очень заметно снижает производительность).

Про прописные истины: оглянитесь вокруг, среди ваших коллег много специалистов по криптоанализу? И если завтра к вам придет начальство и скажет «а давайте сделаем свой TPM», вы ляжете костьми, но специалиста такого наймете? Ну вот. Людям дали микроконтроллер и библиотеку на С, и сказали, чтобы за полгода-год они сделали из этого TPM, не не простой, а проходящий все сертификации. Они его сделали, выпустили, и продают успешно, а что там они подвержены простейшим атакам — это надо сначала дождаться, чтобы кто-то атаковать пришел, будучи при этом достаточно умелым.

Ну вот к ним и пришли теперь люди, которые там в академической среде имеют и массу времени, и достаточно знаний, и сильное желание сломать и опубликовать результаты (потому что диссертация им нужна намного сильнее, чем ключи какие-то). Реальный же атакующий (который за ключами пришел как раз) раскрывать суть успешной атаки не станет никогда (потому что ее тут же закроют), поэтому любым подобным сообщениям производители должны радоваться (потому что для них бесплатно сделали дорогой аудит).
UFO just landed and posted this here
По постоянной (т.н. black-box mitigation) тоже есть работы, но они по большей части требуют использования hard-RTOS, почитайте пункт 5.3.2 вот этого анализа.

Про спец-проц: кто вам сказал, что это он? Intel fTPM — это программная реализация, исполняемая на синтезированном из верилога аналоге i586 (т.н. Minute IA). Что внутри у STMicro я не знаю, не не удивлюсь какому-нибудь 8051, MIPS или ARCompact'у. Специальные вычислительные ядра делать дорого и долго, а бизнесу нужно дешево и вчера.
атака включает в себя инициирование около 45 тысяч handshake-соединений с удаленным VPN-сервером

Веское основание для ограничения количества соединений до 10 в час

… после чего какой-нибудь злоумышленник 10 раз пытается залогиниться с Вашим логином и паролем 123456, и всё, Вы попали, ждите час.

Обычно лимиты ставят per-ip, но в мире ipv4 это приводит к блокировке ip и сотням потенциально заблокированным невиновным (в мире веб к разгадывание капчи), а в ipv6… стоимость покупки/аренды огромных блоков настолько мала, что блокировки более-менее серьёзных атак по ipv6 малоэффективны

Sign up to leave a comment.

Other news