CN116405265A - Communication method and device for service end and user end of DID system - Google Patents

Communication method and device for service end and user end of DID system Download PDF

Info

Publication number
CN116405265A
CN116405265A CN202310264156.XA CN202310264156A CN116405265A CN 116405265 A CN116405265 A CN 116405265A CN 202310264156 A CN202310264156 A CN 202310264156A CN 116405265 A CN116405265 A CN 116405265A
Authority
CN
China
Prior art keywords
service
response data
public key
server
service response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310264156.XA
Other languages
Chinese (zh)
Inventor
徐登伟
陈远
辛知
孙善禄
张涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alipay Hangzhou Information Technology Co Ltd
Original Assignee
Alipay Hangzhou Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Hangzhou Information Technology Co Ltd filed Critical Alipay Hangzhou Information Technology Co Ltd
Priority to CN202310264156.XA priority Critical patent/CN116405265A/en
Publication of CN116405265A publication Critical patent/CN116405265A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

The invention relates to a communication method and a device of a user side and a service side of a DID system, wherein the method is applied to the service side for providing DID service and comprises the following steps: receiving a DID service acquisition request sent by a user terminal; generating DID service response data to be transmitted according to the DID service acquisition request; signing DID service response data to be transmitted by adopting a preset private key; and sending the signed DID service response data to the user side, so that the user side verifies the signature of the DID service response data by adopting a preset public key, and acquiring the DID service based on the DID service response data after the signature verification is passed. According to the communication method and device of the service end and the user end of the DID system, the DID service response data is signed through the preset private key, so that the user end verifies the signature through the preset public key, and the DID service response data is ensured to be sent from the service end.

Description

Communication method and device for service end and user end of DID system
Technical Field
The invention relates to the field of decentralised identity, in particular to a communication method and a communication device for a service end and a user end of a DID system.
Background
The de-centralized identity (Decentralized Identity, DID) is a type of digital identity that is derived and derived from traditional centralized identities, and in a DID system, each entity (including individuals, organizations, devices, etc.) uses a DID identity, which is a string of characters in a specific format that represents the digital identity of the entity. Each DID identity corresponds to a DID document. The DID identification may be used as a Uniform Resource Identifier (URI) for locating the DID document. The DID document is descriptive text including a preset format (e.g., JSON-LD) on the DID identity and the owner of the DID. The DID document may include various attributes such as context, DID topic, public key, authentication, authorization and delegation, service endpoint, and so forth.
When an entity is to join in the DID system, it is necessary to apply to a server for creating and managing the DID, then the server generates the DID identifier and the DID document of the entity, and uploads the DID document to the blockchain, and in this process, the entity (which may be a user at this time) needs to perform data communication with the server. If the data transmitted from the server to the client is not trusted, the DID identifier and the DID document cannot be guaranteed to be generated by the server, so that the data of the client is leaked.
Therefore, how to ensure the credibility of the data transmitted from the server to the client is a technical problem to be solved by those skilled in the art.
Disclosure of Invention
The invention aims to provide a communication method between a service end and a user end of a DID system, which signs DID service response data through a preset private key so that the user end verifies the signature through a preset public key, thereby ensuring that the DID service response data is sent from the service end.
Based on the above object, the present invention provides a communication method between a user terminal and a server terminal of a DID system, where the method is applied to the server terminal providing the DID service, and the method includes the steps of:
receiving a DID service acquisition request sent by a user terminal;
generating DID service response data to be transmitted according to the DID service acquisition request;
signing the DID service response data to be transmitted by adopting a preset private key;
and sending the signed DID service response data to the user side, so that the user side verifies the signature of the DID service response data by adopting a preset public key, and after the signature verification is passed, acquiring the DID service based on the DID service response data.
Further, in some embodiments, the DID service obtaining request is a create DID request, and the DID service response data includes a DID identifier generated by the server according to the create DID request and an upload success message generated by the server after uploading the DID document to the blockchain.
Further, in some embodiments, the DID service acquisition request is a VC creation request sent by a user side requesting a VC, and the DID service response data is a VC sent to the server side by the user side that issued the VC.
Further, in some embodiments, when the preset public key needs to be updated, the method further includes:
receiving a symmetric key which is sent by the user terminal and is encrypted by the preset public key;
decrypting the encrypted symmetric key through the preset private key;
generating a second public key and a second private key;
encrypting the second public key by adopting the decrypted symmetric key;
and sending the encrypted second public key to the user side so that the user side decrypts the encrypted second public key through the symmetric key, and when receiving DID service response data signed by the server side by adopting the second private key, verifying the signature of the DID service response data by adopting the second public key.
The invention also aims to provide a communication method between the service end and the user end of the DID system, which verifies the DID service response data sent by the service end after the signature by the preset private key through the preset public key, thereby ensuring that the received DID service response data is sent by the service end.
Based on the above object, the present invention provides a communication method between a user terminal and a server terminal of a DID system, where the method is applied to the user terminal requesting the DID service, and the method includes the steps of:
sending a DID service acquisition request to the server side, so that the server side generates DID service response data to be transmitted according to the DID service acquisition request, signs the DID service response data to be transmitted by adopting a preset private key, and then sends the signed DID service response data to the user side;
receiving the signed DID service response data;
and verifying the signature of the DID service response data by adopting a preset public key, and acquiring the DID service based on the DID service response data after the signature is verified.
Further, in some embodiments, the DID service obtaining request is a create DID request, and the DID service response data includes a DID identifier generated by the server according to the create DID request and an upload success message generated by the server after uploading the DID document to the blockchain.
Further, in some embodiments, the DID service acquisition request is a VC creation request sent by a user side requesting a VC, and the DID service response data is a VC sent to the server side by the user side that issued the VC.
Further, in some embodiments, when the preset public key needs to be updated, the method further includes:
generating a symmetric key;
encrypting the symmetric key through the preset public key;
the encrypted symmetric key is sent to the server, so that the server decrypts the encrypted symmetric key by adopting the preset private key, generates a second public key and a second private key, encrypts the second public key through the symmetric key, and sends the encrypted second public key to the user;
receiving the encrypted second public key;
and when receiving DID service response data signed by the second private key sent by the server, verifying the signature of the DID service response data by adopting the second public key.
Still another object of the present invention is to provide a communication device between a service end and a user end of a DID system, in which the user end verifies the signature by a preset public key by signing the DID service response data with a preset private key, so as to ensure that the DID service response data is sent from the service end.
Based on the above object, the present invention provides a communication device for a user side and a server side of a DID system, the device being applied to the server side providing a DID service, the device comprising:
The first receiving module is used for receiving a DID service acquisition request sent by a user side;
the generation module is used for generating DID service response data to be transmitted according to the DID service acquisition request;
the signature module is used for signing the DID service response data to be transmitted by adopting a preset private key;
the first sending module is configured to send the signed DID service response data to the user side, so that the user side verifies the signature of the DID service response data by using a preset public key, and obtains the DID service based on the DID service response data after the signature verification is passed.
Further, in some embodiments, the DID service obtaining request is a create DID request, and the DID service response data includes a DID identifier generated by the server according to the create DID request and an upload success message generated by the server after uploading the DID document to the blockchain.
Further, in some embodiments, the DID service acquisition request is a VC creation request sent by a user side requesting a VC, and the DID service response data is a VC sent to the server side by the user side that issued the VC.
Further, in some embodiments, the method further comprises a first update module configured to:
When a preset public key needs to be updated, receiving a symmetric key which is sent by the user terminal and is encrypted by the preset public key;
decrypting the encrypted symmetric key through the preset private key;
generating a second public key and a second private key;
encrypting the second public key by adopting the decrypted symmetric key;
and sending the encrypted second public key to the user side so that the user side decrypts the encrypted second public key through the symmetric key, and when receiving DID service response data signed by the server side by adopting the second private key, verifying the signature of the DID service response data by adopting the second public key.
Still another object of the present invention is to provide a communication device between a service end and a user end of a DID system, which verifies, by a preset public key, DID service response data sent by the service end and signed by a preset private key, thereby ensuring that the received DID service response data is sent by the service end.
Based on the above object, the present invention provides a communication device for a user side and a server side of a DID system, the device being applied to the user side requesting the DID service, the device comprising:
the second sending module is configured to send a DID service acquisition request to the server side, so that the server side generates DID service response data to be transmitted according to the DID service acquisition request, signs the DID service response data to be transmitted by adopting a preset private key, and then sends the signed DID service response data to the user side;
The second receiving module is used for receiving the signed DID service response data;
and the verification module is used for verifying the signature of the DID service response data by adopting a preset public key, and acquiring the DID service based on the DID service response data after the signature is verified.
Further, in some embodiments, the DID service obtaining request is a create DID request, and the DID service response data includes a DID identifier generated by the server according to the create DID request and an upload success message generated by the server after uploading the DID document to the blockchain.
Further, in some embodiments, the DID service acquisition request is a VC creation request sent by a user side requesting a VC, and the DID service response data is a VC sent to the server side by the user side that issued the VC.
Further, in some embodiments, the method further includes a second update module configured to:
when the preset public key needs to be updated, generating a symmetric key;
encrypting the symmetric key through the preset public key;
the encrypted symmetric key is sent to the server, so that the server decrypts the encrypted symmetric key by adopting the preset private key, generates a second public key and a second private key, encrypts the second public key through the symmetric key, and sends the encrypted second public key to the user;
Receiving the encrypted second public key;
and when receiving DID service response data signed by the second private key sent by the server, verifying the signature of the DID service response data by adopting the second public key.
Drawings
Fig. 1 is a schematic configuration diagram of a DID system according to an exemplary embodiment of the present invention;
fig. 2 is a flowchart of a communication method between a service end and a user end of a DID system according to an embodiment of the present invention;
fig. 3 is a flowchart of a communication method between a service end and a user end of a DID system according to another embodiment of the present invention;
fig. 4 is a schematic structural diagram of a communication device of a service side and a user side of a DID system according to an embodiment of the present invention;
fig. 5 is a schematic structural diagram of a communication device of a service side and a user side of a DID system according to another embodiment of the present invention.
Detailed Description
Preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.
In the DID system, each entity (including individuals, organizations, devices, etc.) has a DID identity, which is a string in a specific format that represents the digital identity of the entity. Each DID identity corresponds to a DID document. The DID identification may be used as a Uniform Resource Identifier (URI) for locating the DID document. The DID identity includes a Scheme (Scheme), a DID method, and a DID method specific string (DID method specific string), wherein the Scheme is fixed to represent that the string is a DID identity string, the DID method represents through which set of methods the DID identity is defined and operated, and the DID method specific string is used to represent a unique identity string under the DID method. Each DID identity corresponds to a DID document. The DID identification may be used as a Uniform Resource Identifier (URI) for locating the DID document. The DID document is descriptive text including a preset format (e.g., JSON-LD) on the DID identity and the owner of the DID. The DID document may include various attributes such as context, DID topic, public key, authentication, authorization, and delegation, service endpoint, creation, update, attestation, extensibility, other suitable attributes, or any combination thereof. The DID document may define or point to a resource defining a plurality of operations that may be performed with respect to the DID.
The DID of an entity may allow the entity to gain complete control over its identity and its identity-related information. Verifiable Claims (VCs) may allow authorization, endorsements, and acknowledgements between different entities. In a business environment, a service or provider may use its customer's DID and VC to identify and authenticate the customer and provide a corresponding service or product.
The VC may provide verifiable online information about the quality, characteristics, relationships, and other related information of the entity. VC may contain descriptive text in a pre-set format (e.g., JSON-LD) describing one or more claims about DID (e.g., age of DID owner, educational background of DID owner), and endorsements of the claims by the entity. The VC may include various attributes such as context, identity, type, credential topic, publisher, release date, proof, expiration date, status, representation, other suitable attributes, or any combination thereof. The VC may specify the type of its declaration (claim), which may indicate the structure of the declaration. This may prompt the VC issuer and VC verifier to automatically process.
Each entity in the DID system may participate in and implement the DID service in different roles. For example, one entity (individual) desires to use a service provided by a business entity (e.g., an internet cafe) that needs to prove that the individual has exceeded 18 years old, the individual can request a VC issued by another entity (a government agency providing citizen age verification), at which point the government agency is the VC issuer, the individual is the VC holder, and the business entity is the VC verifier. The business entity may authenticate the VC to ensure that the individual meets age requirements. In another example, one entity (user) may issue a VC to another entity (first enterprise) to allow it to use data stored by yet another entity (second enterprise), where the user is a VC issuer, the first enterprise is a VC holder, and the second enterprise is a VC verifier.
As shown in fig. 1, in an exemplary embodiment, the DID system 100 includes a server 110 and a plurality of entities 120, and a server 111 is run on the server 110 for creating and managing a DID, and a user 121 is run on each entity 120 for executing a DID service. For example, when an entity 120 is to join the DID system, the user terminal 121 on the entity 120 sends a request to the server terminal 111, and after receiving the request, the server terminal 111 generates a DID identifier and a DID document, where the DID document includes a public key, and the private key is stored in the user terminal 121 or the server terminal 111; the DID document is then uploaded to the blockchain 130, and after the uplink is completed, all entities 120 on the blockchain 130 can view the DID document. Or, when one entity 120 (first entity) needs another entity 120 (second entity) to issue a verifiable statement (VC) for it, the client 121 on the first entity sends a VC request to the server 111, after the server 111 receives the VC request, the VC request is sent to the client 121 on the second entity, the client 121 on the second entity generates a VC according to the VC request, and sends the VC to the server 111, and then the server 111 sends the VC to the client 121 on the first entity.
In the DID system, in order to implement the DID service, the server 111 and the client 121 need to communicate with each other, for example, in a scenario of creating a DID, the server 111 sends the generated DID identifier to the client 121; or, after the server 111 uploads the DID document to the blockchain 130, an upload success request is sent to the client 121 (if the upload fails, an upload failure request is sent); or, in the application scenario of requesting VC, the server 111 may send the VC generated by the client 121 that issued the VC to the client 121 that requested the VC. In the process of the communication between the server 111 and the client 121, if the data sent by the server 111 to the client 121 is attacked, for example, the DID identifier generated by the server 111 is replaced by an attacker or the attacker replaces the upload success message with the upload failure message, then data leakage may be caused or the DID service cannot be implemented. Therefore, it is important to ensure that the data transmitted from the server 111 to the client 121 is reliable for the proper operation of the DID system.
In order to solve the above-mentioned problems, the present invention provides a communication method between a service end and a user end of a DID system, where the service end 111 signs the DID service response data by a preset private key, and the user end 121 verifies the signature by a preset public key to ensure that the DID service response data is sent by the service end 111.
As shown in fig. 2, an embodiment of the present invention provides a communication method between a service end and a user end of a DID system, where the method is applied to a service end 111 providing a DID service, and includes the following steps:
s210: receiving a DID service acquisition request sent by the user terminal 121;
s220: generating DID service response data to be transmitted according to the DID service acquisition request;
s230: signing DID service response data to be transmitted by adopting a preset private key;
s240: and sending the signed DID service response data to the user side so that the user side verifies the signature of the DID service response data by adopting a preset public key, and acquiring the DID service based on the DID service response data after the signature verification is passed.
In some embodiments, the DID service may be a service for creating a DID, and accordingly, the DID service obtaining request is a DID creating request, and the DID service response data is a DID identifier generated by the server 111 according to the DID creating request or an upload success message generated by the server 111 after uploading the DID document to the blockchain 130.
In some embodiments, the specific steps of the method of the embodiment of the present invention applied in creating the DID scene are as follows:
the server 111 receives the DID creation request sent by the user 121;
The server 111 generates a DID identifier according to the request;
the server 111 signs the DID identifier by using a preset private key, and sends the signed DID identifier to the client 121, so that the client 121 verifies the signature of the DID identifier by using a preset public key, and after verification, the user public key and the user private key generated according to the DID identifier are generated, and then sends the user public key to the server 111;
the server 111 receives the user public key, generates a DID document according to the user public key and the DID identifier, and then uploads the DID document to the blockchain 130;
after the uploading is successful, the server 111 generates an uploading success message, signs the uploading success message by using a preset private key, and then sends the signed uploading success message to the user 121, so that the user 121 verifies the signature of the uploading success message by using the preset public key, and after the verification, the user 121 can participate in other DID services of the DID system through the user private key.
In some embodiments, the DID service may be a service for creating a VC, and the corresponding DID service acquisition request is a request for creating a VC, and the DID service response data is a VC generated by the user terminal 121 that issued the VC. Since VC is generated by an issuer (hereinafter referred to as a second user side) and stored by a holder (hereinafter referred to as a first user side), in an application scenario where VC is requested, the server 111 needs to communicate to both user sides. The method of the embodiment of the invention is used in the application scene of creating the VC and comprises the following steps:
The server 111 receives a VC creation request sent by a first user;
the server 111 signs the VC creation request by using a preset private key, and sends the signed VC creation request to the second user, so that the second user verifies the signature of the VC creation request by using a preset public key, generates VC according to the VC creation request after verification is passed, and sends the generated VC to the server 111;
the server 111 receives the VC and signs the VC with a preset private key, and then sends the signed VC to the first user, so that the first user verifies the VC signature with the preset public key, and after verification, the first user saves the VC to participate in other DID services of the DID system through the VC.
It will be appreciated that the method according to the embodiment of the present invention may be used whenever the server 111 needs to transmit data to the client 121, and thus the method of the present invention is not limited to the two scenarios described above, but may be applied to any scenario in which the server 111 and the client 121 communicate.
Since the preset public key and the preset private key are pre-generated and may not be secure, they need to be updated. In some embodiments, when the preset public key needs to be updated (e.g., due to a preset public key failure or for other security reasons), the method further comprises:
The server 111 receives the symmetric key encrypted by the preset public key sent by the user 121;
the server 111 decrypts the encrypted symmetric key through a preset private key;
the server 111 generates a second public key and a second private key;
the server 111 encrypts the second public key by using the decrypted symmetric key;
the server 111 sends the encrypted second public key to the client 121, so that the client 121 decrypts the encrypted second public key through the symmetric key, and when receiving the DID service response data signed by the server with the second private key, verifies the signature of the DID service response data with the second public key.
After updating, signing and signing verification operations are performed by adopting the new second private key and the second public key, so that the credibility of the data transmitted to the user terminal 121 by the server terminal 111 is ensured. Since the symmetric key is generated at the user terminal 121 and is encrypted by the preset public key and then sent to the server terminal 111, the security of the symmetric key can be ensured, while the second private key and the second public key are generated at the server terminal 111, the second public key is encrypted by the symmetric key and then transmitted to the user terminal 121, so that the security of the second public key in the transmission process can be ensured, and even if an attacker obtains the encrypted second public key, the attacker cannot obtain the plaintext of the encrypted second public key because the symmetric key is not available. The updated second public key is only owned by the server 111 and the client 121, so that the data transmitted from the server 111 to the client 121 can be ensured to be trusted.
As shown in fig. 3, another embodiment of the present invention provides a communication method between a user side and a server side of a DID system, where the method is applied to a user side 121, and includes the following steps:
s310: sending a DID service acquisition request to the server 111, so that the server 111 generates DID service response data to be transmitted according to the DID service acquisition request, signs the DID service response data to be transmitted by using a preset private key, and then sends the signed DID service response data to the client 121;
s320: receiving signed DID service response data;
s330: and verifying the signature of the DID service response data by adopting a preset public key, and acquiring the DID service based on the DID service response data after the signature is verified.
When the user terminal 121 wants to acquire the DID service, a DID service acquisition request is sent to the server terminal 111, after the server terminal 111 receives the DID service acquisition request, the server terminal 111 generates DID service response data to be transmitted according to the request, then signs the DID service response data with a preset private key, and sends the signed DID service response data to the user terminal 121, the user terminal 121 verifies the signature with a preset public key, after verification, it is indicated that the DID service response data is sent by the server terminal 111 (i.e. is trusted), and the user terminal 121 can acquire the DID service based on the DID service response data.
In some embodiments, the DID service may be a service for creating a DID, and accordingly, the DID service obtaining request is a DID creating request, and the DID service response data is a DID identifier generated by the server 111 according to the DID creating request or an upload success message generated by the server 111 after uploading the DID document to the blockchain 130.
In some embodiments, the specific steps of the method of the embodiment of the present invention applied in creating the DID scene are as follows:
the user terminal 121 sends a DID creating request to the server terminal 111, so that the server terminal 111 generates a DID identifier according to the DID creating request, signs the DID identifier by adopting a preset private key, and then sends the signed DID identifier to the user terminal 121;
the user terminal 121 receives the signed DID identifier;
the user 121 verifies the signature of the DID identity using a preset public key;
after the verification is passed, the user terminal 121 generates a user public key and a user private key according to the DID identifier, and sends the user public key to the server terminal 111, so that the server terminal 111 generates a DID document according to the user public key and the DID identifier, uploads the DID document to the blockchain 130, after the uploading is successful, the server terminal 111 generates an uploading success message, then signs the uploading success message by adopting a preset private key, and sends the signed uploading success message to the user terminal 121;
The user terminal 121 receives the signed uploading success message;
the user terminal 121 adopts a preset public key to verify the signature of the uploading success message, and after the verification is passed, the user terminal 121 can participate in other DID services of the DID system through the private key of the user.
In other embodiments, the DID service may be a service for creating a VC, and the corresponding DID service acquisition request is a request for creating a VC, and the DID service response data is a VC generated by the user terminal 121 that issued the VC. The method of the embodiment of the invention is used in the application scene of requesting VC as follows:
the first user terminal sends a VC creation request to the server terminal 111, so that the server terminal 111 signs the VC creation request by adopting a preset private key, and sends the signed VC creation request to the second user terminal;
the second user side verifies the signature of the VC creation request by adopting a preset public key, after the verification is passed, the VC is generated according to the VC creation request, the generated VC is sent to the server side 111, so that the server side 111 signs the VC by adopting a preset private key, and then the signed VC is sent to the first user side;
the first user terminal adopts a preset public key to verify the signature of the VC, and after the signature passes the verification, the first user terminal stores the VC so as to participate in other DID services of the DID system through the VC.
In some embodiments, when the preset public key needs to be updated (e.g., due to a preset public key failure or for other security reasons), the method further comprises:
the user terminal 121 generates a symmetric key;
the user 121 encrypts the symmetric key through a preset public key;
the user terminal 121 sends the encrypted symmetric key to the server terminal 111, so that the server terminal 111 decrypts the encrypted symmetric key by adopting a preset private key, generates a second public key and a second private key, encrypts the second public key through the symmetric key, and sends the encrypted second public key to the user terminal 121;
the user terminal 121 receives the encrypted second public key;
when receiving the DID service response data signed with the second private key sent by the server 111, the user 121 verifies the signature of the DID service response data with the second public key.
After updating, signing and signing verification operations are performed by adopting the new second private key and the second public key, so that the credibility of the data transmitted to the user terminal 121 by the server terminal 111 is ensured.
In some embodiments, to further secure the second public key, it may be stored in the trusted execution environment and the signature is verified in the trusted execution environment using the second public key.
In the communication method between the user terminal and the server terminal of the DID system in the embodiment of the present invention, the preset private key is used to sign the DID service response data to be transmitted, so that after receiving the signed DID service response data, the user terminal 121 verifies the signature by using the preset public key, thereby ensuring that the DID service response data is sent by the server terminal 111.
As shown in fig. 4, an embodiment of the present invention provides a communication device for a user side and a server side of a DID system, where the device is applied to the server side 111, and includes a first receiving module 11, a generating module 12, a signing module 13, and a first transmitting module 14.
The first receiving module 11 is configured to receive a DID service acquisition request sent by the user terminal.
The generating module 12 is configured to generate the DID service response data to be transmitted according to the DID service acquisition request.
The signature module 13 is configured to sign the DID service response data to be transmitted using a preset private key.
The first sending module 14 is configured to send the signed DID service response data to the user side, so that the user side verifies the signature of the DID service response data by using a preset public key, and obtains the DID service based on the DID service response data after the signature verification is passed.
In some embodiments, the DID service may be a service for creating a DID, and accordingly, the DID service obtaining request is a DID creating request, and the DID service response data is a DID identifier generated by the server 111 according to the DID creating request or an upload success message generated by the server 111 after uploading the DID document to the blockchain 130.
In other embodiments, the DID service may be a service for creating a VC, and the corresponding DID service acquisition request is a request for creating a VC, and the DID service response data is a VC generated by the user terminal 121 that issued the VC. Since VC is generated by an issuer (hereinafter referred to as a second user side) and stored by a holder (hereinafter referred to as a first user side), in an application scenario where VC is requested, the server 111 needs to communicate to both user sides.
In some embodiments, the apparatus further comprises a first update module configured to:
when the preset public key needs to be updated, receiving a symmetric key encrypted by the preset public key and sent by the user terminal 121;
decrypting the encrypted symmetric key through a preset private key;
generating a second public key and a second private key;
encrypting the second public key by adopting the decrypted symmetric key;
and sending the encrypted second public key to the user terminal 121, so that the user terminal 121 decrypts the encrypted second public key through the symmetric key, and when receiving the DID service response data signed by the server terminal by adopting the second private key, verifies the signature of the DID service response data by adopting the second public key.
After updating, signing and signing verification operations are performed by adopting the new second private key and the second public key, so that the credibility of the data transmitted to the user terminal 121 by the server terminal 111 is ensured.
As shown in fig. 5, another embodiment of the present invention provides a communication device for a user side and a server side of a DID system, which is applied to a user side 121 and includes a second transmitting module 21, a second receiving module 22, and a verifying module 23.
The second sending module 21 is configured to send a DID service obtaining request to the server 111, so that the server 111 generates DID service response data to be transmitted according to the DID service obtaining request, signs the DID service response data to be transmitted by using a preset private key, and then sends the signed DID service response data to the user.
The second receiving module 22 is configured to receive the signed DID service response data.
The verification module 23 is configured to verify the signature of the DID service response data using a preset public key, and obtain the DID service based on the DID service response data after the signature is verified.
In some embodiments, the DID service may be a service for creating a DID, and accordingly, the DID service obtaining request is a DID creating request, and the DID service response data is a DID identifier generated by the server 111 according to the DID creating request or an upload success message generated by the server 111 after uploading the DID document to the blockchain 130.
In other embodiments, the DID service may be a service for creating a VC, and the corresponding DID service acquisition request is a request for creating a VC, and the DID service response data is a VC generated by the user terminal 121 that issued the VC.
In some embodiments, the apparatus further comprises a second update module configured to:
when the preset public key needs to be updated, generating a symmetric key;
encrypting the symmetric key through a preset public key;
the encrypted symmetric key is sent to the server 111, so that the server 111 decrypts the encrypted symmetric key by adopting a preset private key, generates a second public key and a second private key, encrypts the second public key through the symmetric key, and sends the encrypted second public key to the client 121;
receiving the encrypted second public key;
upon receiving the DID service response data signed with the second private key transmitted by the server 111, the signature of the DID service response data is verified with the second public key.
After updating, signing and signing verification operations are performed by adopting the new second private key and the second public key, so that the credibility of the data transmitted to the user terminal 121 by the server terminal 111 is ensured.
The communication devices of the user side and the server side of the DID system in the embodiment of the present invention sign the DID service response data to be transmitted by a preset private key, so that after receiving the signed DID service response data, the user side 121 verifies the signature by using a preset public key, so as to ensure that the DID service response data is sent by the server side 111.
Still another embodiment of the present invention provides a readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the steps of the communication method of the user side and the server side of the DID system in the above-described embodiment of the present invention.
Still another embodiment of the present invention provides an electronic device including a memory and a processor, in which executable codes are stored, which when executed by the processor, perform the steps of the communication method of the user side and the server side of the DID system in the above embodiment of the present invention.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in the same piece or pieces of software and/or hardware when implementing the present invention.
It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
The embodiments of the present invention are described in a progressive manner, and the same and similar parts of the embodiments are all referred to each other, and each embodiment is mainly described in the differences from the other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.
The foregoing description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention, and various modifications can be made to the above-described embodiment of the present invention. All simple, equivalent changes and modifications made in accordance with the claims and the specification of this application fall within the scope of the patent claims. The present invention is not described in detail in the conventional art.

Claims (18)

1. A communication method between a user terminal and a server terminal of a DID system, the method being applied to the server terminal providing a DID service, the method comprising the steps of:
receiving a DID service acquisition request sent by a user terminal;
generating DID service response data to be transmitted according to the DID service acquisition request;
signing the DID service response data to be transmitted by adopting a preset private key;
and sending the signed DID service response data to the user side, so that the user side verifies the signature of the DID service response data by adopting a preset public key, and after the signature verification is passed, acquiring the DID service based on the DID service response data.
2. The communication method between the user side and the server side of the DID system according to claim 1, wherein the DID service obtaining request is a create DID request, and the DID service response data includes a DID identifier generated by the server side according to the create DID request and an upload success message generated by the server side after uploading the DID document to the blockchain.
3. The communication method between a user terminal and a server terminal of the DID system according to claim 1, wherein the DID service acquisition request is a VC creation request sent by a user terminal requesting a VC, and the DID service response data is a VC sent to the server terminal by a user terminal issuing a VC.
4. The communication method between the user side and the server side of the DID system according to claim 1, when the preset public key needs to be updated, the method further comprises:
receiving a symmetric key which is sent by the user terminal and is encrypted by the preset public key;
decrypting the encrypted symmetric key through the preset private key;
generating a second public key and a second private key;
encrypting the second public key by adopting the decrypted symmetric key;
and sending the encrypted second public key to the user side so that the user side decrypts the encrypted second public key through the symmetric key, and when receiving DID service response data signed by the server side by adopting the second private key, verifying the signature of the DID service response data by adopting the second public key.
5. A communication method between a user terminal and a server terminal of a DID system, the method being applied to a user terminal requesting a DID service, the method comprising the steps of:
Sending a DID service acquisition request to the server side, so that the server side generates DID service response data to be transmitted according to the DID service acquisition request, signs the DID service response data to be transmitted by adopting a preset private key, and then sends the signed DID service response data to the user side;
receiving the signed DID service response data;
and verifying the signature of the DID service response data by adopting a preset public key, and acquiring the DID service based on the DID service response data after the signature is verified.
6. The communication method between the user side and the server side of the DID system according to claim 5, wherein the DID service obtaining request is a create DID request, and the DID service response data includes a DID identifier generated by the server side according to the create DID request and an upload success message generated by the server side after uploading the DID document to the blockchain.
7. The communication method between the user side and the server side of the DID system according to claim 5, wherein the DID service acquisition request is a VC creation request sent by the user side requesting VC, and the DID service response data is VC sent to the server side by the user side issuing VC.
8. The communication method between the user side and the server side of the DID system according to claim 5, when the preset public key needs to be updated, the method further comprises:
generating a symmetric key;
encrypting the symmetric key through the preset public key;
the encrypted symmetric key is sent to the server, so that the server decrypts the encrypted symmetric key by adopting the preset private key, generates a second public key and a second private key, encrypts the second public key through the symmetric key, and sends the encrypted second public key to the user;
receiving the encrypted second public key;
and when receiving DID service response data signed by the second private key sent by the server, verifying the signature of the DID service response data by adopting the second public key.
9. A communication apparatus of a user side and a server side of a DID system, the apparatus being applied to the server side providing a DID service, the apparatus comprising:
the first receiving module is used for receiving a DID service acquisition request sent by a user side;
the generation module is used for generating DID service response data to be transmitted according to the DID service acquisition request;
The signature module is used for signing the DID service response data to be transmitted by adopting a preset private key;
the first sending module is configured to send the signed DID service response data to the user side, so that the user side verifies the signature of the DID service response data by using a preset public key, and obtains the DID service based on the DID service response data after the signature verification is passed.
10. The communication device between the user side and the server side of the DID system according to claim 9, wherein the DID service obtaining request is a create DID request, and the DID service response data includes a DID identifier generated by the server side according to the create DID request and an upload success message generated by the server side after uploading the DID document to the blockchain.
11. The communication device between the user side and the server side of the DID system according to claim 9, wherein the DID service acquisition request is a VC creation request sent by the user side requesting VC, and the DID service response data is VC sent to the server side by the user side issuing VC.
12. The communication device between the user side and the server side of the DID system according to claim 9, further comprising a first update module configured to:
When a preset public key needs to be updated, receiving a symmetric key which is sent by the user terminal and is encrypted by the preset public key;
decrypting the encrypted symmetric key through the preset private key;
generating a second public key and a second private key;
encrypting the second public key by adopting the decrypted symmetric key;
and sending the encrypted second public key to the user side so that the user side decrypts the encrypted second public key through the symmetric key, and when receiving DID service response data signed by the server side by adopting the second private key, verifying the signature of the DID service response data by adopting the second public key.
13. A communication apparatus of a user side and a service side of a DID system, the apparatus being applied to a user side requesting a DID service, the apparatus comprising:
the second sending module is configured to send a DID service acquisition request to the server side, so that the server side generates DID service response data to be transmitted according to the DID service acquisition request, signs the DID service response data to be transmitted by adopting a preset private key, and then sends the signed DID service response data to the user side;
The second receiving module is used for receiving the signed DID service response data;
and the verification module is used for verifying the signature of the DID service response data by adopting a preset public key, and acquiring the DID service based on the DID service response data after the signature is verified.
14. The communication device between the user side and the server side of the DID system according to claim 13, wherein the DID service obtaining request is a create DID request, and the DID service response data includes a DID identifier generated by the server side according to the create DID request and an upload success message generated by the server side after uploading the DID document to the blockchain.
15. The communication device between the user side and the server side of the DID system according to claim 13, wherein the DID service acquisition request is a VC creation request sent by the user side requesting VC, and the DID service response data is VC sent to the server side by the user side issuing VC.
16. The communication device between the user side and the server side of the DID system according to claim 13, further comprising a second updating module configured to:
when the preset public key needs to be updated, generating a symmetric key;
encrypting the symmetric key through the preset public key;
The encrypted symmetric key is sent to the server, so that the server decrypts the encrypted symmetric key by adopting the preset private key, generates a second public key and a second private key, encrypts the second public key through the symmetric key, and sends the encrypted second public key to the user;
receiving the encrypted second public key;
and when receiving DID service response data signed by the second private key sent by the server, verifying the signature of the DID service response data by adopting the second public key.
17. A readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the communication method of the user side and the server side of the DID system as claimed in claims 1-8.
18. A further embodiment of the invention provides an electronic device comprising a memory and a processor, the memory having executable code stored therein, which when executed by the processor performs the communication method of the user side and the server side of the DID system as claimed in claims 1-8.
CN202310264156.XA 2023-03-10 2023-03-10 Communication method and device for service end and user end of DID system Pending CN116405265A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310264156.XA CN116405265A (en) 2023-03-10 2023-03-10 Communication method and device for service end and user end of DID system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310264156.XA CN116405265A (en) 2023-03-10 2023-03-10 Communication method and device for service end and user end of DID system

Publications (1)

Publication Number Publication Date
CN116405265A true CN116405265A (en) 2023-07-07

Family

ID=87009495

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310264156.XA Pending CN116405265A (en) 2023-03-10 2023-03-10 Communication method and device for service end and user end of DID system

Country Status (1)

Country Link
CN (1) CN116405265A (en)

Similar Documents

Publication Publication Date Title
US10824701B2 (en) System and method for mapping decentralized identifiers to real-world entities
EP3688930B1 (en) System and method for issuing verifiable claims
CN111095327B (en) System and method for verifying verifiable claims
CN111066020B (en) System and method for creating a decentralised identity
CN111213147A (en) System and method for block chain based cross entity authentication
CN111316303A (en) System and method for block chain based cross entity authentication
US9100171B1 (en) Computer-implemented forum for enabling secure exchange of information
CN113704734A (en) Distributed digital identity-based method for realizing certificate verification and related device
CN112927026A (en) Coupon processing method and device, electronic equipment and computer storage medium
CN115706729B (en) Service providing method and device, equipment and storage medium
CN116405265A (en) Communication method and device for service end and user end of DID system
CN116248274A (en) DID generation method and device, readable storage medium and electronic equipment
CN116760534A (en) Data processing method based on identification, terminal equipment, electronic equipment and medium
CN118353645A (en) Block chain-based credential processing method, device, equipment, medium and product
CN116894236A (en) Authority distribution method and device, processor and electronic equipment
CN116614240A (en) Data transmission method

Legal Events

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