Найдены несоответствия эцп digest в signerinfo не совпадает с digest данных

Обновлено: 07.07.2024

Некоторые исследования цифровой подписи PE-файлов на платформе Windows

Цифровая подпись PE-файла на платформе Windows выполняет две функции: гарантировать, что файл исходит от назначенного издателя и что файл не был изменен после подписания. Поэтому некоторые программы используют цифровые подписи, чтобы проверить, принадлежит ли файл производителю, и проверить целостность файла.Программное обеспечение безопасности часто проверяет наличие цифровой подписи у файла для предотвращения ложных срабатываний. Однако из-за проблем с реализацией широко используемого API-интерфейса проверки цифровой подписи WinVerifyTrust и некоторых неподходящих примеров кодов во многих местах возникают проблемы с медленными картами или низким уровнем безопасности при проверке цифровых подписей. В этой статье будут представлены общие методы использования цифровых подписей, общие коды проверки, принципы проверки и проблемы, возникающие во время использования, а также предложен более безопасный и быстрый метод проверки в определенных сценариях, а также Прочие мелочи. Некоторые детали не совсем понятны. Я предполагаю, что есть некоторые ошибки. Если вы обнаружите их, укажите на них, но слегка при распылении.

1.1 Создать сертификат

Обычно мы используем сертификат, выданный центром сертификации, при подписании файлов PE, но мы также можем использовать инструмент создания сертификатов Microsoft makecert для создания тестовых сертификатов при тестировании самих себя. Первая строка следующей команды становится самозаверяющим корневым сертификатом, а затем использует корневой сертификат для подписи суб-сертификата.

Конечно, этому типу сертификата система не доверяет, и вам необходимо вручную импортировать сгенерированный сертификат в систему.

1.2 Встроенная подпись

Используйте инструмент Microsoft signtool для встраивания подписи файлов PE и запустите signtool signwizard, чтобы открыть графический интерфейс для подписи в стиле мастера.

Изображение эффекта после подписания:

1.3 Подпись в каталоге

Подпись каталога предназначена для помещения данных подписи в файл каталога с суффиксом .cat, а не встроенным в PE-файл, поэтому вы не можете увидеть метку цифровой подписи, щелкнув правой кнопкой мыши свойства файла. Этот метод подписи может подписывать файлы любого формата, не ограничиваясь файлами PE. Системные файлы Microsoft в основном подписываются таким образом, поэтому некоторые люди называют это подписью каталога Microsoft.На самом деле, этот метод доступен не только Microsoft.

①, создайте cdf файл, в качестве примера возьмем подпись 7zFM.exe:

[CatalogHeader]Name=softsigntest.cat[CatalogFiles]<hash>7zFM=7zFM.exe

②, сгенерируйте файл cat из файла cdf, созданного на предыдущем шаге

③, запустите signtool signwizard, чтобы подписать softsigntest.cat.

④, если вы проверяете подпись PE файла, он не может пройти проверку, вам необходимо импортировать файл cat в систему.

Нет проблем с базовым процессом создания кода в Интернете. Многие студенты могут также скопировать код подписи для самостоятельного использования. Но здесь также есть несколько мелких проблем:

①, если вы просто хотите проверить встроенную подпись, для неподписанного или подписанного невстроенного файла, чтение всего файла и вычисление HASH будут выполнены напрасно. Нет проблем с базовым процессом создания кода в Интернете. Многие студенты также могут скопировать код подписи для самостоятельного использования. Но есть и несколько мелких проблем:

②Существует особый случай: после того, как файл встроен и подписан, его все еще можно каталогизировать и подписать. Если подпись каталога недействительна, а встроенная подпись действительна, здесь будет возвращена ошибка проверки. Конечно, по оценкам, у большинства людей не будет проблем, и они не подпишут документ двумя способами.

③Похоже, здесь есть опечатка. Назначение WINTRUST_DATA :: fdwRevocationChecks отличается в ветви подписи каталога и встроенной подписи, а WTD_STATEACTION_VERIFY - это значение перечисления, заполненное для dwStateAction.Хотя значение то же самое, это не подходит. Учащиеся, которые видят здесь, могут увидеть, скопирован ли их проверочный код отсюда и является ли он неправильным.

3.1 Встроенная подпись

После извлечения подписи проверка цифровой подписи примерно делится на следующие этапы. Сначала извлеките цифровую подпись из PE-файла, затем проверьте подпись самого файла, затем проверьте цепочку сертификатов до корневого сертификата и, наконец, сравните, соответствует ли сводка файла То же, что и в цифровой подписи. Следующее описание предназначено только для проверки цифровой подписи файлов PE. Во-первых, изображение в предыдущем документе Microsoft примерно иллюстрирует расположение цифровой подписи в PE-файле и его формат:

①, выньте цифровую подпись

Таблица сертификатов в каталогах данных заголовка PE указывает место хранения и размер WIN_CERTIFICATE, а bCertificate WIN_CERTIFICATE является подписью в формате SignedData.

②, проверьте подпись самого файла

Сама подпись файла соответствует формату SignedData в стандарте PKCS7, а формат, выраженный в ASN1, выглядит следующим образом:

Структура SignerInfos выглядит следующим образом:

AuthenticatedAttributes содержит contentType и messageDigest, а messageDigest - это сводка ContentInfo SignedData. Дайджест AuthenticatedAttributes, чтобы получить структурированные данные DigestInfo. Структура DigestInfo следующая:

Используйте IssuerAndSerialNumber, чтобы найти сертификат подписывающей стороны, используйте открытый ключ внутри, чтобы расшифровать EncryptedDigest, чтобы получить структуру DigestInfo (обычно алгоритм RSA), сравните эту структуру со структурой, полученной путем переваривания AuthenticatedAttributes, и перейдите к следующему шагу, если они согласованы.

③, проверьте цепочку сертификатов

Соответствующая структура выглядит следующим образом:

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

Когда цепочка сертификатов сформирована, keyIdentifier, AuthorityCertIssuer, AuthorCertSerialNumber AuthorityKeyIdentifier (AKID для краткости) сертификата A будут сопоставлены с SubjectKeyIdentifier (SKID для краткости), эмитентом и серийным номером сертификата B. Если они совпадают, сертификат B является выдачей сертификата B. По. Если указанные выше три элемента сертификата A соответствуют своим соответствующим данным, сертификат A является самоподписанным сертификатом, и цепочка сертификатов создается.

4.1 Карта WinVerifyTrust API медленная

WinVerifyTrust, здесь много проблем. Известно, что проблемы могут быть в следующих местах.

① Производительность API серии WinINet, используемого при проверке CRL (списка отмены сертификатов), невысока. API этой серии является общеизвестно нестабильным, и говорят, что он может вызвать повреждение кучи. На практике мы также обнаружили, что он вызывает зависание, но мы не можем найти DUMP, └ (T_T;) ┘.

② Зависание при перечислении сертификата. Это ДАМП, который у нас есть. Он застрял здесь почти на 10 минут.

③Если мы проверяем подпись каталога, мы обнаружили, что межпроцессное взаимодействие застряло. В стеке вызовов мы видим, что несколько потоков имеют RPC на вершине стека потока, который проверяет подпись.

④, бесконечный цикл при перечислении подписи. Говорят, что WinVerfiyTrust не оценивает длину подписи при проверке встроенной подписи PE-файла в системе XP. Если PE-файл поврежден и длина подписи равна 0, WinVerfiyTrust попадет в бесконечный цикл.

4.2 Безопасность

4.2.1 Вредоносное ПО может импортировать сертификаты в систему

Вредоносная программа может импортировать корневой сертификат через CertAddCertificateContextToStore после запуска.Хотя система Windows выдает всплывающее окно с предупреждением, она может имитировать щелчок мышью для подтверждения окна предупреждения.

Ниже приведен рендеринг:

4.2.2 Сертификаты, выданные без разбора

Общие центры сертификации имеют базовые концепции безопасности и более осторожны при выдаче сертификатов. Однако некоторые производители, у которых есть средства для вставки корневого сертификата в компьютер пользователя, не проявляют осторожности при выдаче сертификата.Например, использование сертификата в USB-Shield интернет-банка ICBC не ограничено, и файлы PE могут быть подписаны. Смотри ниже

Alipay также ранее взламывала эту уязвимость, и теперь она исправлена.Следующий скриншот из темного облака.

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

Вышеупомянутое множество проблем при реальном использовании проверки цифровой подписи. Итак, если вы хотите быстро проверить подпись и обеспечить безопасность, то что делать? Поднятые проблемы в основном сводятся к двум пунктам: одна - проблема медленной карты WinVerfiyTrust, а другая - проблема злоупотребления сертификатом или загрязнения среды пользователя. Затем, если вы хотите это сделать, вы можете написать код для проверки подписи и принести список доверенных корневых сертификатов. После прохождения проверки информация обо всех сертификатах во всей цепочке сертификатов отправляется на серверную часть для проверки сертификата через собственный протокол CS. Достоверно ли это, чтобы мы также могли уничтожить сертификаты в списке отзыва через фон.

Только для проверки подписи файлов PE необходимо написать много кода, включая анализ данных формата кодирования ASN1 данных подписи, проверку подписи и проверку цепочки сертификатов, но этот вид общего кода можно получить из библиотеки с открытым исходным кодом. Ищите OpenSSL, например, ниже приведен фрагмент кода, скопированный по частям, который может проверять цифровую подпись PE-файлов, но этот код очень грубый, некоторые части не полностью поняты, а большая часть обработки ошибок удалена, чтобы сократить длину. Осторожно распылите, просто чтобы проверить, может ли эта дорога пройти.

Кроме того, я также просто написал небольшую демонстрацию для проверки цифровой подписи. Процесс написания кода очень сложен. Эффект демонстрации показан на рисунке:

Если вы работаете на сайте ФНС с одного ПК с несколькими учётными записями (сертификатами), при каждой смене учётной записи необходимо чистить SSL (Сервис — Свойства браузера — Содержание — Очистить SSL).

1. Пройдите диагностику и выполните рекомендуемые действия.

2. Если электронная подпись установлена на носитель Рутокен ЭЦП 2.0, воспользуйтесь инструкцией и установите Рутокен.Коннект (см. Поддерживаемые браузеры).

4. Проверьте работу в браузерах:

— Спутник
Примечание: после запуска скачанного установочного файла перейдите в раздел «Настройки» и уберите галку с пункта «Установить КриптоПро CSP для поддержки защищенных каналов на основе ГОСТ шифрования и цифровой подписи».

— Яндекс.Браузер
После установки браузера зайдите в его настройки и включите поддержку ГОСТ-шифрования («Настройки» — «Системные» — «Сеть»):

6. Запустите программу КриптоПро CSP с правами администратора. Перейдите на вкладку «Настройки TLS» и снимите галочку «Не использовать устаревшие cipher suite-ы». После изменения данной настройки нужно обязательно перезагрузить компьютер.

7. После перезагрузки компьютера поставьте галочку «Не использовать устаревшие cipher suite-ы» в настройках КриптоПро CSP на вкладке «Настройки TLS», не соглашайтесь с предложением о перезагрузке.

9. Если на компьютере установлены другие СКЗИ (VipNet CSP, Континент-АП, Агава и др.), удалите их или перейдите на другое рабочее место. Корректная работа с несколькими криптопровайдерами на одном ПК не гарантируется.

При работе в ЛК физического лица появляется окно (не окно КриптоПро) с требованием ввести пароль, но при этом пароля на контейнере нет или стандартный пин-код от токена не подходит.

1. Войдите в Личный кабинет Физического лица.

2. Откройте страницу «Главная» — «Профиль» — «Получить электронную подпись».

3. Если на открывшейся странице выбрана ЭП — удалите подпись и зарегистрируйте КЭП заново.

При регистрации Юридического лица появляется ошибка «У Вас отсутствуют полномочия действовать от лица организации без доверенности».

Для управляющей компании КЭП должен содержать ФИО руководителя управляющей компании и реквизиты (ИНН, ОГРН) той организации, управление которой осуществляется. Также перед первым входом по сертификату дочерней организации требуется зарегистрировать в ФНС доверенность на руководителя УК.

По вопросам работы на портале и ошибкам, не связанным с настройкой рабочего места и электронной подписью, обратитесь в службу поддержки портала ФНС:
— Телефон: 8 (800) 222-22-22
— Форма обращения в техподдержку ФНС

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

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

Чуть истории

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

• Версия синтаксиса 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.

  
  

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

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

  • стандарт защищенной электронной почты S/MIME (RFC 3851),
  • расширенные сервисы защиты для S/MIME (RFC 2634, кстати, тут описаны дополнительные атрибуты CMS и технология тройного «обертывания» на основе множественной инкапсуляции: данные подписываются, затем шифруются и снова подписываются),
  • расширенные форматы представления информации об аннулированных сертификатах (RFC 5940) и пр.

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

  компании Крипто-Про компании Инфотекс или Message-PRO компании СигналКом и др.

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

  Неожиданные значения диапазона байтов, определяющие объем подписанных данных

  Есть идеи, в чем может быть проблема?

  1 ответ

  Первый пример документа

  Второй пример документа

  второй пример документа был опубликован в комментарии:

  «Документ был изменен или поврежден с тех пор, как была применена подпись». - здесь указывается на несоответствие дайджеста.

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

  Так что ваша подпись действительно не соответствует подписанным диапазонам байтов.

  Интересно, однако, что это точно такой же дайджест, который был подписан в контейнере подписи в первом файле. Фактически весь контейнер подписи идентичен. По-видимому, вы просто повторно использовали контейнер подписи, который вы получили в предыдущем тесте. Поскольку время подписи в новом документе отличается, это не может работать, однако вам необходимо заново вычислить дайджест подписанных диапазонов байтов и запросить для него подпись.

  При этом даже для вашего первого документа этот дайджест неверен. Итак, у вас, по-видимому, есть проблема с вычислением значений дайджеста.

  «Подпись включает встроенную метку времени, но ее не удалось проверить». Я тоже это понял, но здесь мне снова просто нужно было доверять корневому сертификату сертификата TSA, чтобы начать работу.

  Комментарии

  В комментариях вы спрашиваете:

  Если вы хотите понять детали того, что вы видите, вам следует изучить RFC 5652 и спецификации, на которые ссылаются оттуда.

  И как я могу явно доверять корневому сертификату?

  Для сертификата подписавшего в Foxit Reader откройте диалоговое окно Свойства подписи , выберите Показать сертификат , выберите сертификат, которому вы хотите доверять (корневой ЦС / промежуточный ЦС / конечный объект), откройте откройте вкладку Trust и нажмите Добавить в доверенные сертификаты .

  Для сертификата TSA в Foxit Reader откройте диалоговое окно Signature Properties , внизу нажмите Advanced Properties , выберите Show Certificate в Timestamp Details, выберите сертификат, которому вы хотите доверять (корневой ЦС / промежуточный ЦС / конечный объект), откройте вкладку Trust и нажмите Добавить в доверенные сертификаты .

  Читайте также:

    
  • Kaspersky типы проверяемых файлов
    
  • Как подтвердить права через dns
    
  • Файл ресурса поврежден или версии не совпадают pubg
    
  • Как правильно вставлять лист в файл
    
  • Можно ли вместо qr кода предъявить бумажный сертификат