WO2024048838A1 - 블록체인 did 기술 기반의 종단 암호화를 통한 비밀 메신저 기능을 제공하는 전자 장치 및 방법 - Google Patents

블록체인 did 기술 기반의 종단 암호화를 통한 비밀 메신저 기능을 제공하는 전자 장치 및 방법 Download PDF

Info

Publication number
WO2024048838A1
WO2024048838A1 PCT/KR2022/015505 KR2022015505W WO2024048838A1 WO 2024048838 A1 WO2024048838 A1 WO 2024048838A1 KR 2022015505 W KR2022015505 W KR 2022015505W WO 2024048838 A1 WO2024048838 A1 WO 2024048838A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
subscription
agency server
topic
account
Prior art date
Application number
PCT/KR2022/015505
Other languages
English (en)
French (fr)
Inventor
김용태
임병완
Original Assignee
블록체인랩스 주식회사
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 블록체인랩스 주식회사 filed Critical 블록체인랩스 주식회사
Publication of WO2024048838A1 publication Critical patent/WO2024048838A1/ko

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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • 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
    • 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
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • 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/40—Network security protocols
    • 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

Definitions

  • Embodiments disclosed in this document relate to encryption technology and online chat applications.
  • message data Since the messenger service has the function of transmitting users' private message data, the message data must be encrypted.
  • message data In messenger services provided to date, message data is encrypted and transmitted and received by a central server.
  • a central server In order to send and receive messages between clients without an intermediary called a central server, an encryption function between clients is required.
  • message data is stored in the central server, and the user who created the message data can only view already stored message data, but does not have the authority to delete/edit it. Therefore, there is a problem in which the data creator's private rights to his or her data are infringed.
  • Various embodiments disclosed in this document seek to implement scalable messenger functions that are not dependent on a specific central server based on a decentralized identifier (DID) that can be searched through a public blockchain network.
  • DID decentralized identifier
  • it is intended to provide an electronic device and method that provide a messenger function that allows messages to be sent/received between clients without an intermediary through end-to-end encryption and that allows users to be guaranteed private rights to message data.
  • a client device includes an agency server, a communication interface configured to communicate with a counterpart device, a memory, and at least one processor operably connected to the memory and configured to execute instructions, The at least one processor transmits a topic creation request to the agency server, and when a topic creation notification is received from the agency server, a first subscription DID corresponding to the topic and a pair of first subscription DIDs corresponding to the first subscription DID.
  • the at least one processor transmits a topic creation request to the agency server, and when a topic creation notification is received from the agency server, a first subscription DID corresponding to the topic and a pair of first subscription DIDs corresponding to the first subscription DID.
  • 1 Generate a subscription private key and a first subscription public key, transmit the first subscription DID to the other party device, receive the second subscription DID generated from the other party device from the agency server, and send the first subscription DID to the other party device.
  • a first encryption key may be generated based on the key and the second subscription DID, and message data encrypted with the first
  • a method for providing a messenger service includes the steps of a first client transmitting a topic creation request to an agency server, the agency server responding to the topic creation request, and the agency server Creating a topic in memory, the first client generates a first subscription DID corresponding to the topic, a pair of first subscription private key and first subscription public key corresponding to the first subscription DID, and 2. Transmitting a first subscription DID to a client, wherein the second client receives a second subscription DID corresponding to the topic, a pair of second subscription private keys and a second subscription public key corresponding to the second subscription DID.
  • generating and transmitting a second subscription DID to the agency server the agency server transmitting the second subscription DID to the first client, and the first client receiving the first subscription private key and the second subscription DID.
  • transmitting message data encrypted with a first encryption key generated based on a subscription DID to the agency server transmitting the encrypted message data to the second client by the agency server, and transmitting the encrypted message data to the second client, and the second client transmits the encrypted message data to the second client. It may include decrypting the encrypted message data using the first encryption key generated based on the second subscription private key and the first subscription DID.
  • an end-to-end secret messenger function can be provided through end-to-end encryption in which an intermediary of the messenger function cannot decrypt message data transmitted and received between end-to-ends.
  • FIG. 1 is a diagram illustrating an environment in which a secret messenger function operates according to an embodiment.
  • Figure 2 is a block diagram of a client device according to one embodiment.
  • FIG. 3 is a flowchart of a method by which a client device provides a secret messenger function according to one embodiment.
  • Figure 4 is a signal flow diagram of a method for providing a secret messenger function according to an embodiment.
  • FIG. 5 is a diagram for explaining a storage format of a message sequence according to an embodiment.
  • FIG. 1 is a diagram illustrating an environment in which a secret messenger function operates according to an embodiment.
  • a secret messenger function (hereinafter referred to as a messenger function) may be performed between the first client 100 and the second client 200. It is assumed that the first client 100 is the inviter and creator of the topic, and the second client 200 is the invitee of the topic. However, the second client 200 can also become an inviter and creator of a topic.
  • Agency server A (300) can be understood as a server device operated by an entity (eg, a company) that provides a messenger service capable of running the messenger function.
  • Agency server A (300) may create a first cloud DID agent (310) that can be controlled by the first client (100) in at least one memory.
  • the at least one memory may be understood as a cloud storage space.
  • the first client 100 can access the first cloud DID agent 310 and control the first cloud DID agent 310 in an Internet environment.
  • the first cloud DID agent 310 may be understood as a module that can be controlled only by the first client 100.
  • the first cloud DID agent 310 may correspond to the account DID of the first client 100, and the address (e.g. service end point) of the first cloud DID agent 310 is the DID on the blockchain network 410. It may be stored in the document 410 in correspondence with the account DID.
  • the blockchain network 400 may include at least one blockchain network among known public blockchains.
  • an account DID can be understood as a user ID required to use a messenger function.
  • the DID document 410 of the blockchain network 400 may store information related to the account DID.
  • Agency server A (300) and the second client (200) can search the DID document (410) and information related to the first client (100) based on the account DID.
  • the first client 100 may create an account DID to be used as a user ID.
  • Account DID can be understood as an ID that can be used as an account in the blockchain network 400.
  • the first client 100 may generate a pair of private key/public key (hereinafter referred to as account private key/account public key) corresponding to the account DID.
  • the account public key may be mapped to the account DID and stored in the blockchain network 400.
  • the account private key can be used to create a digital signature of the first client 100 to be used on the messenger service.
  • the account DID and the account public key may be the same.
  • Agency server A (300) and the second client (200) can search the DID document (410) and information related to the first client (100) based on the account DID.
  • the first cloud DID agent 310 may receive a request for creating a topic 315 from the first client 100. When a request for creating a topic 315 is received, the first cloud DID agent 310 may create a topic 315 within the first cloud DID agent 310.
  • the topic 315 can be understood as a messenger space for the first client 100 created in the first cloud DID agent 310 in the cloud space of agency server A (300).
  • the first client 100 may invite other clients who wish to use the messenger function together to the topic 315.
  • the first client 100 invites the second client 200 as a counterpart with whom it wishes to send and receive messages through the messenger function on the topic 315.
  • the first client 100 can create a subscription DID corresponding to the topic 315.
  • Subscription DID can be understood as an ID that can be used as an account in the blockchain network 400.
  • the first client 100 may generate a pair of private key/public key (hereinafter referred to as subscription private key/subscription public key) corresponding to the subscription DID.
  • the first client 100 exchanges the subscription DID with another client. can do.
  • Subscription DID can be understood as a key exchanged to generate an encryption key needed to encrypt message data.
  • the subscription DID and subscription public key may be the same.
  • the first client 100 may transmit a subscription request for the topic 315 to the agency server 300.
  • agency server A (300) may transmit a push notification about an event (new message reception, topic deletion, new subscription application, etc.) that occurred in relation to the topic (315) to the first client (100).
  • the first client 100 can receive notifications about events that occur in the topic 315 even if the messenger service is not online.
  • the first client 100 can invite the second client 200 to the topic 315.
  • the first client 100 may transmit an invitation request to the second client 200, and the invitation request may include the subscription DID and account DID of the first client 100.
  • the second client 200 can query the DID document 410 based on the account DID and obtain the address (e.g. service end point) of the first cloud DID agent 310 stored by matching the account DID. There is (DID resolution). The second client 200 can apply for subscription to the topic 315 based on the address.
  • DID resolution e.g. service end point
  • the second client 200 In order to use the messenger function in the topic 315, the second client 200 generates a subscription DID, a pair of subscription public keys and a subscription private key corresponding to the subscription DID, and sends the subscription DID to the first client. It can be sent to (100).
  • the first client 100 and the second client 200 can generate the same encryption key based on the subscription DID exchanged with each other, and send and receive message data encrypted based on the encryption key.
  • the sequence of message data (hereinafter referred to as message sequence) transmitted and received between the first client 100 and the second client 200 may be stored in the topic 315, the first client 100, and the second client 200. there is.
  • the messenger function may be provided by different agency servers (agency server A (300) and agency server B (600)). Since the messenger function is operated based on account DID, subscription DID, etc. that can be viewed through the public blockchain network 400, any server or client device that can access the blockchain network 400 through the network can provide or use the messenger function. You can. Therefore, the architecture for driving the messenger function according to the embodiment of the present invention has expandability.
  • agency server A (300) and agency server B (600) may be operated by different entities (eg, companies). Accordingly, a plurality of different entities can provide messenger functions and allow users to use them by implementing devices and methods according to embodiments of the present invention.
  • the third client 500 can use the messenger function provided by agency server B (600).
  • the third client 500 may request agency server B 600 to create a third cloud DID agent 610 that the third client 500 can control.
  • the third client 500 can create a topic, invite other clients, and use the messenger function through the third cloud DID agent 610 provided by agency server B (600).
  • Figure 2 is a block diagram of the first client device 100 according to one embodiment. Descriptions of the second client device 200 and third client device 500 are replaced with descriptions of the first client device 100. Additionally, the agency server 300 capable of providing the following messenger service may be understood as agency server A (300) or agency server B (600). In the following embodiment, the agency server 300 operated by one entity (eg, a company) provides a messenger service. However, other agency servers operated by different entities can also provide the same messenger function.
  • agency server 300 capable of providing the following messenger service may be understood as agency server A (300) or agency server B (600).
  • the agency server 300 operated by one entity eg, a company
  • other agency servers operated by different entities can also provide the same messenger function.
  • the first client 100 may be various types of electronic devices.
  • the first client 100 may include, for example, a portable communication device (eg, a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance device.
  • a portable communication device eg, a smartphone
  • a computer device e.g., a laptop, a desktop, a tablet, or a portable multimedia device
  • portable medical device e.g., a portable medical device
  • camera e.g., a portable medical device
  • a camera e.g., a portable medical device
  • a wearable device e.g., a portable medical device
  • a home appliance device e.g., a portable medical device, a portable medical device, a camera, a wearable device, or a home appliance device.
  • the first client 100 may include at least one processor 110, a memory 120, and a communication interface 130. At least one processor 110 may control the overall operation of the first client 100.
  • the processor 110 may be operably connected to the memory 120 and configured to execute instructions (eg, application 122) stored in the memory 120.
  • instructions eg, application 122
  • operations performed by the first client 100 may be understood as being performed by at least one processor 110.
  • the first client 100 can transmit and receive data with the agency server 300 and the second client 200 through the communication interface 130.
  • Memory 120 may store an application 122.
  • the first client 100 can run the messenger function by executing the application 122.
  • Memory 120 may store message sequence 124 .
  • the messenger sequence 124 may include message data generated through a messenger function. Encrypted message data can be stored sequentially in the messenger sequence 124 in the order in which it was created, and as will be described later with reference to FIG. 5, the encrypted message data is included in a message block, and a plurality of message blocks are stored in the form of a blockchain. It can be saved.
  • Memory 120 may store an identifier list 126. As the messenger function runs, the generated account DID, a pair of account private keys and account public keys corresponding to the account DID, a subscription DID, and a pair of subscription private keys and subscription public keys corresponding to the subscription DID are included in the identifier list. It can be stored at (126). In various embodiments, multiple subscription DIDs corresponding to multiple topics may be stored.
  • FIG. 3 is a flowchart of a method by which a client device provides a secret messenger function according to one embodiment.
  • the operations in FIG. 3 may be performed by the first client 100.
  • the second client 200 when the second client 200 becomes an inviter of a messenger, the second client 200 may perform the operations of the first client 100 described throughout the specification.
  • the first client 100 may transmit a request to create a topic 315 to the agency server 300 (3010).
  • the agency server 300 may create a topic 315 in the first cloud DID agent 310 and create a topic ID for the topic 315.
  • the agency server 300 may transmit a topic creation notification to the first client 100.
  • the first client 100 may receive a topic creation notification from the agency server 300 (3020).
  • the topic creation notification may include a topic ID.
  • the first client 100 can access the topic 315 through the address and topic ID of the first cloud DID agent 310.
  • the address of the first cloud DID agent 310 is stored in the DID document 410 in correspondence with the first account DID, so that any third party (second client 200) can access the first cloud DID agent 310. If you know the account DID, you can know the address of the first cloud DID agent 310 through DID resolution.
  • the address of the generated topic 315 is not stored in the DID document 410, and the topic ID is provided only to the first client 100 and the second client 200 participating in the topic 315. Because it is shared, only clients participating in the topic 315 can access the topic. This increases the security of the topic.
  • the first client 100 generates a first subscription DID corresponding to the topic 315 (or topic ID), a pair of first subscription private keys, and a second subscription public key corresponding to the first subscription DID. Can (3030).
  • the first client 100 may transmit the first subscription DID to the second client 200 (eg, the second client 200 in FIG. 1) (3040).
  • the first client 100 may receive the second subscription DID generated by the second client 200 from the agency server 300 (3050).
  • the first client 100 generates a first encryption key based on the first subscription private key and the second subscription DID (3060), and sends message data encrypted with the first encryption key to the agency server 300. Can be transmitted (3070). Specifically, the first client 100 searches the DID document 410 based on the second subscription DID, obtains the second subscription public key, and then uses the first subscription private key and the obtained second subscription public key. You can generate the first encryption key.
  • the first client 100 may transmit the encrypted message data and a digital signature generated based on the first account private key to the agency server 300.
  • the digital signature may indicate that the creator of the encrypted message data is the first client 100.
  • the first client 100 sends a topic deletion request (a request for deletion of a message sequence stored in the topic 315) containing the digital signature generated based on the first account private key to the agency. It can be transmitted to the server 300.
  • the agency server 300 which has received the deletion request, determines whether the digital signature is a legitimate signature generated by the first client 100 based on the first account public key stored in the DID document 410 of the blockchain network 400. You can verify whether or not.
  • the agency server 300 can delete the topic 315 according to the deletion request only when verification of the digital signature is completed.
  • a topic creation request may include the digital signature generated based on the first account private key.
  • the agency server 300 may be configured to verify the digital signature and create a topic according to the topic creation request only when verification is completed.
  • control commands (topic creation, deletion request) for the first cloud DID agent 310 may be forced to include a digital signature based on the first account private key. Through this, only the first client 100 can have control authority over the first cloud DID agent 310.
  • FIG 4 is a signal flow diagram of a method for providing a secret messenger function according to an embodiment.
  • the first client 100 may generate a first account DID to be used in the messenger service, and a pair of account private keys and account public keys corresponding to the first account DID (401).
  • the first account DID can be understood as the account ID in the messenger service of the first client 100 and the user of the first client 100 (hereinafter referred to as first user).
  • the first account DID, account private key, and account public key may be stored in the first client 100 (eg, identifier list 126).
  • the first account private key may be used to create a digital signature of the first client 100.
  • the account DID may be the same as the first account public key.
  • the first client 100 may transmit a request to use a messenger service to the agency server 300 (403).
  • the messenger service use request is a request message required for the first user to use the messenger service through the agency server 300, and includes the first account DID.
  • the agency server 300 assigns the first cloud DID agent 310 (for the first user) corresponding to the first account DID, and the assigned address is sent to the blockchain network 400.
  • the address of the first cloud DID agent 310 may be transmitted to the blockchain network 400 to be recorded in correspondence with the first account DID (405).
  • the first client 100 is authorized to use the messenger service provided by the agency server 300.
  • the first client 100 can create a topic in the first cloud DID agent 310, invite other users to the topic, and use the messenger service with other users.
  • a plurality of topics may be created in the first cloud DID agent 310.
  • the first client 100 may transmit a topic creation request to the agency server 300 (407).
  • the agency server 300 may create a topic 315 (e.g., topic 315 in FIG. 1) in the memory (cloud space) of the agency server 300 (409). .
  • the agency server 300 may transmit a topic creation notification to the first client 100, and the first client 100 may send a first subscription request for the topic to the agency server 300. It can be transmitted (411).
  • the topic creation notification may include a topic ID assigned to the topic 315 created in the first cloud DID agent 310.
  • a client of a messenger service can access a specific topic of the first user through the address and topic ID of the first cloud DID agent 310.
  • Subscription application can be understood as a request to receive notification of an event occurring in the topic 315 of the agency server 300.
  • the agency server 300 may send a push notification to clients who have applied for subscription to a specific topic when an event occurs, such as a new message or a new subscription request.
  • the agency server 300 may transmit a push notification about an event occurring in the topic 315 to the first client 100 in response to the first subscription application.
  • the first client 100 generates a first subscription DID corresponding to the topic 315, a pair of first subscription private key and first subscription public key corresponding to the first subscription DID (413), and 2
  • An invitation request to the topic may be transmitted to the client 200, and the invitation request may include the first subscription DID (415).
  • the first subscription DID may be understood as a key exchanged to generate an encryption key for encrypting message data generated between the first client 100 and the second client 200.
  • the first client 100 may generate a different subscription DID for each topic, and a pair of subscription private keys and subscription public keys corresponding to the subscription DIDs.
  • the subscription DID can be used as a key exchanged to generate an encryption key for the topic.
  • the second client 200 searches the DID document 410 associated with the first client 100 and retrieves the topic created by the first client 100 from the blockchain network 400. You can obtain the address of (315).
  • the invitation request may further include the first account DID and the topic ID of the topic 315.
  • the second client 200 can query the address of the first cloud DID agent 310 stored in correspondence with the first account DID from the blockchain network 400 (417). The second client 200 can access the topic 315 based on the address of the first cloud DID agent 310 and the topic ID.
  • the first client 100 may transmit the invitation request to the second client 200 through an SMS message through the telecommunication company's communication network.
  • the first client 100 may generate the invitation request as a QR code, and the second client 200 may receive the invitation request by scanning the QR code.
  • the first user of the first client 100 sends the first subscription to the second user of the second client 200 offline. You can send an invitation request by passing the DID, first account DID, and topic ID.
  • the second client 200 In response to an invitation request to the topic 315, the second client 200 includes a second subscription DID corresponding to the topic 315, a pair of second subscription private keys corresponding to the second subscription DID, and A second subscription public key may be generated (419).
  • the second client 200 may transmit the second subscription DID to the agency server 300.
  • the second subscription DID can be understood as a key exchanged to generate an encryption key for encrypting message data generated between the first client 100 and the second client 200.
  • the second client 200 may generate a subscription DID corresponding to a specific topic, a pair of subscription private keys, and a subscription public key corresponding to the subscription DID for different topics, respectively.
  • Subscription DID can be used in key exchange to generate encryption keys for specific topics.
  • the second client 200 may transmit the second subscription DID to the agency server 300 (421).
  • the second client 200 may transmit an invitation acceptance message in response to the invitation request to the agency server 300.
  • the invitation acceptance message may include a second subscription DID.
  • the invitation acceptance message may include a second subscription request for the topic 315.
  • the second client 200 may transmit a second subscription request including the address of the topic 315 (address of the first cloud DID agent 310, topic ID) to the agency server 300.
  • the agency server 300 may transmit a push notification about an event occurring in the topic 315 to the second client 200 in response to the second subscription request.
  • the agency server 300 may transmit the second subscription DID to the first client 100 (423).
  • the agency server 300 may transmit an invitation acceptance notification of the second client 200 to the first client 100 .
  • the invitation acceptance notification may include the second subscription DID.
  • the first client 100 and the second client 200 may perform Diffie-Hellman key exchange to generate an encryption key to be used in a symmetric key algorithm.
  • the first client 100 and the second client 200 exchange each other's public keys (first subscription public key, second subscription public key) by exchanging the first subscription DID and the second subscription DID.
  • the first client 100 and the second client 200 can generate an encryption key by exchanging public keys with each other.
  • the first client 100 may generate a first encryption key based on the first subscription private key and the second subscription DID received from the second client 200 (425).
  • the first client 100 may query the DID document 410 based on the second subscription DID and obtain the second subscription public key from it (DID resolution).
  • the first client 100 may generate a first encryption key based on the first subscription private key and the second subscription public key.
  • the second client 200 may generate a first encryption key based on the second subscription private key and the first subscription DID received from the first client 100 (427).
  • the second client 200 may query the DID document 410 based on the first subscription DID and obtain the first subscription public key from it (DID resolution).
  • the second client 200 may generate a first encryption key based on the second subscription private key and the first subscription public key.
  • the first client 100 may transmit message data encrypted with the first encryption key to the agency server 300 (429).
  • the agency server 300 can transmit the encrypted message data to the second client 200 (431), and the second client 200 can decrypt the encrypted message data with the first encryption key (431). 433).
  • the agency server 300 may store the encrypted message in the topic 315.
  • the second client 200 may display the decrypted message through a display (not shown) and store it in the memory (e.g., memory 120 of FIG. 2) of the second client 200. You can.
  • the first encryption key can only be generated by the first client 100 and the second client 200, and the agency server 300 does not know the first encryption key, so the encrypted message stored in the agency server 300 cannot be decrypted by the agency server 300 or any other third party. Therefore, a secret messenger function through end-to-end encryption becomes possible.
  • the first client 100 which is the creator of the topic 315, may have deletion authority for the topic 315.
  • the first client 100 sends a request to delete the topic 315 containing the digital signature (generated by the first account private key) of the first client 100 to the agency server 300.
  • the agency server 300 verifies the digital signature in response to the deletion request and then sends the topic 315 and the message sequence included in the topic 315 stored in the agency server 300. It can be deleted.
  • FIG. 5 is a diagram for explaining a storage format of a message sequence according to an embodiment.
  • the message sequence 500 stored in the agency server 300 may be stored in block chain form as illustrated in FIG. 5.
  • the message block (510, 520, 530) contains the hash value of the previous message block (512, 522, 532), encrypted message data (514, 524, 534), and the electronic signature of the message creator (516, 526, 536). can do.
  • the hash values 512, 522, and 532 of the message block can be understood as hash values calculated for the message block through a predetermined hash function. When there is no previous message block, that is, the previous hash value of the first message block created may be set to 0.
  • the encrypted message data 514, 524, and 534 can be understood as message data encrypted by the first encryption key in FIGS. 3 and 4.
  • the electronic signature 516, 526, 536 of the message creator is an electronic signature generated based on the first account private key of the first client 100 that created the message or the second account private key of the second client 200. It can be understood as an electronic signature created based on The client receiving the message can confirm who the message creator is through the message creator's electronic signature (516, 526, 536).
  • the second client 200 as an invitee, generates a second account DID for using the messenger service, a pair of second account private keys and a second account public key corresponding to the second account DID. can do.
  • the second account public key may be mapped to the second account DID and recorded in the DID document 410, and a digital signature generated based on the second account private key may be verified through the second account public key.
  • the creation and use of the message sequence 500 will be described through the process of the second client 200 receiving the message generated by the first client 100.
  • a process in which the first client 100 creates message block 2 520 and transmits it to the second client 200 will be described.
  • the first client 100 may generate a message block 520 including encrypted message data 524 and a block header 522 with the hash value (0x00075) of the previous message block. And the generated message block 520 can be transmitted to the agency server 300.
  • the agency server 300 may transmit the message block to the second client 200.
  • the message block 520 may further include an electronic signature 526 generated based on the first account private key of the first client 100.
  • the second client 200 determines that the hash value (0x00075) of the previous message block stored in the message block 520 is message block 1 (510), which is the previous message block previously stored in the second client 200. ) can be determined whether it is the same as the hash value (0x00075).
  • the first client 100 and the second client 200 confirm that they have a message block with the same last hash value, thereby including all message data exchanged between the first client 100 and the second client 200. It can be proven that they have exactly the same message sequence. Since the existing messenger brokerage service is not a system that guarantees 100% delivery of messages, but is a best effort system, the immutability and integrity of the message sequence can be guaranteed through this blockchain structure according to an embodiment of the present invention. .
  • the second client ( 200) may transmit a hash value mismatch alarm to the first client 100 through the agency server 300.
  • a hash value mismatch alarm may occur when some messages are omitted by the agency server 300 or when some messages are changed or omitted due to a third party hacking attack. This alarm means that the messaging channel between the first client 100 and the second client 200 is not secure.
  • the topic creator (first client 100) can delete the topic and create a new topic.
  • the first client 100 may delete the first cloud DID agent 310 and create a new cloud DID agent.
  • a request for deletion of an existing cloud DID agent and creation of a new cloud DID agent may include a digital signature generated based on the first account private key and may be transmitted to the agency server 300.
  • the agency server 300 when two message blocks are received simultaneously from the first client 100 and the second client 200, the agency server 300 receives only one of the two message blocks. It is treated as received, and reception of the remaining message block can be rejected. This is because received message blocks must be recorded sequentially in the form of a blockchain.
  • the agency server 300 may transmit a notification requesting retransmission of the message to the creator of the rejected message block.
  • the first client 100 may further invite a third client (eg, the third client 500 in FIG. 1) to use the messenger function in the topic 315.
  • the first client 100 may transmit the first encryption key generated through key exchange with the second client 200 to the third client.
  • the first client 100 and the third client can generate a second encryption key through key exchange in the same manner as described above.
  • the first client 100 may encrypt the first encryption key with a second encryption key and transmit the first encryption key encrypted based on the second encryption key to the third client.
  • the first client 100 transmits message data including the first encryption key encrypted based on the second encryption key to the topic 315, and the third client decrypts the message data to create the first encryption key. You can obtain the key.
  • the first encryption key encrypted based on the second encryption key can be transmitted to the third client using a separate communication method between the first client 100 and the third client.
  • the third client receives the first encryption key
  • the message data can be encrypted based on the first encryption key and transmitted to the topic 315, or the message data transmitted to the topic 315 can be decrypted.
  • first, second, or first or second may be used simply to distinguish one component from another, and to refer to that component in other respects (e.g., importance or order) is not limited.
  • One (e.g., first) component is said to be “coupled” or “connected” to another (e.g., second) component, with or without the terms “functionally” or “communicatively.”
  • any of the components can be connected to the other components directly (e.g. wired), wirelessly, or through a third component.
  • a storage medium e.g., memory 120
  • a machine e.g., first client 100, second client 200
  • the processor e.g., processor 110
  • the device calls at least one command among one or more commands stored from the storage medium, and , you can run it. This allows the device to be operated to perform at least one function according to the at least one instruction called.
  • the one or more instructions may include code generated by a compiler or code that can be executed by an interpreter.
  • a storage medium that can be read by a device may be provided in the form of a non-transitory storage medium.
  • 'non-transitory' only means that the storage medium is a tangible device and does not contain signals (e.g. electromagnetic waves). This term refers to cases where data is stored semi-permanently in the storage medium. There is no distinction between temporary storage cases.
  • Computer program products are commodities and can be traded between sellers and buyers.
  • the computer program product may be distributed in the form of a machine-readable storage medium (e.g. compact disc read only memory (CD-ROM)) or through an application store (e.g. Play StoreTM) or on two user devices (e.g. It can be distributed (e.g. downloaded or uploaded) directly between smartphones) or online.
  • a machine-readable storage medium e.g. compact disc read only memory (CD-ROM)
  • an application store e.g. Play StoreTM
  • two user devices e.g. It can be distributed (e.g. downloaded or uploaded) directly between smartphones) or online.
  • at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.
  • each component (eg, module or program) of the above-described components may include a single entity or a plurality of entities.
  • one or more of the components or operations described above may be omitted, or one or more other components or operations may be added.
  • multiple components eg, modules or programs
  • the integrated component may perform one or more functions of each component of the plurality of components in the same or similar manner as those performed by the corresponding component of the plurality of components prior to the integration. .
  • operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, or omitted. Alternatively, one or more other operations may be added.

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)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

에이전시 서버, 상대방 장치와 통신하도록 설정된 통신 인터페이스, 메모리, 및 상기 메모리와 동작 가능하도록 연결되어 명령어들을 실행하도록 설정된 적어도 하나의 프로세서를 포함하고, 상기 적어도 하나의 프로세서는, 상기 에이전시 서버로 토픽 생성 요청을 전송하고, 상기 에이전시 서버로부터 토픽 생성 알림이 수신되면 상기 토픽에 대응하는 제1 구독 DID, 상기 제1 구독 DID에 대응되는 한 쌍의 제1 구독 개인키 및 제1 구독 공개키를 생성하고, 상기 제1 구독 DID를 상기 상대방 장치로 전송하고, 상기 에이전시 서버로부터 상기 상대방 장치로부터 생성된 제2 구독 DID를 수신하고, 상기 제1 구독 개인키 및 상기 제2 구독 DID를 기초로 제1 암호키를 생성하고, 상기 제1 암호키로 암호화된 메시지 데이터를 상기 에이전시 서버로 전송하도록 설정된 클라이언트 장치가 개시된다. 이 외에도 명세서를 통해 파악되는 다양한 실시 예가 가능하다.

Description

블록체인 DID 기술 기반의 종단 암호화를 통한 비밀 메신저 기능을 제공하는 전자 장치 및 방법
본 문서에서 개시되는 실시 예들은, 암호화 기술 및 온라인 채팅 어플리케이션과 관련된다.
일반적으로 사용되는 대다수의 메신저 서비스의 경우 중앙화 된 서버를 통해서 클라이언트 간의 메시지를 송/수신한다. 중앙 서버가 메시지 송수신 중간자 역할을 하는 경우, 비록 정책적으로 법률적으로 금지되었다 하여도, 중간자는 기술적으로 클라이언트들의 사적 메시지를 저장, 조회할 수 있는 권한을 갖게 된다. 따라서 중간자는 이로부터 다양한 데이터를 수집 및 활용할 수 있고 나아가 상업화 할 수 있는 가능성이 있다. 따라서 클라이언트들의 사적 정보가 침해될 가능성이 있다.
메신저 서비스는 사용자들의 사적인 메시지 데이터를 전송하는 기능을 가지기 때문에, 메시지 데이터는 반드시 암호화 되어야한다. 현재까지 제공되고 있는 메신저 서비스에서는 중앙 서버에 의하여 메시지 데이터가 암호화되고 송수신된다. 중앙 서버라는 중간자 없이 클라이언트간 메시지를 송수신하기 위해서는 클라이언트간 암호화 기능이 필요하다.
또한 중앙 서버에 메시지 데이터들이 저장되고, 그 메시지 데이터를 생성한 사용자는 이미 저장된 메시지 데이터들에 대한 조회만 가능할 뿐, 삭제/수정 권한은 가지지 못한다. 따라서 데이터 생성자가 자신의 데이터에 대한 사적 권한이 침해 받게 되는 문제점이 있다.
본 문서에서 개시되는 다양한 실시 예들은, 퍼블릭 블록체인 네트워크를 통해 조회할 수 있는 분산 식별자(Decentralized Identifier, 이하 DID)에 기초하여 특정 중앙 서버에 종속되지 않는 확장 가능한 메신저 기능을 구현하고자 한다. 또한 종단간 암호화를 통해 중간자 없이 클라이언트 사이에 메시지를 송/수신할 수 있고, 사용자가 메시지 데이터에 대한 사적 권한을 보장받을 수 있는 메신저 기능을 제공하는 전자 장치 및 그 방법을 제공하고자 한다.
본 문서에 개시되는 일 실시 예에 따른 클라이언트 장치는, 에이전시 서버, 상대방 장치와 통신하도록 설정된 통신 인터페이스, 메모리, 및 상기 메모리와 동작 가능하도록 연결되어 명령어들을 실행하도록 설정된 적어도 하나의 프로세서를 포함하고, 상기 적어도 하나의 프로세서는, 상기 에이전시 서버로 토픽 생성 요청을 전송하고, 상기 에이전시 서버로부터 토픽 생성 알림이 수신되면 상기 토픽에 대응하는 제1 구독 DID, 상기 제1 구독 DID에 대응되는 한 쌍의 제1 구독 개인키 및 제1 구독 공개키를 생성하고, 상기 제1 구독 DID를 상기 상대방 장치로 전송하고, 상기 에이전시 서버로부터 상기 상대방 장치로부터 생성된 제2 구독 DID를 수신하고, 상기 제1 구독 개인키 및 상기 제2 구독 DID를 기초로 제1 암호키를 생성하고, 상기 제1 암호키로 암호화된 메시지 데이터를 상기 에이전시 서버로 전송하도록 설정될 수 있다.
또한, 본 문서에 개시되는 일 실시 예에 따른 메신저 서비스 제공을 위한 방법은 제1 클라이언트가 토픽 생성 요청을 에이전시 서버로 전송하는 단계, 상기 에이전시 서버가 상기 토픽 생성 요청에 응답하여, 상기 에이전시 서버의 메모리에 토픽을 생성하는 단계, 상기 제1 클라이언트는 상기 토픽에 대응하는 제1 구독 DID, 상기 제1 구독 DID에 대응되는 한 쌍의 제1 구독 개인키 및 제1 구독 공개키를 생성하고, 제2 클라이언트에 제1 구독 DID 를 전송하는 단계, 상기 제2 클라이언트는 상기 토픽에 대응하는 제2 구독 DID, 상기 제2 구독 DID에 대응되는 한 쌍의 제2 구독 개인키 및 제2 구독 공개키를 생성하고, 상기 에이전시 서버에 제2 구독 DID를 전송하는 단계, 상기 에이전시 서버가 상기 제2 구독 DID를 상기 제1 클라이언트로 전송하는 단계, 상기 제1 클라이언트가 상기 제1 구독 개인키 및 상기 제2 구독 DID를 기초로 생성된 제1 암호키로 암호화된 메시지 데이터를 상기 에이전시 서버로 전송하는 단계, 상기 에이전시 서버가 상기 암호화된 메시지 데이터를 상기 제2 클라이언트로 전송하는 단계, 및 상기 제2 클라이언트가 상기 제2 구독 개인키 및 상기 제1 구독 DID를 기초로 생성된 상기 제1 암호키로 상기 암호화된 메시지 데이터를 복호화하는 단계를 포함할 수 있다.
본 문서에 개시되는 실시 예들에 따르면, 종단간 암호화를 통해 메신저 기능의 중개자가 종단간 송수신된 메시지 데이터를 복호화할 수 없는 종단간의 비밀 메신저 기능을 제공할 수 있다.
또한 클라이언트들 사이에 송수신된 메시지 시퀀스가 모든 클라이언트들에게 동일하게 메시지가 전달되었음을 보장할 수 있다.
이 외에, 본 문서를 통해 직접적 또는 간접적으로 파악되는 다양한 효과들이 제공될 수 있다.
도 1은 일 실시 예에 따른 비밀 메신저 기능이 동작하는 환경을 설명하기 위한 도면이다.
도 2는 일 실시 예에 따른 클라이언트 장치의 블록도이다.
도 3은 일 실시 예에 따라 클라이언트 장치가 비밀 메신저 기능을 제공하는 방법의 순서도이다.
도 4는 일 실시 예에 따른 비밀 메신저 기능을 제공하는 방법에 신호 흐름도이다.
도 5는 일 실시 예에 따른 메시지 시퀀스의 저장 형태에 대해 설명하기 위한 도면이다.
도면의 설명과 관련하여, 동일 또는 유사한 구성요소에 대해서는 동일 또는 유사한 참조 부호가 사용될 수 있다.
이하, 본 발명의 다양한 실시 예가 첨부된 도면을 참조하여 기재된다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 실시 예의 다양한 변경(modification), 균등물(equivalent), 및/또는 대체물(alternative)을 포함하는 것으로 이해되어야 한다.
도 1은 일 실시 예에 따른 비밀 메신저 기능이 동작하는 환경을 설명하기 위한 도면이다. 비밀 메신저 기능(이하, 메신저 기능)은 제1 클라이언트(100) 및 제2 클라이언트(200) 사이에서 수행될 수 있다. 제1 클라이언트(100)는 토픽의 초대자 및 생성자이고, 제2 클라이언트(200)는 토픽의 초대받은 자로 가정한다. 그러나 제2 클라이언트(200)도 토픽의 초대자 및 생성자가 될 수 있다.
에이전시 서버 A(300)는 상기 메신저 기능을 구동할 수 있는 메신저 서비스를 제공하는 주체(예: 기업)에 의하여 운영되는 서버 장치로 이해될 수 있다. 에이전시 서버 A(300)는 적어도 하나의 메모리에 제1 클라이언트(100)가 제어할 수 있는 제1 클라우드 DID 에이전트(310)를 생성할 수 있다. 상기 적어도 하나의 메모리는 클라우드 저장 공간으로 이해될 수 있다. 제1 클라이언트(100)는 인터넷 환경에서 제1 클라우드 DID 에이전트(310)에 접속하고, 제1 클라우드 DID 에이전트(310)를 제어할 수 있다.
제1 클라우드 DID 에이전트(310)는 제1 클라이언트(100)에 의해서만 제어될 수 있는 모듈로 이해될 수 있다. 제1 클라우드 DID 에이전트(310)는 제1 클라이언트(100)의 계정 DID에 대응될 수 있고, 제1 클라우드 DID 에이전트(310)의 주소(예: 서비스 엔드 포인트)는 블록체인 네트워크(410) 상의 DID 도큐먼트(410)에 상기 계정 DID에 대응되어 저장될 수 있다.
다양한 실시 예에서, 블록체인 네트워크(400)는 공지의 퍼블릭 블록체인 중 적어도 하나의 블록체인 네트워크를 포함할 수 있다.
일 실시 예에서, 계정 DID란, 메신저 기능을 사용하기 위하여 필요한 사용자 아이디로 이해될 수 있다. 블록체인 네트워크(400)의 DID 도큐먼트(410)는 상기 계정 DID에 연관된 정보를 저장할 수 있다. 에이전시 서버 A(300), 제2 클라이언트(200)는 상기 계정 DID를 기초로 DID 도큐먼트(410)를 조회하고 제1 클라이언트(100)와 연관된 정보를 조회할 수 있다.
제1 클라이언트(100)는 사용자 아이디로 사용할 계정 DID를 생성할 수 있다. 계정 DID(Account DID)는 블록체인 네트워크(400)의 계정으로 사용될 수 있는 아이디로 이해될 수 있다. 제1 클라이언트(100)는 계정 DID에 대응되는 한 쌍의 개인키/공개키(이하, 계정 개인키/계정 공개키)를 생성할 수 있다. 계정 공개키는 계정 DID에 맵핑되어 블록체인 네트워크(400)에 저장될 수 있다. 상기 계정 개인키는 메신저 서비스 상에서 사용될 제1 클라이언트(100)의 디지털 서명을 생성하는데 이용될 수 있다. 다양한 실시 예에서, 계정 DID와 계정 공개키는 동일할 수 있다.
에이전시 서버 A(300), 제2 클라이언트(200)는 계정 DID를 기초로 DID 도큐먼트(410)를 조회하고 제1 클라이언트(100)와 연관된 정보를 조회할 수 있다.
제1 클라우드 DID 에이전트(310)는 제1 클라이언트(100)로부터 토픽(315) 생성 요청을 수신할 수 있다. 제1 클라우드 DID 에이전트(310)는 토픽(315) 생성 요청이 수신되면, 제1 클라우드 DID 에이전트(310) 내에 토픽(315)을 생성할 수 있다.
토픽(315)이란, 에이전시 서버 A(300)의 클라우드 공간 내의 제1 클라우드 DID 에이전트(310) 내에 생성되는 제1 클라이언트(100)를 위한 메신저 공간으로 이해될 수 있다. 제1 클라이언트(100)는 메신저 기능을 함께 사용하고자 하는 다른 클라이언트를 토픽(315)으로 초대할 수 있다. 예를 들어, 제1 클라이언트(100)는 제2 클라이언트(200)를 토픽(315) 상의 메신저 기능을 통해 메시지를 송수신하고자 하는 상대방으로 초대한 예시가 도시되었다.
토픽(315)이 생성되면, 제1 클라이언트(100)는 상기 토픽(315)에 대응되는 구독 DID를 생성할 수 있다. 구독 DID(Subscription DID)는 블록체인 네트워크(400)의 계정으로 사용될 수 있는 아이디로 이해될 수 있다. 제1 클라이언트(100)는 구독 DID에 대응되는 한 쌍의 개인키/공개키(이하, 구독 개인키/구독 공개키)를 생성할 수 있다 제1 클라이언트(100)는 구독 DID를 다른 클라이언트와 교환할 수 있다. 구독 DID란, 메시지 데이터를 암호화하기 위하여 필요한 암호키를 생성하기 위하여 교환되는 키로 이해될 수 있다. 다양한 실시 예에서, 구독 DID와 구독 공개키는 동일할 수 있다.
제1 클라이언트(100)는 토픽(315)에 대한 구독 신청을 에이전시 서버(300)에 전송할 수 있다. 구독 신청이 되면, 에이전시 서버 A(300)는 상기 토픽(315)과 관련하여 발생한 이벤트(신규 메시지 수신, 토픽 삭제, 신규 구독 신청 등)에 대한 푸시 노티를 제1 클라이언트(100)에 전송할 수 있다. 구독 신청을 통해, 메신저 서비스에 온라인 상태가 아니더라도, 제1 클라이언트(100)는 토픽(315)에 발생한 이벤트에 대한 알림을 수신할 수 있다.
토픽(315) 생성이 완료되면, 제1 클라이언트(100)는 토픽(315)에 제2 클라이언트(200)를 초대할 수 있다. 제1 클라이언트(100)는 제2 클라이언트(200)에 초대 요청을 전송할 수 있고, 상기 초대 요청은 제1 클라이언트(100)의 구독 DID와 계정 DID를 포함할 수 있다.
제2 클라이언트(200)는 상기 계정 DID를 기초로 DID 도큐먼트(410)를 조회하고, 상기 계정 DID에 매칭되어 저장된 제1 클라우드 DID 에이전트(310)의 주소(예: 서비스 엔드 포인트)를 획득할 수 있다(DID resolution). 제2 클라이언트(200)는 상기 주소를 기초로 토픽(315)에 대한 구독 신청을 할 수 있다.
제2 클라이언트(200)는 토픽(315)에서의 메신저 기능을 사용하기 위하여 구독 DID, 상기 구독 DID에 대응되는 한 쌍의 구독 공개키, 구독 개인키를 생성하고, 그 중 구독 DID를 제1 클라이언트(100)에 전송할 수 있다. 제1 클라이언트(100) 및 제2 클라이언트(200)는 서로 교환한 구독 DID를 기초로 동일한 암호화 키를 생성할 수 있고, 상기 암호화키를 기초로 암호화한 메시지 데이터를 송, 수신 하게 된다. 제1 클라이언트(100) 및 제2 클라이언트(200) 사이에 송수신된 메시지 데이터의 시퀀스(이하, 메시지 시퀀스)는 토픽(315), 제1 클라이언트(100) 및 제2 클라이언트(200)에 저장될 수 있다.
다양한 실시 예에서, 메신저 기능은 서로 다른 에이전시 서버(에이전시 서버 A(300) 및 에이전시 서버 B(600))에 의하여 제공될 수 있다. 메신저 기능은 퍼블릭 블록체인 네트워크(400)를 통해 조회 가능한 계정 DID, 구독 DID등을 기초로 구동되기 때문에, 네트워크를 통해 블록체인 네트워크(400)에 접속가능한 서버, 클라이언트 장치라면 메신저 기능을 제공 또는 이용할 수 있다. 따라서 본 발명의 실시 예에 따른 메신저 기능을 구동하기 위한 아키텍쳐는 확장성을 가진다. 예를 들어, 에이전시 서버 A(300) 및 에이전시 서버 B(600)는 서로 다른 주체(예: 기업)에 의하여 운영될 수 있다. 따라서 서로 다른 복수 개의 주체가 본 발명의 실시 예에 따른 장치 및 방법을 구현함으로써 메신저 기능을 제공하고, 사용자로 하여금 이용하게 할 수 있다.
예를 들어, 제3 클라이언트(500)는 에이전시 서버 B(600)에 의하여 제공되는 메신저 기능을 이용할 수 있다. 제3 클라이언트(500)는 에이전시 서버 B(600)에 제3 클라이언트(500)가 제어할 수 있는 제3 클라우드 DID 에이전트(610) 생성을 요청할 수 있다. 제3 클라이언트(500)는 에이전시 서버 B(600)에 의하여 제공되는 제3 클라우드 DID 에이전트(610)를 통해 토픽을 생성하고, 다른 클라이언트를 초대하고, 메신저 기능을 이용할 수 있다.
도 2는 일 실시 예에 따른 제1 클라이언트 장치(100)의 블록도이다. 제2 클라이언트 장치(200) 및 제3 클라이언트 장치(500)에 대한 설명은 제1 클라이언트 장치(100)에 대한 설명으로 갈음한다. 또한 이하 메신저 서비스를 제공할 수 에이전시 서버(300)는 에이전시 서버 A(300) 또는 에이전시 서버 B(600)로 이해될 수 있다. 이하 실시 예에서는 한 개의 주체(예: 기업)에 의하여 운영되는 에이전시 서버(300)가 메신저 서비스를 제공한다. 그러나 다른 주체에 의하여 운영되는 다른 에이전시 서버도 동일한 메신저 기능을 제공할 수 있다.
본 문서에 개시된 다양한 실시예들에 따른 제1 클라이언트(100)는 다양한 형태의 전자 장치가 될 수 있다. 제1 클라이언트(100)는 예를 들면, 휴대용 통신 장치(예: 스마트폰), 컴퓨터 장치, 휴대용 멀티미디어 장치, 휴대용 의료 기기, 카메라, 웨어러블 장치, 또는 가전 장치를 포함할 수 있다. 본 문서의 실시예에 따른 전자 장치는 전술한 기기들에 한정되지 않는다.
일 실시 예에서, 제1 클라이언트(100)는 적어도 하나의 프로세서(110), 메모리(120), 통신 인터페이스(130)를 포함할 수 있다. 적어도 하나의 프로세서(110)는 제1 클라이언트(100)의 동작 전반을 제어할 수 있다. 프로세서(110)는 메모리(120)와 동작 가능하도록 연결되어 메모리(120)에 저장된 명령어들(예: 어플리케이션(122))을 실행하도록 설정될 수 있다. 이하 제1 클라이언트(100)에 의하여 수행되는 동작은 적어도 하나의 프로세서(110)에 의하여 수행되는 것으로 이해될 수 있다.
제1 클라이언트(100)는 통신 인터페이스(130)를 통하여 에이전시 서버(300) 및 제2 클라이언트(200)와 데이터를 송수신할 수 있다.
메모리(120)는 어플리케이션(122)을 저장할 수 있다. 제1 클라이언트(100)는 어플리케이션(122)을 실행함으로써 메신저 기능을 구동 시킬 수 있다. 메모리(120)는 메시지 시퀀스(124)를 저장할 수 있다. 메신저 시퀀스(124)는 메신저 기능을 통해 생성된 메시지 데이터를 포함할 수 있다. 메신저 시퀀스(124)에 암호화된 메시지 데이터가 생성된 순서대로 순차적으로 저장될 수 있고, 도 5를 통해 후술할 바와 같이 암호화된 메시지 데이터는 메시지 블록에 포함되고, 복수의 메시지 블록들이 블록체인 형태로 저장될 수 있다.
메모리(120)는 식별자 목록(126)을 저장할 수 있다. 메신저 기능이 구동되면서, 생성되는 계정 DID, 상기 계정 DID에 대응되는 한 쌍의 계정 개인키 및 계정 공개키, 구독 DID, 상기 구독 DID에 대응되는 한 쌍의 구독 개인키 및 구독 공개키가 식별자 목록(126)에 저장될 수 있다. 다양한 실시 예에서, 복수 개의 토픽에 대응되는 복수의 구독 DID들이 저장될 수 있다.
도 3은 일 실시 예에 따라 클라이언트 장치가 비밀 메신저 기능을 제공하는 방법의 순서도이다. 도 3의 동작들은 제1 클라이언트(100)에 의하여 수행될 수 있다. 다양한 실시 예에서, 제2 클라이언트(200)가 메신저의 초대자가 되는 경우, 제2 클라이언트(200)는 명세서 전반에 기재된 제1 클라이언트(100)의 동작들을 수행할 수 있다.
제1 클라이언트(100)는 에이전시 서버(300)로 토픽(315) 생성요청을 전송할 수 있다(3010). 에이전시 서버(300)는 상기 토픽 생성요청에 응답하여, 제1 클라우드 DID 에이전트(310) 내에 토픽(315)을 생성하고, 토픽(315)에 대한 토픽 아이디를 생성할 수 있다. 에이전시 서버(300)는 토픽 생성 알림을 제1 클라이언트(100)로 전송할 수 있다.
제1 클라이언트(100)는 상기 에이전시 서버(300)로부터 토픽 생성 알림을 수신할 수 있다(3020). 토픽 생성 알림은 토픽 아이디를 포함할 수 있다. 제1 클라이언트(100)는 제1 클라우드 DID 에이전트(310)의 주소와 토픽 아이디를 통해 상기 토픽(315)에 접근할 수 있다.
본 발명의 실시 예에서, 제1 클라우드 DID 에이전트(310)의 주소는 제1 계정 DID에 대응되어 DID 도큐먼트(410)에 저장되기 때문에 임의의 제3 자(제2 클라이언트(200))가 제1 계정 DID를 알면, DID 레졸루션(DID resolution)을 통해 제1 클라우드 DID 에이전트(310)의 주소를 알 수 있게 된다.
본 발명의 실시 예에서, 생성된 토픽(315)의 주소는 DID 도큐먼트(410)에 저장되지 않고, 토픽(315)에 참여하는 제1 클라이언트(100) 및 제2 클라이언트(200)에게만 토픽 아이디가 공유되므로, 토픽(315)에 참여하는 클라이언트만이 토픽에 접근이 가능하게 된다. 이를 통해 토픽에 대한 보안성이 높아지게 된다.
제1 클라이언트(100)는 상기 토픽(315)(또는 토픽 아이디)에 대응하는 제1 구독 DID, 상기 제1 구독 DID에 대응되는 한 쌍의 제1 구독 개인키, 제2 구독 공개키를 생성할 수 있다(3030). 제1 클라이언트(100) 제1 구독 DID를 상기 제2 클라이언트(200)(예: 도 1의 제2 클라이언트(200))로 전송할 수 있다(3040).
제1 클라이언트(100)는 상기 에이전시 서버(300)로부터 상기 제2 클라이언트(200)로부터 생성된 제2 구독 DID를 수신할 수 있다(3050).
제1 클라이언트(100)는 상기 제1 구독 개인키 및 상기 제2 구독 DID를 기초로 제1 암호키를 생성하고(3060), 상기 제1 암호키로 암호화된 메시지 데이터를 상기 에이전시 서버(300)로 전송할 수 있다(3070). 구체적으로 제1 클라이언트(100)는 제2 구독 DID를 기초로 DID 도큐먼트(410)를 조회하고 제2 구독 공개키를 획득한 후에, 제1 구독 개인키 및 상기 획득한 제2 구독 공개키를 기초로 제1 암호키를 생성할 수 있다.
다양한 실시 예에 따른 동작 3070에서, 제1 클라이언트(100)는 상기 암호화된 메시지 데이터 및 상기 제1 계정 개인키를 기초로 생성한 디지털 서명을 상기 에이전시 서버(300)로 전송할 수 있다. 상기 디지털 서명을 통해 상기 암호화된 메시지 데이터의 생성자가 제1 클라이언트(100)임을 나타낼 수 있다.
다양한 실시 예에서, 제1 클라이언트(100)는 상기 제1 계정 개인키를 기초로 생성한 상기 디지털 서명을 포함하는 상기 토픽 삭제 요청(토픽(315)에 저장된 메시지 시퀀스에 대한 삭제 요청)을 상기 에이전시 서버(300)로 전송할 수 있다. 삭제 요청을 수신한 에이전시 서버(300)는 블록체인 네트워크(400)의 DID 도큐먼트(410)에 저장된 제1 계정 공개키를 기초로 상기 디지털 서명이 정당한 제1 클라이언트(100)에 의하여 생성된 서명인지 여부를 검증할 수 있다. 에이전시 서버(300)는 상기 디지털 서명에 대한 검증이 완료된 경우에만, 상기 삭제 요청에 따른 토픽(315)에 대한 삭제를 수행할 수 있다.
다양한 실시 예에 따른 동작 3010에서, 토픽 생성 요청은 상기 제1 계정 개인키를 기초로 생성한 상기 디지털 서명을 포함할 수 있다. 에이전시 서버(300)는 상기 디지털 서명을 검증하고, 검증이 완료된 경우에만, 상기 토픽 생성 요청에 따라서 토픽을 생성하도록 설정될 수 있다.
다양한 실시 예에서, 제1 클라우드 DID 에이전트(310)에 대한 제어 명령(토픽 생성, 삭제 요청)은 제1 계정 개인키에 기초한 디지털 서명을 포함하도록 강제될 수 있다. 이를 통해, 오직 제1 클라이언트(100) 만이 제1 클라우드 DID 에이전트(310)에 대한 제어 권한을 가질 수 있다.
도 4는 일 실시 예에 따른 비밀 메신저 기능을 제공하는 방법에 신호 흐름도이다. 제1 클라이언트(100)는 메신저 서비스에서 사용할 제1 계정 DID, 상기 제1 계정 DID에 대응되는 한 쌍의 계정 개인키 및 계정 공개키를 생성할 수 있다(401). 제1 계정 DID는 제1 클라이언트(100) 및 제1 클라이언트(100)의 사용자(이하, 제1 사용자)의 메신저 서비스에서의 계정 아이디로 이해될 수 있다. 제1 계정 DID, 계정 개인키, 계정 공개키는 제1 클라이언트(100)(예: 식별자 목록(126))에 저장될 수 있다. 다양한 실시 예에서 제1 계정 개인키는 제1 클라이언트(100)의 디지털 서명을 생성할 때 사용될 수 있다. 다양한 실시 예에서, 계정 DID는 제1 계정 공개키와 동일할 수 있다.
제1 클라이언트(100)는 에이전시 서버(300)로 메신저 서비스 사용 요청을 전송할 수 있다(403). 메신저 서비스 사용 요청은 에이전시 서버(300)를 통해 제1 사용자가 메신저 서비스를 이용하기 위하여 필요한 요청 메시지로서, 제1 계정 DID를 포함한다.
메신저 서비스 사용 요청이 전송되면, 에이전시 서버(300)는 제1 계정 DID에 대응되는(제1 사용자에 대한) 제1 클라우드 DID 에이전트(310)를 할당하고, 할당한 주소가 블록체인 네트워크(400)에 제1 계정 DID에 대응되어 기록되도록 블록체인 네트워크(400)에 제1 클라우드 DID 에이전트(310)의 주소를 전송할 수 있다(405). 동작 401 내지 405를 통해 제1 클라이언트(100)는 에이전시 서버(300)에 의하여 제공되는 메신저 서비스를 사용할 권한을 갖게 된다.
제1 클라이언트(100)는 제1 클라우드 DID 에이전트(310)에 토픽을 생성할 수 있고, 토픽에 다른 사용자를 초대하고, 다른 사용자와 메신저 서비스를 사용할 수 있다. 제1 클라우드 DID 에이전트(310)에는 복수 개의 토픽들이 생성될 수 있다.
제1 클라이언트(100)는 토픽 생성 요청을 에이전시 서버(300)로 전송할 수 있다(407). 에이전시 서버(300)는 상기 토픽 생성 요청에 응답하여, 상기 에이전시 서버(300)의 메모리(클라우드 공간)에 토픽(315)(예: 도 1의 토픽(315))을 생성할 수 있다(409).
토픽(315)이 생성되면, 에이전시 서버(300)는 토픽 생성 알림을 제1 클라이언트(100)로 전송할 수 있고, 제1 클라이언트(100)는 상기 토픽에 대한 제1 구독 신청을 에이전시 서버(300)로 전송할 수 있다(411).
토픽 생성 알림은 제1 클라우드 DID 에이전트(310) 내에 생성된 상기 토픽(315)에 할당된 토픽 아이디를 포함할 수 있다. 예를 들어, 메신저 서비스의 클라이언트는 제1 클라우드 DID 에이전트(310)의 주소와 토픽 아이디를 통해, 제1 사용자의 특정 토픽에 접근할 수 있다.
구독 신청이란, 에이전시 서버(300)의 상기 토픽(315)에서 발생하는 이벤트에 대한 알림을 받기 위한 요청으로 이해될 수 있다. 에이전시 서버(300)는 특정 토픽에 구독 신청을 한 클라이언트들에게, 신규 메시지가 수신되거나 새로운 구독 신청이 수신되는 등의 이벤트가 발생하는 경우, 이에 대한 푸시 노티를 발송할 수 있다.
에이전시 서버(300)가 상기 제1 구독 신청에 응답하여 상기 토픽(315)에서 발생하는 이벤트에 대한 푸시 노티를 상기 제1 클라이언트(100)로 전송할 수 있다.
제1 클라이언트(100)는 상기 토픽(315)에 대응하는 제1 구독 DID, 상기 제1 구독 DID에 대응되는 한 쌍의 제1 구독 개인키 및 제1 구독 공개키를 생성하고(413), 제2 클라이언트(200)에 상기 토픽에의 초대 요청을 전송할 수 있고, 상기 초대 요청은 제1 구독 DID를 포함할 수 있다(415).
동작 415에서, 제1 구독 DID는 제1 클라이언트(100)와 제2 클라이언트(200) 사이에 생성되는 메시지 데이터를 암호화하기 위한 암호키를 생성하기 위하여 교환되는 키로 이해될 수 있다.
다양한 실시 예에서, 제1 클라이언트(100)는 토픽마다 서로 다른 구독 DID, 상기 구독 DID에 대응되는 한 쌍의 구독 개인키 및 구독 공개키를 생성할 수 있다. 구독 DID는 상기 토픽에 대한 암호키를 생성하기 위하여 교환되는 키로 사용될 수 있다.
제2 클라이언트(200)는 상기 초대 요청을 수신하면, 제1 클라이언트(100)와 연관된 DID 도큐먼트(410)를 조회하고, 블록체인 네트워크(400)로부터 상기 제1 클라이언트(100)가 생성한 상기 토픽(315)의 주소를 획득할 수 있다. 예를 들어 동작 415에서, 상기 초대 요청은 제1 계정 DID, 토픽(315)의 토픽 아이디를 더 포함할 수 있다. 제2 클라이언트(200)는 상기 제1 계정 DID에 기초하여, 블록체인 네트워크(400)로부터 제1 계정 DID 에 대응되어 저장된 제1 클라우드 DID 에이전트(310)의 주소를 조회할 수 있다(417). 제2 클라이언트(200)는 제1 클라우드 DID 에이전트(310)의 주소 및 상기 토픽 아이디에 기초하여 상기 토픽(315)에 접근할 수 있다.
다양한 실시 예에 따른 동작 415에서, 제1 클라이언트(100)는 제2 클라이언트(200)에 통신사의 통신망을 통한 SMS 메시지를 통해 상기 초대 요청을 전달할 수 있다. 또는 제1 클라이언트(100)가 상기 초대 요청을 QR 코드로 생성하고, 제2 클라이언트(200)가 상기 QR 코드를 스캔함으로써 상기 초대 요청을 전달받을 수 있다. 또는 제1 클라이언트(100)와 제2 클라이언트(200) 간의 통신을 통해 전달되지 않더라도, 제1 클라이언트(100)의 제1 사용자가 오프라인에서 제2 클라이언트(200)의 제2 사용자에게 상기 제1 구독 DID, 제1 계정 DID 및 토픽 아이디를 전달함으로써 초대 요청을 전달할 수 있다
상기 토픽(315)으로의 초대 요청에 응답하여, 제2 클라이언트(200)는 상기 토픽(315)에 대응하는 제2 구독 DID, 상기 제2 구독 DID에 대응되는 한 쌍의 제2 구독 개인키 및 제2 구독 공개키를 생성할 수 있다(419). 제2 클라이언트(200)는 제2 구독 DID를 에이전시 서버(300)에 전송할 수 있다. 제2 구독 DID는 제1 클라이언트(100)와 제2 클라이언트(200) 사이에 생성되는 메시지 데이터를 암호화하기 위한 암호키를 생성하기 위하여 교환되는 키로 이해될 수 있다.
다양한 실시 예에서, 제2 클라이언트(200)는 서로 다른 토픽에 대하여 특정 토픽에 대응하는 구독 DID, 상기 구독 DID에 대응되는 한 쌍의 구독 개인키 및 구독 공개키를 각각 생성할 수 있다. 구독 DID는 특정 토픽에 대한 암호키를 생성하기 위한 키 교환에 사용될 수 있다.
제2 클라이언트(200)는 상기 제2 구독 DID를 상기 에이전시 서버(300)에 전송할 수 있다(421). 예를 들어, 제2 클라이언트(200)는 상기 초대 요청에 대한 초대 승락 메시지를 에이전시 서버(300)에 전송할 수 있다. 상기 초대 승락 메시지는 제2 구독 DID를 포함할 수 있다.
다양한 실시 예에서 초대 승락 메시지는 상기 토픽(315)에 대한 제2 구독 신청을 포함할 수 있다. 제2 클라이언트(200)가 상기 토픽(315)의 주소(제1 클라우드 DID 에이전트(310) 주소, 토픽 아이디)를 포함하는 제2 구독 신청을 상기 에이전시 서버(300)로 전송할 수 있다. 상기 에이전시 서버(300)는 상기 제2 구독 신청에 응답하여 상기 토픽(315)에서 발생하는 이벤트에 대한 푸시 노티를 상기 제2 클라이언트(200)로 전송할 수 있다.
에이전시 서버(300)는 제2 구독 DID를 상기 제1 클라이언트(100)로 전송할 수 있다(423). 에이전시 서버(300)는 제2 클라이언트(200)의 초대 승락 알림을 제1 클라이언트(100)로 전송할 수 있다. 예를 들어, 초대 승락 알림은 제2 구독 DID를 포함할 수 있다.
제1 클라이언트(100)와 제2 클라이언트(200)는 대칭키 알고리즘에 사용할 암호키를 생성하기 위하여 디피-헬먼 키 교환(Diffie-Hellman key exchange)을 수행할 수 있다. 제1 클라이언트(100)와 제2 클라이언트(200)는 제1 구독 DID 및 제2 구독 DID을 교환함으로써 서로의 공개키(제1 구독 공개키, 제2 구독 공개키)를 교환하게 된다. 제1 클라이언트(100)와 제2 클라이언트(200)는 서로 공개 키를 교환함으로써 암호키를 생성할 수 있게 된다.
제1 클라이언트(100)는 제1 구독 개인키 및 제2 클라이언트(200)로부터 수신된 제2 구독 DID를 기초로 제1 암호키를 생성할 수 있다(425). 제1 클라이언트(100)는 제2 구독 DID를 기초로 DID 도큐먼트(410)를 조회하고, 그로부터 제2 구독 공개키를 획득할 수 있다(DID resolution). 제1 클라이언트(100)는 제1 구독 개인키 및 제2 구독 공캐키를 기초로 제1 암호키를 생성할 수 있다.
제2 클라이언트(200)는 제2 구독 개인키, 및 제1 클라이언트(100)로부터 수신된 제1 구독 DID를 기초로 제1 암호키를 생성할 수 있다(427). 제2 클라이언트(200)는 제1 구독 DID를 기초로 DID 도큐먼트(410)를 조회하고, 그로부터 제1 구독 공개키를 획득할 수 있다(DID resolution). 제2 클라이언트(200)는 제2 구독 개인키 및 제1 구독 공캐키를 기초로 제1 암호키를 생성할 수 있다.
제1 클라이언트(100)는 제1 암호키로 암호화된 메시지 데이터를 상기 에이전시 서버(300)로 전송할 수 있다(429). 에이전시 서버(300)는 상기 암호화된 메시지 데이터를 상기 제2 클라이언트(200)로 전송할 수 있고(431), 제2 클라이언트(200)는 상기 제1 암호키로 상기 암호화된 메시지 데이터를 복호화할 수 있다(433).
동작 429에서, 에이전시 서버(300)는 상기 암호화된 메시지를 상기 토픽(315)에 저장할 수 있다. 동작 433에서, 제2 클라이언트(200)는 상기 복호화된 메시지를 디스플레이(미도시)를 통해 표시할 수 있고, 상기 제2 클라이언트(200)의 메모리(예: 도 2의 메모리(120))에 저장할 수 있다. 제1 암호키는 제1 클라이언트(100) 및 제2 클라이언트(200)에 의해서만 생성될 수 있고, 에이전시 서버(300)는 제1 암호키를 알 수 없기 때문에 에이전시 서버(300)에 저장된 암호화된 메시지는 에이전시 서버(300)나 기타 제3자에 의하여 복호화될 수 없다. 그러므로 종단간 암호화를 통한 비밀 메신저 기능이 가능해진다.
다양한 실시 예에서, 토픽(315)의 생성자인 제1 클라이언트(100)가 토픽(315)에 대한 삭제 권한을 가질 수 있다. 예를 들어, 제1 클라이언트(100)는 상기 제1 클라이언트(100)의 디지털 서명(제1 계정 개인키에 의하여 생성된)을 포함하는 상기 토픽(315)에 대한 삭제 요청을 상기 에이전시 서버(300)로 전송하면, 상기 에이전시 서버(300)가 상기 삭제 요청에 응답하여 상기 디지털 서명을 검증한 후에 상기 에이전시 서버(300)에 저장된 상기 토픽(315) 및 상기 토픽(315)에 포함된 메시지 시퀀스를 삭제할 수 있다.
도 5는 일 실시 예에 따른 메시지 시퀀스의 저장 형태에 대해 설명하기 위한 도면이다. 다양한 실시 예에서, 에이전시 서버(300)에 저장되는 메시지 시퀀스(500)는 도 5에 예시된 바와 같이 블록 체인 형태로 저장될 수 있다.
메시지 블록(510, 520, 530)은 이전 메시지 블록의 해시 값(512, 522, 532), 암호화된 메시지 데이터(514, 524, 534), 메시지 생성자의 전자 서명(516, 526, 536)을 포함할 수 있다.
메시지 블록의 해시 값(512, 522, 532)은 소정의 해시 함수를 통해 메시지 블록에 대하여 연산된 해시 값으로 이해될 수 있다. 이전 메시지 블록이 없을 때, 즉 최초로 생성되는 메시지 블록의 이전 해시 값은 0으로 설정될 수 있다.
암호화된 메시지 데이터(514, 524, 534)는 도 3, 도 4에서 제1 암호키에 의하여 암호화된 메시지 데이터로 이해될 수 있다.
메시지 생성자의 전자 서명(516, 526, 536)은 메시지를 생성한 제1 클라이언트(100)의 제1 계정 개인키에 기초하여 생성된 전자 서명 또는 제2 클라이언트(200)의 제2 계정 개인키에 기초하여 생성된 전자 서명으로 이해될 수 있다. 메시지를 수신한 클라이언트는 상기 메시지 생성자의 전자 서명(516, 526, 536)을 통해 메시지 생성자가 누구인지를 확인할 수 있다.
다양한 실시 예에서 제2 클라이언트(200)는 초대받은 자로서 메신저 서비스를 이용하기 위한 제2 계정 DID, 상기 제2 계정 DID에 대응되는 한 쌍의 제2 계정 개인키 및 제2 계정 공개키를 생성할 수 있다. 제2 계정 공개키는 제2 계정 DID에 맵핑되어 DID 도큐먼트(410)에 기록될 수 있고, 제2 계정 개인키에 기초하여 생성된 디지털 서명이 상기 제2 계정 공개키를 통해 검증될 수 있다.
상술한 도 3, 도 4를 참조하여 제1 클라이언트(100)가 생성한 메시지를 제2 클라이언트(200)가 수신하는 과정을 통해 메시지 시퀀스(500)의 생성 및 활용을 설명한다. 예를 들어, 제1 클라이언트(100)가 메시지 블록 2(520)을 생성하고 제2 클라이언트(200)로 전송하는 과정을 설명한다.
상술한 도 3의 동작 3070에서 제1 클라이언트(100)는 암호화된 메시지 데이터(524), 이전 메시지 블록의 해시 값(0x00075)을 블록 헤더(522)를 포함하는 메시지 블록(520)을 생성할 수 있고, 생성된 메시지 블록(520)을 에이전시 서버(300)로 전송할 수 있다. 에이전시 서버(300)가 상기 메시지 블록을 상기 제2 클라이언트(200)로 전송할 수 있다. 메시지 블록(520)은 제1 클라이언트(100)의 제1 계정 개인키에 기초하여 생성된 전자 서명(526)을 더 포함할 수 있다.
일 실시 예에서, 제2 클라이언트(200)는 상기 메시지 블록(520)에 저장된 상기 이전 메시지 블록의 해시 값(0x00075)이 상기 제2 클라이언트(200)에 기 저장된 이전 메시지 블록인 메시지 블록 1(510)의 해시 값(0x00075)과 동일한지 여부를 판단할 수 있다.
제1 클라이언트(100) 및 제2 클라이언트(200)는 마지막 해시 값이 동일한 메시지 블록을 가지고 있다는 것을 확인함으로써, 제1 클라이언트(100) 및 제2 클라이언트(200)가 서로 주고 받았던 메시지 데이터를 모두 포함하는 완전히 동일한 메시지 시퀀스를 가지고 있다는 것을 증명할 수 있다. 기존의 메신저 중개 서비스는 메시지가 100% 전달되는 것을 보장하는 시스템은 아니고 베스트 에포트 시스템이기 때문에, 본 발명의 일 실시 예에 따른 이러한 블록체인 구조를 통해 메시지 시퀀스의 불변성과 무결성이 보장될 수 있다.
만약 메시지 블록 2(520)에 저장된 상기 이전 메시지 블록의 해시 값(0x00075)이 상기 제2 클라이언트(200)에 기 저장된 이전 메시지 블록(510)의 해시 값과 동일하지 않은 경우, 상기 제2 클라이언트(200)가 상기 에이전시 서버(300)를 통해 해시 값 불일치 알람을 상기 제1 클라이언트(100)로 전송할 수 있다.
다양한 실시 예에서, 에이전시 서버(300)에 의하여 일부 메시지가 누락되거나, 제3 자의 해킹 등의 공격으로 인하여 일부 메시지가 변경되거나 누락된 경우에 해시 값 불일치 알람이 발생할 수 있다. 이러한 알람은 제1 클라이언트(100)와 제2 클라이언트(200) 사이의 메시징 채널이 안전하지 않음을 의미한다. 이 경우 토픽 생성자(제1 클라이언트(100))는 해당 토픽을 삭제하고 새로운 토픽을 생성할 수 있다. 또는 제1 클라이언트(100)는 제1 클라우드 DID 에이전트(310)를 삭제하고, 새로운 클라우드 DID 에이전트에 대한 생성할 수 있다. 기존 클라우드 DID 에이전트의 삭제 및 신규 클라우드 DID 에이전트에 대한 생성 요청은 제1 계정 개인키에 기초하여 생성된 디지털 서명을 포함할 수 있고, 에이전시 서버(300)에 전송될 수 있다.
다양한 실시 예에서, 에이전시 서버(300)는 제1 클라이언트(100) 및 제2 클라이언트(200)로부터 동시에 2개의 메시지 블록이 수신된 경우에는 에이전시 서버(300)는 2개 중 하나의 메시지 블록만을 수신된 것으로 처리하고, 나머지 하나의 메시지 블록은 수신을 거절(reject)할 수 있다. 수신된 메시지 블록들을 순차적으로 블록체인의 형태로 기록해야 하기 때문이다. 에이전시 서버(300)는 거절된 메시지 블록의 생성자에게 메시지 재전송을 요청하는 알림을 전송할 수 있다.
다양한 실시 예에서, 제1 클라이언트(100)는 토픽(315)에서의 메신저 기능을 사용할 제3 클라이언트(예: 도 1의 제3 클라이언트(500))를 더 초대할 수 있다. 이 경우, 제1 클라이언트(100)는 제2 클라이언트(200)와의 키 교환을 통해 생성된 제1 암호키를 제3 클라이언트에게 전달할 수 있다. 이 때, 제1 클라이언트(100)와 제3 클라이언트는 상술된 방법과 동일한 방법으로 키 교환을 통해 제2 암호키를 생성할 수 있다. 제1 클라이언트(100)는 상기 제1 암호키를 제2 암호키로 암호화하고, 제2 암호키를 기초로 암호화된 제1 암호키를 제3 클라이언트에게 전달할 수 있다. 예를 들어, 제1 클라이언트(100)는 제2 암호키를 기초로 암호화된 제1 암호키를 포함하는 메시지 데이터를 토픽(315)에 전송하고, 제3 클라이언트가 메시지 데이터를 복호화함으로써 제1 암호키를 획득하도록 할 수 있다. 또는 제1 클라이언트(100)와 제3 클라이언트의 별도의 통신 방법으로 제2 암호키를 기초로 암호화된 제1 암호키를 제3 클라이언트로 전송할 수 있다. 제3 클라이언트가 제1 암호키를 수신하면, 제1 암호키를 기초로 메시지 데이터를 암호화 하여 토픽(315)으로 전송하거나, 토픽(315)으로 전송된 메시지 데이터를 복호화할 수 있다.
본 문서의 다양한 실시예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 상기 아이템 한 개 또는 복수 개를 포함할 수 있다. 본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나", "A 또는 B 중 적어도 하나,""A, B 또는 C," "A, B 및 C 중 적어도 하나,"및 "A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들의 모든 가능한 조합을 포함할 수 있다. "제 1", "제 2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성요소를 다른 해당 구성요소와 구분하기 위해 사용될 수 있으며, 해당 구성요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제 1) 구성요소가 다른(예: 제 2) 구성요소에, "기능적으로" 또는 "통신적으로"라는 용어와 함께 또는 이런 용어 없이, "커플드" 또는 "커넥티드"라고 언급된 경우, 그것은 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로(예: 유선으로), 무선으로, 또는 제 3 구성요소를 통하여 연결될 수 있다는 것을 의미한다.
본 문서의 다양한 실시예들은 기기(machine)(예: 제1 클라이언트(100), 제2 클라이언트(200)) 의해 읽을 수 있는 저장 매체(storage medium)(예:메모리(120))에 저장된 하나 이상의 명령어들을 포함하는 소프트웨어로서 구현될 수 있다. 예를 들면, 기기(예: 제1 클라이언트(100), 제2 클라이언트(200))의 프로세서(예: 프로세서(110))는, 저장 매체로부터 저장된 하나 이상의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 기기가 상기 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 상기 하나 이상의 명령어들은 컴파일러에 의해 생성된 코드 또는 인터프리터에 의해 실행될 수 있는 코드를 포함할 수 있다. 기기로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, ‘비일시적’은 저장매체가 실재(tangible)하는 장치이고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.
일실시예에 따르면, 본 문서에 개시된 다양한 실시예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory (CD-ROM))의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 또는 두개의 사용자 장치들(예: 스마트폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
다양한 실시예들에 따르면, 상기 기술한 구성요소들의 각각의 구성요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있다. 다양한 실시예들에 따르면, 전술한 해당 구성요소들 중 하나 이상의 구성요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성요소들(예: 모듈 또는 프로그램)은 하나의 구성요소로 통합될 수 있다. 이런 경우, 통합된 구성요소는 상기 복수의 구성요소들 각각의 구성요소의 하나 이상의 기능들을 상기 통합 이전에 상기 복수의 구성요소들 중 해당 구성요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시예들에 따르면, 모듈, 프로그램 또는 다른 구성요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱하게 실행되거나, 상기 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.

Claims (14)

  1. 클라이언트 장치에 있어서,
    에이전시 서버, 상대방 장치와 통신하도록 설정된 통신 인터페이스;
    메모리; 및
    상기 메모리와 동작 가능하도록 연결되어 명령어들을 실행하도록 설정된 적어도 하나의 프로세서;를 포함하고,
    상기 적어도 하나의 프로세서는,
    상기 에이전시 서버로 토픽 생성 요청을 전송하고,
    상기 에이전시 서버로부터 토픽 생성 알림이 수신되면 상기 토픽에 대응하는 제1 구독 DID, 상기 제1 구독 DID에 대응되는 한 쌍의 제1 구독 개인키 및 제1 구독 공개키를 생성하고,
    상기 제1 구독 DID를 상기 상대방 장치로 전송하고,
    상기 에이전시 서버로부터 상기 상대방 장치로부터 생성된 제2 구독 DID를 수신하고,
    상기 제1 구독 개인키 및 상기 제2 구독 DID를 기초로 제1 암호키를 생성하고,
    상기 제1 암호키로 암호화된 메시지 데이터를 상기 에이전시 서버로 전송하도록 설정된,
    클라이언트 장치.
  2. 청구항 1에 있어서,
    상기 적어도 하나의 프로세서는,
    상기 암호화된 데이터 메시지, 이전 메시지 블록의 해시 값을 포함하는 메시지 블록을 생성하고,
    상기 메시지 블록을 상기 에이전시 서버로 전송하도록 설정된,
    클라이언트 장치.
  3. 청구항 1에 있어서,
    상기 적어도 하나의 프로세서는,
    상기 클라이언트 장치에 대응하는 제1 계정 DID, 상기 제1 계정 DID에 대응되는 한 쌍의 계정 개인키 및 계정 공개키를 생성하고,
    상기 제1 계정 DID를 상기 에이전시 서버로 전송하고,
    상기 에이전시 서버로부터 상기 제1 계정 DID에 대응되는 클라우드 DID 에이전트의 주소를 수신하도록 설정되고,
    상기 토픽은 상기 클라우드 DID 에이전트 내에 포함되는 것인
    클라이언트 장치.
  4. 청구항 3에 있어서,
    상기 토픽 생성 알림은 상기 토픽에 대응되어 에이전시 서버에 의하여 생성된 토픽 아이디를 포함하고,
    상기 적어도 하나의 프로세서는,
    상기 제1 계정 DID, 상기 토픽 아이디 및 상기 제1 구독 DID를 상기 상대방 장치로 전송하고,
    상기 클라우드 DID 에이전트의 주소와 상기 토픽 아이디를 통해, 상기 암호화된 메시지 데이터를 상기 클라우드 DID 에이전트 내에 생성된 토픽으로 전송하도록 설정된, 클라이언트 장치.
  5. 청구항 4에 있어서,
    상기 클라우드 DID 에이전트의 주소는,
    블록체인 네트워크에 상기 제1 계정 DID에 대응되어 저장되는 것인,
    클라이언트 장치.
  6. 청구항 3에 있어서,
    상기 적어도 하나의 프로세서는,
    상기 제2 구독 DID를 통해 블록체인 네트워크로부터 상기 제2 구독 DID에 맵핑되어 저장된 제2 구독 공개키를 획득하고,
    상기 획득된 제2 구독 공개키와 상기 제1 구독 개인키를 기초로 상기 제1 암호키를 생성하도록 설정된,
    설정된,
    클라이언트 장치.
  7. 메신저 서비스 제공을 위한 방법에 있어서,
    제1 클라이언트가 토픽 생성 요청을 에이전시 서버로 전송하는 단계;
    상기 에이전시 서버가 상기 토픽 생성 요청에 응답하여, 상기 에이전시 서버의 메모리에 토픽을 생성하는 단계;
    상기 제1 클라이언트는 상기 토픽에 대응하는 제1 구독 DID, 상기 제1 구독 DID에 대응되는 한 쌍의 제1 구독 개인키 및 제1 구독 공개키를 생성하고, 제2 클라이언트에 제1 구독 DID 를 전송하는 단계;
    상기 제2 클라이언트는 상기 토픽에 대응하는 제2 구독 DID, 상기 제2 구독 DID에 대응되는 한 쌍의 제2 구독 개인키 및 제2 구독 공개키를 생성하고, 상기 에이전시 서버에 제2 구독 DID를 전송하는 단계;
    상기 에이전시 서버가 상기 제2 구독 DID를 상기 제1 클라이언트로 전송하는 단계;
    상기 제1 클라이언트가 상기 제1 구독 개인키 및 상기 제2 구독 DID를 기초로 생성된 제1 암호키로 암호화된 메시지 데이터를 상기 에이전시 서버로 전송하는 단계;
    상기 에이전시 서버가 상기 암호화된 메시지 데이터를 상기 제2 클라이언트로 전송하는 단계; 및
    상기 제2 클라이언트가 상기 제2 구독 개인키 및 상기 제1 구독 DID를 기초로 생성된 상기 제1 암호키로 상기 암호화된 메시지 데이터를 복호화하는 단계; 를 포함하는,
    방법.
  8. 청구항 7에 있어서,
    상기 제1 클라이언트가 상기 제1 클라이언트에 대응하는 제1 계정 DID, 상기 제1 계정 DID에 대응되는 한 쌍의 제1 계정 개인키 및 제1 계정 공개키를 생성하는 단계;
    상기 제1 클라이언트가 상기 제1 계정 DID를 상기 에이전시 서버로 전송하는 단계;
    상기 에이전시 서버가 상기 제1 계정 DID에 대응되는 클라우드 DID 에이전트를 생성하는 단계; 및
    상기 제1 클라이언트가 상기 에이전시 서버로부터 상기 제1 계정 DID에 대응되는 클라우드 DID 에이전트 주소를 수신하는 단계;를 더 포함하고,
    상기 에이전시 서버가 상기 토픽을 생성하는 단계는,
    상기 에이전시 서버가 상기 토픽 생성 요청에 응답하여, 상기 클라우드 DID 에이전트 내에 상기 토픽을 생성하는 단계;를 포함하는,
    방법.
  9. 청구항 8에 있어서,
    상기 제1 클라이언트가 상기 제1 계정 개인키에 기초한 디지털 서명을 포함하는 상기 토픽에 대한 삭제 요청을 상기 클라우드 DID 에이전트로 전송하는 단계; 및
    상기 에이전시 서버가 상기 디지털 서명을 블록체인 네트워크를 통해 검증하는 단계;
    상기 에이전시 서버가 상기 디지털 서명이 상기 제1 클라이언트에 의하여 생성된 정당한 디지털 서명임이 확인될 때, 상기 삭제 요청에 응답하여 상기 클라우드 DID 에이전트에 저장된 상기 토픽을 삭제하는 단계;를 더 포함하는,
    방법.
  10. 청구항 7에 있어서,
    상기 제1 클라이언트는 상기 암호화된 메시지 데이터, 이전 메시지 블록의 해시 값을 포함하는 메시지 블록을 생성하고, 상기 메시지 블록을 상기 에이전시 서버로 전송하는 단계;
    상기 에이전시 서버가 상기 메시지 블록을 상기 제2 클라이언트로 전송하는 단계; 및
    상기 제2 클라이언트가 상기 메시지 블록에 저장된 상기 이전 메시지 블록의 해시 값이 상기 제2 클라이언트에 기 저장된 이전 메시지 블록의 해시 값과 동일한지 여부를 판단하는 단계; 를 더 포함하는,
    방법.
  11. 청구항 7에 있어서,
    상기 에이전시 서버는 상기 암호화된 메시지를 상기 토픽에 저장하는 단계; 및
    상기 제2 클라이언트는 상기 복호화된 메시지를 상기 제2 클라이언트의 디스플레이를 통해 표시하는 단계; 를 더 포함하는, 방법.
  12. 청구항 7에 있어서,
    상기 제1 클라이언트는 상기 암호화된 메시지 데이터, 이전 메시지 블록의 해시 값을 포함하는 메시지 블록을 생성하고, 상기 메시지 블록을 상기 에이전시 서버로 전송하는 단계;
    상기 에이전시 서버가 상기 메시지 블록을 상기 제2 클라이언트로 전송하는 단계; 및
    상기 제2 클라이언트가 상기 메시지 블록에 저장된 상기 이전 메시지 블록의 해시 값이 상기 제2 클라이언트에 기 저장된 이전 메시지 블록의 해시 값과 동일한지 여부를 판단하는 단계; 를 더 포함하는,
    방법.
  13. 청구항 12에 있어서,
    상기 메시지 블록에 저장된 상기 이전 메시지 블록의 해시 값이 상기 제2 클라이언트에 기 저장된 이전 메시지 블록의 해시 값과 동일하지 않은 경우, 상기 제2 클라이언트가 상기 에이전시 서버를 통해 해시 값 불일치 알람을 상기 제1 클라이언트로 전송하는 단계;를 더 포함하는,
    방법.
  14. 청구항 7에 있어서,
    상기 제1 클라이언트가 상기 제1 구독 개인키 및 상기 제2 구독 DID로 상기 제1 암호키를 생성하는 단계는,
    상기 제1 클라이언트가 상기 제2 구독 DID를 통해 블록체인 네트워크로부터 상기 제2 구독 DID에 맵핑되어 저장된 제2 구독 공개키를 획득하는 단계; 및
    상기 제1 클라이언트가 상기 획득된 제2 구독 공개키와 상기 제1 구독 개인키를 기초로 상기 제1 암호키를 생성하는 단계;를 포함하는,
    방법.
PCT/KR2022/015505 2022-08-30 2022-10-13 블록체인 did 기술 기반의 종단 암호화를 통한 비밀 메신저 기능을 제공하는 전자 장치 및 방법 WO2024048838A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020220108948A KR20240030213A (ko) 2022-08-30 2022-08-30 블록체인 did 기술 기반의 종단 암호화를 통한 비밀 메신저 기능을 제공하는 전자 장치 및 방법
KR10-2022-0108948 2022-08-30

Publications (1)

Publication Number Publication Date
WO2024048838A1 true WO2024048838A1 (ko) 2024-03-07

Family

ID=90098101

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/015505 WO2024048838A1 (ko) 2022-08-30 2022-10-13 블록체인 did 기술 기반의 종단 암호화를 통한 비밀 메신저 기능을 제공하는 전자 장치 및 방법

Country Status (2)

Country Link
KR (1) KR20240030213A (ko)
WO (1) WO2024048838A1 (ko)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102003272B1 (ko) * 2019-04-10 2019-10-01 (주)지란지교시큐리티 블록체인 기반 스캠 메일 방지 메일게이트웨이용 프로그램, 단말용 프로그램, 블록체인 서비스용 서버 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체 및 그 시스템
KR20220066823A (ko) * 2020-11-16 2022-05-24 포항공과대학교 산학협력단 블록체인 기반 피싱 방지 시스템, 장치 및 방법
KR20220092748A (ko) * 2020-12-24 2022-07-04 주식회사 디지털존 Did 기반의 문서 관리 서버, 블록 체인 서버, 시스템 및 그것의 제어 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102003272B1 (ko) * 2019-04-10 2019-10-01 (주)지란지교시큐리티 블록체인 기반 스캠 메일 방지 메일게이트웨이용 프로그램, 단말용 프로그램, 블록체인 서비스용 서버 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체 및 그 시스템
KR20220066823A (ko) * 2020-11-16 2022-05-24 포항공과대학교 산학협력단 블록체인 기반 피싱 방지 시스템, 장치 및 방법
KR20220092748A (ko) * 2020-12-24 2022-07-04 주식회사 디지털존 Did 기반의 문서 관리 서버, 블록 체인 서버, 시스템 및 그것의 제어 방법

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JO JUNG-HWA, YOO SOO-BIN, YOO SU-MIN, SON AE-SEON: "Contract Platform in a Blockchain-based Decentralized Identity Environment", THE JOURNAL OF KOREAN INSTITUTE OF INFORMATION TECHNOLOGY, vol. 18, no. 12, 31 December 2020 (2020-12-31), pages 131 - 139, XP093145744, ISSN: 1598-8619, DOI: 10.14801/jkiit.2020.18.12.131 *
RAMAN SINGH; ARK NANDAN SINGH CHAUHAN; HITESH TEWARI: "Blockchain-Enabled End-to-End Encryption for Instant Messaging Applications", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 17 April 2021 (2021-04-17), 201 Olin Library Cornell University Ithaca, NY 14853 , XP081940079 *

Also Published As

Publication number Publication date
KR20240030213A (ko) 2024-03-07

Similar Documents

Publication Publication Date Title
US10880732B2 (en) Authentication of phone caller identity
WO2018043865A2 (ko) 블록체인을 기반으로 한 파일 관리/검색 시스템 및 파일 관리/검색 방법
US7171001B2 (en) Method and apparatus for managing secure collaborative transactions
WO2017119564A1 (ko) 본인인증용 정보 보안 전송시스템 및 방법
US7366897B2 (en) Method and system for communication via a computer network
US7376834B2 (en) System and method for securely controlling communications
JP2010033580A (ja) 信頼性のある分散型ピアツーピアネットワークを確立する方法及びシステム
CN1643839A (zh) Ip语音通信系统的媒体流密钥的端对端保护
CN112689014B (zh) 一种双全工通信方法、装置、计算机设备和存储介质
JP2001177513A (ja) 通信システムにおける認証方法、センタ装置、認証プログラムを記録した記録媒体
WO2022240026A1 (ko) 복수 개의 블록체인을 통합하여 하나의 미들 블록으로 api 서비스를 제공하는 방법과 장치 및 이를 이용한 신원 증명 방법
WO2015178597A1 (ko) Puf를 이용한 비밀키 업데이트 시스템 및 방법
WO2019045540A1 (ko) 분할 기능을 이용한 소셜 미디어 제공 방법 및 시스템
WO2024048838A1 (ko) 블록체인 did 기술 기반의 종단 암호화를 통한 비밀 메신저 기능을 제공하는 전자 장치 및 방법
WO2023149660A1 (ko) 그룹 서명 기반 연합학습 방법 및 시스템, 이를 수행하기 위한 기록 매체
WO2021075604A1 (ko) 상속 데이터 전달 방법 및 장치
WO2024111830A1 (ko) 사용자간에 스트리밍 형식으로 송수신되는 미디어의 암호화 방법 및 시스템
KR102387911B1 (ko) 보안 인스턴트 메시징 방법 및 장치
US20230388112A1 (en) Method and apparatus for providing secure messaging service
WO2024117568A1 (ko) 데이터를 암호화하는 방법 및 장치
WO2023277532A1 (ko) 블록체인 네트워크 상에서 발행된 토큰을 통한 서비스 이용 방법 및 이를 이용하는 시스템
CN115102698A (zh) 量子加密的数字签名方法及系统
WO2018097548A1 (ko) 암호화된 트래픽 분석을 통한 내부 정보 유출 모니터링 시스템 및 방법
JP2022103134A (ja) セキュリティ指向及びグループ共有に基づくモノのインターネットシステム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22957516

Country of ref document: EP

Kind code of ref document: A1