JP2023157288A - Device, secure component, device management server, device management system, and device management method - Google Patents

Abstract

To provide a device, a secure component, a device management server, a device management system, and a device management method, which allow for suppressing formation of a single point of failure in robotics.SOLUTION: A device with multiple secure components is provided, comprising a determination unit for determining whether the multiple secure components are operating or not, and a setting unit configured to set an operating secure component to be used by the device from among the operating secure components of the multiple secure components.SELECTED DRAWING: Figure 1

Description

The present invention relates to a device, a secure component, a device management server, a device management system, and a device management method.

In recent years, automatic control of robots based on robotics technology, such as automatic driving technology linked to machine learning, bipedal robots, and drones, has become more prevalent in society. It can be said that ROS (Robot Operating System) is the most popular general-purpose middleware for robotics. Patent Document 1 discloses a distributed system that integrates and shares information based on the ROS architecture.

On the other hand, security is a major issue in promoting the penetration of robotics technology into society. ROS2, the successor to ROS1, has moved to distributed node management using DDS (Data Distribution Service), which eliminates the single point of failure in ROS1 (a single point where a failure or defect can cause a failure in the entire system). It is planned. It is also possible to consider hardware security components as an element of robotics.

JP 2019-8158 Publication

Since hardware security components are generally embedded products, they tend to be highly reliable on their own, but for example, in order to protect against external security attacks, they may be configured to stop operating under certain environments, or they may require credential information. The hardware security component itself may become a single point of failure.

The present invention has been made in view of the above circumstances, and aims to provide a device, a secure component, a device management server, a device management system, and a device management method that can suppress the occurrence of a single point of failure in robotics. do.

The present application includes a plurality of means for solving the above problems, and to give one example, the device is a device including a plurality of secure components, and a device that determines whether or not the plurality of secure components are in an operating state. The device includes a determination unit that makes a determination, and a setting unit that configures a secure component that is in a use state to be used by the device from among the secure components that are in an operating state among the plurality of secure components.

According to the present invention, it is possible to suppress the occurrence of a single point of failure in robotics.

FIG. 1 is a diagram illustrating an example of the configuration of a device management system. FIG. 3 is a diagram showing a steady state of the device. It is a figure which shows the update of an operating state by operating state confirmation. FIG. 7 is a diagram illustrating switching when a secure component fails and notification to a management server. FIG. 3 is a diagram showing credential database update and replication. FIG. 2 is a diagram illustrating direct replication between secure components. FIG. 3 is a diagram illustrating an example of status grasping by a management server. FIG. 7 is a diagram illustrating an example of an instruction of a secure component to be used by the management server. FIG. 3 is a diagram illustrating an example of a replication instruction to a device. FIG. 3 is a diagram illustrating an example of remote replication from a management server. FIG. 3 is a diagram illustrating an example of device malfunction detection.

DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described below based on drawings showing embodiments thereof. FIG. 1 is a diagram showing an example of the configuration of a device management system. The device management system includes a management server (device management server) 100, a device 50 (IoT device 1), and a device 60 (IoT device 2). The device 50 includes a secure component 10 (secure element 1), a secure component 20 (secure element 2), a secure component 30 (trusted environment 1), a network I/F 51, an SEI/F 52, a TEI/F 53, and a secure component management table 54. Equipped with The device 60 includes a secure component 70 (trusted environment 2), a network I/F 61, and a secure component management table 64. I/F means an interface. It is envisioned that the devices 50, 60 are part of a hardware security component of robotics.

In this embodiment, there are two devices 50 and 60, three secure components 10, 20, and 30 are present in the device 50, and one secure component 70 is present in the device 60. The secure component is a tamper-resistant component, and is a secure element installed (connected) to a device or a software component (trusted environment) installed (built-in) to the device. The trusted environments 1 and 2 are secure components placed in the trusted environments of the devices 50 and 60, have software tamper resistance, and are implemented as applications in the trusted environments. The secure elements 1 and 2 and the device 50 are connected through a physical I/F, and communication between the secure elements 1 and 2 and the device 50 is possible. Direct communication between the secure elements 1 and 2 is also possible. Note that the number of devices and the number of secure components are not limited to the example in FIG. 1.

The management server 100 is a server that manages the operating status of the devices 50 and 60 and the status of the secure components 10, 20, and 30 installed in the device 50 and the secure component 70 installed in the device 60. The management server 100 includes a network I/F 101 and a device/secure component management table 102.

The network I/F 101 is an interface for communication between the management server 100 and the devices 50 and 60, and is, for example, an interface using IoT such as Ethernet (trademark), Wi-Fi (trademark), and LPWA (Low Power Wide Area). An interface can be used to control any communication path used by the device.

The device/secure component management table 102 is stored in a storage unit (not shown) of the management server 100, and stores the ID of each device, the ID of each secure component installed in the device, the state of the secure component, and the secret communication channel key. This is a table that is managed by The state of the secure component is expressed by two flags: whether it is currently in operation (available state) (isAlive) or whether it is currently in use (isUse).

The devices 50 and 60 are devices that perform authentication and communication using secure components. In this embodiment, the device is also referred to as an IoT device, but it is not limited to a typical IoT device such as a so-called SBC (single board computer), and is not limited to a typical IoT device such as a so-called SBC (single board computer). It may be hardware.

The network I/F 51 of the device 50 and the network I/F 61 of the device 60 are interfaces for communication between the management server 100 and the devices 50 and 60, and are, for example, Ethernet (trademark), Wi-Fi (trademark) , LPWA (Low Power Wide Area), and other interfaces that control arbitrary communication paths used in IoT devices can be used.

The SEI/F 52 is an interface when the device 50 communicates with each of the secure elements 1 and 2 (secure components 10 and 20), and includes UART (Universal Asynchronous Receiver/Transmitter), SPI (Serial Peripheral Interface), and I2C (Interface). -Integrated Circuit) etc. When performing direct communication between secure elements, use an interface that supports slave-to-slave communication or an interface that does not use the master-slave method.

The TEI/F 53 is an interface when the device 50 communicates with the trusted environment 1 (secure component 30), and is usually a software API (Application Programming Interface), but it uses a dedicated physical bus. You may.

The secure component management table 54 is a table that manages the ID of each secure component installed in the device 50 and the status of the secure component in association with each other. The state of the secure component is expressed by two flags: whether it is currently in operation (available state) (isAlive) or whether it is currently in use (isUse). The same applies to the secure component management table 64, which is a table that manages the ID of each secure component installed in the device 60 and the status of the secure component in association with each other.

The secure component 10 includes a command generation/processing unit 11, an SEI/F 12, a secure communication unit 13, a credential database (credential information) 14, a replication key, and a secure communication channel key. The secure component 20 includes a command generation/processing unit 21, an SEI/F 22, a secure communication unit 23, a credential database (credential information) 24, a replication key, and a secure communication channel key. The secure component 30 includes a command generation/processing unit 31, a TEI/F 32, a secure communication unit 33, a credential database (credential information) 34, a replication key, and a secure communication channel key.

The command generation/processing units 11, 21, and 31 have a function of processing received commands and a function of generating commands for performing replication to other secure components.

The SEI/Fs 12 and 22 are interfaces for communicating with the device 50 and other secure elements, and correspond to UART (Universal Asynchronous Receiver/Transmitter), SPI (Serial Peripheral Interface), I2C (Inter-Integrated Circuit), etc. . When performing direct communication between secure elements, use an interface that supports slave-to-slave communication or an interface that does not use the master-slave method.

The TEI/F 32 is an interface when the trusted environment 1 (secure component 30) communicates with the device 50, and is usually a software API (Application Programming Interface), but it does not use a dedicated physical bus. It's okay.

The secure communication units 13, 23, and 33 have a function of opening a secure communication path to the management server 100 and performing two-way secure communication on the established secure communication path.

The replication key is a key for performing replication between secure components, and may be volatile or non-volatile.

The secret communication channel key is a non-volatile key for opening a secret communication channel independent of the management server 100, and may be a common key or a public key pair. The secret communication channel key differs depending on the secure component.

The credential databases 14, 24, and 34 are databases that store information (security information) used to ensure the security of the device 50. The credential databases 14, 24, and 34 store the same contents in all the secure components 10, 20, and 30 belonging to the device 50, and these databases are the targets of replication.

The credential databases 14, 24, 34 hold device public key pairs, application public key pairs, and CA public key certificates. Note that the content of the information held by the credential databases 14, 24, and 34 is not limited to the example shown in FIG. All you have to do is decide on the content.

The device public key pair is a public key pair that serves as the root of trust of the device 50. Trust means that device 50 can be expected to operate by specific rules for specific purposes.

The application public key pair is a public key pair used when an application on the device 50 performs secure communication.

The CA public key certificate is a public key certificate of a CA (Certification Authority) that signed the device public key pair and/or the application public key pair.

There are two types of secret information stored in the secure components 10, 20, and 30, and the storage locations and handling thereof differ. The first is secret information that should be unique as security information for the device 50, and is stored in the credential databases 14, 24, and 34, and is subject to replication. The second key is a key (replication key and secret channel key) that is managed as an individual value for each secure component 10, 20, 30, and is not stored in the credential database 14, 24, 34.

Next, a use case of this embodiment will be explained. First, a steady state situation in which devices 50, 60 are using a particular secure component will be described, followed by a description of each use case.

FIG. 2 is a diagram showing the steady state of the device. In the device 50, all the secure components 10 (secure element 1), secure components 20 (secure elements 1), and secure components 30 (trusted environment 1) are in an operating state (usable state). Further, the secure component in use that the device 50 actually uses is the secure component 10 (secure element 1). This state of the device 50 is expressed as a flag (isAlive, isUse true, false) on the secure component management table 54.

In the device 60, all secure components 70 (trusted environment 2) are in an operating state (usable state). Further, the secure component in use that the device 60 actually uses is the secure component 70 (trusted environment 2). This state of the device 60 is expressed as a flag (isAlive, isUse true, false) on the secure component management table 64. The states of the devices 50 and 60 are also expressed as flags in the device/secure component management table 102 of the management server 100, and the states expressed in the management tables of both the devices 50 and 60 and the management server 100 match. .

FIG. 3 is a diagram illustrating updating of the operating status by confirming the operating status. The operating states of the secure components are updated by checking the operating states of all the secure components 10, 20, and 30 from the device 50. Each process in the figure will be described below as #1 to #4.

#1 (Transmission of operation status confirmation command): The device 50 checks the operation status of all secure components connected to itself. Here, a command for checking the operating status is sent.

#2 (Processing of the operation status confirmation command): The secure components 10, 20, and 30 that have received the operation status confirmation command transfer the command to the command generation/processing units 11, 21, and 31, and perform command processing (response creation). )I do.

#3 (Response): The secure components 10, 20, and 30 send back the created operational status confirmation response to the device 50.

#4 (Update of operating status): The device 50 updates the operating status of the secure components 10, 20, and 30 according to the reception status of the operating status confirmation response. Here, the isAlive field of the secure component that returned the response is updated to true. In the illustrated example, all the secure components 10, 20, and 30 have returned responses, so all of the secure components 10, 20, and 30 are updated to the operating state. That is, the secure component that has returned a response is determined to be in an operating state (usable state), and the secure component that has not returned a response is determined to be in an inactive state (unusable state).

In the example shown in Figure 3, a command is generated and sent to the secure component to confirm the operating status, but a separate signal line for confirming the operating status is prepared, and if the signal level is High, it is in the operating status, and the signal If the level is Low, the operating state may be confirmed by the electric signal level, such as a non-operating state (operation stopped, unusable state).

The trigger for checking the operating state may be determined as appropriate depending on the use case of the device. For example, when the device is started, a timer may be used at fixed intervals, or a fixed random number element may be added to the intervals. Alternatively, a trigger may be given from an external system. Alternatively, it may be executed manually by an operator (human). Note that although not shown, similar processing can be performed in the device 60 as well.

FIG. 4 is a diagram showing switching when a secure component fails and notification to the management server. In the operation status check illustrated in FIG. 3, if a specific secure component does not return a response or returns an abnormal response, the device 50 sets the isAlive field of the specific secure component to false when updating the operation status. Update to. This update triggers a secure component switch. In FIG. 4, each process of the switching procedure when the secure component 10 (secure element 1) that is in use in the initial state fails will be described as #1 to #8.

#1 (Transmission of operating state confirmation command): The device 50 checks the operating state of all secure components connected to itself. Here, a command for checking the operating status is sent.

#2 (Processing of the operation status confirmation command): The secure components 10, 20, and 30 that have received the operation status confirmation command transfer the command to the command generation/processing units 11, 21, and 31, and perform command processing (response creation). )I do.

#3 (response): The secure components 20 and 30 send back the created operational status confirmation response to the device 50. However, since the secure component 10 is out of order, it does not return the operating state confirmation response to the device 50.

#4 (Update of operating status): The device 50 updates the operating status of the secure components 10, 20, and 30 according to the reception status of the operating status confirmation response. Here, the isAlive field of the secure components 20 and 30 that returned the response is updated to true. Additionally, the isAlive field of the secure component 10 that does not return a response is updated to false.

#5 (Stopping the use of the secure component in use): In #4 above, the isAlive field of the secure component 10 that is currently in use has been updated to false, so the secure component 10 is in the inactive state. Since a certain thing, that is, a failure due to some cause has been detected, the device 50 changes the usage state (isUse) of the secure component 10 from true to false, and stops using the secure component 10.

#6 (switching the secure component to be used): The device 50 is set to newly use one of the secure components 20 and 30 that is currently in operation (that is, isAlive=true). Here, the use status (isUse) of the secure component 20 (secure element 2) is changed from false to true in order to set the secure component 20 (secure element 2) as a target for use.

#7 (Notification to management server): The device 50 notifies the management server 100 that the secure component management table 54 has been updated.

#8 (Update of device/secure component management table): The management server 100 receives the notification from the device 50 and updates the value of the device/secure component management table 102. This allows synchronization with the secure component management table 54 of the device 50. Specifically, isAlive and isUse of secure element 1 are set from true to false, and isUse of secure element 2 is set from false to true.

As described above, the SEI/F 52 and TEI/F 53 have a function as a determination unit, and determine whether the plurality of secure components 10, 20, and 30 installed in the device 50 are in an operating state. More specifically, the SEI/F 52 and TEI/F 53 transmit operating state confirmation signals (for example, commands) to the plurality of secure components 10, 20, 30, and Based on the response from 30, it is determined whether or not it is in the operating state.

The secure component management table 54 has a function as a setting section, and is used to set a secure component in an operating state to be used by the device 50 from among the plurality of secure components 10, 20, and 30 that are in an operating state. I can do it. More specifically, when a change occurs in the operating state of any of the plurality of secure components, the device 50 can configure (reconfigure) the secure component in use based on a predetermined policy. can. The case where a change occurs in the operating state of any of the plurality of secure components includes not only a change in the state of a secure component that is in use, but also a change in the state of a secure component that is not in use. For example, if multiple secure components are running in a trusted environment, and you use one of them and the status of another secure component that is not in use changes from running to stopped, the stopped secure component Considering that there is a possibility of mutual influence between the secure component and the secure component in use, by resetting the secure component used, it is possible to eliminate the mutual influence with the stopped secure component, and prevent failures in the trusted environment. It can be prevented.

With the above configuration, for example, when the secure component in use falls into an inconvenient state such as failure, an alternative secure component can be used as a new root of trust. By installing multiple secure components, it is possible to prevent robotics (systems) from becoming a single point of failure.

The network I/F 51 has a function as a notification unit, and transmits the status including at least one of the operating status and usage status of the plurality of secure components 10, 20, and 30 to the management server 100 based on a predetermined policy. Can be notified. The notification of the status may be periodically notified not only when there is a change in the status including at least one of the operating status and the usage status, but also when there is no change in the status. Thereby, the operating states of the secure components 10, 20, and 30 can be monitored.

Further, as described above, the secure component to be used by the device 50 can be determined after sending commands and signals to the secure component installed in the device 50 and understanding the state of the secure component. As a result, by constantly grasping the status of the secure component, it is possible to prevent component malfunction (system failure) during execution of security processing.

Further, as described above, the management server 100 manages the device 50 including a plurality of secure components, and has a device/secure component management table 102 (a storage section that stores device management information including the status of a plurality of secure components). , a network I/F 101 (update information acquisition unit) that acquires update information from the device 50 when the state of the secure component is updated, and updates the device/secure component management table 102 based on the acquired update information. (update section that updates device management information).

In this way, by detecting the switching of the root of trust on the device 50 side and switching the information of the secure component used by the device 50 on the management server 100 side that manages the device 50, security and After understanding the failure risk of the system, it is possible to switch the operation of secure components and achieve continuous security operation.

The secure component to be newly used may be determined according to the security policy of the device 50, etc. For example, various policies can be considered, such as giving priority to hardware components over software components when they are in an operating state, or newly using the first secure component found after searching in ascending order of serial number.

FIG. 5 is a diagram showing credential database update and replication. It is necessary to continue to maintain the security of the device 50 even when the secure component in use is switched as described in FIG. 4. In order to continue to maintain the security of the device 50 when switching secure components, the information of all secure components, including the switching destination secure component, must be synchronized. This is because if the key value stored in the credential database is changed by switching the secure component in use, there is a possibility that existing encrypted communication and authentication cannot be maintained. FIG. 5 shows a method in which a secure component autonomously synchronizes with other secure components when information within the secure component is updated. Each process in the figure will be described below as #1 to #8.

#1 (Sending a credential update command): When the device 50 needs to update the credentials in the secure component, it sends an update command to update the credentials to the currently used secure component 10. do. Here, it is assumed that the device public key pair (value: 11112222) stored in the secure component 10 (secure element 1) is updated.

#2 (Update command processing): The secure component 10 passes the update command received from the device 50 to the command generation/processing unit 11 for processing.

#3 (Credential database update): The secure component 10 updates the information in the credential database 14 based on the update command. Here, the value of the device public key pair in the credential database 14 has been updated from 11112222 to 77778888.

#4 (Replication command creation): The secure component 10, triggered by the above-mentioned credential database update in #3, sends a command (replication command) for replicating the credential database to the other secure components 20 and 30. generate. The secure component 10 encrypts the replication command using the replication key stored within itself.

#5 (replication command return): The secure component 10 returns the encrypted replication command to the device 50, and also distributes the returned encrypted replication command to the other secure components 20 and 30. I ask. The SEI/F 12 has a function as an output unit that outputs a replication command.

#6 (Distribution to other secure components): The device 50 distributes the encrypted replication command received from the secure component 10 to the other secure components 20 and 30.

#7 (Replication command processing): The secure components 20 and 30 that have received the encrypted replication command decrypt the encrypted replication command using their own command generation/processing units 21 and 31 using their own replication keys. do.

#8 (Updating credentials of other secure components): The secure components 20, 30 update their own credential databases 24, 34 based on the content of the replication command, and synchronize the credential databases 14, 24, 34. Specifically, the value of the device public key pair in the credential database 24 is updated from 11112222 to 77778888, and the value of the device public key pair in the credential database 34 is updated from 11112222 to 77778888. That is, the update of the device public key pair in the secure element 1 is reflected in all secure components.

As described above, each of the plurality of secure components 10, 20, 30 has a credential database 14, 24, 34 (storage unit that stores credential information). The command generation/processing units 11, 21, and 31 have functions as an update unit and a generation unit. The secure component 10 that has updated the credential information (credential database information) based on the command from the device 50 uses the command generation/processing unit 11 to generate a replication command (replication command) for replicating the updated credential information. do. The plurality of secure components 20 and 30 other than the secure component 10 can update their own credential information when acquiring the replication command via the device 50.

In this way, when one secure component updates its own credential database information, the device 50 performs replication processing on another secure component. This allows each secure component to maintain a synchronized state.

Additionally, by internally creating the commands and authentication processing required for replication by the secure component, replication can be achieved without passing the secure component's knowledge or secret information in plain text to the device.

Setting the replication key to the same value in all secure components is considered to be a convenient and simple configuration for distributing update information, but it is not necessary to have the same value in all secure components. There is no need to have a replication key as a non-volatile value. For example, at system startup, secret information is shared between secure components using a key sharing algorithm such as Diffie-Helman based on an individual public key pair for each secure component, and the secret information is used as a volatile replication key. It is also possible to perform operations such as using

FIG. 6 is a diagram illustrating direct replication between secure components. The process illustrated in FIG. 5 is based on the premise that communication between the device 50 and the secure component is a master-slave method. In the case of a master-slave system represented by I2C or SPI, communication is basically performed under the initiative of the master, that is, under the initiative of the device 50, and direct communication between secure components corresponding to slaves cannot be executed. However, if direct communication is possible, such as when slave-to-slave communication is supported or when secure components are connected via a bus that allows them to communicate with each other, replication can occur directly between secure components without going through the device 50. It can be performed. Each process in the figure will be described below as #1 to #7.

#1 (Sending a credential update command): When the device 50 needs to update the credentials in the secure component, it sends an update command to update the credentials to the currently used secure component 10. do. Here, it is assumed that the device public key pair (value: 11112222) stored in the secure component 10 (secure element 1) is updated.

#2 (Update command processing): The secure component 10 passes the update command received from the device 50 to the command generation/processing unit 11 for processing.

#3 (Credential database update): The secure component 10 updates the information in the credential database 14 based on the update command. Here, the value of the device public key pair in the credential database 14 has been updated from 11112222 to 77778888.

#4 (Replication command creation): The secure component 10, triggered by the above-mentioned credential database update in #3, sends a command (replication command) for replicating the credential database to the other secure components 20 and 30. generate. The secure component 10 encrypts the replication command using the replication key stored within itself.

#5 (returning replication command): The secure component 10 delivers the encrypted replication command to the secure component 20 on the communication path to which it is connected. In the example of FIG. 6, the secure component 10 also distributes the encrypted replication command to the device 50, but does not distribute it from the device 50 to other secure components. The TEI/F 53 of the device 50 transfers the received encrypted replication command as is to the built-in secure component 30 (trusted environment 1).

#6 (Replication command processing): The secure components 20 and 30 that have received the encrypted replication command decrypt the encrypted replication command using their own command generation/processing units 21 and 31 using their own replication keys. do.

#7 (Credential update of other secure components): The secure components 20, 30 update their own credential databases 24, 34 based on the content of the replication command, and synchronize the credential databases 14, 24, 34. Specifically, the value of the device public key pair in the credential database 24 is updated from 11112222 to 77778888, and the value of the device public key pair in the credential database 34 is updated from 11112222 to 77778888. That is, the update of the device public key pair in the secure element 1 is reflected on the secure component 20 (secure element 2) connected to the same communication path, and the update of the device public key pair in the secure element 1 is reflected on the secure component 20 (secure element 2) connected to the same communication path, 30 (trusted environment 1).

As described above, each of the plurality of secure components 10, 20, 30 has a credential database 14, 24, 34 (storage unit that stores credential information). The command generation/processing units 11, 21, and 31 have a function as an update unit. When the credential information (credential database information) of one of the plurality of secure components 10, 20, and 30 (for example, the secure component 10) is updated, the updated credential information of the one secure component is updated. , it is possible to update the credential information of a plurality of secure components (secure components 20, 30) except for the one secure component. Specifically, when a plurality of secure components 20 and 30 except one secure component 10 directly obtain a replication command from the one secure component 10, they cannot update their own credential information. can.

In this way, when one secure component updates its own credential database information, replication processing is performed for other secure components. Thereby, the replication process can be executed without depending on the trigger operation on the device 50 side, and the synchronized state of each secure component can be maintained.

In addition, when secure components are directly connected, by directly sending and receiving commands to achieve replication, replication is performed without intermediary processing on the device, eliminating any room for interference or tampering on the device side, and ensuring replication. can be prevented from becoming a processing bottleneck.

As shown in FIG. 6, according to this embodiment, not only are secure components installed in a device connected to the same physical bus, but also secure components installed in the device are connected to the same physical bus. Even if the secure components in the device are in a trusted environment, replication commands can be delivered to the secure components in the device to update credential information.

The aforementioned secure component switching and replication processing is basically completed between the device and the secure component. However, if an end-to-end confidential communication path can be established between the management server 100 and the secure component, the remote management by the management server allows the management server to grasp the status of the secure component (operating status or usage status) and check the integrity of the credential information. It is possible to perform processes such as security and failure detection. A use case for remote management of the management server 100 will be described below.

FIG. 7 is a diagram showing an example of status grasping by the management server. In FIG. 7, in a situation where the management server 100 has individually opened a confidential communication channel to each secure component 10, 20, 30, the management server 100 has opened a credential database 14 of each secure component 10, 20, 30, The processing of checking the states of 24 and 34 and comparing them with each other will be explained as #1 to #8.

#1 (Acquisition of information from the secure component in use): The management server 100 acquires information in the credential database 14 from the secure component 10 currently in use (isUse is set to true) in the device 50. In this embodiment, as information on the credential database 14, a hash of all stored values currently stored in the credential database 14 is encrypted using the secret communication path key of the secure component 10, and the encrypted hash value is sent from the secure component 10. Transfer to the management server 100. Although not shown, the management server 100 also performs the same processing on the device 60 as on the device 50.

#2 (Identification of connected secure component): The management server 100 identifies a secure component installed in the device 50 other than the secure component 10 that transferred the encrypted hash value. In this embodiment, it is determined from the device/secure component management table 102 that SCID:00000002 and SCID:10000001 exist.

#3 (Information output request to secure component): The management server 100 transmits an information output request for the credential databases 24 and 34 to the secure components 20 and 30 grasped in #2 above. The information output request is transmitted via a secret communication path established between each of the secure components 20 and 30 and the management server 100.

#4 (Transfer to secure communication unit): The secure components 20, 30 that have received the information output request transfer the information output request to the secure communication units 23, 33, and decrypt it.

#5 (Acquisition of credential database information): The secure components 20, 30 calculate and obtain hash values of all stored values currently stored in the credential databases 24, 34 as credential database information.

#6 (Encryption of information): The secure components 20 and 30 encrypt the obtained hash value using their own secret channel keys.

#7 (Output of credential database information): The secure components 20 and 30 transmit the encrypted hash value to the management server 100.

#8 (Comparison of credential database information): The management server 100 compares the credential database information (in this embodiment, the hash value of all stored values stored in the credential database) received from each secure component 10, 20, and 30. is decrypted using the secret communication channel key of each secure component 10, 20, 30. The management server 100 compares the information in the credential database of the secure component 10 in use in the device 50 with the information in the credential database of the other secure components 20 and 30 other than the secure component 10.

In the example of FIG. 7, the value of the device public key pair in the credential database 14 of the secure component 10 is "77778888", whereas the value of the device public key pair in the credential databases 24, 34 of the secure components 20, 30 is "77778888". 11112222”. Therefore, the hash (SE1Hash) received from the secure component 10 is, for example, "FE3F3DAF", whereas the hash (SE2Hash, TE1Hash) received from the secure components 20 and 30 is, for example, "DEADBEAF". and the two do not match.

Through the process shown in FIG. 7, the management server 100 can mutually compare the states of the credential databases of the secure components included in a certain device. Depending on this comparison result, the management server 100 can take various measures for the device based on its own management policy.

In the above example, the hash of all stored values in the credential database is used as the credential database information, but information that can compare and determine the status of the credential database in each secure component based on the management policy of the management server 100 may also be used. If so, any information other than hash may be used.

As shown in FIG. 7, by analyzing the status of each secure component, the management server 100 can determine the appropriateness of the secure components within the device. In the example of FIG. 7, the hash received from the secure component 10 and the hash received from the secure components 20 and 30 do not match. In such cases, there is a possibility that unintended changes or malfunctions have occurred, such as when a credential database that should not have been updated has been updated, or that some kind of tampering has been done to the secure components on the device. . In such a case, by switching the secure component in use from the management server 100 side instead of leaving it in a state where security is compromised, it is possible to prevent the security level from decreasing and ensure stable secure communication.

FIG. 8 is a diagram showing an example of instructions for secure components to be used by the management server. Each process in the figure will be described below as #1 to #4.

#1 (Comparison and determination of credential database status): The management server 100 compares the credential database information received from each secure component. In the example of FIG. 8, similarly to the example of FIG. 7, the hashes received from the secure component 10 and the hashes received from the secure components 20 and 30 do not match. At this time, the information (SE1Hash: "FE3F3DAF") in the credential database of the secure component 10 in use is inappropriate information, and the information (SE2Hash, TE1Hash) in the credential database of the secure components 20 and 30 in standby (available) state is incorrect. : "DEADBEAF") is appropriate information. The management server 100 determines that it is necessary to switch the secure component to be used from the secure component 10 currently in use to one of the secure components 20 and 30 on standby.

#2 (Change of secure component to be used): Based on the determination result in #1, the management server 100 changes the state of isUse in the device/secure component management table 102 and switches the secure component used by the device 50. . Here, isUse of SCID: 00000001 is changed from true to false to remove the secure component 10 from the usage target, and isUse of SCID: 00000002 is changed from false to true to make the secure component 20 a new usage target.

#3 (Change instruction to device): The management server 100 instructs the device 50 to change the secure component to be used.

#4 (Changing the secure component to be used): The device 50 updates the contents of the secure component management table 54 based on the change instruction from the management server 100. Here, in the same way as changing the device/secure component management table 102, isUse of SCID: 00000001 is changed from true to false to remove the secure component 10 from being used, and isUse of SCID: 00000002 is changed from false to true. The secure component 20 is now used.

The management server 100 provides information for a single secure component among the plurality of secure components 10, 20, 30 so that the credential information of the plurality of secure components 10, 20, 30 included in the device 50 is updated in synchronization. , a command output unit (network I/F 101) that instructs other secure components to output a copy command.

With the above configuration, even if the secure component used by the device 50 temporarily becomes inappropriate in handling credentials (thereby making the security function unavailable), other available secure components will still be able to handle the credentials. By switching the secure components to be used based on the information and instructions from the management server 100, stable operation can be continued while maintaining security, and the occurrence of a single point of failure in robotics can be suppressed.

As described above, the management server 100 includes the network I/F 101 (credential information acquisition unit) that acquires credential information stored in each of a plurality of secure components, and performs secure operations based on the acquired credential information (credential database information). It is possible to determine whether there is an abnormality in the component. In addition, when the management server 100 determines that the secure component in use state used by the device 50 is abnormal, the management server 100 outputs a change command to change the secure component in use state to the device 50 via the network I/F 101. can do.

Note that even if the secure component in the used state used by the device 50 is not abnormal, the management server 100 may output a change command to change the secure component in the used state to the device 50. For example, the secure component is a secure element, and in preparation for deterioration due to its service life, the secure element used can be changed from a secure element that has been used for a long time to a secure element that has been used for a short time.

Contrary to the example of FIG. 8, the management server 100 determines that the information in the credential database of the secure component in use is valid and that the information in the credential database is appropriately replicated between all the secure components of the device 50. If the management server 100 determines that the credential database information has not been created, the management server 100 can ensure synchronization of the information in the credential database by instructing the device 50 to execute replication.

FIG. 9 is a diagram showing an example of a replication instruction to a device. Below, the processes in the figure will be explained as #1 to #4.

#1 (Comparison and determination of credential database status): The management server 100 compares the credential database information received from each secure component. In the example of FIG. 9, the hash received from the secure component 10 and the hash received from the secure components 20 and 30 do not match. At this time, the information in the credential database of the secure component 10 in use (SE1Hash: "FE3F3DAF") is appropriate information, and the information in the credential database of the secure components 20 and 30 in standby (available) state (SE2Hash, TE1Hash: It is assumed that "DEADBEAF") is inappropriate information. The management server 100 determines that replication of the credential databases 24, 34 of the standby secure components 20, 30 is necessary.

#2 (Replication instruction to device): The management server 100 instructs the device 50 to replicate the secure component.

#3 (Replication instruction to secure component): The device 50 instructs the currently used secure component 10 to generate a command for replication processing.

#4 (Start generation of replication command): The secure component 10 requests the command generation/processing unit 31 to generate a command for replication processing.

The subsequent replication processing is similar to the processing from #4 onward in "Credential database update and replication" illustrated in Figure 5, or the processing on and after #4 in "Direct replication between secure components" illustrated in Figure 6. .

As described above, the management server 100 includes a command output unit (network I/F 101). A replication command is a command that directly updates credential information.

Furthermore, if the credential information of a secure component in use by the device 50 is different from the credential information of another secure component that is different from the secure component in use, the management server 100 determines whether the credential information of the other secure component is different from the secure component in use. , a network I/F 101 may be provided that outputs a command (replication command) to the device 50 so that the credential information of the secure component in use is replicated.

If the management server 100 determines that replication is necessary, as another option, all secure components can be replicated from the management server 100 side via a secret communication channel. By providing a means to update the credential database in the secure component directly from the management server 100, the secure component can be forcibly synchronized regardless of the reliability of the device's spontaneous execution of replication processing. This point will be explained below.

FIG. 10 is a diagram showing an example of remote replication from the management server 100. Below, the processes in the figure will be explained as #1 to #8.

#1 (Request for update information): The management server 100 requests the secure component 10 currently used by the device 50 to transmit update information via the secret communication channel.

#2 (Transfer to secure communication unit): The secure component 10 transfers the received update information transmission request to the secure communication unit 13.

#3 (Acquisition of update information): The confidential communication unit 13 acquires update information of the credential database 14. Here, the update details of the last updated device public key pair (update from "11112222" to "77778888") are acquired as update information.

#4 (Encrypted output of update information): The secret communication unit 13 encrypts the acquired update information using its own secret communication path key and outputs the encrypted information.

#5 (Transmission to management server): The secure component 10 transmits the encrypted update information to the management server 100 via the secret communication path.

#6 (Distribution to other secure components): The management server 100 decrypts the acquired encrypted update information using the secret communication channel key. The management server 100 re-encrypts the decrypted update information to other secure components 20 and 30 that are replication targets using their respective secret channel keys, and distributes the encrypted information via the secret channel.

#7 (Transfer to secure communication unit): The secure components 20 and 30 transfer the received encrypted update information to the secure communication unit 23 and 33.

#8 (Reflection of update information): The secure component 20 decrypts the encrypted update information using its own secret channel key, and reflects it in the credential database 24. Here, the device public key pair is updated from "11112222" to "77778888." Similarly, the secure component 30 decrypts the encrypted update information using its own secret channel key and reflects it in the credential database 34. Here, the device public key pair is updated from "11112222" to "77778888."

As described above, the management server 100 provides self-service information to each of the plurality of secure components 10, 20, 30 so that the credential information of the plurality of secure components 10, 20, 30 included in the device 50 is updated synchronously. It may be provided with a command output unit (network I/F 101) that outputs a command to instruct update using the credential information together with the credential information held by the credential information.

Furthermore, if the credential information of a secure component in use by the device 50 is different from the credential information of another secure component that is different from the secure component in use, the management server 100 determines whether the credential information of the other secure component is different from the secure component in use. , a network I/F 101 may be provided that outputs a command (replication command) to the other secure components 20 and 30 so that the credential information of the secure component in use is replicated.

In this way, a host system such as the management server 100 directly instructs the secure component to perform replication, thereby preventing security attacks at the device level, such as blocking replication on the device.

In the example shown in FIG. 10, the configuration is such that replication is performed remotely and directly from the management server 100, but on the management server 100 side, the subject of replication is the device, and the management server 100 only uses the device (secure component) state as a device. It is also envisaged that the operation will be limited to monitoring. In this case, by continuing to check the status of the secure component on the management server 100 side, it is effective to remotely monitor the replication processing status of the device. This point will be explained below.

FIG. 11 is a diagram illustrating an example of device malfunction detection. FIG. 11 shows that the status of the secure components 10, 20, and 30 installed in the device 50 (operating status "isAlive" and usage status "isUse") is checked at regular intervals on the management server 100 side, and each secure component is It shows how information (update status) of the credential databases 14, 24, and 34 of the components 10, 20, and 30 is also acquired at the same time.

In the example of FIG. 11A, the information in the credential databases 14, 24, and 34 of the secure components 10, 20, and 30 do not match. Specifically, the information in the credential database 14 of the secure component 10 is SE1Hash: "FE3F3DAF", whereas the information in the credential databases 24, 34 of the secure components 20 and 30 is SE2Hash, TE1Hash: "DEADBEAF". , the two do not match. As described above, if there is a discrepancy in the state of the credential database, replication is not being performed appropriately, and there is a risk of replication failure on the device 50 side.

In the example of FIG. 11B, among the secure components 10, 20, and 30 installed in the device 50, the secure component 20 that is neither in operation nor in use (both "isAlive" and "isUse" are false) periodically Update information is being sent to. In this case, there is a possibility that the secure component sending the update information is not legitimate, not genuine, or has been replaced due to tampering or the like.

As shown in Figure 11A, if there is a situation where there is no change in the usage status or operation status of the secure component, but a discrepancy in the credential database status continues to occur, malfunction on the device side (replication failure) may occur. ) is assumed. Also, as shown in Figure 11B, there is a discrepancy between the secure component operating state and the credential database state (credential database update information is returned from an inactive secure component, or credential database update information is returned from an operating secure component). If a phenomenon such as database update information not being returned occurs, there may be doubts about the operating status of the secure component (the secure component's function may not be working properly, or in the worst case, the secure component may be malicious). (may have been replaced).

Some security attacks, such as downgrade attacks, are attacks that are executed after disabling a part of the security mechanism. For example, an attack can be envisaged in which a part of the secure component is disabled and then a device prepared by the attacker is used as an alternative connection or a connection is faked. In some aspects, it is difficult to distinguish this from a phenomenon in which the operating rate decreases without an attack. By intentionally not performing active replication from the management server 100 and only monitoring it as in this embodiment, the validity of the behavior of the secure components within the device can be verified, and the above-mentioned attack occurrence and secure It becomes possible to prepare for factors that reduce the reliability of components.

(Additional Note 1) The device of this embodiment is a device that includes a plurality of secure components, and includes a determination unit that determines whether or not the plurality of secure components are in an operating state, and a determination unit that determines whether or not the plurality of secure components are in an operating state. and a setting unit for setting a secure component in a usage state to be used by the device from among secure components in a state.

(Additional Note 2) In the device of the present embodiment, in the device of Addendum 1, the setting unit is configured to change the usage status based on a predetermined policy when a change occurs in the operating status of any of the plurality of secure components. Configure secure components.

(Additional Note 3) In the device of the present embodiment, in the device of Addendum 1 or 2, the determination unit transmits an operating state confirmation signal to the plurality of secure components, and responds to responses from the plurality of secure components. Based on this, it is determined whether or not it is in an operating state.

(Additional Note 4) The device of this embodiment, in any one of Appendices 1 to 3, maintains a state including at least one of the operating state and usage state of the plurality of secure components based on a predetermined policy. , a notification unit that notifies the device management server.

(Additional Note 5) In the device of this embodiment, in any one of Appendices 1 to 4, each of the plurality of secure components includes a storage section for storing credential information and one of the plurality of secure components. an updating unit that updates the credential information of the plurality of secure components other than the one secure component with the updated credential information of the one secure component when the credential information of the one secure component is updated.

(Additional Note 6) In the device of the present embodiment, in the device of Addendum 5, the first secure component that has updated the credential information based on the command of the device or the command of the device management server is configured to copy the updated credential information. the plurality of secure components excluding the one secure component acquire the replication instruction via the device or directly from the one secure component, Update credential information.

(Additional Note 7) In the device of the present embodiment, in any one of the devices set forth in Appendixes 1 to 6, the secure component is a secure element, a trusted platform module, or a trusted execution environment.

(Additional Note 8) The secure component of this embodiment is a secure component installed in a device, and includes a storage section that stores credential information, and, when the credential information stored in the storage section is updated, a secure component that stores the updated credential information. and an update unit that updates credential information of other secure components installed in the device with the information.

(Appendix 9) In the secure component of Appendix 8, when the credential information stored in the storage unit is updated based on a command from the device or a command from the device management server, the secure component of the present embodiment is installed in the device. The invention includes a generation unit that generates a copy command for copying the updated credential information to other secure components.

(Additional Note 10) The secure component of this embodiment is the secure component of Addendum 9, and includes an output unit that outputs the replication command via a device or directly to the other secure component.

(Additional Note 11) The secure component of the present embodiment is configured by any one of a secure element, a trusted platform module, or a trusted execution environment in the secure component according to any one of Appendices 8 to 10.

(Additional Note 12) The device management server of this embodiment is a device management server that manages a device including a plurality of secure components, and includes a storage unit that stores device management information including the states of the plurality of secure components; The device includes an update information acquisition unit that acquires update information from the device when the state of the secure component is updated, and an update unit that updates the device management information based on the acquired update information.

(Additional Note 13) The device management server of this embodiment includes a credential information acquisition unit that acquires the credential information stored in each of the plurality of secure components, and a credential information acquisition unit that acquires the credential information stored in each of the plurality of secure components, and a credential information acquisition unit that acquires the credential information stored in each of the plurality of secure components, and and a determination unit that determines whether or not there is an abnormality.

(Additional Note 14) In the device management server of Appendix 12 or 13, the device management server of the present embodiment is configured to update the credential information of the plurality of secure components included in the device in a synchronized manner. A command output unit is provided for commanding a single secure component to output a replication command to other secure components.

(Additional Note 15) The device management server of the present embodiment is configured to update the credential information of a plurality of secure components included in the device in a synchronized manner in the device management server according to any one of Appendices 12 to 14. A command output unit is provided for outputting a replication command to.

(Additional Note 16) The device management server of the present embodiment is configured such that the credential information of a plurality of secure components included in the device is synchronously updated in the device management server according to any one of Appendices 12 to 15. The secure component includes a command output unit that outputs the credential information held by the secure component itself as well as a command instructing the secure component to update the credential information.

(Additional Note 17) The device management server of the present embodiment includes an opening unit that opens a confidential communication path with the plurality of secure components in any one of the device management servers set forth in Notes 12 to 16.

(Additional Note 18) The device management system of this embodiment includes the above-described device and the above-described device management server.

(Additional Note 19) The device management method of the present embodiment is a device management method for managing a device including a plurality of secure components, which stores device management information including the states of the plurality of secure components, and stores device management information including the states of the plurality of secure components. When the status is updated, update information is acquired from the device, and the device management information is updated based on the acquired update information.

Items described in each embodiment can be combined with each other. Moreover, the independent claims and dependent claims recited in the claims may be combined with each other in any and all combinations, regardless of the form in which they are cited. Further, although the scope of claims uses a format in which claims refer to two or more other claims (multi-claim format), the invention is not limited to this format. It may be written using a multi-claim format that cites at least one multi-claim.

10, 20, 30, 70 Secure component 11, 21, 31 Command generation/processing unit 12, 22, 52 SEI/F
13, 23, 33 Secret communication section 14, 24, 34 Credential database 50, 60 Device 51, 61, 101 Network I/F
32, 53 TEI/F
54, 64 Secure component management table 100 Management server 102 Device/secure component management table

Claims (19)

A device comprising multiple secure components, the device comprising:
a determination unit that determines whether the plurality of secure components are in an operating state;
a setting unit configured to set a secure component in an active state to be used by the device from among the secure components in an operating state among the plurality of secure components;
device. The setting section includes:
When a change occurs in the operating state of any of the plurality of secure components, setting the active secure component based on a predetermined policy;
A device according to claim 1. The determination unit includes:
transmitting an operating state confirmation signal to the plurality of secure components;
determining whether the plurality of secure components are in an operating state based on responses from the plurality of secure components;
A device according to claim 1 or claim 2. comprising a notification unit that notifies a device management server of a state including at least one of an operating state and a usage state of the plurality of secure components based on a predetermined policy;
A device according to claim 1 or claim 2. Each of the plurality of secure components includes:
a storage unit that stores credential information;
When the credential information of one of the plurality of secure components is updated, the updated credential information of the one secure component is used to replace the credential information of the plurality of secure components other than the one secure component. comprising an update section for updating;
A device according to claim 1 or claim 2. The first secure component that has updated credential information based on a command from a device or a command from a device management server includes a generation unit that generates a replication command for replicating the updated credential information,
The plurality of secure components excluding the one secure component are:
updating its own credential information if the replication instruction is obtained through the device or directly from the one secure component;
6. A device according to claim 5. The secure component is
is a secure element, trusted platform module or trusted execution environment;
A device according to claim 1 or claim 2. A secure component installed in a device,
a storage unit that stores credential information;
an updating unit that updates credential information of other secure components installed in the device with the updated credential information when the credential information stored in the storage unit is updated;
Secure component. When the credential information stored in the storage unit is updated based on a command from the device or a command from the device management server, copying is performed to copy the updated credential information to other secure components installed in the device. comprising a generation unit that generates a command;
Secure component according to claim 8. comprising an output unit that outputs the replication instruction via the device or directly to the other secure component;
Secure component according to claim 9. consisting of either a secure element, a trusted platform module, or a trusted execution environment;
A secure component according to any one of claims 8 to 10. A device management server that manages a device including multiple secure components,
a storage unit that stores device management information including states of the plurality of secure components;
an update information acquisition unit that acquires update information from the device when the state of the secure component is updated;
an updating unit that updates the device management information based on the acquired update information;
Device management server. a credential information acquisition unit that acquires credential information stored in each of the plurality of secure components;
a determination unit that determines whether or not there is an abnormality in the secure component based on the acquired credential information;
The device management server according to claim 12. Instructing a single secure component among the plurality of secure components to output a replication command to other secure components so that the credential information of the plurality of secure components included in the device is updated synchronously. Equipped with a command output section,
The device management server according to claim 12 or claim 13. a command output unit that outputs a replication command to the device so that credential information of a plurality of secure components included in the device is updated synchronously;
The device management server according to claim 12 or claim 13. A command to output to each of the plurality of secure components a command to instruct the plurality of secure components to update with the credential information along with the credential information held by the device so that the credential information of the plurality of secure components included in the device is updated synchronously. Equipped with an output section,
The device management server according to claim 12 or claim 13. comprising an opening unit that opens a secret communication path with the plurality of secure components;
The device management server according to claim 12 or claim 13. A device according to any one of claims 1 to 7,
and the device management server according to claim 12 or 13.
Device management system. A device management method for managing a device including multiple secure components, the method comprising:
storing device management information including states of the plurality of secure components;
when the state of the secure component is updated, obtaining update information from the device;
updating the device management information based on the obtained update information;
How to manage devices.

Images