Secure component, device, and process execution management methods

Abstract

To provide a secure component, device, execution platform, and process execution management method, which allow each participant in a system to control behavior of an implemented process.SOLUTION: A secure component is mounted in a device in which an execution platform operates, and comprises an acquisition unit for acquiring execution constraints imposed on a process from the process operating on the execution platform, a verification unit for verifying the acquired execution constraints, and an output unit for outputting a verification result of the execution constraints to the execution platform.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to secure components, devices Su and and process execution management methods.

Background Art

[0002] In recent years, the social penetration of automatic control of robots based on robotics technologies such as automatic driving technology linked with machine learning, bipedal walking robots, drones, etc. has been progressing. It can be said that ROS (Robot Operating System), as a general-purpose middleware for robotics, has been expanding its influence the most. Patent Document 1 discloses a distributed system that integrates and shares information based on the ROS architecture.

[0003] On the other hand, security is cited as a major issue when promoting the social penetration of robotics technologies. In ROS2, which is the successor to ROS1, authentication and encryption of each component are carried out using the security mechanisms incorporated in DDS (Data Distribution Service). Furthermore, recently, the application of hardware security components to the security mechanisms of robotics has been discussed.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In current robotics systems, all process (Node) keys (e.g., public key pair, private key) reside on the same file system, allowing each process to access the keys of other processes. Therefore, it is common practice to restrict key access at the OS level. However, in open-source software (OSS) ecosystems like ROS, the software providers (participants) within the robot are diverse. On the other hand, not all software providers are trustworthy, and even with trustworthy providers, the behavior of processes due to proprietary implementations can be problematic.

[0006] This invention was made in view of the above circumstances, and provides a secure component and device that can control the behavior of processes implemented by each participant in the system. Su and The objective is to provide a process execution management method. [Means for solving the problem]

[0007] The present invention includes several means for solving the above-mentioned problems, but to give one example, the secure component is a secure component mounted on a device on which an execution platform is running, and comprises an acquisition unit that acquires execution constraints imposed on a process from a process running on the execution platform, a verification unit that verifies the acquired execution constraints, and an output unit that outputs the verification results of the execution constraints to the execution platform. [Effects of the Invention]

[0008] According to the present invention, the behavior of the processes implemented by each participant in the system can be controlled. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows an example of a process management system configuration. [Figure 2] This diagram shows the verification of signed execution constraints when there is no external communication. [Figure 3]This diagram shows the verification of signed execution constraints when external communication is involved. [Figure 4] This diagram shows the effect of execution constraints. [Figure 5] This diagram shows how to update signed execution constraints. [Figure 6] This diagram shows the internal information updates of the secure component. [Modes for carrying out the invention]

[0010] The present invention will be described below based on the drawings illustrating its embodiments. Figure 1 is a diagram showing an example of the configuration of a process management system. The process management system comprises a device (IoT device) 100, a secure component management server 200, a motor manufacturer management server 300, and a control program management server 400. Device 100 is equipped with secure components and has the function of controlling equipment such as sensors 61 and motors 62. Device 100 is envisioned to be an element of hardware security components for the security mechanism of a robotics (system).

[0011] The secure component management server 200 is a server operated by the manufacturer that developed and manufactured the secure component, and is capable of remotely managing the secure component. The motor manufacturer management server 300 is a server managed by the manufacturer that developed and manufactured the motor 62 and the motor control process (Node03) within device 100. The control program management server 400 is a server managed by the manufacturer that developed and manufactured the process (Node02) that controls the coordinated operation with other processes within device 100.

[0012] Within device 100, three processes are running, as described below. Each manufacturer that developed and manufactured the process has its own server, and the processes communicate with the servers under certain constraints. The manufacturer that developed and manufactured sensor 61 and the sensor control process (Node01) does not operate its own server, but instead delegates key management to the secure component development manufacturer. This configuration is adopted when the manufacturer does not actively perform remote management, or when the process provider is an open-source software (OSS) community.

[0013] Device 100 comprises process 10 (Node01 for sensor control), signed Node01 execution constraint 11, process 20 (Node02 for overall control), signed Node02 execution constraint 21, process 30 (Node03 for motor control), signed Node03 execution constraint 31, execution base 40, secure component 50, sensor 61, and motor 62.

[0014] The secure component 50 is a tamper-resistant component that verifies the execution constraints of each process. The secure component 50 may be implemented in either software or hardware form. The secure component 50 can communicate with the execution base 40 via a dedicated I / F (interface).

[0015] Sensor 61 is a sensor mounted on device 100, and in this embodiment, it is manufactured by the manufacturer that developed process 10 (Node01).

[0016] Motor 62 is a motor mounted on device 100, and in this embodiment, it is manufactured by the manufacturer that developed process 30 (Node03). Other actuators may be used instead of motor 62.

[0017] The execution infrastructure 40 is basic software that performs hardware control such as process execution, execution right control, and device communication on the device 100. The execution infrastructure 40 may be an OS (Operating System), middleware executed on the OS, or a container infrastructure such as Docker (trademark) or Kubernetes (trademark).

[0018] Processes 10, 20, and 30 are processes that cooperate to realize functions on the device 100. The process may be a software module. Node01 performs sensor control (e.g., reading sensor values), Node03 performs motor control (e.g., driving an actuator), and Node02 is configured as a process that performs overall control, and functions are realized by each Node communicating with each other. Processes 10, 20, and 30 are units of processing executed on the execution infrastructure 40. In this embodiment, processes 10, 20, and 30 are assumed to be instances of programs executed on the OS, but when the container infrastructure is used as the execution infrastructure, the container corresponds to it.

[0019] The signed execution constraints 11, 21, and 31 are obtained by signing the execution constraints associated with each process with the private key held by each manufacturer, and are attached and distributed together with the process. The specified content of the execution constraints can be, for example, internal communication, external communication, and devices that can be used. Internal communication specifies processes (Nodes) that can communicate within the device 100. Communication is not possible with processes not specified in the execution constraints. External communication specifies whether communication with the outside of the device 100 is permitted. When permitted by the execution constraints, the domain or host name for which communication is permitted is specified. The device to be used specifies the devices for which control is permitted within the device 100.

[0020] In the example of FIG. 1, the execution constraints of Process 10 are specified such that the internal communication is Node02, there is no external communication, and the device in use is a sensor. The execution constraints of Process 20 are specified such that the internal communications are Node01 and Node03, the external communication is ControllerMaker (control program management server 400), and there is no device in use. The execution constraints of Process 30 are specified such that the internal communication is Node02, the external communication is MotorMaker (motor maker management server 300), and the device in use is a motor. Note that the execution constraints of the processes are not limited to the example of FIG. 1.

[0021] Each process has its execution constraints defined according to the manufacturer's design intent and security policy during development by the manufacturer. The execution constraints are signed and distributed together with the process. Each process is expected to operate according to its respective execution constraints, enabling each participant in the system to control the behavior of the processes implemented. The signature for the execution constraints is generated by signing the execution constraint data using a private key. The signature method may be a commonly used method such as ECDSA (Elliptic Curve Digital Signature Algorithm), for example.

[0022] The secure component 50 includes a secure communication unit 51, an execution constraint verification unit 52, and an execution constraint table 53.

[0023] The secure communication unit 51 has a function for the secure component 50 to directly perform secure communication with the secure component management server 200.

[0024] The execution constraint verification unit 52 has a function to receive the signed execution constraints 11, 21, 31 from the processes 10, 20, 30 on the device 100 via the execution infrastructure and then perform verification. The execution constraint verification unit 52 verifies the signature using the public key of each Node (Node01 public key, Node02 public key, Node03 public key) held by itself or the secure component 50, and collates with the execution constraint table 53 to verify the validity of the execution constraints.

[0025] The execution constraint table 53 is used when there are specific restrictions on the execution of each process, in addition to signature verification performed with a public key. The execution constraint table 53 specifies whether or not there are constraints to check for each Node. In the example in Figure 1, Node01 and Node02 have constraints to check, while Node03 does not. Node01's confirmation item 531 specifies that internal communication is limited to Node02 only, external communication is prohibited, and the use of devices other than sensors is prohibited. Similarly, Node02's confirmation item 532 specifies that there is no specific internal communication, external communication is limited to ControllerMaker only, and the use of devices is prohibited. Note that the constraints to check are just examples and are not limited to the example in Figure 1. The execution constraint table 53 is a data structure used by the secure component 50 to define the execution constraints that each process 10, 20, and 30 must comply with. In this embodiment, it consists of two tables: one showing whether or not there are confirmation items for each process, and another showing the specific confirmation items for each process, but the configuration is not limited to this.

[0026] The secure component 50 can be either a hardware implementation (e.g., a secure element, a TPM: Trusted Platform Module) or a software implementation (e.g., a trusted execution environment), as long as it satisfies two conditions: being independent of the execution base 40 and being able to communicate with the execution base 40 and processes 10, 20, and 30 via a communication channel. In this embodiment, the secure component 50 will be described as an external secure element.

[0027] The execution platform 40 includes a network interface 41, a secure component interface 42, an inter-process communication interface 43, and a device access interface 44.

[0028] Network I / F41 is the interface for communication via the network with the secure component management server 200, the motor manufacturer management server 300, and the control program management server 400, which are located outside of device 100. Network I / F41 corresponds to, for example, a Socket API that provides TCP / IP (Transmission Control Protocol / Internet Protocol) communication.

[0029] The Secure Component I / F 42 is an interface for communicating with the Secure Component 50 built into the device 100. The Secure Component I / F 42 is, for example, a PC / SC (Personal Computer / Smart Card) API.

[0030] The inter-process communication interface 43 is an interface for processes on the execution platform 40 to communicate with each other. Examples of inter-process communication interfaces 43 include pipes and brokers (interfaces that accept publish / subscribe requests from each process).

[0031] The device access interface 44 is an interface for controlling the sensor 61 and motor 62 (actuator) mounted on device 100. The device access interface 44 is equivalent to, for example, an SPI (Serial Peripheral Interface) or I2C (Inter-Integrated Circuit) driver.

[0032] The execution platform 40 provides processes running on it with interfaces for using network, hardware, and security components. Each interface is controlled by the execution platform 40 and cannot be used by processes without explicit permission from the execution platform 40. When a process wants to use an interface, it must first identify its communication partner and then obtain explicit permission from the execution platform 40 for the source-destination combination before it can be used. The execution platform 40 includes, for example, operating systems in the narrow sense (Windows, Linux®, etc.), middleware such as robotics frameworks (ROS, etc.), and container execution platforms such as Docker and Kubernetes.

[0033] The secure component management server 200 includes a signature generation unit 210, a secure communication unit 220, Node01 execution constraints 230, and Node01 verification items 240.

[0034] The signature generation unit 210 uses its own private key to generate a signed execution constraint for the process.

[0035] The secure communication unit 220 has the function of directly establishing a secure communication channel with the secure component 50 using a secure communication key. The Node01 execution constraints 230 and Node01 verification items 240 are the same as the contents of the signed Node01 execution constraints 11 in device 100 and the Node01 verification items 531 in secure component 50.

[0036] In this embodiment, the secure component management server 200 is responsible for receiving the secret key of the sensor control process (Node01) from the sensor manufacturer and generating a signed Node01 execution constraint 11 for Node01. The signature generation unit 210 generates the signed Node01 execution constraint 11 for Node01.

[0037] The motor manufacturer management server 300 includes a signature generation unit 310 and a Node communication unit 320. The control program management server 400 includes a signature generation unit 410 and a Node communication unit 420.

[0038] The signature generation units 310 and 410 have the function of generating signed execution constraints for processes using the private keys they hold. The functions of the signature generation units 310 and 410 are the same as those of the signature generation unit 210 of the secure component management server 200. The developers of Node02 (for overall control) and Node03 (for motor control) manage their own private keys and, when a new signed execution constraint is needed, sign it themselves using their own private key and attach it to the process.

[0039] The Node communication units 320 and 420 have functions for communicating with corresponding processes within device 100. The Node communication units 320 and 420 have functions for communicating with each Node within device 100, and these functions vary depending on the application of device 100.

[0040] Some of the hardware and software manufacturers whose products are installed in device 100 have built their own management servers, such as a motor manufacturer management server 300 and a control program management server 400, and have means of communicating with device 100. This allows some manufacturers to manage the processes on device 100.

[0041] Process management systems use key information such as Node private keys, Node public keys, Node communication keys, and confidential communication keys. The Node private key is a signature generation key used to generate new signed execution constraints for processes. Each manufacturer generates it as a public key pair along with the Node public key. The private key is held and kept confidential by each manufacturer.

[0042] The Node public key is a signature verification key used to verify the signed execution constraint entered into the secure component 50. Each manufacturer generates a public key pair along with the Node private key, and pre-writes only the public key to the secure component 50.

[0043] The Node communication key is the key used for network communication between each manufacturer's management server and the processes developed by each manufacturer. The Node communication key may be a public key pair or a symmetric key, but it is treated as a value that should be kept secret from everyone except each manufacturer's management server, the secure component 50, and each manufacturer's processes. In this embodiment, the Node communication key is defined as a representative example of a "credential stored within the secure component 50 and used securely only within the corresponding process."

[0044] The secure communication key is the key used by the secure component 50 to establish an independent secure communication channel with the secure component management server 200.

[0045] The basic use cases of the process management system in this embodiment include the following three: (1) The process presents signed execution constraints for verification and operates under those constraints on the execution platform 40 (even when performing external communication using a network, the communication partner is specified in the execution constraints and verified). (2) The developer / manufacturer updates the signed execution constraints. (3) Update the internal information of the secure component 50. These will be explained in order from here on.

[0046] Figure 2 shows the verification of signed execution constraints when there is no external communication. Processes running on the execution platform 40 undergo verification of signed execution constraints to the secure component 50 via the execution platform 40 prior to their actual execution. Here, we illustrate the verification flow of signed execution constraints for Node01. Node01 is a process that does not communicate with the outside world, but only with Node02 and sensor 61. The processes in the figure will be explained below as #1 to #10.

[0047] #1 (Reading signed execution constraint): Process 10 reads the signed Node01 execution constraint 11 that it possesses.

[0048] #2 (Call to Secure Component I / F): Process 10 passes the signed Node01 execution constraint 11 to the Secure Component I / F 42 provided by the execution infrastructure 40 and requests verification of the execution constraint.

[0049] #3 (Transfer to Secure Component): The execution infrastructure 40 passes the signed Node01 execution constraint 11 to the secure component 50 and calls the execution constraint verification unit 52 of the secure component 50.

[0050] #4 (Signature Verification of Execution Constraint): The secure component 50 reads the public key of process 10 corresponding to the received signed Node01 execution constraint 11, and uses the read public key to verify the signature of the signed Node01 execution constraint 11. If the signature verification fails, the process terminates here and the verification failure is communicated to the execution infrastructure 40, which then does not run process 10. If the signature verification is successful, the process proceeds to the next step, #5.

[0051] #5 (Checking for the presence of constraints): Secure component 50 refers to its own execution constraint table 53 to check for the presence of constraints for the process being verified. In the example in Figure 2, there are constraints for Node01, so the content of the constraints is checked.

[0052] #6 (Constraint Verification): The secure component 50 compares the Node01 verification item 531 for Node01 and verifies whether the contents of the signed Node01 execution constraint 11 match the contents of the Node01 verification item 531. In the example in Figure 2, all three conditions are met: (1) internal communication is prohibited except for Node02, (2) external communication is prohibited, and (3) only sensors can be used as devices. Therefore, it is determined that the contents of the signed Node01 execution constraint 11 match the contents of the Node01 verification item 531. If they do not match, the process ends here and the verification failure is communicated to the execution platform 40, which does not run process 10. If they match, the process proceeds to the next step, #7.

[0053] #7 (Returning results to the execution platform): Secure component 50 returns the execution constraint verification results to the execution platform 40.

[0054] #8 (Communication permission for each I / F): If the execution constraint verification is successful, the execution platform 40 allows the process 10 that requested the verification to use the I / F corresponding to the execution constraint. In the example in Figure 2, (1) communication between Node01 and Node02 is permitted to the inter-process communication I / F 43, and (2) the device access I / F 44 is permitted to allow Node01 to use the sensor 61.

[0055] #9 (Returning results to the process): Execution platform 40 returns the execution constraint verification results to process 10.

[0056] #10 (Perform permitted communication and device access): Process 10 initiates communication with Node02 (Process 20) based on execution constraints, accesses sensor 61, and performs its defined function.

[0057] Figure 3 shows the verification of signed execution constraints when external communication is involved. In the example in Figure 2, Node01 did not need to communicate with an external server and did not need to use the secret information (communication key) within the secure component 50. On the other hand, for processes that communicate with an external server based on the secret information within the secure component 50, external communication can be enabled by outputting that information to the process and allowing the use of the network I / F 41. Each process related to the execution constraint verification of Node02, which performs this operation, is described as #1 to #12.

[0058] #1 (Reading signed execution constraint): Process 20 (Node02) reads the signed Node02 execution constraint 21 that it possesses.

[0059] #2 (Call to Secure Component I / F): Process 20 passes the signed Node02 execution constraint 21 to the Secure Component I / F 42 provided by the execution infrastructure 40 and requests verification of the execution constraint.

[0060] #3 (Transfer to Secure Component): The execution infrastructure 40 passes the signed Node02 execution constraint 21 to the secure component 50 and calls the execution constraint verification unit 52 of the secure component 50.

[0061] #4 (Signature Verification of Execution Constraint): The secure component 50 reads the public key of process 20 corresponding to the received signed Node02 execution constraint 21, and uses the read public key to verify the signature of the signed Node02 execution constraint 21. If the signature verification fails, the process terminates here and the verification failure is communicated to the execution infrastructure 40, which then does not run process 20. If the signature verification is successful, the process proceeds to the next step, #5.

[0062] #5 (Checking for the presence of constraints): Secure component 50 refers to its own execution constraint table 53 to check for the presence of constraints for the process being verified. In the example in Figure 3, there are constraints for Node02, so the content of the constraints is checked.

[0063] #6 (Constraint Verification): The secure component 50 compares the Node02 verification item 532 for Node02 and verifies whether the contents of the signed Node02 execution constraint 21 match the contents of the Node02 verification item 532. In the example in Figure 3, all three conditions are met: (1) there are no restrictions on internal communication (i.e., communication with Node01 and Node03 is possible), (2) external communication is limited to ControllerMaker only, and (3) the use of devices is prohibited. Therefore, it is determined that the contents of the signed Node02 execution constraint 21 match the contents of the Node02 verification item 532. If they do not match, the process terminates here and the verification failure is communicated to the execution platform 40, which then does not run process 20. If they match, the process proceeds to the next step, #7.

[0064] #7 (Reading confidential information): If the execution constraint verification is successful, the secure component 50 reads the confidential information associated with the requesting process 20. In the example in Figure 3, the secure component 50 reads the Node02 communication key corresponding to Node02 as confidential information.

[0065] #8 (Returning results to the execution platform): The secure component 50 returns the execution constraint verification results and the retrieved secret information (Node02 communication key) to the execution platform 40.

[0066] #9 (Communication permission for each I / F): If the execution constraint verification is successful, the execution infrastructure 40 permits the process 20 that requested the verification to use the I / F corresponding to the execution constraint. In the example in Figure 3, (1) the inter-process communication I / F 43 is instructed to allow communication between Node02 and Node01, and between Node02 and Node03, and (2) the network I / F 41 is instructed to allow communication from Node02 to ControllerMaker (control program management server 400).

[0067] #10 (Returning results to the process): The execution infrastructure 40 returns the execution constraint verification results and the retrieved secret information (Node02 communication key) to process 20.

[0068] #11 (Perform permitted internal communication): Process 20 initiates inter-process communication with Node01 (Process 10) and Node03 (Process 30) based on execution constraints.

[0069] #12 (Perform authorized external communication): Based on the execution constraints, process 20 communicates with the external ControllerMaker (control program management server 400) via network I / F41 using the retrieved secret information (Node02 communication key) to implement functions such as remote monitoring and remote management.

[0070] As described above, the execution constraint verification unit 52 of the secure component 50 includes the functions of an acquisition unit that acquires execution constraints imposed on a process from a process running on the execution platform 40, a verification unit that verifies the acquired execution constraints, and an output unit that outputs the verification results of the execution constraints to the execution platform 40.

[0071] This allows control over the behavior of the processes implemented by each participant in the system.

[0072] More specifically, the secure component 50 includes a storage unit that stores signature verification keys (each node's public key), and the execution constraint verification unit 52 obtains signed execution constraints and verifies the signed execution constraints using the signature verification keys.

[0073] Furthermore, the secure component 50 includes a storage unit that stores constraint confirmation information (execution constraint table 53) related to processes operating on the execution platform 40. The execution constraint verification unit 52 verifies the execution constraints based on the acquired execution constraints and the constraint confirmation items related to the processes to which the execution constraints are imposed.

[0074] In this way, by requiring the presentation of signed execution constraints that the process follows as a condition for the process's operation, and verifying this in the secure component 50, it is possible to prevent tampering or attacks on the execution constraint verification process by verifying within the secure component 50 that the process complies with execution constraints approved by the process manufacturer and permitted by the secure component 50. Furthermore, it is possible to control the behavior of processes implemented by each participant in the system.

[0075] As described in #9 above, the network I / F 41 functions as a provider, and if the acquired execution constraint permits a process to communicate with devices outside 100 and the verification of the execution constraint is successful, it can provide the process with at least one of the information and functions necessary for external communication. The network I / F 41 also functions as a prohibition, and if the acquired execution constraint permits a process to communicate with devices outside 100 and the verification of the execution constraint fails, it can prohibit the process from communicating with devices outside 100. The inter-process communication I / F 43 also functions as a provider, and if the acquired execution constraint permits a process to communicate with devices 100 and the verification of the execution constraint is successful, it can provide the process with at least one of the information and functions necessary for inter-process communication. The inter-process communication I / F 43 also functions as a prohibition, and if the acquired execution constraint permits a process to communicate with devices 100 and the verification of the execution constraint fails, it can prohibit the process from communicating with devices outside 100. The information required for communication includes, for example, key information, and the functions required for communication include functions such as authentication calculations required for communication.

[0076] The secure component interface 42 of the execution platform 40 functions as a transfer unit and an acquisition unit, acquiring execution constraints imposed on a process from that process and transferring them to the secure component 50, and acquiring the verification results of the execution constraints from the secure component 50. The network interface 41, inter-process communication interface 43, and device access interface 44 of the execution platform 40 function as control units, and can control the operation of the process according to the acquired verification results.

[0077] Furthermore, in the process execution management method of this embodiment, the process outputs execution constraints imposed on the process to the secure component 50 via the execution platform 40, the secure component 50 acquires the execution constraints, verifies the acquired execution constraints, and outputs the verification results of the execution constraints to the execution platform 40. The execution platform 40 can control the operation of the process according to the verification results.

[0078] In this way, by having the execution platform 40 enforce the execution constraints approved by the secure component 50 on the process, enforcement power that would be difficult to achieve with the secure component 50 alone can be secured through cooperation with the execution platform 40. Furthermore, the behavior of the processes implemented by each participant in the system can be controlled.

[0079] Figure 4 shows the effects of execution constraints. By imposing signed execution constraints on each process, as illustrated in Figures 2 and 3, several advantages can be obtained, such as: (1) preventing unauthorized addition of execution constraints to each process; (2) preventing processes from performing actions not permitted by the execution constraints; (3) enabling verification of execution constraints on the secure component 50 independently of the processes; and (4) limiting the scope of dissemination of confidential information specific to each process.

[0080] Figure 4 illustrates the following four situations: (1) the execution constraints of Node01 were illegally altered by a third party (without using the Node01 private key); (2) the execution constraints of Node02 were inappropriately modified using the Node02 private key; (3) Node03 attempted to access sensor 61, which is not specified in the execution constraints; and (4) Node03 attempted to access the control program management server 400, which is not specified in the execution constraints. Note that Node03 is only permitted to communicate with the motor manufacturer management server 300.

[0081] However, the combination of the secure component 50 and the execution platform 40 in this embodiment suppresses each problematic behavior as follows. (Problem behavior #1): Information leakage attack through tampering with execution constraints (Addressing Problematic Behavior #1): In secure component 50, signature verification against execution constraints fails, and the process operation is blocked by execution infrastructure 40.

[0082] (Problem behavior #2): Malfunction due to inappropriate execution constraint specification (Addressing Problematic Behavior #2): In secure component 50, an execution constraint that is not permitted according to the execution constraint verification requirements is detected, execution constraint verification fails, and the process operation is blocked by the execution infrastructure 40.

[0083] (Problem behavior #3): Access to unauthorized devices (Addressing Problematic Behavior #3): The device access interface 44 of the execution platform 40 blocks the communication as unauthorized. Thus, the device access interface 44 functions as a provider, and if the acquired execution constraint permits a process to communicate with a peripheral within device 100, and the verification of the execution constraint is successful, it can provide the process with at least one of the information and functions necessary for such communication. Furthermore, the device access interface 44 functions as a prohibition, and if the acquired execution constraint permits a process to communicate with a peripheral within device 100, and the verification of the execution constraint fails, it can prohibit the process from performing such communication. The information necessary for communication includes, for example, key information, and the functions necessary for communication include functions such as authentication calculations necessary for communication.

[0084] (Problem behavior #4): Communication to unauthorized external servers (Addressing problematic behavior #4): The network interface 41 of the execution platform 40 blocks it as unauthorized communication.

[0085] According to this embodiment, the potential destinations for the leakage of confidential information extracted by the process from the secure component 50 can also be minimized. In this embodiment, the Node02 communication key and the Node03 communication key are confidential information. For example, suppose Node03 attempts to fraudulently obtain this confidential information by using Node02's signed Node02 execution constraint. Since this verification itself is successful, Node03 will obtain the Node02 communication key, which is Node02's confidential information. However, the execution constraint only allows communication with parties authorized by the Node02 manufacturer. For example, it is not possible to leak the stolen Node02 communication key by communicating with a server other than the control program management server (ControllerMaker) 400. Therefore, leakage is suppressed within a specific process within device 100. This is a minimal security mechanism that limits the scope of signature verification to execution constraints only. Depending on the security policy, it is also possible to implement stronger protection by combining known mechanisms, such as including the hash value of the entire process in signature verification or using user authentication in combination.

[0086] Furthermore, according to this embodiment, by sharing the functions and information of the secure component 50 related to a process only with respect to processes whose execution constraints have been appropriately verified, the scope of sharing of the functions and information of the secure component 50 can be restricted based on the execution constraints. In addition, the behavior of the processes implemented by each participant in the system can be controlled.

[0087] Figure 5 shows the update of signed execution constraints. Signed execution constraints are expected to be generated and attached in advance by the manufacturer when supplying a process to device 100, but it is also possible to apply new execution constraints to the process later for reasons such as functional enhancements. In this case, each manufacturer can sign the new execution constraints using their private key and distribute them. It is also possible for the manufacturer not to directly manage the signatures and to entrust the signature generation to a secure component manufacturer. The processes in the figure will be explained below as #1 to #3.

[0088] #1 (Updating execution constraints): The secure component management server 200 modifies the execution constraint 230 for Node01, which it manages. In the example shown in the diagram, Node03 has been added to internal communication.

[0089] #2 (Signature): The secure component management server 200 signs the modified Node01 execution constraint 230 with the manufacturer's private key it holds, generating a signed Node01 execution constraint 11. Here, the signature is generated using the Node01 private key.

[0090] #3 (Distribution to devices): The secure component management server 200 distributes the generated signed Node01 execution constraint 11 to device 100 (process 10 on it). Distribution may be done online or offline using a storage medium such as a USB memory stick.

[0091] Figure 6 shows the internal information update of the secure component 50. As illustrated in Figure 5, even if execution constraints are updated, the updated execution constraints may not be correctly verified due to the information on the secure component 50 side. In the example in Figure 5, the execution constraints were updated so that Node01 could communicate not only with Node01 but also with Node03, but in the constraint verification on the secure component 50 side, Node01 is only allowed to communicate with Node02, and the execution constraint verification fails. In such a case, the secure component 50 should communicate with the secure component management server 200 via a secure communication channel and update its internal information from the secure component management server 200. The processes in the figure will be explained below as #1 to #4.

[0092] #1 (Update of Verification Items): The secure component management server 200 updates the Node01 verification item 240 (constraint verification item) that it manages. Here, it changes the execution constraint to allow communication with Node03 in accordance with the procedure in Figure 5.

[0093] #2 (Transmission to secure communication unit): The secure component management server 200 sends the updated Node01 verification items 240 to the secure communication unit 220 in order to send them to the secure component 50.

[0094] #3 (Establishment of secure communication channel): The secure component management server 200 establishes a secure communication channel to the secure component 50 via the network I / F 41 of device 100 using a secure communication key.

[0095] #4 (Update of Verification Items): The secure component management server 200 sends the new Node01 verification item 531 to the secure component 50 via the established secure communication channel. The secure component 50 updates the Node01 verification item 531 with the newly received value.

[0096] This procedure ensures consistency between the execution constraints of Node01 and the constraint checks within Secure Component 50 (allowing communication to Node03), enabling Node01 to behave as intended by the developer.

[0097] By individually updating both the signed execution constraints associated with the process and the constraint verification items stored in the secure component 50, it becomes easier to modify the process, while independently managing execution permissions at the secure component 50 level as needed, thereby ensuring the appropriate behavior of the process.

[0098] As described above, in the secure component 50, the execution constraints imposed on the process can be updated by the management server (secure component management server 200). In addition, the secure component 50 establishes a secure communication channel with the management server, and the information used when verifying the execution constraints (constraint verification items) can be updated via the established secure communication channel.

[0099] In this way, by making the execution constraints, keys, and other internal information used for authentication that the secure component 50 allows change remotely via an independent, secure communication channel, it is possible to manage the secure component 50 independently of the device 100 and the execution infrastructure 40, thereby preventing malicious processes from tampering with the authentication conditions while enabling remote management.

[0100] (Note 1) The secure component of this embodiment is a secure component mounted on a device on which an execution platform is running, and comprises an acquisition unit that acquires execution constraints imposed on a process from a process running on the execution platform, a verification unit that verifies the acquired execution constraints, and an output unit that outputs the verification results of the execution constraints to the execution platform.

[0101] (Note 2) The secure component of this embodiment includes a storage unit for storing a signature verification key in the secure component of Note 1, the acquisition unit acquires a signed execution constraint, and the verification unit verifies the signed execution constraint using the signature verification key.

[0102] (Note 3) The secure component of this embodiment includes a storage unit that stores constraint confirmation information relating to a process operating on the execution platform, in the secure component of Note 1 or Note 2, and the verification unit verifies the execution constraint based on the acquired execution constraint and the constraint confirmation items relating to the process to which the execution constraint is imposed.

[0103] (Note 4) The secure component of this embodiment includes a providing unit that, in any of the secure components of Notes 1 to 3, provides the process with at least one of the information and functions necessary for the communication if the acquired execution constraint permits the process to communicate with an entity outside the process and the verification of the execution constraint is successful.

[0104] (Note 5) The secure component of this embodiment includes a prohibition unit in any of the secure components of Notes 1 to 4 that prohibits communication by the process if the acquired execution constraint permits communication by the process with an entity outside the process, and the verification of the execution constraint fails.

[0105] (Note 6) In the secure component of this embodiment, the execution constraints imposed on the process in any of the secure components described in Notes 1 to 5 can be updated by the management server.

[0106] (Note 7) The secure component of this embodiment includes an opening unit in any of the secure components described in Notes 1 to 6 for establishing a secure communication channel with the management server, and the information used when verifying execution constraints can be updated via the secure communication channel.

[0107] (Note 8) The secure component of this embodiment is comprised of one of the secure components described in Notes 1 to 7, consisting of a secure element, a trusted platform module, or a trusted execution environment.

[0108] (Note 9) The device of this embodiment is a device equipped with a secure component and on which an execution platform capable of running a process operates, wherein the process includes an output unit that outputs execution constraints imposed on the process to the secure component via the execution platform, the secure component includes an acquisition unit that acquires the execution constraints, a verification unit that verifies the acquired execution constraints, and an output unit that outputs the verification results of the execution constraints to the execution platform, and the execution platform includes a control unit that controls the operation of the process according to the verification results.

[0109] (Note 10) The execution platform of this embodiment is an execution platform that operates on a device equipped with a secure component and on which a process can operate, and comprises a transfer unit that obtains execution constraints imposed on the process from the process and transfers them to the secure component, an acquisition unit that obtains the verification results of the execution constraints from the secure component, and a control unit that controls the operation of the process according to the acquired verification results.

[0110] (Note 11) The process execution management method of this embodiment is a process execution management method using a device equipped with a secure component and on which an execution platform capable of running a process is operated, wherein the process outputs execution constraints imposed on the process to the secure component via the execution platform, the secure component acquires the execution constraints, verifies the acquired execution constraints, outputs the verification results of the execution constraints to the execution platform, and the execution platform controls the operation of the process according to the verification results.

[0111] The matters described in each embodiment can be combined with each other. Furthermore, the independent and dependent claims described in the claims can be combined with each other in any combination, regardless of the form of reference. In addition, the claims use a form in which claims referencing two or more other claims (multi-claim form), but are not limited to this. A form in which multi-claims referencing at least one multi-claim (multi-multi-claim) may also be used. [Explanation of symbols]

[0112] 10 Node01 11. Signed Node01 execution constraints 20 Node02 21. Signed Node02 execution constraints 30 Node03 31. Signed Node03 execution constraints 40 Execution Platform 41 Network Interface 42 Secure Component Interface 43 Inter-process communication interface 44 Device Access Interfaces 50 Secure Components 51 Covert Communications Department 52 Execution Constraint Verification Unit 53 Execution Constraint Table 531 Node01 Verification Items 532 Node02 Verification Items 61 Sensors 62 motors 100 devices 200 Secure Component Management Server 210 Signature generation section 220 Covert Communications Unit 230 Node01 execution constraints 240 Node01 Verification Items 300 Motor Manufacturer Management Server 400 Control Program Management Server 310, 410 Signature generation section 320, 420 Node communication department

Claims

1. A secure component installed on a device on which the execution platform is running, An acquisition unit that acquires signed execution constraints imposed on a process running on the execution platform, which are signed by the process's manufacturer using a secret key held by the manufacturer of the process. A verification unit verifies the validity of the signed execution constraint by using a signature verification key corresponding to the private key and comparing the acquired signed execution constraint with the contents of the constraint verification items related to the process to which the signed execution constraint is imposed. An output unit that outputs the verification results of the execution constraints to the execution platform. Equipped with, Secure component.

2. The acquired execution constraint permits the process to communicate with an entity outside of the process, and if the verification of the execution constraint is successful, the system includes a providing unit that provides the process with at least one of the information and functions necessary for the communication. The secure component according to claim 1.

3. The acquired execution constraint allows the process to communicate with an entity outside of the process, and if the verification of the execution constraint fails, the system includes a prohibition unit that prohibits communication by the process. The secure component according to claim 1.

4. The execution constraints imposed on the aforementioned process can be updated by the management server. The secure component according to claim 1.

5. It is equipped with an opening unit that establishes a secure communication channel with the management server, The information used when verifying execution constraints can be updated via the aforementioned secure communication channel. The secure component according to claim 1.

6. It consists of either a secure element, a trusted platform module, or a trusted execution environment. The secure component according to claim 1.

7. A device equipped with secure components and running an execution platform on which processes can operate, The aforementioned process, The system includes an output unit that outputs execution constraints imposed on the process to the secure component via the execution platform, The aforementioned secure component is An acquisition unit that acquires signed execution constraints imposed on a process running on the execution platform, which are signed by the process's manufacturer using a secret key held by the manufacturer of the process. A verification unit verifies the validity of the signed execution constraint by using a signature verification key corresponding to the private key and comparing the acquired signed execution constraint with the contents of the constraint verification items related to the process to which the signed execution constraint is imposed. An output unit that outputs the verification results of the execution constraints to the execution platform. Equipped with, The aforementioned execution platform is The system includes a control unit that controls the operation of the process according to the verification results, device.

8. A process execution management method using a device equipped with secure components and running an execution platform capable of running processes, The aforementioned process, The execution constraints imposed on the process are output to the secure component via the execution platform. The aforementioned secure component is Obtain a signed execution constraint from a process running on the execution platform, which is imposed on the process and is signed by the process's manufacturer using a secret key held by the manufacturer of the process. The legitimacy of the signed execution constraint is verified by using the signature verification key corresponding to the private key and by comparing the obtained signed execution constraint with the contents of the constraint verification items related to the process to which the signed execution constraint is imposed. The verification results of the execution constraints are output to the execution platform. The aforementioned execution platform is The operation of the process is controlled according to the verification results. Process execution management method.

Images