Законный перехват зашифрованных обменов данными

Законный перехват зашифрованных обменов данными

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Изобретение относится к области законного перехвата зашифрованных обменов данными.

Уровень техники

Законный перехват (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 проиллюстрирован формат пакета дан