Web Cryptography API: пример использования / Хабр

Activex

Компания Microsoft разработала два основных клиентских ActiveX-компонента, которые транслируют функционал CryptoAPI в скрипты, в браузер.Для генерации ключа и создания PKCS#10-запроса применятся компонент XEnroll/CertEnroll, а для ЭЦП/шифрования и работы с сертификатами компонент CAPICOM.

В следующих статьях будут подробно рассмотрены оставшиеся решения.

Cryptographic application programming interface (cryptoapi)

ИнтерфейсMicrosoft CryptoAPl 2.0 содержит как функции, осуществляющие базовые криптографические преобразования, так и функции, реализующие преобразования более высокого уровня – работу с сертификатами Х.

509, работу с криптографическими сообщениями PKCS#7 [9.4, 9.5] и другие функции, поддерживающие так называемую инфраструктуру открытых ключей ( Public Key Infrastructure ).

Набор функций из CryptoAPI 2.0, реализующих базовые криптографические преобразования ( basecryptographyfunctions ), называют также CryptoAPI 1.0 [9.2].

Функции высокого уровня, предназначенные для реализации криптографических преобразований, вызывают именно функции CryptoAPI 1.0. Таким образом, именно интерфейсCryptoAPI 1.0 является криптографическим ядром прикладного уровня современных операционных систем Microsoft.

Круг задач, на решение которых ориентирован CryptoAPI [9.3]:

Реализация всех алгоритмов полностью выведена из состава CryptoAPI и реализуется в независимых динамических библиотеках – ” криптопровайдерах ” (см. раздел ” Криптопровайдеры “). CryptoAPI предоставляет конечному пользователю унифицированный интерфейс работы с функциями криптопровайдера.

CryptoAPI достаточно полно поддерживает набор стандартов “PKCS” [9.6], предложенный компанией RSASecurity, и позволяет формировать криптографические приложения, которые могут быть обработаны в дальнейшем любыми программными продуктами.

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

Общая архитектураCryptoAPI состоит из пяти основных функциональных групп (см. рис. 9.1):

1. Базовые криптографические функции:
2. Функции кодирования/декодирования. Под кодированием в данном случае подразумевается получение на выходе информации, кодированной в формате ASN.1 ( AbstractSyntax Notation One ).
3. Функции работы с сертификатами.
4. Высокоуровневые функции обработки криптографических сообщений.
5. Низкоуровневые функции обработки криптографических сообщений.

Для доступа к CryptoAPI можно использовать CAPICOM. CAPICOM предоставляет COMинтерфейс, использующий основные функции CryptoAPI.

Этот компонент является добавлением к COM -интерфейсу Certificate Enrollment Control ( xenroll ), который реализуют клиентские функции генерации ключей, запросов на сертификаты и обмена с центром сертификации.

Данный компонент позволяет получать доступ к функциям формирования и проверки электронной цифровой подписи, построения и проверки цепочек сертификатов, взаимодействия с различными справочниками сертификатов (включая Active Directory ) с использованием Visual Basic, C , JavaScript, VBScript и среды разработкиDelphi. CAPICOM доступен в операционных системах Windows Server 2008, Vista, Windows XP, Windows Me, Windows 2000 и Windows 98.

В последующих версиях в него могут быть внесены изменения; также неисключено, что Microsoft совсем откажется от использования этого компонента. В связи с этим для реализации криптографической функциональности рекомендуется использовать средства .NET Framework.

Cryptography next generation api (cng)

Служба CNG предоставляет набор интерфейсов API для выполнения основных криптографических операций и благодаря своей модульной архитектуре позволяет создавать, обновлять и использовать собственные алгоритмы шифрования в таких приложениях и технологиях, как служба сертификацииActive Directory, технологии SSL и IPsec.

CNG поддерживает все алгоритмы, предлагаемые CryptoAPI, а также новые алгоритмы, включая алгоритмы шифрования, цифровых подписей, обмена ключами и хеширования, перечисленные в своде правил Suite B Агентства национальной безопасности США [9.

7] – например, такие алгоритмы, как алгоритмхешированияSHA-256 и алгоритмы шифрования на основе эллиптических кривых ( ECC ).

Алгоритмы Suite B используются в службах Certificate Services, чтобы генерировать сертификаты и защитить архив частных ключей в базе данных СА.

Чтобы издавать сертификаты с алгоритмами Suite B, в инфраструктуре PKIWindows Vista и Server 2008 расширены свойства шаблона сертификата.

Шаблоны сертификата – заготовки сертификатов различных типов, которые может выпускать удостоверяющий центр, интегрированный со службой Active Directory (удостоверяющим центром предприятия).

На рис. 9.2 [9.1] приведена общая схема CNG. BCrypt (‘B’ – сокр. от ‘base’, базовый) – это подмножествоCNG, которое предоставляет такие примитивы криптографии, как средства генерации случайных чисел, функции хеширования, подписи и ключи шифрования. NCrypt (‘N’ – сокр. от ‘new’, новый) обеспечивает механизмы сохранения асимметричных ключей и поддержки аппаратных средств, таких как смарт-карты. BCrypt и NCrypt – имена заголовочных файлов и DLL, предоставляющих базовые сервисы для CNG и высокоуровневую функциональность для хранения ключей соответственно.

В версиях Windows, предшествующих Vista, криптографические технологии, такие как CryptoAPI, работали только в пользовательском режиме, в то время как режим ядра требовал применения совсем других API -интерфейсов. CNG содержит универсальный набор API -интерфейсов, которые впервые предоставляют общую инфраструктуру шифрования для приложений как пользовательского режима, так и режима ядра. Исключение составляют механизмы хранения ключей, предоставляемые NCrypt: они доступны только приложениям пользовательского режима.

Существует два основных подхода к примитивам криптографии, обеспечиваемых CNG [9.1]. В первом подходе они рассматриваются как набор логических объектов, предоставляющих методы, которые можно вызывать, и свойства, которые можно запрашивать и иногда изменять.

К этим объектам относятся поставщики алгоритмов, функции хеширования, ключи и секретные соглашения. При другом подходе CNG рассматривается как программный маршрутизатор, или посредник для операций криптографии. ИнтерфейсAPI CNG строится на основе набора логических интерфейсов криптографии.

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

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

CNG позволяет разработчикам запрашивать алгоритмы, не указывая поставщиков алгоритмов. Это позволяет администраторам перенастраивать приложения с целью использования других реализаций (подробнее см. раздел “Шаблоны использования криптографических функций в корпоративных приложениях”).

Windows Vista и Server 2008 располагают новым общим провайдером услуг шифрования для подсистем смарт-карт различных поставщиков ( BaseSmart CardCryptographic Service Provider, BaseCSP ).

Кроме того, новая инфраструктураCNG включает провайдеры хранилищ ключей ( Key Storage Provider, KSP ) для смарт-карт.

Благодаря новому общему провайдеру BaseCSP поставщики смарт-карт могут быстро и без труда интегрировать свое программное обеспечение с операционной системой Windows без необходимости разработки сложных собственных провайдеров – достаточно небольших модулей, которые встраиваются в архитектуру смарт-картWindows. Модуль, написанный поставщиком смарт-карт для интеграции своего криптопровайдера, позволит интегрировать и хранилище ключей (см. рис. 9.4 [9.8]).

Другое изменение Windows Vista и Server 2008, относящееся к смарт-картам и удобное для пользователей и администраторов, – расширенная поддержка приложений.

Например, в файловой системе EFSсмарт-карты могут применяться для надежного хранения частного ключа EFS пользователя.

Openssl-style

Open Source библиотека OpenSSL обладает широкими криптографическими возможностями и удобным механизмом ее расширения другими криптоалгоритмами. OpenSSL является основным криптоядром для широкого спектра приложений Open Source.

После того, как в эту библиотеку компанией Криптоком были добавлены ГОСТы, появились патчи для «гостификации» многих популярных приложения, использующих OpenSSL. На базе OpenSSL некоторые вендоры разработали и сертифицировали СКЗИ, кроме того в ряд продуктов OpenSSL входит «неявным» образом.

Pkcs#11

Библиотека PKCS#11 предоставляет универсальный кроссплатформенный программный интерфейс к USB-токенам и смарт-картам.

Функции делятся на:

• Функции доступа к устройству;
• Функции записи/чтения произвольных данных;
• Функции работы с ключами (поиск, создание, удаление, импорт, экспорт);
• Функции работы с сертификатами (поиск, импорт, экспорт);
• Функции ЭЦП;
• Функции хэширования;
• Функции шифрования;
• Функции вычисления имитовставки;
• Функции выработки ключа согласования (Диффи-Хeллман);
• Функции экспорта/импорта сессионного ключа;

Таким образом, стандарт PKCS#11 поддерживает полный набор криптопримитивов, пригодный для реализации криптографических форматов (PKCS#7/CMS/CADES, PKCS#10, X.509 и др.) и протоколов (TLS, IPSEC, openvpn и др.).

Для обеспечения быстродействия часть криптопримитивов может быть реализована программно.

В стандарте PKCS#11, начиная с версии 2.30, поддерживаются ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94, ГОСТ 28147-89.

Использование библиотеки PKCS#11 обеспечивает совместимость ПО различных вендоров при работе с токенами. Через PKCS#11 интерфейс умеют работать приложения, написанные на на базе CryptoAPI, NSS, OpenSSL.

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

PKCS#11 бывают также без поддержки аппаратных устройств с программной реализацией криптоалгоритмов и хранением объектов в файловой системе.

Примеры – PKCS#11 интегрированный в NSS (Mozilla), проект aToken, библиотека Агава-Про.

У компании Крипто-Про есть библиотека PKCS#11, реализованная на базе MS CryptoAPI:

Существуют PKCS#11-библиотеки для мобильных платоформ. Примером подобной библиотеки служит библиотека для Рутокен ЭЦП Bluetooth, которая позволяет использовать устройство на iOS и Android.

Безопасность

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

Пользователями КриптоПро DSS управляет оператор, который имеет возможность посредством веб-интерфейса или API выполнять следующие действия:

Библиотеки c собственным интерфейсом

Проприетарные библиотеки предоставляют собственный API для встраивания в приложения. В данный список можно внести:

• Агава-С
• Крипто-C
• Крипто-КОМ

Браузерные плагины

Для того, чтобы из скриптов WEB-страницы вызвать нативную библиотеку большинство браузеров поддерживают специальные расширения — ActiveX для IE и NPAPI-плагин для GH, MF, Opera, Sаfari и др. В данный момент на рынке существует широкий спектр продуктов, относящихся к браузерным плагинам.

Архитектурно данные плагины могут быть исполнены по-разному. Некоторые работают на базе CryptoAPI и требуют дополнительной установки криптопровайдера, другие используют в качестве криптоядра PKCS#11-совместимые устройства и не требуют установки дополнительных СКЗИ на рабочее место клиента. Есть универсальные плагины, которые поддерживают как все основные криптопровайдеры, так и широкий спектр аппаратных СКЗИ.

Высокая отказоустойчивость и доступность

Обеспечивается с помощью горячего резервирования и кластеризации всех компонент КриптоПро DSS и КриптоПро HSM с помощью специализированных балансировщиков нагрузки (например, HAProxy) и SQL-кластера на базе технологий MS SQL Server AlwaysOn availability groups.

В случае нарушения функционирования любого из зарезервированных компонентов переключение на резервные, в т.ч. размещенные на территориально-удаленных технологических площадках (Резервных ЦОД), осуществляется автоматически без участия обслуживающего персонала и без потери сохраненных данных.

Интерфейс программирования приложений

Предназначен для создания и проверки сообщений, подписанных усовершенствованной подписью и удовлетворяющих стандарту CAdES (ETSI TS 101 733). На настоящий момент интерфейс поддерживает создание подписей типа CAdES BES, CADES-T и CAdES-X Long Type 1.

Интерфейс клиентских приложений имеет следующие особенности:

• Поддерживаемые платформы:
• Содержит интерфейс языка С, спроектированный таким образом, чтобы дополнять или замещать функции Crypto API для работы с подписанными сообщениями.
• Содержит компоненту COM, расширяющую интерфейс Microsoft CAPICOM.
• Содержит КриптоПро ЭЦП Browser plug-in, предоставляющий интерфейс языка JavaScript для реализации криптографических операций в браузерах. Поддерживает создание и проверку подписи, шифрование и создание запросов на сертификат.
• Расширение для языка PHP, предоставляющее интерфейс, аналогичный КриптоПро ЭЦП Browser plug-in, для использования в серверных приложениях на языке PHP.
• Для настройки клиентских модулей в пределах организации или подразделения можно использовать групповые политики.

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

Подробное описание КриптоПро ЭЦП SDK приведено в Руководстве разработчика КриптоПро ЭЦП SDK.

Клиент

Здесь начинается самое интересное.

Открываем файл client.js.

Для шифрования данных будет использоваться симметричный алгоритм AES-GCM. Такие алгоритмы позволяют использовать один и тот же ключ для шифрования и расшифровки.

Создаем функцию генерации симметричного ключа:

Криптопровайдеры

Де-факто стандартом отрасли является класс криптосредств, известных как криптопровайдеры. Криптопровайдер — это предоставляющая специальный API и специальным образом зарегистрированная в ОС библиотека, которая позволяет расширить список поддерживаемых в ОС криптоалгоритмов.

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

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

Кроссбраузерные плагины

Проблемы:

• отсутствие TLS
• удаление NPAPI из Chromium
• браузеры на мобильных платформах не поддерживают плагины
• настройки безопасности IE могут блокировать исполнение плагина

Плюсы:

• кроссплатформенность для плагинов на базе PKCS#11
• кроссбраузерность
• плагины на базе PKCS#11 не требуют установки СКЗИ
• прозрачное использование для пользователя

Локальные прокси

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

Мониторинг функционирования и доступности

В составе с КриптоПро DSS может использоваться специальный программный комплекс класса Network Performance Monitoring and Diagnostics (NPMD) “КриптоПро Центр Мониторинга” для мониторинга работоспособности и оперативного уведомления администраторов СЭП о выявленных сбоях, ошибках функционирования и прочих внештатных ситуациях.

Сервис электронной подписи ООО «КРИПТО-ПРО»

Тестовый сервис электронной подписи

Приобрести ПАК “КриптоПро DSS 2.0”

Загрузить ПАК “КриптоПро DSS 2.0”

Порядок использования комплектаций ПАКМ «КриптоПро HSM» с компонентом «КриптоПро DSS 2.0» для работы с квалифицированной электронной подписью

Учебный курс по ПАК “КриптоПро DSS 2.0”

Учебный курс по “КриптоПро Центр мониторинга 1.0”

Необработанная подпись

Сервис Подписи DSS позволяет формировать необработанную подпись двумя способами:

Подготовка

Создаем директорию

crypto-tut

mkdir crypto-tut

Заходим в нее и инициализируем проект:

cd crypto-tut

npm init -y

Устанавливаем

express

npm i express

Устанавливаем

nodemon

npm i -D nodemon

Редактируем

package.json

"main": "server.js",
"scripts": {
    "start": "nodemon"
},

Структура проекта:

crypto-tut
    --node_modules
    --src
        --client.js
        --index.html
        --style.css
    --package-lock.json
    --package.json
    --server.js

Содержание

index.html

Подпись в формате cades-xlt1/cades-t

Сервис Подписи DSS позволяет создавать следующие виды подписи в формате CAdES-XLT1/CAdES-T:

Подпись в формате cms

Сервис Подписи DSS позволяет создавать следующие виды CMS-подписи:

Подпись в формате xmldsig

REST-интерфейс Сервиса Подписи позволяет формировать XML-подпись следующими способами:

Пользовательский сертификат

При выполнении любой операции подписи Сервис должен располагать информацией о сертификате ключа подписи.
Это можно сделать двумя способами:

• передача идентификатора сертификата в запросе на формирование подписи
• использование сертификата по умолчанию

Для получения идентификтора сертификата можно воспользоваться методом GetCertificates.

Если необходимо использовать сертификат по умолчанию, то в качестве идентификатора сертификата в запросе следует передавать значение 0, предварительно назначив один из сертификатов пользователя сертификатом по умолчанию.

Примечание

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

В поле OriginalDocument необходимо передавать исходный документ.

В запросе должен присутствовать параметр CmsSignatureType, имеющий значение countersign.

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

Сервер

Приступаем к созданию сервера.

Открываем server.js.

Подключаем express и создаем экземпляры приложения и маршрутизатора:

const express = require('express')
const app = express()
const router = express.Router()

Подключаем middleware (промежуточный слой между запросом и ответом):

// разбор запроса
app.use(express.json({
    type: ['application/json', 'text/plain']
}))
// подключение роутера
app.use(router)
// директория со статическими файлами
app.use(express.static('src'))

Создаем переменную для хранения данных:

let data

Обрабатываем получение данных от клиента:

router.post('/secure-api', (req, res) => {
    // получаем данные из тела запроса
    data = req.body
    // выводим данные в терминал
    console.log(data)
    // закрываем соединение
    res.end()
})

Обрабатываем отправку данных клиенту:

router.get('/secure-api', (req, res) => {
    // данные отправляются в формате JSON,
    // после чего соединение автоматически закрывается
    res.json(data)
})

Запускаем сервер:

app.listen(3000, () => console.log('Server ready'))

Выполняем команду

npm start

. В терминале появляется сообщение «Server ready». Открываем

Способы аутентификации

В зависимости от настройки, КриптоПро DSS 2.0 может реализовывать следующие способы аутентификации пользователя:

Текст лекции

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

Современные операционные системы Microsoft содержат множество криптографических подсистем различного назначения как прикладного уровня, так и уровня ядра. Ключевую роль в Windows 2000, Windows XP, Windows ME играет интерфейсCryptoAPI ( Cryptography API, CAPI ).

В основе шифрованияWindows Vista и Server 2008 лежит новый API шифрования, называемый CNG API ( Cryptography Next Generation – новое поколение криптографии) [9.1].

Первый выпуск CNG в рамках криптографической инфраструктуры предоставляет интерфейсы API и среду, позволяющие добавлять в Windows новые алгоритмы для использования с протоколами Secure Sockets Layer / Transport LayerSecurity ( SSL / TLS ) и IPSec ; в будущем планируется реализовать поддержку других возможностей, например S / MIME и EFS.

В конечном итоге Microsoft будет использовать этот новый API вместо текущего CryptoAPI, но в Vista и Server 2008 старый и новый API сосуществуют (в основном для совместимости со старыми приложениями).

В данном разделе мы рассмотрим CryptoAPI, после чего перейдем к обзору функциональности CNG. Кроме того, мы уделим внимание интерфейсу DPAPI. Windows, начиная с версии 2000, поддерживает встроенный механизм для хранения и защиты секретов.

Этот механизм использует машинный ключ, сгенерированный при инсталляции системы специально для шифрования данных. Только локальная операционная система (локальный системный центр авторизации) имеет доступ к машинному ключу.

Машинный ключ уникален для каждой инсталляции. Windows поддерживает программный интерфейсData Protection API для защиты данных этим ключом.

Использование этого API не дает прямого доступа к этому ключу, а позволяет отдавать системе команды зашифровать/расшифровать некоторую информацию с использованием этого ключа. Другим вариантом является использование ключа, сгенерированного для текущего пользователя.

Требования к окружению

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

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

Форматы подписи

REST-интерфейс Сервиса Подписи DSS позволяет подписывать документы, используя следующие форматы электронной подписи:

Типовые ошибки