Криптографические системы и сервисы: целостность, аутентичность, конфиденциальность и открытые ключи

Модель угроз и криптографические сервисы

Зачем начинать с модели угроз

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

Модель угроз описывает:

что именно мы защищаем

от кого защищаем

какими возможностями обладает нарушитель

какие допущения считаем верными

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

> The security of a cryptosystem should not depend on keeping the encryption algorithm secret; it should depend only on keeping the key secret. — формулировка принципа Керкгофса в инженерной традиции > > Источник: Kerckhoffs's principle

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

Что такое криптографические сервисы

Криптографический сервис — это свойство безопасности, которое система предоставляет с помощью криптографических механизмов.

В рамках курса ключевые сервисы такие:

Конфиденциальность — скрыть содержимое данных от посторонних.

Целостность — обнаружить несанкционированное изменение данных.

Аутентичность — подтвердить, что данные пришли от ожидаемого отправителя.

Неотказуемость — возможность доказать третьей стороне факт создания/подписания сообщения конкретным субъектом.

Важно различать близкие термины:

Целостность отвечает на вопрос: данные изменились?

Аутентичность отвечает на вопрос: кто их создал/отправил?

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

Базовые элементы модели угроз

Хорошая модель угроз обычно включает четыре части.

Активы

Активы — то, что имеет ценность и требует защиты.

Примеры активов в криптосистемах:

содержимое сообщений и файлов

ключи шифрования и подписи

пароли и токены доступа

метаданные (кто с кем общается, когда и как часто)

журнал аудита и доказательства действий

Субъекты и границы доверия

Нужно явно описать участников и места, где доверие меняется.

Типичные субъекты:

пользователь

клиентское приложение

сервер

удостоверяющий центр (в системах открытых ключей)

внешние сервисы

Граница доверия — точка, где данные переходят из более доверенной области в менее доверенную (например, из процесса приложения в сеть). Именно на границах доверия чаще всего возникают атаки.

!Схема показывает, что сеть считается недоверенной, а атакующий может как читать трафик, так и активно вмешиваться.

Нарушитель и его возможности

Модель нарушителя отвечает на вопрос: что именно может делать атакующий?

Удобное разделение:

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

Активный нарушитель — может изменять, удалять, вставлять и повторно отправлять сообщения.

Также важно уточнять дополнительные возможности:

доступ к устройству пользователя (временный или постоянный)

компрометация сервера или базы данных

кража резервных копий

возможность заставлять систему подписывать или расшифровывать выбранные данные (часто это модель для протокольных атак)

частичная компрометация (утечка части ключевого материала, ошибок генератора случайных чисел)

Допущения и ограничения

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

Примеры допущений:

алгоритмы и их реализации корректны (или перечислены исключения)

ключи хранятся в защищенном хранилище (или нет, и это часть риска)

есть надежный источник случайности для генерации ключей

некоторые каналы/компоненты доверены (например, обновления ПО подписаны и проверяются)

Неправильные допущения ломают любую криптографию. Типичный пример: сильное шифрование при слабом управлении ключами.

Типовые угрозы, которые должна покрывать криптография

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

Прослушивание — чтение содержимого или метаданных.

Подмена — отправка сообщения от имени другого субъекта.

Модификация — незаметное изменение данных.

Повтор (replay) — повторная отправка ранее перехваченного корректного сообщения.

Понижение версии (downgrade) — принуждение к более слабым алгоритмам/параметрам.

Компрометация ключа — утечка ключевого материала.

Криптография не решает все:

Доступность (защита от DDoS) в основном достигается архитектурой и инфраструктурой, хотя криптография может участвовать (например, в защите от некоторых типов спуфинга).

Социальная инженерия обходится без взлома алгоритмов.

Соответствие: угроза → сервис → механизм

Один и тот же сервис может реализовываться разными механизмами, и выбор зависит от модели угроз.

| Угроза | Какой сервис нужен | Примеры механизмов | |---|---|---| | Прослушивание | Конфиденциальность | Симметричное шифрование, асимметричное шифрование, гибридные схемы | | Модификация | Целостность | MAC, цифровая подпись, AEAD | | Подмена отправителя | Аутентичность | MAC (при общем секрете), цифровая подпись (при открытых ключах) | | Повтор (replay) | Аутентичность + свежесть | Нонсы, счетчики, метки времени, привязка к сессии | | Отрицание факта отправки | Неотказуемость | Цифровая подпись + корректная проверка и хранение доказательств | | Компрометация ключа | Минимизация ущерба | Ротация ключей, разделение ключей по назначению, прямой секрет (forward secrecy) |

Пояснения к терминам из таблицы:

MAC (Message Authentication Code) — код аутентификации сообщения: значение, вычисляемое по сообщению и секретному ключу. Проверка MAC подтверждает, что сообщение пришло от обладателя ключа и не было изменено.

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

AEAD (Authenticated Encryption with Associated Data) — режимы и схемы, которые одновременно дают конфиденциальность и целостность (а значит, и аутентичность в рамках ключа) для зашифрованных данных, а также позволяют аутентифицировать незашифрованные поля (например, заголовки).

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

Почему одного шифрования недостаточно

Шифрование защищает от чтения, но не обязательно защищает от вмешательства.

Если система использует только шифрование без проверки целостности, возможны ситуации:

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

атакующий добивается различимого поведения системы на некорректных данных, извлекая информацию (в некоторых протоколах)

Поэтому в инженерной практике для обмена по недоверенной сети обычно требуется либо:

схема вида шифрование + аутентификация (например, AEAD), либо

отдельная проверка целостности и аутентичности, корректно скомпонованная с шифрованием (это нетривиально и будет разбираться далее в курсе)

Как строить модель угроз на практике

Ниже базовый процесс, который подходит для большинства прикладных задач.

Описать сценарий и поток данных: кто с кем общается, какие данные передаются и где хранятся.

Перечислить активы: что нельзя раскрыть, изменить или подделать.

Определить границы доверия: где данные выходят в недоверенную среду.

Определить нарушителя: пассивный или активный, локальный или удаленный, есть ли доступ к устройствам.

Сопоставить угрозы сервисам: конфиденциальность, целостность, аутентичность, неотказуемость.

Выбрать механизмы: шифрование, MAC, подпись, управление ключами, защита от replay.

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

Для ориентиров и терминологии полезны следующие источники:

RFC 3552: Guidelines for Writing RFC Text on Security Considerations

NIST SP 800-30 Revision 1: Guide for Conducting Risk Assessments

NISTIR 7298 Revision 3: Glossary of Key Information Security Terms

Итоги

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

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

Криптографические примитивы: хэши, MAC, шифрование

В предыдущей статье мы связали угрозы (прослушивание, модификация, подмена, replay) с криптографическими сервисами (конфиденциальность, целостность, аутентичность). Теперь разберем базовые примитивы — строительные блоки, из которых собирают механизмы и протоколы.

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

!Схема показывает входы/выходы примитивов и какие свойства безопасности они дают

Что такое криптографический примитив

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

Важно различать:

Примитив (например, SHA-256, AES)

Схему/режим использования примитива (например, HMAC-SHA-256, AES-GCM)

Протокол (например, TLS), который комбинирует несколько схем вместе

Хэш-функции

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

Примеры стандартов:

SHA-256 и SHA-512 определены в FIPS 180-4: Secure Hash Standard

Зачем нужны хэши

Хэш-функции используют в задачах, где нужно компактное представление данных:

идентификатор содержимого (например, отпечаток файла)

контроль неизменности при условии, что ожидаемый хэш получен из доверенного источника

часть конструкций для аутентификации и подписи (например, HMAC или подпись хэша сообщения)

Критично: сам по себе хэш не дает аутентичности. Если атакующий может подменить и сообщение, и хэш рядом с ним, то проверка хэша ничего не гарантирует.

Основные свойства безопасности хэшей

Для криптографических хэшей обычно требуют три свойства.

Стойкость к нахождению прообраза (preimage resistance)

Дано значение хэша . Должно быть вычислительно трудно найти сообщение , такое что .

Обозначения:

- — хэш-функция - — сообщение - — хэш (дайджест)

Стойкость ко второму прообразу (second preimage resistance)

Дано конкретное сообщение . Должно быть трудно найти другое сообщение , такое что .

Стойкость к коллизиям (collision resistance)

Должно быть трудно найти любую пару разных сообщений с одинаковым хэшем: .

Интуитивное различие:

прообраз — «попасть в заданный хэш»

второй прообраз — «подобрать под конкретное сообщение другое с тем же хэшем»

коллизия — «найти любые два разных сообщения с одинаковым хэшем»

Частая ошибка: “хэш = целостность”

Хэш помогает обнаружить изменение только если:

у проверяющей стороны есть доверенный эталонный хэш, или

хэш защищен механизмом аутентичности (например, MAC или цифровой подписью)

В недоверенной сети «сообщение + SHA-256(сообщение)» не защищает от активного нарушителя, потому что он пересчитает хэш после подмены.

MAC: код аутентификации сообщения

MAC (Message Authentication Code) — это короткое значение тег, вычисляемое по сообщению и секретному ключу.

отправитель вычисляет тег

получатель, имея тот же секретный ключ , проверяет тег

MAC обычно дает сразу два сервиса в рамках модели «общий секрет»:

целостность — изменения сообщения обнаруживаются

аутентичность — сообщение мог сформировать только тот, у кого есть ключ

Хорошая отправная точка: RFC 2104: HMAC.

Почему MAC — это не “просто хэш с ключом”

Некорректные конструкции вида H(K || m) или H(m || K) часто приводят к уязвимостям из-за особенностей конкретных хэшей.

Например, для семейства хэшей на основе конструкции Меркла—Дамгарда (исторически так устроены MD5, SHA-1, SHA-256) существует класс атак, известный как length extension, который может ломать некоторые “самодельные” схемы аутентификации.

Поэтому на практике используют стандартизованные конструкции:

HMAC (на базе хэша)

CMAC (на базе блочного шифра)

Poly1305 (как часть связки ChaCha20-Poly1305)

Ограничения MAC

MAC работает, когда у сторон есть общий секрет . Отсюда следуют ограничения:

если ключ известен нескольким участникам, то они все могут создавать корректные теги; доказать третьей стороне, кто именно создал сообщение, обычно нельзя

если ключ утек, атакующий сможет и читать/менять трафик (в зависимости от протокола), и создавать валидные теги

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

Шифрование

Шифрование обеспечивает конфиденциальность: данные становятся недоступны для чтения без ключа.

Симметричное и асимметричное шифрование

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

Симметричное шифрование: один секретный ключ для шифрования и расшифрования

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

Блочные шифры и режимы работы

Популярный блочный шифр — AES (стандарт FIPS 197: Advanced Encryption Standard).

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

Режимы стандартизованы, например, в NIST SP 800-38A: Block Cipher Modes of Operation.

Ключевые инженерные выводы:

нельзя «просто применить AES к каждому блоку одинаково» — это приводит к утечкам структуры

почти всегда нужен IV/nonce (вектор инициализации или одноразовое значение), чтобы одинаковые сообщения не давали одинаковый результат

Потоковое шифрование и nonce

Многие современные схемы шифрования устроены так, что генерируют псевдослучайный поток и комбинируют его с данными. Для таких схем критично правило:

nonce должен быть уникальным для данного ключа

Если нарушить уникальность nonce (например, повторить nonce с тем же ключом), можно потерять конфиденциальность, а иногда и возможность подделывать сообщения.

Почему “шифрование” не равно “безопасность”

Шифрование отвечает на вопрос «кто может прочитать?», но само по себе не отвечает на вопрос «изменили ли данные?».

Если атакующий активен, то без защиты целостности возможны:

незаметная модификация зашифрованных данных (получатель расшифрует “мусор” или опасно искаженные значения)

атаки по “оракулу” ошибок, когда различимое поведение системы на некорректном шифртексте постепенно раскрывает информацию

Поэтому в современных протоколах шифрование почти всегда идет вместе с аутентификацией.

AEAD: шифрование с аутентификацией

AEAD (Authenticated Encryption with Associated Data) — класс схем, которые одновременно обеспечивают:

конфиденциальность зашифрованных данных

целостность и аутентичность (тег аутентификации)

возможность аутентифицировать дополнительные данные без шифрования (Associated Data), например заголовки

Два наиболее распространенных варианта:

AES-GCM: NIST SP 800-38D: Galois/Counter Mode

ChaCha20-Poly1305: RFC 8439: ChaCha20 and Poly1305 for IETF Protocols

Что важно помнить про AEAD

Нужен ключ и обычно нужен nonce .

Nonce почти всегда должен быть уникальным для одного ключа.

На выходе получается:

- шифртекст - тег аутентификации

Если тег не проверяется или ошибки обработки “текут наружу” необычными способами, безопасность схемы может разрушиться на уровне протокола.

Как выбирать примитив под сервис из модели угроз

Свяжем примитивы с сервисами из предыдущей статьи.

| Примитив/схема | Конфиденциальность | Целостность | Аутентичность | Типичная область применения | |---|---|---|---|---| | Хэш | нет | частично, только при доверенном эталоне | нет | отпечатки файлов, дедупликация, часть подписи | | MAC (например, HMAC) | нет | да | да (в рамках общего ключа) | API-запросы, внутренние протоколы, защищенные каналы | | Шифрование без аутентификации | да | нет | нет | ограниченные случаи, обычно не рекомендуется | | AEAD (например, AES-GCM) | да | да | да (в рамках ключа) | сетевые протоколы, защищенные хранилища |

Итоги

Хэш — это компактный отпечаток данных; он полезен для контроля неизменности только при наличии доверенного способа сравнения или если хэш защищен (MAC/подписью).

MAC дает целостность и аутентичность, но требует общего секрета и обычно не дает неотказуемости.

Шифрование дает конфиденциальность, но без аутентификации не защищает от активного вмешательства.

AEAD — практический стандарт для “шифровать по сети”: конфиденциальность плюс проверяемая целостность и аутентичность.

Базовая целостность и аутентичность: MAC и подписи

В первых статьях курса мы:

зафиксировали, что в недоверенной сети нарушитель может быть активным (не только читать, но и менять сообщения)

разобрали примитивы (хэши, MAC, шифрование) и увидели, что одно лишь шифрование не гарантирует целостность

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

Что именно мы хотим получить от механизма целостности

В модели угроз (из первой статьи) для активного нарушителя нам обычно нужны свойства:

Целостность: получатель должен обнаружить любое изменение сообщения.

Аутентичность: получатель должен убедиться, что сообщение сформировал ожидаемый субъект.

Свежесть: защита от replay (повторной отправки старого корректного сообщения) часто идет рядом с аутентичностью.

Важно: целостность и аутентичность почти всегда проверяются на уровне конкретного сообщения. Поэтому механизм должен быть привязан к точному набору байт, которые считаются «тем самым сообщением».

MAC: аутентичность при общем секрете

Идея MAC

MAC (Message Authentication Code) — это значение (часто говорят тег), которое вычисляется по сообщению и секретному ключу, известному обеим сторонам.

В виде абстрактной схемы это выглядит так:

вычисление тега:

проверка:

Пояснение обозначений:

— сообщение (байты, которые вы хотите защитить)

— общий секретный ключ MAC

— тег (короткое значение, отправляемое вместе с сообщением)

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

Что дает MAC

MAC обычно дает два сервиса сразу (в модели «общий секрет»):

целостность (модификации обнаруживаются)

аутентичность (тег мог вычислить только обладатель ключа)

Но есть важное ограничение: если один и тот же ключ знают несколько субъектов, то любой из них может сгенерировать корректный тег, и доказать третьей стороне «кто именно подписал» невозможно. Поэтому MAC обычно не дает неотказуемость.

Стандартные конструкции MAC

На практике почти всегда используются стандартизованные MAC:

HMAC (на базе хэш-функции), стандарт: RFC 2104: HMAC

CMAC (на базе блочного шифра), стандарт: NIST SP 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication

Связь с предыдущей статьей: HMAC использует хэш как примитив, но превращает его в конструкцию, устойчивую к типовым проблемам «самодельных» схем.

Что обязательно продумать при использовании MAC

#### Защита от replay

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

Типовые решения:

добавлять в счетчик (монотонный sequence number)

добавлять nonce (одноразовое значение) и хранить «уже использованные» на стороне сервера

использовать метки времени и окна допустимого времени (если можно доверять времени и есть допуски)

Главное правило: элемент свежести должен входить в защищаемое сообщение , то есть быть покрыт MAC.

#### Разделение ключей по назначению

Частая инженерная практика:

разные ключи для разных направлений (клиент → сервер и сервер → клиент)

разные ключи для разных типов сообщений

Это уменьшает радиус поражения при ошибках протокола и упрощает анализ.

#### Сравнение тегов без утечек

Проверка тега должна быть реализована как сравнение с постоянным временем выполнения (constant-time compare), иначе возможны атаки по времени, особенно в сетевых сервисах.

Цифровые подписи: аутентичность без общего секрета

Идея цифровой подписи

Цифровая подпись использует пару ключей:

закрытый ключ хранится у подписанта

открытый ключ распространяется всем проверяющим

Абстрактно:

подпись:

проверка:

Пояснение обозначений:

— сообщение

— закрытый ключ (секрет подписанта)

— открытый ключ (публичный)

— подпись

Если проверка проходит, это означает: «подпись мог создать тот, у кого был соответствующий закрытый ключ».

Что дают подписи

Цифровая подпись обычно обеспечивает:

целостность подписанного сообщения

аутентичность относительно владельца закрытого ключа

часто — основу для неотказуемости, но только при корректной инфраструктуре (идентификация владельца ключа, политика хранения ключей, аудит, метки времени и т.д.)

Важно: подпись сама по себе не решает проблему «кому принадлежит открытый ключ». Это уже область инфраструктуры открытых ключей (сертификаты, доверие, привязка ключа к имени), к которой курс подойдет в следующих темах.

Алгоритмы и стандарты

Распространенные варианты:

RSA-PSS и ECDSA: стандарт FIPS 186-5: Digital Signature Standard (DSS)

Ed25519: стандарт RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)

Практическая деталь: многие схемы подписи устроены как «подпиши хэш сообщения», поэтому для больших сообщений обычно сначала считают хэш, а затем подписывают результат.

Подпись и replay

Подпись, как и MAC, не делает сообщение свежим автоматически. Если злоумышленник перехватил подписанное сообщение, он может повторить его позднее.

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

MAC и подписи: ключевые различия

!Сравнение моделей доверия для MAC и цифровой подписи

Сравнение в инженерных терминах:

| Критерий | MAC | Цифровая подпись | |---|---|---| | Ключи | один общий секрет у сторон | пара (секрет) и (публичный) | | Кто может проверять | только тот, у кого есть | любой, у кого есть | | Кто может создавать | любой, у кого есть | только владелец | | Неотказуемость | обычно нет | возможно, но зависит от инфраструктуры | | Производительность | обычно быстрее | обычно дороже по CPU | | Типичный сценарий | внутренние сервисы, API, протоколы с общим секретом | обновления ПО, документы, распределенные системы, где проверяющих много |

Простое правило выбора:

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

если проверяющих много, нужен публичный аудит или нет общего секрета, обычно нужны подписи

Композиция с конфиденциальностью: где место MAC и подписи

Из предыдущей статьи: шифрование без аутентификации не гарантирует целостность. Поэтому при активном нарушителе безопасные варианты обычно такие:

AEAD (например, AES-GCM или ChaCha20-Poly1305): единая схема «шифрование + аутентификация»

либо комбинация шифрования и MAC, но с правильным порядком

Распространенная рекомендация в протоколах: Encrypt-then-MAC — сначала шифровать, затем считать MAC по шифртексту (и по нужным незашифрованным полям, если они должны быть защищены). Это снижает риск классов атак, связанных с обработкой некорректного шифртекста.

На практике чаще всего выбирают AEAD, потому что:

меньше шансов ошибиться в композиции

проще интерфейс использования

Частые ошибки и как их избежать

Ошибка: «SHA-256 от сообщения рядом положим — будет целостность»

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

Правильный подход:

либо MAC (если есть общий секрет)

либо цифровая подпись (если нужна публичная проверка)

Ошибка: не аутентифицировать контекст

Если MAC/подпись считается только по «данным», но не покрывает важные поля (например, user_id, amount, currency, destination, версию протокола), атакующий может переставлять поля, менять смысл или переносить тег между сообщениями.

Практика: включать в защищаемую строку/структуру все поля, которые определяют смысл операции, плюс явный контекст (например, строку "payment_v1").

Ошибка: подпись или MAC без защиты от replay

Если операция опасна при повторе (платеж, смена пароля, выдача токена), нужно встроить свежесть:

счетчик

nonce

срок действия

И все это должно входить в подписываемые/аутентифицируемые данные.

Ошибка: один ключ «на все»

Один и тот же ключ для разных задач усложняет анализ и увеличивает последствия утечки.

Практика: разделять ключи по назначению и по направлению, а для протоколов использовать KDF и отдельные ключи для шифрования и аутентификации.

Два минимальных инженерных шаблона

Запрос к API с HMAC

Идея: клиент и сервер разделяют секрет K. Клиент отправляет:

параметры запроса

timestamp или nonce

тег t = HMAC(K, canonical_request)

Сервер:

проверяет свежесть timestamp/nonce

проверяет HMAC

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

Подписанное обновление ПО

Идея: производитель хранит sk в защищенной среде, клиенты вшивают или доверяют pk.

производитель публикует файл и подпись

клиент скачивает и проверяет подпись по pk

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

Итоги

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

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

И MAC, и подписи требуют проектирования свежести (защита от replay) и строгой привязки к контексту протокола.

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

Конфиденциальность: симметричное шифрование и режимы

В предыдущих статьях курса мы связали угрозы с криптографическими сервисами и разобрали примитивы: хэши, MAC и шифрование. Мы также зафиксировали важное ограничение: одно лишь шифрование не гарантирует целостность и аутентичность.

Эта статья углубляет именно сервис конфиденциальности: как в реальных системах применяется симметричное шифрование, что такое блочные шифры и режимы работы, зачем нужны IV/nonce, и какие инженерные ошибки чаще всего приводят к утечкам.

Что такое конфиденциальность в модели угроз

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

Практически это отвечает на вопрос: кто может прочитать данные?

При этом важно помнить вывод из прошлых тем:

шифрование отвечает за чтение, но не за подмену

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

Симметричное шифрование: базовая модель

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

шифрование:

расшифрование:

Обозначения:

— открытый текст (исходные данные)

— шифртекст (результат шифрования)

— секретный ключ

— алгоритм шифрования

— алгоритм расшифрования

Смысл формул простой: применяя шифрование с ключом , мы получаем шифртекст , а применяя расшифрование с тем же ключом — возвращаемся к исходному .

Почему нужны режимы: блочный шифр шифрует только блок

На практике один из самых распространенных примитивов — AES (стандарт FIPS 197: Advanced Encryption Standard). AES — это блочный шифр.

Свойство блочного шифра:

он принимает на вход блок фиксированного размера (для AES это 128 бит)

и на выходе выдает блок того же размера

Проблема инженерная: реальные сообщения имеют произвольную длину (байты, строки, файлы, пакеты). Поэтому блочный шифр почти всегда используют не “как есть”, а в составе режима работы.

Режимы работы блочных шифров систематизированы в рекомендациях NIST SP 800-38A: Block Cipher Modes of Operation.

!Иллюстрация, почему AES требует режима работы и IV/nonce для шифрования сообщений произвольной длины

IV и nonce: что это и зачем

Почти все безопасные режимы используют дополнительное значение, которое отправляется вместе с шифртекстом:

IV (Initialization Vector, вектор инициализации)

nonce (number used once, число, используемое один раз)

Они похожи по роли (вводят “разнообразие” в шифрование), но есть типичное инженерное различие:

IV часто должен быть непредсказуемым (или, как минимум, случайным) — это зависит от режима

nonce почти всегда должен быть уникальным для данного ключа (никогда не повторяться)

Ключевая практическая цель одна: одинаковый открытый текст не должен превращаться в одинаковый шифртекст при одном и том же ключе.

Важно:

IV/nonce обычно не является секретом

но требования к уникальности или случайности критичны; нарушение часто ломает конфиденциальность

Режим ECB: пример того, как делать нельзя

ECB (Electronic Codebook) — исторический режим, который часто приводят как антипример.

Суть ECB:

каждый блок шифруется независимо одним и тем же ключом

Проблема:

одинаковые блоки открытого текста дают одинаковые блоки шифртекста

структура данных “просвечивает”

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

Инженерное правило: не использовать ECB для данных длиннее одного блока, а на практике — не использовать почти никогда.

CBC: классический режим, который требует аккуратности

CBC (Cipher Block Chaining) связывает блоки: каждый следующий блок зависит от предыдущего шифртекста.

Что важно для конфиденциальности:

CBC требует случайный (непредсказуемый) IV для первого блока

CBC требует padding (дополнение), если длина сообщения не кратна размеру блока

CBC долго был стандартом “по умолчанию”, но сегодня в сетевых протоколах и прикладных системах его вытеснили более современные подходы (обычно AEAD), потому что CBC сложнее безопасно “обвязать”.

Практическая причина сложности:

ошибки в обработке padding и различимое поведение при ошибках могут приводить к утечкам (класс атак padding oracle)

Вывод для дизайна систем:

если вы вынуждены использовать CBC, нужно крайне дисциплинированно проектировать обработку ошибок и добавлять надежную аутентификацию

для новых протоколов обычно выбирают AEAD вместо “CBC + что-то вокруг”

CTR: превращаем блочный шифр в потоковый (и получаем риск повторов)

CTR (Counter mode) использует AES для генерации псевдослучайного потока, который затем комбинируется с открытым текстом.

Интуитивная модель:

строится последовательность блоков “счетчика”

каждый блок счетчика шифруется AES

результат используется как “ключевой поток”

Критическое правило:

nonce (и счетчик как его продолжение) должен быть уникальным для каждого сообщения при одном ключе

Если nonce повторить:

повторится ключевой поток

атакующий сможет сопоставлять шифртексты и извлекать информацию о сообщениях

CTR удобен тем, что:

не требует padding

хорошо параллелится

Но он не дает целостности: атакующий может модифицировать шифртекст так, что предсказуемо изменится открытый текст после расшифрования. Поэтому CTR почти всегда используют либо внутри AEAD-конструкций, либо в сочетании с MAC по правильной схеме.

Потоковые шифры и правило уникальности nonce

Кроме режимов блочных шифров, есть потоковые шифры как отдельный класс. Один из самых известных современных вариантов — ChaCha20, применяемый в связке ChaCha20-Poly1305 (стандарт RFC 8439: ChaCha20 and Poly1305 for IETF Protocols).

Потоковые шифры почти всегда опираются на nonce, и для них действует то же базовое правило:

nonce не должен повторяться для одного ключа

Ошибка с повтором nonce — одна из самых разрушительных в прикладной криптографии, потому что часто приводит к мгновенной потере конфиденциальности.

Шифрование “данных на диске”: отдельный случай (XTS)

Для шифрования данных на носителях (диски, разделы, SSD) часто используют режим XTS.

Особенность задачи:

данные читаются и записываются блоками по адресам

важна устойчивость к ситуации, когда атакующий видит множество шифртекстов “похожей структуры”

XTS — это специализированный инструмент именно для storage encryption. Он не является универсальным режимом для сетевых протоколов.

Если ваша задача — защищать трафик или сообщения, то обычно правильнее выбирать AEAD.

Что значит “безопасное шифрование” на практике

В инженерной практике под “безопасным шифрованием” обычно подразумевается не просто “алгоритм не сломан”, а что:

схема правильно использует IV/nonce

ключи корректно генерируются и хранятся

ошибки протокола не превращают шифрование в “оракул”

Ниже — чек-лист, который покрывает самые частые провалы.

Типовые ошибки при использовании симметричного шифрования

Повтор nonce или IV там, где нужна уникальность

Опасный сценарий:

два разных сообщения шифруются одним ключом и одним nonce

Последствия:

утечки взаимосвязей между сообщениями

часто — возможность восстановить данные при наличии частичного знания открытого текста

Практика:

проектировать генерацию nonce как монотонный счетчик или как случайное значение с гарантией уникальности

хранить состояние (если требуется уникальность, а не просто случайность)

“Шифруем и все”: отсутствие аутентификации

Как мы уже обсуждали в предыдущих статьях:

шифрование без проверки целостности не защищает от активной подмены

Практика:

для сообщений по сети обычно использовать AEAD

если используется композиция “шифрование + MAC”, то важна правильная конструкция (часто рекомендуют Encrypt-then-MAC)

Неправильная обработка ошибок

Даже при правильных алгоритмах утечки происходят из-за различимого поведения:

разные сообщения об ошибке

разные коды ответа

различимое время выполнения

Особенно опасно:

детально сигнализировать ошибки расшифрования или padding (это может стать “оракулом”)

Слабые ключи, слабая случайность, повтор ключей

Ключи должны:

генерироваться криптографически стойким генератором случайных чисел

иметь достаточную длину (например, AES-128 или AES-256)

не переиспользоваться “на все случаи жизни” без разделения по назначению

Связь с темой модели угроз:

часто ломается не AES, а управление ключами (утечки, бэкапы, логирование, доступы)

Как выбирать подход в зависимости от сценария

Ниже — практическая карта выбора, привязанная к задачам.

| Сценарий | Что нужно | Что обычно выбирают | Почему | |---|---|---|---| | Защита трафика по сети при активном нарушителе | конфиденциальность + целостность | AEAD (например, AES-GCM или ChaCha20-Poly1305) | меньше шансов ошибиться, есть тег аутентификации | | Внутренний протокол с отдельной аутентификацией | конфиденциальность + отдельная целостность | шифрование + MAC (по правильной схеме) | иногда нужно разделение уровней | | Шифрование данных на диске | конфиденциальность в модели “украли носитель” | AES-XTS | режим адаптирован для storage | | Шифрование короткого значения фиксированного размера | конфиденциальность | специализированные конструкции или AEAD | часто важно не ошибиться с nonce/IV |

Про AES-GCM полезный первоисточник: NIST SP 800-38D: Galois/Counter Mode (GCM).

Итоги

Симметричное шифрование — основной инструмент конфиденциальности в прикладных системах.

Блочные шифры (например, AES) требуют режима работы, чтобы безопасно шифровать длинные сообщения.

IV/nonce нужны, чтобы одинаковые сообщения не давали одинаковый шифртекст; для многих схем nonce должен быть уникальным на ключ.

ECB почти всегда неприемлем из-за утечек структуры.

Режимы вроде CBC и CTR требуют дисциплины (IV/nonce, padding, обработка ошибок) и сами по себе не дают целостности.

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

Криптография открытых ключей: основы и алгоритмы

В предыдущих статьях курса мы разобрали криптографические сервисы (конфиденциальность, целостность, аутентичность), а также примитивы и механизмы, которые часто применяются при наличии общего секрета (MAC, симметричное шифрование, AEAD). Но в реальных системах очень часто возникает более сложная ситуация: участники не разделяют секрет заранее, а проверяющих может быть много.

Криптография открытых ключей решает именно эту проблему: позволяет организовать защищенное взаимодействие между сторонами без предварительного общего секрета и (в случае подписей) с публичной проверяемостью.

Какая задача решается и какая модель доверия меняется

В схемах с MAC обе стороны должны знать один и тот же секретный ключ. Это удобно, но плохо масштабируется: если проверяющих много или они не должны уметь «подписывать» сообщения, общий секрет становится неудобным и опасным.

Криптография открытых ключей (асимметричная криптография) вводит пару ключей:

закрытый ключ хранится в секрете у владельца

открытый ключ можно распространять

Запись пары ключей часто выглядит так: .

означает public key (открытый ключ)

означает secret key (закрытый ключ)

Главная инженерная идея: то, что можно сделать с использованием , обычно не позволяет «подделать» действие, которое требует .

!Диаграмма показывает два основных применения открытых ключей: подпись и получение общего секрета для симметрического шифрования

Базовые операции: подпись, шифрование, обмен ключами

Цифровая подпись

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

Абстрактно:

подпись:

проверка:

Пояснение символов:

это сообщение (конкретные байты, которые подписываются)

это подпись

это алгоритм подписи

это алгоритм проверки подписи

Связь с предыдущей темой про MAC:

MAC проверяют только те, кто знает общий секрет

подпись может проверить любой, у кого есть открытый ключ

Практический вывод: подписи удобны для обновлений ПО, документов, публичных журналов событий, а также для протоколов, где проверяющих много.

Стандарты и первоисточники:

FIPS 186-5: Digital Signature Standard (DSS)

RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)

Асимметричное шифрование

Асимметричное шифрование отвечает на вопрос конфиденциальности в модели «у отправителя есть открытый ключ получателя».

Абстрактно:

шифрование:

расшифрование:

Пояснение символов:

это шифртекст

это алгоритм шифрования

это алгоритм расшифрования

Важный инженерный момент: в большинстве современных протоколов асимметричное шифрование редко применяют для больших данных напрямую. Причины:

оно дороже по CPU, чем симметричное

у него больше «острых углов» на уровне корректного использования

Поэтому чаще используют гибридный подход (ниже).

Стандарт для RSA-шифрования и RSA-подписей:

RFC 8017: PKCS #1: RSA Cryptography Specifications Version 2.2

Обмен ключами (key agreement)

Третья ключевая задача открытых ключей: две стороны без общего секрета могут получить общий секрет, а потом перейти на симметрическую криптографию (AEAD), которая эффективна для трафика.

Самый известный класс схем для этого: Diffie-Hellman и его варианты на эллиптических кривых.

Практический смысл:

открытые ключи помогают «договориться о ключе»

дальше все шифруется симметрически, как мы обсуждали в теме про конфиденциальность и AEAD

Стандарты:

RFC 7748: Elliptic Curves for Security (X25519)

NIST SP 800-56A Rev. 3: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography

Гибридная криптография: как это выглядит в реальных системах

Почти всегда практичная схема выглядит так:

Стороны используют открытые ключи, чтобы аутентифицироваться и (или) получить общий секрет.

Из полученного секрета выводят симметрические ключи (обычно через KDF).

Дальше применяют AEAD (например, AES-GCM или ChaCha20-Poly1305) для защиты трафика.

Почему так делают:

симметрическая криптография быстрее

AEAD сразу дает конфиденциальность и проверяемую целостность

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

В современной терминологии часто встречаются две абстракции:

KEM (Key Encapsulation Mechanism) это механизм «упаковать ключ» для получателя

DEM (Data Encapsulation Mechanism) это симметрическое шифрование данных этим ключом

Даже если в протоколе не употребляют слова KEM/DEM, логика часто именно такая.

Что именно делает систему безопасной: «алгоритм» против «схемы применения»

Как и в предыдущих статьях (про MAC и режимы шифрования), важно различать:

алгоритм (например, RSA)

безопасную схему применения (например, RSA-OAEP для шифрования, RSA-PSS для подписи)

протокол, который комбинирует несколько алгоритмов и правил (например, TLS)

Пример инженерной ошибки: «используем RSA» без уточнения схемы. В реальности критичны детали заполнения (padding) и формата, потому что именно они предотвращают классы атак на «сырой RSA».

Основные семейства алгоритмов

RSA

RSA исторически очень распространен и поддерживается почти везде.

Где применяется:

цифровые подписи (на практике рекомендуют RSA-PSS)

шифрование/инкапсуляция ключей (на практике используют OAEP)

Что помнить инженеру:

не использовать «голый RSA» без схемы заполнения

использовать стандартизованные варианты из PKCS #1

Первичный стандарт:

RFC 8017: PKCS #1

Diffie-Hellman и ECDH

Diffie-Hellman позволяет двум сторонам получить общий секрет через недоверенную сеть.

Две основные реализации:

DH на конечных полях (классический вариант)

ECDH на эллиптических кривых (обычно короче ключи и быстрее для многих сценариев)

Практически часто встречается X25519 как стандартная ECDH-функция.

Стандарт:

RFC 7748: Elliptic Curves for Security

Важное предупреждение по модели угроз:

«чистый» DH/ECDH дает общий секрет, но не гарантирует, что вы договорились именно с тем, с кем хотели

для защиты от атаки посредника (man-in-the-middle) нужен механизм аутентификации (например, подписи, сертификаты или предварительно известный ключ)

Подписи на эллиптических кривых: ECDSA и Ed25519

Два очень распространенных подхода:

ECDSA широко стандартизован и используется в разных экосистемах

Ed25519 (семейство EdDSA) популярно в современных протоколах и библиотеках благодаря удобной и более «цельной» спецификации

Стандарты:

FIPS 186-5: Digital Signature Standard (DSS)

RFC 8032: EdDSA

Инженерная деталь, которая связывает тему подписей с темой про случайность:

в некоторых схемах подписи качество случайных чисел критично

ошибки генератора случайных чисел или повтор значений внутри подписи могут привести к компрометации закрытого ключа

Поэтому в практических системах важно:

использовать проверенные криптобиблиотеки

не писать реализацию подписи «самостоятельно»

обеспечивать надежный источник случайности

Чем открытые ключи отличаются от симметрической криптографии на практике

Стоимость и роль в протоколах

Симметрическая криптография:

быстрая

удобна для больших объемов данных

требует распределения общего секрета

Асимметрическая криптография:

медленнее

решает проблему распределения доверия и ключей

чаще используется для аутентификации и обмена ключами, а не для «шифровать весь трафик напрямую»

Кто кому что доказывает

Сопоставим MAC и подписи (в привязке к предыдущей статье про целостность и аутентичность).

| Вопрос | MAC | Цифровая подпись | |---|---|---| | Кто может проверить? | только обладатели общего секрета | любой с открытым ключом | | Кто может создать? | любой с общим секретом | только владелец закрытого ключа | | Можно ли доказать третьей стороне? | обычно нет | часто да, если ключ привязан к личности |

Эта таблица подводит нас к вопросу, который пока остается открытым: как доверять открытым ключам? Это уже тема инфраструктуры открытых ключей.

Главная нерешенная проблема: привязка открытого ключа к личности

Криптография открытых ключей дает инструменты, но не отвечает автоматически на вопрос:

«Этот открытый ключ действительно принадлежит серверу example.com?»

Если атакующий подменит открытый ключ на свой, он сможет:

выполнять атаку посредника

заставить пользователя проверять подписи «не тем ключом»

Практическое решение в интернете: PKI и сертификаты.

Минимальная идея сертификата:

удостоверяющий центр (CA) подписывает данные вида «вот этот открытый ключ принадлежит этому имени»

клиент проверяет подпись CA по заранее доверенному набору корневых ключей

Базовый стандарт для сертификатов X.509:

RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

В этом курсе мы выделяем PKI в отдельную тему на уровне протоколов и инфраструктуры, но важно уже сейчас видеть границу:

алгоритмы подписи и обмена ключами не дают доверия к идентичности сами по себе

Типовые ошибки при использовании криптографии открытых ключей

Ошибка: не аутентифицировать обмен ключами

Если вы используете DH/ECDH, но не проверяете, с кем именно происходит обмен, активный нарушитель может незаметно стать посредником.

Практика:

добавлять аутентификацию (подписи, сертификаты, заранее известные ключи)

использовать стандартные протоколы, где это уже сделано (например, TLS)

Ошибка: путать «подпись» и «шифрование»

Подпись не скрывает данные. Она подтверждает авторство и целостность.

Практика:

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

Ошибка: «используем RSA» без OAEP/PSS

Для RSA критично использовать правильные схемы:

RSA-PSS для подписи

RSA-OAEP для шифрования

Именно эти схемы проектируются для устойчивости к известным классам атак.

Стандартный источник:

RFC 8017: PKCS #1

Ошибка: считать открытый ключ «доказательством личности»

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

Практика:

использовать сертификаты и проверку цепочек доверия

или использовать закрепление ключей (pinning) в ограниченных сценариях

Итоги

Криптография открытых ключей вводит пару и решает проблему отсутствия общего секрета.

Основные применения: цифровые подписи (аутентичность и целостность), обмен ключами (получение общего секрета), реже асимметричное шифрование больших данных.

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

Критическая граница темы: алгоритмы сами по себе не привязывают открытый ключ к личности. Для этого нужна инфраструктура доверия (PKI, сертификаты), к которой мы подойдем далее.

PKI, сертификаты и управление жизненным циклом ключей

В предыдущей статье про криптографию открытых ключей мы уперлись в ключевую границу: подписи, ECDH и асимметричное шифрование дают инструменты, но сами по себе не отвечают на вопрос кому принадлежит открытый ключ. Если атакующий подменит (открытый ключ) на свой, то проверка подписи или установление общего секрета может успешно пройти, но уже с атакующим.

Эта статья закрывает эту дыру на уровне системной инженерии: как работает PKI (Public Key Infrastructure), что такое сертификаты, как строится цепочка доверия, как выполняется проверка сертификата, что такое отзыв и почему в современном интернете важны дополнительные механизмы вроде Certificate Transparency. Во второй части мы разберем, как управлять жизненным циклом ключей, потому что даже идеально выбранные алгоритмы ломаются из-за ошибок в генерации, хранении, ротации и компрометации ключевого материала.

Что такое PKI и какую проблему она решает

PKI — это набор ролей, правил и технических механизмов, которые позволяют:

связать открытый ключ с идентичностью (именем домена, организацией, человеком, сервисом)

масштабировать доверие (чтобы не договариваться о ключе вручную с каждым)

управлять сроками действия, заменой и отзывом ключей

В практическом интернете под PKI часто имеют в виду Web PKI: экосистему сертификатов, которые используются в TLS для HTTPS.

Ключевое утверждение PKI формулируется так:

удостоверяющий центр (CA) подписывает сообщение вида: «этот открытый ключ принадлежит этому субъекту и действителен на этих условиях»

Субъект может быть, например, доменом example.com.

Роли в PKI

Типовая PKI включает несколько ролей.

Субъект (Subject): тот, чья идентичность описана в сертификате (например, сайт).

Владелец закрытого ключа: обычно субъект (или его инфраструктура), кто хранит и делает подписи в TLS.

Удостоверяющий центр (CA): выпускает и подписывает сертификаты.

Регистрационный центр (RA): проверяет, что субъект имеет право на идентичность (часто это часть CA).

Полагатель (Relying Party): клиент, который проверяет сертификат (браузер, API-клиент, сервис).

!Роли PKI и направления доверия

Сертификат X.509: что это такое и что внутри

В Web PKI основным форматом является X.509 сертификат. Базовая спецификация: RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile.

Сертификат можно понимать как структурированное заявление, подписанное CA.

Основные поля сертификата (инженерно важные)

Subject: кому принадлежит сертификат.

Subject Alternative Name (SAN): список доменных имен и/или IP, для которых сертификат действителен (в Web PKI это критичнее, чем старое поле CN).

Subject Public Key Info: открытый ключ субъекта (тот самый , который клиент будет использовать для проверки).

Issuer: кто выпустил сертификат (какой CA).

Validity: период действия notBefore и notAfter.

Key Usage / Extended Key Usage: для чего разрешено использовать ключ (например, serverAuth для TLS-сервера).

Basic Constraints: является ли сертификат CA (может ли он подписывать другие сертификаты) или это конечный (end-entity) сертификат.

Signature Algorithm + Signature: каким алгоритмом CA подписал сертификат и сама подпись.

Смысл PKI в том, что клиент доверяет не словам сервера, а подписи CA на данных сертификата.

Цепочка доверия: от сайта до корневого сертификата

Сертификаты обычно проверяются не по одному, а как цепочка.

Корневой сертификат (root CA): самоподписанный; ему доверяют потому, что он заранее установлен в доверенном хранилище (в браузере/ОС).

Промежуточный сертификат (intermediate CA): подписан корневым CA и используется для выпуска конечных сертификатов.

Конечный сертификат (leaf, end-entity): сертификат сайта/сервиса.

Практическая причина такой архитектуры:

корневой ключ держат максимально изолированно (редко используют)

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

!Как строится цепочка доверия в X.509

Проверка сертификата: что именно делает клиент

Когда клиент получает сертификат сервера (и часто цепочку intermediate-сертификатов), он выполняет набор проверок. Важно понимать: “сертификат есть” не означает “сертификат принят”.

Типовые шаги проверки:

Проверить, что доменное имя, к которому подключаемся, присутствует в SAN сертификата.

Проверить сроки действия (текущее время попадает в notBefore–notAfter).

Построить цепочку до доверенного корневого сертификата из trust store.

Криптографически проверить подписи в цепочке (каждый сертификат подписан ключом Issuer).

Проверить ограничения и политики.

Basic Constraints: intermediate действительно CA.

Key Usage / Extended Key Usage: сертификат допустим для serverAuth.

Проверить статус отзыва (если политика клиента это требует): CRL и/или OCSP.

Если все проверки пройдены, клиент принимает, что ключ в leaf-сертификате принадлежит ожидаемому имени.

Почему CA — это не “магический источник правды”

PKI не устраняет риск полностью, она его перераспределяет:

доверие переносится на экосистему CA и правила их работы

компрометация или ошибка CA может привести к выпуску “неправильного” сертификата

Поэтому в Web PKI существуют дополнительные механизмы контроля (например, журналы Certificate Transparency) и строгие требования к CA.

Отзыв сертификатов: CRL и OCSP

Сертификат может стать недействительным до истечения срока по причинам:

компрометация закрытого ключа

ошибка выпуска (неправильные домены)

прекращение права владения доменом/именем

Для этого есть механизмы отзыва.

CRL

CRL (Certificate Revocation List) — список отозванных сертификатов, который публикует CA. Описано в профиле X.509: RFC 5280.

Инженерные особенности:

CRL может быть большим

клиенту нужно уметь скачать CRL и периодически обновлять

OCSP

OCSP (Online Certificate Status Protocol) — протокол, по которому клиент запрашивает у OCSP-респондера статус конкретного сертификата. Стандарт: RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP.

Инженерные особенности:

требует сетевого запроса (это влияет на задержку и приватность)

если OCSP недоступен, многие клиенты переходят в режим soft-fail (иначе интернет “ломался” бы из-за недоступности инфраструктуры)

OCSP stapling

Чтобы не заставлять клиента ходить к OCSP отдельно, сервер может прикреплять “свежий” OCSP-ответ прямо в TLS-рукопожатии. Это снижает задержку и улучшает приватность.

Практический вывод: отзыв в Web PKI исторически сложен, и многие системы безопасности проектируют так, чтобы минимизировать время жизни сертификатов и ускорять ротацию.

Certificate Transparency: публичная наблюдаемость выпусков

Certificate Transparency (CT) — механизм, который делает выпуск сертификатов публично наблюдаемым через журналы. Базовая спецификация: RFC 6962: Certificate Transparency.

Зачем это нужно:

обнаруживать ошибочные или злонамеренные выпуски сертификатов

повышать контролируемость экосистемы CA

Практический эффект для владельца домена:

можно мониторить CT-логи и получать сигнал, если кто-то выпустил сертификат на ваш домен

Как PKI используется в TLS (на уровне идеи)

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

Высокоуровневая логика современного TLS:

клиент проверяет сертификат сервера (PKI)

клиент и сервер устанавливают общий секрет (обычно через (EC)DHE)

из секрета выводятся симметрические ключи

дальше трафик защищается AEAD (то, что мы разбирали в темах про конфиденциальность и целостность)

Если интересно связать это со стандартом: RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3.

Pinning и TOFU: альтернативы классическому доверию к CA

Иногда модель угроз не хочет или не может полностью полагаться на “публичные CA”. Тогда применяют альтернативы.

Pinning: клиент “прибивает” конкретный публичный ключ или конкретный CA для домена.

TOFU (Trust On First Use): при первом подключении ключ запоминается как доверенный, дальше любые изменения считаются подозрительными.

Инженерные плюсы:

сокращение поверхности доверия к множеству CA

Инженерные минусы:

сложность ротации (как безопасно сменить ключ)

риск “первого подключения” в присутствии атакующего (особенно для TOFU)

Выбор зависит от модели угроз, с которой мы начинали курс.

Управление жизненным циклом ключей: почему это часть криптосистемы

До этого курса мы много говорили про алгоритмы и схемы (AEAD, подписи, ECDH). Но в реальных инцидентах часто ломается не математика, а процесс:

ключ утек в логах

ключ попал в бэкап без шифрования

ключ использовали дольше, чем планировалось

ключ не отозвали после компрометации

Управление ключами обычно описывают как жизненный цикл. Хороший ориентир по терминологии и практикам: NIST SP 800-57 Part 1: Recommendation for Key Management.

!Жизненный цикл криптографического ключа

Генерация ключей

Требования:

использовать криптографически стойкий генератор случайных чисел

выбирать корректные параметры (например, рекомендованные кривые или длины ключей)

фиксировать, для какой цели создается ключ (подпись, шифрование, KDF), чтобы не смешивать назначения

Практика:

генерировать ключи внутри защищенного окружения (HSM, TPM, KMS), чтобы закрытый ключ физически не покидал контролируемую границу

Хранение и доступ

Базовые инженерные правила:

минимизировать количество мест, где ключ существует в открытом виде

ограничивать доступ по принципу наименьших привилегий

использовать разделение обязанностей (например, разные роли на выпуск и на эксплуатацию)

вести аудит операций с ключами

Технические меры:

HSM для CA и для критичных серверных ключей

KMS для управления ключами приложений (с политиками доступа, ротацией, журналированием)

Использование ключей: привязка к контексту

Даже при корректном хранении ключ можно использовать опасно:

один и тот же ключ применяют для разных протоколов

один и тот же ключ используют и для шифрования, и для подписи

Практика:

разделять ключи по назначению

в протоколах использовать KDF и выводить отдельные ключи для отдельных целей

Ротация и срок жизни

Ротация — плановая замена ключей и/или сертификатов.

Зачем:

ограничить ущерб от незамеченной компрометации

адаптироваться к изменениям требований (например, алгоритмы/размеры ключей)

соблюдать политики и стандарты

Инженерно важно отличать:

ротацию сертификата (часто делают чаще)

ротацию ключа (может быть реже, но зависит от модели угроз)

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

Компрометация: что делать, если утек

Если закрытый ключ утек, это означает:

атакующий может выдавать себя за владельца ключа

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

Реакция должна быть процедурой, а не импровизацией:

немедленно прекратить использование ключа

отозвать сертификат (если применимо)

выпустить новый ключ и новый сертификат

провести расследование: откуда утекло, какие системы затронуты

обновить зависимости: pinning, конфиги клиентов, цепочки доверия

Уничтожение и архивирование

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

Практика:

уничтожать ключевой материал по окончании срока

хранить архивы в зашифрованном виде, с жестким контролем доступа

документировать, какие ключи для чего были предназначены и когда были активны

Частые ошибки в PKI и управлении ключами

Не проверять имя в сертификате: сертификат “валиден”, но не для того домена.

Пропускать проверку цепочки: принимать самоподписанный сертификат без явного pinning.

Смешивать окружения: один и тот же ключ используется в dev/stage/prod.

Не планировать ротацию: сертификат “внезапно” истекает и сервис падает.

Слабая защита закрытого ключа: ключ лежит на диске без аппаратной защиты и без контроля доступа.

Игнорировать отзыв и CT-сигналы: компрометация выявляется, но не закрывается процессом.

Итоги

PKI решает проблему привязки открытого ключа к идентичности и защищает от подмены ключа в недоверенной сети.

Сертификаты X.509 (RFC 5280) несут имя (SAN), открытый ключ, ограничения использования и подпись CA.

Клиент принимает сертификат только после набора проверок: имя, сроки, цепочка до trust store, ограничения, отзыв.

Отзыв реализуется через CRL и OCSP (RFC 6960), но в Web PKI это сложная область, поэтому важны автоматизация и короткие сроки.

Certificate Transparency (RFC 6962) добавляет публичную наблюдаемость выпусков.

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

Криптографические протоколы и практики внедрения

В предыдущих статьях курса мы последовательно разобрали:

модель угроз и криптографические сервисы (что именно защищаем)

примитивы и схемы (хэши, MAC, шифрование, AEAD)

базовую целостность и аутентичность (MAC и подписи)

конфиденциальность на практике (симметричное шифрование, режимы, nonce)

криптографию открытых ключей и PKI (как масштабировать доверие)

Эта статья отвечает на инженерный вопрос: как собрать все это в работающий протокол и не сломать безопасность реализацией и эксплуатацией.

Что такое криптографический протокол

Криптографический протокол — это согласованный набор правил, по которым участники:

договариваются о ключах и параметрах

аутентифицируют друг друга и/или сообщения

защищают сообщения (конфиденциальность, целостность, аутентичность)

обрабатывают ошибки и повторные передачи

Протокол важнее отдельного алгоритма, потому что большинство практических провалов происходит на стыке:

композиции схем (что подписываем, что шифруем, в каком порядке)

форматов сообщений (какие байты считаются «тем самым сообщением»)

управления состоянием (nonce, счетчики, сессии)

поведения при ошибках (оракулы, утечки по времени)

Хороший ориентир по тому, как писать и анализировать security considerations протоколов: RFC 3552: Guidelines for Writing RFC Text on Security Considerations.

Базовый шаблон современного защищенного канала

Практически все «защищенные каналы» в современных системах следуют гибридной логике, которую мы обсуждали в статье про открытые ключи:

Аутентифицироваться и/или установить общий секрет с помощью открытых ключей.

Вывести из секрета набор симметрических ключей (разделение по назначению).

Передавать данные с помощью AEAD (конфиденциальность плюс проверяемая целостность).

!Схема показывает, как открытые ключи и AEAD соединяются в единый защищенный канал

Классический пример такого протокола в интернете: RFC 8446: TLS 1.3.

Протокольные цели: что именно нужно «прибить» криптографией

На уровне протокола обычно нужно явно обеспечить несколько свойств.

Аутентификация участников: с кем установлен канал.

Согласование алгоритмов: чтобы не было принудительного выбора слабых параметров.

Свежесть: защита от replay на уровне рукопожатия и/или сообщений.

Связь контекста: чтобы теги/подписи нельзя было перенести в другой сценарий.

Разделение ключей: чтобы один ключ не использовался «на все».

Если хотя бы одно из этих свойств не сформулировано, система часто «выглядит криптографичной», но остается атакуемой.

Каноникализация и «какие именно байты мы защищаем»

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

Типовая инженерная проблема: одно и то же сообщение может иметь несколько эквивалентных представлений.

Примеры источников неоднозначности:

порядок полей (JSON-объекты не упорядочены)

разный формат чисел и строк (пробелы, Unicode-нормализация)

разные варианты кодирования (base64 с переносами строк)

Практики:

определять бинарный формат (TLV, protobuf) или строгую каноникализацию

всегда включать в аутентифицируемые данные явные разделители и длины полей

включать контекст (например, строку версии протокола или тип операции)

Идея «явного контекста» часто называется domain separation: один и тот же ключ или алгоритм используется в разных местах, но входы различимы.

Согласование алгоритмов и защита от downgrade

Даже если у вас есть сильные алгоритмы, протокол может быть уязвим, если активный нарушитель может заставить стороны выбрать более слабый вариант.

Что важно в протоколе:

список поддерживаемых алгоритмов должен передаваться аутентифицированно

выбранный набор алгоритмов должен входить в то, что подписывается/аутентифицируется

версия протокола должна быть защищена так же, как и остальной контекст

TLS 1.3 уделяет этому большое внимание на уровне «привязки» параметров к рукопожатию и проверке целостности сообщений рукопожатия: RFC 8446: TLS 1.3.

Вывод ключей и разделение по назначению

В статье про MAC и подписи мы обсуждали правило: один ключ не должен обслуживать разные задачи. На уровне протокола это достигается через KDF.

Часто используется HKDF: RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF).

Идея в инженерных терминах:

есть один исходный секрет (например, результат ECDH)

из него детерминированно выводится множество ключей

каждый ключ получает свой info (контекст), чтобы ключи не «перепутались»

Эту логику можно записать одной строкой:

Пояснение элементов формулы:

— i-й производный ключ (например, ключ для шифрования в направлении клиент → сервер)

— функция вывода ключей (конкретный стандартный алгоритм)

— общий секрет, полученный из обмена ключами или другого источника

— контекст, который различает назначения (например, строка "c2s key" или "handshake")

Практический результат разделения:

отдельные ключи для разных направлений

отдельные ключи для разных стадий (рукопожатие и прикладные данные)

отдельные ключи для шифрования и аутентификации (или единый AEAD-ключ, если используется AEAD)

Nonce и счетчики: как не сломать AEAD и потоковые режимы

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

Типовой безопасный подход:

хранить счетчик сообщений (sequence number)

строить nonce как функцию от базового nonce и счетчика

запрещать повтор счетчика

Проблемы, которые нужно решить проектированием:

что делать при потере пакетов и переупорядочивании (актуально для UDP)

как синхронизировать счетчики после разрыва соединения

как ограничить число сообщений на одном ключе (policy по лимитам)

Если протокол не задает эти правила, реализация почти неизбежно придет к повтору nonce в edge-case сценариях.

Replay: свежесть на уровне рукопожатия и сообщений

Replay-атака возможна даже при идеальной криптографии: атакующий повторяет корректное старое сообщение.

Практики защиты:

nonce-вызов (challenge) от проверяющей стороны

монотонные счетчики и окна принятия

метки времени плюс допуск (если можно доверять времени)

привязка к сессии (идентификатор сессии входит в защищаемые данные)

Ключевое правило из статьи про MAC и подписи сохраняется: элемент свежести должен входить в данные, покрываемые MAC/подписью/AEAD-тегом.

Обработка ошибок и «оракулы»

Многие протоколы ломались не потому, что шифр слабый, а потому что система сообщала слишком много при ошибках.

Типовые опасные сигналы:

разные тексты ошибок для «неверный padding» и «неверный MAC»

разные HTTP-коды или разные задержки для разных типов неуспеха

раннее прекращение сравнения тегов

Практики:

единообразные ошибки расшифрования и проверки

сравнение тегов в постоянное время (constant-time compare)

минимизация различимого поведения до проверки целостности

Исторический контекст: проблемы вокруг CBC и padding-oracle атак привели к тому, что современная инженерная практика предпочитает AEAD и протоколы, где порядок проверок и ошибки строго регламентированы.

Защита «протоколом», а не «надеждой»: привязка всех параметров к аутентификации

Один из самых надежных принципов проектирования:

все, что влияет на смысл и безопасность, должно быть аутентифицировано

Сюда обычно входят:

идентификаторы сторон и ролей (кто клиент, кто сервер)

версия протокола и выбранные алгоритмы

параметры обмена ключами

идентификатор сессии

заголовки и метаданные, которые нельзя менять (в AEAD это обычно AAD)

Если часть полей не покрыта аутентификацией, атакующий будет пытаться менять именно их.

Практики безопасной реализации

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

Использовать высокоуровневые примитивы и стандартные протоколы

Инженерная рекомендация по умолчанию:

не проектировать «свой TLS»

использовать стандартные протоколы, прошедшие анализ и внедрение

Для защищенного транспорта это обычно означает TLS, а не самодельные схемы.

Не «склеивать» примитивы вручную, если есть AEAD

Из тем про целостность и конфиденциальность:

шифрование без аутентификации опасно

композиция «шифрование + MAC» требует строгих правил

Если задача похожа на «передать данные по сети или хранить запись так, чтобы нельзя было незаметно изменить», выбор по умолчанию:

AEAD (например, AES-GCM по NIST SP 800-38D: GCM или ChaCha20-Poly1305 по RFC 8439: ChaCha20 and Poly1305 for IETF Protocols)

Безопасная генерация случайных чисел

Случайность критична для:

генерации ключей

некоторых схем подписи

nonce/IV там, где требуется непредсказуемость

Практика:

использовать системный CSPRNG

не использовать Math.random() и аналоги

не генерировать ключи из паролей без KDF (это отдельная тема, обычно PBKDF2/scrypt/Argon2)

Постоянное время выполнения для критичных операций

В сетевых сервисах опасны утечки по времени:

сравнение MAC/тега

операции с секретными ключами

Практика:

использовать библиотечные constant-time функции

избегать ветвлений по секретным данным

Учет границ доверия и «утечек в логах»

Из модели угроз:

сеть недоверенная

логи и мониторинг часто читают многие системы и люди

Практики:

не логировать ключи, токены, расшифрованные данные

аккуратно логировать причины ошибок (особенно криптографических)

ограничивать доступ к дампам памяти и трейсингу

Рекомендации высокого уровня по хранению секретов и криптографическим ошибкам удобно сверять с прикладными гайдами, например: OWASP Cryptographic Storage Cheat Sheet.

Практики безопасного внедрения и эксплуатации

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

Управление ключами и секретами

Практики:

хранить ключи в KMS/HSM, когда это оправдано моделью угроз

ограничивать доступ к ключам по ролям

разделять ключи по окружениям (dev, stage, prod)

планировать ротацию и аварийную замену

Ориентир по терминологии и ключевым принципам: NIST SP 800-57 Part 1: Recommendation for Key Management.

Обновления и совместимость

Реальные системы живут годами, поэтому нужно проектировать:

версионирование протокола

безопасный отказ при неподдерживаемых версиях

выключение слабых алгоритмов без поломки критичных клиентов

Важный практический риск: «временная совместимость» с устаревшими алгоритмами часто становится постоянной.

Тестирование и валидация криптографии

Минимальный набор инженерных проверок:

тесты на корректность форматов и каноникализации

тесты на повтор nonce и на восстановление после сбоев

негативные тесты (изменение 1 байта в шифртексте должно приводить к отказу)

проверка того, что все параметры протокола действительно входят в аутентифицируемые данные

Для TLS полезны внешние средства тестирования конфигурации, например: Qualys SSL Labs: SSL Server Test.

Минимальные «красные флаги» криптопротокола

Если при ревью вы видите один из признаков ниже, почти всегда нужен углубленный анализ.

«Своя криптография» без строгой спецификации формата байт.

Шифрование без аутентификации или проверка тега после разбора данных.

Неописанные правила nonce/счетчиков.

Согласование алгоритмов без криптографической привязки к рукопожатию.

Разные сообщения об ошибках расшифрования.

Один ключ «на все» или повторное использование ключей между окружениями.

Итоги

Криптографический протокол — это не «алгоритм», а правила композиции: форматы, состояния, ключи, обработка ошибок.

Типовой современный шаблон: аутентифицированный обмен ключами (открытые ключи и PKI) → KDF и разделение ключей → AEAD для трафика.

Основные протокольные риски: downgrade, replay, неверная каноникализация, повтор nonce, оракулы ошибок.

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

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