Ticket business management system based on block chain

Abstract

The invention provides a ticket business management system based on a block chain. Comprises: a first authorization mechanism comprising a plurality of users: a ticket data writing party and a ticket data reading party; the second authorization mechanism correspondingly generates voucher information based on identification information provided by the user and returns the voucher information to the user; the ticket business data writing direction provides first voucher information for the first authorization mechanism, and the ticket business data reading direction provides second voucher information for the first authorization mechanism; the first authorization mechanism sends a first secret key to the ticket business data writing party based on the first certificate information; or sending a second secret key to the ticket business data reading party based on the second certificate information; sending of the first key and the second key is determined based on agreement of a plurality of users; the block chain is configured to perform signature verification and storage on the second data and provide the second data for a ticket business data reader; the ticket data reader is further configured to decrypt the second data based on the second key and determine the admission qualification. The method has the technical effects of good user identity information security and high ticket checking process efficiency.

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain technology, and in particular to a ticket management system based on blockchain. Background Art

[0002] Blockchain technology, a type of distributed ledger technology (DLT), is characterized by its decentralized, tamper-proof data recording, ensuring transparent, traceable, secure, and reliable transactions. Its application in ticketing management systems can effectively address issues inherent in traditional ticketing systems, such as ticket fraud, widespread counterfeiting, scalper hoarding, and a lack of transparency. However, due to its inherent openness and transparency, it also presents challenges with data ownership and user privacy. Traditional public and private key infrastructures make it easy for malicious nodes to obtain user information, and it is difficult to maintain user anonymity during data manipulation. Therefore, the information security of ticket purchasers in ticketing management systems warrants attention. Summary of the Invention

[0003] The present disclosure provides a ticket management system based on blockchain, in order to improve the identity information security of users in the ticket management process. A ticket management system based on blockchain is provided, wherein a first authorization agency, a second authorization agency and a blockchain perform ticket verification, including: a first authorization agency, including multiple users, the types of multiple users including: ticket data writers and identity information managers; a second authorization agency, configured to generate credential information corresponding to the identification information provided by the user and return it to the user, the credential information is used to prove the identity of the user; the ticket data writer is configured to provide the first credential information to the first authorization agency, and the ticket data reader is configured to provide the second credential information to the first authorization agency; the first authorization agency is configured to send a credential to the ticket data reader based on the first credential information. The ticket data writer sends a first key, which is used to sign the first data and generate the second data; or, based on the second credential information, the ticket data reader sends a second key, which 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 multiple users in the ticket data writer or the ticket data reader; the blockchain is configured to obtain the second data, verify and store the second data, and provide the second data to the ticket data reader in response to the request of the ticket data reader; the ticket data reader is also configured to decrypt the second data based on the second key to determine the admission qualification of the ticket data writer.

[0004] In the above ticket management system, multiple users can apply to the second authorization agency for credential information proving their identities to register. This eliminates the need for users in the first authorization agency to store sensitive information such as personal identity information. User identities can be verified using credential information, eliminating the need for ticket data readers to manage sensitive identity information. Verification of identity information can be completed using credential information, reducing complex identity authentication processes and improving the information security and verification efficiency of the overall ticket management process. Furthermore, when a user encrypts their first data, they can apply to the first authorization agency using their credential information. After identity authentication and the consent of multiple other users involved in ticket management, the first key is sent to the first user to encrypt the first data, generating encrypted second data. When other users need to read the second data, they also need to provide their own credential information. After authentication, the other users, other than the user, jointly determine whether the user is allowed to decrypt the second data. Upon consent from the other users, the second key is sent to the user to decrypt the second data, completing the entire ticket management process. Through distributed approval by multiple users, the security of ticket management can be further improved, single-point attacks or tampering can be prevented, mistakes in single-point decision-making or abuse of authority can be avoided, and the security of the ticket management process can be further ensured.

[0005] In some implementations, 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 credential information, and to sign the identity information determined based on the identification information based on the first private key to form credential information, where the credential information includes the first public key, and the first public key is used to verify the signed identity information.

[0006] In some implementations, the first authorization agency is further 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 passed and multiple users among the ticket data writer or ticket data reader agree.

[0007] In some implementations, the first authorization agency is further 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 passed and multiple users among the ticket data writer or ticket data reader agree.

[0008] In some implementations, the ticket data writer 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, wherein the second data includes: the signature policy, the signature result, the signature timestamp, and the signed ciphertext.

[0009] In some implementations, the blockchain is further configured to verify the identity information of the party writing the ticket data based on the first public key, and store the second data when the identity information is verified.

[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 identity information is verified.

[0011] In some implementations, multiple users are further configured to determine multiple partial organizational secrets, generate multiple secret sharing values ​​based on the multiple partial organizational secrets, and share the secret sharing values ​​among the multiple users; the users are further configured to generate a second private key based on the secret sharing values, and determine a 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 a partial institutional secret of all multiple users.

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

[0014] The following is a brief introduction to the drawings used in describing the embodiments of the present disclosure:

[0015] Figure 1 A schematic structural diagram of a blockchain-based ticket management system 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, the specific embodiments of the present disclosure will be described below with reference to the accompanying drawings. The drawings described below are only some embodiments of the present disclosure. For those skilled in the art, other drawings or embodiments can be obtained based on these drawings or embodiments without inventive work. Any adjustments and improvements made without departing from the concept of the present disclosure are within the scope of protection of the present disclosure.

[0017] To simplify the drawings, the drawings schematically illustrate only portions relevant to the embodiments and do not represent the actual structure of the product. Furthermore, to simplify the drawings and facilitate understanding, only some structures or components are schematically depicted; more or fewer similar structures or components may exist in practice.

[0018] As a decentralized database, blockchain addresses the storage drawbacks of traditional centralized databases, supporting data integrity and non-repudiation to a certain extent. It records data in a decentralized, tamper-proof manner, ensuring transparent, traceable, secure, and reliable transactions. The application of blockchain technology in ticket management systems can effectively address issues inherent in traditional ticketing systems, such as ticket fraud, widespread counterfeit tickets, scalper hoarding, and a lack of transparency. However, due to its unique characteristics of openness and transparency, it presents challenges with data ownership and user privacy. Traditional public-private key infrastructures make it easy for malicious nodes to obtain user-related information, and it also struggles to ensure user anonymity during data processing. Therefore, this application discloses a blockchain-based ticket management system that eliminates the need for ticket data readers to store sensitive identity information of ticket purchasers. Furthermore, by implementing identity verification through blockchain technology, ticket data readers no longer need to perform complex verification of the purchaser's identity information during ticket verification. Instead, they use the received key to decrypt the purchaser's encrypted data, thereby improving the security of the purchaser's identity information and enhancing the efficiency of the ticket verification process.

[0019] Figure 1 The schematic diagram of the structure of a ticket management system based on blockchain is shown in some embodiments of the present application. The ticket management system 100 is used for ticket verification between a first authorization agency 110, a second authorization agency 120 and a blockchain 130, including: a first authorization agency 110, including multiple users, the types of multiple users include: a ticket data writer 111 and a ticket data reader 112; a second authorization agency 120, configured to generate credential information corresponding to the identification information provided by the user and return it to the user, the credential information is used to prove the identity of the user; the ticket data writer is configured to provide the first credential information to the first authorization agency, and the ticket data reader is configured to provide the second credential information to the first authorization agency; the first authorization agency is configured to generate credential information based on the identification information provided by the second authorization agency. A first key is sent to the ticket data writer based on a credential information, and the first key is used to sign the first data and generate the second data; or a second key is sent to the ticket data reader based on the second credential information, 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 multiple users in the ticket data writer or the ticket data reader; the blockchain is configured to obtain the second data, verify and store the second data, and provide the second data to the ticket data reader in response to the request of the ticket data reader; the ticket data reader is also configured to decrypt the second data based on the second key to determine the admission qualification of the ticket data writer.

[0020] In this application, the first authorization agency 110 is comprised of all parties involved in ticket management, including a ticket data writer 111 and a ticket data reader 112. The ticket data writer 111 can include consumers, such as regular ticket purchasers and VIP ticket purchasers, as well as ticket management users, such as ticketing companies, agency platforms, or other service providers involved in ticket management. The ticket data reader 112 can also be a consumer, such as regular ticket purchasers and VIP ticket purchasers, or a ticket management user, such as ticketing companies, agency platforms, or other service providers involved in ticket management. However, the ticket data writer 111 and the ticket data reader 112 have relative roles in different aspects of the ticketing process. For example, when entering ticket information before a ticket purchase, the ticket management user is the ticket data writer 111, while the consumer user, when viewing the information after the ticket purchase is complete, is the ticket data reader 112. For another example, during the ticket verification phase, a consumer-type user belongs to the ticket data writer 111 , and a ticket management-type user belongs to the ticket data reader 112 .

[0021] In traditional ticket management systems, the sensitive identity information of the ticket data writer 111 is often stored in the ticket data reader 112 in order to improve ticket verification efficiency. However, the database of the ticket data reader 112 is limited by the information security management technology of the ticket data reader 112 company, and there may be uneven management levels and defense technologies, which poses a risk of information leakage. In this application, during the registration stage of the ticket data writer 111 and the ticket data reader 112, the second authorization agency 120 provides identification information, and the second authorization agency 120 provides the first credential information to the ticket data writer 111 and the second credential information to the ticket data reader based on the representation information. The first identification information and the second identification information can be unique identity information, and the certificate authority will return an identity credential that proves its identity information. For example, the second authorization agency 120 can sign the user's identity information by generating a private key and provide a public key for verifying the identity information, thereby encrypting the user's identity information. The first and second credential information can be used as authentication content in subsequent ticket management processes, eliminating the need for ticket data readers to manage sensitive identity information. Identity verification can be completed using the credential information, reducing complex identity verification processes and improving information security and verification efficiency throughout the ticket management process. Second authorization agency 120 can include one or more of an ID card information management unit, a communication information management unit, or other personal information management units, collectively forming a credible identity-sensitive information management unit. Users apply to these management units, eliminating the need for ticket data readers 112 to store sensitive identity information, thereby improving information security.

[0022] The first authorization agency 110 can be a collection 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 it possesses that needs to be encrypted can be related to ticket purchase information, such as the show, seat, price, etc. For another example, if the ticket data writer 111 is a consumer user, the user can apply for a first key from the first authorization agency 110 and use the first key to encrypt the first data to generate second data. The ticket data reader 112 can also apply for a second key from the first authorization agency 110. This second key can be used to decrypt the encrypted second data, thereby confirming the ticket data writer 111's admission eligibility and completing corresponding venue management, such as reserving a seat or determining the rights and interests of the ticket data writer 111, such as seat class, meal package, or other information related to ticketing commercial activities. For example, a ticket data writer 111, a user in the ticket management category, can apply for a first key from the first authorization agency 110. Using the first key, they encrypt the first data to generate second data. This first data contains specific information such as the show time, seats, and price. A consumer user, acting as the ticket data reader 112, decrypts the second data using the second key to view the aforementioned details.

[0023] The acquisition of the first and second keys requires approval from the first authorization authority 110. For example, the ticket data writer 111 needs to provide the first credential information to one or more users of the first authorization authority 110. Only after these users approve the first credential information can the first key be issued to the ticket data writer 111, thereby encrypting the first data. For example, the application for the first key requires approval of the first credential information by multiple users before the first authorization authority 110 issues the first key. Another example is that the application for the second key requires approval of the second credential information by multiple users before the second key is issued. Distributed approval by multiple users during the signing and decryption phases can further enhance the security of ticket management and prevent single-point attacks or tampering. If only a single user (with a unique identity type and number of users) is responsible for key distribution, the entire system could be at risk if that user is attacked or subjected to malicious activity. By establishing a collaborative decision-making process among multiple users within the first authorization authority 110, errors in single-point decision-making or abuse of authority can be avoided. For example, the ticket management system allows VIP users to apply for high-priority ticket purchasing permissions (such as "buy concert tickets 24 hours in advance"). Applicants must pass the joint review of multiple users in the first authorization agency 110 to ensure that their identity is authentic and their application is legal. The ticket data writer 111 submits an application, declaring that he is a VIP member and hopes to obtain a key to unlock VIP ticket purchasing permissions. Provide first credential information formed by identity proof (such as ID card, membership card) and relevant attribute information to apply for the first key. User A of the first authorization agency 110 verifies the membership of the ticket data writer 111 and signs the consent. User B of the first authorization agency 110 verifies the ticket purchase record of the ticket data writer 111 and confirms that it meets the VIP upgrade conditions. User C of the first authorization agency 110 passes the verification, and the system detects that the membership card of the ticket data writer 111 has not expired. The first authorization agency 110 can authorize the ticket purchaser 111 to use the first key to digitally sign his own ticket purchase data after purchasing the ticket.

[0024] Another example includes: the ticket data reader 112 is responsible for verifying the authenticity and validity of the ticket purchase data at the event site. The first authorization agency 110 is composed of multiple users including: the ticket platform administrator, who is responsible for managing ticket purchase records; the organizer's authorization agency is responsible for generating the keys required by the ticket data writer and the ticket data reader. The blockchain 130 stores encrypted ticket purchase data and signatures, which are publicly verifiable. After the ticket data writer 111 completes the ticket purchase, the system generates a copy of the ticket purchase data, including: name, purchase time, seat number and other information. The ticket data writer 111 applies for the first key from the first authorization agency 110 through its own first credential information. After the consent of multiple users of the first authorization agency 110, the ticket purchase data is signed, and the signed data is uploaded to the blockchain together with the ticket purchase information (encrypted form). The ticket data reader 112 needs to obtain the encrypted data and scan the purchaser's electronic ticket at the event. Multiple users of the first authorization agency 110 verify the identity of the ticket data reader 112. After all verifications are successful, the second key is issued to the reader to decrypt the ticket purchase data. If the verification is successful, the authenticity and validity of the ticket purchase data are confirmed. This application can prevent ticket information from being forged. The encrypted ticket purchase data can only be decrypted and viewed by the authorized ticket data reader 112. The data involved in the above process is uploaded to the blockchain. Due to the traceability of blockchain records, all signatures and encryptions can be verified at any time, thereby improving the security of the ticket management system. The blockchain 130 is responsible for verifying the signed second data and storing it after confirming that the second data has not been tampered with. In addition, when the ticket data reader 112 requests to obtain the second data, the ticket data reader 112 can be verified, further ensuring the security of the ticket management process.

[0025] In some embodiments of the present application, blockchain 130 is further configured such that, when the second authorization authority 120 generates credential information, it generates a first public key and a first private key based on the identification information, and uses the first private key to sign the identity information determined based on the identification information to form the credential information. The credential information includes the first public key, which is 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 their identification information to the second authorization authority 120 to prove their identity and apply for credential information, such as a token. This token is bound to the user's identity information and permissions. After verifying the user's identity, the second authorization authority 120 generates credential information and binds it to the user's identification information. The credential information may include encrypted user information, validity period, permissions, and other data. Blockchain 130 can store and record this information. To prevent tampering and forgery, blockchain 130 utilizes its immutable and decentralized nature, becoming a reliable storage medium to ensure the validity of the credential information and the authenticity of the user's identity. The decentralized nature of blockchain technology means that no single central entity 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, allowing attackers to commit fraud by tampering with the database or copying tokens. With blockchain technology, all identification and credential information is encrypted and protected by the blockchain. Once recorded, it cannot be modified. Therefore, even malicious users cannot forge or tamper with it. Blockchain 130 also provides traceability. Every record on it is timestamped, so the issuance time and modification history of credential information can be traced, ensuring that the authenticity and legitimacy of credential information can be proven through blockchain records in the event of a dispute.

[0026] In some embodiments of the present application, the first authorization agency 110 is further 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 passed and multiple users among the ticket data writer, ticket data reader or identity information manager agree.

[0027] In some embodiments of the present application, the first authorization agency 110 is further 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 passed and multiple users among the ticket data writer, ticket data reader or identity information manager agree.

[0028] By managing key issuance within the ticketing system through blockchain technology, signature verification of credential information, and a multi-party consent mechanism, the system improves security, transparency, traceability, and resilience. This effectively prevents counterfeiting and abuse, ensures the privacy of ticket information, and provides a decentralized, trusted 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, it can establish a first access policy to specify which users can and cannot access the second data. The core of the first access policy can be implemented using a Boolean function, representing user access rights. Attributes in the first access policy, such as the user's role and identity information, are key factors in enabling decryption and data access. When the ticket data reader 112 requests access to the second data from the blockchain 130, the blockchain 130 can verify whether the ticket data reader 112 complies with the access requirements of the first access policy. Only those ticket data readers 112 that comply with the first access policy are permitted to obtain the second data. The signature policy is how the ticket data writer 111 chooses to sign data based on specific rules and conditions. This policy can include how keys, attributes, and conditions are used to determine which information is signed, and how signature validity and compliance are managed. The ticket data writer 111 can control which users can access data based on their identity attributes, without relying on a centralized authority 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. Therefore, a mechanism must be in place to ensure the data's legitimate origin. Only verified ticket purchasers 111 can upload data, ensuring that the person uploading the secondary data is the legitimate ticket owner and not an unauthorized third party. Blockchains use algorithms to verify user identity, preventing data forgery and malicious uploads. Ticket data writers 111 can sign their data on blockchain 130 using their private key, while other users can verify the data's authenticity using the corresponding public key. Blockchain 130 can implement complex authentication logic through smart contracts. For example, when ticket purchaser 111 submits a data upload request, the smart contract can check the first public key and signature to verify compliance with identity authentication rules (such as whether the signature matches and whether the user has sufficient permissions). It also verifies data integrity, timestamps, and other aspects, ensuring the secondary data stored on blockchain 130 is flawless, further improving the reliability of ticketing 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] Blockchain 130 can verify the identity of the ticket data reader 112. The identity information provided by the ticket data reader 112 is verified using the first public key to ensure its legitimacy and authenticity. The decentralized nature of blockchain makes this authentication more transparent and tamper-proof. After successful verification, the blockchain system sends the second data to the ticket data reader. This second data allows the ticket data reader to perform further operations, such as ticket verification and access control. Using public key encryption to verify the identity of the ticket data reader prevents identity forgery or impersonation. Because only the user holding the first private key corresponding to the first public key can generate a correct signature, the identity of the user can be confirmed after successful verification, and the second data can be sent to the user.

[0035] In some embodiments of the present application, multiple users are also configured to determine multiple partial institutional secrets, generate multiple secret sharing values ​​based on the multiple partial institutional secrets, and share the secret sharing values ​​with each other; the users are also 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] This application can generate a second private key using a secret sharing algorithm, with multiple users determining multiple partial organizational secrets. A partial organizational secret can be a fragment or portion of a secret (e.g., identity information, ticketing information, etc.) held by multiple different users. Each user holds a portion of the secret, and no single user can independently determine the entire secret. Users exchange and combine their respective secret sharing values ​​based on their respective partial secrets, ensuring that no single user possesses the complete key. This step ensures a decentralized attribute key generation process. After all users share the secret sharing values, they can use them to generate the final second private key. The second private key is crucial for 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, ensuring that it can be used for data authentication and access control. The public key record on the blockchain ensures that ticket data readers or data accessors use the correct second public key during the authentication process. This distributed key generation and secret sharing approach effectively prevents key leakage from any single party, ensuring that the complete secret for generating the second private key remains under the control of multiple participants, reducing the risk of key leakage and misuse. Since the generation and management of the second key is completed through the collaboration of multiple users, there is no single central authority that can control the key. The decentralized attribute key management improves the transparency and anti-attack capability of the system.

[0037] In some embodiments of the present 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 a partial institutional secret of all multiple users.

[0038] The blockchain 130 can obtain a second public key from the first authorized institution 110. This second public key comprises multiple partial institutional public keys provided by multiple users. These public keys, collectively formed as the second public key, can be used to generate a third key. The core concept of the threshold secret sharing algorithm is to split a key or secret into multiple parts, ensuring that the original key or secret can only be reconstructed when a sufficient number of users agree to share. Therefore, the public keys of multiple users are stored and shared on the blockchain, with each institution only having access to a portion of the information. The blockchain can participate in the key generation or verification process using selected public keys, ensuring the system's decentralization and security. For example, if the ticket data reader 112 needs to obtain the second data for decryption, the first authorized institution 110 will need to send it the second key when the blockchain determines that it has passed verification based on the second credential information. The generation of the second key requires multiple users within the first authorized institution 110 to share partial institutional secrets to determine a third private key, thereby generating a second key capable of decrypting the second data. For example, if the second key includes the third private key, the second key can decrypt the entire content of the second data. When the ticket data reader 112 performs decryption, there is no need to access multiple users in the first authorization agency 110, and the process of multiple users sharing partial agency secrets can also be implemented in the blockchain 130, ensuring the security and decentralization of the data and further improving the security of the ticketing system.

[0039] In this disclosure, unless otherwise expressly provided or limited, ordinal numbers, such as "first" and "second," are used only to distinguish and describe related objects and are not to be understood as indicating or implying the relative importance or order of the related objects. In addition, ordinal numbers do not represent the number of related objects.

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

[0041] The terms "or" and "and / or" in this disclosure are used to describe the relationship between associated objects, which indicates non-exclusive inclusion. For example, "A and / or B" and "A or B" can both include: "A alone", "B alone", or "A and B", where "A" and "B" can include a single object or multiple objects. For another example, "A, B and / or C", "A, B or C" and "A, B and C" can both include: "A alone", "B alone", "C alone", "A and B", "A and C", "B and C", or "A, B and C", where "A", "B" and "C" can include a single object or multiple objects. In addition, " / " in this disclosure is used to indicate the "or" relationship between the preceding and following associated objects. In this disclosure, "at least one of A or B" and "one or more of A and B" have the same meaning as "A or B" above, and "one or more of A, B and C" and "at least one of A, B or C" have the same meaning as "A, B or C" above. "One or more of A, B and C" have the same meaning as "A, B or C" above.

[0042] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments. In addition, the above embodiments can be freely combined as needed.

Claims

1. A ticket management system based on blockchain, characterized in that: Ticket verification is performed between the first authorized institution, the second authorized institution 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 writer and a ticket data reader; The second authorization agency is configured to generate credential information corresponding to the identification information provided by the user and return it to the user, wherein the credential information is used to prove the identity of the user; The ticket data writer is configured to provide first credential information to the first authorization agency, and the ticket data reader 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 writer based on the first credential information, the first key is used to sign the first data and generate the second data; or send a second key to the ticket data reader based on the second credential information, 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 multiple users in the ticket data writer or the ticket data reader; The blockchain is configured to obtain the second data, verify and store the second data, and provide the second data to the ticket data reader in response to a request from the ticket data reader; The ticket data reader is further configured to decrypt the second data based on the second key to determine the admission qualification of the ticket data writer.

2. The ticket management system according to claim 1, characterized in that: The blockchain is also 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, and to sign the identity information determined based on the identification information based on the first private key to form the credential information, wherein the credential information includes the first public key, and the first public key is used to verify the signed identity information.

3. The ticket management system according to claim 2, characterized in that: The first authorization agency is further 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 passed and multiple users among the ticket data writer or the ticket data reader agree.

4. The ticket management system according to claim 3, characterized in that: The first authorization agency is further 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 passed and multiple users among the ticket data writer or the ticket data reader agree.

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

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

7. The ticket management system according to claim 6, characterized in that: The blockchain is also configured to verify the identity information of the ticket data reader based on the first public key, and when the verification is passed, send the second data to the ticket data reader.

8. The ticket management system according to claim 7, characterized in that: The plurality of users are further configured to determine a plurality of partial institutional secrets, generate a plurality of secret sharing values ​​based on the plurality of partial institutional secrets, and share the secret sharing values ​​among the plurality of users; The user is also configured to generate a second private key based on the secret shared 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 according to claim 8, characterized in that: The blockchain is also 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 secret of all the multiple users.

10. The ticket management system according to any one of claims 1 to 9, characterized in that: The second authorization agency includes: one or more of an identity card information management unit, a communication information management unit, or other personal information management units.

Images