В этом документе OpenSSL Management Committee излагает основные принципы стратегической архитектуры OpenSSL. Начиная с 3.0.0, потребуется несколько версий, чтобы перейти от текущей архитектуры (версия 1.1.1) к будущей.

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

Текущую функциональность, предоставляемую интерфейсом движка, со временем заменит программный интерфейс. OpenSSL 3.0.0 сохранит поддержку движков. Будущая архитектура может быть полностью реализована не ранее OpenSSL 4.0.0.

Текущая архитектура

В настоящее время OpenSSL состоит из четырёх основных компонентов:

libcrypto. Основная библиотека для обеспечения реализаций многочисленных криптографических примитивов. Кроме того, она предоставляет набор вспомогательных сервисов для libssl и libcrypto, а также реализации протоколов, таких как CMS и OCSP.
Движок. Функциональность libcrypto может быть расширена через API движка.

Обычно движки — это динамически загружаемые модули, зарегистрированные в libcrypto и использующие доступные хуки для реализации криптографических алгоритмов, чаще всего альтернативных реализаций алгоритмов, уже предоставляемых libcrypto (например, с поддержкой аппаратного ускорения), но они также могут включать алгоритмы, не реализованные в OpenSSL по умолчанию (например, механизм GOST реализует семейство алгоритмов российского ГОСТ). Некоторые движки поставляются с дистрибутивом OpenSSL, а другие — третьими лицами (опять же, GOST).
libssl. Библиотека, которая зависит от libcrypto и реализует протоколы TLS и DTLS.
Приложения. Набор инструментов командной строки, которые используют базовые компоненты libssl и libcrypto для предоставления набора криптографических и других функций, таких как:
- Генерация и проверка ключей и параметров
- Генерация и проверка cертификатов
- Инструменты тестирования SSL/TLS
- Проверка ASN.1
- и др.
В настоящее время OpenSSL обладает следующими характеристиками:
1. EVP. Уровень EVP (envelope) API обеспечивает абстрактный интерфейс высокого уровня для криптографической функциональности, без привязки к конкретной реализации. Не рекомендуется прямое использование конкретных реализаций криптографических алгоритмов в обход интерфейсов EVP. Здесь также предоставлены составные операции, такие как подписание и проверка. Некоторые составные операции также предоставляются в качестве операции уровня EVP (например, HMAC-SHA256). EVP также позволяет использовать криптографические алгоритмы в алгоритмически-агностической манере (например, EVP_DigestSign работает как для алгоритмов RSA, так и для алгоритмов ECDSA).
2. FIPS140 не поддерживается, он доступен только в OpenSSL-1.0.2, которая предшествует текущей архитектуре и несовместима с API или ABI.
Концептуальная схема компонентов

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

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

Схема пакетов

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

Будущая архитектура

Особенности будущей архитектуры:
- Службы ядра образуют строительные блоки, используемые приложениями и поставщиками (например, BIO, X509, SECMEM, ASN1 и т. д.).
- Поставщики применяют криптографические алгоритмы и вспомогательные службы. Поставщик реализует одну или несколько из следующих функций:
  - Криптографические примитивы для алгоритма: шифрование, расшифровка, подпись, хэширование и т. д.
  - Сериализация для алгоритма, например, функция преобразования закрытого ключа в файл PEM. Сериализация может осуществляться в форматы или из форматов, которые в настоящее время не поддерживаются.
  - Бэкенд загрузчика хранилища (store loader). В настоящее время с OpenSSL поставляется загрузчик для считывания ключей, параметров и других элементов из файлов. Поставщики могут реализовать загрузчики для считывания данных из других мест (например, из каталога LDAP).
  Поставщик может быть полностью автономным или использовать услуги, предоставляемые разными поставщиками или службами ядра. Например, приложение может использовать криптографические примитивы для алгоритма, реализованного поставщиком устройства для аппаратного ускорения, но использовать службы сериализации другого поставщика для экспорта ключей в формат PKCS#12.
  
  Поставщик по умолчанию (который содержит ядро текущих реализаций криптографического алгоритма OpenSSL) будет «встроенным», но другие поставщики смогут динамически загружаться во время выполнения.
  
  Модуль(-и) устаревших поставщиков будут предоставлять криптографические реализации для старых алгоритмов (например, DES, MDC2, MD2, Blowfish, CAST). Мы опубликуем правила, как и когда алгоритмы переходят от поставщика по умолчанию к устаревшему поставщику.
  
  Поставщик FIPS, который реализует криптографический модуль OpenSSL FIPS, сможет динамически загружаться во время выполнения.
- Ядро обеспечивает доступ к услугам, предлагаемым поставщиками приложений (и другими). Поставщики открывают ядру доступ к методам. Ядро — это механизм, с помощью которого обнаруживаются конкретные реализации таких вещей, как алгоритмы.
  
  Ядро реализует функцию поиска на основе свойств для нахождения алгоритмов. Например, это позволит найти алгоритм, где "fips=true" или "keysize=128, constant_time=true". Подробности опубликуем в последующих проектных документах.
- Реализации протоколов, таких как TLS, DTLS.
Будущая архитектура имеет следующие характеристики:
- Слой EVP становится тонкой обёрткой для сервисов, реализованных через поставщиков. Большинство вызовов проходят насквозь с минимальной предварительной или постобработкой или вообще без неё.
- Появятся новые EVP API для поиска в ядре реализации алгоритма, который будет использоваться для любого вызова EVP.
- Информация будет передаваться между основной библиотекой и поставщиками одинаковым образом, независимо от их реализации.
- Устаревшие API (например, низкоуровневые криптографические API, которые не проходят через уровень EVP), будут исключены. Обратите внимание, что существуют устаревшие API для алгоритмов, которые не устарели (например, AES — это не устаревший алгоритм, но AES_encrypt — устаревший API).
- Криптографический модуль OpenSSL FIPS будет реализован как динамически загружаемый поставщик. Он будет автономным (т. е. может зависеть только от системных библиотек рантайма и сервисов, предоставляемых ядром).
- Другие интерфейсы тоже с течением времени могут быть переведены на использование ядра (например, OSSL_STORE).
- Пользование движком переходит к поставщикам. «Пока-пока, инженеры, здравствуйте, поставщики».
Концептуальная схема компонентов

На диаграмме ниже приведён обзор компонентов будущей архитектуры OpenSSL.

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

Здесь показаны следующие компоненты:
- Приложения: утилиты командной строки: ca, ciphers, cms, dgst и др.
- Протоколы: компонент обеспечивает возможность связи между конечными точками по стандартным протоколам:
  - Протоколы TLS: реализация всех поддерживаемых протоколов TLS/DTLS и обслуживающей инфраструктуры:
    - SSL BIO: BIO для связи по TLS
    - Statem: машина состояния TLS
    - Record: слой записи TLS
  - Другие протоколы
    - CMS: реализация стандарта Cryptographic Message Syntax
    - OCSP: реализация Online Certificate Status Protocol
    - TS: реализация Timestamp Protocol
  - Вспомогательные службы: компоненты, специально предназначенные для поддержки реализации кода протокола
    - Packet: внутренний компонент для чтения сообщений протокола
    - Wpacket: внутренний компонент для записи сообщений протокола
- Ядро: это фундаментальный компонент, который соединяет запросы на службу (например, шифрование) с поставщиком этой службы. Он даёт возможность поставщикам регистрировать свои службы вместе с их свойствами. Ядро также предоставляет возможность найти службу с заданным набором свойств, которые служба должна выполнить. Например, свойства службы шифрования могут включать "aead", "aes-gcm", "fips", "security-bits=128" и т. д.
- Поставщик по умолчанию: реализует набор служб по умолчанию, зарегистрированных в ядре.
  - Вспомогательные службы
    - Реализации низкого уровня: это набор компонентов, которые фактически реализуют криптографические примитивы.
- Поставщик FIPS: реализует набор служб, проверенных и доступных ядру FIPS. Включает следующие вспомогательные службы:
  - POST: Power On Self Test
  - KAT: Known Answer Tests
  - Проверка целостности
  - Реализации низкого уровня: это набор компонентов, которые фактически реализуют криптографические примитивы (для удовлетворения автономного требования FIPS).
- Поставщик устаревших алгоритмов: предоставляет реализации старых алгоритмов, которые будут предоставляться через API уровня EVP.
- Сторонний поставщик: не является частью дистрибутива OpenSSL. Третьи стороны могут реализовать собственных поставщиков.
- Общие службы: образуют строительные блоки, используемые приложениями и поставщиками (например, BIO, X509, SECMEM, ASN1 и т.д.).
- Устаревшие API. «Низкоуровневые» API: здесь слово «устаревший» относится именно к API, а не к самому алгоритму. Например, AES не является устаревшим алгоритмом, но для него есть устаревшие API (например, AES_encrypt).
Схема пакетов

Различные компоненты, описанные выше на концептуальной схеме компонентов, физически упакованы в:
- Исполняемые приложения для пользователей
- Библиотека (библиотеки) для приложений
- Динамически загружаемый модуль (модули) для ядра.
Здесь показаны следующие фактические пакеты:
- Исполняемый файл OpenSSL. Приложение командной строки.
- Libssl. Содержит всё, что непосредственно связано с TLS и DTLS. Его содержимое во многом такое же, как в нынешнем libssl. Обратите внимание, что некоторые вспомогательные службы будут перемещены в libcrypto.
- Libcrypto. Данная библиотека содержит следующие компоненты:
  - Реализации основных сервисов: X509, ASN1, EVP, OSSL_STORE и т. д.
  - Ядро
  - Протоколы, не связанные с TLS или DTLS
  - Службы поддержки протокола (например, Packet и Wpacket)
  - Поставщик по умолчанию, содержащий реализации всех алгоритмов по умолчанию
- Libcrypto-legacy. Предоставляет устаревшие «низкоуровневые» API. Реализация алгоритмов для этих API может исходить от любого поставщика.
- Модуль FIPS. Содержит поставщика FIPS, который реализует набор служб, проверенных FIPS и зарегистрированных в ядре.
- Legacy-модуль. Содержит устаревшего поставщика.

Текущая архитектура

Концептуальная схема компонентов

Схема пакетов

Будущая архитектура

Концептуальная схема компонентов

Схема пакетов

Стратегическая архитектура OpenSSL