Часто задаваемые вопросы о реализациях ZRTP, SRTP и GNU ZRTP

Нуждаться

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

• Безопасный транспортный протокол реального времени (SRTP)Повышает безопасность RTP и обеспечивает целостность и конфиденциальность мультимедийных подключений RTP. Однако для эффективного использования SRTP приложения VoIP должны иметь возможность автоматически согласовывать ключи и другие параметры.
• ZRTP — это протокол, который согласовывает ключи и другую информацию, необходимую для установления голосового и видеосеанса SRTP.

Хотя необходимо учитывать технологии, протоколы и т. д., необходимо также учитывать влияние на реализацию, развертывание и удобство использования конкретной технологии. Доступность жизненно важна для одноранговых приложений VoIP, которые в основном используются сторонами, не связанными с ИТ. Следовательно, процесс должен быть простым, легким в использовании и не требовать специальной инфраструктуры или регистрации.

ЗРТП - что тут такого?

Фил Циммерманн, изобретатель ZRTP, является известным человеком в области компьютерной безопасности. Он наиболее известен своей знаменитой программой Pretty Good Privacy (PGP), которая обеспечивает надежное шифрование, безопасность данных и конфиденциальность для широких масс. Новейшая разработка Фила, ZRTP, повышает безопасность и конфиденциальность, когда мы используем Интернет для общения друг с другом с помощью аудио или видео, широко известного как передача голоса по IP (VoIP). С точки зрения пользователя, ZRTP очень прост в использовании и не требует какой-либо специальной инфраструктуры после реализации в программах VoIP.ЗРТПСпецификацию можно найти на странице Фила в Zfone.

Возможности и недостатки ZRTP

ZRTP и реализация GNU ZRTP предоставляют функции коммуникационным программам.

• Установление безопасных аудио- и видеосессий без дополнительной инфраструктуры, серверных программ, записи и подобных процессов,
• Информирование пользователя о том, безопасен сеанс или нет, предоставление информации о проблемах и их серьезности,
• Он предоставляет простой в использовании метод определения того, вмешались ли хакеры в сеанс.

Чего ZRTP не обеспечивает:

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

ЗРТП и коммуникационные программы

ZRTP не может работать независимо и не может обеспечить безопасную связь. Вместо этого коммуникационные программы используют реализацию ZRTP со стеками RTP; Программы предоставляют пользовательский интерфейс и другие функции, необходимые для настройки аудио/видеовызовов и обеспечения совместимости с ZRTP.

Как это работает?

В принципе, ZRTP использует три этапа для согласования и установки главных ключей SRTP и переключения в режим SRTP:

1. этап обнаружения – определение того, поддерживают ли одноранговые узлы ZRTP;
2. Ключевой этап сделки – обмен ключевыми материалами;
3. безопасная фаза – подтвердите криптографические данные и переключитесь в режим SRTP.

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

На следующем этапе пиры генерируют свои собственные значения Диффи-Хеллмана и обмениваются публичной частью пары ключей Диффи-Хеллмана. ZRTP требует создания новых пар ключей Диффи-Хеллмана для каждого сеанса. ZRTP не использует долгоживущие ключи. Дополнительную информацию по этим темам см. в ответах на основные вопросы непрерывности и восстановления.

Пиры могут обмениваться этими значениями вместе с другими секретами, такими как Retained Secrets (RS) или секретом, например, другим паролем (в зависимости от реализации программы связи). ZRTP использует все доступные секреты и разумно комбинирует их для создания и получения главных ключей SRTP. Сочетание нескольких важных данных сильно затрудняет угадывание значений злоумышленником.

После того как ZRTP вычислит данные ключа SRTP, ZRTP изменяет некоторые данные подтверждения, чтобы проверить, успешно ли согласовано ключ. На последнем этапе ZRTP устанавливает контекст шифрования SRTP и переключается со стандартного режима RTP на режим SRTP.

Отношения RTP, SRTP и ZRTP

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

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

SRTPСтрого говоря, это не протокол сам по себе, а скорее спецификация того, как защитить и зашифровать пакет RTP. SRTP (RFC 3711) определяет

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

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

ZRTP — это отдельный протокол, который использует сеансы RTP для обмена данными. Единственная цель ZRTP — согласовать ключи и криптографические алгоритмы между узлами и сгенерировать данные с использованием этих ключей и алгоритмов для установления криптографического контекста SRTP. ТакZRTP не является заменой SRTP, но позволяет легко использовать SRTP.

SRTPПосле установки контекста шифрования ZRTP исключается и не требует использования полосы пропускания или циклов ЦП.

Что произойдет, если программа другой стороны не поддерживает ZRTP?

ZRTP обнаружит это на этапе обнаружения и сможет проинформировать об этом пользователя. В этом случае ZRTP не сможет установить безопасный сеанс RTP.

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

Поддерживает ли ZRTP сохранение ключей?

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

Такое поведение может произойти, если пользователь удаляет файл кэша ZRTP или повреждает устройство. Таким образом, это не настоящая проблема безопасности, а просто незначительное неудобство.

Могу ли я или кто-либо еще восстановить ключ?

На этот вопрос есть простой ответ: нет, если оба пользователя гарантируют, что атака «Человек посередине» (MitM) не произойдет на этапе согласования ZRTP. Это простая процедура: сравните короткую строку аутентификации – см. SAS.

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

Требуются ли для этого ZRTP, SIP, XMPP или другие протоколы сигнализации?

Нет. ZRTP использует сеанс RTP для обмена данными. Для установления связи сеанса RTP программы могут использовать любой механизм, включая SIP или XMPP, чтобы стороны обменивались адресами сеанса RTP и другой необходимой информацией.

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

Хранит ли ZRTP данные обо мне? Например, сохраняются ли использованные ключи?

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

ZRTP хранит информацию о состоянии, состоящую из идентификатора ZRTP, состояния аутентификации SAS, сохраненного общего секрета (RS) и других.

Расположение этого файла зависит от реализации коммуникационной программы.

Что такое идентификатор ZRTP?

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

Что такое общий секрет (RS)?

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

ZRTP рассчитывает и обновляет RS после каждого согласования ключей, чтобы обеспечить непрерывность ключей и восстановление после потенциальных ошибок во время согласования ключей.

Может ли ZRTP обнаруживать и сообщать об атаках «Человек посередине»?

При первом сеансе устройства/коммуникационной программы данные о состоянии недоступны (см. также здесь), и ZRTP не может обнаружить атаку «Человек посередине» (MitM). Поэтому пользователям следует всегда проверять SAS и проверять правильность соглашения о ключах. Программа связи отображает предупреждающее сообщение, подобное этому: Общие секреты не сохранены — необходимо проверить SAS.

По окончании первоначального соглашения о ключах ZRTP GNU ZRTP вычисляет и сохраняет сохраненные общие секреты (RS), которые позволяют ему обнаруживать и предупреждать о возможной атаке MitM в последующих сеансах к тому же устройству/программе связи. Если ZRTP обнаруживает возможный MitM, он сообщает об этом. Кроме того, коммуникационная программа часто выдает предупреждающее сообщение, подобное этому: Общие секреты, признанные действительными, существуют, но совпадений не найдено — необходимо проверить SAS.

справочная информация
ZRTP использует соглашение о ключах Диффи-Хеллмана для обмена ключевыми данными между двумя коммуникационными программами. К сожалению, протокол соглашения о ключах Диффи-Хеллмана уязвим для так называемой атаки «Человек посередине» (MitM), когда плохой парень сидит среди хороших парней и контролирует пути связи.

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

• Короткая строка аутентификации (SAS) и
• Общие секреты (RS) сохранены.

Что такое SAS и как его использовать?

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

Приложения ZRTP рассчитывают SAS, а коммуникационные программы должны представить его пользователю в виде короткой текстовой информации (ZRTP определяет длину обязательного SAS как 4 символа).

Теперь оба пользователя могут читать данные SAS и сравнивать их по голосовому соединению.

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

После проверки данных SAS, если оба пользователя установили SAS для аутентификации, оба пользователя могут установить статус SAS для аутентификации, приложения ZRTP сохранят эту информацию и будут использовать ее в последующих сеансах ZRTP.

Файл кэша ZRTP удален или поврежден?

Это незначительная проблема. GNU ZRTP создает новый пустой файл кэша и новый идентификатор ZRTP (ZID) для этой комбинации устройства и средства связи. Затем совершайте звонки как обычно. Конечно, вся проверенная информация SAS больше не существует, и ее необходимо воссоздать (см. SAS).

Если вы начинаете с нового файла кэша ZRTP или впервые звоните партнеру, GNU ZRTP выдает следующее предупреждение: Нет доступных сохраненных общих секретов — необходимо проверить SAS.

Файл кэша ZRTP скопирован хакером?

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

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

GNU ZRTP сообщает об этой ошибке, если файлы кэша ZRTP не синхронизированы: общие секреты, признанные действительными, существуют, но совпадений не найдено — следует проверить SAS.