side channel

[sab123]

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

Comments

[sobriquet9]

Не только в чипах. Постоянное время выполнения является одним из факторов, которые используются при выборе примитивов для алгоритмов шифрования. В частности поэтому так популярны ARX шифры (add-rotate-exclusive or) вроде ChaCha20.

[sab123]

Ну так какой-нибудь AES наверное тоже со вполне себе постоянным временем. Даже древний DES - тоже сплошное перемешивание и XOR. Другое дело, что в DESe перемешивание такое, что его легко сделать в железе, но очень неудобно делать в софте. А для софта популярны алгоритмы, в которых не надо выбирать отдельные биты, а можно оперировать сразу словами. Для AES это тоже было одним из критериев.

[sobriquet9]

AES использует массивы, время доступа к элементам которых зависит от того, есть ли они в кеше. This attack should be blamed on the AES design, not on the particular AES library used by the server; it is extremely difficult to write constant-time high-speed AES software for common general-purpose computers (ссылка на PDF).

[sab123]

Ну, в железных реализациях это наверное не проблема, там S-boxes легко сделать с фиксированным временем доступа. А в софте это, наверное, можно обойти с некоторой ценой, поместив их в не-кэшируемую память. Вообще эта атака полагается на кооперацию со стороны сервера, который старательно дает точную информацию о времени шифрования.

[sobriquet9]

Не так просто из софта управлять тем, что будет в кеше, а что нет. Если код переносимый (кросс платформенный), то вообще никак. А если удастся все кеши выключить, то доступ к памяти будет медленнее в разы, производительность пострадает. Сейчас же шифруется всё, что ходит наружу и сохраняется на диске.

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

[sab123]

Операция доступа к диску вносит гораздо более крупные задержки, чем шифрование. Ну, а если начинается затык в производительности, то запросы начинают составляться в очереди, и включается время ожиания в очереди. Это не говоря уже о том, что когда начинает идти шифрование не одного блока, а более длинного массива, то получается больше разброса.

[sobriquet9]

В статье по ссылке была не теоретическая, а вполне практическая атака, с учётом сетевых и прочих задержек. Диск тут не при чём, сервера на многие запросы отвечают прямо из памяти, без походов на диск.

Шифрование - базовый алгоритм. Если его можно сделать так, чтобы не было атак по времени исполнения, то надо так и делать, а не использовать хреновый алгоритм и обвешивать его задержками. Время течёт в одну сторону, любые задержки в итоге увеличивают время выполнения команд. Если поручить программистам включать их по необходимости, программисты накосячат и забудут это делать в нужном месте. В частности именно отсюда популярность ChaCha20 и подобных шифров.

[sab123]

В статье сервер возвращал информацию о времени выполнения явным образом прямо внутри ответа.

[sobriquet9]

Автор объясняет, почему: "I wrote this server to minimize the amount of noise in the timings available to the client. However, adding noise does not stop the attack: the client simply averages over a larger number of samples, as in [7]. In particular,reducing the precision of the server's timestamps, or eliminating them from the server's responses, does not stop the attack: the client simply uses round-trip timings based on its local clock, and compensates for the increased noise by averaging over a larger number of samples."