Набор шифров - Cipher suite

Набор шифров - это набор алгоритмов, которые помогают защитить сетевое соединение. Пакеты обычно используют Transport Layer Security (TLS) или его устаревший предшественник Secure Socket Layer (SSL). Набор алгоритмов , которые шифры обычно содержат включает: алгоритм обмена ключей , а алгоритм шифрования насыпного , и код аутентификации сообщения алгоритма (MAC).

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

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

Структура и использование концепции набора шифров определены в стандартном документе TLS. TLS 1.2 - самая распространенная версия TLS. Следующая версия TLS (TLS 1.3) включает дополнительные требования к комплектам шифров. TLS 1.3 был стандартизирован только недавно и пока не получил широкого распространения. Наборы шифров, определенные для TLS 1.2, не могут использоваться в TLS 1.3, и наоборот, если иное не указано в их определении.

Справочный список именованных наборов шифров предоставляется в реестре TLS Cipher Suite.

История

Использование шифров было частью транзитного протокола Secure Socket Layer (SSL) с момента его создания. SSL был заменен TLS для большинства применений. Однако название Cipher Suite не использовалось в первоначальном проекте SSL. Вместо этого возможность для клиента и сервера выбирать из небольшого набора шифров для защиты своего соединения была названа Cipher-Choice. Имя Cipher Suite использовалось только после SSL v3 (последней версии SSL) . С тех пор каждая версия TLS использовала Cipher Suite в своей стандартизации. Концепция и цель Cipher Suite не изменились с момента появления этого термина. Он имеет и до сих пор используется в качестве структуры, описывающей алгоритмы, которые поддерживает машина, чтобы две машины могли решить, какие алгоритмы использовать для защиты своего соединения. Что изменилось, так это версии алгоритмов, которые поддерживаются в наборах шифров. В каждую версию TLS добавлена ​​поддержка более сильных версий алгоритмов и удалена поддержка версий алгоритмов, которые были определены как небезопасные.

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

Схема именования

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

Значение этого имени таково:

  • TLS определяет протокол, для которого предназначен этот набор шифров; Обычно это TLS.
  • ECDHE указывает используемый алгоритм обмена ключами .
  • Механизм аутентификации RSA во время рукопожатия.
  • Сессионный шифр AES
  • 128 размер ключа шифрования сеанса (бит) для шифра
  • Тип шифрования GCM (зависимость блока шифрования и дополнительные параметры)
  • Хэш-функция SHA (SHA2). Для дайджеста 256 и выше. Механизм подписи. указывает алгоритм аутентификации сообщения, который используется для аутентификации сообщения.
  • 256 Размер дайджеста (бит).

Полное рукопожатие: координация наборов шифров

Чтобы использовать наборы шифров, клиент и сервер должны согласовать конкретный набор шифров, который будет использоваться при обмене сообщениями. И клиент, и сервер должны поддерживать согласованный набор шифров. Если клиент и сервер не согласны с набором шифров, соединение не будет установлено. Этот процесс выбора происходит во время протокола установления связи TLS. TLS 1.3 включает протокол установления связи TLS, который отличается от прошлой и текущей версии TLS / SSL.

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

Чтобы проверить, какие шифры TLS поддерживает сервер, можно использовать сканер SSL / TLS. [1]

Рукопожатие TLS 1.0–1.2

Визуальное представление того, как клиент и сервер, работающие на TLS 1.2, согласовывают, какой набор шифров использовать

Этот клиент запускает процесс, отправляя на сервер сообщение clientHello, которое включает версию используемого TLS и список наборов шифров в порядке, выбранном клиентом. В ответ сервер отправляет сообщение serverHello, которое включает в себя выбранный набор шифров и идентификатор сеанса. Затем сервер отправляет клиенту цифровой сертификат для подтверждения своей личности. Сервер также может запросить цифровую сертификацию клиента, если это необходимо.

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

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

Визуальное представление того, как клиент и сервер, работающие на TLS 1.3, координируют, какой набор шифров использовать

Рукопожатие TLS 1.3

Если две машины соответствуют TLS 1.3, они координируют, какой набор шифров использовать, используя протокол установления связи TLS 1.3. Рукопожатие в TLS 1.3 было сведено только к одному циклу приема- передачи по сравнению с двумя циклами приема-передачи, необходимыми в предыдущих версиях TLS / SSL.

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

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

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

Поддерживаемые алгоритмы

В TLS 1.0–1.2

Алгоритмы, поддерживаемые в наборах шифров TLS 1.0–1.2
Обмен ключами / соглашение Аутентификация Блочные / потоковые шифры Аутентификация сообщения
ЮАР ЮАР RC4 MD5 на основе хеша
Диффи – Хеллмана DSA Тройной DES Хеш-функция SHA
ECDH ECDSA AES
SRP ИДЕЯ
PSK DES
Камелия
ChaCha20

Для получения дополнительной информации об алгоритмах, поддерживаемых TLS 1.0–1.2, см. Также: Безопасность транспортного уровня § Приложения и внедрение

TLS 1.3

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

DTLS с наборами шифров

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

Чтобы определить, совместим ли набор шифров TLS с DTLS, просмотр его имени не поможет. Каждый набор шифров TLS по-прежнему будет включать в себя пространство идентификаторов TLS в своем имени. например: TLS _ECDHE_RSA_WITH_AES_128_GCM_SHA256 . Вместо этого все реестры параметров TLS теперь включают флаг DTLS-OK, чтобы сигнализировать, поддерживает ли набор шифров DTLS.

Уязвимости

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

При инициировании рукопожатия современный клиент предложит самый высокий протокол, который он поддерживает. Если соединение не удается, оно автоматически повторяет попытку снова с более низким протоколом, таким как TLS 1.0 или SSL 3.0, до тех пор, пока подтверждение связи с сервером не будет успешным. Целью перехода на более раннюю версию является обеспечение совместимости новых версий TLS со старыми версиями. Однако злоумышленник может воспользоваться этой функцией и сделать так, чтобы клиент автоматически переходил на версию TLS или SSL, которая поддерживает наборы шифров с алгоритмами, которые известны слабой безопасностью и уязвимостями. Это привело к атакам типа POODLE .

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

Наборы шифров для ограниченных устройств

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

  1. TLS_PSK_WITH_AES_128_CCM_8 ( предварительный общий ключ )
  2. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 ( необработанный открытый ключ )

Каждый из этих наборов шифров был реализован для работы на устройствах с ограничениями в вычислительной мощности и памяти. Оба они реализованы в проекте TinyDTLS с открытым исходным кодом . Причина, по которой они могут работать на этих ограниченных устройствах, заключается в том, что они могут быть реализованы легким способом. Реализации набора шифров с предварительным общим ключом использовали только 1889 байт ОЗУ и 38266 байт флэш-ПЗУ, что очень требовательно к ресурсам по сравнению с большинством алгоритмов шифрования и безопасности. Такое низкое использование памяти связано с тем, что в этих наборах шифров используются проверенные эффективные алгоритмы, которые являются безопасными, но, возможно, не такими безопасными, как алгоритмы, требующие большего количества ресурсов; exp: Использование 128-битного шифрования против 256-битного шифрования. Кроме того, они используют предварительный общий ключ или необработанный открытый ключ, который требует меньше места в памяти и вычислительной мощности по сравнению с использованием традиционной инфраструктуры открытых ключей (PKIX).

Ссылки по программированию

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

CipherSuite cipher_suites
список криптографических опций, поддерживаемых клиентом. Пример того, как cipher_suites обычно используется в процессе рукопожатия:
   struct {
       ProtocolVersion client_version;
       Random random;
       SessionID session_id;
       CipherSuite cipher_suites<2..2^16-2>;
       CompressionMethod compression_methods<1..2^8-1>;
       select (extensions_present) {
           case false:
               struct {};
           case true:
               Extension extensions<0..2^16-1>;
       };
   } ClientHello;
CipherSuite cipher_suite
набор шифров, выбранный сервером из клиентского набора cipher_suites . Пример того, как cipher_suite обычно используется в процессе рукопожатия:
      struct {
          ProtocolVersion server_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suite;
          CompressionMethod compression_method;
          select (extensions_present) {
              case false:
                  struct {};
              case true:
                  Extension extensions<0..2^16-1>;
          };
      } ServerHello;

Смотрите также

использованная литература