Передача симметричного ключа в асимметричный ключ

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

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

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

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


person Crowe T. Robot    schedule 08.02.2010    source источник
comment
Разве вы не пытаетесь заново изобрести SSL?   -  person Vladislav Rastrusny    schedule 08.02.2010


Ответы (3)


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

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

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

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

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

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

person caf    schedule 09.02.2010
comment
Спасибо за ваши очень хорошо изложенные мысли по этому поводу, особенно в части, касающейся энтропии PRNG. Это часть того, что меня особенно беспокоило, но я не знал, как это технически называется, прежде чем вы это сказали. Никогда не зная, что такое SSL на самом деле, я приступил к созданию системы, которая очень похожа, но свернула себя, которая, как вы сказали, почти всегда менее безопасна. Двигаясь вперед, я буду внедрять шифрование SSL, а не свое собственное развернутое решение. Спасибо за совет. - person Crowe T. Robot; 09.02.2010

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

person Andrew McGregor    schedule 08.02.2010
comment
Спасибо за ответ. Я буду использовать полномасштабный SSL для этого проекта, а не свое собственное развернутое решение. Я просто не знал, что такое SSL/реализация (с точки зрения корпоративной архитектуры) достаточно хорошо, чтобы идти с ним с самого начала. Теперь, когда я знаю, что способ, которым я собирался это сделать, далеко не безопасен, я буду придерживаться старого доброго SSL. - person Crowe T. Robot; 09.02.2010

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

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

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

person Draemon    schedule 08.02.2010
comment
Я не использую идентификатор сеанса в качестве ключа. Я отправляю его в качестве ссылки на индекс таблицы на сервере Secure MySQL, в котором хранится секрет blowfish после первого его шифрования с помощью blowfish из жестко запрограммированного и неразделяемого ключа (клиентские сеансовые ключи blowfish хранятся в зашифрованном виде в БД) . Так что... это не НАСТОЛЬКО ужасно спроектировано. -- Мой исходный пост не совсем ясно дал понять, извините. - person Crowe T. Robot; 08.02.2010
comment
Вы правы, SSL будет проще и безопаснее. После дальнейших исследований (я понятия не имел, что это именно то, что делает SSL (более или менее)), я решил продолжить и использовать SSL для проекта. Спасибо за совет. - person Crowe T. Robot; 09.02.2010