Динамика доверия[продолжение, предыдущая часть] Доверие не статично. Рут доверяет Алисе ограниченно долго, с момента t1 до момента t2. Например, с момента приема на работу и до окончанияконтракта. Отрезок [t1,t2] указывается в сертификате A(R) и называется сроком действия. Интересно, что сертификат X.509 спроектирован так, что момент выпуска в нем не фиксируется. Обычно предполагается, что сертификат выпущен в момент t1. Отрезок доверия [t1,t2] также не статичен. Алиса может уволиться в момент t3 > t2 или потерять в этот момент свой личный ключ. В таких ситуациях отрезок доверия должен быть сокращен до [t1,t3]. Как это сделать? Ведь сертификат A(R) уже выпущен, забрать его нельзя. Мы сталкиваемся с общей особенностью цифрового мира – опубликованные данные бессрочны, "рукописи не горят". Если нельзя отменить публикацию, то давайте опубликуем опровержение. Так и поступает Рут. Рут регулярно (например, ежедневно) публикует объявление об отзыве. В нем Рут перечисляет номера отозванных сертификатов, ранее им выпущенных, указывает время отзыва. Рут фиксирует время публикации текущего и следующего объявлений, подписывает объявление. Объявление называется списком отозванных сертификатов (СОС). По последнему СОС Боб определяет текущий отрезок доверия сертификата Алисы. Отзыв сертификата происходит после публикации действующего СОС и перед публикацией следующего. СОС может обновляться не очень часто, и тогда Боб долгое время может не знать об отзыве. Если такая ситуация Боба не устраивает, то он может обратиться к Ольге. Ольга – это служба, которая реализует протокол онлайн-проверки статуса сертификата (OCSP, Online Certificate Status Protocol, зафиксирован в СТБ 34.101.26). Протокол очень простой. Боб отправляет Ольге серийный номер интересующего его сертификата, а Ольга возвращает статус сертификата в момент времени, близкий к текущему. Ольга указывает время и срок действия ответа, подписывает ответ. Для подготовки ответа Ольга тесно взаимодействует с Рутом, получая у него самую свежую информацию об отзыве. Рут сам может выполнять функции Ольги, подписывая OCSP-ответы на своем личном ключе. СОС и OCSP-ответы – это новые примеры аттестатов. Их естественно назвать аттестатами отзыва. Располагая свежим аттестатом отзыва, Боб может убедиться в действительности сертификата Алисы в момент проверки ее подписи. Но что делать, если Боб проверяет подпись в момент t4>t3, тогда, когда сертификат Алисы уже отозван (см. рисунок)?
Здесь мы должны обсудить две модели проверки подписи. В первой модели сертификат Алисы должен быть действителен в момент проверки, во второй – в момент выработки подписи. Первая модель используется при проверке цепочки сертификатов в стандарте 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. Обратим внимание, что на рисунке дополнительно вырабатывается архивный штамп времени. Он покрывает не только базовую подпись Алисы, но и аттестаты. Архивный штамп позволяет удостоверить подпись даже по прошествии большого времени и даже после компрометации базовых криптографических алгоритмов. Кроме штампа времени, еще одним аттестатом существования является рапорт времени – запись в журнале аудита специальной службы. Запись касается подписи данных с определенным хэш-значением в определенный момент времени. Служба рапортов времени является менее прозрачной, чем служба Тома – Боб не получает рапорт и не может быть уверен, что служба не откажется от него впоследствии. Тем не менее, при полном доверии к службе вопросы заверения времени подписи решаются. Службы рапортов времени неявно используются в действующих системах электронного документооборота. |
Новости
17.06.2025
Digital Expo 2025
16.05.2025
XХX научно-практическая конференция
19.12.2024
Выборы Президента Республики Беларусь
12.12.2024
Награждение победителей конкурса
10.12.2024
Визит Министра образования
21.10.2024
Создание сектора КБ
07.05.2024
Защита диссертации
07.03.2024
План семинара весна 2024
12.02.2024
Единый день голосования
|