Title of Invention

"METHOD OF PROCESSING SECURITY MESSAGE IN MOBILE COMMUNICATION SYSTEM"

Abstract

Disclosed is a method for processing security message in a radio resource control (RRC) layer of a mobile communication system. The method for processing a security message includes the steps of receiving the security message (S31), storing previous security-relating variables, carrying out an integrity check (S34) on the received security message, discarding (S37) or processing (S36) the security message according to a result of the integrity check (S34), and updating the security-relating variables (S33). Accordingly, a security setup control message processing method is provided which includes an integrity check of the received security message.

Full Text

Method for Processing Security Message in Mobile Communication System technical Field The present invention relates to a message processing -method applied to mobile communication, and more particularly, to a method for processing a security message in a SRC layer., Background Art UMTS {universal mobile telecommunications system) includes UE (user equipment), UTRAN (UMTS terrestrial radio access network) , and CN (core network) . Moreover, the UTRAN • comprises a plurality of RNSs (radio network subsystems). Each of the RNS comprises RNC (radio network controller) and a plurality of Node Bs managed by the RNC. A Node B receives uplink signals transmitted from UE and transmits downlink signals to the UE. The RNC takes charge of allocation and management of radio resource, and plays a role of an access point to connect the Node Bs to the CN. Each UE connected to the UMTS is managed by a specific RNC in the UTRAN, and the specific RNC is called SRNC (serving RNC). The UTRAN configures, maintains, and manages RABs {radio access bearers) for the communications between the UE and the CN. The CN applies end-to-end QoS (quality of service) requirements to the RAB, and the RAB supports QoS requirements set up by the CN. The UTRAN therefore configures, maintains, and manages the RAB, thereby enabling to meet the end-to-end QoS requirements. A radio interface protocol vertically comprises a physical layer, a data link layer, and a network layer and horizontally comprises a user plane for providing data information and a control plane for providing signaling. The protocol layers are grouped into LI (layer 1), L2 {layer 2), and L3 (layer 3) based on three lower layers of an OSI {open system interconnection) reference model. The LI provides upper layers with information transfer service using various radio transmission techniques. And, the LI is connected to a MAC (medium access control) layer of the upper layers via transport channels. A RLC layer supports data transmission reliably and carries out segmentation and concatenation on RLC SDUs (service data units) transferred from the upper layers. The RLC SDUs transferred from the upper layers are divided into RLC data units that can be processed in the RLC layer, and header information is added to the divided RLC data units to transfer to the MAC layer as a form of PDU (protocol data unit). A PDCP (packet data convergence protocol) layer is disposed over the RLC layer. The PDCP layer makes data, which is transferred through the network protocol, be transmitted efficiently over a radio interface of which bandwidth, is relatively narrow. A BMC (broadcast/multicast control) layer schedules UEs to which a CB {cell broadcast) message transferred from the CM will be transmitted, and transfers the CB message to the corresponding UEs located in specific cell(s) on the basis of the scheduling. On request from higher layers, A RRC {radio resource control) layer controls transport and physical channels to perform the establishment, reconfiguration, and release of RBs {radio bearers). In this case, the RB means a service provided by the L2 for data transfer between the UE and UTRAN. Meanwhile, various channels for receiving/transmitting data are defined between the UEs and the UTRAN to use. Data are sent and received between the PHY layer of UE and that of the UTRAN using the physical channel. In addition to physical channel, data transport paths between the protocol layers are defined as transport and logical channels in the radio access network of the UMTS. The logical channels are exchange between the RLC and MAC layer, while the transport channels are provided for data exchange between the MAC and PHY layer. Mapping between transport channels is performed in the MAC layer, while another mapping between the transport and physical layers is performed in the physical layer. Various kinds of messages are received/transmitted between the terminal and UTRAN. 'Security check' is mostly carried out to protect data contained in the messages. Such 'security check' includes Ciphering' and 'integrity check'. The ciphering adds a specific mask, which is known to both of transmitting and receiving parties only, to a message so that a third party failing to know the mask is unable to recognize the contents of the message. And, the integrity check is used for checking whether an unauthorized third party has altered the contents of the message or whether the transmission is made by an unauthenticated party. Namely, the integrity check is performed for integrity protection and is a procedure required for checking whether the contents of the received message are intentionally and previously changed by the third party. In the UMTS, the ciphering and the integrity check are simultaneously carried out on most of the messages transferred to the RRC layer and most of the control messages transmitted to the upper layers of the RRC layer. And, the ciphering is carried out on other general user data only. Such integrity check can be carried out in the RRC layer. Thus, if the message of which contents are changed by the I third party between the transmitting and receiving parties is received, or in order to filter a message transmitted from the unauthenticated transmitting party, the receiving party carries out the integrity check on the received message. Hen the received message is normally processed or discarded according to whether the received message passes the integrity check or not. For instance, one of the received messages may be a security setup control message. In connection between the US and the network (ex. UTRAN), the security setup control message is used for initiating to secure messages that will be transmitted thereafter. Moreover, the security setup control message car be used for controlling security-relating environment variables that are used for the connection on i which the security process has been carried out. Information, which is related to controlling the security-relating environment variables, among the contents contained in the security setup control message is called security-relating environment setup information. Yet, the security-relating information contained in the security setup control message itself can be changed by the unauthenticated third party or can be transmitted by the unauthenticated transmitting party, whereby it is unable to rely on such security-relating information. Disclosure of invention Accordingly, the present invention is directed to a method for processing a security message in mobile communication system that substantially obviates one or more problems due to limitations and disadvantages of the related art. An object of the present invention is to provide a security setup control message processing method including security check of a security message itself. Additional advantages, objects, and features of the invention will be set forth in part in the description which follows and in part will become apparent to those having ordinary skill in the art upon examination of the following or may be learned from practice of the invention. The objectives and other advantages of the invention may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings. To achieve these objects and other advantages and in accordance with the purpose of the invention/ as embodied and broadly described herein, a method for processing security message in mobile communication system according to the present invention includes the steps of receiving. The security message, storing previous security-relating variables, carrying out security check on the security message, discarding or processing the security message according to a result of the security check, and updating the security-relating variables. The present invention is characterized in that the security check of the security message itself is performed to secure integrity protection. It is to be understood that both the foregoing general description and the following detailed description of the present invention are exemplary and explanatory and areintended to provide further explanation of the invention as claimed. Brief Description of Drawings The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment (s) of the invention and together with the » description serve to explain the principle of the invention. In the drawings: FIG. 1 illustrates a flowchart of a general message processing method; PIG, 2 illustrates a flowchart of a method for processing a security setup control message according to a first embodiment of the present invention; FIG. 3 illustrates a flowchart of a method for processing a security setup control message according to a second embodiment of the present invention; FIG. 4 illustrates a diagram of one embodiment representing COUNT-1 in security-relating environment variables; and FIG. 5 illustrates a diagram for explaining one embodiment of generating an authentication value in integrity check. Best Mode for Carrying out the Invention Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. FIG. 1 illustrates a flowchart of a general message processing method. Referring to FIG. 1, OB (user equipment) firstly receives a general message (Sll) and then carries out integrity check on it (S12) , In accordance with a result of the integrity check, the message is normally processed or discarded. Namely, if the message passes the integrity check, it is normally processed (S13). If the message fails to pass the integrity check, it is discarded since there exists a security problem (S14). FIG. 2 illustrates a flowchart of a method for processing a security setup control message according to a first embodiment of the present invention. Referring to FIG. 2, UE (user equipment) receives a security setup control message (S21), And, security-relating environment variables are updated using security-relating environment setup information contained in the received security setup control message (S22). The UE (ex. terminal) carries out security check on the security setup control message itself using the updated security-relating environment variables (S23). The security check includes integrity check. If the security setup control message passes the integrity check, the message is normally processed (S24). Yet, if the security setup control message fails to pass the integrity check, the message is judged as abnormal so that the received security setup control message is discarded (S25) . Moreover, it is unable to rely on the security-relating environment setup information included in the security setup control message. Hence, it is unable to use the security-relating environment setup information. In the first embodiment of the present invention, once a receiving party receives the security setup control message, the previously set security-relating environment variables are updated with the security-relating environment setup information included in the message, and the previous security-relating environment variables are discarded. Hence, 5= the security-relating environment variables of the receiving party do not coincide with those of a transmitting party anymore, it is unable to further exchange messages, and the receiving party cannot be provided with further requested services. FIG. 3 illustrates a flowchart of a method for processing a security setup control message according to a second embodiment of the present invention. Referring to FIG. 3, a method for processing a security setup control message is carried out in a following manner. First of all, UE (user equipment) receives a security setup control message (S31). Before the UE carries out security check on the security setup control message itself, security-relating environment variables which were previously set are temporarily stored (S32). And, the security-relating environment variables are updated using security-relating environment setup information included in the received security setup control message (S33). The UE (ex, terminal) carries out security check on the security setup control message itself using the updated security-relating environment variables (S34). And, the security check includes integrity check. If the security setup control message passes a result of the integrity check, the temporarily stored security-relating environment variables are deleted (S35), Thereafter, security check is carried ou on messages received later using the updated security-relating environment variables and .the message is normally processed (S36}, However, if the security setup control message fails to pass the integrity check, it is handled such that the security setup control message is not received. Namely, if it is judged that the message is abnormal, the received security setup control message is discarded (S37). Moreover, the security-relating environment setup information included in the security setup control message cannot be used since it is not reliable. Thus, in case that the security setup control message is unable to pass the security check, the security setup control message is discarded as well as the temporarily stored security-relating environment variables are restored (838). And, messages received later are processed using the restored security-relating environment variables. In accordance with the second embodiment of the present invention, even if the message of which contents are changed in the middle of transmission t from the UTRAN to UE is received, or even if the security setup control message provided from an unauthenticated party is received, it is able to maintain the security-relating environment variables to be equal to those of the terminal using the previously set security-relating environment variables by storing and restoring them. Hence, if the security-relating environment setup variables are deleted instead of being stored, it is able to prevent the case that the message cannot be processed later due to the difference between the security-relating environment variables of the UE and the UTRAN. A method of performing the integrity check is explained in detail as follows. For such explanation, parameters required for performing the integrity check are explained. In order to perform the integrity check, required are such parameters as IK (integrity key), COUNT-I, MESSAGE, DIRECTION (direction identifier, I bit), and FRESH. FIG. 4 illustrates a diagram of one embodiment representing COUNT-I in security-relating environment variables. COUNT-I is one of security-relating environment variables. Namely, the COUNT-I is a value corresponding to a sequence number for integrity check. Referring to FIG. 4, the COUNT-I includes a pair of areas. One area of the two includes RRC HFN (hyper frame number) of 28 bits, while the other area of the two includes RRC SN (sequence number) of 4 bits. A procedure of updating the security-relating environment variables is carried out in a manner that HFN as a value of upper 28 bits of the COUNT-I is reset. Namely, the reset HFN may be a START value transmitted recently by a terminal, 0, or a specific value. And, UE carries out security check on the received security setup 'control message using the updated security-relating environment variables. The IK among the parameters for performing the integrity check indicates an integrity key, which is generated from an Authentication procedure in an upper layer of the RRC layer to have the RRC layer be informed of. A value of the IK is not transmitted via a radio interface, but the upper layer of the RRC layer in the terminal and a network (ex. UTRAN) calculate values of the IK to use based on specific input values, respectively. A value of the START is read from an SIM card when the terminal initiates connection between RRC layers of the UTRAN and the terminal, and is transmitted to the UTRAN. The value of the START, which is included in a message transmitted from the upper layer of the RRC layer of the terminal, may be transmitted to the UTRAN. While the connection between the RRC layers of the UTRAN and terminal is activated, the value of the START is defined as the greatest number of upper 20 bits of the currently used values of the COUNT-I or COUNT-C (which is used for ciphering and plays a role similar to the COUNT-I) . And the value of the START currently used between the RRC layers of the terminal and UTRAN is stored in the SIM card when the connection between the RRC layers of the terminal and UTRAN ends. The MESSAGE means a message which is transmitted itself. The DIRECTION is a direction discriminator and its value varies in accordance with uplink or downlink. The DIRECTION can be set as '0' or '1' on uplink or downlink. The FRESH is a value given to each terminal independently, and is a value that UTRAN transmits to UE on an initial state of the RRC connection. Namely, the value of the FRESH is an arbitrary number that UTRAN transmits to UE, which is for securing the security of the UTRAN from the terminal reusing the values of the COUNT-1 and MAC-1 in a manner that UTRAN provides UE with a new value every RRC connection. A value of the MAC-I (message authentication code-I) is a message authentication code calculated using UIA (UMTS integrity algorithm) with security-relating environment values, which is an integrity checksum inserted in RRC PDU. If there is no procedure of updating the value of the FRESH, a security invader easily makes the security of UTRAN vulnerable by requesting that the value of the START that will be used as an upper value of the COUNT-I should be set s into a very small value when new connection between RRC layers is requested and then 'by using a pair of vales of the i SN and MAC-I which was used for the previous connection between the RRC layers. Yet, such vulnerability of the security can be prevented by assigning a new value of the PRESH in UTRAN whenever the connection between RRC layers is newly established. FIG. 5 illustrates a diagram for explaining one embodiment of generating an authentication value in integrity check, in which 'f9' is a. standardized integrity check authentication generation algorithm adopted by 3GPP. Referring to FIG. 5, UTRAN and terminal use values of the parameters as input values, thereby generating values of MAC-I and XMAC-I using such an algorithm as ‘f9'. The MAC-I is an integrity check authentication value generated from the UTRAN, and the XMAC-I is an integrity check authentication value generated from the terminal. If all input values of the UTRAN and terminal are equal to each other, the values of the MAC-I and XMAC-I generated from the procedure of PIG. 3 will be equal to each other. Yet, if the message is changed in the middle of processing, input values of MESSAGE of receiving and transmitting parties are different from each other so that the value of the XMAC-I is not equal to that of the MAC-I. Hence, if the values of the MAC-I and XMAC-I are not equal to each other as a result of comparison, the terminal judges that contents of the received security setup control message are intentionally changed during transmission or that the received security setup control message is, transmitted from an unauthenticated party. In such a case, the security setup control message is judged as invalid, thereby failing to pass the integrity check. UTRAN changes a portion of the input values used for the procedure in PIG. 3 whenever sending a new message. And, the UTRAN generates a new MAC-1 each time using the partial change of input values. This is performed to prevent that an unauthorized party reuses the value of the MAC-1 to pass the integrity check. For this, the UTRAN increases the SN value of the COUNT-I by increment of '1' whenever sending a message. As mentioned in the foregoing description, the SN value constructs lower 4 bits of the COUNT-I. Being 4 bits, the SN value can have values ranging between 0-15 and sequentially increases by '!' from '0'. Once the SN value becomes '15', the next SN value becomes '0' and then increases by the increment of '1' again. Thus, HFN corresponding to upper value of the COUNT-I value is increased by '1' whenever the SN becomes back to '0' from '15'. Hence, such a method brings about the effect that the COUNT-I increases by '1' each time, whereby the input values are changed in part in a ciphering authentication value calculation procedure. Meanwhile, if the terminal recognizes the SN value of the received message and judges that the SN value has completed one cycle, the terminal increases its HFN value by '1'. Thus, the COUNT-I can coincide with that of the transmitting party. If such a method is used, the terminal and UTRAN can have the same COUNT-I information even if SN information is sent only. Besides, security information leakage, which may occur when the entire COUNT-I is sent, to a third party can be prevented. Hence, UTRAN enables the receiving party to accurately calculate the XMAC-I value as well as adds the SN value as lower value of the COUNT-1 to the message of each message transmission to prevent the unauthorized third party from passing the integrity check. And, the MAC-I value, which will be used as a reference for the terminal to perform the integrity check, is added to the message to transmit. Once UE receives the security setup control message, it is necessary to perform the security check of the SN value. For this, UE manages its local parameter SN only using the SN values received so far. If the SN value transmitted together with the security setup control message is equal to the local parameter SN value of the terminal, it can be assumed that a third party sends the message using the same security information of the transmitting party or that the same message is transmitted again from the authenticated UTRAN. In such a case, the terminal immediately discards the security setup control message. The terminal configures COUNT-I using the SN value received together with the security setup control message and calculates XMAC-I using the parameters set previously in COUNT-I and UE. The parameters set previously in UE include MESSAGE, DIRECTION, FRESH. By comparing the MAC-I value transmitted together with the security setup control message to the XMAC-I value calculated by UE, the UE performs the integrity check of the security setup control message. Once the received security setup control message passes the integrity check, the receiving party stores the SN value included in the message in the local parameter SN and uses it for the SN value check of the next message. Industrial Applicability Accordingly, the method according to the present invention is implemented as a program and can be stored in recording media (CD ROM, floppy disk, hard disk, optical magnetic disk, etc.) as a form that can be read by computer. Such a process is apparent to those skilled in the art, whereby its explanation is skipped in this description. It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention. Thus, it is intended that the present invention covers the modifications and variations of this invention provided they come, within the scope of the appended claims and their equivalents. WE CLAIM: 1. A method for processing security message in mobile communication system, the method comprising: receiving a security message by an user equipment; carrying out security check on the security message by means of an ex-terminal; processing by means of the said ex-terminal the security message and updating a value of at least one security variable with new security information if the security message passed the security check, and discarding the security message and leaving the value of the at least one security variable unchanged if the security message does not pass the security check. 2. The method as claimed in claim 1, wherein the security check is verifying integrity of the security message. 3. The method as claimed in claim 1 wherein the previous value of the at least one security variable is stored before the previous value of the at least one security variable is updated with the new security information. 4. The method as claimed in claim 1, wherein a new security information is extracted from the security message. 5. The method as claimed in claim 1, wherein an expected authentication value related to the security message is generated. 6. The method as claimed in claim 5, wherein a standardized integrity check authentication generating method is performed. 7. The method as claimed in claim 5 wherein the expected authentication value is compared with a received authentication code. 8. The method as claimed in claim 7, wherein the security message is processed if the received authentication code is equal to the expected authentication value and the security message is discarded if the received authentication code is not equal to the expected authentication value. 9. The method as claimed in claim 3, wherein the stored previous value of the at least one security variable is restored if the security message is discarded. 10. The method as claimed in claim 1, wherein the security message is an RRC (Radio Resource Control) message. 1 I. The method as claimed in claim 1, wherein the security message is a signaling message.

Documents:

3418-delnp-2005-abstract.pdf

3418-DELNP-2005-Claims-25-09-2008.pdf

3418-DELNP-2005-Claims-28-05-2008.pdf

3418-delnp-2005-claims.pdf

3418-delnp-2005-complete specification (granted).pdf

3418-DELNP-2005-Correspondence-Others-28-05-2008.pdf

3418-delnp-2005-correspondence-others.pdf

3418-delnp-2005-description (complete).pdf

3418-delnp-2005-description (complete)28-05-2008.pdf

3418-DELNP-2005-Drawings-28-5-2008.pdf

3418-delnp-2005-drawings.pdf

3418-DELNP-2005-Form-1-28-05-2008.pdf

3418-delnp-2005-form-1.pdf

3418-delnp-2005-form-18.pdf

3418-delnp-2005-form-2.pdf

3418-delnp-2005-form-26-(04-03-2008).pdf

3418-DELNP-2005-Form-3-28-05-2008.pdf

3418-delnp-2005-form-3.pdf

3418-DELNP-2005-Form-5-28-05-2008.pdf

3418-delnp-2005-form-5.pdf

3418-delnp-2005-pct-210.pdf

3418-delnp-2005-pct-220.pdf

3418-delnp-2005-pct-301.pdf

3418-delnp-2005-pct-308.pdf

abstract.jpg