Отметка времени не прошла проверку электронной подписи

Обновлено: 21.11.2024

У меня есть установочный пакет WiX/Burn, который, среди прочего, устанавливает среду выполнения ReportViewer 2012. При запуске на компьютере с Windows 7 или более поздней версии он работает нормально. В XP (SP3) или Vista (SP1) это не удается.

Теперь, проверяя страницу загрузки распространяемого пакета ReportViewer, я заметил, что он требует Vista SP2 или более поздней версии. Обычно я бы согласился с этим, но а) я думаю, что это недавно изменилось, и б) загрузка и ручная установка этого распространяемого пакета работает. Возможно, есть части, которые не работают на XP/Vista, но для моих целей и задач установка и запуск выполняются достаточно хорошо, несмотря на их заявления.

Проблема

Изучение файла журнала установки показывает, что проверка цифровой подписи не удалась. Поэтому я вручную загружаю распространяемый пакет на компьютер с Windows XP и проверяю его подпись. Подпись есть, но временная метка сообщает «Недоступно». Нажатие «Подробности» также сообщает мне, что время подписания «Недоступно». Сам файл подписан сертификатом с истекшим сроком действия, поэтому без этой временной метки проверка, естественно, не пройдет.

Однако, если я загружаю тот же файл на компьютер с Windows 7, метка времени сохраняется. Нажав на кнопку «Подробности», я узнаю о подписи, проверке и установке.

Что я пробовал

Я установил несколько разных версий "Обновления для корневых сертификатов" безрезультатно, включая последнюю. Если это действительно решение, скажите, какое мне нужно.

Я проследил цепочку сертификатов в контрподписи, и она заканчивается на "Корневой центр сертификации Microsoft 2010". Этот корневой сертификат, по-видимому, установлен на компьютере с XP. Единственное, что я вижу, это версия этого сертификата "2011" также в хранилище "Сторонние корневые центры сертификации", а версия 2010 - нет. Я не знаю, является ли это причиной проблемы или нормальным явлением.

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

Мой вопрос

Есть ли обновление для загрузки или шаг, который могут предпринять "обычные" пользователи, который позволит распознавать отметку времени/контрподпись в XP/Vista? "Обычные" пользователи здесь означают тех, кто не очень хорошо разбирается в компьютерах; Я не имею в виду права администратора.

Ошибка подписи временной метки возникает при установке таких приложений, как DotNetFramework, LogMeIn Go to Assist и т. д. Обычно это происходит, если Windows вашей системы устарела или существуют ограничения из политики выполнения вашей системы.

Ниже приводится полное сообщение об ошибке:

Подпись и/или сертификат временной метки не могут быть проверены или имеют неверный формат

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

Устаревшая Windows: Microsoft постоянно обновляет Dotnet Framework, чтобы устранить ошибки в работе/разработке приложений, и чтобы не отставать от них, Windows на вашем ПК должна быть полностью обновлена до последней версии. Если в вашей системе отсутствуют какие-либо такие обновления, это может вызвать проблему с подписью временной метки платформы Dotnet.
Устаревший установщик Dotnet Framework. Если вы пытаетесь использовать устаревший установщик Dotnet Framework (возможно, он уже присутствует в папках загрузки вашей системы), этот установщик может быть несовместим с ОС вашей системы и может вызвать проблему с Dotnet на рука.
Неподписанный системный драйвер. Чтобы повысить безопасность Windows и Dotnet Framework для запуска приложений, важно, чтобы все драйверы в вашей системе имели цифровую подпись, а если какой-либо из драйверов вашей системы не имеет цифровой подписи, Dotnet Framework установщик может выдать ошибку подписи метки времени.
Устаревшие корневые сертификаты вашей системы. Если ваша система не может автоматически обновить свои корневые сертификаты из-за сбоя в диспетчере сертификатов вашей системы, установщик Dotnet Framework может не пройти аутентификацию многих важных системных ресурсов и, таким образом, показать временную метку. вопрос.

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

Обновите Windows вашей системы до последней версии

Проблема с отметкой времени может быть результатом несовместимости проблемного приложения (например, LogMeIn Go to Assist) и ОС. В этом случае обновление Windows на вашем компьютере до последней стабильной версии может решить проблему.

Нажмите Windows, введите Проверить наличие обновлений и откройте Центр обновления Windows. Откройте "Проверить наличие обновлений".
Теперь в окне Центра обновления Windows нажмите кнопку «Проверить наличие обновлений» и, если обновления доступны, загрузите и установите эти обновления (в том числе необязательные обновления). Проверить наличие обновлений Windows.
После обновления перезагрузите компьютер и после перезагрузки проверьте, решена ли проблема с проверкой сертификата.

Если есть обновления, которые не удается установить, вы вручную устанавливаете эти обновления с веб-сайта каталога Microsoft, чтобы устранить ошибку сертификата.

Если проблема не устранена с таким приложением, как LogMeIn Go to Assist, проверьте, решает ли проблема использование его EXE-файла для установки приложения (а не средства открытия).

Используйте последнюю версию установщика Dotnet Framework

Выполнить SFC-сканирование системы

Вы можете столкнуться с проблемой, если основные системные файлы повреждены; выполнение сканирования SFC вашей системы заменит неполные файлы. Имейте в виду, что это сканирование может занять некоторое время (в зависимости от размера вашего системного диска), поэтому попробуйте его, когда у вас есть свободное время (например, на ночь).

Нажмите Windows, введите командную строку, щелкните ее правой кнопкой мыши и выберите «Запуск от имени администратора». Откройте командную строку от имени администратора
Затем выполните следующее: выполните сканирование SFC
Теперь дождитесь завершения сканирования, а затем проверьте, можно ли установить проблемное приложение (например, платформу Dot Net) без ошибки подписи временной метки.

Отключить подписывание кода пакета драйвера

Если вы столкнулись с проблемой "Не удалось проверить сертификат" с драйвером, отключение подписи кода пакета драйвера решит проблему.

Предупреждение:

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

Нажмите Windows, введите Редактор групповой политики и выберите результат редактирования групповой политики.
Теперь в окне редактора групповой политики разверните Конфигурация пользователя и перейдите по следующему пути:
Затем в левой половине окна дважды нажмите «Подпись кода для драйверов устройств» и выберите «Включено». Дважды щелкните Подписание кода для драйверов устройств в редакторе групповой политики.
Теперь разверните раскрывающийся список Когда Windows обнаружит файл драйвера без цифровой подписи и выберите Игнорировать. Установить, когда Windows обнаруживает файл драйвера без цифровой подписи, чтобы игнорировать его
Затем примените внесенные изменения и перезагрузите компьютер.
После перезагрузки проверьте, можно ли установить драйвер без проблем с отметкой времени.

Отключить автоматическое обновление корневых сертификатов

Эта ошибка также может возникнуть, если системе не удается автоматически обновить корневые сертификаты. Отключение автоматического обновления корневых сертификатов с помощью сторонней утилиты (DigiCert) решит проблему в этом случае.

Предупреждение. Действуйте на свой страх и риск, поскольку указанная утилита является сторонней утилитой, и использование сторонней утилиты может представлять угрозу безопасности вашей системы/данных.

Запустите веб-браузер и перейдите на страницу загрузки DigiCert. Скачать утилиту DigiCert
Затем нажмите кнопку "Загрузить" и после завершения загрузки запустите утилиту.
Теперь на левой панели перейдите в меню "Инструменты", а затем на правой панели нажмите "Автоматическое обновление корневого каталога". Откройте Auto Root Update на вкладке "Инструменты" утилиты DigiCert Certificate Utility.
Затем измените параметр Auto Root Update на Disabled и закройте утилиту (если потребуется, обязательно примените изменения).
Теперь перезагрузите компьютер и после перезагрузки проверьте, решена ли проблема с проверкой сертификата.

Если проблема не устранена, вы можете экспортировать проблемный сертификат и импортировать его обратно, чтобы решить проблему проверки сертификата (если проблемный сертификат идентифицирован). Если вы столкнулись с проблемой с DotNetFramework, проверьте, решает ли загрузка следующего сертификата Microsoft и его импорт в Управление сертификатами пользователей>> Доверенные корневые центры сертификации>> Сертификаты.

Импортируйте сертификат в доверенный корневой центр сертификации в Диспетчере сертификации

В зависимости от источника этой проблемы сообщение об ошибке может выглядеть примерно так:

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

Что такое неправильно сформированный сертификат?

Как исправить отметку времени. Подпись и/или сертификат не могут быть проверены или имеют неверный формат?

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

Подпись с меткой времени и/или сертификат не могут быть проверены или имеют неверный формат

Проверьте отметку времени сертификата
Загрузить последнюю версию программы установки
Разблокировать водителя
Отключить подписывание кода для пакета драйвера
Отключить обязательное использование подписи драйверов

Чтобы узнать больше об этих решениях, читайте дальше.

1] Проверьте отметку времени сертификата

Нажмите файл правой кнопкой мыши и выберите "Свойства".
Перейдите на вкладку "Цифровые подписи".
Выберите подписывающую сторону и нажмите кнопку "Сведения".
Нажмите кнопку "Просмотреть сертификат".
Проверьте дату Действителен с.

Если срок его действия не истек, вы можете воспользоваться остальными обходными путями. Однако, если срок его действия истек, вы можете обратиться к разработчику драйвера или загрузить последнюю версию установщика.

2] Загрузите последнюю версию установщика

3] Разблокировать водителя

Далее вы можете продолжить процесс установки.

4] Отключить подпись кода для пакета драйверов

Нажмите Win+R, чтобы открыть диалоговое окно «Выполнить».
Введите gpedit.msc и нажмите кнопку Enter.
Выберите «Конфигурация пользователя» > «Административные шаблоны» > «Система» > «Установка драйвера».
Дважды щелкните параметр Подписание кода для пакетов драйверов.
Выберите параметр «Включено».
Выберите вариант «Игнорировать» в раскрывающемся списке.
Нажмите кнопку "ОК".

После этого закройте все окна и проверьте, можете ли вы установить фреймворк или нет.

5] Отключить обязательное использование подписи драйверов

Чтобы решить эту проблему, вы можете полностью отключить обязательное использование подписи драйверов на компьютере с Windows 11/10. Это не занимает много времени и решает проблему сразу. Поэтому следуйте этому подробному руководству, чтобы отключить обязательное использование подписи драйверов в Windows 11/10.

Вот и все! Надеюсь, это руководство помогло вам решить проблему.

Исправить ошибку 0x80071AB1 (ERROR_LOG_GROWTH_FAILED) в Windows 11/10

Не удалось загрузить файл или сборку MOM.implementation или одну из ее зависимостей

[электронная почта защищена]

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

сообщить об этом объявлении

Как известно, подпись гарантирует, что электронный документ не был изменен после подписания. Это полезная функция для конфиденциальных данных, которые могут быть изменены во время передачи по сети. Например, Интернет.Существует одна известная атака под названием Man In The Middle (MITM). В MITM злоумышленник перехватывает документ, изменяет некоторые данные и передает исходному получателю. Если документ изначально подписан (отправителем), получатель попытается проверить подпись документа и увидит, что документ был изменен во время передачи данных. Это сделает документ недействительным.

В реальном мире цифровые подписи используются очень часто и используют асимметричные процессы шифрования/дешифрования.

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

Как работает процесс подписания?

Отправитель создает документ и вычисляет для него криптографический хэш, используя один из алгоритмов одностороннего хеширования. Хэш представляет собой нечто вроде контрольной суммы и уникален для каждого документа. Когда вы меняете документ, хэш документа тоже меняется. Существует множество алгоритмов хэширования, таких как SHA1, SHA2 (семейство), MD5 и так далее. Используя эти алгоритмы, вы можете получить контрольную сумму, но не можете восстановить исходный документ по этой контрольной сумме (хешу).
При вычислении хэша отправитель шифрует его с помощью собственного закрытого ключа. Полученная зашифрованная строка является желаемой цифровой подписью, прикрепленной к документу.
Когда получатель получает подписанный документ, он хочет проверить, был ли документ изменен во время передачи файла или нет. Получатель отделяет подпись от документа и берет открытый (общедоступный) ключ подписывающей стороны для расшифровки зашифрованной строки и извлечения хэша исходного документа.
Если оба хэша совпадают, подпись действительна и документ не был изменен во время передачи. В противном случае документ был изменен, и мы не можем ему доверять. Итак, отклоните документ.

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

После этого получатель вычисляет хеш для документа, используя тот же алгоритм хэширования, который использовался в процессе подписания. Если документ не изменен, оба хэша (рассчитанные получателем и извлеченные из подписи) ДОЛЖНЫ совпадать, и документ считается действительным. Если они не совпадают, то документ был изменен неуполномоченным лицом и документ считается ненадежным.

Довольно просто (на самом деле нет ничего сложного).

В Windows представлены 4 уровня доверия цифровой подписи:

Ненадежный. Подпись была создана явно недоверенным издателем. Сертификат подписи часто отзывается, когда владелец сертификата теряет свой собственный закрытый ключ подписи или когда он украден. Во избежание потери сертификата от использования (чтобы никто не смог использовать украденный сертификат для выдачи себя за законного пользователя и создания вредоносных подписей) сертификат ДОЛЖЕН быть отозван и/или помещен в контейнер ненадежных сертификатов в локальном хранилище сертификатов Windows.
Неизвестный издатель. Личность неизвестна и подпись недействительна. Поскольку нет проверенной подписи, личность не может быть определена. Сертификат подписи не отзывается и не является явно недоверенным, а выдается недоверенным центром сертификации (ЦС).
Известный издатель. Личность известна, и подпись действительна. Действительная подпись Authenticode обеспечивает идентификацию. Сертификат подписи — это действительный сертификат, выданный доверенным ЦС.
Надежный издатель. Подпись действительна и была создана явно доверенным издателем. Сертификаты подписи для этого уровня доверия должны быть выпущены любым доверенным ЦС, а сертификат должен быть помещен в локальное хранилище сертификатов доверенных издателей.

Почему так много уровней доверия? Возможно, это должно быть просто Trusted/Untrusted? Да, для определенных сценариев этого достаточно, но не всегда. Приложения используют различные уровни доверия в зависимости от внутренних требований. Поскольку существует множество доверенных ЦС, они выдают множество сертификатов подписи различным издателям.Однако часто мы не хотим доверять документам, подписанным этими издателями. Четырехуровневая модель доверия позволяет нам доверять только определенным издателям и не более того.

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

В обычном случае (например, с SSL и другими сертификатами шифрования) по истечении срока действия сертификата все подписанные данные становятся недействительными. Вы не можете подключиться к веб-серверу с просроченным SSL. Однако вам необходимо сохранять подписи действительными, даже если срок действия сертификата подписи истек. Одна из идей состоит в том, чтобы разрешить успешную проверку сертификата подписи (и подписи) даже после истечения срока действия сертификата. Однако это решение не было бы мудрым, потому что мы потеряли бы контроль над незаконным использованием сертификата — операциями подписи после истечения срока действия сертификата подписи. Кроме того, если ключ подписи был скомпрометирован и подтверждено, что он был действителен до указанной даты/времени, мы не сможем определить, была ли подпись сгенерирована до или после даты компрометации.

Для решения этой проблемы была введена дополнительная служба — отметка времени. Согласно Википедии:

Надежная временная метка — это процесс безопасного отслеживания времени создания и изменения документа. Безопасность здесь означает, что никто — даже владелец документа — не сможет изменить его после того, как он был записан, при условии, что целостность метки времени никогда не будет нарушена.

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

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

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

Пример сценария — стандартный жизненный цикл сертификата

Предположим следующий сценарий: у вас есть сертификат для подписи документа со сроком действия: с 1 января 2015 г. по 31 декабря 2015 г. В следующих двух разделах показано, что произойдет с подписью в различные моменты времени. В первом разделе предполагается, что вы делали подписи без отметок времени, а во втором сценарии предполагается, что вы делали подписи с отметками времени.

Стандартный жизненный цикл сертификата — подпись без временных меток

Здесь правило довольно простое: подписи могут быть проверены только в течение срока действия сертификата подписи. Если вы попытаетесь проверить подпись (без подделки) в период с 1 января 2015 г. по 31 декабря 2015 г., проверка завершится успешно. Любые попытки проверки, выходящие за пределы действительности сертификата, завершатся неудачей. Это связано с тем, что у нас нет информации о том, когда были созданы подписи.

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

Стандартный жизненный цикл сертификата — подпись с отметкой времени

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

В результате мы можем доверять подписям, если выполняем проверку подписи даже после истечения срока действия сертификата подписи.В этом сценарии отпадает необходимость повторно подписывать все ранее подписанные документы, поскольку срок действия сертификата подписи истек. Более того, подпись будет доверенной, даже если срок действия всех сертификатов в обеих цепочках (сертификат подписи и сертификат с меткой времени), включая сертификаты ЦС, истек. Пока оба корня являются доверенными (представлены в контейнере Trusted Root CAs на машине).

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

Обратите внимание, что мы по-прежнему не можем доверять подписям, созданным за пределами срока действия сертификата подписи. Подпись ДОЛЖНА быть создана в течение срока действия сертификата, в противном случае подпись не заслуживает доверия.

Пример сценария — отзыв

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

У вас есть сертификат для подписи документа со сроком действия: с 1 января 2015 г. по 31 декабря 2015 г. Сертификат (и его закрытый ключ) был утерян 1 августа 2015 г. Вы предприняли необходимые действия для немедленного отзыва сертификата. В следующих двух разделах показано, что произойдет с подписью в различные моменты времени. В первом разделе предполагается, что вы делали подписи без отметок времени, а во втором сценарии предполагается, что вы делали подписи с отметками времени.

Сценарий с отозванным сертификатом — нет подписи с меткой времени

Правило здесь довольно простое. Если вы попытаетесь проверить подпись в период с 1 января 2015 г. (начало действия сертификата подписи) по 1 августа 2015 г. (когда сертификат был отозван и помещен в список отзыва сертификатов), мы будем доверять подписи. Однако после 1 августа траст будет прекращен. Как только мы найдем сертификат подписи в CRL, мы аннулируем *все* подписи, сделанные отозванными сертификатами.

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

Сценарий с отозванным сертификатом — подпись с отметкой времени

В целом, если подпись имеет отметку времени, мы можем доверять ей, если подпись была сделана в течение срока действия сертификата подписи. Однако в нашем сценарии есть условие: сертификат отозван. Поскольку дата отзыва представлена в CRL, а время создания подписи представлено в отметке времени, мы можем безопасно доверять всем подписям, сгенерированным в период между началом действия сертификата подписи (1 января 2015 г.) и до даты отзыва (1 августа 2015 г.). Мы не можем доверять подписям, созданным после 1 августа, поскольку контроль над ключом потерян.

Неочевидным моментом здесь является то, что мы можем успешно проверять подпись даже после истечения срока действия сертификата подписи (и сертификат активно указан в CRL), потому что мы знаем, что подпись была сделана в период, когда ключ не был скомпрометирован.< /p>

Это приводит нас к еще одному передовому методу управления отзывами:

Некоторые центры сертификации (ЦС) удаляют просроченные сертификаты из своих списков отзыва сертификатов (CRL). Однако для большей безопасности вы НЕ ДОЛЖНЫ удалять просроченные сертификаты подписи кода/документа/электронной почты/чего-либо еще из CRL до тех пор, пока ЦС не будет полностью выведен из эксплуатации. В противном случае вы открываете брешь в успешной проверке подписи, когда ключ подписи был отозван.

В этом разделе представлена краткая таблица, показывающая статус проверки подписи при всех описанных выше условиях.

Простая подпись

Подпись с отметкой времени

как видите, есть только один случай, когда простая подпись остается действительной — пока сертификат действителен по времени и не отозван. Во всех остальных случаях подпись становится недействительной. Но подпись с меткой времени остается действительной, даже если срок действия всех сертификатов в цепочках подписи и метки времени истек. Поэтому вы должны ставить отметку времени для своих подписей каждый раз, когда подписываете что-либо, если это возможно. Некоторое время назад (когда я еще не учился в PKI) я задался вопросом — «Для каких целей Windows поставляется с просроченными корневыми сертификатами в контейнере Trusted Root CAs? Они просрочены и нет причин им доверять!». И ответ был довольно прост — для проверки цифровой подписи с отметкой времени. Поэтому, если вы выдаете сертификаты подписи своим внутренним ЦС — не удаляйте сертификат корневого ЦС после обновления сертификата ЦС.

Категории: Безопасность | PKI
Опубликовано: 21.10.2010 22:58 (GMT+3) Вадим Поданс | Постоянная ссылка | Комментарии (23)

Когда записываются дата и время события, мы говорим, что оно имеет отметку времени. Цифровая камера записывает время и дату фотосъемки, компьютер записывает время и дату сохранения и редактирования документа. Пост в социальной сети может иметь записанную дату и время. Все это примеры метки времени.

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

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

В таких юридических условиях недостаточно просто иметь временную метку. Если ваш аргумент сводится к тому, когда было подписано соглашение о неразглашении, вы должны быть в состоянии доказать, что отметка времени подписи действительна, что в ней говорится, что документ был подписан, когда он был фактически подписан. Временных меток, основанных на системных часах, недостаточно, так как несложно изменить дату и время локально на машине. Кроме того, существует множество онлайн-инструментов, которые позволят вам изменить дату изменения, создания и последнего обращения к документу или PDF-файлу. Итак, как нам узнать, можно ли доверять метке времени?

Именно здесь на помощь приходят «надежные» временные метки. Эти типы временных меток генерируются доверенной третьей стороной с использованием безопасного оборудования, совместимого с FIPS, поэтому локальный пользователь не может их изменить. Надежная отметка времени означает, что вы можете с высокой степенью уверенности сказать, что дата на отметке времени является точной и не была изменена.

RFC 3161 описывает требования, которым должна соответствовать третья сторона, чтобы работать в качестве центра временных меток (TSA).

TSA используют технологию инфраструктуры открытых ключей (PKI) для применения меток времени. Вот краткий обзор необходимых шагов.

Клиентское приложение создает хэшированное значение (как уникальный идентификатор данных или файла, которому необходимо присвоить отметку времени) и отправляет его в TSA.
С этого момента любое изменение (даже одного бита информации) в исходном файле потребует передачи изменений на сервер TSA.
TSA объединяет хэш и другую информацию, включая официальное время. Результат подписывается в цифровой форме закрытым ключом TSA, создавая токен с меткой времени, который отправляется обратно клиенту. Маркер временной метки содержит информацию, которая потребуется клиентскому приложению для проверки временной метки позже.
Токен временной метки принимается клиентским приложением и записывается в документе или подписи кода.

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

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

Электронная подпись документов

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

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

Цифровая подпись документов

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

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

Долгосрочная проверка (LTV)

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

В зависимости от программы, которую вы используете для применения подписи, вам может потребоваться включить в подпись доверенную временную метку, чтобы достичь LTV. В этих случаях метка времени используется в качестве контрольной точки для проверки достоверности подписи. Если программа увидит, что текущий статус сертификата отозван или просрочен, но подпись была применена до отзыва или истечения срока действия, она покажет, что подпись все еще действительна. Большинству программ для этого требуется доверенная отметка времени третьей стороны; использование системных часов вашего компьютера ненадежно, поскольку ими можно манипулировать.

Программам Microsoft Office и Adobe версий 6, 7 и 8 требуется отметка времени для LTV. Adobe 9+ встраивает информацию об отзыве (CRL или OCSP) во время подписания, что позволяет достичь той же цели проверки действительности сертификата при применении подписи, поэтому отметка времени не требуется для LTV.

Добавление уверенности в дате и времени подписания документа

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

Надежные временные метки поддерживают эти сценарии, поскольку они применяются с использованием независимо проверенных и поддающихся аудиту источников даты и UTC (всемирное скоординированное время). Это означает, что они не подвержены фальсификации, как локальные системные часы, поэтому вы точно знаете, когда была применена подпись.

Цифровая подпись кода

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

Без временной метки срок действия подписи истекает или становится недействительным, когда сертификат истечет или будет отозван, а конечные пользователи увидят пугающие предупреждающие сообщения о том, что им не следует доверять коду. С отметкой времени (и LTV) подпись по-прежнему будет считаться надежной, поскольку сертификат подписи был действителен на момент применения подписи.

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

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