Область техники, к которой относится изобретение
Изобретение относится к области законного перехвата зашифрованных обменов данными.
Уровень техники
Законный перехват (LI) позволяет правоохранительным органам (LEA) получать данные сети связи в целях анализа или сбора доказательств. Эти данные обычно включают в себя подробности передачи сигналов, такие как вызываемые и вызывающие абоненты, а в некоторых случаях и само содержание "разговора".
Сервисы связи, такие как Мультимедийная подсистема протокола межсетевого взаимодействия (подсистема IMS) по стандарту 3GPP (стандарту Проекта партнерства третьего поколения), предлагают удобные сервисы связи, основанные на IP-протоколе (Протоколе межсетевого взаимодействия). Для того чтобы создать заслуживающие доверия сервисы, такие сервисы иногда предлагают защиту (кодирование и целостность/аутентичность) сеансов связи. Для того чтобы сделать возможной такую защиту, полезно, когда необходимое управление ключами входит в состав сервисов, избавляя пользователей от трудности физического конфигурирования ключей и тому подобного. Примерами таких сервисов управления ключами являются системы, основанные на протоколе Kerberos (Протоколе аутентификации сетевых пользователей), в котором так называемый Сервер управления ключами (KMS-сервер) предоставляет материал ключей пользователям. Мультимедийная подсистема протокола межсетевого взаимодействия по стандарту 3GPP (3GPP IMS) (TR 33.328 (Технический отчет 33.328, включенный в состав этой заявки посредством ссылки) использует Kerberos - подобную концепцию сервера управления ключами (MIKEY-билет, RFC (Рабочие предложения) 6043), хотя и намного более сложную и усовершенствованную. Следует понимать, что сервисы управления ключами могут быть использованы в любом типе сети коммуникаций. Только в порядке примера, нижеследующее описание фокусируется на сетях 3GPP IMS. В контексте подсистемы IMS (Мультимедийной подсистемы протокола межсетевого взаимодействия), сервисы связи основаны на RTP-протоколе (Протоколе транспортного уровня в реальном масштабе времени) и защищаются (например, шифруются) с использованием SRTP-протокола (Защищенного протокола транспортного уровня в реальном масштабе времени) (IETF RFC 3711 (Рабочие предложения 3711 Рабочей группы по инженерным проблемам сети Internet), и, таким образом, нижеследующее описание рассматривает RTP-протокол и SRTP-протокол. Однако следует понимать, что аналогичные процедуры могут быть применены и к другим протоколам защиты, таким как TLS (Протокол защиты транспортного уровня), IPsec (Защищенный протокол межсетевого взаимодействия) и так далее, и также использованы для защиты связи, основанной не на RTP-протоколе (а, например, на HTTP-протоколе (Протоколе для передачи гипертекстов), MSRP-протоколе (Протоколе трансляции сеанса передачи сообщений) и так далее).
Системы, основанные на протоколе Kerberos, на высоком уровне работают так, как проиллюстрировано на фиг. 1. На фиг. 1 (x)y обозначают элемент x информации, защищенный, например зашифрованный, посредством некоторого ключа y. Некоторыми средствами, такими как внеполосная связь, Сервер управления ключами (KMS-сервер) 1 распределяет ключи, K_А, K_В, соответственно, Алисе 2 и Бобу 3. Сервер 1 управления ключами также имеет другой ключ, K' (или средства для генерирования такого ключа K'). Kerberos - подобные протоколы используют концепцию "билета", используемого для того, чтобы переносить криптографические данные, такие как ключи, случайные однократно используемые числа ("nonce"), криптографические алгоритмы и так далее. Нижеследующие ссылочные позиции соответствуют ссылочным позициям, показанным на фиг. 1.
S1. Алиса (2), желая установить связь с Бобом (3), отправляет на Сервер (1) управления ключами запрос билета, обычно содержащий идентификационные данные Алисы (2) и Боба (3).
S2. Сервер (1) управления ключами генерирует некоторый случайный ключ (K), и зашифровывает его, используя ключ (K_А) Алисы и некоторый другой ключ (K') (это может быть или может не быть ключ (K_В) Боба). Эта вторая копия ключа (K) предназначена для Боба (3). Сервер (1) управления ключами возвращает эти два зашифрованных ключа Алисе (2). Копия для Боба обычно кодируется как "билет", который может включать в себя другую информацию (например, информацию, которая проиллюстрирована выше).
S3. Алиса (2) может дешифровать свою копию ключа (K) (используя K_А) и направляет билет Бобу (3).
S4. Боб (3) просит Сервер (1) управления ключами "разложить" этот билет. Это обычно содержит дешифрование Сервером (1) управления ключами ключа K (с использованием ключа K') и повторное его зашифровывание с использованием ключа (K_В).
S5. Повторно зашифрованная копия ключа (K) отправляется из Сервера (1) управления ключами Бобу (3).
S6. Боб (3) может теперь дешифровать ключ (K) (используя ключ (K_В)), и ключ (K) теперь совместно используется Алисой (2) и Бобом (3), которые могут использовать его для того, чтобы обмениваться защищенными (например зашифрованными) данными.
Отметим, что в некоторых вариантах протокола Kerberos используется K'=K_В. В таких ситуациях, сообщения (S4) и (S5) могут быть опущены, поскольку Боб (3) в таком случае может разложить билет локально, используя свой уже известный ключ (K_B).
Следует отметить, что Сервер (1) управления ключами, используемый Бобом (3), и Сервер (1) управления ключами, используемый Алисой (2), могут быть двумя отдельными серверами управления ключами. Если они представляют собой различные серверы управления ключами, то для того, чтобы система работала, они должны синхронизировать свои данные. В частности, когда сервер управления ключами, обслуживающий Боба (3), получает сообщение S4 ("разложение билета"), сервер управления ключами, обслуживающий Боба (3), войдет в контакт с сервером управления ключами, обслуживающим Алису (2), (если принять, что данные о местонахождении сервера управления ключами, обслуживающего Алису, например, IP-адрес (адрес по протоколу межсетевого взаимодействия), URL (универсальный указатель ресурса) или тому подобное, закодированы в билете), и запросит релевантную информацию относительно ключа (K). Связь между серверами управления ключами обычно также зашифрована с использованием IPSec-протокола (Защищенного протокола межсетевого взаимодействия) или аналогичных протоколов, что делает возможной защищенную передачу ключа (K) между серверами управления ключами.
Система управления ключами по стандарту 3GPP (проекта партнерства третьего поколения), основанная на вышеописанном принципе протокола Kerberos, работает следующим образом. Сообщения транспортируются с использованием HTTP-протокола (Протокола для передачи гипертекстов), но могут быть использованы и другие протоколы (например, использующие Протокола инициирования сеанса связи (SIP-протокола), RFC (Рабочие предложения) 3261). На фиг. 2 показана приводимая в качестве примера сетевая архитектура и сигналы, при этом нижеследующие ссылочные позиции соответствуют ссылочным позициям, показанным на фиг. 2.
Сначала, имеет место стадия самонастройки (не показанная на чертеже), в ходе которой Алиса (2) и Сервер (1) управления ключами получают совместно используемый ключ (K_А). Это может быть сделано внеполосными средствами или с использованием процедуры GBA стандарта 3GPP (TS (Технические условия) 33.220) или тому подобного. Аналогичным образом Боб (3) и Сервер (1) управления ключами также получают совместно используемый ключ (K_В), как это показано на фиг. 1.
S7. Алиса (2), желая установить связь с Бобом (3), отправляет Серверу (1) управления ключами (защищенный, например, заверенный) запрос на "билет". Это сообщение может содержать информацию о сеансе связи с Бобом (3) и параметры, необходимые для защиты (алгоритмы, однократно используемое число RAND_A и так далее).
S8. Сервер (1) управления ключами проверяет, чтобы этот запрос имел полномочия, и, если это так, то генерирует ключ (K_KMS_AB).
S9. Этот ключ защищают (например зашифровывают) с использованием ключа (K_А) и возвращают Алисе (2). Этот ключ также кодируется в билете, предназначенном для Боба (3), то есть этот билет содержит копию ключа (K_KMS_AB), зашифрованного посредством некоторого ключа (K'), аналогично тому, что показано на фиг. 1. Алиса (2) может осуществить дешифрование с использованием ключа (K_А) и восстановить ключ (K_KMS_AB).
S10. Алиса (2) передает билет (и, возможно, другие параметры, например, однократно используемое число) Бобу (3) посредством сигналов настройки сеанса связи (например, по SIP-протоколу (Протоколу инициирования сеанса связи)).
S11. Боб (3) направляет билет на Сервер (1) управления ключами, прося Сервер (1) управления ключами "разложить билет". Это сообщение может содержать дополнительные криптографические параметры, такие как однократно используемое число (RAND_B), выбранное Бобом (3).
S12. Разложение билета (способом, аналогичным способу, показанному на фиг. 1) означает, что Сервер (1) управления ключами извлекает (дешифрует) ключ (K_KMS_AB), используя ключ (K'), и повторно зашифровывает его с использованием ключа (K_B).
S13. В обратном направлении посылается ответ, который включает в себя ключ (K_KMS_AB), зашифрованный посредством ключа (K_B). Боб (3) может теперь дешифровать и восстановить ключ (K_KMS_AB).
S14. Боб может теперь сгенерировать ответ (например, закодированный в сообщении по SIP-протоколу) для того, чтобы отправить его назад Алисе (2). Он может содержать однократно используемое число (RAND_B) Боба, и, возможно, другие параметры.
На этот момент времени Алиса (2) и Боб (3) совместно обладают ключом (K_KMS_AB) и другими параметрами, например, однократно используемыми числами, криптографическими алгоритмами и так далее. Вообще говоря, любая информация, включенная в состав первоначального билета, теперь может быть признана информацией, которой совместно обладают Алиса (2) и Боб (3). В частности, Алиса (2) и Боб (3) могут использовать ключ (K_KMS_AB) в качестве основы для обеспечения связи по SRTP-ротоколу (Защищенному протоколу транспортного уровня в реальном масштабе времени), например, посредством выведения (т.е. получения на основе некоторого расчета, умозаключения) из ключа (K_KMS_AB) ключей шифрования по SRTP-протоколу и, аналогичным образом, конфигурирования других параметров в SRTP-протоколе, например, алгоритмы кодирования, "соли" и так далее. Более подробно это описано в TS (Технических условиях) 33.328 и RFC (Рабочих предложениях) 6043 (MIKEY_TICKET, определяющих подробности обработки билета).
В случае, когда в качестве сервиса предлагаются (например, оператором подсистемы IMS (Мультимедийной подсистемы протокола межсетевого взаимодействия)) сервисы управления ключами, такие как те, что описаны выше, в большинстве случаев имеется обязательное требование к Правоохранительному органу (LEA) о том, чтобы оно было в состоянии выполнить Законный перехват (LI) для того, чтобы предотвратить/раскрыть преступление, акт терроризма и так далее. Отметим, что Законный перехват означает здесь способность Правоохранительных органов "прослушивать", основываясь на ордере, обмен данными, относящийся к объекту Законного перехвата. Поскольку этот обмен данными зашифрован, то недостаточно просто получить доступ к этому зашифрованному обмену данными. Правоохранительный орган также нуждается в доступе к ключам, используемым для шифрования/дешифрования обмена сообщениями. Вообще говоря, Правоохранительному органу будет нужен доступ ко всем данным/информации, необходимым для дешифрования потока обмена данными, и обычно ответственность за предоставление этой информации лежит на операторе подсистемы IMS. В качестве альтернативы, в зависимости от конкретных национальных правил, оператор подсистемы IMS может дешифровывать и поставлять Правоохранительному органу незашифрованный поток обмена данными. Однако, оператору подсистемы IMS необходимо знание этих параметров дешифрования.
Например, предположим, что Алиса (2) ведет "разговор" в подсистеме IMS (или, вообще, осуществляет некоторую передачу данных/сообщений) с другой стороной - Бобом (3). Предположим далее, что Правоохранительный орган выдает ордер на выполнение законного перехвата в отношении обменов данными, в котором участвует Алиса (2). Теперь следует рассмотреть два случая. В момент времени, когда оператор подсистемы IMS получает ордер на Законный перехват, может иметь место один из двух случаев:
1. У Алисы (2) нет никакого текущего сеанса связи (с Бобом (3) или кем-либо еще) или,
2. Алиса (2) уже начала "разговор", например, с Бобом (3).
В любом случае, требование заключается в том, что Законный перехват должен быть в состоянии начаться немедленно. В случае (1) это довольно просто. Всякий раз, когда Алиса (2) инициирует вызов, А будет контактировать с Сервером (1) управления ключами, и Сервер (1) управления ключами (или некоторый другой объект в сети оператора), может уже быть сконфигурирован таким образом, чтобы поставлять ключ(и) и другую информацию Правоохранительному органу. Аналогичным образом, и другие узлы, участвующие в установлении связи (SIP-серверы (серверы Протокола инициирования сеанса связи), шлюзы сред и так далее) для А, могут быть сконфигурированы таким образом, чтобы "сохранять" и "направлять" Правоохранительному органу необходимые параметры, включающие в себя (зашифрованный) поток обмена данными. Случай (1) может быть охвачен уже известными способами. Однако, в случае (2) это работать не будет.
В настоящее время, стандартные IMS-сети (сети Мультимедийной подсистемы протокола межсетевого взаимодействия) являются, по существу, "не имеющими состояний" в том смысле, что они обычно не сохраняют параметры, используемые во время настройки вызова. Соответственно, в настоящее время по этой причине невозможно сделать возможным Законный перехват для вызова/сеанса связи, который уже начался: необходимые параметры могут более не иметься в наличии. Согласно решению этой проблемы, основанному на Kerberos-протоколе, например, согласно подобному решению, определенному стандартом 3GPP, можно было бы, в принципе, сохранить копию ключа (K_KMS_AB), поставленного перед этим Алисе (2) (и Бобу (3)). Когда впоследствии поступает ордер на Законный перехват, Сервер (1) управления ключами может, в таком случае, поставить ключ Правоохранительному органу. Однако, этого недостаточно для Законного перехвата, потому что одного лишь ключа не достаточно для того, чтобы дешифровать средства связи. В частности, в любом защищенном протоколе (таком как SRTP (Защищенный протокол транспортного уровня в реальном масштабе времени), TLS (Протокол защиты транспортного уровня), IPsec (Защищенный протокол межсетевого взаимодействия) и так далее) участвующие стороны (Алиса и Боб) не используют ключ, поставленный Сервером (1) управления ключами, непосредственно. В частности, они выведут некоторый вторичный ключ, основанный на ключе, поступившем от Сервера (1) управления ключами, и "однократно используемых числах" (известных выше как "RAND"), выбранных Алисой (2) и Бобом (3) (псевдо)случайным образом без контроля со стороны сети связи. В примере подсистемы IMS, который показан на фиг. 2, ключ сеанса связи может принять такую форму, как:
K_session_AB=KDF(K_KMS_AB, RAND_A, RAND_B, ….)
где
K_session_AB(K_сеанса_связи_АВ): ключ сеанса связи между Алисой (2) и Бобом (3) (используемый, например, с SRTP-протоколом)
KDF: функция выведения ключа (например, основанная на HMAC_SHA256)
K_KMS_AB (K_Сервера_управления_ключами_АВ): ключ, поставленный из Сервера управления ключами (KMS-сервера) Алисе (2) и Бобу (3)
RAND_A: случайное однократно используемое число, выбранное Алисой (2)
RAND_B: случайное однократно используемое число, выбранное Бобом (3).
Однократно используемые числа (RAND_A), (RAND_B) обычно пересылаются между Алисой (2) и Бобом (3) во время настройки сеанса связи (например, будучи включенными в сигналы SIP-протокола, соответствующие сообщениям (S10) и (S14), показанным на фиг. 2).
Таким образом, Правоохранительный орган должен был бы быть снабжен ключом (K_session_AB), что требует знания, помимо ключа (K_KMS_AB), также (по меньшей мере) и RAND_A и RAND_B. Другие требующиеся параметры могут включать в себя дополнительные однократно используемые числа, (например в случае SRTP-протокола, для того, чтобы дешифровать поток обмена данными, необходима так называемая "соль"), другую информацию, требующуюся для указания векторов инициализации (IV) для алгоритма шифрования, и алгоритмы шифрования: Алиса (2) и Боб (3) могут выбрать то, какой алгоритм, из числа набора разрешенных/поддерживаемых алгоритмов, использовать. Таким образом, для дешифрования обменов данными, выполняемого Правоохранительным органом или в другом месте, необходимо знание того, какой алгоритм предварительно выбрали Алиса (2) и (Боб 3).
Решение вышеупомянутой задачи "перехвата посреди разговора" предложено в опубликованной в рамках проекта 3GPP статье SA3LI12_017 (ftp://ftp.3gpp.org/TSG_SA/WG3_Securuty/TSGS3_LI/2012_44_Barcelona/SA3LI12_017.zip). В этом предложенном решении Сервер управления ключами делится с Алисой (2) не только ключом (K_А), но также и вторым ключом, обозначенным здесь как K_А'. Далее, в этом решении предлагается, чтобы Алиса (2) не выбирала RAND_A случайным образом, но скорее как (псевдослучайную) функцию от ключа (K_A') и, например, нового однократно используемого числа N_A.
RAND_A=F(K_A', N_A)
Это даст, например, Серверу (1) управления ключами возможность повторно сгенерировать RAND_A, если ему предоставлен доступ к числу N_A. Обращаясь к этому вопросу, решение предлагает, чтобы число N_A было включено в состав каждого мультимедийного пакета по SRTP-протоколу (как часть заголовка пакета, например, в поле Идентификатора главного ключа (MKI-идентификатора) по SRTP-протоколу), пересылаемого между Алисой (2) и Бобом (3). Аналогичным образом, предполагается, что Боб (3) также имеет второй ключ (KB'), которым он обладает совместно с Сервером управления ключами, из которого он генерирует свой RAND_B, используя однократно используемое число N_B. Следовательно, также и однократно используемое число (N_B) должно быть включено в состав каждого SRTP-пакета (пакета по Защищенному протоколу транспортного уровня в реальном масштабе времени).
Если запрос на Законный перехват поступает к оператору подсистемы IMS посреди "разговора" (или сеанса связи) между Алисой (2) и Бобом (3), то некоторый элемент, имеющий доступ к SRTP-пакетам в плоскости сред передачи, может извлекать значения N_A, N_B из этих пакетов. Сочетание этой информации с ключами (K_A') и (K_B') (имеющихся у Сервера управления ключами) дает возможность вывести ключи, используемые Алисой (2) и Бобом (3), выведя сначала значения RAND_A и RAND_B, и выведя из них и ключа (K_KMS_AB) (также полученного от Сервера управления ключами) ключа, соответствующего ключу (K_session_AB). Это решение имеет несколько недостатков:
- Оно вводит второй ключ, совместно используемый между Алисой (2) (и Бобом (3)) и Сервером (1) управления ключами, увеличивая непроизводительные затраты/сложность управления ключами.
- Оно вводит ограничения на варианты реализации клиента: в них должен использоваться некоторый предварительно заданный способ генерирования RAND-значений. Это может снизить уровень защищенности. Другая опубликованная для проекта 3GPP статья, S3 - 120175, продемонстрировала, что подобный подход, если он используется в сочетании с одной конкретной схемой управления ключами, снижает защищенность.
- Высоки непроизводительные затраты ширины полосы пропускания. Каждый SRTP-пакет должен включать в себя, по меньшей мере, значения N_A и N_B. Для безопасности, эти значения должны каждое иметь порядок 16 восьмибитовых байтов, что приводит к непроизводительным затратам 32 восьмибитовых байтов на один пакет. Это означает непроизводительные затраты в 50-100% для типичных размеров SRTP-пакета аудиоданных.
- Это решение является неполным, поскольку оно не объясняет то, каким образом отыскивать другие необходимые параметры, например, вышеупомянутую "соль" в SRTP-протоколе, криптографические алгоритмы и так далее. Неясно, будет ли необходимость в отыскании также и этих значений дополнительно увеличивать непроизводительные затраты ширины полосы пропускания вследствие необходимости кодировать в каждом пакете даже еще больше информации.
В патентной заявке US 2007/0297418 раскрывается способ для законного перехвата. Этот способ, как и вышеупомянутая SA3LI12_017, основывается на том, что сеть сохраняет копию ключа, используемого пользователями. Хотя различие заключается в том, что это раскрываемое изобретение предлагает, чтобы сеть (периодически) запрашивала ключи от пользователей. В таком случае, это, в принципе, сделало бы возможным перехват посреди "разговора". Однако, имеется несколько недостатков такой технологии. Прежде всего, сеть нуждалась бы в более или менее постоянном опросе пользователей в отношении ключей для того, чтобы не позволить пользователю, исходя из запроса о ключе, сделать вывод о том, что они подвергаются перехвату, поскольку решения для Законного перехвата имеют служебные требования в отношении того, что пользователи не должны быть в состоянии сделать это. Во-вторых, это решение обращено только на потребность в ключах и некриптографических данных, таких как информация кодирования - декодирования, и не имеет дела с другими криптографическими параметрами, необходимыми для Законного перехвата.
Раскрытие изобретения
Задача данного изобретения заключается в том, чтобы предложить способ и устройство, который делает возможным Законный перехват зашифрованных обменов данными в сети связи даже после того, как "разговор" или сеанс связи начались. В соответствии с первым аспектом изобретения предлагается способ предоставления Правоохранительному органу (LEA) доступа к зашифрованному обмену данными между посылающим узлом и принимающим узлом. Функциональное звено Сервера управления ключами (KMS-сервера) сохраняет в базе данных криптографическую информацию, используемую для шифрования обмена данными. Эта криптографическая информация связана с идентификатором, используемым для идентификации зашифрованного обмена данными между посылающим узлом и принимающим узлом. Сервер управления ключами принимает запрос, исходящий от Правоохранительного органа, на Законный перехват, причем запрос включает в себя идентификационные данные объекта для Законного перехвата. Сервер управления ключами использует эти идентификационные данные объекта для того, чтобы определить идентификатор, и извлекает из базы данных криптографическую информацию, связанную с идентификатором. Эта криптографическая информация может быть использована для дешифрования этого зашифрованного обмена данными. После этого сервер управления ключами отправляет Правоохранительному органу либо информацию, выведенную из этой криптографической информации, либо дешифрованный обмен данными. Это позволяет Правоохранительному органу получать дешифрованную версию обмена данными независимо от того, начался ли зашифрованный обмен данными до или после того, как был выдан ордер на Законный перехват.
В качестве дополнительной возможности, функциональное звено Сервера управления ключами принимает от посылающего узла запрос на билет: Этот запрос содержит криптографическую информацию, относящуюся к посылающему узлу. Сервер управления ключами генерирует первый ключ, подлежащий использованию посылающим узлом, билет, и Сервер управления ключами сохраняет в базе данных первый ключ и криптографическую информацию посылающего узла, связанную с этим идентификатором. Сервер управления ключами отправляет первый ключ и билет и информацию, относящуюся к идентификатору, посылающему узлу. Сервер управления ключами принимает от принимающего узла запрос, причем сообщение с запросом включает в себя билет, информацию, относящуюся к идентификатору, и дополнительную криптографическую информацию, относящуюся к принимающему узлу. После этого Сервер управления ключами генерирует второй ключ, подлежащий использованию принимающим узлом, и криптографическую информацию принимающего узла, связанную с этим идентификатором в базе данных. После этого второй ключ отправляют принимающему узлу.
В дополнительном варианте реализации изобретения, функциональное звено Сервера управления ключами обеспечивается в более чем одном Сервере управления ключами. В этом случае, этап генерирования второго ключа содержит обмен информацией между, по меньшей мере, двумя из Серверов управления ключами. Это позволяет реализовать этот способ в случае, когда посылающий и принимающий узлы обслуживаются различными Серверами управления ключами.
Идентификатор, если требуется, выводится с использованием, по меньшей мере какого-либо параметра из числа: временной метки, подразумеваемого знания текущего времени, порядкового номера, связанного с сеансом связи, идентификатора билета, идентификатора ключа и идентификатора сеанса связи.
В качестве дополнительной возможности идентификатор выводится с использованием идентификационных данных по меньшей мере одного узла из числа: посылающего узла и принимающего узла.
В соответствии со вторым аспектом изобретения предлагается способ организации зашифрованного обмена данными между посылающим узлом и принимающим узлом. Посылающий узел отправляет Серверу управления ключами запрос на билет, причем запрос содержит криптографическую информацию, относящуюся к посылающему узлу. Посылающий узел принимает от Сервера управления ключами ключ и информацию, связанные с идентификатором, причем идентификатор используется Сервером управления ключами для идентификации криптографической информации, относящейся к этому обмену данными и хранящейся в базе данных. Посылающий узел отправляет билет и идентификатор принимающему узлу для организации сеанса зашифрованного обмена данными с принимающим узлом. Вторая информация, выведенная из информации, связанной с этим идентификатором, включается в состав пакетов, отправляемых принимающему узлу в ходе зашифрованного обмена данными. Это позволяет Правоохранительному органу получить дешифрованную версию обмена данными независимо от того, начался ли зашифрованный обмен данными до или после того, как был выдан ордер на Законный перехват.
В соответствии с третьим аспектом изобретения, предлагается способ организации зашифрованного обмена данными между посылающим узлом и принимающим узлом. Принимающий узел принимает от посылающего узла запрос на организацию зашифрованного обмена данными. Запрос включает в себя билет и информацию, связанную с идентификатором, причем идентификатор используется функциональным звеном Сервера управления ключами для идентификации криптографической информации, относящейся к обмену данными и хранящейся в базе данных. Принимающий узел отправляет Серверу управления ключами сообщение с запросом, причем сообщение с запросом включает в себя информацию, связанную с идентификатором, и дополнительную криптографическую информацию, относящуюся к принимающему узлу. Принимающий узел принимает от Сервера управления ключами второй ключ, подлежащий использованию принимающим узлом и хранящийся в базе данных. Вторая информация, выведенная из информации, связанная с идентификатором, включена в состав пакетов, отправляемых в ходе этого зашифрованного обмена данными.
В качестве дополнительной возможности принимающий узел дополнительно отправляет посылающему узлу информацию, относящуюся к генерации второго ключа, для организации зашифрованного обмена данными между посылающим узлом и принимающим узлом.
В дополнительном варианте реализации изобретения вторую информацию, выведенную из информации, связанную с идентификатором, отправляют в ходе зашифрованного обмена данными в любом поле из числа: поля заголовка MKI-идентификатора по Защищенному протоколу транспортного уровня в реальном масштабе времени, в заголовке расширения Протокола транспортного уровня в реальном масштабе времени, тега аутентификации, дополнительного поля в заголовке Защищенного протокола транспортного уровня в реальном масштабе времени, дополнительного поля в заголовке Протокола транспортного уровня в реальном масштабе времени, и в качестве дополняющего источника в списке дополняющих источников в заголовке Протокола транспортного уровня в реальном масштабе времени.
В соответствии с четвертым аспектом изобретения, предлагается способ обеспечения Законного перехвата зашифрованного обмена данными между посылающим узлом и принимающим узлом. Узел Законного перехвата (LI) принимает пакеты, относящиеся к зашифрованному обмену данными, причем пакеты включают в себя информацию, связанную с идентификатором, связанным с криптографической информацией, используемой для шифрования обмена данными и хранящейся на Сервере управления ключами. На Сервер управления ключами отправляют запрос, причем запрос включает в себя информацию, связанную с идентификатором. Узел Законного перехвата принимает либо криптографическую информацию, связанную с идентификатором, либо дешифрованную версию зашифрованного обмена данными и отправляет криптографическую информацию, связанную с идентификатором, и/или дешифрованную версию зашифрованного обмена данными Правоохранительному органу, который, следовательно, может получить дешифрованную версию обмена данными независимо от того, начался ли зашифрованный обмен данными до или после того, как был выдан ордер на Законный перехват.
В соответствии с пятым аспектом изобретения, предлагается Сервер управления ключами, который снабжен функциональным звеном обработки данных, предназначенным для того, чтобы хранить в базе данных криптографическую информацию, используемую для шифрования обмена данными между посылающим узлом и принимающий узлом, причем криптографическая информация связана с идентификатором. Предусматривается приемник для приема запроса, исходящего от Правоохранительного органа, на Законный перехват, причем запрос включает в себя идентификационные данные объекта для Законного перехвата. Функциональное звено обработки данных выполнено с возможностью использовать идентификационные данные объекта для того, чтобы определить идентификатор и отыскать в базе данных криптографическую информацию, связанную с идентификатором, причем криптографическая информация используется для дешифрования зашифрованного обмена данными. Предусматривается передатчик для отправки криптографической информации Правоохранительному органу.
В качестве дополнительной возможности приемник устроен таким образом, чтобы принимать от посылающего узла запрос на билет, причем запрос содержит криптографическую информацию, относящуюся к посылающему узлу. В этом случае, Сервер управления ключами дополнительно содержит функциональное звено генерации, предназначенное для генерирования первого ключа, подлежащего использованию посылающим узлом, причем ключ и криптографическая информация посылающего узла связаны с идентификатором в базе данных. Передатчик дополнительно выполнен с возможностью отправлять ключ, билет и информацию, относящуюся к идентификатору, посылающему узлу. Приемник дополнительно выполнен с возможностью принимать от принимающего узла запрос, причем сообщение с запросом включает в себя билет, информацию, относящуюся к идентификатору, и дополнительную криптографическую информацию, относящуюся к принимающему узлу. Функциональное звено генерации дополнительно выполнено с возможностью генерировать второй ключ, подлежащий использованию принимающим узлом, причем второй ключ и криптографическая информация принимающего узла связаны с идентификатором в базе данных. Передатчик дополнительно выполнен с возможностью отправлять второй ключ принимающему узлу.
В соответствии с шестым аспектом изобретения предлагается посылающий узел для использования в сети связи. Этот посылающий узел снабжен передатчиком для того, чтобы отправлять Серверу управления ключами запрос на билет, причем запрос содержит криптографическую информацию, относящуюся к посылающему узлу. Предусматривается приемник для того, чтобы принимать от Сервера управления ключами ключ, билет и информацию, связанные с идентификатором, причем идентификатор используется Сервером управления ключами для идентификации криптографической информации, относящейся к обмену данными и хранящейся в базе данных. Передатчик дополнительно выполнен с возможностью отправлять принимающему узлу билет и информацию, связанные с идентификатором, для организации сеанса зашифрованного обмена данными с принимающим узлом. Предусматривается процессор, который выполнен с возможностью включать вторую информацию, выведенную из информации, связанной с идентификатором, в состав пакетов, отправляемых принимающему узлу в ходе зашифрованного обмена данными.
В соответствии с седьмым аспектом изобретения предусматривается принимающий узел для приема зашифрованного обмена данными от посылающего узла. Принимающий узел снабжен приемником для того, чтобы принимать от посылающего узла запрос на организацию зашифрованного обмена данными, причем запрос включает в себя билет и информацию, связанные с идентификатором, причем идентификатор используется функциональным звеном Сервера управления ключами для того, чтобы идентифицировать криптографическую информацию, относящуюся к этому обмену данными и хранящуюся в базе данных. Предусматривается передатчик для того, чтобы отправлять функциональному звену Сервера управления ключами сообщение с запросом, причем сообщение с запросом включает в себя билет, информацию, связанную с идентификатором, и дополнительную криптографическую информацию, относящуюся к принимающему узлу. Приемник выполнен с возможностью принимать от функционального звена Сервера управления ключами второй ключ, подлежащий использованию принимающим узлом и хранящийся в базе данных. Предусматривается процессор, который выполнен с возможностью включать вторую информацию, выведенную из информации, связанной с идентификатором, в состав пакетов, отправляемых в ходе зашифрованного обмена данными.
В качестве дополнительной возможности, передатчик дополнительно устроен таким образом, чтобы отправлять посылающему узлу информацию, относящуюся к генерации второго ключа для организации зашифрованного обмена данными.
В соответствии с восьмым аспектом изобретения, предусматривается узел Законного перехвата для использования в сети связи. Узел Законного перехвата снабжен приемником для приема пакетов, относящихся к зашифрованному обмену данными между посылающим узлом и принимающим узлом, причем пакеты включают в себя информацию, связанную с идентификатором, причем идентификатор связан с криптографической информацией, используемой для шифрования обмена данными. Предусматривается передатчик для отправки запроса Серверу управления ключами на предоставление информации шифрования для зашифрованного обмена данными, причем запрос включает в себя информацию, связанную с идентификатором. Приемник выполнен с возможностью принимать любое из числа: криптографической информации, связанной с идентификатором, и дешифрованной версии этого зашифрованного обмена данными. Передатчик дополнительно выполнен с возможностью отправлять криптографическую информацию, связанную с идентификатором, и/или дешифрованную версию зашифрованного обмена данными Правоохранительному органу.
В соответствии с девятым аспектом изобретения предусматривается компьютерная программа, содержащая машиночитаемое кодовое средство, которое, когда исполняется на компьютерном устройстве, вызывает выполнение компьютерным устройством любого из способов, описанных выше. Также предлагается компьютерный программный продукт, содержащий машиночитаемый носитель информации и компьютерную программу, которая описана выше, причем компьютерная программа хранится на этом машиночитаемом носителе информации.
Краткое описание чертежей
На фиг. 1 схематично проиллюстрирован на структурной схеме принцип протокола Kerberos, позволяющий одной стороне посылать зашифрованные данные другой стороне;
на фиг. 2 схематично проиллюстрированы на структурной схеме сетевая архитектура и сигналы для решения по управлению ключами по стандарту 3GPP;
на фиг. 3 схематично проиллюстрированы на структурной схеме сетевая архитектура и сигналы для решения по управлению ключами по стандарту 3GPP в соответствии с вариантом реализации изобретения;
на фиг. 4 проиллюстрирован формат пакета данных по SRTP-протоколу;
фиг. 5 представляет собой схему сигналов, на которой показаны сигналы для настройки сеанса связи в соответствии с вариантом реализации изобретения;
на фиг. 6 схематично проиллюстрированы на структурной схеме сетевая архитектура и сигналы для того, чтобы организации Законного перехвата в соответствии с вариантом реализации изобретения;
фиг. 7 представляет собой схему сигналов, на которой показаны сигналы для настройки сеанса связи в варианте реализации изобретения, в котором абоненты используют различные Серверы управления ключами, в соответствии с дополнительным вариантом реализации изобретения;
на фиг. 8 схематично проиллюстрирован на структурной схеме Сервер управления ключами, соответствующий варианту реализации изобретения;
на фиг. 9 схематично проиллюстрирован на структурной схеме посылающий узел, соответствующий варианту реализации изобретения;
на фиг. 8 схематично проиллюстрирован на структурной схеме принимающий узел, соответствующий варианту реализации изобретения; и
на фиг. 8 схематично проиллюстрирован на структурной схеме узел Законного перехвата, соответствующий варианту реализации изобретения.
Осуществление изобретения
В нижеследующем описании посылающий узел именуется как Алиса, а принимающий узел - как Боб. Более обобщенно, посылающий узел может в случаях использования, к которым обращено изобретение, рассматриваться в качестве узла, "инициирующего обмен данными", а принимающий узел может рассматриваться в качестве узла, "отвечающего при обмене данными". Отметим, что "принимающий узел" может также представлять собой группу приемников, например, если Алиса участвует в некотором сценарии групповой связи, например в голосовой/телевизионной многосторонней конференцсвязи. Изобретение также охватывает разветвляющиеся сценарии, например, в случае, когда Алиса направляет приглашение группе приемников, и при этом любой отдельный член группы может откликнуться на ("принять") вызов. Например, если вызов направлен по адресу *@corporate.com, и при этом любой зарегистрированный пользователь, принадлежащий домену corporate.com, может откликнуться на этот вызов.
У сервера (1) управления ключами функциональные возможности расширены для того, чтобы он мог сохранять параметры из переносящих билет сообщений таким образом, чтобы Сервер (1) управления ключами мог позже (если это необходимо, например, вследствие Законного перехвата) отыскать необходимые/релевантные параметры Законного перехвата. Отметим, что статья SA3LI12_017 неявным образом подразумевает то, что Сервер (1) управления ключами уже хранит ключ, соответствующий ключу (K_KMS_AB). Как было упомянуто выше, IMS-сети (сети Мультимедийной подсистемы протокола межсетевого взаимодействия) могут быть, по существу, не имеющими состояний, и, следовательно, желательно сохранять это свойство в максимально возможной степени. Однако, Сервер (1) управления ключами должен сохранить состояние, даже без каких бы то ни было требований Законного перехвата. Сервер (1) управления ключами должен, по меньшей мере, хранить копии ключей, совместно используемых им с Алисой (2) и Бобом (3) (ключей (K_А) и (K_В)), которые, как было упомянуто, получены от процедуры GBA (3GPP TS 33.220 (проект 3GPP, технические условия 33.220)). Поскольку такое криптографическое состояние, таким образом, уже присутствует, считается допустимым немного расширить это состояние, добавив другие параметры для того, чтобы сделать возможным Законный перехват посреди сеанса связи. Отметим, однако, что хранение этой дополнительной информации о состоянии, предназначенной для Законного перехвата, на Сервере (1) управления ключами представляет собой просто один из нескольких возможных вариантов реализации изобретения. Как будет более подробно описано ниже, это состояние мог бы хранить отдельный сервер, внешний по отношению к Серверу (1) управления ключами.
Обратимся к фиг. 3, на которой показаны приводимые в качестве примера сигналы, иллюстрирующие вариант реализации изобретения. Нижеследующие ссылочные позиции соответствуют ссылочным позициям, показанным на фиг. 3:
S15. Алиса (2), желая установить связь с Бобом (3), отправляет Серверу (1) управления ключами (защищенный, например, заверенный) запрос на "билет". Это сообщение может содержать информацию о сеансе связи и параметры, необходимые для защиты (алгоритмы, однократно используемое число RAND_A и так далее).
S16. Сервер (1) управления ключами проверяет, чтобы этот запрос имел полномочия, и, если это так, то генерирует ключ (K_KMS_AB). В дополнение к этому, Сервер (1) управления ключами присваивает идентификатор, ассоциативно связанный с билетом (он может быть связан или может не быть связан с TICKET ID (ИДЕНТИФИКАТОРОМ БИЛЕТА)), который определен в RFC 6043 (Рабочих предложениях 6043)). Этот идентификатор используется в качестве индекса в базе данных. Сервер (1) управления ключами сохраняет ключ (K_KMS_AB) и другие релевантные данные, например, RAND_A, и ассоциативно связывает эти данные с идентификатором - индексом (или индексом, выводимым из идентификатора).
S17. Этот ключ защищают (например зашифровывают) с использованием ключа (K_А) и возвращают Алисе (2). Этот ключ также кодируется в билете, предназначенном для Боба (3), то есть этот билет содержит копию ключа (K_KMS_AB), зашифрованного посредством некоторого ключа (K'). Сообщение также содержит идентификатор (или некоторое другое значение, из которого может быть выведен идентификатор). Алиса (2) может осуществить дешифрование с использованием ключа (K_А) и восстановить ключ (K_KMS_AB). Алиса (2) также извлекает и сохраняет идентификатор для более позднего использования. Алиса (2) может также принять идентификатор (или некоторое другое значение, из которого может быть выведен идентификатор) другими средствами (например, в другом сообщении), если она в состоянии установить его ассоциативную связь с данными, упомянутыми на этапе S16. Значение, из которого может быть выведен идентификатор, может, например, представлять собой временную метку, подразумеваемого знания текущего времени, порядкового номера, который несет в себе протокол, используемый в сеансе связи, идентификатор данного сеанса связи, который несет в себе некоторый другой протокол, ассоциативно связанный с данным сеансом связи, вышеупомянутый TICKET ID (Идентификатор билета) из RFC 6043 (Рабочих предложений 6043) и так далее.
S18. Алиса (2) передает билет (и, возможно, другие параметры, например, однократно используемые числа) Бобу (3) посредством сигналов настройки сеанса связи (например, по SIP-протоколу). Кроме того, в этом сообщении также закодирован идентификатор.
S19. Боб (3) направляет билет и идентификатор Серверу (1) управления ключами, прося Сервер (1) управления ключами разложить этот билет. Разложение билета содержит проверку его действительности и проверку полномочий Боба на получение ключа, ассоциативно связанного с билетом. Это сообщение может содержать дополнительную криптографическую информацию, такую как однократно используемое число (RAND_B), выбранное Бобом (3). Оно может также включать в себя значение, исходя из которого как Боб (3), так и Сервер (1) управления ключами могут вычислить RAND_B. Такого рода значение могло бы представлять собой явный или подразумеваемый порядковый номер, добавленный с этой целью, или некоторый существующий порядковый номер из другого протокола, который используется повторно, временную метку, некоторое другое значение, которое является уникальным для этого сеанса связи (используемое совместно с чем-то, что является уникальным для Боба (3), например, его идентификационными данными в формате NAI (Идентификатора доступа к сети)). Можно предположить и другие примеры.
S20. Для того, чтобы разложить билет, Сервер (1) управления ключами, используя ключ (K'), извлекает (дешифрует) ключ (K_KMS_AB) проверяет то, чтобы было разрешено разложение билета Бобом, и повторно зашифровывает его с использованием ключа (K_B). Сервер (1) управления ключами также обновляет запись в базе данных, проиндексированную посредством идентификатора (или посредством индекса, выводимого из идентификатора), внося в нее релевантные параметры, например, RAND_B. В зависимости от того, какое значение Боб (3) включал (в состав сообщения) на этапе S19, Серверу (1) управления ключами, возможно, придется выполнить вычисление для того, чтобы вывести значение для внесения в запись, проиндексированную посредством идентификатора. Сервер (1) управления ключами может также предпочесть вставить значение (значения), принятые от Боба (3), непосредственно в таблицу и выполнить необходимые вычисления тогда, когда впервые потребуется окончательное значение.
S21. В обратном направлении присылается ответ, который содержит ключ (K_KMS_AB), зашифрованный посредством ключа (K_В). Боб (3) может дешифровать и восстанавливать ключ (K_KMS_AB). Также, если в этом сообщении был перенесен идентификатор, Боб (3) извлекает и записывает идентификатор. Если сообщение не несло в себе идентификатора, по тем же самым причинам, которые приведены на этапе S17, то Боб выводит идентификатор, соответственно, некоторым другим способом. Идентификатор, может, например, быть в зашифрованной форме в сообщении S18, в таком случае Боб (3) может извлечь эго только после получения ответа от Сервера управления ключами.
S22. Теперь Боб (3) может сгенерировать ответ для того, чтобы отправить его назад Алисе (2). Он может содержать однократно используемое число (RAND_B) Боба (3) и, возможно, другие параметры. Бобу (3) может потребоваться выполнить некоторые вычисления над данными, которые он получил от Сервера управления ключами, для того, чтобы быть в состоянии произвести, например, сгенерировать число (RAND_B), если число (RAND_B) может быть выведено из упомянутых данных. Например, Сервер (1) управления ключами может возвратить временную метку, которую, для выведения числа (RAND_B), Боб (3) должен использовать вместе с ключом, который он использует совместно с Сервером (1) управления ключами. Ключевым моментом здесь является то, что Сервер (1) управления ключами имеет полную информацию о том, какое значение Боб (3) выведет и отправит Алисе (2).
На этой стадии может начаться передача SRTP-пакетов между Алисой (2) и Бобом (3). В состав каждого пакета Алиса (2) и Боб (2) включает закодированное значение идентификатора или информации, выведенной из идентификатора, которая позволяет Серверу (1) управления ключами восстановить идентификатор. В предпочтительном варианте реализации изобретения, для переноса этого закодированного значения используется поле заголовка MKI-идентификатора (Идентификатора главного ключа) по SRTP-протоколу. Также возможны и другие опции по кодированию идентификатора в SRTP-пакетах. Примеры включают в себя перенос идентификатора в заголовке расширения по RTP-протоколу, перенос его в части тега аутентификации, добавление нового поля в заголовок по RTP-протоколу или SRTP-протоколу, добавление его в качестве дополняющего источника в список дополняющих источников (поле CSRC) в конце заголовка RTP-протокола.
Отметим теперь, что вышеописанная процедура обеспечивает Серверу (1) управления ключами доступ ко всем релевантным параметрам (включающим в себя числа (RAND) и так далее) даже в случае, если ордер на Законный перехват появляется в середине сеанса связи. Отметим, что идентификатор (и его кодирование) может быть довольно коротким, поскольку необходимо только, чтобы он однозначно идентифицировал запись в базе данных на Сервере (1) управления ключами. В действительности, Сервер (1) управления ключами может использовать расширенный индекс:
ID=(ID_Alice, ID_Bob, ID_AB).
и использовать его для индексации своей базы данных. При добавлении собственных идентификационных данных Алисы (2) и Боба (3) необходимо только чтобы идентификатор (ID_AB) был уникальным по отношению к паре общающихся субъектов, например, обычно было бы достаточно единственного восьмибитового байта. В таком случае, Алисе (2) и Бобу (3) необходимо только включить/кодировать идентификатор (ID_AB) в пакеты мультимедийных данных/SRTP-пакеты. Поскольку идентификатор (ID_AB) не используется ни при каком выведении ключей, то использование короткого идентификатора (ID_AB) не оказывает никакого влияния на безопасность (в отличие от вышеупомянутого SA3LI12_017). Также отметим, что в вариантах реализации клиента может быть использован любой способ для генерирования RAND-значений (случайных значений), поскольку он не зависит от идентификатора. Если для кодирования идентификатора (ID_AB) используется поле MKI-идентификатора (Идентификатора главного ключа) по SRTP-протоколу, то оно может быть использовано таким образом, чтобы иметь полную обратную совместимость с существующим вариантом реализации клиента по SRTP-протоколу благодаря использованию идентификатора (ID_AB) в качестве идентификатора для того, какой ключ использовать, поскольку идентификатор (ID_AB) является идентификатором ключа.
Имеется возможность, чтобы параметры, которые составляют идентификатор (ID), который показан выше, были пропущены через хеш-функцию, выход которой может быть или может не быть усеченным. Результат мог бы быть использован в качестве идентификатора, который может быть сделан статистически уникальным для всех практических целей. Например, используя, скажем, 80 младших битов выхода SHA256 весьма вероятно дало бы уникальное значение для всех вызовов, которые будут нуждаться в перехвата посреди.
Как было отмечено, Сервер управления ключами, используемый Бобом (3), и Сервер управления ключами, используемый Алисой (2), могут представлять собой два отдельных Сервера управления ключами, например, если Алиса (2) и Боб (3) используют различных операторов подсистемы IMS. Если они являются отдельными, то для того, чтобы система работала, они должны синхронизировать свои данные. Однако, эта синхронизация необходима не только для целей Законного перехвата. Если Сервер управления ключами, используемый Алисой (2) и Бобом (3), различается, то, когда Боб (3), на этапе S19, просит разложить билет, Серверу управления ключами, используемому Бобом, потребуется (как часть обработки данных на этапе S20) установить связь с Сервером управления ключами, используемым Алисой (2), который первоначально выдал этот билет. Если необходимо, то Серверы управления ключами могут обменяться параметрами, относящимися к Законному перехвату, (например ключами, RAND-значениями (случайными значениями) и так далее), чтобы гарантировать то, что они имеют одинаковую информацию. Это означает, что, если операторы подсистемы IMS/Серверы управления ключами принадлежат раздельным судебным юрисдикциям, Правоохранительный орган любой из этой юрисдикции будет в состоянии выполнить Законный перехват независимо, без какой бы то ни было потребности передавать дополнительную информацию об абонентах, которые являются объектом для законного перехвата, через различные домены.
Вышеприведенное описание описывает общий вариант реализации изобретения в контексте любого типа сети с пакетной коммутацией. Нижеследующее описание описывает конкретный вариант осуществления изобретения в контексте сети подсистемы IMS стандарта 3GPP. Специалист в данной области техники поймет, что использовать такое же решение можно в любом окружении, в котором развернут Kerberos-подобный сервис управления ключами. Единственные отличия заключаются в том, какие протоколы используются для транспортировки ключей/билетов (MIKEY_Ticket (Билет работы с ключами в мультимедийном Интернете), HTTP (Протокол для передачи гипертекстов), UDP (Протокол дейтаграмм пользователя) и так далее), и в том, какой протокол защиты используется для защиты связи между Алисой (2) и Бобом (3) (SRTP (Защищенный протокол транспортного уровня в реальном масштабе времени), PSK-TLS (Протокол защиты транспортного уровня с предварительно выданными ключами), IPsec (Защищенный протокол межсетевого взаимодействия) и так далее). Это просто вопрос формата/транспортировки сообщения. Влияние различных вариантов выбора на протокол защиты кроется в том, какие параметры необходимы для выполнения Законного перехвата, то есть для дешифрования. Эти параметры в некоторых вариантах реализации изобретения могли бы содержать любой или все параметры из числа:
- ключ, предоставленный Сервером (1) управления ключами (то есть соответствующий ключу (K_KMS_AB), описанному выше),
- однократно используемые числа/числа (RAND), используемые для выведения ключей (то есть, число (RAND_A) и так далее, приведенное выше),
- однократно используемые числа/"соли", используемые в протоколе защиты (например, "соль" по SRTP-протоколу),
- выбранные криптографические алгоритмы,
- счетчики или другая информация синхронизации (например, ROC (счетчик перебора по SRTP-протоколу)).
В нижеследующем описании, термин "криптографическая информация для Законного перехвата" (CLII-информация) используется для отсылки к параметрам, необходимым Правоохранительному органу (и/или оператору подсистемы IMS) для того, чтобы дешифровать зашифрованные данные. Он может содержать любой из вышеупомянутых примеров. В варианте реализации изобретения, идентификационные данные (именуемые идентификатором), используемые для идентификации CLII-информации кодируются в поле MKI-идентификатора по SRTP-протоколу. Следует понимать, что могут быть использованы и альтернативные механизмы, а этот механизм используется только в порядке примера. Например, если используется протокол защиты, отличный от SRTP-протокола, то следует понимать, что может быть использовано специальное поле другого протокола. Например, в случае IPsec-протокола могут быть использованы поле SPI-индекса (Индекса параметра защиты) или некоторое другое поле заголовка (расширения) по IP-протоколу.
Обратимся теперь к фиг. 4, на которой проиллюстрирован пакет данных по SRTP-протоколу в соответствии с IETF RFC 3711 (Рабочими предложениями 3711 Рабочей группы по инженерным проблемам сети Internet). Как было упомянуто, другие протоколы будут иметь аналогичные поля данных, например, поле Индекса параметров защиты (поле SPI индекса) по IPsec-протоколу. SRTP-пакет (пакет данных по SRTP-протоколу) (4) включает в себя заголовок (5) по RTP-протоколу и полезные данные (6) по RTP-протоколу. Полезные данные (6) обычно зашифрованы, и заголовок (5) и полезные данные (6) обычно аутентифицируются. Может также иметься поле (7) MKI-идентификатора (его использование является необязательным), которое используется для того, чтобы сообщить Алисе/Бобу то, какой ключ использовать для обработки пакета (4), когда он принят.Каждый сеанс связи по SRTP-протоколу имеет ассоциативно связанный с ним криптографический контекст, содержащий ключи, алгоритмы и другие параметры, необходимые Алисе/Бобу для обработки принятого пакета. Таким образом, вообще, Алиса (2) и Боб (3) могут иметь ряд таких контекстов, и каждый контекст может далее иметь несколько ключей. Алиса (2) и Боб (3) будет использовать IP-адрес (адрес по IP-протоколу) и номер порта (по UDP-протоколу) для отыскания правильного криптографического контекста (как это описано в RFC3711). Имея контекст, затем используют поле (7) MKI-идентификатора для определения того, какой ключ (в пределах этого криптографического контекста) использовать. Например, предположим, что криптографический контекст имеет два ключа (K_АВ1), (K_АВ2). Алиса (2) и Боб (3) каким-то образом договариваются ассоциативно связать ключ (K_АВ1) с MKI_AB1, а ключ (K_АВ2) с MKI_АВ2. Когда Алиса (2) отправляет зашифрованный пакет Бобу (3), она включает в состав поля MKI (7) пакета либо MKI_AB1, либо MKI_AB2, в зависимости от того, какой ключ она использовала для того, чтобы обработать (зашифровать) пакет. Боб (3) может, таким образом, при обследовании поля (7) MKI-идентификатора сделать вывод о том, использовать ли для обработки (дешифрования) ключ (K_АВ1), или ключ (K_АВ2).
Поле (7) MKI-идентификатора может быть коротким, только один или два байта. От него только требуется быть уникальным в пределах криптографического контекста. В частности, было бы достаточно, если MKI-идентификатор был уникальным для всего сеанса связи по SRTP-протоколу между Алисой (2) и Бобом (3), и обычно будет лишь небольшое количество таких сеансов связи.
Когда используется MIKEY-БИЛЕТ, билеты могут нести информацию, касающуюся MKI-идентификатора (7) (или, вообще говоря, SPI-тип информации). Узлы в сети оператора подсистемы IMS (например, Сервер (1) управления ключами) будут, следовательно, иметь доступ к полю (7) MKI-идентификатора в билетах.
В сущности, Сервер управления ключами будет использовать (Identity_A (Идентификационные_данные_А), Identity_B (Идентификационные_данные_В), MKI) в качестве идентификатора/индекса для CLII-информации, тогда как только часть этого идентификатора, MKI-идентификатор, входит в состав пакетов, пересылаемых между Алисой (2) и Бобом (3).
Обратимся к фиг. 5, на которой проиллюстрированы сигналы настройки сеанса связи (адаптированные из TR 33.328 (Технического отчета 33.328) проекта 3GPP). Нижеследующие ссылочные позиции соответствуют этапам, показанным на фиг. 5:
S23. Когда Сервер (1) управления ключами принимает от Алисы (2) сообщение REQUEST_INIT ("запрос билета"), этот запрос будет (в соответствии с существующими на текущий момент техническими требованиями 3GPP/IETP) включать в себя информацию, относящуюся к CLII-информации, например, RAND-значение (однократно используемое число), криптографические алгоритмы, подлежащие использованию в SRTP-протоколе, и так далее. В соответствии с изобретением, Сервер (1) управления ключами сохраняет эту CLII-информацию. Сервер (1) управления ключами также генерирует ключ (соответствующий K_KMS_AB), который будет возвращен в ответе. Сервер (1) управления ключами сохраняет также этот ключ (и любую другую информацию, относящуюся к CLII-информации, сгенерированную Сервером управления ключами, например, дополнительные однократно используемые числа, значения счетчиков и так далее, которые применимы) как часть "комплекта CLII-информации". Поскольку сообщение от Алисы (2) содержит идентификаторы для Алисы (2) и Боба (3), то в одном варианте реализации изобретения эта пара идентификационных данных используется как часть индекса или идентификатора CLII-информации, посредством которого Сервер (1) управления ключами обращается к этому комплекту CLII-информации. Сервер (1) управления ключами также присоединяет к идентификатору CLII-информации MKI-идентификатор (или соответствующее значение). Если Алиса (2) не определила MKI-значение, то Сервер (1) управления ключами может выбрать MKI-идентификатор от имени Алисы (2) и включить его в состав ответа.
S24. Сервер (1) управления ключами отправляет Алисе (2) сообщение REQUEST_RESP (ОТВЕТ_НА_ЗАПРОС). В некоторый момент времени после приема сообщения REQUEST_RESP, Алиса (2) заносит в свою базу данных криптографических контекстов по SRTP-протоколу информацию, принятую от Сервера (1) управления ключами. Она включает в себя ключ (K_KMS_AB) и MKI-идентификатор. Алиса (2) ассоциативно связывает ключ (K_KMS_AB) с этим MKI-идентификатором в соответствии со стандартным определением SRTP-протокола.
S25. Алиса (2) отправляет Бобу 3 сообщение TRANSFER_INIT (ИНИЦИИРОВАНИЕ_ПЕРЕДАЧИ). Это сообщение включает в себя билет Боба (3), включающий в себя MKI-идентификатор, другие параметры, такие как RAND_A, алгоритмы и (зашифрованную) копию ключа (K_KMS_AB), который делают доступным для Боба (3), используя, в этом примере, сигналы по SIP-протоколу (Протоколу инициирования сеанса связи).
S26. Боб (3) отправляет Серверу (1) управления ключами сообщение RESOLVE_INIT (ИНИЦИИРОВАНИЕ_РАЗЛОЖЕНИЯ). Когда Сервер (1) управления ключами принимает сообщение RESOLVE_INIT, он будет искать запись, которая проиндексирована посредством идентификатора CLII-информации (то есть идентификационных данных Инициирующей стороны и Отвечающей стороны и MKI-идентификатора, которые извлечены из принятого сообщения/билета). Сервер (1) управления ключами добавит любые релевантные дополнительные параметры, относящиеся к CLII-информации, (например, число RAND_B, предоставленное Бобом 3, и/или число RAND, выбранное/предоставленное самим Сервером (1) управления ключами, и так далее) и обновит CLII-информацию этим значением (этими значениями), проиндексированными посредством идентификатора CLII-информации.
S27. Сервер (1) управления ключами возвращает разложенный билет (включающий в себя MKI-идентификатор) Бобу (3). Боб (3) теперь аналогичным образом заполняет свою базу данных криптографических контекстов, ассоциативно связывая ключ (K_KMS_AB) с этим MKI-идентификатором.
S28. Боб (3) отправляет Алисе (2) TRANSFER_RESP (ОТВЕТ_О_ПЕРЕДАЧЕ).
В некоторой более поздней момент времени, между Алисой (2) и Бобом (3) будут пересылаться SRTP-пакеты. Эти пакеты (по умолчанию все пакеты, но по выбору только некоторые пакеты) будут включать в себя поле MKI-идентификатора. Отметим, что для Алисы (2) и Боба (3) MKI-идентификатор является только идентификатором главного ключа, с которым обращаются в соответствии со стандартными процедурами SRTP-протокола. Они не имеют понятия (и им не нужно иметь такое понятие) о расширенной "семантике" MKI-идентификатора, когда тот используется Сервером (1) управления ключами в качестве (части) идентификатора CLII-информации.
Теперь рассмотрим ситуацию, при которой, после начала обмена данными по SRTP-протоколу между Алисой (2) и Бобом (3), Правоохранительный орган выдает запрос на Законный перехват. Эта процедура, проиллюстрирована на фиг. 6, при этом нижеследующие ссылочные позиции соответствуют ссылочным позициям, показанным на фиг. 6.
S29. Правоохранительный орган (9) отправляет функциональному звену (10) Законного перехвата, управляемому оператором (И) подсистемы IMS, запрос на Законный перехват. Этот запрос включает в себя идентификатор Объекта Законного перехвата (в этом примере объектом является Алиса (2)).
S30. Оператор (11) подсистемы IMS преобразовывает принятый идентификатор в некоторый идентификатор для внутреннего использования, обозначенный как Target_ID (Идентификатор_Объекта), для объекта (2) (то, как это точно делается, находится вне объема изобретения), то есть идентификаторы, используемые Алисой (2) при запросе билетов, как это обсуждалось выше.
S31. Функциональное звено (10) Законного перехвата, имеющееся у оператора подсистемы IMS, определяет то, имеет ли Алиса (2), по меньшей мере, один продолжающийся "разговор"/сеанс связи. Это могло бы быть сделано, например, посредством обращения к серверам управления вызовами (SIP-серверам), узлам/шлюзам обработки мультимедийных данных, базам данных (например, HSS (Сервера домашних абонентов)) и так далее. Точный механизм для этого находится вне объема этого описания. Если никакого продолжающегося сеанса связи не обнаружено, то могут быть предприняты некоторые предварительные действия для Законного перехвата (они - вне объема этого описания). Если продолжающийся сеанс связи обнаружен, то процедура продолжается на этапе S32.
S32. Устанавливается связь с Сервером (1) управления ключами, и его запрашивают предоставить CLII-информацию, ассоциативно связанную с Алисой (2).
S33. Сервер (1) управления ключами выполняет поиск в своей базе данных, используя предоставленные идентификационные данные. Например, он мог бы осуществлять поиск по идентификаторам CLII-информации, имеющим форму (Target_ID, *, *), (*, Target_ID, *), где символ "*" обозначает "универсальный символ" вместо, соответственно, идентификатора другой стороны и MKI-идентификатора. В качестве альтернативы, если MKI-идентификатор и/или идентификационные данные стороны, общающейся с Алисой, каким-то образом уже известны, то эти значения могут быть явным образом включены в поиск CLII-информации.
S34. Сервер (1) управления ключами отыскивает CLII-информацию для (всех) продолжающихся сеансов связи для Алисы (2) и возвращает ее имеющемуся у оператора функциональному звену (10) Законного перехвата, включая в нее информацию, позволяющую установить взаимосвязь между CLII-информацией и относящимся к ней сеансом связи. Например, в случае, при котором Алиса (2) участвует в более чем одном сеансе связи, причем каждый сеанс связи имеет отличные от других ключи сеанса связи и другие криптографические параметры, существует необходимость в том, чтобы быть в состоянии ассоциативно связать каждый набор CLII-информации с относящимся к нему сеансом связи для обеспечения того, чтобы Правоохранительный орган мог установить соответствие правильных ключей с правильным сеансом связи. Более подробно это описывается ниже.
S35. Имеющееся у оператора функциональное звено (110) Законного перехвата предоставляет CLII-информацию (или информацию выведенную из нее) Правоохранительному органу (9).
S36. (Зашифрованный) поток обмена данными в адрес/от Алисы (Объекта) также предоставляют Правоохранительному органу (9), направляя ему поток обмена данными, относящийся к объекту перехвата, из некоторого узла в плоскости передачи мультимедийных данных, например, из SGSN-узла (Обслуживающего узла поддержки системы GPRS), Шлюза мультимедийных данных (MGw-шлюза), Граничного шлюза сеанса связи (SBG-шлюза), Функционального звена ресурса мультимедийных данных (MRF) или тому подобного. Правоохранительный орган (9) теперь имеет средства для дешифрования зашифрованного потока обмена данными.
В качестве специального варианта реализации этапа S34, вместо того, чтобы предоставлять Правоохранительному органу (9) всю CLII-информацию, имеющееся у оператора функциональное звено (10) Законного перехвата (и/или Сервер (1) управления ключами) может обследовать некоторые SRTP-пакеты объекта, в частности, поле MKI-идентификатора, и отыскать/вывести необходимые ключи и предоставить Правоохранительному органу (9) только ключи (и, возможно, другие выбранные релевантные параметры).
В зависимости от национальных правил, в качестве дополнительного альтернативного механизма к этапам S35 и S36, функциональное звено (10) Законного перехвата для того, чтобы дешифровать мультимедийные данные и отправить незашифрованные мультимедийные данные Правоохранительному органу (9), может использовать CLII-информацию и информацию о взаимосвязи, полученную на этапе S34.
Хотя действия по подготовке к Законному перехвату, упомянутые на этапе S31, находятся вне объема этого описания, предложим пример такого рода действия по подготовке к Законному перехвату. Функциональное звено (10) Законного перехвата может на этапе S31 отдать команду или предварительно сконфигурировать Сервер (1) управления ключами таким образом, чтобы он вел себя в соответствии с этапом S33 и S34 для каждого последующего ключа/билета REQUEST_INIT (ИНИЦИИРОВАНИЯ_ЗАПРОСА), сделанного Алисой. Это сделает возможным использование в точности такой же обработки Законного перехвата также и для вызовов/сеансов связи, которые еще не были инициированы в то время, когда запрос на Законный перехват был принят функциональным звеном (10) Законного перехвата.
Отметим, что изобретение работает хорошо независимо от того, является ли Объект Законного перехвата Инициирующей стороной или Отвечающей стороной (Алисой (2) или Бобом (3)) обмена данными. Случай Инициирующей стороны был уже описан подробно. Если Объект Законного перехвата является Отвечающей стороной (Бобом (3)), то необходимо рассмотреть два случая:
Если Алиса (2) и Боб (3) используют один и тот же Сервер управления ключами/одного и того же Оператора подсистемы IMS, то никакого различия нет. Однако, если Боб (3) имеет отдельный сервер управления ключами, возможно, в другой юрисдикции, то сервер управления ключами, обслуживающий Боба, будет, используя информацию, закодированную в билете, созданном сервером управления ключами, обслуживающим Алису (2), в состоянии предоставить Бобу (3) всю информацию, необходимую для выведения совместно используемого ключа (K_KMS_AB), и все другие параметры, необходимые для дальнейшего выведения ключей, например, RAND-значения, выбранные Алисой (2) и так далее. Боб (3) и/или сервер управления ключами, обслуживающий Боба, может дополнительно выбрать такие параметры (например, дополнительные RAND-значения), и они будут также известны Серверу управления ключами, обслуживающему Бобу (3). Таким образом, информация, имеющаяся на Сервере управления ключами, обслуживающем Боба (3) (возможно, полученная частично при связи с Сервером управления ключами, обслуживающим Инициирующую сторону) даст Серверу управления ключами, обслуживающему Боба (3), возможность создать и сохранить полный набор CLII-информации, которая впоследствии (если/когда будет получен ордер на Законный перехват) может быть сделана доступный для Правоохранительного органа местной юрисдикции, как это описано выше.
Как было упомянуто выше, эта процедура немного увеличивает количество информации, сохраняемой как состояние на Сервере (1) управления ключами. Если это проблематично (например, вследствие ограничений памяти на Сервере (1) управления ключами), то сохранять это состояние мог бы отдельный узел/сервер. Сервер (1) управления ключами по-прежнему бы участвовал в обработке билета, как было описано, но хранение осуществлялось бы отдельно. Сервер (1) управления ключами, таким образом, имел бы интерфейс для поддержания связи с этим узлом хранения и отправлял CLII-информацию (извлеченный из билетов и/или сгенерированную локально) в этот узел для хранения. Получив ордер на Законный перехват, функциональное звено (10) Законного перехвата, имеющееся у оператора, могло бы в таком случае, вместо этого, получать CLII-информацию от этого узла хранения.
На фиг. 7 (адаптированной из TR 33.328 (Технического отчета 33.328) проекта 3GPP) показан случай, при котором Алиса (3) имеет Сервер управления ключами (сервер KMS_I (12)), а Боб (3) имеет отдельный Сервер управления ключами (сервер KMS_R (13)). Как было отмечено выше, сервер KMS_R (13) будет посредством обмена информации с сервером KMS_I (12) получать всю информацию, необходимую для того, чтобы дать возможность Бобу (3) вывести тот же самый набор ключей и других криптографических параметров, что и Алисе/серверу KMS_I (12). Следовательно, сервер KMS_R (13) будет в состоянии сохранять копию той же самой (или эквивалентной) CLII-информации, что и информация, хранимая сервером KMS_I (12).
Проблема возникает в том случае, когда Серверы управления ключами являются отдельными, как это показано на фиг. 7, и ордер на Законный перехват выдается в юрисдикции сервера KMS_I (12) (случай Законного перехвата в юрисдикции сервера KMS_R (13) был уже описан).
Отметим, что Боб (3) и/или сервер KMS_R (13) могут выбрать дополнительные параметры, существенные для CLII-информации (например, RAND-значения) в сообщении RESOLVE_INIT (ИНИЦИИРОВАНИЕ_ЗАПРОСА) от Боба (3) (или после этого сообщения). Например, если сервер KMS_R (13) выберет некоторый параметр после того, как связь с сервером (KMS_I 12) завершена, то этот параметр не будет известен серверу KMS_I (12), что могло создать проблему в случае, если ордер на законный перехват выдан в юрисдикции сервера KMS_I (12). Возможные решения этой проблемы включают в себя:
1. Потребовать, чтобы сервер KMS_I (12) направлял любую дополнительную информацию, релевантную для CLII-информации, (выбранную/сгенерированную на "Отвечающей стороне") серверу KMS_R (13) в сочетании с передачей сообщения RESOLVE_INIT (ИНИЦИИРОВАНИЕ_РАЗЛОЖЕНИЯ) серверу KMS_I (12). В частности, требуется, чтобы сервер KMS_R (13) не выбирал никаких дополнительных параметров CLII-информации после этой передачи информации. Таким образом CLII-информация на сервере KMS_I (12) обновляется посредством информации, релевантной для CLII-информации, которая принята от сервера KMS_R (13).
2. Извлекать, на сервере KMS_I (12) или в соединении с этим сервером, любую дополнительную информацию, релевантную для CLII-информации, включенную в конечное сообщение TRANSFER_RESP (ОТВЕТ_О_ПЕРЕДАЧЕ) от Боба (3) Алисе (2). Это сообщение пройдет через домен/юрисдикцию Алисы (2). Сервер KMS_I (12) будет иметь всю информацию, необходимую для того, чтобы дешифровать это сообщение/извлечь из него информацию. В конце концов, Алиса (2) должна быть в состоянии декодировать это сообщение, и сервер KMS_I (12) с этой целью также имеет доступ ко всей релевантной информации/ключам. После этого извлечения, CLII-информация на сервере KMS_I (12) соответствующим образом обновляется.
Отметим, что в любом случае, между этими двумя доменами не передается никакой информации об абонентах, которые являются объектом для Законного перехвата. Информация, обмен которой осуществляется между доменами, передается независимо от того, активирован ли Законный перехват или нет, так что невозможно обнаружить то, что обмен данными перехватывается.
Как упомянуто выше на этапе S34, в случае, при котором объект для Законного перехвата участвует в двух или больше сеансах связи, должна быть установлена взаимосвязь правильной CLII-информация с правильным сеансом связи. Прежде всего IP-адрес объекта Законного перехвата признается известным. Например, объект будет регистрироваться на SIP-серверах, которые обеспечивают достижимость для поступающих вызовов подсистемы IMS, и, таким образом, эти серверы должны в любом случае знать отображение между пользовательскими идентификационными данными и IP-адресами, независимо от того, зашифрованы ли вызовы или нет. Часть изобретения заключается в том, чтобы использовать поле MKI-идентификатора (или эквивалентное поле) в качестве основы для идентификации, ассоциативно связанной с ним CLII-информации. Поскольку MKI-идентификатор переносится в пакетах мультимедийных данных, то это дополнительное знание идентификационных данных Инициирующей стороны/Отвечающей стороны может, в принципе, быть использовано для того, чтобы идентифицировать правильную CLII-информацию. Если MKI-идентификатор присваивается Сервером (1) управления ключами, то Сервер (1) управления ключами может обеспечить то, чтобы MKI-идентификатор (с идентификаторами пользователей) уникальным образом идентифицировал CLII-информацию для каждого мультимедийного сеанса связи. Однако, если за присвоение MKI-идентификатора отвечают пользователи, то могло бы случиться так, что Алиса (1) и/или Боб (2) случайно (или даже преднамеренно) выберут конфликтующий MKI-идентификатор для двух различных сеансов связи, делая таким образом идентификацию CLII-информации неоднозначной. Поскольку маловероятно, что любые два пользователя участвуют в больше чем малом количестве сеансов связи, то сеть и/или Правоохранительный орган могли бы просто попробовать все возможные варианты CLII-информации, и один из них будет правильным. Другая опция заключается в том, чтобы позволить использовать в качестве (части) идентификатора CLII-информации Идентификационные данные Билета (MIKEY-билета, RFC 6043 (Рабочие предложения 6043) определяют такого рода идентификатор). Как обсуждалось выше, этот идентификатор билета (или информация, из которой он может быть выведен) может быть включен в состав поля MKI-идентификатора.
Обратимся к фиг. 8, на которой проиллюстрирован Сервер (8) управления ключами. Сервер управления ключами может включать в себя функциональное звено (14) обработки данных и хранилище (15) CLII-информации, или они могут быть предусмотрены в отдельном узле. Функциональное звено (14) обработки данных используется, как было описано выше, в отношении идентификатора, ассоциативно связанного с CLII-информацией в хранилище (15) CLII-информации. Для ясности отметим, что на чертеже проиллюстрирован единственный приемопередатчик (16), хотя следует понимать, что он может быть физически реализован посредством нескольких передатчиков и приемников. Приемопередатчик (16) устроен таким образом, чтобы принимать запрос от функционального звена (10) Законного перехвата, причем запрос включает в себя идентификационные данные объекта для Законного перехвата. В результате этого, функциональное звено (14) обработки данных использует эти идентификационные данные объекта для того, чтобы определить идентификатор и отыскать CLII-информацию в хранилище (15) CLII-информации. После этого приемопередатчик (16) отправляет CLII-информацию Правоохранительному органу (9) (или функциональному звену (10) Законного перехвата). Правоохранительный орган может в таком случае использовать CLII-информацию для того, чтобы дешифровать отправленный поток (S36b) обмена данными. В качестве альтернативы; дешифрование выполняется в узле плоскости передачи мультимедийных данных или в функциональном звене (10) Законного перехвата так, чтобы отправленный поток (S36b) обмена данными, когда он поступает в Правоохранительный орган, был уже дешифрован.
Сервер управления ключами, в дополнение к хранилищу (20) ключей, также снабжен функциональным звеном (17) криптографической генерации, предназначенным для того, чтобы генерировать криптографические материалы, и функциональным звеном (18) обработки билетов, предназначенным для того, чтобы генерировать билеты и осуществлять разложение билетов. Функциональное звено (17) криптографической генерации, предназначенное для того, чтобы генерировать криптографические материалы, и функциональное звено (18) обработки билетов, предназначенное для того, чтобы генерировать билеты/осуществлять разложение билетов, могут быть реализованы посредством единственного процессора (19) или различных процессоров. Сервер (1) управления ключами может также быть снабжен памятью (21) в форме машиночитаемого носителя информации. Память (21) может использоваться для того, чтобы хранить программу (22), которая при исполнении ее процессором (19) заставляет Сервер управления ключами вести себя так, как было описано выше.
Обратимся к приведенной здесь фиг. 9, на которой проиллюстрирован посылающий узел (2). Вновь, для ясности, проиллюстрирован единственный приемопередатчик (23), но следует понимать, что он может быть реализован как множество передатчиков и приемников. Приемопередатчик (23) устроен таким образом, чтобы отправлять Серверу (1) управления ключами запрос на билет, причем запрос содержит криптографическую информацию, относящуюся к этому посылающему узлу. Приемопередатчик (23), кроме того, устроен таким образом, чтобы принимать от Сервера (1) управления ключами ответ, который включает в себя ключ, билет и информацию, ассоциативно связанную с идентификатором (ID). Приемопередатчик также устроен таким образом, чтобы отправлять приемнику (3) билет и информацию, ассоциативно связанную с идентификатором (ID), для того, чтобы устроить сеанс зашифрованного обмена данными. Предусматривается процессор (24), который устроен таким образом, чтобы включать информацию, ассоциативно связанную с идентификатором (ID), в состав пакетов, отправляемых приемнику (3) в ходе этого зашифрованного обмена данными. Может быть предусмотрена память (25) в форме машиночитаемого носителя информации. Она может быть использована для того, чтобы хранить программу (26), которая при исполнении ее процессором (24) заставляет этот узел вести себя так, как было описано. Память (25) может также быть использована для того, чтобы хранить информацию, относящуюся к идентификатору (ID) (27).
Отметим, что посылающий узел может не знать, что он использует информацию, ассоциативно связанную с идентификатором (ID) в пакетах. Это может иметь место, например, в случае, при котором информацию, подлежащую использованию в поле MKI-идентификатора предоставляет Сервер (1) управления ключами. Однако, может случиться так, что используется протокол, не являющийся SRTP-протоколом, такой как IPSec-протокол. Обычно, ключи по IPsec-протоколу создаются с использованием IKE-протокола, который заботится об ассоциативной связи между "ключом" и "SPI-индексом" ("Индексом параметра защиты"). В случае, при котором описанный выше способ применяется в среде IPsec-протокола, следует IKE-протокол должен быть заменен Kerberos-подобным протоколом (например, так, как описано в IETF RFC 4430 (Рабочих предложениях 4430 Рабочей группы по инженерным проблемам сети Internet), или с использованием Kerberos-протокола непосредственно с IPsec-протоколом). Механизм "заполнения" SA-базы данных по IPSec-протоколу SPI-индексами, которые не были созданы IKE-протоколом, представляет собой новую функцию, которую должны будут выполнять посылающая сторона (и принимающая сторона).
Обратимся к приведенной здесь фиг. 10, на которой проиллюстрирован принимающий узел (3). Для ясности отметим, что проиллюстрирован единственный приемопередатчик (28), но следует понимать, что он может быть реализован как множество передатчиков и приемников. Приемопередатчик (28) устроен таким образом, чтобы принимать запрос на организацию зашифрованного обмена данными с посылающей стороной (2). Запрос включает в себя билет и информацию, ассоциативно связанную с идентификатором (ID). Приемопередатчик (28) устроен таким образом, чтобы отправлять Серверу (1) управления ключами сообщение с запросом, причем сообщение с запросом включает в себя билет, информацию, ассоциативно связанную с идентификатором (ID) и дополнительную криптографическую информацию, относящуюся к принимающей стороне (3). Приемопередатчик (28), кроме того, устроен таким образом, чтобы принимать от функционального звена Сервера (1) управления ключами некоторый второй ключ, подлежащий использованию принимающей стороной (3). Приемопередатчик (28) может также быть устроен таким образом, чтобы для организации сеанса зашифрованного обмена данными отправлять посылающей стороне (2) криптографическую информацию (например, однократно используемые числа), относящуюся к генерации второго ключа. Процессор (29) устроен таким образом, чтобы включать информацию, ассоциативно связанную с этим идентификатором, в состав пакетов, отправляемых в ходе этого зашифрованного обмена данными. Может быть предусмотрена память (30) в форме машиночитаемого носителя информации. Она может быть использована для того, чтобы хранить программу (31), которая при ее исполнении процессором (27) заставляет принимающий узел вести себя так, как было описано. Память (30) может также быть использована для того, чтобы хранить информацию, относящуюся к идентификатору (ID) (27).
Обратимся к приведенной здесь фиг. 11, на которой проиллюстрирован узел (10) Законного перехвата. Для ясности отметим, что проиллюстрирован единственный приемопередатчик (33), но следует понимать, что он может быть реализован как множество передатчиков и приемников. Приемопередатчик (33) принимает пакеты, относящиеся к зашифрованному обмену данными между Алисой (2) и Бобом (3). Пакеты включают в себя информацию, ассоциативно связанную с идентификатором (ID). Приемопередатчик отправляет запрос Серверу (1) управления ключами, причем запрос включает в себя информацию, ассоциативно связанную с идентификатором (ID). Приемопередатчик также устроен таким образом, чтобы принимать, от Сервера (1) управления ключами, CLII-информацию. Приемопередатчик (33) устроен таким образом, чтобы затем отправлять Правоохранительному органу (9) либо CLII-информацию, либо дешифрованную версию этого зашифрованного обмена данными. В качестве альтернативы, приемопередатчик (33) устроен таким образом, чтобы передавать CLII-информацию узлу плоскости передачи мультимедийных данных и отдавать этому узлу плоскости передачи мультимедийных данных команду использовать эту CLII-информацию для того, чтобы дешифровать обмен данными между Алисой (2) и Бобом (3) и направить это Правоохранительному органу (9). Предусматривается процессор (34) для обработки сигналов. Может быть предусмотрена память (35) в форме машиночитаемого носителя информации. Она может быть использована для того, чтобы хранить программу (36), которая при ее исполнении процессором (34) заставляет узел (10) Законного перехвата вести себя так, как было описано.
Узел (10) Законного перехвата может отправлять CLII-информацию непосредственно Правоохранительному органу (9) для того, чтобы Правоохранительный орган выполнил дешифрование. В качестве альтернативы, узел (10) Законного перехвата может, используя CLII-информацию, выполнять дешифрование сам и отправлять дешифрованный обмен данными Правоохранительному органу (9). В альтернативном варианте реализации изобретения, узел (10) Законного перехвата может отправлять CLII-информацию узлу плоскости передачи мультимедийных данных, который выполняет дешифрование зашифрованного обмена данными и отправляет дешифрованный обмен данными Правоохранительному органу (9).
В варианте реализации изобретения, в котором идентификатор (ID) зависит от информации билета, информация билета может быть защищена ключом, известным только Серверу (1) управления ключами. Это предотвращает манипуляции с идентификатором (ID) со стороны Алисы (2) и/или Боба (3) в служебных сообщениях с билетом. Если эта защита отсутствует, то все-таки имеются еще мероприятия, которые могут быть предприняты для того, чтобы сделать это решение более надежным. Например, когда Сервер (1) управления ключами принимает запросы на разложение, поступающие от Боба (3), он мог бы проверять то, что идентификатор (ID) является действительным (то есть что он "существует"), и что он ассоциативно связан с теми же самыми сторонами: Алисой (2) и Бобом (3). Алиса (2) и Боб (3) могли бы вставить в SRTP-пакеты неправильные значения MKI-идентификатора. Это означает, что Сервер (1) управления ключами, возможно, будет не в состоянии отыскать правильный ключ. Сервер (1) управления ключами мог бы в таком случае, в качестве опции, возвращать все варианты CLII-информации, связанные с объектом, и узел (10) Законного перехвата (или Правоохранительный орган (9)) мог бы попробовать все эти ключи.
Изобретение обеспечивает законный перехват посреди "разговора"/посреди сеанса связи с минимальными непроизводительными затратами ширины полосы пропускания, без ухудшения защищенности и прозрачности для клиентов.
Специалист в данной области техники должен понимать, что в вышеописанные варианты реализации изобретения могут быть внесены различные изменения без выхода за рамки объема настоящего изобретения.
В вышеприведенном описании были использованы нижеследующие аббревиатуры:
3GPP Проект партнерства третьего поколения
CLII Криптографическая информация для Законного перехвата
HSS Сервер домашних абонентов,
HTTP Протокол для передачи гипертекстов
IMS Мультимедийная подсистема протокола межсетевого взаимодействия
IPsec Защищенный протокол межсетевого взаимодействия
LEA Правоохранительный орган
LI Законный перехват
MKI Идентификатор главного ключа
MSRP Протоколе трансляции сеанса передачи сообщений
NAI Идентификатор доступа к сети
RTP Протокол транспортного уровня в реальном масштабе времени
SIP Протокола инициирования сеанса связи
SPI Индекс параметра защиты
ROC Счетчик перебора
SRTP Защищенный протокол транспортного уровня в реальном масштабе времени
TLS Протокол защиты транспортного уровня
PSK-TLS Протокол защиты транспортного уровня с предварительно выданным ключом (ключами)
UDP Протокол дейтаграмм пользователя.
Изобретение относится к области предоставления правоохранительному органу доступа к зашифрованному обмену данными между посылающим узлом и принимающим узлом. Технический результат – обеспечение возможности быстро найти всю криптографическую информацию, относящуюся к зашифрованному обмену данными, и направить ее в правоохранительный орган. Способ предоставления правоохранительному органу доступа к зашифрованному обмену данными между посылающим узлом и принимающим узлом, содержащий этапы, на которых в функциональном звене сервера управления ключами: сохраняют (S16, S20) в базе данных криптографическую информацию, используемую для шифрования обмена данными, причем криптографическая информация связана с идентификатором, используемым для идентификации зашифрованного обмена данными между посылающим узлом и принимающим узлом, причем криптографическая информация содержит криптографическую информацию, выведенную как в посылающем узле, так и в принимающем узле; принимают (S32) запрос, исходящий от правоохранительного органа, на законный перехват, причем запрос включает в себя идентификационные данные объекта для законного перехвата; используют (S33) идентификационные данные объекта для определения указанного идентификатора и извлекают из базы данных криптографическую информацию, связанную с идентификатором, причем криптографическая информация выполнена с возможностью использования для дешифрования указанного зашифрованного обмена данными; и отправляют (S34) правоохранительному органу информацию, выведенную из криптографической информации, или дешифрованный обмен данными. 5 н. и 5 з.п. ф-лы, 11 ил.
1. Способ предоставления правоохранительному органу доступа к зашифрованному обмену данными между посылающим узлом (2) и принимающим узлом (3), содержащий этапы, на которых в функциональном звене (1) сервера управления ключами:
сохраняют (S16, S20) в базе данных криптографическую информацию, используемую для шифрования обмена данными, причем криптографическая информация связана с идентификатором, используемым для идентификации зашифрованного обмена данными между посылающим узлом (2) и принимающим узлом (3), причем криптографическая информация содержит криптографическую информацию, выведенную как в посылающем узле, так и в принимающем узле;
принимают (S32) запрос, исходящий от правоохранительного органа (9), на законный перехват, причем запрос включает в себя идентификационные данные объекта для законного перехвата;
используют (S33) идентификационные данные объекта для определения указанного идентификатора и извлекают из базы данных криптографическую информацию, связанную с идентификатором, причем криптографическая информация выполнена с возможностью использования для дешифрования указанного зашифрованного обмена данными; и
отправляют (S34) правоохранительному органу информацию, выведенную из криптографической информации, или дешифрованный обмен данными.
2. Способ по п. 1, дополнительно содержащий этапы, на которых в функциональном звене (1) сервера управления ключами:
принимают (S15) от посылающего узла (2) запрос на билет, причем запрос содержит криптографическую информацию, относящуюся к посылающему узлу (2);
генерируют (S16) первый ключ, подлежащий использованию посылающим узлом, билет, и сохраняют первый ключ и криптографическую информацию посылающего узла, связанную с идентификатором, в базе данных;
отправляют (S17) первый ключ и билет и информацию, относящуюся к идентификатору, посылающему узлу (2);
принимают (S19) от принимающего узла (3) запрос, причем сообщение с запросом включает в себя указанный билет, информацию, относящуюся к идентификатору, и дополнительную криптографическую информацию, относящуюся к принимающему узлу;
генерируют (S20) второй ключ, подлежащий использованию принимающим узлом, и криптографическую информацию принимающего узла, связанную с указанным идентификатором в базе данных;
отправляют (S21) второй ключ принимающему узлу (3).
3. Способ по п. 1 или 2, в котором функциональное звено сервера управления ключами обеспечено в более чем одном сервере управления ключами, при этом этап генерирования второго ключа содержит обмен информацией между по меньшей мере двумя из указанных более чем одного серверов управления ключами.
4. Способ по п. 1 или 2, в котором идентификатор выводят с использованием по меньшей мере какого-либо параметра из числа: временной метки, неявного знания текущего времени, порядкового номера, связанного с сеансом связи, идентификатора билета, идентификатора ключа и идентификатора сеанса связи.
5. Способ по п. 1 или 2, в котором идентификатор выводят с использованием идентификационных данных по меньшей мере одного узла из посылающего узла и принимающего узла.
6. Способ обеспечения законного перехвата зашифрованного обмена данными между посылающим узлом и принимающим узлом, содержащий этапы, на которых в узле законного перехвата:
принимают пакеты, относящиеся к указанному зашифрованному обмену данными, причем пакеты включают в себя информацию, связанную с идентификатором, причем идентификатор связан с криптографической информацией, используемой для шифрования указанного обмена данными и хранящейся на сервере управления ключами, причем криптографическая информация содержит криптографическую информацию, выведенную как в посылающем узле, так и в принимающем узле;
отправляют запрос на сервер управления ключами, причем запрос включает в себя указанную информацию, связанную с идентификатором;
принимают криптографическую информацию, связанную с идентификатором, и/или дешифрованную версию указанного зашифрованного обмена данными; и
отправляют криптографическую информацию, связанную с идентификатором, и/или дешифрованную версию зашифрованного обмена данными правоохранительному органу.
7. Сервер управления ключами (KMS - сервер) (1) для использования в сети связи, содержащий:
функциональное звено (14) обработки данных для сохранения в базе (15) данных криптографической информации, используемой для шифрования обмена данными между посылающим узлом (2) и принимающий узлом (3), причем криптографическая информация связана с идентификатором и содержит криптографическую информацию, выведенную как в посылающем узле, так и в принимающем узле;
приемник (16) для приема запроса, исходящего от правоохранительного органа, на законный перехват, причем запрос включает в себя идентификационные данные объекта для законного перехвата;
при этом функциональное звено (14) обработки данных выполнено с возможностью использовать идентификационные данные объекта для определения идентификатора и извлечения из базы данных криптографической информации, связанной с указанным идентификатором, причем криптографическая информация выполнена с возможностью использования для дешифрования указанного зашифрованного обмена данными; и
передатчик (16) для отправки криптографической информации правоохранительному органу.
8. Сервер (1) управления ключами по п. 7, в котором приемник выполнен с возможностью принимать от посылающего узла запрос на билет, причем запрос содержит криптографическую информацию, относящуюся к посылающему узлу, при этом сервер управления ключами дополнительно содержит:
функциональное звено (17) генерации для генерирования первого ключа, подлежащего использованию посылающим узлом, причем ключ и криптографическая информация посылающего узла связаны с указанным идентификатором в базе данных;
при этом передатчик (16) дополнительно выполнен с возможностью отправлять ключ, билет и информацию, относящуюся к идентификатору, посылающему узлу;
приемник дополнительно выполнен с возможностью принимать от принимающего узла запрос, причем сообщение с запросом включает в себя билет, информацию, относящуюся к идентификатору, и дополнительную криптографическую информацию, относящуюся к принимающему узлу;
функциональное звено (17) генерации дополнительно выполнено с возможностью генерировать второй ключ, подлежащий использованию принимающим узлом, причем второй ключ и криптографическая информация принимающего узла связаны с указанным идентификатором в базе данных;
передатчик дополнительно выполнен с возможностью отправлять второй ключ принимающему узлу.
9. Узел (10) законного перехвата для использования в сети связи, содержащий:
приемник (31) для приема пакетов, относящихся к зашифрованному обмену данными между посылающим узлом и принимающим узлом, причем пакеты включают в себя информацию, связанную с идентификатором, причем идентификатор связан с криптографической информацией, используемой для шифрования указанного обмена данными, причем криптографическая информация содержит криптографическую информацию, выведенную как в посылающем узле, так и в принимающем узле;
передатчик для отправки запроса серверу управления ключами на предоставление информации шифрования для зашифрованного обмена данными, причем запрос включает в себя информацию, связанную с указанным идентификатором;
при этом приемник дополнительно выполнен с возможностью приема криптографической информации, связанной с указанным идентификатором, и/или дешифрованной версии указанного зашифрованного обмена данными; а
передатчик дополнительно выполнен с возможностью отправки криптографической информации, связанной с указанным идентификатором, и/или дешифрованной версии указанного зашифрованного обмена данными правоохранительному органу.
10. Машиночитаемый носитель информации, хранящий компьютерную программу, содержащую машиночитаемое кодовое средство, которое, когда запущено на компьютерном устройстве, вызывает выполнение компьютерным устройством способа по любому из пп. 1-6.
| Приспособление для суммирования отрезков прямых линий | 1923 |
|
SU2010A1 |
| Переносная печь для варки пищи и отопления в окопах, походных помещениях и т.п. | 1921 |
|
SU3A1 |
| Пресс для выдавливания из деревянных дисков заготовок для ниточных катушек | 1923 |
|
SU2007A1 |
