Data access authentication method and device, network equipment, medium and program product

Abstract

The present disclosure provides a data access authentication method and device, network equipment, medium and program product, and relates to the technical field of Internet. The data access authentication method comprises: receiving a DOIP identifier analysis request sent by a data request end, the DOIP identifier analysis request carrying a business requirement parameter, a physical location compliance verification parameter and a security verification parameter; performing identity security verification on the data request end based on the security verification parameter; if the identity security verification is passed, performing physical location compliance verification of the data request end based on the physical location compliance verification parameter; if the physical location compliance verification is passed, generating a PPP-Token, the PPP-Token being used for data access authentication of a data provider end, the PPP-Token carrying digital object metadata corresponding to the business requirement parameter; and sending DOIP response information carrying the PPP-Token to the data request end. Through the technical scheme of the present disclosure, the credibility of the client location verification can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of Internet technology, and in particular to a data access authentication method, a data access authentication device, a network device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] In current internet business scenarios involving data element circulation and cross-domain data access, data is required to circulate and be used only within specific geographical areas (such as within China). Currently, compliance verification of the geographical location of the access requester mainly relies on server-side GeoIP tracing or terminal GPS, base station, and Wi-Fi self-reporting of location to determine whether the user's access area is compliant. However, since this method of location verification is easily forged and tampered with, the reliability of location verification evidence is low, which easily leads to illegal access vulnerabilities where the user's identity verification passes but the actual physical access location is illegal.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] The purpose of this disclosure is to provide a data access authentication method, a data access authentication device, a network device, a storage medium, and a computer program product, which at least to some extent overcome the problem of poor performance in network element fault prediction in related technologies.

[0005] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0006] According to one aspect of this disclosure, a data access authentication method is provided, comprising: applying to a data requesting end, including: constructing a DOIP identifier resolution request based on a Digital Object Interface Protocol, the DOIP identifier resolution request carrying service requirement parameters, physical location compliance verification parameters, and security verification parameters; sending the DOIP identifier resolution request to a resolution server, wherein the resolution server to which the DOIP identifier resolution request is sent is determined by the operator network based on anycast routing addressing; receiving DOIP response information fed back by the resolution server, the DOIP response information carrying a Physical Proximity Proof Token (PPP-Token), the PPP-Token being generated by the resolution server after verifying the physical location compliance verification parameters and the security verification parameters, the PPP-Token being used by a data provider for data access authentication, the PPP-Token carrying digital object metadata corresponding to the service requirement parameters; sending a data access request carrying the PPP-Token to the data provider; and receiving target data matching the digital object metadata sent by the data provider after successful authentication of the PPP-Token.

[0007] In one embodiment of this disclosure, the business requirement parameters include a target digital object identifier and / or a business identifier; the physical location compliance verification parameters include domain declaration parameters of the data requesting end for the compliant access area and / or policy domain, and verification method declaration parameters; the security verification parameters include a one-time random number for anti-replay association, and a digital signature and / or integrity verification value for the target digital object identifier and / or the business identifier, the domain declaration parameters, the one-time random number, and the verification method declaration parameters.

[0008] In one embodiment of this disclosure, before receiving the DOIP response information from the parsing server, the method further includes: receiving a challenge message sent by the parsing server, wherein the physical location compliance verification includes anycast proximity evidence verification and terminal trusted proof verification; if the result of the anycast proximity evidence verification is questionable, the parsing server sends the challenge message; in response to the challenge message, in a trusted execution environment, the following steps are performed: extracting a one-time random number and a network observation digest carried in the challenge message; encrypting and signing the one-time random number and the network observation digest to obtain a digital signature; adding the terminal network observation data of the local machine to the digital signature to obtain a terminal trusted proof; and sending the terminal trusted proof to the parsing server, so that the parsing server generates the PPP-Token after verifying the digital signature of the terminal trusted proof and determining that the network-side access observation data collected by the parsing server is consistent with the terminal network observation data.

[0009] In one embodiment of this disclosure, constructing a DOIP identifier resolution request based on the Digital Object Interface protocol includes: configuring a Location Semantic Extension (LSE) segment in the request header or message extension field area of ​​the original identifier resolution request message; and filling the LSE segment with the number of business requirement parameters, physical location compliance verification parameters, and security verification parameters to obtain the identifier resolution request.

[0010] According to another aspect of this disclosure, a data access authentication method is provided, applied to a parsing server, comprising: receiving a DOIP identifier resolution request sent by a data requesting client, the DOIP identifier resolution request carrying business requirement parameters, physical location compliance verification parameters, and security verification parameters; performing identity security verification on the data requesting client based on the security verification parameters; if the identity security verification passes, performing physical location compliance verification on the data requesting client based on the physical location compliance verification parameters; if the physical location compliance verification passes, generating a PPP-Token, the PPP-Token being used by a data provider for data access authentication, the PPP-Token carrying digital object metadata corresponding to the business requirement parameters; and sending DOIP response information carrying the PPP-Token to the data requesting client.

[0011] In one embodiment of this disclosure, the security verification parameters include a digital signature and / or integrity verification value, and a one-time random number. The identity security verification of the data requesting client is performed based on the security verification parameters, including: invoking a pre-stored client certificate of the data requesting client; decrypting the digital signature and / or the integrity verification value based on the public key in the client certificate to obtain an original digest; performing hash calculations on the business requirement parameters, physical location compliance verification parameters, and security verification parameters to obtain a verification digest; detecting whether the verification digest is consistent with the original digest; if the verification digest is consistent with the original digest, the identity security verification is deemed successful; if they are inconsistent, the DOIP identifier resolution request is rejected.

[0012] In one embodiment of this disclosure, the physical location compliance verification parameters include domain declaration parameters of the data requesting end for the compliant access area and / or policy domain, and verification method declaration parameters. The physical location compliance verification includes anycast proximity evidence verification. The physical location compliance verification of the data requesting end is performed based on the physical location compliance verification parameters, including: collecting network-side access observation data based on the operator border gateway protocol (BGP) topology anycast routing addressing mechanism; performing policy domain consistency verification and baseline deviation verification based on the network-side access observation data, the domain declaration parameters, and the verification method declaration parameters; if both the policy domain consistency verification and the baseline deviation verification pass, the physical location compliance verification is determined to be passed; if both the policy domain consistency verification and the baseline deviation verification fail, the physical location compliance verification fails; if either the policy domain consistency verification or the baseline deviation verification passes, the proximity evidence is determined to be questionable.

[0013] In one embodiment of this disclosure, the access observation data includes the node ID of the parsing server, routing domain information, round-trip delay vectors between multiple observation points in the Anycast Identifier Resolution Node Cluster to which the parsing server belongs and the data requester, and the transmission path characteristics of the DOIP identifier resolution request. Based on the network-side access observation data, the domain declaration parameters, and the verification method declaration parameters, policy domain consistency verification and baseline deviation verification are performed, including: performing policy domain consistency verification between the compliant access area and / or policy domain and the routing domain information based on the verification method declaration parameters; invoking the network baseline record bound to the business requirement parameters by the data requester during the registration and account opening phase, the network baseline record including the persistent and legitimate network characteristics of the data requester; and comparing the node ID, the round-trip delay vector, and the transmission path characteristics with the network baseline record to perform the baseline deviation verification.

[0014] In one embodiment of this disclosure, the physical location compliance verification further includes terminal trusted proof verification. Performing physical location compliance verification on the data requesting end based on the physical location compliance verification parameters further includes: if the proximity evidence is questionable, generating a challenge message, the challenge message carrying a one-time random number and a network observation digest; sending the challenge message to the data requesting end; receiving a terminal trusted proof generated by the data requesting end in a trusted execution environment based on the challenge message; and after verifying the terminal trusted proof, if the terminal network observation data in the terminal trusted proof is found to be consistent with the network-side access observation data, determining that the physical location compliance verification has passed.

[0015] In one embodiment of this disclosure, the PPP-Token includes a token identifier, digital object metadata corresponding to the business requirement parameters, a data request terminal area obtained by passing the policy domain consistency verification, the verification method used for this physical location compliance verification, the access restriction rules of the PPP-Token, and the corresponding digital signature.

[0016] In one embodiment of this disclosure, before performing identity security verification on the data requesting end based on the security verification parameters, the method further includes: sending a handshake message and / or a data read request to the data providing end; and receiving the verification method corresponding to the verification method declaration parameters and the digital object metadata corresponding to the business requirement parameters fed back by the data providing end.

[0017] According to another aspect of this disclosure, a data access authentication method is provided, applied to a data provider, comprising: receiving a data access request carrying a PPP-Token sent by a data requesting end, the PPP-Token carrying digital object metadata; authenticating the PPP-Token by signature, validity period, and binding constraints; and, upon successful authentication of the signature, validity period, and binding constraints, sending target data matching the digital object metadata to the data requesting end.

[0018] In one embodiment of this disclosure, the PPP-Token is authenticated by signing, validating, and binding constraints, including: obtaining a verification public key from a pre-set certificate, public key infrastructure, or digital object proxy to verify the validity of the digital signature of the PPP-Token; reading the expiration time of the exp field in the PPP-Token to detect whether the PPP-Token has exceeded its validity period; and extracting the constraint parameters in the bind field and comparing them with the session matching parameters carried in the data access request to perform binding constraint authentication.

[0019] In one embodiment of this disclosure, before receiving a data access request carrying a PPP-Token sent by a data requesting end, the method further includes: receiving a handshake message and / or a data read request sent by a parsing server, wherein the handshake message and / or data read request carries verification method declaration parameters and business requirement parameters; and feeding back to the parsing server a verification method corresponding to the verification method declaration parameters and digital object metadata corresponding to the business requirement parameters, wherein the verification method and the digital object metadata are used to generate the PPP-Token.

[0020] According to another aspect of this disclosure, a data access authentication device is provided, applied to a data request end, comprising: a construction module, configured to construct a DOIP identifier resolution request based on the Digital Object Interface Protocol, the DOIP identifier resolution request carrying service requirement parameters, physical location compliance verification parameters, and security verification parameters; a first sending module, configured to send the DOIP identifier resolution request to a resolution server, wherein the resolution server to which the DOIP identifier resolution request is sent is determined by the operator network based on anycast routing addressing; a first receiving module, configured to receive DOIP response information fed back by the resolution server, the DOIP response information carrying a Physical Proximity Proof Token (PPP-Token), the PPP-Token being generated by the resolution server after verifying the physical location compliance verification parameters and the security verification parameters, the PPP-Token being used by a data provider end for data access authentication, the PPP-Token carrying digital object metadata corresponding to the service requirement parameters; a second sending module, configured to send a data access request carrying the PPP-Token to the data provider end; and a second receiving module, configured to receive target data matching the digital object metadata sent by the data provider end after successful authentication of the PPP-Token.

[0021] According to another aspect of this disclosure, a data access authentication device is provided, applied to a parsing server, comprising: a third receiving module, configured to receive a DOIP identifier resolution request sent by a data requesting end, the DOIP identifier resolution request carrying business requirement parameters, physical location compliance verification parameters, and security verification parameters; a first verification module, configured to perform identity security verification on the data requesting end based on the security verification parameters; a second verification module, configured to perform physical location compliance verification on the data requesting end based on the physical location compliance verification parameters if the identity security verification passes; a generation module, configured to generate a PPP-Token if the physical location compliance verification passes, the PPP-Token being used by a data provider for data access authentication, the PPP-Token carrying digital object metadata corresponding to the business requirement parameters; and a third sending module, configured to send DOIP response information carrying the PPP-Token to the data requesting end.

[0022] According to another aspect of this disclosure, a data access authentication device is provided, applied at a data provider, comprising: a fourth receiving module for receiving a data access request carrying a PPP-Token sent by a data requesting end, the PPP-Token carrying digital object metadata; an authentication module for authenticating the PPP-Token by signature, validity period, and binding constraints; and a fourth sending module for sending target data matching the digital object metadata to the data requesting end after the signature, validity period, and binding constraints have been authenticated.

[0023] According to another aspect of this disclosure, a network device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; the processor being configured to perform the data access authentication method of the first aspect described above by executing the executable instructions.

[0024] According to another aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the data access authentication method described above.

[0025] According to another aspect of this disclosure, a computer program product is provided, on which a computer program is stored, which, when executed by a processor, implements the above-described data access authentication method.

[0026] The data access authentication scheme provided in the embodiments of this disclosure encapsulates service requirement parameters, physical location compliance verification parameters, and security verification parameters in the DOIP identifier resolution request. The operator's anycast routing addressing mechanism completes the request distribution, sending the request to the resolution server in the corresponding area. The network side can generate network access observation data based on the operator's underlying routing, which cannot be tampered with by the terminal. The trusted resolution server can complete client identity security verification and physical location dual-layer compliance verification based on the generated network access observation data and the DOIP identifier resolution request reported by the data requesting terminal. After the verification is passed, a PPP-Token carrying the area verification result, session binding constraints, and the server's trusted signature is generated, and the data requesting terminal carries this token. When an access request is initiated to the data provider, the data provider only needs to independently verify the token to confirm the compliance of the access location. By deploying the trusted location verification in advance on the parsing server, and using the immutable operator network observation data as the basis for location determination, the credibility of location verification is improved. It can also intercept illegal access behavior that is compliant in identity verification but violates the actual network area access. The PPP-Token, as a location compliance credential that can be independently verified and reused, integrates the downstream data authentication process into the DOIP protocol interaction link. The downstream data provider does not need to repeatedly build a location verification process that is easily forged and tampered with. It realizes trusted control of regional access at the protocol layer to adapt to the compliance control requirements of data elements that are restricted to circulation and use in designated geographical areas.

[0027] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0028] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0029] Figure 1 This diagram illustrates a flowchart of a data access authentication method according to an embodiment of the present disclosure; Figure 2 A flowchart illustrating another data access authentication method in an embodiment of this disclosure is shown; Figure 3 A flowchart illustrating another data access authentication method in an embodiment of this disclosure is shown; Figure 4 This diagram illustrates a data access authentication system according to an embodiment of the present disclosure. Figure 5 This illustration shows an interaction diagram based on DOIP location semantic extension in an embodiment of the present disclosure; Figure 6 A flowchart illustrating another data access authentication method in an embodiment of this disclosure is shown; Figure 7 This diagram illustrates a data access authentication device according to an embodiment of the present disclosure. Figure 8 This diagram illustrates a data access authentication device according to an embodiment of the present disclosure. Figure 9 This diagram illustrates a data access authentication device according to an embodiment of the present disclosure. Figure 10 A structural block diagram of a computer device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0030] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0031] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0032] In business scenarios such as data element circulation and cross-domain data access, it is necessary to reliably verify the physical location of the data access requester to prevent unauthorized cross-regional data transfer. Related technologies use GeoIP (Geographic IP) lookup of the server's source IP or terminal GPS (Global Positioning System), base station, or Wi-Fi self-reported location to determine the compliance of the access area. However, these verification methods are easily bypassed by VPNs (Virtual Private Networks), proxies, and domestic jump servers spoofing IPs. Furthermore, the location data reported by the terminal can be artificially tampered with or simulated.

[0033] In addition, the DOA (Digital Object Architecture) / DOIP (Digital Object Interface Protocol) system can perform identity authentication and digital object parsing, but the protocol does not have location semantic related interaction capabilities and cannot complete location compliance verification at the protocol layer.

[0034] Therefore, there is an urgent need for a trusted geofence management solution that introduces location semantics into the DOIP protocol interaction layer and generates location proof tokens that can be independently verified by data providers.

[0035] To facilitate understanding, the following is an explanation of several terms used in this application.

[0036] Anycast: Multiple geographically dispersed nodes share the same service IP prefix, and requests are routed to the node that is "topologically closer" through the operator's network. In general Internet access scenarios, it is difficult for the client to actively and accurately control the landing point.

[0037] DOA (Digital Object Architecture): Used for the identification, parsing, and management of digital objects.

[0038] DOIP (Digital Object Interface Protocol): Used for clients to interact with DOA / Handle services.

[0039] Handle / Identifier: A persistent identifier in the DOA system (e.g., 86.5000 / xxxxx).

[0040] LSE (Location-Semantic Extension): A set of extended fields defined in DOIP requests / responses to carry location semantic objects such as location claims, challenge response elements, and proof result tokens.

[0041] PPP (Physical Proximity Proof): In a DOIP interaction, a set of evidence used to prove to the Identifier Resolution Service that the physical proximity reflected by its network-side observations is consistent with its allowed area. PPP can be generated by a combination of one or more proof methods, such as Anycast, multipoint measurement, and trusted terminal proof.

[0042] PPP-Token (Proof of Physical Proxies Token): A token issued by the identifier resolution service after completing PPP verification, which can be independently verified by the data provider and is used to restrict subsequent data access.

[0043] TEE (Trusted Execution Environment): Used to generate an immutable proof of the terminal environment.

[0044] The following will describe in more detail each step of the data access authentication method in this example embodiment, with reference to the accompanying drawings and embodiments.

[0045] Figure 1 A flowchart of a data access authentication method according to an embodiment of this disclosure is shown.

[0046] like Figure 1 As shown, a data access authentication method according to an embodiment of this disclosure, applied to a data requesting end, includes: Step S102: Construct a DOIP identifier resolution request based on the Digital Object Interface Protocol. The DOIP identifier resolution request carries business requirement parameters, physical location compliance verification parameters, and security verification parameters.

[0047] In some embodiments, the DOIP identifier resolution request is an interactive message that encapsulates parameters such as business access, location verification, and security verification in accordance with the protocol specification, and is used to initiate digital object access permission verification to the resolution server.

[0048] In one embodiment of this disclosure, the business requirement parameters include a target digital object identifier and / or a business identifier; the physical location compliance verification parameters include domain declaration parameters of the data requesting end for the compliant access area and / or policy domain, and verification method declaration parameters; the security verification parameters include a one-time random number for anti-replay association, and a digital signature and / or integrity verification value for the target digital object identifier and / or business identifier, the domain declaration parameters, the one-time random number, and the verification method declaration parameters.

[0049] In some embodiments, the business requirement parameter corresponds to the field handle_id, which is the target digital object identifier or business identifier, used to specify the digital object or service that the data requesting end wishes to access; the physical location compliance verification parameters include the domain declaration parameter client_geo_assertion and the verification method declaration parameter proof_hint. client_geo_assertion is the client's proactive declaration of its geographical or network region that conforms to the access policy, and can be filled with a country code, region code, autonomous system number, or operator domain. proof_hint is used by the client to declare the physical proximity that this request will use or support. The proof method may include anycast and / or tee; the security verification parameters include a one-time random number ppp_nonce and a client signature client_sig. ppp_nonce is a random string generated by the server and is used for the response interaction between the challenge and the client to prevent replay attacks and to associate the request with the current proof session. client_sig is a digital signature or integrity verification value generated for the target digital object identifier, domain declaration parameters, one-time random number, and verification method declaration parameters. The signature private key can be the device's pre-installed private key or the private key corresponding to the client certificate issued by the identifier resolution service, and is used to verify the integrity of the request and the identity of the data requester.

[0050] Step S104: Send a DOIP identifier resolution request to the resolution server, wherein the resolution server to which the DOIP identifier resolution request is sent is determined by the operator network based on anycast routing addressing.

[0051] In some embodiments, the operator network uses anycast routing to automatically allocate corresponding identifier resolution node clusters based on the network area where the data circulation client is located. If the client is in a domestic network area, the DOIP identifier resolution request will be automatically routed to the domestic anycast identifier resolution node cluster, and the domestic decision node will complete the verification. If the client is in a foreign network area, the request will be automatically routed to the foreign anycast identifier resolution node cluster, and the foreign decision node will process it. The identifier resolution node clusters on the domestic and foreign sides complete data interaction through a cluster cross-domain secure synchronization mechanism. The data provider only recognizes the proximity proof token issued by the domestic resolution node cluster. Data can only be released to legitimate users in the domestic area after the token verification is completed, thereby distinguishing between legitimate access in the domestic area and illegal access from abroad.

[0052] Step S106: Receive the DOIP response information from the parsing server. The DOIP response information carries a Physical Proximity Proof Token (PPP-Token). The PPP-Token is generated by the parsing server after the physical location compliance verification parameters and security verification parameters have been verified. The PPP-Token is used by the data provider for data access authentication. The PPP-Token carries the metadata of the digital object corresponding to the business requirement parameters.

[0053] In some embodiments, the PPP-Token is a location compliance credential issued by the parsing server after completing multi-level parameter verification. The token encapsulates the proof method identifier of the current verification, the client-declared area, the session random number, the target digital object metadata, and the server-side digital signature. The data provider can independently verify the token signature and location verification record without having to repeatedly execute the complex location verification process.

[0054] Step S108: Send a data access request carrying a PPP-Token to the data provider.

[0055] Step S110: Receive target data sent by the data provider after PPP-Token authentication, which matches the metadata of the digital object.

[0056] In this embodiment, by encapsulating service requirement parameters, physical location compliance verification parameters, and security verification parameters in the DOIP identifier resolution request, the operator's anycast routing addressing mechanism completes the request distribution, sending the request to the resolution server in the corresponding area. The network side can generate network access observation data based on the operator's underlying routing, which cannot be tampered with by the terminal. The trusted resolution server can complete client identity security verification and physical location dual-layer compliance verification based on the generated network access observation data and the DOIP identifier resolution request reported by the data requester. After the verification is successful, a PPP-Token carrying the area verification result, session binding constraints, and the server's trusted signature is generated. The data requester carries this token to the data provider. When initiating an access, the data provider only needs to independently verify the token to confirm the compliance of the access location. By deploying the trusted location verification in advance on the parsing server, and using the immutable operator network observation data as the basis for location determination, the credibility of location verification is improved. It can also intercept illegal access behavior that is compliant in identity verification but violates the actual network area access. PPP-Token, as a location compliance credential that can be independently verified and reused, integrates the downstream data authentication process into the DOIP protocol interaction link. The downstream data provider does not need to repeatedly build a location verification process that is easily forged and tampered with. It realizes end-to-end trusted regional access control at the protocol layer to adapt to the compliance control requirements of data elements being restricted to circulation and use in designated geographical areas.

[0057] In one embodiment of this disclosure, before receiving the DOIP response information from the parsing server, the method further includes: The server receives and parses challenge messages sent by the parsing server. The physical location compliance verification includes any-broadcast proximity evidence verification and terminal trust proof verification. If the result of any-broadcast proximity evidence verification is questionable, the parsing server sends a challenge message.

[0058] In response to the challenge message, the following steps are performed in the trusted execution environment: extract the one-time random number and network observation digest carried in the challenge message; encrypt and sign the one-time random number and network observation digest to obtain a digital signature; add the local terminal network observation data to the digital signature to obtain the terminal's trusted proof.

[0059] In some embodiments, the Trusted Execution Environment (TEE) is completely isolated from the terminal's general-purpose operating system based on a hardware security isolation mechanism and an independent security kernel. When the terminal receives a challenge message from the parsing server, the one-time random number and network observation digest carried in the message are transferred to the TEE for processing. The entire data extraction and reading operation is completed within the isolated security domain. Subsequently, the locally stored encrypted private key is used in the security domain to perform an encrypted signature operation on the above data. During the signing process, the private key remains in the TEE and is not exported to the external operating system. After the signature is completed, the terminal network observation data collected locally by the terminal is concatenated and appended to the digital signature to generate a terminal trust certificate. After the terminal trust certificate is generated, it is output to the general-purpose operating system and sent to the parsing server. The isolated operation method can prevent malicious programs on the terminal side from stealing the signature private key and tampering with the original network observation data, thus ensuring the authenticity of the generated terminal trust certificate.

[0060] The terminal's trusted certificate is sent to the parsing server. After the parsing server verifies the digital signature of the terminal's trusted certificate and determines that the network access observation data collected by the parsing server is consistent with the terminal's network observation data, it generates a PPP-Token.

[0061] In this embodiment, a challenge-response verification process is set up for scenarios where the verification of anycast proximity evidence is questionable. The parsing server sends a challenge message carrying a one-time random number and a network observation summary. The terminal completes data signing in the trusted execution environment and generates a terminal trusted certificate by superimposing local terminal network observation data. The terminal then sends the certificate back to the parsing server. The parsing server re-verifies the observation data reported by the terminal with the network access observation data it collects. After both verifications pass, a PPP-Token is issued to compensate for the insufficient evidentiary strength of a single anycast route ranging evidence. Based on the trusted execution environment, the risk of the terminal system tampering with the observation data is isolated. Through a two-layer verification logic of bidirectional cross-comparison between the terminal's local data and the network-side backend data, the objectivity and authenticity of the location verification are strengthened, and the defect that relying solely on anycast routes cannot completely confirm the terminal's true access area is solved.

[0062] In one embodiment of this disclosure, constructing a DOIP identifier resolution request based on the Digital Object Interface protocol includes: Configure the Location Semantic Extension (LSE) segment in the request header or message extension field area of ​​the original identifier resolution request message; fill the LSE segment with the number of business requirement parameters, physical location compliance verification parameters, and security verification parameters to obtain the identifier resolution request.

[0063] In some embodiments, LSE stands for Location Semantic Extension, which is a dedicated storage segment set in the DOIP original message header or message extension field to carry business requirement parameters, physical location compliance verification parameters, and security verification parameters.

[0064] In this embodiment, by configuring the Location Semantic Extension (LSE) segment within the native structure of the DOIP message, the standardized carrying of location-related semantic data can be achieved without modifying the basic DOIP message framework. All parameters related to business access, region declaration, and security signature are filled into independent fields of the LSE, which facilitates the parsing server to quickly locate and extract verification parameters, and simultaneously completes location compliance judgment and message integrity verification. The protocol layer geolocation control function can be achieved simply by modifying the message extension, without the need to reconstruct the entire DOIP interaction system.

[0065] like Figure 2 As shown, a data access authentication method according to another embodiment of this disclosure, applied to a parsing server, includes: Step S202: Receive the DOIP identifier resolution request sent by the data requesting end. The DOIP identifier resolution request carries business requirement parameters, physical location compliance verification parameters, and security verification parameters.

[0066] Step S204: Perform identity security verification on the data requesting end based on security verification parameters.

[0067] In some embodiments, identity security verification is based on the comparison of hash digests with the public key of the client certificate to verify the integrity of the DOIP request message.

[0068] Step S206: If the identity security verification passes, perform physical location compliance verification on the data request end based on the physical location compliance verification parameters.

[0069] In some embodiments, physical location compliance verification is based on comparing the operator's network observation data with the client's region declaration to verify that the requester's actual access to the network region complies with the business access region control rules.

[0070] Step S208: If the physical location compliance verification passes, a PPP-Token is generated. The PPP-Token is used for data access authentication by the data provider. The PPP-Token carries the metadata of the digital object corresponding to the business requirement parameters.

[0071] In some embodiments, data access authentication refers to the data provider verifying the legality of the PPP-Token to determine access permissions, and digital object metadata refers to the attribute information of the corresponding target business or digital object.

[0072] Step S210: Send the DOIP response information carrying the PPP-Token to the data requesting end.

[0073] In this embodiment, after the parsing server receives the DOIP identifier parsing request from the data requester, it extracts security verification parameters to complete the verification of the requester's identity legitimacy and message integrity. After the identity verification is correct, it performs network-side physical area verification. After both verifications pass, it generates a constraint field and a PPP-Token with a trusted server signature, and encapsulates it into the DOIP response and sends it to the requester. Identity security verification and network location compliance verification are centrally deployed on the trusted parsing server to complete the pre-access verification. The downstream data provider does not need to repeatedly execute complex identity and location verification logic. The PPP-Token has a built-in globally unique identifier, business binding relationship, and area verification result, which can be independently verified by the data provider to achieve end-to-end trusted area access control at the DOIP protocol layer.

[0074] In one embodiment of this disclosure, the security verification parameters include a digital signature and / or integrity verification value, and a one-time random number. Based on these security verification parameters, identity security verification of the data requesting end is performed, including: The system invokes the pre-stored client certificate of the data requesting end; based on the public key in the client certificate, it decrypts the digital signature and / or integrity verification value to obtain the original digest; it performs hash calculations on the business requirement parameters, physical location compliance verification parameters, and security verification parameters to obtain the verification digest; it checks whether the verification digest is consistent with the original digest; if the verification digest is consistent with the original digest, the identity security verification is deemed successful; if the comparison is inconsistent, the DOIP identifier resolution request is rejected.

[0075] In some embodiments, identity security verification is performed based on a client certificate asymmetric encryption mechanism. The server pre-stores the client certificates corresponding to each data request client, which include the public key publicly disclosed by the request client. The server extracts the digital signature or integrity check value carried in the DOIP request, calls the corresponding client certificate public key to perform decryption operation, and restores the original message digest generated when the request client signed. The server further extracts the business, location, and security check parameters in this DOIP request independently, performs hash operation to generate a check digest, and finally compares the original digest obtained by decryption with the locally calculated check digest. The digest matching result determines whether the request message is complete and tamper-proof, and whether the signature was generated by a legitimate client private key.

[0076] In this embodiment, by employing asymmetric certificate verification and hash digest dual verification logic, the private key is only stored locally on the data requesting end, and only the public key is distributed to the parsing server. External entities cannot forge legitimate digital signatures. By comparing the local hash digest with the client signature digest, it can be identified whether the message has been tampered with during transmission, thereby further intercepting DOIP parsing requests initiated by forged identities. Identity security access is completed before location compliance verification, preventing the parsing server from consuming computing power to perform subsequent complex regional verification processes for forged identity requests, thus improving the overall operating efficiency and access security of the parsing server.

[0077] In one embodiment of this disclosure, the physical location compliance verification parameters include domain declaration parameters of the data requesting end for compliant access areas and / or policy domains, and verification method declaration parameters. The physical location compliance verification includes any-broadcast proximity evidence verification. Performing physical location compliance verification on the data requesting end based on the physical location compliance verification parameters includes: Based on the BGP topology anycast routing addressing mechanism of the operator's border gateway protocol, network-side access observation data is collected; based on the network-side access observation data, domain declaration parameters, and verification method declaration parameters, policy domain consistency verification and baseline deviation verification are performed; if both policy domain consistency verification and baseline deviation verification pass, the physical location compliance verification is determined to be passed; if both policy domain consistency verification and baseline deviation verification fail, the physical location compliance verification is determined to be failed; if either policy domain consistency verification or baseline deviation verification passes, the proximity evidence is determined to be questionable.

[0078] In some embodiments, physical location compliance verification may include two layers of verification logic. The first layer is any-cast proximity evidence verification based on the operator's underlying network data, which determines the region by objectively collecting client access network characteristics based on routing topology. The second layer is terminal trusted proof verification, which is triggered when the network evidence in the first layer is questionable, and cross-verifies the real access region based on trusted observation data generated by the terminal isolation security domain.

[0079] In some embodiments, a distributed anycast node cluster is constructed based on the operator's global BGP routing topology. Client DOIP requests will be automatically forwarded to the nearest physical anycast resolution node based on the underlying BGP routing rules. The resolution node can capture complete routing domain information, node round-trip time, transmission path and other native network characteristics during the request transmission process. This type of network data is natively generated by the operator's underlying routing network and cannot be tampered with or forged by terminal-side programs.

[0080] In some embodiments, policy domain consistency verification refers to matching and comparing the compliant access areas and / or policy domain declarations reported by the client with the operator's routing domain information to determine whether the access areas declared by the client match the routing domain to which the current actual access network belongs.

[0081] In some embodiments, baseline deviation verification refers to retrieving the legitimate resident network baseline features retained during the client's account opening phase, comparing the node ID, round-trip delay vector, and transmission path features collected this time with the baseline records item by item, and determining whether the current network features deviate from the client's regular legitimate access baseline beyond a threshold.

[0082] In this embodiment, native and tamper-proof network observation data collected from the operator's BGP anycast routing is used as the basis for location verification. Proximity verification is performed by combining short-range matching and baseline feature deviation. Location compliance is determined only when all verifications pass. The operator's underlying network routing data has high authenticity, which can reduce the defect that the terminal's self-reported location data can be tampered with. The two-layer verification logic can identify violations such as client forging regional declarations and using proxy VPNs to change access networks. At the same time, for scenarios where only single-layer verification passes and network proximity evidence is questionable, a secondary verification process for subsequent terminal trusted proof is set up to balance the rigor of regional control and the compatibility of business access.

[0083] In one embodiment of this disclosure, the access observation data includes the node ID of the parsing server, routing domain information, round-trip delay vectors between multiple observation points in the anycast identifier parsing node cluster to which the parsing server belongs and the data requesting end, and the transmission path characteristics of the DOIP identifier parsing request. Based on the network-side access observation data, domain declaration parameters, and verification method declaration parameters, policy domain consistency verification and baseline deviation verification are performed, including: Based on the verification method, the parameters will perform policy domain consistency verification with the routing domain information for compliant access areas and / or policy domains; during the registration and account opening phase, the data request client will call the network baseline record bound to the business requirement parameters. The network baseline record includes the network characteristics that are resident and valid on the data request client; the node ID, round-trip delay vector, and transmission path characteristics will be compared with the network baseline record to perform baseline deviation verification.

[0084] In some embodiments, the server parses the verification method declaration parameters carried in the request to confirm the target compliant access area and business policy domain range that the verification needs to match. Then, the region and / or policy domain identifier is matched with the collected operator routing domain information to determine whether the network routing domain currently accessed by the client falls within the declared compliant access policy domain range.

[0085] In some embodiments, the network baseline record is a legitimate, permanently resident network feature file that is jointly confirmed and retained by the business side and the parsing server during the registration and account opening stage of the data requesting end. The baseline record is bound to the corresponding business requirement parameters and client identity, and stores network features such as the node ID, round-trip latency range, fixed transmission path, and permanent routing domain of the client for long-term stable and compliant access, which serve as the standard reference benchmark for subsequent baseline deviation verification.

[0086] In some embodiments, the parsing server extracts the node ID, round-trip delay vector, and transmission path features collected in this instance, and retrieves the network baseline record bound to the client item by item for threshold comparison: matching whether the node ID belongs to a legal node permanently resident on the client; comparing the real-time round-trip delay vector with the baseline delay range to determine whether the delay deviation exceeds the preset compliance threshold; verifying whether the current transmission path matches the regular legal transmission path retained by the baseline, and determining that the baseline deviation verification fails if any feature exceeds the compliance deviation threshold.

[0087] In this embodiment, the dedicated network baseline record retained during the account opening stage is used as the verification benchmark. Regional verification is completed from two dimensions: routing domain matching and network feature baseline deviation. It not only verifies whether the client's declared region matches the actual routing domain, but also identifies hidden illegal access scenarios such as the client changing unfamiliar network nodes, long-distance cross-regional access, and abnormal latency and transmission paths caused by proxy forwarding. The baseline record is bound to the client's business identity, and the baseline threshold can be configured based on business management requirements to adapt to the differentiated regional management intensity of different data elements, further improving the identification accuracy of physical location compliance verification and reducing the probability of misjudgment and omission caused by single anycast route verification.

[0088] In one embodiment of this disclosure, the physical location compliance verification further includes terminal trusted proof verification. Performing physical location compliance verification on the data requesting end based on physical location compliance verification parameters also includes: If the proximity evidence is questionable, a challenge message is generated, carrying a one-time random number and a network observation summary; the challenge message is sent to the data requester; the data requester receives the terminal trusted certificate generated in the trusted execution environment based on the challenge message; after the terminal trusted certificate is verified and signed, if the terminal network observation data in the terminal trusted certificate is found to be consistent with the network-side access observation data, the physical location compliance verification is deemed to have passed.

[0089] In some embodiments, the challenge message is a secondary verification instruction issued by the parsing server when there is doubt about the proximity evidence of any broadcast. It carries a randomly generated one-time random number and a network observation summary collected by the parsing node. The terminal trust proof is an immutable location proof generated by the client in a hardware-isolated trusted execution environment based on the challenge message data encryption signature and superimposed local terminal network observation data.

[0090] In some embodiments, the terminal network observation data collected locally by the terminal and the network-side access observation data of the parsing server are collected independently by the terminal and the operator's routing network, respectively. There is no unilateral tampering condition for the two sets of data. By comparing the consistency of the two sets of observation data, it can be verified that the network observation data generated by the terminal is true and valid, so as to prevent the client from tampering with the local observation data and forging the compliant area certificate outside the trusted execution environment.

[0091] In this embodiment, by setting up a secondary verification process for terminal trust proof, the challenge message sent by the server carrying a random number and network observation summary is parsed, and the client completes the signature operation to generate terminal trust proof in a trusted execution environment that is hardware isolated and cannot be tampered with by malicious programs. The server re-verifies the legality of the signature and the consistency of the network observation data collected independently by both ends, which helps to improve the ability to identify covert cross-regional illegal access behavior.

[0092] In one embodiment of this disclosure, the PPP-Token includes a token identifier, digital object metadata corresponding to the business requirement parameters, a data request terminal area obtained by passing the policy domain consistency verification, the verification method used for this physical location compliance verification, access restriction rules for the PPP-Token, and the corresponding digital signature.

[0093] In some embodiments, the globally unique token identifier `token_id` is used for log queries and security audits; `handle_id` refers to the digital object associated identifier bound to the original DOIP request, limiting the token to be used only for the corresponding business, preventing the token from being misappropriated across businesses, and can also represent the metadata of the digital object; `verified_region` refers to the client's real and compliant access region confirmed by network verification, and `method` refers to the set of verification methods actually used in this location verification, recording the verification based on; `bind` refers to multi-dimensional access binding constraints, locking the token to a single access session through multiple constraints such as source IP, target data provider identifier, session flow_id, and token validity period, preventing the token from being stolen and reused; `sig` refers to the digital signature uniformly calculated and generated by the parsing server for all the aforementioned fields, which downstream data providers can independently verify to ensure that the token is complete, tamper-proof, and issued by the trusted parsing server.

[0094] In one embodiment of this disclosure, before performing identity security verification on the data requesting end based on security verification parameters, the method further includes: sending a handshake message and / or a data read request to the data provider; and receiving the verification method corresponding to the verification method declaration parameters and the digital object metadata corresponding to the business requirement parameters from the data provider.

[0095] In this embodiment, before processing DOIP resolution requests and performing security identity verification, the parsing server can also pre-communicate with the downstream data provider to retrieve the standard area verification method and target digital object metadata corresponding to the business. This pre-communicating process can realize real-time synchronization of verification rules and business metadata between the parsing server and the data provider, ensuring the uniformity of the parsing server's location compliance verification standard and the data provider's access authentication standard. This prevents the problem of legitimate access being blocked and illegal access being allowed due to inconsistent verification rules between the two ends. At the same time, obtaining digital object metadata in advance can also reduce the interaction overhead of the data provider repeatedly querying metadata and improve the overall processing efficiency of the access chain.

[0096] A data access authentication method according to another embodiment of this disclosure, applied to a data provider, includes: Step S302: Receive a data access request carrying a PPP-Token sent by the data requesting end.

[0097] Step S304: Sign the PPP-Token, verify its validity period, and authenticate its binding constraints.

[0098] Step S306: After the signature, validity period and binding constraints are authenticated, the target data matching the metadata of the digital object is sent to the data requesting end.

[0099] In this embodiment, PPP-Token is uniformly used as the sole access credential on the data provider side. Only three verifications are required for the token: signature, validity period, and session binding. There is no need to repeatedly perform complex client identity verification and network area compliance verification, which simplifies the authentication logic of the data provider and reduces local computing power overhead. PPP-Token has built-in parsing of the area verification results, business binding relationship, session locking constraints, and server digital signature after the server has completed multi-layer trusted verification. The three verifications can respectively intercept security risks such as forged and tampered tokens, expired replay access, and token theft across sessions and / or across services. Only after all three verifications pass will the target data matching metadata be sent to the requesting party. This extends the area compliance control capability to the data delivery stage, realizing full-link trusted area access control from request initiation, network location verification, token issuance to data distribution, ensuring that data is only open to legitimate requesters with area compliance.

[0100] In one embodiment of this disclosure, authentication of the PPP-Token for signing, validity period, and binding constraints includes: Obtain the verification public key from a pre-installed certificate, public key infrastructure, or digital object agent to verify the validity of the digital signature of the PPP-Token; read the exp expiration time in the bind field of the PPP-Token to detect whether the PPP-Token has exceeded its validity period; extract the constraint parameters in the bind field and compare them with the session matching parameters carried in the data access request to perform binding constraint authentication.

[0101] In some embodiments, PPP-Token authentication is completed based on asymmetric cryptography and structured binding constraints. The data provider obtains the trusted verification public key corresponding to the parsing server from a pre-set certificate store, public key infrastructure, or digital object proxy. The public key is used to decrypt the digital signature in the sig field of the token and restore the original signature message to verify that the overall content of the token has not been tampered with and was issued by the trusted parsing server. The expiration timestamp of exp in the bind field of the token is read and compared with the local real-time system time to determine whether the token has exceeded the legal validity period and to intercept replay access initiated by expired tokens. Multiple session constraint parameters such as src_ip, flow_id, and dst identifier built into the bind field are extracted and matched item by item with the client source address, transaction session ID, and its own service identifier carried in the current data access request to verify that the token can only be used for the current original access session and to prevent the token from being reused in other sessions after being stolen.

[0102] In this embodiment, signature integrity verification, time-limited replay protection verification, and session binding anti-theft verification are implemented in layers, forming a complete token security protection system. Based on the signature verification of the trusted public key of the parsing server, it can accurately identify tampered and forged illegal tokens without the need for local storage of massive client identity files, making the authentication logic lightweight. By limiting the validity period of the token through the exp time threshold, the attack window after the token is leaked is significantly shortened, effectively resisting network replay attacks. Based on multiple parameters of the bind field, the session, client, and target service are strongly bound. Even if the PPP-Token is leaked, the thief cannot use the token for other access sessions or other business data access, reducing the risk of data leakage caused by token theft from multiple dimensions. At the same time, the identity and region verification results completed in advance by the parsing server are reused to prevent the data provider from repeatedly building a complex location verification system, reducing the development and maintenance costs on the business side.

[0103] In one embodiment of this disclosure, before receiving the data access request carrying a PPP-Token sent by the data requesting end, the method further includes: receiving a handshake message and / or a data read request sent by the parsing server, wherein the handshake message and / or data read request carry verification method declaration parameters and business requirement parameters; and feeding back to the parsing server the verification method corresponding to the verification method declaration parameters and the digital object metadata corresponding to the business requirement parameters, wherein the verification method and the digital object metadata are used to generate a PPP-Token.

[0104] In some embodiments, before receiving a data access request carrying a PPP-Token, the data provider actively establishes a pre-handshake interaction link with the parsing server, and receives a handshake message or data read request pushed by the parsing server. The message synchronously carries the verification method declaration parameters and business requirement parameters corresponding to this DOIP request. Based on the parameters in the message, the data provider feeds back the corresponding business standard verification rules and the complete metadata of the target digital object to the parsing server. The parsing server caches this type of data, and when generating a PPP-Token after subsequent verification, it directly encapsulates the metadata of the digital object into the token, thereby realizing the pre-synchronization of verification standards and business metadata between the two ends.

[0105] In this embodiment, the synchronization of verification rules and business metadata between the parsing server and the data provider is completed in advance through a pre-handshake interaction, unifying the compliance verification judgment standards of the two ends and preventing control loopholes such as the blocking of legitimate access and the allowing of unauthorized cross-regional access due to inconsistent verification rules between the two ends. The metadata of digital objects is distributed and cached in advance, and the parsing server can directly encapsulate the metadata when generating PPP-Token. After the data provider's authentication is passed, there is no need to query the database to read the metadata again, reducing the number of database interactions in a single data access link and improving the overall access response speed.

[0106] like Figure 4As shown, the data access authentication architecture in this embodiment is deployed in a telecommunications operator network and can be divided into domestic network areas and overseas network areas. It includes data circulation clients (i.e., data requesters), an identifier resolution service node (i.e., resolution server) cluster, a data provider (DP) node, and domestic and overseas Anycast observation nodes. Data circulation clients include legitimate domestic users and illegitimate overseas users. The device embeds a trusted execution environment. Clients initiate DOIP requests carrying location semantic extension fields, and anycast routing automatically routes the requests. Domestic client requests are forwarded to domestic nodes, and overseas client requests are forwarded to overseas nodes. Anycast resolution node sets are deployed domestically and overseas, corresponding to domestic anycast identifier resolution node clusters (domestic identifier resolution nodes 1, 2, and 3) and overseas anycast identifier resolution node clusters (overseas identifier resolution nodes 1 and 2). The two types of clusters rely on a cross-domain secure synchronization mechanism to complete data interaction. The identifier resolution service nodes within the cluster are Handle / Resolver clusters, which can act as multi-point observation nodes to synchronously detect the same client, generating network-side proximity evidence based on the operator network to complete PPP verification.

[0107] The identifier resolution service nodes centrally process DOIP requests, perform PPP location compliance verification, and issue PPP-Tokens upon successful verification. Domestic data providers, acting as the true data source, only perform proximity proof token verification on PPP-Tokens issued by the domestic cluster. After obtaining the PPP-Token, the client initiates data access to the DP. The DP authenticates the token signature, validity period, and binding constraints item by item. Upon successful authentication, it distributes the target data matching the metadata. Requests from overseas clients are consistently routed to the overseas resolution cluster, preventing the generation of DP-approved compliance tokens. This architecture, by intercepting unauthorized cross-regional access from overseas at the network layer, helps address the security vulnerabilities of traditional location verification evidence having low reliability and allowing access to locations that violate geographical rules despite successful identity verification.

[0108] like Figure 5 As shown, an interaction method based on DOIP location semantic extension according to an embodiment of this disclosure includes: In step S502, the data requesting end sends a 0.DOIP / Op.Retrieve request.

[0109] Among them, the 0.DOIP / Op.Retrieve request is a standard operation request that the data requesting end follows the DOIP protocol specification to initiate a digital object read permission verification to the identifier resolution server. The message encapsulates business requirement parameters, physical location compliance verification parameters, security verification parameters and location semantic extension fields.

[0110] Step S504: The identifier resolution server performs PPP verification by comparing the Permission declared by the client with the service policy.

[0111] Among them, the service policy can be a set of access control rules pre-configured by the data provider and synchronized to the identifier resolution server. It defines the geographical range of access allowed for each digital object, the enabled PPP verification methods, access time limits, session binding restrictions and other constraints, which serve as the benchmark for determining whether PPP verification is compliant.

[0112] Step S506: The identifier resolution server sends Op.Hello / Op.Retrieve.

[0113] Among them, Op.Hello is the DOIP operation command for establishing a pre-handshake interaction between the identifier resolution server and the data provider, and Op.Retrieve is the read command for synchronously pulling the configuration information related to the digital object. The two are combined and sent to the data provider to synchronously obtain DO metadata and verification method set.

[0114] Step S508: The data provider returns DO metadata and a set of available methods.

[0115] Step S510: The identifier resolution server generates a list of callable methods, including the verification conclusion.

[0116] Step S512: The identifier resolution server returns a PPP-Token that includes a set of DOs and methods plus a verification conclusion.

[0117] like Figure 6 As shown, a data access authentication method according to another embodiment of this disclosure includes: Step S602: The identifier resolution server receives the DOIP request message and the Location Semantic Extension (LSE) segment within the message sent by the data requester.

[0118] Step S604: Extract the LSE field content from the received message, and simultaneously complete the verification operation of the client signature client_sig and the one-time random number ppp_nonce.

[0119] Step S606: Determine whether the client signature and ppp_nonce are valid. If the result is "yes", proceed to step S608. If the result is "no", proceed to step S610.

[0120] Step S608: Collect proximity evidence generated by the network side. The evidence includes network observation data such as the current access node ID, multi-node round-trip time (RTT) vector, autonomous system (ASN), and time to live (TTL).

[0121] Step S610: Reject processing, retain audit logs, and return a processing failure result to the client.

[0122] Step S612: The collected network-side observation evidence is compared with the declared region reported by the client through the client_geo_assertion field to determine consistency. The determination dimensions include node affiliation matching, RTT baseline comparison, and TTL numerical deviation verification. If the determination result is "pass", proceed to step S614; if the determination result is "fail", proceed to step S610; if the determination result is "doubtful", proceed to step S618.

[0123] Step S614: Generate a set of methods based on the evidence sources verified during this verification process. The set of methods has two combination forms: {anycast_proximity, baseline_match} and {anycast_proximity, tee_attestation}. Write the generated set of methods into the PPP-Token to be issued.

[0124] Step S616: Issue PPP-Token.

[0125] In step S618, the server sends a challenge message to the client, which carries a new ppp_nonce and a network observation digest, requiring the client to complete the signature operation within the Trusted Execution Environment (TEE) and then send back the terminal's trusted proof.

[0126] In step S620, the identifier resolution server receives the tee_attestation terminal trusted certificate returned by the client, performs a signature verification operation on the digital signature in the certificate, and compares and verifies the local network observation data reported by the terminal with the network side observation data collected by the server itself.

[0127] Step S622: Determine whether the terminal's trusted certificate signature is valid and whether the network observation data at both ends are consistent. If both conditions cannot be met at the same time, return to step S610. If both conditions are met at the same time, proceed to step S616.

[0128] It should be noted that the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this disclosure, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Furthermore, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0129] The following reference Figure 7 This describes a data access authentication device 700 according to an embodiment of the present disclosure. Figure 7The data access authentication device 700 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments disclosed herein.

[0130] The data access authentication device 700 is manifested as a hardware module. Components of the data access authentication device 700 may include, but are not limited to: a construction module 702, used to construct a DOIP identifier resolution request based on the Digital Object Interface Protocol (DOIP), the DOIP identifier resolution request carrying service requirement parameters, physical location compliance verification parameters, and security verification parameters; a first sending module 704, used to send the DOIP identifier resolution request to the resolution server, wherein the resolution server to which the DOIP identifier resolution request is delivered is determined by the operator network using anycast routing addressing; a first receiving module 706, used to receive DOIP response information from the resolution server, the DOIP response information carrying a Physical Proximity Proof Token (PPP-Token), the PPP-Token being generated by the resolution server after verifying the physical location compliance verification parameters and security verification parameters, the PPP-Token being used by the data provider for data access authentication, the PPP-Token carrying digital object metadata corresponding to the service requirement parameters; a second sending module 708, used to send a data access request carrying the PPP-Token to the data provider; and a second receiving module 710, used to receive target data matching the digital object metadata sent by the data provider after successful PPP-Token authentication.

[0131] The following reference Figure 8 This describes a data access authentication device 800 according to an embodiment of the present disclosure. Figure 8 The data access authentication device 800 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments disclosed herein.

[0132] The data access authentication device 800 is manifested in the form of a hardware module. Components of the data access authentication device 800 may include, but are not limited to: a third receiving module 802, used to receive a DOIP identifier resolution request sent by the data requesting end, the DOIP identifier resolution request carrying business requirement parameters, physical location compliance verification parameters, and security verification parameters; a first verification module 804, used to perform identity security verification on the data requesting end based on the security verification parameters; a second verification module 806, used to perform physical location compliance verification on the data requesting end based on the physical location compliance verification parameters if the identity security verification passes; a generation module 808, used to generate a PPP-Token if the physical location compliance verification passes, the PPP-Token being used by the data provider for data access authentication, the PPP-Token carrying digital object metadata corresponding to the business requirement parameters; and a third sending module 810, used to send DOIP response information carrying the PPP-Token to the data requesting end.

[0133] The following reference Figure 9 To describe the data access authentication device 900 according to an embodiment of the present disclosure. Figure 9 The data access authentication device 900 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments disclosed herein.

[0134] The data access authentication device 900 is manifested in the form of a hardware module. The components of the data access authentication device 900 may include, but are not limited to: a fourth receiving module 902, used to receive a data access request carrying a PPP-Token sent by the data requesting end; an authentication module 904, used to authenticate the PPP-Token for signature, validity period, and binding constraints; and a fourth sending module 906, used to send target data matching the digital object metadata to the data requesting end after the signature, validity period, and binding constraints authentication are passed.

[0135] Those skilled in the art will understand that various aspects of this disclosure can be implemented as a system, method, or program product. Therefore, various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0136] The following reference Figure 10 This describes an electronic device 1000 according to this embodiment of the present disclosure. It may be a network device or a terminal. Figure 10 The electronic device 1000 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0137] like Figure 10 As shown, the electronic device 1000 is manifested in the form of a general-purpose computing device. The components of the electronic device 1000 may include, but are not limited to: at least one processing unit 1010, at least one storage unit 1020, and a bus 1030 connecting different system components (including storage unit 1020 and processing unit 1010).

[0138] The storage unit stores program code that can be executed by the processing unit 1010, causing the processing unit 1010 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the processing unit 1010 can perform actions such as... Figure 1 The described solution.

[0139] Storage unit 1020 may include readable media in the form of volatile storage units, such as random access memory (RAM) 10201 and / or cache 10202, and may further include read-only memory (ROM) 10203.

[0140] Storage unit 1020 may also include a program / utility 10204 having a set (at least one) program module 10205, such program module 10205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0141] Bus 1030 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0142] Electronic device 1000 can also communicate with one or more external devices 1070 (e.g., keyboard, pointing device, Bluetooth device, etc.), one or more devices that enable a user to interact with electronic device 1000, and / or any device that enables electronic device 1000 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 1050. Furthermore, electronic device 1000 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1060. As shown, network adapter 1060 communicates with other modules of electronic device 1000 via bus 1030. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 1000, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0143] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0144] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, having stored thereon a program product capable of implementing the methods described above. In some possible implementations, various aspects of this disclosure may also be implemented as a program product including program code that, when run on an electronic device, causes the electronic device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0145] The program product for implementing the above-described method according to embodiments of the present disclosure may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on an electronic device, such as a personal computer. However, the program product of the present disclosure is not limited thereto. In this document, the readable storage medium may be any tangible medium that includes or stores a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0146] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0147] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0148] The program code included on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0149] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0150] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0151] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0152] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0153] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. A data access authentication method, characterized in that, Applied to the data request end, including: Construct a DOIP identifier resolution request based on the Digital Object Interface Protocol, wherein the DOIP identifier resolution request carries business requirement parameters, physical location compliance verification parameters, and security verification parameters; Send the DOIP identifier resolution request to the resolution server, wherein the resolution server to which the DOIP identifier resolution request is sent is determined by the operator network based on anycast routing addressing; The system receives a DOIP response from the parsing server. The DOIP response carries a Physical Proximity Proof Token (PPP-Token). The PPP-Token is generated by the parsing server after verifying the physical location compliance verification parameters and the security verification parameters. The PPP-Token is used by the data provider for data access authentication. The PPP-Token carries digital object metadata corresponding to the business requirement parameters. Send a data access request carrying the PPP-Token to the data provider; The data provider receives target data that matches the metadata of the digital object after authenticating the PPP-Token using the data provider.

2. The data access authentication method according to claim 1, characterized in that, The business requirement parameters include the target digital object identifier and / or the business identifier; The physical location compliance verification parameters include the domain declaration parameters of the data requesting end for the compliant access area and / or policy domain, as well as the verification method declaration parameters; The security verification parameters include a one-time random number for anti-replay association, and a digital signature and / or integrity verification value for the target digital object identifier and / or the service identifier, the domain declaration parameter, the one-time random number, and the verification method declaration parameter.

3. The data access authentication method according to claim 1, characterized in that, Before receiving the DOIP response information from the parsing server, the process also includes: The server receives a challenge message sent by the parsing server. The physical location compliance verification includes any-broadcast proximity evidence verification and terminal trust proof verification. If the result of the any-broadcast proximity evidence verification is questionable, the parsing server sends the challenge message. In response to the challenge message, the following steps are performed in the trusted execution environment: extract the one-time random number and network observation digest carried in the challenge message; encrypt and sign the one-time random number and the network observation digest to obtain a digital signature; add the terminal network observation data of the local machine to the digital signature to obtain a trusted terminal certificate. The terminal's trusted certificate is sent to the parsing server, so that the parsing server generates the PPP-Token after verifying the digital signature of the terminal's trusted certificate and determining that the network access observation data collected by the parsing server is consistent with the terminal's network observation data.

4. The data access authentication method according to claim 1, characterized in that, Constructing a DOIP identifier resolution request based on the Digital Object Interface Protocol includes: Configure the Location Semantic Extension (LSE) segment in the request header or message extension field area of ​​the original identifier resolution request message; The business requirement parameters, physical location compliance verification parameters, and security verification parameters are filled into the Location Semantic Extension (LSE) segment to obtain the identifier resolution request.

5. A data access authentication method, characterized in that, Applied to the parsing server, including: The system receives a DOIP identifier resolution request sent by the data requesting end. The DOIP identifier resolution request carries business requirement parameters, physical location compliance verification parameters, and security verification parameters. The identity security verification of the data requesting client is performed based on the security verification parameters. If the identity security verification passes, the physical location compliance verification of the data requesting end is performed based on the physical location compliance verification parameters; If the physical location compliance verification passes, a PPP-Token is generated. The PPP-Token is used for data access authentication by the data provider. The PPP-Token carries the metadata of the digital object corresponding to the business requirement parameters. The DOIP response information carrying the PPP-Token is sent to the data requesting end.

6. The data access authentication method according to claim 5, characterized in that, The security verification parameters include a digital signature and / or integrity verification value, and a one-time random number. Based on these security verification parameters, the identity security verification of the data requesting client includes: Invoke the pre-stored client certificate of the data requesting end; Based on the public key in the client certificate, the digital signature and / or the integrity check value are decrypted to obtain the original digest. The business requirement parameters, physical location compliance verification parameters, and security verification parameters are hashed to obtain a verification digest. Check whether the verification digest is consistent with the original digest; If the verification digest matches the original digest, the identity security verification is deemed successful. If the comparison is inconsistent, the DOIP identifier resolution request will be rejected.

7. The data access authentication method according to claim 5, characterized in that, The physical location compliance verification parameters include the domain declaration parameters of the data requesting end for the compliant access area and / or policy domain, and the verification method declaration parameters. The physical location compliance verification includes anycast proximity evidence verification. The physical location compliance verification performed by the data requesting end based on the physical location compliance verification parameters includes: Based on the BGP topology anycast routing addressing mechanism of the Carrier Border Gateway Protocol, network-side access observation data is collected. Based on the network-side access observation data, the domain declaration parameters, and the verification method declaration parameters, perform policy domain consistency verification and baseline deviation verification; If both the policy domain consistency check and the baseline deviation check pass, the physical location compliance check is deemed to have passed. If both the policy domain consistency check and the baseline deviation check fail, the physical location compliance check is determined to have failed. If either the policy domain consistency check or the baseline deviation check passes, the proximity evidence is deemed questionable.

8. The data access authentication method according to claim 7, characterized in that, The access observation data includes the node ID of the parsing server, routing domain information, round-trip delay vectors between multiple observation points in the anycast identifier parsing node cluster to which the parsing server belongs and the data requesting end, and the transmission path characteristics of the DOIP identifier parsing request. Based on the network-side access observation data, the domain declaration parameters, and the verification method declaration parameters, policy domain consistency verification and baseline deviation verification are performed, including: Based on the verification method declaration parameters, the policy domain consistency verification is performed between the compliant access area and / or policy domain and the routing domain information; During the registration and account opening phase, the data request client invokes the network baseline record bound to the business requirement parameters. The network baseline record includes the network characteristics that the data request client is resident in and that are valid. The node ID, the round-trip delay vector, and the transmission path feature are compared with the network baseline record to perform the baseline deviation check.

9. The data access authentication method according to claim 7, characterized in that, The physical location compliance verification also includes terminal trusted proof verification. Based on the physical location compliance verification parameters, the physical location compliance verification of the data requesting end is performed, and further includes: If the proximity evidence is questionable, a challenge message is generated, which carries a one-time random number and a network observation summary; Send the challenge message to the data request terminal; The receiving end generates a trusted terminal proof in a trusted execution environment based on the challenge message; After the terminal's trusted certificate is verified and signed, if the terminal network observation data in the terminal's trusted certificate is found to be consistent with the network-side access observation data, the physical location compliance verification is deemed to have passed.

10. The data access authentication method according to claim 5, characterized in that, The PPP-Token includes a token identifier, digital object metadata corresponding to the business requirement parameters, a data request terminal area obtained after passing the policy domain consistency verification, the verification method used for this physical location compliance verification, the access restriction rules of the PPP-Token, and the corresponding digital signature.

11. The data access authentication method according to claim 7, characterized in that, Before performing identity security verification on the data requesting end based on the security verification parameters, the method further includes: Send a handshake message and / or a data read request to the data provider; The system receives the verification method corresponding to the verification method declaration parameters and the digital object metadata corresponding to the business requirement parameters from the data provider.

12. A data access authentication method, characterized in that, Applied to the data provider, including: Receive a data access request sent by the data requesting end, which carries a PPP-Token, wherein the PPP-Token carries digital object metadata; The PPP-Token is authenticated by signing, validating, and binding constraints. Once the signature, validity period, and binding constraints are authenticated, target data matching the metadata of the digital object is sent to the data requesting end.

13. The data access authentication method according to claim 12, characterized in that, The PPP-Token is authenticated by signing, validating, and binding constraints, including: Obtain a verification public key from a pre-installed certificate, public key infrastructure, or digital object agent to verify the validity of the digital signature of the PPP-Token; Read the exp expiration time in the bind field of the PPP-Token to detect whether the PPP-Token has exceeded its validity period; Extract the constraint parameters from the bind field and compare them with the session matching parameters carried in the data access request to perform binding constraint authentication.

14. The data access authentication method according to claim 12, characterized in that, Before receiving the data access request carrying the PPP-Token sent by the data requesting end, it also includes: Receive and parse handshake messages and / or data read requests sent by the server, wherein the handshake messages and / or data read requests carry verification method declaration parameters and business requirement parameters; The server sends back the verification method corresponding to the verification method declaration parameters and the digital object metadata corresponding to the business requirement parameters. The verification method and the digital object metadata are used to generate the PPP-Token.

15. A data access authentication device, characterized in that, Applied to the data request end, including: The construction module is used to construct a DOIP identifier resolution request based on the Digital Object Interface Protocol. The DOIP identifier resolution request carries business requirement parameters, physical location compliance verification parameters, and security verification parameters. The first sending module is used to send the DOIP identifier resolution request to the resolution server, wherein the resolution server to which the DOIP identifier resolution request is sent is determined by the operator network based on anycast routing addressing. The first receiving module is used to receive DOIP response information fed back by the parsing server. The DOIP response information carries a Physical Proximity Proof Token (PPP-Token). The PPP-Token is generated by the parsing server after the physical location compliance verification parameter and the security verification parameter have been verified. The PPP-Token is used for data access authentication by the data provider. The PPP-Token carries digital object metadata corresponding to the business requirement parameters. The second sending module is used to send a data access request carrying the PPP-Token to the data provider; The second receiving module is used to receive target data that matches the metadata of the digital object, sent by the data provider after PPP-Token authentication.

16. A data access authentication device, characterized in that, Applied to the parsing server, including: The third receiving module is used to receive the DOIP identifier resolution request sent by the data requesting end. The DOIP identifier resolution request carries business requirement parameters, physical location compliance verification parameters, and security verification parameters. The first verification module is used to perform identity security verification on the data requesting end based on the security verification parameters. The second verification module is used to perform physical location compliance verification on the data request end based on the physical location compliance verification parameters if the identity security verification passes. The generation module is used to generate a PPP-Token if the physical location compliance verification passes. The PPP-Token is used for data access authentication by the data provider. The PPP-Token carries digital object metadata corresponding to the business requirement parameters. The third sending module is used to send the DOIP response information carrying the PPP-Token to the data requesting end.

17. A data access authentication device, characterized in that, Applied to the data provider, including: The fourth receiving module is used to receive a data access request carrying a PPP-Token sent by the data requesting end, wherein the PPP-Token carries digital object metadata; The authentication module is used to authenticate the PPP-Token by signing, valid period, and binding constraints. The fourth sending module is used to authenticate the signature, validity period, and binding constraints, and then send target data that matches the metadata of the digital object to the data requesting end.

18. A network device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the data access authentication method according to any one of claims 1 to 4, or any one of claims 5 to 11, or any one of claims 12 to 14 by executing the executable instructions.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the data access authentication method according to any one of claims 1 to 4, or any one of claims 5 to 11, or any one of claims 12 to 14.

20. A computer program product having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the data access authentication method according to any one of claims 1 to 4, or any one of claims 5 to 11, or any one of claims 12 to 14.

Images