stringtranslate.com

Набор шифров

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

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

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

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

Список именованных наборов шифров представлен в Реестре наборов шифров TLS. [4]

История

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

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

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

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

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

ТЛС
определяет протокол, для которого предназначен этот набор шифров; обычно это TLS.
ECDHE
указывает используемый алгоритм обмена ключами .
ЮАР
механизм аутентификации во время рукопожатия.
АЕС
сеансовый шифр.
128
Размер ключа шифрования сеанса (бит) для шифра.
ГКМ
тип шифрования (зависимость от шифрблока и дополнительные параметры).
ША
(SHA2)хэш-функция. Для дайджеста 256 и выше. Механизм подписи. Указывает алгоритм аутентификации сообщения , который используется для аутентификации сообщения.
256
Размер дайджеста (бит).

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

Для использования наборов шифров клиент и сервер должны договориться о конкретном наборе шифров, который будет использоваться при обмене сообщениями. И клиент, и сервер должны поддерживать согласованный набор шифров. Если клиент и сервер не договорятся о наборе шифров, соединение не будет установлено. [8] Этот процесс выбора происходит во время протокола TLS Handshake. TLS 1.3 включает протокол TLS Handshake, который отличается от предыдущей и текущей версии 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 со своим ключом, сертификатом, выбранным набором шифров и готовым сообщением.

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

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

В TLS 1.0–1.2

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

ТЛС 1.3

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

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

Datagram Transport Layer Security (DTLS) основан на TLS, но специально используется для соединений UDP вместо соединений TCP . Поскольку DTLS основан на TLS, он может использовать большинство наборов шифров, описанных для TLS. Существуют особые случаи, которые необходимо учитывать при использовании наборов шифров TLS с DTLS. DTLS не поддерживает потоковый шифр RC4, что означает, что ни один шифр TLS, использующий RC4, не может использоваться с DTLS. [14]

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

Уязвимости

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

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

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

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

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

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

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

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

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

CipherSuite cipher_suites
список криптографических опций, поддерживаемых клиентом. [21] Пример того, как cipher_suites обычно используется в процессе рукопожатия:
 struct { ProtocolVersion client_version ; Случайный случайный ; 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 клиента . [22] Пример того, как 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 ;                         

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

Ссылки

  1. ^ "Наборы шифров в TLS/SSL (Schannel SSP) (Windows)". docs.microsoft.com . Получено 2018-07-02 .
  2. ^ "Настройка списка наборов шифров с использованием TLS v1.3". www.microfocus.com . Получено 2023-11-30 .
  3. ^ RFC5246 ​
  4. ^ Реестр наборов шифров TLS
  5. ^ "Протокол SSL 0.2". www-archive.mozilla.org . Получено 2017-12-07 .
  6. ^ "draft-hickman-netscape-ssl-00". tools.ietf.org . Получено 2017-12-07 .
  7. ^ "Спецификация SSL 3.0". www.freesoft.org . Получено 2017-12-07 .
  8. ^ Вильянуэва, Джон Карл. "Введение в наборы шифров" . Получено 25 октября 2017 г.
  9. ^ Вальсорда, Филиппо (23 сентября 2016 г.). «Обзор TLS 1.3 и вопросы и ответы». Блог Cloudflare . Получено 1 сентября 2020 г.
  10. ^ ECDHE_PSK с наборами шифров AES-GCM и AES-CCM для TLS 1.2 и DTLS 1.2. doi : 10.17487/RFC8442 . RFC 8442.
  11. ^ "Поддержка протокола TLS 1.3 | Встроенная библиотека SSL/TLS wolfSSL". wolfSSL . Получено 26.10.2017 .
  12. ^ E. Rescorla (4 ноября 2016 г.). "Протокол Transport Layer Security (TLS) версии 1.3" . Получено 11 ноября 2016 г.
  13. ^ Салливан, Ник (11 августа 2018 г.). «Подробный взгляд на RFC 8446 (он же TLS 1.3)». Блог Cloudflare . Получено 11 августа 2020 г.
  14. ^ Н., Модадугу; Э., Рескорла. "Datagram Transport Layer Security". tools.ietf.org . Получено 25.10.2017 .
  15. ^ Эрик, Рескорла; Нагендра, Модадугу. «Datagram Transport Layer Security Version 1.2». tools.ietf.org . Получено 25.10.2017 .
  16. ^ Бодо, Мёллер; Адам, Лэнгли. «Значение набора шифров сигнализации TLS Fallback (SCSV) для предотвращения атак понижения версии протокола». tools.ietf.org . Получено 25.10.2017 .
  17. ^ Бодо, Мёллер; Адам, Лэнгли. «Значение набора шифров сигнализации TLS Fallback (SCSV) для предотвращения атак понижения версии протокола». tools.ietf.org . Получено 25.10.2017 .
  18. ^ Дэниел, Бейли; Дэвид, МакГрю. «Наборы шифров AES-CCM для безопасности транспортного уровня (TLS)». tools.ietf.org . Получено 26.10.2017 .
  19. ^ Перельмен, Владислав (29 июня 2012 г.). «Безопасность в беспроводных сенсорных сетях с поддержкой IPv6: реализация TLS/DTLS для операционной системы Contiki» (PDF) : 38. Архивировано из оригинала (PDF) 29 августа 2017 г. Получено 7 декабря 2017 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  20. ^ Сэмюэл, Вайлер; Джон, Гилмор; Ханнес, Чофениг; Теро, Кивинен; Пол, Воутерс. «Использование необработанных открытых ключей в протоколах Transport Layer Security (TLS) и Datagram Transport Layer Security (DTLS)». tools.ietf.org . Получено 07.12.2017 .
  21. RFC  5246, стр. 41
  22. RFC  5246, стр. 42–43, 64