Сообщение Re: Защищённый сервис обмена сообщениями от 11.10.2021 13:29
Изменено 11.10.2021 13:33 vsb
Re: Защищённый сервис обмена сообщениями
Здравствуйте, 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. Его главная проблема — подавляющее большинство пользователей плевать хотело на приватность, безопасность и тд, поэтому в реальности из ваших ста контактов никто никого удостоверять не будет. А тот, кто будет, вполне может это сделать внутри того же чата, что, естественно, сводит ценность такого удостоверения к нулю, а учитывая, что вы на него будете полагаться, в итоге к отрицательному значению.
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. Его главная проблема — подавляющее большинство пользователей плевать хотело на приватность, безопасность и тд, поэтому в реальности из ваших ста контактов никто никого удостоверять не будет. А тот, кто будет, вполне может это сделать внутри того же чата, что, естественно, сводит ценность такого удостоверения к нулю, а учитывая, что вы на него будете полагаться, в итоге к отрицательному значению.
Re: Защищённый сервис обмена сообщениями
Здравствуйте, 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. Его главная проблема — подавляющее большинство пользователей плевать хотело на приватность, безопасность и тд, поэтому в реальности из ваших ста контактов никто никого удостоверять не будет. А тот, кто будет, вполне может это сделать внутри того же чата, что, естественно, сводит ценность такого удостоверения к нулю, а учитывая, что вы на него будете полагаться, в итоге к отрицательному значению.
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. Его главная проблема — подавляющее большинство пользователей плевать хотело на приватность, безопасность и тд, поэтому в реальности из ваших ста контактов никто никого удостоверять не будет. А тот, кто будет, вполне может это сделать внутри того же чата, что, естественно, сводит ценность такого удостоверения к нулю, а учитывая, что вы на него будете полагаться, в итоге к отрицательному значению.