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

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

Ожидаются многочисленные изменения в архитектуре.

Мы предлагаем возможный путь миграции.

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

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

OpenSSL 3.0.0 сохранит поддержку движка.

Будущая архитектура может быть полностью реализована не раньше OpenSSL 4.0.0. Текущая архитектура OpenSSL в настоящее время состоит из четырех основных компонентов:

  1. libcrypto. Базовая библиотека для реализации множества криптографических примитивов.

    Кроме того, он предоставляет набор услуг поддержки для libssl и libcrypto, а также реализации таких протоколов, как CMS и OCSP.

  2. Двигатель.

    Функциональность libcrypto можно расширить через API движка.

    Движки обычно представляют собой динамически загружаемые модули, зарегистрированные в libcrypto, и используют доступные перехватчики для реализации криптографических алгоритмов, чаще всего альтернативных реализаций алгоритмов, уже предоставляемых libcrypto (например, с поддержкой аппаратного ускорения), но они также могут включать алгоритмы, не реализованные в OpenSSL с помощью по умолчанию (например, механизм ГОСТ реализует семейство алгоритмов российского ГОСТа).

    Некоторые движки поставляются с дистрибутивом OpenSSL, другие — от третьих лиц (опять же ГОСТ).

  3. libssl. Библиотека, зависящая от libcrypto и реализующая протоколы TLS и DTLS.
  4. Приложения.

    Набор инструментов командной строки, которые используют базовые компоненты libssl и libcrypto для предоставления набора криптографических и других функций, таких как:

    • Генерация и проверка ключей и параметров
    • Генерация и проверка сертификатов
    • Инструменты тестирования SSL/TLS
    • проверка АСН.

      1

    • и так далее.

    На данный момент OpenSSL имеет следующие характеристики:
    1. Е.

      В.

      П.

      Уровень API EVP (конверта) обеспечивает высокоуровневый абстрактный интерфейс для криптографических функций без привязки к конкретной реализации.

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

      Здесь также предусмотрены составные операции, такие как подписание и проверка.

      Некоторые составные операции также предоставляются как операции уровня EVP (например, HMAC-SHA256).

      EVP также позволяет использовать криптографические алгоритмы независимо от алгоритма (например, EVP_DigestSign работает как для алгоритмов RSA, так и для ECDSA).

    2. FIPS140 не поддерживается, он доступен только в OpenSSL-1.0.2, который предшествует текущей архитектуре и не совместим с API или ABI.


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

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

    Уровень TLS зависит от криптографического уровня, а приложения зависят как от TLS, так и от криптографического уровня.

    Примечание.

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



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



    Схема упаковки

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

    Это показано на схеме ниже.



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

    Архитектура будущего Особенности будущей архитектуры:

    • Службы ядра образуют строительные блоки, используемые приложениями и поставщиками (например, BIO, X509, SECMEM, ASN1 и т. д.).

    • Поставщики используют криптографические алгоритмы и службы поддержки.

      Поставщик реализует одну или несколько из следующих функций:

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

      • Серверная часть загрузчика магазина.

        OpenSSL в настоящее время поставляется с загрузчиком для чтения ключей, параметров и других элементов из файлов.

        Поставщики могут реализовать загрузчики для чтения данных из других мест (например, из каталога LDAP).

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

      Например, приложение может использовать криптографические примитивы для алгоритма, реализованного поставщиком устройства для аппаратного ускорения, но использовать службы сериализации другого поставщика для экспорта ключей в формате PKCS#12. Поставщик по умолчанию (который содержит ядро текущих реализаций криптографического алгоритма OpenSSL) будет «встроенным», но другие поставщики смогут динамически загружаться во время выполнения.

      Модули устаревших поставщиков будут обеспечивать криптографические реализации для старых алгоритмов (например, DES, MDC2, MD2, Blowfish, CAST).

      Мы опубликуем правила того, как и когда алгоритмы перейдут от поставщика по умолчанию к устаревшему поставщику.

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

    • Ядро обеспечивает доступ к сервисам, предлагаемым поставщиками приложений (и другими).

      Поставщики предоставляют методы ядру.

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

      Ядро реализует функцию поиска на основе свойств для поиска алгоритмов.

      Например, это позволит вам найти алгоритм, в котором «fips=true» или «keysize=128, Constant_time=true».

      Подробности мы опубликуем в последующих проектных документах.

    • Реализации таких протоколов, как TLS, DTLS.
    Архитектура будущего имеет следующие характеристики:
    • Уровень EVP становится тонкой оболочкой для услуг, реализуемых через поставщиков.

      Большинство вызовов проходят без предварительной или постобработки или практически без нее.

    • Появятся новые API-интерфейсы EVP для поиска базовой реализации алгоритма, который будет использоваться для любого вызова EVP.
    • Информация будет передаваться между основной библиотекой и провайдерами одинаково, независимо от их реализации.

    • Устаревшие API (например, криптографические API низкого уровня, которые не проходят через уровень EVP) будут исключены.

      Обратите внимание, что существуют устаревшие API для алгоритмов, которые не устарели (например, AES не является устаревшим алгоритмом, но AES_encrypt — устаревшим API).

    • Криптографический модуль OpenSSL FIPS будет реализован как динамически загружаемый провайдер.

      Он будет автономным (т. е.

      может зависеть только от системных библиотек времени выполнения и служб, предоставляемых ядром).

    • Другие интерфейсы также могут быть преобразованы для использования ядра с течением времени (например, OSSL_STORE).

    • Использование двигателя передается поставщикам.

      «До свидания инженеры, здравствуйте поставщики» .



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

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

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



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

    Здесь показаны следующие компоненты:

    • Приложения: утилиты командной строки: ca, ciphers, cms, dgst и т. д.
    • Протоколы: компонент обеспечивает возможность взаимодействия между конечными точками с использованием стандартных протоколов:
      • Протоколы TLS: реализация всех поддерживаемых протоколов TLS/DTLS и поддерживающая инфраструктура:
        • SSL BIO: BIO для связи TLS.
        • Statem: конечный автомат TLS.
        • Запись: слой записи TLS.
      • Другие протоколы
        • CMS: реализация стандарта синтаксиса криптографических сообщений.

        • OCSP: реализация протокола статуса онлайн-сертификата
        • TS: реализация протокола отметок времени
      • Вспомогательные услуги: компоненты, специально разработанные для поддержки реализации кода протокола.

        • Пакет: внутренний компонент для чтения сообщений протокола.

        • Wpacket: внутренний компонент для написания протокольных сообщений.

    • Ядро: это фундаментальный компонент, который связывает запросы на услугу (например, шифрование) с поставщиком этой услуги.

      Это позволяет поставщикам регистрировать свои услуги вместе со своей собственностью.

      Ядро также предоставляет возможность найти службу с заданным набором свойств, которые эта служба должна выполнять.

      Например, свойства службы шифрования могут включать «aead», «aes-gcm», «fips», «security-bits=128» и т. д.

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

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

    • Поставщик FIPS: реализует набор служб, которые проверены и доступны для механизма FIPS. Включает следующие услуги поддержки:
      • ПОСТ: Самотестирование при включении питания
      • KAT: тесты с известными ответами
      • Проверка целостности
      • Реализации низкого уровня: это набор компонентов, которые фактически реализуют криптографические примитивы (для удовлетворения отдельных требований FIPS).

    • Поставщик устаревших алгоритмов: предоставляет реализации устаревших алгоритмов, которые будут доступны через API уровня EVP.
    • Сторонний поставщик: не входит в дистрибутив OpenSSL. Третьи лица могут реализовать своих собственных поставщиков.

    • Общие сервисы: образуют строительные блоки, используемые приложениями и поставщиками (например, BIO, X509, SECMEM, ASN1 и т. д.).

    • Устаревшие API. «Низкоуровневые» API: здесь слово «устарело» относится конкретно к API, а не к самому алгоритму.

      Например, AES не является устаревшим алгоритмом, но для него существуют устаревшие API (например, AES_encrypt).



    Схема упаковки

    Различные компоненты, описанные на концептуальной диаграмме компонентов выше, физически упакованы как:
    • Исполняемые приложения для пользователей
    • Библиотека(и) для приложений
    • Динамически загружаемые модули ядра.



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

    Фактические пакеты, показанные здесь:
    • Исполняемый файл OpenSSL. Приложение командной строки.

    • Libssl. Содержит все, что напрямую связано с TLS и DTLS. Его содержимое во многом такое же, как и в текущей версии libssl. Обратите внимание, что некоторые службы поддержки будут перенесены в libcrypto.
    • Либкрипто.

      Эта библиотека содержит следующие компоненты:

      • Реализации основных сервисов: X509, ASN1, EVP, OSSL_STORE и т. д.
      • Основной
      • Протоколы, не связанные с TLS или DTLS
      • Службы поддержки протоколов (такие как Packet и Wpacket)
      • Поставщик по умолчанию, содержащий реализации всех алгоритмов по умолчанию.

    • Libcrypto-наследие.

      Предоставляет устаревшие API-интерфейсы «низкого уровня».

      Реализации алгоритмов для этих API могут быть предоставлены любым поставщиком.

    • Модуль ФИПС.

      Содержит поставщика FIPS, который реализует набор проверенных FIPS служб, зарегистрированных в ядре.

    • Унаследованный модуль.

      Содержит устаревшего поставщика.

Теги: #Программное обеспечение #архитектура #Криптография #шифрование #openssl #libssl #libcrypto
Вместе с данным постом часто просматривают: