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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline DSRX  
#1 Оставлено : 31 августа 2021 г. 23:30:09(UTC)
DSRX

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

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

Здравствуйте!

Интересует вопрос необходимости наличия лицензий (ФСБ и/или ФСТЭК и/или какой-либо еще). Реализуем онлайн сервис ЭДО (исключительно веб-сайт), мы являемся разработчиками. В сервисе планируются следующие функции (каждая из которых, как нам кажется, потенциально должна лицензироваться):

1. Пользователь (отправитель) загружает документ и подписывает его своей ЭЦП средствами КриптоПро Browser Plugin

2. Мы данный документ шифруем с использованием алгоритма RSA (средствами OpenSSL) и сохраняем на сервере

3. Пользователь (получатель) просматривает документ (мы его предварительно расшифровываем), после чего также подписывает его средствами КриптоПро Browser Plugin, мы его опять шифруем RSA и сохраняем на сервере

Итого имеем: применение КриптоПро Browser Plugin + RSA-шифрование документов через OpenSSL и последующее их хранение + сам факт оказания услуг ЭДО (передача документов между пользователями).

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

а) нас, как разработчиков данной системы (работаем по договору подряда)

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

Ознакомившись с положениями лицензирования подобной деятельности ФСБ, отметили для себя следующее (пока-что не понимаем насколько это применимо в данной ситуации):

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

2) Лицензированию не подлежит деятельность с использованием "шифровальных (криптографических) средств, используемых для защиты технологических каналов информационно-телекоммуникационных систем и сетей связи, не относящихся к критически важным объектам" - правильно ли я понимаю, что услуги ЭДО (если они оказываются лицам, не включенным в реестр КИИ РФ) не подлежат лицензированию ФСБ (как с точки зрения нас, в качестве разработчика, так и с точки зрения нашего Клиента, как продавца этих услуг)? В нашем случае такие вещи как отправка отчетности в ФНС, допустим, не планируются. Хотя, возможно, лицензирование ЭДО все-таки требуется (например, просто потому что это обмен документами, которые подписаны ЭЦП)?

3) Пока-что не понимаем как можно сопоставить применение КриптоПро Browser Plugin с положениями о лицензировании - нужна ли лицензия (ФСБ или иная) нам как разработчику системы с использованием данного плагина и/или нашему Клиенту как владельцу сервиса с данным плагином.

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

Кроме лицензии ФСБ, возможно, в контексте нашей ситуации (нам и/или нашему Клиенту) потребуется лицензия ФСТЭК, Роскомнадзора или какая-то еще? Возможно, помимо лицензирования потребуется сертификация (и если да то по каким стандартам)?

Всем заранее спасибо за помощь!

Отредактировано пользователем 1 сентября 2021 г. 0:40:40(UTC)  | Причина: Опечатка

Offline two_oceans  
#2 Оставлено : 1 сентября 2021 г. 7:39:10(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
На полноту ответа не претендую (исчерпывающе могут ответить только сами регуляторы), выскажу свои мысли. По-моему мнению по линии подписания плагином браузера - лицензирования не требуется, так как подписание фактически выполняется на клиентской стороне и сертифицированными средствами (причем их сертифицированность, правильность использования ключей и т.д. на совести клиента). По сути действия выполняются под контролем самого клиента.
Цитата:
асиметричный криптографический алгоритм, основанный либо на методе разложения на множители целых чисел, размер которых не превышает 512 бит
Современные реализации RSA используют 2048 бит и больше, так что я думаю данный пункт к Вам не относится. Небольшая оговорка, что ключ RSA состоит из двух чисел, так что вероятно длину ключа надо делить пополам, но 1024 все равно не подходит. Менее - будет не стойкое шифрование, смысла шифровать никакого. Еще технический момент с хранением и распространением ключей RSA - ключ нужно либо как-то передавать между адресатам (схема обмена ключей) либо вырабатывать из 2 ассиметричных ключей общий симметричный. По сути клиент должен будет иметь ключ RSA в дополнение к ключу гост.

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

Совсем другой вопрос по поводу ЭДО и хранения документов. Передавать между браузером и своим сервером будете по шифрованному соединению? С каким алгоритмом?

Если соединение без шифрования, то имеет смысл и шифрование / расшифрование документа провести на стороне клиента. Без входа по сертификату не будет необходимости в криптографии на сервере вообще, в самом тривиальном случае сервер будет только хранилищем (сойдет ftp сервер с логином и паролем), все криптографические операции на стороне клиента.

На практике конечно желательно предусмотреть чтобы страничка сайта автоматически проверяла есть ли на клиентском компьютере нужный сертификат; позволяла перешифровать сессионный ключ (на клиентской стороне) со старого сертификата на новый сертификат при смене сертификата; предлагала сертификаты адресатов, то есть полностью от криптографии не уйти, но гораздо проще без шифрования данных.
Offline DSRX  
#3 Оставлено : 1 сентября 2021 г. 8:01:56(UTC)
DSRX

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

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

Спасибо за ответ!

Автор: two_oceans Перейти к цитате
Еще технический момент с хранением и распространением ключей RSA - ключ нужно либо как-то передавать между адресатам (схема обмена ключей) либо вырабатывать из 2 ассиметричных ключей общий симметричный. По сути клиент должен будет иметь ключ RSA в дополнение к ключу гост.

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

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

Автор: two_oceans Перейти к цитате
Совсем другой вопрос по поводу ЭДО и хранения документов. Передавать между браузером и своим сервером будете по шифрованному соединению? С каким алгоритмом?

Естественно, планируем установку SSL-сертификата

Отредактировано пользователем 1 сентября 2021 г. 8:03:48(UTC)  | Причина: Не указана

Online Андрей *  
#4 Оставлено : 1 сентября 2021 г. 8:15:14(UTC)
Андрей *

Статус: Сотрудник

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

Сказал «Спасибо»: 493 раз
Поблагодарили: 2034 раз в 1578 постах
Здравствуйте.

У получателя всегда есть ГОСТ-сертификат?
Если Да - почему бы не шифровать на него + на сертификат отправителя, в плагине?

И не нужна тогда схема с RSA.
Техническую поддержку оказываем тут
Наша база знаний
Offline DSRX  
#5 Оставлено : 1 сентября 2021 г. 8:35:22(UTC)
DSRX

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

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

Автор: Андрей * Перейти к цитате
У получателя всегда есть ГОСТ-сертификат?
Нет, системой могут пользоваться пользователи без ЭЦП в принципе (как отправители, так и получатели).

Автор: Андрей * Перейти к цитате
Если Да - почему бы не шифровать на него + на сертификат отправителя, в плагине?

И не нужна тогда схема с RSA.
Если гипотетически предположить, что у всех сторон документооборота будет ГОСТ-сертификат, то мы можем реализовать сквозное шифрование в плагине КриптоПро? В таком случае мы должны при отправке зашифровать документ с открытым ключом получателя и потом расшифровать с его закрытым ключом?

Выше я описал планируемую схему с RSA:
Автор: DSRX Перейти к цитате
Логику планируем следующую: При регистрации пользователя генерируем для него пару RSA ключей, закрытый ключ защищаем паролем (который вводит сам пользователь), открытый ключ сохраняем в системе. Далее один пользователь отправляет документ другому пользователю. Перед сохранением документа на сервере мы шифруем его открытым ключом получателя, при попытке просмотра входящего документа получатель вводит свой пароль от закрытого ключа и мы можем расшифровать документ.
то есть принципиально схема такая-же? Просто Вы написали
Автор: Андрей * Перейти к цитате
шифровать на него + на сертификат отправителя
а мы предполагали что при шифровании используется только открытый ключ получателя. Буду признателен, если разъясните этот момент. Спасибо!
Online Андрей *  
#6 Оставлено : 1 сентября 2021 г. 8:42:40(UTC)
Андрей *

Статус: Сотрудник

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

Сказал «Спасибо»: 493 раз
Поблагодарили: 2034 раз в 1578 постах
Вы можете шифровать через плагин сразу на несколько получателей (отправитель+получатели).

Код:

  var oRecipients = yield oEnvelopedData.Recipients;
                yield oRecipients.Add(Cert1);
                yield oRecipients.Add(Cert2);
...
                yield oRecipients.Add(CertN); 


Пример шифрования и расшифрования данных с использованием объекта CPEnvelopedData.

Только изменить источник (сертификаты получателей обычно в AddressBook\Другие пользователи или скачиваются с сервера перед шифрованием), в примере используется поиск двух сертификатов из Личного хранилища.
Техническую поддержку оказываем тут
Наша база знаний
Offline DSRX  
#7 Оставлено : 1 сентября 2021 г. 8:54:38(UTC)
DSRX

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

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

Автор: Андрей * Перейти к цитате
Вы можете шифровать через плагин сразу на несколько получателей (отправитель+получатели).
Спасибо за ответ!

В контексте данной темы - как мне кажется, при шифровании по ГОСТ-алгоритмам (с использованием плагина КриптоПро, как Вы предложили) лицензия ФСБ необходима будет в любом случае :)
Offline two_oceans  
#8 Оставлено : 1 сентября 2021 г. 9:14:08(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: DSRX Перейти к цитате
то есть принципиально схема такая-же?
В очень общем плане, на высоком уровне функций да, но есть нюансы: RSA позволяет шифровать и самим ассимметричным ключом (долго шифруется) и симметричным ключом согласования (из двух ассиметричных пар) и сессионным ключом (сгенерированным для конкретного документа). В случае симметричного шифрования конечно алгоритм шифрования не сам RSA, а один из связанных с ним алгоритмов (симметрично шифруется гораздо быстрее). Например, при установлении TLS только небольшая часть данных в начале шифруется ассиметрично, далее идет симметричное шифрование сессионным ключом. Вторая особенность в том, что в RSA при ассиметричном шифровании открытый и закрытый ключ одной пары равноправны - зашифровал одним, расшифровал другим.

ГОСТ не позволяет шифровать ассиметричным ключом, ключи разного размера и неравноправны, всегда нужно либо из двух пар получать симметричный ключ согласования либо генерировать симметричный сессионный ключ. Если у отправителя нет своей пары - приходится генерировать "эфемерную" пару и прикладывать ее открытую часть к документу. В теории это работает и без сертификата, просто нужен открытый ключ другой стороны (Вы можете сгенерировать ключевую пару клиентам у которых нет сертификата), но, как видите, плагин для выбора ключей использует сертификаты, то есть Вам придется для такой пары сделать и сертификат.

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