🪙Цифровой рубль - новый этап внедрения массовой отечественной криптографии

Через неделю мобильные приложения самых крупных банков должны получить апгрейд, по итогу которого каждый телефон получит своё СКЗИ (год назад таким образом в приложение Госуслуг был интегрирован TrustCryptoBase Госключ).

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

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

🔐 PKI - основа инфраструктуры Цифрового рубля:
🔹Два Головных УЦ в Банке России для НЭП и TLS.
🔹в самих банках два УЦ, уже подчиненных - аналогично для НЭП и TLS (в 2027 году - переход на НУЦ), а также TLS-шлюзы и СКЗИ класса КС3,
🔹в мобильных приложениях граждан - средства ЭП КС1, на рабочих местах корпоративных CSP, криптоплагины и браузеры с ГОСТ-TLS.

Согласно программе PKI-Форума заместитель Председателя Банка России приглашена к участию в стратегической сессии "Куда и как развивается отрасль" по вопросу "PKI в цифровом рубле".

✍️Телеграм-канал "Об ЭП и УЦ" четвертый раз выступает информационным партнёром форума.

✍️CA/Browser Forum: корректировка причин отзыва сертификатов

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

Статистика показывает большой разброс: одни УЦ массово используют код "unspecified", другие "superseded", третьи "cessationOfOperation", что и говорит о разной трактовке одного и того же стандарта.

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

Представитель TWCA сообщил, что Chrome, публично заявил - отзывы сертификатов добавляются в CRLSet на основе указанного кода причины (keyCompromise или privilegeWithdrawn). Однако, согласно официальной документации, в CRLSet сейчас попадают только keyCompromise, но не privilegeWithdrawn.

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

Предлагается поэтапный план:
Этап 1 - пересмотр раздела 4.9.1.1 (обстоятельства, требующие отзыва):
🔹установить иерархию, чтобы конкретная причина имеет приоритет над общей
🔹убрать дублирования и пересекающиеся формулировки 🔹чётко разграничить: ключевая безопасность, валидация, авторизация, техническое соответствие
🔹ввести дерево решений для аудиторов и операторов УЦ
🔹пересмотреть, вписываются ли 24-часовые и 5-дневные сроки в новую семантику
🔹определить, как быть с требованиями CP/CPS, которые строже BR - считать ли их нарушением BR или выделять отдельно.

Этап 2 - пересмотр раздела 7.2.2
/RFC 5280 (сопоставление с кодами CRL):
🔹сделать использование кодов единообразным для всех УЦ
🔹пересмотреть устаревшие коды (holdInstruction, removeFromCRL)
🔹чётко определить, когда использовать superseded (только для плановой замены, а не для компрометации)
🔹обсудить возможность изменения RFC 5280 (это более масштабная задача ведь текущие определения не работают)

Как обычно, вопросов много:
1. Как быть с выбором кода неопытным оператором, если он выбирает "на глаз"?
2. Должен ли УЦ проверять обстоятельства или достаточно заявления пользователя?
3. Как УЦ должен проверять причины, заявленные пользователем? Как независимо подтвердить прекращение деятельности?
4. Должен ли УЦ изменить код, если его анализ показывает другую причину?
5. Не пора ли менять RFC 5280, если существующие коды не соответствуют современным реалиям?

✍️"Об ЭП и УЦ"