Ключи, Сертификаты, МЧД

Определения понятий, и как они соотносятся

Аналогия: как устроены электронные подписи через сравнение с обычной жизнью

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

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

• У человека есть тело — его можно сравнить с токеном.
  Это физический носитель, который “носит” в себе всё, что нужно для подписи.

• Есть рука, которой он ставит уникальную подпись — её можно сравнить с ГОСТ-ключом.
  ГОСТ-ключ служит инструментом для создания электронной подписи, так же как рука служит инструментом для подписи на бумаге.

• Есть сама подпись как результат действия руки — и аналогично ей есть ЭЦП,
  то есть электронная подпись, появляющаяся как результат применения ГОСТ-ключа.

• Есть паспорт, который подтверждает, кому принадлежит способность подписывать документы (ФИО, ИНН, СНИЛС).
  В электронном мире этому соответствует ГОСТ-сертификат, который связывает человека и его электронную подпись.

• У человека могут быть водительские права или специальные пропуска, дающие ему права в определённых областях.
  В электронном мире аналогом таких документов является RSA-сертификат — специальное удостоверение, используемое, например, в системе ЕГАИС.

• И у человека могут быть доверенности на выполнение действий от имени организации.
  В электронном мире этому полностью соответствует МЧД — машиночитаемая доверенность, которая также даёт право действовать от имени юридического лица.

Так же, как в обычной жизни у человека есть тело, рука, подпись, паспорт, права и доверенности, в электронной среде эти роли выполняют токен, ключ, ЭЦП, сертификаты и МЧД.

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

Теперь более формальные определения.

1. Физический носитель ключа (токен) для физического лица выдается в удостоверяющем центре (УЦ).

2. На токен УЦ генерирует или записывает ГОСТ-ключ (закрытый ключ + открытый ключ).

3. К этому ключу выпускается сертификат ЭЦП.

• ключ — это математика, число, используемое для подписи

• сертификат — это паспорт ключа, в котором УЦ подтверждает:
  «этот ключ принадлежит вот этому физлицу (ФИО, ИНН, СНИЛС)».

То есть сертификат описывает ключ и подтверждает его владельца.
Ключ ≠ сертификат. Ключ остаётся на токене, сертификат можно копировать.

4. Сертификат прикрепляется к идентификаторам физлица — ИНН, СНИЛС — в ФНС.

ФНС принимает от УЦ сведения:

• ФИО

• ИНН

• СНИЛС

• отпечаток сертификата

• дата действия

И помещает сертификат в свой реестр.

5. На токене также может быть RSA-сертификат — это отдельный сертификат.

• RSA-ключ создаётся не УЦ, а сервисом ЕГАИС/ФСРАР

• RSA-сертификат нужен только для ЕГАИС

• он используется как транспортный контейнер для ГОСТ-ключа

То есть RSA = отдельная сущность.
Он не влияет на МЧД, не связан с ФНС, нужен только для алкоголя/ЕГАИС.

МЧД все-таки  требуется на этапе генерации RSA. Для того, чтобы создать RSA, в УТМ нужно приложить файл МЧД

6. МЧД выдается прежде всего на ИНН/СНИЛС физлица и не прикрепляется напрямую к сертификату.

Но при первом использовании отпечаток сертификата фиксируется в ФНС.

• Выдаётся МЧД → в ней указано физлицо (ИНН, СНИЛС).

• При первом входе/подписи сервис фиксирует:
  «эта МЧД → использует сертификат с таким отпечатком».

• Это делается, чтобы никто другой не мог подписывать от имени этого человека.

7. Если тому же физлицу (ИНН/СНИЛС) выдан новый ГОСТ-сертификат, доверенности “перепривяжутся” к нему автоматически.

Да — ключевые сервисы (ФНС, ЧЗ, ГИС МТ, ЕГАИС) проверяют не отпечаток, а:

• совпадает ли ИНН/СНИЛС человека в сертификате

• есть ли у него действующая МЧД

Если совпадает — новая связка сертификата и МЧД автоматически считается корректной.

Пример рабочей ситуации

В ресторане Молоко перестала вставать бочка с пивом. Показывает следующую ошибку

Мы подключаемся на ПК с сервисом Rkdexch, видим там ключ Рутокен:

Открываем админку RKDexch. Видим ИНН с которым должен работать сертификат на ключе.

Заходим в ЛК ЧЗ

Нам не предлагается никакого выбора юр. лиц, после проверки сертификата, а мы сразу попадаем в ЛК.

Открываем профиль

И видим там не ООО Молоко, которое у нас должно быть с нашим ИНН, а ООО Луч с другим ИНН.

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

Но мы видим, что на ключе еще есть сертификат RSA для ЕГАИС, мы открываем WEB УТМ, и видим, что нет - там ООО Молоко.

Как это объяснить.

Ключ и сертификат принадлежат Пичугиной. Ей же была выдана МЧД от ООО Луч на право работы с ЧЗ. Плюс, ее же ГОСТ-сертификат используется как основа для RSA-сертификата ЕГАИС от ООО Молоко.

У Пичугиной может быть сколько угодно доверенностей МЧД от разных организаций. Все эти доверенности через ее ИНН\СНИЛС сопоставлены с ее ГОСТ-Сертификатом (его отпечатком). И если бы у нее было больше одной действующей доверенности, то при входе в ЛК ЧЗ был бы выбор - в ЛК какой организации она хочет войти, используя свой сертификат:

Таким образом, у Пичугиной (ИНН\СНИЛС) или вовсе не было доверенности на работу с ЧЗ от ООО Молоко, или она истекла. Поскольку до настоящего момента у клиента все работало, то скорее всего она истекла.

И мы можем это проверить. Снова открываем админку RKDexch и копируем уникальный номер МЧД. Заходим на сайт: https://m4d.nalog.gov.ru/emchd/check-status

Вставляем номер

Видим результат

Да, доверенность истекла. Поэтому rkdexch пытается работать с чужой МЧД, которая от Луча, что и приводит к исходной ошибке. Теперь можно точно сообщить клиенту, что МЧД на ООО Молоко истекла, и нужно ее перевыпустить. Клиент под сертификатом предприятия (не МЧД) должен зайти в ЛК ЧЗ (или в ФНС) и перевыпустить доверенность на Пичугину (ИНН\СНИЛС). При этом, ему не нужен отпечаток ее сертификата, он сам привяжется к новой доверенности при обработке первого запроса от имени Пичугиной.

Таблица: что к чему привязано