Здравствуйте, коллеги.
На “тимбилдинге”, возник такой вопрос, а возможно ли организовать такой сервис обмена сообщений, в котором невозможно было бы прочитать сообщения даже имея возможность модифицировать код сервиса, без знания пароля пользователей.
Видится такая схема:
На клиенте задается логин, пароль, генерятся соль, ключи для RSA Kpub, Kpr, приватный ключ зашифровывается с помощью пароля и соли и таким образом на сервере для каждого пользователя храниться:
соль, публичный ключ и зашифрованный приватный.
Процесс отправки сообщения выглядит так:
Клиент через TLS/SSL соединяется с сервером, проходит какая-то авторизация, сервер удостоверяется что клиент это тот самый клиент, дальше сервер посылает клиенту открытый ключ адресата, и затем клиент шифрует сообщение открытым ключом (или генерирует ключ для АЕS им шифрует письмо, а сам ключ AES уже шифрует открытым ключом адресата), и шифрованное сообщение отправляется на сервер, где его получит адресат, который сначала своим паролём расшифрует свой приватный ключ и следом текст сообщения.
В такой схеме данные на сервере хранятся зашифрованными, ключей к расшифровке сообщений на сервере нет, без знания пароля клиента, расшифровать тексты писем за исключением брутфорса нельзя. Но все ровно это не защищает от того, что на сервере могут установить “MITM” в котором будут отдавать открытый ключ не адресата, а “свой”, таким образом прослушивая переписку. Выглядит так что это не решаемая задача, либо каждый участник переписки должен иметь подписанные своим сертификатом открытые ключи, что конечно не масштабируемо на миллионы пользователей.
Здравствуйте, JacobR, Вы писали:
JR>На “тимбилдинге”, возник такой вопрос, а возможно ли организовать такой сервис обмена сообщений, в котором невозможно было бы прочитать сообщения даже имея возможность модифицировать код сервиса, без знания пароля пользователей.
Это называется end to end encryption.
JR>Видится такая схема:
JR>На клиенте задается логин, пароль, генерятся соль, ключи для RSA Kpub, Kpr, приватный ключ зашифровывается с помощью пароля и соли и таким образом на сервере для каждого пользователя храниться:
JR>соль, публичный ключ и зашифрованный приватный.
JR>Процесс отправки сообщения выглядит так:
JR>Клиент через TLS/SSL соединяется с сервером, проходит какая-то авторизация, сервер удостоверяется что клиент это тот самый клиент, дальше сервер посылает клиенту открытый ключ адресата, и затем клиент шифрует сообщение открытым ключом (или генерирует ключ для АЕS им шифрует письмо, а сам ключ AES уже шифрует открытым ключом адресата), и шифрованное сообщение отправляется на сервер, где его получит адресат, который сначала своим паролём расшифрует свой приватный ключ и следом текст сообщения.
JR>В такой схеме данные на сервере хранятся зашифрованными, ключей к расшифровке сообщений на сервере нет, без знания пароля клиента, расшифровать тексты писем за исключением брутфорса нельзя. Но все ровно это не защищает от того, что на сервере могут установить “MITM” в котором будут отдавать открытый ключ не адресата, а “свой”, таким образом прослушивая переписку. Выглядит так что это не решаемая задача, либо каждый участник переписки должен иметь подписанные своим сертификатом открытые ключи, что конечно не масштабируемо на миллионы пользователей.
В целом я рекомендую не изобретать свои протоколы. Почитайте документацию Signal-а, там современные криптографические схемы.
https://signal.org/docs/ Скажем в вашей схеме сразу очевидно отсутствие защиты от повтора, т.е. сервер сможет сохранить зашифрованное сообщение и в какой-то момент переслать его повторно (или не пересылать в первый раз). Это, конечно, относительно легко исправляется, но лучше пользоваться схемами, в которых всё исправлено.
Чтобы сервер не отдавал чужой ключ, вы должны сверять публичные ключи вручную (через альтернативный канал, либо же способом, затрудняющим подделку, к примеру продиктовать хеш своего ключа голосом). Если не хотите сверять вручную — есть ещё два варианта — Certificate Authorities, когда есть авторитетные источники, которые удостоверяют, что данный сертификат действительно принадлежит такому-то человеку, а также Web of Trust, когда, например, вы обменялись ключами с первым товарищем, первый товарищ обменялся ключами со вторым товарищем, и теперь у вас есть цепочка доверия до второго товарища, с ним уже не нужно обмениваться ключами.
В популярных мессенджерах используется только первый вариант.
Второй вариант используется в HTTPS, в мессенджерах без дополнительной инфраструктуры им будет пользоваться затруднительно. Но, например, в Казахстане есть центральный орган, выдающий сертификаты гражданам, мессенджер может интегрироваться с такими сертификатами и использовать их, как авторитетный источник. В России и во многих других странах есть похожие структуры.
Ещё можно использовать в качестве авторитетного источника такую схему: независимый сервис отправляет токен через SMS, вы этот токен подписываете своим ключом и отправляете товарищу. Товарищ с независимым сервисом удостоверяет, что этот токен соответствует вашему телефону. То же можно сделать с e-mail, rsdn account, github account и кучей других вариантов. Можете посмотреть в сторону keybase как агрегатора.
Третий вариант используется в GPG. Его главная проблема — подавляющее большинство пользователей плевать хотело на приватность, безопасность и тд, поэтому в реальности из ваших ста контактов никто никого удостоверять не будет. А тот, кто будет, вполне может это сделать внутри того же чата, что, естественно, сводит ценность такого удостоверения к нулю, а учитывая, что вы на него будете полагаться, в итоге к отрицательному значению.
