CN111031010B

CN111031010B - Certificate transaction warning method of resource public key infrastructure based on block chain

Info

Publication number: CN111031010B
Application number: CN201911168993.2A
Authority: CN
Inventors: 张硕; 刘亚萍; 吴纯青; 田李; 李清源; 彭素芳
Original assignee: Guangzhou University; Peng Cheng Laboratory
Current assignee: Guangzhou University; Peng Cheng Laboratory
Priority date: 2019-11-25
Filing date: 2019-11-25
Publication date: 2021-10-08
Anticipated expiration: 2039-11-25
Also published as: CN111031010A

Abstract

The invention discloses a certificate transaction warning method of resource public key infrastructure based on a block chain, aiming at timely warning and reminding when resource conflict occurs or transaction is illegal in the transaction process. The technical scheme is as follows: constructing a resource public key infrastructure consisting of a resource issuer, a resource transaction application client, a resource receiver, a blockchain network, a verification node and an alarm server; designing the operation of the resource certificate and the routing origin authorization as a transaction; the verification node runs the intelligent contract to verify the transaction, the successful transaction passing the verification is stored in the resource transaction success block chain, and the failed transaction failing the verification and the reason are stored in the resource transaction failure block chain; and the alarm server gives potential malicious person risks and gives an alarm according to the failure transaction and reasons in the resource transaction failure block chain. The invention can effectively improve the safety of the RPKI and solve the problems that an alarm system is lacked in the RPKI system and errors are generated in the operation and the RPKI system cannot know the errors.

Description

Certificate transaction warning method of resource public key infrastructure based on block chain

Technical Field

The invention belongs to the field of network information security, and particularly relates to a block chain-based certificate transaction warning method for a Resource Public Key Infrastructure (RPKI) for improving the security of the RPKI.

Background

BGP (Border Gateway Protocol) is an interdomain routing Protocol in the Internet. However, the conventional BGP protocol is susceptible to many security threat attacks, one of the most common BGP attacks being prefix hijacking. By forging the originating AS (i.e., the AS that originated the route advertisement information) in the BGP route advertisement information, traffic corresponding to these IP address prefixes is caused to be intercepted or dropped by the hijacker's AS. The resource public key infrastructure (i.e., RPKI) is an infrastructure for supporting IP address prefix origination verification, which can provide a trusted mapping of authorized IP address prefixes to the originating AS. The IP address is equal to the network address plus the host address, and the IP address prefix refers to the address portion of the IP address corresponding to its network portion, i.e., the network address of the IP address, and is used to uniquely identify the network number of a network connected to the Internet. IP address { < address prefix >, < host number > }. To distinguish address prefixes, a "slash notation" is usually adopted, i.e., the number of bits occupied by the IP address/network prefix. For example: 192.168.24.0/22 indicates 32-bit address, the first 22 bits are network prefix, and the last 10(32-22 ═ 10) bits represent host number. In the conversion, 192.168.24.0/22 corresponds to a binary value:

1100 0000(192)，1010 1000(168)，0001 1000(24)，0000 0000(0)

RPKI is attached to the distribution process of Internet digital resources INR (Internet number resources), where INR includes IP address resources and AS number resources, i.e. the IP address and AS number owned by a organization, and an Internet registration management authority RIR (regional Internet registry) is used AS the uppermost resource issuer, and the RIR may distribute its own Internet number resources to lower resource issuers such AS local Internet registration authority (LIR), national Internet registration authority (national Internet registry, NIR), and Internet service provider (Internet service provider, ISP), and then lower resource issuers distribute them downward step by step in sequence, and provide a top-down mapping library of verifiable IP address prefixes and AS origin through a top-down authority hierarchy. The RPKI consists of three components: a public key infrastructure-based certificate object, a signature object for representing a route Origin authorization, roa, (route Origin authorization), and a distributed storage system for maintaining the object. The RP (resolving Party) is the user of the RPKI, which takes a copy of the set of signed objects, verifies the signature, generates a list of valid ROAs, and periodically checks for updates to the signed objects in the distributed storage system and synchronizes the updates. The ROA is authorization information for an IP address owner to authorize an AS to perform routing advertisement for the ROA, and contains a "binding relationship" between an AS number and one or more IP address prefixes.

The ROA may be used by the RP to verify whether the AS that initiates routing for a particular IP address prefix is authorized by the address owner. The BGP router uses the valid ROA list information provided by the RPs in the RPKI to distinguish between BGP routes originated by a legitimate originating AS and BGP routes that may be hijacked.

However, RPKI itself also faces security risks. While many specifications for RPKI discuss how RPKI verifies BGP routing, proper functioning of RPKI depends on whether the RP can provide correct, comprehensive, valid ROA information. The main security issues of RPKI themselves are: a malicious authority may cause some legitimate BGP routes to be illegitimate by malicious operations on the RPKI on various resource certificates RC (resource certificate) (the contents of RC include the x.509 certificate of standard RFC 5280, accompanied by the IP address and AS extension identifier of RFC 3779, used to guarantee the allocation of the IP address prefix and AS number). Or the malicious authority operates different resource certificate views to different RPs, thereby achieving the purpose that certain legal IP addresses are blocked or redirected to different forwarding paths at the routing forwarding level to illegally attract the traffic. Aiming at the problems, the current RPKI has no alarm mechanism for the error operation caused by the operation of various resource certificate objects (the operation error of an organization administrator or the malicious behavior of attack) to send out alarm information in time, so that the caused error can be remedied in time.

The blockchain is generally used for solving the trust problem caused by centralization, and in 2008, the owner is clever in bitjoin: a Peer-to-Peer Electronic Cash System (bit currency: a point-to-point Electronic Cash System) proposes a block chain as the bottom layer technology of bit currency. The block chain is formed by a plurality of blocks (the first block is designated as a created block) connected in sequence according to the time stamp of the generated transaction. The block chain is generally used for solving the problem of node dependence, and as a decentralized technology, the block chain allows two transaction parties to directly perform online transaction without a third-party management mechanism or central control, and all nodes can automatically and safely verify and exchange data in a system. Blockchain techniques will trust the existence of the network rather than some central authority. The terminal responsible for maintaining the operation of the network may be referred to as a node. A blockchain is a decentralized distributed database that is not dependent on which centralized server, but rather consists of numerous "servlets," which become one of numerous "servlets" as long as the server has a blockchain client installed, then the server is a node.

The concept of smart contracts was first proposed in 1994 by the computer student Nick Szabo, who published several articles on their own web site at that time, and the concept of smart contracts was mentioned in the articles. He writes: the overall goal of a smart contract is to satisfy common contract conditions (e.g., pay, lien, confidentiality, and even enforcement) with minimal exceptions and requirements on trusted intermediaries. Related economic objectives include reducing fraud losses, arbitration and execution costs, and other transaction costs. Intelligent contracts in digital form mean that the contracts are implemented by computer code. In an intelligent contract, whenever a participant agrees, the intelligent contract establishes rights and obligations for each party. The contract is then executed over a computer network.

No disclosure is known concerning the use of blockchains to solve the RPKI intrinsic security problem.

Because no role in the RPKI system is used for alarming, namely when the resource certificate RC conflicts with the operation of the routing origin authorized ROA or the operation is illegal, no monitoring user sends out alarm information to remind an operator of misoperation or attack, the operator cannot respond in time, misoperation or illegal operation is caused without awareness, the routing between legal domains is judged illegal, the legal IP address is blocked or corresponding flow is maliciously attracted, and great security threat is caused.

Disclosure of Invention

The technical problem to be solved by the invention is to provide an alarm method of resource public key infrastructure based on a block chain, any operation of issuing, canceling, updating and modifying a resource certificate is designed as a transaction behavior in the block chain, when resource conflict or transaction is illegal occurs when the resource certificate RC and routing origin authorization ROA carry out transactions (issue transactions, cancel transactions, update transactions and modify transactions) in the block chain, alarm reminding is carried out in time, and security threat caused by operation fault or illegal operation without awareness during the transactions is avoided.

The technical scheme of the invention is as follows: the current RPKI working architecture is changed, the operation of the resource certificate and the routing origin authorization ROA is designed into a transaction, the resource issuer submits the operation of the objects as the transaction to the blockchain platform, and the verification node runs an intelligent contract to verify the transaction. Recording successful transaction passing the verification of the intelligent contract in a resource transaction successful block chain; and the failure transaction and the failure reason which fail to pass the intelligent contract verification are stored in the resource transaction failure block chain, and the monitoring user gives the risk of the potential malicious person and sends an alarm prompt according to the failure transaction and the reason recorded in the resource transaction failure block chain.

The invention comprises the following steps:

in the first step, a Resource Public Key Infrastructure (RPKIB) (RPKIBlockchain) system is constructed. The resource transaction system consists of a resource issuer, a resource transaction application client, a resource receiver, a blockchain network, a verification node and an alarm server.

The block chain network is a decentralized system, each node in the block chain network is peer-to-peer, and the peer-to-peer node can be used as a resource issuer or a resource receiver. The block chain network eliminates the dependence problem of the original RPKI on the central node through a decentralized mechanism, and is connected with a resource issuer, a resource receiver, an alarm server and a verification node. And the resource issuer, the resource receiver and the alarm server are connected with the block chain network to form a common node of the block chain network. The verification node is another node different from the common node in the block chain network, is a server for verifying resource transaction initiated by a resource issuer, and is provided with a resource certificate transaction intelligent contract. The resource issuer and the resource receiver take various operations of the resource certificate and the routing origin authorization ROA as transactions through the blockchain network, and store transaction records in a distributed account book. The distributed account book comprises a resource tree and two chains: the resource tree is used for storing effective resource certificates; and the resource transaction success block chain and the resource transaction failure block chain exist in all the block chain nodes, and the contents of the resource transaction success block chain and the resource transaction failure block chain of each node are kept consistent. The resource transaction success block chain is a chain in the distributed account book and is used for storing resource transaction records successfully verified by the resource certificate transaction intelligent contract. The resource transaction failure block chain is another chain in the distributed account book and is used for storing the resource transaction failure block chain which cannot pass through the resource certificate transaction intelligent contract verification and recording the reason of the resource transaction failure.

The resource issuer is a server, a resource transaction application client is installed on the server, and the resource issuer becomes a node of the blockchain network after being connected to the blockchain network. The resource issuer and the resource receiver are used as both transaction parties, and after the agreement of both transaction parties (namely the resource issuer and the resource receiver) is obtained through bidirectional authorization, the resource issuer sends the transaction to the block chain network.

The resource receiver is a server on which a resource transaction application client is installed, and is connected with the blockchain. The resource receiver is connected to the blockchain network and becomes a node of the blockchain network.

The resource transaction application client is installed on a resource issuer and a resource receiver and consists of a resource transaction module, a resource certificate generation module and a display module.

The resource certificate generation module is connected with the resource transaction module; the resource certificate generation module receives information of a pre-issued RC certificate and ROA from the resource transaction module, and generates a resource certificate RC which is defined by the same RPKI according to the pre-issued RC certificate, wherein the content of the resource certificate RC comprises an X.509 certificate of standard RFC 5280 and is attached with an IP address and an AS extended identifier of RFC 3779 standard. The resource certificate generation module creates a Route Origination Authority (ROA) for a resource held by a resource recipient based on pre-issued ROA information (including an AS number and one or more IP address prefixes). An effective ROA comprises three parts: an AS number; a list of IP address prefixes; optional content that restricts the prefix of the IP address. The resource certificate generation module sends the generated RC and ROA to the resource transaction module.

The resource transaction module is connected with the resource issuer (or the resource receiver), the resource certificate generation module, the display module and the blockchain network. The resource transaction module receives the RC or the ROA from the resource certificate generation module, receives an operation instruction about the RC or the ROA from the resource issuer, conducts transaction through the blockchain network, and provides various operation services of RC or ROA resource transaction for the resource issuer, such as: issuing the RC and the ROA to the resource receiver; revoking the RC and the ROA from the resource receiver; modifying RC and ROA (ROA modification is realized by issuing a new certificate under the condition that the set ROA extension item, namely IP address prefix and AS number, needs to be modified); performing an update operation on the RC (the update refers to replacing the old certificate with a new certificate before the old certificate expires, and only the certificate validity period and the serial number (serial number of the certificate) change in the old certificate update process); the RC updating operation only needs to change the validity period and the serial number of the old certificate, and does not relate to the IP address prefix and the AS number carried by the certificate; and the RC modify operation involves the IP address prefix and AS number carried by the certificate; one operation is a transaction in the RPKIB. And when the transaction is successful, the resource transaction module sends a success message to the display module, when the transaction is unsuccessful, the resource transaction module sends a conflict reason, an operation failure reason and a transaction result which are detected by the conflict to the display module, and when the operation is cancelled, the resource transaction module sends the RC and the ROA to the display module.

The display module is connected with the resource transaction module, receives the transaction success message or the conflict reason, the operation failure reason and the transaction result when the transaction is unsuccessful from the resource transaction module, and displays the transaction result; and receiving the RC and the ROA from the resource transaction module when the operation is cancelled, and displaying the specific content of the RC and the ROA.

The verification node is a server for verifying resource transactions sent to the block chain by a resource issuer, and a resource certificate transaction intelligent contract is installed on the verification node. The verification node runs an intelligent contract to verify the transaction, verifies whether the signature of the transaction and the content of the transaction accord with the authority of a resource issuer or not, and whether the content of the transaction does not conflict with the currently allocated resource or not, records the transaction passing the verification into a resource transaction success block chain, and records the transaction failing to pass the verification and the reason of the transaction failure into a resource transaction failure block chain.

The resource certificate transaction intelligent contract is jointly established by a resource issuer and a resource receiver and is a commitment defined in a digital form, wherein the digital form means that the contract is a piece of computer-readable code for solving transaction behaviors between the resource issuer and the resource receiver. The commitments and agreements established by the intelligent contracts are executed by a computer or network of computers.

The alarm server is a server for alarming illegal transactions in resource transactions and is connected with the blockchain network. The alarm server is used for monitoring the user to join the block chain network, and a resource certificate transaction alarm module is installed on the alarm server.

And the resource certificate transaction warning module acquires the failure transaction record and reason in the resource transaction failure block chain, analyzes the possibly malicious role according to the reason of the resource transaction failure, and gives a potential malicious risk warning prompt.

And secondly, defining a resource transaction structure.

The resource transaction structure comprises a transaction initiator, a transaction receiver, a transaction type, transaction contents, transaction attributes, transaction evidence and a transaction signature given by the transaction initiator. The transaction initiator refers to the address of the resource issuer, and the transaction receiver is the address of the resource receiver. A transaction signature refers to a digital signature made by a transaction initiator on an initiated transaction in a blockchain network. The transaction types include seven types, respectively: RC issuance, RC revocation, RC updating, RC modification, ROA issuance authorization, ROA revocation and ROA modification. The transaction content is the content of the RC or ROA corresponding to the transaction. The transaction attribute comprises a transfer attribute and an expiration attribute; the transmission attribute indicates whether the IP address resource allocated to a certain organization can be reallocated to another resource authorization entity, the transmission attribute is 0, and indicates that a resource issuer does not want to perform sub-allocation on the IP address prefix resource allocated to the certain organization, at this time, the organization is called a terminal node, the IP address resource and the AS number resource owned by the organization are not subdivided, and only the terminal node can issue ROA; the transfer attribute is 1, which indicates that a resource issuer wishes to sub-allocate the IP address prefix resource allocated to a certain organization; the expiration attribute shows whether the IP address resource has lease period, the expiration attribute is 0 to indicate that the lease time is not expired, the expiration attribute is 1 to indicate that the lease time is expired, and the IP address resource should be released and returned to the original resource authorization entity. The transaction evidence represents signatures of the resource issuer and the resource receiver twice, and the evidence agreed by the two parties consists of messages transacted by the two parties and random numbers (for example, when the RC is revoked, the evidence of the transaction is RC _ revoke _ reply messages and the random number +1 issued by the holder of the RC), so that the risk that a legal IP address is possibly blocked due to a unilateral authorization protocol of the resource issuer in the current RPKI but an attacker or a behavior offender is difficult to find is overcome. The transaction signature given by the transaction initiator shows that the transaction initiator and the transaction recipient have agreed upon the transaction. For ROA operations, since the transaction initiator and the transaction recipient are the same, no evidence of two-way signatures is required. For ROA-related operations transactions, the transaction signature field given by the initiator of the transaction is NULL.

And thirdly, defining a resource tree, wherein the resource tree is constructed by the resource transaction module according to the effective resource certificate RC. One node of the resource tree includes 7 domains, which are: resource issuer, resource receiver, resource certificate, parent certificate identifier, child certificate identifier, ip (internet protocol) address prefix included in the certificate, as (autonomous system) number included in the certificate. The node is linked to the child node through a child certificate identity domain and to the parent node of the node through a parent certificate identity domain. The IP address prefix contained in the certificate and the AS number contained in the certificate are obtained by the resource transaction module through analyzing the certificate. The resource tree is stored in a distributed account book and is commonly maintained by a resource issuer and a resource receiver.

Fourthly, performing bidirectional authorization on resource operation between the resource issuer and the resource receiver by the resource public key infrastructure system RPKIB based on the block chain, and performing transaction corresponding to the resource operation between the resource issuer and the resource receiver after each type of bidirectional authorization passes; when the verification node receives the corresponding transaction message, the verification node runs the resource certificate transaction intelligent contract to verify the corresponding transaction, records the transaction passing the verification into the resource transaction success block chain, and records the transaction failing the verification and the reason of the transaction failure into the resource transaction failure block chain; the resource certificate transaction warning module of the warning server monitors the resource transaction failure block chain, and when the transaction which fails to pass the verification and the reason of the transaction failure are recorded in the resource transaction failure block chain, the warning server analyzes the possibly malicious role according to the reason of the resource transaction failure and gives a potential malicious risk warning prompt; the method comprises the following steps:

4.1 block chain initialization and resource tree initialization:

4.1.1 initializing resource trade success blockchain and resource trade failure blockchain to null.

4.1.2 resource transaction Module initializes the root node of the resource Tree to make the root node V₀: an Internet registration management organization RIR (regional Internet registry) is used as a century creator of a block chain to create a creation block (the first block of the block chain), and a resource certificate owned by the RIR is used as a root node V of a resource tree₀：V₀Resource issuer and resource receiver of (1) are both RIR's IP addresses, V₀The resource certificate of (a) is a resource certificate held by the RIR, V₀Is NULL, V₀Is marked as NULL (because the RIR has not issued a sub-certificate yet), V₀The IP address prefix of the network is the IP address prefix owned by the RIR, and the AS number is the AS number owned by the RIR. Handle V₀And recording the data into the distributed account book.

4.2 the resource transaction module of the resource transaction application client receives a message from the resource issuer, if the resource certificate RC (command RC1) is received, 4.2.1 is switched; if a revocation message of the resource certificate RC (instruction RC2) is received, 4.2.2 is switched to; if a message for updating the resource certificate RC (command RC3) is received, 4.2.3 is switched; if a message relating to RC (order RC4) modification of resource allocation adjustment is received, go to 4.2.4; if a message issued by the ROA (order is ROA1) is received, 4.2.5 is turned; if a message for ROA (command ROA2) revocation is received, go to 4.2.6; if a message modified by ROA (let ROA3) is received, transition 4.2.7:

4.2.1 resource transaction Module now receives RC1 issue message from the resource issuer, RC1 issues message containing IP address of resource receiver (order is IP)_{Receiving 1}) An IP address prefix (order is IP) pre-issued to a resource recipient_{Prefix 1}) An AS number (AS 1), and issues a certificate RC1 by the certificate issuing method described in 4.2.1.1 to 4.2.1.12.

The 4.2.1.1 resource transaction module is provided with an RC1 issuing instruction, and the RC1 issuing instruction comprises IP_{Receiving 1}，IP_{Prefix 1}、AS1。

4.2.1.2 resource transaction module issues the following instructions according to RC 1:

4.2.1.2.1 resource exchangeThe barter module issues IP in the instruction according to RC1_{Prefix 1}And the AS1 searches the resource tree and checks whether the pre-issued RC1 certificate conflicts with the issued RC certificate in the resource tree, wherein the method comprises the following steps:

4.2.1.2.1.1 checking for pre-issued IP_{Prefix 1}And AS1 is not the resource issuer (having its IP address IP)_{Issue 1}) The method comprises the following steps:

4.2.1.2.1.1.1 resource transaction module of resource issuer resolves resource certificate RC held by itself_{Issue a}To obtain RC_{Issue a}The IP address prefix and the AS number contained therein.

4.2.1.2.1.1.2 resource transaction Module of resource issuer checks Pre-issued IP_{Prefix 1}And whether AS1 is contained in the RC_{Issue a}IP address prefix and AS number contained in RC_{Issue a}Containing an IP address prefix and an AS number specifying the pre-issued IP_{Prefix 1}And AS1 are owned by the resource issuer, without conflict, go to 4.2.1.2.1.2; if not included in RC_{Issue a}In, pre-issued IP_{Prefix 1}And AS1 not owned by the resource issuer, conflict, transition 4.2.1.2.1.3;

4.2.1.2.1.2 checking IP contained in a pre-issued RC1 certificate_{Prefix 1}And whether AS1 has been issued, i.e. whether the IP address prefix and AS number contained in the resource certificate that the resource issuer has issued contain an IP address_{Prefix 1}And AS1, if the checking result is 'not issued', turning to 4.2.1.3; if the checking result is' pre-issued IP_{Prefix 1}And AS1 has been issued, creating a conflict ", transition 4.2.1.2.1.4; the specific method comprises the following steps:

4.2.1.2.1.2.1 order node variable V ═ V₀；

4.2.1.2.1.2.2 checking the value in v sub-certificate identification field, if it is NULL, the checking result is "not issued", turning to 4.2.1.3; if not, finding out the node where the resource issuer is located, wherein the method comprises the following steps: obtaining a child node v1 according to the value in the child certificate identification domain of v, and judging whether the value of the resource certificate domain of v1 is the RC1 held by the resource issuer, if so, the node v1 is the node where the resource issuer is located, turning to 4.2.1.2.1.2.4, and if not, turning to 4.2.1.2.1.2.3;

4.2.1.2.1.2.3 where v is v1, turn 4.2.1.2.1.2.2;

4.2.1.2.1.2.4 obtains the child node v2 of v1 through the child certificate identification domain of the v1 node, and the resource transaction module of the resource issuer parses the resource certificate RC held by the child node v2_v2Comparison RC_v2The IP address prefix, AS number and pre-issued IP contained in the same_{Prefix 1}Whether or not it overlaps with AS1, if so, indicates pre-issued IP_{Prefix 1}And AS1 has been issued, creating a conflict, the check result being "Pre-issued IP_{Prefix 1}And AS1 has been issued, creating a conflict ", transition 4.2.1.2.1.4; if there is no overlap, the pre-issued IP is indicated_{Prefix 1}And AS1 has not been issued, the check result is "not issued", go to 4.2.1.3.

4.2.1.2.1.3 the resource transaction module sends the 'resource conflict' message to the display module, the display module displays the 'resource conflict' message, the message contains the reason of the resource conflict (the conflict reason is that the IP address prefix resource and the AS number contained in the pre-issued RC certificate are not owned by the current certificate issuer), and then the fifth step is carried out.

4.2.1.2.1.4 the resource transaction module sends a "resource conflict" message to the display module, which displays the "resource conflict" message containing the reason for the resource conflict (the reason for the conflict is that "the IP address prefix and AS number contained in the pre-issued RC certificate have been issued"), go to 4.2.1.2.2.

4.2.1.2.2 the resource transaction module checks whether the instruction of 'abandoning the transaction' is received from the resource issuer, if so, go to the fifth step; otherwise go to 4.2.1.2.3.

4.2.1.2.3 the resource transaction module determines whether a revocation message (revoking an issued resource that conflicts with the pre-issued RC1) is received from the resource issuer, and if a revocation message is received, revoking an issued RC that conflicts with the pre-issued RC 1; if the revocation message is not received, turning to the fifth step;

4.2.1.3 resource transaction Module issues IP in the instruction to RC1_{Prefix 1}And AS1 to the resource certificate generation module, turn to 4.2.1.4;

4.2.1.4 resource certificate generation Module based on IP received from resource transaction Module_{Prefix 1}And AS1, generating a resource certificate, naming the certificate AS RC 1.

4.2.1.5 resource issuer and resource receiver of RC1 perform bidirectional authorization, which is as follows:

4.2.1.5.1 resource transaction module of resource issuer of RC1 constructs an issuance request message RC _ issue _ request of RC1 based on UDP (User Datagram Protocol), and sends RC _ issue _ request to resource transaction module of resource receiver through blockchain network, where the content of RC _ issue _ request includes issued certificate (here, RC1), parent certificate (certificate owned by resource issuer), random number r, and resource receiver address. The resource issuer of the RC1 initializes the retransmission times m to be 0, starts an issuance request sending timer corresponding to the RC1, and waits for receiving an issuance request response message of the RC1 from the resource receiver;

4.2.1.5.2 the resource issuer of RC1 checks if the issuance request transmission timer has expired, if not, go to 4.2.1.5.3; if the issuance request sending timer is overtime and M is less than the maximum retransmission number M (M is a positive integer and M is less than or equal to 16), increasing M by 1, retransmitting RC _ issue _ request to the resource receiver, restarting the issuance request sending timer corresponding to RC1, and turning to 4.2.1.5.3; if the issuance request sending timer is overtime and M is equal to M, the issuance request fails, the resource issuer deletes RC1, and the resource transaction module sends the operation failure and the reason of the operation failure (the reason is 'sending overtime') to the display module for displaying, turning to the fifth step;

4.2.1.5.3 resource issuer of RC1 determines whether an issuance request reply message RC _ issue _ reply is received from the resource receiver, the contents of RC _ issue _ reply include the received message (RC _ issue _ request), whether the resource issuer operation is granted, and a random number. If not, the resource transaction module of the resource issuer of RC1 sends a failure message and the reason of the operation failure to the display module (because "the issuance request response message sent from the resource receiver is not received"), go to the fifth step; if rc _ issue _ reply is received, checking the format and content of rc _ issue _ reply, if the format is wrong, discarding rc _ issue _ reply, sending a failure message and the reason of operation failure (because the 'format of the issuance request response message is wrong') to the display module by the resource transaction module, and turning to the fifth step; if the format is correct, checking the content of the RC _ issue _ reply message, if the RC _ issue _ reply message is rejected, deleting the RC1 by the resource issuer, sending an operation failure message and a reason of the operation failure to a display module of the resource transaction application client by the resource issuer (because the resource receiver does not agree with the certificate issue), displaying the operation failure message and the reason of the operation failure by the display module, and turning to the fifth step; if it is in rc _ issue _ reply that the operation request is granted, 4.2.1.6 is performed;

4.2.1.6 resource transaction module of resource issuer constructs the transaction message RC _ issue of RC1 according to the resource transaction structure, the content of RC _ issue includes resource issuer (here, issuer of RC), resource receiver (here, receiver of RC1), transaction type (here, issue of RC1), transaction content (here, concrete content of RC1), transaction attribute (including transfer attribute and expiration attribute), transaction evidence (here, RC _ issue _ reply message, random number +1 issued by receiver of RC), signature of transaction by resource issuer of RC1 (transaction signature is that transaction information is encrypted by digital signature technology, which is a valid proof of information authenticity sent by transaction initiator); the resource issuer sends rc _ issue to the resource transaction module and the verification node of the resource receiver through the blockchain network, and the operation is switched to 4.2.1.7;

4.2.1.7 verifying that the node receives rc _ issue from the resource issuer, runs the resource certificate transaction intelligent contract, checks as follows;

4.2.1.7.1 resource certificate transaction Smart contract checks if the resource issuer signature in rc _ issue is correct, checks if rc _ issue is in correct format and has been previously submitted (see if previously submitted by checking the transaction record in the resource transaction success blockchain); if the resource issuer signature is correct and the format of rc _ issue is correct and rc _ issue has not been previously submitted, go to 4.2.1.7.2, if the resource issuer signature is incorrect or the format of rc _ issue is incorrect, then record failure reason is "issuer signature is incorrect or transaction format is incorrect", go to 4.2.1.7.5; if the transaction message issued by the RC1 has been submitted before, the record failure reason is "the transaction message has been submitted before", go to 4.2.1.7.5;

4.2.1.7.2 resource certificate transaction intelligent contract checks whether the transaction evidence (transaction evidence is contained in resource issuance message RC _ issue, which is the random number +1 issued by the resource receiver who sends the issuance request message response RC _ issue _ reply to the resource issuer and the receiver of RC) is correct, that is, checks whether the transaction has the message approved by both parties (resource issuer and resource receiver) participating in the transaction, that is, checks the format and content (whether the resource receiver approves the issuance request) of the resource issuance request reply message RC _ issue _ reply, and whether the random numbers of both parties in the message are not repeated with the random numbers which are received by both parties and stored currently; if the execution is passed 4.2.1.7.3, otherwise the record failure reason is "transaction evidence is incorrect", execution 4.2.1.7.5;

4.2.1.7.3 the resource certificate transaction intelligent contract extracts the transaction content (namely the specific content of RC1) of the transaction message issued by RC1, analyzes the IP address prefix contained in the resource certificate from the transaction content, and checks whether the IP address prefix conflicts with the IP address prefix contained in the resource certificate issued by the resource issuer; if there is no conflict transition 4.2.1.7.4, otherwise the record failure reason is "conflict between pre-issued IP address resources and IP address resources contained in the issued resource certificate", transition 4.2.1.7.5;

4.2.1.7.4 the resource certificate transaction intelligent contract passes the verification, the verification node records the transaction to the resource transaction success block chain, and then the 4.2.1.8 is turned;

4.2.1.7.5 the intelligent contract verification of resource certificate transaction fails, the verification node records the transaction and failure reason to the resource transaction failure block chain;

4.2.1.7.6 the resource certificate transaction warning module monitors the change of the resource transaction failure block chain, reads the failure transaction record and reason newly added in the resource transaction failure block chain, analyzes the possible malicious role, and gives a prompt, specifically as follows:

4.2.1.7.6.1, if the reason of the resource transaction failure is 'the publisher signature is incorrect or the transaction format is wrong', then prompting 'the malicious role is the resource issuer', and turning to the fifth step; otherwise, turning to 4.2.1.7.6.2;

4.2.1.7.6.2, if the reason of the resource transaction failure is that the transaction message has been submitted before, prompting that the malicious role is the resource issuer, and turning to the fifth step; otherwise, turning to 4.2.1.7.6.3;

4.2.1.7.6.3, if the reason of the resource transaction failure is that the transaction evidence is incorrect, prompting that the malicious role is the resource issuer or the resource receiver, and turning to the fifth step; otherwise, turning to 4.2.1.7.6.4;

4.2.1.7.6.4, if the reason of the resource transaction failure is that the pre-issued IP address resource conflicts with the IP address resource contained in the issued resource certificate, prompting that the malicious role is the resource issuer, and turning to the fifth step;

4.2.1.8 if the resource transaction module of the resource receiver receives RC _ issue sent from the resource issuer and obtains the specific transaction content, namely the RC1 resource certificate, from the transaction content field of RC _ issue, the transaction is successful, and 4.2.1.9 is turned; if the resource transaction module of the resource receiver does not receive RC _ issue or the transaction content obtained from the transaction content domain of RC _ issue is not the RC1 resource certificate, turning to 4.2.1.10;

4.2.1.9 resource transaction Module of resource receiver creates a new node (named RC1 node) for the resource tree by:

4.2.1.9.1 update a certificate RC held by a parent node of the RC1 node, i.e., the resource issuer_{Issue a}The information of the node where the node is located adds a sub-certificate identifier in the sub-certificate identifier field, and the sub-certificate identifier points to the new node RC1 node.

4.2.1.9.2 create a new node RC1 and populate the information for each domain: the resource issuer domain of the RC1 node is the IP address IP of the resource issuer of the RC1_{Issue 1}The resource recipient domain is the IP address IP of the resource recipient of RC1_{Receiving 1}The content of the resource certificate domain is RC1, and the parent certificate identification domain points to the resource certificate RC held by the resource issuer of RC1_{Issue a}The node is located, the sub-certificate identification field is NULL, and the current nodeA sub-certificate has not yet been issued and the IP address prefix and AS number contained in the certificate are resolved by resource transaction module RC 1.

4.2.1.9.3 sends a transaction success message to the resource transaction module of the resource issuer, turn 4.2.1.11;

4.2.1.10 the resource transaction module of the resource recipient sends a transaction failure message to the resource transaction module of the resource issuer, block 4.2.1.12.

4.2.1.11 if the resource transaction module of the resource issuer of RC1 receives the transaction success message sent from the resource transaction module of the resource receiver, the resource transaction module of the resource issuer of RC1 sends the transaction success message to the display module, the display module displays the transaction success, and the fifth step is carried out;

4.2.1.12 if the resource transaction module of the resource issuer of the RC1 receives the transaction failure message sent from the resource transaction module of the resource receiver, the resource issuer of the RC1 deletes the node where the RC1 certificate is located in the resource tree, and at the same time, the resource transaction module of the resource issuer of the RC1 sends the "operation failure" message and the reason of the operation failure (because the RC1 certificate is not correctly received) to the display module, which displays the "operation failure" message and the reason of the operation failure, and goes to the fifth step.

4.2.2 at this time, the resource transaction module of the resource transaction application client receives a message of RC (order of RC2) revocation from the resource issuer, the message of RC2 revocation includes a holder of the RC resource certificate (as a resource receiver), a pre-revocation resource certificate RC, and the certificate revocation method according to 4.2.2.1-4.2.2.8 revokes the certificate RC 2:

4.2.2.1 resource transaction module of resource issuer sets up canceling RC2 command according to the message of RC2 canceling, canceling RC2 command includes holder of RC resource certificate (as resource receiver) and pre-cancelled resource certificate RC2, and sends specific content of RC2 to display module, which displays specific content of RC 2;

4.2.2.2 resource issuer performs two-way authorization with the holder of the pre-revoked RC2 certificate (as the resource receiver) by:

4.2.2.2.1 resource issuer's resourceThe transaction module checks the node where RC2 certificate resides (let V be_rc2) Whether the resource tree belongs to a leaf node or not is determined by the following steps:

4.2.2.2.1.1 let variable node V be the root node V of resource tree₀；

4.2.2.2.1.2 finding node V_rc2The method comprises the following steps: obtaining a child node V1 according to the value in the V child certificate identification domain, judging whether the value of the V1 resource certificate domain is the RC2 held by the resource issuer, if the value is equal, the node V1 is the V1_rc2Turning to 4.2.2.2.1.4, if not equal, turning to 4.2.2.2.1.3;

4.2.2.2.1.3 let v be the child certificate of v to identify the child node pointed to (i.e., v 1); turning to 4.2.2.2.1.2;

4.2.2.2.1.4 inspection V_rc2If the sub-certificate mark is null, V_rc2For leaf nodes, branch 4.2.2.2.2 performs a specific undo operation; if V_rc2If the sub-certificate identification of (2) is not null, go to 4.2.2.2.1.5;

4.2.2.2.1.5 at this point V_rc2Not a leaf node, but waiting for the certificate holder to revoke node V_rc2The lower resource subtree can revoke the node V_rc2Execution 4.2.2.2.1.6;

4.2.2.2.1.6 order V_rc2Is a V_rc2Identifies the child node pointed to, turn 4.2.2.2.1.4;

4.2.2.2.2 the resource trading module of the resource issuer constructs a revocation message RC _ revoke _ request of the RC2 based on UDP, the content of RC _ revoke _ request includes an identifier of a certificate to be revoked (in this case, an identifier of RC2), a random number r, and an address of a certificate holder (i.e., a resource receiver), and the resource trading module of the resource issuer sends RC _ revoke _ request to the resource trading module of the resource receiver (in this case, a holder of RC 2); the resource issuer initializes the second retransmission number m2 to 0, and starts a revocation request sending timer corresponding to the RC 2;

4.2.2.2.3 the resource issuer of the RC2 checks if the revocation request transmission timer has expired, if not, go to 4.2.2.2.4; if the revocation request sending timer is overtime and M2 is less than the maximum retransmission number M, increasing M2 by 1, retransmitting RC _ revoke _ request to the resource transaction module of the resource receiver, starting an issuance request sending timer corresponding to RC2 by the resource issuer, and turning to 4.2.2.2.4; if M2 is equal to M, the revocation request fails, the resource transaction module of the resource issuer sends 'operation failure' and the reason of the operation failure to the display module (the reason is 'revocation request message sending timeout'), the display module displays the 'operation failure' and the reason of the operation failure, and the fifth step is executed.

4.2.2.2.4 the resource trading module of the resource issuer of RC2 determines whether receiving the revocation request response message RC _ revoke _ reply sent from the resource trading module of the resource receiver, where RC _ revoke _ reply includes the message (RC _ revoke _ request) received by the resource receiver, whether granting the resource issuer operation, and the random number. If not, the resource transaction module of the resource issuer sends a failure message and the reason of the operation failure to the display module (because the reason is that the revocation request response message sent from the resource receiver is not received), turning to the fifth step; if rc _ revoke _ reply is received, checking the format and content of rc _ revoke _ reply, if the format is wrong, discarding the message, sending a failure message and the reason of operation failure to the display module (because the reason is that the format of the revocation request response message sent by the resource receiver is wrong), and turning to the fifth step; if the format is correct, checking response information in rc _ revoke _ reply, if the request is refused to revoke the operation, sending ' operation failure ' and the reason of the operation failure to the display module by the resource transaction module (because the ' certificate holder does not agree with the certificate revocation), displaying the ' operation failure ' and the reason of the operation failure by the display module, and going to the fifth step; if the operation request is approved to be withdrawn, 4.2.2.3 is carried out;

4.2.2.3RC2, based on the identity of RC2, the resource transaction module of the resource issuer checks whether the node (say v1) where RC2 is located is a leaf node in the resource tree (i.e., determines whether the value of the child certificate identification field of v1 is NULL), and if v1 is a leaf node (i.e., the value of the child certificate identity of v1 is NULL), go to 4.2.2.4; if v1 is not a leaf node, it indicates that the owner of RC2 has not completely deleted the resource subtree of RC2, RC2 does not meet the revocation condition, "operation failure" and the reason for the operation failure (because "the owner of RC2 returns an RC revocation agreement request without revoking the child resources, violates the agreement rules or is attacked"), the display module displays "operation failure" and the reason for the operation failure, go to the fifth step;

4.2.2.4 resource transaction module of resource issuer of RC2 constructs the revocation transaction message RC _ revoke of RC2 according to the resource transaction structure, where RC _ revoke includes resource issuer (here, issuer of RC2), transaction receiver (here, holder of RC2), transaction type (here, RC revoke), transaction content (here, concrete content of RC2), transaction attribute (here, null), proof of transaction (here, random number +1 issued by holder of RC _ revoke _ reply message, RC2), signature of transaction by resource issuer of RC 2; the resource transaction module of the resource issuer sends the rc _ revoke to the resource transaction module and the verification node of the resource receiver through the blockchain network, and the conversion is 4.2.2.5;

4.2.2.5 the authentication node receives rc _ revoke from the resource issuer, the resource certificate transaction smart contract is checked as follows;

4.2.2.5.1 resource certificate transaction Smart contract checks if the resource issuer signature in rc revoke is correct, checks if rc revoke is in the correct format and has been previously committed (by checking the transaction record in the resource transaction success blockchain to see if it has been previously committed); if the resource issuer signature is correct and the transaction message format is correct and the RC2 cancellation transaction message has not been submitted before, execute 4.2.2.5.2, if the resource issuer signature is incorrect or the resource cancellation transaction message format is incorrect, record failure reason is "issuer signature is incorrect or transaction format is wrong", execute 4.2.2.5.5; if rc _ revoke has been submitted before, record failure reason is "the transaction message has been submitted before", go to 4.2.2.5.5;

4.2.2.5.2 the resource certificate transaction intelligent contract checks whether the evidence of transaction revocation (the transaction evidence is contained in the certificate revocation message RC _ revoke, which is the revocation request message RC _ revoke _ reply issued by the resource receiver to the resource issuer, and the random number +1 issued by the receiver of RC) is correct, that is, checks whether the transaction has a message approved by both parties participating in the transaction (i.e. checks the format and content of the revocation request reply message RC _ revoke _ reply) (whether the resource receiver approves the revocation operation request), whether the random numbers of both parties in the message are not duplicated with the currently stored random numbers that both parties have already received; if the execution is passed 4.2.2.5.3, otherwise the record failure reason is "transaction evidence is incorrect", execution 4.2.2.5.5;

4.2.2.5.3 resource certificate trading intelligence contract queries resource trading success block chain, checks whether RC2 has been issued, i.e. the issued resource certificate RC2 can be queried in the resource trading success block chain, if passing the check (i.e. there is an already issued RC2 in the resource trading success block chain), executes 4.2.2.5.4, otherwise records failure reason because "pre-revoked resource certificate RC2 does not exist"; 4.2.2.5.5 is executed;

4.2.2.5.4 the resource certificate transaction intelligent contract passes the verification, the verification node records the transaction to the resource transaction success block chain, and then the 4.2.2.6 is turned;

4.2.2.5.5 the intelligent contract verification of resource certificate transaction fails, the verification node records the transaction and failure reason to the resource transaction failure block chain; turning to 4.2.2.5.6;

4.2.2.5.6 the resource certificate transaction warning module monitors the change of the resource transaction failure block chain, reads the failure transaction record and reason newly added in the resource transaction failure block chain, analyzes the possible malicious role, and gives a prompt, specifically as follows:

4.2.2.5.6.1 if the reason of resource transaction failure is 'publisher signature is incorrect or transaction format is wrong', prompting 'malicious role is resource issuer', turning to the fifth step, otherwise, turning to 4.2.2.5.6.2;

4.2.2.5.6.2, if the reason of the resource transaction failure is that the transaction message has been submitted before, prompting that the malicious role is the resource issuer, turning to the fifth step, otherwise, turning to 4.2.2.5.6.3;

4.2.2.5.6.3, if the reason of the resource transaction failure is that the transaction evidence is incorrect, prompting that the malicious role is the resource issuer or the resource receiver, turning to the fifth step, otherwise, turning to 4.2.2.5.6.4;

4.2.2.5.6.4, if the reason of the resource transaction failure is that the pre-revoked resource certificate RC2 does not exist, prompting that the malicious role is the resource issuer, and turning to the fifth step;

4.2.2.6 the resource trading module of the resource receiver performs a delete operation based on the type of trade in RC _ revoke (this is RC revoke) and the content of the trade, deleting the resource certificate RC2 while modifying the resource tree: the node v1 where the RC2 is located is deleted, and the child certificate identity pointing to the node v1 in the child certificate identity field in the v1 parent node is deleted. At which point the transaction is successful. The resource transaction module of the resource receiver sends a transaction success message to the resource transaction module of the resource issuer, and the operation is switched to 4.2.2.7; otherwise, a transaction failure message is sent to the resource transaction module of the resource issuer, and 4.2.2.8 is turned to.

4.2.2.7 if the resource transaction module of the RC2 resource issuer receives the successful transaction message sent from the resource transaction module of the resource receiver, the resource transaction module sends the successful transaction to the display module, the display module displays the successful transaction, and the fifth step is carried out;

4.2.2.8 if the resource issuer receives the transaction failure message, sending 'operation failure' to the display module, prompting the reason of the operation failure (because of 'resource deletion failure'), displaying 'operation failure' and the reason of the operation failure by the display module, and turning to the fifth step.

4.2.3 at this time, the resource transaction module of the resource transaction application client receives RC (order is RC3) expiration time modification, RC3 update messages such as certificate serial number and the like which do not relate to public and private keys and resource allocation from the resource issuer, and updates the certificate RC3 according to the certificate update method of 4.2.3.1-4.2.3.7:

4.2.3.1 resource transaction module of resource issuer of RC3 sets RC3 updating instruction, the content of RC3 updating instruction includes identification of RC3, holder of RC3 resource certificate, RC3 which are currently valid, and attribute value (including certificate expiration time and integer serial number) which can be changed by updating operation, if attribute value to be updated does not conform to value range (if RC3 expiration time is earlier than current expiration time value of RC3), error information is sent to display module, attribute value to be updated is reset, 4.2.3.2 is turned.

4.2.3.2RC3 performs two-way authorization with the holder of the RC3 certificate resource (as the resource receiver), as follows:

4.2.3.2.1 the resource transaction module of the resource issuer of the RC3 constructs an update request message RC _ override 1_ request of the RC3 based on UDP, the content of RC _ override 1_ request includes a certificate identifier to be updated, a random number r, and a certificate holder ID, and the resource transaction module of the resource issuer sends the update request message RC _ override 1_ request of the RC3 to the resource transaction module of the certificate holder through a blockchain network; the resource transaction module of the resource issuer initializes the third retransmission number m3 to 0, and starts an update request sending timer corresponding to the RC3 for the RC 3;

4.2.3.2.2 the resource transaction module of the resource issuer of RC3 checks whether the update request transmission timer of RC3 has expired, if not, go to 4.2.3.2.3; if the update request transmission timer of RC3 times out and M3 is less than the maximum number of retransmissions M, then increment M3 by 1, the resource transaction module of the resource issuer retransmits RC _ override 1_ request of RC3, starts the update request transmission timer of RC3, go 4.2.3.2.2; if the update request sending timer of the RC3 is overtime and M3 is equal to M, the update request of the RC3 fails, and the operation failure and the reason of the operation failure (because the update request message fails to be sent and is overtime) are sent to the display module, and the display module displays the operation failure and the reason of the operation failure, and then the fifth step is executed.

4.2.3.2.3 the resource transaction module of the resource issuer of RC3 determines if an update request reply message RC _ override 1_ reply of RC3 is received from the resource transaction module of the certificate holder, the contents of RC _ override 1_ reply including the message received by the resource receiver (RC _ override 1_ request), whether the resource issuer operation is granted, a random number. If not, the resource transaction module of the resource issuer sends 'operation failure' and reason to the display module (because 'the update request response message sent from the resource transaction module of the resource receiver is not received'), and then the fifth step is carried out; if rc _ overhead 1_ reply is received, the format and content of rc _ overhead 1_ reply are checked, if the format is wrong, the message is discarded, the resource transaction module of the resource issuer sends 'operation failure' and the reason (because 'the format of the update request response message is wrong') to the display module, and then the fifth step is executed; if the format is correct, checking rc _ override 1_ reply, if the operation request is refused to be updated, sending ' operation failure ' and the reason of the operation failure (because the ' certificate holder does not agree with the operation) to the display module, displaying the ' operation failure ' and the reason of the operation failure by the display module, and going to the fifth step; if the rc _ overhead 1_ reply response message is to approve the operation request, then 4.2.3.3 is executed;

4.2.3.3RC3, the resource trading module of the resource issuer constructs an update message RC _ override 1 of RC3 according to the resource trading structure, where RC _ override 1 includes the resource issuer (the issuer of RC3 in this case), the resource receiver (the holder of RC3 in this case), the trading type (the RC3 in this case), the trading content (the new RC 3' content (the content after the RC3 certificate to be updated is updated), the trading attributes (including transfer attributes and expiration attributes), the proof of the trade (the RC _ override 1_ reply message in this case, the random number +1 issued by the holder of RC3 in this case), the resource issuer of RC3 signs the trade, the resource trading module of RC3 sends RC _ override 1 to the resource trading module and the verification node of the resource receiver through the block chain network, and 4.2.3.3.4.3;

4.2.3.4 the validation node receives RC _ override 1 (modify expiration time or certificate sequence number) from the resource issuer of RC3, the resource certificate transaction Smart contract checks as follows;

4.2.3.4.1 resource certificate transaction Smart contract checks if the resource issuer signature in rc _ override 1 is correct, checks if the format of resource certificate update transaction message rc _ override 1 sent from the resource issuer is correct and has been submitted before (check if the transaction record in the resource transaction success Block chain has been submitted before); if the resource issuer signature is correct and the transaction message format is correct, and the resource certificate RC update transaction message RC _ override 1 has not been submitted before, execute 4.2.3.4.2, if the resource issuer signature is incorrect or the resource update transaction message format is incorrect, the record failure reason is "issuer signature is incorrect or transaction message format is incorrect", execute 4.2.3.4.5; if the resource certificate has been submitted before updating the transaction message, the record failure reason is that "the transaction message has been submitted before", go to 4.2.3.4.5;

4.2.3.4.2 the resource certificate transaction intelligent contract checks whether the transaction evidence (the transaction evidence is contained in the resource modification transaction message RC _ override 1, which is the random number +1 issued by the receiver of the modification request response message RC _ override 1_ reply and RC issued by the resource receiver to the resource issuer) is correct, that is, whether the transaction has a message approved by both parties participating in the transaction (the format and content of the update request response message RC _ override 1_ reply are checked (whether the resource receiver approves the modification operation request)), and whether the random numbers of both parties in the message are not repeated with the currently stored random numbers which have been received by both parties; if the execution is passed 4.2.3.4.3, otherwise the record failure reason is "transaction evidence is incorrect", execution 4.2.3.4.5;

4.2.3.4.3 resource certificate trading intelligent contract inquires resource trading success block chain, checks whether resource certificate RC3 has been issued, i.e. the issued resource certificate RC3 can be inquired on the resource trading success block chain, if the check is passed (i.e. there is RC3 already issued), executes 4.2.3.4.4, otherwise records failure reason because "pre-modified resource certificate RC3 does not exist"; 4.2.3.4.5 is executed;

4.2.3.4.4 the resource certificate transaction intelligent contract passes the verification, the verification node records the transaction to the resource transaction success block chain, and then the 4.2.3.5 is turned;

4.2.3.4.5 the resource certificate transaction intelligent contract fails to verify, the verification node sends the transaction record containing the failure reason to the resource transaction failure block chain; turning to 4.2.3.4.6;

4.2.3.4.6 the resource certificate transaction warning module monitors the change of the resource transaction failure block chain, reads the failure transaction record and reason newly added in the resource transaction failure block chain, analyzes the possible malicious role, and gives a prompt, specifically as follows:

4.2.3.4.6.1 if the reason of resource transaction failure is 'publisher signature is incorrect or transaction format is wrong', prompting 'malicious role is resource issuer', turning to the fifth step, otherwise, turning to 4.2.3.4.6.2;

4.2.3.4.6.2, if the reason of the resource transaction failure is that the transaction message has been submitted before, prompting that the malicious role is the resource issuer, turning to the fifth step, otherwise, turning to 4.2.3.4.6.3;

4.2.3.4.6.3, if the reason of the resource transaction failure is that the transaction evidence is incorrect, prompting that the malicious role is the resource issuer or the resource receiver, turning to the fifth step, otherwise, turning to 4.2.3.4.6.4;

4.2.3.4.6.4 if the reason for the resource transaction failure is that the pre-modified resource certificate RC3 does not exist, prompting that the malicious role is the resource issuer to go to the fifth step;

4.2.3.5 if the resource transaction module of the resource receiver replaces the RC3 to be updated with the RC 3' according to the transaction type (update) and the transaction content in the RC _ override 1, at this time, the transaction is successful, the resource transaction module of the resource receiver modifies the resource tree: modifying the information of the resource certificate domain of the node where the resource certificate RC3 is located, namely replacing the resource certificate domain (information of RC3 before modification) with the information of RC 3', simultaneously sending a transaction success message to the resource transaction module of the resource issuer by the resource transaction module of the resource receiver, and turning to 4.2.3.6; otherwise, a transaction failure message is sent to the resource transaction module of the resource issuer, transitioning to 4.2.3.7.

4.2.3.6 if the resource transaction module of the resource issuer of RC3 receives the successful transaction message sent from the resource transaction module of the resource receiver and sends the transaction success to the display module, the display module displays the transaction success, and the fifth step is carried out;

4.2.3.7 if the resource issuer of RC3 receives the transaction failure message, it sends the operation failure and the reason of the operation failure to the display module (because the resource receiver fails to modify the certificate), and the display module displays the operation failure and the reason of the operation failure, going to the fifth step.

4.2.4 at this time, the resource transaction module of the resource transaction application client receives a message of RC (command RC4) modification related to resource allocation adjustment from the resource issuer, the resource transaction module of the resource issuer needs to revoke the old certificate RC4, and issues a new certificate (command RC5) according to the modification message setting, by:

4.2.4.1 revoke RC4 by the certificate revocation method described in 4.2.2;

4.2.4.2 issuing a new certificate (instruction RC5) according to the modification message setting, and issuing RC5 according to the certificate issuing method of 4.2.1; and turning to the fifth step.

4.2.5 at this time, the resource transaction module of the resource transaction client receives a message issued by the ROA (order is ROA1) from the resource issuer, and issues ROA1 according to the ROA issuing method of 4.2.5.1-4.2.5.8:

4.2.5.1ROA1 resource transaction module sets ROA1 to issue instructions, and ROA1 issues instructions including pre-issued IP address prefix and AS number;

4.2.5.2 the resource transaction module of the resource issuer of the ROA1 checks whether the IP address prefix and AS number contained in the ROA1 are owned by the resource issuer of the ROA1, i.e. whether the IP address prefix and AS number contained in the pre-issued ROA1 are contained in the IP address prefix and AS number bound by the resource certificate held by the resource issuer of the ROA1, according to the IP address prefix and AS number in the ROA1 issuance directive, if not, conflict, go to 4.2.5.2.2, if contain, no conflict, go to 4.2.5.2.1;

4.2.5.2.1ROA1 resource transaction module checks whether the pre-issued IP address prefix and AS number resources have been issued, queries the transaction record of ROA1 resource issuer ROA recorded in the resource transaction success block chain to obtain all ROAs issued by ROA1 resource issuer, compares whether the IP address prefix and AS number contained in all the issued ROAs overlap with the pre-issued IP address prefix and AS number, if so, conflicts (indicating that the resource has been issued) occur, and then 4.2.5.2.3 is turned; if not, go to 4.2.5.3;

4.2.5.2.2ROA1 resource transaction module sends ' operation failure ' message and reason to display module (the reason is ' resource conflict, the IP address prefix and AS number resource held by resource issuer do not contain the IP address prefix and AS number contained in the pre-issued ROA), the display module displays ' operation failure ' message, the message contains the reason of operation failure, go to the fifth step.

4.2.5.2.3ROA1 resource transaction module sends an "operation failure" message to the display module, the message including the reason for the operation failure, along with the reason (for the reason that "the IP address prefix and AS number included in the pre-issued ROA have been issued"), the display module displays an "operation failure" message, go to 4.2.5.2.4;

4.2.5.2.4ROA1 resource transaction module checks whether a command of 'abandoning the transaction' is received from the resource issuer, if yes, go to the fifth step, otherwise go to 4.2.5.2.5;

4.2.5.2.5 the resource transaction module of the resource issuer of the ROA1 determining whether a revocation message (revoking an issued ROA that conflicts with ROA1) was received from the resource issuer, and if a revocation message was received, revoking an issued ROA that conflicts with the pre-issued ROA1, block 4.2.5.2; and if the revocation message is not received, turning to the fifth step.

4.2.5.3 if no conflict occurs, the resource transaction module of the resource issuer of the ROA1 sends the IP address prefix and the AS number in the ROA1 issuance instruction to the resource certificate generation module of the resource issuer; the resource certificate generation module of the resource issuer generates ROA1 from the contents of the issuance instruction (IP address prefix, AS number) of ROA 1.

4.2.5.4 the resource transaction module of the resource issuer of the ROA1 constructs an issuance transaction message ROA _ issue of the ROA1 according to the defined resource transaction structure, wherein ROA _ issue includes a resource issuer (in this case, the issuer of the ROA1), a resource receiver (in this case, the receiver of the ROA1), a transaction type (in this case, the issuer of the ROA1), transaction contents (in this case, the specific contents of the ROA1), transaction attributes (including a transfer attribute, which is null, and indicates whether the ROA has a deadline), evidence of the transaction (in this case, it is null), and a signature of the transaction by the resource issuer of the ROA 1; the resource transaction module of the resource issuer of the ROA1 sends an issuance transaction message ROA _ issue of the ROA1 to the resource receiver and the verification node through the blockchain network, and then the process goes to 4.2.5.5;

4.2.5.5 verifying that the node receives ROA _ issue from the resource issuer of ROA1, the resource certificate transaction intelligent contract checks as follows;

4.2.5.5.1 resource certificate transaction Smart contract checks if the resource issuer signature in roa _ issue is correct, checks if the format of roa _ issue is correct and has been previously submitted (by checking the transaction records in the resource transaction success blockchain to see if previously submitted); if the resource issuer signature is correct and the transaction message format is correct and the ROA1 has not submitted the transaction message before issuing the transaction message, executing 4.2.5.5.2, if the resource issuer signature is incorrect or the resource issuer transaction message format is incorrect, recording that the failure reason is 'issuer signature is incorrect or transaction format is wrong', executing 4.2.5.5.4; if the transaction message issued by the ROA1 was previously submitted, the record failure reason is "the transaction message was previously submitted", go to 4.2.5.5.4;

4.2.5.5.2 resource certificate transaction intelligent contract extracts the IP address prefix contained in the transaction content (namely the concrete content of ROA1) in the issued transaction message ROA _ issue submitted by the resource issuer of ROA1, and checks whether the IP address prefix is already issued by the resource issuer, the method is: inquiring transaction records of ROA issued by a resource issuer of ROA1 recorded in a resource transaction success block chain to obtain all ROAs issued by the resource issuer of ROA1, comparing whether IP address prefixes contained in all the issued ROAs are overlapped with pre-issued IP address prefixes, and if so, generating conflict; record failure reason is "pre-issued IP geological resources conflict with IP address resources contained in issued ROA", transfer 4.2.5.5.4; if not, go to 4.2.5.5.3;

4.2.5.5.3 the resource certificate transaction intelligent contract passes the verification, the verification node records the transaction to the resource transaction success block chain, and then the 4.2.5.6 is turned;

4.2.5.5.4 the resource certificate transaction intelligent contract fails to verify, the verification node sends the transaction record containing the failure reason to the resource transaction failure block chain; turning to 4.2.5.5.5;

4.2.5.5.5 the resource certificate transaction warning module monitors the change of the resource transaction failure block chain, reads the failure transaction record and reason newly added in the resource transaction failure block chain, analyzes the possible malicious role, and gives a prompt, specifically as follows:

4.2.5.5.5.1 if the reason of resource transaction failure is 'publisher signature is incorrect or transaction format is wrong', prompting 'malicious role is resource issuer', turning to the fifth step, otherwise, turning to 4.2.5.5.5.2;

4.2.5.5.5.2, if the reason of the resource transaction failure is that the transaction message has been submitted before, prompting that the malicious role is the resource issuer, turning to the fifth step, otherwise, turning to 4.2.5.5.5.3;

4.2.5.5.5.3, if the reason of the resource transaction failure is that the pre-issued IP geological resource conflicts with the IP address resource contained in the issued ROA, prompting that the malicious role is the resource issuer, and turning to the fifth step;

4.2.5.6 if the resource transaction module of the resource receiver parses the transaction type (here, issued by ROA1) and the transaction content (the specific content of ROA1) from ROA _ issue, at this time, the transaction is successful, the resource transaction module of the resource receiver sends a transaction success message to the resource transaction module of the resource issuer, and then 4.2.5.7 is carried out; if the transaction is unsuccessful, the resource transaction module of the resource receiver sends a transaction failure message to the resource transaction module of the resource issuer, block 4.2.5.8.

4.2.5.7 if the resource issuer of ROA1 receives the successful transaction message from the resource receiver, it sends the transaction success to the display module, the display module displays the transaction success, and goes to the fifth step;

4.2.5.8 if the resource issuer of the ROA1 receives the transaction failure message from the resource receiver, the resource transaction module of the resource issuer of the ROA1 deletes the ROA1 and sends the operation failure message and the reason of the operation failure to the display module (because the resource receiver fails to acquire the transaction content), the display module displays the operation failure and the reason of the operation failure, and the fifth step is carried out.

4.2.6 when the resource trading module of the resource trading client receives the message of canceling the ROA (order is ROA2) from the resource issuer, canceling the ROA2 according to the ROA canceling method of 4.2.6.1-4.2.6.6:

4.2.6.1ROA2 resource trading module of resource issuer's resource trading application client sets a ROA2 cancel command, the ROA2 cancel command includes ROA2 holder and ROA2 identifier, and sends ROA2 concrete content to the display module, the display module displays ROA2 concrete content;

4.2.6.2 the resource trading module of the resource issuer of the ROA2 constructs a revoke trading message ROA _ revoke of the ROA2 according to the defined resource trading structure, wherein the ROA _ revoke content includes a resource issuer (at this time, the issuer of the ROA2), a resource receiver (at this time, the holder of the ROA2), a trading type (at this time, the ROA2 revoke), a trading content (at this time, the identifier of the ROA2), a trading attribute (at this time, null), and a trading evidence (at this time, null); signing the transaction by the resource issuer of the ROA2, sending ROA _ revoke to the resource transaction module and the verification node of the resource receiver through the blockchain network by the resource transaction module of the resource issuer, go to 4.2.6.3;

4.2.6.3. the authentication node receives ROA _ revoke from the resource issuer of ROA2, and the resource certificate transaction smart contract checks as follows;

4.2.6.3.1 resource certificate deal intelligence contract checks whether the resource issuer signature in roa _ revoke is correct, checks whether the format of roa _ revoke is correct and has been previously committed (by checking the transaction record in the resource deal success blockchain to see if it has been previously committed); if the resource issuer signature is correct and the transaction message format is correct and the ROA2 has not been submitted before revoking the transaction message, execute 4.2.6.3.2, if the resource issuer signature is incorrect or the resource revocation transaction message format is incorrect, record the failure reason is "issuer signature is incorrect or transaction format is wrong", execute 4.2.6.3.4; if the ROA2 has already submitted the transaction message before revoking, the record failure reason is "the transaction message has already been submitted before", go to 4.2.6.3.4;

4.2.6.3.2 resource certificate transaction Smart contract queries resource transaction success blockchain, checks if ROA2 has been issued, i.e. issued ROA2 can be queried on the resource transaction success blockchain, if it passes the check (i.e. there is already issued ROA2) then 4.2.6.3.3 is executed; otherwise the recording failure reason is "pre-revoked ROA2 not present", execute 4.2.6.3.4;

4.2.6.3.3 the resource certificate transaction intelligent contract passes the verification, the verification node records the transaction to the resource transaction success block chain, and then the 4.2.6.4 is turned;

4.2.6.3.4 the resource certificate transaction intelligent contract fails to verify, the verification node sends the transaction record containing the failure reason to the resource transaction failure block chain; turning to 4.2.6.3.5;

4.2.6.3.5 the resource certificate transaction warning module monitors the change of the resource transaction failure block chain, reads the failure transaction record and reason newly added in the resource transaction failure block chain, analyzes the possible malicious role, and gives a prompt, specifically as follows:

4.2.6.3.5.1 if the reason of resource transaction failure is 'publisher signature is incorrect or transaction format is wrong', prompting 'malicious role is resource issuer', turning to the fifth step, otherwise, turning to 4.2.6.3.5.2;

4.2.6.3.5.2, if the reason of the resource transaction failure is that the transaction message has been submitted before, prompting that the malicious role is the resource issuer, turning to the fifth step, otherwise, turning to 4.2.6.3.5.3;

4.2.6.3.5.3 if the reason of the resource transaction failure is that the pre-revoked ROA2 does not exist, prompting that the malicious role is the resource issuer, and turning to the fifth step;

4.2.6.4 if the resource transaction module of the resource receiver parses the transaction type (here, ROA2 revoked) and the transaction content (the specific content of ROA2) from ROA _ revoke, the resource transaction module of the resource receiver deletes ROA2, and when the transaction is successful, the resource transaction module of the resource receiver sends a transaction success message to the resource transaction module of the resource issuer, turning to 4.2.6.5; if the transaction is unsuccessful, the resource transaction module of the resource receiver sends a transaction failure message to the resource transaction module of the resource issuer, block 4.2.6.6.

4.2.6.5 if the resource transaction module of the resource issuer receives the successful transaction message sent from the resource receiver, the resource receiver resource transaction module deletes the ROA2 and sends the transaction success to the display module, the display module displays the transaction success, and the fifth step is carried out;

4.2.6.6 if the resource transaction module of the resource issuer receives the transaction failure message, it sends the notification of the operation failure and the reason of the operation failure to the display module (because "the resource receiver fails to delete ROA 2"), the display module displays "the operation failure" and the reason of the operation failure, and goes to the fifth step.

4.2.7 at this time, when the resource transaction module of the resource transaction application client receives the instruction of modifying the ROA (instruction ROA3) from the resource issuer, the resource transaction module of the resource issuer of ROA3 needs to cancel ROA3, generate a new ROA3 'according to the modified content, and issue a new ROA 3', the method is:

4.2.7.1 canceling ROA3 according to 4.2.6 said ROA canceling method:

4.2.7.2 generating a new ROA3 'according to the modified contents, issuing ROA 3' according to the ROA issuing method of 4.3.5, and turning to the fifth step;

and fifthly, turning to 4.2, the resource transaction module of the resource transaction application client waits for receiving the next message from the resource issuer to perform the next transaction.

Description of the drawings: 4.2.1.2.3, when a revocation message is received (revoking a resource certificate that conflicts with pre-issued RC1), the revocation method employed to revoke an issued RC that conflicts with pre-issued RC1 is the same as described in 4.2.2. 4.2.5.2.5, when receiving a ROA1 revocation message (revoking an issued ROA that conflicts with ROA1), revoking an issued ROA that conflicts with pre-issued ROA1 is the same as that described in 4.2.6.

The invention can achieve the following technical effects:

1. the invention discloses a resource transaction warning method of an RPKI constructed on a block chain, which effectively improves the safety of the RPKI based on the block chain. Through the addition of the alarm server, if various resource transaction operations initiated by the resource issuer generate resource conflict in the block chain transaction or the resource issuer submits illegal transaction, and the resource issuer and the resource receiver conspire to carry out illegal transaction, the resource certificate transaction alarm module sends alarm information according to specific reasons and gives out possible malicious roles according to the transaction failure reasons. The condition that the alarm system is lacked in the conventional RPKI system and errors are generated in the operation of various resources without self-knowledge is remedied.

2. The invention uses the block chain technology, and because of the fault tolerance of the block chain network, the fault of the whole block chain network can not be caused after some nodes go wrong, so that the RPKIB constructed in the first step also has certain fault tolerance.

Drawings

FIG. 1 is a general structure diagram of a transaction verification system RPKIB based on a resource public key infrastructure of a block chain constructed in the first step of the invention;

FIG. 2 is a block diagram of a resource transaction structure according to a second step of the present invention;

FIG. 3 is a structural diagram of a resource tree according to a third step of the present invention;

fig. 4 is an overall flow chart of the present invention.

Detailed Description

Fig. 4 is an overall flow chart of the present invention. As shown in fig. 4, the present invention comprises the steps of:

firstly, constructing a resource public key infrastructure RPKIB system. The resource public key infrastructure RPKIB system is shown in fig. 1 and comprises a resource issuer, a resource transaction application client, a resource receiver, a blockchain network, a verification node and an alarm server.

And the block chain network is connected with the resource issuer, the resource receiver, the alarm server and the verification node. And the resource issuer, the resource receiver and the alarm server are connected with the block chain network to form a common node of the block chain network. The verification node is another node different from the common node in the block chain network, is a server for verifying resource transaction initiated by a resource issuer, and is provided with a resource certificate transaction intelligent contract. The resource issuer and the resource receiver take various operations of the resource certificate and the routing origin authorization ROA as transactions through the blockchain network, and store transaction records in a distributed account book. The distributed account book comprises a resource tree and two chains: the resource tree is used for storing effective resource certificates; and the resource transaction success block chain and the resource transaction failure block chain exist in all the block chain nodes, and the contents of the resource transaction success block chain and the resource transaction failure block chain of each node are kept consistent. The resource transaction success blockchain is used for storing resource transaction records successfully verified by the resource certificate transaction intelligent contract. And the resource transaction failure block chain is used for storing the resource transaction failure block chain which cannot pass the verification of the resource certificate transaction intelligent contract and recording the reason of the resource transaction failure.

The resource issuer is a server, a resource transaction application client is installed on the server, and the resource issuer becomes a node of the blockchain network after being connected to the blockchain network. And the resource issuer and the resource receiver serve as both transaction parties, and after the agreement of both transaction parties is obtained through bidirectional authorization, the resource issuer sends the transaction to the block chain network.

The resource certificate transaction intelligent contract is jointly formulated by a resource issuer and a resource receiver, and is a segment of computer readable code used for solving the transaction behavior between the resource issuer and the resource receiver.

And secondly, defining a resource transaction structure.

The resource transaction structure is shown in fig. 2 and includes a transaction initiator, a transaction receiver, a transaction type, a transaction content, a transaction attribute, a transaction evidence, and a transaction signature given by the transaction initiator. The transaction initiator refers to the address of the resource issuer, and the transaction receiver is the address of the resource receiver. A transaction signature refers to a digital signature made by a transaction initiator on an initiated transaction in a blockchain network. The transaction types include seven types, respectively: RC issuance, RC revocation, RC updating, RC modification, ROA issuance authorization, ROA revocation and ROA modification. The transaction content is the content of the RC or ROA corresponding to the transaction. The transaction attribute comprises a transfer attribute and an expiration attribute; the transmission attribute indicates whether the IP address resource allocated to a certain organization can be reallocated to another resource authorization entity, the transmission attribute is 0, and indicates that a resource issuer does not want to perform sub-allocation on the IP address prefix resource allocated to the certain organization, at this time, the organization is called a terminal node, the IP address resource and the AS number resource owned by the organization are not subdivided, and only the terminal node can issue ROA; the transfer attribute is 1, which indicates that a resource issuer wishes to sub-allocate the IP address prefix resource allocated to a certain organization; the expiration attribute shows whether the IP address resource has lease period, the expiration attribute is 0 to indicate that the lease time is not expired, the expiration attribute is 1 to indicate that the lease time is expired, and the IP address resource should be released and returned to the original resource authorization entity. The transaction evidence represents signatures of the resource issuer and the resource receiver twice, and the evidence agreed by the two parties consists of messages transacted by the two parties and random numbers (for example, when the RC is revoked, the evidence of the transaction is RC _ revoke _ reply messages and the random number +1 issued by the holder of the RC), so that the risk that a legal IP address is possibly blocked due to a unilateral authorization protocol of the resource issuer in the current RPKI but an attacker or a behavior offender is difficult to find is overcome. The transaction signature given by the transaction initiator shows that the transaction initiator and the transaction recipient have agreed upon the transaction. For ROA operations, since the transaction initiator and the transaction recipient are the same, no evidence of two-way signatures is required. For ROA-related operations transactions, the transaction signature field given by the initiator of the transaction is NULL.

And thirdly, defining a resource tree, wherein the resource tree is constructed by the resource transaction module according to the effective resource certificate RC. As shown in fig. 3, a node of the resource tree includes 7 domains, which are: the method comprises the steps of a resource issuer, a resource receiver, a resource certificate, a parent certificate identifier, a child certificate identifier, an IP address prefix contained in the certificate and an AS number contained in the certificate. The node is linked to the child node through a child certificate identity domain and to the parent node of the node through a parent certificate identity domain. The IP address prefix contained in the certificate and the AS number contained in the certificate are obtained by the resource transaction module through analyzing the certificate. The resource tree is stored in a distributed account book and is commonly maintained by a resource issuer and a resource receiver.

4.1 block chain initialization and resource tree initialization:

4.1.2 resource transaction Module initializes the root node of the resource Tree to make the root node V₀: creating a founder block by taking an Internet registration management mechanism RIR as a century creator of a block chain, and taking a resource certificate owned by the RIR as a root node V of a resource tree₀：V₀Resource issuer and resource receiver of (1) are both RIR's IP addresses, V₀The resource certificate of (a) is a resource certificate held by the RIR, V₀Is NULL, V₀Is marked as NULL (because the RIR has not issued a sub-certificate yet), V₀The IP address prefix of the network is the IP address prefix owned by the RIR, and the AS number is the AS number owned by the RIR. Handle V₀And recording the data into the distributed account book.

4.2.1.2.1 resource transaction Module issuing IP in Instructions according to RC1_{Prefix 1}And the AS1 searches the resource tree and checks whether the pre-issued RC1 certificate conflicts with the issued RC certificate in the resource tree, wherein the method comprises the following steps:

4.2.1.2.1.2.1 order node variable V ═ V₀；

4.2.1.2.1.2.3 where v is v1, turn 4.2.1.2.1.2.2;

4.2.1.4 resource certificate generation module generates a certificate based on IP received from the resource transaction module_{Prefix 1}And AS1, generating a resource certificate, naming the certificate AS RC 1.

4.2.1.9.2 create a new node RC1 and populate the information for each domain: resource issuance for RC1 nodeThe domain is the IP address IP of the resource issuer of RC1_{Issue 1}The resource recipient domain is the IP address IP of the resource recipient of RC1_{Receiving 1}The content of the resource certificate domain is RC1, and the parent certificate identification domain points to the resource certificate RC held by the resource issuer of RC1_{Issue a}The node where the sub-certificate identification field is NULL, the current node does not issue the sub-certificate, and the IP address prefix and the AS number contained in the certificate are obtained by analyzing RC1 by the resource transaction module.

4.2.2.2.1 resource transaction Module of resource issuer checks the node where the RC2 certificate resides (let V be_rc2) Whether the resource tree belongs to a leaf node or not is determined by the following steps:

4.2.2.2.1.1 let variable node V be the root node V of resource tree₀；

4.2.4.1 revoke RC4 by the certificate revocation method described in 4.2.2;

4.2.7.1 canceling ROA3 according to 4.2.6 said ROA canceling method:

Claims

1. A certificate transaction warning method of resource public key infrastructure based on block chain is characterized by comprising the following steps:

firstly, constructing a Resource Public Key Infrastructure (RPKIB) system, wherein the RPKIB system consists of a resource issuer, a resource transaction application client, a resource receiver, a block chain network, a verification node and an alarm server;

the block chain network is connected with the resource issuer, the resource receiver, the alarm server and the verification node, and the resource issuer, the resource receiver and the alarm server are connected with the block chain network to form a common node of the block chain network; the verification node is another type of node different from a common node in the block chain network, is a server for verifying resource transaction initiated by a resource issuer, and is provided with a resource certificate transaction intelligent contract; the resource issuer and the resource receiver take various operations of the resource certificate and the routing origin authorization ROA as transactions and carry out the transactions through the blockchain network, and store transaction records in a distributed account book; the distributed account book comprises a resource tree and two chains: the resource tree is used for storing effective resource certificates; the resource transaction success block chain and the resource transaction failure block chain exist in all the block chain nodes, and the contents of the resource transaction success block chain and the resource transaction failure block chain of each node are kept consistent; the resource transaction success blockchain is used for storing resource transaction records successfully verified by the resource certificate transaction intelligent contract, and the resource transaction failure blockchain is used for storing the resource transaction failure blockchain which fails to be verified by the resource certificate transaction intelligent contract and recording the reason of resource transaction failure;

the resource issuer is a server and is provided with a resource transaction application client, the resource issuer and the resource receiver are used as both transaction parties, and after the agreement of both transaction parties is obtained through bidirectional authorization, the resource issuer sends the transaction to the block chain network;

the resource receiver is a server on which a resource transaction application client is installed;

the resource transaction application client is arranged on a resource issuer and a resource receiver and consists of a resource transaction module, a resource certificate generation module and a display module;

the resource certificate generation module is connected with the resource transaction module; the resource certificate generation module receives information of a pre-issued RC certificate and ROA from the resource transaction module, generates a resource certificate RC which is the same as the RPKI definition according to the pre-issued RC certificate, and creates ROA for resources held by a resource receiver according to the pre-issued ROA information, wherein one effective ROA comprises three parts: an AS number, an IP address prefix list, optional content that restricts the IP address prefix; the resource certificate generation module sends the generated RC and the generated ROA to the resource transaction module;

the resource transaction module is connected with a resource issuer or a resource receiver, a resource certificate generation module, a display module and a block chain network; the resource transaction module receives RC or ROA from the resource certificate generation module, receives an operation instruction about RC or ROA from the resource issuer, conducts transaction through the blockchain network, and provides various operation services of RC or ROA resource transaction for the resource issuer, wherein one operation is one transaction in RPKIB; when the transaction is successful, the resource transaction module sends a success message to the display module, when the transaction is unsuccessful, the resource transaction module sends a conflict reason, an operation failure reason and a transaction result which are detected by the conflict to the display module, and when the operation is cancelled, the resource transaction module sends the RC and the ROA to the display module;

the display module is connected with the resource transaction module, receives the transaction success message or the conflict reason, the operation failure reason and the transaction result when the transaction is unsuccessful from the resource transaction module, and displays the transaction result; receiving the RC and the ROA from the resource transaction module during the cancel operation, and displaying the specific contents of the RC and the ROA;

the verification node is a server for verifying resource transactions sent to the block chain by a resource issuer, and is provided with a resource certificate transaction intelligent contract; the verification node runs an intelligent contract to verify the transaction, verifies whether the signature of the transaction and the content of the transaction accord with the authority of a resource issuer or not, and whether the content of the transaction does not conflict with the currently allocated resource or not, records the transaction passing the verification into a resource transaction success block chain, and records the transaction failing to pass the verification and the reason of the transaction failure into a resource transaction failure block chain;

the resource certificate transaction intelligent contract is jointly formulated by a resource issuer and a resource receiver, is a segment of computer readable code defined in a digital form and is used for solving the transaction behavior between the resource issuer and the resource receiver;

the alarm server is a server for alarming illegal transactions in resource transactions and is provided with a resource certificate transaction alarm module;

the resource certificate transaction warning module acquires a failure transaction record and reasons in a resource transaction failure block chain, analyzes a possibly malicious role according to the reasons of the resource transaction failure, and gives a potential malicious risk warning prompt;

secondly, defining a resource transaction structure, wherein the resource transaction structure comprises a transaction initiator, a transaction receiver, a transaction type, transaction contents, transaction attributes, transaction evidence and a transaction signature given by the transaction initiator; the transaction initiator refers to the address of the resource issuer, and the transaction receiver is the address of the resource receiver; the transaction signature refers to a digital signature made by a transaction initiator on an initiated transaction in the blockchain network; the transaction types include seven types, respectively: RC issue, RC cancel, RC update, RC modification, ROA issue, ROA cancel, ROA modification; the transaction content is the content of the RC or ROA corresponding to the transaction; the transaction attribute comprises a transfer attribute and an expiration attribute; the transmission attribute indicates whether the IP address resource allocated to a certain organization can be reallocated to another resource authorization entity, the transmission attribute is 0, and indicates that a resource issuer does not want to perform sub-allocation on the IP address prefix resource allocated to the certain organization, at this time, the organization is called a terminal node, the IP address resource and the AS number resource owned by the organization are not subdivided, and only the terminal node can issue ROA; the transfer attribute is 1, which indicates that a resource issuer wishes to sub-allocate the IP address prefix resource allocated to a certain organization; the expiration attribute shows whether the IP address resource has a lease term, the expiration attribute is 0 to indicate that lease time is not expired, the expiration attribute is 1 to indicate that the lease time is expired, and the IP address resource is released and returned to the original resource authorization entity; the transaction evidence represents the signatures of the resource issuer and the resource receiver twice, and the evidence agreed by the two parties consists of messages and random numbers of the transaction of the two parties; the transaction signature given by the transaction initiator shows that the transaction initiator and the transaction receiver agree on the transaction; a transaction signature field given by an initiator of the ROA related operation transaction is NULL;

thirdly, defining a resource tree, wherein the resource tree is constructed by a resource transaction module according to an effective resource certificate, and one node of the resource tree comprises 7 domains, which are respectively: the method comprises the following steps that a resource issuer, a resource receiver, a resource certificate, a parent certificate identifier, a child certificate identifier, an IP address prefix contained in the certificate and an AS number contained in the certificate are obtained; the node is linked to the child node through the child certificate identification domain and is linked to the father node of the node through the father certificate identification domain; the IP address prefix contained in the certificate and the AS number contained in the certificate are obtained by the resource transaction module through analyzing the certificate; the resource tree is stored in a distributed account book and is maintained by a resource issuer and a resource receiver together;

fourthly, performing bidirectional authorization on resource operation between the resource issuer and the resource receiver by the resource public key infrastructure system RPKIB based on the block chain, and performing transaction corresponding to the resource operation between the resource issuer and the resource receiver after each type of bidirectional authorization passes; when the verification node receives the corresponding transaction message, operating a resource certificate transaction intelligent contract to verify the corresponding transaction, recording the transaction passing the verification into a resource transaction success block chain, and recording the transaction failing the verification and the reason of the transaction failure into a resource transaction failure block chain; the resource certificate transaction warning module of the warning server monitors the resource transaction failure block chain, and when the transaction which fails to pass the verification and the reason of the transaction failure are recorded in the resource transaction failure block chain, the warning server analyzes the possibly malicious role according to the reason of the resource transaction failure and gives a potential malicious risk warning prompt; the method comprises the following steps:

4.1 block chain initialization and resource tree initialization:

4.1.1 initializing the resource transaction success block chain and the resource transaction failure block chain to be null;

4.1.2 resource transaction Module initializes the root node of the resource Tree to make the root node V₀: the Internet registration management organization RIR is used as a century creator of the block chain to create a first block of the block chain, and a resource certificate owned by the RIR is used as a root node V of a resource tree₀：V₀Resource issuer and resource receiver of (1) are both RIR's IP addresses, V₀The resource certificate of (a) is a resource certificate held by the RIR, V₀Is NULL, V₀Is marked as NULL, V₀The IP address prefix of the network is an IP address prefix owned by the RIR, and the AS number is an AS number owned by the RIR; handle V₀RecordingTo a distributed ledger;

4.2 the resource transaction module of the resource transaction application client receives the message from the resource issuer, if the issuance message of the resource certificate RC1 is received, 4.2.1 is switched; if the revocation message of the resource certificate RC2 is received, 4.2.2 is switched; if a message for updating the resource certificate RC3 is received, 4.2.3 is switched; if a message related to RC4 modification of resource allocation adjustment is received, go to 4.2.4; if a message issued by the ROA1 is received, 4.2.5 is switched; if a message for the revocation of ROA2 is received, go to 4.2.6; if a message modified by ROA3 is received, transition 4.2.7:

4.2.1 at this time, the resource transaction module receives an RC1 issue message from the resource issuer, and the RC1 issue message contains the IP address of the resource receiver, namely the IP address_{Receiving 1}IP address prefix, i.e. IP, pre-issued to resource recipients_{Prefix 1}AS1, issuing a certificate RC1 by the certificate issuing method described in 4.2.1.1-4.2.1.12:

the 4.2.1.1 resource transaction module is provided with an RC1 issuing instruction, and the RC1 issuing instruction comprises IP_{Receiving 1}，IP_{Prefix 1}、AS1；

4.2.1.2.1.1 checking for pre-issued IP_{Prefix 1}And AS1 is owned or not owned by the resource issuer, having the resource issuer IP address IP_{Issue 1}The method comprises the following steps:

4.2.1.2.1.1.1 resource transaction module of resource issuer resolves resource certificate RC held by itself_{Issue a}To obtain RC_{Issue a}The IP address prefix and AS number contained therein;

4.2.1.2.1.2 checking IP contained in a pre-issued RC1 certificate_{Prefix 1}And whether AS1 has been issued, i.e. whether the IP address prefix and AS number contained in the resource certificate that the resource issuer has issued contain an IP address_{Prefix 1}And AS1, if the checking result is 'not issued', turning to 4.2.1.3; if the checking result is' pre-issued IP_{Prefix 1}And AS1 has been issued, creating a conflict ", transition 4.2.1.2.1.4;

4.2.1.2.1.3, the resource transaction module sends the resource conflict message to the display module, the display module displays the resource conflict message, the message contains the reason of the resource conflict, the conflict reason is that the IP address prefix resource and AS number contained in the pre-issued RC certificate are not owned by the current certificate issuer, and the fifth step is carried out;

4.2.1.2.1.4 the resource transaction module sends the 'resource conflict' message to the display module, the display module displays the 'resource conflict' message, the message contains the reason of the resource conflict, the conflict reason is that 'the IP address prefix and AS number contained in the pre-issued RC certificate have been issued', turn 4.2.1.2.2;

4.2.1.2.2 the resource transaction module checks whether the instruction of 'abandoning the transaction' is received from the resource issuer, if so, go to the fifth step; otherwise, turning to 4.2.1.2.3;

4.2.1.2.3 the resource transaction module determines whether a revocation message is received from the resource issuer to revoke an issued resource that conflicts with the pre-issued RC1, and if a revocation message is received, revoking an issued RC that conflicts with the pre-issued RC 1; if the revocation message is not received, turning to the fifth step;

4.2.1.4 resource certificate generation module generates a certificate based on IP received from the resource transaction module_{Prefix 1}And AS1, generating a resource certificate, which will beThis certificate is named RC 1;

4.2.1.5.1 the resource transaction module of the resource issuer of RC1 constructs an issuance request message RC _ issue _ request of RC1 based on UDP, and sends RC _ issue _ request to the resource transaction module of the resource receiver through the blockchain network; the resource issuer of the RC1 initializes the retransmission times m to be 0, starts an issuance request sending timer corresponding to the RC1, and waits for receiving an issuance request response message of the RC1 from the resource receiver;

4.2.1.5.2 the resource issuer of RC1 checks if the issuance request transmission timer has expired, if not, go to 4.2.1.5.3; if the issuing request sending timer is overtime, M is smaller than the maximum retransmission time M, and M is a positive integer, increasing M by 1, retransmitting RC _ issue _ request to the resource receiver, restarting the issuing request sending timer corresponding to RC1, and turning to 4.2.1.5.3; if the issuance request sending timer is overtime and M is equal to M, the issuance request is failed, the resource issuer deletes RC1, and the resource transaction module sends the operation failure and the reason of the operation failure to the display module for displaying because of the transmission overtime, and then the fifth step is carried out;

4.2.1.5.3 the resource issuer of RC1 determines whether an issuance request reply message RC _ issue _ reply is received from the resource receiver; if not, the resource transaction module of the resource issuer of RC1 sends a failure message and the reason of operation failure to the display module, because the issue request response message sent from the resource receiver is not received, turning to the fifth step; if rc _ issue _ reply is received, checking the format and content of rc _ issue _ reply, if the format is wrong, discarding rc _ issue _ reply, sending a failure message and the reason of operation failure to the display module by the resource transaction module, and turning to the fifth step because the 'format of the issuance request response message is wrong'; if the format is correct, checking the content of the RC _ issue _ reply message, if the RC _ issue _ reply message is rejected, deleting the RC1 by the resource issuer, and simultaneously sending an operation failure message and a reason of the operation failure to a display module of the resource transaction application client by the resource issuer, wherein the reason is that the resource receiver does not agree with the certificate issue, and the display module displays the operation failure message and the reason of the operation failure, and turning to the fifth step; if it is in rc _ issue _ reply that the operation request is granted, 4.2.1.6 is performed;

4.2.1.6 the resource transaction module of the resource issuer constructs an issuance transaction message RC _ issue of RC1 according to the resource transaction structure, the resource issuer sends RC _ issue to the resource transaction module and the verification node of the resource receiver through the blockchain network, the RC _ issue includes the signature of the resource issuer of RC1 on the transaction;

4.2.1.7.1 resource certificate transaction Smart contract checks if the resource issuer signature in rc _ issue is correct, checks if rc _ issue is in correct format and has been submitted before; if the resource issuer signature is correct and the format of rc _ issue is correct and rc _ issue has not been previously submitted, go to 4.2.1.7.2, if the resource issuer signature is incorrect or the format of rc _ issue is incorrect, then record failure reason is "issuer signature is incorrect or transaction format is incorrect", go to 4.2.1.7.5; if the transaction message issued by the RC1 has been submitted before, the record failure reason is "the transaction message has been submitted before", go to 4.2.1.7.5;

4.2.1.7.2 the resource certificate transaction intelligent contract checks whether the transaction evidence is correct, that is, checks the format and content of the resource issuance request response message rc _ issue _ reply, and whether the random numbers of the two parties in the message are not repeated with the currently stored random numbers that the two parties have received; if the execution is passed 4.2.1.7.3, otherwise the record failure reason is "transaction evidence is incorrect", execution 4.2.1.7.5;

4.2.1.7.3 resource certificate transaction intelligent contract extracts the transaction content of the transaction message issued by RC1, analyzes the IP address prefix contained in the resource certificate from the transaction content, and checks whether the IP address prefix conflicts with the IP address prefix contained in the resource certificate issued by the resource issuer; if there is no conflict transition 4.2.1.7.4, otherwise the record failure reason is "conflict between pre-issued IP address resources and IP address resources contained in the issued resource certificate", transition 4.2.1.7.5;

4.2.1.7.6.1, if the reason of the resource transaction failure is 'issuer signature is incorrect or transaction format is wrong', prompting 'malicious role is resource issuer', turning to the fifth step, otherwise, turning to 4.2.1.7.6.2;

4.2.1.8 if the resource transaction module of the resource receiver receives RC _ issue sent from the resource issuer and obtains the specific transaction content, namely the RC1 resource certificate, from the transaction content domain of RC _ issue, the transaction is successful, and 4.2.1.9 is turned; if the resource transaction module of the resource receiver does not receive RC _ issue or the transaction content obtained from the transaction content domain of RC _ issue is not the RC1 resource certificate, turning to 4.2.1.10;

4.2.1.9 resource transaction module of resource receiver creates a new node for resource tree, namely RC1 node, and sends transaction success message to resource transaction module of resource issuer, turn to 4.2.1.11;

4.2.1.10 resource transaction module of resource receiver sends transaction failure message to resource transaction module of resource issuer, go to 4.2.1.12;

4.2.1.12, if the resource transaction module of the resource issuer of the RC1 receives the transaction failure message sent from the resource transaction module of the resource receiver, the resource issuer of the RC1 deletes the node where the RC1 certificate is located in the resource tree, and at the same time, the resource transaction module of the resource issuer of the RC1 sends the "operation failure" message and the reason of the operation failure to the display module, because the RC1 certificate is not correctly received, the display module displays the "operation failure" message and the reason of the operation failure, and the fifth step is carried out;

4.2.2 at this time, the resource transaction module of the resource transaction application client receives a message of RC2 revocation from the resource issuer, the message of RC2 revocation includes a holder of the RC resource certificate, a pre-revocation resource certificate RC, and revokes the certificate RC2 according to the certificate revocation method described in 4.2.2.1-4.2.2.8, at this time, the holder of the RC resource certificate acts as the resource receiver:

4.2.2.1 resource transaction module of resource issuer sets up canceling RC2 command according to the message of RC2 canceling, canceling RC2 command includes holder of RC resource certificate and pre-cancelled resource certificate RC2, and sends specific content of RC2 to display module, which displays specific content of RC 2;

4.2.2.2 resource issuer performs bidirectional authorization with the holder of the pre-revoked RC2 certificate by:

4.2.2.2.1 resource transaction Module of resource issuer checks the node V where the RC2 certificate is located_rc2Whether the resource tree belongs to a leaf node or not is determined by the following steps:

4.2.2.2.1.1 let variable node v be the root node of the resource treePoint V₀；

4.2.2.2.1.3 where v is v 1; turning to 4.2.2.2.1.2;

4.2.2.2.2 the resource trading module of the resource issuer constructs the revocation message RC _ revoke _ request of RC2 based on UDP, and the resource trading module of the resource issuer sends RC _ revoke _ request to the resource trading module of the resource receiver, that is, the holder of RC 2; the resource issuer initializes the second retransmission number m2 to 0, and starts a revocation request sending timer corresponding to the RC 2;

4.2.2.2.3 the resource issuer of the RC2 checks if the revocation request transmission timer has expired, if not, go to 4.2.2.2.4; if the revocation request sending timer is overtime and M2 is less than the maximum retransmission number M, increasing M2 by 1, retransmitting RC _ revoke _ request to the resource transaction module of the resource receiver, starting an issuance request sending timer corresponding to RC2 by the resource issuer, and turning to 4.2.2.2.4; if M2 is equal to M, the cancellation request fails, the resource transaction module of the resource issuer sends 'operation failure' and the reason of the operation failure to the display module, the reason is 'cancellation request message sending overtime', the display module displays 'operation failure' and the reason of the operation failure, and the fifth step is executed;

4.2.2.2.4RC2 resource transaction module determines whether receiving the cancellation request response message RC _ revoke _ reply sent from the resource transaction module of the resource receiver, if not, the resource transaction module of the resource issuer sends failure message and reason of operation failure to the display module, because "not receiving the cancellation request response message sent from the resource receiver", turning to the fifth step; if rc _ revoke _ reply is received, checking the format and content of rc _ revoke _ reply, if the format is wrong, discarding the message, sending a failure message and the reason of operation failure to the display module, wherein the reason is 'the format of a revocation request response message sent by a resource receiver is wrong', and turning to the fifth step; if the format is correct, checking response information in rc _ revoke _ reply, if the request is refused to revoke the operation, sending 'operation failure' and the reason of the operation failure to a display module by the resource transaction module, wherein the reason is that the 'certificate holder does not agree with the certificate revocation', and the display module displays the 'operation failure' and the reason of the operation failure, and going to the fifth step; if the operation request is approved to be withdrawn, 4.2.2.3 is carried out;

4.2.2.3RC2, according to the identification of RC2, the resource transaction module of the resource issuer checks whether the node v1 where RC2 is located is a leaf node in the resource tree, that is, determines whether the value of the sub certificate identification field of v1 is NULL, and if v1 is a leaf node, turns to 4.2.2.4; if v1 is not a leaf node, it indicates that the owner of RC2 has not completely deleted the resource subtree of RC2, RC2 does not meet the revocation condition, "operation failure" and the reason for the operation failure are sent to the display module, because the owner of RC2 returns an RC revocation agreement request without revoking the child resources, violates the agreement rules or is attacked, "operation failure" and the reason for the operation failure are displayed by the display module, go to the fifth step;

4.2.2.4 the resource trading module of the resource issuer of RC2 constructs a revoke trading message RC _ revoke of RC2 according to the resource trading structure, the resource trading module of the resource issuer sends RC _ revoke to the resource trading module and the verification node of the resource receiver through the blockchain network, and the conversion is 4.2.2.5; the revocation transaction message RC _ revoke comprises a signature of a resource issuer of the RC2 on the transaction;

4.2.2.5.1 resource certificate transaction Smart contract checks if the resource issuer signature in rc revoke is correct, checks if rc revoke is in correct format and has been submitted before; if the resource issuer signature is correct and the transaction message format is correct and the RC2 cancellation transaction message has not been submitted before, execute 4.2.2.5.2, if the resource issuer signature is incorrect or the resource cancellation transaction message format is incorrect, record failure reason is "issuer signature is incorrect or transaction format is wrong", execute 4.2.2.5.5; if rc _ revoke has been submitted before, record failure reason is "the transaction message has been submitted before", go to 4.2.2.5.5;

4.2.2.5.2 the resource certificate transaction intelligent contract checks whether the evidence of the transaction revocation is correct, that is, checks the format and content of the revocation request response message rc _ revoke _ reply, and whether the random numbers of the two parties in the message are not repeated with the random numbers which have been received by the two parties; if the execution is passed 4.2.2.5.3, otherwise the record failure reason is "transaction evidence is incorrect", execution 4.2.2.5.5;

4.2.2.5.3 resource certificate trading intelligent contract inquires resource trading success block chain, checks whether RC2 has been issued, that is, the issued resource certificate RC2 can be inquired in the resource trading success block chain, if there is RC2 already issued in the resource trading success block chain, executes 4.2.2.5.4, otherwise records failure reason because "pre-revoked resource certificate RC2 does not exist"; 4.2.2.5.5 is executed;

4.2.2.5.6.1, if the reason of the resource transaction failure is 'issuer signature is incorrect or transaction format is wrong', prompting 'malicious role is resource issuer', turning to the fifth step, otherwise, turning to 4.2.2.5.6.2;

4.2.2.6 the resource trading module of the resource receiver executes the delete operation according to the trade type and trade content in RC _ revoke, deletes the resource certificate RC2, and modifies the resource tree: deleting the node v1 where the RC2 is located, and deleting the child certificate identifier pointing to the node v1 in the child certificate identifier field of the v1 parent node, wherein the transaction is successful at this moment; the resource transaction module of the resource receiver sends a transaction success message to the resource transaction module of the resource issuer, and the operation is switched to 4.2.2.7; otherwise, sending a transaction failure message to the resource transaction module of the resource issuer, and turning to 4.2.2.8;

4.2.2.8 if the resource issuer receives the transaction failure message, sending 'operation failure' to the display module, prompting the reason of the operation failure, wherein the reason is 'resource deletion failure', displaying 'operation failure' and the reason of the operation failure by the display module, and turning to the fifth step;

4.2.3 at this time, the resource transaction module of the resource transaction application client receives an RC3 update message which does not relate to public and private keys and resource allocation from the resource issuer, and updates the certificate RC3 according to the certificate update method of 4.2.3.1-4.2.3.7:

4.2.3.1, the resource trading module of the resource issuer of the RC3 sets an RC3 updating instruction, the content of the RC3 updating instruction comprises the identifiers of the currently effective RC3, the holder of the RC3 resource certificate, the RC3 and the attribute value which can be changed by the updating operation, if the attribute value to be updated does not accord with the value range, error reporting information is sent to the display module, the attribute value to be updated is reset, and 4.2.3.2 is turned;

4.2.3.2RC3 performs bidirectional authorization with the holder of the RC3 certificate resource, namely the resource receiver, as follows:

4.2.3.2.1 the resource transaction module of the resource issuer of RC3 constructs an update request message RC _ override 1_ request of RC3 based on UDP, and the resource transaction module of the resource issuer sends RC _ override 1_ request to the resource transaction module of the certificate holder through the blockchain network; the resource transaction module of the resource issuer initializes the third retransmission number m3 to 0, and starts an update request sending timer corresponding to the RC3 for the RC 3;

4.2.3.2.2 the resource transaction module of the resource issuer of RC3 checks whether the update request transmission timer of RC3 has expired, if not, go to 4.2.3.2.3; if the update request transmission timer of RC3 times out and M3 is less than the maximum number of retransmissions M, then increment M3 by 1, the resource transaction module of the resource issuer retransmits RC _ override 1_ request of RC3, starts the update request transmission timer of RC3, go 4.2.3.2.2; if the update request sending timer of the RC3 is overtime and M3 is equal to M, the update request of the RC3 fails, and the operation failure and the reason of the operation failure are sent to the display module, the reason is that the update request message fails to be sent and is overtime, the display module displays the operation failure and the reason of the operation failure, and the fifth step is carried out;

4.2.3.2.3 the resource transaction module of the resource issuer of the RC3 determines whether the update request response message RC _ override 1_ reply of RC3 is received from the resource transaction module of the certificate holder, if not, the resource transaction module of the resource issuer sends "operation failure" and reason to the display module, because "the update request response message sent from the resource transaction module of the resource receiver is not received", go to the fifth step; if rc _ overhead 1_ reply is received, the format and content of rc _ overhead 1_ reply are checked, if the format is wrong, the message is discarded, the resource transaction module of the resource issuer sends operation failure and reasons to the display module, and the fifth step is carried out because the format of the update request response message is wrong; if the format is correct, checking rc _ override 1_ reply, if the operation request is refused to be updated, sending 'operation failure' and the reason of the operation failure to the display module, wherein the reason is that the certificate holder does not agree with the operation, the display module displays the 'operation failure' and the reason of the operation failure, and turning to the fifth step; if the rc _ overhead 1_ reply response message is to approve the operation request, then 4.2.3.3 is executed;

4.2.3.3RC3, the resource transaction module of the resource issuer constructs an update message RC _ override 1 of RC3 according to the resource transaction structure, and the resource transaction module of the resource issuer of RC3 sends RC _ override 1 to the resource transaction module and the verification node of the resource receiver through the blockchain network; a signature of a transaction by a resource issuer of RC3 included in the RC _ override 1';

4.2.3.4 the validation node receives RC _ override 1 from the resource issuer of RC3, the resource certificate transaction Smart contract is checked as follows;

4.2.3.4.1 resource certificate transaction Smart contracts check if the resource issuer signature in rc _ override 1 is correct, check if the format of rc _ override 1 is correct and was previously submitted; if the resource issuer signature is correct and the transaction message format is correct, and the resource certificate RC update transaction message RC _ override 1 has not been submitted before, execute 4.2.3.4.2, if the resource issuer signature is incorrect or the resource update transaction message format is incorrect, the record failure reason is "issuer signature is incorrect or transaction message format is incorrect", execute 4.2.3.4.5; if the resource certificate has been submitted before updating the transaction message, the record failure reason is that "the transaction message has been submitted before", go to 4.2.3.4.5;

4.2.3.4.2 resource certificate transaction intelligent contract checks whether the transaction evidence is correct, that is, checks the format and content of update request response message rc _ overhead 1_ reply, and whether the random numbers of both parties in the message are not repeated with the currently stored random numbers that both parties have received; if the execution is passed 4.2.3.4.3, otherwise the record failure reason is "transaction evidence is incorrect", execution 4.2.3.4.5;

4.2.3.4.3 resource certificate trading intelligent contract inquires resource trading success block chain, checks whether resource certificate RC3 has been issued, namely, can inquire the issued resource certificate RC3 on the resource trading success block chain, if there is the already issued RC3, executes 4.2.3.4.4, otherwise records failure reason because "pre-modified resource certificate RC3 does not exist"; 4.2.3.4.5 is executed;

4.2.3.4.5 the resource certificate transaction intelligent contract fails to verify, the verification node sends the transaction record containing the failure reason to the resource transaction failure block chain;

4.2.3.4.6.1, if the reason of the resource transaction failure is 'issuer signature is incorrect or transaction format is wrong', prompting 'malicious role is resource issuer', turning to the fifth step, otherwise, turning to 4.2.3.4.6.2;

4.2.3.4.6.4 if the reason of the resource transaction failure is that the pre-modified resource certificate RC3 does not exist, prompting that the malicious role is the resource issuer, and turning to the fifth step;

4.2.3.5 if the resource transaction module of the resource receiver replaces the RC3 to be updated with the RC 3' according to the transaction type and the transaction content in the RC _ override 1, at this time, the transaction is successful, the resource transaction module of the resource receiver modifies the resource tree: modifying the information of the resource certificate domain of the node where the resource certificate RC3 is located, namely, replacing the resource certificate domain with the information of RC 3', simultaneously sending a transaction success message to the resource transaction module of the resource issuer by the resource transaction module of the resource receiver, and turning to 4.2.3.6; otherwise, sending a transaction failure message to the resource transaction module of the resource issuer, and turning to 4.2.3.7;

4.2.3.7 if the resource issuer of RC3 receives the transaction failure message, it sends the "operation failure" and the reason of the operation failure to the display module, the reason is "the resource receiver fails to modify the certificate", the display module displays the "operation failure" and the reason of the operation failure, go to the fifth step;

4.2.4 at this time, the resource transaction module of the resource transaction application client receives a message of RC4 modification related to resource allocation adjustment from the resource issuer, the resource transaction module of the resource issuer needs to revoke the old certificate RC4, and issues a new certificate, namely RC5, according to the setting of the modification message, the method is as follows:

4.2.4.1 revoke RC4 by the certificate revocation method described in 4.2.2;

4.2.4.2 issuing a new certificate RC5 instruction according to the modification message setting, and issuing an RC5 according to the certificate issuing method of 4.2.1; turning to the fifth step;

4.2.5 at this time, the resource transaction module of the resource transaction client receives a message issued by the ROA1 from the resource issuer, and issues the ROA1 according to the ROA issuing method of 4.2.5.1-4.2.5.8:

4.2.5.2.1ROA1 resource transaction module checks whether the pre-issued IP address prefix and AS number resources have been issued, queries the transaction record of ROA1 resource issuer ROA recorded in the resource transaction success block chain to obtain all ROA issued by ROA1 resource issuer, compares whether the IP address prefix and AS number contained in all ROA issued overlap with the pre-issued IP address prefix and AS number, if so, conflict occurs, and goes to 4.2.5.2.3; if not, go to 4.2.5.3;

4.2.5.2.2ROA1 resource transaction module sends ' operation failure ' message and reason to display module, the reason is ' resource conflict ', the IP address prefix and AS number resource held by resource issuer do not contain IP address prefix and AS number contained in ROA issued in advance ', the display module displays ' operation failure ' message, the message contains reason of operation failure, go to the fifth step;

4.2.5.2.3ROA1 resource transaction module sends an ' operation failure ' message and reason to the display module, because the ' IP address prefix and AS number contained in the pre-issued ROA ' are already issued ', the display module displays the ' operation failure ' message, and the message contains the reason of the operation failure;

4.2.5.2.4ROA1 resource transaction module checks whether receiving the command of 'abandoning this transaction' from the resource issuer, if yes, go to the fifth step, otherwise go to 4.2.5.2.5;

4.2.5.2.5 the resource transaction module of the resource issuer of the ROA1 determining whether a revocation message was received from the resource issuer to revoke an issued ROA that conflicts with ROA1, and if a revocation message was received, revoking an issued ROA that conflicts with the pre-issued ROA1, block 4.2.5.2; if the revocation message is not received, turning to the fifth step;

4.2.5.3 if no conflict occurs, the resource transaction module of the resource issuer of the ROA1 sends the IP address prefix and the AS number in the ROA1 issuance instruction to the resource certificate generation module of the resource issuer; the resource certificate generation module of the resource issuer generates ROA1 according to the issuance instruction content of ROA 1;

4.2.5.4 the resource transaction module of the resource issuer of the ROA1 constructs an issuance transaction message ROA _ issue of the ROA1 according to the defined resource transaction structure, and the resource transaction module of the resource issuer of the ROA1 sends the issuance transaction message ROA _ issue of the ROA1 to the resource receiver and the verification node through the blockchain network; a signature of a transaction by a resource issuer of the ROA _ issue that includes the ROA 1;

4.2.5.5.1 resource certificate transaction Smart contract checks if the resource issuer signature in roa _ issue is correct, checks if the format of roa _ issue is correct and was previously submitted; if the resource issuer signature is correct and the transaction message format is correct and the ROA1 has not submitted the transaction message before issuing the transaction message, executing 4.2.5.5.2, if the resource issuer signature is incorrect or the resource issuer transaction message format is incorrect, recording that the failure reason is 'issuer signature is incorrect or transaction format is wrong', executing 4.2.5.5.4; if the transaction message issued by the ROA1 was previously submitted, the record failure reason is "the transaction message was previously submitted", go to 4.2.5.5.4;

4.2.5.5.2 resource certificate transaction intelligent contract extracts the IP address prefix contained in the transaction content in the transaction message ROA _ issue submitted by the resource issuer of ROA1, and checks whether the IP address prefix has been issued by the resource issuer, the method is: inquiring transaction records of ROA issued by a resource issuer of ROA1 recorded in a resource transaction success block chain to obtain all ROAs issued by the resource issuer of ROA1, comparing whether IP address prefixes contained in all the issued ROAs are overlapped with pre-issued IP address prefixes, and if so, generating conflict; record failure reason is "pre-issued IP geological resources conflict with IP address resources contained in issued ROA", transfer 4.2.5.5.4; if not, go to 4.2.5.5.3;

4.2.5.5.5.1, if the reason of the resource transaction failure is 'issuer signature is incorrect or transaction format is wrong', prompting 'malicious role is resource issuer', turning to the fifth step, otherwise, turning to 4.2.5.5.5.2;

4.2.5.6 if the resource transaction module of the resource receiver analyzes the transaction class and the transaction content from roa _ issue, at this time, the transaction is successful, the resource transaction module of the resource receiver sends a transaction success message to the resource transaction module of the resource issuer, and then 4.2.5.7 is carried out; if the transaction is unsuccessful, the resource transaction module of the resource receiver sends a transaction failure message to the resource transaction module of the resource issuer, and the operation is switched to 4.2.5.8;

4.2.5.8 if the resource issuer of ROA1 receives the transaction failure message from the resource receiver, the resource transaction module of the resource issuer of ROA1 deletes ROA1 and sends the operation failure message and the reason of the operation failure to the display module, because the resource receiver fails to acquire the transaction content, the display module displays the operation failure and the reason of the operation failure, go to the fifth step;

4.2.6 when the resource transaction module of the resource transaction client receives the message of canceling the ROA2 from the resource issuer, canceling the ROA2 according to the ROA canceling method of 4.2.6.1-4.2.6.6:

4.2.6.2 the resource trading module of the resource issuer of the ROA2 constructs a revoke trading message ROA _ revoke of the ROA2 according to the defined resource trading structure, and the resource trading module of the resource issuer sends ROA _ revoke to the resource trading module and the verification node of the resource receiver through the blockchain network; the resource issuer of the ROA _ revoke who has the ROA2 signs the transaction;

4.2.6.3.1 resource certificate trading Smart contract checks if the resource issuer signature in roa _ revoke is correct, checks if the format of roa _ revoke is correct and was previously submitted; if the resource issuer signature is correct and the transaction message format is correct and the ROA2 has not been submitted before revoking the transaction message, execute 4.2.6.3.2, if the resource issuer signature is incorrect or the resource revocation transaction message format is incorrect, record the failure reason is "issuer signature is incorrect or transaction format is wrong", execute 4.2.6.3.4; if the ROA2 has already submitted the transaction message before revoking, the record failure reason is "the transaction message has already been submitted before", go to 4.2.6.3.4;

4.2.6.3.2 resource certificate transaction Smart contract queries resource transaction success Block chain, checks if ROA2 has been issued, i.e. can query issued ROA2 on resource transaction success Block chain, if there is already issued ROA2, executes 4.2.6.3.3; otherwise the recording failure reason is "pre-revoked ROA2 not present", execute 4.2.6.3.4;

4.2.6.3.4 the resource certificate transaction intelligent contract fails to verify, the verification node sends the transaction record containing the failure reason to the resource transaction failure block chain;

4.2.6.3.5.1, if the reason of the resource transaction failure is 'issuer signature is incorrect or transaction format is wrong', prompting 'malicious role is resource issuer', turning to the fifth step, otherwise, turning to 4.2.6.3.5.2;

4.2.6.3.5.2, if the reason of the resource transaction failure is that the transaction message has been submitted before, then prompting that the malicious role is the resource issuer, turning to the fifth step, 4.2.6.3.5.3;

4.2.6.4 if the resource transaction module of the resource receiver resolves from ROA _ revoke that the transaction type is ROA2 revocation and the transaction content is ROA2, the resource transaction module of the resource receiver deletes ROA2, and at this time, the transaction is successful, the resource transaction module of the resource receiver sends a transaction success message to the resource transaction module of the resource issuer, and then 4.2.6.5 is executed; if the transaction is unsuccessful, the resource transaction module of the resource receiver sends a transaction failure message to the resource transaction module of the resource issuer, and the operation is switched to 4.2.6.6;

4.2.6.6 if the resource transaction module of the resource issuer receives the transaction failure message, it sends the operation failure notice and the reason of the operation failure to the display module, the reason is that the resource receiver fails to delete the ROA2, the display module displays the operation failure and the reason of the operation failure, go to the fifth step;

4.2.7 at this time, when the resource trading module of the resource trading application client receives the instruction for modifying the ROA3 from the resource issuer, the resource trading module of the resource issuer of the ROA3 needs to cancel the ROA3 first, then generate a new ROA3 'according to the modified content, and issue a new ROA 3', the method is:

4.2.7.1 canceling ROA3 according to 4.2.6 said ROA canceling method:

and fifthly, rotating to 4.2.

2. The block chain based resource public key infrastructure certificate transaction alerting method AS claimed in claim 1, characterized in that the content of the resource certificate RC includes x.509 certificate of standard RFC 5280, accompanied by IP address and AS extension identifier of RFC 3779 standard.

3. The method for block chaining resource public key infrastructure based certificate transaction alerting as in claim 1, wherein said checking at step 4.2.1.2.1.2 the IP contained in the pre-issued RC1 certificate_{Prefix 1}And whether the AS1 has been issued is to check that the resource issuer has issuedWhether the IP address prefix and AS number contained in the resource certificate contain IP_{Prefix 1}And AS1, the specific method is AS follows:

4.2.1.2.1.2.1 order node variable V ═ V₀；

4.2.1.2.1.2.2 checking the value in v sub-certificate identification field, if it is NULL, the checking result is "not issued", ending; if not, finding out the node where the resource issuer is located, wherein the method comprises the following steps: obtaining a child node v1 according to the value in the child certificate identification domain of v, and judging whether the value of the resource certificate domain of v1 is the RC1 held by the resource issuer, if so, the node v1 is the node where the resource issuer is located, turning to 4.2.1.2.1.2.4, and if not, turning to 4.2.1.2.1.2.3;

4.2.1.2.1.2.3 where v is v1, turn 4.2.1.2.1.2.2;

4.2.1.2.1.2.4 obtains the child node v2 of v1 through the child certificate identification domain of the v1 node, and the resource transaction module of the resource issuer parses the resource certificate RC held by the child node v2_v2Comparison RC_v2The IP address prefix, AS number and pre-issued IP contained in the same_{Prefix 1}Whether or not it overlaps with AS1, if so, indicates pre-issued IP_{Prefix 1}And AS1 has been issued, creating a conflict, the check result being "Pre-issued IP_{Prefix 1}And AS1 has been issued, conflict generated ", end; if there is no overlap, the pre-issued IP is indicated_{Prefix 1}And AS1 has not been issued, the check result is "not issued yet", and end.

4. The method for warning of certificate transaction of resource public key infrastructure based on block chain as claimed in claim 1 wherein the method adopted by the issued RC which conflicts with the pre-issued RC1 of revoking at step 4.2.1.2.3 is the method of certificate revocation of 4.2.2.

5. The certificate transaction warning method of block chain based resource public key infrastructure as claimed in claim 1, wherein the maximum number of retransmissions M is equal to or less than 16.

6. The method for warning the certificate transaction of the resource public key infrastructure based on the block chain as claimed in claim 1, wherein the method for the resource transaction module of the resource receiver to create the RC1 node for the resource tree in step 4.2.1.9 is:

4.2.1.9.1 update a certificate RC held by a parent node of the RC1 node, i.e., the resource issuer_{Issue a}Adding a sub-certificate identifier in a sub-certificate identifier field according to the information of the node where the node is located, wherein the sub-certificate identifier points to a new node RC1 node;

4.2.1.9.2 create a new node RC1 and populate the information for each domain: the resource issuer domain of the RC1 node is the IP address IP of the resource issuer of the RC1_{Issue 1}The resource recipient domain is the IP address IP of the resource recipient of RC1_{Receiving 1}The content of the resource certificate domain is RC1, and the parent certificate identification domain points to the resource certificate RC held by the resource issuer of RC1_{Issue a}The sub-certificate identification field of the located node is NULL, and the IP address prefix and the AS number contained in the certificate are obtained by analyzing RC1 by the resource transaction module.

7. The partition chain-based certificate transaction warning method for the resource public key infrastructure according to claim 1, wherein the rc _ issue _ request content includes an issued certificate, a certificate identifier owned by a parent certificate, i.e. a resource issuer, a random number r, a resource receiver address; the rc _ issue _ reply content comprises a received message, whether a resource issuer operation is agreed or not, and a random number; the content of the RC _ issue comprises an issuer of a resource issuer namely RC1, a receiver of a resource receiver RC1, an issue of a transaction type namely RC1, specific content of a transaction content namely RC1, transaction attributes namely a transfer attribute and an expiration attribute, evidence of the transaction namely RC _ issue _ reply message, a random number +1 issued by the receiver of the RC, and a signature of the resource issuer of the RC1 on the transaction.

8. The method as claimed in claim 1, wherein the rc _ revoke _ request content includes an id of a certificate to be revoked, a random number r, and a certificate holder address; the RC _ revoke _ reply content comprises a message RC _ revoke _ request received by a resource receiver, whether the resource receiver agrees with the operation of the resource issuer, and a random number, wherein the revoke transaction message RC _ revoke comprises a resource issuer, namely an issuer of RC2, a transaction receiver, namely a holder of RC2, a transaction type, namely revocation of RC2, transaction content, namely specific content of RC2, transaction attributes, transaction evidence, namely RC _ revoke _ reply message, and a random number +1 issued by the holder of RC 2; the resource issuer of RC 2's signature for the transaction; the transaction attribute is now null.

9. The block chaining resource public key infrastructure based certificate transaction alerting method as claimed in claim 1, wherein said attribute values that are modifiable by said update operation 4.2.3.1 include certificate expiration time, integer serial number.

10. The certificate transaction warning method based on the resource public key infrastructure of the block chain as claimed in claim 1, wherein the rc _ override 1_ request content includes certificate identification to be modified, random number r, certificate holder ID; the rc _ override 1_ reply content comprises a message rc _ override 1_ request received by a resource receiver, whether the resource receiver agrees with the operation of the resource issuer, and a random number; the RC _ override 1 includes a resource issuer, namely an issuer of RC3, a resource receiver, namely a holder of RC3, a transaction type, namely RC3 update, transaction content, namely content RC 3' after modification of an RC3 certificate to be modified, transaction attributes, namely a transfer attribute and an expiration attribute, evidence of transaction, namely RC _ override 1_ reply message, a random number +1 issued by the holder of RC3, and a signature of the resource issuer of RC3 on the transaction.

11. The block chain-based certificate transaction warning method for the resource public key infrastructure as claimed in claim 1, wherein the ROA _ issue includes content of resource issuer, i.e. issuer of ROA1, resource receiver, i.e. receiver of ROA1, transaction type, i.e. ROA1 issuance, transaction content, i.e. specific content of ROA1, transaction attribute, proof of transaction, signature of transaction by resource issuer of ROA 1; the transfer attribute in the transaction attribute is null, the expiration attribute indicates whether the ROA has a deadline limit, and the proof of the transaction is null at this time.

12. The block chain-based certificate transaction warning method for the resource public key infrastructure according to claim 1, wherein the ROA _ revoke content includes an issuer of the ROA2, a holder of the ROA2, a transaction type of the ROA2 revocation, an identification of the ROA2, transaction attributes, and evidence of the transaction, and the resource issuer of the ROA2 signs the transaction, and the transaction attributes and the evidence of the transaction are both empty at this time.

13. The block chaining resource public key infrastructure based certificate transaction alert method as in claim 1 wherein the method by which the issued ROA that conflicts with the pre-issued ROA1 is revoked at step 4.2.5.2.5 is the ROA revocation method of 4.2.6.

14. The method for warning the certificate transaction of the resource public key infrastructure based on the block chain as claimed in claim 1, wherein the method for checking whether rc _ issue was previously submitted in 4.2.1.7.1 steps of the resource certificate transaction intelligent contract, checking whether rc _ revoke was previously submitted in 4.2.2.5.1 steps of the resource certificate transaction intelligent contract, checking whether rc _ issue 1 was previously submitted in 4.2.3.4.1 steps of the resource certificate transaction intelligent contract, checking whether roa _ issue was previously submitted in 4.2.5.5.1 steps of the resource certificate transaction intelligent contract, and checking whether roa _ revoke was previously submitted in 4.2.6.3.1 steps of the resource transaction successful block chain to check whether the corresponding message was previously submitted in the transaction record.