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

Добрый день,

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

Первая - техническая. В цитируемом Вами отрывке речь идет о том, что нельзя выполнять обратные операции используя одну ключевую пару. Дело в том, что в 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 месяцев)

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

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

Операторы гос. ИС были предварительно уведомлены официальными письмами.

После перехода на ГОСТ 34.10-2015 будут поддерживаться следующие защищенные носители ключевой информации: eToken5110, KazToken, Akey.

А как же удостоверение личности?

Удостоверение личности в том числе

Не совсем понятно какие библиотеки вы имеете в виду? Пересертификация по СТ РК 1073-2007 нужна будет только для провайдера НУЦ РК.

кроме вашего провайдера (Калкан) в РК есть множество других провайдеров, которые используются в том числе клиентами для работы с сертификатами, выпущенными НУЦ.

Вы обращаетесь в НУЦ РК по вопросу использования регистрационных свидетельств выданных НУЦ РК. В рамках данной государственной услуги НУЦ РК использует и предоставляет для интеграции сертифицированный криптопровайдер KalkanCrypt. За использование и сертификацию других СКЗИ использующихся в Вашей информационной системе, НУЦ РК ответственность не несет. Вам необходимо обратиться к поставщику СКЗИ за соответствующим сертификатом и консультацией. Вместе с этим, НУЦ РК заблаговременно направлял соответствующую информацию от 17.09.2021г, во все государственные органы от МЦРИАП (владелец НУЦ РК), по информационной рассылке (интегрированным системам), а также на данном форуме о планируемых изменениях.

Понятно, что НУЦ не несет ответственно за сертификацию других СКЗИ. Вопрос лишь в том, что НУЦ мог бы подумать, что другим СКЗИ всё таки придется интегрироваться и предоставил бы для этого адекватное время.

Так нету до сих пор достаточной информации для начала интеграции. Нету OID`ов, непонятно с форматом хранения открытого ключа в структуре SubjectPublicKeyInfo. Непонятно с форматом хранения закрытого ключа в PKCS#12.

И судя по информации на этом форуме, разработчики сторонних СКЗИ получать это только за 2 месяца, до того, как НУЦ полностью перейдёт на выпуск сертификатов по новому алгоритму.