Jamm

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

Надо бы в краткой форме формализовать систему в том виде, в котором вижу её я.

Итак, кратенько суть проблемы

Интернет это открытая сеть. То есть, если вы не защищаете свои сообщения, то они могут быть прочитаны неизвестной группой лиц. Либо даже всего лишь одним ушлым админом. Чаще всего шифрование используется только для связи с сервером того, или иного сервиса. Например, с почтовым сервером. Ваше сообщение в зашифрованном виде дошло до сервера, там расшифровалось и легло на диск. Потом оно полетело на другой сервер. Это может быть другой сервер этой же почтовой службы, а может и другой службы. Но даже сам Google до этого года не использовал шифрование при передаче данных между своими серверами. Их читали все спецслужбы, какие могли дотянуться до кабеля. В России до сих пор так. В других странах, судя по всему, тоже наплевательски относятся к вашим сообщениям, да еще и вычисляют в круглосуточном режиме ваши предпочтения, покупки, сайты, комментарии, политические взгляды, уровень заработка, уровень владения языками, да и много чего еще…

Я, конечно, понимаю, что существует куча людей, кто не в состоянии задуматься о том, насколько важна приватность переписки. Многие говорят, что им нечего скрывать. Я понимаю, быдла больше, чем думающих людей им наплевать на свою жизнь. Но, они тоже могут столкнуться с ситуацией, когда им надо будет передать «очень секретный пароль» от «очень секретного» файла, компьютера, или базы данных. Глупый отправит почтой, умный хотя бы задумается.

Шифрование сообщений

Два пути

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

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

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

Инфраструктура ключей

Для хранения и распространения ключей пользователей требуется создание специальной инфраструктуры. Тут есть один довольно интересный факт — ни одна компания до сих пор её не создала. И я не думаю, что это потому, что это очень сложно, или совсем невозможно. Почему-то, они не желают этого делать. (Домашнее задание: подумать, почему.)

Защита

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

1. Взлом сервера с базой ключей, подмена в базе
2. Подмена ключа на пути следования к пользователю, либо к серверу (Man in the middle)
3. Кража приватного ключа из устройства пользователя (например, из протрояненого смартфона)

Защита от взлома сервера, подмены в базе и перехвата-подмены трафика

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

Всё это шифруется закрытым ключом второго сервера. Назовем его Jamm 2. Этот сервер находится в другой стране, отзывается только серверу Jamm 1, либо вообще только через сеть Tor.

Созданный ключ пользователя перед попаданием в базу ключей проходит следующие стадии:

• Открытый ключ вместе с идентификатором пользователя (userId, например, e-Mail) отправляется на Jamm 1 (публичный сервер).
• Jamm 1 отсылает его на Jamm 2
• Jamm 2 запоминает его во временной базе с идентификатором и рандомным кодом
• Jamm 2 отсылает код и идентификатор (e-Mail) серверу Jamm 3 (только почта, для сокрытия настоящего местоположения Jamm 2)
• Jamm 3 отсылает письмо с кодом на почту пользователя
• Пользователь вводит код в клиенте (всего лишь один шаг, требующий действий от пользователя, после генерации ключей)
• Клиент отправляет userId и код на Jamm 1
• Jamm 1 отправляет его на Jamm 2, подтверждая, что пользователь владеет указанным почтовым ящиком (идентификатором)
• Jamm 2 шифрует ключ пользователя с его идентификатором и рандомом. Отправляет его как ответ на Jamm 1.
• Jamm 1 в подтверждение нормально прошедшей операции отправляет клиенту пользователя его полностью готовый, зашифрованный ключ, как отправляется другим пользователям.
• Клиент расшифровывает его открытым ключом Jamm 2, сверяет со своими данными, извещает пользователя о результате.

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

Кража ключа с устройства пользователя (смартфона, компьютера)

Закрытый ключ пользователя будет храниться в приватной папке приложения в зашифрованном виде. Для расшифровки будет применяться пароль пользователя, который будет запрашиваться при каждом запуске приложения, или по истечении специального периода — 10-15 минут. Сообщения же, естественно, будут храниться в зашифрованном виде.

 

Продолжение следует.