JP7615605B2 - Secure component, vehicle part, vehicle, computer program, management system and information processing method - Google Patents

Description

The present invention relates to a secure component, a vehicle part, a vehicle, a computer program, a management system , and an information processing method.

Many technical countermeasures have been proposed to prevent theft of vehicles such as bicycles. Patent Document 1 discloses a search device that stores crime prevention registration information online, prints a barcode on the crime prevention registration sticker attached to the bicycle, and can search for crime prevention registration information by reading the barcode with a mobile terminal.

Patent document 2 also discloses a bicycle sharing system in which the bicycles are equipped with electronic locks that can be unlocked using short-range wireless communication with a mobile device.

JP 2003-256960 A JP 2015-113686 A

On the other hand, with the popularity of sports bicycles, luxury bicycles are becoming more common. Like automobiles and motorcycles, luxury bicycles are often traded in parts, so there is a high possibility that these vehicle parts will also be stolen. However, while the devices and systems in Patent Documents 1 and 2 take into consideration bicycle theft, they do not effectively protect vehicle parts.

The present invention has been made in consideration of the above circumstances, and aims to provide a secure component, a vehicle component, a vehicle, a computer program, a management system, and an information processing method that can effectively protect vehicle components.

A secure component according to an embodiment of the present invention is a secure component mounted on a vehicle component used in a vehicle, and includes a communication unit that transmits and receives information to and from other secure components mounted on other vehicle components used in the vehicle, an authentication unit that performs mutual authentication with the other secure components via the communication unit, and a first storage unit that stores mutual authentication information that associates mutual authentication targets with mutual authentication results obtained by the authentication unit.

The vehicle component according to the embodiment of the present invention is equipped with the above-mentioned secure component.

A vehicle component according to an embodiment of the present invention includes a communication unit that transmits and receives information between a first secure component mounted on a first vehicle component used in a vehicle and a second secure component mounted on a second vehicle component used in the vehicle, and an authentication intermediary unit that mediates mutual authentication between the first secure component and the second secure component via the communication unit.

A vehicle according to an embodiment of the present invention includes a plurality of the vehicle components described above.

A computer program according to an embodiment of the present invention causes a computer to execute a process of transmitting and receiving information to and from a secure component mounted on a vehicle component used in a vehicle, performing mutual authentication with the secure component, and storing mutual authentication information that associates mutual authentication targets with mutual authentication results.

An information processing method according to an embodiment of the present invention performs mutual authentication between secure components mounted on each of a plurality of vehicle components used in a vehicle, and each secure component stores mutual authentication information that associates mutual authentication targets with mutual authentication results.

The management system according to an embodiment of the present invention includes a server capable of establishing a secret communication path between the vehicle and a secure component mounted on each of a plurality of vehicle components of the vehicle, and the server manages at least one of the plurality of components and the vehicle based on mutual authentication via the secret communication path.

In a management method according to an embodiment of the present invention, a server capable of establishing a secret communication path between the server and a secure component mounted on each of a plurality of vehicle components of the vehicle manages at least one of the plurality of vehicle components and the vehicle based on mutual authentication via the secret communication path.

The present invention verifies whether vehicle parts are connected in a predetermined appropriate combination, which prevents the intrusion of stolen goods and effectively protects vehicle parts.

1 is a schematic diagram illustrating an example of a configuration of an information processing system according to an embodiment of the present invention. FIG. 2 is a schematic diagram showing an example of the configuration of a derailleur, a battery, a secure element embedded in a front wheel, a secure element embedded in a rear wheel, and a secure element embedded in a frame. FIG. 1 is a schematic diagram showing an example of a procedure for creating a public key TrustChain. FIG. 4 is a schematic diagram showing an example of a command transmission and reception flow between electric components. FIG. 13 is a schematic diagram showing an example of a command transmission and reception flow between an electric component and a non-electric component. FIG. 13 is a schematic diagram showing an example of a command transmission and reception flow between non-electric components; FIG. 13 is a schematic diagram showing an example of a flow of mutual authentication when commands are manually exchanged between electric components; FIG. 13 is a schematic diagram showing an example of a flow of mutual authentication when a command is exchanged between non-electric components; FIG. 11 is a schematic diagram illustrating an example of a flow of component operation control when mutual authentication is completed. FIG. 11 is a schematic diagram showing an example of a flow of updating a mutual authentication list via a secure communication channel. FIG. 13 is a schematic diagram showing an example of an updated mutual authentication list for a part other than a shifter. FIG. 11 is a schematic diagram showing an example of a flow of function suspension by a secret communication function. FIG. 13 is a schematic diagram showing an example of disabling a secure element in a part other than a shifter. FIG. 11 is a schematic diagram illustrating an example of a flow of temporarily revoking mutual authentication in the case of via a secret communication path. FIG. 13 is a schematic diagram showing an example of temporary disabling of mutual authentication of a secure element in a component other than a shifter. FIG. 13 is a schematic diagram showing an example of a flow of temporarily disabling mutual authentication in the case of via an input I/F; FIG. 13 is a schematic diagram showing an example of temporary disabling of mutual authentication of secure elements in components other than the shifter. FIG. 1 is a schematic diagram illustrating an example of a configuration of a management system according to an embodiment of the present invention.

The present invention will now be described with reference to the drawings showing an embodiment of the invention. FIG. 1 is a schematic diagram showing an example of the configuration of an information processing system according to this embodiment. The information processing system comprises a bicycle 100 as a vehicle, a bicycle management server 200, and a bicycle parts DB 250. In the following description, a bicycle is used as an example of a vehicle, but the vehicle is not limited to bicycles and also includes motorcycles (motorcycles) and automobiles. The bicycle 100 and the bicycle management server 200 can communicate via a wireless network or a wired network. The bicycle management server 200 may be distributed across multiple servers, and the bicycle parts DB 250 may be stored within the bicycle management server 200.

The bicycle 100 includes multiple components (vehicle components) with embedded secure elements. In the following, secure elements are used as an example of a secure component, but the secure component is not limited to a secure element, and may be a trusted execution environment (also called a TEE) separated within a SoC (System on Chip) by using a technology called CPU virtualization support technology (e.g., TrustZone (registered trademark)) on the SoC, or may be an IC tag.

In the case of a typical (low-cost) bicycle, all of the bicycle's functions are mechanical (such as gear changes being transmitted by wires), but in the case of expensive bicycles for racing and the like, some functions may be motorized (electric components). In this embodiment, the explanation will be mainly based on a configuration equipped with this electric component, but secure elements are also embedded in parts other than the electric component (such as the frame and wheels), and signal lines capable of communicating with the electric component parts (also called electric components) are connected. Note that power is supplied to the secure elements of parts other than the electric component from the electric components. Note that for convenience, some of the parts that actually make up the bicycle have been omitted, but they operate using the same mechanism as the parts shown in the figure.

The bicycle 100 includes a shifter 10, a derailleur 20, a battery 30, a secure element 40 embedded in the front wheel, a secure element 50 embedded in the rear wheel, and a secure element 60 embedded in the frame.

The shifter 10 is a gear shift instruction device, and is a device for instructing gear changes on the bicycle 100 from the handlebars. The shifter 10 comprises a secure element 11, a control unit 12, a mutual authentication intermediary unit 13, a network communication unit 14, a shifter operation unit 15, and an input I/F. The secure element 11 comprises a mutual authentication unit 16, a part certificate 17, a secret communication unit 18, and a mutual authentication list 19.

In this embodiment, the core functions for bicycle communication are incorporated into the shifter 10. The core functions are composed of a network communication unit 14, a mutual authentication unit 16, and an input I/F. The network communication unit 14 has a function that allows the bicycle 100 to communicate with an external network. The mutual authentication unit 16 has a function that mediates authentication when mutual authentication is performed between non-electric parts. The input I/F has a function that allows the user to start mutual authentication and instruct network communication. When mutual authentication of non-electric parts is performed or communication with an external network is performed, these core functions mediate communication. Note that in this embodiment, the shifter 10 has the core functions, but other devices such as a cycle computer or smartphone may also have the core functions.

Figure 2 is a schematic diagram showing an example of the configuration of a derailleur 20, a battery 30, a secure element 40 embedded in the front wheel, a secure element 50 embedded in the rear wheel, and a secure element 60 embedded in the frame. The derailleur 20 is an externally mounted transmission, and is a mechanism that actually changes gears in response to instructions from the shifter 10. The derailleur 20 includes a secure element 21, a derailleur control unit 22, a derailleur drive unit 23, a mutual authentication unit 24, a part certificate 25, a mutual authentication list 26, and a secret communication unit 27.

The battery 30 is a battery for supplying power to electric components. The battery 30 includes a secure element 31, a battery control unit 32, a battery 33, a mutual authentication unit 34, a component certificate 35, a secret communication unit 36, and a mutual authentication list 37.

The front wheel is the wheel at the front of the bicycle. The secure element 40 embedded in the front wheel includes a mutual authentication unit 41, a part certificate 42, a mutual authentication list 43, and a secret communication unit 44.

The rear wheel is the wheel at the rear of the bicycle. The secure element 50 embedded in the rear wheel includes a mutual authentication unit 51, a part certificate 52, a mutual authentication list 53, and a secret communication unit 54.

The frame is the body of the bicycle and is the basic component into which each component is assembled to create a complete bicycle. The secure element 60 embedded in the frame includes a mutual authentication unit 61, a component certificate 62, a mutual authentication list 63, and a secret communication unit 64.

Next, the secure elements built into each component will be explained using the secure element 11 built into the shifter 10 as an example. Note that the other secure elements are similar, so explanations of the other secure elements will be omitted.

The mutual authentication unit 16 has a function for performing mutual authentication with a secure element incorporated in another component. The component certificate 17 is a data set that stores manufacturing information (ID, etc.) of the component in which the secure element is incorporated, and the component's individual public key and public key signature. The secret communication unit 18 has a function for performing secret communication between the bicycle management server 200 and the secure element 11. The mutual authentication list 19 represents mutual authentication information and is a list of components for which mutual authentication should be performed and a flag (mutual authentication flag) indicating whether mutual authentication has been completed for that component. The mutual authentication information is information that associates mutual authentication targets with mutual authentication results.

The keys used by the secure element 11 are a public key (also called a "part public key"), a private key (also called a "part private key"), a secret communication key, and a CA public key. The public key is a key for verifying a signature during mutual authentication. The public key is distributed to the secure elements of other parts to be used to verify the signature generated by the secure element itself. The private key is a key for generating a signature during mutual authentication. The secret communication key is a key for the bicycle management server 200 and the secure element to perform secret communication. The CA public key is a key made public by the CA (Certificate Authority) that signed the public key, and is a key for verifying the public key distributed using a public key certificate. The public key certificate of this embodiment includes data in which the part public key and part information are signed with the CA private key held by the CA. As a result, even if a fraudulent part that falsely claims to be a manufacturer uses a fake public key or part information, it is possible to detect that the data is fraudulent due to the confidentiality of the CA private key.

Figure 3 is a schematic diagram showing an example of the procedure for creating a public key TrustChain. Each process in the diagram will be explained below as #1 to #9.

#1 (Generating part information): The parts factory generates information on the part name, ID, etc., into which the secure element will be embedded, as one piece of part information.

#2 (Provision of component information): The component factory provides the generated component information to the secure element factory.

#3 (Generate a key pair for components): The secure element factory generates a new key pair and assigns it to the component information received.

#4 (CSR generation): The secure element factory compiles the generated component public key and component information and sends it to the CA as a CSR (Certificate Signing Request).

#5 (Signature generation using CA private key): The CA uses its own private key to generate a signature for the component public key and the entire component information.

#6 (Return of signature): The CA returns the generated signature to the secure element factory.

#7 (Generate component certificate): The secure element factory generates a component certificate by combining the component information, public key (component public key), and public key signature.

#8 (Write to secure element): The secure element factory writes the part certificate, the CA public key obtained from the CA, and the part private key corresponding to the part to the secure element.

#9 (Providing a secure element): The secure element factory provides the secure element after programming has been completed to the parts factory. The parts factory incorporates (embeds) the secure element into the parts.

The TrustChain creation procedure does not necessarily have to be carried out in the order illustrated in Figure 3. Various procedures can be used to make it difficult to forge public keys, signatures, IDs, etc.

The bicycle management server 200 comprises a parts DB access unit 210, a network communication unit 220, and a secret communication unit 230. The network communication unit 220 has a function for performing network communication with the bicycle 100. The parts DB access unit 210 has a function for accessing the bicycle parts DB 250 and for reading and updating keys, etc. The secret communication unit 230 has a function for opening a secret communication path with a secure element built into each part of the bicycle 100 using a secret communication key.

The bicycle parts DB 250 stores a bicycle table 251 that records the configuration of a completed bicycle using the IDs of the parts for each bicycle frame, and the public keys, private keys, and secret communication keys of the parts linked to each ID. The configuration of the bicycle parts DB 250 is not limited to the example in Figure 1. For example, the public keys of parts may be stored in a distributed manner, such as by parts manufacturer.

Next, we will explain the processing of the information processing system in this embodiment.

In this embodiment, after each component is assembled, mutual authentication processing is executed between the components at the user's command, and the execution result can be configured to be recorded in the mutual authentication list of each secure element. There are three patterns for combinations of components during mutual authentication: (1) electric component-electric component, (2) electric component-non-electric component, and (3) non-electric component-non-electric component. For electric component-electric component combinations, mutual authentication is performed by sending a command from one electric component to the other electric component. For electric component-non-electric component combinations, mutual authentication is performed by sending a command from the electric component to the non-electric component. For non-electric component-non-electric component combinations, mutual authentication is performed by sending a command from the mutual authentication intermediary unit 13 to both non-electric components. The mutual authentication processing for each pattern is explained below.

Figure 4 is a schematic diagram showing an example of the command exchange flow between electric components. Each process in the diagram will be explained below as #1 to #11.

#1 (User's mutual authentication instruction): The user inputs a mutual authentication instruction to the shifter 10. The user's instruction is transmitted to the control unit 12 of the shifter 10.

#2 (Instruction to start mutual authentication to the secure element 11 on the shifter 10 side): Triggered by user input, the control unit 12 instructs its own secure element 11 to generate a mutual authentication command.

#3 (Command generation): Upon receiving a command to perform mutual authentication from the control unit 12, the secure element 11 generates a command to perform mutual authentication. At this time, the mutual authentication list 19 is searched for components that require mutual authentication, and commands are generated for components for which authentication has not been completed. In the example of FIG. 4, it is assumed that authentication for components other than the battery 30 has been completed (indicated by the symbol O), and a command for the battery 30 is generated.

#4 (Sending a command to the control unit 12): The secure element 11 sends the generated command to the control unit 12. At this time, it also notifies the control unit 12 of the destination of the command (here, the battery 30).

#5 (sending a command to the battery 30): The control unit 12 sends the command generated by the secure element 11 to the destination specified by the secure element 11. In this case, the destination is the battery 30, so the control unit 12 sends the command to the battery 30. The battery control unit 32 of the battery 30 receives the mutual authentication command from the control unit 12.

#6 (sending a command to the secure element 31 on the battery 30 side): The battery control unit 32 passes the received mutual authentication command to its own secure element 31.

#7 (command processing + response generation): The secure element 31 of the battery 30 processes the received mutual authentication command and generates a response.

#8 (output of response): The secure element 31 passes the response to the battery control unit 32.

#9 (Returning response to shifter 10): The battery control unit 32 returns the received response to the shifter 10.

#10 (Returning a response to the secure element 11 on the shifter 10 side): The control unit 12 of the shifter 10 returns the response received from the battery control unit 32 to the secure element 11.

#11 (Response processing and generation of next command): The secure element 11 processes the response received from the control unit 12. If necessary, it can generate a subsequent command and repeat command exchange until the mutual authentication process is completed.

Figure 5 is a schematic diagram showing an example of a command exchange flow between an electrically powered component and a non-electrical component. The following describes the process using the derailleur 20 as an example of an electrically powered component and the rear wheel as an example of a non-electrical component. Below, each process in the diagram will be described as #1 to #11.

#1 (User's mutual authentication instruction): The user inputs a mutual authentication instruction to the shifter 10. The user's instruction is transmitted to the control unit 12 of the shifter 10.

#2 (mutual authentication instruction to derailleur 20): The control unit 12 of the shifter 10 instructs the derailleur 20 to perform mutual authentication of the derailleur 20 itself.

#3 (derailleur control unit 22 receives instruction): The derailleur control unit 22 receives an instruction from the shifter 10 to perform mutual authentication.

#4 (command generation instruction to the secure element 21 on the derailleur 20 side): The derailleur control unit 22 instructs its own secure element 21 to generate a mutual authentication command.

#5 (Command generation): Upon receiving a command from the derailleur control unit 22, the secure element 21 generates a command to perform mutual authentication. At this time, it searches the mutual authentication list 26 for parts that require mutual authentication, and generates commands for parts for which authentication has not been completed. In the example of FIG. 5, it is assumed that authentication for parts other than the rear wheel has been completed (indicated by the symbol O), and a command for the rear wheel is generated.

#6 (Sending a command to the derailleur control unit 22): The secure element 21 sends the generated command to the derailleur control unit 22. At this time, it also notifies the derailleur control unit 22 of the destination of the command (here, the rear wheel).

#7 (sending a command to the secure element 50 of the rear wheel): The derailleur control unit 22 sends the command generated by the secure element 21 to the destination specified by the secure element 21. In this case, since the destination is the rear wheel, the derailleur control unit 22 sends the command to the rear wheel. The secure element 50 of the rear wheel receives the mutual authentication command from the derailleur control unit 22.

#8 (command processing + response generation): The secure element 50 in the rear wheel processes the received mutual authentication command and generates a response.

#9 (Response output): The secure element 50 of the rear wheel passes the response to the derailleur control unit 22.

#10 (Returning a response to the secure element 21 on the derailleur 20 side): The derailleur control unit 22 returns the response received from the secure element 50 to its own secure element 21.

#11 (Response processing and generation of next command): The secure element 21 processes the response received from the derailleur control unit 22. If necessary, it can generate a subsequent command and repeat command exchange until the mutual authentication process is completed.

As mentioned above, unlike the secure elements of electrically-operated components, the secure elements of non-electrical components are connected directly without going through the control unit of the component, and the control unit of the electrically-operated component sends and receives commands directly to the secure elements of the non-electrical components.

Figure 6 is a schematic diagram showing an example of a command exchange flow between non-electric components. In mutual authentication between non-electric components, since the secure element built into the non-electric component does not have an active communication function, mutual authentication can be performed using the command intermediation function of the electric component. Here, the procedure for mutual authentication between the front wheel and the frame via the mutual authentication intermediation unit 13 of the shifter 10 is explained. Each process in the diagram is explained below as #1 to #15.

#1 (User's mutual authentication instruction): The user inputs a mutual authentication instruction to the shifter 10. The user's instruction is transmitted to the control unit 12 of the shifter 10.

#2 (command generation instruction to mutual authentication intermediary unit 13): The control unit 12 of the shifter 10 instructs the mutual authentication intermediary unit 13 to mediate mutual authentication between non-electric components.

#3 (Generation of mutual authentication instruction command): The mutual authentication mediation unit 13 identifies two non-electric parts for which mutual authentication should be mediated, and then generates a command (mutual authentication instruction command) to mutually authenticate both parts. Here, after identifying the front wheel and frame, which are non-electric parts, it decides to send commands in the order of front wheel → frame, and first generates a mutual authentication instruction command for the front wheel.

#4 (output of mutual authentication command): The mutual authentication intermediary unit 13 passes the mutual authentication command for the front wheel to the control unit 12 of the shifter 10 along with the command destination (front wheel).

#5 (Sending a command to the secure element 40): The control unit 12 of the shifter 10 sends a mutual authentication instruction command to the secure element 40 of the front wheel.

#6 (Processing of mutual authentication command): When the front wheel secure element 40 receives the mutual authentication command, it processes the mutual authentication command and generates a response to be transferred to the mutual authentication intermediary unit 13 or the frame secure element 60.

#7 (sending mutual authentication instruction response): The secure element 40 of the front wheel sends a response to the control unit 12 of the shifter 10.

#8 (Transfer to mutual authentication intermediary unit 13): The control unit 12 of the shifter 10 transfers the response to the mutual authentication intermediary unit 13.

#9 (Response processing and generation of mutual authentication instruction command): The mutual authentication intermediary unit 13 analyzes the received response and generates a mutual authentication instruction command for the frame based on the information obtained from the response.

#10 (output of mutual authentication command): The mutual authentication intermediary unit 13 passes the mutual authentication command for the frame along with the command destination (frame) to the control unit 12 of the shifter 10.

#11 (Sending a command to the secure element 60): The control unit 12 of the shifter 10 sends a mutual authentication instruction command to the secure element 60 of the frame.

#12 (Processing of mutual authentication command): When the frame's secure element 40 receives the mutual authentication command, it processes the mutual authentication command and generates a response to be transferred to the mutual authentication intermediary unit 13 or the front wheel's secure element 40.

#13 (sending mutual authentication instruction response): The secure element 60 of the frame sends a response to the control unit 12 of the shifter 10.

#14 (Transfer to mutual authentication intermediary unit 13): The control unit 12 of the shifter 10 transfers the response to the mutual authentication intermediary unit 13.

#15 (Response processing and generation of mutual authentication instruction command): The mutual authentication intermediary unit 13 analyzes the received response. If a subsequent command is required, it can generate a mutual authentication instruction command for the front wheel again and repeat the process until mutual authentication is completed.

The mutual authentication mediation unit 13 can determine the identification and order of components when mediating mutual authentication as appropriate. For example, various applications are possible, such as (1) referring to the mutual authentication list of its own secure element and the secure elements in other components, (2) comparing each mutual authentication list and creating a list of pairs of components that require mutual authentication, and (3) performing mutual authentication in order from the top of the list.

Based on the flows shown in Figures 4 to 6, it is possible to send and receive commands and exchange information between secure elements in each part of the bicycle 100, regardless of the combination of electric and non-electric parts.

The specific encryption algorithms used in the mutual authentication can be determined as appropriate, but in this embodiment, mutual authentication using asymmetric keys consisting of a component public key, a certificate, a private key, and a CA public key is used as an example. The following describes a method for performing mutual authentication based on the exchange of commands.

Figure 7 is a schematic diagram showing an example of the flow of mutual authentication when commands are exchanged primarily with an electric component. Here, the process is explained when commands are exchanged primarily with an electric component, such as between electric components, or between an electric component and a non-electric component. The explanation will be given using the derailleur 20 as an example of an electric component, and the rear wheel as an example of a non-electric component. Below, each process in the diagram will be explained as #1 to #15.

#1 (command generation instruction from derailleur control unit 22): The derailleur control unit 22 instructs the secure element 21 on the derailleur 20 side to generate a mutual authentication command.

#2 (Generating a data string to be signed): When the secure element 21 of the derailleur 20 receives an instruction to generate a mutual authentication command, it prepares a data string that concatenates the ID of the derailleur 20 and a random number that it has generated as the data to be signed.

#3 (Signing with a private key): The secure element 21 uses its own private key to generate a signature for the data to be signed.

#4 (Generation of command transmission data): The secure element 21 concatenates its own component public key and public key signature in addition to the ID, random number, and signature to generate command transmission data.

#5 (Sending command): The secure element 21 sends the command to the secure element 50 on the rear wheel side via the derailleur control unit 22.

#6 (Component public key signature verification using CA public key): When the rear wheel secure element 50 receives the command, it uses the CA public key it holds to verify the signature of the component public key in the command. If the signature verification fails, the component public key in the command cannot be trusted, so the mutual authentication flag of the component specified by the ID in the mutual authentication list 53 is updated to unauthenticated (represented by the sign x), and processing ends here.

#7 (Signature verification using component public key): The secure element 50 of the rear wheel performs signature verification on the command data (ID + random number) using the component public key for which signature verification was successful. If signature verification fails, there is a possibility that the command has been tampered with, so the mutual authentication flag of the component specified by the ID in the mutual authentication list 53 is updated to unauthenticated (represented by the symbol x), and processing ends here.

#8 (updating the mutual authentication flag in the mutual authentication list 53): If the signature verifications in both steps #6 and #7 are successful, the rear wheel secure element 50 searches its own mutual authentication list 53 and updates the mutual authentication flag of the part with the ID specified in the command. Here, the mutual authentication flag of the derailleur 20 is updated to indicate authentication is complete (represented by the symbol x → O). Note that if the specified ID is not found, the command is for a part not included in the mutual authentication list, so the mutual authentication flag is not updated and processing ends here.

#9 (Generate data string to be signed): The secure element 50 of the rear wheel prepares a data string that concatenates the ID of the rear wheel and a random number that it has generated as the data to be signed.

#10 (Signing with a private key): The secure element 50 uses its own private key to generate a signature for the data to be signed.

#11 (Generate response return data): The secure element 50 concatenates its own component public key and public key signature in addition to the ID, random number, and signature to generate response return data.

#12 (sending response): The secure element 50 sends a response to the secure element 21 of the derailleur 20 via the derailleur control unit 22.

#13 (Component public key signature verification using CA public key): When the secure element 21 of the derailleur 20 receives the response, it uses the CA public key it holds to verify the signature of the component public key in the response. If the signature verification fails, the component public key in the response cannot be trusted, so the mutual authentication flag of the component specified by the ID in the mutual authentication list 26 is updated to unauthenticated (represented by the sign x), and processing ends here.

#14 (Signature verification using component public key): The secure element 21 of the derailleur 20 performs signature verification on the response data (ID + random number) using the component public key for which signature verification was successful. If signature verification fails, there is a possibility that the response has been tampered with, so the mutual authentication flag of the component specified by the ID in the mutual authentication list 26 is updated to unauthenticated (represented by the symbol x), and processing ends here.

#15 (updating the mutual authentication flag in the mutual authentication list 26): If the secure element 21 of the derailleur 20 is successful in both signature verifications in steps #13 and #14, it searches its own mutual authentication list 26 and updates the mutual authentication flag of the part with the ID specified in the response. In this case, it updates the mutual authentication flag of the rear wheel to indicate that authentication has been completed (represented by the symbol x → O). Note that if the specified ID is not found, the response is for a part not included in the mutual authentication list, so the mutual authentication flag is not updated and processing ends here.

Figure 8 is a schematic diagram showing an example of the flow of mutual authentication when sending and receiving commands between non-electric parts. Here, the front wheel and frame are used as examples of non-electric parts. Each process in the diagram will be explained below as #1 to #26.

#1 (command generation instruction from the control unit 12 of the shifter 10): The control unit 12 of the shifter 10 instructs the mutual authentication intermediary unit 13 to generate a mutual authentication command.

#2 (Command generation): The mutual authentication mediation unit 13 selects the part to perform mutual authentication and generates a command for mutual authentication. Here, it mediates authentication between the front wheel and the frame, and generates a mutual authentication command to send to the front wheel.

#3 (return of command): The mutual authentication intermediary unit 13 returns the command destination (front wheel) and the command to the control unit 12 of the shifter 10.

#4 (Sending a command to the secure element 40): The control unit 12 of the shifter 10 sends a command to the secure element 40 on the front wheel side.

#5 (Generate data string to be signed): The secure element 40 of the front wheel prepares a data string that concatenates the ID of the front wheel and a random number that it has generated as the data to be signed.

#6 (Signing with a private key): The secure element 40 uses its own private key to generate a signature for the data to be signed.

#7 (Generate response transmission data): The secure element 40 concatenates its own component public key and public key signature in addition to the ID, random number, and signature to generate response transmission data.

#8 (sending response): The secure element 40 sends a response to the control unit 12 of the shifter 10.

#9 (Return to mutual authentication intermediary unit 13): The control unit 12 of the shifter 10 returns a response to the mutual authentication intermediary unit 13.

#10 (Response processing and command generation): The mutual authentication intermediary unit 13 analyzes the received response and generates a command by setting the response data as the command data for the command to be sent to the frame.

#11 (return of command): The mutual authentication intermediary unit 13 returns the command destination (here, a frame) and the command to the control unit 12 of the shifter 10.

#12 (Sending command to secure element 40): The control unit 12 of the shifter 10 sends a command to the secure element 60 of the frame.

#13 (Component public key signature verification using CA public key): When the secure element 60 of the frame receives a command, it uses the CA public key it holds to verify the signature of the component public key in the command. If the signature verification fails, the component public key in the command cannot be trusted, so the mutual authentication flag of the component specified by the ID in the mutual authentication list 63 is updated to unauthenticated (represented by the symbol x), and processing ends here.

#14 (Signature verification using component public key): The secure element 60 performs signature verification on the command data (ID + random number) using the component public key for which the signature verification was successful. If the signature verification fails, there is a possibility that the command has been tampered with, so the mutual authentication flag of the component specified by the ID in the mutual authentication list 63 is updated to unauthenticated (represented by the symbol x), and processing ends here.

#15 (updating the mutual authentication flag in the mutual authentication list 63): If the signature verifications in both steps #13 and #14 are successful, the secure element 60 searches its own mutual authentication list 63 and updates the mutual authentication flag of the part with the ID specified in the command. Here, the mutual authentication flag of the front wheel is updated to indicate authentication is complete (represented by the symbol x → O). Note that if the specified ID is not found, the command is for a part not included in the mutual authentication list, so the mutual authentication flag is not updated and processing ends here.

#16 (Generate data string to be signed): The secure element 60 prepares a data string that concatenates the frame ID and a random number that it has generated as the data to be signed.

#17 (Signing with a private key): The secure element 60 uses its own private key to generate a signature for the data to be signed.

#18 (Generate response transmission data): The secure element 60 concatenates its own component public key and public key signature in addition to the ID, random number, and signature to generate response transmission data.

#19 (sending response): The secure element 60 sends a response to the control unit 12 of the shifter 10.

#20 (Return to mutual authentication intermediary unit 13): The control unit 12 of the shifter 10 returns a response to the mutual authentication intermediary unit 13.

#21 (Response processing and command generation): The mutual authentication intermediary unit 13 analyzes the received response and generates a command by setting the response data as the command data for the command to be sent to the front wheel.

#22 (return of command): The mutual authentication intermediary unit 13 returns the command destination (here, the front wheel) and the command to the control unit 12 of the shifter 10.

#23 (Sending command to secure element 40): The control unit 12 of the shifter 10 sends a command to the secure element 40 of the front wheel.

#24 (Component public key signature verification using CA public key): When the secure element 40 of the front wheel receives a command, it uses the CA public key it holds to verify the signature of the component public key in the command. If the signature verification fails, the component public key in the command cannot be trusted, so the mutual authentication flag of the component specified by the ID in the mutual authentication list 43 is updated to unauthenticated (represented by the sign x), and processing ends here.

#25 (Signature verification using component public key): The secure element 40 performs signature verification on the command data (ID + random number) using the component public key for which the signature verification was successful. If the signature verification fails, there is a possibility that the command has been tampered with, so the mutual authentication flag of the component specified by the ID in the mutual authentication list 43 is updated to unauthenticated (represented by the symbol x), and processing ends here.

#26 (updating the mutual authentication flag in the mutual authentication list 43): If the signature verifications in both processes #24 and #25 are successful, the secure element 40 searches its own mutual authentication list 43 and updates the mutual authentication flag of the component with the ID specified in the command. Here, the mutual authentication flag of the frame is updated to indicate authentication completion (represented by the symbol x → O). Note that if the specified ID is not found, the command is for a component not included in the mutual authentication list, so the mutual authentication flag is not updated and processing ends here.

As described above, the secure component performs mutual authentication with other secure components via a communication unit that transmits and receives information to and from other secure components mounted in other components used in the vehicle, and stores the mutual authentication information. Since mutual authentication is performed by the secure components between components that mount the secure components, it is possible to verify whether each component is connected via the communication unit in a predetermined appropriate combination, which makes it possible to prevent stolen goods from being mixed into components used in the vehicle, thereby effectively protecting the components.

In addition, a secure component receives a calculation result encrypted by another secure component with a mutual authentication private key, and performs mutual authentication based on the decryption result obtained by decrypting the received calculation result with a mutual authentication public key. Each secure component holds its own public key and private key. This enables mutual authentication between components to be achieved, rather than one-sided authentication.

The secure component also stores mutual authentication information with a specified secure component mounted on a specified part used in the vehicle, and when mutual authentication with the specified secure component is complete, outputs permission to operate the part in which it is mounted. For example, when the mutual authentication information stored in the secure component of part A indicates that mutual authentication with one or more specified parts is complete, the operation of part A is permitted, and when mutual authentication is not complete (failed), the operation of part A is not permitted. In this way, by not allowing the operation of a vehicle with an inappropriate configuration that combines stolen goods, etc., stolen goods are rendered ineffective as parts, and theft can be indirectly suppressed.

When mutual authentication is performed by sending and receiving commands initiated by electric parts, one secure element generates a command and the other secure element returns a response in response to the generated command. However, when mutual authentication between non-electric parts is performed via the mutual authentication intermediary unit 13, the mutual authentication intermediary unit 13 generates commands for each secure element individually and uses the generated commands to encourage information exchange between the two secure elements.

Figure 9 is a schematic diagram showing an example of the flow of component operation control when mutual authentication is complete. When mutual authentication of each component is complete, for example, with regard to an electrically-operated component, a circuit or function can be configured to inquire of the secure element whether or not it can operate when the component starts to operate, and to operate only if operation is permitted by the secure element. The following explanation uses the shifter 10 as an example. Also, each process in the diagram will be explained as #1 to #4.

#1 (Inquiry about operation): The control unit 12 of the shifter 10 inquires of the secure element 11 about whether it is operational. The inquiry may be made, for example, by sending a specific command.

#2 (Checking the mutual authentication list 19): The secure element 11 checks the mutual authentication list 19 and checks that mutual authentication has been completed for all parts for which it should perform mutual authentication. In this case, the mutual authentication list 19 lists the frame, derailleur 20, front wheel, rear wheel, and battery 30 as parts other than the shifter 10, so the parts for which mutual authentication should be performed are the frame, derailleur 20, front wheel, rear wheel, and battery 30. Depending on the mode of use, it may be dynamically set that some parts, rather than all parts listed in the mutual authentication list, are parts for which mutual authentication should be performed.

#3 (Reply indicating whether operation is possible): If mutual authentication has been completed for all components in the mutual authentication list 19, the secure element 11 returns a response indicating that operation is possible. If authentication has not been completed for some or all of the components (not authenticated), the secure element 11 returns a response indicating that operation is not possible.

#4 (Start of operation): The control unit 12 controls its own functions to operate only if it receives a reply indicating that operation is possible.

For non-electrical components, it may be difficult to control whether the component operates independently, but a mechanism may be used in which a power is supplied from an electric component to release a physical lock in response to user input at the start of operation, or an electric component that is closely related to or linked to the function of the non-electrical component may be configured to control the component instead.

If the above-mentioned mechanism for controlling part operation is applied to a bicycle, even if a thief steals some of the bicycle's parts and sells them, they will not be able to be used in combination with other parts (with the stolen parts mixed in), which will prevent theft at the part level.

On the other hand, there may of course be cases where the bicycle owner wishes to replace a part of their own volition, or where a part is replaced through proper means by a mechanic, etc. The bicycle needs to be able to function normally even after going through such use cases. Below, we will explain the functions that deal with such cases.

Figure 10 is a schematic diagram showing an example of the flow of updating the mutual authentication list via a secret communication channel. Below, as an example, a case where frames are exchanged by regular means is explained. Each process in the figure is explained as #1 to #12.

#1 (Replacing a part): A user (bicycle owner, mechanic, etc.) replaces a bicycle part with a new part. In this case, frame E from company B is replaced with frame V from company F.

#2 (Updating bicycle parts DB 250): The user contacts the administrator of the bicycle management server 200 and requests that the contents of the bicycle parts DB 250 be updated. The administrator receives the request and updates the bicycle parts DB 250. Here, the body ID in the bicycle table 251 for the bicycle 100 in question is updated from ID: 246246 in Company B's Frame E to ID: 147147 in Company F's Frame V, and the corresponding key pair, etc. (public key, public key signature, private key, secret communication key) are also updated.

#3 (Mutual authentication list update instruction): The user inputs an instruction to update the mutual authentication list in response to a part replacement to the shifter 10 via the input I/F.

#4 (Notification to control unit 12): The input I/F notifies the control unit 12 of an instruction to update the mutual authentication list.

#5 (Investigation of mutual authentication list update target): The control unit 12 obtains the part for which the mutual authentication list is to be updated from the secure element 11 built into itself.

#6 (mutual authentication list update request): The control unit 12 sends a mutual authentication list update request to the bicycle management server 200 via the network communication unit 14. At this time, the parts list to be updated in the mutual authentication list is also sent.

#7 (Obtaining a secret communication key for parts to be updated): The bicycle management server 200 references the parts list to be updated in the mutual authentication list, and opens a secret communication path for each part in the parts list other than the replaced part, and updates it. Here, the mutual authentication list 19 of the shifter 10 is updated first, and the secret communication key of the shifter 10 is obtained.

#8 (Instruction to open a secret communication path): The bicycle management server 200 passes the secret communication key for the part to the secret communication unit 230 and instructs it to open a secret communication path.

#9 (Establishing a secret communication path with the part to be updated): The secret communication unit 230 of the bicycle management server 200 uses the secret communication key of the shifter 10 to establish a secret communication path with the secret communication unit 18 in the secure element 11 inside the shifter 10 (this allows communication via the bicycle management server 200, the network communication unit 14 of the shifter 10, and the control unit 12).

#10 (updating the mutual authentication list): The bicycle management server 200 accesses the mutual authentication list 19 of the secure element 11 via the opened secret communication path and updates the part ID of the replaced part. In this case, since a frame has been replaced, the part ID of the part type frame is updated from 246246 to 147147.

#11 (updating mutual authentication lists for other parts): From then on, processes #6 to #9 are repeated for the remaining parts via the communication path within the bicycle 100 to update the mutual authentication lists 26, 37, 43, and 53. Here, for the replaced frame and parts other than the shifter 10 that have already been updated in the above process, individual secret communication paths are opened between the bicycle management server 200 and each secure element, and the part IDs of the frames are updated in the same way.

#12 (Writing mutual authentication list for replaced part): Finally, the bicycle management server 200 opens a secret communication path with the replaced part (frame) and writes the mutual authentication list 63 that lists the parts with which the replaced part should perform mutual authentication.

Figure 11 is a schematic diagram showing an example of a mutual authentication list after updating of parts other than the shifter 10. As shown in the figure, the part ID of the frame part type in the mutual authentication lists 26, 37, 43, and 53 for the secure element 21 of the derailleur 20, the secure element 31 of the battery 30, the secure element 40 of the front wheel, and the secure element 50 of the rear wheel has been updated from 246246 to 147147. In addition, a mutual authentication list 63 has been written to the secure element 60 of the newly replaced frame.

Any method can be used to update the auto parts DB250 as long as it can verify the authenticity of the user. For example, various methods can be used, such as contacting the user by phone or submitting an update form via a Web I/F.

By operating the mutual authentication list as described above, it is possible to prevent the risk of theft of individual parts. Below, we explain the countermeasures to be taken if the entire bicycle is stolen. This will prevent not only the theft of parts, but also the theft of the complete bicycle.

Figure 12 is a schematic diagram showing an example of the flow of function suspension using the secret communication function. Below, each process in the diagram will be explained as #1 to #8.

#1 (Contact administrator): The user contacts the administrator of the bicycle management server 200 to inform them that the bicycle (completed bicycle) has been stolen.

#2 (Instruction to obtain secret communication key): The administrator instructs the bicycle management server 200 to obtain the secret communication key for the corresponding bicycle from the bicycle parts DB 250.

#3 (Obtaining a secret communication key): The parts DB access unit 210 of the bicycle management server 200 obtains the corresponding bicycle's secret communication key from the bicycle parts DB 250.

#4 (Instruction to open a secret communication path): The administrator instructs the bicycle management server 200 to open a secret communication path. Here, the administrator first instructs the bicycle management server 200 to open a secret communication path with the shifter 10.

#5 (Establishing a secret communication path): The bicycle management server 200 establishes a secret communication path via the network to the secure element 11 in the shifter 10 of the bicycle 100.

#6 (Disable mutual authentication flag): The bicycle management server 200 updates the mutual authentication flags of all components in the mutual authentication list 19 in the secure element 11 in the shifter 10 to unauthenticated (represented by the symbol x) via a secret communication channel.

#7 (Mutual authentication blocking): The bicycle management server 200 changes its internal state via a secret communication path so that the mutual authentication function of the secure element 11 always fails. Here, the key pair used for mutual authentication is updated to an invalid value to cause mutual authentication to fail.

#8 (Disabling for other secure elements): From then on, the bicycle management server 200 blocks mutual authentication processing for other secure elements by disabling the mutual authentication flag and updating the key pair used for mutual authentication to an invalid value via a secret communication path.

Figure 13 is a schematic diagram showing an example of disabling secure elements in components other than the shifter 10. As shown in the figure, the mutual authentication flags of all components in the mutual authentication lists 26, 37, 43, and 53 of the secure element 21 of the derailleur 20, the secure element 31 of the battery 30, the secure element 40 of the front wheel, and the secure element 50 of the rear wheel have been updated to unauthenticated (represented by the symbol x). In addition, the key pair used for mutual authentication has been updated to an invalid value.

To block mutual authentication, the internal state of the secure element can be changed so that mutual authentication does not succeed in a stolen vehicle. In this embodiment, the key pair is invalidated, but a separate internal state can be stored in the secure element, and mutual authentication can be configured to always fail by changing the internal state.

In the case of bicycles, they are not necessarily always powered. For example, network communication can be forcibly performed the moment power is applied, and notifications from the bicycle management server 200 can be forcibly received, or network communication can be performed at regular intervals while the bicycle is in operation. If configured in this way, the bicycle's functions can be stopped regardless of the thief's wishes.

In addition, even if the bicycle is stolen, if its functions are suddenly disabled, it could have serious consequences, such as causing a traffic accident, so the bicycle's functions can be disabled after it has been stopped for a certain period of time. This makes it possible to realize bicycles that are considerate of traffic.

On the other hand, even if a bicycle is stolen, there are situations in which it is not appropriate to disable the bicycle's functions. Examples include cases where there is a low risk of theft in a public situation and you want to avoid disabling the functions as much as possible (e.g., bicycle races), and cases where you want to continue using a stolen bicycle (an unauthenticated bicycle) due to an emergency or urgent business (e.g., when you want to move quickly). In these cases where the risk of theft is low or can only be tolerated, the mutual authentication function between bicycle parts can be temporarily disabled (mutual authentication processing is not required). This point is explained below.

Figure 14 is a schematic diagram showing an example of the flow of temporarily invalidating mutual authentication when using a secret communication channel. Below, each process in the diagram will be explained as #1 to #7.

#1 (Contact administrator): The user requests the administrator of the bicycle management server 200 to temporarily disable the mutual authentication function.

#2 (Instruction to obtain secret communication key): The administrator instructs the bicycle management server 200 to obtain the secret communication key for the corresponding bicycle from the bicycle parts DB 250.

#3 (Obtaining a secret communication key): The parts DB access unit 210 of the bicycle management server 200 obtains the corresponding bicycle's secret communication key from the bicycle parts DB 250.

#4 (Instruction to open a secret communication path): The administrator instructs the bicycle management server 200 to open a secret communication path. Here, the administrator first instructs the bicycle management server 200 to open a secret communication path with the shifter 10.

#5 (Establishing a secret communication path): The bicycle management server 200 establishes a secret communication path via the network to the secure element 11 in the shifter 10 of the bicycle 100.

#6 (Delete mutual authentication list): The bicycle management server 200 deletes each part designation from the mutual authentication list 19 in the shifter 10 via a secret communication channel. For convenience, the part names are crossed out in the figure.

#7 (Delete mutual authentication list of other secure elements): From then on, the bicycle management server 200 deletes each component designation from the mutual authentication list for other secure elements in the same way.

Figure 15 is a schematic diagram showing an example of temporary disabling of mutual authentication of secure elements in parts other than the shifter 10. As shown in the figure, the part designations in the mutual authentication lists 26, 37, 43, and 53 for the secure element 21 in the derailleur 20, the secure element 31 in the battery 30, the secure element 40 in the front wheel, and the secure element 50 in the rear wheel have been deleted. For convenience, the part names are crossed out in the figure.

If the mutual authentication list is empty, the mutual authentication units 16, 24, 34, 41, 51, 61 of each secure element enable the parts to operate without performing mutual authentication processing. As a result, for example, when conducting a bicycle race, the mutual authentication list for each bicycle part can be emptied before the start of the race, and the contents of the mutual authentication list can be rewritten (parts specified) after the race is over, making it possible to accommodate part replacement during the race. On the other hand, in the case of an emergency, for example, when it is not possible to open a secret communication path from the bicycle management server 200, an emergency button can be provided on the input I/F of the bicycle, and the parts can be temporarily enabled by operating the emergency button. This point will be explained below.

Figure 16 is a schematic diagram showing an example of the flow for temporarily disabling mutual authentication via an input I/F. Below, each process in the diagram will be explained as #1 to #5.

#1 (Instruction to temporarily disable mutual authentication): The user instructs the bicycle 100 to temporarily disable mutual authentication via its input I/F.

#2 (Notification to control unit 12): The input I/F of the bicycle 100 notifies the control unit 12 of the shifter 10 of an instruction to disable mutual authentication.

#3 (Instruction to disable mutual authentication to secure element): The control unit 12 instructs its own secure element 11 to temporarily disable mutual authentication.

#4 (Delete mutual authentication list): The secure element 11 deletes each component designation from the mutual authentication list 19. For convenience, the component names are crossed out in the figure.

#5 (Delete mutual authentication list of other secure elements): After this, the control unit 12 similarly deletes each component designation from the mutual authentication list for other secure elements.

Figure 17 is a schematic diagram showing an example of temporary disabling of mutual authentication of secure elements in parts other than the shifter 10. As shown in the figure, the part designations in the mutual authentication lists 26, 37, 43, and 53 for the secure element 21 in the derailleur 20, the secure element 31 in the battery 30, the secure element 40 in the front wheel, and the secure element 50 in the rear wheel have been deleted. For convenience, the part names are crossed out in the figure.

The function of temporarily disabling mutual authentication weakens the effectiveness of the bicycle theft prevention function, so in actual application, it is desirable to configure it in a way that takes into account the trade-off between the risk of theft and the risk of the bicycle being disabled in the event of emergency use, such as by limiting the number of times it can be disabled.

It is possible to attach an IC tag to each part of the bicycle to uniquely identify the bicycle and the parts, but simply linking the bicycle and the parts may ensure the traceability of the parts, but a third party who obtains a stolen vehicle or stolen parts can continue to use the stolen goods without any problems, so this is not an effective deterrent against theft. On the other hand, according to this embodiment, if there is a part that has not been mutually authenticated (an unauthenticated part), the bicycle's functions are stopped and it becomes inoperable, which is an effective deterrent against theft.

In this embodiment, a bicycle is used as an example of a vehicle, but bicycle parts are not limited to the parts in the above example, and other parts can be applied in the same manner. Furthermore, vehicles are not limited to bicycles, and can also be applied to motorcycles and automobiles. In the case of motorcycles, parts include, for example, exterior parts such as wheels, mufflers, lights, handlebars, frames, batteries, and seats. In the case of automobiles, parts include, for example, wheels, batteries, chargers, steering wheels, and on-board cameras.

Figure 18 is a schematic diagram showing an example of the configuration of the management system of this embodiment. In the following, an automobile will be described as an example of a vehicle, but the vehicle is not limited to an automobile. The management system includes a vehicle/vehicle parts management server 300 and a plurality of vehicles 400. Although three vehicles are illustrated in the figure, the number of vehicles is not limited to three. Each vehicle 400 is equipped with vehicle parts 410, 420, 430, and 440 each equipped with a secure element. Although four vehicle parts are illustrated in the figure for convenience, the number of vehicle parts is not limited to four. Furthermore, the vehicle parts 410 to 440 do not need to be the same parts in each vehicle 400. The vehicle parts may be different depending on the vehicle model, etc. A secret communication path can be established between the vehicle/vehicle parts management server 300 and the secure element installed in each vehicle part.

The vehicle/vehicle parts management server 300 includes a vehicle parts DB access unit 310, a network communication unit 320, and a secret communication unit 330. The vehicle parts DB access unit 310, the network communication unit 320, and the secret communication unit 330 have the same functions as the parts DB access unit 210, the network communication unit 220, and the secret communication unit 230 of the bicycle management server 200, respectively, and detailed explanations are omitted.

As in the case of the information processing system described above, the vehicle parts 410 to 440 of each vehicle 400 can perform mutual authentication using secure components and activate or stop the functions of the vehicle parts. In other words, the vehicle/vehicle parts management server 300 can perform comprehensive management such as mutual authentication using secure components, activation or stop of vehicle part functions, temporary disabling or enabling of mutual authentication, and updating of keys and certificates used for mutual authentication via a secret communication path. This makes it possible to prevent stolen goods from being mixed into vehicle parts used in vehicles, and effectively protect the vehicle parts.

In recent years, the development of mobility technology has attracted great interest, especially in the automotive industry. Mobility refers to activities related to movement in general, including not only automobiles but also public transportation, and a concept called MaaS (Mobility as a Service) has been attracting particular attention. MaaS is characterized by clouding transportation using ICT (Information and Communication Technology), treating mobility by all means of transportation as one service, and seamlessly connecting them. As the concept of MaaS spreads throughout society, new services will be created, such as dispatching cars by automatic driving, optimizing transportation, and using transportation information related to various means of transportation (cars, buses, trains, motorcycles, etc.) as big data, and the importance of parts (vehicle parts) used in these means of transportation is expected to increase. According to this embodiment, a useful management system or management method can be provided for such new services.

The secure component of this embodiment is a secure component mounted on a vehicle component used in a vehicle, and includes a communication unit that transmits and receives information to and from other secure components mounted on other vehicle components used in the vehicle, an authentication unit that performs mutual authentication with the other secure components via the communication unit, and a first storage unit that stores mutual authentication information that associates mutual authentication targets with mutual authentication results obtained by the authentication unit.

The computer program of this embodiment causes a computer to execute processing to transmit and receive information to and from a secure component mounted on a vehicle component used in a vehicle, to perform mutual authentication with the secure component, and to store mutual authentication information that associates mutual authentication targets with mutual authentication results.

The information processing method of this embodiment performs mutual authentication between secure components mounted on each of multiple vehicle components used in a vehicle, and each secure component stores mutual authentication information that associates mutual authentication targets with mutual authentication results.

The secure component performs mutual authentication with other secure components via a communication unit that transmits and receives information to and from other secure components mounted on other vehicle components used in the vehicle, and stores mutual authentication information that associates mutual authentication targets with mutual authentication results. The mutual authentication targets are secure components or vehicle components mounted with secure components. Since mutual authentication is performed by the secure components between vehicle components mounted with secure components, it is possible to verify whether each vehicle component is connected via the communication unit in a predetermined appropriate combination, which makes it possible to prevent stolen goods from being mixed into vehicle components used in the vehicle, and effectively protect the vehicle components.

In the secure component of this embodiment, the communication unit receives a calculation result encrypted by the other secure component with a mutual authentication private key, and the authentication unit performs mutual authentication based on the decryption result obtained by decrypting the calculation result with a mutual authentication public key.

A secure component receives a calculation result encrypted by another secure component with a mutual authentication private key, and performs mutual authentication based on the decryption result obtained by decrypting the received calculation result with a mutual authentication public key. Each secure component holds its own public key and private key. This enables mutual authentication between vehicle components to be achieved, rather than one-sided authentication.

In the secure component of this embodiment, the first storage unit stores mutual authentication information with a specific secure component mounted on a specific vehicle component used in the vehicle, and includes an output unit that outputs permission to operate the vehicle component in which the first storage unit is mounted when mutual authentication with the specific secure component is completed.

The secure component stores mutual authentication information with a specified secure component mounted on a specified vehicle component used in the vehicle, and when mutual authentication with the specified secure component is complete, outputs permission to operate the vehicle component in which it is mounted. For example, when the mutual authentication information stored in the secure component of vehicle component A indicates that mutual authentication with one or more specified vehicle components is complete, operation of the vehicle component A is permitted, and when mutual authentication is not complete (failure), operation of the vehicle component A is not permitted. In this way, by not allowing the operation of a vehicle with an inappropriate configuration that combines stolen goods, etc., stolen goods are rendered ineffective as vehicle parts, thereby indirectly suppressing theft.

The secure component of this embodiment is capable of updating the mutual authentication information stored in the first storage unit via a secret communication path established with an external server.

The secure component can update the stored mutual authentication information via a secret communication path established with an external server. For example, when a vehicle part is replaced by legitimate means, the mutual authentication information can be updated to correspond to that vehicle part. This provides a means for appropriate mutual authentication against the misappropriation of legitimate vehicle parts by mechanics or manufacturers.

The secure component of this embodiment is capable of updating at least one of the key and the certificate used in the mutual authentication via a secret communication path established with the external server.

The secure component can update at least one of the keys and certificates used for mutual authentication via a secret communication path established with an external server. This makes it possible to prevent mutual authentication between vehicle components from being performed remotely if the vehicle is stolen, thereby preventing theft.

The secure component of this embodiment includes a second storage unit that stores vehicle part information that can uniquely identify the vehicle part in which it is installed, and a vehicle part certificate that includes a public key and a public key signature for mutual authentication.

The secure component stores vehicle part information that can uniquely identify the vehicle part in which it is installed, and a vehicle part certificate that includes a public key for mutual authentication and a public key signature. For example, by using an asymmetric key (public key + certificate + private key) for the key used for mutual authentication and writing information as the manufacturing certificate of the part in the certificate, it is possible to provide a means for verifying the identity of the vehicle part after the fact, as well as a means for certifying the public key.

Mutual authentication between secure components can be achieved even if the vehicle parts equipped with the secure components are non-electrical parts.

The secure component of this embodiment includes one of a secure element, a trusted execution environment, or an IC tag.

The secure component comprises one of a secure element, a trusted execution environment, or an IC tag. That is, the secure component may be a secure element, which is a security chip with tamper resistance, or may be a trusted execution environment (also called TEE) divided within a SoC (System on Chip) by using, for example, a technology called CPU virtualization support technology (for example, TrustZone (registered trademark)) on the SoC, or may be an IC tag. This makes it possible to configure an appropriate secure component depending on the type of vehicle, vehicle part, etc.

The vehicle components in this embodiment are equipped with the aforementioned secure components.

Since the vehicle components are equipped with secure components, mutual authentication between the vehicle components can be performed by mutual authentication between the secure components, and it can be verified whether each vehicle component is connected in a predetermined appropriate combination. This makes it possible to prevent stolen goods from being mixed into vehicle components used in the vehicle, thereby effectively protecting the vehicle components.

The vehicle components of this embodiment are operable based on the operation permission output by the secure component.

In the information processing method of this embodiment, the operation of the vehicle components is determined based on mutual authentication information stored in the secure components installed in each of the vehicle components.

Vehicle parts are operable based on the operation permission output by the secure component. Vehicle parts are operable only when the necessary mutual authentication has been completed by the secure component. Therefore, by preventing the operation of vehicles with inappropriate configurations that incorporate stolen items, etc., stolen items are rendered ineffective as vehicle parts, thereby indirectly preventing theft.

In this embodiment, the vehicle component temporarily disables the mutual authentication function of the secure component based on an instruction received from the external server via a secret communication path established between the secure component and the external server.

The vehicle component temporarily disables the mutual authentication function of the secure component based on instructions received from the external server via a secret communication path established between the secure component and the external server. Temporarily disabling the mutual authentication function allows the vehicle to operate without mutual authentication, making it possible to respond to situations where there is a low risk of theft in public or where the risk of theft is acceptable or unavoidable due to an emergency or urgent business, etc.

The vehicle component of this embodiment can stop operating based on a function stop instruction from the external server via a secret communication path established between the secure component and the external server.

The vehicle components can be stopped from operating based on a function stop command from an external server via a secret communication path established between the secure component and the external server. If the vehicle is stolen, the operation of the vehicle components can be stopped remotely, and the stolen vehicle cannot be used. This makes it possible to prevent theft.

In this embodiment, the vehicle components temporarily activate their operation based on a user instruction from a reception unit installed in the vehicle.

Vehicle parts temporarily enable their operation based on user instructions from a reception unit installed in the vehicle. By issuing a specific user instruction to a disabled vehicle part, the part function is temporarily enabled and use as a vehicle is permitted. This provides a rescue means for moving to a safe location in the event of a disaster or when the vehicle becomes unusable due to an unforeseen incident.

The vehicle component of this embodiment includes a communication unit that transmits and receives information between a first secure component mounted on a first vehicle component used in a vehicle and a second secure component mounted on a second vehicle component used in the vehicle, and an authentication mediation unit that mediates mutual authentication between the first secure component and the second secure component via the communication unit.

When a first secure component mounted on a first vehicle component and a second secure component mounted on a second vehicle component cannot mutually authenticate each other (for example, when the first vehicle component and the second vehicle component are non-electrical components that do not have a control mechanism or an operating mechanism for actually operating the components, unlike electric components that have these mechanisms), an authentication intermediary unit provided in the electric components mediates the mutual authentication, thereby realizing mutual authentication between the first secure component and the second secure component. Even if the vehicle components equipped with secure components are non-electrical components, mutual authentication between the secure components can be realized, so that it is possible to verify whether each vehicle component is connected via the communication unit in a predetermined appropriate combination, and it is possible to prevent stolen goods from being mixed into vehicle components used in a vehicle, thereby effectively protecting the vehicle components.

In the vehicle parts of this embodiment, the first vehicle part and the second vehicle part each include a non-electric part.

The vehicle of this embodiment is equipped with multiple vehicle components as described above.

The vehicle is equipped with multiple vehicle parts. This makes it possible to create a vehicle that can prevent stolen goods from being mixed in.

The management system of this embodiment includes a server capable of establishing a secret communication path between the vehicle and a secure component mounted on each of a plurality of vehicle parts of the vehicle, and the server manages at least one of the vehicle parts and the vehicle based on mutual authentication via the secret communication path.

In the management method of this embodiment, a server capable of establishing a secret communication path between the server and a secure component mounted on each of the vehicle components of the vehicle manages at least one of the vehicle components and the vehicle based on mutual authentication via the secret communication path.

The server can manage mutual authentication by the secure components, activation or deactivation of functions of vehicle components, temporary deactivation or activation of mutual authentication, and updating of keys and certificates used for mutual authentication, etc., via a secret communication path between each secure component. This makes it possible to prevent stolen goods from being mixed into vehicle parts used in vehicles, and to effectively protect the vehicle parts.

LIST OF SYMBOLS 10 Shifter 11 Secure element 12 Control unit 13 Mutual authentication intermediary unit 14 Network communication unit 15 Shifter operation unit 16 Mutual authentication unit 17 Part certificate 18 Secret communication unit 19 Mutual authentication list 20 Derailleur 21 Secure element 22 Derailleur control unit 23 Derailleur drive unit 24 Mutual authentication unit 25 Part certificate 26 Mutual authentication list 27 Secret communication unit 30 Battery 31 Secure element 32 Battery control unit 33 Battery 34 Mutual authentication unit 35 Part certificate 36 Secret communication unit 37 Mutual authentication list 40 Secure element 41 Mutual authentication unit 42 Part certificate 43 Mutual authentication list 44 Secret communication unit 50 Secure element 51 Mutual authentication unit 52 Part certificate 53 Mutual authentication list 54 Secret communication unit 60 Secure element 61 Mutual authentication unit 62 Part certificate 63 Mutual authentication list 64 Secret communication unit 100 Bicycle 200 Bicycle management server 210 Part DB access unit 220 Network communication unit 230 Secret communication unit 250 Bicycle parts DB
251 Bicycle Table

Claims (18)

A secure component mounted on a vehicle component used in a vehicle,
a communication unit that transmits and receives information to and from other secure components mounted on other vehicle components used in the vehicle;
an authentication unit that performs mutual authentication with the other secure component via the communication unit;
a first storage unit that stores mutual authentication information in which a mutual authentication target and a mutual authentication result by the authentication unit are associated with each other ,
The first storage unit is
storing mutual authentication information with a predetermined secure component mounted on a predetermined vehicle component used in the vehicle;
and an output unit that outputs, when mutual authentication with the predetermined secure component is completed, an operation permission for a vehicle component in which the vehicle component is mounted .
Secure components. The communication unit is
receiving a calculation result calculated by the other secure component using a mutual authentication private key;
The authentication unit
performing mutual authentication based on the calculation result by using a public key for mutual authentication;
The secure component of claim 1 . the mutual authentication information can be updated by the external server accessing the mutual authentication information stored in the first storage unit via a secret communication path established between the external server and the external server;
A secure component according to claim 1 or 2 . storing at least one of a key and a certificate used for the mutual authentication, and enabling at least one of the key and the certificate to be updated via a secret communication path established with an external server;
A secure component according to any one of claims 1 to 3 . a second storage unit that stores vehicle part information that can uniquely identify a vehicle part on which the vehicle part is mounted, and a vehicle part certificate including a public key and a public key signature for mutual authentication;
A secure component according to any one of claims 1 to 4 . The device includes one of a secure element, a trusted execution environment, and an IC tag.
A secure component according to any one of claims 1 to 5 . A secure component according to any one of claims 1 to 6 ,
Vehicle parts. The secure component is operable based on an operation permission output by the secure component.
The vehicle component according to claim 7 . temporarily disabling a mutual authentication function performed by the secure component based on an instruction received from the external server via a secret communication path established between the secure component and the external server;
The vehicle component according to claim 7 or 8 . The operation of the secure component can be stopped based on a function stop instruction from an external server via a secret communication path established between the secure component and the external server.
The vehicle component according to any one of claims 7 to 9 . Temporarily enabling an operation based on a user instruction from a reception unit provided in the vehicle.
The vehicle component according to claim 8 . a communication unit that transmits and receives information between a first secure component mounted on a first vehicle component used in a vehicle and a second secure component mounted on a second vehicle component used in the vehicle;
an authentication intermediation unit that mediates mutual authentication between the first secure component and the second secure component via the communication unit ;
the first secure component;
Equipped with
The first secure component comprises:
a storage unit that stores mutual authentication information with the second secure component;
an output unit that outputs permission for operation of a vehicle part in which the second secure component is mounted when mutual authentication with the second secure component has been completed;
Equipped with
Vehicle parts. Each of the first vehicle component and the second vehicle component includes a non-electric component.
The vehicle component of claim 12 . A vehicle component according to any one of claims 7 to 13 ,
vehicle. On the computer,
Sending and receiving information between other secure components installed in vehicle components used in the vehicle,
Mutual authentication is performed with the other secure component;
storing mutual authentication information in which the mutual authentication subject and the mutual authentication result are associated with each other;
storing mutual authentication information with a predetermined secure component mounted on a predetermined vehicle component used in the vehicle;
When mutual authentication with the predetermined secure component has been completed, outputting permission for operation of the vehicle component in which the device is mounted.
A computer program that executes a process. Mutual authentication is performed between the other secure components installed in each of the multiple vehicle parts used in the vehicle ,
storing mutual authentication information in which the mutual authentication subject and the mutual authentication result are associated with each other;
storing mutual authentication information with a predetermined secure component mounted on a predetermined vehicle component used in the vehicle;
When mutual authentication with the predetermined secure component has been completed, outputting permission for operation of the vehicle component in which the device is mounted.
Information processing methods. the plurality of vehicle components determine whether or not to operate depending on whether or not mutual authentication based on mutual authentication information stored in a secure component mounted on each of the vehicle components has been completed .
The information processing method according to claim 16 . A vehicle according to claim 14 ;
a server capable of establishing a secret communication path between the server and a secure component mounted in each of a plurality of vehicle components provided in the vehicle,
The server,
Activating or deactivating functions of the plurality of vehicle parts based on mutual authentication via the secret communication path.
Management system.

Images