Authentication for non-3gpp access using digital signature

Abstract

The present disclosure relates to authentication for non-3GPP access using digital signatures. In an embodiment, a user equipment (UE) is configured to store a plurality of certificates having different digital signature algorithms, and when accessing a core network through a gateway via non-third generation partnership project (non-3GPP) access, use a first certificate of the certificates to perform authentication with the gateway by computing a first digital signature using a first digital signature algorithm of the digital signature algorithms associated with the first certificate of the certificates, receive revocation information to revoke the first certificate of the certificates in response to a security event regarding the first digital signature algorithm of the digital signature algorithms, and use a second certificate of the certificates to perform authentication with the gateway by computing a second digital signature using a second digital signature algorithm of the digital signature algorithms associated with the second certificate of the certificates in response to the revocation information.

Description

Technical Field

[0001] This disclosure relates to the field of communication systems, and more specifically to next-generation networks. Background Technology

[0002] Next-generation networks, such as fifth-generation (5G) and above (e.g., sixth-generation (6G)), represent the next major phase of mobile telecommunications standards after fourth-generation (4G) standards. Compared to 4G networks, next-generation networks can be enhanced in terms of radio access and network architecture to deliver faster data rates and higher reliability. As mobile networks are widely deployed across countries and the world, communications can be intercepted or subjected to other types of attacks. To ensure security and privacy, the 3rd Generation Partnership Project (3GPP) and other organizations have proposed security mechanisms for mobile networks, as well as security processes to be performed within them. Due to the importance of security in 5G systems and above, continued development of improved security mechanisms is expected. Summary of the Invention

[0003] This document describes an enhancement to the security mechanism for non-3GPP access using digital signatures for authentication. In summary, User Equipment (UE) can access the core network via non-3GPP access through interoperability or gateway functions (generally referred to herein as gateways). When establishing a non-3GPP access connection or channel, the UE and gateway perform an authentication process for mutual authentication. For the authentication process, the UE can prove its identity to the gateway by signing a data block using a Digital Signature Algorithm (DSA) associated with a public key certificate or digital certificate. However, digital signature algorithms can be vulnerable to attacks, such as those using quantum computers. In the embodiments described herein, the UE can (e.g., automatically) switch to a different digital signature algorithm associated with a different public key certificate, such as when a security event is detected. For example, the core network can provide the UE with information, for example, to revoke the primary certificate and / or switch to an alternative or secondary certificate with a different digital signature algorithm. One technical advantage is that the UE is notified of potential vulnerabilities in non-3GPP access and can switch to a different certificate / digital signature algorithm for authentication. This significantly improves security in the network.

[0004] In one embodiment (also referred to as an aspect), an apparatus implemented as a user equipment (UE) includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the UE to at least: store a plurality of certificates having different digital signature algorithms; and when accessing a core network via a gateway through a non-3GPP access: use the first certificate in the certificates to perform authentication with the gateway by calculating a first digital signature using a first digital signature algorithm associated with a first certificate in the certificates; receive revocation information to revoke the first certificate in the certificates in response to a security event concerning the first digital signature algorithm; and use the second certificate in the certificates to perform authentication with the gateway by calculating a second digital signature using a second digital signature algorithm associated with a second certificate in the certificates in response to the revocation information.

[0005] In one embodiment, a method includes: storing multiple certificates with different digital signature algorithms in a user equipment (UE) configured to access a core network; and when accessing the core network via a gateway through a non-3GPP access: using the first certificate in the certificate to perform authentication with the gateway by calculating a first digital signature using a first digital signature algorithm associated with a first certificate in the certificate; receiving revocation information to revoke the first certificate in the certificate in response to a security event concerning the first digital signature algorithm; and using the second certificate in the certificate to perform authentication with the gateway by calculating a second digital signature using a second digital signature algorithm associated with a second certificate in the certificate in response to the revocation information.

[0006] In one embodiment, an apparatus implemented as a user equipment (UE) includes: components for storing a plurality of certificates having different digital signature algorithms; and, when accessing a core network via a gateway through a non-3GPP access point: components for performing authentication with the gateway using the first certificate by calculating a first digital signature using a first digital signature algorithm associated with a first certificate in the digital signature algorithms; components for receiving revocation information to revoke the first certificate in the digital signature algorithms in response to a security event concerning the first digital signature algorithms; and components for performing authentication with the gateway using the second certificate in the digital signature algorithms in response to the revocation information by calculating a second digital signature using a second digital signature algorithm associated with a second certificate in the digital signature algorithms.

[0007] Other embodiments may include computer-readable media, other systems or apparatus, or other methods or components as described below. Furthermore, one or more embodiments as described above may be composable as described herein.

[0008] The foregoing summary provides a basic understanding of some aspects of this specification. This summary is not a comprehensive overview of the specification. It is intended neither to identify key or essential elements of the specification, nor to define any scope of any particular embodiment or claim. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that follows. Attached Figure Description

[0009] Some embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings. The same reference numerals in all the drawings denote the same elements or elements of the same type.

[0010] Figure 1 The diagram illustrates the advanced architecture of a 5G system.

[0011] Figure 2 The diagram illustrates the non-roaming architecture of a 5G system.

[0012] Figure 3 The diagram illustrates the NG-RAN architecture.

[0013] Figure 4 The illustration shows non-roaming and roaming scenarios for user equipment (UE).

[0014] Figure 5A The diagram illustrates a non-roaming architecture with untrusted, non-3GPP access.

[0015] Figure 5B The diagram illustrates the roaming architecture for a Local Offloading (LBO) scenario with untrusted, non-3GPP access.

[0016] Figure 6 The diagram illustrates the security mechanisms within a 5G system.

[0017] Figure 7 This is a block diagram of a system for providing security management in an illustrative embodiment.

[0018] Figure 8 This is a block diagram of the UE in an illustrative embodiment.

[0019] Figure 9 This is a block diagram illustrating a non-3GPP access via a UE in a schematic embodiment.

[0020] Figure 10 This is a diagram illustrating the block structure created by IKE SA.

[0021] Figure 11 This is a block diagram illustrating IKEv2 communication for IPsec.

[0022] Figure 12 This is a block diagram illustrating an authentication method in a schematic embodiment.

[0023] Figure 13 This is a block diagram illustrating an authentication method in another illustrative embodiment.

[0024] Figure 14 The illustration depicts a UE and / or gateway provided with multiple certificates in a schematic embodiment.

[0025] Figure 15 This is a message diagram illustrating certificate modification for non-3GPP access in a schematic embodiment.

[0026] Figure 16 This is a block diagram illustrating the dual access mode of a UE in a schematic embodiment.

[0027] Figures 17A-17C This is a flowchart illustrating a method for performing certificate modification in an illustrative embodiment.

[0028] Figures 18A-18B This is a block diagram illustrating certificate modification in a schematic embodiment.

[0029] Figures 19A-19C This is a flowchart illustrating a method for performing certificate modification in an illustrative embodiment.

[0030] Figure 20 Further details of the IKE_AUTH swap in the illustrative embodiment are shown.

[0031] Figure 21A The illustration shows the Certificate Payload (CERT) in an illustrative embodiment.

[0032] Figure 21B The illustration shows a Certificate Request Payload (CERTREQ) in an illustrative embodiment.

[0033] Figure 22 This is a diagram illustrating certificate modification in a schematic embodiment.

[0034] Figures 23A-23C This is a flowchart illustrating a method for performing certificate modification in an illustrative embodiment. Detailed Implementation

[0035] The accompanying drawings and the following description illustrate specific exemplary embodiments. Therefore, it should be understood that those skilled in the art will be able to design various arrangements, although not explicitly described or shown herein, which embody the principles of the embodiments and are included within the scope of the embodiments. Furthermore, any examples described herein are intended to aid in understanding the principles of the embodiments and should be construed as not being limited to such specifically described examples and conditions. Therefore, the inventive concept(s) are not limited to the specific embodiments or examples described below, but are limited by the claims and their equivalents.

[0036] Figure 1 The high-level architecture of a 5G system 100 is illustrated. The 5G system (5GS) 100 is a communication system (e.g., a 3GPP system) comprising an access network ((R)AN) 102 (also commonly referred to herein as RAN, 5G access network, etc.) and a core network 104 (also commonly referred to herein as 5G core network or 5GC), which communicate with user equipment (UE) 106 (e.g., a 5G-enabled UE). Together, RAN 102 and core network 104 may be referred to as a 5G network 101, a 5G mobile network, a 5G communication network, a next-generation network, etc. Although the term "5G" is used as an example herein, any next-generation or future generation network above 4G, such as 6G, is also considered. Therefore, "mobile network" and the concepts described herein apply to 5G and above.

[0037] RAN 102 provides radio or wireless connectivity to UE 106 and connects UE 106 to core network 104. RAN 102 may include Next Generation Radio Access Network (NG-RAN), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Non-3GPP Access Network (N3AN), Non-Terrestrial Access Network (NTN), and / or another type of RAN connected to core network 104. RAN 102 may support access through at least one RAN node, such as gNodeB (gNB), ng-eNodeB (ng-eNB), eNodeB (eNB), and / or Wireless Local Area Network (WLAN) access points. RAN 102 may support satellite radio access, new radio access technologies (RAT), etc. 5G access networks may also support fixed access. Core network 104 interconnects RAN 102 with data network (DN) 108. Core network 104 includes network functions (NFs) 110, which can be implemented as network elements on dedicated hardware, as chips or chipsets included in network elements, as software instances running on dedicated hardware, or as virtualized network functions (VNFs) instantiated on dedicated or general-purpose virtualization platforms (e.g., cloud infrastructure). Data network 108 can be a public or private data network outside the operator, or an internal data network within the operator (e.g., for IP Multimedia Subsystem (IMS) services). UE 106 (also referred to as a mobile terminal) includes a 5G-enabled device configured to register with core network 104 to access services. UE 106 can include end-user equipment such as mobile phones (e.g., smartphones), tablets, computers with mobile broadband adapters, etc. UE 106 can be enabled for voice services, data services, machine-to-machine (M2M) or machine-type communication (MTC) services, and / or other services.

[0038] Figure 2 The diagram illustrates the non-roaming architecture 200 of the 5G system 100. Figure 2Architecture 200 is a service-based representation, as further described in 3GPP TS 23.501 (Release 19), which is incorporated herein by reference as if fully included herein. Architecture 200 includes Network Functions (NFs) for the core network 104, and the NFs for the control plane (CP) are decoupled from the user plane (UP). The control plane of the core network 104 includes Authentication Server Function (AUSF) 210, Access and Mobility Management Function (AMF) 212, Session Management Function (SMF) 214, Policy Control Function (PCF) 216, Unified Data Management (UDM) 218, Network Slice Selection Function (NSSF) 220, and Application Function (AF) 222. The control plane of core network 104 also includes Network Exposure Function (NEF) 224, NF Repository Function (NRF) 226, Serving Communication Agent (SCP) 228, Network Slice Admission Control Function (NSACF) 230, Network Slice Specific and SNPN Authentication and Authorization Function (NSSAAF) 232, and Edge Application Server Discovery Function (EASDF) 234. The user plane of core network 104 includes one or more User Plane Functions (UPFs) 240, which communicate with data network 108. UE 106 can access the control plane and user plane of core network 104 via RAN 102.

[0039] Figure 3 The diagram illustrates the NG-RAN architecture 300. NG-RAN 302 is an example of RAN 102 as described above and includes multiple RAN nodes 304 (also referred to as NG-RAN nodes). RAN node 304 can be a gNB 306 configured to provide new radio user plane and control plane protocol termination to UE 106, or an ng-eNB 308 configured to provide E-UTRA user plane and control plane protocol termination to UE 106. gNB 306 and ng-eNB 308 are interconnected via the Xn interface. gNB 306 and ng-eNB 308 are also connected to core network 104 via the NG interface, more specifically, to AMF212 via the NG-C interface, and to UPF 240 via the NG-U interface.

[0040] Generally, UE 106 can have service availability when connected to a Home Public Land Mobile Network (HPLMN) via one or more access types (such as 3GPP access and non-3GPP access (trusted or untrusted)). UE 106 can also have service availability when connected to an Access Public Land Mobile Network (VPLMN) or a serving network via one or more access methods (again, such as 3GPP access and non-3GPP access (trusted or untrusted)).

[0041] Figure 4 The illustration depicts non-roaming and roaming scenarios for UE 106. Roaming extends the coverage of a home operator's services, allowing mobile users to access those services within another network. UE 106 of a 5G system has a home mobile network (e.g., HPLMN 402), and UE 106 can access services when located within the coverage area of ​​HPLMN 402. HPLMN 402 is the PLMN in which a mobile subscriber's profile or subscription is held. When a user roams to another network different from HPLMN 402 (referred to as the access network or serving network), the core network 104 of HPLMN 402 can interconnect or interoperate with the access network, enabling the user to access services even when roaming outside of HPLMN 402. For example, the core network 104 of HPLMN 402 can interconnect or interoperate with the core network (not shown) of VPLMN 404 (or another PLMN not shown), or with one or more non-3GPP access networks 406. Figure 4 In this context, it can be assumed that there is a service agreement or roaming agreement between the home network operator 412 of HPLMN 402 and the roaming partner 414 of VPLMN 404 and / or with other service networks.

[0042] The 5G system is designed to enable access-independent converged service availability for UE 106. UE 106 can have service availability through different access types, such as 3GPP access 420 and non-3GPP access 422. 3GPP access means that the service is available to the UE via 3GPP licensed spectrum (e.g., 5G services are available to the UE via the 5G New Radio (NR) air interface of the PLMN). Non-3GPP access means that the service is available to the UE via another type of access, such as via unlicensed spectrum radio (e.g., WLAN access (e.g., IEEE 802.11 (Wi-Fi)), fixed access, etc.). The following types of non-3GPP networks are: untrusted non-3GPP networks, trusted non-3GPP networks, and wired networks.

[0043] exist Figure 4 In this configuration, UE 106 roaming in VPLMN 404 can have connectivity to VPLMN 404 via 3GPP access 420. UE 106 roaming in a non-3GPP access network 406 can additionally or alternatively have service availability via that non-3GPP access network 406 (e.g., a WLAN access network). The non-3GPP access network is connected to the PLMN's core network. For example, the non-3GPP access network 406 is connected to the core network of VPLMN 404. When a UE is "connected" to the PLMN's core network, the UE is registered in the PLMN's AMF 212. Figure 4As illustrated, the roaming UE 106 can have service availability via at least one of 3GPP access 420 through VPLMN 404 and non-3GPP access 422 through a non-3GPP access network 406 connected to VPLMN 404.

[0044] Non-roaming UE 106 can have connectivity to HPLMN 402 via 3GPP access 420. Additionally or alternatively, non-roaming UE 106 can have service availability via a non-3GPP access network 407 (e.g., a WLAN access network) connected to the core network 104 of HPLMN 402. Therefore, UE 106 can have non-3GPP access 422 via the non-3GPP access network 407 of HPLMN 402. For UE 106, 3GPP access 420 and non-3GPP access 422 via HPLMN 404, and 3GPP access 420 and non-3GPP access 422 via HPLMN 402, can be considered different access types 418. Those skilled in the art will understand that non-3GPP access types can be further divided into trusted access, untrusted access, and wired access.

[0045] Figure 5A The diagram illustrates a non-roaming architecture with untrusted, non-3GPP access. In this architecture, UE 106 has service availability via 3GPP access 420 and (untrusted) non-3GPP access 422. The untrusted, non-3GPP access network connects to the core network via a non-3GPP interworking function (N3IWF). The N3IWF provides a secure gateway to the core network for non-3GPP access 422. Figure 5A In this case, the non-3GPP access network 407 is connected to the core network (e.g., AMF 212) of HPLMN 402 via N3IWF 520. Figure 5B The diagram illustrates a Local Offloading (LBO) roaming architecture with untrusted, non-3GPP access. In this architecture, UE 106 has service availability via 3GPP access 420 and (untrusted) non-3GPP access 422. Non-3GPP access network 406 is connected to the core network (i.e., AMF212) of VPLMN 404 via N3IWF 520 in the same PLMN (i.e., VPLMN 404) as 3GPP access 420.

[0046] There are a large number of subscribers who can access services from a carrier or home / mobile network operator that implements a mobile network including 5G System 100, such as... Figures 1-2In this context, communication between the user or subscriber (i.e., through the UE) and the mobile network is protected by security mechanisms, such as those standardized by 3GPP. Subscribers and operators expect security guarantees from these mechanisms.

[0047] Figure 6 The diagram illustrates security mechanisms 600 within the 5G system 100. One security mechanism in 600 is the master authentication and key negotiation between the network (e.g., AMF 212 / UDM 218) and UE 106. Other security mechanisms 600 are used to protect signaling between the network and UE 106. For example, security mechanism 600 is used to protect non-access stratum (NAS) signaling between AMF 212 and UE 106. Other security mechanisms 600 are used to protect access stratum (AS) communications (such as Radio Resource Control (RRC) signaling between gNB 306 and UE 106) between RAN node 304 (e.g., gNB 306) and UE 106, as well as user plane (UP) traffic (also referred to as UP data) between gNB 306 and UE 106. Within the network, security mechanism 600 can be used to protect the IP connection between gNB 306 and core network 104 (e.g., AMF 212 / UPF 240), such as Internet Protocol Security (IPSec). Another security mechanism 600 is used for roaming and interconnection security, such as protecting control plane signaling between Security Edge Protection Agent (SEPP) 610 and another network 601 (e.g., accessing a 5G network), and / or protecting user plane data between UPF 240 and other networks 601. Another security mechanism 600 can be used to protect the IP connection between gateway 620 (e.g., N3IWF 520 in the case of untrusted, non-3GPP access) and UE 106. Additional security mechanisms 600 may exist or be defined, but for the sake of brevity, they will not be discussed.

[0048] Figure 7 This is a block diagram of a system 700 for providing security management in an illustrative embodiment. More specifically, Figure 7System 700 includes: at least one UE 106, at least one access node 704, and multiple network elements / functions 110 (i.e., first network element / function 110-1 and second network element / function 110-N). It should be understood that UE 106, access node 704, and network elements / functions 110 are configured to interact with each other to provide security management (also known as protection management). Examples of network elements / functions 110 (typically referred to as core NFs) may include, but are not limited to, AMF 212, AUSF 210, UDM 218, UPF240, etc. Access node 704 is an element / function of the access network configured to provide the UE with access to the core network 104, such as via 3GPP access or non-3GPP access. Examples of access nodes 704 are RAN node 304 (e.g., gNB 306, ng-eNB 308, eNB, etc.), gateway 620 (e.g., N3IWF 520), or non-3GPP access points, etc.

[0049] Network element / function 110-1 includes a processor 722-1 and an interface circuitry system 720-1 coupled to a memory 726-1. The processor 722-1 of network element / function 110-1 includes a security management processing module 724-1, which may be implemented at least partially in the form of software executed by the processor 722-1. The security management processing module 724-1 performs security management as described in conjunction with the following figures and other methods herein. The memory 726-1 includes a security management storage module 728-1 storing data generated or otherwise used during security management operations.

[0050] Network element / function 110-N includes a processor 722-N and an interface circuitry 720-N coupled to a memory 726-N. The processor 722-N of network element / function 110-N includes a security management processing module 724-N, which may be implemented at least partially in the form of software executed by the processor 722-N. The security management processing module 724-N performs security management as described in conjunction with the following figures and other methods herein. The memory 726-N includes a security management storage module 728-N storing data generated or otherwise used during security management operations.

[0051] The processors 722-1 and 722-N of the corresponding network elements / functions 110-1 and 110-N may include, for example, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or other types of processing devices or integrated circuits, as well as portions or combinations of such elements. Such integrated circuit devices and portions or combinations thereof are examples of the term "circuit system" as used herein. Various other arrangements of hardware and associated software or firmware may be used in implementing the illustrative embodiments.

[0052] The corresponding network element / function 110-1 and network element / function 110-N's memories 726-1 and 726-N can be used to store one or more software programs, which are executed by the corresponding processors 722-1 and 722-N to implement at least a portion of the functions described herein. For example, security management operations and other functions, as described in conjunction with the following figures or otherwise herein, can be implemented in a straightforward manner using software code executed by processors 722-1 and 722-N.

[0053] Therefore, one of the given memories 726-1 and 726-N can be considered as an example of a computer program product, or more generally referred to herein as a processor-readable storage medium having executable program code therein. Other examples of processor-readable storage media may include magnetic disks or other types of magnetic or optical media in any combination. Illustrative embodiments may include articles of manufacture containing such computer program products or other processor-readable storage media.

[0054] Memory 726-1 and Memory 726-N may more specifically include, for example, electronic random access memory (RAM) (such as static RAM (SRAM)), dynamic RAM (DRAM), or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memory such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC-RAM), or ferroelectric RAM (FRAM). As used herein, the term “memory” is intended to be interpreted broadly and may additionally or alternatively include, for example, read-only memory (ROM), disk storage, or other types of storage devices, and portions or combinations thereof.

[0055] The corresponding network element / function 110-1 and network element / function 110-N interface circuit system 720-1 and interface circuit system 720-N schematically include transceivers or other communication hardware or firmware, application programming interfaces (APIs), etc., which allow associated system elements to communicate with each other in the manner described herein.

[0056] Network element / function 110-1 is configured to communicate with network element / function 110-N via its respective interface circuitry 720-1 and interface circuitry 720-N, and vice versa. This communication involves network element / function 110-1 sending data to network element / function 110-N, and network element / function 110-N sending data to network element / function 110-1. However, in alternative embodiments, other network elements may be operatively coupled between network element / function 110-1 and 110-N. The term "data" as used herein is intended to be interpreted broadly to include any type of information that can be sent between network elements / functions (and between UE 106 and core network 104), including but not limited to messages, identifiers, keys, indicators, user data, control data, etc.

[0057] Access node 704 includes a processor 712 and an interface circuitry 710 coupled to memory 716. The processor 712 of access node 704 includes a security management processing module 714, which may be implemented at least partially as software executed by the processor 712. The security management processing module 714 performs security management as described in conjunction with the following figures and otherwise herein. Memory 716 includes a security management storage module 718 that stores data generated or otherwise used during security management operations. Access node 704 is configured to communicate with UE 106 and one or more network elements / functions 110 via interface circuitry 710. For example, interface circuitry 710 may be configured to communicate with UE 106 via radio communication over an air interface and may be configured to backhaul communicate with one or more network elements / functions 110 of core network 104.

[0058] It should be understood that Figure 7 The specific arrangement of the components shown is illustrative, and various alternative configurations can be used in other embodiments. For example, any given network element / function can be configured to include additional or alternative components and support other communication protocols.

[0059] Other system components can also be configured to include components such as processors, memory, and network interfaces. These components do not need to be implemented on separate, independent processing platforms, but instead can, for example, represent different functional parts of a single general-purpose processing platform.

[0060] Figure 8This is a block diagram of UE 106 in an illustrative embodiment. Functionally, UE 106 consists of at least two parts: a mobile device (ME) 800 and a Universal Subscriber Identity Module (USIM) 860. ME 800 includes a radio interface component 802, one or more processors 804, and a memory 806, and may also include a user interface component 808. UE 106 may also include a battery 810. The radio interface component 802 is a hardware component or part representing the local radio resources of UE 106, such as a radio frequency (RF) unit 820 (e.g., one or more wireless transceivers) and one or more antennas 822. The radio interface component 802 can be configured for 5G New Radio (NR), Long Term Evolution (LTE), WiFi, Bluetooth, etc. The processor 804 represents the internal circuitry, logic, hardware, components, etc., that provide the functionality of UE 106. The processor 804 can be configured to execute instructions 840 for software loaded into the memory 806. Processor 804 may execute an operating system (OS) 834 for managing hardware and software resources of UE 106, and one or more application clients 835 for applications. Processor 804 may also execute a security controller 836, which includes components or parts for implementing security mechanisms within UE 106 (i.e., within ME 800), such as integrity protection mechanisms and / or encryption mechanisms. User interface component 808 is a hardware component for interacting with an end user. For example, user interface component 808 may include a display 850, a screen, a touchscreen, and / or the like (e.g., a liquid crystal display (LCD), a light-emitting diode (LED) display, etc.). User interface component 808 may include a keyboard or keypad, a tracking device (e.g., a trackball or touchpad), a speaker, a microphone, etc.

[0061] The USIM 860 is an integrated circuit that provides security and integrity functions for the UE 106. The USIM 860 includes or is provided with a subscription profile associated with a subscriber's subscription. The subscription profile may include various information, such as subscription credentials (e.g., a subscription permanent identifier (SUPI)) used to uniquely identify the subscription and to mutually authenticate the UE 106 and the network.

[0062] UE 106 may include Figure 8 Various other components not specifically illustrated.

[0063] In an embodiment, UE 106 may access or connect to core network 104 via non-3GPP access 422, through a function referred to herein as gateway 620 (e.g., N3IWF 520). Figure 9This diagram illustrates a block diagram of non-3GPP access 422 via UE 106 in an illustrative embodiment. When UE 106 only has non-3GPP access 422 (i.e., no 3GPP access), the access can be referred to as a single (non-3GPP) access mode 902. As described above, non-3GPP access 422 can include trusted non-3GPP access 910 or untrusted non-3GPP access 920. In trusted non-3GPP access 910, communication between UE 106 and core network 104 is secure. A trusted non-3GPP access network 912 (e.g., including a trusted non-3GPP access point 914 (TNAP)) is connected to core network 104 via a trusted non-3GPP gateway function 916 (TNGF), which can generally be referred to as gateway 620. TNGF 916 connects the control plane to AMF 212 via the N2 interface and the user plane to UPF 240 via the N3 interface. For the trusted non-3GPP access network 912, UE 106 establishes a secure connection to the core network 104 via the trusted non-3GPP access of TNGF 916. UE 106 uses 3GPP-based authentication to connect to the non-3GPP access and establishes an IPsec Security Association (SA) with TNGF 916 to register with the core network 104 through a registration process. After registration, UE 106 uses the N1 reference point to support NAS signaling with the core network 104.

[0064] In the untrusted, non-3GPP access network 920, communication between UE 106 and core network 104 is not trusted as secure. To protect communication between UE 106 and core network 104 via the untrusted, non-3GPP access network 922 (e.g., including non-3GPP access point 924), UE 106 establishes a secure connection to core network 104 via N3IWF 520 (also commonly referred to as gateway 620). UE 106 performs registration with core network 104 during the Internet Key Exchange (IKE) SA establishment process. After registration, UE 106 uses reference point N1 to support NAS signaling with core network 104. N3IWF 520 connects the control plane to AMF 212 via interface N2 and the user plane to UPF 240 via interface N3.

[0065] Figure 10This diagram illustrates the block diagram of an IKE SA establishment. The security mechanism 600 protecting the IP connection can use IPsec 1004 between peer 1002 (i.e., peer 1002-1 and peer 1002-2), which can also be referred to as an endpoint or IPsec endpoint. IPsec 1004 is a suite of secure network protocols that protects communication across Internet Protocol (IP) networks, such as Virtual Private Networks (VPNs). IPsec 1004 supports network-level peer authentication, data source authentication, data integrity (integrity protection), data confidentiality (encryption), and prevention of replay attacks. The Internet Key Exchange (IKE) protocol is a component of IPsec 1004, used to perform mutual authentication and to establish and maintain Security Associations (SAs). IKE protocol version 2 (IKEv2) 1006 is described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 7296, which is incorporated herein by reference as if fully included herein. IKEv2 1006 performs mutual authentication between the two participating parties (or peers 1002) and establishes an IKE SA 1010 containing shared secret information used to establish the Authentication Header (AH) SA 1012 and the Encapsulated Secure Payload (ESP) SA 1014. The AH protects the data within IP packets from tampering, ensuring the integrity of transmitted data. The ESP encrypts the payload of the IP packets and provides authentication, replay protection, and integrity checks. The AH SA 1012 and ESP SA 1014 established through IKE SA 1010 are referred to as sub-SA 1016.

[0066] Figure 11 This diagram illustrates a block diagram of IKEv2 communication 1100 for IPsec. IKEv2 communication 1100 includes message pairs (i.e., requests and responses) between an IKE initiator (also referred to as IKE initiator peer 1002-1 or generally referred to as the initiator) and an IKE responder (also referred to as IKE responder peer 1002-2 or generally referred to as the responder). This message pair is referred to as an "exchange" or "request / response pair". Examples of initiators and responders may include UE 106, access node 704 (e.g., RAN node 304, N3IWF 520, etc.), core NF 110 (e.g., AMF 212, UPF 240, etc.), etc.

[0067] The first exchange establishing IKE SA 1010 is called the IKE_SA_INIT exchange 1110, which is also commonly referred to herein as the initial exchange. IKE_SA_INIT exchange 1110 includes: an IKE_SA_INIT request 1112 from IKE initiating peer 1002-1, and an IKE_SA_INIT response 1114 from IKE responding peer 1002-2. IKE_SA_INIT exchange 1110 negotiates the security parameters for IKE SA 1010, sending a random number and a Diffie-Hellman (DH) value / key (or any variant, such as Elliptic Curve Diffie-Hellman (ECDH)). Subsequent exchanges of messages are called the IKE_AUTH exchange 1130, which is also commonly referred to herein as the authentication exchange. The IKE_AUTH exchange 1130 includes: an IKE_AUTH request 1132 from IKE initiating peer 1002-1, and an IKE_AUTH response 1134 from IKE responding peer 1002-2. The IKE_AUTH exchange 1130 sends identifiers, proves knowledge of the keys corresponding to the two identifiers, and establishes AH SA 1012 and ESPSA 1014. Parts of the message in the IKE_AUTH exchange 1130 are encrypted and protected for integrity using the keys established through the IKE_SA_INIT exchange 1110 (or other exchanges), thus hiding the identifiers from eavesdroppers and authenticating the fields in the message.

[0068] The IKE intermediate exchange 1120 procedure is defined between the IKE_SA_INIT exchange 1110 and the IKE_AUTH exchange 1130, and is also commonly referred to herein as the intermediate exchange. The IKE intermediate exchange 1120 can be used to transmit large amounts of data during the establishment of an IKE SA. The IKE intermediate exchange 1120 includes an IKE_INTERMEDIATE request 1122 from the IKE initiating peer 1002-1 and an IKE_INTERMEDIATE response 1124 from the IKE responding peer 1002-2. An example where this is necessary is the use of a quantum-resistant key exchange method for IKE SA establishment. The IKE intermediate exchange 1120 makes it possible to utilize existing IKE fragmentation mechanisms (which are not available in the initial IKEv2 exchange), thus helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKE SA 1010 is established.

[0069] Figure 12This is a block diagram illustrating an authentication method in an illustrative embodiment. In this example, IPsec 1004 is used to establish or build a non-3GPP access connection 1202 between UE 106 and gateway 620. As part of establishing the non-3GPP access connection 1202, UE 106 and gateway 620 perform mutual authentication (e.g., IKEv2 1006) and establish a security association. UE 106 and gateway 620 negotiate an authentication method 1206 for mutual authentication. Authentication method 1206 ensures that the data originates from a known or trusted source and has not been tampered with. For example, UE 106 and gateway 620 may use a public key certificate (also known as a digital certificate) along with a digital signature for authentication method 1206.

[0070] like Figure 12 As illustrated, UE 106 is configured with or provided with a public key certificate 1210. For an entity, the public key certificate 1210 (often referred to as a certificate) binds an identifier to the public key 1218 and is signed by a Certificate Authority (CA) or self-signed. Certificate 1210 can have a format as defined in the X.509 standard, which includes a data portion and a signature portion. The data portion may include the name or identifier of the entity possessing the public key 1218, the name or identifier of the entity issuing the certificate, the validity period of the certificate, public key information (i.e., public key 1218 and the public key algorithm), certificate signature, etc.

[0071] As an example, a CA certificate can be issued by a CA. The highest level of self-signed CA certificate is sometimes referred to as a root CA certificate. An entity wanting a signed certificate requests a signed certificate from a CA using a protocol such as a Certificate Signing Request (CSR), Simple Certificate Registration Protocol (SCEP), Certificate Management Protocol (CMP), etc. The entity generates a key pair including a private key (1216) and a public key (1218). The CSR contains information identifying the applicant and the public key (1218) used to verify the signature of the CSR, as well as a unique Distinguished Name (DN) for the entity. The CSR can be attached with other credentials or proof of identity required by the CA. The CSR will be verified using a Registration Authority (RA), and then the CA will issue a certificate, thus binding the public key (1218) with the DN.

[0072] For authentication method 1206, UE 106 may send or provide authentication request 1214 to gateway 602. UE 106 performs authentication with gateway 602 using certificate 1210. UE 106 may provide certificate 1210 to gateway 620 to prove its identity in authentication request 1214 (e.g., IKE_AUTH request 1132). UE 106 may also sign data blocks to calculate digital signature 1212 based on Digital Signature Algorithm (DSA) 1230 associated with certificate 1210 and its private key 1216 to prove its identity. For example, UE 106 may sign certain bytes of the payload of IKE_AUTH request 1132 in IKE_AUTH exchange 1130, as further described in section 2.15 of RFC 7296. Digital signature 1212 is an authentication mechanism that enables the creator of the message to attach code that acts as a signature. Digital Signature Algorithm (DSA) 1230 is an encryption algorithm used to generate digital signatures 1212, such as for verifying the sender of digital messages and preventing message tampering.

[0073] In the example, UE 106 calculates a digital signature 1212 to generate a hash value by applying the digital signature algorithm 1230 associated with certificate 1210 to a data block (e.g., from authentication request 1214), and encrypts the hash value using private key 1216 to form digital signature 1212. UE 106 can then append digital signature 1212 to authentication request 1214, optionally along with certificate 1210. Gateway 602 decrypts digital signature 1212 using public key 1218 associated with certificate 1210 to identify the hash value. This ensures authenticity because only UE 106 has private key 1216, so only UE 106 can encrypt using private key 1216, which can then be decrypted by UE 106's public key 1218. Gateway 620 applies the digital signature algorithm 1230 associated with certificate 1210 to the same data block (e.g., from authentication request 1214) to generate a hash value and compares the calculated hash value with the decrypted hash value. If the hash value matches, gateway 620 verifies digital signature 1212 and authenticates UE106.

[0074] Both parties (e.g., UE 106 and gateway 620) can independently choose and use their preferred authentication method 1206, and the authentication methods between the two parties can even be different. Figure 13This is a block diagram illustrating an authentication method in another illustrative embodiment. In this example, gateway 620 may send or provide an authentication response 1316 (e.g., an IKE_AUTH response 1134) to UE 106. Gateway 620 may provide certificate 1210 to UE 106 to prove its identity in the authentication response 1316. It should be noted that although the same reference numerals are used for the certificate, UE 106 and gateway 620 obtain different public key certificates. Gateway 620 may also sign data blocks to compute a digital signature 1212 based on a digital signature algorithm (DSA) 1230 associated with certificate 1210 and its private key 1216 to prove its identity. For example, gateway 620 is capable of signing certain bytes of the payload of IKE_AUTH response 1134 in IKE_AUTH exchange 1130, as further described in section 2.15 of RFC 7296. UE 106 is able to verify digital signature 1212 and authenticate gateway 620 in a similar manner to that described above.

[0075] Figure 14The illustration depicts a UE 106 and / or gateway 620 provided with multiple certificates 1210 in an illustrative embodiment. In this embodiment, for example, the UE 106 is provided with multiple certificates 1210 (e.g., 1210-1, 1210-2, etc.). Each certificate 1210 includes a public key 1218 (e.g., 1218-1, 1218-2, etc.) and an associated digital signature algorithm 1230. For example, certificate 1210-1 has an associated digital signature algorithm 1230-1, certificate 1210-2 has an associated digital signature algorithm 1230-2, and so on. It is assumed that the digital signature algorithm 1230 is different between the different certificates 1210. In embodiments, digital signature algorithm 1230 may include conventional digital signature algorithms 1410 (DSA), such as the Rivest-Shamir-Adleman (RSA) algorithm 1412, digital signature algorithm (DSA) 1414, and elliptic curve digital signature algorithm (ECDSA) 1416, although other algorithms are also considered herein. The existence of cryptographically correlated quantum computers (CRQCs) can render state-of-the-art conventional public-key algorithms obsolete and insecure. This is because the assumptions about the unsolvable mathematical problems upon which these algorithms rely (which today provide a robust level of security) no longer apply in the presence of CRQCs. As described herein, digital signature algorithm 1230 may include post-quantum computing (PQC) digital signature algorithm 1420. PQC digital signature algorithm 1420 is a public-key algorithm designed to resist CRQCs and classical computers. PQC digital signature algorithm 1420 may include modular lattice-based digital signature algorithm 1422 (ML-DSA) and stateless hash-based digital signature algorithm 1424 (SLH-DSA), although other algorithms are also considered in this paper. ML-DSA 1422 and SLH-DSA 1424 are quantum-resistant digital signature schemes standardized by the PQC project of the National Institute of Standards and Technology (NIST).

[0076] In one embodiment, priority 1440 (or priority designation) can be assigned to one or more certificates in certificate 1210. For example, primary certificate 1442 (or primary designation), secondary certificate 1444 (or secondary designation), etc., can be assigned in certificate 1210, such as through core network 104, operator management, etc. Accordingly, priority 1440 is assigned to the associated digital signature algorithm 1230. For example, primary certificate 1442 has primary digital signature algorithm 1230-1, secondary certificate 1444 has secondary digital signature algorithm 1230-2, etc. Priority 1440 can be pre-configured in UE 106, gateway 620, etc., can be dynamically configured or provided by core network 104, or can be configured or provided in other ways.

[0077] Traditional digital signature algorithms 1410 and / or PQC digital signature algorithms 1420 may be susceptible to errors or vulnerabilities. For example, although PQC digital signature algorithm 1420 is considered quantum-resistant, it may be vulnerable to unknown attacks from quantum computers, sometimes referred to as cryptographic zero-day attacks. As described herein, automated solutions are provided for, for example, switching to different certificates 1210 in response to security incidents.

[0078] Figure 15 The illustration depicts certificate modification 1500 for non-3GPP access 422 in an illustrative embodiment. Certificate modification 1500 is performed dynamically or automatically in response to triggering conditions (such as security threats, attacks, events, etc., commonly referred to as security event 1508). In this embodiment, it is assumed that UE 106 and gateway 620 perform authentication to establish a non-3GPP access connection 1202. For example, as... Figure 12As shown, authentication is performed using a certificate 1210 selected from multiple certificates (e.g., primary certificate 1442). A digital signature 1212 generated, calculated, or derived based on primary certificate 1442 may be referred to herein as the "first" digital signature 1212. When a security event 1508 concerning the current certificate 1210 (e.g., concerning the digital signature algorithm 1230 associated with the current certificate 1210) is detected or occurs, core network 104 may initiate or trigger a revocation process 1520 to dynamically change or modify the certificate 1210 used for authentication. For the revocation process 1520, core network 104 is configured to provide revocation information 1522 to UE 106 and / or gateway 620. In response to the revocation information 1522, UE 106 initiates or triggers the revocation process 1520. For the revocation process 1520 at UE 106, UE 106 switches to a different or alternative certificate 1210 already provided on UE 106. For example, UE 106 can switch from primary certificate 1442 to secondary certificate 1444. UE 106 can disconnect the currently established or set up non-3GPP access connection 1202 between UE 106 and gateway 620, and attempt to reconnect to the core network 104 through the new non-3GPP access connection 1202. For the establishment or set up of the new non-3GPP access connection 1202, UE 106 and gateway 620 can negotiate an authentication method 1206 for mutual authentication, whereby UE 106 uses a different certificate 1210 (i.e., secondary certificate 1444) to perform authentication with gateway 602. For example, suppose the primary certificate 1442 used by UE 106 is associated with ML-DSA 1422. When a security event 1508 concerning ML-DSA 1422 is detected (e.g., in the network), the revocation procedure 1520 can switch to the secondary certificate 1444 associated with SLH-DSA 1424. The digital signatures 1212 generated, calculated, or derived based on the secondary certificate 1444 may be referred to herein as the “second” digital signature 1212. One technical advantage is that authentication method 1206 can handle attacks (such as zero-day attacks) by dynamically switching certificates 1210.

[0079] It should be noted that although some embodiments or examples may indicate that UE 106 is the initiator and gateway 620 is the responder, similar concepts apply when gateway 620 is the initiator and UE 106 is the responder.

[0080] In the embodiments described herein, certificate modification 1500 can be performed on UE 106 in single access mode 902 (i.e., non-3GPP access only 422) (such as in Figure 9 Triggered when operating in ), or dual access mode (i.e., 3GPP access 420 and non-3GPP access 422). Figure 16This diagram illustrates a dual access mode 1602 for UE 106 in an illustrative embodiment. In this embodiment, UE 106 accesses or connects to core network 104 via an untrusted non-3GPP access network 922. UE 106 also accesses or connects to core network 104 via a 3GPP access network 1612, such as NG-RAN 302 including one or more RAN nodes 304 (e.g., gNB 306). However, it should be understood that UE 106 can also access or connect to core network 104 via a trusted non-3GPP access network.

[0081] Figures 17A-17C The illustration shows a flowchart of method 1700 / 1730 / 1760 for performing certificate modification 1500 in an illustrative embodiment. Figures 17A-17C The steps of methods 1700 / 1730 / 1760 are described accordingly with reference to UE 106, gateway 620, and core network 104 or core NF 110 (e.g., AUSF 210, UDM 218, AMF 212, etc.), although it should be understood that the methods can be performed in other devices, components, functions, systems, etc. The steps in the flowcharts described herein are not exhaustive and may include other steps not shown, and the steps may be performed in an alternative order.

[0082] exist Figure 17A In this process, UE 106 stores multiple certificates 1210 (step 1702), as described above. When accessing the core network 104 via non-3GPP access 422, UE 106 uses one of the certificates 1210 to perform authentication with gateway 620 (step 1704). For example, when establishing a security association with gateway 620, UE 106 can select or identify a primary certificate 1442. UE 106 can use the primary certificate 1442 to authenticate gateway 620 (i.e., UE 106 uses the primary certificate 1442 to authenticate its identity to gateway 620).

[0083] exist Figure 17BIn this process, gateway 620 stores multiple certificates 1210 (step 1732), as described above. Gateway 620 uses one of the certificates 1210 to perform authentication with UE 106 (step 1734). For example, when establishing a security association with UE 106, gateway 620 can select or identify a master certificate 1442. Gateway 620 can use master certificate 1442 to authenticate UE 106 (i.e., gateway 620 uses master certificate 1442 to authenticate the identity of UE 106). Assuming successful authentication, a non-3GPP access connection 1202 is established or set up between UE 106 and gateway 620. Therefore, UE 106 can exchange Mobile Origin (MO) transports or traffic with gateway 620 through non-3GPP access connection 1202, and gateway 620 can exchange Mobile Termination (MT) transports or traffic with UE 106 through non-3GPP access connection 1202. It should be noted that UE 106 and gateway 620 can perform re-authentication periodically or in response to triggering conditions using master certificate 1442.

[0084] exist Figure 17C In this process, core network 104 (i.e., via core NF 110) detects a security event 1508 (step 1762) concerning the current certificate 1210, such as the master certificate 1442. For example, core network 104 may detect a weakness or indication that the digital signature algorithm 1230 associated with the current certificate 1210 has been compromised. In response to security event 1508, core network 104 initiates or triggers revocation process 1520 (step 1764). For revocation process 1520, core network 104 issues, provides, or sends revocation information 1522 to UE 106 (step 1766). Revocation information 1522 includes any data, message, command, etc., indicating the revocation of the current certificate 1210, or otherwise indicating that the use of the current certificate 1210 is revoked or should be stopped. In other words, revocation information 1522 may indicate to UE 106 that the use of the current certificate 1210 is cancelled, revoked, suspended, terminated, etc., and that any authentication performed based on certificate 1210 is no longer valid. Core network 104 may also issue, provide, or send revocation information 1522 to gateway 620 (step 1772). The format and / or content of the revocation information 1522 sent to UE 106 and gateway 620 may vary depending on the corresponding interface, reference point, procedure used, access type of UE 106, etc.

[0085] exist Figure 17AIn this embodiment, UE 106 receives revocation information 1522 from core network 104 (step 1706). In this embodiment, UE 106 may receive revocation information 1522 from core network 104 via 3GPP access 420 (optional step 1708). For example, when UE 106 operates in dual access mode 1602, UE 106 has already accessed or connected to core network 104 via 3GPP access 420 to receive revocation information 1522. When UE 106 operates in single access mode 902 (i.e., non-3GPP access only), UE 106 may receive revocation information 1522 (or a portion thereof) from core network 104 via non-3GPP access 422 (optional step 1714). However, since non-3GPP access 422 may be considered vulnerable, core network 104 may restrict the revocation information 1522 provided via non-3GPP access 422 (e.g., restricting revocation information 1522 to an indication that the current certificate 1210 has been revoked). Core network 104 may provide UE 106 with an instruction (e.g., a paging message) to connect via 3GPP access 420 to receive additional revocation information 1522 (e.g., a switch to a secondary certificate 1444). In response, UE 106 may connect to core network 104 via 3GPP access 420 to receive revocation information 1522 (e.g., additional revocation information 1522).

[0086] In this embodiment, the core network 104 can access 420 via 3GPP through the UE parameter update (UPU) process. Figure 17C In optional step 1768, a withdrawal message 1522 is sent to UE 106, such as from UDM 218. Therefore, UE 106 can access 420 via the 3GPP access via the UPU procedure. Figure 17A (Optional step 1710) Receive revocation information 1522 from core network 104. In another embodiment, core network 104 may receive revocation information 1522 via 3GPP access 420 through a NAS process. Figure 17C In optional step 1770, a withdrawal message 1522 is sent to UE 106, such as from AMF 212. Therefore, UE 106 can access 420 via 3GPP through the NAS procedure. Figure 17A (Optional step 1712) Receive revocation information 1522 from core network 104.

[0087] In response to withdrawal information 1522, UE 106 initiates or triggers withdrawal procedure 1520. Figure 17A Step 1716). For the revocation process 1520, UE 106 switches to a different certificate 1210 (…). Figure 17A(Step 1718). For example, UE 106 can switch from primary certificate 1442 to secondary certificate 1444. In an embodiment, secondary certificate 1444 may be pre-configured or pre-provided in UE 106, and UE 106 may automatically switch to secondary certificate 1444 in response to revocation information 1522. In an embodiment, revocation information 1522 may include an indicator of secondary certificate 1444, and UE 106 may switch to secondary certificate 1444 in response to the indication provided in revocation information 1522. In an embodiment, UE 106 may reconnect to core network 104 via non-3GPP access 422 (see step 1718). Figure 17A Step 1720). For example, UE 106 may disconnect from the current non-3GPP access connection 1202 of gateway 620 and attempt to reconnect to gateway 620 via non-3GPP access 422 to establish or set up a new non-3GPP access connection 1202. When reconnecting, UE 106 performs authentication with gateway 620 using a different certificate 1210 (i.e., secondary certificate 1444). Figure 17A Step 1722).

[0088] exist Figure 17B In this process, gateway 620 can receive revocation information 1522 from core network 104 (step 1736). In response to revocation information 1522, gateway 620 can initiate or trigger revocation process 1520 (…). Figure 17B Step 1738). For the revocation process 1520, gateway 620 can switch to a different certificate 1210 (…). Figure 17B (Step 1740), the certificate 1210 is the same as the certificate 1210 currently used by UE 106. For example, gateway 620 can switch from primary certificate 1442 to secondary certificate 1444. Gateway 620 can reconnect to UE 106 (see step 1740). Figure 17B Optional step 1742). For example, gateway 620 may disconnect from the current non-3GPP access connection 1202 and attempt to reconnect to UE 106 via the new non-3GPP access connection 1202. Upon reconnection, gateway 620 uses a different certificate 1210 (i.e., secondary certificate 1444) to perform authentication with UE 106. Figure 17B Step 1744).

[0089] The following examples illustrate another instance of certificate modification 1500 when UE 106 is in dual access mode.

[0090] Figures 18A-18B This is a schematic diagram illustrating certificate modification 1500 in an exemplary embodiment. Figures 19A-19C The illustration shows a flowchart of the method 1900 / 1930 / 1960 for performing certificate modification 1500 in an illustrative embodiment. Figures 19A-19C The steps of methods 1900 / 1930 / 1960 will be described with reference to core network 104 or core NF 110 (e.g., AUSF210, UDM 218, AMF 212, etc.), UE 106, and gateway 620, although it should be understood that the methods may be performed in other devices, components, functions, systems, etc.

[0091] exist Figures 18A-18B In this context, one assumption is that UE 106 supports multiple certificates 1210, each associated with a different digital signature algorithm 1230, such as... Figure 14 As illustrated in the figure. Another assumption for this embodiment is that UE 106 has dual access (i.e., 3GPP access 420 and non-3GPP access 422). Therefore, UE 106 is authenticated via 3GPP access 420 and connected to core network 104. In this embodiment, core network 104 (via core NF 110) provides or configures multiple certificates 1210 for UE 106 for authentication via non-3GPP access 422. Figure 19A (Step 1902). To provide UE 106, core network 104 may send, transmit, or provide configuration information 1802 (also referred to as control information, certificate information, or provision information) to UE 106. This configuration information 1802 indicates multiple certificates 1210, as well as possible other information or parameters. For example, core NF 110 may determine or select at least a primary certificate 1442 and a secondary certificate 1444 for UE 106 to use in authentication method 1206 for non-3GPP access 422. For example, core NF 110 may select the certificate 1210 associated with ML-DSA 1422 as the primary certificate 1442, and the certificate 1210 associated with SLH-DSA 1424 as the secondary certificate 1444. Core NF 110 is capable of configuring or providing at least the primary certificate 1442 and the secondary certificate 1444 for UE 106.

[0092] Since UE 106 connects via 3GPP access 420, core network 104 can configure or provide UE 106 through a 3GPP access procedure or mechanism. In this embodiment, core network 104 can configure or provide UE 106 via 3GPP access 420 using UPU procedure 1804 (see...). Figure 19A(Optional step 1904). UE Parameter Update (UPU) is a process between the UE and the home network. The UE Parameter Update process enables the home network to update one or more configuration parameters (i.e., UE parameters) using control plane signaling on UE 106 and / or USIM 860. For example, UDM 218 may decide to perform a UE Parameter Update at any time after UE 106 has been successfully authenticated and registered to core network 104, as described in 3GPP TS 33.501 (Release 19), which is incorporated herein by reference as if fully included herein. UPU process 1804 can be enhanced to support certificate configuration at UE 106, such as enhanced UPU information containing or providing certificate data, UPU data, UPU transparent containers, information elements (IEs), etc.

[0093] In other embodiments, core network 104 may configure or provide UE 106 via over-the-air (OTA) mechanism through 3GPP access 420, through non-3GPP access procedures or mechanisms, etc. One technical advantage is that core network 104 can provide UE 106 with multiple certificates 1210.

[0094] exist Figure 19B In this context, UE 106 receives configuration information 1802 from core network 104 (i.e., core NF 110) for use with non-3GPP access 422. This configuration information indicates multiple certificates 1210 (e.g., at least primary certificate 1442 and secondary certificate 1444) (see [link to documentation]). Figure 19B (Step 1932). UE 106 updates its stored parameters based on the received configuration information 1802. Therefore, UE 106 stores multiple certificates 1210 as described above. In an embodiment, UE 106 may receive configuration information 1802 via UPU procedure 1804 (see step 1932). Figure 19B (Optional step 1934). In other embodiments, UE 106 may receive configuration information 1802 via an OTA mechanism, a non-3GPP access procedure or mechanism, etc.

[0095] exist Figures 18A-18B In this example, UE 106 is authenticated and connected to core network 104 via untrusted non-3GPP access network 922. In this example, gateway 620, as discussed above, may include N3IWF 520. In embodiments, core network 104 may configure or provide N3IWF 520 with multiple certificates 1210 for non-3GPP access 422 by UE 106 (see [link to documentation]). Figure 19A(Step 1906). To provide N3IWF 520, core network 104 may send, transmit, or provide configuration information 1812 to N3IWF 520, which indicates a primary certificate 1442 or multiple certificates 1210, as well as possible other information or parameters. For example, configuration information 1812 may at least indicate a primary certificate 1442 and a secondary certificate 1444 for non-3GPP access 422 through UE 106.

[0096] exist Figure 19C In this configuration, the N3IWF 520 receives configuration information 1812 from the core network 104 (i.e., core NF 110) for non-3GPP access 422. This configuration information indicates one or more certificates 1210 (e.g., at least a primary certificate 1442 and a secondary certificate 1444) (see [link to documentation]). Figure 19C (Step 1962). The N3IWF 520 updates its stored parameters based on the received configuration information 1812. Therefore, the N3IWF 520 can store multiple certificates 1210 as described above.

[0097] exist Figures 18A-18B In the process, when UE 106 accesses the core network 104 via non-3GPP access 422, it uses master certificate 1442 to authenticate with N3IWF 520 (i.e., UE 106 uses master certificate 1442 to authenticate its identity with N3IWF 520), such as Figure 19B As shown in step 1936. Similarly, the N3IWF 520 uses master certificate 1442 to authenticate UE 106 (i.e., the N3IWF 520 uses master certificate 1442 to authenticate the identity of UE 106), as... Figure 19C As shown in step 1964. When UE 106 and N3IWF 520 negotiate authentication method 1206, UE 106 and N3IWF 520 can agree on signature authentication using digital signature 1212. Therefore, UE 106 can compute digital signature 1212 by applying digital signature algorithm 1230 associated with master certificate 1442 to a data block (e.g., from authentication request 1214). In turn, N3IWF 520 can verify digital signature 1212 sent by UE 106 by applying digital signature algorithm 1230 associated with master certificate 1442.

[0098] Negotiation can be performed in an authentication exchange, such as an IKE_AUTH exchange 1130. Therefore, UE 106 and N3IWF 520 can perform an IKE_AUTH exchange 1130 as described above. An IKE_AUTH exchange 1130 includes an IKE_AUTH request 1132 from UE 106 (e.g., IKE initiating peer 1002-1) and an IKE_AUTH response 1134 from N3IWF 520 (e.g., IKE responding peer 1002-2). Figure 20 Further details of the IKE_AUTH exchange 1130 in the illustrative embodiment are shown. UE 106 initiates the IKE_AUTH exchange 1130 by sending an IKE_AUTH request 1132 to N3IWF 520. The IKE_AUTH request 1132 includes a header (HDR) and a payload of the following encryption and authentication (SK): Initiator Identifier (IDi), Authentication (AUTH), Security Association (SAi2), Initiator Traffic Selector (TSi), and Responder Traffic Selector (TSr). The IKE_AUTH request 1132 may also include the following payload: Certificate (CERT) and / or Certificate Request (CERTREQ). Figure 20 The content of IKE_AUTH request 1132 shown is provided as an example, and other payloads may be included as needed.

[0099] Certificate Payload 2002 (CERT) is an optional field or payload in IKE_AUTH request 1132, which is used by the initiator (e.g., UE 106) to send its(multiple) certificates. Figure 21A The illustration shows a Certificate Payload 2002 (CERT) in an illustrative embodiment. The Certificate Data Field 2102 is of variable length and contains the actual encoding of the certificate data. Data other than the certificate can be transmitted in the Certificate Payload 2002 (CERT). In this embodiment, UE 106 can insert, populate, or transmit indications of the primary certificate 1442 and / or the secondary certificate 1444 in the Certificate Payload 2002 (CERT). The Certificate Request Payload 2004 (CERTREQ) is an optional field or payload in the IKE_AUTH request 1132 used by the initiator (e.g., UE 106) to send the trust anchor list. Figure 21BThe illustration shows a Certificate Request Payload 2004 (CERTREQ) in an illustrative embodiment. The Certificate Authority field 2104 has a variable length and contains the actual encoding of the certificate data. Data other than the certificate can be transmitted in the Certificate Request Payload 2004 (CERTREQ). In this embodiment, the UE 106 can insert, fill in, or transmit indications of the primary certificate 1442 and / or the secondary certificate 1444 in the Certificate Request Payload 2004 (CERTREQ).

[0100] Assume that after successful authentication, a non-3GPP access connection 1202 is established or set up between UE 106 and N3IWF 520. The current non-3GPP access connection 1202 is authenticated based on the master certificate 1442 and the digital signature algorithm 1230 associated with the master certificate 1442. It should be noted that UE 106 and N3IWF 520 can perform re-authentication periodically or in response to triggering conditions using the master certificate 1442.

[0101] exist Figures 18A-18B At certain points, attacks or vulnerabilities may be detected concerning the master certificate 1442 and / or the digital signature algorithm 1230 associated with the master certificate 1442. For example, core NF 110 can monitor security events 1508 concerning the master certificate 1442 and / or the digital signature algorithm 1230 associated with the master certificate 1442 (see [link to relevant documentation]). Figure 19A Step 1908). When security event 1508 is detected, core network 104 initiates or triggers revocation procedure 1520 (see step 1908). Figure 19A Step 1910). Regarding the revocation process 1520, core network 104 can revoke the master certificate 1442 (see step 1910). Figure 19A Step 1912). Core network 104 (e.g., UDM 218, AMF 212, etc.) notifies UE 106 via 3GPP access 420 to revoke primary certificate 1442 and / or switch to secondary certificate 1444. To notify UE 106, core network 104 may send, transmit, or provide revocation information 1522 to UE 106, which indicates the revocation of primary certificate 1442 and / or the switch to secondary certificate 1444, as well as any other information or parameters. In turn, UE 106 receives revocation information 1522 from core network 104 (i.e., core NF 110), which indicates the revocation of primary certificate 1442 and / or the switch to secondary certificate 1444, for use in non-3GPP access authentication (see [link to relevant documentation]). Figure 19B (Step 1938). UE 106 specifies the secondary certificate 1444 for authentication and updates its stored parameters accordingly.

[0102] exist Figure 18AIn this context, core network 104 (e.g., via UDM 218) can use UPU procedure 1804 to notify UE 106 via 3GPP access 420 (see...). Figure 19A (Optional step 1914). Therefore, UE 106 can receive revocation information 1522 via UPU procedure 1804 (see...). Figure 19B (Optional step 1940). In UPU procedure 1804, core network 104 can provide configuration update 1814, which indicates the revocation of primary certificate 1442, the switch from primary certificate 1442 to secondary certificate 1444, and / or other parameter updates. UPU procedure 1804 can be enhanced to support the revocation of certificate 1210 at UE 106, changes to certificate 1210, etc., such as enhancements to UPU information, UPU data, UPU transparent container, information element (IE), etc. For example, for UPU procedure 1804, a new IE can be defined that indicates or contains revocation information 1522 (e.g., revocation of certificate 1210 or digital signature algorithm 1230 in certificate 1210), which indicates changes to secondary certificate 1444 or a switch to secondary certificate 1444, etc.

[0103] exist Figure 18B In this context, core network 104 (e.g., via AMF 212) can use NAS procedure 1810 to notify UE 106 via 3GPP access 420 (see NAS procedure 1810). Figure 19A (Optional step 1916 in the process). Therefore, UE 106 can receive revocation information 1522 via NAS procedure 1810 (see NAS procedure 1810). Figure 19B Optional step 1942). The NAS procedure is further described in 3GPP TS 24.501 (version 19), which is incorporated herein by reference as if fully included herein. The NAS procedure 1810 can be enhanced to support the revocation of certificate 1210 at UE 106, changes to certificate 1210, such as new or modified information elements (IEs) that indicate or contain revocation information 1522 (e.g., revocation of certificate 1210 or digital signature algorithm 1230 in certificate 1210), new error reasons 1820 indicating the revocation of certificate 1210 or digital signature algorithm 1230 in certificate 1210, etc.

[0104] In response to withdrawal information 1522, UE 106 initiates or triggers withdrawal procedure 1520. Figure 19B Step 1944). For revocation procedure 1520, UE 106 switches to secondary certificate 1444 (…). Figure 19BStep 1946). In an embodiment, the secondary certificate 1444 may be pre-configured in UE 106, and in response to revocation information 1522, UE 106 may automatically switch to the secondary certificate 1444. In an embodiment, revocation information 1522 may include an indicator of the secondary certificate 1444, and in response to the indication provided in revocation information 1522, UE 106 may switch to the secondary certificate 1444. In an embodiment, in response to revocation information 1522, UE 106 may terminate existing non-3GPP access 422. For example, UE 106 may disconnect from the current non-3GPP access connection 1202 with N3IWF 520 ( Figure 19B Step 1948), and attempt to reconnect to N3IWF 520 via non-3GPP access 422 to establish or set up a new non-3GPP access connection 1202. Figure 19B Step 1950). Upon reconnection, UE 106 uses secondary certificate 1444 to perform authentication with N3IWF 520 ( Figure 19B Step 1952).

[0105] Core network 104 can also notify N3IWF 520 to revoke primary certificate 1442 and / or switch to secondary certificate 1444 (see...) Figure 19A (Optional step 1918). To notify N3IWF 520, core network 104 may send, transmit, or provide configuration update 1816 (i.e., revocation information 1522) to N3IWF 520. This configuration update 1816 indicates the revocation of primary certificate 1442 and / or the switch to secondary certificate 1444, as well as other possible information or parameters. In turn, N3IWF 520 receives configuration update 1816 from core network 104 (i.e., core NF110) for non-3GPP access 422 (see [link to relevant step]). Figure 19C Step 1966), the configuration update 1816 indicates the revocation of the primary certificate 1442 and / or the switch to the secondary certificate 1444. In response to the revocation information 1522, the N3IWF 520 initiates or triggers the revocation process 1520 ( Figure 19C Step 1968). For revocation procedure 1520, N3IWF 520 switches to secondary certificate 1444 (…). Figure 19C Step 1970). In an embodiment, in response to the revocation information 1522, N3IWF 520 can terminate the current non-3GPP access 422. For example, N3IWF 520 can disconnect from the current non-3GPP access connection 1202 of UE 106 ( Figure 19C Step 1972), and attempt to reconnect to UE 106 via non-3GPP access 422 to establish or set up a new non-3GPP access connection 1202 ( Figure 19CStep 1974). N3IWF 520 uses auxiliary certificate 1444 to perform authentication with UE 106 ( Figure 19C Step 1976).

[0106] If authentication is successful, a new non-3GPP access connection 1202 is established or set up between UE 106 and N3IWF 520. The new non-3GPP access connection 1202 will be authenticated based on the secondary certificate 1444 and the digital signature algorithm 1230 associated with the secondary certificate 1444. One technical advantage is that when the non-3GPP access connection 422 is compromised, the 3GPP access 420 can be used to switch certificates 1210 (e.g., from the primary certificate 1442 to the secondary certificate 1444). This improves network security, such as protection against zero-day attacks. Furthermore, since UE 106 is already provided with the secondary certificate 1444, the core network 104 can use a small amount of revocation information 1522 (e.g., a single packet) to notify UE 106 to switch to the secondary certificate 1444. For example, if UE 106 is provided with only a single certificate 1210, there is a significant overhead in responding to security event 1508 to switch to the new certificate 1210, such as after UE 106 receives a notification that the digital signature algorithm 1230 used in the current certificate 1210 has been compromised, it must send a CSR to obtain a signature certificate from the network.

[0107] The following examples illustrate another instance of certificate modification 1500 for UE 106 in single access mode.

[0108] Figure 22 This is a schematic diagram illustrating certificate modification 1500 in an exemplary embodiment. Figures 23A-23C The illustration shows a flowchart of the method 2300 / 2330 / 2360 for performing certificate modification 1500 in an illustrative embodiment. Figures 23A-23C The steps of methods 2300 / 2330 / 2360 will be described with reference to core network 104 or core NF 110 (e.g., AUSF 210, UDM218, AMF 212, etc.), UE 106, and gateway 620, although it should be understood that the methods can be performed in other devices, components, functions, systems, etc. Some details provided above for dual access are applicable to single access and will not be discussed further for the sake of brevity.

[0109] exist Figure 22 In this context, one assumption is that UE 106 stores multiple certificates 1210, each associated with a different digital signature algorithm 1230 (see [link to documentation]). Figure 23B Step 2332), such as Figure 14 As shown in the diagram. The N3IWF 520 also stores multiple certificates 1210 ( Figure 23C Step 2362).

[0110] exist Figure 22 In this example, UE 106 is authenticated and connected to core network 104 via untrusted non-3GPP access network 922. In this example, gateway 620, as discussed above, may include N3IWF 520. When accessing core network 104 via non-3GPP access, UE 106 authenticates with N3IWF 520 using master certificate 1442 (i.e., UE 106 authenticates its identity with N3IWF 520 using master certificate 1442), as... Figure 23B As shown in step 2334. Similarly, the N3IWF 520 uses master certificate 1442 to authenticate UE 106 (i.e., the N3IWF 520 uses master certificate 1442 to authenticate the identifier of UE 106), as shown in step 2334. Figure 23C In step 2364, when UE 106 and N3IWF 520 negotiate authentication method 1206, UE 106 and N3IWF 520 can agree on signature authentication using digital signature 1212. Therefore, UE 106 can compute digital signature 1212 by applying digital signature algorithm 1230 associated with master certificate 1442 to a data block (e.g., from authentication request 1214). In turn, N3IWF 520 can verify digital signature 1212 sent by UE 106 by applying digital signature algorithm 1230 associated with master certificate 1442.

[0111] Assuming successful authentication, a non-3GPP access connection 1202 is established or set up between UE 106 and N3IWF 520. The current non-3GPP access connection 1202 is authenticated based on the master certificate 1442 and the digital signature algorithm 1230 associated with the master certificate 1442. It should be noted that UE 106 and N3IWF 520 can perform re-authentication periodically or in response to triggering conditions using the master certificate 1442.

[0112] exist Figure 22 In certain points, attacks or vulnerabilities may be detected concerning the master certificate 1442 and / or the digital signature algorithm 1230 associated with the master certificate 1442. For example, core NF 110 can detect security events 1508 concerning the master certificate 1442 and / or the digital signature algorithm 1230 associated with the master certificate 1442 (see [link to relevant documentation]). Figure 23A Step 2302). When security event 1508 is detected, core network 104 initiates or triggers revocation procedure 1520 (see step 2302). Figure 23A Step 2304). Regarding the revocation process 1520, core network 104 can revoke the primary certificate 1442 (see step 2304). Figure 23AStep 2306). Core network 104 (e.g., UDM 218, AMF 212, etc.) can notify UE 106 to revoke the primary certificate 1442 via non-3GPP access 422. To notify UE 106, core network 104 can send, transmit, or provide revocation information 1522 to UE 106, which indicates the revocation of the primary certificate 1442 and / or the switch to the secondary certificate 1444, as well as other possible information or parameters. Since non-3GPP access 422 may be considered compromised, core network 104 can send limited revocation information 1522 to UE 106 via non-3GPP access 422. Therefore, core network 104 can send, transmit, or provide notification 2201 to UE 106 via non-3GPP access 422 to revoke the primary certificate 1442 ( Figure 23A Step 2308). In an embodiment, core network 104 (e.g., via AMF 212) uses NAS procedure 1810 to send notification 2201 to UE 106 via 3GPP access 420 (see step 2308). Figure 23A (Optional step 2310). The NAS process 1810 can be enhanced to support the revocation of certificate 1210 at UE 106, such as new or modified information elements (IEs) that indicate or contain revocation information 1522 (e.g., revocation of certificate 1210 or digital signature algorithm 1230 in certificate 1210), new error reasons indicating the revocation of certificate 1210 or digital signature algorithm 1230 in certificate 1210, etc.

[0113] Conversely, UE 106 receives revocation information 1522 from core network 104 to revoke the master certificate 1442. Figure 23B Step 2336). More specifically, UE 106 can receive notification 2201 from core network 104 via non-3GPP access 422, which indicates that the primary certificate 1442 has been revoked (step 2338). For example, UE 106 can receive notification 2201 via non-3GPP access 422 through NAS procedure 1810 (see step 2336). Figure 23B (Optional step 2340). UE 106 designates the primary certificate 1442 as revoked and updates its stored parameters accordingly. In an embodiment, UE 106 may initiate revocation procedure 1520 in response to notification 2201. For example, UE 106 may be programmed to automatically switch to secondary certificate 1444 in response to notification 2201.

[0114] In this embodiment, the core network 104 may request the UE 106 to access or connect via 3GPP access. Figure 23AStep 2312). Therefore, core network 104 (via RAN node 304) can send an indication message (e.g., paging message 2202) to UE 106 to connect to core network 104 via 3GPP access 420. The indication message can indicate that at least one mobile terminal (MT) packet is waiting for UE 106 via 3GPP access 420 instead of non-3GPP access 422. UE 106 receives the indication message ( Figure 23B Steps 2342), and attempt to register with core network 104 via 3GPP access 420 ( Figure 23B (Step 2344). Upon successful registration, UE 106 is authenticated via 3GPP access 420 and connects to core network 104. Core network 104 (e.g., UDM 218, AMF212, etc.) notifies UE 106 via 3GPP access 420 to switch to secondary certificate 1444. To notify UE 106, core network 104 may send, transmit, or provide configuration update 2204 to UE 106, which indicates the switch to secondary certificate 1444, and possibly other information or parameters (see step 2344). Figure 23A (Optional step 2314). In an embodiment, core network 104 (e.g., via UDM 218) can use UPU procedure 1804 to send configuration update 2204 to UE 106 via 3GPP access 420. UPU procedure 1804 can be enhanced to support the revocation of certificate 1210 at UE 106, changes to certificate 1210, etc., such as enhancements to UPU information, UPU data, UPU transparent container, information element (IE), etc. For example, a new IE can be defined for UPU procedure 1804, which indicates or contains revocation information 1522 (e.g., revocation of certificate 1210 or digital signature algorithm 1230 in certificate 1210), which indicates changes to secondary certificate 1444 or switching to secondary certificate 1444, etc.

[0115] UE 106 receives configuration update 2204 from core network 104 (i.e., core NF 110), which indicates a handover to secondary certificate 1444 (see [link]). Figure 23B (Step 2346). In an embodiment, UE 106 may receive configuration update 2204 from core network 104 via 3GPP access 420 through UPU procedure 1804. In response to configuration update 2204, UE 106 specifies a secondary certificate 1444 for authentication in non-3GPP access 422 and updates its stored parameters accordingly.

[0116] In response to notification 2201 and / or configuration update 2204, UE 106 initiates or triggers revocation procedure 1520. Figure 23BStep 2348). Regarding the revocation process 1520, UE 106 switches to the secondary certificate 1444 (…). Figure 23B (Step 2350 in the example). In an embodiment, the secondary certificate 1444 may be pre-configured in the UE 106, and the UE 106 may automatically switch to the secondary certificate 1444 in response to notification 2201. In an embodiment, configuration update 2204 may include an indicator of the secondary certificate 1444, and in response to the indicator provided in configuration update 2204, the UE 106 may switch to the secondary certificate 1444. In an embodiment, in response to revocation information 1522, the UE 106 may terminate existing non-3GPP access 422. For example, the UE 106 may disconnect from the current non-3GPP access connection 1202 of the N3IWF 520 ( Figure 23B Step 2352), and attempt to reconnect to N3IWF520 via non-3GPP access 422 to establish or set up a new non-3GPP access 1202 ( Figure 23B Step 2354). Upon reconnection, UE 106 uses secondary certificate 1444 to perform authentication with N3IWF 520 ( Figure 23B Step 2356).

[0117] Core network 104 can also notify N3IWF 520 to revoke primary certificate 1442 and / or switch to secondary certificate 1444 (see...) Figure 23A (Optional step 2316). To notify N3IWF 520, core network 104 may send, transmit, or provide revocation information 1522 to N3IWF 520, which indicates the revocation of primary certificate 1442 and / or the switch to secondary certificate 1444, as well as possible other information or parameters. In turn, N3IWF 520 receives revocation information 1522 from core network 104 (i.e., core NF 110) for non-3GPP access 422 (see [link to relevant documentation]). Figure 23C Step 2366), the revocation information 1522 indicates the revocation of the primary certificate 1442 and / or the switch to the secondary certificate 1444. In response to the revocation information 1522, the N3IWF 520 initiates or triggers the revocation process 1520 ( Figure 23C Step 2368). For revocation procedure 1520, N3IWF 520 switches to secondary certificate 1444 (…). Figure 23C Step 2370). In an embodiment, in response to the revocation information 1522, N3IWF 520 can terminate the current non-3GPP access 422. For example, N3IWF 520 can disconnect from the current non-3GPP access connection 1202 of UE 106 ( Figure 23CStep 2372), and attempt to reconnect to UE 106 via non-3GPP access 422 to establish or set up a new non-3GPP access connection 1202. Figure 23C Step 2374). Upon reconnection, the N3IWF 520 uses secondary certificate 1444 to perform authentication with UE 106 ( Figure 23C Step 2376).

[0118] If authentication is successful, a new non-3GPP access connection 1202 is established or set up between UE 106 and N3IWF 520. The new non-3GPP access connection 1202 will be authenticated based on the secondary certificate 1444 and the digital signature algorithm 1230 associated with the secondary certificate 1444. One technical advantage is that when the non-3GPP access 422 is compromised, UE 106 can register via 3GPP access 420, and 3GPP access 420 can be used to switch certificates 1210 (e.g., from primary certificate 1442 to secondary certificate 1444). This improves network security, such as protection against zero-day attacks.

[0119] Any of the various elements or modules shown in the figures or described herein can be implemented as hardware, software, firmware, or some combination thereof. For example, an element can be implemented as dedicated hardware. A dedicated hardware element can be referred to as a “processor,” a “controller,” or similar terms. When functionality is provided by a processor, it can be provided by a single dedicated processor, by a single shared processor, or by multiple separate processors (some of which may be shared). Furthermore, the explicit use of the terms “processor” or “controller” should not be construed as referring only to hardware capable of executing software, but may implicitly include, but is not limited to, digital signal processor (DSP) hardware, network processors, application-specific integrated circuits (ASICs) or other circuit systems, field-programmable gate arrays (FPGAs), read-only memory (ROM) for storing software, random access memory (RAM), non-volatile memory, logic, or some other physical hardware component or module.

[0120] Additionally, a component can be implemented as instructions executable by a processor or computer to perform the component's function. Some examples of instructions are software, program code, and firmware. Instructions are operable when executed by a processor to instruct the processor to perform the component's function. Instructions can be stored on a processor-readable storage device. Some examples of storage devices are digital or solid-state memory, magnetic storage media (such as disks and tapes), hard disk drives, or optically readable digital data storage media.

[0121] As used in this application, the term "circuit system" may refer to one or more of the following: (a) Hardware circuit implementation only (such as implementation only in analog and / or digital circuit systems); (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits with software / firmware; and (ii) Any portion of a hardware processor (including a digital signal processor), software, and memory (including a plurality of other processors), which work together to enable a device (such as a mobile phone or a server) to perform various functions; and (c) (Multiple) hardware circuits and / or (multiple) processors (such as (multiple) microprocessors or portions of (multiple) microprocessors) that require software (e.g., firmware) for operation, but may be absent when the software is not required for operation.

[0122] The definition of "circuit system" applies to all uses of this term in this application (including in any claim). As another example, as used in this application, the term "circuit system" also covers only the implementation of hardware circuitry or processors (or processors), or portions thereof, and their accompanying software and / or firmware. For example, if applicable to a particular claim symbol, the term "circuit system" also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0123] Although specific embodiments have been described herein, the scope of this disclosure is not limited to those specific embodiments. The scope of this disclosure is defined by the following claims and their equivalents.

[0124] Clause 1. A user equipment configured to access a core network, the user equipment comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the user equipment to at least: store a plurality of certificates having different digital signature algorithms; and when accessing the core network via a gateway through a non-3GPP access network: use the first certificate in the certificates to perform authentication with the gateway by calculating a first digital signature using a first digital signature algorithm associated with a first certificate in the certificates; receive revocation information to revoke the first certificate in the certificates in response to a security event concerning the first digital signature algorithm; and use the second certificate in the certificates to perform authentication with the gateway by calculating a second digital signature using a second digital signature algorithm associated with a second certificate in the certificates in response to the revocation information.

[0125] Clause 2. User equipment pursuant to Clause 1, wherein: the digital signature algorithm includes a post-quantum computing digital signature algorithm.

[0126] Clause 3. A user equipment pursuant to Clause 1, wherein when the instructions are executed by at least one processor, the user equipment performs at least: disconnecting from the gateway in response to a revocation message; and reconnecting to the gateway, wherein using a second certificate from the certificate includes: using the second certificate from the certificate to perform authentication upon reconnection.

[0127] Clause 4. User equipment pursuant to Clause 1, wherein: when further accessing the core network via 3GPP access, receiving revocation information includes: receiving revocation information from the core network via 3GPP access.

[0128] Clause 5. According to Clause 4, receiving revocation information via 3GPP access includes: receiving revocation information from the core network via 3GPP access through the User Equipment Parameter Update (UPU) procedure.

[0129] Clause 6. User equipment pursuant to Clause 4, wherein receiving revocation information via 3GPP access includes: receiving revocation information from the core network via 3GPP access, through a non-access stratum procedure.

[0130] Clause 7. User equipment pursuant to Clause 1, wherein receiving revocation information includes: receiving notification of the revocation of the first certificate in the certificate from the core network via a non-3GPP access, through a non-access stratum procedure.

[0131] Clause 8. For a user equipment pursuant to Clause 1, receiving revocation information includes: receiving an instruction message for registration with the core network via 3GPP access; and, after accessing the core network via 3GPP access, receiving a configuration update from the core network via the user equipment parameter update UPU procedure to switch to the second certificate in the certificate.

[0132] Clause 9. A method comprising: storing, in a user equipment configured to access a core network, a plurality of certificates having different digital signature algorithms; and, when accessing the core network via a gateway through a non-3GPP access route: using the first certificate in the certificate to perform authentication with the gateway by calculating a first digital signature using a first digital signature algorithm associated with a first certificate in the certificate; receiving revocation information to revoke the first certificate in the certificate in response to a security event relating to the first digital signature algorithm; and using the second certificate in the certificate to perform authentication with the gateway by calculating a second digital signature using a second digital signature algorithm associated with a second certificate in the certificate in response to the revocation information.

[0133] Clause 10. The method according to Clause 9, wherein: the digital signature algorithm includes a post-quantum computing digital signature algorithm.

[0134] Clause 11. The method according to Clause 9 further includes: disconnecting from the gateway in response to a revocation message; and reconnecting to the gateway, wherein using a second certificate from the certificate includes: using the second certificate from the certificate to perform authentication after reconnection.

[0135] Clause 12. The method according to Clause 9, wherein: when further accessing the core network via 3GPP access, receiving the revocation information includes: receiving the revocation information from the core network via 3GPP access.

[0136] Clause 13. The method according to Clause 12, wherein receiving revocation information via 3GPP access includes: receiving revocation information from the core network via 3GPP access, through the User Equipment Parameter Update (UPU) procedure.

[0137] Clause 14. The method according to Clause 12, wherein receiving revocation information via 3GPP access includes: receiving revocation information from the core network via a non-access stratum procedure through 3GPP access.

[0138] Clause 15. The method according to Clause 9, wherein receiving revocation information includes: receiving notification of the revocation of the first certificate in the certificate from the core network via a non-3GPP access, through a non-access stratum procedure.

[0139] Clause 16. The method according to Clause 9, wherein receiving revocation information includes: receiving an instruction message for registration with the core network via 3GPP access; and after accessing the core network via 3GPP access, receiving a configuration update from the core network via the User Equipment Parameter Update (UPU) procedure to switch to the second certificate in the certificate.

[0140] Clause 17. A non-transitory computer-readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least the following: in a user equipment configured to access a core network: storing a plurality of certificates having different digital signature algorithms; and when accessing the core network via a gateway through a non-3GPP access network: using the first certificate in the certificate to perform authentication with the gateway by calculating a first digital signature using a first digital signature algorithm associated with a first certificate in the certificate; receiving revocation information to revoke the first certificate in the certificate in response to a security event relating to the first digital signature algorithm; and using the second certificate in the certificate to perform authentication with the gateway by calculating a second digital signature using a second digital signature algorithm associated with a second certificate in the certificate in response to the revocation information.

[0141] Clause 18. A computer-readable medium pursuant to Clause 17, wherein: the digital signature algorithm includes a post-quantum computing digital signature algorithm.

[0142] Clause 19. The computer-readable medium pursuant to Clause 17, wherein the program instructions further cause the device to perform at least the following: disconnect from the gateway in response to a revocation message; and reconnect to the gateway, wherein using the second certificate in the certificate includes: performing authentication using the second certificate in the certificate after reconnection.

[0143] Clause 20. The computer-readable medium pursuant to Clause 17, wherein: when further access to the core network via 3GPP access, receiving revocation information includes: receiving revocation information from the core network via 3GPP access.

Claims

1. A user equipment for communication, the user equipment being configured to access a core network, the user equipment comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the user equipment to perform at least the following: Store multiple certificates with different digital signature algorithms; as well as When accessing the core network via a gateway through a non-3GPP (Non-3rd Generation Partnership Project) access route: The first digital signature is calculated by using the first digital signature algorithm associated with the first certificate in the certificate, and the first certificate in the certificate is used to perform authentication with the gateway. In response to a security event concerning the first digital signature algorithm in the digital signature algorithm, a revocation message is received to revoke the first certificate in the certificate; as well as In response to the revocation information, a second digital signature is calculated using a second digital signature algorithm associated with the second certificate in the certificate, and the second certificate in the certificate is used to perform authentication with the gateway.

2. The user equipment according to claim 1, wherein: The digital signature algorithm includes a post-quantum computing digital signature algorithm.

3. The user equipment of claim 1, wherein the instructions, when executed by the at least one processor, cause the user equipment to perform at least: In response to the revocation information, disconnect from the gateway; and Reconnect to the gateway, where Using the second certificate in the certificate includes: Upon reconnection, the second certificate from the aforementioned certificates is used to perform authentication.

4. The user equipment according to claim 1, wherein: When further accessing the core network via 3GPP access, receiving the revocation information includes: receiving the revocation information from the core network via the 3GPP access.

5. The user equipment according to claim 4, wherein receiving the revocation information via the 3GPP access includes: The cancellation information is received from the core network via the 3GPP access and the User Equipment Parameter Update (UPU) process.

6. The user equipment according to claim 4, wherein receiving the revocation information via the 3GPP access includes: The revocation information is received from the core network via the 3GPP access through a non-access stratum process.

7. The user equipment according to claim 1, wherein receiving the revocation information includes: Through the non-3GPP access, via a non-access stratum process, a notification to revoke the first certificate in the certificate is received from the core network.

8. The user equipment according to claim 1, wherein receiving the revocation information includes: Access via 3GPP, and receive the instruction message for registration with the core network; as well as After accessing the core network via the 3GPP access, the user equipment parameter update (UPU) process is used to receive a configuration update from the core network to switch to the second certificate in the certificate.

9. A method for communication, comprising: In user equipment configured to access the core network: Store multiple certificates with different digital signature algorithms; as well as When accessing the core network via a gateway through a non-3GPP (Non-3rd Generation Partnership Project) access route: The first digital signature is calculated by using the first digital signature algorithm associated with the first certificate in the certificate, and the first certificate in the certificate is used to perform authentication with the gateway. In response to a security event concerning the first digital signature algorithm in the digital signature algorithm, a revocation message is received to revoke the first certificate in the certificate; as well as In response to the revocation information, a second digital signature is calculated using a second digital signature algorithm associated with the second certificate in the certificate, and the second certificate in the certificate is used to perform authentication with the gateway.

10. The method of claim 9, further comprising: In response to the revocation information, disconnect from the gateway; as well as Reconnect to the gateway, where Using the second certificate from the certificate includes: using the second certificate from the certificate to perform authentication after reconnection.

Images