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][6].
  • Простота в реализации.
  • Эффективность реализации. Протокол поддерживает низкое потребление полосы пропускания, малое количество использования системных ресурсов, при этом поддерживая высокую производительность системы передачи данных. Также узлы, использующие протокол MIKEY, обмениваются сообщениями за кратчайшее время, используя минимальное расстояние между, например, между узлами А и Б.
  • Независимость от функциональной безопасности. Обмен ключами и корректное выполнение функций транспортного уровня, таких как, например, функции передачи данных без подтверждения приема, выполняются независимо.
  • Интеграция с другими протоколами безопасной передачи данных. Протокол поддерживает возможность передавать служебные сообщения другим протоколам, таким как, например, SDP.

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

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

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

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

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

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

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

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

Чтобы разобраться как устроен данный протокол, необходимо в первую очередь ознакомиться с основными конструкциями и параметрами протокола MIKEY. Для реализации функционала управления ключами MIKEY устанавливает Data SA.

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

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

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

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

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

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

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

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

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

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

,

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

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

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

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

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

В дополнение к вышесказанному, данная модель протокола MIKEY разрешает проблему, связанную с атакой "человек посередине", end-to-end шифрования, а также защищает от спуфинга. Атаки такого типа угрожают безопасности в случае, когда между узлами сети отправляются не аутентифицированные сообщения. Протокол MIKEY устраняет эту угрозу, обеспечивая взаимную аутентификацию конечных узлов сети и целостность сообщений[14].

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

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

  1. Wenyu Jiang, Henning Schulzrinne, 1999, p. 9.
  2. Andre L. Alexander et al, 2009, p. 96-97.
  3. Handley, Mark, Perkins, Colin, Jacobson, Van. SDP: Session Description Protocol (англ.). tools.ietf.org. Проверено 10 декабря 2017.
  4. Ari Takanen, Peter Thermos, 2007, p. 234.
  5. Wen-Pai Lu, Malur K. Sundareshan, 1989, p. 1014-1017.
  6. Hacker Lexicon: What Is End-to-End Encryption? (англ.), WIRED. Проверено 22 декабря 2017.
  7. McGrew, David A., Norrman, Karl. The Secure Real-time Transport Protocol (SRTP) (англ.). tools.ietf.org. Проверено 11 декабря 2017.
  8. Krishnan, Suresh, Frankel, Sheila. IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap (англ.). tools.ietf.org. Проверено 11 декабря 2017.
  9. Ari Takanen, Peter Thermos, 2007, p. 234-235.
  10. 1 2 Ari Takanen, Peter Thermos, 2007, p. 235.
  11. L. Lo Iacono, C. Ruland Confidential multimedia communication in IP networks // The 8th International Conference on Communication Systems, 2002. ICCS 2002.. — November 2002. — Т. 1. — С. 516–523 vol.1. — DOI:10.1109/ICCS.2002.1182529.
  12. Ari Takanen, Peter Thermos, 2007, p. 235-237.
  13. Ari Takanen, Peter Thermos, 2007, p. 236-240.
  14. HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) p. 12-13.

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

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