Планируемые изменения в НУЦ РК на 2022 год

Важно!

На сегодняшний день (10.06.22 г), МЦРИАП РК принято решение о переносе сроков реализации запланированных изменений НУЦ РК в части перехода на криптографический стандарт СТ РК ГОСТ Р 34.10-2015, отказа от ключа аутентификации на алгоритме RSA и исключения невостребованных шаблонов для ЮЛ до 1 октября 2022 года в связи с тем, что информационные системы государственных органов несмотря на заблаговременные уведомления о планируемых изменениях НУЦ РК не успевают произвести соответствующие доработки в своих ИС до 27 июня 2022 года.

В связи с вышеизложенным, обновление информационной системы НУЦ РК в рамках указанных изменений переносится до 1 октября 2022 года.

  1. Отказ от ключа аутентификации AUTH_RSA - физическим и юридическим лицам будет выдаваться одно регистрационное свидетельство / ключ для подписи на алгоритме ГОСТ;

  2. Переход на криптографический стандарт СТ РК ГОСТ Р 34.10-2015;

  3. Исключение из списка доступных шаблонов невостребованные шаблоны: «Сотрудник с правом подписи финансовых документов» и «Сотрудник отдела кадров».

Внимание!
Сообщения, не относящиеся к теме будут удаляться!!

Лучше бы гост убрали, а rsa оставили. Этот гост нигде не поддерживается и не признается.

Добрый день,

Подскажите, пожалуйста:

  1. Переход на ГОСТ 34.10-2018 планируется производить постепенно (в течении какого-то времени НУЦ РК будет выпускать сертификаты и на 34.310-2004 и на 34.10-2018) или одномоментно (в какой-то момент времени НУЦ РК перестанет выпускать сертификаты на 34.310-2004 и начнет на 34.10-2018)?
  2. Планируется полностью отказаться от 34.310-2004 для всех шаблонов сертификатов?
  3. Когда будут зарегистрированы OIDы для новых алгоритмов?
  4. Когда будет доставлена поддержка новых алгоритмов в библиотеки из SDK НУЦ?
  5. В какие библиотеки SDK НУЦ будет добавлена поддержка новых алгоритмов?

Добрый день.

  1. С момента перехода на ГОСТ 34.10-2018 все сертификаты, выпущенные на ГОСТ 34.310-2004 будут до работоспособны до полного окончания cрока их действия;

  2. Да, планируется отказ от 34.310-2004 для всех шаблонов сертификатов;

  3. Планируется на 1 квартал 2022 года;

  4. Поддержка новых алгоритмов в библиотеках SDK НУЦ РК будет осуществлена 1 квартале 2022 года;

  5. Во все возможные библиотеки с поэтапным обеспечением с начала 2022 года до конца в 2-го квартала 2022 года.

Аутентификации по сертификатам не будет? или же для целей аутентификации будут использоваться сертификаты ЭЦП?

или этот вопрос еще не решен?

Вы можете просто использовать ключ подписи вместо ключа аутентификации.

согласно ст рк 1073

5.1.3 Любой используемый СКЗИ ключ должен применяться только одним алгоритмом криптографического преобразования, например, только для шифрования или только для формирования электронной цифровой подписи.

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

Добрый день,

На мой взгляд тут есть две стороны медали.

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

Связано это с тем, что задачи разные:

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

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

Теперь о том как шифрование и подписание связаны с аутентификацией.

Дело в том, что в двусторонней SSL/TLS аутентификации применяется именно шифрование. Изначально сертификаты аутентификации НУЦ использовались именно для двусторонней SSL/TLS аутентификации - если помните для этого нужно было импортировать сертификат и закрытый ключ в браузер и браузер при открытии сайта сам выдавал запрос о том какой сертификат использовать. Такой подход не прижился и все постепенно перешли аутентификацию с использованием NCALayer. В этом случае на самом деле используется подписание - сервер передает браузеру блок случайных данных, браузер передает их NCALayer на подписание, получает подпись и передает ее серверу на проверку. В том случае, если подпись верна, сервер может быть уверен в том, что на той стороне тот, чьи данные указаны в субъекте сертификата. Детальнее схема описана в статье https://sigex.kz/blog/authentication/

То есть уже сейчас сертификат аутентификации используется не для шифрования, а для подписания. Так что противоречия пункту 5.1.3 нет. Более того, это противоречие имело место тогда, когда часть сайтов использовала двустороннюю SSL/TLS аутентификацию, а часть аутентификацию средствами NCALayer, так как пользователи то шифровали, то подписывали одной и то же ключевой парой.

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

Добрый день, в нашей компании (KMF) работники HR (в головном офисе и филиалах) активно используется ЭЦП сотрудник отдела кадров для согласования и отзыва ЭЦП работников. В случае отказа от данного шаблона, какой шаблон можно будет использовать для того, что бы не было избыточности прав, т.к. вроде в текущих шаблонах согласование и отзыв могут производить первый руководитель или сотрудник с правом подписи, а это избыточные права для работников HR.

1 Симпатия

Добрый день. В настоящий момент обсуждается реализация индивидуального наделения правами сотрудников организации по ИИН. Дополнительно будет сообщено по результатам принятых решений.

О чем я и говорил выше.


Таких проблем есть и будет очень много, так как все новые технологии приходят с дальнего зарубежья, а там знать не знают про “наш” ГОСТ.
Отсюда у нас только два пути:

  1. Живем с этим ГОСТом, который по сути является просто переименованным алгоритмом Elliptic curve, и пытаемся пристроить его к новым технологиям и софтам;
  2. Отказываемся от ГОСТа и развиваемся вместе со всем миром не испытывая чувство IT изгоя.
    Очевидно, второй вариант логичнее, но 99,9% вероятности, что этого не будет и это печально.

Какой планируется период, от момента когда будет предоставлен SDK с сертификатами для новых алгоритмов до того как УЦ начнёт выпускать сертификаты в новом формате ?

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

Добрый день!
На данный момент идет тестирование нового функционала.
Переход на новый ГОСТ2015 планируется в первой половине июня месяца 2022 года.
Передача обновленного SDK (Новые библиотеки и тестовые ключи) планируется во второй половине марта месяца 2022 года.

Добрый день!
На данный момент идет тестирование нового функционала.
Переход на новый ГОСТ2015 планируется в первой половине июня месяца 2022 года.
Передача обновленного SDK (Новые библиотеки и тестовые ключи) планируется во второй половине марта месяца 2022 года.

1 Симпатия

То есть у всех систем РК, которые работают с сертификатами НУЦ, будет, по сути, два месяца на доработку.

Интересно, успеют ли операторы государственных систем, у которых доработки должны быть заложены в бюджет годом ранее?

2 месяца - это объективно недостаточный срок для внедрения поддержки новых алгоритмов в сторонние крипто-библиотеки.

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

Почему нужна такая спешка, неужели нельзя сделать всё нормально и цивилизовано. Выпустить от лица УЦ нормальный регламент перехода на новые алгоритмы и установить реальные сроки перехода. (хотя-бы 6 месяцев)

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