Authentication system, authentication method, and authentication program

Abstract

A firmware generation device (10) comprises a firmware generation unit (15b) that generates common device firmware to be used for challenge–response authentication by writing a predetermined random number and index information indicating a region subject to hash calculation into a vacant region of firmware.

Description

[Technical field]

[0001] The present invention relates to an authentication system, a generation device, a generation method, and a generation program. [Background technology]

[0002] Malware (such as Mirai) is invading not only ICT (Information and Communication Technology) devices such as PCs (Personal Computers) but also IoT (Internet of Things) devices that do not have hardware such as secure elements, causing widespread damage such as making these devices join botnets. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] Sarita Agrawal, Manik Lal Das, Javier Lopez, "Detection of Node Capture Attack in Wireless Sensor Networks", IEEE SYSTEMS JOURNAL, VOL. 13, MARCH 2019<https: / / ieeexplore.ieee.org / document / <8444374> Summary of the Invention [Problem to be solved by the invention]

[0004] However, conventional technologies cannot effectively verify the integrity of IoT devices because, while a physical root of trust such as a security chip is generally used to ensure the security of ICT devices, dedicated devices such as IoT devices and communication devices often do not implement a physical root of trust.

[0005] In addition, in the prior art, when a physical trust base point is not implemented, it is necessary to generate individual firmware incorporating different random numbers for each device, so the same firmware cannot be used for the same model. Further, in the above technology, even in an IoT gateway, it is necessary to manage different firmware data for each device to be subject to integrity verification, and as the number of devices increases, the amount of data to be managed by the IoT gateway becomes large. Further, in the above technology, since the hash value of the entire memory image is taken, devices having variable parts in the memory are excluded from the target.

[0006] The present invention has been made in view of the above, and an object thereof is to provide an authentication system, a generation device, a generation method, and a generation program that enable effective integrity verification of IoT devices.

Means for Solving the Problems

[0007] In order to solve the above-described problems and achieve the object, an authentication system according to the present invention is an authentication system including a generation device that generates firmware, a verification device that executes integrity verification, and a proof device that executes integrity proof, wherein the generation device writes a predetermined random number and index information indicating an area to be subject to hash calculation into an empty area of the firmware, thereby generating a model-common firmware used for challenge-response authentication, and has a firmware generation unit, the verification device has a challenge generation unit that generates a challenge to the proof device based on the model-common firmware held by the verification device, and the proof device has a response generation unit that generates a response to the verification device based on the model-common firmware held by the proof device.

[0008] In order to solve the above-described problems and achieve the object, a generation device according to the present invention is characterized by having a firmware generation unit that generates model-common firmware used for challenge-response authentication by writing a predetermined random number and index information indicating an area to be subject to hash calculation into an empty area of the firmware.

[0009] Further, the generation method according to the present invention is a generation method executed by a generation device, and includes a firmware generation step of generating model-common firmware used for challenge-response authentication by writing a predetermined random number and index information indicating an area to be subjected to hash calculation into an empty area of the firmware.

[0010] Further, the generation program according to the present invention causes a computer to execute a firmware generation procedure of generating model-common firmware used for challenge-response authentication by writing a predetermined random number and index information indicating an area to be subjected to hash calculation into an empty area of the firmware.

Advantages of the Invention

[0011] In the present invention, effective integrity confirmation of IoT devices is enabled using model-common firmware.

Brief Description of the Drawings

[0012]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

[0013] Embodiments of a firmware generation device (generation device), a firmware generation method (generation method), and a firmware generation program (generation program) according to the present invention will be described in detail below with reference to the drawings. Note that the present invention is not limited to the embodiments described below.

[0014] First Embodiment The configuration of the authentication system 100 according to the first embodiment, the configuration of each device of the authentication system 100, specific examples of each process, and the flow of the authentication process will be described in order below, and finally the effects of the first embodiment will be described.

[0015] (1. Configuration of Authentication System 100) The configuration of the authentication system 100 according to the first embodiment will be described in detail with reference to FIG. 1. FIG. 1 is a diagram showing a configuration example of the authentication system according to the first embodiment. The configuration example of the entire authentication system 100 will be shown below, and then each process will be described.

[0016] (1-1. Configuration Example of Entire Authentication System 100) As shown in FIG. 1, the authentication system 100 includes a firmware generation device 10, a verification device 20 such as an IoT gateway, a certification device 30 such as an IoT device (hereinafter simply referred to as a "device" as appropriate), and a user business operator terminal 40. Here, the firmware generation device 10, the verification device 20, the certification device 30, and the user business operator terminal 40 are communicably connected by wire or wirelessly via a predetermined communication network (not shown). Note that the authentication system 100 shown in FIG. 1 may include a plurality of firmware generation devices 10, a plurality of verification devices 20, a plurality of certification devices 30, or a plurality of user business operator terminals 40.

[0017] (1-1-1. Firmware Generation Device 10) The firmware generation device 10 is a device (computer) that generates firmware, which is a program to be installed in a certification device 30 such as an IoT device. The firmware generation device 10 accepts operations by an administrator of the firmware generation device 10 such as a device manufacturer M. Note that the firmware generation device 10 is realized by, for example, a dedicated machine for manufacturing IoT devices, a server device, a desktop PC, or the like. In the example of FIG. 1, a case where the firmware generation device 10 is realized by a server device is shown.

[0018] (1-1-2. Verification Device 20) The verification device 20 is a device (computer) that verifies the integrity of an IoT device. The verification device 20 also has an integrity confirmation program (verifier) that checks whether the memory information of an IoT device or the like has been tampered with. In the example of FIG. 1, a case where the verification device 20 is realized by an IoT gateway is shown.

[0019] (1-1-3. Certification Device 30) The certification device 30 is a device (computer) that proves completeness, and is a small information device manufactured by a device manufacturer M or the like on the premise of connection to the Internet. The certification device 30 has unique information (such as a MAC (Media Access Control) address and a device serial number) for uniquely identifying an IoT device or the like. Further, the certification device 30 has a completeness confirmation program (certifier) for confirming whether the memory information of an IoT device or the like has been tampered with. In the example of FIG. 1, the case where the certification device 30 is realized by an IoT device such as a camera is shown.

[0020] (1-1-4. User Business Operator Terminal 40) The user business operator terminal 40 is a device (computer) that updates the firmware of the certification device 30 or registers the firmware in the verification device 20. It is a terminal used by a user business operator (hereinafter simply referred to as "user") U. The user business operator terminal 40 is realized by, for example, a smartphone, a tablet terminal, a notebook PC (Personal Computer), a desktop PC, a mobile phone, a PDA (Personal Digital Assistant), or the like. In the example of FIG. 1, the case where the user business operator terminal 40 is realized by a desktop PC is shown.

[0021] (1-2. Processing of the Authentication System 100) Hereinafter, as the processing of the authentication system 100, firmware generation processing (step S1), firmware update / registration processing (steps S2 to S4), official registration processing (steps S5 to S6), challenge transmission processing (steps S7 to S8), and response transmission processing (steps S9 to S10) will be described. Note that the following steps S1 to S10 can also be executed in a different order. Also, some of the following steps S1 to S10 may be omitted.

[0022] (1-2-1. Firmware Generation Processing) First, the firmware generation device 10 generates firmware (model-common firmware) for challenge response authentication by writing a random number (hereinafter, "predetermined random number") generated by a predetermined procedure and index information into the free area of the firmware (step S1). The details of the firmware generation process will be described later in [3. Specific examples of each process of the authentication system 100] (3-2. Hash calculation process).

[0023] (1-2-2. Firmware update / registration process) Next, the user business operator terminal 40 acquires the firmware of the proof device 30 generated by the firmware generation device 10 (step S2). Then, the user business operator terminal 40 executes an update (firmware upgrade) of the proof device 30 such as an IoT device (step S3). Also, the user business operator terminal 40 uses the firmware generated by the firmware generation device 10 to execute firmware registration for the verification device 20 such as an IoT gateway (step S4). The details of the firmware update / registration process will be described later in [3. Specific examples of each process of the authentication system 100] (3-4. Authentication process) (3-4-2. Specific example of device registration).

[0024] (1-2-3. Formal registration process) Subsequently, the proof device 30 executes a formal registration request for devices and the like to the verification device 20 such as an IoT gateway (step S5). Also, the verification device 20 executes formal registration of devices and the like (step S6). The details of the formal registration process will be described later in [3. Specific examples of each process of the authentication system 100] (3-4. Authentication process) (3-4-2. Specific example of device registration).

[0025] (1-2-4. Challenge transmission process) Then, the verification device 20 executes the generation of challenges based on the model - common firmware held by the verification device 20 (step S7). Also, the verification device 20 executes the transmission of the generated challenges to the proof device 30 in order to verify the integrity of IoT devices and the like (step S8). Note that the details of the formal registration process will be described later in [3. Specific Examples of Each Process of the Authentication System 100] (3 - 4. Authentication Process) (3 - 4 - 3. Specific Example of Integrity Confirmation).

[0026] (1 - 2 - 5. Response Transmission Process) Then, the proof device 30 executes the generation of responses based on the model - common firmware held by the proof device 30 (step S9). Also, the proof device 30 executes the transmission of the generated responses to the verification device 20 in order to prove the integrity of IoT devices and the like (step S10). Note that the details of the formal registration process will be described later in [3. Specific Examples of Each Process of the Authentication System 100] (3 - 4. Authentication Process) (3 - 4 - 3. Specific Example of Integrity Confirmation).

[0027] (1 - 3. Effects of the Authentication System 100) Hereinafter, after explaining the problems of TPIV (Trusted platform module enabled Program Integrity Verification) as a reference technology, the effects of the authentication system 100 will be described in detail.

[0028] (1 - 3 - 1. Problems) First, TPIV as the prior art will be described. The technology using TPIV prevents malware from lurking in the free space by filling the free space of the firmware with random data that is difficult to compress. Also, the above technology uses the hash value of the entire firmware embedded with random numbers as a common key for information sharing between an IoT gateway (verification device) and an IoT device (certification device). At this time, the following two advantages are expected by using the said firmware. As the first advantage, in the above technology, by using the said firmware, it becomes possible to prevent spoofing at the time of initial registration. That is, the said firmware can be used as a unique ID for the target device by the IoT gateway to confirm the authenticity. As the second advantage, in the above technology, by using the said firmware, it becomes possible to prevent forgery. That is, the said firmware can be used as data to be the target of hash calculation for integrity confirmation.

[0029] However, the above technology using TPIV has the following three problems. As the first problem, in the above technology, since it is necessary to generate individual firmware embedded with different random numbers for each device, the same firmware cannot be used for the same model. As the second problem, in the above technology, even in the IoT gateway, it is necessary to manage different firmware data for each device that is the target of integrity confirmation, and as the number of devices increases, the data to be managed by the IoT gateway becomes a large amount. As the third problem, in the above technology, since the hash value of the entire memory image is taken, devices with variable parts in the memory are excluded from the target.

[0030] (1-3-2. Overview) In the authentication system 100, the firmware generation device 10 generates model-common firmware for challenge-response authentication by writing a predetermined random number and index information indicating an area to be subjected to hash calculation into an empty area of the firmware. The verification device 20 that executes integrity verification generates a challenge for the proof device 30 based on the model-common firmware held by the verification device 20. The proof device 30 that executes integrity proof generates a response for the verification device 20 based on the model-common firmware installed in the proof device 30.

[0031] Also, in the authentication system 100, the firmware generation device 10 generates a predetermined random number common to each model of the proof device 30 and index information including the start address and size of the memory area to be subjected to hash calculation, and generates model-common firmware by writing the predetermined random number and the index information into an empty area of the firmware. Further, the verification device 20 reads target data for hash calculation using the index information included in the model-common firmware held by the verification device 20, executes hash calculation using the unique information of the proof device 30 and the target data, and generates a challenge. Also, the proof device 30 reads target data for hash calculation using the index information included in the model-common firmware possessed by the proof device 30, executes hash calculation using the unique information of the proof device 30 and the target data, and generates a response.

[0032] (1-3-3. Effect) Therefore, the authentication system 100 contributes to solving the problems of the above-described technology using TPIV. That is, with respect to the first problem, in the authentication system 100, by using a common random number for the same model, it is not necessary for the device manufacturer to create different firmware for each device. Also, with respect to the second problem, in the authentication system 100, since the random numbers are common for the same model, by sharing the same firmware data, the amount of data managed by the IoT gateway is reduced. Further, with respect to the third problem, in the authentication system 100, by excluding variable data from the object of hashing by including index information indicating the memory range used for hashing in the firmware of the device, devices with variable parts in the memory can also be made subject to integrity verification.

[0033] From the above, in the authentication system 100, even for devices without a physical trust basis such as a secure element, it is possible to perform integrity verification as software, and it is possible to achieve "expansion of target devices" in which security functions can be added at low cost. Also, in an actual device manufacturing site, it is difficult to incorporate and distribute management of different software for each individual device from the perspective of cost and operation. Therefore, it is possible to achieve "lowering the introduction barrier" so that the same software can be used for the same model at the manufacturing stage. That is, the authentication system 100 is a system that performs integrity verification of IoT devices using firmware common to the model, enabling effective integrity verification of IoT devices.

[0034] [2. Configuration of Each Device of Authentication System 100] Using FIGS. 2 to 4, a configuration example of the firmware generation device 10, the verification device 20, and the certification device 30 according to the first embodiment will be described in detail. FIG. 2 is a block diagram showing a configuration example of the firmware generation device 10 according to the first embodiment. FIG. 3 is a block diagram showing a configuration example of the verification device 20 according to the first embodiment. FIG. 4 is a block diagram showing a configuration example of the certification device 30 according to the first embodiment.

[0035] (2-1. Configuration Example of Firmware Generation Device 10) Using FIG. 2, a configuration example of the firmware generation device 10 according to the first embodiment will be described in detail. The firmware generation device 10 includes a communication unit 11, an input unit 12, an output unit 13, a storage unit 14, and a control unit 15. Note that the firmware generation device 10 may be configured not to include the input unit 12 or the output unit 13.

[0036] (2-1-1. Communication Unit 11) The communication unit 11 is realized by, for example, a NIC (Network Interface Card) or the like. Then, the communication unit 11 is connected to a predetermined communication network (network) by wire or wirelessly, and transmits and receives information to and from various devices.

[0037] (2-1-2. Input Unit 12) The input unit 12 is realized by, for example, a keyboard, a mouse, or the like. Then, the input unit 12 receives various operations from the administrator or the like of the firmware generation device 10.

[0038] (2-1-3. Output Unit 13) The output unit 13 is realized by, for example, a liquid crystal display or the like. Then, the output unit 13 displays various information.

[0039] (2-1-4. Storage Unit 14) The storage unit 14 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk. Then, the storage unit 14 stores various information referred to when the control unit 15 operates and various information acquired when the control unit 15 operates.

[0040] (2-1-5. Control Unit 15) The control unit 15 controls the entire firmware generation device 10. The control unit 15 includes a reception unit 15a, a firmware generation unit 15b, and a transmission unit 15c. Here, the control unit 15 is an electronic circuit such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), or an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).

[0041] (2-1-5-1. Reception Unit 15a) The reception unit 15a receives various types of information related to the firmware. For example, the reception unit 15a receives a firmware download request from the user U who is the administrator of the authentication system 100.

[0042] (2-1-5-2. Firmware Generation Unit 15b) The firmware generation unit 15b generates model-common firmware for challenge-response authentication by writing a predetermined random number and index information indicating the area to be hashed into the free area of the firmware. For example, the firmware generation unit 15b generates the random number common to each model of the proof device and the index information including the start address and size of the memory area to be hashed, and writes the random number and the index information into the free area to generate the model-common firmware.

[0043] On the other hand, the firmware generation unit 15b stores the generated model-common firmware in the storage unit 14.

[0044] (2-1-5-3. Transmission Unit 15c) The transmission unit 15c transmits various types of information related to the firmware. For example, the transmission unit 15c transmits the generated firmware in response to a firmware download request from the user U who is the administrator of the authentication system 100.

[0045] (Configuration example of verification device 20) Using FIG. 3, a configuration example of the verification device 20 according to the first embodiment will be described in detail. The verification device 20 includes a communication unit 21, an input unit 22, an output unit 23, a storage unit 24, and a control unit 25. Note that the verification device 20 may be configured not to include the input unit 22 or the output unit 23.

[0046] (2-2-1. Communication unit 21) The communication unit 21 is realized by, for example, a NIC or the like. Then, the communication unit 21 is connected to a predetermined communication network (network) by wire or wirelessly, and transmits and receives information to and from various devices.

[0047] (2-2-2. Input unit 22) The input unit 22 is realized by, for example, a keyboard, a mouse, or the like. Then, the input unit 22 receives various operations from an administrator or the like of the verification device 20.

[0048] (2-2-3. Output unit 23) The output unit 23 is realized by, for example, a liquid crystal display or the like. Then, the output unit 23 displays various information.

[0049] (2-2-4. Storage unit 24) The storage unit 24 is realized by, for example, a semiconductor memory element such as a RAM or a flash memory, or a storage device such as a hard disk or an optical disk. Then, the storage unit 24 stores various information referred to when the control unit 25 operates and various information acquired when the control unit 25 operates.

[0050] (2-2-5. Control unit 25) The control unit 25 controls the entire verification device 20. The control unit 25 includes a reception unit 25a, a challenge generation unit 25b, and a transmission unit 25c. Here, the control unit 25 is, for example, an electronic circuit such as a CPU or an MPU, or an integrated circuit such as an ASIC or an FPGA.

[0051] (2-2-5-1. Reception unit 25a) The receiving unit 25a receives various types of information. For example, the receiving unit 25a receives the model-common firmware and the unique information of the certification device 30, and stores them in the storage unit 24. Also, the receiving unit 25a receives a registration request and a response from the certification device 30.

[0052] (2-2-5-2. Challenge Generation Unit 25b) The challenge generation unit 25b generates a challenge for the certification device 30 based on the model-common firmware held by the verification device 20. For example, the challenge generation unit 25b reads out the target data for hash calculation using the index information included in the model-common firmware held by the verification device 20, executes hash calculation using the unique information of the certification device 30 and the target data for hash calculation, and the challenge generation unit 25b generates a challenge.

[0053] (2-2-5-3. Transmission Unit 25c) The transmission unit 25c transmits various types of information. For example, the transmission unit 25c transmits the generated challenge to the certification device 30.

[0054] (2-2-5-4. Response Verification Unit 25d) The response verification unit 25d verifies the response received from the certification device 30. For example, the response verification unit 25d verifies the response in the manner described in [3. Specific Examples of Each Process of the Authentication System 100] (3-1. Integrity Confirmation Process) (3-1-6. Integrity Confirmation Process of the IoT Gateway) to be described later.

[0055] (2-3. Configuration Example of the Certification Device 30) Using FIG. 4, a configuration example of the certification device 30 according to the first embodiment will be described in detail. The certification device 30 includes a communication unit 31, an input unit 32, an output unit 33, a storage unit 34, and a control unit 35. Note that the certification device 30 may be configured not to include the input unit 32 or the output unit 33.

[0056] (2-3-1. Communication Unit 31) The communication unit 31 is realized by, for example, a NIC or the like. The communication unit 31 is connected to a predetermined communication network (network) by wire or wirelessly, and transmits and receives information to and from various devices.

[0057] (2-3-2. Input unit 32) The input unit 32 is realized by, for example, a keyboard, a mouse, or the like. The input unit 32 receives various operations from the administrator or the like of the authentication device 30.

[0058] (2-3-3. Output unit 33) The output unit 33 is realized by, for example, a liquid crystal display or the like. The output unit 33 displays various information.

[0059] (2-3-4. Storage unit 34) The storage unit 34 is realized by, for example, a semiconductor memory element such as a RAM or a flash memory, or a storage device such as a hard disk or an optical disk. The storage unit 34 stores various information referred to when the control unit 35 operates and various information acquired when the control unit 35 operates.

[0060] (2-3-5. Control unit 35) The control unit 35 controls the entire authentication device 30. The control unit 35 includes a reception unit 35a, a response generation unit 35b, and a transmission unit 35c. Here, the control unit 35 is, for example, an electronic circuit such as a CPU or an MPU, or an integrated circuit such as an ASIC or an FPGA.

[0061] (2-3-5-1. Reception unit 35a) The reception unit 35a receives various information. For example, the reception unit 35a receives the model-common firmware. The reception unit 35a also receives a challenge from the verification device 20.

[0062] (2-3-5-2. Response generation unit 35b) The response generation unit 35b generates a response to the verification device 20 based on the model-common firmware held by the certification device 30. For example, the response generation unit 35b reads out the data to be hashed using the index information included in the model-common firmware installed in the certification device 30, executes hash calculation using the unique information of the certification device 30 and the data to be hashed, and generates a response to the verification device 20.

[0063] (2-3-5-3. Transmission unit 35c) The transmission unit 35c transmits various information. For example, the transmission unit 35c transmits a registration request and the generated response to the verification device 20.

[0064] [3. Specific examples of each process of the authentication system 100] Using FIGS. 5 to 11, specific examples of each process of the authentication system 100 according to the first embodiment will be described. Hereinafter, the integrity confirmation process, the hash calculation process, the communication network, and the authentication process will be described in this order.

[0065] (3-1. Integrity confirmation process) Using FIG. 5, a specific example of the integrity confirmation process of the authentication system 100 will be described. FIG. 5 is a diagram showing an example of integrity confirmation according to the first embodiment. Hereinafter, a specific example in which the IoT gateway (cluster head V) is adopted as the verification device 20 and the IoT device (node A) is adopted as the certification device 30 will be described. Also, hereinafter, CH V is the ID of the cluster head V, ID A is the ID of the node A, N v is the nonce generated by the cluster head V, P A is the data to be hashed by the node A, U A is the unique information of the node A, K A is P A and U A is the hash value of the combined data of, and PRF is a pseudo-random function (Pseudo-Random Function).

[0066] (3-1-1. Challenge Generation Process of IoT Gateway) First, if K is not set, the IoT gateway extracts P from the firmware data of Node A. Anew At this time, if the IoT gateway fails, it terminates as an illegal cluster head (see Fig. 5(1)). Next, if K is set, the IoT gateway sets K as K. A At this time, if K is not set, the IoT gateway combines P and U to calculate K (see Fig. 5(2)). Subsequently, the IoT gateway generates a disposable random number N (see Fig. 5(3)). Also, the IoT gateway encrypts N with K (see Fig. 5(4)). Then, the IoT gateway calculates the PRF of {N, ID, CH} using K as the key (see Fig. 5(5)). Anew If K is set Anew Set K as K A At this time, if K is not set Anew P A And U A To combine and calculate K A (See Fig. 5(2)). Subsequently, the IoT gateway generates a disposable random number N v (See Fig. 5(3)). Also, the IoT gateway encrypts N with K v (See Fig. 5(4)). Then, the IoT gateway calculates the PRF of {N A , ID A , CH v} using K as the key A (See Fig. 5(5)). V}

[0067] (3-1-2. Challenge Sending Process of IoT Gateway) The IoT gateway sends, as a challenge, ID A , CH V , the encrypted N v , and the PRF of {N A , ID v , CH A} calculated using K as the key V (See Fig. 5(6)).

[0068] (3-1-3. Response Generation Process 1 of IoT Device) First, if K is set, the IoT device sets K as K Anew At this time, if K is not set Anew Set K as K A At this time, if K is not set, the IoT device extracts P from the memory data of Node A Anew ​A Extract P A and U A Combine them to calculate K A (see Fig. 5(7)). Next, the IoT device decrypts the encrypted N v in the challenge using K A to extract N v (see Fig. 5(8)). Then, the IoT device uses K A as the key to calculate the PRF of {N v , ID A , CH V} and compare it with the challenge value. At this time, if there is a mismatch, the IoT device determines that the request is from an unauthorized cluster head (see Fig. 5(9)).

[0069] (3-1-4. IoT Device Response Generation Process 2) Subsequently, the IoT device calculates the hash of {P A , N v , ID A , CH V} and sets it as K Anew (see Fig. 5(10)). Also, the IoT device uses K Anew as the key to calculate the PRF of {ID A , CH V} (see Fig. 5(11)). Then, the IoT device uses K A as the key to calculate the PRF of N v (see Fig. 5(12)).

[0070] (3-1-5. IoT Device Response Sending Process) The IoT device sends, as the response, ID A 、CH V 、 the PRF of N A calculated using K v as the key, and the PRF of {ID Anew , CH A} calculated using K V as the key (see Fig. 5(13)).

[0071] (3-1-6. IoT Gateway Integrity Verification Process) The IoT gateway uses K A as a key to calculate the PRF of N v and compare it with the response value (see Fig. 5(14)). Also, {P A , N v , ID A , CH V} is hashed to obtain K Anew (see Fig. 5(15)). Finally, using K Anew as a key, the PRF of {ID A , CH V} is calculated and compared with the response value (see Fig. 5(16)). The integrity check is successful when both the PRF of N A calculated using K v and the PRF of {ID Anew , CH A , CH V} calculated using K

[0072] (3-2. Hash Calculation Process) Using Fig. 6, a specific example of the hash calculation process of the authentication system 100 will be described. Fig. 6 is a diagram showing an example of hash calculation according to the first embodiment. Hereinafter, after explaining the calculation method of hash calculation, the specification of the hash calculation target will be explained.

[0073] (3-2-1. Calculation Method of Hash Calculation) Hereinafter, the calculation method of hash calculation according to the first embodiment will be explained in the order of the firmware generation device 10, the IoT gateway which is the verification device 20, and the IoT device which is the certification device 30.

[0074] (3-2-1-1. Calculation Method of the Firmware Generation Device 10) The firmware generation device 10 fills the free area of the firmware with random numbers (process A1). At this time, since it is operationally difficult to input different random number values for each device, a common random number is used for the same model. Also, the firmware generation device 10 includes index information indicating the memory range used for hash creation in the firmware (process A2).

[0075] (3-2-1-2. Calculation Method of IoT Gateway) The IoT gateway registers the firmware of the IoT device to be connected in advance (Process B1). Next, when a registration request comes from the IoT device, the IoT gateway accesses the index information in the firmware to grasp the range of data to be hashed (Process B2). At this time, the position of the index information itself is described in the integrity confirmation program (verifier). Subsequently, the IoT gateway accesses the file position to be hashed based on the data range obtained in Process B2 to acquire the data (Process B3). Then, the IoT gateway adds the unique information of the device (such as MAC address and device serial number) to the data obtained in Process B3 and calculates the hash (Process B4).

[0076] (3-2-1-3. Calculation Method of IoT Device) When the IoT device receives a challenge from the IoT gateway, it accesses the index information in the memory to grasp the range of the memory to be hashed (Process C1). At this time, the position of the index information itself is described in the integrity confirmation program (prover). Next, the IoT device accesses the memory area to be hashed based on the memory range obtained in Process C1 to acquire the data (Process C2). Then, the IoT device adds the unique information of the device (such as MAC address and device serial number) to the data obtained in Process C2 and calculates the hash (Process C3).

[0077] (3-2-2. Identification of Hash Calculation Target) In the following, regarding the identification of the hash calculation target according to the first embodiment, when using DFRobot DRF0478 as an example of an IoT device, the memory image, firmware image, area to be hashed, and index information will be described in this order.

[0078] (3-2-2-1. Memory Image) As shown in FIG. 6(1), a part of the data in the memory image corresponds to the firmware image. In the example of FIG. 6(1), "app0" in the memory image corresponds to the firmware image. At this time, random data and area information for hash calculation are added to the ".flash.text" segment in the "App Image(.bin)" part of the firmware image loaded into the "app0" partition.

[0079] (3-2-2-2. Firmware Image) As shown in FIG. 6(2), a part of the data in the firmware image corresponds to the area for hash calculation. In the example of FIG. 6(2), ".flash.appdesc.flash.rodata" and ".flash.text" in the firmware image correspond to the area for hash calculation.

[0080] (3-2-2-3. Area for Hash Calculation) As shown in FIG. 6(3), the area for hash calculation is the above ".flash.appdesc", ".flash.rodata", and ".flash.text". The ".flash.text" contains a program part and a random data part, and the random data part further contains hash calculation area index information. At this time, in the IoT gateway, a hash value is calculated from the firmware image, and in the IoT device, a hash value is calculated from the memory image in the device and compared.

[0081] (3-2-2-4. Index Information) As shown in FIG. 6(4), the index information has the number (n) of hash areas and the information of the "start address" and "size" of each of the "hash area 1", ···, "hash area n".

[0082] (3-3. Communication Network) Using FIGS. 7 to 8, a specific example of the communication network of the authentication system 100 will be described. FIG. 7 is a diagram showing an example of the outline of the communication network according to the first embodiment. FIG. 8 is a diagram showing a specific example of the communication network according to the first embodiment. Hereinafter, the outline and the specific example of the communication network of the authentication system 100 will be described in this order.

[0083] (3-3-1. Outline of the communication network) Using FIG. 7, the outline of the communication network of the authentication system 100 will be described. As shown in FIG. 7, the IoT gateway, which is the verification device 20, is a device with a high security level as the basis of trust. Also, the IoT devices, which are the certification devices 30 (30-1, 30-2, 30-3), are devices with a low security level as the basis of trust. Here, the IoT gateway is connected to an external service via a WAN (Wide Area Network) such as an optical fiber line or 5G (Generation) (see FIG. 7(1)). Also, the IoT gateway is connected to the IoT devices via a wired or wireless LAN (Local Area Network) (see FIG. 7(2)).

[0084] (3-3-2. Specific example of the communication network) Using FIG. 8, a specific example of the communication network of the authentication system 100 will be described. As shown in FIG. 8, the IoT gateway, which is the verification device 20 (20-1, 20-2, 20-3), can be realized using, for example, a 5G gateway. Also, the IoT devices, which are the certification devices 30 (30-1, 30-2, 30-3, 30-4, 30-5), can be realized using, for example, a security camera or an ATM (Automated Teller Machine). Furthermore, the IoT gateway can be connected to the 5G core via a VPN (Virtual Private Network) or a dedicated line network through, for example, a 5G base station device.

[0085] (3-4. Authentication process) Using FIGS. 9 to 11, a specific example of the authentication process of the authentication system 100 will be described. FIG. 9 is a diagram showing an example of the outline of the authentication process according to the first embodiment. FIG. 9 is a diagram showing a specific example of device registration in the authentication process according to the first embodiment. FIG. 10 is a diagram showing a specific example of integrity confirmation in the authentication process according to the first embodiment. Hereinafter, the outline of the authentication process of the authentication system 100, a specific example of device registration, and a specific example of integrity confirmation will be described in this order.

[0086] (3-4-1. Outline of the authentication process) Using FIG. 9, the outline of the communication network of the authentication system 100 will be described. As shown in FIG. 9, first, the device manufacturer M creates firmware including a random number and index information (see FIG. 9(1)). Next, the user operator U acquires the firmware of the device using the existing mechanism provided by the device manufacturer M and performs a firmware update of the device (see FIGS. 9(2-1) and 9(2-2)). Subsequently, the user operator U places the firmware of the device on the IoT gateway in association with the device-specific information (see FIG. 9(3)). Then, the IoT device sends a formal registration request to the IoT gateway (see FIG. 9(4)). At this time, the IoT gateway performs integrity confirmation of the device using the pre-registered device-specific information and firmware, and if successful, performs formal registration of the device. In the integrity confirmation, the IoT gateway reads the data to be hashed from the firmware image of the IoT device and from the memory image of the IoT device, generates a hash together with the device-specific information, and performs integrity confirmation (see FIG. 9(5)).

[0087] (3-4-2. Specific example of device registration) Using FIG. 10, a specific example of device registration in the authentication system 100 will be described. Here, among the arrows shown in FIG. 10, the thick arrows indicate TLS (Transport Layer Security) communication, the medium-sized arrows indicate MQTT (Message Queueing Telemetry Transport) communication, the dashed arrows indicate internal communication, and the thin arrows indicate other processes. Note that the communication method is just an example, and other methods may be used instead.

[0088] First, user U procures (purchases) an IoT device from device manufacturer M (see FIG. 10(1)). Next, user U makes a firmware download request to device manufacturer M (see FIG. 10(2)), and in response, device manufacturer M sends the firmware to user U to perform the firmware download (see FIG. 10(3)). Also, user U sends the unique information and firmware of IoT device 30 to an IoT gateway (device management) 20B that manages the IoT device to perform device firmware registration (see FIG. 10(4)). At this time, IoT gateway (device management) 20B stores the received unique information and firmware of IoT device 30 in the device information database. Through the processes of FIGS. 10(2) to (4) described above, the firmware of the IoT device is registered in the IoT gateway.

[0089] In addition, user U installs an IoT device (prover) 30 that performs integrity proof (see Fig. 10(5)). Next, IoT device 30 transmits its unique information to IoT gateway (device management) 20B and makes a registration request for IoT device 30 (see Fig. 10(6)). Subsequently, IoT gateway (device management) 20B transmits the unique information of IoT device 30 to IoT gateway (verifier) 20A that performs integrity verification and makes a request for confirming the integrity of IoT device (prover) 30 (see Fig. 10(7)). Also, IoT gateway (verifier) 20A acquires the corresponding firmware using the unique information of IoT device 30 as a key from the device information database. Then, IoT gateway (verifier) 20A executes the integrity confirmation of IoT device (prover) 30 through the challenge-response authentication between the aforementioned IoT devices (provers) 30 in (3-1. Integrity confirmation process) (see Fig. 10(8)). Further, IoT gateway (verifier) 20A transmits the integrity confirmation result to IoT gateway (device management) 20B (see Fig. 10(9)). Finally, IoT gateway (device management) 20B stores the official registration of IoT device (prover) 30 in the device information database. Through the processes of Fig. 10(5) to (9) described above, an IoT device with confirmed integrity is installed.

[0090] (3-4-3. Specific example of integrity confirmation) With reference to Fig. 11, a specific example of integrity confirmation of authentication system 100 will be described. Here, among the arrows shown in Fig. 11, the thick arrows indicate TLS communication, the medium arrows indicate MQTT communication, the dashed arrows indicate internal communication, and the thin arrows indicate other processes. Note that the communication method is an example, and other methods may be used.

[0091] First, user U can set the monitoring execution conditions for the IoT gateway (device management) 20B (see Fig. 11(1)). At this time, the IoT gateway (device management) 20B stores the set execution timing for periodically performing integrity confirmation received in the device information database. By the process shown in Fig. 10(1) described above, the periodic monitoring conditions for the IoT device (prover) 30 are set.

[0092] Also, first, user U performs immediate execution of integrity confirmation for the IoT gateway (device management) 20B (see Fig. 11(2)). At this time, the IoT gateway (device management) 20B sends an execution notification of integrity confirmation to the IoT gateway (verifier) 20A (see Fig. 11(3)). Note that the IoT gateway (device management) 20B also sends an execution notification of integrity confirmation to the IoT gateway (verifier) 20A when performing periodic execution of integrity confirmation based on the monitoring execution conditions. Also, the IoT gateway (verifier) 20A acquires the corresponding firmware using the unique information of the IoT device (prover) 30 from the device information database as a key. Then, the IoT gateway (verifier) 20A executes integrity confirmation of the IoT device (prover) 30 by the challenge-response authentication between the IoT devices (provers) 30 described above in (3-1. Integrity confirmation process) (see Fig. 11(4)). Also, the IoT gateway (verifier) 20A sends the integrity confirmation result to the IoT gateway (device management) 20B (see Fig. 11(5)). Then, the IoT gateway (device management) 20B stores the registration of the determination result of the IoT device (prover) 30 in the device information database. By the processes shown in Fig. 11(2) to (5) described above, integrity confirmation of the IoT device is executed. Finally, the IoT gateway (device management) 20B sends the integrity confirmation result to user U (see Fig. 11(6)).

[0093] [4. Flow of the authentication process of the authentication system 100] Using FIG. 12, the flow of the authentication process of the authentication system 100 according to the first embodiment will be described. FIG. 12 is a flowchart showing an example of the flow of the authentication process according to the first embodiment. Note that the following steps S101 to S105 can also be executed in a different order. Also, among the following steps S101 to S105, there may be processes that are omitted.

[0094] First, the firmware generation device 10 generates model-common firmware (step S101). For example, the firmware generation device 10 generates model-common firmware for challenge-response authentication by writing a predetermined random number and index information indicating an area to be subjected to hash calculation into an empty area of the firmware.

[0095] Second, the firmware generation device 10 updates and registers the model-common firmware (step S102). For example, the firmware generation device 10 updates and registers the model-common firmware by transmitting the model-common firmware to the verification device 20 and the proof device 30.

[0096] Third, the verification device 20 formally registers the proof device 30 (step S103). For example, the verification device 20 performs formal registration by challenge-response authentication using the unique information of the proof device 30 and the firmware.

[0097] Fourth, the verification device 20 transmits a challenge to the proof device 30 (step S104). For example, the verification device 20 reads out data to be subjected to hash calculation using the index information included in the model-common firmware held by the verification device 20, executes hash calculation using the unique information of the proof device 30 and the data to be subjected to hash calculation, generates a challenge for the proof device 30, and transmits the challenge.

[0098] Fifthly, the certification device 30 transmits a response to the verification device 20 (step S105). For example, the certification device 30 reads out data to be subjected to hash calculation using index information included in the model-common firmware that the certification device 30 has, executes hash calculation using the unique information of the certification device 30 and the data to be subjected to hash calculation, generates a response to the verification device 20, and transmits the response.

[0099] [5. Effects of the First Embodiment] Finally, the effects of the first embodiment will be described. Hereinafter, effects 1 to 4 corresponding to the processing according to the first embodiment will be described.

[0100] (5-1. Effect 1) In the first embodiment described above, the firmware generation device 10 generates model-common firmware for use in challenge-response authentication by writing a predetermined random number and index information indicating an area to be subjected to hash calculation into the free area of the firmware, the verification device 20 generates a challenge to the certification device 30 based on the model-common firmware held by the verification device 20, and the certification device 30 generates a response to the verification device 20 based on the model-common firmware installed in the certification device 30. Therefore, it is possible to effectively confirm the integrity of IoT devices using model-common firmware.

[0101] (5-2. Effect 2) In the first embodiment described above, the firmware generation device 10 generates a predetermined random number common to each model of the certification device 30 and index information including the start address and size of the memory area to be subjected to hash calculation, and generates model-common firmware by writing the predetermined random number and the index information into the free area. Therefore, by generating effective model-common firmware, it is possible to more effectively confirm the integrity of IoT devices using model-common firmware.

[0102] (5-3. Effect 3) In the above-described first embodiment, the verification device 20 reads out the data to be hashed using the index information included in the model-common firmware held by the verification device 20, executes hashing using the unique information of the proof device 30 and the data to be hashed, and generates a challenge for the proof device 30. Therefore, by generating an effective challenge, it is possible to more effectively confirm the integrity of IoT devices using model-common firmware.

[0103] (5-4. Effect 4) In the above-described first embodiment, the proof device 30 reads out the data to be hashed using the index information included in the model-common firmware installed in the proof device 30, executes hashing using the unique information of the proof device 30 and the data to be hashed, and generates a response for the verification device 20. Therefore, by generating an effective response, it is possible to more effectively confirm the integrity of IoT devices using model-common firmware.

[0104] 〔System configuration, etc.〕 Each component of each device illustrated in the above embodiment is conceptually functional and does not necessarily have to be physically configured as illustrated. That is, the specific form of distribution and integration of each device is not limited to that illustrated, and all or part of it can be functionally or physically distributed and integrated in any unit according to various loads and usage situations. Furthermore, each processing function performed by each device can be realized in whole or in part by a CPU and a program analyzed and executed by the CPU, or can be realized as hardware by wired logic.

[0105] Also, among the processes described in the above embodiments, all or part of the processes described as being automatically performed can be manually performed, or all or part of the processes described as being manually performed can be automatically performed by a known method. In addition, regarding the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above documents and drawings, they can be arbitrarily changed unless otherwise specified.

[0106] 〔Program〕 Also, it is possible to create a program that describes the processes executed by the firmware generation device 10 described in the above embodiments in a language executable by a computer. In this case, by having the computer execute the program, the same effects as in the above embodiments can be obtained. Further, such a program may be recorded on a computer-readable recording medium, and the same processes as in the above embodiments may be realized by having the computer read and execute the program recorded on this recording medium.

[0107] FIG. 13 is a diagram showing a computer that executes a program. As illustrated in FIG. 13, the computer 1000 has, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070, and these components are connected by a bus 1080.

[0108] As illustrated in FIG. 13, the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System), for example. The hard disk drive interface 1030 is connected to a hard disk drive 1090 as illustrated in FIG. 13. The disk drive interface 1040 is connected to a disk drive 1100 as illustrated in FIG. 13. A removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100, for example. The serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120 as illustrated in FIG. 8. The video adapter 1060 is connected to, for example, a display 1130 as illustrated in FIG. 13.

[0109] Here, as illustrated in FIG. 13, the hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the above programs are stored, for example, in the hard disk drive 1090 as program modules in which instructions to be executed by the computer 1000 are described.

[0110] Also, the various data described in the above embodiments are stored, for example, in the memory 1010 or the hard disk drive 1090 as program data. Then, the CPU 1020 reads out the program module 1093 and the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary and executes various processing procedures.

[0111] Note that the program modules 1093 and program data 1094 related to the program are not limited to being stored in the hard disk drive 1090. For example, they may be stored in a removable storage medium and read by the CPU 1020 via a disk drive or the like. Alternatively, the program modules 1093 and program data 1094 related to the program may be stored in another computer connected via a network (such as a LAN (Local Area Network) or WAN (Wide Area Network)) and read by the CPU 1020 via the network interface 1070.

[0112] The above embodiments and their modifications are included in the invention described in the claims and its equivalent scope, in the same way as the technology disclosed in the present application.

Explanation of Reference Numerals

[0113] 10 Firmware Generation Device (Generation Device) 11, 21, 31 Communication Unit 12, 22, 32 Input Unit 13, 23, 33 Output Unit 14, 24, 34 Storage Unit 15, 25, 35 Control Unit 15a, 25a, 35a Receiving Unit 15b Firmware Generation Unit 15c, 25c, 35c Transmitting Unit 20 Verification Device (IoT Gateway) 25b Challenge Generation Unit 25d Response Verification Unit 30 Proof Device (IoT Device) 35b Response Generation Unit 40 User Business Operator Terminal 100 Authentication System

Claims

1. In an authentication system having a generation device that generates firmware, a verification device that performs integrity verification, and a proof device that performs integrity proof, the generation device generates model-common firmware for challenge-response authentication by writing a predetermined random number and index information indicating an area to be hashed into an empty area of the firmware, and has the verification device has a challenge generation unit that generates a challenge to the proof device based on the model-common firmware held by the verification device, and has the proof device has a response generation unit that generates a response to the verification device based on the model-common firmware held by the proof device, and has the challenge generation unit of the verification device reads data to be hashed using the index information included in the model-common firmware held by the verification device, performs a hash calculation using the unique information of the proof device and the data to be hashed, and generates the challenge, characterized in that it is an authentication system.

2. The firmware generation unit of the generation device generates the random number common to each model of the proof device and the index information including the start address and size of the memory area to be hashed, and generates the model-common firmware by writing the random number and the index information into the empty area, characterized in that it is the authentication system according to claim 1.

3. The response generation unit of the proof device reads data to be hashed using the index information included in the model-common firmware held by the proof device, performs a hash calculation using the unique information of the proof device and the data to be hashed, and generates the response, characterized in that it is the authentication system according to claim 1.

4. An authentication method executed by an authentication system having a generation device that generates firmware, a verification device that performs integrity verification, and a proof device that performs integrity proof, wherein the generation device generates model-common firmware for challenge-response authentication by writing a predetermined random number and index information indicating an area to be hashed into an empty area of the firmware, Execute, The verification device A challenge generation step of generating a challenge for the proof device based on the model common firmware held by the verification device Execute, The proof device A response generation step of generating a response for the verification device based on the model common firmware held by the proof device Execute, The challenge generation step executed by the verification device Read the target data for hash calculation using the index information included in the model common firmware held by the verification device, execute hash calculation using the unique information of the proof device and the target data, and generate the challenge. The authentication method is characterized by the above.

5. An authentication program to be executed in an authentication system having a generation device that generates firmware, a verification device that executes integrity verification, and a proof device that executes integrity proof, For the generation device, A firmware generation procedure for generating model common firmware used for challenge-response authentication by writing a predetermined random number and index information indicating an area to be subject to hash calculation into an empty area of the firmware Execute, For the verification device, A challenge generation procedure for generating a challenge for the proof device based on the model common firmware held by the verification device Execute, For the proof device, A response generation procedure for generating a response for the verification device based on the model common firmware held by the proof device Execute, The challenge generation procedure to be executed by the verification device Read the target data for hash calculation using the index information included in the model common firmware held by the verification device, execute hash calculation using the unique information of the proof device and the target data, and generate the challenge. The authentication program is characterized by the above.

Images