KR20230152990A - Mutual tls authentication system and device with aka - Google Patents

Abstract

In an authentication system according to various embodiments, the authentication system includes an electronic device that performs AKA authentication and TLS authentication functions, and a mobile core that performs AKA authentication and TLS authentication functions, and the electronic device performs AKA authentication and TLS authentication functions in the TLS handshake step. A client message containing an authentication is sent to the mobile core, the mobile core derives encryption material based on the client message and calculates a TLS symmetric encryption key, and the mobile core includes AKA authentication in the TLS handshake phase. A server message is transmitted to the electronic device, the electronic device derives encryption data based on the server message and calculates a TLS symmetric encryption key, and the electronic device and the mobile core establish a secure channel based on the TLS symmetric encryption key. generates, and the electronic device and the mobile core can exchange data through the secure channel.
In addition, various embodiments are possible.

Description

MUTUAL TLS AUTHENTICATION SYSTEM AND DEVICE WITH AKA}

Various embodiments disclosed in this document relate to mutual TLS authentication via AKA between an electronic device and a mobile core.

TLS and AKA authentication systems are completely separate. AKA is used for mobile radio access network (RAN) connectivity and IP layer authentication (IMS, XCAP), while TLS is used for other applications, primarily HTTPS traffic.

The AKA authentication system can establish a fast mutual authentication and secure encrypted channel between an electronic device and a mobile network within a single handshake.

TLS can establish a secure encrypted channel, but in most cases there is only one-way authentication from the server to the electronic device. Additionally, the TLS server must have a certificate chain ultimately signed by a trusted root CA, and the client must be provisioned with a trusted root CA database containing the CA used to sign the server certificate.

TLS certificates can provide a high level of security due to the use of asymmetric encryption and PKI infrastructure. However, TLS authentication has the following limitations. For example, your TLS server must have a valid certificate, the certificate has an expiration time after which it must be replaced, and if a new name or new IP address is assigned to the server, a completely new certificate must be generated and installed. Additionally, certificates are generated by an external organization called a CA (Certificate Authority), so it requires time and money. Additionally, the CA private key can be compromised and there is no easy way to revoke all derived certificates. Additionally, root CA/intermediate CA certificates must be provisioned to the clients. Additionally, the client does not authenticate to the server (until a client certificate is distributed) and TLS provides only one-way authentication.

The TLS-AKA authentication system according to various embodiments of the present invention can perform authentication using the AKA procedure in the TLS handshake step. Specifically, the TLS-AKA authentication system can calculate the TLS symmetric encryption key by transmitting AKA messages to each other in the TLS handshake stage and deriving encryption data for the symmetric encryption key. Accordingly, the TLS-AKA authentication system can eliminate PKI maintenance overhead, provide mutual authentication, improve security, and enable the use of various services.

The technical problem to be achieved in this document is not limited to the technical problem mentioned above, and other technical problems not mentioned can be clearly understood by those skilled in the art from the description below. There will be.

In an authentication system according to various embodiments, the authentication system includes an electronic device that performs AKA authentication and TLS authentication functions, and a mobile core that performs AKA authentication and TLS authentication functions, and the electronic device performs AKA authentication and TLS authentication functions in the TLS handshake step. A client message containing an authentication is sent to the mobile core, the mobile core derives encryption material based on the client message and calculates a TLS symmetric encryption key, and the mobile core includes AKA authentication in the TLS handshake phase. A server message is transmitted to the electronic device, the electronic device derives encryption data based on the server message and calculates a TLS symmetric encryption key, and the electronic device and the mobile core establish a secure channel based on the TLS symmetric encryption key. generates, and the electronic device and the mobile core can exchange data through the secure channel.

TLS-AKA systems according to various embodiments may utilize security credentials generated by xSIM and subscriber management devices through procedures similar to AKA in the TLS handshake.

In the TLS-AKA system according to various embodiments, the AKA encryption suite is used so that PKI certificates are no longer needed, so PKI maintenance overhead is not incurred and there is no need to revoke PKI certificates.

In the TLS-AKA system according to various embodiments, network operators can easily modify the server's IP address and FQDN without having to update the PKI certificate.

In TLS-AKA systems according to various embodiments, security is no longer anchored to server names and/or IP addresses, so operators can easily add or modify server names and/or IP addresses without using new certificates.

In the TLS-AKA system according to various embodiments, PKI-based TLS provides one-way authentication, while at the TLS level, client-to-server and server-to-client mutual authentication is possible.

In the TLS-AKA system according to various embodiments, the TLS handshake can establish a TLS session with four messages.

The TLS-AKA system according to various embodiments can strengthen immunity against MITM attacks and phishing attacks.

In the TLS-AKA system according to various embodiments, the existing AKA encryption suite can be reused for TLS purposes.

In the TLS-AKA system according to various embodiments, the security paradigm is based on per-user shared secrets, so that if one user credential (i.e. one xSIM UICC) is compromised, it can be easily replaced with a new credential and such security breach may not affect other users.

In relation to the description of the drawings, identical or similar reference numerals may be used for identical or similar components .
1 is a block diagram of an electronic device in a network environment, according to various embodiments.
FIG. 2A is a diagram illustrating an AKA authentication operation between the electronic device 210 and the mobile network 220.
FIG. 2B is a diagram illustrating a TLS authentication operation between the client 230 and the server 240.
FIG. 3 is a diagram illustrating a TLS-AKA authentication system between the electronic device 300 and the mobile core 1000 according to various embodiments.
FIG. 4 is a diagram illustrating a TLS-AKA authentication system between the electronic device 300 and the mobile core 1000 according to various embodiments.
FIGS. 5A and 5B are diagrams illustrating the operational flow between the former device 300 and the mobile core 1000 in the AKA mode in the TLS-AKA system according to various embodiments.
6A and 6B are diagrams illustrating the operation flow of fast mode in the TLS-AKA system according to various embodiments.
FIGS. 7A and 7B are diagrams illustrating the operation flow of the DH mode in the TLS-AKA system according to various embodiments.
FIGS. 8A, 8B, and 8C are diagrams illustrating a TLS-AKA system according to various embodiments.

1 is a block diagram of an electronic device 101 in a network environment 100, according to various embodiments. Referring to FIG. 1, in the network environment 100, the electronic device 101 communicates with the electronic device 102 through a first network 198 (e.g., a short-range wireless communication network) or a second network 199. It is possible to communicate with at least one of the electronic device 104 or the server 108 through (e.g., a long-distance wireless communication network). According to one embodiment, the electronic device 101 may communicate with the electronic device 104 through the server 108. According to one embodiment, the electronic device 101 includes a processor 120, a memory 130, an input module 150, an audio output module 155, a display module 160, an audio module 170, and a sensor module ( 176), interface 177, connection terminal 178, haptic module 179, camera module 180, power management module 188, battery 189, communication module 190, subscriber identification module 196 , or may include an antenna module 197. In some embodiments, at least one of these components (eg, the connection terminal 178) may be omitted or one or more other components may be added to the electronic device 101. In some embodiments, some of these components (e.g., sensor module 176, camera module 180, or antenna module 197) are integrated into one component (e.g., display module 160). It can be.

The processor 120, for example, executes software (e.g., program 140) to operate at least one other component (e.g., hardware or software component) of the electronic device 101 connected to the processor 120. It can be controlled and various data processing or calculations can be performed. According to one embodiment, as at least part of data processing or computation, the processor 120 stores commands or data received from another component (e.g., sensor module 176 or communication module 190) in volatile memory 132. The commands or data stored in the volatile memory 132 can be processed, and the resulting data can be stored in the non-volatile memory 134. According to one embodiment, the processor 120 includes a main processor 121 (e.g., a central processing unit or an application processor) or an auxiliary processor 123 that can operate independently or together (e.g., a graphics processing unit, a neural network processing unit ( It may include a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor). For example, if the electronic device 101 includes a main processor 121 and a secondary processor 123, the secondary processor 123 may be set to use lower power than the main processor 121 or be specialized for a designated function. You can. The auxiliary processor 123 may be implemented separately from the main processor 121 or as part of it.

The auxiliary processor 123 may, for example, act on behalf of the main processor 121 while the main processor 121 is in an inactive (e.g., sleep) state, or while the main processor 121 is in an active (e.g., application execution) state. ), together with the main processor 121, at least one of the components of the electronic device 101 (e.g., the display module 160, the sensor module 176, or the communication module 190) At least some of the functions or states related to can be controlled. According to one embodiment, co-processor 123 (e.g., image signal processor or communication processor) may be implemented as part of another functionally related component (e.g., camera module 180 or communication module 190). there is. According to one embodiment, the auxiliary processor 123 (eg, neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. Artificial intelligence models can be created through machine learning. For example, such learning may be performed in the electronic device 101 itself on which the artificial intelligence model is performed, or may be performed through a separate server (e.g., server 108). Learning algorithms may include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but It is not limited. An artificial intelligence model may include multiple artificial neural network layers. Artificial neural networks include deep neural network (DNN), convolutional neural network (CNN), recurrent neural network (RNN), restricted boltzmann machine (RBM), belief deep network (DBN), bidirectional recurrent deep neural network (BRDNN), It may be one of deep Q-networks or a combination of two or more of the above, but is not limited to the examples described above. In addition to hardware structures, artificial intelligence models may additionally or alternatively include software structures.

The memory 130 may store various data used by at least one component (eg, the processor 120 or the sensor module 176) of the electronic device 101. Data may include, for example, input data or output data for software (e.g., program 140) and instructions related thereto. Memory 130 may include volatile memory 132 or non-volatile memory 134.

The program 140 may be stored as software in the memory 130 and may include, for example, an operating system 142, middleware 144, or application 146.

The input module 150 may receive commands or data to be used in a component of the electronic device 101 (e.g., the processor 120) from outside the electronic device 101 (e.g., a user). The input module 150 may include, for example, a microphone, mouse, keyboard, keys (eg, buttons), or digital pen (eg, stylus pen).

The sound output module 155 may output sound signals to the outside of the electronic device 101. The sound output module 155 may include, for example, a speaker or a receiver. Speakers can be used for general purposes such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. According to one embodiment, the receiver may be implemented separately from the speaker or as part of it.

The display module 160 can visually provide information to the outside of the electronic device 101 (eg, a user). The display module 160 may include, for example, a display, a hologram device, or a projector, and a control circuit for controlling the device. According to one embodiment, the display module 160 may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of force generated by the touch.

The audio module 170 can convert sound into an electrical signal or, conversely, convert an electrical signal into sound. According to one embodiment, the audio module 170 acquires sound through the input module 150, the sound output module 155, or an external electronic device (e.g., directly or wirelessly connected to the electronic device 101). Sound may be output through the electronic device 102 (e.g., speaker or headphone).

The sensor module 176 detects the operating state (e.g., power or temperature) of the electronic device 101 or the external environmental state (e.g., user state) and generates an electrical signal or data value corresponding to the detected state. can do. According to one embodiment, the sensor module 176 includes, for example, a gesture sensor, a gyro sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, It may include a temperature sensor, humidity sensor, or light sensor.

The interface 177 may support one or more designated protocols that can be used to connect the electronic device 101 directly or wirelessly with an external electronic device (eg, the electronic device 102). According to one embodiment, the interface 177 may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

The connection terminal 178 may include a connector through which the electronic device 101 can be physically connected to an external electronic device (eg, the electronic device 102). According to one embodiment, the connection terminal 178 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (eg, a headphone connector).

The haptic module 179 can convert electrical signals into mechanical stimulation (e.g., vibration or movement) or electrical stimulation that the user can perceive through tactile or kinesthetic senses. According to one embodiment, the haptic module 179 may include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

The camera module 180 can capture still images and moving images. According to one embodiment, the camera module 180 may include one or more lenses, image sensors, image signal processors, or flashes.

The power management module 188 can manage power supplied to the electronic device 101. According to one embodiment, the power management module 188 may be implemented as at least a part of, for example, a power management integrated circuit (PMIC).

The battery 189 may supply power to at least one component of the electronic device 101. According to one embodiment, the battery 189 may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

Communication module 190 is configured to provide a direct (e.g., wired) communication channel or wireless communication channel between electronic device 101 and an external electronic device (e.g., electronic device 102, electronic device 104, or server 108). It can support establishment and communication through established communication channels. Communication module 190 operates independently of processor 120 (e.g., an application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module 190 is a wireless communication module 192 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 194 (e.g., : LAN (local area network) communication module, or power line communication module) may be included. Among these communication modules, the corresponding communication module is a first network 198 (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network 199 (e.g., legacy It may communicate with an external electronic device 104 through a telecommunication network such as a cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., LAN or WAN). These various types of communication modules may be integrated into one component (e.g., a single chip) or may be implemented as a plurality of separate components (e.g., multiple chips). The wireless communication module 192 uses subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in the subscriber identification module 196 within a communication network such as the first network 198 or the second network 199. The electronic device 101 can be confirmed or authenticated.

The wireless communication module 192 may support 5G networks after 4G networks and next-generation communication technologies, for example, NR access technology (new radio access technology). NR access technology provides high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and access to multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low latency). -latency communications)) can be supported. The wireless communication module 192 may support high frequency bands (eg, mmWave bands), for example, to achieve high data rates. The wireless communication module 192 uses various technologies to secure performance in high frequency bands, for example, beamforming, massive array multiple-input and multiple-output (MIMO), and full-dimensional multiplexing. It can support technologies such as input/output (FD-MIMO: full dimensional MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module 192 may support various requirements specified in the electronic device 101, an external electronic device (e.g., electronic device 104), or a network system (e.g., second network 199). According to one embodiment, the wireless communication module 192 supports Peak data rate (e.g., 20 Gbps or more) for realizing eMBB, loss coverage (e.g., 164 dB or less) for realizing mmTC, or U-plane latency (e.g., 164 dB or less) for realizing URLLC. Example: Downlink (DL) and uplink (UL) each of 0.5 ms or less, or round trip 1 ms or less) can be supported.

The antenna module 197 may transmit or receive signals or power to or from the outside (eg, an external electronic device). According to one embodiment, the antenna module 197 may include an antenna including a radiator made of a conductor or a conductive pattern formed on a substrate (eg, PCB). According to one embodiment, the antenna module 197 may include a plurality of antennas (eg, an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network such as the first network 198 or the second network 199 is connected to the plurality of antennas by, for example, the communication module 190. can be selected Signals or power may be transmitted or received between the communication module 190 and an external electronic device through the at least one selected antenna. According to some embodiments, in addition to the radiator, other components (eg, radio frequency integrated circuit (RFIC)) may be additionally formed as part of the antenna module 197.

According to various embodiments, the antenna module 197 may form a mmWave antenna module. According to one embodiment, a mmWave antenna module includes: a printed circuit board, an RFIC disposed on or adjacent to a first side (e.g., bottom side) of the printed circuit board and capable of supporting a designated high frequency band (e.g., mmWave band); And a plurality of antennas (e.g., array antennas) disposed on or adjacent to the second side (e.g., top or side) of the printed circuit board and capable of transmitting or receiving signals in the designated high frequency band. can do.

At least some of the components are connected to each other through a communication method between peripheral devices (e.g., bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)) and signal ( (e.g. commands or data) can be exchanged with each other.

According to one embodiment, commands or data may be transmitted or received between the electronic device 101 and the external electronic device 104 through the server 108 connected to the second network 199. Each of the external electronic devices 102 or 104 may be of the same or different type as the electronic device 101. According to one embodiment, all or part of the operations performed in the electronic device 101 may be executed in one or more of the external electronic devices 102, 104, or 108. For example, when the electronic device 101 needs to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device 101 may perform the function or service instead of executing the function or service on its own. Alternatively, or additionally, one or more external electronic devices may be requested to perform at least part of the function or service. One or more external electronic devices that have received the request may execute at least part of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device 101. The electronic device 101 may process the result as is or additionally and provide it as at least part of a response to the request. For this purpose, for example, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology can be used. The electronic device 101 may provide an ultra-low latency service using, for example, distributed computing or mobile edge computing. In another embodiment, the external electronic device 104 may include an Internet of Things (IoT) device. Server 108 may be an intelligent server using machine learning and/or neural networks. According to one embodiment, the external electronic device 104 or server 108 may be included in the second network 199. The electronic device 101 may be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

FIG. 2A is a diagram illustrating an AKA authentication operation between the electronic device 210 and the mobile network 220.

AKA (Authentication & Key Agreement) is a technology used for mutual authentication between an electronic device (UE, mobile phone, 210) and a mobile network (mobile network, 220) and to establish a secure encrypted communication channel.

xSIM 211 may be a Subscriber Identity Module (SIM) that identifies various SIM applications such as SIM (for 2G networks), USIM (for 3G networks), and ISIM (for IMS). The xSIM 211 may be included in a Universal Integrated Circuit Card (UICC) card within the electronic device 210. A Universal Integrated Circuit Card (UICC) card may be a chip card inserted into the electronic device 210 to authenticate the electronic device 210.

Home Subscriber Server (HSS) 221 is a subscriber database used within the 4G mobile network 220 and can provide subscriber details to other entities within the network.

xSIM 211 and HSS 221 may share a secret key for each subscriber.

The xSIM 211 of the electronic device 210 does not have direct read access to the secret key, but provides an API (Application Programmer Interface) that can perform cryptographic calculations using the secret key. It can be included. HSS 221 of mobile network 220 may perform cryptographic calculations using a secret key.

The electronic device 210 and the mobile network 220 can use the AKA method to derive a unique one-time symmetric encryption key 201 and establish a secure encryption channel.

The electronic device 210 and the mobile network 220 share common secret information in advance, so that mutual authentication can occur.

The authentication family specified by the 3rd Generation Partnership Project (3GPP) is provided to the subscriber management device (Home Subscriber Server (HSS), Unified Data Management (UDM)/Authentication credential Repository and Processing Function (ARPF), etc.) of the mobile network 220. It may be based on a shared secret common to the inserted xSIM UICC and the common AKA algorithm and procedures described in the 3GPP specifications.

AKA can be used for both Non-Access Stratum (NAS) layer authentication and application layer authentication (VoLTE SIP, Extensible Markup Language (XML) Configurable Access Protocol (XCAP)). In this case, even if the parameters are transmitted in different ways, the method of calculating the parameters may be the same.

VoLTE SIP implementations can utilize AKA to set up IPSec encryption data.

The method by which IMS (IP Multimedia Subsystem) AKA operates through SIP (Session Initiation Protocol) according to one embodiment is as follows.

1. The electronic device 210 can start SIP REGISTER with [IMPI] (IP Multimedia Private Identity).

2. HSS 221 is [IMPI] (IP Multimedia Private Identity), [RAND] (Random Network Challenge), [AUTN] (AUthentication TokeN), [XRES] (Expected Response), [IK] (Integrity Key), and It can respond to S-CSCF (Serving Call State Control Function) with an authentication vector including [CK] (Cipher Key).

3. S-CSCF (Serving Call State Control Function) can maintain [XRES] (Expected Response) and transfer other tokens to P-CSCF (Proxy Call State Control Function).

4. P-CSCF (Proxy Call State Control Function) maintains [IK] (Integrity Key), [CK] (Cipher Key) and transmits [RAND] (Random Network Challenge) and [AUTN] (AUthentication TokeN) to electronic devices. It can be delivered to (210).

5. The electronic device 210 may transmit [RAND] (Random Network Challenge) and [AUTN] (AUthentication TokeN) tokens to the xSIM 211 of the UICC.

6. xSIM (211) calculates [MAC] (Message Authentication Code), [XMAC] (Expected Message Authentication Code), [RES] (Response), [IK] (Integrity Key), and [CK] (Cipher Key) You can then compare [XMAC](Expected Message Authentication Code) with [MAC](Message Authentication Code). This step allows mobile network 220 to be authenticated to xSIM 211.

7. xSIM (211) can transmit [IK] (Integrity Key), [CK] (Cipher Key), and [RES] (Response) back to the electronic device 210. The electronic device 210 can set up an encrypted IPSec channel.

8. The electronic device 210 can transmit [RES] (Response) to the Serving Call State Control Function (S-CSCF) through an encrypted IPSec channel.

9. S-CSCF (Serving Call State Control Function) can compare [RES] (Response) with [XRES] (Expected Response). Electronic device 210 may be authenticated to mobile network 220 at this stage.

10. S-CSCF (Serving Call State Control Function) may generate confirmation (OK) and transmit it to the electronic device 210.

FIG. 2B is a diagram illustrating a TLS authentication operation between the client 230 and the server 240.

Transport Layer Security (TLS) is a security system for an anonymous Internet environment. The TLS handshake (defined in RFC 5246 and 8446) is an Internet Engineering Task Force (IETF) standard based on certificates.

The server 240 does not have information about the client 230, so a third-party Public Key Infrastructure (PKI) infrastructure may be needed.

Server 240 has a name (usually a Domain Name System (DNS) domain name) and an asymmetric key pair (public and private). Name <-> Public key binding can be signed with a digital certificate issued by a trusted CA (part of a Certificate Authority, PKI).

The client 230 may be provided with a list of trusted root CAs in advance.

Client 230 initiates a TLS session (“hello”), server 240 responds with a public key and certificate (“pub key + certificate”), and client 230 validates against a list of trusted CAs. can be inspected. A Diffie-Hellman key exchange may occur between the client 230 and the server 240 and a temporary symmetric key 202 may be derived.

As server 240 is authenticated to client 230, application data can be exchanged over a secure, encrypted channel.

Authentication of client 230 to server 240 may be performed through an additional username/password scheme.

Using certificates in TLS is optional, but most implementations use a chain of intermediate certification authorities (CAs) and a server certificate signed by a root CA at the end. To do this, the server 240 must have a valid certificate, which is ultimately signed by the root CA and known to the TLS client 230. This solution provides server 240 authentication to the client 230, but the client 230 may not be authenticated to the server 240.

The TLS handshake operation method for TLS authentication can be as follows.

1. The client 230 can start a TLS session with a TLS “ClientHello” record. The record may contain a list of supported cipher suites.

2. Server 240 may respond with a TLS “ServerHello” record containing the selected cipher suite. After the hello exchange, both the client 230 and the server 240 can agree on the protocol version, session ID, cipher suite, and compression usage. Additionally, the client 230 may generate a client random (client_random), and the server 240 may generate a server random (server_random).

3. Server 240 may transmit a TLS record including Cerificate, ServerKeyExchange, CertificateRequest, and ServerHelloDone to client 230.

4. The client 230 may transmit a TLS record including Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, and Finished to the server 240.

5. Server 240 may respond with a TLS record containing ChangeCipherSpec and Finished. At this time, the client 230 and the server 240 may agree on a common pre-master secret (as a result of key exchange) and a master secret that serves as a symmetric encryption key.

6. The TLS handshake is completed, and both the client 230 and the server 240 can exchange application data through a secure encrypted channel.

FIG. 3 is a diagram illustrating a TLS-AKA authentication system between the electronic device 300 and the mobile core 1000 according to various embodiments.

The TLS-AKA authentication system according to various embodiments may be a system that performs AKA authentication at the TLS handshake stage in TLS authentication between the electronic device 300 and the mobile core 1000.

According to one embodiment, the electronic device 300 and the mobile core 1000 may transmit AKA messages to each other in the TLS handshake phase.

According to one embodiment, the electronic device 300 and the mobile core 1000 may derive encryption data for the symmetric encryption key in the AKA handshake phase.

According to one embodiment, the electronic device 300 and the mobile core 1000 may calculate a TLS symmetric encryption key based on derived encryption data.

According to one embodiment, the electronic device 300 and the mobile core 1000 may exchange TLS application data after the TLS handshake is completed.

Accordingly, the TLS-AKA authentication system can eliminate PKI maintenance overhead, provide mutual authentication, improve security, and enable the use of various services.

FIG. 4 is a diagram illustrating a TLS-AKA authentication system between the electronic device 300 and the mobile core 1000 according to various embodiments.

A TLS-AKA authentication system according to various embodiments may be a system that uses AKA shared credentials, algorithms, and/or procedures to establish a TLS session between the electronic device 300 and the mobile core 1000.

According to various embodiments, the electronic device 300 may include an xSIM 330. For example, xSIM 211 may be a Subscriber Identity Module (SIM) that identifies various SIM applications, such as SIM (for 2G networks), USIM (for 3G networks), and ISIM (for IMS). The xSIM 330 may be included in a Universal Integrated Circuit Card (UICC) card within the electronic device 300. A Universal Integrated Circuit Card (UICC) card may be a chip card inserted into the electronic device 300 to authenticate the electronic device 300.

According to various embodiments, the mobile core 1000 may include U-AUTH 1300. U-AUTH 1300 is a management device within the mobile core 1000 and may be AuC, HLS, HSS, UDM, or UDR.

In the TLS-AKA authentication system according to one embodiment, the encryption data generated by AKA is used in the TLS handshake between the electronic device 300 and the mobile core 1000, so that the electronic device 300 and the mobile core 1000 ) can establish a mutual trust relationship between them. Accordingly, the TLS-AKA authentication system may not require PKI and certificates in the TLS handshake between the electronic device 300 and the mobile core 1000.

xSIM (330) and U-AUTH (1300) can perform AKA access authentication (Non-Access Stratum (NAS) layer and/or IP layer), TLS handshake, and/or session establishment as described in current standards and specifications. there is.

The electronic device 300 according to one embodiment may connect to a network using the AKA procedure according to 3GPP specifications and then establish a TLS session using the TLS server 1100 and the TLS-AKA authentication system.

According to various embodiments, the TLS-AKA authentication system includes an electronic device 300 including an xSIM 330, an xSIM API 331, and a TLS client 310 used for AKA, and a mobile core interface 1310 used for AKA. ) and the extended TLS handshake (TLS extended handshake, 402) between the mobile core 1000 including the TLS server 1100.

Communication 401 between TLS client 310 and xSIM 330 may be control traffic internal to electronic device 300 that is part of a standard AKA procedure.

The extended TLS handshake 402 may be control traffic over the common Internet IP dataplane.

Communication 403 between the TLS server 1100 and U-AUTH 1300 may be control traffic through the control plane within the operator core network.

After the extended TLS handshake is completed, the electronic device 300 and the mobile core 1000 can perform data traffic 404 passing through a common Internet IP data plane.

According to various embodiments, the TLS-AKA system can be established over a non-3GPP network, so it can be tunneled through an extended TLS handshake that can occur on any network bearer, and can be provided through mobile roaming or Wi-Fi. It can be used on any electronic device 300 that has Internet access and may not require cellular network access.

According to various embodiments, the TLS-AKA system may be used for mobile carrier customer service. Mobile carriers (e.g., Mobile Core 1000) typically provide user services through a web application (e.g., application client 320), and users can use a web app (e.g., application server 1200) to receive dedicated support. (Example: Electronic device 300) is identified. Typically, identification of a mobile carrier user (e.g., electronic device 300) is accomplished through user name/password authentication. In a TLS-AKA system, the identity of the mobile carrier's user (e.g., electronic device 300) may be authenticated within the TLS handshake.

According to various embodiments, the TLS-AKA system may be used for Rich Communication Services (RCS) registration services. Mobile carriers (e.g. Mobile Core (1000)) provide RCS services related to messaging, calls, presence, etc. to customers. The RCS app (e.g., application client 320) of the electronic device 300 can generally communicate with the network via TLS. In general, RCS registration involves an RCS app (e.g., application client 320) of the electronic device 300 establishing a TLS session with an RCS server in the network, and using username/password authentication to connect to the RCS server (e.g., application server 1200). )) is performed by authentication. In a TLS-AKA system, RCS server authentication can be performed within the TLS handshake.

According to various embodiments, the TLS-AKA system can be used for communication security for IoT, V2X, and HTMC slices in 5G networks.

According to 3GPP TS 23.501, the 5G architecture may have network slices dedicated to some specific services (e.g. MIoT Massive IoT services, V2X Vehicle-to-Everything services (see TS 23.287), HMTC high-performance machine type communication services).

IoT sensors equipped with xSIM UICC can establish mutually authenticated TLS sessions directly with a dedicated application server. TLS-AKA systems for IoT security can greatly simplify the deployment process by eliminating the need to pre-configure security credential-related information for sensors. Authentication is access agnostic, so it can work with any type of wireless access, including cellular and Wi-Fi, and non-3GPP wireless access does not need to support specific features such as EAP.

The TLS-AKA system can be applied to V2X because vehicle cellular devices can authenticate via TLS directly to a dedicated application server.

3GPP TS 22.261 Service Requirements for 5G Systems includes requirements for 5G systems for services such as IoT, VR or V2X. Specifically, Section 8.3 Authentication states: "5G systems must be able to support authentication over non-3GPP access technologies using 3GPP credentials." The contents are disclosed.

The TLS-AKA system may operate in AKA mode, fast mode, and/or DH mode.

AKA mode may be a mode in which only the AKA method is used, fast mode may be a mode in which the AKA mode is simplified, and DH mode may be a mode in which the TLS encryption key is derived from Diffie-Hellman exchange.

FIGS. 5A and 5B are diagrams illustrating the operational flow between the former device 300 and the mobile core 1000 in the AKA mode in the TLS-AKA system according to various embodiments.

AKA mode may be a mode in which, in a TLS-AKA system, only the AKA method is used, all encryption data is derived from the AKA procedure, and asymmetric key encryption or client/server key exchange TLS records are not used. Additionally, in AKA mode, AKA can only be used in the “Hello” message of the TLS client 310 and the TLS server 1100.

In AKA mode, the TLS encryption key is derived from the AKA Integrity Key (IK) and Cipher Key (CK) tokens, and the final response message carries additional authentication of the Response (RES)/Expected Response (XRES) parameters based on the AKA token. can be provided.

In AKA mode, specified specifications (e.g. 3GPP) can be additionally defined to perform the operation. For example, the TLS specification may define the “Hello” message from the client (e.g., electronic device 300) and server (e.g., TLS server 1100) as AKA-aware TLS. For example, the app server 1200 has a communication function with the TLS server 1100 for operation 502, a communication function with the U-AUTH 1300 and the mobile core 1000 for operations 503 and 504, and an expected response (XRES). ) can be calculated and compared with the response (RES) received from the electronic device 300 to perform a function of authenticating the electronic device 300. For example, in the TLS-AKA system, a new flow can be defined in the 3GPP specification for communication between the app server 1200 and U-AUTH 1300.

According to various embodiments, in operation 501, the electronic device 300 may establish a TLS session with the TLS server 1100. The electronic device 300 may transmit an extended TLS client “Hello” message (TLS client extend Hello) including [ID], [realm], and [options] to the TLS server 1100.

According to various embodiments, in operation 502, the TLS server 1100 may transmit [ID] and [realm] to the app server 1200.

According to various embodiments, in operation 503, the app server 1200 may transmit a message including [ID] to the U-AUTH 1300. The target node of U-AUTH (1300) may be determined by [realm].

According to various embodiments, in operation 504, U-AUTH 1300 performs [RAND] (Random Network Challenge), [AUTN] (AUthentication TokeN), [XRES] ( Expected Response), [IK] (Integrity Key), and [CK] (Cipher Key) can be calculated and transmitted to the app server 1200.

According to various embodiments, in operation 505, the app server 1200 may maintain the [XRES] (Expected Response) and forward the remaining token to the TLS server 1100.

According to various embodiments, in operation 506, the TLS server 1100 maintains the [IK] (Integrity Key) and [CK] (Cipher Key) and sends an electronic TLS server “Hello” message (TLS server extended Hello). Device 300 may respond. The “Hello” message may include [ID], [RAND] (Random Network Challenge), and [AUTN] (AUthentication TokeN).

According to various embodiments, in operation 507, the electronic device 300 may transmit [RAND] (Random Network Challenge) and [AUTN] (AUthentication TokeN) to the xSIM 330 of the UICC according to the AKA procedure.

According to various embodiments, at operation 508, xSIM 330 performs a [MAC] (Message Authentication Code)/XMAC (Expected Message Authentication Code) and [SQN] match according to the AKA procedure when a network is authenticated to an electronic device. You can check the message through

According to various embodiments, at operation 509, xSIM 330 calculates [IK] (Integrity Key), [CK] (Cipher Key), and [RES] (Response) based on [RAND] and [SQN]; It can be returned to the electronic device 300. From that moment, both the electronic device 300 and the TLS server 1100 may have common [IK] (Integrity Key) and [CK] (Cipher Key) encryption data.

According to various embodiments, in operation 510, the electronic device 300 and the TLS server 1100 generate a common TLS dictionary master-secret (derivePre -MasterSecret) can be derived.

According to various embodiments, in operation 511, the electronic device 300 and the TLS server 1100 may set TLS encryption data (PreMasterSecret) and agree on TLS parameters. Operation 511 may correspond to the moment key exchange is completed within a standard TLS handshake.

According to various embodiments, at operation 512, a master secret (MasterSecret) may be derived by a key expansion function according to a selected cipher suite and standard TLS procedures.

According to various embodiments, in operation 513, the electronic device 300 and the TLS server 1100 may exchange TLS ChangeCipherSpec messages and establish an encrypted data channel. Because it reflects the AKA method, the TLS Finished message is not sent immediately after ChangeCipherSpec.

According to various embodiments, in operation 514, the electronic device 300 may calculate a random cononce value as in the IMS AKA procedure.

According to various embodiments, in operation 515, the electronic device 300 may calculate the response field similar to IMS AKA.

According to various embodiments, in operation 516, the electronic device 300 sends a response including [ID], [realm], [RES], [cnonce] [RAND], and [AUTN] to the TLS server 1100. ) can be transmitted. The response message may be transmitted via an encrypted channel.

According to various embodiments, in operation 517, the TLS server 1100 may decrypt the response message and forward it to the app server 1200.

According to various embodiments, in operation 518, the app server 1200 may check a response using [XRES] (Expected Response) and other transmitted tokens. In operation 518, the electronic device 300 may be authenticated to the mobile core 1000.

According to various embodiments, in operation 519, if the app server 1200 successfully confirms the response, it may transmit an acceptance message (accept) to the TLS server 1100. The TLS server 1100 may transmit a completion message (TLS finished) to the electronic device 300.

According to various embodiments, in operation 520, the electronic device 300 may transmit a completion message (TLS finished) to the TLS server 1100.

6A and 6B are diagrams illustrating the operation flow of fast mode in the TLS-AKA system according to various embodiments.

Fast mode is similar to AKA mode, but may be a more simplified mode.

In fast mode, TLS encryption keys can be derived in the form of AKA IK and CK tokens as in AKA mode. Once calculated, it is used immediately and no further verification may be performed.

Fast mode can be used on clients with limited CPU resources where security level requirements can be relaxed. For example, AKA mode may be a good choice for banking applications, while Fast mode may be a good choice for IoT applications.

The handshake in fast mode consists of two Hello messages and two ChangeSipherSpec/Finished messages, and can be very short and weighty because the AKA procedure is executed over TLS Hello. Additionally, it can be CPU economical as there is no asymmetric key calculation.

In operation 601, the electronic device 300 may establish a TLS session with the TLS server 1100. The electronic device 300 may transmit an extended TLS client “Hello” message (TLS client Extended Hello) containing [ID], [realm], and [options] to the TLS server 1100/app server 1200. .

In operation 602, the TLS server 1100/app server 1200 may transmit a message including [ID] to U-AUTH 1300. The node of U-AUTH (1300) can be determined by [realm].

In operation 603, U-AUTH 1300 performs [RAND] (Random Network Challenge), [AUTN] (AUthentication TokeN), [XRES] (Expected Response), [IK] ( Integrity Key) and [CK] (Cipher Key) can be calculated and transmitted to the TLS server (1100)/app server (1200).

In operation 604, the TLS server 1100/app server 1200 may maintain the [IK] (Integrity Key) and [CK] (Cipher Key) and transfer the remaining tokens to the electronic device 300.

In operation 605, the electronic device 300 may transmit [RAND] (Random Network Challenge) and [AUTN] (AUthentication TokeN) to the UICC xSIM 330 according to the AKA procedure.

At operation 606, xSIM 330 may verify the message via [MAC] (Message Authentication Code)/XMAC (Expected Message Authentication Code) and [SQN] matching according to the AKA procedure when the network is authenticated to the electronic device. .

In operation 607, the xSIM 330 may calculate [IK] (Integrity Key), [CK] (Cipher Key), and [RES] (Response) and return them to the electronic device 300. From that moment, both the electronic device 300 and the TLS server 1100 may have common [IK] (Integrity Key) and [CK] (Cipher Key) encryption data.

At operation 608, the electronic device 300 and the TLS server 1100/app server 1200 determine a common TLS dictionary master-secret (derivePreMasterSecret) as a function of the common Integrity Key (IK), Cipher Key (CK) token. ) can be derived

At operation 609, TLS encryption material (preMasterSecret) may be set and TLS parameters agreed upon. Operation 609 may correspond to an operation where key exchange is completed within a standard TLS handshake.

At operation 610, a master secret (MasterSecret) may be derived by a key expansion function according to the selected cipher suite and standard TLS procedures.

In operation 611, the electronic device 300 and the TLS server 1100 may exchange TLS ChangeCipherSpec and Finished messages and establish an encrypted data channel. When the TLS server 1100/app server 1200 receives a finished message from the electronic device 300, it can verify the message. Since the Finished message is transmitted through an encrypted channel, many IKs and CKs may be required to decrypt the message. Second, the body of the completed message may include a full handshake digest that is compared to the handshake digest calculated by the TLS server 1100/app server 1200. In operation 611, the electronic device 300 may be authenticated to the mobile core 1000.

Figures 7a and 7b are diagrams illustrating the operation flow of DH mode in the TLS-AKA system according to various embodiments.

Diffie-Hellman (DH) mode may be a mode in which, in a TLS-AKA system, the TLS encryption key is derived from a Diffie-Hellman exchange using a TLS client/server key exchange message. D-H exchanges can be signed by SIGK, which is derived from AKA IK, CK and RES tokens.

The handshake in DH mode is similar to the standard TLS handshake, except that AKA derived keys are used for DH signing instead of RSA/PKI.

DH mode can provide a high level of security similar to AKA mode or standard TLS.

DH mode is the most CPU intensive of the three modes presented, but may be the easiest to implement because it changes the standard TLS handshake to a minimal extent.

In operation 701, the electronic device 300 may establish a TLS session with the TLS server 1100. The electronic device 300 may transmit an extended TLS client “Hello” message (TLS client extended Hello) including [ID], [realm], and [options] to the TLS server 1100.

In operation 702, the TLS server 1100 may transmit [ID] and [realm] to the app server 1200.

In operation 703, the app server 1200 may transmit a message including [ID] to the U-AUTH 1300. The node of U-AUTH (1300) can be determined by [realm].

In operation 704, U-AUTH 1300 performs [RAND] (Random Network Challenge), [AUTN] (AUthentication TokeN), [XRES] (Expected Response), [IK] ( Integrity Key) and [CK] (Cipher Key) can be calculated and delivered back to the app server 1200.

In operation 705, the app server 1200 may calculate the signature key SIGK as a function of [Expected Response (XRES), Integrity Key (IK), and Cipher Key (CK)].

In operation 706, the app server 1200 may transmit [ID], [RAND] (Random Network Challenge), [AUTN] (AUthentication TokeN), and [SIGK] to the TLS server 1100.

At operation 707, the TLS server 1100 maintains [SIGK] and uses the [ID], [RAND] (Random Network Challenge), and [AUTN] (AUthentication TokeN) tokens to send an extended TLS server “Hello” message (TLS server Extended Hello) can be transmitted to the electronic device 300. “Hello” messages can be signed with SIGK.

In operation 708, the TLS server 1100 may transmit a TLS server key exchange message signed with SIGK to the electronic device 300.

In operation 709, the electronic device 300 may transmit [RAND] (Random Network Challenge) and [AUTN] (AUthentication TokeN) to the xSIM 330 of the UICC.

At operation 710, xSIM 330 may verify the [Message Authentication Code] (MAC) and [SQN] delivered within the Authentication TokeN ([AUTN]) token. In operation 710, the network may be authenticated for the electronic device 300.

In operation 711, the xSIM 330 may calculate [RES] (Response), [IK] (Integrity Key), and [CK] (Cipher Key) and send them to the electronic device 300.

In operation 712, the electronic device 300 may calculate SIGK with the same value as the value calculated by the TLS server 1100 in operation 705.

In operation 713, the electronic device 300 may verify the extended TLS server “Hello” (TLS server extended Hello) and TLS server key exchange signatures using the recently calculated SIGK.

At operation 714, the electronic device 300 may transmit a TLS client key exchange signed with SIGK.

At operation 715, TLS server 1100 may validate the SIGK and TLS client key exchange and process the message. At operation 715 the Diffie-Hellman exchange may be completed.

In operation 716, additional TLS settings are performed identically to standard TLS, with ChangeCipherSpec/Finished exchanged at the end. The TLS handshake is completed and an encrypted data channel can be established between the electronic device 300 and the TLS server 1100. At this stage, device 300 can be authenticated to mobile core 1000.

FIG. 8A is a diagram illustrating a TLS-AKA system according to various embodiments.

The TLS-AKA system shown in FIG. 8A may be a system extended by a third party.

According to various embodiments, the TLS server 1100 may belong to a third-party application server 1410, and the mobile core 1000 may provide an ID service through a Network Exposure Function (NEF) node 1420. (For more information regarding NEF, see TS 23.501 System Architecture for 5G Systems Sections 5.20 and 6.2.5)

AKA exchange may occur between TLS client 310 and U-AUTH 1300 via TLS server 1100, NEF interface 1421, and NEF itself 1420.

NEF interface 1421 may be implemented within TLS server 1100 to communicate with NEF network 1420. Once the AKA exchange is completed, the TLS client 310 and the TLS server 1100 can calculate common encryption data and establish a TLS session.

Additional communication over the TLS encrypted channel may occur without the participation of the mobile core 1000. For example, the electronic device 300 may be connected via WiFi and may not require cellular data.

According to various embodiments, the TLS-AKA system shown in FIG. 8A may be applied to communication from Unmanned Aerial System (UAS) to Uncrewed Aerial System Traffic Management (UTM).

In 3GPP TS 22.125, “3GPP Unmanned Aerial Systems (UAS) Support”, UAVs can direct unmanned aerial vehicles (Drones). The drone does not have a human pilot on board and can be controlled remotely via a UAV controller. UAVs and UAV controllers (according to TS 22.125) can constitute UAS. UAS can be managed in UTM - Unmanned Aerial System Traffic Management. TS 22.125 Section 5.1 defines the general requirements for remote identification of UAS to UTM, and TS 22.125 Section 5.4 defines security requirements for remote identification of UAS to UTM.

For example, in communication from UAS (Unmanned Aerial System) to UTM (Uncrewed Aerial System Traffic Management) using the TLS-AKA system, UTM corresponds to the third party server 1410, and UAS corresponds to the electronic device 300. Correspondingly, the UAS application can be applied in correspondence with the application client 320.

Figure 8b is a diagram illustrating a TLS-AKA system according to various embodiments.

The TLS-AKA system shown in FIG. 8B may be a system extended to a third party and 2FA (two-factor authentication) applied.

According to various embodiments, the third-party application server 1410 may use the authentication service provided by the mobile core 1000 and may use existing user name/password (1510, 1520) authentication.

In 2FA, client (e.g., electronic device 300) mutual authentication is achieved by use of the TLS-AKA system, and user authentication can be achieved using existing username/password schemes (1510, 1520). Accordingly, existing user authentication can be strengthened by client authentication of the TLS-AKA system to implement strong 2FA.

According to various embodiments, the TLS-AKA system shown in FIG. 8B can be applied to banking applications through 2FA.

Mobile banking can use two-factor authentication (2FA) to achieve a high level of security. Two-factor authentication (2FA) can be based on the principles of ‘what you have’ and ‘what you know’. The principle can be implemented with an additional PIN code sent to the user UE by SMS. In this case, the user logs into the banking application using a username/password (something the user knows) 1510 and via SMS code (something the user has, in this case the user has an xSIM (330) UICC card). Additional certification may be obtained.

For example, in mobile banking two-factor authentication (2FA) using the TLS-AKA system, the mobile banking server may correspond to a third-party application server (1410), and two-step authentication requires the user to enter a username/password (1510). Logging into the bank using (something the user knows) can be performed by a TLS handshake between the TLS server 1421 and the TLS client 310 (something the user has). Therefore, there is no need to copy the password from the received SMS (which the user already has), so no further action may be required from the user. Additionally, when the TLS-AKA system is applied to banking applications, the level of security can be higher because the bank is also authenticated to the user. Additionally, it may be more resistant to phishing attacks because fake banks cannot establish a TLS handshake with mobile banking apps.

FIG. 8C is a diagram illustrating a TLS-AKA system according to various embodiments.

The TLS-AKA system shown in FIG. 8C can be applied to a DNS (Domain Name System) security system.

According to various embodiments, the TLS server 1100 may belong to the DoH/DoT server 1600.

In Internet security for Domain Name System (DNS) over TLS (DoT) and Domain Name System (DNS) over HTTP (DoH), there are initiatives to improve DNS security using DNSSEC encryption.

For example, a DNS security system with the TLS-AKA system can transmit DNS queries via TLS. The DNS server 1600 may know the requestor ID transmitted by the TLS server 1100, and based on this, the TLS-AKA system can be applied to various value-added services based on DNS.

Electronic devices according to various embodiments disclosed in this document may be of various types. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to embodiments of this document are not limited to the above-described devices.

The various embodiments of this document and the terms used herein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various changes, equivalents, or replacements of the embodiments. In connection with the description of the drawings, similar reference numbers may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the above items, unless the relevant context clearly indicates otherwise. As used herein, “A or B”, “at least one of A and B”, “at least one of A or B”, “A, B or C”, “at least one of A, B and C”, and “A Each of phrases such as “at least one of , B, or C” may include any one of the items listed together in the corresponding phrase, or any possible combination thereof. Terms such as "first", "second", or "first" or "second" may be used simply to distinguish one component from another, and to refer to that component in other respects (e.g., importance or order) is not limited. One (e.g., first) component is said to be “coupled” or “connected” to another (e.g., second) component, with or without the terms “functionally” or “communicatively.” Where mentioned, it means that any of the components can be connected to the other components directly (e.g. wired), wirelessly, or through a third component.

The term “module” used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and is interchangeable with terms such as logic, logic block, component, or circuit, for example. It can be used as A module may be an integrated part or a minimum unit of the parts or a part thereof that performs one or more functions. For example, according to one embodiment, the module may be implemented in the form of an application-specific integrated circuit (ASIC).

Various embodiments of the present document are one or more instructions stored in a storage medium (e.g., built-in memory 136 or external memory 138) that can be read by a machine (e.g., electronic device 101). It may be implemented as software (e.g., program 140) including these. For example, a processor (e.g., processor 120) of a device (e.g., electronic device 101) may call at least one command among one or more commands stored from a storage medium and execute it. This allows the device to be operated to perform at least one function according to the at least one instruction called. The one or more instructions may include code generated by a compiler or code that can be executed by an interpreter. A storage medium that can be read by a device may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' only means that the storage medium is a tangible device and does not contain signals (e.g. electromagnetic waves), and this term refers to cases where data is semi-permanently stored in the storage medium. There is no distinction between temporary storage cases.

According to one embodiment, methods according to various embodiments disclosed in this document may be included and provided in a computer program product. Computer program products are commodities and can be traded between sellers and buyers. The computer program product may be distributed in the form of a machine-readable storage medium (e.g. compact disc read only memory (CD-ROM)) or through an application store (e.g. Play StoreTM) or on two user devices (e.g. It can be distributed (e.g. downloaded or uploaded) directly between smart phones) or online. In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

According to various embodiments, each component (e.g., module or program) of the above-described components may include a single or plural entity, and some of the plurality of entities may be separately placed in other components. there is. According to various embodiments, one or more of the components or operations described above may be omitted, or one or more other components or operations may be added. Alternatively or additionally, multiple components (eg, modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each component of the plurality of components in the same or similar manner as those performed by the corresponding component of the plurality of components prior to the integration. . According to various embodiments, operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, or omitted. Alternatively, one or more other operations may be added.

Claims (18)

In the authentication system,
An electronic device that performs AKA authentication and TLS authentication functions;
Contains a mobile core that performs AKA authentication and TLS authentication functions,
The electronic device transmits a client message including AKA authentication to the mobile core in the TLS handshake phase,
The mobile core derives encryption data based on the client message and calculates a TLS symmetric encryption key,
The mobile core transmits a server message including AKA authentication to the electronic device in the TLS handshake phase,
The electronic device derives encryption data based on the server message and calculates a TLS symmetric encryption key,
The electronic device and the mobile core create a secure channel based on the TLS symmetric encryption key,
The electronic device and the mobile core exchange data through the secure channel.
Authentication system.
According to claim 1,
The mobile core is
Includes a management device that performs AKA authentication,
Deriving encryption data based on the client message,
Calculating a TLS symmetric encryption key based on the derived encryption data
Authentication system.
According to claim 2,
The electronic device is
Contains a Subscriber Identity Module (SIM) that performs AKA authentication,
The SIM is
Deriving encryption data based on the server message,
Calculating a TLS symmetric encryption key based on the derived encryption data
Authentication system.
According to claim 3,
The client message includes [ID],
The management device is
Based on the [ID], calculate [RAND] (Random Network Challenge), [AUTN] (AUthentication TokeN), [XRES] (Expected Response), [IK] (Integrity Key), and [CK] (Cipher Key)
Authentication system. According to claim 4,
The server message includes [ID], [RAND] (Random Network Challenge), and [AUTN] (AUthentication TokeN),
The SIM is
Based on [RAND] (Random Network Challenge) and [AUTN] (AUthentication TokeN) above
Calculates [IK] (Integrity Key), [CK] (Cipher Key), and [RES] (Response)
Authentication system.
According to claim 5,
The electronic device and the mobile core
Deriving the encryption data based on the [IK] (Integrity Key) and [CK] (Cipher Key),
Mutually agree on TLS parameters
Authentication system.
According to claim 6,
The electronic device and the mobile core
Calculate a TLS symmetric encryption key based on the encryption material and the TLS parameters,
Creating the secure channel based on the symmetric encryption key
Authentication system.
According to claim 7,
The electronic device transmits response data including [ID], [realm], [RES], [cnonce], [RAND], and [AUTN] to the mobile core through the secure channel,
The mobile core checks the response data obtained through the secure channel based on the [XRES] (Expected Response),
authenticating the electronic device in response to confirming the response data.
Authentication system.
According to claim 5,
The mobile core is
Calculating the SIGK signature key based on the functions related to [XRES] (Expected Response), IK (Integrity Key), CK (Cipher Key)]
Authentication system.
According to clause 9,
The SIM is
Calculating the SIGK signature key based on the functions related to [RES] (Response), IK (Integrity Key), CK (Cipher Key)]
Authentication system.
According to clause 10,
The electronic device and the mobile core
Creating a secure channel based on the calculated SIGK signature key
Authentication system.
In an electronic device that performs a TLS authentication function,
A processor that uses a Subscriber Identity Module (SIM) to perform AKA authentication;
The processor is
In the TLS handshake step, transmit a client message including AKA authentication to the mobile core, and obtain a server message including AKA authentication from the mobile core,
Deriving encryption data based on the server message,
Calculate a TLS symmetric encryption key based on the encryption data,
Create a secure channel based on the TLS symmetric encryption key,
Exchanging data with the mobile core through the secure channel
Electronic devices.
According to claim 12,
The server message includes [ID], [RAND] (Random Network Challenge), and [AUTN] (AUthentication TokeN),
The processor is
Calculate [IK] (Integrity Key), [CK] (Cipher Key) and [RES] (Response) based on [RAND] (Random Network Challenge) and [AUTN] (AUthentication TokeN).
Electronic devices.
According to claim 13,
The processor is
Deriving the encryption data based on the [IK] (Integrity Key) and [CK] (Cipher Key),
Mutually agree TLS parameters with the mobile core
Electronic devices.
According to claim 14,
The processor is
Calculate a TLS symmetric encryption key based on the encryption material and the TLS parameters,
Creating the secure channel based on the symmetric encryption key
Electronic devices.
According to claim 15,
The processor is
Transmitting response data including [ID], [realm], [RES], [cnonce], [RAND], and [AUTN] to the mobile core through the secure channel.
Electronic devices.
According to claim 13,
The server message includes [RES] (Response), IK (Integrity Key), CK (Cipher Key)],
The processor is
Calculating the SIGK signature key based on the functions of [RES] (Response), IK (Integrity Key), CK (Cipher Key)]
Electronic devices.
According to clause 17,
The processor is
Creating a secure channel based on the calculated SIGK signature key
Electronic devices.

Images