Динамика доверия

[продолжение, предыдущая часть]

Доверие не статично. Рут доверяет Алисе ограниченно долго, с момента t₁ до момента t₂. Например, с момента приема на работу и до окончанияконтракта. Отрезок [t₁,t₂] указывается в сертификате A(R) и называется сроком действия. Интересно, что сертификат X.509 спроектирован так, что момент выпуска в нем не фиксируется. Обычно предполагается, что сертификат выпущен в момент t₁.

Отрезок доверия [t₁,t₂] также не статичен. Алиса может уволиться в момент t₃ > t₂ или потерять в этот момент свой личный ключ. В таких ситуациях отрезок доверия должен быть сокращен до [t₁,t₃]. Как это сделать? Ведь сертификат A(R) уже выпущен, забрать его нельзя. Мы сталкиваемся с общей особенностью цифрового мира – опубликованные данные бессрочны, "рукописи не горят".

Если нельзя отменить публикацию, то давайте опубликуем опровержение. Так и поступает Рут. Рут регулярно (например, ежедневно) публикует объявление об отзыве. В нем Рут перечисляет номера отозванных сертификатов, ранее им выпущенных, указывает время отзыва. Рут фиксирует время публикации текущего и следующего объявлений, подписывает объявление.  Объявление называется списком отозванных сертификатов (СОС). По последнему СОС Боб определяет текущий отрезок доверия сертификата Алисы.

Отзыв сертификата происходит после публикации действующего СОС и перед публикацией следующего. СОС может обновляться не очень часто, и тогда Боб долгое время может не знать об отзыве. Если такая ситуация Боба не устраивает, то он может обратиться к Ольге. Ольга – это служба, которая реализует протокол онлайн-проверки статуса сертификата (OCSP, Online Certificate Status Protocol, зафиксирован в СТБ 34.101.26). Протокол очень простой. Боб отправляет Ольге серийный номер интересующего его сертификата, а Ольга возвращает статус сертификата в момент времени, близкий к текущему. Ольга указывает время и срок действия ответа, подписывает ответ.

Для подготовки ответа Ольга тесно взаимодействует с Рутом, получая у него самую свежую информацию об отзыве. Рут сам может выполнять функции Ольги, подписывая OCSP-ответы на своем личном ключе.

СОС и OCSP-ответы – это новые примеры аттестатов. Их естественно назвать аттестатами отзыва. Располагая свежим аттестатом отзыва, Боб может убедиться в действительности сертификата Алисы в момент проверки ее подписи. Но что делать, если Боб проверяет подпись в момент t₄>t₃, тогда, когда сертификат Алисы уже отозван (см. рисунок)?

Здесь мы должны обсудить две модели проверки подписи. В первой модели сертификат Алисы должен быть действителен в момент проверки, во второй – в момент выработки подписи.

Первая модель используется при проверке цепочки сертификатов в стандарте X.509 (СТБ 34.101.19): все сертификаты должны быть действительны одновременно. Вторая модель развивается Европейским институтом телекоммуникационных стандартов (ETSI) в рамках регламента eIDAS (eID, Authentication and Signature) Евросоюза. Во второй модели цепочка сертификатов проверяется по-другому: сертификат эмитента должен быть действителен в момент выпуска сертификата субъекта.

Вернемся к рисунку. В модели X.509 подпись Алисы будет признана недействительной. Отзыв (или даже окончание действия) сертификата Алисы аннулирует все ее подписи! Такая ситуация недопустима в сколь-нибудь серьезных системах электронного документооборота.

Даже при переключении на модель eIDAS вердикт проверки не изменится: Боб не сможет понять, выработана подпись до отзыва сертификата или после. Изменить вердикт помогает дополнительный аттестат – штамп времени.

Штампы времени выпускает Том. Он подверждает существование определенных данных к определенному моменту времени. Алиса, Боб и любая другая сторона могут послать Тому хэш-значение h(D) объекта D. Том подписывает h(D) вместе с отметкой времени t. Подписанные данные и называются штампом времени.

Том подписывает D вслепую, располагая только хэш-значением. Поэтому штамп времени – это аттестат существования: документ с хэш-значением h(D) существует, но какой он – неизвестно. Если Алиса предъявит D после t и функция хэширования h сохранит к этому времени стойкость, то Алиса докажет владение D. Аттестат существования станет аттестатом владения. Если в качестве D Алиса будет использовать подпись документа, то штамп времени сохранит действительность подписи даже после отзыва сертификата Алисы.

Служба Тома (Time Stamp Authority) стандартизирована в RFC 3161. Стандартизация ведется и в нашей стране. Разработан проект стандарта с рабочим названием СТБ 34.101.ts. Его обсуждение и принятие планируются в ближайшее время.

Служба Тома позволяет обосновывать действительность подписи в довольно запутанных ситуациях, связанных с отзывом сертификатов не только Алисы, но и Тома, Ольги и даже Рута. Даже для цепочки событий, изображенной на следующем рисунке, подпись может быть проверена в модели eIDAS.

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

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

[следующая часть]