Принцип работы

< Все документы:

Оглавление документа:

Получение метки времени

Получение метки времени по URL

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

Для ускорения проверки отдельной метки времени

Получение метки времени

Для получения метки времени, клиент¹:

Посредством web-интерфейса или программы, отправляет сервису данные, подлежащие заверению.
Сервис формирует «метку времени»², содержащую данные согласно формату.

Ref-Hash-X = Hash-X (предыдущая метка времени)

Сервис публикует созданную «метку времени».
Сервис отправляет клиенту «метку времени» (возможен произвольный формат), подписанную прозрачной подписью.

Получение метки времени по URL

Идея: Клиент передает url страницы сайта, чтобы иметь возможность впоследствии доказать что было размещено на данной странице.
Обсуждение ведется на странице Получение метки времени по URL

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

Для доказательства факта обладания информацией в определенное время пользователь передает третьей стороне полученную от сервиса метку времени.

Для проверки подлинности представленной метки времени, заинтересованная сторона:

проверяет ЭЦП сервиса
запрашивает от сервиса цепочку меток времени, выданных ранее проверяемой до ближайшей «контрольной» метки.

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

Для ускорения проверки отдельной метки времени

В настоящий момент описанная ниже идея не используется

В конце недели стампер должен ставить свою метку (+ получать метки от других аналогичных сервисов) и публиковать файл в котором находятся:

хэши всех меток за неделю
хэш аналогичного файла за предыдущую неделю

Если выданных подписей за неделю больше 100, то дополнительно создаём промежуточный файл (неделя-хх-1.txt, неделя-хх-2.txt, ...).

В конце года стампер должен ставить свою метку (+ получать метки от других аналогичных сервисов) и публиковать файл в котором находятся:

хэши всех недельных файлов за год
хэш аналогичного файла за предыдущий год

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

¹Клиент — лицо или система, требующие точного заверенного времени для последующего аудита.
²Формат «метки времени» описан в соответствующем разделе.

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

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

На страницу: 1, 2, 3, 4 След.

Комментарии [скрыть комментарии/форму]

—	Alex_B (28/12/2007 16:32) профиль/связь <#> комментариев: 143 документов: 31 редакций: 143

Код чего должен быть крос платформенным? Клиент может быть написан на любом языке.

—	ntldr (28/12/2007 16:41) профиль/связь <#> комментариев: 371 документов: 19 редакций: 20

> Код чего должен быть крос платформенным?

Код всего. Может быть я захочу поставить свой сервер, а у меня как на зло там не окажеться windows? Или может быть я захочу зашить timestamp сервер в железку с мегабайтом памяти где стоит embeded linux?
Если код написан на си, то это все делается легко и просто. К тому же возникает куда меньше проблем с аудитом кода (ну не люблю я c# и ООП, как впрочем и большинство системщиков).

—	Alex_B (28/12/2007 17:07) профиль/связь <#> комментариев: 143 документов: 31 редакций: 143

ntldr, что ж, значит две альтернативные реализации.
Спортивный азарт, соперничество – хорошо, но не хотелось бы разладов. Проект открытый и фраза «Мы делаем», на мой взгляд, должна обозначать именно МЫ ДЕЛАЕМ.

Не хотелось бы сокрытия информации, перемещения обсуждения в кулуары, и всего такого прочего.

Да, не спорю мне открытое обсуждение и мнение участников нужнее, чем вам (и кто там еще стоит за этим «мы»), однако это не обозначает, что я не привношу ничего в проект. И, в любом случаи, я ощущаю себя одним из основателей проекта.

—	*Гость* (28/12/2007 17:31) <#>

ntldr, реализуйте "получение метки времени по URL". Просто скриншот браузера, а в адресе разрешён javaScript.

—	serzh (28/12/2007 17:46) профиль/связь <#> комментариев: 232 документов: 17 редакций: 99

Вопрос:
Как клиент узнает открытый ключ сервиса?
– на странице сервиса (Serzh)
– Откуда у пользователя уверенность, что ему не посунули подделку? Нужно как-то протащить ключ в сеть доверия, что бы каждый мог проверить. — Alex_B
– Оператор подписывает ключ службы своим персональным ключом, который связывается с сетью доверия всеми обычными способами. Или, если сайт службы работает по SSL, положиться на защищённость канала. А ещё лучше объединить оба способа. В общем, я здесь не вижу существенной проблемы. — SATtva

Почему следует использовать SHA512?
– используется несколько независимых хэш-функций (Serzh)
– вообще-то это не ответ на поставленный вопрос. ;-) на мой взгляд, использование RIPEMD-160 при наличии SHA-512 избыточно. можете привести хоть одну причину в её необходимости? — SATtva

Что непосредственно представляет из себя заверяемая информация?
– произвольная информация, которая (если изначально это не файл) компонуется в файл (Serzh)
– Мне кажется это должен быть произвольный файл. А как быть если пользователь захочет заверить уже готовый хеш – он записывает этот хеш в текстовый файл и заверяет уже этот файл?
– да, а если клиенту заверенные данные ещё нужно отпарсить? Зачем заставлять его делать лишние телодвижения при том, что необходимости в этом никакой нет? Считаю, что в ascii armor паковаться должны только двоичные файлы. — SATtva

Обсуждение перевожу на форум, дабы не создавать две паралельные ветки. На странице оставлю только вопросы.

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

Может быть я захочу поставить свой сервер, а у меня ~~как на зло~~ к счастью там не окажеться windows? =)

Не хотелось бы сокрытия информации, перемещения обсуждения в кулуары, и всего такого прочего.

В результате мы должны получить открытые спецификации, реализовать которые может каждый.

Почему следует использовать SHA512?
используется несколько независимых хэш-функций (Serzh)
вообще-то это не ответ на поставленный вопрос. ;-) на мой взгляд, использование RIPEMD-160 при наличии SHA-512 избыточно. можете привести хоть одну причину в её необходимости? — SATtva

Это требуется для долговременных меток (на несколько лет). Спустя несколько лет мы получим такую ситуацию: SHA512 – взломан, RIPEMD-160 – нет (или наоборот). Если мы использовали только адну хэш-функцию (взломаную), то доказать авторство на основе данной метки уже невозможно. Если одна функция ещё держится – то возможно. Поэтому необходимо добавлять все возможные принятые криптографическим сообществом хэш-функции.

—	ntldr (28/12/2007 18:58) профиль/связь <#> комментариев: 371 документов: 19 редакций: 20

> ntldr, реализуйте "получение метки времени по URL". Просто скриншот браузера, а в адресе разрешён javaScript.

К сожалению не знаю как реализовать скриншот броузера безопасным образом. Дело в том, что timestamp сервис черезвычайно критичен к безопасности, а безопасность большинства броузеров далеко не идеальна. Как вариант можно реализовать запуск броузера из под отдельной пользовательской учетки, но это не спасет от наличия в ОС дыр на повышение привилегий.
Если timestamp сервис обретет популярность, то рано или поздно он обязательно будет взломан через броузер, так как 0day уязвимости в них открываются каждый месяц.

—	*Гость* (28/12/2007 19:17) <#>

не знаю как реализовать скриншот броузера безопасным образом

А виртуализаторы чем плохи? Под какой-нибудь ОpenBSD.

—	*Гость* (28/12/2007 19:23) <#>

не знаю как реализовать скриншот броузера безопасным образом

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

—	ntldr (28/12/2007 19:23) профиль/связь <#> комментариев: 371 документов: 19 редакций: 20

> А виртуализаторы чем плохи?

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

—	*Гость* (29/12/2007 18:54) <#>

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

Да бросьте вы, виртуализаторы нынче быстрые, ось можно минимизировать (чтобы только браузер запускала), да и диск можно виртуальный (в оперативной памяти) сделать.

Даде лучше три диска – на одном идет обработка запроса, а на второй в это время копируется первоначальный образ (с уже запущенным браузером) с третьего. Потом первый и второй меняются местами.

Но вот только что по этому поводу скажет хостинг-провайдер...

—	SATtva (29/12/2007 20:54, исправлен 29/12/2007 20:56) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Вообще это странное обсуждение, по-моему. До сих пор нет формализации протокола, нет чётко обозначенного списка решаемых протоколом задач, нет модели угрозы, нет готовой спецификации формата. А вы уже о языке реализации спорите. Если сделать всё вышеперечисленное, то язык вообще не будет играть роли: каждый может писать на том, что нравится или больше подходит. Главное, что в этом случае у всех всё будет работать и работать будет одинаково.

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

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

Делать виртуальную машину ради одной этой функции мне видится ошибочным: корректную настройку получить будет чрезвычайно трудно, к тому же это с высокой вероятностью привяжет к специфическому ПО. Да и слабо я себе представляю заверение такого скриншота: здесь уже отмечалось, что мало текстовых страниц уместится в одном окне браузера. Если уж хочется что-то подобное, достаточно загрузить и заверить html, ибо графика, как правило, почти никогда не несёт смысловой нагрузки и на динамических сайтах меняется реже.

—	*Гость* (30/12/2007 07:25) <#>

мало текстовых страниц уместится в одном окне браузера.

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

достаточно загрузить и заверить html, ибо графика, как правило, почти никогда не несёт смысловой нагрузки и на динамических сайтах меняется реже.

Это всё придумывается из-за AJAX. В простых случаях конечно лучше html.

—	Alex_B (30/12/2007 22:43) профиль/связь <#> комментариев: 143 документов: 31 редакций: 143

мало текстовых страниц уместится в одном окне браузера.

О каком окне браузера идет речь?

Это всё придумывается из-за AJAX

Да и это не выход, не даром поисковики не индексируют сайты поностью на Ajax или flash. Что если информация подгружается только при определенных действиях пользователя (например на кнопку нажать)...

—	*Гость* (31/12/2007 03:13) <#>

Что если информация подгружается только при определенных действиях пользователя (например на кнопку нажать)...

Вот пусть сам пользователь в запросе (на javaScript) и задаёт нужные ему действия.

—	*Гость* (31/12/2007 12:22) <#>

Вот пусть сам пользователь в запросе (на javaScript) и задаёт нужные ему действия.

Т.е. я пишу скрипт который заменяет содержимое, скажем блока div с каким-нибудь id, на произвольную информацию. Иду на такой сервис и он все это проделывает и дает мне доказательство...

Впринципе можно не слишком беспокоиться насчет ajax, поисковиков же это не заботит.

На страницу: 1, 2, 3, 4 След.

Ваша оценка документа [показать результаты]