WO2023210952A1 - Système et dispositif d'authentification mutuelle de tls à l'aide d'aka - Google Patents

Système et dispositif d'authentification mutuelle de tls à l'aide d'aka Download PDF

Info

Publication number
WO2023210952A1
WO2023210952A1 PCT/KR2023/003077 KR2023003077W WO2023210952A1 WO 2023210952 A1 WO2023210952 A1 WO 2023210952A1 KR 2023003077 W KR2023003077 W KR 2023003077W WO 2023210952 A1 WO2023210952 A1 WO 2023210952A1
Authority
WO
WIPO (PCT)
Prior art keywords
tls
electronic device
authentication
key
aka
Prior art date
Application number
PCT/KR2023/003077
Other languages
English (en)
Korean (ko)
Inventor
호르슈차루크크지슈토프
와이즈코우스키프리즈마이슬로
보레키표트르
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Publication of WO2023210952A1 publication Critical patent/WO2023210952A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/162—Implementing security features at a particular protocol layer at the data link layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • Various embodiments disclosed in this document relate to mutual TLS authentication via AKA between an electronic device and a mobile core.
  • 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.
  • RAN mobile radio access network
  • IMS IP layer authentication
  • XCAP IP layer authentication
  • 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.
  • 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.
  • CA Certificate Authority
  • the TLS-AKA authentication system 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 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 may utilize security credentials generated by xSIM and subscriber management devices through procedures similar to AKA in the TLS handshake.
  • 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.
  • network operators can easily modify the server's IP address and FQDN without having to update the PKI certificate.
  • 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.
  • PKI-based TLS provides one-way authentication, while at the TLS level, client-to-server and server-to-client mutual authentication is possible.
  • the TLS handshake can establish a TLS session with four messages.
  • the TLS-AKA system can strengthen immunity against MITM attacks and phishing attacks.
  • the existing AKA encryption suite can be reused for TLS purposes.
  • 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.
  • one user credential i.e. one xSIM UICC
  • FIG. 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.
  • Figures 7a and 7b are diagrams illustrating the operation flow of 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.
  • FIG. 1 is a block diagram of an electronic device 101 in a network environment 100, according to various embodiments.
  • 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.
  • a first network 198 e.g., a short-range wireless communication network
  • a second network 199 e.g., a second network 199.
  • the electronic device 101 may communicate with the electronic device 104 through the server 108.
  • 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.
  • 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.
  • 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.
  • software e.g., program 140
  • 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.
  • 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).
  • a main processor 121 e.g., a central processing unit or an application processor
  • auxiliary processor 123 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.
  • 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.
  • 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.
  • the auxiliary processor 123 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.
  • 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.
  • 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 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.
  • 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).
  • 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.
  • HDMI high definition multimedia interface
  • USB universal serial bus
  • SD card interface Secure Digital Card interface
  • audio interface audio interface
  • 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).
  • 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.
  • 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.
  • 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.
  • the power management module 188 may be implemented as at least a part of, for example, a power management integrated circuit (PMIC).
  • PMIC power management integrated circuit
  • the battery 189 may supply power to at least one component of the electronic device 101.
  • 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.
  • processor 120 e.g., an application processor
  • 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.
  • 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
  • GNSS global navigation satellite system
  • wired communication module 194 e.g., : LAN (local area network) communication module, or power line communication module
  • 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).
  • 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).
  • 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).
  • a telecommunication network such as a cellular network, a 5G network, a next-generation communication network
  • 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.
  • subscriber information e.g., International Mobile Subscriber Identifier (IMSI)
  • IMSI International Mobile Subscriber Identifier
  • 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).
  • 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.
  • Peak data rate e.g., 20 Gbps or more
  • loss coverage e.g., 164 dB or less
  • U-plane latency e.g., 164 dB or less
  • the antenna module 197 may transmit signals or power to or receive signals or power from the outside (e.g., an external electronic device).
  • 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).
  • 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.
  • other components eg, radio frequency integrated circuit (RFIC) may be additionally formed as part of the antenna module 197.
  • RFIC radio frequency integrated circuit
  • 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.
  • a first side e.g., bottom side
  • a designated high frequency band e.g., mmWave band
  • a plurality of antennas e.g., array antennas
  • peripheral devices e.g., bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)
  • signal e.g. commands or data
  • 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.
  • 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.
  • the electronic device 101 may perform the function or service instead of executing the function or service on its own.
  • 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.
  • 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.
  • 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.
  • 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
  • UE electronic device
  • mobile network mobile network, 220
  • 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).
  • SIM Subscriber Identity Module
  • USIM for 3G networks
  • ISIM for IMS
  • the xSIM 211 may be included in a Universal Integrated Circuit Card (UICC) card within the electronic device 210.
  • UICC Universal Integrated Circuit Card
  • a Universal Integrated Circuit Card (UICC) card may be a chip card inserted into the electronic device 210 to authenticate the electronic device 210.
  • 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.
  • 3GPP 3rd Generation Partnership Project
  • 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)).
  • NAS Non-Access Stratum
  • XML Extensible Markup Language
  • XCAP Configurable Access Protocol
  • VoLTE SIP implementations can utilize AKA to set up IPSec encryption data.
  • IMS IP Multimedia Subsystem
  • SIP Session Initiation Protocol
  • the electronic device 210 can start SIP REGISTER with [IMPI] (IP Multimedia Private Identity).
  • 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).
  • S-CSCF Server Call State Control Function
  • [XRES] Exected Response
  • P-CSCF Proxy Call State Control Function
  • P-CSCF Proxy Call State Control Function
  • IK Integrity Key
  • CK Chip Key
  • RAND Random Network Challenge
  • AUTN AUthentication TokeN
  • the electronic device 210 may transmit [RAND] (Random Network Challenge) and [AUTN] (AUthentication TokeN) tokens to the xSIM 211 of the UICC.
  • [RAND] Random Network Challenge
  • [AUTN] AUthentication TokeN
  • xSIM 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.
  • 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.
  • the electronic device 210 can transmit [RES] (Response) to the Serving Call State Control Function (S-CSCF) through an encrypted IPSec channel.
  • RES Response
  • S-CSCF Serving Call State Control Function
  • S-CSCF Server Call State Control Function
  • RES Response Response
  • XRES Extended Response
  • S-CSCF Serving Call State Control Function
  • confirmation OK
  • FIG. 2B is a diagram illustrating a TLS authentication operation between the client 230 and the server 240.
  • Transport Layer Security 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.
  • IETF Internet Engineering Task Force
  • the server 240 does not have information about the client 230, so a third-party Public Key Infrastructure (PKI) infrastructure may be needed.
  • PKI Public Key Infrastructure
  • 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).
  • DNS Domain Name System
  • 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.
  • server 240 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.
  • CAs intermediate certification authorities
  • the TLS handshake operation method for TLS authentication can be as follows.
  • the client 230 can start a TLS session with a TLS “ClientHello” record.
  • the record may contain a list of supported cipher suites.
  • 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).
  • Server 240 may transmit a TLS record including Cerificate, ServerKeyExchange, CertificateRequest, and ServerHelloDone to client 230.
  • the client 230 may transmit a TLS record including Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, and Finished to the server 240.
  • 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.
  • 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 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.
  • the electronic device 300 and the mobile core 1000 may transmit AKA messages to each other in the TLS handshake phase.
  • the electronic device 300 and the mobile core 1000 may derive encryption data for the symmetric encryption key in the AKA handshake phase.
  • the electronic device 300 and the mobile core 1000 may calculate a TLS symmetric encryption key based on derived encryption data.
  • the electronic device 300 and the mobile core 1000 may exchange TLS application data after the TLS handshake is completed.
  • 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 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.
  • the electronic device 300 may include an xSIM 330.
  • 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).
  • SIM Subscriber Identity Module
  • USIM for 3G networks
  • ISIM for IMS
  • the xSIM 330 may be included in a Universal Integrated Circuit Card (UICC) card within the electronic device 300.
  • UICC Universal Integrated Circuit Card
  • a Universal Integrated Circuit Card (UICC) card may be a chip card inserted into the electronic device 300 to authenticate the electronic device 300.
  • 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.
  • 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.
  • AKA access authentication Non-Access Stratum (NAS) layer and/or IP layer
  • TLS handshake TLS handshake
  • session establishment as described in current standards and specifications. there is.
  • the electronic device 300 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.
  • 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.
  • TLS extended handshake TLS extended handshake, 402
  • 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.
  • the electronic device 300 and the mobile core 1000 can perform data traffic 404 passing through a common Internet IP data plane.
  • 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.
  • the TLS-AKA system may be used for mobile carrier customer service.
  • Mobile carriers e.g., Mobile Core 1000
  • a web application e.g., application client 320
  • users can use a web app (e.g., application server 1200) to receive dedicated support.
  • a web app e.g., application server 1200
  • identification of a mobile carrier user e.g., electronic device 300
  • user name/password authentication e.g., electronic device 300
  • the identity of the mobile carrier's user e.g., electronic device 300
  • the TLS-AKA system may be used for Rich Communication Services (RCS) registration services.
  • Mobile carriers e.g. Mobile Core (1000)
  • the RCS app e.g., application client 320
  • the RCS app can generally communicate with the network via TLS.
  • 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.
  • RCS server authentication can be performed within the TLS handshake.
  • the TLS-AKA system can be used for communication security for IoT, V2X, and HTMC slices in 5G networks.
  • 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).
  • MIoT Massive IoT services e.g. MCIoT 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
  • 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.
  • 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.
  • IK AKA Integrity Key
  • CK Cipher Key
  • RES Response/Expected Response
  • specified specifications e.g. 3GPP
  • 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.
  • 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.
  • a new flow can be defined in the 3GPP specification for communication between the app server 1200 and U-AUTH 1300.
  • 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.
  • TLS client extend Hello extended TLS client “Hello” message
  • the TLS server 1100 may transmit [ID] and [realm] to the app server 1200.
  • 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].
  • 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.
  • [RAND] Random Network Challenge
  • [AUTN] AUthentication TokeN
  • [XRES] Expected Response
  • [IK] Integrity Key
  • [CK] Cipher Key
  • the app server 1200 may maintain the [XRES] (Expected Response) and forward the remaining token to the TLS server 1100.
  • 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).
  • the "Hello” message may include [ID], [RAND] (Random Network Challenge), and [AUTN] (AUthentication TokeN).
  • 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.
  • [RAND] Random Network Challenge
  • [AUTN] AUthentication TokeN
  • xSIM 330 performs a Message Authentication Code (MAC)/Expected Message Authentication Code (XMAC) and [SQN] match according to the AKA procedure when a network is authenticated to an electronic device. You can check the message through
  • 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.
  • the electronic device 300 and the TLS server 1100 generate a common TLS dictionary master-secret (derivePre -MasterSecret) can be derived.
  • 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.
  • a master secret may be derived by a key expansion function according to a selected cipher suite and standard TLS procedures.
  • 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.
  • the electronic device 300 may calculate a random cononce value as in the IMS AKA procedure.
  • the electronic device 300 may calculate the response field similar to IMS AKA.
  • 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.
  • the TLS server 1100 may decrypt the response message and forward it to the app server 1200.
  • the app server 1200 may check a response using [XRES] (Expected Response) and other transmitted tokens.
  • the electronic device 300 may be authenticated to the mobile core 1000.
  • the app server 1200 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.
  • the electronic device 300 may transmit a completion message (TLS finished) to the TLS server 1100.
  • TLS finished completion message
  • 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.
  • 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.
  • AKA mode may be a good choice for banking applications
  • 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.
  • 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/app server 1200. .
  • TLS client Extended Hello extended TLS client “Hello” message
  • 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].
  • 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).
  • 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.
  • the electronic device 300 may transmit [RAND] (Random Network Challenge) and [AUTN] (AUthentication TokeN) to the UICC xSIM 330 according to the AKA procedure.
  • [RAND] Random Network Challenge
  • [AUTN] AUthentication TokeN
  • 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. .
  • 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.
  • 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
  • TLS encryption material preMasterSecret
  • Operation 609 may correspond to an operation where key exchange is completed within a standard TLS handshake.
  • a master secret (MasterSecret) may be derived by a key expansion function according to the selected cipher suite and standard TLS procedures.
  • the electronic device 300 and the TLS server 1100 may exchange TLS ChangeCipherSpec and Finished messages and establish an encrypted data channel.
  • 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.
  • 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.
  • 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.
  • 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.
  • TLS client extended Hello extended TLS client “Hello” message
  • the TLS server 1100 may transmit [ID] and [realm] to the app server 1200.
  • 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].
  • 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.
  • [RAND] Random Network Challenge
  • [AUTN] AUthentication TokeN
  • [XRES] Extended Response
  • [IK] Integrity Key
  • [CK] Cipher Key
  • the app server 1200 may calculate the signature key SIGK as a function of [Expected Response (XRES), Integrity Key (IK), and Cipher Key (CK)].
  • the app server 1200 may transmit [ID], [RAND] (Random Network Challenge), [AUTN] (AUthentication TokeN), and [SIGK] to the TLS server 1100.
  • 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.
  • the "Hello” message can be signed with SIGK.
  • the TLS server 1100 may transmit a TLS server key exchange message signed with SIGK to the electronic device 300.
  • the electronic device 300 may transmit [RAND] (Random Network Challenge) and [AUTN] (AUthentication TokeN) to the xSIM 330 of the UICC.
  • [RAND] Random Network Challenge
  • [AUTN] AUthentication TokeN
  • xSIM 330 may verify the [Message Authentication Code] (MAC) and [SQN] delivered within the Authentication TokeN ([AUTN]) token.
  • the network may be authenticated for the electronic device 300.
  • the xSIM 330 may calculate [RES] (Response), [IK] (Integrity Key), and [CK] (Cipher Key) and send them to the electronic device 300.
  • the electronic device 300 may calculate SIGK with the same value as the value calculated by the TLS server 1100 in operation 705.
  • 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.
  • the electronic device 300 may transmit a TLS client key exchange signed with SIGK.
  • TLS server 1100 may validate the SIGK and TLS client key exchange and process the message.
  • the Diffie-Hellman exchange may be completed.
  • TLS handshake is completed and an encrypted data channel can be established between the electronic device 300 and the TLS server 1100.
  • 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.
  • 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.
  • NEF Network Exposure Function
  • 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.
  • the electronic device 300 may be connected via WiFi and may not require cellular data.
  • 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).
  • UAS Unmanned Aerial System
  • UPM Uncrewed Aerial System Traffic Management
  • 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
  • TS 22.125 Section 5.4 defines security requirements for remote identification of UAS to UTM.
  • UTM Unmanned Aerial System
  • UTM Uncrewed Aerial System Traffic Management
  • 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.
  • 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.
  • client e.g., electronic device 300
  • TLS-AKA TLS-AKA system
  • 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.
  • the TLS-AKA system shown in FIG. 8B can be applied to banking applications through 2FA.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • DNS Domain Name System
  • the TLS server 1100 may belong to the DoH/DoT server 1600.
  • 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 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.
  • 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.”
  • any of the components can be connected to the other components directly (e.g. wired), wirelessly, or through a third component.
  • 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).
  • ASIC application-specific integrated circuit
  • 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.
  • a processor e.g., processor 120
  • 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.
  • '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.
  • 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.
  • a machine-readable storage medium e.g. compact disc read only memory (CD-ROM)
  • an application store e.g. Play StoreTM
  • two user devices e.g. It can be distributed (e.g. downloaded or uploaded) directly between smart phones) or online.
  • 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.
  • 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.
  • one or more of the components or operations described above may be omitted, or one or more other components or operations may be added.
  • multiple components eg, modules or programs
  • 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. .
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Un système d'authentification selon divers modes de réalisation comprend : un dispositif électronique qui effectue des fonctions d'authentification AKA et d'authentification TLS ; et un cœur mobile qui effectue une authentification AKA et des fonctions d'authentification TLS, le dispositif électronique transmettant un message client comprenant une authentification AKA au niveau du cœur mobile dans une étape d'établissement de liaison TLS, le cœur mobile calcule une clé de chiffrement symétrique TLS en dérivant un matériel de chiffrement sur la base du message client, le cœur mobile transmet un message de serveur comprenant une authentification AKA au niveau du dispositif électronique dans l'étape d'établissement de liaison TLS, le dispositif électronique calcule la clé de chiffrement symétrique TLS en dérivant un matériel de chiffrement sur la base du message de serveur, le dispositif électronique et le cœur mobile génèrent un canal sécurisé sur la base de la clé de chiffrement symétrique TLS, et le dispositif électronique et le cœur mobile peuvent échanger des données par l'intermédiaire du canal sécurisé. Divers autres modes de réalisation sont possibles.
PCT/KR2023/003077 2022-04-28 2023-03-07 Système et dispositif d'authentification mutuelle de tls à l'aide d'aka WO2023210952A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020220052622A KR20230152990A (ko) 2022-04-28 2022-04-28 Aka를 통한 상호 tls 인증 시스템 및 장치
KR10-2022-0052622 2022-04-28

Publications (1)

Publication Number Publication Date
WO2023210952A1 true WO2023210952A1 (fr) 2023-11-02

Family

ID=88519207

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/003077 WO2023210952A1 (fr) 2022-04-28 2023-03-07 Système et dispositif d'authentification mutuelle de tls à l'aide d'aka

Country Status (2)

Country Link
KR (1) KR20230152990A (fr)
WO (1) WO2023210952A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030200431A1 (en) * 2002-04-18 2003-10-23 Nokia Corporation Method and apparatus for providing peer authentication for a transport layer session
WO2007022800A1 (fr) * 2005-08-26 2007-03-01 Telefonaktiebolaget Lm Ericsson (Publ) Procede et dispositif assurant la securite d'acces dans un reseau de communications
KR20080009235A (ko) * 2005-06-10 2008-01-25 지멘스 악티엔게젤샤프트 통신 링크의 보안을 위해 하나 이상의 제1 통신 가입자와제2 통신 가입자 사이에 보안키를 합의하기 위한 방법
WO2020007461A1 (fr) * 2018-07-04 2020-01-09 Telefonaktiebolaget Lm Ericsson (Publ) Authentification et accord de clé entre un réseau et un équipement utilisateur

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030200431A1 (en) * 2002-04-18 2003-10-23 Nokia Corporation Method and apparatus for providing peer authentication for a transport layer session
KR20080009235A (ko) * 2005-06-10 2008-01-25 지멘스 악티엔게젤샤프트 통신 링크의 보안을 위해 하나 이상의 제1 통신 가입자와제2 통신 가입자 사이에 보안키를 합의하기 위한 방법
WO2007022800A1 (fr) * 2005-08-26 2007-03-01 Telefonaktiebolaget Lm Ericsson (Publ) Procede et dispositif assurant la securite d'acces dans un reseau de communications
WO2020007461A1 (fr) * 2018-07-04 2020-01-09 Telefonaktiebolaget Lm Ericsson (Publ) Authentification et accord de clé entre un réseau et un équipement utilisateur

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Bootstrapping interface (Ub) and network application function interface (Ua); Protocol details (Release 17)", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 24.109, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CT WG1, no. V17.1.0, 25 March 2022 (2022-03-25), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, pages 1 - 82, XP052144821 *

Also Published As

Publication number Publication date
KR20230152990A (ko) 2023-11-06

Similar Documents

Publication Publication Date Title
WO2020226454A1 (fr) Appareil et procédé pour fournir des services informatiques mobile edge dans un système de communication sans fil
WO2021167417A1 (fr) Procédés et systèmes d'authentification de dispositifs à l'aide de justificatifs d'identité d'accès au réseau 3gpp pour fournir des services mec
WO2018147711A1 (fr) Appareil et procédé de contrôle d'accès de esim
WO2019194665A1 (fr) Procédé et dispositif pour exécuter un embarquement
WO2020091281A1 (fr) Procédé et appareil pour effectuer une authentification de serveur mandataire pour une permission d'accès par un terminal dans un système de communication sans fil
WO2022149874A1 (fr) Procédé et système d'authentification et d'autorisation dans un serveur msgin5g
WO2022075815A1 (fr) Procédés et systèmes pour l'authentification et l'établissement d'une connexion sécurisée pour des services informatiques de périphérie
WO2022010134A1 (fr) Procédé de chiffrement de message et dispositif électronique
WO2022220584A1 (fr) Dispositif électronique, et procédé par lequel un dispositif électronique réalise une intégration en nuage d'un dispositif électronique externe
WO2023210952A1 (fr) Système et dispositif d'authentification mutuelle de tls à l'aide d'aka
WO2020091434A1 (fr) Procédé et dispositif pour effectuer une authentification à l'aide d'informations biométriques dans un système de communication sans fil
WO2016072781A1 (fr) Amorçage d'une communication directe wi-fi par une entité de réseau de confiance
WO2022186482A1 (fr) Procédé de mise à jour d'une clé secrète partagée, et dispositif électronique le prenant en charge
WO2022182102A1 (fr) Procédé de mise en œuvre d'une authentification d'utilisateur et dispositif de mise en œuvre associé
WO2022025614A1 (fr) Procédé et appareil de réglage de multiples contrôleurs dans un système lan sans fil dans un environnement de maison intelligente
WO2022186533A1 (fr) Dispositif électronique établissant une tranche de réseau et une session de données, et procédé d'utilisation de celui-ci
WO2022145768A1 (fr) Dispositif électronique effectuant une communication sans fil avec un dispositif accessoire et son procédé de fonctionnement
WO2022225195A1 (fr) Dispositif électronique de fourniture de dispositif dans un réseau sans fil et son procédé de fonctionnement
WO2023017984A1 (fr) Dispositif électronique et procédé d'utilisation de pmk
WO2022203174A1 (fr) Dispositif électronique permettant de réaliser une opération de gestion de réseau, et procédé de fonctionnement associé
WO2022080831A1 (fr) Procédé et appareil destinés à établir des connexions sécurisées pour des services informatiques en périphérie
WO2022158637A1 (fr) Dispositif électronique conçu pour fournir des informations d'un point d'accès dans un système de communication sans fil et procédé associé
WO2022215941A1 (fr) Procédé de traitement de politique de sécurité de réseau de dispositif électronique
WO2022220436A1 (fr) Dispositif électronique effectuant une opération d'accès au réseau et son procédé de fonctionnement
WO2023090799A1 (fr) Procédé et réseau sans fil pour autorisation spécifique à l'application pour services de réseau dans un réseau sans fil

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23796602

Country of ref document: EP

Kind code of ref document: A1