Шифрование почти никогда не ломают лобовой атакой на алгоритм. Чаще ломают ключ, его выдачу, хранение, права доступа или логику обмена. Поэтому «ключ шифрования» - это не абстрактная строка байтов, а весь жизненный цикл от генерации до уничтожения, с правилами, ролями и ротацией.
Что такое ключ шифрования и какие бывают ключи
Ключ шифрования - секретный параметр, который управляет преобразованием данных. Один и тот же алгоритм с разными ключами дает разные результаты, и без правильного ключа восстановить исходные данные практически невозможно. Важно помнить, что ключ - это именно секрет, а не «пароль в конфиге». Его нельзя копировать как удобнее и хранить где попало.
Самое базовое деление - симметричные и асимметричные ключи. Симметричный ключ один и тот же для шифрования и расшифрования. Он быстрый и поэтому почти всегда используется для больших объемов данных. Асимметричная пара состоит из открытого и закрытого ключа. Открытым можно шифровать или проверять подпись, а закрытым - расшифровывать или подписывать.
Помимо ключей для шифрования данных существуют ключи для подписи, аутентификации, выработки ключей, обертки ключей и ключи сеанса. Эта классификация важнее названий алгоритмов, потому что помогает правильно строить схему и права доступа.
На практике вы почти всегда встретите модель с несколькими уровнями ключей. Есть долгоживущий ключ, который защищают максимально жестко, и есть краткоживущие ключи, которыми реально шифруют данные или трафик. Такой подход прямо описывается как «конвертное шифрование» у провайдеров облачных KMS, где ключ данных шифруется более «тяжелым» ключом верхнего уровня.
- Ключ шифрования данных (DEK) - короткоживущий ключ для конкретного объекта, файла или сессии.
- Ключ шифрования ключей (KEK) - ключ, которым «оборачивают» DEK.
- Сеансовый ключ - ключ, живущий ровно в рамках сессии, например в TLS.
- Ключ подписи - ключ для создания цифровой подписи, обычно асимметрический.
- Ключ выработки (master) - вход для KDF, из которого получают рабочие ключи по контексту.
Длина ключа и «стойкость»
Длина ключа - это не единственный фактор безопасности, но она задает нижнюю границу для перебора. Для симметричных алгоритмов ключ на 128 бит уже дает огромный запас для большинства сценариев, а 256 бит чаще выбирают как универсальный вариант с запасом на будущее. Для AES стандартно используются ключи 128, 192 или 256 бит, это зафиксировано в официальном описании стандарта.
У асимметрии другая математика. Там «битность ключа» не сопоставляется напрямую с симметрической. Поэтому корректнее говорить о целевом уровне стойкости, а затем подбирать алгоритм и параметры. В рекомендациях NIST по управлению ключами используется понятие security strength и дискретные уровни вроде 112, 128, 192 и 256 бит.
На выбор длины влияют срок жизни ключа, ценность данных и риск компрометации. Если ключ живет долго и защищает много данных, то любая утечка становится катастрофой. Если ключ краткоживущий и привязан к контексту, последствия утечки локализуются. Поэтому грамотная схема часто важнее, чем гонка за «самыми большими числами».
Еще один типичный промах - путать ключ и параметры режима. Например, для AEAD режимов вроде GCM важен не только ключ, но и уникальность nonce или IV. У OpenSSL прямо описано, что для AES-GCM есть значения по умолчанию для длины IV, и что длину можно настраивать, но смысл не в «магии длины», а в корректном использовании режима и недопущении повторов.
| Что выбираем | Зачем | Практический ориентир |
|---|---|---|
| Симметричный ключ | Шифрование данных и потоков | AES-128 или AES-256 по NIST |
| Пара открытый и закрытый | Подпись, обмен ключами, идентичность | Выбор зависит от протокола и политики, ориентир - целевой уровень стойкости |
| Ключ обертки | Защита ключей данных | Использовать конвертное шифрование в KMS |
Обмен ключами. Как появляется общий секрет
Главная проблема симметрии проста. Сторонам нужен общий секрет, но передать его по сети нельзя, иначе его перехватят. Поэтому обмен ключами решают либо асимметрией, либо протоколами согласования общего секрета, а затем шифруют трафик симметрией.
Самый массовый пример - TLS. В TLS 1.3 протокол устроен так, что сессия строится на Diffie-Hellman подходе, обычно в варианте ECDHE, чтобы получить прямую секретность. Идея в том, что компрометация долгоживущего ключа сервера не должна автоматически раскрывать старые сессии. Спецификация TLS 1.3 описывает схему и требования на уровне стандарта.
После получения общего секрета его нельзя просто «использовать как ключ». Секрет надо преобразовать в набор ключей нужной длины и назначения, а также привязать к контексту сессии. Для этого используются функции выработки ключей. В современных протоколах часто встречается HKDF, который формально описан отдельным RFC и задает аккуратную модель «извлечь и расширить».
Отдельная категория - ключи из паролей. Пароль редко подходит как криптоключ, потому что он предсказуем и имеет маленькую энтропию. Поэтому применяют KDF с затратами по времени и памяти, чтобы сделать перебор дороже. Исторически широко используется PBKDF2, который описан в RFC и применяется как совместимый базовый вариант.
- Согласовать общий секрет через ECDHE или использовать заранее разделяемый секрет.
- Прогнать секрет через KDF, чтобы получить рабочие ключи для шифрования и целостности.
- Разнести ключи по назначениям, например отдельный ключ на шифрование и отдельный на аутентификацию.
- Задать четкое время жизни сессии и условия пересоздания ключей.
Управление, хранение и ротация. То, где реально теряют ключи
Управление ключами - это политика и инфраструктура. Кто имеет право создавать ключи, кто может шифровать, кто может расшифровывать, где ведется аудит, как происходит ротация и как ключи выводятся из эксплуатации. NIST в рекомендациях по key management как раз делает упор на процессы и роли, а не только на алгоритмы.
В инфраструктуре ключи не должны жить в исходниках, переменных окружения и общих папках. Для этого используют KMS и HSM. KMS дает централизованные политики и аудит, а HSM изолирует операции с ключом внутри криптомодуля. Если важна формальная соответствующая база, ориентируются на требования к криптомодулям, описанные в FIPS 140-3.
Конвертное шифрование помогает масштабировать безопасность. Вы генерируете уникальный ключ данных на объект, шифруете данные им, затем шифруете сам ключ данных ключом верхнего уровня. Такой механизм подробно описан у облачных провайдеров, и он позволяет ограничить доступ к расшифрованию через политику KMS, не трогая сами данные.
Ротация должна быть запланирована. Криптопериод зависит от типа ключа и угроз. Чем больше данных шифрует один ключ и чем дольше он живет, тем выше цена утечки. В рекомендациях NIST отдельно обсуждаются сроки использования и хранения ключевого материала. Практически это превращается в простое правило. Ротируйте ключи верхнего уровня по расписанию, а ключи данных делайте одноразовыми или очень короткоживущими.
Для прикладных систем полезны готовые механизмы защиты секретов на платформе. На Windows, например, можно использовать DPAPI через системные API и .NET, чтобы не изобретать собственное хранение ключей в приложении. Для сервисной криптографии удобны решения вроде Transit Engine в Vault, где приложение отправляет данные на шифрование, а ключи и политика живут отдельно.
- Храните ключи в KMS или HSM, доступ выдавайте по минимально необходимым правам.
- Отделяйте права «шифровать» и «расшифровывать», это снижает риск тихой утечки.
- Логируйте операции с ключами и включайте аудит событий.
- Делайте ключи данных короткоживущими, а долгоживущие ключи используйте как KEK.
- Проверяйте, что nonce и IV не повторяются там, где это критично для режима работы.
Если резюмировать, надежность схемы почти всегда определяется дисциплиной. Генерация ключей должна быть криптостойкой, обмен - протокольным, хранение - централизованным, а ротация - регулярной. Тогда «ключ шифрования данных» перестает быть слабым местом и становится управляемым активом безопасности.
