Методические рекомендации по использованию сервисов электронного нотариата службы «Доверенная третья сторона» (стр. 2 )

3. Модуль функциональной поддержки.

4. Утилита командной строки, Абонентский пункт «Digital Secretary Lite» – программное обеспечение пользователей сервиса ДТС.

Транспортировка информации к/от Службы «Электронного нотариата» для протоколов DVCS и OCSP осуществляется по протоколу HTTP инкапсулированному в TLS. Субъектами доступа (ресурсами) выступают веб-сервера.

Интерфейс по осуществлению защищенного доступа и взаимодействия пользователей со Службой «Электронного нотариата» — совокупность средств, при помощи которых пользователь взаимодействует со Службой «Электронного нотариата».

Пользователем является человек, использующий Службу «Электронного нотариата» для решения стоящих перед ним задач. Интерфейс по осуществлению защищенного доступа и взаимодействия пользователей со Службой «Электронного нотариата» включает:

‑ средства криптографической защиты информации;

‑ протоколы HTTP, HTTPS;

‑ протокол TLS, обеспечивающий защищённую передачу данных;

‑ протокол OCSP;

‑ протокол TSP;

‑ протокол DVCS;

‑ веб-серверы;

‑ утилиту командной строки «pki_tool», реализующую диалоги, взаимодействие и транзакции между пользователем и веб-серверами;

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

‑ порядок использования Службы «Электронного нотариата» и документацию на нее.

3.1 Средства криптографической защиты информации

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

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

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

Кроме того, для организации защищенного документооборота необходимы:

‑ средства для хранения цифровых сертификатов и закрытых ключей пользователей. В качестве таких средств могут выступать USB-ключи, реестр операционной системы, внешние носители и др.;

‑ программные или программно-аппаратные средства криптографической защиты, в качестве которых могут использоваться штатные средства прикладного ПО или дополнительные средства защиты.

Для соответствия требованиям и соблюдения условий, определяемых Российским законодательством [5-12] средства криптографической защиты информации должны:

‑ использовать процедуры формирования и проверки электронной цифровой подписи (ЭЦП) в соответствии со стандартами ГОСТ Р 34.11-94, ГОСТ Р 34.10-2001 [13-14];

‑ производить шифрование и имитозащиту, в соответствии с ГОСТ 28147-89 [15];

‑ обеспечивать аутентичность, конфиденциальность и имитозащиту соединений TLS;

‑ иметь действительный сертификат ФСБ России.

3.2 Протоколы HTTP, HTTPS

HTTP (англ. Hypertext Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных, по умолчанию использует порты 80/8080 TCP/IP. Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно используется для получения информации с веб-сайтов.

Детальное описание протокола HTTP и его структуры раскрыто в международных стандартах RFC 1945, RFC 2616 и находится за рамками данного документа [16-17].

HTTPS — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Это расширение было разработано, чтобы обеспечить аутентификацию и защищённое соединение. HTTPS широко используется в веб-приложениях, в которых важна безопасность соединения.

Детальное описание протокола HTTPS раскрыто в международном стандарте RFC 2660 [18] и находится за рамками данного документа.

3.3 Протокол TLS

Целью протокола TLS (Transport Layer Security) является обеспечение конфиденциальности и целостности данных при коммуникации двух приложений. Протокол имеет два уровня: протокол записей TLS и протокол диалога TLS. На нижнем уровне, работающем поверх надежного транспортного протокола (например, TCP), размещается протокол записей TLS. Этот протокол обеспечивает безопасность соединений, которые имеют два основных свойства:

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

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

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

Протокол TLS базируются на спецификации протокола SSL 3.0. Различия между протоколом TLS 1.0 и SSL 3.0 незначительны, но TLS 1.0 и SSL 3.0 не совместимы

Протокол диалога TLS обеспечивает безопасное соединение, которое имеет три базовых свойства:

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

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

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

Полное описание протокола TLS раскрыто в документе «Проект интерфейса защищенного доступа для пользователей к веб-серверу с установленным модулем разграничения доступа для протокола HTTP» и международном стандарте RFC 2246 [19].

3.4 Утилита командной строки

Программные роботы – утилиты командной строки предназначены для работы на стороне серверов прикладного уровня пользователя и обеспечивают автоматическое формирование заявки (DVC, OCSP или TSP) с доставкой ее на сервер и получением в режиме ON-LINE квитанций - ответов. Анализ содержания квитанции может являться основой для работы механизмов внутренний логики прикладного ресурса по обработке заверенных электронных документов. Транспортировка заявок и квитанций может осуществляется по защищенному протоколу TLS с предоставлением сертификата уполномоченного лица, управляющего утилитой.

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

3.5 Протокол OCSP

Служба «Электронного Нотариата» имеет в своем составе службу, реализующую функцию определения статуса сертификатов открытого ключа в реальном времени по протоколу OCSP (Online Certificate Status Protocol).

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

3.5.1 Информационные потоки

Пользователь сервиса формирует OCSP-запрос и осуществляет его доставку по протоколу HTTP как MIME объект с Content-Type application/ocsp-request. На стороне сервера производится проверка синтаксиса запроса, ЭЦП под запросом (если ЭЦП присутствует), проверка статусов цифровых сертификатов открытого ключа, указанных в запросе. Далее формируется OCSP-ответ, который доставляется пользователю по протоколу HTTP как MIME объект с Content-Type application/ocsp-response. Тип OCSP-ответа может быть одним из следующих:

1) Successful – запрос обработан, успешно сформирован ответ.

2) Malformed Request – полученный запрос не соответствует синтаксису OCSP.

3) Internal Error – На сервере произошла внутренняя ошибка.

4) Try Later – Сервер временно не может сформировать ответ для запрашиваемого сертификата. Следует обратиться позже.

5) Signature Required – Сервер требует простановки ЭЦП под запросом либо подпись под запросом не верна.

6) Unauthorized – У пользователя недостаточно прав чтобы осуществлять данный запрос на сервере.

В случае успешной обработки OCSP-запроса (тип Successful) для каждого сертификата в запросе возвращается статус. Возможны следующие типы статусов сертификата:

1) Good – Сертификат действителен.

2) Unknown – Статус сертификата неизвестен. Серверу не удалось найти издателя сертификата либо для указанного издателя не удалось найти сертификата с серийным номером, указанным в запросе.