Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Московский институт электроники и математики им. А.Н. Тихонова

Выпускная квалификационная работа

Исследование TLS сокетов ядра Linux

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

студента образовательной программы специалитета

«Компьютерная безопасность»

Шорникова Наталья

Москва 2020



Аннотация

TLS - это широко распространенный протокол, используемый для защиты TCP соединений в современном интернете. TLS также является обязательным для HTTP/2, последнего веб-стандарта. Реализация данного протокола в ядре Linux позволит сократить нагрузку на процессор и увеличит скорость работы шифрования, а использование новой версии протокола TLS 1.3 сделает транспортный уровень более безопасным, а также потенциально увеличит скорость за счет перестроения архитектуры TLS версии 1.3. Для отечественной реализации TLS в ядре Linux были взяты за основу рекомендации по стандартизации «Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.3)» и исследованы методы и подходы существующей реализации TLS сокетов ядра Linux.Данная реализация соответствует RFC и рекомендациям по ТК26, позволит безопасно обмениваться информацией и ускорить время проведения криптографических операций за счет используемого в TLS 1.3 режима шифрования с аутентификацией и сокращении копирований из/впространство пользователя, осуществляющих дополнительную нагрузку на ЦП.

• TLS is a widely used protocol used to protect TCP connections on the modern Internet. TLS is also required by HTTP /2, the latest web standard. Implementation of this protocol in the Linux kernel will reduce the load on the processor and increase the encryption speed, and using the new version of the TLS 1.3 protocol will make the transport layer more secure and potentially increase the speed by rebuilding the TLS version 1.3 architecture. For the domestic implementation of TLS in the Linux kernel, the standardization recommendations «Use of Russian cryptographic algorithms in the transport layer security protocol (TLS 1.3)» were taken as a basis and the methods and approaches of the existing implementation of TLS sockets of the Linux kernel were investigated. This implementation complies with the RFC and recommendations of TK26, it will allow you to safely exchange information and speed up the time of cryptographic operations due to the encryption mode used in TLS 1.3 with authentication and reduction of copying from / to the user space, which carry additional load on the CPU. сокет sendfile record протокол


Оглавление

• Введение
• Глава 1. TLS сокеты в ядре Linux
• Идея TLS сокетов
• Подходы к реализации TLS сокетов
• Глава 2. Протокол TLS 1.3
• Handshake
• Протокол Record
• Алгоритм работы режима MGM
• Реализация MGM в ядре Linux
• Глава 3. KTLS ядра Linux
• Основные моменты реализации KTLS
• Глава 4. Реализация RecordTLS 1.3 согласно проекту ТК26
• Глава 5. Экспериментальная оценка результатов
• Полученные результаты
• Список литературы


Введение

Протокол защиты транспортного уровня (TLS) является строительным блоком для безопасности транспорта в современном Интернете. Последняя версия протокола передачи гипертекста (HTTP/2) предписывает использование протокола TLS. Он обеспечивает как шифрование, так и аутентификацию TCP-соединений, но требует затрат на процессор. TLS состоит из двух основных операций: сначала выполняется согласование TLS для согласования алгоритма и ключей безопасного симметричного шифрования, а затем выполняется симметричное шифрование TLS для записей TLS. TLS имеет несколько типов записей, включая записи данных и контрольные записи.

Протокол TLS на данный момент имеет 4 версии. Для исследования и реализации была взята последняя версия TLS - TLS 1.3. Современная версия TLS 1.3 имеет существенные отличия от всех предыдущих версий TLS. В частности, радикально изменена логика установления соединения, а сам протокол стал архитектурно стройнее. Есть причины предполагать, что в общемировом Интернете TLS 1.3 быстро станет основной версией. На момент написания данной работы поддержку TLS 1.3 для веба предоставляют Google, Facebook, а также последние версии браузеровChrome и Firefox.

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

Так как целью данной работы является исследование возможности реализации отечественного протокола TLS 1.3 в ядре Linux, за основу построения архитектуры протокола был взят документ проекта ТК26 - «Рекомендации по стандартизации: использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.3)». Принципиальное различие протокола Record в отечественном варианте является использование режима шифрования с аутентификацией MGM.

В 2017 году был представлен отечественный режим аутентифицированного шифрования - MultilinearGaloisMode, соответствующий известным международным стандартам и рассматриваемый для включения в стандарты шифрования РФ. Данный режим является AEAD-режимом и обеспечивает конфиденциальность и имитозащиту сообщений. При этом сообщения могут состоять из двух частей. Часть сообщения, конфиденциальность и имитозащиту которой требуется обеспечить, называется открытым текстом. Другая часть сообщения содержит дополнительные аутентифицируемые данные AAD, которые не подлежат шифрованию, но требуют имитозащиты.



Глава 1. TLS сокеты в ядре Linux

Идея TLS сокетов

Безопасность транспортного уровня становится все более актуальной в современном Интернете. К сожалению, это приводит к значительным потерям производительности процессора. С данной проблемой столкнулась компанияNetflix при включении TLSдля видео-объектовв OCA- OpenConnectAppliances - приложение на основе на FreeBSD, которое предоставляет фильмы подписчикам Netflix. Учитывая высокие вычислительные затраты на обслуживание TLS, Netflix запустила небольшой проект, чтобы выяснить, какое влияние TLS оказывает на его продукты и каким образом можно сократить расходы на TLS [10].

Рис.1.1.

Традиционный веб-сервер, получив запрос клиента на объект, хранящийся на локальном диске, выделит локальный буфер для данных объекта с помощью библиотечного вызова malloc(), а затем выполнит системный вызов read() для извлечения и копирования содержимого объекта в буфер, и, наконец, выполнит системный вызов write() для копирования содержимого буфера в буфер сокета, который затем передается клиенту. Этот процесс включает в себя много копирований данных, обрабатываемых непосредственно ЦП, а также некоторое связанное с этим использование кеш-памяти ЦП и пропускной способности памяти. Данная модель потока данныххорошо работает для нужд с низкой пропускной способностью, но перегружает процессор для приложений с высокой пропускной способностью. Первые тесты в процессе разработки ОСА показали, что сервер, как правило, не может обслуживать более 4-5 Гбит полосы пропускания в соответствии с этой моделью. Со временем более совершенное оборудование принесло с собой улучшения в производительности обслуживания, но простота этой модели продолжает снижать потенциальную производительность.

Nginx представил новое решение, которое использует системный вызов sendfile() для выполнения потока данных нулевого копирования с диска на сокет. Когда приходит клиентский запрос, Nginx выполняет вызов sendfile() как для файлового дескриптора, так и для дескриптора сокета. Затем ядро извлекает объект в свою подсистему кэширования страниц виртуальной памяти и передает набор указателей на эти страницы кэша в буфер сокетов для передачи. Никаких дополнительных буферов или копий данных не требуется, и данные никогда не покидают адресное пространство памяти ядра. Это освобождает ЦП от бремени создания копий, значительно снижает нагрузку на кэш-память и ресурсы шины, устраняет системный вызов и сокращает конвейер кода для пути данных. Nginx улучшил эту модель, используя подсистему AIO для асинхронного заполнения кэша виртуальной машины чтением с диска перед выполнением вызова sendfile(). Это позволило избежать принудительного выполнения потока Nginx на дисковых операциях ввода-вывода синхронно с помощью sendfile(), но это увеличило сложность потока данных и риск того, что данные могут быть сброшены из кэша, прежде чем они могут быть помещены в сокет. Даже при такой сложности экономия позволила повысить производительность на одном и том же оборудовании на 20% и более.

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

Рис.1.2.

Функциональность TLS традиционно выполнялась в пространстве приложения как библиотека для веб-сервера (Рис.1.2). Когда веб-сервер подготавливает объекты для передачи клиенту, они передаются в библиотеку TLS для шифрования, после шифрования данных библиотека TLS записывает их в дескриптор сокета. Наряду с этой функцией массового шифрования библиотека TLS также выполняет настройку сеансов, управление ими, а также генерацию и обмен ключами. Эта схема хорошо вписывается в традиционную простую модель потока данных, представленную выше. К сожалению, это несовместимо с моделью sendfile [12], поскольку эта модель не позволяет данным поступать в область приложения.



Рис.1.3.

Чтобы сохранить преимущества модели sendfile, а также реализовать функциональность TLS, мы разработали гибридную схему TLS, при которой управление сеансами будет оставаться в пространстве приложения, но массовое шифрование будет вставлено в конвейер данных sendfile в ядре (см. Рис.1.3). Сообщения о согласовании сеанса TLS и обмене ключами передаются из Nginx в библиотеку TLS, а состояние сеанса находится в пространстве приложения библиотеки. Как только сеансы TLS установлены, и соответствующие ключи генерируются и обмениваются с клиентом, эти ключи становятся связанными с коммуникационным сокетом для клиента и совместно используются ядром. Для сокетов, помеченных для шифрования, массовое шифрование TLS происходит через обход через OpenCryptoFramework, когда страницы данных добавляются в буфер сокетов. Для сеансов, которым требуются службы шифрования, недоступные в OpenCryptoFramework, Nginx возвращается к традиционной модели чтения + отправки и выполняет шифрование в пространстве приложения. В конечном итоге это позволяет модульно выбирать протоколы и алгоритмы шифрования, которые наилучшим образом соответствуют требованиям клиента и доступным ресурсам сервера.

Параллельно с Netflix данную проблему исследовал Facebook. Facebook также обратил внимание на загрузку процессора из-за копирований из/в пространство пользователя. Чтобы устранить накладные расходы из-за копий, Facebook исследовал использование системных вызовов sendfile() или splice()для отправки статического контента непосредственно с диска в сеть, без каких-либо копий через пространство пользователя.

Исследования Facebook показали, что из-за шифрования на копирование из/в пространство пользователя затрачивается примерно 2% общего ЦП, и примерно 10% общего ЦП расходуется на процедуры шифрования и дешифрования на машинах, интенсивно использующих TLS [9].

ПроектNetflix предложил, чтобы все обмены ключами и обычная обработка SSL происходили как обычно. Когда ключи будут готовы, пусть библиотека TLS отправит их ядру и позволит ядру выполнить часть шифрования, в то время как все остальные части TLS будут продолжать выполняться библиотекой TLS. Библиотека TLS будет продолжать формировать свои сообщения и отправлять в рамку, но не зашифрованные сообщения ядру. Затем ядро будет использовать ключи, данные ранее, для шифрования и отправки данных. Для системного вызова sendfile() ядро добавило бы как уровень кадрирования, так и шифрование. Это позволило бы библиотеке TLS выполнять всю обработку ключей и состояния TLS и обрабатывать повторный ввод ключа, если одна из сторон инициирует эту процедуру и все же позволит системному вызову sendfile() работать.

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



Подходы к реализации TLS сокетов

Facebook в сотрудничестве с RedHat внедрил сокет TLS для ядра Linux. Чтобы избежать ненужных сложностей в ядре, установление соединения TLS хранится в пользовательском пространстве. Полное соединение TLS с использованием сокета выполняется по следующей схеме:

1. Вызвать connect() или accept() для стандартного дескриптора файла TCP.

2. Библиотека пользовательского пространства TLS используется для завершения рукопожатия. Было протестировано как с GnuTLS, так и с OpenSSL.

3. Создать новый дескриптор файла сокета KTLS.

4. Извлечь векторы инициализации TLS (IV), сеансовые ключи и идентификаторы последовательности из библиотеки TLS. С помощью setsockopt() на KTLS fd передать их ядру.

5. Использовать стандартные системные вызовы read(), write(), sendfile() и splice() для KTLS fd.

После получения TLS сообщения TLS (управляющего сообщения, не содержащего прикладные данные) сокет KTLS возвращает ошибку, и сообщение вместо этого остается в исходном сокете TCP. Сокет KTLS автоматически отключается. Передача управления обратно в исходный зашифрованный выполняется путем вызова getsockopt() для получения текущих порядковых номеров и вставки их в библиотеку TLS.

Пример:

if (read(...) < 0){

getsockopt(tls_fd, AF_KTLS, KTLS_GET_IV_RECV, ssl_->s3->

read_sequence, &optlen);

/* Similar for IV_SEND */

SSL_read(tcp_fd, ...);

}

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



Глава 2. Протокол TLS 1.3

Данная глава посвящена описанию работы протокола TLS. На данный момент существует 4 версии протокола, однако при рассмотрении будем акцентировать свое внимание на версии TLS 1.3, так как она является самой последней на момент написания данной работы (RFC8446 выпущен в 2018 году). Затем будет рассмотрена версия 1.3 отечественного проекта.

TLS 1.3 очень сильно отличается от своих предшественников, в протоколе переработаны сами основы обеспечения защиты передаваемых данных. Согласно RFC 8446 -TLS1.3 можно разделить еще на два составляющих протокола: Handshake (русский аналог - рукопожатие), отвечающий за установление защищенного соединения, и Record (русский аналог - записи), выполняющий обмен данными.

По соображениям, отмеченным в главе 1, этап установления соединения (Handshake) остается в пространстве пользователя и в реализацию TLS в ядре Linux входить не будет. Однако, чтобы не оставлять без внимания важные изменения TLS 1.3, рассмотрим основные моменты этапы рукопожатия дляцелостной картины работы протокола TLS 1.3.

Handshake

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

Handshake можно условно разделить на три этапа:

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

К данному этапу относятся ClientHello, ServerHello, их расширения (обозначения «+» на схеме). Результатом первого этапа является первоначальное значение секрета (handshake_traffic_secret), с помощью которого стороны получают первый набор симметричных ключей. Данные ключи используются для шифрования сообщений Handshake, начиная с сообщения EncryptedExtensions со стороны сервера. То есть серверный сертификат передается в зашифрованном виде, и прослушивающая сторона теперь не может определить, что было предоставлено сервером, настоящая длина сообщений может быть скрыта дополнительными нулями.

uint16 ProtocolVersion;

opaque Random[32];

uint8CipherSuite[2]; /* Cryptographic suite selector */

struct {

ProtocolVersionlegacy_version = 0x0303; /* TLS v1.2 */

Random random;

opaquelegacy_session_id<0..32>;

CipherSuitecipher_suites<2..2^16-2>;

opaquelegacy_compression_methods<1..2^8-1>;

Extension extensions<8..2^16-1>;

} ClientHello;

legacy_version - поле для согласования версии протокола, не используется в версии 1.3, по умолчанию имеет значение 0x303, что означает версию 1.2. Определить, что установление соединения происходит по версии 1.3, сервер может по наличию расширения SupportedVersions (0x304). Таким образом, если сервер еще не поддерживает версию 1.3, будет использоваться TLS 1.2.

random - состоит из 32 байт, сгенерированных генератором случайных чисел.

2. Определение дополнительных параметров соединения со стороны сервера - включает в себя серверные сообщения EncryptedExtensions, а также CertificateRequest, если необходима аутентификация клиента.

3. Аутентификация севера и клиента.

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

В TLS 1.3 используемая версия протокола определяется по-новому. Поле, которое отвечало за номер версии, сохранено в TLS 1.3 как историческое и имеет фиксированное значение 0x0303 (версия 1.2) для совместимости с младшими версиями. Использование версии 1.3 определено в специальном расширении supported_versions. в ClientHello, supported_versions содержит список версий протокола, поддерживаемых клиентом. Сервер передаёт в этом расширении номер выбранной версии.

В версии TLS 1.3 сообщение от сервера Finished приходит в первом же ответе сервера, соответственно, клиент может сразу переходить к отправке полезной нагрузки, не дожидаясь ещё одного пакета от сервера. Это экономит время, необходимое для доставки пакетов от клиента к серверу и обратно. Для сервисов, устанавливающих большое количество TLSсоединений в секунду, уменьшение задержки в каждом сеансе на 30-100 мс, соответствующих времени передачи данных, очень существенно. Такая экономия ресурсов ускоряет работу сервисадля всех клиентов, а не только для поддерживающих TLS 1.3. Схема Handshake согласно RFC 8446:



Рис.2.1.

Протокол Record

ServerHello, при штатном ходе установления соединения, является единственным сообщением сервера, которое передаётся в незашифрованном виде. Уже следующее сообщение - EncryptedExtensions - зашифровано. Все зашифрованные сообщения в TLS 1.3 передаются строго внутри TLS-записей с типом ApplicationData (код 0x17). "Настоящий" тип записи -например, Handshake (0x16) - передаётся внутри защищённой записи, и доступен только после того, как эта запись успешно расшифрована.

Полезные данные внутри записи зашифрованы действующим шифронабором, защищены AEAD шифром. Часть параметров передаётся в открытом виде: тип записи, версия, длина данных и др. В TLS 1.3 открытый заголовок зафиксирован в качестве исторического: то есть, любая защищённая запись TLS 1.3 имеет значение поля версии 0x0303, что соответствует TLS 1.2, однако на деле в протоколе TLS1.3 данное поле не используется.

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

Принятые с верхнего уровня данные разбиваются протоколом Record на фрагменты, помещаемые в поля TLSPlaintext.fragment. Если состояние соединения не подразумевает защиты данных, каждая запись задается структурой TLSPlaintext. Если состояние соединения подразумевает защиту данных, каждая запись задается структурой TLSCiphertext.

Рис.2.2.

Функции защиты записей переводят структуру TLSPlaintext в структуру TLSCiphertext. В TLS 1.3, в отличие от предыдущих версий TLS, все шифры моделируются как «Аутентифицированное шифрование с ассоциированными данными» (AEAD) [RFC5116]. Функции AEAD обеспечивают унифицированную операцию шифрования и аутентификации, которая превращает открытый текст в зашифрованный аутентифицированный текст и обратно. Каждая зашифрованная запись состоит из заголовка открытого текста, за которым следует зашифрованное тело, которое само содержит тип и дополнительное заполнение нулями.

struct {

ContentTypeopaque_type = application_data; /* 23 */

ProtocolVersionlegacy_record_version = 0x0303; /* TLS v1.2 */

uint16 length;

opaqueencrypted_record[TLSCiphertext.length];

} TLSCiphertext;

opaque_type: всегда устанавливается в значение 23 (application_data) для внешней совместимости с промежуточными модулями, привыкшими к анализу предыдущих версий TLS. Фактический тип содержимого записи находится в TLSInnerPlaintext.type после расшифровки.

legacy_record_version: полеlegacy_record_versionвсегда 0x0303.В TLS 1.3 TLSCiphertext не генерируется до тех пор, пока не будет согласовано TLS 1.3, поэтому не существует исторических проблем совместимости, где могут быть получены другие значения. Протокол Handshake, включая сообщения ClientHello и ServerHello, аутентифицирует версию протокола, поэтому это значение является избыточным.

length: длина (в байтах) TLSCiphertext.encrypted_record, который представляет собой сумму длин содержимого и заполнения, плюс один байт для внутреннего типа содержимого плюс любое расширение, добавленное алгоритмом AEAD. Длина не должна превышать байт. Хост, который получает запись, превышающую эту длину, должен разорвать соединение с предупреждением «record_overflow».

encrypted_record: AEAD-зашифрованная форма сериализованной структуры TLSInnerPlaintext.

Алгоритмы AEAD принимают в качестве входных данных один ключ, одноразовый номер, открытый текст и «дополнительные данные», которые должны быть включены в проверку аутентификации. Ключом является либо client_write_key, либо server_write_key, одноразовый номер получается из порядкового номера и client_write_iv или server_write_iv, а входные дополнительные данные - заголовок записи.

additional_data = TLSCiphertext.opaque_type ||

TLSCiphertext.legacy_record_version ||

TLSCiphertext.length

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

Выходные данныеалгоритма AEAD состоят из зашифрованного текста, полученного в результате операции шифрования AEAD. Длина открытого текста больше соответствующей TLSPlaintext.length из-за включения TLSInnerPlaintext.type и любого дополнения. Длина результатаAEAD, как правило, будет больше, чем открытый текст, но на величину, которая зависит от алгоритма AEAD.

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

AEADEncrypted =

AEAD-Encrypt(write_key, nonce, additional_data, plaintext)

Полеencrypted_recordвTLSCiphertextимеетзначениеAEADEncrypted.

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

plaintext of encrypted_record =

AEAD-Decrypt(peer_write_key, nonce,

additional_data, AEADEncrypted)

Если дешифрование не удалась, получатель должен разорвать соединение с предупреждением «bad_record_mac».

Алгоритм AEAD, используемый в TLS 1.3, не должен создавать расширение, превышающее 255 октетов. Конечный узел, который получает запись от своего партнера с TLSCiphertext.length больше, чем октетов, должен разорвать соединение с предупреждением «record_overflow». Этот предел получается из максимальной длины TLSInnerPlaintext байт + 1 байт для ContentType + максимальное расширение AEAD 255 байт.

Одноразовый номер для каждой записи

64-битный порядковый номер используется отдельно для чтения и записи. Соответствующий порядковый номер увеличивается на единицу после чтения или записи каждой записиRecord. В начале соединения номер обнуляется, а также всякий раз, когда ключ изменяется; первая запись, передаваемая под конкретным ключом трафика, должна использовать порядковый номер 0.

Поскольку размер порядковых номеров 64-битный, они не должны иметь обертку. Если реализация TLS использует обертку для порядкового номера, она должна либо изменить ключ, либо завершить соединение. Каждый алгоритм AEAD будет указывать диапазон возможных длин для одноразового номера для каждой записи, от N_MIN до N_MAX байтов ввода [RFC5116]. Длина одноразового номера TLS для каждой записи (iv_length) устанавливается в 8 байтов и N_MIN для алгоритма AEAD. Алгоритм AEAD, где N_MAX меньше 8 байт, не должен использоваться. Одноразовый номер для записи для конструкции AEAD формируется следующим образом:

1. 64-битный порядковый номер записи кодируется в сетевом байтовом порядке и дополняется слева нулями до необходимой длины iv_length.

2. Для сформированного таким образом номера используется XOR со статическим client_write_iv или server_write_iv (в зависимости от роли).

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

Эта конструкция отличается от конструкции в TLS 1.2, в которой указан явно явный одноразовый номер.

Дополнительное заполнение записи.

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

При создании записи TLSCiphertext реализации могут выбрать заполнение. Запись без заполнения -- это просто запись с нулевой длиной заполнения. Заполнение (строка байтов с нулевым значением) добавляется к полю ContentType перед шифрованием. Реализации должнызаполнить все октеты нулями перед шифрованием.

Записи, содержащие данные приложения, могут иметь нулевую длину TLSInnerPlaintext.content, если этого пожелает отправитель. Это позволяет генерировать трафик правдоподобного размера в ситуациях, когда присутствие или отсутствие активности может быть чувствительным. Реализации не должны отправлять записи, содержащиеHandshake и Alert с нулевой длиной TLSInnerPlaintext.content; если такое сообщение получено, принимающая стороны реализациидолжна разорвать соединение с предупреждением «непредвиденное сообщение». Отправленное заполнение автоматически проверяется механизмом защиты записей; после успешного дешифрования TLSCiphertext.encrypted_record принимающая сторона поле от конца к началу, пока не найдет ненулевой байт. Этот ненулевой байт является типом содержимого сообщения. Эта схема заполнения была выбрана потому, что она позволяет заполнять любую зашифрованную запись TLS произвольным размером (от нуля до пределов размера записи TLS) без введения новых типов контента. Конструкция также предусматривает использование нулевых октетов заполнения, что позволяет быстро обнаруживать ошибки заполнения.

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

Наличие заполнения не меняет общих ограничений размера записи: полный кодированный TLSInnerPlaintextне должен превышать байт. Если максимальная длина фрагмента уменьшается - как, например, расширением record_size_limit из [RFC8449], - то уменьшенный предел применяется к целой записи, включая тип содержимого и заполнение.

Выбор политики заполнения, которая предлагает, когда и сколько дополнять, является сложной темой. Если протокол прикладного уровня поверх TLS имеет свое собственное заполнение, может оказаться предпочтительным заполнить записи TLS прикладных данных на более высоком уровне. Однако заполнение для зашифрованных записей Handshake или Alert должно обрабатываться на уровне TLS.

Ограничения на использование ключа

Существуют криптографические ограничения на количество открытого текста, который можно безопасно зашифровать с помощью данного набора ключей. [AEAD-LIMITS] обеспечивает анализ этих пределов в предположении, что базовый примитив (AES или ChaCha20) не имеет слабых мест.

Алгоритм работы режима MGM

Стандарт RFCTLS 1.3 предписывает использование AEAD-шифра в качестве шифрования записей и имитозащиты. Для отечественной реализации согласно проекту ТК 26 необходимо использовать отечественный алгоритм шифрования с аутентификацией MGM - MultilinearGaloisMode.

Зашифрование осуществляется с помощью функции MGM-Encrypt.

Входные параметры:

1. Ключ зашифрования

2. Уникальный вектор

3. Дополнительные аутентифицируемые данные в виде , где .

4. Открытый текст в виде , где .

Длины и удовлетворяют: .

Процесс зашифрования:

1.

2. - операция +1 в кольце

3.

4. , где .

5. Дополнение последних блоков ),

Выработка имитовставки.

6.

7.

8.

9.

Возвращаемые значения функции MGM-Encrypt

1. Уникальный вектор

2. Дополнительные аутентифицируемые данные

3. Шифртекст

4. Имитовставка

Расшифрование осуществляет функция MGM-Decrypt.

1. Дополнение последних блоков ),

Выработка значения

2.

3.

4.

5.

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

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

6.

7. - операция +1 в кольце

8.

9.

Возвращаемые значения:

1. Дополнительные аутентифицируемые данные

2. Открытый текст

Реализация MGM в ядре Linux

В качестве реализации MGM в ядре была взята дипломная работа В. Снигерева, которая рассматривает возможности реализации режима MGM в ядроLinux. Однако реализация, представленная в работе, поддерживается CryptoAPILinux версии ядра 4.x.x. Так как на данный момент используется версия ядра 5.x.x, исходный код реализации MGMбыл модифицирован для совместимости с новым ядром. Далее будут рассмотрены основные моменты реализации MGM для версии ядра Linux 5.x.x.

Реализация MGM в ядре состоит из трех отдельных модулей:

1. Модуль, реализующий шифрование в режиме счетчика в соответствии с алгоритмом шифрования MGM;

2. Модуль, реализующий выработку имитовставки;

3. Модуль, агрегирующий в себе два вышеупомянутых и предоставляющий пользователю Crypto API интерфейсы для работы с режимом MGM.

1. Модуль шифрования MGM

Данный модуль называется mgmctr. Рассмотрим основные функции модуля шифрования MGM.

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

Структура crypto_mgmcrt_template - содержит имя шаблона и функции для создания и удаления:

staticstructcrypto_templatecrypto_mgmctr_tmpl = {

.name = "mgmctr",

.alloc = crypto_mgmctr_alloc,

.free = crypto_mgmctr_free,

.module = THIS_MODULE,

};

Функцияcrypto_mgmcrt_alloc()

staticstructcrypto_instance *crypto_mgmctr_alloc(structrtattr **tb)

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

Функцияcrypto_mgmcrt_init_tfm()

staticintcrypto_mgmctr_init_tfm(structcrypto_tfm *tfm)

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

Функцияcrypto_mgmctr_setkey()

staticintcrypto_mgmctr_setkey(structcrypto_tfm *parent, const u8 *key, unsigned intkeylen)

Устанавливает ключ для последующего шифрования.

Функцияcrypto_mgmcrt_crypt()

staticintcrypto_mgmctr_crypt(structblkcipher_desc *desc,

structscatterlist *dst, structscatterlist *src,

unsignedintnbytes)

Реализуеталгоритмшифрования:

1. Преобразование инициализирующего вектора;

2. Шифрования полных блоков открытого текста с помощью функции crypto_mgmctr_crypt_segment();

3. Шифрования последнего неполного блока с помощью функции crypto_mgmcrt_crypt_final().

2. Модуль выработки имитовставки в соответствии с алгоритмом MGM.

Заполнение структуры шаблона криптографического преобразования mgmhash:

Структура crypto_mgmhash_template

staticstructcrypto_templatecrypto_mgmhash_tmpl = {

.name = "mgmhash",

.alloc = crypto_mgmhash_alloc,

.free = crypto_mgmhash_free,

.module = THIS_MODULE,

};

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

Функцияcrypto_mgmhash_init_tfm()

staticintcrypto_mgmhash_init_tfm(structcrypto_tfm *tfm)

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

Функцияcrypto_mgmhash_crypt()

staticintcrypto_mgmhash_crypt(structblkcipher_desc *desc,

structscatterlist *dst, structscatterlist *src,

unsignedintnbytes)

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

1. Преобразование инициализационного вектора в соответствии с алгоритмом;

2. Выработка промежуточного значения имитовставки из полных блоков присоединенных данных;

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

4. Выработка промежуточного значения имитовставки из полных блоков шифртекста;

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

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

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

3. Основной модульmgm, реализующий интерфейсы аутентифицированного шифрования MGM, предоставляемые пользователям Crypto API.

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

Структураcrypto_mgm_tmpl:

staticstructcrypto_templatecrypto_mgm_tmpl = {

.name = "mgm",

.create = crypto_mgm_create,

.module = THIS_MODULE,

};

В функции crypto_mgm_create аналогично инициализируется структура типа crypto_instance, также, в отличие от предыдущих, данное преобразование объединяет в себе алгоритмы шифрования и выработки имитовставки, в данной функции также инициализируются алгоритмы шифрования и выработки имитовставки, которые сохраняются в приватные области данных MGM:

structcrypto_mgm_ctx {

structcrypto_skcipher *ctr;

structcrypto_skcipher *hash;

structskcipher_requestskreq;

};

Функцияcrypto_mgm_setkey()

staticintcrypto_mgm_setkey(structcrypto_aead *aead, const u8 *key, unsigned intkeylen)

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

Функцияcrypto_mgm_setauthsize()

staticintcrypto_mgm_setauthsize(structcrypto_aead *tfm, unsigned intauthsize)

Проверяет и устанавливает длину имитовставки.

Функцияcrypto_mgm_encrypt()

staticintcrypto_mgm_encrypt(structaead_request *req)

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

Таким образом данный модуль соединяет в себе работу режима аутентифицированного шифрования MGM и предоставляет пользователю указанные ранее интерфейсы в соответствии с интерфейсами AEAD - преобразований в Crypto API.



Глава 3. KTLS ядраLinux.

Данная глава посвящена исследованию TLS сокетов ядра Linux.

Для того чтобы перенести TLS шифрование в ядро, необходимо сначала создать TCP/UDP сокет и установить TLS сокет поверх TCP (TLSULP - UpperLayerProtocol):

sock= socket(AF_INET, SOCK_STREAM, 0);

setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));

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

structtls_crypto_info {

unsignedshort version;

unsignedshortcipher_type;

};

struct tls12_crypto_info_aes_gcm_128 {

structtls_crypto_info info;

unsignedchar iv[TLS_CIPHER_AES_GCM_128_IV_SIZE];

unsignedchar key[TLS_CIPHER_AES_GCM_128_KEY_SIZE];

unsignedchar salt[TLS_CIPHER_AES_GCM_128_SALT_SIZE];

unsignedcharrec_seq[TLS_CIPHER_AES_GCM_128_REC_SEQ_SIZE];

};

struct tls12_crypto_info_aes_gcm_128 crypto_info;

crypto_info.info.version= TLS_1_2_VERSION;

crypto_info.info.cipher_type= TLS_CIPHER_AES_GCM_128;

memcpy(crypto_info.iv, iv_write, TLS_CIPHER_AES_GCM_128_IV_SIZE);

memcpy(crypto_info.rec_seq, seq_number_write,

TLS_CIPHER_AES_GCM_128_REC_SEQ_SIZE);

memcpy(crypto_info.key, cipher_key_write, TLS_CIPHER_AES_GCM_128_KEY_SIZE);

memcpy(crypto_info.salt, implicit_iv_write, TLS_CIPHER_AES_GCM_128_SALT_SIZE);

Здесь в качестве примера указан AEAD шифр AES 128 GCM - единственный поддерживаемый в TLS сокетах ядра Linuxна данный момент.

Передача и прием реализованы отдельно, но их настройка идентичная с использованием структур TLS_TX и TLS_RX, соответственно.

setsockopt(sock, SOL_TLS, TLS_TX, &crypto_info, sizeof(crypto_info));

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

constchar*msg= "helloworld\n";

send(sock, msg, strlen(msg));

Данные, отправленные с помощью вызова send(), напрямую шифруются из буфера пользовательского пространства в буфер пространства ядро, если это возможно. Системный вызов sendfile() позволяет отправить данные длиной максимум 2^14.

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

Операции TLS в ядре Linux

Ядро Linux обеспечивает инфраструктуру разгрузки TLS-соединения. Как только соединение TCP установлено, пользовательское пространство может включить протокол верхнего уровня TLS (ULP) и установить защищенное соединение.

KTLS может работать в трех режимах:

1. Программный режим шифрования (TLS_SW) - процессор обрабатывает криптографию. В большинстве базовых случаев могут использоваться только криптографические преобразования, синхронные с ЦП, но в зависимости от контекста вызова ЦП может использовать асинхронные криптографические ускорители. Использование ускорителей вносит дополнительную задержку при чтении сокетов (расшифрование начинается только после выполнения системного вызова чтения) и дополнительную нагрузку ввода-вывода в системе.

2. Режим разгрузки NIC на основе пакетов (TLS_HW) - NIC обрабатывает шифрование для каждого пакета в отдельности, если пакеты поступают последовательно. Этот режим лучше всего интегрируется со стеком ядра (ethtool с флагамиtls-hw-tx-offload и tls-hw-rx-offload).

3. Режим полной разгрузки NIC TCP (TLS_HW_RECORD) - режим работы, при котором драйвер и встроенное ПО NIC заменяют сетевой стек ядра собственной обработкой TCP, его нельзя использовать в производственных средах, использующих сетевой стек Linux, например, любые возможности межсетевого экрана или QoS и планирование пакетов (ethtool с флагомtls-hw-record).

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

В дальнейшем остановимся на программном режиме реализации KTLS.

Передача данных.

На высоком уровне пользовательские запросы на запись превращаются в разбросанные области памяти. TLS перехватывает их, добавляет кадрирование записей, выполняет шифрование (в режиме TLS_SW) и затем передает модифицированный scatter list на уровень TCP. С этого момента TCP стэк работает как обычно.

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

Получение данных.

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

Рис.3.1.

Основные моменты реализации KTLS

Реализация протокола RecordTLS в ядре Linux состоит из следующих исходных файлов:

include/uapi/linux/tls.h - определение используемых в реализации TLS констант и структур, используемых для AEAD-шифров.

include/net/tls.h - основной заголовочный файл с описаниями и определениями структур и функций.

net/tls/tls_device.c, net/tls/tls_device_fallback.c - содержат основные функции для аппаратной разгрузки TLS на сетевом и канальном уровнях стэка.

net/tls/tls_main.c, net/tls/tls_sw.c - данные файлы относятся к программной реализации KTLS и она будет рассмотрена более подробна ниже.

Начнем с описания основных структур.

Структураtls_rec

structtls_rec {

structlist_head list;

inttx_ready;

inttx_flags;

intinplace_crypto;

structsk_msgmsg_plaintext;

structsk_msgmsg_encrypted;

/* AAD | msg_plaintext.sg.data | sg_tag */

structscatterlistsg_aead_in[2];

/* AAD | msg_encrypted.sg.data (data contains overhead for hdr& iv & tag) */

structscatterlistsg_aead_out[2];

char content_type;

structscatterlistsg_content_type;

charaad_space[TLS_AAD_SPACE_SIZE];

u8 iv_data[MAX_IV_SIZE];

structaead_requestaead_req;

u8 aead_req_ctx[];

};

Записи TLS хранятсявструктуреstructtls_rec. Структура хранит страницы памяти, выделенные или сопоставленные для каждой записи TLS. После шифрования записи хранятся в связанном списке.

Структуры для контрольных сообщений и отложенных заданий.

structtls_msg {

structstrp_msgrxm;

u8 control;

};

structtx_work {

structdelayed_work work;

struct sock *sk;

};

Структура для контекста при отправке tls данных.

structtls_sw_context_tx {

structcrypto_aead *aead_send;//структурадля AEAD-алгоритма

structcrypto_waitasync_wait;

structtx_worktx_work;

structtls_rec *open_rec;

structlist_headtx_list;

atomic_tencrypt_pending;

intasync_notify;

intasync_capable;

#define BIT_TX_SCHEDULED0

#define BIT_TX_CLOSING1

unsigned long tx_bitmask;

};

structcrypto_wait - Вспомогательная структура для ожидания завершения асинхронных операций шифрования

structtls_rec - указатель на структуру для хранения TLS записи

structlist_head - структура для хранения TLS записей в связном списке

atomic_tencrypt_pending

atomic_tencrypt_pending

intasync_capable

unsigned long tx_bitmask

Структура для получения tls данных:

structtls_sw_context_rx {

structcrypto_aead *aead_recv;

structcrypto_waitasync_wait;

structstrparserstrp;

structsk_buff_headrx_list;/* list of decrypted 'data' records */

void (*saved_data_ready)(struct sock *sk);

structsk_buff *recv_pkt;

u8 control;

intasync_capable;

bool decrypted;

atomic_tdecrypt_pending;

boolasync_notify;

};

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

structsk_buff_head - структура для списка зашифрованных TLS записей (/include/linux/skbuff.h)

void (*saved_data_ready)(structsock *sk) - указатель на функцию проверки готовности всех TLS записей для получения

structsk_buff *recv_pkt - указатель на сокет для буфера данных для получения

Структура, содержащая необходимую информацию о TLS записи:

structtls_record_info {

structlist_head list;

u32 end_seq;

intlen;

intnum_frags;

skb_frag_t frags[MAX_SKB_FRAGS];//массивструктурskb_frag_struct (хранениестраниц (/include/linux/skbuff.h))

};

Структура для хранения крипто-контекста TLS

union tls_crypto_context {

structtls_crypto_info info;

union {

struct tls12_crypto_info_aes_gcm_128 aes_gcm_128;

struct tls12_crypto_info_aes_gcm_256 aes_gcm_256;

};

};

Структура для хранения информации о версии протокола TLS

structtls_prot_info {

u16 version;

u16 cipher_type;

u16 prepend_size;

u16 tag_size;

u16 overhead_size;

u16 iv_size;

u16 salt_size;

u16 rec_seq_size;

u16 aad_size;

u16 tail_size;

};

Общая структура для хранения контекста TLS (отправка и получение):

structtls_context {

/* read-only cache line */

structtls_prot_infoprot_info;

u8 tx_conf:3;

u8 rx_conf:3;

int (*push_pending_record)(struct sock *sk, int flags);

void (*sk_write_space)(struct sock *sk);

void *priv_ctx_tx;

void *priv_ctx_rx;

structnet_device *netdev;

/* rw cache line */

structcipher_contexttx;

structcipher_contextrx;

structscatterlist *partially_sent_record;

u16 partially_sent_offset;

bool in_tcp_sendpages;

bool pending_open_record_frags;

structmutextx_lock; /* protects partially_sent_* fields and

* per-type TX fields

*/unsigned long flags;

/* cache cold stuff */

struct proto *sk_proto;

void (*sk_destruct)(struct sock *sk);

union tls_crypto_contextcrypto_send;

union tls_crypto_contextcrypto_recv;

structlist_head list;

refcount_trefcount;// счетчикссылок

structrcu_headrcu; //структура-списокдля RCU - механизмсинхронизации read-copy-update

};

Основные взаимодействия KTLS ядра Linux

Изучим, как построено взаимодействие KTLS по исходному фалу /net/tls/tls_sw.c.

При установлении типа сокета TCP_ULP используется вызов setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));

Затем можно создать TLS сокет на отправку или получение с помощью следующего вызова:setsockopt(sock, SOL_TLS, TLS_TX, &crypto_info, sizeof(crypto_info)), передав согласованный криптонабор.

Создание TLS сокета:

staticinttls_setsockopt(structsock*sk,intlevel,intoptname,char__user*optval,unsignedintoptlen)

{

structtls_context*ctx=tls_get_ctx(sk);

if(level!=SOL_TLS)

returnctx->setsockopt(sk,level,optname,optval,optlen);

returndo_tls_setsockopt(sk,optname,optval,optlen);

}

В теле данной функции происходит инициализация сокета TLS (staticinttls_init(structsock*sk)- выделение памяти) и установка параметров TLS сокета:

staticintdo_tls_setsockopt_conf(structsock*sk,char__user*optval, unsignedintoptlen,inttx)

Структурасокетаtls

structtls_context{

/* read-only cache line */

structtls_prot_infoprot_info;

u8tx_conf:3;

u8rx_conf:3;

int(*push_pending_record)(structsock*sk,intflags);

void(*sk_write_space)(structsock*sk);

void*priv_ctx_tx;

void*priv_ctx_rx;

structnet_device*netdev;

/* rw cache line */

structcipher_contexttx;

structcipher_contextrx;

structscatterlist*partially_sent_record;

u16partially_sent_offset;

boolin_tcp_sendpages;

boolpending_open_record_frags;

unsignedlongflags;

/* cache cold stuff */

structproto*sk_proto;

void(*sk_destruct)(structsock*sk);

void(*sk_proto_close)(structsock*sk,longtimeout);

int(*setsockopt)(structsock*sk,intlevel,

intoptname,char__user*optval,

unsignedintoptlen);

int(*getsockopt)(structsock*sk,intlevel,

intoptname,char__user*optval,

int__user*optlen);

int(*hash)(structsock*sk);

void(*unhash)(structsock*sk);

uniontls_crypto_contextcrypto_send;

uniontls_crypto_contextcrypto_recv;

structlist_headlist;

refcount_trefcount;

};

Отправка сообщения.

Для отправки данных используются системные вызовы sendmsg() или sendpage() - tls_sw_sendmsg;tls_sw_sendpage;

Исходя из установленных параметров в сокете TLS, инициализируется структура structtls_rec с помощью функции staticstructtls_rec*tls_get_rec(structsock*sk).

Во время отправки сообщения в функции staticinttls_push_record(structsock*sk,intflag, unsignedcharrecord_type) составляется TLS запись и происходит шифрование указанным способом в соответствии с версией протокола.

Функция, осуществляющая шифрование записей:

staticinttls_do_encryption(structsock*sk,

structtls_context*tls_ctx,

structtls_sw_context_tx*ctx,

structaead_request*aead_req,

size_tdata_len,u32start)

Таким образом, модуль ядра KTLS предоставляет интерфейс для поддержки TLS согласно стандарту RFC для версии TLS 1.3.

Внедрение TLS в ядре Linux обеспечивает разгрузку процессора при обрабатывании TLS шифрования за счет уменьшения числа копирований из и в пространство пользователя.



Глава 4. Реализация RecordTLS 1.3 согласно проекту ТК26

На данный момент KTLS поддерживает всего два алгоритма шифрования: AES_GCM, ChaCha20/Poly1305. Согласно документу проекта ТК26 [Рекомендации ТК26] в отечественном TLS версии 1.3 алгоритм шифрования является MGM. В связи с этим был разработан модуль для ядра Linux, реализующий протокол RecordTLS 1.3 по данному документу. Как было сказано выше протокол Handshake лучше оставить в пространстве пользователя.

...