Secure component, vehicle part, vehicle, computer program, management system and information processing method

A secure component system in vehicle parts enables mutual authentication between components, ensuring only authorized parts operate together, effectively preventing theft by rendering stolen parts inoperable.

JP7615605B2Active Publication Date: 2025-01-17DAI NIPPON PRINTING CO LTD
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
JP2020176817
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2020-10-21
Publication Date
2025-01-17
Estimated Expiration
2040-10-21

AI Technical Summary

Technical Problem

Existing technologies do not effectively protect luxury vehicle parts from theft, as they focus primarily on preventing the theft of entire vehicles rather than individual components.

Method used

A secure component system is installed in vehicle parts that enables mutual authentication between components through a communication unit, authentication unit, and storage of mutual authentication information, allowing verification of appropriate combinations and preventing the mixing of stolen parts.

Benefits of technology

The system ensures that only properly authenticated parts can operate together, effectively preventing theft by rendering stolen parts inoperable and deterring theft by ensuring only authorized components are combined.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007615605000001
    Figure 0007615605000001
  • Figure 0007615605000002
    Figure 0007615605000002
  • Figure 0007615605000003
    Figure 0007615605000003
Patent Text Reader

Abstract

To provide a secure component that can effectively protect vehicle parts, vehicle parts, a vehicle, a computer program, a management system, an information processing method, and a management method.SOLUTION: A secure component mounted on a vehicle part used in a vehicle includes a communication unit that sends and receives information to and from another secure component mounted on another vehicle component used in the vehicle, an authentication unit that performs mutual authentication with the other secure component via the communication unit, and a first storage unit that stores mutual authentication information associated with a mutual authentication result by a mutual authentication target and the authentication unit.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates to a secure component, a vehicle part, a vehicle, a computer program, and a management system. and Information Processing By law Regarding. [Background technology]

[0002] There are many technical countermeasures against theft of vehicles such as bicycles. Patent Document 1 discloses a search device that stores crime prevention registration information online and prints a barcode on the crime prevention registration sticker attached to the bicycle, allowing the crime prevention registration information to be searched for by reading the barcode with a mobile terminal.

[0003] Furthermore, Patent Document 2 discloses a bicycle sharing system in which the bicycles are fitted with electronic locks that can be unlocked using short-range wireless communication with a mobile terminal. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2003-256960 A [Patent Document 2] JP 2015-113686 A Summary of the Invention [Problem to be solved by the invention]

[0005] On the other hand, high-end bicycles are becoming more and more popular with the popularity of sports bicycles. High-end bicycles are often traded in parts, just like automobiles and motorcycles, 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.

[0006] The present invention has been made in consideration of the above circumstances, and relates to a secure component, a vehicle component, a vehicle, a computer program, and a management system that can effectively protect vehicle components. and Information Processing Law The purpose is to provide. [Means for solving the problem]

[0007] 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 between 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 memory unit that stores mutual authentication information that associates a mutual authentication target with a mutual authentication result by the authentication unit.

[0008] A vehicle component according to an embodiment of the present invention includes the above-mentioned secure component.

[0009] 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 intermediation unit that mediates mutual authentication between the first secure component and the second secure component via the communication unit.

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

[0011] A computer program according to an embodiment of the present invention causes a computer to execute processing to send and receive information between a secure component installed in a vehicle component used in a vehicle, perform mutual authentication with the secure component, and store mutual authentication information that associates the mutual authentication target with the mutual authentication result.

[0012] An information processing method according to an embodiment of the present invention performs mutual authentication between secure components installed in each of a plurality of vehicle components used in a vehicle, and each secure component stores mutual authentication information that associates the mutual authentication target with the mutual authentication result.

[0013] A 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 equipped on 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.

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

[0015] According to the present invention, since it is verified whether vehicle parts are connected in a predetermined appropriate combination, it is possible to prevent the intrusion of stolen goods and the like, and to effectively protect the vehicle parts. [Brief description of the drawings]

[0016] [Figure 1] 1 is a schematic diagram illustrating an example of a configuration of an information processing system according to an embodiment of the present invention. [Diagram 2] 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. [Diagram 3] FIG. 1 is a schematic diagram showing an example of a procedure for creating a public key TrustChain. [Figure 4] FIG. 4 is a schematic diagram showing an example of a command transmission and reception flow between electric components. [Diagram 5]FIG. 4 is a schematic diagram showing an example of a command transmission and reception flow between an electric component and a non-electric component. [Figure 6] FIG. 13 is a schematic diagram showing an example of a command transmission and reception flow between non-electric components; [Figure 7] FIG. 13 is a schematic diagram showing an example of a flow of mutual authentication when commands are manually exchanged between electric components; [Figure 8] FIG. 11 is a schematic diagram showing an example of a flow of mutual authentication when a command is exchanged between non-electric components; [Figure 9] FIG. 11 is a schematic diagram illustrating an example of a flow of component operation control when mutual authentication is completed. [Figure 10] FIG. 11 is a schematic diagram showing an example of a flow of updating a mutual authentication list via a secure communication channel. [Figure 11] FIG. 13 is a schematic diagram showing an example of an updated mutual authentication list for a part other than a shifter. [Figure 12] FIG. 11 is a schematic diagram showing an example of a flow of function suspension by a secret communication function. [Figure 13] FIG. 13 is a schematic diagram showing an example of disabling a secure element in a part other than a shifter. [Figure 14] 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. [Figure 15] 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. [Figure 16] FIG. 13 is a schematic diagram showing an example of a flow of temporarily disabling mutual authentication via an input I / F. [Figure 17] 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. [Figure 18] FIG. 1 is a schematic diagram illustrating an example of a configuration of a management system according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] 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.

[0018] Bicycle 100 includes multiple components (vehicle components) with embedded secure elements. In the following description, secure elements are given 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 system on a chip (SoC) 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.

[0019] In the case of a typical (low-cost) bicycle, all of the bicycle functions using mechanical mechanisms (such as a wire for transmitting gear changes), 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 (frame, wheels, etc.), 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.

[0020] 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.

[0021] The shifter 10 is a gear shift instruction device, and is a device for instructing gear changes of 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.

[0022] In this embodiment, core functions for bicycle communication are incorporated in 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 enables 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 instruct the start of mutual authentication and network communication. These core functions mediate communication when mutual authentication of non-electric parts is performed or when communication is performed with an external network. Note that, although the shifter 10 has the core functions in this embodiment, other devices such as a cycle computer or smartphone may also have the core functions.

[0023] 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.

[0024] The battery 30 is a battery for supplying power to electrically-driven parts and includes a secure element 31, a battery control unit 32, a battery 33, a mutual authentication unit 34, a part certificate 35, a secret communication unit 36, and a mutual authentication list 37.

[0025] The front wheel is the wheel at the front of the bicycle. A 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.

[0026] The rear wheel is the wheel at the rear of the bicycle. A 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.

[0027] The frame is the body of the bicycle and is the basic component on which each component is assembled to complete the 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.

[0028] Next, the secure elements incorporated in each component will be described using as an example the secure element 11 incorporated in the shifter 10. Note that the other secure elements are similar, so descriptions of the other secure elements will be omitted.

[0029] The mutual authentication unit 16 has a function for performing mutual authentication with a secure element built into 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 built, 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.

[0030] The keys used by the secure element 11 are a public key (also referred to as a "component public key"), a private key (also referred to as a "component 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 components 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 secret communication between the bicycle management server 200 and the secure element. 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 component public key and component information are signed with a CA private key held by the CA. As a result, even if a fraudulent component that falsely claims to be a manufacturer uses a fake public key or component information, it is possible to detect that the data is fraudulent due to the confidentiality of the CA private key.

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

[0032] #1 (Generation of component information): The component factory generates information such as the name and ID of the component into which the secure element is to be embedded as a single piece of component information.

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

[0034] #3 (Generation of a key pair for components): The secure element factory generates a new key pair and uses it as a key pair corresponding to the received component information.

[0035] #4 (Generation of CSR): 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).

[0036] #5 (Signature generation using CA private key): The CA uses the private key it holds to generate a signature for the component public key and the entire component information.

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

[0038] #7 (Generation of component certificate): The secure element factory generates a component certificate by combining the component information, public key (component public key), and public key signature.

[0039] #8 (Writing 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 into the secure element.

[0040] #9 (Provision of secure element): The secure element factory provides the secure element for which programming has been completed to the component factory. The component factory incorporates (embeds) the secure element into the component.

[0041] Note that the procedure for creating a TrustChain does not necessarily have to be performed in the order illustrated in Figure 3. Various procedures can be used to make it difficult to forge public keys, signatures, IDs, etc.

[0042] 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 communicating with the bicycle 100 over a network. The parts DB access unit 210 has a function for accessing the bicycle parts DB 250 and 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.

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

[0044] Next, the processing of the information processing system according to this embodiment will be described.

[0045] 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 an electric component-electric component combination, mutual authentication is performed by sending a command from one electric component to the other electric component. For an electric component-non-electric component combination, mutual authentication is performed by sending a command from the electric component to the non-electric component. For a non-electric component-non-electric component combination, mutual authentication is performed by sending a command from the mutual authentication mediation unit 13 to both non-electric components. The mutual authentication processing for each pattern will be described below.

[0046] 4 is a schematic diagram showing an example of a command exchange flow between electrically-driven components. Each process in the diagram will be described below with the numbers #1 to #11.

[0047] #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.

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

[0049] #3 (Command generation): The secure element 11 receives a command to perform mutual authentication in response to a command generation instruction from the control unit 12. At this time, the secure element 11 searches the mutual authentication list 19 for components that require mutual authentication, and generates commands for components for which authentication has not been completed. In the example of Fig. 4, it is assumed that authentication of components other than the battery 30 has been completed (indicated by symbol O), and a command for the battery 30 is generated.

[0050] #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, the control unit 12 is also notified of the destination of the command (here, the battery 30).

[0051] #5 (Sending a command to the battery 30): The control unit 12 transmits the command generated by the secure element 11 to the destination specified by the secure element 11. In this case, since the destination is the battery 30, the control unit 12 transmits 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.

[0052] #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.

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

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

[0055] #9 (Return of response to shifter 10): The battery control unit 32 returns the received response to the shifter 10.

[0056] #10 (Return of response to 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.

[0057] #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.

[0058] 5 is a schematic diagram showing an example of a command exchange flow between an electrically powered component and a non-electrical component. The description will be given by taking the derailleur 20 as an example of an electrically powered component and the rear wheel as an example of a non-electrical component. Each process in the diagram will be described below as #1 to #11.

[0059] #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.

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

[0061] #3 (reception of instruction by derailleur control unit 22): The derailleur control unit 22 receives an instruction from the shifter 10 to perform mutual authentication.

[0062] #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.

[0063] #5 (Command generation): Upon receiving a command to generate a command from the derailleur control unit 22, the secure element 21 generates a command to perform mutual authentication. At this time, the secure element 21 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.

[0064] #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).

[0065] #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.

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

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

[0068] #10 (Return of response to 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.

[0069] #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.

[0070] As described above, unlike the secure elements of electric components, the secure elements of non-electric components are connected directly without going through the control unit of the component, and the control unit of the electric component sends and receives commands directly to the secure element of the non-electric component.

[0071] Fig. 6 is a schematic diagram showing an example of a command transmission and reception 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 will be explained. Each process in the figure will be explained below as #1 to #15.

[0072] #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.

[0073] #2 (command generation instruction to the mutual authentication mediation unit 13): The control unit 12 of the shifter 10 instructs the mutual authentication mediation unit 13 to mediate mutual authentication between non-electrical parts.

[0074] #3 (Generation of a 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) for mutually authenticating both parts. Here, after identifying the front wheel and the frame, which are non-electric parts, it decides to send commands in the order of the front wheel, then the frame, and first generates a mutual authentication instruction command for the front wheel.

[0075] #4 (output of mutual authentication instruction command): The mutual authentication intermediary unit 13 passes a mutual authentication instruction command for the front wheel to the control unit 12 of the shifter 10 together with the command transmission destination (front wheel).

[0076] #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.

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

[0078] #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.

[0079] #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.

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

[0081] #10 (output of mutual authentication instruction command): The mutual authentication mediation unit 13 passes the mutual authentication instruction command for the frame to the control unit 12 of the shifter 10 together with the command destination (frame).

[0082] #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.

[0083] #12 (Processing of mutual authentication instruction command): Upon receiving the mutual authentication instruction command, the frame secure element 40 processes the mutual authentication instruction command and generates a response to be transferred to the mutual authentication intermediary unit 13 or the front wheel secure element 40.

[0084] # 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 .

[0085] # 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 .

[0086] #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.

[0087] The mutual authentication mediation unit 13 can appropriately determine the identification and order of components when mediating mutual authentication. 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 making a list of pairs of components that require mutual authentication, and (3) performing mutual authentication in order from the top of the list.

[0088] Based on the flows shown in Figs. 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.

[0089] Although the specific encryption algorithm, etc. used in the mutual authentication can be appropriately determined and used, in this embodiment, an example of mutual authentication using an asymmetric key consisting of a component public key, a certificate, a private key, and a CA public key will be described. The following describes a method for performing mutual authentication based on the exchange of commands.

[0090] Fig. 7 is a schematic diagram showing an example of a flow of mutual authentication when commands are exchanged primarily with an electric component. Here, the process of exchanging commands primarily with an electric component, such as between electric components or between an electric component and a non-electric component, is described. The derailleur 20 is used as an example of an electric component, and the rear wheel is used as an example of a non-electric component. Each process in the diagram is described below as #1 to #15.

[0091] #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.

[0092] #2 (Generation of 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 as data to be signed by concatenating the ID of the derailleur 20 and a random number that it has generated.

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

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

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

[0096] #6 (component public key signature verification using CA public key): When the secure element 50 of the rear wheel receives the command, it verifies the signature of the component public key in the command using the CA public key it holds. 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 the process ends here.

[0097] #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 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 53 is updated to unauthenticated (represented by the sign x), and the process ends here.

[0098] #8 (updating mutual authentication flag in mutual authentication list 53): If the rear wheel secure element 50 is successful in both signature verifications in steps #6 and #7, it searches its own mutual authentication list 53 and updates the mutual authentication flag of the part with the ID specified in the command. Here, it updates the mutual authentication flag of the derailleur 20 to indicate authentication is complete (represented by the symbol ×→O). 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.

[0099] #9 (Generation of data string to be signed): The secure element 50 of the rear wheel prepares a data string as data to be signed by concatenating the ID of the rear wheel and a random number that it has generated.

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

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

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

[0103] #13 (Component public key signature verification using CA public key): When the secure element 21 of the derailleur 20 receives the response, it performs signature verification of the component public key in the response using the CA public key it holds. 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 the process ends here.

[0104] #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 the signature verification was successful. If the 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 sign x), and the process ends here.

[0105] #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 is complete (represented by the symbol ×→O). 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.

[0106] Fig. 8 is a schematic diagram showing an example of a flow of mutual authentication when a command is exchanged between non-motorized parts. Here, a front wheel and a frame are taken as examples of non-motorized parts. Each process in the diagram will be explained below as #1 to #26.

[0107] #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.

[0108] #2 (Command generation): The mutual authentication mediation unit 13 selects a 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 be sent to the front wheel.

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

[0110] #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.

[0111] #5 (Generation of Data String to be Signed): The secure element 40 of the front wheel prepares, as data to be signed, a data string that concatenates the ID of the front wheel and a random number that it has generated.

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

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

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

[0115] #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.

[0116] #10 (Response processing and command generation): The mutual authentication intermediary unit 13 analyzes the received response, and sets the response data as command data for the command to be sent to the frame, thereby generating a command.

[0117] #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.

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

[0119] #13 (component public key signature verification using CA public key): When the secure element 60 of the frame receives a command, it verifies the signature of the component public key in the command using the CA public key it holds. 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 sign x), and processing ends here.

[0120] #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 sign x), and the process ends here.

[0121] #15 (updating mutual authentication flag in mutual authentication list 63): If both signature verifications in processes #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 completion (represented by the symbol ×→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.

[0122] #16 (Generation of data string to be signed): The secure element 60 prepares, as data to be signed, a data string in which the frame ID and a random number generated by itself are concatenated.

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

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

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

[0126] #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.

[0127] #21 (Response processing and command generation): The mutual authentication intermediary unit 13 analyzes the received response, and sets the response data as command data for the command to be sent to the front wheel, thereby generating a command.

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

[0129] #23 (Send 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.

[0130] #24 (component public key signature verification using CA public key): When the secure element 40 of the front wheel receives the command, it verifies the signature of the component public key in the command using the CA public key that it holds. 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 the process ends here.

[0131] #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 sign x), and the process ends here.

[0132] #26 (updating the mutual authentication flag in the mutual authentication list 43): If the signature verifications in both steps #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 ×→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.

[0133] 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 the components mounting the secure components, it is possible to verify whether the components are connected in a predetermined appropriate combination via the communication unit, which makes it possible to prevent stolen goods from being mixed into the components used in the vehicle, thereby enabling effective protection of the components.

[0134] In addition, a secure component receives a calculation result encrypted by another secure component with a private key for mutual authentication, and performs mutual authentication based on the decryption result obtained by decrypting the received calculation result with a public key for mutual authentication. 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.

[0135] Furthermore, the secure component stores mutual authentication information with a predetermined secure component mounted in a predetermined part used in the vehicle, and when mutual authentication with the predetermined 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 predetermined parts is complete, the operation of part A is permitted, and when mutual authentication is not complete (failure), the operation of part A is not permitted. This makes it possible to indirectly suppress theft by preventing the operation of a vehicle with an inappropriate configuration that combines stolen goods, etc., thereby destroying the effectiveness of stolen goods as parts.

[0136] When mutual authentication is performed by exchanging commands initiated by electric components, 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 components 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.

[0137] Fig. 9 is a schematic diagram showing an example of a flow of component operation control when mutual authentication is completed. When mutual authentication of each component is completed, for example, a circuit or function can be configured for an electrically-operated component to inquire of the secure element whether or not it can operate at the start of operation, and to operate only if the operation is permitted by the secure element. The following description will be given using the shifter 10 as an example. Also, each process in the diagram will be described as #1 to #4.

[0138] #1 (Inquiry about operation): The control unit 12 of the shifter 10 inquires of the secure element 11 about whether or not it is capable of operating. The inquiry may be made by, for example, transmitting a predetermined command.

[0139] #2 (Confirming mutual authentication list 19): The secure element 11 checks the mutual authentication list 19 and confirms 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 of the parts, rather than all of the parts listed in the mutual authentication list, are parts for which mutual authentication should be performed.

[0140] #3 (Reply of Operation Possibility): The secure element 11 returns a response indicating that operation is possible if mutual authentication has been completed for all components in the mutual authentication list 19. If authentication has not been completed for some or all of the components (unauthenticated), the secure element 11 returns a response indicating that operation is not possible.

[0141] #4 (operation start): The control unit 12 controls its own functions to operate only when a response indicating that operation is possible is received.

[0142] In the case of non-electric components, it may be difficult to control whether the component operates on its own, but a mechanism may be used in which power is supplied from an electric component to release a physical lock in response to user input at the start of operation, or a configuration may be used in which an electric component that is closely related to or linked in function with the non-electric component is instead controlled.

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

[0144] On the other hand, there may be cases where the bicycle owner wishes to replace parts of their own volition, or where parts are replaced by a mechanic or other authorized means. The bicycle must be able to function normally even after such use cases. Below, we will explain the functions to handle such cases.

[0145] 10 is a schematic diagram showing an example of a flow of updating the mutual authentication list via a secret communication channel. As an example, a case where frames are exchanged by a regular means will be described below. Also, each process in the diagram will be described as #1 to #12.

[0146] #1 (Replacement of parts): A user (bicycle owner, mechanic, etc.) replaces a bicycle part with a new part. In this case, frame E of company B is replaced with frame V of company F.

[0147] #2 (updating bicycle parts DB 250): The user contacts the administrator of bicycle management server 200 and requests that the contents of bicycle parts DB 250 be updated. The administrator receives the request and updates bicycle parts DB 250. Here, the body ID in 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.

[0148] #3 (instruction to update the mutual authentication list): The user inputs an instruction to update the mutual authentication list accompanying the part replacement to the shifter 10 through the input I / F.

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

[0150] #5 (investigation of mutual authentication list update target): The control unit 12 acquires the part that is the mutual authentication list update target from the secure element 11 built in itself.

[0151] #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, a list of parts for which the mutual authentication list is to be updated is also sent.

[0152] #7 (Obtaining a secret communication key for parts to be updated): The bicycle management server 200 refers to 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 them. Here, the mutual authentication list 19 of the shifter 10 is first updated, and the secret communication key of the shifter 10 is obtained.

[0153] #8 (command 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 commands it to open a secret communication path.

[0154] #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).

[0155] #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.

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

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

[0158] 11 is a schematic diagram showing an example of the mutual authentication list after updating for a part other than the shifter 10. As shown in the figure, the part ID of the frame type in the mutual authentication lists 26, 37, 43, 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.

[0159] Any method may be used to update the automobile parts DB 250 as long as the authenticity of the user can be confirmed. For example, various methods may be used, such as contacting the user by telephone or submitting an update form via a Web I / F.

[0160] By using the mutual authentication list as described above, it is possible to prevent the risk of theft of individual parts. Below, we will 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.

[0161] 12 is a schematic diagram showing an example of a flow of function suspension by the secret communication function. In the following, each process in the diagram will be described as #1 to #8.

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

[0163] #2 (command to obtain secret communication key): The administrator commands the bicycle management server 200 to obtain the secret communication key for the corresponding bicycle from the bicycle parts DB 250.

[0164] #3 (obtaining a secret communication key): The parts DB access unit 210 of the bicycle management server 200 obtains the corresponding bicycle secret communication key from the bicycle parts DB 250.

[0165] #4 (Instruction to open a secret communication path): The administrator instructs the bicycle management server 200 to open a secret communication path. Here, first, an instruction is given to open a secret communication path with the shifter 10.

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

[0167] #6 (disable mutual authentication flag): The bicycle management server 200 updates the mutual authentication flags of all parts 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 path.

[0168] #7 (Mutual authentication block): 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.

[0169] #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.

[0170] 13 is a schematic diagram showing an example of disabling secure elements in parts other than the shifter 10. As shown in the figure, the mutual authentication flags of all parts in the mutual authentication lists 26, 37, 43, and 53, respectively, of 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 updated to unauthenticated (represented by the symbol x). In addition, the key pair used for mutual authentication has been updated to an invalid value.

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

[0172] 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. With this configuration, the bicycle's functions can be stopped regardless of the thief's wishes.

[0173] In addition, even if the bicycle is stolen, if its functions are suddenly disabled, it may have serious consequences, such as causing a traffic accident, so the bicycle's functions may be disabled after it has been stopped for a certain period of time. This allows for a bicycle that is considerate of traffic.

[0174] 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 it is desirable to avoid disabling the functions as much as possible (e.g., bicycle races), and cases where it is desirable to continue using a stolen bicycle (an unauthenticated bicycle) due to an emergency or urgent business (e.g., when moving quickly). In this way, when the risk of theft is low or can only be tolerated, it is possible to temporarily disable the mutual authentication function between bicycle parts (making mutual authentication unnecessary). This point will be explained below.

[0175] 14 is a schematic diagram showing an example of a flow of temporarily invalidating mutual authentication via a secret communication path. In the following, each process in the diagram will be described as #1 to #7.

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

[0177] #2 (command to obtain secret communication key): The administrator commands the bicycle management server 200 to obtain the secret communication key for the corresponding bicycle from the bicycle parts DB 250.

[0178] #3 (obtaining a secret communication key): The parts DB access unit 210 of the bicycle management server 200 obtains the corresponding bicycle secret communication key from the bicycle parts DB 250.

[0179] #4 (Instruction to open a secret communication path): The administrator instructs the bicycle management server 200 to open a secret communication path. Here, first, an instruction is given to open a secret communication path with the shifter 10.

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

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

[0182] #7 (Delete mutual authentication list of other secure elements): Thereafter, the bicycle management server 200 similarly deletes each part designation from the mutual authentication list for other secure elements.

[0183] 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 have been deleted from 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. For convenience, the part names are crossed out in the figure.

[0184] Here, 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 holding 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 handle part replacement during the race. On the other hand, in the event of an emergency or other such situation where it is not possible to open a secret communication path from the bicycle management server 200, it is possible, for example, to provide an emergency button or the like on the input I / F of the bicycle and operate the emergency button to temporarily enable operation. This point will be explained below.

[0185] 16 is a schematic diagram showing an example of a flow of temporarily invalidating mutual authentication via an input I / F. In the following, each process in the diagram will be described as #1 to #5.

[0186] #1 (Instruction to temporarily disable mutual authentication): The user instructs, via the input I / F of the bicycle 100, to temporarily disable mutual authentication.

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

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

[0189] #4 (Deletion from the 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.

[0190] #5 (Deletion of mutual authentication list of other secure elements): Thereafter, the control unit 12 similarly deletes each component designation from the mutual authentication list for other secure elements.

[0191] 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 have been deleted from 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. For convenience, the part names are crossed out in the figure.

[0192] Since the function of temporarily disabling mutual authentication weakens the effectiveness of the bicycle theft prevention function, 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's functionality being suspended in the event of emergency use, such as by limiting the number of times it can be disabled to a certain number of times.

[0193] 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.

[0194] 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, the vehicle is not limited to a bicycle, and can also be applied to a motorcycle (motorcycle) or an automobile. In the case of a motorcycle, the parts include, for example, exterior parts such as wheels, mufflers, lights, handlebars, frames, batteries, and seats. In the case of an automobile, the parts include, for example, wheels, batteries, chargers, steering wheels, and on-board cameras.

[0195] FIG. 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. Moreover, 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 mounted on each vehicle part.

[0196] 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 similar functions to 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 description thereof will be omitted.

[0197] The vehicle parts 410 to 440 of each vehicle 400 can perform mutual authentication by secure components and activate or stop functions of the vehicle parts, similar to the case of the above-mentioned information processing system. That is, the vehicle / vehicle parts management server 300 can perform comprehensive management such as mutual authentication by secure components, activation or stop of functions of the vehicle parts, temporary disablement or enablement of mutual authentication, and updating of keys, certificates, etc. used for mutual authentication, via a secret communication path. This makes it possible to prevent stolen goods, etc. from being mixed into vehicle parts used in vehicles, and to effectively protect the vehicle parts.

[0198] 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 permeates society, new services will be created, such as, for example, dispatching cars by automatic driving, optimizing transportation, and using movement information related to various means of transportation (cars, buses, trains, motorcycles, etc.) as big data, and it is expected that the importance of parts (vehicle parts) used in these means of transportation will increase. According to this embodiment, a useful management system or management method can be provided for such new services.

[0199] 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 between 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 memory unit that stores mutual authentication information that associates a mutual authentication target with a mutual authentication result by the authentication unit.

[0200] The computer program of this embodiment causes a computer to execute processing to send and receive information between a secure component installed in a vehicle component used in a vehicle, perform mutual authentication with the secure component, and store mutual authentication information that associates the mutual authentication target with the mutual authentication result.

[0201] The information processing method of this embodiment performs mutual authentication between secure components installed in each of a plurality of vehicle components used in a vehicle, and each secure component stores mutual authentication information that associates the mutual authentication target with the mutual authentication result.

[0202] 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 the vehicle components are connected via the communication unit in a predetermined appropriate combination, which makes it possible to prevent stolen goods or the like from being mixed into vehicle components used in the vehicle, and effectively protect the vehicle components.

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

[0204] A secure component receives a calculation result encrypted by another secure component with a private key for mutual authentication, and performs mutual authentication based on the decryption result obtained by decrypting the received calculation result with a public key for mutual authentication. 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.

[0205] In the secure component of this embodiment, the first memory unit stores mutual authentication information with a specific secure component installed in a specific vehicle component used in the vehicle, and has an output unit that outputs operation permission for the vehicle component in which it is installed when mutual authentication with the specific secure component has been completed.

[0206] The secure component stores mutual authentication information with a predetermined secure component mounted on a predetermined vehicle component used in a vehicle, and when mutual authentication with the predetermined secure component is completed, 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 predetermined vehicle components is completed, the operation of the vehicle component A is permitted, and when mutual authentication is not completed (failed), the operation of the vehicle component A is not permitted. In this way, by not operating a vehicle with an inappropriate configuration that combines stolen goods, etc., the effectiveness of the stolen goods as vehicle parts is lost, and theft can be indirectly suppressed.

[0207] The secure component of the present 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.

[0208] 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 a legitimate means, the mutual authentication information can be updated to correspond to the replaced vehicle part. This provides a means for performing appropriate mutual authentication against the misappropriation of legitimate vehicle parts by mechanics or manufacturers.

[0209] 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 an external server.

[0210] The secure component is capable of updating at least one of the key and the certificate 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 in the event that the vehicle is stolen, thereby preventing theft.

[0211] The secure component of the present embodiment includes a second storage unit that stores vehicle part information capable of uniquely identifying the vehicle part on which the secure component is mounted, and a vehicle part certificate including a public key and a public key signature for mutual authentication.

[0212] The secure component stores vehicle part information that can uniquely identify the vehicle part on which it is mounted, 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 a 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.

[0213] Mutual authentication between secure components can be achieved even if the vehicle parts equipped with the secure components are non-electric components.

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

[0215] The secure component includes 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 system on a chip (SoC) 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 allows an appropriate secure component to be configured depending on the type of vehicle, vehicle parts, etc.

[0216] The vehicle part of this embodiment includes the above-mentioned secure component.

[0217] 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 parts used in a vehicle, thereby effectively protecting the vehicle components.

[0218] The vehicle part of this embodiment is operable based on the operation permission output by the secure component.

[0219] In the information processing method of the present embodiment, the operation of each of the vehicle components is determined based on mutual authentication information stored in a secure component mounted on each of the vehicle components.

[0220] The vehicle parts are operable based on the operation permission output by the secure component. Since the vehicle parts are operable only when the necessary mutual authentication is completed by the secure component, the stolen goods or the like are rendered ineffective as vehicle parts by preventing the operation of a vehicle having an inappropriate configuration combined with the stolen goods, and thus theft can be indirectly suppressed.

[0221] The vehicle component of this embodiment 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.

[0222] The vehicle part 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. By temporarily disabling the mutual authentication function, the vehicle can be operated without mutual authentication, which can be used when there is a low risk of theft in public or when the risk of theft is acceptable or unavoidable due to an emergency or urgent business.

[0223] The vehicle component of the present embodiment can stop its operation based on a function stop instruction from the external server via a secure communication path established between the secure component and the external server.

[0224] 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.

[0225] The vehicle component of the present embodiment temporarily enables an operation based on a user instruction from a reception unit provided in the vehicle.

[0226] The vehicle parts are temporarily enabled to operate based on a user instruction from a reception unit provided 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 place in the event of a disaster or when the vehicle becomes unusable due to an unforeseen event.

[0227] 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 intermediation unit that mediates mutual authentication between the first secure component and the second secure component via the communication unit.

[0228] In the case where 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, 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 the secure components are non-electrical components, mutual authentication between the secure components can be realized, so that it is possible to verify whether the vehicle components are connected via the communication unit in a predetermined appropriate combination, and it is possible to prevent stolen goods from being mixed into the vehicle components used in the vehicle, thereby effectively protecting the vehicle components.

[0229] In the vehicle component of the present embodiment, each of the first vehicle component and the second vehicle component includes a non-electric component.

[0230] The vehicle of this embodiment includes a plurality of the vehicle components described above.

[0231] The vehicle includes a plurality of vehicle parts, which makes it possible to realize a vehicle that is resistant to the intrusion of stolen goods, etc.

[0232] 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 equipped on the vehicle, and the server manages at least one of the plurality of vehicle parts and the vehicle based on mutual authentication via the secret communication path.

[0233] In the management method of this embodiment, a server capable of establishing a secret communication path between a secure component mounted on each of a plurality of vehicle parts equipped in the vehicle as described above manages at least one of the plurality of vehicle parts and the vehicle based on mutual authentication via the secret communication path.

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

[0235] 10. Shifter 11 Secure Element 12 Control section 13 Mutual Certification Agency 14 Network Communication Section 15 Shifter operation section 16 Mutual Authentication Section 17 Parts Certificate 18 Secret Communications Department 19 Cross-certification list 20 Derailleur 21 Secure Element 22 Derailleur control unit 23 Derailleur drive unit 24 Mutual Certification Department 25 Parts Certificate 26 Cross-certification list 27 Secret Communications Department 30 Battery 31 Secure Element 32 Battery control unit 33 Battery 34 Mutual Certification Department 35 Parts Certificate 36 Secret Communications Department 37 Cross-certification list 40 Secure Element 41 Mutual Certification Department 42 Parts Certificate 43 Cross-certification list 44 Secret Communications Department 50 Secure Element 51 Mutual Certification Department 52 Parts Certificate 53 Cross-certification list 54 Secret Communications Department 60 Secure Element 61 Mutual Certification Department 62 Parts Certificate 63 Cross-certification list 64 Secret Communications Department 100 Bicycles 200 Bicycle management server 210 Parts DB Access Section 220 Network Communication Department 230 Secret Communications Department 250 Bicycle parts DB 251 Bicycle Table

Claims

1. 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; Equipped with 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.

2. 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 .

3. 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.

4. At least one of a key and a certificate used for the mutual authentication is stored, and at least one of the key and the certificate is made updateable via a secret communication path established with an external server. A secure component according to any one of claims 1 to 3.

5. 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.

6. 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.

7. A secure component according to any one of claims 1 to 6, Vehicle parts.

8. The secure component is operable based on an operation permission output by the secure component. The vehicle component according to claim 7.

9. 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.

10. 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.

11. Temporarily enabling an operation based on a user instruction from a reception unit provided in the vehicle. The vehicle component according to claim 8.

12. 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.

13. Each of the first vehicle component and the second vehicle component includes a non-electric component. The vehicle component of claim 12.

14. A vehicle component according to any one of claims 7 to 13, vehicle.

15. 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.

16. 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.

17. 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.

18. A vehicle according to claim 14; 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 provided in the vehicle; Equipped with The server, Activating or deactivating functions of the plurality of vehicle parts based on mutual authentication via the secret communication path. Management system.

Citation Information

Patent Citations

  • System and device for retrieving crime prevention registration information

    JP2003256960A

  • Anti-theft device

    JP2009151557A

  • Bicycle sharing system

    JP2015113686A

  • Internet of Things (IoT) security and management system and method

    JP2019517228A

  • System access using mobile devices

    JP2020511069A