Поддержание целостности сообщения

Question

У меня есть сообщение о том, что я передаю себе, что будет подвержено атакам типа «человек в середине». Из-за этого меня беспокоит целостность сообщения, которое поддерживается между временем отправки и временем получения.

Следует учитывать, что как только я отправлю сообщение самому себе, никакая информация о отправленном сообщении не будет доступна мне в будущем. Сообщение полностью самодостаточно.

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

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

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

В этом случае у меня есть набор пар ключ/значение. С этой целью я должен предпринять следующие шаги:

1. Добавить соль в сообщение. Соль является секретом для остального мира. Он прикрепляется к содержимому сообщения перед хешированием.
2. Согласовать пары ключ/значение перед генерированием хеша.
3. В то время как не непосредственно релевантно, отметка времени будет добавлена ​​к содержимому каждого сообщения перед хэшированием, чтобы предотвратить повторные атаки.

Эти дополнительные шаги, которые я рассматриваю:

1. Преобразуя ключи, прежде чем я их заказать. Я рассмотрел их реверсирование, затем упорядочивая счет/ключ.
2. Игра с разделителями, которые разделяют пары ключ/значение (как для разделителя для ключа/значения, так и для разделителя для пары).

ПРИМЕЧАНИЕ

конфиденциальности Сообщение является не требование здесь, так что я не ищу для шифрования. Значения должны быть переданы в текстовом формате.

Наконец, какие алгоритмы хеширования следует избегать?

---

Особенность

У меня есть сайт ASP.NET MVC, который у меня есть контроллер, который обрабатывает входную проверку и настойчивость.

Если (на основе эвристики, это не важно, какой) ввод определяется как автоматическая попытка спама, создается модель IDictionary<string, string> с входными значениями, а ViewResult отправляется на общую страницу CAPTCHA.

В этом представлении в форме, содержащей элемент управления CAPTCHA, содержимое IDictionary<string, string> будет выписано в скрытые поля ввода, а действие формы будет тем же самым действием, в котором было отправлено содержимое. Таким образом, MVC может получать значения при повторной отправке формы.

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

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

Решение

Я решил пойти с классом SignedCms в пространстве имен System.Security.Cyrptography.Pkcs, который представляет signging и проверочные о CMS/PKCS # 7 сообщений.

Для разработки, я создал самостоятельно выданный сертификат с Makecert.exe, а затем в моем коде, я использую пример здесь для цифровой подписи данных:

http://blogs.msdn.com/shawnfa/archive/2006/02/27/539990.aspx

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

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

Ответ на вопрос Kalium, а не за его initial post, но за его последующие комментарии, указывающие путь к цифровым подписям, и в конечном итоге мое открытие о том, как их использовать в .NET.

Спасибо всем, кто внес свой вклад.

Answer 1

Я думаю, что PGP/GPG - это то, что вы хотите здесь.

Answer 2

Вы хотите a Digitally Signed message. Используя GPG, вы можете подписать сообщение без, шифруя его. Но никто не сможет вмешаться в это, потому что они не могут генерировать хэш - только вы можете, потому что хэш использует ваш закрытый ключ.

Answer 3

Возможно, вам стоит подписать цифровую подпись (следовательно, PGP/GPG, рекомендованный Kalium, является релевантным как опция). Любой чистый хэш, который вы можете создать, может быть воссоздан злоумышленником. Цифровое подписание - использование вашего частного ключа подписи, чтобы ваш открытый ключ можно было использовать для его проверки - это решение. Все остальное - бесполезность.

Answer 4

Предполагая, что вы не можете передать какую-либо информацию по каналу «обеспечения» (то есть хэш) вот как бы это сделать:

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

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

Как уже упоминалось, это просто ванильным цифровой подписи и могут быть обработаны чем-то вроде PGP/GPG

Answer 5

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

Я бы особенно рекомендовал реализацию, описанную в RFC-2104 http://www.ietf.org/rfc/rfc2104.txt, поскольку ее тщательно продумали, чтобы избежать большинства возможных ловушек.

Если сообщения должны быть проверены подлинности не доверенными сторонами, тогда вы должны использовать схему цифровой подписи.

Возможно, существует поддержка как в библиотеках .Net. Майлз предоставил (как комментарий) ссылку на веб-страницу MSDN для функций библиотеки .Net, реализующих HMAC с ключами, используя хэш SHA1: http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.aspx.