Просмотр актов с расширением .p7s

Подробное описание

Файл P7S — это сообщение электронной почты, содержащее электронную цифровую подпись (ЭЦП). Она используется для более безопасного обмена данными, удостоверяет личность отправителя и подтверждает, что в процессе передачи письмо не было изменено третьими лицами.

С файлом P7S обычно сталкиваются при просмотре входящего email. Если почтовая программа не поддерживает работу с ЭЦП, то письмо невозможно прочесть и в виде вложения отображается файл smime.p7s. В этом случае для просмотра письма следует использовать одну из почтовых программ, корректно обрабатывающих цифровые подписи, например, Microsoft Outlook или Mozilla Thunderbird.

Cms в реальной жизни

Стандарт CMS имеет немало воплощений в современном мире IT – на нем основаны:


Закономерным развитием идей CMS для сообщений с электронной подписью cтал CAdES (CMS Advanced Electronic Signature), расширенный стандарт подписанных сообщений CMS, который также послужит темой для еще одной нашей статьи.

Галопом по европам оставшимся типам

СMS предлагает еще несколько интересных типов сообщений, не охватываемых темой этой статьи. Поэтому буквально по паре слов об оставшихся типах для общей картины.

Упакованные данные (enveloped data) представляют собой зашифрованные данные вместе с зашифрованными для одного или более получателей ключами, которыми эти данные были зашифрованы. Комбинация зашифрованного сообщения с одним зашифрованным ключом шифрования для одного получателя называется цифровым конвертом. Данный тип используется в качестве конверта с (подписанными) данными для одного или нескольких получателей.

Хешированные данные (данные вместе со своим хешем) используются для проверки целостности сообщения и часто являются содержимым упакованных данных.


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

Данные из аутентифицированного источника (данные с проверкой подлинности) включают в себя данные вместе с их MAC-кодом и зашифрованными ключами аутентификации для одного или нескольких получателей. Используются для защиты целостности сообщений для неограниченного количества получателей.

В следующей статье мы подробно остановимся на сообщениях типа enveloped data с использованием российских криптоалгоритмов.

Для чего нужен cms

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

Читайте также:  Как получить усиленную квалифицированную электронную подпись

Некоторые из указанных атрибутов носят опциональный характер, но приложение может само определить необходимость их наличия. У каждого алгоритма есть набор параметров, который должен быть согласован на обеих сторонах: для ГОСТ 34.10-2001, помимо открытого ключа, это модуль

p

, коэффициенты эллиптической кривой

ab

и порядок циклической подгруппы точек эллиптической кривой

q

. И все это нужно каким-то образом передать адресату сообщения.

RSA Laboratories в серии своих стандартов криптографии с открытом ключом (PKCS) предложила решение этой проблемы путем определения синтаксиса для защищенных сообщений в следующих стандартах:

Развитием этих стандартов стал стандарт CMS. CMS кроме

определенной заголовком статьи

подписи поддерживает операции шифрования, хеширования и вычисления имитовставки, в том числе и по российским алгоритмам (

), а также множественную инкапсуляцию. Последнее означает, что сообщение формата CMS может лежать внутри другого CMS сообщения.

Всего CMS поддерживает шесть типов данных:

  • просто данные (data),
  • данные с электронной подписью (signed data),
  • упакованные данные (enveloped data),
  • хешированные данные (digested data),
  • зашифрованные данные (encrypted data),
  • данные с проверкой подлинности (authenticated data).

В рамках статьи мы подробно рассмотрим только данные с электронной подписью (signed data).

Чтобы не путаться в терминологии, далее исходные данные, которые мы хотим передать защищенным способом, будут называться данными, а получившееся защищенное сообщение CMS – просто сообщением.

Как реализовать на практике?


Стандарт CMS/PKCS#7 с поддержкой российских криптоалгоритмов реализован в сертифицированных СКЗИ наших партнеров:

Кроме того, стандарт CMS с российской криптографией реализован в Open Source приложении OpenSSL.

Наша компания поддержала CMS c российской криптографией в продукте Рутокен Плагин. Рутокен Плагин предназначен для использования в браузерах, все криптографические операции производятся аппаратно, «на борту» USB-токена.

Подпись в cms-формате (signed data type)


Подпись, описанная стандартом CMS, характеризуется следующими особенностями:

  1. Данные могут быть подписаны несколькими сторонами (множественная подпись). В таком случае в сообщении будут присутствовать несколько структур SignerInfo с информацией о подписывающих сторонах: значением подписи и необходимой для проверки ее подлинности информацией.
  2. Тип данных никак не регламентируется, лишь уточняется, что в качестве данных может быть сообщение формата CMS, то есть подписанное Алисой сообщение может быть целиком подписано Бобом.
  3. Подписывать можно не только данные, но и некоторые атрибуты сообщения – хеш сообщения (digest message), время подписи (signing time), значение другой подписи (countersignature).
  4. Открытый ключ подписывающей стороны может быть несертифицированным.
  5. Подпись может отсутствовать и вовсе.
Читайте также:  Настройка подписи в Outlook 2010

Данные с электронной подписью используются не только для подписи содержимого и часто используются для распространения сертификатов и списков отзыва сертификатов (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.

Если Боб решит подписать только данные, переданные Алисой, и заодно подписать подпись Алисы, то сообщение будет иметь такой вид:

Просмотр актов с расширением .p7s

  1. Для сохранения и расшифровки документов необходимо выполнить следующие действия:
  2. Сохраните программу VerifyDocSign.exe (нажмите здесь, чтобы скачать) для расшифровки актов
  3. Зайдите в личный кабинет на сайте https://torgi.center-inform.ru/
  4. Выберите заказ, документы из которого вы хотите открытьПросмотр актов с расширением .p7s
  5. Перейдите в раздел Заказанные услуги и сохраните счета и документы для получения услуги.
    Просмотр актов с расширением .p7s
  6. В выбранном заказе сохраните акт с расширением .p7s, нажав на него
  7. Запустите сохраненную программу VerifyDocSign.exe, нажмите Проверить подписи и выберите сохраненный файл акта с расширением  .p7s
    Просмотр актов с расширением .p7s
  8. После того, как подписи были проверены, нажмите Сохранить документ, чтобы открыть акт
    Просмотр актов с расширением .p7s
  9. Откроется окно Сохранить как, введите имя документа и нажмите Сохранить
    Просмотр актов с расширением .p7s
  10. После того, как акт был сохранен, вы можете ознакомиться с его содержимым и распечатать

Документы успешно расшифрованы.

Чуть истории

Синтаксис криптографических сообщений (CMS) впервые был определен в

, который позже был опубликован в качестве рекомендаций

. Спустя еще несколько версий RFC в сентябре 2009 года был принят

, который является действующим стандартом на данный момент.


Под спойлером иллюстрируется тяжелая судьба стандарта.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector