WO2023132650A1 - 제어 평면을 이용하여 크리덴셜을 단말에 프로비저닝 시 종단 보안 형성을 위한 방법 및 장치 - Google Patents

제어 평면을 이용하여 크리덴셜을 단말에 프로비저닝 시 종단 보안 형성을 위한 방법 및 장치 Download PDF

Info

Publication number
WO2023132650A1
WO2023132650A1 PCT/KR2023/000202 KR2023000202W WO2023132650A1 WO 2023132650 A1 WO2023132650 A1 WO 2023132650A1 KR 2023000202 W KR2023000202 W KR 2023000202W WO 2023132650 A1 WO2023132650 A1 WO 2023132650A1
Authority
WO
WIPO (PCT)
Prior art keywords
snpn
provisioning
control plane
certificate
dcs
Prior art date
Application number
PCT/KR2023/000202
Other languages
English (en)
French (fr)
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 삼성전자 주식회사
Priority to EP23737398.0A priority Critical patent/EP4443929A1/en
Publication of WO2023132650A1 publication Critical patent/WO2023132650A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks

Definitions

  • Various embodiments of the present disclosure relate to a method and apparatus for provisioning credential information of a terminal in a wireless communication system.
  • 5G mobile communication technology defines a wide frequency band to enable fast transmission speed and new services. It can also be implemented in the ultra-high frequency band ('Above 6GHz') called Wave.
  • 6G mobile communication technology which is called a system after 5G communication (Beyond 5G)
  • Beyond 5G in order to achieve transmission speed that is 50 times faster than 5G mobile communication technology and ultra-low latency reduced to 1/10, tera Implementations in Terahertz bands (eg, such as the 3 Terahertz (3 THz) band at 95 GHz) are being considered.
  • eMBB enhanced mobile broadband
  • URLLC ultra-reliable low-latency communications
  • mMTC massive machine-type communications
  • Beamforming and Massive MIMO to mitigate the path loss of radio waves in the ultra-high frequency band and increase the propagation distance of radio waves, with the goal of satisfying service support and performance requirements, and efficient use of ultra-high frequency resources
  • numerology support multiple subcarrier interval operation, etc.
  • BWP Band-Width Part
  • large capacity New channel coding methods such as LDPC (Low Density Parity Check) code for data transmission and Polar Code for reliable transmission of control information, L2 pre-processing, and dedicated services specialized for specific services Standardization of network slicing that provides a network has been progressed.
  • LDPC Low Density Parity Check
  • NR-U New Radio Unlicensed
  • UE Power Saving NR terminal low power consumption technology
  • NTN non-terrestrial network
  • IAB Intelligent Internet of Things
  • IIoT Intelligent Internet of Things
  • DAPS Dual Active Protocol Stack
  • 2-step random access that simplifies the random access procedure
  • RACH for Standardization in the field of air interface architecture/protocol for technologies such as NR
  • 5G baseline for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies Standardization in the field of system architecture/service is also in progress for an architecture (eg, service based architecture, service based interface), mobile edge computing (MEC) for which services are provided based on the location of a terminal, and the like.
  • an architecture eg, service based architecture, service based interface
  • MEC mobile edge computing
  • AR augmented reality
  • VR virtual reality
  • MR mixed reality
  • XR extended reality
  • AI artificial intelligence
  • ML machine learning
  • FD-MIMO Full Dimensional MIMO
  • Array Antenna for guaranteeing coverage in the terahertz band of 6G mobile communication technology.
  • multi-antenna transmission technologies such as large scale antennas, metamaterial-based lenses and antennas to improve coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), RIS ( Reconfigurable Intelligent Surface) technology, as well as full duplex technology to improve frequency efficiency and system network of 6G mobile communication technology, satellite, and AI (Artificial Intelligence) are utilized from the design stage and end-to-end (End-to-End) -to-End) Development of AI-based communication technology that realizes system optimization by internalizing AI-supported functions and next-generation distributed computing technology that realizes complex services beyond the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources could be the basis for
  • 3GPP which is in charge of cellular mobile communication standards, names a new core network structure as 5G core (5GC) to seek evolution from the existing 4G LTE system to the 5G system, and standardization is in progress.
  • 5GC 5G core
  • 5GC supports the following differentiated functions compared to the evolved packet core (EPC), which is the network core for existing 4G.
  • EPC evolved packet core
  • 5GC In 5GC, a network slice function is introduced. As a requirement of 5G, 5GC must support various types of terminal types and services (e.g. eMBB, URLLC, or mMTC service). Different types of services have different requirements for the core network. For example, eMBB service requires high data rate and URLLC service requires high stability and low delay.
  • eMBB service requires high data rate and URLLC service requires high stability and low delay.
  • One of the technologies proposed to satisfy these various service requirements is network slicing.
  • Network slicing is a method of creating multiple logical networks by virtualizing one physical network, and each network slice instance (NSI) may have different characteristics. Accordingly, each NSI can satisfy various service requirements by having a network function (NF) suitable for its characteristics. If an NSI suitable for the characteristics of the service requested by each terminal is allocated, various 5G services can be efficiently supported.
  • NF network function
  • 5GC can facilitate network virtualization paradigm support through separation of mobility management function and session management function.
  • 4G LTE services could be provided through signaling exchange with a single core device called a mobility management entity (MME) responsible for registration, authentication, mobility management, and session management functions for all terminals.
  • MME mobility management entity
  • 5G as the number of terminals explodes and the mobility and traffic/session characteristics that must be supported according to the type of each terminal are subdivided, if all functions are supported in a single device such as the MME, it is necessary to add entities for each required function. Scalability is inevitable. Accordingly, various functions are being developed based on a structure in which a mobility management function and a session management function are separated in order to improve scalability in terms of function/implementation complexity and signaling load of a core device in charge of a control plane.
  • NPN non-public network
  • Various embodiments of the present disclosure provide a method and apparatus for safely providing credentials of a UE without exposing them to entities other than the UE and the PS using a control plane from a provisioning server (PS) that manages the credentials.
  • PS provisioning server
  • Various embodiments of the present disclosure provide a method and apparatus for enabling a UE to successfully complete access to an SO-SNPN to receive service based on credentials provided through a control plane.
  • a method performed by a terminal in a wireless communication system includes obtaining configuration information including a certificate authority (CA) certificate associated with a certificate of a provisioning server and a certificate of the terminal, using a control plane. Confirming that provisioning is performed, generating an ephemeral key pair based on the confirmation, and based on the configuration information and the ephemeral key pair, in the control plane, SO-SNPN (subscription owner- It may include a step of acquiring credentials of a standalone non-public network.
  • CA certificate authority
  • SO-SNPN subscription owner- It may include a step of acquiring credentials of a standalone non-public network.
  • a method performed by a provisioning server in a wireless communication system includes obtaining configuration information including a certificate of the provisioning server and a CA certificate associated with a certificate of a terminal, and provisioning is performed using a control plane. verifying, generating a temporary key pair for provisioning using the control plane, and generating credentials of an SO-SNPN to be transmitted in the control plane based on the setting information and the temporary key pair.
  • a terminal in a wireless communication system according to an embodiment of the present disclosure, includes a transceiver and a control unit functionally connected to the transceiver, and the control unit includes a CA certificate associated with a certificate of a provisioning server and setting information including a certificate of the terminal.
  • the control unit includes a CA certificate associated with a certificate of a provisioning server and setting information including a certificate of the terminal.
  • a provisioning server includes a transceiver and a control unit functionally connected to the transceiver, and the control unit includes a CA certificate associated with a certificate of the provisioning server and a terminal certificate.
  • Acquiring information confirming that provisioning using the control plane is performed, generating a temporary key pair for provisioning using the control plane, and based on the setting information and the temporary key pair, to be transmitted in the control plane. It can be configured to generate credentials of SO-SNPN.
  • a UE in a state where a UE does not have SO-SNPN credentials, it can safely receive corresponding credentials from a PS that possesses SO-SNPN credentials, and using this, A desired service can be effectively provided from the SO-SNPN.
  • the authentication server function (AUSF) of ON-SNPN may perform the DCS (default credentials server) function in the authentication process Yes, DCS other than AUSF may perform.
  • DCS default credentials server
  • DCS other than AUSF may perform.
  • a unified data management (UDM) function may be performed by a UDM of a DCS, PS, or ON-SNPN.
  • the SO-SNPN credential to be delivered by the PS is protected using a temporary shared key that can only be generated by the UE and the PS, and can be safely delivered to the UE so that entities other than the UE and the PS cannot view it.
  • FIG. 1 is a diagram illustrating the structure of a 5G mobile communication network according to an embodiment of the present disclosure.
  • FIG. 2 is a diagram illustrating a structure of a network for provisioning credentials of a UE according to an embodiment of the present disclosure.
  • 3A to 3C illustrate an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then receives provisioning of SO-SNPN credentials from a PS using a user plane, according to an embodiment of the present disclosure. It is a flow chart.
  • 4A to 4E are flowcharts illustrating an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then securely provisions SO-SNPN credentials from a PS according to an embodiment of the present disclosure.
  • 5A to 5E are flowcharts illustrating an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then securely provisions SO-SNPN credentials from a PS according to an embodiment of the present disclosure.
  • 6A to 6E are flowcharts illustrating an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then securely provisions SO-SNPN credentials from a PS according to an embodiment of the present disclosure.
  • FIGS. 7A to 7E are flowcharts illustrating an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then securely provisions SO-SNPN credentials from a PS according to an embodiment of the present disclosure.
  • 8A and 8B are flowcharts illustrating an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then securely provisions SO-SNPN credentials from a PS according to an embodiment of the present disclosure.
  • FIG. 9 is a diagram showing the configuration of a terminal according to an embodiment of the present disclosure.
  • FIG. 10 is a diagram showing the configuration of a network entity according to an embodiment of the present disclosure.
  • each block of the process flow chart diagrams and combinations of the flow chart diagrams can be performed by computer program instructions.
  • These computer program instructions may be embodied in a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment are described in the flowchart block(s). Create means to perform functions.
  • These computer program instructions may also be stored in a computer usable or computer readable memory that can be directed to a computer or other programmable data processing equipment to implement functionality in a particular way, such that the computer usable or computer readable memory
  • the instructions stored in are also capable of producing an article of manufacture containing instruction means that perform the functions described in the flowchart block(s).
  • the computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operational steps are performed on the computer or other programmable data processing equipment to create a computer-executed process to generate computer or other programmable data processing equipment. Instructions for performing processing equipment may also provide steps for performing the functions described in the flowchart block(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). It should also be noted that in some alternative implementations it is possible for the functions mentioned in the blocks to occur out of order. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in reverse order depending on their function.
  • ' ⁇ unit' used in various embodiments of the present disclosure means software or a hardware component such as FPGA or ASIC, and ' ⁇ unit' may perform certain roles.
  • ' ⁇ part' is not limited to software or hardware.
  • ' ⁇ bu' may be configured to be in an addressable storage medium and may be configured to reproduce one or more processors. Therefore, as an example, ' ⁇ unit' refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, and procedures. , subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.
  • components and ' ⁇ units' may be combined into smaller numbers of components and ' ⁇ units' or further separated into additional components and ' ⁇ units'.
  • components and ' ⁇ units' may be implemented to play one or more CPUs in a device or a secure multimedia card.
  • a base station is a subject that performs resource allocation of a terminal, and is an eNode B (eNB), Node B, base station (BS), radio access network (RAN), access network (AN), RAN node, NR NB, gNB, It may be at least one of a radio access unit, a base station controller, or a node on a network.
  • a terminal may include a user equipment (UE), a mobile station (MS), a cellular phone, a smart phone, a computer, or a multimedia system capable of performing communication functions.
  • UE user equipment
  • MS mobile station
  • a cellular phone a smart phone
  • a computer or a multimedia system capable of performing communication functions.
  • various embodiments of the present disclosure are described below using a system based on LTE, LTE-A, or NR as an example, various embodiments of the present disclosure may also be applied to other communication systems having a similar technical background or channel type. may be applied. In addition, various embodiments of the present disclosure can be applied to other communication systems through some modification within a range that does not greatly deviate from the scope at the discretion of a person with skilled technical knowledge.
  • Each function provided by the 5G network system can be performed in network function (NF) units.
  • NF network function
  • An example of the architecture of a 5G mobile communication network is shown in FIG. 1 .
  • FIG. 1 is a diagram illustrating the structure of a 5G mobile communication network according to an embodiment of the present disclosure.
  • a 5G mobile communication network includes an access and mobility management function (AMF) 120 that manages network access and mobility of a UE 110, and an SMF that performs functions related to a session for the UE 110 ( session management function) 130, a user plane function (UPF) 125 that is in charge of delivering user data and controlled by the SMF 130, and an application function (AF) that communicates with 5GC to provide application services.
  • AMF access and mobility management function
  • SMF session management function
  • UPF user plane function
  • AF application function
  • policy It may include at least one of a policy and control function (PCF) 150 that manages the user data, or a data network (DN) 140 (eg, the Internet) through which user data is transmitted.
  • PCF policy and control function
  • DN data network
  • an operation, administration, and management (OAM) server (not shown), which is a system for managing the UE 110 and the 5G mobile communication network, may exist.
  • OAM operation, administration, and management
  • a RAN eg base station
  • AUSF authentication server function
  • NSSF network slice selection function
  • NRF network repository function
  • FIG. 2 is a diagram illustrating a structure of a network for provisioning credentials of a UE according to an embodiment of the present disclosure.
  • the network shown in FIG. 2 may be included in a wireless communication system (eg, 5th generation system (5GS)), and is the same as at least one of the components (eg, NFs) of the 5G mobile communication network shown in FIG. or contain similar components.
  • UE 210, NG-RAN 215, UPF 225, and DN 240 of FIG. 2 are UE 110, RAN 115, UPF 125, and DN 240 of FIG. DN (140).
  • the AMF 220 and SMF 230 of FIG. 2 may be the AMF 120 and SMF 130 of FIG. 1 , respectively.
  • the NSSF 270, UDM 275, NEF 280, NRF 285, and AUSF 290 of FIG. 2 are the NSSF 175, UDM 160, NEF 170, NRF (155), and AUSF (165).
  • UE 210, NG-RAN 215, UPF 225, DN 240, AMF 220, SMF 230, NSSF 270, UDM 275, NEF ( 280), NRF 285, and AUSF 290 may be included in ON-SNPN (Onboarding - Standalone Non-Public Network (SNPN)), PS (provisioning server) 260 SO-SNPN (Subscription Owner- SNPN) may be included.
  • ON-SNPN Onboarding - Standalone Non-Public Network (SNPN)
  • PS provisioning server
  • SO-SNPN Subscribescription Owner- SNPN
  • the SO-SNPN credential can be provisioned.
  • the UE 210 may receive SO-SNPN credentials from the PS 260 after performing an authentication operation.
  • the UE 210 transmits a registration request to ON-SNPN and performs authentication with a default credentials server (DCS) 250 using default credentials provisioned when the UE 210 is manufactured. Actions to be performed may be included.
  • the authentication operation according to an embodiment may include an operation of selectively performing additional authentication with the DCS 250 after the UE 210 performs authentication with the ON-SNPN.
  • the UE 210 manufactured without SO-SNPN credentials makes a registration request to ON-SNPN in order to acquire the credentials of the SO-SNPN that it wants to receive service from, and then sends a DCS 250 based on the default credentials of the UE 210. ) or mutual authentication with ON-SNPN.
  • the DCS 250 is a network or entity that authenticates the UE 210 and may exist inside or outside the ON-SNPN.
  • the PS 260 is a network or entity having the SO-SNPN credential of the UE 260, and may be located inside or outside the ON-SNPN, and may exist in the same domain as the DCS 250 or a different domain.
  • the UDM 275 of the ON-SNPN is used to authenticate the UE 210 or provision credentials. It may not be. Alternatively, the UDM 275 of the ON-SNPN may not exist in the ON-SNPN.
  • the DCS 250 is an authentication authorization accounting (AAA) server
  • protocol conversion eg, conversion between SBI (service based interface) and RADIUS (remote authentication dial-in user service)
  • NSSAAF network slice-specific authentication and authorization function
  • the UE 210 may perform a provisioning process in which the SO-SNPN credential is provided from the PS 260 through the control plane.
  • the provisioning process if the DCS 250 or PS 260 exists outside the ON-SNPN domain, the NEF 280 of the ON-SNPN may be used.
  • FIGS. 3A to 8B Components (eg, UE, DCS, AMF, or PS) described in FIGS. 3A to 8B may correspond to the components shown in FIG. 2 .
  • Components eg, UE, DCS, AMF, or PS
  • FIGS. 3A to 8B may correspond to the components shown in FIG. 2 .
  • 3A to 3C illustrate an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then receives provisioning of SO-SNPN credentials from a PS using a user plane, according to an embodiment of the present disclosure. It is a flow chart.
  • the signaling order of FIGS. 3A to 3C may be changed depending on circumstances. Also, some of the steps of FIGS. 3A to 3C may be omitted depending on circumstances, or two or more steps may be combined and performed as one step.
  • one or more of the following settings may be performed in advance.
  • the UE manufacturer can provision the UE with credentials to be used for mutual authentication with the DCS when manufacturing the UE.
  • the UE may have a certificate authority (CA) certificate to verify the certificate of the PS and a certificate of the UE itself.
  • CA certificate authority
  • UE manufacturers can provision DCS with credentials to be used for mutual authentication with UEs accessing ON-SNPN. After the UE is sold to the SO-SNPN owner, the UE manufacturer can provision the DCS with at least one of either the address of the PS that can provision the UE with the credentials of the SO-SNPN or a CA certificate that can verify the certificate of the PS. .
  • the address of the PS may be used when the DCS searches for the PS to trigger provisioning on the PS.
  • the DCS may receive all or part of information about whether the PS, ON-SNPN, or UE supports provisioning using the control plane.
  • the UE manufacturer may provide the PS with the ID (eg, onboarding subscriber permanent identifier (SUPI), international mobile equipment identity (IMEI), etc.) of the UE sold to the owner of the SO-SNPN.
  • the PS stores the UE ID and can later use it to find the SO-SNPN credentials to be provided to the UE with the corresponding UE ID.
  • the PS may have a CA certificate to verify the certificate of the UE and a certificate of the PS itself.
  • the PS may receive information about whether the DCS and the UE support provisioning using the control plane from the terminal manufacturer.
  • a first preset (301-A1), a second preset (301-A2), and a third preset (301-A3) A3) can be performed.
  • the first presetting, the second presetting, and the third presetting may be simultaneously performed, or the three presettings may be sequentially performed without being performed simultaneously. If performed sequentially, the order may not be fixed.
  • the first presetting and/or the second presetting is a process necessary for successful authentication with the help of a DCS capable of authenticating the UE when the UE accesses an ON-SNPN without subscription information of the UE (the UE and the DCS
  • the process of pre-provisioning credentials), and later, the process necessary for the UE to successfully receive SO-SNPN credentials from the PS (the process of storing the PS address in the DCS and the CA certificate that can verify the PS certificate). process) may be included.
  • the first presetting and/or the third presetting is a process of setting certificates required for signing when the UE and PS send information to generate a temporary shared key (UE's certificate/CA certificate, PS certificate in the UE and PS, respectively) /CA certificate settings).
  • the DCS may be provided in advance with PS, ON-SNPN, or an indicator indicating whether the UE supports provisioning using the control plane, or otherwise may be provided through a registration process.
  • the PS may be previously provided with an indicator indicating whether the DCS or UE supports provisioning using the control plane from the terminal manufacturer, or may be provided later from another entity.
  • the NG-RAN may broadcast broadcast system information.
  • Broadcast system information may be received by the UE.
  • the broadcast system information may include one or more public land mobile network (PLMN) identifiers (ID), a network ID per PLMN ID, and an onboarding enabled indication.
  • PLMN public land mobile network
  • ID network ID per PLMN ID
  • NPN Non-Public Network
  • the NG-RAN may provide the UE with an indicator of whether the ON-SNPN supports provisioning using the control plane.
  • the UE may select an ON-SNPN based on the broadcasting system information received from the NG-RAN and transmit a Registration Request message to AMF/SEAF. For example, transmission of the registration request message may be triggered when a power-on event occurs in the UE or there is a user's input.
  • the registration request message may include a registration type and an onboarding subscription concealed identifier (SUCI).
  • the registration type may include "SNPN Onboarding” indicating that the UE does not have subscription information for the corresponding NPN.
  • an Onboarding SUCI could have the format "username@realm".
  • the realm part may represent DCS.
  • the UE may send an indicator indicating whether the UE supports provisioning using the control plane together with the registration request message.
  • the AMF/SEAF may receive a registration request message from the UE and check the Onboarding SUCI included in the received registration request message.
  • the AMF/SEAF may identify the DCS based on the realm part of the onboarding SUCI and transmit an Authentication Request message to the AUSF capable of communicating with the identified DCS.
  • the corresponding message may include an indicator indicating whether the UE received in step 303 supports provisioning using the control plane.
  • AUSF may transmit an authentication request message to the DCS based on the authentication request message.
  • the authentication request message may include information included in the authentication request message that the AUSF receives from the AMF in step 304 . Additionally, an indicator of whether the ON-SNPN supports provisioning using the control plane may be included.
  • DCS is an AAA server
  • AUSF may send an authentication request message to DCS through NSSAAF for protocol conversion.
  • ON-SNPN and DCS may have a contractual relationship.
  • message exchange between the ON-SNPN and the DCS may be performed through NEF.
  • AUSF may replace the functional role of DCS in the authentication process.
  • the UE and the DCS may perform extensible authentication protocol (EAP) authentication (eg, EAP-transport layer security (TLS)).
  • EAP extensible authentication protocol
  • TLS EAP-transport layer security
  • the DCS determines that at least one entity (e.g., among UE, ON-SNPN, DCS, and PS) does not support provisioning using the control plane, according to the indicator received in step 305 or the indicator set by the second preset. If the DCS can know that, it may go to step 311. Before proceeding to step 311, the DCS may send an indicator to the PS that provisioning using the user plane will be performed. Even if the DCS finds that the method using the control plane is not performed because at least one entity does not support provisioning using the control plane, steps 308-310 may be performed as is. If the DCS does not know whether provisioning using the control plane of the PS is supported by the second preset, step 308 may be performed.
  • at least one entity e.g., among UE, ON-SNPN, DCS, and PS
  • the DCS may send an indicator to the PS that provisioning using the user plane will be performed. Even if the DCS finds that the method using the control plane is not performed because at least one entity does not support provisioning using
  • the DCS receives the indicators received in step 305 (e.g., an indicator indicating whether the ON-SNPN supports provisioning using the control plane, an indicator indicating whether the UE supports provisioning using the control plane, etc.) and the DCS An indicator for whether provisioning using the control plane of the control plane is supported may be transmitted to the PS.
  • the indicators received in step 305 e.g., an indicator indicating whether the ON-SNPN supports provisioning using the control plane, an indicator indicating whether the UE supports provisioning using the control plane, etc.
  • An indicator for whether provisioning using the control plane of the control plane is supported may be transmitted to the PS.
  • the PS supports provisioning using the control plane by at least one entity (e.g., among UE, ON-SNPN, DCS, and PS) based on the indicators received in step 308 or indicators set by the third preset. If not, you can prepare to send an indicator that provisioning with the user plane is being performed.
  • entity e.g., among UE, ON-SNPN, DCS, and PS
  • the PS may transmit an indicator to the DCS that provisioning using the user plane will be performed.
  • the DCS may transmit an EAP response message to AUSF.
  • the EAP response message includes an EAP Success message, an Onboarding SUPI indicating the UE, keying material for generating a key to be used for communication with the UE in ON-SNPN, and the user plane received in step 310. It may also include an indicator that provisioning using will be performed.
  • AUSF may generate K_ausf (intermediate key) based on the key material in the EAP response message received in step 310.
  • AUSF may transmit an EAP response message to AMF/SEAF.
  • the EAP response message transmitted to AMF/SEAF may include an authentication success message (EAP success), K_seaf (anchor key) generated from K_ausf, Onboarding SUPI, and an indicator that provisioning using the user plane is performed. .
  • AMF/SEAF may transmit an EAP response message to the UE.
  • the EAP response message transmitted to the UE may include an authentication success message (EAP success), a 5G key set identifier (ngKSI) indicating a key, an ABBA parameter, and an indicator that provisioning using the user plane is performed.
  • EAP success an authentication success message
  • ngKSI 5G key set identifier
  • ABBA parameter an indicator that provisioning using the user plane is performed.
  • the UE may generate K_ausf using a method corresponding to the method in which AUSF generated K_ausf in step 312.
  • the AMF/SEAF may transmit a non access stratum (NAS) Security Mode Command message for algorithm negotiation with the UE.
  • NAS non access stratum
  • the UE may transmit a NAS Security Mode Complete message.
  • the UE may request PDU Session establishment and perform provisioning using the PS and user plane.
  • 4A to 4E are flowcharts illustrating an example in which a UE accesses an ON-SNPN, performs mutual authentication, and then securely provisions SO-SNPN credentials from a PS, according to an embodiment of the present disclosure.
  • FIGS. 4A to 4E may be changed depending on circumstances. Also, some of the steps of FIGS. 4A to 4E may be omitted depending on circumstances, or two or more steps may be combined and performed as one step.
  • one or more of the following settings may be performed in advance.
  • the UE manufacturer can provision the UE with credentials to be used for mutual authentication with the DCS when manufacturing the UE.
  • the UE may have a CA certificate to verify the certificate of the PS and a certificate of the UE itself.
  • UE manufacturers can provision DCS with credentials to be used for mutual authentication with UEs accessing ON-SNPN. After the UE is sold to the SO-SNPN owner, the UE manufacturer can provision the DCS with at least one of either the address of the PS that can provision the UE with the credentials of the SO-SNPN or a CA certificate that can verify the certificate of the PS. .
  • the address of the PS may be used when the DCS searches for the PS to trigger provisioning on the PS.
  • the DCS may be provided with PS, ON-SNPN, or information on whether the UE supports provisioning using the control plane.
  • the UE manufacturer may provide the PS with the ID (eg, Onboarding SUPI, IMEI, etc.) of the UE sold to the SO-SNPN owner.
  • the PS stores the UE ID and can later use it to find the SO-SNPN credentials to be provided to the UE with the corresponding UE ID.
  • the PS may have a CA certificate to verify the certificate of the UE and a certificate of the PS itself.
  • the PS may receive information about whether the DCS and the UE support provisioning using the control plane from the terminal manufacturer.
  • a first preset 401-B1, a second preset 401-B2, and a third preset 401-B2. B3) may be performed.
  • the first presetting, the second presetting, and the third presetting may be simultaneously performed, or the three presettings may be sequentially performed without being performed simultaneously. If performed sequentially, the order may not be fixed.
  • the first presetting and/or the second presetting is a process necessary for successful authentication with the help of a DCS capable of authenticating the UE when the UE accesses an ON-SNPN without subscription information of the UE (the UE and the DCS
  • the process of pre-provisioning credentials), and later, the process necessary for the UE to successfully receive SO-SNPN credentials from the PS (the process of storing the PS address in the DCS and the CA certificate that can verify the PS certificate). process) may be included.
  • the first presetting and/or the third presetting is a process of setting certificates required for signing when the UE and PS send information to generate a temporary shared key (UE's certificate/CA certificate, PS certificate in the UE and PS, respectively) /CA certificate settings).
  • the DCS may be provided in advance with PS, ON-SNPN, or an indicator indicating whether the UE supports provisioning using the control plane, or otherwise may be provided through a registration process.
  • the PS may be previously provided with an indicator indicating whether the DCS or the UE supports provisioning using the control plane from the terminal manufacturer, or may be provided later by another entity.
  • the NG-RAN may broadcast broadcast system information.
  • Broadcast system information may be received by the UE.
  • the broadcast system information may include one or more PLMN identifiers (IDs), a list of network IDs per PLMN ID, and an onboarding enabled indication.
  • IDs PLMN identifiers
  • a combination of PLMN ID and Network ID may represent NPN.
  • the NG-RAN may provide the UE with an indicator of whether the ON-SNPN supports provisioning using the control plane.
  • the UE may select an ON-SNPN based on the broadcasting system information received from the NG-RAN and transmit a Registration Request message to AMF/SEAF. For example, transmission of the registration request message may be triggered when a power-on event occurs in the UE or there is a user's input.
  • the registration request message may include a registration type and Onboarding SUCI.
  • the registration type may include "SNPN Onboarding” indicating that the UE does not have subscription information for the corresponding NPN.
  • an Onboarding SUCI could have the format "username@realm".
  • the realm part may represent DCS.
  • the UE may send an indicator of whether the UE supports provisioning using the control plane together with the registration request message.
  • the AMF/SEAF may receive a registration request message from the UE and check the Onboarding SUCI included in the received registration request message.
  • the AMF/SEAF may identify the DCS based on the realm part of the onboarding SUCI and transmit an Authentication Request message to the AUSF capable of communicating with the identified DCS.
  • the corresponding message may include an indicator of whether the UE received in step 403 supports provisioning using the control plane.
  • AUSF may transmit an authentication request message to the DCS based on the authentication request message received from AMF/SEAF.
  • the authentication request message transmitted to the DCS may include information included in the authentication request message that the AUSF receives from the AMF/SEAF in step 404 . Additionally, an indicator of whether the ON-SNPN supports provisioning using the control plane may be included.
  • DCS is an AAA server
  • AUSF may send an authentication request message to DCS through NSSAAF for protocol conversion.
  • ON-SNPN and DCS may have a contractual relationship.
  • message exchange between the ON-SNPN and the DCS may be performed through NEF.
  • AUSF may replace the functional role of DCS in the authentication process.
  • the UE and DCS may perform EAP authentication (eg, EAP-TLS).
  • EAP-TLS EAP authentication
  • the DCS may transmit a notification to the PS based on the result of step 406.
  • the notification may include the UE ID and indicators received in step 405 or provided by the second preset.
  • the notification includes an indicator of whether the UE ID and ON-SNPN support provisioning using the control plane, an indicator of whether the UE supports provisioning using the control plane, or an indicator indicating whether the DCS supports provisioning using the control plane. It may include at least one indicator among indicators for whether to support.
  • the PS indicates that the indicators received in step 407 or indicators provided by the third preset support the control plane for both UE/ON-SNPN/DCS, and the PS also prefers provisioning using the control plane. may determine to provide the credentials of the SO-SNPN to the UE using the control plane. In this step, based on the indicators received by the PS in step 407 or indicators set by the third preset, and whether or not the PS supports provisioning using the control plane, at least one entity among UE/ON-SNPN/DCS/PS If provisioning using the control plane is not supported, steps 310 to 318 of FIG. 3 may be performed.
  • the PS may send an indicator that provisioning using the control plane will be performed and a nonce value (e.g., nonce.PS) generated by the PS to the DCS.
  • a nonce value e.g., nonce.PS
  • the nonce value generated by the PS can be received by the UE in a later step, signed with the UE's private key, and transmitted back to the PS, thereby preventing replay attacks.
  • the DCS may transmit an EAP response message to AUSF.
  • the EAP response message includes an authentication success message, Onboarding SUPI indicating the UE, keying material for generating a key to be used for communication with the UE in ON-SNPN, and information received in step 409 ( e.g., an indicator that provisioning using the control plane will be performed, a nonce value generated by the PS), or a CA certificate capable of verifying the certificate of the PS set in 401-B2 if an indicator that provisioning using the control plane is to be performed is received may include at least one of them.
  • AUSF may generate K_ausf based on the key material in the EAP response message received in step 410.
  • AUSF may transmit an EAP response message to AMF/SEAF.
  • the EAP response message transmitted to AMF/SEAF is an authentication success message (EAP success), K_seaf generated from K_ausf, an onboarding SUPI, an indicator that provisioning is performed using the control plane, a nonce value generated by the PS, or verification of the PS certificate. It may include at least one of the CA certificates available.
  • AMF/SEAF may transmit an EAP response message to the UE.
  • the EAP response message transmitted to the UE includes an authentication success message (EAP success), a 5G key set identifier (ngKSI) indicating a key, an ABBA parameter, an indicator that provisioning using the control plane is performed, a nonce value generated by the PS, or a PS It may include at least one of CA certificates capable of verifying certificates.
  • the UE may generate K_ausf using a method corresponding to the method in which AUSF generated K_ausf in step 411.
  • the UE may generate an ephemeral key pair based on the indicator that provisioning using the control plane received in step 413 is performed.
  • An ephemeral key pair may consist of an ephemeral public key of UE (ePK.UE) and an ephemeral private key of UE (eSK.UE).
  • the UE stores the eSK.UE, the ePK.UE signs with the private key corresponding to the UE's certificate, and the nonce value generated by the PS can also be signed with the UE's private key.
  • the AMF/SEAF may transmit a NAS Security Mode Command message for algorithm negotiation with the UE.
  • the UE may transmit a NAS Security Mode Complete message.
  • the message contains ePK.UE and a value signed with the UE's private key, a nonce value generated by the PS signed with the UE's private key, a certificate of the UE, and/or a nonce value generated by the UE (e.g., nonce.UE ) may be included.
  • a temporary shared key (ePK.UE) generated by the UE may be used as the nonce.UE.
  • the AMF/SEAF can know that the UE has successfully completed the onboarding process to the ON-SNPN, and can prepare to notify it.
  • AMF/SEAF may transmit an authentication notification message to AUSF.
  • the authentication notification message includes information indicating that the UE has successfully completed the onboarding process, the UE's ID, the ePK.UE received in step 416, a value signed with the UE's private key, and a nonce value generated by the PS. It may include a value signed with the private key of , a certificate of the UE, and/or a nonce value generated by the UE.
  • AUSF may transmit an authentication notification message to DCS.
  • the authentication notification message sent to the DCS includes the UE ID, the address of the UDM to be used in the UPU (UE Parameters Update) process, ePK.UE and the value signed with the UE's private key, and the nonce value generated by the PS signed with the UE's private key. value, a certificate of the UE, and/or a nonce value generated by the UE.
  • step 420 the DCS matches the UE ID received in step 419 to find the address of the PS provided by the second preset. Also, the corresponding information may be stored.
  • the DCS may transmit an authentication notification message to the PS.
  • the authentication notification message sent to the PS includes the UE's ID, ePK.UE and the value signed with the UE's private key, the nonce value generated by the PS signed with the UE's private key, the UE's certificate, and/or the UE-generated nonce value. It can contain a nonce value.
  • the PS matches the ID of the UE received in step 421 with the UE ID provided by the third preset to find the credentials of the SO-SNPN to be provided to the corresponding UE.
  • the PS may verify the UE certificate received in step 421 using the CA certificate provided by the third preset.
  • the PS can verify the signed ePK.UE value and the nonce value generated by the signed PS using the public key of the UE in the UE certificate.
  • the PS can generate its own temporary key pair (ePK.PS, eSK.PS) and create temporary shared keys (ephemeral session keys) with ePK.UE and eSK.PS.
  • the temporary shared keys may be composed of a key to be used for encryption (ephemeral encryption key) and a key to be used for integrity protection (ephemeral MAC key).
  • the PS can encrypt the credentials of the SO-SNPN to be delivered to the corresponding UE with a temporary encryption key (Cipher-text value), and calculate a value obtained by hashing this value (Cipher-text value) with a MAC key (MAC-tag value).
  • the encrypted and integrity-protected SO-SNPN credential may consist of a Cipher-text value and a MAC-tag value.
  • the PS can sign the public key (ePK.PS) generated by the PS with the private key corresponding to the certificate of the PS, and the nonce value generated by the UE can also be signed with the private key of the PS.
  • ePK.PS public key
  • the PS may transmit a provisioning request message to the DCS.
  • the message may include the UE ID, ePK.PS, a value obtained by signing it with the private key of the PS, a value obtained by signing the nonce generated by the UE, a certificate of the PS, and/or encryption and integrity-protected SO-SNPN credentials. there is.
  • the DCS may prepare to deliver a provisioning request message to the UDM.
  • the DCS or PS may replace the functional role of the UDM described later.
  • the DCS may transmit a provisioning request message to the UDM.
  • the message is the information received from the PS in step 423 (e.g., UE ID, ePK.PS and the value that signed it with the private key of the PS, the value that signed the nonce generated by the UE, the certificate of the PS, and/or the encryption and integrity protection credential of the registered SO-SNPN).
  • the UDM may request the Nausf_UPUPProtection service to perform the UPU process.
  • the corresponding message may include Onboarding SUPI and encrypted and integrity-protected SO-SNPN credentials.
  • step 427 the encrypted and integrity-protected SO-SNPN credential can be integrity-protected by AUSF using K_ausf.
  • AUSF may transfer the UPU-MAC-I_ausf value and the Counter_upu value calculated in step 427 to the UDM through Nausf_UPUPProtection Response.
  • Counter_upu is a value that starts from 0x00 0x00 and increases each time UPU-MAC-I_ausf is calculated, and can prevent replay attacks.
  • UDM provides UPU Data through Nudm_SDM_Notification service, UPU-MAC-I_ausf calculated by AUSF in step 427, Counter_upu value, ePK.PS received in step 425 and a value signed with the private key of the PS, and a nonce generated by the UE.
  • a value obtained by signing a value with the private key of the PS and/or a certificate of the PS may be transmitted to AMF/SEAF.
  • AMF/SEAF may transmit a DL NAS Transport message to the UE.
  • the DL NAS Transport message includes UPU data, UPU-MAC-I_ausf, Counter_upu, ePK.PS received in step 429 and a value signed with the private key of the PS, a value obtained by signing the nonce value generated by the UE with the private key of the PS, and/ Alternatively, it may include a certificate of PS.
  • the UE may verify UPU-MAC-I_ausf using K_ausf.
  • the UE can verify the certificate of the PS using the CA certificate provided by the first preset.
  • the public key in the PS' certificate can be used to verify the values signed by the PS (ePK.PS signed with the private key of the PS, the nonce value generated by the UE signed with the private key of the PS).
  • the UE may generate ephemeral session keys using eSK.UE and ePK.PS.
  • Ephemeral shared keys consist of a key to be used for encryption (ephemeral encryption key) and a key to be used for integrity protection (ephemeral MAC key). These keys may be the same keys generated by the PS in step 422.
  • the UE can verify the MAC-tag value using the ephemeral MAC key and obtain the SO-SNPN credentials from the Cipher-text value using the ephemeral encryption key.
  • 5A to 5E are flowcharts illustrating an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then securely provisions SO-SNPN credentials from a PS according to an embodiment of the present disclosure.
  • the signaling order of FIGS. 5A to 5E may be changed depending on circumstances. Also, some of the steps of FIGS. 5A to 5E may be omitted depending on circumstances, or two or more steps may be combined and performed as one step.
  • one or more of the following settings may be performed in advance.
  • the UE manufacturer can provision the UE with credentials to be used for mutual authentication with the DCS when manufacturing the UE.
  • the UE may have a CA certificate to verify the certificate of the PS and a certificate of the UE itself.
  • UE manufacturers can provision DCS with credentials to be used for mutual authentication with UEs accessing ON-SNPN. After the UE is sold to the SO-SNPN owner, the UE manufacturer can provision the DCS with at least one of either the address of the PS that can provision the UE with the credentials of the SO-SNPN or a CA certificate that can verify the certificate of the PS. .
  • the address of the PS may be used when the DCS searches for the PS to trigger provisioning on the PS.
  • the DCS may have information that the PS prefers provisioning using the control plane.
  • the DCS may be provided with ON-SNPN and information on whether the UE supports provisioning using the control plane.
  • the UE manufacturer may provide the PS with the ID (eg, Onboarding SUPI, IMEI, etc.) of the UE sold to the SO-SNPN owner.
  • the PS stores the UE ID and can later use it to find the SO-SNPN credentials to be provided to the UE with the corresponding UE ID.
  • the PS may have a CA certificate to verify the certificate of the UE and a certificate of the PS itself.
  • the PS may receive information about whether the DCS and the UE support provisioning using the control plane from the terminal manufacturer.
  • a first preset 501-C1, a second preset 501-C2, and a third preset 501-C3. C3) may be performed.
  • the first presetting, the second presetting, and the third presetting may be simultaneously performed, or the three presettings may be sequentially performed without being performed simultaneously. If performed sequentially, the order may not be fixed.
  • the first presetting and/or the second presetting is a process necessary for successful authentication with the help of a DCS capable of authenticating the UE when the UE accesses an ON-SNPN without subscription information of the UE (the UE and the DCS
  • the process of pre-provisioning credentials), and later, the process necessary for the UE to successfully receive SO-SNPN credentials from the PS (the process of storing the PS address in the DCS and the CA certificate that can verify the PS certificate). process) may be included.
  • the first presetting and/or the third presetting is a process of setting certificates required for signing when the UE and PS send information to generate a temporary shared key (UE's certificate/CA certificate, PS certificate in the UE and PS, respectively) /CA certificate settings).
  • the DCS may be provided in advance with PS, ON-SNPN, or an indicator indicating whether the UE supports provisioning using the control plane, or otherwise may be provided through a registration process.
  • the PS may be previously provided with an indicator indicating whether the DCS or the UE supports provisioning using the control plane from the terminal manufacturer, or may be provided later by another entity.
  • the NG-RAN may broadcast broadcast system information.
  • Broadcast system information may be received by the UE.
  • the broadcast system information may include one or more PLMN identifiers (IDs), a list of network IDs per PLMN ID, and an onboarding enabled indication.
  • IDs PLMN identifiers
  • a combination of PLMN ID and Network ID may represent NPN.
  • the NG-RAN may provide the UE with an indicator of whether the ON-SNPN supports provisioning using the control plane.
  • the UE may select an ON-SNPN based on the broadcasting system information received from the NG-RAN and transmit a Registration Request message to AMF/SEAF. For example, transmission of the registration request message may be triggered when a power-on event occurs in the UE or there is a user's input.
  • the registration request message may include a registration type and Onboarding SUCI.
  • the registration type may include "SNPN Onboarding” indicating that the UE does not have subscription information for the corresponding NPN.
  • an Onboarding SUCI could have the format "username@realm".
  • the realm part may represent DCS.
  • the UE may send an indicator of whether the UE supports provisioning using the control plane together with the registration request message.
  • the AMF/SEAF may receive a registration request message from the UE and check the Onboarding SUCI included in the received registration request message.
  • the AMF/SEAF may identify the DCS based on the realm part of the onboarding SUCI and transmit an Authentication Request message to the AUSF capable of communicating with the identified DCS.
  • the corresponding message may include the onboarding SUCI received in step 503 and/or an indicator of whether the UE supports provisioning using the control plane.
  • AUSF may transmit an authentication request message to the DCS based on the authentication request message.
  • the authentication request message may include information included in the authentication request message that the AUSF receives from the AMF in step 504 . Additionally, an indicator of whether the ON-SNPN supports provisioning using the control plane may be included.
  • DCS is an AAA server
  • AUSF may send an authentication request message to DCS through NSSAAF for protocol conversion.
  • ON-SNPN and DCS may have a contractual relationship.
  • message exchange between the ON-SNPN and the DCS may be performed through NEF.
  • AUSF may replace the functional role of DCS in the authentication process.
  • the UE and DCS may perform EAP authentication (eg, EAP-TLS).
  • EAP-TLS EAP authentication
  • step 507 the DCS performs a control plane provisioning step if it is determined that the UE/ON-SNPN/DCS/PS both support provisioning using the control plane based on the indicators received in step 505 or provided by the second preset. You can prepare. If at least one entity among the UE/ON-SNPN/DCS/PS does not support provisioning using the control plane, steps 311 to 318 of FIG. 3 may be performed.
  • the DCS may forward a notification to the PS that provisioning using the control plane is to be used.
  • the notification may include a UE ID and/or an indicator indicating that provisioning using the control plane is used. If the PS receives this, the SO-SNPN credential to be delivered to the corresponding UE may be prepared in advance.
  • the DCS may transmit an EAP response message to AUSF.
  • the EAP response message includes an authentication success (EAP Success) message, an Onboarding SUPI indicating the UE, keying material for generating a key to be used for communication with the UE in ON-SNPN, and provisioning using the control plane.
  • EAP Success authentication success
  • Onboarding SUPI indicating the UE
  • keying material for generating a key to be used for communication with the UE in ON-SNPN
  • provisioning using the control plane In case of receiving an indicator indicating that provisioning using the control plane is to be performed, or a CA certificate capable of verifying the certificate of the PS set in step 501-C2, at least one of a CA certificate may be included.
  • AUSF may generate K_ausf based on the key material in the EAP response message received in step 509.
  • AUSF may transmit an EAP response message to AMF/SEAF.
  • the EAP response message transmitted to AMF/SEAF may include at least one of an authentication success message, K_seaf generated from K_ausf, an onboarding SUPI, an indicator that provisioning using the control plane is performed, or a CA certificate capable of verifying the PS certificate.
  • AMF/SEAF may transmit an EAP response message to the UE.
  • the EAP response message transmitted to the UE is at least one of an authentication success message, a 5G key set identifier (ngKSI) indicating a key, an ABBA parameter, an indicator that provisioning using the control plane is performed, or a CA certificate capable of verifying the PS certificate can include
  • ngKSI 5G key set identifier
  • the UE may generate K_ausf using a method corresponding to the method in which AUSF generated K_ausf in step 510.
  • the UE may generate an ephemeral key pair based on the indicator that provisioning using the control plane received in step 512 is performed.
  • An ephemeral key pair may consist of an ephemeral public key of UE (ePK.UE) and an ephemeral private key of UE (eSK.UE).
  • the UE can store eSK.UE, sign the ePK.UE with a private key corresponding to the certificate of the UE, generate a time stamp, and sign with the private key.
  • AMF/SEAF may transmit a NAS Security Mode Command message for algorithm negotiation.
  • the UE may transmit a NAS Security Mode Complete message.
  • ePK.UE a value obtained by signing it with the private key of the UE, a time stamp generated by the UE, a value obtained by signing the time stamp with the private key of the UE, and/or a certificate of the UE may be sent.
  • the time stamp generated by the UE is received by the PS in a step described later, if the time stamp exceeds the time range allowed by the PS, the PS may not tolerate it. This can prevent replay attacks.
  • the UE may send a nonce value generated by the UE for authentication of the PS.
  • the AMF/SEAF can know that the UE has successfully completed the onboarding process to the ON-SNPN, and can prepare to notify it.
  • AMF/SEAF may transmit an authentication notification message to AUSF.
  • the authentication notification message includes information indicating that the UE has successfully completed the onboarding process, the UE's ID, the ePK.UE received in step 515, the value signed with the UE's private key, and the time stamp generated by the UE. It may include a value signed with the UE's private key, and/or the UE's certificate.
  • the authentication notification message may include a nonce value generated by the UE, if any.
  • AUSF may transmit an authentication notification message to DCS.
  • the authentication notification message sent to the DCS includes the UE ID, the address of the UDM to be used in the UPU process, ePK.UE and the value signed with the UE's private key, the time stamp generated by the UE and the value signed with the UE's private key, and the UE's If a certificate and a nonce value generated by the UE in step 517 are received, this may be included.
  • step 519 the DCS matches the UE ID received in step 518 to find the address of the PS provided by the second preset.
  • the DCS may transmit an authentication notification message to the PS.
  • the authentication notification message sent to the PS includes the UE's ID, ePK.UE and the value signed with the UE's private key, the time stamp generated by the UE and the value signed with the UE's private key, the UE's certificate, and the UE at step 518. If a nonce value generated by is received, it may be included. And, if step 508 is not performed, it may include an indicator that provisioning using the control plane will be used.
  • the PS matches the ID of the UE received in step 520 with the UE ID provided by the third preset to find the credentials of the SO-SNPN to be provided to the corresponding UE.
  • the PS may verify the UE certificate received in step 520 using the CA certificate provided by the third preset.
  • the PS can verify the signed ePK.UE value and the signed UE's time stamp value using the UE's public key in the UE certificate.
  • the PS can generate its own temporary key pair (ePK.PS, eSK.PS) and create temporary shared keys (ephemeral session keys) with ePK.UE and eSK.PS.
  • the temporary shared keys may be composed of a key to be used for encryption (ephemeral encryption key) and a key to be used for integrity protection (ephemeral MAC key).
  • the PS may encrypt the credentials of the SO-SNPN to be delivered to the corresponding UE with a temporary encryption key (Cipher-text value), and calculate a value obtained by hashing this value (Cipher-text value) with a MAC key (MAC-tag value).
  • the encrypted and integrity-protected SO-SNPN credential may consist of a Cipher-text value and a MAC-tag value.
  • the PS can sign the public key (ePK.PS) it has generated with the private key corresponding to the certificate of the PS.
  • step 520 if the nonce value generated by the UE is received, the nonce value generated by the UE is also signed with the private key, and if the nonce value generated by the UE is not received, the time stamp generated by the PS and it can be signed with the private key of the PS. there is.
  • the PS may transmit a provisioning request message to the DCS.
  • the message includes the UE ID, ePK.PS and the value that signed it with the private key of the PS, the value that signed the nonce generated by the UE, or the time stamp generated by the PS and the value that signed it, the PS's certificate, and/or encryption and Integrity protected SO-SNPN credentials may be included.
  • the DCS may prepare to deliver a provisioning request message to the UDM.
  • the DCS or PS may replace the functional role of the UDM described later.
  • the DCS may transmit a provisioning request message to the UDM.
  • the message is the information received from the PS in step 522 (e.g., UE ID, ePK.PS and the value signed with the private key of the PS, the value of signing the nonce generated by the UE, or the time stamp generated by the PS and the value of signing it). , certificate of PS, credential of encrypted and integrity-protected SO-SNPN).
  • the UDM may request the Nausf_UPUPProtection service to perform the UPU process.
  • the corresponding message may include Onboarding SUPI and encrypted and integrity-protected SO-SNPN credentials.
  • the encrypted and integrity-protected SO-SNPN credential can be integrity-protected by AUSF using K_ausf.
  • AUSF may transmit the UPU-MAC-I_ausf value and the Counter_upu value calculated in step 526 to the UDM through Nausf_UPUPProtection Response.
  • Counter_upu is a value that starts from 0x00 0x00 and increases each time UPU-MAC-I_ausf is calculated, and can prevent replay attacks.
  • UDM provides UPU Data through Nudm_SDM_Notification service, UPU-MAC-I_ausf calculated by AUSF in step 526, Counter_upu value, ePK.PS received in step 524 and a value signed with the private key of the PS, and a nonce generated by the UE.
  • a value signed with the PS private key, a time stamp generated by the PS, a value signed with the PS private key, and/or a PS certificate may be transmitted to AMF/SEAF.
  • AMF/SEAF may transmit DL NAS Transport to the UE.
  • the DL NAS Transport message includes UPU data, UPU-MAC-I_ausf, and Counter_upu, ePK.PS received in step 528 and a value signed with the private key of the PS, a value obtained by signing the nonce value generated by the UE with the private key of the PS, or PS It may include a time stamp generated by , a value signed with the private key of the PS, and/or a certificate of the PS.
  • the UE may verify UPU-MAC-I_ausf using K_ausf.
  • the UE can verify the certificate of the PS using the CA certificate provided by the first preset. Values signed by PS using the public key in the certificate of PS (ePK.PS signed with PS private key, nonce value generated by UE signed with PS private key, or time stamp generated by PS) signed value) can be verified.
  • the UE may generate ephemeral session keys using eSK.UE and ePK.PS.
  • Ephemeral shared keys consist of a key to be used for encryption (ephemeral encryption key) and a key to be used for integrity protection (ephemeral MAC key). These keys may be the same keys generated by the PS in step 521.
  • the UE can authenticate the MAC-tag value using the ephemeral MAC key and obtain the SO-SNPN credentials from the Cipher-text value using the ephemeral encryption key.
  • 6A to 6E are flowcharts illustrating an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then securely provisions SO-SNPN credentials from a PS according to an embodiment of the present disclosure.
  • the signaling order of FIGS. 6A to 6E may be changed depending on circumstances. Also, some of the steps of FIGS. 6A to 6E may be omitted depending on circumstances, or two or more steps may be combined and performed as one step.
  • one or more of the following settings may be performed in advance.
  • the UE manufacturer can provision the UE with credentials to be used for mutual authentication with the DCS when manufacturing the UE.
  • UE manufacturers can provision DCS with credentials to be used for mutual authentication with UEs accessing ON-SNPN. After the UE is sold to the SO-SNPN owner, the UE manufacturer can provision the DCS with the address of the PS that can provision the SO-SNPN's credentials to the UE.
  • the address of the PS may be used when the DCS searches for the PS to trigger provisioning on the PS.
  • the DCS may have information that the PS prefers provisioning using the control plane.
  • the DCS may be provided with ON-SNPN and information on whether the UE supports provisioning using the control plane.
  • the UE manufacturer may provide the PS with the ID (eg, Onboarding SUPI, IMEI, etc.) of the UE sold to the SO-SNPN owner.
  • the PS stores the UE ID and can later use it to find the SO-SNPN credentials to be provided to the UE with the corresponding UE ID.
  • the PS may receive information about whether the DCS and the UE support provisioning using the control plane from the terminal manufacturer.
  • a first preset 601-D1, a second preset 601-D2, and a third preset 601-D2. D3) may be performed.
  • the first presetting, the second presetting, and the third presetting may be simultaneously performed, or the three presettings may be sequentially performed without being performed simultaneously. If performed sequentially, the order may not be fixed.
  • the first presetting and/or the second presetting is a process necessary for successful authentication with the help of a DCS capable of authenticating the UE when the UE accesses an ON-SNPN without subscription information of the UE (the UE and the DCS It may include a process of pre-provisioning credentials) and a process necessary for the UE to successfully receive SO-SNPN credentials from the PS later (a process of storing the PS address in the DCS).
  • the DCS may be provided with PS, ON-SNPN, or an indicator indicating whether the UE supports provisioning using the control plane in advance, or otherwise, it may be provided through a registration process.
  • the PS may be previously provided with an indicator indicating whether the DCS or the UE supports provisioning using the control plane from the terminal manufacturer, or may be provided later by another entity.
  • the NG-RAN may broadcast broadcast system information.
  • Broadcast system information may be received by the UE.
  • the broadcast system information may include one or more PLMN identifiers (IDs), a network ID per PLMN ID, and an onboarding enabled indication.
  • IDs PLMN identifiers
  • a combination of PLMN ID and Network ID may represent NPN.
  • the NG-RAN may provide the UE with an indicator of whether the ON-SNPN supports provisioning using the control plane.
  • the UE may select an ON-SNPN based on the broadcasting system information received from the NG-RAN and transmit a Registration Request message to AMF/SEAF. For example, transmission of the registration request message may be triggered when a power-on event occurs in the UE or there is a user's input.
  • the registration request message may include a registration type and Onboarding SUCI.
  • the registration type may include "SNPN Onboarding” indicating that the UE does not have subscription information for the corresponding NPN.
  • an Onboarding SUCI could have the format "username@realm".
  • the realm part may represent DCS.
  • the UE may send an indicator of whether the UE supports provisioning using the control plane together with the registration request message.
  • the AMF/SEAF may receive a registration request message from the UE and check the Onboarding SUCI included in the received registration request message.
  • the AMF/SEAF may identify the DCS based on the realm part of the onboarding SUCI and transmit an Authentication Request message to the AUSF capable of communicating with the identified DCS.
  • the corresponding message may include an indicator of whether the UE received in step 603 supports provisioning using the control plane.
  • AUSF may transmit an authentication request message to the DCS based on the authentication request message.
  • the authentication request message transmitted to the DCS may include information included in the authentication request message that the AUSF receives from the AMF in step 604 . Additionally, an indicator of whether the ON-SNPN supports provisioning using the control plane may be included.
  • DCS is an AAA server
  • AUSF may send an authentication request message to DCS through NSSAAF for protocol conversion.
  • ON-SNPN and DCS may have a contractual relationship.
  • message exchange between the ON-SNPN and the DCS may be performed through NEF.
  • AUSF may replace the functional role of DCS in the authentication process.
  • the UE and the DCS may perform EAP authentication (eg, EAP-TLS).
  • EAP-TLS EAP authentication
  • step 607 if the DCS knows that all entities of the UE/ON-SNPN/DCS/PS support provisioning using the control plane based on the indicators received in step 605 or provided by the second preset, the DCS performs provisioning using the control plane. steps can be prepared. If at least one entity among UE/ON-SNPN/DCS/PS does not support provisioning using the control plane, steps 311 to 318 of FIG. 3 may be performed.
  • the DCS may forward a notification to the PS that provisioning using the control plane will be used.
  • the notification may include a UE ID and/or an indicator indicating that provisioning using the control plane is to be used. If the PS receives this, the SO-SNPN credential to be delivered to the corresponding UE may be prepared in advance.
  • the DCS may transmit an EAP response message to AUSF.
  • the EAP response message includes an authentication success message, onboarding SUPI indicating the UE, keying material for generating a key to be used for communication with the UE in ON-SNPN, and provisioning using the control plane. It may contain an indicator that it will be.
  • AUSF may generate K_ausf based on the key material in the EAP response message received in step 609.
  • AUSF may transmit an EAP response message to AMF/SEAF.
  • the EAP response message transmitted to the AMF/SEAF may include an authentication success message, K_seaf generated from K_ausf, an onboarding SUPI, and/or an indicator that provisioning using the control plane is performed.
  • AMF/SEAF may transmit an EAP response message to the UE.
  • the EAP response message may include an authentication success message, a 5G key set identifier (ngKSI) indicating a key, an ABBA parameter, and an indicator that provisioning using the control plane is performed.
  • ngKSI 5G key set identifier
  • the UE may generate K_ausf using a method corresponding to the method in which AUSF generated K_ausf in step 610.
  • the UE may generate an ephemeral key pair based on the indicator that provisioning using the control plane received in step 612 is performed.
  • An ephemeral key pair may consist of an ephemeral public key of UE (ePK.UE) and an ephemeral private key of UE (eSK.UE).
  • the UE may store the eSK.UE and prepare the ePK.UE for delivery.
  • AMF/SEAF may transmit a NAS Security Mode Command message for algorithm negotiation.
  • the UE may transmit a NAS Security Mode Complete message.
  • the corresponding message may include ePK.UE.
  • the AMF/SEAF can know that the UE has successfully completed the onboarding process to the ON-SNPN, and can prepare to notify it.
  • AMF/SEAF may transmit an authentication notification message to AUSF.
  • the authentication notification message may include information indicating that the UE has successfully completed the onboarding process, the ID of the UE, and/or the ePK.UE received in step 615 .
  • AUSF may transmit an authentication notification message to DCS.
  • the authentication notification message transmitted to the DCS may include the UE ID, the address of the UDM to be used in the UPU process, and/or ePK.UE.
  • step 619 the DCS matches the UE ID received in step 618 to find the address of the PS provided by the second preset.
  • the DCS may transmit an authentication notification message to the PS.
  • the authentication notification message may include the ID of the UE, ePK.UE, and an indicator that provisioning using the control plane will be used if step 608 is not performed.
  • the PS matches the ID of the UE received in step 620 with the UE ID provided by the third preset to find the credentials of the SO-SNPN to be provided to the corresponding UE.
  • the PS generates its own ephemeral key pair (ePK.PS, eSK.PS) based on the indicator provided by the DCS, and can generate ephemeral session keys with the ePK.UE and eSK.PS.
  • the temporary shared keys may be composed of a key to be used for encryption (ephemeral encryption key) and a key to be used for integrity protection (ephemeral MAC key).
  • the PS may encrypt the credentials of the SO-SNPN to be delivered to the corresponding UE with a temporary encryption key (Cipher-text value), and calculate a value obtained by hashing this value (Cipher-text value) with a MAC key (MAC-tag value).
  • the encrypted and integrity-protected SO-SNPN credential may consist of a Cipher-text value and a MAC-tag value.
  • the PS may transmit a provisioning request message to the DCS.
  • the message may include the UE ID, ePK.PS, and/or credentials of the encrypted and integrity-protected SO-SNPN.
  • the DCS may prepare to deliver a provisioning request message to the UDM.
  • the DCS or PS may replace the functional role of the UDM described later.
  • the DCS may transmit a provisioning request message to the UDM.
  • the corresponding message may include information received from the PS in step 622.
  • the UDM may request the Nausf_UPUPProtection service to perform the UPU process.
  • the corresponding message (e.g., Nausf_UPUPProtection request message) may include Onboarding SUPI and encrypted and integrity-protected SO-SNPN credentials.
  • the encrypted and integrity-protected SO-SNPN credential can be integrity-protected by AUSF using K_ausf.
  • AUSF may transmit the UPU-MAC-I_ausf value and the Counter_upu value calculated in step 626 to the UDM through Nausf_UPUPProtection Response.
  • Counter_upu is a value that starts from 0x00 0x00 and increases each time UPU-MAC-I_ausf is calculated, and can prevent replay attacks.
  • the UDM may transmit the UPU Data, the UPU-MAC-I_ausf calculated by AUSF in step 626, the Counter_upu value, and/or the ePK.PS received in step 624 to the AMF/SEAF through the Nudm_SDM_Notification service.
  • AMF/SEAF may transmit DL NAS Transport to the UE.
  • the DL NAS Transport message may include UPU data, UPU-MAC-I_ausf, and Counter_upu, and/or ePK.PS received in step 628.
  • the UE may verify UPU-MAC-I_ausf using K_ausf.
  • the UE may generate ephemeral session keys using eSK.UE and ePK.PS.
  • the temporary shared keys may be composed of a key to be used for encryption (ephemeral encryption key) and a key to be used for integrity protection (ephemeral MAC key). These keys are the same keys generated by PS in step 621.
  • the UE can authenticate the MAC-tag value using the ephemeral MAC key and obtain the SO-SNPN credentials from the Cipher-text value using the ephemeral encryption key.
  • FIGS. 7A to 7E are flowcharts illustrating an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then securely provisions SO-SNPN credentials from a PS according to an embodiment of the present disclosure.
  • FIGS. 7A to 7E may be changed depending on circumstances. Also, some of the steps of FIGS. 7A to 7E may be omitted depending on circumstances, or two or more steps may be combined and performed as one step.
  • one or more of the following settings may be performed in advance.
  • the UE manufacturer can provision the UE with credentials to be used for mutual authentication with the DCS when manufacturing the UE.
  • UE manufacturers can provision DCS with credentials to be used for mutual authentication with UEs accessing ON-SNPN. After the UE is sold to the SO-SNPN owner, the UE manufacturer can provision the DCS with the address of the PS that can provision the SO-SNPN's credentials to the UE.
  • the address of the PS may be used when the DCS searches for the PS to trigger provisioning on the PS.
  • the DCS may have information that the PS prefers provisioning using the control plane.
  • the DCS may be provided with ON-SNPN and information on whether the UE supports provisioning using the control plane.
  • the UE manufacturer may provide the PS with the ID (eg, Onboarding SUPI, IMEI, etc.) of the UE sold to the SO-SNPN owner.
  • the PS stores the UE ID and can later use it to find the SO-SNPN credentials to be provided to the UE with the corresponding UE ID.
  • the PS may receive information about whether the DCS and the UE support provisioning using the control plane from the terminal manufacturer.
  • a first preset (701-E1), a second preset (701-E2), and a third preset (701-E2) E3) may be performed.
  • the first presetting, the second presetting, and the third presetting may be simultaneously performed, or the three presettings may be sequentially performed without being performed simultaneously. If performed sequentially, the order may not be fixed.
  • the first presetting and/or the second presetting is a process necessary for successful authentication with the help of a DCS capable of authenticating the UE when the UE accesses an ON-SNPN without subscription information of the UE (the UE and the DCS It may include a process of pre-provisioning credentials) and a process necessary for the UE to successfully receive SO-SNPN credentials from the PS later (a process of storing the PS address in the DCS).
  • the DCS may be provided in advance with PS, ON-SNPN, or an indicator indicating whether the UE supports provisioning using the control plane, or otherwise may be provided through a registration process.
  • the PS may be previously provided with an indicator indicating whether the DCS or the UE supports provisioning using the control plane from the terminal manufacturer, or may be provided later by another entity.
  • the NG-RAN may broadcast broadcast system information.
  • Broadcast system information may be received by the UE.
  • the broadcast system information may include one or more PLMN identifiers (IDs), a network ID per PLMN ID, and an onboarding enabled indication.
  • IDs PLMN identifiers
  • a combination of PLMN ID and Network ID may represent NPN.
  • the NG-RAN may provide the UE with an indicator of whether the ON-SNPN supports provisioning using the control plane.
  • the UE may select an ON-SNPN based on the broadcasting system information received from the NG-RAN and transmit a Registration Request message to AMF/SEAF. For example, transmission of the registration request message may be triggered when a power-on event occurs in the UE or there is a user's input.
  • the registration request message may include a registration type and Onboarding SUCI.
  • the registration type may include "SNPN Onboarding” indicating that the UE does not have subscription information for the corresponding NPN.
  • an Onboarding SUCI could have the format "username@realm".
  • the realm part may represent DCS.
  • the UE may send an indicator of whether the UE supports provisioning using the control plane together with the registration request message.
  • the AMF/SEAF may receive a registration request message from the UE and check the onboarding SUCI included in the received registration request message.
  • the AMF/SEAF may identify the DCS based on the realm part of the onboarding SUCI and transmit an Authentication Request message to the AUSF capable of communicating with the identified DCS.
  • the corresponding message may include an indicator of whether the UE received in step 703 supports provisioning using the control plane.
  • AUSF may transmit an authentication request message to the DCS based on the authentication request message.
  • the authentication request message transmitted to the DCS may include information included in the authentication request message that the AUSF receives from the AMF/SEAF in step 704 . Additionally, an indicator of whether the ON-SNPN supports provisioning using the control plane may be included.
  • DCS is an AAA server
  • AUSF may send an authentication request message to DCS through NSSAAF for protocol conversion.
  • ON-SNPN and DCS may have a contractual relationship.
  • message exchange between the ON-SNPN and the DCS may be performed through NEF.
  • AUSF may replace the functional role of DCS in the authentication process.
  • the UE and the DCS may perform EAP authentication (eg, EAP-TLS).
  • EAP-TLS EAP authentication
  • step 707 if the DCS knows that all entities of the UE/ON-SNPN/DCS/PS support provisioning using the control plane, based on the indicators received in step 705 or provided by the second preset, the DCS performs provisioning using the control plane. steps can be prepared. In addition, after successful authentication, the DCS can store the EMSK (Extended Master Session Key) among the generated key materials. EMSK is one of the key materials generated after successful authentication, and is a value that is not transmitted to any other entity. If at least one entity among the UE/ON-SNPN/DCS/PS does not support provisioning using the control plane, steps 311 to 318 of FIG. 3 may be performed.
  • EMSK Extended Master Session Key
  • the DCS may forward a notification to the PS that provisioning using the control plane will be used.
  • the notification may include a UE ID and/or an indicator indicating that provisioning using the control plane is to be used. If the PS receives this, the SO-SNPN credential to be delivered to the corresponding UE may be prepared in advance.
  • the DCS may transmit an EAP response message to AUSF.
  • the EAP response message includes an authentication success message, onboarding SUPI indicating the UE, keying material for generating a key to be used for communication with the UE in ON-SNPN, and provisioning using the control plane. It may contain an indicator that it will be.
  • AUSF may generate K_ausf based on the key material in the EAP response message received in step 709.
  • AUSF may transmit an EAP response message to AMF/SEAF.
  • the EAP response message transmitted to the AMF/SEAF may include an authentication success message, K_seaf generated from K_ausf, an onboarding SUPI, and/or an indicator that provisioning using the control plane is performed.
  • AMF/SEAF may transmit an EAP response message to the UE.
  • the EAP response message transmitted to the UE may include an authentication success message, a 5G key set identifier (ngKSI) indicating a key, an ABBA parameter, and/or an indicator that provisioning using the control plane is performed.
  • ngKSI 5G key set identifier
  • the UE may generate K_ausf using a method corresponding to the method in which AUSF generated K_ausf in step 710.
  • the UE may generate an ephemeral key pair based on the indicator that provisioning using the control plane received in step 712 is performed.
  • An ephemeral key pair may consist of an ephemeral public key of UE (ePK.UE) and an ephemeral private key of UE (eSK.UE).
  • the UE may store the eSK.UE and prepare the ePK.UE for delivery.
  • the UE may obtain the EMSK obtained by the DCS in the same way in step 707, and may directly use the EMSK or perform integrity protection on the ePK.UE generated by the UE using this key material.
  • the AMF/SEAF may transmit a NAS Security Mode Command message to the UE for key sharing with the UE.
  • the UE may also transmit a NAS Security Mode Complete message to AMF/SEAF for key sharing.
  • the corresponding message may include ePK.UE and a MAC value integrity-protected with EMSK or a key using EMSK.
  • the AMF/SEAF can know that the UE has successfully completed the onboarding process to the ON-SNPN, and can prepare to notify it.
  • AMF/SEAF may transmit an authentication notification message to AUSF.
  • the authentication notification message includes information indicating that the UE has successfully completed the onboarding process, the ID of the UE, and/or the ePK.UE received in step 715 and the MAC value integrity-protected with EMSK or a key using EMSK. may also include
  • AUSF may transmit an authentication notification message to DCS.
  • the authentication notification message transmitted to the DCS may include a UE ID, a UDM address to be used in the UPU process, and/or an ePK.UE and a MAC value integrity-protected with EMSK or a key using EMSK.
  • step 719 the DCS matches the UE ID received in step 718 to find the address of the PS provided by the second preset.
  • the DCS can verify the MAC value received in step 718 using the EMSK stored in step 707.
  • the DCS may transmit an authentication notification message to the PS.
  • the authentication notification message transmitted to the PS may include the ID of the UE, ePK.UE, and an indicator that provisioning using the control plane will be used if step 708 is not performed.
  • the PS matches the ID of the UE received in step 720 with the UE ID provided by the third preset to find the credentials of the SO-SNPN to be provided to the corresponding UE.
  • the PS can generate its own ephemeral key pair (ePK.PS, eSK.PS) based on the indicator provided by the DCS, and can generate ephemeral session keys with the ePK.UE and eSK.PS.
  • the temporary shared keys may be composed of a key to be used for encryption (ephemeral encryption key) and a key to be used for integrity protection (ephemeral MAC key).
  • the PS may encrypt the credentials of the SO-SNPN to be delivered to the corresponding UE with a temporary encryption key (Cipher-text value), and calculate a value obtained by hashing this value (Cipher-text value) with a MAC key (MAC-tag value).
  • the encrypted and integrity-protected SO-SNPN credential may consist of a Cipher-text value and a MAC-tag value.
  • the PS may transmit a provisioning request message to the DCS.
  • the message may include the UE ID, ePK.PS, and/or credentials of the encrypted and integrity-protected SO-SNPN.
  • the DCS may prepare to deliver a provisioning request message to the UDM.
  • the DCS may calculate a MAC value by performing integrity protection using the EMSK stored in step 707 of the ePK.PS received in step 722 .
  • a DCS or PS may replace the functional role of the UDM described below.
  • the DCS may transmit a provisioning request message to the UDM.
  • the corresponding message may include the information received from the PS in step 722 and the MAC value integrity-protected ePK.PS in step 723.
  • the UDM may request the Nausf_UPUPProtection service to perform the UPU process.
  • the corresponding message (e.g., Nausf_UPUPProtection request message) may include Onboarding SUPI and encrypted and integrity-protected SO-SNPN credentials.
  • the encrypted and integrity-protected SO-SNPN credential can be integrity-protected by AUSF using K_ausf.
  • AUSF may transfer the UPU-MAC-I_ausf value and the Counter_upu value calculated in step 726 to the UDM through Nausf_UPUPProtection Response.
  • Counter_upu is a value that starts from 0x00 0x00 and increases each time UPU-MAC-I_ausf is calculated, and can prevent replay attacks.
  • the UDM may transmit the UPU Data, the UPU-MAC-I_ausf calculated by AUSF in step 726, the Counter_upu value, and the ePK.PS and MAC values received in step 724 to AMF/SEAF through the Nudm_SDM_Notification service.
  • AMF/SEAF may transmit DL NAS Transport to the UE.
  • the DL NAS Transport message may include UPU data, UPU-MAC-I_ausf, and Counter_upu, ePK.PS and MAC values received in step 728.
  • the UE may verify UPU-MAC-I_ausf using K_ausf. In addition, the UE may verify the MAC value received in step 729 by using EMSK.
  • the UE may generate ephemeral session keys using eSK.UE and ePK.PS.
  • the temporary shared keys may be composed of a key to be used for encryption (ephemeral encryption key) and a key to be used for integrity protection (ephemeral MAC key). These keys may be the same keys generated by the PS in step 721.
  • the UE can authenticate the MAC-tag-value using the ephemeral MAC key and obtain the SO-SNPN credential from the Cipher-text value using the ephemeral encryption key.
  • 8A and 8B are flowcharts illustrating an example of a method in which a UE accesses an ON-SNPN, performs mutual authentication, and then securely provisions SO-SNPN credentials from a PS according to an embodiment of the present disclosure.
  • FIGS. 8A and 8B may be changed according to circumstances. Also, some of the steps of FIGS. 8A and 8B may be omitted depending on circumstances, or two or more steps may be combined and performed as one step.
  • one or more of the following settings may be performed in advance.
  • the UE manufacturer can provision the UE with credentials to be used for mutual authentication with the DCS when manufacturing the UE.
  • the UE may have a CA certificate to authenticate the certificate of the PS and a certificate of the UE itself.
  • UE manufacturers can provision DCS with credentials to be used for mutual authentication with UEs accessing ON-SNPN. After the UE is sold to the SO-SNPN owner, the UE manufacturer can provision the DCS with the address of the PS that can provision the SO-SNPN's credentials to the UE. When provisioning using the control plane is performed, the address of the PS may be used when the DCS searches for the PS to trigger provisioning on the PS.
  • the DCS may be provided with information about whether the PS, ON-SNPN, and UE support provisioning using the control plane.
  • the UE manufacturer may provide the PS with the ID (eg, Onboarding SUPI, IMEI, etc.) of the UE sold to the SO-SNPN owner.
  • the PS stores the UE ID and can later use it to find the SO-SNPN credentials to be provided to the UE with the corresponding UE ID.
  • the PS may have a CA certificate to authenticate the certificate of the UE and a certificate of the PS itself.
  • the PS may receive information about whether the DCS and the UE support provisioning using the control plane from the terminal manufacturer.
  • a first preset (801-F1), a second preset (801-F2), and a third preset (801-F3) F3) may be performed.
  • the first presetting, the second presetting, and the third presetting may be simultaneously performed, or the three presettings may be sequentially performed without being performed simultaneously. If it is performed sequentially, the order may not be fixed.
  • the first presetting and/or the second presetting is a process necessary for successful authentication with the help of a DCS capable of authenticating the UE when the UE accesses an ON-SNPN without subscription information of the UE (the UE and the DCS It may include a process of pre-provisioning credentials) and a process necessary for the UE to successfully receive SO-SNPN credentials from the PS later (a process of storing the PS address in the DCS).
  • the first presetting and/or the third presetting is a process of setting certificates required for signing when the UE and PS send information to generate a temporary shared key (UE's certificate/CA certificate, PS certificate in the UE and PS, respectively) /CA certificate settings).
  • the DCS may be provided in advance with PS, ON-SNPN, or an indicator indicating whether the UE supports provisioning using the control plane, or otherwise may be provided through a registration process.
  • the PS may be previously provided with an indicator indicating whether the DCS or the UE supports provisioning using the control plane from the terminal manufacturer, or may be provided later by another entity.
  • the NG-RAN may broadcast broadcast system information.
  • Broadcast system information may be received by the UE.
  • the broadcast system information may include one or more PLMN identifiers (IDs), a network ID per PLMN ID, and an onboarding enabled indication.
  • IDs PLMN identifiers
  • a combination of PLMN ID and Network ID may represent NPN.
  • the NG-RAN may provide the UE with an indicator of whether the ON-SNPN supports provisioning using the control plane.
  • the UE may select an ON-SNPN based on the broadcasting system information received from the NG-RAN and transmit a Registration Request message to AMF/SEAF. For example, transmission of the registration request message may be triggered when a power-on event occurs in the UE or there is a user's input.
  • the registration request message may include a registration type and Onboarding SUCI.
  • the registration type may include "SNPN Onboarding” indicating that the UE does not have subscription information for the corresponding NPN.
  • an Onboarding SUCI could have the format "username@realm".
  • the realm part may represent DCS.
  • the UE may send an indicator indicating which option of provisioning using the control plane the UE supports in the registration request message together.
  • a UE may support one or more methods among several options. Alternatively, the UE may not support provisioning using the control plane. In this case, the indicator may have no value or may indicate a value of 0, for example.
  • the AMF/SEAF may receive a registration request message from the UE and check the Onboarding SUCI included in the received registration request message.
  • the AMF/SEAF may identify the DCS based on the realm part of the onboarding SUCI and transmit an Authentication Request message to the AUSF capable of communicating with the identified DCS.
  • the corresponding message may include an indicator of which option of provisioning using the control plane is supported by the UE received in step 803 .
  • AUSF may transmit an authentication request message to the DCS based on the authentication request message.
  • the authentication request message transmitted to the DCS may include information included in the authentication request message that the AUSF receives from the AMF in step 804 . Additionally, an indicator of whether the ON-SNPN supports provisioning using the control plane may be included.
  • DCS is an AAA server
  • AUSF may send an authentication request message to DCS through NSSAAF for protocol conversion.
  • ON-SNPN and DCS may have a contractual relationship.
  • message exchange between the ON-SNPN and the DCS may be performed through NEF.
  • AUSF may replace the functional role of DCS in the authentication process.
  • the UE and the DCS may perform EAP authentication (eg, EAP-TLS).
  • EAP-TLS EAP authentication
  • the DCS may transmit a notification to the PS based on the result of step 806.
  • the corresponding message includes the UE ID, and indicators received in step 805 or provided by the second preset (e.g., indicator of whether ON-SNPN supports provisioning using the control plane, DCS provisioning using the control plane). , an indicator of whether the UE supports an option among provisioning using the control plane, and the like) may be included.
  • the PS indicates that the indicators received in step 807 or the indicators provided by the third preset support the control plane for both UE/ON-SNPN/DCS/PS, and if the PS prefers an option supported by the UE, The PS may decide to provide the credentials of the SO-SNPN to the UE using the control plane. If there are several options supported by the UE, the PS can select and deliver the option it prefers. If at least one entity among the UE/ON-SNPN/DCS/PS indicates that provisioning using the control plane is not supported or the PS prefers provisioning using the user plane, in step 809 the indicator is set to a specific value (eg, For example, it can be sent after setting it to "0").
  • a specific value eg, For example, it can be sent after setting it to "0"
  • the PS may send an indicator indicating an option selected by the PS during provisioning using the control plane. If the option selected by the PS requires a nonce value generated by the PS, the nonce value generated by the PS may be transmitted in this step.
  • the UE may use the network entity of the ON-SNPN when receiving credentials of the SO-SNPN from the PS using the control plane.
  • credential is provisioned to the UE using the existing UPU process as it is, the credential information provided by the PS can be exposed to the ON-SNPN network entity.
  • the UE and PS each generate a temporary key pair, share each other's temporary public key, and use the other's temporary public key and their own temporary private key to create a temporary key pair.
  • a shared key can be generated.
  • PS encrypts SO-SNPN's credentials, performs integrity protection, and delivers them using the control plane.
  • ON-SNPN delivers encrypted and integrity-protected credential information to the UE using the control plane.
  • the UE can acquire the credentials of the SO-SNPN using the temporary shared key.
  • FIGS. 3A to 8B described above may be performed by a terminal and a network entity of FIGS. 9 and 10 described later.
  • FIG. 9 is a block diagram of a terminal according to an embodiment of the present disclosure.
  • a terminal may include a transceiver 920 and a control unit 910 that controls overall operations of the terminal.
  • the transmission/reception unit 920 may include a transmission unit 925 and a reception unit 923 .
  • the transceiver 920 may transmit and receive signals with other network entities (eg, an initial AMF or a base station).
  • other network entities eg, an initial AMF or a base station.
  • the controller 910 may control the terminal to perform any one operation among the various embodiments described above.
  • the control unit 910 and the transmission/reception unit 920 do not necessarily have to be implemented as separate modules, but can be implemented as a single component in the form of a single chip.
  • the controller 910 and the transceiver 920 may be electrically connected.
  • the controller 910 may be a circuit, an application-specific circuit, or at least one processor.
  • operations of the terminal may be realized by including a memory device storing corresponding program codes in a configuration unit (eg, the control unit 910 and/or other components not shown) in the terminal.
  • the network entity shown in FIG. 10 includes at least one NF (e.g., base station, initial AMF, target AMF, existing AMF, NSSF, NRF, SMF, UPF, AF, NEF, PCF, DN or UDM, etc.) depending on system implementation. ) may be included.
  • NF e.g., base station, initial AMF, target AMF, existing AMF, NSSF, NRF, SMF, UPF, AF, NEF, PCF, DN or UDM, etc.
  • a network entity may include a transceiver 1020 and a control unit 1010 that controls overall operations of the network entity.
  • the transmission/reception unit 1020 may include a transmission unit 1025 and a reception unit 1023.
  • the transmitting/receiving unit 1020 may transmit/receive a signal to/from a terminal or other network entities.
  • the controller 1010 may control a network entity to perform any one operation of the above-described embodiments.
  • the control unit 1010 and the transceiver 1020 do not necessarily have to be implemented as separate modules, but can be implemented as a single component in the form of a single chip.
  • the controller 1010 and the transceiver 1020 may be electrically connected.
  • the control unit 1010 may be a circuit, an application-specific circuit, or at least one processor.
  • operations of the network entity may be realized by including a memory device storing corresponding program codes in a configuration unit (eg, the controller 1010 and/or other components not shown) in the network entity.
  • FIGS. 1 to 10 exemplary diagrams of a control/data signal transmission/reception method, and operational procedure diagrams are not intended to limit the scope of rights of the embodiments of the present disclosure. That is, all components, entities, or operational steps described in FIGS. 1 to 10 should not be interpreted as being essential components for the implementation of the disclosure, and even if only some components are included, within the scope of not harming the essence of the disclosure. can be implemented in
  • the operations of the above-described embodiments may be realized by including a memory device storing a corresponding program code in an arbitrary component of a device. That is, the controller in the device may execute the above-described operations by reading and executing program codes stored in the memory device by a processor or a central processing unit (CPU).
  • a processor or a central processing unit (CPU).
  • Entities described in this specification, or various components, modules, etc. of a terminal device may include a hardware circuit, for example, a complementary metal oxide semiconductor-based logic circuit, firmware, and the like. , software and/or a combination of hardware and firmware and/or software embedded in a machine readable medium.
  • a hardware circuit for example, a complementary metal oxide semiconductor-based logic circuit, firmware, and the like.
  • software and/or a combination of hardware and firmware and/or software embedded in a machine readable medium may be implemented using electrical circuits such as transistors, logic gates, and application specific semiconductors.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 개시는 무선 통신 시스템에서 논 퍼블릭 네트워크를 사용함에 있어서, 단말이 서비스 받기를 희망하는 SO-SNPN의 credential을 PS로부터 안전하게 프로비저닝 받기 위한 방법 및 장치를 제공한다. 무선 통신 시스템에서 단말에 의해 수행되는 방법은 프로비저닝 서버의 인증서와 연관된 CA 인증서 및 상기 단말의 인증서를 포함하는 설정 정보를 획득하는 단계, 제어 평면을 이용한 프로비저닝이 수행됨을 확인하는 단계, 상기 확인에 기반하여 임시 키 쌍을 생성하는 단계, 및 상기 설정 정보 및 상기 임시 키 쌍에 기초하여, 상기 제어 평면에서 SO-SNPN 의 크리덴셜(credential)을 획득하는 단계를 포함할 수 있다.

Description

제어 평면을 이용하여 크리덴셜을 단말에 프로비저닝 시 종단 보안 형성을 위한 방법 및 장치
본 개시의 다양한 실시 예들은 무선 통신 시스템에서 단말의 자격 증명 정보(credential)를 프로비저닝(provisioning)하는 방법 및 장치에 관한 것이다.
5G 이동통신 기술은 빠른 전송 속도와 새로운 서비스가 가능하도록 넓은 주파수 대역을 정의하고 있으며, 3.5 기가헤르츠(3.5GHz) 등 6GHz 이하 주파수('Sub 6GHz') 대역은 물론 28GHz와 39GHz 등 밀리미터파(㎜Wave)로 불리는 초고주파 대역('Above 6GHz')에서도 구현이 가능하다. 또한, 5G 통신 이후(Beyond 5G)의 시스템이라 불리어지는 6G 이동통신 기술의 경우, 5G 이동통신 기술 대비 50배 빨라진 전송 속도와 10분의 1로 줄어든 초저(Ultra Low) 지연시간을 달성하기 위해 테라헤르츠(Terahertz) 대역(예를 들어, 95GHz에서 3 테라헤르츠(3THz) 대역과 같은)에서의 구현이 고려되고 있다.
5G 이동통신 기술의 초기에는, 초광대역 서비스(enhanced Mobile BroadBand, eMBB), 고신뢰/초저지연 통신(Ultra-Reliable Low-Latency Communications, URLLC), 대규모 기계식 통신 (massive Machine-Type Communications, mMTC)에 대한 서비스 지원과 성능 요구사항 만족을 목표로, 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위한 빔포밍(Beamforming) 및 거대 배열 다중 입출력(Massive MIMO), 초고주파수 자원의 효율적 활용을 위한 다양한 뉴머롤로지 지원(복수 개의 서브캐리어 간격 운용 등)와 슬롯 포맷에 대한 동적 운영, 다중 빔 전송 및 광대역을 지원하기 위한 초기 접속 기술, BWP(Band-Width Part)의 정의 및 운영, 대용량 데이터 전송을 위한 LDPC(Low Density Parity Check) 부호와 제어 정보의 신뢰성 높은 전송을 위한 폴라 코드(Polar Code)와 같은 새로운 채널 코딩 방법, L2 선-처리(L2 pre-processing), 특정 서비스에 특화된 전용 네트워크를 제공하는 네트워크 슬라이싱(Network Slicing) 등에 대한 표준화가 진행되었다.
현재, 5G 이동통신 기술이 지원하고자 했던 서비스들을 고려하여 초기의 5G 이동통신 기술 개선(improvement) 및 성능 향상(enhancement)을 위한 논의가 진행 중에 있으며, 차량이 전송하는 자신의 위치 및 상태 정보에 기반하여 자율주행 차량의 주행 판단을 돕고 사용자의 편의를 증대하기 위한 V2X(Vehicle-to-Everything), 비면허 대역에서 각종 규제 상 요구사항들에 부합하는 시스템 동작을 목적으로 하는 NR-U(New Radio Unlicensed), NR 단말 저전력 소모 기술(UE Power Saving), 지상 망과의 통신이 불가능한 지역에서 커버리지 확보를 위한 단말-위성 직접 통신인 비 지상 네트워크(Non-Terrestrial Network, NTN), 위치 측위(Positioning) 등의 기술에 대한 물리계층 표준화가 진행 중이다.
뿐만 아니라, 타 산업과의 연계 및 융합을 통한 새로운 서비스 지원을 위한 지능형 공장 (Industrial Internet of Things, IIoT), 무선 백홀 링크와 액세스 링크를 통합 지원하여 네트워크 서비스 지역 확장을 위한 노드를 제공하는 IAB(Integrated Access and Backhaul), 조건부 핸드오버(Conditional Handover) 및 DAPS(Dual Active Protocol Stack) 핸드오버를 포함하는 이동성 향상 기술(Mobility Enhancement), 랜덤액세스 절차를 간소화하는 2 단계 랜덤액세스(2-step RACH for NR) 등의 기술에 대한 무선 인터페이스 아키텍쳐/프로토콜 분야의 표준화 역시 진행 중에 있으며, 네트워크 기능 가상화(Network Functions Virtualization, NFV) 및 소프트웨어 정의 네트워킹(Software-Defined Networking, SDN) 기술의 접목을 위한 5G　베이스라인 아키텍쳐(예를 들어, Service based Architecture, Service based Interface), 단말의 위치에 기반하여 서비스를 제공받는 모바일 엣지 컴퓨팅(Mobile Edge Computing, MEC) 등에 대한 시스템 아키텍쳐/서비스 분야의 표준화도 진행 중이다.
이와 같은 5G 이동통신 시스템이 상용화되면, 폭발적인 증가 추세에 있는 커넥티드 기기들이 통신 네트워크에 연결될 것이며, 이에 따라 5G 이동통신 시스템의 기능 및 성능 강화와 커넥티드 기기들의 통합 운용이 필요할 것으로 예상된다. 이를 위해, 증강현실(Augmented Reality, AR), 가상현실(Virtual Reality, VR), 혼합 현실(Mixed Reality, MR) 등을 효율적으로 지원하기 위한 확장 현실(eXtended Reality, XR), 인공지능(Artificial Intelligence, AI) 및 머신러닝(Machine Learning, ML)을 활용한 5G 성능 개선 및 복잡도 감소, AI 서비스 지원, 메타버스 서비스 지원, 드론 통신 등에 대한 새로운 연구가 진행될 예정이다.
또한, 이러한 5G 이동통신 시스템의 발전은 6G 이동통신 기술의 테라헤르츠 대역에서의 커버리지 보장을 위한 신규 파형(Waveform), 전차원 다중입출력(Full Dimensional MIMO, FD-MIMO), 어레이 안테나(Array Antenna), 대규모 안테나(Large Scale Antenna)와 같은 다중 안테나 전송 기술, 테라헤르츠 대역 신호의 커버리지를 개선하기 위해 메타물질(Metamaterial) 기반 렌즈 및 안테나, OAM(Orbital Angular Momentum)을 이용한 고차원 공간 다중화 기술, RIS(Reconfigurable Intelligent Surface) 기술 뿐만 아니라, 6G 이동통신 기술의 주파수 효율 향상 및 시스템 네트워크 개선을 위한 전이중화(Full Duplex) 기술, 위성(Satellite), AI(Artificial Intelligence)를 설계 단계에서부터 활용하고 종단간(End-to-End) AI 지원 기능을 내재화하여 시스템 최적화를 실현하는 AI 기반 통신 기술, 단말 연산 능력의 한계를 넘어서는 복잡도의 서비스를 초고성능 통신과 컴퓨팅 자원을 활용하여 실현하는 차세대 분산 컴퓨팅 기술 등의 개발에 기반이 될 수 있을 것이다.
한편, 셀룰러 이동통신 표준을 담당하는 3GPP는 기존 4G LTE 시스템에서 5G 시스템으로의 진화를 꾀하기 위해 새로운 코어 네트워크(core network) 구조를 5G core (5GC)라는 이름으로 명명하고 표준화를 진행하고 있다.
5GC는 기존 4G를 위한 네트워크 코어인 진화된 패킷 코어(evolved packet core: EPC) 대비 다음과 같은 차별화된 기능을 지원한다.
첫째, 5GC에서는 네트워크 슬라이스(network slice) 기능이 도입된다. 5G의 요구 조건으로, 5GC는 다양한 종류의 단말 타입 및 서비스(예: eMBB, URLLC, 또는 mMTC 서비스)를 지원해야 한다. 다양한 종류의 서비스는 각각 코어 네트워크에 요구하는 요구 조건이 다르다. 예를 들어, eMBB 서비스는 높은 데이터 전송 속도(data rate)를 요구하고 URLLC 서비스는 높은 안정성과 낮은 지연을 요구한다. 이러한 다양한 서비스 요구 조건을 만족하기 위해 제안된 기술 중의 하나는 네트워크 슬라이싱(network slicing)이다.
네트워크 슬라이싱은 하나의 물리적인 네트워크를 가상화(virtualization) 하여 여러 개의 논리적인 네트워크를 만드는 방법으로, 각 네트워크 슬라이스 인스턴스(network slice instance: NSI)는 서로 다른 특성을 가질 수 있다. 따라서, 각 NSI는 그 특성에 맞는 네트워크 기능(network function: NF)을 가짐으로써 다양한 서비스 요구 조건을 만족시킬 수 있다. 각 단말마다 요구하는 서비스의 특성에 맞는 NSI가 할당되면 여러 5G 서비스가 효율적으로 지원될 수 있다.
둘째, 5GC는 이동성 관리 기능과 세션 관리 기능의 분리를 통해 네트워크 가상화 패러다임 지원을 수월하게 할 수 있다. 4G LTE에서는 모든 단말들에 대한 등록, 인증, 이동성 관리 및 세션 관리 기능을 담당하는 이동성 관리 엔티티(mobility management entity: MME)라는 단일 코어 장비와의 시그널링 교환을 통해서 서비스를 제공받을 수 있었다. 하지만, 5G에서는 단말들의 수가 폭발적으로 늘어나고, 각 단말의 타입에 따라 지원해야 하는 이동성 및 트래픽/세션 특성이 세분화됨에 따라, MME와 같은 단일 장비에서 모든 기능을 지원하게 되면 필요한 기능별로 엔티티를 추가하는 확장성(scalability)이 떨어질 수 밖에 없다. 따라서, 제어 평면을 담당하는 코어 장비의 기능/구현 복잡도와 시그널링 부하 측면에서 확장성 개선을 위해 이동성 관리 기능과 세션 관리 기능을 분리하는 구조를 기반으로 다양한 기능들이 개발되고 있다.
이동 통신 시스템의 발전에 따라 다양한 서비스를 제공할 수 있게 됨으로써 이동 통신 시스템, 특히 NPN(Non-Public Network)를 효율적으로 사용하기 위한 방안이 요구되고 있다. 이를 고려하여, 본 개시의 다양한 실시 예들은 단말이 서비스 받기를 원하는 SO-SNPN(Subscription Owner-Standalone Non-Public Network)의 자격 증명 정보(이하 'credential'이라 칭함)를 가지고 있지 않더라도 SO-SNPN으로부터 원하는 서비스를 제공받을 수 있도록 하는 방법 및 장치를 제공한다.
본 개시의 다양한 실시 예들은 credential을 관리하는 PS(Provisioning Server)로부터 제어 평면(Control Plane)을 이용하여 UE의 credential을 UE와 PS 이외의 엔티티에 노출시키지 않고 안전하게 제공하는 방법 및 장치를 제공한다.
본 개시의 다양한 실시 예들은 UE가 제어 평면을 통해 제공된 credential을 기반으로 서비스 받기를 희망하는 SO-SNPN에 성공적으로 접속을 완료할 수 있도록 하기 위한 방법 및 장치를 제공한다.
본 개시의 일 실시 예에 따른 무선 통신 시스템에서 단말에 의해 수행되는 방법은 프로비저닝 서버의 인증서와 연관된 CA(certificate authority) 인증서 및 상기 단말의 인증서를 포함하는 설정 정보를 획득하는 단계, 제어 평면을 이용한 프로비저닝이 수행됨을 확인하는 단계, 상기 확인에 기반하여 임시 키 쌍(ephemeral key pair)을 생성하는 단계, 및 상기 설정 정보 및 상기 임시 키 쌍에 기초하여, 상기 제어 평면에서 SO-SNPN (subscription owner-standalone non-public network)의 크리덴셜(credential)을 획득하는 단계를 포함할 수 있다.
본 개시의 일 실시 예에 따른 무선 통신 시스템에서 프로비저닝 서버에 의해 수행되는 방법은 상기 프로비저닝 서버의 인증서 및 단말의 인증서와 연관된 CA 인증서를 포함하는 설정 정보를 획득하는 단계, 제어 평면을 이용한 프로비저닝이 수행됨을 확인하는 단계, 상기 제어 평면을 이용한 프로비저닝을 위한 임시 키 쌍을 생성하는 단계, 및 상기 설정 정보 및 상기 임시 키 쌍에 기초하여, 상기 제어 평면에서 전달될 SO-SNPN의 크리덴셜을 생성하는 단계를 포함할 수 있다.
본 개시의 일 실시 예에 따른 무선 통신 시스템에서 단말은 송수신부 및 상기 송수신부와 기능적으로 연결된 제어부를 포함하고, 상기 제어부는 프로비저닝 서버의 인증서와 연관된 CA 인증서 및 상기 단말의 인증서를 포함하는 설정 정보를 획득하고, 제어 평면을 이용한 프로비저닝이 수행됨을 확인하며, 상기 확인에 기반하여 임시 키 쌍을 생성하고, 및 상기 설정 정보 및 상기 임시 키 쌍에 기초하여, 상기 제어 평면에서 SO-SNPN의 크리덴셜(credential)을 획득하도록 구성될 수 있다.
본 개시의 일 실시 예에 따른 무선 통신 시스템에서 프로비저닝 서버는 송수신부 및 상기 송수신부와 기능적으로 연결된 제어부를 포함하고, 상기 제어부는 상기 프로비저닝 서버의 인증서 및 단말의 인증서와 연관된 CA 인증서를 포함하는 설정 정보를 획득하고, 제어 평면을 이용한 프로비저닝이 수행됨을 확인하며, 상기 제어 평면을 이용한 프로비저닝을 위한 임시 키 쌍을 생성하고, 및 상기 설정 정보 및 상기 임시 키 쌍에 기초하여, 상기 제어 평면에서 전달될 SO-SNPN 의 크리덴셜을 생성하도록 구성될 수 있다.
본 개시의 실시 예들에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 개시의 실시 예들이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확히 이해될 수 있을 것이다.
본 개시의 다양한 실시 예들에 따르면, 무선 통신 시스템에서 UE가 SO-SNPN의 credential을 가지고 있지 않은 상태에서, SO-SNPN의 credential을 소유하고 있는 PS로부터 안전하게 해당 credential을 제공받을 수 있고, 이를 이용하여 SO-SNPN으로부터 원하는 서비스를 효과적으로 제공받을 수 있다.
또한, 본 개시의 다양한 실시 예들에 따르면, 인증 과정에서의 DCS (default credentials server)의 기능을 ON-SNPN (Onboarding - Standalone Non-Public Network (SNPN))의 AUSF (authentication server function)가 수행할 수도 있고, AUSF가 아닌 DCS가 수행할 수도 있다. 또한, UPU (UE Parameters Update) 과정을 진행함에 있어 UDM (unified data management)의 기능을 DCS, PS, 혹은 ON-SNPN의 UDM이 수행할 수도 있다. UE와 PS만이 생성할 수 있는 임시 공유 키를 이용하여 PS가 전달할 SO-SNPN의 credential을 보호하여 UE와 PS 이외의 엔티티가 열람할 수 없도록 안전하게 UE에 전달할 수 있다.
본 개시에서 얻을 수 있는 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시의 일 실시 예에 따른 5G 이동 통신 네트워크의 구조를 예시한 도면이다.
도 2는 본 개시의 일 실시 예들에 따른 UE의 credential를 프로비저닝 하기 위한 네트워크의 구조를 나타낸 도면이다.
도 3a 내지 도 3c는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 사용자 평면을 사용하여 PS로부터 SO-SNPN의 credential을 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 4a 내지 도 4e는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 PS로부터 SO-SNPN의 credential을 안전하게 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 5a 내지 도 5e는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 PS로부터 SO-SNPN의 credential을 안전하게 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 6a 내지 도 6e는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 PS로부터 SO-SNPN의 credential을 안전하게 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 7a 내지 도 7e는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 PS로부터 SO-SNPN의 credential을 안전하게 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 8a 및 도 8b는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 PS로부터 SO-SNPN의 credential을 안전하게 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 9는 본 개시의 일 실시예에 따른 단말의 구성을 나타낸 도면이다.
도 10은 본 개시의 일 실시예에 따른 네트워크 엔티티(network entity)의 구성을 나타낸 도면이다.
이하 다양한 실시 예들을 첨부한 도면과 함께 상세히 설명한다. 또한 본 개시의 실시 예들을 설명함에 있어서 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 실시 예들의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다. 그리고 후술되는 용어들은 실시 예들에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성한다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
이 때, 본 개시의 다양한 실시 예들에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA 또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행할 수 있다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함할 수 있다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.
이하, 기지국은 단말의 자원 할당을 수행하는 주체로서, eNode B(eNB), Node B, BS(base station), RAN(radio access network), AN(access network), RAN node, NR NB, gNB, 무선 접속 유닛, 기지국 제어기, 또는 네트워크 상의 노드 중 적어도 하나일 수 있다. 단말은 UE(user equipment), MS(mobile station), 셀룰러폰, 스마트폰, 컴퓨터, 또는 통신 기능을 수행할 수 있는 멀티미디어 시스템을 포함할 수 있다. 본 개시의 다양한 실시 예들에서는 단말이 UE인 경우를 일 예로 설명하기로 한다.
또한, 이하에서 LTE, LTE-A, 혹은 NR을 기반으로 하는 시스템을 일 예로서 본 개시의 다양한 실시 예들을 설명하지만, 유사한 기술적 배경 또는 채널 형태를 갖는 여타의 통신 시스템에도 본 개시의 다양한 실시 예들이 적용될 수 있다. 또한, 본 개시의 다양한 실시 예들을 숙련된 기술적 지식을 가진자의 판단으로써 그 범위를 크게 벗어나지 아니하는 범위에서 일부 변형을 통해 다른 통신 시스템에도 적용될 수 있다.
5G 네트워크 시스템이 제공하는 각 기능들은 네트워크 기능(NF) 단위로 수행될 수 있다. 5G 이동 통신 네트워크의 구조(architecture)의 일 예는 도 1에 도시되어 있다.
도 1은 본 개시의 일 실시 예에 따른 5G 이동 통신 네트워크의 구조를 예시한 도면이다.
도 1을 참조하면, 5G 이동 통신 네트워크는 UE(110)의 네트워크 접속과 이동성을 관리 하는 AMF(access and mobility management function)(120), UE(110)에 대한 세션과 관련된 기능들을 수행하는 SMF(session management function)(130), 사용자 데이터의 전달을 담당하고 SMF(130)에 의해 제어를 받는 UPF(user plane function)(125), 어플리케이션 서비스의 제공을 위해 5GC와 통신하는 AF(application function)(180), AF(180)와의 통신을 지원하는 NEF(network exposure function)(170), 데이터 저장 및 관리를 위한 UDM(unified data management)(160)과 UDR(unified data repository)(미도시), 정책을 관리하는 PCF(policy and control function)(150), 또는 사용자 데이터가 전달되는 데이터 네트워크(data network: DN)(140)(예: 인터넷) 중 적어도 하나를 포함할 수 있다.
상기한 NF들 외에 UE(110) 및 5G 이동 통신 네트워크를 관리하기 위한 시스템인 OAM(operation, administration, and management) 서버(미도시)가 존재할 수 있다. 그리고 5G 이동 통신 네트워크에는 RAN(예: 기지국)(115), AUSF(authentication server function)(165), NSSF(network slice selection function)(175), 또는 NRF(network repository function)(155) 중 적어도 하나가 더 포함될 수 있다.
도 2는 본 개시의 일 실시 예에 따른 UE의 credential 를 프로비저닝 하기 위한 네트워크의 구조를 나타낸 도면이다.
도 2에 도시된 네트워크는 무선 통신 시스템(예: 5GS(5th generation system))에 포함될 수 있고, 도 1에 도시된 5G 이동 통신 네트워크의 구성 요소들(예: NF들) 중 적어도 하나와 동일하거나 유사한 구성 요소를 포함할 수 있다. 예를 들어, 도 2의 UE(210), NG-RAN(215), UPF(225), 및 DN(240)은 각각 도 1의 UE(110), RAN(115), UPF(125), 및 DN(140)일 수 있다. 그리고, 도 2의 AMF(220) 및 SMF(230)는 각각 도 1의 AMF(120) 및 SMF(130)일 수 있다. 또한, 도 2의 NSSF(270), UDM(275), NEF(280), NRF(285), 및 AUSF(290)는 각각 도 1의 NSSF(175), UDM(160), NEF(170), NRF(155), 및 AUSF(165)일 수 있다.
일 실시 예에 따르면, UE(210), NG-RAN(215), UPF(225), DN(240), AMF(220), SMF(230), NSSF(270), UDM(275), NEF(280), NRF(285), 및 AUSF(290)는 ON-SNPN(Onboarding - Standalone Non-Public Network (SNPN))에 포함될 수 있고, PS(provisioning server)(260)는 SO-SNPN(Subscription Owner-SNPN)에 포함될 수 있다.
본 개시의 다양한 실시 예들에 따르면, 도 2에 도시된 바와 같은 네트워크 구조를 기반으로, SO-SNPN의 자격 증명 정보(이하 'credential'이라 칭함)가 없는 UE(210)에 대해 SO-SNPN의 credential이 프로비저닝(provisioning)될 수 있다. 일 실시 예에서, UE(210)는 인증 동작 수행 후 PS(260)로부터 SO-SNPN의 credential을 제공받을 수 있다. 일 실시 예에 따른 인증 동작은 UE(210)가 ON-SNPN에 등록 요청을 송신하고, UE(210)를 제조할 시 프로비저닝 된 default credential을 이용하여 DCS (default credentials server) (250)와 인증을 수행하는 동작을 포함할 수 있다. 또는, 일 실시 예에 따른 인증 동작은 UE(210)가 ON-SNPN과 인증을 수행한 후 선택적으로 DCS(250)와 추가적인 인증을 수행하는 동작을 포함할 수도 있다.
이처럼 SO-SNPN의 credential이 없이 제조된 UE(210)는 서비스 받기 원하는 SO-SNPN의 credential을 획득하기 위해, ON-SNPN에 등록 요청을 한 후 UE(210)의 default credential을 기반으로 DCS(250) 혹은 ON-SNPN과 상호 인증을 수행할 수 있다. DCS(250)는 UE(210)를 인증하는 네트워크 또는 엔티티로써 ON-SNPN의 내부 혹은 외부에 존재할 수 있다. PS(260)는 UE(260)의 SO-SNPN credential을 가진 네트워크 또는 엔티티로서 ON-SNPN의 내부 혹은 외부에 위치할 수 있고, DCS(250)와 동일한 도메인 혹은 상이한 도메인에 존재할 수 있다.
ON-SNPN은 UE(210)의 가입 정보(subscription information) 또는 가입 데이터(subscription data)를 가지고 있지 않기 때문에, ON-SNPN의 UDM(275)은 UE(210)를 인증하거나 credential을 프로비저닝 할 때 사용되지 않을 수 있다. 혹은, ON-SNPN의 UDM(275)은 ON-SNPN에 존재하지 않을 수도 있다.
인증 동작이 수행될 때, DCS(250)가 AAA(authentication authorization accounting) 서버인 경우 프로토콜(protocol) 변환(예: SBI (service based interface)와 RADIUS (remote authentication dial-in user service) 간의 변환)을 위해 NSSAAF(network slice-specific authentication and authorization function)(295)가 사용될 수도 있다. UE(210)는 인증 동작이 성공적으로 수행되고 ON-SNPN에 접속이 완료되면, PS(260)로부터 제어 평면을 통해 SO-SNPN의 credential을 제공받는 프로비저닝 과정이 수행될 수 있다. 프로비저닝 과정에 있어서 DCS(250) 혹은 PS(260)가 ON-SNPN 도메인 외부에 존재할 경우에는 ON-SNPN의 NEF(280)가 사용될 수도 있다.
이하 도 2에 도시된 네트워크 환경에서 수행되는 다양한 실시 예들에 따른 동작들을 도 3a 내지 도 8b를 참조하여 설명하기로 한다. 도 3a 내지 도 8b에서 설명되는 구성 요소들(예: UE, DCS, AMF, 또는 PS 등)은 도 2에 도시된 구성 요소들에 대응될 수 있다.
본 개시의 다양한 실시 예들은 PS가 SO-SNPN의 credential을 제어 평면을 이용하여 프로비저닝 할 때, UE와 PS간 종단 보호를 형성하기 위해 UE와 PS가 전달하는 내용에 따라 다양한 실시 예들을 제시한다.
도 3a 내지 도 3c는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 사용자 평면을 사용하여 PS로부터 SO-SNPN의 credential을 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 3a 내지 도 3c의 시그널링 순서는 경우에 따라 변경될 수도 있다. 또한, 도 3a 내지 도 3c의 각 단계들 중 일부는 경우에 따라 생략될 수도 있으며, 둘 이상의 단계가 결합되어 하나의 단계로 수행될 수도 있다.
도 3a 내지 도 3c에 도시된 절차를 위해 다음의 설정 중 하나 이상이 사전에 수행될 수 있다.
301-A1: 제 1 사전 설정
UE 제조사는 UE를 제조할 때 DCS와의 상호 인증에 사용될 credential을 UE에 프로비저닝 할 수 있다. UE는 PS의 인증서를 검증할 CA (certificate authority) 인증서와 UE 자신의 인증서를 가지고 있을 수 있다.
301-A2: 제 2 사전 설정
UE 제조사는 온보딩(onboarding)의 목적을 위해 ON-SNPN에 접속하는 UE와의 상호 인증에 사용될 credential을 DCS에 프로비저닝 할 수 있다. UE가 SO-SNPN 소유자에 팔리고 난 후, UE 제조사는 SO-SNPN의 credential을 UE에 프로비저닝 할 수 있는 PS의 주소 또는 PS의 인증서를 검증할 수 있는 CA 인증서 중 적어도 하나를 DCS에 프로비저닝 할 수 있다. PS의 주소는 제어 평면을 이용한 프로비저닝이 수행될 경우, DCS가 PS에 프로비저닝을 트리거링(triggering)하기 위해 PS를 찾을 때 사용될 수 있다. DCS는 PS, ON-SNPN, 또는 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 모두 혹은 일부 제공받을 수도 있다.
301-A3: 제 3 사전 설정
UE 제조사는 SO-SNPN 소유자에 팔린 UE의 ID(예를 들어 Onboarding SUPI (subscriber permanent identifier), IMEI(international mobile equipment identity) 등)를 PS에 제공할 수 있다. PS는 UE ID를 저장해두었다가 후에 해당 UE ID를 가진 단말에 제공할 SO-SNPN의 credential을 찾는 데 사용할 수 있다. PS는 UE의 인증서를 검증할 CA 인증서와 PS 자신의 인증서를 가지고 있을 수 있다. PS는 단말 제조사로부터 DCS와 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
도 3a 내지 도 3c를 참조하면, 301-A1, 301-A2, 301-A3 단계에서 제 1 사전 설정(301-A1), 제 2 사전 설정(301-A2), 그리고 제 3 사전 설정(301-A3)이 수행될 수 있다. 제 1 사전 설정, 제 2 사전 설정, 제 3 사전 설정은 동시에 수행되거나, 3 개의 사전 설정이 동시에 수행되지 않고 순차적으로 수행될 수 있다. 순차적으로 수행되는 경우 그 순서는 정해져 있는 것은 아닐 수 있다.
제 1 사전 설정 및/또는 제 2 사전 설정은 UE가 UE의 가입 정보가 없는 ON-SNPN에 접속할 때, UE를 인증할 수 있는 DCS의 도움을 받아 성공적으로 인증하기 위해 필요한 과정(UE와 DCS가 credential을 미리 프로비전 받는 과정)과, 후에 UE가 PS로부터 성공적으로 SO-SNPN의 credential을 제공받기 위해 필요한 과정(DCS에 PS 주소를 저장하는 과정 및 PS의 인증서를 검증할 수 있는 CA 인증서를 저장하는 과정)을 포함할 수 있다. 제 1 사전 설정 및/또는 제 3 사전 설정은 UE와 PS가 임시 공유 키를 생성하기 위해 정보를 보낼 때 사인에 필요한 인증서를 설정해 놓는 과정(UE와 PS에 각각 UE의 인증서/CA 인증서, PS 인증서/CA 인증서 설정)을 포함할 수 있다. 제 2 사전 설정을 통해 DCS는 PS, ON-SNPN, 또는 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 그렇지 않은 경우 등록 과정을 통해서 제공받을 수 있다. 제 3 사전 설정을 통해 PS는 단말 제조사로부터 DCS 혹은 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 이후의 다른 엔티티로부터 제공받을 수도 있다.
302 단계에서 NG-RAN은 브로드캐스트 시스템 정보(broadcast system information)를 브로드캐스팅 할 수 있다. 브로드캐스트 시스템 정보는 UE에 의해 수신될 수 있다. 브로드캐스트 시스템 정보는 하나 이상의 PLMN(public land mobile network) 식별자(identifier: ID), PLMN ID당 네트워크 ID, 온보딩 가능 인디케이션(onboarding enabled indication)을 포함할 수 있다. PLMN ID와 Network ID의 조합은 NPN(Non-Public Network)을 나타낼 수 있다. NG-RAN은 UE에 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 제공할 수도 있다.
303 단계에서 UE는 NG-RAN으로부터 수신한 브로드캐스팅 시스템 정보를 기반으로 ON-SNPN을 선택하고, AMF/SEAF로 등록 요청(Registration Request) 메시지를 송신할 수 있다. 예를 들어, 등록 요청 메시지의 송신은 UE에서 파워 온(power-on) 이벤트가 발생하거나 사용자의 입력이 있는 경우 트리거될 수 있다. 등록 요청 메시지는 등록 타입(registration type) 및 Onboarding SUCI(subscription concealed identifier)를 포함할 수 있다. 등록 타입은 UE가 해당 NPN에 대한 가입 정보가 없다는 것을 나타내는"SNPN Onboarding"을 포함할 수 있다. 예를 들어, Onboarding SUCI는 "username@realm"와 같은 형식을 가질 수 있다. 여기서 realm 부분은 DCS를 나타낼 수 있다. UE는 등록 요청 메시지에 UE가 제어 평면을 이용한 프로비저닝을 지원하는지 여부를 나타내는 지시자를 함께 보낼 수도 있다.
304 단계에서 AMF/SEAF는 UE로부터 등록 요청 메시지를 수신하고, 수신된 등록 요청 메시지에 포함된 Onboarding SUCI를 확인할 수 있다. 그리고 AMF/SEAF는 onboarding SUCI의 realm 부분을 기반으로 DCS를 식별하고, 식별된 DCS와 통신할 수 있는 AUSF로 인증 요청(Authentication Request) 메시지를 송신할 수 있다. 해당 메시지에는 303 단계에서 수신된 UE가 제어 평면을 이용한 프로비저닝을 지원하는지 여부를 나타내는 지시자를 포함할 수도 있다.
305 단계에서 AUSF는 인증 요청 메시지를 기반으로 DCS로 인증 요청 메시지를 송신할 수 있다. 인증 요청 메시지는 AUSF가 304 단계에서 AMF로부터 수신한 인증 요청 메시지에 포함된 정보를 포함할 수 있다. 추가로 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 포함할 수도 있다. DCS가 AAA 서버인 경우, AUSF는 프로토콜 변환을 위해 NSSAAF를 통해 DCS에 인증 요청 메시지를 송신할 수 있다. ON-SNPN과 DCS는 계약 관계가 있을 수도 있다. 또한 DCS가 ON-SNPN의 도메인 밖에 존재할 경우에 ON-SNPN과 DCS 간의 메시지 교환은 NEF를 통해 수행될 수도 있다. 혹은 인증 과정에서의 DCS의 기능적 역할을 AUSF가 대신할 수도 있다.
306 단계에서 UE와 DCS는 EAP(extensible authentication protocol) 인증(예를 들어 EAP-TLS(transport layer security))을 수행할 수 있다.
307 단계에서 DCS는 305 단계에서 받은 지시자 혹은 제 2 사전 설정에 의해 설정된 지시자에 의해, 적어도 하나의 엔티티(e.g., UE, ON-SNPN, DCS, PS 중)가 제어 평면을 이용한 프로비저닝을 지원하지 않는다는 것을 DCS가 알 수 있다면 311 단계로 넘어갈 수도 있다. 311 단계로 넘어가기 전에, DCS는 PS에 사용자 평면을 이용한 프로비저닝이 수행될 것이라는 지시자를 전달할 수도 있다. 적어도 하나의 엔티티가 제어 평면을 이용한 프로비저닝을 지원하지 않기 때문에 제어 평면을 이용한 방법이 수행되지 않는 것을 DCS가 알게 되더라도 308-310 단계는 그대로 수행될 수도 있다. 만약 DCS가 제 2 사전 설정에 의해 PS의 제어 평면을 이용한 프로비저닝 지원 여부를 알고 있지 않다면 308 단계가 수행될 수 있다.
308 단계에서 DCS는 305 단계에서 수신한 지시자들(e.g., ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지 여부를 나타내는 지시자, 단말이 제어 평면을 이용한 프로비저닝을 지원하는지 여부를 나타내는 지시자 등)과 DCS의 제어 평면을 이용한 프로비저닝 지원 여부에 대한 지시자를 PS에 송신할 수 있다.
309 단계에서 PS는 308 단계에서 받은 지시자들 혹은 제 3 사전 설정에 의해 설정된 지시자들을 기반으로, 적어도 하나의 엔티티(e.g., UE, ON-SNPN, DCS, PS 중)가 제어 평면을 이용한 프로비저닝을 지원하지 않는다면, 사용자 평면을 이용한 프로비저닝이 수행된다는 지시자를 보낼 준비를 할 수 있다.
310 단계에서 PS는 DCS에 사용자 평면을 이용한 프로비저닝이 수행될 것이라는 지시자를 송신할 수 있다.
311 단계에서 DCS는 EAP 응답(response) 메시지를 AUSF로 송신할 수 있다. EAP 응답 메시지는 인증 성공(EAP Success) 메시지와 UE를 나타내는 Onboarding SUPI, ON-SNPN에서 UE와의 통신에 사용될 키(key)를 생성하기 위한 키 재료(keying material), 그리고 310 단계에서 수신한 사용자 평면을 이용한 프로비저닝이 수행될 것이라는 지시자를 포함할 수도 있다.
312 단계에서 AUSF는 310 단계에서 수신한 EAP 응답 메시지 내의 키 재료를 기반으로 K_ausf (중간 키(intermediate key))를 생성할 수 있다.
313 단계에서 AUSF는 EAP 응답 메시지를 AMF/SEAF로 송신할 수 있다. AMF/SEAF로 전송되는 EAP 응답 메시지는 인증 성공 메시지 (EAP success), K_ausf 로부터 생성한 K_seaf (앵커 키(anchor key)), Onboarding SUPI, 그리고 사용자 평면을 이용한 프로비저닝이 수행된다는 지시자를 포함할 수도 있다.
314 단계에서 AMF/SEAF는 EAP 응답 메시지를 UE로 송신할 수 있다. UE로 전송되는 EAP 응답 메시지는 인증 성공 메시지 (EAP success), 키를 나타내는 ngKSI(5G key set identifier), ABBA 파라미터, 및 사용자 평면을 이용한 프로비저닝이 수행된다는 지시자를 포함할 수도 있다.
315 단계에서 UE는 312 단계에서 AUSF가 K_ausf를 생성한 방식에 대응되는 방식을 사용하여 K_ausf를 생성할 수 있다.
316 단계에서 AMF/SEAF는 UE와의 알고리즘 협상을 위해 NAS(non access stratum) Security Mode Command 메시지를 송신할 수 있다.
317 단계에서 UE는 NAS Security Mode Complete 메시지를 송신할 수 있다.
318 단계에서 UE는 PDU Session 수립 요청을 하고 PS와 사용자 평면을 이용한 프로비저닝을 수행할 수 있다.
도 4a 내지 도 4e는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 PS로부터 SO-SNPN의 credential을 안전하게 프로비저닝 받는 일 예를 도시한 흐름도이다.
도 4a 내지 도 4e의 시그널링 순서는 경우에 따라 변경될 수도 있다. 또한, 도 4a 내지 도 4e의 각 단계들 중 일부는 경우에 따라 생략될 수도 있으며, 둘 이상의 단계가 결합되어 하나의 단계로 수행될 수도 있다.
도 4a 내지 도 4e에 도시된 절차를 위해 다음의 설정 중 하나 이상이 사전에 수행될 수 있다.
401-B1: 제 1 사전 설정
UE 제조사는 UE를 제조할 때 DCS와의 상호 인증에 사용될 credential을 UE에 프로비저닝 할 수 있다. UE는 PS의 인증서를 검증할 CA 인증서와 UE 자신의 인증서를 가지고 있을 수 있다.
401-B2: 제 2 사전 설정
UE 제조사는 온보딩(onboarding)의 목적을 위해 ON-SNPN에 접속하는 UE와의 상호 인증에 사용될 credential을 DCS에 프로비저닝 할 수 있다. UE가 SO-SNPN 소유자에 팔리고 난 후, UE 제조사는 SO-SNPN의 credential을 UE에 프로비저닝 할 수 있는 PS의 주소 또는 PS의 인증서를 검증할 수 있는 CA 인증서 중 적어도 하나를 DCS에 프로비저닝 할 수 있다. PS의 주소는 제어 평면을 이용한 프로비저닝이 수행될 경우, DCS가 PS에 프로비저닝을 트리거링(triggering)하기 위해 PS를 찾을 때 사용될 수 있다. DCS는 PS, ON-SNPN, 또는 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
401-B3: 제 3 사전 설정
UE 제조사는 SO-SNPN 소유자에 팔린 UE의 ID(예를 들어 Onboarding SUPI, IMEI 등)를 PS에 제공할 수 있다. PS는 UE ID를 저장해두었다가 후에 해당 UE ID를 가진 단말에 제공할 SO-SNPN의 credential을 찾는 데 사용할 수 있다. PS는 UE의 인증서를 검증할 CA 인증서와 PS 자신의 인증서를 가지고 있을 수 있다. PS는 단말 제조사로부터 DCS와 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
도 4a 내지 도 4e를 참조하면, 401-B1, 401-B2, 401-B3 단계에서 제 1 사전 설정(401-B1), 제 2 사전 설정(401-B2), 그리고 제 3 사전 설정(401-B3)이 수행될 수 있다. 제 1 사전 설정, 제 2 사전 설정, 제 3 사전 설정은 동시에 수행되거나, 3 개의 사전 설정이 동시에 수행되지 않고 순차적으로 수행될 수 있다. 순차적으로 수행되는 경우 그 순서는 정해져 있는 것은 아닐 수 있다.
제 1 사전 설정 및/또는 제 2 사전 설정은 UE가 UE의 가입 정보가 없는 ON-SNPN에 접속할 때, UE를 인증할 수 있는 DCS의 도움을 받아 성공적으로 인증하기 위해 필요한 과정(UE와 DCS가 credential을 미리 프로비전 받는 과정)과, 후에 UE가 PS로부터 성공적으로 SO-SNPN의 credential을 제공받기 위해 필요한 과정(DCS에 PS 주소를 저장하는 과정 및 PS의 인증서를 검증할 수 있는 CA 인증서를 저장하는 과정)을 포함할 수 있다. 제 1 사전 설정 및/또는 제 3 사전 설정은 UE와 PS가 임시 공유 키를 생성하기 위해 정보를 보낼 때 사인에 필요한 인증서를 설정해 놓는 과정(UE와 PS에 각각 UE의 인증서/CA 인증서, PS 인증서/CA 인증서 설정)을 포함할 수 있다. 제 2 사전 설정을 통해 DCS는 PS, ON-SNPN, 또는 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 그렇지 않은 경우 등록 과정을 통해서 제공받을 수 있다. 제 3 사전 설정을 통해 PS는 단말 제조사로부터 DCS 혹은 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 또는 이후의 다른 엔티티로부터 제공받을 수도 있다.
402 단계에서 NG-RAN은 브로드캐스트 시스템 정보를 브로드캐스팅 할 수 있다. 브로드캐스트 시스템 정보는 UE에 의해 수신될 수 있다. 브로드캐스트 시스템 정보는 하나 이상의 PLMN 식별자(ID), PLMN ID당 네트워크 IDs의 리스트, 온보딩 가능 인디케이션(onboarding enabled indication)을 포함할 수 있다. PLMN ID와 Network ID의 조합은 NPN을 나타낼 수 있다. NG-RAN은 UE에 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 제공할 수도 있다.
403 단계에서 UE는 NG-RAN으로부터 수신한 브로드캐스팅 시스템 정보를 기반으로 ON-SNPN을 선택하고, AMF/SEAF로 등록 요청(Registration Request) 메시지를 송신할 수 있다. 예를 들어, 등록 요청 메시지의 송신은 UE에서 파워 온(power-on) 이벤트가 발생하거나 사용자의 입력이 있는 경우 트리거될 수 있다. 등록 요청 메시지는 등록 타입(registration type) 및 Onboarding SUCI를 포함할 수 있다. 등록 타입은 UE가 해당 NPN에 대한 가입 정보가 없다는 것을 나타내는"SNPN Onboarding"을 포함할 수 있다. 예를 들어, Onboarding SUCI는 "username@realm"와 같은 형식을 가질 수 있다. 여기서 realm 부분은 DCS를 나타낼 수 있다. UE는 등록 요청 메시지에 UE가 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 함께 보낼 수도 있다.
404 단계에서 AMF/SEAF는 UE로부터 등록 요청 메시지를 수신하고, 수신된 등록 요청 메시지에 포함된 Onboarding SUCI를 확인할 수 있다. 그리고 AMF/SEAF는 onboarding SUCI의 realm 부분을 기반으로 DCS를 식별하고, 식별된 DCS와 통신할 수 있는 AUSF로 인증 요청(Authentication Request) 메시지를 송신할 수 있다. 해당 메시지에는 403 단계에서 수신한 UE가 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 포함할 수도 있다.
405 단계에서 AUSF는 AMF/SEAF로부터 수신된 인증 요청 메시지를 기반으로 DCS로 인증 요청 메시지를 송신할 수 있다. DCS로 전송되는 인증 요청 메시지는 AUSF가 404 단계에서 AMF/SEAF로부터 수신한 인증 요청 메시지에 포함된 정보를 포함할 수 있다. 추가로 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 포함할 수도 있다. DCS가 AAA 서버인 경우, AUSF는 프로토콜 변환을 위해 NSSAAF를 통해 DCS에 인증 요청 메시지를 송신할 수 있다. ON-SNPN과 DCS는 계약 관계가 있을 수도 있다. 또한 DCS가 ON-SNPN의 도메인 밖에 존재할 경우에 ON-SNPN과 DCS 간의 메시지 교환은 NEF를 통해 수행될 수도 있다. 혹은 인증 과정에서의 DCS의 기능적 역할을 AUSF가 대신할 수도 있다.
406 단계에서 UE와 DCS는 EAP 인증(예를 들어 EAP-TLS)을 수행할 수 있다.
407 단계에서 DCS는 406 단계의 결과를 기반으로 PS에 알림(Notification)을 송신할 수 있다. 해당 알림에는 UE ID를 포함하고, 405 단계에서 받았거나 제 2 사전 설정에 의해 제공된 지시자들을 포함할 수도 있다. 예를 들어, 해당 알림에는 UE ID와 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자, 단말이 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자, 또는 DCS가 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자 중 적어도 하나의 지시자를 포함할 수 있다.
408 단계에서 PS는 407 단계에서 받은 지시자들 혹은 제 3 사전 설정에 의해 제공된 지시자들이 UE/ON-SNPN/DCS 모두 제어 평면을 지원한다는 것을 나타내고, PS도 제어 평면을 이용한 프로비저닝을 선호할 경우, PS는 제어 평면을 이용하여 SO-SNPN의 credential을 UE에 제공하기를 결정할 수 있다. 해당 단계에서 PS가 407 단계에서 받은 지시자들 혹은 제 3 사전 설정에 의해 설정된 지시자들, PS의 제어 평면을 이용한 프로비저닝 지원 여부를 기반으로, UE/ON-SNPN/DCS/PS 중 적어도 하나의 엔티티가 제어 평면을 이용한 프로비저닝을 지원하지 않는다면 도 3의 310 내지 318 단계가 수행될 수 있다.
409 단계에서 PS는 제어 평면을 이용한 프로비저닝이 수행될 것이라는 지시자와 PS가 생성한 nonce 값 (e.g., nonce.PS)을 DCS로 보낼 수 있다. PS가 생성한 nonce 값은 이후 단계에서 UE가 수신하여 UE의 개인키로 서명하여 다시 PS로 전달될 수 있으며, 이를 통해 재전송 공격을 방지할 수 있다.
410 단계에서 DCS는 EAP 응답(response) 메시지를 AUSF로 송신할 수 있다. EAP 응답 메시지는 인증 성공(EAP Success) 메시지와 UE를 나타내는 Onboarding SUPI, ON-SNPN에서 UE와의 통신에 사용될 키(key)를 생성하기 위한 키 재료(keying material), 409 단계에서 수신한 정보들(e.g., 제어 평면을 이용한 프로비저닝이 수행될 것이라는 지시자, PS가 생성한 nonce 값), 또는 제어 평면을 이용한 프로비저닝이 수행될 것이라는 지시자를 수신하였다면 401-B2에서 설정된 PS의 인증서를 검증할 수 있는 CA 인증서 중 적어도 하나를 포함할 수 있다.
411 단계에서 AUSF는 410 단계에서 수신한 EAP 응답 메시지 내의 키 재료를 기반으로 K_ausf를 생성할 수 있다.
412 단계에서 AUSF는 EAP 응답 메시지를 AMF/SEAF로 송신할 수 있다. AMF/SEAF로 전송되는 EAP 응답 메시지는 인증 성공 메시지(EAP success), K_ausf로부터 생성된 K_seaf, Onboarding SUPI, 제어 평면을 이용한 프로비저닝이 수행된다는 지시자, PS가 생성한 nonce 값, 또는 PS의 인증서를 검증할 수 있는 CA 인증서 중 적어도 하나를 포함할 수 있다.
413 단계에서 AMF/SEAF는 EAP 응답 메시지를 UE로 송신할 수 있다. UE로 전송되는 EAP 응답 메시지는 인증 성공 메시지(EAP success), 키를 나타내는 ngKSI(5G key set identifier), ABBA 파라미터, 제어 평면을 이용한 프로비저닝이 수행된다는 지시자, PS가 생성한 nonce 값, 또는 PS의 인증서를 검증할 수 있는 CA 인증서 중 적어도 하나를 포함할 수 있다.
414 단계에서 UE는 411 단계에서 AUSF가 K_ausf를 생성한 방식에 대응되는 방식을 사용하여 K_ausf를 생성할 수 있다. 또한 UE는 413 단계에서 받은 제어 평면을 이용한 프로비저닝이 수행된다는 지시자를 기반으로, 임시 키 쌍(ephemeral key pair)을 생성할 수 있다. 임시 키 쌍은 임시 공유 키(ePK.UE: ephemeral public key of UE)와 임시 개인 키(eSK.UE: ephemeral private key of UE)로 구성될 수 있다. UE는 eSK.UE는 저장해두고, ePK.UE는 UE의 인증서에 대응되는 개인 키로 서명을 하고, PS가 생성한 nonce 값도 UE의 개인 키로 서명을 할 수 있다.
415 단계에서 AMF/SEAF는 UE와의 알고리즘 협상을 위해 NAS Security Mode Command 메시지를 송신할 수 있다.
416 단계에서 UE는 NAS Security Mode Complete 메시지를 송신할 수 있다. 해당 메시지에는 ePK.UE와 이를 UE의 개인 키로 서명한 값, PS가 생성한 nonce 값을 UE의 개인 키로 서명한 값, UE의 인증서, 및/또는 UE가 생성한 nonce값 (e.g., nonce.UE)을 포함할 수 있다. 일례로, UE가 생성한 임시 공유 키(ePK.UE)가 nonce.UE로 사용될 수도 있다.
417 단계에서 AMF/SEAF는 UE가 ON-SNPN에 성공적으로 온보딩 과정을 마쳤다는 것을 알 수 있고, 이를 알릴 준비를 할 수 있다.
418 단계에서 AMF/SEAF는 인증 통지 메시지를 AUSF로 송신할 수 있다. 인증 통지 메시지는 UE가 온보딩 과정을 성공적으로 끝마쳤음을 지시하는 정보, UE의 ID, 416 단계에서 수신한 ePK.UE와 이를 UE의 개인 키로 서명한 값, PS가 생성한 nonce 값을 UE의 개인 키로 서명한 값, UE의 인증서, 및/또는 UE가 생성한 nonce 값을 포함할 수 있다.
419 단계에서 AUSF는 DCS로 인증 통지 메시지를 송신할 수 있다. DCS로 전송되는 인증 통지 메시지는 UE ID, UPU (UE Parameters Update) 과정에 사용될 UDM의 주소, ePK.UE와 이를 UE의 개인 키로 서명한 값, PS가 생성한 nonce 값을 UE의 개인 키로 서명한 값, UE의 인증서, 및/또는 UE가 생성한 nonce 값을 포함할 수 있다.
420 단계에서 DCS는 419 단계에서 받은 UE ID를 매칭시켜 제 2 사전 설정에 의해 제공된 PS의 주소를 찾을 수 있다. 또한, 해당 정보를 저장할 수도 있다.
421 단계에서 DCS는 인증 통지 메시지를 PS에 송신할 수 있다. PS로 전송되는 인증 통지 메시지는 UE의 ID, ePK.UE와 이를 UE의 개인 키로 서명한 값, PS가 생성한 nonce 값을 UE의 개인 키로 서명한 값, UE의 인증서, 및/또는 UE가 생성한 nonce 값을 포함할 수 있다.
422 단계에서 PS는 421 단계에서 수신한 UE의 ID와 제 3 사전 설정에 의해 제공된 UE ID를 매칭시켜 해당 UE에 제공될 SO-SNPN의 credential을 찾을 수 있다. PS는 제 3 사전 설정에 의해 제공된 CA의 인증서를 이용하여 421 단계에서 수신한 UE의 인증서를 검증할 수 있다. PS는 UE 인증서에 있는 UE의 공개 키를 이용하여 서명된 ePK.UE 값, 서명된 PS가 생성한 nonce 값을 검증할 수 있다. 검증이 완료되면 PS는 자신의 임시 키 쌍(ePK.PS, eSK.PS)를 생성하고, ePK.UE와 eSK.PS로 임시 공유 키들(ephemeral session keys)을 생성할 수 있다. 임시 공유 키들은 암호화에 사용될 키(ephemeral encryption key)와 무결성 보호에 사용될 키(ephemeral MAC key)로 구성될 수 있다. PS는 해당 UE에 전달할 SO-SNPN의 credential을 임시 암호화 키로 암호화 하고(Cipher-text value), 이 값(Cipher-text value)을 MAC 키로 해쉬한 값(MAC-tag value)을 계산할 수 있다. 암호화 및 무결성 보호된 SO-SNPN의 credential은 Cipher-text 값과 MAC-tag 값으로 이루어질 수 있다. PS는 자신이 생성한 공개 키(ePK.PS)를 PS의 인증서에 대응되는 개인 키로 서명하고, UE가 생성한 nonce 값도 PS의 개인 키로 서명할 수 있다.
423 단계에서 PS는 DCS에 프로비저닝 요청 메시지를 송신할 수 있다. 해당 메시지는 UE ID, ePK.PS와 이를 PS의 개인 키로 서명한 값, UE가 생성한 nonce를 서명한 값, PS의 인증서, 및/또는 암호화 및 무결성 보호된 SO-SNPN의 credential을 포함할 수 있다.
424 단계에서 DCS는 UDM에 프로비저닝 요청 메시지를 전달할 준비를 할 수도 있다. 혹은 후술되는 UDM의 기능적 역할을 DCS 혹은 PS가 대신할 수도 있다.
425 단계에서 DCS는 UDM에 프로비저닝 요청 메시지를 송신할 수 있다. 해당 메시지는 423 단계에서 PS로부터 받은 정보(e.g., UE ID, ePK.PS와 이를 PS의 개인 키로 서명한 값, UE가 생성한 nonce를 서명한 값, PS의 인증서, 및/또는 암호화 및 무결성 보호된 SO-SNPN의 credential)를 포함할 수 있다.
426 단계에서 UDM은 UPU 과정을 수행하기 위해 Nausf_UPUProtection 서비스를 요청할 수 있다. 해당 메시지는 Onboarding SUPI와 암호화 및 무결성 보호된 SO-SNPN의 credential을 포함할 수 있다.
427 단계에서 암호화 및 무결성 보호된 SO-SNPN의 credential은 AUSF에 의해 K_ausf를 이용하여 무결성 보호가 될 수 있다.
428 단계에서 AUSF는 Nausf_UPUProtection Response를 통해 427 단계에서 계산한 UPU-MAC-I_ausf 값과 Counter_upu 값을 UDM에 전달할 수 있다. Counter_upu는 0x00 0x00에서 시작하여 UPU-MAC-I_ausf를 계산할 때마다 증가하는 값으로서, 재전송 공격을 방지할 수 있다.
429 단계에서 UDM은 Nudm_SDM_Notification 서비스를 통해 UPU Data, 427 단계에서 AUSF가 계산한 UPU-MAC-I_ausf, Counter_upu 값, 425 단계에서 수신한 ePK.PS와 PS의 개인 키로 서명된 값, UE가 생성한 nonce 값을 PS의 개인 키로 서명한 값, 및/또는 PS의 인증서를 AMF/SEAF로 송신할 수 있다.
430 단계에서 AMF/SEAF는 UE에 DL NAS Transport 메시지를 송신할 수 있다. DL NAS Transport 메시지는 UPU 데이터, UPU-MAC-I_ausf, Counter_upu, 429 단계에서 수신한 ePK.PS와 PS의 개인 키로 서명된 값, UE가 생성한 nonce 값을 PS의 개인 키로 서명한 값, 및/또는 PS의 인증서를 포함할 수 있다.
431 단계에서 UE는 K_ausf를 사용하여 UPU-MAC-I_ausf를 검증할 수 있다. UE는 제 1 사전 설정에 의해 제공된 CA 인증서를 이용하여 PS의 인증서를 검증할 수 있다. PS의 인증서에 있는 공개 키를 사용하여 PS가 서명한 값들(ePK.PS를 PS의 개인키로 서명한 값, UE가 생성한 nonce 값을 PS의 개인 키로 서명한 값)을 검증할 수 있다. 검증이 완료된 후 UE는 eSK.UE와 ePK.PS를 이용하여 임시 공유 키들(ephemeral session keys)을 생성할 수 있다. 임시 공유 키들은 암호화에 사용될 키(ephemeral encryption key)와 무결성 보호에 사용될 키(ephemeral MAC key)로 구성되어 있다. 이 키들은 422 단계에서 PS가 생성한 키들과 같을 수 있다. UE는 ephemeral MAC key를 이용해 MAC-tag 값을 검증하고, ephemeral encryption key를 이용하여 Cipher-text 값으로부터 SO-SNPN의 credential을 구할 수 있다.
도 5a 내지 도 5e는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤, PS로부터 SO-SNPN의 credential을 안전하게 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 5a 내지 도 5e 의 시그널링 순서는 경우에 따라 변경될 수도 있다. 또한, 도 5a 내지 도 5e 의 각 단계들 중 일부는 경우에 따라 생략될 수도 있으며, 둘 이상의 단계가 결합되어 하나의 단계로 수행될 수도 있다.
도 5a 내지 도 5e에 도시된 절차를 위해 다음의 설정 중 하나 이상이 사전에 수행될 수 있다.
501-C1: 제 1 사전 설정
UE 제조사는 UE를 제조할 때 DCS와의 상호 인증에 사용될 credential을 UE에 프로비저닝 할 수 있다. UE는 PS의 인증서를 검증할 CA 인증서와 UE 자신의 인증서를 가지고 있을 수 있다.
501-C2: 제 2 사전 설정
UE 제조사는 온보딩(onboarding)의 목적을 위해 ON-SNPN에 접속하는 UE와의 상호 인증에 사용될 credential을 DCS에 프로비저닝 할 수 있다. UE가 SO-SNPN 소유자에 팔리고 난 후, UE 제조사는 SO-SNPN의 credential을 UE에 프로비저닝 할 수 있는 PS의 주소 또는 PS의 인증서를 검증할 수 있는 CA 인증서 중 적어도 하나를 DCS에 프로비저닝 할 수 있다. PS의 주소는 제어 평면을 이용한 프로비저닝이 수행될 경우, DCS가 PS에 프로비저닝을 트리거링(triggering)하기 위해 PS를 찾을 때 사용될 수 있다. DCS는 PS가 제어 평면을 이용한 프로비저닝을 선호한다는 정보를 가지고 있을 수 있다. 추가로 DCS는 ON-SNPN, UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
501-C3: 제 3 사전 설정
UE 제조사는 SO-SNPN 소유자에 팔린 UE의 ID(예를 들어 Onboarding SUPI, IMEI 등)를 PS에 제공할 수 있다. PS는 UE ID를 저장해두었다가 후에 해당 UE ID를 가진 단말에 제공할 SO-SNPN의 credential을 찾는 데 사용할 수 있다. PS는 UE의 인증서를 검증할 CA 인증서와 PS 자신의 인증서를 가지고 있을 수 있다. PS는 단말 제조사로부터 DCS와 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
도 5a 내지 도 5e를 참조하면, 501-C1, 501-C2, 501-C3 단계에서 제 1 사전 설정(501-C1), 제 2 사전 설정(501-C2), 그리고 제 3 사전 설정(501-C3)이 수행될 수 있다. 제 1 사전 설정, 제 2 사전 설정, 제 3 사전 설정은 동시에 수행되거나, 3 개의 사전 설정이 동시에 수행되지 않고 순차적으로 수행될 수 있다. 순차적으로 수행되는 경우 그 순서는 정해져 있는 것은 아닐 수 있다.
제 1 사전 설정 및/또는 제 2 사전 설정은 UE가 UE의 가입 정보가 없는 ON-SNPN에 접속할 때, UE를 인증할 수 있는 DCS의 도움을 받아 성공적으로 인증하기 위해 필요한 과정(UE와 DCS가 credential을 미리 프로비전 받는 과정)과, 후에 UE가 PS로부터 성공적으로 SO-SNPN의 credential을 제공받기 위해 필요한 과정(DCS에 PS 주소를 저장하는 과정 및 PS의 인증서를 검증할 수 있는 CA 인증서를 저장하는 과정)을 포함할 수 있다. 제 1 사전 설정 및/또는 제 3 사전 설정은 UE와 PS가 임시 공유 키를 생성하기 위해 정보를 보낼 때 사인에 필요한 인증서를 설정해 놓는 과정(UE와 PS에 각각 UE의 인증서/CA 인증서, PS 인증서/CA 인증서 설정)을 포함할 수 있다. 제 2 사전 설정을 통해 DCS는 PS, ON-SNPN, 또는 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 그렇지 않은 경우 등록 과정을 통해서 제공받을 수 있다. 제 3 사전 설정을 통해 PS는 단말 제조사로부터 DCS 혹은 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 또는 이후의 다른 엔티티로부터 제공받을 수도 있다.
502 단계에서 NG-RAN은 브로드캐스트 시스템 정보를 브로드캐스팅 할 수 있다. 브로드캐스트 시스템 정보는 UE에 의해 수신될 수 있다. 브로드캐스트 시스템 정보는 하나 이상의 PLMN 식별자(ID), PLMN ID당 네트워크 IDs의 리스트, 온보딩 가능 인디케이션(onboarding enabled indication)을 포함할 수 있다. PLMN ID와 Network ID의 조합은 NPN을 나타낼 수 있다. NG-RAN은 UE에 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 제공할 수도 있다.
503 단계에서 UE는 NG-RAN으로부터 수신한 브로드캐스팅 시스템 정보를 기반으로 ON-SNPN을 선택하고, AMF/SEAF로 등록 요청(Registration Request) 메시지를 송신할 수 있다. 예를 들어, 등록 요청 메시지의 송신은 UE에서 파워 온(power-on) 이벤트가 발생하거나 사용자의 입력이 있는 경우 트리거될 수 있다. 등록 요청 메시지는 등록 타입(registration type) 및 Onboarding SUCI를 포함할 수 있다. 등록 타입은 UE가 해당 NPN에 대한 가입 정보가 없다는 것을 나타내는"SNPN Onboarding"을 포함할 수 있다. 예를 들어, Onboarding SUCI는 "username@realm"와 같은 형식을 가질 수 있다. 여기서 realm 부분은 DCS를 나타낼 수 있다. UE는 등록 요청 메시지에 UE가 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 함께 보낼 수도 있다.
504 단계에서 AMF/SEAF는 UE로부터 등록 요청 메시지를 수신하고, 수신된 등록 요청 메시지에 포함된 Onboarding SUCI를 확인할 수 있다. 그리고 AMF/SEAF는 onboarding SUCI의 realm 부분을 기반으로 DCS를 식별하고, 식별된 DCS와 통신할 수 있는 AUSF로 인증 요청(Authentication Request) 메시지를 송신할 수 있다. 해당 메시지에는 503 단계에서 수신한 onboarding SUCI, 및/또는 UE가 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 포함할 수도 있다.
505 단계에서 AUSF는 인증 요청 메시지를 기반으로 DCS로 인증 요청 메시지를 송신할 수 있다. 인증 요청 메시지는 AUSF가 504 단계에서 AMF로부터 수신한 인증 요청 메시지에 포함된 정보를 포함할 수 있다. 추가로 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 포함할 수도 있다. DCS가 AAA 서버인 경우, AUSF는 프로토콜 변환을 위해 NSSAAF를 통해 DCS에 인증 요청 메시지를 송신할 수 있다. ON-SNPN과 DCS는 계약 관계가 있을 수도 있다. 또한 DCS가 ON-SNPN의 도메인 밖에 존재할 경우에 ON-SNPN과 DCS 간의 메시지 교환은 NEF를 통해 수행될 수도 있다. 혹은 인증 과정에서의 DCS의 기능적 역할을 AUSF가 대신할 수도 있다.
506 단계에서 UE와 DCS는 EAP 인증(예를 들어 EAP-TLS)을 수행할 수 있다.
507 단계에서 DCS는 505 단계에서 받았거나 제 2 사전 설정에 의해 제공된 지시자들을 기반으로, UE/ON-SNPN/DCS/PS 모두 제어 평면을 이용한 프로비저닝을 지원한다는 것을 알았다면 제어 평면을 이용한 프로비저닝 단계를 준비할 수 있다. 만약 UE/ON-SNPN/DCS/PS 중 적어도 하나 이상의 엔티티가 제어 평면을 이용한 프로비저닝을 지원하지 않는다면 도 3의 311 내지 318 단계가 수행될 수 있다.
508 단계에서 DCS는 제어 평면을 이용한 프로비저닝이 사용될 것이라는 통지를 PS에 전달할 수 있다. 상기 통지는 UE ID 및/또는 제어 평면을 이용한 프로비저닝이 사용됨을 나타내는 지시자를 포함할 수 있다. 이를 만약 PS가 받았다면 해당 UE에 전달될 SO-SNPN의 credential을 미리 준비할 수도 있다.
509 단계에서 DCS는 EAP 응답(response) 메시지를 AUSF로 송신할 수 있다. EAP 응답 메시지는 인증 성공(EAP Success) 메시지와 UE를 나타내는 Onboarding SUPI, ON-SNPN에서 UE와의 통신에 사용될 키(key)를 생성하기 위한 키 재료(keying material), 제어 평면을 이용한 프로비저닝이 수행될 것임을 나타내는 지시자, 또는 제어 평면을 이용한 프로비저닝이 수행될 것이라는 지시자를 수신하였다면 501-C2에서 설정된 PS의 인증서를 검증할 수 있는 CA 인증서 중 적어도 하나를 포함할 수 있다.
510 단계에서 AUSF는 509 단계에서 수신한 EAP 응답 메시지 내의 키 재료를 기반으로 K_ausf를 생성할 수 있다.
511 단계에서 AUSF는 EAP 응답 메시지를 AMF/SEAF로 송신할 수 있다. AMF/SEAF로 전송되는 EAP 응답 메시지는 인증 성공 메시지, K_ausf로부터 생성한 K_seaf, Onboarding SUPI, 제어 평면을 이용한 프로비저닝이 수행된다는 지시자, 또는 PS의 인증서를 검증할 수 있는 CA 인증서 중 적어도 하나를 포함할 수 있다.
512 단계에서 AMF/SEAF는 EAP 응답 메시지를 UE로 송신할 수 있다. UE로 전송되는 EAP 응답 메시지는 인증 성공 메시지, 키를 나타내는 ngKSI(5G key set identifier), ABBA 파라미터, 제어 평면을 이용한 프로비저닝이 수행된다는 지시자, 또는 PS의 인증서를 검증할 수 있는 CA 인증서 중 적어도 하나를 포함할 수 있다.
513 단계에서 UE는 510 단계에서 AUSF가 K_ausf를 생성한 방식에 대응되는 방식을 사용하여 K_ausf를 생성할 수 있다. 또한 UE는 512 단계에서 받은 제어 평면을 이용한 프로비저닝이 수행된다는 지시자를 기반으로, 임시 키 쌍(ephemeral key pair)을 생성할 수 있다. 임시 키 쌍은 임시 공유 키(ePK.UE: ephemeral public key of UE)와 임시 개인 키(eSK.UE: ephemeral private key of UE)로 구성될 수 있다. UE는 eSK.UE는 저장해두고, ePK.UE는 UE의 인증서에 대응되는 개인 키로 서명을 하고, time stamp를 생성하여 개인 키로 서명을 할 수 있다.
514 단계에서 AMF/SEAF는 알고리즘 협상을 위해 NAS Security Mode Command 메시지를 송신할 수 있다.
515 단계에서 UE는 NAS Security Mode Complete 메시지를 송신할 수 있다. 해당 메시지에는 ePK.UE와 이를 UE의 개인 키로 서명한 값, UE가 생성한 time stamp, time stamp를 UE의 개인 키로 서명한 값, 및/또는 UE의 인증서를 보낼 수 있다. UE가 생성한 time stamp는 후술되는 단계에서 PS가 수신하였을 때, PS가 허용하는 시간 범위를 넘어선 time stamp가 왔을 경우엔 PS가 이를 용인하지 않을 수 있다. 이는 재전송 공격을 방지할 수 있다. UE가 PS의 인증을 위해 UE가 생성한 nonce 값을 보낼 수도 있다.
516 단계에서 AMF/SEAF는 UE가 ON-SNPN에 성공적으로 온보딩 과정을 마쳤다는 것을 알 수 있고, 이를 알릴 준비를 할 수 있다.
517 단계에서 AMF/SEAF는 인증 통지 메시지를 AUSF로 송신할 수 있다. 인증 통지 메시지는 UE가 온보딩 과정을 성공적으로 끝마쳤음을 지시하는 정보, UE의 ID, 515 단계에서 수신한 ePK.UE와 이를 UE의 개인 키로 서명한 값, UE가 생성한 time stamp와 이를 UE의 개인 키로 서명한 값, 및/또는 UE의 인증서를 포함할 수 있다. 515 단계에서 인증 통지 메시지는 UE가 생성한 nonce 값이 있다면 이를 포함할 수도 있다.
518 단계에서 AUSF는 DCS로 인증 통지 메시지를 송신할 수 있다. DCS로 전송되는 인증 통지 메시지는 UE ID, UPU 과정에 사용될 UDM의 주소, ePK.UE와 이를 UE의 개인 키로 서명한 값, UE가 생성한 time stamp와 이를 UE의 개인 키로 서명한 값, UE의 인증서, 그리고 517 단계에서 UE가 생성한 nonce 값을 수신하였다면 이를 포함할 수 있다.
519 단계에서 DCS는 518 단계에서 받은 UE ID를 매칭시켜 제 2 사전 설정에 의해 제공된 PS의 주소를 찾을 수 있다.
520 단계에서 DCS는 인증 통지 메시지를 PS에 송신할 수 있다. PS로 전송되는 인증 통지 메시지는 UE의 ID, ePK.UE와 이를 UE의 개인 키로 서명한 값, UE가 생성한 time stamp와 이를 UE의 개인 키로 서명한 값, UE의 인증서, 그리고 518 단계에서 UE가 생성한 nonce 값을 수신하였다면 이를 포함할 수 있다. 그리고 508 단계가 수행되지 않았다면 제어 평면을 이용한 프로비저닝이 사용될 것이라는 지시자를 포함할 수 있다.
521 단계에서 PS는 520 단계에서 수신한 UE의 ID와 제 3 사전 설정에 의해 제공된 UE ID를 매칭시켜 해당 UE에 제공될 SO-SNPN의 credential을 찾을 수 있다. PS는 제 3 사전 설정에 의해 제공된 CA의 인증서를 이용하여 520 단계에서 수신한 UE의 인증서를 검증할 수 있다. PS는 UE 인증서에 있는 UE의 공개 키를 이용하여 서명된 ePK.UE 값, 서명된 UE의 time stamp 값을 검증할 수 있다. 검증이 완료되면 PS는 자신의 임시 키 쌍(ePK.PS, eSK.PS)를 생성하고, ePK.UE와 eSK.PS로 임시 공유 키들(ephemeral session keys) 을 생성할 수 있다. 임시 공유 키들은 암호화에 사용될 키(ephemeral encryption key)와 무결성 보호에 사용될 키(ephemeral MAC key)로 구성될 수 있다. PS는 해당 UE에 전달할 SO-SNPN의 credential을 임시 암호화 키로 암호화 하고(Cipher-text value), 이 값(Cipher-text value)을 MAC 키로 해쉬한 값(MAC-tag value)을 계산할 수 있다. 암호화 및 무결성 보호된 SO-SNPN의 credential은 Cipher-text 값과 MAC-tag 값으로 이루어질 수 있다. PS는 자신이 생성한 공개 키(ePK.PS)를 PS의 인증서에 대응되는 개인 키로 서명할 수 있다. 520 단계에서 만약 UE가 생성한 nonce 값을 수신하였다면 UE가 생성한 nonce 값도 개인 키로 서명하고, UE가 생성한 nonce 값을 수신하지 않았다면 PS가 생성한 time stamp와 이를 PS의 개인 키로 서명할 수 있다.
522 단계에서 PS는 DCS에 프로비저닝 요청 메시지를 송신할 수 있다. 해당 메시지는 UE ID, ePK.PS와 이를 PS의 개인 키로 서명한 값, UE가 생성한 nonce를 서명한 값 또는 PS가 생성한 time stamp와 이를 서명한 값, PS의 인증서, 및/또는 암호화 및 무결성 보호된 SO-SNPN의 credential을 포함할 수 있다.
523 단계에서 DCS는 UDM에 프로비저닝 요청 메시지를 전달할 준비를 할 수도 있다. 혹은 후술되는 UDM의 기능적 역할을 DCS 혹은 PS가 대신할 수도 있다.
524 단계에서 DCS는 UDM에 프로비저닝 요청 메시지를 송신할 수 있다. 해당 메시지는 522 단계에서 PS로부터 받은 정보(e.g., UE ID, ePK.PS와 이를 PS의 개인 키로 서명한 값, UE가 생성한 nonce를 서명한 값 또는 PS가 생성한 time stamp와 이를 서명한 값, PS의 인증서, 암호화 및 무결성 보호된 SO-SNPN의 credential)를 포함할 수 있다.
525 단계에서 UDM은 UPU 과정을 수행하기 위해 Nausf_UPUProtection 서비스를 요청할 수 있다. 해당 메시지는 Onboarding SUPI와 암호화 및 무결성 보호된 SO-SNPN의 credential을 포함할 수 있다.
526 단계에서 암호화 및 무결성 보호된 SO-SNPN의 credential은 AUSF에 의해 K_ausf를 이용하여 무결성 보호가 될 수 있다.
527 단계에서 AUSF는 Nausf_UPUProtection Response를 통해 526 단계에서 계산한 UPU-MAC-I_ausf 값과 Counter_upu 값을 UDM에 전달할 수 있다. Counter_upu는 0x00 0x00에서 시작하여 UPU-MAC-I_ausf를 계산할 때마다 증가하는 값으로서, 재전송 공격을 방지할 수 있다.
528 단계에서 UDM은 Nudm_SDM_Notification 서비스를 통해 UPU Data, 526 단계에서 AUSF가 계산한 UPU-MAC-I_ausf, Counter_upu 값, 524 단계에서 수신한 ePK.PS와 PS의 개인 키로 서명된 값, UE가 생성한 nonce 값을 PS의 개인 키로 서명한 값 또는 PS가 생성한 time stamp와 이를 PS의 개인 키로 서명한 값, 및/또는 PS의 인증서를 AMF/SEAF로 송신할 수 있다.
529 단계에서 AMF/SEAF는 UE에 DL NAS Transport를 송신할 수 있다. DL NAS Transport 메시지는 UPU 데이터, UPU-MAC-I_ausf, 및 Counter_upu, 528 단계에서 수신한 ePK.PS와 PS의 개인 키로 서명된 값, UE가 생성한 nonce 값을 PS의 개인 키로 서명한 값 또는 PS가 생성한 time stamp와 이를 PS의 개인 키로 서명한 값, 및/또는 PS의 인증서를 포함할 수 있다.
530 단계에서 UE는 K_ausf를 사용하여 UPU-MAC-I_ausf를 검증할 수 있다. UE는 제 1 사전 설정에 의해 제공된 CA 인증서를 이용하여 PS의 인증서를 검증할 수 있다. PS의 인증서에 있는 공개 키를 사용하여 PS가 서명한 값들(ePK.PS를 PS의 개인키로 서명한 값, UE가 생성한 nonce 값을 PS의 개인 키로 서명한 값 또는 PS가 생성한 time stamp를 서명한 값)을 검증할 수 있다. 검증이 완료된 후 UE는 eSK.UE와 ePK.PS를 이용하여 임시 공유 키들(ephemeral session keys)을 생성할 수 있다. 임시 공유 키들은 암호화에 사용될 키(ephemeral encryption key)와 무결성 보호에 사용될 키(ephemeral MAC key)로 구성되어 있다. 이 키들은 521 단계에서 PS가 생성한 키들과 같을 수 있다. UE는 ephemeral MAC key를 이용해 MAC-tag 값을 인증하고, ephemeral encryption key를 이용하여 Cipher-text 값으로부터 SO-SNPN의 credential을 구할 수 있다.
도 6a 내지 도 6e는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 PS로부터 SO-SNPN의 credential을 안전하게 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 6a 내지 도 6e의 시그널링 순서는 경우에 따라 변경될 수도 있다. 또한, 도 6a 내지 도 6e의 각 단계들 중 일부는 경우에 따라 생략될 수도 있으며, 둘 이상의 단계가 결합되어 하나의 단계로 수행될 수도 있다.
도 6a 내지 도 6e에 도시된 절차를 위해 다음의 설정 중 하나 이상이 사전에 수행될 수 있다.
601-D1: 제 1 사전 설정
UE 제조사는 UE를 제조할 때 DCS와의 상호 인증에 사용될 credential을 UE에 프로비저닝 할 수 있다.
601-D2: 제 2 사전 설정
UE 제조사는 온보딩(onboarding)의 목적을 위해 ON-SNPN에 접속하는 UE와의 상호 인증에 사용될 credential을 DCS에 프로비저닝 할 수 있다. UE가 SO-SNPN 소유자에 팔리고 난 후, UE 제조사는 SO-SNPN의 credential을 UE에 프로비저닝 할 수 있는 PS의 주소를 DCS에 프로비저닝 할 수 있다. PS의 주소는 제어 평면을 이용한 프로비저닝이 수행될 경우, DCS가 PS에 프로비저닝을 트리거링(triggering)하기 위해 PS를 찾을 때 사용될 수 있다. DCS는 PS가 제어 평면을 이용한 프로비저닝을 선호한다는 정보를 가지고 있을 수 있다. 추가로 DCS는 ON-SNPN, UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
601-D3: 제 3 사전 설정
UE 제조사는 SO-SNPN 소유자에 팔린 UE의 ID(예를 들어 Onboarding SUPI, IMEI 등)를 PS에 제공할 수 있다. PS는 UE ID를 저장해두었다가 후에 해당 UE ID를 가진 단말에 제공할 SO-SNPN의 credential을 찾는 데 사용할 수 있다. PS는 단말 제조사로부터 DCS와 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
도 6a 내지 도 6e를 참조하면, 601-D1, 601-D2, 601-D3 단계에서 제 1 사전 설정(601-D1), 제 2 사전 설정(601-D2), 그리고 제 3 사전 설정(601-D3)이 수행될 수 있다. 제 1 사전 설정, 제 2 사전 설정, 제 3 사전 설정은 동시에 수행되거나, 3 개의 사전 설정이 동시에 수행되지 않고 순차적으로 수행될 수 있다. 순차적으로 수행되는 경우 그 순서는 정해져 있는 것은 아닐 수 있다.
제 1 사전 설정 및/또는 제 2 사전 설정은 UE가 UE의 가입 정보가 없는 ON-SNPN에 접속할 때, UE를 인증할 수 있는 DCS의 도움을 받아 성공적으로 인증하기 위해 필요한 과정(UE와 DCS가 credential을 미리 프로비전 받는 과정)과, 후에 UE가 PS로부터 성공적으로 SO-SNPN의 credential을 제공받기 위해 필요한 과정(DCS에 PS 주소를 저장하는 과정)을 포함할 수 있다. 제 2 사전 설정을 통해 DCS가 PS, ON-SNPN, 또는 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 그렇지 않은 경우 등록 과정을 통해서 제공받을 수 있다. 제 3 사전 설정을 통해 PS가 단말 제조사로부터 DCS 혹은 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고, 또는 이후의 다른 엔티티로부터 제공받을 수도 있다.
602 단계에서 NG-RAN은 브로드캐스트 시스템 정보를 브로드캐스팅 할 수 있다. 브로드캐스트 시스템 정보는 UE에 의해 수신될 수 있다. 브로드캐스트 시스템 정보는 하나 이상의 PLMN 식별자(ID), PLMN ID당 네트워크 ID, 온보딩 가능 인디케이션(onboarding enabled indication)을 포함할 수 있다. PLMN ID와 Network ID의 조합은 NPN을 나타낼 수 있다. NG-RAN은 UE에 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 제공할 수도 있다.
603 단계에서 UE는 NG-RAN으로부터 수신한 브로드캐스팅 시스템 정보를 기반으로 ON-SNPN을 선택하고, AMF/SEAF로 등록 요청(Registration Request) 메시지를 송신할 수 있다. 예를 들어, 등록 요청 메시지의 송신은 UE에서 파워 온(power-on) 이벤트가 발생하거나 사용자의 입력이 있는 경우 트리거될 수 있다. 등록 요청 메시지는 등록 타입(registration type) 및 Onboarding SUCI를 포함할 수 있다. 등록 타입은 UE가 해당 NPN에 대한 가입 정보가 없다는 것을 나타내는"SNPN Onboarding"을 포함할 수 있다. 예를 들어, Onboarding SUCI는 "username@realm"와 같은 형식을 가질 수 있다. 여기서 realm 부분은 DCS를 나타낼 수 있다. UE는 등록 요청 메시지에 UE가 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 함께 보낼 수도 있다.
604 단계에서 AMF/SEAF는 UE로부터 등록 요청 메시지를 수신하고, 수신된 등록 요청 메시지에 포함된 Onboarding SUCI를 확인할 수 있다. 그리고 AMF/SEAF는 onboarding SUCI의 realm 부분을 기반으로 DCS를 식별하고, 식별된 DCS와 통신할 수 있는 AUSF로 인증 요청(Authentication Request) 메시지를 송신할 수 있다. 해당 메시지에는 603 단계에서 수신한 UE가 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 포함할 수도 있다.
605 단계에서 AUSF는 인증 요청 메시지를 기반으로 DCS로 인증 요청 메시지를 송신할 수 있다. DCS로 전송되는 인증 요청 메시지는 AUSF가 604 단계에서 AMF로부터 수신한 인증 요청 메시지에 포함된 정보를 포함할 수 있다. 추가로 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 포함할 수도 있다. DCS가 AAA 서버인 경우, AUSF는 프로토콜 변환을 위해 NSSAAF를 통해 DCS에 인증 요청 메시지를 송신할 수 있다. ON-SNPN과 DCS는 계약 관계가 있을 수도 있다. 또한 DCS가 ON-SNPN의 도메인 밖에 존재할 경우에 ON-SNPN과 DCS 간의 메시지 교환은 NEF를 통해 수행될 수도 있다. 혹은 인증 과정에서의 DCS의 기능적 역할을 AUSF가 대신할 수도 있다.
606 단계에서 UE와 DCS는 EAP 인증(예를 들어 EAP-TLS)을 수행할 수 있다.
607 단계에서 DCS는 605 단계에서 받았거나 제 2 사전 설정에 의해 제공된 지시자들을 기반으로, UE/ON-SNPN/DCS/PS 모든 엔티티가 제어 평면을 이용한 프로비저닝을 지원한다는 것을 알았다면 제어 평면을 이용한 프로비저닝 단계를 준비할 수 있다. UE/ON-SNPN/DCS/PS 중 적어도 하나 이상의 엔티티가 제어 평면을 이용한 프로비저닝을 지원하지 않는다면, 도 3의 311 내지 318 단계가 수행될 수 있다.
608 단계에서 DCS는 제어 평면을 이용한 프로비저닝이 사용될 것이라는 통지를 PS에 전달할 수 있다. 상기 통지는 UE ID 및/또는 제어 평면을 이용한 프로비저닝이 사용될 것임을 나타내는 지시자를 포함할 수 있다. 이를 만약 PS가 받았다면 해당 UE에 전달될 SO-SNPN의 credential을 미리 준비할 수도 있다.
609 단계에서 DCS는 EAP 응답(response) 메시지를 AUSF로 송신할 수 있다. EAP 응답 메시지는 인증 성공(EAP Success) 메시지와 UE를 나타내는 Onboarding SUPI, ON-SNPN에서 UE와의 통신에 사용될 키(key)를 생성하기 위한 키 재료(keying material), 그리고 제어 평면을 이용한 프로비저닝이 수행될 것이라는 지시자를 포함할 수 있다.
610 단계에서 AUSF는 609 단계에서 수신한 EAP 응답 메시지 내의 키 재료를 기반으로 K_ausf를 생성할 수 있다.
611 단계에서 AUSF는 EAP 응답 메시지를 AMF/SEAF로 송신할 수 있다. AMF/SEAF로 송신된 EAP 응답 메시지는 인증 성공 메시지, K_ausf로부터 생성한 K_seaf, Onboarding SUPI, 및/또는 제어 평면을 이용한 프로비저닝이 수행된다는 지시자를 포함할 수 있다.
612 단계에서 AMF/SEAF는 EAP 응답 메시지를 UE로 송신할 수 있다. EAP 응답 메시지는 인증 성공 메시지, 키를 나타내는 ngKSI(5G key set identifier), ABBA 파라미터, 및 제어 평면을 이용한 프로비저닝이 수행된다는 지시자를 포함할 수 있다.
613 단계에서 UE는 610 단계에서 AUSF가 K_ausf를 생성한 방식에 대응되는 방식을 사용하여 K_ausf를 생성할 수 있다. 또한 UE는 612 단계에서 받은 제어 평면을 이용한 프로비저닝이 수행된다는 지시자를 기반으로, 임시 키 쌍(ephemeral key pair)을 생성할 수 있다. 임시 키 쌍은 임시 공유 키(ePK.UE: ephemeral public key of UE)와 임시 개인 키(eSK.UE: ephemeral private key of UE)로 구성될 수 있다. UE는 eSK.UE는 저장해두고, ePK.UE는 전달할 준비를 할 수 있다.
614 단계에서 AMF/SEAF는 알고리즘 협상을 위해 NAS Security Mode Command 메시지를 송신할 수 있다.
615 단계에서 UE는 NAS Security Mode Complete 메시지를 송신할 수 있다. 해당 메시지는 ePK.UE를 포함할 수 있다.
616 단계에서 AMF/SEAF는 UE가 ON-SNPN에 성공적으로 온보딩 과정을 마쳤다는 것을 알 수 있고, 이를 알릴 준비를 할 수 있다.
617 단계에서 AMF/SEAF는 인증 통지 메시지를 AUSF로 송신할 수 있다. 인증 통지 메시지는 UE가 온보딩 과정을 성공적으로 끝마쳤음을 지시하는 정보, UE의 ID, 및/또는 615 단계에서 수신한 ePK.UE를 포함할 수도 있다.
618 단계에서 AUSF는 DCS로 인증 통지 메시지를 송신할 수 있다. DCS로 전송되는 인증 통지 메시지는 UE ID, UPU 과정에 사용될 UDM의 주소, 및/또는 ePK.UE를 포함할 수 있다.
619 단계에서 DCS는 618 단계에서 받은 UE ID를 매칭시켜 제 2 사전 설정에 의해 제공된 PS의 주소를 찾을 수 있다.
620 단계에서 DCS는 인증 통지 메시지를 PS에 송신할 수 있다. 인증 통지 메시지는 UE의 ID, ePK.UE, 그리고 608 단계가 수행되지 않았다면 제어 평면을 이용한 프로비저닝이 사용될 것이라는 지시자를 포함할 수 있다.
621 단계에서 PS는 620 단계에서 수신한 UE의 ID와 제 3 사전 설정에 의해 제공된 UE ID를 매칭시켜 해당 UE에 제공될 SO-SNPN의 credential을 찾을 수 있다. PS는 DCS가 제공한 지시자를 바탕으로 자신의 임시 키 쌍(ePK.PS, eSK.PS)을 생성하고, ePK.UE와 eSK.PS로 임시 공유 키들(ephemeral session keys) 을 생성할 수 있다. 임시 공유 키들은 암호화에 사용될 키(ephemeral encryption key)와 무결성 보호에 사용될 키(ephemeral MAC key)로 구성될 수 있다. PS는 해당 UE에 전달할 SO-SNPN의 credential을 임시 암호화 키로 암호화 하고(Cipher-text value), 이 값(Cipher-text value)을 MAC 키로 해쉬한 값(MAC-tag value)을 계산할 수 있다. 암호화 및 무결성 보호된 SO-SNPN의 credential은 Cipher-text 값과 MAC-tag 값으로 이루어질 수 있다.
622 단계에서 PS는 DCS에 프로비저닝 요청 메시지를 송신할 수 있다. 해당 메시지는 UE ID, ePK.PS, 및/또는 암호화 및 무결성 보호된 SO-SNPN의 credential을 포함할 수 있다.
623 단계에서 DCS는 UDM에 프로비저닝 요청 메시지를 전달할 준비를 할 수도 있다. 혹은 후술되는 UDM의 기능적 역할을 DCS 혹은 PS가 대신할 수도 있다.
624 단계에서 DCS는 UDM에 프로비저닝 요청 메시지를 송신할 수 있다. 해당 메시지는 622 단계에서 PS로부터 받은 정보를 포함할 수 있다.
625 단계에서 UDM은 UPU 과정을 수행하기 위해 Nausf_UPUProtection 서비스를 요청할 수 있다. 해당 메시지(e.g., Nausf_UPUProtection 요청 메시지)는 Onboarding SUPI와 암호화 및 무결성 보호된 SO-SNPN의 credential을 포함할 수 있다.
626 단계에서 암호화 및 무결성 보호된 SO-SNPN의 credential은 AUSF에 의해 K_ausf를 이용하여 무결성 보호가 될 수 있다.
627 단계에서 AUSF는 Nausf_UPUProtection Response를 통해 626 단계에서 계산한 UPU-MAC-I_ausf 값과 Counter_upu 값을 UDM에 전달할 수 있다. Counter_upu는 0x00 0x00에서 시작하여 UPU-MAC-I_ausf를 계산할 때마다 증가하는 값으로서, 재전송 공격을 방지할 수 있다.
628 단계에서 UDM은 Nudm_SDM_Notification 서비스를 통해 UPU Data, 626 단계에서 AUSF가 계산한 UPU-MAC-I_ausf, Counter_upu 값, 및/또는 624 단계에서 수신한 ePK.PS를 AMF/SEAF로 송신할 수 있다.
629 단계에서 AMF/SEAF는 UE에 DL NAS Transport를 송신할 수 있다. DL NAS Transport 메시지는 UPU 데이터, UPU-MAC-I_ausf, 및 Counter_upu, 및/또는 628 단계에서 수신한 ePK.PS를 포함할 수 있다.
630 단계에서 UE는 K_ausf를 사용하여 UPU-MAC-I_ausf를 검증할 수 있다. UE는 eSK.UE와 ePK.PS를 이용하여 임시 공유 키들(ephemeral session keys)을 생성할 수 있다. 임시 공유 키들은 암호화에 사용될 키(ephemeral encryption key)와 무결성 보호에 사용될 키(ephemeral MAC key)로 구성될 수 있다. 이 키들은 621 단계에서 PS가 생성한 키들과 같다. UE는 ephemeral MAC key를 이용해 MAC-tag 값을 인증하고, ephemeral encryption key를 이용하여 Cipher-text 값으로부터 SO-SNPN의 credential을 구할 수 있다.
도 7a 내지 도 7e는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 PS로부터 SO-SNPN의 credential을 안전하게 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 7a 내지 도 7e의 시그널링 순서는 경우에 따라 변경될 수도 있다. 또한, 도 7a 내지 도 7e 의 각 단계들 중 일부는 경우에 따라 생략될 수도 있으며, 둘 이상의 단계가 결합되어 하나의 단계로 수행될 수도 있다.
도 7a 내지 도 7e 에 도시된 절차를 위해 다음의 설정 중 하나 이상이 사전에 수행될 수 있다.
701-E1: 제 1 사전 설정
UE 제조사는 UE를 제조할 때 DCS와의 상호 인증에 사용될 credential을 UE에 프로비저닝 할 수 있다.
701-E2: 제 2 사전 설정
UE 제조사는 온보딩(onboarding)의 목적을 위해 ON-SNPN에 접속하는 UE와의 상호 인증에 사용될 credential을 DCS에 프로비저닝 할 수 있다. UE가 SO-SNPN 소유자에 팔리고 난 후, UE 제조사는 SO-SNPN의 credential을 UE에 프로비저닝 할 수 있는 PS의 주소를 DCS에 프로비저닝 할 수 있다. PS의 주소는 제어 평면을 이용한 프로비저닝이 수행될 경우, DCS가 PS에 프로비저닝을 트리거링(triggering)하기 위해 PS를 찾을 때 사용될 수 있다. DCS는 PS가 제어 평면을 이용한 프로비저닝을 선호한다는 정보를 가지고 있을 수 있다. 추가로 DCS는 ON-SNPN, UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
701-E3: 제 3 사전 설정
UE 제조사는 SO-SNPN 소유자에 팔린 UE의 ID(예를 들어 Onboarding SUPI, IMEI 등)를 PS에 제공할 수 있다. PS는 UE ID를 저장해두었다가 후에 해당 UE ID를 가진 단말에 제공할 SO-SNPN의 credential을 찾는 데 사용할 수 있다. PS는 단말 제조사로부터 DCS와 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
도 7a 내지 도 7e를 참조하면, 701-E1, 701-E2, 701-E3 단계에서 제 1 사전 설정(701-E1), 제 2 사전 설정(701-E2), 그리고 제 3 사전 설정(701-E3)이 수행될 수 있다. 제 1 사전 설정, 제 2 사전 설정, 제 3 사전 설정은 동시에 수행되거나, 3 개의 사전 설정이 동시에 수행되지 않고 순차적으로 수행될 수 있다. 순차적으로 수행되는 경우 그 순서는 정해져 있는 것은 아닐 수 있다.
제 1 사전 설정 및/또는 제 2 사전 설정은 UE가 UE의 가입 정보가 없는 ON-SNPN에 접속할 때, UE를 인증할 수 있는 DCS의 도움을 받아 성공적으로 인증하기 위해 필요한 과정(UE와 DCS가 credential을 미리 프로비전 받는 과정)과, 후에 UE가 PS로부터 성공적으로 SO-SNPN의 credential을 제공받기 위해 필요한 과정(DCS에 PS 주소를 저장하는 과정)을 포함할 수 있다. 제 2 사전 설정을 통해 DCS는 PS, ON-SNPN, 또는 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 그렇지 않은 경우 등록 과정을 통해서 제공받을 수 있다. 제 3 사전 설정을 통해 PS는 단말 제조사로부터 DCS 혹은 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 또는 이후의 다른 엔티티로부터 제공받을 수도 있다.
702 단계에서 NG-RAN은 브로드캐스트 시스템 정보를 브로드캐스팅 할 수 있다. 브로드캐스트 시스템 정보는 UE에 의해 수신될 수 있다. 브로드캐스트 시스템 정보는 하나 이상의 PLMN 식별자(ID), PLMN ID당 네트워크 ID, 온보딩 가능 인디케이션(onboarding enabled indication)을 포함할 수 있다. PLMN ID와 Network ID의 조합은 NPN을 나타낼 수 있다. NG-RAN은 UE에 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 제공할 수도 있다.
703 단계에서 UE는 NG-RAN으로부터 수신한 브로드캐스팅 시스템 정보를 기반으로 ON-SNPN을 선택하고, AMF/SEAF로 등록 요청(Registration Request) 메시지를 송신할 수 있다. 예를 들어, 등록 요청 메시지의 송신은 UE에서 파워 온(power-on) 이벤트가 발생하거나 사용자의 입력이 있는 경우 트리거될 수 있다. 등록 요청 메시지는 등록 타입(registration type) 및 Onboarding SUCI를 포함할 수 있다. 등록 타입은 UE가 해당 NPN에 대한 가입 정보가 없다는 것을 나타내는"SNPN Onboarding"을 포함할 수 있다. 예를 들어, Onboarding SUCI는 "username@realm"와 같은 형식을 가질 수 있다. 여기서 realm 부분은 DCS를 나타낼 수 있다. UE는 등록 요청 메시지에 UE가 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 함께 보낼 수도 있다.
704 단계에서 AMF/SEAF는 UE로부터 등록 요청 메시지를 수신하고, 수신된 등록 요청 메시지에 포함된 Onboarding SUCI를 확인할 수 있다. 그리고 AMF/SEAF는 onboarding SUCI의 realm 부분을 기반으로 DCS를 식별하고, 식별된 DCS와 통신할 수 있는 AUSF로 인증 요청(Authentication Request) 메시지를 송신할 수 있다. 해당 메시지에는 703 단계에서 수신한 UE가 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 포함할 수도 있다.
705 단계에서 AUSF는 인증 요청 메시지를 기반으로 DCS로 인증 요청 메시지를 송신할 수 있다. DCS로 전송되는 인증 요청 메시지는 AUSF가 704 단계에서 AMF/SEAF로부터 수신한 인증 요청 메시지에 포함된 정보를 포함할 수 있다. 추가로 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 포함할 수도 있다. DCS가 AAA 서버인 경우, AUSF는 프로토콜 변환을 위해 NSSAAF를 통해 DCS에 인증 요청 메시지를 송신할 수 있다. ON-SNPN과 DCS는 계약 관계가 있을 수도 있다. 또한 DCS가 ON-SNPN의 도메인 밖에 존재할 경우에 ON-SNPN과 DCS 간의 메시지 교환은 NEF를 통해 수행될 수도 있다. 혹은 인증 과정에서의 DCS의 기능적 역할을 AUSF가 대신할 수도 있다.
706 단계에서 UE와 DCS는 EAP 인증(예를 들어 EAP-TLS)을 수행할 수 있다.
707 단계에서 DCS는 705 단계에서 받았거나 제 2 사전 설정에 의해 제공된 지시자들을 기반으로, UE/ON-SNPN/DCS/PS 모든 엔티티가 제어 평면을 이용한 프로비저닝을 지원한다는 것을 알았다면 제어 평면을 이용한 프로비저닝 단계를 준비할 수 있다. 또한 인증이 성공한 후 DCS는 생성한 키 재료 중 EMSK(Extended Master Session Key)를 저장할 수 있다. EMSK는 인증이 성공한 후 생성되는 키 재료 중 하나로, 어느 다른 엔티티로 전달되지 않는 값이다. 만약 UE/ON-SNPN/DCS/PS 중 적어도 하나 이상의 엔티티가 제어 평면을 이용한 프로비저닝을 지원하지 않는다면, 도 3의 311 내지 318 단계가 수행될 수 있다.
708 단계에서 DCS는 제어 평면을 이용한 프로비저닝이 사용될 것이라는 통지를 PS에 전달할 수 있다. 상기 통지는 UE ID 및/또는 제어 평면을 이용한 프로비저닝이 사용될 것임을 나타내는 지시자를 포함할 수 있다. 이를 만약 PS가 받았다면 해당 UE에 전달될 SO-SNPN의 credential을 미리 준비할 수도 있다.
709 단계에서 DCS는 EAP 응답(response) 메시지를 AUSF로 송신할 수 있다. EAP 응답 메시지는 인증 성공(EAP Success) 메시지와 UE를 나타내는 Onboarding SUPI, ON-SNPN에서 UE와의 통신에 사용될 키(key)를 생성하기 위한 키 재료(keying material), 및 제어 평면을 이용한 프로비저닝이 수행될 것이라는 지시자를 포함할 수 있다.
710 단계에서 AUSF는 709 단계에서 수신한 EAP 응답 메시지 내의 키 재료를 기반으로 K_ausf를 생성할 수 있다.
711 단계에서 AUSF는 EAP 응답 메시지를 AMF/SEAF로 송신할 수 있다. AMF/SEAF로 전송되는 EAP 응답 메시지는 인증 성공 메시지, K_ausf로부터 생성한 K_seaf, Onboarding SUPI, 및/또는 제어 평면을 이용한 프로비저닝이 수행된다는 지시자를 포함할 수 있다.
712 단계에서 AMF/SEAF는 EAP 응답 메시지를 UE로 송신할 수 있다. UE로 전송되는 EAP 응답 메시지는 인증 성공 메시지, 키를 나타내는 ngKSI(5G key set identifier), ABBA 파라미터, 및/또는 제어 평면을 이용한 프로비저닝이 수행된다는 지시자를 포함할 수 있다.
713 단계에서 UE는 710 단계에서 AUSF가 K_ausf를 생성한 방식에 대응되는 방식을 사용하여 K_ausf를 생성할 수 있다. 또한 UE는 712 단계에서 받은 제어 평면을 이용한 프로비저닝이 수행된다는 지시자를 기반으로, 임시 키 쌍(ephemeral key pair)을 생성할 수 있다. 임시 키 쌍은 임시 공유 키(ePK.UE: ephemeral public key of UE)와 임시 개인 키(eSK.UE: ephemeral private key of UE)로 구성될 수 있다. UE는 eSK.UE는 저장해두고, ePK.UE는 전달할 준비를 할 수 있다. UE는 707 단계에서 DCS가 구한 EMSK를 같은 방식으로 구할 수 있으며, EMSK를 직접 이용하거나 혹은 이 키 재료를 이용하여 UE가 생성한 ePK.UE에 대한 무결성 보호를 수행할 수 있다.
714 단계에서 AMF/SEAF는 UE와의 키 공유를 위해 NAS Security Mode Command 메시지를 UE에게 송신할 수 있다.
715 단계에서 UE도 키 공유를 위해 NAS Security Mode Complete 메시지를 AMF/SEAF로 송신할 수 있다. 해당 메시지에는 ePK.UE와 이를 EMSK 혹은 EMSK를 활용한 키로 무결성 보호한 MAC 값을 포함할 수 있다.
716 단계에서 AMF/SEAF는 UE가 ON-SNPN에 성공적으로 온보딩 과정을 마쳤다는 것을 알 수 있고, 이를 알릴 준비를 할 수 있다.
717 단계에서 AMF/SEAF는 AUSF에 인증 통지 메시지를 AUSF로 송신할 수 있다. 인증 통지 메시지는 UE가 온보딩 과정을 성공적으로 끝마쳤음을 지시하는 정보, UE의 ID, 및/또는 715 단계에서 수신한 ePK.UE와 이를 EMSK 혹은 EMSK를 활용한 키로 무결성 보호한 MAC 값을 포함할 수도 있다.
718 단계에서 AUSF는 DCS로 인증 통지 메시지를 송신할 수 있다. DCS로 전송되는 인증 통지 메시지는 UE ID, UPU 과정에 사용될 UDM의 주소, 및/또는 ePK.UE와 이를 EMSK 혹은 EMSK를 활용한 키로 무결성 보호한 MAC 값을 포함할 수 있다.
719 단계에서 DCS는 718 단계에서 받은 UE ID를 매칭시켜 제 2 사전 설정에 의해 제공된 PS의 주소를 찾을 수 있다. DCS는 718 단계에서 수신한 MAC 값을 707 단계에서 저장한 EMSK를 활용하여 검증할 수 있다.
720 단계에서 DCS는 인증 통지 메시지를 PS에 송신할 수 있다. PS로 전송되는 인증 통지 메시지는 UE의 ID, ePK.UE, 그리고 708 단계가 수행되지 않았다면 제어 평면을 이용한 프로비저닝이 사용될 것이라는 지시자를 포함할 수 있다.
721 단계에서 PS는 720 단계에서 수신한 UE의 ID와 제 3 사전 설정에 의해 제공된 UE ID를 매칭시켜 해당 UE에 제공될 SO-SNPN의 credential을 찾을 수 있다. PS는 DCS가 제공한 지시자를 바탕으로 자신의 임시 키 쌍(ePK.PS, eSK.PS)을 생성하고, ePK.UE와 eSK.PS로 임시 공유 키들(ephemeral session keys)을 생성할 수 있다. 임시 공유 키들은 암호화에 사용될 키(ephemeral encryption key)와 무결성 보호에 사용될 키(ephemeral MAC key)로 구성될 수 있다. PS는 해당 UE에 전달할 SO-SNPN의 credential을 임시 암호화 키로 암호화 하고(Cipher-text value), 이 값(Cipher-text value)을 MAC 키로 해쉬한 값(MAC-tag value)을 계산할 수 있다. 암호화 및 무결성 보호된 SO-SNPN의 credential은 Cipher-text 값과 MAC-tag 값으로 이루어질 수 있다.
722 단계에서 PS는 DCS에 프로비저닝 요청 메시지를 송신할 수 있다. 해당 메시지는 UE ID, ePK.PS, 및/또는 암호화 및 무결성 보호된 SO-SNPN의 credential을 포함할 수 있다.
723 단계에서 DCS는 UDM에 프로비저닝 요청 메시지를 전달할 준비를 할 수도 있다. DCS는 722 단계에서 수신한 ePK.PS를 707 단계에서 저장한 EMSK를 활용하여 무결성 보호를 수행하여 MAC 값을 계산할 수 있다. 후술되는 UDM의 기능적 역할을 DCS 혹은 PS가 대신할 수도 있다.
724 단계에서 DCS는 UDM에 프로비저닝 요청 메시지를 송신할 수 있다. 해당 메시지는 722 단계에서 PS로부터 받은 정보와 723 단계에서 ePK.PS를 무결성 보호한 MAC 값을 포함할 수 있다.
725 단계에서 UDM은 UPU 과정을 수행하기 위해 Nausf_UPUProtection 서비스를 요청할 수 있다. 해당 메시지(e.g., Nausf_UPUProtection 요청 메시지)는 Onboarding SUPI와 암호화 및 무결성 보호된 SO-SNPN의 credential을 포함할 수 있다.
726 단계에서 암호화 및 무결성 보호된 SO-SNPN의 credential은 AUSF에 의해 K_ausf를 이용하여 무결성 보호가 될 수 있다.
727 단계에서 AUSF는 Nausf_UPUProtection Response를 통해 726 단계에서 계산한 UPU-MAC-I_ausf 값과 Counter_upu 값을 UDM에 전달할 수 있다. Counter_upu는 0x00 0x00에서 시작하여 UPU-MAC-I_ausf를 계산할 때마다 증가하는 값으로서, 재전송 공격을 방지할 수 있다.
728 단계에서 UDM은 Nudm_SDM_Notification 서비스를 통해 UPU Data, 726 단계에서 AUSF가 계산한 UPU-MAC-I_ausf, Counter_upu 값, 724 단계에서 수신한 ePK.PS와 MAC 값을 AMF/SEAF로 송신할 수 있다.
729 단계에서 AMF/SEAF는 UE에 DL NAS Transport를 송신할 수 있다. DL NAS Transport 메시지는 UPU 데이터, UPU-MAC-I_ausf, 및 Counter_upu, 728 단계에서 수신한 ePK.PS와 MAC 값을 포함할 수 있다.
730 단계에서 UE는 K_ausf를 사용하여 UPU-MAC-I_ausf를 검증할 수 있다. 또한 UE는 EMSK를 활용하여 729 단계에서 수신한 MAC 값을 검증할 수 있다. UE는 eSK.UE와 ePK.PS를 이용하여 임시 공유 키들(ephemeral session keys)을 생성할 수 있다. 임시 공유 키들은 암호화에 사용될 키(ephemeral encryption key)와 무결성 보호에 사용될 키(ephemeral MAC key)로 구성될 수 있다. 이 키들은 721 단계에서 PS가 생성한 키들과 같을 수 있다. UE는 ephemeral MAC key를 이용해 MAC-tag-값을 인증하고, ephemeral encryption key를 이용하여 Cipher-text 값으로부터 SO-SNPN의 credential을 구할 수 있다.
도 8a 및 도 8b는 본 개시의 일 실시 예에 따른 UE가 ON-SNPN에 접속하여 상호 인증을 수행한 뒤 PS로부터 SO-SNPN의 credential을 안전하게 프로비저닝 받는 방법의 일 예를 도시한 흐름도이다.
도 8a 및 도 8b의 시그널링 순서는 경우에 따라 변경될 수도 있다. 또한, 도 8a 및 도 8b의 각 단계들 중 일부는 경우에 따라 생략될 수도 있으며, 둘 이상의 단계가 결합되어 하나의 단계로 수행될 수도 있다.
도 8a 및 도 8b에 도시된 절차를 위해 다음의 설정 중 하나 이상이 사전에 수행될 수 있다.
801-F1: 제 1 사전 설정
UE 제조사는 UE를 제조할 때 DCS와의 상호 인증에 사용될 credential을 UE에 프로비저닝 할 수 있다. UE는 PS의 인증서를 인증할 CA 인증서와 UE 자신의 인증서를 가지고 있을 수도 있다.
802-F2: 제 2 사전 설정
UE 제조사는 온보딩(onboarding)의 목적을 위해 ON-SNPN에 접속하는 UE와의 상호 인증에 사용될 credential을 DCS에 프로비저닝 할 수 있다. UE가 SO-SNPN 소유자에 팔리고 난 후, UE 제조사는 SO-SNPN의 credential을 UE에 프로비저닝 할 수 있는 PS의 주소를 DCS에 프로비저닝 할 수 있다. PS의 주소는 제어 평면을 이용한 프로비저닝이 수행될 경우, DCS가 PS에 프로비저닝을 트리거링(triggering)하기 위해 PS를 찾을 때 사용될 수 있다. DCS는 PS, ON-SNPN, UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
801-F3: 제 3 사전 설정
UE 제조사는 SO-SNPN 소유자에 팔린 UE의 ID(예를 들어 Onboarding SUPI, IMEI 등)를 PS에 제공할 수 있다. PS는 UE ID를 저장해두었다가 후에 해당 UE ID를 가진 단말에 제공할 SO-SNPN의 credential을 찾는 데 사용할 수 있다. PS는 UE의 인증서를 인증할 CA 인증서와 PS 자신의 인증서를 가지고 있을 수 있다. PS는 단말 제조사로부터 DCS와 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 제공받을 수도 있다.
도 8a 및 도 8b를 참조하면, 801-F1, 801-F2, 801-F3 단계에서 제 1 사전 설정(801-F1), 제 2 사전 설정(801-F2), 그리고 제 3 사전 설정(801-F3)이 수행될 수 있다. 제 1 사전 설정, 제 2 사전 설정, 제 3 사전 설정은 동시에 수행되거나, 3 개의 사전 설정이 동시에 수행되지 않고 순차적으로 수행될 수 있다. 순차적으로 수행되는 경우 그 순서는 정해져 있는 것은 아닐 수 있다.
제 1 사전 설정 및/또는 제 2 사전 설정은 UE가 UE의 가입 정보가 없는 ON-SNPN에 접속할 때, UE를 인증할 수 있는 DCS의 도움을 받아 성공적으로 인증하기 위해 필요한 과정(UE와 DCS가 credential을 미리 프로비전 받는 과정)과, 후에 UE가 PS로부터 성공적으로 SO-SNPN의 credential을 제공받기 위해 필요한 과정(DCS에 PS 주소를 저장하는 과정)을 포함할 수 있다. 제 1 사전 설정 및/또는 제 3 사전 설정은 UE와 PS가 임시 공유 키를 생성하기 위해 정보를 보낼 때 사인에 필요한 인증서를 설정해 놓는 과정(UE와 PS에 각각 UE의 인증서/CA 인증서, PS 인증서/CA 인증서 설정)을 포함할 수 있다. 제 2 사전 설정을 통해 DCS는 PS, ON-SNPN, 또는 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 그렇지 않은 경우 등록 과정을 통해서 제공받을 수 있다. 제 3 사전 설정을 통해 PS가 단말 제조사로부터 DCS 혹은 UE가 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 미리 제공받을 수도 있고 또는 이후의 다른 엔티티로부터 제공받을 수도 있다.
802 단계에서 NG-RAN은 브로드캐스트 시스템 정보를 브로드캐스팅 할 수 있다. 브로드캐스트 시스템 정보는 UE에 의해 수신될 수 있다. 브로드캐스트 시스템 정보는 하나 이상의 PLMN 식별자(ID), PLMN ID당 네트워크 ID, 온보딩 가능 인디케이션(onboarding enabled indication)을 포함할 수 있다. PLMN ID와 Network ID의 조합은 NPN을 나타낼 수 있다. NG-RAN은 UE에 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 제공할 수도 있다.
803 단계에서 UE는 NG-RAN으로부터 수신한 브로드캐스팅 시스템 정보를 기반으로 ON-SNPN을 선택하고, AMF/SEAF로 등록 요청(Registration Request) 메시지를 송신할 수 있다. 예를 들어, 등록 요청 메시지의 송신은 UE에서 파워 온(power-on) 이벤트가 발생하거나 사용자의 입력이 있는 경우 트리거될 수 있다. 등록 요청 메시지는 등록 타입(registration type) 및 Onboarding SUCI를 포함할 수 있다. 등록 타입은 UE가 해당 NPN에 대한 가입 정보가 없다는 것을 나타내는"SNPN Onboarding"을 포함할 수 있다. 예를 들어, Onboarding SUCI는 "username@realm"와 같은 형식을 가질 수 있다. 여기서 realm 부분은 DCS를 나타낼 수 있다. UE는 등록 요청 메시지에 UE가 제어 평면을 이용한 프로비저닝 중 어떤 옵션을 지원하는지에 대한 지시자를 함께 보낼 수도 있다. UE가 여러 옵션 중 하나 이상의 방법을 지원할 수도 있다. 또는, UE가 제어 평면을 이용한 프로비저닝을 지원하지 않을 수도 있다. 이 경우에 해당 지시자는 값을 가지고 있지 않거나 예를 들어 0 값을 나타낼 수 있다.
804 단계에서 AMF/SEAF는 UE로부터 등록 요청 메시지를 수신하고, 수신된 등록 요청 메시지에 포함된 Onboarding SUCI를 확인할 수 있다. 그리고 AMF/SEAF는 onboarding SUCI의 realm 부분을 기반으로 DCS를 식별하고, 식별된 DCS와 통신할 수 있는 AUSF로 인증 요청(Authentication Request) 메시지를 송신할 수 있다. 해당 메시지에는 803 단계에서 수신한 UE가 제어 평면을 이용한 프로비저닝 중 어떤 옵션을 지원하는지에 대한 지시자를 포함할 수도 있다.
805 단계에서 AUSF는 인증 요청 메시지를 기반으로 DCS로 인증 요청 메시지를 송신할 수 있다. DCS로 전송되는 인증 요청 메시지는 AUSF가 804 단계에서 AMF로부터 수신한 인증 요청 메시지에 포함된 정보를 포함할 수 있다. 추가로 ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자를 포함할 수도 있다. DCS가 AAA 서버인 경우, AUSF는 프로토콜 변환을 위해 NSSAAF를 통해 DCS에 인증 요청 메시지를 송신할 수 있다. ON-SNPN과 DCS는 계약 관계가 있을 수도 있다. 또한 DCS가 ON-SNPN의 도메인 밖에 존재할 경우에 ON-SNPN과 DCS 간의 메시지 교환은 NEF를 통해 수행될 수도 있다. 혹은 인증 과정에서의 DCS의 기능적 역할을 AUSF가 대신할 수도 있다.
806 단계에서 UE와 DCS는 EAP 인증(예를 들어 EAP-TLS)을 수행할 수 있다.
807 단계에서 DCS는 806 단계의 결과를 기반으로 PS에 알림(Notification)을 송신할 수 있다. 해당 메시지에는 UE ID를 포함하고, 805 단계에서 받았거나 제 2 사전 설정에 의해 제공된 지시자들(e.g., ON-SNPN이 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자, DCS가 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자, UE가 제어 평면을 이용한 프로비저닝 중 어떤 옵션을 지원하는지에 대한 지시자 등)을 포함할 수도 있다.
808 단계에서 PS는 807 단계에서 받은 지시자들 혹은 제 3 사전 설정에 의해 제공된 지시자들이 UE/ON-SNPN/DCS/PS 모두 제어 평면을 지원한다는 것을 나타내고, UE가 지원하는 옵션을 PS가 선호한다면, PS는 제어 평면을 이용하여 SO-SNPN의 credential을 UE에 제공하기를 결정할 수 있다. 만약 UE가 지원하는 옵션이 여러 가지라면, PS는 자신이 선호하는 옵션을 선택하여 전달할 수 있다. 만약 UE/ON-SNPN/DCS/PS 중 적어도 하나 이상의 엔티티가 제어 평면을 이용한 프로비저닝을 지원하지 않는다는 것을 나타내거나 혹은 PS가 사용자 평면을 이용한 프로비저닝을 선호한다면, 809 단계에서 지시자를 특정 값(예를 들어"0")으로 설정 후 보낼 수 있다.
809 단계에서 PS는 제어 평면을 이용한 프로비저닝 중 PS가 선택한 옵션을 나타내는 지시자를 보낼 수 있다. 만약 PS가 선택한 옵션이 PS가 생성한 nonce 값을 필요로 한다면 이 단계에서 PS가 생성한 nonce 값을 포함하여 전송할 수도 있다.
810 단계에서 DCS가 809 단계에서 받은 지시자가 "0"이었다면, 도 3a 내지 도 3c의 310단계 내지 318 단계가 수행될 수 있다. 만약 지시자가 "1"이었다면, 도 4a 내지 도 4e의 410 단계 내지 431 단계가 수행될 수 있다. 만약 지시자가 "2"이었다면, 도 5a 내지 도 5e의 509 단계 내지 530 단계가 수행될 수 있다. 만약 지시자가 "3"이었다면 도 6a 내지 도 6e의 609 단계 내지 630 단계가 수행될 수 있다. 만약 지시자가 "4"이었다면 도 7a 내지 도 7e의 709 단계 내지 730 단계가 수행될 수 있다.
본 개시의 다양한 실시 예들에 따르면, UE는 ON-SNPN에 성공적으로 접속한 후에, 제어 평면을 이용하여 PS로부터 SO-SNPN의 credential을 받을 때 ON-SNPN의 네트워크 엔티티를 이용할 수 있다. 기존의 UPU 과정을 그대로 이용하여 UE에 credential을 프로비저닝 할 시에는 PS가 제공하는 credential의 정보가 ON-SNPN의 네트워크 엔티티에 노출될 수 있다. UE와 PS 이외의 엔티티에 노출되는 위험을 막기 위해 UE와 PS가 각각 임시 키 쌍을 생성하고, 서로의 임시 공개 키를 공유한 후, 상대의 임시 공개 키와 자신의 임시 개인 키를 이용하여 임시 공유 키를 생성할 수 있다. 생성된 임시 공유 키를 이용하여 PS가 SO-SNPN의 credential을 암호화, 무결성 보호를 수행하여 제어 평면을 이용해 전달하고, ON-SNPN은 암호화 및 무결성 보호된 credential 정보를 제어 평면을 이용하여 UE에 전달할 수 있다. UE는 임시 공유 키를 이용하여 SO-SNPN의 credential을 획득할 수 있다.
상술한 도 3a 내지 도 8b의 동작들은 후술하는 도 9 및 도 10의 단말 및 네트워크 엔티티에 의해 수행될 수 있다.
도 9는 본 개시의 일 실시 예에 따른 단말의 블록 구성도이다.
도 9를 참조하면, 단말은 송수신부(920) 및 단말의 전반적인 동작을 제어하는 제어부(910)를 포함할 수 있다. 송수신부(920)는 송신부(925) 및 수신부(923)를 포함할 수 있다.
송수신부(920)는 다른 네트워크 엔티티들(예를 들어, 초기 AMF 또는 기지국)과 신호를 송수신할 수 있다.
제어부(910)는 상술한 다양한 실시 예들 중 어느 하나의 동작을 수행하도록 단말을 제어할 수 있다. 제어부(910) 및 송수신부(920)는 반드시 별도의 모듈들로 구현되어야 하는 것은 아니고, 단일 칩과 같은 형태로 하나의 구성부로 구현될 수 있음은 물론이다. 제어부(910) 및 송수신부(920)는 전기적으로 연결될 수 있다. 일 실시 예에서 제어부(910)는 회로(circuit), 어플리케이션 특정(application-specific) 회로, 또는 적어도 하나의 프로세서(processor)일 수 있다. 또한, 단말의 동작들은 해당 프로그램 코드를 저장한 메모리 장치를 단말 내의 구성부(예를 들어 제어부(910) 및/또는 도시되지 않은 다른 구성 요소)에 구비함으로써 실현될 수 있다.
도 10은 본 개시의 일 실시 예에 따른 네트워크 엔티티(network entity)의 블록 구성도이다. 도 10에 도시된 네트워크 엔티티는 시스템 구현에 따라 적어도 하나의 NF(예를 들어, 기지국, 초기 AMF, 타겟 AMF, 기존 AMF, NSSF, NRF, SMF, UPF, AF, NEF, PCF, DN 또는 UDM 등)을 포함할 수 있다.
도 10을 참조하면, 네트워크 엔티티는 송수신부(1020) 및 네트워크 엔티티의 전반적인 동작을 제어하는 제어부(1010)를 포함할 수 있다. 송수신부(1020)는 송신부(1025) 및 수신부(1023)를 포함할 수 있다.
송수신부(1020)는 단말 또는 다른 네트워크 엔티티들과 신호를 송수신할 수 있다.
제어부(1010)는 상술한 실시 예들 중 어느 하나의 동작을 수행하도록 네트워크 엔티티를 제어할 수 있다. 제어부(1010) 및 송수신부(1020)는 반드시 별도의 모듈들로 구현되어야 하는 것은 아니고, 단일 칩과 같은 형태로 하나의 구성부로 구현될 수 있음은 물론이다. 제어부(1010) 및 송수신부(1020)는 전기적으로 연결될 수 있다. 일 실시 예에서 제어부(1010)는 회로(circuit), 어플리케이션 특정(application-specific) 회로, 또는 적어도 하나의 프로세서(processor)일 수 있다. 또한, 네트워크 엔티티의 동작들은 해당 프로그램 코드를 저장한 메모리 장치를 네트워크 엔티티 내의 구성부(예를 들어 제어부(1010) 및/또는 도시되지 않은 다른 구성요소)에 구비함으로써 실현될 수 있다.
도 1 내지 도 10이 예시하는 구성도, 제어/데이터 신호 송수신 방법의 예시도, 동작 절차 예시도들은 본 개시의 실시 예들의 권리범위를 한정하기 위한 의도가 없음을 유의하여야 한다. 즉, 도 1 내지 도 10에 기재된 모든 구성부, 엔티티, 또는 동작의 단계가 개시의 실시를 위한 필수구성요소인 것으로 해석되어서는 안되며, 일부 구성요소 만을 포함하여도 개시의 본질을 해치지 않는 범위 내에서 구현될 수 있다.
앞서 설명한 실시 예들의 동작들은 해당 프로그램 코드를 저장한 메모리 장치를 장치 내의 임의의 구성부에 구비함으로써 실현될 수 있다. 즉, 장치 내의 제어부는 메모리 장치 내에 저장된 프로그램 코드를 프로세서 혹은 CPU(Central Processing Unit)에 의해 읽어내어 실행함으로써 앞서 설명한 동작들을 실행할 수 있다.
본 명세서에서 설명되는 엔티티, 또는 단말 장치의 다양한 구성부들과, 모듈(module)등은 하드웨어(hardware) 회로, 일 예로 상보성 금속 산화막 반도체(complementary metal oxide semiconductor) 기반 논리 회로와, 펌웨어(firmware)와, 소프트웨어(software) 및/혹은 하드웨어와 펌웨어 및/혹은 머신 판독 가능 매체에 삽입된 소프트웨어의 조합과 같은 하드웨어 회로를 사용하여 동작될 수도 있다. 일 예로, 다양한 전기 구조 및 방법들은 트랜지스터(transistor)들과, 논리 게이트(logic gate)들과, 주문형 반도체와 같은 전기 회로들을 사용하여 실시될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 안되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (15)

  1. 무선 통신 시스템에서 단말에 의해 수행되는 방법에 있어서,
    프로비저닝 서버의 인증서와 연관된 CA(certificate authority) 인증서 및 상기 단말의 인증서를 포함하는 설정 정보를 획득하는 단계;
    제어 평면을 이용한 프로비저닝이 수행됨을 확인하는 단계;
    상기 확인에 기반하여 임시 키 쌍(ephemeral key pair)을 생성하는 단계; 및
    상기 설정 정보 및 상기 임시 키 쌍에 기초하여, 상기 제어 평면에서 SO-SNPN (subscription owner-standalone non-public network)의 크리덴셜(credential)을 획득하는 단계를 포함하는, 방법.
  2. 제 1항에 있어서,
    브로드캐스트 시스템 정보를 수신하는 단계를 더 포함하고,
    상기 브로드캐스트 시스템 정보는 ON-SNPN (onboarding-standalone non-public network)이 상기 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 지시자를 포함하는 것을 특징으로 하는 방법.
  3. 제 2항에 있어서,
    상기 브로드캐스트 시스템 정보에 기초하여 상기 ON-SNPN을 선택하는 단계; 및
    상기 ON-SNPN에 등록하기 위한 요청 메시지를 전송하는 단계를 더 포함하고,
    상기 요청 메시지는 상기 단말이 상기 제어 평면을 이용한 프로비저닝을 지원하는지 여부를 나타내는 지시자를 포함하는 것을 특징으로 하는 방법.
  4. 제 1항에 있어서,
    상기 제어 평면을 이용한 프로비저닝이 수행됨을 나타내는 지시자 및 상기 프로비저닝 서버가 생성한 논스(nonce) 값을 획득하는 단계; 및
    상기 논스 값을 상기 단말의 인증서에 대응되는 개인 키로 서명하여 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  5. 제 1항에 있어서,
    상기 임시 키 쌍은 상기 단말의 임시 공유 키 및 상기 단말의 임시 개인 키를 포함하며, 및
    상기 설정 정보는 DCS (default credentials server)와의 상호 인증에 사용될 크리덴셜을 더 포함하는 것을 것을 특징으로 하는 방법.
  6. 제 1항에 있어서, 상기 SO-SNPN의 크리덴셜을 획득하는 단계는:
    상기 CA 인증서에 기반하여 상기 프로비저닝 서버의 인증서를 검증하는 단계;
    상기 단말의 임시 개인 키 및 상기 프로비저닝 서버의 임시 공유 키에 기초하여, 암호화를 위한 제1 임시 키 및 무결성 보호를 위한 제2 임시 키를 생성하는 단계; 및
    상기 제1 임시 키 및 상기 제2 임시 키에 기반하여 상기 SO-SNPN의 크리덴셜을 획득하는 단계를 포함하는 것을 특징으로 하는 방법.
  7. 무선 통신 시스템에서 프로비저닝 서버에 의해 수행되는 방법에 있어서,
    상기 프로비저닝 서버의 인증서 및 단말의 인증서와 연관된 CA(certificate authority) 인증서를 포함하는 설정 정보를 획득하는 단계;
    제어 평면을 이용한 프로비저닝이 수행됨을 확인하는 단계;
    상기 제어 평면을 이용한 프로비저닝을 위한 임시 키 쌍(ephemeral key pair)을 생성하는 단계; 및
    상기 설정 정보 및 상기 임시 키 쌍에 기초하여, 상기 제어 평면에서 전달될 SO-SNPN (subscription owner-standalone non-public network)의 크리덴셜(credential)을 생성하는 단계를 포함하는, 방법.
  8. 제 7항에 있어서,
    상기 설정 정보는 DCS(default credentials server)가 상기 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보 및 상기 단말이 상기 제어 평면을 이용한 프로비저닝을 지원하는지에 대한 정보를 더 포함하는 것을 특징으로 하는 방법.
  9. 제 7항에 있어서,
    알림 메시지를 수신하는 단계를 더 포함하고,
    상기 알림 메시지는 ON-SNPN(onboarding-standalone non-public network)이 상기 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자, 상기 단말이 상기 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자, 또는 DCS(default credentials server)가 상기 제어 평면을 이용한 프로비저닝을 지원하는지 여부에 대한 지시자 중 적어도 하나의 지시자를 포함하는 것을 특징으로 하는 방법.
  10. 제 9항에 있어서, 상기 제어 평면을 이용한 프로비저닝이 수행됨을 확인하는 단계는:
    상기 설정 정보 또는 상기 알림 메시지 중 적어도 하나에 기반하여 상기 단말, 상기 ON-SNPN, 상기 DCS 및 상기 프로비저닝 서버가 모두 상기 제어 평면을 이용한 프로비저닝을 지원하는 경우, 상기 제어 평면을 이용하여 상기 SO-SNPN의 크리덴셜을 상기 단말에게 제공하기로 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
  11. 제 7항에 있어서,
    상기 제어 평면을 이용한 프로비저닝이 수행됨을 나타내는 지시자 및 상기 프로비저닝 서버가 생성한 논스(nonce) 값을 전송하는 단계; 및
    상기 논스 값을 상기 단말의 인증서에 대응되는 개인 키로 서명한 값을 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  12. 제 11항에 있어서,
    상기 단말의 인증서 및 상기 단말의 식별자를 수신하는 단계;
    상기 수신된 단말의 식별자 및 상기 설정 정보에 포함된 단말의 식별자를 매칭하여 상기 SO-SNPN의 크리덴셜을 찾는 단계;
    상기 CA 인증서에 기반하여 상기 수신된 단말의 인증서를 검증하는 단계;
    상기 단말의 임시 공유 키 및 상기 프로비저닝 서버의 임시 개인 키에 기초하여, 암호화를 위한 제1 임시 키 및 무결성 보호를 위한 제2 임시 키를 생성하는 단계를 더 포함하고,
    상기 상기 SO-SNPN의 크리덴셜은 상기 제1 임시 키에 기반하여 암호화 된 값과 상기 암호화된 값을 상기 제2 임시 키에 기반하여 해쉬하여 무결성 보호된 값으로 구성되는 것을 특징으로 하는 방법.
  13. 제 12항에 있어서,
    상기 암호화된 값 및 상기 무결성 보호된 값으로 구성된 상기 SO-SNPN의 크리덴셜을 상기 제어 평면에서 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  14. 무선 통신 시스템에서 단말에 있어서,
    송수신부; 및
    상기 송수신부와 기능적으로 연결된 제어부를 포함하고,
    상기 제어부는,
    프로비저닝 서버의 인증서와 연관된 CA(certificate authority) 인증서 및 상기 단말의 인증서를 포함하는 설정 정보를 획득하고,
    제어 평면을 이용한 프로비저닝이 수행됨을 확인하며,
    상기 확인에 기반하여 임시 키 쌍(ephemeral key pair)을 생성하고, 및
    상기 설정 정보 및 상기 임시 키 쌍에 기초하여, 상기 제어 평면에서 SO-SNPN (subscription owner-standalone non-public network)의 크리덴셜(credential)을 획득하도록 구성되는, 단말.
  15. 무선 통신 시스템에서 프로비저닝 서버에 있어서,
    송수신부; 및
    상기 송수신부와 기능적으로 연결된 제어부를 포함하고,
    상기 제어부는,
    상기 프로비저닝 서버의 인증서 및 단말의 인증서와 연관된 CA(certificate authority) 인증서를 포함하는 설정 정보를 획득하고,
    제어 평면을 이용한 프로비저닝이 수행됨을 확인하며,
    상기 제어 평면을 이용한 프로비저닝을 위한 임시 키 쌍(ephemeral key pair)을 생성하고, 및
    상기 설정 정보 및 상기 임시 키 쌍에 기초하여, 상기 제어 평면에서 전달될 SO-SNPN (subscription owner-standalone non-public network)의 크리덴셜(credential)을 생성하도록 구성되는, 프로비저닝 서버.
PCT/KR2023/000202 2022-01-05 2023-01-05 제어 평면을 이용하여 크리덴셜을 단말에 프로비저닝 시 종단 보안 형성을 위한 방법 및 장치 WO2023132650A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP23737398.0A EP4443929A1 (en) 2022-01-05 2023-01-05 Method and device for forming end-to-end security during provisioning of credentials to terminal by using control plane

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2022-0001620 2022-01-05
KR1020220001620A KR20230105957A (ko) 2022-01-05 2022-01-05 제어 평면을 이용하여 credential을 UE에 프로비저닝 시 종단 보안 형성을 위한 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2023132650A1 true WO2023132650A1 (ko) 2023-07-13

Family

ID=87073987

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/000202 WO2023132650A1 (ko) 2022-01-05 2023-01-05 제어 평면을 이용하여 크리덴셜을 단말에 프로비저닝 시 종단 보안 형성을 위한 방법 및 장치

Country Status (3)

Country Link
EP (1) EP4443929A1 (ko)
KR (1) KR20230105957A (ko)
WO (1) WO2023132650A1 (ko)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020205609A1 (en) * 2019-03-29 2020-10-08 Idac Holdings, Inc. Methods and apparatus for secure access control in wireless communications
WO2021236078A1 (en) * 2020-05-20 2021-11-25 Nokia Technologies Oy Simplified method for onboarding and authentication of identities for network access

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020205609A1 (en) * 2019-03-29 2020-10-08 Idac Holdings, Inc. Methods and apparatus for secure access control in wireless communications
WO2021236078A1 (en) * 2020-05-20 2021-11-25 Nokia Technologies Oy Simplified method for onboarding and authentication of identities for network access

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3 Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 17)", 3GPP TS 33.501, no. V17.4.0, 23 December 2021 (2021-12-23), pages 1 - 286, XP052083370 *
"3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 16)", 3GPP TS 38.331, no. V16.7.0, 23 December 2021 (2021-12-23), pages 1 - 963, XP052083424 *
ERICSSON: "Rapporteur`s editorial cleanup for eNPN", 3GPP TSG-WG SA2 MEETING #147E E-MEETING, S2-21XXXX (REVISION OF S2-21XXXXX), 6 October 2021 (2021-10-06), pages 1 - 17, XP009547863 *

Also Published As

Publication number Publication date
EP4443929A1 (en) 2024-10-09
KR20230105957A (ko) 2023-07-12

Similar Documents

Publication Publication Date Title
WO2020204474A1 (ko) 무선 통신 시스템에서 에지 컴퓨팅 서비스를 제공하기 위한 장치 및 방법
WO2018008943A1 (en) Method and device for managing security according to service in wireless communication system
WO2018008972A1 (en) Method and apparatus for accessing cellular network for sim profile
WO2018008983A1 (en) Method and system for authenticating access in mobile wireless network system
WO2020036401A1 (ko) 무선 통신 시스템에서 네트워크에 등록하기 위한 장치 및 방법
WO2021066427A1 (en) Method and apparatus for handling mobility procedure for ue
WO2021167314A1 (en) Method and apparatus for handling security policies in v2x communication system
WO2021066452A1 (ko) 5g 사용자 활성화 방법 및 장치
WO2020218843A1 (en) Method and system for providing non-access stratum (nas) message protection
WO2022114760A1 (en) Method and device for authenticating access stratum in next generation wireless communication system
WO2022149874A1 (en) Method and system of authentication and authorization in an msgin5g server
WO2021060904A1 (ko) 무선 통신 시스템에서 통신을 수행하는 방법 및 장치
WO2024025375A1 (en) Method and apparatus for authenticating an attack of false base station in a wireless communication system
WO2011155772A2 (ko) 팸토 시스템에서 네트워크 초기 접속 방법 및 장치
WO2014171711A1 (ko) 이동 통신에서 가입 사업자 변경 제한 정책을 지원하는 정책 적용 방법 및 장치
WO2023140704A1 (ko) 무선 통신 시스템에서 단말 라우팅 선택 정책을 매핑하는 방법 및 장치
WO2023132650A1 (ko) 제어 평면을 이용하여 크리덴셜을 단말에 프로비저닝 시 종단 보안 형성을 위한 방법 및 장치
WO2023003379A1 (en) Method and apparatus for authenticating and authorizing network function in mobile communication system
WO2022177353A1 (en) Method and system for handling key distribution for multicast and broadcast services in wireless network
WO2024025391A1 (en) Method and device for provision key for base station verification in wireless communication system
WO2024151076A1 (en) Method and apparatus for protecting privacy issue for authentication and key management for applications
WO2023146265A1 (en) A method and apparatus for authentication method selection in edge network system
WO2023153785A1 (en) Method and device for performing data communication for roaming terminal in wireless communication system
WO2023014177A1 (en) Apparatus and method for verifying authenticity of a backhaul-radio link failure
WO2024147662A2 (ko) 단말 간 릴레이 통신에서 보안 수립을 지원하기 위한 방법 및 장치

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: 23737398

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023737398

Country of ref document: EP

Effective date: 20240703

NENP Non-entry into the national phase

Ref country code: DE