CC BY
187
УДК 004.056
ИССЛЕДОВАНИЕ ВЕРОЯТНОСТНО-ВРЕМЕННЫХ ХАРАКТЕРИСТИК ПРОТОКОЛА РАСПРЕДЕЛЕНИЯ КЛЮЧЕЙ ЗАЩИЩЕННОЙ IP-ТЕЛЕФОНИИ
М. М. Ковцур,
аспирант В. Н. Никитин,
канд. техн. наук, доцент
Санкт-Петербургский государственный университет телекоммуникаций им. проф. М. А. Бонч-Бруевича А. В. Винель,
канд. техн. наук, ведущий научный сотрудник ЗАО «НПФ ИНСЕТ», г. Москва
Разработана математическая модель криптографического протокола распределения ключей IP-телефонии Zimmermann Real-time Transport Protocol в виде вероятностного графа. Представлены теоретические зависимости вероятностно-временных характеристик данного протокола от параметров канала связи: задержки пакетов и вероятности битовых ошибок. Выполнено сравнение полученных теоретических оценок с результатами экспериментального моделирования.
Ключевые слова — ключ, криптографический протокол, канал с ошибками, среднее время выполнения, вероятность успешного завершения, ZRTP, IP-телефония.
Введение
В отличие от традиционной телефонии, использующей коммутацию каналов (аналоговых или цифровых), IP-телефония — это технология, обеспечивающая передачу речевого сигнала с применением коммутации пакетов в IP-сетях. В IP-телефонии, как правило, применяются протокол Real-time Transport Protocol (RTP)/Real-time Transport Control Protocol (RTCP) [1] для передачи голоса и один из протоколов сигнализации Session Initiation Protocol (SIP) [2], H.323, Media Gateway Control Protocol (MGCP) или H.248 для установления и поддержания соединения.
Наибольшее распространение в настоящий момент получил протокол SIP, отличающийся простотой реализации, гибкостью и расширяемостью.
При вызове вначале отрабатывает протокол SIP, позволяющий установить соединение между корреспондентами. Как только корреспондент снимает трубку, начинает работу протокол RTP/ RTCP. Сценарии установления соединений представлены на рис. 1, а схема обмена сообщениями — на рис. 2, а.
В силу общедоступности используемых каналов передачи голосовой информации особую актуальность приобретает обеспечение конфиденциальности VoIP. Для этих целей разработаны протоколы обеспечения безопасности IP-телефонии, которые можно разделить на 3 категории:
— протоколы защиты сигнализации (Secured SIP);
— протоколы защиты медиаинформации (SRTP);
— протоколы генерации/распределения ключей для протоколов защиты медиаинформации (Multimedia Internet KEYing (MIKEY), Session Description Protocol Security (SDES), ZRTP, Datagram Transport Layer Security (DTLS)).
Протокол Secured SIP работает по аналогии с протоколом HyperText Transfer Protocol Secure (HTTPS), когда между корреспондентом и сервером организовывается туннель с использованием сертификатов и открытого ключа (Secure Sockets Layer — SSL). Все SIP-сообщения (сигнализация) передаются по этому туннелю.
Для обеспечения безопасности передачи речи широко используется защищенный протокол ре-
Кор. А
SIP
RTP
Кор. Б
SIP
Кор. А 1 1
RTP
SIP
SS
Кор. А
SIP
RTP
Ч ssi г
RTP
SIP
Кор. Б
<-
♦■fSS^Y
SIP Кор. Б
RTP
Условные обозначения
Кор. А/Б — Корреспондент А/Б
SS — SoftSwitch, IP телефонная станция
GW — gateway, шлюз
ТФОП — телефонная сеть общего пользования E1 — цифровой поток E1 АЛ — абонентская линия
Кор. А < sip .
RTP
SIP
Кор. А SIP
1 *
RTP
RTP
SIP
GW
E1
^тфоп)
ч—АЛ ►
Кор. Б
1< SIP 0 E1 „(too^ - E1
> GW
SIP
RTP
SS2
SIP Кор. Б
RTP
■ Рис. 1. Типовые сценарии соединений в IP-телефонии
а)
192.168.2.241 192.168.2.104
(5060) (5060) (5060) (5060) INVITE SDP (5060) (5060) (5060) (5060)
100 Trying
180 Ringing
200 OK SDP
ACK
(5060) (19976) (19976) (5060) (5060) RTP(g711U) (5060) (13022) (13022) (5060) (5060)
RTP(g711U)
BYE
200 OK
б)
192.168.2.241
192.168.2.104
(5060)
(5060)
(5060)
(5060)
(5060)
(19976)
(19976)
(19976)
(5060)
(5060)
INVITE SDP
100 Trying
180 Ringing
200 OK SDP
ACK
ZRTP
RTP(g711U)
RTP(g711U)
BYE
200 OK
(5060)
(5060)
(5060)
(5060)
(5060)
(13022)
(13022)
(13022)
(5060)
(5060)
■ Рис. 2. Схема обмена сообщениями при соединении двух корреспондентов с использованием протоколов SIP/ RTP (а) и SIP/ZRTP/SRTP (б)
ального времени SRTP [3], который выполняет функции криптографической защиты (шифрование и аутентификацию сообщений) совместно с одним из протоколов, реализующих генерацию и распределение ключей.
Проблемы безопасности протокола ZRTP и его прототипа (алгоритма Диффи — Хелмана (Diffie-Hellman, DH)) исследованы в работах [4, 5]. Однако влияние его на характеристики своевременности предоставления связи не изучалось. Данная работа содержит результаты исследования вероятностно-временных характеристик одного из наиболее перспективных протоколов генерации ключей — протокола ZRTP [6, 7].
Поскольку протокол ZRTP работает сразу после завершения работы протокола сигнализации, время установления защищенного соединения увеличивается на величину времени выполнения протокола ZRTP. Пример установления соединения в защищенном режиме представлен на рис. 2, б.
При работе по идеальному каналу связи протоколы SIP/ZRTP будут иметь фиксированное время выполнения, равное сумме времен, необходимых для каждой итерации протокола, но при наличии задержек и ошибок в канале связи время выполнения будет случайной величиной. Поскольку время установления соединения в телефонной связи является нормированной величиной, задача оценки вероятностно-временных характеристик протокола ZRTP по каналам с задержками и ошибками является актуальной задачей, которая решается в данной статье.
Параметры, определяющие вероятностно-временные характеристики протокола ZRTP
Протокол ZRTP реализует функции генерации ключевых параметров SRTP сессии, аутентификации корреспондентов, обеспечения конфи-
денциальности обмена сообщениями протокола, защиты от атаки вторжения посередине (Man In The Middle — MITM). Эти задачи решаются последовательно (рис. 3).
Особенностью протокола является передача сообщений протокола внутри RTP-пакетов при сохранении их совместимости с RTP\AVP (Audio and Video Payload) профилем. В этом случае ZRTP-
Корреспондент А Hello _ Корреспондент Б
Вычисления Прием/передача Прием/передача Вычисления
Hello A Hello A Версия ZRTP, опции, ZID корреспондента А
HelloACK
Получение сообщения как правило означает, что партнер поддерживает ZRTP HelloACK HelloACK
Hello
Версия ZRTP, опции, ZID корреспондента Б Hello Б Hello Б
HelloACK ►
HelloACK HelloACK
Согласование ролей корреспондентов и выполнение алгоритма Диффи—Хелмана: корреспондент Б — инициатор, корреспондент А — респондент
svr — случайное число pvr = gsvrmodp ZID корреспондента Б, опции, hvi Commit ZID корреспондента Б, опции, hvi svi — случайное число pvi = gsvimodp rsllDi = HMAC(rs1, «Initiator») rs2IDi = HMAC(rs2, «Initiator») auxsecretlDi = HMAC(auxsecret, Initiators H3) pbxsecretlDi = HMAC(pbxsecret, «Initiator») DHPart2 = pvi + rsllDi + rs2IDi hvi = hash(DHPart2||Hello корреспондента А)
DHPart1
rsllDr = HMAC (rsl, «Responder») rs2IDr = HMAC (rs2, «Responder») auxsecretlDr = HMAC (auxsecret, Responder's H3) pbxsecretlDr = HMAC (pbxsecret, «Responder») pvr, rsllDr, rs2IDr, auxsecretlDr, pbxsecretlDr pvr, rsllDr, rs2IDr, auxsecretIDr, pbxsecretIDr DHR = pvrsvimodp
DHPart2
total_hash = hash (Hello корреспондента А || Commit || DHPart1 || DHPart2) s0 = hash(c\\DHR\\ «ZRTP-HMAC-KDF» \\ZIDi\\ IDr\\total_hash\\len(sl)\\ sl\\len(s2)\\s2\\len(s3)\\s3) pvi, rsllDi, rs2IDi, auxsecretIDi, pbxsecretlDi pvi, rsllDi, rs2IDi, auxsecretIDi, pbxsecretIDi total_hash = hash (Hello корреспондента А || Commit || DHPart1 || DHPart2) s0 = hash(c |DhR|| «ZRTP-HMAC-KDF» IZIDill ZIDr\total_ hashlllen(s1)lls1 \len(s2)\ s2|| len(s3)\ s3)
Генерация ключей ZRTP и главных ключей SRTP
rs0 = HMAC(s0, «retained secret») zrtpkeyr = KDF(s0, «Responder ZRTP key», KDF_Context) zrtpkeyi = KDF(s0, «Initiator ZRTP key», KDF Context) AES CFB(MAC, D, A, V, E flags, sig)(zrtpkeyr) CFB инициализирующий вектор Confirm1 AES CFB(MAC, D, A, V, E flags, sig)(zrtpkeyr) rs0 = HMAC(s0, «retained secret») zrtpkeyi = KDF(s0, «Initiator ZRTP key», KDF_Context) zrtpkeyr = KDF(s0, «Responder ZRTP key», KDF Context)
Confirm2
AES CFB(MAC, D, A, V, E flags, sig)(zrtpkeyi) AES CFB(MAC, D, A, V, E flags, sig)(zrtpkeyi) CFB инициализирующий вектор
Conf2ACK ►
Conf2ACK Conf2ACK
■ Рис. 3. Диаграмма взаимодействия корреспондентов при выполнении протокола ZRTP
несовместимым устройством ZRTP-пакеты просто отклоняются и не влияют на установленное соединение, которое будет продолжено в незащищенном режиме. Параметры сообщений представлены в табл. 1 [7].
Протокол требует операции определения сторон — инициатора и отвечающего (респондента), поэтому она выполняется на первой фазе протокола, когда корреспонденты обмениваются сообщениями Hello. Эти сообщения содержат информацию о поддерживаемых партнерами протоколах для определения возможности использовать SRTP: поддерживаемых алгоритмах хеширования, алгоритмах шифрования, типах аутентификационных тегов, протоколах согласования ключей и др. Предусмотрена повторная передача сообщения Hello до 20 раз, после чего принимается решение о невозможности продолжать выполнение протокола ZRTP и устанавливать сессию в защищенном режиме. Повторная передача данного сообщения производится с задержкой переменной величины 50, 100, 200 мс, причем, начиная с четвертой передачи, задержка имеет постоянную величину 200 мс. Каждое принятое сообщение Hello подтверждается ответным сообщением HelloACK. Для перехода протокола в следу-
■ Таблица 1. Параметры сообщений протокола ZRTP
Назначение сообщения Обозначение Полная длина UDP-пакета, бит Подтверждение Число повторных передач (max)
Согласование параметров и возможностей корреспондентов Hello 1392 Нужно 20
Подтверждение получения Не11о-сообщения HelloACK 650 Нет
Согласования хеш-функций Commit 1392 Нужно 10
Первое сообщение обмена ключами Диффи — Хелмана DHPart1 4208 Нет
Второе сообщение обмена ключами Диффи — Хелмана DHPart2 4208 Нужно 10
Подтверждение обмена с применением сгенерированного общего ключа Confirm1 1072 Нет
Подтверждение обмена с применением сгенерированного общего ключа Confirm2 1072 Нужно 10
Подтверждение Соп:Н.гт2 Conf2ACK 560 Нет
ющую фазу оба корреспондента должны получить сообщение Hello и хотя бы один из корреспондентов должен получить сообщение HelloACK. Корреспондент, получивший сообщение HelloACK, принимает на себя роль инициатора сессии.
Перед началом второй фазы каждый из корреспондентов генерирует свое случайное число и производит вычисление DH:
первый корреспондент: pvi = ^vimod(p);
второй корреспондент: pvr = gsvrmod(p),
где svi и svr — случайные числа, закрытые ключи инициатора и респондента для алгоритма Диффи — Хелмана.
После этого корреспонденты подготавливают сообщение DHPart1/DHPart2 и формируют параметр hvi как укороченную до 256 бит хеш-функцию от конкатенации DHPart1/DHPart2 и сообщения Hello корреспондента:
hvi = hash(DHPart1 or DHPart2||Hello).
Параметр hvi предназначен для проверки правильности аутентификации и подтверждения выбора инициатора. Он передается в составе сообщения Commit.
Инициатор первым посылает сообщение Commit. В том случае если оба устройства выбирают роль инициатора и одновременно посылают сообщение Commit, сравнивается значение хеша hvi. Тот, у кого значение hvi будет больше, принимает роль инициатора.
Протоколом предусмотрена повторная передача данного сообщения до 10 раз, после чего также принимается решение о невозможности продолжать выполнение протокола ZRTP и устанавливать сессию в защищенном режиме. Повторная передача сообщения Commit производится с задержкой, величина которой имеет переменное значение 150, 300, 600, 1200 мс, причем, начиная с четвертой передачи, задержка имеет постоянную величину 1200 мс. Каждое принятое сообщение Commit подтверждается сообщением DH-Part1, после приема которого передача Commit прекращается.
В результате обмена открытыми сообщениями DHPart1 и DHPart2 формируются секретные ключи для SRTP-сессии. При этом для защиты от атаки MITM-протокол позволяет использовать данные предыдущих соединений. Для этого используется специальная таблица в памяти устройств, поддерживающих ZRTP-протокол, индексированная по ZID респондента.
Оба корреспондента используют полученные открытые ключи pvi и pvr для расчета результирующего ключа обмена Диффи — Хелмана. При
обмене в сообщениях передаются рассчитанный ранее pvi/pvr и хеш-функции значений регистров данных, распределенных в предыдущей сессии.
Корреспонденты сверяют полученные в сообщениях значения регистров данных, распределенных в предыдущей сессии, со значениями, рассчитанными локально.
Протоколом предусмотрена повторная передача сообщения DHPart2 до 10 раз, после чего также принимается решение о невозможности продолжать выполнение протокола ZRTP и устанавливать сессию в защищенном режиме. Повторная передача сообщения DHPart2 производится с задержкой, величина которой имеет переменное значение 150, 300, 600, 1200 мс, причем, начиная с четвертой передачи, задержка имеет постоянную величину 1200 мс. Каждое принятое сообщение DHPart2 подтверждается сообщением Confirm, после приема которого передача DH-Part2 прекращается.
Для подтверждения успешного формирования секретных ключей происходит обмен сообщениями Confirm1 и Confirm2, которые содержат зашифрованное с помощью Advanced Encryption Standard в режиме Cipher FeedBack (AES CFB) сообщение, передающее несколько флагов и параметров, включая время действия нового сгенерированного ключа, а также некоторые служебные флаги и опциональные цифровые подписи. Для шифрования используются ключи, рассчитанные на предыдущей фазе протокола.
Протокол считается завершенным, когда респондент отправляет сообщение Conf2ACT или первый SRTP-пакет с верным тегом аутентификации.
Математическая модель протокола и оценка вероятностно-временных характеристик
Исследуя работу протокола ZRTP в канале связи с ошибками, имеет смысл оценивать такие характеристики протокола, как зависимость среднего времени выполнения от вероятности ошибки в канале связи и вероятность успешного завершения протокола. Анализ проводится для дискретного канала без памяти, параметром которого является вероятность ошибки p0.
Для анализа вероятностно-временных характеристик (ВВХ) протокола целесообразно использовать апробированный метод вероятностных графов [8].
Граф, описывающий переход из начального состояния протокола ZRTP в состояние завершения первого этапа первой фазы при неограниченном числе передач одного сообщения Hello, имеет вид, представленный на рис. 4, а. Производящая функция такого вероятностного графа
■ Рис. 4. Граф передачи сообщения Hello при бесконечном (а) и конечном (б) числе повторов
Ю = &■,&,
1=1
где Рь — вероятность перехода из первого состояния во второе; — время, необходимое для перехода.
При расчете времени перехода от одной вершины графа к другой необходимо учитывать как время передачи сообщения протокола передачи, так и задержки, вызванные ожиданием перед передачей сообщения, которые также зависят от номера итерации, при этом производящие функции переходов имеют вид:
/1 = р1ха1,
где Р1 — вероятность успешного приема сообщения респондентом; а — время передачи сообщения, которое определяется длиной передаваемого сообщения и скоростью передачи;
/ = р2Ха2,
где р2 — вероятность неуспешного приема сообщения респондентом; а2 — время ожидания перед повторной передачей сообщения.
Тогда производящая функция графа
*12Р = Р1 ха1 + Р1Ха1 Р2*а2 +... + Р\хаа (Р2Ха2)1 +... =
= ' + **2 +... + '*2 + ... = 1 ■
1 'я
Однако в протоколе с конечным числом передач в графе (см. рис. 4, а) добавляется третье состояние неуспешного завершения (рис. 4, б).
Определим производящую функцию, учитывающую конечное число повторов, равное &. Поскольку общая производящая функция имеет вид
*12 Р = Р]Ха1 + Р]Ха1 Р2Ха2 +... + Р1ХаЛ( Р2Ха2 )к +
+ (Р1Ха2)(Р2Ха2)к+1... + Р1Ха1( Р2Ха2)' +...,
то производящая функция перехода из точки 1 в точку 2 записывается как
*12 = Р1ХаЛ (1 + Р2Ха2 + (Р2Ха2)2 +... + (Р2Ха2)к).
В случае с одинаковым временем задержки повтора
*12 = РХа ^(Р2Ха )',
1=0
сумма £ + 1 первых членов может быть также определена как
f -і) (f -і) .
(1)
Тогда производящая функция перехода из точки 1 в точку 3
*13 = Р]ХаА(Р2Ха2)к+Л +... + Р1Ха (Р2Ха2У +... =
= Р1 Ха (Р2Ха2)к+Л (1 + ^.. + 1 (Р2Ха2)/-(к+1
*1 (Р2Ха2 )к++ ^*1
= Р1Х
і- P2X
a2
(і- f>)
Среднее время перехода из точки 1 в точку 2 определяется соотношением
6*12
тпд =-
dx
(x=і).
(2)
Рассмотрим случай, когда времена ожидания при повторе сообщения будут разными. Производящая функция при этом будет иметь вид
,al
frX^ P2Xa2і
plX^ (R2Xa2k)k-
*\2 = Р1Х
+ Р1Ха1 (Р2Ха2(к+1))к+1... Р1Ха1 (Р2Ха2(к+1))к+'■.
Поскольку при переменном времени эта производящая функция не является геометрическим рядом, к ней не применимо соотношение (1).
Пусть времена а21... а2(т - 1) выполнения повторов 1 ... (т - 1) разные, а2т...а2к — одинаковые. Тогда производящая функция перехода из точки 1 в точку 2 определяется выражением
т-1
*12 = Р1хЗЛ ^ (Р2х321 У +
/=і
+ plxal( p2xa2m)
a2m\m
P2X
a2m
k-m+l
-і
(P2Xa2m-і)
(3)
Составим полный вероятностный граф для первой фазы протокола ZRTP с переменным временем ожидания (рис. 5) и определим следующие параметры:
ТНА — время формирования и передачи сообщения Hello корреспондентом А;
■ Рис. 5. Полный вероятностный граф передачи сообщения Hello
Тож — время ожидания при передаче сообщения Hello, которое выжидает корреспондент между повторными передачами сообщения;
l — размер пакета, передаваемого по каналу связи;
p0 — вероятность битовой ошибки в канале связи.
При определении производящей функции передачи одного сообщения Hello первой фазы протокола учтем следующие особенности:
— повтор сообщения Hello производится только 20 раз, причем Тож будет изменяться по закону
o їде i=o o,o5 їде i = і o,l їде i = 2 . o,2 їде і> З
Тн/ (і) =
Также введем допущение, что доставка сообщения Hello не подтверждается сообщением Hel-loACK.
При таких условиях производящая функция первой фазы протокола передачи одного сообщения Hello будет иметь вид
F (po) = Hho + H
ні
H2o-
H
/ 2і,
(4)
где Hho = ( — (1 — Po)1 )xTHA — производящая функция ветви безошибочной передачи сообщения Hello при первой передаче сообщения; ТНа = l/c (с — скорость канала связи);
Hhi = ( — (1 — Po)l) xTha + Тш — производящая функция, определяющая ветвь безошибочной передачи сообщения Hello при первой повторной передаче; ' lХ Т +iT
\М .Jha + ll\si.
Hh(i) = ( — (1 — Po) ) x HA ' ' 'iSi — производящая функция, определяющая ветвь безошибочной передачи сообщения Hello при i-й повторной передаче сообщения;
Фаза 1 Фаза 2 Фаза З Фаза 4
Hello_A, Commit+ DHPart2+ Confirm2+
Иєі^Б DHPart1 Confirm1 ConfACK
■ Рис. б. Вероятностный граф протокола ZRTP
Hh21 = F\noxThlA +20Т'1В — производящая функция, определяющая ветвь безуспешной передачи сообщения после 20 повторных передач сообщения, где Рост отражает вероятность, что сообщение Hello не было передано за 20 попыток.
Для составления полного вероятностного графа работы протокола ZRTP (рис. 6) воспользуемся диаграммой взаимодействия (см. рис. 3).
Для получения необходимых оценок в соответствии со статьей [8] граф разбивается на ветви, характеризующие успешное и неуспешное выполнение протокола в каждой фазе и затем упрощается для определения полной производящей функции протокола. Производящая функция упрощенного графа (рис. 7) используется для оценки среднего времени успешного завершения протокола.
Производящая функция всего графа имеет вид
Hfu\\ = НН0_20 ■ НН0_20 ■ HQ0_10 ' HN0_10 x x HK0 _ 10 + HT21 ■ HH21 + HH0 _ 20 x
: (нт2і ' HH2l + Hi ■ (HN0
Hr
H0 _ 20 ■ HDl і[ HQl і + і0 ■ HKll + hnii)]).
700 _ 10 '(
Производящая функция ветви успешного завершения протокола имеет вид
Hsuccess = HH0_20 ■ HH0_ 20 X X HQ0_і0 ■ HN0_і0 ■ HK0_і0.
(5)
Производящая функция ветви неуспешного завершения протокола имеет вид
#fail = HT2i ■ HH2i + HH0_20 X
x ШТ21 ■ Нн2i + HH0 _ 20 ■ Hq11[Hq11 H + Hq0 _io ■ (HN о _io ■ HK11 + Д^ц)])
Фаза 1 Фаза 2 Фаза З Фаза 4
Hello A, Commit+ DHPart2+ Confirm2+
Иєі^Б DHPart1 Confirm1 ConfACK
■ Рис. 7. Упрощенный вероятностный граф протокола ZRTP
Hfai\ = НТ21 ■ НН21 + НН0_20 ■ (НТ21 ' HH21 +
+ HH0 _ 20 ■ HDM[HQ11 + HQ0 _ 10 x x (HN0_10 ■ HK11 + Hnh)\)-
На первом и втором этапе первой фазы протокола ZRTP, при передаче Hello от корреспондента А к корреспонденту Б и при передаче Hello от Б к А, сообщения имеют одинаковые параметры, поэтому передача сообщений для обоих этапов может быть представлена в виде одинаковых функций:
l9 y I1
HH0 20(x, P0) = Е HA Ы X po) П hT, T
y=0 l/=l >\
20
+ HA _
Ax, po) П Нт(і, x) i=0
где производящая функция передачи сообщения с номером y
NH
HA po) = (і-po)NHX c \l-(l-p0)NH ]xTH'(y
' l9 [і-po )\NH [i-(\-л )NH |y]
Е
y=0
нA_Тпо(x, p0
По аналогии определяются производящие функции для следующих фаз протокола: Нд0 ю
и H
N0 10
описывают передачу сообщений второй и третьей фазы протокола, а именно передачу Commit+DH1 и DH2+Confirm1 сообщений. Общая максимальная длина сообщений Commit+DH1 и DH2+Confirm1 составляет соответственно 5600 и 5280 бит. В связи с тем, что в фазах 2 — 4 определены иные времена ожидания, используется производящая функция Нп ветви ожидания перед повторной передачей сообщения в случае недоставки на предыдущей попытке:
Hd(і, x) = x
= x'Di(i)
Tdі (і) =
0 їде i=0 0,і5 їде і = і 0,3 їде і = 2 . o,B їде i = З і,2 їде і> 4
Аналогично определяется производящая функция Нк для четвертой фазы протокола, когда передаются сообщения Confirm2 + Confirm2ACK общим размером 1632 бит.
Для расчета среднего времени успешного завершения протокола в соответствии с (2) необходимо вычислить первую производную производя-
щей функции ветви успешного выполнения протокола (5) в точке х = 1.
Для вышеописанной модели был произведен расчет для работы протокола в каналах связи с разным значением вероятности ошибок и при различных величинах задержки пакетов. График зависимости среднего успешного времени выполнения протокола ZRTP представлен на рис. 8, а, а в канале с малой вероятностью ошибки — на рис. 8, б.
Вероятность успешного завершения определяется соотношением
а) T , с
ср
40 35 30 25 20 15 10 5 0
1
1
!1
Ае 11 1 1
1 х 10-
б) T*, с 15
12
9
6
3
0
1 х 10-
1 х 10-
0,01
pg
if
А у
у
і. ■ • * "Г
1 х 10-
1 х 104
— Тср при задержке 50 мс
ср
Тср при задержке 100 мс
ср
— Тср при задержке 150 мс
ср
Тср при задержке 200 мс
ср
— Тср при задержке 300 мс
ср
1 х
10-3
p0
■ Рис. 8. Зависимость среднего времени выполнения протокола ZRTP от вероятности ошибки в канале с задержками пакетов на интервале 105 < p0 < 102 (а) и 105 < p0 < 103 (б)
P
1,4
1,2
1
0,8
0,6
0,4
0,2
0
1 х 105 1 х 104 1 х 103 0,01
p0
----P успешного завершения при задержке 300 мс
----P успешного завершения при задержке 50 мс
■ Рис. 9. Зависимость вероятности успешного завершения протокола ZRTP от вероятности ошибки
^success = НН0_ 20(x = 1)НН0_ 20(x = 1)x
x HQ0 _ 10(x = 1)HN0_10(x = 1)HK0_ 10(x = "0-
График зависимости вероятности успешного завершения протокола от вероятности ошибок в канале представлен на рис. 9.
Экспериментальная оценка ВВХ протокола
Целью эксперимента является оценка влияния потери пакетов в канале передачи данных и задержки данных при передаче на качество речи, а также оценка среднего времени работы и вероятности успешного завершения протокола ZRTP.
Экспериментальная установка (рис. 10) состоит из трех компьютеров, управляемого коммутатора, маршрутизатора на базе ОС FreeBSD. Маршрутизатор выполняет роль имитатора канала передачи данных, воспроизводя различные состояния канала связи, и позволяет задавать величины двух параметров канала связи: процента потерянных пакетов, передаваемых через порт маршрутизатора, а также задержки для передаваемых пакетов.
Для тестирования использовались персональные компьютеры.
На компьютере ПК1 установлено ПО Wireshark, позволяющее перехватывать и анализировать пакеты, передаваемые между ПК2 и ПК3. Для реализации этой цели на управляемом коммутаторе включается функция зеркалирования портов.
На ПК2 и ПК3 устанавливаются программы — VoIP-клиент Phoner и VoIP-шлюз Zfone. Программа Phoner была выбрана в качестве VoIP-клиента, так как она имеет встроенную, настраиваемую поддержку ZRTP-протокола. Эта опция позволяет включать/выключать встроенный модуль ZRTP при проведении тестов.
Zfone — программа, созданная Филипом Циммерманом, разработчиком протокола ZRTP. Фактически данная программа играет роль шлюза для RTP-пакетов, преобразуя их в SRTP, а также позволяет выполнять ZRTP-протокол между корреспондентами для генерации ключей. В случае
ПК1
ПК3
Канал передачи данных
Коммутатор Маршрутизатор
О
%
ПК2
■ Рис. 10. Схема экспериментальной установки
-/""КОДироб^ ~7
выключения опции поддержки ZRTP на Phoner и запуска программы Zfone ZRTP-протокол будет выполняться средствами программы Zfone, что позволит сравнить поведение протокола ZRTP в реализациях двух разных разработчиков.
Перед измерением на интерфейсе маршрутизатора устанавливались настройки: процент потерянных пакетов, задержка для передаваемых пакетов.
На ПКЗ в программе Phoner был включен режим автоподнятия трубки с воспроизведением тестовой записи. При звонке с ПК2 на ПКЗ на ПК2 автоматически включалась запись разговора и сохранялась тестовая запись в том виде и с тем качеством, с которым она была доступна пользователю.
Измерение проводилось в следующей последовательности:
1) устанавливались требуемые величины потери пакетов и задержки канала передачи данных на маршрутизаторе;
2) выполнялась проверка точности установки задержки и потери пакетов утилитой ping;
3) включался сетевой снифер на ПК1, совершался звонок ПК2-ПК3, сохранялся дамп и запись звонка;
4) по дампу определялось время работы ZRTP.
Как отмечалось ранее, работа протокола ZRTP может быть организована одним из двух способов:
1) параллельно с RTP, т. е. до окончания работы ZRTP RTP-трафик передается в открытом виде. По окончании работы ZRTP голосовой трафик передается зашифрованным в SRTP;
2) до RTP; как только между абонентами включается голосовой канал, ZRTP начинает работать, при этом блокируется передача RTP. Разговор между абонентами начинается по окончании ZRTP с использованием SRTR
Программа Zfone реализует второй способ, поэтому работу ZRTP можно оценить также по голосовым диаграммам.
В качестве источника эталонного речевого сигнала (рис. 11) на одном из компьютеров был включен автоответчик, который диктует фразу «Нажмите 1, чтобы принять этот звонок; нажмите 2, чтобы отклонить его; нажмите 3, чтобы всегда принимать звонки с этого номера; нажмите 4, чтобы никогда не принимать звонки с этого номера; нажмите 5, чтобы сбрасывать звонки с этого номера и сообщить звонящему, чтобы он внес вас в список абонентов, „кому не надо звонить“».
На втором компьютере производилась запись принятого речевого сигнала.
■ Рис. 11. Запись исходного речевого сообщения
■ Рис. 12. Записи принятого речевого сообщения с учетом влияния протокола ZRTP в реализации Zfone: а — при выключенном протоколе ZRTP; б — при передаче по каналу с односторонней задержкой 0 мс; в — при передаче по каналу с односторонней задержкой 100 мс; г — при передаче по каналу с односторонней задержкой 300 мс
■ Таблица 2. Результаты измерения времени выполнения протокола ZRTP
Задержка, iwc Время выполнения, c, при потерях, %
1 5 10 15
0 0,26 0,42 0,5 0,71
100 0,99 1,19 1,38 1,90
300 2,89 3,08 3,19 3,4
Ро 5,8 ■ 10-6 2,9 ■ 10-5 6■10-5 9,3 ■ 10-5
Тcр, c
3
2.5 2
1.5 1
0,5
0
10-6 10-5
■ Тcр при задержке 0 ме
cр
Тcр при задержке 100 iwc
cр
Т„р при задержке 300 ме
0 ме задержка X 100 iwc задержка X 300 ме задержка
10-4
Ро
■ Рис. 13. Сравнение теоретических расчетов и результатов измерений среднего времени работы протокола ZRTP
Голосовые дорожки при передаче тестового звука по схеме компьютер-компьютер с учетом работы протокола ZRTP показаны на рис. 12, а—г.
Результаты измерений для различных задержек и потери пакетов в канале связи приведены в табл. 2. Для устранения случайных погрешностей в таблицу вносились средние значения измеряемого времени по результатам 20 измерений. Очевидно, что в каналах связи с задержками вре-
Литература
1. RFC 3261 Session Initiation Protocol, 2002. http://tools.ietf.org/html/rfc326l (дата обращения: 18.09.2012).
2. RFC 3550. A Transport Protocol for Real-Time Applications, 2003. http://www.ietf.org/rfc/rfc3550.txt (дата обращения: 22.09.2012).
3. RFC 3711. The Secure Real-time Transport Protocol (SRTP), 2004. http://www.ietf.org/rfc/rfc37ll.txt (дата обращения: 10.09.2012).
4. Menezes P. van Oorschot, S. Vanstone. Handbook of Applied Cryptography // CRC Press. 1996. Р. 515-520, 522-524.
5. Bresciani R., Butterfield A. Formal security proof for the ZRTP Protocol // Intern. Conf. for Internet Tech-,
мя выполнения протокола может возрастать до нескольких секунд. Например, для канала связи с задержкой 300 мс время выполнения протокола составляет около 3 с. При этом время начала защищенной передачи голоса между абонентами сдвигается на величину, равную времени работы протокола.
На рис. 13 представлены результаты сравнения времени выполнения протокола, полученные на основании теоретического анализа и экспериментальной оценки.
Заключение
Исследование показывает, что среднее время работы протокола ZRTP определяется в основном величиной задержки сообщений в канале связи. Зависимость среднего времени работы протокола ZRTP от вероятности битовых ошибок в каналах хорошего и удовлетворительного качества слабо выражена, но существенно возрастает при увеличении вероятности ошибок свыше 1 ■ 10-4.
Результаты экспериментальной оценки среднего времени работы протокола ZRTP подтверждают теоретические расчеты. Вместе с тем они несколько превышают расчетные величины, что обусловлено упрощениями, введенными при построении математической модели. Среднее время работы протокола ZRTP в каналах с задержкой более 200 мс превышает 1,5 с и в зависимости от используемого режима защищенной №-телефо-нии приводит либо к потере соответствующего фрагмента речевого сообщения, либо к передаче этого фрагмента речи в незащищенном режиме.
Таким образом, имеются существенные предпосылки для совершенствования протокола ZRTP с целью снизить зависимости времени работы протокола от задержки в канале.
nology and Secured Transactions, London, 9-12 Nov. 2009. ICITST, 2009. Р. 1-6.
6. RFC 6189. ZRTP: Media Path Key Agreement for Unicast Secure, 2011. http://tools.ietf.org/html/rfc6189 (дата обращения: 20.09.2012).
7. Ковцур М. М., Никитин В. Н., Юркин Д. В. Протоколы обеспечения безопасности VoIP-телефонии // Защита информации. Инсайд. 2012. № 3. С. 74-81.
8. Никитин В. Н., Юркин Д. В. Улучшение способов аутентификации для каналов связи с ошибками // Информационно-управляющие системы. 2010. № 6. С. 42-46.
