Patent Application
20050243799
1. Field of the Invention
The present invention relates in general to protecting traffic within Signaling System No. 7 (SS7) networks and more particularly to a SS7 network component (e.g., Signaling Transfer Point (STP)) and a method for protecting Signaling Connection Control Part (SCCP) messages from being spoofed and/or eavesdropped.
2. Description of Related Art
The Third Generation Partnership Project (3GPP) has standardized a number of protocols with the aim of providing globally applicable third generation mobile systems based upon the evolution of second generation Global System for Mobile Communication (GSM) technology.
As a result, the 3G network operators/service providers continue to use SS7 networks to exchange signalling information between signalling nodes of the various core networks of their mobile systems and to exchange signalling information with signalling nodes of third party networks such as Public Switched Telephone Networks (PSTNs).
A particular concern of 3GPP has been the securing of network traffic, given that the old model of a few trusted service providers freely exchanging signaling traffic with each other no longer applies. This is because a large number of new and sometimes unreliable service providers are expected to enter into the business of supplying telecommunication services to businesses and consumers. As such, a given service provider will no longer be able to rely on the assumption that other service providers will not try to “attack” their network either deliberately or inadvertently. For instance, an unreliable service provider can simply pay a modest fee to gain access to SS7 networks and then can spoof traffic and eavesdrop on messages in the SS7 networks.
To help address this concern, the 3GPP has standardized a protocol called “MAP application layer security” (MAPsec) which is described in the standard entitled “3GPP TS 33.200 v5.1.0 (2002-12) (release 5)”. Unfortunately, the MAPsec protocol protects only part of the MAP operations and leaves other protocols untouched, and unsafe. Moreover, the implementation of the MAPsec protocol is expensive and complicated. Accordingly, there is a need for new method that can protect messages like SCCP messages that are transmitted within SS7 networks. This need and other needs are satisfied by the method and the SS7 network component (e.g., STP) of the present invention.
The present invention includes a SS7 network component (e.g., STP) and a method which function to add a security parameter and if desired encrypt the data in a traditional SCCP message to create a secure SCCP message that can be safely transmitted through one or more transport SS7 networks to a destination SS7 network. The destination SS7 network has a SS7 network component (e.g., STP) that can function to transform the secure SCCP message back into the traditional SCCP message.
A more complete understanding of the present invention may be obtained by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein:
Referring to
The SS7 network components 108 and 118 each can have a protocol stack as shown in TABLE 1:
*SCCP protocol can also be carried over MTP3b or M3UA protocols.
In mobile networks, the most important protocol that the SCCP carries is TCAP over which MAP (for example) can be transported. Several different types of SCCP messages 110 and their associated parameter fields are listed below in TABLE 2.
a)Information in these parameter fields are ignored if the protocol class parameter indicates class 2.
b)The segmentation parameter must be included by the originating node, if MTP/MTP-3b interworking is expected.
*Reference is made to the International Telecommunication Union standard ITU-T Q.712 (07/96) entitled “Definition and Function of Signalling Connection Control Part Messages” for a more detailed description about the SCCP messages and the parameter fields shown in TABLE 2. The contents of ITU-T Q.712 are incorporated by reference herein.
The SCCP messages 110 listed in TABLE 2 are defined in more detail as follows:
In accordance with the preferred embodiment of the SSCPsec method 200, the SCCP messages 110 that are protected are the connectionless messages that carry user data such as the UDT message 110, the XUDT message 110 and the LUDT message 110. As can be seen in TABLE 2, the only difference between the LUDT message 110 and the XUDT message 110 is that in the XUDT message 110 there is the ‘normal’ (mandatory) user data field, and no long data field. And, in the LUDT message 110 there. is the (mandatory) long data field, but no user data field. As can also be seen in TABLE 2, the different parameter fields in the LUDT message 110 and the XUDT message 110 are:
The SCCPsec method 200 protects the XUDT and LUDT messages 110 by including a “security” parameter 114 (with a number of parameter fields (e.g., integrity checksum) in the optional parameters field and by possibly encrypting the actual user data 116. In particular, the SS7 network component 108 (e.g., STP 108) implements SCCPsec method 200 to add the security parameter 114 and if desired encrypt the user data 116 of the XUDT and LUDT messages 110 so as to create the secure XUDT and LUDT messages 112. It should be noted that the secure XUDT and LUDT messages 112 are likely going to be segmented at the SCCP level due to the increase in the total message length because of the information associated with the security parameter 114.
The SCCPsec method 200 can also protect the UDT message 110 in a similar manner but needs to first convert the traditional UDT message 110 into a traditional LUDT or XUDT message 110. To accomplish this, the parameters of the UDT message 110 can be directly copied into equivalent parameters of the XUDT or LUDT message 110. The particular type of message that the UDT message 110 is converted into would depend on the capabilities of the lower layer narrowband or broadband signaling links. It should be noted that the security measures provided by the SCCPsec method 200 cannot be directly applied to UDT messages 110 mainly for two reasons: (1) there are no optional parameters in the message type to include the security information and adding new ones is very unlikely in the standardization; and (2) the UDT message 110 type provides no segmentation service.
The “security” parameter 114 in the secure XUDT and LUDT messages 112 (including the converted UDT messages 112) could contain the following parameter fields:
It should be appreciated that the integrity protection provided by the integrity checksum in SCCPsec method 200 ensures that the secured SCCP message 112 received at the destination SS7 network 106 was not altered and did originate at the originating SS7 network 102. This helps prevent unreliable service providers from “spoofing” the secure SCCP message 112. And, the encryption protection provided by the SCCPsec method 200 ensures that only the destination SS7 network 106 which has the encryption key can read the user data if it was encrypted. This helps prevent unreliable service providers from “eavesdropping” on the secure SCCP message 112.
In accordance with another embodiment of the SCCPsec method 200, the SCCP messages 110 that are SCCP management messages 110 can also be protected. The protection of SCCP management messages 110 would help prevent malicious attacks against the management interfaces. The different types of SCCP management messages 110 that could be protected and their associated parameter fields are listed below in TABLE 3.
a)The affected SSN is equal to one if the message pertains to the SCCP itself or to the SCCP node.
b)Reserved for national use.
*Reference is made to the International Telecommunication Union standard ITU-T Q.712 (07/96) entitled “Definition and Function of Signalling Connection Control Part Messages” for a more detailed description about the SCCP management messages and the parameter fields shown in TABLE 3.
The SCCP management messages 110 listed in TABLE 3 are defined in more detail as follows:
The SCCPsec method 200 can protect a SCCP management message 110 by encapsulating it in full into the data field of the secure XUDT or LUDT message 112. In particular, the SCCPsec method 200 can generate a new secured XUDT or LUDT message 112 from the SCCP management message 110 by putting the full SCCP management message 110 in the user data/long data parameter and creating a new header and security parameter 114. The SCCPsec method 200 could also if desired encrypt the user data 116 in these secured XUDT and LUDT messages 112. The SS7 network component 118 (e.g., STP 118) at the destination SS7 network 106 could then transform/decapsulate the secured XUDT or LUDT message 112 back into the SCCP management message 110. It should also be appreciated that the SCCPsec method 200 can be used to protect key management messages in a similar fashion as the SCCP management messages 110.
In accordance with yet another embodiment of the SCCPsec method 200, a policy decision point can be added to method 200 before step 202 to determine whether a destination PLMN has also implemented the SCCPsec method 200. Because, a secure SCCP message 112 should only be sent to a PLMN that has implemented the SCCPsec method 200.
From the foregoing, it can be readily appreciated by those skilled in the art that the present invention provides a SCCPsec method 200 that adds integrity protection and encryption protection to the SCCP protocol which ensures operators that the higher layer applications related to SCCP traffic which they receive truly originated unchanged from where it claimed to originate and that the SCCP traffic has not been eavesdropped. The SCCPsec method 200 requires no changes to the existing transport SS7 networks 104. However, the SCCPsec method 200 does require minor modifications to the SS7 network components 108 and 118 (e.g., SCCP relay points/gateways, STPs) at the network boundaries of the originating and destination SS7 networks 102 and 106.
It should be noted that many components and details associated with the SS7 networks 102, 104 and 106 and STPS 108 and 118 described herein and shown in
Following are some additional features, advantages and uses of the SCCPsec method 200 of the present invention:
Although several embodiments of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.
