WO2005079035A1

WO2005079035A1 - Security within ss7 networks

Info

Publication number: WO2005079035A1
Application number: PCT/EP2004/050116
Authority: WO
Inventors: Juha SÄÄSKILAHTI; Reijo Pekkala
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2004-02-11
Filing date: 2004-02-11
Publication date: 2005-08-25

Abstract

A method of establishing a Security Association for securing traffic sent over an SS7 signalling network between signalling nodes, such that the parameters of the Security Association are known to each signalling node involved. The method comprises using the Internet Key Exchange protocol to negotiate said parameters between signalling nodes, Internet Key Exchange messages being sent over the SS7 network.

Description

Security within SS7 Networks

Field of the Invention

The present invention relates to security within SS7 networks and more particularly to apparatus and methods for establishing shared security keys and policies between SS7 signalling nodes.

Background to the Invention

The Third Generation Partnership Project (3GPP) has standardised a number of protocols with the aim of providing globally applicable third generation mobile systems based upon the evolution of second generation GSM technology. A particular concern of 3GPP has been the securing of network traffic, given that the old model of a few trusted operators freely exchanging signalling traffic with each other no longer applies. In the future, a large number of new and sometimes unreliable operators are expected to enter into the business of supplying telecommunication services to businesses and consumers, and a given operator will no longer be able to rely on the assumption that other operators will not try to "attack" his network either deliberately or inadvertently.

3G network operators will continue to use Signalling System Number 7 (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 PSTN networks. SS7 will, in particular, continue to be used to carry Mobile Application Part (MAP) signalling between peer nodes in a mobile cellular network. The MAP protocol might be used for example to transfer location information for particular mobile subscribers from a Visitor Location Register (VLR) to a Home Location Register (HLR). 3GPP has standardised the MAP Security Protocol (MAPsec) [TS33.200 (for R5/R4)] in order to secure certain MAP signalling over SS7.

MAPsec secures traffic according to Security Associations shared between participating end nodes. A Security Association comprises secret encryption keys and security policies. In order to achieve the distribution of information between MAPsec nodes necessary to establish the shared Security Associations, 3GPP has outlined in the MAPsec technical standard a proposal for a so-called Key Administration Centre (KAC), although this has yet to be formalised. The resulting network architecture is illustrated schematically in Figure 1. The current proposal is for each KAC node to communicate with a peer KAC node using the Internet Key Exchange (IKE) procedure to establish a shared security policy and to allocate keys for services that require these keys. IKE requires the presence of an IP network connecting peer KAC nodes, and this is indicated in Figure 1 by the Zd interface. In addition, communication between the KAC nodes and the MAP nodes occurs over an IP network indicated by the Ze interface in Figure 1. The SS7 interfaces are identified in Figure 1 as the Zf interfaces.

It is understood that, as well as MAPsec, other similar security protocols making use of IKE may be standardised and implemented for securing traffic over the SS7 network. For example, one might consider implementing CAPsec, TCAPsec, and SCCPsec protocols for securing CAP, TCAP, and SCCP messages.

Summary of the Invention

Telecommunication networks demand both high speed and high reliability in the setting up and control of user sessions. IP interfaces offering these qualities are not yet in place within telecommunication networks. At best, only low quality IP interfaces are present offering only best efforts transmission. It is likely to be some time before F networks of sufficient quality are in place, and network operators must therefore look for alternative solutions if the implementation of MAPsec and other security services for SS7 is not to be seriously delayed.

According to a first aspect of the present invention there is provided a method of establishing a Security Association for securing traffic sent over an SS7 signalling network between signalling nodes, such that the parameters of the Security Association are known to each signalling node involved, the method comprising using the Internet Key Exchange protocol to negotiate said parameters between signalling nodes, Internet Key Exchange messages being sent over the SS7 network. Embodiments of the present invention obviate the need for reliable IP networks interconnecting nodes of SS7 signalling networks. These embodiments allow IKE based security protocols such as MAPsec to be implemented by operators in the absence of such IP networks.

Preferably, the IKE protocol is implemented within Key Administration Centre (KAC) nodes of operator networks. KAC nodes have been outlined by 3GPP for use in key and policy distribution among MAPsec nodes. A given KAC communicates with a peer KAC of a "remote" network using IKE to exchange valid keys, and then distributes those keys to the MAPsec nodes within the same network. More preferably, each KAC node is implemented as an SS7 node having its own unique Global Title.

Preferably, within each KAC a new Transmission Capabilities Application Part (TCAP) user is created, this user implementing an extended IKE protocol. The new user is allocated a new Subsystem Number (SSN). For outgoing IKE traffic, the extended IKE will convert the Global Title of the destination (SS7) node into a virtual IP address for inclusion in the header of the IKE messages. The Global Title of the sending KAC is also converted into a virtual IP address for inclusion as the source address in the IKE messages.

Global Titles may be BCD-coded (Binary Coded Decimal) in order to generate Pv6 addresses. Where IPv4 addresses are used, Global Titles may be hashed to generate respective IP addresses. The extended IKE has access to a translation table mapping Global Titles to hash values.

According to a second aspect of the present invention there is provided a node for negotiating parameters relating to a Security Association to be used for securing traffic sent over an SS7 signalling network between signalling nodes, the node comprising: means for implementing the Internet Key Exchange protocol; and means for translating SS7 Global Titles into IP addresses for inclusion in outgoing IKE messages; and interface means for coupling the node to an SS7 signalling network. The node may conform substantially to the Key Administration Centre (KAC) node outlined by 3GPP, with appropriate modifications.

According to a third aspect of the present invention there is provided a method of operating a Key Administration Centre located within a communications network for the purpose of determining Security Association parameters, the method comprising using the Internet Key Exchange protocol to negotiate said parameters with one or more other Key Administration Centres, Internet Key Exchange messages being sent and received by the Key Administration Centre over an SS7 network.

Brief Description of the Drawings

Figure 1 illustrates a known SS7 based signalling architecture in which KAC nodes communicate with each other and with MAP nodes via IP networks;

Figure 2 illustrates an SS7 based signalling architecture in which KAC nodes communicate with each other and with MAP nodes via the SS7 signalling links;

Figure 3 illustrates schematically the protocol stack implemented at each KAC node of the architecture of Figure 2; and Figure 4 illustrates schematically functional elements of an extended IKE protocol,

SS7KE, implemented at each KAC node of the architecture of Figure 2; and

Figure 5 illustrates schematically a pair of MAP nodes within an SS7 network.

Detailed Description of Certain Embodiments

A known architecture for establishing a Security Association to protect SS7 signalling traffic, and in particular MAP traffic, has been described with reference to Figure 1. This architecture employs the use of KAC nodes to negotiate security parameters including keys, between networks over an IP network. Once agreed upon, the parameters are passed by a KAC node to MAP nodes of the same network, again over an IP network. Within each MAP node, the parameters are used in implementing the MAPsec protocol. Figure 2 illustrates a modified architecture in which the KAC nodes are implemented as SS7 signalling points and have an interface to the SS7 signalling network. Figure 3 illustrates schematically the protocol stack implemented within each KAC node. The three lower entities of the stack are the standard Message Transfer Part (MTP layers 1, 2, and 3), Signalling Connection and Control Part (SCCP), and Transaction Capabilities Application Part (TCAP). A new application protocol layer referred to here as SS7 Key Exchange (SS7KE) is introduced and is an extended version of the existing Internet Key Exchange (IKE) protocol. This requires relatively little change to the existing large IKE software "block".

IKE has been defined by the Internet Engineering Task Force (IETF) as a means of negotiating security parameters between nodes over an IP network. The result of the negotiation is a key (or keys) which represents a secret shared between the participating nodes, and other shared security parameters, which together represent a so-called "Security Association" (SA). It is inherent to IKE that nodes be identified with unique IP addresses. IKE writes SA data to a Security Association Database (SAD) with each entry having a source and destination IP address. However, given that the KAC node proposed here is attached to the SS7 network and is allocated a unique (SS7) Global Title, the modification made to IKE is the provision of a means for translating Global Titles into IP addresses. The translation is such that it ensures that each IP address is unique within the SS7 network, thereby avoiding address collision problems.

The longest Global Titles in SS7 are 17 digits, while an IPv6 address has 128 bytes. In the case of IKE for IPv6, the Global Titles may be BCD-coded (Binary Coded Decimal) to generate IPv6 addresses. Given that one BCD digit requires 4 bytes, even the longest Global Titles (17*4=68 bits) can be coded as an IP address. By way of example, the Global Title "358 9 123 456" would code to the IPv6 address ⁽V:0:0:358:9123:456" (plus any appropriate prefix). Figure 4 illustrates the two main functional components of the SS7KE protocol. These are the unmodified IKE implementation and an IP/GT address translation "interface".

In the case of IPv4 addresses, the address space is only 32 bits. This is not sufficient to allow translation of the Global Titles into IP addresses using BCD coding. It is therefore proposed that in the case of IPv4 addresses Global Titles be hashed in order to generate unique IP addresses. As hashing is a one-way operation, i.e. it is not possible to recover the Global Title from the hash value using a formula, it is necessary to maintain at the KAC node a table or database mapping hash values (the IP addresses) to Global Titles. This approach will give rise to the possibility of two different Global Titles hashing to the same value, but this risk is small.

The complete SA negotiation and distribution process proceeds as follows. A destination Global Title is passed to the IP/GT address translation entity within the KAC, and the corresponding unique IP address generated. This is provided to IKE, which then initiates the negotiation with that IP address. The IKE messages are passed to the TCAP layer, encapsulated, and passed to the SCCP layer together with the associated Global Title for transmission over the SS7 network.

In a first phase of the signalling, IKE messages are exchanged between KAC nodes of respective operator networks in order to negotiate parameters required for establishing a Security Association. Once negotiated, the parameters are distributed by each KAC node to MAP nodes of the same operator network. This first signalling phase is typically instigated each time a new KAC node is introduced. The new KAC node will perform the phase 1 signalling with each existing KAC node with which it is required to establish a relationship. The Global Titles of the remote KAC nodes may be preprogrammed into a memory of the new KAC node. The procedure may be repeated occasionally (e.g. to ensure that security levels are maintained), and/or upon restarting of a failed KAC node.

Receipt of security parameters at a MAP node causes that node to establish the appropriate Security Association for the corresponding remote network in its Security Association Database. Typically, a MAP node will maintain a number of Security Associations, two for each foreign network with which it must communicate (one for incoming traffic and one for outgoing traffic).

When a signalling session is initiated with another MAP node within a network for which a Security Association exists, the MAPsec protocol is used to authenticate and authorise that other node, and optionally to secure MAP traffic exchanged. The signalling flow is as follows, with reference to Figure 5 which illustrates two MAP nodes NEa and NEb:

As the Sending Entity, NEa performs the following actions during the outbound processing of every MAP message: 1. NEa checks its Security Policy Database (SPD) to check if MAP security mechanisms shall be applied towards PLMN B: a) If the SPD does not mandate the use of MAPsec towards PLMN B, then normal MAP communication procedures will be used and the process continues in step 4.b. b) If the SPD mandates the use of MAPsec towards PLMN B, then the process continues at step 2. c) If no valid entry in the SPD is found for PLMN B, then the communication is aborted and an error is returned to the MAP user. 2. NEa checks its Security Association Database (SAD) for a valid Security Association (SA) to be used towards PLMN B. In the case where more than one valid SA is available at the SAD, NEa shall choose the one, the soft expiry time of which will be reached next. a) In case protection of MAP messages towards PLMN B is not possible (e.g. no SA available, invalid SA...), then the communication is aborted and an error is returned to MAP user. b) If a valid SA exists but the MAP dialogue being handled does not require protection (Protection Mode 0 applies to all the components of the dialogue), then either the original MAP message in clear text is sent in step 4.b, or a MAPsec message with Protection Mode 0 is created in step 3. c) If a valid SA exists and the MAP dialogue being handled requires protection, then the process continues at step 3. 3. NEa constructs the MAPsec message towards NEb using the parameters (keys, algorithms and protection profiles) found in the SA. 4. NEa generates either: a) MAPsec message towards NEb. b) An unprotected MAP message in the event that the SPD towards NEb or protection profiles for that specific MAP dialogue so allows it (l.a. or 2.b.). At the Receiving Entity, NEb performs the following actions during the inbound processing of every MAP message it receives:

5. If an unprotected MAP message is received, the process continues with step 6. Otherwise, NEb decomposes the received MAPsec message and retrieves SPI and Original component Id from the security header.

6. NEb checks the SPD:

An unprotected MAP message is received: a) If an unprotected MAP message is received and fallback to unprotected mode is allowed, then the unprotected MAP message is merely processed (Process goes to END) b) If an unprotected MAP message is received and the 'MAPsec operation components table' of the SPD does not mandate the use of MAPsec for the included 'Original Component Identifier', then the unprotected MAP message is merely processed (Process goes to END) c) If an unprotected MAP message is received, the 'MAPsec operation components table' of the SPD mandates the use of MAPsec for the included 'Original Component Identifier' and fallback to unprotected mode is NOT allowed, then the message is discarded. If the MAP dialogue is still open and it is waiting for an answer, NEb also reports an error back to NEa.

A MAPsec message is received, NEb checks SPI in the SPD: d) If SPI is not in SPD or there is no valid entry for the PLMN associated with SPI in the SPD, then the message is discarded and an error is reported to MAP user. If the MAP dialogue is still open and it is waiting for an answer, NEb also reports an error back to NEa. e) If a MAPsec message is received, but the SPD indicates that MAPsec is NOT to be used, then the message is discarded and an error is reported to MAP user. If the MAP dialogue is still open and it is waiting for an answer, NEb also reports an error back to NEa. f) If a MAPsec message is received and the SPD indicates that MAPsec is required, then the process continues at step 7. 7. NEb checks its SAD to retrieve the relevant S A- information for processing of the MAPsec message: a) If the received SPI points to a valid SA, then NEb uses the 'Original Component Identifier' in the MAPsec header to identify the protection level that has to be applied to the component indicated, according to the protection profile indicated in the SA. If Protection Mode 0 was applied, then the MAP message is simply processed (Process goes to END). Otherwise The process continues at step 8. b) If the received SPI does not point to a valid SA, the message is discarded and an error is reported to MAP user. If the MAP dialogue is still open and it is waiting for an answer, NEb also reports an error back to NEa.

8. Freshness of the protected message is checked by ensuring the Time Variant Parameter (TVP) is in an acceptable window. Integrity and encryption mechanisms are applied to the message according to the identified protection level, by using the information in the SA (Keys, algorithms). a) If the result after applying such mechanisms is NOT successful then the message is discarded and an error is reported to MAP user. If the MAP dialogue is still open and it is waiting for an answer, NEb also reports an error back to NEa. b) If the result after applying such procedures is successful, then NEb has the clear text MAP message NEa originally wanted to send NEb. The clear text MAP message can now be processed (Process goes to END) END: A clear text MAP message is available at NEb. In the event the received message at NEb requires an answer to NEa (Return Result Error), NEb will perform the process in steps 1 to 4 acting as the Sender and NEa will perform the process in steps 5 to 8 acting as the Receiver. In the event that a MAPsec enabled NE has initiated a secured MAP communication towards a non-MAPsec enabled NE and the MAPsec enabled NE received an error indication of such circumstance (i.e. "ApplicationContextNotSupported"). The MAPsec enabled NE shall check whether "Fallback to Unprotected Mode" is allowed: If NOT allowed, then the communication is aborted. - If allowed, then the MAPsec enabled NE shall send an unprotected MAP message instead. The same procedures shall apply to secure MAP communications between MAP-NEs in the same PLMN.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiment without departing from the scope of the present invention. For example, security protocols other than MAPsec might make use of the SS7 network to exchange IKE messages. These could include SCCPsec, TCAPsec, and CAPsec. Also, the proposed Common Open Policy Service (COPS) protocol, utilised for transmitting entire Security Association Policies (e.g. for MAPsec), could be carried out over the SS7 network.

Claims

1. A method of establishing a Security Association for securing traffic sent over an SS7 signalling network between signalling nodes, such that the parameters of the Security Association are known to each signalling node involved, the method comprising using the Internet Key Exchange protocol to negotiate said parameters between signalling nodes, Internet Key Exchange messages being sent over the SS7 network.

2. A method according to claim 1, wherein the IKE protocol is implemented within Key Administration Centre (KAC) nodes of operator networks.

3. A method according to claim 2, wherein each KAC node is implemented as an SS7 node having its own unique Global Title.

4. A method according to claim 3, wherein within each KAC a new Transmission Capabihties Apphcation Part (TCAP) user is created, this user implementing an extended IKE protocol.

5. A method according to claim 3 or 4, wherein for outgoing IKE traffic, the extended IKE converts the Global Title of the destination (SS7) node into a virtual IP address for inclusion in the header of the IKE messages, and the Global Title of the sending KAC is also converted into a virtual IP address for inclusion as the source address in the IKE messages.

6. A method according to claim 5, wherein the extended IKE codes Global Titles using BCD coding in order to generate IPv6 addresses.

7. A method according to claim 5 wherein the extended IKE has access to a translation table mapping Global Titles to hash values in order to generate IPv4 addresses.

8. A node for negotiating parameters relating to a Security Association to be used for securing traffic sent over an SS7 signalling network between signalling nodes, the node comprising: means for implementing the Internet Key Exchange protocol; and means for translating SS7 Global Titles into IP addresses for inclusion in outgoing IKE messages; and interface means for coupling the node to an SS7 signaling network.

9. A method of operating a Key Administration Centre located within a communications network for the purpose of determining Security Association parameters, the method comprising using the Internet Key Exchange protocol to negotiate said parameters with one or more other Key Administration Centres, Internet Key Exchange messages being sent and received by the Key Administration Centre over an SS7 network.