Формат метки времени
Введение
Метка времени – это подписанный (ЭЦП) сертификат, содержащий штамп времени, выдаваемый сервисом меток времени. С помощью такого сертификата можно установить факт существования информации в засвидетельствованный момент времени.
«Метки времени» образуют цепочку, в которой каждая последующая метка содержит доказательство, что выдана именно после предыдущей (в метку включается хеш предыдущей). Таким образом, снижается риск фальсификации «метки времени» — если сервис выдаст «метку времени» задним числом, это можно будет обнаружить.
Использования связывания «меток времени» позволяет вам контролировать сервис.
Цепочка меток времени – последовательность «меток времени», где каждая последующая «метка времени» имеет доказательство, что была выдана именно после предыдущей.
Формат метки времени
Примечание: Хеш значение атрибута Ref-Hash считается от следующей части предыдущей метки:
Немного подробнее формат "меток времени" описан в статье Формат «Меток времени»
p.s. Для упрощения в настоящий момент упразднил два формата меток времени.
© 2007 ntldr
© 2008 poptalk
© 2009 Анонимные пользователи
Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike
комментариев: 143 документов: 31 редакций: 143
комментариев: 271 документов: 13 редакций: 4
однозначно неверен. Нет связывания хэшей.
комментариев: 232 документов: 17 редакций: 99
Либо от всей метки, либо от данной части (метка без подписи):
Лучше использовать хэш метки без подписи (аргументы я уже говорил раньше), хотя допустимо и подсчёт хэша от целой метки.
комментариев: 143 документов: 31 редакций: 143
Берете предыдущую метку, смотрите поле Hash и сравниваете с Ref-Hash текущей метки.
Если совпали, значит метки идут друг за другом.
За целостность меток отвечает ЭЦП.
Например админ сервиса меняет в одной из меток поле Hash на другое (выгодное ему) значение. Цепочка оказывается разорванной – ведь в следующей метке поле Ref-Hash не будет совпадать с помененным задним числом значением.
serzh, понял, спасибо.
комментариев: 271 документов: 13 редакций: 4
Потому что тогда возможна вставка меток в середину цепочки. ЭЦП, конечно, защищает от фальсификации со стороны клиента, но не защищает со стороны владельца сервиса, который владеет ключом шифрования. Да вот, собственно, ответ на ваш вопрос.
Пример:
было:
Ref-Hash: 1
Hash: 2
Ref-Hash: 2
Hash: 3
стало:
Ref-Hash: 1
Hash: 2
Ref-Hash: 2
Hash: 4
Ref-Hash: 4
Hash: 3
А вообще-то именно вы сказали мне, что должно быть связывание хешэй, когда я предлагал от него отказаться. :-)
Думаю что после переписи код будет не стыдно открывать + программка для удаленного администрирования (загрузка ключей, смена шаблона и т.п.).
Вопрос:
1. Кому-нибудь нужно API доступа к сервису? (Скорее всего SOAP)
2. Кому-нибудь нужен код сервиса? (Инсталлятор, клиент для администрирования и немного документации)?
SATtva, уже поднимал этот вопрос, но он вроде бы остался без ответа.
3. Как децентрализовать сервис? (Этот вопрос интересует больше всего)
комментариев: 11558 документов: 1036 редакций: 4118
Ну, вот, я жду уже какое-то время.
По меньшей мере, надо расширить формат метки, чтобы она могла включать заверенные хэши от других аналогичных служб. Детали продумывать сейчас лень, к тому же, мы здесь где-то это уже обсуждали, полистайте дискуссии.
И код в этом случае, само собой, пригодится. Единственная его проблема, что заточен под Венду, так большое число желающих ставить его в оригинальном виде вряд ли найдётся.
Могу попробовать на Mono написать. C привязкой к БД вопрос тоже решается — всякие Hibernate. Только бы в этом был смысл.
Если и Mono не устраивает — как вариант, можно на Java перейти.
комментариев: 11558 документов: 1036 редакций: 4118
Я не вижу необходимости переписывать код. Формат метки опубликован, так что любой желающий может реализовать нужный функционал на любом приемлемом языке.
Однако если будет найдено хорошее решение децентрализации возможно найдутся желающие развернуть сервис, но не всякий желающий будет готов писать свою реализацию.
Хотя, действительно, код может потребоваться единицам – если вообще потребуется.
И все же если переписывать на чем было бы предпочтительней — Mono или Java?
Нет ли тут противоречия?
комментариев: 11558 документов: 1036 редакций: 4118
Ни то, ни другое. Или Си, или распространённый интерпретируемый язык, типа Питона (предпочтительнее) или Перла.
Нет. Кто сочтёт приемлемым — возьмёт готовый код или использует его в качестве наглядного пособия.