Криптопровайдер: что это и как он работает с ключом

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

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

На условном примере подписи документа разберём, где находятся эти объекты, кто выполняет операцию и почему криптопровайдер, контейнер ключа и токен выполняют разные задачи.

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

У каждого объекта своя роль

Открытый и закрытый ключи математически связаны. Закрытым создают подпись, открытым проверяют. Сертификат содержит открытый ключ и сведения о субъекте; закрытого ключа внутри него нет.

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

От документа к криптографической операции

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

1. Приложение определяет, какие данные подписываются и в каком формате будет сохранён результат.
2. По выбранному сертификату и настройкам оно находит соответствующий ключ. Эта связь может храниться в свойствах сертификата или задаваться самим приложением.
3. Программа через криптографический интерфейс запрашивает подпись. Для многих схем подписи сначала вычисляется хеш — значение, зависящее от подписываемых данных. Где именно считается хеш, зависит от интерфейса и механизма.
4. Провайдер обращается к токену. Использование ключа разрешается по правилам устройства и приложения: например, после ввода PIN-кода.
5. Токен выполняет операцию закрытым ключом и возвращает подпись. В выбранном режиме сам ключ устройство не покидает.
6. Приложение сохраняет подпись в документе или отдельном файле, при необходимости добавляет сертификат и другие данные формата.

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

Что получает и проверяет получатель

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

Проверяющая программа определяет подписанные данные по правилам формата и проверяет подпись открытым ключом. Если подписанные данные изменены, проверка не пройдёт. Затем отдельно оцениваются доверие к сертификату, допустимость его использования и требования принимающей системы. Поэтому «подпись создана» и «получатель принял документ» — разные результаты. Процедура проверки подписи в формате CMS описана в RFC 5652 ↗.

Хранилище сертификатов показывает сертификаты и может хранить ссылку на соответствующий ключ. Сам закрытый ключ обслуживается отдельным механизмом. В Windows и macOS название раздела со списком сертификатов не определяет место выполнения подписи.

Контейнер — не ещё одно название сертификата

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

Файл PFX/P12 в формате PKCS#12 — отдельный случай: он может объединять сертификаты и закрытый ключ для переноса. Не всякий контейнер можно экспортировать в PFX. О составе такого файла подробнее сказано в объяснении сертификата и ключей.

Как различаются программное хранение и токен

Пассивный носитель хранит ключевые данные; криптографическую операцию выполняет программа на компьютере. Криптографический токен способен выполнить операцию внутри устройства. Возможность извлечь ключ зависит от модели, настроек и режима работы, а не только от слова «токен» на упаковке. Это различие отражено в документации Рутокен ↗ и описании способов хранения ключей КриптоПро CSP ↗.

Неизвлекаемый ключ сложнее скопировать, но это не полная защита от злоупотребления: вредоносная программа может попытаться запросить подпись, пока устройство подключено и доступ разрешён. Значение имеют и подтверждение операции, и защита рабочего места.

CSP и KSP — виды провайдеров, а PKCS#11 — программный интерфейс. Интерфейс определяет, как одна программа обращается к другой; провайдер реализует доступные через него возможности. Эти названия обозначают разные части системы.

В Windows есть две архитектуры криптографических средств: CryptoAPI и более новая CNG (Cryptography API: Next Generation). В них используются разные виды провайдеров. Поддержка одной архитектуры приложением не означает автоматической совместимости с другой.

Различия CSP и KSP описаны в справочнике Microsoft по CSP ↗ и справочнике Microsoft по KSP ↗. Интерфейс токенов определяет спецификация PKCS#11 ↗.

КриптоПро — пример продукта, а не общее название

КриптоПро CSP — конкретный криптопровайдер. Его используют, в частности, для операций с российскими алгоритмами ГОСТ. Выбор зависит от требований приложения, ключа, алгоритмов и носителя. Для обычного HTTPS не требуется повсеместно устанавливать КриптоПро.

У OpenSSL тоже есть модель providers ↗: модули предоставляют реализации криптографических функций библиотеке OpenSSL. Это другая архитектура, а не Windows CSP под новым названием.

Драйвер и браузерный плагин

Драйвер помогает системе взаимодействовать с устройством. Браузерный компонент связывает веб-приложение с доступными на компьютере средствами подписи. Провайдер отвечает за криптографические операции. Как показывает описание браузерного плагина КриптоПро ↗, эти компоненты могут устанавливаться одним пакетом, но наличие одного не доказывает готовность остальных. В документации КриптоАРМ ↗ роль провайдера рассматривается отдельно от программы работы с документами.

Кто участвует в рабочем результате

Издатель выпускает сертификат после своих проверок. Администратор или пользователь настраивает рабочее место и доступ к ключу. Разработчик приложения обеспечивает совместимость интерфейса и формата. Принимающая система проверяет результат по своим правилам. Поэтому сообщение «сертификат установлен» описывает только один этап.

Криптопровайдер выпускает сертификаты?

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

Успешная подпись означает доверие к владельцу?

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

Тот же механизм работает при подключении к серверу?

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

Что читать дальше

Основу пары ключей и сертификата раскрывает статья о сертификатах. Причины доверия издателю — разбор цепочки сертификатов. Применение ключа для взаимной аутентификации — объяснение mTLS.