Method and device for protecting inter-domain routing security audit based on rpki cryptographic object

Abstract

The application discloses an inter-domain routing security audit protection method and equipment based on an RPKI encryption object, which adds a new encryption object Forwarding Commitment (FC) in the RPKI, synchronizes the encryption object with the RPKI repository, performs security audit on routing table entries of inter-domain routers, removes problematic routing table entries, realizes prefix hijacking protection of autonomous inter-domain routing and protection of an AS_PATH path attribute in a BGP-UPDATE message, and partially solves a routing leakage attack. Through the application, security audit can be performed on routing table entries of inter-domain routers, and prefix hijacking, path tampering and routing leakage attacks in BGP routing are solved.

Description

Technical Field

[0001] This application relates to the field of computer network information security technology, and in particular to a method, apparatus, electronic device and storage medium for inter-domain routing security audit protection based on RPKI encrypted objects. Background Technology

[0002] BGP, short for Border Gateway Protocol, is a dynamic routing protocol used between Autonomous Systems (AS) in the current Internet. It is used to automatically exchange IP routing information and reachability information between different ASs. Its main function is to control route propagation between domains and select the optimal route.

[0003] While the BGP protocol plays a crucial role in the Internet, its security is not always guaranteed. Generally, BGP-related problems can be divided into two categories: route leakage and route hijacking. Route leakage occurs when one or more route advertisements propagate beyond their intended scope. This happens when a BGP route learned from one AS (Autonomous System) is advertised to another AS, violating the predefined policies of the receiver, sender, and / or an AS along the path of the preceding AS. Route hijacking typically involves unauthorized route advertisements. Route hijacking can be further divided into route prefix hijacking and route path tampering. The causes of route leakage or route hijacking may include unintentional administrator misconfiguration or malicious network attacks. The consequences of these routing problems can include path loops, route redirection, or denial-of-service attacks.

[0004] BGPSec is used to solve the security problems of BGP, but BGPSec requires all routers of all routing entities on the path to sign and verify the prefix in order to ensure the correctness and integrity of the path. Therefore, its incremental deployment is difficult and it places an excessive computational burden on the routers. Summary of the Invention

[0005] This application aims to at least partially address one of the technical problems in the related art.

[0006] Therefore, the first objective of this application is to propose a method for inter-domain routing security audit protection based on RPKI encrypted objects, which aims to perform security audits on routing table entries of inter-domain routers and solve attacks such as prefix hijacking, path tampering, and route leakage in BGP routing.

[0007] The second objective of this application is to propose an inter-domain routing security audit protection device based on RPKI encrypted objects.

[0008] The third objective of this application is to propose an electronic device.

[0009] The fourth objective of this application is to provide a computer-readable storage medium.

[0010] To achieve the above objectives, the first aspect of this application proposes a method for inter-domain routing security audit protection based on RPKI encrypted objects, comprising:

[0011] When the first routing entity makes a route announcement, it generates the first encrypted object through the router request of the first routing entity and stores it in the RPKI repository;

[0012] After the router of the first routing entity sends the routing advertisement, the routing entities on the routing path receive the routing advertisements in the order of receipt.

[0013] After receiving the route advertisement, the router of the current priority routing entity obtains the encrypted objects generated by all routing entities before the current priority for verification, in order to verify whether the received route advertisement message is authorized.

[0014] After successful verification, the router of the current priority routing entity generates an encrypted object corresponding to the current priority routing entity and stores it in the RPKI repository, which is used to authorize subsequent priority routing entities on the routing path to forward the route advertisement;

[0015] According to the receiving order of the routing entities on the routing path, the routing announcements are transmitted in sequence until the last routing entity receives the encrypted objects generated by all the routing entities in the previous order and verifies the routing announcements.

[0016] The first encrypted object indicates that the first routing entity authorizes the routing entity on the preset routing path to announce routing declaration information; the encrypted object corresponding to the current priority routing entity indicates that the current priority routing entity authorizes the routing entity on the preset routing path to announce routing declaration information; the message type contained in the routing declaration message corresponds to the certificate of the encrypted object, and the number of encrypted objects generated by the routing entity is equal to the number of message types contained in the routing declaration message.

[0017] In this process, the router of the current priority routing entity, after receiving the route advertisement, obtains the encrypted object generated by the previous priority routing entity to verify whether the route advertisement message is authorized. If the authorization fails, the route advertisement message is discarded.

[0018] In this process, the router of each hop in the routing entity on the path verifies the existing encrypted object and generates a new encrypted object according to the direction of the route advertisement, so as to avoid route path tampering and hijacking attacks.

[0019] The route announcement message is a BGP-UPDATE message, which contains the route address prefix of each route entity on the preset route path.

[0020] In this process, the preceding routing entity on the preset routing path announces its own routing address prefix to the following routing entity through route announcement.

[0021] In this process, the router of the next-order routing entity retrieves the encrypted objects stored by all the preceding routing entities from the RPKI repository, verifies the certificate signature information of each encrypted object, and if the verification is successful, it means that the route advertisement has not been hijacked and can continue to be received and advertised; otherwise, it means that there is a problem with the route advertisement and the message needs to be discarded.

[0022] To achieve the above objectives, a second aspect of this application provides an inter-domain routing security audit protection device based on RPKI encrypted objects, comprising:

[0023] The first encrypted object signing module is used to generate a first encrypted object through the router request of the first routing entity when the first routing entity makes a route announcement, and store it in the RPKI repository;

[0024] The receiving module is used to receive the route announcements in the order of reception by the routing entities along the route path after the router of the first routing entity sends the route announcement;

[0025] The verification module is used by the router of the current priority routing entity to obtain the encrypted objects generated by all routing entities before the current priority after receiving the route advertisement, so as to verify whether the received route advertisement message information is authorized.

[0026] The authorization module is used to generate an encrypted object corresponding to the current-order routing entity and store it in the RPKI repository after successful verification. This object is then used to authorize subsequent routing entities on the routing path to forward the route advertisement.

[0027] The loop module is used to transmit route announcements sequentially according to the receiving order of the route entities on the route path, until the last route entity receives the encrypted objects generated by all the route entities in the previous order and verifies the route announcement.

[0028] To achieve the above objectives, a third aspect of this application provides an electronic device, including: a processor and a memory communicatively connected to the processor;

[0029] The memory stores the instructions that the computer executes;

[0030] The processor executes computer execution instructions stored in memory to implement the method described above.

[0031] To achieve the above objectives, a fourth aspect of this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described above.

[0032] Unlike existing technologies, this invention provides a method, apparatus, electronic device, and storage medium for inter-domain routing security auditing and protection based on RPKI encrypted objects. This method adds a new encrypted object, ForwardingCommitment (FC), to RPKI. This encrypted object is synchronized with the RPKI repository to perform security auditing on routing table entries of inter-domain routers, eliminating problematic routing table entries. This achieves protection against prefix hijacking of inter-autonomous zone routes and protection of the AS_PATH path attribute in BGP-UPDATE messages, and partially solves route leakage attacks. Through this invention, security auditing of routing table entries of inter-domain routers can be performed, resolving prefix hijacking, path tampering, and route leakage attacks in BGP routes.

[0033] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating a method for inter-domain routing security audit protection based on RPKI encrypted objects provided by the present invention.

[0035] Figure 2 This is a schematic diagram of the RPKI architecture in the inter-domain routing security audit protection method based on RPKI encrypted objects provided by the present invention.

[0036] Figure 3 This is a schematic diagram of BGP route prefix hijacking in an inter-domain routing security audit protection method based on RPKI encrypted objects provided by the present invention.

[0037] Figure 4 This is a schematic diagram of BGP route path tampering in an inter-domain route security audit protection method based on RPKI encrypted objects provided by the present invention.

[0038] Figure 5 This is a schematic diagram of a BGP route leakage attack in an inter-domain route security audit protection method based on RPKI encrypted objects provided by the present invention.

[0039] Figure 6 This is a schematic diagram of the eContent content of the BM encrypted object in the inter-domain routing security audit protection method based on RPKI encrypted objects provided by the present invention.

[0040] Figure 7 This is a schematic diagram of the route update announcement process of a single BGP router in an inter-domain route security audit protection method based on RPKI encrypted objects provided by the present invention.

[0041] Figure 8 This is a schematic diagram of a practical example of an inter-domain routing security audit protection method based on RPKI encrypted objects provided by the present invention.

[0042] Figure 9 This is a schematic diagram of the structure of an inter-domain routing security audit protection device based on RPKI encrypted objects provided by the present invention. Detailed Implementation

[0043] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0044] The following description, with reference to the accompanying drawings, illustrates an embodiment of an inter-domain routing security audit protection method and apparatus based on RPKI encrypted objects.

[0045] Figure 1 This is a flowchart illustrating a method for inter-domain routing security audit protection based on RPKI encrypted objects, provided in an embodiment of this application. The method includes the following steps:

[0046] S101: When the first routing entity makes a route announcement, it requests the signing of the first encryption object certificate through the router of the first routing entity, generates the first encryption object, and stores it in the RPKI repository.

[0047] The first encrypted object certificate indicates that the first routing entity authorizes the routing entity on the preset routing path to announce routing declaration information.

[0048] In embodiments of the present invention, AS represents the routing entity, RP represents the dependent party, and FC represents the ForwardingCommitment, which is an encrypted object to be newly added to RPKI.

[0049] When router R1 of the first routing entity AS1 broadcasts a BGP-UPDATE message to its neighbors, R1 generates a corresponding first encrypted object. The first encrypted object involved in this invention, and the encrypted objects generated by subsequent routing entities, are all FC encrypted objects and are placed in the RPKI repository. The certificate of the first encrypted object is self-signed by R1 and uploaded to the RPKI repository for other RPs to synchronize and download. The first encrypted object is verified by the RP to prove its correctness. Specifically, the certificate of the first encrypted object indicates that AS1 authorizes its neighbors to advertise a certain IP address prefix, how many IP address prefixes are in the BGP-UPDATE message, and the routing entity corresponding to each IP address prefix generates an encrypted object and signs a certificate accordingly. The RPKI architecture is as follows... Figure 2 As shown.

[0050] In practical applications, route prefix hijacking attacks, such as Figure 3 As shown, router R3 in AS3 received two announcements for the same route prefix. Since the route prefix announced by AS4 is longer, according to the BGP routing rules, AS4 is selected as the best route, and the hijacking is successful.

[0051] Routing path tampering attacks such as Figure 4 As shown, router R3 in AS3 received two announcements for the same route prefix. Since AS4's AS_PATH is shorter, according to the BGP routing rules, AS4 is selected as the best route, and the hijacking is successful.

[0052] Router leak attacks such as Figure 5 This is an example of route leakage. The relationships between ASs include Provider-Customer (P2C), Peer-Peer (P2P), and Sibling-Sibling (S2S). The principles to follow when configuring route declaration rules are:

[0053] Declaring to a Provider: When a Customer declares routing information to its Provider, the AS that is the Customer can output its own routes and the routes of its Customer, but cannot output routes obtained from other Providers or Peers.

[0054] Declaring to a Customer: When a Provider declares routing information to its Customer, the AS that acts as the Provider can declare its own routes and the routes of its Customer, or it can output routes obtained from other Providers or Peers.

[0055] Declare to a Peer: When exchanging routing information with a Peer, you can declare your own routes and the customer's routes, but you cannot output routes obtained from other Providers or Peers.

[0056] Routing policies between ASs need to adhere to the No-Valley criterion, which estimates the direction of routing information exchange between Provider-Customer and Peer-Peer relationships.

[0057] Rule 1: There can be at most one P2P connection in an AS path;

[0058] Rule 2: In an AS path, if there is a P2C connection, it cannot be followed by a C2P connection; it can only be a P2C or S2S connection.

[0059] Rule 3: A P2C connection cannot become a P2P connection.

[0060] Rule 4: A P2P connection cannot become a C2P connection; it can only become a P2C or S2S connection.

[0061] According to the No-Valley standard, RFC 7908 categorizes BGP route leaks as follows:

[0062] AS receives route advertisements from the provider and forwards them to other providers; (P2C is followed by C2P);

[0063] AS receives route advertisements from peers and then passes them on to other peers; (P2P is followed by P2P);

[0064] AS receives route advertisements from the provider and then passes them on to its peers; (P2C is followed by P2P);

[0065] The AS receives route advertisements from its peers and then forwards them to its provider. (P2P is followed by C2P).

[0066] RPKI stands for Resource Public Key Infrastructure. RPKI is a public key infrastructure built around the rights to use internet digital resources, including IP addresses and ASNs (Application Service Numbers). The purpose of RPKI is to make internet routing more secure. RPKI mainly consists of three parts: a public key infrastructure, cryptographic signature objects, and a distributed repository. RPKI allows holders of internet digital resources to make verifiable claims about how they use their resources. To achieve this, it uses a public key infrastructure that creates a chain of resource certificates with the same structure as the transmission of IP addresses and numbers. Currently, RPKI is used to authenticate the rightful owner of an IP address block, specifying which AS (Application Service) the IP prefix in BGP belongs to. This authentication claim, called Route Origin Authorization (ROA), contains a prefix, a maximum prefix length, and the source AS number, authorizing the source AS to declare that IP address prefix. Other network operators can then download and verify these claims from RPKI's distributed repository and make routing decisions based on them; this process is called Route Origin Validation (ROV).

[0067] BGPSec is used to solve the security problems of BGP, but BGPSec requires all AS routers on the path to sign and verify the prefix to ensure the correctness and integrity of the path. Therefore, its incremental deployment is difficult and it places an excessive computational burden on the routers.

[0068] The content of the eContent of the FC encrypted object designed by the method of this invention is as follows: Figure 6 As shown. In step S101, when the BGP router R1 of the first routing entity AS1 performs BGP-UPDATE route advertisement, it first generates an FC encrypted object for the BGP-UPDATE message, which includes a signing certificate, authorizing the next-order routing entity AS to continue to advertise the IP address prefix, and proving the origin of this IP address prefix, and puts the FC encrypted object into the RPKI repository.

[0069] S102: After the router of the first routing entity sends the routing announcement, the routing entities on the routing path receive the routing announcement in the order of receipt.

[0070] In embodiments of the present invention, the encrypted object corresponding to the current priority routing entity indicates that the current priority routing entity authorizes the routing entity on the preset routing path to announce routing declaration information.

[0071] The message types contained in the route advertisement message correspond to the certificates of the encrypted objects, and the number of encrypted objects generated by the routing entity is equal to the number of message types contained in the route advertisement message.

[0072] The router at each hop of the routing entity on the path verifies the certificate of the existing encrypted object and generates a new encrypted object according to the direction of the route advertisement to prevent route path tampering and hijacking attacks.

[0073] After router R1 in AS1 generates an encrypted object using its self-signed certificate and places it in the RPKI repository, R1 will advertise the FC encrypted object to router R2 in AS2, the first routing entity in its routing path, via a BGP-UPDATE message. This FC encrypted object is denoted as FC{1,2}. R1 then advertises the FC encrypted object to router R2 in AS2 via a BGP-UPDATE message according to its own routing policy.

[0074] S103: After receiving the route advertisement, the router of the current priority routing entity obtains the encrypted objects generated by all routing entities before the current priority for verification, so as to verify whether the received route advertisement message information is authorized.

[0075] Following the previous step, after receiving the BGP-UPDATE message, router R2 in AS2 first retrieves the FC encryption object FC{1,2} from the RPKI repository based on the BGP-UPDATE path information. Then, it uses the public key within the FC{1,2} to verify the signature information in the certificate of FC{1,2} to confirm whether the current BGP-UPDATE message is authorized. If the verification is successful, it means that the route advertisement has not been hijacked and can continue to be received and advertised; otherwise, it means that there is a problem with the route advertisement and the message needs to be discarded.

[0076] S104: After successful verification, the router of the current priority routing entity generates an encrypted object corresponding to the current priority routing entity and stores it in the RPKI repository, which is used to authorize subsequent priority routing entities on the routing path to forward the route advertisement.

[0077] If the verification is successful, R2 will sign a new FC encryption object FC{2,3} using its own private key according to its own routing policy, authorize the next-order routing entity AS3 to continue advertising the IP routing prefix, and continue to advertise BGP-UPDATE to its next-order routing entity AS3 according to step S102; otherwise, the packet will be discarded.

[0078] S105: The route announcements are transmitted sequentially according to the receiving order of the route entities on the route path, until the last route entity receives the encrypted objects generated by all the route entities in the preceding order and verifies the route announcements.

[0079] Specifically, after receiving the BGP-UPDATE message, the router R3 of the second-priority routing entity AS3 obtains the current path AS_PATH as 2,1 from the UPDATE message, retrieves the FC encryption objects FC{2,3} and FC{1,2} from the RPKI repository, and uses the public key information in them to sign and verify the FC encryption objects. If the verification is successful, it continues to sign the FC encryption object FC{3,i} and put it into the RPKI repository, and sends out the BGP-UPDATE message; otherwise, it discards the message.

[0080] It should be noted that 'i' in FC{3, i} does not refer to a specific hop AS, but rather to a next-hop route of AS3. If routes are no longer advertised from AS3, then signing certificates is no longer required. If there are not only three hop ASs, but route advertisements can transmit N+1 hops, then N corresponding FC encrypted objects should be generated.

[0081] The remaining ASs on the path continue with BGP-UPDATE announcements and FC verification according to steps S103 and S104. Once BGP routes converge, protection against BGP route hijacking and detection of route leakage can be achieved.

[0082] In embodiments of the present invention, the BGP router of each routing entity needs to advertise routes to the next routing entity. Before this, the router of the next routing entity needs to sign and authenticate the routes in BGP-UPDATE, generate a new FC encrypted object, and put it into the RPKI repository.

[0083] The processing flow of this invention on a single BGP router is as follows: Figure 7 As shown in the diagram. If the router is the router of the routing entity to which the source prefix belongs, that is, the originating routing entity of the routing prefix, then the router does not need to perform steps ①②③ in the diagram. That is, it does not need to wait to receive BGP-UPDATE message information, does not need to obtain the FC encryption object list from the RPKI repository, and does not need to verify the FC encryption object. It can directly perform steps ④⑤ in the diagram.

[0084] The following is a specific embodiment of the present invention. An example topology for BGP-UPDATE declaration used in the present invention is as follows: Figure 8 As shown, the subsequent implementation methods and explanations will refer to... Figure 8 conduct.

[0085] The FC encryption object of this invention follows the encryption object template designed in RFC 6488, wherein the eContent content of the FC encryption object is as follows: Figure 5 As shown, the field definitions are as follows:

[0086] version: This is the current FC version number, which defaults to 0;

[0087] ASID: is the AS number to which the prefix of this FC belongs;

[0088] The prefix field contains the prefix information corresponding to the FC (Fixed Address Class), which needs to specify the address family it belongs to, i.e., whether it is an IPv4 or IPv6 address prefix. Therefore, it contains three parts: IP address family identifier (1 for IPv4 address, 2 for IPv6 address), IP address, and prefix length.

[0089] FCID: A unique identifier for an FC, used to uniquely locate an FC encrypted object in RPKI. It is a hash result containing the prefix field, the current AS_PATH path information, and the next-hop AS number.

[0090] FCSIG: Signature information for the FC. It contains the SKI used to identify the public key, and the SigValue is the actual signature information.

[0091] This example simplifies the operations within a routing entity AS. While multiple BGP routers may exist within a single routing entity AS, they essentially perform the same function, requiring no additional operations, thus simplifying the process. BGP router R1 of the first routing entity AS1 is about to advertise a route to BGP router R2 of the first-priority routing entity AS2. It needs to first generate FC{1,2} and store it in the RPKI repository. Assume the route prefix advertised by R1 is 192.0.2.0 / 24, ASID is 1, FCID is HASH(192.0.2.0 / 24,{1},2), and FCSIG is filled in as needed. The public and private keys for generating the FC encryption object in this invention can use the public and private keys of the BGPSec router; for details, refer to RFC 8209, which will not be elaborated here.

[0092] This embodiment announces BGP-UPDATE message information and performs related processing according to the BGP UPDATE message update method. This invention does not modify the BGP-UPDATE message format or processing flow.

[0093] This invention requires the RP to retrieve all FC encrypted objects from the RPKI repository. This can be divided into online processing and offline processing. Online processing requires the BGP router to immediately retrieve the relevant FC encrypted objects from the RPKI repository and verify them after receiving the BGP-UPDATE message. This processing method has very high latency requirements and is difficult to implement in the current RPKI validator implementation. Offline processing, on the other hand, involves the BGP router processing the BGP-UPDATE message first, updating the routing table entries. After the RP synchronizes the relevant FC encrypted objects from the RPKI Trust Anchor repository, it then performs auditing and removes invalid routing table entries. This method has relatively low latency requirements and basically does not affect the route convergence speed of the BGP router. Regardless of the method, the BGP router is required to retrieve the route prefix (here, 192.0.2.0 / 24), the current AS_PATH information (here, {1}), and the next-hop AS number (here, 2) from the BGP-UPDATE message or the routing table entries to verify the FC encrypted object FC{1,2} and perform verification. If the verification passes, continue with the next steps; otherwise, discard the BGP-UPDATE message or the routing table entry.

[0094] The BGP router R2 of the first-priority routing entity AS2 has successfully authenticated FC{1,2} and needs to advertise the route prefix 192.0.2.0 / 24 to the BGP router R3 of the second-priority routing entity AS3 via a BGP-UPDATE message. Before this, an FC encryption object FC{2,3} needs to be generated and placed in the RPKI repository. Therefore, the route prefix is ​​192.0.2.0 / 24, the ASID is the starting route source 1 of the route prefix, the FCID is HASH(192.0.2.0 / 24,{1,2},3), and FCSIG is filled in as needed.

[0095] This invention announces BGP-UPDATE message information and performs related processing according to the BGPv4 UPDATE message update method. The BGP-UPDATE message format and processing flow remain unchanged in this invention.

[0096] The second-priority routing entity AS3, BGP router R3, received a BGP-UPDATE message from R2, where AS_PATH is {2, 1}. R3 needs to verify two FC encrypted objects, FC{1, 2} and FC{2, 3}. It obtains the list of the two FC encrypted objects through FCID. After successful retrieval, it verifies the SigValue of FCSIG. If the verification is successful, it updates the route in the BGP-UPDATE message into the routing table entry of BGP router R3. There are both online and offline processing scenarios here, which will not be elaborated further.

[0097] Figure 9 This is a schematic diagram of the structure of an inter-domain routing security audit protection device based on RPKI encrypted objects, provided in an embodiment of this application.

[0098] like Figure 9 As shown, the device 300 includes:

[0099] The first encrypted object signing module 310 is used to generate a first encrypted object through the router request of the first routing entity when the first routing entity makes a route announcement, and store it in the RPKI repository;

[0100] The receiving module 320 is configured to receive the routing announcement sequentially according to the receiving order after the router of the first routing entity sends the routing announcement;

[0101] The verification module 330 is used by the router of the current priority routing entity to obtain the encrypted objects generated by all routing entities before the current priority after receiving the route advertisement, so as to verify whether the received route advertisement message information is authorized.

[0102] The authorization module 340 is used to generate an encrypted object corresponding to the current-order routing entity and store it in the RPKI repository after the verification is successful, so as to authorize subsequent routing entities on the routing path to forward the route advertisement;

[0103] The loop module 350 is used to transmit the route announcement in sequence according to the receiving order of the route entities on the route path, until the last route entity receives the encrypted object generated by all the route entities in the previous order and verifies the route announcement.

[0104] To implement the above embodiments, this application also proposes an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0105] To implement the above embodiments, this application also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0106] To implement the above embodiments, this application also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0107] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0108] It should be noted that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. Furthermore, such collection / sharing should only be conducted after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes authorization of relevant user information before the user uses the function. In addition, any necessary steps must be taken to protect and safeguard access to such personal information data and ensure that others with access to personal information data comply with their privacy policies and procedures.

[0109] This application is intended to provide an implementation scheme for users to selectively prevent the use or access to their personal information data. Specifically, this disclosure is intended to provide hardware and / or software to prevent or block access to such personal information data. Once personal information data is no longer needed, risks can be minimized by restricting data collection and deleting data. Furthermore, where applicable, such personal information is de-identified to protect user privacy.

[0110] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0111] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0112] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0113] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0114] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0115] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes one or a combination of the steps of the method embodiments.

[0116] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0117] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for inter-domain route security audit protection based on RPKI cryptographic objects, characterized in that, include: When the first routing entity performs route advertisement, it requests the generation of a first encrypted object through the router of the first routing entity and stores it in the RPKI repository. The first encrypted object is an FC encrypted object. The eContent of the FC encrypted object includes version, ASID, prefix, FCID, FCSIG, SKI, and SigValue. The version is the version number of the current FC. The ASID is the AS number to which the prefix of the FC belongs. The prefix is ​​the prefix content corresponding to the FC, including the IP address family identifier, IP address, and prefix length. The FCID is the unique identifier of the FC, used to uniquely locate an FC encrypted object in the RPKI. The FCID is a HASH result. The HASH content is the prefix field, the current AS_PATH path information, and the next-hop AS number. The FCSIG is the signature information of the FC, including SKI and SigValue. The SKI is used to identify the public key, and the SigValue is the specific signature information. The route advertisement message is a BGP-UPDATE message. The BGP-UPDATE message contains the route address prefix of each routing entity on the preset route path. The public and private keys for generating the FC encrypted object use the public and private keys of the BGPSec router. After the router of the first routing entity sends the routing advertisement, the routing entities on the routing path receive the routing advertisement in the order of receipt. After receiving the route advertisement, the router of the current priority routing entity obtains the encrypted objects generated by all routing entities before the current priority and verifies them to verify whether the received route advertisement message information is authorized. After successful verification, the router of the current priority routing entity generates an encrypted object corresponding to the current priority routing entity and stores it in the RPKI repository, which is used to authorize subsequent priority routing entities on the routing path to forward the route advertisement; According to the receiving order of the routing entities on the routing path, the routing announcements are transmitted sequentially until the last routing entity receives the encrypted objects generated by all the routing entities in the preceding order and verifies the routing announcements. The method further includes: The BGP router first processes the BGP-UPDATE message to update the routing table entries. After the RP synchronizes the relevant FC encrypted objects from the TrustAnchor repository of RPKI, it then performs an audit to remove invalid routing table entries.

2. The method for inter-domain route security audit protection based on RPKI cryptographic object according to claim 1, characterized in that, The first encrypted object indicates that the first routing entity authorizes the routing entities on the preset routing path to announce the routing announcement information; the encrypted object corresponding to the current priority routing entity indicates that the current priority routing entity authorizes the routing entities on the preset routing path to announce the routing announcement information. The message types included in the route announcement message correspond to the certificates of the encrypted objects, and the number of encrypted objects generated by the routing entity is equal to the number of message types included in the route announcement message.

3. The method of claim 1, wherein the RPKI cryptographic object is a Route Origin Validation, ROV, object. After receiving the route advertisement, the router of the current priority routing entity obtains the encrypted object generated by the previous priority routing entity to verify whether the route advertisement message is authorized. If the authorization fails, the route advertisement message is discarded.

4. The method of claim 1, wherein the RPKI cryptographic object is a Route Origin Validation, ROV, object. The router at each hop of the routing entity on the path verifies the existing encrypted object and generates a new encrypted object according to the direction of the route advertisement to prevent route path tampering and hijacking attacks.

5. The method of claim 1, wherein the RPKI cryptographic object is a Route Origin Validation, ROV, object. The preceding routing entity on the preset routing path announces its own routing address prefix to the following routing entity through the routing announcement.

6. The inter-domain routing security audit protection method based on RPKI encrypted objects according to claim 1, characterized in that, The router of the next-order routing entity retrieves the encrypted objects stored by all the preceding routing entities from the RPKI repository, verifies the certificate signature information of each encrypted object, and if the verification is successful, it means that the route advertisement has not been hijacked and can continue to receive and advertise. Otherwise, it indicates a problem with the route advertisement, and the packet needs to be discarded.

7. An inter-domain routing security audit protection apparatus based on RPKI cryptographic objects, characterized by, The apparatus implements the method as described in claim 1, the apparatus comprising: The first encrypted object signing module is used to generate a first encrypted object through the router request of the first routing entity when the first routing entity makes a route announcement, and store it in the RPKI repository; A receiving module is configured to receive the routing announcement sequentially according to the receiving order after the router of the first routing entity sends the routing announcement; The verification module is used by the router of the current priority routing entity to obtain the encrypted objects generated by all routing entities before the current priority after receiving the route advertisement, so as to verify whether the received route advertisement message information is authorized. The authorization module is used to generate an encrypted object corresponding to the current-order routing entity and store it in the RPKI repository after successful verification, so as to authorize subsequent routing entities on the routing path to forward the route advertisement; The loop module is used to transmit the route announcement in sequence according to the receiving order of the route entities on the route path, until the last route entity receives the encrypted object generated by all the route entities in the previous order and verifies the route announcement.

8. An electronic device, comprising: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

Images