Принцип работы
Получение метки времени
Для получения метки времени, клиент1:
- Посредством web-интерфейса или программы, отправляет сервису данные, подлежащие заверению.
- Сервис формирует «метку времени»2, содержащую данные согласно формату.
- Сервис публикует созданную «метку времени».
- Сервис отправляет клиенту «метку времени» (возможен произвольный формат), подписанную прозрачной подписью.
Получение метки времени по URL
Идея: Клиент передает url страницы сайта, чтобы иметь возможность впоследствии доказать что было размещено на данной странице.
Обсуждение ведется на странице Получение метки времени по URL
Проверка метки времени
Для доказательства факта обладания информацией в определенное время пользователь передает третьей стороне полученную от сервиса метку времени.
Для проверки подлинности представленной метки времени, заинтересованная сторона:
- проверяет ЭЦП сервиса
- запрашивает от сервиса цепочку меток времени, выданных ранее проверяемой до ближайшей «контрольной» метки.
Каждое заинтересованное лицо может сделать несколько «контрольных» меток времени и запомнить их. Потом достаточно проверить цепочку до такой сохраненной метки, а также совпадение сохраненной метки с меткой представленной сервисом.
Для ускорения проверки отдельной метки времени
В настоящий момент описанная ниже идея не используется
В конце недели стампер должен ставить свою метку (+ получать метки от других аналогичных сервисов) и публиковать файл в котором находятся:
- хэши всех меток за неделю
- хэш аналогичного файла за предыдущую неделю
Если выданных подписей за неделю больше 100, то дополнительно создаём промежуточный файл (неделя-хх-1.txt, неделя-хх-2.txt, ...).
В конце года стампер должен ставить свою метку (+ получать метки от других аналогичных сервисов) и публиковать файл в котором находятся:
- хэши всех недельных файлов за год
- хэш аналогичного файла за предыдущий год
Для проверки нужной метки проходим (проверяем хэши) от последней выданной метки до первого "недельника", далее с шагом в неделю идём до первого "годовика" доходим до нужного года и начинаем сбавлять шаг сначала до недели, а потом и до отдельных меток.
идея Serzh
1Клиент — лицо или система, требующие точного заверенного времени для последующего аудита.
2Формат «метки времени» описан в соответствующем разделе.
© 2009 Kent
© 2007 SATtva, ntldr
© 2009 Анонимные пользователи
Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike
комментариев: 371 документов: 19 редакций: 20
комментариев: 11558 документов: 1036 редакций: 4118
Добро пожаловать в мир XSS-атак.
комментариев: 232 документов: 17 редакций: 99
Описание с сайта:
В результате работы получаем zip архив.
комментариев: 371 документов: 19 редакций: 20
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 271 документов: 13 редакций: 4
Правильная — это та, которая противостоит всем атакам. Сначала надо определиться с возможными атаками.
комментариев: 271 документов: 13 редакций: 4
Возможна такая вариация алгоритма:
Каждая метка времени с порядковым номером Number, кратным 10, хранит дополнительное поле Ref-Hash-10, содержащее хэш метки, которая находится на 10 шагов назад. Если порядковый номер кратен 100, то дополнительное поле Ref-Hash-100 хранит хэш метки, которая находится на 100 шагов назад. И так далее.
Так можно организовать короткие пути между метками.
комментариев: 143 документов: 31 редакций: 143
Таким образом получается что связывание "меток времени" как бы подкреплено несколькими алгоритмами хеширования.
Причем было отдельно оговорено что хеш предыдущей метки считается от метаданных, а не от ЭЦП. Так как если считать хоть пять разных хешей (используя разные алгоритмы) только от ЭЦП, то фактически надежность связывание все равно будет зависеть от одного алгоритма хеширования, того который используется при формировании ЭЦП.
Внимание вопрос:
Немного поразмыслив пришел к выводу что служба «меток времени» может осуществлять свою деятельность вообще не используя ЭЦП. Достаточно только сохранять хеши и порядковые номера, в общем все метаданные – без ЭЦП.
Вроде что-то подобное уже обсуждалось.
Так ли это? Зачем вообще было использовать ЭЦП, только для удобства пользователя – что бы выдавать ему сертификаты которые моно проверить не получая цепочку от сервиса?
комментариев: 11558 документов: 1036 редакций: 4118
Именно за этим.
комментариев: 271 документов: 13 редакций: 4
Не хочу показаться назойливым, :) но я как раз и предлагал разделить на два сервиса: вычисление хэшей одно, подписывание времени (показания часов) другое. Просто так сложнее.
"В публикацию идут только порядковый (серийный) номер метки, её дата/время и цифровая подпись этих данных" – как тогда проверить, на какую именно информацию выдана данная метка времени?