id: Гость   вход   регистрация
текущее время 19:28 20/04/2018
Владелец: Alex_B (создано 19/12/2007 17:43), редакция от 03/09/2009 08:30 (автор: Kent) Печать
Категории: инфобезопасность, политика, разное
создать
просмотр
редакции
ссылки

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

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

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


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


  1. Посредством web-интерфейса или программы, отправляет сервису данные, подлежащие заверению.
  2. Сервис формирует «метку времени»2, содержащую данные согласно формату.
Ref-Hash-X = Hash-X (предыдущая метка времени)
  1. Сервис публикует созданную «метку времени».
  2. Сервис отправляет клиенту «метку времени» (возможен произвольный формат), подписанную прозрачной подписью.

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


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

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


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


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

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

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


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


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


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

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

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


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

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

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



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


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

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

 
На страницу: 1, 2, 3, 4 След.
Комментарии [скрыть комментарии/форму]
— Гость (20/12/2007 13:44)   <#>
удостоверяется что общается именно с тем сервисом, который ему нужен
Чем SSL плох?

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

сертификат может пригодится в будущем для разграничения прав доступа к услугам сервиса

Непонятно зачем это, если не для будущей коммерции. Почему бы не сделать как у stamper'а (добаваив связывание меток), хотя бы в качестве альтернативы.

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

Ещё хотелось бы получать метку времени на http-запрос, заданный клиентом. Можно даже, опционально, через анонимизирующую сеть. Просто выдаётся подпись на <запрос, ответ, время>, и пусть сам клиент думает, как ему использовать эти данные (если был указан динамический сайт)
— Alex_B (20/12/2007 15:17, исправлен 20/12/2007 15:18)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143

Стоит денег, а во вторых хотелось использовать альтернативное децентрализованное решение. Основная идея в статье ""Управление идентификацией посредством PGP"".


Ну вобщем да, нужно сфокусироваться на чем-то одном – или система идентификации или сервис меток. Видимо пока не стоит думать на тему "Сертификата доступа".


Да, спасибо.


Что это значит, распишите подробнее.


SATtva, никак не пойму как сервис может выдать сертификат, если клиент к нему не подключен? При выдачи сертификата нужна уверенность что у клиента есть секретный ключ соответствующий предоставленному открытому. Иначе возможно приписать любому ложное высказывание. Какая схема будет лучше?
— Гость (20/12/2007 16:14)   <#>
Ещё хотелось бы получать метку времени на http-запрос, заданный клиентом. Можно даже, опционально, через анонимизирующую сеть. Просто выдаётся подпись на <запрос, ответ, время>, и пусть сам клиент думает, как ему использовать эти данные (если был указан динамический сайт)
Что это значит, распишите подробнее.
Хотелось бы возможность иметь заверенные меткой времени "скриншоты" интернет-страниц, чтобы можно было доказать, что на них было то что было. Для этого клиент даёт вам ссылку на интересующую его страницу.

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

Случай динамических сайтов, выдающих на один и тот же запрос разный ответ пусть заботит самого клиента – вы подписываетесь только за один запрос.
— Гость (20/12/2007 16:23)   <#>
"скриншоты" интернет-страниц

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

клиент сам может составить цепочку "прокси" в запросе
Доверие к цепочке не больше, чем доверие к самому "подозрительному" её звену.
— SATtva (20/12/2007 16:42)   профиль/связь   <#>
комментариев: 11524   документов: 1036   редакций: 4050
Alex_B, пожалуйста, используйте общепринятые термины. "Сертификат авторства" мало того, что к ним не относится (можно вообще задуматься, что подразумевается как под "сертификатом", так и под "авторством"), ещё неявно накладывает ограничения на цели использования службы. Кроме того, от такого названия ползёт туча юридических неоднозначностей (поскольку ни одна служба меток времени не может доказать/сертифицировать "авторство", как таковое); не повторяйте ошибку криптологов, обозвавших своё изобретение "цифровой подписью". Если речь о метках времени, то так их и называйте.

никак не пойму как сервис может выдать сертификат, если клиент к нему не подключен?

В Unix клиент может написать скрипт, использующий wget или curl для отправки HTTP(S)-запроса на URL службы и получения метки времени на любые данные.

Если под "подключением" имеется в виду предварительная аутентификация клиента и установление сессии, то я не вижу в этом никакого прока. Зачем вообще аутентифицировать клиента? Если в модель угрозы вводить товарища Мэллори, который перехватывает запрос клиента и пересылает его от своего имени (скажем, желая сплагиатить тот материал, который отправляет клиент), но нет желания использовать SSL как контрмеру, схему всё равно можно упростить до одного прохода:

  1. Клиент отправляет серверу:
EKs( SKc( [Kc|fprKc], P ) )
Здесь EKs — зашифрование ключом сервера, SKc — подписание ключом клиента, [Kc|fprKc] — открытый ключ клиента или его отпечаток, P — данные, подлежащие заверению.

  1. Сервер возвращает клиенту:
EKc( SKs( P ) )
Я исхожу из того, что используется подпись OpenPGP, т.е. SKs уже содержит криптографически заверенную метку времени сервера.

Хотя мне даже такая схема представляется избыточной. Но в любом случае здесь клиентские запросы могут быть автоматизированы, поскольку он лишь отправляет запрос и получает ответ, не выполняя никакого анализа.
— ntldr (20/12/2007 17:07)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Хотелось бы возможность иметь заверенные меткой времени "скриншоты" интернет-страниц, чтобы можно было доказать, что на них было то что было. Для этого клиент даёт вам ссылку на интересующую его страницу.

+1, это очень нужная и полезная возможность.
— Alex_B (20/12/2007 17:19)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
SATtva, я не "варюсь" в этой теме достаточно времени, что бы обрасти общепринятыми терминами, спасибо за любые поправки и замечания. (Весь кластер позже перепишу)

Понял, действиельно лучше с одним проходом.

Т.е. никакой вот этой мути не надо?


А кто будет "клиентом" предоставляющим информацию? Кого вписывать в "метку времени"?
("метка времени" – она же "сертификат авторства", далее все перепишу в единой терминалогии).
— Гость (20/12/2007 17:36)   <#>
А кто будет "клиентом" предоставляющим информацию? Кого вписывать в "метку времени"?
Я не настаиваю на терминах. Хотнлось бы вводить в web-интерфейсе адрес страницы, а в ответ получать её содержимое+время, подписанное ключом сервиса.
— ntldr (20/12/2007 17:40, исправлен 20/12/2007 17:44)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Все нужно максимально упростить. Очень прошу не изобретать самому никаких протоколов и форматов, а использовать для защиты соединения TLS v1, а для подписи меток времени – OpenPGP.
Сами метки должны иметь исключительно текстовый формат, без всяких нынче модных XML.

Использование общепринятых форматов есть огромный плюс для сервиса такого рода. Создание же всех протоколов и форматов с нуля затрудняет использование сервиса, создает проблемы совместимости и вызывает сомнения в безопасности реализации. И еще раз призываю вас все максимально упростить. Чем проще это будет устроено – тем лучше.
— Гость (20/12/2007 18:24)   <#>
Сами метки должны иметь исключительно текстовый формат, без всяких нынче модных XML.
ХML есть просто стандартный язык форматирования, иначе вам придётся изобретать собственный, нестандартный "язык". Всё равно надо будет указывать, где подписанный текст, подпись, время, имя службы, хэш предыдущего, ... Почему бы не сделать это стандартным образом?
"Зачем изобретать велосипед"?
— ntldr (20/12/2007 18:59)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

И чем же XML с нестандартными (придумаными вами полями) будет "стандартнее" обычного текста с CRLF разделителями? Например
Name1: Value1
Name2: Value2
...

Зато такой текстовый формат гораздо читабельнее. Подписи должны быть понятны человеку, и не должно быть необходимости использования дополнительного софта для их проверки. В случае же автоматизации, парсинг подобного формата ничем не сложнее (даже проще) парсинга XML. К тому же этот формат компактнее, что может оказаться актуальным при проверке большого числа подписей.
Не зря ведь в подобном виде представляются HTTP запросы. HTTP протокол умные люди делали, берите с них пример.
— Alex_B (20/12/2007 19:23)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Что бы не раздваивать по сути одну тему – формат "метки времени", прошу обсуждение данного вопроса перенести на соответствующую страницу.
— SATtva (20/12/2007 22:52)   профиль/связь   <#>
комментариев: 11524   документов: 1036   редакций: 4050
SATtva, я не "варюсь" в этой теме достаточно времени, что бы обрасти общепринятыми терминами, спасибо за любые поправки и замечания.

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


Т.е. никакой вот этой мути не надо?

Нет, муть в виде дополнительных полей нужна, я её здесь опустил для наглядности. Но, как и ntldr, я болею за plaintext-формат, не сторонник я лишних сложностей. Главным образом, это упростит проверку меток времени без привлечения дополнительного софта (или дополнительных телодвижений по воссозданию plaintext-сообщения, сверяемого PGP).

Использование общепринятых форматов есть огромный плюс для сервиса такого рода. Создание же всех протоколов и форматов с нуля затрудняет использование сервиса, создает проблемы совместимости и вызывает сомнения в безопасности реализации. И еще раз призываю вас все максимально упростить. Чем проще это будет устроено – тем лучше.

Поддерживаю.
— serzh (24/12/2007 07:41)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Предлагаю базовую реализацию на bash.
Файл timestamp:



Замечания:
1. Меткой времени является файл <номер>.txt (общедоступный). Сообщение, высылаемое пользователю, может содержать дополнительные данные любого характера.
2. Связка меток идёт по нескольким хэш-функциям (необходимо добавить хэш с альтернативной архитектурой RIPEMD160), т.е. при взломе одной функции цепочка сохранится. Ключа службы может вообще не быть (при использовании SSL).
3. При появлении новых (взломе старых) хэш-функций их список можно редактировать "на лету". При взломе всех хэш-функций, используемых в самом начале, отбраковывается только часть цепочки (от начала до первой метки с новой хэш-функцией).
© 2007 Serzh, лицензия: CC-BY-SA

P. S. Кто в теме с лицензированием, тот поймёт =)
— ntldr (24/12/2007 10:52)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

Доверие к SSL весьма невелико, так как достаточно получить поддельный сертификат от любого СЦ (коих много) для дискредитации всей этой системы. OpenPGP использовать нужно обязательно.
Далее, названия полей лучше делать без пробелов. Тогда они лучше будут поддаваться парсингу и не будут недонозначны (т.к. зачастую трудно отличить пробелы от табов).
Хеш от пользовательских данных не нужно передавать в заголовке. Нужно передавать сами пользовательские данные в виде текста внутри подписаного сообщения. В этом случае проверка подписи не потребует лишних телодвижений ввиде сохранения пользовательских данных в отдельный файл и подсчета их хеша. Ну а если надо подписать файл, то пользователь может указать хеш собственноручно.
Т.е. поле пользовательских данных целиком заполняется пользователем, а замена полных данных на хеш приводит к снижению юзабельности сервиса.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3