Симметричный ключ к передаче обслуживания асимметричного ключа - PullRequest
0 голосов
/ 08 февраля 2010

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

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

Хорошо, у меня есть клиент -> сервер связи. Клиент я могу жестко кодировать в публичной части 2048-битного ключа RSA. Когда клиент хочет инициировать безопасное соединение, он отправляет свое имя пользователя, md5-хэш своего пароля и хэш-код случайного UUID, все из которых были зашифрованы с помощью открытого ключа сервера. Сервер получает информацию и расшифровывает, используя свой закрытый ключ. Проверяет базу данных, чтобы увидеть, работают ли его логин + пароль и, если они это делают, создать новую запись в таблице «Сеансы» в БД. Это включает в себя SessionID, UID (идентификатор пользователя) и хеш UUID. Используя UUID соответствующего идентификатора сеанса в качестве ключевой фразы, сервер затем отправит обратно сообщение с зашифрованным словом Blowfish «Success!» + случайный UUID (это сообщение имеет цифровую подпись, чтобы мы могли определить, пришло оно с сервера или нет). С этого момента, когда клиент отправляет информацию на сервер, он будет иметь открытый текст sess_id и включать зашифрованное сообщение Blowfish, используя в качестве ключа для шифрования / дешифрования секрет Blowfish соответствующего идентификатора сеанса (хранится в зашифрованном виде в БД).

В частности, мне любопытно, должна ли эта система «работать» или кто-то замечает, что совершенно очевидно, что существует уязвимость, такая как MITM.

Ответы [ 3 ]

2 голосов
/ 09 февраля 2010

Просто используйте SSL или DTLS, IKEv2, HIP, EAP или какой-либо подходящий стандартный протокол. Не пытайтесь изобретать свои собственные крипто-протоколы, никто не имеет достаточного опыта, чтобы сделать это самостоятельно. Насколько мне известно, в вашем протоколе недостаточно энтропии, поэтому полученные ключи будут довольно слабыми.

2 голосов
/ 09 февраля 2010

Проблемы, которые я вижу на макушке головы (хотя вы упустили большинство деталей, в которых, как известно, живет дьявол):

  • Если вы используете генератор UUID, а не настоящий криптографический ГСЧ, он, вероятно, обладает недостаточной энтропией. Не пренебрегайте этим - в реальном мире любимым способом скрытного ослабления системы шифрования было ослабление ГСЧ;

  • Ваше первоначальное шифрование RSA звучит так, как будто оно подвержено атаке с небольшим экспонентом и, возможно, другим творческим атакам. Там слишком много структуры, чтобы быть удобной;

  • Похоже, есть множество возможностей для повторных атак;

  • Какой режим блочного шифра вы используете с Blowfish?

Я рекомендую использовать TLS / SSL - на него смотрят гораздо дружелюбнее, гораздо дольше, чем то, что вы когда-либо создавали сами.

0 голосов
/ 08 февраля 2010

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

Если вы отправляете идентификатор сеанса в виде открытого текста и используете его в качестве ключа шифрования, насколько это безопасно?

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

...