РегистрацияЭлектронная подпись на внешнем сервере
Уважаемые спецы! Подскажите, с чего начать.
Задача – организовать веб-вервис, который будет заверять своей электронной подписью пользовательские файлы. Предполагается использовать это для подтверждения владения определённым файлом на момент подписи.
Хотелось бы реализовать два варианта работы:
1- подписывается электронная подпись пользователя, которой уже заверен основной файл, и,
2- подписывается закачаный на сервер пользовательский файл (архив).
Я в криптографии новичёк, только на десктопе использовал pgp, пока не перешёл на truecrypt из-за невостребованности подписей... И пока не очень представляю от какой печки плясать :-)
Сервер, на котором должен крутиться сервис:
http://www.hostgator.com/shared.shtml
(план Baby или Swamp, ОС Linux, Kernel version 2.6.17.11-grsechg, Apache version 1.3.37 Unix).
Буду рад вашим советам!
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 9796 документов: 488 редакций: 5664
И всё?
Достаточно пользователю отправить на сервер значение хэша (из числа криптостойких) для файла, а затем пусть сервер подписывает пару [хэш:дата]. Ну и хэш перед этим тоже пусть сам пользователь и считает.
комментариев: 5 документов: 1 редакций: 0
А насчёт работы с хэшем, боюсь, не всё так просто – мои пользователи не имеют ни малейшего понятия о криптографии, подавляющее большинство их даже собственной электронной подписью не обладают. Поэтому и хочется предоставить им помимо обычного тайм-стемпинга вариант файлового хранилища с автоматической подписью сервером закачанных файлов.
комментариев: 9796 документов: 488 редакций: 5664
Пусть скачают gpg и выполнят комманду, а если не могут, напишите .bat файл :-)
комментариев: 5 документов: 1 редакций: 0
а со стороны сервера это так элегантно не решить?
комментариев: 11558 документов: 1036 редакций: 4118
Операционные требования какие? Подтверждение (доказательство) — понятие широкое. Простая подпись файлов докажет только в том случае, если арбитр (независимая сторона, которой в конфликтной ситуации демонстрируется доказательство) имеет безоговорочное, слепое доверие к Вашей системе. Например, как арбитр может быть уверен, что Вы как разработчик/админ не вступили в сговор с одной из конфликтующих сторон и не переподписали файл с поддельной меткой времени?
На самом деле, я занимаюсь реализацией того же самого для этого сайта. Разумеется, ни о каком хранении файлов речи не идёт, предполагается чистая служба меток времени с надёжным аудитом.
комментариев: 9796 документов: 488 редакций: 5664
Нужно только подумать над защитой безпарольного ввода на сервере
комментариев: 9796 документов: 488 редакций: 5664
Куда уж более слепое, если на подпись надо давать не хэши, а закачивать сами файлы.
комментариев: 5 документов: 1 редакций: 0
Персональный файловый сервер предполагается как один из сервисов для зарегистрированных пользователей, и функция ЭП была бы на нем очень интересна. Никто не мешает пользователям закачивать зашифрованные файлы.
Насчёт доверия арбитра – это, насколько я вижу, не решается техническими средствами на базе виртуального хостинга. Так что придётся занимать позицию нескомпрометированного сервиса на основе презумции невиновности. Или есть иные решения, прозрачные для пользователей? Было бы интересно услышать о них.
На этом сайте вижу реализацию шифрования при отправке личного сообщения – где можно почитать про практическую реализацию такого механизма? Кажется, ответ на мою проблему состоит в нескольких строках кода...
комментариев: 11558 документов: 1036 редакций: 4118
Решается. Обычно связыванием меток времени, когда каждая последующая включает некоторый уникальный элемент предыдущей, например:
где S — цифровая подпись данных M, H — операция хэширования
В этом примере оператор сервиса не может произвольно изменить одну из старых меток времени, поскольку это повлечёт инвалидацию всех последующих. (Здесь нужно быть внимательным с семантикой и чётко определить, что именно подлежит хэшированию: каждый пользователь должен иметь возможность сделать то же самое, чтобы убедиться в честности системы.) Правда, ничто не мешает ему изменить последнюю изданную метку, не имеющую аудиторского следа, или попробовать подделать все последующие в надежде, что это останется незамеченным. Данный пример очень прост, но демонстрирует нетривиальную схему.
Здесь можно и комментарии и страницы подписывать. ;-) Почитать можно здесь, только кода там всё-таки побольше...
комментариев: 5 документов: 1 редакций: 0
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 5 документов: 1 редакций: 0
комментариев: 11558 документов: 1036 редакций: 4118
Зато полно обменников.