id: Гость   вход   регистрация
текущее время 19:56 14/12/2019
Владелец: 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 След.
Комментарии [скрыть комментарии/форму]
— ntldr (23/12/2007 23:24)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Потому что это позволяет не раскрывать содержимое предыдущей подписи (которое пользователь сервиса может хотеть сохранить в тайне). Для проверки достаточно знать дату предыдущей подписи. В это случае лучше хранить даже не хеш, а саму дату, т.е. это будет более читабельно.
— serzh (24/12/2007 07:50)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
>>Ref-Hash: (SHA512 хеш от предыдущей подписи)
Лучше хэш-значение предыдущей метки.

А почему?

В подписи может быть использована более слабая функция хэширования.
— ntldr (28/12/2007 00:17)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
SHA1 из спецификации предлагаю выкинуть по причине его устарелости.
— serzh (28/12/2007 00:30)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
SHA1 из спецификации предлагаю выкинуть по причине его устарелости.

Он ещё не устарел и его можно было оставить для скорости, но впринципе согласен.
— poptalk (01/01/2008 21:32)   профиль/связь   <#>
комментариев: 259   документов: 12   редакций: 3
Почитал диалог, но так и не понял, обязательно сообщать сервису меток времени оригинальный документ, или достаточно хэша от этого документа?

Ведь если я передам оригинальный документ, что мешает сервису заменить в документе автора на другого? Если имя автора в док. будет прописываться стандартным образом, подмена автора может быть автоматической. :-( Борьба с плагиатом станет невозможной.

И, кстати, мошеннический сервис может выдать не только свою метку времени, но и получить метки на других серверах. Так что даже нельзя будет определить, кто из сервисов является М.
— serzh (01/01/2008 21:47)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Почитал диалог, но так и не понял, обязательно сообщать сервису меток времени оригинальный документ, или достаточно хэша от этого документа?

Достаточно хэша, хотя можно послать и документ.

Ведь если я передам оригинальный документ, что мешает сервису заменить в документе автора на другого? Если имя автора в док. будет прописываться стандартным образом, подмена автора может быть автоматической. :-( Борьба с плагиатом станет невозможной.

Легко проветь правильность работы сервиса, т.е. сервис рискует быть пойманым.

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

В метке содержится адрес сервиса.
— poptalk (01/01/2008 21:52, исправлен 01/01/2008 21:54)   профиль/связь   <#>
комментариев: 259   документов: 12   редакций: 3
Ведь если я передам оригинальный документ, что мешает сервису заменить в документе автора на другого? Если имя автора в док. будет прописываться стандартным образом, подмена автора может быть автоматической. :-( Борьба с плагиатом станет невозможной.

Легко проветь правильность работы сервиса, т.е. сервис рискует быть пойманым.

Так сервис и работает правильно, когда он подменяет автора. Подмена не противоречит правилам работы сервиса.
— serzh (01/01/2008 22:05)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Из данных, высылаемых пользователю, убрал следующие поля:
Ref-Hash-SHA512: (SHA512 хеш от предыдущей подписи)
Ref-Hash-RIPEMD160: (RIPEMD160 хеш от предыдущей подписи)

Они избыточны, т.к. для проверки цепочки всё равно нужно получать список меток.
— serzh (01/01/2008 22:07)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Так сервис и работает правильно, когда он подменяет автора. Подмена не противоречит правилам работы сервиса.

Противоречит, т.к. сервис должен заверять оригинальный документ.
— poptalk (02/01/2008 15:44)   профиль/связь   <#>
комментариев: 259   документов: 12   редакций: 3
Почитал диалог, но так и не понял, обязательно сообщать сервису меток времени оригинальный документ, или достаточно хэша от этого документа?

Достаточно хэша, хотя можно послать и документ.
...
Так сервис и работает правильно, когда он подменяет автора. Подмена не противоречит правилам работы сервиса.

Противоречит, т.к. сервис должен заверять оригинальный документ.

Только что вы говорили, что оригинальный документ посылать не обязательно, а теперь уже обязательно.
— poptalk (02/01/2008 16:05)   профиль/связь   <#>
комментариев: 259   документов: 12   редакций: 3
«Метки времени» образуют цепочку, в которой каждая последующая метка содержит доказательство, что выдана именно после предыдущей.

Таким доказательством является порядковый номер метки. Если порядковые номера только возрастают и занимают сплошной диапазон. Действительно ли нужны эти поля?:
Ref-Hash-SHA512: (SHA512 хеш от предыдущей подписи)
Ref-Hash-RIPEMD160: (RIPEMD160 хеш от предыдущей подписи)


Обосную свою точку зрения: сервис выдал мне метку с номером N1 и временем T1. Теперь сервис хочет создать метку задним числом, то есть со временем T2<T1 (и номером N2). Следовательно, N2<N1. Но весь диапазон 0.. N1 уже занят. (Отрицательные N запрещены. ;-) )
— poptalk (02/01/2008 16:10)   профиль/связь   <#>
комментариев: 259   документов: 12   редакций: 3
Для проверки цепочки штампов нужно будет получить предыдущий штамп по ссылке wwwhttp://signer.com/ref.php?id=Ref-Id, вычислить SHA512 от него, и сравнить с полем Ref-Hash текущего штампа.
Для ускорения проверки цепочки подписей можно выпускать предыдущие штампы в .zip архивах по 10000 штук в каждом.

Можно более гибко, разрешить запросы вида
http://signer.com/ref.php?min_id=Ref-Id&max_id=Ref-Id
а результат сжать штатным сжатием http.
— Гость (02/01/2008 17:47)   <#>
Только что вы говорили, что оригинальный документ посылать не обязательно, а теперь уже обязательно.
Не доверяете – посылайте хэш (но никто вас не обязывает это делать). В этом случае хэш и будет для сервиса "оригинальным документом" :)
— serzh (02/01/2008 18:18)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Таким доказательством является порядковый номер метки. Если порядковые номера только возрастают и занимают сплошной диапазон. Действительно ли нужны эти поля?:
Ref-Hash-SHA512: (SHA512 хеш от предыдущей подписи)
Ref-Hash-RIPEMD160: (RIPEMD160 хеш от предыдущей подписи)

Если я вступил в сговор со службой меток, то могу сначала "застолбить" себе место, а после заменить необходимую метку.
Связывающие хэши противостоят этой атаке.
— Alex_B (05/01/2008 17:32, исправлен 05/01/2008 17:32)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
сервис выдал мне метку с номером N1 и временем T1. Теперь сервис хочет создать метку задним числом, то есть со временем T2<T1 (и номером N2). Следовательно, N2<N1. Но весь диапазон 0.. N1 уже занят. (Отрицательные N запрещены. ;-) )
Сервис просто берет и заменяет одну метку времени на другую.
Нужна именно цепочка меток, где каждая метка связана с предыдущей и последующей.

Каждое заинтересованное лицо может сделать несколько «контрольных» меток времени и запомнить их. Потом клиенту достаточно проверить цепочку до такой сохраненной метки.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3