Blockchain-based ticket management system

Abstract

The application provides a kind of ticket management system based on blockchain.It includes: the first authorized agency includes multiple users: ticket data writer and ticket data reader;Second authorized agency generates corresponding credential information based on the identification information provided by the user and returns to the user;Ticket data writer provides first credential information to the first authorized agency, and ticket data reader provides second credential information to the first authorized agency;The first authorized agency sends the first key to the ticket data writer based on the first credential information, or sends the second key to the ticket data reader based on the second credential information;The sending of the first key and the second key is determined based on the consent of multiple users;Blockchain is configured to sign and store second data, and provide second data to ticket data reader;Ticket data reader is also configured to decrypt second data based on second key and determine entry qualification.The technical effect has good user identity information security and high efficiency of ticket checking process.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of blockchain, in particular to a ticket management system based on blockchain. BACKGROUND

[0002] Blockchain technology is a kind of distributed ledger technology (DLT), whose core feature is to record data in a decentralized and tamper-proof manner, ensuring transparent, traceable, secure and reliable transactions. The application of blockchain technology in the ticket management system can effectively solve the problems such as ticket fraud, fake ticket proliferation, ticket hoarding by scalpers and lack of transparency in traditional ticket management systems. However, due to its unique openness and transparency, there are problems in data ownership and user privacy protection. The traditional public-private key infrastructure makes it easy for malicious nodes to obtain user-related information, and it is also difficult to ensure user anonymity during data operation. Therefore, the information security of ticket buyers in the ticket management system is worth attention. SUMMARY

[0003] The present disclosure provides a ticket management system based on blockchain to improve the security of user identity information in the ticket management process. A ticket management system based on blockchain is provided, and ticket verification is performed between a first authorization agency, a second authorization agency and a blockchain, including: the first authorization agency, including a plurality of users, the types of the plurality of users including: a ticket data writing party and an identity information management party; the second authorization agency is configured to generate corresponding credential information based on the identification information provided by the user and return the user, the credential information being used to prove the identity of the user; the ticket data writing party is configured to provide the first authorization agency with first credential information, and the ticket data reading party is configured to provide the first authorization agency with second credential information; the first authorization agency is configured to send a first key to the ticket data writing party based on the first credential information, the first key being used to sign the first data to generate second data; or, based on the second credential information, the second key is sent to the ticket data reading party, the second key being used to decrypt the second data; wherein the sending of the first key and the second key is determined based on the consent of the plurality of users in the ticket data writing party or the ticket data reading party; the blockchain is configured to obtain the second data, and to verify and store the second data, and in response to a request of the ticket data reading party, to provide the ticket data reading party with the second data; the ticket data reading party is further configured to decrypt the second data based on the second key, and to determine the entry qualification of the ticket data writing party.

[0004] In the above ticketing management system, multiple users can register by applying for identity verification credentials from a second authorized institution. This eliminates the need for the first authorized institution to store sensitive personal information; user identity can be proven solely through the credentials. This frees ticketing data readers from managing sensitive identity information, allowing verification through credentials alone. It also reduces complex identity verification processes and improves overall information security and verification efficiency in the ticketing management process. Furthermore, when a user encrypts their own primary data, they can apply to the first authorized institution using their credentials. After identity authentication and the consent of multiple other users involved in ticketing management, a first key is sent to encrypt the primary data, creating encrypted secondary data. When other users need to read this secondary data, they must also provide their own credentials. After authentication, the remaining users jointly determine whether the user is authorized to decrypt the secondary data. With their consent, a second key is sent to decrypt the secondary data, completing the entire ticketing management process. Distributed authorization from multiple users can further enhance the security of ticketing management, prevent single-point attacks or tampering, avoid errors in single-point decision-making or abuse of permissions, and further ensure the security of the ticketing management process.

[0005] In some implementations, the blockchain is also configured to generate a first public key and a first private key based on the identification information when a second authorized institution generates credential information, and to sign the identity information determined based on the identification information based on the first private key to form credential information. The credential information includes the first public key, which is used to verify the identity information of the signature.

[0006] In some implementations, the first authorizing authority is also configured to verify the first credential information based on the first public key, and send the first key to the ticket data writer when the verification is successful and multiple users among the ticket data writer or ticket data reader agree.

[0007] In some implementations, the first authorizing authority is also configured to verify the second credential information based on the first public key, and send the second key to the ticket data reader when the verification is successful and multiple users among the ticket data writer or ticket data reader agree.

[0008] In some implementations, the ticketing data writer is also configured to sign the first data based on a first access policy, a signature policy, and a first key, generate second data, and send the second data to the blockchain. The second data includes: a signature policy, a signature result, a signature timestamp, and the ciphertext after signing.

[0009] In some implementations, the blockchain is also configured to verify the identity of the person writing the ticketing data based on a first public key, and then store the second data when the verification is successful.

[0010] In some implementations, the blockchain is further configured to verify the identity information of the ticket data reader based on the first public key, and send the second data to the ticket data reader when the verification is passed.

[0011] In some implementations, the plurality of users are further configured to determine a plurality of partial organization secrets, generate a plurality of secret sharing values based on the plurality of partial organization secrets, and share the secret sharing values among the plurality of users; and the user is further configured to generate the second private key based on the secret sharing values, and determine the second public key based on the second private key, wherein the second public key is sent to the blockchain.

[0012] In some implementations, the blockchain is further configured to generate a third key based on the second public key and a threshold secret sharing algorithm, wherein the third key is used to generate the first key or the second key, and the third key includes a third private key and a third public key, wherein the third private key is determined based on the partial organization secrets of all the plurality of users.

[0013] In some implementations, the second authorization organization includes one or more of an identity certificate information management unit, a communication information management unit, or other personal information management unit. BRIEF DESCRIPTION OF DRAWINGS

[0014] The drawings used in the following description of embodiments of the present disclosure are briefly described as follows:

[0015] Figure 1 A structure schematic diagram of a ticket management system based on a blockchain provided in some embodiments of the present application is shown. DETAILED DESCRIPTION

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure, specific embodiments of the present disclosure will be described below with reference to the drawings. The drawings in the following description are only some embodiments of the present disclosure, and for those skilled in the art, other drawings or embodiments can be obtained from these drawings or embodiments without creative labor, and adjustments and improvements made without departing from the concept of the present disclosure are within the protection scope of the present disclosure.

[0017] In order to make the drawing simple, each drawing only schematically represents the part related to the embodiments, and they do not represent the actual structure of the product. In addition, in order to make the drawing simple and easy to understand, only some structures or components are schematically shown, and there can be more or less similar structures or components.

[0018] The blockchain, as a decentralized database, solves the storage disadvantages of traditional centralized databases, supports the integrity and non-repudiation of data to a certain extent, records data in a decentralized and tamper-proof manner, and ensures transparent, traceable, safe and reliable transactions. The application of blockchain technology in the ticket management system can effectively solve the problems such as ticket fraud, fake ticket proliferation, ticket hoarding by ticket scalpers, and lack of transparency in traditional ticket management systems. However, due to its unique openness and transparency, there are problems in data ownership and user privacy protection. The traditional public-private key infrastructure makes it easy for malicious nodes to obtain user-related information, and it is also difficult to guarantee the anonymity of users in the data processing process. Therefore, the application discloses a ticket management system based on a blockchain, so that the ticket data reader does not store the sensitive identity information of the ticket purchaser, and at the same time, identity verification is realized through the blockchain technology, so that the ticket data reader does not need to perform complex verification on the identity information of the ticket purchaser when checking tickets, and only uses the received key to decrypt the encrypted data of the ticket purchaser, thereby improving the security of the identity information of the ticket purchaser and improving the efficiency of the ticket checking process.

[0019] Figure 1 A structure diagram of a ticket management system based on a blockchain is shown in some embodiments of the application. The ticket management system 100 is used for ticket verification between a first authorized institution 110, a second authorized institution 120 and a blockchain 130, which includes: the first authorized institution 110, including a plurality of users, the types of the plurality of users including: a ticket data writer 111 and a ticket data reader 112; the second authorized institution 120 is configured to generate corresponding credential information based on the identification information provided by the user and return the user, the credential information is used to prove the identity of the user; the ticket data writer is configured to provide the first authorized institution with first credential information, and the ticket data reader is configured to provide the first authorized institution with second credential information; the first authorized institution is configured to send a first key to the ticket data writer based on the first credential information, the first key is used to sign the first data to generate second data; or, based on the second credential information, the second key is sent to the ticket data reader, and the second key is used to decrypt the second data; wherein the sending of the first key and the second key is determined based on the consent of the plurality of users in the ticket data writer or the ticket data reader; the blockchain is configured to obtain the second data, and to sign and store the second data, and in response to the request of the ticket data reader, to provide the second data to the ticket data reader; the ticket data reader is further configured to decrypt the second data based on the second key, and to determine the entry qualification of the ticket data writer.

[0020] In the present application, the first authorization institution 110 is composed of parties participating in ticket management, and can include a ticket data writing party 111 and a ticket data reading party 112. The ticket data writing party 111 can include users of the consumer type, such as ordinary ticket purchasing users, VIP ticket purchasing users, and the like, and can also include users of the ticket management type, such as ticket companies, agent platforms, or other service providers related to ticket management work. The ticket data reading party 112 can also be users of the consumer type, such as ordinary ticket purchasing users, VIP ticket purchasing users, and the like, and can also include users of the ticket management type, such as ticket companies, agent platforms, or other service providers related to ticket management work. However, the ticket data writing party 111 and the ticket data reading party 112 have a relative role relationship in different ticket links. For example, in the link of entering ticket information before ticket purchase, the users of the ticket management type belong to the ticket data writing party 111, and the users of the consumer type belong to the ticket data reading party 112 when checking information after ticket purchase. For another example, in the ticket checking stage, the users of the consumer type belong to the ticket data writing party 111, and the users of the ticket management type belong to the ticket data reading party 112.

[0021] In the traditional ticket management system, in order to improve the ticket checking efficiency, the sensitive identity information of the ticket data writer 111 is often stored in the ticket data reader 112. The database of the ticket data reader 112 is limited by the information security management technology of the ticket data reader 112 enterprise, and there may be uneven management level and defense technology, and there is a risk of information leakage. In the registration stage of the ticket data writer 111 and the ticket data reader 112, that is, the second authorization institution 120 provides the identity information, and the second authorization institution 120 provides the first credential information to the ticket data writer 111 and the second credential information to the ticket data reader according to the identity information. The first identity information and the second identity information can be identity information with uniqueness, and the certificate authority will return an identity credential proving the identity information. For example, the second authorization institution 120 can sign the user identity information by generating a private key, and provide a public key for verifying the identity information, so as to realize the encryption of the user's identity information. The first credential information and the second credential information can be used as the content of identity verification in the subsequent ticket management process, so that the ticket data reader no longer needs to manage the identity sensitive information, and the verification of the identity information can be completed through the credential information, and the complex identity verification process can be reduced, and the information security and verification efficiency of the whole ticket management process are improved. The second authorization institution 120 can include one or more of an identity card information management unit, a communication information management unit, or other personal information management units, to form a highly credible identity sensitive information management institution, and the user applies to the above management institution, so that the ticket data reader 112 does not need to store the identity sensitive information, and the information security is improved.

[0022] The first authority 110 can be a set of multiple users, such as a ticket data writer 111 and a ticket data reader 112. After the ticket data writer 111 obtains the first credential information, the first data owned by the ticket data writer 111 that needs to be encrypted can be some relevant content about ticket purchase information, such as session, seat, price, and the like. For example, the ticket data writer 111 is a user of a consumer type, which can apply for a first key from the first authority 110, encrypt the first data by using the first key, and generate second data. The ticket data reader 112 can also apply for a second key from the first authority 110, which can decrypt the second data that has been encrypted to determine the entry qualification of the ticket data writer 111 and complete corresponding venue management, such as seat occupation or determination of the rights and interests of the ticket data writer 111, for example, seat level, meal package, or other content related to ticket commercial activities. For another example, the ticket data writer 111 is a user of a ticket management type, which can apply for a first key from the first authority 110, encrypt the first data by using the first key, and generate second data. The first data involves specific content such as session, seat, price, and the like, which can be decrypted by using the second key when a user of a consumer type is the ticket data reader 112 to view the specific content.

[0023] The obtaining of the first key and the second key needs the approval of the first authorization institution 110. For example, the ticket data writer 111 needs to provide the first credential information to one or more users in the preset first authorization institution 110, and these users approve the first credential information, and then the first key is issued to the ticket data writer 111 to realize the encryption of the first data. For example, the application of the first key needs to pass the approval of the preset multiple users for the first credential information, and then the first authorization institution 110 sends the first key to the user. For another example, the application of the second key needs to pass the approval of the preset multiple users for the second credential information, and then the second key can be sent. In the signature and decryption link, through the distributed approval of multiple users, the security of the ticket management can be further improved, and single-point attack or tampering can be prevented. If only one user (the identity type is unique and the number of users is unique) is responsible for distributing the key, once the user is attacked or maliciously operated, the whole system may face risks. By setting multiple users in the first authorization institution 110 to jointly decide, the mistake of single-point decision or abuse of power can be avoided. For example, the ticket management system allows VIP users to apply for high-priority ticket purchase rights (such as “purchasing concert tickets 24 hours in advance”). The applicant must pass the joint review of multiple users in the first authorization institution 110 to ensure that the identity is real and the application is legal. The ticket data writer 111 submits an application, declares that he is a VIP member, and hopes to obtain a key to unlock the VIP ticket purchase right. The first credential information formed by the identity proof (such as an ID card, a membership card) and the related attribute information is provided to apply for the first key. User A of the first authorization institution 110 verifies the membership of the ticket data writer 111 and signs the agreement. User B of the first authorization institution 110 verifies the ticket purchase record of the ticket data writer 111 and confirms that it meets the VIP upgrade condition. User C of the first authorization institution 110 verifies that the system detects that the membership card of the ticket data writer 111 is not expired. The first authorization institution 110 can authorize the ticket purchaser 111 with the first key, which is used to digitally sign the ticket purchase data after the ticket purchase.

[0024] For example, ticket data reader 112 is responsible for verifying the authenticity and validity of ticket data at the event site. The first authorized institution 110 includes multiple users, including: ticket platform administrators responsible for managing ticket records; and event organizers authorized to generate keys required by ticket data writers and ticket data readers. The blockchain 130 stores encrypted ticket data and signatures, which are publicly verifiable. After ticket data writer 111 completes ticket purchase, the system generates a ticket data, including: name, ticket purchase time, seat information, etc. Ticket data writer 111 applies for a first key from first authorized institution 110 through its own first credential information, and after the consent of multiple users of first authorized institution 110, signs the ticket data. The signed data is uploaded to the blockchain together with the ticket information (in encrypted form). Ticket data reader 112 needs to obtain the above encrypted data, and scans the electronic ticket of the ticket purchaser at the event site. The multiple users of the first authorized institution 110 verify the identity of the ticket data reader 112, and after all pass, issue a second key to the ticket data reader 112, and decrypt the above ticket data. If the verification is passed, the authenticity and validity of the ticket data are confirmed. The present application can prevent ticket information from being counterfeited, and the encrypted ticket data can only be decrypted and viewed by authorized ticket data readers 112. The above process involves data chaining, and the characteristics of traceable blockchain records can verify all signatures and encryption at any time, thereby improving the security of the ticket management system. The blockchain 130 stores the second data after verifying the signature of the second data and determining that the second data has not been tampered with. When ticket data reader 112 requests to obtain the second data, ticket data reader 112 can be verified, further ensuring the security of the ticket management process.

[0025] In some embodiments of the present application, the blockchain 130 is further configured to generate, based on the identification information, a first public key and a first private key when the second authority 120 generates the credential information, and to sign, based on the first private key, identity information determined based on the identification information to form the credential information, the credential information including the first public key, the first public key being used to verify the signed identity information. For example, a user (such as the ticket data writer 111 or the ticket data reader 112) submits his / her identification information to the second authority 120 to prove his / her identity and apply for credential information, such as a token. This token is bound to the user's identity information and authority. After verifying the user's identity, the second authority 120 generates the credential information and binds it to the user's identification information. The credential information can include encrypted user information, validity period, authority, and other data. The blockchain 130 can store and record it. In order to prevent tampering and forgery, the blockchain 130 is used as a reliable storage medium by taking advantage of its tamper-proof and decentralized characteristics, ensuring the validity of the credential information and the authenticity of the user's identity. The decentralized feature means that there is no single central entity that can modify or delete these records, increasing the security and credibility of the system. Traditional token issuance mechanisms may rely on a single database or centralized system, and attackers can commit fraud by tampering with the database or duplicating tokens. After using the blockchain, all identification information and credential information are protected by the encryption of the blockchain, and once recorded, they cannot be modified. Therefore, even malicious users cannot forge or tamper with them. The blockchain 130 also has traceability, and each record on it has a timestamp, so the issuance time of the credential information, modification records, etc. can be traced, ensuring that in the event of a dispute, the authenticity and legality of the credential information can be proven through the blockchain records.

[0026] In some embodiments of the present application, the first authority 110 is further configured to verify the first credential information based on the first public key, and to send the first key to the ticket data writer when the verification is passed and multiple users among the ticket data writer, the ticket data reader, or the identity information manager agree.

[0027] In some embodiments of the present application, the first authority 110 is further configured to verify the second credential information based on the first public key, and to send the second key to the ticket data reader when the verification is passed and multiple users among the ticket data writer, the ticket data reader, or the identity information manager agree.

[0028] The issuance of keys in the ticket system is managed through the blockchain 130, signature verification of credential information, and multi-party agreement mechanism, which improves the security, transparency, traceability, and attack resistance of the system. It effectively prevents forgery and abuse, while ensuring the privacy protection of ticket information, and provides a decentralized and trustworthy infrastructure for verification and authorization.

[0029] In some embodiments of the present application, the ticket data writer 111 is further configured to sign the first data based on the first access policy, the signature policy and the first key, generate second data, and send the second data to the blockchain 130, wherein the second data includes: the signature policy, the signature result, the signature timestamp and the signed ciphertext.

[0030] Before the ticket data writer 111 uploads the second data to the system, the first access policy can be formulated to specify which users can access the second data and which users cannot access. The core of the first access policy can be implemented by a Boolean function, which represents the access rights of the user. The attributes in the first access policy, such as the role and identity information of the user, are key factors that can decrypt and access the data. When the ticket data reader 112 applies to obtain the second data from the blockchain 130, the blockchain 130 can verify whether the ticket data reader 112 meets the access requirements of the first access policy, and only the ticket data reader 112 that meets the first access policy is allowed to obtain the second data. The signature policy is a way for the ticket data writer 111 to select how to sign the data according to certain rules and conditions, which can include how to use keys, attributes, conditions, etc. to determine which information is signed, how to manage the validity and compliance of the signature, etc. The ticket data writer 111 can control which users can access the data according to their identity attributes without relying on a centralized authorization agency for verification each time, thereby improving data privacy and security.

[0031] In some embodiments of the present application, the blockchain 130 is further configured to verify the identity information of the ticket data writer 111 based on the first public key, and store the second data when the verification is passed.

[0032] In a decentralized blockchain, anyone can upload data, so there must be a mechanism to ensure that the source of the data is legitimate, and only verified ticket buyers 111 can upload data to ensure that the ticket buyer 111 uploading the second data is a legitimate ticket owner, rather than any unauthorized third party. The blockchain verifies the identity of the user through an algorithm to prevent the uploading of fake data and malicious data. The ticket data writer 111 can sign the data by using its private key in the blockchain 130, and other users can use the corresponding public key to verify the authenticity of the data. The blockchain 130 can implement complex identity verification logic through a smart contract. For example, when the ticket buyer 111 submits a data upload application, the smart contract can check the first public key and the signature to verify whether it meets the identity authentication rules (such as whether the signature matches, whether the user's rights are sufficient, etc.), and verify the data integrity, timestamp, etc. to ensure that the second data stored in the blockchain 130 is flawless, further improving the reliability of ticket management.

[0033] In some embodiments of the present application, the blockchain 130 is further configured to verify the identity information of the ticket data reader 112 based on the first public key, and send the second data to the ticket data reader when the verification is passed.

[0034] The blockchain 130 can verify the identity of the ticket data reader 112. The identity information provided by the ticket data reader 112 is verified by the first public key to ensure that it is legitimate and trustworthy. The decentralized nature of the blockchain makes this identity verification more transparent and tamper-proof. After successful verification, the blockchain system will send the second data to the ticket data reader. The second data can allow the ticket data reader to perform further operations, such as ticket verification, access control, etc. Using public key encryption to verify the identity of the ticket data reader can prevent identity forgery or impersonation. Because only the user holding the first private key corresponding to the first public key can generate the correct signature, it can be ensured that the identity is verified after the verification is successful, so that the second data can be sent to it.

[0035] In some embodiments of the present application, the plurality of users are further configured to determine a plurality of partial organization secrets, generate a plurality of secret sharing values based on the plurality of partial organization secrets, and share the secret sharing values among the plurality of users; the user is further configured to generate a second private key based on the secret sharing value, and determine a second public key based on the second private key, wherein the second public key is sent to the blockchain.

[0036] The application can generate the second private key through a secret sharing algorithm, and multiple users determine multiple partial institutional secrets. The partial institutional secret can be a fragment or part of a secret (e.g., identity information, ticket information, etc.), which is kept by multiple different users. Each user holds a part of the secret, and no single user can independently determine the entire secret. Based on the partial secret each user holds, users exchange and combine their respective secret sharing values to ensure that no single user has the complete key. This step ensures a decentralized attribute key generation process. After all users share the secret sharing values, they can generate the final second private key based on these values. The second private key is the key to access control and data decryption. The generated second private key can be used to calculate the corresponding second public key. The second public key is sent to the blockchain 130, which can ensure that data verification and access control can be performed through the second public key. The public key record on the blockchain can ensure that the ticket data reader or data access uses the correct second public key in the identity verification process. The distributed key generation and secret sharing method can effectively prevent any single party from leaking the key, ensuring that the complete secret of the generated second private key is always under the control of multiple participants, reducing the risk of key leakage and abuse. Since the generation and management of the second key is done through the cooperation of multiple users, there is no single central authority that can control the key, and the decentralized attribute key management improves the transparency and attack resistance of the system.

[0037] In some embodiments of the application, the blockchain 130 is further configured to generate a third key based on the second public key and a threshold secret sharing algorithm, wherein the third key is used to generate the first key or the second key, and the third key includes a third private key and a third public key, wherein the third private key is determined based on the partial institutional secrets of all the multiple users.

[0038] The blockchain 130 can obtain a second public key from the first authorized institution 110, the second public key including a plurality of partial institution public keys provided by a plurality of users, and the second public key formed by the plurality of partial institution public keys can be used to generate a third key. The core idea of the threshold secret sharing algorithm is to divide the key or secret into multiple parts to ensure that the original key or secret can be reconstructed only when enough users agree to share. Therefore, the public keys of the plurality of users are stored and shared on the blockchain, and each institution can only access part of the information. The blockchain can participate in the generation or verification process of the key by selecting the public key to ensure the decentralization and security of the system. For example, the ticket data reader 112 needs to obtain the second data machine for decryption, and when the blockchain determines that it passes the verification according to the second credential information, the first authorized institution 110 needs to send the second key to it, and the generation of the second key needs to determine the third private key through the plurality of user sharing partial institution secrets in the first authorized institution 110, and then form the second key capable of decrypting the second data, for example, the second key includes the third private key, and the second key can decrypt all the contents in the second data. When the ticket data reader 112 decrypts, it does not need to access the plurality of users in the first authorized institution 110, and the plurality of users in the process of sharing the partial institution secret can also be implemented in the blockchain 130, which guarantees the security and decentralization of the data, and further improves the security of the ticket system.

[0039] In the present disclosure, unless otherwise explicitly specified and limited, ordinal words such as “first”, “second”, etc. are only used to distinguish the description of the associated objects, and cannot be understood as indicating or implying the relative importance or order between the associated objects. In addition, the ordinal words also do not represent the number of the associated objects.

[0040] “Multiple” includes two or more, and other quantifiers are similar.

[0041] The terms "or," "and / or," used in the disclosure are used to describe associations between items in an inclusive sense, that is, there existence of the associations between the items is not mutually exclusive. For example, "A and / or B" and "A or B" each can include "A," "B," or "A and B," where A and B can include singular or plural items. As another example, "A, B, and / or C," "A, B, or C," and "A, B, and C" each can include "A," "B," "C," "A and B," "A and C," "B and C," or "A, B, and C," where A, B, and C can include singular or plural items. Additionally, " / " in the disclosure is used to represent an "or" relationship between the associated items. The meanings of "at least one of A or B" and "one or more of A and B" in the disclosure are the same as the meaning of "A or B" above, and the meanings of "one or more of A, B, and C" and "at least one of A, B, or C" are the same as the meaning of "A, B, or C" above. The meaning of "one or more of A, B, and C" is the same as the meaning of "A, B, or C" above.

[0042] In the above embodiments, the description of each embodiment is focused on, and the part not described or recorded in detail in a certain embodiment can be referred to the relevant description of other embodiments. In addition, the above embodiments can be freely combined as needed.

Claims

1. A blockchain-based ticket management system, characterized in that, The ticket verification is performed among the first authorization agency, the second authorization agency and the blockchain, including: The first authorization agency includes a plurality of users, and the types of the plurality of users include a ticket data writing party and a ticket data reading party; The second authorization agency is configured to generate corresponding credential information based on identification information provided by the user and return the credential information to the user, the credential information being used to prove the identity of the user; The ticket data writing party is configured to provide first credential information to the first authorization agency, and the ticket data reading party is configured to provide second credential information to the first authorization agency; The first authorization agency is configured to send a first key to the ticket data writing party based on the first credential information, the first key being used to sign first data to generate second data, or send a second key to the ticket data reading party based on the second credential information, the second key being used to decrypt the second data; wherein the sending of the first key and the second key is based on the consent of a plurality of users in the ticket data writing party or the ticket data reading party; The blockchain is configured to obtain the second data, verify and store the second data, and provide the second data to the ticket data reading party in response to a request of the ticket data reading party; The ticket data reading party is further configured to decrypt the second data based on the second key to determine the entry qualification of the ticket data writing party.

2. The ticket management system according to claim 1, characterized by, The blockchain is further configured to generate a first public key and a first private key based on the identification information when the second authorization agency generates the credential information, sign identity information determined based on the identification information based on the first private key to form the credential information, and the credential information includes the first public key, the first public key being used to verify the signed identity information.

3. The ticket management system according to claim 2, characterized by, The first authorization agency is further configured to verify the first credential information based on the first public key, send the first key to the ticket data writing party when the verification is passed and a plurality of users in the ticket data writing party or the ticket data reading party agree.

4. The ticket management system according to claim 3, characterized by, The first authorization agency is further configured to verify the second credential information based on the first public key, send the second key to the ticket data reading party when the verification is passed and a plurality of users in the ticket data writing party or the ticket data reading party agree.

5. The ticket management system according to claim 4, characterized by The ticket data writing party is further configured to sign the first data based on a first access policy, a signature policy and the first key to generate the second data, and send the second data to the blockchain, wherein the second data includes the signature policy, a signature result, a signature timestamp and a signed ciphertext.

6. The ticket management system according to claim 5, characterized by The blockchain is further configured to verify the identity information of the ticket data writing party based on the first public key, and store the second data when the verification is passed.

7. The ticket management system according to claim 6, characterized by The blockchain is further configured to verify the identity information of the ticket data reading party based on the first public key, and send the second data to the ticket data reading party when the verification is passed.

8. The ticket management system according to claim 7, characterized by, The plurality of users are further configured to determine a plurality of partial authority secrets, generate a plurality of secret share values based on the plurality of partial authority secrets, and share the secret share values among the plurality of users; The user is further configured to generate a second private key based on the secret share value, and determine a second public key based on the second private key, wherein the second public key is sent to the blockchain.

9. The ticket management system of claim 8, wherein, The blockchain is further configured to generate a third key based on the second public key and a threshold secret sharing algorithm, wherein the third key is used to generate the first key or the second key, and the third key comprises a third private key and a third public key, wherein the third private key is determined based on the partial authority secrets of all the plurality of users.

10. The ticket management system according to any one of claims 1 to 9, wherein, The second authority comprises one or more of an identity card information management unit, a communication information management unit, or other personal information management units.

Images