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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline Евгений Пономаренко  
#1 Оставлено : 29 января 2020 г. 15:27:06(UTC)
Евгений Пономаренко

Статус: Активный участник

Группы: Участники
Зарегистрирован: 03.05.2012(UTC)
Сообщений: 171
Откуда: Екатеринбург

Сказал(а) «Спасибо»: 46 раз
Поблагодарили: 23 раз в 19 постах
Добрый день.
Вопрос следующий-
руководствуясь Приложением 2 из ЖТЯИ.00102-01 95 01. КриптоПро CSP. Правила пользования, я пишу некий софт. При этом мне нужно исключить необходимость разработки отдельного СКЗИ.
Вроде бы все понятно. Набор необходимых и достаточных вызовов есть в этом приложении.
Но при этом- у меня есть настоятельная потребность формировать cades-bes (cms) без использования API. т.е. я получаю "голую" подпись данных (64 байта) при помощи КриптоПро API, а остальные действия произвожу самостоятельно.
Могут ли эти действия считаться "криптографическими"? Или все нормально, и будет достаточно работ по оценке влияния?
Offline Владимир Пузырев  
#2 Оставлено : 30 января 2020 г. 15:19:07(UTC)
Владимир Пузырев

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

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

Доброго дня!

В документации отсутствует запрет на формирование "нового" формата данных на основе указанного в документации набора вызовов. Если все выбранные вызовы интерфейса КриптоПро CSP есть в перечне, тогда действительно возможно их использовать без создания нового СКЗИ после проведения работ по оценке влияния.

Вместе с тем стоит отметить, что по положительным результатам работ по оценке влияния в общем случае можно будет только утверждать, что КриптоПро CSP в новой среде работает корректно и что отсутствует негативное влияние со стороны разработанного прикладного ПО.

За полным ответом лучше обратиться к регулятору. Если предположить, что формируемые на стороне прикладного ПО сообщения формата cades-bes нужны не просто так, а так или иначе для защиты информации, тогда наверняка потребуется разработать отдельное СКЗИ. Если сообщения будут целиком формироваться средствами КриптоПро CSP, то можно пытаться обойтись без создания нового СКЗИ, однако порядок работ для конечной информационной системы будет подлежать обсуждению с регулятором.

Отредактировано пользователем 30 января 2020 г. 15:20:52(UTC)  | Причина: Не указана

Offline Евгений Пономаренко  
#3 Оставлено : 31 января 2020 г. 9:04:45(UTC)
Евгений Пономаренко

Статус: Активный участник

Группы: Участники
Зарегистрирован: 03.05.2012(UTC)
Сообщений: 171
Откуда: Екатеринбург

Сказал(а) «Спасибо»: 46 раз
Поблагодарили: 23 раз в 19 постах
Автор: Владимир Пузырев Перейти к цитате

За полным ответом лучше обратиться к регулятору.

Обратиться к регулятору в данном случае и есть проверка корректности встраивания. С положительным или отрицательным результатом.
Задам вопрос проще-
1) результат вызова CryptSignMessage и есть искомая cades-bes. Тут все понятно и хорошо
2) вызов CryptCreateHash/CryptSignHash без нарушения условий формуляра, получение подписи. Формирование CMS, идентичной пункту 1, является созданием самостоятельного СКЗИ?

Offline Владимир Пузырев  
#4 Отправлено: : 31 января 2020 г. 20:39:41(UTC)
Владимир Пузырев

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

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

Если отвечать как можно проще, то -
да, самостоятельное формирование структуры CMS, идентичной создаваемой CryptSignMessage, по умолчанию приводит к созданию нового СКЗИ (кажется, что могут быть исключения, но на это не стоит закладываться). Из документации это следует только опосредованно.
Offline Евгений Пономаренко  
#5 Оставлено : 3 февраля 2020 г. 13:35:47(UTC)
Евгений Пономаренко

Статус: Активный участник

Группы: Участники
Зарегистрирован: 03.05.2012(UTC)
Сообщений: 171
Откуда: Екатеринбург

Сказал(а) «Спасибо»: 46 раз
Поблагодарили: 23 раз в 19 постах
Автор: Владимир Пузырев Перейти к цитате
Если отвечать как можно проще, то -
да, самостоятельное формирование структуры CMS, идентичной создаваемой CryptSignMessage, по умолчанию приводит к созданию нового СКЗИ (кажется, что могут быть исключения, но на это не стоит закладываться). Из документации это следует только опосредованно.


А можно увидеть, в каком месте документации это хотя бы опосредованно указано?
Или тут все будет по желанию левой пятки проводящих проверку?
Тот же вопрос, но немного с другой стороны.
Где-то определен перечень именно криптографических операций, которые и составляют собственно СКЗИ?
Навскидку, это генерация ключей, хэширование, подпись/проверка, шифрование/расшифрование. что-то еше?
Упаковка результата криптографической операции в некий массив байт- тоже криптографическая операция? где та грань, если это не отражено в документации?
Offline two_oceans  
#6 Оставлено : 4 февраля 2020 г. 7:40:45(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 221 раз в 207 постах
Цитата:
Упаковка результата криптографической операции в некий массив байт- тоже криптографическая операция? где та грань, если это не отражено в документации?
Меня тоже интересует такой вопрос. Как мне кажется проблема возникнет не с тем, что упаковать результат в массив (тут все прозрачно и скзи на мой взгляд не возникнет как не конвертируй результат), а с тем что cades xades в ряде случаев подписывают не то, что передает пользователь, например, не исходный файл, а атрибуты в которых хэш исходных данных или тег SignedInfo c хэшами фрагментов документа. Вот именно с генерацией подписываемого, не связанного напрямую с подписываемыми данными, возникнет проблема корректности. Фактически Вы уже сами частично сделаете ту же операцию подписания (для более широкого формата подписи cades чем низкоуровневая RawSignature), что может быть расценено как новое скзи.

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

В конечном счете, выходит все зависит называть самодельное подписью или нет? Скажете, что это массив байт "как есть" без всяких гарантий, по чистой случайности совпавший с cades и Ваша программа не скзи? Если пользователи будут использовать массив как cades это уже их проблема? Скажете, что делаете подпись cades и программа внезапно скзи?

Отредактировано пользователем 4 февраля 2020 г. 7:52:28(UTC)  | Причина: Не указана

Offline Евгений Пономаренко  
#7 Оставлено : 5 февраля 2020 г. 7:53:07(UTC)
Евгений Пономаренко

Статус: Активный участник

Группы: Участники
Зарегистрирован: 03.05.2012(UTC)
Сообщений: 171
Откуда: Екатеринбург

Сказал(а) «Спасибо»: 46 раз
Поблагодарили: 23 раз в 19 постах
Автор: two_oceans Перейти к цитате
С другой стороны, если сделать просто список хэшей (возвращенных белым списком) файлов, а потом от списка посчитать и подписать хэш (белым списком), приклеить к списку значение подписи и сертификат, то скзи с моей точки зрения не возникнет, так как компоненты подписания четко разделены на 2 операции: формирование списка хэшей произвольного формата и raw подписание.

А вот этого как раз таки делать нельзя, исходя из документации. Прямо написано, что CryptSetHashParam
Разрешено использование только с символьными аргументами HP_HASHSTARTVECT (при условии, что передаваемый объект функции хэширования был создан функцией CryptCreateHash с символьным аргументом CALG_GR3411), HP_PBKDF2_SALT, HP_PBKDF2_PASSWORD, HP_PBKDF2_COUNT, HP_OID/KP_HASHOID, HP_OPEN.
Этому есть подтверждение из других источников, в частности Крриптотокен2 на Jacarta SE2 не умеет подписывать сторонний хэш- это было условием прохождения сертификации.

Но вернемся к вопросу. Хотелось бы услышать мнение авторитетных сотрудников КриптоПро по поводу ручной сборки CMS
Offline two_oceans  
#8 Оставлено : 5 февраля 2020 г. 9:40:58(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 221 раз в 207 постах
Автор: Евгений Пономаренко Перейти к цитате
Автор: two_oceans Перейти к цитате
С другой стороны, если сделать просто список хэшей (возвращенных белым списком) файлов, а потом от списка посчитать и подписать хэш (белым списком), приклеить к списку значение подписи и сертификат, то скзи с моей точки зрения не возникнет, так как компоненты подписания четко разделены на 2 операции: формирование списка хэшей произвольного формата и raw подписание.

А вот этого как раз таки делать нельзя, исходя из документации. Прямо написано, что CryptSetHashParam

Но вернемся к вопросу. Хотелось бы услышать мнение авторитетных сотрудников КриптоПро по поводу ручной сборки CMS
Я не предлагаю использовать CryptSetHashParam, в процитированном имелось в виду подписать список хэшей (с именами или другими отличительными идентификаторами файлов) уже как данные, то есть
Цитата:
от списка посчитать и подписать хэш
это CryptCreateHash, CryptHashData (список хэшей), CryptSignHash, а CryptSetHashParam не используется. Действительно, вернемся к теме.

Отредактировано пользователем 5 февраля 2020 г. 9:49:01(UTC)  | Причина: Не указана

Offline Владимир Пузырев  
#9 Оставлено : 5 февраля 2020 г. 11:46:54(UTC)
Владимир Пузырев

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

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

Помочь в разборе ситуации помогут документы
  • "Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств зашиты информации (Положение ПКЗ-2005)" (например, пп. 2, 3, 4),
  • Формуляр на КриптоПро CSP (п.1.5),
  • Правила пользования КриптоПро CSP (пп. 4 и 6).
В зависимости от набора используемых вызовов из Приложения 2 Правил пользования в документах на разрабатываемое ПО (и в ТЗ в том числе) можно будет написать
либо "<Наименование ПО> предназначено для формирования и проверки ЭП средствами КриптоПро CSP",
либо "<Наименование ПО> предназначено для формирования и проверки ЭП в формате CMS средствами КриптоПро CSP".

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

Тем не менее, я в первую очередь посоветую обратиться за консультацией к Регулятору, тем более, что это потребуется сделать (максимум как поздно - с передачей технического задания) и при оценке влияния, и при разработке нового СКЗИ.
Offline Евгений Пономаренко  
#10 Оставлено : 5 февраля 2020 г. 17:41:15(UTC)
Евгений Пономаренко

Статус: Активный участник

Группы: Участники
Зарегистрирован: 03.05.2012(UTC)
Сообщений: 171
Откуда: Екатеринбург

Сказал(а) «Спасибо»: 46 раз
Поблагодарили: 23 раз в 19 постах
Автор: Владимир Пузырев Перейти к цитате
Помочь в разборе ситуации помогут документы
  • "Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств зашиты информации (Положение ПКЗ-2005)" (например, пп. 2, 3, 4),
  • Формуляр на КриптоПро CSP (п.1.5),
  • Правила пользования КриптоПро CSP (пп. 4 и 6).
В зависимости от набора используемых вызовов из Приложения 2 Правил пользования в документах на разрабатываемое ПО (и в ТЗ в том числе) можно будет написать
либо "<Наименование ПО> предназначено для формирования и проверки ЭП средствами КриптоПро CSP",
либо "<Наименование ПО> предназначено для формирования и проверки ЭП в формате CMS средствами КриптоПро CSP".

Документы, обозначенные выше, прояснить ситуацию не могут. Никак.
Естественно, в ТЗ будет написано "<Наименование ПО> предназначено для формирования и проверки ЭП средствами КриптоПро CSP"
+ перечисление (список сертифицированных криптопровайдеров, для которых существует своя докумеентация). КриптоПро CSP- лишь один из используемых.
Не будем усложнять, в этом кейсе для простоты только КриптоПро CSP.
Набор используемых вызовов будет соответствовать Приложению 2. Само собой. Однако,

Автор: Владимир Пузырев Перейти к цитате

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

В Приложении 2 присутствуют именно вызовы функций, т.е. операции над данными, а не сами форматы данных. Может ли формат данных быть "криптографическим" сам по себе? Так легко объявить криптографическими все операции над ASN.1.
Общее понимание того, что можно, а что нельзя, существует. Я не задаю вопрос, могу ли я, используя криптографические функции из Приложения 2, в дополнение к ним использовать еще и собственную реализацию ГОСТ Р 34.11-2012 с какими-то целями. Есть какие-то ссылки на "общую тенденцию"?

Автор: Владимир Пузырев Перейти к цитате

Тем не менее, я в первую очередь посоветую обратиться за консультацией к Регулятору, тем более, что это потребуется сделать (максимум как поздно - с передачей технического задания) и при оценке влияния, и при разработке нового СКЗИ.

У Вас, возможно, есть опыт обращения к регулятору с подобными запросами? Интересно было бы посмотреть практику. Легко представить, что такая консультация закончится вопросом, умею ли я читать, и если да, то -> ПКЗ2005 и документация на СКЗИ.
Т.е. данный случай это игра в рулетку, я верно понимаю? т.е. подготовка и передача ТЗ, а там, как карта ляжет. так?

Отредактировано пользователем 5 февраля 2020 г. 17:49:29(UTC)  | Причина: Не указана

Offline Владимир Пузырев  
#11 Оставлено : 6 февраля 2020 г. 12:42:36(UTC)
Владимир Пузырев

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

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

Автор: Евгений Пономаренко Перейти к цитате
Может ли формат данных быть "криптографическим" сам по себе?

Формат может по умолчанию (т.е. «сам по себе») быть предназначен для криптографической защиты информации.

Автор: Евгений Пономаренко Перейти к цитате
Есть какие-то ссылки на "общую тенденцию"?

Общая тенденция прослеживается на примере принимаемых и рассматриваемых документов ТК26 (https://tc26.ru/standarts/).

Автор: Евгений Пономаренко Перейти к цитате
У Вас, возможно, есть опыт обращения к регулятору с подобными запросами?

Опыта обращения без ТЗ нет. В обращениях с ТЗ формат CMS будет отнесён к тем форматам, реализация которых подлежит исследованию и должна соответствовать рекомендациям ТК26.

Автор: Евгений Пономаренко Перейти к цитате
Т.е. данный случай это игра в рулетку, я верно понимаю? т.е. подготовка и передача ТЗ, а там, как карта ляжет. так?

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