Verifiable resource transmission method and device based on incremental coding
By adopting incremental encoding and hop-by-hop verification methods in the resource delivery process, the problem of difficulty in ensuring resource security and integrity during resource delivery in the prior art is solved, and the trusted transmission and protection of resources in the network is realized.
Patent Information
- Application Number
- CN202411992171.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-31
- Publication Date
- 2025-05-16
- Estimated Expiration
- 2044-12-31
AI Technical Summary
The prior art is difficult to ensure the confidentiality, integrity and availability of resources during resource delivery, especially in the forwarding and filtering process of intermediate box devices.
Using a verifiable resource delivery method based on incremental encoding, the public key mapping relationship of the communication entity is determined by pulling certificate information from the key server, and hop-by-hop verification and attaching verifiable encoding are ensured to ensure the security and integrity of the resources during the transmission process.
It realizes hop-by-hop verification and protection of resources, solves the problem of trusted transfer of resources in the network, and is compatible with the existing basic principles of resource delivery, conveniently and safely implements resource delivery and sharing by hop-by-hop.
Smart Images

Figure CN120017311A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer network information security technology, and in particular to a verifiable resource delivery method and device based on incremental encoding. Background Art
[0002] In modern cryptography, five aspects are considered to ensure information security, namely confidentiality, integrity, availability, authentication and non-repudiation of information and information systems. In the process of resource transmission and forwarding, the three most important and concerned characteristics are confidentiality, integrity and availability.
[0003] Confidentiality means that useful information is not disclosed to unauthorized user entities or used by them. Information confidentiality can be ensured through information encryption, access control, etc. Integrity means that information is not destroyed or modified during transmission, exchange, and processing. The integrity of information that cannot be tampered with can be ensured through digest algorithms. Availability refers to the property that information can be used normally when authorized user entities access it normally as required.
[0004] In the computer network architecture, a "best effort" packet forwarding mechanism is used to transmit data resource information. During the transmission process, resources face the problems of insecurity and unreliability. In the prior art, the measures adopted to solve the problems of insecurity and unreliability are generally to protect resource transmission by encrypting information or establishing a secure tunnel, such as the secure transport layer protocol SSL / TLS and the zero trust architecture.
[0005] SSL / TLS is a protocol suite built on the transport layer of the computer network architecture. SSL / TLS is used to build encrypted connections between communication entities, including but not limited to between browsers and website servers, or between computer systems and servers. Currently, applications / protocols using SSL / TLS include email, instant messaging software, IP voice, and the widely used HTTPS. SSL / TLS can ensure the confidentiality, integrity, and authenticity of information. However, the overhead of SSL / TLS for traffic encryption cannot be ignored. Zero trust architecture, also known as the zero trust security model, is used to describe a design and implementation mechanism for implementing IT systems. Its core principle is "never trust, always verify." That is to say, no one, thing, or object in the IT system will be trusted by default. Before accessing the system, any person, thing, or object needs to be authenticated; any behavior that needs to be done in the system also needs to be authenticated, even if they have been authenticated in previous behaviors. This puts more stringent requirements on the encryption, authentication, and verification capabilities of IT systems.
[0006] The two most common entities on the Internet are computer terminal devices and middlebox devices. Computer terminal devices are generally intelligent and more general, and do not require particularly high forwarding performance. They can perform encryption and decryption operations and accept their overhead. However, middlebox devices are generally more specialized for specific purposes such as forwarding filtering, so their performance in processing other than forwarding filtering is more limited. Summary of the invention
[0007] The present application aims to solve one of the technical problems in the related art at least to some extent.
[0008] To achieve the above-mentioned purpose, the first aspect of the present application proposes a verifiable resource delivery method based on incremental encoding, including:
[0009] Pull certificate information from the key server to determine the mapping relationship between each communication entity and the public key;
[0010] Determine the target communication entity and the intermediate communication entities on the communication path based on the forwarding strategies and certificate information of the respective communication entities;
[0011] Transmitting resource information on the source communication entity to an intermediate communication entity on the next path, and having the intermediate communication entity verify the incremental code contained in the resource information;
[0012] If the verification is successful, the verifiable code of the intermediate communication entity is appended to the incremental code, and the processed resource information is sent to the intermediate communication entity on the next path, and the verification process and the appending process are repeated until the target communication entity receives the resource information.
[0013] Optionally, before pulling certificate information from the key server and determining the mapping relationship between each communication entity and the public key, the following is further included:
[0014] Determine the public key, private key and certificate generated by each communication entity;
[0015] The certificate information is obtained according to the public key and certificate of each communication entity, and the certificate information of each communication entity is uploaded to the key server.
[0016] Optionally, the resource information includes entity resources and session resources.
[0017] Optionally, the verifiable code includes a verifiable code identifier, a communication entity identifier, a signature algorithm identifier, a public key identifier, a signature degree and signature content.
[0018] Optionally, the incremental code includes a version number, an incremental code length and a verifiable code list, wherein the verifiable code list is directional and flows from a source communication entity to a target communication entity on the communication path.
[0019] Optionally, when the incremental encoding is verified by a certain intermediate communication entity, the method further includes:
[0020] Verifying all verifiable codes contained in the incremental code one by one;
[0021] According to the communication entity identifier and the public key identifier in the verifiable code, determining whether the mapping relationship between the communication entity and the public key is met;
[0022] If the mapping relationship is met, the corresponding public key is used to verify the signature content in the verifiable code.
[0023] Optionally, also include:
[0024] If the mapping relationship is not met or the mapping relationship is met but the verification fails, the resource information is discarded.
[0025] Optionally, also include:
[0026] If the verification is successful, the intermediate communication entity or the target communication entity performs local processing on the received resource information, wherein the local processing step includes storing and modifying the resource information.
[0027] Optionally, when the verifiable code of a certain intermediate communication entity is appended to the incremental code, the method further includes:
[0028] Determining a signing method according to a version number in the incremental encoding;
[0029] According to the determined signature method, the signature length and signature content are filled using the signature algorithm of the intermediate communication entity to generate a verifiable code;
[0030] The verifiable code is appended to the incremental code according to the order of the communication entities on the communication path, and the incremental code length of the incremental code is adjusted.
[0031] To achieve the above-mentioned purpose, the second aspect of the present application proposes a verifiable resource transfer device based on incremental encoding, comprising:
[0032] A first determination module is used to pull certificate information from a key server and determine a mapping relationship between each communication entity and a public key;
[0033] A second determination module, configured to determine a target communication entity and an intermediate communication entity on a communication path based on respective forwarding strategies and certificate information of the communication entities;
[0034] A verification module, used to transmit the resource information on the source communication entity to the intermediate communication entity on the next path, and the intermediate communication entity verifies the incremental code contained in the resource information;
[0035] The generation and transmission module is used to append the verifiable code of the intermediate communication entity to the incremental code if the verification is successful, and send the resource information to the intermediate communication entity on the next path, repeating the verification process and the appending process until the target communication entity receives the resource information.
[0036] The technical solution provided by the embodiments of the present application brings at least the following beneficial effects:
[0037] A verifiable trusted resource delivery mechanism is provided based on incremental coding that is generated hop by hop and verified hop by hop. By appending incremental coding to resources, communication entities using this mechanism can verify resources and protect them. At the same time, it is compatible with the existing basic principles of resource delivery, so as to facilitate and securely realize resource delivery and sharing hop by hop, verify the origin of resources, protect communication paths, and solve the problem of trusted resource delivery in the network.
[0038] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0039] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:
[0040] Figure 1 It is a flowchart of a verifiable resource delivery method based on incremental encoding according to an embodiment of the present application;
[0041] Figure 2 is a forwarding flow chart of a single communication entity shown according to an embodiment of the present application;
[0042] Figure 3 is an example topology diagram including multiple communication entities according to an embodiment of the present application;
[0043] Figure 4 It is a block diagram of a verifiable resource delivery device based on incremental encoding according to an embodiment of the present application. DETAILED DESCRIPTION
[0044] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.
[0045] Figure 1 A verifiable resource delivery method based on incremental encoding according to an embodiment of the present application includes:
[0046] Step 101: Pull certificate information from a key server to determine the mapping relationship between each communication entity and the public key.
[0047] In the present application embodiment, Figure 2 As shown, each communication entity needs to obtain the certificate information of other communication entities from the key server. It can be understood that each communication entity needs to have its own identification information. According to the communication entity identification, the relevant information of the communication entity can be quickly found.
[0048] As a possible implementation manner, the key server may be a real physical server, or a peer communication entity based on DH exchange.
[0049] It is understandable that before obtaining the certificate information of other communication entities from the key server, such as Figure 2 As shown, each communication entity needs to generate its own public and private keys and certificates, and then upload the generated certificate information to the key server through a certain mechanism for storage based on its own information, so that other communication entities can query it.
[0050] The embodiments of the present application do not impose any specific restrictions on the public key cryptography system used by the communication entity.
[0051] It should be noted that the key server is only responsible for storing and querying the public key certificate information of each communication entity, and is not responsible for generating, distributing, or destroying public keys, private keys, and certificate information. Each communication entity needs to pull the public key certificate information of other communication entities from the key server on its own.
[0052] Step 102: Determine the target communication entity and the intermediate communication entity on the communication path based on the forwarding strategies and certificate information of the respective communication entities.
[0053] In the embodiment of the present application, through the forwarding strategy and certificate information of each entity, starting from the source communication entity, the target communication entity and the communication path and intermediate communication entities in the resource transmission process can be determined.
[0054] It can be understood that the communication entities in the entire communication path use a "receive-process-forward" method to transmit resources. The communication entities process resource information hop by hop with each other, but forwarding resources from the current communication entity to the next communication entity is an end-to-end process, and does not require the two communication entities to be in a directly connected state.
[0055] More specifically, the source communication entity is the origin node of the resource, which only sends the resource from this communication entity to complete the resource forwarding process; the intermediate communication entity is the forwarding node of the resource, which completes the "receiving-processing-forwarding" process of the resource; the target communication entity is the end node of the resource, which completes the "receiving-processing" process of the resource.
[0056] Step 103: Transmit the resource information on the source communication entity to the intermediate communication entity on the next path, and the intermediate communication entity verifies the incremental code included in the resource information.
[0057] In the embodiment of the present application, resource information includes physical resources and session resources, wherein physical resources include data resources, digital resources, etc., and session resources include information, messages, etc.
[0058] In addition, the incremental code included in the resource information includes a version number, an incremental code length and a verifiable code list, and the verifiable code list is directional and flows from the source communication entity to the target communication entity on the communication path.
[0059] It should be noted that the version number refers to the field for iterative version updates of incremental coding and for distinguishing different signature methods, and its value is an unsigned integer value; the incremental coding length refers to the content length in bytes of the verifiable coding list field in the incremental coding format; the verifiable coding list refers to the communication entity on the communication path, a list of verifiable codes arranged in chronological order.
[0060] As for verifiable coding, it includes information such as verifiable coding identifier, communication entity identifier, signature algorithm identifier, public key identifier, signature degree and signature content.
[0061] It should be noted that the verifiable code identifier is the identification number of the current verifiable code, which is a string of numbers that can uniquely identify the current verifiable code; the communication entity identifier is a number that can uniquely identify the communication entity to which the current verifiable code is added, and this number can be used to quickly locate the relevant information of a communication entity on the communication path; the signature algorithm identifier refers to the number of the signature algorithm used by the current verifiable code; the public key identifier is the currently widely used X.509 certificate, and the use of SKI (Subject Key Identifier) can locate the certificate holder, distinguish different certificates, and then identify the public key; the signature length refers to the length of the signature content; the signature content refers to the signature of the resource information, the communication entity and its complete path or partial path. The specific signing method depends on the version number and signature algorithm used by the incremental encoding.
[0062] After explaining the meaning of each term, the verification process of the incremental encoding in this step is explained.
[0063] It can be understood that the verification process of the intermediate communication entity in this step and other intermediate communication entities on the communication path for the incremental encoding is similar.
[0064] When an intermediate communication entity verifies the incremental code, the required incremental code is taken out from the received resources, and then all the verifiable codes contained in the incremental code are verified one by one. According to the communication entity identifier and public key identifier in the verifiable code, it is determined whether the mapping relationship between the communication entity and the public key is met. If the mapping relationship is met, the corresponding public key is used to verify the signature content in the verifiable code.
[0065] It should be noted that before using the corresponding public key to verify the signature content in the verifiable code, the resource content and the encoding information need to be sorted in the order specified by the version number field in the incremental code.
[0066] It is to be understood that the source communication entity does not need to perform the authentication process.
[0067] It is understandable that if the mapping relationship is not met or the mapping relationship is met but the verification fails, it means that there is a problem with the resource information and the resource information needs to be discarded.
[0068] Step 104, if the verification is successful, the verifiable code of the intermediate communication entity is appended to the incremental code, and the processed resource information is sent to the intermediate communication entity on the next path, and the verification process and the appending process are repeated until the target communication entity receives the resource information.
[0069] In the embodiment of the present application, if the verification is successful, the intermediate communication entity performs local processing on the received resource information, wherein the local processing step includes storing and modifying the resource information.
[0070] It is understandable that the target communication entity is the end node of the resource and completes the "receiving-processing" process of the resource. Therefore, when the target communication entity receives the resource information and the verification is successful, the received resource information can also be processed locally.
[0071] It can be understood that the process of appending the verifiable code to the incremental code for the intermediate communication entity in this step and other intermediate communication entities on the communication path is similar.
[0072] When appending the verifiable code of an intermediate communication entity to the incremental code, it is necessary to determine the signature method according to the version number in the incremental code, and then fill in the non-signature content fields in the verifiable code according to the determined signature method, and then sort the resource content and coding information, and use the signature algorithm corresponding to the private key of the communication entity to fill in the signature length and signature content to generate the verifiable code. Finally, the verifiable code is appended to the incremental code in the order of the communication entities on the communication path, and the incremental code length of the incremental code is adjusted.
[0073] It should be noted that if the version number is 0, all nodes passed through on the current complete communication path of the resource information need to be signed; if the version number is 1, the previous communication entity, the current communication entity and the next communication entity of the communication path are signed.
[0074] It can be understood that when the intermediate communication entity completes the receiving and processing process, the combined resource information and incremental encoding are sent as new resource information to the next intermediate communication entity, and the next intermediate communication entity continues to execute the "receiving-processing-forwarding" process until the final resource information is delivered to the target communication entity.
[0075] It should be noted that intermediate communication entities can perform some special processing on resource information based on their local policies, but they must not modify the resources themselves. These processing include but are not limited to, for example, not forwarding it further, or expressing a preference for a certain source or destination of a resource.
[0076] It should be noted that in some scenarios, each communication entity on the communication path may be a communication entity that does not use a verifiable trusted resource delivery mechanism for incremental coding that is generated hop by hop and verified hop by hop. The entity does not need to verify the incremental coding and add verifiable coding information.
[0077] In order to explain in more detail the incrementally encoded verifiable trusted resource delivery mechanism proposed in this application, refer to Figure 3 , a flow chart including three communication entities is given.
[0078] In this topology example, communication entity 1 is the source communication entity and the origin node of the resource. It only sends the resource from this communication entity to complete the resource "forwarding" process; communication entity 2 is the intermediate communication entity and the forwarding node of the resource. It completes the resource "receiving-processing-forwarding" process; communication entity 3 is the target communication entity and the end node of the resource. It completes the resource "receiving-processing" process.
[0079] The specific steps are as follows:
[0080] Step 1), each communication entity generates its own public key PK, private key pk and certificate C.
[0081] For communication entity 1, communication entity 2, and communication entity 3, the public keys generated by each are: PK1, PK2, PK3, private keys: pk1, pk2, pk3, and certificates: C1, C2, C3.
[0082] Step 2), each communication entity uploads the certificate information including the public key information to the key server.
[0083] For communication entity 1, communication entity 2, and communication entity 3, the information uploaded to the key server respectively is: C1 (PK1), C2 (PK2), and C3 (PK3).
[0084] Step 3), each communication entity queries and obtains the certificate information of other communication entities from the key server.
[0085] The certificate information of other communication entities obtained by communication entity 1 from the key server: C2(PK2), C3(PK3); the certificate information of other communication entities obtained by communication entity 2 from the key server: C1(PK1), C3(PK3); the certificate information of other communication entities obtained by communication entity 3 from the key server: C1(PK1), C2(PK2).
[0086] Step 4), the communication entity 1 processes the resource and adds its own verifiable code VC1 to the incremental code M into the resource.
[0087] Step 5) Communication entity 1 forwards resources to communication entity 2.
[0088] Step 6) Communication entity 2 receives resources from communication entity 1.
[0089] Step 7), communication entity 2 first takes out the incremental code M from the received resources, then takes out the verifiable code VC1 of communication entity 1 from M and verifies it. If the verification fails, the resource is discarded; if the verification passes, the resource is saved and its own verifiable code VC2 is added to the incremental code M.
[0090] Step 8) Communication entity 2 forwards resources to communication entity 3.
[0091] Step 9) Communication entity 3 receives resources from communication entity 2.
[0092] Step 10), communication entity 3 first takes out the incremental code M from the received resources, then takes out the verifiable code VC1 of communication entity 1 and the verifiable code VC2 of communication entity 2 from M, and verifies them respectively. If the verification fails, the resources are discarded; if the verification passes, the resources are saved.
[0093] The embodiments of the present application provide a verifiable trusted resource delivery mechanism based on incremental coding that is generated hop by hop and verified hop by hop. By appending incremental coding to resources, communication entities using this mechanism can verify resources and protect resources. At the same time, it is compatible with the basic principles of existing resource delivery, so as to facilitate and securely realize resource delivery and sharing hop by hop, verify the origin of resources, protect communication paths, and solve the problem of trusted delivery of resources in the network.
[0094] Figure 4 1 is a block diagram of a verifiable resource delivery device 10 based on incremental encoding according to an embodiment of the present application, including:
[0095] The first determination module 100 is used to pull certificate information from the key server and determine the mapping relationship between each communication entity and the public key;
[0096] A second determination module 200, configured to determine a target communication entity and intermediate communication entities on a communication path based on respective forwarding strategies and certificate information of the communication entities;
[0097] A verification module 300, configured to transmit resource information on a source communication entity to an intermediate communication entity on a next path, and for the intermediate communication entity to verify the incremental code contained in the resource information;
[0098] The generation and transmission module 400 is used to append the verifiable code of the intermediate communication entity to the incremental code if the verification is successful, and send the resource information to the intermediate communication entity on the next path, repeating the verification process and the appending process until the target communication entity receives the resource information.
[0099] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.
[0100] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this disclosure can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of this disclosure can be achieved, and this document is not limited here.
[0101] The above specific implementations do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.
Claims
1. A verifiable resource delivery method based on incremental encoding, characterized in that: include: Pull certificate information from the key server to determine the mapping relationship between each communication entity and the public key; Determine the target communication entity and the intermediate communication entity on the communication path based on the forwarding strategies and certificate information of the respective communication entities; Transmitting resource information on the source communication entity to an intermediate communication entity on the next path, and having the intermediate communication entity verify the incremental code contained in the resource information; If the verification is successful, the verifiable code of the intermediate communication entity is appended to the incremental code, and the processed resource information is sent to the intermediate communication entity on the next path, and the verification process and the appending process are repeated until the target communication entity receives the resource information.
2. The method according to claim 1, before pulling the certificate information from the key server and determining the mapping relationship between each communication entity and the public key, further comprises: Determine the public key, private key and certificate generated by each communication entity; The certificate information is obtained according to the public key and certificate of each communication entity, and the certificate information of each communication entity is uploaded to the key server.
3. The method according to claim 1, characterized in that The resource information includes entity resources and session resources.
4. The method according to claim 1, characterized in that The verifiable code includes a verifiable code identifier, a communication entity identifier, a signature algorithm identifier, a public key identifier, a signature level and signature content.
5. The method according to claim 1, characterized in that The incremental code includes a version number, an incremental code length and a verifiable code list, wherein the verifiable code list has directionality and flows from a source communication entity to a target communication entity on the communication path.
6. The method according to claim 1 or 4, characterized in that: When the incremental encoding is verified by an intermediate communication entity, it also includes: Verifying all verifiable codes contained in the incremental code one by one; According to the communication entity identifier and the public key identifier in the verifiable code, determining whether the mapping relationship between the communication entity and the public key is met; If the mapping relationship is met, the corresponding public key is used to verify the signature content in the verifiable code.
7. The method according to claim 6, characterized in that Also includes: If the mapping relationship is not met or the mapping relationship is met but the verification fails, the resource information is discarded.
8. The method according to claim 1, characterized in that Also includes: If the verification is successful, the intermediate communication entity or the target communication entity performs local processing on the received resource information, wherein the local processing step includes storing and modifying the resource information.
9. The method according to claim 1, 4 or 5, characterized in that: When a verifiable code of an intermediate communication entity is appended to the incremental code, the method further includes: Determining a signing method according to a version number in the incremental encoding; According to the determined signature method, the signature length and signature content are filled using the signature algorithm of the intermediate communication entity to generate a verifiable code; The verifiable code is appended to the incremental code according to the sequence of communication entities on the communication path, and the incremental code length of the incremental code is adjusted.
10. A verifiable resource delivery device based on incremental encoding, characterized in that: include: A first determination module is used to pull certificate information from a key server and determine a mapping relationship between each communication entity and a public key; A second determination module, configured to determine a target communication entity and an intermediate communication entity on a communication path based on respective forwarding strategies and certificate information of the communication entities; A verification module, used to transmit the resource information on the source communication entity to the intermediate communication entity on the next path, and the intermediate communication entity verifies the incremental code contained in the resource information; The generation and transmission module is used to append the verifiable code of the intermediate communication entity to the incremental code if the verification is successful, and send the resource information to the intermediate communication entity on the next path, repeating the verification process and the appending process until the target communication entity receives the resource information.
Citation Information
Patent Citations
Identity authentication method and system and computing device
CN109936547A
Source and path verification mechanism based on dynamic label
CN114499920A
Enendorsement declaration in verifiable credentials
CN117426072A
Protecting signaling messages in hop-by-hop network communication link
US20210243173A1