Кратко и по делу — природа атак по побочным каналам и практические методы их снижения для криптографических библиотек и прикладного ПО.
1) Что такое побочные каналы (общая идея)
- Побочный канал — утечка секретной информации через нецелевой канал: время выполнения, поведение кэша, потребляемая мощность, электромагнитное излучение и т.д. Атакующий измеряет эти побочные параметры и сопоставляет с моделью алгоритма, чтобы восстановить секреты.
2) Timing attacks (атаки по времени)
- Природа: время выполнения зависит от секретных данных (ветвления, ранний выход, таблицы поиска, деление на переменную длину и т.п.).
- Примеры утечек: сравнение MAC с ранним выходом, условные ветви по битам ключа, таблицы S-box.
- Меры снижения:
- Писать алгоритмы constant-time: избегать ветвлений и памяти, зависящих от секрета; пример постоянного сравнения байтов: $\text{res}=0;\text{for}i\text{res}|=a_i\oplus b_i;\text{return}(\text{res}==0)$.
- Использовать константные по времени примитивы из проверенных библиотек (AES-NI, curve25519 реализации без ветвлений).
- Паддинг длины и ответы с фиксированными задержками (в сетевых протоколах) — только как дополнительная мера: добавление случайной задержки плохо защищает от статистического снятия измерений.
- Алгоритмические паттерны: Montgomery ladder для операций на эллиптических кривых, алгоритмы с детерминированным числом итераций.
- Тестирование на тайминг-утечки: tools типа dudect/ctgrind/Valgrind-плагины, статистический анализ.
3) Cache side‑channel (кэши — Flush+Reload, Prime+Probe и т.п.)
- Природа: доступы к памяти оставляют след в кэше; наблюдая время доступа к страницам/линиям кэша, атакующий узнаёт, какие данные/таблицы использовались.
- Уязвимые конструкции: таблицы S-box, lookup-таблицы, секрет-зависимые адреса, совместное использование кэша (виртуальные машины, SMT/hyperthreading).
- Меры снижения:
- Убрать таблицы: использовать bitslicing или арифметические/логические реализации вместо lookup.
- Использовать инструкции HW-crypto (AES-NI) — они не обращаются к программным таблицам.
- Выравнивание и предфетчинг не надёжны сами по себе; вместо этого:
- запрещать совместное использование физических ядер (отключить SMT/hyperthreading) в условиях угрозы;
- использовать изоляцию процессов/ядра (pinning, cgroups) и ограничивать совместный доступ к памяти;
- page coloring / cache partitioning (на уровне ОС/гипервизора) там, где доступно.
- Очистка конфиденциальных таблиц из кэша при завершении или использование непересекающихся таблиц для разных пользователей.
- Тестирование: Prime+Probe/Flush+Reload симуляции, инструменты профилирования кэша.
4) Power analysis (SPA/DPA/CPA) — анализ потребляемой мощности
- Природа: мгновенные или усреднённые измерения тока/напряжения во время операций коррелируют с промежуточными значениями (битами ключа, операциями над битами).
- SPA (Simple): визуальный анализ паттернов мощности; DPA/CPA: статистический метод, использующий множество измерений и модель предсказания промежуточной функции, затем корреляция.
- Меры снижения:
- Masking (сопрятание): представлять секрет как комбинацию масок, например $s=s_1\oplus s_2\oplus \dots$, и обеспечить корректные операции над замаскированными значениями (одно- и многократное маскирование).
- Blinding (слепление): для RSA — вычислять $m^{\prime }=m\cdot r^e\mathrm{mod}N$, затем после операции удалять $r$; для ЭЦП — рандомизация скаляра/координат.
- Hiding: добавление шумов, выравнивание уровня потребления (но это трудно и ненадёжно само по себе).
- Аппаратные меры: токовые фильтры, константное энергопотребление (dual-rail logic, current flattening), шифрующие co-processors.
- Для встроенных устройств применять порядок-маскирование (higher-order masking) и регулярную регенерацию масок.
- Тестирование: TVLA (Test Vector Leakage Assessment), CPA и SPA симуляции.
5) Практические рекомендации для крипто‑библиотек
- Использовать проверенные реализации, рассчитанные на constant-time (включая сборку на целевую архитектуру): например, libsodium, BearSSL/BoringSSL/LibreSSL с соответствующими модификациями; включать аппаратные ускорители (AES-NI, PCLMULQDQ).
- Не использовать секрет-зависимые lookup-таблицы; применять bitslicing или инструкции HW-crypto.
- Включать RSA/DSA/ECDSA блайндинг и случайизацию скаляров для ЭКК.
- Писать тесты на отсутствие утечек (dudect, Valgrind-ctgrind, TVLA/CPA) как часть CI.
- Документировать и задокументировать требования к среде исполнения (отключение SMT, требования к изоляции).
6) Практические рекомендации для общего прикладного ПО
- Не реинвентить криптографию: использовать библиотеку с доказанной безопасностью по побочным каналам.
- Для аутентификации/сравнения секретов — использовать constant-time сравнение (см. пример в пункте 2).
- Управлять длительностью ответов: фиксированная длина сообщений, одинаковая обработка ошибок (без дифференцированного стека ошибок), но не полагаться только на задержки как защиту.
- Минимизировать совместное размещение критических криптоопераций с непроверенным кодом (контейнеры, изоляция процессов).
- На сервере/VM: отключать SMT/hyperthreading при работе с чувствительными ключами; использовать отдельные CPU/pinning для криптографических потоков если возможно.
7) Проверка и оценка риска
- Включать автоматические тесты на утечки в CI: статистический TVLA, dudect, CPA-симуляции; проводить профайлинг кэша и тайминговые измерения.
- Оценивать угрозу: есть ли локальный/виртуальный атакующий, физический доступ, возможность измерять питание или кэш? Чем ближе атакующий к аппаратуре — тем строже меры.
Короткая сводка «что сделать в первую очередь»
- Использовать проверенные constant-time реализации и HW-ускорение.
- Для разработчиков: избегать секрет-зависимых ветвлений и обращений к памяти; применять блайндинг/маскирование для алгоритмов с физическим риском.
- В инфраструктуре: изоляция, отключение SMT, ограничение совместного использования кэша.
- Тестировать утечки (TVLA/dudect/CPA) как часть разработки.
Если нужно — могу дать чеклист для аудита конкретной библиотеки или примеры преобразования уязвимого кода в constant-time.