Армия показала новые знаки различия
Отныне в ВСУ не будет погон с галунными нашивками, пятиконечными звездами и просветами, введенными в российской...
ОСНОВНЫЕ ПОНЯТИЯ
КСКПЭП
–квалифицированный сертификат ключа проверки электронной подписи.
КЭП
– квалифицированная электронная подпись.
Криптопровайдер – средство защиты криптографической защиты информации.Программа с помощью которой генерируется закрытая часть электронной подписи и которая позволяет производить работу с электронной подписью. Данная галочка проставляется автоматически.
Экспортируемый ключ – возможность копирования электронной подписи на другой носитель. При отсутствии галочки копирование электронной подписи будет невозможно.
ЛКМ – левая кнопка мыши.
ПКМ – правая кнопка мыши.
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 данной инструкции.
В случае, если у вас отсутствуют предустановленные криптопровайдеры, после этапа предоставления доступа появятся ссылки для скачивания КриптоПРО (Рис.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 |
Электронная подпись (далее - ЭП), согласно Федеральному закону Российской Федерации № 63-ФЗ от 25 марта 2011 года «Об электронной подписи», определяется как информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию. Указанный нормативный акт пришел на смену утратившему с 1 июля 2013 г. юридическую силу Федеральному закону Российской Федерации № 1-ФЗ от 10 января 2002 года «Об электронной цифровой подписи».
Закон от 25 марта 2011 года выделяет два вида ЭП: простую и усиленную. Последняя может быть квалифицированной либо неквалифицированной. Если простая ЭП подтверждает только то, что данное электронное сообщение отправлено конкретным лицом, то усиленная неквалифицированная ЭП позволяет не только однозначно идентифицировать отправителя, но и подтвердить, что с момента подписания документа его никто не изменял. В дальнейшем речь пойдет об усиленной неквалифицированной ЭП. Сообщение с неквалифицированной ЭП может быть приравнено к бумажному документу, подписанному собственноручно, если стороны заранее об этом договорились, а также в специально предусмотренных законом случаях.
С одной стороны, ЭП используется для подтверждения авторства документа – в этом ее значение для отправителя документа. С другой стороны, электронная подпись в случае признания ее юридической значимости обеспечивает неотказуемость автора от подписанного документа, что в свою очередь важно и для получателя документа. В случае спорной ситуации всегда может быть проведен разбор конфликтов, который однозначно определит автора подписанного документа и заставит его нести ответственность за подписанный документ.
Основной проблемой при разборе конфликтов спортных ситуаций по документам, подписанным ЭП, является доказательство того факта, что «информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации)» является юридически-значимой ЭП конкретного человека под конкретным документом.
Использование криптографических методов позволяет решить данную проблему. Если человеку выдать уникальный электронный ключ и затем произвести специальные преобразования с использованием данного электронного ключа и электронного документа, то результат этих преобразований (а это и есть ЭП) будет уникален для данной пары (ключ-документ). Таким образом, задача первого этапа разбора конфликтов - выявить, была ли данная подпись выработана с помощью данного электронного ключа или нет – решается методами криптографии.
Второй этап разбора конфликтов – это доказать, что данный электронный ключ является собственностью конкретного человека. Это доказательство придает ЭП юридическую значимость. Для решения данной организационной задачи – учета выданных ключей – используется PKI (инфраструктура открытого ключа).
В законе "Об электронной подписи" различают ключ ЭП и ключ проверки ЭП. Ключ электронной подписи - это уникальная последовательность символов, предназначенная для создания электронной подписи.ключ проверки электронной подписи - это уникальная последовательность символов, однозначно связанная с ключом электронной подписи и предназначенная для проверки подлинности электронной подписи. Ключ проверки ЭПвыводится из ключа ЭП, но обратная операция невозможна. Таким образом, между ключом ЭП и ключом проверки ЭП имеется однозначное соответствие. Ключ ЭП должен создаваться самим клиентом и храниться в секрете. Именно этот ключ служит для подписывания документов электронной подписью. Ключ проверки ЭП служит для проверки ЭП и раздается всем желающим проверить подпись.
Основным элементом PKI является Удостоверяющий центр. В Удостоверющем центре ведется реестр соответствия ключей и лиц, которые являются владельцами этих ключей. Для регистрации ключа клиент относит в УЦ открытую часть своего ключа вместе со своими идентификационными данными и получает сертификат соответствия, удостоверящий его владение именно этим ключом. Сертификат соответствия содержит ключ проверки ЭП и идентификационные данные клиента, и подписан ЭП Удостоверяющего центра. Таким образом, УЦ удостоверяет, что данный клиент был проверен и является тем, за кого себя выдает. При получении сертификата клиент в свою очередь подписывает специальные документы о достоверности выданного сертификата своей ручной подписью. Эти документы являются основным связуюшим звеном между конкретным человеком и «набор электронных символов», его ЭП.
Таким образом, для проверки подписи и идентификации подписанта достаточно сертификата подписанта. То есть подписант подписывает документ своим ключом ЭП, а затем посылает получателю этот подписанный документ и свой сертификат, содержащий ключ проверки ЭП. Таким образом получатель сможет проверить, что подпись действительно была сделана ключом ЭП подписанта и получит идентификационные данные подписанта из сертификата. Клиент должен защищать свой ключ ЭП от компрометации. Именно с этой целью создаются различные аппаратные ключевые хранилища с повышенным уровнем защиты, например, USB-устройство ruToken.
Стандарты на ЭП являются двухуровневыми. На первом уровне располагается непосредственно ЭП от документа. Второй уровень заключает в себе ЭП и все документы, необходимые для придания ЭП юридической значимости: сертификат подписанта или цепочку сертификатов, время создания подписи и т.п.
Российским стандартом ЭП первого уровня является ГОСТ 34-10.2012. Российским стандартом ЭП второго уровня является PKCS#7 с возможностью добавления временных меток TSA.
Предположим в вашей организации принято решение перейти на систему электронного документооборота, построенную на web-технологиях. При этом основными местами, в которых требуется ЭП являются:
выделить сервер, на котором будет развернут Удостоверяющий центр. Опционально могут быть развернуты службы временных меток и online-проверки статуса сертификата. УЦ и указанные службы в целях экономии могут быть использовать один сервер, который должен быть доступен online. Целесообразность этих служб мы обсудим ниже.
установить на сервер продукт МагПро КриптоПакет
создать ключ УЦ и заявку на корневой сертификат УЦ с помощью утилиты mkkey из состава МагПро КриптоПакет . Ключ может быть создан на защищенном устройстве, например, на ruToken. После создания ключа УЦ требуется обеспечить его безопасность организационными методами. Наиболее безопасным вариантом является хранение ключа на устройстве ruToken и поключение его к серверу только при выдаче сертификатов. Сертификат УЦ представляет из себя файл. Этот файл впоследствии будет выдаваться всем клиентам УЦ при получении ими сертификата.
создать корневой сертификат УЦ с помощью утилиты openssl из состава МагПро КриптоПакет .
создать в файловой системе структуру директорий, в которых будут храниться в виде файлов выданные сертификаты пользователей, выданные сертификаты серверов, заявки на сертификаты. Следует организационными методами (например, с помощью ACL) обеспечить правильные права доступа к эти директориям. Сертификаты будут выдаваться в виде файлов в формате PEM. Следует иметь в виду, что имена файлов сертификатов лучше делать понятными, чтобы в дальнейшем облегчить задачу поиска сертификатов.
Для получения сертификата пользователем УЦ могут использоваться две схемы: централизованная и удаленная. При централизованной схеме пользователь приходит в УЦ и ему выдают файл, в котором находятся ключ и сертификат. Затем он этот файл складывает на флешку. Данная схема является простой и удобной, но небезопасной, так как позволяет узнать ключ пользователя сотрудникам УЦ. Но в ряде случаев использование данной схемы является опраданным.
Наиболее безопасной схемой получения сертификата является распределенная. Пользователь создает ключ, создает заявку PKCS#10 на сертификат, которая содержит его ключ проверки ЭП и идентификационные данные. Эту заявку пользователь подписывает своим ключом ЭП и относит в УЦ. УЦ проверяет подпись под заявкой, сверяет идентификационные данные пользователя, например, с паспортными и выдает сертификат. Затем производится распечатка сертификата и пользователь подписывает ручной подписью документ о соответствии выданного сертификата.
В рамках обсуждаемого решения генерация ключей и создание заявки производится с помощью специальной программы из состава МагПро КриптоПакет . Данная программа входит в пользовательский комплект КриптоТуннель .
Данная программа обладает гибкой системой конфигурирования, с помощью которой можно создавать заявки на совершенно различные виды сертификатов, расширять стандартный набор идентификационной информации, добавлять в сертификаты роли и права пользователей, например, для разграничения доступа на 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-форму. Не требуется писать каких-либо дополнительных скриптов, вызывать Active X и т.п.
Множественная ЭП требуется в том случае, если документ должен быть подписан несколькими лицами. В этом случае документ обычно выкладывается на сайте таким образом, чтобы он был доступен только пользователям, ЭП которых требуется. Подобное разделение доступа обепечивается с помощью аутентификации пользователей по цифровому сертификату.
При использовании КриптоТуннеля пользователю не придется скачивать документ, а потом подписывать и снова загружать документ на сервер – все эти операции КриптоТуннель сделает автоматически при нажатии на кнопку на web-странице.
Часто случается, что УЦ отзывает сертификат пользователя (например, если ключ пользователя был украден злоумышленником). При этом остальные пользователи должны быть оповещены об отзыве этого сертификата, для того чтобы они перестали ему доверять. Существует несколько способов оповестить пользователей об отзыве.
Наиболее простым способом является раздача списков отзыва (CRL). То есть УЦ создает и периодически обновляет специальный файл, который пользователи так же периодически скачивают.
Другим способом является использование службы online проверки статуса сертификата – службы OCSP. Для проверки статуса любого сертификата КриптоТуннель и КриптоСервер автоматически формируют OCSP-запрос, отправляют по сети этот запрос службе. Служба проверяет сертификат, подписывает результат проверки своей ЭП и возвращает клиенту ответ. Клиент смотрит ответ, проверяет под ним подпись и принимает решение – доверять ли данному сертификату или нет.
Создание службы OCSP возможно с помощью утилиты openssl из состава МагПро КриптоПакет . Следует иметь в виду, что выбор между CRL и OCSP всегда остается на усмотрение создателей сайта. CRL – немного дешевле, OCSP – немного безопаснее.
Следует отменить, что КриптоТуннель и КриптоСервер поддерживаеют как OCSP, так и CRL.
Основным назначением службы временных меток является подтвержение того факта, что документ был подписан ЭП не позже времени, указанного во временной метке.
Для создания временной метки КриптоТуннель создает TSA-запрос, к которому прикладывает хэш от ЭП; отправляет этот запрос службе TSA. Служба TSA добавляет к этому хэшу текущее время и подписывает результат своей ЭП. Таким образом, создается доверенная временная метка.
Для создания online-службы доверенных временных меток следует использовать продукт МагПро TSA. При этом URL службы временных меток задается Web-страницей, на которой находится Web-форма подписи
Клиентская часть TSA встроена в КриптоТуннель. При получении временной метки на ЭП все действия производятся автоматически, без привлечения пользователя.
Арбитр - это специальная программа, которая используется при разборе конфиликтов по ЭП.
Арбитр позволяет визуализировать идентификационные данные сертификата, который находится в подписи PKCS#7; визуализировать цепочку доверия и время создания ЭП (TimeStamp). Для разбора конфликта Арбитр проверяет подпись под указанным документом и выявляет, была ли она произведена владельцем сертификата.
Следует заметить, что для самой возможности разбора конфликтов документы и их подписи должны храниться в электронном архиве в течение длительного времени.
Данные, которыми обмениваются между браузер клиента и сайт, могут содержать персональные данные и конфиденциальную информацию. Если в защите конфиденциальной информации заинтересованы все пользователи сайта, то защита персональных данных является требованием закона ФЗ 152-ФЗ "О персональных данных".
При использовании сайта данные подвергаются угрозе при передаче их через Internet и при их дальнейшем хранении на сервере сайта.
Internet является небезопасным каналом передачи информации. Основной угрозой при передаче данных через Internet является атака "man in the middle", то есть злоумышленник подключается к линии между клиентом и сервером и подменяет передающуюся информацию. Единственным способом защиты данных в Internet является шифрование этих данных. Так как шифрование представляет собой криптографический способ защиты информации, то на него распространяются требования ФСБ к средствам криптографической защиты информации - наличие сертификата ФСБ.
Для криптографической защиты соединений между браузером пользователя и Web-сайтом (Web-соединений) используется протокол SSL/TLS. «КриптоТуннель» обеспечивает защиту данных по этому протоколу полностью соответствующую требованиям ФСБ. Таким образом, «КриптоТуннель» представляет собой сертифицированное решение, полностью отвечающее требованиям к техническим средствам защиты персональных данных.
При хранении данных в электронном архиве сайта эти данные должны храниться в зашифрованном виде. Создание защищенного электронного архива - это тема отдельной статьи.
Процесс подписи документа выглядит следующим образом. На первом шаге строится специальная функция (хэш-функция), напоминающая контрольную сумму, она идентифицирует содержимое документа (создается "дайджест" документа). На втором шаге автор документа шифрует содержимое хэш-функции своим персональным закрытым ключом. Зашифрованная хэш-функция помещается в то же сообщение, что и сам документ. Цифровая подпись является производной “дайджеста” и личного закрытого ключа, чем гарантируется её абсолютная уникальность (см. рис.14.1).
Рис. 14.1 – Алгоритм формирования ЭЦП
Используемая в алгоритме хэш функция должна удовлетворять ряду требований а именно:
Сообщение любой длины должно преобразовываться в бинарную последовательность
фиксированной длины;
Полученная хешированная версия сообщения должна зависеть от каждого бита исходного сообщения и от порядка их следования;
По хешированной версии сообщения нельзя никакими способами восстановить само
сообщение.
Алгоритм верификации электронной подписи
Алгоритм верификации электронной подписи состоит в следующем. На первом этапе получатель сообщения строит собственный вариант хэш-функции подписанного документа.
На втором этапе происходит расшифровка хэш-функции, содержащейся в сообщении с помощью открытого ключа отправителя. На третьем этапе производится сравнение двух хэш- функций. Их совпадение гарантирует одновременно подлинность содержимого документа и его авторства (см. рис.14.2).
Рис. 14.2 – Верификация ЭЦП
Электронную цифровую подпись, как и любые другие данные, можно передавать вместе с
подписанными, то есть защищенными ею данными. Кроме того, цифровая подпись позволяет убедиться в том, что данные при передаче адресату не были изменены (случайно или преднамеренно).
Шифрование и электронная подпись могут с успехом применяться вместе. Сначала можно подписать документ личным закрытым ключом, а потом зашифровать открытым ключом адресата. Подпись удостоверяет личность, шифрование защищает письмо от чужих глаз.
Криптография с открытыми ключами обеспечивает надежные службы распределенной идентификации, аутентификации и авторизации. Такого рода задачи возникают при любом факте доступа субъекта (пользователя системы) к информации. В частности при подключении клиента к серверу в условиях открытого канала (Интернет). Идентификационные данные клиента и сервера присутствуют в соответствующих сертификатах открытых ключей, выданных единым удостоверяющим центром, либо удостоверяющими центрами из одной иерархии. Таким образом, при подключении клиента к серверу можно произвести взаимную идентификацию.
Аутентификация – проверка принадлежности клиенту или серверу предъявленного им идентификатора – можно реализовать на основе ИОК и соответствующих сертификатов открытых ключей.
Аутентификация возможна несколькими способами.
1. Сервер посылает клиенту запрос на подтверждение подлинности зашифрованный открытым ключом клиента, полученным из сертификата открытого ключа клиента. Клиент расшифровывает запрос личным закрытым ключом и возвращает серверу, подтвердив таким образом, что он является владельцем соответствующего закрытого ключа, и, следовательно, идентификационные данные в сертификате принадлежат именно ему.
2. Сервер посылает запрос на подтверждение подлинности открытым текстом. Клиент отвечает на запрос, подписав его собственной электронной цифровой подписью.
Сервер проверяет ЭЦП клиента с помощью открытого ключа полученного из сертификата открытого ключа клиента и удостоверяется в том, что клиент действительно имеет соответствующий личный закрытый ключ.
Описанная схема называется протоколом доказательства владения (proof-of-possession), поскольку отправитель доказывает, что он владеет требуемым для дешифрации и создания электронной цифровой подписи личным секретным ключом.
3. Согласование общего секретного ключа сессии Криптография с открытыми ключами также позволяет двум сторонам согласовать общийсекретный ключ сессии при обмене информацией через незащищенные каналы связи.
Схема выработки общего ключа сессии выглядит следующим образом. Сначала клиент и сервер генерируют по одному случайному числу, которые используются как половины их общего секретного ключа сессии. Затем клиент отправляет серверу свою половину секретного ключа, зашифрованную открытым ключом, полученным из сертификата открытого ключа сервера. Сервер отправляет клиенту свою половину, зашифрованную открытым ключом, полученным из сертификата открытого ключа клиента. Каждая из сторон расшифровывает полученное сообщение с недостающей половиной секретного ключа, и создает из этих двух половин общий секретный ключ. Выполнив такой протокол, стороны могут пользоваться общим секретным ключом для шифрования последующих сообщений.
4. Шифрование без предварительного обмена симметричным секретным ключом Технология шифрования с открытым ключом позволяет шифровать большие объемыданных в том случае, если у обменивающихся информацией сторон нет общего ключа.Существующие алгоритмы шифрования с открытым ключом требуют значительно большевычислительных ресурсов, чем симметричные алгоритмы, поэтому они неудобны дляшифрования больших объемов данных. Однако можно реализовать комбинированный подходс использованием, как симметричного шифрования, так и шифрования с открытым ключом.
Сначала выбирается алгоритм шифрования с секретным ключом (ГОСТ 28147-89, DES и т.п.) затем создается случайный сеансовый ключ (random session key), который будет использоваться для шифрования данных. Далее отправитель шифрует этот ключ сеанса, используя открытый ключ получателя. Затем он отправляет получателю зашифрованный ключ и зашифрованные данные. Своим личным закрытым ключом получатель расшифровывает ключ сеанса и использует его для дешифрации данных.
Подтверждение доверия ЭЦП
При получении подписанного ЭЦП сообщения, возникает вопрос доверия этой подписи (действительно ли данная ЭЦП принадлежит отправителю сообщения). Целостность подписи можно проверить с помощью известного открытого ключа отправителя и криптографических алгоритмов. Однако при этом необходимо удостовериться, что используемый для проверки открытый ключ действительно принадлежит субъекту, именем которого подписано сообщение.
Если возможно найти сертификат открытого ключа отправителя, выданный удостоверяющим центром, которому есть доверие, тогда можно получить убедительное
подтверждение того, что открытый ключ отправителя действительно принадлежит отправителю. Таким образом, можно удостовериться, что открытый ключ принадлежит именно данному отправителю, если найден сертификат, который: · имеет действительную с криптографической точки зрения подпись его издателя;
Подтверждает связь между именем отправителя и открытым ключом отправителя;
Выдан удостоверяющим центром, которому есть доверие.
Если был найден такой сертификат открытого ключа отправителя, то подлинность этого сертификата можно проверить с помощью открытого ключа удостоверяющего центра.
Однако возникает вопрос проверки принадлежности открытого ключа данному удостоверяющему центру. Необходимо найти сертификат, заверяющий подлинность этого удостоверяющего центра. Таким образом, в процессе проверки сертификата происходит продвижение по цепочке сертификатов (certification path). В конце цепочки сертификатов, ведущей от сертификата открытого ключа отправителя через ряд удостоверяющих центров, находится сертификат, выданный тем УЦ, которому есть полное доверие. Такой сертификат называется доверенным корневым сертификатом (trusted root certificate), поскольку он образует в иерархии связей «открытые ключи – личность» корень (самый верхний узел), который считается надежным.
Если есть явное доверие данному доверенному корневому сертификату, то тогда появляется неявное доверие всем сертификатам, выданным доверенным корневым сертификатом и всеми сертифицированными им УЦ.
Набор доверенных корневых сертификатов, которым есть явное доверие – это единственная информация, которую необходимо получить надежным способом. На этом наборе сертификатов базируется система доверия и обоснование надежности инфраструктуры открытых ключей.
В общем случае при верификации сертификата необходимо проверить следующие поля сертификата:
· Тип сертификата – сертификат разрешено использовать в данном режиме .
· Срок действия – сертификат действителен в данный момент.
· Целостность – цифровая подпись УЦ, выдавшего сертификат, верна.
· Легитимность – сертификат не был отозван.
· Доверие – сертификат корневого УЦ присутствует в хранилище «доверенные
корневые УЦ».
· Запреты – списки CTL не запрещают использование сертификата для данной задачи.
Сегодня мы поговорим о том:
Хочу обратить внимание на два термина, которые будут использоваться в мастер-классе.
Почему вопросы криптографии и электронной подписи актуальны на текущий момент?
Какие понятия мы рассмотрим?
Электронный документ - это любая информация, представленная в электронном виде:
Любой документ можно перевести в «цифру», но не каждый электронный документ может быть распознан без участия человека.
Машинная обработка более перспективна, поэтому множество документов можно разделить на формализованные и неформализованные электронные документы .
Перспектива за формализованными электронными документами. Ведомства постепенно переходят на новые рельсы. Многие из них выпускают свои нормативные положения, описывающие, в каком формате можно обмениваться информацией.
Раньше была проблема, что ФНС обязывала переходить на новый формат электронных документов примерно так же, как на новый формат электронной отчетности - с 1 марта будет новый формат, и дальше «хоть трава не расти». Сейчас, по истечению пары лет, они публикуют формат, ждут обратную связь и затем предупреждают, что на него нужно плавно перейти в течение этого года. При этом параллельно принимаются и старые, и новые форматы. Налоговая служба всегда должна принимать документы в любом формате, потому что документы могут быть пятилетней давности, и в электронном виде они все равно должны приниматься.
Закон № 63-ФЗ вводит понятие электронной подписи. Раньше было понятие «электронная цифровая подпись» (ЭЦП), теперь правильнее использовать термин «электронная подпись». По этому закону есть три вида электронной подписи .
Усиленную квалифицированную электронную подпись иногда называют просто квалифицированной электронной подписью (КЭП). Это электронная подпись на базе сертификата, который выдается аккредитованным удостоверяющим центром. Минкомсвязь ведет список удостоверяющих центров, которые выдают сертификаты электронной подписи.
Сертификат электронной подписи (он может еще называться сертификат ключа проверки электронной подписи) - это бумажный или электронный документ, однозначно определяющий, кому принадлежит эта подпись.
Квалифицированная электронная подпись применяется наиболее широко. Ее основное назначение в том, что она подтверждает авторство, гарантирует неотказуемость и обеспечивает целостность подписанных данных. Это означает, что если Вы подписали электронный счет-фактуру квалифицированной электронной подписью, то:
Если говорить про применение электронных подписей , то стоит поделить их на локальные и облачные.
ФСБ выпустила разъяснительное письмо, в котором объяснила, что облачная электронная подпись не является квалифицированной . Поэтому, если в законе написано, что документ должен подписываться именно квалифицированной электронной подписью, а у Вас документ подписывается в «облаке», то имейте в виду, что с этим могут быть проблемы - к этому нужно подходить очень внимательно.
Что можно еще рассказать интересного про законодательство, которое будет нас касаться?
Какие бывают особенности применения электронного документооборота в компаниях? Обратите внимание, что когда Вы запускаете проекты, связанные с электронной подписью и криптографией, консалтинговые услуги очень важны.
Если компания запускает электронный документооборот , то:
Все это нужно прописать и использовать.
Я бы оценил готовность нашей нормативной базы - уже есть какое-то «здание», но его нужно еще достраивать.
В общем, есть куда двигаться.
Механизм криптографии в платформе появился с версии 8.2 - это достаточно молодой механизм. Сама платформа не содержит криптоалгоритмы, она содержит только вызовы и объекты, с помощью которых можно обращаться к криптосредствам, находящимся на компьютере:
Отсюда становится понятно, что криптографию можно применять, только если на компьютере установлено криптосредство . И, с другой стороны, что саму платформу «1С:Предприятие» не требуется сертифицировать с точки зрения криптографии.
Основные криптографические операции в платформе «1С:Предприятие 8»:
Именно так сделано в механизме БСП - об этом речь пойдет чуть позже. Платформа этого не делает.
Защищенное соединение TLS для организации шифрованного канала обмена данными. Поддерживаются две версии TLS - 1.0/1.2. Версия TLS задается источником, с которым Вы устанавливаете соединение - если в источнике используется протокол 1.2, то и платформа поднимет шифрованное соединение по 1.2. Если используется БСП, то при обращении к ресурсу, в адресе которого прописан «https», шифрование включается автоматически. Если в адресе прописан «http», то трафик не шифруется. Еще из интересного могу сказать, что раньше шифрованное соединение устанавливалась только на RSA-алгоритмах, а сейчас и на ГОСТ-алгоритмах тоже. Браузеры пока что ГОСТ-алгоритмы не поддерживают, а платформа уже умеет. Но не все так хорошо, к сожалению.
Я уже упоминал, что платформа умеет работать только с теми криптосредствами, которые установлены на самом компьютере. Соответственно, есть ограничение - если Вы хотите использовать криптографию, у Вас должно быть какое-то криптосредство. При этом криптосредство нельзя использовать в портативном режиме, оно должно быть обязательно установлено на ОС . Казалось бы, воткнули токен с криптосредством в компьютер, платформа с ним поработала - так не получится.
Электронная подпись генерируется только в формате PKCS#7 (отдельный, внешний файл), по-другому платформа не умеет.
Некоторые ведомства требуют формат подписи XMLDSig - в упрощенном варианте ситуация, когда в XML-файле Вы можете взять некий набор тегов, подписать их и положить подпись в следующий тег, чтобы в одном документе было несколько подписей. Платформа так делать не умеет.
Еще я бы отметил, что с помощью платформы сложно диагностировать возникающие проблемы. Например, на компьютере есть криптосредство, есть сертификат, где-то есть закрытая часть ключа, и если платформа начинает все это вызывать и в какой-то момент что-то не стыкуется, просто выдается ошибка - что произошел сбой, и операция не состоялась. Что там случилось, где проблема - непонятно. Поэтому есть куда двигаться в эту сторону и платформе, и криптосредствам.
Чтобы снять ограничения платформы, можно попробовать сделать внешнюю компоненту.
Теперь о том, как проще работать.
«1С:Библиотека стандартных подсистем» (БСП) - это готовая типовая конфигурация от фирмы «1С», набор универсальных функциональных подсистем, одна из которых называется «Электронная подпись».
Сразу хочу обратить внимание, что сама БСП - это некий изолированный от платформы уровень, у которого есть программный и пользовательский интерфейсы. Подсистема «Электронная подпись» реализует программный и пользовательский интерфейс для работы со средствами криптографии (шифрование, электронная подпись).
При рассмотрении подсистемы «Электронная подпись» важно понимать, что в ней есть:
Количество объектов в подсистеме не очень большое, справочников всего два:
Но количество строчек кода в общих модулях очень большое - 11,5 тысяч строчек кода. И сама работа с подсистемой не очень простая.
Как встраивать подсистему «Электронная подпись»?
Предположим, что у Вас есть какая-то конфигурация, Вы решили, что Вам нужно встроить в нее эту подсистему:
А если у Вас конфигурация с нуля, то берете подсистему и на ее базе пишете - обновлять будете сами.
Как тестировать электронную подпись?
Таким образом, «не вставая с дивана», Вы получите тестовую среду для работы с сертификатами и криптографией. Это можно использовать.
Это пример демобазы БСП. В разделе «Администрирование» есть две функциональные опции: «Шифрование» и «Электронная подпись». Если Вы их включили, можно переходить в настройки.
В настройках находятся два справочника: «Программы» и «Сертификаты». В «Программах» система определяет, какие программы установлены, и сразу показывает, что все хорошо или все плохо. Если у Вас используется какое-то специфичное криптосредство, которого нет в БСП, Вы можете нажать кнопку «Добавить» и указать там параметры обращения к нему.
Если Вы работаете через веб-клиент, то подсистема БСП подскажет, что сначала нужно установить расширение для работы с файлами и расширение для работы с криптографией. Это очень удобно, потому что не нужно настраивать самим - система найдет расширение и предложит поставить его.
Сертификаты можно добавить двумя способами.
Таким образом, пользователи, не выходя из программы, получают квалифицированный сертификат электронной подписи.
Дальше происходит магия - проверка сертификата с помощью диагностики корректности настроек. Этот диалог позволяет проверить, насколько корректно настроена криптография на компьютере - система попытается подписать сертификатом, проверить, зашифровать, расшифровать. Также есть возможность вставить сюда какую-то свою дополнительную диагностику.
Если у Вас или у ваших клиентов возникают какие-то проблемы, запускаете «Диагностику», и все будет понятно. Если будут проблемы, как в примере на слайде, можно щелкнуть по иконке ошибки, она покажет Вам возможные причины, и попытается подсказать, что нужно исправить.
Как делать вызовы для подписания и шифрования/расшифрования можно посмотреть на примере справочника «Файлы» в демо-базе БСП или в «1С:Управление торговлей», «1С:ERP» - там есть такая же подсистема.
Как используется криптография в сервисах? Первый сервис, «1С-ЭДО» - это сервис, предназначенный для обмена юридически значимыми электронными документами через дружественных операторов компании «1С».
Второй сервис - это «1С:ДиректБанк». Его назначение - обмен с банками электронными документами напрямую, минуя программу клиент-банк.
Вот такой мини-цикл - по нему становится понятно, насколько у Вас с банком корректно настроен обмен.
Как разрабатывать собственные решения с криптографией?
Вы можете создать конфигурацию с нуля - открыть «Синтаксис-помощник» и использовать возможности платформы для криптографических операций. Но я бы рекомендовал использовать БСП - там уже много чего написано. В этом случае Вам потребуется написать не 11 тысяч строк кода, а поменьше. Но пять тысяч строк кода - точно.
Как тестировать - я уже рассказывал. Можно получить тестовый сертификат и попробовать поработать.
Если Вы разработали конфигурацию с нуля - Вы ее сопровождаете сами. А если Вы использовали при разработке БСП, а она выпустила какую-то новую возможность, то Вы можете обновить подсистему БСП и попробовать эту возможность. Трудности будут в любом случае, потому что «серебряной пули» здесь нет. Я бы подходил к оценке того, стоит или не стоит что-то изобретать, в зависимости от задачи, которую Вы хотите решить. Рассматривая конкретную задачу, уже выбираете: свое решение или стандартное на базе БСП.
Примером собственного решения является разработка партнера «Индустрия ИТ ». Они разработали небольшой модуль для внутреннего электронного документооборота на базе «1С:УПП». Там на основе печатной формы формируется электронный документ, который привязывается к документу информационной базы, и есть возможность подписать его электронной подписью. Простой документооборот внутри компании, но сопровождать его все равно надо.
Какие бывают основные проблемы ?
Первый вариант - разнести эти криптосредства по разным компьютерам.
Если это невозможно, тогда для одного из сервисов нужно выпустить сертификат на другом криптосредстве - когда Вы заказываете сертификат в удостоверяющем центре, Вы можете указать, для какого криптосредства Вы его будете использовать .
Я бы порекомендовал использовать тот удостоверяющий центр, с которым Вы будете в дальнейшем работать в части обмена электронными документами. Пример - есть оператор электронного документооборота «Такском», у него есть удостоверяющий центр. Если Вы будете запускать электронный документооборот через «Такском», то имеет смысл и за сертификатом обращаться к ним же.
Ты говорил, что ФСБ давала какое-то разъяснение по поводу облачных сертификатов. Что если сертификат хранить не локально, а в облаке, он не может считаться усиленным. В случае стандартного обмена счетами-фактурами и УПД, мы можем использовать облачный сертификат или там требуется усиленный все-таки?
В законе написано, что при обмене счетами-фактурами требуется усиленная квалифицированная электронная подпись, поэтому "облако" тут не подойдет. А вот для других видов электронных документов - пожалуйста.
Грубо говоря, для любого стандартного ЭДО, которое мы используем в 1С, нам нужен усиленный сертификат?
Нет, не для любого. В законе написано только про электронные счета-фактуры. Их нужно подписывать именно квалифицированной электронной подписью. По поводу остальных документов ничего не написано. Это значит, что для накладных, для заказов Вы можете использовать усиленную неквалифицированную электронную подпись - в том числе и в облаке.
А про УПД там нет ничего? По сути, УПД сейчас это то же самое, что и счет-фактура.
Там есть размытое определение - счет-фактура с расширенными показателями, но это не то же самое, что УПД. Поэтому я думаю, что УПД попадает в разряд неквалифицированной электронной подписи.
А какую функцию во всей этой цепочке выполняет именно оператор - «1С-ЭДО» или «Такском»? Обычно через операторов мы отправляем документы в госорганы и обмениваемся счетами-фактурами, а при обмене другими документами с контрагентами зачем нам нужен оператор?
Операторы на рынке тоже не первый день работают, счета-фактуры ходят через них. Они так и говорят - отправляешь один счет-фактуру, а два другие документа - бесплатно. Вы же все равно счетами-фактурами будете обмениваться через них, поэтому проще и документы сами тоже через них посылать. Другое дело, если Вы сидите на упрощенке, и у Вас нет счетов-фактур, тогда можно попросить оператора поискать для Вас недорогой тарифный план. А так в той же самой «Библиотеке электронных документов» есть возможность обмениваться документами с электронной подписью по электронной почте, через FTP и т.д. Но когда у тебя 100 контрагентов, организовывать для каждого из них свой канал связи будет сложно в плане сопровождения.
А если мы хотим протестить самоподписанный сертификат, через оператора мы можем тестировать какой-то обмен с использованием самоподписанного сертификата?
Нет, через оператора - нет. Если сильно хочется потестировать, напишите в фирму «1С», что Вы хотите подключиться к сервису ЭДО, чтобы протестировать.
Они говорят, что мы не удостоверяющий центр.
Напишите мне, я помогу.
А если мы обмениваемся без оператора ЭДО, мне приносят подписанный электронный документ, и я его хочу загрузить в 1С, чтобы хранить его там. В БСП достаточно средств для проверки, что это КЭП и у него правильные реквизиты, чтобы все это было в автоматическом режиме без модальных окон и т.д.?
Я такие кейсы на своей практике не встречал, но в БСП точно есть возможность загрузить файл и проверить его электронную подпись. Скорее всего, Вам надо будет просто под этот сценарий нарисовать какой-то мастер: проверь папку, забери документ, забери подпись, проверь это все, сложи, куда надо и скажи, что все ок. По поводу синхронности вызова - в БСП все это реализовано, все в браузерах работает в асинхронном режиме.
А если в 1С по терминалу работать? Можно ли поставить «КриптоПро» и в терминале пробросить для него ключи? Какие есть особенности, проблемы? И, соответственно, если у нас более 20 юрлиц и на каждое из них по два ключа, как идет разграничение прав к этим ключам? На уровне 1С или как?
В самом БСП, когда грузишь открытую часть ключа, есть возможность указать, какому пользователю она будет доступна. Там можно, войдя под своим именем, видеть только свои сертификаты. Но при этом они все будут находиться на самом компьютере. Поэтому, сами понимаете, устанавливать закрытую часть в реестр точно не нужно, потому что закрытая часть ключа без проблем переносится с машины на машину. Лучше используйте токены. Есть возможность пробросить токен с закрытой частью ключа до терминального сервера. Ребята-производители ключей сами помогают это настроить так, чтобы в терминале этот ключ был виден. Попробуйте, поэкспериментируйте, найдите другие ключи, найдите людей, которые помогут настроить. Но здесь нужно понимать, что этот туннель от терминального сервера до вашего ключа не безопасен. Ты генеришь электронный документ на терминальном сервере и говоришь - подпиши. Что произойдет? Идет передача данных по незащищенному каналу сначала на локальный компьютер, где установлен ключ, формируется электронная подпись, потом данные передаются обратно на терминальный сервер. Но этот канал не защищен. Его можно защитить только с помощью установки специализированного программного обеспечения, которое делает туннель между терминальным сервером и локальной машиной безопасным. Если хочешь работать безопасно, значит, нужно поставить токен, пробросить его до терминалки и поставить ПО для шифрования канала между терминальным сервером и клиентской машиной.
Скажите, есть ли какая-нибудь разница по скорости работы между подписанием электронного счета-фактуры и отсканированного договора в 100 страниц (где чисто графика).
Чем больше документ, тем он медленнее подписывается, потому что там идет асинхронное шифрование - хэш вычисляется по асинхронному алгоритму. Но с точки зрения того, подписываете ли Вы электронную счет-фактуру в несколько строк или 10Мб файл - визуально разницу Вы не заметите. Заметите только на объемах в 1000-3000 документов.
По поводу роуминга 1С-ЭДО. В «Такском» есть роуминг между операторами. А насколько это работоспособно в «1С-ЭДО»? У Вас есть такой опыт? Потому что все контрагенты сидят на разных операторах и выбрать оператора с максимальным покрытием очень сложно. Кого бы Вы посоветовали?
Если выбирать между «1С-ЭДО» и другими, то конечно, «1С-ЭДО». Но у «1С-ЭДО» есть некоторые проблемы с роумингом - он не так много операторов поддерживает. Есть отдельный ресурс по 1С-ЭДО, там приведен список поддерживаемых операторов, думаю, что он должен со временем пополниться.
А где хранить архив подписанных документов? Локально в компании или в облаке? Можно ли обеспечить валидность сохраняемых в облаке документов?
Где мы храним подписанные документы (в облаке или нет) - неважно. Математически хэш уже вычислен, и содержимое документа бесследно уже не подменить. Вы его потом можете хоть 10 раз куда-нибудь передавать, подпись всегда можно будет проверить чисто математически. Если облачный сервис удобный - пожалуйста, храните в нем, это, наверное, даже интереснее.
А оператор такую услугу предоставляет?
Если с ним отдельный договор заключать для хранения бэкапов - они это делают за отдельные деньги.
А разве подписанные документы у них не хранятся?
Физически они хранятся, но по закону они не обязаны их хранить. Они обязаны хранить только квитанцию. Если к ним налоговая придет и спросит - проходил ли такой-то документ, они покажут, да, вот квитанция, смотрите - подпись такая-то. А что там внутри этого документа - это уже не к ним вопрос.
А для УПП операторы не предоставляют какую-нибудь обработку для ЭДО?
Про операторов не могу сказать, их много, и у каждого есть свои разработки, но в самом УПП электронный документооборот есть.
****************
Данная статья написана по итогам , прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY. Больше статей можно прочитать .
В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.