Динамика доверия[продолжение, предыдущая часть] Доверие не статично. Рут доверяет Алисе ограниченно долго, с момента 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. Обратим внимание, что на рисунке дополнительно вырабатывается архивный штамп времени. Он покрывает не только базовую подпись Алисы, но и аттестаты. Архивный штамп позволяет удостоверить подпись даже по прошествии большого времени и даже после компрометации базовых криптографических алгоритмов. Кроме штампа времени, еще одним аттестатом существования является рапорт времени – запись в журнале аудита специальной службы. Запись касается подписи данных с определенным хэш-значением в определенный момент времени. Служба рапортов времени является менее прозрачной, чем служба Тома – Боб не получает рапорт и не может быть уверен, что служба не откажется от него впоследствии. Тем не менее, при полном доверии к службе вопросы заверения времени подписи решаются. Службы рапортов времени неявно используются в действующих системах электронного документооборота. |
Новости
21.10.2024
Создание сектора КБ
07.05.2024
Защита диссертации
07.03.2024
План семинара весна 2024
12.02.2024
Единый день голосования
24.10.2023
II Международная научная конференция
26.05.2023
XХVIII научно-практическая конференция
28.04.2023
TIBO 2023
02.01.2023
Программный комплекс ЭАДП
27.12.2022
С Новым годом!
|