Доверенные программы для обмена сообщениями

Какими базовыми свойствами должно обладать приложение (например, для смартфона) и соответствующий сервис, которые претендуют на роль современного суперзащищённого мессенджера? Часть “супер-” – здесь важна. Это не конкретные технические свойства, а, скорее, свойства-признаки, позволяющие строить предположения о реальной безопасности и “приватности” приложения. Дело в том, что про такие приложения периодически делают какие-то заявления, в стиле, что “разработали” или “разработают”, но далеко не всегда заявления сопровождаются подробным содержательным описанием проекта. Все приведённые ниже свойства довольно трудно реализовать, а сам список – скорее иллюстрирует сложность построения системы. Возможно, подобных популярных приложений пока не появилось именно по причине этой сложности.

Естественно, конкретный набор свойств, их интерпретация – зависят от выбранной модели угроз. В нашем случае, с целью экономии букв, конкретная модель угроз вынесена за скобки. Так как описываемые свойства это не технические требования, а признаки, позволяющие составить предварительное мнение о степени безопасности конкретного типа приложения, просто встанем на “фольклорную” точку зрения и предположим, что гипотетический мессенджер должен защищать от продвинутого технического противника, который перехватывает и подменяет трафик, а также может проводить другие активные атаки на любых технических уровнях. Поэтому в список даже не входят рассуждения о том, что типичный смартфон-носитель не контролируется его пользователем, а уже одно это легко сводит к нулю все утверждения о защищённости приложения.

Итак, список свойств. Некоторые из них совсем очевидны, некоторые – очевидны в меньшей степени, есть и неочевидные.

1. Ни в каком виде не должно быть авторизации по телефонному номеру. Тем более – привязки аккаунта к телефонному номеру. Телефонный номер – это ресурс оператора связи. Следует считать, что оператор связи решает собственные задачи и вовсе не собирается участвовать в обеспечении безопасности очередного “безопасного” мессенджера.

2. Не должно быть централизованного инструмента для “восстановления аккаунта”. То есть, если пользователь совсем потерял все свои реквизиты доступа, то, к сожалению, это означает, что он потерял и доступ, без возможности восстановления. Дело в том, что наличие централизованного инструмента восстановления аккаунта (типа, “получите код в SMS”), означает, что внутри мессенджера встроен механизм перехвата аккаунтов. Ключевое понятие здесь: “централизованный”. Это, естественно, не отменяет дополнительных резервных реквизитов и защищённых распределённых инструментов восстановления доступа.

3. Идентификация аккаунта проводится по отпечатку некоторого криптографического ключа (или “токена”), секретная часть которого находится у пользователя. Этот принцип соблюдается далеко не всегда, но только такой вариант позволяет разделить “адресацию” на уровне сообщений пользователей и всю прочую адресацию (IP-адреса узлов, доменные имена, телефонные номера и пр.). Привязка идентификатора к реальному пользователю происходит за пределами мессенджера.

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

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

6. Исходный код приложений (клиентских, серверных, “промежуточных” и пр.) должен быть открыт и опубликован. Так сказать, в “максимальной разумной общности”: то есть, вместе со всеми “дополнительными библиотеками”, если таковые используются существенным образом. Это не означает, что нужно включать в состав кода приложения, скажем, реализацию IP из модулей ядра ОС: потому что логика мессенджера не должна зависеть от реализации сетевого транспорта. Публикация исходных кодов, пожалуй, самый непрозрачный момент. С одной стороны – само по себе раскрытие исходников не гарантирует ни отсутствия ошибок, ни отсутствия закладок (да и вообще ничего не гарантирует); с другой – ожидать, в данном случае, какой-то особой защищённости от приложения с закрытым кодом ещё труднее (см. следующий пункт). Код должен быть обозримым (а этого трудно достигнуть).

7. Необходимо наличие документированной и открытой процедуры, которая позволяет из исходного кода получить исполняемый код и проверить, что, во-первых, получилось то, что планировалось, во-вторых, что у всех пользователей получились одинаковые (возможно, с точностью до платформы и окружения) приложения. К сожалению, точное выполнение этого пункта на практике недостижимо, если говорить о сколь-нибудь сложном приложении. Но можно попытаться приблизиться. Понятно, что в процесс доверенной сборки должны включаться и доверенные компиляторы/интерпретаторы. С другой стороны – очевидно, что даже совпадающие побайтно исполняемые файлы могут вести себя различным образом при исполнении в конкретных условиях (зависит от входных данных, системного окружения и т.д.). Однако в публикации неких исходных кодов без проверки того, что используемое всеми приложение действительно как-то с этими кодами связано, тоже смысла не так много, как хотелось бы. Ну, если говорить о гипотетическом суперзащищённом приложении, на практике-то – с лёгкостью используются “бинарники” из дистрибутива ОС.

8. Приложение должно быть максимально независимым от аппаратной платформы и операционной системы. То есть, не должно быть, например, строгой привязки к конкретному “типу смартфонов” или к конкретной компании-разработчику, которая, скажем, славится громкими заявлениями о “своей приверженности обеспечению приватности пользователей”. Вообще, всякая подобная привязка должна наводить на подозрения, что не так всё просто с этим “супербезопасным мессенджером”.

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

Адрес записки: https://dxdt.ru/2021/09/05/9093/

Похожие записки:



Далее - мнения и дискуссии

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

Комментарии читателей блога: 9

  • 1. 5th September 2021, 14:12 // Читатель fdsc написал:

    Мда. Осталось только, чтобы кто-то это сделал.
    Последний пункт не является пунктом, связанным с безопасностью.
    Это, скорее, обеспечение доступности для всех пользователей.

    Я бы также отметил, что
    1. Приложение должно повзолять работать через TOR
    2. Приложение не должно требовать открытых входящих портов: сейчас от операторов связи не допросишься
    3. В идеале, приложение должно быть возможно разделить на части: одна часть сетевая, вторая – шифрующая. Чтобы шифрующая часть могла быть запущена в доверенном окружении и никуда не могла передать данные.
    4. Приложение должно обращаться к опубликованным заранее доменным именам. Если оно обращается к IP-адресам, я должен понимать, к каким и как разграничить к ним доступ. Это касается централизованных приложений.

  • 2. 5th September 2021, 15:10 // Читатель Skwiz написал:

    Интересный вопрос – где хранить привязку пользователя к IP? Это тоже элемент безопасности.
    И самый главный – как с этого зарабатывать деньги? :)

  • 3. 5th September 2021, 18:24 // Читатель fdsc написал:

    Skwiz, привязка пользователя к IP в таких системах практически невозможна. Ведь пользователь может выходить с мобильных устройств или через TOR или прокси.
    Поэтому никакой привязки к IP там быть не может.

  • 4. 5th September 2021, 23:37 // Читатель yshurik написал:

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

    Может добавите пункт 10) про устойчивость к идентификации самого факта общения по таймингу?

  • 5. 6th September 2021, 13:34 // Александр Венедюхин:

    > Может добавите пункт 10) про устойчивость к идентификации самого факта общения по таймингу?

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

  • 6. 6th September 2021, 17:15 // Читатель fdsc написал:

    Я так понимаю, BitMessage загнулся. Впечатление, что разработчики, после эксплоита, его забросили.

    Кстати, ещё одно требование, которое можно предъявить к чату, это то, что он не должен быть разработан на базе языков C, C++, Assembler. Желательно, чтобы язык был со сборщиком мусора.

  • 7. 7th September 2021, 16:56 // Читатель yshurik написал:

    > Я так понимаю, BitMessage загнулся. Впечатление, что разработчики, после эксплоита, его забросили.

    И да и нет, дальнейшей разработки оригинального клиента похоже нету. Но протокол и сеть никуда не делись и в использовании. К тому же есть альтернативные клиенты, например notbit, а к нему удобная обвязка (https://github.com/yshurik/docker-bitmessage) для почтовика.

  • 8. 12th September 2021, 16:46 // Читатель yshurik написал:

    Таки нет, я был не прав, BitMessage в активной разработке судя по сообщениям Peter Surda в reddit, но публичных релизов пока не было. Из последнего eсть appimage для linux версий в разработке. Ждем обновлений.

  • 9. 6th March 2022, 22:39 // Читатель ValdikSS написал:

    Такие средства связи существуют, они не единичны. Двумя самыми массовыми из возможных вариантов можно назвать протоколы XMPP и Matrix, и современные клиенты к ним, при условии поднятия своего собственного сервера. Они удовлетворяют всем условиям, кроме третьего — идентификация пользователя происходит по идентификатору имя@домен, а домен, как и телефонный номер, нельзя купить, а можно только арендовать.

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

Написать комментарий

Ваш комментарий:

Введите ключевое слово "662RZ" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

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