CN114401091B - Device cross-domain authentication management method and device based on block chain - Google Patents

Device cross-domain authentication management method and device based on block chain Download PDF

Info

Publication number
CN114401091B
CN114401091B CN202111545634.1A CN202111545634A CN114401091B CN 114401091 B CN114401091 B CN 114401091B CN 202111545634 A CN202111545634 A CN 202111545634A CN 114401091 B CN114401091 B CN 114401091B
Authority
CN
China
Prior art keywords
equipment
merck tree
management department
institution
merck
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202111545634.1A
Other languages
Chinese (zh)
Other versions
CN114401091A (en
Inventor
刘懿中
刘建伟
邢馨心
关振宇
孙钰
李大伟
李东禹
杨林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beihang University
Original Assignee
Beihang University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beihang University filed Critical Beihang University
Priority to CN202111545634.1A priority Critical patent/CN114401091B/en
Publication of CN114401091A publication Critical patent/CN114401091A/en
Application granted granted Critical
Publication of CN114401091B publication Critical patent/CN114401091B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem
    • H04L2209/463—Electronic voting

Abstract

The application discloses a device cross-domain authentication management method and device based on a blockchain, an electronic device and a storage medium, wherein the method comprises the following steps: adding a plurality of institution management departments to an institution alliance committee according to a voting mechanism; updating the root value of the merck tree in a plurality of institution management departments and storing the root value of the merck tree into an intelligent contract; when the lending equipment requests, the lender confirms that the equipment lending condition is met according to the generated equipment merck tree evidence and the merck tree root value in the intelligent contract, and signs and trades by the two parties and uploads the trade to the blockchain when the two party gater is used for carrying out equipment handover, so that the local state is updated; when the equipment is returned and borrowed, the returning party generates an equipment merck tree evidence, and the local state is updated by signing and uploading the transaction to the blockchain while the equipment is handed over by using the gating devices of the two parties. The device cross-domain management has safety and expandability, can prevent various threats and attacks, and protects private data of users and devices from being revealed.

Description

Device cross-domain authentication management method and device based on block chain
Technical Field
The present application relates to the field of information security technologies, and in particular, to a device cross-domain authentication management method and apparatus based on blockchain, an electronic device, and a storage medium.
Background
In the internet of things and in many fields, the number of devices is numerous, and sharing of devices and resources exists between different enterprises and organizations. In this scenario, cross-domain authentication management of the device is required.
In the process of device exchange, sharing, management, there are many problems to be solved, such as access control, authentication device tracking, etc. In addition, most devices contain sensitive and private data for many businesses or users, and once the data is lost, huge economic losses are incurred for the relevant businesses, resulting in very bad consequences. Therefore, a secure device management scheme is necessary to prevent unauthorized users from accessing and using these critical devices. In addition, considering the mass characteristics of devices in some internet of things scenarios, the device management scheme must have scalability and high throughput. High throughput means that the system can handle a large number of cross-domain device ingress and egress requests per second, and scalability means that the system's ability to handle requests can be enhanced as the number of participating nodes in the network increases.
Existing device cross-domain authentication management schemes can be divided into two broad categories. The first is based on symmetric cryptography and key management protocols, such as Kerberos protocol. However, this approach to management is inefficient, and thus, the protocol typically requires multiple rounds of message computation and transmission by the participants, and the communication complexity is high. The second category is to use digital certificates to authenticate the identity of the device with the participation of an authentication center (Certificate Authority, CA). However, most of the existing schemes are realized by a trusted third party, so that single-point faults are easy to occur, and the usability of the system is poor.
The blockchain technology can be used in the identity authentication process to overcome the defects of the prior scheme and provide a safer, more reliable and more efficient device cross-domain authentication management solution. Blockchains can be viewed as public, non-tamperable, distributed databases that are commonly maintained by terminal participating nodes in the network by some established rules of consensus. The decentralization, tamper-resistance, transparency, etc. characteristics of the blockchain enable it to be considered a trusted platform upon which authentication protocols can be built. In addition, intelligent contracts can be deployed on blockchain to implement automatically executed program logic. The blockchain and intelligent contract technology is applied to the field of equipment cross-domain management, so that the limits of the safety and throughput of the previous scheme can be broken, and a more efficient and safer system can be constructed.
Disclosure of Invention
The application provides a device cross-domain authentication management method and device based on a blockchain, electronic equipment and a storage medium, and aims to solve the problems that a trusted third party is needed for realizing the cross-domain authentication, three-point faults are easy to occur, and usability is poor.
An embodiment of a first aspect of the present application provides a blockchain-based device cross-domain authentication management method, including the steps of: s1, adding a plurality of organization management departments into an organization alliance committee S2 according to a voting mechanism, updating the root value of the merck tree in the plurality of organization management departments, and storing the root value into an intelligent contract; s3, when a second organization management department sends a device lending request to a first organization management department, generating a device merck tree evidence of the first organization management department, and when the condition of the device lending is met according to the device merck tree evidence and the merck tree root value in the intelligent contract, signing a transaction by using two gating devices of the two parties and uploading the transaction to a blockchain at the same time of device handover, and updating the local state; and S4, when the second organization management department returns the lending equipment to the first organization management department, generating the merck tree evidence of the equipment of the second organization management department, signing the transaction by the two parties while carrying out equipment handover by using the gate controllers of the two parties, uploading the transaction to a block chain, and updating the local state.
Optionally, in one embodiment of the present application, the joining the plurality of institutional management units to the institutional federation committee according to a voting mechanism includes: generating bilinear pair public parameters locally by each member in an organization management department to be added into the organization alliance committee, randomly selecting a self public key and a public key certificate corresponding to self private key calculation by each member, sending the self public key and the public key certificate to an authentication center, comparing the public keys by using the calculation of the authentication center, adding legal public keys into a public key list after verifying the validity of the public keys, and broadcasting the public key list to each member in the organization alliance committee after the number of legal public keys in the public key list reaches a first preset number; sending a joining request to the institution alliance committee through an institution management department to be joined in the institution alliance committee, and calling an intelligent contract to vote on the institution management department when the institution alliance committee joins in mind; counting the number of votes in a preset time, and adding the institution management department into the institution alliance committee when the number of votes is larger than the preset number of votes.
Optionally, in one embodiment of the present application, updating the merck tree root values in the plurality of institution management departments includes: acquiring equipment data of each equipment in a mechanism and recording the equipment data into a local database, wherein the equipment data comprises equipment identity information, state information, place information and time information; integrating the device data of each device, calculating the hash value of the device data, constructing a merck tree by taking each device data as a merck leaf node, and calculating the root hash value of the merck tree; and calling the intelligent contract, and uploading the Merker tree root hash value to the intelligent contract.
Optionally, in one embodiment of the present application, the S3 includes: signing device data through each member of the second institution management department, generating signature shares of each member by utilizing a signature share generating algorithm of an aggregate signature, sending signature information to a leader of the second institution management department by each member, verifying the validity of each signature share through the leader, adding the legal signature shares into a public key list, calculating information such as a total signature, a total public key and the like by the leader through the aggregate signature algorithm when the number of the effective signature shares in the public key list reaches a second preset number, constructing a request message, sending the request message to the first institution management department, verifying the validity of the public key and the signature in the search request message by the first institution management department, inquiring the current state of the borrowing device after verification is passed, and returning a confirmation message to the second institution management department when the borrowing device allows borrowing; generating a merck tree evidence of the lending equipment in the first institution management department, changing the state of the lending equipment in a local database, and writing the merck tree evidence and equipment data into a radio frequency identification tag of the lending equipment; when the equipment is handed over, a first gate controller corresponding to the first mechanism management department scans the radio frequency identification tag of the lending equipment to obtain equipment data and Merck tree evidence, and calculates to obtain a Merck tree root hash value according to the scanned data, and meanwhile, the first gate controller inquires the Merck tree root value of the mechanism corresponding to the first mechanism management department in an intelligent contract, and when the two values are equal, the lending equipment is handed to a second gate controller corresponding to the second mechanism management department for verification; after the second gatekeeper passes the verification, the two parties sign the transaction and upload the transaction to the blockchain, and update the state of the lending device in a local database, and simultaneously recalculate the merck tree root hash values of the first and second institution management departments and store the merck tree root hash values in the intelligent contracts.
Optionally, in one embodiment of the present application, the S4 includes: calculating by the second mechanism management department to obtain a device data hash value and a merck tree evidence thereof, and storing the device data hash value and the merck tree evidence into a radio frequency identification tag of the device; after the radio frequency identification tag is scanned by the second gate controller, calculating the root value of the Merck tree, and when the root value of the Merck tree is equal to the root value in the intelligent contract, transferring the lending equipment to the first gate controller; and scanning the radio frequency identification tag by the first gate controller to calculate the Merck tree root value, signing a transaction by both parties and uploading the transaction to a blockchain when the Merck tree root value is equal to the tree root value in the intelligent contract, updating the state of the lending equipment in a local database, and simultaneously, recalculating the Merck tree root hash values of the first mechanism management department and the second mechanism management department and storing the Merck tree root hash values in the intelligent contract.
Optionally, in one embodiment of the application, the smart contract includes a plurality of functions to conduct the institutional federation committee voting, merck tree root value updating, and query contract and the lending device handoff.
An embodiment of a second aspect of the present application provides a blockchain-based device cross-domain authentication management apparatus, including: a joining module for joining the plurality of institution management departments to the institution alliance committee according to the voting mechanism; the updating module is used for updating the root values of the merck trees in the plurality of mechanism management departments and storing the root values into the intelligent contracts; the lending module is used for generating the device merck tree evidence of the first mechanism management department when the second mechanism management department sends a device lending request to the first mechanism management department, and signing and uploading the transaction to the blockchain by using the gates of the two parties when the device lending condition is met according to the device merck tree evidence and the merck tree root value in the intelligent contract, and updating the local state; and the return module is used for generating the merck tree evidence of the equipment of the second mechanism management department when the second mechanism management department returns the lending equipment to the first mechanism management department, signing the transaction by the two parties and uploading the transaction to the blockchain when the two parties carry out equipment handover by using the gating devices of the two parties, and updating the local state.
Optionally, in one embodiment of the application, the smart contract includes a plurality of functions to conduct the institutional federation committee voting, merck tree root value updating, and query contract and the lending device handoff.
An embodiment of a third aspect of the present application provides an electronic device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor executing the program to perform the blockchain-based device cross-domain authentication management method as described in the above embodiments.
An embodiment of a fourth aspect of the present application provides a computer-readable storage medium having stored thereon a computer program that is executed by a processor to perform the blockchain-based device cross-domain authentication management method as described in the above embodiment.
The device cross-domain authentication management method and device based on the blockchain, the electronic device and the storage medium provided by the embodiment of the application design the blockchain and the intelligent contract technology and have the beneficial effects that:
1) Device cross-domain management has utility. Different organizations can manage their own devices and data using different management systems, only with periodic updates to the merck tree root hash value of all their device data using the smart contract on the disclosed blockchain. When the equipment is handed over, the equipment can be realized by only needing a simple verification step.
2) Device cross-domain management has privacy preserving features. Each organization forms the device data into the merck tree, only the root hash value is uploaded to the intelligent contract disclosure, and the privacy data of the device and the user are not disclosed. In the process of equipment handover, only two handover parties can acquire equipment data, so that the privacy protection of the data is realized.
3) Device cross-domain management has security. The design of each step of equipment management and intelligent contracts considers the malicious behaviors possibly initiated by an attacker, and can effectively prevent distributed denial of service attacks, witches attacks, counterfeiting attacks and the like through security measures.
4) Device cross-domain management is scalable. In one aspect, the OAC can allow multiple institutions to join as members, with member joining and exiting requiring only voting by the OAC. On the other hand, the process of calculating and generating the merck tree root is scalable for each organization administration OAD, enabling the administration of millions and tens of millions of levels of device data. Through calculation verification, the merck tree formed by 100 ten thousand devices only takes 2.65 seconds to calculate the root of the merck tree. Therefore, the scheme can realize the effective and safe cross-domain management of the mass equipment.
Additional aspects and advantages of the application will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the application.
Drawings
The foregoing and/or additional aspects and advantages of the application will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a flow chart of a method for device cross-domain authentication management based on blockchain according to an embodiment of the present application;
FIG. 2 is a block diagram of a block chain based device cross-domain authentication management method according to an embodiment of the present application;
fig. 3 is a schematic diagram of a device cross-domain authentication management system according to an embodiment of the present application;
FIG. 4 is a flow chart of a device lending process provided in accordance with an embodiment of the present application;
FIG. 5 is a device return flow chart provided in accordance with an embodiment of the present application;
FIG. 6 is an example diagram of a blockchain-based device cross-domain authentication management apparatus in accordance with an embodiment of the application;
fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the application.
Detailed Description
Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to like or similar elements or elements having like or similar functions throughout. The embodiments described below by referring to the drawings are illustrative and intended to explain the present application and should not be construed as limiting the application.
The block chain-based device cross-domain authentication management method has the characteristics of protecting device privacy data, along with safety, high throughput and strong expandability. The main purpose is as follows: first, device information sharing and device cross-domain authentication are achieved through a blockchain and an intelligent contract. By establishing an institutional coalition committee, committee members are able to monitor and manage device status. The device information is stored in each institution database in the form of a merck tree whose root hash value is associated with all the device information, and is stored by the authorities on the smart contract. The device cross-domain authentication process is accomplished by comparing the merck tree root value on the chain with the calculated root value off the chain. Second, various threats and attacks can be prevented. The device cross-domain authentication management method based on the blockchain can effectively resist distributed denial of service attack, witch attack, fake attack and the like, and can well guarantee the safety of the system. Third, the privacy data of the user and the equipment can be protected from being revealed. The device data is stored in the database of the corresponding mechanism in a ciphertext mode, on the public blockchain, only the merck tree root value obtained by calculating all the device information is stored, and the device privacy data cannot be revealed in the authentication and cross-domain use processes of the device.
In an embodiment of the present application, a total of six entities are included:
1) Institution management (Organization Administration Department, OAD): the organization administration is responsible for updating the merck tree root hash value stored on the smart contract. Meanwhile, the organization management department is responsible for managing the Internet of things equipment. An organization's management typically contains n members, which use an aggregate signature to effect authentication. In the organization, the condition that n is equal to or greater than 2f+1 is required to be satisfied, and f represents the number of malicious nodes.
2) Institutional alliance committee (Organization Alliance Committee, OAC): the institutional federation committee is made up of a plurality of institutional administration OADs. The committee members are responsible for the deployment and management of intelligent contracts. In addition, the organization union committee decides together by voting whether or not a certain organization administration OAD can join the committee OAC.
3) Device (D): each device is assigned a unique identity identifier ID and each device is managed by the institution authority OAD to which it belongs. Each device is labeled with a radio frequency identification (Radio Frequency Identification, RFID) tag in which device information, such as device identity information and merck certificates, is stored.
4) Gate Controller (GC): the gate controller is responsible for the identity authentication of the organization equipment and controls the equipment to enter and exit. The gater obtains information of the equipment and corresponding merck tree evidence through RFID on the scanning equipment, and calculates the merck tree root hash value through the information. Meanwhile, the gate controller is connected to the blockchain network, and obtains the Merker tree root hash value stored in the intelligent contract through inquiry. Then, the gate controller determines whether the device authentication is successful or not by comparing whether the two hash values are the same or not, and further determines whether the subsequent device operation is performed or not.
(5) Blockchain network (Blockchain Network): with a blockchain network that supports intelligent contracts, blockchains can ensure that overt, traceable, and non-tamperable features are implemented.
(6) Smart Contract: the intelligent contracts are responsible for managing and storing the equipment information for each committee member institution. The smart contract contains five specific functions: adding members, deleting members, updating the root value of the merck tree, inquiring the root value of the merck tree, and handing over equipment.
Fig. 1 is a flowchart of a device cross-domain authentication management method based on blockchain according to an embodiment of the present application.
As shown in fig. 1, the blockchain-based device cross-domain authentication management method includes the following steps:
in step S1, a plurality of institutional management units are joined in an institutional federation committee according to a voting mechanism.
In an embodiment of the present application, joining a plurality of institutional management units to an institutional federation committee according to a voting mechanism includes:
generating bilinear pair public parameters locally by each member in an organization management department to be added into an organization alliance committee, randomly selecting a private key of each member to calculate a corresponding self public key and a public key certificate, sending the self public key and the public key certificate to an authentication center, comparing the public key with each other by using the calculation of the authentication center, adding a legal public key to a public key list after verifying the validity of the public key, and broadcasting the public key list to each member in the organization alliance committee after the number of the legal public keys in the public key list reaches a first preset number; sending a joining request to the organization alliance committee through an organization management department of the organization alliance committee to be joined, and calling an intelligent contract to vote on the organization management department when the organization alliance committee joins in mind; counting the number of votes in a preset time, and adding the institution management department into the institution alliance committee when the number of votes is larger than the preset number of votes.
The step is the management department of the organizationOAD joining the institutional federation committee OAC, comprising three steps: organization administration OAD A Initialization, organization alliance committee OAC membership voting, organization administration OAD A OAC was added, specifically:
step 1: organization administration OAD A Initializing: OAD (optical axis of arrival) A Requiring the generation of bilinear pair common parameters locally. Then each member P i Will randomly select its own private key sk according to the requirement i Calculate the corresponding public key pk i . This step requires the member to calculate the public key attestation pi that generates itself, due to the adoption of a robust aggregate signature i Is used for preventing the counterfeit attack of the public key and ensuring the validity of each member for generating the public key. The member sends the public key and the certificate to the authentication center CA, and the authentication center verifies the validity of the public key through calculation and comparison and adds the legal public key to the public key list PK_OAD A Is a kind of medium. When the legal public key number in the public key list reaches a certain requirement, the CA broadcasts the public key list, the OAC receives the legal public key list, and each member stores the legal public key list.
Step 2: institutional alliance committee OAC membership voting: organization administration OAD A Sending a join request to the OAC, if the OAC member receiving the request agrees to the OAD A The intelligent contract is invoked to vote on it.
Step 3: organization administration OAD A Adding OAC: the intelligent contracts will count OAD A The number of votes obtained, if within time constraints, OAD A If a sufficient number of tickets is obtained, OAD A Successful addition to OAC.
In step S2, the merck tree root values in the plurality of institution management departments are updated and stored in the smart contracts.
In an embodiment of the present application, updating the merck tree root values in a plurality of institution management departments includes: acquiring equipment data of each equipment in the mechanism and recording the equipment data into a local database, wherein the equipment data comprises equipment identity information, state information, place information and time information; integrating the device data of each device, calculating the hash value of the device data, constructing a merck tree by taking each device data as a merck leaf node, and calculating the root hash value of the merck tree; and calling the intelligent contract, and uploading the Merker tree root hash value to the intelligent contract.
The step is for the organization administration department OAD to update the root value of the merck tree, comprising the following three steps: OAD (optical axis of arrival) A Acquiring data of each device, OAD A Calculating Merker tree root hash value and OAD A Uploading the root hash value to the smart contract. The method comprises the following steps:
Step 4: OAD (optical axis of arrival) A Acquiring data of each device: OAD (optical axis of arrival) A The data of each device in the organization is acquired locally and recorded in a local database, and the device data should include device identity information, status information, location information, and time information.
Step 5: OAD (optical axis of arrival) A Calculating the root hash value of the merck tree: OAD (optical axis of arrival) A Integrating the information of each device, calculating the hash value of the information, constructing a merck tree by taking each device data as merck leaf nodes, and calculating the root hash value mr of the merck tree A 。
Step 6: OAD (optical axis of arrival) A Uploading the root hash value to the intelligent contract: OAD (optical axis of arrival) A Calling an intelligent contract to calculate the obtained Merker tree root hash value mr A Uploading to the smart contract.
In step S3, when the second organization management department sends a device lending request to the first organization management department, a device merck tree proof of the first organization management department is generated, and when the device lending condition is met according to the device merck tree proof and the merck tree root value in the intelligent contract, both sides sign the transaction and upload the transaction to the blockchain while the two sides of gatekeepers are used for device handover, so as to update the local state.
In an embodiment of the present application, S3 includes: signing the device data by each member of the second institution management department, generating a signature share of each member by utilizing a signature share generating algorithm of the aggregate signature, sending a signature message to a leader of the second institution management department by each member, verifying the legitimacy of each signature share by the leader, adding the legal signature share into a public key list, calculating information such as a total signature, a total public key and the like by the leader through the aggregate signature algorithm when the number of the effective signature shares in the public key list reaches a second preset number, constructing a request message, sending the request message to the first institution management department, verifying the legitimacy of the public key and the signature in the search request message by the first institution management department, inquiring the current state of the borrowing device after the verification is passed, and returning a confirmation message to the second institution management department when the borrowing device is allowed; generating a merck tree evidence of the lending equipment in the first mechanism management department, changing the state of the lending equipment in a local database, and writing the merck tree evidence and equipment data into a radio frequency identification tag of the lending equipment; when the equipment is handed over, a first gate controller corresponding to a first mechanism management department scans a radio frequency identification tag of lending equipment to obtain equipment data and Merck tree evidence, and calculates to obtain a Merck tree root hash value according to the scanned data, and meanwhile, the first gate controller inquires the Merck tree root value of a mechanism corresponding to the first mechanism management department in an intelligent contract, and when the two values are equal, the lending equipment is handed to a second gate controller corresponding to a second mechanism management department for verification; after the second gatherer passes the verification, the two parties sign the transaction and upload the transaction to the blockchain, and update the state of the lending equipment in the local database, and simultaneously recalculate the Merker tree root hash values of the first institution management department and the second institution management department and store the hash values in the intelligent contract.
This step is the organization administration OAD B To OAD A Borrowing equipment D A Wherein the first institution management department is OAD A The second institution management department is OAD B Lending device D A The method comprises four steps: OAD (optical axis of arrival) B To OAD A Send request, OAD A Generating device merck tree certification, two-party gate controller authentication, handing over device, two-party signing transaction uploading to the blockchain and updating local state. The method comprises the following steps:
step 7: OAD (optical axis of arrival) B To OAD A Sending a request: OAD (optical axis of arrival) B To OAD A Borrowing equipment D A First, OAD B The number of devices required for each member of (a)Based on the signature, a signature share generation algorithm for aggregating the signatures is utilized to generate a signature share for each member. Each member then sends a signed message to the OAD B Is a leader of (c). The leader first verifies the legitimacy of each signature share, adding the legitimate signature share to the public key list. When the number of the effective signature shares in the public key list reaches a certain requirement, the leader calculates the information such as the total signature, the total public key and the like through an aggregate signature algorithm, constructs a request message and sends the request message to the OAD A 。
OAD A After receiving the message, verifying the validity of the public key and signature, and if the verification is passed, querying the device D A If can be lent, to OAD B An acknowledgement message is returned.
Step 8: OAD (optical axis of arrival) A Generating a device merck tree proof: OAD (optical axis of arrival) A Generating device D A And altering the state of the device in a local database, writing the merck tree evidence, device data into the RFID tag of the device.
Step 9: two-party gater authentication, handover equipment: when the equipment is connected, the equipment needs to sequentially pass through a gate controller GC A 、GC B Is verified by the verification system. GC (gas chromatography) A Device data and Merker tree evidence are obtained through RFID labels of scanning devices, and Merker tree root hash value mr 'is obtained through calculation of the data' A . At the same time, GC A Merkel tree root value mr of current organization A is queried in intelligent contract A If the two values are equal, the verification is passed, and the device is handed to the gate controller GC B 。GC B The same verification was performed.
Step 10: both parties sign the transaction upload to the blockchain and update the local state: GC (gas chromatography) B After passing the verification, the multi-signature transaction is sent to the blockchain, GC A It is also necessary to sign the transaction. The transaction being used to authenticate device D A Passes the verification of both side gates and the device has arrived at the GC B Where the device handover is completed. OAD (optical axis of arrival) A The state of the device needs to be updated in the local database as borrowed, OAD B Device D A Marked as D A-B Adding device D to a database A-B Both parties need to recalculate the merck tree root hash value and upload it to the smart contract for recording.
In step S4, when the second institution management department returns the lending device to the first institution management department, a merck tree proof of the device of the second institution management department is generated, and both parties sign the transaction and upload the transaction to the blockchain while the two parties use the gatekeeper of the two parties to perform the device handover, thereby updating the local state.
In one embodiment of the application, S4 comprises: calculating to obtain a device data hash value through a second mechanism management department and a merck tree evidence thereof, and storing the device data hash value into a radio frequency identification tag of the device; after the radio frequency identification tag is scanned by the second gate controller, calculating the root value of the Merck tree, and when the root value of the Merck tree is equal to the root value in the intelligent contract, transferring the lending equipment to the first gate controller; and scanning the radio frequency identification tag by the first gate controller to calculate the Merker tree root value, signing transactions by both parties and uploading the transactions to the blockchain when the Merker tree root value is equal to the tree root value in the intelligent contract, updating the state of the lending equipment in the local database, and simultaneously, recalculating the Merker tree root hash values of the first organization management department and the second organization management department and storing the Merker tree root hash values in the intelligent contract.
This step is the organization administration OAD B Device D A Return to OAD A The method comprises the following three steps: OAD (optical axis of arrival) B Generating device merck tree certification, two-party gate controller authentication, handing over device, two-party signing transaction uploading to the blockchain and updating local state. The method comprises the following steps:
step 11: OAD (optical axis of arrival) B Generating a device merck tree proof: OAD (optical axis of arrival) B By computing the device data hash value and its merck tree proof, will (d A-B ，mproof A-B ) Stored in the RFID tag of the device.
Step 12: two-party gater authentication, handover equipment: OAD (optical axis of arrival) B Returning the device to OAD A The devices need to pass through the gate controller GC in turn B 、GC A Is verified by the verification system. GC B Obtained by scanning RFID (d A-B ，mproof A-B ) Obtaining the Merker tree root value mr 'through calculation' B Obtaining a tree root value mr by inquiring intelligent contracts B If the two values are equal, the verification passes and the device is handed over to the GC A Where it is located. GC (gas chromatography) A Scanning RFID acquisition (d A ，mproof A ) Obtaining the Merker tree root value mr 'through calculation' A Obtaining a tree root value mr by inquiring intelligent contracts A If the two values are equal, the verification passes.
Step 13: both parties sign the transaction upload to the blockchain and update the local state: GC (gas chromatography) A After verification passes, the multi-signature transaction is signed and sent to the blockchain network. Also GC B The transaction needs to be signed, the device is verified, and the device handoff is completed. OAD (optical axis of arrival) B Deleting device D in local database A-B Data of (a), OAD A Updating the device state in the local database, both parties need to recalculate the merck tree root hash value and upload it to the smart contract for recording.
Further, in an embodiment of the present application, the smart contracts include a variety of functions to conduct institutional union board voting, merck tree root value updating, query contracts, and lending device interfacing.
Specifically, the intelligent contracts of the embodiments of the present application are used for OAC add members, member vote, delete member contracts, merck tree root value update and query contracts, and equipment handoff contracts. In particular, the method comprises the steps of,
OAC adds members, votes for members, deletes contracts for members: the OAC add member is implemented using an addmembrane () function. The function only allows current OAC member calls to vote on the newly added member. The new member gets votes that exceed the threshold and within the time limit, the current round of voting is considered successful and the new member joins the OAC successfully.
The member voting is realized by adopting a Vote () function, and the voting number of new members is counted.
The deletion of the members is realized by adopting a DelMember () function, the members needing to exit in the OAC also need to initiate a request, all the members vote on the request, and after the voting passes, the members exit successfully.
Merck tree root value update and query contract: the merck tree root value update is implemented by the updatermr () function. Only members of the OAC can call the function and only update their corresponding merck tree root values.
The merck tree root value query is realized through a LookupMR () function, and the function can be called by any party to query the tree root value uploaded by a management department of a certain organization.
Device handover contracts: device handoff is accomplished through the handle () function. Also, the function can only be invoked by OAC members to record data generated during the handover of the device, such as information about the sender of the device, the receiver of the device, the time of handover, the location of handover, etc.
With the above, each organization of the present application includes an organization administration OAD, a gate GC, and a device D. The plurality of organization administration OAD together constitute an organization union committee OAC. When a new member wants to join the committee, it needs to vote by the institutional federation committee member. The devices of each organization are managed by their respective organization administration OAD, all device information being stored in the local database of the organization in the form of a merck tree. At intervals, the OAD calculates the merck tree root hash value of its device constituents and uploads it to the smart contract. For a certain device D to be lent, the corresponding organization administration department OAD calculates to obtain the corresponding merck tree evidence, and the merck tree evidence is written into the RFID tag of the device D. The gate controller GC of the mechanism obtains the Merker tree evidence by scanning the device RFID, further calculates and obtains the Merker tree root hash value, compares the Merker tree root hash value with the tree root hash value on the intelligent contract, considers that the authentication is passed if the two values are equal, and releases the device D. The authentication process is similar for the receiving structure. The process of returning the device corresponds to this.
The block chain-based device cross-domain authentication management method of the present application is described in detail below with reference to the accompanying drawings and specific embodiments.
As shown in fig. 2 and 3, the present application includes the following 5 stages, using 3 kinds of collision-resistant one-way hash functions:
Hash 0 ：{0，1} * →{0，1} * ，
1. the organization administration OAD joins the organization alliance committee OAC phase
Step 1: organization administration OAD A Initializing:
(1)OAD A comprising n A And the members. For a certain member P i It establishes a bilinear pair as follows:
(2) Member P i The private key, public key and public key are calculated as follows:
(3) Member P i Its public key and certificate (pk i ，π i ) Sent to the authentication center CA, which verifies the validity of the public key by the following formula:
e(π i ，g 2 )＝e(Hash 1 (pk i )，pk i )
(4) If the verification passes, the CA will OAD A The public key list of (1) is set as follows:
PK_OAD A ：＝PK_OAD A ∪{pk i }
(5) When the condition |PK_OAD is satisfied A |＝n A When CA lists PK_OAD with public keys A Broadcast, then organization OAD A Is the leader L of (2) A List public keys PK _ OAD A To the alliance committee OAC.
Step 2: office alliance committee OAC member voting
Each member of OAC verifies the public key list pk_oad A Is the legitimacy of (2). Agreement on OAD in OAC A Members joining the federation committee send transactions to the smart contract, calling the function addmembrane () of the smart contract. The intelligent contract will automatically count.
Step 3: organization administration OAD A Adding OAC
If the mechanism OAD A The ticket number is enough in a set time, and the OAD A Will be added to the institutional federation committee OAC and the voting results will be recorded on the intelligent contract and its information will be recorded in the federation Consortium.
2. The OAD updating Merck tree root value stage of the organization management department
Step 4: OAD (optical axis of arrival) A Acquiring data of each device
A organization administration OAD A The data of each device in its department is acquired. For a certain device D A The data are as follows:
d A ：＝(id A ，status A ，place A ，time A )
wherein, id A Representing device D A Identity information of (a) is provided. status of status A The device status information is represented, and the values may be c, r, b, and f. Where c represents "can be loaned", r represents "ready to be loaned", b represents "already loaned", and f represents "loaned from other institutions". Place A Indicating where the device is stored. time of A The time of device data update is shown.
Step 5: OAD (optical axis of arrival) A Computing Merker tree root hash values
1)OAD A The hash value for each device D is calculated by the following formula:
h A ：＝Hash 0 (id A ||status A ||place A ||time A )
2)OAD A storing the hash value into a Merker tree data structure, and calculating the hash value mr of the root of the Merker tree in a bottom-up mode A Then attach the current timestamp.
Step 6: OAD (optical axis of arrival) A Uploading root hash value to intelligent contract
OAD A Invoking UpdateMR () function in the Smart contract, hashing the recently updated Merker Tree root A Uploading to the smart contract. OAD (optical axis of arrival) A The Merker tree root hash value is updated every other fixed time.
3. Organization administration OAD B To OAD A Borrowing equipment D A Stage(s)
As shown in fig. 4, step 7: OAD (optical axis of arrival) B To OAD A Sending a request
1) Mechanism OAD B To the OAD A Borrowing equipment D A ，OAD B Is a member P of (2) i To device D A The identity information signature of (a) is as follows:
2) Member P i Signature and message(s) i ，Hash(id A ) To the organization OAD) B Is the leader L of (2) B 。L B The signature list is set to an empty set: SIG_OAD B : =Φ. For each received signature share s i If the following conditions are satisfied:
(pk i ∈PK_OAD B )∧(e(s i ，g 2 )＝e(Hash 2 (Hash 0 (id A ))，pk i ))
leader L B The signature list is set as follows:
SIG_OAD B ：＝SIG_OAD B ∪{(s i ，pk i )}
3) If the condition |SIG_OAD B |=f+1, then leader L B Computing a total signature, a total public key, and a signature indication vector such asThe following steps:
for each i=1 to n B If the condition (-, pk) i )∈SIG_OAD B If yes, set b i 1. Leader L B Will borrow device request message m B The method comprises the following steps:
m B ：＝(id A ，PK_OAD B ，σ B ，apk B ，E，Hash 0 (id A ))
L B message m B Send to OAD A 。
4)OAD A After receiving the request, verifying whether the following conditions are met:
if true, OAD A Further verifying whether the following conditions are true:
e(σ B ，g 2 )＝e(Hash 2 (Hash 0 (id A ))，apk B )
If true, OAD A Verifying whether the following conditions are satisfied: OAD (optical axis of arrival) A .d A .status＝c。
If so, OAD A To OAD B Sending a reply message indicating device D A Can be used.
Step 8: OAD (optical axis of arrival) A Generating device merck tree certificates
1)OAD A Updating the device state in its local database, setting: OAD (optical axis of arrival) A .d A Status=r, reading device data d A And calculate d A Proof of mproof by merck tree of (a) A 。
(2)OAD A Device data and merck tree evidence (d A ，mproof A ) Writing to device D A Is a Radio Frequency Identification Device (RFID) tag.
Step 9: authentication and handover device for two-party gatherer
(1) When OAD B Wanting to take away device D A Gate controller GC A First of all, the device D is required A And (5) performing verification. First, a gate controller GC A Slave device D A By scanning to obtain device data and merck tree evidence (d A ，mproof A )。
(2)GC A Through (d) A ，mproof A ) Calculating to obtain Merker tree root hash value mr' A 。
(3)GC A Function LookupMR () query OAD invoking Smart contracts A Uploaded latest Merker tree root hash value mr A 。
(4) If mr' A ＝mr A Then the verification is considered to be passed; otherwise, the verification is not passed and the device is not allowed to be loaned.
(5)GC A After verification is passed, device D A Is sent to GC B Where it is located. Gate controller GC B GC was performed A The same verification before, if mr' A ＝mr A And received device data d A Device identity information id contained therein A And message m B If the identity information is the same, the verification is passed; otherwise, verify not pass, GC B Refusing to receive device D A 。
Step 10: both parties sign up for transaction upload to blockchain and update local state
(1)GC B After passing the verification, sending a multi-signature transaction to the blockchain network to prove the device D A Through gate controller GC B Is verified by the verification system. The transaction includes the time of the handoverAnd information of both parties.
(2)GC A Also require signing GC B Transactions sent to blockchain to prove D A Through GC A And GC B Device D has received A 。
(3)OAD A Updating the local state in its database, setting d A .status：＝b，d A Place: =b. At the same time, OAD B Obtain the device D wanted to borrow A And marks it as D A-B 。OAD B Calculating to obtain data d A-B The following are provided:
d A-B ：＝id A ||f||B||time A-B
4. organization administration OAD B Device D A Return to OAD A Stage(s)
As shown in fig. 5, step 11: OAD (optical axis of arrival) B Generating device merck tree certificates
(1)OAD B Hash value Hash is obtained through calculation 0 (d A-B ) And calculate D A-B Proof of mproof by merck tree of (a) A-B 。
(2)OAD B Will mprofe A-B Storage to device D A-B Still including the previous merkel tree proof mproof A 。
Step 12: authentication and handover device for two-party gatherer
(1) When OAD B Wanted return device D A-B When, gate controller GC B First of all authentication device D is required A-B . First, a gate controller GC B By scanning apparatus D A-B The above RFID tag gets its data and merck proof (d A-B ，mproof A-B ). Then, gate controller GC B By the obtained (d A-B ，mproof A-B ) Calculating Merker tree root hash value mr' B . At the same time, gate controller GC B Querying by institution administration OAD by invoking a lookepmr () function of a smart contract B Uploaded latest Merker tree root hash value mr B . If two tree rootsEqual value, pass gate controller GC B Is verified; otherwise, the verification is not passed, and the gate controller GC B To the administration OAD B And sending a rejection message.
(2) Device D A-B Through gate controller GC B Is sent to the gater GC A . Also, the equipment needs to pass through a gate controller GC when returning A Is verified by the verification system. Gate controller GC A Device data and merck tree information (d) are obtained by scanning RFID tags A ，mproof A ) Calculating to obtain Merker tree root hash value mr' A Calling intelligent contract LookupMR () function to obtain tree root value mr A . If the following conditions are satisfied, then the verification is considered to be passed; otherwise, the verification is not passed, and the gate controller GC A To the administration OAD A And sending a rejection message.
(mr′ A ＝mr A )∧(id A |id A ∈d A ＝id A-B |id A-B ∈d A-B )
Step 13: both parties sign up for transaction upload to blockchain and update local state
(1) The device passes through a gate controller GC A After verification of (C) gate controller GC A Signing a multi-signature transaction to a blockchain network, transaction attestation device D A-B (D A ) Has successfully passed GC A Is verified by the verification system.
(2) Gate controller GC B Also sign GC A Initiating a transaction, proving device D A-B Through GC B And gater GC A Device D has received A-B 。
(3) Organization administration OAD B Deleting device D A-B And updates its local database and the merck tree root hash value. Organization administration OAD A Update its local state, device D A The state of (2) is set as: d, d A .place：＝ A，d A Status: =c, a new merck tree root is computed and uploaded onto the smart contract.
5. Intelligent contract design phase
The smart contract design contains 5 different functions, the name and meaning of each parameter is shown in table 1.
TABLE 1 Smart contract common parameters
/>
Step 14: OAC adds members, member votes, and deletes member contracts
(1) Addmembrane () function. The function uses a volt () function as a subfunction. The addmembrane () function can only be called by members of the institutional alliance committee OAC. The member who agrees to join the new member initiates a transaction to the intelligent contract, calls the AddMember () function, and takes the address of the new member as the function input. The addmembrane () function will automatically count, counting the total number of votes currently. In addition, the function sets a threshold and time limit for each round of voting. The threshold value indicates that more than 1/2 of the member votes pass. The time limit refers to the time that each round of voting cannot exceed the generation time of 100 blocks. In each round, a member of the OAC can only vote for a new member. To prevent malicious nodes from launching a DDoS attack, the function addmembrane () requires that two consecutive rounds of voting objects cannot be the same new member.
When the new member joins successfully, its address will be automatically written into the lead Consortium list.
/>
(2) Vote () function. The function is used to count the number of votes for a member. When a legitimate voter votes for it, the number of votes increases by one.
(3) DelMember () function. This function can only be invoked by the OAC member to vote on members leaving the OAC. The method of operation is similar to the addmembrane () function. When a member leaves the OAC, its data will be deleted.
Step 15: merker tree root value update and query contract
(1) updateMR () function. This function can only be invoked by OAC members to upload their merck tree root hash value on the smart contract. The address of the member input mechanism and its new merck tree root hash value. Each OAC member can only update its corresponding root value. If a member wants to attempt to update the root value of other members, the function will automatically abort and return a corresponding error message.
(2) LookupMR () function. The purpose of this function is to query the merck tree root hash value stored on the smart contract.
Step 16: device handover contracts
And a handle () function. This function can only be invoked by OAC members to record device handoff information. After the verification is passed, the device receiver calls the function and takes the hash value of the address, the address of the device sender and the transaction information as input.
According to the device cross-domain authentication management method based on the block chain, device information sharing and device cross-domain authentication are achieved through the block chain and the intelligent contract. By establishing an institutional coalition committee, committee members are able to monitor and manage device status. The device information is stored in each institution database in the form of a merck tree whose root hash value is associated with all the device information, and is stored by the authorities on the smart contract. The device cross-domain authentication process is accomplished by comparing the merck tree root value on the chain with the calculated root value off the chain. Thus, various threats and attacks can be prevented, and the private data of the user and the equipment can be protected from being revealed.
Next, a blockchain-based device cross-domain authentication management apparatus according to an embodiment of the present application will be described with reference to the accompanying drawings.
Fig. 6 is an example diagram of a blockchain-based device cross-domain authentication management apparatus in accordance with an embodiment of the application.
As shown in fig. 6, the blockchain-based device cross-domain authentication management apparatus 10 includes: a joining module 100, an updating module 200, a lending module 300, and a return module 400.
Wherein, the joining module 100 is configured to join a plurality of organization administration departments to the organization union committee according to a voting mechanism. An updating module 200, configured to update the root value of the merck tree in the plurality of organization management departments, and store the root value in the smart contract. The lending module 300 is configured to generate a merck tree proof of the first organization management department when the second organization management department sends a device lending request to the first organization management department, and sign a transaction by both sides and upload the transaction to the blockchain when the merck tree proof of the first organization management department and a merck tree root value in the intelligent contract determine that the device lending condition is met according to the merck tree proof of the device and the merck tree root value in the intelligent contract, so as to update the local state. And the return module 400 is configured to generate a merck tree proof of the equipment of the second organization management department when the second organization management department returns the lending equipment to the first organization management department, sign the transaction by the two parties while performing equipment handover by using the gatekeeper of the two parties, upload the transaction to the blockchain, and update the local state.
Optionally, in one embodiment of the application, the smart contract includes a variety of functions to conduct institutional federation committee voting, merck tree root value updating, and query contract and lending device interfacing.
It should be noted that the foregoing explanation of the embodiment of the blockchain-based device cross-domain authentication management method is also applicable to the blockchain-based device cross-domain authentication management apparatus of this embodiment, and will not be repeated here.
According to the device cross-domain authentication management device based on the blockchain, which is provided by the embodiment of the application, the device information sharing and the device cross-domain authentication are realized through the blockchain and the intelligent contract. By establishing an institutional coalition committee, committee members are able to monitor and manage device status. The device information is stored in each institution database in the form of a merck tree whose root hash value is associated with all the device information, and is stored by the authorities on the smart contract. The device cross-domain authentication process is accomplished by comparing the merck tree root value on the chain with the calculated root value off the chain. Thus, various threats and attacks can be prevented, and the private data of the user and the equipment can be protected from being revealed.
Fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application. The electronic device may include:
Memory 701, processor 702, and computer programs stored on memory 701 and executable on processor 702.
The processor 702, when executing the programs, implements the blockchain-based device cross-domain authentication management method provided in the above embodiments.
Further, the electronic device further includes:
a communication interface 703 for communication between the memory 701 and the processor 702.
Memory 701 for storing a computer program executable on processor 702.
The memory 701 may include a high-speed RAM memory or may further include a non-volatile memory (non-volatile memory), such as at least one magnetic disk memory.
If the memory 701, the processor 702, and the communication interface 703 are implemented independently, the communication interface 703, the memory 701, and the processor 702 may be connected to each other through a bus and perform communication with each other. The bus may be an industry standard architecture (Industry Standard Architecture, abbreviated ISA) bus, an external device interconnect (Peripheral Component, abbreviated PCI) bus, or an extended industry standard architecture (Extended Industry Standard Architecture, abbreviated ELSA) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, only one thick line is shown in fig. 7, but not only one bus or one type of bus.
Alternatively, in a specific implementation, if the memory 701, the processor 702, and the communication interface 703 are integrated on a chip, the memory 701, the processor 702, and the communication interface 703 may communicate with each other through internal interfaces.
The processor 702 may be a central processing unit (Central Processing Unit, abbreviated as CPU) or an application specific integrated circuit (Application Specific Integrated Circuit, abbreviated as ASIC) or one or more integrated circuits configured to implement embodiments of the present application.
The present embodiment also provides a computer-readable storage medium having stored thereon a computer program, wherein the program when executed by a processor implements the blockchain-based device cross-domain authentication management method as above.
In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or N embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.
Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In the description of the present application, "N" means at least two, for example, two, three, etc., unless specifically defined otherwise.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more N executable instructions for implementing specific logical functions or steps of the process, and further implementations are included within the scope of the preferred embodiment of the present application in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the embodiments of the present application.
It is to be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, the N steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. As with the other embodiments, if implemented in hardware, may be implemented using any one or combination of the following techniques, as is well known in the art: discrete logic circuits having logic gates for implementing logic functions on data signals, application specific integrated circuits having suitable combinational logic gates, programmable Gate Arrays (PGAs), field Programmable Gate Arrays (FPGAs), and the like.
Those of ordinary skill in the art will appreciate that all or a portion of the steps carried out in the method of the above-described embodiments may be implemented by a program to instruct related hardware, where the program may be stored in a computer readable storage medium, and where the program, when executed, includes one or a combination of the steps of the method embodiments.

Claims (10)

1. The device cross-domain authentication management method based on the blockchain is characterized by comprising the following steps of:
s1, adding a plurality of institution management departments into an institution alliance committee according to a voting mechanism;
s2, updating the root values of the merck tree in the plurality of institution management departments and storing the root values to the intelligent contract;
s3, when a second organization management department sends a device lending request to a first organization management department, generating a device merck tree evidence of the first organization management department, and when the condition of the device lending is met according to the device merck tree evidence and the merck tree root value in the intelligent contract, signing a transaction by using two gating devices of the two parties and uploading the transaction to a blockchain at the same time of device handover, and updating the local state;
and S4, when the second organization management department returns the lending equipment to the first organization management department, generating the merck tree evidence of the equipment of the second organization management department, signing the transaction by the two parties while carrying out equipment handover by using the gate controllers of the two parties, uploading the transaction to a block chain, and updating the local state.
2. The method of claim 1, wherein the joining the plurality of institutional management units to the institutional federation committee according to the voting mechanism comprises:
generating bilinear pair public parameters locally by each member in an organization management department to be added into the organization alliance committee, randomly selecting a self public key and a public key certificate corresponding to self private key calculation by each member, sending the self public key and the public key certificate to an authentication center, comparing the public keys by using the calculation of the authentication center, adding legal public keys into a public key list after verifying the validity of the public keys, and broadcasting the public key list to each member in the organization alliance committee after the number of legal public keys in the public key list reaches a first preset number;
sending a joining request to the institution alliance committee through an institution management department to be joined in the institution alliance committee, and calling an intelligent contract to vote on the institution management department when the institution alliance committee joins in mind;
counting the number of votes in a preset time, and adding the institution management department into the institution alliance committee when the number of votes is larger than the preset number of votes.
3. The method of claim 1, wherein updating the merck tree root values in the plurality of institution management departments comprises:
Acquiring equipment data of each equipment in a mechanism and recording the equipment data into a local database, wherein the equipment data comprises equipment identity information, state information, place information and time information;
integrating the device data of each device, calculating the hash value of the device data, constructing a merck tree by taking each device data as a merck leaf node, and calculating the root hash value of the merck tree;
and calling the intelligent contract, and uploading the Merker tree root hash value to the intelligent contract.
4. The method according to claim 1, wherein S3 comprises:
signing device data through each member of the second institution management department, generating signature shares of each member by utilizing a signature share generating algorithm of an aggregate signature, sending signature information to a leader of the second institution management department by each member, verifying the validity of each signature share through the leader, adding the legal signature shares into a public key list, calculating information such as a total signature, a total public key and the like by the leader through the aggregate signature algorithm when the number of the effective signature shares in the public key list reaches a second preset number, constructing a request message, sending the request message to the first institution management department, verifying the validity of the public key and the signature in the search request message by the first institution management department, inquiring the current state of the borrowing device after verification is passed, and returning a confirmation message to the second institution management department when the borrowing device allows borrowing;
Generating a merck tree evidence of the lending equipment in the first institution management department, changing the state of the lending equipment in a local database, and writing the merck tree evidence and equipment data into a radio frequency identification tag of the lending equipment;
when the equipment is handed over, a first gate controller corresponding to the first mechanism management department scans the radio frequency identification tag of the lending equipment to obtain equipment data and Merck tree evidence, and calculates to obtain a Merck tree root hash value according to the scanned data, and meanwhile, the first gate controller inquires the Merck tree root value of the mechanism corresponding to the first mechanism management department in an intelligent contract, and when the two values are equal, the lending equipment is handed to a second gate controller corresponding to the second mechanism management department for verification;
after the second gatekeeper passes the verification, the two parties sign the transaction and upload the transaction to the blockchain, and update the state of the lending device in a local database, and simultaneously recalculate the merck tree root hash values of the first and second institution management departments and store the merck tree root hash values in the intelligent contracts.
5. The method of claim 4, wherein S4 comprises:
Calculating by the second mechanism management department to obtain a device data hash value and a merck tree evidence thereof, and storing the device data hash value and the merck tree evidence into a radio frequency identification tag of the device;
after the second gate controller scans the radio frequency identification tag, calculating the root value of the Merck tree, and when the root value of the Merck tree is equal to the root value in the intelligent contract, transferring the lending equipment to the first gate controller;
and scanning the radio frequency identification tag by the first gate controller to calculate the Merck tree root value, signing a transaction by both parties and uploading the transaction to a blockchain when the Merck tree root value is equal to the tree root value in the intelligent contract, updating the state of the lending equipment in a local database, and simultaneously, recalculating the Merck tree root hash values of the first mechanism management department and the second mechanism management department and storing the Merck tree root hash values in the intelligent contract.
6. The method of any of claims 1-5, wherein the smart contract includes a plurality of functions to conduct the institutional federation committee voting, merck tree root value updating, and query contracts and the lending device handoff.
7. A blockchain-based device cross-domain authentication management apparatus, comprising:
A joining module for joining the plurality of institution management departments to the institution alliance committee according to the voting mechanism;
the updating module is used for updating the root values of the merck trees in the plurality of mechanism management departments and storing the root values into the intelligent contracts;
the lending module is used for generating the device merck tree evidence of the first mechanism management department when the second mechanism management department sends a device lending request to the first mechanism management department, and signing and uploading the transaction to the blockchain by using the gates of the two parties when the device lending condition is met according to the device merck tree evidence and the merck tree root value in the intelligent contract, and updating the local state;
and the return module is used for generating the merck tree evidence of the equipment of the second mechanism management department when the second mechanism management department returns the lending equipment to the first mechanism management department, signing the transaction by the two parties and uploading the transaction to the blockchain when the two parties carry out equipment handover by using the gating devices of the two parties, and updating the local state.
8. The apparatus of claim 7, wherein the smart contract includes a plurality of functions to conduct the institutional federation committee voting, merck tree root value updating, and query contract and the lending device handoff.
9. An electronic device, comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor executing the program to implement the blockchain-based device cross-domain authentication management method of any of claims 1-6.
10. A computer readable storage medium having stored thereon a computer program, wherein the program is executed by a processor for implementing the blockchain-based device cross-domain authentication management method of any of claims 1-6.
CN202111545634.1A 2021-12-16 2021-12-16 Device cross-domain authentication management method and device based on block chain Active CN114401091B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111545634.1A CN114401091B (en) 2021-12-16 2021-12-16 Device cross-domain authentication management method and device based on block chain

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111545634.1A CN114401091B (en) 2021-12-16 2021-12-16 Device cross-domain authentication management method and device based on block chain

Publications (2)

Publication Number Publication Date
CN114401091A CN114401091A (en) 2022-04-26
CN114401091B true CN114401091B (en) 2023-10-24

Family

ID=81226429

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111545634.1A Active CN114401091B (en) 2021-12-16 2021-12-16 Device cross-domain authentication management method and device based on block chain

Country Status (1)

Country Link
CN (1) CN114401091B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117252558B (en) * 2023-11-17 2024-01-19 南京特沃斯清洁设备有限公司 Cleaning equipment management method and system based on face recognition

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107103098A (en) * 2017-05-12 2017-08-29 曾建伟 A kind of block chain net type database comprising intelligent contract and method of work
KR101849912B1 (en) * 2017-05-25 2018-04-19 주식회사 코인플러그 Method for providing certificate service based on smart contract and server using the same
KR20180041054A (en) * 2017-09-06 2018-04-23 주식회사 코인플러그 Method for providing certificate service based on smart contract and server using the same
CN107995197A (en) * 2017-12-04 2018-05-04 中国电子科技集团公司第三十研究所 A kind of method for realizing across management domain identity and authority information is shared
WO2018124718A1 (en) * 2016-12-29 2018-07-05 주식회사 코인플러그 Method for providing integrated point service by managing balance database for each block in blockchain, and support server using same
CN108711052A (en) * 2018-05-18 2018-10-26 电子科技大学 A kind of information authentication system based on block chain
CN109360100A (en) * 2018-11-13 2019-02-19 北京航空航天大学 Transaction rapid acknowledgment method and device based on block chain technology
CN110311782A (en) * 2019-04-29 2019-10-08 山东工商学院 Zero-knowledge proof method, system and the storage medium of personal information
CN111506931A (en) * 2020-05-19 2020-08-07 江苏荣泽信息科技股份有限公司 Electronic evidence management method based on block chain and cloud computing platform
CN111523855A (en) * 2020-04-16 2020-08-11 成都新敏捷链科技有限公司 Information management method and system based on block chain
WO2020220412A1 (en) * 2019-04-29 2020-11-05 山东工商学院 Zero knowledge proof-based citizen privacy protection method and system, and storage medium
CN112600875A (en) * 2020-11-25 2021-04-02 北京电力交易中心有限公司 Distributed electric quantity transaction block chain storage method and device based on Merckel tree

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11177961B2 (en) * 2017-12-07 2021-11-16 Nec Corporation Method and system for securely sharing validation information using blockchain technology
CN109345388B (en) * 2018-09-20 2020-09-08 百度在线网络技术（北京）有限公司 Block chain intelligent contract verification method and device and storage medium

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018124718A1 (en) * 2016-12-29 2018-07-05 주식회사 코인플러그 Method for providing integrated point service by managing balance database for each block in blockchain, and support server using same
CN107103098A (en) * 2017-05-12 2017-08-29 曾建伟 A kind of block chain net type database comprising intelligent contract and method of work
KR101849912B1 (en) * 2017-05-25 2018-04-19 주식회사 코인플러그 Method for providing certificate service based on smart contract and server using the same
KR20180041054A (en) * 2017-09-06 2018-04-23 주식회사 코인플러그 Method for providing certificate service based on smart contract and server using the same
CN107995197A (en) * 2017-12-04 2018-05-04 中国电子科技集团公司第三十研究所 A kind of method for realizing across management domain identity and authority information is shared
CN108711052A (en) * 2018-05-18 2018-10-26 电子科技大学 A kind of information authentication system based on block chain
CN109360100A (en) * 2018-11-13 2019-02-19 北京航空航天大学 Transaction rapid acknowledgment method and device based on block chain technology
CN110311782A (en) * 2019-04-29 2019-10-08 山东工商学院 Zero-knowledge proof method, system and the storage medium of personal information
WO2020220412A1 (en) * 2019-04-29 2020-11-05 山东工商学院 Zero knowledge proof-based citizen privacy protection method and system, and storage medium
CN111523855A (en) * 2020-04-16 2020-08-11 成都新敏捷链科技有限公司 Information management method and system based on block chain
CN111506931A (en) * 2020-05-19 2020-08-07 江苏荣泽信息科技股份有限公司 Electronic evidence management method based on block chain and cloud computing platform
CN112600875A (en) * 2020-11-25 2021-04-02 北京电力交易中心有限公司 Distributed electric quantity transaction block chain storage method and device based on Merckel tree

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
区块链共识机制研究综述;刘懿中;《密码学报》;全文 *
区块链技术及其应用场景;杨继民;徐鸿飞;;金陵科技学院学报(01);全文 *

Also Published As

Publication number Publication date
CN114401091A (en) 2022-04-26

Similar Documents

Publication Publication Date Title
US20210133359A1 (en) Permission management method, permission verification method, and related apparatus
CN113194469B (en) 5G unmanned aerial vehicle cross-domain identity authentication method, system and terminal based on block chain
CN108769230B (en) Transaction data storage method, device, server and storage medium
CN111797159A (en) Information management and access control in a database
CN111742531B (en) Profile information sharing
US8793773B2 (en) System and method for providing reputation reciprocity with anonymous identities
CN102223420A (en) Digital content distribution method for multimedia social network
CN114139203B (en) Block chain-based heterogeneous identity alliance risk assessment system and method and terminal
EP3598333A1 (en) Electronic device update management
CN114205136A (en) Traffic data resource sharing method and system based on block chain technology
CN113850599B (en) Cross-link transaction method and system applied to alliance link
CN115865418A (en) Cross-domain access control scheme based on block chain and Byzantine fault-tolerant algorithm
CN113228560A (en) Issuing apparatus and method for issuing, and requesting apparatus and method for requesting digital certificate
Wang et al. Achieving fine-grained and flexible access control on blockchain-based data sharing for the Internet of Things
Tapas et al. Blockchain-based publicly verifiable cloud storage
CN114401091B (en) Device cross-domain authentication management method and device based on block chain
CN113328854B (en) Service processing method and system based on block chain
Liu et al. A blockchain-based cross-domain authentication management system for IoT devices
Wang et al. Anonymous single sign-on schemes transformed from group signatures
CN112837023A (en) Business collaboration platform, method and device of organization and electronic equipment
WO2017210914A1 (en) Method and apparatus for transmitting information
KR20210039190A (en) Method for maintaining private information on blockchain network and device thereof
CN115913647A (en) Cross-domain device access control policy enforcement method and device based on block chain
Das et al. Design of a Trust-Based Authentication Scheme for Blockchain-Enabled IoV System
Ahmed et al. Transparency of SIM profiles for the consumer remote SIM provisioning protocol

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant