id: Гость   вход   регистрация
текущее время 16:31 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 След.
Комментарии [скрыть комментарии/форму]
— Alex_B (14/01/2008 23:43, исправлен 14/01/2008 23:44)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Спасибо за информацию.
А знаки тире в сообщении пользователя должны ставиться только перед
BEGIN PGP SIGNED MESSAGE ,
BEGIN PGP SIGNATURE и
END PGP SIGNATURE

А "пользовательские данные (сообщение или ascii-кодированный файл)" не должны оформляться таким же способом?
— SATtva (14/01/2008 23:56)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Экранируются любые тире в начале подписанных строк. (В gpg есть опция для отключения экранирования (в основном используемая для заверения исходных текстов патчей), но она несовместима со стандартом. PGP, к примеру, корректно такую подпись не сверит.) А при повторном подписании будет экранироваться и сама экранировка:

— poptalk (15/01/2008 04:45)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Не пойму, Вы предлагаете сделать evil-bit, как в TCP? Пусть сервис помечает мошеннические метки специальным флагом. :-) Что вообще в данном случае подразумевается под мошенничеством?

Если два человека спорят, кто автор некоторой идеи, кто считается автором? Тот, кто зарегистрировал идею раньше. Поэтому дата метки времени важна.

Допустим, настощий автор зарегистрировал идею в момент T1, а потом опубликовал. Мошенник берёт идею, подписывает своим именем, и регистрирует в момент T2>T1, но на метке стоит дата T3<T1, благодаря тому, что сервис в сговоре.
— SATtva (15/01/2008 11:58)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Предположим, оператор действительно вступил в сговор с мошенником и выдал две метки: одну легитимную с правильной датой (Т1) и другую — нелегитимную с подложной датой (Т3).

Дальше сервис должен внести метку Т3 в свою базу — ой, номера меток и даты оказываются непоследовательны (поскольку Т3 была сгенерирована позднее, она будет иметь больший порядковый номер, но её дата по условию будет меньшей). Не забывайте, что вставить метку в базу "задним числом" (т.е. с меньшим порядковым номером) сервис не может благодаря связыванию по хэшам.

Допустим также, что оператор пошёл на самое крайнее нарушение протокола: он просто заверил подложную метку ключом сервиса, но не стал вносить её в базу ни в каком виде. Это с очевидностью будет раскрыто при возникновении конфликтной ситуации, поскольку метка с данным номером в базе сервиса не будет иметь ничего общего с представленной.

Ну и, наконец, как я уже говорил, сервис меток — это репутационная система. В любом из этих сценариев подлог с высокой вероятностью будет раскрыт. Это подорвёт доверие к сервису и сделает несостоятельными любые свидетельства, выданные им ранее, как легитимные, так и нет.
— poptalk (15/01/2008 16:12)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Предположим, оператор действительно вступил в сговор с мошенником и выдал две метки: одну легитимную с правильной датой (Т1) и другую — нелегитимную с подложной датой (Т3).

Дальше сервис должен внести метку Т3 в свою базу — ой, номера меток и даты оказываются непоследовательны (поскольку Т3 была сгенерирована позднее, она будет иметь больший порядковый номер, но её дата по условию будет меньшей). Не забывайте, что вставить метку в базу "задним числом" (т.е. с меньшим порядковым номером) сервис не может благодаря связыванию по хэшам.

Вы исходите из того, что сервис всего один. Представим, что оных много. Настоящий автор и мошенник пользовались разными сервисами. Мошеннический сервис до некоторого момента выдавал только легитимные метки, а после только нелегитимные. Соответственно, он выдаёт T3, но не T1.
— SATtva (15/01/2008 16:26)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Настоящий автор и мошенник пользовались разными сервисами.

Если это ключевой момент, то обратите внимание на формат метки, приведённый в документе, где URL сервиса является одним из важных полей. Впрочем, даже если бы его не было, разные сервисы заверяли бы метки разными ключами. Не вижу, как спутать метки, выданные разными сервисами. Каждый сервис отвечает исключительно за собственные выданные метки; остальные — это не его дело и не его ответственность.
— Alex_B (17/01/2008 19:23)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Прошу всех заинтерисованных еще раз посмотреть на формат сохраняемой сервисом метки. Можно ли считать данный вариант конечным?
— SATtva (17/01/2008 20:10)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
А который из вариантов? Я запутался. Там сейчас формат метаданных и формат итоговой компоновки с другим списком метаданных.
— Alex_B (17/01/2008 21:53)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Я подумал, что будет логичнее вынести версию протокола

первым пунктом.

Потом, поле

излишне, да и ключ пользователь должен получать из других источников.

Более ни каких изменений не вносил.

А который из вариантов?

Тот который сейчас.
— SATtva (18/01/2008 20:06)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
А который из вариантов?

Тот который сейчас.

Ещё раз посмотрите внимательно два блока кода наверху. Поля в одном: Timestamp-version, Signed-by, Timestamp, Number, Ref-Hash-SHA512, Ref-Hash-RIPEMD160, Hash-SHA512, Hash-RIPEMD160. Поля в другом: Timestamp-version, Description, Signed-by, Timestamp, Number, Hash-SHA512, Hash-RIPEMD160. Найдите три отличия. :-)
— Alex_B (18/01/2008 22:25)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Не очень понял о чем речь. Они разные.
В одном формате метки хранятся(публикуются) на сервере, в другом метка, для удобства использования, передается клиенту.
— SATtva (18/01/2008 23:51)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
А смысл? Вот я с ходу обратил внимание на такую "нестыковку". Хотите потом ежедневно получать по десять сообщений от таких же, как я, непонятливых пользователей? :-) А они будут, поверьте!

Почему бы не привести оба формата к общему знаменателю? К каким это приведёт потерям?
— serzh (19/01/2008 01:13)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Почему бы не привести оба формата к общему знаменателю? К каким это приведёт потерям?

Они всё равно будут отличаться, т.к. отсылаемые пользователю данные содержат оригинальный документ.
В данном случае с высылаемой пользователю метки удаляются все лишние поля, дабы не путать пользователя. А все поля необходимые для контроля находятся на сервере, а следить за их достоверностью будет гораздо меньше людей, понимающих что и как.
— Alex_B (19/01/2008 12:08)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
"Делай так просто, насколько возможно, но не проще." © не помню кто

Может все же действительно, перенсти все метаданные из сохраняемой метки времени в выдаваемую?

Нужно добавить всего-то два поля:
Ref-Hash-SHA512: (SHA512 хеш от предыдущей подписи)
Ref-Hash-RIPEMD160: (RIPEMD160 хеш от предыдущей подписи)

И все равно будет два формата – нельзя же на сервере хранить информацию пользователя.

И еще стоит ли подписывать храняющуюся метку времени?
— SATtva (19/01/2008 13:58)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Они всё равно будут отличаться, т.к. отсылаемые пользователю данные содержат оригинальный документ.

Это нерелевантно, пользователь будет этого ожидать.

В данном случае с высылаемой пользователю метки удаляются все лишние поля, дабы не путать пользователя.

Получается всё наоборот. :-)

Нужно добавить всего-то два поля:

Три, там Description ещё. Оно сильно место не сэкономит.

И еще стоит ли подписывать храняющуюся метку времени?

Каждую — не обязательно. Блоками (суточными) — надо.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3