Криптографическое сообщение — это электронная подпись или зашифрованные данные, которые используются в СБИС.
Все криптографические сообщения на online.sbis.ru представляют собой двоичные данные в формате CMS/PKCS#7. Этот формат поддерживает российские криптоалгоритмы и используется в СКЗИ, которые сертифицированы ФСБ.
Область применения электронной подписи (ЭП или ЭЦП) довольно широка. Например, многие специальные сервисы требуют верификации пользователя с её помощью: Госуслуги, онлайн-сервисы для управления средствами в банке, электронные площадки и другие. Поэтому любые технические неполадки, возникающие при использовании ЭЦП, могут вызвать различные серьёзные: от упущенной выгоды до материальных убытков.
При возникновении любых ошибок при подписании и расшифровке, воспользуйтесь следующими инструкциями (рекомендуется выполнять по порядку):
1. Проверьте срок действия сертификата;
2. Проверьте систему на наличие двух СКЗИ;
3. Проверьте совместимость СКЗИ:
4. Проверьте зарегистрирован ли СКЗИ. Если нет — произведите регистрацию:
5. Повторно установите сертификат из контейнера:
6. Очистите кэш учетной записи документооборота;
7. Выдайте права на папки с 1С, СКЗИ и контейнером;
8. Отключите контроль учетных записей (UAC);
9. Выдайте права пользователю 1С через конфигуратор;
10. Переустановите СКЗИ с чисткой реестра и обязательной перезагрузкой ПК:
- Удаление и Установка СКЗИ ViPNet CSP;
- Удаление и Установка СКЗИ КриптоПро CSP.
11. Проверьте разрядность платформы 1С. Рекомендуется использовать платформу разрядности x32. Проверить можно так: платформы разрядности x64 обычно установлены в каталог Program Files, а не в Program Files (x86), а также отображаются на вкладке Процессы Диспетчера задач без пометки *32
Статья посвящена обзору стандартов СMS (Cryptographic Message Syntax) для подписанных сообщений.
Для чего нужен CMS
Стандарт CMS описывает структуру криптографических сообщений, включающих в себя защищенные данные вместе со сведениями, необходимыми для их корректного открытия или использования. Например, в сообщении размещаются защищенные данные, информация об алгоритме хеширования и подписи, времени подписи, сертификате открытого ключа, цепочке сертификации и т.д. Некоторые из указанных атрибутов носят опциональный характер, но приложение может само определить необходимость их наличия. У каждого алгоритма есть набор параметров, который должен быть согласован на обеих сторонах: для ГОСТ 34.10-2001, помимо открытого ключа, это модуль p, коэффициенты эллиптической кривой a и b и порядок циклической подгруппы точек эллиптической кривой q. И все это нужно каким-то образом передать адресату сообщения.
RSA Laboratories в серии своих стандартов криптографии с открытом ключом (PKCS) предложила решение этой проблемы путем определения синтаксиса для защищенных сообщений в следующих стандартах:
● PKCS #7 «Cryptographic Message Syntax Standard»;
● PKCS #10 «Certificate Request Syntax Standard».
Развитием этих стандартов стал стандарт CMS. CMS кроме определенной заголовком статьи подписи поддерживает операции шифрования, хеширования и вычисления имитовставки, в том числе и по российским алгоритмам (RFC 4490), а также множественную инкапсуляцию. Последнее означает, что сообщение формата CMS может лежать внутри другого CMS сообщения.
Всего CMS поддерживает шесть типов данных:
● просто данные (data);
● данные с электронной подписью (signed data);
● упакованные данные (enveloped data);
● хешированные данные (digested data);
● зашифрованные данные (encrypted data);
● данные с проверкой подлинности (authenticated data).
В рамках статьи мы подробно рассмотрим только данные с электронной подписью (signed data).
Чтобы не путаться в терминологии, далее исходные данные, которые мы хотим передать защищенным способом, будут называться данными, а получившееся защищенное сообщение CMS – просто сообщением.
Стандарт CMS (PKCS #7 и RFC 5652)
Синтаксис криптографических сообщений (CMS) впервые был определен в PKCS #7, который позже был опубликован в качестве рекомендаций RFC 2315 «PKCS #7: Cryptographic Message Syntax Version 1.5». Спустя еще несколько версий RFC в сентябре 2009 года был принят RFC 5652 «Cryptographic Message Syntax (CMS)», который является действующим стандартом на данный момент.
Рис. Эволюция PKCS#7/CMS
Подпись в CMS-формате (signed data type)
Подпись, описанная стандартом CMS, характеризуется следующими особенностями:
1. Данные могут быть подписаны несколькими сторонами (множественная подпись). В таком случае в сообщении будут присутствовать несколько структур SignerInfo с информацией о подписывающих сторонах: значением подписи и необходимой для проверки ее подлинности информацией.
2. Тип данных никак не регламентируется, лишь уточняется, что в качестве данных может быть сообщение формата CMS, то есть подписанное Алисой сообщение может быть целиком подписано Бобом.
3. Подписывать можно не только данные, но и некоторые атрибуты сообщения – хеш сообщения (digest message), время подписи (signing time), значение другой подписи (countersignature).
4. Открытый ключ подписывающей стороны может быть несертифицированным.
5. Подпись может отсутствовать и вовсе.
Данные с электронной подписью используются не только для подписи содержимого и часто используются для распространения сертификатов и списков отзыва сертификатов (Certification Revocation List, CRL). В таком случае подписываемые данные отсутствуют, а поля Certificates и CRLs, наоборот, присутствуют.
Подписанное Алисой сообщение в формате CMS будет иметь следующий вид (серым отмечены необязательные атрибуты):
● версия синтаксиса CMS Version зависит от сертификатов, типа подписываемых данных и информации о подписывающих сторонах;
● Digest Algorithms включает в себя идентификаторы используемых алгоритмов хеширования и ассоциированные с ними параметры;
● Encapsulated Content содержит подписываемые данные (Content) вместе с их типом (Content Type). Содержимое может отсутствовать, тип – нет;
● Certificates предназначен для цепочки сертификатов, отражающих путь сертификации от центра сертификации, выдавшего сертификат, до каждой из подписывающих сторон. Также могут присутствовать сертификаты подписывающих сторон;
● CRLs (Certificate Revocation List) предоставляет информацию о статусе отзыва сертификатов, достаточную для определения валидности сертификата подписывающей стороны;
● информация о каждой подписывающей стороне содержится в структурах типа Signer Info, которых может быть любое количество, в том числе и нулевое (в случае отсутствия подписи);
● версия синтаксиса CMS Version определяется значением Signer ID;
● Signer ID определяет открытый ключ подписывающей стороны (subjectKeyIdentifier) или сертификат его открытого ключа, необходимый для проверки подлинности подписи (issuerAndSerialNumber);
● Digest Algorithm определяет алгоритм хеширования и все ассоциированные с ним параметры, используемые подписывающей стороной;
● в Signed Attributes помещаются атрибуты, требующие подписи. Поле может отсутствовать только при подписи простых данных (Content Type = id-data), при подписи других данных (например, Content Type = id-SignedData) должно присутствовать с как минимум двумя обязательными атрибутами – типом (Content Type) и хешем данных (Message Digest);
● Signature Algorithm содержит идентификатор алгоритма подписи вместе с его параметрами;
● в Signature Value помещается значение подписанного закрытым ключом хеша от данных (Content) и атрибутов для подписи (Signed Attributes);
● в Unsigned Attributes помещаются оставшиеся атрибуты, не требующие подписи.
Если Боб решает целиком подписать полученное от Алисы сообщение, то используется механизм инкапсуляции, и сообщение будет выглядеть вот так:
CMS предлагает два интересных атрибута, расширяющих возможности обычной подписи: время подписи (Signing Time) и контрасигнатуру (Countersignature). Первый атрибут определяет предполагаемое время осуществления подписи, а второй предназначен для подписи другой подписи (подписывается хеш от значения подписи). Атрибут Countersignature представляет собой структуру Signer Info с отсутствующим в Signed Attributes атрибутом Content Type и обязательно присутствующим атрибутом Message Digest. Атрибут Countersignature может иметь свой собственный атрибут Countersignature.
Если Боб решит подписать только данные, переданные Алисой, и заодно подписать подпись Алисы, то сообщение будет иметь такой вид:
Галопом по Европам оставшимся типам
СMS предлагает еще несколько интересных типов сообщений, не охватываемых темой этой статьи. Поэтому буквально по паре слов об оставшихся типах для общей картины.
Упакованные данные (enveloped data) представляют собой зашифрованные данные вместе с зашифрованными для одного или более получателей ключами, которыми эти данные были зашифрованы. Комбинация зашифрованного сообщения с одним зашифрованным ключом шифрования для одного получателя называется цифровым конвертом. Данный тип используется в качестве конверта с (подписанными) данными для одного или нескольких получателей.
Хешированные данные (данные вместе со своим хешем) используются для проверки целостности сообщения и часто являются содержимым упакованных данных.
Зашифрованные данные часто используются для шифрования данных для локального хранилища, иногда с выработанным из пароля ключом шифрования.
Данные из аутентифицированного источника (данные с проверкой подлинности) включают в себя данные вместе с их MAC-кодом и зашифрованными ключами аутентификации для одного или нескольких получателей. Используются для защиты целостности сообщений для неограниченного количества получателей.
В следующей статье мы подробно остановимся на сообщениях типа enveloped data с использованием российских криптоалгоритмов.
CMS в реальной жизни
Стандарт CMS имеет немало воплощений в современном мире IT – на нем основаны:
● стандарт защищенной электронной почты S/MIME (RFC 3851),
● расширенные сервисы защиты для S/MIME (RFC 2634, кстати, тут описаны дополнительные атрибуты CMS и технология тройного «обертывания» на основе множественной инкапсуляции: данные подписываются, затем шифруются и снова подписываются),
● расширенные форматы представления информации об аннулированных сертификатах (RFC 5940) и пр.
Закономерным развитием идей CMS для сообщений с электронной подписью cтал CAdES (CMS Advanced Electronic Signature), расширенный стандарт подписанных сообщений CMS, который также послужит темой для еще одной нашей статьи.
Как реализовать на практике?
Предложения и варианты практических решений ищите в полном тексте статьи.
Спасибо за предоставленный материал Компании «Актив».
ЭП не подписывает документ
Причин у подобной проблемы множество. Каждый случай требует отдельной проверки. Среди самых распространённых можно выделить следующие неполадки:
- Закрытый ключ на используемом контейнере не соответствует открытому ключу сертификата. Возможно, был выбран не тот контейнер, поэтому следует проверить все закрытые контейнеры на компьютере. Если необходимый контейнер по тем или иным причинам отсутствует, владельцу придётся обращаться в удостоверяющий центр для перевыпуска ЭП.
- Ошибка «Сертификат недействителен» (certificate is not valid). Следует повторно установить сертификат ЭП по инструкциям УЦ в зависимости от используемого криптопровайдера — КриптоПро CSP, ViPNet CSP или другого.
- Сертификат ЭП определяется как непроверенный. В этом случае необходимо переустановить корневой сертификат удостоверяющего центра.
- Истёк срок действия криптопровайдера. Для решения этой проблемы необходим новый лицензионный ключ к программе-криптопровайдеру. Для его получения необходимо обращаться к специалистам УЦ или к ответственным сотрудникам своей организации.
- Подключён носитель с другим сертификатом. Убедитесь, что подключён правильный токен. Проверьте также, не подключены ли носители других сертификатов. Отключите другие носители в случае их обнаружения.
В момент подписания электронных документов или формирования запроса в различных может возникнуть ошибка «Невозможно создание объекта сервером программирования объектов».
В этой ситуации помогает установка и регистрация библиотеки Capicom:
Как шифруются данные в криптографическом сообщении
Зашифрованные данные передаются в виде структуры «enveloped data». Данные шифруются при помощи симметричного алгоритма ГОСТ 28147-89 на сгенерированном сессионном ключе. Зашифрованный сессионный ключ содержится в криптографическом сообщении.
Вычисление криптографического хеша
Подписанные данные представлены в системе как структура «signed data». Алгоритм подписи — ГОСТ Р 34.11/ 34.10-2012. Подпись — вычисляется по формату электронной подписи CAdES-T. Хеш от подписываемых данных и тип данных — одни из обязательных атрибутов. Чтобы проверить подпись, СБИС сравнивает хеш от криптографического сообщения и расшифрованные данные подписи открытым ключом из сертификата подписанта. Алгоритм вычисления хеша — ГОСТ Р 34.11-2012.
Часто задаваемые вопросы
Почему компьютер не видит ЭЦП?
Причина кроется в несовместимости программного обеспечения и физического носителя ЭЦП. Необходимо проверить версию операционной системы и переустановить её до нужной версии. Если токен повреждён, возможно, понадобится обратиться в удостоверяющий центр для перевыпуска электронной подписи.
О том, что делать, если компьютер не видит ЭЦП и о способах проверки настроек, мы подробно писали в нашей статье.
Почему КриптоПро не отображает ЭЦП?
Если КриптоПро не отображает ЭЦП, следует проверить настройки браузера. Также исправляет ошибку добавление программы в веб-обозреватель и загрузка недостающих сертификатов электронной подписи.
Подробнее ознакомиться, как устранить данную неисправность можно в нашей статье.
Где на компьютере искать сертификаты ЭЦП?
Сертификат ЭЦП позволяет проверить подлинность подписи, содержит в себе срок её действия и информацию о владельце. Он автоматически загружается в папку с системными файлами. В операционной системе Windows от 7 версии и выше ЭЦП хранится по адресу:
Что такое сертификат ЭЦП и зачем он нужен мы рассказали в нашей статье.
Какие бывают ошибки
Проблемы при использовании ЭП, с которыми пользователи встречаются чаще всего, можно условно разделить на три группы:
- Проблемы с сертификатом. Они появляются, когда сертификат не выбран, не найден или не верен.
- Проблемы с подписанием документа. Ошибки возникают при попытке подписать документ.
- Проблема при авторизации на торговых площадках.
Рассмотрим неполадки подробнее и разберёмся, как их решать.
Сертификат не найден
Иногда при попытке подписать электронный документ с помощью ЭП пользователь может столкнуться с ошибкой «Не удалось найти ни одного сертификата, пригодного для создания подписи».
У подобных ошибок могут быть следующие причины:
- На компьютере не установлены корневые сертификаты Удостоверяющего Центра (УЦ), в котором была получена ЭП. Необходимо установить либо обновить корневой сертификат. Установка корневых сертификатов удостоверяющего центра подробно описана в нашей инструкции.
- На ПК не установлено ни одного личного сертификата ЭП. Для применения ЭП необходимы и личные сертификаты. Об их установке мы писали в другой статье.
- Установленные на компьютере необходимые сертификаты не валидны. Сертификаты отозваны или просрочены. Уточните статус сертификата в УЦ. Ошибка с текстом «Ваш сертификат ключа подписи включён в список отозванных» возникает, если у сертификата закончился срок действия или на ПК нужно обновить список сертификатов. В последней ситуации следует вручную загрузить перечень отозванных сертификатов.
Для установки списка отозванных сертификатов:
Нормативные документы
Нашли неточность? Выделите текст с ошибкой и нажмите ctrl + enter.
Требования к сертификату
Помимо проверки математической корректности подписи в online.sbis.ru также проверяется валидность сертификата подписи. Сертификат должен удовлетворять требованиям, а также быть действительным и квалифицированным для ряда регламентов документооборота. Это означает, что в сертификате должны быть определенные комбинации реквизитов и расширений. Подробная информация о расширениях сертификата описана в стандарте RFC5280.
Штамп времени
Как правило, причина такой проблемы — сбой в работе программных компонентов. Для её решения достаточно перезагрузить компьютер. Однако иногда этого бывает недостаточно, поэтому требуется переустановка драйверов или обращение в службу техподдержки.
К наиболее распространённым причинам такой проблемы относятся следующие случаи:
- Долгое опознание носителя. Для решения проблемы необходимо дождаться завершения процесса или обновить версию операционной системы.
- Некорректная работа USB-порта. Подключите токен к другому USB-порту, чтобы убедиться, что проблема не в носителе ЭП. Если система определила токен, перезагрузите компьютер. Если это не поможет, следует обратиться службу технической поддержки.
- Неисправность носителя. Если при подключении токена к другому компьютеру или USB-порту система не определяет его, значит, проблема в самом носителе. Устранение неисправности возможно в данном случае лишь одним путём — нужно обратиться в сервисный центр для выпуска нового носителя.
Выбранная подпись не авторизована
Подобная ошибка возникает при попытке авторизации в личном кабинете на электронных торговых площадках. Например, при входе на площадку ZakazRF отображается сообщение «Выбранная ЭЦП не авторизована».
Эта ошибка возникает из-за того, что пользователь не зарегистрирован на площадке, либо не зарегистрирован новый сертификат ключа ЭП. Решением проблемы будет регистрация нового сертификата.
Процесс запроса на авторизацию ЭП на разных торговых площадках может отличаться: часто нужно отправлять запрос оператору системы на авторизацию, иногда рабочее место настраивается автоматически.
Если ошибка сохраняется, возможно, следует отключить защитное ПО или добавить сайт электронной площадки в исключения.