Криптография

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

«ИТ-специалисты часто просят нематематических определений криптографических терминов… Но даже имея их, легко ошибиться. Как сказал Пол Кохер: "Можно ожидать взлома любого криптопродукта, разработанного компанией, которая не нанимает кого‑то из присутствующих в этом зале"».

1. Исторический контекст и базовые понятия

Начнем с истории, чтобы показать эволюцию идей.

• Шифр Цезаря и моноалфавитная подстановка: простые замены букв. Взламываются частотным анализом.
• Шифр Виженера (Vigenère): полиалфавитная подстановка с повторяющимся ключом. Считался невзламываемым веками, пока Касиски не нашёл метод анализа повторений для определения длины ключа.
• Одноразовый блокнот (One‑Time Pad): единственная система с абсолютной (безусловной) стойкостью. Ключ должен быть истинно случайным, равным длине сообщения и использоваться только один раз. Проблема: сложность распределения и хранения огромных объёмов ключей.
• Однонаправленные функции (one‑way functions): функции, которые легко вычислить в одну сторону, но трудно обратить. Пример из истории: тестовые ключи (test keys) в телеграфе для проверки целостности сообщений.

2. Модель случайного оракула (Random Oracle Model)

Теоретическая модель, чтобы формализовать понятие «хорошего» шифра.

• Идея: криптографический примитив считается хорошим, если он неотличим от истинно случайной функции (оракула), которая возвращает случайный ответ на каждый новый запрос.
• Зачем это нужно: это позволяет разделить задачу доказательства стойкости протокола (компьютерная наука) и задачу доказательства стойкости алгоритма (математика). Мы предполагаем, что алгоритм ведёт себя как «чёрный ящик» со случайными выходами.

3. Симметричные криптопримитивы

Здесь рассматриваются алгоритмы, использующие один ключ для шифрования и расшифровки.

Блочные шифры (block ciphers)

Шифруют данные фиксированными блоками (например, 64 или 128 бит).

• SP‑сети (Substitution‑Permutation Networks): комбинация замен (S‑boxes) и перестановок. Примеры: AES (Advanced Encryption Standard) и Serpent.
  -- AES: современный стандарт. Использует байтовые замены, сдвиги строк и смешивание столбцов. Очень эффективен в программной реализации.
  -- Serpent: консервативный дизайн с большим запасом прочности (больше раундов), но медленнее AES.
• Сети Фейстеля (Feistel ciphers): делят блок на две половины и применяют функцию раунда к одной половине, затем меняют их местами. Главное преимущество: функция раунда не обязана быть обратимой.
  -- DES (Data Encryption Standard): классический шифр с 56‑битным ключом. Сейчас считается устаревшим из‑за малой длины ключа (взламывается полным перебором).
  -- Triple‑DES: использование DES три раза с разными ключами для увеличения стойкости. Всё ещё используется в банковских системах из‑за совместимости.

Режимы работы блочных шифров

Как шифровать данные длиннее одного блока?

• ECB (Electronic Code Book): каждый блок шифруется независимо. Опасно! Одинаковые блоки открытого текста дают одинаковые блоки шифротекста, выявляя структуру данных (знаменитый пример с пингвином Tux).
• CBC (Cipher Block Chaining): каждый блок перед шифрованием складывается по XOR с предыдущим блоком шифротекста. Скрывает паттерны, но ошибки распространяются. Требует вектора инициализации (IV).
• CTR (Counter Mode) и OFB (Output Feedback): превращают блочный шифр в потоковый. Шифруется счётчик или предыдущий выход, результат складывается с данными. Позволяют параллельное шифрование.
• MAC (Message Authentication Code): код аутентификации сообщения. Гарантирует целостность и подлинность. Обычно строится на основе CBC (берётся последний блок) или специальных конструкций (CMAC, GMAC).

Потоковые шифры (stream ciphers)

Генерируют длинную псевдослучайную последовательность (ключевой поток), которая складывается по XOR с данными.

• Часто реализуются аппаратно (быстро, мало вентилей).
• Критическая уязвимость: повторное использование ключевого потока (как в одноразовом блокноте) фатально. Если C1=P1⊕K и C2=P2⊕K, то C1⊕C2=P1⊕P2, что позволяет восстановить открытые тексты.

Хеш‑функции (hash functions)

Преобразуют сообщение произвольной длины в фиксированный дайджест (отпечаток).

• Свойства: односторонность, устойчивость к коллизиям (трудно найти два разных сообщения с одинаковым хешем).
• Парадокс дней рождений: вероятность найти коллизию растёт не линейно, а как квадратный корень от пространства значений. Для хеша длиной n бит нужно около 2n/2 попыток. Поэтому для стойкости 128 бит нужен хеш длиной 256 бит.
• Примеры: MD5 и SHA‑1 считаются сломанными (найдены методы нахождения коллизий быстрее полного перебора). Рекомендуется использовать SHA‑256 и выше.
• HMAC: способ построения MAC на основе хеш‑функций с ключом.

4. Асимметричные криптопримитивы

Используют пару ключей: открытый (для шифрования / проверки) и закрытый (для расшифровки / подписи).

• RSA: основан на сложности разложения больших чисел на множители.
  -- Шифрование: C = Me mod N.
  -- Подпись: S = Md mod N.
  -- Угрозы: гомоморфизм (произведение шифротекстов соответствует произведению открытых текстов), атаки по времени, атаки на реализацию (BLEICHENBACHER). Требуется правильное дополнение (padding), например OAEP.
• Дискретные логарифмы (Diffie‑Hellman, ElGamal, DSA): основаны на сложности вычисления дискретного логарифма в конечных полях.
  -- Diffie‑Hellman: протокол обмена ключами. Позволяет двум сторонам создать общий секрет по незащищённому каналу. Уязвим к атаке «человек посередине» без дополнительной аутентификации.
  -- DSA/DSS: стандарт цифровой подписи США. Использует рандомизацию (каждая подпись уникальна даже для одного сообщения).
• Эллиптические кривые (ECC): позволяют использовать гораздо более короткие ключи при той же стойкости, что и RSA/DH. Эффективны для смарт‑карт и мобильных устройств.

5. Глубокий анализ уязвимостей реализаций: почему теория расходится с практикой

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

Атаки по сторонним каналам (side‑channel attacks)

• Анализ потребления энергии (power analysis):
  -- Простой анализ (SPA): наблюдение за формой волны потребления тока. Разные операции (сложение, умножение, сдвиг) потребляют разное количество энергии. Если код выполняет ветвление if (bit == 1), это видно на графике.
  -- Дифференциальный анализ (DPA): статистическая обработка тысяч трасс потребления. Даже если шум велик, корреляция между гипотетическим битом ключа и реальным потреблением позволяет восстановить ключ.
  -- Пример: взлом смарт‑карт GSM (алгоритм Comp128) и банковских карт. Злоумышленник просто подключает осциллограф к контактам питания карты.
• Атаки по времени (timing attacks):
  -- Измерение времени выполнения операций. Например, в RSA операция возведения в степень зависит от значений битов секретного ключа. Если бит равен 1, выполняется дополнительное умножение. Измеряя время расшифровки множества сообщений, можно побитово восстановить приватный ключ.
  -- Кэш‑атаки (cache timing): в современных процессорах доступ к данным в кэше быстрее, чем в оперативной памяти. Если таблица подстановки (S‑box) блочного шифра не помещается целиком в кэш или доступ к ней зависит от ключа, злоумышленник (даже удалённый, через виртуальную машину) может измерить время доступа и восстановить ключ. Это актуально для реализаций AES в программном обеспечении.
• Защита:
  -- Маскирование (masking): разделение данных на случайные доли так, чтобы потребление энергии не коррелировало с обрабатываемыми данными.
  -- Выравнивание (balancing): написание кода так, чтобы все ветви исполнения занимали одинаковое время и потребляли одинаковую энергию (constant‑time implementation).
  -- Шум: добавление случайных задержек или шума в питание.

Ошибки в режимах работы и протоколах

• Повторное использование nonce/IV: в потоковых шифрах (или режиме CTR/OFB) повторное использование одного и того же ключа и вектора инициализации (IV) фатально. Если C1 = P1 ⊕ K и C2 = P2 ⊕ K, то C1 ⊕ C2 = P1 ⊕ P2. Зная структуру открытого текста (например, заголовки файлов), можно восстановить оба сообщения.
  -- Исторический пример: проект VENONA, где советские разведчики повторно использовали части одноразовых блокнотов, что позволило США раскрыть сеть шпионов.
• Гомоморфизм RSA: «сырой» RSA обладает свойством E(m1) * E(m2) = E(m1 * m2). Это позволяет атаковать подписи или шифрования без знания ключа.
  -- Решение: использование схем заполнения (padding), таких как OAEP (Optimal Asymmetric Encryption Padding), которые добавляют случайность и разрушают алгебраическую структуру.

6. Управление ключами: самое слабое звено

Криптография сводится к управлению ключами. Если ключ скомпрометирован, алгоритм не имеет значения.

• Генерация ключей: ключи должны быть истинно случайными. Псевдослучайные генераторы (PRNG), основанные на предсказуемых источниках энтропии (например, системное время), могут быть взломаны.
  -- Пример: уязвимость в генераторе случайных чисел Debian OpenSSL (2008), где из‑за ошибки в коде пространство ключей сократилось до нескольких тысяч вариантов, делая перебор тривиальным.
• Распределение ключей: проблема «курицы и яйца»: как передать ключ безопасно, если нет безопасного канала?
  -- Решение: протоколы обмена ключами (Diffie‑Hellman), но они уязвимы к атаке «человек посередине» без дополнительной аутентификации (цифровые сертификаты, предварительно распределённые ключи).
• Хранение ключей: ключи не должны храниться в открытом виде на диске.
  -- Использование аппаратных модулей безопасности (HSM, TPM, смарт‑карты), которые защищают ключи от извлечения даже при физическом доступе (хотя и здесь возможны атаки по сторонним каналам).
  -- Разделение секрета (secret sharing): схема Шамира позволяет разделить ключ на n частей так, что для восстановления нужны любые k частей (k < n). Это защищает от потери ключа одним лицом и требует сговора нескольких инсайдеров для компрометации.

7. Формальная верификация и доказательства безопасности

Можно ли доказать, что криптосистема надёжна?

• Сведение задач (reductionist security): доказательство строится по принципу: «Если существует эффективный алгоритм взлома нашей криптосистемы, то существует эффективный алгоритм решения известной сложной математической задачи (например, факторизации больших чисел или дискретного логарифмирования)». Поскольку считается, что эти математические задачи нерешаемы за полиномиальное время, то и криптосистема стойка.
• Модель случайного оракула: многие доказательства (например, для OAEP) предполагают, что хеш‑функция ведёт себя как идеальный случайный оракул. На практике хеш‑функции (SHA‑256 и др.) детерминированы и могут иметь скрытые свойства, отличные от случайного оракула, что иногда ломает доказательства безопасности.
• Ограничения: доказательства часто игнорируют реализацию (side‑channels), человеческий фактор и корректность спецификаций. Система может быть «доказательно безопасной» в модели, но уязвимой в реальности.

8. Эволюция стандартов и длина ключей

Безопасность не статична; она деградирует со временем из‑за роста вычислительной мощности и улучшения алгоритмов.

• Закон Мура и алгоритмические прорывы:
  -- DES (56 бит) был взломан перебором ещё в конце 90‑х (проект EFF Deep Crack). Сейчас это делается за часы на обычном ПК.
  -- RSA‑1024 считается находящимся на грани опасности. Современные стандарты рекомендуют RSA‑2048 или RSA‑3072 для долгосрочной защиты.
  -- Эллиптические кривые (ECC) обеспечивают ту же стойкость при значительно меньшей длине ключа (256 бит ECC ≈ 3072 бит RSA), что критично для мобильных устройств и IoT.
• Квантовая угроза:
  -- Алгоритм Шора позволяет квантовому компьютеру эффективно решать задачи факторизации и дискретного логарифма, ломая RSA и ECC.
  -- Симметричные шифры (AES) более устойчивы: квантовый алгоритм Гровера лишь квадратично ускоряет перебор, поэтому удвоение длины ключа (переход на AES‑256) нейтрализует угрозу.
  -- Постквантовая криптография: активная разработка новых алгоритмов (на решётках, кодах исправления ошибок), устойчивых к квантовым атакам.

9. Экономика криптографии

Выбор криптографии — это всегда компромисс между безопасностью, производительностью и стоимостью.

• Лицензионные ограничения: исторически экспорт сильной криптографии из США был ограничен (до 40 бит), что вынуждало использовать слабые версии («export grade»), которые легко взламывались. Это создало ложное чувство безопасности у пользователей.
• Стоимость внедрения: переход на новые алгоритмы требует обновления оборудования (смарт‑карты, HSM) и ПО. Инерция индустрии (особенно банковской) огромна. Пример: медленный переход от DES к Triple‑DES и затем к AES.
• «Security through Obscurity» vs открытость: попытки создать собственные закрытые алгоритмы («секретные») почти всегда приводят к провалу. Принцип Керкгоффса гласит: стойкость системы должна зависеть только от секретности ключа, а не от секретности алгоритма. Открытый общественный анализ (как в случае с конкурсом AES) выявляет слабости до внедрения.

Главный вывод

Криптография — мощный инструмент, но это всего лишь «клей», скрепляющий систему.

1. Не изобретайте свои алгоритмы; используйте стандартизированные (AES, SHA‑2, RSA/ECC).
2. Правильно выбирайте режимы работы (никакого ECB!).
3. Следите за длиной ключей (с учётом роста вычислительной мощности).
4. Защищайте реализацию от побочных каналов.
5. Помните, что криптография не спасёт от плохого управления ключами или социальной инженерии.

Самые серьёзные утечки происходят из‑за ошибок в коде, побочных каналов и плохого управления ключами, а не из‑за слабости математики. Алгоритм, безопасный сегодня (RSA‑2048), может стать уязвимым завтра — необходимо планировать миграцию заранее. Инженер безопасности должен понимать не только математику, но и физику (для защиты от side‑channels), архитектуру процессоров (для защиты от кэш‑атак) и процессы управления жизненным циклом ключей.

Распределённые системы

Если ранее мы закладывали фундамент (протоколы, контроль доступа, криптография), то сейчас расскажу, как эти элементы ведут себя в реальном, сложном и часто враждебном мире распределённых вычислений. Подчёркнем, что масштабирование систем приводит не просто к количественным изменениям, а к качественному скачку сложности. То, что тривиально для одной машины, становится огромной проблемой для сети из тысяч узлов.

1. Конкурентность (concurrency)

Процессы, выполняющиеся одновременно, создают уникальные проблемы безопасности, которых нет в последовательных системах.

• Использование устаревших данных vs. распространение состояния: в распределённых системах данные реплицируются. Возникает дилемма: использовать локальную копию (риск использования устаревших данных, replay‑атаки) или ждать обновления от центра (задержки, нагрузка на сеть). Пример: списки горячих кредитных карт. Если проверять каждый чек онлайн — медленно; если хранить список локально — он быстро устаревает.
• Блокировки (locking): для предотвращения несогласованных обновлений используются блокировки. Но это создаёт новые векторы атак, например, deadlock (взаимоблокировка), когда два процесса ждут друг друга.
• Порядок обновлений: в распределённой среде нет глобальных часов. Порядок транзакций может быть разным на разных узлах. Это критично для финансовых систем (дебет перед кредитом или наоборот?).
• Неконвергентное состояние: данные на разных узлах могут никогда не сойтись к единому значению из‑за задержек или потерь пакетов.
• Безопасное время (secure time): многие протоколы (например, Kerberos) зависят от синхронизации времени. Атака на часы (сдвиг времени вперёд или назад) может сделать недействительными билеты или ключи. Протоколы синхронизации сами должны быть защищены от подмены.

Проблема «Время проверки — Время использования» (TOCTTOU)

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

• Механизм: программа проверяет, имеет ли пользователь право на запись в файл A. Если да, она открывает файл A для записи. Злоумышленник в этот микроскопический промежуток времени заменяет файл A символической ссылкой (symlink) на критический системный файл (например, /etc/passwd). В результате программа с привилегиями записывает данные в системный файл.
• Защита: использование атомарных операций ядра (например, открытие файла по файловому дескриптору, полученному сразу при создании, использование флагов O_EXCL), минимизация времени между проверкой и использованием, или использование механизмов транзакций.

Проблема порядка обновлений (order of updates)

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

• Финансовый пример: если на счёт поступают кредит 500000 и дебет 400000, порядок их применения критичен. Если сначала применить дебет, счёт может уйти в минус (овердрафт), что вызовет штрафы или блокировку, даже если в итоге баланс положительный.
• Решения:
  -- Пакетная обработка (batching): транзакции накапливаются и применяются в строго определённом порядке overnight. Это создаёт задержки, но гарантирует согласованность.
  -- Расчёт в реальном времени (real‑time gross settlement): транзакции обрабатываются по мере поступления. Здесь возникает риск зависимости от сетевых задержек и возможности манипуляций через создание искусственных задержек (DoS).
  -- Тентативные обновления (tentative updates): система предлагает временное состояние, которое становится окончательным только после подтверждения консенсуса. Это требует сложных механизмов отката (rollback) при сбоях.

Безопасное время (secure time)

Многие протоколы безопасности (Kerberos, SSL/TLS с сертификатами) критически зависят от синхронизации времени.

• Атака «Золушка» (Cinderella attack): злоумышленник переводит часы жертвы вперёд или назад.
  -- Вперёд: сертификаты или билеты (tickets) могут истечь преждевременно, вызывая отказ в обслуживании (DoS). Или, наоборот, можно использовать уже истекшие ключи, если система не проверяет их актуальность относительно надёжного источника.
  -- Назад: позволяет replay‑атаки (повторное воспроизведение старых сообщений), так как система считает их ещё действительными.
• Защита: использование протоколов синхронизации времени (NTP) с криптографической аутентификацией, использование логических часов Лэмпорта (Lamport timestamps) там, где абсолютное время не требуется, или включение nonce (случайных чисел) в каждое сообщение для гарантии свежести (freshness).

2. Отказоустойчивость и восстановление (fault tolerance and failure recovery)

Безопасность тесно переплетена с надёжностью. Злоумышленник может действовать как случайный сбой, но с конкретной целью.

Модели отказов

• Обычные отказы: компонент перестаёт отвечать (fail‑stop).
• Византийские отказы (Byzantine failure): компонент ведёт себя произвольным, возможно злонамеренным образом (посылает противоречивые сообщения разным узлам). Задача консенсуса в таких условиях решается только если число честных узлов n≥3t+1, где t — число предателей. Цифровые подписи упрощают эту задачу (требование смягчается до n = 2t + 1).

Византийские отказы (Byzantine failure)

• Обычный отказ (fail‑stop): компонент просто перестаёт отвечать. Решается избыточностью (репликацией): если один сервер упал, другой подхватывает нагрузку.
• Византийский отказ: компонент ведёт себя произвольным, возможно злонамеренным образом. Он может посылать противоречивые сообщения разным узлам (одному сказать «атакуй», другому — «отступай»), чтобы разрушить консенсус.
• Теорема: для достижения консенсуса при наличии t византийских узлов в системе должно быть не менее n = 3t + 1 узлов.
• Роль цифровых подписей: если сообщения подписаны криптографически, требование смягчается до n = 2t + 1, так как подпись предотвращает подмену сообщений и доказывает авторство. Однако это требует эффективного управления ключами.

Взаимодействие с безопасностью

• Избыточность vs. конфиденциальность: репликация данных для надёжности повышает риск утечки. Если данные размножены на 5 серверов, злоумышленнику достаточно взломать один из них, чтобы получить доступ.
• Уничтожение данных: если требуется гарантированное уничтожение данных (по запросу пользователя или суда), наличие множества реплик делает эту задачу крайне сложной («проблема стирания»).

Атаки типа «Отказ в обслуживании» (DoS / DDoS)

Распределённые системы уязвимы для атак, исчерпывающих ресурсы.

• Экономический аспект: защита от DoS часто требует избыточной пропускной способности, что дорого. Злоумышленник может использовать ботнеты (сети заражённых компьютеров) для создания трафика, стоимость генерации которого для него ничтожна, а стоимость фильтрации для жертвы огромна.
• Стратегии защиты:
  -- Фильтрация на периметре: использование специализированных сервисов (как Akamai) для поглощения удара.
  -- Proof‑of‑Work: требование от клиента решить вычислительную задачу перед обработкой запроса (как в Bitcoin или анти‑spam системах), чтобы сделать атаку дорогой.
  -- Анонимность vs. подотчётность: анонимные сети облегчают организацию DDoS, так как сложно отследить источник.

3. Именование (naming)

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

Принципы именования (по Нидэму)

1. Имена подразумевают обязательства: привязка имени к объекту должна быть устойчивой. Если имя меняется (например, при смене провайдера IP‑адреса), все сертификаты и ссылки ломаются.
2. Глобальные имена — иллюзия: уникальный ID (как IPv6) не решает проблему доверия. Локальное имя всё равно должно быть разрешено в глобальное и обратно. Промежуточные службы именования сами становятся точками отказа и атаки.
3. Имена как билеты доступа: часто имя используется как пароль или capability. Если имя легко угадать или подобрать (как MAC‑адреса или некоторые серийные номера), система уязвима.

Культурные и социальные аспекты

• Несоответствие моделей: западные модели именования (Имя Фамилия) не работают в других культурах (например, в Исландии нет фамилий, только патронимы; в некоторых культурах имена меняются при замужестве). Жёсткие системы валидации имен ломаются при масштабировании на глобальный уровень.
• Проблема «Снежного кома» (snowball search) в анализе трафика: даже если содержимое коммуникаций зашифровано, анализ метаданных (кто с кем связывается) позволяет восстанавливать социальные сети. Полицейские и спецслужбы используют этот метод: начиная с подозреваемого, они смотрят всех его контактов, затем контакты контактов, выявляя скрытые сообщества. Это показывает, что анонимность в распределённых системах крайне хрупка.

Уникальность и стабильность

• Коллизии: обеспечение глобальной уникальности сложно. Коллизии IP‑адресов, DNS‑спуфинг (подмена записей DNS) позволяют перенаправлять трафик на фишинговые сайты.
• Стабильность: адреса меняются. Сертификаты, привязанные к доменным именам или IP, становятся невалидными при миграции сервисов. Это создаёт окно уязвимости или требует сложных процедур перевыпуска ключей.

4. Практические уроки и кейсы

• Каскадная проблема (cascade problem): соединение двух безопасных систем может создать небезопасную. Например, если система уровня «Secret» соединена с системой «Unclassified» через шлюз, а та, в свою очередь, соединена с другой системой «Secret», информация может просочиться по цепочке, нарушая политику изоляции.
• Проблема доверия к компонентам: в распределённой системе вы вынуждены доверять множеству узлов. Если хотя бы один из них скомпрометирован (инсайдер или взлом), безопасность всей цепи может рухнуть. Принцип наименьших привилегий (least privilege) здесь реализовать сложнее всего.
• Человеческий фактор в администрировании: сложность настройки распределённых систем (например, правил фаерволов или политик доступа в LDAP/Active Directory) приводит к ошибкам конфигурации, которые являются основной причиной утечек. Администраторы часто дают слишком широкие права «на всякий случай» или забывают отозвать права уволенных сотрудников.

Главный вывод

Безопасность распределённых систем — это не сумма безопасностей отдельных узлов. Это управление состоянием, временем, доверием и идентичностью в хаотичной среде.

• Компромисс CAP: невозможно одновременно обеспечить полную согласованность (Consistency), доступность (Availability) и устойчивость к разделению (Partition tolerance). При атаках или сбоях приходится жертвовать либо доступностью (система ложится), либо согласованностью (разные пользователи видят разные данные).
• Необходимость глубокой защиты (defense in depth): поскольку любой отдельный механизм (криптография, фаерволы, контроль доступа) может быть обойдён, необходима многоуровневая защита, включающая мониторинг, аудит и быстрые процедуры реагирования.
• Важность простоты: чем сложнее протокол взаимодействия и схема именования, тем выше вероятность ошибки в реализации или конфигурации. Простые, понятные модели часто оказываются безопаснее сложных «умных» систем.