CN112242979A

CN112242979A - IP address prefix authentication method and equipment based on block chain system

Info

Publication number: CN112242979A
Application number: CN201910650739.XA
Authority: CN
Inventors: 魏鑫鹏; 杨飞; 刘冰洋; 任首首; 杨雪
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-07-18
Filing date: 2019-07-18
Publication date: 2021-01-19
Anticipated expiration: 2039-07-18
Also published as: CN112242979B

Abstract

The application relates to the field of communication and discloses an IP address prefix authentication method and equipment based on a block chain system. The authentication method of the application can comprise pre-authentication and authentication of the IP address prefixes, and the pre-authentication of the IP address prefixes can inform each client node in the blockchain system that an authentication requester can authenticate ownership of a certain IP address prefix. The authentication of the IP address prefix can be used to authenticate that the authentication requester has ownership of the IP address prefix, or when the authentication requester wants to hijack ownership of the IP address prefix, the legitimate owner of the IP address prefix intercepts the authentication of the authentication requester for ownership of the IP address prefix through the routing system.

Description

IP address prefix authentication method and equipment based on block chain system

Technical Field

The present application relates to the field of communications, and in particular, to an IP address prefix authentication method and device based on a blockchain system.

Background

Border Gateway Protocol (BGP) is a routing Protocol for autonomous routing systems, which handles multiple connections between unrelated routing domains. BGP by itself does not provide any security mechanism to secure an internet interdomain autonomous routing system, and thus routing devices in a routing system using BGP (even if they belong to different network operators) trust the network-layer reachable messages passing through the system. From a protocol security perspective, BGP is based on an implicit assumption: all routing devices in the BGP system are trusted so that it can be further inferred that all network operators in the internet are trusted.

For example, in the routing system using BGP, if a BGP routing device in the autonomous routing system a announces a network prefix p that the autonomous routing system B legitimately owns to the outside through the route announcement and the route announcement is propagated over the internet, it indicates that the autonomous routing system a has launched a prefix hijacking attack on the network prefix p of the autonomous routing system B, or that the network prefix p of the autonomous routing system B is hijacked by the autonomous routing system a.

Disclosure of Invention

The embodiment of the application provides an IP address prefix authentication method and equipment based on a blockchain system, which can provide a function of authenticating ownership of the IP address prefix for an authentication requester in the blockchain system, and provide a function of intercepting authentication for a legal owner of the IP address prefix when the authentication of the authentication requester belongs to illegal authentication.

In a first aspect, an embodiment of the present application provides a method for IP address prefix authentication based on a blockchain system, where the method includes: generating an authentication request message, wherein the authentication request message comprises an IP address prefix and public key information of an authentication requester, and the authentication request message is used for requesting the authentication requester to have ownership of the IP address prefix and requesting that an authentication result indicating that the authentication request passes be written into a block of the block chain system; an authentication request message is sent to an authentication node in the blockchain system. The authentication requester requests the authentication requester to have ownership of the IP address prefix by sending an authentication request message to an authentication node in the blockchain system. It is to be understood that the client node is mainly used for sending an authentication request message or receiving an authentication response, and the client node may be an authentication requester or not, and is not limited herein.

In a possible implementation of the first aspect, the method further includes: and sending a routing advertisement to the routing equipment, wherein the routing advertisement comprises an IP address prefix and signature information obtained by signing the IP address prefix by private key information of the authentication requester. When the ownership of the IP address prefix is authenticated, the authentication node needs to compare the IP address prefix in the route advertisement directly or indirectly sent by the client node to the routing device with the IP address prefix in the authentication request, if the IP address prefixes in the route advertisement received within a predetermined time period are all the same as the IP address prefix in the authentication request, it indicates that the route advertisement directly or indirectly sent by the client node to the routing device is continuously transmitted by the routing device, and no interception of the authentication request of the authentication requester by other people occurs, at this time, it is determined that the authentication requester has the ownership of the IP address prefix, otherwise, it indicates that someone intercepts the authentication requested by the authentication requester through the routing system, so that the routing device does not transmit all the route advertisements directly or indirectly sent by the client node, at this time, it can be determined that the authentication of the IP address prefix ownership by the authentication requester may be illegal, and the authentication requester can be considered not to have ownership of the IP address prefix.

In a possible implementation of the first aspect, the method further includes: and receiving an authentication response from the authentication node, wherein the authentication response comprises an authentication result indicating that the authentication request passes. It is to be understood that the authentication node may send the authentication response to the client node only after the authentication request passes, or may send an authentication response to the client node regardless of whether the authentication request passes, that is, when the authentication request passes, the authentication node sends an authentication response to the client node, the authentication response including an authentication result indicating that the authentication request passes, and when the authentication request fails, the authentication node sends an authentication response to the client node, the authentication response including an authentication result indicating that the authentication request fails.

In a possible implementation of the first aspect, the blockchain system is a hyper ledger (hyper folder) system, and the system includes an endorsement node and a sorting node. The sending of the authentication request message to the authentication node in the blockchain system includes: and sending the authentication request message to at least one first endorsement node in the blockchain system. The client node sends an authentication request message to a first endorsement node in the blockchain system, and aims to request the first endorsement node to endorse the authentication request according to a certain authentication rule, and returns an endorsement response comprising an endorsement response indicating that the authentication request passes.

In a possible implementation of the first aspect, the method further includes: and sending a first endorsement request to at least one first sequencing node in the blockchain system under the condition of receiving a first endorsement response from at least one first endorsement node, wherein the first endorsement response comprises an authentication result representing the passing of the authentication request, and the first endorsement request is used for requesting the consensus verification of the authentication result representing the passing of the authentication request.

In a possible implementation of the first aspect, the first endorsement response further comprises an endorsement signature of the endorsement node on the authentication result.

In a possible implementation of the first aspect, the blockchain system is a blockchain system using a Practical Byzantine Fault Tolerance (PBFT), that is, the authentication node includes a first main node and at least one first backup node; and sending the authentication request message to the authentication node in the blockchain system comprises: an authentication request message is sent to at least one of a first primary node and at least one first backup node of a blockchain system. It can be understood that the client node may send the authentication request message to the first master node, may send the authentication request message to the first backup node, or may send the authentication request message to the first master node and the first backup node at the same time. If the first main node receives the authentication request message, the authentication request message is broadcasted to each first backup node, so that the authentication request sent by the client node is authenticated after the first main node and each first backup node achieve consensus. If the first backup node receives the authentication request message, the authentication request message is forwarded to the first main node, and after the forwarded authentication request message is received by the first main node, the authentication request message is sent to each first backup node for consensus verification.

In a possible implementation of the first aspect, the method further includes: and receiving an authentication response from at least one of the first master node and the at least one first backup node, wherein the authentication response comprises an authentication result indicating that the authentication request passes.

In a possible implementation of the first aspect, the method further includes: generating a pre-authentication request message, wherein the pre-authentication request message comprises an IP address prefix and public key information of an authentication requester, and the pre-authentication request message is used for requesting that the ownership of the IP address prefix is not authenticated and requesting that a pre-authentication result indicating that the pre-authentication request passes is written into a block of the block chain system; and sending a pre-authentication request message to a pre-authentication node in the blockchain system. This step is to request the pre-authentication node of the blockchain system to pre-authenticate the IP address prefix without being authenticated, and to request the pre-authentication result that the pre-authentication request passes to be written into the block of the blockchain system, so as to broadcast to each node in the blockchain system that the authentication requester is about to authenticate the ownership of an IP address prefix. The method can quickly send the hijacking information under the condition that the authentication of the authentication requester on the IP address prefix is illegal hijacking on the IP address prefix, and if a legal owner of the IP address prefix is a certain node in a block chain system, the illegal hijacking can be known in time based on the received information, so that measures are taken to prevent the illegal hijacking.

In a possible implementation of the first aspect, the method further includes: and receiving a pre-authentication response from the pre-authentication node, wherein the pre-authentication response comprises a pre-authentication result indicating that the pre-authentication request passes. It is to be understood that the pre-authentication node may send the pre-authentication response to the client node only after the pre-authentication request passes, or may send a pre-authentication response to the client node regardless of whether the pre-authentication request passes, that is, when the pre-authentication request passes, the pre-authentication node sends a pre-authentication response including a pre-authentication result indicating that the pre-authentication request passes to the client node, and when the pre-authentication request does not pass, the pre-authentication node sends a pre-authentication response including a pre-authentication result indicating that the pre-authentication request fails to pass to the client node.

In a possible implementation of the first aspect, the blockchain system is a hyper ledger (hyper folder) system, that is, the authentication node includes at least one second endorsement node; the sending of the pre-authentication request message to the pre-authentication node in the blockchain system includes: sending a pre-authentication request message to at least one second endorsement node in the blockchain system. The client node sends a pre-authentication request message to a second endorsement node in the blockchain system, and is intended to request the second endorsement node to endorse the content requested by the pre-authentication request and return a pre-authentication response comprising a pre-authentication result indicating that the pre-authentication request passes.

In a possible implementation of the first aspect, the method further includes: and sending a consensus request to at least one second sequencing node in the blockchain system under the condition that a second endorsement response from at least one second endorsement node is received, wherein the second endorsement response comprises a pre-authentication result which represents that the pre-authentication request passes, and the consensus request is used for requesting consensus verification on the pre-authentication result which represents that the pre-authentication request passes.

In a possible implementation of the first aspect, the second endorsement response further comprises an endorsement node endorsement signature of the pre-authentication result.

In a possible implementation of the first aspect, the blockchain system is a blockchain system using a pragmatistine fault-tolerant algorithm (PBFT), and the pre-authentication node includes a second primary node and at least one second backup node; and, the sending of the pre-authentication request message to the pre-authentication node in the blockchain system comprises: sending a pre-authentication request message to at least one of a second primary node and at least one second backup node of the blockchain system. It can be understood that the client node may send the pre-authentication request message to the second master node, may send the pre-authentication request message to the second backup node, or may send the pre-authentication request message to the second master node and the second backup node at the same time. If the second main node receives the pre-authentication request message, the pre-authentication request message is broadcast to each second backup node, so that the pre-authentication is carried out on the pre-authentication request message sent by the client node after the second main node and each second backup node achieve consensus. If the second backup node receives the pre-authentication request message, the pre-authentication request message is forwarded to the second main node, and after the forwarded pre-authentication request message is received by the second main node, the pre-authentication request message is broadcasted to each second backup node.

In a possible implementation of the first aspect, the method further includes: receiving a pre-authentication response from at least one of the second primary node and the at least one second backup node, wherein the pre-authentication response includes the authentication result indicating that the authentication request passed. For example, the client node, upon receiving a pre-authentication response for at least two-thirds of the nodes in the master node and endorsement node, indicates that the pre-authentication request has passed.

In a second aspect of the present application, a method for IP address prefix authentication based on a routing device is disclosed, the method including: receiving a first routing advertisement, wherein the first routing advertisement comprises a first IP address prefix and signature information of private key information of an authentication requester for requesting authentication for ownership of the first IP address prefix to the first IP address prefix; determining whether to transmit the first route advertisement according to a route advertisement record, wherein the route advertisement record comprises an IP address prefix in the route advertisement transmitted by the routing device. The route advertisement record generated by the routing device may record only the IP address prefix in the route advertisement transmitted by the routing device, or record the whole route advertisement, which is not limited herein.

In the second aspect, the authentication node in the blockchain system needs to verify the stability of the routing advertisement sent directly or indirectly by the client node, that is, only if the routing device stably transmits the first routing advertisement for a predetermined period of time without other intercepted routing advertisements, the IP address prefix for which the authentication requester requests authentication is determined to have ownership. The routing device is arranged to not deliver the first route advertisement sent directly or indirectly by the client node when the intercepted route advertisement is received. For example, the routing device may determine whether to transmit the first route advertisement by: judging whether continuous bits identical to the bit string of the first IP address prefix exist in the bit string of the IP address prefix in the route notification record or not, and judging whether the length of the IP address prefix in the route notification record is larger than that of the first IP address prefix; and in the case of no judgment result, determining to transmit the first route advertisement. In addition, it is understood that the routing device may also determine whether to transmit a route advertisement in other manners, which is not limited herein.

In a possible implementation of the second aspect, the method further includes: and writing the related information of the transmitted first route advertisement into a route advertisement record, wherein the related information of the first route advertisement comprises a first IP address prefix and signature information.

In one possible implementation of the second aspect, the sending the first route advertisement includes: the first route advertisement is transmitted to an authentication node in the blockchain system, so that the authentication node in the blockchain system determines whether the authentication requester has ownership of the IP address prefix according to whether the first route advertisement is stably received within a predetermined time period without receiving the interception route advertisement.

In a possible implementation of the second aspect, the method further includes: receiving a second route advertisement, the second route advertisement including a second IP address prefix; judging whether the bit string of the IP address prefix in the route notification record has continuous bits which are the same as the bit string of the second IP address prefix, and judging whether the length of the IP address prefix in the route notification record is larger than that of the second IP address prefix; and transmitting the second route announcement in the case of no judgment result. In the case where the authentication supplicant maliciously authenticates the IP address prefix, the legitimate owner of the IP address prefix may prevent the routing device from transmitting the above-mentioned first routing advertisement, directly or indirectly sent by the client node, by sending a second routing advertisement to the routing device, thereby preventing the authentication supplicant from authenticating the first IP prefix.

In a possible implementation of the second aspect, the method further includes: and writing the related information of the transmitted second route advertisement into a route advertisement record, wherein the related information of the second route advertisement comprises a second IP address prefix.

In a possible implementation of the second aspect, the method further includes: and sending the route advertisement record to an authentication node in the blockchain system.

In one possible implementation of the second aspect described above, the route advertisement is a border gateway protocol route advertisement.

A third aspect of the present application discloses an IP address prefix authentication method based on a blockchain system, the method including: receiving a pre-authentication request message sent directly or indirectly by a client node, wherein the pre-authentication request message sent by the client node comprises an IP address prefix and public key information of an authentication requester, the pre-authentication request message is used for requesting that the ownership of the IP address prefix is not authenticated before authentication, and requesting that a pre-authentication result indicating that the pre-authentication request passes is written into a block of a block chain system; after receiving the pre-authentication request message, the pre-authentication node determines whether the IP address prefix is authenticated; if the pre-authentication result is determined not to be authenticated before, performing consensus verification on the pre-authentication result, and writing the pre-authentication result indicating that the pre-authentication request passes into the block of the blockchain system after the consensus verification passes and agrees with other pre-authentication nodes, wherein the pre-authentication result may include public key information of the authentication requester. The method illustrates a pre-authentication phase in which a pre-authentication node authenticates ownership of an IP prefix, in the pre-authentication phase, the pre-authentication node verifies the pre-authentication request message sent by the client node, verifies whether the IP address prefix is authenticated before, a message that the authentication requester will verify the IP address prefix is broadcast to each node in the blockchain system, without having been previously authenticated, at which point, if the authentication of the authentication requester for ownership of the IP address prefix is illegal (e.g., the authentication requester is to hijack the IP address prefix), the legitimate owner of the IP address prefix in the blockchain system is able to know the illegitimate authentication, so as to announce the interception route sent to the routing system to prevent the authentication of the IP address prefix ownership by the authentication requester, or take some offline legal means to defend the IP address prefix ownership.

In a possible implementation of the third aspect, the method further includes: a pre-authentication response is sent to the client node including a pre-authentication result indicating that the pre-authentication request has been authenticated. It is to be understood that the pre-authentication response may be sent by the pre-authentication node only after the pre-authentication request passes, or may be a pre-authentication response sent to the client node regardless of whether the pre-authentication request passes or not, that is, when the pre-authentication passes, the pre-authentication response includes a pre-authentication result that the pre-authentication request passes, and when the pre-authentication request fails, the pre-authentication response includes a pre-authentication result that the pre-authentication request fails.

The fourth aspect of the present application discloses an IP address prefix authentication method based on a blockchain system, including: receiving an authentication request message, wherein the authentication request message comprises an IP address prefix and public key information of an authentication requester, and the authentication request message is used for requesting the authentication requester to have ownership of the IP address prefix and writing an authentication result indicating that the authentication request passes into a block of the block chain system; and determining whether the authentication requester possesses the ownership of the IP address prefix according to the authentication request message and the route advertisement information received from the routing device. It is understood that the authentication request message may be sent by the client node to the authentication node, or may be transmitted to the authentication node by other authentication nodes, depending on the specific blockchain system structure, and is not limited herein.

In a possible implementation of the fourth aspect, before authenticating the authentication request message sent by the client node, the authentication node needs to determine whether the authentication requester has performed the pre-authentication request in the blockchain system, and authenticates the authentication request sent by the client node if the pre-authentication request has passed, for example, determining whether the public key information and the private key information in the signature information match according to the received public key information of the authentication requester in the block regarding the pre-authentication result of the authentication requester and the signature information in the route advertisement information received from the routing device; in the case where the public key information and the private key information in the signature information match, it is determined that the authentication requester has completed the pre-authentication.

In a possible implementation of the fourth aspect, the method further includes: under the condition that the authentication requester has ownership of the IP address prefix as a result of the authentication node, determining whether the authentication node agrees with other authentication nodes in the blockchain system with respect to the authentication result; and if the agreement is reached, writing the authentication result into the block of the blockchain system.

In a possible implementation of the fourth aspect, the route advertisement information includes at least one first route advertisement that includes an IP address prefix received from the routing device within a predetermined time period and is related to or identical to the IP address prefix in the authentication request, where the related means that the same consecutive bits exist in the bit string of the IP address prefix of the route advertisement as the bit string of the IP address prefix of the authentication request, and the length is greater than the length of the IP address prefix in the authentication request. At this time, the authentication node may compare the IP address prefix in each received routing advertisement with the IP address prefix in the authentication request, and if the IP address prefixes are the same, it means that all the routing advertisements directly or indirectly sent by the client node are transmitted by the routing device, the transmission is stable, and no routing advertisement intercepting the routing advertisement appears, so it may be determined that the authentication requester has ownership over the IP address prefix, otherwise, it is considered that the authentication requester has no ownership over the IP address prefix.

In one possible implementation of the fourth aspect, the route advertisement information includes a route advertisement record received from the routing device, the route advertisement record including an IP address prefix in the route advertisement that has been transmitted by the routing device. The determining whether the authentication requester has ownership of the IP address prefix according to the authentication request and the route advertisement information received from the routing device includes: judging whether a route advertisement exists in the route advertisement transmitted by the routing equipment in a preset time period or not according to the route advertisement record, wherein the bit string of the IP address prefix of the route advertisement has continuous bits which are the same as the bit string of the IP address prefix in the authentication request, and the length of the continuous bits is greater than the length of the IP address prefix in the authentication request; and if the judgment result is that the IP address prefix does not exist, determining that the authentication requester has ownership of the IP address prefix.

In one possible implementation of the fourth aspect, determining whether the authentication requester owns the IP address prefix comprises: judging whether the private key information of the authentication requester contained in the first routing advertisement in the routing advertisement information is matched with the public key information of the authentication requester in the authentication request; if the first IP address prefix in the first route advertisement is related to the second IP address prefix in the second route advertisement, determining whether a second route advertisement is received from the routing equipment within a preset time period; if the second route notification is not received, determining that the authentication requester has ownership of the IP address prefix; and if it is determined that the second route advertisement is received, determining that the authentication requester does not possess ownership of the IP address prefix. Wherein the correlation between the second IP address prefix in the second routing advertisement and the first IP address prefix in the first routing advertisement means: the bit string of the second IP address prefix contains the same continuous bits as the bit string of the first IP address prefix and the length of the second IP address prefix is longer than that of the first IP address prefix.

The fifth aspect of the present application discloses an IP address prefix authentication method based on a blockchain system, including: receiving an authentication request message from a client node in a blockchain system, wherein the authentication request message comprises an IP address prefix and public key information of an authentication requester, and the authentication request message is used for requesting the authentication requester to have ownership of the IP address prefix; determining whether the authentication requester has ownership of the IP address prefix according to the authentication request and the route advertisement information received from the routing device; and if the ownership is determined, performing endorsement on the authentication request, and sending a first endorsement response to the client node, wherein the first endorsement response comprises an authentication result indicating that the authentication request passes, so that the client node requests to write the authentication result indicating that the authentication request passes into a block of the blockchain system by sending a consensus request to the sorting node, and the ownership of the IP address prefix by the authentication requester is broadcasted to each node in the blockchain system.

In a possible implementation of the fifth aspect, before authenticating the authentication request message sent by the client node, the endorsement node needs to determine whether the authentication requester has performed pre-authentication in the blockchain system, and only authenticates the authentication request message sent by the client node if the pre-authentication has passed, for example, determining whether the public key information and the private key information in the signature information match according to the received public key information of the authentication requester in the block regarding the pre-authentication result of the authentication requester and the signature information in the route advertisement information received from the routing device; in the case where the public key information and the private key information in the signature information match, it is determined that the authentication requester has completed the pre-authentication.

In one possible implementation of the fifth aspect, the route advertisement information includes at least one first route advertisement received from the routing device within a predetermined time period, wherein an IP address prefix of the at least one first route advertisement is related to or the same as an IP address prefix in the authentication request. Here, the correlation means that the same continuous bits as those of the bit string of the IP address prefix of the authentication request exist in the bit string of the IP address prefix of the route advertisement, and the length is greater than that of the IP address prefix in the authentication request. At this time, the first endorsement node may compare the IP address prefix in each received first routing advertisement with the IP address prefix in the authentication request, and if the IP address prefixes in each received first routing advertisement are the same, it indicates that the first routing advertisements directly or indirectly sent by the client node are all transmitted by the routing device, the transmission is stable, and no routing advertisement with a longer IP address prefix is present to intercept the first routing advertisement, so that it may be determined that the authentication requester has ownership over the IP address prefix, otherwise, it is determined that the authentication requester has no ownership over the IP address prefix.

In one possible implementation of the fifth aspect, the route advertisement information includes a route advertisement record received from the routing device, the route advertisement record including an IP address prefix in the route advertisement that has been transmitted by the routing device. The determining whether the authentication requester has ownership of the IP address prefix according to the authentication request message and the route advertisement message received from the routing device includes: judging whether a route advertisement exists in the route advertisement transmitted by the routing equipment in a preset time period or not according to the route advertisement record, wherein the bit string of the IP address prefix of the route advertisement has continuous bits which are the same as the bit string of the IP address prefix in the authentication request, and the length of the continuous bits is greater than the length of the IP address prefix in the authentication request; and if the judgment result is that the IP address prefix does not exist, determining that the authentication requester has ownership of the IP address prefix.

In one possible implementation of the above fifth aspect, determining whether the authentication requester owns the IP address prefix further comprises: judging whether private key information of an authentication requester contained in a first route advertisement in the route advertisement information is matched with public key information of the authentication requester in the pre-authentication request; if the first IP address prefix in the first route advertisement is related to the second IP address prefix in the second route advertisement, determining whether a second route advertisement is received from the routing equipment within a preset time period; if the second route notification is not received, determining that the authentication requester has ownership of the IP address prefix; and if it is determined that the second route advertisement is received, determining that the authentication requester does not possess ownership of the IP address prefix. Wherein the correlation between the second IP address prefix in the second routing advertisement and the first IP address prefix in the first routing advertisement means: the second IP address prefix includes the first IP address prefix and the length of the second IP address prefix is greater than the length of the first IP address prefix.

In a possible implementation of the above fifth aspect, the route advertisement is a border gateway protocol route advertisement.

A sixth aspect of the present application discloses an IP address prefix authentication method based on a blockchain system, including: receiving a consensus request for a first endorsement response from a client node in the blockchain system, wherein the first endorsement response comprises an authentication result indicating that the authentication request passes; determining whether a first endorsement node that made a first endorsement response qualifies for the first endorsement response; and if the authentication result is determined to be qualified, performing consensus verification on the authentication result, and if the consensus verification is passed, writing the authentication result which indicates that the authentication request is passed into the blockchain system.

A seventh aspect of the present application discloses an authentication method for a second endorsement node of a blockchain system, including: receiving a pre-authentication request message from a client node; and verifying the pre-authentication request message to determine whether ownership of the IP address prefix is authenticated, and if not, endorsing the pre-authentication request from the client node and sending a second endorsement response to the client node, so that the client node requests to write a pre-authentication result indicating that the pre-authentication request passes into a block of the block chain system by sending a second consensus request to a second sorting node, thereby broadcasting a message to each node in the block chain system that the authentication requester will verify the IP address prefix.

In a possible implementation of the seventh aspect, the second endorsement response comprises a pre-authentication result indicating that the pre-authentication request passes and an endorsement signature performed on the pre-authentication request.

An eighth aspect of the present application discloses an IP address prefix authentication method based on a blockchain system, including: receiving a second consensus request from a client node in the blockchain system for a second endorsement response, wherein the second endorsement response comprises a pre-authentication result indicating that the pre-authentication request passes, and the pre-authentication request is used for requesting authentication that ownership of the IP address prefix is not authenticated; determining whether a second endorsement node sending a second endorsement response is qualified to make a second endorsement response to the pre-authentication request; if it is determined to qualify, the pre-authentication result is written into the blockchain system with consensus on the pre-authentication result, so that other client nodes in the blockchain system obtain information that the authentication requester will authenticate ownership of the IP address prefix.

In a possible implementation of the above eighth aspect, the second endorsement response comprises an endorsement signature after endorsement signing the pre-authentication result.

A ninth aspect of the present application discloses an IP address prefix authentication method based on a blockchain system, the method including: generating a pre-authentication request message, wherein the pre-authentication request message comprises an IP address prefix and public key information of an authentication requester, the pre-authentication request message is used for requesting that ownership of the IP address prefix is not authenticated, and requesting that a pre-authentication result indicating that the pre-authentication request passes be written into a block of the block chain system; a pre-authentication request message is sent to an authentication node in the blockchain system. The method can quickly send the hijacking information under the condition that the authentication of the authentication requester on the ownership of the IP address prefix is illegal hijacking of the IP address prefix, and if a legal owner of the IP address prefix is a certain client node in a block chain system, the illegal hijacking can be known in time based on received information, so that measures are taken to prevent the illegal hijacking.

A tenth aspect of the present application provides a client node in a blockchain system, the client node having a function of implementing a behavior of the client node in the blockchain system in the above method. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions.

An eleventh aspect of the present application provides a routing device having a function of implementing the behavior of the routing device in the above-described method. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions.

A twelfth aspect of the present application provides an authentication node in a blockchain system, where the authentication node has a function of implementing a behavior of the authentication node in the above method. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions. A thirteenth aspect of the present application discloses a computer-readable storage medium having stored therein instructions, which, when run on a computer, cause the computer to perform the method disclosed in any of the first to ninth aspects described above.

A fourteenth aspect of the present application discloses a computer program product containing instructions which, when run on a computer, cause the computer to perform the method disclosed in any of the first to ninth aspects above.

A fifteenth aspect of the present application discloses an apparatus, comprising:

a memory for storing instructions for execution by one or more processors of the device, an

A processor, being one of the processors of the device, for performing the method disclosed in any one of the first to ninth aspects.

A sixteenth aspect of the present application discloses an apparatus comprising a processor, a memory, and a communication module. The processor, the memory and the communication module communicate with each other via an internal link path to transmit control and/or data signals, so that the apparatus performs the method disclosed in any one of the first to ninth aspects.

A seventeenth aspect of the present application discloses an apparatus comprising a processor and a communication module. The processor and the communication module communicate with each other through an internal link path to transmit control and/or data signals, so that the device performs the method disclosed in any one of the first to ninth aspects.

An eighteenth aspect of the present application discloses a system comprising the client node of the above tenth aspect and the authentication node of the above twelfth aspect, and the routing device of the eleventh aspect.

Drawings

Fig. 1 is an application scenario of authenticating an IP address prefix based on a blockchain system according to an embodiment of the present disclosure.

Fig. 2 is a flowchart illustrating a method for IP address prefix authentication based on a client node in a blockchain system according to some embodiments of the present application based on the application scenario of fig. 1.

Fig. 3 is a flowchart illustrating a method for authenticating an IP address prefix based on an endorsement node in a blockchain system according to some embodiments of the present disclosure based on the application scenario of fig. 1.

Fig. 4 is a flowchart illustrating a method for IP address prefix authentication based on a sorting node in a blockchain system according to some embodiments of the present application, based on the application scenario of fig. 1.

Fig. 5 is a flowchart illustrating a method for IP address prefix authentication based on a client node in a blockchain system according to some embodiments of the present application based on the application scenario of fig. 1.

Fig. 6 is a flowchart illustrating a method for authenticating an IP address prefix of a routing device based on a routing system according to some embodiments of the present application based on the application scenario of fig. 1.

Fig. 7 is a flowchart illustrating a method for authenticating an IP address prefix based on an endorsement node in a blockchain system according to some embodiments of the present disclosure based on the application scenario of fig. 1.

Fig. 8 is a flowchart illustrating a method for IP address prefix authentication based on a sorting node in a blockchain system according to some embodiments of the present application based on the application scenario of fig. 1.

Fig. 9 is a diagram illustrating another application scenario for authentication of IP address prefixes based on a blockchain system, according to some embodiments of the present application.

Fig. 10 is a flowchart illustrating a method for IP address prefix authentication based on a client node in a blockchain system according to some embodiments of the present application based on the application scenario of fig. 9.

Fig. 11 is a flowchart illustrating a method for IP address prefix authentication based on a client node in a blockchain system according to some embodiments of the present application based on the application scenario of fig. 9.

FIG. 12 is a block diagram of an apparatus according to some embodiments of the present application.

Fig. 13 is a block diagram of a system on a chip (SoC) according to some embodiments of the present application.

Fig. 14 is a block chain system of client nodes according to some embodiments of the present application.

Fig. 15 is a schematic structural diagram of a routing device according to some embodiments of the present application.

Fig. 16 is a block chain system of client nodes according to some embodiments of the present application.

DETAILED DESCRIPTION OF EMBODIMENT (S) OF INVENTION

The illustrative embodiments of the present application include, but are not limited to, a blockchain-based IP address prefix authentication method and apparatus.

It will be appreciated that as used herein, the term module may refer to or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality, or may be part of such hardware components.

It is to be appreciated that, according to some embodiments of the present application, the method of authenticating an IP address prefix of the present application may include a pre-authentication phase and an authentication phase. The two phases can be independent of each other and used separately, i.e. only the pre-authentication phase, or only the authentication phase, or simultaneously, i.e. the authentication phase is executed after the pre-authentication phase is executed. In the pre-authentication phase, it is mainly verified whether the ownership of the IP address prefix is authenticated, and after the verification is passed, the pre-authentication result is written into the blockchain system, so as to quickly send a message to each node in the blockchain system that the authentication requester will authenticate the ownership of the IP address prefix. Therefore, when the authentication of the IP address prefix by the authentication requester is illegal hijacking of the IP address prefix, the hijacking information can be quickly sent out, if the legal owner of the IP address prefix is a certain node in the block chain system, the illegal hijacking can be timely known based on the received information, and measures are taken to prevent the illegal hijacking. The IP address prefix can be intercepted by the authentication method, and can also be intercepted by offline legal means or other offline means.

In the authentication phase, whether the authentication requester has ownership of the IP address prefix is mainly authenticated, and after the authentication is passed, the authentication result is written into the blockchain system to issue the ownership of the IP address prefix authenticated by the authentication requester to each node in the blockchain system. And under the condition that the authentication of the IP address prefix proposed by the authentication requester belongs to illegal hijacking, the legal owner of the IP address prefix can destroy the authentication by sending an interception route advertisement for intercepting the route advertisement of the authentication requester, so that the authentication requester cannot obtain the ownership of the IP address prefix.

It will be appreciated that a "communication module" in this application may include a receiver or transmitter, or may include a transceiver, for providing wireless communication functionality for a located device, such that the located device communicates with other devices (e.g., front end modules, antennas, etc.). For example, having the client node send an authentication request message, receive an authentication response, and the like

It is to be appreciated that in various embodiments of the present application, the processor may be a microprocessor, a digital signal processor, a microcontroller, or the like, and/or any combination thereof. According to another aspect, the processor may be a single-core processor, a multi-core processor, the like, and/or any combination thereof.

Embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Some embodiments according to the present application disclose an authentication scenario for authenticating ownership of an IP address prefix based on a blockchain system. The blockchain system in this scenario may be a hyper ledger (hyper leader) blockchain system or other similar blockchain system. The following description takes the Hyperhedgehog blockchain system as an example.

Fig. 1 shows a scenario diagram of this authentication scenario. As shown in fig. 1, the authentication scenario has a blockchain system 10 and a routing system 20. The blockchain system 10 includes client nodes 100-1 through 100-n, endorsement nodes 130-1 through 130-n, and sort nodes 140-1 through 140-n. Where each of the client nodes 100-1 to 100-n holds a copy of the Ledger (Ledger) and a copy of the intelligent contract (Smart contract), an application or computer administrator needs to access the copies of the Ledger (Ledger) and the intelligent contract (Smart contract) that the client nodes 100-1 to 100-n have by interacting with the client nodes 100-1 to 100-n. Where the owner of the application or computer administrator may be the authentication requestor. In conducting the authentication transaction, any of the client nodes 100-1 through 100-n may determine which of the endorsement nodes 130-1 through 130-n to send the authentication request message to based on the endorsement policy. It is to be appreciated that the client nodes 100-1 through 100-n may include, but are not limited to, servers, laptop computers, desktop computers, tablet computers, mobile phones, wearable devices, head mounted displays, mobile email devices, portable game consoles, portable music players, reader devices, televisions with one or more processors embedded or coupled therein, or other electronic devices capable of accessing a network.

Endorsement nodes 130-1 to 130-n are configured to receive an authentication request message to initiate an authentication transaction, and determine whether to perform an endorsement and send an endorsement response or refuse to perform an endorsement on the authentication transaction according to a certain verification rule. It is to be appreciated that endorsement nodes 130-1 to 130-n can be any device including, but not limited to, a server, a laptop computer, a desktop computer, a tablet computer, a mobile phone, a wearable device, a head-mounted display, a mobile email device, a portable game console, a portable music player, a reader device, a television with one or more processors embedded or coupled therein, or other electronic device capable of accessing a network.

The rank nodes 140-1 to 140-n may communicate with the client nodes 100-1 to 100-n and the endorsement nodes 130-1 to 130-n to determine whether to write the authentication result of the authentication request message sent by the client nodes or the pre-authentication result of the pre-authentication request message to the tiles of the blockchain system. It is to be appreciated that the rank nodes 140-1 through 140-n may include, but are not limited to, servers, laptops, desktops, tablets, mobile phones, wearable devices, head-mounted displays, mobile email devices, portable game consoles, portable music players, reader devices, televisions with one or more processors embedded or coupled therein, or other electronic devices capable of accessing a network.

Further, it is understood that in the present application, the nodes in the block chain system are merely divided by function, and in an actual setting, different nodes may be disposed on one physical device, such as a server, a laptop computer, a desktop computer, a tablet computer, a mobile phone, a wearable device, a head-mounted display, a mobile email device, a portable game console, a portable music player, a reader device, a television with one or more processors embedded or coupled therein, or other electronic devices capable of accessing a network. The endorsement node may be configured to be located on the same physical device, or may be configured to be located on the same physical device.

Further, it is to be understood that while FIG. 1 illustrates a plurality of customer nodes, a plurality of endorsement nodes, and a plurality of sequencing nodes, only one or two of the customer nodes, endorsement nodes, or sequencing nodes may be used in particular to conduct an authentication transaction.

Routing system 20 may include a plurality of routing autonomous systems AS 20-1 through AS 20-n. Each routing autonomous system of routing system 20 includes a plurality of routing devices, at least one of which may receive a route advertisement sent directly or indirectly by at least one of client nodes 100-1 through 100-n, and at least one of which may send a route advertisement or route advertisement information containing a record of the route advertisement to at least one of the back-office nodes 130-1 through 130-n. The indirect sending of the route advertisement by the client node to the routing device means that, when the client node cannot directly send the route advertisement to the routing device or the authentication requester cannot send the route advertisement to the routing device through the client node, the route advertisement containing the IP address prefix and the signature information obtained by signing the IP address prefix with the private key information of the authentication requester is sent through a computing device (such as a routing device) capable of sending the route advertisement.

It is to be understood that although fig. 1 shows a routing system comprising a plurality of autonomous systems AS, in practical applications, the routing system referred to in this application may comprise only one autonomous system AS.

According to some embodiments of the present application, the functions of each node of the HyperLegendre blockchain system in the pre-authentication phase are described. It will be appreciated that in particular implementations, the prevention of hijacking of IP address prefixes may be accomplished entirely with only a pre-authentication phase, not necessarily in combination with an authentication phase, by those skilled in the art.

The client node 100-1 (and possibly other ones of the client nodes 100-2 through 100-n) may generate a pre-authentication request message and send the pre-authentication request message to the endorsement nodes 130-1 through 130-n (and possibly one endorsement node or a portion of the endorsement nodes 130-1 through 130-n) in accordance with the endorsement policy. The pre-authentication request message is used to request authentication of the IP address Prefix that has not been authenticated before, and includes the IP address Prefix #1 and the public key information pk #1 of the authentication requester. The endorsement policy described above specifies which endorsement nodes can endorse the pre-authentication request message sent by the client node 100-1.

Furthermore, it is understood that in other embodiments, the pre-authentication request message may also be a request to authenticate other transactions, and is not limited herein. For example, the pre-authentication request message is used to request that the authentication requester has not hijacked the IP address prefix before, i.e. the authentication requester attempts to authenticate the ownership of the IP address prefix belonging to other client nodes in the blockchain system.

Each of the endorsement nodes 130-1 to 130-n may receive the pre-authentication request message transmitted by the client node 100-1, verify whether the IP address Prefix #1 has been previously authenticated in the blockchain system based on the received authentication request message, respectively, endorse the pre-authentication request message if not, and transmit an endorsement response to the client node 100-1, wherein the endorsement response includes a pre-authentication result indicating that the IP address Prefix #1 has not been previously authenticated in the blockchain system and an endorsement signature performed on the pre-authentication result.

The client node 100-1 may also determine whether an endorsement response is received, and in the event an endorsement response is received, determine whether the received endorsement response satisfies a predetermined condition, e.g., the predetermined condition is that endorsement responses returned by all of the endorsement nodes 130-1 to 130-n are received, or the predetermined condition is that endorsement responses have been received by a proportion of the endorsement nodes 130-1 to 130-n (e.g., 60% of the endorsement responses returned by the endorsement nodes are received). In addition, it is understood that the predetermined condition may be other conditions, and is not limited herein.

If the client node 100-1 determines that the endorsement response satisfies the predetermined condition, a consensus request is sent to the sort nodes 140-1 through 140-n (which may also be one or a portion of the sort nodes 140-1 through 140-n).

Each of the sequencing nodes 140-1 to 140-n may receive a consensus request from the client node 100-1, and may verify the identity of the endorsement node sending the endorsement response according to the endorsement response in the consensus request, and if each endorsement node sending the endorsement response is an endorsement node capable of endorsement of the pre-authentication request specified in the endorsement policy, perform consensus verification on the pre-authentication result in the endorsement response with other sequencing nodes, and write the pre-authentication result into the block in a certain order when the consensus verification is achieved, and send the formed block to each node of the block chain system. In this way, each node in the blockchain system can obtain the message that the authentication requester will authenticate the IP address Prefix # 1.

According to some embodiments of the present application, the functions of each node of the superhedgehog blockchain system and the routing device of the routing system in the authentication phase are described in the following specific embodiments.

The client node 100-1 may generate an authentication request message and send the authentication request message to an endorsement node 130-1 to 130-m (m is less than or equal to n) (or one or a portion of the endorsement nodes 130-1 to 130-n) of the endorsement nodes 130-1 to 130-n according to the endorsement policy. The authentication request message is used to request the authentication requester to have ownership over the IP address Prefix #1, and includes the IP address Prefix #1 requiring authentication and the public key information pk #1 of the authentication requester. Wherein the endorsement policy specifies which endorsement nodes can endorse the authentication request message sent by the client node 100-1.

The client node 100-1 sends a route advertisement (BGP Update message) to a routing device (not shown) in the routing system 20 directly or through a routing device or other machine capable of sending the route advertisement, where the route advertisement carries a signature information obtained by signing Prefix #1 with a private key sk #1 of a block chain of an authentication requester, in addition to the advertised IP address Prefix #1 and AS #1 (identification of a routing autonomous system).

BGP Update message format:

the signature information is contained in the Path Attribute part.

The routing device may receive the BGP Update message, and determine, according to the route advertisement record, whether the routing device has previously transmitted a route advertisement, where consecutive bits in a bit string of an IP address Prefix #2 in the route advertisement that are the same as a bit string of the IP address Prefix #1 in the BGP Update message exist, and the length of the consecutive bits is greater than the length of the IP address Prefix #1, and if it is determined that there is transmission, it may be determined that someone has intercepted transmission of the IP address Prefix #1, and therefore the routing device does not transmit the BGP Update message. If it is determined that the route advertisement has not been transmitted, a BGP Update message is transmitted. For example, Prefix #1 is 10.0.0.0/16, Prefix #2 is 10.0.0.0/16/8, and Prefix #2 has consecutive bits 10.0.0.0/16 identical to the bit string 10.0.0/16 of Prefix # 1.

In addition, the routing device may also send a route advertisement record to each of the endorsement nodes 130-1 to 130-m or a BGP Update message to each of the endorsement nodes 130-1 to 130-m after the routing device determines to transmit the BGP Update message.

Further, it will be appreciated that in some embodiments, the route advertisement record may be a route table generated by the routing device, and the relevant information of the transmitted route advertisement is recorded in the route table, and may include the IP address Prefix in the route advertisement, the AS path of the route advertisement (i.e., the transmitted AS, which may be represented by the identity ASN of the AS), and the transmission priority, for example, for the BGP Update message, the routing device may record in the route table, after transmitting the message, a Prefix #1, an AS path (e.g., AS 8 → AS 12 → AS 15, which indicates that the BGP Update message has been transmitted by AS 1 to AS 12 and then to AS 15), and the transmission priority. In addition, since the BGP Update message is sent by the client node, the routing table may also record the signature information thereof. The routing device determines whether to transmit a routing advertisement, which may be based on other methods and is not limited to the comparison of the IP address prefix bit string.

Each of the endorsement nodes 130-1 to 130-m may receive the authentication request message sent by the client node 100-1 and verify whether the authentication supplicant has ownership over the IP address Prefix #1, respectively. The specific verification method is as follows:

according to the route advertisement record received from the routing device, it is determined whether a route advertisement contains an IP address Prefix #2 in the route advertisements transmitted by the routing device within a predetermined time period (for example, one week, one month, or three months, etc.) in the record, wherein the Prefix #2 has the same continuous bits in the bit string as the IP address Prefix #1 in the BGP Update message, and the length of the bit string is greater than the length of the IP address Prefix # 1. If not, it means that nobody sends an intercepted routing advertisement (i.e. a routing advertisement containing the IP address Prefix # 2) to the routing device, and it can be determined that the authentication requester has ownership of the IP address Prefix; otherwise, it is determined that the authentication supplicant does not possess ownership of the IP address prefix.

Further, it is understood that in other embodiments, there may be other ways to verify whether the authentication requester has ownership over the IP address Prefix #1, such as:

each of the endorsement nodes 130-1 to 130-m may receive each route advertisement associated with the IP address Prefix #1 within a predetermined time period from the above-mentioned routing device, and determine whether the authentication supplicant owns the IP address Prefix by: if no route advertisement containing the IP address Prefix #2 exists in the route advertisements received within the predetermined time period, it means that nobody sends an intercepted route advertisement (i.e. the route advertisement containing the IP address Prefix # 2) to the routing device, and it can be determined that the authentication requester has ownership of the IP address Prefix; if the routing advertisement containing the IP address Prefix #2 exists, the routing advertisement indicates that someone sends an intercepted routing advertisement to the routing device, and the authentication requester is determined not to have ownership of the IP address Prefix.

Each of the endorsement nodes 130-1 to 130-m endorses the authentication request message sent by the client node 100-1 and sends an endorsement response to the client node 100-1 after verifying that the authentication requester has ownership of the IP address Prefix # 1. The endorsement response comprises an authentication result indicating that the authentication request passes and an endorsement node signing the authentication request.

Furthermore, it can be understood that, in some embodiments, the authentication requester is required to be authenticated after the pre-authentication is completed, and thus, the endorsement node is required to confirm whether the authentication requester has already performed the pre-authentication request in the blockchain system before performing the endorsement, and authenticate the authentication request of the authentication requester only in the case that the pre-authentication request has passed, for example, whether the public key information and the private key information in the signature information match is determined according to the received public key information of the authentication requester in the block of the pre-authentication result of the authentication requester and the received signature information in the route advertisement information from the routing device; in the case where the public key information and the private key information in the signature information match, it is determined that the authentication requester has completed the pre-authentication.

The client node 100-1 may also determine whether the received endorsement responses by the endorsement nodes 130-1 to 130-m satisfy a predetermined condition, for example, the predetermined condition is that endorsement responses returned by all of the endorsement nodes 130-1 to 130-m are received, or the predetermined condition is that endorsement responses by a proportion of the endorsement nodes 130-1 to 130-m are received (e.g., that endorsement responses returned by 60% of the endorsement nodes are received). In addition, it is understood that the predetermined condition may be other conditions, and is not limited herein.

If the client node 100-1 determines that the endorsement response satisfies the predetermined condition, a consensus request is sent to the sorting nodes 140-1 through 140-j (j is less than n).

Each of the sequencing nodes 140-1 to 140-j may receive the consensus request, and verify the identity of the endorsement node sending the endorsement response according to the endorsement response in the consensus request, if each endorsement node sending the endorsement response is legal, perform consensus verification on the authentication result in the endorsement response with the other sequencing nodes, and write the authentication result into the block in a certain order if the consensus verification is achieved, and send the formed block to each node of the block chain system. Thus, each node in the blockchain system can obtain a message for authenticating that the requester has ownership of the IP address Prefix # 1. And, the authentication requester can perform other transactions related to the IP address Prefix #1 in the blockchain system based on the authentication result.

Based on the above description, the main workflow of each node in the blockchain system and each routing device in the routing system is described in detail below.

According to some embodiments of the present application, in conjunction with the description of each node in the blockchain system in the pre-authentication phase, the working process of at least one of the client nodes 100-1 to 100-n is as shown in fig. 2, and specifically includes:

1) the client node generates a pre-authentication request message for requesting authentication of the IP address Prefix #1 that has not been authenticated before (200).

It is to be understood that the pre-authentication request message may also request authentication of other content, and is not limited herein. For example, requesting authentication authenticates that the requestor has not previously maliciously authenticated the IP address prefix.

2) A pre-authentication request message is sent to at least one of the endorsement nodes 130-1 to 130-n (202).

2) It is determined whether an endorsement response is received from the endorsement nodes 130-1 to 130-n (204), the endorsement response including a pre-authentication result indicating that the IP address Prefix #1 has not been authenticated in the blockchain system before and an endorsement signature performed on the pre-authentication result.

3) In the case where an endorsement response is received, it is determined whether the received endorsement response satisfies a predetermined condition (206). For example, the predetermined condition is that endorsement responses returned by all of the endorsement nodes 130-1 to 130-n are received, or the predetermined condition is that endorsement responses of more than 60% (or other ratios, which is not limited herein) of the endorsement nodes 130-1 to 130-n are received. In addition, it is understood that the predetermined condition may be other conditions, and is not limited herein.

4) In the event that the endorsement response satisfies a predetermined condition, a consensus request is sent to at least one of the ranking nodes 140-1 through 140-n (208). After the sequencing node receives the consensus request, the identity of the endorsement node sending the endorsement response is verified according to the endorsement response in the consensus request, if each endorsement node sending the endorsement response is an endorsement node which can make the endorsement response and is specified in the endorsement policy, the pre-authentication result in the endorsement response is verified in consensus with other sequencing nodes, the pre-authentication results are written into the block according to a certain sequence under the condition of consensus, and the formed block is sent to each node of the block chain system.

According to some embodiments of the present application, in combination with the description of each node in the blockchain system in the pre-authentication phase, the working process of at least one endorsement node in the endorsement nodes 130-1 to 130-n is as shown in fig. 3, and specifically includes:

1) a pre-authentication request message (300) may be received from the client node, wherein the pre-authentication request message is for requesting authentication of an IP address Prefix #1 that has not been previously authenticated.

2) It is verified whether the IP address Prefix #1 has been authenticated (302).

3) And if the IP address Prefix #1 is verified to be not authenticated, performing endorsement on the pre-authentication request message sent by the client node, and sending an endorsement response (304) to the client node, and if the IP address Prefix #1 is verified to be authenticated, not performing endorsement on the authentication request. Wherein, the endorsement response comprises a pre-authentication result indicating that the IP address Prefix #1 is not authenticated in the blockchain system before and an endorsement signature carried out on the pre-authentication result.

According to some embodiments of the present application, in combination with the description of each node in the blockchain system in the pre-authentication phase, the working process of each of the sequencing nodes 140-1 to 140-n receiving the consensus request is as shown in fig. 4, and specifically includes:

1) and receiving a consensus request (400) from the client node, wherein the consensus request comprises an endorsement response sent by the endorsement node to the client node and used for requesting consensus verification on an authentication result which represents that the pre-authentication request passes in the endorsement response.

2) And in response to the received consensus request, performing authenticity verification on the endorsement response in the consensus request to verify whether the endorsement node making the endorsement response is qualified to endorse the pre-authentication request, namely judging whether each endorsement node sending the endorsement response is an endorsement node capable of making the endorsement response and specified in the endorsement policy (402).

3) If the endorsement node verifying the endorsement response qualifies to endorse, the sorting nodes associated with others perform consensus verification on the pre-authentication result in the endorsement response indicating that the pre-authentication request passes (404).

4) If the consensus is found, the pre-authentication result is sorted and written into the block, and the block is sent to each node in the block chain system connected to the sorting node (406).

According to some embodiments of the present application, in conjunction with the description of each node in the blockchain system in the authentication phase, the working process of at least one of the client nodes 100-1 to 100-n is as shown in fig. 5, and specifically includes:

1) an authentication request message (500) is generated, wherein the authentication request message is for requesting authentication that the authentication requester has ownership of the IP address Prefix # 1. The authentication request message includes an IP address Prefix #1 and public key information pk #1 of the authentication requester.

2) An authentication request message is sent to at least one of the endorsement nodes 130-1 to 130-m and a route advertisement containing the IP address Prefix #1 may also be sent, directly or indirectly, to at least one routing device in the routing system 20 (502).

3) It is determined whether an endorsement response is received for the endorsement node (504), wherein the endorsement response comprises an authentication result indicating that the authentication request passes and an endorsement signature of the endorsement node on the authentication request.

4) In the case where an endorsement response is received, it is determined whether the received endorsement response satisfies a predetermined condition (506). For example, the predetermined condition is that endorsement responses returned by all of the endorsement nodes 130-1 to 130-m are received, or the predetermined condition is that endorsement responses of more than 49% of the endorsement nodes 130-1 to 130-m are received. In addition, it is understood that the predetermined condition may be other conditions, and is not limited herein.

5) And in the case that the endorsement response meets a preset condition, sending a consensus request (508) to at least one of the sequencing nodes 140-1 to 140-j, so that each sequencing node receiving the consensus request verifies the identity of the endorsement node sending the endorsement response according to the endorsement response in the consensus request, if each endorsement node sending the endorsement response is an endorsement node which can endorse the pre-authentication request and is specified in the endorsement policy, performing consensus verification on the authentication result in the endorsement response with other sequencing nodes, writing the authentication result into a block in a certain sequence in the case of achieving the consensus, and sending the formed block to each node of the block chain system.

According to some embodiments of the present application, in conjunction with the description of the routing device in the authentication phase, the working process of at least one routing device in the routing system 20 is as shown in fig. 6, and specifically includes:

1) a route advertisement a (600) sent directly or indirectly by the client node 100-1 may be received, the route advertisement a including an IP address prefix and signature information obtained by signing the IP address prefix with private key information of an authentication requester.

2) Determining whether a route advertisement B is received (602) according to a route advertisement record in a routing device, wherein an IP address prefix of the route advertisement B comprises an IP address prefix of the route advertisement A, and the length of the IP address prefix of the route advertisement B is longer than that of the IP address prefix of the route advertisement A. It is noted that the route advertisement B may not include signature information obtained by signing the IP address prefix with the private key information of the authentication requester.

3) If it is determined that route advertisement B is received, route advertisement A is not transmitted (604).

4) If it is determined that route advertisement B has not been received, route advertisement A is transmitted (606).

According to some embodiments of the present application, in combination with the description of each node in the blockchain system in the authentication phase, the working process of at least one of the endorsement nodes 130-1 to 130-j is as shown in fig. 7, and specifically includes:

1) an authentication request message (700) for requesting authentication that an authentication requester has ownership of an IP address Prefix #1 is received from the client node 100-1.

2) It is verified whether the authentication requester has ownership of the IP address prefix (702). The specific authentication method may refer to the description of the endorsement node above.

3) If the verification result is ownership, the authentication request is endorsed, and an endorsement response is sent to the client node (704). And if the verification result is that the ownership is not owned, the endorsement is not carried out.

It will be appreciated that if both the pre-authentication phase and the authentication phase are used, then in the authentication phase, the endorsement node performs

steps

702 and 704 above if it determines that the authentication supplicant has made a pre-authentication request and that the pre-authentication request has passed.

According to some embodiments of the present application, in combination with the description of each node in the blockchain system in the authentication phase, an operation process of sorting at least one of the nodes 140-1 to 140-j is shown in fig. 8, and specifically includes:

1) a consensus request is received from the client node 100-1 (800), wherein the consensus request requests the sequencing node to perform consensus verification on the authentication result in the endorsement response.

2) And in response to the received consensus request, performing authenticity verification on the endorsement response in the consensus request to verify whether the endorsement node making the endorsement response is qualified to endorse the authentication request (802), namely verifying whether the endorsement node making the endorsement response is the endorsement node capable of making the endorsement response and specified in the endorsement policy.

3) If the endorsement node verifying the endorsement response is qualified to make the endorsement response, performing consensus verification on the authentication result in the endorsement response by the other related sorting nodes (804).

4) If the verification result is a consensus, the authentication result is sorted and written into a block, and the block is sent to each node in the blockchain system connected to the sorting node (806), wherein the authentication result indicates that the authentication requester has ownership of the IP address prefix.

Another authentication scenario of the present application is described below. Fig. 9 shows a scenario diagram of this authentication scenario. The block chain system in the scene may be a block chain system using PBFT (Practical Byzantine Fault Tolerance algorithm), or may be other similar block chain systems, which is not limited herein.

As shown in fig. 9, in this scenario, there is a blockchain system 90 and a routing system 20. The blockchain system 90 includes client nodes 900-1 through 900-n and authentication nodes 920-1 through 920-n. Also, among the authentication nodes 920-1 to 920-n, there is one primary node (e.g., 920-1), and the rest are backup nodes. Wherein each of the client nodes 100-1 through 100-n may send an authentication request message or a pre-authentication request message to the primary node or the backup node. It is to be appreciated that the client nodes 100-1 through 100-n may include, but are not limited to, servers, laptop computers, desktop computers, tablet computers, mobile phones, wearable devices, head mounted displays, mobile email devices, portable game consoles, portable music players, reader devices, televisions with one or more processors embedded or coupled therein, or other electronic devices capable of accessing a network.

The primary node 920-1 sends a PRE-PREPARE message (PRE-PREPARE message) about the authentication request message or the PRE-authentication request message to other backup nodes after receiving the authentication request message or the PRE-authentication request message, and the backup node may verify the PRE-PREPARE message after receiving the PRE-PREPARE message and send a PREPARE message (PRE-PREPARE message) to the primary node and other backup nodes after the verification is passed. It is to be appreciated that the authentication nodes 920-1 through 920-n, including the primary node and backup nodes, may include, but are not limited to, servers, laptop computers, desktop computers, tablet computers, mobile phones, wearable devices, head-mounted displays, mobile email devices, portable game consoles, portable music players, reader devices, televisions with one or more processors embedded or coupled therein, or other electronic devices capable of accessing a network.

Further, it is understood that in the present application, the nodes in the block chain system are merely divided by function, and in an actual setting, different nodes may be disposed on one physical device, such as a server, a laptop computer, a desktop computer, a tablet computer, a mobile phone, a wearable device, a head-mounted display, a mobile email device, a portable game console, a portable music player, a reader device, a television with one or more processors embedded or coupled therein, or other electronic devices capable of accessing a network. It may also be located on different physical devices, for example, where the client node and the authentication node are located on the same physical device, or where multiple authentication nodes are located on the same physical device.

Further, it is to be understood that although fig. 9 illustrates a plurality of client nodes, a plurality of authentication nodes, only one or two of the client nodes or authentication nodes may be used when specifically performing an authentication transaction.

Routing system 20 may include a plurality of routing autonomous systems AS 20-1 through AS 20-n. Each routing autonomous system of routing system 20 includes a plurality of routing devices, at least one of which may receive a route advertisement sent directly or indirectly by at least one of client nodes 100-1 through 100-n, and at least one of which may send a route advertisement or route advertisement information containing a route advertisement record to at least one of authentication nodes 920-1 through 920-n.

It is to be understood that although fig. 9 shows a routing system comprising a plurality of autonomous systems AS, in practical applications, the routing system may comprise only one autonomous system AS.

The following describes the functionality of each node of the blockchain system in the pre-authentication phase, according to some embodiments of the present application.

The client node 900-1 (and possibly also the client node 900-2 through other ones of the client nodes 900-n) may generate a pre-authentication request message m1 and transmit the pre-authentication request message m1 to the master node 920-1. The pre-authentication request message m1 is used to request authentication of an IP address prefix that has not been previously authenticated. The pre-authentication request message in the pre-authentication request message m1 includes an IP address Prefix #1 and public key information pk #1 of the authentication requester.

After receiving the pre-authentication request message m1 sent by the client node 900-1, the master node 920-1 verifies whether the signature performed by the client node 900-1 on the pre-authentication request message m1 is correct. The primary node 920-1 sends a PREPARE message PRE-PREPARE 1 to the backup node if the check result is correct.

Backup nodes 920-2 through 920-n that receive the PRE-PREPARE message from primary node 920-1 can check the PRE-PREPARE 1 message and send a PREPARE 1 message to other backup nodes and primary nodes through backup nodes 920-2 through 920-n after checking. Each of the primary node 920-1 or the backup nodes enters a prepended state after receiving 2f (where n is 3f +1) PREPARE 1 messages from other backup nodes, and transmits a consensus message (COMMIT 1 message) to the other consensus nodes.

Each of the primary node 920-1 or the backup node enters an agreed-upon state after receiving 2f +1 (including itself) COMMIT messages, performs an instruction in the pre-authentication request, i.e., verifies whether the IP address prefix has been authenticated, and transmits a pre-authentication response message (REPLY message) to the client node 900-1 in case that the IP address prefix has not been authenticated as a result of the verification. The client node 900-1, upon receiving f +1 REPLY messages, may consider the pre-authentication request message m1 to be successfully processed by the consensus node. After the primary node and each backup node achieve the consensus, the primary node and each backup node write the pre-authentication result indicating that the pre-authentication request passes into the blocks of the block chain.

The following describes, according to some embodiments of the present application, the functions of each node of the blockchain system and the routing device of the routing system in the authentication phase.

The client node 900-1 (and possibly also the client node 900-2 through other ones of the client nodes 900-n) may generate an authentication request message m2 and transmit the authentication request message m2 to the master node 920-1. The authentication request message is for requesting authentication that the authentication requester has ownership of the IP address Prefix # 1. The authentication request message includes an authenticated IP address Prefix #1 and public key information pk #1 of the authentication requester. The client node 900-1 sends a route advertisement (BGP Update message) to a routing device (not shown) in the routing system 20 directly or through a routing device or other machine capable of sending the route advertisement, where the route advertisement carries a signature information obtained by signing Prefix #1 with the block chain private key sk #1 of the authentication requester, in addition to the advertised IP address Prefix #1 and AS number AS #1 (identification of the routing autonomous system).

BGP Update message format:

the signature information is contained in the Path Attribute part.

The routing device may receive a BGP Update message. The routing device may determine, according to the route advertisement record, whether the routing device has previously transmitted a route advertisement, where consecutive bits in a bit string of an IP address Prefix #2 in the route advertisement are the same as a bit string of the IP address Prefix #1 in the BGP Update message, and the length of the consecutive bits is greater than the length of the IP address Prefix #1, and if it is determined that there is transmission, it may be determined that someone has intercepted transmission of the IP address Prefix #1, so that the routing device does not transmit the BGP Update message. If the routing device determines that the route advertisement was not transmitted, the routing device transmits a BGP Update message. For example, Prefix #1 is 10.0.0.0/16, Prefix #2 is 10.0.0.0/16/8, and Prefix #2 has consecutive bits 10.0.0.0/16 identical to the bit string 10.0.0/16 of Prefix # 1.

In addition, the routing device may also send a route advertisement record to each backup node in the master node 920-1 or the backup nodes 920-2 to 920-n, or transmit a BGP Update message to each backup node in the master node 920-1 or the backup nodes 920-2 to 920-n after the routing device determines to transmit the BGP Update message.

Further, it will be appreciated that in some embodiments, the route advertisement record may be a route table generated by the routing device, and the relevant information of the transmitted route advertisement is recorded in the route table, and may include the IP address Prefix in the route advertisement, the AS path of the route advertisement (i.e., the transmitted AS, which may be represented by the identity ASN of the AS), and the transmission priority, for example, for the BGP Update message, the routing device may record in the route table, after transmitting the message, a Prefix #1, an AS path (e.g., AS 8 → AS 12 → AS 15, which indicates that the BGP Update message has been transmitted by AS 8 to AS 12 and then to AS 15), and the transmission priority. In addition, since the BGP Update message is sent by the client node, the routing table may also record the signature information thereof. The routing device determines whether to transmit a routing advertisement, which may be based on other methods and is not limited to the comparison of the IP address prefix bit string.

The master node 920-1 may receive the authentication request message m2 sent by the client node 900-1, and the master node 920-1 verifies whether the signature performed by the client node 900-1 on the authentication request message m2 is correct. The primary node 920-1 sends a PREPARE message PRE-PREPARE 2 to the backup node if the check result is correct. The backup nodes 920-2 to 920-n receiving the PRE-PREPARE 2 message of the primary node 920-1 check the PRE-PREPARE 2 message and send a PREPARE 2 message to other backup nodes and the primary node after the check is passed.

Each of the primary node 920-1 or backup nodes enters a prepared (prepared) state after receiving 2f (where n is 3f +1) PREPARE 2 messages from other backup nodes, and transmits a consensus message (COMMIT 2 message) to the other backup nodes (or primary nodes). After each backup node or primary node receives 2f +1 (including itself) COMMIT 2 messages, it enters the agreed-upon state, and the nodes execute the instructions in the authentication request in m2, i.e. verify whether the authentication requester has ownership over the IP address Prefix # 1. The specific verification method is as follows:

receiving each route advertisement related to the IP address Prefix #1 in a predetermined time period from the routing device, and if no route advertisement containing the IP address Prefix #2 is included in the route advertisements received in the predetermined time period, it indicates that no one has sent an intercepted route advertisement (i.e. the route advertisement containing the IP address Prefix # 2) to the routing device, and it may be determined that the authentication requester has ownership of the IP address Prefix; if the routing advertisement containing the IP address Prefix #2 exists, the routing advertisement indicates that someone sends an intercepted routing advertisement to the routing device, and the authentication requester is determined not to have ownership of the IP address Prefix.

Each backup node or the master node transmits an authentication response message (REPLY 2 message) to the client node 900-1 in the case where the authentication requester has ownership of the IP address Prefix #1 as a result of the verification. The client node 900-1, upon receiving f +1 REPLY 2 messages, may consider the request message m2 to be successfully processed by the consensus node. After the primary node and each backup node achieve the consensus, the authentication result indicating that the authentication request passes is written into the blocks of the block chain.

Furthermore, it can be understood that, in some embodiments, the authentication requester is required to perform authentication after completing the pre-authentication, and thus, the master node or the backup node is required to confirm whether the authentication requester has performed the pre-authentication request in the blockchain system before performing authentication according to the instruction of the authentication request, and authenticate the authentication request of the authentication requester only when the pre-authentication request has passed, for example, whether the public key information and the private key information in the signature information match is determined according to the received public key information of the authentication requester in the block of the pre-authentication result of the authentication requester and the signature information in the route advertisement information received from the routing device; in the case where the public key information and the private key information in the signature information match, it is determined that the authentication requester has completed the pre-authentication.

According to some embodiments of the present application, the working process of at least one of the client nodes 900-1 to 900-n in the pre-authentication phase is as shown in fig. 10, and specifically comprises:

1) a pre-authentication request message (1000) is generated, wherein the pre-authentication request message is used for requesting authentication of the IP address Prefix #1 that has not been authenticated before, and the pre-authentication request can include the IP address Prefix #1 and public key information of the authentication requester.

2) A pre-authentication request message is sent to the master node 920-1 (1002).

3) A pre-authentication response is received from at least one of primary node 920-1 and backup nodes 920-2 through 920-n (1004), the pre-authentication response including a pre-authentication result pk #1 indicating that the IP address prefix was not authenticated before being authenticated.

According to some embodiments of the present application, in the authentication phase, the working process of at least one of the client nodes 900-1 to 900-n is as shown in fig. 11, and specifically includes:

1) an authentication request message (1100) is generated, wherein the authentication request message is for requesting authentication that the authentication requester has ownership of the IP address Prefix # 1. The authentication request message includes an IP address Prefix #1 and public key information pk #1 of the authentication requester.

2) An authentication request message is sent to the master node 920-1 (1102).

3) An authentication response is received from at least one of the primary node 920-1 and the backup nodes 920-2 through 920-n (1104), the authentication response including an authentication result indicating that the client node 100-1 has ownership of the IP address Prefix # 1.

Under the PBFT blockchain system, the function of the routing device in the routing system is substantially the same as that under the hyperhedger blockchain system, and the only difference is that the object for sending the route advertisement or the route advertisement record is at least one of the master node 920-1 and the backup nodes 920-2 to 920-n. Therefore, the description thereof is omitted.

According to some embodiments of the present application, in this scenario, the operation of at least one routing device in the routing system 20 in the authentication phase is substantially the same as that in fig. 8, except that the routing device transmits route advertisement information containing a route advertisement or route advertisement information containing a route advertisement record to at least one of the authentication nodes 920-1 to 920-n. And will not be described in detail herein.

Referring now to FIG. 12, shown is a block diagram of an apparatus 1200 in accordance with one embodiment of the present application. The device 1200 may include one or more processors 1201 coupled to a controller hub 1203. For at least one embodiment, controller hub 1203 communicates with processor 1201 via a multi-drop bus such as a front-side bus (FSB), a point-to-point interface such as a quick channel interconnect (QPI), or similar connection 1206. The processor 1201 executes instructions that control general types of data processing operations. In one embodiment, controller hub 1203 includes, but is not limited to, a Graphics Memory Controller Hub (GMCH) (not shown) and an input/output hub (IOH) (which may be on separate chips) (not shown), where the GMCH includes a memory and a graphics controller and is coupled with the IOH.

The device 1200 may also include a coprocessor 1202 and a memory 1204 coupled to the controller hub 1203. Alternatively, one or both of the memory and GMCH may be integrated within the processor (as described herein), with the memory 1204 and coprocessor 1202 being directly coupled to the processor 1201 and to the controller hub 1203, with the controller hub 1203 and IOH being in a single chip. The memory 1204 may be, for example, Dynamic Random Access Memory (DRAM), Phase Change Memory (PCM), or a combination of the two. In one embodiment, coprocessor 1202 is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like. The optional nature of coprocessor 1202 is represented in FIG. 12 by dashed lines.

In one embodiment, device 1200 may further include a Network Interface (NIC) 1206. Network interface 1206 may include a transceiver to provide a radio interface for device 1200 to communicate with any other suitable device (e.g., front end module, antenna, etc.). In various embodiments, the network interface 1206 may be integrated with other components of the device 1200. The network interface 1206 may implement the functions of the communication unit in the above-described embodiments.

Device 1200 may further include an input/output (I/O) device 1205. I/O1205 may include: a user interface designed to enable a user to interact with the device 1200; the design of the peripheral component interface enables peripheral components to also interact with the device 1200; and/or sensors may be configured to determine environmental conditions and/or location information associated with device 1200.

It is noted that fig. 12 is merely exemplary. That is, although fig. 12 shows that the apparatus 1200 includes a plurality of devices, such as the processor 1201, the controller hub 1203, the memory 1204, etc., in practical applications, an apparatus using the methods of the present application may include only a part of the devices of the apparatus 1200, for example, only the processor 1201 and the NIC1206 may be included. The nature of the alternative device in fig. 12 is shown in dashed lines.

Referring now to fig. 13, shown is a block diagram of a SoC (System on Chip) 1300 in accordance with an embodiment of the present application. In fig. 13, like parts have the same reference numerals. In addition, the dashed box is an optional feature of more advanced socs. In fig. 13, the SoC130 includes: an interconnect unit 1339 coupled to the application processor 1310; a system agent unit 1370; a bus controller unit 1380; an integrated memory controller unit 1330; a set or one or more coprocessors 1310 which may include integrated graphics logic, an image processor, an audio processor, and a video processor; an Static Random Access Memory (SRAM) unit 1320; a Direct Memory Access (DMA) unit 1349. In one embodiment, the coprocessor 1310 includes a special-purpose processor, such as, for example, a network or communication processor, compression engine, GPGPU, a high-throughput MIC processor, embedded processor, or the like.

According to some embodiments of the present application, a client node in a blockchain system is disclosed. Fig. 14 shows a schematic structural diagram of the client node. The client node may implement the functionality of the client node in the embodiments described above. Specifically, as shown in fig. 14, the client node includes:

an authentication generating module 1402, configured to generate an authentication request message, where the authentication request message includes an IP address prefix and public key information of an authentication requester, and the authentication request message is used to request that the authentication requester has ownership over the IP address prefix and to request that an authentication result indicating that the authentication request passes is written into a block of the blockchain system;

an authentication sending module 1404, configured to send an authentication request message to an authentication node in the blockchain system.

Optionally, the authentication sending module 1404 is further configured to send a route advertisement to the routing device, where the route advertisement includes an IP address prefix and signature information obtained by signing the IP address prefix with the private key information of the authentication requester.

Optionally, the authentication generating module 1402 is further configured to generate a pre-authentication request message, where the pre-authentication request message includes an IP address prefix, and the pre-authentication request message is used to request that ownership of the IP address prefix is not authenticated and that a pre-authentication result indicating that the pre-authentication request passes is written into a block of the blockchain system; and the authentication sending module 1404 is further configured to send a pre-authentication request message to a pre-authentication node in the blockchain system.

According to some embodiments of the present application, a routing device is disclosed. Fig. 15 shows a schematic structural diagram of the routing device. The routing device may implement the functions of the routing device in the embodiments described above. Specifically, as shown in fig. 15, the routing device includes:

a route receiving module 1502, configured to receive a first route advertisement, where the first route advertisement includes a first IP address prefix and signature information of private key information of an authentication requester requesting authentication for ownership of the first IP address prefix to the first IP address prefix;

a route determining module 1504, configured to determine whether to transmit the first route advertisement according to a route advertisement record, where the route advertisement record includes an IP address prefix in the route advertisement that has been transmitted by the routing device.

Optionally, the route determining module 1504 is specifically configured to: judging whether continuous bits identical to the bit string of the first IP address prefix exist in the bit string of the IP address prefix in the route notification record or not, and judging whether the length of the IP address prefix in the route notification record is larger than that of the first IP address prefix; and in the case that the judgment result is negative, determining to transmit the first route advertisement.

Optionally, the route determining module 1504 is further configured to write information related to the transmitted first route advertisement into a route advertisement record, where the information related to the first route advertisement includes a first IP address prefix and signature information.

Optionally, the route receiving module 1502 is further configured to receive a second route advertisement, where the second route advertisement includes a second IP address prefix; the route determining module is further configured to determine whether a bit string of the IP address prefix in the route advertisement record has consecutive bits that are the same as a bit string of the second IP address prefix, and determine to transmit the second route advertisement if the determination result is negative, where the length of the IP address prefix in the route advertisement record is greater than the length of the second IP address prefix; and the routing device further comprises:

and the route transmitting unit is used for transmitting the second route advertisement under the condition that the route determining module determines to transmit the second route advertisement, and is also used for sending a route advertisement record to the authentication node in the blockchain system.

Optionally, the route determining module 1504 is further configured to write information related to the transmitted second route advertisement into a route advertisement record, where the information related to the second route advertisement includes a second IP address prefix.

According to some embodiments of the present application, a client node in a blockchain system is disclosed. Fig. 16 is a schematic diagram of the structure of the client node. The client node may implement the functionality of the client node in the embodiments described above. Specifically, as shown in fig. 16, the client node includes:

a pre-authentication generating module 1602, configured to generate a pre-authentication request message, where the pre-authentication request message includes an IP address prefix and public key information of an authentication requester, and the pre-authentication request message is used to request that ownership of the IP address prefix is not authenticated and that a pre-authentication result indicating that a pre-authentication request passes is written into a block of the blockchain system;

a pre-authentication sending module 1604, configured to send the pre-authentication request message to an authentication node in the blockchain system.

In addition, it can be understood that, in the present application, in addition to the public key and the private key, other modes or other encryption modes may be used for performing identity verification, that is, the pre-authentication request message or the authentication request message may not include public key information, but other information with an encryption verification function, which is not limited herein, and accordingly, the routing advertisement sent by the authentication requester may not include signature information signed by the private key, or may be other information corresponding to other encryption transmission modes and corresponding to the encryption function information in the authentication request.

Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementations. Embodiments of the application may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device.

Program code may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For purposes of this application, a processing system includes any system having a processor such as, for example, a Digital Signal Processor (DSP), a microcontroller, an Application Specific Integrated Circuit (ASIC), or a microprocessor.

The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The program code can also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described in this application are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.

In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or via other computer readable media. Thus, a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including, but not limited to, floppy diskettes, optical disks, read-only memories (CD-ROMs), magneto-optical disks, read-only memories (ROMs), Random Access Memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or a tangible machine-readable memory for transmitting information (e.g., carrier waves, infrared digital signals, etc.) using the internet in an electrical, optical, acoustical or other form of propagated signal. Thus, a machine-readable medium includes any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

In the drawings, some features of the structures or methods may be shown in a particular arrangement and/or order. However, it is to be understood that such specific arrangement and/or ordering may not be required. Rather, in some embodiments, the features may be arranged in a manner and/or order different from that shown in the illustrative figures. In addition, the inclusion of a structural or methodical feature in a particular figure is not meant to imply that such feature is required in all embodiments, and in some embodiments, may not be included or may be combined with other features.

It should be noted that, in the embodiments of the apparatuses in the present application, each unit/module is a logical unit/module, and physically, one logical unit/module may be one physical unit/module, or may be a part of one physical unit/module, and may also be implemented by a combination of multiple physical units/modules, where the physical implementation manner of the logical unit/module itself is not the most important, and the combination of the functions implemented by the logical unit/module is the key to solve the technical problem provided by the present application. Furthermore, in order to highlight the innovative part of the present application, the above-mentioned device embodiments of the present application do not introduce units/modules which are not so closely related to solve the technical problems presented in the present application, which does not indicate that no other units/modules exist in the above-mentioned device embodiments.

It is noted that, in the examples and descriptions of this patent, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the use of the verb "comprise a" to define an element does not exclude the presence of another, same element in a process, method, article, or apparatus that comprises the element.

While the present application has been shown and described with reference to certain preferred embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present application.

Claims

1. An IP address prefix authentication method based on a block chain system is characterized by comprising the following steps:

generating an authentication request message, wherein the authentication request message comprises an IP address prefix, and the authentication request message is used for requesting an authentication requester to have ownership over the IP address prefix and requesting to write an authentication result indicating that the authentication request passes into a block of the blockchain system;

sending the authentication request message to an authentication node in the blockchain system.

2. The method of claim 1, further comprising:

and sending a route advertisement to a routing device, wherein the route advertisement comprises the IP address prefix and signature information obtained by signing the IP address prefix by private key information of an authentication requester.

3. The method of claim 1 or 2, further comprising:

generating a pre-authentication request message, wherein the pre-authentication request message comprises the IP address prefix, and the pre-authentication request message is used for requesting to authenticate that the ownership of the IP address prefix is not authenticated and requesting to write a pre-authentication result indicating that the pre-authentication request passes into the blocks of the blockchain system;

sending the pre-authentication request message to a pre-authentication node in the blockchain system.

4. An IP address prefix authentication method based on routing equipment is characterized by comprising the following steps:

receiving a first routing advertisement, wherein the first routing advertisement comprises a first IP address prefix and signature information of private key information of an authentication requester requesting authentication for ownership of the first IP address prefix to the first IP address prefix;

determining whether to transmit the first route advertisement according to a route advertisement record, wherein the route advertisement record comprises an IP address prefix in a route advertisement transmitted by the routing device.

5. The method of claim 4, wherein determining whether to transmit the first route advertisement based on a route advertisement record comprises:

judging whether continuous bits identical to the bit string of the first IP address prefix exist in the bit string of the IP address prefix in the route advertisement record or not and the length of the IP address prefix in the route advertisement record is larger than that of the first IP address prefix;

and determining to transmit the first route advertisement under the condition that the judgment result is negative.

6. The method of claim 5, further comprising:

writing the related information of the transmitted first route advertisement into the route advertisement record, wherein the related information of the first route advertisement comprises the first IP address prefix and the signature information.

7. The method of claim 5, further comprising:

receiving a second route advertisement, the second route advertisement including a second IP address prefix;

judging whether the bit string of the IP address prefix in the route advertisement record has continuous bits which are the same as the bit string of the second IP address prefix and the length of the IP address prefix in the route advertisement record is larger than the length of the second IP address prefix;

and determining to transmit the second route advertisement under the condition that the judgment result is negative.

8. The method of claim 7, further comprising:

writing the related information of the transmitted second route advertisement into the route advertisement record, wherein the related information of the second route advertisement includes the second IP address prefix.

9. The method of any of claims 4 to 8, further comprising:

sending the route advertisement record to the authentication node in the blockchain system.

10. An IP address prefix authentication method based on a block chain system is characterized by comprising the following steps:

generating a pre-authentication request message, wherein the pre-authentication request message comprises an IP address prefix and public key information of an authentication requester, the pre-authentication request message is used for requesting authentication that ownership of the IP address prefix is not authenticated, and requesting to write a pre-authentication result indicating that the pre-authentication request passes into a block of the block chain system;

sending the pre-authentication request message to an authentication node in the blockchain system.

11. A client node in a blockchain system, comprising:

an authentication generation module, configured to generate an authentication request message, where the authentication request message includes an IP address prefix, and the authentication request message is used to request authentication that the authentication requester has ownership over the IP address prefix and to request that an authentication result indicating that the authentication request passes is written into a block of the blockchain system;

and the authentication sending module is used for sending the authentication request message to an authentication node in the blockchain system.

12. The client node of claim 11, wherein the authentication sending module is further configured to send a routing advertisement to a routing device, wherein the routing advertisement includes the IP address prefix and signature information of an authentication requester that signed the IP address prefix.

13. The client node of claim 11 or 12, wherein the authentication generation module is further configured to generate a pre-authentication request message, wherein the pre-authentication request message includes the IP address prefix, the pre-authentication request message is configured to request authentication that ownership of the IP address prefix is not authenticated and to request writing of a pre-authentication result indicating that the pre-authentication request passes into a block of the blockchain system; and is

The authentication sending module is further configured to send the pre-authentication request message to a pre-authentication node in the blockchain system.

14. A routing device, comprising:

a route receiving module, configured to receive a first route advertisement, where the first route advertisement includes a first IP address prefix and signature information of private key information of an authentication requester requesting authentication for ownership of the first IP address prefix to the first IP address prefix;

a route determining module, configured to determine whether to transmit the first route advertisement according to a route advertisement record, where the route advertisement record includes an IP address prefix in a route advertisement that has been transmitted by the routing device.

15. The routing device of claim 14, wherein the route determination module is specifically configured to:

16. The routing device of claim 15, wherein the route determination module is further configured to write information related to the transmitted first route advertisement into the route advertisement record, wherein the information related to the first route advertisement includes the first IP address prefix and the signature information.

17. The routing device of claim 16, wherein the route reception module is further to receive a second route advertisement, the second route advertisement including a second IP address prefix; and is

The route determining module is further configured to determine whether a bit string of the IP address prefix in the route advertisement record has consecutive bits that are the same as a bit string of the second IP address prefix, and determine to transmit the second route advertisement if the determination result is negative, where the length of the IP address prefix in the route advertisement record is greater than the length of the second IP address prefix; and is

The routing device further comprises

A route transmitting unit, configured to transmit the second route advertisement if the route determining module determines to transmit the second route advertisement.

18. The routing device of claim 17, wherein the route determination module is further configured to write the related information of the transmitted second route advertisement into the route advertisement record, wherein the related information of the second route advertisement includes the second IP address prefix.

19. The routing device of claim 14, further comprising:

a route transfer unit, configured to send the route advertisement record to the authentication node in the blockchain system.

20. A client node in a blockchain system, comprising:

a pre-authentication generation module, configured to generate a pre-authentication request message, where the pre-authentication request message includes an IP address prefix, and the pre-authentication request message is used to request to authenticate that ownership of the IP address prefix is not authenticated, and to request to write a pre-authentication result indicating that a pre-authentication request passes into a block of the blockchain system;

and the pre-authentication sending module is used for sending the pre-authentication request message to an authentication node in the blockchain system.