Key management for secure communication

IS 2 589 112 T3

DESCRIPTION

Key management for secure communication

Field of the invention

The invention is in the field of establishing secure communication between endpoints. In particular, the invention eliminates the requirement that both endpoints use the same type of basic credentials.

Background of the invention

Many access technologies such as GSM, WCDMA, WLAN, WiMAX provide basic first hop security, that is, communication between the user device and a network access point. Communication can use layer 2 or layer 3 of the protocol stack. SRTP (RFC3711) and MIKEY (RFC3830) are examples of protocols for media security and key management. MIKEY can be based on both pre-shared keys and PKI. Additionally, MIKEY can be integrated into a session setup signaling (SIP or RTSP) using RFC4567.

However, the basic security provided by these access technologies cannot always be considered secure enough. In fact, some access technologies do not provide any basic security, eg. eg 802.3 / Ethernet or DSL.

Therefore, there is a need to provide additional or improved security mechanisms in many access technologies.

One problem with existing approaches to key management concerns the assumption that both endpoints use the same type of basic credentials. However, this presumption is not always correct, as is the case in, p. For example, fixed-mobile convergence (FMC). At the FMC, one of the users can be a 3GPP subscriber using a SIM-based credential, eg. eg SIM, USIM, ISIM and the other can be eg. eg, a wired access user implementing PKI-based credentials.

There are also certain problems with integrating key management into known signaling protocols.

Another example presenting a problem concerns pre-media, which means that media can start to flow from the responder before key management operations have been completed according to, eg. eg MIKEY via SIP. Therefore, while MIKEY can be carried out in-band with SIP, there may be no key available to protect the first few packets. The alternative, using in-band media key management would solve this problem, but it is unfavorable, e.g. eg from the point of view of the transverse firewall. Furthermore, the transport of signaling on the media track does not coincide with the practice of sound engineering.

Another problem with known methods for key management concerns "fork", where the initiator, eg. For example, from a multimedia telephony call (MMTEL) you may not be sure which terminal the other endpoint will use to answer. Although all terminals to answer the call have a PKI enabled, different terminals may use different public keys and therefore the initiator may not know which key to use for an invitation request. More precisely, according to known methods, key management cannot be started until the responder has answered and neither can a suitable public key be determined until then. As mentioned above, in-band media key management can alleviate the problem, but it is unfavorable, as already mentioned.

Yet another problem with known key management methods is that some IMS services are peer-to-peer (P2P) while others provide group services, eg. eg, press and talk on cell phone (PoC). Requiring users to manage group passwords creates problems and, in fact, a user cannot even be sure that all members of the group respond to an invitation and participate in the session. Therefore, in this case, it is necessary to make a distinction between members who could be in a group session and the members who participate in the group session, since, p. For example, it may be beneficial to distribute session keys only to members who actually participate.

An additional problem with the prior art is that some services, eg. For example, messaging, they can be handled in different ways, depending on whether the responder is online or not. For example, an instant message (IM) can automatically be converted to a deferred message (DM) for later delivery if the user is not online. The sender may not know if the other party is online and therefore may not know which key management is appropriate when sending the message. S / MIME-based solutions could alleviate the situation, but S / MIME is not suitable for real-time media such as MMTEL. Therefore, the key management approach can become dependent on the IMS service being used, which is undesirable. Also, S / MIME lacks support for pre-shared keys (eg SIM) and does not provide protection against replay due to the fact that there is no

ES 2 589 112 T3 session concept in which two S / MIME protected messages can be correlated.

US-2007/0101122-A1 describes an approach for the generation of application session keys within a secure module of a user terminal. The Generic Boot Architecture (GBA) is described in 3GPP2.

WO-2005/078988 describes the establishment of a shared secret session key between two network elements, ie non-user terminals, for secure communication with each other.

Compendium

A general objective of the invention is to overcome the shortcomings of known methods of establishing secure communication between an initiating party and a responding party by establishing shared keys between endpoints that could be used directly for media protection or form the foundation of end-to-end key establishment.

It is an object to establish keys for secure communication between the initiating and responding party that provide independence of the type of credentials used by the respective party for security management.

According to the invention, a key management server, KMS, with the ability to establish a shared key with a user device, provides the user with a key generation entry and information in response to a request. key. Having received said information, a first user calculates a session key and transmits the entry to a second party in a communication request. In response to receipt of the voucher, the second party establishes secure communication with the same or other KMS entity and provides the voucher. In response to this, the same KMS or another returns key generation information. Based on said key generation information, both the first and second parties generate a common session key.

The integrity of the entry is favorably protected by the issuing KMS entity and may also include metadata, for example, stakeholder identities, creation time, sequence number, validity time, type of use, such as press and talk on cell phone or telephone, type of communication, p. eg, peer-to-peer or group communication. In addition, the seat can include copies of session keys and other information that requires encryption, for example to protect privacy.

In one embodiment of the invention, the ability to establish a shared key is based on the GBA procedure where a network and user BSF functionality are provided with a basic shared secret, e.g. eg, a secret based on SIM / USIM / ISIM. The KMS entity, according to this embodiment, acts as a NAF entity towards the BSF entity.

According to another embodiment, the session keys generated by the respective first and second parties are different, and through these an intermediary party is arranged to generate both keys for secure communication with each of the first and second parties, where the intermediary party is able to process a message from the first to the second part, first, by decoding the message and, after processing, re-encrypting the message. In particular, the generation of keys in the intermediary party is based on an entry received from the first party which, after the generation of the key, is forwarded to the second party for a corresponding generation of a session key.

In still another embodiment, the second party is represented by a group of second parties and the intermediary party, by using an entry, first generates a master key and, based on the master key, generates individual session keys and entries. for each member of the second-party group. The intermediary party, after generating the key, forwards the entry to each of the second parties, and each of them then generates corresponding individual session keys. The second party group can be obtained in the intermediate party by resolving a group identity or identifying a predefined group as specified by the first party.

In yet another embodiment, the intermediary party does not process information received from the first party and therefore does not need to generate separate keys for communication with each of the first and second parties. In this embodiment, the intermediary party forwards the entry received from the first party to each of the second parties in the group, whereby the first and each of the second parties can generate a shared session key for secure endpoint communication. to extreme. In order to eliminate the possibility of intercepting the entry in an intermediary party and using the intercepted entry to request a KMS functionality to resolve the entry into a session key, the KMS entity is provided with a functionality to verify that a user , for which an entry is resolved, is a member of the group.

A first party message destined for a second party can be stored on a network entity for deferred delivery. For example, the intermediary party may discover that at least a second party is not registered with the network and may therefore store a message for later delivery, along with an entry.

ES 2 589 112 T3

Once the at least one second party is registered, the network entity temporarily storing a message can continue the protocol as described above and finally push the message and associated entry towards the recipient party.

According to one embodiment, the invention is implemented in an IMS 3GPP environment.

According to one aspect, a method is provided for establishing secure communication between parts of a communication network, in which each part is capable of performing a startup procedure based on local credentials, where the startup creates a shared key between each party. and an associated boot function. The method comprises the stages of:

- receiving at the initiating party the first key information, based on an initial startup procedure, and an entry in response to the request for a first key management functionality;

- storing said first key information in said first key management functionality and referring to said first key information with an identifier included in said entry;

- generating, from the first key information, the first session key;

- send the entry to at least one responding party;

- forwarding from the at least one responding party the entry or parts thereof to the second key management functionality;

- communicating to the second key management functionality with the first key management functionality to resolve the entry in the second key information, wherein said communication includes retrieving, in the first key management functionality, the first key information by using the identifier, and providing the second key management functionality with information based on the first key information;

- receiving in the at least one responding party, from the second key management functionality, a second key information, and generating from this a second session key;

- the use, of the sending party and at least one responding party, of the first and second session keys for secure communication.

According to another aspect of the invention, a key management apparatus is provided. The key management apparatus supports the generation of session keys for secure communication between parts of a communication network. The apparatus has processing means and comprises:

- means for generating a first key information and an entry in response to a request from a first party, where the first key information is referred to by an identifier included in the entry;

- means for the communication of the entry to the first party,

- means for storing the first key information and the identifier,

- means for communicating with a second key management apparatus to resolve a received entry in a second key management information, wherein said communication includes retrieving the first key information through the use of the identifier, and providing the second management functionality key information based on the first key information.

Detailed description.

The following description sets out specific details, such as embodiments, procedures, techniques, etc. particular, for explanatory and non-exhaustive purposes. In some instances, detailed descriptions of known methods, interfaces, circuits, and devices are omitted so as not to complicate the description with unnecessary detail. Additionally, individual blocks are shown in some of the drawings. It will be seen that the functions of such blocks can be implemented through the use of individual hardware circuits, through the use of software and data programs, in conjunction with a suitably programmed digital microprocessor or general purpose computer, through the use of integrated circuits. specific to the application and / or through the use of one or more digital signal processors.

For the purpose of illustrating security key management, the 3GPP GBA / GAA architecture is used. However, it is readily appreciated from the description that any other method for managing security keys may be used that provides for the generation of a shared key between a user UE and an application server, e.g. eg, NAF 160. For example, a UE that supports PKI-based credentials could use TLS to create a shared key with the application server. In an architecture based on the name of

ES 2 589 112 T3 username / password, PKCS # 5 standard could be used to set shared key etc.

Figure 1 illustrates the deployment of the prior art of GBA / GAA through an authentication proxy 160 that acts as a network application function nAf (for its acronym in English) against the GBA / GAA infrastructure. A generic boot server function 110 BSF and user equipment 101 UE authenticate manually using the UMTS AKA protocol. The UE communicates with the BSF through an interface 120 Ub. The UE and a home subscriber system 130 (HSS) share a key that is the basis of the HSS for generating an authentication vector provided to the BSF through the interface 170 Zh. According to the AKA protocol, the BSF sends the UE a challenge and the UE returns a response to the BSF. Authentication is verified by the BSF's comparison of the UE's response with an expected response provided by the HSS. A successful authentication is initiated in the BSF and a shared key Ks is generated in the UE. The BSF stores the key Ks and the associated reference B-TID. The reference B-TID and other data, such as the lifetime of the key, are then provided to the UE in a termination message. The BSF performs a query on the subscriber locator function 140 SLF via interface 191 Dz together with the operation of interface Zh to obtain the name of the HSS containing the specific data required from the subscriber. . The UE can simultaneously connect to at least one application server As 150_n through an authentication proxy of the network application function NAF 160. The connection comprises a first authentication stage between the UE and the NAF. Therefore, the UE provides the reference B-TID to the NAF which, using the B-TID, requests a key (Ks_NAF) from the BSF through the 190 Zn interface. The Ks_NAF key is derived from the Ks key. The same key can be derived in the UE. Authentication then occurs, based on the derived key Ks_NAF. Communication between the UE and the NAF is through a Ua 180 interface.

For illustrative purposes, a SIP-based signaling according to 3GPP IMS is used in the following description. However, as understood by the person skilled in the art, the invention may use other protocols that are capable of loading metadata necessary for the configuration of the session.

Figure 2 illustrates basic elements of an IMS CN backbone network subsystem and connection to application server 210. While Figure 2 indicates an application server located within a home network, it must It is understood that the service platform can also be located outside the home network.

The IP Multimedia Core Network (IM CN) ​​subsystem enables fixed line and PLMN operators to offer their subscribers multimedia services based and built on internet services, protocols and applications. These services are intended to be developed by PLMN operators and other third-party providers, including those in the Internet space that use the mechanisms provided by the Internet and the IMS system. The IMS system enables the convergence of, and access to, web-based and data, messaging, video, and voice technologies for the wireless and landline user.

The Proxy-CSCF (P-CSCF) 220 is the first point of contact within the IMS system that responds to the SIP INVITE message from the UE. Your address can be discovered by the UE 101 through the use of a discovery mechanism. The P-CSCF behaves like a Proxy, that is, it accepts requests and reviews them internally or forwards them to the CSCF server, S-CSCF 230. The S-CSCF routes the SIP request to the application server of home network 210.

A first embodiment is described below with reference to Figure 3. In Figure 3, similar numbers correspond to the entities of Figures 1 and 2. Two user entities UE_A and UE_B are shown in Figure 3 capable of performing a GBA / GAA boot with respective boot functions BSF_A, 110_A and BSF_B 110_B. However, as understood by the person skilled in the art, any other available means can be used for creating a shared key with such a server. Therefore, the boot can be based on an identification credential, e.g. eg SIM, USIM, ISIM or PKI, or username / password. The boot causes each UE and associated BSF to determine a shared key Ks_A, respectively Ks_B. Users A and B wish to establish a communication illustrated at 320. According to the invention, a key management server KMS_A and KMS_B, indicated by 310_A and 310_B, respectively, supports each UE.

According to the invention, users A and B can base their respective security management on different credentials, e.g. eg based on an identity card such as a * SIM card (SIM, USIM, ISIM), username / password, PKI public key or password.

Inter-domain network signaling between KMS key management entities, indicated at 330, can be ensured by using eg. eg TLS or IPsec. The signaling can be encrypted and / or it can have integrity protection.

The usual GBA / GAA interfaces Ua, Ub, Zn are indicated in Figure 3 which corresponds to Figure 1.

Reference is now made to Figure 4, which shows a signal diagram according to one embodiment of the invention. In Figure 4, the entities of the IMS structure and the GBA / GAA structure are indicated as explained with respect to Figures 1-3. For the sake of simplicity, user A is also denoted UE_A interchangeably.

ES 2 589 112 T3

Hereinafter, (x) k denotes the protection of x by the key K. By protection is meant protection of integrity and / or confidentiality, and such protection of confidentiality may apply only to parts of a message x.

Steps 1 and 2 are now performed according to the prior technique.

In step 1, user A registers with IMS.

In step 2, user A performs a GBA boot, whereby a key Ks_A is generated and shared between A and BSF_A. At this stage, BSF_A provides A with a reference B-TID_A. Stage 2 includes sub-stage 2: 1 in which KMS_A receives from A the reference B-TID which is then used to capture from BSF_A a key KA = Ks_KMS_A derived from Ks_A. User A calculates the same key knowing Ks_A and other information entered in the derivation. Therefore, A and KMS_A share a KA key that can be used for secure communication.

Corresponding steps are performed on the B-side indicated in Figure 4 with the same reference numerals, where the corresponding entities are generated, that is, Ks_B, B-TID_B and KB = Ks_KMS_B.

It should be noted that B, as a user, can have multiple devices, each of which can be used for communication. However, the KB key is valid only for a particular device that booted according to steps 1 and 2. The case that B can use multiple devices can lead to a branching problem that is further addressed in an alternative embodiment. For the present first embodiment, it is assumed that B responds to a communication invitation by using a single device.

In 3, user A decides to communicate with user B.

In step 4, A sends a key request to the key management server KMS_A according to the invention. The key generated at this stage is used later for secure end-to-end communication with B. The key request has the format:

GET key info = (ld_A, ld_B, key_type, param .....) ka, B-TID_A

Where Id_A and Id_B are entities that identify users A and B respectively, key_type is the type of key requested, eg. eg, a key for point-to-point communication or a key for group communication. Id_A can be in the form of a global identifier, for example Id_A = A®op.com. Finally, param denotes any other parameter that can be included in the message. The message is encrypted using the previously generated KA key. In addition, the reference B-TID is included in the message, allowing KMS_A to obtain the KA key from BSF_A according to the GBA / GAA procedure. Alternatively, in a non-GBA-based approach to boot, some other key identifier could be used if Id_A does not uniquely determine the KA key. It should be noted that nothing is mentioned here about the type of credential used by receiver B and therefore the method according to the invention does not depend on the type of credential at sender A or receiver B.

In 5, KMS_A responds to A with the message "RETURN key info" of the form:

RETURN key info = (Key_info_A, VOUCHER) ka

Where Key_info_A comprises a key Kab or key generation material that allows A to calculate, in step 6, a key Kab. The entity VOUCHER (seat), according to the invention, comprises information that enables KMS_B to subsequently regenerate the same key Kab that allows A and B to communicate securely. For KMS_B to know about KMS_A, the journal includes Id_A.

In addition, the integrity of the seat is protected and at least parts of it can be encrypted. For example, integrity and confidentiality keys can be derived from the KA key.

The key Kab, for example, can be generated as a cryptographic function of KA and the identities of A and B and / or a nonce. In this case, Key_info_A would contain said nonce. Alternatively, Kab can be a completely random key, in which case Key_info_A comprises the Kab key itself.

According to the present embodiment, the entry information includes a pointer, for example B-TID, for the retrieval of the Kab key or key material stored in KMS_A. Other information may be included in the entry, such as, eg. For example, key type information, such as peer or group communication, identity of the parties involved, issuer of the entry, that is, identity of KMS_A, time of issue or sequence number, validity time, type of use , such as pulse by cell phone (PoC) or multimedia telephony (MMTEL).

In step 7, A directs a SIP INVITE to user B which, according to the IMS infrastructure, passes P-CSCF, SCSCF serving A and arrives at S-CSCF serving B. In step 8, the invitation message is forwarded to user B. The invitation message includes at least the entry. Other information in this message may include key type information.

ES 2 589 112 T3

In step 9, user B forwards the entry in a GET key info message to KMS_B for regeneration, from this, of the Kab key, where the message, for example, has the form:

GET key info = VOUCHER, B-TID_B

Here, B-TID_B is the GBA / GAA reference to authenticate user B and set a KB key for secure communication between user B and KMS_B in the same way as mentioned above regarding step 4.

In stage 9: 1 the communication between KMS_A and KMS_B occurs, where KMS_A supports KMS_B in the generation of the Kab key. According to the first embodiment, the voucher includes a pointer generated by KMS_A in step 5 and enabling KMS_A to retrieve key material, the same that was returned in step 5 to user A. Said pointer can be included in a request for key communicated in stage 9: 1 in the form:

Here the pointer is pulled from the seat in KMS_B and used to retrieve key material in KMS_A. Id_B is an identifier of user B. The inclusion of Id_B in the key request, through KMS_B, allows KMS_A to determine that it is the desired user B who requests a key, that is, that no one else intercepted the entry in order to obtain a key for secure communication with user A, pretending to be user B.

In response to the key request, KMS_A returns the key information Key_info_B comprising the key Kab or the key information which KMS_B then forwards in step 10 to user B for the generation of the key Kab in step 11. The key information from step 10 is encrypted using the key KB, for example, generated in step 9. If only key material is delivered in step 10, a key generation is performed in step 11 and a Kab key is generated.

Step 11 involves user B returning an OK response from SIP 200 to invite signal 7, after which he initiates the session between A and B.

Favorably, according to the first embodiment, the aforementioned pointer comprises the entity BTID_A.

If the key type information specifies peer-to-peer communication, the key that is returned to KMS_B in step 9: 1 is sufficient and no further key processing is necessary.

It is known from the GBA / GAA standard that the reference B-TID can have a shelf life. Therefore, in an alternative embodiment, the KMS_A maintains the state by storing at least one previously used B-TID and the corresponding key material in order to manage the case where user A has performed a new boot and generated a new B-TID.

With respect to Figure 5, a second embodiment is described with respect to the case where the key information (key info) indicates that a group key is requested. In Figure 5, a broker is inserted between sides A and B. Preferably, the broker is divided into a party A broker IM_A and a party B broker IM_B. For example, the respective part may comprise a cellular push-to-talk server, denoted PoC server. In Figure 5, the receiving party entry B now represents a group of users where each has an individual identity ID_Bk. Also, for the sake of simplicity, it is assumed that each user on the B side connects to the same BSF_B and the same KMS_B, although each user can use separate BSF and KMS functionalities.

In Figure 5, references to similar signals indicate similar signals in Figure 4, although the message parts of the signal may be slightly different, as explained in more detail below.

Steps 1,2, 2: 1 and 3 are identical to the corresponding steps according to the first embodiment, with the exception that in step 3, the so-called part B now represents an identified group with a group identity Gid.

In stage 4, the GET message now includes Gid. In step 5, a voucher and key material are returned, eg. eg, a master key K, for the generation, in step 6, of a session key Kima; alternatively, the session key is included in the returned message. It should be noted that said session key will later be used by A for communication with the intermediary, eg. eg IM_A, rather than directly with group participants. The master key and other information can be protected with the KA key generated in boot stages 2, 2: 1.

In step 7: 1, similar to step 7 of Figure 4, an INVITE message is sent to the group through the broker or, alternatively, to the IM_A part of the broker. The invitation message includes the seat and other information that includes at least Gid.

In step 8: 1, the broker IM_A, recognizing that ID_A of the entry is a group key, forwards the entry to KMS_A and requests key material, after which KMS_A returns to IM_A said master key K. Additionally, the key of Kima session is returned or generated in IM_A from the master key.

In step 8: 2, IM_A resolves the group identity provided in the invite message to a group of

ES 2 589 112 T3 user identities ID_Bk and generates, from the master key K, an individual session key Kimb for each member of the group. It is understood that an individual Kimb key is generated for each Bk. Also, if not received from KMS_A, the Kima session key is generated from the master key K. Note that the broker may require support from an associated group management server, not shown, to retrieve individual group members from the group ID.

The individual key Kimb can be calculated as Kimb = F (K, X) where X denotes some characteristic identifier of the part X that represents the group Bk.

The session keys Kima and Kimb are then used to protect the communication links A - broker, respectively, broker - B.

In step 7, the broker IM_A sends a SIP INVITE message to all members of the group including the seat. According to the IMS infrastructure, the message passes S-CSCF and then, in step 8, through P_CSCF to the network serving the receiver Bk. Message 7 corresponds to said message of Figure 4, although, in the present embodiment, the sender is the broker instead of user A.

In step 9, which corresponds to step 9 of Figure 4, each receiver Bk contacts a serving KMS_B to resolve the entry into appropriate keys.

In step 9: 1, similar to the first embodiment, a communication occurs between KMS_A and KMS_B, where KMS_A returns the key Kimb or, alternatively, the master key K, to KMS_B and from there it is forwarded, in the step 10, to each member of the group, protected with the key of the individual member of the group KBk indicated, for the sake of simplicity, as the key KB in Figure 5. Message 10 corresponds to the same message of Figure 4. It should be understood that step 10 is repeated for all members of group Bk. The KB keys are calculated corresponding to KA and it is assumed that each Bk carried out a boot with an associated BSF functionality. In the case where KMS_A returns the master key K, each Bk computes from the corresponding key Kimb.

In step 11 an OK signal 200 is returned in response to the respective invite signals 7: 1, 7 and 8, after which you can initiate the session between A - IM - Bk (k = 1, 2, ...) .

Now, A can communicate with the members of group Bk, after which A encrypts the communication by using the key Kima towards the broker, where the message is decoded and possibly processed, e.g. eg it is transcoded before it is forwarded, it is re-encrypted with the Kimb key, individually for all Bk's.

Alternatively, Kima = Kimb.

According to an alternative of the second embodiment, step 8: 1 does not include the Kima key and the master key K. Therefore, in this embodiment, the intermediary cannot decode the communication of the initiating party A for processing. Therefore, the re-writing stage of the communication with the Kimb key is not relevant. So the broker in this case basically acts to resolve a group identity to individual members of a responding group to provide an INVITE message to each member and subsequently to forward the communication from A to each Bk without any processing. back of the information.

An alternative of the second embodiment comprises calculating separate keys for an upper link, towards the intermediary, respectively a lower link, in the direction of the intermediary towards users A and B. Said master key K can be the basis for the generation of keys.

According to an alternative embodiment of the second embodiment, the key type indicates an ad hoc group key whereby, in step 8: 1, IM_A requests the key material K and generates, in step 8: 2, a group of user identities ID_Bk from the enumeration of the parts provided in the invitation message 7: 1 of A. Finally, IM_A generates, from the master key K, an individual key KBk for each member of the ad hoc group specified by user A.

According to yet another alternative of the second embodiment, each member of the group obtains an individual key that can also be different for an upper link, in the direction of user B towards the intermediary IM_A, and a lower link, in the direction of the intermediary IM_A to user B For example, IM_A can perform a key customization according to the scheme:

Here, Bk denotes some characteristic data for the individual Bk and K is the master key defined above. In order for each Bk to generate the same corresponding key, the invitation signal of steps 7 and 8 preferably includes the characteristic information Bk additionally included in the request message 10 to KMS_B, where, after this, customization is done. The custom key is finally provided to user Bk at token 10.

According to an alternative to the above embodiment, the broker communicates with the group of Bk via multicast. In this case, all Bk users should use the same group key to receive downlink information. Therefore, no downlink customization is done in this case and all

ES 2 589 112 T3 Bk users receive the same downlink key from KMS_A.

According to another alternative of the second embodiment, the intermediary is not included in the processing, e.g. e.g., transcoding, of user A's communication and thus not provided with an ability to decode the payload reported by user A. In this case, therefore, steps 8: 1 and 8 are skipped : 2 and, in steps 7 and 8, the entry is simply forwarded to the group identified by the broker IM_A by resolving the group identifier. The same key resolution mechanism of the first embodiment is then used on the receiver side. Effectively, this means that sides A and B communicate end-to-end without interference from the middle man.

A general problem may appear, p. For example, more likely in the case of multicast, an unauthorized user who has intercepted the signaling or intermediary link and obtained the seat could forward it to the kMs functionality and request that it be resolved. Therefore, preferably, the KMS functionality should be able to verify that the users for whom it resolves the entries are authorized members of the group. Therefore, according to this alternative embodiment, a unique random user identifier, or other unique identifier, is included in the SIP signaling of the broker with the node. Due to the protection of SIP signaling, the identifier is protected from an external party that gains access to the seat and identifier. The KMS functionality can verify that a random identifier was not already presented by some other user.

Alternatively, the identifier can also be entered in the key derivation for individual users.

According to the first and second embodiments, the key material obtained in the request signal 4 may include one or more Kab or Kima session keys. The one or more received session keys can be used directly or indirectly, eg. eg, by using the MIKEY protocol, to secure the upload data.

However, in an alternative to the first and second embodiments, the signal 5 may include one or more nonces from which the corresponding session keys may be derived, e.g. eg, from Ka = Ks_KMS_A. The transport of these nonces, p. For example, included in the seat, it does not need to be encrypted.

A problem can occur if user A disconnects or performs a new boot, whereby the old key KA = Ks_KMS_A may no longer be valid, as a KA 'key may be produced from the new boot. When KMS_A receives the voucher, the voucher information would not be useful in recreating the Kab or Kima session key.

Therefore, in an alternative to the first and second embodiments, KMS_A maintains the state and saves the previously used keys KA.

In yet another alternative, the journal entry may include a copy of the key KA, in a journal entry field protected by a key known only to KMS_A. In the latter case, only the secret keys need to be maintained and there is no need to maintain the individual user state using KMS_A.

According to another alternative of the first and second embodiments, the S-CSCF of stage 7 of Figures 4 and 5, can carry out stages 9 and 10 of Figures 4 and 5, on behalf of user B or, in the case of the group, each user Bk, and replace the entry with the key generation information and include it directly in the SIP message forwarded in step 8. Alternatively, step 8 is carried out by some other method, e.g. . eg, GBA insert, whereby S-CSCF terminates SIP signaling by sending signal 12.

In the particular case that either B or Bk can respond to the INVITE signal from SIP 8 on any of several available devices, some precautions should be taken. In this case, a responding device generated a particular key KB 'or KBk' from boot stages 1 and 2. Therefore, the S-CSCF, not knowing which device will be used to respond to the invitation message, must include all the possibilities when carrying out step 9 and repeat step 9 to generate all possible individual keys K'imb. Therefore, when the S-CSCF finally receives the response to the INVITE request from SIP 8, a suitable key K'imb is prepared and ready to be used in step 10.

It should be noted that the alternative embodiments described require a different trust model, in that the S-CSCF knows to trust the keys for the protection of the SIP center operator communication. However, this is normally a valid assumption.

Another alternative of the first and second embodiments refers to the messaging service, that is, the user A sends a message to B or to each of Bk in the case of the group. The message can be included in the invitation message 7 or 7: 1. If the S-CSCF determines that at least one recipient is not registered with the network, a message from A may be stored at a network node, for example, at network node S_CSCF, along with the seat, until it is registered as active receptor B or Bk. Then, when B registers with the network, the S-CSCF can go ahead with the protocol and insert the entry in B or Bk, for example by using GBA insert, and inform B or Bk where to find the message. This approach is generally valid for any service that can be treated as a deferred service. Since A may have been disconnected and / or restarted, they can be used

ES 2 589 112 T3 mechanisms similar to those mentioned above to verify that KMS_A is able to retrieve the correct key generation information.

While Figure 3 indicates specific interfaces between functionalities involved in the method according to the invention, it is readily understood that the interfaces can be arranged differently in various ways, e.g. eg, as indicated in Figure 6. In Figure 6, the interfaces T_A and T_B1 correspond to the known interface Ua according to the GBA method. The T_B2 interface is an alternative to T_B1, where user B communicates with KMS_A instead of KMS_B.

K_AB1 indicates an interface between the KMS functionalities required to resolve an entry.

K_AB2 is an inter-domain key management interface between the KMS in the domain of B and the BSF in the domain of A. KMS in the domain of B can use this interface to assist in resolving a journal entry in a key.

K_AB3 is an inter-domain key management interface between the KMS in the domain of A and the BSF in the domain of B.

It is readily understood that both the first and second embodiments provide lawful interception in the KMS functionality. An authority that knows the key KA can generate the session key Kab or, in the second embodiment, the key Kima, allowing the authority to intercept communication from A to B or the broker.

Illustrated in Figure 7 is an apparatus according to the invention that supports the generation of session keys for secure communication between parties in a communication network.

In Figure 7, at 710, an input / output unit is shown. The means 710 may communicate key information with other support units or end users, for example, receive from the end user a request for key information or an entry to resolve it into key information. Means 710 further provides communication with a support boot functionality to receive key material generated in a boot procedure.

Means 720 provides the generation of key information such as the derivation of key material from boot information, eg, received from boot functionality.

Means 730 processes a received entry to retrieve stored key information from storage 740. Means 730 may further resolve, possibly in communication with supporting network units, a user group identity to individual members of the group.

At 750, the general processing means provides the necessary control of the various processes.

The invention described by way of non-limiting example can be readily understood to provide numerous variations, e.g. eg, to implement functional entities, communication and signaling interfaces.