id: Гость   вход   регистрация
текущее время 02:26 26/04/2024
создать
просмотр
редакции
ссылки

24.03 // MoP-2-MoP: приватный мобильный микроблоггинг


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


Проблему связи в экстремальных условиях рассмотрела группа немецких исследователей Marius Senftleben, Mihai Bucicoiu1, Erik Tews, Frederik Armknecht, Stefan Katzenbeisser и Ahmad-Reza Sadeghi, представляющих центр совместных исследований в области безопасных вычислений Intel (ICRI-SC), Технический Университет Дармштадт, центр углублённого изучения проблем безопасности (CASED) и Университет Манхейм при частичном спонсировании от министерства труда Румынии. Для решения этой задачи ими был педставлен протокол мобильного приватного микроблогинга MoP-2-MoP.


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


Если вместо централизованного сервиса использовать распределённые сети обмена данными (P2P), то для доставки сообщения с задержками смартфон может выбрать подходящую стратегию использования каналов связи в зависимости от ситуации.


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


Mop2Mop (36 Кб)


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


Рэндомизированное перешифрование играет при этом важную роль. Оно представляет собой возможность перешифровать кем-то ранее защифрованный текст без знания публичного ключа получателя. Авторы предлагают использовать этот блок построения протокола на основе одной из схем Эль-Гамаля. При этом, используются групповые ключи доверия, обмен которыми строится на социальных взаимодействиях.


Более чётко три требования приватного мобильного микроблоггинга сформулированы исследователями таким образом:


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


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


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


Противник может действовать на уровне глобальных сетей (Wide Area Network) и локальных коммуникаций через P2P-сети. Подразумевается, что противник не может взламывать криптопримитивы, но обладает следующими возможностями:


  • Все WAN находятся под полным пассивным контролем операторов противника. Противник осуществляет мониторинг и логирование всех каналов связи.
  • У противника существует и может быть задействован рубильник (kill-switch), отключающий все каналы связи WAN.
  • Против локальных P2P-соединений противник может использовать ограниченный арсенал мониторинга, логирования и глушения.
  • Узлы P2P нескомпрометированы.

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


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


Групповой ключ (как закрытый, так и открытый) является общим для группы, его сборка происходит по частям в результате работы протокола разделения секрета. Пользователь, имеющий больше доверия в группе, получает больше частей для сборки. Аналогично происходит и с групповым HMAC-ключом. К сожалению, широковещательная криптография, с возможностью использовать индивидуальные ключи в группе, не предусмотрена. Поэтому в случае компрометации, групповой ключ должен быть заменён.


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


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


Исследователями проведено моделирование поведения разных групп на площадке 0.16 km2. Выполнен тестовый Java-клиент для платформы Android. Ими отмечено, что из-за перешифровки сообщений приватность групп сохраняется, но возникает побочный канал утечки сведений о членстве в группе по количеству синхронизированных сообщений, что может быть использовано противником, плотно прослушивающим значительную часть группы. Методы перекрытия этого канала утечки оставлены авторами в планах на исследование в последующих работах.


Анонимное множество асимптотически приближается к 100% по мере логистического охвата всех узлов сети. Результата 95% можно достичь за 9 раундов обмена. Вероятность доставки сообщений остаётся на приемлемом уровне при локальном глушении половины всех узлов на каждом раунде.


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


Спам-сообщения могут быть отфильтрованы только на уровне расшифровки при получении в группе и промаркированы фильтром, а фальшивые шифртексты, которые не могут быть расшифрованы ни одной группой, эффективно забивают буфер сообщений и позволяют проводить DoS-атаки. Также, как и обычным DoS-атакам, им нелегко противостоять, но существует возможность выявлять и вносить в чёрный список узлы, распространяющие такие сообщения.


Работа исследователей была представлена на конференции по финансовой криптографии и безопасности данных в марте 2014 года.


Источник: Центр совместных исследований в области безопасных вычислений Intel.


См. также: Проект Rangzen обеспечит уклонение от отключения властями каналов связи и электричества.


 
На страницу: 1, 2, 3 След.
Комментарии [скрыть комментарии/форму]
— unknown (01/04/2014 10:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Оказывается, даже через твиттер можно вести относительно содержательные дискуссии, если использовать ёмкие короткие фразы с сокращениями, аккуратно подбирать ссылки и хэштеги:
filehttp://cryptome.org/2014/03/snowden-redactions.pdf
filehttp://cryptome.org/2014/03/snowden-redactions-02.pdf
— Гость (01/04/2014 12:14)   <#>

А ещё можно сжимать, шифровать, в base64 кодировать. Ведь можно?
— Гость (01/04/2014 17:05)   <#>

https://www.linux.org.ru/people/spinore/profile
Это традиция.
— unknown (01/04/2014 17:46, исправлен 01/04/2014 17:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Для корректного шифрования нужно передать блок вектора инициализации (128-бит) в начале сообщения и код аутентификации (128 бит) в конце. Т.е. 32 байта. После преобразования в base64 на это будет израсходовано где-то в 1.5 раза больше — 48 символов.

— SATtva (01/04/2014 18:18)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Когда нет ограничения на набор символов кодировки (как в том же твиттере), есть смысл использовать base85.
— Гость (26/05/2014 01:12)   <#>

Не очень понял, о чём это. Есть ли возможность прочитать зашифрованное сообщение всеми, а не только какой-то конкретной группой, владеющей ключами? Один из самых распространённых сценариев — читать могут все, а писать — только члены группы, причём получатели могут проверить, действительно ли сообщение подписано групповым ключом (кольцевые подписи или как их там).
— unknown (26/05/2014 09:39, исправлен 26/05/2014 09:41)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Broadcast Encryption.


В основном рассматривают коммерческую сферу широковещательной криптографии: DRM видеоканалов. Но есть и обычная, и военная. И даже широковещательная стеганография. Идея в том, из группы n абонентов надо передать сообщение некому подмножеству из списка m. Чтобы не шифровать сообщение ключом каждого получателя, используется протокол, который позволяет включить абонентов в подгруппу и уменьшить количество накладных расходов на шифрование. Т.е. прочитать могут все из выделенной подгруппы m, но для этого сообщение не шифруется каждому персонально.


И это не такие примитивные протоколы, как шифрование сеансового симметричного ключа всеми асимметричными ключами получателей, что реализовано в OpenPGP. Используются системы уравнений, полиномы, аналоги схем разделения секрета, предвычисления по пересечению множеств, деревья хэшей. Есть инф.-теоретически стойкий броадкастинг для шифрования (включения в подгруппу, но не самого шифрования) и пр.

— Гость (26/05/2014 17:48)   <#>

У меня сложилось впечатление, что для шифрованных чатов и рассылок это не используется, вместо этого берут те самые кустарные примитивные протоколы на основе OpenPGP (что странно, раз разработаны более эффективные методы). Или я не прав?
— unknown (26/05/2014 18:00, исправлен 26/05/2014 18:02)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Всё верно. Большинство используемых протоколов — они такие :)



Можете глянуть fileслайды. Эти методы оправданы только для экономии ресурсов при большом числе абонентов.

— Гость (26/05/2014 18:39)   <#>

Там не сказано, при насколько большом. Одна сотня абонентов — это много или мало?
— unknown (26/05/2014 21:49)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Сложный вопрос. Количество абонентов — лишь один из параметров. А ещё важны вычислительные мощности. Например, маломощные смарткарты, выделяющие ключ из потока для передачи его в приёмник платного TV. В приёмнике мощный процессор, но для за-DRM-ливания протокол выделения ключа исполняется в смарткарте, которая условно невзламываема. Или есть крошечные микропроцессоры умных датчиков-счётчиков. Другой вопрос, насколько критичны задержки? Если это видео или поток управления какими-то системами. Насколько узкий канал для передачи ключа? Может можно слать гигабайты данных, но нельзя прерывать передачу мегабайтами копий шифрованного ключа для всех абонентов и др.

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

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

Broadcasting/Multicasting crypto и вообще способы управления ключами и криптоданными в группах — целое обширное направление с множеством протоколов, со своей терминологией, системой доказательств и пр. Слайды, которые приведены выше, опираются ещё на работу 1993 года. С тех пор ещё много чего разрабатывалось.
— Гость (27/05/2014 12:03)   <#>
Я имел в виду, что адаптировать такие протоколы в рамках небольших любительских сообществ (всё исполняется на ПК), судя по всему, имело бы смысл. Просто подумалось, что эти протоколы настолько сложны и громоздки, что даже в этом случае вряд ли стоило бы с ними связываться. Однако, судя по вашим дальнейшим пояснениям, это не так.
— unknown (27/05/2014 13:11, исправлен 27/05/2014 13:12)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

В этом вопросе не опирайтесь на мои объяснения всерьёз :) Я перечитал некоторое количество работ и даже диссеров по сотне-другой страниц по теме, но только составил общее впечатление как об интересном направлении. На заданные вами простые вопросы я могу ответить откровенную глупость, поскольку сейчас этой темой не занят, а подымать соответствующую литературу не готов.


Вот так поставили вопрос про PFS и отрицаемость, развернулась долгая дискуссия, были перерыты тонны первоисточников и для себя я решил и готов аргументировать, что тема обоснованно сложная в плане доказательств, потому и не внедряется, несмотря на вал исследований и обилие протоколов. Аналогично было в многочисленных дискуссиях по шумовому крипто в качестве дешёвой альтернативы квантовому. Годы ушли на построение и понимание общей картины. Там мне больше объяснил spinore, да ещё что-то, похоже разузнав у своих коллег — мне скорее пришлось принять его доводы. Сам бы я, возможно и не догадался сделать некие смелые выводы.


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

— Гость (27/05/2014 13:39)   <#>

Я внимательно не прочитывал тот топик, но у меня сложилось впечатление, что есть какие-то протоколы, их можно реализовать (что gegel и хочет сделать), вот только безопасность этих протоколов несколько сомнительна. Впрочем, лучше уж, наверно, такие протоколы, чем вообще никаких.


Да, может быть и так. Смысл ваших замечаний понятен.
— Гость (27/05/2014 13:52)   <#>

Припоминая ваш комментарий

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

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

подумалось, что Broadcasting/Multicasting crypto как раз может быть реализовано через шумовое в определённых случаях типа военной сферы. Т.е. есть множество военных единиц непонятно где находящихся, новые единицы могут вводиться в строй, а старые выводиться (из-за предательства или ещё каких причин), т.е. группа непостоянна. Канал связи, к примеру, односторонний — транслирование команд центра для запуска ракет или ещё чего-нибудь.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3