PUF-based cryptographic communication method and computing device for performing the same

The PUF-based cryptographic communication method addresses the challenges of lightweight hardware and resource-efficient cryptographic protocols by generating keys and signatures temporarily, ensuring secure data transmission for IoT devices.

JP2026041697APending Publication Date: 2026-03-10CHUNGBUK NAT UNIV IND ACADEMIC COOPERATION FOUND
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-08-25
Publication Date
2026-03-10

AI Technical Summary

Technical Problem

Existing cryptographic protocols for IoT devices require significant hardware, computational resources, and storage of cryptographic information, which is challenging for ultra-small and low-power devices, and pose risks of data security breaches due to potential hacking.

Method used

A PUF-based cryptographic communication method that generates private keys and session keys temporarily using a PUF circuit, enabling lightweight hardware and reduced resource consumption, with a controller decrypting encrypted messages and signatures.

Benefits of technology

Enables secure cryptographic communication with reduced hardware requirements, minimal computational complexity, and low resource consumption, while ensuring data confidentiality, integrity, and authentication.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026041697000001_ABST
    Figure 2026041697000001_ABST
Patent Text Reader

Abstract

To provide a cryptographic communication method requiring light-weight hardware, a small amount of calculation, and low resource consumption. [Solution] An electronic device (100) includes a PUF circuit that implements a physically unclonable function (PUF), a communication device, and a controller. The PUF circuit generates a private key by inputting a random challenge signal to the physically unclonable function. The communication device receives from a partner electronic device a message encrypted with a temporarily generated message session key and an encrypted message session key generated by encrypting the message session key with a public key corresponding to the private key. The controller decrypts the message session key encrypted with the private key to obtain the message session key, and decrypts the message encrypted with the message session key.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] An embodiment of the present invention relates to a PUF-based cryptographic communication method and a computing device technology for performing the same. [Background technology]

[0002] As the internet and smartphones become more widespread, the market for the Internet of Things (IoT), which connects many people and devices through smart devices, sensors, and other terminals, is expanding. Data transmitted between IoT devices (hereafter referred to as electronic devices) must be guaranteed to be confidential (only authorized devices can read the data), intact (data is not modified), and authenticated (the identities of the sender and receiver are verified). Cryptographic protocol technology is used in data transmission to ensure data confidentiality, integrity, and authentication. Cryptographic protocol technology can be broadly divided into technology for a server to authenticate an electronic device and technology for communicating messages between electronic devices authenticated by the server. On the other hand, since electronic devices are becoming ultra-small and low-power, it is difficult to use cryptographic protocols that require large hardware, a large amount of calculations, and a large consumption of resources. Therefore, there is a demand for cryptographic protocols that require only lightweight hardware, a small amount of calculations, and a small consumption of resources. Furthermore, since electronic devices are generally portable, there is a risk that cryptographic information (e.g., various keys of cryptographic protocols) stored in the electronic device may be hacked if the electronic device is stolen. Therefore, there is a demand for cryptographic protocols that do not store cryptographic information in memory but temporarily generate it when needed. [Prior art documents] [Patent documents]

[0003] Korean Patent Publication No. 10-2022-0138648 (2022.10.13) Summary of the Invention [Problem to be solved by the invention]

[0004] The problem to be solved by the present invention is to provide a cryptographic communication method that requires light-weight hardware, a small amount of calculation, and low resource consumption. Another problem to be solved by the present invention is to provide a cryptographic communication method that temporarily generates information required for cryptographic communication when necessary. Another problem to be solved by the present invention is to provide a cryptographic key sharing method that temporarily generates cryptographic information when necessary. The problems to be solved by the present invention are not limited to those mentioned above, and other problems not mentioned will be clearly understood by those skilled in the art from the following description. [Means for solving the problem]

[0005] According to one aspect, an electronic device is provided that includes: a PUF circuit that generates a private key by inputting a random challenge signal into a function that cannot be physically copied; a communication device that receives from a counterpart electronic device a message encrypted with a temporarily generated message session key and the message session key by encrypting the message session key with a public key corresponding to the private key, and the generated encrypted message session key; and a controller that decrypts the encrypted message session key with the private key to obtain the message session key, and decrypts the encrypted message with the message session key. According to one embodiment, the communication device receives the random challenge signal from a server connected to each of the electronic device and the other electronic device via a channel independent of the outside world, and the public key may be generated based on a private key retrieved in response to the random challenge signal from a challenge response pair database pre-stored for the electronic device at the server. According to one embodiment, the private key generated by the PUF circuit and the retrieved private key may be the same. According to one embodiment, the controller may generate a second shared session key based on the private key and the encrypted session key, and decrypt the encrypted session key with the second shared session key. According to one embodiment, the message session key may be encrypted in the other electronic device with a first shared session key generated based on the message session key and a public key corresponding to the private key. According to one embodiment, the electronic device may further include a random number generator that generates a new random number that does not overlap depending on environmental conditions when a new message is generated, and generates a new message session key based on the new random number. According to one embodiment, the controller generates a signature based on the private key to ensure the integrity of the transmitted data, and the communication device transmits the transmitted data and the signature to the other electronic device. According to one embodiment, the electronic device further includes a random number generator that generates unique random numbers depending on environmental conditions and generates a signature session key based on the random numbers, and the controller may generate the signature by inputting the personal key and the signature session key into a signature generation function that cannot predict an input signal corresponding to the output signal from an output signal. According to one embodiment, the communication device communicates with a server connected to each of the electronic device and the other electronic device via a channel independent of the outside world, the public key is generated by the server in response to the random challenge signal and transmitted to the other electronic device, and the signature can be verified by the other electronic device based on the private key. According to one embodiment, the communication device receives a certificate of the other electronic device from a server connected to each of the electronic device and the other electronic device via a channel independent of the outside world, and the controller can verify the certificate based on a private key generated via the PUF circuit to obtain the public key of the other electronic device. According to one embodiment, the electronic device further includes a random number generator that generates unique random numbers based on environmental conditions and generates a message session key based on the random number, and the controller may encrypt data to be sent to the other electronic device with the message session key and encrypt the message session key with the public key of the other electronic device. According to one embodiment, the certificate includes a personal key searched for in response to the random challenge signal from a challenge response pair database pre-stored for the electronic device in the server, and a first authentication code generated based on one or more of a plurality of device information related to the other electronic device, and the controller generates a second authentication code based on the personal key generated by the PUF circuit and one or more of the plurality of device information, and can authenticate the certificate based on the first authentication code and the second authentication code. According to one embodiment, the electronic device further includes a challenge signal generating device that receives an initial signal from the server connected to a channel unrelated to the outside via the communication device and generates a plurality of challenge signals, the PUF circuit receives each of the plurality of challenge signals as input and generates a corresponding plurality of response information, the controller pairs each of the plurality of challenge signals with the corresponding plurality of response information to generate a plurality of challenge response pairs, and the communication device may transmit the plurality of challenge response pairs to the server. According to another aspect, a method is provided that includes the steps of: generating a private key by inputting a random challenge signal into a function that cannot be physically copied using a PUF circuit; receiving from a counterpart electronic device a message encrypted with a temporarily generated message session key and an encrypted message session key generated by encrypting the message session key with a public key corresponding to the private key; decrypting the encrypted message session key with the private key to obtain the message session key; and decrypting the encrypted message with the message session key. [Effects of the Invention]

[0006] According to one embodiment of the present disclosure, cryptographic communication can be performed with reduced hardware requirements, a small amount of calculations, and low resource consumption. Furthermore, according to one embodiment of the present disclosure, information required for cryptographic communication can be temporarily generated when necessary, and cryptographic communication can be performed. Furthermore, according to one embodiment of the present disclosure, it is possible to share keys used in cryptographic protocols with reduced hardware requirements, less computational complexity, and less resource consumption. Furthermore, according to one embodiment of the present disclosure, digital signatures can be generated and verified with reduced hardware requirements, reduced computational complexity, and reduced resource consumption. Furthermore, according to one embodiment of the present disclosure, information required for cryptographic communication can be temporarily generated as needed, and digital signatures can be generated and verified. The effects of the present invention are not limited to those mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the following description.

[0007] The present disclosure may be readily understood in conjunction with the following detailed description and the accompanying drawings, in which reference numerals refer to structural elements. [Brief explanation of the drawings]

[0008] [Figure 1a] 1 is a schematic diagram illustrating a system for performing a PUF-based cryptographic communication method according to an embodiment of the present invention. [Figure 1b] 1 is a diagram illustrating a process of a PUF-based cryptographic communication method according to an embodiment of the present invention. [Figure 2] 1 is a block diagram showing the configuration of an electronic device that constructs a challenge-response pair database and performs PUF-based cryptographic communication according to an embodiment of the present invention. [Figure 3]10 is a flowchart illustrating a process of constructing a PUF-based challenge-response pair database according to an embodiment of the present invention. [Figure 4] 1 is a flowchart illustrating a method for an electronic device to generate multiple challenge signals and corresponding multiple response information according to one embodiment of the present invention. [Figure 5] 1 is a flowchart illustrating a method for generating response information according to an embodiment of the present invention. [Figure 6] 4 is a flowchart illustrating a method for generating a private key according to an embodiment of the present invention. [Figure 7] 10 is a flowchart illustrating a process for authenticating an electronic device based on a constructed challenge-response pair database according to an embodiment of the present invention. [Figure 8] 10 is a flowchart illustrating a process in which a server authenticates an electronic device according to another embodiment of the present invention. [Figure 9] 10 is a flowchart illustrating a process in which a server shares a first public key of a first electronic device with a second electronic device according to an embodiment of the present invention. [Figure 10] 10 is a flowchart illustrating an operation of a server that shares a first public key of a first electronic device with a second electronic device according to an embodiment of the present invention. [Figure 11] 10 is a flowchart illustrating a process in which a server shares a second public key of a second electronic device with a first electronic device according to an embodiment of the present invention. [Figure 12] 10 is a flowchart illustrating an operation of a server that shares a second public key of a second electronic device with a first electronic device according to an embodiment of the present invention. [Figure 13] 1 is a flowchart illustrating a process in which a first electronic device transmits a message to a second electronic device according to an embodiment of the present invention. [Figure 14] 10 is a flowchart illustrating a process in which a second electronic device receives a message from a first electronic device according to an embodiment of the present invention. [Figure 15]1 is a flowchart illustrating a process in which a first electronic device transmits a message to a second electronic device according to an embodiment of the present invention. [Figure 16] 10 is a flowchart illustrating a process in which a second electronic device receives a message from a first electronic device according to an embodiment of the present invention. [Figure 17] 10 is a flowchart illustrating a process in which a first electronic device verifies a second certificate of a second electronic device and obtains a public key of the second electronic device according to an embodiment of the present invention. [Figure 18] 10 is a flowchart illustrating a process in which a server shares a second certificate including a public key of a second electronic device with a first electronic device according to an embodiment of the present invention. [Figure 19] 10 is a flowchart illustrating a process in which a first electronic device verifies a second certificate of a second electronic device received from a server and obtains a public key of the second electronic device, according to an embodiment of the present invention. [Figure 20] 1 is a flowchart illustrating a process in which a first electronic device transmits a message to a second electronic device according to an embodiment of the present invention. [Figure 21] 10 is a flowchart illustrating a process in which a second electronic device receives a message from a first electronic device according to an embodiment of the present invention. [Figure 22] 1 is a block diagram illustrating a configuration of a computing device according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] Specific embodiments of the present invention will now be described with reference to the accompanying drawings. The following detailed description is provided to facilitate a comprehensive understanding of the methods, devices, and / or systems described herein. However, this is for illustrative purposes only, and the present invention is not limited thereto. When describing embodiments of the present invention, detailed descriptions of known technologies related to the present invention may be omitted if they are deemed to obscure the gist of the present invention. Furthermore, the terms used below are defined in consideration of their functions in the present invention, and these definitions may vary depending on the intentions or practices of users and operators. Therefore, their definitions should be based on the entire contents of this specification. Terms used in the detailed description are intended solely to describe embodiments of the present invention and are not limiting in any way. Unless clearly stated otherwise, the appearance of "a" or "an" includes the plural meaning. In this specification, terms such as "comprises" or "has" are intended to refer to certain features, numbers, steps, operations, elements, portions thereof, or combinations thereof, and should not be interpreted as excluding the presence or possibility of one or more other features, numbers, steps, operations, elements, portions thereof, or combinations thereof other than those stated. Furthermore, terms including ordinal numbers such as "first" or "second" may be used to describe various components, but the components should not be limited by these terms. These terms may be used to distinguish one component from another. For example, a first component may be referred to as a second component, and similarly, a second component may be referred to as a first component, without departing from the scope of the present invention. Furthermore, when a certain component is said to be "connected" to another component, this includes not only the case where it is "directly connected" but also the case where it is "connected with another component in between." As used herein, a "communications network" may include the Internet, one or more local area networks, wide area networks, cellular networks, mobile networks, other different types of networks, or a combination of these networks. In this specification, a "cryptographic protocol" refers to a communication protocol that uses encryption technology to protect the confidentiality and integrity of data transmitted between an electronic device and a server. Data is encrypted and transmitted to prevent eavesdropping or modification during transmission, and received encrypted data can be decrypted to the original data before being read. In this case, the function (or program time) that encrypts or decrypts data can be called a key. Cryptographic protocols can be broadly divided into symmetric key (shared key) encryption and asymmetric key (public key) encryption, depending on whether the keys used for encryption and decryption are the same. As used herein, "data" may refer to a set of meaningful electrical signals transmitted over a communications network. For example, data may be a message sent by one electronic device to another. For example, data may be a key transmitted between an electronic device and a server. Data may be encrypted or decrypted by a key. For example, data may be a signature generated by a particular user entity. In this specification, a "session key" may be a key temporarily generated for cryptographic protocol-based communication. A session key may expire after a preset time or when a certain condition is met. A session key may be newly generated for a new calculation. A session key may undergo additional processing for communication stability or to be divided according to each subsequent role. In one exemplary embodiment, the additional processing may be input to a random number function to adjust the bit length to a predetermined value. The session key may be input to a random number function to adjust the bit length to a predetermined value. In another exemplary embodiment, the additional processing may be input to a range check function to check whether the range of the predetermined function is satisfied. The session key may be input to the range check function and discarded if it does not meet the range of the predetermined function, thereby generating a new session key. The session key can be further processed to be subdivided into a message session key, a personal session key, and a signature session key. In an exemplary embodiment, the message session key may be a key used to encrypt or decrypt data using a symmetric key encryption scheme. The data to be encrypted or decrypted may be a message being sent or received. The message session key may be generated by inputting a 640-bit session key into a random number function that reduces the length of the session key to 128 bits. In an exemplary embodiment, the private session key may be a key used in an intermediate step for a predetermined other purpose. For example, the predetermined other purpose may be a key agreement process (e.g., Elliptic Curve Diffie-Hellman Key Exchange (ECDH)). Alternatively, the predetermined other purpose may be a process for decrypting an encrypted message session key. The private session key may be generated by inputting a 640-bit session key to a random number function that reduces the length to 256 bits, and then inputting the result to a range check function that checks whether the result falls within the range of the elliptic curve encryption function. In an exemplary embodiment, the signature session key may be a key used to generate a signature for a message. The signature session key may be generated by inputting a 640-bit session key to a random number function that reduces the length to 256 bits, and then inputting the result to a range check function that checks whether the result falls within the range of an elliptic curve encryption function. The message session key, the personal session key, and the signature session key may be different session keys, or two or more of the message session key, the personal session key, and the signature session key may be the same key. In this specification, a "symmetric key encryption method" refers to a method of decrypting encrypted data using the same key that encrypted the data. In this case, a commonly used key is called a shared key. A shared key that is used temporarily and disposably in one session is called a session key. As used herein, "asymmetric key encryption" refers to a method of decrypting encrypted data using a key different from the key used to encrypt the data. Each electronic device may have a unique public key and a unique private key. The public key may be made public to all but the electronic device that owns it. On the other hand, the private key may not be exposed outside the electronic device. The private key and public key owned by an electronic device work in pairs, with one key encrypting data and the other key further decrypting the encrypted data. As used herein, a "private key" may be a key that an electronic device does not share with other electronic devices. In an exemplary embodiment, a private key may be used by an electronic device to generate a signature, verify a certificate of another electronic device, or encrypt or decrypt data sent to or received from another electronic device. A private key is not shared with other electronic devices, but may be shared with a server connected via a secure channel (a channel that is isolated from the outside and cannot be attacked or hacked). In an exemplary embodiment, a private key may be used to decrypt a session key encrypted with a public key. In this case, the private key may correspond to the public key that encrypted the session key. In this specification, the "reference private key" may be a private key that serves as a reference for determining whether a certificate received by an electronic device from a server is forged or altered. The reference private key may be a private key that is generated by inputting a random challenge signal to a PUF circuit of the electronic device. As used herein, a "reference private key" may be a private key used to generate the authentication code included in the certificate that the server sends to the electronic device. In an exemplary embodiment, the electronic device may receive a random challenge signal from a server. The electronic device may input the random challenge signal into a PUF circuit to generate a private key. The private key generated by the electronic device may be a reference private key. Meanwhile, the server may search for a random challenge signal identical to the random challenge signal sent to the electronic device from a challenge response pair database pre-stored for the electronic device. The server may detect a private key corresponding to the random challenge signal from the challenge response pair database. The private key detected by the server may be a reference private key. The electronic device may receive from the server an authentication code generated based on a reference private key, and the electronic device may generate the authentication code based on the reference private key, and may compare the generated authentication code with the received authentication code to authenticate the certificate. In this specification, a "public key" may refer to a key that one electronic device can share with another electronic device. In an exemplary embodiment, the public key may be used to verify a signature generated with a private key, generate an authentication code for verifying a certificate, or encrypt or decrypt data. The public key may be shared with another electronic device. In this case, the channel connected to the other electronic device may be an insecure channel. In an exemplary embodiment, the public key may decrypt a session key. A session key encrypted with a public key may be decrypted into a private key corresponding to the public key. As used herein, a "derived key" may refer to a key generated by encrypting a private key. A derived key may be exported in place of a private key that cannot be exported, or may be used to perform additional encryption operations. As used herein, a key, such as a "shared key," "session key," "public key," "private key," and "derived key," can be a function (or program) that encrypts or decrypts data. A key can be a means of encrypting and decrypting data, as well as the data itself that is encrypted and decrypted. In this specification, a "shared session key" may be a key generated based on a private key and a public key. The shared session key may encrypt or decrypt a session key. The shared session key generated based on a private key may decrypt a session key. Similarly, the shared session key generated based on a public key may encrypt a session key. In other words, the session key may not be directly encrypted or decrypted with the private key and the public key, but may be encrypted or decrypted with a shared session key generated based on the session key with the private key and the public key. In this specification, a "certificate" may be data including a public key and an authentication code for verifying the integrity of the public key (e.g., whether it has been forged or altered). A certificate may be generated by a trusted server. The certificate generated by the server may be transmitted to an electronic device requesting the public key of the other electronic device. The electronic device may verify the certificate to verify that the public key is intact and use it in subsequent cryptographic protocols. In this specification, a "signature" may be an electronic signature that guarantees that specific data was generated by a specific electronic device and has not been subsequently modified (forged or altered). The signature may be generated using a private key of the specific electronic device. The signature may be transmitted to a counterpart electronic device communicating with the specific electronic device along with the data (e.g., a message) to be communicated. (Messages are merely an example, and digital signatures may also be generated for other information.) In the counterpart electronic device, the signature may be verified based on the public key of the electronic device that sent the data. In this case, the public key may be the key of the electronic device that sent the data and may correspond to the private key. In this specification, a "physically unclonable function (PUF)" may be a function implemented by hardware that cannot be copied. In this case, even if the hardware is the same type and has undergone the same process, each piece of hardware may implement a different physically unclonable function because it has different physical properties. In other words, each piece of hardware has its own unique physical properties, so each piece of hardware may implement a unique physically unclonable function. As a result, each piece of hardware may output a different signal even when a common signal is input. Furthermore, because the physical properties of hardware once created do not change, a physically uncopyable function can output a consistent signal each time a specific signal is input multiple times. However, a physically uncopyable function is a function implemented by physical hardware rather than software, and can be changed by the external environment. On the other hand, due to its unique nature, a physically uncopyable function can be used as a means for authentication systems, etc. In this case, the input of the physically uncopyable function can be called a challenge signal, and the output can be called a response signal. A pair of an input challenge signal and a corresponding response signal can be called a challenge-response pair (CRP). On the other hand, in the present invention, the response signal can be used as the personal key described above. In this specification, a "PUF circuit" may be hardware that implements a physically unclonable function. A PUF circuit may receive a challenge signal as input and generate a response signal. A PUF circuit may obtain the same output value (response signal) for the same input value (challenge signal). However, when the same input value (challenge signal) is input to multiple different PUF circuits, each PUF circuit may obtain a different output value (response signal). In other words, the response signal output by each PUF circuit in response to the same challenge signal may be a unique value for each PUF circuit. In this specification, "response information" may refer to information including one or more data generated based on the response signal. In this specification, the electronic device 100 may generate one or more of a private key, helper data, a public key, and a derived key based on the response signal. In this case, the response information may include one or more of a private key, helper data, a public key, and a derived key. One response information corresponds to one response signal, and multiple response information may correspond to multiple response signals, respectively. In other words, one challenge signal, one response signal, and one response information may correspond to each other. In this specification, a "challenge response pair (CRP) database" may refer to a database including a plurality of challenge response pairs. Each challenge response pair may include a challenge signal and a response signal corresponding to the challenge signal. A challenge response pair database may be established corresponding to a specific electronic device. That is, a plurality of challenge response pair databases may be established corresponding to a plurality of electronic devices. In an exemplary embodiment, when an electronic device is authenticated by a server, the server may store a challenge response pair database for the electronic device, and the server may authenticate the electronic device based on the stored challenge response pair database. As used herein, an "initial signal" may be a signal that the electronic device receives from a server to generate multiple challenge signals for a challenge-response pair database. The electronic device may generate multiple challenge signals from the initial signal. In this specification, a "challenge signal generator" may be a device that receives an initial signal as an input and outputs a challenge signal. Response information corresponding to the challenge signal may be generated by a PUF circuit. The challenge signal generator may repeatedly generate a challenge signal until a preset number of response information is reached. In this case, the generated challenge signals may be different from each other. Unlike a PUF circuit, the challenge signal generator may calculate different output values ​​even when the same input value is obtained.

[0010] FIG. 1a is a schematic diagram illustrating a system for performing a PUF-based cryptographic communication method according to an embodiment of the present invention. 1a, a system 10 for performing a PUF-based cryptographic communication method may include one or more electronic devices 100, 100-T, 100-R, and a server 200. The schematic diagram of system 10 for performing a PUF-based cryptographic communication method shown in FIG. 1 is one example of configuring system 10, and system 10 may be implemented with more or fewer components than those shown. One or more electronic devices 100 and a server 200 may be coupled to transmit and receive data via a communication network 50. The data transmitted and received may include messages sent or received between users, one or more keys for encrypting the messages, certificates for transmitting the keys, and signatures for ensuring the integrity of the data. The electronic device 100 may be a device that transmits and receives data. In an exemplary embodiment, the electronic device 100 may be one or more of a first electronic device 100-T that transmits data and a second electronic device 100-R that receives data. In an exemplary embodiment, an electronic device (e.g., 100-T) may be authenticated by the server 200 to transmit and receive data to and from other electronic devices 100-R and the server, or to obtain a key required for communication. Authentication may be performed based on a challenge-response pair database generated by a unique PUF circuit included in the electronic device 100. The challenge-response pair database may be generated by the electronic device 100 and provided to the server 200. A more detailed description of the process in which the electronic device 100 provides the challenge-response pair database to the server 200 and is authenticated based on the provided challenge-response pair database will be provided below with reference to FIGS. 3 to 6. In an exemplary embodiment, the first electronic device 100-T may be authenticated by the trusted server 200 to communicate with one or more of the second electronic device 100-R and the server 200. In this case, the authentication may be to confirm one or more of whether the first electronic device 100-T is a trustworthy device (e.g., whether it has not been counterfeited, altered, or stolen) and whether it has permission to access the data it is attempting to access. The second electronic device 100-R may also be authenticated by the server 200. In an exemplary embodiment, the electronic device 100 may generate a private key during the authentication process. In this case, the private key may be generated based on a PUF circuit included in the electronic device 100. A more detailed description of the process of generating the private key will be provided later with reference to FIG. 6, which illustrates the configuration of the electronic device 100. In an exemplary embodiment, the first electronic device 100-T may encrypt a session key with a private key. The session key may be a key used to encrypt a message that the first electronic device 100-T transmits to the second electronic device 100-R. The first electronic device 100-T may send the encrypted session key and the encrypted message to the second electronic device 100-R. The second electronic device 100-R may receive the encrypted session key and the encrypted message from the first electronic device 100-T. The second electronic device 100-R may decrypt the session key with the public key of the first electronic device 100-T and decrypt the message using the decrypted session key. Encryption and decryption of messages and session keys will be described in more detail below with reference to FIGS. 13 and 14, which describe message transmission and reception. In an exemplary embodiment, the first electronic device 100-T may receive the public key of the second electronic device 100-R from the server 200. In this case, the public key of the second electronic device 100-R may be generated based on the private key of the second electronic device 100-R. A more detailed description of the process of generating the public key will be provided later with reference to FIGS. 9 to 12, which describe a process of sharing the public key. Similarly, the second electronic device 100-R may receive the public key of the first electronic device 100-T from the server 200. In this case, the public key of the first electronic device 100-T may be generated based on the private key of the first electronic device 100-T. A more detailed description of the process of generating a public key will be given later with reference to FIGS. 9 to 12, which describe a process of sharing a public key. In an exemplary embodiment, the first electronic device 100-T may receive a second certificate of the second electronic device 100-R from the server 200. The second certificate may include an authentication code for verifying the integrity of the second certificate. The first electronic device 100-T may verify the second certificate based on the authentication code. The first electronic device 100-T may verify the second certificate of the second electronic device 100-R and confirm the integrity of the second public key of the second electronic device 100-R. In an exemplary embodiment, the first electronic device 100-T may generate a signature for data (e.g., a message) to be transmitted and transmit the data with the generated signature to the second electronic device 100-R. The data with the generated signature may prove that the data is intact and not forged or altered. The second electronic device 100-R may verify the signature generated for the received data to confirm that the data has not been forged or altered. The signature may be generated by the first electronic device 100-T that transmits the data, and the signature may be verified by the second electronic device 100-R that receives the data. Furthermore, the signature may be generated based on the private key of the first electronic device 100-T, and the signature may be verified based on the public key of the first electronic device 100-T. The server 200 may be connected to each of the electronic devices 100 via a communication network 50. The server 200 may authenticate the electronic devices 100. The server 200 may also distribute one or more of a private key, a public key, and a certificate to each of the electronic devices 100 that transmit and receive data to each other. FIG. 1b is a diagram illustrating a process of a PUF-based cryptographic communication method according to an embodiment of the present invention. Referring to FIG. 1b, the PUF-based encrypted communication method includes step S110 of generating a challenge response pair database for one or more electronic devices 100, step S122 of the server 200 generating a random challenge signal to be transmitted to each electronic device 100, step S124 of each electronic device 100 generating a private key via the PUF circuit 103, step S126 of authenticating each electronic device 100 using each private key, step S132 of generating a certificate for each electronic device 100 including a public key corresponding to the private key, and step S132 of each electronic device 100 verifying the certificate of the other electronic device to obtain the public key of the other electronic device. the first electronic device 100-T generating a signature for the message based on the first private key; and the second electronic device 100-R verifying the signature of the message using the first public key of the first electronic device 100-T. In step S110, a challenge-response pair database may be generated by the PUF circuits 103-T and 103-R of the respective electronic devices 100-T and 100-R. According to an exemplary embodiment, the process is as follows: The first electronic device 100-T may receive an initial signal from the server 200. The first electronic device 100-T may input the received initial signal to the challenge signal generating device 102 to generate one or more challenge signals. Each of the multiple challenge signals may be input to the PUF circuit 103-T. The PUF circuit 103-T may generate a response signal corresponding to each of the plurality of challenge signals. Response information may be generated from the plurality of response signals corresponding to the plurality of challenge signals. A challenge signal, a corresponding response signal, and the response information may be paired and designated as a challenge-response pair. The plurality of challenge-response pairs may be transmitted to the server 200 and stored as a first challenge-response pair database, which will be described in more detail below with reference to FIGS. 3 to 6. Similarly, a second challenge-response pair database may be generated for the second electronic device 100-R. In step S122, the server 200 may generate a random challenge signal to be sent to each electronic device 100. In an exemplary embodiment, the server 200 may send a first random challenge signal to the first electronic device 100-T upon receiving an authentication request from the first electronic device 100-T. Similarly, the server 200 may send a second random challenge signal to the second electronic device 100-T. In step S124, each electronic device 100 may generate a private key (response private key) using the PUF circuit 103. According to an exemplary embodiment, the first electronic device 100-T may input a first random challenge signal to the PUF circuit 103-T and generate a first private key as the response private key. The first electronic device 100-T may transmit the first private key to the server 200. Similarly, the second electronic device 100-R may input a second random challenge signal to the PUF circuit 103-R and generate a second private key as the response private key and transmit it to the server 200. In step S126, each electronic device 100 may be authenticated using each personal key (response personal key). An exemplary embodiment of the process is as follows: The server 200 may search for a first personal key corresponding to the first random challenge signal from a first challenge-response pair database. The server 200 may compare the searched first personal key with the first personal key received from the first electronic device 100-T to determine whether the first electronic device 100-T is authenticated. Similarly, the server 200 may compare a second personal key searched from a second challenge-response pair database with the second personal key received from the second electronic device 100-R to determine whether the second electronic device 100-R is authenticated. This will be described in more detail below with reference to FIG. 8. In step S132, the server 200 may generate a certificate including a public key corresponding to the private key for each electronic device 100. According to an exemplary embodiment, the server 200 may generate a first public key corresponding to the first private key of the first electronic device 100-T when the first electronic device 100-T is authenticated. The server 200 may generate a first certificate including the first public key of the first electronic device 100-T based on the public key of the first electronic device 100-T and the private key of the second electronic device 100-R. The server 200 may transmit the first certificate including the first public key of the first electronic device 100-T to the second electronic device 100-R. Similarly, the server 200 may generate a second certificate including the second public key of the second electronic device 100-R and transmit it to the first electronic device 100-T. This will be described in more detail below with reference to FIGS. 17 and 18. In step S134, each electronic device 100-T, 100-R may verify the certificate of the other electronic device to obtain the public key of the other electronic device 100-R, 100-T. According to an exemplary embodiment, the second certificate received by the first electronic device 100-T may include a first authentication code generated based on a second public key and a first private key (reference private key) retrieved from the server 200. The first electronic device 100-T may generate the second authentication code using the first private key (reference private key) generated via the PUF circuit 103-T and the second public key. The first electronic device 100-T may verify the second certificate by comparing the first authentication code generated by the server 200 with the second authentication code generated by the first electronic device 100-T. If the first authentication code and the second authentication code are the same, the first electronic device 100-T may determine that the second public key included in the second certificate is trustworthy and obtain it. Similarly, the second electronic device 100-R can also verify the first certificate and obtain the first public key, which will be described in more detail below with reference to FIG. In step S142, the first electronic device 100-T sending the message may encrypt a session key for encrypting the message with the second public key of the second electronic device 100-R receiving the data. According to an exemplary embodiment, the first electronic device 100-T may generate a session key (e.g., a message session key) for encrypting a message to be sent to the second electronic device 100-R. The first electronic device 100-T may encrypt the message with the message session key. The first electronic device 100-T may encrypt the message with the second public key. The first electronic device 100-T may send the encrypted message session key and the encrypted message to the second electronic device 100-R. This will be described in more detail below with reference to FIG. 15. In step S144, the second electronic device 100-R receiving the message may decrypt the message using the session key (message session key) decrypted with the generated second private key. According to an exemplary embodiment, the second electronic device 100-R may decrypt the message session key encrypted with the generated second private key to obtain the message session key. The second electronic device 100-R may decrypt the message encrypted with the message session key. This will be described in more detail below with reference to FIG. 16. In step S152, the first electronic device 100-T may generate a signature for the message based on the generated first private key. According to an exemplary embodiment, the first electronic device 100-T may generate a unique random number based on environmental conditions and generate a signature session key based on the random number. The first electronic device 100-T may generate a signature for the message based on the first private key and the signature session key. This will be described in more detail below with reference to FIG. 13. In step S154, the second electronic device 100-R may verify the signature of the message using the first public key of the first electronic device 100-T. According to an exemplary embodiment, the second electronic device 100-R may generate a signature based on the first public key of the first electronic device 100-T and a signature session key. The second electronic device 100-R may verify the signature by comparing the generated signature with the signature received from the first electronic device 100-T. This will be described in more detail below with reference to FIG. 14.

[0011] FIG. 2 is a block diagram illustrating a configuration of an electronic device that constructs a challenge-response pair database and performs PUF-based cryptographic communication according to an embodiment of the present invention. 2, the electronic device 100 may include a communication device 101, a challenge signal generation device 102, a PUF circuit 103, a random number generator 104, and a controller 105. The block diagram of the electronic device 100 shown in FIG. 2 is an example of the electronic device 100, and the electronic device 100 may be realized with more or fewer components than those shown. The electronic device 100 may be a first electronic device 100-T that transmits data or a second electronic device 100-R that receives data. The electronic device 100 may not store the required data permanently when authenticating to the server 200, sending and receiving data (e.g., messages), generating and verifying a signature, or verifying the integrity of a certificate, but may temporarily generate and use the data based on the PUF circuit 103 and then delete it. The communication device 101 can send and receive data to and from other electronic devices 100 and the server 200 . The contents according to an exemplary embodiment are as follows: The communication device 101 may receive an initial signal from the server 200. The communication device 101 may transmit the initial signal to the challenge signal generating device 102. The challenge signal generating device 102 may generate one or more challenge signals by acquiring the initial signal. One or more response signals may be generated in response to each of the one or more challenge signals. A challenge-response pair database may be generated based on the one or more challenge signals and the one or more response signals. The communication device 101 may transmit one or more of the response signals and the challenge-response pair database to the server 200. According to another exemplary embodiment, the communication device 101 of the first electronic device 100-T may receive the public key of the second electronic device 100-R from the server 200. The communication device 101 of the first electronic device 100-T may also transmit an encrypted session key and an encrypted message to the second electronic device 100-R. In an exemplary embodiment, the communication device 101 of the second electronic device 100-R may also perform the same function. According to another exemplary embodiment, the communication device 101 of the second electronic device 100-R may receive the public key of the first electronic device 100-T from the server 200. The communication device 101 of the first electronic device 100-T may also send a session key, an encrypted message, and a signature to the second electronic device 100-R. In an exemplary embodiment, the communication device 101 of the second electronic device 100-R may also perform the same functions. According to another exemplary embodiment, the communication device 101 of the first electronic device 100-T may receive a second certificate of the second electronic device 100-R from the server 200. The communication device 101 of the first electronic device 100-T may also transmit a session key and an encrypted message to the second electronic device 100-R. In an exemplary embodiment, the communication device 101 of the second electronic device 100-R may also perform the same function. The challenge signal generation device 102 may receive as input an initial signal received via the communication device 101. The challenge signal generation device 102 may output one or more randomly generated challenge signals in response to the input of the initial signal. In addition, the challenge signal generation device 102 may generate a second challenge signal when response information corresponding to the first challenge signal is generated. The PUF circuit 103 may be a circuit that implements a PUF function that cannot be physically copied. Multiple PUF circuits 103 may obtain different output values ​​(response signals) in response to the same input value (challenge signal). In other words, the response signal may be a unique value of only the PUF circuit 103 that generated the response signal. However, if the same challenge signal is input multiple times, one PUF circuit 103 may output the same response signal multiple times. According to an exemplary embodiment, the PUF circuit 103 may calculate a response signal corresponding to each of a plurality of challenge signals. The controller 105 may acquire the response signals and generate authentication information including data necessary for authentication based on the response signals. A particular challenge signal, the corresponding response signal, and the corresponding authentication information may be designated as a challenge-response pair. The plurality of challenge-response pairs may be transmitted to the server 200. The server 200 may generate a challenge-response pair database based on the plurality of challenge-response pairs. A more detailed description of the electronic device 100 generating a challenge-response pair database will be provided below with reference to FIGS. 3 to 6.

[0012] According to another exemplary embodiment, the PUF circuit 103 may generate a private key using a random challenge signal as an input. The PUF circuit 103 may receive a random challenge signal received from the server 200 via the communication device 101 as an input. The PUF circuit 103 may output a corresponding response signal in response to the input of the random challenge signal. The PUF circuit 103 may generate a private key based on the corresponding response signal. Specifically, the electronic device 100 may input the same random challenge signal to the PUF circuit 103 multiple times and obtain multiple corresponding response signals for each input. In this case, since the PUF circuit 103 is a circuit that calculates the corresponding response signal based on the physical characteristics of the circuit itself, it may calculate different corresponding response signals depending on the surrounding environment at the moment the challenge signal is input. As a result, the multiple corresponding response signals obtained by the PUF circuit 103 may be discrete values ​​rather than a single specific value. The PUF circuit 103 may perform pre-defined post-processing on the plurality of corresponding response signals to generate a private key. In an exemplary embodiment, the PUF circuit 103 may obtain a private key by voting on the plurality of corresponding response signals. The electronic device 100 may designate a representative corresponding response signal as the private key based on the frequency of occurrence of the plurality of corresponding response signals. The random number generator 104 may generate random numbers (random numbers). In an exemplary embodiment, the random number generator 104 may be a true random number generator (TRNG) 105. The true random number generator 104 may generate random numbers from physical phenomena of hardware. Unlike a pseudo random number generator (PRNG), the true random number generator 104 may utilize the randomness of physical phenomena rather than algorithms. In an exemplary embodiment, the physical phenomenon may be phenomena such as electromagnetic thermal noise, shot noise in semiconductor devices, radioactive decay reactions, and stochastic reactions when detecting photons. This allows a different random number to be generated each time even if the same random number generator 104 is used multiple times. The random number generator 104 can set the generated random number as a session key for encrypting a message. The controller 105 controls the communication device 101, the PUF circuit 103, the challenge signal generating device 102, and the random number generator 105, and can calculate data obtained from the communication device 101, the PUF circuit 103, the challenge signal generating device 102, and the random number generator 105. FIG. 3 is a flowchart illustrating a process of constructing a PUF-based challenge-response pair database according to an embodiment of the present invention. Referring to FIG. 3, a method S300 for constructing a challenge-response pair database may include a step S310 in which the server 200 sends an initial signal to the electronic device 100, a step S320 in which the electronic device 100 generates response information in response to the initial signal, a step S330 in which the electronic device 100 sends the response information to the server 200, and a step S340 in which the server 200 generates a challenge-response pair database. In step S310, server 200 may send an initial signal to electronic device 100. In an exemplary embodiment, server 200 may send an initial signal to electronic device 100 that it wishes to send or receive data or share one or more keys required for communication. In step S320, the electronic device 100 may generate response information in response to the initial signal. In an exemplary embodiment, the electronic device 100 may generate multiple challenge signals in response to the received initial signal and generate response information corresponding to each challenge signal. Details regarding the electronic device 100 generating multiple challenge signals and corresponding response information will be described below with reference to FIG. 4. In step S330, the electronic device 100 may transmit response information to the server 200. Specifically, the electronic device 100 may transmit the generated challenge signals and the corresponding response information to the server 200. In step S340, the server 200 may generate a challenge-response pair database. Specifically, the server 200 may store the challenge signals received from the electronic device 100, the corresponding response information, and the unique identification information of the electronic device 100 to generate the database.

[0013] 4 is a flowchart illustrating a method for generating a plurality of challenge signals and a plurality of corresponding response information by an electronic device 100 according to an embodiment of the present invention. The method illustrated in FIG. 4 may be performed, for example, by the electronic device 100 described above. Although the illustrated flowchart describes the method as being divided into a plurality of steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into more detailed steps, or one or more additional steps not illustrated may be performed. In an exemplary embodiment, the data for constructing the challenge-response pair database may be generated by the PUF circuit 103 within the electronic device 100 requesting authentication. Referring to FIG. 4, the method S400 for generating a plurality of challenge signals and corresponding plurality of response information may include step S410 of receiving an initial signal, step S420 of generating a challenge signal, step S430 of generating a personal key and response information, step S430 of transmitting unique identification information, the challenge signal, and the response information, and step S450 of repeating steps S420 to S440 until a predetermined number of challenge signal and response information pairs are obtained. In step S410, the electronic device 100 may receive an initial signal. According to an exemplary embodiment, the content is as follows: The communication device 101 in the electronic device 100 may receive a randomly generated signal from the server 200 as the initial signal. The communication device 101 may transmit the initial signal to the challenge signal generating device 102. In step S420, the electronic device 100 may generate a challenge signal. According to an exemplary embodiment, the content is as follows: The electronic device 100 may input an initial signal to the challenge signal generating device 102. The electronic device 100 may obtain a challenge signal from the challenge signal generating device 102. In step S430, the electronic device 100 may generate a personal key and response information. According to an exemplary embodiment, the electronic device 100 may generate a personal key corresponding to the challenge signal. The electronic device 100 may generate corresponding response information based on the generated personal key. More detailed information regarding this will be described below with reference to FIG. 5. In step S440, the electronic device 100 may transmit the unique identification information, the challenge signal, and the response information to the server 200. The contents according to an exemplary embodiment are as follows: The unique identification information may be unique information corresponding to multiple electronic devices 100, allowing the multiple electronic devices 100 to be distinguished from one another. The challenge signal and the response information may form a pair. The electronic device 100 may transmit the unique identification information and the pair of the challenge signal and the response information to the server 200. In step S450, the electronic device 100 may repeat steps S420 to S440 until a preset number of pairs of challenge signals and response information are generated. Specifically, the challenge signal generating device 102 may generate a first challenge signal by receiving an initial signal. The electronic device 100 may generate response information corresponding to the first challenge signal in step S430, and transmit the first challenge signal and the corresponding response information to the server in step S450. When the electronic device 100 generates response information corresponding to the first challenge signal and transmits it to the server 200, the challenge signal generating device 102 may newly generate a second challenge signal (in this case, the second challenge signal may be different from the first challenge signal). The electronic device 100 may also generate second response information corresponding to the second challenge signal and transmit it to the server 200. The electronic device 100 may generate a third challenge signal by obtaining the second response information. As described above, the electronic device 100 may repeatedly generate the challenge signal and the corresponding response information to obtain a plurality of pairs of the challenge signal and the response information. The electronic device 100 may generate new challenge signals until the number of pairs of the challenge signal and the response information reaches a predetermined number. In an exemplary embodiment, the predetermined number is 1.6*10 8 It could be.

[0014] FIG. 5 is a flowchart illustrating a method for generating response information according to an embodiment of the present invention. In step S510, the electronic device 100 may generate a personal key. The details according to an exemplary embodiment are as follows: The personal key may be a unique key corresponding to each of the electronic devices 100 and may be a key that cannot be accessed by other users. The electronic device 100 may input the generated challenge signal to the PUF circuit. The electronic device 100 may generate the personal key by processing a signal output from the PUF circuit in response to the input challenge signal. A more detailed description of obtaining the personal key by processing the output signal will be provided below with reference to FIG. 6. In step S520, the electronic device 100 (e.g., 100-T) may generate a derived key and helper data based on the private key. The content according to an exemplary embodiment is as follows: The derived key may be transmitted to another electronic device (e.g., 100-R) in place of the private key, or may be used to perform additional encryption operations. The electronic device 100 may generate a derived key by inputting the private key to a predetermined derivation function. The predetermined derivation function may be a function that makes it impossible to predict an input signal corresponding to an output signal from an output signal. For example, the derivation function may be a hash function. A hash function may be a function that receives input data of an arbitrary size and outputs data of a predetermined fixed size. A hash function may also be a function that obtains different output data depending on the input data. The helper data may be data for correcting errors in the private key generated based on the PUF circuit. The helper data may be generated based on a plurality of response signals generated in the process of generating the private key. More details regarding the generation of the helper data will be described later with reference to FIG. 6, which explains the generation of the private key. In step S530, the electronic device 100 may generate response information including one or more of a private key, a derived key, and helper data. In an exemplary embodiment, the private key, the derived key, and the helper data may be data generated based on a challenge signal.

[0015] 6 is a flowchart illustrating a method for generating a private key according to an embodiment of the present invention. The method illustrated in FIG. 6 may be performed, for example, by the electronic device 100 described above. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not illustrated may be performed. Referring to FIG. 6, the step S510 of generating a private key may include the step S610 of generating a response signal and the step S620 of voting to obtain a private key. In step S610, the electronic device 100 may generate a response signal. According to an exemplary embodiment, the process is as follows: The electronic device 100 may input a challenge signal (e.g., a first challenge signal) to the PUF circuit 103. The electronic device 100 may obtain a response signal corresponding to the input challenge signal from the PUF circuit 103. In an exemplary embodiment, the electronic device 100 may input the same challenge signal multiple times to the PUF circuit 103 and obtain multiple response signals corresponding to each input. In this case, since the PUF circuit 103 is a circuit that calculates response signals based on its own physical characteristics, it may calculate different response signals depending on the surrounding environment at the moment the challenge signal is input. As a result, the multiple response signals obtained by the electronic device 100 may be discrete values ​​rather than a single specific value. In step S620, the electronic device 100 may obtain a personal key by voting for the plurality of response signals. According to an exemplary embodiment, the electronic device 100 may generate a personal key by performing pre-defined post-processing on the plurality of response signals. In an exemplary embodiment, the electronic device 100 may determine a representative response signal based on the frequency of occurrence of the plurality of response signals. The electronic device 100 may determine the response signal with the highest frequency of occurrence among the plurality of response signals as the representative response signal. Alternatively, the electronic device 100 may determine the representative response signal by averaging the plurality of response signals. Alternatively, if the plurality of response signals are normally distributed, the electronic device 100 may determine the representative response signal by averaging only values ​​included in a predetermined dispersion range from the average. The electronic device 100 may designate the representative response signal as the personal key. The electronic device 100 may generate helper data based on multiple response signals corresponding to one challenge signal. The helper data may be data for correcting errors in the personal key generated by the corresponding challenge signal. The electronic device 100 may compare the multiple response signals with the personal key generated from the multiple response signals. The user device 100 may calculate the difference between each of the multiple response signals and the personal key. When a new personal key is generated based on the calculated differences, the electronic device 100 may generate helper data that can correct errors in the generated personal key. In an exemplary embodiment, the electronic device 100 may generate helper data that allows the average to be calculated when a non-average response signal is output from the PUF circuit 103 based on the variance and average of the normally distributed response signal.

[0016] FIG. 7 is a flowchart illustrating a process for authenticating an electronic device based on a constructed challenge-response pair database according to one embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed in a different order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be added. Referring to FIG. 7, the method for authenticating the electronic device 100 may include step S710 in which the server 200 transmits a random challenge signal to the electronic device 100 requesting authentication, step S720 in which the electronic device 100 inputs the random challenge signal into a PUF circuit of the electronic device 100 and transmits corresponding response information generated by the input to the server 200, and step S730 in which the server 200 compares the corresponding response information with a challenge response pair database to determine whether to authenticate the electronic device 100. In step S710, the server 200 may transmit a random challenge signal to the electronic device 100 requesting authentication. The process according to an exemplary embodiment is as follows: The server 200 may receive an authentication request from the electronic device 100 requesting authentication. The server 200 may generate a random challenge signal by receiving the authentication request. The server 200 may transmit the generated random challenge signal to the electronic device 100 requesting authentication. In step S720, the electronic device 100 may transmit response information generated in response to the random challenge signal to the server 200. According to an exemplary embodiment, the electronic device 100 may receive a random challenge signal via the communication device 101. The electronic device 100 may input the received random challenge signal to the PUF circuit 103 and obtain a corresponding response signal as an output. The output response signal may have a one-to-one correspondence with the input random challenge signal. A private key may be generated based on the response signal. The electronic device 100 may process the corresponding response signal to generate response information related to user authentication. The method of processing the corresponding response signal to generate the corresponding response information is the same as the method of generating the response information from the response signal in FIGS. 5 and 6 described above. The electronic device 100 may send the generated response information to the server 200. The response information may include a private key. In step S730, it may be determined whether the electronic device 100 is authenticated. According to an exemplary embodiment, the process is as follows: The server 200 may receive response information corresponding to a random challenge signal transmitted from the electronic device 100. The server 200 may determine the received response information based on a pre-collected challenge-response pair database. The pre-collected challenge-response pair database may store a plurality of pairs of challenge signals input to the PUF circuit 103 of the electronic device 100 and response information generated corresponding to each of the plurality of challenge signals. The server 200 may search a challenge response pair database for the random challenge signal sent to the electronic device 100 and its corresponding response information. The server 200 may compare the response information received from the electronic device 100 with the response information searched for in the challenge response pair database. The server 200 may approve the authentication request of the electronic device 100 if the received response information is the same as the searched response information. Alternatively, the server 200 may reject the authentication request of the electronic device 100 if the received response information is different from the searched response information.

[0017] 8 is a flowchart illustrating a process for a server to authenticate an electronic device according to another embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be added. Referring to FIG. 8, the method for the server 200 to authenticate the electronic device 100 may include step S810 in which the server 200 sends a random challenge signal to the electronic device 100, step S820 in which the electronic device 100 generates a response private key, step S830 in which the electronic device 100 sends the response private key to the server 200, and step S840 in which the server 200 determines whether to authenticate the electronic device 100. In step S810, the server 200 may transmit a random challenge signal to the electronic device 100. The contents according to an exemplary embodiment are as follows: The server 200 may transmit a randomly generated random challenge signal (hereinafter referred to as a random challenge signal) to the electronic device 100 requesting authentication. In detail, the server 200 may receive an authentication request from the electronic device 100 that wishes to be authenticated. The server 200 may generate a random challenge signal by receiving the authentication request. The server 200 may transmit the generated random challenge signal to the electronic device 100 that requested authentication. In step S820, the electronic device 100 may generate a response private key. According to an exemplary embodiment, the process is as follows: The electronic device 100 may receive a random challenge signal from the server 200. The electronic device 100 may input the received random challenge signal to the PUF circuit 103 and obtain a response signal as an output. The output response signal may have a one-to-one correspondence with the input random challenge signal. The electronic device 100 may designate the output response signal as a private key. In step S830, the electronic device 100 may send a response private key to the server 200. According to an exemplary embodiment, the content is as follows: The electronic device 100 may send a response private key generated in response to the random challenge signal to the server 200. In step S840, the server 200 may determine whether the electronic device 100 is authenticated. According to an exemplary embodiment, the process is as follows: The server 200 may receive a response private key generated in response to a random challenge signal transmitted from the electronic device 100. The server 200 may determine the received response private key based on a pre-stored challenge-response pair database. The pre-stored challenge-response pair database may be generated based on the PUF circuit 103 of the electronic device 100 according to FIGS. 3 to 6. The challenge response pair database may include a plurality of challenge response pairs. The challenge response pair may include a pair of a challenge signal and a private key based on the PUF circuit 103. The challenge signal may be a signal input to the PUF circuit 103. The private key may be a key generated based on a response signal output by the PUF circuit 103 in response to the challenge signal. In this case, the plurality of challenge response pairs may be different from each other. The server 200 may search a challenge response pair database for the random challenge signal sent to the electronic device 100 and its corresponding response private key. The server 200 may compare the response private key received from the electronic device 100 with the response private key searched for in the challenge response pair database. If the received response private key is the same as the searched response private key, the server 200 may approve the authentication request of the electronic device 100. Alternatively, if the received response private key is different from the searched response private key, the server 200 may reject the authentication request of the electronic device 100.

[0018] 9 is a flowchart illustrating a process in which a server shares a first public key of a first electronic device with a second electronic device according to one embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed in a different order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be added. Referring to FIG. 9, a method for sharing public keys among multiple electronic devices 100 may include step S910 in which the second electronic device 100-R requests a first public key of the first electronic device 100-T from the server 200, step S920 in which the server 200 authenticates the first electronic device 100-T based on the first random challenge signal, step S930 in which the server 200 generates a first public key of the first electronic device 100-T, and step S940 in which the server 200 transmits the first public key of the first electronic device 100-T to the second electronic device 100-R. In step S910, the second electronic device 100-R may request the first public key of the first electronic device 100-T from the server 200. According to an exemplary embodiment, the second electronic device 100-R may be a device that wishes to receive data (e.g., a message) from the first electronic device 100-T. The second electronic device 100-R may request the first public key of the first electronic device 100-T to verify a signature generated on the data received from the first electronic device 100-T. The second electronic device 100-R may request the server 200 to obtain the first public key of the first electronic device 100-T. In step S920, the server 200 may authenticate the first electronic device 100-T based on the first random challenge signal. The process according to an exemplary embodiment is as follows: The server 200 may randomly generate a signal (hereinafter, referred to as the first random challenge signal) in response to a request for the first public key of the first electronic device 100-T from the second electronic device 100-R. The server 200 may transmit the first random challenge signal to the first electronic device 100-T. The server 200 may receive a first private key corresponding to the first random challenge signal from the first electronic device 100-T. The server 200 may authenticate the first electronic device 100-T based on the first random challenge signal and the first private key. Details regarding the server 200 authenticating the first electronic device 100-T are omitted because they are the same as those for authenticating the electronic device 100 in FIG. 8. In step S930, the server 200 may generate a first public key for the first electronic device 100-T. The process according to an exemplary embodiment is as follows: The server 200 may acquire a first private key for the first electronic device 100-T during the process of authenticating the first electronic device 100-T. In this case, the first private key acquired by the server 200 may be a response private key generated in the first electronic device 100-T in response to the first random challenge signal. Alternatively, the first private key acquired by the server 200 may be a response private key searched for in response to the first random challenge signal from a first challenge-response pair database stored by the server 200. The server 200 may generate a first public key based on the first private key. This will be described in more detail below with reference to FIG. 10. In step S940, the server 200 may transmit the first public key of the first electronic device 100-T to the second electronic device 100-R. According to an exemplary embodiment, the process is as follows: The server 200 may transmit the first public key generated in step S930 to the second electronic device 100-R that requested the first public key of the first electronic device 100-T. In an exemplary embodiment, the first public key may be included in a first certificate and transmitted to the second electronic device 100-R. The second electronic device 100-R may verify the first certificate to obtain the first public key.

[0019] 10 is a flowchart illustrating the operation of a server that shares a first public key of a first electronic device with a second electronic device, according to one embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be performed. 10, the method for the server 200 to share the first public key of the first electronic device 100-T with the second electronic device 100-R may include step S1010 in which the server 200 receives a request for the first public key of the first electronic device 100-T from the second electronic device 100-R, step S1020 in which the server 200 authenticates the first electronic device 100-T based on the first random challenge signal, step S1030 in which the server 200 acquires a first private key for the first electronic device 100-T corresponding to the first random challenge signal, step S1040 in which the server 200 inputs the first public key into a preset public key generation function to generate the first public key, and step S1050 in which the server 200 transmits the first public key of the first electronic device 100-T to the second electronic device 100-R. In step S1010, the server 200 may be requested by the second electronic device 100-R for the first public key of the first electronic device 100-T. The content according to an exemplary embodiment is as follows: The second electronic device 100-R may be a device that wishes to receive data (e.g., a message) from the first electronic device 100-T. The second electronic device 100-R may request the first public key of the first electronic device 100-T to verify a signature generated on the data received from the first electronic device 100-T. The server 200 may be requested by the second electronic device 100-R for the first public key of the first electronic device 100-T. In step S1020, the first electronic device 100-T may be authenticated based on the first random challenge signal. The details of the server 200 authenticating the first electronic device 100-T are the same as those of the server 200 authenticating the electronic device 100 in FIG. 8, and therefore will not be repeated. In step S1030, the server 200 may acquire a first personal key corresponding to the first random challenge signal for the first electronic device 100-T. The content according to an exemplary embodiment is as follows: The server 200 may acquire a first personal key for the first electronic device 100-T in the process of authenticating the first electronic device 100-T. In this case, the first personal key acquired by the server 200 may be a response personal key generated in the first electronic device 100-T in response to the first random challenge signal. Alternatively, the first personal key acquired by the server 200 may be a response personal key searched for in response to the first random challenge signal from a first challenge-response pair database stored by the server 200. In step S1040, the server 200 may input the first private key into a preset public key generation function to generate a first public key. According to an exemplary embodiment, the first public key of the first electronic device 100-T may be a unique key corresponding to the first private key of the first electronic device 100-T. The first public key of the first electronic device 100-T may be a key accessible not only to the second electronic device 100-R but also to all other users' electronic devices 100. The preset public key generation function may be a function that makes it impossible to predict an input signal corresponding to an output signal from an output signal. In an exemplary embodiment, the public key generation function may be an Elliptic Curve Cryptography (ECC) function. The Elliptic Curve Cryptography function may be a function including a quadratic equation on an elliptic curve. In step S1050, the server 200 may transmit the first public key of the first electronic device 100-T to the second electronic device 100-R. The process according to an exemplary embodiment is as follows: The server 200 may transmit the first public key of the first electronic device 100-T to the second electronic device 100-R that has requested the first public key of the first electronic device 100-T. In this case, the server 200 may generate a first certificate including the first public key and transmit the first certificate to the second electronic device 100-R. The second electronic device 100-R may verify the first certificate and obtain the first public key included in the first certificate.

[0020] 11 is a flowchart illustrating a process in which a server shares a second public key of a second electronic device with a first electronic device according to one embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed in a different order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be added. Referring to FIG. 11, a method for sharing public keys among multiple electronic devices 100 may include step S1110 in which the first electronic device 100-T requests a second public key of the second electronic device 100-R from the server 200, step S1120 in which the server 200 authenticates the second electronic device 100-R based on the second random challenge signal, step S1130 in which the server 200 generates a second public key of the second electronic device 100-R, and step S1140 in which the server 200 transmits the second public key of the second electronic device 100-R to the first electronic device 100-T. In step S1110, the first electronic device 100-T may request the second public key of the second electronic device 100-R from the server 200. According to an exemplary embodiment, the first electronic device 100-T may be a device that intends to transmit data (e.g., a message) to the second electronic device 100-R. The first electronic device 100-T may request the second public key of the second electronic device 100-R to encrypt the data to be transmitted to the second electronic device 100-R. The first electronic device 100-T may request the server 200 to obtain the second public key of the second electronic device 100-R. In step S1120, the second electronic device 100-R may be authenticated based on the second random challenge signal. The process according to an exemplary embodiment is as follows: The server 200 may randomly generate a signal (hereinafter, referred to as the second random challenge signal) in response to a request for the second public key of the second electronic device 100-R from the first electronic device 100-T. The server 200 may transmit the second random challenge signal to the second electronic device 100-R. The server 200 may receive a second private key corresponding to the second random challenge signal from the second electronic device 100-R. The server 200 may authenticate the second electronic device 100-R based on the second random challenge signal and the second private key. Details regarding the server 200 authenticating the second electronic device 100-R are omitted because they are the same as those for authenticating the electronic device 100 in FIG. 8. In step S1130, the server 200 may generate a second public key for the second electronic device 100-R. The process according to an exemplary embodiment is as follows: The server 200 may acquire a second private key for the second electronic device 100-R during the process of authenticating the second electronic device 100-R. In this case, the second private key acquired by the server 200 may be a response private key generated in the second electronic device 100-R in response to the second random challenge signal. Alternatively, the second private key acquired by the server 200 may be a response private key searched for in response to the second random challenge signal from a second challenge-response pair database stored by the server 200. The server 200 may generate a second public key based on the second private key. This will be described in more detail below with reference to FIG. 12. In step S1140, the server 200 may transmit the second public key of the second electronic device 100-R to the first electronic device 100-T. According to an exemplary embodiment, the server 200 may transmit the second public key generated in step S1130 to the first electronic device 100-T that requested the second public key of the second electronic device 100-R. In an exemplary embodiment, the second public key may be included in a second certificate and transmitted to the second electronic device 100-R. The second electronic device 100-R may verify the second certificate to obtain the second public key.

[0021] 12 is a flowchart illustrating the operation of a server that shares a second public key of a second electronic device with a first electronic device, according to one embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be performed. 12, the method for the server 200 to share the second public key of the second electronic device 100-R with the first electronic device 100-T may include step S1210 in which the server 200 receives a request for the second public key of the second electronic device 100-R from the first electronic device 100-T; step S1220 in which the server 200 authenticates the second electronic device 100-R based on the second random challenge signal; step S1230 in which the server 200 acquires a second private key corresponding to the second random challenge signal for the second electronic device 100-R; step S1240 in which the server 200 inputs the second public key into a preset public key generation function to generate the second public key; and step S1250 in which the server 200 transmits the second public key of the second electronic device 100-R to the first electronic device 100-T. In step S1210, the server 200 may be requested by the first electronic device 100-T for the second public key of the second electronic device 100-R. According to an exemplary embodiment, the content is as follows: The first electronic device 100-T may be a device that intends to transmit data to the second electronic device 100-R. The first electronic device 100-T may request the second public key of the second electronic device 100-R to encrypt data to be transmitted to the second electronic device 100-R. The server 200 may be requested by the first electronic device 100-T for the second public key of the second electronic device 100-R. In step S1220, the server 200 may authenticate the second electronic device 100-R based on the second random challenge signal. The details of the server 200 authenticating the second electronic device 100-R are the same as those of the server 200 authenticating the electronic device 100 in FIG. 8, and therefore will not be repeated. In step S1230, the server 200 may acquire a second private key corresponding to the second random challenge signal for the second electronic device 100-R. The content according to an exemplary embodiment is as follows: The server 200 may acquire a second private key for the second electronic device 100-R in the process of authenticating the second electronic device 100-R. In this case, the second private key acquired by the server 200 may be a response private key generated in the second electronic device 100-R in response to the second random challenge signal. Alternatively, the second private key acquired by the server 200 may be a response private key searched for in response to the second random challenge signal from a second challenge-response pair database stored by the server 200. In step S1240, the server 200 may input the second private key into a preset public key generation function to generate a second public key. According to an exemplary embodiment, the second public key of the second electronic device 100-R may be a unique key corresponding to the second private key of the second electronic device 100-R. The second public key of the second electronic device 100-R may be a key accessible not only to the first electronic device 100-T but also to all other users' electronic devices 100. The preset public key generation function may be a function that makes it impossible to predict an input signal corresponding to an output signal from an output signal. In an exemplary embodiment, the public key generation function may be an elliptic curve cryptography (ECC) function. The elliptic curve cryptography function may be a function including a quadratic equation on an elliptic curve. In step S1250, the server 200 may transmit the second public key of the second electronic device 100-R to the first electronic device 100-T. According to an exemplary embodiment, the server 100 may transmit the second public key of the second electronic device 100-R to the first electronic device 100-T that has requested the second public key of the second electronic device 100-R. In this case, the server 200 may generate a second certificate including the second public key and transmit the second certificate to the first electronic device 100-T. The first electronic device 100-T may verify the second certificate and obtain the second public key included in the second certificate.

[0022] 13 is a flowchart illustrating a process for a first electronic device to send a message to a second electronic device according to an embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be performed. Referring to FIG. 13, the process of the first electronic device 100-T sending a message to the second electronic device 100-R may include step S1310 in which the first electronic device 100-T generates a first personal key, step S1320 in which the first electronic device 100-T generates a session key and encrypts the message with the session key, step S1330 in which the first electronic device 100-T generates a signature based on the first personal key, and step S1340 in which the first electronic device 100-T sends the session key, the encrypted message, and the signature to the second electronic device 100-R. In step S1310, the first electronic device 100-T may generate a first private key. The process according to an exemplary embodiment is as follows: The first electronic device 100-T may make an authentication request to the server 200 connected via a secure channel. The first electronic device 100-T may receive a first random challenge signal in response to the authentication request from the server 200. The first electronic device 100-T may input the first random challenge signal into a PUF circuit to obtain a first private key. A more detailed description thereof is omitted as it is the same as that described above with reference to FIGS. 2, 4 to 6. In step S1320, the first electronic device 100-T may generate a session key and encrypt a message using the session key. The process according to an exemplary embodiment is as follows: The first electronic device 100-T may include a random number generator 104. The first electronic device 100-T may generate a session key using the random number generator 104. A detailed description of generating a session key using the random number generator 104 is omitted here, as it is the same as that described above with reference to FIG. 2. The first electronic device 100-T may generate a message session key by inputting the generated session key into a random number function that converts a 640-bit session key into a 128-bit session key. Hereinafter, the session key used to encrypt a message may be the message session key. The first electronic device 100-T may decrypt (encrypt) the message using the session key. In step S1330, the first electronic device 100-T may generate a signature based on the private key. An exemplary embodiment is as follows: The first electronic device 100-T may generate a signature by inputting the first private key generated in step S1310 into a preset signature generation function. The first electronic device 100-T may also generate a session key and generate a signature by inputting the first private key and the session key into a preset signature generation function. In this case, the session key used to generate the signature (hereinafter, the signature session key) may be different from the message session key. The signature session key may be generated by inputting a session key generated by a random number generator into a random number function that converts the 640-bit session key into a 256-bit key, and then inputting the key into a range check function that checks whether the key is within the range of an elliptic curve encryption function. In this case, the preset signature generation function may be an elliptic curve function that makes it impossible to predict an input signal corresponding to an output signal from an output signal. In an exemplary embodiment, the preset signature generation function may be an Elliptic Curve Digital Signature Algorithm (ECDSA). On the other hand, the message session key may be a key generated to encrypt a message to be sent to the second electronic device 100-R. In an exemplary embodiment, the first electronic device 100-T includes a random number generator 104 and may generate the message session key from the session key generated by the random number generator 104. In this case, the generated signature may be transmitted to the second electronic device 100-R along with the message. The signature may be verified by the second electronic device 100-R based on the first public key corresponding to the first private key. This will be described in more detail below with reference to step S1430 of FIG. 14. In step S1340, the first electronic device 100-T may send the session key, the encrypted message, and the signature to the second electronic device 100-R. In an exemplary embodiment, the signature generated for the message may be the signature generated in step S1330. The encrypted message may be the message encrypted in step S1320.

[0023] 14 is a flowchart illustrating a process in which a second electronic device receives a message from a first electronic device according to an embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be performed. Referring to FIG. 14, the process of the second electronic device 100-R receiving a message from the first electronic device 100-R may include step S1410 in which the first electronic device 100-T sends a session key, an encrypted message, and a signature to the second electronic device 100-R, step S1420 in which the second electronic device 100-R obtains the first public key of the first electronic device, step S1430 in which the second electronic device 100-R verifies the signature based on the first public key of the first electronic device 100-R, and step S1440 in which the second electronic device 100-R decrypts the message encrypted with the session key. In step S1410, the first electronic device 100-T may send the session key (e.g., the message session key), the encrypted message, and the signature to the second electronic device 100-R. In an exemplary embodiment, the signature generated on the message may be the signature generated by the first electronic device 100-T in step S1330. The encrypted message may be the message encrypted by the first electronic device 100-T in step S1320. In step S1420, the second electronic device 100-R may obtain the first public key of the first electronic device 100-T. The process according to an exemplary embodiment is as follows: The second electronic device 100-R may request the first public key of the first electronic device 100-T from the server 200 connected via a secure channel. The server 200 may generate the first public key of the first electronic device 100-T and transmit it to the second electronic device 100-R. The detailed process is the same as that described above with reference to FIGS. 9 and 10, and therefore will not be repeated here. In step S1430, the second electronic device 100-R may verify the signature based on the first public key of the first electronic device 100-T. According to an exemplary embodiment, the first electronic device 100-T may generate a signature by inputting the first public key of the first electronic device 100-T obtained in step S1420 into a preset signature generation function. The second electronic device 100-R may also receive a session key and generate a signature by inputting the first private key and the session key into a preset signature generation function. In this case, the preset signature generation function may be a function that represents an elliptic curve and that makes it impossible to predict an input signal corresponding to the output signal from the output signal. In an exemplary embodiment, the preset signature generation function may be an Elliptic Curve Digital Signature Algorithm (ECDSA). Meanwhile, the session key may be a key received for encrypting a message received from the first electronic device 100-T. The second electronic device 100-R may compare the signature generated based on the first public key of the first electronic device 100-T with the signature received from the first electronic device 100-T. The second electronic device 100-R may determine whether the signature can be verified based on whether the signature generated by the second electronic device 100-R is identical to the received signature. In an exemplary embodiment, the second electronic device 100-R may determine that the signature is verified if the signature generated by the second electronic device 100-R is identical to the received signature. Furthermore, the second electronic device 100-R may determine that the signature is not verified if the signature generated by the second electronic device 100-R is different from the received signature. In step S1440, the second electronic device 100-R may decrypt the encrypted message with the session key, which may be the session key received from the first electronic device 100-T, and provide the decrypted message to the user.

[0024] 15 is a flowchart illustrating a process for a first electronic device to send a message to a second electronic device according to an embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be performed. Referring to FIG. 15, the process of the first electronic device 100-T sending a message to the second electronic device 100-R may include step S1510 in which the first electronic device 100-T obtains the second public key of the second electronic device 100-R, step S1520 in which the first electronic device 100-T generates a session key and encrypts the message with the session key, step S1530 in which the first electronic device 100-T encrypts the session key with the second public key of the second electronic device 100-R, and step S1540 in which the first electronic device 100-T sends the encrypted session key and the encrypted message to the second electronic device 100-R. In step S1510, the first electronic device 100-T may obtain the second public key of the second electronic device 100-R. The process according to an exemplary embodiment is as follows: The first electronic device 100-T may request the second public key of the second electronic device 100-R from the server 200 connected via a secure channel. The server 200 may generate the second public key of the second electronic device 100-R and transmit it to the first electronic device 100-T. In this case, the second public key of the second electronic device 100-R may correspond to the second private key of the second electronic device 100-R. The server 200 may authenticate the second electronic device 100-R based on the second random challenge signal. The server 200 may store a pre-stored second challenge-response pair database for the second electronic device 100-R to authenticate the second electronic device 100-R. The server 200 may obtain the second private key of the second electronic device 100-R during the authentication process. In this case, the acquired second private key may be a response private key generated in the second electronic device 100-R and transmitted to the server, or may be a response private key searched for by the server 200 in response to the second random challenge signal from a pre-stored second challenge / response pair database. The server 200 may generate a public key for the second electronic device 100-R by inputting the private key of the second electronic device 100-R into a pre-set public key generation function. A detailed description thereof is omitted as it is the same as that described above with reference to FIGS. 11 and 12. In step S1520, the first electronic device 100-T may generate a session key and encrypt a message with the session key. According to an exemplary embodiment, the first electronic device 100-T may include a random number generator 104. For example, the random number generator 104 may be a true random number generator (TRNG) 105. The first electronic device 100-T may generate the session key using the random number generator 104. The first electronic device 100-T may generate a message session key by inputting the generated session key into a random number function that converts the 640-bit session key into a 128-bit session key. Hereinafter, the session key used to encrypt a message may be referred to as the message session key. The session key may be a key temporarily generated by the first electronic device 100-T sending a message to encrypt the message. The session key may expire after a preset time has elapsed. Alternatively, the session key may be temporarily generated each time the first electronic device 100-T sends a message to the second electronic device 100-R and expire after the transmission of the message has elapsed. After the session key expires, the first electronic device 100-T may generate a new session key to re-encrypt the message. More details regarding the generation of the session key by the random number generator 104 will be described below together with the description of the configuration of the electronic device 100 in Figure 7. The first electronic device 100-T may encrypt a message using the session key. In step S1530, the first electronic device 100-T may encrypt the session key with the second public key of the second electronic device 100-R. According to an exemplary embodiment, the first electronic device 100-T may directly encrypt the session key with the second public key of the second electronic device 100-R. Alternatively, the first electronic device 100-T may generate a shared session key based on the second public key of the second electronic device 100-R and encrypt the session key with the generated shared session key. Specifically, the first electronic device 100-T may generate a shared session key based on the second public key and session key of the second electronic device 100-R. In this case, the session key (hereinafter referred to as a personal session key) used to generate the shared session key may be different from the message session key. The personal session key may be generated by inputting a session key generated by a random number generator to a random number function that converts the 640-bit session key to a 256-bit key, and then inputting the key to a range check function that checks whether the key is within the range of an elliptic curve encryption function. The first electronic device 100-T may encrypt the session key with a shared session key. For example, the first electronic device 100-T may share the session key with the second electronic device 100-R using the Elliptic Curve Diffie-Hellman key sharing (ECDH) method. In step S1540, the first electronic device 100-T may send the encrypted session key and the encrypted message to the second electronic device 100-R. In an exemplary embodiment, the encrypted session key may be the key generated in step S1530. The encrypted message may be the message encrypted in step S1520.

[0025] 16 is a flowchart illustrating a process in which a second electronic device receives a message from a first electronic device according to an embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be performed. Referring to FIG. 16, the process of the second electronic device 100-R receiving a message from the first electronic device 100-R may include step S1610 in which the first electronic device 100-R sends an encrypted session key and the encrypted message to the second electronic device 100-R, step S1620 in which the second electronic device 100-R generates a second private key, step S1630 in which the second electronic device 100-R decrypts the session key encrypted with the second private key, and step S1640 in which the second electronic device 100-R decrypts the message encrypted with the session key. In step S1610, the first electronic device 100-T may send the encrypted session key and the encrypted message to the second electronic device 100-R. According to an exemplary embodiment, the encrypted session key may be the key generated in step S1530 in the first electronic device 100-T. The encrypted message may be the message encrypted in step S1520 in the first electronic device 100-T. The session key may be a key used to encrypt and decrypt messages transmitted and received between the first electronic device 100-T and the second electronic device 100-R. The session key may be encrypted using a second public key of the second electronic device 100-R that receives the message, and the encrypted session key may be decrypted using a second private key of the second electronic device 100-R. In this case, the second public key that encrypts the session key and the second private key that decrypts the session key may correspond to each other. In addition, the second public key may be generated based on the second private key. A process of generating the second private key that decrypts the encrypted session key will be described below in step S1620. In step S1620, the second electronic device 100-R may generate a second private key. The process according to an exemplary embodiment is as follows: The second electronic device 100-R may request authentication from the server 200. The second electronic device 100-R may generate a second private key during the authentication process. The second electronic device 100-R, which wishes to receive a message, may receive an encrypted session key. The second electronic device 100-R may encrypt the encrypted message with a session key (e.g., a message session key). At this time, the session key may also be received from the first electronic device 100-T. At this time, the session key may also be received in an encrypted state. The encrypted session key may be encrypted using a second public key of the second electronic device 100-R. To decrypt the encrypted session key, the second electronic device 100-R may request a second private key corresponding to the second public key used to decrypt the session key. In step S1630, the second electronic device 100-R may decrypt the session key encrypted with the second private key. According to an exemplary embodiment, the second electronic device 100-R may directly decrypt the session key with the second private key. Alternatively, the second electronic device 100-R may generate a shared session key using the second private key and decrypt the session key using the generated shared session key. Specifically, the second electronic device 100-R may generate a shared session key based on the second private key and the received session key. In this case, the received session key may be an encrypted session key. Furthermore, the session key (hereinafter, personal session key) used to generate the shared session key may be different from the message session key. The personal session key may be generated by inputting a session key generated by a random number generator into a random number function that converts the 640-bit session key into a 256-bit session key, and then inputting the key into a range check function that checks whether the key is within the range of an elliptic curve encryption function. The second electronic device 100-R may decrypt the session key using the shared session key. In this case, the shared session key generated by the first electronic device 100-T and the shared session key generated by the second electronic device 100-R may be the same. For example, the second electronic device 100-R may share a session key with the first electronic device 100-T using the Elliptic Curve Diffie-Hellman key sharing (ECDH) method. In step S1640, the second electronic device 100-R may decrypt the encrypted message with the session key, which may be the session key decrypted in step S1630. The second electronic device 100-R may provide the decrypted message to the user.

[0026] 17 is a flowchart illustrating a process in which a first electronic device verifies a second certificate of a second electronic device and obtains a second public key of the second electronic device, according to one embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed in a different order, combined with other steps, omitted, divided into smaller steps, or one or more steps not shown may be added. Referring to FIG. 17, a method for sharing public keys among multiple electronic devices 100 may include step S1710 in which the first electronic device 100-T requests the second public key of the second electronic device 100-R from the server 200; step S1722 in which the server 200 authenticates the first electronic device 100-T based on the first random challenge signal; step S1724 in which the server 200 authenticates the second electronic device 100-R based on the second random challenge signal; step S1730 in which the server 200 generates a second certificate including the second public key of the second electronic device 100-R; step S1740 in which the server 200 transmits the second certificate of the second electronic device 100-R to the first electronic device 100-T; and step S1750 in which the first electronic device 100-T verifies the second certificate. In step S1710, the first electronic device 100-T may request the second public key of the second electronic device 100-R from the server 200. According to an exemplary embodiment, the first electronic device 100-T may be a device that intends to transmit data (e.g., a message) to the second electronic device 100-R. The first electronic device 100-T may request the second public key of the second electronic device 100-R to encrypt the data to be transmitted to the second electronic device 100-R. The first electronic device 100-T may request the server 200 to obtain the second public key of the second electronic device 100-R. In step S1722, the first electronic device 100-T may be authenticated based on the first random challenge signal. The process according to an exemplary embodiment is as follows: The server 200 may randomly generate a signal (hereinafter, referred to as the first random challenge signal) in response to a request for the second public key of the second electronic device 100-R from the first electronic device 100-T. The server 200 may transmit the first challenge signal to the first electronic device 100-T. The server 200 may receive a first private key corresponding to the first random challenge signal from the first electronic device 100-T. The server 200 may authenticate the first electronic device 100-T based on the first random challenge signal and the first private key. Specific details regarding the server 200 authenticating the first electronic device 100-T are omitted because they are the same as those for authenticating the electronic device 100 in FIG. 8. In step S1724, the server 200 may authenticate the second electronic device 100-R based on the second random challenge signal. The process according to an exemplary embodiment is as follows: The server 200 may randomly generate a signal (hereinafter, referred to as the second random challenge signal) in response to a request for the second public key of the second electronic device 100-R from the first electronic device 100-T. The server 200 may transmit the second random challenge signal to the second electronic device 100-R. The server 200 may receive a second private key corresponding to the second random challenge signal from the second electronic device 100-R. The server 200 may authenticate the second electronic device 100-R based on the second random challenge signal and the second private key. Details regarding the server 200 authenticating the second electronic device 100-R are omitted because they are the same as those for authenticating the electronic device 100 in FIG. 8. In step S1730, the server 200 may generate a second certificate including the second public key of the second electronic device 100-R. The process according to an exemplary embodiment is as follows: The server 200 may acquire a first private key of the first electronic device 100-R in the process of authenticating the first electronic device 100-T, and may acquire a second private key of the second electronic device 100-R in the process of authenticating the second electronic device 100-R. In this case, the first private key and the second private key acquired by the server 200 may be private keys (reference private keys) received from the first electronic device 100-T and the second electronic device 100-R. Alternatively, the private key acquired by the server 200 may be a private key (reference private key) searched for from a challenge-response pair database stored by the server 200. The server 200 may generate a second public key for the second electronic device 100-R based on the second private key of the second electronic device 100-R. The server 200 may generate a second certificate for the second electronic device 100-R including the second public key based on the second private key and the second public key of the second electronic device 100-R. This will be described in more detail below with reference to FIG. 18. In step S1740, the server 200 may send the second certificate of the second electronic device 100-R to the first electronic device 100-T. According to an exemplary embodiment, the content is as follows: The server 200 may transmit the second certificate generated in step S1730 to the first electronic device 100-T that requested the second public key of the second electronic device 100-R. In step S1750, the first electronic device 100-T may verify the second certificate. The process according to an exemplary embodiment is as follows: The first electronic device 100-T may receive the second certificate from the server 200, which includes the second public key of the second electronic device 100-R. The first electronic device 100-T may verify the second certificate based on its own first private key (first reference private key) and the second public key of the second electronic device 100-R included in the second certificate. If the verification of the second certificate is successful, the first electronic device 100-T may determine that the second public key included in the second certificate is not forged or altered, and may acquire the second public key and use it in a cryptographic protocol later. This will be described in more detail below with reference to FIG. 19.

[0027] 18 is a flowchart illustrating a process in which a server shares a second certificate including a second public key of a second electronic device with a first electronic device according to an embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed in a different order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be added. Referring to FIG. 18, a method in which the server 200 shares the second public key of the second electronic device 100-R with the first electronic device 100-T may include step S1810 in which the server 200 authenticates the first electronic device 100-T based on the first random challenge signal and authenticates the second electronic device 100-R based on the second random challenge signal; step S1820 in which the server 200 obtains a first private key for the first electronic device 100-T; step S1830 in which the server 200 obtains a second public key for the second electronic device 100-R; step S1840 in which the server 200 generates a first authentication code based on the first private key of the first electronic device 100-T and the second public key of the second electronic device 100-R; and step S1850 in which the server 200 sends a second certificate including the first authentication code to the first electronic device 100-T. In step S1810, the server 200 may authenticate the first electronic device 100-T based on the first random challenge signal and may authenticate the second electronic device 100-R based on the second random challenge signal. The process by which the server 200 authenticates each electronic device 100 is the same as that described above in FIG. 8, and therefore will not be repeated. In step S1820, the server 200 may acquire a first personal key for the first electronic device 100-T. The content according to an exemplary embodiment is as follows: The server 200 may acquire a first personal key for the first electronic device 100-T in the process of authenticating the first electronic device 100-T. In this case, the first personal key acquired by the server 200 may be a personal key (first reference personal key) received from the first electronic device 100-T. Alternatively, the personal key acquired by the server 200 may be a personal key (first reference personal key) searched from a first challenge-response pair database stored by the server 200 for the first electronic device 100-T. In step S1830, the server 200 may acquire a second public key for the second electronic device 100-R. The process according to an exemplary embodiment is as follows: The server 200 may acquire a second private key for the second electronic device 100-R in the process of authenticating the second electronic device 100-R. In this case, the second private key acquired by the server 200 may be a private key (second reference private key) received from the second electronic device 100-R. Alternatively, the second private key acquired by the server 200 may be a private key (second reference private key) searched from a second challenge-response pair database stored by the server 200 for the second electronic device 100-R. A more detailed description thereof is the same as that of FIG. 2. The server 200 may generate a second public key for the second electronic device 100-R based on the second private key. According to an exemplary embodiment, the server 200 may generate the second public key by inputting the second private key into a preset public key generation function. In this case, the second public key of the second electronic device 100-R may be a unique key corresponding to the second private key of the second electronic device 100-R. The second public key of the second electronic device 100-R may be accessible not only to the first electronic device 100-T but also to all other users' electronic devices 100. The predetermined public key generation function may be a function that makes it impossible to predict an input signal corresponding to an output signal from an output signal. In an exemplary embodiment, the public key generation function may be an elliptic curve cryptography (ECC) function. The elliptic curve cryptography function may be a function including a quadratic equation on an elliptic curve. In step S1840, the server 200 may generate a first authentication code based on the first private key of the first electronic device 100-T and the second public key of the second electronic device 100-R. According to an exemplary embodiment, the server 200 may acquire and store a plurality of pieces of device information for each of the plurality of electronic devices 100-T and 100-R. The one or more pieces of information included in the plurality of pieces of device information may be one or more of values, data, and information generated based on the PUF circuits included in each of the plurality of electronic devices 100-T and 100-R. For example, the plurality of pieces of device information may include the public keys of the corresponding electronic devices 100-T and 100-R. The server 200 may input the first private key and the second public key into a preset authentication code generation function to output a first authentication code. The preset authentication code generation function may be a function that makes it impossible to predict an input signal corresponding to an output signal from an output signal. In an exemplary embodiment, the authentication code generation function may be a hash-based message authentication code (HMAC) function. The hash-based message authentication code function may be a function that applies a hash function multiple times. In this case, the hash function may be a function that calculates output data of a fixed length regardless of the length of input data. In step S1850, the server 200 may send a second certificate including the first authentication code to the first electronic device 100-T. According to an exemplary embodiment, the content is as follows: The server 200 may generate a second certificate including a second public key and the first authentication code for the second electronic device 100-R. The server 200 may send the generated second certificate to the first electronic device 100-T that requested the second public key of the second electronic device 100-R.

[0028] 19 is a flowchart illustrating a process in which a first electronic device verifies a second certificate of a second electronic device received from a server and obtains a second public key of the second electronic device, according to an embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed in a different order, combined with other steps, omitted, divided into smaller steps, or one or more steps not shown may be added. Referring to FIG. 19, a method for verifying the second certificate of the second electronic device 100-R received by the first electronic device 100-T from the server 200 may include step S1910 in which the first electronic device 100-T generates a private key (first reference private key) based on a first random challenge signal, step S1920 in which the first electronic device 100-T acquires a second public key of the second electronic device 100-R, step S1930 in which the first electronic device 100-T generates a second authentication code based on the first private key (first reference private key) of the first electronic device 100-T and the second public key of the second electronic device 100-R, and step S1940 in which the first electronic device 100-T compares the received first authentication code with the generated second authentication code to verify the certificate. In step S1910, the first electronic device 100-T may generate a private key (first reference private key) based on the first random challenge signal. According to an exemplary embodiment, the first electronic device 100-T may request the second public key of the second electronic device 100-R from the server 200. By requesting the second public key, the first electronic device 100-T may be authenticated by the first random challenge signal from the server. During the authentication process, the first electronic device 100-T may input the first random challenge signal received from the server into the PUF circuit 103 to obtain the first private key (first reference private key). In step S1920, the first electronic device 100-T may obtain the second public key of the second electronic device 100-R. According to an exemplary embodiment, the process is as follows: The first electronic device 100-T may receive a second certificate of the second electronic device 100-R from the server 200. The second certificate may include the second public key and the first authentication code of the second electronic device 100-R. By obtaining the second certificate, the first electronic device 100-T may obtain the public key included in the second certificate. In step S1930, the first electronic device 100-T may generate a second authentication code based on the first private key (first reference private key) of the first electronic device 100-T and the second public key of the second electronic device 100-R. According to an exemplary embodiment, the first private key (first reference private key) may be the key generated in step S1910, and the second public key may be the key obtained in step S1920. The first electronic device 100-T may input the first private key and the second public key into a preset authentication code generation function to output a second authentication code. A detailed description of the authentication code generation function is omitted here because it is the same as the description of step S1840 of FIG. 18 above. In step S1940, the first electronic device 100-T may verify the certificate by comparing the received first authentication code with the generated second authentication code. The process according to an exemplary embodiment is as follows: As described above in the description of step S1920 of FIG. 19 , the second certificate received by the first electronic device 100-T from the server 200 may include the first authentication code. Also, as described above in the description of step S1930 of FIG. 19 , the first electronic device 100-T may generate the second authentication code. The first electronic device 100-T may verify the certificate based on the first authentication code included in the second certificate received from the server 200 and the second authentication code generated by the first electronic device 100-T. Specifically, the first electronic device 100-T may compare the received first authentication code with the generated second authentication code. If the received first authentication code and the generated second authentication code are the same, the first electronic device 100-T may determine that the second authentication certificate is verified. If the received first authentication code and the generated second authentication code are different, the first electronic device 100-T may determine that the second authentication certificate is not verified. If the second authentication certificate is determined to be verified, the first electronic device 100-T may consider the second public key of the second electronic device 100-R included in the second authentication certificate to be unforged and may subsequently use it in a cryptographic protocol.

[0029] 20 is a flowchart illustrating a process for a first electronic device to send a message to a second electronic device according to one embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be performed. Referring to FIG. 20, the process of the first electronic device 100-T sending a message to the second electronic device 100-R may include step S2010 in which the first electronic device 100-T obtains the second public key of the second electronic device 100-R, step S2020 in which the first electronic device 100-T generates a session key and encrypts the message with the session key, step S2030 in which the first electronic device 100-T encrypts the session key with the second public key of the second electronic device 100-R, and step S2040 in which the first electronic device 100-T sends the encrypted session key and the encrypted message to the second electronic device 100-R. In step S2010, the first electronic device 100-T may obtain the second public key of the second electronic device 100-R. According to an exemplary embodiment, the process is as follows: The first electronic device 100-T may request the second public key of the second electronic device 100-R from the server 200 connected via a secure channel. The server 200 may generate a certificate including the second public key of the second electronic device 100-R and transmit it to the first electronic device 100-T. The first electronic device 100-T may verify the second certificate and confirm the integrity of the second public key included in the second certificate. In step S2020, the first electronic device 100-T may generate a session key and encrypt a message using the session key. An exemplary embodiment of the present invention is as follows: The first electronic device 100-T may include a random number generator 104. The first electronic device 100-T may generate a session key using the random number generator 104. A detailed description of generating a session key using the random number generator 104 is omitted here, as it is the same as the configuration of the electronic device 100 described in FIG. 2 . The first electronic device 100-T may generate a message session key by inputting the generated session key into a random number function that converts a 640-bit session key into a 128-bit session key. Hereinafter, the session key used to encrypt a message may be the message session key. The first electronic device 100-T may decrypt the message using the session key. In step S2030, the first electronic device 100-T may encrypt the session key with the second public key of the second electronic device 100-R. According to an exemplary embodiment, the first electronic device 100-T may directly encrypt the session key with the second public key of the second electronic device 100-R. Alternatively, the first electronic device 100-T may generate a shared session key based on the second public key of the second electronic device 100-R and encrypt the session key with the generated shared session key. Specifically, the first electronic device 100-T may generate a shared session key based on the second public key and session key of the second electronic device 100-R. In this case, the session key (hereinafter referred to as a personal session key) used to generate the shared session key may be different from the message session key. The personal session key may be generated by inputting a session key generated by a random number generator to a random number function that converts the 640-bit session key to a 256-bit key, and then inputting the key to a range check function that checks whether the key is within the range of an elliptic curve encryption function. The first electronic device 100-T may encrypt the session key with a shared session key. For example, the first electronic device 100-T may share the session key with the second electronic device 100-R using the Elliptic Curve Diffie-Hellman key sharing (ECDH) method. In step S2040, the first electronic device 100-T may send the encrypted session key and the encrypted message to the second electronic device 100-R. In an exemplary embodiment, the encrypted session key may be the key generated in step S2030. The encrypted message may be the message encrypted in step S2020.

[0030] 21 is a flowchart illustrating a process in which a second electronic device receives a message from a first electronic device according to one embodiment of the present invention. Although the illustrated flowchart describes the method as being divided into multiple steps, at least some of the steps may be performed out of order, combined with other steps, omitted, divided into smaller steps, or one or more additional steps not shown may be performed. Referring to FIG. 21, the process of the second electronic device 100-R receiving a message from the first electronic device 100-R may include step S2110 in which the first electronic device 100-R sends an encrypted session key and the encrypted message to the second electronic device 100-R, step S2120 in which the second electronic device 100-R generates a second private key, step S2130 in which the second electronic device 100-R decrypts the session key encrypted with the second private key, and step S2140 in which the second electronic device 100-R decrypts the message encrypted with the session key. In step S2110, the first electronic device 100-T may send the encrypted session key and the encrypted message to the second electronic device 100-R. In an exemplary embodiment, the encrypted session key may be the key encrypted in step S2030 in the first electronic device 100-T. The encrypted message may be the message encrypted in step S2020 in the first electronic device 100-T. In step S2120, the second electronic device 100-R may generate a second private key. According to an exemplary embodiment, the second electronic device 100-R may request authentication from the server 200. The second electronic device 100-R may generate a second private key during the authentication process. In step S2130, the second electronic device 100-R may decrypt the session key encrypted with the second private key. According to an exemplary embodiment, the second electronic device 100-R may directly decrypt the session key with the second private key. Alternatively, the second electronic device 100-R may generate a shared session key using the second private key and decrypt the session key using the generated shared session key. Specifically, the second electronic device 100-R may generate a shared session key based on the second private key and the received session key. In this case, the received session key may be an encrypted session key. Furthermore, the session key (hereinafter, personal session key) used to generate the shared session key may be different from the message session key. The personal session key may be generated by inputting a session key generated by a random number generator into a random number function that converts the 640-bit session key into a 256-bit session key, and then inputting the key into a range check function that checks whether the key is within the range of an elliptic curve encryption function. The second electronic device 100-R may decrypt the session key using the shared session key. In this case, the shared session key generated by the first electronic device 100-T and the shared session key generated by the second electronic device 100-R may be the same. For example, the second electronic device 100-R may share a session key with the first electronic device 100-T using the Elliptic Curve Diffie-Hellman key sharing (ECDH) method. In step S2140, the second electronic device 100-R may decrypt the encrypted message with the session key, which may be the session key decrypted in step S2130. The second electronic device 100-R may provide the decrypted message to the user.

[0031] 22 is a block diagram illustrating the configuration of a computing device according to one embodiment. In the illustrated embodiment, each component may have different functions and capabilities than those described below, and may include additional components beyond those described below. The illustrated computing environment 10 includes a computing device 12. In one embodiment, the computing device 12 may be one of the electronic devices 100 and servers 200 described above and may perform the operations of the electronic device 100 and server 200 described in Figures 1a through 21. Computing device 12 includes at least one controller 14, a computer-readable storage medium 16, and a communication bus 18. Controller 14 may cause computing device 12 to operate according to the exemplary embodiments described above. For example, controller 14 may execute one or more programs stored on computer-readable storage medium 16. The one or more programs may include one or more computer-executable instructions that, when executed by controller 14, may configure computing device 12 to perform operations according to the exemplary embodiments. The computer-readable storage medium 16 is configured to store computer-executable instructions or program code, program data, and / or other suitable forms of information. The program 20 stored on the computer-readable storage medium 16 includes a set of instructions executable by the controller 14. In one embodiment, the computer-readable storage medium 16 may be memory (volatile memory, such as random access memory, non-volatile memory, or a suitable combination thereof), one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, other forms of storage media that can be accessed by the computing device 12 to store desired information, or a suitable combination thereof. A communications bus 18 couples together the controller 14, the computer-readable storage medium 16, and various other components of the computing device 12. Computing device 12 may also include one or more input / output interfaces 22 and one or more network communication interfaces 26 that provide interfaces for one or more input / output devices 24. I / O interface 22 and network communication interface 26 are coupled to communication bus 18. I / O device 24 may be coupled to other components of computing device 12 via I / O interface 22. Exemplary I / O devices 24 may include input devices such as a pointing device (e.g., a mouse or trackpad), a keyboard, a touch input device (e.g., a touchpad or touchscreen), a voice or sound input device, various types of sensor devices and / or photographic devices, and / or output devices such as a display device, a printer, speakers, and / or a network card. Exemplary I / O device 24 may be included within computing device 12 as a component constituting computing device 12, or may be coupled to computing device 12 as a separate device distinct from computing device 12. According to one disclosed embodiment, cryptographic communication can be performed with reduced hardware, less computational complexity, and less resource consumption. According to another disclosed embodiment, cryptographic communication can be performed by temporarily generating information required for cryptographic communication when necessary. According to another disclosed embodiment, keys used in cryptographic protocols can be shared with reduced hardware, less computational complexity, and less resource consumption. According to another disclosed embodiment, digital signature generation and verification of signatures can be performed with reduced hardware, less computational complexity, and less resource consumption. According to another disclosed embodiment, digital signature generation and verification of signatures can be performed by temporarily generating information required for cryptographic communication when necessary. While the representative embodiments of the present invention have been described in detail above, those skilled in the art will understand that various modifications can be made to the above-described embodiments without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined by the following claims and their equivalents. [Explanation of symbols]

[0032] 10: Cryptographic Communication System 100:Electronic equipment 100-T: 1st electronic device 100-R:Second electronic device 200:Server

Claims

1. a PUF circuit that generates a private key by inputting a random challenge signal into a function that cannot be physically copied; a communication device receiving from a counterpart electronic device a message encrypted with a temporarily generated message session key and an encrypted message session key generated by encrypting the message session key with a public key corresponding to the private key; a controller that decrypts the encrypted message session key with the private key to obtain the message session key, and decrypts the encrypted message with the message session key.

2. The communication device receiving the random challenge signal from a server connected to each of the electronic device and the other electronic device via a channel independent of the outside world; The public key is 2. The electronic device of claim 1, wherein the random challenge signal is generated based on a private key retrieved in the server from a challenge-response pair database pre-stored for the electronic device in response to the random challenge signal.

3. The electronic device according to claim 2 , wherein the private key generated by the PUF circuit and the retrieved private key are the same.

4. The controller 2. The electronic device of claim 1, further comprising: a second shared session key generated based on the private key and the encrypted session key; and a second shared session key used to decrypt the encrypted session key.

5. The message session key is 6. The electronic device of claim 5, wherein the message is encrypted at the other electronic device with a first shared session key generated based on a public key corresponding to the private key and the message session key.

6. The electronic device is The electronic device of claim 1 , further comprising a random number generator that generates a new random number that is unique depending on environmental conditions when a new message is generated, and generates a new message session key based on the new random number.

7. The controller generating a signature based on the private key to ensure the integrity of the transmitted data; The communication device The electronic device according to claim 1 , wherein the transmission data and the signature are transmitted to the other electronic device.

8. The electronic device is a random number generator that generates unique random numbers depending on environmental conditions and generates a signature session key based on the random numbers; The controller 8. The electronic device of claim 7, wherein the signature is generated by inputting the private key and the signature session key into a signature generation function that cannot predict an input signal corresponding to the output signal from an output signal.

9. The communication device communicating with a server connected to each of the electronic device and the other electronic device via a channel independent of the outside world; The public key is A random challenge signal is generated by the server in response to the random challenge signal and transmitted to the other electronic device; The signature is:

8. The electronic device of claim 7, wherein the electronic device is verified in the other electronic device based on the personal key.

10. The communication device receiving a certificate of the other electronic device from a server connected to each of the electronic device and the other electronic device via a channel independent of the outside world; The controller The electronic device according to claim 1 , wherein the certificate is verified based on the private key generated via the PUF circuit to obtain the public key of the other electronic device.

11. The electronic device is The method further includes a random number generator that generates a unique random number according to an environmental condition and generates a message session key based on the random number; The controller 11. The electronic device of claim 10, wherein data to be sent to the other electronic device is encrypted with the message session key, and the message session key is encrypted with the public key of the other electronic device.

12. The certificate is The server includes a private key searched in response to the random challenge signal from a challenge response pair database pre-stored for the electronic device, and a first authentication code generated based on at least one of a plurality of device information items related to the other electronic device, The controller The electronic device of claim 10, further comprising: a second authentication code generated based on the private key generated by the PUF circuit and one or more of the plurality of device information; and an authentication certificate authenticated based on the first authentication code and the second authentication code.

13. The electronic device is The method further includes a challenge signal generating device that receives an initial signal from the server connected to a channel unrelated to the outside via the communication device and generates a plurality of challenge signals; The PUF circuit comprises: generating a plurality of pieces of response information corresponding to each of the plurality of challenge signals; The controller generating a plurality of challenge-response pairs by pairing a plurality of challenge signals with a plurality of corresponding response information; The communication device The electronic device of claim 1 , further comprising: a processor configured to transmit the plurality of challenge-response pairs to the server.

14. generating a private key by inputting the random challenge signal to a physically unclonable function using a PUF circuit; receiving from the other electronic device a message encrypted with the temporarily generated message session key and an encrypted message session key generated by encrypting the message session key with a public key corresponding to the private key; decrypting the encrypted message session key with the private key to obtain the message session key; decrypting the encrypted message with the message session key.

15. The method comprises: generating a signature based on the private key to ensure the integrity of the transmitted data; The method of claim 14 , further comprising the step of: transmitting the transmission data and the signature to the other electronic device.