id: Гость   вход   регистрация
текущее время 22:35 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 След.
Комментарии [скрыть комментарии/форму]
— poptalk (21/01/2008 02:01)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Децентрализованная сеть нехороша, потому что есть одно важное соображение в пользу централизации. Один сервис легче контролировать. Чтобы контролировать, нужно регулярно запрашивать и сохранять контрольные метки (и, разумеется, проверять, что в метках время соответствует действительному). Чем больше людей им пользуются, тем чаще сохраняются контрольные метки. Например, у нас один сервис, 100 клиентов и каждый клиент запрашивает контрольную метку один раз в сутки. Итого 100 контрольных меток в сутки. А если сервисов два, то на каждый сервис приходится 50 контрольных меток в сутки, соответственно, степень контроля снижается.

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

И тогда возникает вопрос: а должен ли сервис что-либо подписывать вообще? Если на сервисе нет ключа шифрования — нечего компрометировать.
— ntldr (21/01/2008 05:58)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

А как иначе доказать что метка выдана этим сервисом а не кем попало? Факт публикации заголовка метки на сайте доказательством не является, так как в случае отсутствия подписи возможен будет ряд атак связаных с подменой данных TCP соединения.
— Paran0ik (21/01/2008 07:55)   профиль/связь   <#>
комментариев: 88   документов: 13   редакций: 3
Лично я знаю случаи когда админы ДЦ за деньги сливали данные с таких серверов.

информацию на сервере можно шифровать...
— ntldr (21/01/2008 08:06)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

А толку? Имея физический доступ всегда можно закинуть простенький скрипт скопирующий информацию после расшифрования.
— Paran0ik (21/01/2008 09:01)   профиль/связь   <#>
комментариев: 88   документов: 13   редакций: 3
А толку? Имея физический доступ всегда можно закинуть простенький скрипт скопирующий информацию после расшифрования.

я хз как вы закините на запароленный сервер какие-то скрипты...
— ntldr (21/01/2008 10:06)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Очень просто. Закину подключив винт к другой машине.
— Alex_B (21/01/2008 10:58, исправлен 21/01/2008 10:59)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
«Правильная спецификация — это та, которая противостоит всем атакам.
входящим в модель угрозы.»
Надо сначала значит модель угрозы описать. А хороший пример такой модели есть?
(я понимаю о чем речь, но хочется посмотреть хорошие примеры)


Это хорошая идея (давным давно я сам предлагал такую )

Есть вариант и мне посмотреть, что же там такое?


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

А неделя это не слишком часто?

В первой метке должен быть записан тот момент, когда я открыл сервис. А что мешает мне поставить в первой метке любую дату на 10 лет раньше?

Надо что-бы первая метка времени была подписана или другими сервисами или авторитетами, которым можно доверять.
— Paran0ik (21/01/2008 12:48)   профиль/связь   <#>
комментариев: 88   документов: 13   редакций: 3
Очень просто. Закину подключив винт к другой машине.


ок, я повторюсь – информацию на сервере можно шифровать...можно даже весь винт тем же DiskCryptor'ом :)
— ntldr (21/01/2008 14:45)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Если вы не шифруете системный раздел, то вредоносный скрипт закину туда. А если шифруете, то как собираетесь вводить пароль до загрузки ос? Сервер стоит в далеком датацентре без клавиатуры и монитора, и единственная связь с ним по сети.
— Гость (21/01/2008 15:37)   <#>
Например.
в бут разделе просто образ системы – первичного загрузчика.
таким образом, загрузку основной системы можно организовать с запросом пароля по сети.
— Гость (21/01/2008 15:47)   <#>
можно также сделать образ системы-посредника, которая проверит контрольную сумму своего образа и образа первичного загрузчика, и при несовпадении уничтожит мастер ключь основной системы.
— Alex_B (21/01/2008 16:11, исправлен 21/01/2008 16:21)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Если использовать мастер ключ, возможно стоит изменить формат метки времени следующим образом:





Тогда пользователь сможет сразу проверить корректность подписи. Ему не нужно будет постоянно следить за текущими ключами. Вся информация будет содержаться в самой метке.
— ntldr (21/01/2008 16:36, исправлен 21/01/2008 16:43)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Нет, имхо это как раз не нужно. Лишнее утяжеление каждой метки, причем утяжеление существенное. Для распостранения ключей есть кейсерверы.

Как уже сказал SATva, лучше не выносить это в спецификацию метки, а сделать опциональной рекомендацией. В спецификацию процедуры проверки метки стоит лишь добавить загрузку ключа подписи если он не совпадает с имеющимся ключем сервиса.
— Alex_B (21/01/2008 17:47)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
А почему бы не включить в спецификацию регулярную смену ключа?

Иначе проверка цепочки будет сложным занятием.
— poptalk (21/01/2008 17:47, исправлен 21/01/2008 17:48)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4


Критичная операция — простановка времени, а если сервис не ставит время, так его и не обязательно защищать. Он просто связывает хэши, а связанность хэшей может проверить сам клиент. Сервис можно считать просто вычислителем и ячейкой памяти для хэша. ;-)

Оформил это в отдельную спецификацию. У меня связывание хэшей и простановка времени — разные роли. А время должно подписываться, обязательно.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3