Method and apparatus for authenticating access stratum in next generation wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate than a 4G communication system such as an LTE system. According to an embodiment, a method for performing a mutual authentication operation of a user equipment (UE) operating in an access stratum (AS) segment includes transmitting, to a base station, a first message including a first random value, receiving, from the base station, a second message including a second random value and a base station certificate of the base station in response to the first message, and identifying information included in the base station certificate and verifying the validity of the base station certificate when the base station certificate is valid according to a verification result of the base station certificate.

Description

Technical Field

[0001] This disclosure relates to a method and apparatus for mutual authentication between a UE and a base station based on Public Key Infrastructure (PKI) during the initial connection between a wireless device and a base station in a next-generation mobile communication system. Background Technology

[0002] Existing wireless communication technologies are primarily used for human services, such as voice, multimedia, and data communication. With the commercialization of fifth-generation (5G) communication systems, an explosive growth in interconnected devices is expected, connecting to communication networks. Examples of connected things can include vehicles, robots, drones, home appliances, displays, smart sensors installed in various infrastructures, construction machinery, and factory equipment. Mobile devices will evolve into various form factors, such as augmented reality glasses, virtual reality headsets, and holographic devices. In the sixth-generation (6G) communication era, efforts are underway to develop enhanced 6G communication systems to provide a wide range of services by connecting hundreds of billions of devices and things. Therefore, 6G communication systems are referred to as "super 5G" systems.

[0003] The 6G communication system, expected to be realized around 2030, will have a maximum transmission rate of tera (1000 gigabits) bps and a wireless latency of 100 microseconds (μsec). In other words, the transmission rate of the 6G communication system will be 50 times faster than that of the 5G communication system, and the wireless latency will be reduced to one-tenth of that of the 5G communication system.

[0004] To achieve such high data rates and ultra-low latency, 6G communication systems are considered to be implemented in the terahertz band (e.g., the 95 GHz to 3 THz band). Since the terahertz band suffers from more severe path loss and atmospheric absorption problems compared to the millimeter waves (mmWave) introduced by 5G, technologies that guarantee signal arrival, i.e., coverage, will become even more important. As a key technology for ensuring coverage, multi-antenna transmission technologies that exhibit better coverage characteristics than radio frequency (RF) devices and orthogonal frequency division multiplexing (OFDM) need to be developed, such as new waveforms, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, or massive MIMO. Several new technologies are currently under discussion, such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing using orbital angular momentum (OAM), and reconfigurable smart surfaces (RIS) to enhance the coverage of terahertz band signals.

[0005] For 6G communication systems that improve frequency efficiency and for system networks used in 6G communication systems including full-duplex technology, the following technologies are under development: full-duplex technology that utilizes the same frequency resources for both uplink and downlink; network technologies that integrate satellite and High Altitude Platform Stations (HAPS); network architecture innovations that optimize and automate network operations and support mobile base stations; obstacle avoidance dynamic spectrum sharing technology based on spectrum usage prediction; AI-based communication technologies that use artificial intelligence (AI) from the design stage and internalize end-to-end AI support to optimize the system; and next-generation distributed computing technologies that enable services beyond the computing power limitations of UEs through ultra-high performance communication, mobile edge computing (MEC), or the cloud. Furthermore, efforts are being made to enhance connectivity between devices, further optimize networks, promote the implementation of network entities in software, improve the openness of wireless communication by designing new protocols for 6G communication systems, implement hardware-based security environments, develop mechanisms for secure data use, and develop technologies to maintain privacy.

[0006] The development of this 6G communication system will enable the next generation of hyper-connected experiences, including connections between people and things, and between things themselves. Specifically, the 6G communication system will be able to provide services such as truly immersive extended reality (XR), high-fidelity mobile holograms, and digital copies. Furthermore, due to its enhanced security and reliability, the 6G communication system will be used to provide services such as remote surgery, industrial automation, and emergency response, and will have various applications in the medical, automotive, and home appliance industries. Summary of the Invention

[0007] [Technical Issues]

[0008] In a wireless communication system, a method and device are provided for mutual authentication between a UE and a base station based on Public Key Infrastructure (PKI) in the wireless segment between a terminal and a base station.

[0009] [Technical Solution]

[0010] According to an embodiment, a method for operating a user equipment (UE) to perform mutual authentication in the access layer (AS) segment of a wireless communication system includes: sending a first message including a first random value to a base station; receiving a second message including a second random value and a base station certificate from the base station; in response to the first message, identifying information included in the base station certificate and verifying the validity of the base station certificate; when the base station certificate is valid according to the verification result of the base station certificate, sending a third message including a UE certificate and a temporary session key to the base station; and when the authentication of the UE certificate is completed, receiving a fourth message from the base station indicating that mutual authentication between the UE and the base station is completed. In this case, the session key of the base station can be generated based on the first random value, the second random value, and the temporary session key.

[0011] The method may further include sending a certificate revocation information request message to the base station to receive revocation information of the base station certificate from the certificate verification server, and receiving a certificate revocation information response message from the base station including the base station certificate revocation information sent from the certificate verification server.

[0012] According to an embodiment, the revocation information of a base station certificate may be a Credential Revocation List (CRL) that indicates a certificate revocation list or an Online Certificate Status Protocol (OCSP) used to identify whether a base station certificate has been revoked.

[0013] The method may also include: performing a mutual authentication procedure between the UE and the certificate verification server; sending a certificate revocation information request message to the certificate verification server requesting revocation information of the base station certificate; and receiving a certificate revocation information response message including the base station certificate revocation information from the certificate verification server.

[0014] According to an embodiment, the revocation information of a base station certificate may be a Credential Revocation List (CRL) that indicates a certificate revocation list or an Online Certificate Status Protocol (OCSP) used to identify whether a base station certificate has been revoked.

[0015] According to an embodiment, the certificate revocation request message can be encrypted based on at least one of the UE's private key, a hash function, and the operator's public key.

[0016] According to an embodiment, the certificate revocation request message may be encrypted together with at least one of the following: the identification information of the entity that sent the certificate revocation request message, and the time information of sending the certificate revocation request message.

[0017] According to an embodiment, the certificate revocation information response message can be encrypted based on at least one of the UE's private key, a hash function, or the operator's public key.

[0018] According to an embodiment, the certificate revocation information response message may be encrypted together with at least one of the following: the identification information of the entity receiving the certificate revocation information response message, and the time information of sending the certificate revocation information response message.

[0019] According to an embodiment, the revocation information of base station certificates can be managed based on the location information of at least one base station and the mobility information of at least one UE, according to the Registration Area (RA) or the Tracking Area (TA).

[0020] The method may further include: receiving a first system information block (SIB) from a base station; and receiving a second SIB from the base station based on the first SIB, which includes a credential revocation list (CRL) indicating a certificate revocation list.

[0021] The method may further include, when the base station certificate is invalid based on the verification result of the base station certificate, performing a mutual authentication procedure with another base station; when the mutual authentication procedure with the other base station is completed, sending an authentication failure report message indicating that the mutual authentication with the base station failed to the certificate verification server; and receiving an authentication failure report response message corresponding to the authentication failure report message from the certificate verification server.

[0022] According to an embodiment, a method for operating a base station to perform mutual authentication in the access layer (AS) segment of a wireless communication system includes: receiving a first message from a UE including a first random value; sending a second message to the UE including a second random value and a base station certificate of the base station; in response to the first message, receiving a third message from the UE including a UE certificate and a temporary session key when authentication of the base station certificate is completed; identifying information included in the UE certificate and verifying the validity of the UE certificate; and when the UE certificate is valid, sending a fourth message to the UE indicating that mutual authentication between the UE and the base station is completed.

[0023] According to an embodiment, a session key between the UE and the base station can be generated based on a first random value, a second random value, and a temporary session key.

[0024] It may further include: receiving from the UE a certificate revocation information request message for the UE to receive revocation information of the base station certificate from the certificate verification server; and sending to the UE a certificate revocation information response message including the base station certificate revocation information sent from the certificate verification server.

[0025] According to an embodiment, the revocation information of a base station certificate may be a Credential Revocation List (CRL) that indicates a certificate revocation list or an Online Certificate Status Protocol (OCSP) used to identify whether a base station certificate has been revoked.

[0026] According to an embodiment, the certificate revocation request message can be encrypted based on at least one of the UE's private key, a hash function, and the operator's public key.

[0027] According to an embodiment, the certificate revocation information response message can be encrypted based on at least one of the UE's private key, a hash function, and the operator's public key.

[0028] According to an embodiment, the revocation information of base station certificates can be managed based on the location information of at least one base station and the mobility information of at least one UE, according to the Registration Area (RA) or the Tracking Area (TA).

[0029] The method may further include: sending a certificate revocation information request message for the UE certificate to the certificate verification server to receive the revocation information of the UE certificate; and receiving a certificate revocation information response message including the revocation information of the UE certificate from the certificate verification server.

[0030] According to an embodiment, the UE certificate revocation information may be a Credential Revocation List (CRL) indicating the certificate revocation list or an Online Certificate Status Protocol (OCSP) used to identify whether a UE certificate has been revoked.

[0031] The method may further include: sending a first system information block (SIB) to the UE; and sending a second SIB to the UE based on the first SIB, which includes a credential revocation list (CRL) indicating a certificate revocation list.

[0032] According to an embodiment, a user equipment (UE) configured to perform mutual authentication in the access layer (AS) segment of a wireless communication system includes a transceiver and a controller connected to and controlling the transceiver. The controller may be configured to: control the sending of a first message including a first random value to a base station; control the receiving of a second message including a second random value and a base station certificate from the base station; in response to the first message, identify information included in the base station certificate and verify the validity of the base station certificate; when the base station certificate is valid according to the verification result, control the sending of a third message including a UE certificate and a temporary session key to the base station; and when the authentication of the UE certificate is completed, control the receiving of a fourth message from the base station indicating that mutual authentication between the UE and the base station has been completed.

[0033] According to an embodiment, a session key between the UE and the base station can be generated based on a first random value, a second random value, and a temporary session key.

[0034] According to an embodiment, a base station configured to perform mutual authentication in the access layer (AS) segment of a wireless communication system includes a transceiver and a controller connected to and controlling the transceiver. The controller may be configured to: control the reception of a first message from a UE including a first random value; control the sending of a second message to the UE including a second random value and a base station certificate of the base station; in response to the first message, when authentication of the base station certificate is completed, control the reception of a third message from the UE including a UE certificate and a temporary session key; identify information included in the UE certificate and verify the validity of the UE certificate; and when the UE certificate is valid, control the sending of a fourth message to the UE indicating that mutual authentication between the UE and the base station has been completed. According to an embodiment, a session key between the UE and the base station may be generated based on the first random value, the second random value, and the temporary session key.

[0035] Before proceeding with the following detailed description, it may be advantageous to clarify the definitions of certain words and phrases used in this patent document: the terms “comprising” and “including” and their derivatives mean including but not limited to; the term “or” is inclusive, meaning “and / or”; the phrases “associated with” and “associated with” and their derivatives mean including, being included, interconnected with, containing, being contained, connected to or linked with, coupled to or coupled with, able to communicate with, cooperate with, interleave, juxtapose, approach, combine with or combine with, own, own property of, etc.; and the term “controller” means any device, system or part thereof that controls at least one operation, which may be implemented in hardware, firmware or software, or at least a particular combination of both. It should be noted that the functionality associated with any particular controller may be local or remote, centralized or distributed.

[0036] Furthermore, the various functions described below may be implemented or supported by one or more computer programs, each of which is formed by computer-readable program code and implemented in a computer-readable medium. The terms "application program" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, associated data, or portions thereof implemented in appropriate computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium that can be accessed by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, optical disc (CD), digital video disc (DVD), or any other type of storage. "Non-transitory" computer-readable medium does not include wired, wireless, optical, or other communication links that transmit transient electrical signals or other signals. Non-transitory computer-readable medium includes media that can permanently store data and media that can store data and later overwrite said data, such as rewritable optical discs or erasable storage devices.

[0037] This patent document provides definitions for certain words and phrases, and those skilled in the art will understand that, in many cases, though not in most, such definitions apply to the prior and future use of the defined words and phrases.

[0038]

Advantages and Effects

[0039] According to an embodiment, an efficient method for mutual authentication in the access layer (AS) segment of a wireless communication system is provided. Attached Figure Description

[0040] To gain a more complete understanding of this disclosure and its advantages, reference will now be made to the following description taken in conjunction with the accompanying drawings, in which the same reference numerals denote the same parts:

[0041] Figure 1 This is a view illustrating the structure of an LTE system according to an embodiment;

[0042] Figure 2 This is a view illustrating the structure of the radio protocol in an LTE system according to an embodiment;

[0043] Figure 3 This is a view illustrating the structure of the radio protocol of a next-generation mobile communication system according to an embodiment;

[0044] Figure 4 This is a view illustrating a procedure for performing public key infrastructure (PKI)-based authentication when a UE establishes a connection with a base station, according to an embodiment.

[0045] Figure 5Aand 5B This is a view illustrating a procedure for identifying the validity of a certificate when performing PKI-based authentication during the establishment of a connection between a UE and a base station, according to an embodiment.

[0046] Figure 6A and 6B This is a view illustrating a procedure for identifying the validity of a certificate when performing PKI-based authentication during the establishment of a connection between a UE and a base station, according to an embodiment.

[0047] Figure 7A and 7B This is a view illustrating a procedure for identifying the validity of a certificate when performing PKI-based authentication during the establishment of a connection between a UE and a base station, according to an embodiment.

[0048] Figure 8A and 8B This is a view illustrating a procedure, according to an embodiment, for identifying the validity of a certificate after performing PKI-based authentication when a UE establishes a connection with a base station;

[0049] Figure 9 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0050] Figure 10 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0051] Figure 11 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0052] Figure 12 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0053] Figure 13 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0054] Figure 14 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0055] Figure 15 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity response message, according to an embodiment.

[0056] Figure 16 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity response message, according to an embodiment.

[0057] Figure 17 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity response message, according to an embodiment.

[0058] Figure 18 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity response message, according to an embodiment.

[0059] Figure 19 This is a view illustrating a procedure for identifying the validity of a certificate when the UE receives a base station certificate, according to an embodiment.

[0060] Figure 20 This is a view illustrating a procedure for requesting the download of a CRL while the UE is connected to Wi-Fi or RRC (RRC_Connected) according to an embodiment;

[0061] Figure 21 This is a view illustrating an example of a network managing multiple base stations in a single CRL area, according to an embodiment;

[0062] Figure 22 This is a view illustrating the procedure by which a base station broadcasts a CRL to a UE via a System Information Block (SIB) according to an embodiment;

[0063] Figure 23 This is a view illustrating a procedure, according to an embodiment, in which a base station sends CRL information stored therein in response to a CRL request from a UE;

[0064] Figure 24 This is a view illustrating a procedure in which a base station broadcasts a CRL in response to a request from a UE, according to an embodiment.

[0065] Figure 25 This is a view illustrating a procedure, according to an embodiment, in which a base station sends a CRL request to the network and receives a CRL from the network;

[0066] Figure 26 This is a view illustrating a procedure, according to an embodiment, for a network entity to identify whether a CRL received via unicast or a System Information Block (SIB) is the latest CRL;

[0067] Figure 27 This is a view illustrating the operation of a network entity authenticating a certificate according to an embodiment;

[0068] Figure 28 This is a view illustrating the operation of a UE authenticating a base station certificate according to an embodiment;

[0069] Figure 29 This is a view illustrating the operation when a UE fails to authenticate with a base station according to an embodiment;

[0070] Figure 30 This is a flowchart illustrating an operational method of a UE for mutual authentication in the access stratum (AS) segment according to an embodiment;

[0071] Figure 31 This is a flowchart illustrating an operational method of a base station for mutual authentication in the access layer (AS) segment according to an embodiment; and

[0072] Figure 32 This is a block diagram showing a UE and a base station according to an embodiment.

[0073] Throughout the specification and drawings, the same or similar reference numerals may be used to refer to the same or similar elements. Detailed Implementation

[0074] The following discussion Figures 1 to 32 The various embodiments used to describe the principles of this disclosure in this patent document are for illustrative purposes only and should not be construed as limiting the scope of this disclosure in any way. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or apparatus.

[0075] Wireless communication systems have evolved from voice-centric services to broadband wireless communication systems that provide high data rates and high-quality packet data services, such as the 3rd Generation Partnership Project (3GPP) High-Speed ​​Packet Access (HSPA), Long Term Evolution (LTE) or Evolved Universal Terrestrial Radio Access (E-UTRA), LTE-Advanced (LTE-A), LTE-pro, 3GPP2 High-Speed ​​Packet Data (HRPD), Ultra Mobile Broadband (UMB), and the Institute of Electrical and Electronics Engineers (IEEE) 802.16e communication standard.

[0076] As a representative example of such broadband wireless communication systems, the LTE system employs Orthogonal Frequency Division Multiplexing (OFDM) for the downlink (DL) and Single-Carrier Frequency Division Multiple Access (SC-FDMA) for the uplink (UL). The uplink refers to the radio link through which the UE (terminal or MS) transmits data or control signals to the base station (gNB, generating Node B, or eNB, eNode B, or BS), and the downlink refers to the radio link through which the base station transmits data or control signals to the UE. This multi-access scheme allocates and operates time-frequency resources carrying data or control information in a way that prevents overlap between users, i.e., maintains orthogonality, thereby distinguishing the data or control information for each user.

[0077] Post-LTE communication systems, such as 5G communication systems, need to be flexible enough to reflect the diverse needs of users and service providers, thereby supporting services that simultaneously meet various requirements. Services considered for 5G communication systems include, for example, enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable low-latency communications (URLLC).

[0078] eMBB aims to provide significantly enhanced data transmission rates compared to LTE, LTE-A, or LTE-pro. For example, eMBB for 5G communication systems requires a peak download data rate of 20Gbps and an uplink peak data rate of 10Gbps on a single base station. In addition to these peak data rates, 5G communication systems also need to provide higher user-perceived data rates. To meet these requirements, various transmit (TX) / receive (RX) technologies and multiple-input multiple-output (MIMO) technologies need to be further enhanced. While LTE currently uses up to 20MHz of TX bandwidth in the 2GHz band to transmit signals, 5G communication systems utilize wider frequency bandwidths in the 3GHz to 6GHz or even higher 6GHz flat bands to meet the data rates required by 5G communication systems.

[0079] mMTC is also seen as supporting application services such as the Internet of Things (IoT) in 5G communication systems. To effectively deliver IoT, mMTC needs to support a large number of UEs within a cell, enhance UE coverage and battery life, and reduce UE costs. IoT terminals connect to various sensors or devices to provide communication capabilities; therefore, it needs to support multiple UEs per cell (e.g., 1,000,000 UEs / km). 2 Because UEs supporting mMTC are likely to be located in shadow areas not covered by the cell, such as underground in buildings, depending on the nature of the service, they require a wider coverage area compared to other services provided by 5G communication systems. UEs supporting mMTC also need to have very long battery life, such as 10 to 15 years, due to their need for low cost and the difficulty in frequently replacing batteries.

[0080] URLLC is a cellular-based mission-critical wireless communication service. For example, URLLC can be used for remote control of robots or machinery, industrial automation, drones, remote healthcare, or emergency alerts. This requires URLLC to provide very low latency and very high reliability. For instance, services supporting URLLC need to simultaneously meet an air interface latency of less than 0.5 milliseconds and a data packet error rate of 10^6. -5 Or even lower. Therefore, for services that support URLLC, 5G communication systems need to provide shorter transmission time intervals (TTIs) than other services, while ensuring reliable communication links by allocating wide resources in the frequency band.

[0081] It is possible to multiplex and transmit three 5G services—eMBB, URLLC, and mMTC—within a single system. In this scenario, the services may employ different TX / RX schemes and parameters to meet their varying requirements.

[0082] More advanced services are emerging in the communications field, such as mobile holography, virtual reality, and augmented reality. To support these services, research is underway on key technologies in communications systems, including artificial intelligence (AI), sensing technologies, wired / wireless communication and network infrastructure, service interface technologies, and security technologies.

[0083] The embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0084] Descriptions of embodiments that are known to those skilled in the art and not directly related to this disclosure will be omitted. This is to further clarify the key points of this disclosure and to avoid ambiguity.

[0085] For the same reason, some elements may be exaggerated or shown schematically in the accompanying drawings. The size of each element does not necessarily reflect its actual size. The same reference numerals are used to refer to the same element throughout the drawings.

[0086] The advantages and features of this disclosure, as well as the methods for achieving such advantages and features, can be understood from the embodiments described below in conjunction with the accompanying drawings. However, this disclosure is not limited to the embodiments disclosed herein, and various modifications can be made thereto. The embodiments disclosed herein are only intended to inform those skilled in the art of the category of this disclosure. This disclosure is defined solely by the appended claims. Throughout the specification, the same reference numerals denote the same elements.

[0087] It should be understood that each block in a flowchart, and combinations thereof, can be executed by computer program instructions. Since computer program instructions can be mounted on the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, the instructions, which execute via the computer's processor or other programmable data processing device, generate components for performing the functions described in conjunction with the blocks in each flowchart. Since computer program instructions can be stored in computer-usable or computer-readable storage, and are directed to instruct the computer or other programmable data processing device to implement the functions in a specified manner, the instructions stored in computer-usable or computer-readable storage can produce a product comprising instruction components for performing the functions described in conjunction with the blocks in each flowchart. Since computer program instructions can be mounted on a computer or other programmable data processing device, the instructions that generate the process to be executed by the computer are executed as a series of operational steps on the computer or other programmable data processing device, and operating the computer or other programmable data processing device can provide steps for performing the functions described in conjunction with the blocks in each flowchart.

[0088] Furthermore, each box may represent a module, segment, or portion of code, including one or more executable instructions for performing a specified logical function. It should also be noted that in some alternative execution examples, the functions mentioned in the boxes may appear in a different order. For example, two boxes illustrated consecutively may execute substantially simultaneously or in reverse order, depending on the respective functions.

[0089] As used herein, the term "cell" refers to a software element or hardware element, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC). A cell plays a specific role. However, the term "cell" is not limited to referring to a software or hardware element. A "cell" can be configured in a storage medium that can be addressed or configured to reproduce one or more processors. Accordingly, as examples, a "cell" includes elements such as software elements, object-oriented software elements, class elements and task elements, processes, functions, attributes, programs, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data schemas, tables, arrays, and variables. The functionality provided in an element or "cell" can be combined with other elements or broken down into sub-elements or sub-cells. Furthermore, an element or "cell" can be implemented as one or more CPUs in a reproduction device or secure multimedia card. According to embodiments of this disclosure, "...cell" can include one or more processors.

[0090] The terms used herein to identify access nodes, network entities, messages, inter-network entity interfaces, and various identifying information are provided for ease of description. Therefore, this disclosure is not limited to these terms, and these terms may be replaced by other terms representing objects with equivalent technical concepts.

[0091] For ease of description, this disclosure uses terms and names as defined in 5G, NR, or LTE system standards. However, this disclosure is not limited to such terms and names and may also be applicable to systems conforming to other standards.

[0092] The description of the embodiments of this disclosure focuses primarily on 3GPP communication standards, but the subject matter of this disclosure can also be applied to other communication systems with similar technical backgrounds, but with slight modifications without significantly deviating from the scope of this disclosure, and can be determined by those skilled in the art related to this disclosure.

[0093] Figure 1 This is a view illustrating the structure of an LTE system according to an embodiment.

[0094] Figure 1 An example is shown according to an embodiment, in which the UE moves to change the base station to which the UE is connected among multiple base stations in a mobile communication system.

[0095] Base stations 1-20 and 1-30 can connect to some of their neighboring base stations, and base stations 1-20 and 1-30 can connect to mobile communication core networks (CN) 1-40, such as evolved packet core network (EPC) or 5G core network (5GC).

[0096] The radio access technology used for base stations 1-20 and 1-30 can be LTE, NR, or Wi-Fi, but is not limited to these. For example, base stations 1-20 and 1-30 can be mobile communication base stations independent of radio access technology.

[0097] UE 1-10 can connect to a base station to receive mobile communication services. As UE 1-10 moves, the connected base station may change, and UE 1-10 can seamlessly receive mobile communication services through a handoff (HO) procedure. Figure 1 In the example shown, UE 1-10 can connect to base station 1-20, and then disconnect from base station 1-20 by handover, while connecting to another base station 1-30.

[0098] Figure 2 This is a view illustrating the structure of the radio protocol in an LTE system according to an embodiment.

[0099] See Figure 2The LTE system radio protocols include Packet Data Convergence Protocol (PDCP) 2-110 and 2-210, Radio Link Control (RLC) 2-120 and 2-220, and Media Access Control (MAC) 2-130 and 2-230 for UE 2-100 and base station 2-200, respectively. Components of the radio protocols can be referred to as layers or entities, or devices.

[0100] PDCP 2-110 and 2-210 are responsible for IP header compression / reconstruction. The main functions of PDCP can be summarized as follows:

[0101] - Header compression and decompression (ROHC only);

[0102] - User data transmission;

[0103] - During the PDCP reconstruction process of RLC AM, upper-layer PDUs are delivered sequentially;

[0104] - For split bearers in the DC (RLC AM only), route the PDCP PDUs for transmission and reorder the PDCP PDUs for reception;

[0105] - Repeatedly detect the underlying service data unit (SDU) in the PDCP reconstruction procedure of RLC AM;

[0106] - For RLC AM, retransmit PDCP SDU during handover and (for split bearers in DC) retransmit PDCP PDU in the PDCP data recovery procedure;

[0107] - Encryption and decryption; and / or

[0108] - Timer-based SDUs are dropped in the uplink.

[0109] Radio Link Control (RLC) 2-120 and 2-220 reconfigure PDCP Packet Data Units (PDUs) to the appropriate size and perform ARQ operations. The main functions of the RLC can be summarized as follows:

[0110] -Transmission of upper-layer PDUs;

[0111] - Error correction via ARQ (for AM data transmission only);

[0112] - Segmentation, reassembly, and assembly of RLC SDUs (for UM and AM data transmission only);

[0113] - Re-segmentation of RLC data PDUs (for AM data transmission only);

[0114] - Reordering of RLC data PDUs (for UM and AM data transfer only);

[0115] - Duplicate detection (only for UM and AM data transfers);

[0116] - Protocol error detection (only for AM data transmission);

[0117] - RLC SDU discard (for UM and AM data transfer only); and / or

[0118] -RLC reconstruction.

[0119] MAC 2-130 and 2-230 connect to several RLC layer devices configured in a UE, multiplexing RLC PDUs to MAC PDUs and demultiplexing MAC PDUs back to RLC PDUs. The main functions of the MAC can be summarized as follows:

[0120] - Mapping between logical channels and transport channels;

[0121] - Multiplex MAC SDUs belonging to one or different logical channels into transport blocks (TBs) delivered to the physical layer on the transport channel, or demultiplex them from transport blocks (TBs) delivered from the physical layer on the transport channel;

[0122] - Scheduling information report;

[0123] - Error correction via HARQ;

[0124] - Priority processing between logical channels of a UE;

[0125] - Prioritization is performed among UEs through dynamic scheduling;

[0126] -MBMS service identification;

[0127] -Transmission format selection; and / or

[0128] -filling.

[0129] Physical layers 2-140 and 2-240 perform channel coding on data from higher layers and modulate it into OFDM symbols. They then transmit the OFDM symbols via a wireless channel or demodulate OFDM symbols received via a wireless channel, perform channel decoding on the symbols, and transmit them to higher layers.

[0130] Figure 3 This is a view illustrating the structure of a radio protocol for a next-generation mobile communication system according to an embodiment.

[0131] Reference Figure 3The radio protocols for next-generation mobile communication systems include NR Service Data Application Protocol (SDAP) 3-110 and 3-210, NR PDCP 3-120 and 3-220, NR RLC 3-130 and 3-230, and NR MAC 3-140 and 3-240, respectively, in UE 3-100 and NR base station 3-200. Components of the radio protocols can be referred to as layers or entities, or devices.

[0132] The main functions of NR SDAP 3-110 and 3-210 may include some of the following functions:

[0133] -Transmission of user plane data;

[0134] - Mapping between QoS flows and DRB for both DL and UL;

[0135] - Mark the QoS flow ID in both DL and UL packets; and / or

[0136] - Reflection QoS flow to DRB mapping for UL SDAP PDU.

[0137] For SDAP layer devices, the UE can be configured via RRC messages to use either SDAP layer functionality or the header of the SDAP layer device for each PDCP layer device, each bearer, or each logical channel. If the SDAP header is configured, the UE can be instructed to update or reset the uplink and downlink data bearer and QoS flow mapping information via a NAS-reflected QoS indicator and an AS-reflected QoS indicator. The SDAP header can include QoS flow ID information indicating QoS. QoS information can be used for data prioritization or scheduling to seamlessly support services.

[0138] The main functions of NR PDCP 3-120 and 3-220 may include some of the following functions:

[0139] - Header compression and decompression (ROHC only);

[0140] - User data transmission;

[0141] - Sequential delivery of upper-layer PDUs;

[0142] - Out-of-order delivery of upper-layer PDUs;

[0143] - Reordering of received PDCP PDUs;

[0144] - Duplicate detection of lower-level SDUs;

[0145] -Retransmission of PDCP SDU;

[0146] - Encryption and decryption; and / or

[0147] - Timer-based SDUs are dropped in the uplink.

[0148] NR PDCP reordering refers to reordering the PDCP PDUs received from the lower layer based on the PDCP sequence number (SN). It may include transmitting data in the reordered order or immediately transmitting it to a higher layer regardless of the order. It also involves reordering missing PDCP PDUs, reporting the status of missing PDCP PDUs to the transmitting part, and requesting the retransmission of missing PDCP PDUs.

[0149] The main functions of NR RLC 3-130 and 3-230 may include some of the following functions:

[0150] -Transmission of upper-layer PDUs;

[0151] - Sequential delivery of upper-layer PDUs;

[0152] - Out-of-order delivery of upper-layer PDUs;

[0153] - Error correction via ARQ;

[0154] - Assembly, segmentation, and reassembly of RLC SDUs;

[0155] - Resegmentation of RLC data PDUs;

[0156] - Reordering of RLC data PDUs;

[0157] -Repeated detection;

[0158] - Protocol error detection;

[0159] -RLC SDU discarded; and / or

[0160] -RLC reconstruction.

[0161] In-order delivery of NR RLC refers to transmitting RLC SDUs received from a lower layer to a higher layer in sequence. If an original RLC SDU is split into multiple subsequently received RLC SDUs, in-order delivery may include reassembling and transmitting these RLC SDUs, reordering received RLC PDUs based on the RLC SN or PDCP SN, recording missing RLC PDUs by reordering them, reporting the status of missing RLC PDUs to the transmitting part, and requesting retransmission of missing RLCPDUs. If missing RLC SDUs exist, in-order delivery may include transmitting only the RLCPDUs preceding the missing RLC SDU in sequence to a higher layer. Even if missing RLC SDUs exist, if a pre-set timer has expired, in-order delivery may include transmitting all RLC SDUs received before the timer started in sequence to a higher layer. Alternatively, even if missing RLC SDUs exist, if a pre-set timer has expired, in-order delivery may include transmitting all RLC SDUs received up to this point in sequence to a higher layer.

[0162] Furthermore, RLC PDUs can be processed in the order of reception (arrival order regardless of the SN sequence) and sent to the PDCP device, regardless of the order (out-of-order delivery). If the received RLC PDU is fragmented, the fragments stored in the buffer or received later can be received and reconstructed into a single complete RLC PDU, then the entire RLC PDU is processed and transmitted to the PDCP device. The NR RLC layer may not include splicing functionality, and this functionality can be performed by the NRMAC layer or replaced by the multiplexing functionality of the NR MAC layer.

[0163] Out-of-order delivery of NR RLC devices refers to the function of directly transmitting RLC SDUs received from a lower layer to an upper layer regardless of their order. Out-of-order delivery may include the function of reassembling and transmitting multiple received RLC SDUs, where a single RLC SDU has been segmented into the multiple received RLC SDUs, and may also include the function of storing the RLC SN or PDCP SN of the received RLC PDUs, reordering them, and recording lost RLC PDUs.

[0164] NR MACs 3-140 and 3-230 can connect to several NR RLC layer devices configured in a UE, and the main functions of the NR MAC can include the following:

[0165] - Mapping between logical channels and transport channels;

[0166] - MAC SDU multiplexing / demultiplexing;

[0167] - Scheduling information report;

[0168] - Error correction via HARQ;

[0169] - Priority processing between logical channels of a UE;

[0170] - Prioritization is performed among UEs through dynamic scheduling;

[0171] -MBMS service identification;

[0172] -Transmission format selection; and / or

[0173] -filling.

[0174] NR PHY layers 3-150 and 3-250 perform channel coding on data from higher layers and modulate it into OFDM symbols. They then transmit the OFDM symbols via a wireless channel or demodulate OFDM symbols received via a wireless channel, perform channel decoding on them, and transmit them to higher layers.

[0175] Figure 4 This image shows a view of a procedure for performing public key infrastructure (PKI)-based authentication when a UE establishes a connection with a base station, according to an embodiment.

[0176] Figure 4 This illustrates the mutual authentication procedure performed by UE 4-10 with base station 4-15 when UE initially accesses the base station or when UE switches from RRC idle mode or RRC inactive mode (or lightly connected mode) to RRC connected mode to connect to the network.

[0177] In this context, mutual authentication may include: 1) session key generation (key encapsulation) and 2) peer authentication (authentication). Session key generation (key encapsulation) is the process of generating a session key for secure communication between "communication targets" on the network, while peer authentication (authentication) means verifying that the "entity" generating the message on the network is indeed the "communication target".

[0178] In this disclosure, for session key generation (key encapsulation), UE 4-10 and base station 4-15 may exchange a random value for preventing eavesdropping by entities other than the communication target, and a PreMasterSecret for preventing man-in-the-middle (MITM) attacks, and then generate a gNB key.

[0179] Furthermore, in this disclosure, for peer authentication, UE 4-10 and base station 4-15 perform certificate reception, checks on certificate expiration, certificate validity checks, and certificate content checks. In this case, certificate validity checks mean checking for events such as certificate issuance cancellation, erroneous issuance, certificate errors, and key exposure.

[0180] exist Figure 4 In this process, UE 4-10 can first send an authentication request message (authentication request) including its own 6G identifier to base station 4-15 to access base station 4-15 (4-30).

[0181] Base station 4-15 receives an authentication request message from UE 4-10, and can then send a message (Auth-Req.) to UE 4-10 requesting authentication of EAP-TLS (TLS start) of base station 4-15 (4-40). Base station 4-15 may include a 6G key set identifier (6G_KSI) as an identifier for authentication, and an anti-bidding down between architectures (ABBA) parameter to prevent security features from bidding down from higher versions to lower versions, and send it (4-40).

[0182] When UE 4-10 receives TLS start information from base station 4-15, UE 4-10 can send an authentication response message (Auth-Resp.) including TLS client_hello information to base station 4-15 (4-50). The TLS client_hello information can represent a random value (or client seed value) used to prevent eavesdropping by entities other than the communication target.

[0183] Upon receiving the TLS client_hello information included in the authentication response message (Auth-Resp.) from UE 4-10, base station 4-15 may send an authentication request message (Auth-Req.) to UE 4-10 containing at least one of the following: TLS RAN_hello, TLS certificate (base station 4-15 certificate), TLS RAN_key_exchange (temporary session key), TLS certificate_request (whether the UE certificate was requested), TLS RAN_hello_done information, 6G KSI, and ABBA (4-60). The TLS RAN_hello information may include a random value (or RAN seed value) to prevent eavesdropping by entities other than the communication target. The TLS RAN_key_exchange information may include a temporary session key (PreMasterSecret) to prevent man-in-the-middle (MITM) attacks.

[0184] In this scenario, base station 4-15 can verify the UE certificate by setting the certificate_request, unless a TLS emergency call is used. UE 4-10 recognizes the base station certificate (TLS certificate) included in the authentication request message (Auth-Req.) of base station 4-15 and can perform authentication to determine if the base station certificate (TLS certificate) is a valid certificate (4-70). UE 4-10 can identify whether the base station certificate (TLS certificate) has expired, check the validity of the base station certificate (TLS certificate), and identify the content of the base station certificate (TLS certificate). UE 4-10 can perform validity checks on the base station certificate (TLS certificate) by identifying whether events such as certificate issuance cancellation, incorrect issuance, certificate errors, or key leakage exist.

[0185] The process of UE 4-10 verifying the base station certificate will be described in detail below with reference to the accompanying drawings.

[0186] After confirming that the certificate of base station 4-15 is not abnormal, UE 4-10 can send an authentication response message (Auth-Resp.) to base station 4-15 including at least one of the following: TLS certificate (UE certificate), TLS client_key_exchange (temporary session key), TLS certificate_verify, TLS change_cipher_spec (possibly chip specification information), and TLS completion information (4-80). The TLS client_key_exchange information may include a temporary session key (PreMasterSecret) used to prevent man-in-the-middle (MITM).

[0187] According to an embodiment, UE 4-10 can use the base station public key (TLS client_key_exchange) to encrypt the temporary session key and send the temporary session key to base station 4-15.

[0188] Upon receiving the certificate from UE 4-10, base station 4-15 identifies the UE 4-10 certificate (4-90). Base station 4-15 can determine whether the UE certificate (TLS certificate) has expired, check the validity of the base station certificate (TLS certificate), and identify the content of the UE certificate (TLS certificate). Base station 4-15 can perform validity checks on the UE certificate (TLS certificate) by identifying events such as certificate issuance cancellation, incorrect issuance, certificate errors, or key leakage.

[0189] Base station 4-15 can recognize the certificate of UE 4-10, select the appropriate encryption specification from the encryption specifications sent by UE 4-10, specify the certificate of UE 4-10 in TLS change_cipher_spec, and send an authentication request message (Auth-Req.) (4-100) including TLS completion information to UE 4-10. The authentication request message (Auth-Req.) may include 6G KSI and ABBA information (4-100).

[0190] UE 4-10 can send an Authentication Response Message (Auth-Resp) as a response to an Authentication Request Message (Auth-Req.) to base station 4-15 (4-110). Base station 4-15 can use the most valid 256 (128) bits of the generated EMSK as the session key (gNB key). A pseudo-random function (PRF) can be used when generating the EMSK. For example, the EMSK can be generated via hash-based RFC4306 using parameters including a first random value, a second random value, and a temporary session key (PreMasterSecret). Here, the Authentication Response Message (Auth-Resp) may include an EAP response and an EAP type (EAP-TLS).

[0191] Base station 4-15 can send an EAP success message to UE 4-10. The EAP success message indicates that it has successfully authenticated with UE 4-10 (EAP successful), including the 6G-KSI and ABBA parameters, and induces the gNB key (4-120). After receiving the EAP success message, UE 4-10 can use the most valid 256 (128) bits of EMSK as the session key (gNB key), and so can base station 4-15.

[0192] In other words, UE 4-10 can generate a session key using a temporary session key (TLS client_key_exchange) and the information required for authentication. A pseudo-random function (PRF) can be used when generating the EMSK. For example, the EMSK can be generated via hash-based RFC4306 using parameters including a first random value, a second random value, and a temporary session key (PreMasterSecret). Base station 4-15 can generate a session key using the temporary session key (TLS client_key_exchange) and the information required for authentication. According to an embodiment, base station 4-15 and UE 4-10 can negotiate an encryption algorithm after generating the session key.

[0193] Figure 5A and 5B This illustrates a procedure, according to an embodiment, for identifying the validity of a certificate when performing PKI-based authentication during the establishment of a connection between a UE and a base station.

[0194] Figure 5A and Figure 5B This illustrates the mutual authentication procedure performed by the UE with the base station when initially accessing the base station or when the UE switches from RRC idle mode or RRC inactive mode (or lightly connected mode) to RRC connected mode to connect to the network.

[0195] Figure 5A and Figure 5B The illustrated embodiment provides operations for downloading the Credential Revocation List (CRL) during the mutual authentication process and identifying whether the CRL includes the certificate of the corresponding base station (or the certificate of the corresponding UE). In this case, since UE 5-10 is not communicating, it cannot send a request for the CRL to a network entity (e.g., a certificate authority (CA) server), therefore base station 5-15 needs a procedure to forward (or allow) the UE's CRL request message to the network.

[0196] UE 5-10 can first send an authentication request message (authentication request) including its own 6G identifier to base station 5-15 to access base station 5-15 (5-30). Upon receiving the authentication request message from UE 5-10, base station 5-15 can send a message (Auth-Req.) (5-40) to UE 5-10 requesting authentication of base station 5-15 using EAP-TLS (TLS-started). Base station 5-15 can include in the authentication request message (Auth-Req) a 6G key set identifier (6G_KSI) as the identifier used for authentication, and ABBA parameters (5-40) to prevent security features from being down-bid from higher versions to lower versions.

[0197] When UE 5-10 receives TLS start information from base station 5-15, UE 5-10 can send an authentication response message (Auth-Resp.) (5-50) to base station 5-15, which includes TLS client_hello information.

[0198] Upon receiving the TLS client_hello information included in the authentication response message (Auth-Resp.) of UE 5-10, base station 5-15 may send an authentication request message (Auth-Req.) to UE 5-10 including at least one of the following: TLS RAN_hello, TLS certificate (base station certificate), TLS RAN_key_exchange, TLS certificate_request (whether the UE certificate is requested), TLS RAN_hello_done information, 6G KSI, and ABBA (5-60).

[0199] In this scenario, base station 5-15 can verify the UE certificate by setting the certificate_request, unless a TLS emergency call is used. UE 5-10 needs to verify the base station certificate included in the authentication request message from base station 5-15. Since the base station certificate was legally signed by the CA but may have been revoked later, UE 5-10 requires additional checks.

[0200] Therefore, UE 5-10 needs to receive a Credential Retraction List (CRL), which records whether the base station certificate has been revoked from the CA or the server designated by the CA for certificate verification contained in the base station certificate.

[0201] To send a CRL request message (CRL-req) to Unified Data Management (UDM) 5-30 to receive the CRL of the base station certificate, UE 5-10 can send a CRL request message (CRL-req(TLS Certificate Revocation List Download Request))(5-70) to base station 5-15.

[0202] Since UE 5-10 has not yet been authenticated when the CRL request message (CRL-req) is received, base station 5-15 should, by default, reject UE 5-10's NAS communication. However, base station 5-15 can exceptionally allow the sending of the CRL request message (CRL-req). Base station 5-15 can forward the CRL request message (CRL-req (TLS Certificate Revocation List Download Request)) to the network entity (NE), namely UDM 5-20 in the illustrated case, which acts as the CA (5-80) for the base station certificate. In this process, UE 5-10 can determine whether to forward the CRL request message (CRL-req) to a server known to base station 5-15 as the CA based on the information contained in the packet (e.g., IP or current information of the UE).

[0203] UDM 5-20 can recognize the CRL request message (CRL-Req) received from UE 5-10, and in order to send the CRL information requested by UE 5-10, sends a CRL response message (CRL-Resp (TLS Certificate Revocation List)) (5-90) to base station 5-15. Base station 5-15 can forward the CRL response message (TLS Certificate Revocation List (CRL-Resp)) including CRL information to UE 5-10 (5-100).

[0204] UE 5-10 can identify the base station certificate included in the authentication request message of base station 5-15 and perform authentication (5-110) to determine whether the base station certificate is a valid certificate.

[0205] After confirming that the certificate of base station 5-15 is not abnormal, UE 5-10 can send an authentication response message (Auth-Resp.) to base station 5-15 including at least one of the following: TLS certificate (UE certificate), TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec (possibly chip specification information), and TLS completion information (5-120). Upon receiving the certificate from UE 5-10, base station 5-15 can recognize the certificate of UE 5-10 (5-130).

[0206] According to an embodiment, the procedure for receiving a Certificate Revocation List (CRL) for a UE certificate from UDM 5-20 can be executed between operation 5-120 and operation 5-130.

[0207] To receive the CRL for the UE certificate, base station 5-15 can send a CRL request message (CRL-req) for the UE certificate to the network entity (NE), namely UDM 5-20 in the illustrated example, which acts as the CA for the UE certificate. UDM 5-20 can then send a CRL response message (CRL-Resp) to base station 5-15, which includes the CRL information for the UE certificate. Afterward, base station 5-15 can identify the CRL information for the UE certificate and determine whether the UE certificate has been revoked.

[0208] Base station 5-15 can recognize the certificate of UE 5-10, select the appropriate encryption specification from the encryption specifications sent by UE 5-10, specify the certificate of UE 5-10 in TLS change_cipher_spec, and send an authentication request message (5-140) including TLS completion information to UE 5-10. The authentication request message may include 6G KSI and ABBA information (5-140).

[0209] UE 5-10 can send an empty authentication response message (Auth-Resp) as a response to the authentication request message to base station 5-15 (5-150). Base station 5-15 uses the most valid 256 (128) bits of the generated EMSK as the gNB key. Base station 5-15 can send an EAP success message (EAP success) indicating normal authentication with UE 5-10 and induce the gNB key (5-160). Upon receiving EAP success, UE 5-10 uses the most valid 256 (128) bits of the EMSK as the gNB key, as done by base station 5-15.

[0210] Figure 6A and 6B This illustrates a procedure, according to an embodiment, for identifying the validity of a certificate when performing PKI-based authentication during the establishment of a connection between a UE and a base station.

[0211] Figure 6A and Figure 6B This illustrates the mutual authentication procedure performed by the UE with the base station when initially accessing the base station or when the UE switches from RRC idle mode or RRC inactive mode (or lightly connected mode) to RRC connected mode to connect to the network.

[0212] exist Figure 6A and Figure 6BIn the illustrated embodiment, the Online Certificate Status Protocol (OCSP) can be used during the mutual authentication process to identify whether the corresponding certificate (base station certificate or UE certificate) has been revoked. In this case, since UE 6-10 is not in communication and cannot send an OCSP request to the CA, base station 6-15 can perform a process that allows communication of the OCSP request message (OCSP-Req) to UE 6-10.

[0213] UE 6-10 can send an authentication request message (authentication request) including its own 6G identifier to base station 6-15 to access base station 6-15 (6-30). Upon receiving the authentication request message from UE 6-10, base station 6-15 can send a message (Auth-Req.) (6-40) to UE 6-10 requesting authentication of base station 6-15 using EAP-TLS (TLS start).

[0214] Base station 6-15 may include a 6G key set identifier (6G_KSI) in the authentication request message (Auth-Req), which is an identifier used for authentication, and ABBA parameters (6-40) used to prevent security features from bidding down from higher versions to lower versions.

[0215] When UE 6-10 receives TLS start information from base station 6-15, UE 6-10 can send an authentication response message (Auth-Resp.) including TLS client_hello information to base station 6-15 (6-50).

[0216] Upon receiving the TLS client_hello information included in the authentication response message (Auth-Resp.) from UE 6-10, base station 6-15 can send an authentication request message (Auth-Req.) to UE 5-10 containing at least one of the following: TLS RAN_hello, TLS certificate (base station certificate), TLS RAN_key_exchange, TLS certificate_request (whether the UE certificate is requested), TLS RAN_hello_done information, 6G KSI, and ABBA (6-60). In this case, base station 6-15 can verify the UE certificate by setting certificate_request, unless a TLS emergency call is used.

[0217] UE 6-10 needs to verify the base station certificate included in the authentication request message of base station 6-15. Since the base station certificate was legally signed by the CA but may have been revoked later, UE 6-10 needs to check whether the base station certificate has been revoked. In Figure 6, UE 6-10 can send a request for a response to the Online Certificate Status Protocol (OCSP) included in the certificate or a server designated by the CA. This protocol is used to identify in real time whether a base station certificate has been revoked.

[0218] To identify in real time whether the corresponding base station certificate has been revoked from UDM 6-20, UE 6-10 can send an OCSP request message (OCSP-req(TLS certificate status request))(6-70) to base station 6-15.

[0219] Since UE 6-10 has not yet been authenticated when it receives the OCSP request message (OCSP-req) from UE 6-10, base station 6-15 should reject NAS communication from UE 6-10 by default. However, base station 6-15 can exceptionally allow the transmission of the OCSP request message because it does not belong to normal data communication.

[0220] Base station 6-15 can forward OCSP request messages (TLS certificate status requests) to the NE, i.e., UDM6-20 in the illustrated example, which acts as the CA for the base station certificate (6-80). During this process, UE 6-10 can determine whether to forward the OCSP request message to a server known to base station 6-15 as the CA based on the messages contained in the packet (e.g., IP or current information of the UE).

[0221] UDM 6-20 recognizes the OCSP request message received from UE 6-10 and can send an OCSP response message (OCSP-Resp) to base station 6-15, which includes the base station certificate status information (TLS certificate status response) requested by UE 6-10 (6-90). Base station 6-15 can resend the OCSP response message (OCSP-Resp (TLS certificate status response)) to UE 6-10 (6-100).

[0222] UE 6-10 identifies the base station certificate included in the authentication request message of base station 6-15 and performs authentication (6-110) to determine whether the base station certificate is a valid certificate.

[0223] After confirming that the certificate of base station 6-15 is not abnormal, UE 6-10 can send an authentication response message (Auth-Resp.) to base station 6-15 including at least one of the following: TLS certificate (UE certificate), TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec (possibly chip specification information), and TLS completion information (6-120).

[0224] According to an embodiment, the process for identifying whether a UE certificate has been revoked via the Online Certificate Status Protocol (OCSP) of the UE certificate can be performed between operation 6-120 and operation 6-130.

[0225] To identify in real time whether a UE certificate has been revoked from UDM 6-20, base station 6-15 can send an OCSP request message (TLS certificate status request) for the UE certificate to NE, i.e., UDM 6-20, which serves as the CA for the base station certificate in the illustrated example. UDM 6-20 can then send an OCSP response message to base station 6-15, including the UE certificate status information (TLS certificate status response) requested by base station 6-15. Subsequently, base station 6-15 can identify whether the UE certificate has been revoked based on the UE certificate status response (TLS certificate status response).

[0226] Upon receiving the certificate from UE 6-10, base station 6-15 recognizes the certificate of UE 6-10 (6-130). Base station 6-15 can recognize the certificate of UE 6-10, select the appropriate encryption specification from the encryption specifications sent by UE 6-10, specify the certificate of UE 6-10 in TLS change_cipher_spec, and send an authentication response message (Auth-Resp) including TLS completion information to UE 6-10 (6-140). The authentication response message may also include 6G KSI and ABBA information (6-140). UE 6-10 may send an empty Auth-Resp message to the base station as a response (6-150). Base station 6-15 uses the most valid 256 (128) bits in the generated EMSK as the gNB key.

[0227] Base station 6-15 can send an EAP success message (EAP success) indicating normal authentication with UE 6-10 and induce the gNB key (6-160). Upon receiving EAP success, UE 6-10 uses the most valid 256 (128) bits in the EMSK as the gNB key, as done by base station 6-15.

[0228] Figure 7A and 7BThis is a view illustrating a procedure for identifying the validity of a certificate when performing PKI-based authentication during the establishment of a connection between a UE and a base station, according to an embodiment.

[0229] Figure 7A and Figure 7B This illustrates the mutual authentication procedure performed by the UE with the base station when initially accessing the base station or when the UE switches from RRC idle mode or RRC inactive mode (or lightly connected mode) to RRC connected mode to connect to the network.

[0230] Figure 7A and Figure 7B The illustrated embodiment provides operations for downloading the Credential Revocation List (CRL) during the mutual authentication process and identifying whether the CRL includes the certificate of the corresponding base station. In this case, since UE 7-10 is not communicating, it cannot send a CRL request to a network entity (e.g., a CA server), therefore base station 7-15 needs a procedure to forward (or allow) the UE's CRL request message to the network.

[0231] Despite Figure 5A and Figure 5B In the embodiments described, the UE and UDM send / receive CRL request / response messages via the base station during operations 5-70 and 5-100 during mutual authentication. Figure 7A and Figure 7B In the embodiment, after UE 7-10 and UDM 7-20 perform temporary mutual authentication between UE 7-10 and base station 7-15, they directly send / receive CRL request / response messages in operations 7-140 and 7-150.

[0232] UE 7-10 can first send an authentication request message (authentication request) including its own 6G identifier to base station 7-15 to access base station 7-15 (7-30).

[0233] After receiving the authentication request message from UE 7-10, base station 7-15 can send a message (Auth-Req.)(7-40) to UE 7-10 to request authentication of base station 7-15 using EAP-TLS (TLS start).

[0234] Base station 7-15 may include a 6G key set identifier (6G_KSI) as an identifier for authentication in the authentication request message (Auth-Req), as well as an anti-architecture downbidding (ABBA) parameter to prevent security features from downbidding from higher versions to lower versions, and send it to UE 7-10 (7-40).

[0235] When UE 7-10 receives TLS start information from base station 7-15, UE 7-10 can send an authentication response message (Auth-Resp.) including TLS client_hello information to base station 7-15 (7-50).

[0236] Upon receiving the TLS client_hello information included in the authentication response message (Auth-Resp.) of UE 7-10, base station 7-15 may send an authentication request message (Auth-Req.) to UE 7-10 including at least one of the following: TLS RAN_hello, TLS certificate (base station certificate), TLS RAN_key_exchange, TLS certificate_request (whether the UE certificate is requested), TLS RAN_hello_done information, 6G KSI, and ABBA (7-60).

[0237] In this scenario, base station 7-15 can verify the UE certificate by setting the certificate_request, unless a TLS emergency call is used. UE 7-10 needs to verify the base station certificate included in the authentication request message from base station 7-15. Since the base station certificate was legally signed by the CA but may have been revoked later, UE 7-10 needs to perform this check.

[0238] Therefore, UE 7-10 needs to receive a Credential Revocation List (CRL), which records whether the base station certificate has been revoked from the CA or the server designated by the CA for certificate verification contained in the base station certificate. However, since UE 7-10 has not yet been authenticated, UE 7-10 cannot perform both AS communication and NAS communication simultaneously.

[0239] UE 7-10 can temporarily perform authentication using only the base station certificate without verifying whether the certificate has been revoked (7-70). After determining that the certificate of base station 7-15 is not abnormal, UE 7-10 can respond by sending an authentication response message to base station 7-15 including the following: TLS certificate (UE certificate), TLS client_key_exchange, TLS certificate_verify, TLSchange_cipher_spec (possibly chip specification information), and TLS completion information (7-80).

[0240] Upon receiving the certificate from UE 7-10, base station 7-15 recognizes the certificate of UE 7-10 (7-90). Base station 7-15 can recognize the certificate of UE 7-10, select the appropriate encryption specification from the encryption specifications sent by UE 7-10, specify the certificate of UE 7-10 in TLS change_cipher_spec, and send an authentication request message including TLS completion information (7-100). The authentication request message may also include 6G KSI and ABBA information (7-100). UE 7-10 may send an empty Auth-Resp message to base station 7-15 as a response to it (7-110). Base station 7-15 uses the most valid 256 (128) bits in the generated EMSK as the gNB key. Base station 7-15 may send an EAP success message indicating normal authentication with UE 7-10 (EAP success) and induce the gNB key (7-120). Upon successful EAP reception, UE 7-10 uses the most valid 256 (128) bits of the EMSK as the gNB key, as base station 7-15 does.

[0241] Then UE 7-10 can perform authentication for NAS communication between the core network and the UE (7-130).

[0242] After performing NAS communication, UE 7-10 can verify whether the temporarily authenticated base station certificate has been revoked. UE 7-10 can send a CRL request message (CRL-req) for the base station certificate to UDM 7-20 (7-140). UDM 7-20 can recognize the CRL request message (CRL-Req) received from UE 7-10 and send the CRL information of the base station certificate requested by UE 7-10 to UE 7-10 (7-160).

[0243] Then, UE 7-10 can identify whether there is a base station certificate in the authentication request message of base station 7-15, and perform authentication to determine whether the base station certificate is a valid certificate (7-160).

[0244] According to an embodiment, base station 7-15 can send a CRL request message (CRL-req) for the UE certificate to UDM 7-20. UDM 7-20 can recognize the CRL request message (CRL-Req) for the UE certificate and send the CRL information of the base station certificate requested by base station 7-15 to base station 7-15.

[0245] Figure 8A and 8B This is a view illustrating a procedure for identifying the validity of a certificate when performing PKI-based authentication during the establishment of a connection between a UE and a base station, according to an embodiment.

[0246] Figure 8A and Figure 8B This illustrates the mutual authentication procedure performed by the UE with the base station when initially accessing the base station or when the UE switches from RRC idle mode or RRC inactive mode (or lightly connected mode) to RRC connected mode to connect to the network.

[0247] exist Figure 8A and Figure 8B In this embodiment, during the mutual authentication process, UE 8-10 needs to identify whether the certificate of base station 8-15 has been revoked via the Online Certificate Status Protocol (OCSP). However, since UE 8-10 is not in a communication state and cannot send an OCSP request to the CA, UE 8-10 can temporarily only identify the base station certificate, and after NAS authentication is completed, UE 7-10 can perform verification on whether the base station certificate has been revoked.

[0248] Despite Figure 6A and Figure 6B In the embodiments described, the UE and UDM send / receive OCSP request / response messages via the base station during operations 6-70 and 6-100 during mutual authentication. Figure 8A and Figure 8B In the embodiment, after UE 8-10 and UDM 8-20 perform temporary mutual authentication between UE 8-10 and base station 8-15, they directly send / receive OCSP request / response messages in operations 8-140 and 8-150.

[0249] UE 8-10 can first send an authentication request message (authentication request) including its own 6G identifier to base station 8-15 to access base station 8-15 (8-30).

[0250] Upon receiving the authentication request message from UE 8-10, base station 8-15 can send a message (Auth-Req.) (8-40) to UE 8-10 requesting authentication of base station 8-15 using EAP-TLS (TLS-Start). Base station 8-15 may include a 6G key set identifier (6G_KSI) as an identifier for authentication, and an anti-architecture downbidding (ABBA) parameter to prevent security features from downbidding from higher versions to lower versions in the authentication request message (Auth-Req), and send it to UE 8-10 (8-40).

[0251] When UE 8-10 receives TLS start information from base station 8-15, UE 8-10 can send an authentication response message (Auth-Resp.) including TLS client_hello information to base station 8-15 (8-50).

[0252] Upon receiving the TLS client_hello information included in the authentication response message (Auth-Resp.) of UE 8-10, base station 8-15 may send an authentication request message (Auth-Req.) to UE 8-10 including at least one of the following: TLS RAN_hello, TLS certificate (base station certificate), TLS RAN_key_exchange, TLS certificate_request (whether the UE certificate is requested), TLS RAN_hello_done information, 6G KSI, and ABBA (8-60).

[0253] In this scenario, base station 8-15 can verify the UE certificate by setting the certificate_request, unless a TLS emergency call is used. UE 8-10 needs to verify the base station certificate included in the authentication request message from base station 8-15.

[0254] Because base station certificates are legally signed by a CA but may later be revoked, UE 8-10 needs to check whether the base station certificate has been revoked. Therefore, UE 8-10 needs to receive an OCSP from the CA included in the certificate or a server designated by the CA for certificate verification to provide real-time notification of whether the corresponding base station certificate has been revoked.

[0255] However, since UE 8-10 has not yet been certified, it cannot perform both AS and NAS communication. Therefore, UE 8-10 can temporarily perform certification using only the base station certificate without verifying whether the certificate has been revoked (8-70).

[0256] After confirming that the certificate of base station 8-15 is not abnormal, UE 8-10 can respond by sending an authentication response message to base station 8-15 including the following: TLS certificate (UE certificate), TLS client_key_exchange, TLScertificate_verify, TLS change_cipher_spec (possible chip specification information), and TLS completion information (8-80).

[0257] Upon receiving the certificate from UE 8-10, base station 8-15 identifies the certificate (8-90). Base station 8-15 can recognize the certificate of UE 8-10, select an appropriate encryption specification from the encryption specifications sent by UE 8-10, specify the certificate of UE 8-10 in TLS change_cipher_spec, and send an authentication response message (8-100) to UE 8-10 including TLS completion information. The authentication response message may also include 6G KSI and ABBA information (8-100).

[0258] UE 8-10 can send an empty Auth-Resp message to base station 8-15 as a response (8-110). Base station 8-15 uses the most valid 256 (128) bits of the generated EMSK as the gNB key.

[0259] Base station 8-15 can send an EAP success message indicating normal authentication with UE 8-10 and induce the gNB key (8-120). Upon receiving a successful EAP, UE 8-10 uses the most valid 256 (128) bits of the EMSK as the gNB key, as done by base station 8-15.

[0260] Subsequently, UE 8-10 performs authentication for NAS communication between the core network and the UE (8-130). After performing NAS communication, UE 8-10 verifies whether the temporarily authenticated base station certificate has been revoked. To do this, UE 8-10 can send an OCSP request message (OCSP-req) for the base station certificate to UDM 8-20 (8-140). UDM 8-20 can recognize the OCSP request message (OCSP-Req) received from UE 8-10 and send an OCSP response message (OCSP-Resp) including the OCSP information requested by UE 8-10 to UE 8-10 (8-150).

[0261] UE 8-10 identifies whether the certificate of base station 8-15 has been revoked based on the OCSP response message, and performs authentication (8-160) to determine whether the base station certificate is a valid certificate.

[0262] According to an embodiment, base station 8-15 can send an OCSP request message (OCSP-req) for the UE certificate to UDM 8-20. UDM 8-20 can recognize the OCSP request message (OCSP-Req) for the UE certificate and send the OCSP information of the UE certificate requested by base station 8-15 to base station 8-15.

[0263] Figure 9 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0264] Figure 9 This illustrates an encryption method used by the UE to ensure message confidentiality when sending a message used to identify certificate revocation to the CA. In the authentication process for the UE to receive mobile communication services, specifically during the mutual authentication process between the UE and the base station, it is necessary to identify whether the certificate has been revoked by an unauthenticated base station before mutual authentication. In this case, encryption is required to protect the message used to identify whether the certificate has been revoked.

[0265] Figure 9 The message (CertValid-req) 9-10, ID 9-20, time 9-30, and UE private key 9-40 used to identify whether the certificate has been revoked are shown.

[0266] exist Figure 4 As shown in Figure 8, the message (CertValid-req) 9-10 used to identify whether a certificate has been revoked represents a message sent by the UE to the UDM to identify whether a certificate has been revoked. As an example, this message refers to a communication message (such as CRL or OCSP), but is not limited thereto and can include any communication message that can identify whether a certificate has been revoked.

[0267] ID 9-20 or 9-60 represents the identifier of the entity that sent the CertValid-req 9-10 message. Because the ID is included in the encrypted information, UDM can identify that the message was created by the sender and has not been tampered with by a hacker.

[0268] The time 9-30 or 9-70 indicates the time information when the message was sent. Because the time is included in the encrypted information, it prevents hackers from using the message for replay attacks. The time format can be represented in Coordinated Universal Time (UTC) or an offset from UTC, but is not limited to UTC.

[0269] The encrypted CertValid-req 9-50 is obtained by encrypting a message including CertValid-req 9-10, ID 9-20, and time 9-30 using the UE's private key 9-40.

[0270] According to one embodiment, a message including encrypted CertValid-req 9-50, ID 9-20, and time 9-30 can be generated to protect the message indicating whether a certificate has been revoked. According to another embodiment, a message including encrypted CertValid-req 9-50 and ID 9-20 can be generated to protect the message indicating whether a certificate has been revoked. According to yet another embodiment, a message including encrypted CertValid-req 9-50 and time 9-30 can be generated to protect the message indicating whether a certificate has been revoked.

[0271] Figure 10 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0272] Figure 10This illustrates an encryption method that ensures message integrity when the UE sends a message used to identify certificate revocation to the CA. In the authentication process for the UE to receive mobile communication services, specifically in the mutual authentication process between the UE and the base station, before the base station is authenticated, it is necessary to identify whether the certificate has been revoked via an unauthorized base station, and the message used for authentication needs to be encrypted and protected.

[0273] refer to Figure 10 The message (CertValid-req) 10-10, ID 10-20, time 10-30, and UE private key 10-90 used to identify whether the certificate has been revoked are shown.

[0274] The message used to identify whether a certificate has been revoked (CertValid-req) 10-10 represents a message sent by the UE to the UDM to identify whether a certificate has been revoked during the aforementioned process. As an example, the message used to identify whether a certificate has been revoked (CertValid-req) 10-10 refers to a communication message (such as CRL or OCSP), but is not limited thereto and may include any communication message that can identify whether a certificate has been revoked.

[0275] ID 10-20 or 10-60 represents the identifier of the entity that sent the CertValid-req 10-10 message. Because the ID is included in the encrypted information, UDM can identify that the message was created by the sender and has not been tampered with by a hacker.

[0276] The time 10-30 or 10-70 indicates the time information when the message was sent. Because the time is included in the encrypted information, it prevents hackers from using the message for replay attacks. The time format can be represented in Coordinated Universal Time (UTC) or an offset from UTC, but is not limited to UTC.

[0277] Hash value 10-80 is the value obtained by calculating a message that includes at least one of ID 10-20, time 10-30, and CertValid-req10-10 using a hash function.

[0278] exist Figure 10 In this context, a message can be generated that includes a value obtained by using the UE private key 10-90 to encrypt ID 10-20, time 10-30, CertValid-req 10-10, and a hash value, thereby protecting the message used to identify whether the certificate has been revoked.

[0279] Figure 11 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0280] Figure 11 This illustrates an encryption method for ensuring message confidentiality when the UE sends a message used to identify certificate revocation to the CA. In the authentication process for the UE to receive mobile communication services, specifically in the mutual authentication process between the UE and the base station, prior to the base station's authentication, it is necessary to identify whether the certificate has been revoked via an unauthorized base station, and the message used to identify whether the certificate has been revoked needs to be encrypted and protected.

[0281] Figure 11 The message (CertValid-req) 11-10, ID 11-20, time 11-30, and operator public key 11-40 used to identify whether the certificate has been revoked are shown.

[0282] The message used to identify whether a certificate has been revoked (CertValid-req) 11-10 refers to a message sent by the UE to the UDM to identify whether a certificate has been revoked. As an example, the message used to identify whether a certificate has been revoked (CertValid-req) 11-10 refers to a communication message (such as CRL or OCSP), but is not limited thereto and may include any communication message that can identify whether a certificate has been revoked.

[0283] ID 11-20 or 11-60 indicates the entity that sent the CertValid-req 11-10 message. Because the ID is included in the encrypted information, UDM can identify that the message was created by the sender and has not been tampered with by a hacker.

[0284] The time 11-30 or 11-70 indicates the time information when the message was sent. Because the time is included in the encrypted information, it prevents hackers from using the message for replay attacks. The time format can be represented in Coordinated Universal Time (UTC) or an offset from UTC, but is not limited to UTC.

[0285] The encrypted CertValid-req 11-50 is a message obtained by encrypting a message containing at least one of ID 3-20, time 11-30, and CertValid-req 11-10 using the operator's public key 11-40.

[0286] exist Figure 11 In this process, a message can be generated that includes at least one of ID 11-20, time 11-30, and encrypted CertValid-req11-50, thereby protecting the message used to identify whether the certificate has been revoked.

[0287] Figure 12 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0288] Figure 12 This illustrates an encryption method that ensures message integrity when the UE sends a message used to identify certificate revocation to the CA. In the authentication process for the UE to receive mobile communication services, specifically in the mutual authentication process between the UE and the base station, prior to authentication by the base station, it is necessary to identify whether the certificate has been revoked via an unauthorized base station. Therefore, the message used to identify whether the certificate has been revoked needs to be encrypted and protected.

[0289] Figure 12 The message (CertValid-req) 12-10, ID 12-20, time 12-30, and operator public key 12-90 used to identify whether the certificate has been revoked are shown.

[0290] The message used to identify whether a certificate has been revoked (CertValid-req) 12-10 represents a message sent by the UE to the UDM to identify whether a certificate has been revoked during the aforementioned process. As an example, the message used to identify whether a certificate has been revoked (CertValid-req) 12-10 refers to a communication message (such as CRL or OCSP), but is not limited thereto and may include any communication message that can identify whether a certificate has been revoked.

[0291] ID 12-20 or 12-60 indicates the entity that sent the CertValid-req 12-10 message. Because the ID is included in the encrypted information, UDM can identify that the message was created by the sender and has not been tampered with by a hacker.

[0292] The time 12-30 or 12-70 indicates the time information when the message was sent. Because the time is included in the encrypted information, it prevents hackers from using the message for replay attacks. The time format can be represented in Coordinated Universal Time (UTC) or an offset from UTC, but is not limited to UTC.

[0293] Hash value 12-80 is the value obtained by calculating a message that includes at least one of ID 12-20, time 12-30, and CertValid-req12-10 using a hash function.

[0294] exist Figure 12 In the illustrated embodiment, a message can be generated that includes a value obtained by encrypting at least one of CertValid-req 12-10, ID 12-20, and time 12-30, and a hash value using the operator's public key 12-90, thereby protecting the message used to identify whether the certificate has been revoked.

[0295] Figure 13 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0296] Figure 13 This illustrates an encryption method that provides message integrity and confidentiality when the UE sends a message used to identify certificate revocation to the CA.

[0297] In the authentication process for a UE to receive mobile communication services, specifically in the mutual authentication process between the UE and the base station, before the base station authenticates the UE, it is necessary to identify whether the certificate has been revoked by an unauthorized base station. Therefore, the message used to identify whether the certificate has been revoked needs to be encrypted and protected.

[0298] refer to Figure 13 The message (CertValid-req) 13-10, ID 13-20, time 13-30, UE private key 13-40, and operator public key 13-80 used to identify whether the certificate has been revoked are shown.

[0299] The message used to identify whether a certificate has been revoked (CertValid-req) 13-10 refers to a message sent by the UE to the UDM to identify whether a certificate has been revoked during the aforementioned process. As an example, the message used to identify whether a certificate has been revoked (CertValid-req) 13-10 refers to a communication message (such as CRL or OCSP), but is not limited thereto and may include any communication message that can identify whether a certificate has been revoked.

[0300] ID 13-20 or 13-60 indicates the entity that sent the CertValid-req 13-10 message. Because the ID is included in the encrypted information, UDM can identify that the message was created by the sender and has not been tampered with by a hacker.

[0301] The time 13-30 or 13-70 indicates the time information when the message was sent. Because the time is included in the encrypted information, it prevents hackers from using the message for replay attacks. The time format can be represented in Coordinated Universal Time (UTC) or an offset from UTC, but is not limited to UTC.

[0302] The encrypted CertValid-req 13-50 is a message obtained by encrypting a message including at least one of ID 13-20, time 11-30, and CertValid-req 13-10 using the UE private key 13-40.

[0303] exist Figure 13In the illustrated embodiment, a message obtained by re-encrypting a message including at least one of ID 13-20, time 13-30, and encrypted CertValid-req 13-50 using the operator's public key 13-80 can be generated to protect the message used to identify whether the certificate has been revoked.

[0304] Figure 14 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity request message, according to an embodiment.

[0305] Figure 14 This illustrates an encryption method that provides message integrity and confidentiality when the UE sends a message used to identify certificate revocation to the CA.

[0306] In the authentication process for a UE to receive mobile communication services, specifically in the mutual authentication process between the UE and the base station, before the base station authenticates the UE, it is necessary to identify whether the certificate has been revoked by an unauthorized base station. Therefore, the message used to identify whether the certificate has been revoked needs to be encrypted and protected.

[0307] refer to Figure 14 The message (CertValid-req) 14-10, ID 14-20, time 14-30, UE private key 14-90, and operator public key 14-100 used to identify whether the certificate has been revoked are shown.

[0308] The message used to identify whether a certificate has been revoked (CertValid-req) 14-10 refers to a message sent by the UE to the UDM to identify whether a certificate has been revoked during the aforementioned process. As an example, the message used to identify whether a certificate has been revoked (CertValid-req) 14-10 refers to a communication message (such as CRL or OCSP), but is not limited thereto and may include any communication message that can identify whether a certificate has been revoked.

[0309] ID 14-20 or 14-60 indicates the entity that sent the CertValid-req 14-10 message. Because the ID is included in the encrypted information, UDM can identify that the message was created by the sender and has not been tampered with by a hacker.

[0310] The time 14-30 or 14-70 indicates the time information when the message was sent. Because the time is included in the encrypted information, it prevents hackers from using the message for replay attacks. The time format can be represented in Coordinated Universal Time (UTC) or an offset from UTC, but is not limited to UTC.

[0311] Hash value 14-80 is the value obtained by hashing a message that includes at least one of ID 14-20, time 14-30, and CertValid-req14-10 using a hash function.

[0312] exist Figure 14 In the illustrated embodiment, a message for identifying whether a certificate has been revoked can be generated by encrypting the entirety of a value obtained by encrypting at least one of CertValid-req 14-20, ID 14-20, time 14-30, and hash value 14-80 using the operator public key 14-100.

[0313] Figure 15 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity response message, according to an embodiment.

[0314] Figure 15 This demonstrates an encryption method for providing confidentiality to a message when sending a certificate revocation response message to the UE.

[0315] In the authentication process for a UE to receive mobile communication services, specifically in the mutual authentication process between the UE and the base station, before the base station authenticates the UE, it is necessary to identify whether the certificate has been revoked by an unauthorized base station. Therefore, the message used to identify whether the certificate has been revoked needs to be encrypted and protected.

[0316] refer to Figure 15 This shows the message (CertValid-resp) 15-10, ID 15-20, time 15-30, and operator private key 15-40 used to respond to whether the certificate has been revoked.

[0317] The message used to respond to whether a certificate has been revoked (CertValid-resp) 15-10 represents a message sent by the CA to the UE regarding whether a certificate has been revoked. As an example, the message used to respond to whether a certificate has been revoked (CertValid-resp) 15-10 refers to a communication message (such as CRL or OCSP), but is not limited thereto and may include any message responding to a communication message that can identify whether a certificate has been revoked.

[0318] ID 15-20 or 15-60 indicates the entity that sent the CertValid-resp 15-10 message. Because the ID is included in the encrypted information, the UE can identify that the UDM message was created by the sender and has not been tampered with by a hacker.

[0319] The time 15-30 or 15-70 indicates the time information when the message was sent. Because the time is included in the encrypted information, it prevents hackers from using the message for replay attacks. The time format can be represented in Coordinated Universal Time (UTC) or an offset from UTC, but is not limited to UTC.

[0320] The encrypted CertValid-resp 15-50 is a message obtained by encrypting a message including at least one of ID 15-20, time 15-30, and CertValid-resp 15-10 using the operator's private key 15-40.

[0321] exist Figure 15 In the illustrated embodiment, a message including at least one of ID 15-20, time 15-30, and encrypted CertValid-resp 15-50 can be generated to protect the message used to identify whether the certificate has been revoked.

[0322] Figure 16 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity response message, according to an embodiment.

[0323] Figure 16 This demonstrates an encryption method for providing confidentiality to a message when sending a certificate revocation response message to the UE.

[0324] In the authentication process for a UE to receive mobile communication services, specifically in the mutual authentication process between the UE and the base station, before the base station authenticates the UE, it is necessary to identify whether the certificate has been revoked by an unauthorized base station. Therefore, the message used to identify whether the certificate has been revoked needs to be encrypted and protected.

[0325] refer to Figure 16 This shows the message (CertValid-resp) 16-10, ID 16-20, time 16-30, and operator private key 16-90 used to respond to whether the certificate has been revoked.

[0326] The message used to respond to whether a certificate has been revoked (CertValid-resp) 16-10 indicates that the CA sends a message to the UE with information about whether the certificate has been revoked. As an example, the message used to respond to whether a certificate has been revoked (CertValid-resp) 16-10 refers to a communication message (such as CRL or OCSP), but is not limited thereto, and may include any message responding to a communication message that can identify whether a certificate has been revoked.

[0327] ID 16-20 or 16-60 indicates the entity that sent the CertValid-resp 16-10 message. Because the ID is included in the encrypted information, UDM can identify that the message was created by the sender and has not been tampered with by a hacker.

[0328] The time 16-30 or 16-70 indicates the time information when the message was sent. Because the time is included in the encrypted information, it prevents hackers from using the message for replay attacks. The time format can be represented in Coordinated Universal Time (UTC) or an offset from UTC, but is not limited to UTC.

[0329] Hash value 16-80 is the value obtained by calculating a message that includes at least one of ID 16-20, time 16-30, and CertValid-resp16-10 using a hash function.

[0330] exist Figure 16 In the illustrated embodiment, a message can be generated that includes a value obtained by encrypting at least one of CertValid-resp 16-10, ID 16-20, and time 16-30, and a hash value using the operator's private key 16-90, thereby protecting the message used to identify whether the certificate has been revoked.

[0331] Figure 17 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity response message, according to an embodiment.

[0332] Figure 17 This demonstrates an encryption method for providing confidentiality to a message when sending a certificate revocation response message to the UE.

[0333] In the authentication process for a UE to receive mobile communication services, specifically in the mutual authentication process between the UE and the base station, before the base station authenticates the UE, it is necessary to identify whether the certificate has been revoked by an unauthorized base station. Therefore, the message used to identify whether the certificate has been revoked needs to be encrypted and protected.

[0334] refer to Figure 17 The message (CertValid-resp) 17-10, ID 17-20, time 17-30, and UE public key 17-40 are shown in response to whether the certificate has been revoked.

[0335] The message used to respond to whether a certificate has been revoked (CertValid-resp) 17-10 refers to a message sent by the CA to the UE regarding whether a certificate has been revoked. As an example, the message used to respond to whether a certificate has been revoked (CertValid-resp) 17-10 refers to a communication message (such as CRL or OCSP), but is not limited thereto and may include any message responding to a communication message that can identify whether a certificate has been revoked.

[0336] ID 17-20 or 17-60 indicates the entity that sent the CertValid-resp 17-10 message. Because the ID is included in the encrypted information, the UE can identify that the UDM message was created by the sender and has not been tampered with by a hacker.

[0337] The time 17-30 or 17-70 indicates the time information when the message was sent. Because the time is included in the encrypted information, it prevents hackers from using the message for replay attacks. The time format can be represented in Coordinated Universal Time (UTC) or an offset from UTC, but is not limited to UTC.

[0338] The encrypted CertValid-req 17-50 is a message obtained by encrypting a message including at least one of ID 17-20, time 17-30, and CertValid-req 17-10 using the UE public key 17-40.

[0339] exist Figure 17 In the illustrated embodiment, a message including at least one of ID 17-20, time 17-30, and encrypted CertValid-req 17-50 can be generated to protect the message in response to whether the certificate has been revoked.

[0340] Figure 18 This is a view illustrating an example of a UE applying encryption technology to prevent tampering with a certificate validity response message, according to an embodiment.

[0341] Figure 18 This demonstrates an encryption method that provides message integrity when sending a certificate revocation response message to the UE.

[0342] In the authentication process for a UE to receive mobile communication services, specifically in the mutual authentication process between the UE and the base station, before the base station authenticates the UE, it is necessary to identify whether the certificate has been revoked by an unauthorized base station. Therefore, the message used to identify whether the certificate has been revoked needs to be encrypted and protected.

[0343] refer to Figure 18The message (CertValid-resp) 18-10, ID 18-20, time 18-30, and UE public key 18-90 are shown in response to whether the certificate has been revoked.

[0344] The message used to respond to whether a certificate has been revoked (CertValid-resp) 18-10 refers to a message sent by the CA to the UE regarding whether a certificate has been revoked. As an example, the message used to respond to whether a certificate has been revoked (CertValid-resp) 18-10 refers to a communication message (such as CRL or OCSP), but is not limited thereto and may include any message responding to a communication message that can identify whether a certificate has been revoked.

[0345] ID 18-20 or 18-60 indicates the entity that sent the CertValid-req 18-10 message. Because the ID is included in the encrypted information, UDM can identify that the message was created by the sender and has not been tampered with by a hacker.

[0346] The time 18-30 or 18-70 indicates the time information when the message was sent. Because the time is included in the encrypted information, it prevents hackers from using the message for replay attacks. The time format can be represented in Coordinated Universal Time (UTC) or an offset from UTC, but is not limited to UTC.

[0347] Hash value 18-80 is the value obtained by calculating a message that includes at least one of ID 18-20, time 18-30, and CertValid-req18-10 using a hash function.

[0348] exist Figure 18 In the illustrated embodiment, a message can be generated that includes a value obtained by encrypting at least one of CertValid-resp 18-10, ID 18-20, and time 18-30, and a hash value using the operator's private key 18-90, thereby protecting the message used to identify whether the certificate has been revoked.

[0349] Figure 19 This is a view illustrating a procedure for identifying the validity of a certificate when the UE receives a base station certificate, according to an embodiment.

[0350] See Figure 19 The UE can identify whether it has received a certificate from the base station (19-20). The UE can send a message to the CA to identify whether the certificate has been revoked (CertValid-req) and start a timer T. cert (19-30).

[0351] If in timer T certNo response to the Certificate Revocation Request (CertValid-req) message was received within the set time, and timer T... cert If the time limit expires (19-40), the UE can determine that the base station is an invalid base station (19-50).

[0352] If in timer T cert If a message responding to a Certificate Revocation Identification Request (CertValid-req) is received within the set time (19-60), the UE can identify whether the base station's certificate has been revoked in the Certificate Revocation Response Message (19-70).

[0353] If the base station certificate is revoked and therefore invalid, the UE can determine that the base station is invalid (19-50). If the base station certificate is not revoked and the base station certificate is valid, the UE can determine that the corresponding base station is valid.

[0354] Figure 20 This is a view illustrating a procedure for requesting the download of a CRL while the UE is connected to Wi-Fi or RRC (RRC_Connected) according to an embodiment.

[0355] CRLs have a reliable validity period. Therefore, UEs can download CRLs in advance when communication is possible and use them for base station authentication within the validity period.

[0356] When UE 20-10 is in a Wi-Fi connected state or RRC_connected state (20-30), UE 20-10 can send a request to UDM (or CA) for a CRL that includes a list of revoked base station certificates (TLS Certificate Revocation List Download Request) (20-40).

[0357] Accordingly, UDM 20-20 can include the CRL in the certificate revocation response message and send the CRL to UE20-10 (20-50). UE 20-10 stores the CRL therein (or in a database) (20-60) and uses the CRL for subsequent authentication.

[0358] According to the embodiment, UE 20-10 can include past and current location information in the CRL request message (TLS certificate revocation list download request) and send the past and current location information (20-40), and UDM 20-20 can send the CRL required by the UE, instead of a list of all base station certificates to be revoked, thereby taking into account the location information included in the CRL request message and the UE mobility information retained in the network (20-50).

[0359] Figure 21This is a view illustrating an example of a network managing multiple base stations in a single CRL area, according to an embodiment.

[0360] When a network creates a single CRL for the certificates of all base stations managed by the network, the data volume increases, and radio resources may be wasted due to CRL transmission / reception. Furthermore, the CRL needs to be updated whenever a base station certificate is renewed / revoked.

[0361] Therefore, a method is provided in which network-managed base stations are divided into CRL regions, and CRLs are managed by region, such as... Figure 21 As shown.

[0362] The network can generate a CRL for each region by considering at least one of the following: the location of the base station, the average mobility information of the UE, the mobility information of an individual UE, and CRL request statistics based on location or mobility. When generating a CRL for each region, for example, it may include a Registration Area (RA), a Tracking Area (TA), and a list of base stations so that the UE can know its location information when receiving the CRL.

[0363] Each region represents a set of one or more base stations (cells), and a base station can belong to one or more CRL regions. CRL regions typically consist of base stations that are in physically adjacent regions but are not necessarily physically adjacent.

[0364] During the transmission of the CRL for each CRL region, the UE can send a CRL request message (CRL-req), which includes, for example, UE location information (e.g., GPS), base station PCI information, and base station certificate information. The network can send the UE a CRL generated by comprehensively considering not only the UE's current location information, but also the UE's past mobility information, predicted future mobility information, and base station deployment information for network management.

[0365] Figure 22 This is a view illustrating the procedure by which a base station broadcasts a CRL to a UE via a System Information Block (SIB) according to an embodiment.

[0366] Since CRL information is valid for all UEs, broadcasting is more advantageous than unicasting in terms of radio resource efficiency.

[0367] Figure 22 The method provided is a procedure by which base station 22-20 periodically (or aperiodically) sends CRL information to UE 22-10 via System Information Block (SIB).

[0368] Base stations 22-20 can periodically (using T) CRLThe UE 22-10 can send CRL information to the UE 22-10 either periodically or non-periodically, and when the UE 22-20 receives the CRL broadcast from the base station 22-20, the UE 22-10 can identify whether the certificate of the base station 22-20 has been revoked.

[0369] Using this method, UE 22-10 can receive CRL information from the SIB of neighboring cells and from the serving cell. Furthermore, using this method, UE 22-10 can receive CRL information from the SIB sent by base station 22-20, which is not only in an RRC connected state but also in an RRC idle state or an RRC inactive state (if necessary).

[0370] Base station 22-20 can set an information bit in the SIB to indicate that an SIBx for transmitting the CRL has been sent, and broadcast this information bit (22-30). Base station 22-20 can transmit SIBx including the CRL (22-50).

[0371] Base stations 22-20 can periodically (using T) CRL (Timer) or send CRL information non-periodically (22-40).

[0372] According to the embodiment, the CRL information is periodic (using T) CRL In the case of timer) sending (22-40), at T CRL After the timer expires, base station 22-20 can set an information bit in the SIB indicating that the SIBx used for transmitting the CRL has been sent, and then broadcast this information bit again (22-60). Afterwards, base station 22-20 can send SIBx including the CRL (22-70).

[0373] UE 22-10 receives and stores the CRL, and uses the CRL to identify whether the certificate has been subsequently revoked (22-80). The CRL sent by base station 22-20 has a CRL identifier so that it can be distinguished from CRLs sent by another base station or from previous and subsequent CRLs, and UE 22-10 can distinguish and manage the CRL identifier. An embodiment of a method for managing the UE's CRL identifier is described below.

[0374] Figure 23 This is a view illustrating a procedure, according to an embodiment, in which a base station sends CRL information stored therein in response to a CRL request from a UE.

[0375] Since CRL information is valid for all UEs, base station 23-20 can store CRL information internally and immediately send it to UE 23-10, instead of downloading and relaying CRL information from CA every time.

[0376] See Figure 23 UE 23-10 can send a request for CRL to CA (23-30) by sending a Base Station Certificate Revocation Request message (CRL_Req) ​​to base station 23-20.

[0377] Base station 23-20 can identify base station information, which is to be identified from message 23-30 sent from UE 22-10, and if CRL exists in it (23-40), it immediately sends a CRL request response message (CRL_resp) including CRL to UE 22-10 (23-50).

[0378] In the above operation, UE 22-10 can set a bit in CRL-req 23-30 that enables base station 22-20 to respond to the CRL stored therein. If UE 22-10 wants to receive a response from CA instead of the CRL stored in base station 22-20, UE 22-10 can receive the CRL from CA by not setting this bit.

[0379] UE 23-10 receives and stores the CRL, and uses the CRL to identify whether the certificate has been subsequently revoked (23-60). The CRL sent by base station 22-20 has a CRL identifier so that it can be distinguished from the CRL sent by another base station or from previous and subsequent CRLs, and the UE can distinguish and manage the CRL identifier.

[0380] Figure 24 This is a view illustrating a procedure in which a base station broadcasts a CRL in response to a request from a UE, according to an embodiment.

[0381] Since CRL information is valid for all UEs, base station 24-20 can store CRL information internally and immediately send it to UE 24-10, instead of downloading and relaying CRL information from CA every time.

[0382] See Figure 24 UE 24-10 can send a request for CRL (24-30) to UDM 24-20 by sending a Base Station Certificate Revocation Request message (CRL_Req) ​​to Base Station 24-15.

[0383] Base station 24-15 identifies the base station information in the message (CRL_Req) ​​sent by UE 24-10, and if the CRL is not present, the base station certificate revocation request message (CRL_Req) ​​can be resent to UDM 24-20 (24-50).

[0384] When base station 24-15 receives a certificate revocation information response message (CRL_Resp) from UDM 24-20 (24-60), base station 24-15 can store the CRL information in it (24-70).

[0385] Base station 24-15 can set a bit in the SIB to indicate that SIBx for transmitting CRL is to be sent, and broadcast this bit (24-80). Afterwards, base station 24-15 can broadcast SIBx including CRL (24-90).

[0386] UE 24-10 receives and stores the CRL, and uses the CRL to identify whether the certificate was subsequently revoked (24-100). The CRL sent by base station 24-15 has a CRL identifier so that it can be distinguished from the CRL sent by another base station or from previous and subsequent CRLs, and the UE can distinguish and manage the CRL identifier.

[0387] Figure 25 This is a view illustrating a procedure, according to an embodiment, in which a base station sends a request for a CRL to the network and receives the CRL from the network.

[0388] See Figure 25 Base station 25-10 can send a base station certificate revocation request message (CRL_Req) ​​(25-30) to UDM 25-20. UDM 25-20 can send a base station certificate revocation response message (CRL_Resp) including the CRL (25-40) to base station 25-10.

[0389] Base station 25-10 can store CRL information (25-50) included in the base station certificate revocation response message (CRL_Resp). The CRL sent by UDM 25-20 has a CRL identifier that makes it distinguishable from CRLs sent by another base station or CRLs sent before and after, and the UE can distinguish and manage these identifiers.

[0390] Figure 26 This is a view illustrating a procedure, according to an embodiment, for a network entity to identify whether a CRL received via unicast or SIB is the latest CRL.

[0391] exist Figure 26 In this context, a network entity (NE) refers to any entity that intends to identify whether a certificate has been revoked, as well as a UE or a base station.

[0392] When the NE receives a CRL (26-20), the NE can identify the CRL's identifier and check if a previously received (stored) CRL (26-30) exists in the same region as the received CRL. If no previously received CRL exists in the same region, the NE can store the CRL (26-50). The NE can also identify the CRL's identifier, and if a previously received CRL (26-30) exists in the same region as the received CRL, it checks if the CRL is a new CRL (26-40). If the CRL is a new CRL, the NE can store the CRL (26-50).

[0393] Figure 27 This is a view illustrating the operation of a network entity authenticating a certificate according to an embodiment.

[0394] exist Figure 27 In this context, a network entity (NE) refers to any entity that intends to identify whether a certificate has been revoked, as well as a UE or a base station.

[0395] When a NE receives a certificate from another NE (27-20), the NE can determine whether the certificate format is valid (27-30). If the certificate format is valid, the NE can determine whether the certificate has expired by checking the certificate's expiration date (27-40).

[0396] If the certificate has not expired, the NE can identify whether the certificate has been revoked (27-50). As a result of this identification, if the certificate has not been revoked, the NE corresponding to the certificate can be considered a valid NE (27-60).

[0397] If any of procedures 27-30, 27-40, and 27-50 are not met, the NE corresponding to the certificate may be considered an invalid NE, and the NE may be determined as an authentication failure.

[0398] Figure 28 This is a view illustrating the operation of a UE authenticating a base station certificate according to an embodiment.

[0399] When the UE receives the base station certificate (28-20), the UE can identify whether the base station certificate format is valid (28-30). If the base station certificate format is valid, the UE can identify whether the certificate has expired by checking the certificate's authentication validity period (28-40).

[0400] If the base station certificate has not expired, the UE can identify whether the base station certificate has been revoked (28-50). As a result of this identification, if the base station certificate has not been revoked, the base station corresponding to that certificate can be considered a valid base station (28-60).

[0401] If any of procedures 28-30, 28-40, and 28-50 are not met, the base station corresponding to the certificate may be considered an invalid base station, and the UE may determine that the base station's authentication has failed.

[0402] Figure 29 This is a view illustrating the operation when a UE fails to authenticate with a base station according to an embodiment.

[0403] Figure 29 This demonstrates the procedure for a UE connected to a base station to fail to authenticate the base station and report this to the network.

[0404] Reference Figure 29 UE 29-10 can first send an authentication request message (authentication request) including its own 6G identifier to the first base station 29-15 to access the first base station 29-15 (29-30).

[0405] After receiving the authentication request message from UE 29-10, the first base station 29-15 may send a message (Auth-Req.)(29-40) to the UE requesting authentication from the first base station 29-15 via EAP-TLS (TLS start).

[0406] The first base station 29-15 can send an authentication request message (Auth-Req) to the UE 29-10, which includes a 6G key set identifier (6G_KSI) as an identifier for authentication, and an anti-architecture downbidding (ABBA) parameter (29-40) to prevent security features from bidding down from higher versions to lower versions.

[0407] When UE 29-10 receives TLS start information from the first base station 29-15, UE 29-10 can send an authentication response message (Auth-Resp.) including TLS client_hello information to the first base station 29-15 (29-50).

[0408] Upon receiving the TLS client_hello information included in the authentication response message (Auth-Resp.) of UE 29-10, the first base station 29-15 may send an authentication request message (Auth-Req.) to UE 29-10 including at least one of the following: TLS RAN_hello, TLS certificate (first base station certificate), TLS RAN_key_exchange, TLScertificate_request (whether the UE certificate is requested), TLS RAN_hello_done information, 6G KSI, and ABBA (29-60).

[0409] In this scenario, the first base station 29-15 can verify the UE certificate by setting the certificate_request, unless a TLS emergency call is used. The UE 29-10 can recognize the first base station certificate included in the authentication request message of the first base station 29-15 and perform authentication to determine whether the first base station certificate is a valid certificate (29-70).

[0410] During the process of UE 29-10 recognizing the certificate of the first base station 29-15, authentication failed (29-70). Then UE 29-10 connected to the second base station 29-20 and was able to successfully perform authentication (29-80).

[0411] When NAS communication is possible, UE 29-10 can send a message (Auth-Failure-Report) (29-90) to UDM 29-25 regarding the previous authentication failure of the first base station 29-15. In this case, the authentication failure message (Auth-Failure-Report) of the first base station 29-15 can include information that the first base station 29-15 has failed in authentication, such as the certificate and PCI information of the first base station 29-15. Subsequently, UDM 29-25 can send a response message (Auth-Failure-Report-Resp.) (29-100) to UE 29-10 regarding the authentication failure of the first base station 29-15.

[0412] Figure 30 This is a flowchart illustrating an operational method of a UE for mutual authentication in the access stratum (AS) segment according to an embodiment.

[0413] See Figure 30 In operation 30-10, the UE may send a first message to the base station including a first random value. The first random value may represent a value used to prevent eavesdropping by entities other than the communication target (or a client seed value). Figures 4 to 8B The TLS client_hello information shown.

[0414] In operation 30-20, the UE can receive a second message from the base station, including a second random value and the base station certificate. The second random value may represent a value (or a server seed value) used to prevent eavesdropping by entities other than the communication target. Figures 4 to 8B The TLS Server_hello information shown.

[0415] In operation 30-30, the UE can identify and authenticate the base station certificate.

[0416] In operations 30-40, when the base station certificate authentication is completed based on the authentication result, the UE can send a third message to the base station including the UE certificate and a temporary session key. The temporary session key can be used to prevent man-in-the-middle attacks (MITMs) and can be used when generating the session key. The temporary session key can represent... Figures 4 to 8B The TLSclient_key_exchange information shown.

[0417] In operations 30-50, when the UE certificate authentication is completed, the UE can receive a fourth message from the base station indicating that the mutual authentication between the UE and the base station is complete.

[0418] According to an embodiment, a session key between the UE and the base station can be generated based on a first random value, a second random value, and a temporary session key.

[0419] According to an embodiment, the UE can send a certificate revocation information request message to the base station to receive revocation information of the base station certificate from the certificate verification server. The UE can receive a certificate revocation information response message from the base station, which includes the revocation information of the base station certificate sent from the certificate verification server.

[0420] According to an embodiment, the revocation information of a base station certificate may be a Credential Revocation List (CRL) that indicates a certificate revocation list or an Online Certificate Status Protocol (OCSP) used to identify whether a base station certificate has been revoked.

[0421] According to an embodiment, the UE can execute a mutual authentication procedure between the UE and the certificate verification server. The UE can send a certificate revocation information request message to the certificate verification server to request the revocation information of the base station certificate. The UE can receive a certificate revocation information response message from the certificate verification server, which includes the revocation information of the base station certificate.

[0422] According to an embodiment, the revocation information of a base station certificate may be a Credential Revocation List (CRL) that indicates a certificate revocation list or an Online Certificate Status Protocol (OCSP) used to identify whether a base station certificate has been revoked.

[0423] According to an embodiment, the certificate revocation request message can be encrypted based on at least one of the UE's private key, a hash function, and the operator's public key.

[0424] According to an embodiment, the certificate revocation request message may be encrypted together with at least one of the following: the identification information of the entity that sent the certificate revocation request message, and the time information of sending the certificate revocation request message.

[0425] According to an embodiment, the certificate revocation information response message can be encrypted based on at least one of the UE's private key, a hash function, and the operator's public key.

[0426] According to an embodiment, the certificate revocation information response message may be encrypted together with at least one of the following: the identification information of the entity receiving the certificate revocation information response message, and the time information of sending the certificate revocation information response message.

[0427] According to an embodiment, CRL can be managed for each Registration Area (RA) or each Tracking Area (TA) based on the location information of at least one base station and the mobility information of at least one UE.

[0428] According to an embodiment, the UE can receive a first SIB from the base station. The UE can receive a second SIB from the base station based on the first SIB, the second SIB including a Credential Revocation List (CRL) indicating a Certificate Revocation List.

[0429] According to an embodiment, based on the authentication result of the base station certificate, the UE may fail to authenticate the base station certificate and then perform a mutual authentication procedure with another base station. The UE may send an authentication failure report message indicating the failure of mutual authentication with the base station to the certificate verification server. The UE may receive an authentication failure report response message corresponding to the authentication failure report message from the certificate verification server.

[0430] Figure 31 This is a flowchart illustrating an operational method of a base station for mutual authentication in the access layer (AS) segment according to an embodiment.

[0431] See Figure 31 In operation 31-10, the base station may receive a first message including a first random value from the UE. The first random value may represent a value (or a client seed value) used to prevent eavesdropping by entities other than the communication target. Figures 4 to 8B The TLS client_hello information shown.

[0432] In operation 31-20, the base station may send a second message to the UE including a second random value and the base station's certificate. The second random value may represent a value used to prevent eavesdropping by entities other than the communication target (or a server seed value). Figures 4 to 8B The TLS Server_hello information shown.

[0433] In operations 31-30, when the base station certificate authentication is complete, the base station can receive a third message from the UE including the UE certificate and a temporary session key. The temporary session key can be used to prevent man-in-the-middle attacks (MITMs) and can be used when generating the session key. The temporary session key can represent... Figures 4 to 8B The TLS client_key_exchange information shown.

[0434] In operations 31-40, the base station can identify the UE certificate and authenticate the UE certificate.

[0435] In operations 31-50, when the UE certificate authentication is completed, the base station can send a fourth message to the UE indicating that the mutual authentication between the UE and the base station is complete.

[0436] According to an embodiment, a session key between the UE and the base station can be generated based on a first random value, a second random value, and a temporary session key.

[0437] According to an embodiment, the base station can receive a certificate revocation information request message from the UE, which is used by the UE to receive revocation information of the base station certificate from the certificate verification server. The base station can send a certificate revocation information response message to the UE, which includes the revocation information of the base station certificate sent from the certificate verification server.

[0438] According to an embodiment, the revocation information of a base station certificate may be a Credential Revocation List (CRL) that indicates a certificate revocation list or an Online Certificate Status Protocol (OCSP) used to identify whether a base station certificate has been revoked.

[0439] According to an embodiment, the certificate revocation request message can be encrypted based on at least one of the UE's private key, a hash function, and the operator's public key.

[0440] According to an embodiment, the certificate revocation information response message can be encrypted based on at least one of the UE's private key, a hash function, and the operator's public key.

[0441] According to an embodiment, CRL can be managed for each Registration Area (RA) or each Tracking Area (TA) based on the location information of at least one base station and the mobility information of at least one UE.

[0442] According to an embodiment, the base station may send a first SIB to the UE. Based on the first SIB, the base station may send a second SIB to the UE, including a Credential Revocation List (CRL) indicating a Certificate Revocation List.

[0443] Figure 32 This is a block diagram illustrating a UE and a base station according to an embodiment.

[0444] See Figure 32 UE 32-100 may include transceiver 32-110, controller 32-120, and storage device 32-130. However, the components of UE 32-100 are not limited to the examples shown above. For example, UE 32-100 may include more or fewer components than illustrated. Transceiver 32-110, storage device 32-130, and controller 32-120 may be implemented as a single chip.

[0445] Transceiver 32-110 can transmit / receive signals to / from base station 32-140. Signals may include control information and data. For this purpose, transceiver 32-110 may include a radio frequency (RF) transmitter for up-converting and amplifying the transmitted signals, and an RF receiver for low-noise amplification and down-converting the received signals. However, this is merely an example of transceiver 32-110, and the components of transceiver 32-110 are not limited to RF transmitters and RF receivers. Transceiver 32-110 can receive signals via a radio channel, output signals to controller 32-120, and transmit signals output from controller 32-120 via a radio channel. Transceiver 32-110 may include RF transceivers for a first wireless communication technology and RF transceivers for a second wireless communication technology, or a single transceiver may be used to perform physical layer processing according to both the first and second wireless communication technologies.

[0446] Storage device 32-130 can store programs and data necessary for operating UE 32-100. Storage device 32-130 can store control information or data included in signals sent and received by UE 32-100. Storage device 32-130 may include storage media such as ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media. Multiple storage devices 32-130 may be provided.

[0447] Controller 32-120 can control a series of operations to allow UE 32-100 to operate according to the above embodiments. For example, controller 32-120 can calculate and determine authentication information and certificate information received from base station 32-140 via transceiver 32-110. Multiple controllers 32-120 can be configured. Controller 32-120 can control components of UE 32-100 by executing programs stored in storage device 32-130.

[0448] Base station 32-140 may include transceiver 32-150, controller 32-160, connector 32-170, and storage device 32-180. However, the components of base station 32-140 are not limited to the examples shown above. For example, base station 32-150 may include more or fewer components than illustrated. Transceiver 32-150, storage device 32-180, and controller 32-160 may be implemented as a single chip.

[0449] Transceiver 32-150 can transmit / receive signals to / from UE 32-100. Signals may include control information and data. For this purpose, transceiver 32-150 may include a radio frequency (RF) transmitter for up-converting and amplifying the transmitted signals, and an RF receiver for low-noise amplification and down-converting the received signals. However, this is merely an example of transceiver 32-150, and the components of transceiver 32-150 are not limited to RF transmitters and RF receivers. Transceiver 32-150 can receive signals via a radio channel, output signals to controller 32-160, and transmit signals output from controller 32-160 via a radio channel.

[0450] Controller 32-160 can control a series of operations to allow base station 32-140 to operate according to the embodiments described above. For example, controller 32-160 can generate authentication and certificate information to be sent to UE 32-100 and send it to UE 32-100 via transceiver 32-150. Multiple controllers 32-160 can be configured. Controller 32-160 can control components of base station 32-140 by executing programs stored in storage device 32-180.

[0451] Storage device 32-180 can store programs and data required for base station operation. Storage device 32-180 can store control information or data included in signals transmitted and received by base station 32-100. Storage device 32-180 may include storage media such as ROM, RAM, hard disk, CD-ROM, and DVD, or combinations of storage media. Multiple storage devices 32-140 may be provided.

[0452] Connector 32-170 is a device that connects base station 32-140 to the core network and can perform physical layer processing for sending and receiving messages, sending messages to the core network, and receiving messages from the core network.

[0453] The methods described in the embodiments of this disclosure or in the claims can be implemented in hardware, software, or a combination of hardware and software.

[0454] When implemented in software, a computer-readable storage medium may be provided to store one or more programs (software modules). The one or more programs stored in the computer-readable storage medium may be configured to be executed by one or more processors within an electronic device. The one or more programs include instructions that enable the electronic device to perform methods according to embodiments described in this disclosure or the claims.

[0455] The program (software module or software) may be stored in random access memory, non-volatile memory (including flash memory, ROM, electrically erasable programmable read-only memory (EEPROM), disk storage devices, optical disc ROM, digital versatile optical disc DVD) or other types of optical storage devices or magnetic tape. Alternatively, the program may be stored in a memory consisting of all or part of it. Since each constituting memory may include multiple memories.

[0456] The program can be stored in connectable storage devices that can be accessed via a communication network, such as the Internet, intranet, local area network (LAN), wide area network (WLAN), or storage area network (SAN), or a combination thereof. The storage device can be connected to a device executing embodiments of this disclosure via an external port. A separate storage device can be connected to a device executing embodiments of this disclosure via a communication network.

[0457] In the specific embodiments described above, components included in this disclosure are represented in either a singular or plural form, according to the provided specific embodiments. However, the choice of singular or plural form is appropriate for describing the proposed context, and this disclosure is not limited to singular or plural components. The singular forms “a,” “an,” and “the” used herein are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0458] As can be clearly seen from the above description, according to this disclosure, the security of wireless communication between the UE and the base station can be enhanced through PKI-based access layer (AS) authentication in a wireless communication system.

[0459] Although this disclosure has been described with reference to various embodiments, those skilled in the art may make various changes and modifications.

[0460] This disclosure is intended to include changes and modifications that fall within the scope of the appended claims.

Claims

1. A method for a user equipment (UE) to perform mutual authentication operations in the access layer (AS) segment of a wireless communication system, the method comprising: Send a first message, including a first random value, to the base station; In response to sending the first message, a second message including a second random value and the base station certificate of the base station is received from the base station; Send a certificate revocation information request message to the base station to receive the revocation information of the base station certificate from the certificate verification server; Receive a certificate revocation information response message from the base station, the certificate revocation information response message including the revocation information of the base station certificate; The validity of the base station certificate is determined based on the information included in the base station certificate and the revocation information of the base station certificate; Based on the determination that the base station certificate is valid, a third message including the UE certificate and a temporary session key is sent to the base station; as well as Upon completion of the UE certificate authentication operation, a fourth message indicating the completion of the mutual authentication operation between the UE and the base station is received from the base station. The session key of the base station is generated based on the first random value, the second random value, and the temporary session key, and The revocation information of the base station certificate includes a Credential Revocation List (CRL) indicating the certificate revocation list, and the revocation information of the base station certificate is identified based on the location information of at least one base station and the mobility information of at least one UE, according to the Registration Area (RA) or the Tracking Area (TA).

2. The method according to claim 1, wherein the certificate revocation information request message is encrypted based on at least one of the UE's private key, hash function, and operator public key.

3. The method of claim 2, wherein the certificate revocation request message is encrypted together with at least one of the following: identification information of the entity sending the certificate revocation request message, and time information of sending the certificate revocation request message.

4. The method according to claim 1, wherein the certificate revocation information response message is encrypted based on at least one of the operator's private key, hash function, and operator's public key.

5. The method of claim 4, wherein the certificate revocation information response message is encrypted together with at least one of the following: identification information of the entity receiving the certificate revocation information response message, and time information of sending the certificate revocation information response message.

6. The method of claim 1, further comprising: Based on the determination that the base station certificate is invalid, a mutual authentication operation with another base station is performed; Upon completion of the mutual authentication operation with another base station, an authentication failure report message indicating that the mutual authentication operation with the base station failed is sent to the certificate verification server. as well as Receive an authentication failure report response message from the certificate verification server in response to the authentication failure report message.

7. A method for a base station to perform mutual authentication operations in the access layer AS segment of a wireless communication system, the method comprising: Receive a first message from the UE, which includes a first random value; In response to receiving the first message, a second message including a second random value and the base station certificate of the base station is sent to the UE; The UE receives a certificate revocation information request message to receive the revocation information of the base station certificate from the certificate verification server. Send a certificate revocation information response message to the UE, the certificate revocation information response message including the revocation information of the base station certificate; Upon completion of the authentication operation of the base station certificate, a third message including the UE certificate and a temporary session key is received from the UE. The validity of the UE certificate is determined based on the information included in the UE certificate. as well as Based on the determination that the UE certificate is valid, a fourth message is sent to the UE indicating that the mutual authentication operation between the UE and the base station has been completed. The session key of the base station is generated based on the first random value, the second random value, and the temporary session key, and The revocation information of the base station certificate includes a Credential Revocation List (CRL) indicating the certificate revocation list, and the revocation information of the base station certificate is identified based on the location information of at least one base station and the mobility information of at least one UE, according to the Registration Area (RA) or the Tracking Area (TA).

8. The method of claim 7, wherein the certificate revocation request message is encrypted based on at least one of the UE's private key, a hash function, and the operator's public key, and The certificate revocation response message is encrypted based on at least one of the operator's private key, hash function, and operator's public key.

9. The method of claim 7, wherein the base station certificate revocation information is managed based on the location information of at least one base station and the mobility information of at least one UE, according to the registration area (RA) or the tracking area (TA).

10. A user equipment (UE) for performing mutual authentication operations in the access layer (AS) segment of a wireless communication system, the UE comprising: transceiver; as well as A controller, coupled to the transceiver and configured to control the transceiver: Send a first message including a first random value to the base station. In response to sending the first message, a second message including a second random value and the base station certificate of the base station is received from the base station. Send a certificate revocation request message to the base station to receive the certificate revocation information of the base station from the certificate verification server. The system receives a certificate revocation information response message from the base station, the message including the revocation information of the base station's certificate. The validity of the base station certificate is determined based on the information included in the base station certificate and the revocation information of the base station certificate. Based on the determination that the base station certificate is valid, a third message including the UE certificate and a temporary session key is sent to the base station, and Upon completion of the UE certificate authentication operation, a fourth message indicating the completion of the mutual authentication operation between the UE and the base station is received from the base station. The session key of the base station is generated based on the first random value, the second random value, and the temporary session key, and The revocation information of the base station certificate includes a Credential Revocation List (CRL) indicating the certificate revocation list, and the revocation information of the base station certificate is identified based on the location information of at least one base station and the mobility information of at least one UE, according to the Registration Area (RA) or the Tracking Area (TA).

11. The UE of claim 10, wherein the certificate revocation request message is encrypted based on at least one of the UE's private key, a hash function, and the operator's public key, and The certificate revocation response message is encrypted based on at least one of the operator's private key, hash function, and operator's public key.

12. A base station for performing mutual authentication operations in the access layer AS segment of a wireless communication system, the base station comprising: transceiver; as well as A controller, coupled to the transceiver and configured to control the transceiver: Receive a first message from the UE, including a first random value. In response to receiving the first message, a second message including a second random value and the base station certificate of the base station is sent to the UE. The UE receives a certificate revocation request message to receive the revocation information of the base station certificate from the certificate verification server. A certificate revocation information response message is sent to the UE, the certificate revocation information response message including the revocation information of the base station certificate. Upon completion of the authentication operation of the base station certificate, a third message including the UE certificate and a temporary session key is received from the UE. The validity of the UE certificate is determined based on the information included in the UE certificate, and Based on the determination that the UE certificate is valid, a fourth message is sent to the UE indicating that the mutual authentication operation between the UE and the base station has been completed. The session key of the base station is generated based on the first random value, the second random value, and the temporary session key, and The revocation information of the base station certificate includes a Credential Revocation List (CRL) indicating the certificate revocation list, and the revocation information of the base station certificate is identified based on the location information of at least one base station and the mobility information of at least one UE, according to the Registration Area (RA) or the Tracking Area (TA).

Images