Patent Description:
An example of a typical replay attack will be illustrated and described with reference to <FIG>. In this example, the user equipment computing device <NUM>(<NUM>), which detects replay attacks in GNSS systems in accordance with examples of the claimed technology illustrated and described below, is attempting to receive a valid signal from the Global Navigation Satellite System (GNSS) satellites <NUM>(<NUM>)-<NUM>(n). However, in this example the attacker equipment computing device <NUM> is attempting to fool or spoof the user equipment computing device <NUM>(<NUM>) into receiving a fake signal from the attacker equipment computing device <NUM>.

To attempt to fool or spoof the user equipment device <NUM>, the attacker equipment computing device <NUM> receives a valid GNSS signal from one of the GNSS satellites <NUM>(<NUM>)-<NUM>(n) and then either re-transmits it immediately or records it to be played back at a later time. The fake signal from the attacker equipment computing device <NUM> will differ from a valid signal in two ways: (<NUM>) the fake signal will represent the position of the receive antenna for the attacker equipment computing device <NUM>, not the receive antenna for the user equipment computing device <NUM>(<NUM>); and (<NUM>) the fake signal will be delayed in time. Unfortunately, in this replay attack situation, it is very difficult to determine whether a position report is fake because valid signals are used in the transmission of the fake signal.

Document <CIT> relates to an on-board unit that uses Global Navigation Satellite System, GNSS; it describes a solution for the detection of spoofing of an actual position of a vehicle.

Further details are provided in the dependent claims.

A method for countering and detecting a replay attack includes monitoring, by a computing device, a Global Navigation Satellite System (GNSS) time obtained by a GNSS receiver from a GNSS signal from a GNSS satellite. An alert condition for the replay attack is identified, by the computing device, based on at least a detected delay between a universal coordinated time (UTC) and the GNSS time. An alert notification is provided, by the computing device, based on the identification of the alert condition for the replay attack.

A non-transitory machine-readable medium having stored thereon instructions comprising executable code which when executed by one or more processors, causes the processors to monitor a Global Navigation Satellite System (GNSS) time obtained by a GNSS receiver from a GNSS signal from a GNSS satellite. An alert condition for the replay attack is identified based on at least a detected delay between a universal coordinated time (UTC) and the GNSS time. An alert notification is provided based on the identification of the alert condition for the replay attack.

A computing device includes a memory comprising programmed instructions stored thereon and one or more processors configured to be capable of executing the stored programmed instructions to monitor a Global Navigation Satellite System (GNSS) time obtained by a GNSS receiver from a GNSS signal from a GNSS satellite. An alert condition for the replay attack is identified based on at least a detected delay between a universal coordinated time (UTC) and the GNSS time. An alert notification is provided based on the identification of the alert condition for the replay attack.

A system comprising one or more server devices executing in a cloud environment or one or more computing devices, each of the devices having memory comprising programmed instructions stored thereon and one or more processors configured to execute one or more of the stored programmed instructions to monitor a Global Navigation Satellite System (GNSS) time obtained by a GNSS receiver from a GNSS signal from a GNSS satellite. An alert condition for the replay attack is identified based on at least a detected delay between a universal coordinated time (UTC) and the GNSS time. An alert notification is provided based on the identification of the alert condition for the replay attack.

The technology provides a number of advantages including providing methods and devices that effectively detect replay attacks in GNSS systems. With examples of this technology, GNSS replay attacks can be effectively countered by detecting time changes and delays between a valid GNSS signal and a fake signal so that an alarm or other alert on the attack can be provided. Examples of this technology may also eliminate false positives by identifying detected delays related to a multipath condition. Examples of this technology also may utilize neural network detector or other artificial intelligence to identify delays between a UTC and a GNSS time to effectively detect a replay attack and to efficiently identify any multipath condition. Additionally, examples of this technology which utilize a directional antenna may generate and provide an estimated location of attacking computing equipment. Further, examples of this technology may execute various aspects of this technology in a cloud computing environment which can be communicated to user equipment devices.

An environment <NUM>(<NUM>) with an example of a user equipment computing device <NUM>(<NUM>) that detects replay attacks in GNSS systems is illustrated in <FIG>. In this example, the environment includes the user equipment computing device <NUM>(<NUM>), GNSS satellite transmitters <NUM>(<NUM>)-<NUM>(n), the attacker equipment computing device <NUM>, and an optional UTC source <NUM>, although other types and/or numbers of other systems, devices, components, and/or other elements in other configurations may be used. This technology provides a number of advantages including providing methods and devices that counter GNSS replay attacks by detecting time changes and delays between a valid GNSS signal and a fake signal so that an alarm or other alert about the attack can be provided.

Referring more specifically to <FIG>, the user equipment computing device <NUM>(<NUM>) in this example includes at least one processor <NUM>, a memory <NUM>, a communication interface <NUM>, a GNSS receiver <NUM> which includes an antenna <NUM>(<NUM>), a clock control device <NUM>, and one or more GNSS disciplined oscillators <NUM>(<NUM>)-<NUM>(n) which are coupled together by a bus or other communication link <NUM>, although the user equipment computing device <NUM>(<NUM>) can include other types and/or numbers of elements in other configurations.

The processor <NUM> of the user equipment computing device <NUM>(<NUM>) may execute programmed instructions stored in the memory for the any number of the functions or other operations illustrated and described by way of the examples herein. The processor <NUM> of the user equipment computing device <NUM>(<NUM>) may include one or more CPUs or other processors with one or more processing cores, for example, although other types of processor(s) can also be used.

The memory <NUM> of the user equipment computing device <NUM>(<NUM>) stores these programmed instructions for one or more aspects of the present technology as illustrated and described herein, although some or all of the programmed instructions could be stored elsewhere. By way of example, one or aspects of the technology may be executed in a cloud computing environment <NUM> by one or cloud computing servers <NUM>(<NUM>)-<NUM>(n) as illustrated and described with reference to <FIG> herein. A variety of different types of memory storage devices, such as random access memory (RAM), read only memory (ROM), hard disk (HDD), solid state drives (SSD), flash memory, or other computer readable medium which is read from and written to by a magnetic, optical, or other reading and writing system that is coupled to the processor(s) <NUM>, can be used for the memory <NUM>.

Accordingly, the memory <NUM> of the user equipment computing device <NUM>(<NUM>) can store application(s) that can include executable instructions that, when executed by the user equipment computing device <NUM>(<NUM>), cause the user equipment computing device <NUM>(<NUM>) to perform actions, such as to transmit, receive, or otherwise process signals related to navigation or other positioning, to detect and counter GNSS replay attacks, and to perform other actions illustrated and described by way of the examples herein with reference to <FIG>. The application(s) can be implemented as modules or components of other application(s). Further, the application(s) can be implemented as operating system extensions, modules, plugins, or the like. In this particular example, the memory <NUM> includes a replay detection module <NUM> that includes programmed instructions to detect and counter GNSS replay attacks as illustrated and described by way of the examples herein. Additionally, in this particular example, the memory <NUM> also includes a neural network detector <NUM> which has been trained with machine learning to detect delays in GNSS signals which indicate a replay attack and to identify a multipath condition as illustrated and described by way of the examples herein, although the neural network detector can be trained with machine learning to identify other aspects to assist with the accurate detection of a replay attack.

The communication interface <NUM> of the user equipment computing device <NUM>(<NUM>) operatively couples and communicates between the user equipment computing device <NUM>(<NUM>) and one or more GNSS satellite transmitters <NUM>(<NUM>)-<NUM>(n) which are all coupled together by one or more communication network(s), although other types and/or numbers of connections and/or configurations to other devices and/or elements can be used. By way of example only, the communication network(s) can include local area network(s) (LAN(s)) or wide area network(s) (WAN(s)), and/or wireless networks by way of example only, although other types and/or numbers of protocols and/or communication networks can be used.

The GNSS receiver <NUM> with the antenna <NUM>(<NUM>), the control clock device <NUM> and the one or more GNSS disciplined oscillators <NUM>(<NUM>)-<NUM>(n) of the user equipment computing device <NUM>(<NUM>) are coupled together and are configured to operate as a GNSS receiver timing system, although the user equipment computing device <NUM>(<NUM>) may have other receiver timing devices or may be otherwise coupled or connected to one or more external receiver timing devices. The GNSS receiver <NUM> is configured to capture signals, such as data packets, from GNSS satellites <NUM>(<NUM>)-<NUM>(n) when navigation or other positioning is to be determined, although other types of receivers may be used. In this example, each of the one or more GNSS disciplined oscillators <NUM>(<NUM>)-<NUM>(n) is an oscillator whose output is controlled to agree with the signals broadcast by GNSS satellites <NUM>(<NUM>)-<NUM>(n), although other types of controlled or disciplined oscillators or other timing elements with similar accuracy may be used. Additionally, in this example the antenna <NUM>(<NUM>) is an omni-directional antenna, although other types of antennas may be used, such as a directional antenna <NUM>(<NUM>) for user equipment device <NUM>(<NUM>) as illustrated in <FIG>. In this example, the control clock device <NUM> is configured to manage the operations of the one or more disciplined oscillators <NUM>(<NUM>)-<NUM>(n) and maintains the UTC time from the UTC source <NUM>, although the control clock device <NUM> may have other types and/or numbers of other functions. Further, in this example, each of the one or more GNSS disciplined oscillators <NUM>(<NUM>)-<NUM>(n) is an oscillator with at least about <NUM>-<NUM> stability to provide in these examples the necessary accuracy for the calculated measurements, although other stability ranges may be used. By way of example only, each of the one or more GNSS disciplined oscillators <NUM>(<NUM>)-<NUM>(n) may be a TCXO - Temperature Compensated quartz crystal Oscillator with at least about <NUM>-<NUM> stability, an OCXO - Oven Controlled quartz crystal Oscillator with about a <NUM>-<NUM> - <NUM>-<NUM> stability, or an Atomic Oscillator with about a <NUM>-<NUM> - <NUM>-<NUM> stability.

In this example, GNSS satellite transmitters <NUM>(<NUM>)-<NUM>(n) are illustrated, although other types and/or numbers of satellite transmitters may be used. The GNSS satellites <NUM>(<NUM>)-<NUM>(n) are configured to broadcast GNSS signals which can be received and processed by the user equipment computing device <NUM>(<NUM>) for positioning and navigation.

The attacker equipment computing device <NUM> in this example includes at least one processor, a memory, a communication interface, a GNSS receiver which includes an antenna, which are coupled together by a bus or other communication link, although the attacker equipment computing device <NUM> can include other types and/or numbers of elements in other configurations. The attacker equipment computing device <NUM> may receive signal and may generate a fake signal which is transmitted to user equipment device <NUM>(<NUM>) in the exemplary environment shown in <FIG> and user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) in the exemplary environment shown in <FIG>.

The UTC source <NUM> may provide a UTC time to the user equipment computing device <NUM>(<NUM>) which can then be maintained by the clock control device <NUM> and the one or more disciplined oscillators <NUM>(<NUM>)-<NUM>(n) in the user equipment computing device <NUM>(<NUM>).

Referring to <FIG>, another exemplary environment <NUM>(<NUM>) with multiple user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>), a cloud computing environment <NUM> with cloud computing server devices <NUM>(<NUM>)-<NUM>(n), and an attacker equipment computing device <NUM> is illustrated. The user equipment computing devices <NUM>(<NUM>) and <NUM>(<NUM>) are the same in structure and operation as the user equipment computing device <NUM>(<NUM>), except as otherwise illustrated and described by way of the examples herein. As noted earlier, in this example user equipment computing devices <NUM>(<NUM>) and <NUM>(<NUM>) have an omni-directional antenna <NUM>(<NUM>) while user equipment computing device <NUM>(<NUM>) has a directional antenna <NUM>(<NUM>) which can be used to identify an estimated location of the attacker equipment computing device <NUM>. Further, in this example one or more aspects of the claimed technology, such as the replay detection module <NUM> and/or the neural network detector <NUM>, may in part or all be executed by one or more of the cloud computing server devices <NUM>(<NUM>)-<NUM>(n) in the cloud computing environment <NUM>. For ease of illustration, the cloud computing environment <NUM> coupled to the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) is illustrated in multiple clouds in <FIG>. Each of the cloud computing server devices <NUM>(<NUM>)-<NUM>(n) may include at least one processor, a memory, and a communication interface which are coupled together by a bus or other communication link, although each of the cloud computing server devices <NUM>(<NUM>)-<NUM>(n) can include other types and/or numbers of elements in other configurations.

Although the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>), the GNSS satellite transmitters <NUM>(<NUM>)-<NUM>(n), attacker equipment computing device <NUM>, optional UTC source <NUM>, and optional cloud computing environment <NUM> with cloud computing server devices <NUM>(<NUM>)-<NUM>(n) are illustrated and described in the illustrative examples herein, other types and/or numbers of systems, devices, components, and/or elements in other topologies can be used. It is to be understood that the systems of the examples described herein are for exemplary purposes, as many variations of the specific hardware and software used to implement the examples are possible, as will be appreciated by those skilled in the relevant art(s).

Portions of all of the examples of the technology illustrated and described herein may also be embodied as one or more non-transitory computer readable media having instructions stored thereon for one or more aspects of the present technology. The instructions in some examples include executable code that, when executed by the processor of the user equipment computing device <NUM>(<NUM>), cause the processor to carry out steps necessary to implement the methods of the examples of this technology that are illustrated and described herein.

Exemplary methods for detecting and countering GNSS replay will now be described with reference to <FIG>. Referring more specifically to <FIG>, in these examples in step <NUM> the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) begin the initialization by obtaining a UTC time from a GNSS signal received by the GNSS receiver <NUM> with the antenna <NUM>(<NUM>) or <NUM>(<NUM>) from one of the GNSS satellites <NUM>(<NUM>)-<NUM>(n) from a safe zone of no known attacks, or other detection methods for jamming and spoofing by way of example, although the UTC time can be UTC can be obtained in other manners, such as from another UTC source <NUM> by way of example only.

In the example shown in <FIG>, the control clock device <NUM> and one of the disciplined oscillators <NUM>(<NUM>)-<NUM>(n) in the user equipment computing device <NUM>(<NUM>) may be used to maintain an internal representation of the obtained UTC time. In this example, the user equipment computing device <NUM>(<NUM>) may determine if the internal UTC time is accurate by comparing it to the obtained UTC time from the UTC source <NUM> in this example. This determination may include statistical averaging over time and spoofing detection on the obtained UTC time by way of example, although other types of determinations can be made. The same approach may be used with the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) shown in the example in <FIG>.

In examples of this technology, one or more of the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) may use multiple disciplined oscillators <NUM>(<NUM>)-<NUM>(n) to maintain an internal representation of the obtained UTC time, although other numbers may be used. Additionally, in other examples of this technology, each of the disciplined oscillators <NUM>(<NUM>)-<NUM>(n) may have been disciplined from an obtained GNSS signal from one of the satellite transmitters <NUM>(<NUM>)-<NUM>(n) individually and at separate times from each other. In this example, while one of the oscillators <NUM>(<NUM>)-<NUM>(n) is being disciplined, the other ones of the oscillators <NUM>(<NUM>)-<NUM>(n) are not. This protects the other ones of the oscillators <NUM>(<NUM>)-<NUM>(n) from being corrupted by a fake GNSS signal in the disciplining process. As a result, at most, only one of the oscillators <NUM>(<NUM>)-<NUM>(n) is corrupted.

Accordingly, in the example shown in <FIG>, the user equipment computing device <NUM>(<NUM>) when obtaining a UTC from two or more of the disciplined oscillators <NUM>(<NUM>)-<NUM>(n) to try counter and detect a replay attack, may employ a majority voting scheme to determine the correct UTC time to use to compare against the received GNSS signal which needs to be checked for a possible replay attack. For example, the majority voting scheme being executed may use two of the disciplined oscillators <NUM>(<NUM>)-<NUM>(n) and the external UTC source <NUM> or may use three disciplined oscillators <NUM>(<NUM>)-<NUM>(n) or some other number of disciplined oscillators to identify the reliable UTC. Further, in this example, the user equipment computing device <NUM>(<NUM>) may identify the one of the oscillators <NUM>(<NUM>)-<NUM>(n) which is not in conformance with the others and therefore assumed to be corrupted and may take that one of the oscillators <NUM>(<NUM>)-<NUM>(n) offline or otherwise ignore it until it can be reset. As illustrated in these examples, the UTC time can be obtained from different sources and when multiple sources are used a majority or other voting scheme can be used to obtain an accurate UTC. The same approach can be used with the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) shown in the example in <FIG>.

Referring back to <FIG>, in step <NUM> the user equipment computing device <NUM>(<NUM>) determines if the internal UTC time is accurate by comparing it to the obtained UTC time from the UTC source <NUM> in this example. This determination may include statistical averaging over time and spoofing detection on the obtained UTC time by way of example, although other types of determinations can be made. The same approach can be used with the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) in the example shown in <FIG>.

If in step <NUM> the user equipment computing device <NUM>(<NUM>) determines the internal UTC time is not accurate, then the No branch may be taken back to step <NUM> to obtain another UTC time as described above and possibly from another source. If in step <NUM> the user equipment computing device <NUM>(<NUM>) determines the internal UTC time accurately matches the obtained UTC time then the Yes branch is be taken to step <NUM>.

In step <NUM>, once the user equipment computing device <NUM>(<NUM>) has achieved an accurate UTC time synchronization internally with the control clock device <NUM> and the disciplined oscillators <NUM>(<NUM>)-<NUM>(n), then the user equipment computing device <NUM>(<NUM>) enters a normal operation state in this state. In the normal operation state, the user equipment computing device <NUM>(<NUM>) compares the internal UTC synchronized time to a GNSS time obtained from one or more of the GNSS satellites <NUM>(<NUM>)-<NUM>(n) received by the GNSS receiver <NUM> with the antenna <NUM>(<NUM>). As noted earlier, in examples of this technology the user equipment computing device <NUM>(<NUM>) when obtaining a UTC to try counter and detect a replay attack, may employ a majority voting scheme to determine the correct UTC time to use to compare against the received GNSS signal which needs to be checked for a possible replay attack. The same approach can be used with the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) in the example shown in <FIG>.

In step <NUM>, the user equipment computing device <NUM>(<NUM>) may determine if there is any discrepancy, i.e. a delay between the GNSS time and the internal UTC synchronized time. Accordingly, if in step <NUM>, the user equipment computing device <NUM>(<NUM>) determines there is no discrepancy, then the No can be taken back to step <NUM> to continue with normal operations. If in step <NUM>, the user equipment computing device <NUM>(<NUM>) determines there is a discrepancy which indicates the possibility of a replay attack, then the Yes branch is taken to step <NUM>.

In step <NUM>, the user equipment computing device <NUM>(<NUM>) determines if the GNSS time is delayed from the internal UTC synchronized time. In this example, the user equipment computing device <NUM>(<NUM>) may determine when the detected delay between the UTC and the GNSS time is above a set threshold and identify the alert condition indicting a replay attack when the determination indicates the detected delay is above the set threshold, although other manners for detecting the alert condition may be used. The same approach can be used with the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) in the example shown in <FIG>. Additionally, in the example shown in <FIG>, one or more of the cloud computing server devices <NUM>(<NUM>)-<NUM>(n) in the cloud computing environment <NUM> may communicate with the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) and may make this determination. Further, one or more of the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) and/or one or more of the cloud computing server devices <NUM>(<NUM>)-<NUM>(n) in the cloud computing environment <NUM> may train a neural network <NUM> on a subset of data with detected delays corresponding to replay attacks and another subset of data with detected delays not corresponding to replay attacks to dynamically adjust thresholds and/or to more accurately detect replay attacks.

In other examples of this technology, the user equipment computing device <NUM>(<NUM>) may be configured to dynamically adjust the threshold based on an analysis of data of any identified alert conditions received by, for example, one or more other computing devices <NUM>(<NUM>) and <NUM>(<NUM>) located within a set geographic region, i.e. a set or defined region around the user equipment computing device <NUM>(<NUM>) at the same time or within some set or otherwise stored time period. In other examples of the technology, one or more of the cloud computing servers <NUM>(<NUM>)-<NUM>(n) in the cloud computing environment <NUM> may be used to monitor data from each of the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) related to detected replay attacks and may accordingly raise or lower the threshold. For example, if one of the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) within the same set geographic area and time period detects a replay attack then the threshold for detecting a replay attack for the other ones of the user computing devices <NUM>(<NUM>)-<NUM>(<NUM>) may be lowered for a period of time and/or another alert or action may be implemented.

The discrepancy or time delay of a replay attack signal being detected by one or more of the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) in the examples herein will depend on several factors, such as: (<NUM>) the length of cabling between the receive antenna, receiver, transmitter, and transmitting antenna in the attacker equipment computing device <NUM>; (<NUM>) electronics delay of the receiver and transmitter in the attacker equipment computing device <NUM>; (<NUM>) any optional delay inserted by recording and then playing back by the attacker equipment computing device <NUM>; and (<NUM>) a standoff range between the attacker equipment computing device <NUM> and the user equipment computing device <NUM>(<NUM>).

If in step <NUM>, the user equipment computing device <NUM>(<NUM>) determines the GNSS time is not delayed from the internal UTC synchronized time, then the No branch is taken to step <NUM>. In step <NUM>, the user equipment computing device <NUM>(<NUM>) determines if there is spoofing from a simulated signal. If we have arrived at this point, then the GNSS time precedes the internal UTC synchronized time. This is an indication to the user equipment computing device <NUM>(<NUM>) that either there is a simulated signal attack occurring, i.e. spoofing and not a replay attack, although other manners for detecting spoofing from a simulated signal may be used, or that the internal UTC disciplined oscillator is in error, i.e., no longer in sync with the true UTC synchronized time. In other examples of this technology, one or more of the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) and/or one or more of the cloud computing server devices <NUM>(<NUM>)-<NUM>(n) in the cloud computing environment <NUM> may also train a neural network <NUM> on a subset of data with detected delays corresponding to a multipath condition and another subset of data with detected delays not corresponding to a multipath condition to more accurately identify a multipath condition.

If in step <NUM>, the user equipment computing device <NUM>(<NUM>) determines there is no spoofing from a simulated signal, then the GNSS time is correct and the No branch can be taken back to step <NUM> to re-initialize the internal UTC time to get it back into synchronization. If in step <NUM>, the user equipment computing device <NUM>(<NUM>) determines there is spoofing from a simulated signal, then the Yes branch is taken to step <NUM> where an alarm of a spoofing attack is provided to the user equipment computing device <NUM>(<NUM>), although the alarm could be provided to other devices and/or other types of alerts may be provided.

If back in step <NUM>, the user equipment computing device <NUM>(<NUM>) determines the GNSS time is delayed from the internal UTC synchronized time, then the Yes branch is taken to step <NUM>. In step <NUM>, the user equipment computing device <NUM>(<NUM>) determines if the delay is the result of a multipath condition.

Detection of a time delay indicating a replay attacked can be complicated by a multipath condition. GNSS radio signals from the GNSS satellites12(<NUM>)-<NUM>(n) take both a direct path to the GNSS receiver <NUM> of the user equipment computing device <NUM>(<NUM>) and a bounce path, reflecting off of nearby objects or the ground, for example. These signals are typically weaker and can be usually rejected by other means, but there are certain circumstances where they can be strong enough to corrupt the reception. The bounced paths are always longer than the direct path so reception of a multipath signal may mimic a fake replay attack signal.

The multipath signal can be differentiated from a fake signal by the user equipment computing device <NUM>(<NUM>) by comparing the delay times reported by each of multiple ones of the GNSS satellites <NUM>(<NUM>)-<NUM>(n). For the fake signal from a replay attack, the added delay for all GNSS satellite signals will be identical, however for a multipath condition the user equipment computing device <NUM>(<NUM>) will detect a variation from one of the GNSS satellites <NUM>(<NUM>)-<NUM>(n) to another one of the GNSS satellites <NUM>(<NUM>)-<NUM>(n) because the angle of arrivals will all be different, creating unique multipaths for each of the GNSS satellites <NUM>(<NUM>)-<NUM>(n). The same approach can be used by the user equipment computing devices <NUM>(<NUM>)-<NUM>(<NUM>) and/or the cloud computing server devices <NUM>(<NUM>)-<NUM>(n) in the cloud computing environment <NUM> in the example in <FIG>.

Accordingly, if in step <NUM> the user equipment computing device <NUM>(<NUM>) determines the delay is the result of a multipath condition, then the Yes branch taken back to step <NUM> to continue with normal operations. However, if in step <NUM> the user equipment computing device <NUM>(<NUM>) determines the delay is not the result of a multipath condition, then the No branch is taken to step <NUM> where an alarm of a spoofing attack is provided to the user equipment computing device <NUM>(<NUM>), although the alarm could be provided to other devices and/or other types of alerts may be provided.

In examples of this technology as illustrated in <FIG>, the user equipment computing device <NUM>(<NUM>) may receive direction of signal arrival data by a directional antenna <NUM>(<NUM>) of the GNSS receiver <NUM>. The user equipment computing device <NUM>(<NUM>) may determine an estimated location of a source of the fake GNSS signal based on the direction of the signal arrival data when the identification indicates the alert condition for the replay attack. The user equipment computing device <NUM>(<NUM>) may provide the estimated location of the source of the replay attack, such as the location of the attacker equipment computing device <NUM>.

In other examples, an attacker equipment computing device <NUM> may intentionally insert delay so the perceived difference between a valid time and a replay attack time aligns with an integer second, minute, hour or day boundary. This makes the replay attack less noticeable, especially during leap second step changes that occur on occasional June <NUM> or December <NUM> boundaries. The detection algorithm in the user equipment computing device <NUM>(<NUM>) may be further configured to take into account these cases and detect jumps not only in the fractional second reported values, but also the integer second and time of week reported values. In further examples, the replay detection method is also valid for applications where the user equipment computing device <NUM>(<NUM>) is fixed, not mobile, such as applications where GNSS reception is being used for determining precise time.

Accordingly, as illustrated and described by way of the examples herein this technology provides methods and devices that effectively detect replay attacks in GNSS systems. Examples of this technology may also eliminate false positives by identifying detected delays related to a multipath condition. Examples of this technology also may utilize neural network detector or other artificial intelligence to identify delays between a UTC and a GNSS time to effectively detect a replay attack and to efficiently identify any multipath condition. Additionally, examples of this technology which utilize a directional antenna may generate and provide an estimated location of attacking computing equipment. Further, examples of this technology may execute various aspects of this technology in a cloud computing environment which can be communicated to user equipment devices.

Claim 1:
A method for countering and detecting a replay attack, the method comprising:
monitoring, by a computing device, a Global Navigation Satellite System, GNSS, time obtained by a GNSS receiver from a GNSS signal from a GNSS satellite;
identifying, by the computing device, an alert condition for the replay attack based on at least a detected delay between a universal coordinated time, UTC, and the GNSS time, wherein the identifying the alert condition for the replay attack further comprises:
dynamically adjusting, by the computing device, a threshold based on an analysis of data of any identified alert conditions;
determining, by the computing device, when the detected delay between the UTC and the GNSS time is above the dynamically adjusted threshold; and
providing, by the computing device, an alert notification based on the identification of the alert condition for the replay attack when the determination indicates the detected delay is above the threshold.