Что может предложить экспериментальная система коммуникаций для защиты от MITM-атак

    Специалист Техасского университета в Остине и Нью-Йоркского университета вместе с экспертом исследовательского подразделения MSR предложили оригинальный подход к разработке систем связи. Обсуждаем особенности и ограничения пробного протокола.

    Unsplash / Jon Tyson
    Unsplash / Jon Tyson

    Как она может работать

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

    Он поддерживает большее число пользователей по сравнению с аналогами и не боится компрометации систем, обслуживающих проект. В случае экспериментального Pung-кластера — это четыре севера с пропускной способностью в 135 тыс. сообщений пользователей в минуту.

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

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

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

    Unsplash / Daria Nepriakhina
    Unsplash / Daria Nepriakhina

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


    Дополнительное чтение у нас на Хабре:


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

    Зачем все это нужно

    Ранее мы рассказывали о MITM-атаках на стороне некоторых европейских провайдеров, когда службы правопорядка загружали в их сеть программное обеспечение, позволяющее подменять обновления ПО. Подобные практики отмечали и в WikiLeaks. Еще мы говорили о том, как провайдеры торгуют метаданными клиентов, и попытках Фонда электронных рубежей (EFF) урегулировать подобные практики. Внедрение оптимизированной версии Pung или его альтернативы могло бы защитить пользовательские данные на уровне протокола.

    Unsplash / Jaroslav Devia
    Unsplash / Jaroslav Devia

    Еще Pung теоретически можно было бы адаптировать для медиа и соцсетей, где присутствует возможность публикации анонимных постов и обмена сообщениями. Однако глобальные проекты в этой области скорее всего будут вынуждены пойти по пути ввода ограничений на end-to-end шифрование, которое сейчас обсуждают регуляторы и спецслужбы. В таком случае разговоры о защите метаданных и содержимого переписки на некоторое время потеряют какой-либо смысл.


    Что еще почитать у нас в блоге:


    VAS Experts
    Разработчик платформы глубокого анализа трафика

    Комментарии 5

      +2
      Лейбл переписки может по аналогии быть идентификатором подписки на какой-либо информационный источник (скрыть возможность отслеживания того, что и кто читает), если развивать тему с использованием в медиа. Но при текущей реализации с регулярными броадкастами может быть еще больше проблем с «лишним»/служебным трафиком
        0
        Из статьи нифига непонятно. Изобрели аналог email в котором шифрованы заголовки?
          +1

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

            0

            Все равно не понятно, как это защитит от MITM, которая основана на том, что в системе пользователя есть сертификат, благодаря которому протокол начинает доверять промежуточному съемнику трафика. Что здесь принципиально иначе?


            Возможно, здесь решается проблема не MITM, а DPI, когда протокол генерирует псевдо-диалоги, чтобы обмануть сигнатуры..


            А насчет изоляции между сервером и id пользователей через лейблы — это только в голом концепте выглядит реально. Интерфейс пользователя, авторизация через номер телефона или просто возможность зайти в свои диалоги с разных устройств — это вынудит все равно держать связки пользователя и лейблов где-то на сервере

              +1

              Тут trustless система, допускающая компрометацию самого кластера. А про проблему входа и первого сообщения тут сказано, как и в ограничениях в научной статье. Я думаю, что с того момента уже кто-то мог предложить решения, надо смотреть

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое