Как правильно подписывать данные в Ruby (HMAC?)

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

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

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

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

(Я добавил код в github с тех пор, как написал этот вопрос, так что вы можете (если хотите!) покопаться: Клиент Сервер)

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

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

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

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

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


person JP.    schedule 04.12.2009    source источник


Ответы (1)


Я не уверен, что именно вы подразумеваете под «свободно изученным, но не воспроизведенным».

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

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

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

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

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

person Hank Gay    schedule 04.12.2009
comment
Приветствую вас, кажется, что HMAC — это путь вперед, но если код для клиента находится в свободном доступе, сможет ли HMAC справиться? HTTPS был бы идеальным вариантом, но поскольку мой «клиент» (фактически веб-сервер) будет находиться на компьютере Джо Паблика, SSL не подходит. - person JP.; 05.12.2009
comment
HTTPS (как обычно реализуется) требует сертификата только для серверной части связи. HMAC обычно достаточно для проверки того, что содержимое сообщения не изменилось, но если вы хотите убедиться, что никто в середине не проверяет его, вам необходимо зашифровать подписанное сообщение. - person Hank Gay; 05.12.2009
comment
Проверка не проблема, мне просто нужно убедиться, что поступающие сообщения исходят от того, кем они должны быть. Я почитаю HMAC, спасибо! - person JP.; 05.12.2009
comment
К сожалению, кажется, что HMAC не поможет, так как мой клиент должен знать закрытый ключ, чтобы иметь возможность сравнить MAC-адрес сервера с тем, каким он должен быть. Злоумышленник может извлечь этот закрытый ключ из интерпретируемого кода и подделать правильно подписанный запрос. С моей стороны требуется больше размышлений - спасибо за вашу помощь! - person JP.; 05.12.2009
comment
Я не знаю, решена ли проблема. однако мне интересно обсудить дальше. Как сделать HMAC асимметричным? ключ, который вы используете для генерации, также требуется для проверки. поэтому вы должны поделиться ключом. есть ли какое-либо решение, подобное HMAC, с парой открытого/закрытого ключа? Но легче, чем https? - person Neel Basu; 28.03.2012
comment
Цифровые подписи ЯВЛЯЮТСЯ асимметричными. Вы подписываете сообщение, используя свой закрытый ключ, получатель проверяет его, используя ваш открытый ключ. Ваш открытый ключ и ваш закрытый ключ хранятся отдельно, и вы НИКОГДА не распространяете свой закрытый ключ. Клиентской программе ни в коем случае не требуется копия вашего закрытого ключа для проверки сообщения. - person Hank Gay; 04.04.2012