Primeshark - многоточечная система организации защищенных сеансов видеоконференцсвязи

Номинация: Инновации в программных продуктах

Растущий проект (Startup-проект)

Тема проекта:

Primeshark - многоточечная система организации защищенных сеансов видеоконференцсвязи

Primeshark – многоточечная система организации сеансов видеоконференцсвязи

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

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

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

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

Конфиденциальность (Confidentiality) Доступность сервисов (Availability) Аутентификация (проверка подлинности) (Authentication) Идентичность (Identity) Авторизация (Authorization) Целостность (Integrity) Анонимность в публичной сети (Public anonimity)

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

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

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

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

Авторизацию не следует путать с аутентификацией. Авторизация – процесс подтверждения того, что авторизующийся пользователь обладает только теми возможностями и наборами разрешений, которые были выданы именно ему. Часто, защищенные системы видеоконференцсвязи реализуют принцип AAA (authentication, authorization, accounting) предоставляемый протоколом RADIUS.

Целостность позволяет получателю определять были ли передаваемые данные модифицированы злоумышленников в процессе их передачи по каналу связи. Один из способов обеспечения целостности - проверка подлинности получаемых пакетов данных.

Анонимность в сети интернет – один из основных вопросов обеспечения безопасности сегодняшнего дня. У анонимности нет однозначного порога, после которого можно быть уверенным в её обеспечении — невозможно создать нечто «абсолютно анонимное», но можно работать над тем чтобы атаки, компрометирующие анонимность такой системы становились бы всё более и более «дорогостоящими» для злоумышленника.

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

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

полностью децентрализованная система – отсутствует необходимость в серверном оборудовании. Терминальные устройства могут самостоятельно организовывать многоточечную сессию видеоконференцсвязи. Как правило одно из клиентских устройств выполняет функцию медиасервера и сервера сигнализации, управляя сессией и потоками данных. Данные передаются по принципу «от каждого к каждому»; частично-децентрализованная система с сервером обработки сигнальных сообщений – обеспечивается поддержка функций авторизации, аутентификации, улучшенной мобильности пользователей, а также облегченной возможностью работы с символическими адресами, по сравнению с полностью децентрализованным подходом; частично-децентрализованная система с сервером конференций - обеспечивается возможность ведения централизованных адресных книг и сценариев, появляется возможность запускать сессии конференцсвязи в автоматическом режиме по расписанию, а так же централизованно осуществлять сбор статистики по сессиям конференцсвязи; частично децентрализованная система с сервером управления медиаданных - централизация по обработке медиаданных, что  позволяет понизить требования к производительности терминального оборудования и пропускной способности каналов связи, а также, в некоторых случаях более гибко учитывать топологические особенности сети связи.

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

Разумеется, наиболее перспективным с точки зрения безопасности из всех перечисленных способов организации является полностью распределенный децентрализованный подход. При реализации данного подхода в сети интернет непременно возникает ряд трудностей. Ключевым из них является практически невозможное определение IP-адресов терминальных устройств, между которыми необходимо установить сеанс видеоконференцсвязи. Здесь возможность  обеспечения практически полной анонимности негативно сказывается на процессе установления сеанса связи. На сегодняшний день данная задача решается путем создания «демонов», осуществляющих «прослушку» всех возможных заранее глубоко зашифрованных запросов на установление соединения и проверкой принадлежности данного запроса соответствующему адресату - тому, на котором запущен «демон». Проверка подразумевает дешифрование каждого пришедшего сообщения имеющимся ключом шифрования – дешифруется лишь то сообщение, которое было адресовано адресату. Данный метод хорошо описан и реализован в рамках протокола Bitсoin сервиса  Bitmessage. К сожалению, на сегодняшний день реализация данного подхода в рамках систем видеоконференцсвязи в сети Internet практически невозможна, так как требует наличие больших вычислительных ресурсов на терминальных станциях, тем более если станция - мобильное устройство.

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

Рис. 1 Схема частично децентрализованного подхода организации системы видеоконференцсвязи с сервером сигнальных сообщений

В качестве протокола сигнализации, используемого для связи с сервером сигнализации будем использовать протокол SIP (Session Initiation Protocol) – протокол установления сеансов связи. Протокол описывает, каким образом терминал может запросить начало соединения у другого терминала, используя его уникальное имя. Протокол определяет способ согласования между клиентами об открытии каналов обмена на основе других протоколов, которые могут использоваться для непосредственной передачи информации (например, RTP). Допускается добавление или удаление таких каналов в течение установленного сеанса, а также подключение и отключение дополнительных клиентов (то есть допускается участие в обмене более двух сторон — конференц-связь). Протокол также определяет порядок завершения сеанса.

В качества протокола передачи медиаданных будем использовать RTP (Real-time Transport Protocol), а точнее его модификацию SRTP (Secure RTP) описываемую далее. Протокол RTP переносит в своём заголовке данные, необходимые для восстановления аудиоданных или видеоизображения в приёмном узле, а также данные о типе кодирования информации. В заголовке данного протокола, в частности, передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также интерполировать потерянные пакеты. RTP неразрывно связан с протоколом RTCP (Real-time Control Protocol) – протоколом управления передачей в режиме реального времени. Он основан на периодической передаче пакетов управления всем участникам сеанса связи при использовании того же механизма распределения, что и протокол RTP. Протокол нижележащего уровня должен обеспечить мультиплексирование информационных и управляющих пакетов, например, с использованием различных номеров портов UDP. У SRTP также есть родственный протокол, названный Secure RTCP (или SRTCP). SRTCP обеспечивает те же самые функции, связанные с безопасностью применительно к организации RTCP сессии. Тем самым мы определили структуру работы системы видеоконференцсвязи, и основные протоколы взаимодействия и передачи данных. Исходя из вышеизложенного опишем комплекс мер, применяемых для защиты данной инфраструктуры от различных действий злоумышленников. Описание проведем опираясь на основные уровни защиты.

Обеспечение конфиденциальности медиаданных:

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

В качестве протокола передачи медиаданных используется RTP. В стандарте IETF RFC 3711 описывается его расширение SRTP. Данное расширение автоматически осуществляет процесс шифрования и дешифрования медиаданных. SRTP шифрует лишь полезную нагрузку RTP пакета, при этом его заголовок остается незашифрованным. В добавок SRTP добавляет HMAC заголовок, используемый при дальнейшей аутентификации RTP пакета.

Использование SRTP позволит полностью решить вопросы, связанные с конфиденциальностью, установления подлинности сообщения, целостности и защиту от замены медиаданных RTP.

Использование SRTP или SRTCP является необязательным при использовании RTP или RTCP, но даже если SRTP/SRTCP используются, все дополнительные возможности (такие как шифрование и установление подлинности) опциональны и могут быть включены или выключены. Единственное исключение — функция аутентификации сообщений, которая обязательна при использовании SRTCP.

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

•        Сегментированный целочисленный счётчик — типичный режим, который осуществляет произвольный доступ к любым блокам, что является существенным для трафика RTP, передающегося в публичных сетях с непредсказуемым уровнем надежности и возможной потерей пакетов. В общем случае почти любая функция может использоваться в роли «счётчика», предполагая, что эта функция не повторяется для большого числа итераций. Но стандарт для шифрования данных RTP — только обычное целочисленное значение счётчика. AES, работающий в этом режиме, является алгоритмом шифрования по умолчанию, с длиной шифровального ключа по умолчанию в 128 бит и ключом сессии длиной в 112 бит.

•        f8-режим — вариант режима с обратной связью, расширенного, чтобы быть доступным с изменённой функцией инициализации. Значения по умолчанию для шифровального ключа и ключа сессии — то же, что и в AES в режиме, описанным выше. (AES, работающий в этом режиме, был выбран для использования в мобильных сетях 3G UMTS.)

Помимо шифра AES, SRTP позволяет осуществлять прямое шифрование, используя так называемый «пустой шифр», который может быть принят как второй поддерживаемый шифр (или третий режим шифрования в дополнение к описанным двум выше). Фактически, пустой шифр не выполняет шифрования (то есть функции алгоритма шифрования, как если бы ключевой поток содержал только нули, и копирует входной поток в выходной без изменений). Это обязательное правило для реализации данного способа шифрования, которое должно выполняться в любой SRTP-совместимой системе. Также он может использоваться, когда конфиденциальность, гарантируемая SRTP не требуется, однако требуется выполнение других возможностей протокола SRTP — аутентификация и целостность сообщений.

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

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

Функция генерации ключей используется для получения сеансовых ключей, используемых в свою очередь для шифрования контекста (SRTP, шифровальные ключи контрольного протокола SRTCP и ключи сессий, опознавательные ключи SRTP и SRTCP) из одного единственного первичного ключа. Таким образом, протокол обмена ключами позволяет обменяться только первичными ключами, остальные необходимые сеансовые ключи будут получены используя данную функцию.

Периодическое изменение самой функции генерации ключей ведет к дополнительным мерам по усилению безопасности. Как правило это препятствует тому, чтобы злоумышленник (man-in-the-middle) собрал большое количество защищенного материала, зашифрованного одним единственным сеансовым ключом. Некоторые взломы легче выполнить, когда имеется большое количество зашифрованного материала. Кроме того, многократное изменение функции генерации ключей обеспечивает прямую и обратную безопасность в том смысле, что расшифрованный сеансовый ключ не ставит под угрозу другие сеансовые ключи, полученные из того же самого главного ключа. Это означает, что, даже если взломщику удалось получить определенный сеансовый ключ, он не в состоянии расшифровать сообщения, зашифрованными предыдущими и более поздними сеансовыми ключами, полученными из того же самого главного ключа. Но, естественно, что полученный первичный ключ даст возможность получить все сеансовые ключи.

SRTP полагается на внешний протокол обмена ключами, чтобы установить главный первичный ключ. Разработаны два специальных протокола совместимых с SRTP — ZRTP и MIKEY. Вопрос выбора протокола обмена ключами требует особого внимания, но, из технических соображений реализации данного протокола в рамках системы будет использоваться протокол ZRTP.

ZRTP использует метод обмена ключами Диффи-Хеллмана через медиапоток, устанавливаемый протоколом RTP, образовывающийся после инициализации звонка, используя выбранный в контексте разрабатываемой системы тип сигнализации SIP. Во время посыла звонка создаётся публичный одноразовый SIP-идентификатор, используемый для создания ключей, которыми будут шифроваться медиаданные. Таким образом пара ключей действительна только в течение одного сеанса связи, образовывая таким образом сессию SRTP. Графически весь процесс организации защищенного соединения с использованием спец. протокола ZRTP представлен на рис. 2. Здесь DH1  и DH2 – публичные значения алгоритма Диффи-Хеллмана.

Рис. 2 Процесс организации защищенного соединения с использованием ZRTP

Обеспечение аутентификация и целостности медиаданных:

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

Касаясь вопроса обмена ключами шифрования с использованием ZRTP, сам по себе алгоритм обмена ключами Диффи-Хеллмана не может обеспечить полноценную защиту от присутствия «человека посередине». Для аутентификации ZRTP использует Short Authentication String (SAS), который, обычно, является криптографическим хэшем двух публичных значений Диффи-Хеллмана. Оба значения SAS вычисляются, передаются после инициализации звонка протоколом SIP и сверяются на обоих концах соединения. Если значения не совпали, то с большой уверенностью можно предположить присутствие «человека посередине». Это даёт потенциальному «человеку посередине» всего одну попытку сгенерировать правильный SAS. Так как SAS является очень коротким сообщением, вероятность того, что при передаче, например, 16-ти битного SAS, он будет угадан равна 1/65536.

Чтобы подтвердить подлинность RTP сообщения и защитить его целостность, реализованный SRTP механизм хэширования HMAC-SHA1, определенный в RFC 2104, используется для получения 160-битового хэша, который затем урезается до 80 или до 32 битов, чтобы стать опознавательным признаком, включаемым в пакет. HMAC вычисляется с использованием полезной нагрузки RTP пакета и данных в его заголовке (включая индекс RTP-последовательности). Для защиты от модифицирования сообщений «человеком посередине», приёмник сохраняет индексы ранее полученных пакетов, сравнивает их с индексом каждого нового полученного пакета и пропускает каждый новый пакет (если он не был послан ранее). Такой подход в большой степени полагается на полную защиту целостности (чтобы лишать возможности изменить индексы последовательности пакетов для обмана).

Конфиденциальность, аутентификация и целостность сигнальных сообщений

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

В описании протокола SIP определен метод обеспечения конфиденциальности, аутентификации и целостности передаваемых сообщений с использованием протокола TLS (Transport Layer Security). TLS – протокол транспортного уровня, описанный в RFC 5246. Как и его предшественник SSL,  TLS использует асимметричную криптографию для аутентификации, симметричное шифрование для конфиденциальности и коды аутентичности для сохранения целостности сообщений. Реализация протокола SIP с использованием TLS получила название SIPS. Описание данного протокола приведено в RFC 5630. SIPS в своей реализации предполагает использование одной из четырех моделей реализации защищенного соединения:

Сервер-провайдер сертификатов – используется TLS сервер, предоставляющий сертификаты авторизации отдельным терминалам в процессе установления доверенного соединения (handshake). Модель предполагает постоянное наличие TLS-соединения. Взаимная-аутентификация – модель предполагает использование сертификатов для пар терминал-сервер, терминал-терминал. Сертификаты генерируются обеими сторонами. В данном случае, для работы модели нет необходимости иметь постоянное TLS-соединение. Использование TLS и SIP без SIPS-URI схемы – решение позволяет реализовывать «наиболее эффективную» TLS модель для SIP протокола. Этот момент описан в RFC 3261. Модель предполагает достаточно простую в реализации схему взаимодействия, в рамках которой терминальное устройство открывает TLS соединение и использует SIP-URI схему адресации, вместо SIPS-URI для всех заголовков SIP-сообщения. В данном случае в заголовке передаваемого пакета поля «Via» (чем сгенерирован пакет), отображается протокол TLS. Это благоприятно влияет на процесс передачи данного пакета, т. к. локальные политики безопасности, реализованные на промежуточном оборудовании чаще всего позволяют проход TLS-пакетов, в независимости от того, используется SIPS или нет. Использование TLS параметров – модель предполагает использование параметров, позволяющих выбирать транспортный протокол передачи SIPS пакетов в независимости от правил протокола TLS. Например оба SIPS-URI: «sips:*****@***com;transport=TCP» «sips:*****@***com;transport=SCTP»

адреса верны, но при этом стоит помнить, что UDP невозможно использовать в рамках SIPS. Данная модель устарела и ее использование в рамках данной работы не рекомендуется.

       Из всех вышеперечисленных моделей наиболее привлекательной для использования в рамках разрабатываемой системы видеоконференцсвязи является модель TLS + SIP без использования SIPS-URI схемы адресации. Весь процесс организации SIPS соединения представлен на рис. 3.

Рис. 3 Процесс организации SIPS соединения

Обеспечение доступности сервисов видеоконференцсвязи. Защита от DoS атак

Как уже было сказано выше, доступность предполагает гарантию того, что инфраструктурные ресурсы системы связи защищены от возможного их истощения за счёт действий злоумышленников, т. е. стойкость системы к различным сетевым атакам типа DoS (Denial of Service) – отказа в обслуживании.

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

Защиту от данного типа атак можно осуществить следующими способами:

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

DoS  атаки не всегда связаны именно с загрузкой эффективной полосы пропускания каналов связи. Под DoS так же понимают атаки, направленные на истощение системных ресурсов как серверов так и терминальных станций. К примеру, пусть наш SIP сервер сигнальных сообщений инициализирует внешние соединения по протоколу TCP. TCP предполагает гарантированную передачу IP-пакета, т. е. подтверждение о приеме каждого TCP сообщения. При это сервер расходует определенное количество ресурсов системы. На этом факте основано применение одной из разновидности DoS атак такого типа – SYN-атаки. Здесь, используя зараженную сеть компьютеров (ботнет), путем отправки с них огромного количества SYN-запросов (запросов в рамках инициализации TCP сессии) к SIP серверу, можно привести к истощению его системных ресурсов. В обычном случае сервер отвечает на SYN-запрос SYN/ACK-подтверждением. При этом терминал должен прислать подтверждение ACK о приеме SYN/ACK и TCP-сессия считается установленной. Но, атакующий терминал этого не делает, расходуя тем самым системные ресурсы сервера. Процесс повторяется до тех пор, пока сервер не выйдет из строя.

Защита от данного типа атак осуществляется путем использованию SYN Cookie Firewall. Firewall обрабатывает все приходящие на сервер сообщения, перехватывая при этом SYN запросы, поступающие напрямую к SIP-серверу. Здесь firewall выполняет роль промежуточного звена, защищающего  сервер от перегрузок, путем использования SYN/ACK пакетов подтверждения с Cookie меткой. TCP соединение между сервером и терминалом установится лишь в том случае если терминал вернет верное ACK+Cookie подтверждение Firewall-у на его SYN/ACK+Cookie сообщение.

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

Защита от данного типа атак осуществляется путем обеспечения требуемого уровня конфиденциальности и аутентификации пользователей. В рамках данной системы это обеспечивается путем применения протоколов SRTP и SIPS.

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

Обеспечение анонимности в публичных сетях при организации видеоконференцсвязи

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

Использование в данной работе концепции частично-децентрализованного подхода с сервером сигнализации позволяет решать часть вопросов, связанных с обеспечение анонимности. Здесь, мы исключили одну из самых уязвимых частей системы – сервер обработки и перераспределения медиаданных. Проблема очевидна – при всей децентрализации терминальных станций, потенциальным пользователям необходимо будет «доверять» оставшейся, наиболее уязвимой с точки зрения анонимности части системы – SIP серверу. Здесь мы плавно переходим от вопроса обеспечения должного уровня анонимности к вопросу обеспечения должного уровня доверия.

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

Зарегистрировать нового пользователя в системе видеоконференцсвязи Авторизовать существующего в системе пользователя (пара идентификатор/пароль) Предоставлять авторизированным пользователям необходимые для организации сеанса связи их текущие адресные данные (IP адреса назначения)

Регистрация пользователя предполагает непосредственное хранение пользовательской информации – пары идентификатор/пароль в некотором виде на некотором устройстве хранения информации. Очевидным является то, что данные нужно представить в строго защищенном виде, понятном только SIP серверу для выполнения роли сервера регистрации и авторизации. Ключевыми факторами при защите локальных данных являются: выбор алгоритма шифрования и размера ключа шифрования. На сегодняшний день, для эффективного решения задачи защиты локальных данных применяется множество подходов. Одним из таких подходов, который в последствии и был выбран для решения данной задачи стал подход шифрования данных с использованием многоядерных графических процессоров (GPU Data Encryption). Достоинствами этого метода являются возможность работы с большими объемами данных, распределенный процесс шифрования и дешифрования хранимой информации с достаточно высокой скоростью. Стойкость к взлому данных, зашифрованных этим методом практически бесконечна.

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

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

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

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

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

Интерфейс программного клиента под ОС Windows изображен на рис. 4.

Рис. 4 Интерфейс программного клиента.

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

Рис. 5 Интерфейс отладочной программы комплексной оценки активности пользователей.

На данный момент у проекта отсутствуют какие-либо источники инвестирования в реализацию. Разработка проекта осуществляется на собственные средства.

Информация о заявителе

.

23 года. (06.01.1991)

Программист-проектировщик. Менеджер проекта.

Ярославский государственный университет им. . Техник. Инструктор сетевой академии Cisco (CCNA). Магистрант радиофизики.

Россия, – 414.

*****@***com

http://www. /profile/view? id=255808280

[phone]

Бакалавр телекоммуникаций.

Сертифицированный Cisco сетевой специалист. (Cisco / Pearson Vue, License 416913472924JQYL)