Портал о ремонте ванной комнаты. Полезные советы

Инструкция по генерации ключа электронной подписи. Инструкция по генерации ключа электронной подписи Создание ключа и заявки PKCS#10 на сертификат

Электронная подпись (далее - ЭП), согласно Федеральному закону Российской Федерации № 63-ФЗ от 25 марта 2011 года «Об электронной подписи», определяется как информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию. Указанный нормативный акт пришел на смену утратившему с 1 июля 2013 г. юридическую силу Федеральному закону Российской Федерации № 1-ФЗ от 10 января 2002 года «Об электронной цифровой подписи».

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

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

Разбор конфликтов, связанных с ЭП

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

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

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

Придание ЭП юридической значимости с помощью PKI

В законе "Об электронной подписи" различают ключ ЭП и ключ проверки ЭП. Ключ электронной подписи - это уникальная последовательность символов, предназначенная для создания электронной подписи.ключ проверки электронной подписи - это уникальная последовательность символов, однозначно связанная с ключом электронной подписи и предназначенная для проверки подлинности электронной подписи. Ключ проверки ЭПвыводится из ключа ЭП, но обратная операция невозможна. Таким образом, между ключом ЭП и ключом проверки ЭП имеется однозначное соответствие. Ключ ЭП должен создаваться самим клиентом и храниться в секрете. Именно этот ключ служит для подписывания документов электронной подписью. Ключ проверки ЭП служит для проверки ЭП и раздается всем желающим проверить подпись.

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

Таким образом, для проверки подписи и идентификации подписанта достаточно сертификата подписанта. То есть подписант подписывает документ своим ключом ЭП, а затем посылает получателю этот подписанный документ и свой сертификат, содержащий ключ проверки ЭП. Таким образом получатель сможет проверить, что подпись действительно была сделана ключом ЭП подписанта и получит идентификационные данные подписанта из сертификата. Клиент должен защищать свой ключ ЭП от компрометации. Именно с этой целью создаются различные аппаратные ключевые хранилища с повышенным уровнем защиты, например, USB-устройство ruToken.

Российский стандарт ЭП

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

Российским стандартом ЭП первого уровня является ГОСТ 34-10.2012. Российским стандартом ЭП второго уровня является PKCS#7 с возможностью добавления временных меток TSA.

Сферы применения ЭП

  • интернет-банк
  • электронная торговая площадка
  • системы корпоративного документооборота
  • электронная почта
  • сдача отчетностей в различные федеральные службы
  • авторское право

WEB-сайт с ЭП

Постановка задачи

Предположим в вашей организации принято решение перейти на систему электронного документооборота, построенную на web-технологиях. При этом основными местами, в которых требуется ЭП являются:

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

Схема решения

Создание удостоверяющего центра

    выделить сервер, на котором будет развернут Удостоверяющий центр. Опционально могут быть развернуты службы временных меток и online-проверки статуса сертификата. УЦ и указанные службы в целях экономии могут быть использовать один сервер, который должен быть доступен online. Целесообразность этих служб мы обсудим ниже.

    установить на сервер продукт МагПро КриптоПакет

    создать ключ УЦ и заявку на корневой сертификат УЦ с помощью утилиты mkkey из состава МагПро КриптоПакет . Ключ может быть создан на защищенном устройстве, например, на ruToken. После создания ключа УЦ требуется обеспечить его безопасность организационными методами. Наиболее безопасным вариантом является хранение ключа на устройстве ruToken и поключение его к серверу только при выдаче сертификатов. Сертификат УЦ представляет из себя файл. Этот файл впоследствии будет выдаваться всем клиентам УЦ при получении ими сертификата.

    создать корневой сертификат УЦ с помощью утилиты openssl из состава МагПро КриптоПакет .

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

Создание ключа и заявки PKCS#10 на сертификат

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

Наиболее безопасной схемой получения сертификата является распределенная. Пользователь создает ключ, создает заявку PKCS#10 на сертификат, которая содержит его ключ проверки ЭП и идентификационные данные. Эту заявку пользователь подписывает своим ключом ЭП и относит в УЦ. УЦ проверяет подпись под заявкой, сверяет идентификационные данные пользователя, например, с паспортными и выдает сертификат. Затем производится распечатка сертификата и пользователь подписывает ручной подписью документ о соответствии выданного сертификата.

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

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

После создания ключа пользователь должен обеспечить его безопасное хранение

Виды сертификатов для ЭП на WEB-сайте

В нашем портале будут использоваться несколько видов сертификатов:

    корневой сертификат УЦ

    Данный сертификат используется для проверки всех остальных сертификатов участников Web-портала.

    сертификат TLS-аутентификации сервера

    Данный сертификат используется для проверки сервера клиентом при создании защищенного TLS-соединения при передаче подписанных документов на web-сайт

    сертификат TLS-аутентификации клиента

    Данный сертификат используется для проверки клиента сервером и для доступа клиента в его личный кабинет при создании защищенного TLS-соединения при передаче подписанных документов на web-сайт

    сертификат ЭП клиента

    Данный сертификат клиент добавляет в свою ЭП, и таким образом, проверяющая сторона может проверить подпись и идентифицировать подписанта

    сертификат подписи OCSP-сервера

    Данным сертификат OCSP-сервер добавляет в свой подписанный ответ для его удостоверения

    сертификат подписи TSA-сервера

    Данным сертификат TSA-сервер добавляет в свой подписанный ответ для его удостоверения и придания ему юридической значимости

Все эти виды сертификатов можно создать с помощью утилиты из МагПро КриптоПакет и УЦ на базе МагПро КриптоПакет .

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

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

Итак, на данный момент мы смогли развернуть УЦ и научились создавать ключи пользователей, принимать от них заявки на сертификаты и выдавать сертификаты по полученным заявкам. Получение и соответствие сертификата пользователь удостоверяет своей ручной подписью, и поэтому можно утверждать, что у нас развернута PKI, обеспечивающая юридическую значимость ЭП пользователя

Следующей задачей является использование развернутой PKI для решения прикладной задачи – организации безопасной передачи с помощью браузера подписанных электронных документов на Web-сайт и прием их в обработку на Web-сайт.

Модуль проверки и хранения ЭП (сервер)

Обычно Web-сайт развернут на некотором web-сервере (Apache, IIS, nginx и т.п.). Данный сайт содержит личный кабинет для каждого пользователя, который зарегистрирован на сайте. Для доступа в личный кабинет пользователь должен пройти процедуру аутентификации. Обычно аутентификация заключается в вводе догина и пароля, согласованных при регистрации пользователя.

Кроме того, для загрузки электронных документов на сервер используется web-форма ввода.

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

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

КриптоСервер устанавливается перед защищаемым Web-сервером. При этом Web-сервер настраивается таким образом, что принимает входящие соединения только от КриптоСервера (см. инструкцию по настройке). КриптоСервер принимает входящие HTTS-соединения, расшифровывает их и переадресует на Web-сервер. Кроме этого, КриптоСервер добавляет в HTTP-запрос заголовок X509-Cert, в котором передает цифровой сертификат клиента, прошедшего процедуру аутентификации. Этот сертификат затем используется для доступа клиента в его личный кабинет. Для проверки ЭП под передаваемыми документами в КриптоСервер входит утилита openssl, которая позволяет проверить разичные виды подписей, получить из конверта PKCS#7 сертификат подписанта или цепочку сертификатов и т.п. Для проверки ЭП web-страница приема документов должна произвести вызов данной утилиты.

Модуль выработки ЭП (клиент)

Основный задачей пользователя при доступе на Web-сайт является загрузка электронных документов и текстовых данных на сайт, а так же скачивание электронных документов с сайта. Для защиты web-соединения с сайтом по протоколу SSL/TLS и для online подписи данных, передаваемых на сайт, на клиентском рабочем месте следует использовать КриптоТуннель .

Основные достоинства КриптоТуннеля:

  • обеспечивает защиту web-соединений между любым браузером и сайтом по протоколу SSL/TLS c поддержкой российских криптоалгоритмов
  • позвoляет аутентифицировать пользователя по цифровому сертификату для доступа в личный кабинет пользователя
  • позволяет подписывать документы online при загрузке на сайт без использования CSP и Active X
  • поддерживает online-проверку статуса сертификата (OCSP)
  • поддерживает получение доверенных временных меток под ЭП (TimeStamp)
  • поддерживает различные USB-Tokenы и смарт-карты для хранения ключей
  • не требует установки на пользовательских местах, распространяется копированием
  • может храниться на обычной флешке и запускаться с нее
  • не требует для работы прав системного администратора
  • поддерживает работу с любым web-браузером (Internet Explorer, Mozilla FireFox, Google Chrome, Opera, Safari Apple и т.д.)
  • не имеет «привязки» к одному компьютеру – пользователь может использовать один комплект для использования в офисе и дома - экономия денежных средств
  • имеет простой и понятный пользовательский интерфейс, что позволяет обойтись без обучения пользователей
  • позволяет минимизировать затраты на техническую поддержку пользователей
  • может работать на большом спектре операционных систем (кроссплатформенное решение)
КриптоТуннель осуществляет подпись данных и файлов, передающихся через Web-форму, если эта Web-форма специальным образом промаркирована. То есть Web-форма должна содержать поле с заданным именем. Это имя прописывается в конфигурационном файле КриптоТуннеля и после этого КриптоТуннель начинает подписывать данные или файл, которые передаются в этом поле. Кроме того, в одном из hidden полей Web-формы может задаваться тип подписи (ATTACHED или DETACHED), а в другом hidden поле - URL службы доверенных временных меток. Имена этих полей так же должны быть заданы в конфигурационном файле КриптоТуннеля. Если подпись имеет тип DETACHED, то в конфигурационном файле КриптоТуннеля следует задать имя поля, в котором эта DETACHED-подпись будет отправлена на сервер. Там же следует задать имя поля, в котором на сервер будет отправлена временная метка.

Это ВСЕ действия, которые требуется произвести для того, чтобы КриптоТуннель начал подписывать данные и файлы, передаваемые через Web-форму. Не требуется писать каких-либо дополнительных скриптов, вызывать Active X и т.п.

Организация множественной ЭП

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

При использовании КриптоТуннеля пользователю не придется скачивать документ, а потом подписывать и снова загружать документ на сервер – все эти операции КриптоТуннель сделает автоматически при нажатии на кнопку на web-странице.

Служба OCSP

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

Наиболее простым способом является раздача списков отзыва (CRL). То есть УЦ создает и периодически обновляет специальный файл, который пользователи так же периодически скачивают.

Другим способом является использование службы online проверки статуса сертификата – службы OCSP. Для проверки статуса любого сертификата КриптоТуннель и КриптоСервер автоматически формируют OCSP-запрос, отправляют по сети этот запрос службе. Служба проверяет сертификат, подписывает результат проверки своей ЭП и возвращает клиенту ответ. Клиент смотрит ответ, проверяет под ним подпись и принимает решение – доверять ли данному сертификату или нет.

Создание службы OCSP возможно с помощью утилиты openssl из состава МагПро КриптоПакет . Следует иметь в виду, что выбор между CRL и OCSP всегда остается на усмотрение создателей сайта. CRL – немного дешевле, OCSP – немного безопаснее.

Следует отменить, что КриптоТуннель и КриптоСервер поддерживаеют как OCSP, так и CRL.

Служба временных меток TSA

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

Для создания временной метки КриптоТуннель создает TSA-запрос, к которому прикладывает хэш от ЭП; отправляет этот запрос службе TSA. Служба TSA добавляет к этому хэшу текущее время и подписывает результат своей ЭП. Таким образом, создается доверенная временная метка.

Для создания online-службы доверенных временных меток следует использовать продукт МагПро TSA. При этом URL службы временных меток задается Web-страницей, на которой находится Web-форма подписи

Клиентская часть TSA встроена в КриптоТуннель. При получении временной метки на ЭП все действия производятся автоматически, без привлечения пользователя.

Арбитр

Арбитр - это специальная программа, которая используется при разборе конфиликтов по ЭП.

Арбитр позволяет визуализировать идентификационные данные сертификата, который находится в подписи PKCS#7; визуализировать цепочку доверия и время создания ЭП (TimeStamp). Для разбора конфликта Арбитр проверяет подпись под указанным документом и выявляет, была ли она произведена владельцем сертификата.

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

Защита персональных данных на WEB-сайте

Данные, которыми обмениваются между браузер клиента и сайт, могут содержать персональные данные и конфиденциальную информацию. Если в защите конфиденциальной информации заинтересованы все пользователи сайта, то защита персональных данных является требованием закона ФЗ 152-ФЗ "О персональных данных".

При использовании сайта данные подвергаются угрозе при передаче их через Internet и при их дальнейшем хранении на сервере сайта.

Защита при передаче между клиентом и сервером

Internet является небезопасным каналом передачи информации. Основной угрозой при передаче данных через Internet является атака "man in the middle", то есть злоумышленник подключается к линии между клиентом и сервером и подменяет передающуюся информацию. Единственным способом защиты данных в Internet является шифрование этих данных. Так как шифрование представляет собой криптографический способ защиты информации, то на него распространяются требования ФСБ к средствам криптографической защиты информации - наличие сертификата ФСБ.

Для криптографической защиты соединений между браузером пользователя и Web-сайтом (Web-соединений) используется протокол SSL/TLS. «КриптоТуннель» обеспечивает защиту данных по этому протоколу полностью соответствующую требованиям ФСБ. Таким образом, «КриптоТуннель» представляет собой сертифицированное решение, полностью отвечающее требованиям к техническим средствам защиты персональных данных.

Защита при хранении

При хранении данных в электронном архиве сайта эти данные должны храниться в зашифрованном виде. Создание защищенного электронного архива - это тема отдельной статьи.

1. Процесс подписи документа. Алгоритм верификации электронной подписи

Процесс подписи документа выглядит следующим образом. На первом шаге строится специальная функция (хэш-функция), напоминающая контрольную сумму, она идентифицирует содержимое документа (создается "дайджест" документа). На втором шаге автор документа шифрует содержимое хэш-функции своим персональным закрытым ключом. Зашифрованная хэш-функция помещается в то же сообщение, что и сам документ. Цифровая подпись является производной “дайджеста” и личного закрытого ключа, чем гарантируется её абсолютная уникальность (см. рис.14.1).

Рис. 14.1 – Алгоритм формирования ЭЦП

Используемая в алгоритме хэш функция должна удовлетворять ряду требований а именно:

Сообщение любой длины должно преобразовываться в бинарную последовательность

фиксированной длины;

Полученная хешированная версия сообщения должна зависеть от каждого бита исходного сообщения и от порядка их следования;

По хешированной версии сообщения нельзя никакими способами восстановить само

сообщение.

Алгоритм верификации электронной подписи

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

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

Рис. 14.2 – Верификация ЭЦП

Электронную цифровую подпись, как и любые другие данные, можно передавать вместе с

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

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

2. Проверка подлинности

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

Аутентификация – проверка принадлежности клиенту или серверу предъявленного им идентификатора – можно реализовать на основе ИОК и соответствующих сертификатов открытых ключей.

Аутентификация возможна несколькими способами.

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

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

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

Описанная схема называется протоколом доказательства владения (proof-of-possession), поскольку отправитель доказывает, что он владеет требуемым для дешифрации и создания электронной цифровой подписи личным секретным ключом.

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

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

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

Сначала выбирается алгоритм шифрования с секретным ключом (ГОСТ 28147-89, DES и т.п.) затем создается случайный сеансовый ключ (random session key), который будет использоваться для шифрования данных. Далее отправитель шифрует этот ключ сеанса, используя открытый ключ получателя. Затем он отправляет получателю зашифрованный ключ и зашифрованные данные. Своим личным закрытым ключом получатель расшифровывает ключ сеанса и использует его для дешифрации данных.

Подтверждение доверия ЭЦП

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

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

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

Подтверждает связь между именем отправителя и открытым ключом отправителя;

Выдан удостоверяющим центром, которому есть доверие.

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

Однако возникает вопрос проверки принадлежности открытого ключа данному удостоверяющему центру. Необходимо найти сертификат, заверяющий подлинность этого удостоверяющего центра. Таким образом, в процессе проверки сертификата происходит продвижение по цепочке сертификатов (certification path). В конце цепочки сертификатов, ведущей от сертификата открытого ключа отправителя через ряд удостоверяющих центров, находится сертификат, выданный тем УЦ, которому есть полное доверие. Такой сертификат называется доверенным корневым сертификатом (trusted root certificate), поскольку он образует в иерархии связей «открытые ключи – личность» корень (самый верхний узел), который считается надежным.

Если есть явное доверие данному доверенному корневому сертификату, то тогда появляется неявное доверие всем сертификатам, выданным доверенным корневым сертификатом и всеми сертифицированными им УЦ.

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

В общем случае при верификации сертификата необходимо проверить следующие поля сертификата:

· Тип сертификата – сертификат разрешено использовать в данном режиме .

· Срок действия – сертификат действителен в данный момент.

· Целостность – цифровая подпись УЦ, выдавшего сертификат, верна.

· Легитимность – сертификат не был отозван.

· Доверие – сертификат корневого УЦ присутствует в хранилище «доверенные

корневые УЦ».

· Запреты – списки CTL не запрещают использование сертификата для данной задачи.

ОСНОВНЫЕ ПОНЯТИЯ

КСКПЭП –квалифицированный сертификат ключа проверки электронной подписи.
КЭП – квалифицированная электронная подпись.

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

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

ЛКМ – левая кнопка мыши.

ПКМ – правая кнопка мыши.

CRM- AGENT – приложение, разработанное специалистами УЦ для упрощения процедуры генерации ключевой пары, создания запроса и записи сертификата.

Перед началом генерации

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

Откройте ссылку для генерации из письма в одном из рекомендуемых браузеров: Google Chrome , Mozilla Firefox , Yandex.Браузер . Если Вы уже находитесь в одном из вышеперечисленных браузеров, кликните по ссылке ЛКМ или ПКМ > «Открыть ссылку в новой вкладке». Страница генерации (Рис.1) откроется в новом окне.

При открытии ссылки, появится первоначальное предупреждение. Ознакомьтесь с ним, если для хранения КЭП вы используете носитель Jacarta LT . Подробнее о носителях в ниже. Если используете иной носитель, то нажмите кнопку «Закрыть» .

Рис.1 – Страница генерации

Установка приложения

Нажмите на ссылку «Скачать приложение» для начала загрузки. Если ничего не произошло после нажатия, кликните по ссылке ПКМ > «Открыть ссылку в новой вкладке» . После скачивания приложения запустите установку.

Рекомендуется отключить антивирусное ПО перед загрузкой программы !

В процессе установки приложения « crm - agent » появится сообщение с запросом доступа (Рис.2).

Рис.2 – Запрос доступа


Нажмите кнопку «Да».

Предоставление доступа

После окончания установки приложения вернитесь на страницу с генерацией. Появится сообщение о «Предоставлении доступа» (Рис.3).

Рис.3 – Доступ к хранилищу сертификатов


Нажмите «Продолжить» и, в появившемся окне, «Предоставить доступ» (Рис.4).

Рис.4 – Доступ к хранилищу сертификатов 2


Если не появилась кнопка «Продолжить»

Если после установки приложения « crm - agent » , ссылка на скачивание приложения не исчезла, причиной может быть блокировка подключения вашей системой безопасности.

Для устранения ситуации необходимо:

Отключить антивирус, установленный на вашем компьютере;

Открыть новую вкладку в браузере;

Ввести в адресную строку браузера адрес без пробелов - 127.0.0.1:90 – и перейти (нажать Enter на клавиатуре);

При появлении сообщения браузера «Ваше подключение не защищено» , добавьте страницу в исключения браузера. Например, Chrome : «Дополнительные» - «Все равно перейти на сайт» . Для остальных браузеров воспользуйтесь соответствующей инструкцией разработчика.

После появления сообщения об ошибке, вернитесь на страницу с генерацией и повторите Пункт 2 данной инструкции.

Установка КриптоПРО CSP

В случае, если у вас отсутствуют предустановленные криптопровайдеры, после этапа предоставления доступа появятся ссылки для скачивания КриптоПРО (Рис.5).


Это важно: приложение « crm - agent » обнаруживает любые криптопровайдеры на компьютере, и, если у Вас установлена отличная от КриптоПРО CSP программа (например, VipNET CSP ), свяжитесь со специалистами технической поддержки УЦ для консультации.

Нажмите на ссылку «КриптоПРО 4.0» на странице генерации или на аналогичную ссылку ниже для загрузки файла установки КриптоПРО на компьютер.

КриптоПро CSP 4.0 – версия для ОС Win 7 / 8 / 10

После окончания загрузки откройте zip -архив с помощью соответствующей программы-архиватора (например, Win - RAR ). Внутри будет сам файл установки КриптоПРО. Запустите его и установите с параметрами по умолчанию. В процессе установки у Вас может появиться следующее окно:

Рис.5 – Установка КриптоПРО

Пропустите окно, нажав «Далее» . Установка КриптоПРО завершена.

Установка драйвера для токена

Подписи можно хранить в реестре компьютера, на обычных флеш-накопителях и на специальных usb -токенах. Список токенов, пин-коды и ссылки на ПО представлены в таблице ниже (Таблица 1).

Таблица 1 – Драйверы для защищенных носителей

Тип USB-носителя

Внешний вид USB-носителя

Ссылка на загрузку драйверов

PIN-код

ruToken