METHOD FOR MUTUALLY ATTESTING SECURITY LEVELS OF ELECTRONIC DEVICES IN MULTI DEVICE ENVIRONMENT

An electronic device is provided. The electronic device includes a communication module for supporting near-field wireless communication, memory, and at least one processor operatively connected to the communication module and the memory. The memory stores one or more programs including instructions that, when executed by the at least one processor, may cause the electronic device to establish near-field wireless communication connection with an external device through the communication module, generate a first private key by using a determined random function, generate a first public key based on the first private key, generate a first certificate including a security level of the electronic device with respect to the first public key, and transmit the generated first certificate to the external device through the communication module.

TECHNICAL FIELD

The disclosure relates to an electronic device. More particularly, the disclosure relates to a method for mutually attesting security levels of respective electronic devices in a multi-device environment including multiple electronic devices.

BACKGROUND ART

Device attestation is a method for attesting that hardware and/or software of a specific electronic device (or a terminal) is not changed. For example, in case that an electronic device disguises itself as another electronic device by transferring an identifier (ID) different from a hardware ID initially configured or hardware and/or software is changed after the electronic device is manufactured, the disguising or change is identified through the device attestation. Various services may require the device attestation. For example, when using a service providing one item for a specific electronic device, an electronic device not eligible for the service may duplicate and use identification information (e.g., international mobile equipment identity (IMEI)) of another electronic device, and this unauthorized duplication may be identified through the device attestation. For another example, in the case of an electronic device having authority to process confidential data, a high level of security is required and identification of hardware and software changes may be required prior to accessing data in this case.

For the device attestation in various environments, server-based device attestation is utilized in a communication environment between an electronic device and a server. For example, a key for device attestation is injected to the electronic device, an attestation certificate is issued, and then the server may perform device attestation of the electronic device based on a response of the electronic device with respect to a challenge transmitted by the server.

DISCLOSURE OF INVENTION

As various services are provided, a multi-device environment in which an electronic device is connected to another electronic device without interference of a server may be required. In this multi-device environment, it is not enough for one electronic device to verify another electronic device, both electronic devices need to be able to verify the other electronic device, and an exchange of keys to be used for communication between both electronic devices may be necessary after verification. In addition, depending on a service to be provided, a device attestation method for an electronic device to identify and verify information such as a security level of another electronic device may be required.

Aspects of the disclosure are to address at least the above-mentioned problems and/or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the disclosure is to provide an electronic device and a method for mutually attesting security levels of respective electronic devices in a multi-device environment including multiple electronic devices.

In accordance with an aspect of the disclosure, an electronic device is provided. The electronic device may include a communication module for supporting near-field wireless communication, memory, and at least one processor operatively connected to the communication module and the memory. According to various embodiments, the memory stores one or more programs including instructions that, when executed by the at least one processor, cause the electronic device to establish near-field wireless communication connection with an external device through the communication module, generate a first private key by using a determined random function, generate a first public key based on the first private key, generate a first certificate including a security level of the electronic device with respect to the first public key, and transmit the generated first certificate to the external device through the communication module.

In accordance with another aspect of the disclosure, a method, performed by an electronic device, to mutually attest a security level of an external device is provided. The method may include an operation of establishing near-field wireless communication connection with the external device, an operation of generating a first private key by using a determined random function, an operation of generating a first public key based on the first private key, an operation of generating a first certificate including a security level of the electronic device with respect to the first public key, and an operation of transmitting the generated first certificate to the external device.

In accordance with yet another aspect of the disclosure, one or more non-transitory computer-readable storage media is provided. The one or more non-transitory computer-readable storage media store one or more programs including instructions that, when executed by at least one processor of an electronic device, may cause the electronic device to perform operations. The operations may include establishing near-field wireless communication connection with an external device, generating a first private key by using a determined random function, generating a first public key based on the first private key, generating a first certificate including a security level of the electronic device with respect to the first public key, and transmitting the generated first certificate to the external device.

Various embodiments of the disclosure may provide a method for electronic devices to mutually attest security levels in a multi-device environment, which may perform verification, including the integrity of hardware and/or software of the other device, and identify and verify device information such as a security level between both electronic devices through mutual attestation in a multi-device environment.

MODE FOR THE INVENTION

FIG.1is a block diagram illustrating an electronic device101in a network environment100according to an embodiment of the disclosure.

FIG.2is a diagram illustrating a method for mutual attestation between electronic devices in a multi-device environment according to an embodiment of the disclosure.

A first electronic device210and a second electronic device220inFIG.2may include at least a portion of the structure and/or function of the electronic device101inFIG.1and the electronic device300inFIG.3, respectively.

According to an embodiment, the first electronic device210and the second electronic device220may store an attestation key, and the attestation key may include a key (e.g., a Samsung attestation key (SAK)) injected by a manufacturer of the first electronic device210and the second electronic device220. For example, the attestation key may be stored in a non-volatile area of a memory in a manufacturing process of the first electronic device210and the second electronic device220. According to an embodiment, the attestation key may include a private key used in a public key cryptosystem such as an elliptic curve digital signature algorithm (ECDSA), an Edwards curve digital signature algorithm (EdDDSA), and an RSA or a post-quantum cryptography (PQC) cryptosystem and a certificate for the private key.

According to an embodiment, the first electronic device210and the second electronic device220may perform mutual attestation of the other device based on the stored attestation key. For example, the first electronic device210and the second electronic device220may identify, through the mutual attestation, whether the other electronic device is manufactured by the same manufacturer and hardware and/or software is modified.

According to an embodiment, the first electronic device210and the second electronic device220may discover the other device through near-field wireless communication (e.g., Wi-Fi or Bluetooth) and establish connection. In case that a device attestation operation for the other device is triggered in the first electronic device210or the second electronic device220, data may be transmitted and received through established near-field wireless communication.

According to an embodiment, the first electronic device210may generate a first random number and transmit the first random number to the second electronic device220. According to an embodiment, the first electronic device210may generate the first random number by using a predetermined random function and combine the generated first random number and an elliptic curve point to generate a first public element required to generate a session key (or symmetric key), and transmit the session key to the second electronic device220.

According to an embodiment, the second electronic device220may generate a second random number, an electronic signature, and a certificate. According to an embodiment, the second electronic device220may generate the second random number by using a predetermined secure random function and combine the generated second random number and an elliptic curve point to generate a first public element required to generate a session key (or symmetric key). In addition, the second electronic device220may electronically sign the second public element by using the private key, generate a second electronic signature, and generate a second certificate with respect to the public key. The second electronic device220may transmit the generated second random number, the electronic signature, and the certificate to the first electronic device210.

According to an embodiment, the first electronic device210may generate an electronic signature and a certificate. According to an embodiment, the first electronic device210may electronically sign the first public element by using the private key, generate a first electronic signature, and generate a first certificate with respect to the public key. The first electronic device210may transmit the generated electronic signature, and the certificate to the second electronic device220.

According to an embodiment, based on the second random number, the electronic signature, and the certificate received from the second electronic device220, the first electronic device210may attest the second electronic device220.

According to an embodiment, the first electronic device210may identify an attestation result of the second electronic device220, a security level (e.g., L1, L2, or L3) of the second electronic device220, a child node list, whether hardware has been modified, whether software has been modified, and/or firmware information.

According to an embodiment, based on the first random number, the electronic signature, and the certificate received from the first electronic device210, the second electronic device220may attest the first electronic device210.

According to an embodiment, the second electronic device220may identify an attestation result of the first electronic device210, a security level (e.g., L1, L2, or L3) of the first electronic device210, a child node list, whether hardware has been modified, whether software has been modified, and/or firmware information.

FIG.2illustrates a mutual attestation procedure in the case that after the first electronic device210and the second electronic device220establish wireless connection, the first electronic device210transmits the first random number to the second electronic device220first, but the order is not limited thereto. According to an embodiment, after wireless connection establishment, the second electronic device220may transmit the second random number to the first electronic device210first. In this case, the first electronic device210may transmit the first random number, the digital signature, and the certificate to the second electronic device220in response to the reception of the second random number, and the second electronic device220may transmit the digital signature and the certificate to the first electronic device210. In this embodiment, the method of the first electronic device210and the second electronic device220to attest the other device may be identical to the method described with reference to the above embodiment.

FIG.3is a block diagram illustrating an electronic device according to an embodiment of the disclosure.

Referring toFIG.3, the electronic device300according to various embodiments may include a communication module350, a processor360, and memory370, and even if some of the components are omitted or substituted with others, various embodiments of the disclosure may be implemented. The electronic device may further include at least a portion of the structure and/or function of the electronic device101inFIG.1and the first electronic device210or the second electronic device220inFIG.2.

According to an embodiment, the communication module350may support near-field wireless communication. The communication module350may support establishment of a wireless communication channel with an external device (e.g., the second electronic device220inFIG.2) and transmission/reception of data through the established communication channel. There is no fixed type of near-field wireless communication supported by the communication module350, but for example, at least one of Wi-Fi, Bluetooth, and Bluetooth low energy (BLE) may be supported. The communication module350may further include at least a portion of the structure or function of the communication module190inFIG.1.

According to an embodiment, the memory370may include one or more computer-readable storage media. The computer-readable storage media are, for example, tangible and non-transitory. The memory370includes a well-known volatile memory and non-volatile memory. The memory370may store various instructions (e.g., for performing aspects of operations described herein) executable by the processor360. The instructions may include control commands, such as arithmetic and logic operations, data movement, and input/output, which may be recognized by the processor360. The memory360may be distributed among different types of memory, with any given type being a singular or plural memory. Different memory may be used by, or associated with, a different at least one of one or more processors. The memory370may include at least a portion of the structure and/or function of the memory130inFIG.1and may store at least a portion of the program140inFIG.1.

According to an embodiment, the processor360corresponds to a component capable of performing calculation or data processing for control and/or communication of each component of the electronic device300and may include at least a portion of components of the processor120inFIG.1. The processor360may be operatively, electrically, and/or functionally connected to internal components of the electronic device300, such as the communication module350or the memory370. According to an embodiment, the processor360serves to execute various instructions of one or more programs that may be loaded into memory to perform various operations of the electronic device300and to process data. The processor360may be a set of one or more processors or may be a multi-processor core, depending on the particular implementation. Here the set of one or more processors may include one or more of an application processor (e.g. a central processing unit (CPU)), a communication processor (e.g., a modem), a graphical processing unit (GPU), a neural processing unit (NPU) (e.g., an artificial intelligence (AI) chip), a Wi-Fi chip, a Bluetooth chip, a global positioning system (GPS) chip, a near field communication (NFC) chip, connectivity chips, a sensor controller, a touch controller, a finger-print sensor controller, a display drive integrated circuit (IC), an audio CODEC chip, a universal serial bus (USB) controller, a camera controller, an image processing IC, or the like. The electronic device300may perform operations based collectively on different processors of the one or more processors executing different instructions of the one or more programs. Further, the processor360may be implemented using one or more heterogeneous processor systems in which a main processor is present with secondary processors on a single chip. As another illustrative example, the processor360may be a symmetric multi-processor system containing multiple processors of the same type.

There are no limitations to a calculation and data processing function that the processor360may implement within the electronic device300, and in the disclosure, a description will be given of various embodiments for performing certification, including integrity of hardware and/or software through mutual attestation in a multi-device environment and identifying and verifying device information, such as a security level of an external device.

According to an embodiment, at least a portion of operations of the processor360described below may include an operation of an application processor, a secure processor, or a secure element. The secure processor may be implemented in a secure area independent from a normal area of the application processor. For example, the secure processor may be packaged inside the processor360and may correspond to a secure chip implemented in an area physically separated from a normal area. The secure processor may include a separate central processing unit (CPU) and random-access memory (RAM) and may provide a security level in hardware level therethrough. The secure element may correspond to a secure chip mounted outside the application processor. The secure element may include an internal processor (or CPU), a volatile memory (e.g., a RAM), and a non-volatile memory, which operate independently from the application processor.

According to an embodiment, the processor360(or secure processor, or secure element) may execute a trusted application. The trusted application (TA) may include an application executed in a secure environment. For example, the trusted application may have an access authority to security data and may need to be executed in a secure area (secure world) distinguished from the normal area (normal world).

According to an embodiment, the security level of the electronic device300may be determined based on a hardware configuration (e.g., the processor360, the secure processor, or the secure element) in which the trusted application is executed, or an attestation key generated in the electronic device300and a storage location of a certificate for the attestation key. For example, in case that the trusted application is executed on security-specific hardware (e.g., the secure processor) configured inside the processor360or on security-specific hardware (e.g., the secure element) configured outside the processor360, the security level of the electronic device300may be determined as a first level (or L1). In addition, in case that the trusted application is executed in a partial area (e.g., a trustzone) of the processor360, the security level of the electronic device300may be determined as a second level (or L2).

The secure area may be realized in various forms in the electronic device300and an example of the secure area realized in the electronic device300and the security level thereof will be described in detail with reference toFIGS.4A to4D.

According to an embodiment, in an environment including multiple devices, the electronic device300(e.g., the first electronic device210inFIG.2) and the external device (e.g., the second electronic device220inFIG.2) may identify the security level of the other through mutual attestation and provide a service appropriate for the security level. Here, the security level may be determined based on a level of security provided by an execution environment that provides a critical service and a key protection environment on each device. In addition, the security level may be determined based on a hardware specification and software loading level at the time of manufacturing of the electronic device300. The security level information may be loaded inside a certificate and/or inside security environment software when the certificate is injected in the manufacturing process of the electronic device300.

The security level for a security environment of each device may be defined as shown in Table 1 below.

According to Table 1 above, it may be defined as the highest security level in the order of L1-L2-L3. In case that the electronic device300has a security-specific chip mounted therein, the security level of L1 may be assigned. In this case, an attestation key (e.g., a Samsung attestation key (SAK)) used for attestation of the electronic device300may be protected by the corresponding security-specific chip. In addition, an operation for a mutual attestation protocol to be described with reference toFIGS.5and6may be implemented in association with the security function of the inside of the security-specific chip or the processor360.

According to an embodiment, in case that the electronic device300has a security function inside the processor360, such as an advanced RISC machine (ARM) trustzone, a security level of L2 may be assigned. In case of a device of L2 level, an intermediate level of security (or capacity) for protecting software based on hardware may be provided. The attestation key and security function of the electronic device300of L2 level may be implemented by a security function inside the processor360.

According to an embodiment, in case that the electronic device300does not provide a hardware security function, a security level of L3 may be assigned. In case of the electronic device300of L3 level, because of restrictions on key protection, only a relatively low level of authority may be provided.

Hereinafter, a protocol operation of the electronic device300(e.g., the first electronic device210inFIG.2) and the external device (e.g., the second electronic device220inFIG.2) for mutual attestation will be described.

According to an embodiment, the processor360may generate a first private key by using a determined random function. For example, the processor360may generate the first private key by using a cryptographically secure random function.

According to an embodiment, the processor360may generate a first public key based on the first private key. According to an embodiment, the processor360may generate the first public key in an elliptic curve cryptography (ECC) manner, and for example, the generated first public key may be a value calculated by combining (or multiplying) the private key and an elliptic curve point.

According to an embodiment, the processor360may encrypt a key pair of the first private key and first public key, and store same in the non-volatile area of the memory370.

According to an embodiment, the processor360may generate a first random number by using a predetermined secure random function and generate a first public element from the first random number by using an encryption algorithm. For example, the processor360may combine (or multiply) the generated first random number and an elliptic curve point to generate the first public element required to generate a session key (or symmetric key). The processor360may electrically sign the first public element by using the first private key to generate a first electronic signature.

According to an embodiment, the processor360may generate a first certificate for the first public key including the security level of the electronic device300. According to an embodiment, the first certificate may include at least a portion of the security level, account information, firmware version, software modification, device type, or list of child nodes of the electronic device300.

According to an embodiment, the processor360may transmit, to the external device, an attestation request including at least one piece of generated data (e.g., the first public element, the first electronic signature, and the first certificate).

According to an embodiment, the processor360may receive, from the external device (e.g., the second electronic device inFIG.2), an attestation request including a second public element, a second electronic signature, and a second certificate. According to an embodiment, the external device may generate the second public element, the second electronic signature, and the second certificate in substantially the same manner by which the electronic device300generates the first public element, the first electronic signature, and the first certificate.

According to an embodiment, the processor360may verify the received second certificate by using a root key prestored in the memory370. The root key may be injected to the non-volatile area of the memory330during the manufacturing of the electronic device300. According to an embodiment, the processor360may verify the second electronic signature by using the second public key built into the second certificate.

According to an embodiment, the processor360may identify the security level of the external device included in the second certificate. According to an embodiment, depending on a configuration (e.g.,FIGS.4A to4D) of the external device, the security level (or trust level) of the external device may be determined and the security level may be one of L1, L2, or L3. The security level of the external device may be stored during the manufacturing procedure of the external device and included in the second certificate generated by the external device. According to an embodiment, the second certificate acquired from the external device may further include at least one of at least a portion of account information of the external device (e.g., an account ID for accessing a service of the manufacturer of the external device), a firmware version, whether the software has been modified (integrity), a device type (e.g., whether the device has a child node in the IoT system, such as an IoT hub), a list of child nodes (e.g., a list of IoT devices connected to an IoT hub), the security level of the child nodes, or firmware information.

According to an embodiment, the processor360may provide an authority of the external device on a network including the electronic device300and the external device, based on the identified security level of the external device. For example, in case that the external device is identified to have the security level of L1, there may be provided an authority to determine addition of membership when configuring the network including the electronic device300and the external device and an authority to monitor network security. In case that the external device is identified to have the security level of L2, the external device may be provided with an authority to that allows only monitoring of network security.

According to an embodiment, the processor360may store the identified security level of the external device in a public area of the memory370.

According to an embodiment, the electronic device300may verify a proof of knowledge using the electronic signature through direct attestation with the external device as well as the security level of the other device so as to provide a service appropriate thereto.

FIGS.4A,4B,4C, and4Dare diagrams illustrating a security level of an electronic device according to various embodiments of the disclosure.

According to an embodiment, in an environment including multiple devices, a first electronic device (e.g., the first electronic device210inFIG.2) and a second electronic device (e.g., the second electronic device220inFIG.2) may identify the security level of the other device through mutual attestation and provide a service appropriate for the security level.FIGS.4A to4Dillustrate an example of a security level assigned according to a configuration of hardware and software included in a security environment of each electronic device. The electronic device (e.g., the electronic device300inFIG.3) may be realized as one of electronic devices410,430,450, and470inFIGS.4A to4D.

According to an embodiment, a trusted application (TA)411,431,451, or471may be an application executed in the security environment. For example, the trusted application411,431,451, or471may have an access authority to security data and may need to be executed in a secure area (secure world) distinguished from the normal area (normal world). As shown inFIGS.4A to4D, the trusted application411,431,451, or471may be executed in a different configuration (e.g., a processor412, a secure processor433, or a secure element454or474) depending on the security environment of the electronic device. The security level may be determined according to an execution position of the trusted application411,431,451, or471and/or a storage position of a key and certificate on the electronic device and, for example, security levels may be sequentially divided into L1, L2, and L3, which are sequentially higher levels of security.

FIG.4Aillustrates an example of executing the trusted application411in the security environment within the processor412.

Referring toFIG.4A, the electronic device410may include a platform420, a kernel, the processor412, a secure element, a flash memory416, and a connectivity module418.

According to an embodiment, the platform420may include a software framework and a hardware architecture for driving various software and may be implemented as, for example, an android platform.

According to an embodiment, the connectivity module418may include a communication module for supporting near-field wireless communication, such as Wi-Fi and Bluetooth provided by the platform420(or operation system).

According to an embodiment, a trust manager422and a network module426may be implemented on the platform420. The network module426corresponds to a network stack provided by the platform420(or operation system) and may control transmission and reception of near-field wireless communication data through the connectivity module418.

According to an embodiment, the trust manager422may correspond to a module for performing an operation associated with device-to-device attestation between the electronic device410and the external device. The trust manager422may be positioned between the security environment (e.g., the trust zone of the processor412) and the network module426, and may perform a function of processing data generated in the security environment and transmitting same to the outside or parsing a message received from the network module426and transferring same to the security environment.

According to an embodiment, the trust manager422may include a protocol module423and a key store module424. The protocol module423may include a module defining and implementing an inter-device communication protocol standard. The key store module424may include a module processing management of key used for an electronic signature and a certificate.

According to an embodiment, a key and certificate417generated in the trusted application411may be stored in the flash memory416. For example, the key and certificate417may be encrypted in the security environment inside the processor412and stored in an area of the flash memory416.

According to an embodiment, the trusted application411may be executed on the processor412. The embodiment ofFIG.4Amay show a trusted execution environment (TEE) implemented inside an application and a software execution environment protected by hardware. The embodiment is an example in which a trustzone is used in the security environment, and since the trustzone does not support a separated storage (or a non-volatile memory), a key may be encrypted through the trustzone and then stored on a normal area of the flash memory416.

In the embodiment ofFIG.4A, the trusted application411is not executed by separate security-specific hardware, and thus a security level of L2 may be provided. The embodiment is applicable to various devices supporting a security environment, such as the ARM trustzone, thus showing an advantage of high scalability.

FIG.4Billustrates an example of executing the trusted application431on the secure processor433independent from the normal area of the processor432.

According to an embodiment, the secure processor433may be implemented on a secure area independent from the normal area of the processor432. For example, the secure processor433may be packaged inside the processor432and may correspond to a secure chip implemented in an area physically separated from the normal area. The secure processor433may include a separate CPU and RAM and provide a security level in hardware level therethrough. The secure processor433shows a fast performance but may not include a storage (or flash memory), and thus permanent storage of data is impossible and software may be temporarily loaded.

According to an embodiment, the trusted application431may be executed on the secure processor433and the key and certificate437of the trusted application431generated on the secure processor433may be encrypted on the secure processor433and stored in the flash memory436.

According to the embodiment ofFIG.4B, a protocol for mutual attestation between the electronic device430and the external device may be implemented on the secure processor433which corresponds to a security-specific chip. In the case of the embodiment, the security in hardware level is implemented and thus the security level of L1 which is the highest level may be provided.

FIG.4Cillustrates an example in which the trusted application451is executed on the secure processor453independent from the normal area of the processor and the key and certificate457is stored on the secure element454.

According to an embodiment, the secure element454may correspond to a secure chip mounted outside the processor452. The secure element454may include an internal processor (or CPU), a volatile memory (e.g., a RAM), and a non-volatile memory, which operate independently from the processor452.

According to the embodiment ofFIG.4C, a protocol for mutual attestation between the electronic device450and the external device may be implemented on the secure processor453which corresponds to a security-specific chip. In addition, a key and certificate457generated in the trusted application451may be encrypted and stored in the non-volatile memory of the secure element454.

In the case of the embodiment, the security in hardware level is implemented and thus the security level of L1 which is the highest level may be provided. When comparing the embodiment ofFIG.4Cwith the embodiment ofFIG.4B, since the key and certificate457is stored in the storage area of the secure element454rather than the flash memory436, a higher level of security function may be provided.

FIG.4Dillustrates an example in which the trusted application471is executed on the secure element474outside the processor and the key and certificate477is stored on the secure element474.

According to the embodiment ofFIG.4D, a protocol for mutual attestation between the electronic device470and the external device may be implemented on the secure element474which corresponds to a security-specific chip outside the processor. According to an embodiment, the trusted application471may be executed on the secure element474. In addition, the key and certificate477generated in the trusted application471may be stored in a storage area of the secure element474.

In the case of the embodiment, the security in hardware level is implemented as the embodiment ofFIG.4Cand thus the security level of L1 which is the highest level may be provided.

According to various embodiments, the electronic device may pre-store, in the non-volatile area of the memory, the security level assigned according to a method (e.g.,FIGS.4A to4D) for implementing the security environment of the electronic device.

FIG.5is a signal flowchart illustrating a protocol for mutual attestation between electronic devices according to an embodiment of the disclosure.

In the following embodiment, respective operations may be sequentially performed, but are not necessarily sequentially performed. For example, the sequential position of each operation may be changed, or at least two operations may be performed in parallel.

The method described herein may be performed by a first electronic device (e.g., the first electronic device210inFIG.2) and a second electronic device (e.g., the second electronic device220inFIG.2), and the first electronic device and the second electronic device may respectively include the configuration and/or function of the electronic device300inFIG.3.

Referring toFIG.5, the first electronic device310may include a first secure module312, a first trust manager314(e.g., the trust manager422inFIGS.4A to4D), and a first connectivity module316(e.g., the connectivity module418inFIGS.4A to4D). The configuration of the second electronic device320may correspond to that of the first electronic device310and as described above, the second electronic device320may include a second secure module322, a second trust manager324, and a second connectivity module326.

According to an embodiment, the first secure module312and the second secure module322may respectively include a processor and a storage implemented on a secure area (secure world) of the first electronic device310and the second electronic device320.

According to an embodiment, the first electronic device310may include at least one configuration ofFIGS.4A to4Dand the security level (or trust level) (e.g., L1, L2, or L3) of the first electronic device310may be determined based on the included configuration. The security level of the first electronic device310may be stored in the non-volatile area of the memory (e.g., the memory370inFIG.3) of the first electronic device during the manufacture procedure of the first electronic device310. The security level of the second electronic device320may be stored in substantially the same manner as the security level of the first electronic device310.

According to an embodiment, an attestation key (e.g., the Samsung attestation key (SAK)) and a root key may be loaded on the secure area during the manufacturing procedure of the first electronic device310and the second electronic device320.

According to an embodiment, the security level of the electronic device (e.g., the first electronic device310and the second electronic device320) may be loaded on the secure module in an unmodifiable form. For example, it may be a state in which software including the security level is code signed and verified with a secure boot chain of the electronic device at a time point of operation. Here, the code signing (or code signature) is a digital signing process to ensure the reliability of the software including the security level and it may be ensured that code signed software is not modified or damaged. Accordingly, when arbitrarily attempting modification of the security level of the electronic device through a software attack, the attack may be filtered out by a secure boot (or trusted boot) chain of the electronic device.

According to an embodiment, when receiving an attestation request from the other device, the first electronic device310and the second electronic device320may read out the prestored security level and insert same into a newly generated electronic device.

According to an embodiment, in operation510, the first electronic device310and the second electronic device320may discover the other device through the first connectivity module316and the second connectivity module326, respectively. For example, the first electronic device310and the second electronic device320may identify the other device through Wi-Fi or Bluetooth scanning and establish near-field wireless communication connection. When the discovery and the wireless connection establishment are completed, the first electronic device310and the second electronic device320may initiate a mutual security verification procedure.

According to an embodiment, in operation512, in case that establishing connection with the second electronic device320through the second connectivity module326, the first trust manager314of the first electronic device310may transmit an attestation request to the first secure module312.

According to an embodiment, in operation520, the first secure module312may generate attestation request data required for the device attestation. For example, the first electronic device310may generate the first public element, the first electronic signature, and the first certificate.

According to an embodiment, the first secure module312perform an integrity check on a software module in the normal area (or normal world), a firmware version of the electronic device, and/or account information of the electronic device.

According to an embodiment, the first secure module312may generate a first private key of the first electronic device310. For example, the first secure module312may generate the first private key by using a cryptographically secure random function. Hereinafter, the first private key generated in the first electronic device310is defined as “a”.

According to an embodiment, the first secure module312may generate a first public key corresponding to the first private key. The first secure module312may generate the first public key in an elliptic curve cryptography (ECC) manner, and for example, the generated first public key may be aG calculated by combining (or multiplying) the first private key a and an elliptic curve point G. According to another embodiment, the first electronic device310may use an encryption method such as the RSA public key system, and in this case, the first electronic device310may generate the private key and the public key together.

According to an embodiment, the first secure module312may encrypt a key pair {a, aG} of the generated first private key and first public key and store same in the storage.

According to an embodiment, the first secure module312may generate a first random number x by using a predetermined secure random function and combine (or multiply) the generated first random number x and an elliptic curve point G to generate a first public element c1 required to generate a session key (or symmetric key). That is, the first public element c1 may be calculated as xG.

According to an embodiment, the first secure module312may electrically sign the first public element c1 by using the first private key a to generate the first electronic signature sig_a.

According to an embodiment, the first secure module312may generate a first certificate (attestation certificate) cert-a for the generated first public key aG. According to an embodiment, the first certificate cert-a may include the security level of the first electronic device310. For example, depending on a configuration (e.g.,FIGS.4A to4D) of the first electronic device310, the security level (or trust level) of the first electronic device310may be determined and the security level may be one of L1, L2, or L3. The security level of the first electronic device310may be stored in the non-volatile area of the memory during the manufacture procedure of the electronic device. According to an embodiment, the first certificate cert-a may further include at least one of at least a portion of account information (e.g., an account ID for accessing a service of the manufacturer of the first electronic device310) of the first electronic device310, a firmware version FW_a, whether the software has been modified (integrity), a device type (e.g., whether the device has a child node in the IoT system, such as an IoT hub), a list of child nodes (e.g., a list of IoT devices connected to an IoT hub), the security level of the child nodes, or firmware information.

According to an embodiment, in operation522, the first secure module312may transmit, to the first connectivity module316, the first public element c1, the first electronic signature sig_a, and the first certificate cert_a which are generated in operation520.

According to an embodiment, in operation524, the first connectivity module316may transmit, to the second electronic device320, an attestation request including the first public element c1, the first electronic signature sig_a, and the first certificate cert_a through the established near-field wireless communication connection (e.g., Wi-Fi or Bluetooth).

According to an embodiment, in operation526, the second connectivity module326of the second electronic device320may receive the attestation request from the first electronic device310and transfer the first public element c1, the first electronic signature sig_a, and the first certificate cert_a which are included in the attestation request data to the second secure module322.

According to an embodiment, in operation530, the second secure module322may verify the first public element c1, the first electronic signature sig_a, and the first certificate cert_a of attestation request data received from the first electronic device310. The second secure module322may verify the first certificate cert_a by using the root key loaded on the second electronic device320and verify the first public element c1 and the first electronic signature sig_a by using the first public key aG embedded in cert_a.

According to an embodiment, in operation532, the second secure module322may generate second attestation request data required for the device attestation. For example, the second electronic device320may generate the second public element, the second electronic signature, and the second certificate.

According to an embodiment, the second secure module322perform an integrity check on a software module in the normal area (or normal world), a firmware version of the second electronic device320, and/or account information of the second electronic device320.

According to an embodiment, the second secure module322may generate a second private key of the second electronic device320. For example, the second secure module322may generate the second private key by using a cryptographically secure random function. Hereinafter, the second private key generated in the second electronic device320is defined as “b”.

According to an embodiment, the second secure module322may generate a second public key corresponding to the second private key. The second secure module322may generate the second public key in an elliptic curve cryptography (ECC) manner, and for example, the generated second public key may be bG calculated by combining (or multiplying) the private key b and an elliptic curve point G. According to another embodiment, the second electronic device320may use an encryption method such as the RSA public key system, and in this case, the second electronic device320may generate the private key and the public key together.

According to an embodiment, the second secure module322may encrypt a key pair {b, bG} of the generated second private key and second public key and store same in the storage.

According to an embodiment, the second secure module322may generate a second random number y by using a predetermined secure random function and combine (or multiply) the generated second random number y and an elliptic curve point G to generate a second public element c2 required to generate a session key (or symmetric key). That is, the second public element c2 may be calculated as yG.

According to an embodiment, the second secure module322may electrically sign the second public element c2 by using the second private key b to generate the second electronic signature sig_b.

According to an embodiment, the second secure module322may generate a second certificate (attestation certificate) cert-b for the generated second public key bG. According to an embodiment, the second certificate cert-b may include the security level of the second electronic device320. For example, depending on a configuration (e.g.,FIGS.4A to4D) of the second electronic device320, the security level (or trust level) of the second electronic device320may be determined and the security level may be one of L1, L2, or L3. The security level of the second electronic device320may be stored during the manufacture procedure of the second electronic device320. According to an embodiment, the second certificate cert_b may further include at least one of at least a portion of account information (e.g., an account ID for accessing a service of the manufacturer of the second electronic device320) of the second electronic device320, a firmware version FW_a, whether the software has been modified (integrity), a device type (e.g., whether the device has a child node in the IoT system, such as an IoT hub), a list of child nodes (e.g., a list of IoT devices connected to an IoT hub), the security level of the child nodes, or firmware information.

According to an embodiment, in operation533, the second secure module322may generate a second AC value to be used for encryption and integrity identification.

According to an embodiment, the second secure module322may combine the second random number y generated using the predetermined secure random function and the first public element c1 (xG) received from the first electronic device310to generate a key xyG. The generated key xyG is used for encryption and integrity identification and may be derived and calculated once more by using a key derivation function (KDF) and a pseudo random function (PRF) as shown in Equation 1 and Equation 2.

Equation 1 is merely an example to help understanding without limitation thereto and may be modified, applied, or expanded in various manners.

In Equation 1, tag1 may be a predetermined string (e.g., Mac) or a fixed number value and may be publicized.

Equation 2 is merely an example to help understanding without limitation thereto and may be modified, applied, or expanded in various manners.

In Equation 2, tag2 may be a predetermined string (e.g., Enc) or a number value and may be publicized.

According to an embodiment the second secure module322may calculate an arithmetic complexity (AC) value for identifying the MK and EK as shown in Equation 3.

Equation 3 is merely an example to help understanding without limitation thereto and may be modified, applied, or expanded in various manners.

In Equation 3, tag3 may be a predetermined string (e.g., confirm) or a number value and may be publicized.

According to an embodiment, in operation534, the second secure module322may transfer, to the second connectivity module326, the second public element c2, the second electronic signature sig_b, and the second certificate cert_b, and the second AC value AC_b generated in operation533.

According to an embodiment, in operation536, the second connectivity module326may transmit, to the first electronic device310, an attestation request including the second public element c2, the second electronic signature sig_b, and the second certificate cert_b through the established near-field wireless communication connection (e.g., Wi-Fi or Bluetooth).

According to an embodiment, in operation538, the first connectivity module316of the first electronic device310may receive the attestation request from the second electronic device320and transfer the second public element c2, the second electronic signature sig_b, and the second certificate cert_b which are included in the attestation request data to the first secure module312.

According to an embodiment, in operation540, the first secure module312may verify the second public element c2, the second electronic signature sig_b, and the second certificate cert_b of the attestation request data received from the second electronic device320. The first secure module312may verify the second certificate cert_b by using the root key loaded on the first electronic device310and verify the second electronic signature sig_b of the second public element c2 by using the second public key bG embedded in cert_b.

According to an embodiment, in operation541, the first secure module312may generate a first AC value to be used for encryption and integrity identification.

According to an embodiment, the first secure module312may combine the first random number x generated using the predetermined secure random function and the second public element c2 (yG) received from the second electronic device320to generate a key xyG. The generated key xyG is used for encryption and integrity identification and may be derived and calculated once more by using a key derivation function (KDF) and a pseudo random function (PRF) as shown in Equation 1 and Equation 2 described above.

According to an embodiment the first secure module312may calculate an arithmetic complexity (AC) value for identifying the MK and EK as shown in Equation 3 described above.

According to an embodiment, in operation542, the first secure module312may identify whether the first AC value AC_a calculated in operation541and the second AC value AC_b received from the second electronic device320are identical to each other.

According to an embodiment, in case that the first AC value AC_a and the second AC value AC_b are identical to each other, in operation560, the first secure module312may encrypt {the first private key a, the first certificate cert_a, MK, EK, and an ID} through a key which may only be accessed in a secure area and store same in the storage. In addition, the first secure module312may store {the first public key aG, an ID ID_a of the first electronic device310, the security level TL_a of the first electronic device310, and the firmware information FW_a of the first electronic device310} in a publicized local storage or a verified network storage.

According to an embodiment, in operation543, the first secure module312may transmit the generated first AC value to the first connectivity module316and in operation544, the first connectivity module316may transmit the first AC value to the second electronic device320. In operation546, the second connectivity module326may receive the first AC value from the first electronic device310and transmit same to the second secure module322.

According to an embodiment, in operation550, the second secure module322may identify whether the second AC value AC_b calculated in operation533and the first AC value AC_a received from the first electronic device310are identical to each other.

According to an embodiment, in case that the first AC value AC_a and the second AC value AC_b are identical to each other, in operation570, the second secure module322may encrypt {the second private key b, the second certificate cert_b, MK, EK, and an ID} through a key which may only be accessed in a secure area and store same in the storage. In addition, the second secure module322may store {the second public key bG, an ID ID_b of the second electronic device320, the security level TL_b of the second electronic device320, and the firmware information FW_b of the second electronic device320} in a publicized local storage or a verified network storage.

By using a result acquired executing the protocol described above, the first electronic device310and the second electronic device320verify the certificate and electronic signature received from the other device by using the root key respectively inserted during the manufacture procedure and thus it may be identified that the electronic devices are manufactured by the same manufacturer. In addition, the first electronic device310and the second electronic device320may identify that the other device is signed by the key which may only be accessed in a secure area.

According to an embodiment, the first electronic device310and the second electronic device320may identify the security level of the other device stored in the certificate of the other device. Furthermore, the first electronic device310and the second electronic device320may further identify at least a portion of the account information, the firmware version, whether software has been modified, the device type, the list of child nodes, the security level of child nodes, and the firmware information stored in the certificate of the other device.

According to an embodiment, in case that the protocol has a problem (e.g., in case that the first AC value and the second AC value are not identical to each other), the protocol may be ended immediately and the first electronic device310and the second electronic device320may release the connection with the other device and prevent the other device from participating in the network.

According to an embodiment, in case that the protocol execution result verification is completed, the first electronic device310and the second electronic device320may identify the security level of the other device and store the identified security level in a public storage of which integrity is protected.

According to an embodiment, the first electronic device310and the second electronic device320may use the security levels of both devices for authority control when a secure service is operated between two devices. For example, in case that the second electronic device320is identified to have the security level of L1, the first electronic device310may provide an authority to determine addition of membership when configuring the whole network and/or an authority to monitor network security. Alternatively, in case that the second electronic device320is identified to have the security level of L2, the first electronic device310may provide an authority to the second electronic device320in a level of only monitoring the network security.

FIG.6is a signal flowchart illustrating a protocol for mutual attestation between electronic devices according to an embodiment of the disclosure.

In the following embodiment, respective operations may be sequentially performed, but are not necessarily sequentially performed. For example, the sequential position of each operation may be changed, or at least two operations may be performed in parallel.

FIG.6illustrates a method for providing updated information when device information of the first electronic device310, such as the account information and/or the firmware version, is updated after the device attestation between the first electronic device310and the second electronic device320is completed through the procedure ofFIG.5.

According to an embodiment, in operation610, the first electronic device310and the second electronic device320may discover the other device through the first connectivity module316and the second connectivity module326, respectively.

According to an embodiment, in operation612, the first trust manager314of the first electronic device310may transmit an attestation request to the first secure module312. The first trust manager314may transmit the attestation request in case that a change of the device information of the first electronic device310is identified.

According to an embodiment, in operation614, the first secure module312may load the first private key a, the first certificate cert_a, MK, and EK stored in the secure area of the storage. The first private key a, the first certificate cert_a, MK, and EK may be encrypted and stored in the secure area of the storage and the first secure module312may decrypt the encrypted information.

According to an embodiment, in operation620, the first secure module312may update the first certificate cert_a. For example, the first secure module312may change the device information (e.g., the account information or the firmware version) of the first electronic device310to changed device information. The first secure module312may generate an updated certificate including the second public key bG received from the second electronic device320, the security level TL_a of the first electronic device310, and the firmware information FW_a. According to an embodiment, the first secure module312may generate the certificate by using an attestation key (e.g., the Samsung attestation key (SEK)) when generating the updated certificate.

According to an embodiment, the first secure module312may electrically sign the changed device information by using the first private key a to generate an electronic signature sig_a{diff} of the updated device information.

According to an embodiment, in operation622, the first secure module312may transmit, to the first connectivity module316, the updated device information diff, the updated electronic signature sig_a, and the updated certificate cert_a.

According to an embodiment, in operation624, the first connectivity module316may transmit, to the second electronic device320, an attestation update request including the updated device information diff, the updated electronic signature sig_a, and the updated certificate cert_a, through the near-field wireless communication connection.

According to an embodiment, in operation626, the second connectivity module326may transfer, to the second secure module322, the updated device information diff, the updated electronic signature sig_a, and the updated certificate cert_a included in an attestation update response received from the first electronic device310.

According to an embodiment, in operation630, the second secure module322may verify the updated electronic signature sig_a and the updated certificate cert_a received from the first electronic device310. The second secure module322may verify the updated certificate cert_a by using the root key loaded on the second electronic device320and verify the updated electronic signature sig_a by using a public key bG embedded in cert_a.

According to an embodiment, in operation632, the second secure module322may generate an AC value to be used for encryption and integrity identification. For example, the AC value may be calculated as in Equation 4 below.

Equation 4 is merely an example to help understanding without limitation thereto and may be modified, applied, or expanded in various manners.

According to an embodiment, in operation634, the second secure module322may transfer the AC value to the second connectivity module326. In operation636, the second connectivity module326may transmit an attestation update response including the transferred AC value to the first electronic device310through the near-field communication connection.

According to an embodiment, in operation638, the first connectivity module316may transmit the AC value included in the attestation update response received from the second electronic device320to the first secure module312.

According to an embodiment, in operation640, an AC value is calculated and it may be identified that the AC value is identical to the AC value received from the second electronic device320.

According to an embodiment, in operation650, the first secure module312may encrypt {the first private key a, the first certificate cert_a, MK, EK, and the ID} through a key which may only be accessed in a secure area and store same in the storage.

According to an embodiment, in operation660, the second secure module322may store {the second public key bG, the ID ID_b of the second electronic device320, the security level TL_b of the second electronic device320, and the firmware information FW_b of the second electronic device320} in a publicized local storage or a verified network storage.

For the mutual attestation of the first electronic device310and the second electronic device320, in the case of using a server-client-based attestation, two procedures may be required for attesting the first electronic device and the second electronic device on the server, and compared with this, the embodiments of the disclosure may more efficiently implement a communication round. In addition, the embodiments of the disclosure may remove an additional communication round by combining and sending attestation and a key sharing message for communication efficiency. Furthermore, the embodiments of the disclosure may classify nodes having various security capacities for each security level, attest same, and assign an authority appropriate to the security level.

FIG.7is a flowchart of a method of an electronic device for mutually attesting security levels of an external device according to an embodiment of the disclosure.

In the following embodiment, respective operations may be sequentially performed, but are not necessarily sequentially performed. For example, the sequential position of each operation may be changed, or at least two operations may be performed in parallel.

A method to be described may be performed by an electronic device (e.g., the first electronic device210or the second electronic device220inFIG.2, or the electronic device300inFIG.3), and the description of the technical features that have been described will be omitted below.

According to an embodiment, in operation710, the electronic device (e.g., the first electronic device210inFIG.2) may establish near-field wireless communication connection with an external device (e.g., the second electronic device220inFIG.2). For example, the electronic device and the external device may support near-field wireless communication, such as Wi-Fi, Bluetooth, or Bluetooth low energy (BLE), and the near-field wireless communication connection with the external device may be established through a communication module. In case that the near-field wireless communication connection between the electronic device and the external device is established, a process for the mutual attestation may be performed.

According to an embodiment, in operation720, the electronic device may generate a first private key by using a determined random function. For example, the electronic device may generate the first private key by using a cryptographically secure random function.

According to an embodiment, in operation730, the electronic device may generate a first public key based on the first private key. According to an embodiment, the electronic device may generate the first public key in an elliptic curve cryptography (ECC) manner, and for example, the generated first public key may be a value calculated by combining (or multiplying) the private key and an elliptic curve point. According to an embodiment, the electronic device may encrypt a key pair of the first private key and first public key, and store same in a non-volatile area of the memory (e.g., the memory370inFIG.3).

According to an embodiment, in operation740, the electronic device may generate a first certificate for the first public key including the security level of the electronic device. According to an embodiment, the first certificate may include at least a portion of the security level, account information, firmware version, software modification, device type, or list of child nodes of the electronic device300. According to an embodiment, the electronic device may generate a first random number by using a predetermined secure random function and generate a first public element from the first random number by using an encryption algorithm. In addition, the electronic device may electrically sign the first public element by using the first private key to generate a first electronic signature.

According to an embodiment, in operation750, the electronic device may transmit the generated first certificate to the external device. The electronic device may transmit an attestation request including the first certificate to the external device through the established near-field wireless communication connection with the external device. According to an embodiment, the attestation request transmitted from the electronic device may further include the first public element and the first electronic signature generated earlier.

According to an embodiment, the electronic device may receive a second public element, a second electronic signature, and a second certificate generated from the external device. The electronic device may verify the second certificate by using a root key stored in the memory and verify the second electronic signature by using the second public key embedded in the second certificate. Through the attestation procedure, the electronic device may identify the security level of the external device and provide an authority to the external device on a network based on the security level. For example, in case that the external device is identified to have the security level of L1, there may be provided an authority to determine addition of membership when configuring the network including the electronic device300and the external device and an authority to monitor network security. In case that the external device is identified to have the security level of L2, the external device may be provided with an authority to that allows only monitoring of network security.

The electronic device according to various embodiments of the disclosure may include a communication module for supporting near-field wireless communication, memory, and at least one processor operatively connected to the communication module and the memory. According to various embodiments, the memory stores one or more programs including instructions that, when executed by the at least one processor, may cause the electronic device to establish near-field wireless communication connection with an external device through the communication module, generate a first private key by using a determined random function, generate a first public key based on the first private key, generate a first certificate including a security level of the electronic device with respect to the first public key, and transmit the generated first certificate to the external device through the communication module.

According to various embodiments, the security level of the electronic device may be determined based on at least one of a hardware configuration for executing a trusted application, or an attestation key of the electronic device and a storage location of a certificate for the attestation key.

According to various embodiments, in case that the trusted application is executed on security-specific hardware configured inside or outside the at least one processor, the security level of the electronic device may be determined as a first level, and in case that the trusted application is executed on a partial area of the at least one processor, the security level of the electronic device may be determined as a second level lower than the first level.

According to various embodiments, the first certificate may include at least one of at least a portion of account information, a firmware version, whether software has been modified, a device type, or a list of child nodes of the electronic device.

According to various embodiments, the one or more programs further include instructions that, when executed by the at least one processor, may cause the electronic device to generate a first random number by using a determined random function, generate a first public element from the first random number by using an encryption algorithm, electrically sign the first public element by using the first private key to generate a first electronic signature, and transmit the first public element, the first electronic signature, and the first certificate to the external device through the communication module.

According to various embodiments, the one or more programs further include instructions that, when executed by the at least one processor, may cause the electronic device to receive a second public element, a second electronic signature, and a second certificate from the external device through the communication module, verify the second certificate by using a prestored root key, and verify the second electronic signature by using a second public key included in the second certificate.

According to various embodiments, the one or more programs further include instructions that, when executed by the at least one processor, may cause the electronic device to identify a security level of the external device included in the second certificate.

According to various embodiments, the one or more programs further include instructions that, when executed by the at least one processor, may cause the electronic device to provide an authority of the external device on a network including the electronic device and the external device, based on the identified security level of the external device.

According to various embodiments, the one or more programs further include instructions that, when executed by the at least one processor, may cause the electronic device to store the identified security level of the external device in a public area of the memory.

A method, performed by an electronic device, to mutually attest a security level of an external device according to various embodiments of the disclosure may include an operation of establishing near-field wireless communication connection with the external device, an operation of generating a first private key by using a determined random function, an operation of generating a first public key based on the first private key, an operation of generating a first certificate including a security level of the electronic device with respect to the first public key, and an operation of transmitting the generated first certificate to the external device.

According to various embodiments, the security level of the electronic device may be determined based on at least one of a hardware configuration for executing a trusted application, or an attestation key of the electronic device and a storage location of a certificate for the attestation key.

According to various embodiments, in case that the trusted application is executed on security-specific hardware configured inside or outside at least one processor of the electronic device, the security level of the electronic device may be determined as a first level, and in case that the trusted application is executed on a partial area of the at least one processor, the security level of the electronic device may be determined as a second level lower than the first level.

According to various embodiments, the first certificate may include at least one of at least a portion of account information, a firmware version, whether software has been modified, a device type, or a list of child nodes of the electronic device.

According to various embodiments, the method may further include an operation of generating a first random number by using a determined random function, an operation of generating a first public element from the first random number by using an encryption algorithm, an operation of electrically signing the first public element by using the first private key to generate a first electronic signature, and an operation of transmitting the first public element, the first electronic signature, and the first certificate to the external device.

According to various embodiments, the method may further include an operation of receiving a second public element, a second electronic signature, and a second certificate from the external device, an operation of verifying the second certificate by using a prestored root key, and an operation of verifying the second electronic signature by using a second public key included in the second certificate.

According to various embodiments, the method may further include an operation of identifying a security level of the external device included in the second certificate.

According to various embodiments, the method may further include an operation of providing an authority of the external device on a network including the electronic device and the external device, based on the identified security level of the external device.

According to various embodiments, the method may further include an operation of storing the identified security level of the external device in a public area of memory of the electronic device.

One or more non-transitory computer-readable storage media storing one or more programs including instructions that, when executed by at least one processor of an electronic device, according to various embodiments of the disclosure may cause the electronic device to perform operations. According to various embodiments, the operations may include establishing near-field wireless communication connection with an external device, generating a first private key by using a determined random function, generating a first public key based on the first private key, generating a first certificate including a security level of the electronic device with respect to the first public key, and transmitting the generated first certificate to the external device.

According to various embodiments, the security level of the electronic device may be determined based on at least one of a hardware configuration configured to execute a trusted application, or an attestation key of the electronic device and a storage location of a certificate for the attestation key.

According to various embodiments, in case that the trusted application is executed on security-specific hardware configured inside or outside the at least one processor, the security level of the electronic device may be determined as a first level. According to various embodiments, in case that the trusted application is executed on a partial area of the at least one processor, the security level of the electronic device may be determined as a second level lower than the first level.

According to various embodiments, the first certificate further includes at least one of at least a portion of account information, a firmware version, whether software has been modified, a device type, or a list of child nodes of the electronic device.

According to various embodiments, the operations may further include generating a first random number by using a determined random function, generating a first public element from the first random number by using an encryption algorithm, electrically signing the first public element by using the first private key to generate a first electronic signature, and transmitting the first public element, the first electronic signature, and the first certificate to the external device.

According to various embodiments, the operations may further include receiving a second public element, a second electronic signature, and a second certificate from the external device, verifying the second certificate by using a prestored root key, and verifying the second electronic signature by using a second public key included in the second certificate.

According to various embodiments, the operations may further include identifying a security level of the external device included in the second certificate.

According to various embodiments, the operations may further include providing an authority of the external device on a network including the electronic device and the external device, based on the identified security level of the external device.

According to various embodiments, the operations may further include storing the identified security level of the external device in a public area of memory of the electronic device.