Dynamic path generation method, resource access method and device

Abstract

This application provides a dynamic path generation method, relating to the field of information security, and applicable to the fintech field. The dynamic path generation method includes: responding to a connection request initiated by a client, negotiating and generating a shared key with the client; temporarily generating the shared key during each negotiation; performing a hash operation on the shared key to obtain a hash value; truncating a predetermined number of bits from the hash value as a dynamic path identifier; concatenating the dynamic path identifier and a resource base path to obtain a dynamic path; the dynamic path pointing to a specific resource stored on the server. This application also provides a dynamic path generation apparatus, device, and program product, as well as a resource access method and apparatus.

Description

Technical Field

[0001] This application relates to the field of information security and can be used in the field of financial technology. Specifically, it relates to a dynamic path generation method, a resource access method, and an apparatus. Background Technology

[0002] Directory brute-force attacks are a common type of cyberattack. Attackers use automated tools to attempt to enumerate resource paths on a server, such as Uniform Resource Locator (URL) paths, to obtain unauthorized access to sensitive files or interfaces. To overcome the shortcomings of traditional defense methods, existing technologies have attempted to generate encrypted paths through encryption or hashing; however, such solutions rely on fixed keys on the client or server side, posing a risk of key leakage. Summary of the Invention

[0003] In view of the above problems, this application provides a dynamic path generation method, resource access method and apparatus to improve URL path security.

[0004] According to a first aspect of this application, a dynamic path generation method is provided, applied to a server, comprising: responding to a connection request initiated by a client, negotiating with the client to generate a shared key; the shared key is calculated based on a randomly generated private key in each negotiation; performing a hash operation on the shared key to obtain a hash value; truncating a set number of bits of the hash value as a dynamic path identifier; concatenating the dynamic path identifier and a resource base path to obtain a dynamic path; the dynamic path points to a specific resource stored within the server.

[0005] According to an embodiment of this application, truncating a set number of bits in a hash value as a dynamic path identifier includes: truncating a set number of bits at a fixed position in the hash value as a dynamic path identifier; or, determining the truncating position based on a shared key, and truncating a set number of bits in the hash value after the truncating position as a dynamic path identifier.

[0006] According to an embodiment of this application, in response to a connection request initiated by a client, negotiating and generating a shared key with the client includes: in response to a connection request initiated by a client, sending public parameters to the client; randomly generating a first private key, calculating a first public key based on the first private key and sending it to the client; receiving a second public key sent by the client, and calculating a shared key based on the first private key, the second public key and the public parameters.

[0007] According to an embodiment of this application, concatenating a dynamic path identifier and a resource base path includes: inserting the dynamic path identifier into a set position of the resource base path.

[0008] According to an embodiment of this application, the method further includes: recording the generation time of the dynamic path identifier; and allowing the client to access the corresponding resource of the server according to the dynamic path within a set time after the generation time.

[0009] According to an embodiment of this application, the method for determining the set time includes: calculating the difference between a first parameter and a second parameter; the first parameter is obtained based on the parameters sent by the server to the client during the negotiation process, and the second parameter is obtained based on the parameters received by the server from the client during the negotiation process; and the set time is determined based on the magnitude of the difference.

[0010] According to an embodiment of this application, the method for determining the set time includes: calculating the difference between a first parameter and a second parameter; the first parameter is obtained based on the parameters sent by the server to the client during the negotiation process, and the second parameter is obtained based on the parameters received by the server from the client during the negotiation process; comparing the difference with a preset threshold, and when the difference is greater than the preset threshold, determining the set time based on the preset threshold.

[0011] The second aspect of this application provides a dynamic path generation method applied to a client, comprising: sending a connection request to a server and negotiating with the server to generate a shared key; the shared key being calculated based on a randomly generated private key in each negotiation; performing a hash operation on the shared key to obtain a hash value; truncating a set number of bits from the hash value as a dynamic path identifier; concatenating the dynamic path identifier and the resource base path to obtain a dynamic path; the dynamic path pointing to a specific resource stored on the server.

[0012] A third aspect of this application provides a resource access method, comprising: a client obtaining a dynamic path according to the dynamic path generation method applied to the client; a server obtaining a dynamic path according to the dynamic path generation method applied to the server; and the client accessing a specific resource stored on the server through the dynamic path.

[0013] A fourth aspect of this application provides a dynamic path generation apparatus, comprising: a first negotiation module, configured to negotiate with the client to generate a shared key in response to a connection request initiated by the client; the shared key is temporarily generated in each negotiation; a first encryption module, configured to perform a hash operation on the shared key to obtain a hash value; a first calculation module, configured to truncate a set number of bits in the hash value as a dynamic path identifier; and a first dynamic path generation module, configured to concatenate the dynamic path identifier and a resource base path to obtain a dynamic path; the dynamic path points to a specific resource stored in the server.

[0014] The fifth aspect of this application provides a dynamic path generation apparatus, comprising: a second negotiation module for sending a connection request to a server and negotiating with the server to generate a shared key; the shared key is temporarily generated in each negotiation; a second encryption module for performing a hash operation on the shared key to obtain a hash value; a second calculation module for truncating a set number of bits from the hash value as a dynamic path identifier; and a second dynamic path generation module for concatenating the dynamic path identifier and a resource base path to obtain a dynamic path; the dynamic path points to a specific resource stored within the server.

[0015] A sixth aspect of this application provides a resource access apparatus, comprising: a client for obtaining a dynamic path according to the dynamic path generation method applied to the client described above; a server for obtaining a dynamic path according to the dynamic path generation method applied to the server described above; and the client for accessing a specific resource stored in the server via the dynamic path.

[0016] A seventh aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0017] The eighth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0018] The above one or more embodiments have the following beneficial effects: the server and client generate a shared key through negotiation, and dynamically generate a dynamic path identifier based on the shared key and concatenate it with the basic resource path. On the one hand, the shared key is generated based on negotiation between the server and client, overcoming the risk of leakage associated with using a single key; on the other hand, the shared key is calculated based on a randomly generated private key in each negotiation, meaning that the shared key used each time a dynamic path is generated is temporarily calculated and has a random value. Furthermore, the dynamic path identifier is obtained by further hashing and intercepting the shared key, ensuring that the generated dynamic path is unpredictable. This overcomes the risk of leakage associated with using a fixed key and the risk that the fixed path generation pattern is easily cracked through long-term observation or repeated attempts, thus improving the security of resource access. Attached Figure Description

[0019] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0020] Figure 1 This diagram illustrates an application scenario of the dynamic path generation method according to an embodiment of this application.

[0021] Figure 2 A flowchart illustrating a dynamic path generation method applied to a server according to an embodiment of this application is shown schematically.

[0022] Figure 3 This illustration schematically shows a flowchart of the process by which the server and client negotiate and generate a shared key according to an embodiment of this application.

[0023] Figure 4 This illustration schematically shows a flowchart of adding validity period management to the server according to an embodiment of this application;

[0024] Figure 5 A flowchart illustrating a dynamic path generation method applied to a client according to an embodiment of this application is shown schematically;

[0025] Figure 6 This illustration schematically shows a flowchart of the process by which a client and a server negotiate and generate a shared key according to an embodiment of this application.

[0026] Figure 7 This illustration schematically shows a flowchart of adding validity period management to a client according to an embodiment of this application;

[0027] Figure 8 The illustration shows a schematic diagram of the interaction between the client and the server according to an embodiment of this application;

[0028] Figure 9 This schematic diagram illustrates the structure of a dynamic path generation apparatus according to an embodiment of the present application;

[0029] Figure 10 This schematic diagram illustrates a structural block diagram of another dynamic path generation apparatus according to an embodiment of the present application;

[0030] Figure 11 This schematically illustrates a structural block diagram of a resource access apparatus according to an embodiment of the present application; and

[0031] Figure 12 A block diagram schematically illustrates an electronic device suitable for implementing a dynamic path generation method according to an embodiment of this application. Detailed Implementation

[0032] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0033] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0034] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0035] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0036] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0037] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this application all offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0038] The following section will first explain some of the terms used in this application.

[0039] Directory enumeration (or directory brute-force): A network attack technique that uses automated tools to guess or traverse hidden directories and file paths on a server. Attackers send a large number of requests using lists of common directory names or brute-force combinations, and determine whether sensitive files exist based on the server's responses. This attack may lead to the leakage of sensitive data (such as database backups and configuration files). Defense measures include disabling directory listing, strict access control, and using a WAF (Web Application Firewall) to block malicious requests.

[0040] Diffie-Hellman (DH) key exchange is an asymmetric encryption algorithm that allows two parties to securely negotiate and share a key over an insecure network. Its core is based on the discrete logarithm problem: each party generates a temporary public-private key pair, and after exchanging the public key, they compute the same key (e.g., (g^a)^b mod p = (g^b)^a mod p). This protocol requires authentication to prevent man-in-the-middle attacks and ensures that the parameter (e.g., a prime number p) is sufficiently large to prevent cracking.

[0041] Hash is the process of converting data of arbitrary length into a fixed-length string (hash value) using a hash function. It is irreversible and collision-resistant. The same input always produces the same output, but the original data cannot be deduced from the hash value. Hash is used in scenarios such as password storage (salted hashing), data integrity verification (e.g., file download comparison), and blockchain.

[0042] Figure 1 The diagram illustrates an application scenario of the dynamic path generation method according to an embodiment of this application.

[0043] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0044] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 and access resources on the server 105 through a specific URL path. Various communication client applications can also be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0045] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers. Furthermore, the first terminal device 101, the second terminal device 102, and the third terminal device 103 can also be business processing terminals with image acquisition capabilities at the business site.

[0046] Server 105 can be a server that provides various services, such as a backend management server that supports resources accessed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process the received resource access requests, and then return the corresponding resources to the terminal devices.

[0047] It should be noted that the dynamic path generation method applied to the server provided in this application embodiment can generally be executed by the server 105. Correspondingly, the dynamic path generation device provided in this application embodiment can generally be located in the server 105. The dynamic path generation method applied to the server provided in this application embodiment can also be executed by a server or server cluster that is different from the server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or the server 105. Correspondingly, the dynamic path generation device provided in this application embodiment can also be located in a server or server cluster that is different from the server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or the server 105.

[0048] The dynamic path generation method for clients provided in this application embodiment can generally be executed by a first terminal device 101, a second terminal device 102, and / or a third terminal device 103. Correspondingly, the dynamic path generation apparatus provided in this application embodiment can generally be located in the first terminal device 101, the second terminal device 102, and / or the third terminal device 103. The dynamic path generation method for clients provided in this application embodiment can also be executed by a server or server cluster that is different from the first terminal device 101, the second terminal device 102, and / or the third terminal device 103 and is capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or the server 105. Correspondingly, the dynamic path generation apparatus provided in this application embodiment can also be located in a server or server cluster that is different from the first terminal device 101, the second terminal device 102, and / or the third terminal device 103 and is capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or the server 105.

[0049] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0050] The following will be based on Figure 1 The described scene, through Figures 2-8 The dynamic path generation method and resource access method according to the embodiments of this application will be described in detail.

[0051] Figure 2 The flowchart illustrates a dynamic path generation method applied to a server according to an embodiment of this application.

[0052] like Figure 2 As shown, the dynamic path generation method in this embodiment includes operations S210 to S240.

[0053] In operation S210, in response to a connection request initiated by the client, a shared key is negotiated with the client to generate a shared key; wherein, the shared key is calculated based on a randomly generated private key in each negotiation.

[0054] Directory brute-force attacks are a common attack method. Attackers use automated tools to attempt to enumerate resource paths (such as URL paths) on a server to obtain sensitive files or interfaces without authorization. Traditional defense methods mainly include static path design, access control lists, or rule-based path filtering mechanisms. However, these methods have the following technical flaws and shortcomings:

[0055] (1) Static paths are easily enumerated: Traditional URL paths are usually static or predictable (such as named by time or sequence number). Attackers can discover valid paths through dictionary attacks or brute-force enumeration, thereby bypassing access control mechanisms.

[0056] (2) Access control depends on explicit rules: Existing protection technologies usually rely on predefined rules or signatures to block malicious requests, but the rule base needs to be continuously updated to deal with new attack patterns and it is difficult to cover all possible variant attacks.

[0057] (3) Lack of dynamism and timeliness: Even if randomized path generation technology is used, if the path generation logic is fixed or lacks timeliness, attackers may still be able to crack the path generation pattern through long-term observation or repeated attempts.

[0058] Furthermore, existing technologies have attempted to generate encrypted paths through encryption or hashing, but these typically rely on a single key on the client or server side, posing a risk of key leakage or replay attacks. Additionally, without an effective expiration mechanism, dynamic paths may remain valid indefinitely, further reducing system security.

[0059] Based on this, in the embodiments of this application, a key negotiation mechanism is introduced, in which the server and the client negotiate to generate a shared key, overcoming the risk of key leakage that exists in traditional encryption based on a single key of the server or the client; at the same time, the shared key is calculated based on the private keys randomly generated by the server and the client, ensuring that the shared key generated in each negotiation is random, and further, a dynamic path identifier is dynamically generated based on the shared key and concatenated with the resource base path, ensuring that the generated dynamic path has unpredictability and dynamism, fundamentally resisting directory brute-force attacks.

[0060] In the embodiments of this application, the key negotiation process is implemented based on a key exchange protocol (Diffie-Hellman, DH), which can be based on classical Diffie-Hellman or elliptic curve Diffie-Hellman methods. This application uses classical Diffie-Hellman as an example for illustration; for ease of description, it will be referred to as the DH protocol below.

[0061] Figure 3 This illustration schematically shows a flowchart of the process by which the server and client negotiate and generate a shared key according to an embodiment of this application. Figure 3 As shown, in response to a connection request initiated by the client, a shared key is negotiated and generated with the client, including operations S310 to S330.

[0062] When operating S310, in response to a connection request initiated by the client, common parameters are sent to the client.

[0063] In the embodiments of this application, the client and server exchange common parameters based on the DH protocol. These common parameters are global common parameters, including a prime number p and a generator g. The common parameters form the basis of the entire DH protocol, defining the cyclic group in which the computation occurs. They must meet strict security requirements; for example, p must be a very large strong prime or a safe prime, and g must be a generator of p. Generating these parameters is computationally intensive and time-consuming. Therefore, in practical applications, the prime number p and the generator g are usually pre-calculated and standardized, and can be pre-stored on the server. They are then sent to the client when key negotiation is required.

[0064] When operating the S320, a first private key is randomly generated, and a first public key is calculated based on the first private key and sent to the client.

[0065] In the embodiments of this application, the first private key is generated by the server. To ensure security, the first private key is randomly and temporarily generated by the server. The server calculates and generates a corresponding first public key based on the DH protocol and sends it to the client.

[0066] In the embodiments of this application, the first public key is calculated based on the first private key and public parameters. The calculation method of the first public key is as follows:

[0067] ;

[0068] Where A represents the first public key, a represents the first private key, g represents the generator, and p represents a prime number.

[0069] When operating S330, it receives the second public key sent by the client and calculates the shared key based on the first private key, the second public key, and public parameters.

[0070] The server's shared key can be obtained by operating on the first private key and the second public key. To ensure security, in the embodiments of this application, the shared key is calculated based on the operation method specified in the DH protocol, using the first private key, the second public key, and common parameters. The client and server can independently calculate the shared key based on their respective private and public keys, without needing to exchange the shared key, thus ensuring security.

[0071] The shared key K is calculated as follows:

[0072] ;

[0073] ;

[0074] Where B represents the second public key and b represents the second private key.

[0075] In the embodiments of this application, the shared key generated by the key exchange protocol is mathematically irreversible, and attackers cannot deduce subsequent paths by observing public parameters or historical URL paths, thus ensuring security.

[0076] In the embodiments of this application, the client and the server negotiate and share a key based on a key exchange protocol, and use the key to dynamically generate time-sensitive resource URL paths, thereby further effectively preventing attackers from enumerating or predicting sensitive resource paths through directory brute-force attacks.

[0077] The shared key is generated only temporarily within a single session, without the need for pre-storage or fixed distribution, thus avoiding the risk of leakage due to long-term use of fixed keys in traditional schemes. Even if the key for a single session is cracked, it will not affect the security of other sessions.

[0078] In operation S220, a hash operation is performed on the shared key to obtain a hash value.

[0079] In the embodiments of this application, the server performs a hash operation on the shared key K to obtain a hash value H, which is used for subsequent path concatenation. Combining key negotiation with hash operation, the generated shared key is hashed, and the resulting hash value is concatenated with the path to obtain an encrypted dynamic path, further ensuring path security. The hash operation can be implemented using a Secure Hash Algorithm 256-bit (SHA-256).

[0080] In operation S230, a set number of bits in the hash value is truncated as the dynamic path identifier. Considering that the dynamic path generated by the method in this application embodiment is temporary, and only requires the dynamic paths generated by the server and the client to correspond, the hash value is truncated in this application embodiment.

[0081] In embodiments of this application, truncating a predetermined number of bits at a fixed position in the hash value as a dynamic path identifier may include truncating the first predetermined number of bits of the hash value as the dynamic path identifier, such as truncating the first 16 bits of the hash value as the dynamic path identifier. For example, if the calculated shared key K is 2, performing SHA-256 hashing on K=2 yields H="d4735...", and truncating the first 16 bits as the dynamic path identifier X, i.e., X="d4735e3a265e16ee". In other embodiments, truncating a predetermined number of bits in the hash value as the dynamic path identifier may also include truncating a predetermined number of bits after a certain fixed position in the hash value as the dynamic path identifier.

[0082] In other embodiments, the interception position can be determined based on the shared key, and a set number of bits after the interception position of the hash value can be used as the dynamic path identifier. For example, if the calculated shared key K is 2, then the 8 bits after the second bit of the hash value, "735e3a26", can be intercepted as the dynamic path identifier.

[0083] In the embodiments of this application, the use of hash-truncated dynamic path identifiers further enhances randomness, making it impossible for directory brute-force attacks to obtain valid paths through dictionary enumeration or brute-force guessing.

[0084] In the embodiments of this application, the generation and verification of dynamic paths rely only on key negotiation and hash operation, without the need to maintain a complex access rule base or frequently update protection policies, thus reducing system operation and maintenance costs.

[0085] In operation S240, the dynamic path identifier and the resource base path are concatenated to obtain the dynamic path; where the dynamic path points to a specific resource stored in the server.

[0086] In the embodiments of this application, the server concatenates the dynamic path identifier X with the resource base path to generate a complete dynamic path. Path concatenation can be achieved by appending the dynamic path identifier to the end of the resource base path, or by inserting the dynamic path identifier into a predetermined position within the resource base path, to further increase the difficulty of cracking and ensure security. For example, if the resource base path is " / M / N", the dynamic path identifier can be appended to the end of the path to obtain " / M / N / X", or inserted into a predetermined position within the path, such as " / M / X / N".

[0087] In the embodiments of this application, in order to avoid the security risks caused by fixed keys or long-term validity of paths, a path expiration mechanism is further introduced to ensure that the generated dynamic path has short-term validity and fundamentally resist directory brute-force attacks. Figure 4 This illustration shows a flowchart of adding validity period management to the server according to an embodiment of this application, such as... Figure 4 As shown, the method also includes operations S410 to S420.

[0088] In operation S410, the generation time of the dynamic path identifier is recorded.

[0089] When operating S420, within a set time period after the generation time, clients are allowed to access the corresponding resources on the server based on dynamic paths.

[0090] After generating the dynamic path identifier, the server records the generation time of the dynamic path identifier and sets the corresponding validity period (i.e., the set time). Within the validity period, the client can access resources through the dynamic path; after the expiration, the server refuses access and returns an error response. At this time, the client needs to re-initiate key negotiation to obtain a new dynamic path.

[0091] In the embodiments of this application, the dynamic path is generated based on a temporarily negotiated shared key and has a strict validity period limit. After expiration, the path automatically becomes invalid, and even if an attacker intercepts a historical path, it cannot be reused, effectively resisting replay attacks and long-term observation attacks.

[0092] The validity period can be a preset time, such as 5 minutes; or it can be calculated based on parameters exchanged between the client and the server. In this case, the method for determining the set time includes: calculating the difference between the first parameter and the second parameter; wherein the first parameter is obtained from the parameters sent by the server to the client during the negotiation process, and the second parameter is obtained from the parameters received by the server from the client during the negotiation process; the set time is determined based on the magnitude of the difference.

[0093] In the embodiments of this application, the first public key sent by the server to the client can be used as the first parameter, and the second public key sent by the client to the server can be used as the second parameter. The time setting is then determined based on the difference between the first and second public keys. For example, if the first public key is 8 and the second public key is 19, then the time setting, i.e., the validity period, is set to 11 minutes. In practice, static validity periods are simpler and more convenient to implement, while dynamic validity periods can enhance security, prevent the time pattern from being observed and cracked over a long period, and provide a time reference for the process of cracking the shared key.

[0094] In some implementations, a time limit can be further designed to prevent excessively long validity periods from affecting security. In this case, the method for determining the set time includes: calculating the difference between a first parameter and a second parameter; the first parameter is obtained from the parameters sent by the server to the client during the negotiation process, and the second parameter is obtained from the parameters received by the server from the client during the negotiation process; comparing the difference with a preset threshold, and if the difference is greater than the preset threshold, determining the set time based on the preset threshold. For example, if the preset threshold is set to 5 minutes, and the difference between the first parameter and the second parameter is greater than 5, then the set time, i.e., the validity period, is 5 minutes.

[0095] Figure 5 A flowchart illustrating a dynamic path generation method applied to a client according to an embodiment of this application is shown schematically.

[0096] like Figure 5 As shown, the dynamic path generation method in this embodiment includes operations S510 to S540.

[0097] When operating the S510, a connection request is sent to the server to negotiate and generate a shared key; the shared key is calculated based on a randomly generated private key in each negotiation.

[0098] In the embodiments of this application, by introducing a key negotiation mechanism, the server and the client negotiate to generate a shared key, and based on the shared key, a dynamic path identifier is dynamically generated and concatenated with the resource base path, ensuring that the generated dynamic path has unpredictability and dynamism, fundamentally resisting directory brute-force attacks.

[0099] In the embodiments of this application, the key negotiation process is implemented based on a key exchange protocol, which can be based on classical Diffie-Hellman or elliptic curve Diffie-Hellman methods. This application's embodiments use classical Diffie-Hellman as an example for illustration.

[0100] Figure 6 This illustration schematically shows a flowchart of the process by which a client and a server negotiate and generate a shared key according to an embodiment of this application. Figure 6As shown, a connection request is sent to the server, and a shared key is generated through negotiation with the server, including operations S610 to S630.

[0101] When operating the S610, a connection request is sent to the server, and common parameters are received from the server.

[0102] In the embodiments of this application, the client and server exchange common parameters based on the DH protocol. These common parameters are global common parameters, including a prime number p and a generator g. The common parameters form the basis of the entire DH protocol, defining the cyclic group in which the computation occurs. They must meet strict security requirements; for example, p must be a very large strong prime or a safe prime, and g must be a generator of p. Generating these parameters is computationally intensive and time-consuming. Therefore, in practical applications, the prime number p and the generator g are usually pre-calculated and standardized, and can be pre-stored on the server. They are then sent to the client when key negotiation is required.

[0103] When operating the S620, a second private key is randomly generated, and a second public key is calculated based on the second private key and sent to the server.

[0104] In the embodiments of this application, the second private key is generated by the client. To ensure security, the second private key is randomly and temporarily generated by the client. A second public key corresponding to the client is calculated based on the DH protocol and sent to the server.

[0105] In the embodiments of this application, the second public key is calculated based on the second private key and public parameters. The calculation method for the second public key is as follows:

[0106] ;

[0107] Where B represents the second public key, b represents the second private key, g represents the generator, and p represents a prime number.

[0108] When operating the S630, the server sends the first public key, and the shared key is calculated based on the first public key, the second private key, and the public parameters.

[0109] The client's shared key can be obtained by operating on the second private key and the first public key. To ensure security, in the embodiments of this application, the shared key is calculated based on the operation method specified in the DH protocol, using the second private key, the first public key, and common parameters. The client and server can independently calculate the shared key based on their respective private and public keys, without the need for exchanging shared keys, thus ensuring security.

[0110] The shared key K is calculated as follows:

[0111] ;

[0112] ;

[0113] Where A represents the first public key and a represents the first private key.

[0114] In the embodiments of this application, the shared key generated by the DH key exchange protocol is mathematically irreversible, and attackers cannot deduce subsequent paths by observing public parameters or historical URL paths, thus ensuring security.

[0115] In the embodiments of this application, the client and the server negotiate and share a key based on a key exchange protocol, and use the key to dynamically generate time-sensitive resource URL paths, thereby further effectively preventing attackers from enumerating or predicting sensitive resource paths through directory brute-force attacks.

[0116] The shared key is generated only temporarily within a single session, without the need for pre-storage or fixed distribution, thus avoiding the risk of leakage due to long-term use of fixed keys in traditional schemes. Even if the key for a single session is cracked, it will not affect the security of other sessions.

[0117] When operating the S520, a hash operation is performed on the shared key to obtain a hash value.

[0118] In the embodiments of this application, the client performs a hash operation on the shared key K to obtain a hash value H, which is used for subsequent path concatenation to obtain a dynamic path that can access the server. Combining key negotiation with hash operation, the generated shared key is hashed, and the resulting hash value is concatenated with the path to obtain an encrypted dynamic path, further ensuring the security of the path.

[0119] In operation S530, the set number of bits in the hash value is extracted as the dynamic path identifier.

[0120] In embodiments of this application, truncating a predetermined number of bits from the hash value as a dynamic path identifier may include truncating the first predetermined number of bits of the hash value as the dynamic path identifier, such as truncating the first 16 bits of the hash value as the dynamic path identifier. For example, if the calculated shared key K is 2, performing SHA-256 hashing on K=2 yields H="d4735...", and truncating the first 16 bits as the dynamic path identifier X, i.e., X="d4735e3a265e16ee". In other embodiments, truncating a predetermined number of bits from the hash value as a dynamic path identifier may also include truncating a predetermined number of bits after a certain fixed position from the hash value as the dynamic path identifier.

[0121] In other embodiments, the interception position can be determined based on the shared key, and a set number of bits after the interception position can be used as the dynamic path identifier. For example, if the calculated shared key K is 2, then the 8-bit value "735e3a26" after the second bit of the hash value can be intercepted as the dynamic path identifier.

[0122] In the embodiments of this application, the use of hash-truncated dynamic path identifiers further enhances randomness, making it impossible for directory brute-force attacks to obtain valid paths through dictionary enumeration or brute-force guessing.

[0123] In the embodiments of this application, the generation and verification of dynamic paths rely only on key negotiation and hash operation, without the need to maintain a complex access rule base or frequently update protection policies, thus reducing system operation and maintenance costs.

[0124] In operation S540, the dynamic path identifier and the resource base path are concatenated to obtain the dynamic path; where the dynamic path points to a specific resource stored in the server.

[0125] In the embodiments of this application, the client concatenates the dynamic path identifier X with the resource base path to generate a complete dynamic path. The client's concatenation method is the same as the server's, thereby obtaining a dynamic path consistent with the server's, so as to access the corresponding resources within the server based on the dynamic path. Path concatenation can be achieved by appending the dynamic path identifier to the end of the resource base path, or by inserting the dynamic path identifier into a predetermined position in the resource base path, to further increase the difficulty of cracking and ensure security. For example, if the resource base path is " / M / N", the dynamic path identifier can be appended to the end of the path to obtain " / M / N / X", or inserted into a predetermined position in the path, such as " / M / X / N".

[0126] In the embodiments of this application, in order to avoid the security risks caused by fixed keys or long-term validity of paths, a path expiration mechanism is further introduced to ensure that the generated dynamic path has short-term validity and fundamentally resist directory brute-force attacks. Figure 7 The flowchart illustrating the addition of expiration date management to a client according to an embodiment of this application is shown. Figure 7 As shown, the method also includes operations S710 to S720.

[0127] When operating S710, record the generation time of the dynamic path identifier.

[0128] When operating the S720, within a set time period after the generation time, access the corresponding resources on the server according to the dynamic path.

[0129] After generating a dynamic path identifier, the client records the generation time of the dynamic path identifier and the corresponding validity period (i.e., the set time). Within the validity period, the client can access resources in the server through the dynamic path. After the validity period expires, the client needs to re-initiate key negotiation with the server to obtain a new dynamic path.

[0130] In the embodiments of this application, the dynamic path is generated based on a temporarily negotiated shared key and has a strict validity period limit. After expiration, the path automatically becomes invalid, and even if an attacker intercepts a historical path, it cannot be reused, effectively resisting replay attacks and long-term observation attacks.

[0131] The validity period can be a preset time, such as 5 minutes; or it can be calculated based on parameters exchanged between the client and the server. In this case, the method for determining the set time includes: calculating the difference between the first parameter and the second parameter; wherein the first parameter is obtained from the parameters sent by the server to the client during the negotiation process, and the second parameter is obtained from the parameters received by the server from the client during the negotiation process; the set time is determined based on the magnitude of the difference.

[0132] In the embodiments of this application, the first public key sent by the server to the client can be used as the first parameter, and the second public key sent by the client to the server can be used as the second parameter. The time setting is then determined based on the difference between the first and second public keys. For example, if the first public key is 8 and the second public key is 19, then the time setting, i.e., the validity period, is set to 11 minutes. In practice, static validity periods are simpler and more convenient to implement, while dynamic validity periods can enhance security, prevent the time pattern from being observed and cracked over a long period, and provide a time reference for the process of cracking the shared key.

[0133] In some implementations, a time limit can be further designed to prevent excessively long validity periods from affecting security. In this case, the method for determining the set time includes: calculating the difference between a first parameter and a second parameter; the first parameter is obtained from the parameters sent by the server to the client during the negotiation process, and the second parameter is obtained from the parameters received by the server from the client during the negotiation process; comparing the difference with a preset threshold, and if the difference is greater than the preset threshold, determining the set time based on the preset threshold. For example, if the preset threshold is set to 5 minutes, and the difference between the first parameter and the second parameter is greater than 5, then the set time, i.e., the validity period, is 5 minutes.

[0134] In the embodiments of this application, to illustrate the interaction process between the client and the server, a resource access method is also provided, including: the client obtaining a dynamic path according to the dynamic path generation method applied to the client; the server obtaining a dynamic path according to the dynamic path generation method applied to the server; and the client accessing a specific resource stored in the server through the dynamic path.

[0135] Figure 8 This illustration schematically depicts a flow diagram of client-server interaction according to an embodiment of this application, where the operations within the dashed boxes represent steps in which the client and server negotiate and generate a shared key. Figure 8 As shown, when a client wants to access a specific resource stored on the server, it sends a connection request to the server. The client and server then negotiate and generate a shared key used only for this connection. Subsequently, the client and server independently perform hash calculations, truncate the hash value, and concatenate the path based on the shared key to obtain the same dynamic path. The client then accesses the server based on this dynamic path. The client's access to the server based on the obtained dynamic path can be achieved by the client sending an HTTP (Hypertext Transfer Protocol) request to the server, and the server responding to the received HTTP request by matching and returning the corresponding resource. The steps for negotiating and generating the shared key between the client and server can be implemented according to the aforementioned operations S310~S330 and S610~S630, and will not be elaborated further here.

[0136] The following specific embodiment illustrates the implementation of the dynamic path generation method provided in this application.

[0137] (1) The client initiates a connection request to the server, and the server returns the common parameters of the DH protocol (e.g., p=23, g=5).

[0138] (2) The client randomly generates the first private key a=6 corresponding to this access, calculates the first public key A=5^6 mod23=8 and sends it to the server; the server randomly generates the second private key b=15, calculates the second public key B=5^15 mod 23=19 and sends it to the client.

[0139] (3) The server and client jointly calculate the shared key K = 19^6 mod 23 = 8^15 mod 23 = 2.

[0140] (4) The server performs SHA-256 hash on K=2 to get H="d4735...", and extracts the first 16 bits as Path_ID="d4735e3a265e16ee".

[0141] (5) The server generates a dynamic URL / M / d4735e3a265e16ee / N, which is valid for 5 minutes.

[0142] (6) Within 5 minutes, the client accesses the resource via the dynamic URL / M / d4735e3a265e16ee / N.

[0143] The method provided in this application has the following advantages compared with the prior art.

[0144] Unpredictability and resistance to enumeration: Shared keys generated via the Diffie-Hellman key exchange protocol are mathematically irreversible, preventing attackers from deriving subsequent paths by observing public parameters or historical URL paths. The hash-truncated dynamic path identifier further enhances randomness, making it impossible for directory brute-force attacks to obtain valid paths through dictionary enumeration or brute-force guessing.

[0145] Dynamic and Time-Limited: Dynamic URL paths are generated based on temporarily negotiated shared keys and have strict validity periods. Once expired, the path automatically becomes invalid, preventing attackers from reusing it even if they intercept historical paths, effectively resisting replay attacks and long-term observation attacks.

[0146] Key security: The shared key is generated only temporarily within a single session, without the need for pre-storage or fixed distribution, thus avoiding the risk of leakage due to long-term use of fixed keys in traditional schemes. Even if the key for a single session is cracked, it will not affect the security of other sessions.

[0147] Simplified access control logic: The generation and verification of dynamic paths rely only on key negotiation and hash calculation, eliminating the need to maintain a complex access rule base or frequently update protection policies, thus reducing system operation and maintenance costs.

[0148] Compatibility and low overhead: It is implemented on the basis of existing HTTP protocol and key exchange technology, without the need to modify the network layer protocol or introduce additional hardware support. The server only needs to add key negotiation and path generation modules to deploy.

[0149] Based on the above dynamic path generation method, this application also provides a dynamic path generation apparatus. The following will be combined with... Figure 9 and Figure 10 The device is described in detail.

[0150] Figure 9 A schematic block diagram of a dynamic path generation apparatus according to an embodiment of this application is shown.

[0151] like Figure 9 As shown, the dynamic path generation device 900 of this embodiment is applicable to the server side and includes a first negotiation module 910, a first encryption module 920, a first calculation module 930 and a first dynamic path generation module 940.

[0152] The first negotiation module 910 is used to negotiate and generate a shared key with the client in response to a connection request initiated by the client. The shared key is calculated based on a randomly generated private key during each negotiation. In one embodiment, the first negotiation module 910 can be used to perform the operation S210 described above, which will not be repeated here.

[0153] The first encryption module 920 is used to perform a hash operation on the shared key to obtain a hash value. In one embodiment, the first encryption module 920 can be used to perform the operation S220 described above, which will not be repeated here.

[0154] The first calculation module 930 is used to truncate a set number of bits in the hash value as a dynamic path identifier. In one embodiment, the first calculation module 930 can be used to perform the operation S230 described above, which will not be repeated here.

[0155] The first dynamic path generation module 940 is used to concatenate the dynamic path identifier and the resource base path to obtain a dynamic path. In one embodiment, the first dynamic path generation module 940 can be used to perform the operation S240 described above, which will not be repeated here.

[0156] According to embodiments of this application, any plurality of modules among the first negotiation module 910, the first encryption module 920, the first calculation module 930, and the first dynamic path generation module 940 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the first negotiation module 910, the first encryption module 920, the first calculation module 930, and the first dynamic path generation module 940 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in a suitable combination of any of these. Alternatively, at least one of the first negotiation module 910, the first encryption module 920, the first calculation module 930, and the first dynamic path generation module 940 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0157] According to embodiments of this application, the above-described apparatus may further include a first time setting module, used to record the generation time of the dynamic path identifier; within a set time after the generation time, the client is allowed to access the corresponding resource of the server according to the dynamic path. In one embodiment, the first time setting module may be used to execute the operations S410 to S420 described above, which will not be repeated here.

[0158] Figure 10 A schematic block diagram of another dynamic path generation apparatus according to an embodiment of this application is shown.

[0159] like Figure 10 As shown, the dynamic path generation device 1000 of this embodiment is applicable to a client and includes a second negotiation module 1010, a second encryption module 1020, a second calculation module 1030, and a second dynamic path generation module 1040.

[0160] The second negotiation module 1010 is used to negotiate and generate a shared key with the client in response to a connection request initiated by the client. The shared key is calculated based on a randomly generated private key during each negotiation. In one embodiment, the second negotiation module 1010 can be used to perform the operation S510 described above, which will not be repeated here.

[0161] The second encryption module 1020 is used to perform a hash operation on the shared key to obtain a hash value. In one embodiment, the second encryption module 1020 can be used to perform the operation S520 described above, which will not be repeated here.

[0162] The second calculation module 1030 is used to truncate a set number of bits in the hash value as a dynamic path identifier. In one embodiment, the second calculation module 1030 can be used to perform the operation S530 described above, which will not be repeated here.

[0163] The second dynamic path generation module 1040 is used to concatenate the dynamic path identifier and the resource base path to obtain a dynamic path. In one embodiment, the second dynamic path generation module 1040 can be used to perform the operation S540 described above, which will not be repeated here.

[0164] According to embodiments of this application, any plurality of modules among the second negotiation module 1010, the second encryption module 1020, the second calculation module 1030, and the second dynamic path generation module 1040 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the second negotiation module 1010, the second encryption module 1020, the second calculation module 1030, and the second dynamic path generation module 1040 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in a suitable combination of any of these. Alternatively, at least one of the second negotiation module 1010, the second encryption module 1020, the second calculation module 1030, and the second dynamic path generation module 1040 may be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0165] According to embodiments of this application, the above-described apparatus may further include a second time setting module, used to record the generation time of the dynamic path identifier; and to access the corresponding resource of the server according to the dynamic path within a set time after the generation time. In one embodiment, the second time setting module may be used to execute the operations S710 to S720 described above, which will not be repeated here.

[0166] Based on the above resource access method, this application also provides a resource access device.

[0167] Figure 11 A schematic block diagram of a resource access device according to an embodiment of this application is shown.

[0168] like Figure 11 As shown, the resource access device 1100 of this embodiment includes a server 1110 and a client 1120.

[0169] Server 1110 is used to perform the above operations S210 to S240 to obtain a dynamic path, and to access specific resources stored in the server through the obtained dynamic path.

[0170] Client 1120 is used to perform the above operations S510~S540 to obtain a dynamic path.

[0171] In the embodiments of this application, the server 1110 may include the dynamic path generation device 900 provided above, and perform operations S210 to S240 based on the dynamic path generation device 900; correspondingly, the client 1120 may also include the dynamic path generation device 1000 provided above, and perform operations S510 to S540 based on the dynamic path generation device 1000, which will not be described in detail here.

[0172] Figure 12 A block diagram schematically illustrates an electronic device suitable for implementing a dynamic path generation method according to an embodiment of this application.

[0173] like Figure 12 As shown, an electronic device 1200 according to an embodiment of this application includes a processor 1201, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1202 or a program loaded from a storage portion 1208 into a random access memory (RAM) 1203. The processor 1201 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1201 may also include onboard memory for caching purposes. The processor 1201 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0174] RAM 1203 stores various programs and data required for the operation of electronic device 1200. Processor 1201, ROM 1202, and RAM 1203 are interconnected via bus 1204. Processor 1201 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 1202 and / or RAM 1203. It should be noted that the program may also be stored in one or more memories other than ROM 1202 and RAM 1203. Processor 1201 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0175] According to embodiments of this application, the electronic device 1200 may further include an input / output (I / O) interface 1205, which is also connected to a bus 1204. The electronic device 1200 may also include one or more of the following components connected to the input / output (I / O) interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the input / output (I / O) interface 1205 as needed. A removable medium 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1210 as needed so that computer programs read from it can be installed into the storage section 1208 as needed.

[0176] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0177] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 1202 and / or RAM 1203 and / or one or more memories other than ROM 1202 and RAM 1203 described above.

[0178] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the dynamic path generation method provided in the embodiments of this application.

[0179] When the computer program is executed by the processor 1201, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0180] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 1209, and / or installed from the removable medium 1211. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0181] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1209, and / or installed from the removable medium 1211. When the computer program is executed by the processor 1201, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0182] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, 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).

[0183] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0184] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A dynamic path generation method, characterized in that, Applied to the server side, including: In response to a connection request initiated by a client, a shared key is negotiated and generated with the client; the shared key is calculated based on a randomly generated private key in each negotiation. Perform a hash operation on the shared key to obtain a hash value; A predetermined number of bits in the hash value is used as a dynamic path identifier; The dynamic path is obtained by concatenating the dynamic path identifier and the resource base path; the dynamic path points to a specific resource stored in the server.

2. The method according to claim 1, characterized in that, The step of truncating a set number of bits from the hash value as a dynamic path identifier includes: Alternatively, a predetermined number of bits at a fixed position in the hash value can be extracted as a dynamic path identifier; or, the extraction position can be determined based on the shared key, and a predetermined number of bits after the extraction position in the hash value can be extracted as a dynamic path identifier.

3. The method according to claim 1, characterized in that, The step of responding to a connection request initiated by the client and negotiating with the client to generate a shared key includes: In response to a connection request initiated by a client, send common parameters to the client; A first private key is randomly generated, and a first public key is calculated based on the first private key and sent to the client. Receive the second public key sent by the client, and calculate the shared key based on the first private key, the second public key, and the public parameters.

4. The method according to claim 1, characterized in that, The step of concatenating the dynamic path identifier and the resource base path includes: inserting the dynamic path identifier into a set position in the resource base path.

5. The method according to claim 1, characterized in that, Also includes: Record the generation time of the dynamic path identifier; Within a set time period following the generation time, the client is allowed to access the corresponding resources of the server according to the dynamic path.

6. The method according to claim 5, characterized in that, The method for determining the set time includes: Calculate the difference between the first parameter and the second parameter; the first parameter is obtained from the parameters sent by the server to the client during the negotiation process, and the second parameter is obtained from the parameters received by the server from the client during the negotiation process. The set time is determined based on the magnitude of the difference.

7. The method according to claim 5, characterized in that, The method for determining the set time includes: Calculate the difference between the first parameter and the second parameter; the first parameter is obtained from the parameters sent by the server to the client during the negotiation process, and the second parameter is obtained from the parameters received by the server from the client during the negotiation process. The difference is compared with a preset threshold. When the difference is greater than the preset threshold, the set time is determined according to the preset threshold.

8. A dynamic path generation method, characterized in that, Applied to the client side, including: A connection request is sent to the server to negotiate and generate a shared key; the shared key is calculated based on a randomly generated private key in each negotiation. Perform a hash operation on the shared key to obtain a hash value; A predetermined number of bits in the hash value is used as a dynamic path identifier; The dynamic path is obtained by concatenating the dynamic path identifier and the resource base path; the dynamic path points to a specific resource stored in the server.

9. A resource access method, characterized in that, include: The server obtains the dynamic path according to the method described in any one of claims 1 to 7; The client obtains the dynamic path according to the method described in claim 8; The client accesses specific resources stored on the server through the dynamic path.

10. A dynamic path generation device, characterized in that, include: The first negotiation module is used to negotiate and generate a shared key with the client in response to a connection request initiated by the client. The shared key is calculated based on a randomly generated private key during each negotiation. The first encryption module is used to perform a hash operation on the shared key to obtain a hash value; The first calculation module is used to extract a set number of bits from the hash value as a dynamic path identifier; The first dynamic path generation module is used to concatenate the dynamic path identifier and the resource base path to obtain a dynamic path. The dynamic path points to a specific resource stored on the server.

11. A dynamic path generation device, characterized in that, include: The second negotiation module is used to send a connection request to the server and negotiate with the server to generate a shared key; The shared key is calculated based on a randomly generated private key during each negotiation. The second encryption module is used to perform a hash operation on the shared key to obtain a hash value; The second calculation module is used to extract a set number of bits from the hash value as a dynamic path identifier; The second dynamic path generation module is used to concatenate the dynamic path identifier and the resource base path to obtain a dynamic path. The dynamic path points to a specific resource stored within the server.

12. A resource access device, characterized in that, include: The server is used to obtain a dynamic path according to the method described in any one of claims 1 to 7; A client, configured to obtain a dynamic path according to the method described in claim 8; The client is also used to access specific resources stored within the server via the dynamic path.

13. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

14. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images