id: Гость   вход   регистрация
текущее время 15:52 29/03/2024
Владелец: 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 След.
Комментарии [скрыть комментарии/форму]
— Alex_B (24/12/2007 14:36)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
serzh, надо бы мне побыстрей раскачиваться – а то все за меня сделают :)

Т.е. сервис заверяет только строковую информацию?

Какого же размера могут получаться эти "метки времени"? А ведь их нужно хранить.
Кстати как посоветуете хранить – в базе или просто текстовые файлы?
— SATtva (24/12/2007 15:41)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Какого же размера могут получаться эти "метки времени"? А ведь их нужно хранить.

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

  1. Сервер заверяет своей подписью пользовательский ввод (каким бы он ни был) и метаданные предыдущей метки времени.
  2. Сервер подписывает подпись (хэш подписи) из п.1 (не сами заверенные данные) и публикует результат в базе выданных меток. Именно эта итоговая подпись или её хэш добавляется к последующей метке.

Напомню, что Stamper вообще использовал два ключа. Одним ключом заверялись метки времени (п.1), а другим — связанные отчёты и аудиторский след (п.2).
— Alex_B (24/12/2007 16:41)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Сервер заверяет своей подписью пользовательский ввод (каким бы он ни был) и метаданные предыдущей метки времени.
Пользователь может подписать не строковую информацию? Может он файл целиком подписать?

Сервер подписывает подпись (хэш подписи) из п.1 (не сами заверенные данные) и публикует результат в базе выданных меток. Именно эта итоговая подпись или её хэш добавляется к последующей метке
Сервис хранит вот такого вида информацию:
  1. Номер текущей "метки времени"
  2. хеш подписи предыдущей метки
  3. Подпись информации из 1 и 2 на секретном ключе сервиса

так?
— SATtva (24/12/2007 16:54)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Пользователь может подписать не строковую информацию? Может он файл целиком подписать?

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



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

Сервис хранит вот такого вида информацию: ... так?

Да, вроде того.
— serzh (24/12/2007 18:51)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Доверие к SSL весьма невелико, так как достаточно получить поддельный сертификат от любого СЦ (коих много) для дискредитации всей этой системы. OpenPGP использовать нужно обязательно.

Дискредитации системы не будет. В данном случае SSL/OpenPGP/X.509 используется для гарантированного получения сервисом оригинальных данных. Я просто хочу подчеркнуть: если данные дошли до сервиса, то задача SSL/OpenPGP/X.509 выполненна.

OpenPGP/X.509 конечно нужно использовать, хотя бы для простоты предоставления информации третьей стороне.

Кстати при утере подписанного пакета или компроментации/замене ключа сервиса, можно попросить получить копию заверения метки.
В данном случае хороша простота и независимость от других стандартов.
— ntldr (24/12/2007 21:17)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

Вопрос только в том, дошли ли эти данные в неизменном виде :)
— serzh (25/12/2007 03:17)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
А как быть если пользователь захочет заверить уже готовый хеш – он записывает этот хеш в текстовый файл и заверяет уже этот файл?

В заверении готовых хэшей есть проблема, а именно подстановка под видом хэша рекламы (ссылки на сторонний сайт) и т.д., что создаёт ненужную нагрузку и провацирует спамеров. Следовательно всегда нужно вычислять хэш полученных данных. Хотя признаю, что некоторые неудобства это может создавать.
— serzh (28/12/2007 02:46)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Давайте определимся на каком языке лучше реализовать.
Я за bash, который вызывается чем угодно =)
— ntldr (28/12/2007 06:27)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Имхо CGI приложение на си.
BASH не может обеспечивать сериализацию операций, и при большом числе пользователей сервиса будут возникать странные глюки и хериться файлы.
— Alex_B (28/12/2007 15:20)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
я за C#
— Alex_B (28/12/2007 16:10)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Если возражений по поводу меня в качестве исполнителя нет, то обсуждение на каком языке реализовывать продолжать не стоит – уже и билиотеку нашел и разобрался как работает, и т.п. – вобщем C#.

Если есть возражения, лучше сообщите их сейчас.
— ntldr (28/12/2007 16:14)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Категорически против C#. Этот недоязык не имеет в данной задаче никаких преимуществ, но привязывает нас к Windows и . NET framework. К тому же я не доверяю безопасности сетевого софта на .net, так как работать с сетью он будет через классы от Microsoft, а всем печально известна безопасность кода от этой фирмы.
К тому же код должен быть кроссплатформенным, и если бы не проблема сериализации, то лучше всего бы подошел php.
— ntldr (28/12/2007 16:16)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

Значит мы делаем альтернативный сервис на си. Вопрос использования C# это вопрос доверия к Microsoft. У меня к этой фирме очень мало доверия.
— Alex_B (28/12/2007 16:27)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Есть проект mono для unix.
— Гость (28/12/2007 16:31)   <#>
Наверно, лучше будет. сначала четко построить и написать формальный алгоритм.
А потом уж приняться за трансляцию этого алгоритма на какой-либо язык программирования, и тут уж кто на чем может/хочет на том и пишет, это не принципиально.

Но согласен с ntldr, реализовать сие на практике как CGI приложение на си кажеться наиболее благоразумным. Хотя сам хотел бы иметь реализацию на bash, для маленькой сети.

Экзотика типа C# здесь не желательна. Лучше либо C/C++, либо какой-нибудь популярный скриптовый язык со стабильным и быстрым интерпретатором.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3