Verification method and device for longitude and latitude watermarks and computer program product

Abstract

The embodiment of the invention discloses a latitude and longitude watermark verification method, a latitude and longitude watermark verification device and a computer program product. According to the main technical scheme, the method comprises the steps that multiple pieces of longitude and latitude data obtained for a target picture are obtained, and the multiple pieces of longitude and latitude data at least comprise longitude and latitude data obtained by calling a C / C + + language layer positioning interface; performing splicing processing on the multiple pieces of longitude and latitude data to obtain service data; sending the service data to a server side, so that the server side detects whether a latitude and longitude forgery risk exists or not by comparing differences of a plurality of pieces of latitude and longitude data contained in the service data; and in response to the existence of the latitude and longitude counterfeiting risk, executing risk processing. According to the method, the authenticity of the generated latitude and longitude watermark data can be ensured by detecting the latitude and longitude counterfeiting risk, and the credibility of the watermark image is improved.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to verification methods, devices and computer program products for latitude and longitude watermarking. Background Technology

[0002] Watermark camera apps are mobile applications that automatically add various information watermarks to photos when they are taken, and are widely used in scenarios such as work recording, daily check-ins, and content creation. These watermarks include time watermarks, latitude and longitude watermarks, and location watermarks. Among them, the authenticity of latitude and longitude watermarks is the core element in ensuring the credibility of the location information of the captured content. However, malicious attackers may tamper with latitude and longitude information in various ways, such as modifying the return value of the location interface to forge latitude and longitude data, making it difficult to guarantee the authenticity of latitude and longitude, further distorting the watermark information, and ultimately reducing the credibility of the watermarked image. Summary of the Invention

[0003] This application provides a method, apparatus, and computer program product for verifying latitude and longitude watermarks, which can detect the risk of latitude and longitude forgery and ensure the authenticity of latitude and longitude watermark data.

[0004] This application provides the following solution: According to the first aspect, a method for verifying latitude and longitude watermarks is provided, applied to a client. The method includes: acquiring multiple latitude and longitude data for a target image, wherein the multiple latitude and longitude data includes at least latitude and longitude data acquired by calling a C / C++ language layer positioning interface; concatenating the multiple latitude and longitude data to obtain business data; sending the business data to a server so that the server can detect the existence of latitude and longitude forgery risk by comparing the differences of the multiple latitude and longitude data contained in the business data; and performing risk handling in response to the existence of latitude and longitude forgery risk.

[0005] According to the second aspect, a method for verifying latitude and longitude watermarks is provided, applied to the server side. The method includes: receiving business data sent by a client, wherein the business data is obtained by concatenating multiple latitude and longitude data, and the multiple latitude and longitude data includes at least the latitude and longitude data obtained by the client by calling the C / C++ language layer positioning interface; detecting the existence of latitude and longitude forgery risk by comparing the differences of the multiple latitude and longitude data; and in response to detecting the existence of latitude and longitude forgery risk, sending information indicating the existence of latitude and longitude forgery risk or risk handling instructions to the client so that the client can perform risk handling.

[0006] According to a third aspect, a latitude and longitude watermark verification device is provided, set on a client side. The device includes: a data acquisition unit configured to acquire multiple latitude and longitude data for a target image, wherein the multiple latitude and longitude data includes at least latitude and longitude data acquired by calling a C / C++ language layer positioning interface; a splicing processing unit configured to splice the multiple latitude and longitude data to obtain business data; a data sending unit configured to send the business data to a server, so that the server can detect whether there is a risk of latitude and longitude forgery by comparing the differences of the multiple latitude and longitude data contained in the business data; and a risk processing unit configured to perform risk processing in response to the existence of a risk of latitude and longitude forgery.

[0007] According to the fourth aspect, a latitude and longitude watermark verification device is provided, which is set on the server side. The device includes: a data receiving unit configured to receive business data sent by a client, wherein the business data is obtained by splicing multiple latitude and longitude data, and the multiple latitude and longitude data includes at least the latitude and longitude data obtained by the client calling the C / C++ language layer positioning interface; a risk detection unit configured to detect whether there is a risk of latitude and longitude forgery by comparing the differences of the multiple latitude and longitude data; and a data sending unit configured to send information indicating the existence of latitude and longitude forgery risk or risk handling instructions to the client in response to the detection of latitude and longitude forgery risk, so that the client can perform risk handling.

[0008] According to a fifth aspect, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the steps of the method described in any one of the first and second aspects.

[0009] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a method for verifying the authenticity of latitude and longitude watermark data. It introduces a C / C++ language layer positioning interface to obtain latitude and longitude data, thereby increasing the difficulty of cracking the positioning interface. Multiple latitude and longitude data are obtained through multiple positioning interfaces, and the multiple latitude and longitude data are transmitted to the server. The server can then detect whether there is a risk of forgery by comparing the differences between the multiple latitude and longitude data. If there is a risk of forgery, risk processing is performed. This method can better guarantee the authenticity of latitude and longitude watermark data and improve the credibility of watermark images. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a system architecture diagram applicable to the embodiments of this application.

[0012] Figure 2 A flowchart of the latitude and longitude watermark verification method executed by the client provided in this application embodiment.

[0013] Figure 3 This is a flowchart for generating a dynamic key, provided as an embodiment of this application.

[0014] Figure 4 This is a schematic diagram of a latitude and longitude watermark image provided in an embodiment of this application.

[0015] Figure 5 A flowchart of a server-side verification method for latitude and longitude watermarks provided in this application embodiment.

[0016] Figure 6 A schematic block diagram of a latitude and longitude watermark verification device set on a client side, as provided in an embodiment of this application.

[0017] Figure 7 This is a schematic block diagram of a latitude and longitude watermark verification device set on the server side, as provided in an embodiment of this application.

[0018] Figure 8 A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0020] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0022] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0023] In scenarios where latitude and longitude watermarks are generated for images, the authenticity of the latitude and longitude is difficult to guarantee because the Java interface is easily tampered with, further reducing the credibility of the watermarked image.

[0024] In view of this, this application provides a new approach. To facilitate understanding of this application, the system architecture on which this application is based will first be described. Figure 1 An exemplary system architecture that can be applied to embodiments of this application is shown, such as Figure 1 As shown, the system architecture may include a client and a server.

[0025] The server and client are the two main components of an application service. The server, using a server as its primary hardware infrastructure, may include one or more software service modules. In this embodiment, it is mainly responsible for verifying the authenticity of latitude and longitude coordinates and querying and returning the corresponding address based on the verified coordinates, forming a collaborative front-end and back-end with the client.

[0026] The user terminal where the client resides can include, but is not limited to, smart mobile terminals, wearable devices, and PCs (Personal Computers). Smart mobile devices can include devices such as mobile phones, tablets, PDAs (Personal Digital Assistants), and connected car terminals. Wearable devices can include devices such as smartwatches, smart glasses, smart bracelets, VR (Virtual Reality) devices, AR (Augmented Reality) devices, and mixed reality devices (i.e., devices that support both virtual and augmented reality), etc.

[0027] The client can be an application located on the user's terminal, or it can be a plugin or software development kit (SDK) or other functional unit set in the application.

[0028] A server can be a standalone server, a server cluster, or a cloud server. A cloud server, also known as a cloud computing server or cloud host, is a hosting product within the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) services, such as high management difficulty and weak service scalability.

[0029] As one feasible implementation, the client can send the acquired latitude and longitude coordinates to the server for verification to determine whether the latitude and longitude coordinates are genuine. Then, the client can obtain the address corresponding to the real latitude and longitude coordinates from the server and use the method provided in this application embodiment to verify the latitude and longitude coordinates and address information in the watermark image to generate a real and valid watermark image.

[0030] It should be understood that Figure 1 The server and client shown are merely illustrative. Depending on the implementation requirements, there can be any number of servers and clients.

[0031] Figure 2 This is a flowchart of a latitude and longitude watermark verification method provided in an embodiment of this application. The method can be... Figure 1 The client in the system shown executes this. For example... Figure 2 As shown, the method may include the following steps: Step 201: Obtain multiple latitude and longitude data for the target image, wherein the multiple latitude and longitude data includes at least the latitude and longitude data obtained by calling the C / C++ language layer positioning interface.

[0032] Step 202: Perform splicing processing on multiple latitude and longitude data to obtain business data.

[0033] Step 203: Send the business data to the server so that the server can detect the risk of latitude and longitude forgery by comparing the differences of multiple latitude and longitude data contained in the business data.

[0034] Step 204: In response to the risk of latitude and longitude falsification, perform risk handling.

[0035] As can be seen from the above process, this application provides a method for verifying the authenticity of latitude and longitude watermark data. By introducing a C / C++ language layer positioning interface to obtain latitude and longitude data, the difficulty of cracking the positioning interface is increased. Multiple latitude and longitude data are obtained through multiple positioning interfaces, and the multiple latitude and longitude data are transmitted to the server. This allows the server to detect whether there is a risk of latitude and longitude forgery by comparing the differences between multiple latitude and longitude data. If there is a risk of latitude and longitude forgery, risk processing is performed. This method can better guarantee the authenticity of latitude and longitude watermark data and improve the credibility of watermark images.

[0036] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments.

[0037] First, the above step 201, namely "acquiring multiple latitude and longitude data for the target image, wherein the multiple latitude and longitude data includes at least latitude and longitude data obtained by calling the C / C++ language layer positioning interface", will be described in detail with reference to the embodiment.

[0038] In this embodiment, the target image involved in this application can be an image to which a watermark is to be added, captured by a watermark camera. The latitude and longitude data can be the latitude and longitude corresponding to the location of the photographer when taking the target image.

[0039] Generally, when photographers use watermarked cameras to take real-time photos, they usually add watermarks to the target images, with latitude and longitude watermarks being one type, to increase the credibility of the photographed content. Traditionally, the user client typically calls a Java-layer positioning interface to obtain latitude and longitude data. This Java-layer positioning interface refers to positioning logic written in Java and running on the Java Virtual Machine. Because the bytecode generated after editing the Java layer is semi-structured, with clearly defined classes, methods, and variable names, hooking the Java layer is relatively easy. Crackers can easily decompile it to obtain near-original Java code and replace the latitude and longitude returned by this interface.

[0040] To increase the difficulty of cracking, a C / C++ language layer positioning interface is introduced in this embodiment. The so-called C / C++ language layer positioning interface refers to the positioning logic written in C / C++ and compiled into native machine code. Since it is directly compiled into machine code, decompilation tools can only restore it to assembly language. It does not have the logical interface of classes and methods, and requires native hooking technology, making it difficult to crack. Specifically, if an attacker wants to replace the latitude and longitude returned by the interface, they need to replace the WiFi, base station, and Gnss satellite observations from the source. However, it is difficult to arbitrarily modify the location to a specific location. In other words, it is not easy to obtain the WiFi, base station, and Gnss satellite observations of a specific location.

[0041] One feasible method for detecting whether the C / C++ language layer positioning interface has been hooked involves the client performing system library verification and dynamic library integrity verification. System library verification checks whether the libc.so running in memory is consistent with the libc.so program segment on the system hard drive, and whether it has been tampered with. If they are consistent, the code execution environment is trustworthy. Dynamic library integrity verification matches the CRC32 signature of the dynamic library containing the C / C++ language layer positioning interface code in memory with the signature used when compiling the dynamic library. If the match is successful, the C / C++ language layer positioning interface has not been hooked. Specifically, after the C / C++ language layer positioning interface program is compiled into a dynamic library, the content of the program segment in the dynamic library remains unchanged; it is fixed at the moment of generation. To detect the risk of hooking, the system calculates the signature of the program segment in the dynamic library when it is generated. When the app runs, it verifies in real time whether the signature of this program segment in memory is the same as that generated. If they are different, meaning the program segment has been modified and does not match the signature, then the C / C++ language layer positioning interface can be considered hooked. In addition, obfuscation and encryption can be added when generating code for dynamic libraries.

[0042] In this embodiment of the application, in addition to using the C / C++ language layer positioning interface to obtain latitude and longitude data, the Java layer positioning interface can also be called to obtain latitude and longitude data.

[0043] One possible approach is to call the Java layer positioning interface to obtain at least one of GPS (Global Positioning System) latitude and longitude data, network positioning latitude and longitude data, or fused positioning latitude and longitude data.

[0044] One possible approach is to call the C / C++ language layer positioning interface to obtain at least one of network positioning latitude and longitude data and GNSS (Global Navigation Satellite System) latitude and longitude data.

[0045] The aforementioned GPS latitude and longitude data can be the latitude and longitude directly returned by the GPS application in the client system. The aforementioned network positioning latitude and longitude data can be the latitude and longitude data obtained from base station and WiFi positioning. The aforementioned fused positioning latitude and longitude data can be obtained by fusing the aforementioned GPS latitude and longitude data and network positioning latitude and longitude data. For example, based on the differences in accuracy between different types of latitude and longitude data, the aforementioned GPS latitude and longitude data and network positioning latitude and longitude data can be weighted and fused. It should be noted that fused positioning latitude and longitude data is generally more accurate than GPS positioning alone.

[0046] The C / C++ language layer positioning interface can collect and send base station and WiFi positioning information to the server to obtain latitude and longitude data for network positioning. The C / C++ language layer positioning interface can also calculate GNSS latitude and longitude data based on GNSS observations.

[0047] In this way, even if the Java layer positioning interface is cracked and the latitude and longitude data is tampered with, the client can still obtain the real latitude and longitude data from the C / C++ language layer positioning interface, which is more difficult to crack.

[0048] The following describes step 202, namely "splitting multiple latitude and longitude data to obtain business data", in detail with reference to the embodiments.

[0049] In this embodiment, in order to verify whether there is a risk of latitude and longitude data forgery, the client splices multiple latitude and longitude data to obtain business data, which is then sent to the server for risk verification.

[0050] Furthermore, to prevent data tampering during transmission, the client concatenates the aforementioned multiple latitude and longitude data points and their signatures, and uses the concatenated result as the aforementioned business data. The latitude and longitude data signatures are digital signatures, which can be used to verify the integrity of the data and the authenticity of its source. Since latitude and longitude data and signatures typically have a one-to-one correspondence, when at least one latitude and longitude data point in the business data is tampered with, the tampered latitude and longitude data will not be able to successfully match the original corresponding signature. This facilitates the detection of latitude and longitude forgery risks during data transmission by verifying the signatures of each latitude and longitude data point in the aforementioned business data.

[0051] Furthermore, the client can generate corresponding signatures for each latitude and longitude data separately, or it can first concatenate the latitude and longitude data, and then generate corresponding signatures for the concatenation results, for example, by generating signatures for the data through a hash function.

[0052] The following describes step 203, namely "sending business data to the server so that the server can detect the risk of latitude and longitude forgery by comparing the differences of multiple latitude and longitude data contained in the business data", in detail with reference to the embodiments.

[0053] In this embodiment, the client can send business data to the server in various ways, so that the server can detect the risk of latitude and longitude forgery by comparing the differences of multiple latitude and longitude data contained in the business data.

[0054] For example, to further enhance data transmission security, a dynamic encryption mechanism can be used to process business data during transmission in this embodiment. Specifically, the client's business data can be encrypted first using a dynamic key; then, the encrypted business data is sent to the server. Upon receiving the encrypted business data, the server can detect the risk of latitude and longitude spoofing by decrypting the data, for example, by checking for decryption failure. This approach can significantly improve the security of business data during transmission.

[0055] The aforementioned dynamic key can be obtained by the client requesting it from the server using a pre-stored basic key. One possible implementation method is as follows: Figure 3 As shown, the client can obtain the dynamic key through the following steps S31~S34: S31: Obtain the pre-stored base key.

[0056] In this embodiment, a base key can be pre-stored on the client. This base key can be included in the client's installation package or issued to the client by the server after installation. It is a long-term, fixed key that can typically be used to bind the client's unique identity. The server also pre-stores the base key corresponding to each client.

[0057] S32: Send the base key along with the key request to the server.

[0058] After the client sends the base key to the server in a key request, the server verifies the base key. For example, it verifies whether the received base key matches the base key stored on the server using the client's identity information. If they match, the server assigns a dynamic key to the client and stores the correspondence between the dynamic key and the client. This dynamic key is a short-term valid key with an expiration time. After the expiration time, the dynamic key becomes invalid, and a new dynamic key needs to be requested using the base key.

[0059] S33: Receive dynamic key segments sent by the server through at least two different communication connections.

[0060] To further enhance security, the server can split the dynamic key into multiple dynamic key segments and send each segment to the client through a different communication connection.

[0061] S34: Assemble the dynamic key segment to obtain the dynamic key.

[0062] This "split distribution" strategy for dynamic keys, which transmits them through different links and assembles them at the client, can effectively reduce the risk of the dynamic key being completely stolen after being distributed in one go, thereby further improving security.

[0063] For example, to further reduce the risk of a single data transmission failure, the client can send business data to the server through at least two different communication connections.

[0064] The following describes step 204, namely "in response to the risk of latitude and longitude forgery, perform risk processing", in detail with reference to the embodiments.

[0065] As one possible approach, after the server detects the risk of latitude and longitude spoofing, if the risk exists, it can return the result to the client for risk handling. If the risk does not exist, it can obtain the target latitude and longitude based on the received multiple latitude and longitude values ​​and return the target latitude and longitude to the client, whereby the client generates a latitude and longitude watermark. The server can also further query the address information corresponding to the target latitude and longitude and return the address information to the client.

[0066] As another feasible approach, after detecting the risk of latitude and longitude spoofing, the server can send instructions to the client based on the detection results, allowing the client to perform corresponding operations. For example, if latitude and longitude spoofing risk exists, the server sends a risk handling instruction to the client so that the client can perform risk handling; if no latitude and longitude spoofing risk exists, the server returns the target latitude and longitude to the client so that the client can generate a latitude and longitude watermark. The server can also further query the address information corresponding to the target latitude and longitude and return the address information to the client.

[0067] For example, risk handling can include, but is not limited to, at least one of the following: error reporting, crashes, user authentication, reinstalling the client's installation package, and disabling service functions. Error reporting can manifest as displaying an error message window. Crashes can prevent the client from functioning properly. User authentication can force users to log in for authentication, thereby tracking abnormal user accounts. Disabling service functions can prevent the function of generating watermarks for images. Other risk handling methods are also possible, which will not be listed here. Through the above risk handling mechanisms, the client can prevent the risk of data tampering from escalating, thus improving security.

[0068] Furthermore, when there is no risk of latitude and longitude spoofing, to generate a watermark image, the client typically first uses a text view component to set and display latitude and longitude text and address text, then converts the latitude and longitude text and address text into a watermark image, and finally overlays the watermark image onto the target image to obtain the watermark image. For example, a TextView (text view component) can be drawn using Canvas or the TextView can be converted into a Bitmap to obtain the watermark image. Even in the above process of generating the watermark image, there may still be a significant risk of data tampering. The client can take measures to address different risks depending on the specific circumstances. Specifically: When the server returns the target latitude and longitude and its signature or address information and its signature to the client, the client can achieve at least one of the following: The first method: If the server returns the target latitude and longitude and its signature, the client verifies the signature. The target latitude and longitude are obtained by the server based on the aforementioned multiple latitude and longitude coordinates. Subsequently, if the signature verification fails, the client can prevent the generation of a latitude and longitude watermark for the target image. If the signature verification succeeds, the client can generate a watermarked image based on the target latitude and longitude.

[0069] The second approach: If the server returns address information and its signature, the client verifies the signature of the address information. The address information is determined by the server based on the target's latitude and longitude. If the signature verification fails, the client can perform risk handling. If the signature verification succeeds, the client can generate a watermark image based on the address information.

[0070] In this way, by determining whether the received target latitude, longitude, or address information has been tampered with during transmission, and by taking corresponding risk handling measures when the data has been tampered with, the client can avoid embedding forged latitude, longitude, or address information into the watermark image, thus improving the security of watermark image generation.

[0071] Furthermore, when displaying latitude and longitude text or address text through a text view component, the client can achieve at least one of the following: The first method involves generating a latitude and longitude watermark for the target image. The client can then verify the latitude and longitude displayed in the text view component using the target latitude and longitude. If the verification fails, the client will perform risk handling.

[0072] The second method involves generating a latitude and longitude watermark for the target image. The client can use this address information to verify the address displayed in the text view component. If verification fails, the client will perform risk handling.

[0073] The client also improves the security of watermark image generation by determining whether latitude and longitude or address information has been tampered with when displayed through the text view component, and by taking corresponding risk handling measures when the data has been tampered with.

[0074] Furthermore, after generating a latitude and longitude watermark for the target image, the client can use character recognition technology to identify the latitude and longitude contained in the watermark, verify the identified latitude and longitude using the target latitude and longitude, and perform risk handling if the verification fails.

[0075] The client also determines whether the latitude and longitude watermark has been altered at the image level (e.g., a screenshot overlaying the original image), and takes corresponding risk handling measures when the latitude and longitude watermark is confirmed to have been tampered with. This can prevent the forged watermark image from being superimposed on the target image, improve the security of watermark image generation, and further enhance the credibility of the watermark image.

[0076] by Figure 4 For example, Figure 4 The image shown is a watermarked image with latitude and longitude coordinates, displaying both the coordinates and the address. It should be noted that... Figure 4 The layout of latitude, longitude, and address is for reference only, and there are no specific restrictions on the arrangement of latitude, longitude, and address.

[0077] It should be noted that when a user generates a latitude and longitude watermark for a target image but does not select to display an address entry on the watermark, the client will not need to send business data to the server for risk verification and address acquisition. It only needs to use the location fusion latitude and longitude data as the target latitude and longitude to verify the forgery risk of the latitude and longitude used to generate the latitude and longitude watermark. If the verification fails, the client will perform risk processing.

[0078] Figure 5 A flowchart illustrating the latitude and longitude watermark verification method provided in this application embodiment. Figure 5 As shown, the method may include the following steps: Step 501: Receive business data sent by the client. The business data is obtained by splicing multiple latitude and longitude data. The multiple latitude and longitude data include at least the latitude and longitude data obtained by the client calling the C / C++ language layer positioning interface.

[0079] Step 502: Detect the risk of latitude and longitude forgery by comparing the differences between multiple latitude and longitude data.

[0080] Step 503: In response to the detection of a risk of latitude and longitude spoofing, information indicating the risk of latitude and longitude spoofing or a risk handling instruction is sent to the client so that the client can perform risk handling.

[0081] As can be seen from the above process, the server receives business data including multiple latitude and longitude data, and detects whether there is a risk of latitude and longitude forgery by comparing the differences of multiple latitude and longitude data. When there is a risk of latitude and longitude forgery, the server instructs the client to perform risk processing. This method can better ensure the authenticity of latitude and longitude watermark data and improve the credibility of watermark images.

[0082] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments.

[0083] First, the above step 501, namely "receiving business data sent by the client, the business data being obtained by splicing multiple latitude and longitude data, the multiple latitude and longitude data including at least the latitude and longitude data obtained by the client calling the C / C++ language layer positioning interface", will be described in detail with reference to the embodiment.

[0084] In this embodiment, the client can obtain multiple latitude and longitude data, including latitude and longitude data obtained by calling the C / C++ language layer positioning interface, and concatenate the multiple latitude and longitude data into business data before sending it to the server. The server can receive the business data sent by the client.

[0085] Furthermore, before receiving business data from the client, the server also receives a key request from the client and verifies the base key carried in the request. If the base key verification is successful, the server generates a dynamic key for the client and returns this dynamic key information to the client. The client then encrypts and transmits the business data using the dynamic key, and the server uses the client's corresponding dynamic key to decrypt the data. If decryption fails, it indicates a risk of latitude and longitude spoofing. This dynamic encryption mechanism improves the security of data transmission.

[0086] Furthermore, when the server returns the dynamic key information to the client, it first splits the dynamic key into at least two dynamic key segments, and then sends each of these at least two dynamic key segments to the client through at least two different communication connections. The client then uses these at least two dynamic key segments to reassemble the final dynamic key. This key splitting and distribution strategy on the server side, along with the method of transmission through different links, effectively reduces the risk of the dynamic key being completely stolen in a single distribution, thereby further improving security.

[0087] The following describes step 502, namely "detecting the risk of latitude and longitude forgery by comparing the differences of multiple latitude and longitude data", in detail with reference to the embodiments.

[0088] In this embodiment, the server can compare the differences between multiple latitude and longitude data. For example, if the difference between any two latitude and longitude coordinates exceeds a preset difference threshold, it can be considered that there is a risk of latitude and longitude forgery. Similarly, if the difference between any two latitude and longitude coordinates does not exceed the preset difference threshold, it can be considered that there is no risk of latitude and longitude forgery. The preset difference threshold can be a pre-set threshold. For example, the preset difference threshold can be 200 meters.

[0089] The aforementioned business data may include signatures for the latitude and longitude coordinates. As one possible approach, the server can verify the signatures of the latitude and longitude coordinates in the business data to detect any risk of latitude and longitude forgery. Specifically, the server can regenerate new signatures for the latitude and longitude coordinates in the business data, and then match and verify these new signatures against the corresponding old signatures sent by the client. If the match is successful, there is no risk of latitude and longitude forgery; if the match fails, there is a risk. The server-side determination of latitude and longitude forgery risk based on the signatures of the latitude and longitude coordinates is a simple and efficient process.

[0090] The following describes in detail step 503, namely, "in response to detecting a risk of latitude and longitude spoofing, sending information indicating the risk of latitude and longitude spoofing or a risk handling instruction to the client so that the client can perform risk handling," with reference to an embodiment.

[0091] In this embodiment, if the server detects a risk of latitude and longitude spoofing, it will send information indicating the risk or a risk handling instruction to the client, and the client will perform risk handling according to the instruction.

[0092] Furthermore, when the server detects that there is no risk of latitude and longitude spoofing, the server can achieve at least one of the following: The first approach: If no risk of latitude and longitude spoofing is detected, the server uses the aforementioned multiple latitude and longitude data to determine the target latitude and longitude, and returns the target latitude and longitude and its signature to the client. When using multiple latitude and longitude data to determine the target latitude and longitude, one of the average, median, or multiple values ​​of the data can be used as the target latitude and longitude, or the fused positioning latitude and longitude data included in the business data can be used as the target latitude and longitude.

[0093] The second approach: If no risk of latitude and longitude spoofing is detected, the server uses the aforementioned multiple latitude and longitude data to determine the target latitude and longitude, uses the target latitude and longitude to query the address information corresponding to the target latitude and longitude, and returns the address information and its signature to the client.

[0094] The server returns the actual latitude, longitude, and address to the client to generate a watermark image, ensuring the authenticity of the latitude and longitude watermark data and improving the credibility of the watermark image.

[0095] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0096] According to another embodiment, a verification device for latitude and longitude watermarks is provided. Figure 6 A schematic block diagram of a latitude and longitude watermark verification device according to one embodiment is shown, the device being disposed in... Figure 1 The client in the illustrated architecture. For example... Figure 6 As shown, the device 600 includes: The data acquisition unit 601 is configured to acquire multiple latitude and longitude data for the target image, wherein the multiple latitude and longitude data includes at least the latitude and longitude data acquired by calling the C / C++ language layer positioning interface.

[0097] The splicing processing unit 602 is configured to splice the above-mentioned multiple latitude and longitude data to obtain business data.

[0098] The data sending unit 603 is configured to send the aforementioned business data to the server so that the server can detect the risk of latitude and longitude forgery by comparing the differences between multiple latitude and longitude data contained in the aforementioned business data.

[0099] Risk processing unit 604 is configured to perform risk processing in response to the existence of latitude and longitude forgery risk.

[0100] As one possible implementation method, the data acquisition unit 601 is also configured to call the Java layer positioning interface to acquire at least one of GPS latitude and longitude data, network positioning latitude and longitude data, or fused positioning latitude and longitude data, wherein the fused positioning latitude and longitude data is obtained by fusing the GPS latitude and longitude data and the network positioning latitude and longitude data; and to call the C / C++ language layer positioning interface to acquire at least one of network positioning latitude and longitude data and GNSS latitude and longitude data.

[0101] As one possible implementation method, the splicing processing unit 602 is also configured to splice the above-mentioned multiple latitude and longitude data and their signatures to obtain the above-mentioned business data, so that the above-mentioned server can detect whether there is a risk of latitude and longitude forgery by verifying the signatures of each latitude and longitude data in the above-mentioned business data.

[0102] As one possible implementation method, the data sending unit 603 is also configured to encrypt the aforementioned business data using a dynamic key, wherein the dynamic key is obtained by the client from the server using a pre-stored basic key; and send the encrypted business data to the server so that the server can detect the risk of latitude and longitude spoofing by decrypting the business data.

[0103] Furthermore, the data acquisition unit 601 is also configured to acquire a pre-stored basic key; send the basic key to the server in a key request; receive dynamic key segments sent by the server through at least two different communication connections; and assemble the dynamic key segments to obtain the dynamic key.

[0104] Furthermore, the risk processing unit 604 is also configured to, in response to the server returning the target latitude and longitude and its signature, verify the signature of the target latitude and longitude, wherein the target latitude and longitude are obtained by the server based on the multiple latitude and longitude coordinates; in response to the signature verification failure of the target latitude and longitude, prohibit the generation of latitude and longitude watermarks for the target image; and in response to the server returning address information and its signature, verify the signature of the address information, wherein the address information is determined by the server based on the target latitude and longitude; in response to the signature verification failure of the address information, perform risk processing.

[0105] Furthermore, the risk processing unit 604 is also configured to, during the process of generating a latitude and longitude watermark for the target image, verify the latitude and longitude displayed in the text view component using the target latitude and longitude; if the verification fails, perform risk processing; and during the process of generating a latitude and longitude watermark for the target image, verify the address displayed in the text view component using the address information; if the verification fails, perform risk processing.

[0106] Furthermore, the risk processing unit 604 is also configured to use character recognition technology to identify the latitude and longitude contained in the latitude and longitude watermark, verify the identified latitude and longitude using the target latitude and longitude, and perform risk processing if the verification fails.

[0107] As one possible approach, the aforementioned risk handling includes at least one of the following: error reporting, crashes, user authentication, and prohibiting the generation of latitude and longitude watermarks for the target images.

[0108] According to another embodiment, a verification device for latitude and longitude watermarks is provided. Figure 7 A schematic block diagram of a latitude and longitude watermark verification device according to one embodiment is shown, the device being disposed in... Figure 1 The server side in the illustrated architecture. For example... Figure 7 As shown, the device 700 includes: The data receiving unit 701 is configured to receive business data sent by the client. The business data is obtained by splicing multiple latitude and longitude data, including at least the latitude and longitude data obtained by the client by calling the C / C++ language layer positioning interface.

[0109] Risk detection unit 702 is configured to detect the presence of latitude and longitude forgery risk by comparing the differences between the above multiple latitude and longitude data.

[0110] The data sending unit 703 is configured to send information indicating the risk of latitude and longitude spoofing or a risk handling instruction to the client in response to detecting the risk of latitude and longitude spoofing, so that the client can perform risk handling.

[0111] As one possible implementation, the aforementioned business data may include signatures of the latitude and longitude data. The risk detection unit 702 is also configured to verify the signatures of the latitude and longitude data in the aforementioned business data to detect the presence of latitude and longitude forgery risk.

[0112] Furthermore, the data receiving unit 701 is also configured to receive a key request sent by the client and verify the basic key carried in the key request; in response to the successful verification of the basic key, generate a dynamic key for the client and return the information of the dynamic key to the client; after receiving the service data sent by the client, decrypt the service data using the dynamic key corresponding to the client, and if the decryption fails, it is determined that there is a risk of latitude and longitude forgery.

[0113] Furthermore, the data receiving unit 701 is also configured to split the dynamic key into at least two dynamic key segments; and send the at least two dynamic key segments to the client through at least two different communication connections, so that the client can use the at least two dynamic key segments to assemble the dynamic key.

[0114] Furthermore, the risk detection unit 702 is also configured to, if no risk of latitude and longitude spoofing is detected, determine the target latitude and longitude using the aforementioned multiple latitude and longitude data, and return the target latitude and longitude and its signature to the aforementioned client; if no risk of latitude and longitude spoofing is detected, determine the target latitude and longitude using the aforementioned multiple latitude and longitude data, query the address information corresponding to the target latitude and longitude using the target latitude and longitude, and return the address information and its signature to the aforementioned client.

[0115] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0116] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0117] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0118] And an electronic device, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any of the foregoing method embodiments.

[0119] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0120] in, Figure 8 An exemplary architecture of an electronic device is shown, which may include a processor 810, a video display adapter 811, a disk drive 812, an input / output interface 813, a network interface 814, and a memory 820. The processor 810, video display adapter 811, disk drive 812, input / output interface 813, network interface 814, and memory 820 can communicate with each other via a communication bus 830.

[0121] The processor 810 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs and implement the technical solution provided in this application.

[0122] The memory 820 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 820 can store the operating system 821 for controlling the operation of the electronic device 800, and the basic input / output system (BIOS) 822 for controlling the low-level operations of the electronic device 800. Additionally, it can store a web browser 823, a data storage management system 824, and latitude / longitude watermark verification devices 600 / 700, etc. The latitude / longitude watermark verification devices 600 / 700 can be the application programs that specifically implement the aforementioned steps in this embodiment. In summary, when implementing the technical solution provided in this application through software or firmware, the relevant program code is stored in the memory 820 and executed by the processor 810.

[0123] The input / output interface 813 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0124] Network interface 814 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0125] Bus 830 includes a pathway for transmitting information between various components of the device, such as processor 810, video display adapter 811, disk drive 812, input / output interface 813, network interface 814, and memory 820.

[0126] It should be noted that although the above-described device only shows the processor 810, video display adapter 811, disk drive 812, input / output interface 813, network interface 814, memory 820, bus 830, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily include all the components shown in the figures.

[0127] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer program product. This computer program product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0128] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for verifying latitude and longitude watermarks, applied to a client-side application, characterized in that, The method includes: Obtain multiple latitude and longitude data for the target image, wherein the multiple latitude and longitude data includes at least the latitude and longitude data obtained by calling the C / C++ language layer positioning interface; The multiple latitude and longitude data are stitched together to obtain business data; The business data is sent to the server so that the server can detect the risk of latitude and longitude forgery by comparing the differences of multiple latitude and longitude data contained in the business data. In response to the risk of latitude and longitude falsification, risk management measures were implemented.

2. The method according to claim 1, characterized in that, The acquisition of multiple latitude and longitude data for the target image includes: Call the Java layer positioning interface to obtain at least one of GPS latitude and longitude data, network positioning latitude and longitude data, or fused positioning latitude and longitude data, wherein the fused positioning latitude and longitude data is obtained by fusing the GPS latitude and longitude data and the network positioning latitude and longitude data; Call the C / C++ language layer positioning interface to obtain at least one of network positioning latitude and longitude data and GNSS latitude and longitude data.

3. The method according to claim 1, characterized in that, The process of stitching together the multiple latitude and longitude data to obtain the business data includes: The multiple latitude and longitude data and their signatures are concatenated to obtain the business data, so that the server can detect the risk of latitude and longitude forgery by verifying the signatures of each latitude and longitude data in the business data.

4. The method according to claim 1, characterized in that, Sending the business data to the server includes: The business data is encrypted using a dynamic key, wherein the dynamic key is obtained by the client from the server using a pre-stored basic key; The encrypted business data is sent to the server so that the server can detect the risk of latitude and longitude spoofing by decrypting the business data.

5. The method according to claim 4, characterized in that, The method further includes: Obtain the pre-stored base key; The basic key is sent to the server along with the key request; Receive dynamic key segments sent by the server through at least two different communication connections; The dynamic key is obtained by assembling the dynamic key segment.

6. The method according to claim 1, characterized in that, The method further includes at least one of the following: In response to the server returning the target latitude and longitude and its signature, the signature of the target latitude and longitude is verified, wherein the target latitude and longitude is obtained by the server based on the multiple latitude and longitude. In response to the signature verification failure of the target latitude and longitude, the generation of latitude and longitude watermarks for the target image is prohibited. In response to the server returning address information and its signature, the signature of the address information is verified, wherein the address information is determined by the server based on the target latitude and longitude. In response to the failure of the signature verification of the address information, risk handling is performed.

7. The method according to claim 6, characterized in that, The method further includes at least one of the following: During the process of generating a latitude and longitude watermark for the target image, the latitude and longitude displayed in the text view component are verified using the target latitude and longitude. If the verification fails, risk handling is performed. During the process of generating a latitude and longitude watermark for the target image, the address information is used to verify the address displayed by the text view component. If the verification fails, risk handling is performed.

8. The method according to claim 6, characterized in that, After generating a latitude and longitude watermark for the target image, the method further includes at least one of the following: The latitude and longitude contained in the latitude and longitude watermark are identified using character recognition technology. The identified latitude and longitude are verified using the target latitude and longitude. If the verification fails, risk handling is performed.

9. The method according to any one of claims 1 to 8, characterized in that, The risk handling includes at least one of the following: error reporting, crash, user authentication, and prohibiting the generation of latitude and longitude watermarks for the target image.

10. A method for verifying latitude and longitude watermarks, applied on the server side, characterized in that, The method includes: The system receives business data sent by the client, which is obtained by splicing together multiple latitude and longitude data, including at least the latitude and longitude data obtained by the client through the C / C++ language layer positioning interface. The risk of latitude and longitude forgery is detected by comparing the differences among the multiple latitude and longitude data. In response to the detection of a risk of latitude and longitude spoofing, information indicating the risk of latitude and longitude spoofing or a risk handling instruction is sent to the client so that the client can perform risk handling.

11. The method according to claim 10, characterized in that, The business data includes the signatures of the latitude and longitude data, and the method further includes: Verify the signatures of each latitude and longitude data in the business data to detect the risk of latitude and longitude forgery.

12. The method according to claim 10, characterized in that, The method further includes: Receive the key request sent by the client and verify the underlying key carried in the key request; In response to the successful verification of the basic key, a dynamic key is generated for the client, and the information of the dynamic key is returned to the client. After receiving the service data sent by the client, the service data is decrypted using the dynamic key corresponding to the client. If decryption fails, it is determined that there is a risk of latitude and longitude forgery.

13. The method according to claim 12, characterized in that, Returning the information of the dynamic key to the client includes: The dynamic key is split into at least two dynamic key segments; The at least two dynamic key segments are sent to the client through at least two different communication connections, so that the client can use the at least two dynamic key segments to assemble the dynamic key.

14. The method according to any one of claims 10 to 13, characterized in that, The method further includes at least one of the following: If no risk of latitude and longitude forgery is detected, the target latitude and longitude is determined using the multiple latitude and longitude data, and the target latitude and longitude and its signature are returned to the client. If no risk of latitude and longitude spoofing is detected, the target latitude and longitude is determined using the multiple latitude and longitude data, the address information corresponding to the target latitude and longitude is queried using the target latitude and longitude, and the address information and its signature are returned to the client.

15. A latitude and longitude watermark verification device, installed on a client side, characterized in that, The device includes: The data acquisition unit is configured to acquire multiple latitude and longitude data for the target image, wherein the multiple latitude and longitude data includes at least latitude and longitude data acquired by calling the C / C++ language layer positioning interface; The stitching processing unit is configured to stitch together the multiple latitude and longitude data to obtain business data. The data sending unit is configured to send the business data to the server so that the server can detect the risk of latitude and longitude spoofing by comparing the differences of multiple latitude and longitude data contained in the business data. The risk handling unit is configured to perform risk handling in response to the existence of latitude and longitude forgery risk.

16. A latitude and longitude watermark verification device, installed on a server side, characterized in that, The device includes: The data receiving unit is configured to receive business data sent by the client. The business data is obtained by splicing multiple latitude and longitude data, and the multiple latitude and longitude data includes at least the latitude and longitude data obtained by the client by calling the C / C++ language layer positioning interface. The risk detection unit is configured to detect the presence of latitude and longitude forgery risk by comparing the differences between the plurality of latitude and longitude data; The data sending unit is configured to send information indicating the risk of latitude and longitude spoofing or a risk handling instruction to the client in response to detecting a risk of latitude and longitude spoofing, so that the client can perform risk handling.

17. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method described in any one of claims 1 to 14.

Images