Исследователи из Вустерского политехнический института США, Любекского университета Германии и Калифорнийского университета в Сан-Диего выявили две уязвимости в TPM-процессорах. Проблемы под общим названием TPM-FAIL делали возможным для злоумышленников похищать хранящиеся в процессорах криптографические ключи.
Уязвимость CVE-2019-11090 затрагивает технологию Intel Platform Trust (PTT). Данное программное TPM-решение от Intel fTPM применяется в серверах, ПК и ноутбуках. Его используют большинство производителей компьютеров, включая Dell, HP и Lenovo. Также Intel fTPM широко используется в семействе продуктов Intel Internet of Things (IoT) для промышленности, здравоохранения и транспортных средств.
Другая уязвимость CVE-2019-16863 затрагивает чип ST33 TPM производства STMicroelectronics, который применяется на устройствах начиная от сетевого оборудования и заканчивая облачными серверами. Он является одним из немногих процессоров с классификацией CommonCriteria (CC) EAL 4+, то есть поставляется со встроенной защитой против атак по сторонним каналам.
Исследователи организовали атаки под названием «timing leakage». Источник атаки может определить разницу во времени при выполнении TPM повторяющихся операций. Он может «просмотреть» обрабатываемые внутри защищенного процессора данные. Эту технику можно использовать для извлечения 256-битных закрытых ключей в TPM.
Ключи применяют в определенных схемах цифровой подписи на основе алгоритмов эллиптических кривых, таких как ECDSA и ECSchnorr. Они являются общими схемами цифровой подписи, используемыми во многих современных криптографически защищенных операциях — установление TLS-соединений, подписывание цифровых сертификатов, авторизация входов в систему.
«Локальный злоумышленник может восстановить ключ ECDSA из Intel fTPM за 4-20 минут в зависимости от уровня доступа. Атаки можно также осуществлять удаленно в сетях путем восстановления ключа аутентификации VPN-сервера за 5 часов», — поделились исследователи.
Они выяснили, что такая атака включает в себя инициирование около 45 тысяч handshake-соединений с удаленным VPN-сервером и запись ответов. В ходе наблюдения за временем отклика злоумышленник может восстановить закрытый ключ, который VPN-сервер использует для подписи и проверки процессов авторизации, и получить доступ к защищенной сети VPN.
Однако в исследовании подчеркивается, что эту атаку достаточно сложно реализовать, для этого хакеру потребуются дополнительные технические знания.
Исследователи сообщили Intel о своих выводах 1 февраля, и компания выпустила обновления прошивки для Intel PTT, которые исправляют уязвимость. STMicroelectronics, которую проинформировали 15 мая, подготовила новую версию чипа ST33, в сентябре признанную устойчивой к атакам TPM-FAIL.
Комментарии (21)
loki82
16.11.2019 21:57Я правильно понимаю, что каждая часть ключа вносит свою задержку? Т. Е ключ получают по частям? А как такое возможно?
vanxant
15.11.2019 23:23Простейший вариант атаки возможен, если используется стандартная функция сравнения строк типа strcmp, которая на х86 может являться обёрткой над инструкцией repe cmpsb, в свою очередь время исполнения которой зависит от номера байта (слова, ...), в котором строки не совпадают.
Дальше вы шифровали-хешировали-расшифровывали, но в конце вам надо сравнить результат вашего шифрования с тем, что прислала та сторона, чтобы убедиться, что она знает ключ или пароль. Если функция сравнения уязвима к атаке по времени и нет ограничений на число попыток, «та сторона» может перебирать присылаемый результат по 1 байту и замерять время — у правильного байта это время будет больше.
CodeRush
16.11.2019 03:01+2Графики с этой новости совсем не те, которые нужны, оригинальная статья намного лучше поясняет, в чем именно проблема.
А проблема в том, если в используемых для генерации ключей затравочных однократно используемых значений (nonce) оказывается много нулей в начале, то генерация такого ключа выполняется быстрее (т.к. при наивной реализации на 0 быстрее умножать, чем на число, и умножение на число с большим количеством ведущих нулей оказывается быстрее, чем с небольшим. Мозг человека тоже уязвим, т.к. умножать в уме на 0007 легче, чем на 0183, а на 0183 легче, чем на 2749.).
В результате авторы, замеряя время генерации ключа, и собирая сгенерированные ключи, смогли накопить достаточно материала для lattice-атаки. По сути атака сводится к решению большой СЛАУ, которую получается составить только если можно каким-то образом отличить «уязвимые» ключи от «обычных». Там где у авторов это получилось, они смогли достать приватные ключи из устройств, специально сделаных для того, чтобы ключи из них достать было максимально непросто.
Разница в таймингах при этом оказалась настолько заметная, что ее можно замерять даже с удаленной машины.
Вот графики зависимости времени генерации ключа от количества ведущих нулей в nonce на уязвимых реализациях:
Intel — зависимость ступенчатая.
STMicro — зависимость линейная.
Приведенный тут график для Infinion — это то, как выглядит неуязвимая к данной атаке реализация.
Короче, и интересующимся, и особенно автору посоветую оригинальную публикацию прочитать все же, а не переводить новости из источников, которые только звон слышали, и то где-то далеко, и картинки прикрепляют почти случайные.S-trace
16.11.2019 14:08Правильно ли я понял, что изменение тактовой частоты на случайную величину или пропуск случайных тактов может свести эффективность такой атаки к нулю?
CodeRush
16.11.2019 17:27Сложно сделать эти случайности достаточно непредсказуемыми, чтобы их нельзя было отфильтровать статистикой. Намного лучше будет использовать вычисления, устойчивые к этой атаке, т.е. такие, в котором секретное значение (nonce) не влияет на скорость вычисления результата. Таких "устойчивых к тайминг-атакам" крипто-библиотек уже разработано немало, но сама по себе задача написания такого кода очень нетривиальная, и зачастую практически невозможная без активной поддержки со стороны разработчиков и процессора, и компилятора. Пока что дальше предложений дело не пошло, поэтому так и приходится очень осторожно писать на ассемблере и тестировать непрерывно.
loki82
16.11.2019 17:36Это же специализированный проц. Он не может считать кол-во тактов? И отдавать только по определённым? Т.е. Не важно сколько ушло на дешифровку. Отдавать результат в такт с максимальным временем на дешифровку популярного алгоритма. И сразу. Это можно вылечить программно, или все. Все уязвимы?
CodeRush
16.11.2019 17:56+1Вот это максимальное время может быть очень сложным концептом. Как его вычислить, не перебирая всех возможных nonce? Как гарантировать, что это время именно максимальное? Как замерять время, если источника качественных часов у тебя нет? Пробовали задержки, и где-то они даже работают относительно как-то, но консенсус у авторов крипто-библиотек сейчас в том, что задержки — это только малая часть общего решения, и смысл в них если и есть, то не очень много.
loki82
16.11.2019 18:03Тогда совсем не понятно. Если не вносить задержек, то видим то что видим. А если вносить, то через какое то время есть вероятность что тоже не поможет? Я не про квантовые вычисления. Всегда думал что на вычисление значения требуется определённое количество тактов. А чем криптографический чип отличается от других? Или все намного сложней?
CodeRush
16.11.2019 18:13Если вносить неправильно, то толку от них в смысле безопасности не будет, только производительность упадет.
Вычислять, понятно, все равно придется, но нужно делать это так, чтобы количество (а значит и время) вычислений не зависело от значения байтов секрета (точнее, не было заметно, потому что совсем убрать эту зависимость сложно). Вот отличная подборка техник от известного криптолога, автора книги Serious Cryptography Жана-Филлипа Омассона.
loki82
16.11.2019 16:17Я думал это прописные истины. Чуть ли не в каждом учебнике про это пишется. Или это все ради ускорения? Достаточно же внести задержку в вычисление? Если слишком быстро расшифровали, ждём и только потом отдаём.
CodeRush
16.11.2019 17:44Про задержку написал выше, идея эта крайне плохая, т.к. внесение случайной задержки требует наличия источника и очень хорошей случайности, и «хороших» в некотором смысле задержек (слишком маленькая задержка удаляется из данных статистикой, за слишком большую не пропустят, т.к. она очень заметно снижает производительность).
Про прописные истины: оглянитесь вокруг, среди ваших коллег много специалистов по криптоанализу? И если завтра к вам придет начальство и скажет «а давайте сделаем свой TPM», вы ляжете костьми, но специалиста такого наймете? Ну вот. Людям дали микроконтроллер и библиотеку на С, и сказали, чтобы за полгода-год они сделали из этого TPM, не не простой, а проходящий все сертификации. Они его сделали, выпустили, и продают успешно, а что там они подвержены простейшим атакам — это надо сначала дождаться, чтобы кто-то атаковать пришел, будучи при этом достаточно умелым.
Ну вот к ним и пришли теперь люди, которые там в академической среде имеют и массу времени, и достаточно знаний, и сильное желание сломать и опубликовать результаты (потому что диссертация им нужна намного сильнее, чем ключи какие-то). Реальный же атакующий (который за ключами пришел как раз) раскрывать суть успешной атаки не станет никогда (потому что ее тут же закроют), поэтому любым подобным сообщениям производители должны радоваться (потому что для них бесплатно сделали дорогой аудит).loki82
16.11.2019 17:52Я прочитал про рандомную задержку. А с постоянной что? Ещё раз это спец проц. Скорее всего с реалтаймом. Или не так? За пояснения спасибо. Но даже на сайте при авторизации рекомендуют вносить такую задержку.
CodeRush
16.11.2019 18:06По постоянной (т.н. black-box mitigation) тоже есть работы, но они по большей части требуют использования hard-RTOS, почитайте пункт 5.3.2 вот этого анализа.
Про спец-проц: кто вам сказал, что это он? Intel fTPM — это программная реализация, исполняемая на синтезированном из верилога аналоге i586 (т.н. Minute IA). Что внутри у STMicro я не знаю, не не удивлюсь какому-нибудь 8051, MIPS или ARCompact'у. Специальные вычислительные ядра делать дорого и долго, а бизнесу нужно дешево и вчера.
S-trace
16.11.2019 01:28-1атака включает в себя инициирование около 45 тысяч handshake-соединений с удаленным VPN-сервером
Веское основание для ограничения количества соединений до 10 в час
Wesha
16.11.2019 02:34+2… после чего какой-нибудь злоумышленник 10 раз пытается залогиниться с Вашим логином и паролем 123456, и всё, Вы попали, ждите час.
in_heb
16.11.2019 09:06Обычно лимиты ставят per-ip, но в мире ipv4 это приводит к блокировке ip и сотням потенциально заблокированным невиновным (в мире веб к разгадывание капчи), а в ipv6… стоимость покупки/аренды огромных блоков настолько мала, что блокировки более-менее серьёзных атак по ipv6 малоэффективны
Tsvetik
Объясните кто-нибудь электронику, как работает TPM, чем он занимается и почему осциллографом ничего нельзя подсмотреть?
Rigidus
Вторая ссылка в гугле по запросу «как работает ТРМ»
docs.microsoft.com/ru-ru/windows/security/information-protection/tpm/trusted-platform-module-overview
powerman
…не отвечает на заданный вопрос.
herrjemand
TPM это криптопроцессор. Он генерирует, хранит и управляет ключевым материалом. Это такой оооочен сжаты TLDR. Он есть практически во всех новых ноутбуках. Все что с биометрикой он там точно присутствует. Фактически Apple T2 но не совсем.
CodeRush
Все можно подсмотреть осциллографом, если TPM живет на шине LPC, но обсуждаемый в статье Intel fTPM находится внутри чипсета или SoC'а, а туда просто так осциллограф уже не подсунешь.