id: Гость   вход   регистрация
текущее время 13:18 28/03/2024
Владелец: Alex_B (создано 20/12/2007 14:47), редакция от 17/09/2009 21:26 (автор: Гость) Печать
Категории: инфобезопасность, политика, разное
создать
просмотр
редакции
ссылки

Формат метки времени

< Все документы:
Оглавление документа:

Введение


Метка времени – это подписанный (ЭЦП) сертификат, содержащий штамп времени, выдаваемый сервисом меток времени. С помощью такого сертификата можно установить факт существования информации в засвидетельствованный момент времени.


«Метки времени» образуют цепочку, в которой каждая последующая метка содержит доказательство, что выдана именно после предыдущей (в метку включается хеш предыдущей). Таким образом, снижается риск фальсификации «метки времени» — если сервис выдаст «метку времени» задним числом, это можно будет обнаружить.


Использования связывания «меток времени» позволяет вам контролировать сервис.


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


Формат метки времени



Примечание: Хеш значение атрибута Ref-Hash считается от следующей части предыдущей метки:


Немного подробнее формат "меток времени" описан в статье Формат «Меток времени»


p.s. Для упрощения в настоящий момент упразднил два формата меток времени.


© 2007-2008 Alex_B, SATtva, serzh
© 2007 ntldr
© 2008 poptalk
© 2009 Анонимные пользователи

Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike
CreativeCommons-Attribution-ShareAlike

 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Комментарии [скрыть комментарии/форму]
— poptalk (06/01/2008 23:31)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Сервис просто берет и заменяет одну метку времени на другую.

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

Каждое заинтересованное лицо может сделать несколько «контрольных» меток времени и запомнить их. Потом клиенту достаточно проверить цепочку до такой сохраненной метки.

Хм. Если мне нужна метка задним числом T, сервис находит метку М1 со временем T1, T1 чуть меньше T, и выпускает метку М, где М. Ref-Hash-* = хэш М1. От М можно проследить путь к контрольной метке М2 со временем T2, T2<T1.

Предлагаю другой способ проверки: я получаю с сервиса последнюю выданную сервисом метку М3 и прослеживаю путь до проверяемой мною метки М.
— serzh (07/01/2008 00:57)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Если бы все метки обязательно дублировались на других серверах, то поймать сервис на подмене можно было бы даже при простой порядковой нумерации меток, как я предложил.
В данном случае достаточно только одной контрольной метки, что значительно удобнее.

Предлагаю другой способ проверки: я получаю с сервиса последнюю выданную сервисом метку М3 и прослеживаю путь до проверяемой мною метки М.
В общем случае, так и делается. Контрольные метки необходимы для защиты от фальсификации всей цепочки (Мп(последняя) -> М). А если у вас есть достоверная метка M' (T'>T), необходимая для проверки цепочка сокращается (M' -> M).
— poptalk (14/01/2008 13:57)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Ещё ситуация. Допустим, сервис работает, работает, а потом замораживается. Если он был заморожен год назад, он может выдавать метки годичной давности. Что с этим делать?
— SATtva (14/01/2008 14:21)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Это как? Метки выдаются согласно системному времени, которое должно регулярно синхронизироваться с NTP-серверами.
— poptalk (14/01/2008 14:48)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Это как? Метки выдаются согласно системному времени, которое должно регулярно синхронизироваться с NTP-серверами.

Сервис мошеннический.
— SATtva (14/01/2008 15:23)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Слабо понимаю, о чём Вы говорите. Попробуйте привести пример. Но на всякий случай напоминаю, что связывание меток не защищает последнюю выданную метку от модификации/замены оператором сервиса. Если Вы способны запретить оператору незаметно перезаписывать опубликованные данные, то сможете это предотвратить (это может быть совместное заверение метки разными независимыми сервисами или публикация отчётов на ресурсе, где оператор сервиса меток не имеет права на изменение данных). Stamper с этой целью публиковал суточные отчёты в news-конференциях. Изменить их после опубликования, разумеется, невозможно.
— poptalk (14/01/2008 16:29)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Слабо понимаю, о чём Вы говорите. Попробуйте привести пример.

Сервис в некоторый момент перестаёт работать. Выдаёт "временно недоступен". Но на самом деле он выдаёт метки — мошенникам, которые заплатят. При этом выдаёт не текущей датой, а датой последней метки + одна миллисекунда (минимальная дискрета времени). То есть отодвигает метку как можно дальше в прошлое.

Можно ли с этим бороться?
— SATtva (14/01/2008 16:43)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Может я один такой непонятливый, но что с того? Пусть мошенники получают любое число меток. В чём это негативно скажется на легитимных метках? Или Вы говорите о подобии DoS-атаки, при которой сервис заваливается кучей мусорных запросов?
— Alex_B (14/01/2008 16:45)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Если злоумышленник получил информацию и раньше автора поставил метку времени — это не проблема сервиса, такие задачи он не решает.
— Alex_B (14/01/2008 17:20, исправлен 14/01/2008 17:21)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Я вот еще подумал. Автор с помощью PGP подписывает свое сообщение. Затем ставит метку времени на подписанный текст.

Получается выдаваемая метка времени будет иметь странный вид:



что же делать?
— SATtva (14/01/2008 17:27, исправлен 14/01/2008 17:29)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Нет, не так. Вот:



Что в этом плохого?
— poptalk (14/01/2008 18:14)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Может я один такой непонятливый, но что с того? Пусть мошенники получают любое число меток. В чём это негативно скажется на легитимных метках?

Дык ведь легитимная и нелегитимная ничем не отличаются! Никто не знает, что сервис продался.
— SATtva (14/01/2008 19:22)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Не пойму, Вы предлагаете сделать evil-bit, как в TCP? Пусть сервис помечает мошеннические метки специальным флагом. :-) Что вообще в данном случае подразумевается под мошенничеством?
— Alex_B (14/01/2008 23:04)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Тогда лучше вот так:



Или нет?
— SATtva (14/01/2008 23:24, исправлен 14/01/2008 23:27)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Нет, это нестандартный формат. Когда OpenPGP-программа сверяет подпись и выдаёт исходное заверенное сообщение, она удаляет лишние знаки тире (dash escaping) из вложенной подписи, после чего вложенную подпись можно аналогично сверить, т.е. сверять подписи рекурсивно. В Вашем случае придётся парсить ввод дополнительно, вырезая решётки. Тем более, это ведь не то, что пользователь давал на заверение изначально.

А dash escaping — экранирование знаков тире в начале строк — является частью стандарта.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3