[go: up one dir, main page]

WO2011131070A1 - Système d'interception licite permettant une sécurité de médias ims basé sur un serveur de gestion de clés - Google Patents

Système d'interception licite permettant une sécurité de médias ims basé sur un serveur de gestion de clés Download PDF

Info

Publication number
WO2011131070A1
WO2011131070A1 PCT/CN2011/072020 CN2011072020W WO2011131070A1 WO 2011131070 A1 WO2011131070 A1 WO 2011131070A1 CN 2011072020 W CN2011072020 W CN 2011072020W WO 2011131070 A1 WO2011131070 A1 WO 2011131070A1
Authority
WO
WIPO (PCT)
Prior art keywords
kms
signaling
network element
ims network
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2011/072020
Other languages
English (en)
Chinese (zh)
Inventor
田甜
朱允文
韦银星
高峰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Publication of WO2011131070A1 publication Critical patent/WO2011131070A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/30—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information
    • H04L63/306—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information intercepting packet switched data communications, e.g. Web, Internet or IMS communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2281—Call monitoring, e.g. for law enforcement purposes; Call tracing; Detection or prevention of malicious calls

Definitions

  • 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).
  • IMS IP Multimedia Subsystem
  • KMS Key Management Servicer
  • 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.
  • 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.
  • 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.
  • this KMS-based secure communication technology solution requires the addition of a new network element, that is, the addition of a KMS.
  • 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.
  • P-CSCF Proxy-Call Session Control Function
  • S-CSCF Service-Call Session Control Function
  • the implementation process of the KMS-based secure communication technology solution includes the following steps: Step 1.
  • User A ie, UE A
  • KMS establish a secure channel by using a universal authentication mechanism (GBA) mechanism.
  • 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.
  • KMS can implement key management and distribution functions.
  • KMS can also use the Network Application Function (NAF).
  • NAF Network Application Function
  • 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.
  • 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 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.
  • TBS Ericsson's Ticket-based System
  • the Ticket entity does not have a specific protocol to carry. It can be transmitted in signaling.
  • SDP Session Description Protocol
  • the MIKEY-Ticket mechanism contains three interactions, as shown in Figure 2, namely: Ticket Requets; Ticket Transfer and Ticket Resolve.
  • user I indicates the originating session user
  • user R indicates the answering session user
  • KMS indicates the key management server.
  • 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.
  • 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.
  • MAC message authentication code
  • 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.
  • the KMS 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.
  • the Ticket Request step can be omitted.
  • step 14 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.
  • 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.
  • 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.
  • KMS 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.
  • RESOLVE_RESP 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.
  • TRANSFER_RESP message 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 TPK is the key for protecting the ticket.
  • the key is only known to the KMS.
  • the random number RAND is generated by the KMS.
  • 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.
  • 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.
  • the sender 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.
  • 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.
  • Ka the verification key
  • the random numbers RAND and TGK generate a forked TEK
  • the SALT in the TEK and KEMAC is used as the key input of the SRTP protocol.
  • KMS-based end-to-end media security solutions must also meet legitimate interception needs.
  • Figure 9 The legal monitoring solution that is currently open as a standard IMS control surface is shown in Figure 9, which includes:
  • LMF Listening Center
  • DF2 Transfer Unit
  • ADMF Management Entity
  • Intercepted Subscriber Other Party
  • P-CSCF Transfer Unit
  • S-CSCF S-CSCF
  • LEMF through P-CSCF And S-CSCF to Intercepted Subscriber Monitor.
  • 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.
  • 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.
  • a lawful interception system for IMS media security based on a key management server KMS 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.
  • 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.
  • 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.
  • 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.
  • a lawful interception system for IMS media security based on a key management server 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.
  • 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.
  • 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.
  • 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.
  • Figure 1 is a system architecture diagram of an existing MIKEY-Ticket
  • FIG. 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
  • FIG. 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
  • FIG. 10 is a system architecture diagram of a KMS-PUSH scheme of the system of the present invention.
  • FIG. 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;
  • FIG. 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
  • FIG. 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
  • FIG. 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.
  • 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.
  • the KMS-PUSH system architecture the system is based on the KMS-based PUSH mode. System;
  • the KMS-PULL system architecture the system is a KMS-based PULL mode system.
  • 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:
  • ADMF is used as an entity for sending a listening instruction to a network element
  • 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'.
  • DF2 and DF2 are the specific implementations of the signaling interception unit.
  • Delivery Function 2 can be called the transmission unit.
  • DF2 also called the transmission unit, represents the transmission unit that is functionally different from DF2.
  • 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).
  • LEMF Law Enforcement Monitoring Facility
  • 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.
  • 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.
  • DF2 and DF2 send the interception data to LEMF for information association.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the signaling intercepting unit includes DF2 and DF2, and DF2 and DF2 are independently set.
  • DF2 is used as a signaling intercepting unit of the IMS network element
  • DF2 is used as a signaling intercepting unit of the KMS.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the interception data can also be referred to as the session message of the target user.
  • KMS connected to DF2
  • DF2 is configured to parse according to the content of the listening command, and return the parsing result to DF2.
  • 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.
  • the content that DF2 sends to the KMS for the listening command includes the following two specific implementations:
  • DF2 is used to send the ticket intercepted to the message to the KMS when the local policy for trusted messages is used.
  • KMS is used to parse directly according to the ticket, and returns the parsing result for the ticket to DF2.
  • 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.
  • 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.
  • 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 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.
  • 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 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.
  • 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 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.
  • 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
  • P-CSCF proxy call session control unit
  • S-CSCF service call session control unit
  • Request Init refers to ticket request
  • Request Res refers to ticket request result
  • Transfer Resp refers to the ticket transfer request response
  • Resolve Init refers to the ticket resolution request
  • Resolve Resp refers to the ticket resolution result information

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Technology Law (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention fournit un système d'interception licite permettant une sécurité de médias de sous-système multimédia IP (IMS) basé sur le serveur de gestion de clés (KMS), qui inclut deux schémas de réalisation de système de PUSH et de PULL. Dans lequel, le système de mode PULL comprend : une unité d'interception de signalisation, destinée à obtenir les données d'interception à partir de l'élément de réseau IMS, et à les envoyer au KMS ; le KMS est connecté à l'unité d'interception de signalisation, pour résoudre les données d'interception et retourner le résultat de la résolution à l'unité d'interception de signalisation. Grâce à l'invention, l'interception licite permettant une sécurité de médias IMS basée sur KMS peut être mise en œuvre.
PCT/CN2011/072020 2010-04-19 2011-03-21 Système d'interception licite permettant une sécurité de médias ims basé sur un serveur de gestion de clés Ceased WO2011131070A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010150834.2A CN102223356B (zh) 2010-04-19 2010-04-19 基于密钥管理服务器的ims媒体安全的合法监听系统
CN201010150834.2 2010-04-19

Publications (1)

Publication Number Publication Date
WO2011131070A1 true WO2011131070A1 (fr) 2011-10-27

Family

ID=44779787

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/072020 Ceased WO2011131070A1 (fr) 2010-04-19 2011-03-21 Système d'interception licite permettant une sécurité de médias ims basé sur un serveur de gestion de clés

Country Status (2)

Country Link
CN (1) CN102223356B (fr)
WO (1) WO2011131070A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013104072A1 (fr) * 2012-01-12 2013-07-18 Research In Motion Limited Système et procédé d'accès légal à des communications sécurisées
US9083509B2 (en) 2012-01-12 2015-07-14 Blackberry Limited System and method of lawful access to secure communications
US9413530B2 (en) 2012-01-12 2016-08-09 Blackberry Limited System and method of lawful access to secure communications

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103546442B (zh) * 2012-07-17 2018-10-23 中兴通讯股份有限公司 浏览器的通讯监听方法及装置
CN105075182B (zh) * 2013-02-07 2019-01-04 诺基亚技术有限公司 用于通过提供安全性信息来允许合法拦截的方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1642115A (zh) * 2004-01-16 2005-07-20 华为技术有限公司 一种实现ip多媒体业务监听的系统及方法
CN1960292A (zh) * 2005-10-31 2007-05-09 华为技术有限公司 一种监听方法和监听数据收集设备及系统
CN101013691A (zh) * 2007-02-01 2007-08-08 刘华友 绝缘栅双极晶体管模块

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101106449B (zh) * 2006-07-13 2010-05-12 华为技术有限公司 实现多方通信安全的系统和方法
CN101043691B (zh) * 2007-04-28 2012-01-11 中兴通讯股份有限公司 用于ims网络的合法监听方法
US20090180614A1 (en) * 2008-01-10 2009-07-16 General Instrument Corporation Content protection of internet protocol (ip)-based television and video content delivered over an ip multimedia subsystem (ims)-based network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1642115A (zh) * 2004-01-16 2005-07-20 华为技术有限公司 一种实现ip多媒体业务监听的系统及方法
CN1960292A (zh) * 2005-10-31 2007-05-09 华为技术有限公司 一种监听方法和监听数据收集设备及系统
CN101013691A (zh) * 2007-02-01 2007-08-08 刘华友 绝缘栅双极晶体管模块

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013104072A1 (fr) * 2012-01-12 2013-07-18 Research In Motion Limited Système et procédé d'accès légal à des communications sécurisées
US9083509B2 (en) 2012-01-12 2015-07-14 Blackberry Limited System and method of lawful access to secure communications
US9264227B2 (en) 2012-01-12 2016-02-16 Blackberry Limited System and method of lawful access to secure communications
US9413530B2 (en) 2012-01-12 2016-08-09 Blackberry Limited System and method of lawful access to secure communications
US9871827B2 (en) 2012-01-12 2018-01-16 Blackberry Limited System and method of lawful access to secure communications

Also Published As

Publication number Publication date
CN102223356B (zh) 2015-06-03
CN102223356A (zh) 2011-10-19

Similar Documents

Publication Publication Date Title
US11943262B2 (en) Securing method for lawful interception
US9537837B2 (en) Method for ensuring media stream security in IP multimedia sub-system
KR101013427B1 (ko) 보이스-오버-ｉｐ시스템들에 대한 미디어 스트림 암호화키들의 종단 간 보호
CN104094574B (zh) 对加密通信的合法监听
US20110154022A1 (en) Method and Apparatus for Machine-to-Machine Communication
CN103119976B (zh) 通信网络中经由中间单元发送受保护数据
CN101379802B (zh) 在媒体服务器和用户设备之间以加密方式传输媒体数据的方法和装置
KR20100107033A (ko) 암호화된 트래픽의 합법적 인터셉트를 가능하게 하는 방법 및 장치
WO2011041962A1 (fr) Procédé et système de négociation de clé de session de bout en bout prenant en charge les interceptions légales
WO2011131055A1 (fr) Procédé, système et appareil pour mettre en œuvre un transfert d'appel sécurisé
CN111756726A (zh) 一种支持国密算法的sip安全认证方法
WO2011131070A1 (fr) Système d'interception licite permettant une sécurité de médias ims basé sur un serveur de gestion de clés
WO2017197968A1 (fr) Procédé et dispositif de transmission de données
CN102025485B (zh) 密钥协商的方法、密钥管理服务器及终端
US20030154408A1 (en) Method and apparatus for secured unified public communication network based on IP and common channel signaling
CN118590250A (zh) 一种通信方法、终端、设备及介质
CN100583733C (zh) 实现媒体流安全的方法及通信系统
CN118075021A (zh) 一种加密通信建立方法及系统和加密通信方法及系统
CN117499919A (zh) 5g网络安全增强防护系统
Blom et al. Key management and protection for IP multimedia
Kultti Secure text in sip based voip
Traynor et al. Vulnerabilities in Voice over IP
HK1224097B (en) Securing method for lawful interception

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11771523

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11771523

Country of ref document: EP

Kind code of ref document: A1