CC BY
39
СОПОСТАВЛЕНИЕ ТЕХНОЛОГИЙ WEBRTC И RTMFP ПО КРИТЕРИЯМ БЕЗОПАСНОСТИ
© Тейхриб А.П.*
ЗАО «Нау-сервис», г. Екатеринбург
В статье рассматриваются вопросы обеспечения безопасности в современных технологиях осуществления коммуникаций в веб-браузерах WebRTC и RTMFP. В результате показано, что обе технологии обеспечивают защиту от несанкционированного доступа к данным за счет применения шифрования.
Работа выполнена при финансовой поддержке Министерства образования и науки Российской Федерации, уникальный идентификатор прикладных научных исследований (проекта) RFMEFI57614X00086.
Ключевые слова WebRTC, RTMFP, шифрование, безопасность интернет-коммуникаций.
Введение
Проведем сопоставление параметров защищенности голосовых интернет-коммуникаций посредством WebRTC и RTMFP в аспекте средств шифрования.
Рассматривая защищенность того или иного способа коммуникаций в сети интернет необходимо обратить внимание на решение следующих вопросов:
- методов и алгоритмов шифрования;
- способ обмена ключами;
- аутентификации и авторизации пользователей.
Реализация данных методов в рассматриваемых технологиях требуется для обеспечения защиты рассматриваемых уровней. При этом в рамках каждой технологии решение данных вопросов выполняется определенным образом.
WebRTC
Технология WebRTC никак не регламентирует процедуру установления сеанса передачи потоковых данных и лишь определяет непосредственно сам процесс передачи. Поэтому процедуру установления сеанса и передачи данных будем рассматривать отдельно.
Методы и алгоритмы шифрования. При установлении сеанса связи в методической литературе от производителей специализированных решений, предлагается использование различных решений, в частности Microsoft
* Ведущий инженер-программист.
предлагает в большинстве случаев использовать защищенное подключение WebSocket (WSS) [1]. С одной стороны, это позволяет обеспечивать безопасность подключения, с другой стороны, это увеличивает шансы удачного подключения, т.к. многие прокси-серверы отклоняют незашифрованные подключения WebSocket.
В нотации «WebSocket Security» [2] от Heroku (одна из самых популярных в мире PaaS платформ) также рекомендуется использование защищенного wss:// протокола.
Для обеспечения функционирования WSS используется TLS [3] (англ. Transport Layer Security) - безопасность транспортного уровня) - криптографический протокол, обеспечивающий защищенную передачу данных между узлами в сети, использующий асимметричную криптографию для аутентификации, симметричное шифрование для конфиденциальности и коды аутентичности сообщений для сохранения целостности сообщений. TLS устанавливает туннель, который обеспечивает низкоуровневую TCP-связь по типу точка-точка через HTTP прокси-сервер, между WebSocket Secure клиентом и сервером WebSocket.
Другим вариантом процедуры защищенного установления сеанса передачи потоковых данных в рамках технологии WebRTC является использование HTTPS запросов с долгим временем ожидания (long polling). В этом случае защищенность также обеспечивается за счет использования протокола транспортного уровня - TLS.
Таким образом, оба подхода могут использоваться для установления защищенного сеанса передачи данных. При этом защита передаваемых осуществляется на основе протокола транспортного протокола TLS.
Для безопасной передачи речи и медиа-данных в рамках WebRTC предполагается использовать традиционный Secure Real-time Transport Protocol (SRTP). Используемый в нем алгоритм шифрования AES (симметричный алгоритм блочного шифрования) позволяет реализовать функции криптографической защиты голосовых сообщений. При этом важно, что защита пакетов голосовой информации выполняется в режиме реального времени, то есть мало влияет на ключевые характеристики передачи последовательности и времени обмена данными.
Способы обмена ключами. Обмен ключами на сигнальном уровне происходит в рамках протокола TLS. А на уровне передачи потоковых данных могут использоваться протоколы, которые применяются для протокола RTP. Для генерации и распределения ключей шифрования медиаинформа-ции между субъектами коммуникации могут использоваться протоколы SDES, ZRTP, DTLS, дадим их краткое описание.
Описание протокола SDES дано в RFC 4568. В рамках данного подхода ключ передается в SIP-сообщении по сигнальному каналу, получатель использует его для шифрования трафика (при этом обмен сигнальными сооб-
щениями должен быть также защищен). Таким образом, возможность использования протокола SDES ограничивается обязательностью защиты соединения SIP/TLS (описана выше). Другим ограничивающим фактором является невозможность использования данного протокола для обеспечения безопасности «из конца в конец», например, при использовании ВАТС, SDES будет распределять ключи между субъектом коммуникации 1 и ВАТС и между субъектом коммуникации 2 и ВАТС, но не напрямую между коммуни-цирующими сторонами.
Протокол ZRTP разработан специально для VoIP и стандартизирован в RFC 6189. Протокол обеспечивает безопасную аутентификацию и обмен данными. Во время инициализации ZRTP-звонка используется метод обмена ключами Диффи-Хеллмана (криптографический протокол, позволяющий двум и более сторонам получить общий секретный ключ, используя незащищенный от прослушивания канал связи), который не обеспечивает защиту от атак типа «человек посередине» (man in the middle). Для преодоления этой проблемы в целях аутентификации применяется SAS (Short Authentication String) «короткая строка аутентификации», являющаяся сокращённым представлением криптографического хэша полученных ключей Диффи-Хеллмана.
Протокол DTLS для SRTP описан в спецификации RFC 5764. Он описывает обмен голосовым трафиком в режиме «точка-точка» с жесткой фиксацией портов UDP у субъектов коммуникации. Сообщения протокола передаются совместно с RTP -пакетами. Для организации сессии участники коммуникации обмениваются сообщениями. Так как в основе протокола DTLS лежит TLS (Transport Layer Security), использующий инфраструктуру открытых ключей (PKI), то применение DTLS возможно тоже только при наличии узлов инфраструктуры выдачи, хранения и верификации сертификатов субъектов коммуникации.
Стоит отметить, что в соответствии с проектом стандарта [4] только DTLS является обязательным для поддержки в информационных системах, реализующих WebRTC.
Аутентификация и авторизация пользователя. Технология WebRTC никак не определяет способ аутентификации и авторизации пользователей, поэтому данный вопрос требует самостоятельного решения.
RTMFP
В случае использования RTMFP подходы, рассматриваемые в контексте технологии WebRTC не могут использоваться, это связано с тем, что для установления сеанса передачи данных и непосредственной передачи используется один протокол.
Методы и алгоритмы шифрования. Рассмотрим возможности для шифрования в рамках RTMFP. В самом протоколе RTMFP не задано исполь-
зование какого-либо алгоритма шифрования, лишь указывается на необходимость его использования [5]. Однако через некоторое время после опубликования данного протокола появилось описание его конкретной реализации, которая используется в продуктах компании Adobe. Рассмотрим данную реализацию с точки зрения В этой реализации, используется шифрование с помощью шифра AES со 128 битными ключами [6]. Пакеты установления сеанса передачи потоковых данных и непосредственно передаваемые данные шифруются одинаковым образом и одинаковыми ключами.
Способы обмена ключами. Обмен ключами осуществляется в два этапа:
- на первом этапе устанавливается сессия и используется общий ключ (симметричное шифрование), который задан в [6]: «Adobe Systems 02» в кодировке UTF-8, при этом для проверки целостности пакета используется криптографическая 16-битная контрольная сумма, в рамках установления сессии происходит обмен асимметричными ключами для последующей работы;
- далее на основе алгоритма Диффи-Хеллмана происходит установление общего секретного ключа, которое становится возможным за счет установленного соединения, защищенного от модификации (но доступного для прослушивания);
- после установления общего ключа все вновь передаваемые данные кодируются с его помощью.
Аутентификация и авторизация пользователя. В реализации протокола RTMFP отсутствует какая-либо поддержка аутентификации и авторизации. В соответствии с [6] любой правильно закодированный сертификат будет считаться достоверным. В связи с этим при использовании протокола RTMFP требуется разработать отдельный алгоритм по аутентификации и последующей авторизации пользователя, который будет работать поверх протокола RTMFP.
Таким образом, в случае использования протокола RTMFP вопросы связанные с обменом ключами и шифрованием передаваемых данных имеют решение, однако не решены вопросы, связанные с авторизацией и аутентификацией пользователей, решение данного вопроса в рамках данного протокола должно быть выполнено на следующем этапе.
Таким образом, из сопоставления параметров безопасности описанных технологий видно, что для непосредственного шифрования используется алгоритм AES в той и другой технологии, однако отличается механизм обмен ключами. Так для технологии WebRTC на данный момент регламентируется использование протокола DTLS (дополнительно могут использоваться и другие алгоритмы) для обмена ключами, в то время как для RTMFP предполагается собственный алгоритм. В то же время для WebRTC отсутствует регламентация протокола установления сеанса связи, поэтому необходима разработка самостоятельного решения для проведения установления
сеанса. В то же время та и другая технология не позволяет организовать процедуру аутентификации и авторизации пользователей, участвующих в коммуникации и данный процесс должен быть разработан самостоятельно.
Выводы
В статье рассматриваются вопросы обеспечения безопасности в современных технологиях осуществления коммуникаций в веб-браузерах WebRTC и RTMFP и способы защиты в них от угрозы прослушивания, перехвата и изменения передаваемых данных. Исследование показало, что в рамках данных технологий для защиты от этой угрозы используется шифрование по алгоритму AES. Однако не регламентируется протокол установления сеанса, который должен разрабатываться отдельно и использовать самостоятельные механизмы защиты.
Список литературы
1. Microsoft. Как защитить подключения WebSocket с помощью протокола TLS/SSL (XAML) [Электронный ресурс]. - Режим доступа: https://msdn. microsoft.com/ru-ru/library/windows/apps/xaml/hh994399.aspx, свободный. -Загл. с экрана (дата обращения: 9 июня 2015).
2. Heroku. WebSocket Security [Электронный ресурс]. - Режим доступа: https://devcenter.heroku.com/articles/websocket-security, свободный. - Загл. с экрана (дата обращения: 13 июня 2015).
3. Dierks T., Rescorla E. The Transport Layer Security (TLS) Protocol. - Internet Engineering Task Force (IETF), 2008.
4. Perkins C.S., Westerlund M., Ott J. Web Real-Time Communication (WebRTC): Media Transport and Use of RTP. - Internet Engineering Task Force (IETF), 2015.
5. Thornburgh M. Adobe's Secure Real-Time Media Flow Protocol. - Internet Engineering Task Force (IETF), 2013.
6. Thornburgh M. Adobe's RTMFP Profile for Flash Communication. - Internet Engineering Task Force (IETF), 2014.
