Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline xacinay  
#1 Оставлено : 23 октября 2014 г. 15:51:27(UTC)
xacinay

Статус: Новичок

Группы: Участники
Зарегистрирован: 23.10.2014(UTC)
Сообщений: 4
Российская Федерация
Откуда: Москва

Проектируем распределенный документооборот бух. документов, защищаемый по ГОСТ.
Т.е. с системой работают из удаленных филиалов, функционал подписания реализован посредством КриптоПро 3.6 CSP.

Есть желание оптимизировать сетевую нагрузку. Текущий сценарий выглядит так:
    устанавливается TLS-соединение между клиентом и сервером
    документ передается на удаленный АРМ
    документ подписывается ключом (eToken,КриптоПро) посредством ActiveX компонента
    документ передается на сервер
    TLS-соединение закрывается
    документ на сервере обновляется

И так - последовательно для каждого подписанта.

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

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

Просьба посоветовать наиболее эффективное решение на базе семейства КриптоПро.
Offline Павел Смирнов  
#2 Оставлено : 24 октября 2014 г. 14:01:05(UTC)
Павел Смирнов

Статус: Вам и не снилось

Группы: Администраторы
Зарегистрирован: 24.12.2007(UTC)
Сообщений: 831
Откуда: Крипто-Про

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

Применение протокола TLS может лишь увеличить сетевой трафик (по сравнению с передачей по незащищённому каналу), но в вашей схеме использование сертифицированного СКЗИ для защиты канала клиент-сервер необходимо.
Техническую поддержку оказываем тут.
Наша база знаний.
Offline xacinay  
#3 Оставлено : 27 октября 2014 г. 17:38:46(UTC)
xacinay

Статус: Новичок

Группы: Участники
Зарегистрирован: 23.10.2014(UTC)
Сообщений: 4
Российская Федерация
Откуда: Москва

Коллега, спасибо за ответ! Контекст у вопроса следующий. Целевая Система обрабатывет Документы в Электронном Виде (ДЭВ). Подписываемые ДЭВ участвуют в информационном обмене, регламентированном указанием ЦБ 2346-У (бухгалерские отчетные формы, 50-500Мб).

У пользователя есть доступ через веб-приложение к реквизитам ДЭВ и оригинальному файлу ДЭВ(печатная pdf-форма по запросу).
возможность визировать(подписывать).
Соответственно, есть мысль с сервера на АРМ на подписание передавать хэш-значение документа посчитанное КриптоПро CSP вместо тела документа, приравнивать подписание хэш-значения к подписанию оригинального ДЭВ.

Не противоречит ли изложенный выше подход существующей практике(нормативной базе насколько понимаю не противоречит)?
Рекомендуется ли использовать в этих целях какой-либо конкретный CSP-алгоритм ГОСТ (для хэш)?
Достаточно ли средств КриптоПро CSP для валидации на сервере полученной с АРМ подписи(обратное преобразование)?

Отредактировано пользователем 27 октября 2014 г. 19:18:16(UTC)  | Причина: Не указана

Offline Павел Смирнов  
#4 Оставлено : 28 октября 2014 г. 10:26:37(UTC)
Павел Смирнов

Статус: Вам и не снилось

Группы: Администраторы
Зарегистрирован: 24.12.2007(UTC)
Сообщений: 831
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 48 раз в 44 постах
Изложенный подход не будет противоречить практике и нормативной базе, если система перед подписанием ознакомит пользователя с документом. Для хэширования на данный момент в сертифицированном КриптоПро CSP есть только один алгоритм - ГОСТ Р 34.11-94. На серверной стороне функциями КриптоПро CSP можно будет проверить сделанную на клиенте подпись.
Техническую поддержку оказываем тут.
Наша база знаний.
Offline xacinay  
#5 Оставлено : 27 ноября 2014 г. 12:51:43(UTC)
xacinay

Статус: Новичок

Группы: Участники
Зарегистрирован: 23.10.2014(UTC)
Сообщений: 4
Российская Федерация
Откуда: Москва

Добрый день! Описанный подход согласовываю со службой безопасности нашей Организации.
1. Просьба пояснить, на какие нормативные документы будет правильно сослаться для аргументации подписания документов по хэш-функции ГОСТ Р 34.11-94.
Использовать планируем СКЗИ КриптоПро.
2. С формальной точки зрения, в какой форме можно направить официальный запрос на использовние и получить официальный ответ?
Offline Павел Смирнов  
#6 Оставлено : 28 ноября 2014 г. 10:08:15(UTC)
Павел Смирнов

Статус: Вам и не снилось

Группы: Администраторы
Зарегистрирован: 24.12.2007(UTC)
Сообщений: 831
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 48 раз в 44 постах
По вопросам:

1. Вопрос не совсем понятен. Если планируете использовать КриптоПро CSP, то выбора алгоритмов хэширования нет - он там один. Также обратите внимание, что хэш-функция не подписывает документ, а считает хэш-значение.
Если вам нужно обеспечить подписание квалифицированной ЭП, то ссылаетесь на ФЗ "Об электронной подписи", затем на сертификат ФСБ на КриптоПро CSP, затем на эксплуатационную документацию КриптоПро CSP.

2. Присылайте официальное письмо на наш адрес.
Техническую поддержку оказываем тут.
Наша база знаний.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest (2)
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.