Patent Publication Number: US-2021176075-A1

Title: Cryptographic communication system and cryptographic communication method based on blockchain

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims priority under 35 U.S.C. § 119 to Korean Patent Application No. 10-2019-0162519 filed on Dec. 9, 2019, in the Korean Intellectual Property Office, the disclosures of which are incorporated by reference herein in their entireties. 
     BACKGROUND 
     Example embodiments of inventive concepts disclosed herein relate to a cryptographic communication system, and more particularly, relate to a cryptographic communication system based on a distributed ledger, such as a blockchain. 
     A public key cryptographic technology is/includes a cryptographic technology using two correlated encryption keys (e.g., a public key and a secret, or private key). A secret/private key may be open/available to only a user possessing the secret/private key, and a public key may be available, e.g. in the open, to anyone wanting the public key. A user may encrypt (respectively, decrypt) a message by using the public key (respectively, private/secret key. 
     The public key cryptographic technology is used for message encryption and an electronic signature, and requires/utilizes a public key infrastructure (PKI) to secure and manage a public key. The public key infrastructure is/includes a security system for certificate management tasks such as issuing, updating, and revoking public keys. A user in the public key infrastructure may identify himself/herself through a certificate issued by a certification authority (hereinafter referred to as “CA”). 
     Public key infrastructures are/include a centralized system in which authentication and management are made by the CA. In the centralized public key infrastructure, in a case where the root/administration of the CA is attacked, certificates of all users in the public key infrastructure have to be revoked. 
     SUMMARY 
     Example embodiments of inventive concepts provide a cryptographic communication system and/or a cryptographic communication method based on blockchain. 
     According to some example embodiments, a cryptographic communication system may include includes an electronic device configured to output a certificate and a transaction including a first hash value in which a certificate is hashed certificate, and a node configured to first determine whether the electronic device generated the transaction based on the transaction and the certificate, to second determine whether information included in the transaction and information included in the certificate coincide, and to third add a block to a distributed ledger depending on the result of the first determining and the second determining. The block includes the transaction, and the electronic device is configured to generate the certificate such that the certificate includes an ID of the electronic device and a public key of the electronic device. 
     According to some example embodiments, an electronic device may include An interface, processing circuitry, and a memory configured to store instructions executable by the processor. The instructions, when executed by the processing circuitry, cause the processing circuitry to, generate a first certificate including an ID and a public key, the ID and the public key being associated with the electronic device, generate a first transaction including a hash value of a hash of the first certificate, output the first certificate and the first transaction to a distributed ledger through the interface, obtain a second transaction including an identity of an external electronic device from the distributed ledger in response to a second certificate indicating the external electronic device received the identity of the external electronic device, and verify the identity of the external electronic device based on the second certificate and the second transaction. 
     According to some example embodiments, a cryptographic communication method may include receiving a first certificate of a first electronic device and a first transaction including a first hash value in which the first certificate is hashed, comparing a first result value corresponding to a decryption of a portion of the first transaction based on a first public key included in the first transaction with a second hash value of a hashing of the first certificate received from the first electronic device, comparing information included in the first transaction with information included in the first certificate, and registering the first transaction at a distributed ledger in response to the first result value and the second hash value coinciding, and the information included in the first transaction and the information included in the first certificate coinciding. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
       The above and other objects and features of inventive concepts will become apparent by describing in detail example embodiments thereof with reference to the accompanying drawings. 
         FIG. 1  is a conceptual diagram for describing a cryptographic communication system according to some example embodiments of inventive concepts. 
         FIG. 2  is a conceptual diagram for describing a transaction of  FIG. 1 . 
         FIG. 3  is a diagram for describing functions disclosed in the specification. 
         FIG. 4  is a conceptual diagram illustrating some example embodiments of a transaction of  FIG. 1 . 
         FIG. 5  is a block diagram illustrating some example embodiments of a certificate of  FIG. 1 . 
         FIG. 6  is a conceptual diagram for describing a method in which a node of  FIG. 1  verifies a transaction and a certificate. 
         FIG. 7  is a flowchart for describing a method in which a node of  FIG. 1  verifies a transaction and a certificate. 
         FIG. 8  is a conceptual diagram for indicating blocks registered at a distributed ledger on a blockchain network of  FIG. 1 . 
         FIG. 9  is a conceptual diagram illustrating some example embodiments of a transaction of  FIG. 1 . 
         FIG. 10  is a conceptual diagram illustrating some example embodiments of a certificate of  FIG. 1 . 
         FIG. 11  is a diagram for describing a signature of a transaction of  FIG. 9 . 
         FIG. 12  is a flowchart for describing a method in which a node of  FIG. 1  verifies a transaction and a certificate. 
         FIG. 13  is a conceptual diagram for indicating blocks registered at a distributed ledger on a blockchain network of  FIG. 1 . 
         FIG. 14  is a conceptual diagram illustrating some example embodiments of a transaction of  FIG. 1 . 
         FIG. 15  is a conceptual diagram illustrating some example embodiments of a certificate of  FIG. 1 . 
         FIG. 16  is a flowchart for describing a method in which a node of  FIG. 1  verifies a transaction and a certificate. 
         FIG. 17  is a conceptual diagram for indicating blocks registered at a distributed ledger on a blockchain network of  FIG. 1 . 
         FIG. 18  is a conceptual diagram for describing a procedure in which electronic devices in a cryptographic communication system prove their own identities. 
         FIG. 19  is a flowchart for describing a procedure in which electronic devices in a cryptographic communication system prove their own identities. 
         FIG. 20  is a conceptual diagram for describing a method in which electronic devices automatically search for a block. 
         FIG. 21  is a conceptual diagram for describing how to extend a public key registered at a distributed ledger. 
         FIG. 22  is a conceptual diagram illustrating some example embodiments of a transaction of  FIG. 1 . 
         FIG. 23  is a block diagram illustrating a cryptographic communication system of  FIG. 1 . 
     
    
    
     DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS 
     Below, some example embodiments of inventive concepts may be described in detail and clearly to such an extent that an ordinary one in the art easily implements inventive concepts. 
     Inventive concepts may provide a cryptographic communication system and/or a cryptographic communication method based on blockchain. 
     As used herein, a “blockchain” may mean and/or correspond to a distributed ledger technology that allows nodes in a network to record and manage a ledger, e.g. a common ledger, recording transaction information. The distributed ledger may mean that a ledger is distributed into a peer-to-peer (P2P) network, and is not at a central server of a specific authority. All nodes in the P2P network may provide resources such as processing capability, storage space, data, network bandwidth, etc., to each other without interference of and/or communication with a central node. There may be some mechanism, such as a proof-of-work and/or a proof-of-stake mechanism, wherein nodes of the P2P network securely update the distributed blockchain network; however, example embodiments are not limited thereto. 
     In general, a “blockchain wallet” may mean and/or correspond to a mechanism that stores a value in an electronic device by an electronic method and enables online and/or offline transactions without an exchange of a commodity money. In particular, the “blockchain wallet” mentioned herein may be and/or correspond to and/or include a program that is used to generate a transaction and a certificate, the certificate being based on a public key and/or a private key, etc. The blockchain wallet may be implemented through software including program codes and/or may be implemented through hardware storing program codes. 
     As used herein, a “hash” may mean and/or correspond to a function mapping data of any length onto data of a fixed length. A “hash value” may mean a value that is obtained by a hash function. 
     As used herein, an “electronic device” may mean and/or correspond and/or include a device that is supplied with electric energy and operates. For example, an electronic device may be or include, but is not limited to, a smartphone, a tablet personal computer (PC), a smart TV, a mobile phone, a personal digital assistant (PDA), a laptop, a stationary computing device, etc. 
     As used herein, a “node” may mean and/or correspond to and/or include a component in a blockchain network. For example, the node may be or include, but is not limited to, a special-purpose computer, a general-purpose computer, a supercomputer, a mainframe computer, a personal computer, a smartphone, a tablet PC, etc. 
       FIG. 1  is a conceptual diagram for describing a cryptographic communication system according to some example embodiments of inventive concepts. 
     Based on a blockchain, a cryptographic communication system  10  may verify electronic devices  100 ,  200 , and  300 , and may verify transactions between the electronic devices  100 ,  200 , and  300 . The cryptographic communication system  10  may include the first electronic device  100 , the second electronic device  200 , the third electronic device  300 , and a blockchain network  400 . Below, for convenience of description, nodes  410  to  440  of the blockchain network  400  and the electronic devices  100  to  300  are illustrated to be independent of each other, but the electronic devices  100  to  300  may provide the same or substantially the same operations as the nodes  410  to  440 . For example, the electronic devices  100  to  300  may also operate as a client of the blockchain network  400  like the nodes  410  to  440 . 
     The electronic devices  100 ,  200 , and  300  may provide the same or substantially the same operations. Accordingly, in the following descriptions, operations of the first electronic device  100  will be mainly described. 
     The first electronic device  100  may execute a blockchain wallet. The first electronic device  100  may generate a private key SK 1 , a public key PK 1 , a transaction  110 , and a certificate  120 , by using/based on the blockchain wallet. The private key SK 1  may be known only to the first electronic device  100  and may not be known or publicly accessible to other external components such as electronic devices  200 ,  300 , and  410  to  440 . The public key PK 1  may be known to/accessible by all the components/electronic devices  200 ,  300 , and  410  to  440  in the cryptographic communication system  10 . 
     The first electronic device  100  may encrypt a message by using the private key SK 1 . The remaining components  200 ,  300 , and  410  to  440  may decrypt the encrypted message by using the public key PK 1 . Encrypting a message with the private key SK 1  may mean or correspond to signing the message with the private key SK 1 . A method in which the first electronic device  100  encrypts a message may be at least one of a Diffie-Hellman key exchange method, a RSA method, a Rabin method, an ElGamal method, a DSA method, and/or an elliptic-curve method. However, example embodiments are not limited thereto. For example, the first electronic device  100  may encrypt a message by using any other method other than methods described herein, such as post-quantum encryption method. 
     The transaction  110  may be, include, or correspond to a character string in which there is contained information of a transaction, e.g. an update transaction, that the first electronic device  100  requests from the blockchain network  400 . The transaction  110  may include information about an identity of the first electronic device  100  and a command that the first electronic device  100  requests from/of the blockchain network  400 . The transaction  110  will be more fully described with reference to  FIG. 2 . 
     The certificate  120  may be, include, or correspond to a document and/or string indicating the identity of the first electronic device  100 . The certificate  120  may include at least the following information: an ID of the first electronic device  100  and the public key PK 1  of the first electronic device  100 . The certificate  120  will be more fully described with reference to  FIG. 5 . 
     The first electronic device  100  may output the transaction  110  and the certificate  120  to the blockchain network  400 , e.g. may output the transaction  110  and the certificate  120  over a P2P network corresponding to the blockchain network  400 . 
     The blockchain network  400  may receive the transaction  110  and the certificate  120  output from the first electronic device  100 . The blockchain network  400  may include the nodes  410  to  440 . The node  410  may perform a verification operation on the transaction  110  and the certificate  120 . However, example embodiments are not limited thereto. For example, at least one of the remaining nodes  420  to  440  may perform an operation of verifying a transaction and a certificate. For example, the operation of verifying the transaction  110  and the certificate  120  may include an operation of determining whether the transaction  110  and the certificate  120  are generated from the first electronic device  100 , and an operation of determining whether information about the first electronic device  100  included in the certificate  120  and information about the first electronic device  100  included in the transaction  110  coincide. 
     After the transaction  110  and the certificate  120  have been fully verified, the node  410  may generate a block including the transaction  110 . The node  410  may output the generated block to the remaining nodes  420  to  440 , for example over the P2P network. In this case, the generated block may be recorded at a distributed ledger on the blockchain network  400 . For example, the transaction  110  may be registered at the distributed ledger on the blockchain network  400 . 
       FIG. 2  is a conceptual diagram for describing a transaction of  FIG. 1 . 
     The transaction  110  may include a message  111  (e.g. a payload) and a signature σ. 
     The message  111  may include an identification, e.g. an ID DID 1  of the first electronic device  100  of  FIG. 1 , a command CMD that the first electronic device  100  requests from the node  410 , the public key PK 1  of the first electronic device  100 , and a hash value HC 1  being a result of hashing the certificate  120  of  FIG. 1 . Inventive concepts may use, but is not limited to, a secure hash function such as the SHA256 hash function. The ID DID 1  of the first electronic device  100 , the command CMD, the public key PK 1 , and the hash value HC 1  included in the transaction  110  may be listed in a different order from the order illustrated in  FIG. 2 . 
     The signature σ 1  may be a result of encrypting the message  111  by using the private key SK 1  of  FIG. 1 . For example, the signature σ 1  may be a result of encrypting a hash value by using the private key SK 1 , wherein the hash value corresponds to a hash of the message  111 . 
     The node  410  of  FIG. 1  may perform a verification operation on the transaction  110  and the certificate  120  before performing an operation corresponding to the command CMD. For example, the node  410  may determine whether information included in the transaction  110  and information included in the certificate  120  coincide, by using the message  111 . The node  410  may determine whether the transaction  110  and the certificate  120  are generated from the first electronic device  100 , by using the signature σ 1 . An operation of the node  410  will be more fully described with reference to  FIG. 6 . 
       FIG. 3  is a diagram for describing functions disclosed in the specification. 
     Referring to  FIG. 3 , “DIDx” indicates an ID of an electronic device “x”. The electronic device “x” may be or correspond to one of the electronic devices  100  to  300  of  FIG. 1 . “PKx” indicates a public key of the electronic device “x”. “SKx” indicates a private key of the electronic device “x”. “HCx” indicates a hash value being a result of hashing a certificate of the electronic device “x”. “Mx” indicates a message generated from the electronic device “x”. As described with reference to  FIG. 2 , “Mx” may be a bit string in which “DIDx”, “PKx”, “SKx”, and “HCx” are listed. “ax” indicates a signature generated from the electronic device “x”. As described with reference to  FIG. 2 , “ax” may be a result of encrypting a hash value being a result of hashing “Mx” by using a private key. 
     A command may include “REG”, “UPD”, and “REV”, and may correspond to commands to be performed within the blockchain  400  of  FIG. 1 . However, inventive concepts are not limited thereto. For example, a command, which is not disclosed in  FIG. 3 , such as “Look up” may be used. The “Look up” command will be more fully described with reference to  FIGS. 19 and 20 . 
     The electronic device “x” may use the “REG” command when intending to register identity information of the electronic device “x” at or within a distributed ledger such as the blockchain  400  of  FIG. 1 . In a case of using the “REG” command, the electronic device “x” may generate a message Mx including “DIDx”, “REG”, “PKx”, and/or “HCx”. The electronic device “x” may request the node  410  of  FIG. 1  to register a public key of the electronic device “x” at the distributed ledger as “PKx”, by using the message Mx. 
     The electronic device “x” may use the “UPD” command when intending to update the identity information of the electronic device “x” registered at or within the distributed ledger. In a case of using the “UPD” command, the electronic device “x” may generate a message Mx including “DIDx”, “REG”, “{PKx 0 , PKx 1  }”, and “HCx”. The electronic device “x” may request the node  410  to update a public key of the “DIDx” registered at the distributed ledger from “PKx 0 ” to “PKx 1 ”, by using the message Mx. For example, after the electronic device “x” updates the public key of the “DIDx” registered at the distributed ledger from “PKx 0 ” to “PKx 1 ”, in a case where the electronic device “x” again updates the public key of the “DIDx” registered at the distributed ledger from “PKx 1 ” to “PKx 2 ”, the electronic device “x” may generate a message Mx including “DIDx”, “REG”, “{PKx 0 , PKx 2 }”, and “HCx”. For example, the message Mx may be generated to include information about the public key PKx 0  registered for the first time and information about the public key PKx 2  to be registered at a distributed ledger. When a transaction and a certificate of the electronic device “x” are completely verified, the node  410  may generate a block including the message Mx and may register the block at the distributed ledger. 
     The electronic device “x” may use the “REV” command when intending to revoke the identity information of the electronic device “x” registered at the distributed ledger. In a case of using the “REV” command, the electronic device “x” may generate a message Mx including “DIDx”, “REV”, “PKx”, and “HCx”. The electronic device “x” may request the node  410  to revoke the public key of the “DIDx” registered at the distributed ledger, by using the message Mx. 
       FIG. 4  is a conceptual diagram illustrating some example embodiments of a transaction of  FIG. 1 . 
     The first electronic device  100  of  FIG. 1  may generate a transaction  110   a  when intending to register identity information of the first electronic device  100  at a distributed ledger. The transaction  110   a  may include a message  111   a  (e.g. a payload) and a signature σ 1 . The message  111   a  may include “DID 1 ”, “REG”, “PK 1 ”, and “HC 1 ”. “DID 1 ”, “PK 1 ”, and “HC 1 ” indicate an ID of the first electronic device  100 , a public key of the first electronic device  100 , and a hash value being a result of hashing the certificate  120  of the first electronic device  100 , respectively. The signature σ 1  may be a result of encrypting a hash value by using the private key SK 1  with the hash value being a result of hashing the message  111   a.    
       FIG. 5  is a block diagram illustrating some example embodiments of the certificate of  FIG. 1 . 
     The first electronic device  100  of  FIG. 1  may generate a certificate  120   a  for the purpose of proving the first electronic device  100 &#39;s own identity to the blockchain network  400  of  FIG. 1 . The first electronic device  100  may generate the certificate  120   a  complying with the X.509 certificate format. X.509 is an ITU-T standard, which is based on a public key (KPI), from among standards of a public key certificate and an authentication algorithm. The X.509 certificate may indicate a PKI certificate of the IETF (Internet Engineering Task Force) and a CRI (Client Responsible Individual) profile of an X.509 v.3 certificate standard and may be defined in [RFC 3280]. However, inventive concepts are not limited thereto. For example, the first electronic device  100  may generate a certificate that complies with standards of another authentication algorithm/a conventional authentication algorithm. 
     Each field of the certificate  120   a  complying with the X.509 certificate format is described with reference to  FIG. 5 . 
     A version field indicates a version of a certificate. 
     A serial number field indicates a unique serial number of a certificate, which the certification authority (CA) specifies. Because the CA does not exist in the cryptographic communication system  10  of inventive concepts, the serial number field of the certificate  120   a  may indicate a number that the first electronic device  100  randomly generates. Alternatively and/or additionally, the serial number field of the certificate  120   a  may be filled with random and/or meaningless information, and/or may be reserved for future use. 
     A signature algorithm ID field may indicate an algorithm and an algorithm identifier that the CA uses when signing a certificate. The signature algorithm ID field of the certificate  120   a  may indicate a hash algorithm and/or a hash function that the first electronic device  100  uses. For example, the first electronic device  100  may use an ECDSA (Elliptic Curve Digital Signature Algorithm) and/or an SHA-256 algorithm. In this case, the signature algorithm ID field of the certificate  120   a  may indicate the ECDSA and/or the SHA-256 algorithm. 
     An issuer field may indicate information about the certification authority (CA) that issues a certificate. Because an issuer of the certificate  120   a  is the first electronic device  100 , the issuer field of the certificate  120   a  may indicate the ID DID 1  of the first electronic device  100 . 
     A validity period field may indicate a start date and an end date of a validity period, e.g. a period of time corresponding to the validity of the digital certificate  120   a.    
     A subject field may indicate a name of a certificate owner. For example, the subject field of the certificate  120   a  may indicate the ID DID 1  of the first electronic device  100 . 
     A public key information field may include a public key algorithm field and a public key value field. The public key value field of the certificate  120   a  may indicate the public key PK 1  of the first electronic device  100 . 
     An issuer unique ID field and a subject unique ID field may indicate an ID of a certification authority and the ID DID 1  of the first electronic device  100 , respectively. The fields may be selectively included in the certificate  120   a.  Because a certification authority does not exist in the cryptographic communication system  10  of inventive concepts, the issuer unique ID field of the certificate  120   a  may include a random and/or meaningless bit string, and/or may be reserved for future use. 
     The first electronic device  100  may additionally include private information in an extension field of the certificate  120   a.    
     A certificate signature field may indicate a certificate signature  122   a.  The certificate signature  122   a  may correspond to a result of encrypting a hash value by using the private key SK 1  with the hash value being a result of hashing identity information  121   a  included in the certificate  120   a.    
     For example, the first electronic device  100  may fill fields associated with a certification authority from among the fields of the X.509 certificate with information about the first electronic device  100 . The first electronic device  100  may generate the certificate  120   a  complying with the X.509 certificate format. This may mean or may indicate that the first electronic device  100  is capable of being used in an X.509 system. 
       FIG. 6  is a conceptual diagram for describing a method in which a node of  FIG. 1  verifies a transaction and a certificate. 
     The first electronic device  100  of  FIG. 1  may output the transaction  110   a  of  FIG. 4  and the certificate  120   a  of  FIG. 5  in a case of intending to register the first electronic device  100 &#39;s own identity information at a distributed ledger. 
     The node  410  of  FIG. 1  may receive a transaction  110   a _ 1  and a certificate  120   a _ 1  from the first electronic device  100 . In a case where the transaction  110   a  and the certificate  120   a  are transmitted from the first electronic device  100  to the node  410  without an attack, the transaction  110   a _ 1  and the certificate  120   a _ 1  may be identical to the transaction  110   a  and the certificate  120   a.  For example, in this case, “DID 10 ”, “PK 10 ”, “HC 10 ”, and “σ 10 ” may be identical to “DID 1 ”, “PK 1 ”, “HC 1 ”, and “σ 1 ” of  FIG. 4 . Also, “DID 11 ” and “PK 11 ” may be identical to “DID 1 ” and “PK 1 ” of  FIG. 5 . 
     The node  410  may perform a verification operation on the transaction  110   a _ 1  and the certificate  120   a _ 1 . The verification operation associated with the transaction  110   a _ 1  and the certificate  120   a _ 1  may include an operation of determining whether the transaction  110   a _ 1  and the certificate  120   a _ 1  are generated from the first electronic device  100 , and an operation of determining whether information of the transaction  110   a _ 1  and information of the certificate  120   a _ 1  coincide. The operation of determining whether the transaction  110   a _ 1  and the certificate  120   a _ 1  are generated from the first electronic device  100  may mean or correspond to an operation of determining whether the transaction  110   a  and the certificate  120   a  are or have been attacked/corrupted by an attacker while being transferred from the first electronic device  100  to the node  410 . 
     When the verification succeeds, the node  410  may generate a block including the transaction  110   a _ 1 . When the verification fails, the node  410  may revoke the transaction  110   a _ 1  and the certificate  120   a _ 1  received from the first electronic device  100 . In the following descriptions, “verification success” may mean or correspond to the transaction  110   a _ 1  and the certificate  120   a _ 1  being generated from the first electronic device  100  and the information of the transaction  110   a _ 1  and the information of the certificate  120   a _ 1  coinciding. Also, “verification fail” may mean or correspond to the transaction  110   a _ 1  and the certificate  120   a _ 1  not being generated from the first electronic device  100 , and/or the information of the transaction  110   a _ 1  and the information of the certificate  120   a _ 1  not coinciding. 
     An operation in which the node  410  determines whether the transaction  110   a _ 1  and the certificate  120   a _ 1  are generated from the first electronic device  100  is described with reference to operation (a) to operation (c) of  FIG. 6 . In operation (a), the node  410  may generate a hash value of the certificate  120   a _ 1 . In operation (b), the node  410  may generate a hash value by decrypting the signature σ 10  of the transaction  110   a _ 1 , the decryption being by using the public key PK 10 . To perform operation (b), the node  410  may obtain the public key PK 10  from the transaction  110   a _ 1 . 
     The node  410  may compare the hash value generated in operation (a) with the hash value generated in operation (b). That the hash value generated in operation (a) and the hash value generated in operation (b) coincide may mean, indicate, or correspond to the transaction  110   a _ 1  and the certificate  120   a _ 1  being generated from the first electronic device  100 . That the hash value generated in operation (a) and the hash value generated in operation (b) do not coincide may mean, indicate, or correspond to the transaction  110   a _ 1  and the certificate  120   a _ 1  not being generated from the first electronic device  100 . 
     When the node  410  determines that the transaction  110   a _ 1  is generated from the first electronic device  100 , the node  410  may determine whether the information of the transaction  110   a _ 1  and the information of the certificate  120   a _ 1  coincide, through operation (a) and operation (d) to operation (g). 
     In operation (d) and operation (e), the node  410  may determine whether an ID DID 10  and an ID DID 11  coincide, by comparing the ID DID 10  of the transaction  110   a _ 1  with the ID DID 11  of the certificate  120   a _ 1 . In detail, operation (d) may be or include an operation of comparing the ID DID 10  of the transaction  110   a _ 1  and the ID DID 11  included in the issuer field of the certificate  120   a _ 1 . Operation (e) may be or include an operation of comparing the ID DID 10  of the transaction  110   a _ 1  and the ID DID 11  included in the subject field of the certificate  120   a _ 1 . The node  410  may selectively perform one of operation (d) or operation (e) or may perform both operation (d) and operation (e). 
     In operation (f), the node  410  may determine whether a public key PK 10  and a public key PK 11  coincide, by comparing the public key PK 10  of the transaction  110   a _ 1  and the public key PK 11  of the certificate  120   a _ 1 . 
     In operation (g), the node  410  may determine whether a hash value HC 10  included in the transaction  110   a _ 1  and the hash value generated in operation (a) coincide, by comparing the hash value HC 10  and the hash value generated in operation (a). 
     When is the node  410  determine through operation (a) and operation (d) to operation (g) that the information of the transaction  110   a _ 1  and the information of the certificate  120   a _ 1  coincide, the node  410  may generate a block including the transaction  110   a _ 1 . The node  410  may broadcast the block on the P2P network, and may broadcast other information such as a proof-of-work; however, example embodiments are not limited thereto. 
     The order of operation (a) to operation (g) is not limited to the above description. The first electronic device  100  may perform operation (a) to operation (g) in any order. However, operation (a) may be performed before operation (c) and operation (g) are performed. 
       FIG. 7  is a flowchart for describing a method in which a node of  FIG. 1  verifies a transaction and a certificate. 
     The node  410  of  FIG. 1  may perform operation S 110  to operation S 190  for the purpose of verifying the transaction  110   a _ 1  and the certificate  120   a _ 1  of  FIG. 6 . Because operation S 110  to operation S 190  are substantially identical to operation (a) to operation (g) described with reference to  FIG. 6 , operation S 110  to operation S 190  are briefly described. 
     In operation S 110 , the node  410  may receive the transaction  110   a _ 1  and the certificate  120   a _ 1  from the first electronic device  100  of  FIG. 1 . 
     In operation S 120 , the node  410  may obtain/calculate a hash value of the certificate  120   a _ 1 . Operation S 120  may correspond to operation (a) of  FIG. 6 . 
     In operation S 130 , the node  410  may obtain a hash value by decrypting the signature σ 10  by using the public key PK 10 . Operation S 130  may correspond to operation (b) of  FIG. 6 . 
     In operation S 140 , the node  410  may compare the hash value obtained in operation S 120  and the hash value obtained in operation S 130 . Operation S 140  may correspond to operation (c) of  FIG. 6 . 
     When the hash value obtained in operation S 120  and the hash value obtained in operation S 130  do not coincide, the node  410  may perform operation S 190 . When the hash value obtained in operation S 120  and the hash value obtained in operation S 130  do not coincide, there may be an indication that an attacker has attacked/corrupted the transaction  110   a _ 1  and/or the certificate  120 _ 1  In operation S 190 , the node  410  may revoke the transaction  110   a _ 1  and the certificate  120   a _ 1  received from the first electronic device  100  of  FIG. 1 . 
     When the hash value obtained in operation S 120  and the hash value obtained in operation S 130  coincide, the node  410  may perform operation S 150 . In operation S 150 , the node  410  may compare the ID DID 10  included in the transaction  110   a _ 1  and an ID DID 11  included in the certificate  120   a _ 1 . Operation S 140  may correspond to operation (d) and operation (e) of  FIG. 6 . 
     When the ID DID 10  included in the transaction  110   a _ 1  and the ID DID 11  included in the certificate  120   a _ 1  do not coincide, the node  410  may perform operation S 190 . 
     When the ID DID 10  included in the transaction  110   a _ 1  and the ID DID 11  included in the certificate  120   a _ 1  coincide, the node  410  may perform operation S 160 . In operation S 160 , the node  410  may compare the public key PK 10  included in the transaction  110   a _ 1  and the public key PK 11  included in the certificate  120   a _ 1 . Operation S 160  may correspond to operation (f) of  FIG. 6 . 
     When the public key PK 10  included in the transaction  110   a _ 1  and the public key PK 11  included in the certificate  120   a _ 1  do not coincide, the node  410  may perform operation S 190 . 
     When the public key PK 10  included in the transaction  110   a _ 1  and the public key PK 11  included in the certificate  120   a _ 1  coincide, the node  410  may perform operation S 170 . In operation S 170 , the node  410  may compare the hash value HC 10  included in the transaction  110   a _ 1  and the hash value obtained in operation S 120 . Operation S 170  may correspond to operation (g) of  FIG. 6 . 
     When the hash value HC 10  included in the transaction  110   a _ 1  and the hash value obtained in operation S 120  do not coincide, the node  410  may perform operation S 190 . 
     When the hash value HC 10  included in the transaction  110   a _ 1  and the hash value obtained in operation S 120  coincide, the node  410  may perform operation S 180 . In operation S 180 , the node  410  may generate a block including the transaction  110   a _ 1 . The node  410  may register the generated block at the distributed ledger, for example by broadcasting the block on the P2P network, or broadcasting the block and a proof-of-work on the P2P network. For example, a block indicating that a public key of the first electronic device  100  having the ID DID 10  is “PK 10 ” may be registered at the distributed ledger. 
       FIG. 8  is a conceptual diagram for indicating blocks registered at a distributed ledger on a blockchain network of  FIG. 1 . 
       FIG. 8  illustrates how blocks  510  to  530  respectively indicating identity information of the electronic devices  100  to  300  of  FIG. 1  are sequentially registered at/on the distributed ledger through verification of the transaction  110  for a public key and ID register/update/revoke/extension request and the self-signed certificate  120 . 
     The block  510  may indicate that a public key of the first electronic device  100  having the ID DID 1  is “PK 1 ”. The block  520  may indicate that a public key of the second electronic device  200  having an ID DID 2  is “PK 2 ”. The block  530  may indicate that a public key of the third electronic device  300  having an ID DID 3  is “PK 3 ”. 
     Accordingly, the distributed ledger where the blocks  510  to  530  are registered may secure the following: a public key of the first electronic device  100  having the ID DID 1  is “PK 1 ”, a public key of the second electronic device  200  having the ID DID 2  is “PK 2 ”, and a public key of the third electronic device  300  having an ID DID 3  is “PK 3 ”. 
     There may be other information included in each of the blocks  510  to  530 ; however, example embodiments are not limited thereto. For example, there may include a proof-of-work included in each of the blocks  510  to  530 ; however, example embodiments are not limited thereto. Furthermore, the transaction data may be organized as a tree, for example as Merkle tree; however, example embodiments are not limited thereto. 
       FIG. 9  is a conceptual diagram illustrating some example embodiments of a transaction of  FIG. 1 . 
     The first electronic device  100  of  FIG. 1  may generate a new private key and a new public key PK 01  corresponding to the new private key. The first electronic device  100  of  FIG. 1  may generate a new certificate along with a transaction  110   b,  for the purpose of registering the newly generated public key PK 01  at a distributed ledger. For example, the first electronic device  100  of  FIG. 1  may generate a new certificate and the transaction  110   b  for the purpose of updating identity information of the first electronic device  100  registered at the distributed ledger. The new certificate will be more fully described with reference to  FIG. 10 . 
     The transaction  110   b  may include a message  111   b  and a signature σ 01 . The message  111   b  may include “DID 1 ”, “UPD”, “{PK 1 , PK 01 }”, and “HC 01 ”. Herein “DID 1 ”, “PK 1 ”, “PK 01 ”, and “HC 01 ” indicate an ID of the first electronic device  100 , a public key of the first electronic device  100  registered at the distributed ledger, a public key of the first electronic device  100  to be registered at the distributed ledger, and a hash value being a result of hashing a new certificate of the first electronic device  100 , respectively. 
     The signature σ 01  may be or include a signature σ 01_1  and a signature σ 01_2 . The signature σ 01_1  may be or include a result of encrypting a hash value of hashing the message  111   a  registered at the distributed ledger and a hash value HC 01  of the message  111   b,  with the encryption being by using the private key SK 1 . The message  111   a  may be or include a message indicating a current identity of the first electronic device  100  from among messages registered at the distributed ledger. The private key SK 1  may be or include a private key that has been used to generate the message  111   a.  The signature σ 01_2  may be a result of encrypting a hash value of hashing the message  111   b,  with the encryption being by using the new private key. Functional formulas of the signature σ 01_1  and the signature σ 01_2  are illustrated in  FIG. 11 . 
       FIG. 10  is a conceptual diagram illustrating some example embodiments of a certificate of  FIG. 1 . 
     The first electronic device  100  of  FIG. 1  may generate a new certificate  120   b  for the purpose of registering the newly generated public key PK 01  at a distributed ledger. Because a public key of the first electronic device  100  to be registered at the distributed ledger changes, the certificate  120   b  may also be different from the certificate  120  of  FIG. 5 . However, the certificate  120   b  may be identical to the certificate  120  except for a portion associated with the public key of the first electronic device  100 . Thus, additional description will be omitted to avoid redundancy. 
     The public key value field of the certificate  120   b  may indicate “PK 01 ”, and not “PK 1 ”. Because identity information  121   b  included in the certificate  120   b  is changed, a certificate signature  122   b  may also be changed. 
       FIG. 11  is a diagram for describing a signature of a transaction of  FIG. 9 . 
     As described with reference to  FIG. 9 , the signature σ 01_1  may be a result of encrypting a hash value being a result of hashing the message  111   a  registered at the distributed ledger and a hash value HC 01  of the message  111   b,  with the encryption being based on the (previous) private key SK 1 . The signature σ 01_2  may be a result of encrypting a hash value being a result of hashing the message  111   b,  with the encryption being by using the new private key. 
       FIG. 12  is a flowchart for describing a method in which a node of  FIG. 1  verifies a transaction and a certificate. 
     The first electronic device  100  of  FIG. 1  may generate the transaction  110   b  of  FIG. 9  and the certificate  120   b  of  FIG. 10  for the purpose of registering the newly generated public key PK 01  at a distributed ledger. The node  410  of  FIG. 1  may receive a transaction and a certificate from the first electronic device  100 . In the description given with reference to  FIG. 12 , the transaction and the certificate that the node  410  receives are expressed as a new transaction and a new certificate. In a case where the transaction  110   b  and the certificate  120   b  are transmitted from the first electronic device  100  to the node  410  without an attack and/or corruption, the transaction and the certificate that the node  410  receives may be identical to the transaction  110   b  and the certificate  120   b.    
     In operation S 210 , the node  410  may receive the new transaction and the new certificate. 
     In operation S 220 , the node  410  may determine whether the signature σ 01_1  of the transaction  110   b  is valid. The node  410  may decrypt the signature σ 01_1  by using a public key PK 1 . The node  410  may obtain the public key PK 1  from the transaction  110   b.  The node  410  may hash both the message  111   a  of the transaction  110   a  registered at the distributed ledger and the hash value HC 01 . The node  410  may obtain the hash value HC 01  from the transaction  110   b.  The node  410  may compare the decrypted signature σ 01_1  and the hash value, with the hash value being a result of hashing the message  111   a  and the hash value HC 01 . When the decrypted signature σ 01_1  and the hash value being a result of hashing the message  111   a  and the hash value HC 01  coincide, the node  410  may determine that the signature σ 01_1  is valid. 
     When the node  410  determines that the signature σ 01_1  is invalid, operation S 260  may be performed. In operation S 260 , the node  410  may revoke the new transaction and the new certificate. 
     When the node  410  determines that the signature σ 01_1  is valid, operation S 230  may be performed. In operation S 230 , the node  410  may determine whether the signature σ 01_2  of the transaction  110   b  is valid. The node  410  may decrypt the signature σ 01_2  by using a public key PK 01 . The node  410  may obtain the public key PK 01  from the transaction  110   b.  An operation in which the node  410  determines whether the signature σ 01_2  is valid is substantially identical to operation (a) to operation (c) of  FIG. 6 , and thus, additional description will be omitted to avoid redundancy. 
     When the node  410  determines that the signature σ 01_2  is invalid, operation S 260  may be performed. In operation S 260 , the node  410  may revoke the new transaction and the new certificate. 
     When the node  410  determines that the signature σ 01_2  is valid, operation S 240  may be performed. In operation S 240 , the node  410  may determine whether information included in the message  111   b  and information included in the certificate  120   b  coincide. An operation in which the node  410  determines whether information included in the message  111   b  and information included in the certificate  120   b  coincide is substantially identical to operation (a) and operation (d) to operation (g) of  FIG. 6 , and thus, additional description will be omitted to avoid redundancy. 
     When the information included in the message  111   b  and the information included in the certificate  120   b  do not coincide, operation S 260  may be performed. In operation S 260 , the node  410  may revoke the new transaction and the new certificate. 
     When the information included in the message  111   b  and the information included in the certificate  120   b  coincide, operation S 250  may be performed. That the signature σ 01_1  and the signature σ 01_2  are valid and the information included in the message  111   b  and the information included in the certificate  120   b  coincide means/corresponds to at least the following: (1) the electronic device  100  generating the transaction  110   a  generates the transaction  110   b,  and (2) the transaction  110   b  and the certificate  120   b  are not attacked/corrupted while transmitted from the electronic device  100  to the node  410 . 
     In operation S 250 , the node  410  may generate a block including the new transaction. The node  410  may register the generated block at the distributed ledger. For example, a block indicating that a public key of the first electronic device  100  having the ID DID 1  is “PK 01 ” may be registered at the distributed ledger. 
       FIG. 13  is a conceptual diagram for indicating blocks registered at a distributed ledger on a blockchain network of  FIG. 1 . 
     As described with reference to  FIG. 12 , the node  410  of  FIG. 1  may generate a block  540  when the new transaction and the new certificate are successfully verified. The block  540  may be linked to the previously generated block  530 . That the block  540  is linked to the block  530  may mean that a header of the block  540  refers to a hash value of a header of the block  530 . 
     The block  540  may indicate that a public key of the first electronic device  100  having the ID DID 1  is changed from “PK 1 ” to “PK 01 ”. 
     There may be other information included in each of the blocks  510  to  530 ; however, example embodiments are not limited thereto. For example, there may include a proof-of-work included in each of the blocks  510  to  530 ; however, example embodiments are not limited thereto. Furthermore, the transaction data may be organized as a tree, for example as Merkle tree; however, example embodiments are not limited thereto. 
     Accordingly, the distributed ledger where the blocks  510  to  540  are registered may secure the following: a public key of the first electronic device  100  having the ID DID 1  is “PK 01 ”, a public key of the second electronic device  200  having the ID DID 2  is “PK 2 ”, and a public key of the third electronic device  300  having an ID DID 3  is “PK 3 ”. 
       FIG. 14  is a conceptual diagram illustrating some example embodiments of a transaction of  FIG. 1 . 
     The first electronic device  100  of  FIG. 1  may generate a transaction  110   c  for the purpose of revoking the public key PK 01  registered at the distributed ledger. 
     The transaction  110   c  may include a message  111   c  and a signature σ 01 . The message  111   c  may include “DID 1 ”, “REV”, “PK 01 ”, and “HC 01 ”. “DID 1 ”, “PK 01 ”, and “HC 01 ” indicate an ID of the first electronic device  100 , a public key of the first electronic device  100  registered at the distributed ledger, and a hash value being a result of hashing a certificate of the first electronic device  100 , respectively. The first electronic device  100  may hash the certificate illustrated in  FIG. 15  to generate a hash value HC 01 . The signature σ 01  may be a result of encrypting a result of hashing the message  111   c,  with the encryption being by using a new private key. 
       FIG. 15  is a conceptual diagram illustrating some example embodiments of a certificate of  FIG. 1 . 
     The first electronic device  100  of  FIG. 1  may generate a certificate  120   c  for the purpose of revoking the public key PK 01  registered at the distributed ledger. Because the public key PK 01  included in the transaction  110   c  of  FIG. 14  is identical to the public key PK 01  included in the transaction  110   b  of  FIG. 9 , the certificate  120   c  may be identical to the certificate  120   b  of  FIG. 10 . Thus, additional description will be omitted to avoid redundancy. 
       FIG. 16  is a flowchart for describing a method in which a node of  FIG. 1  verifies a transaction and a certificate. 
     The first electronic device  100  of  FIG. 1  may generate the transaction  110   c  of  FIG. 14  and the certificate  120   c  of  FIG. 15  for the purpose of revoking the public key PK 01  registered at the distributed ledger. The node  410  of  FIG. 1  may receive a transaction and a certificate from the first electronic device  100 . In the description given with reference to  FIG. 16 , the transaction and the certificate that the node  410  receives are expressed as a new transaction and a new certificate. In a case where the transaction  110   c  and the certificate  120   c  are transmitted from the first electronic device  100  to the node  410  without an attack/corruption, the transaction and the certificate that the node  410  receives may be identical to the transaction  110   c  and the certificate  120   c.    
     The node  410  may verify the new transaction and the new certificate. Operations in which the node  410  verifies the new transaction and the new certificate are substantially identical to the operations (including operation (a) to operation (g)) described with reference to  FIG. 6 . Thus, additional description will be omitted to avoid redundancy. 
     In operation S 310 , the node  410  may receive the new transaction and the new certificate. 
     In operation S 320 , the node  410  may verify the new transaction and the new certificate. The node  410  may perform operation (a) to operation (g) of  FIG. 6  on the new transaction and the new certificate. 
     When the new transaction and the new certificate are successfully verified, operation S 330  may be performed. In operation S 330 , the node  410  may generate a block including the new transaction. The node  410  may register the generated block at the distributed ledger, for example by broadcasting the block on the P2P. That is, a block indicating that there is revoked a transaction meaning that a public key of the first electronic device  100  is “PK 01 ” may be registered at the distributed ledger. 
     When the verification of the new transaction and the new certificate fails, operation S 340  may be performed. In operation S 340 , the node  410  may revoke the new transaction and the new certificate. 
       FIG. 17  is a conceptual diagram for indicating blocks registered at a distributed ledger on a blockchain network of  FIG. 1 . 
     As described with reference to  FIG. 16 , the node  410  of  FIG. 1  may generate a block  550  when the new transaction and the new certificate are successfully verified. The block  550  may be linked to the previously generated block  540 . 
     There may be other information included in each of the blocks  510  to  530 ; however, example embodiments are not limited thereto. For example, there may include a proof-of-work included in each of the blocks  510  to  530 ; however, example embodiments are not limited thereto. Furthermore, the transaction data may be organized as a tree, for example as Merkle tree; however, example embodiments are not limited thereto. 
     The block  550  may indicate that there is revoked a transaction meaning that a public key of the first electronic device  100  having the ID DID 1  is “PK 01 ”. That is, the blocks  510 ,  540 , and  550  may indicate that a public key of the first electronic device  100  having the ID DID 1  is “PK 1 ”. 
     Accordingly, the distributed ledger where the blocks  510  to  550  are registered may secure the following: a public key of the first electronic device  100  having the ID DID 1  is “PK 1 ”, a public key of the second electronic device  200  having the ID DID 2  is “PK 2 ”, and a public key of the third electronic device  300  having an ID DID 3  is “PK 3 ”. 
       FIG. 18  is a conceptual diagram for describing a procedure in which electronic devices in a cryptographic communication system prove their own identities. 
     As described with reference to  FIGS. 1 to 17 , after the verification of the node  410 , identity information of the electronic devices  100  and  200  may be registered at the distributed ledger of the blockchain network  400 . In this case, the identities of the electronic devices  100  and  200  may be guaranteed and/or secured by the blockchain network  400 . 
     The electronic devices  100  and  200  may deal with/communicate with each other. Before dealing with each other, each of the electronic devices  100  and  200  may check an identity of a counterpart. Because an operation of the first electronic device  100  and an operation of the second electronic device  200  are symmetrical, the operation of the first electronic device  100  is mainly described with reference to  FIG. 18 . 
     For a transaction, the first electronic device  100  may request the second electronic device  200  to prove an identity of the second electronic device  200 . The second electronic device  200  may output a certificate  220  depending on the request of the first electronic device  100 . The certificate  220  may be/include a certificate indicating the identity of the second electronic device  200 . The second electronic device  200  may generate a private key SK 2 , a public key PK 2 , a transaction  210 , and the certificate  220 . 
     When the certificate  220  is received, the first electronic device  100  may request the transaction  210  including identity information of the second electronic device  200  from the blockchain network  400 . The blockchain network  400  may search the distributed ledger for a block indicating the identity information of the second electronic device  200 , depending on the request of the first electronic device  100 . The blockchain network  400  may output the block indicating the identity information of the second electronic device  200  and/or the transaction  210  included in the block. 
     The first electronic device  100  may receive the transaction  210 . The first electronic device  100  may verify the certificate  220  received from the second electronic device  200  and the transaction  210  received from the blockchain network  400 . That the verification succeeds may mean the identity of the second electronic device  200  is verified. 
     The second electronic device  200  may verify the identity of the first electronic device  100  in a method similar to the method performed by the first electronic device  100 . 
     In a case where both the verification in the first electronic device  100  and the verification in the second electronic device  200  succeed, the first electronic device  100  and the second electronic device  200  may deal with each other. 
     For example, the electronic devices  100  and  200  may verify counterpart&#39;s identities by using the distributed ledger of the blockchain network  400  without needing to verify counterpart&#39;s identities through layers of certification authorities. Accordingly, even though the number of electronic devices in the cryptographic communication system  10  increases, a time taken to verify an identity may not be long. 
       FIG. 19  is a flowchart for describing a procedure in which electronic devices in a cryptographic communication system prove their own identities. 
     The electronic devices  100  and  200  and the blockchain network  400  may communicate based on a secure sockets layer (SSL) and/or a transport layer security (TLS). The SSL/TLS may be or include a standard cryptographic protocol for protecting data exchanged when communicating on the Internet. Because the SSL/TLS is a cryptographic manner of a transport layer, the SSL/TLS may be available regardless of a protocol kind of an application layer, such as FTP and/or XMPP, as well as HTTP. As described with reference to  FIG. 19 , the communication between the electronic devices  100  and  200  may be defined as a structure compatible with a TLS 1.2 handshake protocol. However, inventive concepts is not limited thereto. For example, the communication may be defined as a structure compatible with a protocol using a certificate such as TLS 1.3. 
     An operation in which the electronic devices  100  and  200  verify counterpart&#39;s identities, make mutual authentication, and establish a cryptographic channel, by using the SSL/TLS, is described with reference to  FIG. 19 . In the description given with reference to  FIG. 19  and in  FIG. 19 , a “client” and a “server” may indicate the first electronic device  100  and the second electronic device  200 , respectively. 
     In operation S 410  and operation S 415 , the first electronic device  100  and the second electronic device  200  may transmit/receive basic information through ‘hello’ messages. For example, the first electronic device  100  may transmit the following information through the ‘hello’ message: an authentication algorithm, a key exchange algorithm, a hash algorithm, and a cryptographic algorithm that the first electronic device  100  supports. The second electronic device  200  may transmit the following information through the ‘hello’ message: an authentication algorithm, a key exchange algorithm, a hash algorithm, and a cryptographic algorithm that the second electronic device  200  supports. 
     In operation S 420 , the second electronic device  200  may output the certificate  220 . The certificate  220  may include information about the public key PK 1  of the second electronic device  200 . 
     When the certificate  220  is received from the second electronic device  200 , in operation S 425 , the first electronic device  100  may request the blockchain network  400  to verify an identity of the second electronic device  200 . In detail, the first electronic device  100  may request the transaction  210  indicating the identity of the second electronic device  200  from the blockchain network  400 . For example, the first electronic device  100  may transmit a “Lookup” command to the blockchain network  400 . The first electronic device  100  and the second electronic device  200  may communicate with different nodes. That is, the first electronic device  100  may request the node  410  of the blockchain network  400  to verify the identity of the second electronic device  200 , and the second electronic device  200  may request a node  420  of the blockchain network  400  to verify the identity of the first electronic device  100 . 
     Depending on the request of the first electronic device  100 , in operation S 430 , the blockchain network  400  may look up the transaction  210  indicating the identity of the second electronic device  200  at the distributed ledger. Accordingly, the blockchain network  400  may look up in the order of recently registered block. 
     In operation S 435 , the blockchain network  400  may transmit the found transaction  210  to the first electronic device  100 . 
     In operation S 440 , the first electronic device  100  may verify the transaction  210  received from the blockchain network  400  and the certificate  220  received from the second electronic device  200 . The verification in the first electronic device  100  is substantially identical to the verification through operation (a) to operation (g) of  FIG. 6 . Thus, additional description will be omitted to avoid redundancy. 
     An operation in which the first electronic device  100  obtains the transaction  210  registered at the distributed ledger by using the blockchain network  400  is described with reference to operation S 425  to operation S 435 . However, inventive concepts is not limited thereto. The first electronic device  100  may store a part of blocks registered at the distributed ledger. Accordingly, the first electronic device  100  may automatically loop up a block without requesting the transaction  210  from the blockchain network  400 . A method in which the first electronic device  100  automatically looks up a block will be described with reference to  FIG. 20 . 
     In operation S 445 , the second electronic device  200  may send a server key exchange message when necessary/desirable to exchange a key with the first electronic device  100 . 
     In operation S 450  and operation S 455 , the second electronic device  200  may request the certificate  120   a  from the first electronic device  100  and may terminate a server hello. 
     In operation S 460 , the first electronic device  100  may output the certificate  120   a  depending on the request of the second electronic device  200 . The certificate  120   a  may include information about the public key PK 2  of the first electronic device  100 . 
     When the certificate  120   a  is received from the first electronic device  100 , in operation S 465 , the second electronic device  200  may request the blockchain network  400  to verify the identity of the first electronic device  100 . In detail, the second electronic device  200  may request the transaction  110   a  indicating the identity of the first electronic device  100  from the blockchain network  400 . For example, the second electronic device  200  may transmit the “Lookup” command to the blockchain network  400 . 
     Depending on the request of the second electronic device  200 , in operation S 470 , the blockchain network  400  may look up the transaction  110   a  indicating the identity of the first electronic device  100  at the distributed ledger. 
     In operation S 475 , the blockchain network  400  may transmit the found transaction  110   a  to the second electronic device  200 . 
     An operation in which the second electronic device  200  obtains the transaction  110   a  registered at the distributed ledger by using the blockchain network  400  is described with reference to operation S 465  to operation S 475 . However, inventive concepts is not limited thereto. As described above, the second electronic device  200  may also store a part of blocks registered at the distributed ledger. In this case, the second electronic device  200  may automatically loop up a block without requesting the transaction  110   a  from the blockchain network  400 . A method in which the second electronic device  200  automatically looks up a block will be described with reference to  FIG. 20 . 
     In operation S 480 , the second electronic device  200  may verify the transaction  110   a  received from the blockchain network  400  and the certificate  120   a  received from the first electronic device  100 . The verification in the second electronic device  200  is substantially identical to the verification through operation (a) to operation (g) of  FIG. 6 . Thus, additional description will be omitted to avoid redundancy. 
     In operation S 485 , the first electronic device  100  may send a client key exchange message when necessary/desirable to exchange a key with the second electronic device  200 . 
     In operation S 490 , the first electronic device  100  may transmit a certificate valid message for the purpose of providing notification that the identity of the second electronic device  200  is verified. 
     To provide notification that a handshake protocol is normally finished, in operation S 495 , the first electronic device  100  and the second electronic device  200  may transmit complete messages each other. 
     After determining that the handshake protocol is normally completed, the first electronic device  100  and the second electronic device  200  may start communication safely through the cryptographic channel. 
       FIG. 20  is a conceptual diagram for describing a method in which electronic devices automatically search for a block. 
     The electronic devices  100  and  200  may store a part of the blocks  510  to  550  registered at the distributed ledger. However, inventive concepts are not limited thereto. For example, the electronic devices  100  and  200  may store all the blocks  510  to  550  registered at the distributed ledger. Because the second electronic device  200  provides substantially the same operations as the first electronic device  100 , the operation of the first electronic device  100  is mainly described with reference to  FIG. 20 . 
     The first electronic device  100  may store the blocks  530  to  550 . The blocks  530  and  550  may be blocks, which are registered the most lately, from among the blocks  510  to  550 . The first electronic device  100  may search the blocks  530  to  550  for the purpose of finding the block  520  indicating the identity of the second electronic device  200 . The first electronic device  100  may search the blocks  530  to  550  in the order of the most recently registered block. 
     In a case where the first electronic device  100  fails to look up the block  520  indicating the identity of the second electronic device  200  in the blocks  530  to  550 , the first electronic device  100  may additionally download the blocks  510  and  520  from the distributed ledger. The first electronic device  100  may search the blocks  510  to  520  to look up the block  520 . 
       FIG. 21  is a conceptual diagram for describing how to extend a public key registered at a distributed ledger. 
     A user that uses the first electronic device  100  may additionally use first electronic devices  100   a  and  100   b.  The user may set IDs DID 1a  and DID 1a  of the first electronic devices  100   a  and  100   b  to be identical to the ID DID 1  of the first electronic device  100 . That is, the first electronic device  100  may share the ID DID 1a  with the first electronic devices  100   a  and  100   b.  However, private keys SK 1a  and SK 1b , public keys PK 1a  and PK 1b , and certificates Cert 1a  and Cert 1b  of the first electronic devices  100   a  and  100   b  may be different from the private key SK 1 , the public key PK 1 , and the certificate Cert 1  of the first electronic device  100 . 
     In a case where the identity information of the first electronic device  100  is already registered at the distributed ledger, the first electronic devices  100   a  and  100   b  may use an “EXT” command for the purpose of registering identity information of the first electronic devices  100   a  and  100   b.    
     In detail, in the case of intending to register the identity information of the first electronic device  100   a  in a state where the identity information of the first electronic device  100  is already registered at the distributed ledger, the first electronic device  100  or the first electronic device  100   a  may generate a transaction including the “EXT” command. The transaction including the “EXT” command will be more fully described with reference to  FIG. 22 . The first electronic device  100  or the first electronic device  100   a  may transmit a transaction including the “EXT” command and a certificate indicating the identity of the first electronic device  100   a  to the node  410  of  FIG. 1 . 
     The node  410  may verify the transaction including the “EXT” command and the certificate indicating the identity of the first electronic device  100   a;  if successful, the node  410  may generate a block including a transaction including the “EXT” command. In this case, two public keys PK 1  and PK 1a  may be registered with regard to one ID DID 1 . 
       FIG. 22  is a conceptual diagram illustrating some example embodiments of a transaction of  FIG. 1 . 
     A transaction  110   d  may include a message  111   d  and a signature σ 1a . The message  111   d  may include “DID 1 ”, “EXT”, “{PK 1 , PK 1a }”, and “HC 1a ”. “DID 1 ”, “PK 1 ”, “PK 1a ”, and “HC 1a ” indicate an ID of the first electronic device  100   a,  a public key of the first electronic device  100  registered at the distributed ledger, a public key of the first electronic device  100   a  to which the first electronic device  100  is extended, and a hash value being a result of hashing a certificate of the first electronic device  100   a,  respectively. 
     The signature σ 1a  may include a signature σ 1a_1  and a signature σ 1a_2 . The signature σ 1a_1  may be a result of encrypting a hash value being a result of hashing the message  111   a  registered at the distributed ledger and a hash value HC 1a  of the message  111   d,  by using the private key SK 1 . The message  111   a  may be a message indicating the identity of the first electronic device  100  from among messages registered at the distributed ledger. The private key SK 1  may be a private key of the first electronic device  100 . The signature σ 1a_2  may be a result of encrypting a hash value being a result of hashing the message  111   d  by using the private key SK 1a . The private key SK 1a  may be a private key of the first electronic device  100   a.    
     Because the first electronic device  100  and the first electronic device  100   a  share identity information each other, as well as the first electronic device  100   a,  the first electronic device  100  may generate the transaction  110   d.    
     The first electronic device  100   a  may generate a certificate indicating an identity of the first electronic device  100   a.  The certificate indicating the identity of the first electronic device  100   a  is identical to the certificate  120   a  of  FIG. 5 , and thus, additional description will be omitted to avoid redundancy. 
     The first electronic device  100  or the first electronic device  100   a  may transmit the transaction  110   d  and the certificate indicating the identity of the first electronic device  100   a  to the node  410 . The node  410  may verify the transaction  110   d  and the certificate of the first electronic device  100   a.  A method in which the node  410  verifies the transaction  110   d  and the certificate of the first electronic device  100   a  is similar to operation S 220  to operation S 240  described with reference to  FIG. 12 . Thus, additional description will be omitted to avoid redundancy. 
       FIG. 23  is a block diagram illustrating a cryptographic communication system of  FIG. 1 . 
     An electronic device  1000  may include an interface  1100 , a memory  1200 , and a processor  1300 . However, all the components illustrated in  FIG. 23  are not essential. The electronic device  1000  may be implemented with more than the components illustrated in  FIG. 23  or may be implemented with less than the components illustrated in  FIG. 23 . Below, the components are described. 
     According to some example embodiments, the interface  1100  may perform communication with an external device. In detail, the interface  1100  may, through a wired and/or wireless connection, connect to a network to perform communication with the external device. Here, the external device may be a server, a smartphone, a tablet, a PC, a computing device, etc. The interface  1100  may include a communication module supporting one of various wired/wireless communication schemes. For example, the communication module may be in the form of a chipset or may be a sticker/barcode (e.g., a sticker including an NFC tag) including information necessary/desirable for communication. Also, the communication module may be a short range communication module or a wired communication module. 
     According to some example embodiments, the memory  1200  may include a storage medium that is implemented in at least one of the following memory types: a flash memory, a hard disk, a multimedia card micro, a card type memory (e.g., SD memory, XD memory, etc.), a RAM (Random Access Memory), an SRAM (Static Random Access Memory), a ROM (Read-Only Memory), an EEPROM (Electrically Erasable Programmable Read-Only Memory), a PROM (Programmable Read-Only Memory), a magnetic memory, a magnetic disc, an optical disc, etc. In the case where the electronic device  1000  is the node  410  of  FIG. 1 , the memory  1200  may store at least one program for executing an operating method of the node  410  on a blockchain network, which distributes and manages a ledger at which a transaction of cryptocurrency is registered. In a case where the electronic device  1000  is the first electronic device  100  of  FIG. 1 , the memory  1200  may store program codes for executing a blockchain wallet. At least one program stored in the memory  1200  may be divided into a plurality of modules based on functions. Electronic devices and/or extended electronic devices such as electronic devices  200 ,  300 ,  400 ,  1000 ,  1300 , etc. and/or a nodes such as node  410  may include a processor and/or processing circuitry such as hardware including logic circuits; a hardware/software combination such as a processor and/or processing circuitry executing software; or a combination thereof. For example, the processing circuitry more specifically may include, but is not limited to, a central processing unit (CPU), an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a System-on-Chip (SoC), a programmable logic unit, a microprocessor, application-specific integrated circuit (ASIC), etc. 
     According to some example embodiments, the processor  1300  may control the overall operations of the electronic device  1000  and may include at least one processor such as a central processing unit (CPU). The processor  1300  may include at least one processor specialized to correspond to each function or may be one integrated processor. In a case where the electronic device  1000  is the node  410 , the processor  1300  may perform a verification operation on a transaction and a certificate by using pieces of information stored in the memory  1200 . In the case where the electronic device  1000  is the first electronic device  100  of  FIG. 1 , the processor  1300  may execute a blockchain wallet and may generate a private key, a public key, a transaction, and a certificate. 
     Inventive concepts may guarantee identities of electronic devices in a cryptographic communication system based on a blockchain network without several layers of certification authorities. Alternatively or additionally, even though the number of electronic devices in the cryptographic communication system increases, a time taken to verify an identity may not be long. Alternatively or additionally, the cryptographic communication system according to some example embodiments of inventive concepts is compatible with an existing standard protocol. Alternatively or additionally, security of certification may be improved, for example, because certificates may be recorded on a blockchain network that does not include a root/administrator. 
     While inventive concepts has been described with reference to example embodiments thereof, it will be apparent to those of ordinary skill in the art that various changes and modifications may be made thereto without departing from the spirit and scope of inventive concepts as set forth in the following claims.