Как правильно подписать данные в Ruby (HMAC?) - PullRequest
1 голос
/ 04 декабря 2009

У меня есть сервер (приложение RoR), отправляющий информацию клиенту (приложение Ruby Sinatra), и мне нужен способ, чтобы клиент был уверен, что данные поступили с моего сервера, а не злой третьей стороны.

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

Я хотел бы найти какой-нибудь способ (в Ruby, с целью межплатформенной применимости) подписать ответ сервера, чтобы его можно было проверить без проверки кода клиента, приводящего к подделкам. Есть идеи?

ОБНОВЛЕНИЕ : Посмотрим, смогу ли я объяснить это лучше!

(я добавил код в github с тех пор, как написал этот вопрос, так что вы можете (если хотите!) Возиться: 'client' 'server' )

Процесс такой: Джо Блоггс использует букмарклет на своем мобильном устройстве. Это отправляет в настоящее время посещенный URL на sitesender.heroku.com. Когда sitesender.heroku.com получает этот запрос, он проверяет свою БД и проверяет, не вошел ли кто-либо в ту же учетную запись с помощью целевого приложения 1018 *. Если это так, их IP-адрес будет записан, и sitesender.heroku.com отправит GET-запрос целевого приложения (веб-сервера) на этот IP-адрес, запрашивая у цели запуск URL-адреса с закладкой в ​​браузере по умолчанию.

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

Очевидно, что основная проблема заключается в том, что с открытым сервером любой может отправить запрос на открытие «серьезноevilwebsite.com» на широкий диапазон IP-адресов, и я развязал чумы в цифровом мире. Поскольку я использую heroku.com в качестве сервера (это невероятно хороший, но облачный хост RoR), я не могу просто проверить исходящий IP.

Насколько я понимаю HTTPS, для этого параметра мне пришлось бы сортировать сертификаты для каждого целевого приложения? Я согласен, что мне нужна какая-то форма асимметричного шифрования, подписать исходящие запросы от sitesender.heroku.com с закрытым ключом (никогда не распространяемым) и получить target для выполнения той же операции с использованием открытого ключа и теста для сходства - но вы правильно догадались, я все еще немного не понимаю, как работает HMAC! Как это асимметрично? Сформулировано ли это так, чтобы при выполнении одной и той же операции HMAC с закрытым ключом и открытым ключом генерировалась одна и та же подпись? В этом случае - HMAC - победитель!

Спасибо за ваше терпение!

1 Ответ

1 голос
/ 04 декабря 2009

Я не совсем уверен, что вы имеете в виду под "свободно исследуемым, но не тиражируемым".

В общем, если вам нужен безопасный канал связи, https - ваш друг.

Если это не удастся (или если этого недостаточно из-за какой-либо архитектурной проблемы), HMAC и асимметричная криптография - это путь.

ОБНОВЛЕНИЕ: Я не уверен, что понимаю проблему, поэтому я попытаюсь описать проблему, которую, я думаю, вы пытаетесь решить: у вас есть клиенты, которые должны быть уверены, что ответ, который они видим, на самом деле идет с вашего сервера.

Предполагая, что я прав, и это действительно проблема, которую вы пытаетесь решить, HTTPS прекрасно решает эту проблему. Вы устанавливаете сертификат на своем сервере - вы можете подписать его самостоятельно, но клиенты не будут доверять ему по умолчанию; для этого вам нужно купить один из стандартных центров сертификации (CA), а затем клиент отправляет HTTPS-запрос на ваш сервер. HTTPS обрабатывает проверку того, что предоставленный сертификат был выдан для сервера, с которым он разговаривает. Вы сделали.

Наконец, я думаю, что есть недопонимание того, как работает HMAC. Ключевой принцип асимметричной криптографии - НИКОГДА не распространяет ваш закрытый ключ. С помощью асимметричного шифрования вы шифруете сообщения открытым ключом получателя, а он / она дешифрует его своим закрытым ключом. Вы подписываете сообщения своим закрытым ключом, и он / она проверяет его, используя ваш открытый ключ.

...