id: Гость   вход   регистрация
текущее время 13:31 28/03/2024
Владелец: Alex_B (создано 20/12/2007 14:47), редакция от 17/09/2009 21:26 (автор: Гость) Печать
Категории: инфобезопасность, политика, разное
создать
просмотр
редакции
ссылки

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

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

Введение


Метка времени – это подписанный (ЭЦП) сертификат, содержащий штамп времени, выдаваемый сервисом меток времени. С помощью такого сертификата можно установить факт существования информации в засвидетельствованный момент времени.


«Метки времени» образуют цепочку, в которой каждая последующая метка содержит доказательство, что выдана именно после предыдущей (в метку включается хеш предыдущей). Таким образом, снижается риск фальсификации «метки времени» — если сервис выдаст «метку времени» задним числом, это можно будет обнаружить.


Использования связывания «меток времени» позволяет вам контролировать сервис.


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


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



Примечание: Хеш значение атрибута Ref-Hash считается от следующей части предыдущей метки:


Немного подробнее формат "меток времени" описан в статье Формат «Меток времени»


p.s. Для упрощения в настоящий момент упразднил два формата меток времени.


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

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

 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Комментарии [скрыть комментарии/форму]
— ntldr (19/01/2008 14:04)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Поля служебного заголовка сохраняемой и выдаваемой меток должны быть одинаковы.
Подписывать сохраняемые заголовки тоже весьма желательно. Применение SSL в броузерах не может считаться достаточной защитой (например я не доверяю сотням УЦ каждый их которых может скомпрометировать систему).
— poptalk (19/01/2008 18:43)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Согласен с SATtva-ой. Второй формат содержит в себе первый. То есть во второй формат можно было бы включить первый как одно из полей.

Но. Поскольку польза от второго формата
Для упрощения доказательства третьей стороне

хотелось бы узнать, что подразумевается под "упрощённым доказательством". Я вообще пока не увидел спецификации доказательства или проверки, хоть упрощённой, хоть не упрощённой. (То, что мы с serzh-ем обсуждали, не в счёт — это неформальное обсуждение ;-) ).
— SATtva (19/01/2008 18:58)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Согласен с poptalk и ntldr. :-)
— Alex_B (19/01/2008 21:08, исправлен 19/01/2008 21:09)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
не увидел спецификации доказательства или проверки, хоть упрощённой, хоть не упрощённой.
Вот тут я попытался описать процесс проверки подлинности метки времени.

Покажите пример правильной спецификации, я постараюсь сделать так как надо.
— ntldr (19/01/2008 21:45)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Общие принципы работы сервиса мы сформировали, но не учли одну весьма опасную угрозу – компрометацию секретного ключа сервера.
Ключ которым осуществляется подпись должен обязательно храниться на сервере, а значит его могут украсть админы хостинга, лица имеющие физический доступ в датацентр, а иногда даже другие пользователи хостинга. Еще сервер либо скрипты сервиса могут взломать, админам ДЦ могут дать взятку. Если вы часто меняете хостинг, то опасность сильно возрастает.
Короче говоря безопасность ключа висит буквально на волоске. Ну а компрометация ключа приведет к немедленной потере заработываемой годами репутации и эквивателентна немедленному закрытию сервиса и аннулированию всех меток выданых им за все время работы.

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

Я считаю защиту от компрометации ключа сервиса крайне важным элементом системы. В противном случае сервис проживет до первого желающего его скомпрометировать.
— poptalk (20/01/2008 14:37)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Вот тут я попытался описать процесс проверки подлинности метки времени.

Покажите пример правильной спецификации, я постараюсь сделать так как надо.

Да, я не видел этого документа. Ответил там.
— poptalk (20/01/2008 14:43)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Я предлагаю немного усложнить выдачу метки чтобы защититься от этой атаки. Для этого пусть у сервиса будет один мастер-ключ хранимый только у автора, и каждую неделю будут издаваться ключи сервиса с ограниченым сроком действия.

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

Можно, например, сделать сеть сервисов меток времени распределённой, типа p2p. То есть сервисы установлены на личных машинах. К ним никто не имеет доступа, кроме владельца машины (и его родственников ;-) ). Клиент получает метку времени от первого попавшегося сервиса, находящегося online. Ключи шифрования у всех сервисов, конечно, разные.
— SATtva (20/01/2008 14:47, исправлен 20/01/2008 14:55)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Покажите пример правильной спецификации, я постараюсь сделать так как надо.

#: Правильная — это та, которая противостоит всем атакам.

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

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

Я считаю защиту от компрометации ключа сервиса крайне важным элементом системы.

Это хорошая идея (давным давно я сам deniedпредлагал такую), но не думаю, что следует регламентировать её в самой программе или в спецификациях (в терминах IETF, её можно было бы разместить как рекомендацию в Security Considerations, но не в формальной части документа).
— ntldr (20/01/2008 15:09, исправлен 20/01/2008 15:11)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

что знают двое, ​то знает свинья ©
Иметь полностью подконтрольный лично вам сервер практически нереально. Даже если вы покупаете выделеный сервер и не делите ни с кем его использование, то админы датацентра всегда имеют к нему физический доступ. Лично я знаю случаи когда админы ДЦ за деньги сливали данные с таких серверов.
Считать защищенным можно только ключ к которому имеет доступ один человек, не более того.
— poptalk (20/01/2008 19:25)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Можно, например, сделать сеть сервисов меток времени распределённой, типа p2p.

Подумал, как может выглядеть p2p для меток времени. Метка времени должна содержать несколько полей Ref-Hash, и эти поля хранят хэши меток, выданных разными сервисами.

Модель угрозы такова, что все люди составили заговор против меня и моих друзей. Далее я хочу узнать, когда на самом деле была выдана метка М. Я нахожу предыдущую относительно М метку, потом от неё предыдущую и так рекурсивно, пока не найду метку МП, выпущенную моим другом. Потом я нахожу следующую метку и так рекурсивно, пока не найду метку МС, выпущенную моим другом. Мои друзья поставили в своих метках время, и этому времени я доверяю. Таким образом, время выпуска М лежит между МП. Timestamp и МС. Timestamp. То есть я определил интервал времени, внутри которого была выпущена метка М.
— poptalk (20/01/2008 20:20)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Подумал, как может выглядеть p2p для меток времени.

А можно использовать существующие p2p-сети, где распространяются файлы. Ведь в этих сетях ссылка на файл есть его хэш! То есть, если я включаю в файл ссылку на предыдущий файл, я могу проверять цепочки файлов.
— SATtva (20/01/2008 21:24)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Можно, например, сделать сеть сервисов меток времени распределённой, типа p2p.

А может, если Вы доверяете друзьям, просто попросите их подписать нужный файл? В сущности, Вы можете обратиться к любому пользователю PGP с просьбой независимо заверить нужную информацию. Сам это делал неоднократно, мало кто в этих случаях отказывает.

Сервис меток полезен именно своей простотой, надёжностью и доступностью. А теперь подумайте, во что превратится схема, стоит к ней добавить одну аббревиатуру "p2p". Децентрализованность, к сожалению, простой не бывает. Даже одно лишь совместное заверение метки несколькими сервисами, о чём я постоянно говорю, — не самая тривиальная задача.
— poptalk (20/01/2008 23:04)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
А может, если Вы доверяете друзьям, просто попросите их подписать нужный файл?

Вопрос в том, доверяет ли моим друзьям тот, кто будет проверять метку.

Ведь человек, который заказывает метку, и человек, который проверяет метку, это разные люди, и друзья у них разные. ;-)

С другой стороны, p2p уже в нашем протоколе используется. Вы говорили, что надо архивы меток публиковать в Usenet. Разве это не p2p для файлов? Или, допустим, клиент должен хранить некоторые метки (контрольные метки). А потом передавать эти метки другим клиентам:
Как человек не делавший «контрольных» меток сможет проверить подлинность, предоставленной ему метки времени?
-Иметь свою контрольную метку необязательно, т.к. другие люди, делая их (метки) будут тем самым контролировать сервис. — Serzh
principraboty
Просто пока предполагается делать эту p2p руками.
— SATtva (20/01/2008 23:30, исправлен 20/01/2008 23:33)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Вы говорили, что надо архивы меток публиковать в Usenet. Разве это не p2p для файлов?

Во-первых, я не говорил, что это обязательно (это интересный приём — размещать журнал меток в месте, недоступном оператору для последующих исправлений, — но его можно избежать или заменить чем-нибудь другим). Во-вторых, называть Usenet p2p-сетью можно с тем же успехом, что и сеть почтовых MTA. Peer-to-peer означает, что нет явного разделения на клиенты и серверы. В Usenet это, конечно, не так.

P. S. Это до чего же докатился нынче Юзнет, если его считают простой файлопомойкой! :-))
— poptalk (21/01/2008 01:25, исправлен 21/01/2008 01:26)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Публикую ещё одну уязвимость.

Я решил открыть свой сервис меток времени. В первой метке должен быть записан тот момент, когда я открыл сервис. А что мешает мне поставить в первой метке любую дату на 10 лет раньше? Я мог бы запатентовать механику Ньютона раньше самого Ньютона, а Новый Завет — раньше Христа! ;-) И формально эти метки будут выглядеть правильно. Конечно, такие большие сроки я взял для прикола. Но если выбрать срок, например, год назад, то никто ничего не заподозрит.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3