KR20080036731A - Method of bootstrapping for authenticated execution of application in mobile communication network - Google Patents

Abstract

A bootstrapping method for executing applications in mobile communication networks is provided to minimize a bootstrap delay time by executing query on VLR/SGSN having a short access time. A user terminal(100) requests authentication information from a bootstrap server(200). The bootstrap server requests authentication information from one of a VLR(Visitor Location Register) and a SGSN(Serving GPRS Support Node). The bootstrap server requests self-authentication by transmitting a part of the authentication information to the user terminal. According to the request of the user terminal where a first code key for user authentication is generated, the bootstrap server authenticates the user terminal. The bootstrap server generates a second code key to be supplied to an application server.

Description

Bootstrap method for application execution in mobile communication network {Method of bootstrapping for authenticated execution of application in mobile communication network}

1 is a simplified illustration of a conventional MBMS network model for performing bootstrap.

2 is a signal flow diagram sequentially illustrating a conventional bootstrap process.

3 is a block diagram illustrating the MBMS network configuration of the present invention as viewed from a security point of view.

4 is a schematic diagram of a simple MBMS network model for implementing the bootstrap method of the present invention.

5 is a signal flow diagram illustrating a process of transferring various security settings stored in the VLR / SGSN in accordance with the movement of the UE.

6 is a signal flow diagram sequentially illustrating a process of performing bootstrap of the present invention.

The present invention relates to a method for shortening a session key establishment time according to bootstrap in a multicast / broadcast multimedia service of a wireless mobile communication network.

Multicast Broadcast Multimedia Service (MBMS) introduced the concept of point to multipoint in the 3rd Generation Partnership Project (3GPP). The biggest feature of multicast compared to broadcast is that it must be billable. That is, only a user with a certain authority should be able to receive the multicast service, and such authority is associated with charging. In order to ensure that only authorized users can receive data, encryption of the data is essential, and the encryption key information necessary for encryption is delivered only to users who have paid or paid for a subscription.

Encryption for MBMS is performed at the application layer and encryption of the RAN layer is not defined separately for MBMS. The application layer of the broadcast-multicast service center (hereinafter referred to as 'BM-SC') generates an encryption key and delivers it to each user equipment (UE). In addition, since the user data is encrypted and transmitted with a key generated from the generated encryption key, the UE having no encryption key cannot read the data even if it can receive the data.

Such an encryption key should be continuously changeable, and when the change is made, a new key and a time point for applying the key should be transmitted to each UE. The UE must receive a new encryption key from the network before receiving user data, and information for generating such an encryption key or encryption key is transmitted in a secure manner from the BM-SC to the UE in a point-to-point manner. .

If the UE requests the MBMS user service in a situation in which the UE has not received the information for generating the encryption key or the encryption key from the BM-SC, the UE and the bootstrapping server function; BSF ') bootstrap process for mutual authentication and encryption key sharing.

FIG. 1 briefly illustrates a conventional MBMS network model for performing such bootstrap, and FIG. 2 is a signal flowchart sequentially illustrating a conventional bootstrap process.

When the UE 100 sends an HTTP request including the user's ID to the BSF 200 (S201), the BSF 200 receives a message from the Home Subscriber Server (hereinafter referred to as 'HSS') 300. Obtain a complete set of GBA User Security Settings (GUSS) and one Authentication Vector (AV) (AV = RAND || AUTN || XRES || CK || IK) (S202). ).

The BSF 200 requests the UE 100 to authenticate itself by transmitting a RAND (Random Challenge) and an Authentication Token (AUTN) to the UE 100 through a 401 message (S203). The UE 100 checks the AUTN included in the message to confirm whether the message is transmitted from an authorized network, and calculates a cipher key (CK), an integrity key (IK), and a user authentication response (RES). Session keys CK and IK are formed (S204). As a result, respective session keys CK and IK are set in both the UE 100 and the BSF 200.

Subsequently, when the UE 100 transmits a separate HTTP request including the Digest Authentication and Key Agreement (AKA) response obtained by calculating the RES to the BSF 200 (S205), the BSF 200 receives the received Digest AKA response. Check to authenticate the UE (100) (S206).

The BSF 200 generates a key material (Ks) by concaterating CK and IK (Ks = CK || IK) (S207), and specifies a bootstrapping transaction identifier (bootstrapping transaction identifier) to specify the success of authentication; Hereinafter, a 200 OK message including 'B-TID') is transmitted to the UE 100 (S208). Thereafter, the UE 100 generates Ks by concaterating CK and IK (Ks = CK || IK) (S209).

As described above, in the related art, when the UE wants to obtain a session key to be shared with the BM-SC, the bootstrap method of accessing the HSS every time through the BSF and obtaining authentication information (eg, AV) is used. The same cumbersome bootstrap procedure has caused a problem of degrading the quality of service (QoS) of MBMS that must be provided in real time in a mobile wireless mobile communication environment.

The present invention has been proposed to solve the above problems, and temporarily stores the authentication information stored in the HSS in the VLR / SGSN and the BSF is required to bootstrap by obtaining the authentication information by querying the VLR / SGSN instead of the HSS Its purpose is to provide a method of minimizing the delay time that is incurred.

One aspect of the present invention for achieving the above object relates to a bootstrap method for executing an application in a mobile communication network, the bootstrap server receiving the authentication information from the user terminal, the bootstrap server VLR Requesting the authentication information to any one of a (Visitor Location Register) and a Serving GPRS Support Node (SGSN), and the bootstrap server transmitting a part of the authentication information to a user terminal to request its authentication; In response to a request of a user terminal generating a first encryption key for user authentication, the bootstrap server authenticating the corresponding user terminal and generating a second encryption key to be provided to the application server by the bootstrap server. It is made to include.

The VLR and SGSN may further include receiving the authentication information from an authentication information server. As the user terminal moves, the authentication information is transferred from the VLR / SGSN of the first area to the VLR / SGSN of the second area. The step of transferring may be further included.

The authentication information may be a concept including an authentication vector (AV) and an MBMS user context.

Hereinafter, preferred embodiments will be described in detail with reference to the accompanying drawings. In particular, the bootstrap process for the case where the multimedia application is executed through the MBMS of the mobile communication network will be described as a preferred embodiment. Accordingly, the user terminal may correspond to the UE, the bootstrap server to the BSF, the authentication information server to the HSS, and the application server to the BM-SC, respectively.

However, despite these preferred embodiments, the multimedia service provided in the mobile communication network is not necessarily limited to the MBMS, but may be applied to various multimedia services having components corresponding to each element constituting the mobile communication system of the present invention. It will be apparent to those skilled in the art.

On the other hand, it should be noted that the same reference numerals are assigned to the same components throughout the drawings attached to the specification.

3 is a block diagram of the MBMS network configuration of the present invention as viewed from the security point of view.

In MBMS, in general, almost all security related functions except for network bearer security are performed in the UE 100 or the BM-SC 400.

The UE 100 shares various keys with the BM-SC 400 through the Generic Bootstrapping Architecture (GBA). That is, the UE 100 requests a key for using the MBMS user service from the BM-SC 400 and decrypts the received MBMS data using the received key. Prior to such a key request process, the UE 100 performs mutual authentication with the BM-SC 400 through HTTP digest authentication. This procedure is done via the Ua interface and all HTTP procedures can be guaranteed integrity through the HTTP Digest authentication.

The BM-SC 400 is a source of MBMS data, schedules data and receives data from a third source. To this end, the BM-SC 400 may include a membership function 410, a security function (not shown), a session and transmission function 430, a proxy and a transport. And a service announcement function (not shown in the figure) and a service announcement function (not shown in the figure).

Here, the membership function 410 checks whether a specific user is authorized to register, receive a key, and form an MBMS bearer (see 3GPP TS 23.246 [3]), and the session and transfer function 430 is connected to streaming data or download data. Encryption and / or integrity protection using MTK (MBMS Traffic Key) is performed.

In addition, the key management function 420 constituting the security function may be further subdivided into a key request function 421 and a key distribution function 422.

The key request function 421 obtains a GBA key from the BSF 200, derives an MMS (MBMS User Key) and an MRK (MBMS Request Key) from the GBA key, and sends the UE 100 to the MBMS user service. Register or de-registration. In addition, it performs the MBMS Service Key (MSK) request procedure, authenticates the relevant user using the MRK, and provides the MUK to the key distribution function. In addition, it performs subscription checks from membership functions, and initializes and renegotiates bootstrap.

The key distribution function 422 is provided with the MUK from the key request function 421, generates an MSK and an MTK through the MIKEY (Multimedia Internet Keying) protocol, and delivers the MSK to the UE 100, and transmits the MSK and MTK to the session and transmission function 430. Provide MTK.

Meanwhile, the UE 100 and the BM-SC 400 form a shared key for protecting point-to-point communication between the two using the GBA. If the UE 100 does not have a key to share with the BM-SC 400, the UE 100 performs a GBA with the BSF 200 of the home network, and the GBA automatically implements a 3GPP AKA mechanism for MBMS security. Run In this case, the BM-SC 400 operates as a Network Application Function (NAF), and a predetermined bootstrap process is performed between the UE 100 and the BSF 200.

In addition to the above-described case, the bootstrap may be performed before the UE 100 performs the interaction with the NAF 400, or the message that the UE 100 requests initialization of the bootstrap from the NAF 400 or This may be performed when a negotiation instruction of the bootstrap is received. It may also be performed when the lifetime of the key has expired. In addition, the details of the MBMS security model with respect to GBA can be implemented with reference to 3GPP 33.220 and 33.246.

4 shows a simple MBMS network model for performing the bootstrap method of the present invention.

First, the UE 100 preferably satisfies the following requirements.

That is, the UE 100 supports the HTTP Digest AKA protocol and uses both the IP Multimedia Services Identity Module (ISIM) and the Universal Subscriber Identity Module (USIM) to perform bootstrapping. It should be able to support bootstrap by selecting one of the ISIM and USIM.

In addition, a Ua interface application for assigning a type or name of a Universal IC Card (UICC) application used in bootstrap to a GBA function can be executed, and a new key material used for a protocol on the Ua interface can be used as an encryption key ( It can derive from Cypher Key (hereinafter 'CK') and Integrity Key (hereafter 'IK') and must support NAF-specific application protocols.

The BSF 200 performs mutual authentication with the UE 100 through a predetermined protocol (eg, the HTTP AKA protocol). In addition, the BSF 200 may restrict a key material from being applied to a specific NAF 400 through a predetermined key derivation procedure. This key derivation procedure may be performed at multiple NAFs 400 for the validity period of that key. Meanwhile, the BSF 200 receives the GUSS from the HSS 300.

When the bootstrap is completed, the NAF 400 may execute a specific application by using a predetermined protocol with the UE 100, and at this time, messages transmitted and received to perform the corresponding application may be transmitted between the UE9100 and the BSF 200. Authentication is based on session keys generated during mutual authentication.

The HSS 300 permanently stores a set of User Security Settings (USSs) for all users, such as GUSS. If a subscriber has multiple subscriptions, such as multiple ISIMs or USIMs, the HSS 300 will include one or more GUSS that map to one or more private identities. . However, unlike the conventional HSS 300, instead of providing GUSS to the BSF 200 every time a bootstrap occurs, when there is a request from the BSF for a predetermined period or for the reason that the key validity period has passed, etc. It is a feature of the present invention to provide. However, the present invention is not limited thereto, and the GUSS stored in the Visitor Location Register (VLR) / Serving GPRS Support Node (SGSN) 600, which will be described later, is lost for some reason, or the GUSS needs to be newly generated in the other VLR / SGSN 600. Various cases may fall within the scope apparent to those skilled in the art, such as when a situation occurs.

The subscriber locator function (SLF) 500 provides the BSF 200 with the name of the HSS 300 with the particular subscriber data when there is a query from the BSF 200.

The VLR / SGSN 600 is further responsible for storing a set of security settings such as GUSS and providing the same to the BSF 200 in addition to the conventional basic role played by the communication system. However, as described above, unlike the conventional HSS 300, only the GUSS for the UEs 100 within the area controlled by the UE is temporarily maintained.

In addition, the VLR / SGSN 600 may deliver the GUSS to the VLR / SGSN of the new area as the UE moves. FIG. 5 is a signal flow diagram illustrating a process of transferring various security settings stored in a VLR / SGSN according to the movement of the UE.

In the figure, VLRn / SGSNn 600-1 indicates the VLR / SGSN of the new region to which the UE 100 moves, and VLRo / SGSNo 600-2 indicates the VLR / SGSN of the previous region. Therefore, whenever the UE 100 moves to an area controlled by the new VLR / SGSN 600-1, the VLRo / SGSNo 600-2 is connected to the AV, MBMS user context of the UE 100. And other security contexts to the VLRn / SGSNn 600-1.

Here, the MBMS user context includes UE-specific information related to a specific MBMS bearer service subscribed to by the corresponding UE, and at the time of UE, SGSN, Gateway GPRS Support Node (GGSN), and BM-SC when the UE subscribes to the MBMS bearer service Is generated. Also, even after the MBMS user context is transmitted from the previous SGSN, the MBMS user context is generated again in the new SGSN when the inter-SGS routing area is updated.

Therefore, even when the UE 100 moves, the VLR or SGSN 600 of the corresponding area may receive all the GUSSs (AV, MBMS user context, and other security contexts, etc.) of the UE 100. When the 100 performs bootstrap for receiving the MBMS user service, the BSF 200 may query the VLR or SGSN 600 of the corresponding region without having to query the GUSSs for the HSS each time.

On the other hand, the movement of the UE specified in the present invention means one network domain managed by the same operator.

Next, look at the role of the main reference point (reference point) located between each component of the above-described MBMS network as follows.

Zh is located between the BSF 200 and the HSS 300 and allows the BSF 200 to obtain some authentication information and all GUSS from the HSS 300. In addition, the interface with the 3G authentication center is implemented inside the HSS (300). Preferred requirements for Zh are as follows.

That is, Zh must provide mutual authentication, confidentiality and integrity, and through Zh, the BSF 200 must be able to request bootstrap information about the subscriber from the HSS 300, and optionally the BSF 200 may request HSS ( It should be able to transmit a timestamp of the subscriber GUSS to 300). In addition, the HSS 300 must be able to send one 3GPP AKA vector to the BSF 200 at once, and be able to send the complete GUSS set of subscribers required for security to the BSF 200. At this time, the HSS 300 may optionally indicate to the BSF 200 whether the BSF 200 already has a recent GUSS copy based on the time stamp. In addition, no state information about the bootstrip is required in the HSS 300, and all procedures occurring in Zh are initialized by the BSF 200, and the number of different interfaces to the HSS 300 should be minimized.

The Ub is located between the UE 100 and the BSF 200 and provides mutual authentication therebetween. It also allows the UE 100 to bootstrap a session key based on the 3GPP AKA infrastructure. Preferred requirements for Ub are as follows.

That is, the BSF 200 should be able to identify the UE 100 through the Ub, the BSF 200 and the UE 100 should be able to authenticate each other based on the AKA, the BSF 200 is a UE Must be able to send the bootstrap transaction identifier to 100. In addition, the BSF 200 and the UE 100 form a shared key through the Ub, and the BSF 200 may designate a lifetime of a key material to the UE 100. have.

The Ua enables the application protocol to be securely delivered using a key material generated in a mutual authentication procedure (eg, an HTTP Digest AKA's execution procedure) between the UE 100 and the BSF 200. For example, when the subscriber supports 3GPP TS 33.221, the Ua may be a protocol that allows the user to request authentication from the NAF 400.

Zn is used by the NAF 400 to fetch a key material established through the previous HTTP Digest AKA protocol. Preferred requirements for Zn are as follows.

In other words, if mutual authentication, confidentiality and integrity must be provided by Zn, and BSF 200 and NAF 400 are located in the same operator network, DIAMETER-based Zn is not secured according to NDS / IP (Network Domain Security). When the BSF 200 and the NAF 400 are located in different provider networks, the DIAMETER-based Zn located between the Zn proxy and the BSF should be secured using TLS (Transport Layer Security). Here, the DIAMETER refers to the protocol of the IETF standard developed for the next generation portable Internet and roaming network.

Dz is located between the BSF 200 and the SLF 500 and allows the BSF 200 to receive the name of the HSS 300 with specific subscriber data from the SLF 500.

The Zv / Zs is located between the VLR / SGSN 600 and the BSF 200 and securely provides the GUSS and the like at the request of the BSF 200. Preferred requirements for Zv / Zs are as follows.

That is, mutual authentication, confidentiality and integrity must be provided by Zv / Zs, and the VLR / SGSN 600 must be able to transmit one 3GPP AKA vector to the BSF at a time via Zv / Zs. In addition, the VLR / SGSN 600 must be able to send a series of GUSS for the subscriber to the BSF 200 for security, and in addition, the VLR / SGSN 600 requires that the BSF 200 be based on the GUSS time stamp. It may be specified to the BSF 200 whether it already has the latest GUSS information. In addition, the VLR / SGSN 600 does not require any state information related to bootstrap via Zv / Zs.

Hereinafter, a process of performing bootstrap through the aforementioned MBMS network model will be described in more detail. 6 is a signal flowchart sequentially illustrating a process of performing bootstrap of the present invention.

When the UE 100 sends an HTTP request containing the user's ID to the BSF 200 (S601), the BSF 200 receives a complete set of GUSS and one authentication vector (from the VLR or SGSN 600). Authentication Vector (hereinafter referred to as 'AV') is obtained (S602). Here, AV refers to a value in which RAND, AUTN, XRES, CK, and IK are connected in sequence or in a predetermined order (ie AV = RAND || AUTN || XRES || CK || IK).

The BSF 200 delivers the RAND and the AUTN to the UE 100 through a predetermined message (eg, a 401 message) (S603). At this time, the message does not include XRES, CK, IK. This is to request the UE to authenticate itself.

The UE 100 checks the AUTN included in the message in order to confirm whether the message is transmitted from an authorized network (S604). In addition, CK, IK and RES are calculated to form session keys CK and IK. As a result, respective session keys CK and IK are set in both the UE 100 and the BSF 200.

Thereafter, when the UE 100 transmits a separate HTTP request including the Digest AKA response obtained by calculating the RES to the BSF 200 (S605), the BSF 200 examines the received Digest AKA response to the UE 100. ) Is authenticated (S606).

The BSF 200 generates a key material (Ks) by concaterating CK and IK (ie, Ks = CK || IK) (S607). In this case, the B-TID value for binding the subscriber ID to a keying material in the Ua, Ub, and Zn interfaces may be a network access identifier (Network) using an appropriate RAND value and the BSF server name generated in step S603. It may be generated in the format of Access Identifier (NAI). In this case, the RAND value may be encrypted with base64. In this case, base64encode (RAND) @BSF_servers_domain_name may be used as an example of the BSF server name.

To inform the authentication success, the BSF 200 transmits a predetermined message (eg, 200 OK message) including the B-TID to the UE (S608). In this case, the transmitted message may further include a valid period of Ks.

Thereafter, the UE 100 generates a key material (Ks) by concaterating CK and IK (ie, Ks = CK || IK) (S609).

Both the UE 100 and the BSF 200 use Ks to generate Ks_xxx_NAF while the procedure is performed. Ks_xxx_NAF can guarantee safety at reference point Ua. Ks_xxx_NAF can be programmed in the manner Ks_xxx_NAF = KDF (Ks, "gba-me", RAND, IMPI, NAF_Id), where KDF is the key derivation function specified in Reference B (Annex B) of 3GPP 33.220. Derivation Function). In addition, the NAF_ID may be configured as a DNS name for the NAF 400 and may be concaterated with a Ua security protocol identifier specified in Reference H (Annex H) of 3GPP 33.220. In addition, KDF may be implemented in a mobile equipment (ME).

The present invention described above is capable of various substitutions, modifications, and changes without departing from the spirit of the present invention for those skilled in the art to which the present invention pertains. It is not limited by the drawings.

According to the present invention, since it is not necessary to query the HSS every time to obtain the encryption key in the bootstrap process for receiving the MBMS, it is possible to shorten the time required for generating, updating and distributing the encryption key. Branch offices can provide high quality of service (QoS) for multiple users in a real-time application environment.

Claims (9)

In the bootstrap method for running an application in a mobile communication network, Receiving, by the bootstrap server, authentication information from a user terminal; Requesting, by the bootstrap server, the authentication information from any one of a visitor location register (VLR) and a serving GPRS support node (SGSN); The bootstrap server transmitting a part of the authentication information to a user terminal to request its authentication; Authenticating, by the bootstrap server, the corresponding user terminal according to a request of the user terminal generating a first encryption key for user authentication; And Generating a second encryption key to be provided to the application server by the bootstrap server Bootstrap method in a mobile communication network comprising a. The method of claim 1, Bootstrap method in a mobile communication network, characterized in that the VLR and SGSN further comprises the step of receiving the authentication information from the authentication information server. The method of claim 1, And as the user terminal moves, the authentication information is transferred from the VLR / SGSN of the first area to the VLR / SGSN of the second area. The method of claim 1, The application is provided through a Multicast Broadcast Multimedia Service (hereinafter referred to as "MBMS") The method of claim 4, wherein Bootstrap method in a mobile communication network, characterized in that the bootstrap is performed by a Generic Bootstrapping Architecture (GBA). The method according to claim 4 or 5, The authentication information bootstrap method in a mobile communication network, characterized in that it comprises an Authentication Vector (AV) and MBMS User Context (MBMS User Context). The method of claim 6, The AV bootstrap method in a mobile communication network comprising at least one of RAND (Random Challenge), AUTN (Authentication Token), CK (Ciphier Key), IK (Integrity Key), RES (User Authentication Response) . The method of claim 7, wherein And the first encryption key and the second encryption key are generated by concaterating the CK and IK. The method of claim 7, wherein The user terminal checks the AUTN of the authentication information received from the bootstrap server to perform the authentication of the bootstrap server, The bootstrap server bootstrap method in a mobile communication network, characterized in that for verifying the RES received from the user terminal performs the authentication of the user terminal.

Images