Electronic device for cryptographic communication and cryptographic communication system

Abstract

An electronic device of a first domain, the first domain being a public key infrastructure (PKI) domain based on a blockchain, includes an interface configured to receive, from a first entity belonging to a second domain that is a PKI domain based on a certification authority (CA), a first certificate of the first entity and a second certificate of a second entity, wherein the second entity is an upper node of the first entity and is a node of a blockchain; a memory configured to store the first certificate and the second certificate; and a processor configured to look up, based on an identifier of the second entity, a transaction corresponding to the second entity at a distributed ledger of the first domain, verify the second certificate based on the transaction, and verify the first certificate based on the second certificate.

Description

[0001] Cross-references to related applications

[0002] This application is based on and claims priority to Korean Patent Application No. 10-2020-0039126, filed on March 31, 2020, with the Korean Intellectual Property Office, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The embodiments described herein relate to cryptographic communication systems, and more specifically, to electronic devices in a blockchain-based public key infrastructure (PKI) domain, electronic devices in a certification authority-based PKI domain, and cryptographic communication systems that include such electronic devices. Background Technology

[0004] Public-key cryptography uses two associated encryption keys (specifically, a public key and a private key). The private key can be disclosed only to the user who possesses it, while the public key can be disclosed to anyone. Users can use either the public or private key to encrypt or decrypt messages.

[0005] Public-key cryptography is used in PKI to protect and manage public keys used for message encryption and electronic signatures. A PKI is a secure system for issuing and using authorized certificates. Users in a PKI can identify themselves using authorized certificates issued by a Certification Authority (CA). A PKI is a centralized system where transactions are conducted by the CA.

[0006] In centralized PKI, if the root CA is attacked, the authorization certificates of all users in the PKI must be revoked. Therefore, blockchain-based PKIs are increasingly being developed that can secure user identities by verifying certificates at nodes in the blockchain network without multiple layers of CAs. Summary of the Invention

[0007] Embodiments of this invention provide electronic devices in a blockchain-based PKI domain, which enable cryptographic communication with different domains by using a blockchain-based PKI domain, electronic devices in a CA-based PKI domain, and a cryptographic communication system including these electronic devices.

[0008] According to an embodiment, an electronic device is provided as a first domain of a blockchain-based PKI domain, comprising: an interface configured to receive a first certificate of the first entity and a second certificate of a second entity belonging to a second domain of a Certification Authority (CA)-based PKI domain, wherein the second entity is an upper-level node of the first entity and a node of the blockchain; a memory configured to store the first certificate and the second certificate; and a processor configured to look up a transaction corresponding to the second entity in a distributed ledger of the first domain based on an identifier of the second entity, verify the second certificate based on the transaction, and verify the first certificate based on the second certificate.

[0009] According to an embodiment, an electronic device is provided as a first domain of a CA-based PKI domain, comprising: an interface configured to receive a first certificate from a first entity belonging to a second domain of a blockchain-based PKI domain, send a verification request and the first certificate to a second entity, the second entity being an upper-layer node of the electronic device registered at a blockchain network of the second domain, and receive a response message based on the verification request from the second entity; a memory configured to store a second certificate of the second entity; and a processor configured to verify the response message based on the second certificate.

[0010] According to an embodiment, a cryptographic communication system is provided, comprising: a first electronic device belonging to a first domain and registered at a distributed ledger in the first domain, the first domain being a blockchain-based Public Key Infrastructure (PKI) domain; a second electronic device belonging to a second domain, the second domain being a Certificate Authority (CA)-based PKI domain; and a CA, the CA being registered at the distributed ledger and being an upper-layer node of the second electronic device, wherein, upon a request from the second electronic device, the CA is configured to: authenticate the first electronic device based on a first certificate of the first electronic device and a first transaction corresponding to the first electronic device registered at the distributed ledger, and wherein the first electronic device is configured to authenticate the second electronic device based on a second certificate of the CA, a second transaction corresponding to the CA registered at the distributed ledger, and a third certificate of the second electronic device. Attached Figure Description

[0011] The above and other objects and features will become clear from the detailed description of exemplary embodiments therein with reference to the accompanying drawings.

[0012] Figure 1 This is a block diagram of a cryptographic communication system according to an embodiment.

[0013] Figure 2 It is according to the embodiment for use in Figure 1A flowchart illustrating the method for registering as a node in a blockchain network within a cryptographic communication system.

[0014] Figure 3 This is a description based on embodiments. Figure 1 and Figure 2 A conceptual diagram of the certificate described in the document.

[0015] Figure 4 This is a description based on embodiments. Figure 1 and Figure 2 A conceptual diagram of the transaction described in the document.

[0016] Figure 5 This is a detailed illustration based on the embodiments. Figure 2 The flowchart for operation S130.

[0017] Figure 6 This is a description based on embodiments. Figure 1 A block diagram illustrating the process of mutual authentication performed by electronic devices in a cryptographic communication system.

[0018] Figure 7 This is a flowchart of a method for performing mutual authentication between entities belonging to a CA-based PKI domain and entities belonging to a blockchain-based PKI domain, according to an embodiment.

[0019] Figure 8 This is a detailed illustration based on the embodiments. Figure 7 The flowchart of operation S210.

[0020] Figure 9 This is a detailed illustration based on the embodiments. Figure 7 The flowchart for operation S220.

[0021] Figure 10 This is an illustration based on an embodiment. Figure 1 and Figure 6 A flowchart detailing the process by which entities in a cryptographic communication system perform mutual authentication.

[0022] Figure 11 This is an illustration based on an embodiment. Figure 1 and Figure 6 A block diagram of an electronic device. Detailed Implementation

[0023] Embodiments of the inventive concept will now be described clearly and in detail with reference to the accompanying drawings to enable those skilled in the art to implement the embodiments. It should be noted that the embodiments described herein are exemplary embodiments, and therefore, the inventive concept can be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein.

[0024] Figure 1This is a block diagram of a cryptographic communication system according to an embodiment. Figure 1 In the cryptographic communication system 1000, public key infrastructure (PKI) based on certification authorities (CAs) and blockchain-based PKI are compatible with each other. Here, it can be understood that the first domain 100 is a blockchain-based PKI domain, and the second domain 200 and the third domain 300 are CA-based PKI domains. The first to third domains 100, 200, and 300 can be different domains.

[0025] Referring to the first domain 100, the cryptographic communication system 1000 includes a blockchain network 110 for blockchain-based PKI. Here, "blockchain" can refer to distributed ledger technology that allows nodes in the blockchain network 110 to collaboratively record and manage a ledger that records transaction information. The distributed ledger 111 can be distributed across a P2P network, rather than in a central server of a specific institution, and implemented within the blockchain network 110. All nodes in the P2P network can provide resources (e.g., processing power, storage space, data, and network bandwidth) to each other without interference from a central node.

[0026] Here, "node" can refer to a component in the blockchain network 110. A node corresponds to an electronic device connected through the blockchain network 110 (e.g., the first to third electronic devices ED1, ED2, and ED3, and the first intermediate CA ICA1 and the second intermediate CA ICA2, which will be described later). That is, the blockchain network 110 represents the connection relationship of electronic devices sharing transactions through the distributed ledger 111. For example, a node or electronic device can be, but is not limited to, a dedicated computer, a general-purpose computer, a supercomputer, a mainframe computer, a personal computer (PC), a smartphone, a tablet PC, a smart home appliance, etc.

[0027] The following description will be based on nodes corresponding to, but not limited to, electronic devices, but nodes can be various entities. For example, cryptographic communication may be required between intellectual property (IP) within a System-on-Chip (SoC). In this case, a cryptographic communication system 1000 can be implemented within the SoC. Figure 1 The IP address can be an entity used to perform cryptographic communication.

[0028] The first to third electronic devices ED1, ED2, and ED3 of the first domain 100 of the cryptographic communication system 1000 can execute blockchain wallets. Generally, a "blockchain wallet" refers to an electronic device that stores value electronically and supports online or offline transactions. The following description of a blockchain-based PKI will be based on the operation of the first electronic device ED1. The operations described below can also be performed at any other node, such as the second electronic device ED2 or the third electronic device ED3.

[0029] The first electronic device ED1 can generate private keys, public keys, transactions, and certificates using a blockchain wallet, and the blockchain wallet can be a program used in the aforementioned generation operation. The blockchain wallet can be implemented at the first electronic device ED1 using software including program code or hardware storing program code. The private key may exist only in the first electronic device ED1, while the public key may exist in all electronic devices in the first domain 100 (e.g., the second electronic device ED2 and the third electronic device ED3).

[0030] The certificate generated by the first electronic device ED1 can be a file indicating the identity of the first electronic device ED1. The certificate may include information such as the identifier (ID) of the first electronic device ED1 and the public key of the first electronic device ED1. (See reference...) Figure 3 Provide a more comprehensive description of the certificate.

[0031] A transaction generated by the first electronic device ED1 can be a string containing information about a transaction requested by the first electronic device ED1 from the blockchain network 110. This transaction may include information allowing the first electronic device ED1 to register at a node of the blockchain network 110. The transaction may include the ID of the first electronic device ED1, information about the public key of the first electronic device ED1, and the command requested by the first electronic device ED1 from the blockchain network 110. (See reference...) Figure 4 Provide a more comprehensive description of the transaction.

[0032] To register a public key on blockchain network 110, the first electronic device ED1 can output a transaction and certificate to blockchain network 110. Nodes (or electronic devices) connected to blockchain network 110 can perform verification operations on the output transactions and certificates. The node that completes the verification operation can generate a block BLK1 containing the transaction. The generated block BLK1 can be added to distributed ledger 111, and any other node can share the transaction through distributed ledger 111. Through the above registration, a public key can be registered. Figure 1 The first to fifth blocks, BLK1, BLK2, BLK3, BLK4, and BLK5, are added to the distributed ledger 111 and can form a blockchain. Each node can store at least a portion of blocks BLK1 to BLK5.

[0033] Nodes connected to blockchain network 110 can perform cryptographic communication based on transactions registered at distributed ledger 111. For example, a first electronic device ED1 can encrypt a message using its private key. In this case, any other node (e.g., a second electronic device ED2) can decrypt the encrypted message using its public key registered at distributed ledger 111. Encrypting a message with a private key can refer to signing the message using the private key. The first electronic device ED1 can encrypt messages using various methods such as Diffie-Hellman key exchange, Rivest-Shamir-Adleman (RSA), and Rabin encryption, but the encryption methods are not limited to these.

[0034] Referring to the second domain 200, the cryptographic communication system 1000 includes: a root CA RCA1 based on a CA-based PKI; an intermediate CA ICA1; CAs (CA1, CA2, and CA3); and electronic devices ED4, ED5, and ED6. The root CA RCA1 can be a trust anchor in the second domain 200, and the certificate of the root CA RCA1 can be self-signed using the private key of the root CA RCA1. The root CA RCA1 can issue certificates for the intermediate CA ICA1. The intermediate CA ICA1 can issue certificates for CAs CA1 through CA3. Each of CAs CA1 through CA3 can issue certificates for electronic devices ED4 through ED6. That is, the second domain 200 of the cryptographic communication system 1000 can perform cryptographic communication through a hierarchical trust authentication chain.

[0035] Referring to the third domain 300, the cryptographic communication system 1000 includes: a root CA RCA2 for a CA-based PKI; an intermediate CAICA2; CAs (CA4, CA5, and CA6); and electronic devices ED7, ED8, and ED9. Similar to the second domain 200, the third domain 300 of the cryptographic communication system 1000 can perform cryptographic communication through a hierarchical trust authentication chain.

[0036] Electronic devices ED4 through ED6 belonging to the second domain 200 can mutually verify their certificates and the public keys included in the certificates through a certificate chain formed by CAs CA1 through CA3 and the intermediate CA ICA1. However, in the absence of an upper-level CA that allows the second domain 200 and the third domain 300 to perform mutual authentication, electronic devices ED4 through ED6 belonging to the second domain 200 may be unable to perform cryptographic communication with electronic devices ED7 through ED9 belonging to the third domain 300. This problem may also arise in the relationship between the first domain 100 and the second domain 200, as well as in the relationship between the first domain 100 and the third domain 300.

[0037] According to an embodiment, the cryptographic communication system 1000 can register a first intermediate CA ICA1 (as an intermediate CA in the second domain 200) and a second intermediate CA ICA2 (as an intermediate CA in the third domain 300) as nodes of the blockchain network 110. In this case, electronic devices ED1 to ED3 of the first domain 100, electronic devices ED4 to ED6 of the second domain 200, and electronic devices ED7 to ED9 of the third domain 300 can perform cryptographic communication with each other through the blockchain network 110. However, mutual authentication between electronic devices ED4 to ED6 of the second domain 200 and electronic devices in any other domain can be performed by the first intermediate CA ICA1. This is because electronic devices ED4 to ED6 of the second domain 200 are not members of the blockchain network 110. The operation of cryptographic communication for different domains will be described in detail later.

[0038] Figure 2 It is used in Figure 1 A flowchart illustrating the method for registering as a node in a blockchain network within a cryptographic communication system. Figure 2 The operation represents the second field 200. Figure 1 The first intermediate CA ICA1 can be registered as a node in blockchain network 110, and the second intermediate CA ICA2, representing the third domain 300, can also be registered as a node in blockchain network 110. For ease of description, the first intermediate CA ICA1 will be described in detail. Figure 2 Each operation.

[0039] In operation S110, the first intermediate CA ICA1 can generate an identifier ID and a public and private key pair. This ID can be the identifier of the first intermediate CA ICA1 and can be included in the certificate. The public key of the first intermediate CA ICA1 can be... Figure 1 The nodes of the blockchain network 110 are public and included in the certificate. The private key of the first intermediate CA ICA1 can be public only to the first intermediate CA ICA1.

[0040] In operation S120, the first intermediate CA ICA1 can generate a certificate based on the ID and the public and private key pair generated in operation S110. The first intermediate CA ICA1 can generate a certificate to be signed, including the ID, public key, and information about the certificate (i.e., identity information). This information may include the certificate issuer, the certificate's validity period, and additional private information. The first intermediate CA ICA1 can generate a certificate by self-signing the identity information using its private key. For example, the first intermediate CA ICA1 can encrypt the hash value of the identity information using its private key to generate a signature on the identity information. The first intermediate CA ICA1 can generate certificates conforming to the X.509 certificate format, but the certificate format is not limited to this.

[0041] In operation S130, the first intermediate CA ICA1 may generate a transaction for the purpose of registering the public key corresponding to the first intermediate CA ICA1. This transaction may include a registration message and a signature for that registration message. The registration message may include an ID, a registration command, a public key, and a hash value of the certificate. The signature for the registration message can be generated by encrypting the hash value using a private key.

[0042] In operation S130, the first intermediate CA ICA1 can output a transaction and certificate to the blockchain network 110 to request registration. Nodes of the blockchain network 110 can check whether the first intermediate CA ICA1 has registered. To do this, the node can verify the signature of the received transaction, the signature of the received certificate, and the ID, public key, and hash value identifier between the certificate and the transaction. When it is determined that it is possible to register the first intermediate CA ICA1, the node can add the transaction to the distributed ledger 111 as a new block (e.g., ...). Figure 1 The second block (BLK2). Nodes in blockchain network 110 can share the updated distributed ledger 111.

[0043] Figure 3 It is used to describe Figure 1 and Figure 2 A conceptual diagram of the certificate described herein. (See reference.) Figure 3 The certificate CT can include the certificate to be signed (i.e., the identity information tbsCT) and the signing SNc. The identity information tbsCT can include the identifier ID, the public key PK, and information IC about the certificate CT.

[0044] For example, a certificate CT can conform to the X.509 certificate format. Here, X.509 is the ITU-T (International Telecommunication Union Telecommunication Standard) standard for public key certificates and authentication algorithms based on PKI. An X.509 certificate can represent an Internet Engineering Task Force (IETF) PKI certificate and a Client Responsible Individual (CRI) profile of the X.509 v.3 certificate standard, and may be defined in [RFC 3280]. However, the inventive concept is not limited thereto. For example, a first intermediate CA ICA1 can generate certificates conforming to any other authentication algorithm standard.

[0045] The identifier (ID) can be identity information about the electronic device corresponding to the certificate (CT). For example, if the first intermediate CA (ICA1) wants to register its public key (PK) on blockchain network 110, the device issuing the certificate CT is the first intermediate CA (ICA1). Therefore, in an X.509 certificate, the ID of the first intermediate CA (ICA1) can appear in the subject field indicating the owner of the certificate CT.

[0046] Once the public key key (PK) is registered with blockchain network 110, it can be made public to nodes. The public key key can be used for verification by nodes of blockchain network 110. In an X.509 certificate, the public key key can appear in the public key information field.

[0047] The Information Core (IC) for a Certificate Certificate (CT) can include various information associated with the CT. In an X.509 certificate, the IC for the CT can include the hash algorithm and / or hash function used for the signature present in the Signature Algorithm ID field, the validity period present in the Validity Period field, information about the CA that issued the CT present in the Publisher field, and private information present in the Extension fields.

[0048] A signature SNc can be generated by encrypting the hash value of the identity information tbsCT using a private key. That is, the hash value generated by applying the identity information tbsCT to a hash function can be encrypted using a private key. For example, the first intermediate CA ICA1 can generate a signature SNc using the private key of the first intermediate CA ICA1.

[0049] Figure 4 It is used to describe Figure 1 and Figure 2 A conceptual diagram of the transaction described herein. (See reference.) Figure 4 A transaction TX can include a registration message RM and a signature SNm. The registration message RM can include an ID, a registration command RG, a public key PK, and a hash value HC of the certificate. Here, we will describe the transaction TX as necessary for registration, but the transaction TX can include various messages used to update, revoke, and extend the registered public key according to the command.

[0050] A signature SNm can be generated by encrypting the hash value of the registration message RM using a private key. That is, the hash value generated by applying the registration message RM to a hash function can be encrypted using a private key. For example, the first intermediate CA ICA1 can generate a signature SNm using the private key of the first intermediate CA ICA1.

[0051] Figure 5 It is shown in detail Figure 2 The flowchart for operation S130 is shown below. (Refer to the flowchart.) Figure 5 , Figure 1 The first intermediate CA ICA1 can register as a member of blockchain network 110 to represent the second domain 200, and in an embodiment, the first electronic device ED1 can check whether it is possible to register the first intermediate CA ICA1 as a member of blockchain network 110. Figure 5 In this context, distributed ledger 111 is represented as a component separate from the first intermediate CA ICA1 and the first electronic device ED1, but it can be understood that distributed ledger 111 is distributed to nodes of blockchain network 110.

[0052] In operation S131, the first intermediate CA ICA1 can request registration at blockchain network 110. To do this, the first intermediate CA ICA1 can generate a transaction TX for registration. The transaction TX for registration may include, as referenced... Figure 4 The aforementioned registration command. The first intermediate CA, ICA1, can output the certificate (CT) and transaction (TX) to the blockchain network 110.

[0053] In operation S132, the first electronic device ED1 can verify the signature of transaction TX. For example, the first electronic device ED1 can extract the public key from transaction TX (e.g., Figure 4 The first electronic device ED1 can decrypt the signature of transaction TX using the extracted public key PK (e.g., PK). Figure 4 (SNm). Registration messages can be generated (e.g., Figure 4 The hash value of the RM (Record Message) in the transaction (TX) is used as the decryption result. The first electronic device ED1 can perform a hash operation on the RM of the registration message of the transaction (TX) to generate a hash value. The first electronic device ED1 can compare the hash value generated from the hash operation with the hash value generated from the decryption. When the two hash values ​​match, the first electronic device ED1 can determine that the corresponding verification is successful.

[0054] In operation S133, the first electronic device ED1 can verify the signature of certificate CT. For example, the first electronic device ED1 can decrypt the signature of certificate CT using the public key PK included in certificate CT (e.g., Figure 3 (SNc). It can generate identity information (e.g., Figure 3 The hash value of the tbsCT (certificate identity information) is used as the decryption result. The first electronic device ED1 can hash the tbsCT of the certificate CT to generate a hash value. The first electronic device ED1 can compare the hash value generated from the hash with the hash value generated from the decryption. When the two hash values ​​match, the first electronic device ED1 can determine that the corresponding verification was successful.

[0055] In operation S134, the first electronic device ED1 can check whether the information of transaction TX and certificate CT are consistent with each other. For example, the first electronic device ED1 can determine whether the identifier ID and public key PK included in transaction TX are the same as the identifier ID and public key PK included in certificate CT. For example, the first electronic device ED1 can determine the hash value of the certificate included in transaction TX (e.g., Figure 4 The first electronic device ED1 determines whether the HC value is the same as the hash value generated by hashing the certificate CT. When the information of transaction TX and certificate CT are consistent, the first electronic device ED1 can determine that the corresponding verification is successful.

[0056] When the verification operations corresponding to operations S132 to S134 are successful, operation S135 can be executed. In operation S135, the first electronic device ED1 can add transaction TX to the distributed ledger 111 as a new block of the blockchain (e.g., Figure 1 The second block (BLK2). In this way, the first intermediate CA ICA1 can be registered as a node in the blockchain network 110. The updated distributed ledger 111 can be shared by all nodes. When the verification operations corresponding to operations S132 to S134 fail respectively, operation S135 can be omitted, and the transaction TX and certificate CT can be revoked.

[0057] Figure 6 It is used to describe Figure 1 A block diagram illustrating the process of mutual authentication performed by electronic devices in a cryptographic communication system. (Reference) Figure 6 It can be understood that the first domain 2100 is a blockchain-based PKI domain, and the second domain 2200 is a CA-based PKI domain. The cryptographic communication system 2000 includes a blockchain network 2110 for the PKI of the first domain 2100. The distributed ledger 2111 is implemented in the blockchain network 2110.

[0058] The cryptographic communication system 2000 may include CAs (RCA1, ICA1, CA1, CA2, and CA3) for the PKI of the second domain 2200. For example, the intermediate CA ICA1 may be a node registered through the first block BLK1 of the blockchain network 2110. For example, the first electronic device ED1 and the second electronic device ED2 may be nodes registered through the second block BLK2 and the third block BLK3 of the blockchain network 2110. The intermediate CA ICA1 may represent a third electronic device ED3 and a fourth electronic device ED4 to perform mutual authentication with the first electronic device ED1 and the second electronic device ED2. The following will describe how cryptographic communication is performed between the second electronic device ED2 of the first domain 2100 and the fourth electronic device ED4 of the second domain 2200 in an embodiment.

[0059] Figure 7 This is a flowchart illustrating a method for performing mutual authentication between entities belonging to a CA-based PKI domain and entities belonging to a blockchain-based PKI domain. Through... Figure 7 The corresponding operations, the entity of the first field 2100 (e.g., Figure 6 The second electronic device ED2) and the entity of the second domain 2200 (e.g., Figure 6 The fourth electronic device (ED4) can perform cryptographic communication. Figure 7 The order of operations S210 and S220 shown is merely an example, and operations S210 and S220 can be interchanged.

[0060] For mutual authentication to be performed, at least one entity belonging to a CA-based PKI domain must be a node in blockchain network 2110. The above describes how the intermediate CA ICA1, belonging to the second domain 2200, registers as a node in blockchain network 2110. Therefore, Figure 6 Electronic devices belonging to the second domain 2200 and Figure 6 Electronic devices belonging to the first domain 2100 can perform mutual authentication.

[0061] In operation S210, it belongs to the CA-based PKI domain (e.g., Figure 6 Entities belonging to the second domain (2200) can be authenticated as belonging to a blockchain-based PKI domain (e.g., Figure 6 The entity in the first field (2100). Figure 6 In the second domain 2200, the third electronic device ED3 and the fourth electronic device ED4 are not members of the blockchain network 2110. Therefore, for the third electronic device ED3 and the fourth electronic device ED4 to perform cryptographic communication with electronic devices in any other domain, the electronic devices in other domains can be authenticated by the intermediate CA ICA1 instead of the third electronic devices ED3 and the fourth electronic devices ED4. Then, the intermediate CA ICA1 can notify the lower-level entities, namely the third electronic device ED3 and the fourth electronic device ED4, of the authentication result.

[0062] In operation S220, it belongs to the blockchain-based PKI domain (e.g., Figure 6 Entities in the first domain (2100) can be authenticated as belonging to a CA-based PKI domain (e.g., Figure 6 The entity in the second domain (2200). The CA-based PKI domain is a centralized PKI through a hierarchical trust authentication chain. Therefore, the first electronic device ED1 and the second electronic device ED2 of the first domain 2100 can verify the certificate of the intermediate CA ICA1, which is a node of the blockchain network 2110, and then can verify the certificates of the lower-level entities.

[0063] Figure 8 It is shown in detail Figure 7 The flowchart for operation S210 is shown below. (Refer to...) Figure 6 and Figure 8 Replacing the fourth electronic device ED4, the intermediate CA ICA1, belonging to the CA-based PKI domain, can authenticate the second electronic device ED2. The second electronic device ED2 belongs to the blockchain-based PKI domain. Figure 8 In this context, the distributed ledger 2111 is represented as a separate component, but it can be understood that the distributed ledger 2111 is distributed to the nodes of the blockchain network 2110.

[0064] In operation S211, for cryptographic communication, the fourth electronic device ED4 may request identification from the second electronic device ED2. In response to the request for the identification, the second electronic device ED2 may send identifier ID2 and certificate CT2 to the fourth electronic device ED4.

[0065] In operation S212, the fourth electronic device ED4 can send the received identifier ID2 and the received certificate CT2 to the intermediate CA ICA1. Because the fourth electronic device ED4 is not a member of the blockchain network 2110, the intermediate CA ICA1 can authenticate the second electronic device ED2.

[0066] In operation S213, the intermediate CA ICA1 can store the certificate CT2 of the second electronic device ED2. The certificate CT2 can be stored in the memory of the intermediate CA ICA1, and when verifying the certificate CT2 of the second electronic device ED2, the intermediate CA ICA1 can verify the stored certificate CT2.

[0067] In operation S214, the intermediate CA ICA1 can look up transaction TX2 corresponding to the second electronic device ED2 at the distributed ledger 2111. The intermediate CA ICA1 can also look up transaction TX2 using the identifier ID2 received from the fourth electronic device ED4. As described above, because transaction TX2 includes a registration message containing the identifier ID2 and the public key, transaction TX2 can be found using the received identifier ID2.

[0068] In operation S215, the intermediate CA ICA1 can verify the second electronic device ED2 based on the transaction TX2 found in operation S214 and the certificate CT2 stored in operation S213. This can be done in conjunction with... Figure 5 The second electronic device ED2 is verified in the same manner as described in operations S132 to S134.

[0069] For example, in operation S215, intermediate CA ICA1 can verify the signature of transaction TX2. Intermediate CA ICA1 can decrypt the signature of transaction TX2 using its public key. A hash value of the registration message included in transaction TX2 can be generated as the decryption result. Intermediate CA ICA1 can hash the registration message of transaction TX2 to generate a hash value. Intermediate CA ICA1 can verify the signature of transaction TX2 by comparing the decrypted hash value with the hash value generated by the hash operation.

[0070] Additionally, in operation S215, intermediate CA ICA1 can verify the signature of certificate CT2 stored in operation S213. Intermediate CA ICA1 can decrypt the signature of certificate CT2 using the public key. A hash value of the identity information can be generated as the decryption result. Intermediate CA ICA1 can hash the identity information of certificate CT2 to generate a hash value. Intermediate CA ICA1 can verify the signature of certificate CT2 by comparing the decrypted hash value with the hash value generated by the hash operation.

[0071] Furthermore, in operation S215, the intermediate CA ICA1 can determine whether the identifier ID2 and public key included in transaction TX2 are the same as the identifier ID2 and public key included in certificate CT2. Additionally, the intermediate CA ICA1 can determine whether the hash value of the certificate included in transaction TX2 is the same as the hash value generated by hashing certificate CT2. Through these operations, it can be verified whether certificate CT2 corresponds to the second electronic device ED2.

[0072] In operation S216, the intermediate CA ICA1 can send a response message to the fourth electronic device ED4. This response message may include the identifier of the intermediate CA ICA1, the verification result of certificate CT2, and a signature associated with the response message. The signature associated with the response message can be generated by encrypting the hash value of the response message using a private key at the intermediate CA ICA1. The signature associated with the response message can be included in the response message for the purpose of verifying authentication and the integrity of the response message.

[0073] The fourth electronic device ED4 can verify the signature of the received response message. The fourth electronic device ED4 possesses the certificate of the intermediate CA ICA1 through a trusted authentication chain. In this way, the fourth electronic device ED4 can extract the public key of the intermediate CA ICA1 from its certificate. The fourth electronic device ED4 can verify the signature of the response message by decrypting the signature of the response message using the public key. The method of verifying the signature using the public key is the same as that described in operation S133.

[0074] Figure 9 It is shown in detail Figure 7 The flowchart for operation S220 is shown below. (Refer to the flowchart.) Figure 6 and Figure 9 A second electronic device ED2, belonging to a blockchain-based PKI domain, can authenticate a fourth electronic device ED4, belonging to a CA-based PKI domain. Before authenticating the fourth electronic device ED4, the second electronic device ED2 can authenticate the intermediate CA ICA1 and the third CA CA3, forming a trust authentication chain. Figure 9 In this context, the distributed ledger 2111 is represented as a separate component, but it can be understood that the distributed ledger 2111 is distributed to the nodes of the blockchain network 2110.

[0075] In operation S221, for cryptographic communication, the second electronic device ED2 can request identification from the fourth electronic device ED4. In response to the identification request, the fourth electronic device ED4 can send the identifier IDi1 and certificate CTi1 of the intermediate CA ICA1, the certificate CTc3 of the third CA CA3, and the certificate CT4 of the fourth electronic device ED4 to the second electronic device ED2. The fourth electronic device ED4 can possess the identifier IDi1 and certificate CTi1 of the intermediate CA ICA1 and the certificate CTc3 of the third CA CA3. Therefore, it may be necessary to authenticate the fourth electronic device ED4 using the identifier IDi1 and certificate CTi1 of the intermediate CA ICA1 as a member of the blockchain network 2110, and the certificate CTc3 of the third CA CA3 forming the trust authentication chain.

[0076] In operation S222, the second electronic device ED2 may store certificates CTi1, CTc3, and CT4 received from the fourth electronic device ED4. Certificates CTi1, CTc3, and CT4 may be stored in the memory of the second electronic device ED2 and may be used when verifying certificates CTi1, CTc3, and CT4.

[0077] In operation S223, the second electronic device ED2 can look up the transaction TXI1 corresponding to the intermediate CA ICA1 at the distributed ledger 2111. The second electronic device ED2 can look up the transaction TXI1 corresponding to the intermediate CA ICA1 by using the identifier IDi1 of the intermediate CA ICA1 received from the fourth electronic device ED4. As described above, since the transaction TXI1 includes a registration message containing the identifier IDi1 and the public key, the transaction TXI1 can be found by using the received identifier IDi1.

[0078] In operation S224, the second electronic device ED2 can verify the intermediate CA ICA1 based on the transaction TXI1 found in operation S223 and the certificate CTi1 of the intermediate CA ICA1 stored in operation S222. This can be done in conjunction with... Figure 5 Operations S132 to S134 and Figure 8 The intermediate CA ICA1 is verified in the same manner as described in operation S215. For example, the verification operation may include: verifying the signature of transaction TXI1, verifying the signature of certificate CTi1, determining whether the identifier ID2 and public key included in transaction TXI1 are the same as the identifier ID2 and public key included in certificate CTi1, and determining whether the hash value of the certificate included in transaction TXI1 is the same as the hash value generated by hashing certificate CTi1.

[0079] In operation S225, the second electronic device ED2 can verify the third CA CA3 based on the certificate CTc3 of the third CA CA3 stored in operation S222. A public key is required to verify the certificate CTc3 of the third CA CA3. According to CA-based PKI, the certificate CTc3 of the third CA CA3 can be signed using the private key of the intermediate CA ICA1. Therefore, the second electronic device ED2 can decrypt the certificate CTc3 of the third CA CA3 using the public key of the intermediate CA ICA1. The public key of the intermediate CA ICA1 can be extracted from the certificate CTi1 of the intermediate CA ICA1. Therefore, the authentication of the certificate CTc3 described in operation S133 is possible.

[0080] In operation S226, the second electronic device ED2 can verify the fourth electronic device ED4 based on the certificate CT4 of the fourth electronic device ED4 stored in operation S222. A public key is required to verify the certificate CT4 of the fourth electronic device ED4. According to CA-based PKI, the certificate CT4 of the fourth electronic device ED4 can be signed using the private key of the third CA CA3. Therefore, the second electronic device ED2 can decrypt the certificate CT4 of the fourth electronic device ED4 using the public key of the third CA CA3. The public key of the third CA CA3 can be extracted from the certificate CTc3 of the third CA CA3. Therefore, the authentication of the certificate CT4 described in operation S133 is possible.

[0081] Figure 10 It is shown Figure 1 and Figure 6 A flowchart detailing the process by which entities in a cryptographic communication system perform mutual authentication. Figure 1 and Figure 6Each of the cryptographic communication systems 1000 and 2000 can perform communication based on Secure Sockets Layer (SSL) / Transport Layer Security (TLS). SSL / TLS is a standard cryptographic protocol used to protect data exchanged when communicating over the Internet. Because SSL / TLS is a transport layer cryptographic approach, it can be used regardless of the application layer protocol type (e.g., FTP, XMPP, and HTTP). Communication between entities can be defined using a structure compatible with the TLS 1.3 handshake protocol. However, the inventive concept is not limited to this. For example, communication can be defined using a structure compatible with protocols that use certificates such as TLS 1.2.

[0082] The following describes how entities belonging to different domains can identify each other. Here, "client" and "server" can refer to the fourth electronic device ED4 and the second electronic device ED2, respectively. Figure 1 or Figure 6 In the cryptographic communication system 100 or 2000, the fourth electronic device ED4 belongs to the second domain 200 or 2200, which is a CA-based PKI domain. Figure 1 or Figure 6 In the cryptographic communication system 100 or 2000, the second electronic device ED2 belongs to the first domain 100 or 2100, which is a blockchain-based PKI domain.

[0083] In operations S301 and S302, the fourth electronic device ED4 and the second electronic device ED2 can exchange basic information through greeting messages. For example, the fourth electronic device ED4 can send the following information through a client greeting message: the authentication algorithm, key exchange algorithm, hash algorithm, and cryptographic algorithm supported by the fourth electronic device ED4. The second electronic device ED2 can send the following information through a server greeting message: the authentication algorithm, key exchange algorithm, hash algorithm, and cryptographic algorithm supported by the second electronic device ED2.

[0084] In operation S303, the second electronic device ED2 can send encrypted extended data to the fourth electronic device ED4 via an encrypted extended message. The extended data can be data that does not require setting a password context or is not associated with a personal certificate.

[0085] In operation S304, because CA-based authentication is required, the second electronic device ED2 can send a certificate request message to the fourth electronic device ED4.

[0086] In operation S310, an entity belonging to a CA-based PKI domain can authenticate an entity belonging to a blockchain-based PKI domain. Operation S310 can include operations S311 through S318. Operation S310 and... Figure 7 This corresponds to operation S210.

[0087] In operation S311, the second electronic device ED2 can output certificate CT2 to the fourth electronic device ED4. Certificate CT2 may include information about the public key of the second electronic device ED2. Operation S311 and Figure 8 This corresponds to operation S211.

[0088] In operation S312, in response to receiving certificate CT2 from the second electronic device ED2, the fourth electronic device ED4 can request the intermediate CA ICA1 to verify the second electronic device ED2. Specifically, the fourth electronic device ED4 can request a transaction from the intermediate CA ICA1 that indicates the identifier of the second electronic device ED2. For example, the fourth electronic device ED4 can send certificate CT2 and identifier ID2 along with a lookup command to the intermediate CA ICA1. Operation S312 and Figure 8 The operation corresponds to S212.

[0089] In operation S313, in response to a request from the fourth electronic device ED4, the intermediate CA ICA1 can look up the transaction corresponding to the second electronic device ED2 at distributed ledger 2111. The intermediate CA ICA1 can look up the transaction using the identifier ID2 received from the fourth electronic device ED4. Operation S313 and... Figure 8 This corresponds to operation S214.

[0090] In operation S314, the intermediate CA ICA1 can verify the transaction found in operation S313 and the certificate CT2 received from the second electronic device ED2. For example, the verification operation may include: verifying the signature of the transaction, verifying the signature of certificate CT2, determining whether the identifier ID2 and public key included in the transaction are the same as the identifier ID2 and public key included in certificate CT2, and determining whether the hash value of the certificate included in the transaction is the same as the hash value generated by hashing certificate CT2. Operation S314 and... Figure 8 This corresponds to operation S215.

[0091] In operation S315, the intermediate CA ICA1 can request the electronic device ED4 to verify a response message including the verification result of certificate CT2. The intermediate CA ICA1 can send the verification result of certificate CT2 and a signature associated with the response message including that verification result to the fourth electronic device ED4. The signature associated with the response message can be generated by encrypting the hash value of the response message using a private key at the intermediate CA ICA1. Operation S315 and... Figure 8 This corresponds to operation S216.

[0092] In operation S316, the fourth electronic device ED4 can verify the signature of the received response message. The fourth electronic device ED4 possesses the certificate of the intermediate CA ICA1 through a trusted authentication chain. In this way, the fourth electronic device ED4 can extract the public key of the intermediate CA ICA1 from its certificate. The fourth electronic device ED4 can verify the signature of the response message by decrypting the signature of the response message using the public key.

[0093] In operation S317, the second electronic device ED2 can send a certificate verification message to the fourth electronic device ED4. This certificate verification message is used to prove that the second electronic device ED2 possesses the private key corresponding to certificate CT2. In operation S318, the second electronic device ED2 can end the server greeting by sending a completion message to the fourth electronic device ED4.

[0094] After operation S310, in operation S320, the second electronic device ED2 can send application data to the fourth electronic device ED4.

[0095] In operation S330, an entity belonging to a blockchain-based PKI domain can authenticate an entity belonging to a CA-based PKI domain. Operation S330 may include operations S331 through S339. Operation S330 and... Figure 7 The operation corresponds to S220.

[0096] In operation S331, the fourth electronic device ED4 can output a certificate to the second electronic device ED2. Here, the certificate may include: a certificate CTi1 of the intermediate CA ICA1, which is a node of the blockchain network 2110, and a CA (e.g., between the intermediate CA ICA1 and the fourth electronic device ED4) Figure 6 The third CA (CA3) certificate CTc3, and the fourth electronic device ED4 certificate CT4. Operation S331 and Figure 9 This corresponds to operation S221.

[0097] In operation S332, the fourth electronic device ED4, in response to receiving a certificate from the fourth electronic device ED4, requests a transaction associated with the intermediate CA ICA1 from the distributed ledger 2111. In operation S333, the distributed ledger 2111, in response to the transaction request, searches for the transaction TXI1 corresponding to the intermediate CA ICA1. Transaction TXI1 can be found using the identifier IDi1 of the intermediate CA ICA1. In operation S334, the transaction TXI1 found in operation S333 can be provided to the second electronic device ED2. Operations S332 to S334 are related to... Figure 9 The operation corresponds to S223.

[0098] In operation S335, the second electronic device ED2 can verify the transaction TXI1 found in operation 333, and the certificate CTi1 of the intermediate CA ICA1 received from the fourth electronic device ED2. Operation S335 and... Figure 9 The operation corresponds to S224.

[0099] In operation S336, the second electronic device ED2 can verify the certificate CTc3 of the third CA CA3 by using the public key of the intermediate CA ICA1 extracted from the certificate CTi1 of the intermediate CA ICA1. Operation S336 and Figure 9 The operation corresponds to S225.

[0100] In operation S337, the second electronic device ED2 can verify the certificate CT4 of the fourth electronic device ED4 by using the public key of the third CA CA3, which is extracted from the certificate CTc3 of the third CA CA3. Operation S337 and... Figure 9 This corresponds to operation S226.

[0101] In operation S338, the fourth electronic device ED4 can send a certificate verification message to the second electronic device ED2. This certificate verification message proves that the fourth electronic device ED4 possesses the private key corresponding to certificate CT4. In operation S339, the fourth electronic device ED4 can end the client greeting by sending a completion message to the second electronic device ED2.

[0102] After operation S330, in operation S340, the fourth electronic device ED4 can send application data to the second electronic device ED2.

[0103] Figure 11 It is shown Figure 1 and Figure 6 A block diagram of the electronic device shown. (Reference) Figure 11 The electronic device 3000 may include an interface 3100, a memory 3200, and a processor 3300. However, Figure 11 Not all components shown are required. Electronic device 3000 may also include, in addition to... Figure 11 Any other components besides those shown, or which may not be included. Figure 11 One or more of the components shown. An electronic device can represent... Figure 1 and Figure 6 At least one node included in the cryptographic communication systems 1000 and 2000.

[0104] Interface 3100 can communicate with external devices. Specifically, interface 3100 can connect to a network via wired or wireless means to communicate with external devices. These external devices can be servers, smartphones, tablets, personal computers (PCs), computing devices, etc. Interface 3100 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 it may be a tag / barcode containing information required for communication (e.g., the tag includes an NFC tag). Alternatively, the communication module can be a short-range communication module or a wired communication module. Interface 3100 can... Figure 1 or Figure 6 The cryptographic communication system 1000 or 2000 performs data communication with any other electronic device or CA.

[0105] In the case where electronic device 3000 belongs to a blockchain-based PKI domain, in order to perform verification operations against other electronic devices or CAs through interface 3100, electronic device 3000 can receive transactions and certificates from any other electronic device or CA. Through interface 3100, electronic device 3000 can receive certificates used to authenticate any other electronic device, and can send certificates to enable other electronic devices to authenticate electronic device 3000.

[0106] When electronic device 3000 belongs to a CA-based PKI domain, it can receive certificates for authenticating any other electronic device through interface 3100, and can send authentication requests and received certificates to the upper-layer CA. Electronic device 3000 can send its own certificate and the upper-layer CA's certificate through interface 3100 to enable any other electronic device to authenticate it.

[0107] The memory 3200 may include a storage medium implemented using at least one of the following: flash memory, hard disk, micro multimedia card, SD memory, XD memory, RAM (random access memory), SRAM (static random access memory), ROM (read-only memory), EEPROM (electrically erasable programmable read-only memory), PROM (programmable read-only memory), magnetic storage, disk, optical disk, etc.

[0108] In the case that electronic device 3000 belongs to a blockchain-based PKI domain, memory 3200 can store program code for allocating and managing ledgers used for recording transactions. Memory 3200 can store program code for executing a blockchain wallet. Memory 3200 can store at least one or more program codes for verifying transactions and certificates of any other electronic device. Additionally, memory 3200 can store certificates received through interface 3100 for verifying any other electronic device.

[0109] When electronic device 3000 belongs to a CA-based PKI domain, memory 3200 can store program code for performing cryptographic communication operations through a trust authentication chain. Memory 3200 can also store program code for requesting a CA (Certificate Authority) to authenticate electronic devices belonging to any other domain, where the CA is a node in the blockchain network. Memory 3200 can store the certificates of the CAs forming the trust authentication chain, enabling any other electronic device to authenticate both the CA and electronic device 3000.

[0110] Processor 3300 can control the overall operation of electronic device 3000 and may include at least one processor, such as a central processing unit (CPU). Processor 3300 may include at least one processor specifically corresponding to each function, or it may be an integrated processor. Processor 3300 can perform the above operations by using program code and information stored in memory 3200.

[0111] Even if an external electronic device belonging to an external domain is not registered as a node in the blockchain, according to the embodiment, an electronic device belonging to a blockchain-based PKI domain can still be authenticated by using the certificate of the upper-level CA registered as a node in the blockchain.

[0112] According to the above embodiments, electronic devices belonging to the CA-based PKI domain can perform authentication and cryptographic communication with external electronic devices by requesting an upper-level certification authority registered as a node in the blockchain to perform authentication.

[0113] The cryptographic communication system according to the above embodiments can achieve cryptographic communication between different domains by using blockchain-based PKI domains. Furthermore, since the upper-level CAs of each domain are registered as nodes in the blockchain network, cryptographic communication between lower-level entities is possible; therefore, each domain can be easily integrated and expanded through the blockchain.

[0114] Although the inventive concept has been described with reference to exemplary embodiments thereof, it will be apparent to those skilled in the art that various changes and modifications may be made to the inventive concept without departing from the spirit and scope of the inventive concept set forth in the appended claims.

Claims

1. An electronic device with a first domain, wherein the first domain is a blockchain-based Public Key Infrastructure (PKI) domain, the electronic device comprising: An interface is configured to receive a first certificate of the first entity, a second certificate of the second entity of the second domain, and a third certificate of the third entity of the second domain from a first entity of the second domain, wherein the first certificate is issued by the third entity to the first entity, and the third certificate is issued by the second entity to the third entity. A memory, configured to store the first certificate, the second certificate, and the third certificate; and The processor is configured as follows: Based on the identifier of the second entity, look up the transaction corresponding to the second entity in the second domain in the distributed ledger of the first domain; The second certificate of the second entity in the second domain is verified based on the public key of the second entity included in the exchange and the certificate hash value of the second certificate of the second entity; The third certificate is verified based on the verification of the second certificate, and also based on the public key of the second entity obtained from the second certificate; and The first certificate is verified based on the verification of the second certificate and the third certificate, and also based on the public key of the third entity obtained from the third certificate. Wherein, the first domain is different from the second domain; The first entity was not registered as a member of the first domain. The second certificate of the second entity is registered in the distributed ledger of the first domain.

2. The electronic device according to claim 1, wherein, The processor is configured to verify the transaction by: obtaining the public key of the second entity from the transaction; obtaining a first hash value by decrypting the signature of the transaction using the public key; and obtaining a second hash value by hashing the message of the transaction. And compare the first hash value and the second hash value.

3. The electronic device according to claim 1, wherein, The processor is configured to verify the second certificate by: decrypting the signature of the second certificate using the public key of the second entity to obtain a first hash value; and hashing the identity information of the second certificate to obtain a second hash value. And compare the first hash value and the second hash value.

4. The electronic device according to claim 1, wherein, The processor is configured to compare the identifier and public key included in the transaction with the identifier and public key included in the second certificate to verify the second certificate.

5. The electronic device according to claim 1, wherein, The processor is configured to verify the second certificate by obtaining a first hash value from the transaction as the hash value of the second certificate; The second hash value is obtained by hashing the second certificate; And compare the first hash value and the second hash value.

6. The electronic device according to claim 1, wherein, The processor is also configured to: The third certificate is verified by decrypting the signature of the third certificate using the public key of the second entity to obtain the first hash value. The second hash value is obtained by hashing the identity information of the third certificate; And compare the first hash value and the second hash value; as well as The first certificate is verified by decrypting the signature of the first certificate using the public key of the third entity to obtain a third hash value. The fourth hash value is obtained by hashing the identity information of the first certificate; And compare the third hash value with the fourth hash value.

7. The electronic device according to claim 1, wherein, The processor is also configured to generate a certificate for the electronic device. The certificate is signed using the private key of the electronic device, and The public key of the electronic device is registered in the distributed ledger.

8. The electronic device according to claim 1, wherein, The interface is configured to receive a registration transaction and a fourth certificate from a fourth entity that is registered as a member of a third domain different from the first and second domains, and The processor is configured to verify the registration transaction and the fourth certificate, and to add the registration transaction to the distributed ledger.

9. A cryptographic communication system, comprising: The first electronic device belongs to the first domain and is registered in the distributed ledger of the first domain, which is a blockchain-based public key infrastructure (PKI) domain. The second electronic device is registered as a member of a second domain, which is a PKI domain based on a Certificate Authority (CA), and the second electronic device is not registered as a member of the first domain. as well as The first CA is an upper-level node in the second domain of the hierarchical trust authentication chain, and the first CA is registered in the distributed ledger of the first domain. Specifically, based on the request of the second electronic device, the first CA is configured to: authenticate the first electronic device based on the first electronic device's first certificate and a first transaction corresponding to the first electronic device registered at the distributed ledger. The first electronic device includes a processor configured to: The second electronic device is authenticated based on the second certificate of the first CA, the second transaction corresponding to the first CA registered in the distributed ledger, and the third certificate of the second electronic device; Receives a fourth certificate from the second electronic device from a second CA registered as a member of the second domain, the second CA being an intermediate node of the first CA in the hierarchical trust authentication chain, and issues the third certificate; and The fourth certificate is verified based on the public key of the first CA obtained from the second certificate, and the third certificate of the second electronic device is verified based on the verification of the second certificate of the first CA and also based on the public key of the second CA obtained from the fourth certificate.

10. The cryptographic communication system according to claim 9, wherein, The first CA is configured to: look up the first transaction in the distributed ledger based on the identifier of the first electronic device; and verify the first certificate based on the first transaction; And based on the verification of the first certificate, a response message is sent to the second electronic device.

11. The cryptographic communication system according to claim 9, wherein, The first CA is configured to authenticate the first electronic device by verifying the signature of the first transaction based on the public key of the first electronic device; The signature of the first certificate is authenticated based on the public key of the first electronic device; it is determined whether the identifier included in the first transaction is the same as the identifier included in the first certificate; And determine whether the hash value obtained by hashing the first certificate is the same as the hash value of the first certificate included in the first transaction.

12. The cryptographic communication system according to claim 9, wherein, The first CA is configured to send a response message to the second electronic device, wherein the response message includes a verification result authenticating the first electronic device, and The second electronic device is configured to verify the signature of the response message based on the second certificate.

13. The cryptographic communication system according to claim 9, wherein, The first electronic device is configured to authenticate the second electronic device by: looking up a second transaction corresponding to the first CA at the distributed ledger based on the identifier of the first CA; Verify the second certificate based on the second transaction; The fourth certificate is verified based on the public key of the first CA obtained from the second certificate; And verify the third certificate based on the public key of the second CA obtained from the fourth certificate.

14. The cryptographic communication system according to claim 9, wherein, Based on the first CA authentication of the first electronic device, the first electronic device is configured to send first application data to the second electronic device, and Specifically, the second electronic device is authenticated based on the first electronic device, and the second electronic device is configured to send second application data to the first electronic device.

Images