System, method and apparatus to prevent geofenced location spoofing of a client device

The Geofence Status Device, using cryptographic techniques and a Trusted Execution Environment, addresses the vulnerability of geofencing to spoofing attacks by ensuring reliable geofence determination, enhancing security and privacy without revealing precise location data.

WO2026142987A1PCT designated stage Publication Date: 2026-07-02THALES DIS CPL USA INC

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
THALES DIS CPL USA INC
Filing Date
2025-12-22
Publication Date
2026-07-02

Smart Images

  • Figure US2025060864_02072026_PF_FP_ABST
    Figure US2025060864_02072026_PF_FP_ABST
Patent Text Reader

Abstract

A system or method for attesting to a server that a client device is within or outside a geofence boundary specified by the server can include a geofence status device coupled to the client device using one or more processors that perform certain operations. The operations can include receiving a geofence boundary requirement sent by the server to the client device along with a request for a geofence status, assigning a geofence status as true when the client device and the geofence status device are determined as being within the geofence boundary specified by the server, assigning a geofence status as false when the client device or the geofence status device or both are determined as being outside the geofence boundary specified by the server, signing the geofence status to provide a signed geofence status, and returning the geofence status to the server.
Need to check novelty before this filing date? Find Prior Art

Description

SYSTEM, METHOD AND APPARATUS TO PREVENT GEOFENCED LOCATION SPOOFING OF A CLIENT DEVICE TECHNICAL FIELD

[0001] The present embodiments relate generally to systems and methods of anti-spoofing. More particularly, the system, method, and apparatus relate to prevention of geofenced location spoofing of a client device.BACKGROUND

[0002] Device spoofing is the act of disguising or faking a device’s identity by altering or masking its unique characteristics. It can be done in a variety of ways, including IP address spoofing, MAC address spoofing, browser user agent spoofing, location spoofing, and more.

[0003] While the techniques and types vary, they all share a common goal, namely to deceive systems into accepting a fraudulent identity. The end result includes problems like financial losses or compromised data security.

[0004] Device spoofing typically occurs by altering data sent from a device. Some of the common tools and methods of spoofing include proxy servers that act as intermediaries, masking the original device details or virtual private networks (VPNs) that can obscure a user’s real IP address and making it appear as if the device is connecting from a different location, and browser extensions or tools that can be designed to change browser characteristics to hide a user’s identity. Various types of device spoofing include IP address, browser, GPS, MAC address, IME I, and WiFi SSID spoofing.

[0005] Some secure communication techniques rely on geofencing.Geofencing is a virtual boundary around a physical location that uses GPS, radio frequency identification (RFID), WiFi, or cellular data to identify when a device enters or exits the area. Thus, location spoofing such as WiFi SSID spoofing might involve the creation of a fake WiFi network with the same name (SSID) as alegitimate one, luring users into connecting to it. This method is often used in phishing attacks to intercept sensitive data, spread malware, and conduct Man-in-the-Middle attacks. Once connected to the spoofed network, attackers can easily capture login credentials and other personal information from unsuspecting users. In the case of GPS spoofing, several ways to protect against such spoofing including the use of cryptography, signal-distortion detection, and direction-of-arrival sensing provide some protection, but no single method can stop every spoof.

[0006] All of the subject matter discussed in this Background section is not necessarily prior art and should not be assumed to be prior art merely as a result of its discussion in the Background section. Along these lines, any recognition of problems in the prior art discussed in the Background section or associated with such subject matter should not be treated as prior art unless expressly stated to be prior art. Instead, the discussion of any subject matter in the Background section should be treated as part of the inventor's approach to the particular problem, which, in and of itself, may also be inventive.SUMMARY

[0007] In some embodiments, system for attesting to a server that a client device is within or outside a geofence boundary specified by the server can include a geofence status device coupled to the client device and one or more processors and memory operatively coupled to the one or more processors, where the memory includes computer instructions which when executed by the one or more processors causes the one or more processors to perform certain operations.

[0008] In some embodiments, the operations can include receiving a geofence boundary requirement sent by the server to the client device along with a request for a geofence status, assigning a geofence status as true when the client device and the geofence status device are determined as being within the geofenceboundary specified by the server, assigning a geofence status as false when the client device or the geofence status device or both are determined as being outside the geofence boundary specified by the server, signing the geofence status to provide a signed geofence status, and returning the geofence status to the server.

[0009] In some embodiments, the client device sends a service request along with the signed geofence status to the server. In some embodiments, the server checks a signature of the signed geofence status and checks the geofence boundary requirement. In some embodiments, the server provides service to the client device if the signature of the geofence status is valid and the geofence status is true. In some embodiments, the server denies service to the client if the signature of the geofence status is invalid or the geofence status is false.

[0010] In some embodiments, the geofence status device further uses encryption to encrypt messages sent to the client device or server. In some embodiments, the encryption is achieved by having the geofence status device operating in a Trusted Execution Environment (TEE) containing geofence status device symmetric keys that perform cryptographic operations.

[0011] In some embodiments, the server adds an encrypted service requirement to server requirements to provide encrypted service requirements and the geofence status device checks the encrypted service requirements, adds an encryption public key to the signed message. In some embodiments, the server further checks the encrypted service requirements. In some embodiments, in response to checking the signature and service geofence requirement, the server encrypts the service with a session key, extracts the geofence encryption public key from the signed message, encrypts the session key with the geofence encryption public key and provides service encrypted with the session key. In some embodiments, the client device provides the encrypted session for decryption to the geofence status device and the geofence status device decrypts the encrypted session key with an encryption private key andreturns a plain session key to the client device whereupon the client device decrypts a payload with the plain session key to access service.

[0012] In some embodiments, the geofence status device is an independent and separate device from the client device and physically connected to the client device. In some embodiments, the geofence status device is embedded within the client device.

[0013] In some embodiments, a processor-implemented method for attesting to a server that a client device is within or outside a geofence boundary specified by the server includes a geofence status device coupled to the client device that performs certain operations.

[0014] In some embodiments, the operations can include receiving a geofence boundary requirement sent by the server to the client device along with a request for a geofence status, assigning a geofence status as true when the client device and the geofence status device are determined as being within the geofence boundary specified by the server, assigning a geofence status as false when the client device or the geofence status device or both are determined as being outside the geofence boundary specified by the server, signing the geofence status to provide a signed geofence status, and returning the geofence status to the server.

[0015] In some embodiments, the geofence status device is further configured to add an encryption public key to a message to the server and to decrypt an encrypted session key from the server with an encryption private key.

[0016] In some embodiments the geofence status device (506) assigns a geofence status as true (704) when the geofence status device determines that externally identifiable signal sources are where they are expected to be if the device is where it believes that it is and the status as false (706) otherwise.

[0017] In some embodiments the geofence status device (506) assigns a geofence status as false (706) when the geofence status device determines that the client device is not in proximity.BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of this description, illustrate embodiments consistent with the embodiments and, together with the description, serve to explain the principles of the embodiments.

[0019] FIG. 1 illustrates a block diagram of a system for preventing geofenced location spoofing of a client device where both a client device and a geofence status device is inside a geofence boundary in accordance with the embodiments;

[0020] FIG. 2 illustrates a block diagram of a system for preventing geofenced location spoofing of a client device where the client device is outside the geofence boundary and the geofence status device is inside the geofence boundary in accordance with the embodiments;

[0021] FIG. 3 illustrates a block diagram of a system for preventing geofenced location spoofing of a client device where neither the client device nor the geofence status device is inside the geofence boundary in accordance with the embodiments;

[0022] FIG. 4 illustrates a system where both the client device and the geofence status device use communication dongles to ensure proximity between the client device and the geofence status device in accordance with the embodiments;

[0023] FIG.5 illustrates a flow or timing diagram showing the possible sequential steps of a method of preventing geofenced location spoofing of a client device in accordance with the embodiments;

[0024] FIG. 6 illustrates a more detailed flow or timing diagram for preventing geofenced location spoofing of the client device in accordance with the embodiments;

[0025] FIG. 7 illustrates a flowchart of a method for preventing geofenced location spoofing of a client device in accordance with the embodiments.

[0001] Specific embodiments have been shown by way of example in the foregoing drawings and are hereinafter described in detail. The figures and written description are not intended to limit the scope of the inventive concepts in any manner. Rather, they are provided to illustrate the inventive concepts to a person skilled in the art by reference to particular embodiments.DETAILED DESCRIPTION

[0002] Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise represented. The implementations set forth in the following description of exemplary embodiments do not represent all implementations consistent with the embodiments. Instead, they are merely examples of systems, apparatuses and methods consistent with aspects related to the embodiments as recited in the appended claims.

[0003] The current embodiments overcome the vulnerability that existing geofencing technologies can be easily spoofed. The generation of existing location data is typically provided by hardware or services hosted with a Client Device. Client Devices need to be treated as potentially hostile environments. Furthermore, providing accurate location data such as GPS coordinates can have privacy and tracking concerns.

[0004] The embodiments solve the technical problem by creating a system that attests to a server device that a client device is either within or without of a Geofence boundary that is specified by the server. More particularly, the embodiments introduce an anti-spoofing mechanism that ensures reliable geofencing determination for a client devices’ location during server requests.

[0005] In some embodiments, this requires the manufacture of a physical device such as a Geofence Status Device or GSD 106 as illustrated in the system100 of FIG. 1 that is separate and apart from a client device 104 that communicates with a server 102. Rather than having the GSD 106 embedded within the potentially hostile Client Device, the GSD 106 is separate and needs to couple or connect to the Client Device 104. The Geofence Status Device 106 and the Server 102 can share signature keys to prevent the potentially hostile Client Device 104 from acting as a Man in the Middle (MitM) to alter a Geofence Status. The GSD 106 also contains a Trusted Execution Environment (TEE) containing the GSD symmetric keys that perform cryptographic operations. These keys can be used to secure all or any of the communications between devices to be both signed and encrypted.

[0006] The server 102 can confidently determine whether the client 104 is within a designated geofence boundary or not when a client device sends attested geofence status to a server. The server can then make informed decisions and execute appropriate operations when restricted by sovereignty factors.FIG. 1 illustrates a block diagram of a system for preventing geofenced location spoofing of a client device where both a client device and a geofence status device is inside a geofence boundary in accordance with the embodiments.Here, in this ideal environment, everything is where it should be, namely that the client device 104 and GSD 106 are both within or inside a server defined geofence boundary 108. The embodiments detect this condition and provides a cryptographically signed “TRUE” Geofence status response in a geofence status data blob 112 for example. “TRUE” means that both the client device 104 and GSD 106 are within the Geofence boundary 108.

[0007] However, a bad actor may move the client device outside (110 or 210) of the Geofence but leave the Geofence Status Device inside as in the case shown in the system 200 of FIG. 2. In other words, the GSD 106 resides within or inside a server defined geofence 208 while a client device 104 resides outside the geofence boundary 208 in area 210. The embodiments detect this attack andprovides a cryptographically signed “FALSE” Geofence status response. A “FALSE” designation for the Geofence status would mean that either or both the client device or GSD are outside the geofence 208.

[0008] In some instances, a bad actor may position both the client device 104 and the Geofence Status Device 106 outside of a Geofence boundary 308 as shown in the system 300 of FIG. 3. The bad actor could then introduce false signals within the Geofence Status Devices’ environment to fool the Geofence Status Device into believing it is inside the Geofence. Thus, spoofing its actual location. The embodiments herein detect this attack and provides a cryptographically signed “FALSE” Geofence status response since both the client device 104 and GSD 106 are outside the Geofence boundary 308 in area 310.

[0009] In some embodiments, the Geofence status response may optionally contain a GSD encryption public key used for End to End Protection (E2EP) between Server and GSD. This arrangement would provide additional security by protecting all the communication links between the server and GSD.

[0010] The mechanisms by which the Geofence Status Device 106 can achieve the detections include externally identifiable signal sources but are not limited to use of GPS Satellite data providing precise location, GPS Satellite monitoring providing an ever-changing list of satellites that should be in view from the location identified, aircraft location monitoring providing an ever-changing list of airplanes that should be overhead of the location identified, radio frequency or RF sources monitoring providing a constant list of RF towers that should be detectable from the location identified, monitoring of signal strengths to identify spoofing injection of overpowered sources, Inertial Measurement Unit (IMU) that invalidates previous Geofence status conditions when movement is detected, detection of magnetic variations in the Earths field, or the use of a speaker and microphone to determine the distance between the Client Device and the Geofence Status Device.

[0011] The Geofence Status Device 104 in some embodiments receives RF signals from various sources and uses publicly available location data for those signals transmission origins to triangulate a location. It can utilize the IMU to verify I cross check that any physical movement of the device corresponds to associated adjustments in the reported location. If these do not match, then the attack in FIG. 3 is detected.

[0012] The Geofence Status Device in some embodiments can include two physical components, one which attaches to the Client Device (e.g., PC or mobile phone) and one which generates the attested Geofence status.

[0013] The two components can each contain a “Comms Dongle” 404 that allows them to securely communicate with each other and determine the distance between each other via response times as illustrated in the system 400 of FIG. 4 where one comms dongle 404 is coupled to the client device 402 and another comms dongle 404 is couple to the GSD 406. Invocations can include ultrasonics, infrared, audible tones, LED lasers (e.g. range finders). In some embodiments, one Comms Dongle generates a signal that the other one receives, where it computes the time to return the signal and calculates the distance traveled. If the time is too big then the attack in FIG. 2 is detected.

[0014] In some embodiments, an IMU (or Inertial measurement unit) can be used instead or in addition to the dongle. An IMU typically includes a collection of sensors, including an accelerometer, gyroscope and magnetometer.

[0015] Further note that the server (102) shown in FIGs. 1-3 can be any type of server, e.g., a key management server or an authentication server. When any data that it holds is requested, it looks at its policy configuration to see if there is an associated Geofence parameter. If there is no associated geofence parameter, then the server just returns the requested data. However, if a Geofence restriction is in place, then the server 102 requests from the Client Device 104 a status from the connected Geofence Status Device 106 that includes a confirmation that it is currently within the Geofence boundary required (108 / 208 / 308). Using aGeofence Status rather than an actual location also allows some privacy preservation, depending upon the size of the fence. The server 102 receives a signed Geofence Status response from the client device 104. Based on the received result, the server determines whether to provide requested data to the Client Device or not. Optionally, the requested data can be sent back to the client device using encryption using a provided GSD public key. This encrypted payload can only be decrypted inside the GSD TEE. This provides E2EP delivery in order to prevent Man in the Middle (MitM) or any collusion.

[0016] Referring to FIG. 5, a flow diagram 500 illustrates the communication flow among a client device 504, server 502 and Geofence Status Device 506 in a system that prevents geofenced location spoofing of a client device. The initial or first or step 1 involves the client device 504 making a service request of the server 502. At step 2, the sever 502 will check if a geofence requirement exists. If no geofence requirement exists, then service is provided at step 3A. If a geofence requirement exists, the server 502 provides such requirement to the client device 504 at step 3. In response, the client device 504 sends a request to the GSD 506 that requests a geofence status along with the geofence requirement (forwarded from the server) at step 4. At step 5, the GSD 506 determines if the geofence status is TRUE or FALSE using one of the aforementioned location techniques discussed above. The GSD 506 further signs the Geofence status at step 6 before returning the signed geofence status at step 7 to the client device 504. The client device 504 then in turn requests service from the server 502 with the signed geofence status at step 8. The server 502 then checks the signature and service geofence requirement at step 9. At step 10, the server 502 provides service to the client device 504 if the both the signature is valid and the geofence status is TRUE. If the signature is invalid or the geofence status is FALSE, then the server 502 denies service to the client device 504 at step 11.

[0017] FIG. 6 is another flow diagram 600 illustrating a similar communication flow among the client device 504, server 502, and GSD 50D, but with further details, particularly with respect to encryption. As with flow diagram 500, flow diagram 600 includes step 1 where the client device 504 initially makes a service request of the server 502. At step 2, the sever 502 will check if a geofence requirement exists. If no geofence requirement exists, then service is provided at step 3A and the client device begins to use the service at step 3B.

[0018] If the server 502 has a geofence requirement, a geofence boundary is added to the service requirements at step 4A and then the client device 504 sends a geofence status request with the server requirements to the GSD 506 at step 4 and the GSD 506 will add the determined geofence status to a message at step 5D.

[0019] Optionally, if the server further requires an encryption service, the server will check for an encryption service requirement at step 4B and subsequently add such encryption requirement to the server requirements at step 4C before the client device 504 sends a geofence status request with the server requirements to the GSD 506 at step 4.

[0020] In one alternative, if both the client device and the GSD are inside the geofence boundary, then the GSD 506 assigns a Geofence Status as TRUE at step 5A. In a second alternative, if the client device is outside the geofence boundary and the GSD is inside the geofence boundary, then the GSD 506 assigns geofence status as FALSE at step 5B. In yet a third alternative, if the client device is outside the geofence boundary and the GSD is also outside the geofence boundary, then the GSD 506 assigns geofence status as FALSE at step 5C. In any case (5A, 5B, or 5C), the GSD 506 will add the geofence status to a message at step 5D.

[0021] Optionally, if encryption service is required, the GSD 506 will check for the encrypted service requirement at step 5E and subsequently add an encryption public key to the message at step 5F.

[0022] The GSD 506 further signs the Geofence status at step 6 before returning the signed geofence status at step 7 to the client device 504. The client device 504 then in turn requests service from the server 502 with the signed geofence status at step 8. The server 502 then checks the signature and service geofence requirement at step 9.

[0023] In one alternative at step 10A, assuming that the message signature is valid and the geofence status is TRUE, the server 502 checks if there is an encryption service requirement at step 10A. If encryption services are not required, then the server 502 begins to provide service to the client device at step 10 and the client device 504 uses the service at step 10J.

[0024] In response to determining at step Athat encryption service is indeed required, the server 502 will encrypt its service with a session key at step 10B, extract the GSD Public Key (see Step 5F) from the signed message at step 10C, encrypt the session key with the GSD public key at step 10D, and then provide service that is encrypted with the session key to the client device 504 at step 10E. The client device 504 will then provide at step 10F the encrypted session key to the GSD 506 for decryption, whereupon the GSD 506 decrypts the session key with an encryption private key at step 10G. Next, at step 10H, the GSD 506 returns a plain session key to the client device 504 and the client device 504 decrypts a payload with the plain session key to access service at step 10i.Subsequently, the client device uses the service at step 10J.

[0025] If the server 502 (after checking the signature and service geofence requirements at step 9) determines that the message signature is invalid or that the geofence status is FALSE, then the server 502 denies service to the client device 504 at step 11.

[0026] Referring to FIG. 7, a method 700 of attesting to a server that a client device is within or outside a geofence boundary specified by the server can include a number of steps that can be performed in various ways in accordance with the embodiments and not necessarily limited in the order shown ornecessarily including every single step shown. In some embodiments, the method is a processor-implemented method. In some embodiments, a geofence status device couples to the client device and one or more processors and memory operatively coupled to the one or more processors includes computer instructions which when executed by the one or more processors causes the one or more processors to perform certain operations.

[0027] In some embodiments as shown in method 700, the operations or steps can include receiving at 702 a geofence boundary requirement sent by the server to the client device along with a request for a geofence status, assigning at step 704 a geofence status as TRUE when the client device and the geofence status device are determined as being within the geofence boundary specified by the server, and assigning at step 706 a geofence status as FALSE when the client device or the geofence status device or both are determined as being outside the geofence boundary specified by the server.

[0028] The method 700 can further include the step 707 of signing the geofence status to provide a signed geofence status, and returning at step 708 the geofence status to the server.

[0029] In some embodiments, the client device sends a service request along with the signed geofence status to the server. In some embodiments, the server checks a signature of the signed geofence status and checks the geofence boundary requirement. In some embodiments as shown at step 710, the server provides service to the client device if the signature of the geofence status is valid and the geofence status is TRUE. In some embodiments, the server at step 712 denies service to the client if the signature of the geofence status is invalid or the geofence status is FALSE.

[0030] In some embodiments as shown at step 714, the geofence status device further uses encryption to encrypt messages or service sent to the client device or server. In some embodiments, the encryption is achieved by having the geofencestatus device operating in a Trusted Execution Environment (TEE) containing geofence status device symmetric keys that perform cryptographic operations.

[0031] In some embodiments, the server can add an encrypted service requirement to server requirements to provide encrypted service requirements and the geofence status device checks the encrypted service requirements, adds an encryption public key to the signed message. In some embodiments, the server further checks the encrypted service requirements. In some embodiments, in response to checking the signature and service geofence requirement, the server encrypts the service with a session key, extracts the geofence encryption public key from the signed message, encrypts the session key with the geofence encryption public key and provides service encrypted with the session key. In some embodiments, the client device provides the encrypted session for decryption to the geofence status device and the geofence status device decrypts the encrypted session key with an encryption private key and returns a plain session key to the client device whereupon the client device decrypts a payload with the plain session key to access service.

[0032] The embodiments provide several technical advantages including, but not limited to Anti-Spoofing by having an attested location (which makes it extremely difficult to spoof multiple RF signals where bad actor(s) would essentially need be Nation states to overcome such obstacles), Anti-remote access where the attested co-location of the two components which makes it extremely difficult to utilize remote terminal features to host the locator in the desired location and the client machine in a bad location, and cost efficiency by providing the option to the customer to choose a solution for geofencing of keys that provides comparable security, for example, without the use of costly cryptographic hardware systems. Further note that the embodiments are cost effective to build by using a unique combinations of off-the-shelf products.Furthermore, the embodiments help organizations achieve compliance where data sovereignty is required.

[0033] In summary, the embodiments provide a device that produces an unspoofable (or nearly unspoofable) determination as to whether a client device is in a geofence boundary or not and can utilize moving signals that are deterministic to verify a geofence location. Additionally, the embodiments do not expose precise location data that allows tracking and creates privacy concerns.

[0034] Such embodiments of the inventive subject matter may be referred to herein, individually and / or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Claims

CLAIMSWhat is claimed, is:

1. A system (500 or 600) for attesting to a server (502) that a client device (504) is within or outside a geofence boundary specified by the server, comprising:a geofence status device (506) coupled to the client device; one or more processors (508) and memory (510) operatively coupled to the one or more processors, wherein the memory includes computer instructions which when executed by the one or more processors causes the one or more processors to perform the operations of:receiving (702) a geofence boundary requirement sent by the server to the client device along with a request for a geofence status;assigning (704) a geofence status as true when the client device and the geofence status device are determined as being within the geofence boundary specified by the server;assigning (706) a geofence status as false when the client device or the geofence status device or both are determined as being outside the geofence boundary specified by the server;signing (707) the geofence status to provide a signed geofence status; andreturning (708) the geofence status to the server.

2. The system of claim 1 , wherein the client device sends a service request along with the signed geofence status to the server.

3. The system of claim 2, wherein the server checks a signature of the signed geofence status and checks the geofence boundary requirement.

4. The system of claim 3, wherein the server provides service (710) to the client device if the signature of the geofence status is valid and the geofence status is true.

5. The system of claim 3, wherein server denies service (712) to the client if the signature of the geofence status is invalid or the geofence status is false.

6. The system of claim 1 , wherein the geofence status device further uses encryption (714) to encrypt messages sent to the client device or server by operating in a Trusted Execution Environment (TEE) containing geofence status device symmetric keys that perform cryptographic operations.

7. The system of claim 1 , wherein the server adds an encrypted service (714) requirement to server requirements to provide encrypted service requirements and the geofence status device checks the encrypted service requirements, adds an encryption public key to the signed message, and then checks the encrypted service requirements.

8. The system of claim 7, wherein in response to checking the signature and service geofence requirement, the server encrypts the service with a session key, extracts the geofence encryption public key from the signed message, encrypts the session key with the geofence encryption public key and provides service encrypted with the session key.

9. The system of claim 9, wherein the client device provides the encrypted session for decryption to the geofence status device and the geofence status device decrypts the encrypted session key with an encryption private key and returns a plain session key to the client device whereupon the client device decrypts a payload with the plain session key to access service.

10. The system of claim 1 , wherein the geofence status device is an independent and separate device from the client device and physically connected to the client device.

11. The system of claim 1 , wherein the geofence status device is embedded within the client device.

12. A processor-implemented method for attesting to a server (502) that a client device (504) is within or outside a geofence boundary specified by the server, comprising:a geofence status device (506) coupled to the client device that performs the operations of:receiving (702) a geofence boundary requirement sent by the server to the client device along with a request for a geofence status;assigning (704) a geofence status as true when the client device and the geofence status device are determined as being within the geofence boundary specified by the server;assigning (706) a geofence status as false when the client device or the geofence status device or both are determined as being outside the geofence boundary specified by the server;signing (707) the geofence status to provide a signed geofence status; andreturning (708) the geofence status to the server.

13. The processor-implemented method of claim 14, wherein the geofence status device is further configured to add (714) an encryption public key to a message to the server and to decrypt an encrypted session key from the server with an encryption private key.

14. The system of claim 1 , wherein the geofence status device (506) assigns a geofence status as true (704) when the geofence status device determines that externally identifiable signal sources are where they are expected to be if the device is where it believes that it is and the status as false (706) otherwise.

15. The system of claim 16, wherein the geofence status device (506) assigns a geofence status as false (706) when the geofence status device determines that the client device is not in proximity.