РешенияПродуктыКонсалтингПоддержкаКонтакты
Перейти на предыдущую страницу  Перейти на главную страницу  Версия для печати  

Службы меток времени и эталонного доверенного времени

Автор:
Фролов Никита Владимирович,
системный инженер отдела информационной безопасности
ООО "Компания "Демос"


Введение

    Возросшие требования к безопасности приложений обеспечиваются механизмами аутентификации и авторизации, а также процедурами, гарантирующими конфиденциальность, целостность и неотказуемость. Часть этих задач решается в инфраструктуре открытых ключей (PKI). Важную роль в PKI играет проставление меток времени, заслуживающих доверия (Time-Stamping Protocol RFC 3161 и Policy Requirements for Time-Stamping Authorities RFC 3628). В этом случае метка времени используется для проверки того, что на момент подписания время жизни ключевой пары подписавшего не истекло, или она не была отозвана. Цифровая метка времени позволяет утверждать, что данный документ существовал или, например, был подписан до указанного момента времени, и не был с тех пор изменен. Возможное использование механизма выпуска меток времени в разных сферах применения:

Инфраструктура открытых ключей:

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

  • цифровые квитанции;
  • онлайновые банковские транзакции;
  • биржевая торговля.
А также:

  • почтовая служба, входящий/исходящий трафик электронной почты
  • защищенные журналы транзакций и пр.


Центр выдачи меток времени

    Большинство реализаций сервиса меток времени используют третью доверенную сторону - центр выпуска меток времени (Time-Stamping Authority - TSA), для того чтобы связать данные с эталоном времени. TSA является сервисом, который обеспечивает доказательство того, что данный документ был предъявлен TSA в указанное время. По получению верно сформированного запроса TSA выпускает метку времени, в которую включается уникальный идентификатор, идентификатор применяемой политики безопасности, значение времени, полученное от доверенного эталонного источника, цифровая подпись значения времени, хеш помечаемых данных. При выпуске метки осуществляется лишь соответствие длины полученного хеша заявленному алгоритму хеширования, других проверок не осуществляется. Также в метку не включается информация о стороне, производящей запрос, но по требованию запрашивающей стороны возможно добавление дополнительной информации в рамках поддерживаемых расширений. TSA подписывает каждую метку времени своим ключом, генерированным исключительно для этой цели, что должно быть подтверждено соответствующим полем сертификата ключа. Допускается использование нескольких ключей различной длины для использования различных алгоритмов или политик безопасности, а так же для повышения производительности.


Эталонный доверенный источник времени

    Для получения информации о времени TSA использует сервис времени (stratum 1), обладающий необходимой для клиентских приложений точностью, что оговаривается используемой политикой выпуска меток времени, и доступный по безопасному протоколу (обычно, DS/NTP). Включение в метку времени подписи значения времени позволяет отследить путь значения непосредственно до stratum 1. Для уменьшения сетевого трафика, повышения надежности и производительности TSA часто содержит собственный (менее точный для уменьшения себестоимости) источник времени, синхронизируемый с основным, в таком случае политика должна запрещать выпуск меток без периодической синхронизации.


Обзор протокола проставления меток времени

В каждой системе использующей механизм выпуска меток времени участвуют три стороны:
  1. клиент - сторона, формирующая запрос на получение метки времени и отправляющая его стороне, отвечающей за проставление меток времени (используя протокол, оговоренный в RFC 3161).
  2. сервер (TSA) - сторона, принимающая, обрабатывающая запросы на получение меток времени и выпускающая метки времени.
  3. клиент - сторона, осуществляющая проверку меток времени

Формат запроса

    Запрос состоит из версии используемого протокола, хэша документа, некоторых других опционных полей. Весь документ не отправляется из соображений конфиденциальности и уменьшения объема трафика и данных, хранящихся на сервере. Запрос представляется в нотации ASN.1:
  • version (обязательное поле)- версия используемого протокола меток времени (текущая версия v1);
  • messageImprint (обязательное поле) - содержит хэш значение данных, которые нужно связать с меткой времени и идентификатор алгоритма хеширования. Алгоритм должен быть однонаправленным и без столкновений. При получении запроса TSA должен проверить алгоритм хэширования, и в том случае, если он ему не известен или слабый, отказать в предоставлении метки времени и отправить сообщение об ошибке (со значением PKIFailInfo badAlg);
  • reqPolicy (необязательное поле) - содержит идентификатор политики, применяемой для выпуска метки времени;
  • nonce (необязательное поле) - большое целое случайное число (например, 64 битное) с высокой вероятностью того, что клиент может сгенерировать его только один раз. Это поле является случайным параметром процесса. Так же позволяет проверить своевременность ответа. В этом случае это число должно быть включено в ответ, иначе он не будет принят;
  • certReq (необязательное поле, по умолчанию false) - если это поле присутствует и выставлено значение true, то в ответе должен присутствовать сертификат TSA.
    Поскольку в самом запросе на получение метки времени нет информации, указывающей на личность запрашивающего, то в тех случаях, когда необходима идентификация запрашивающего, используются дополнительные средства идентификации/аутентификации.


Формат ответа

    Хеш данных и текущая дата формируют структуру данных о метке времени TSTInfo. Полученная структура подписывается закрытым ключом TSA.
    Первым в ответе следует структура statusInfo. Она кратко описывает состояние процесса проставления меток времени. Если ошибки отсутствуют, то к этому полю прикладывается действующая метка времени (TimeStampToken). Возможные состояния и ошибки описываются в RFC 3161. Информация о метке времени содержится в поле TSTInfo.
    Поля policy (обязательное поле), message imprint (обязательное поле) и nonce (необязательное поле) должны быть такими же, как и в запросе.
    SerialNumber (обязательное поле) - уникальное целое число, которое TSA добавляет к каждой выпускаемой метке времени.
    genTime (обязательное поле) - время создания TST в формате UTC.
    accuracy (необязательное поле) - временная точность (с точностью до микросекунд).
    ordering (необязательное поле, по умолчанию false) - если это поле выставлено 'false' или отсутствует, то упорядочивание меток времени возможно в том случае, если разница во времени между первой выпущенной меткой и следующей превышает сумму значений полей accuracy для обеих меток времени. Если оно имеет значение 'true', то упорядочивание происходит на основании значения поля genTime, независимо от значения поля accuracy.
    После получения ответа, запрашивающая сторона должна проверить код ошибки. В случае успешного получения ответа необходимо проверить поля полученного ответа и действительность цифровой подписи метки времени. В частности, необходимо проверить соответствие хэша данных, которым требуется метка, хэшу, для которого была выдана метка в действительности. Необходимо проверить, что ответивший TSA является тем, за кого он себя выдает. Полученное значение времени должно быть сопоставлено с доверенным источником времени, в случае его отсутствия сравниваются включенные в запрос и ответ большие случайные числа. Полученная метка времени отклоняется при любом возникшем несоответствии. Если сертификат TSA мог быть отозван, необходимо проверить действительность сертификата при помощи CRL. Также должна быть осуществлена проверка политики, в рамках которой была выпущена метка, чтобы установить приемлемость использования полученной метки клиентским приложением.
    Существует несколько реализаций API запроса и проверки меток времени, соответствующих RFC 3161, от различных поставщиков.


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

    При обеспечении надежных и управляемых цифровых свидетельств необходимо иметь соглашение (политику) о методе сопоставления значения времени и транзакции для того, чтобы иметь возможность проверить их в дальнейшем. Качество доказательств обеспечивается созданием и поддержанием хранилища, которое содержит сведения о событиях и некоторые параметрические данные, связывающие записи с реальным миром (в данном случае это привязанные к данным значения времени). Разделы политики, описывающие жизненный цикл ключевого материала, роли персонала (офицеры безопасности, администраторы, операторы архивации, аудиторы), физическую защиту устройств, входящих в состав TSA, составляются на основе шаблонов политик эксплуатации критических сервисов, разработанных для конкретной инфраструктуры.
    Каждая транзакция - документ, обладающий цифровой подписью, для которой должно существовать доказательство того, что сертификат подписанта был действителен и не скомпрометирован на момент подписи. Метка времени, безопасно сохраняемая третьей стороной и доступная для аудита, обеспечивает такое доказательство. Подобная схема позволяет удостоверять цифровую подпись и время создания документа, используя цепочку сертификатов. Сертификаты ключей должны издаваться в рамках политик, созданных специально для выпуска меток времени и распространения значений времени. Требуется организация хранения сертификатов публичных ключей TSA и источника времени, прекративших свое действие или скомпрометированных сертификатов, и описание процедуры уничтожения закрытых ключей.
    В настоящее время архивация ключей, используемых для выпуска меток времени, не поддерживается большинством решений, реализующих TSA, по соображениям минимизации риска компрометации. Рекомендуется использование совместно с TSA криптографических модулей для защиты ключевого материала, соответствующих спецификациям FIPS 140-1 уровня 3 и выше, CWA 14167-2 или ISO 15408.

Перейти в начало страницы