Сертифицирован ли NcaLayer

#1

Добрый день, знакомые юристы попросили поинтересоваться.

У вас на сайте размещен сертификат соответствия по 1073 некоего программного продукта Kalkan Crypt версии 1.0.
В составе, которого Java криптографическая библиотека не указанной версии.

Вопрос собственно: как соотносится продукт NcaLayer версии 1.3 и обозначенный в сертификате соответствия продукт kalkan crypt версии 1.0

Является ли продукт NcaLayer 1.3 сертифицированным по 1073?
Являются ли текущая Java библиотека kalkan версии 0.6.1 сертифицированной ?

Будет ли подпись проставленная в сторонней информационной системе проставленная с помощью NcaLayer 1.3 являться юридически значимой ?
Будет ли подпись проставленная в сторонней информационной системе проставленная с помощью kalkancrypt-0.6.1.jar.jar являться сертифицированной ?

#2

NCALayer это не криптопровайдер и следовательно нет необходимости его сертифицировать. Можно представить NCALayer как “прослойку” между браузером и провайдером Kalkancrypt.

#3

получается, если в свое ПО вставить и использовать Kalkancrypt, то такое ПО сертифицировать не надо на 1073? И оно будет считаться легитимным средством электронной цифровой подписи?

#4

По правилам требуется сертифицировать СКЗИ (https://adilet.zan.kz/rus/docs/V1500012181). Если ваше ПО не является СКЗИ, то соответственно нет необходимости его сертифицировать.

#5

Как отдельно kalkancrypt.jar может быть сертифицирован на 1073.

Ввиду того, что:

Пункт стандарта 1073 - 4.2 гласит: 4.2 СКЗИ, соответствующие требованиям настоящего стандарта, рассматриваются как технологически завершенные (работоспособные) аппаратные, программные или аппаратно-программные средства.

Библиотека сама по себе не является технологически заверешнным продуктом. Сама по себе она не может функционировать. Нужна вызывающая программа, которая будет использовать эту библиотеку. И только вместе программа+библиотека являются технологически заверешенными.

Ну и далее практически каждый пункт, который выдвигает ограничения на длину используемых хэшей, симметирчных и ассиметричных ключей не проходит

KALKAN: Cipher.DES -> kz.gov.pki.kalkan.jce.provider.JCEBlockCipher$DES

KALKAN: Signature.MD2WithRSAEncryption -> kz.gov.pki.kalkan.jce.provider.JDKDigestSignature$MD2WithRSAEncryption
aliases: [MD2withRSAEncryption, 1.2.840.113549.1.1.2, MD2WithRSA, MD2withRSA, MD2/RSA, MD2WITHRSAENCRYPTION]

KALKAN: Signature.MD4WithRSAEncryption -> kz.gov.pki.kalkan.jce.provider.JDKDigestSignature$MD4WithRSAEncryption
aliases: [MD4withRSAEncryption, MD4WithRSA, MD4withRSA, MD4/RSA, 1.2.840.113549.1.1.3]

KALKAN: Signature.MD5WithRSAEncryption -> kz.gov.pki.kalkan.jce.provider.JDKDigestSignature$MD5WithRSAEncryption
aliases: [MD5withRSAEncryption, MD5WithRSA, MD5withRSA, MD5/RSA, 1.2.840.113549.1.1.4, 1.2.840.113549.2.5with1.2.840.113549.1.1.1, MD5WITHRSAENCRYPTION, MD5WITHRSA]

#6

Укажите источник, где указывается то, что технологически завершенное ПО не должно вызываться другим ПО. По такой логике NCALayer тоже незавершенный продукт, потому что нужно вызывать его методы и просто так он вам ничего не подпишет. Следовательно ничего сертифицировать не надо. :+1:

Если у вас есть претензии, то обратитесь к аккредитованной испытательной лаборатории, которая выдала сертификат соответствия. Лаборатория указана на самом сертификате.

В целом по вопросам касательно документов, законов и т.д. лучше писать на info@pki.gov.kz.

#7

Ну тут действительно найти определение технологически завершенного ПО - трудно. Чисто логически так сужу. Ну да ладно, забьём на этот пункт, насчет которого можно спорить и иметь разные мнения.

В части вопросов с теми же алгоритмами, которые kalkan.jar предоставляет неоднозначностей меньше. MD2, MD4 и прочие - явно не проходят под требования стандарта 1073.

Так я вот для начала и хотел разобраться - на что же всё таки выдан сертификат. Потому как под программный продукт Kalkan Crypt версии 1.0 как-то kalkan-0.6.1.jar не сильно подходит.

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

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

Обращаться в испытательную лабораторию я конечно же не буду (ну что они мне пояснят)?
Тут если куда и обращаться - то наверное в ГТС - это вроде как их зона компетенции.

PS.

По этой логике да - NCALayer тоже не заверешнный продукт. А сертифицировать надо связку pki.gov.kz + NCALayer, egov.kz + NCALayer. etc…

#8

Соответственно сертификат нужно аннулировать, с лабораторией, выдавшей его - разобраться. Ну а дейтельность НУЦа приостановить на время, пока из провайдера не выпилят всё лишнее и не проведут повторную сертификацию )))

Отлично! Давно пора навести шороху. Может сынициируете обращение в министерство? Может наконец-то сначала создадут институт на базе, которого будут приниматься какие-то эталонные решения, писаться хотя бы те же RFC и спецификации. Создадут при нём лабораторию разработки для решения прикладных задач. Вот тогда может и заживём. А на время приостановки «дейтельности» можно будет и отдохнуть… всем.
А по существу, удаление лишних алгоритмов можно взять в работу. Сначала убрать из числа регистрируемых, а потом удалить и сами реализации.

#9

Ну ок, а вот по этому поводу куда надо обращаться ?

Сертификат вам выдан 30.07.2021 (судя по датам вероятнее всего соответствует версии 0.6.1)
А сейчас в последней версии NcaLayer у вас представлен kalkancrypt-0.6.2.jar (выпущенный 17.01.2022)

Получается, что NcaLayer использует несертифицированную версию библиотеки ?

#10

Добрый день.

После сертификации kalkancrypt криптографические библиотеки не менялись, изменения вносились в функциональную часть для обеспечения работы НУЦ.
Следуя Вашей логики, нельзя менять файлы библиотек которые присутствуют в сертификате соответствия. Если пойти по такому пути, то любое изменение kalkancrypt нужно сертифицировать, а это большие деньги и время от 1 года и все развитие остановится.

#11

У вас изменилась именно библиотека в которой реализованы криптоалгоритмы.

Естетственно, после внесения в неё изменений она должна быть пересертифицирована. Иначе как убедиться, что она всё ещё соответствует требованиям стандарта. (Это в нормальной ситуации. У вас же она изначально конечно не соответствовала - смотрите выше)

#12

Добрый день, @mika.

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

Меня этот вопрос давно интересует и очень интересна Ваша точка зрения.

#13

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

  1. согласно закона “Об электронном документе и электронной цифровой подписи” статья 11 “Средства электронной цифровой подписи подлежат подтверждению соответствия в случаях и порядке, установленных законодательством Республики Казахстан в области технического регулирования.”
  2. В " Правилах проведения аккредитации удостоверяющих центров" в обязательном порядке требуется предоставить “электронную копию сертификатов соответствия на используемые средства криптографической защиты информации по СТ РК 1073-2007 не ниже второго уровня, которые применяется услугополучателем и его пользователями”
#14

Добрый день.

я выше описал наше мнение, Вы с ним можете согласиться или нет, это Ваше право.
в этом году во 2 квартале планируется повторная сертификация, в связи с переходом на СТ РК ГОСТ Р 34.10-2015

#15

@Pablo, точно, но:

  1. согласно закона “Об электронном документе и электронной цифровой подписи” статья 11 “Средства электронной цифровой подписи подлежат подтверждению соответствия в случаях и порядке, установленных законодательством Республики Казахстан в области технического регулирования.”

Но где прописаны случаи и порядок? Да и на соответствие чему необходимо сертифицировать? К сожалению я не в курсе на что тут можно ссылаться.

В " Правилах проведения аккредитации удостоверяющих центров" в обязательном порядке требуется предоставить “электронную копию сертификатов соответствия на используемые средства криптографической защиты информации по СТ РК 1073-2007 не ниже второго уровня, которые применяется услугополучателем и его пользователями”

А тут речь идет о требованиях к УЦ. Мы же сейчас обсуждаем скорее требования к пользователям. То есть УЦ, чтобы пройти аккредитацию, обязан работать на сертифицированных СКЗИ, но я не знаю о требовании использовать для формирования ЭЦП исключительно тех СКЗИ, которые предоставил (или допускает использовать) УЦ.

#16

В самом СТ РК 1073.

#17

Ну а где определено, что обычная ЭЦП создается СКЗИ 2-го уровня? Что эти средства должны быть сертифицированы?
В приказе “Об утверждении Правил выдачи, хранения, отзыва регистрационных свидетельств и подтверждения принадлежности и действительности открытого ключа электронной цифровой подписи корневым удостоверяющим центром Республики Казахстан, удостоверяющим центром государственных органов и национальным удостоверяющим центром Республики Казахстан” есть про открытый ключ:

Глава 5. Порядок подтверждения принадлежности и действительности открытого ключа электронной цифровой подписи

  1. Проверка регистрационного свидетельства на действительность подписывающей стороны осуществляется путем выполнения следующих проверок с использованием СКЗИ НУЦ РК:

Есть про носители

  1. носитель ключевой информации – специализированный носитель, в котором для защиты хранящихся закрытых ключей электронной цифровой подписи используется СКЗИ, имеющее сертификат соответствия требованиям национального Стандарта Республики Казахстан 1073-2007 “Средства криптографической защиты информации. Общие технические требования” (2 уровень);

Всё. Где и на что опираться?

#18

В Приложение 1 к Правилам проведения аккредитации удостоверяющих центров, описаны требования к СКЗИ:
электронная копия сертификатов соответствия на используемые средства криптографической защиты информации по СТ РК 1073-2007 “Средства криптографической защиты информации. Общие технические требования” не ниже второго уровня, которые применяется услугополучателем и его пользователями.

#19

Но ведь “Правила проведения аккредитации удостоверяющих центров” - это требования к УЦ, под них не попадают пользователи УЦ. То есть не получится в суде признать какой-то электронный документ, подписанный ЭЦП, не имеющим юридической значимости на основании того, что при формировании ЭЦП субъект не соответствовал какому-то положению “Правила проведения аккредитации удостоверяющих центров”.