阅读说明：本技术 安全模式完整性验证 (Secure mode integrity verification ) 是由 安德烈亚斯·孔茨 哥纳季·韦列夫 于 2020-03-06 设计创作，主要内容包括：公开了用于安全模式完整性验证的装置、方法和系统。一种方法(600)包括向一个或多个网络设备传送(602)请求消息。方法(600)包括,响应于传送请求消息,与一个或多个网络设备进行认证(604)。该方法(600)包括,响应于与一个或多个网络设备的成功认证,接收(606)安全模式命令消息。方法(600)包括验证(608)安全模式命令消息的完整性。方法(600)包括,响应于安全模式命令消息的完整性的验证指示安全密钥无效,执行(610)小区重选过程。(Apparatus, methods, and systems for secure mode integrity verification are disclosed. A method (600) includes transmitting (602) a request message to one or more network devices. The method (600) includes, in response to transmitting the request message, authenticating (604) with the one or more network devices. The method (600) includes, in response to successful authentication with one or more network devices, receiving (606) a security mode command message. The method (600) includes verifying (608) the integrity of the secure mode command message. The method (600) comprises, in response to a verification of the integrity of the security mode command message indicating that the security key is invalid, performing (610) a cell reselection procedure.)

1. A method, comprising:

transmitting a request message to one or more network devices;

authenticating with the one or more network devices in response to transmitting the request message;

receiving a security mode command message in response to successful authentication with the one or more network devices;

verifying the integrity of the secure mode command message; and

performing a cell reselection procedure in response to verification of the integrity of the security mode command message indicating that a security key is invalid.

2. The method of claim 1, further comprising: transmitting a secure mode reject message in response to verification of the integrity of the secure mode command message indicating that the secure key is invalid.

3. The method of claim 1, further comprising, in response to verification of the integrity of the security mode command message indicating that the security key is invalid, storing information indicating that a cell corresponding to the one or more network devices is an invalid cell.

4. The method of claim 1, wherein performing the cell reselection procedure comprises beginning an initial registration with a second cell different from a first cell corresponding to the one or more network devices.

5. An apparatus, comprising:

a transmitter to transmit a request message to one or more network devices;

a processor that authenticates with the one or more network devices in response to transmitting the request message; and

a receiver that receives a secure mode command message in response to successful authentication with the one or more network devices, wherein the processor:

verifying the integrity of the secure mode command message; and is

Performing a cell reselection procedure in response to verification of the integrity of the security mode command message indicating that the security key is invalid.

6. The device of claim 5, wherein the transmitter transmits a secure mode reject message in response to verification of the integrity of the secure mode command message indicating that the secure key is invalid.

7. The apparatus of claim 5, wherein in response to verification of the integrity of the security mode command message indicating that the security key is invalid, the processor stores information indicating that a cell corresponding to the one or more network devices is an invalid cell.

8. The apparatus of claim 5, wherein the processor performing the cell reselection procedure comprises: the processor initiates initial registration with a second cell different from a first cell corresponding to the one or more network devices.

9. A method, comprising:

receiving a request message corresponding to user equipment;

in response to receiving the request message, determining whether the request message is valid based on information corresponding to the user equipment; and

transmitting a response message indicating to the user equipment that the request message is rejected in response to determining that the request message is invalid.

10. The method of claim 9, wherein the information corresponding to the user device comprises a globally unique temporary identifier, a user device identifier, or a combination thereof.

11. The method of claim 9, further comprising successfully authenticating the user device.

12. The method of claim 1, further comprising receiving a security mode reject message indicating that a security mode command message integrity check performed by the user equipment failed.

13. An apparatus, comprising:

a receiver that receives a request message corresponding to a user equipment;

a processor, responsive to receiving the request message, that determines whether the request message is valid based on information corresponding to the user equipment; and

a transmitter to transmit a response message indicating to the user equipment that the request message is denied in response to determining that the request message is invalid.

14. The apparatus of claim 12, wherein the processor successfully authenticates the user device and the receiver receives a security mode reject message indicating failure of a security mode command message integrity check performed by the user device.

15. A method, comprising:

receiving an authentication request message corresponding to user equipment; and

in response to receiving the authentication request message:

determining whether the user equipment has moved from a first public land mobile network to a second public land mobile network within a predetermined time period;

determining a likelihood factor indicating a likelihood of the user equipment moving from the first public land mobile network to the second public land mobile network in response to the user equipment having moved from the first public land mobile network to the second public land mobile network within the predetermined period of time; and

transmitting an authentication response message indicating a failed authentication in response to the likelihood factor being less than a predetermined threshold.

16. The method of claim 15, wherein the likelihood factor corresponds to: a distance between the first public land mobile network and the second public land mobile network taking into account the predetermined time period between two registrations corresponding to the first and second public land mobile networks.

17. The method of claim 15, further comprising: receiving information indicative of a security key mismatch detected by the user equipment, and in response to receiving the information indicative of the security key mismatch detected by the user equipment, setting a parameter to a value indicative of a potential security issue.

18. An apparatus, comprising:

a transmitter;

a processor; and

a receiver that receives an authentication request message corresponding to a user equipment, wherein in response to receiving the authentication request message:

the processor determining whether the user equipment has moved from a first public land mobile network to a second public land mobile network within a predetermined time period;

in response to the user equipment having moved from the first public land mobile network to the second public land mobile network within the predetermined time period, the processor determining a likelihood factor indicating a likelihood that the user equipment has moved from the first public land mobile network to the second public land mobile network; and

a transmitter to transmit an authentication response message indicating a failed authentication in response to the likelihood factor being less than a predetermined threshold.

19. The apparatus of claim 18, wherein the likelihood factor corresponds to: a distance between the first public land mobile network and the second public land mobile network taking into account the predetermined time period between two registrations corresponding to the first and second public land mobile networks.

20. The apparatus of claim 18, wherein the receiver receives information indicative of a security key mismatch detected by the user equipment, and the processor sets a parameter to a value indicative of a potential security issue in response to the receiver receiving the information indicative of the security key mismatch detected by the user equipment.

Technical Field

The subject matter disclosed herein relates generally to wireless communications, and more particularly to secure mode integrity verification.

Background

The following abbreviations are defined herein, at least some of which are referred to in the following description: third generation partnership project ("3 GPP"), fifth generation ("5G"), authentication, authorization, and accounting ("AAA"), positive acknowledgements ("ACK"), authentication and key agreement ("AKA"), aggregation level ("AL"), access and mobility management function ("AMF"), access point ("AP"), access stratum ("AS"), authentication server function ("AUSF"), authentication token ("AUTN"), beam failure detection ("BFD"), beam failure recovery ("BFR"), binary phase shift keying ("BPSK"), base station ("BS"), buffer status report ("BSR"), bandwidth ("BW"), bandwidth part ("BWP"), cell RNTI "), carrier aggregation (" CA "), contention-based random access (" CBRA "), clear channel assessment (" CCA "), common control channel (" CCCH ")," authentication, authorization, and accounting ("AAA"), positive acknowledgement ("ACK"), authentication token-and-key agreement ("AKA"), beam failure detection ("BFD"), beam failure recovery ("BFR"), binary phase shift keying ("BPSK-psk"), base station ("BS"), buffer status report ("BSR"), bandwidth ("BW"), bandwidth part of bandwidth ("BWP"), cell RNTI "), cell-RNTI"), carrier aggregation ("C-RNTI"), carrier aggregation ("CA"), contention-based random access ("CBRA"), clear channel assessment ("CCA"), and/or a combination of a common control channel ("CCCH") to a number of a number Control channel element ("CCE"), cyclic delay diversity ("CDD"), code division multiple access ("CDMA"), control element ("CE"), contention free random access ("CFRA"), closed loop ("CL"), coordinated multipoint ("CoMP"), channel occupancy time ("COT"), cyclic prefix ("CP"), cyclic redundancy check ("CRC"), channel state information ("CSI"), channel state information-reference signal ("CSI-RS"), common search space ("CSS"), control resource set ("CORESET"), discrete fourier transform extension ("DFTS"), downlink control information ("DCI"), downlink ("DL"), demodulation reference signal ("DMRS"), data radio bearer ("DRB"), discontinuous reception ("DRX"), downlink pilot slot ("DwPTS"), clear enhanced channel assessment ("eCCA"),(s), Enhanced mobile broadband ("eMBB"), evolved node B ("eNB"), extensible authentication protocol ("EAP"), effective Omnidirectional radiated Power ("EIRP"), European Telecommunications standards institute ("ETSI"), frame-based device ("FBE"), frequency division Duplex ("FDD"), frequency division multiplexing ("FDM"), frequency division multiple Access ("FDMA"), frequency division orthogonal cover code ("FD-OCC"), frequency range 1-sub-6 GHz band and/or 410MHz to 7125MHz ("FR 1"), frequency range 2-24.25 GHz to 52.6GHz ("FR 2"), general geographic area description ("GAD"), 5G node B or next generation node B ("gNB"), Global navigation satellite System ("GNSS"), general packet radio service ("GPRS"), guard period ("GP"), Global positioning System ("GPS"), Global Mobile communication System ("GSM"), (UK), A globally unique temporary UE identifier ("GUTI"), a home AMF ("hAMF"), a hybrid automatic repeat request ("HARQ"), a home location register ("HLR"), a handover ("HO"), a home PLMN ("HPLMN"), a home subscriber server ("HSS"), a hashed expected response ("HXRES"), an identification or identifier ("ID"), an information element ("IE"), an international mobile equipment identification ("IMEI"), an international mobile subscriber identification ("IMSI"), an international mobile telecommunications ("IMT"), an internet of things ("IoT"), layer 1 ("L1"), layer 2 ("L2"), layer 3 ("L3"), licensed assisted access ("LAA"), a local area network ("LAN"), a load-based device ("LBE"), listen before talk ("LBT"), a logical channel ("LCH"), a logical channel priority ("LCP"), a log-likelihood ratio ("LLR"), "HARQ Long term evolution ("LTE"), multiple access ("MA"), media access control ("MAC"), multimedia broadcast multicast service ("MBMS"), modulation and coding scheme ("MCS"), master information block ("MIB"), multiple input multiple output ("MIMO"), mobility management ("MM"), mobility management entity ("MME"), mobile network operator ("MNO"), large-scale MTC ("MTC"), maximum power reduction ("MPR"), machine type communication ("MTC"), multi-user shared access ("MUSA"), non-access stratum ("NAS"), narrowband ("NB"), negative acknowledgement ("NACK") or ("NAK"), network entity ("NE"), network function ("NF"), next generation ("NG"), NG 5G S-TMSI ("NG-5G-S-TMSI"), non-orthogonal multiple access ("NOMA"), (S-TMSI), A new radio ("NR"), an unlicensed NR ("NR-U"), a network repository function ("NRF"), a network slice instance ("NSI"), network slice selection assistance information ("NSSAI"), a network slice selection function ("NSSF"), a network slice selection policy ("NSSP"), an operations, administration, and maintenance system or operations and maintenance center ("OAM"), orthogonal frequency division multiplexing ("OFDM"), open loop ("OL"), other system information ("OSI"), power angle spectrum ("PAS"), physical broadcast channel ("PBCH"), power control ("PC"), UE-to-UE interface ("PC 5"), primary cell ("PCell"), policy control function ("PCF"), physical cell identification ("PCI"), physical downlink control channel ("PDCCH"), packet data convergence protocol ("PDCP"), "network repository function (" NRF "), and operations and maintenance center (" OAM ") Packet data network gateway ("PGW"), physical downlink shared channel ("PDSCH"), pattern division multiple access ("PDMA"), packet data unit ("PDU"), physical hybrid ARQ indicator channel ("PHICH"), power headroom ("PH"), power headroom report ("PHR"), physical layer ("PHY"), public land mobile network ("PLMN"), physical random access channel ("PRACH"), physical resource block ("PRB"), physical sidelink control channel ("PSCCH"), primary and secondary cell ("PSCell"), physical uplink control channel ("PUCCH"), physical uplink shared channel ("PUSCH"), quasi-co-site ("QCL"), quality of service ("QoS"), quadrature phase shift keying ("QPSK"), registration region ("RA"), RA ("RA-RNTI"), radio access network ("RAN"), "and, Random ("RAND"), radio access technology ("RAT"), random access procedure ("RACH"), random access preamble identifier ("RAPID"), random access response ("RAR"), resource element group ("REG"), radio link control ("RLC"), RLC acknowledged mode ("RLC-AM"), RLC unacknowledged mode/transparent mode ("RLC-UM/TM"), radio link monitoring ("RLM"), radio network temporary identifier ("RNTI"), reference signal ("RS"), remaining minimum system information ("RMSI"), radio resource control ("RRC"), radio resource management ("RRM"), resource extension multiple access ("RSMA"), reference signal received power ("RSRP"), round trip time ("RTT"), receive ("RX"), sparse code multiple access ("SCMA"), "random access, Scheduling requests ("SRs"), sounding reference signals ("SRs"), single-carrier frequency division multiple access ("SC-FDMA"), secondary cells ("scells"), secondary cell groups ("SCG"), shared channels ("SCH"), subcarrier spacing ("SCs"), service data units ("SDU"), security anchor function ("SEAF"), service gateway ("SGW"), system information blocks ("SIB"), system information block type 1 ("SIB 1"), system information block type 2 ("SIB 2"), subscriber identification/identification module ("SIM"), signal-to-interference-plus-noise ratio ("SINR"), sidechains ("SL"), service level agreement ("SLA"), sidechain synchronization signal ("SLSS"), session management function ("SMF"), special cells ("SpCell"), single-network slice selection assistance information ("S-NSSAI"), and the like, Scheduling requests ("SRs"), signaling radio bearers ("SRB"), shortened TMSI ("S-TMSI"), shortened TTIs ("sTTI"), synchronization signals ("SS"), side chain SSBs ("S-SSB"), synchronization signal blocks ("SSB"), subscription hidden identifiers ("SUCI"), supplemental uplink ("SUL"), subscriber permanent identifier ("SUPI"), tracking area ("TA"), TA identifier ("TAI"), TA update ("TAU"), timing alignment timer ("TAT"), transport block ("TB"), transport block size ("TBs"), time division duplex ("TDD"), time division multiplex ("TDM"), time division orthogonal cover code ("TD-OCC"), temporary mobile subscriber identity ("TMSI"), transmission power control ("TPC"), transmission reception point ("TRP"), transmission time interval ("TTI"), and combinations thereof, The system includes a transmission ("TX"), uplink control information ("UCI"), a unified data management function ("UDM"), a unified data repository ("UDR"), a user entity/device (mobile terminal) ("UE"), an uplink ("UL"), an UL SCH ("UL-SCH"), a universal mobile telecommunications system ("UMTS"), a user plane ("UP"), an UP function ("UPF"), an uplink pilot time slot ("UpPTS"), ultra-reliable and low-delay communications ("URLLC"), a UE routing policy ("URSP"), a vehicle-to-vehicle ("V2V"), a visited AMF ("vmaf"), a visited NSSF ("vnsss"), a visited PLMN ("VPLMN"), a wide area network ("WAN"), and global microwave access interoperability ("WiMAX").

In some wireless communication networks, a fake base station may authenticate a user equipment.

Disclosure of Invention

A method for secure mode integrity verification is disclosed. The apparatus and system also perform the functions of the method. One embodiment of a method includes transmitting a request message to one or more network devices. In some embodiments, the method includes authenticating with one or more network devices in response to transmitting the request message. In some embodiments, the method includes receiving a security mode command message in response to successful authentication with one or more network devices. In various embodiments, the method includes verifying the integrity of the secure mode command message. In some embodiments, the method comprises performing a cell reselection procedure in response to verification of the integrity of the security mode command message indicating that the security key is invalid.

An apparatus for secure mode integrity verification includes a transmitter to transmit a request message to one or more network devices. In some embodiments, the apparatus includes a processor that authenticates with one or more network devices in response to transmitting the request message. In various embodiments, the apparatus includes a receiver that receives a security mode command message in response to successful authentication with one or more network devices, wherein the processor: verifying the integrity of the secure mode command message; and, in response to the verification of the integrity of the security mode command message indicating that the security key is invalid, performing a cell reselection procedure.

Another embodiment for a security mode integrity verification method includes receiving a request message corresponding to a user device. In some embodiments, the method includes, in response to receiving the request message, determining whether the request message is valid based on information corresponding to the user device. In some embodiments, the method includes transmitting a response message indicating to the user equipment that the request message is rejected in response to determining that the request message is invalid.

Another apparatus for secure mode integrity verification includes a receiver that receives a request message corresponding to a user device. In some embodiments, the apparatus includes a processor that, in response to receiving the request message, determines whether the request message is valid based on information corresponding to the user equipment. In various embodiments, the apparatus includes a transmitter that transmits a response message indicating to the user equipment that the request message is rejected in response to determining that the request message is invalid.

Yet another embodiment for an authentication method includes receiving an authentication request message corresponding to a user device. In some embodiments, the method comprises, in response to receiving the authentication request message: determining whether the user equipment has moved from the first public land mobile network to the second public land mobile network within a predetermined time period; determining a likelihood factor indicating a likelihood of the user equipment moving from the first public land mobile network to the second public land mobile network in response to the user equipment having moved from the first public land mobile network to the second public land mobile network within a predetermined time period; and, in response to the likelihood factor being less than a predetermined threshold, transmitting an authentication response message indicating a failed authentication.

Yet another apparatus for authentication includes a transmitter and a processor. In some embodiments, the apparatus includes a receiver that receives an authentication request message corresponding to a user equipment, wherein in response to receiving the authentication request message: the processor determines whether the user equipment has moved from the first public land mobile network to the second public land mobile network within a predetermined time period; the processor determines a likelihood factor indicating a likelihood of the user equipment moving from the first public land mobile network to the second public land mobile network in response to the user equipment having moved from the first public land mobile network to the second public land mobile network within a predetermined time period; and a transmitter that transmits an authentication response message indicating a failed authentication in response to the likelihood factor being less than a predetermined threshold.

Drawings

A more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only some embodiments and are not therefore to be considered to be limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 is a schematic block diagram illustrating one embodiment of a wireless communication system for secure mode integrity verification;

FIG. 2 is a schematic block diagram illustrating one embodiment of an apparatus that may be used for secure mode integrity verification;

FIG. 3 is a schematic block diagram illustrating one embodiment of an apparatus that may be used for secure mode integrity verification;

FIG. 4 is a schematic block diagram illustrating one embodiment of an authentication relay attack;

FIG. 5 is a schematic block diagram illustrating one embodiment of network communications;

FIG. 6 is a flow diagram illustrating one embodiment of a method for secure mode integrity verification;

FIG. 7 is a flow diagram illustrating another embodiment of a method for secure mode integrity verification; and

FIG. 8 is a flow diagram of one embodiment of a method for authentication.

Detailed Description

As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method or program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," module "or" system. Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and/or program code, referred to hereinafter as code. The storage device may be tangible, non-transitory, and/or non-transmissive. The storage device may not embody the signal. In certain embodiments, the memory device only employs signals for accessing the code.

Some of the functional units described in this specification may be labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integration ("VLSI") circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

Modules may also be implemented in code and/or software for execution by various types of processors. An identified module of code may, for instance, comprise one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

Indeed, a module of code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different computer-readable storage devices. Where a module or portions of a module are implemented in software, the software portions are stored on one or more computer-readable storage devices.

Any combination of one or more computer-readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. A storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or flash memory), a portable compact disc read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The code for performing the operations of an embodiment may be any number of lines and may be written in any combination including one or more of an object oriented programming language such as Python, Ruby, Java, Smalltalk, C + +, etc., and conventional procedural programming languages, such as the "C" programming language, and/or a machine language, such as assembly language. The code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer, partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network ("LAN") or a wide area network ("WAN"), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

Reference in the specification to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise. The enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms "a", "an" and "the" also mean "one or more", unless expressly specified otherwise.

Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that an embodiment may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments.

Aspects of the embodiments are described below with reference to schematic flow charts and/or schematic block diagrams of methods, apparatuses, systems, and program products according to the embodiments. It will be understood that each block of the schematic flow chart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flow chart diagrams and/or schematic block diagrams, can be implemented by code. The code can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block or blocks of the schematic flow diagrams and/or schematic block diagrams.

The code may also be stored in a memory device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the memory device produce an article of manufacture including instructions which implement the function/act specified in the schematic flowchart and/or schematic block diagram block or blocks.

The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the code which executes on the computer or other programmable apparatus provides processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The schematic flow charts and/or schematic block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods and program products according to various embodiments. In this regard, each block in the schematic flow chart diagrams and/or schematic block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).

It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It is contemplated that other steps and methods may be equivalent in function, logic, or effect to one or more blocks or portions thereof of the illustrated figures.

Although various arrow types and line types may be employed in the flow chart diagrams and/or block diagram blocks, they are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and code.

The description of the elements in each figure may refer to elements of the previous figures. Like numbers refer to like elements throughout, including alternative embodiments of the same elements.

Fig. 1 depicts an embodiment of a wireless communication system 100 for secure mode integrity verification. In one embodiment, wireless communication system 100 includes a remote unit 102 and a network unit 104. Although a particular number of remote units 102 and network units 104 are depicted in fig. 1, those skilled in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100.

In one embodiment, remote unit 102 may include a computing device such as a desktop computer, laptop computer, personal digital assistant ("PDA"), tablet computer, smart phone, smart television (e.g., television connected to the internet), set-top box, game console, security system (including a surveillance camera), on-board computer, networking device (e.g., router, switch, modem), airborne vehicle, drone, or the like. In some embodiments, remote unit 102 includes a wearable device, such as a smart watch, a fitness band, an optical head-mounted display, and so forth. Moreover, remote unit 102 may be referred to as a subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, UE, user terminal, device, or other terminology used in the art. Remote unit 102 may communicate directly with one or more network units 104 via UL communication signals. In particular embodiments, remote units 102 may communicate directly with other remote units 102 via sidelink communications.

The network elements 104 may be distributed over a geographic area. In particular embodiments, network element 104 may also be referred to as an access point, access terminal, base station, node-B, eNB, gNB, home node-B, relay node, device, core network, over-the-air server, radio access node, AP, NR, network entity, AMF, UDM, UDR, UDM/UDR, PCF, RAN, NSSF, or any other terminology used in the art. The network elements 104 are typically part of a radio access network that includes one or more controllers communicatively coupled to one or more corresponding network elements 104. The radio access network is typically communicatively coupled to one or more core networks, which may be coupled to other networks, such as the internet and public switched telephone networks, among others. These and other elements of the radio access and core networks are not illustrated but are generally well known to those of ordinary skill in the art.

In one embodiment, wireless communication system 100 conforms to the NR protocol standardized in 3GPP, where network units 104 transmit on the DL using an OFDM modulation scheme and remote units 102 transmit on the UL using an SC-FDMA scheme or an OFDM scheme. More generally, however, the wireless communication system 100 may implement some other open or proprietary communication protocol, such as WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, CDMA, GSM, CDMA, and/or GSM, and/or UMTS, and/or GSM, and/or UMTS, and/or LTE, and/or CDMA, variants,ZigBee, Sigfoxx, and other protocols. The present disclosure is not intended to be limited to implementation by any particular wireless communication system architecture or protocol.

Network element 104 may serve multiple remote units 102 within a service area (e.g., a cell or cell sector) via wireless communication links. The network element 104 transmits DL communication signals in the time, frequency, and/or spatial domains to serve the remote unit 102.

In one embodiment, remote unit 102 may transmit a request message to one or more network devices (e.g., network element 104). In some embodiments, remote unit 102 may authenticate with one or more network devices in response to transmitting the request message. In some embodiments, the remote unit 102 may receive the secure mode command message in response to successful authentication with one or more network devices. In various embodiments, the remote unit 102 may verify the integrity of the secure mode command message. In some embodiments, the remote unit 102 may perform a cell reselection procedure in response to the verification of the integrity of the security mode command message indicating that the security key is invalid. Thus, the remote unit 102 may be used for secure mode integrity verification.

In various embodiments, network element 104 may receive a request message corresponding to a user device (e.g., remote unit 102). In some embodiments, in response to receiving the request message, the network element 104 may determine whether the request message is valid based on information corresponding to the user equipment. In some embodiments, in response to determining that the request message is invalid, network element 104 may transmit a response message indicating to the user equipment that the request message is rejected. Thus, the network element 104 may be used for security mode integrity verification.

In some embodiments, the network element 104 may receive an authentication request message corresponding to a user device (e.g., remote unit 102). In some embodiments, in response to receiving the authentication request message, the network element 104 may: determining whether the user equipment has moved from the first public land mobile network to the second public land mobile network within a predetermined time period; determining a likelihood factor indicating a likelihood of the user equipment moving from the first public land mobile network to the second public land mobile network in response to the user equipment having moved from the first public land mobile network to the second public land mobile network within a predetermined time period; and, in response to the likelihood factor being less than a predetermined threshold, transmitting an authentication response message indicating a failed authentication. Thus, the network element 104 may be used for authentication.

Fig. 2 depicts one embodiment of an apparatus 200 that may be used for secure mode integrity verification. The apparatus 200 includes one embodiment of the remote unit 102. In addition, remote unit 102 may include a processor 202, memory 204, input device 206, display 208, transmitter 210, and receiver 212. In some embodiments, the input device 206 and the display 208 are combined into a single device, such as a touch screen. In some embodiments, remote unit 102 may not include any input device 206 and/or display 208. In various embodiments, remote unit 102 may include one or more of processor 202, memory 204, transmitter 210, and receiver 212, and may not include input device 206 and/or display 208.

In one embodiment, processor 202 may include any known controller capable of executing computer readable instructions and/or capable of performing logical operations. For example, the processor 202 may be a microcontroller, microprocessor, central processing unit ("CPU"), graphics processor ("GPU"), auxiliary processing unit, field programmable gate array ("FPGA"), or similar programmable controller. In some embodiments, the processor 202 executes instructions stored in the memory 204 to perform the methods and routines described herein. In various embodiments, processor 202 may authenticate to one or more network devices in response to transmitting the request message. The processor 202 is communicatively coupled to a memory 204, an input device 206, a display 208, a transmitter 210, and a receiver 212.

In one embodiment, memory 204 is a computer-readable storage medium. In some embodiments, memory 204 includes volatile computer storage media. For example, the memory 204 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and/or static RAM ("SRAM"). In some embodiments, memory 204 includes non-volatile computer storage media. For example, memory 204 may include a hard drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 204 includes both volatile and nonvolatile computer storage media. In some embodiments, memory 204 also stores program code and related data, such as an operating system and other controller algorithms operating on remote unit 102.

In one embodiment, input device 206 may comprise any known computer input device, including a touchpad, buttons, keyboard, stylus, microphone, and the like. In some embodiments, the input device 206 may be integrated with the display 208, for example, as a touch screen or similar touch sensitive display. In some embodiments, the input device 206 includes a touch screen such that text may be entered using a virtual keyboard displayed on the touch screen and/or by handwriting on the touch screen. In some embodiments, the input device 206 includes two or more different devices, such as a keyboard and a touch panel.

In one embodiment, the display 208 may comprise any known electronically controllable display or display device. The display 208 may be designed to output visual, audible, and/or tactile signals. In some embodiments, display 208 comprises an electronic display capable of outputting visual data to a user. For example, the display 208 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, and the like to a user. As another non-limiting example, display 208 may include a wearable display such as a smart watch, smart glasses, heads-up display, and the like. Further, the display 208 may be a component of a smart phone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

In certain embodiments, the display 208 includes one or more speakers for producing sound. For example, the display 208 may produce an audible alarm or notification (e.g., a beep or chime). In some embodiments, the display 208 includes one or more haptic devices for generating vibrations, motions, or other haptic feedback. In some embodiments, all or part of the display 208 may be integrated with the input device 206. For example, the input device 206 and the display 208 may form a touch screen or similar touch sensitive display. In other embodiments, the display 208 may be located near the input device 206.

The transmitter 210 is used to provide UL communication signals to the network element 104 and the receiver 212 is used to receive DL communication signals from the network element 104, as described herein.

In some embodiments, the transmitter 210 may transmit a request message to one or more network devices (e.g., network element 104). In various embodiments, in response to successful authentication with one or more network devices, receiver 212 may receive a secure mode command message, wherein processor 202: verifying the integrity of the secure mode command message; and, in response to the verification of the integrity of the security mode command message indicating that the security key is invalid, performing a cell reselection procedure. Although only one transmitter 210 and one receiver 212 are illustrated, remote unit 102 may have any suitable number of transmitters 210 and receivers 212. The transmitter 210 and receiver 212 may be any suitable type of transmitter and receiver. In one embodiment, the transmitter 210 and receiver 212 may be part of a transceiver.

Fig. 3 depicts one embodiment of an apparatus 300 that may be used for secure mode integrity verification. The apparatus 300 includes one embodiment of the network element 104. Further, the network element 104 may include a processor 302, a memory 304, an input device 306, a display 308, a transmitter 310, and a receiver 312. It is to be appreciated that processor 302, memory 304, input device 306, display 308, transmitter 310, and receiver 312 may be substantially similar to processor 202, memory 204, input device 206, display 208, transmitter 210, and receiver 212, respectively, of remote unit 102.

In various embodiments, the receiver 312 may receive a request message corresponding to a user device (e.g., remote unit 102). In some embodiments, in response to receiving the request message, processor 302 may determine whether the request message is valid based on information corresponding to the user device. In various embodiments, in response to determining that the request message is invalid, the transmitter 310 may transmit a response message indicating to the user equipment that the request message is rejected.

In some embodiments, the receiver 312 may receive an authentication request message corresponding to a user equipment (e.g., the remote unit 102), wherein in response to receiving the authentication request message, the processor 302 may determine whether the user equipment has moved from a first public land mobile network to a second public land mobile network within a predetermined time period; in response to the user equipment having moved from the first public land mobile network to the second public land mobile network within a predetermined time period, the processor 302 may determine a likelihood factor indicating a likelihood of the user equipment moving from the first public land mobile network to the second public land mobile network; and in response to the likelihood factor being less than the predetermined threshold, the transmitter 310 may transmit an authentication response message indicating a failed authentication. Although only one transmitter 310 and one receiver 312 are illustrated, the network element 104 may have any suitable number of transmitters 310 and receivers 312. The transmitter 310 and receiver 312 may be any suitable type of transmitter and receiver. In one embodiment, the transmitter 310 and receiver 312 may be part of a transceiver.

Fig. 4 is a schematic block diagram 400 illustrating one embodiment of an authentication relay attack. The diagram 400 includes a victim UE 402 and a fake BS 404, both located at a first location 406, and a rogue UE 408, a real BS 410, a real AMF 412, all located at a second location 414. The diagram 400 also includes the UDM/AUSF of the victim UE 416. Diagram 400 illustrates authentication attack 418 occurring across devices.

In some configurations, the victim UE 402 may be attracted to the fake BS 404 (e.g., a malicious gNB). In such a configuration, the fake BS 404 may cooperate with the malicious UE 408. Furthermore, there may be a dedicated channel between the fake BS 404 and the malicious UE 408. In these configurations, the distance between the fake BS 404 and the malicious UE 408 may be far, and the fake BS 404 and the malicious UE 408 may be linked through a LAN or WAN to form a malicious network through the two PLMNs.

In various embodiments, the victim UE 402 may perform a registration request, service request, or TAU request procedure. In such embodiments, the fake BS 404 may forward the message of the victim UE 402 to the malicious UE 408, and the malicious UE 408 may forward the message to the true AMF 412 in the home network through the true BS 410 (e.g., the remote legitimate gNB). If the AMF 412 initiates the authentication procedure, the fake BS 404 and the malicious UE may forward authentication messages between the remote legitimate gNB and the victim UE 402 to complete the authentication. Thus, the victim UE 402 can successfully access the true BS 410 through the fake BS 404 and the malicious UE 408 and register with the home network.

In some embodiments, the network-aware user's location and the user's actual location may not be consistent. For example, if the user is in london, the attacker forwards the message to the true BS 410 located in new york through the false BS 404 and the malicious UE 408, causing the core network to assume that the user is located in new york, thereby providing a way to establish false out-of-the-field evidence or to undermine criminal investigations with false evidence. The victim UE 402 may be directed by an attacker to access a roaming network, resulting in charging fraud.

Unlike a typical man-in-the-middle attack, the adversary in this attack cannot decrypt encrypted traffic between the victim UE 402 and the core network, nor inject valid encrypted traffic, unless the service provider is unfamiliar with standard security recommendations and chooses a weak security context and/or no security context during connection setup.

In some embodiments, the true AMF 412 does not store the actual location information of the UE, but rather the location information may be reported by the gNB. Once the UE accesses the malicious gNB and the attacker employs the authentication relay attack as described above, the current location information of the UE stored by the AMF and the actual location information of the UE may not be consistent, thereby causing the location of the UE to be incorrect.

In various embodiments, there may not be a way to do the following: 1) determining, at the UE or AMF, that a malicious attack is occurring; or 2) inform the UE and AMF about the ongoing malicious attack.

As found herein, the term BS may be used for a base station but may also be replaced with any other radio access node (e.g., BS, eNB, gNB, AP, NR, etc.). Furthermore, the embodiments described herein may also be applicable to various types of networks, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, bluetooth, ZigBee, Sigfoxx, and the like.

In one embodiment, the UE and/or the AMF may detect an ongoing man-in-the-middle attack.

In some embodiments, the victim UE may use a different 5G-GUTI than expected from the actual PLMN of the rogue UE (e.g., as a UE id in a NAS signaling message). The malicious UE may filter out those identifiers or the NAS message may be encrypted with the current security context because the victim UE does not know that its message is rerouted to a different destination. This network-based solution can look at the rationality of the disturbed UE changing geographical location within the time difference of the timestamp of the last known location in the UDM and the new location forced by the malicious UE.

Fig. 5 is a schematic block diagram illustrating network communications 500. The illustrated communication 500 is between a victim UE 502, a fake BS 504, a malicious UE 506, a true BS 508, an AMF 510, and a UDM/AUSF 512. The victim UE 502 and the fake BS 504 are located at the same approximate location in the first PLMN, and the malicious UE 506, the real BS 508, and the AMF 510 are located at the same approximate location in the second PLMN. Each of the communications 500 described herein may include one or more messages. The communication 500 may be for a NAS registration or service request procedure triggered by the victim UE 502.

In one embodiment, in the first communication 514 communicated between the victim UE 502 and the false BS 504, the victim UE 502 performs an RRC establishment procedure with the false BS 504.

In another embodiment, in the second communication 516 transmitted from the fake BS 504 to the malicious UE 506, the fake BS 504 transmits a message to the malicious UE 506 that triggers the malicious UE 506. The malicious UE 506 may be triggered by the first RRC message, the RRC setup request, and/or the RRC setup complete message. In some embodiments, the malicious UE 506 replaces the 502S-TMSI (e.g., NG-5G-S-TMSI) from the victim UE of the RRC establishment request with the malicious UE' S506S-TMSI, such as in the form of a random string. In various embodiments, the RRC layer uses a random string if there is no S-TMSI provided from an upper layer (e.g., NAS layer).

In certain embodiments, in the third communication 518 transmitted between the malicious UE 506 and the true BS 508, the malicious UE 506 performs an RRC establishment procedure with the true BS 508.

In a fourth communication 520 transmitted from the true BS 508 to the AMF 510, in some embodiments, the true BS 508 transmits an initial NAS message to the AMF 510. The initial NAS message may include the 5G-GUTI of the first PLMN and/or may be integrity protected.

Once the AMF 510 in the second PLMN receives the initial NAS message (e.g., any suitable NAS message such as NAS transport, uplink NAS transport, message containing PDU session establishment, authentication, modification, and/or release request, etc.) forwarded from the malicious UE 506 in the fourth communication 520, the AMF 510 may determine 522 that there is no NAS context (e.g., security, access, and/or mobility context) corresponding to the 5G-GUTI, and the AMF 510 may determine 522 that the 5G-GUTI contains a PLMN ID different from the PLMN ID of the second PLMN. The AMF 510 may not be able to check the integrity protection of the NAS message and may not be able to decrypt the NAS container. The victim UE 502 can assume that it is in the same PLMN network as it started on. In some embodiments, the victim UE 502 can send a message with the complete initial NAS message ciphered in the NAS container along with a clear text IE with the entire message integrity protected. The initial NAS message may be a service request, a periodic re-registration message, a mobility re-registration message, and/or another message. If the victim UE 502 is to perform PLMN selection (e.g., due to roaming), the victim UE 502 can send the sui in an initial NAS message that is not protected because it does not have a security context and valid 5G-GUTI assigned from the PLMN in which the victim UE 502 resides. This may be used as a first indication of an authentication relay attack.

If the message received by the AMF 510 is a service request or a registration request, the AMF 510 may reject the request because the victim UE 502 is unknown in the network. In certain embodiments, in a fifth communication 524 transmitted from the AMF 510 to the victim UE 502, the AMF 510 may transmit a NAS message rejection to the victim UE 502. The NAS message rejection may include information indicating that the 5G-GUTI is invalid and/or that the PLMN is mismatched. The victim UE 502 can detect 526 an error cause, re-register, and/or perform cell reselection. For example, the victim UE 502 can implicitly detect that it resides at a false BS based on the cause of the error and can perform cell reselection. The victim UE may internally mark the cell of the false BS as an invalid cell so as not to return to the cell after performing cell reselection.

In various embodiments, if the victim UE 502 does not perform cell reselection, the victim UE 502 itself may initiate an initial registration request through its SUCI and/or UE capabilities via transmission to the AMF 510 in a sixth communication 528 transmitted from the victim UE 502 to the AMF 510. The victim UE 502 can use this as a criterion to identify the false BS 504 because the victim UE 502 assumes that it has successfully registered with the current PLMN for playback by the false BS 504. As a result, in some embodiments, the seventh communication 530 may be skipped.

In some embodiments, in the seventh communication 530 transmitted between the victim UE 502 and the AMF 510, the AMF 510 of the second PLMN does not know the identity of the victim UE 502, and therefore the AMF 510 transmits an identity request and requests a SUCI to the victim UE 502. The identity request is forwarded to the victim UE 502 and the victim UE 502 provides its SUCI to the AMF 510 in an identity reply message.

In some embodiments, in an eighth communication 532 communicated from AMF 510 and UDM/AUSF 512, AMF 510 sends a Nausf _ UE authentication _ authentication request message to UDM/AUSF 512 of the HPLMN of victim UE 502. The request message contains a serving network identifier (e.g., an identifier of the second PLMN). To provide additional location information to the HPLMN, the AMF 510 may send the location of the victim UE 502 according to the GAD. This information may help the HPLMN identify the distance between the last registered location in the UDM/AUSF 512 and the new location from the AMF 510, as well as the time difference.

In various embodiments, the UDM/AUSF 512 may conduct 534 a plausibility check to determine whether it is possible to travel from the last known location to the new location within the time that the current registration request occurred. If implemented in the HPLMN, the HPLMN may reject the authentication request to the AMF 510 by the location mismatch cause value. Alternatively, the UDM/AUSF 512 may provide the last known location of the victim UE 502 including a timestamp to the AMF 510 using the GAD, and the AMF 510 may make a decision as to whether a location difference between the first PLMN and the second PLMN is possible based on the corresponding timestamp. This check may be performed in roaming scenarios based on PLMN ID and non-roaming scenarios based on tracking area ID or global cell ID. The outcome of such a location change assessment may be a factor in detecting man-in-the-middle attacks.

In some embodiments, in a ninth communication 536 transmitted from UDM/AUSF 512 to AMF 510, UDM/AUSF 512 provides a challenge (e.g., SEAF, AKA' challenge, or 5G service environment authentication vector, such as RAND, AUTN, and/or HXRES) to AMF 510.

In some embodiments, the UDM/AUSF 512 may perform normal primary authentication procedures (e.g., 5G AKA or EAP-AKA') in a tenth communication 538 between the victim UE 502, the fake BS 504, the malicious UE 506, the true BS 508, the AMF 510, and/or the UDM/AUSF 512.

Once the authentication is successful, the victim UE 502 derives 540 andUDM/AUSF 512 export 542K_SEAFBut with a different PLMN ID as input to the KDF, resulting in two different keys (e.g., one in the victim UE 502 and one in the UDM/AUSF 512, i.e., K)_SEAF1And K_SEAF2)。

In various embodiments, in an eleventh communication 544 transmitted from UDM/AUSF 512 to AMF 510, UDM/AUSF 512 provides K to AMF 510_SEAF2. AMF 510 derives K_AMFAnd a NAS key.

In some embodiments, a successful authentication process results in a new K_SEAFThis may mean that all derived keys are updated in the AMF 510 and the victim UE 502. Thus, the security mode command procedure may be performed after each authentication procedure.

In certain embodiments, in a twelfth communication 546 transmitted from the AMF 510 to the victim UE 502, the AMF 510 sends a security mode command to the victim UE 502. The secure mode command may use a key (e.g., K)_NASint2) Integrity protection is performed.

Upon receiving the security mode command message, the victim UE 502 can learn that the authentication procedure was successful. The victim UE 502 attempts 548 to verify the integrity of the security mode command, but the victim UE 502 is due to K_SEAFAnd K obtained_NASintKey mismatch of keys (e.g., K)_NASint1Different from K_NASint2) And fails.

Thus, in various embodiments, in the thirteenth communication 550 transmitted from the victim UE 502 to the AMF 510, the victim UE 502 sends a security mode reject message to the AMF 510 that includes an appropriate error cause value (e.g., an integrity check failure). The victim UE 502 may use the victim UE 502's own derived key K_NASint1To integrity protect the message (e.g., a secure mode reject message). The AMF 510 may verify 552 whether it failed to transmit or was a key mismatch, and the AMF 510 may determine a NAS key mismatch based on one or more of: 1) the AMF 510 receives a security mode rejection with an error cause that the victim UE 502 cannot verify the integrity of the previously sent security mode command; and/or 2) the AMF 510 may not be able to verify the integrity of the security mode denial from the victim UE 502 (e.g., the AMF may not be able to verify the integrity of the security mode denialThe AMF 510 may know that the victim UE 502 has performed successful authentication).

In a fourteenth communication 554 transmitted from the AMF 510 to the victim UE 502, in some embodiments, the AMF 510 may reject registration by transmitting a registration reject message to the victim UE 502. The AMF 510 may indicate re-registration to the victim UE 502 after cell or PLMN reselection in order to allow the victim UE 502 to attempt from another (e.g., possibly true) cell.

The victim UE 502 can detect 556 the false BS 504 and/or perform cell reselection. The victim UE 502 can internally mark the cell of the false BS 504 as an invalid cell so as not to return to the cell after performing cell reselection. In addition, AMF 510 may notify 558 UDM/AUSF 512 of the key mismatch. It can be appreciated that one cause of key mismatch may be man-in-the-middle attacks. Especially if the AUSF/UDM 512 considers the result of the rationality check in step 534 and if the victim UE 502 changes to a real cell and starts the initial registration again.

As described herein, by exchanging location information between a UE and an AMF, a man-in-the-middle attack may be detected with fake base stations and malicious UEs located at different locations.

In various embodiments described herein, the AMF may: 1) providing location information with timestamps in a common format to the HPLMN of the victim UE so that the AUSF/UDM can make a plausibility check whether it is possible to travel between two destinations within a given time of two timestamps of the last known location in the UDM and the location of the malicious UE; 2) checking the last known location information retrieved from the HPLMN of the victim UE with the time stamp in the common format in order to make a plausibility check whether it is possible to travel to both destinations within a given time of the two time stamps of the current occurrence request of the AMF; 3) detecting a NAS key mismatch based on a) integrity check failure reported from the UE (e.g., in a security mode reject message) and b) the fact that the primary authentication performed was successful; 4) sending a NAS reject message (e.g., a service request and/or registration reject message) to the UE indicating cell and/or PLMN reselection or invalid GUTI (or no context of the UE) and/or PLMN mismatch; and/or 5) notify the UDM/AUSF about NAS key mismatch.

In some embodiments as described herein, the UDM/AUSF may: 1) providing the AMF of the malicious UE with the last known location information with a timestamp in a generic format, such that the AMF can make a plausibility check whether it is possible to travel between two destinations within a given time of the two timestamps of the last known location and the location of the malicious UE in the UDM; 2) checking the last known location information retrieved from the AMF of the malicious UE with a timestamp in a generic format in order to make a plausibility check whether it is possible to travel between the two destinations within a given time of the two timestamps of the last known location of the UDM of the victim UE and the request currently occurring at the AMF; and/or 3) man-in-the-middle attacks based on fast PLMN changes for the UE and NAS key mismatch errors from the AMF.

In certain embodiments as described herein, the UE may: 1) performing a successful authentication but experiencing an integrity check failure of the received security mode command, the UE may send a security mode reject message including an error cause, e.g., an error cause of the integrity check failure, and/or the UE may integrity protect the message using its derived NAS key, so that the AMF may verify whether the transmission failed or the key mismatch; 2) implicitly and/or internally (e.g., not based on NAS reject message) determines that if the primary authentication is successful, but the security mode command integrity check fails (e.g., due to a false BS being a man-in-the-middle attack), then cell reselection is performed; 3) performing cell reselection after receiving NAS message rejection, whose reject error is due to the 5G-GUTI invalid, in particular if additionally indicating that the PLMN IDs do not match, but the UE previously registered successfully in the PLMN where the fake BS is located and emulated the local BS such that the UE cannot recognize the change; 4) implicit and/or internal (e.g., not based on NAS reject message) determination: performing cell reselection if a timeout is experienced after sending a security mode reject message discarded by an attacker (e.g., a fake BS or a malicious UE), considering a) security mode command integrity check failure, b) successful authentication, and/or c) re-registration or identification request; 5) internally marking the cell of the false BS as an invalid cell so that the cell is not returned to after cell reselection; and/or 6) if the service request is rejected or the re-registration request is rejected, it can be used as a criterion to perform cell and/or PLMN reselection (e.g., due to detection of a false BS) even if the UE assumes a valid security context and successfully registers to the PLMN.

Figure 6 is a flow diagram illustrating one embodiment of a method 600 for secure mode integrity verification. In some embodiments, the method 600 is performed by an apparatus, such as the remote unit 102. In certain embodiments, the method 600 may be performed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

The method 600 may include transmitting 602 a request message to one or more network devices. In some embodiments, method 600 includes authenticating 604 with one or more network devices in response to transmitting the request message. In certain embodiments, method 600 includes receiving 606 a security mode command message in response to successful authentication with one or more network devices. In various embodiments, method 600 includes verifying 608 the integrity of the secure mode command message. In some embodiments, the method 600 includes performing 610 a cell reselection procedure in response to the verification of the integrity of the security mode command message indicating that the security key is invalid.

In some embodiments, the method 600 further comprises transmitting a secure mode deny message in response to the verification of the integrity of the secure mode command message indicating that the secure key is invalid. In some embodiments, method 600 further comprises receiving a registration rejection message in response to transmitting the secure mode rejection message.

In various embodiments, the method 600 further includes, in response to the verification of the integrity of the security mode command message indicating that the security key is invalid, storing information indicating that the cell corresponding to the one or more network devices is an invalid cell. In one embodiment, performing the cell reselection procedure includes initiating initial registration with a second cell different from a first cell corresponding to the one or more network devices.

Fig. 7 is a flow diagram illustrating another embodiment of a method 700 for secure mode integrity verification. In some embodiments, method 700 is performed by an apparatus, such as network element 104. In certain embodiments, method 700 may be performed by a processor executing program code, e.g., a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

The method 700 can include receiving 702 a request message corresponding to a user device. In some embodiments, the method 700 includes, in response to receiving the request message, determining 704 whether the request message is valid based on information corresponding to the user device. In some embodiments, the method 700 includes transmitting 706 a response message indicating to the user equipment that the request message is rejected in response to determining that the request message is invalid.

In some embodiments, the request message comprises a network access stratum registration message, a service request message, a radio resource control setup request message, or some combination thereof. In some embodiments, the information corresponding to the user device includes a globally unique temporary identifier, a user device identifier, or a combination thereof.

In various embodiments, method 700 further comprises successfully authenticating the user device. In one embodiment, the method 700 further comprises receiving a security mode reject message indicating that the security mode command message integrity check performed by the user equipment failed.

FIG. 8 is a flow chart illustrating one embodiment of a method 800 for authentication. In some embodiments, method 800 is performed by an apparatus, such as network element 104. In certain embodiments, the method 800 may be performed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

The method 800 may include receiving 802 an authentication request message corresponding to a user device. In some embodiments, method 800 includes, in response to receiving the authentication request message: determining 804 whether the user equipment has moved from the first public land mobile network to the second public land mobile network within a predetermined time period; determining a likelihood factor indicating a likelihood of the user equipment moving from the first public land mobile network to the second public land mobile network in response to the user equipment having moved from the first public land mobile network to the second public land mobile network within a predetermined time period; and, in response to the likelihood factor being less than a predetermined threshold, transmitting an authentication response message indicating a failed authentication.

In some embodiments, the likelihood factor corresponds to: a distance between the first public land mobile network and the second public land mobile network taking into account a predetermined time period between two registrations corresponding to the first public land mobile network and the second public land mobile network. In some embodiments, method 800 further comprises receiving information indicative of a security key mismatch detected by the user equipment. In various embodiments, method 800 further includes setting a parameter to a value indicative of a potential security issue in response to receiving information indicative of a security key mismatch detected by the user equipment.

In one embodiment, a method comprises: transmitting a request message to one or more network devices; authenticating with one or more network devices in response to transmitting the request message; receiving a security mode command message in response to successful authentication with one or more network devices; verifying the integrity of the secure mode command message; and performing a cell reselection procedure in response to the integrity verification of the security mode command message indicating that the security key is invalid.

In certain embodiments, the method further comprises: in response to the verification of the integrity of the secure mode command message indicating that the secure key is invalid, a secure mode reject message is transmitted.

In some embodiments, the method further comprises, in response to transmitting the secure mode reject message, receiving a registration reject message.

In various embodiments, the method further comprises: in response to the verification of the integrity of the security mode command message indicating that the security key is invalid, storing information indicating that the cell corresponding to the one or more network devices is an invalid cell.

In one embodiment, performing the cell reselection procedure includes initiating initial registration with a second cell different from a first cell corresponding to the one or more network devices.

In one embodiment, an apparatus comprises: a transmitter to transmit a request message to one or more network devices; a processor that authenticates to one or more network devices in response to transmitting the request message; and a receiver that receives the secure mode command message in response to successful authentication with the one or more network devices, wherein the processor: verifying the integrity of the secure mode command message; and, in response to the verification of the integrity of the security mode command message indicating that the security key is invalid, performing a cell reselection procedure.

In some embodiments, the transmitter transmits a secure mode reject message in response to verification of the integrity of the secure mode command message indicating that the secure key is invalid.

In some embodiments, the receiver receives a registration rejection message in response to transmitting the secure mode rejection message.

In various embodiments, the processor stores information indicating that a cell corresponding to the one or more network devices is an invalid cell in response to verification of the integrity of the security mode command message indicating that the security key is invalid.

In one embodiment, the processor performs a cell reselection procedure comprising: the processor initiates initial registration with a second cell different from the first cell corresponding to the one or more network devices.

In one embodiment, a method comprises: receiving a request message corresponding to user equipment; in response to receiving the request message, determining whether the request message is valid based on information corresponding to the user equipment; and, in response to determining that the request message is invalid, transmitting a response message indicating to the user equipment that the request message is denied.

In some embodiments, the request message comprises a network access stratum registration message, a service request message, a radio resource control setup request message, or some combination thereof.

In some embodiments, the information corresponding to the user device comprises a globally unique temporary identifier, a user device identifier, or a combination thereof.

In various embodiments, the method further comprises successfully authenticating the user device.

In one embodiment, the method further comprises receiving a security mode rejection message indicating that a security mode command message integrity check performed by the user equipment failed.

In one embodiment, an apparatus comprises: a receiver that receives a request message corresponding to a user equipment; a processor, responsive to receiving the request message, that determines whether the request message is valid based on information corresponding to the user device; and a transmitter, responsive to determining that the request message is invalid, the transmitter transmitting a response message indicating to the user equipment that the request message is denied.

In some embodiments, the request message comprises a network access stratum registration message, a service request message, a radio resource control setup request message, or some combination thereof.

In some embodiments, the information corresponding to the user device includes a globally unique temporary identifier, a user device identifier, or a combination thereof.

In various embodiments, the processor successfully authenticates the user device.

In one embodiment, the receiver receives a security mode rejection message indicating that a security mode command message integrity check performed by the user equipment failed.

In one embodiment, a method comprises: receiving an authentication request message corresponding to user equipment; and in response to receiving the authentication request message: determining whether the user equipment has moved from the first public land mobile network to the second public land mobile network within a predetermined time period; determining a likelihood factor indicating a likelihood of the user equipment moving from the first public land mobile network to the second public land mobile network in response to the user equipment having moved from the first public land mobile network to the second public land mobile network within a predetermined time period; and transmitting an authentication response message indicating a failed authentication in response to the likelihood factor being less than the predetermined threshold.

In some embodiments, the likelihood factor corresponds to: a distance between the first public land mobile network and the second public land mobile network taking into account a predetermined time period between two registrations corresponding to the first public land mobile network and the second public land mobile network.

In some embodiments, the method further comprises receiving information indicative of a security key mismatch detected by the user equipment.

In various embodiments, the method further comprises setting the parameter to a value indicative of a potential security issue in response to receiving information indicative of a security key mismatch detected by the user equipment.

In one embodiment, an apparatus comprises: a transmitter; a processor; and a receiver that receives an authentication request message corresponding to the user equipment, wherein in response to receiving the authentication request message: the processor determines whether the user equipment has moved from the first public land mobile network to the second public land mobile network within a predetermined time period; in response to the user equipment having moved from the first public land mobile network to the second public land mobile network within a predetermined time period, the processor determining a likelihood factor indicating a likelihood of the user equipment moving from the first public land mobile network to the second public land mobile network; and a transmitter, responsive to the likelihood factor being less than a predetermined threshold, the transmitter transmitting an authentication response message indicating a failed authentication.

In some embodiments, the likelihood factor corresponds to: a distance between the first public land mobile network and the second public land mobile network taking into account a predetermined time period between two registrations corresponding to the first public land mobile network and the second public land mobile network.

In some embodiments, the receiver receives information indicating a security key mismatch detected by the user equipment.

In various embodiments, in response to the receiver receiving information indicating a security key mismatch detected by the user equipment, the processor sets a parameter to a value indicating a potential security issue.

Embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.