Принцип работы
Получение метки времени
Для получения метки времени, клиент1:
- Посредством web-интерфейса или программы, отправляет сервису данные, подлежащие заверению.
- Сервис формирует «метку времени»2, содержащую данные согласно формату.
- Сервис публикует созданную «метку времени».
- Сервис отправляет клиенту «метку времени» (возможен произвольный формат), подписанную прозрачной подписью.
Получение метки времени по URL
Идея: Клиент передает url страницы сайта, чтобы иметь возможность впоследствии доказать что было размещено на данной странице.
Обсуждение ведется на странице Получение метки времени по URL
Проверка метки времени
Для доказательства факта обладания информацией в определенное время пользователь передает третьей стороне полученную от сервиса метку времени.
Для проверки подлинности представленной метки времени, заинтересованная сторона:
- проверяет ЭЦП сервиса
- запрашивает от сервиса цепочку меток времени, выданных ранее проверяемой до ближайшей «контрольной» метки.
Каждое заинтересованное лицо может сделать несколько «контрольных» меток времени и запомнить их. Потом достаточно проверить цепочку до такой сохраненной метки, а также совпадение сохраненной метки с меткой представленной сервисом.
Для ускорения проверки отдельной метки времени
В настоящий момент описанная ниже идея не используется
В конце недели стампер должен ставить свою метку (+ получать метки от других аналогичных сервисов) и публиковать файл в котором находятся:
- хэши всех меток за неделю
- хэш аналогичного файла за предыдущую неделю
Если выданных подписей за неделю больше 100, то дополнительно создаём промежуточный файл (неделя-хх-1.txt, неделя-хх-2.txt, ...).
В конце года стампер должен ставить свою метку (+ получать метки от других аналогичных сервисов) и публиковать файл в котором находятся:
- хэши всех недельных файлов за год
- хэш аналогичного файла за предыдущий год
Для проверки нужной метки проходим (проверяем хэши) от последней выданной метки до первого "недельника", далее с шагом в неделю идём до первого "годовика" доходим до нужного года и начинаем сбавлять шаг сначала до недели, а потом и до отдельных меток.
идея Serzh
1Клиент — лицо или система, требующие точного заверенного времени для последующего аудита.
2Формат «метки времени» описан в соответствующем разделе.
© 2009 Kent
© 2007 SATtva, ntldr
© 2009 Анонимные пользователи
Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike
комментариев: 143 документов: 31 редакций: 143
Т.е. сервис заверяет только строковую информацию?
Какого же размера могут получаться эти "метки времени"? А ведь их нужно хранить.
Кстати как посоветуете хранить – в базе или просто текстовые файлы?
комментариев: 11558 документов: 1036 редакций: 4118
На сервере пользовательская информация не должна храниться. Это, помимо прочего, нарушение конфиденциальности.
Напомню, что Stamper вообще использовал два ключа. Одним ключом заверялись метки времени (п.1), а другим — связанные отчёты и аудиторский след (п.2).
комментариев: 143 документов: 31 редакций: 143
Сервис хранит вот такого вида информацию:
так?
комментариев: 11558 документов: 1036 редакций: 4118
Технически это возможно. Единственная проблема, что придётся изловчиться, чтобы как-то впихнуть туда же и связку с предыдущей меткой. Можно сделать так (не самое оптимальное решение, может быть кто-то придумает лучше):
Этим будет сгенерирован литеральный пакет, который затем можно обработать прозрачной подписью, как обычные строковые данные.
Да, вроде того.
комментариев: 232 документов: 17 редакций: 99
Дискредитации системы не будет. В данном случае SSL/OpenPGP/X.509 используется для гарантированного получения сервисом оригинальных данных. Я просто хочу подчеркнуть: если данные дошли до сервиса, то задача SSL/OpenPGP/X.509 выполненна.
OpenPGP/X.509 конечно нужно использовать, хотя бы для простоты предоставления информации третьей стороне.
Кстати при утере подписанного пакета или компроментации/замене ключа сервиса, можно попросить получить копию заверения метки.
В данном случае хороша простота и независимость от других стандартов.
комментариев: 371 документов: 19 редакций: 20
Вопрос только в том, дошли ли эти данные в неизменном виде :)
комментариев: 232 документов: 17 редакций: 99
В заверении готовых хэшей есть проблема, а именно подстановка под видом хэша рекламы (ссылки на сторонний сайт) и т.д., что создаёт ненужную нагрузку и провацирует спамеров. Следовательно всегда нужно вычислять хэш полученных данных. Хотя признаю, что некоторые неудобства это может создавать.
комментариев: 232 документов: 17 редакций: 99
Я за bash, который вызывается чем угодно =)
комментариев: 371 документов: 19 редакций: 20
BASH не может обеспечивать сериализацию операций, и при большом числе пользователей сервиса будут возникать странные глюки и хериться файлы.
комментариев: 143 документов: 31 редакций: 143
комментариев: 143 документов: 31 редакций: 143
Если есть возражения, лучше сообщите их сейчас.
комментариев: 371 документов: 19 редакций: 20
К тому же код должен быть кроссплатформенным, и если бы не проблема сериализации, то лучше всего бы подошел php.
комментариев: 371 документов: 19 редакций: 20
Значит мы делаем альтернативный сервис на си. Вопрос использования C# это вопрос доверия к Microsoft. У меня к этой фирме очень мало доверия.
комментариев: 143 документов: 31 редакций: 143
А потом уж приняться за трансляцию этого алгоритма на какой-либо язык программирования, и тут уж кто на чем может/хочет на том и пишет, это не принципиально.
Но согласен с ntldr, реализовать сие на практике как CGI приложение на си кажеться наиболее благоразумным. Хотя сам хотел бы иметь реализацию на bash, для маленькой сети.
Экзотика типа C# здесь не желательна. Лучше либо C/C++, либо какой-нибудь популярный скриптовый язык со стабильным и быстрым интерпретатором.