Криптография с открытым ключом с выбранными пользователем паролями?

Question

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

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

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

Мой подход заключается в создании асимметричной пары ключей на клиенте, публикации открытого ключа на сервере вместе с зашифрованной копией личного ключа (зашифрованного паролем пользователя). Затем пользователи могут отправлять зашифрованные сообщения другим пользователям, используя опубликованный открытый ключ получателя; когда пользователю необходимо расшифровать сообщение, его (зашифрованный) закрытый ключ выбирается на клиенте с сервера, расшифровывается с помощью пароля, предоставленного пользователем, а затем используется для дешифрования сообщений.

Имеет ли это какой-то смысл? Есть ли недостаток в этой конструкции системы? (кроме слабости, вызванной тем, что пользователи выбирают короткие или неверные пароли) Этот подход уже используется в подобных сценариях?

Спасибо:)

Answer 1

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

Это не будет работать.

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

Чего здесь не хватаетявляется центром сертификации.Это доверенная третья сторона, которая подписывает цифровой подписью связь между открытым ключом и именем пользователя.Эта привязка называется сертификатом.Таким образом, когда сервер предоставляет открытый ключ клиенту для использования для шифрования, клиент может использовать открытый ключ CA для проверки сертификата и быть уверенным, что открытый ключ, который он собирается зашифровать, принадлежит предполагаемому получателю,и не злоумышленник.

Пользователи должны доверять ЦС, что может быть более приемлемым, чем доверие к администраторам сервера.Но также должен быть защищенный от несанкционированного доступа способ хранения сертификата CA.На практике это часто делается с использованием MAC на основе пароля (код аутентификации сообщения).Или, CA может быть подписан цифровой подписью с закрытым ключом пользователя (никогда не видел это сделано, но это будет работать).Но сложнее было бы получить сертификат CA из надежного источника, минуя ненадежный сервер.

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

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

Answer 2

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

Answer 3

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

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

Почему бы не использовать симметричное шифрование с помощью предварительного общего пароля? Это может быть сделано без хранения на стороне клиента. Я верю, что именно это @erickson говорил в своем последнем абзаце.

Answer 4

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

• При шифровании закрытого ключа используйте что-то вроде PBKDF2 с солью и довольно большим числом итераций.
• Это, вероятно, подразумевается, но вместо шифрования с открытым ключом, вероятно, имеет смысл генерировать случайный ключ (например, 32 байта случайных данных, если используется, например, AES-256). Зашифруйте сообщение этим ключом, зашифруйте ключ открытым ключом и отправьте обе части.
• Как описано, идентификация отправителя отсутствует. Это позволяет отправлять чисто анонимные сообщения. Это может быть предназначено, но если нет, то потребуется какая-то идентификация / аутентификация.
• Несколько похоже на предыдущую запись, аутентификация сообщений не описана. Злоумышленник может изменить зашифрованное сообщение, и получатель не сможет сказать, что оно было изменено. Хотя, если это текстовое сообщение, было бы довольно ясно, что оно было изменено, потому что это был бы просто искаженный текст. Однако существуют некоторые типы данных, которые не так легко определить, если они были изменены.