Apparatus and method for authenticating smart factory

Abstract

An apparatus and a method for authenticating a smart factory are disclosed. An apparatus for authenticating a smart factory, according to an embodiment of the present invention, comprises: a memory in which at least one program is recorded; and a processor that executes the program, wherein the program receives a certificate for each of an intermediate device and an IoT device from a cloud CA through a certificate management server, matches the issued certificate to a hash tree, and transmits the issued certificate to a corresponding device, wherein the hash tree may be configured such that each hash is layered so as to correspond to a connection configuration of an operating server, the intermediate device, and the IoT device.

Description

Smart factory authentication device and method

[0001] The described embodiment relates to a technique for authenticating devices configured in a smart factory.

[0002] Globally, the share of the working-age population is rapidly declining due to declining birth rates, rapid aging, and rising wages. To overcome this, innovative improvements in production efficiency are essential. Automation is a key element in the Fourth Industrial Revolution, ensuring the productivity and competitiveness of industries and companies.

[0003] Accordingly, the importance of smart factories, intelligent production plants that apply information and communication technology (ICT) to various production processes, including design, development, manufacturing, quality control, and distribution, is growing. These smart factories are future-oriented factories that collect process data in real time via the Internet of Things (IoT), analyze it, and control themselves.

[0004] However, these IoT-based smart factories are exposed to various security threats, such as damage to the integrity of device data, network attacks in the IoT communication environment, authentication bypass of devices and users, and data manipulation and integrity damage in the application area.

[0005] Therefore, there is a growing need to strengthen authentication of devices and transmitted / received data in these IoT-based smart factories to prepare for security threats.

[0006] The purpose of the described embodiment is to strengthen authentication of devices and transmitted / received data in an IoT-based smart factory to prepare for security threats.

[0007] A smart factory authentication device according to an embodiment includes a memory in which at least one program is recorded, and a processor that executes the program, wherein the program issues a certificate for each intermediate device and IoT device from a cloud CA through a certificate management server, matches the issued certificate to a hash tree, and transmits the issued certificate to the corresponding device, wherein the hash tree may be configured in a hierarchical form in which each hash corresponds to a connection configuration of the operating server, the intermediate device, and the IoT device.

[0008] At this time, the hash tree may be composed of a first hash generated based on unique information of the IoT device, a second hash generated based on a hash table including a first hash matching at least one IoT device connected below the intermediate device, and a third hash generated based on a hash table including a second hash matching at least one intermediate device connected below the operating server.

[0009] At this time, the unique information may include MAC or serial number.

[0010] At this time, the program can obtain a certificate of the new device as a new device registration request is made, regenerate a hash tree that additionally reflects the hash of the new device, rematch the certificate to the regenerated hash tree, and transfer the obtained certificate to the new device.

[0011] At this time, when obtaining a certificate for a new device, the program checks whether a certificate for the new device has already been issued, and if so, requests and obtains a certificate from the new device, and if not so issued, requests and obtains a certificate for the new device from the certificate management server.

[0012] At this time, the program can request the cloud CA to revoke the certificate of the new device through the certificate management server in response to a request for removal of the registered device, regenerate a hash tree reflecting the deleted hash of the removed device, and rematch the certificate to the regenerated hash tree.

[0013] At this time, the program can verify the certificate that signed the data as data is received from the intermediate device, verify the hash transmitted with the data based on the certificate verification result, verify the hash tree, and confirm or discard based on whether the hash tree is verified.

[0014] At this time, the program verifies the certificate by obtaining a Certificate Revoke List (CRL) from the verification server, or requests verification by transmitting the certificate to the verification server so that it can be compared and confirmed with the certificate revocation list. However, the Certificate Revoke List (CRL) can be transmitted to the verification server as it is updated by the cloud CA.

[0015] At this time, the data received from the intermediate device may be a fifth hash generated based on the second hash and the first data generation variable, and the data received from the IoT device may be signed with the intermediate device's certificate, and the data received from the IoT device may be a fourth hash generated based on the first hash and the second data generation variable, and the data generated from the IoT device may be signed with the IoT device's certificate.

[0016] At this time, the program may verify the fifth hash based on the second hash and the first data generation variable of the intermediate device previously stored in the hash verification process, and the fourth hash may be verified based on the first hash and the second data generation variable previously stored by the intermediate device.

[0017] In a smart factory authentication method according to an embodiment, a step of receiving a certificate for each intermediate device and IoT device from a cloud CA through a certificate management server, a step of matching the issued certificate to a hash tree, and a step of transmitting the issued certificate to the corresponding device are included, wherein the hash tree may be configured in a hierarchical form in which each hash corresponds to a connection configuration of an operating server, an intermediate device, and an IoT device.

[0018] At this time, the hash tree may be composed of a first hash generated based on unique information of the IoT device, a second hash generated based on a hash table including a first hash matching at least one IoT device connected below the intermediate device, and a third hash generated based on a hash table including a second hash matching at least one intermediate device connected below the operating server.

[0019] At this time, the unique information may include MAC or serial number.

[0020] At this time, the smart factory authentication method according to the embodiment may further include a step of obtaining a certificate of a new device when a new device registration request is made, a step of regenerating a hash tree that additionally reflects a hash of the new device, a step of re-matching the certificate to the re-generated hash tree, and a step of transferring the obtained certificate to the new device.

[0021] At this time, the step of obtaining a certificate for a new device may include a step of checking whether a certificate for the new device has already been issued, a step of requesting and obtaining a certificate from the new device if the certificate has already been issued, and a step of requesting and obtaining a certificate for the new device from a certificate management server if the certificate has not already been issued.

[0022] At this time, the smart factory authentication method according to the embodiment may further include a step of requesting the cloud CA to revoke a certificate of a new device through a certificate management server when a request for removal of a registered device is made, a step of regenerating a hash tree that reflects the deleted hash of the removed device, and a step of re-matching the certificate to the re-generated hash tree.

[0023] A smart factory authentication method according to an embodiment includes a step of verifying a certificate that signed data when data is received from an intermediate device, a step of verifying a hash transmitted together with the data based on a certificate verification result, a step of verifying a hash tree, and a step of confirming or discarding the data based on whether the hash tree has been verified, wherein the hash tree may be configured in a hierarchical form in which each hash is hierarchized to correspond to a connection configuration of an operating server, an intermediate device, and an IoT device.

[0024] At this time, the step of verifying the certificate may be to obtain a Certificate Revoke List (CRL) from the verification server and verify the certificate, or to request verification by transmitting the certificate to the verification server so that it can be compared and confirmed with the certificate revocation list. However, the Certificate Revoke List (CRL) may be transmitted to the verification server as it is updated by the cloud CA.

[0025] At this time, the hash tree is composed of a first hash generated based on unique information of the IoT device, a second hash generated based on a hash table including a first hash matching at least one IoT device connected below the intermediate device, and a third hash generated based on a hash table including a second hash matching at least one intermediate device connected below the operating server, and data received from the intermediate device may be a fifth hash generated based on the second hash and the first data generation variable and data received by the intermediate device from the IoT device signed with a certificate of the intermediate device, and data received from the IoT device may be a fourth hash generated based on the first hash and the second data generation variable and data generated by the IoT device signed with a certificate of the IoT device.

[0026] At this time, the step of verifying the hash may verify the fifth hash based on the second hash and the first data generation variable of the previously stored intermediate device, and the fourth hash may be verified based on the first hash and the second data generation variable previously stored by the intermediate device.

[0027] According to the described embodiment, authentication of devices and transmitted / received data in an IoT-based smart factory can be strengthened to prepare for security threats.

[0028] Figure 1 is a schematic block diagram of a smart factory authentication system according to an embodiment.

[0029] Figure 2 is an example diagram of a hash tree according to an embodiment.

[0030] Figure 3 is a flowchart for explaining the schematic operation of a smart factory authentication method according to an embodiment.

[0031] FIG. 4 is a signal flow diagram for explaining a process of linking a certificate management server and a verification server to a cloud CA according to an embodiment.

[0032] FIG. 5 is a signal flow diagram for explaining a process of linking an operating server to an authentication system according to an embodiment.

[0033] FIG. 6 is a signal flow diagram for explaining a process for initially issuing certificates for components of a smart factory system according to an embodiment.

[0034] FIG. 7 is a signal flow diagram for explaining steps for generating a hash tree according to an embodiment.

[0035] FIG. 8 is a signal flow diagram illustrating a step of matching and transmitting a certificate to a hash tree according to an embodiment.

[0036] FIG. 9 is a signal flow diagram for explaining a process of additionally issuing a certificate in response to a new device registration request according to an embodiment.

[0037] FIG. 10 is a signal flow diagram illustrating a process for revoking a certificate in response to a request for removal of a registered device according to an embodiment.

[0038] Fig. 11 is a signal flow diagram for explaining a process of verifying transmitted data using a certificate issued according to an embodiment.

[0039] FIG. 12 and FIG. 13 are signal flow diagrams for explaining a process of verifying data and hash transmitted using a certificate issued according to an embodiment.

[0040] Fig. 14 is a diagram showing a computer system configuration according to an embodiment.

[0041] The advantages and features of the present invention, and the methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various different forms. These embodiments are provided only to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims. Like reference numerals designate like elements throughout the specification.

[0042] Although "first" or "second" are used to describe various components, these components are not limited by such terms. Such terms may only be used to distinguish one component from another. Accordingly, a first component referred to below may also be a second component within the technical scope of the present invention.

[0043] The terminology used herein is for the purpose of describing embodiments and is not intended to limit the present invention. In this specification, the singular also includes the plural unless specifically stated otherwise. As used herein, the terms "comprises" or "comprising" imply that a stated component or step does not exclude the presence or addition of one or more other components or steps.

[0044] Unless otherwise defined, all terms used herein are to be interpreted as having a meaning commonly understood by those of ordinary skill in the technical field to which the present invention pertains. Furthermore, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless explicitly and specifically defined otherwise.

[0045] Figure 1 is a schematic block diagram of a smart factory authentication system according to an embodiment.

[0046] Referring to FIG. 1, a smart factory authentication system according to an embodiment can be configured so that a cloud certificate authority device (hereinafter referred to as a 'cloud CA') (10) existing in an Internet network (1) issues a certificate to a smart factory system (3-1, 3-1, ...3-N) configured as a closed network (2), and the smart factory system (3-1, 3-1, ...3-N) can use the issued certificate to authenticate when transmitting and receiving data.

[0047] At this time, the smart factory authentication system according to the embodiment may further include a certificate management server (20) and a verification server (30) between the cloud CA (10) and the smart factory system (3-1, 3-1, ...3-N), thereby relaying certificate issuance / revocation and certificate verification. The detailed operations of the certificate management server (20) and the verification server (30) will be described later with reference to FIGS. 4 to 13.

[0048] Meanwhile, the smart factory system (3-1, 3-1, ...3-N) may include an operation server (40), an intermediate device (50), and an IoT device (60).

[0049] At this time, the operating server (40) can receive a certificate for each of the intermediate device (50) and the IoT device (60) from the cloud CA (10) through the certificate management server (20), match the issued certificate to a hash tree, and transmit the issued certificate to the corresponding device.

[0050] Additionally, the operating server (40) can verify data transmitted from each of the intermediate device (50) and the IoT device (60) using the issued certificate and matching hash.

[0051] At this time, the hash tree may be configured in a hierarchical form in which each hash corresponds to the connection configuration of the operating server (40), intermediate device (50), and IoT device (60).

[0052] Figure 2 is an example diagram of a hash tree according to an embodiment.

[0053] Referring to FIG. 2, a smart factory system (3-1, 3-1, ...3-n) may be configured such that at least one intermediate device (51, 52, ..., 5n) is connected to an operation server (40), and each of the at least one intermediate device (51, 52, ..., 5n) has at least one IoT device connected thereto.

[0054] That is, at least one IoT device (61-1, 61-2, ... 61-M) can be connected to the lower part of the intermediate device (51), at least one IoT device (62-1, 62-2, ... 62-K) can be connected to the lower part of the intermediate device (52), and at least one IoT device (6N-1, 6N-2, ... 6N-L) can be connected to the lower part of the intermediate device (5n).

[0055] Accordingly, the hash tree can have a hierarchical connection structure in which each hash corresponds to the hierarchical connection structure of the components of the smart factory system. The creation of this hash tree will be described in detail later with reference to Figure 7.

[0056] Meanwhile, the intermediate device (50) may be an HMI (Human-Machine Interface) or a PLC (Programmable Logic Controller), as shown in FIGS. 1 and 2.

[0057] Here, the HMI (Human-Machine Interface) may be a device capable of interfacing with a user, such as a button interface and a touch interface. The PLC (Programmable Logic Controller) may be an intermediate device that controls the IoT device (60).

[0058] The IoT device (60) may be directly connected to a PLC or may be connected to an HMI.

[0059] Then, with reference to FIGS. 3 to 13, the smart factory authentication method in the authentication system described above will be described in detail.

[0060] Figure 3 is a flowchart for explaining the schematic operation of a smart factory authentication method according to an embodiment.

[0061] Referring to FIG. 3, a smart factory authentication method according to an embodiment may largely include a process of linking server devices for smart factory system authentication (S110 to S120), a process of issuing certificates for components of a smart factory system (S130 to S170), and a process of verifying transmitted data using the issued certificates (S180 to S190, FIGS. 11 to 13).

[0062] At this time, the process of linking server devices for smart factory system authentication (S110 to S120) may include a process of linking a certificate management server (20) and a verification server (30) to a cloud CA (10) in an Internet network (S110, FIG. 4) and a process of linking an operation server (40) of the smart factory system to an authentication system in an Internet network (S120, FIG. 5).

[0063] At this time, the process of issuing certificates for components of the smart factory system (S130 to S170) may include a process of initially issuing certificates for components of the smart factory system (S130, FIG. 6), a process of additionally issuing certificates in response to a request for new device registration (S140 to S150, FIG. 9), and a process of discarding certificates in response to a request for removal of a registered device (S160 to S170, FIG. 10).

[0064] Here, each of the processes of initial issuance, additional issuance, and revocation of a certificate according to an embodiment may include a process of generating a hash tree (Fig. 7) and a process of matching and transferring an issued certificate to the hash tree (Fig. 8).

[0065] FIG. 4 is a signal flow diagram for explaining a process of linking a certificate management server and a verification server to a cloud CA according to an embodiment.

[0066] Referring to Fig. 4, the company manager accesses the cloud CA (10) through the certificate management server (20) and performs the membership registration procedure (S210).

[0067] Then, the cloud CA (10) verifies the API connection of the certificate management server (20) (S220) and receives a connection success response (S230) from the certificate management server (20) to complete the data session establishment.

[0068] In addition, the cloud CA (10) verifies the API connection of the verification server (30) (S240) and completes the data session establishment by receiving a connection success response (S250) from the verification server (30).

[0069] When the cloud CA (10) and the verification server (30) are linked in this way, a certificate revocation list (CRL) can be periodically distributed (S260) from the cloud CA (10) to the verification server (30). That is, when a certificate issued at the request of the certificate management server (20) is revoked, the cloud CA (10) transmits an updated certificate revocation list (CRL) to the verification server (30).

[0070] Then, the verification server (30) stores the received certificate revocation list (CRL) (S270) and responds to the cloud CA (10) that the storage is complete (S270).

[0071] FIG. 5 is a signal flow diagram for explaining a process of linking an operating server to an authentication system according to an embodiment.

[0072] Referring to FIG. 5, when the operating server (40) connects to the certificate management server (20) (S310), the certificate management server (20) responds with an API (S320). Then, the operating server (40) confirms the connection with the certificate management server (20) (S330), connects to the certificate management server (20), and completes the establishment of a secure communication session (S340).

[0073] In addition, when the operating server (40) connects to the verification server (30) (S350), the verification server (30) responds with an API (S360). Then, the operating server (40) confirms the connection with the verification server (30) (S370) and connects to the verification server (30) to complete the establishment of a secure communication session (S380).

[0074] FIG. 6 is a signal flow diagram for explaining a process of initially issuing certificates of components of a smart factory system according to an embodiment, FIG. 7 is a signal flow diagram for explaining a step of generating a hash tree according to an embodiment, and FIG. 8 is a signal flow diagram for explaining a step of matching and transmitting a certificate to a hash tree according to an embodiment.

[0075] Referring to FIG. 6, a smart factory authentication method according to an embodiment may include a step of receiving a certificate for each intermediate device and IoT device from a cloud CA through a certificate management server (S410 to S485), a step of matching the issued certificate to a hash tree (S495), and a step of transmitting the issued certificate to the corresponding device (S495).

[0076] In detail, the operating server (40) collects information on components of the smart factory system (S420) as certificate issuance begins (S410). That is, it collects information on at least one intermediate device (50) and IoT device (60).

[0077] Referring again to FIG. 6, the operation server (40) generates a certificate signing request (CSR) (S430) and transmits the certificate signing request (CSR) to the certificate management server (20) to request certificate issuance (S440).

[0078] At this time, a Certificate Signing Request (CSR) can be generated and transmitted as many times as the number N of components that constitute the smart factory system.

[0079] Then, the certificate management server (20) checks the connection status of the components that make up the smart factory system for which certificate issuance has been requested (S450) and requests the cloud CA (10) to issue N certificates (S460).

[0080] Then, the cloud CA (10) issues N certificates (S470) and transmits the issued certificates to the operation server (40) through the certificate management server (20) (S480 to S485).

[0081] At this time, the certificate information may include at least one of the following: version, serial number, Cloud CA signature, issuer (DN), expiration date, distinguished name (DN), public key, issuer ID, certificate subject unique ID, and extension field (CRL (validation server) URL).

[0082] After that, the operation server (40) can perform a hash tree generation operation (S490) based on the information collected in S420. However, in order to help understand the explanation, in Fig. 6, the hash tree generation operation (S490) is illustrated as being performed immediately before the operation of matching the hash tree to the certificate (S495), but the present invention is not limited thereto. That is, this hash tree generation operation (S490) may be performed before the start of certificate issuance, or may be performed at any point before matching the hash tree to the certificate (S495).

[0083] Referring to Fig. 7, the hash tree creation operation (S490) will be described in more detail. As hash tree creation begins (S505), the operating server (40) requests hash information from at least one intermediate device (50) connected to the lower level (S510).

[0084] Then, the intermediate device (50) checks the hash table it has (S515) and requests hash information from at least one IoT device (60) connected to the lower level (S520).

[0085] Then, each IoT device (60) generates a first hash (HASH1) based on the unique information of the IoT device (S525) and transmits the generated first hash (HASH1) to the upper connected intermediate device (50) (S530).

[0086] At this time, the unique information may include a MAC or serial number. That is, it may be "Hash1=Hash{IoT unique information (Serial number, MAC address, etc.)}".

[0087] Then, each intermediate device (50) matches the first hash (HASH1) received in its hash table with the corresponding IoT device and stores it (S535).

[0088] After that, the intermediate device (50) generates a second hash (HASH2) based on a hash table including a first hash (HASH1) matching at least one IoT device (50) connected to its subordinates (S540), and transmits the generated second hash (HASH2) to the operating server (40) (S545). That is, "Hash2=Hash(IoT1Hash, IoT2Hash, IoT3Hash,..., IoT n Hash) may be.

[0089] Then, the operating server (40) matches the received second hash (HASH2) with the corresponding intermediate device and stores it in the hash table it has (S550).

[0090] After that, the operating server (40) generates a third hash (HASH3) based on a hash table including a second hash (HASH2) matching at least one intermediate device (40) connected to its subordinates (S555). That is, "Hash3=Hash(HMI / PLC1Hash, HMI / PLC2Hash, HMI / PLC3Hash,... HMI / PLC n Hash) may be.

[0091] Here, the third hash (HASH3) can be the root hash (ROOT HASH) of the hash tree as illustrated in FIG. 2.

[0092] As described above, the generated hashes can be generated and transmitted together as a packet when transmitting data later.

[0093] Smart factories can be deployed and operated with countless devices. Therefore, even if a malicious user deploys an IoT device containing malware within a smart factory, detection is difficult. However, as described above, if a hash is generated based on a hash tree according to an embodiment, it becomes easier to detect IoT devices containing such malware. That is, since the hash of a parent device is generated based on the hash table of connected devices below it, if a device containing malware is deployed, the hash of the parent device changes, causing an error in data verification, enabling the detection of a malicious attack.

[0094] Referring again to FIG. 6, the operating server (40) can perform an operation of matching the issued certificate to a hash tree and transmitting the certificate to the corresponding device (S495).

[0095] Referring to Fig. 8, the operation of matching and transmitting a certificate issued to a hash tree (S495) will be described in more detail. The operating server (40) matches (S560) a certificate issued to an intermediate device (50) to the hash tree it possesses and stores it (S565).

[0096] After that, the operating server (40) transmits the issued certificate to at least one corresponding intermediate device (50) (S570). Then, the intermediate device (50) matches the issued certificate to the IoT device (50) of the hash tree it possesses (S575).

[0097] After that, the intermediate device (50) stores the certificate matched to the hash tree and the certificate issued to itself (S580). Then, the intermediate device (50) transmits the certificate issued to the IoT device (60) to the corresponding IoT device (60) (S585), and the IoT device (60) receives and stores the certificate issued to itself (S590).

[0098] FIG. 9 is a signal flow diagram for explaining a process of additionally issuing a certificate in response to a new device registration request according to an embodiment.

[0099] Referring to FIG. 9, the smart factory authentication method according to the embodiment may further include a step of obtaining a certificate of a new device when a new device registration request is made (S605 to S655), a step of regenerating a hash tree that additionally reflects a hash of the new device (S650), a step of re-matching a certificate to the re-generated hash tree (S665), and a step of transferring the obtained certificate to the new device (S665).

[0100] That is, when the intermediate device (50) recognizes that a new IoT device has been added within the smart factory, it requests the operation server (40) to register the new IoT device (S605).

[0101] At this time, the intermediate device (50) can receive an additional registration signal of a new IoT device being broadcasted and recognize whether a new IoT device is additionally registered.

[0102] At this time, the step of obtaining a certificate for a new device (S605 to S655) may include a step of checking whether a certificate for the new device has already been issued (S610 to S620), and if a certificate has already been issued, a step of requesting and obtaining a certificate from the new device (S625).

[0103] That is, if a new IoT device being added has already been set up within another smart factory system and has already been issued a certificate, the operation server (40) can request and obtain the already issued certificate from the device without performing a new certificate issuance procedure.

[0104] On the other hand, if a certificate for a new IoT device has not been issued, the operating server (40) can request the cloud CA (10) to issue a certificate for the new device through the certificate management server (20) (S630 to S640) and obtain a certificate newly issued by the cloud CA (10) (S645 to S655).

[0105] Next, a step (S660) of regenerating a hash tree may be performed as a new device is registered. A detailed description of this is omitted as it overlaps with the description made with reference to FIG. 7.

[0106] Additionally, a step (S670) may be performed to re-match the certificate of the new device to the re-generated hash tree and, in the case of a newly issued certificate, to transmit it to the device.

[0107] FIG. 10 is a signal flow diagram illustrating a process for revoking a certificate in response to a request for removal of a registered device according to an embodiment.

[0108] Referring to FIG. 10, the smart factory authentication method according to the embodiment may further include a step (S705 to S725) in which the operation server (40) requests the cloud CA (10) to revoke the certificate of a new device through the certificate management server (20) in response to a request for removal of a registered device, a step (S730) in which a hash of the removed device is deleted and reflected, and a step (S735) in which the certificate is re-matched to the re-created hash tree.

[0109] That is, the operating server (40) transmits a certificate revocation request to the cloud CA (10) through the certificate management server (20) (S705~710).

[0110] Then, the cloud CA (10) revokes the certificate of the requested device and updates the Certificate Revoke List (CRL) (S715).

[0111] After that, the cloud CA (10) transmits the completion of certificate revocation to the operating server through the certificate management server (20) (S725).

[0112] Next, a step (S730) of regenerating a hash tree as the existing device is removed may be performed, and a detailed description thereof will be omitted as it overlaps with that described with reference to FIG. 7.

[0113] Additionally, a step (S735) of re-matching the certificate to the re-generated hash tree may be performed.

[0114] Meanwhile, a step (S740 to S760) may be further included in which the Certificate Revoke List (CRL) is transmitted to the verification server (30) as it is updated by the cloud CA (10).

[0115] FIG. 11 is a signal flow diagram for explaining a process of verifying data transmitted using a certificate issued according to an embodiment, and FIGS. 12 and 13 are signal flow diagrams for explaining a process of verifying data and a hash transmitted using a certificate issued according to an embodiment.

[0116] Referring to FIG. 11, a smart factory authentication method according to an embodiment may include a step of verifying a certificate that signed the data (S810 to S835, S850 to S860) and a step of confirming or destroying the data according to the certificate verification result (S840, S865) as the operation server (40) receives data from an intermediate device (50) (S805, S845).

[0117] At this time, according to the first embodiment, in the step of verifying the certificate (S810 to S835), the operating server (40) can obtain a certificate revocation list (CRL) from the verification server (40) and verify the certificate.

[0118] That is, when the smart factory system becomes larger and the number of operating servers (40) increases, if the operating server (40) requests certificate verification from the verification server (30) every time, the load on the verification server (30) due to verification performance increases.

[0119] Therefore, according to the first embodiment, the operation server (40) can prevent the load on the verification server (30) from increasing by directly performing certificate verification after obtaining the Certificate Revoke List (CRL).

[0120] In detail, the operating server (40) checks the CRL caching data (S810) as it receives data from the intermediate device (50) (S805).

[0121] At this time, if there is no CRL caching data, the operating server (40) requests CLR from the verification server (30) (S815) and receives an updated CRL (S820 to S825).

[0122] After that, the operation server (40) caches the transmitted CRL, verifies the certificate that signed the transmitted data (S830 to S835), and then verifies and uses the data according to the certificate verification (S840).

[0123] On the other hand, according to the second embodiment, in the step of verifying the certificate (S850 to S860), the operating server (40) can request verification (S850) by transmitting the certificate to the verification server (30) so that it can be compared and confirmed with the certificate revocation list.

[0124] That is, if the number of operating servers (40) is not large and the load on the verification server (30) does not increase, the certificate can be verified according to this second embodiment.

[0125] Then, the verification server (30) verifies the transmitted certificate through direct CRL verification (S855) and transmits the verification result to the operation server (40) (S860).

[0126] Then, if the certificate verification is successful, the operation server (40) verifies and uses the data (not shown), and if the certificate verification is not possible, it determines that the received data was created by an IoT device with malicious code and destroys it (S865).

[0127] Meanwhile, data transmitted by the IoT device (60) can be transmitted in a state where a packet including a hash and data is signed by a certificate.

[0128] Accordingly, referring to FIG. 12, the smart factory authentication method according to the embodiment may include a step (S950) of verifying a hash transmitted with data based on the result of certificate verification (S945), a step (S955) of verifying a hash tree, and a step (S960) of verifying data based on whether the hash tree has been verified.

[0129] At this time, the data transmitted from the IoT device (60) may be a fourth hash (HASH4) generated based on the first hash (HASH1) and the data generation variable (α), and data generated from the IoT device may be signed with the IoT device's certificate.

[0130] That is, referring to FIG. 12, the IoT device (60) prepares to transmit the collected data (S905) and generates a first hash (HASH1) (S910). Then, based on the first hash (HASH1) and the data generation variable (α), a fourth hash (HASH4) is generated (S915). That is, 'HASH4=HASH(HASH1, α)' may be true.

[0131] After that, the IoT device (60) signs a packet consisting of HASH4 and data with a certificate and transmits it to the intermediate device (S920).

[0132] Then, the intermediate device (50) verifies the fourth hash (HASH4) based on the first hash and data generation variable (α) previously stored (S925). That is, the fourth hash can be verified by re-encoding the first hash and data generation variable (α) previously stored in the hash tree.

[0133] In another embodiment, when transmitting a packet composed of a first hash (HASH1) and data from an IoT device (60) in consideration of an increase in network load, the intermediate device (50) can verify the first hash (HASH1) by examining the hash tree.

[0134] Additionally, the data transmitted from the intermediate device (50) may be a fifth hash (HASH5) generated based on the second hash (HASH2) and the data generation variable (α), and the data received by the intermediate device (50) from the IoT device (60) may be signed with the intermediate device's certificate.

[0135] That is, referring to FIG. 12, the intermediate device (50) generates a fifth hash (HASH5) based on the second hash (HASH2) and the data generation variable (α) (S930). That is, 'HASH5=HASH(HASH2, α)' may be true.

[0136] After that, the intermediate device (50) signs a packet consisting of HASH5 and data with a certificate (S935) and transmits it to the operating server (40) (S940).

[0137] Then, the operating server (40) verifies the certificate that signed the transmitted data (S945).

[0138] Thereafter, the operating server (40) verifies the fifth hash (HASH5) based on the previously stored second hash and data generation variable (α) (S950). That is, the fifth hash can be verified by re-encoding the second hash and data generation variable (α) previously stored in the hash tree.

[0139] In another embodiment, when a packet consisting of a second hash (HASH2) and data is transmitted from an intermediate device (50) in consideration of an increase in network load, the operating server (40) can verify the second hash (HASH2) by examining the hash tree.

[0140] In addition, the operation server (40) requests a hash from nodes other than the node that received the data in order to verify the hash tree of the intermediate device (50) (S955), and after hashing the received hashes to create a root hash, verification can be performed on the node that received the data.

[0141] When the verification procedure described above is completed and authentication is successful, the operating server (40) verifies and stores IoT data (S960).

[0142] As mentioned above, when transmitting data, a newly generated hash is used using the hash already stored in the hash tree and the data generation variable (α). This prevents malicious users from leaking the hash tree if it remains unchanged for an extended period of time. In other words, by modifying the hash once more in this manner, even if a malicious user hijacks the hash tree and collects data, the source of the IoT cannot be identified.

[0143] At this time, the data generation variable (α) is a one-time variable generated by each of the IoT device (60) and the intermediate device (50), and may be a value that can be confirmed by the upper connected device, i.e., the intermediate device (50) and the operating server (60).

[0144] For example, the data generation variable (α) may be generated as an OTP or may be generated as a value converted from data to a number.

[0145] That is, as illustrated in Fig. 13, an index having randomness is shared between the intermediate device (50) and the IoT device (60). In addition, the randomness index can be used to digitize data to be transmitted from the IoT device (60) to form a data generation variable (α).

[0146] At this time, according to the embodiment, the data generation variable (α) used to generate the fourth hash (HASH4) to transmit the data (DATA) collected from the IoT device (60) and the data generation variable (α) used to generate the fifth hash (HASH5) to transmit the same data (DATA) received from the IoT device (60) by the intermediate device (50) may be the same.

[0147] That is, the length of data to be transmitted from the IoT device (60) is derived as the value of the data generation variable (α), and the fourth hash (HASH4) is generated using the data generation variable (α) derived in this manner, and the data and the fourth hash (HASH4) are transmitted to the intermediate device (50). Then, the intermediate device (50) derives the length of data transmitted from the IoT device (60) as the value of the data generation variable (α), and the fifth hash (HASH5) is generated using the data generation variable (α) derived in this manner, and the data and the fifth hash (HASH5) are transmitted to the operating server (40).

[0148] Fig. 14 is a diagram showing a computer system configuration according to an embodiment.

[0149] According to an embodiment, at least one of a cloud CA (10), a certificate management server (20), a verification server (30), an operation server (40), an intermediate device (50), and an IoT device (60) may be implemented in a computer system (1000) such as a computer-readable recording medium.

[0150] The computer system (1000) may include one or more processors (1010), memory (1030), user interface input devices (1040), user interface output devices (1050), and storage (1060) that communicate with each other via a bus (1020). In addition, the computer system (1000) may further include a network interface (1070) connected to a network (1080). The processor (1010) may be a central processing unit or a semiconductor device that executes programs or processing instructions stored in the memory (1030) or storage (1060). The memory (1030) and storage (1060) may be storage media that include at least one of a volatile medium, a nonvolatile medium, a removable medium, a non-removable medium, a communication medium, or an information transmission medium. For example, the memory (1030) may include a ROM (1031) or a RAM (1032).

[0151] Although embodiments of the present invention have been described above with reference to the attached drawings, those skilled in the art will appreciate that the present invention can be implemented in other specific forms without altering the technical concept or essential features thereof. Therefore, the embodiments described above should be understood to be illustrative in all respects and not restrictive.

Claims

1. Memory in which at least one program is recorded; and Includes a processor that executes a program, The program is, For each intermediate device and IoT device, a certificate is issued from the cloud CA through the certificate management server, the issued certificate is matched to the hash tree, and the issued certificate is delivered to the corresponding device. Hash tree, A smart factory authentication device in which each hash is configured in a hierarchical form to correspond to the connection configuration of the operating server, intermediate device, and IoT device.

2. In the first paragraph, the hash tree, A first hash generated based on the unique information of the IoT device; A second hash generated based on a hash table including a first hash matching at least one IoT device connected to a lower level of the intermediate device; and A smart factory authentication device comprising a third hash generated based on a hash table including a second hash matching at least one intermediate device connected to a lower level of the operation server.

3. In paragraph 2, the unique information is, Smart factory authentication device containing MAC or serial number.

4. In paragraph 2, the program, A smart factory authentication device that obtains a certificate for a new device upon a new device registration request, regenerates a hash tree that additionally reflects the hash of the new device, rematches the certificate to the regenerated hash tree, and transfers the obtained certificate to the new device.

5. In paragraph 2, the program, A smart factory authentication device that, when obtaining a certificate for a new device, checks whether a certificate for the new device has already been issued, and if so, requests and obtains a certificate from the new device, and if not so issued, requests and obtains a certificate for the new device from the certificate management server.

6. In paragraph 2, the program, A smart factory authentication device that requests the cloud CA to revoke the certificate of a new device through a certificate management server upon a request to remove a registered device, regenerates a hash tree reflecting the deleted hash of the removed device, and rematches the certificate to the regenerated hash tree.

7. In paragraph 2, the program, A smart factory authentication device that verifies the certificate that signed the data upon receiving data from an intermediate device, verifies the hash transmitted with the data based on the certificate verification result, verifies the hash tree, and confirms or discards the data based on whether the hash tree has been verified.

8. In paragraph 7, the program, When verifying a certificate, Verify the certificate by obtaining the Certificate Revoke List (CRL) from the verification server, or Request verification by sending the certificate to the verification server and comparing it with the certificate revocation list. The Certificate Revoke List (CRL) is Smart factory authentication device that is delivered to the verification server as it is updated by the cloud CA.

9. In paragraph 7, data received from the intermediate device is The fifth hash is generated based on the second hash and the first data generation variable, and the data received by the intermediate device from the IoT device is signed with the intermediate device's certificate. Data received from IoT devices is A smart factory authentication device, wherein a fourth hash is generated based on the first hash and second data generation variables, and data generated from the IoT device is signed with the IoT device's certificate.

10. In paragraph 9, the program, In verifying the hash, the fifth hash is verified based on the second hash and the first data generation variable of the previously stored intermediate device, The fourth hash is, A smart factory authentication device that is verified based on a first hash and a second data generation variable stored by an intermediate device.

11. Step of receiving a certificate for each intermediate device and IoT device from the cloud CA through the certificate management server; A step of matching the issued certificate to the hash tree; and Including the step of transmitting the issued certificate to the device, Hash tree, A smart factory authentication method in which each hash is configured in a hierarchical form to correspond to the connection configuration of the operating server, intermediate device, and IoT device.

12. In the 11th paragraph, the hash tree, A first hash generated based on the unique information of the IoT device; A second hash generated based on a hash table including a first hash matching at least one IoT device connected to a lower level of the intermediate device; and A smart factory authentication method comprising a third hash generated based on a hash table including a second hash matching at least one intermediate device connected to a lower level of the operation server.

13. In paragraph 12, the unique information is: Smart factory authentication method including MAC or serial number.

14. In paragraph 12, Steps to obtain a certificate for a new device upon request for new device registration; A step to regenerate the hash tree by additionally reflecting the hash of the new device; A step of re-matching the certificate to the re-generated hash tree; and A smart factory authentication method further comprising a step of transferring the acquired certificate to a new device.

15. In paragraph 12, the step of obtaining a certificate for a new device is: Step to check whether a certificate has been issued for a new device; If already issued, a step of requesting and obtaining a certificate from a new device; and A smart factory authentication method, comprising a step of requesting and obtaining a certificate for a new device from a certificate management server if the certificate has not been issued yet.

16. In paragraph 12, Step of requesting the cloud CA to revoke the certificate of the new device through the certificate management server upon requesting the removal of the registered device; A step of regenerating a hash tree that reflects the deletion of the hash of the removed device; and A smart factory authentication method further comprising a step of re-matching a certificate to a re-generated hash tree.

17. A step of verifying the certificate that signed the data as data is received from the intermediate device; A step of verifying the hash transmitted along with the data based on the certificate verification result; Step of verifying the hash tree; and Including a step of verifying or discarding data depending on whether the hash tree has been verified; Hash tree, A smart factory authentication method in which each hash is configured in a hierarchical form to correspond to the connection configuration of the operating server, intermediate device, and IoT device.

18. In paragraph 17, the step of verifying the certificate is: Verify the certificate by obtaining the Certificate Revoke List (CRL) from the verification server, or Request verification by sending the certificate to the verification server and comparing it with the certificate revocation list. The Certificate Revoke List (CRL) is A smart factory authentication method that is delivered to the verification server as it is updated by the cloud CA.

19. In paragraph 17, the hash tree, A first hash generated based on the unique information of the IoT device; A second hash generated based on a hash table including a first hash matching at least one IoT device connected to a lower level of the intermediate device; and A third hash generated based on a hash table that includes a second hash that matches at least one intermediate device connected to the lower level of the operating server, Data received from the intermediate device is The fifth hash is generated based on the second hash and the first data generation variable, and the data received by the intermediate device from the IoT device is signed with the intermediate device's certificate. Data received from IoT devices is A smart factory authentication method wherein a fourth hash is generated based on a first hash and a second data generation variable, and data generated from an IoT device is signed with a certificate of the IoT device.

20. In paragraph 19, the step of verifying the hash is: Verify the fifth hash based on the second hash and the first data generation variable of the previously stored intermediate device, The fourth hash is, A smart factory authentication method, which is verified based on a first hash and a second data generation variable stored by an intermediate device.

Images