Производители средств криптографической защиты информации (СКЗИ) предлагают различные механизмы для интеграции криптосредств в информационные системы. Существуют решения, ориентированные на поддержку систем с Web-интерфейсом, мобильных и десктопных приложений, серверных компонентов. СКЗИ интегрируются в приложения Microsoft и в продукты Open Source, обеспечивают поддержку различных прикладных протоколов и форматов электронной подписи.

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

В данном материале сделана попытка классифицировать средства криптографической защиты информации.

• Рассмотрены в основном СКЗИ, использующиеся на клиентских местах для защиты клиент-серверных соединений по протоколу TLS, для организации ЭЦП, шифрования передаваемых данных;
  
• Не рассматриваются СКЗИ, применяемые для создания VPN и шифрования файловой системы, хранимых данных, а так же УЦ;
  
• Отдельно выделены аппаратные криптографические устройства.

Классификация построена на основе:

• технологий интеграции (CryptoAPI, Active-X, NPAPI и др.), которые поддерживают СКЗИ для встраивания в приложения и прикладные системы;
• интерфейсов, которые предоставляют СКЗИ для встраивания в приложения и прикладные системы.

Кроме того, показаны способы интеграции СКЗИ с Web-приложениями и возможность его использования на мобильных платформах

Общая схема классификации приведена в таблице:

Криптопровайдеры	Нативные библиотеки (openssl-style, PKCS#11, NSS, собственные интерфейсы)	Локальные прокси	Браузерные плагины	Облачная подпись	Браузеры с российской криптографией
Почтовые клиенты с российской криптографией	Российская криптография в фреймворках, платформах, интерпретаторах	Настольные криптографические приложения	Криптография в BIOS UEFI	Сервис-провайдеры ЭЦП	Эмуляторы доверенной среды
Аппаратные средства

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

Сравнительно недавно я решил перевести домашний компьютер с Windows на Linux. То есть идея такая бродила уже некоторое время, подогреваемая новостями с фронтов борьбы с добровольно-принудительной установкой Windows 10 и размышлениями о неизбежном устаревании «семерки» следом за XP, а вот поводом взяться за дело стал выход очередного LTS-релиза Ubuntu. При этом основным мотивом такого перехода я назову простое любопытство: домашний компьютер используется в основном для развлечений, ну а знакомство с новой ОС — развлечение не хуже прочих. Причем развлечение, как мне кажется, полезное в плане расширения кругозора. Дистрибутив же от Canonical был выбран просто как наиболее популярный: считаю при первом знакомстве с системой это немаловажным подспорьем.

Довольно быстро я на собственном опыте убедился, что для котиков и кино Ubuntu вполне подходит. Но, поскольку компьютер используется еще и для удаленной работы, для отказа от Windows не хватало настроенного подключения к Cisco VPN c авторизацией по eToken.

Набор программ

Было ясно, что для подключения понадобятся по меньшей мере драйвер токена и некий VPN-клиент. В результате поисков в сети получился такой список:

1. OpenConnect — VPN-клиент, «совершенно случайно» совместимый с серверами Cisco «AnyConnect»
2. GnuTLS — свободная реализация протоколов TLS и SSL. Что важно, в состав этой библиотеки входит утилита p11tool для работы со смарт-картами
3. SafeNet Authentication Client — набор драйверов и дополнительных утилит, обеспечивающий работу с электронными ключами eToken

Поскольку для установки соединения OpenConnect-у требуется URL сертификата клиента, который можно узнать с помощью утилиты p11tool, и обеим программам требуется драйвер для работы со смарт-картой — с установки этого драйвера и начнем.

Токены PKCS#11 выполняют не только криптографические функции (генерация ключевых пар, формирование и проверка электронной подписи и другие), но и являются хранилищем для публичных (открытых, PUBLIC KEY) и приватных (закрытых, PRIVATE KEY) ключей. На токене также могут храниться сертификаты. Как правило, на токене хранятся личные сертификаты вместе с ключевой парой. При этом на токене может храниться несколько личных сертификатов.

Встает дилемма, как определить какой закрытый ключ (да и открытый тоже) соответствует тому или иному сертификату.

Такое соответствие, как правило, устанавливается путем задание идентичных параметров CKA_ID и/или CKA_LABEL для тройки объектов: сертификата (CKO_CERTIFICATE), публичного ключа (CKO_PUBLIC_KEY) и приватного ключа (CKO_PRIVATE_KEY).

С появлением библиотеки GCrypt-1.7.0 с поддержкой российской криптографии (ГОСТ 28147-89, ГОСТ Р 34.11-94/2012 и ГОСТ Р 34.10-2001/2012), стало возможным говорить о поддержке российского PKI в таких проектах как Kleopatra и KMail.

KMail – это почтовый клиент, который для обеспечения безопасности переписки позволяет подписывать и шифровать сообщения по протоколу S/MIME. И то и другое базируется на архитектуре PKI, сертификатах X509 и протоколах CMS/PKCS#7:

В настоящей статье описывается процесс настройки двухфакторной аутентификации по смарт-картам и USB-токенам JaCarta PKI на основе цифровых сертификатов X.509 в OpenVPN.

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

В предыдущей статье в качестве инструментария для создания графического интерфейса для утилит командной строки на базе Tcl/Tk был рассмотрен конструктор tkBuilder. Конструктор хорош, но как было отмечено в статье обладает и рядом недостатков, главным из которых является отсутствие поддержки UTF-8, а следовательно, и русского алфавита. Еще один недостаток был отмечен пользователем merlin-vrn. Это поддержка на сегодняшний день только Tcl/Tk версии 8.4.

И сразу дадим ответ – да, можно и нужно, только не отказаться, а дать гражданам и организациям возможность использовать и другие операционные системы, браузеры и средства криптографической защиты информации (СКЗИ). Ответим на вопрос и как – соблюдать стандарты и технологии. Почему бы для доступа в личные кабинеты не использовать авторизованный доступ по протоколу https? И тогда нет необходимости в использования только CSP а ля Микрософт с поддержкой российской криптографии. Тогда автоматом станут востребованы и токены PKCS#11 и как международный стандарт, так и стандарт, поддерживаемый ТК-26, стандарты PKCS#12 (тем же ТК-26), может что-то другое, но стандартное. В этом случае речь уже будет идти не об MS Windows, Interner Explorer и CSP, а о браузерах или других программ с поддержкой https с российскими шифрсьютами. Это может быть и Internet Explorer, и модификации того же Mozilla Firefox, наконец Google Chrome или прокси типа stunnel.

Название статьи подсказала тема на одном из форумов. Несмотря на то, что с момента возникновения вопроса прошло шесть лет, в этом направлении мало что изменилось. А поскольку в последнее время у меня на слуху постоянно был OpenVPN, то было решено исправить данную ситуацию. Так родилась графическая утилита VpnGUI для создания, редактирования, запуска и контроля выполнения утилиты openvpn.

После запуска утилиты VpnGUI в трее появится иконка (квадрат разбитый на четыре сине-красных квадратика) утилиты:

Криптографические токены/смарткарты сегодня стали довольно обыденным делом. Все больше людей идут на Удостоверяющие Центры (УЦ) и просят выдать ключик и электронную подпись для доступа к различным сайтам для получения тех или иных услуг. Попытка объяснить, что им выдадут сертификат по аналогии с паспортом, а электронную подпись они будут ставить сами, используя свой закрытый ключ, мало кого и в чем убеждает.

Есть магическое слово – ключик, а на нем есть что-то, что позволит отправить данные в налоговую, участвовать в торгах и т.п. И УЦ выдают гражданам и организациям «ключики» с сертификатами и закрытыми ключами. Сегодня в абсолютном большинстве этими ключиками являются токены. Так и хочется сказать -криптографические токены с поддержкой российской криптографией и интерфейсом PKCS#11. К сожалению это далеко не так. Несмотря на то, что и производителей и объем токенов растет, используются все же они в большинстве случаев как обыкновенная флэшка, но с доступом к ней по PIN-коду.

Одним из центральных объектом инфраструктуры открытых ключей (Public Key Infrastructure — PKI/ИОК) наряду с ключевой парой является сертификат, который сегодня фактически является аналогом гражданского паспорта.

Если одним из главных объектов инфраструктуры открытых ключей (ИОК) являются сертификаты X509, то центральным субъектом ИОК являются Удостоверяющие Центры (УЦ). Именно УЦ выпускают сертификаты, прекращают их действие (отзыв сертификата), подтверждают их валидность. На страницах Хабрахабр можно найти различные публикации на тему выпуска цифровых сертификатов с использованием OpenSSL.

Неумолимо приближается час «Ч»: «использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается!». И вот, наконец, 16 июля 2018 г. на сайте Федерального ситуационного центра электронного правительства появилось Уведомление о начале выпуска сертификатов ключей проверки электронных подписей подчиненных удостоверяющих центров на головном удостоверяющем центре в соответствии с ГОСТ Р 34.10-2012. Правда, все равно не ясно когда же прекратится выпуск старых сертификатов. Но «процесс пошел» и это радует.

Когда мы говорим о дистрибутиве операционной системы, то речь впервую очередь идет не об ядре операционной системы, а о тех приложениях, которые входят в состав дистрибутива. А когда мы говорим об импортозамещение операционных систем, то речь идет о той или иной версии Linux. Ничего другого на российском рынке для импортозамещения не предлагается. Что касается ядра linux, то за его развитие отвечает Ли́нус Бенедикт То́рвальдс. И честно говоря мне ничего неизвестно, про российское ядро linux. А вот окружение любого дистрибутива linux разрабатывается различными организациями, все их и не перечислить: KDE, Mozilla, Google, IBM и т.д. и т.д. И следовало бы ожидать, что с появлением отечественных ОС аля linux этот список будет расширен отечественными разработками или модификациями. Но этого нет. Нет, это не обязательно отечественный браузер или почтовый клиент в этих дистрибутивах. Но что-то доработанное с учетом российских реалий в цифровой экономике хотелось бы видеть. Остановимся на этом.

В комментариях к статье «Англоязычная кроссплатформенная утилита для просмотра российских квалифицированных сертификатов x509» было пожелание от пользователя Pas иметь не только «парсинг сертификатов», но и получать «цепочки корневых сертификатов и проводить PKI-валидацию, хотя бы для сертификатов на токенах с неизвлекаемым ключом». О получении цепочки сертификатов рассказывалось в одной из предыдущих статей. Правда там речь шла о сертификатах, хранящихся в файлах, но мы обещали добавить механизмы для работы с сертификатами, хранящимися на токенах PKCS#11. И вот что в итоге получилось.

Транспортный синтаксис ASN.1 определяет однозначный способ преобразования значений переменных допустимых типов в последовательность байт для передачи по сети. В ASN.1 он называется базовыми правилами кодирования (Basic Encoding Rules, BER). Правила являются рекурсивными, так что кодирование составных объектов представляет собой составление в цепочку закодированных последовательностей составляющих объектов. Протокол ASN.1 описывает структуру данных простым и понятным языком.

В своих комментариях к статье «Англоязычная кроссплатформенная утилита для просмотра российских квалифицированных сертификатов x509» пользователь Pas очень правильно заметил про токены PKCS#11, что они «сами все умеют считать». Да, токены фактически являются криптографическими компьютерами. И естественным является желанием использовать эти компьютеры в скриптовых языках будь то Python, Perl или Ruby. Мы уже так или иначе рассматривали использование токенов PKCS#11 с поддержкой российской криптографии в Python для подписания и шифрования документов, для создания запроса на сертификат:

В свое время реализация отечественных криптографических алгоритмов в библиотеке libgcrypt очень меня вдохновила. Стало возможным задействовать эти алгоритмы и в Kleopatra и в Kmail и в GnuPg в целом, рассматривать библиотеку libgcrypt как альтернативу openssl с ГОСТ-ым engine. И все было замечательно до прошлой пятницы.

В комментариях к статье «Использование механизмов криптографических токенов PKCS#11 в скриптовых языках» читатель kovserg написал:

«С нетерпением ждём статью с функцией подписания документа и добавлением метки времени».

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

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

Прошло время и утилита, начатая как просмотрщик сертификатов, дополненная функциями работы с криптографическими токенами PKCS#11 и создания запросов (PKCS#10) на квалифицированный сертификат, пополнилась, как и было заявлено, функциями работы с контейнерами PKCS#12.


Загружаем, запускаем утилиту cryptoarmpkcs и нажимаем кнопку «PKCS12»: