Методы шифрования. от плагинов для браузера до криптопровайдеров

Извлечение информация из подписи

Часто в системах работающих с криптографией требуется печатное представление подписи. В каждом случае оно разное, поэтому лучше сформировать класс информации о подписи, который будет содержать информацию в удобном для использования виде и уже с его помощью обеспечивать печатное представление. Net такой класс есть — SignedCms, однако его аналог в mono c подписями КритоПро, во первых отказывается работать, во вторых содержит модификатор sealed и в третьих почти все свойства у него закрыты на запись, поэтому придется формировать свой аналог.

Сама по себе подпись содержит два основных элемента — список сертификатов и список подписантов. Список сертификатов может быть пустой, а может содержать в себе все сертификаты для проверки, включая полные цепочки. Список же подписантов указывает на кол-во реальных подписей. Связь между ними осуществляется по серийному номеру и издателю (Issuer). Теоретически в одной подписи может быть два сертификата от разных издателей с одним серийным номером, но на практике этим можно пренебречь и искать только по серийному номеру.

Чтение подписи происходит следующим образом:

Извлечение информации из подписи

Разбор подписи происходит в несколько этапов, вначале формируется структура сообщения (CryptMsgOpenToDecode), затем в нее вносятся реальные данные подписи (CryptMsgUpdate). Остается проверить что это реально подпись и получить сначала список сертификатов, а потом список подписантов. Список сертификатов извлекается последовательно :

Получение списка сертификатов

Сначала определятся количество сертификатов из параметра CMSG_CERT_COUNT_PARAM, а затем последовательно извлекается информация о каждом сертификате. Завершает процесс создания формирование контекста сертификата и на его основе самого сертификата.

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

Извлечение информации о подписанте

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

После извлечения сертификата необходимо определить параметры подписи, самая важная из которых — дата подписания (даже если это не верифицированная сервером штампа даты времени, для отображения она очень важна).

Список атрибутов подписи

Атрибуты представляют из себя вложенный справочник вида Oid – список значений (по сути это разобранная структура ASN. Пройдя по первому уровню формируем вложенный список:

Разобрать атрибут подписи

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

Обернув представленные выше методы в два класса — информация о подписи и информация о подписанте — получаем аналог SignedCms, из которой при формировании печатного вида извлекаем данные.

Шифрование

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

Процесс шифрования происходит в три этапа — заполнение параметров, определение длины и наконец шифрование. Зашифрованные данные могут быть большие, вероятно, поэтому метод поддерживает режим двух вызовов.

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

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

Получение алгоритма шифрования

В примере извлекается контекст закрытого ключа и по нему происходит поиск по алгоритмам. Но в этом списке находятся все алгоритмы (обмена ключей, хэширования, подписи, шифрования и проч. ), поэтому надо отфильтровать только алгоритмы шифрования. Пытаемся по каждому извлечь информацию ограничившись группой алгоритмов шифрования (UCConsts. CRYPT_ENCRYPT_ALG_OID_GROUP_ID). И если информация найдена — значит это наш алгоритм.

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

Дешифрование

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

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

Проверка сертификата

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

• целостность цепочки (сертификат издателя, сертификат издателя сертификата издателя, и т. п.);
• сертификат корневого издателя — должен быть в хранилище доверенных корневых центров;
• период действия всех сертификатов — момент использования сертификата должен быть в границах этого периода;
• каждый из сертификатов в цепочке, кроме корневого, должен отсутствовать в списке отозванных у своего издателя (CRL);

По хорошему надо еще проверять и права подписи, но в реальной жизни это делается редко.

Как уже понятно из введения, проверка сертификата на валидность, одна из самых сложных задач. Именно поэтому в библиотеке масса методов для реализации каждого из пунктов в отдельности. Поэтому, для упрощения обратимся к исходникам. Net для метода X509Certificate2. Verify() и возьмем их за основу.

Проверка состоит из двух этапов:

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

Такая проверка должна осуществляться перед подписанием и шифрованием на текущую дату, и в момент проверки подписи на дату подписания. Сам метод проверки небольшой:

Сначала формируется цепочка методом BuildChain, а затем она проверяется. В ходе формирования цепочки формируется структура параметров, дата проверки и флаги проверки:

Формирование цепочки сертификата

Это сильно упрощенный вариант формирования цепочки по сравнению с тем, как ее формирует Microsoft. Структуры hCertPolicy и hAppPolicy можно наполнить OID-ами, отображающими права на действия, которые необходимы в проверяемом сертификате. Но в примере, будем считать, что их мы не проверяем.

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

Метод MapRevocationFlags — можно взять напрямую из исходников. Net без изменений —он просто формирует uint по набору передаваемых флагов.

Заключение

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

• ожидание 10 мс;
• извлечение сертификата;
• проверка полученной подписи;
• извлечение параметров подписи;
• дешифрование полученных данных;

Данный цикл был запущен в Windows и в Linux в 1-ом, 10-и и 50-и потоках, чтобы проверить работу в Linux сразу в нескольких потоках. Приложение в Linux работало стабильно в течении какого-то времени во много-поточном режиме (и чем больше потоков, тем меньше по времени), а затем «вставало» наглухо. Что свидетельствует о наличии взаимной блокировки (deadlock-е) в библиотеке (при нарушении работы с потоками связанных с разделяемым доступом обычно происходит падение с «Access Violation»).

По этой причине для обеспечения стабильности работы все методы класса UCryptoAPI стоит обрамить критической секцией. Для этого добавляем поле fpCPSection типа object после чего в каждый вызов добавляем следующую конструкцию:

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

Нагрузочное тестирование так же показало утечки памяти в mono при обращении к полям Issuer и Subject сертификата. Утечка, вероятно, происходит при попытке mono сформировать классы X500DistinguishedName для подписанта и издателя. К счастью, mono посчитали этот процесс достаточно ресурсоемким (или же они знают об утечке), поэтому предусмотрели кэширование результата данного формирования во внутренние поля сертификата (impl. issuerName и impl. subjectName). Поэтому данная утечка лечится прямой записью через отражение (Reflection) в эти поля экземпляров класса X500DistinguishedName, сформированных на базе значений из структуры CERT_CONTEXT сертификата.

Подключение в коде

Анализ методов библиотек криптографии оказался удачным, т. КриптоПро реализовало библиотеку «libcapi20. so» которая полностью мимикрирует под стандартные библиотеки Windows шифрования — «crypt32. dll» и «advapi32. dll». Возможно, конечно, не целиком, но все необходимые методы для работы с криптографии там в наличии, и почти все работают.

Поэтому формируем два статических класса «WCryptoAPI» и «LCryptoAPI» каждый из которых будет импортировать необходимый набор методов следующим образом:

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

А затем формируем статический класс «UCryptoAPI» который в зависимости от системы будет вызывать метод одного из двух классов:

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

Поиск сертификата

Работа с криптографией обычно начинается с поиска сертификата, для этого в crypt32. dll имеется два метода CertOpenStore (открывает указанное хранилище сертификатов) и простой CertOpenSystemStore (открывает личные сертификаты пользователя). В силу того, что работа с сертификатами не ограничивается только личными сертификатами пользователя подключаем первый:

Поиск происходит в несколько этапов:

• открытие хранилища;
• формирование структуры данных по которым ищем;
• поиск сертификата;
• если требуется, то проверка сертификата (описана в отдельном разделе);

В ходе поиска сертификатов есть несколько тонких моментов.

КриптоПро в Linux работает с ANSI строками, а в Windows с UTF8, поэтому:

• передавая строку для поиска (например, по имени Subject) ее необходимо преобразовывать в набор байт различными кодировками;
• для всех констант криптования, у которых есть вариация по типу строки (например, CERT_FIND_SUBJECT_STR_A и CERT_FIND_SUBJECT_STR_W) в Windows необходимо выбирать *_W, а в Linux *_A;

Метод MapX509StoreFlags можно взять напрямую из исходников Microsoft без изменений, он просто формирует итоговую маску исходя из. Net флагов.

Значение по которому происходит поиск зависит от типа поиска (сверяйтесь с MSDN для CertFindCertificateInStore), в примере приведены два самых часто используемых варианта — для строкового формата (имена Subject, Issuer и проч) и бинарного (отпечаток, серийный номер).

Процесс создания сертификата из IntPtr в Windows и в Linux сильно отличается. Windows создаст сертификат простым способом:

в Linux же приходиться создавать сертификат в два этапа:

В дальнейшем нам для работы потребуется доступ к hCert, и его надо бы сохранить в объекте сертификата. В Windows его позже можно достать из свойства Handle, однако Linux преобразует структуру CERT_CONTEXT, лежащую по ссылке hCert, в ссылку на структуру x509_st (OpenSSL) и именно ее прописывает в Handle. Поэтому стоит создать наследника от X509Certificate2 (ISDP_X509Cert в примере), который сохранит у себя в отдельном поле hCert в обеих системах.

Не стоит забывать, что это ссылка на область неуправляемой памяти и ее надо освобождать после окончания работы. Net 4. 5 X509Certificate2 не Disposable — очистку методом CertFreeCertificateContext, надо проводить в деструкторе.

Формирование подписи

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

В ходе работы метода формируется структура с параметрами и вызывается метод подписания. Структура параметров может позволять сохранить в подписи сертификаты для формирования полной цепочки (поля cMsgCert и rgpMsgCert, первый хранит количество сертификатов, второй список ссылок на структуры этих сертификатов).

Метод подписания может получать один или несколько документов для одновременного подписания одной подписью. Это, кстати, не противоречит 63 ФЗ и бывает очень удобно, т. пользователь вряд ли обрадуется необходимости несколько раз нажимать на кнопку «подписать».

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

Единственной серьезной проблемой является поиск OID алгоритма хэширования (Digest) используемый при подписании — в явном виде его нет в сертификате (там есть только алгоритм самой подписи). И если в Windows его можно указать пустой строкой — он подцепится автоматически, но Linux откажется подписывать если алгоритм не тот.

Но тут есть хитрость — в информации об алгоритме подписи (структура CRYPT_OID_INFO) в pszOID храниться OID подписи, а в Algid — храниться идентификатор алгоритма хэширования. А преобразовать Algid в OID уже дело техники:

Получение OID алгоритма хэширования

Внимательно прочитав код можно удивится, что идентификатор алгоритма получается простым способом (CertOIDToAlgId) а Oid по нему — сложным (CryptFindOIDInfo). Логично было бы предположить использование либо оба сложных, либо оба простых способа, и в Linux оба варианта успешно работают. Однако в Windows сложный вариант получения идентификатора и простой получения OID работает нестабильно, поэтому стабильным решением будет вот такой странный гибрид.

Проверка подписи

Проверка подписи происходит в два этапа, в начале проверяется сама подпись, а затем проверяется сертификат, которым она была сформирована (цепочка, дата подписания и проч). Так же как и при подписании необходимо указать набор подписываемых данных, параметры подписи и саму подпись:

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

После извлечения сертификата подписанта преобразуем его в наш класс и проверяем (если это указано в параметрах метода). Для проверки используется дата подписания первого подписанта (см. раздел извлечение информации из подписи, и раздел проверка сертификата).

ООО КРИПТО-ПРО

Дата регистрации16. 1999

Юридический адресГ. Москва МУНИЦИПАЛЬНЫЙ ОКРУГ ИЗМАЙЛОВО ПРОЕЗД ИЗМАЙЛОВСКИЙ 10 КОРПУС 2 ПОМЕЩ. 4/1

ИНН / КПП7717107991771901001

Среднесписочная численность 153 сотрудников

Читать в полной версии

Лица имеющие право действовать от имени юридического лица без доверенности

ФИОДолжностьЧернова Наталья ГеоргиевнаГенеральный Директор

Топ учредителей компаниий, указан на основании данных из ЕГРЮЛ

ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ “ЗНАКИ И СИМВОЛЫ” Юридическое лицо (Резидент РФ) ОГРН 1197746587774

ДОЛЯ В УСТАВНОМ КАПИТАЛЕ

Сведения о видах деятельности организации в соответствии с данными ЕГРЮЛ

Разработка компьютерного программного обеспечения

Технические испытания, исследования, анализ и сертификация

Торговля оптовая прочей офисной техникой и оборудованием

Деятельность агентов по оптовой торговле универсальным ассортиментом товаров

Деятельность консультативная и работы в области компьютерных технологий

Деятельность по управлению компьютерным оборудованием

Аренда и лизинг офисных машин и оборудования, включая вычислительную технику

Деятельность профессиональная, научная и техническая прочая, не включенная в другие группировки

Копирование записанных носителей информации

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

Торговля оптовая компьютерами, периферийными устройствами к компьютерам и программным обеспечением

Издание прочих программных продуктов

Деятельность, связанная с использованием вычислительной техники и информационных технологий, прочая

Научные исследования и разработки в области естественных и технических наук прочие

Деятельность в области права

Производство компьютеров и периферийного оборудования

Весь список в полной версии

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

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

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

Спецификация-
ПлатформыСемейство Windows, GNULinux, OS X
Алгоритмы и криптографические протоколыЭЦП, шифрование, хэш-функция, имитозащита, HMAC
Интеграция с PKIX. 509, PKCS#10, CMS, CRL, OCSP (КриптоПро ЭЦП Browser plugin), TSP (КриптоПро ЭЦП Browser plugin)
Механизмы ЭЦППрограммный интерфейс для использования в JavaScript

Механизмы аутентификацииЭЦП случайных данных
Механизмы “гостирования” TLS-
Форматы защищенных сообщенийPKCS#7, CMS, XMLSec (КриптоПро ЭЦП Browser plugin), CADES (КриптоПро ЭЦП Browser plugin)
Интеграция с браузеромActiveX (для IE)
NPAPI

Мобильные платформыне поддерживаются
Хранилища ключейРеестр, файлы, USB-токены
Взаимодействие с USB-токенамиХранилище ключей и сертификатов
Использование аппаратной реализации алгоритмов
Через PKCS#11, через CryptoAPI

ПриложенияБраузеры
ИнсталляцияПрограмма установки, не требуются права системного администратора
Примеры (ГОСТ)КриптоПро ЭЦП Browser plugin
eSign-PRO
КриптоПлагин Лисси
Плагин портала госуслуг
JC-WebClient
Рутокен Плагин
Плагин BSS
КриптоАРМ Browser plugin

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

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

ActiveX

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

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

Ссылки

• документация КриптоПро CAPILite
• ресурс c объявлением стандартных экспортируемых функций в С#
• исходники .Net:
  класс CAPIBaseкласс X509Certificate2класс SignedCMSкласс SignerInfo
• класс CAPIBase
• класс X509Certificate2
• класс SignedCMS
• класс SignerInfo
• исходники mono:
  класс X509Certificate2класс X509CertificateImplBtls
• класс X509CertificateImplBtls

Электронная подпись по Российским нормативам

В первой части статьи речь шла об использовании электронной подписи в коммерческих предприятиях. В государственных предприятиях и банках все немного иначе. Здесь нужно использовать сертифицированный криптопровайдер, а сами ключи должны храниться на токенах. Поэтому во второй части этой статьи будет показано, как использовать сертифицированный криптопровайдер и токены для хранения ключей вне компьютера. Сперва мы поговорим о криптопровайдере, а потом уже рассмотрим практическое использование программы. На просторах России сертифицированные криптопровайдеры предоставляют не так уж и много компаний: ООО «КРИПТО-ПРО», ООО «Лисси», ОАО «ИнфоТеКС», ЗАО «Сигнал-КОМ» и некоторые другие. Программа CyberSafe поддерживает работу с сертифицированным криптопровайдером от ООО «КРИПТО-ПРО», что обеспечивает возможность формирования и проверки электронной подписи в соответствии с отечественными стандартами ГОСТ Р 34. 11-94 / ГОСТ Р 34. 11-2012 и ГОСТ Р 34. 10-2001 / ГОСТ Р 34. 10-2012.

Можно ли использовать программу CyberSafe?

Одно дело — шифрование личных файлов, но государственный и банковский сектор — совсем другое. Какие нормы позволяют считать CyberSafe программой, использующей сертифицированное ФСБ России СКЗИ и не требующей соответствующей сертификации? Ответ на этот вопрос можно получить в паспорте (формуляре) на программный продукт КриптоПро CSP и в методических рекомендациях по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации. Последние утверждены ФСБ России 21 февраля 2008 года № 149/54-144. В паспорте на КриптоПро CSP читаем п. 1 из раздела 2:

Допускается использование СКЗИ для криптографической защиты персональных данных

Далее открываем методические рекомендации и читаем пункт 1 из раздела 5:

Встраивание криптосредств класса КС1 и КС2 осуществляется без контроля со стороны ФСБ России (если этот контроль не предусмотрен техническим заданием на разработку (модернизацию) информационной системы).

В соответствии с Требованиями к средствам ЭП и Требованиями к средствам УЦ, которые утверждены приказом ФСБ России от 27 декабря 2011 г. № 796, устанавливается шесть классов криптосредств – КС1, КС2, КС3, КВ1, КВ2, КА1. Встраивание криптосредств класса КС3, КВ1, КВ2 и КА1 осуществляется только под контролем со стороны ФСБ России. Что же касается классов КС1 и КС2, то никакого контроля со стороны ФСБ не осуществляется. Подробнее о классах криптографической защиты вы можете прочитать по ссылке, которая приводится в конце статьи. Как видите, CyberSafe использовать не только можно, но и нужно. Исходный код библиотеки шифрования, которую использует программа, доступен всем желающим (ссылка на него есть на главной странице сайта cybersafesoft. com) по адресу: www. assembla. com/spaces/cybersafe-encryption-library/wiki
Далее приводится код функции шифрования и подписи, чтобы убедиться в надежности реализации (лист.

Листинг 1. Функция шифрования и подписи (ГОСТ)

Практическое использование программы

Рис. КриптоПро CSP успешно установлен

Далее запустите программу CyberSafe. При первом запуске после установки КриптоПро CSP нужно обязательно установить сертификат CyberSafe GOST CA (рис.

Рис. Установите сертификат

После установки сертификата CyberSafe GOST CA самое время поговорить о токенах. Токен — это USB-устройство, которое используется для авторизации пользователя, защиты электронной переписки, безопасного доступа к удаленным информационным ресурсам, а также для хранения криптографических ключей. Поскольку токены — довольно дорогие устройства, программа CyberSafe может вместо них использовать обычные флешки. На флешке будут храниться помещенные на нее ключи. Однако на токенах ваши ключи защищены от копирования, а на флешке — нет. Но учитывая стоимость токенов, такое решение вполне оправдано. Другими словами, программа CyberSafe экономит ваши деньги. При использовании как токенов, так и обычных флешек для хранения ключей, ваши ключи будут храниться не на компьютере, а на внешнем носителе (токене или флешке). Итак, создадим сертификат Крипто-Про. Выберите команду меню Сертификаты, Создать. В окне Создание сертификата введите адрес электронной почты, пароль, наименование и другую информацию. Убедитесь, что вы включили флажок Создать Крипто-Про сертификат (рис. Если этого флажка нет, убедитесь, что вы установили КриптоПро CSP и после установки перезапустили CyberSafe.

Рис. Создание сертификата Крипто-Про

Следующий шаг — очень важен. Вам нужно выбрать, где именно хранить контейнер закрытого ключа — на USB-диске (рис. 4а) или на токене (рис. 4б). Выберите токен или съемный диск, на котором вы хотите хранить сертификат (только убедитесь в правильности выбора), или же выберите Реестр, если вы хотите хранить сертификат в компьютере.

Рис. Сертификат будет храниться на флешке

Рис. Сертификат будет храниться на токене

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

Рис. Процесс создания ключа

Далее нужно создать пароль для самого контейнера (рис. 6а) или pin-код (рис. 6б) — для токена. Этот пароль должен отличаться от пароля сертификата по соображениям безопасности.

Рис. Пароль контейнера (флешка)

Рис. Pin-код для контейнера (токен)

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

Рис. Сертификат успешно создан

Рис. Введите код подтверждения публикации сертификата

Во время публикации сертификата вы увидите, что он состоит из шести файлов (рис. После публикации сертификата вы увидите сообщение об его успешной публикации на сервере. Ясное дело, что на момент публикации соединение с Интернетом должно быть установлено. Откройте Проводник и просмотрите содержимое флешки. В каталоге <наименование>. 000 вы обнаружите закрытые ключи (рис. 10).

Рис. Процесс публикации сертификата

Рис. Закрытые ключи

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

Рис. Созданный сертификат в общем списке

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

Рис. Шифрование файлов по ГОСТу

Аналогично, при прозрачном шифровании папки (когда нужно зашифровать все файлы из этой папки) вам нужно выбрать криптопровайдер Крипто Про ГОСТ из соответствующего списка (рис. 13).

Рис. Выбор криптопровайдера при прозрачном шифровании

Также выбрать шифрование по ГОСТу можно выбрать при шифровании диска/раздела (см. рис. 14). В списке Тип шифрования нужно выбрать ГОСТ и установить параметры шифрования.

Рис. Шифрование диска

Выводы

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

Уровень криптографической защиты при реализации обмена электронными сообщениями, защищенными электронной подписью
Формуляр ЖТЯИ. 00050-03 30 01 (КриптоПро CSP)
Методические рекомендации
Исходный код библиотеки шифрования
Первая часть статьи