MIKEY

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

MIKEY - акроним англ. Multimedia Internet KEYing, протокол обмена ключами разработанный специально для мультимедийных приложений, работающих в реальном времени, таких как передача потоковых аудио данных. Используется для обмена ключами для шифрования голосовых сессий протокола SRTP.

Использование MIKEY определено в RFC 3830.

Введение[править | править код]

Мультимедийные приложения – это совокупность современных цифровых средств коммуникаций, которые позволяют одновременно передавать и получать, либо преобразовывать различного рода информацию (текстовую, графическую, аудиовизуальную). К мультимедийным приложениям можно, например, отнести IP-телефонию, которая представляет из себя совокупность инфокоммуникационных протоколов с использованием различных сетевых технологий и методов, обеспечивающих стандартный для телефонии функционал (от набора номера абонента до установления двустороннего взаимодействия по каналу связи). Также к IP-телефонии можно отнести и видеоконференции (Skype, Cisco Jabber). В качестве основной технологии для организации двустороннего общения в IP-телефонии используется технология VoIP, которая обеспечивает установление и поддержание в работоспособном состоянии мультимедийного приложения. Данная технология должна качественно передавать, как речевую, так и видеоинформацию. Однако VoIP сталкивается с проблемами увеличения вероятности потери IP-пакетов, джиттеров при больших нагрузках, что приводит к потери качества передачи в сети Интернет. Поэтому, чтобы организовать качественный доступ к сети, а также устранить ошибки следования пакетов, VoIP необходимо использовать QoS (Quality of Service). Обеспечение качества доставки, однако, оказывает сильное влияние на производительность системы[1]. К тому же, если в сети применяются различные протоколы безопасной передачи данных, которые, в свою очередь, используют процедуру управления ключами, то данные протоколы также вносят свой вклад в уменьшение производительности системы передачи данных[2]. Дополнительная нагрузка особенно проявляется у устройств, которые имеют ограниченную вычислительную мощность, к ним, например, относятся карманные устройства. Хотя на сегодняшний день производительность и вычислительная мощность карманных устройств значительно улучшились, процесс организации жизненного цикла ключей, начиная с регистрации пользователя и заканчивая отменой ключа, остается ресурсоемкой задачей. Одним из протоколов безопасности для защиты мультимедийных приложений, работающих в режиме реального времени, с поддержкой управления ключами выступает протокол MIKEY. Данный протокол был разработан с целью уменьшить задержки при обмене ключами между небольшими взаимодействующими группами, находящиеся в гетерогенных сетях. Возможность обмена ключами между группами является важным свойством протокола MIKEY. Так, например, в протоколе SDP присутствует процедуры управления ключами (в сообщениях SDP опционально используется параметр, который отвечает за ключ шифрования), но в данном протоколе нет механизмов согласования ключей[3]. MIKEY, в свою очередь, решает данную проблему.

Свойства протокола MIKEY[править | править код]

Протокол MIKEY, как и любой протокол безопасности с управлением ключами, должен обладать следующими свойствами[4]:

  • End-to-end шифрование. Данное свойство гарантирует, что ключи шифрования известны только взаимодействующим сторонам. Также гарантирует безопасную передачу данных между узлами. Однако данный вид шифрования не защищен от такого рода атак, как атака "человек посередине"[5].
  • Простота в реализации.
  • Эффективность реализации. Протокол поддерживает низкое потребление полосы пропускания, малое количество использования системных ресурсов, при этом поддерживая высокую производительность системы передачи данных. Также узлы, использующие протокол MIKEY, обмениваются сообщениями за кратчайшее время, используя минимальное расстояние между, например, узлами А и Б.
  • Независимость от функциональной безопасности. Обмен ключами и корректное выполнение функций транспортного уровня, таких как, например, функции передачи данных без подтверждения приема, выполняются независимо.
  • Интеграция с другими протоколами безопасной передачи данных. Протокол поддерживает возможность передавать служебные сообщения другим протоколам, таким как, например, SDP.

Взаимодействие с протоколами безопасной передачи данных[править | править код]

Такие протоколы безопасной передачи данных, как SRTP (Secure Real Time Protocol) и IPSec используются для защиты передаваемой информации, шифрования, установления подлинности сообщений мультимедийных приложений, работающих в реальном времени[6][7]. Основная проблема, которая лежит перед данными протоколами, это то, что они не поддерживают встроенные механизмы обмена ключами. Для разрешения данной проблемы был разработан протокол MIKEY. На данный момент SRTP является единственным протоколом безопасной передачи данных, который полагается на протокол обмена ключами MIKEY для установления главного первоначального ключа. Что касается протокола IPSec/ESP, то он также поддерживают MIKEY, но для этого нужно реализовать соответствующий функционал, который потом уже используется для взаимодействия протоколов. Протокол MIKEY может использоваться в следующих режимах передачи данных[4]:

  • Unicast (один-к-одному)
  • Многоранговая сеть (многие-ко-многим, без централизованного управления).

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

Основные способы передачи и методы обмена ключей[править | править код]

MIKEY поддерживает три различных метода[8]:

  • предварительно согласованные пароли (англ. pre-shared key): наиболее эффективный способ, предполагающий, что стороны обменялись каким-то образом условным паролем, который является ключом как для шифрования, так и для дешифрования передаваемых данных, так называемое симметричное шифрование. Тем не менее поддерживать большую структуру паролей, индивидуальных для каждого адресата представляется очень сложным, особенно при масштабировании структур.
  • приватные и публичные ключи (англ. private- and public-key): несимметричное шифрование, при котором публичный ключ передаётся открытым способом (то есть по незащищённому, доступному для наблюдения каналу), и используется для шифрования сообщения. Для расшифровки сообщения используется приватный (секретный) ключ. Для полноценного масштабирования требует централизованный менеджмент поддержки обмена ключей с центром авторизации.
  • Алгоритм Диффи — Хеллмана: алгоритм, позволяющий двум сторонам получить общий секретный ключ, используя незащищенный канал связи. Этот ключ может быть использован для шифрования дальнейшего обмена с помощью алгоритма симметричного шифрования. Этот метод требует больших вычислительных ресурсов (и большее время для вычисления) чем предыдущие, и нуждается в централизованной системе поддержки авторизации ключей как и в случае открытого ключа. Однако, это является неоспоримым преимуществом для сохранения тайны.

Конструкции и определения протокола MIKEY[править | править код]

Чтобы разобраться как устроен данный протокол, необходимо в первую очередь ознакомиться с основными конструкциями и параметрами протокола MIKEY. Для реализации функционала управления ключами MIKEY устанавливает Data SA (Data Security Association). SA представляет из себя соединение, которое организуют протоколы безопасной передачи данных. При этом устанавливается прямая связь между двумя узлами сети (point-to-point). Основной целью Data SA является обмен различными атрибутами безопасности, обеспечивающие соединение и шифрование данных, между конечными точками сети. В данном случае, к атрибутам безопасности можно отнести TEK (Traffic-Encrypting Key), а также различные политики безопасности. TEK представляет из себя симметричный шифр, который используется для шифрования сообщений. Данный ключ не является постоянной величиной. Так, например, два различных зашифрованных сообщения, могут иметь совершенно разные ключи шифрования. Для того чтобы получить TEK, используется TGK (TEK Generation Key). TGK - это согласованный между узлами сети набор бит, который, напротив, является постоянной величиной в процессе передачи зашифрованных данных по каналу связи. Будем называть данный процесс передачи зашифрованных сообщений CS (Crypto Session). CS представляет из себя двунаправленный поток данных по каналу связи, который защищен различными протоколами безопасной передачи данных (SRTP, IPSec). Так как, например, SRTP определяет профиль RTP. RTP, в свою очередь, тесно связан с RTCP. Поэтому, когда в качестве протокола безопасной передачи данных выступает SRTP, CS представляет из себя два потока трафика: RTP и соответствующим ему RTCP. Оба потока разделяют общий сеансовый ключ для шифрования SRTP контекста. Сеансовый ключ получается путем использования функции генерации ключей в протоколе SRTP. Для CS в MIKEY предусмотрено хранилище. В качестве хранилища наборов CS с одинаковым TGK выступает CSB (Crypto Session Bundle). Благодаря конструкции CSB у протокола MIKEY существует возможность одновременного установления ключей и политик безопасности для различных протоколов безопасной передачи данных. Используя CSB, MIKEY может вынимать из коллекции необходимый ему TEK. Таким образом, процесс генерации TGK, его согласование с CSB, выделение необходимого TEK для текущего CS и объединение TEK с соответствующим ему протоколом безопасной передачи данных для установки Data SA определяют стандартную процедуру управления ключами MIKEY[4].

Установка сессии[править | править код]

Каждый способ передачи и метод обмена ключами (pre-shared key, private- and public-key и алгоритм Диффи-Хеллмана), определенные в протоколе MIKEY, ориентированы на то, чтобы благополучно доставить ключи шифрования узлам сети, а также создать соединение, на основе которого установить сессию, в которой осуществляется управление ключами. Подход в установки сессии у всех трех методов совпадает, но атрибуты зашифрованных сообщений отличаются в зависимости от метода обмена ключами. Для любого сообщения используются следующие общие обозначения[4]:

  • HDR – стандартный заголовок MIKEY, который содержит CSB ID (идентификатор необходимого хранилища CS), а также параметры, определяющие какой протокол безопасной передачи данных используется в процессе управления ключами MIKEY.
  • T – временная метка для предотвращения повторных атак.
  • IDi - идентификатор отправителя сообщения.
  • IDr - идентификатор получателя сообщения.
  • RAND – псевдослучайная строка байтов, которая является дополнением к TGK. Связь TGK и RAND используется для определения ключа шифрования. В качестве дополнения к выделению необходимого TEK из CSB, определяется его актуальность в текущем процессе управления ключами MIKEY.
  • SP – политики безопасности протокола безопасной передачи данных.

Прежде чем рассмотреть каждый метод обмена ключами, необходимо отметить, что основной задачей для них является составление KEMAC (Key Data Transport Payload). KEMAC - это набор зашифрованных битов. KEMAC содержит TGK в виде зашифрованной последовательности битов.

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

Вычисления выглядят следующим образом:

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

Таким образом, KEMAC вычисляется следующим образом:

,

где Idi - идентификатор отправителя (тот же идентификатор, что и указанный в сертификате).

В алгоритме Диффи-Хеллмана создается с использованием генератора группы g общий секретный ключ. После отработки алгоритма данный ключ будет являться TGK. Основной целью инициатора сообщения является отправка открытого ключа получателю. Открытый ключ вычисляется следующим образом: , где - секретная случайная величина отправителя. Получатель, в свою очередь, отправляет инициатору открытый ключ со значением: , где - секретная случайная величина получателя. Таким образом, инициатор выбирает параметры группы (группа G, генератор g) и сигнализирует об этом получателя, отправив сообщение. После обмена открытыми ключами вычисляется общий секретный ключ, который в свою очередь является TGK: .

См. также[править | править код]

Примечания[править | править код]

  1. Wenyu Jiang, Henning Schulzrinne, 1999.
  2. Andre L. Alexander et al, 2009.
  3. Handley, Mark, Perkins, Colin, Jacobson, Van. SDP: Session Description Protocol (англ.). tools.ietf.org. Проверено 10 декабря 2017.
  4. 1 2 3 4 Ari Takanen, Peter Thermos, 2007.
  5. Wen-Pai Lu, Malur K. Sundareshan, 1989.
  6. McGrew, David A., Norrman, Karl. The Secure Real-time Transport Protocol (SRTP) (англ.). tools.ietf.org. Проверено 11 декабря 2017.
  7. Krishnan, Suresh, Frankel, Sheila. IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap (англ.). tools.ietf.org. Проверено 11 декабря 2017.
  8. Arkko, Jari, Carrara, Elisabetta, Lindholm, Fredrik, Norrman, Karl, Naslund, Mats. MIKEY: Multimedia Internet KEYing (англ.). tools.ietf.org. Проверено 11 декабря 2017.

Литература[править | править код]

Ссылки[править | править код]