Drug supply chain supervision method and system based on decentralized identity
By combining decentralized identity identification and hash XOR tree structure with blockchain technology, the problems of data leakage and untraceability in the pharmaceutical supply chain are solved, realizing the security and traceability of pharmaceutical distribution, and ensuring the authenticity of pharmaceuticals and regulatory efficiency.
Patent Information
- Application Number
- CN202411701684.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-26
- Publication Date
- 2025-11-18
- Estimated Expiration
- 2044-11-26
AI Technical Summary
Traditional pharmaceutical supply chains suffer from data breaches, lack of drug traceability, absence of effective regulatory mechanisms, and malicious actors, leading to an increased risk of counterfeit drugs entering the market and making it difficult for consumers to verify the authenticity of drugs.
By combining decentralized identity identifiers (DID) and hash XOR tree structures with blockchain technology, unique drug identity identifiers and verifiable credentials are generated. Traceability and security supervision of the drug circulation process are achieved through one-time traceable addresses and smart contracts.
It has achieved information security and traceability in the pharmaceutical supply chain, prevented data leakage, ensured the authenticity of pharmaceuticals, prevented counterfeit drugs from entering the market, and improved the system's security and regulatory efficiency.
Smart Images

Figure CN119722097B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of blockchain, and in particular to a medicine supply chain supervision method and system based on decentralized identity. BACKGROUND
[0002] With the rapid development of information technology, emerging technologies such as blockchain, decentralized identity (DID), verifiable credential (VC), and verifiable proof (VP) are increasingly widely used in supply chain management, especially in the pharmaceutical industry. Drug traceability has become a key means to ensure drug safety and quality. The drug supply chain involves multiple participants, including pharmaceutical manufacturers, distributors, pharmacies, consumers, hospitals, and regulatory agencies. Traditional drug supply chain systems often rely on centralized data management methods, which have problems such as information silos and data tampering. Therefore, how to use decentralized technology to ensure the traceability and safety of drugs has become a problem to be solved.
[0003] In traditional drug supply chains, the following four key problems are often encountered: ① In the entire process of drug production and sales, each node (pharmaceutical manufacturers, distributors, pharmacies) records relevant transaction and identity information. However, these sensitive information often lack effective privacy protection measures and are vulnerable to theft by criminals, leading to data leakage problems. Such data leakage not only damages the reputation of enterprises but also threatens public health. ② Traditional drug supply chain systems lack effective supervision mechanisms and are difficult to supervise each link in the supply chain in real time. When problems occur in the supply chain (such as counterfeit drugs, illegal sales), it is difficult for regulatory agencies to trace the responsible party, increasing the risk of counterfeit drugs entering the market. ③ Consumers and downstream distributors often have difficulty verifying the authenticity of the drugs when purchasing them. In existing systems, drug information is easily tampered with, allowing counterfeit and expired drugs to enter the market, posing a serious threat to consumer health and safety. ④ There may be malicious participants in the supply chain, such as illegal distributors and counterfeit manufacturers. These criminals may cheat profits by forging identity information or tampering with transaction records, thereby disrupting the order of the drug market. SUMMARY
[0004] The purpose of the present application is to provide a medicine supply chain supervision method and system based on decentralized identity to improve the problem of easy data leakage and untraceable drug supply links in the prior art.
[0005] To achieve the above-mentioned purpose, the present application provides the following technical solutions:
[0006] In a first aspect, the present application provides a medicine supply chain supervision method based on decentralized identity, comprising a user registration step, a drug registration step, and a circulation link supervision step.
[0007] The user registration step, each participant client generates a decentralized identity DID and a DID document respectively, and obtains a verifiable credential VC signed by a regulatory party; the participant client includes a pharmaceutical factory client, a distributor client, a pharmacy client, and a hospital client;
[0008] In the drug registration step, the pharmaceutical factory client generates a decentralized identity DID med , a DID med document, and a VC med for each batch of drugs;
[0009] In the circulation link supervision step, the buyer client generates a one-time traceable address and a buyer verifiable statement VP, and the buyer verifiable statement VP is generated by selectively disclosing information of the buyer verifiable credential VC through a hash XOR tree structure; the seller client verifies the validity of the one-time traceable address, the integrity of the buyer verifiable statement VP, and the validity of the signature in the buyer verifiable statement VP, and if all verifications are passed, the seller client generates a seller verifiable statement VP by a hash XOR tree structure from the seller verifiable credential VC and sends it to the buyer client, and the buyer client verifies the integrity of the seller verifiable statement VP, and after verification, the seller client is notified to update the transaction field in the VC med .
[0010] In the embodiment of the application, the user registration step includes the following steps:
[0011] S11, each participant client generates a public-private key pair respectively;
[0012] S12, each participant client generates a DID i and a DID i document respectively, the DID i document contains a DID i , a public key PK i , a verification method and a server endpoint information, then the DID i document is first uploaded to the IPFS system, so that the IPFS system generates a content identifier CID i , and then the CID i and the DID i are uploaded to the blockchain, wherein the CID i is a hash value corresponding to the DID i document;
[0013] S13, each participant client sends a request for a verifiable credential VC i to the regulatory client, and the request contains the DID i document and registration information infoi , signature of the application data with the private key;
[0014] S14, the supervisory client verifies the DID i in the document i whether it has been registered in the blockchain, verifies the correctness of the signature on the application data, and verifies the authenticity of the registration information info i , if all the above verifications pass, the supervisory client returns the VC i to the participant client i , the VC i contains the registration information info i, of the participant, the DID of the participant, the DID of the supervisor, the permission declaration, the root root i and the signature of the supervisor, wherein the signature of the supervisor includes the signature of the root root i , the signature of the registration information info i of the participant, the root root i is the final root value generated by the information attribute in the registration information info i of the participant through the hash XOR tree structure;
[0015] S15, each participant client stores the VC i in the respective identity wallet after receiving it.
[0016] In the above scheme, not only is each participant user registered, a corresponding public-private key pair, DID document, and verifiable credential VC are generated, but also signature is performed, which can guarantee the authenticity and integrity of the information and the security of the information.
[0017] The drug registration step includes the following steps:
[0018] S21, whenever a batch of drugs is produced, the pharmaceutical factory client generates a unique identifier DID med and DID med document for each batch of drugs through the identity wallet, the DID med document contains DID med , public key of the pharmaceutical factory, verification method and service endpoint, and uploads the DID med document to the IPFS system, so that the IPFS system generates CID med , and then uploads the CID med to the blockchain;
[0019] S22, the pharmaceutical factory client generates the VC med of the drug based on the DID med , the VC med of the drug records DID medand the drug information, the timestamp and the root generated by the hash XOR tree structure with the drug information as an attribute med , using the private key of the drug factory to sign the root med and all information;
[0020] S23, the drug factory client uploads the signed VC med of the drug to the blockchain.
[0021] The circulation link supervision step includes a drug factory to distributor link supervision sub-step, a distributor to pharmacy link supervision sub-step, and a pharmacy to consumer link supervision sub-step; wherein the drug factory to distributor link supervision sub-step includes the following steps:
[0022] S31, in the process of the drug flowing from the drug factory to the distributor, the distributor client generates a one-time traceable address addr3={pk_addr3, R3, r3} and a private key sk_addr3 corresponding to the one-time traceable address, wherein pk_addr3 is a public key corresponding to the one-time traceable address, and r3 is a random number;
[0023] S32, the distributor client selectively discloses the verifiable credential VC3 of the distributor through the hash XOR tree structure, selects the fields to be disclosed, the verification path and the root root3, and generates a verifiable statement VP3 based on the disclosed information, wherein the VP3 includes a signature made by the distributor client using the private key of the distributor;
[0024] S33, when purchasing the drug, the distributor uses the one-time traceable address addr3 to send the one-time traceable address addr3, VP3 and the random number r3 to the drug factory client;
[0025] S34, after receiving the information sent by the distributor client, the drug factory client verifies the validity of the one-time traceable address addr3, the integrity of VP3 and the validity of the signature in VP3, if all the verifications pass, the drug factory client checks whether it has produced the drug corresponding to the disclosed field, if yes, the drug factory client generates a verifiable statement VP2 from the VC2 of the drug factory through the hash XOR tree structure, wherein the VP2 includes the production permission, the sales permission, the drug information and the signature made by the private key of the drug factory, and sends the VP2 and DID med to the distributor client; if the verification does not pass or the drug factory does not have the corresponding drug, the transaction is terminated;
[0026] S35, the distributor client verifies the integrity of VP2, if the verification passes, the drug factory client is notified to upload the transaction information to the smart contract, the smart contract automatically updates the transaction field in the drug VC med , and sends the updated VC med and DIDmed The document is uploaded to the blockchain; if the verification fails, the transaction is terminated.
[0027] The pharmacy-to-consumer supervision sub-step includes the following steps:
[0028] S51, the consumer client generates a one-time traceable address addr5={pk_addr5, R5, r5}, a private key sk_addr5 corresponding to the one-time traceable address, and a DID5;
[0029] S52, determine whether the medicine to be purchased is a prescription medicine, if it is a prescription medicine, the consumer client submits its DID5, the registration information info5 encrypted with the hospital public key, the one-time traceable address addr5, and the signature of the application data with the consumer private key to the hospital client, and then enters step S53; if it is an over-the-counter medicine, enter step S56;
[0030] S53, the hospital client determines whether the consumer has the right to purchase the prescription medicine, and after determining that the consumer has the right to purchase the prescription medicine, sends the consumer client a verifiable credential VC5 representing the right to purchase the prescription medicine, and then enters step S54; if it is determined that the consumer does not have the right to purchase the prescription medicine, the transaction is terminated;
[0031] S54, the consumer client generates a verifiable statement VP5 based on the information disclosed in VC5, and sends VP5, the one-time traceable address addr5, and the random number r5 to the pharmacy client, and then enters step S55;
[0032] S55, the pharmacy client verifies the validity of the one-time traceable address addr5, the integrity of VP5, and the validity of the signature in VP5, and after verification, sends the pharmacy client's VP4 and the medicine DID med to the consumer client, and then enters step S58;
[0033] S56, the consumer client sends the one-time traceable address addr5 and the random number r5 to the pharmacy client, and then enters step S57;
[0034] S57, the pharmacy client verifies the validity of the one-time traceable address addr5, and after verification, sends the pharmacy client's VP4 and the medicine DID med to the consumer client, and then enters step S58;
[0035] S58, the consumer client verifies the integrity of the pharmacy's VP4, if the verification is passed, the pharmacy client is notified to upload the transaction information to the smart contract, and the smart contract automatically updates the medicine VC medthe transaction field in the VC and send the updated VC to the drugstore client; med and the DID med document to the blockchain; if the verification fails, terminate the transaction.
[0036] In the above scheme, at each circulation link of the drug, the two parties of the transaction are verified to have corresponding permissions, and information transmission and recording are performed through the one-time traceable address, so that the traceability of the drug circulation link can be realized, the security is guaranteed, malicious participants are avoided, and the traceability and security of the drug supply chain are guaranteed.
[0037] In a second aspect, the present application provides a system for implementing the above-mentioned drug supply chain supervision method based on decentralized identity, comprising a supervision client and a participant client, wherein the participant client comprises a pharmaceutical factory client, a distributor client, a drugstore client and a hospital client.
[0038] Each participant client is configured to generate a respective decentralized identity DID and DID document in the user registration step, and obtain a verifiable credential VC signed by the supervision party.
[0039] The pharmaceutical factory client is further configured to generate a decentralized identity DID of the drug, a DID document and a VC for each batch of drugs in the drug registration step. med , DID med document and VC med ;
[0040] Each participant client is further configured to generate a one-time traceable address and a buyer verifiable statement VP in the circulation link supervision step, wherein the buyer verifiable statement VP is generated by selectively disclosing information of the buyer verifiable credential VC through a hash XOR tree structure; the seller client verifies the validity of the one-time traceable address, the integrity of the buyer verifiable statement VP and the validity of the signature in the buyer verifiable statement VP, and if all verifications pass, the seller client generates a seller verifiable statement VP from the seller verifiable credential VC through a hash XOR tree structure and sends it to the buyer client; after the buyer client verifies the integrity of the seller verifiable statement VP, the buyer client notifies the seller client to update the transaction field in the VC med ;
[0041] In the circulation link of the drug, the pharmaceutical factory is the seller, and the distributor is the buyer; in the circulation link of the drug, the distributor is the seller, and the drugstore is the buyer; in the circulation link of the drug, the drugstore is the seller, and the consumer is the buyer.
[0042] In a third aspect, the present application provides a computer program product comprising computer readable instructions, wherein the computer readable instructions, when executed by a processor, implement the steps of the method for supervising a medicine supply chain based on a decentralized identity according to the present application.
[0043] In a fourth aspect, the present application provides a computer readable storage medium comprising computer readable instructions, wherein the computer readable instructions, when executed by a processor, implement the steps of the method for supervising a medicine supply chain based on a decentralized identity according to the present application.
[0044] In a fifth aspect, the present application provides an electronic device comprising: a memory storing program instructions; a processor connected to the memory, executing the program instructions in the memory, and implementing the steps of the method for supervising a medicine supply chain based on a decentralized identity according to the present application.
[0045] Compared with the prior art, the present application combines DID, one-time traceable address and hash XOR tree and other technologies on the basis of the original blockchain technology, not only realizes the non-tamperable and non-copyable characteristics of the traditional scheme, but also solves the problems of unmanageability and privacy leakage of the participants in the traditional medicine supply chain scheme, prevents the emergence of malicious participants (such as illegal dealers and counterfeit manufacturers), and improves the security of the medicine supply chain system.
[0046] Specific technical analysis is as follows:
[0047] Blockchain: The application of blockchain technology in the medicine supply chain can greatly improve the traceability and safety of medicines. By recording the information of each link in the production, transportation, distribution and sales of medicines on the blockchain, the data can be ensured to be tamper-proof and transparent. This not only helps the regulators to effectively supervise and prevent fake drugs from entering the market and prevent pharmacies from selling medicines irregularly, but also enhances the trust of consumers in the source of medicines. In addition, the smart contract function of the blockchain can automatically execute various protocols and transactions in the supply chain, improving efficiency and reducing costs.
[0048] Privacy protection monitoring based on DID and traceable one-time address: In the medicine supply chain scheme, in order to improve the privacy protection and data security, the application realizes the whole process monitoring supporting privacy protection by using DID and traceable one-time address (Traceable One-Time Address) based on HMAC technology. Each supply chain node (such as pharmaceutical factory, distributor, drugstore, user, etc.) in the system has a unique DID, which is used to identify its identity. In addition, each supply chain node needs to apply for a verifiable credential VC to the monitoring party using its own DID, and the monitoring party conducts qualification review. After the review, the monitoring party issues a verifiable credential VC with the signature of the monitoring party. The validity of the VC of a certain node can be verified by the public key of the monitoring party, preventing malicious participants from impersonating qualifications or forging qualification certificates. At the same time, in order to ensure the privacy of transaction data, the buyer can dynamically generate a traceable one-time address based on HMAC each time a transaction (such as medicine circulation) is made. These one-time addresses are generated by encrypting the public and private keys associated with the buyer and the public key of the monitoring party, and each address is used only once in a transaction. This mechanism ensures that even if transaction data is monitored, it is difficult for attackers to track back to the actual supply chain node through the address, protecting the privacy information of the buyer. In addition, since the buyer uses the public key of the monitoring party when generating the one-time address, the monitoring party can use the identity tracing method to monitor the buyer to ensure the compliance and auditability of the supply chain. Under this architecture, the monitoring party uses DID to realize global identity verification and qualification authorization, and uses the traceable one-time address to realize privacy protection tracking monitoring, thereby realizing compliance monitoring and privacy protection in the medicine circulation process.
[0049] Selective disclosure method based on hash XOR tree: In the medicine supply chain scheme, in order to realize the selective disclosure of verifiable credentials (Verifiable Credential, VC) and verifiable declarations (Verifiable Presentation, VP), DID and hash XOR tree are combined. First, a unique DID is assigned to each supply chain node, and its related authentication information is encapsulated into VC. In order to protect data privacy, the hash XOR tree is used to hash the attributes in the VC, and the tree structure is organized. Whenever a node needs to disclose part of the information to other participants (such as the monitoring party), a VP can be generated by selectively disclosing part of the node data in the hash XOR tree, only showing the required attributes and their proof path, without revealing other sensitive data. This mechanism not only guarantees the integrity and authenticity of the data, but also enhances the privacy protection capability, i.e. further enhances the security, realizes more flexible verifiable data disclosure, and has the advantages of higher efficiency and smaller computational overhead compared with the hash Merkle tree structure.
[0050] Dynamic Monitoring of the Pharmaceutical Supply Chain Based on Smart Contracts: Existing pharmaceutical supply chain traceability solutions often only achieve static monitoring, not dynamic monitoring. This invention, however, adds a "from...to..." field to the pharmaceutical value chain (VC) using smart contracts and forcibly updates this field with each transaction. This enables dynamic traceability and full-process tracking of pharmaceutical transactions, clearly identifying the responsible party for violations through a chain of evidence. Furthermore, when updating the "from...to..." field in the VC, the smart contract automatically verifies the participant's qualifications and eligibility based on input information, preventing illegal sales and promptly detecting issues such as returned drugs. This ensures that pharmaceuticals can legally and compliantly re-enter the market or be destroyed as required.
[0051] Other advantages of this invention are described in the embodiments section. Attached Figure Description
[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0053] Figure 1 This is a diagram illustrating the architecture of a decentralized identity-based drug supply chain monitoring system, as exemplified in an embodiment of the present invention.
[0054] Figure 2 The flowchart illustrates a drug supply chain supervision method based on decentralized identity identification, as exemplified in the embodiments.
[0055] Figure 3 The following is a detailed flowchart illustrating the user registration steps exemplified in this embodiment.
[0056] Figure 4 The following is a detailed flowchart illustrating the drug registration steps exemplified in this embodiment.
[0057] Figure 5 This is a detailed flowchart illustrating the regulatory sub-steps from pharmaceutical factory to distributor, as exemplified in the embodiments.
[0058] Figure 6 This is a detailed flowchart illustrating the regulatory sub-steps from pharmacy to consumer, as exemplified in the embodiments.
[0059] Figure 7 This is a block diagram of the components of an electronic device. Detailed Implementation
[0060] In order to make the objects, technical solutions and advantages of the present application clearer, further detailed description will be given below in combination with the drawings and examples. It should be understood that the specific examples described herein are only used to explain the present application and not to limit the present application.
[0061] Referring to Figure 1 , the embodiment provides a drug supply chain supervision system based on decentralized identity, which comprises a supervision client 101, a pharmaceutical factory client 102, a distributor client 103, a pharmacy client 104, a consumer client 105, a hospital client 106 and a server 107 integrating a block chain and an IPFS system. For the convenience of description, the pharmaceutical factory client 102, the distributor client 103, the pharmacy client 104, the consumer client 105 and the hospital client 106 will be collectively referred to as participant clients hereinafter, that is, when the participant clients are described, it means that the pharmaceutical factory client 102, the distributor client 103, the pharmacy client 104, the consumer client 105 and the hospital client 106 all perform the same operation unless otherwise specified.
[0062] Referring to Figure 2 , the drug supply chain supervision method based on decentralized identity realized based on the above drug supply chain supervision system comprises a user registration step, a drug registration step and a circulation link supervision step. In the user registration step, the pharmaceutical factory client 102, the distributor client 103, the pharmacy client 104 and the hospital client 106 respectively generate their own decentralized identity (DID) and DID document (containing their own DID, public key, verification method and server point, etc.) and obtain a verifiable credential (VC) signed by a supervision party. In the drug registration step, the pharmaceutical factory client generates a decentralized identity DID med , a DID med document and a VC med for each batch of drugs. In the circulation link supervision step, the buyer client generates a one-time traceable address and a buyer verifiable statement VP, wherein the buyer verifiable statement VP is generated by selectively disclosing information of the buyer verifiable credential (VC) through a hash XOR tree structure; the seller client verifies the validity of the one-time traceable address, the integrity of the buyer verifiable statement VP and the validity of the signature in the buyer verifiable statement VP, and if all the verifications are passed, the seller client sends a seller verifiable statement VP generated by the seller verifiable credential (VC) through a hash XOR tree structure to the buyer client, the buyer client verifies the integrity of the seller verifiable statement VP, and after the verification is passed, the buyer client notifies the seller client to update the transaction field in the VC med .
[0063] It is easy to understand that the seller and the buyer here are relative concepts. When the drug flows through the distribution link from the pharmaceutical factory to the distributor, the pharmaceutical factory is the seller and the distributor is the buyer; when the drug flows through the distribution link from the distributor to the pharmacy, the distributor is the seller and the pharmacy is the buyer; when the drug flows through the distribution link from the pharmacy to the consumer, the pharmacy is the seller and the consumer is the buyer.
[0064] Please refer to Figure 3 , the user registration step can include the following steps:
[0065] S11, the supervisory client and the participant client generate their own public and private key pairs respectively.
[0066] When generating the public and private key pairs, a i , b i are randomly generated, A i =a i ·G, B i =b i ·G are calculated, and then the public key PK i =(A i ,B i ) and the private key sk i =(a i ,b i ) are obtained, G is a prime order base point on an elliptic curve, the elliptic curve is an equation y^2=x^3+7(mod p), p is a prime number. a i, , b i belong to Z N * , Z N * refers to the multiplicative group of modulo N, which is composed of all integers coprime to N, that is, Z N * contains all integers that have multiplicative inverses under modulo N. A i is the first half of the long-term public key of user i, B i is the second half of the long-term public key of user i, a i is the first half of the long-term private key of user i, and b i is the second half of the long-term private key of user i.
[0067] Here and in the following i refers to the user number, for example, the supervisor (i=1), the pharmaceutical factory (i=2), the distributor (i=3), the pharmacy (i=4), the consumer (i=5), and the hospital (i=6).
[0068] S12, the participant (i>=2 and i! =5, i.e. excluding the consumer) client generates its own DID i and DID i document through the identity wallet, DID iThe document contains its own DID i Public key PK i Verify the method and service endpoint information, and then use the DID. i The document is first uploaded to the IPFS system so that the IPFS system can generate a Content Identifier (CID). i Then CID i With DID i Uploaded to the blockchain, including CID i It is DID i The hash value corresponding to the document.
[0069] S13, the participating client (i>=2 and i!=5, i.e., excluding consumers) sends an application for verifiable credentials VC to the regulatory client. i The request includes a DID generated by the participating client. i Documents, registration information info i The application data is signed using the private keys of the participating parties.
[0070] Registration information for different users (info) i They differ. For example, a pharmaceutical company's registration information may include the company name, address, types of drugs produced, legal representative, production license, and sales license. A distributor's registration information may include the legal representative, address, wholesale license, and sales license. A pharmacy's registration information may include the store name, address, licensed pharmacist, legal representative, wholesale license, and retail license.
[0071] S14, After receiving a request from a participating party's client, the monitoring client verifies the DID. i DID in the document i Check if it has been registered in the blockchain, verify the correctness of the signature on the application data, and verify the registration information (info). i To verify the authenticity of the data, if all the above verifications pass, the regulatory client returns the VC value to the participating client. i VC i Includes the registration information of the participants (info) i Participant's DID, Regulator's DID, License Statement, Root i And the regulator's signature, including the signature of the root. i The signature, the registration information of the participating parties (info) i The signature, root i It is based on the registration information of the participating parties (info). i The information attribute attr ij The final root value is generated through a hash XOR tree structure.
[0072] If any of these verifications fails, the regulator's client will not return a VC to the participating client. i Consequently, the participants are prohibited from carrying out subsequent operations, thereby preventing malicious participants from disrupting market order.
[0073] The above verification operation to check whether the signature of the application data is correct is based on the received DID. i The document allows you to view the public keys of the participants and verify the signatures using those public keys, thereby ensuring that the request content has not been tampered with.
[0074] S15, the participating client receives VC i Then, they store them in their respective identity wallets.
[0075] When the participating client receives VC i This means that you have the relevant licenses and qualifications to carry out the corresponding operations, such as producing, wholesaling, and selling pharmaceuticals.
[0076] Please see Figure 4 The drug registration process may include the following steps:
[0077] S21, whenever a batch of medicines is produced, the pharmaceutical company's client generates a unique identifier (DID) for each batch of medicines through an identity wallet. med and DID med Document, DID med The document contains DID med Information such as the pharmaceutical company's public key, verification method, and service endpoint, and the DID med The document is uploaded to the IPFS system so that the IPFS system can generate a CID. med Then CID med Uploaded to the blockchain.
[0078] S22, Pharmaceutical client based on DID med Vitamin C for drug production med Vitamin C in medicine med DID Record med This includes drug information (drug name, manufacturer, production address, drug grade, production batch, production time, expiration date, and other detailed drug information), timestamps, and a root generated using a hash XOR tree structure with the drug information as attributes. med Use the pharmaceutical company's private key to root. med And the signature of all information.
[0079] S23, The pharmaceutical company's client will sign the drug's VC. med Uploaded to the blockchain, ensuring that drug information is publicly available and traceable throughout the entire supply chain.
[0080] In addition, to ensure data security and access control during the drug distribution process, smart contracts are used to control drug VC. med The smart contract defines the update permissions for each participating client in the drug distribution process. Only authorized participating clients can update the drug's VC (Volume Value). med .
[0081] The regulatory steps in the distribution process include the regulatory steps from pharmaceutical manufacturers to distributors, from distributors to pharmacies, and from pharmacies to consumers.
[0082] Please see Figure 5 The regulatory steps from pharmaceutical manufacturers to distributors may include the following:
[0083] S31, During the process of the drug flowing from the pharmaceutical factory to the distributor, the distributor client generates a one-time traceable address addr3 = {pk_addr3, R3, r3} and a private key sk_addr3 corresponding to the one-time traceable address, where pk_addr3 is the public key corresponding to the one-time traceable address and r3 is a random number.
[0084] S32, the distributor client selectively discloses the verifiable credential VC3 signed by the regulator in its identity wallet through a hash XOR tree structure, selecting the fields to be disclosed (such as drug information and wholesale licenses), verification path and root3, and generating a verifiable claim VP3 based on the disclosed information. VP3 contains the signature made by the distributor client with the distributor's private key.
[0085] S33, when purchasing medicines, the distributor uses a one-time traceable address addr3 to send the one-time traceable address addr3, VP3 and random number r3 to the pharmaceutical company's client.
[0086] S34. After receiving the information from the distributor's client, the pharmaceutical company client verifies the validity of the one-time traceable address addr3, the integrity of VP3, and the validity of the signature in VP3. If all verifications pass (indicating that the distributor is qualified to wholesale pharmaceuticals), the pharmaceutical company client checks whether it has produced the pharmaceuticals corresponding to the disclosed fields. If so, the pharmaceutical company client generates a verifiable claim VP2 from the VC2 signed by the regulator in its identity wallet using a hash XOR tree structure. VP2 contains the production license, sales license, pharmaceutical information, and a signature made with the pharmaceutical company's private key. The pharmaceutical information includes the pharmaceutical name, manufacturer, production address, pharmaceutical grade, production batch, production time, and expiration date. The pharmaceutical company client then combines VP2 and DID. med Send to the distributor's client. If verification fails or the pharmaceutical company does not have the corresponding drug, the transaction is terminated.
[0087] S35, the distributor client verifies the integrity of VP2. If the verification passes, it notifies the pharmaceutical company client to upload the transaction information to the smart contract. The smart contract automatically updates the drug VC. med The transaction fields in the list are: "from: pharmaceutical company address, to: distributor's one-time traceable address, signature: pharmaceutical company signature, timestamp: update timestamp", and the updated VC is then added. med and DID med The document is uploaded to the blockchain. If verification fails, the transaction is terminated.
[0088] The process of drugs flowing from distributors to pharmacies is basically the same as described above, but the distributors act as the pharmaceutical manufacturers, and the pharmacies act as the distributors. Specifically, the regulatory sub-steps for the distributor-to-pharmacy link can include the following steps:
[0089] S41, During the process of medicines flowing from distributors to pharmacies, the pharmacy client generates a one-time traceable address addr4 = {pk_addr4, R4, r4} and the private key sk_addr4 corresponding to the one-time traceable address.
[0090] S42, the pharmacy client selectively discloses the verifiable credential VC4 signed by the regulator in its identity wallet through a hash XOR tree structure. It selects the fields to be disclosed (such as information on the drugs to be wholesaled and wholesale licenses), verification path, and root4, and generates a verifiable claim VP4 based on the disclosed information. The VP4 contains the signature made by the pharmacy client using the pharmacy's private key.
[0091] S43, when purchasing medicines, pharmacies use a one-time traceable address addr4 to send the one-time traceable address addr4, VP4 and random number r4 to the distributor client.
[0092] S44. After receiving the information from the pharmacy client, the distributor client verifies the validity of the one-time traceable address addr4, the integrity of VP4, and the validity of the signature in VP4. If all verifications pass (indicating that the pharmacy is qualified to wholesale pharmaceuticals), the distributor client checks whether it stores the pharmaceuticals corresponding to the disclosed fields. If so, the distributor client generates a verifiable claim VP3 from its identity wallet, which is signed by the regulator, using a hash XOR tree structure. The VP3 contains the sales license and pharmaceutical information, and the distributor client then combines the VP3 with the DID. med Send to the pharmacy's client. If verification fails or the distributor does not have the corresponding medicine, the transaction will be terminated.
[0093] S45, the pharmacy client verifies the integrity of VP3. If the verification passes, it notifies the distributor client to upload the transaction information to the smart contract. The smart contract automatically updates the drug VC. med The transaction fields in the list are: "from: dealer address, to: pharmacy one-time traceable address, signature: dealer signature, timestamp: update timestamp", and the updated VC is used. med and DID med The document is uploaded to the blockchain. If verification fails, the transaction is terminated.
[0094] Please see Figure 6 The regulatory steps from pharmacy to consumer can include the following:
[0095] S51, in order to protect the anonymity and privacy of consumers while achieving regulatory oversight, the consumer client generates a one-time traceable address addr5 = {pk_addr5, R5, r5}, and the corresponding private key sk_addr5 and DID5.
[0096] The consumer's DID is not generated during the user registration process, but only during this step, which further effectively protects the privacy of consumer information.
[0097] S52, determine whether the drug to be purchased is a prescription drug. If it is a prescription drug, the consumer client submits its DID5, registration information info5 encrypted with the hospital's public key, one-time traceable address addr5, and the signature of the application data with the consumer's private key to the hospital client, and then proceeds to step S53; if it is an over-the-counter drug, proceed to step S56.
[0098] Registration information (info5) typically includes name, age, medical insurance information, and symptom information.
[0099] In step S53, the hospital client determines whether the consumer has the authority to purchase prescription drugs. If the consumer has the authority, the hospital sends a verifiable credential VC5, representing the right to purchase prescription drugs, to the consumer's client, and then proceeds to step S54. If the consumer does not have the authority to purchase prescription drugs, the transaction is terminated.
[0100] The hospital client determines whether a consumer has the authority to purchase prescription drugs by verifying the DID5, registration information (since the registration information contains the consumer's symptoms, such as the diseases that enable the purchase of prescription drugs), and signature (to ensure that the data has not been tampered with). If all are correct, the consumer is deemed to have the authority to purchase prescription drugs; otherwise, the consumer is not authorized to purchase prescription drugs.
[0101] During the user registration process, the hospital registers a DID with the regulator. After the regulator approves the registration, it issues a VC (Volume Certificate) to the hospital, which represents its business license. Once the hospital obtains the VC, it can issue VCs to consumers, granting them the right to purchase prescription drugs. This achieves both effective regulation of the hospital by the regulator and effective regulation of consumers' purchase of prescription drugs.
[0102] S54, the consumer client generates a verifiable statement VP5 based on the information disclosed in VC5, and sends its own VP5, one-time traceable address addr5 and random number r5 to the pharmacy client, and then proceeds to step S55.
[0103] S55, the pharmacy client verifies the validity of the one-time traceable address addr5, the integrity of VP5, and the validity of the signature in VP5. After successful verification, the pharmacy client sends the VP4 and the drug DID. med Send to the consumer client, then proceed to step S58;
[0104] S56, the consumer client sends a one-time traceable address addr5 and a random number r5 to the pharmacy client, and then proceeds to step S57.
[0105] S57, the pharmacy client verifies the validity of the one-time traceable address addr5, and after successful verification, sends the pharmacy client's VP4 and the drug's DID. med Send it to the consumer client, and then proceed to step S58.
[0106] S58: The consumer client verifies the integrity of the pharmacy's VP4. If the verification passes, the consumer client is notified to upload the transaction information to the smart contract. The smart contract automatically updates the drug VC. med The transaction fields in the list are: "from: pharmacy address, to: consumer's one-time traceable address, signature: pharmacy signature, timestamp: update timestamp", and the updated VC is used. med and DID med The document is uploaded to the blockchain. If verification fails, the transaction is terminated.
[0107] In the above steps, each participating client selects a random number r when generating a one-time traceable address. i The one-time traceable address is calculated based on the HMAC-SHA256 algorithm:
[0108] h1:=hash1(r i ||a i ·A j );
[0109] h2:=hash2(ri ||h1·A1);
[0110] R i :=h1·G;
[0111] A j =a j ·G;
[0112] The one-time traceable address public key for user i (where i = 3, 4, 5, representing the distributor, pharmacy, and consumer, respectively) is: pk_addr i =h2·G+R i +B i B i =b i ·G,a j a i b i The number is randomly generated; G is a prime-order base point on the elliptic curve.
[0113] User i's one-time traceable address private key is: sk_addr i =h1+h2+b i ;
[0114] User i will calculate addr i ={pk_addr i ,R i ,r i} as its own one-time traceable address.
[0115] hash1:{0,1} * →Z n It is a hash function, which represents mapping a binary string of arbitrary length to a value within the range of integers modulo n; hash2: Gˊ→Z n It is a hash function, G is a prime-order base point on an elliptic curve, Gˊ is the elliptic curve group, and r i It is a random number, r∈Z n * Z n * The multiplication group of integers, A j A1 is the first half of the long-term public key for user j, and A1 is the first half of the long-term public key for the monitoring client. i This refers to the first half of user i's long-term private key. It's important to note that each participant has two pairs of public / private keys: the first half refers to the first public / private key pair, and the second half refers to the second public / private key pair.
[0116] Specifically, if the regulator wants to trace a one-time traceable address, then the regulator holds its own long-term public and private keys and the one-time traceable address addr of user i. i={pk_addr i ,R i ,r i},calculate:
[0117] h2ˊˊ:=hash2(r i ||a1·R i );
[0118] B i :=pk_addr i -R i -h2ˊˊ·G;
[0119] a1 is the first part of the long-term private key for the regulator.
[0120] Calculated B i This refers to the latter half of user i's long-term public key obtained by the regulator. Therefore, the regulator can use the address and its own first half of the long-term private key to trace user i's long-term private key. This method is called identity tracing.
[0121] If user j wants to verify the validity of user i's one-time traceable address, user j holds his own long-term public / private key and user i's one-time traceable address addr. i ={pk_addr i ,R i ,r i},calculate:
[0122] h1ˊ:=hash1(r i ||a j ·A i );
[0123] h2ˊ:=hash2(r i ||h1ˊ·A1);
[0124] Check if the following equations are true:
[0125] B j ==pk_addr i -R i -h2ˊ·G;
[0126] If true, user j determines that user i's one-time traceable address is valid. That is, user j can verify whether user i's long-term public key is correct based on its own long-term private key and one-time traceable address. Therefore, user j can trace user i's identity.
[0127] In particular, a hash XOR tree structure was used to verify VC and VP at each transaction stage, i.e., when generating VC and when VC generates VP, in order to further improve data security.
[0128] When generating a Consumer VC (VC), taking a consumer as an example, the consumer's VC5 should contain the consumer's DID5, registration information info5, root5, and signature information for root5 and registration information info5. Registration information includes info5: name, age, medical insurance information, and symptom information. These attributes must first undergo hash operations to generate hash values. For example, if the consumer's name is Jacky... Let's generate a hash value for this string of characters, denoted as H(A). Similarly, the hash values generated for other attribute information are denoted as H(B), H(C), and H(D). Then, we combine the hash values of each hash value except itself. For example, for H(A), the other hash values combined result in H(H(B)+H(C)+H(D)). Then, we combine H(A) and H(H(B)+H(C)+H(D)) and take the hash to get H(H(A)+H(H(B)+H(C)+H(D))). For the sake of later description, we denote this as 1. At the same time, the other attribute information also results in H(H(B)+H(H(A)+H(C)+H(D))), H(H(C)+H(H(A)+H(B)+H(D))), and H(H(D)+H(D)+H(A)+H(B)+H(D))). Let H(A)+H(B)+H(C)) be denoted as 2, 3, and 4 respectively. Then, for 1, XOR 2, 3, and 4 are performed to obtain XOR(2+3+4). The other information attributes are also XOR(1+3+4), XOR(1+2+4), and XOR(1+2+3) respectively. Then, XOR 1 and XOR(2+3+4) are performed to obtain XOR(1+XOR(2+3+4)). Similarly, the other information attributes are XOR(2+XOR(1+3+4)), XOR(3+XOR(1+2+4)), and XOR(4+XOR(1+2+3)). Finally, any one of these four numbers is hashed to obtain H(XOR(1+2+3+4)), which is root5.
[0129] When generating a VP from a VC, since the attribute information in the VC is stored in a hash XOR tree structure, when a node in the supply chain needs to generate a VP to verify partial information, it can selectively disclose some hash nodes in the tree. For example, if a verifier only needs to verify the production date and batch number of a drug, it only needs to disclose the hash values and their paths related to these attributes, without disclosing the entire VC. The advantage of this is that the authenticity of the disclosed information can be verified quickly without accessing other undisclosed data. When the verifier receives the VP, it uses the hash XOR tree verification algorithm to verify it based on the disclosed hash values and paths, ensuring that the disclosed information is complete, accurate, and tamper-proof. Due to the characteristics of the hash XOR tree structure, even if only partial information is disclosed, its completeness and consistency can still be verified through the root.
[0130] In the steps described above, verifying the validity of the signature in the VP is generally done using the signer's public key. Since the signer's public key is visible to every participant in the system, the verifier can use the signer's public key for verification. For example, a pharmaceutical client can use the distributor's public key for verification.
[0131] like Figure 7 As shown, this embodiment also provides an electronic device that may include a processor 41 and a memory 42, wherein the memory 42 is coupled to the processor 41. It is worth noting that this figure is exemplary, and other types of structures can be used to supplement or replace this structure to achieve data extraction, report generation, communication, or other functions.
[0132] like Figure 7 As shown, the electronic device may also include an input unit 43, a display unit 44, and a power supply 45. It is worth noting that the electronic device is not necessarily required to include these components. Figure 7 All components shown in the image. Furthermore, electronic devices may also include... Figure 7 For components not shown, please refer to existing technologies.
[0133] Processor 41, sometimes also called controller or operation control, may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of the electronic device.
[0134] The memory 42 may be one or more of the following: a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It can store configuration information of the processor 41, instructions executed by the processor 41, and other information. The processor 41 can execute programs stored in the memory 42 to perform information storage or processing. In one embodiment, the memory 42 further includes a buffer memory, or buffer, to store intermediate information.
[0135] This invention also provides a computer program product including computer-readable instructions. When the computer-readable instructions are executed in an electronic device, the program product causes the electronic device to perform the operation steps included in the method of this invention.
[0136] This invention also provides a storage medium storing computer-readable instructions that cause an electronic device to perform the operation steps included in the method of this invention.
[0137] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.
[0138] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0139] The embodiments described above are merely specific implementations of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications, substitutions, and improvements within the technical scope disclosed in the present invention, and these modifications, substitutions, and improvements should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A drug supply chain supervision method based on decentralized identity identification, characterized in that, This includes user registration steps, drug registration steps, and regulatory steps in the distribution process; In the user registration process, each participating client generates its own decentralized identity identifier (DID) and DID document, and obtains a verifiable credential (VC) signed by the regulator; the participating clients include pharmaceutical company clients, distributor clients, pharmacy clients, and hospital clients; In the drug registration process, the pharmaceutical company's client generates a decentralized identity (DID) for each batch of drugs. med DID med Documentation and VC med ; In the aforementioned regulatory steps of the distribution process, the buyer's client generates a one-time traceable address and a buyer's verifiable statement (VP). The buyer's verifiable statement (VP) is generated by selectively disclosing information using a buyer's verifiable credential (VC) through a hash XOR tree structure. The seller's client verifies the validity of the one-time traceable address, the completeness of the buyer's verifiable statement (VP), and the validity of the signature in the buyer's verifiable statement (VP). If all verifications pass, the seller's verifiable credential (VC) generates a seller's verifiable statement (VP) through a hash XOR tree structure and sends it to the buyer's client. The buyer's client then verifies the completeness of the seller's verifiable statement (VP). After successful verification, notify the pharmacy's client to update VC. med The transaction field in; The aforementioned regulatory steps in the distribution process include sub-steps for regulating the process from pharmaceutical manufacturers to distributors, from distributors to pharmacies, and from pharmacies to consumers; among them, the sub-step for regulating the process from pharmaceutical manufacturers to distributors includes the following steps: S31, During the process of drugs flowing from the pharmaceutical factory to the distributor, the distributor client generates a one-time traceable address addr3={pk_addr3,R3,r3} and a private key sk_addr3 corresponding to the one-time traceable address, where pk_addr3 is the public key corresponding to the one-time traceable address and r3 is a random number; S32, the dealer client selectively discloses the dealer's verifiable credential VC3 through a hash XOR tree structure, selects the fields to be disclosed, the verification path and the root root3, and generates a verifiable claim VP3 based on the disclosed information. VP3 contains the signature made by the dealer client using the dealer's private key. S33, when purchasing medicines, the distributor uses a one-time traceable address addr3 to send the one-time traceable address addr3, VP3 and random number r3 to the pharmaceutical company's client; S34, after receiving the information from the distributor's client, the pharmaceutical company client verifies the validity of the one-time traceable address addr3, the integrity of VP3, and the validity of the signature in VP3. If all verifications pass, the pharmaceutical company client checks whether it has produced the drug corresponding to the disclosure field. If so, the pharmaceutical company client generates a verifiable claim VP2 from the pharmaceutical company's VC2 using a hash XOR tree structure. VP2 contains the production license, sales license, drug information, and a signature made with the pharmaceutical company's private key. The pharmaceutical company client then combines VP2 and DID. med Send to the distributor's client; if verification fails or the pharmaceutical company does not have the corresponding drug, the transaction is terminated; S35, the distributor client verifies the integrity of VP2. If the verification passes, it notifies the pharmaceutical company client to upload the transaction information to the smart contract. The smart contract automatically updates the drug VC. med The transaction field in the updated VC, and the updated VC med and DID med The document is uploaded to the blockchain; if verification fails, the transaction is terminated.
2. The drug supply chain supervision method based on decentralized identity identification as described in claim 1, characterized in that, The user registration process includes the following steps: S11, each participating client generates its own public-private key pair; S12, each participating client generates its own DID. i and DID i Document, DID i The document contains DID i Public key PK i Verify the method and service endpoint information, and then use the DID. i The document is first uploaded to the IPFS system so that the IPFS system can generate a Content Identifier (CID). i Then CID i Uploaded to the blockchain with DIDi, including CID i It is DID i The hash value corresponding to the document; S13, each participating client sends an application for a verifiable credential (VC) to the regulatory client. i The request includes a DID generated by the participating client. i Documents, registration information info i Use the private key to sign the request data; S14, Upon receiving the request, the monitoring client verifies the DID. i DID in the document i Check if it has been registered in the blockchain, verify the correctness of the signature on the application data, and verify the registration information (info). i To verify the authenticity of the data, if all the above verifications pass, the regulatory client returns the VC value to the participating client. i VC i Includes the registration information of the participants (info) i DID of the participants i The regulator's DID, license statement, and root access. i And the regulator's signature, which includes the signature of the root. i The signature, the registration information of the participating parties (info) i The signature, root i It is the registration information of the participants. i The information attributes within are generated using a hash XOR tree structure to produce the final root value; S15, upon receiving the VC, each participating client... i Then, they store them in their respective identity wallets.
3. The drug supply chain supervision method based on decentralized identity identification as described in claim 1, characterized in that, The drug registration process includes the following steps: S21, whenever a batch of medicines is produced, the pharmaceutical company's client generates a unique identifier (DID) for each batch of medicines through an identity wallet. med and DID med Document, DID med The document contains DID med The pharmaceutical company's public key, authentication method, and service endpoint, and the DID med The document is uploaded to the IPFS system so that the IPFS system can generate a CID. med Then CID med Uploaded to the blockchain; S22, Pharmaceutical client based on DID med Vitamin C for drug production med Vitamin C in medicine med DID Record med In addition to drug information, timestamps, and a root generated from a hash XOR tree structure using drug information as an attribute. med Use the pharmaceutical company's private key to root. med And the signature of all information; S23, the pharmaceutical company's client will sign the drug VC. med Uploaded to the blockchain.
4. The drug supply chain supervision method based on decentralized identity identification as described in claim 1, characterized in that, The aforementioned sub-step for supervising the process from distributors to pharmacies includes the following steps: S41, During the process of medicines flowing from distributors to pharmacies, the pharmacy client generates a one-time traceable address addr4={pk_addr4,R4,r4} and the private key sk_addr4 corresponding to the one-time traceable address; S42, the pharmacy client selectively discloses the pharmacy's verifiable credential VC4 through a hash XOR tree structure, selecting the fields to be disclosed, the verification path, and the root4, and generates a verifiable claim VP4 based on the disclosed information. VP4 contains the signature made by the pharmacy client using the pharmacy's private key. S43, When purchasing medicines, pharmacies use a one-time traceable address addr4 to send the one-time traceable address addr4, VP4 and random number r4 to the distributor client; S44. After receiving the information from the pharmacy client, the distributor client verifies the validity of the one-time traceable address addr4, the integrity of VP4, and the validity of the signature in VP4. If all verifications pass, the distributor client checks whether it stores the drug corresponding to the disclosure field. If so, the distributor client generates a verifiable claim VP3 from the distributor's VC3 using a hash XOR tree structure. The VP3 contains sales authorization and drug information, and the VP3 and DID are then linked together. med Send to the pharmacy's client; if verification fails or the distributor does not have the corresponding medicine, the transaction is terminated; S45, the pharmacy client verifies the integrity of VP3. If the verification passes, it notifies the distributor client to upload the transaction information to the smart contract. The smart contract automatically updates the drug VC. med The transaction field in the updated VC, and the updated VC med and DID med The document is uploaded to the blockchain; if verification fails, the transaction is terminated.
5. The drug supply chain supervision method based on decentralized identity identification according to claim 1, characterized in that, The regulatory sub-steps for the pharmacy-to-consumer link include the following steps: S51, the consumer client generates a one-time traceable address addr5={pk_addr5,R5,r5}, and the corresponding private key sk_addr5 and DID5; S52, determine whether the drug to be purchased is a prescription drug. If it is a prescription drug, the consumer client submits its DID5, registration information info5 encrypted with the hospital's public key, one-time traceable address addr5, and the signature of the application data with the consumer's private key to the hospital client, and then proceeds to step S53; if it is an over-the-counter drug, proceed to step S56. S53, the hospital client determines whether the consumer has the authority to purchase prescription drugs. If the consumer has the authority to purchase prescription drugs, the hospital client sends a verifiable credential VC5 representing the right to purchase prescription drugs to the consumer client, and then proceeds to step S54. If the consumer does not have the authority to purchase prescription drugs, the transaction is terminated. S54, the consumer client generates a verifiable statement VP5 based on the information disclosed in VC5, and sends VP5, a one-time traceable address addr5 and a random number r5 to the pharmacy client, and then proceeds to step S55; S55, the pharmacy client verifies the validity of the one-time traceable address addr5, the integrity of VP5, and the validity of the signature in VP5. After successful verification, the pharmacy client sends the VP4 and the drug DID. med Send to the consumer client, then proceed to step S58; S56, the consumer client sends the one-time traceable address addr5 and the random number r5 to the pharmacy client, and then proceeds to step S57; S57, the pharmacy client verifies the validity of the one-time traceable address addr5, and after successful verification, sends the pharmacy client's VP4 and the drug's DID. med Send to the consumer client, then proceed to step S58; S58: The consumer client verifies the integrity of the pharmacy's VP4. If the verification passes, the consumer client is notified to upload the transaction information to the smart contract. The smart contract automatically updates the drug VC. med The transaction field in the updated VC, and the updated VC med and DID med The document is uploaded to the blockchain; if verification fails, the transaction is terminated.
6. A drug supply chain supervision system based on decentralized identity identification, characterized in that, It includes regulatory clients and participating party clients, including pharmaceutical company clients, distributor clients, pharmacy clients, and hospital clients; Each participating party's client is configured to generate its own decentralized identity identifier (DID) and DID document during the user registration process, and obtain a verifiable credential (VC) signed by the regulator. The pharmaceutical company's client is also configured to generate a decentralized identity (DID) for each batch of drugs during the drug registration process. med DID med Documentation and VC med ; Each participating client is also configured to, during the regulatory steps of the distribution process, generate a one-time traceable address and a Verifiable Declaration for the Buyer (VP). The VP is generated by selectively disclosing information from the Verifiable Credential (VC) using a hash XOR tree structure. The Seller client verifies the validity of the one-time traceable address, the completeness of the VP, and the validity of the signature in the VP. If all verifications pass, the Seller client sends the VP generated from the VC using a hash XOR tree structure to the Buyer client. After verifying the completeness of the VP, the Buyer client notifies the Seller client to update the VC. med The transaction field in; In the distribution process of medicines from pharmaceutical factories to distributors, the pharmaceutical factories are the sellers and the distributors are the buyers; in the distribution process of medicines from distributors to pharmacies, the distributors are the sellers and the pharmacies are the buyers; and in the distribution process of medicines from pharmacies to consumers, the pharmacies are the sellers and the consumers are the buyers. The aforementioned regulatory steps in the distribution process include sub-steps for regulating the process from pharmaceutical manufacturers to distributors, from distributors to pharmacies, and from pharmacies to consumers; among them, the sub-step for regulating the process from pharmaceutical manufacturers to distributors includes the following steps: S31, During the process of drugs flowing from the pharmaceutical factory to the distributor, the distributor client generates a one-time traceable address addr3={pk_addr3,R3,r3} and a private key sk_addr3 corresponding to the one-time traceable address, where pk_addr3 is the public key corresponding to the one-time traceable address and r3 is a random number; S32, the dealer client selectively discloses the dealer's verifiable credential VC3 through a hash XOR tree structure, selects the fields to be disclosed, the verification path and the root root3, and generates a verifiable claim VP3 based on the disclosed information. VP3 contains the signature made by the dealer client using the dealer's private key. S33, when purchasing medicines, the distributor uses a one-time traceable address addr3 to send the one-time traceable address addr3, VP3 and random number r3 to the pharmaceutical company's client; S34, after receiving the information from the distributor's client, the pharmaceutical company client verifies the validity of the one-time traceable address addr3, the integrity of VP3, and the validity of the signature in VP3. If all verifications pass, the pharmaceutical company client checks whether it has produced the drug corresponding to the disclosure field. If so, the pharmaceutical company client generates a verifiable claim VP2 from the pharmaceutical company's VC2 using a hash XOR tree structure. VP2 contains the production license, sales license, drug information, and a signature made with the pharmaceutical company's private key. The pharmaceutical company client then combines VP2 and DID. med Send to the distributor's client; if verification fails or the pharmaceutical company does not have the corresponding drug, the transaction is terminated; S35, the distributor client verifies the integrity of VP2. If the verification passes, it notifies the pharmaceutical company client to upload the transaction information to the smart contract. The smart contract automatically updates the drug VC. med The transaction field in the updated VC, and the updated VC med and DID med The document is uploaded to the blockchain; if verification fails, the transaction is terminated.
7. A computer program product comprising computer-readable instructions, characterized in that, The computer-readable instructions, when executed by a processor, implement the steps of the drug supply chain supervision method based on decentralized identity as described in any one of claims 1-5.
8. A computer-readable storage medium comprising computer-readable instructions, characterized in that, The computer-readable instructions, when executed by a processor, implement the steps of the drug supply chain supervision method based on decentralized identity as described in any one of claims 1-5.
9. An electronic device, characterized in that, include: Memory, which stores program instructions; The processor, connected to the memory, executes program instructions in the memory to implement the steps in the drug supply chain supervision method based on decentralized identity identification as described in any one of claims 1-5.
Citation Information
Patent Citations
Cross-block chain identity verification method and system in cloud computing environment
CN113806699A
Product quality inspection traceability method and device based on block chain
CN116883024A