SoK: Secure Messaging .. на русском

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 21:52, 8 июня 2016.
SoK:Безопасный обмен сообщениями.[1]
Первый   появившийся 2015 г.
Портал: IEEE Computer Society's Technical Committee on Security and Privacy

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

Вступление

Самые популярные инструменты обмена сообщениями, используемые в Интернете, не предлагают полноценную безопасность. Даже такие протоколы, как OpenPGP и S / MIME доступные в течение десятилетий, не смогли достичь широкого распространения и были неудобны в использовании [2], [3], [4], [5].. Тем не менее, недавние откровения о массовом наблюдением спецслужб подчеркнули отсутствие безопасности и неприкосновенности частной жизни в инструментах обмена сообщениями и стимулировали спрос на лучшие решения. Недавний опрос Pew Research показал, что 80% американцев в настоящее время обеспокоены государственным контролем их электронными переписками. 68% респондентов сообщили, что ощущает себя "не очень безопасно" или "совсем не безопасно" при использовании онлайн-чатов и 57% считают аналогично используя электронную почту [6]. Следовательно, многие новые приложения, претендующие предложить безопасную связь, разработаны и приняты конечными пользователями.

Несмотря на публикации большого количества протоколов безопасного обмена сообщениями в научной литературе, инструменты выпускаются с новой конструкцией, которая не опирается на эти знания, поэтому она или повторяет известные конструкторские ошибки, или использует криптографию небезопасным способом. Однако, как станет ясно в течение этой статьи, научно исследовательское сообщество также не в состоянии усвоить некоторые уроки от инструментов в обыденной жизни. Кроме того, есть отсутствие согласованной концепции для будущего безопасного обмена сообщениями. Большинство решений сосредоточенны на конкретных вопросах и имеют разные цели и модели угроз. Это усугубляется различными словарями безопасности и отсутствие единой оценки уровня работы. Вне научного сообщества, многие продукты вводят в заблуждение пользователей, рекламируя с грандиозные заявки на «военный класс шифрования" или обещая невозможные функции, такие как самоуничтожающиеся сообщения[7], [8], [9],[10]. . Недавнее EFF Показатель Безопасности Обмена сообщениями оценивал у инструментов основные показатели безопасности и здоровья проекта [11] и нашел многих якобы "безопасных" инструменты, которые даже не пытаются полноценно шифровать.

Мы мотивированы систематизировать знания о безопасном обмене сообщениями в связи с отсутствием четкого победителя в гонке за широкое развертывание и сохранения многих затяжных нерешенных проблем исследования. Наша основная цель заключается в идентификации - где лежат проблемы и в создании руководства для научно-исследовательского сообщества, чтобы помочь двигаться вперед по этой важной теме. Еще одна цель в этой работе является создание критериев оценки для измерения функции безопасности систем обмена сообщениями, а также удобства их использования и принятия последствий. Мы стремимся предоставить широкий взгляд на безопасный обмен сообщениями и его проблем, а также сравнительной оценки существующих подходов, чтобы обеспечить контекст, в котором мы опишем будущие усилия. Наши основные взносы: (1) создание набора общих определений безопасности и конфиденциальных особенностей безопасного обмена сообщениями; (2) систематизация подходов безопасного обмена сообщениями, основанных как на научной работе и "обыденных" проектов; (3) сравнительная оценка этих подходов; и (4) определение и обсуждение текущих научно-исследовательских проблем, указывающих направления будущих исследований. Мы представим нашу методологию систематизации в Секции 2. В последующих разделах (разделах III-V), мы оцениваем каждую из предлагаемых проблемных зон (а именно установка доверия, разговорная безопасность и транспортная приватность), безопасного обмена сообщениями. Наши выводы обсуждены и заключены в разделе VI.

Методология систематизации

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

Проблемные области.

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

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

Модель угрозы.

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

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

Глобальный противник (активный / пассивный): злоумышленник, управляющий большими сегментами Интернета, такими как крупными интернет-провайдерами.

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

Структура систематизации

В разделах III-V оцениваем установку доверия, разговорную безопасность и транспортную приватность, соответственно. Для каждой проблемной области, мы разделяем желаемые свойства на три основные группы: обеспечение безопасности и конфиденциальности, особенности использования и соображения по выбору. Каждый раздел начинается с определения этих свойств с последующим извлечением общих подходов из существующих систем безопасного обмена сообщениями, используемых для решения проблемной области. Каждая секция затем определяет и оценивает эти подходы, а также несколько возможных вариаций, в терминах уже определенных свойств. Конкретные примеры протоколов или инструменты использования каждого подхода приводятся, когда это возможно. В конце раздела обсуждение последствий этих оценок как заключение .В каждом разделе, мы прикладываем таблицу (таблицы I, II, III) визуализирующую нашу оценку подходов в этой проблемной области. Столбцы в таблицах представляют выявленные свойства, в то время как ряды представляют подходы. Группа строк начинается с общей концепции, указанного в комбинации криптографических протоколов, с последующими расширенными строками, которые добавляют или изменяют компоненты базовой концепции. Всякий раз, когда это возможно, ряды содержат имя репрезентативного протокола или инструмента, который использует комбинацию концепций. Представители могут не достичь все функции, которые можно достичь с помощью подхода; Тогда они просто включены, чтобы указать, где подходы используются на практике. Каждая строка оценивается как обеспечивающая или не обеспечивающая требуемые свойства. В некоторых случаях, строка может только частично обеспечивать свойства, что объясняется в соответствующем описании. Из-за ограниченного пространства, обсуждение некоторых схем, описанных в таблице, было опущено. Подробная информация о них и их оценки включены в расширенной версии этой статьи [1]. .

Для каждой проблемной области, мы определяем желаемые свойства в трех основных категориях:

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

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

В предыдущем исследовании, различные инструменты безопасного обмена сообщениями были оценены и были выявлены недостатки в части HCI их конструкции. Плодотворная статья "Почему Джонни не может шифровать" [2] вместе с последующими исследованиями, оценивающих PGP инструменты[3], [4] и другие протоколы обмена сообщениями [12], [13], [14], [15], [16] также показали, что пользователи сталкиваются с проблемами, используя разрыв надежного шифрования. Тем не менее, эти исследования сосредоточены на вопросах пользовательского интерфейса, уникальных для конкретных реализаций. Так как мы сосредоточены на последствиях удобства, введенных на общих понятиях, наши результаты справедливы для любого инструмента, который реализует эти понятия.

Чтобы оценить удобство подходов безопасного обмена сообщениями, мы рассмотрим дополнительные усилия пользователя (и решения), ошибки, связанные с безопасностью, и снижение надежности и гибкости, к которому они приводят. Наши показатели удобства сравниваются с этими дополнительными усилиями для базового подхода с минимальной безопасностью или конфиденциальности возможностей. Это является сложной задачей, и обычные исследования пользователей не хорошо подходит для извлечения таких сравнений удобства на высоком уровне между разнородными инструментами. Мы использовали экспертные отзывы в виде когнитивных прохождений реальных реализаций для извлечения и систематизации аспектов удобства использования, основанных на принципах удобства использования Нильсена [17], [18], [19], что согласуется с предыдущими усилиями систематизации для схем безопасности в других областях [20], [21]. Эти результаты дополнили нашу техническую систематизацию и выявили потенциальные компромиссы между безопасностью и удобством использования.

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

Установка доверия

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

Особенности безопасности и конфиденциальности

Протокол установления доверия может предоставить следующее обеспечение безопасности и конфиденциальности:

Сеть профилактика MitM: Предотвращает Man-in-the-Middle (MitM) атаки со стороны местных и глобальных сетевых противников. Оператор профилактика MitM: Предотвращает MitM атаки, выполняемые операторами инфраструктуры. Оператор обнаружение MitM: Позволяет обнаруживать MitM атаки, выполняемые операторами, после того как они произошли. Оператор Подотчетность: Можно проверить, что операторы правильно повели себя во время установки доверия. Возможность ключевых аннулирований: Пользователи могут отозвать и возобновить ключи (например, чтобы восстановиться от утери ключа). Сохранение конфиденциальности: подход предотвращает утечку метаданных разговора другим участникам или даже операторам услуг.

Свойства удобства

Таблица 1. Компромиссы для комбинаций подходов установления доверия. Безопасные подходы часто жертвуют удобством и принятием.

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

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

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

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

Ключ простого восстановления: когда пользователи теряют информацию о долгосрочном ключ, легко отозвать старые ключи и инициализировать новые ключи (например, просто переустановить приложение или регенерировать ключи достаточно).

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

Нет Разделения Секретности: Разделения секретности требуют существующие социальные отношения. Это ограничивает возможности использования системы, так как не все коммуникационные партнеры могут разработать разделение секретности.

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

Немедленная Регистрация: Когда ключи (пере) инициализированы, другие участники сразу могут их проверить и использовать.

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

Свойства принятия

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

Не требуется провайдер услуг: Установка доверия не требует дополнительной инфраструктуры (например, ключевые серверы).

Не требуется аудит: подход не требует аудиторов для проверки правильности поведения операторов инфраструктуры.

Нет "имени на корточках": Пользователи могут выбрать себе имена и можно предотвратить большое количество популярных имен.

Асинхронность: Установка доверия может осуществляться асинхронно без всех участников разговора онлайн.

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

Оценка

Возможность шифрования (базовый): Мы считаем, возможность шифрования, в котором зашифрованная сессия устанавливается без ключа проверки, в качестве базового. Например, это может быть сеанс шифрования ОТР без аутентификации. Основная цель возможного шифрования - противостоять пассивным противников; активные атакующие могут легко выполнить MitM атаки. С точки зрения удобства, этот подход является базовым, поскольку он ни накладывает дополнительных затрат на пользователя, ни порождает новые ошибки или предупреждающие сообщения.

TOFU: Trust-On-First-Use (TOFU) расширяет возможность шифрование помня ранее встретившийся информации о ключе [22]. . Предотвращение сети MitM и инфраструктуры MitM только частично обеспечивается за счет требования, что злоумышленник не присутствует во время начального подключения. TOFU не требует обслуживания, так как ключи могут быть заменены участниками разговора напрямую. TOFU может быть реализовано в строгих и нестрогих формах. Строгая форма терпит неудачу, когда ключ меняется, обеспечивая устойчивость невнимательного пользователя, но предотвращая простое восстановление ключей. Нестрогая форма предлагает пользователям принять изменение ключа, обеспечивая легкое восстановление ключей за счет устойчивости к невнимательному пользователю. Подходы, основанные на TOFU, не требуют какого-либо взаимодействия с пользователем во время первоначального открытия контактов. Это дает хорошие результаты для всех свойств пользователя за исключением усилий для аннулирования свойств ключа , которые не определены, и обновления ключа без оповещния, так как пользователи не могут отличить доброкачественные изменения от ключевых MitM атак без дополнительных методов контроля. С точки зрения принятия, TOFU действует аналогично базовым методам во всём, кроме ключей восстановления в строгой версии и множественной поддержки ключей в обеих версиях. Проблемой множественной поддержки ключей связано с тем, что если используется несколько ключей, протокол не может найти различия между устройствами. Злоумышленник может утверждать, что используется новое устройство, с ключом атакующего.

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

Короткая последовательность аутентификации (SAS): Чтобы облегчить проверку отпечатков пальцев, короткие строки могут быть предоставлены пользователям для сравнения.SAS представляет собой усеченный криптографической хэш (например, длинные 20-30 бит) всех общественных частей обмена ключами. Часто представлены в формате, дружелюбном к пользователю, таким как короткая последовательность слов. Все участники вычисляют обмен ключами на SAS основе, за которым они следили, а затем сравнивают полученное значение с друг с другом. Метод, используемый для сравнения SAS должен аутентифицировать объекты, используя некоторые основной механизм установления доверия. ZRTP, и несколько ранее продукты, используют метод SAS, требуя участников прочитать вслух строки и, таким образом установка доверия была в возможности участников узнавания голосов друг друга voices [23], [24]. . Люди, которые никогда не слышали голоса друг друга, не могут проверить подлинность с помощью этого метода. Даже для пользователей, которые знакомы друг с другом, безопасность, обеспечиваемая голосовой идентификацией, была предметом споров [25], [26]. Недавние работы [27]показывают, что даже при наличии небольшого количества образцов голоса целевого пользователя, эти образцы могут быть синтезированы,и они не будут отличаются от голоса подлинного пользователя с обычным уровнем фонового шума.

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

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

Верификация, основанная на секретном нулевом знании: Socialist Millionaire Protocol (SMP) является нулевым знанием доказательства протокола знаний, который определяет, если тайные значения, проведенные двумя сторонами равны, не раскрывая само их значение. Этот протокол используется в OTR в качестве рекомендованного метода проверки пользователей. [28], [29].. Алиса ставит вопрос, основанный на совместном знаний Бобу внутри полосы и тайно записывает ее ответ. После Боб отвечает на вопрос, обе стороны выполняют SMP, чтобы определить совпадение их ответов не раскрывая никакой дополнительной информации. Ожидаются, что люди будут выбирать безопасные вопросы с ответами, основанные на совместном знаний, и злоумышленники не смогут их узнать или догадаться. Поскольку MitM необходимо выполнить онлайн атаку и можно догадка возможна только один раз, даже низкие секреты c минимальной энтропией достигают высокого уровня безопасности[29],[30]. Тем не менее, использование SMP жертвует асинхронностью, так как все участники должны быть в режиме онлайн во время проверки. Если протокол завершается неудачей, конечные пользователи не знают, совпадают ли их ответы, или существует злоумышленник с атакой MitM, сделавший неправильное предположение.

Обязательная проверка: ранее определенные методы верификации склонны к невнимательным пользователей. Подходы обязательного подтверждения используются против небрежности пользователя, требуя, чтобы пользователи введите правильные строки, отпечатков пальцев, а не просто подтверждали то, что они верны. Конечно, ввод отпечатков пальцев требует усилий пользователя. На практике, QR-коды и NFC популярные методы облегчают этот процесс. В SafeSlinger пользователь должен выбрать правильный ответ из трех вариантов, чтобы продолжить [31]. После завершения протокола, каждое устройство получает копию контактной информации совместно с другими участниками с гарантиями безопасности, включая конфиденциальность и аутентичность. Обязательное подтверждение наследует свойства удобства в подстилающей схеме. Включение обязательной проверки делает невозможным асинхронность, которая обеспечивает защиту невнимательных пользователей.

Доверие на основе авторизации: В схемах доверия на основе авторизации открытые ключи должны быть поручаться одному или более доверенным пользователем. Два известных примера это каталоги с открытым ключом и схемы сертификации.

С точки зрения безопасности, две схемы отличаются только в отзыве ключей и сохранении конфиденциальности. В то время как ключи обновляются в ключевых каталогах, подразумеватся отмена старых ключей, в подходе CA, сертификам, отмеченных доверенными пользователями, доверяют по умолчанию; списки отзыва должны быть сохранены отдельно. Тем не менее, списки отзыва на CA основе, используемые в веб-браузерах, как известно, имеют проблемы с эффективностью и практичностью [21], [32], [33] . С тех пор как сертификаты могут быть непосредственно заменены аналогами , подход на CA основе может сохранять конфиденциальность.

В любой системе, пользователи уязвимы для MitM атак со стороны доверенных пользователей, которые могут поручиться за или могут быть принуждены поручиться за, ложные ключи. Эта уязвимость была подчеркнута в последних CA скандалов [34], [35].. Обе схемы также может быть атакованы, если доверенные пользователи не проверяют ключи, прежде чем ручаться за них. Доверенные пользователи в услугаъ обмена сообщениями часто полагаются на проверку по незащищенной связи SMS или по электронной почте, что может быть потенциально атаковано.

Эти два подхода оба поддерживают достаточно удобны. Хорошо известные системы, использующие каталоги с открытыми, такие как IMessage, работают без какого-либо участия пользователя.

Прозрачность журналирования: Основная проблема с доверенной власти заключается в том, что она могут поручиться за мошеннические ключи во время атаки. Протокол Прозрачного Сертификата [36] требует, чтобы все выданные веб-сертификаты были включены в общественном журнале.

Прозрачность Сертификата это специальное предложение для логгирования сертификатов PKIX для TLS, но общая идея может быть применена к доверенной власти на основе установки доверия в безопасном обмене сообщениями. Мы ссылаемся на общую концепцию - прозрачное логгирование для оставшейся части статьи. Хотя нет никаких известных развертываний на сегодняшний день, Google планирует адаптировать прозрачное журналирование для пользовательских ключей в конец-в-конец, Это его будущий инструмент для шифрования электронной почты [37]. . При отсутствии конкретизации, мы оцениваем прозрачное журналирование на основе протокола прозрачности сертификата.

Основное улучшение безопасности двух схем состоит в ответственности оператора и обнаружения атак MITM-оператора после факта. Остальные функции безопасности унаследованы от систем, основанных на доверии к власти. Тем не менее, эти схемы внедряют новые и нерешенные вопросы удобства и принятие. Например, журналы должны быть проверены, чтобы гарантировать корректность, отрицая свойство отсутствия проверки. Услуги по проверке требуют протоколы общения синхронизировать вид между мониторами и предотвращать пузырчатые атаки (например, когда различные взгляды представлены различным географические регионам) ) [36]. Кроме того, поскольку только владельцы удостоверения в состоянии проверить правильность своих долгосрочных ключей, они разделяют ответственность за проверку правильного поведения журнале. Предыдущие исследования показали, что пользователи часто пренебрегают такими обязанности безопасности [38], так что это задача должна быть выполнена автоматически в клиентских приложениях. Тем не менее, если клиент обнаруживает сертификат в журнале, который отличается от их версии, не будет понятно,допустила ли власть атаку,или противник успешно изображал субъекта сертификата к власти, или, если объект на самом деле поддерживает несколько сертификатов (например, из-за установки приложения на втором устройстве). В конечном счете, конечные пользователи должны справиться с дополнительными предупреждениями о безопасности и ошибках, и еще предстоит определить, смогут ли они отличить доброкачественные и вредоносные отличия логов без подготовки. Кроме того, прозрачное журналирование может помешать немедленной заявки из-за задержек в распределении журнала. Улучшенный Сертификат прозрачность [39] и CONIKS [40] оба улучшают основную концепцию прозрачного журналирования, но еще были развернуты на практике.

Blockchains: В криптовалюте Биткоин используется новый механизм распространяемого консенсуса, используя псевдонимом "горняков", чтобы сохранить лог на только-добавление [41]. . Мощность голосования распределяется пропорционально вычислительным ресурсам с помощью вероятностного доказательства-работы пазла. Для валютного применения, этот журнал записывает каждую сделку, чтобы предотвратить двойной расход. Успех протокола консенсуса Bitcoin привела к энтузиазму, что подобные подходы могут поддерживать глобальный консенсус по другим типам данных, таких как отображение читаемых человеком имен пользователей к ключам.

Namecoin, первое ответвление Bitcoin, позволяет пользователям требовать идентификаторы, добавлять произвольные данные (например, с открытым ключом) как записи для тех идентификаторов, и даже продать контроль над их идентификаторами другим [42]. Namecoin и аналогичные blockchains с именным отображением обозначаются как blockchain в таблице I. В отличие от большинства других схем, Namecoin строго "первый пришел, первый обслужен", с любым пользователем в состоянии купить собственность любого количества невостребованных имен за маленькую, фиксированную плату за имя. Эта цена выплачивается в Namecoins - единица валюты, которая является неотъемлемой частью системы. Небольшая плата обслуживания требуется для поддержания контроля над именами, и малая плата может взиматься добытчиками(майнерами) для обновления данных или передачи права собственности имен

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

Тем не менее, различные недостатки возникают из удобства и принятия. Основное ограничение удобства и простоты использования является то, что если пользователи либо потеряют секретный ключ, используемый для регистрации своего имя (который не совпадает с ключом связи, связанного с этим именем), они окончательно утратят контроль над этим именем (т.е. восстановление ключа невозможно ). Аналогичным образом, если ключ скомпрометирован, имя может быть навсегда и безвозвратно угнано. Таким образом, система требует значительных усилий управления ключами и обременяет пользователей высокой ответственностью. Если пользователи полагаются на услуги веб-сервиса в управлении частныъ ключи для них, как делают многие с Bitcoin на практике, система больше не является конец-в-конец. Система требует, чтобы пользователи платили за то, чтобы зарезервировать и поддерживать имена, жертвуя низким ключом обслуживания и автоматической инициализации ключа. Пользователи также не могут мгновенно выдавать новые ключи для их идентификаторов (то есть, нет непосредственной регистрации), но требуется, чтобы они ждали, пока новый блока будет опубликован и подтвержден. На практике это может занять 10-60 минут в зависимости от желаемого уровня безопасности.

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

Наконец, существуют серьезные проблемы с "именами на корточках", которые страдают от ранних попыток использовать систему.Из-за того, что кто-нибудь может зарегистрировать хоть сколько имен, некоторые системы ввели ограничения на короткие и простые имена. Учитывая децентрализованный характер blockchains, это трудно решить, не поднимая регистрационные сборы, что повышает нагрузку на всех пользователей системы.

Другие подходы

Из-за нехватки места, мы опускаем оценки некоторых подходов в таблице I. читателям, незнакомых с веб-доверительными схемами можно обратиться к Приложению Б. Идентичность шифрования (IBE) и Keybase обсуждается в расширенной статье [1].

Обсуждение

В таблице I очевидно,что ни один подход к установлению доверия не является совершенным. В то время как известно, что удобство и простота использования и безопасность часто расходятся, наши результаты показывают, где именно компромиссы лгут. Подходы либо жертвуют безопасностью и обеспечивают почти идеальный пользовательский опыт, или жертвуют опытом пользователя для достижения практически идеальных показателей безопасности. Схемы доверия, основанное на власти, и TOFU являются наиболее удобным и хорошо адаптированы, но предлагают только основные свойства безопасности. Не удивительно, доверие на основе власти (в частности, приложение конкретных ключевых каталогов) является преобладающим среди недавно разработанных приложений в "дикой природе", а также среди приложений с крупнейшими базами данных пользователей (например, IMessage, BlackBerry Protected и Wickr).

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

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

Другой перспективной стратегией является слоистая конструкция, с базовой безопасностью, предоставленной центральным ключевым каталогом, дополнительные методы установления доверие для более опытных пользователей (например, визуального контроля по отпечаткам пальцев или QR-коды), и предупреждающих сообщений TOFU когда ключи контактов были изменены. TextSecure и Threema, среди прочего, принимают такой многоуровневый подход (в лице второго до последнего ряда в таблице I). В отличие от этого, OTR использует возможное шифрование с возможностью выполнения SMP, чтобы обеспечить доверие (в лице последней строки в таблице I).

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

Защищенность общения

Таблица 2. Компромиссы для комбинаций подходов установления доверия. Безопасные подходы часто жертвуют удобством и принятием.

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

Безопасность и свойства конфиденциальности

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

Целостность: измененное при передаче сообщение не будет принято участниками коммуникации.

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

Целостность участников: в каждый момент времени все участники беседы имеют одинаковый список участников.

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

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

Обратная защищенность: компрометация всего ключа не позволяет расшифровать последующую зашифрованную информацию. Это свойство также часто называют будущей защищенностью [43]. Термин отличается в различной литературе [44], [45], [46].

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

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

Сохранение связности: сообщения могут не отображаться, пока предыдущие не будут отображены.

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

Мы определяем следующие связанные с отказами свойства:

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

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

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

Вычислительная равенство: Все участники чата разделяют равную вычислительную нагрузку.

Равенство доверия: ни одному участнику не доверяют больше, ни один не принимает на себя больше ответственности, чем любой другой.

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

Уменьшаемое членство: после начала разговора, любой может покинуть его без перезагрузки протокола.

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

Удобство и восприятие

В классических средствах обмена сообщениями, пользователю необходимо заботиться лишь о двух простых задачах: отправка и получение сообщений. Однако, при защищенной коммуникации, могут быть добавлены вспомогательные задачи. В старых защищенных системах обмена сообщениями, часто базировавшихся на OpenPGP, пользователи могли самостоятельно решать, необходимо ли шифровать и/или подписывать сообщения. Многие исследования показали, что это вызывало проблемы с удобством использования[2][5], [15]. Однако при проведении исследования мы обнаружили, что многие из последних приложений для безопасного обмена сообщениями защищают все сообщения без вмешательства пользователя. Так как все реализации работают в безопасном режиме с момента установления доверия, мы снижаем усилия пользователя в колонках таблицы 2. Тем не менее, мы берем во внимание другие факторы удобства использования и воcприятия:

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

Устойчивость к потере сообщений: Сообщение может бы дешифровано без получения всех предыдущих сообщений. Это желательно при пользовании асинхронными и ненадежными сетевыми сервисами.

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

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

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

Two-party Chat Evaluation

Доверенные центральные сервера (основные)

Самыми базовыми функциями безопасности, которые предоставляет протокол защищенного обмена сообщениями, являются конфиденциальность и целостность. Это может быть легко реализовано без ущерба для удобства использования и свойств восприятия с помощью центрального сервера для передачи сообщений и обеспечения соединения от клиентов к центральному серверу с использованием протокола транспортного уровня, как TLS. Это также позволяет центральному серверу обеспечивать информацию о присутствии клиентов. Поскольку этот подход не влияет на удобство отрицательно, не удивительно, что эта архитектура была принята некоторыми из наиболее популярных сегодня систем обмена сообщениями (например, Skype, Facebook Chat, Google Hangouts)[47], [48], [49], [50], [51]. Мы не будем рассматривать эти протоколы в дальнейшем, так как они не удовлетворяют нашему определению конфиденциальности - сообщения не должны быть прочитаны никем, кроме конечного получателя(-ей). Мы рассматриваем этот подход в качестве основы в таблице 2 чтобы оценить влияние различных факторов.

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

Статическая асимметричная криптография. Еще один простой подход заключается в использовании статических долгосрочных асимметричных пар ключей участников для подписания и шифрования. OpenPGP и S / MIME - два хорошо известных и широко реализуемых стандарта для защиты сообщений, в основном используется для электронной почты, но также и в инструментах на основе XMPP [47], [52], [53], [54]. .

Хотя этот подход обеспечивает конфиденциальность, аутентификацию сообщений, и целостность, он приводит к потере всех форм отказа. Кроме того, необходимо позаботиться о гарантии того, что проверки назначения и участник согласованность выполнения проверок. Без проверки назначения, возможны атаки посредством пересылки.[55]. Без целостности участника, удостоверяющие личность нападения misbinding может быть возможно [44]. Оборона против атак воспроизведения также должны быть включены. Эти соображения особенно актуальны, так как OpenPGP и S / MIME стандарты не указать, как обеспечить эти функции, и, следовательно, большинство реализаций остаются уязвимыми для всех этих атак.[52], [53].

Вторая проблема с асимметричным шифрованием - отсутствие прямой или обратной секретности. Одним из способов решения этой проблемы является использование ключей с коротким жизненным циклом (например, менять ключ каждый день). Браун и др. предложили несколько расширений для OpenPGP, основанные на этом принципе.[56]. В самом пределе, разговоры начинаются с использованием долгосрочных ключей, но каждое сообщение включает в себя эфемерный открытый ключ, используемый для ответов. Этот метод обеспечивает двустороннюю секретность для всех сообщений, за исключением тех, которые используются, чтобы начать разговор. С точки зрения удобства и восприятия, статический ключ подходит для достижения тех же свойств, как базовой линии. Помимо учреждения непрозрачного доверия, iMessage является ярким примером того, как статической асимметричной криптографией можно добиться полной безопасности разговора без каких-либо изменений для удобства пользователя. Поскольку же долгосрочные ключи используются для всех сообщений, обеспечивается устойчивость порядка сообщений, надежная доставка сообщений, асинхронность и предоставляется поддержка нескольких устройств. Никаких дополнительных услуг не требуется.

FS-IBE. В традиционной криптографии PKI прямая секретность часто достигается путем обмена эфемерными сеансовыми ключами или частыми изменениями пар ключей. Использование ключевых протоколов соглашения усложняет асинхронность, в то время как частая замена пары ключей требует дорогостоящего распространения ключей. Шифрование, основанное на прямой безопасной идентификации ключей (FS-IBE), позволяет часто заменять пары ключей с низкими затратами на их распространение. В отличие от традиционных схем шифрования, основанных на идентификации, генераторы закрытых ключей (PKG) в FS-МБП управляются конечными пользователями, а не сервером. Первоначально, каждый участник генерирует PKG для криптографической системы на основе идентичности. Участники генеририруют n закрытых ключей (SKi) для каждого периода времени i, используя свои PKG, а затем немедленно уничтожают PKG. Каждый закрытый ключ SKi хранится зашифрованным предыдущим ключом SK(i-1)1 [45], [57]. Затем участники распространяют открытые ключи своих PKG. Отправляемые сообщения шифруются закрытым ключом, соответствующим данному периоду времени. Когда период времени заканчивается, следующий секретный ключ шифруется, а истекший удаляется. Таким образом, если промежуточные ключи скомпрометированы, злоумышленник может получить только соответствующие будущие закрытые ключи; обеспечивается прямая секретность, но не обратная. В отличие от генерации пары ключей для каждого периода времени, что требует распределения N ключей, публикуется только один открытый мастер-ключ; однако, генерацию еще нужно повторить, когда все периоды времени истекут. Канетти, Галеви и Кац были первыми создателями неинтерактивной схемы прямой безопасности на основе иерархической IBE с логарифмической затратой генерации и хранения [57]. К тому же, они показали как их схема может быть расширена на неограниченное число периодов (то есть закрытые ключи не нужно генерировать заранее), что устраняет необходимость в дополнительных сервисах для распространения новых ключей за счет увеличения вычислительных потребностей через некоторое время. Эта схема обеспечивает неинтерактивную асинхронную прямую секретность, не полагаясь на дополнительные сервисы. Однако, если сообщения приходят не по порядку, их соответствующие закрытые ключи уже могли быть удалены. В качестве послабления, истекшие ключи могут быть храниться некоторое время, обеспечивая частичную устойчивость к нарушению порядка сообщений.

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

Аутентификация Деффи-Хеллмана. Многие схемы защиты диалога использовать аутентификационный обмен ключами Диффи-Хеллмана (DH), чтобы начать разговор. В аутентификационном обмене ключами (AKE), таком как проверку подлинности DH, участники генерируют эфемерный сессионный ключ и проверяют подлинность обмена, используя свои долгосрочные ключи. Результирующий сессионный ключ используется для получения симметричного шифрования и MAC ключей, которые затем шифровать сообщения с использованием подхода "шифровать, затем вычислять MAC". Эта базовая конструкция обеспечивает конфиденциальность, целостность и аутентификацию. TLS с эфемерным набором шифров DH и общей аутентификацией (TLS-EDH-MA) является хорошо известным примером такого подхода. Обратите внимание, что требуется дополнительная защита во время обмена ключами от атак с подменой личности, нарушающих состав участников, что обеспечивается протоколом SIGMA [29], [44]. Использование эфемерных сессионных ключей обеспечивает прямую и обратную защищенность при общении. Обеспечивается несвязанность и отмена сообщений, так как сообщения проходят проверку подлинности с общими MAC-ключами, а не подписываются долгосрочными ключами. Как минимум, сообщения могут быть изменены участниками общения. Некоторые протоколы, такие как OTR, используют дополнительные меры, такие как публикация MAC ключей и использование прокалывающего шифрования для расширения набора возможных фальсификаторов сообщений [59]. Если участники просто подписать все параметры AKE, то этот подход не обеспечивает отказа участия. Тем не менее, если участники подписывают только свои эфемерные ключи, эти подписи могут быть использованы повторно их собеседников в поддельных стенограммах. OTR использует этот подход, чтобы получить частичное отрицание участия из-за ограниченного набора возможных фальсификаторов. После выполнения AKE, подход encrypt-then-MAC позволяет обмениваться сообщениями асинхронно с сохранением порядка и устойчивостью к потере сообщений. Однако, так как традиционно AKE требует полного “рукопожатия” серверов до начала шифрования сообщений, требуется синхронность во время инициализации разговора. Кроме того, поскольку соглашения ключей могут быть выполнены только с подключенных устройств, поддержка нескольких устройств не тривиальна.

Преобразование Ключа. Желательным свойством является прямая защищенность отдельных сообщений, а не всей переписки в целом. Это особенно полезно, когда, общение может продолжаться на протяжении всего срока службы устройства. Чтобы достичь этого, сессионный ключ начального соглашения может изменяться со временем с использованием храповика [43]. Простым подходом является использование функций преобразования ключа (KDF) для вычисления ключей будущих сообщений из предыдущих. Этот простой метод, используемый в SCIMP [60], обеспечивает прямую защищенность. Однако, он не обеспечивает обратную защищенность во время общения; если ключ был скомпрометирован, все последующие ключи могут быть вычислены с использованием KDF. Постоянство собеседников отчасти обеспечивается, так как сообщения не могут быть тайно удалены без удаления всех последующих сообщений (в противном случае собеседник не сможет расшифровать входящие сообщения). Если сообщения удаляются или приходят в неверном порядке, это будет замечено собеседником, так как они будут зашифрованы не тем ключом, который ожидался. Чтобы с этим справится, получатель должен хранить ключи с истекшим сроком действия, чтобы пришедшие позже или пересланные сообщения могли быть расшифрованы. Таким образом, устойчивость к нарушению порядка и удалению предусмотрена лишь отчасти.

Храповик Деффи-Хеллмана. Другой подход использования храповика, представленный OTR, это присоединение новых DH значений к сообщениям [59]. С каждым отправленным сообщением, отправитель выкладывает новое DH значение. Затем ключи сообщений вычисляются из последних известных значений DH. Такой подход обеспечивает обратную защищенность в коммуникациях, так как скомпрометированный ключ будет постоянно заменяться новым значением ключа. Частично достигается сохранение причинной связи, так как сообщения неявно ссылаются на своих причинно-следственных источников. Тот же уровень целостности отправителя как в KDF может быть достигнут добавлением отправителям счетчиков сообщений. Недостаток храповика DH состоит в том, что сессионные ключи не могут быть обновлены на каждом сообщении (таким образом, прямая защищенность обеспечивается лишь частично). Как в храповике на базе KDF, DF храповик не обеспечивает целостность сообщений при получении не в порядке отправки; если сообщение приходит после обновления ключа, то ключ расшифровки сообщений уже удален.

Двойной храповик (Axolotl). Для улучшения прямой защищенности храповика DH, оба подхода могут быть скомбинированы: сессионные ключи, сгенерированные с использованием храповика DH используются для создания KDF храповика. Тогда сообщения шифруются ключами, сгенерированным с помощью KDF, часто обновляемого храповиком DH при ответе на сообщение. Результирующий двойной храповик, такой как реализованный Axolotl [61],), обеспечивает прямую защищенность сообщений за счет KDF храповика, а также обратную защищенность, так как скомпрометированные ключи будут заменены новыми значениями. Для достижения устойчивости к нарушению порядка сообщений, в KDF используется вторая функция преобразования. KDF ключи проходят через вторую функцию преобразования перед тем как быть использованными для шифрования. Если сообщение приходит вне очереди, храповик KDF смещается вперед, временно сохраняя значение старого полученного ключа во временном хранилище; если этот ключ скомпрометирован, это не влияет на прямую защищенность. Несмотря на эти улучшения, двойной храповик требует синхронности при инициализации AKE.

3-DH Рукопожатие. Тройное DH (3-DH) рукопожатие является другой AKE схемой, которая обеспечивает более высокий уровень устойчивости участия. Полагая что Алиса и Боб имеют долгосрочные ключи ga и gb и эфемерные ключи gae и gbe, общий ключ s вычисляется какs = KDF(DH(gae ; gbe )||DH(ga; g be )||DH(gae ; gb)) [61].

Если используется функция преобразования секретного ключа, злоумышленник MitM должен знать либо a и ae, либо b и be. Кудла и др. показали, что 3-DH обмен ключами обеспечивает тот же уровень аутентификации что достигается аутентификацией с проверкой версий DH ключевых соглашений.[62]. 3-D достигает полного отказа участия, так как любой в состоянии подделать стенограмму между любыми двумя сторонами путем создания ае и be и выполнении ключевых DH обменов с а и б. Поскольку секретный ключ частично получен из долгосрочных открытых ключей, 3-DH также обеспечивает согласованность участников без необходимости явного обмена идентификаторами после создания безопасного канала. К сожалению, это также приводит к частичной потере сохранения анонимности, так долгосрочные открытые ключи могут быть прочитаны во время начального согласования ключа (хотя последующие обмены могут быть защищены с помощью предыдущих секретных ключей для шифрования этих идентификаторов).

Предварительный ключ(prekey). Хотя двойной храповик не обеспечивает асинхронность сам по себе, он может быть скомбинирован со схемой предварительных ключей для создания асинхронной версии протокола. Предключи это одноразовые эфемерные открытые DH ключи, которые были предварительно загружены на сервер. Это позволяет клиентам завершить DH ключ обмена получателем сообщения, запрашивая их следующий prekey с сервера. В сочетании с обменом 3-DH, этого достаточно, чтобы завершить асинхронный AKE как часть первого сообщения. TextSecure [63] является популярным Android-приложением, которое сочетает в себе Axolotl, prekeys и 3-DH, чтобы обеспечить асинхронный пользовательский доступ, используя дополнительную службу. В последнее время оно получило значительное внимание после того, как было включены в WhatsApp [64], [65]. При условии что Axolotl используется на двух устройствах, ключ может изменяться независимо для каждого устройства. Однако, если одно из этих устройств остается вне сети в течение длительного времени, использование ключей на этом устройстве является проблематичным: если устройство может использовать свои устаревшие ключи, чтобы читать сообщения, которые были отправлены, когда оно было в автономном режиме, то это снижает прямую секретность; если устройство не может читать старые сообщения, то протокол не предоставляет полную поддержку использования нескольких устройств. Решение как долго устройство не может быть отключено, прежде чем оно больше не сможет прочитать из буфера сообщений рассматривается и требует дальнейшего изучения поведения пользователей.

Оценка групповых чатов

OTR для групп. Несколько протоколов были предложены для достижения OTR-подобных свойств отказов для групповых бесед. Протокол TextSecure может быть распространен на группы, отправляя сообщения каждому получателю с помощью протокола TextSecure, состоящего из двух частей [66].. Для выполнения этого используется многоадресное шифрование: одно зашифрованное сообщение посылается на центральный сервер для ретрансляции для получателей в то время как ключ дешифровки для сообщения посылается с использованием TextSecure. Такая конструкция не гарантирует целостность участников, но наследует асинхронность протокола TextSecure. Целостность участников беседы и сохранение причинно-следственных связей достигается путем присоединения предшествующего идентификатора сообщений к последующим сообщениям. Идентификатором сообщения является хэш отправителя, список предыдущих идентификаторов и содержимое сообщений.

Групповой чат может быть организован с использованием протокола обмена отменяемым групповым ключом (DGKE), таким как в протоколе mpOTR [67], [68]. При завершении, DGKE предоставляет пользователям эфемерные ключи для подписи. Эта информация аутентифицируется долгосрочными ключами по типу используемых при проверке целостности участников - участники получают друг от друга идентификаторы, однако этот подход не может быть использован при проверке посторонних. Сообщения шифруются разделяемым групповым ключом и подписываются эфемерными ключами. Эфемерные подписи обеспечивают доказательство авторства отправителя другим участникам группы, однако, так как посторонние не могут быть уверены что эти подписи соответствуют определенным долгосрочным ключам, сохраняется отказ сообщений. Однако, так как все сообщения от одного участника подписываются одинаково, не возникает проблем со связыванием сообщений. Для обеспечения целостности участников общения, при отключении производится проверка изменены ли хэши. Если проверка неудачна, необходимо проверить расхождение ключей сообщений. В такой схеме невозможна отправка сообщений подгруппе так как для всех сообщений используется один ключ шифрования. Группа также не может быть расширена или уменьшена без создания нового ключа.

Совершенно другой подход используется в протоколе GOTR, разработанном в 2013. GOTR(2013) [69] построен с использованием протокола группового соглашения “горячего подключения”(GKA), позволяющего членам присоединяться и отсоединяться от беседы с минимальными накладными расходами. Эта система включает “циклические ключи”: множество открытых ключей, обладающее свойством, что разделяемый секретный ключ может быть вычислен любым при помощи сопоставления закрытого ключа с открытым ключом в множестве. Механизм обмена ключами в протоколе относительно сложный; из-за ограничений по объему, заинтересованные читатели могу ознакомиться с деталями в оригинальном иcточнике [[69]]. Парные каналы безопасности устанавливаются между участниками для отправки проверочных сообщений. Эти каналы обладают эффектом глобального порядка расшифровки, но необходимо чтобы все пользователи были в сети для получения сообщений. Система предусматривает особенности, схожие с mpOTR, но с гибкостью состава групп и несвязанностью сообщений.

Другие подходы

Из-за ограничений по объему, в таблице 2 приведены некоторые подходы, детали которых мы не раскрываем. Протоколы типа IMKE [70] и SIMPP [71], [72], [73] используют центральный сервер для обмена эфемерными ключами. GROK [74]и протокол, разработанные Кикучи и др.. [75] являются ранними попытками поддержки безопасных групповых чатов, и требуют лидера чата, передающего эфемерный групповой ключ остальным при помощи центрального сервера. Группа протоколов для чатов таких как OldBlue[76] и KleeQ [77] предоставляют механизмы сохранения причинно-следственных связей при отправке данных через ненадежные сети. Эти протоколы оцениваются в работе [1]. Другие конструкции включают парные OTR соединения, или доверенный сервер, подключенный для использования OTR, как в GROK(2007) [78]. Предложенный недавно (n+1)sec протокол[79] (предоставляет DGKE и проверяет целостность сообщений.

Обсуждение

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

К сожалению, даже у самых общепринятых решений имеются худшие свойства безопасности и секретности, при этом большинство приложений, не связанных с безопасностью, предоставляют только базовую асимметричную криптографию. Кажется, это не вызвано неудобствами использования протоколов безопасности: достаточно один раз настроить режим установки доверенного соединения, затем вся безопасность коммуникации будет настраиваться автоматически без дополнительных усилий пользователя. Исключением является использование асинхронной коммуникации совместно с прямой и обратной защищенностью; единственным решением этой проблемы, которое имеет применение на практике, является использование предварительных ключей, реализованных с использованием TextSecure. Это предполагает относительно сложную инфраструктуру, совмещенную с простым сервером ключей, возникают проблемы поддержки нескольких устройств и склонен к отказу в обслуживании при использовании в анонимной коммуникации. Этот подход слабо изучен в научной литературе. Схема FS-IBE, обсуждаемая в секции IV-C3, обещает решение проблем, связанных со сложностью сервера и отказом сервиса, но возникают новые задачи, такие как масштабируемость и проблемы производительности [57]. . В отличие от использования предварительных ключей (раздел IV-C9), эта схема была довольно хорошо исследована, но нет известных инструментов, реализующих ее на практике. Кроме того, основанная на временном окне схема FS-IBE предполагает хранение эфемерных ключей в течение определенного времени для обеспечения возможности дешифровки сообщений, пришедших с задержкой. Улучшение данной схемы требует дальнейших исследований.

Другим важным аспектом, который ограничивает использование защищенных протоколов, является ограниченная поддержка нескольких устройств. Несмотря на то, что многие пользователи являются владельцами нескольких устройств, только самые небезопасные протоколы поддерживают это свойство, не требуя от пользователя выполнять сопряжение устройств. Сопряжение устройств оказалось чрезвычайно трудной задачей для пользователей [80], [81] и разрешение пользователям регистрировать несколько устройств с одним кодом безопасности значительно увеличивает удобство использования.

Когда речь заходит о групповых чатах, можно выделить некоторые области для улучшения из таблицы 2. Классические протоколы часто не проверяют целостность участников или отправку в точку назначения, делая их уязвимыми для перехвата или подмены пользователя. Однако, эти свойства иногда рассматриваются в отдельных реализациях. Двойной хамовик, используемый Axolotl, улучшает прямую защищенность с низким влиянием на производительность, сложность реализации и устойчивость, но он еще не достаточно освещен в академических кругах. В добавок, схемы децентрализованных групп чатов не позволяют отправлять разные сообщения разным людям. Из-за свойств сети, разные пользователи могут наблюдать различные наборы сообщений. Несмотря на эти уязвимости, на удивление мало протоколов обеспечивают целостность собеседников и сохранение связанности сообщений.

Существующие решения достигают различных результатов в отказоустойчивости. Только OTR подобные протоколы, а именно основанные на обмене аутентификационных DH ключей и OTR-образные группы протоколов предоставляют целостность сообщений и участников совместно с аутентификацией. Имеются также различные дополнительные ограничения, возникшие в результате принятия безопасных протоколов групповых чатов. Групповые протоколы часто выбирают либо использование доверенного участника, либо дополнительного сервиса для улучшения производительности протокола, что может привести к дополнительным затратам на деплоймент. Очень небольшая группа протоколов поддерживает отправку сообщений подгруппе, и только несколько поддерживает изменение состава групп без больших затрат на продолжение работы протокола. В добавок, многие предложенные конструкции требуют синхронности для упрощения протоколов, которые на данный момент широко используются в мобильных устройствах.

Конфиденциальность передачи данных

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

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

Особенности защиты

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

Анонимность отправителя. Когда получено сообщение чата, ни одна не глобальная сущность, кроме отправителя, не должна определить какая сущность создала сообщение.

Анонимность получателя. Ни одна не глобальная сущность кроме получателя сообщения не должна знать что за сущность получила сообщение.

Анонимность участия. Ни одна не глобальная сущность кроме участников общения не может узнать какие узлы сети задействованы в обмене сообщениями.

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

Устойчивость к нарушителям. Злоумышленник не должен нарушить анонимность протокола.

Удобство использования

Доступ к контакту. Система обеспечивает механизм получения доступа к контактной информации.

Отсутствие задержек сообщений. Не допускается длительная задержка доставки сообщения

Отсутствие потерь сообщений. Потерянные сообщения пересылаются.

Простая инициализация. Пользователю не нужно производить сложные операции прежде чем он начнет общение.

Отсутствие выплат. Схема не требует использования денежных взносов.

Свойства восприятия

Независимость топологии. Топология сети не накладывается на безопасность обмена сообщениями и схемы установки доверенного соединения.

Отсутствие дополнительных сервисов. Архитектура не зависит от какой-либо архитектуры за пределами чата.

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

Низкое потребление памяти. Система не должна требовать большого количества места для любых данных.

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

Малое количество вычислений. Система не должна нуждаться в большом количестве работы процессора для каких-либо операций.

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

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

Оценка

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

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

Однако нарушители с глобальным доступом к сети все равно могут взломать свойства анонимности пользуясь средствами статического анализа, например, размера содержимого, направления передачи, количества, времени, и др. данных. Успешность подобных методов может быть ограничена путем отдельного устранения этих данных. Защита может быть усилена путем добавления случайных значений задержек. Чем выше время задержек, тем меньше мощностей для сбора статистики доступно злоумышленнику. Конечно, это может привести к длительной доставке сообщений и требованиям дополнительного объема хранимых данных, делая протокол непригодным для мгновенного обмена сообщениями. Mixminion является реализацией протокола, основывающегося на такой технологии [84].

К сожалению, случайные задержки не полностью защищают от взломщиков. Единственный способ добиться этого - сделать передачу недоступной извне (например, путем насыщения пропускной способности всех соединений). Однако, на практике это неосуществимо. Использование луковой маршрутизации ограничивается использованием большого количества узлов для обеспечения высокого уровня анонимности и покрытия трафика. Для обеспечения поддержки асинхронной коммуникации, можно объединить сервера, работающие по принципу хранения и отправки в луковую сеть. Каждый пользователь сопоставляется со скрытым сервисом Tor, который остается в сети. Для отправки сообщений, отправитель создает цепь принимающих серверов и высылает сообщение. Пользователи периодически пингуют свои сервера для проверки наличия входящих сообщений. Примером такого подхода является Ricochet. Pond использует такую структуру для архитектуры передачи [85], но добавляет случайные задержки между соединениями, каждое из которых передает одно и то же количество данных для усложнения статистического анализа взломщиков. Эта структура требует хранения данных на серверах и обеспечивает высокий уровень латентности. Без дополнительной защиты эта схема также очень уязвима для DoS атак из-за задержек и фиксированного размера передаваемых данных происходит искусственное ограничение пропускной способности до очень низкого уровня. Pond избегает этого требуя пользователей поддерживать списки групп защищенными схемами ZKGP. Таким образом, получатели могут загружать списки контактов, не раскрывая своих контактов. Одновременно, отправители могут аутентифицироваться предоставляя ZKP, подтверждающий из наличие в этом списке. Pond в настоящее время для достижения этого пользуется схемой подписи BBS [86] .

DC-сети.

DC-сети являются анонимными системами которые часто сравнивают со схемами луковой маршрутизации. DC-сети являются группами протоколов, срабатывающих на каждом раунде. В начале каждого раунда, каждый участник либо отправляет тайное сообщение, либо нет. В конце раунда, все участники отправляют результат операции xor всех отправленных секретных сообщений, не зная какое сообщение было отправлено каждым из участников. Таким образом, DC-сети обеспечивают анонимность отправителя, в то же время достигая защиты от злоумышленников - статистический анализ не может определить отправителя. Анонимность получателя может быть достигнута путем использования протокола публикации открытых эфемерных ключей. Сообщения, зашифрованные этими ключами, отправляются и, так как владелец подходящего закрытого ключа неизвестен, получатель не может быть дешифрован. Так как сообщения отправляются в раундах, DC-сети добавляют сообщениям уровень латенстности и не поддерживают асинхронную коммуникацию; потерянные сообщения не позволяют развивать протокол. Сообщения являются легко связываемыми при помощи наблюдения, какие узлы сети были задействованы в раунде. Кроме того, DC-сети имеют ограничения в использовании парной коммуникации.

Базовая конструкция DC-сети имеет проблемы с коллизиями: если два участника отправляют сообщение в одном раунде, результат будет неверным. Злоумышленник может использовать это для реализации DoS атаки, отправляя искаженные сообщения в каждом раунде. Хуже того, хакер может выполнить DoS атаку, искажая передаваемые биты. Есть несколько способов для решения этой проблемы. Anonycaster [87] добавляет псевдослучайно сгенерированные “тихие раунды” в которых все члены знают, что сообщение не должно быть отправлено. Получение сообщение в тихом раунде говорит о том, что проводится DoS атака активным злоумышленником. Однако, злоумышленники все еще могут выполнять атаку во время не тихих раундов. Dissent [88], [89], [90] и Verdict [91] применяют другой подход, конструируя DC-сеть путем проверяемой подмены протоколов передачи. DC-сети, основанные на перетасовке, позволяют точно определить сущность, начавшую раунд. Dissent использует одного участника как лидера для управления временем раундов, протоколом отказа и исключением или разъединением участников от раундов, тем самым восстанавливая поддержку асинхронности. Verdict использует альтернативный подход, в котором протокол DC-сети исполняется множеством центральных серверов, к которым подключены клиенты, в том числе и сервера безопасности.

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

Системы вещания

Существует простой подход для обеспечения анонимности получателей от любых злоумышленников, включая глобальных хакеров: рассылка сообщений всем. Этот подход обеспечивает анонимность получателя и несвязываемость. Это также является естественным путем обнаружения контактов так как запросы контактных данных могут быть отправлены конкретной сущности без информации о ее адресной информации. Однако, имеются некоторые серьезные недостатки: вещание требует высокой пропускной способности, невозможно организовать асинхронный обмен сообщениями, имеются огромные проблемы с масштабируемостью. Кроме того, злоумышленнику просто провести атаку доступности сети используя флуд. Bitmessage [92], основанный на вещании протокол транспортной системы, требует подтверждения работы, либо оплаты для отправки сообщений в нужном порядке для защиты от спама, также требователен к вычислительной мощности и возникают задержки сообщений. как показано в таблице 3. Решение проблемы с масштабируемостью возможно путем разделения пользователей на меньшие группы вешания, взамен уменьшая степень анонимности множества пропорционально его размеру.

PIR. Протоколы частного получения информации позволяют пользователю отправлять запросы к базе данных сервера без возможности сервера определить, какая информация была запрошена. такие системы, например Pynchon Gate [93], могут быть использованы для хранения входящих сообщений и контактной информации в базах данных. Анонимность получателя обеспечивается тем, что хотя сервер знает о узел сети, который подключен, он не может сопоставить входящие подключения с сообщениями протокола, которые они отсылают. По этой же причине, протокол предоставляет анонимность участников и несвязываемость. По умолчанию, механизм, обеспечивающий анонимность отправителя, отсутствует. Такие системы являются асинхронными, но их уровень латентности очень высок, так как входящие сообщения постоянно пингуются. Серверы также обходятся дорого из-за высокой стоимости хранения и подверженности атакам флудом. Реализации PIR могут быть разделены на вычислительные схемы, которые зависят от вычислительных мощностей сервера, информационно-теоретические схемы, требующие отсутствия коллизий на сервере, гибридные схемы, которые сочетают свойства обеих. реализации PIR различаются своей пропускной способностью, стоимостью вычислений и инициализации, а также масштабируемостью. PIR не является широко используемой практикой из-за того что какая-либо из стоимостей обычно очень высока.

Обсуждение

Если сообщения полностью защищены, с сохранением только идентификаторы анонимных почтовых ящиков, тогда метаданные легко защитить от операторов услуг. Учитывая, что каждое сообщение отправляется по новым каналам, нарушитель не может связать отдельные сообщения к коммуникациям. Однако, такие схемы имеют трудности с принятием и удобством использования; они подвержены спаму, флуду, DoS атакам, или требуют дорогих операций, таких как использование zero-knowledge аутентификации, создающих проблем для принятия. Что еще хуже, скрытие метаданных от хакеров в таких схемах приводит к серьезным проблемам с удобством использования, таким как долгие задержки. Напротив, в децентрализованных схемах либо возникают проблемы с синхронностью, либо с масштабируемостью. Большинству децентрализованных проектов, особенно базирующиеся на подходах BitTorrent, не хватает детальной документации, необходимой для полной оценки. Некоторые инструменты, претендующие на защиту метаданных, являются такими только из-за отсутствия взломщиков, которые могут появиться.

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

Заключительные замечания

Подавляющее большинство электронных средств коммуникации во всем мире работают на таких протоколах как SMS/GSM и на централизованной отправке сообщений, ни один из которых не обеспечивает полную безопасность передачи сообщений. Мы призываем научное сообщество рассмотреть яркие разоблачения NSA в США как замечательную возможность содействовать принятию у себя систем безопасности. Как гласит старая пословица: “никогда не позволяйте кризису пройти зря”. К сожалению, хотя за последние 2 года произошел значительный прогресс в практических инструментах обеспечения безопасности, мало свидетельств того, что количество академических исследований в этой области сильно увеличилось. Это печально по двум причинам:

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

Заметим также, что, к сожалению, большая часть существующего прогресса сейчас совершается протоколами, которые являются либо фирменными (например, Apple iMessage), либо проектами с открытым кодом, но им не хватает строго указанных протоколов для обеспечения совместимости реализаций (например, TextSecure). Открытый стандарт для безопасного обмена сообщениями, сочетающий наиболее перспективные возможности, выявленные в нашем опросе, будет иметь огромное значение. Неизбежно, придется идти на компромиссы. Мы пришли к выводу, что безопасные подходы в создании доверительной связи являются неудобными для использования и принятия, а более пригодным подходам не хватает гарантий безопасности. Мы рассматриваем наиболее перспективный подход учреждения доверительного соединения, чтобы сочетать центральные ключевые словари, журналы передач данных для обеспечения глобальной согласованности основных записей каталогов, а также различные варианты для пользователей, заботящихся о безопасности, чтобы проверять вне групповые ключи, а также чтобы сохранять актуальность ключа.

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

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

От авторов

Авторы хотели бы поблагодарить анонимных рецензентов за их полезные замечания, Тревора Перрен и Генри Корриган-Гиббса за обсуждения и отличную обратную связь. Джозеф Бонно поддерживается стипендией Secure Usability Фонда Open Technology and Simply Secure. Мы с благодарностью отмечаем поддержку NSERC и научно-исследовательского фонда Онтарио.

Примечания

  1. 1,0 1,1 N. Unger, S. Dechand, J. Bonneau, S. Fahl, H. Perl, I. Goldberg, and M. Smith, “SoK: Secure Messaging,” CACR, Tech. Rep. 2015-02, 2015.
  2. 2,0 2,1 A. Whitten and J. D. Tygar, “Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0,” in Security Symposium. USENIX, 1999.
  3. 3,0 3,1 S. L. Garfinkel and R. C. Miller, “Johnny 2: A User Test of Key Continuity Management with S/MIME and Outlook Express,” in Symposium on Usable Privacy and Security. ACM, 2005, pp. 13–24.
  4. 4,0 4,1 S. L. Garfinkel, D. Margrave, J. I. Schiller, E. Nordlander, and R. C. Miller, “How to Make Secure Email Easier To Use,” in SIGCHI Conference on Human Factors in Computing Systems. ACM, 2005, pp. 701–710.
  5. 5,0 5,1 K. Renaud, M. Volkamer, and A. Renkema-Padmos, “Why Doesn’t Jane Protect Her Privacy?” in Privacy Enhancing Technologies. Springer, 2014, pp. 244–262.
  6. M. Madden. (2014, Nov) Public Perceptions of Privacy and Security in the Post-Snowden Era. [Online]. Available: http://www.pewinternet.org/2014/11/12/public-privacy-perceptions/
  7. GoldBug Project. GoldBug - Secure Instant Messenger. [Online]. Available: http://goldbug.sourceforge.net/
  8. Telegram. Telegram Messenger. [Online]. Available: https://telegram.org/
  9. Wickr. Wickr – Top Secret Messenger. [Online]. Available: https://wickr.com/
  10. Confide. Confide - Your Off-the-Record Messenger. [Online]. Available: https://getconfide.com/
  11. Electronic Frontier Foundation. Secure Messaging Scorecard. [Online]. Available: https://www.eff.org/secure-messaging-scorecard
  12. S. E. Schechter, R. Dhamija, A. Ozment, and I. Fischer, “The Emperor’s New Security Indicators: An evaluation of website authentication and the effect of role playing on usability studies,” in Symposium on Security and Privacy. IEEE, 2007, pp. 51–65.
  13. R. Stedman, K. Yoshida, and I. Goldberg, “A User Study of Off-the-Record Messaging,” in Symposium on Usable Privacy and Security. ACM, 2008, pp. 95–104.
  14. S. Clark, T. Goodspeed, P. Metzger, Z. Wasserman, K. Xu, and M. Blaze, “Why (Special Agent) Johnny (Still) Can’t Encrypt: A Security Analysis of the APCO Project 25 Two-way Radio System,” in Security Symposium. USENIX, 2011.
  15. 15,0 15,1 S. Fahl, M. Harbach, T. Muders, M. Smith, and U. Sander, “Helping Johnny 2.0 to Encrypt His Facebook Conversations,” Usable Privacy and Security. ACM, 2012.
  16. S. Ruoti, N. Kim, B. Burgon, T. van der Horst, and K. Seamons, “Confused Johnny: When Automatic Encryption Leads to Confusion and Mistakes,” in Symposium on Usable Privacy and Security. ACM, 2013.
  17. J. Nielsen, “Finding Usability Problems Through Heuristic Evaluation,” in SIGCHI Conference on Human Factors in Computing Systems. ACM, 1992, pp. 373–380.
  18. “Usability inspection methods,” in Conference Companion on Human Factors in Computing Systems. ACM, 1994, pp. 413–414.
  19. B. E. John and M. M. Mashyna, “Evaluating a Multimedia Authoring Tool with Cognitive Walkthrough and Think-Aloud User Studies,” DTIC, Tech. Rep., 1995.
  20. J. Bonneau, C. Herley, P. C. van Oorschot, and F. Stajano, “The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes,” in Symposium on Security and Privacy. IEEE, 2012. [Online]. Available: http://www.jbonneau.com/doc/BHOS12-IEEESP-quest to replace passwords.pdf
  21. 21,0 21,1 J. Clark and P. C. van Oorschot, “SoK: SSL and HTTPS: Revisiting past challenges and evaluating certificate trust model enhancements,” in Symposium on Security and Privacy. IEEE, 2013, pp. 511–525.
  22. D. Wendlandt, D. G. Andersen, and A. Perrig, “Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing,” in Annual Technical Conference. USENIX, 2008, pp. 321–334.
  23. P. Zimmermann, A. Johnston, and J. Callas, “ZRTP: Media Path Key Agreement for Unicast Secure RTP,” RFC 6189 (Informational), Internet Engineering Task Force, 2011. [Online]. Available: http: //www.ietf.org/rfc/rfc6189.txt
  24. E. A. Blossom, “The VP1 Protocol for Voice Privacy Devices Version 1.2,” Communication Security Corporation, 1999
  25. P. Gupta and V. Shmatikov, “Security Analysis of Voice-over-IP Pro-tocols,” in Computer Security Foundations Symposium. IEEE, 2007, pp. 49–63.
  26. M. Petraschek, T. Hoeher, O. Jung, H. Hlavacs, and W. N. Gansterer, “Security and Usability Aspects of Man-in-the-Middle Attacks on ZRTP,” Journal of Universal Computer Science, vol. 14, no. 5, pp. 673–692, 2008.
  27. M. Shirvanian and N. Saxena, “Wiretapping via Mimicry: Short Voice Imitation Man-in-the-Middle Attacks on Crypto Phones,” in Conference on Computer and Communications Security. ACM, 2014, pp. 868– 879.
  28. M. Jakobsson and M. Yung, “Proving Without Knowing: On Oblivi-ous, Agnostic and Blindfolded Provers,” in Advances in Cryptology– CRYPTO. Springer, 1996, pp. 186–200
  29. 29,0 29,1 29,2 C. Alexander and I. Goldberg, “Improved User Authentication in Off-The-Record Messaging,” in Workshop on Privacy in the Electronic Society. ACM, 2007, pp. 41–47.
  30. F. Boudot, B. Schoenmakers, and J. Traore,´ “A fair and efficient solution to the socialist millionaires’ problem,” Discrete Applied Math-ematics, vol. 111, no. 1, pp. 23–36, 2001
  31. M. Farb, Y.-H. Lin, T. H.-J. Kim, J. McCune, and A. Perrig, “SafeSlinger: Easy-to-Use and Secure Public-Key Exchange,” in International Conference on Mobile Computing & Networking. ACM, 2013, pp. 417–428.
  32. M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V. Shmatikov, “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software,” in Conference on Computer and Communications Security. ACM, 2012, pp. 38–49.
  33. M. Marlinspike, “More tricks for defeating SSL in practice,” in Black Hat USA, 2009.
  34. VASCO. (2011, Sep) DigiNotar reports security incident. [Online]. Available: https://www.vasco.com/company/about vasco/press room/ news archive/2011/news diginotar reports security incident.aspx
  35. A. Langley. (2013) Enhancing digital certificate security. [Online]. Available: http://googleonlinesecurity.blogspot.de/2013/01/ enhancing-digital-certificate-security.html
  36. 36,0 36,1 B. Laurie, A. Langley, and E. Kasper, “Certificate Transparency,” RFC 6962 (Experimental), Internet Engineering Task Force, 2013. [Online]. Available: http://tools.ietf.org/rfc/rfc6962.txt
  37. Google. End-To-End. [Online]. Available: https://github.com/google/ end-to-end
  38. J. Sunshine, S. Egelman, H. Almuhimedi, N. Atri, and L. F. Cranor, “Crying Wolf: An Empirical Study of SSL Warning Effectiveness,” in Security Symposium. USENIX, 2009, pp. 399–416.
  39. M. D. Ryan, “Enhanced Certificate Transparency and End-to-end En-crypted Mail,” in Network and Distributed System Security Symposium. Internet Society, 2014.
  40. M. S. Melara, A. Blankstein, J. Bonneau, M. J. Freedman, and E. W. Felten, “CONIKS: A Privacy-Preserving Consistent Key Service for Secure End-to-End Communication,” Cryptology ePrint Archive Report 2014/1004, 2014. [Online]. Available: https://eprint.iacr.org/2014/1004
  41. S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008, self-published.
  42. N. Project. Namecoin. [Online]. Available: https://namecoin.info/
  43. 43,0 43,1 O. W. Systems. Advanced cryptographic ratcheting. [Online]. Available: https://whispersystems.org/blog/advanced-ratcheting/
  44. 44,0 44,1 44,2 W. Diffie, P. C. van Oorschot, and M. J. Wiener, “Authentication and Authenticated Key Exchanges,” Designs, Codes and Cryptography, vol. 2, no. 2, pp. 107–125, 1992
  45. 45,0 45,1 R. Anderson, “Two Remarks on Public Key Cryptology,” 1997, avail-able from https://www.cl.cam.ac.uk/users/rja14.
  46. R. Shirey, “Internet Security Glossary,” RFC 2828 (Informational), Internet Engineering Task Force, 2000, obsoleted by RFC 4949. [Online]. Available: http://tools.ietf.org/rfc/rfc2828.txt
  47. 47,0 47,1 P. Saint-Andre, “Extensible Messaging and Presence Protocol (XMPP): Core,” RFC 6120 (Proposed Standard), Internet Engineering Task Force, 2011. [Online]. Available: http://tools.ietf.org/rfc/rfc6120.txt
  48. S. Schrittwieser, P. Fruhwirt,¨ P. Kieseberg, M. Leithner, M. Mulazzani, M. Huber, and E. R. Weippl, “Guess Who’s Texting You? Evaluating the Security of Smartphone Messaging Applications,” in Network and Distributed System Security Symposium. Internet Society, 2012
  49. Microsoft. (2014) Does Skype use encryption? [Online]. Available: https://support.skype.com/en/faq/FA31/does-skype-use-encryption
  50. Google. (2014) Google Hangouts - Video Conferencing & Meeting for Business. [Online]. Available: https://www.google.com/work/apps/ business/products/hangouts/
  51. Facebook. (2014) Facebook Help Center. [Online]. Available: https://www.facebook.com/help/
  52. 52,0 52,1 J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer, “OpenPGP Message Format,” RFC 4880 (Proposed Standard), Internet Engineering Task Force, 1999, updated by RFC 5581. [Online]. Available: http://tools.ietf.org/rfc/rfc4880.txt
  53. 53,0 53,1 B. Ramsdell and S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification,” RFC 5751 (Proposed Standard), Internet Engineering Task Force, 2010. [Online]. Available: http://tools.ietf.org/rfc/rfc5751.txt
  54. D. Fomin and Y. Leboulanger. Gajim, a Jabber/XMPP client. [Online]. Available: https://gajim.org/
  55. D. Davis, “Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML,” in Annual Technical Conference, General Track. USENIX, 2001, pp. 65–78.
  56. I. Brown, A. Back, and B. Laurie, “Forward Secrecy Extensions for OpenPGP,” Draft, Internet Engineering Task Force, 2002. [Online]. Available: https://tools.ietf.org/id/draft-brown-pgp-pfs-03.txt
  57. 57,0 57,1 57,2 R. Canetti, S. Halevi, and J. Katz, “A Forward-Secure Public-Key Encryption Scheme,” in Advances in Cryptology–EUROCRYPT. Springer, 2003, pp. 255–271.
  58. M. Green and I. Miers, “Forward Secure Asynchronous Messaging from Puncturable Encryption,” in Symposium on Security and Privacy. IEEE, 2015.
  59. 59,0 59,1 N. Borisov, I. Goldberg, and E. Brewer, “Off-the-Record Communi-cation, or, Why Not To Use PGP,” in Workshop on Privacy in the Electronic Society. ACM, 2004, pp.77–84.
  60. V. Moscaritolo, G. Belvin, and P. Zimmermann, Silent Circle Instant Messaging Protocol Protocol Specification, 2012.
  61. 61,0 61,1 T. Perrin. (2013) Axolotl Ratchet. [Online]. Available: https: //github.com/trevp/axolotl/wiki
  62. C. Kudla and K. G. Paterson, “Modular Security Proofs for Key Agree-ment Protocols,” in Advances in Cryptology–ASIACRYPT. Springer, 2005, pp. 549–565.
  63. O. W. Systems. Open WhisperSystems. [Online]. Available: https: //whispersystems.org/
  64. T. Frosch, C. Mainka, C. Bader, F. Bergsma, J. Schwenk, and T. Holz, “How Secure is TextSecure?” Cryptology ePrint Archive Report 2014/904, 2014. [Online]. Available: https://eprint.iacr.org/2014/904
  65. O. W. Systems. Open Whisper Systems partners with WhatsApp to provide end-to-end encryption. [Online]. Available: https:// whispersystems.org/blog/whatsapp/
  66. Private Group Messaging. [Online]. Available: https: //whispersystems.org/blog/private-groups/
  67. I. Goldberg, B. Ustaoglu,˘ M. D. Van Gundy, and H. Chen, “Multi-party Off-the-Record Messaging,” in Conference on Computer and Communications Security. ACM, 2009, pp. 358–368.
  68. M. Van Gundy, “Improved Deniable Signature Key Exchange for mpOTR,” 2013, available from http://matt.singlethink.net/projects/ mpotr/improved-dske.pdf
  69. 69,0 69,1 H. Liu, E. Y. Vasserman, and N. Hopper, “Improved Group Off-the-Record Messaging,” in Workshop on Privacy in the Electronic Society. ACM, 2013, pp. 249–254.
  70. M. Mannan and P. C. van Oorschot, “A Protocol for Secure Public Instant Messaging,” in Financial Cryptography and Data Security. Springer, 2006, pp. 20–35
  71. C.-H. Yang and T.-Y. Kuo, “The Design and Implementation of a Secure Instant Messaging Key Exchange Protocol,” 2007, available from http://crypto.nknu.edu.tw/psnl/publications/2007Technology SIMPP.pdf.
  72. C.-H. Yang, T.-Y. Kuo, T. Ahn, and C.-P. Lee, “Design and Implementation of a Secure Instant Messaging Service based on Elliptic-Curve Cryptography,” Journal of Computers, vol. 18, no. 4, pp. 31–38, 2008.
  73. C.-P. Lee and C.-H. Yang, “Design and Implement of a Secure Instant Messaging Service with IC Card,” 2009, available from http://crypto. nknu.edu.tw/psnl/publications/2009CPU SIMICCard.pdf.
  74. J. A. Cooley, R. I. Khazan, B. W. Fuller, and G. E. Pickard, “GROK: A Practical System for Securing Group Communications,” in Interna-tional Symposium on Network Computing and Applications. IEEE, 2010, pp. 100–107
  75. H. Kikuchi, M. Tada, and S. Nakanishi, “Secure Instant Messaging Protocol Preserving Confidentiality against Administrator,” in Interna-tional Conference on Advanced Information Networking and Applica-tions. IEEE, 2004, pp. 27–30
  76. M. D. Van Gundy and H. Chen, “OldBlue: Causal Broadcast In A Mutually Suspicious Environment (Working Draft),” 2012, available from http://matt.singlethink.net/projects/mpotr/oldblue-draft.pdf
  77. J. Reardon, A. Kligman, B. Agala, and I. Goldberg, “KleeQ: Asyn-chronous Key Management for Dynamic Ad-Hoc Networks,” Univer-sity of Waterloo, Tech. Rep., 2007.
  78. J. Bian, R. Seker, and U. Topaloglu, “Off-the-Record Instant Messaging for Group Conversation,” in International Conference on Information Reuse and Integration. IEEE, 2007, pp. 79–84
  79. (2015) (n+1)sec. [Online]. Available: learn.equalit.ie/wiki/Np1sec
  80. R. Kainda, I. Flechais, and A. W. Roscoe, “Usability and Security of Out-Of-Band Channels in Secure Device Pairing Protocols,” in Symposium on Usable Privacy and Security. ACM, 2009.
  81. B. Warner. (2014) Pairing Problems. [Online]. Available: https: //blog.mozilla.org/warner/2014/04/02/pairing-problems/
  82. M. G. Reed, P. F. Syverson, and D. M. Goldschlag, “Anonymous Connections and Onion Routing,” Selected Areas in Communications, vol. 16, no. 4, pp. 482–494, 1998.
  83. R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The Second-Generation Onion Router,” DTIC, Tech. Rep., 2004.
  84. G. Danezis, R. Dingledine, and N. Mathewson, “Mixminion: Design of a Type III Anonymous Remailer Protocol,” in Symposium on Security and Privacy. IEEE, 2003, pp. 2–15.
  85. A. Langley. Pond. [Online]. Available: https://pond.imperialviolet.org/
  86. D. Boneh, X. Boyen, and H. Shacham, “Short Group Signatures,” in Advances in Cryptology–CRYPTO. Springer, 2004, pp. 41–55.
  87. C. C. Head, “Anonycaster: Simple, Efficient Anonymous Group Communication,” 2012, available from https://blogs.ubc.ca/ computersecurity/files/2012/04/anonycaster.pdf.
  88. H. Corrigan-Gibbs and B. Ford, “Dissent: Accountable Anonymous Group Messaging,” in Conference on Computer and Communications Security. ACM, 2010, pp. 340–350
  89. D. I. Wolinsky, H. Corrigan-Gibbs, B. Ford, and A. Johnson, “Dissent in Numbers: Making Strong Anonymity Scale,” in Conference on Operating Systems Design and Implementation. USENIX, 2012, pp. 179–182.
  90. E. Syta, H. Corrigan-Gibbs, S.-C. Weng, D. Wolinsky, B. Ford, and A. Johnson, “Security Analysis of Accountable Anonymity in Dissent,” Transactions on Information and System Security, vol. 17, no. 1, p. 4, 2014
  91. H. Corrigan-Gibbs, D. I. Wolinsky, and B. Ford, “Proactively Account-able Anonymous Messaging in Verdict,” arXiv e-prints, Tech. Rep. arXiv:1209.4819, 2012.
  92. B. Project. Bitmessage. [Online]. Available: https://bitmessage.org/
  93. L. Sassaman, B. Cohen, and N. Mathewson, “The Pynchon Gate: A Secure Method of Pseudonymous Mail Retrieval,” in Workshop on Privacy in the Electronic Society. ACM, 2005, pp. 1–9