id: Гость   вход   регистрация
текущее время 13:56 28/03/2024
Владелец: Alex_B (создано 19/12/2007 17:02), редакция от 08/07/2009 12:51 (автор: Гость) Печать
Категории: инфобезопасность, политика, разное
https://www.pgpru.com/Черновики/Статьи/Сервисметоквремени
создать
просмотр
редакции
ссылки

Сервис меток времени

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

В данном разделе ведется разработка web-сервиса меток времени "timeMarker.org", обсуждаются вопросы реализации и использования.


Назначение и суть сервиса


«Сервис меток времени» является, по сути, электронным нотариусом. Клиент передает сервису информацию, сервис проставляет свой штамп времени и заверяет полученный результат с помощью ЭЦП.


Адрес проекта: http://timeMarker.org/
Русская версия: http://timeMarker.org/ru/


Введение в «Сервис меток времени»


Ход работы


  1. Нужно определиться с принципом работы сервиса.
  2. Определить формат "сертификата доступа" (или другими словами билет доступа к услугам сервиса), или вообще отказать от его использования. Решили отказаться от использования.
  3. Решены основные проблемы как теоретической части (огромное спасибо всем участникам), так и практической реализации. Написана административная часть — реализован минимум:
    • управление PGP ключом сервиса;
    • ведение истории использования ключей.
  4. Разработать API доступа.
  5. Реализовать заверение "меткой времени" файлов.
  6. Сделать "Получение метки времени по URL".
  7. Заверение даты создания \ аннулирования ключа. Ненужная функция.
  8. Децентрализация сервиса.

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

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

 
На страницу: 1, 2, 3, 4 След.
Комментарии [скрыть комментарии/форму]
— SATtva (25/01/2009 19:07)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Большие хостинг-площадки давно не ограничивают потребляемый трафик.
— Alex_B (25/01/2009 20:55)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Ситуация следующая:
Сервис меток времени является WCF сервисом у которого настроены привязки с помощью SOAP и GET. Т.е. сервис может принимать SOAP и GET запросы.

Сайт, который виден пользователям, ничего не делает – сайт это клиент сервиса который контактирует с сервисом с помощью GET запросов. А если еще точнее, то сайт просто формирует правильные URL и редиректит на них пользователя.

Передать base64 строку содержащую 3 мб файл (не говоря уже об 10 мб) с помощью GET не представляется возможным. С помощью SOAP это тоже геморрой (там файлы как раз и передаются как base64 строки). И даже если по SOAP это заработает то это будет потолок – далее бить файлы на части и т.п.
Вся простота и красота (запрос – ответ) теряется.

Потому заверяемая информация не превышает 255 символов – потому что сервис рассчитывался, что бы подписывать хеши (а уж от чего эти хеши, хоть 100 Мб файлов, не дело сервиса).
Таким образом сервис мог бы вообще не вычислять хеши от пользовательских данных, а сразу писать в метку времени пользовательскую строку (предполагается что это был бы хеш, вычисленный пользователем). Что бы не провоцировать спамеров решили пользовательские данные в открытом виде не вставлять в метку, а все-таки считать их хеш.


Можно приделать на сайт кнопку «Обзор» для загрузки файлов.
Сайт будет считать хеш файла и отправлять сервису. Сервис еще раз вычислит хеш и запишет его в метку времени.

Сайт посылает сервису: хеш_от_файла = Хеш(файл)
Сервис записывает в метку времени: хеш_от_хеша = Хеш(хеш_от_файла)


Со стороны пользователя это совсем не логично – проверять связь файла с меткой путем Хеш(Хеш(файл))…
— SATtva (25/01/2009 21:06)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Тут есть и семантическая проблема: теряется связь между переданными данными и меткой. Если пользователь отправляет на сайт хэш или файл, который непосредственно и заверяется, — это одно. Если же отправленные данные где-то за кулисами преобразуются в новый вид (от файла считается хэш) и уже в этом виде заверяются — это несколько другое.
— Гость (27/01/2009 18:38, исправлен 27/01/2009 18:51)   <#>
Передать base64 строку содержащую 3 мб файл (не говоря уже об 10 мб) с помощью GET не представляется возможным.

Вот, погуглил 5 минут, может пригодится?
HTTP формально не лимитирует длину GET-запроса, но ограничение на нее накладывают реализации этого протокола.


достаточно установить на стороне клиента который обращается к сервису
maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647"
и будет счастье.
http://forum.sources.ru/index.php?showtopic=246645

Uploading/Downloading Files using WCF

Сорри если не в тему.
— Гоги (28/01/2009 00:58)   <#>
Подсчитываете хэш-значение файла с помощью утилиты sha1sum или gpg. Хэш отправляете на timemarker. Правда само указанное ограничение я не считаю правильным.
Под рукой есть Total Commander, он просчитывает MD5. Я могу использовать это хэш-значение?

Специально для Windows пользователей, нашел пару прог считающих SHA1!

1. HashTab Windows Shell Extension v2.0 fileСкачать – Добавляет закладку в свойства файла. Расчет MD5, SHA1, CRC-32 по умолчанию, можно в любой момент включить еще полдюжины – HAVAL, RIPEMD-128/256/320, SHA-512, Tiger, Whirlpool.

2. Fsum Frontend 1.5.5 fileСкачать – Программа поддерживает 96 (!) алгоритмов: alder8, adler16, adler32, ap hash, bdkr, cksum, cksum mpeg2, crc8, crc16, crc16 ccitt, crc16 ibm, crc16 x25, crc16 xmodem, crc16 zmodem, crc24, crc32, crc32 bzip2, crc32 jamcrc, crc32 mpeg2, crc64, crc64 ecma, djb hash, dha256, edonley/emule, elf32, fletcher8, fletcher16, fletcher32, fnv0-32, fnv0-64, fnv1-32, fnv1-64, fnv1a-32, fnv1a-64, fork256, ghash3, ghash5, gost, has160, haval (128, 160, 192, 224, 256 bits) (3, 4, 5 passes), jhash, js hash, md2, md4, md5, panama, pjw32, ripemd128, ripemd160, ripemd256, ripemd320, rs hash, sdbm, sha0, sha1, sha224, sha256, sha384, sha512, size64, snefru2 (128, 256 bits) (4, 8 passes), sum8, sum16, sum24, sum32, sum64, sumbsd, sumsyv, tiger128, tiger160, tiger192, tiger2, tiger tree, tiger tree 2, whirlpool0, whirlpool1, whirlpool2, xor8, xum32.
Также поддерживается создание и проверка: SFV, MD5, SHA1/SHA2
ВАЖНО путь к exe-шнику не должен содержать русских названий папок, иначе программа НЕ запустится, т.е. путь не должен быть, например, C:\Программы\fsumfrontend-1.5.5-bin\.
— Alex_B (31/01/2009 13:07)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Гость (27/01/2009 18:38), спасибо. Действительно, что это я — может же WCF и файлы загружать :)
— Kent (03/09/2009 09:04, исправлен 03/09/2009 09:15)   профиль/связь   <#>
комментариев: 437   документов: 30   редакций: 15
Понадобился мне (неожиданно! И искал через google на родном форуме [1]) сервис меток времени. Сохранил скриншот, то есть, файл, web-страницы и заверил подписью http://timeMarker.org/
Теперь пытаюсь проверить по адресу http://timemarker.org/ru/Log.aspx#search, но вижу "Server Error in '/' Application." И что делать?

[1] http://www.pgpru.com/chernowik.....i/servismetokvremeni
Статья, на мой взгляд, закончена. Может быть, пора из черновиков перенести?

Update: заработало.
— Гость (03/09/2009 09:54)   <#>
Теперь пытаюсь проверить по адресу wwwhttp://timemarker.org/ru/Log.aspx#search, но вижу "Server Error in '/' Application." И что делать?
рассказывайте подробности – при каких действиях вылезает ошибка? Буду устранять
— Гость (01/10/2011 18:31)   <#>
Уважаемый автор, я тут как раз искал подходящий таймстамп-сервис, который можно было бы прописать в договоре. Наткнулся на ваш сервис, решил проверить работу. Скачал из нотариального журнала последний архив с метками, и что же? Ни одна метка не проверяется ни в PGP Desktop, ни в GnuPG. Даже не подпись плохая — PGP говорит "file may be corrupt", а GPG — "no valid OpenPGP data found". Для чистоты эксперимента скачал первый архив — всё отлично проверяется без ошибок.

Доверие к сервису подорвано, не успев появиться. Очень жаль.
— SATtva (01/10/2011 20:16)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Есть ещё такая русскоязычная служба меток времени на базе OpenPGP: https://www.metkavremeni.com/index-russian.html
— Гость (02/10/2011 02:53)   <#>
Почитал все треды про этот интересный по задумке сервис. Остался только один существенный вопрос: правильно ли я понял, что помешать злонамеренному администратору сервиса вставить подложную отметку времени куда-нибудь в середину цепочки и пересчитать все последующие хеши может только теоретическая вероятность, что кто-то из пользователей заметит, что полученная им отметка теперь имеет номер, больший на единицу, и хэш предыдущей отметки в ней записан неверно?
— SATtva (02/10/2011 14:39)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
При подмене метки в середине цепочки, станут недействительными все метки новее подменённой. Любой пользователь сервиса (как тот, который получал метку изначально, так и тот, кому её могли позднее передать вместе с заверенными данными) при перепроверке нужной метки обнаружит расхождение. А учитывая, что метка заверена ключом сервиса, этого будет достаточно, чтобы доказать мухлёж администратора.
— unknown (02/10/2011 15:27)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

или компрометацию сервиса злобными силами.
— SATtva (02/10/2011 15:31)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Да, это важное уточнение. В конечном счёте, сторонний пользователь не сможет отличить одно от другого. Для этого нужен какой-то более сложный регулярный аудит системы с привлечением доверенной третьей стороны.
— Гость (25/03/2015 00:21)   <#>
Что с сервисом? Исходники или работающие аналоги существуют?
Украинский сервис не труъ – close source.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3