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

Question

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

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

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

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

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

Спасибо :)

Answer 1

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

Это не сработает.

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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