WO2011131070A1

WO2011131070A1 - Lawful interception system for ims media security based on key management server

Info

Publication number: WO2011131070A1
Application number: PCT/CN2011/072020
Authority: WO
Inventors: 田甜; 朱允文; 韦银星; 高峰
Original assignee: 中兴通讯股份有限公司
Priority date: 2010-04-19
Filing date: 2011-03-21
Publication date: 2011-10-27
Also published as: CN102223356B; CN102223356A

Abstract

The invention provides a lawful interception system for IP Multimedia Subsystem (IMS) media security based on the Key Management Server (KMS), which includes two system implementation schemes of PUSH and PULL. Wherein, the system of PULL mode includes: a signaling interception unit, for obtaining the interception data from the IMS network element, and sending it to the KMS; KMS is connected with the signaling interception unit, for resolving the interception data and returning the resolution result to the signaling interception unit. By using the invention, the lawful interception for IMS media security based on KMS can be implemented.

Description

Legal listening system for IMS media security based on key management server

The present invention relates to network communication security technologies, and in particular, to a lawful interception system for IP Multimedia Subsystem (IMS) media security based on Key Management Servicer (KMS). Background technique

The KMS-based secure communication technology solution is an end-to-end technical solution for protecting media streams, which is proposed for more demanding security requirements independent of signaling and transmission networks.

The KMS-based secure communication technology solution is implemented based on the concept of using KMS and a ticket, wherein KMS is responsible for providing functions such as security, user authentication, and key generation. In IMS media plane security, KMS acts as a third-party server, mainly for issuing tickets and parsing tickets. KMS can also be called a key management system.

The KMS-based secure communication technology solution is mainly for users with higher security requirements, and the KMS-based secure communication technology solution can be completely independent of the security of the signaling plane, that is, even if the data of the signaling plane is Stealing, the attacker can not obtain the media key of both parties of the call, thereby providing users with higher security. However, this KMS-based secure communication technology solution requires the addition of a new network element, that is, the addition of a KMS.

Considering the participation of user equipment (UE) and each network element in the IMS, the KMS-based secure communication technology solution can be referred to the system architecture shown in FIG. Among them, the Proxy-Call Session Control Function (P-CSCF) and the Service-Call Session Control Function (S-CSCF) belong to the IMS network element.

The implementation process of the KMS-based secure communication technology solution includes the following steps: Step 1. User A (ie, UE A) and KMS establish a secure channel by using a universal authentication mechanism (GBA) mechanism. Here, GBA is a mobile communication network and a lightweight security infrastructure defined by 3GPP, which can provide unified security authentication services for application layer services. As a trusted third party, KMS can implement key management and distribution functions. KMS can also use the Network Application Function (NAF).

Step 2. User A applies to the KMS for a media key for communicating with User B (ie UE B) and an encrypted Ticket (including media key and User B information).

Step 3. The KMS generates a media key and an encrypted ticket is sent to the user A.

Step 4. User A sends a communication request and an encrypted ticket to the user through the IMS core network.

B.

Step 5. User B receives the communication request sent by User A and the encrypted ticket.

Step 6. User B and KMS establish a secure channel with the GBA mechanism.

Step 7. User B sends the received encrypted ticket to the KMS, requesting the media key in the ticket.

Step 8: The KMS decrypts the ticket sent by the user B, and verifies whether the information of the called user in the user B and the ticket are consistent. If they are consistent, the media key in the ticket is sent to the user B.

Step 9. After obtaining the media key, user B accepts the communication request of user A, so that user A and user B can communicate with the media key.

The solution for the secure communication technology described above is implemented using the MIKEY-Ticket key agreement mechanism.

The MIKEY-Ticket key agreement mechanism is a new mode used to extend the MIKEY (RFC3830) protocol. This new mode uses the concepts of KMS and Ticket. The MIKEY-Ticket extension to the MIKEY protocol comes from Ericsson's Ticket-based System (TBS) scheme, which uses the concept of Ticket. In practice, the Ticket entity does not have a specific protocol to carry. It can be transmitted in signaling. In the key agreement protocol extension of Session Description Protocol (SDP) of RFC4568, SDP can support the transmission of MIKEY, let MIKEY Support for Tickets, the problem is solved.

The MIKEY-Ticket mechanism contains three interactions, as shown in Figure 2, namely: Ticket Requets; Ticket Transfer and Ticket Resolve.

In Figure 2, user I indicates the originating session user, user R indicates the answering session user, and KMS indicates the key management server. The following three interactive processes are respectively described in detail. Among them, the interactive parameters can be divided into three types of representations, that is, [ ] indicates that the parameter is optional, () indicates that one or more of the parameters can be included, and { } indicates no. Contains or contains more than zero such parameters.

First, for the Ticket Request, first, the session initiator, that is, the user I sends a REQUEST_INIT message to the KMS for requesting a ticket to the KMS, the REQUESTJNIT message contains the session information (for example, the identity of the callee), and this The REQUEST_INIT message is protected by a message authentication code (MAC) based on the shared key of User I and KMS.

Ticket Request is divided into two modes: 1. Shared key; 2. Public and private key mechanism. Since the public and private key mechanisms require PKI support and are not used, only the shared key mode is introduced here. The parameters included in the REQUESTJNIT message are shown in Figure 3, including: HDR, T, RAND, [IDi], [IDkms], (IDre), {SP}, IDtp, [KEMAC], [IDpsk], V , where: HDR indicates a message header, T indicates a timestamp, and RAND indicates a random number;

The IDi contains the identity of the sender. This identifier is generally present in the "send to" field in the ticket. Since the sender's identity can be read from the sender field of the message, this parameter can sometimes be omitted in the REQUESTJNIT message.

IDkms should be included in the message, but can be saved if the KMS has only one unique identifier; IDre is the identifier of the recipient and can be a single user or a group of users. If more than one recipient is present, each recipient's identity must be placed in a separate ID payload;

IDt is the identifier of the ticket policy that you want to use; SP is the security policy payload;

KEMAC is the key data transmission payload, which is simply used to store the key for transmitting each key. Fang, here KEMAC = E(encr_key, [MPK] II {TGKITEK}), where MPK (MIKEY Protection Key) is the MIKEY message protection key, ie encrypt the MPK, TGK or TEK with encr_key, TGK can have more than one, encr_key Generated by PSK, this parameter is optional;

IDpsk is not a required parameter. Only when there is more than one PSK, you need to specify which PSK to use. V is the verification payload and stores the corresponding MAC value.

If the initiator is authenticated and legally initiates the request, the KMS generates the required keys, and encodes the keys in the ticket, and returns a ticket to the initiator user I in the REQUEST_RESP message. See the specific parameters in the message. As shown in Figure 4 below, it includes: HDR, T, [IDkms], [IDtp], [TICKET], [KEMAC], V, where the parameters of [ ] are optional, and the Ticket contains the ticket type and the ticket data. The ticket type and data are both dependent on IDtp.

The above ticket request interaction process is optional. When the user has the ability to generate a ticket without interacting with the KMS, the Ticket Request step can be omitted.

2. For Ticket Transfer, after receiving the REQUEST_RESP message sent by KMS, User I sends the Ticket to the called party R in the TRANSFER_INIT message, as shown in step 13 in Figure 2. If the user R check policy is acceptable, it forwards the ticket to the KMS in the RESOLVEJNIT message, and causes the KMS to return the key information contained in the ticket, as shown in step 14 in Figure 2, where the RESOLVE_INIT message is also based on the user. MAC protection for shared keys of R and KMS. Based on the type of ticket, step 14 is also optional and is only used when user R leaves the assistance of KMS or the information contained in the ticket. The specific parameters in the TRANSFER_INIT and RESOLVE_INIT messages are shown in Figures 5 and 6, respectively:

The IDi and IDr parameters in the TRANSFER_INIT message may not be included in the message when there are other ways to obtain the identity of the sender and the receiver. In the final verification payload, the verification key auth_key is generated by the MPK. Since the sender and the receiver do not have a shared key at this time, the receiver cannot verify the message that the ticket receives from the receiver before processing, so the receiver First, you need to check the policy you accept. If the IDtp in the received message is not acceptable by yourself, the message is rejected and no longer interacts with the KMS. This is also a way to prevent DoS attacks on KMS in advance.

3. For Ticket Resolve, in the RESOLVE_INIT message, the Ticket payload carries the ticket that needs to be decrypted by KMS. The IDt and IDi payloads must match the corresponding parameters in TRANSFER_INIT. V is the verification payload, and the verification key auth_key is generated by PSK.

After receiving the RESOLVE_INIT message, KMS verifies that user R is a legal recipient. If so, KMS retrieves the key and other information in the ticket and sends a RESOLVE_RESP message to user R. If KMS cannot correctly parse the received message. Or if the user R who sent RESOLVEJNIT fails the verification, the KMS should return the corresponding error message. The KMS sends the relevant key along with other additional information to the user R in the RESOLVE_RESP message, see step 15 in Figure 2.

The specific parameters in the RESOLVE_RESP message are shown in Figure 7: In addition to the message type, the next payload and the V-tag, the other header payloads must be consistent with the headers in the RESOLVE_INIT message. The timestamp type and value must be consistent with the RESOLVE_INIT message. KEMAC = E(encr_key, MPK II [MPK] II {TGK I TEK} ). In the case of Forking, KMS requires two forked MPKs and multiple TGKs. In this case, the first MPK is used to protect the TRANSFER_INIT message, and the second MPK is used to protect the TRANSFER_RESP message. The modification factor used to generate the different forked keys is included in the IDmod payload.

After receiving the RESOLVE_RESP message, user R sends a TRANSFER_RESP message to user I as an acknowledgment. See step 16 in Figure 2. The TRANSFER_RESP message may contain some information for key generation. The specific parameters are shown in Figure 8. The actual signaling process needs to depend on the specific ticket type and the policy of the KMS domain. The type of the ticket is determined by the ticket's policy.

The following describes the derivation method of each key of MIKEY-Ticket: For the layers of the keys used in the MIKEY-Ticket in the non-Forking scenario and the relationship between them, the TPK is the key for protecting the ticket. Generally, the key is only known to the KMS. The random number RAND is generated by the KMS. Based on the random numbers RAND and TPK, the KMS generates the corresponding MPK, TGK and SALT using the key generation function KDF, and Ke is the encryption key of the key material in the encrypted ticket generated according to the Pre-shared key. , use Ke encryption MPK, TGK and SALT to put in the KEMAC payload. The key Ka for verification is regenerated by the pre-shared key, and the MAC value is calculated to be placed in the MAC payload.

When the sender sends the TRANSFER_INIT message to the receiver, it uses the RAND generated by itself and the MPK obtained from the KMS to generate the verification key Ka based on the KDF, which is used to calculate the MAC value. According to the information in the HDR, the random number RAND and the TGK are used. The KDF generates a TEK, and the SALT contained in the KEMAC is used as a key input for the SRTP protocol.

For the generation of keys in MIKEY-Ticket in Forking scenario, the only difference between Forking and non-Forking is that KMS will generate a correction factor MOD for each terminal to generate new MPK and TGK. The forked MPK is generated based on MOD and MPK, and the parameters in the forked MPK and HDR and the random number RAND generate a verification key Ka, which is used to calculate the MAC. Based on the parameters in MOD, HDR, the random numbers RAND and TGK generate a forked TEK, and the SALT in the TEK and KEMAC is used as the key input of the SRTP protocol.

Because national laws and regulations require law enforcement to have the ability to properly listen to any call, KMS-based end-to-end media security solutions must also meet legitimate interception needs.

The legal monitoring solution that is currently open as a standard IMS control surface is shown in Figure 9, which includes:

Listening Center (LEMF), Transfer Unit (DF2), Management Entity (ADMF), Intercepted Subscriber, Other Party, P-CSCF, S-CSCF; LEMF through P-CSCF And S-CSCF to Intercepted Subscriber Monitor.

Since the scheme does not include the KMS network element and only intercepts data from the IMS core network element, it does not have the ability to monitor the KMS-based media security mechanism, thereby failing to implement lawful interception of the KMS-based IMS media security. Summary of the invention

In view of this, the main object of the present invention is to provide a lawful interception system based on KMS for IMS media security, which can implement lawful interception of KMS-based IMS media security.

In order to achieve the above object, the technical solution of the present invention is achieved as follows:

A lawful interception system for IMS media security based on a key management server KMS, the system comprising: an administrative entity (ADMF), an IP Multimedia Subsystem (IMS) network element and a Listening Center (LEMF); the system further comprising: KMS and Signaling interception unit:

The ADMF is configured to send a listening command to the KMS;

The KMS is connected to the ADMF, and is configured to send the interception data to the signaling intercepting unit after receiving the intercepting command from the ADMF;

The signaling intercepting unit is connected to the KMS, and configured to send the intercepting data to the LEMF;

The LEMF associates the interception data obtained from the signaling intercepting unit with the intercepted data obtained from the IMS network element; and performs monitoring according to the associated intercepted data.

The signaling intercepting unit is separately set or combined with the signaling intercepting unit DF2 in the IMS network element.

Wherein, when the signaling intercepting unit is combined with the signaling intercepting unit DF2 in the IMS network element,

a set of interception units for intercepting the intercepted data intercepted by the IMS network element and the KMS, and then sending the data to the LEMF; or, the IMS network element and the IMS network element The interception data intercepted by the KMS is directly sent to the LEMF, and the LEMF is Line information association.

The information used by the information association includes one or any combination of the following: a timestamp, a user address of the calling party, and a user address of the recipient.

Wherein, when the signaling intercepting unit is separately set,

The signaling intercepting unit DF2 of the IMS network element is configured to send the interception data intercepted by the IMS network element to the LEMF;

The signaling intercepting unit is configured to send interception data intercepted from the KMS to the LEMF;

The LEMF performs information association based on data received from DF2 and the signaling intercepting unit.

A lawful interception system for IMS media security based on a key management server, the system comprising: ADMF, IMS network element and LEMF; wherein the system further comprises: a KMS and a signaling interception unit,

The signaling intercepting unit is configured to obtain monitoring data from the IMS network element, and send the monitoring data to the KMS;

The KMS is connected to the signaling intercepting unit, configured to parse the interception data, and return the parsing result to the signaling intercepting unit.

In the case that the signaling intercepting unit is the signaling intercepting unit DF2 in the IMS network element, the DF2 is configured to include the MIKEY-Ticket in the intercepting data when the intercepting data is sent to the KMS. information.

The DF2 sends the MIKEY-Ticket information included in the interception data to the KMS;

The KMS is further configured to parse according to the MIKEY-Ticket information, and parse the The result is returned to the DF2.

In the case that the signaling intercepting unit is the signaling intercepting unit DF2 in the IMS network element, the DF2, according to the local policy, identifies that after obtaining the untrusted message from the IMS network element, the IMS network will be obtained from the IMS network. The information obtained by the element and the signaling plane is sent to the KMS, and the information obtained from the IMS network element includes: at least one of a KMS-ID used by the monitored user and a timestamp of the event; The information includes: at least one of a caller's user identifier and a recipient's user identifier;

The KMS is further configured to find the corresponding MIKEY-Ticket information according to the information obtained from the IMS network element and the signaling plane provided by the DF2, parse the information, and send the parsing result to the DF2.

In order to realize the lawful interception of the KMS-based IMS media security after the introduction of the newly added network element of the KMS, the present invention includes two system implementation schemes, namely: the introduction of the corresponding network element after the introduction of the KMS (PUSH) ) Scheme and pull (PULL) scheme. The PUSH solution includes: a new KMS and a signaling intercepting unit; the newly added KMS is connected to the ADMF, and is configured to receive a listening command from the ADMF, and actively send the monitoring data to the signaling intercepting unit; An intercepting unit is configured to intercept the intercepting data from the KMS and the IMS network element.

The invention can realize the lawful interception of the KMS-based IMS media security, and provides an effective and effective monitoring solution corresponding to the KMS-based secure communication technology solution. DRAWINGS

Figure 1 is a system architecture diagram of an existing MIKEY-Ticket;

2 is a schematic diagram of three key negotiation interaction processes defined in the existing MIKEY-Ticket; FIG. 3 is a schematic diagram of an existing REQUEST_INIT message;

Figure 4 is a schematic diagram of an existing REQUEST_RESP message;

Figure 5 is a schematic diagram of an existing TRANSFER_INIT message;

6 is a schematic diagram of an existing RESOLVE_INIT message; 7 is a schematic diagram of an existing RESOLVE_RESP message;

Figure 8 is a schematic diagram of an existing TRANSFER_RESP message;

Figure 9 is a structural diagram of an IMS lawful interception system of a conventional standardized control plane;

10 is a system architecture diagram of a KMS-PUSH scheme of the system of the present invention;

11 is a schematic diagram of an interface between a KMS and other listening network elements in a KMS-PUSH architecture to which the system of the present invention is applied;

12 is a schematic diagram of a monitoring process when a called party is controlled by a KMS-PUSH architecture using the system of the present invention;

13 is a schematic diagram of a monitoring process when a calling party is controlled by a KMS-PUSH architecture using the system of the present invention;

14 is a system architecture diagram of a KMS-PULL scheme of the system of the present invention;

FIG. 15 is a schematic diagram of a message flow when a monitoring object is a called party under the KMS-PULL architecture of the system of the present invention;

16 is a schematic diagram of a message flow when a monitoring object is a calling party in a KMS-PULL architecture to which the system of the present invention is applied. detailed description

The basic idea of the present invention is: To implement the lawful interception of the KMS-based IMS media security after the introduction of the newly added network element of the KMS, including two system implementation schemes, namely: introducing the newly added network element of the KMS Corresponding PUSH scheme and PULL scheme.

The implementation of the technical solution will be further described in detail below with reference to the accompanying drawings.

A KMS-based IMS media security lawful interception system, in order to implement the legal monitoring of KMS-based IMS media security after the introduction of the newly added network element of KMS, includes two system implementation schemes, namely: introducing KMS The PUSH scheme and the PULL scheme corresponding to the newly added NEs may also be referred to as a KMS-PUSH system architecture scheme and a KMS-PULL system architecture scheme. When using the KMS-PUSH system architecture, the system is based on the KMS-based PUSH mode. System; When using the KMS-PULL system architecture, the system is a KMS-based PULL mode system.

It should be pointed out here that the present invention is an effective monitoring solution provided under the KMS-based secure communication technology solution. Since the KMS-based secure communication technology solution does not depend on the security of the signaling plane, the monitoring of the present invention The solution also does not depend on the security of the signaling plane. The present invention mainly includes the following contents:

For the KMS-PUSH scheme, as shown in FIG. 10 and FIG. 11, the system architecture of the KMS-PUSH scheme is shown in FIG. 10: ADMF is used as an entity for sending a listening instruction to a network element, and an IMS network element is used. The monitoring command is issued separately from the KMS, and the IMS network element and the KMS independently send monitoring data to DF2 and DF2'.

Here, DF2 and DF2 are the specific implementations of the signaling interception unit. The full name of DF2 is called Delivery Function 2, which can be called the transmission unit. DF2, also called the transmission unit, represents the transmission unit that is functionally different from DF2. For the transmitting unit, the transmitting unit is used to intercept the signaling plane data in the lawful interception, and converts the intercepted information into a standard format and sends it to the Listening Center (LEMF, Law Enforcement Monitoring Facility). In practical applications, the processing of the signaling intercepting unit includes two modes: one way, DF2 and DF2 can be used as different network entities, that is, two functional units are separately configured in the signaling intercepting unit, That is, DF2 and DF2, to achieve different functions, respectively, so that the functional division can improve the overall operating speed and efficiency of the system; Another way: DF2 and DF2 can be integrated into the same network entity, that is, in Only one functional unit is configured in the signaling interception unit. The functional unit integrates all functions of DF2 and DF2, and does not perform functional division. For example, the specific implementation of the signaling interception unit may be only DF2, but the meaning of the DF2 refers to an upgrade. The DF2, which includes both the functions of the existing DF2 and the functions of the DF2, is distinguished from the DF2 in the prior art.

Here, DF2 and DF2 send the interception data to LEMF for information association. If DF2 and DF2 are the same network entity, DF2 can send the number of listeners sent by IMS network element and KMS. It is first sent to LEMF, or directly to LEMF, and is associated with LEMF. As shown in Figure 11, KMS and ADMF have an Xl_l interface for receiving listener commands from ADMF; KMS and DF2 have X2 interfaces for transmitting a ticket resolution request (Resolve Init) related to the listener object to DF2, and the ticket parsing result (Resolve Resp), Request Init, Request Resp, time of event occurrence, etc. DF2 and DF2, the association of messages can be related by information that cannot be tampered with by the signaling plane, such as time stamp of the time, the user address of the calling party and the recipient, and so on.

For the KMS-PULL scheme, as shown in Figure 14, the system architecture of the KMS PULL scheme is adopted. DF2 intercepts the session message of the target user from the IMS network element. If the session information includes the MIKEY-Ticket message, the DF2 is based on the local policy. For example, for different trusted and untrusted policies, the content of the interception command is sent to the KMS. If the DF2 intercepts the message from the signaling plane, the DF2 can directly send the intercepted ticket to the KMS to obtain the analysis result of the ticket. If the information intercepted by the DF2 from the signaling plane is not trusted, the DF2 obtains the KMS-ID used by the monitored user from the IMS network element, obtains the timestamp of the event from the IMS network element, and obtains the timestamp from the signaling plane. Information that is not easily falsified, such as the user identifier of both parties to the call, is sent to the designated KMS. KMS provides information based on DF2, finds the relevant ticket, and sends the ticket resolution to DF2. DF2 can send the result of the analysis of the ticket to LEMF, and the association between the ticket information and the call information is performed by LEMF. It is also possible to implement the association processing of the ticket information and the call information by itself, and send the processed information to the LEMF. When DF2 sends a listen command to KMS, it decides the data to be sent to KMS according to the local policy.

The invention is illustrated by way of example below.

System Embodiment 1: In the embodiment of the KMS-PUSH architecture of the system of the present invention, the signaling intercepting unit includes DF2 and DF2, and DF2 and DF2 are independently set. In this embodiment, DF2 is used as a signaling intercepting unit of the IMS network element, and DF2 is used as a signaling intercepting unit of the KMS.

As shown in FIG. 10, the system includes: ADMF, P-CSCF, S-CSCF, KMS, DF2. DF2, and LEMF; wherein, both the P-CSCF and the S-CSCF belong to the IMS network element.

ADMF, used to issue a listen command to KMS.

KMS, connected to ADMF, is also connected to DF2, and is used to send monitoring data to DF2' after receiving a listening command from ADMF.

The P-CSCF and the S-CSCF are used to receive the listening command from the ADMF and actively send the monitoring data to the DF2.

DF2, used to send the interception data intercepted from the P-CSCF and the S-CSCF to the LEMF, and the LEMF performs information association.

DF2' is used to send the interception data intercepted from the KMS to the LEMF, and the LEMF performs the information association.

LEMF is used to associate the intercepted data obtained from DF2 and DF2 with the intercepted data obtained from the IMS network element; and listen according to the associated intercepted data.

It should be noted here that the DF2 and DF2 included in the signaling intercepting unit in the embodiment of the system are separately set. That is to say, at this time, DF2 and DF2 are different network entities, respectively.

Here, in the KMS-PUSH architecture, the DF2 and DF2 included in the signaling interception unit can be integrated into an upgraded network entity, and the signaling interception unit is an upgraded network entity. The only difference from the first embodiment of the above system is that an upgraded network entity formed by integrating DF2 and DF2 is used as a signaling intercepting unit. That is to say, at this time, DF2 and DF2 are the same network entity.

When DF2 and DF2 are the same network entity, the interface diagram shown in Figure 11 can be seen: KMS and ADMF have Xl_l interface for receiving listening commands from ADMF; KMS and DF2 have X2 interfaces for DF2 The Resolve Init, Resolve Resp, Request Init, Request Resp, and the time when the event occurred are transmitted.

System Embodiment 2: Embodiment of the KMS-PULL architecture of the system of the present invention, and the signaling intercepting unit is a signaling intercepting unit of the IMS network element, and the signaling intercepting unit of the IMS network element still uses DF2 said. As shown in FIG. 14, the system includes: ADMF, P-CSCF, S-CSCF, KMS, DF2, and LEMF; wherein, both the P-CSCF and the S-CSCF belong to the IMS network element.

DF2, configured to intercept, from the P-CSCF and the S-CSCF, a session message of the target user of the interception data, and send the content for the interception command to the KMS according to the interception data using different local policies. It should be noted here that the interception data can also be referred to as the session message of the target user.

KMS, connected to DF2, is configured to parse according to the content of the listening command, and return the parsing result to DF2. It should be pointed out here that the listening command involved here has different meanings from the listening command involved in the first embodiment of the system, that is: both of them belong to the listening command, but the specific content and format may be different, the above system implementation The interception command involved in the first example is between ADMF and KMS; the listener command involved here is between DF2 and KMS, and the interfaces and parameters of the two may be different, and will not be described again.

For different local policies, the content that DF2 sends to the KMS for the listening command includes the following two specific implementations:

One: DF2 is used to send the ticket intercepted to the message to the KMS when the local policy for trusted messages is used.

Correspondingly, KMS is used to parse directly according to the ticket, and returns the parsing result for the ticket to DF2.

Two: DF2 is used to transmit the information acquired from the P-CSCF and the S-CSCF and the signaling plane to the KMS when the local policy for the untrusted message is used; wherein, the information obtained from the P-CSCF and the S-CSCF The information includes: at least one of a KMS-ID used by the monitored user, and a timestamp of the event; the information acquired from the signaling plane includes: at least one of a caller's user identifier and a recipient's user identifier. .

Correspondingly, the KMS is used to find the relevant ticket according to the information obtained from the P-CSCF and the S-CSCF and the signaling plane provided by the DF2, and send the result of the ticket analysis to the DF2.

The following describes the signaling interaction process under the system architecture of the present invention. Application Example 1: When applying the KMS-PUSH architecture of the system of the present invention, as shown in FIG. 12, the message flow when the receiver (User B) is the monitoring object includes the following steps:

Step 101: User A sends a Ticket Request message to KMS_A.

Step 102: After receiving the request of the user A, the KMS_A sends the key and the ticket to the user A through the Request Res message.

Step 103: User A sends a Transfer Init message to the IMS network.

Step 104: The IMS network forwards the received Transfer Init message to the DF2.

Step 105: The IMS network forwards the Transfer Init message to User B.

Step 106: User B sends a ticket resolution request Resolve Init to KMS_B.

Step 107: KMS_B forwards the ticket resolution request Resolve Init to DF2,.

Step 108: KMS_B sends a ticket resolution request Resolve Init to KMS_A.

Step 109: KMS_A sends the ticket resolution result Resolve Res to KMS_B. Step 110: KMS_B sends the ticket resolution result Resolve Res to DF2, .

Step Ill: KMS_B sends the ticket resolution result Resolve Res is sent to user B. Step 112: User B will send a Transfer Res message to the IMS network.

Step 113: The IMS network forwards the Transfer Res message to the DF2.

Step 114: The IMS network sends a Transfer Res message to User A.

Application Example 2: When applying the KMS-PUSH architecture of the system of the present invention, as shown in FIG. 13, the message flow when the initiator (user A) is the monitoring object includes the following steps: Step 201: User A to KMS_A Send a ticket request message.

Step 202: KMS_A forwards the Ticket Request message to DF2.

Step 203: After receiving the request of the user A, the KMS_A sends the key and the ticket to the user A through the Request Res message.

Step 204: KMS_A forwards the Request Res message to DF2'.

Step 205: User A sends a Transfer Init message to the IMS network. Step 206: The IMS network forwards the received Transfer Init message to the DF2.

Step 207: The IMS network forwards the Transfer Init message to User B.

Step 208: User B sends a ticket resolution request Resolve Init to KMS-B.

Step 209: KMS_B sends a ticket resolution request Resolve Init to KMS_A.

Step 210: KMS_A forwards Resolve Init to DF2'.

Step 211: KMS_A sends the ticket resolution result Resolve Res to KMS_B.

Step 212: KMS_A sends the ticket resolution result Resolve Res to DF2,.

Step 213: KMS_B sends the ticket resolution result Resolve Resp to user B.

Step 214: User B will send a Transfer Res message to the IMS network.

Step 215: The IMS network forwards the Transfer Res message to the DF2.

Step 216: The IMS network sends a Transfer Res message to User A.

Application example. Three: When applying the KMS-PULL architecture of the system of the present invention, as shown in the figure

15 shows that when the signaling plane is not trusted, and the user B is the listening process when listening to the object, the following steps are included.

Step 301: User A sends a Ticket Request message to KMS_A.

Step 302: After receiving the request of user A, KMS_A passes the key and the ticket through the Request.

The Res message is sent to user A.

Step 303: User A sends a Transfer Init message to the IMS network.

Step 304: The IMS network forwards the received Transfer Init message to the DF2, and the KMS-ID (and KMS_B) of the user B, the timestamp of the event, and the like.

Step 305: The DF2 sends the timestamp of the event and the information that is not easily falsified on the signaling plane, such as the identity above the call, from the Transfer Init message to KMS_B.

Step 306: The IMS network forwards the Transfer Init message to User B.

Step 307: User B sends a ticket resolution request Resolve Init to KMS_B.

Step 308: KMS_B sends a ticket resolution request Resolve Init to KMS_A. Step 309: KMS_A sends a ticket resolution result Resolve Resp to KMS_B.

Step 310: KMS_B sends the ticket resolution result Resolve Resp to DF2.

Step 311: KMS_B sends the ticket resolution result Resolve Resp to user B.

Step 312: User B will send a Transfer Resp message to the IMS network.

Step 313: The IMS network forwards the Transfer Res message to the DF2.

Step 314: The IMS network sends a Transfer Res message to User A.

Application Example 4: When the KMS-PULL architecture of the system of the present invention is applied, as shown in FIG. 16, when the signaling plane is not trusted, and the calling party (User A) is the listening process, the following steps are included. :

Step 401: User A sends a Ticket Request message to KMS_A.

Step 402: After receiving the request of the user A, the KMS_A sends the key and the ticket to the user A through the Request Res message.

Step 403: User A sends a Transfer Init message to the IMS network.

Step 404: The IMS network forwards the received Transfer Init message to the DF2, and the KMS-ID (and KMS_A) of the user A, the timestamp of the event, and the like.

Step 405: The DF2 sends the timestamp of the event and the information that is not easily falsified on the signaling plane, such as the identity above the call, from the Transfer Init message to the KMS_A.

Step 406: The IMS network forwards the Transfer Init message to User B.

Step 407: User B sends a ticket resolution request Resolve Init to KMS_B.

Step 408: KMS_B sends a ticket resolution request Resolve Init to KMS_A.

Step 409: KMS_A sends the ticket resolution result Resolve Resp to DF2.

Step 410: KMS_A sends the ticket resolution result Resolve Resp to KMS_B. Step 411: KMS_B sends the ticket resolution result Resolve Resp to user B.

Step 412: User B will send a Transfer Res message to the IMS network.

Step 413: The IMS network forwards the Transfer Res message to the DF2. Step 414: The IMS network sends a Transfer Res message to User A.

Here, the above text includes the Chinese and English characters in the figure: BSF refers to the service function; Media Key refers to the media key; KMS refers to the key management server; NAF refers to the application server;

Key-info refers to; P-CSCF refers to proxy call session control unit; S-CSCF refers to service call session control unit; Request Init refers to ticket request; Request Res refers to ticket request result; Transfer

Init refers to the ticket transfer request; Transfer Resp refers to the ticket transfer request response; Resolve Init refers to the ticket resolution request; and Resolve Resp refers to the ticket resolution result information.

The above is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention.

Claims

Claim

A lawful interception system for IMS media security based on a key management server KMS, the system comprising: a management entity (ADMF), an IP Multimedia Subsystem (IMS) network element, and a Listening Center (LEMF); The system further includes: a KMS and a signaling intercepting unit; wherein the ADMF is configured to send a listening command to the KMS;

2. The system according to claim 1, wherein the signaling intercepting unit is separately provided or combined with the signaling intercepting unit DF2 in the IMS network element.

The system according to claim 2, wherein, when the signaling intercepting unit is combined with the signaling intercepting unit DF2 in the IMS network element,

a set of interception units for intercepting the intercepted data intercepted by the IMS network element and the KMS, and then sending the data to the LEMF; or, the IMS network element and the IMS network element The interception data intercepted by the KMS is directly sent to the LEMF, and the LEMF performs information association.

4. The system according to claim 3, wherein the information used by the information association comprises one or any combination of the following: a timestamp, a user address of the calling party, and a user address of the recipient.

5. The system according to claim 2, wherein, in the case where the signaling intercepting unit is separately set,

a signaling intercepting unit DF2 of the IMS network element, configured to intercept the IMS network element Listening data is sent to the LEMF;

The system according to claim 5, wherein the information used by the information association comprises one or any combination of the following: a timestamp, a caller's user address, and a recipient's user address.

7. A lawful interception system for IMS media security based on a key management server, the system comprising: an ADMF, an IMS network element, and a LEMF; wherein the system further comprises: a KMS and a signaling intercepting unit;

The system according to claim 7, wherein the signaling intercepting unit is a signaling intercepting unit DF2 in the IMS network element,

The DF2, when the intercept data is sent to the KMS, includes MIKEY-Ticket information in the intercept data.

The system according to claim 8, wherein the DF2 sends the MIKEY-Ticket information included in the interception data to the KMS;

The KMS is further configured to parse according to the MIKEY-Ticket information, and return the parsing result to the DF2.

The system according to claim 7, wherein, in the case that the signaling intercepting unit is the signaling intercepting unit DF2 in the IMS network element, The DF2, according to the local policy, identifies that the information obtained from the IMS network element and the signaling plane is sent to the KMS after obtaining the untrusted message from the IMS network element, and the information obtained from the IMS network element includes: At least one of a KMS-ID used by the monitored user, and a timestamp of the event; the information obtained from the signaling plane includes: at least one of a caller's user identifier and a recipient's user identifier;