US7987366B2 - Key management for network elements - Google Patents

Key management for network elements Download PDF

Info

Publication number
US7987366B2
US7987366B2 US10/597,864 US59786404A US7987366B2 US 7987366 B2 US7987366 B2 US 7987366B2 US 59786404 A US59786404 A US 59786404A US 7987366 B2 US7987366 B2 US 7987366B2
Authority
US
United States
Prior art keywords
network
means
network element
network domain
key
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.)
Active, expires
Application number
US10/597,864
Other versions
US20070160201A1 (en
Inventor
Rolf Blom
Mats Naslund
Elisabetta Carrara
Fredrik Lindholm
Karl Norrman
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to PCT/SE2004/000179 priority Critical patent/WO2005078988A1/en
Assigned to TELEFONAKTIEBOLAGET LM ERICSSON (PUBL) reassignment TELEFONAKTIEBOLAGET LM ERICSSON (PUBL) ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BLOM, ROLF, CARRARA, ELISABETTA, LINDHOLM, FREDRIK, NASLUND, MATS, NORRMAN, KARL
Publication of US20070160201A1 publication Critical patent/US20070160201A1/en
Application granted granted Critical
Publication of US7987366B2 publication Critical patent/US7987366B2/en
Application status is Active legal-status Critical
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891Revocation or update of secret information, e.g. encryption key update or rekeying
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80Wireless

Abstract

The invention provides an establishment of a secret session key shared Between two network elements (NEa, NEb) belonging to different network domains (NDa, NDb). A first network element (NEa) of a first network domain (NDa) requests security parameters from an associated key management center (KMC) (AAAa). Upon reception of the request, the KMC (AAAa) generates a freshness token (FRESH) and calculates the session key (K) based on this token (FRESH) and a master key (KAB) shared with a second network domain (NDb). The security parameters are (securely) provided to the network element (NEa), which extracts the session key (K) and forwards the freshness token (FRESH) to the KMC (AAAb) of the second domain (NDb) through a second network element (NEb). Based on the token (FRESH) and the shared master key (KAB), the KMC (AAAb) generates a copy of the session key (K), which is (securely) provided to the second network element (NEb). The two network elements (NEa, NEb) now have shares the session key (K), enabling them to securely communicate with each other.

Description

TECHNICAL FIELD

The present invention generally refers to key management in communications systems, and in particular to inter-network domain key management for network infrastructure elements in such systems.

BACKGROUND

A communications environment or system can generally be envisaged as comprising a plurality of independent communication network domains. Each such network domain can provide access to its services for users connected thereto. In order to provide mobility within the communications environment and across different domains it is typically desirable to establish communications, in particular secure communications, between network elements (NEs) belonging to the different domains. A typical example of such a secure inter-domain communication between two network elements is a secure communication tunnel between Security Gateways (SEGs) of two telecommunication or network operators.

In order to provide secure communication between network elements of different networks domains, a key management/key exchange protocol is typically used to establish the security parameters necessary for the inter-NE communication. There exist different types of key management protocols in the prior art, and they can generally be divided into two classes: symmetric key and public key protocols, respectively. The former relies, in principle, on a secret key that is shared between the parties and cryptographic techniques based on such key(s). The latter makes use of a pair of keys per party (a secret key and a public key), a trusted third party “validating” public keys and public key cryptography techniques.

In a feasibility study to support Network Domain Security (NDS)/Internet Protocol (IP) evolution for 3G mobile network operators [1] a fully meshed symmetric solution for secure inter-SEG communication is disclosed. In the disclosure of [1] each SEG shares a long-term secret key with each exterior SEG, i.e. each SEG belonging to another network domain, it wishes to (securely) communicate with. If each domain has access to one SEG and n is the total number of SEGs in the communications environment housing the domains, the number of long-term keys to be distributed to the SEGs and stored in each SEG will amount to

n n - 1 2
if every SEG is to be able to communicate securely with every other SEG. Thus, the number of pre-shared secret keys can be very large and grows rapidly (with n2) in dependence of the number of active SEGs in the network domains. In addition, it is expected that each network domain can have more than one communicating NE or SEG, and that the SEGs/NEs need to communicate with a relatively large number of other SEGs/NEs in other network domains. Also adding a new SEG to an existing network domain requires large workload in the form of key distribution, management and storage. In addition, if a single SEG is broken or hacked, all SEGs in the different network domains have to be updated and new long-term secret keys have to be distributed therebetween.

Another possible solution, briefly mentioned in [1], is to employ a trusted third party, typically called Key Distribution Center (KDC), common to all network domains that is to communicate securely. In such a case, the KDC shares a secret key with each network domain it has a service agreement with. In order to establish secure communication between two NEs or SEGs of different network domains, the KDC distributes a fresh secret (usually not the same as the shared secret) to the parties that need to communicate. Typical examples in prior art of this solution are the Kerberos-based key management protocols. However, a drawback is that it is typically hard to find a suitable trusted third party that can act as a KDC, in particular in the case of inter-operator communication. In addition, increased administrative work is required to arrange for a common trust of this trusted third party solution. The KDC is also a possible single point of failure, if it is compromised, all network domains using its services are threatened.

The preferred key agreement protocol according to [1], which is also discussed in [2], is to utilize a Public Key Infrastructure (PKI) based method, whereby the SEGs or NEs share their public keys. The document [1] discloses a certificate-based solution without a Bridge Certification Authority (CA) PKI, or with a Bridge CA PKI, which is also further discussed in [2]. In either solution, each operator, whose NEs or SEGs are to communicate, has to sign the other party's root certificate. These certificates are then securely configured in each communicating SEG.

A major drawback with PKI protocols is that the (initial) cost of establishing a PKI infrastructure is very large. Furthermore, revocations of certificates require manual administration and revocation checks must always be performed (a certificate is a credential that is valid unless a verification returns that it is revoked), which requires on-line communication between the operators' Certificate Revocation Lists (CRLs). Moreover, the cryptographic operations involved in PKI solutions are expensive.

SUMMARY

The present invention overcomes these and other drawbacks of the prior art arrangements.

It is a general object of the present invention to provide a secret shared between two network elements of different networks domains in a communications system or environment.

It is a particular object of the invention that the provision of the secret shared between the two network elements is performed in a simple, possibly partially manual, way.

It is another object of the invention to enable secure communication between network elements belonging to different network domains.

Yet another object of the invention is to reduce the number of long-term secret keys required for enabling secure communication between network elements belonging to different network domains.

A further object of the invention is provide a secret shared between two network elements of different network domains re-using existing network infrastructure and functionalities.

Still a further object of the invention is to avoid introducing any possible single point of failures, the compromise of which might render all inter-domain communication insecure.

These and other objects are met by the invention as defined by the accompanying patent claims.

Briefly, the present invention involves establishing a symmetric secret or session key shared between two network elements (NEs) belonging to different networks or network domains (NDs), typically managed by different network operators or service providers. This shared session key then enables the network elements to securely communicate with each other. Such a network element could be a charging node needing to contact a corresponding charging node of another network domain. Similarly, a secure channel has to be set up between two security gateways (network elements) of different network domains. A further example could be the communication between a Proxy Call State Control Function (P-CSCF) of a visited network domain and an Interrogating CSCF or a Serving CSCF of a home domain, traffic between Serving Gateway General Packet Radio System (GPRS) Support Nodes (SGSN) and Gateway GPRS Support Nodes (GGSN). In yet another example, the communicating network elements could be a Home Location Register (HLR) and a Visited Location Register (VLR) or, in general, any form of inter-domain signalling, e.g. using Signaling System No. 7 (SS7).

The session key establishment procedure of the invention is based on that the network domains, comprising the network elements needing to communicate, share a (long-term) secret key, denoted master key in following. This master key is preferably (securely) kept in a central key storage or repository in the network domain. The domain further includes cryptographic means or a cryptographic key management center (KMC) or module connected or associated with the key storage. This KMC includes functionalities and algorithms for performing key management and possibly authentication by means of the keys in the storage. In a preferred embodiment of the invention, the KMC constitutes or comprises the Authentication, Authorization and Accounting (AAA) server node of respective network domain.

The key establishment procedure generally starts with a network element (NEa) in a network domain A (NDa) requesting security parameters from its associated intra-ND KMC (AAAa). This request typically is accompanied by or includes an identifier of an external network element (NEb) in a network domain B (NDb) that the network element NEa wants to communicate with, or an identifier of the network domain NDb of this external network element NEb. Upon reception of the request, the AAAa generates a freshness token, which could be or include a random challenge, a time-stamp and/or a sequence number. In addition, the AAAa identifies the relevant master key from the associated key repository based on the received identifier and generates a session key using a cryptographic function, typically, with the identified master key and generated freshness token as input parameters.

The generated freshness token and session key is then, preferably securely, provided to the network element NEa, which forwards the freshness token to the external network element NEb. This external network element NEb in turn forwards the received token to its associated KMC (AAAb), preferably accompanied by an identifier of the network element NEa or an identifier of the network domain NDa of network element NEa. Similar to above, the AAAb identifies the (same) correct master key from its associated key storage and generates a (identical) copy of the session key using an instance of the same cryptographic function as the AAAa of the other network domain NDa and the identified master key and received freshness token as input parameters.

The copy of the session key is then, preferably securely, provided to the network element NEb. The two network elements NEa and NEb now share a secret symmetric session key. This key may be employed directly for enabling secure communication between the network elements. For example, the session key can be used directly in Internet Protocol security (IPsec) protocols and algorithms. Alternatively, the session key could be used for running e.g. Internet Key Exchange (IKE) and negotiating Security Association (SA).

In a preferred embodiment of the invention, the session key establishment is performed by means of the Authentication and Key Agreement (AKA) algorithms and protocols provided in the AAA server node (KMC), preferably using a challenge-response scheme. It is then possible to connect the key establishment with an authentication procedure, where the communicating network elements may be authenticated. In such a case, in addition to the freshness token (typically a random challenge in case of challenge-response scheme) and session key, the AAAa calculates an expected response based on the master key and the random challenge. This expected response is then (securely) provided to the network element NEa together with the other security parameters (session key, random challenge). Upon reception of the random challenge (freshness token), the AAAb of the other network domain NDb generates a response based on the challenge and the master key, in addition to generating the copy of the session key. This response is then transmitted, via its associated network element NEb to the network element NEa, which compares the received response with the expected response value provided previously from its associated cryptographic means AAAa. If they correctly match, network element NEa authenticates network element NEb and considers the session key establishment successful.

In order to increase the security and allow both network domains (KMC of the domains) influence the generation of the session key, the challenge-response scheme could be repeated (interleaved) in the opposite direction. The shared generated session key(s) may then be a function of the keys generated in both directions. Similarly, the challenge and/or responses in respective direction could be interdependent.

The key storage of the each network domain houses the master key(s) shared with other domains. According to the invention, this storage only needs to keep one long-term master key per network domain pair. In other words, a network domain shares a first master key with a first external network domain and a second master key with a second external domain, etc. Contrary to these long-term master keys that basically only needs to be exchanged if a key storage is compromised, the lifetime of the generated session keys is comparatively much shorter. Thus, a session key is typically only valid during a communication session between network elements, or sometimes only during a portion of such a session. Moreover, should the key storage of a first domain be compromised only communication to that particular domain is potentially threatened, i.e. other network domains, e.g. a second and a third domain, can still securely inter-communicate.

The secret master keys used by the invention can be (securely) exchanged between the network domains (key repositories of the domains) in a number of different ways, for example using the Diffie-Hellman protocol, which can even be carried out manually between operator staff personnel, thereby providing the authentication of the Diffie-Hellman exchange. Thus, the most sensitive part of the establishment of the session key between two NEs can be performed manually, assuring authenticity by personal contact/exchange between operator or provider personnel.

The present invention facilitates adding/revoking a network element to/in an existing network domain. Basically, when adding a new network element, a secure channel is established between this new network element and the node(s) housing the cryptographic means. This is a configuration issue and can usually be done in combination with setting up the operation and maintenance channels to the new network element. Similarly, when a network element is revoked, the cryptographic means simply deletes the network element from its database of available network elements. Any (session) key cached in the network element is further erased.

Furthermore, if a key repository is hacked, the master keys in the key repository (and the corresponding copies of the master keys stored in repositories of other network domains) are simply updated, e.g. by anew performing the Diffie-Hellman or similar agreement protocol mentioned above. Indeed, to provide “backwards” security, the master key could be used in a bootstrap fashion to intermittently or regularly update or exchange new master keys between the domains. This has the advantage that the content of the domain key storage at a given time does not comprise older keys. Depending on the lifetime of the session keys, some or all network elements may need to be flushed from temporary stored session keys. This should be compared to the fully meshed symmetric solution discussed in the background section. In such a solution, if a single network element is hacked the keys of all network elements in all network domains (often several tens or hundreds of keys and network elements) may need to be replaced. However, by employing the present invention, if a network element is hacked, no key replacement has to be performed, though possibly a new session key has to be generated and provided if the network element currently is communicating with another external network element.

The invention offers the following advantages:

    • Reduces the number of long-term secret keys required to be distributed between and stored in network domains;
    • Provides re-utilization of existing network infrastructure and functionality by using the AAA server node and its AKA algorithms, markedly reducing the cost of implementing a key establishment between network elements;
    • Is more computationally efficient than PKI based protocols;
    • Provides replay protection and freshness in establishing shared session keys;
    • Provides easy revocation of network elements and network domains; and
    • Provides easy addition of network elements to existing network domains.

Other advantages offered by the present invention will be appreciated upon reading of the below description of the embodiments of the invention.

SHORT DESCRIPTION OF THE DRAWINGS

The invention together with further objects and advantages thereof, may best be understood by making reference to the following description taken together with the accompanying drawings, in which:

FIG. 1 is an overview of a communications system illustrated with three network domains according to the present invention;

FIG. 2 is an illustration of an embodiment of a communications system according to the present invention;

FIG. 3 is a schematic diagram of an embodiment of a session key establishment according to the present invention;

FIG. 4 is a schematic diagram of another embodiment of a session key establishment according to the present invention;

FIG. 5 is a schematic diagram of a further embodiment of a session key establishment according to the present invention;

FIG. 6 is a schematic diagram continuing the session key establishment of FIG. 5;

FIG. 7 is a schematic diagram of an embodiment of a master key agreement according to the present invention;

FIG. 8 is a block diagram of an embodiment of (cryptographic) key management center (KMC) according to the present invention;

FIG. 9 is a block diagram of an embodiment of an authentication and keying unit of the KMC of FIG. 8; and

FIG. 10 is a block diagram of an embodiment of a network element according to the present invention.

DETAILED DESCRIPTION

Throughout the drawings, the same reference characters will be used for corresponding or similar elements.

The present invention relates to key management for establishing a shared secret key between two network elements of different networks or network domains in a communications system or environment. The invention also enables secure communication between the two network elements based on the established and shared secret key.

In order to facilitate understanding of the invention, in the present description a network is referred a number of connected or associated computers and/or network nodes having communications means and interconnections therebetween. A network domain or administrative network domain is (typically a portion of) a network governed by certain polices, defined by the administrator of the network. In the following, the invention will be described with reference to establishing a shared secret between two network elements of different network domains. However, as the person skilled in the art understands, the two network elements could, alternatively, belong to different administrative network domains and/or networks, and/or two domains of one and the same network. Furthermore, communication between networks is then referred to (if not pointed out otherwise) communication between network domains.

Referring to FIG. 1, a communications system 1 or environment is schematically illustrated. In the figure, the communications system 1 includes three independent network domains (NDs), denoted 100; 200 and 300, respectively. Each such network domain 100; 200; 300 is managed by a network operator or service provider and provides services to users connected to the network domain 100; 200; 300 and, possibly, having a service agreement, e.g. a subscription, with the network operator. In a typical example, each network operator manages one network domain 100; 200; 300, e.g. network domain 100 is managed by a first network operator, a second operator manages network domain 200, etc. However, it is possible for a single operator to manage two or more of the network domains 100; 200; 300 in the communications system 1.

The network domains 100; 200; 300 typically comprise a number of network elements (NE) or nodes NEa1, NEa2; NEb; NEc1, NEc2, NEc3 that are able to conduct communication with network elements of the same domain and also with network elements of other external network domains, the latter case being of particular interest for the present invention. Such a network element NEa1, NEa2; NEb; NEc1, NEc2, NEc3 could be a charging node needing to contact a corresponding charging node of another network domain. Similarly, a secure channel has to be set up between two Security Gateways (SEGs) (or network elements) of different network domains. A further example could be the communication between a Proxy Call State Control Function (P-CSCF) of a visited network domain and an Interrogating CSCF or a Serving CSCF of a home domain, traffic between Serving Gateway General Packet Radio System (GPRS) Support Nodes (SGSN) and Gateway GPRS Support Nodes (GGSN). In yet another example, the communicating network elements could be a Home Location Register (HLR) and a Visited Location Register (VLR) or, in general, any form of inter-domain signalling, e.g. using Signaling System No. 7 (SS7).

The network elements NEa1, NEa2; NEb; NEc1, NEc2, NEc3 are typically fixedly arranged and constitute a portion of the infrastructure of respective network domain 100; 200; 300, allowing provision of different services to users connected to the network domain 100; 200; 300.

In addition to a number of network elements NEa1, NEa2; NEb; NEc1, NEc2, NEc3, the network domain 100; 200; 300 includes cryptographic means or a (cryptographic) key management center (KMC) or module 120; 220; 320 and an associated central key repository or key distribution center 140; 240; 340. The KMC 120; 220; 320 provides keys managed and stored in the key repository 140; 240; 340, performs cryptographic functionalities, e.g. encryption and decryption, using these keys and authentication for the network domain 100; 200; 300 and its network elements NEa1, NEa2; NEb; NEc1, NEc2, NEc3.

In the communication system 1, each network element NEa1, NEa2; NEb; NEc1, NEc2, NEc3 may be configured for conducting communication with all or some of the network elements in the other network domains. For example, network element NEa1 may communicate with network element NEb of network domain 200 and all the network elements NEc1, NEc2, NEc3 of network domain 300. However, a network element may, alternatively, only be allowed to communicate with a limited number of the external network elements.

The network elements NEa1, NEa2; NEb; NEc1, NEc2, NEc3 are also connected with the KMC 120; 220; 320 of respective network domain 100; 200; 300, preferably by means of a secure channel. Using such a secure channel the KMC 120; 220; 320 may provide keys and other sensitive information to its associated network elements NEa1, NEa2; NEb; NEc1, NEc2, NEc3. A typical example of such a secure channel is an Operation and Management (O&M) channel between a network element NEa1, NEa2; NEb; NEc1, NEc2, NEc3 and the KMC 120; 220; 320.

In the following, which is further illustrated in the communication systems 1 of FIG. 2, the KMC will be instantiated by an Authentication, Authorization and Accounting (AAA) server node 120; 220 of the network domain 100; 200. The AAA server node 120; 220 typically includes functionalities and algorithms for generating and managing keys provided in associated key repositories 140; 240 in addition to authentication functionalities, e.g. by using an Authentication and Key Agreement (AKA) functionality or protocol.

Alternatively to FIG. 1, the network domain 100; 200 may include one or a few communicating network elements SEGa; SEGb dedicated for conducting communication with external communicating network elements. In FIG. 2, such dedicated network elements are exemplified by two security gateways SEGa; SEGb, adapted for mutual communication. In such a case, any protocols necessary for the communication may then be housed in only one or a few network elements in each network domain, instead of in all of the network elements of the domain. Any communication between two network elements NEa1, NEa2; NEb not adapted for inter-domain communication is then conducted in a proxy fashion through the security gateways SEGa; SEGb of FIG. 2. Use of designated SEGs is advantageous as security processing only needs to be implemented in the SEG (SEGa; SEGb), which then acts as a “security proxy” for other network elements NEa1, NEa2; NEb.

According to the present invention, the network domains, whose network elements are to communicate, share a secret symmetric key, denoted master key in the following. For example, referring back to FIG. 1, network domain 100 shares a master key (KAB) with network domain 200 and another master key (KAC) with domain 300. Similarly, network domain 200 and domain 300 share a master key (KBC). These master keys are long-term shared keys that are secure kept, preferably, centrally at the key repository 140; 240; 340 of respective domain 100; 200; 300. The procedure of this master key establishment is discussed further below.

Once two network elements of different network domains are to securely communicate with each other, the KMC of respective domain generates a symmetric secret or session key and, preferably securely (relying on intra-domain security in the form of cryptography or in the form of physically protected links), provides it to its associated network element. The inter-NE communication may then be securely performed based on the session keys now present in the network elements. The generation of session key is discussed in more detail herebelow.

FIG. 3 schematically illustrates a method of establishing a session key shared by two network elements (NEa, NEb) of two network domains. The KMC or AAA-server (AAAa, AAAb) of the network domains have pre-shared a master key (KAB) (step S1). In addition, respective AAA server node preferably has a secure (trusted) intra-domain channel towards its associated network element(s).

When NEa and NEb need to communicate, NEb may optionally trigger the communication by sending its identifier or an identifier of its network domain (IDb) to NEa (step S2). Alternatively, NEa triggers the communication itself.

NEa issues a request to AAAa for security parameters for the communication with NEb. The request is accompanied by the identifier IDb (step S3).

In response to the request, AAAa generates or obtains a freshness token (FRESH). Furthermore, the relevant pre-shared master key KAB is identified based on the received identifier IDb and is provided typically from the associated key repository. Once the correct master key KAB is obtained, AAAa generates or calculates a session key (K) based on the generated freshness token FRESH, the master key KAB and some cryptographic function (g). Optionally, additional information, such as the identifiers of the network elements and/or domains IDa, IDb, may be used in this calculation.

The session key K and freshness token FRESH is then (securely) transmitted, preferably using the secure channel, to NEa (step S4).

NEa extracts the session key K from the received security parameters and forwards the freshness token FRESH to NEb, possible accompanied by its identifier or the identifier of its network domain (IDa) (step S5).

NEb forwards the freshness token FRESH to its associated cryptographic KMC or AAAb together with the identifier IDa, received from NEa or obtained elsewhere (step S6).

Similarly to AAAa, AAAb identifies and provides the relevant pre-shared master key KAB from its storage, e.g. in the associated key repository, based on the obtained identifier IDa. Furthermore, AAAb generates an copy of the session key K using an instance of the same cryptographic function g as AAAa with the master key KAB and freshness token FRESH as input parameters.

The now generated (copy of) session key K is, preferably securely, transmitted to NEb (step S7).

At this point, the network elements NEa and NEb shares a secret symmetric session key K. This key may be employed directly for enabling secure communication between the network elements (step S8). For example, the session key can be used directly in Internet Protocol Security (IPsec) protocols and algorithms. Alternatively, the session key could be used for e.g. running Internet Key Exchange (IKE) and negotiating Security Association (SA).

By employing the above-identified method of the present invention, replay protection and freshness for the generation of session keys are provided. As was briefly mentioned above, the cryptographic function used for calculating the session key could also include other information as input parameters in addition to the master key and freshness token. For example, the identifier IDa and/or IDb could be possible additional input to the function.

The freshness token required for generating the session key could be generated by the AAA server node of the network domain or by some other unit or node connected thereto, including the communicating network element. The freshness token could be a time-stamp, e.g. a time-stamp associated with the time of reception of the request for security parameters from the network element, a sequence number and/or a random challenge, possibly associated with an authentication token.

The establishment of session keys may be accompanied by an authentication of the communicating network elements, e.g. using a challenge-response scheme. In such a case, the AAA server node could re-use the AKA algorithms traditionally employed for authenticating and key agreement between a network operator's AAA server and a user's mobile unit, or more precisely between the AAA server and an Identity Module, e.g. Subscriber Identity Module (SIM), arranged in the mobile unit.

FIG. 4 schematically illustrates a session key establishment according to the present invention using a challenge-response procedure.

Correspondingly to FIG. 3, AAAa and AAAb pre-shares a secret master key KAB (step S10). The communication between the network elements may optionally be triggered by NEb providing its identifier or its domain identifier IDb to NEa (step S11). NEa transmits a request for security parameters to AAAa, typically, including the identifier IDb (step S12).

Upon reception of the request, AAAa identifies the relevant master key KAB based on the provided identifier IDb similarly to FIG. 3. In addition, AAAa generates an authentication vector (AV). In this embodiment, the AV is a quintuple of security and authentication parameters. Starting with a random challenge (RAND), generated by AAAa or elsewhere, and an authentication token (AUTN), generally constituting the freshness token of FIG. 3. The authentication token AUTN could be e.g. a (simple) counter or some cryptographically protected information, such as authenticated using a key based on the master key KAB. Furthermore, an expected response (XRES) is generated using a cryptographic function (f) on the challenge RAND and master key KAB. A cipher key (Ck) and integrity key (Ik) are also generated based on the master key KAB and challenge RAND, and possibly other optional information, as input to cryptographic function f1 and f2, respectively. In this embodiment Ck and/or Ik are used as session key(s). For more information of generation of the quintuple AV reference is made to [3], with the master key (or a key derived therefrom) as initial secret for the algorithms in [3].

The generated quintuple AV is then (securely) transmitted to NEa (step S13).

NEa extracts the random challenge RAND and authentication token AUTN form the received security parameters AV and forwards them, possibly together with its identifier or the identifier of its domain IDa, to NEb (step S14).

Upon reception of the parameters, NEb forwards them to its associated AAAb server node (step S15).

AAAb identifies and retrieves the correct master key KAB from its storage based on the received identifier IDa and checks if the authentication token AUTN is ok. If the token AUTN was cryptographically protected by AAAa using its instance of the master key KAB, AAAb employs the identified and provided master key KAB for authentication purposes. Furthermore, using instances of the same functions f, f1, f2 as AAAa, AAAb generates a response (RES) and the cipher Ck and integrity Ik keys.

The response RES and session keys (Ck, Ik) are then, preferably securely, transmitted to NEb (step S16).

The network element NEb forwards the received response RES to NEa (step S17), which now can authenticate NEb by comparing the received response RES with the expected response value XRES in the quintuple AV provided previously from AAAa. If they correctly match, NEa authenticates NEb and considers the session key establishment successful.

NEa and NEb now have access to the keys Ck and Ik, which can be used as session keys e.g. for conducting secure communication between the network elements (step S18), as was discussed in connection with FIG. 3.

Thus, in this embodiment of the invention, the AAA server node and its AKA functionality and protocols are re-used for establishing session keys for network elements and for enabling secure communication between such elements of different network domains. Compared to the traditional role of the AAA server node in authenticating SIM of mobile telephones and other mobile units, the AAA node of the present invention will have two rolls. Firstly that of a normal AAA server (AAAa in FIG. 4) and that of SIM (AAAb in FIG. 4). In this context, NEa could be viewed as corresponding to an AAA proxy and NEb as a “mobile telephone”. However, NEb and AAAb function as two separate network elements or nodes, whereas a mobile telephone and SIM are one integrated mobile unit.

In order to increase the security and allow both network domains (AAA of the domains) influence the generation of the session key, the challenge-response scheme of FIG. 4 could be repeated in the opposite direction. The shared generated session key(s) may then be a function of the keys generated in both directions.

FIGS. 5 and 6 schematically illustrates a possible solution for a double challenge-response procedure according to the present invention. Steps S20, S21 and S22 correspond to steps S1, S2 and S3 of FIG. 3 (steps S10, S11 and S12 of FIG. 4) and are not further discussed.

Upon reception of a request for security parameters from the associated network element NEa, AAAa generates or obtains a first random challenge (RANDa) and a first authentication token (AUTNa). Furthermore, AAAa identifies the correct master key KAB based on the received NEb or NDb associated identifier IDb. A first expected response (XRESb) is calculated using a cryptographic function f and the identified master key KAB and provided first random challenge RANDa as input parameters. Correspondingly, the cryptographic means of the server node AAAa generates a first pre-cipher key (Cka) and a first pre-integrity key (Ika) by means of the master key gxy, random challenge RANDa and cryptographic function f1 and f2, respectively. These keys Cka, Ika are then stored in the server node, or in an associated accessible storage provided elsewhere, for later use.

The security parameters are then (securely) transmitted as a triplet authentication vector, comprising the first authentication token AUTNa, random challenge RANDa and expected response XRESb, to the network element NEa (step S23).

The network element NEa extracts and removes the first expected response XRESb from the authentication vector. The rest of the AV (i.e. AUTNa, RANDa) is then transmitted to the network element NEb possibly accompanied by its identifier of its domain identifier IDa (step S24).

The network element NEb forwards the authentication vector and the identifier IDa to its associated AAAb server node (step S25).

AAAb identifies and retrieves the correct master key KAB from its storage based on the received identifier IDa and investigates whether the first authentication token AUTNa is correct. Using instances of the same functions f, f1, f2 as AAAa, AAAb generates a first response (RESb) and the first pre-cipher Cka and pre-integrity Ika keys. AAAb also generates or obtains from some other unit in its network domain NDb a second random challenge (RANDb) and second authentication token (AUTNb). A second expected response (XRESa) is then calculated using function f and the master key KAB and a concatenation of the second random challenge RANDb and the first response RESb. It is anticipated by the invention that some other function, e.g. exclusive OR (XOR) and/or hash function, could be used instead of the concatenation. The provided second random challenge RANDb is also used, together with the master key KAB and cryptographic function f1 and f2, respectively, for generating a second pre-cipher key (Ckb) and a second pre-integrity key (Ikb). Finally, session key(s) represented by a cipher key Ck and/or integrity key Ik are generated based on the first and second pre-cipher keys Cka, Ckb and the first and second pre-integrity keys Ika, Ikb, respectively, and some function (h).

Continuing to FIG. 6, an authentication vector including the second authentication token AUTNb, second random challenge RANDb, first response RESb, second expected response XRESa and the cipher Ck and integrity Ik keys is, preferably securely, transmitted to the network element NEb (step S26).

The network element NEb extracts the cipher Ck and integrity Ik keys (session key(s)) and second expected response XRESa from the vector, the rest of which is then forwarded, possibly accompanied by the NEb or NDb identifier IDb, to the network element NEa (step S27).

The network element extracts the first response RESb from the authentication vector and compares it to the first expected response XRESb received previously from AAAa. If they correspond or match, network element NEa considers the network element NEb successfully authenticated and forwards the authentication vector received from NEb to AAAa (step S28).

AAAa identifies the correct master key gxy based on the received NEb or NDb identifier IDb and verifies the second authentication token AUTNb. A second response (RESa) is then calculated using function f and the master key KAB and a concatenation of the received second random challenge RANDb and the first expected response XRESb (or first response RESb) as input parameters. This first expected response XRESb could be obtained from a storage in the AAAa server node, or in an associated storage. AAAa has then previously entered the expected response XRESb in the storage, e.g. in connection to generating it upon reception of the request for security parameters from the network element NEa, see FIG. 5. Alternatively, the first expected response XRESb or first response RESb could be provided from network element NEa together with the authentication vector transmitted in step S28. It is also possible for AAAa to anew calculate the first expected response XRESb by means of the first random challenge RANDa, as provided from a storage or from network element NEa.

In addition, AAAa generates the second pre-cipher key Ckb and pre-integrity key Ikb by means of the master key KAB and the received second random challenge RANDb as input parameters to functions f1 and f2, respectively. These calculated keys are used together with the previously generated and stored first pre-cipher key Cka and pre-integrity key Ika for generating the session key(s) (cipher key Ck and/or integrity key Ik).

The generated second response RESa and the cipher Ck and integrity Ik keys are then, preferably securely, provided to the network element NEa (step S29).

The network element NEa extracts the keys (Ck, Ik) and forwards the second response RESa to the network element NEb (step S30).

Network element NEb compares this second response RESa with the second expected response XRESa received earlier from its associated AAAb server node. If they correspond, network element NEb has authenticated network element NEa and considers the session key establishment successful. The now shared secret cipher key Ck and/or integrity key Ik can be used as session key(s) e.g. for conducting secure communication between the network elements (step S31), as was discussed in connection with FIG. 3.

The double challenge-response procedure discussed above and in connection with FIGS. 5 and 6 should merely be seen as an example of such repeated challenge-response based session key establishment according to the present invention. In another embodiment, the second expected response and second response could be calculated with a concatenation, XOR and/or hash of the first and second random challenge as input parameters instead of, or as a complement to, a concatenation, XOR and/or hash of the second random challenge and the first response/expected response. Furthermore, AAAb could use a message authentication code (MAC) function on the second random challenge and an XOR value of the first and second integrity keys (or first and second cipher keys). The output (m′=MAC[(Ika XOR Ikb), RANDb]) from the MAC function could then be provided to AAAa (through steps S26, S27 and S28). AAAa then uses an instance of the same MAC function for calculating a corresponding output (m=MAC[(Ika XOR Ikb), RANDb). AAAa then verifies that the calculated output m corresponds to the received output m′.

The session key(s) generated according to the present invention could be used for cryptographically protecting the traffic between the two network elements during the duration of a whole communication session and is then discarded when the communication is over. Alternatively, the lifetime, during which the session key is valid, may be shorter than the duration of the communication session. For example, the key could be used only for initiating the secure inter-NE channel, where some other key, e.g. derived from the session key, is used for actually encrypting and decrypting information transmitted between the network elements. Alternatively, the session key could be used for transmitting only a certain amount of data, after which a new key establishment or portion thereof has to be performed. In either case, the total lifetime of the session key may be negotiated, e.g. during IKE, between the network elements or domains and may be determined in such a privacy negotiation.

Generally, the lifetime or valid time of a session key is comparatively much shorter than the corresponding lifetime of the long-term secret master key shared between two network domains. Whereas a new secret session key is, typically, generated for each communication session, or several times per session, the same master key is, preferably, used for several such communication sessions. Actually, the master keys only have to be exchanged if the storage (key repository), where the master keys are kept in respective domain, is broken. However, in some applications it may be advantageous from security point of view to intermittently update master keys, e.g. once a year, in the network domains. Indeed, to provide “backwards” security, the master key could be used in a bootstrap fashion to regularly or intermittently update or exchange new master keys between the domains. This has the advantage that the content of the key repository at a given time does not comprise older keys.

The agreement and sharing of master keys between the network domains in the communication systems may be implemented in various ways. However, one common misinterpretation is often that the agreement on a symmetric master key requires complicated (very high) security procedures. A typical example of a key agreement protocol for the master key that can be employed according to the present invention is the Diffie-Hellman (DH) agreement protocol. This protocol allows a robust and secure master key inter-ND establishment.

FIG. 7 schematically illustrates a Diffie-Hellman procedure for master key establishment according the present invention. In the figure, two network domains are to share a common master key. The two network domains, or AAA server nodes of the domains, each generates a secret key, x for AAAa and y for AAAb in FIG. 7. The secret key is then securely stored, e.g. in a tamper-resistant storage in the key repository of respective domain. The secret x; y preferably never should leave this secure storage. In addition, a corresponding public value of the secret x; y is calculated, denoted gx and gy, respectively. Here, gx and gy refer to exponentiation operations (i.e. repeated group operations) in a suitable finite group. For more information refer to [4]. This key generation and calculation can be done at any time in advance of the actual master key agreement.

At the time of the master key establishment, e.g. at the time of signing a roaming agreement between the operators of the two network domains, the calculated public values gx; gy are exchanged (step S40 and S41). This public value exchange is preferably performed in an authenticated way, e.g. by the operators' representatives exchanging floppy disks, each comprising a DH public value gx; gy of the generated secret x; y. Alternatively, these values could be printed on paper in an Optical Character Recognition (OCR) friendly manner. Yet another approach is to use compact flash cards, Universal Serial Bus (USB) storage devices, etc., or the teaching of document [5].

The AAA server of respective network domain can then generate a common shared secret key (master key) gxy based on the exchanged public values gx; gy and respective stored secret x; y. By employing the procedure described above and illustrated in FIG. 7, there is (under usual intractability assumptions on the Diffie-Hellman problem) absolutely no risk of revealing the master key gxy, not even if both floppy disks are “sniffed” by an adversary. The authenticity of the exchange is verified visually by the respective operator representative. Thus, the most sensitive part of the session key establishment can be performed manually and assuring authenticity.

If a ND operator would like to revoke e.g. his roaming agreement with another network domain so that his network elements no longer should be able to securely communicate with the other ND operator's network elements, the master key shared with this external network domain is simply deleted from the key storage or repository. In addition, each time a network element requests security parameters, including the session key, from its AAA server node, it gives automatic check of revocation status of the correspondent network element and operator.

Furthermore, if any key repository is hacked, the master keys in the key repository (and the corresponding copies of the master keys stored in repositories of other network domains) are simply updated, e.g. by anew performing the Diffie-Hellman agreement protocol discussed above. Depending on the lifetime of the session keys, some or all network elements may need to be flushed from temporary stored session keys. This should be compared to the fully meshed symmetric solution discussed in the background section. In such a solution, if a single network element is hacked the keys of all network elements in all network domains (often several tens or hundreds of keys and network elements) may need to be replaced. However, according to the present invention if a network element is hacked, no key replacement has to be performed, though possibly a new session key has to be generated and provided if the network element currently is communicating with another external network element. Moreover, returning briefly to FIG. 1, should the key storage 140 of the network domain 100 be compromised only communication to that particular domain 100 is potentially threatened, i.e. other network domains, e.g. the domain 200 and the domain 300, can still securely inter-communicate.

When a new network element is added to an existing network domain, basically the only measure required is the establishment of a, preferably secure, channel between this new network element and the AAA node. This is a configuration issue. No further distribution of keys or certificates is required. Similarly, when a network element is to be revoked from a network domain, the AAA node simply deletes the network element (the key used for the secure channel between AAA and the network element) from its database of available network elements, to which it has a (secure) channel. Any (session) key cached in the network element is further erased.

FIG. 8 is a schematic block diagram of a (cryptographic) key management center (KMC) or module (AAA server) 20 according to the present invention illustrated associated with a key repository 40. The KMC 20 generally includes an input and output (I/O) unit 22 for managing communication with external units, nodes and elements. In particular, the I/O unit 22 is adapted for receiving requests for security parameters, possibly including a NE or ND identifier, from an associated network element, for (securely) transmitting requested security parameters (including the session key) to a requesting network element and for reception of a freshness token from a intra-ND network element. The KMC 20 further includes an authentication and keying unit 30, typically comprising AKA functionality for performing key management and possibly authentication.

The units 22, 30 of the KMC 20 may be provided as software, hardware or a combination thereof. They may be implemented together for example in a network node in the network domain. Alternatively, a distributed implementation is also possible with some of the units provided in different network nodes.

The KMC 20 comprises, is connected to or associated with the (central) key repository or storage 40 of the network domain. The repository 40 typically includes a set of secrets (x1, x2, . . . ) used for generating DH public values and master keys. In a first embodiment only one secret is used for generating the required master keys shared with other network domains. However, one secret is preferably only used for generating one master key. In other words, if a network domain is to share master keys with two other network domains it preferably generates to two different secrets (x1, x2), where the first (x1) is used for calculating the master key shared with the first domains and the other secret (x2) is employed for generating the master key shared with the second domain.

The repository 40 also comprises a set of master keys (gx 1 y 1 , gx 2 z 1 , . . . ) (or more generally, representations of master keys, e.g. obtained by hashing each Diffie-Hellman value) associated with identifiers (IDb, IDc, . . . ) of the relevant network domain, with which it shares the master keys. The identifier and master key association allows identification of correct master key based on information of the identifier.

Preferably, also a set of secret keys (S1, S2, . . . ) used for secure communication between the KMC 20 and its associated network elements is stored in the repository 40. A corresponding copy of the relevant secret key is then stored also in the network element. It could be possible to use one and the same secret key for the secure communication between the AAA node and all its associated network elements. However, it may be preferred to use one secret only for a group of network elements or a single network element.

The key repository 40 could be provided as a stand-alone node in the communication domain and (securely) connected to the KMC 20. Alternatively, the repository 40 and KMC 20 may be implemented in one and the same network node. Also a distributed implementation is possible, where the different set of keys are provided in different nodes, e.g. the master keys (gx 1 y 1 , gx 2 z 1 , . . . ) are provided in one node, the secrets (x1, x2, . . . ) used for generating the master keys in a second node and the secrets (S1, S2, . . . ) employed for the secure communication with the network elements in a third node, e.g. the AAA server node. However, in the present invention the KMC (AAA server node) 20 and the key repository 40 could for clarity be regarded as one logic unit in the network domain, even if implemented in separate nodes. In either way, the key storage 40 is preferably tamper-resistant rendering it more difficult to break. Furthermore, secrets and keys preferably should preferably not leave the secure environment unprotected.

FIG. 9 is a block diagram illustrating the authentication and keying unit 30 of FIG. 8 in more detail. The authentication and keying unit 30 generally comprises a freshness token generator 32. Depending on the type of freshness token employed in the session key establishment procedure of the invention, the generator 32 could be implemented as a random challenge generator, sequence number counter, time-stamping unit, etc. Alternatively, this token generator 32 could be provided elsewhere in the network domain, including in a network element. Further, the unit 30 may optionally include a cryptographic functionality 34 for generating an expected response or response by means of the freshness token from the generator 32 and a master key from the key storage. Also a key manager 36 is implemented in the authentication and keying unit. The manager 36 in particular includes functionality 38 for generating keys, including generating master keys, generating secrets used for generating master keys, generating DH public values and generating or calculating session keys. In particular in the case of session key generation, the key generator 38 could use a single cryptographic function. Alternatively, a unique cryptographic function could be used for each network domain so that each network domain pair shares one unique function. The key manager 36 also typically manages key deletion and replacement or updatings in the key repository, and possible in the associated network elements, such by sending a key storage flushing command to the network elements and key storage.

The units 32, 34, 36, 38 of the authentication and keying unit 30 may be provided as software, hardware or a combination thereof. They may be implemented together for example in a network node in the network domain. Alternatively, a distributed implementation is also possible with some of the units provided in different network nodes.

FIG. 10 is a schematic block diagram of a network element or node 10 according to the present invention. The network element 10 includes an I/O unit 12 for communicating with the associated AAA server node (KMC) and with external network elements of other network domains. A key storage 14 is also preferably arranged in the network element for (temporarily) storing session keys (K). Also the secret key (S1) shared with the AAA server and used for secure communication therewith may be housed in the storage 14. The key storage 14 is preferably tamper-resistant making it harder to hack or break for an adversary. Optionally, a comparison unit 16 may be provided in the network element 10 for comparing an expected response received in the authentication vector (security parameters) from the AAA server with the response from an external network element. Based on the comparison performed by the unit 16, the network element 10 may authenticate the external network element, with which it wants to securely communicate. Although not illustrated in the figure, a key manager for deleting session keys when their lifetime has expired and/or flushing the key storage 14 upon reception of a key flushing command from the AAA server node may be implemented in the network element.

The units 12, 16 of the network element 10 may be provided as software, hardware or a combination thereof.

It will be understood a person skilled in the art that various modifications and changes may be made to the present invention without departure from the scope thereof, which is defined by the appended claims.

REFERENCES

  • 1 3GPP TR 33.810 V6.0.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Network Domain Security/Authentication Framework (NDS/AF); Feasibility study to support NDS/IP evolution, December, 2002.
  • 2 3GPP TS 33.310 V0.30, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Domain Security; Authentication Framework, May, 2003.
  • 3 3GPP TS 33.102 V5.2.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture, June, 2003.
  • 4 A. J. Menezes, P. C. van Oorschot and S. C. Vanstone, “Handbook of Applied Cryptography”, CRC Press, 1996.
  • 5 ISO/IEC 9798-6, “Information technology, Security techniques, Entity authentication, Part 6: Mechanisms using manual data transfer”, Working draft, April, 2003.

Claims (29)

1. A method of establishing a session key shared between a first network element of a first network domain and a second network element of a second network domain, said first network domain comprising first cryptographic means and means for sharing a secret key with said second network domain comprising second cryptographic means, said method comprising the steps of:
said first cryptographic means generating a freshness token;
said first cryptographic means generating said session key based on said shared secret key and said generated freshness token;
providing said session key (K) to said first network element;
providing said freshness token to said second cryptographic means;
said second cryptographic means generating a copy of said session key based on said shared secret key and said provided freshness token; and,
providing said copy of said session key to said second network element.
2. A method of enabling secure communication between a first network element of a first network domain and a second network element of a second network domain, said first network domain comprising first cryptographic means and means for sharing a secret key with said second network domain comprising second cryptographic means, said method comprising the steps of:
said first cryptographic means generating a freshness token;
said first cryptographic means generating said session key based on said shared secret key and said generated freshness token;
providing said session key to said first network element;
providing said freshness token to said second cryptographic means;
said second cryptographic means generating a copy of said session key based on said shared secret key and said provided freshness token;
providing said copy of said session key to said second network element; and,
said first network element and said second network element securely communicating based on said session key and said copy of said session key.
3. The method according to claim 1, wherein said session key providing step comprises the step of securely providing said session key to said first network element and said session key copy providing step comprises the step of securely providing said copy of said session key to said second network element.
4. The method according to claim 1, wherein said freshness token comprises a random challenge and said method further comprises the steps of:
said first cryptographic means generating an expected response based on said shared secret key and said random challenge;
providing said expected response to said first network element;
said second cryptographic means generating a response based on said shared secret key and said provided random challenge;
providing said response to said first network element; and,
said first network element authenticating said second network element based on a comparison between said expected response and said response.
5. The method according to claim 4, wherein said first cryptographic means comprises an Authentication and Key Agreement (AKA) algorithm for generating said random challenge, said expected response and said session key, and said second cryptographic means comprises an AKA algorithm for generating said response and said copy of said session key.
6. The method according to claim 1, further comprising the steps of:
said first network element providing an identifier associated with said second network domain to said first cryptographic means; and,
said second network element providing an identifier associated with said first network domain to said second cryptographic means.
7. The method according to claim 6, wherein said session key and said copy of said session key are generated based on at least one of said identifier associated with said first network domain and said identifier associated with said second network domain.
8. The method according to claim 6, further comprising the steps of:
said first cryptographic means identifying said shared secret key based on said identifier associated with said second network domain; and,
said second cryptographic means identifying said shared secret key based on said identifier associated with said first network domain.
9. The method according to claim 1, wherein said first cryptographic means is an Authentication, Authorization and Accounting (AAA) server provided in a network node of said first network domain and said second cryptographic means is an AAA server provided in a network node of said second network domain.
10. The method according to claim 1, wherein said first network domain shares a second secret key with a third network domain comprising third cryptographic means and at least a third network element.
11. The method according to claim 1, wherein said first network domain is managed by a first communications network operator and said second network domain is managed by a second different communications network operator.
12. The method according to claim 1, further comprising the step of intermittently replacing said shared secret by a new shared secret by basing a key agreement between said first network domain and said second network domain on said shared secret.
13. A system of establishing a session key shared between a first network element of a first network domain and a second network element of a second network domain, said first network domain sharing a secret key with said second network domain, wherein said first network domain comprises:
first cryptographic means for generating a freshness token and for generating a session key based on said shared secret key and said generated freshness token;
means for providing said session key from said first cryptographic means to said first network element; and,
means for providing said freshness token to said second network domain; wherein said second network domain comprises:
second cryptographic means for generating a copy of said session key based on said shared secret key and said provided freshness token; and,
means for providing said copy of said session key from said second cryptographic means to said second network element.
14. A system of enabling secure communication between a first network element of a first network domain and a second network element of a second network domain, said first network domain sharing a secret key with said second network domain, wherein said first network domain comprises:
first cryptographic means for generating a freshness token and for generating a session key based on said shared secret key and said generated freshness token;
means for providing said session key from said first cryptographic means to said first network element; and,
means for providing said freshness token to said second network domain; said second network domain comprises:
second cryptographic means for generating a copy of said session key based on said shared secret key and said provided freshness token; and,
means for providing said copy of said session key from said second cryptographic means to said second network element, said first network element comprises means for conducting secure communication with said second network element based said session key and said second network element comprises means for conducting secure communication with said first network element based on said copy of said session key.
15. The system according to claim 13, wherein said session key providing means is adapted for securely providing said session key from said first cryptographic means to said first network element and said session key copy providing means is adapted for securely providing said copy of said session key from said second cryptographic means to said second network element.
16. The system according to claim 13, wherein said freshness token comprises a random challenge and said first cryptographic means comprises means for generating an expected response based on said shared secret key and said random challenge and said second cryptographic means comprises means for generating a response based on said shared secret key and said random challenge, said first network domain comprises means for providing said expected response to said first network element and said second network domain comprises means for providing said response to said first network element, wherein said first network element comprises means for authenticating said second network element based on a comparison between said expected response and said response.
17. The system according to claim 16, wherein said first cryptographic means comprises an Authentication and Key Agreement (AKA) algorithm for generating said random challenge, said expected response and said session key, and said second cryptographic means comprises an AKA algorithm for generating said response and said copy of said session key.
18. The system according to claim 13, wherein said first cryptographic means is an Authentication, Authorization and Accounting (AAA) server provided in a network node of said first network domain and said second cryptographic means is an AAA server provided in a network node of said second network domain.
19. The system according to claim 13, further comprising a third network domain with third cryptographic means and at least a third network element, said first network domain and said third network domain share a second secret key.
20. The system according to claim 13, wherein said first network domain is managed by a first communications network operator and said second network domain is managed by a second different communications network operator.
21. The system according to claim 13, further comprising means for intermittently replacing said shared secret by a new shared secret, said shared secret replacing means is adapted for replacing said shared secret based on a key agreement between said first network domain and said second network domain using said shared secret.
22. A network domain comprising:
a first network element adapted for communication with a second network element of an external network domain, wherein said network domain and said external network domain sharing a secret key;
cryptographic means for generating a freshness token and for generating a session key based on said shared secret key and said generated freshness token;
means for providing said session key from said cryptographic means to said first network element; and,
means for providing said freshness token to said external network domain, wherein said external network domain comprises means for generating a copy of said session key for said second network element based on said shared secret key and said provided freshness token.
23. The network domain according to claim 22, wherein said session key providing means is adapted for securely providing said session key from said cryptographic means to said first network element.
24. The network domain according to claim 22, wherein said freshness token comprises a random challenge and said cryptographic means comprises means for generating an expected response based on said shared secret key and said random challenge and said external network domain comprises means for generating a response based on said shared secret key and said random challenge, said network domain comprises means for providing said expected response to said first network element and said external network domain comprises means for providing said response to said first network element, wherein said first network element comprises means for authenticating said second network element based on a comparison between said expected response and said response.
25. The network domain according to claim 22, wherein said cryptographic means is an Authentication, Authorization and Accounting (AAA) server provided in a network node of said network domain.
26. A network domain comprising:
a first network element adapted for communication with a second network element of an external network domain, wherein said network domain and said external network domain sharing a secret key;
cryptographic means for generating a session key based on said shared secret key and a freshness token provided from said external network domain; and,
means for providing said session key from said cryptographic means to said first network element, wherein said external network domain comprises means for generating said freshness token and for generating a copy of said session key for said second network element based on said shared secret key and said generated freshness token.
27. The network domain according to claim 26, wherein said session key providing means is adapted for securely providing said session key from said cryptographic means to said first network element.
28. The network domain according to claim 26, wherein said freshness token comprises a random challenge and said cryptographic means comprises means for generating a response based on said shared secret key and said random challenge and said external network domain comprises means for generating an expected response based on said shared secret key and said random challenge and means for providing said expected response to said second network element, said network domain comprises means for providing said response to said second network element, wherein said response and said expected response enables said second network element to authenticate said first network element.
29. The network domain according to claim 26, wherein said cryptographic means is an Authentication, Authorization and Accounting (AAA) server provided in a network node of said network domain.
US10/597,864 2004-02-11 2004-02-11 Key management for network elements Active 2027-11-27 US7987366B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SE2004/000179 WO2005078988A1 (en) 2004-02-11 2004-02-11 Key management for network elements

Publications (2)

Publication Number Publication Date
US20070160201A1 US20070160201A1 (en) 2007-07-12
US7987366B2 true US7987366B2 (en) 2011-07-26

Family

ID=34859372

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/597,864 Active 2027-11-27 US7987366B2 (en) 2004-02-11 2004-02-11 Key management for network elements

Country Status (6)

Country Link
US (1) US7987366B2 (en)
EP (1) EP1714418B1 (en)
CN (1) CN100592678C (en)
DK (1) DK1714418T3 (en)
HK (1) HK1101624A1 (en)
WO (1) WO2005078988A1 (en)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090013381A1 (en) * 2005-01-28 2009-01-08 Telefonaktiebolaget Lm Ericsson (Publ) User Authentication and Authorisation in a Communications System
US20090240941A1 (en) * 2006-06-29 2009-09-24 Electronics And Telecommunications Research Institute Method and apparatus for authenticating device in multi domain home network environment
US20090279705A1 (en) * 2007-01-23 2009-11-12 Huawei Technologies Co.,Ltd. Method and system for distributing key of media stream
US20090285398A1 (en) * 2008-05-16 2009-11-19 Stmicroelectronics (Rousset) Sas Verification of the integrity of a ciphering key
US20100111308A1 (en) * 2007-03-21 2010-05-06 Nokia Siemens Networks Gmbh & Co. Kg Key handling in communication systems
US20100268937A1 (en) * 2007-11-30 2010-10-21 Telefonaktiebolaget L M Ericsson (Publ) Key management for secure communication
US20110107085A1 (en) * 2009-10-30 2011-05-05 Mizikovsky Semyon B Authenticator relocation method for wimax system
US20110206206A1 (en) * 2008-09-16 2011-08-25 Telefonaktiebolaget Lm Ericsson (Publ) Key Management in a Communication Network
US20110258448A1 (en) * 2005-11-03 2011-10-20 Jesse Walker Method and system of secured direct link set-up (dls) for wireless networks
US20130283362A1 (en) * 2012-04-19 2013-10-24 Microsoft Corporation Authenticating user through web extension using token based authentication scheme
US8769627B1 (en) * 2011-12-08 2014-07-01 Symantec Corporation Systems and methods for validating ownership of deduplicated data
US8886930B1 (en) * 2008-01-22 2014-11-11 F5 Networks, Inc. DNS flood protection platform for a network

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8229118B2 (en) * 2003-11-07 2012-07-24 Qualcomm Incorporated Method and apparatus for authentication in wireless communications
US8230058B2 (en) * 2004-03-29 2012-07-24 Verizon Business Global Llc Health reporting mechanism for inter-network gateway
WO2004100496A2 (en) * 2004-09-02 2004-11-18 Pisaramedia Oy Ends - messaging protocol that recovers and has backward security
CN100574185C (en) 2005-01-07 2009-12-23 华为技术有限公司 Method for ensuring media stream safety in IP multimedia service subsystem network
US20070050630A1 (en) * 2005-08-24 2007-03-01 Samsung Electronics Co., Ltd. Authentication method and system for asynchronous eventing over the internet
GB0517592D0 (en) * 2005-08-25 2005-10-05 Vodafone Plc Data transmission
US7916869B2 (en) * 2005-09-01 2011-03-29 Sharp Laboratories Of America, Inc. System and method for automatic setup of a network device with secure network transmission of setup parameters using a standard remote control
US7609837B2 (en) * 2005-09-01 2009-10-27 Sharp Laboratories Of America, Inc. System and method for automatic setup of a network device with secure network transmission of setup parameters
KR100834629B1 (en) * 2005-11-14 2008-06-02 삼성전자주식회사 System and method of providing based service on internet protocol classified in a communication system
US7747540B2 (en) 2006-02-24 2010-06-29 Microsoft Corporation Account linking with privacy keys
JP4810379B2 (en) * 2006-09-22 2011-11-09 キヤノン株式会社 Communication system, terminal station, communication method and program
KR101351110B1 (en) 2007-08-24 2014-01-16 한국과학기술원 Apparatus and method of transmitting/receiving encrypted data in a communication system
GB0801408D0 (en) * 2008-01-25 2008-03-05 Qinetiq Ltd Multi-community network with quantum key distribution
GB0801395D0 (en) 2008-01-25 2008-03-05 Qinetiq Ltd Network having quantum key distribution
JP5631743B2 (en) * 2008-01-25 2014-11-26 キネテイツク・リミテツド Quantum cryptography equipment
GB0801492D0 (en) * 2008-01-28 2008-03-05 Qinetiq Ltd Optical transmitters and receivers for quantum key distribution
US8533474B2 (en) * 2008-02-27 2013-09-10 Red Hat, Inc. Generating session keys
GB0809038D0 (en) * 2008-05-19 2008-06-25 Qinetiq Ltd Quantum key device
GB0809045D0 (en) * 2008-05-19 2008-06-25 Qinetiq Ltd Quantum key distribution involving moveable key device
GB0809044D0 (en) * 2008-05-19 2008-06-25 Qinetiq Ltd Multiplexed QKD
GB0819665D0 (en) * 2008-10-27 2008-12-03 Qinetiq Ltd Quantum key dsitribution
GB0822254D0 (en) * 2008-12-05 2009-01-14 Qinetiq Ltd Method of performing authentication between network nodes
GB0822253D0 (en) * 2008-12-05 2009-01-14 Qinetiq Ltd Method of establishing a quantum key for use between network nodes
GB0822356D0 (en) * 2008-12-08 2009-01-14 Qinetiq Ltd Non-linear optical device
US8352741B2 (en) * 2009-06-11 2013-01-08 Microsoft Corporation Discovery of secure network enclaves
US9742560B2 (en) 2009-06-11 2017-08-22 Microsoft Technology Licensing, Llc Key management in secure network enclaves
GB0917060D0 (en) 2009-09-29 2009-11-11 Qinetiq Ltd Methods and apparatus for use in quantum key distribution
US9525999B2 (en) * 2009-12-21 2016-12-20 Blackberry Limited Method of securely transferring services between mobile devices
US8929543B2 (en) * 2010-03-17 2015-01-06 Telefonaktiebolaget L M Ericsson (Publ) Enhanced key management for SRNS relocation
US8650639B2 (en) * 2010-09-29 2014-02-11 Blackberry Limited System and method for hindering a cold boot attack
US8711843B2 (en) * 2010-10-29 2014-04-29 Telefonaktiebolaget Lm Ericsson (Publ) Cryptographically generated addresses using backward key chain for secure route optimization in mobile internet protocol
GB201020424D0 (en) 2010-12-02 2011-01-19 Qinetiq Ltd Quantum key distribution
US9264230B2 (en) 2011-03-14 2016-02-16 International Business Machines Corporation Secure key management
US8619990B2 (en) 2011-04-27 2013-12-31 International Business Machines Corporation Secure key creation
US8789210B2 (en) 2011-05-04 2014-07-22 International Business Machines Corporation Key usage policies for cryptographic keys
US8634561B2 (en) * 2011-05-04 2014-01-21 International Business Machines Corporation Secure key management
US8566913B2 (en) 2011-05-04 2013-10-22 International Business Machines Corporation Secure key management
US8755527B2 (en) 2011-05-04 2014-06-17 International Business Machines Corporation Key management policies for cryptographic keys
WO2013121246A1 (en) * 2012-02-14 2013-08-22 Nokia Corporation Device to device security using naf key
EP2874421A1 (en) * 2013-11-13 2015-05-20 Gemalto SA System and method for securing communications between a card reader device and a remote server
CN105141568B (en) * 2014-05-28 2019-02-12 腾讯科技(深圳)有限公司 Secured communication channel method for building up and system, client and server
US9998431B2 (en) * 2015-06-09 2018-06-12 Intel Corporation System, apparatus and method for secure network bridging using a rendezvous service and multiple key distribution servers
US10164710B2 (en) 2016-10-24 2018-12-25 Nokia Of America Corporation Optical transceiver for secure data transmission

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5604807A (en) * 1993-10-06 1997-02-18 Nippon Telegraph And Telephone Corporation System and scheme of cipher communication
US5638444A (en) 1995-06-02 1997-06-10 Software Security, Inc. Secure computer communication method and system
US6336188B2 (en) 1998-05-01 2002-01-01 Certicom Corp. Authenticated key agreement protocol
US20030081774A1 (en) * 2001-10-26 2003-05-01 Paul Lin Method and apparatus for dynamic generation of symmetric encryption keys and exchange of dynamic symmetric key infrastructure
US20040064706A1 (en) * 2002-09-30 2004-04-01 Paul Lin System and method for controlling access to multiple public networks and for controlling access to multiple private networks
US20040153555A1 (en) * 2002-10-03 2004-08-05 Henry Haverinen Method and apparatus enabling reauthentication in a cellular communication system
US20070088950A1 (en) * 1998-11-09 2007-04-19 First Data Corporation Account-based digital signature (abds) system using biometrics
US20070094503A1 (en) * 2005-10-21 2007-04-26 Novell, Inc. Techniques for key distribution for use in encrypted communications
US7243366B2 (en) * 2001-11-15 2007-07-10 General Instrument Corporation Key management protocol and authentication system for secure internet protocol rights management architecture
US7549048B2 (en) * 2004-03-19 2009-06-16 Microsoft Corporation Efficient and secure authentication of computing systems
US20090292914A1 (en) * 2007-02-01 2009-11-26 Huawei Technologies Co., Ltd. Nodes and systems and methods for distributing group key control message

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4833489B2 (en) 2000-06-05 2011-12-07 フィーニックス  テクノロジーズ  リミテッド System, method and software for remote password authentication using multiple servers

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5604807A (en) * 1993-10-06 1997-02-18 Nippon Telegraph And Telephone Corporation System and scheme of cipher communication
US5638444A (en) 1995-06-02 1997-06-10 Software Security, Inc. Secure computer communication method and system
US6336188B2 (en) 1998-05-01 2002-01-01 Certicom Corp. Authenticated key agreement protocol
US20070088950A1 (en) * 1998-11-09 2007-04-19 First Data Corporation Account-based digital signature (abds) system using biometrics
US20030081774A1 (en) * 2001-10-26 2003-05-01 Paul Lin Method and apparatus for dynamic generation of symmetric encryption keys and exchange of dynamic symmetric key infrastructure
US20100195824A1 (en) * 2001-10-26 2010-08-05 Authenex, Inc. Method and Apparatus for Dynamic Generation of Symmetric Encryption Keys and Exchange of Dynamic Symmetric Key Infrastructure
US7243366B2 (en) * 2001-11-15 2007-07-10 General Instrument Corporation Key management protocol and authentication system for secure internet protocol rights management architecture
US20040064706A1 (en) * 2002-09-30 2004-04-01 Paul Lin System and method for controlling access to multiple public networks and for controlling access to multiple private networks
US20040153555A1 (en) * 2002-10-03 2004-08-05 Henry Haverinen Method and apparatus enabling reauthentication in a cellular communication system
US7549048B2 (en) * 2004-03-19 2009-06-16 Microsoft Corporation Efficient and secure authentication of computing systems
US20070094503A1 (en) * 2005-10-21 2007-04-26 Novell, Inc. Techniques for key distribution for use in encrypted communications
US20090292914A1 (en) * 2007-02-01 2009-11-26 Huawei Technologies Co., Ltd. Nodes and systems and methods for distributing group key control message

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8555345B2 (en) * 2005-01-28 2013-10-08 Telefonaktiebolaget Lm Ericsson (Publ) User authentication and authorisation in a communications system
US20090013381A1 (en) * 2005-01-28 2009-01-08 Telefonaktiebolaget Lm Ericsson (Publ) User Authentication and Authorisation in a Communications System
US20110258448A1 (en) * 2005-11-03 2011-10-20 Jesse Walker Method and system of secured direct link set-up (dls) for wireless networks
US9380457B2 (en) * 2005-11-03 2016-06-28 Intel Corporation Method and system of secured direct link set-up (DLS) for wireless networks
US20090240941A1 (en) * 2006-06-29 2009-09-24 Electronics And Telecommunications Research Institute Method and apparatus for authenticating device in multi domain home network environment
US8204229B2 (en) * 2007-01-23 2012-06-19 Huawei Technologies Co., Ltd. Method and system for distributing key of media stream
US20090279705A1 (en) * 2007-01-23 2009-11-12 Huawei Technologies Co.,Ltd. Method and system for distributing key of media stream
US9344411B2 (en) * 2007-03-21 2016-05-17 Nokia Solutions And Networks Gmbh & Co. Kg Key handling in communication systems
US20100111308A1 (en) * 2007-03-21 2010-05-06 Nokia Siemens Networks Gmbh & Co. Kg Key handling in communication systems
US20100268937A1 (en) * 2007-11-30 2010-10-21 Telefonaktiebolaget L M Ericsson (Publ) Key management for secure communication
US9628271B2 (en) * 2007-11-30 2017-04-18 Telefonaktiebolaget Lm Ericsson (Publ) Key management for secure communication
US9178696B2 (en) * 2007-11-30 2015-11-03 Telefonaktiebolaget L M Ericsson (Publ) Key management for secure communication
US20160056959A1 (en) * 2007-11-30 2016-02-25 Telefonaktiebolaget L M Ericsson (Publ) Key Management For Secure Communication
US8886930B1 (en) * 2008-01-22 2014-11-11 F5 Networks, Inc. DNS flood protection platform for a network
US20090285398A1 (en) * 2008-05-16 2009-11-19 Stmicroelectronics (Rousset) Sas Verification of the integrity of a ciphering key
US8848917B2 (en) * 2008-05-16 2014-09-30 Stmicroelectronics (Rousset) Sas Verification of the integrity of a ciphering key
US20110206206A1 (en) * 2008-09-16 2011-08-25 Telefonaktiebolaget Lm Ericsson (Publ) Key Management in a Communication Network
US8837737B2 (en) * 2008-09-16 2014-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Key management in a communication network
US9749318B2 (en) 2008-09-16 2017-08-29 Telefonaktiebolaget Lm Ericsson (Publ) Key management in a communication network
US8443431B2 (en) * 2009-10-30 2013-05-14 Alcatel Lucent Authenticator relocation method for WiMAX system
US20110107085A1 (en) * 2009-10-30 2011-05-05 Mizikovsky Semyon B Authenticator relocation method for wimax system
US8769627B1 (en) * 2011-12-08 2014-07-01 Symantec Corporation Systems and methods for validating ownership of deduplicated data
US8898764B2 (en) * 2012-04-19 2014-11-25 Microsoft Corporation Authenticating user through web extension using token based authentication scheme
US20130283362A1 (en) * 2012-04-19 2013-10-24 Microsoft Corporation Authenticating user through web extension using token based authentication scheme

Also Published As

Publication number Publication date
EP1714418A1 (en) 2006-10-25
CN1914848A (en) 2007-02-14
HK1101624A1 (en) 2010-11-05
EP1714418B1 (en) 2017-01-11
CN100592678C (en) 2010-02-24
US20070160201A1 (en) 2007-07-12
WO2005078988A1 (en) 2005-08-25
DK1714418T3 (en) 2017-04-24

Similar Documents

Publication Publication Date Title
Peyravian et al. Methods for protecting password transmission
JP5432156B2 (en) Secure communication method between UICC and terminal
ES2364574T3 (en) Safe initial sequence for wireless communications.
Weimerskirch et al. A distributed light-weight authentication model for ad-hoc networks
US7194765B2 (en) Challenge-response user authentication
EP1955511B1 (en) Method and system for automated and secure provisioning of service access credentials for on-line services
US8218773B2 (en) Systems and methods to securely generate shared keys
DE10307403B4 (en) Method for forming and distributing cryptographic keys in a mobile radio system and mobile radio system
US8413221B2 (en) Methods and apparatus for delegated authentication
EP1856836B1 (en) Network assisted terminal to sim/uicc key establishment
EP0651533B1 (en) Method and apparatus for privacy and authentication in a mobile wireless network
EP1949651B1 (en) Method and apparatus for establishing a security association
US7542569B1 (en) Security of data connections
JP4651197B2 (en) Certificate self-generation using a secure microprocessor in devices that transfer digital information
KR101266773B1 (en) Method for refreshing a pairwise master key
KR20100103721A (en) Method and system for mutual authentication of nodes in a wireless communication network
US8705743B2 (en) Communication security
US9590961B2 (en) Automated security provisioning protocol for wide area network communication devices in open device environment
US7707412B2 (en) Linked authentication protocols
JP4199074B2 (en) Method and apparatus for secure data communication link
US20100325435A1 (en) Two-factor authenticated key exchange method and authentication method using the same, and recording medium storing program including the same
EP1811744B1 (en) Method, system and centre for authenticating in End-to-End communications based on a mobile network
US20130191632A1 (en) System and method for securing private keys issued from distributed private key generator (d-pkg) nodes
KR100520116B1 (en) A method for discributing the key to mutual nodes to code a key on mobile ad-hoc network and network device using thereof
US20090019284A1 (en) Authentication method and key generating method in wireless portable internet system

Legal Events

Date Code Title Description
AS Assignment

Owner name: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL), SWEDEN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BLOM, ROLF;NASLUND, MATS;CARRARA, ELISABETTA;AND OTHERS;REEL/FRAME:019496/0030;SIGNING DATES FROM 20060720 TO 20060809

Owner name: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL), SWEDEN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BLOM, ROLF;NASLUND, MATS;CARRARA, ELISABETTA;AND OTHERS;SIGNING DATES FROM 20060720 TO 20060809;REEL/FRAME:019496/0030

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8