Information processing apparatus and system, and in-vehicle electronic apparatus
By using the identification information of the vehicle or on-board electronic device as a decryption key, encrypted update software is generated and distributed to the vehicle, the difficulties of on-board software update and key management are solved under the limitations of the storage area, and efficient updating of on-board software and key management are achieved.
Patent Information
- Application Number
- CN202280099709.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2022-12-12
- Publication Date
- 2025-04-11
AI Technical Summary
In the prior art, there are difficulties in updating and key management of on-board software, especially when the storage area of on-board electronic devices is limited, how to effectively update and key management of on-board software becomes a challenge.
By using the identification information of the vehicle or the on-board electronic device as a decryption key, an encryption update software is generated and distributed to the vehicle. The vehicle uses its identification information to decrypt and encrypt the update software, thereby realizing the update of the on-board software.
This method avoids the need to store new keys in the unrewriteable area of the vehicle, reduces the risk of misconfiguration of key values, and reduces the number of keys per vehicle by the management center, suppressing the increase in the burden of key management.
Smart Images

Figure CN119817056A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to an information processing device and system for issuing and updating vehicle-mounted software between a software update management center connected to a network and a vehicle-mounted electronic device, and the vehicle-mounted electronic device to which the software is issued. Background Art
[0002] Cars and other vehicles are equipped with multiple onboard electronic devices called ECUs (Electric Control Units) that are responsible for engine control, brake control, safety control, and other functions. These functions are implemented through onboard software. In recent years, in order to achieve functions such as autonomous driving and driving assistance, these onboard electronic devices are not only connected and coordinated with each other via the onboard network, but also the onboard software is increasing. With this, security threats such as illegal communications such as eavesdropping on the communication data of the onboard network or inserting illegal data, and tampering with the onboard software are increasing.
[0003] In order to protect vehicle functions from such security threats, multiple different keys are stored and used in vehicles or on-board electronic devices according to their functions, such as keys for encrypting and decrypting communication data, verification keys for tampering detection of on-board software, etc. Furthermore, SOTA (Software Over the Air), which distributes and updates on-board software via wireless communication for the purpose of correcting defects in on-board software or vulnerabilities as security weaknesses, adding functions, etc., is becoming popular. As SOTA functions and functions realized by newly added on-board software increase, the keys stored in vehicles and on-board electronic devices and the keys issued and managed by key management centers will also increase in the future.
[0004] On the other hand, in-vehicle electronic devices have limited hardware resources such as memory for storing data, and limited areas where data such as encryption keys can be securely stored, which creates a burden for key management.
[0005] Regarding the above-mentioned key management technology, Patent Document 1 records that a user key is kept in a device, an access request containing a user key including access right information is sent from the user, and when the access request is consistent with the access request, the vehicle-mounted function program encrypted using the access right information and the user key is decrypted. Prior art literature Patent Literature
[0006] Patent Document 1: International Publication No. 2019 / 224912 Summary of the invention Problem that the invention aims to solve
[0007] In the method described in Patent Document 1, the user must have a new device such as an IC (Integrated Card) card for storing a user key required for using the vehicle-mounted function. In addition, the user key must be written into the device every time the user or the user's access right information changes, so there is a risk of erroneous settings such as erroneous writing of the user key value.
[0008] The present invention is completed in view of the above-mentioned problems, and its purpose is to provide an information processing device, system and vehicle-mounted electronic device, which can realize the update and use of vehicle-mounted software even when there is no surplus in the storage area of the vehicle-mounted electronic device, and can suppress the increase of key management burden. Technical means of solving problems
[0009] In order to achieve the above-mentioned purpose, the information processing device involved in the present invention comprises: a storage unit, which stores the inherent number of a vehicle or a vehicle-mounted electronic device; a vehicle selection unit, which selects a vehicle to which the update software is applied; a key generation unit, which generates a key using at least any one of the inherent numbers of the selected vehicle or the vehicle-mounted electronic device mounted on the vehicle as a public key; an encryption unit, which uses the key to encrypt the update software to generate encrypted update software; and a distribution unit, which distributes the encrypted update software to the vehicle. Effects of the Invention
[0010] According to the present invention, by using the identification information of the vehicle or the vehicle-mounted electronic device as the decryption key, it is possible to avoid storing a new key for updating or using the vehicle-mounted software in a non-rewritable area of the vehicle, and further, the risk of incorrectly setting the key value can be reduced. Furthermore, in the management center, by using the identification information of the vehicle or the vehicle-mounted electronic device as the decryption key, the number of keys managed for each vehicle will not increase, thereby suppressing the increase in the burden of key management. Other features related to the present invention will become clear from the description of this specification and the accompanying drawings. In addition, the problems, structures and effects other than those described above will become more clear from the description of the following embodiments. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] Figure 1 It is a block diagram showing the overall structure of an information processing system according to one embodiment of the present invention. Figure 2 A block diagram of the hardware configuration of an example vehicle. Figure 3 The following is a block diagram showing the hardware configuration of an exemplary vehicle-mounted electronic device. Figure 4 A block diagram of the hardware structure of the example management center. Figure 5The present invention shows a process flow of software distribution preparation processing, software distribution processing and software update processing performed by an information processing system according to an embodiment of the present invention. Figure 6 A process flow for representing a software distribution preparation process performed by an information processing system. Figure 7 The process flow of software distribution processing performed by the information processing system is shown. Figure 8 The following is a process flow showing a software update process executed by an information processing system. Fig. 9 This is an example of a screen in the management center where a user selects a vehicle to which updated software is to be applied. Fig.10 This figure illustrates the structure of vehicle management information stored in the management center. Fig.11 The figure is a diagram illustrating the structure of software information stored in the management center. DETAILED DESCRIPTION
[0012] [Example 1] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. Figure 1 1 is a block diagram showing the overall structure of an information processing system according to an embodiment of the present invention. The information processing system includes a management center 10, vehicles 201, 202, and a network 40. Figure 1 In the figure, there are two vehicles 201 and 202, but there may be one or more than three. When the vehicles 201 and 202 are not distinguished, the subscript is omitted and sometimes only vehicle 20 is recorded. In addition, the information processing system of this embodiment controls the update of the vehicle-mounted software installed in the vehicle.
[0013] The management center 10 is a computer having a CPU (Central Processing Unit) and a memory for managing vehicles and managing and distributing vehicle-mounted software. The management center 10 includes: a communication unit 101 for communicating via a network 40, a vehicle information updating unit 102 for updating vehicle-mounted software application information of a vehicle, a vehicle selection unit 103 for selecting a vehicle to which the update software is applied, a key generation unit 104 for generating an encryption key that uses the identification information of the selected vehicle as a decryption key, an encryption unit 105 for encrypting the update software using the encryption key, a distribution unit 106 for distributing the encrypted update software to the vehicle, a vehicle information storage unit 107 for storing the identification information of the vehicle and the applied vehicle-mounted software information, an update software storage unit 108 for storing the update software, and a distribution software storage unit 109 for storing the encrypted update software distributed to the vehicle.
[0014] The vehicle 20 is equipped with an in-vehicle electronic device 30. Figure 1 There is one vehicle-mounted electronic device 30, but there may be more than two. The vehicle-mounted electronic device 30 includes: a communication unit 301 for communicating via a network 40, a receiving unit 302 for receiving the encrypted update software from the management center 10, a decryption verification unit 303 for decrypting the encrypted update software, a decryption result determination unit 304 for determining the decryption result, a user notification unit 305 for notifying the user of the vehicle that the update software has been received and receiving the installation permission of the update software from the user, a software update unit 306 for updating the vehicle-mounted software, a software execution unit 307 for executing the vehicle-mounted software, a vehicle-mounted storage unit 308 for storing identification information of the vehicle-mounted electronic device and the vehicle-mounted software, a distribution software storage unit 309 for storing the encrypted update software received from the management center 10, a decryption result storage unit 310 for storing the result of decrypting the encrypted update software using the identification information, and a software storage unit 311 for storing the vehicle-mounted software.
[0015] Figure 2 2 is a block diagram illustrating a hardware configuration of an exemplary vehicle 20. In the vehicle 20, vehicle-mounted electronic devices 301, 302, 303, and 304 are connected to each other via the vehicle-mounted network 21. Figure 2 In the figure, there are four on-board electronic devices 301, 302, 303, and 304, but there may be one or any number of two or more. Among the on-board electronic devices 301, 302, 303, and 304, there may also be a master device that controls on-board electronic devices other than itself, a slave device that receives instructions from on-board electronic devices other than itself, a proxy device or a gateway device that mediates or converts communications between two or more different on-board electronic devices other than itself, and the like. When the on-board electronic devices 301, 302, 303, and 304 are not distinguished, the subscript is omitted and sometimes only recorded as the on-board electronic device 30. Examples of the on-board network 21 include CAN (Control Area Network) or Ethernet, and there may be multiple on-board networks, but it is not limited to this.
[0016] Figure 3This is a block diagram of the hardware configuration of an example vehicle-mounted electronic device 30. The vehicle-mounted electronic device 30 is configured by connecting a communication device 31, an input / output device 32, a CPU 33, a memory 34, a storage device 35, and a security device 36 through an internal signal line 37 such as a bus. Here, the security device 36 refers to a computing device having a high-security storage area, and the high-security storage area has a storage area that cannot be physically rewritten, a storage area that can only be rewritten once, and a storage area with access control such as user and process authentication set. Specifically, it is a device that stores, encrypts and decrypts, and verifies keys used for encryption or decryption, digital signatures used for verification of software, etc., electronic certificates, set values, verification values, identification information, etc., such as an HSM (Hardware Security Module).
[0017] Figure 4 1 is a block diagram showing the hardware configuration of an exemplary management center 10. The management center 10 is configured by connecting a communication device 11, an input / output device 12, a CPU 13, a memory 14, and a storage device 15 via an internal signal line 16. The input / output device 12 includes, for example, a keyboard, a mouse, a touch panel, a numeric keypad, a scanner, a microphone, a sensor, a display, a printer, a speaker, and the like. The communication device 11 is Figure 1 The communication unit 101 functions to connect to the network 40 and transmit and receive data.
[0018] Next, the processing flow in the information processing system of this embodiment is described. The program stored in the storage device of the management center 10 or the vehicle-mounted electronic device 30 is loaded into the memory and executed by the CPU, so that each processing unit embodied in the device for constructing the vehicle-mounted software update control system executes the processing flow described below. In addition, each program can also be imported through other storage media or communication media (network or transmission waves propagating in the network) when necessary.
[0019] Figure 5 The diagram shows an example of a process flow of preparing for distribution of updated software, distributing updated software, and updating vehicle-mounted software in a management center 10 and a vehicle 20, which is executed by an information processing system according to an embodiment of the present invention.
[0020] First, the management center 10 performs software distribution preparation processing (step S501). Then, the management center 10 and the vehicle 20 perform software distribution processing (step S502). Here, the vehicle 20 can be one or more. Then, the management center 10 and the vehicle 20 perform software update processing (step S503). Figures 6 to 8 Describe the details of each process.
[0021] Figure 6This is a diagram showing an example of the processing flow of the software distribution preparation process S501 performed by the management center 10.
[0022] First, the management center 10 starts the application and starts the software distribution preparation process (step S601). Next, the management center 10 determines whether there is new update software (step S602). Here, the management center 10 can receive the update software from the update software production center or update software production department (not shown) via the network 40, or can receive the update software via an external storage medium such as a DVD (Digital Versatile Disc) or USB (Universal Serial Bus) memory (not shown). The received update software is stored in the update software storage unit 108.
[0023] In the process of step S602, the management center 10 reads the update software storage unit 108 to determine whether new update software has been logged in. Examples of methods for determining whether new update software has been logged in include: comparing the time information of the last judgment with the time information of the vehicle-mounted software logged in the update software storage unit 108, and if the time information of the logged in vehicle-mounted software is new, then the vehicle-mounted software is determined to be newly logged in; or comparing the number of entries of the vehicle-mounted software at the time of the last judgment with the number of entries of the current vehicle-mounted software, and if the current number of entries is larger, then the vehicle-mounted software is determined to be newly logged in; or giving a distribution completion mark to the vehicle-mounted software that has been distributed to the vehicle, and if the distribution completion mark is not issued, then the vehicle-mounted software is determined to be newly logged in, etc., but it can also be any combination of these methods or any execution order, and is not limited to these methods.
[0024] If the management center 10 determines that there is no new update software, it will wait directly. On the other hand, if it determines that there is new update software, the management center 10 determines whether there is input of the vehicle identification information to be sent (step S603). Here, the vehicle identification information to be sent is input by the user of the management center 10 via the vehicle selection unit 103. An example of the user input screen is described below. Fig. 9 As shown. In addition, examples of the vehicle identification information to be sent include VIN (Vehicle Identification Number), ECUID, serial number, hardware type and model, OS (Operating System) name and version number, vehicle software name, vehicle software version number, etc. In addition, any combination or any order of these may be used, and are not limited to this.
[0025] When the management center 10 determines that there is no input of the delivery target vehicle identification information, it directly waits. On the other hand, when it determines that there is input of the delivery target vehicle identification information, it acquires the delivery target vehicle identification information (step S604).
[0026] Next, the management center 10 uses the target vehicle identification information to generate an encryption key (step S605). In step S605, the key generation unit 104 generates an encryption key using attribute-based encryption, which uses the target vehicle identification information obtained in step S604 as a decryption key.
[0027] Here, attribute-based encryption is a type of public key encryption, which is an encryption method in which the encryption key and the decryption key are different values. It is an encryption method based on a pairing operation that maps a group of two points on an elliptic curve to a finite field. Attribute-based encryption is an extension of ID-based encryption. In addition to being able to use any value or string as a public key, it is an encryption method in which the relationship between the encryption key and the public key is 1 to n, and it is an encryption method in which multiple arbitrary values or strings combined in an AND or OR relationship can be used as public keys.
[0028] In step S605, for example, when VIN1 and VIN3 are selected as the vehicle identification information to be sent in step S604 and VIN2 is set as a non-sending object, an encryption key (encryption key) is generated by attribute-based encryption, in which VIN1 or VIN3 becomes a decryption key (public key). That is, in step S605, the vehicle identification information to be sent is used as the above-mentioned arbitrary value or character string.
[0029] Next, the management center 10 obtains the update software issued to the vehicle (step S606). Here, the update software is the software judged as the new update software in step S602. Next, the management center 10 encrypts the update software with an encryption key (step S607). The encryption key is an encryption key generated in step S605 according to the vehicle identification information of the issued object using attribute-based encryption. The encryption unit 105 uses the encryption key to encrypt the update software obtained in step S606 to generate encrypted update software. The encrypted update software is stored in the issued software storage unit 109. In this way, by using attribute-based encryption, the vehicle identification information can be used as a decryption key, so there is no need to prepare a key for decrypting the encrypted update software. Next, the management center 10 ends the software issuance preparation process (step S608). In addition, step S606 can be executed before step S603 or step S604, and the processing order can be arbitrary.
[0030] Figure 7FIG. 1 is a diagram showing an example of a processing flow of software distribution processing S502 performed by the management center 10 and the vehicle 20 in the information processing system of one embodiment of the present invention. Figure 7 In the example, there are N vehicles (vehicles 201, 202 to 20 N ), but the number of vehicles can be any number of vehicles or more than 1.
[0031] First, the management center 10 starts the application and starts the software distribution process (step S701). Here, in the management center 10, the distribution unit 106 reads the encrypted update software from the distribution software storage unit 109, and sends the encrypted update software to all vehicles having the vehicle identification information stored in the vehicle information storage unit 107 via the network 40 (A701).
[0032] Here, the network 40 may be wireless communication such as LTE (Long term evolution), 4G, 5G, Wi-Fi (Wireless fidelity), Bluetooth, etc., or a wired LAN (Local Area Network). In addition, the network 40 may also encrypt the communication path, perform unilateral or mutual authentication through communication protocols such as IPsec (Security Architecture for Internet Protocol), SSL (Secure Socket Layer), TLS (Transport Layer Security), SSH (Secure Shell), etc.
[0033] Next, the vehicle 201 obtains the encrypted update software (step S702). The receiving unit 302 in the vehicle-mounted electronic device 30 of the vehicle 201 stores the encrypted update software received by the communication unit 301 from the network 40 in the distributed software storage unit 309. Next, the vehicle 202 obtains the encrypted update software (step S703). The receiving unit 302 in the vehicle-mounted electronic device 30 of the vehicle 202 stores the encrypted update software received by the communication unit 301 from the network 40 in the distributed software storage unit 309.
[0034] Next, vehicle 20 N Obtain the encrypted update software (step S704). N The receiving unit 302 in the vehicle-mounted electronic device 30 stores the encrypted update software received by the communication unit 301 from the network 40 in the software distribution storage unit 309. Finally, the management center 10 and the vehicle 20 end the software distribution process (step S705). Here, the processing order of S702 to S704 can be arbitrary, and in addition to the method of performing them sequentially, they can also be performed simultaneously in parallel.
[0035] Figure 8FIG. 1 is a diagram showing an example of a processing flow of the software update processing step S503 performed by the management center 10 and the vehicle 20 in the information processing system of one embodiment of the present invention. Figure 8 The number of vehicles is one (vehicle 20 ), but the number of vehicles may be any number greater than one.
[0036] First, the vehicle 20 starts the application and starts the software update process (step S801). Next, the vehicle 20 obtains the vehicle identification information from the non-rewritable area (step S802). Here, the decryption verification unit 303 reads the vehicle identification information from the vehicle storage unit 308. More specifically, the vehicle identification information stored in the non-rewritable area of the security device 36 is read.
[0037] Next, the vehicle 20 uses its own identification information to decrypt the encrypted update software (step S803). Here, the decryption verification unit 303 uses the vehicle identification information read from the vehicle storage unit 308 to decrypt the encrypted update software read from the distributed software storage unit 309 and stores it in the decryption result storage unit 310. In this way, since the vehicle identification information can be used as the decryption key of the encrypted update software, there is no need to store the decryption key separately in the non-rewritable area of the vehicle.
[0038] Next, the vehicle 20 determines whether the decryption of the encrypted update software is successful (step S804). Here, as an example of a method for determining whether the decryption is successful, there is the following method: a hash value, checksum, MAC (Message Authentication Code) value or digital signature is added to the update software, and the decryption result determination unit 304 takes the software obtained by decrypting the encrypted update software as the object, calculates the hash value, checksum, MAC value, and signature value, and verifies whether it is consistent with the value attached to the update software. If it is consistent, it is determined that the decryption is successful, and if it is inconsistent, it is determined that the decryption failed. It can be any one of the hash value, checksum, MAC, digital signature, etc., or a combination, and the order of the combination can be arbitrary, not limited to this method.
[0039] If it is determined that the decryption fails, the update process ends (step S810). On the other hand, if it is determined that the decryption succeeds, it is determined whether there is permission to update the application (step S805). As an example of a method for determining whether there is permission to update the application, there is a method of determining whether there is an input of update permission from the user on a user screen (not shown) displayed via the input / output device 32 of the vehicle-mounted electronic device 30, but the present invention is not limited thereto.
[0040] If it is determined that there is no permission for application update, the system directly waits. On the other hand, if it is determined that there is permission for update, the vehicle 20 sends a decryption success notification (A801) to the management center 10. The communication unit 301 sends a decryption success notification to the communication unit 101 of the management center 10 via the network 40. The network 40 can be wireless communication such as LTE, 4G, 5G, Wi-Fi, Bluetooth, or a wired LAN. In addition, the network 40 can also encrypt the communication path, unilaterally or mutually authenticate through communication protocols such as IPsec, SSL, TLS, and SSH.
[0041] Next, the management center 10 adds information related to the successful decryption to the vehicle information (step S806). Here, the decryption success notification (A801) received by the vehicle information update unit 102 in the communication unit 101 is added to the corresponding entry of the vehicle information storage unit 107. As an example of the method of adding, there is a method of providing a status flag column in the vehicle information storage unit 107 and inputting the decryption success information into the status flag column, but it is not limited to this.
[0042] If it is determined that the application of step S805 is permitted, the vehicle 20 installs the update software (step S807). Here, the software update unit 306 reads the update software from the decryption result storage unit 310 and installs it.
[0043] Next, the vehicle 20 determines whether the installation of the update software is successful (step S808). If the installation fails, the vehicle 20 sends an update failure notification (A802) to the management center 10. Here, the communication unit 301 sends the update failure notification (A802) to the communication unit 101 of the management center 10 via the network 40. In the transmission of A802, encryption or authentication of the communication path can also be performed as in the transmission of A801.
[0044] The management center 10 adds information about the update failure to the vehicle information (step S809). Here, the update failure notification (A802) received by the vehicle information update unit 102 in the communication unit 101 is added to the corresponding entry of the vehicle information storage unit 107. As an example of the appending method, there is a method of providing a status flag column in the vehicle information storage unit 107 and inputting the update failure information in the status flag column, but it can also be a method of appending or overwriting the decrypted successfully information, and is not limited to this.
[0045] When the vehicle 20 successfully installs the updated software, the vehicle 20 sends an update success notification (A803) to the management center 10. Here, the communication unit 301 sends the update success notification (A803) to the communication unit 101 of the management center 10 via the network 40. In the transmission of A803, encryption or authentication of the communication path may be performed similarly to the transmission of A801 and A802.
[0046] The management center 10 appends the information related to the successful update to the vehicle information (step S809). Here, the update success notification (A803) received by the vehicle information update unit 102 in the communication unit 101 is appended to the corresponding entry of the vehicle information storage unit 107. As an example of the appending method, there is a method of providing a status flag column in the vehicle information storage unit 107 and inputting the update success information in the status flag column, but it can also be a method of appending or rewriting the decrypted successful information, and is not limited to this. Finally, the vehicle 20 ends the application and ends the update process (step S810).
[0047] Fig. 9 This is an example of a screen displayed on the management center 10, in which a user selects a vehicle to which updated software is applied. The vehicle selection screen 900 is displayed on a display as an example of the input / output device 12. Vehicle identification information 901, vehicle-mounted electronic device identification information 902, software identification information 903, version information 904, status mark 905, user selection column 906, status update button 907, and send button 908 are displayed.
[0048] The vehicle identification information 901 displays a vehicle identifier such as VIN. The vehicle-mounted electronic device identification information 902 displays an identifier of a vehicle-mounted electronic device such as ECUID. The software identification information 903 displays a software identifier such as a software name and software ID of the vehicle-mounted software.
[0049] The version number of the vehicle software is displayed in the version information 904. The status of the vehicle software is displayed in the status mark 905. Examples of the status include newly arrived, issued, decrypted, installed, etc., but are not limited thereto. In the user selection column 906, the user can enter a check mark, and by entering the check mark, the vehicle to which the updated software is applied can be selected. The check mark can be one or more.
[0050] The status update button 907 is used to update the state of the status flag 905 when a response as update information of the status flag 905 is received from the vehicle 20, or to display the status flag 905 on the vehicle selection screen 900 when the management center 10 receives new update software. In addition, the update of the status flag 905 and the display of the new update software may be automatically read into the vehicle selection screen 900 on a regular basis, or may be read when the status update button 907 is pressed, or these methods may be combined. When the user completes the vehicle selection, by pressing the send button 908, the generation of the encryption key that becomes the decryption key for the identification information entered with the check mark in the user selection column 906 is started. The components of the vehicle selection screen 900 are not limited to those described above, and the order of the components is not limited to those described above.
[0051] Fig.10 1000 is a diagram showing an example of vehicle management information stored in the vehicle information storage unit 107 of the management center 10. The vehicle management information 1000 has vehicle identification information 1001, vehicle-mounted electronic device identification information 1002, software identification information 1003, version information 1004, verification value 1005, date and time 1006, and status flag 1007 as fields. The combination of values of the fields in the same row represents an entry related to one vehicle-mounted software.
[0052] The vehicle identification information 1001 displays a vehicle identifier such as VIN. The vehicle-mounted electronic device identification information 1002 displays an identifier of a vehicle-mounted electronic device such as ECUID. The software identification information 1003 displays a software identifier such as a software name and software ID of the vehicle-mounted software.
[0053] The version number of the vehicle-mounted software is displayed in the version information 1004. The verification value 1005 displays the verification value of the vehicle-mounted software. Examples of the verification value include the hash value, checksum, MAC value, digital signature value, etc. of the vehicle-mounted software, but a combination of these methods is also possible, and it is not limited to these methods. The date and time 1006 displays the receipt date and time, the distribution date and time, the installation date and time, etc. of the vehicle-mounted software, but a combination of these methods is also possible, and it is not limited to these. One example of the display format of the date and time is ISO 8601, but it is not limited to this.
[0054] The status mark 1007 shows the application status of the vehicle-mounted software. As an example of the application status, there are new arrival, designated delivery completed, delivery completed, decryption completed, installation completed, etc., but it can also be a combination of them, and it is not limited to these. The components of the vehicle management information 1000 are not limited to the above, and the order of the components is not limited to the above.
[0055] Fig.11 1 is a diagram showing an example of software information stored in the update software storage unit 108 of the management center 10. The update software information 1100 includes fields such as a vendor name 1101, a software name 1102, version information 1103, an identifier 1104, a correlation 1105, a creator 1106, a timestamp 1107, a software body 1108, a verification value 1109, a provided function 1110, and supported vulnerability information 1111. A combination of the fields in the same column represents an entry of vehicle-mounted software.
[0056] The vendor name 1101 is information indicating the name of the vendor that generated the vehicle-mounted software. The software name 1102 is information indicating the name of the vehicle-mounted software. The version information 1103 is information indicating the version number of the vehicle-mounted software. The identifier 1104 is information of a software identifier such as the vehicle-mounted software ID, SWID (Software Identification), SPDX (Software Package Data Exchange), CPE (Common Platform Emumeration), Cyclone DX, etc.
[0057] The correlation 1105 is information indicating the combination and correlation relationship with different vehicle-mounted software using text or graphs, but is not limited to these. The creator 1106 is information indicating the name of the supplier, department, creator, etc. that created the vehicle-mounted software, but is not limited to these. The timestamp 1107 is information indicating the creation date and time of the vehicle-mounted software. An example of the format of the timestamp 1107 is ISO 8601, but is not limited to this. The software body 1108 is the data of the vehicle-mounted software itself.
[0058] The verification value 1109 is a value used to verify the vehicle-mounted software. Examples thereof include a hash value, a checksum, a MAC value, a digital signature value, etc. of the vehicle-mounted software, but a combination of these methods is also possible, and the method is not limited to these methods. The provided function 1110 is information indicating the function implemented by the vehicle-mounted software. Examples thereof include a UN restricted number, a title, and an RXSWIN (RxSoftware Identification Number), but a combination of these methods is also possible, and the method is not limited to these.
[0059] The corresponding vulnerability information 1111 is information indicating vulnerability information corresponding to the vehicle-mounted software, and examples thereof include CVE (Common Vulnerabilities and Exposures) ID, ISAC (Information Sharing and Analysis Center) ID, JVN (Japan Vulnerability Notes) vulnerability identification code, etc. These combinations are also possible, but not limited to this.
[0060] By implementing these configurations, sequences, and data structures, by using the identification information of the vehicle or the vehicle-mounted electronic device as the decryption key, it is not necessary to store new keys for updating and using the vehicle-mounted software in the non-rewritable area of the vehicle, and the risk of incorrectly setting the key value can be reduced. Furthermore, in the management center, by using the identification information of the vehicle or the vehicle-mounted electronic device as the decryption key, the number of keys managed for each vehicle will not increase, thereby suppressing the increase in the burden of key management.
[0061] In addition, the present invention is not limited to the above-described embodiment, and various modifications can be made within the scope of the gist of the invention.
[0062] For example, when a plurality of onboard electronic devices in a vehicle are hierarchically structured, the onboard electronic device at the highest level may perform decryption processing of the encrypted update software ( Figure 8 In the steps S801 to S803 in the above, the update software is sent to the lower-level vehicle-mounted electronic device, and the encrypted update software can be decrypted in sequence from the vehicle-mounted electronic device at the highest level (steps S801 to S810). In addition, if the identification information used for decryption or part of it is stored in a different vehicle-mounted electronic device, the vehicle-mounted electronic device that performs the decryption process can also receive this information (step S802).
[0063] In addition, the processing unit and storage unit of the management center can be implemented by a single computer or as a system composed of multiple computers. In addition, the management center and the vehicle can be connected via a wireless communication network or via a wired communication network such as a wired LAN. In addition, when the management center receives multiple update software, the processing steps of S501, S502, and S503 can be concentrated and repeatedly processed multiple times, or each processing step can be repeatedly processed multiple times before proceeding to the next processing step. These methods can be combined.
[0064] In addition, the updated software may be sent from the software supplier to the management center, or the updated software may be generated at the management center.
[0065] According to the embodiments of the present invention described above, the following effects are achieved. (1) The information processing device of the present invention comprises: a storage unit that stores an inherent number that identifies a vehicle or an on-board electronic device; a vehicle selection unit that selects a vehicle to which update software is to be applied; a key generation unit that generates a key that uses at least one of the inherent numbers of the selected vehicle or the on-board electronic device mounted on the vehicle as a public key; an encryption unit that encrypts the update software using the key to generate encrypted update software; and a distribution unit that distributes the encrypted update software to the vehicle.
[0066] According to the above configuration, by using the identification information of the vehicle or the vehicle-mounted electronic device as the decryption key, it is not necessary to store a new key used for updating or using the vehicle-mounted software in a non-rewritable area of the vehicle, and the risk of incorrectly setting the key value can be reduced. Furthermore, in the management center, by using the identification information of the vehicle or the vehicle-mounted electronic device as the decryption key, the number of keys managed for each vehicle will not increase, thereby suppressing the increase in the burden of key management.
[0067] (2) The unique number includes vehicle identification information, an in-vehicle electronic device number, or a software number. This allows a variety of information to be used as a decryption key, thereby ensuring defense against attacks from third parties.
[0068] (3) The key generation unit generates the key by attribute-based encryption. By using attribute-based encryption, the unique number of the vehicle identification information or the like can be used as a decryption key, and there is no need to prepare a key for decryption separately.
[0069] (4) In addition, the information processing system of the present invention is an information processing system comprising the information processing device described in (1) and an on-board electronic device mounted on a vehicle that receives the updated software, wherein the on-board electronic device includes: a receiving unit that receives the encrypted updated software; an on-board storage unit that has a non-rewritable area that holds the inherent number; and a decryption and verification unit that decrypts and verifies the encrypted updated software using the inherent number held.
[0070] With the above configuration, it is possible to construct a system that receives the encrypted update software generated by the information processing device (1) on the vehicle side and decrypts the software.
[0071] (5) When the decryption and verification unit cannot perform decryption or verification based on the unique number, the software update process is stopped. This can prevent unnecessary consumption of resources.
[0072] (6) The vehicle-mounted electronic device alone as described in (4) is also within the scope of the present invention.
[0073] The technical scope of the present invention is not limited to the scope described in the above-mentioned embodiments, does not depart from the main features of the present invention, and includes various modifications. Therefore, the above-mentioned embodiments are merely illustrative, not restrictive. In addition, for a part of the composition of each embodiment, other compositions may be added, deleted, or replaced, all within the scope of the present invention. Explanation of symbols
[0074] 10 management center (information processing device), 20 vehicle, 30 vehicle-mounted electronic device, 103 vehicle selection unit, 104 key generation unit, 105 encryption unit, 106 sending unit, 107 vehicle information storage unit, 108 update software storage unit, 109 sending software storage unit, 302 receiving unit, 303 decryption verification unit; 308 vehicle-mounted storage unit.
Claims
1. An information processing device, characterized in that: have: A storage unit that stores a unique number that identifies the vehicle or the vehicle-mounted electronic device; a vehicle selection unit that selects a vehicle to which the updated software is applied; a key generation unit that generates a key using at least one of the unique numbers of the selected vehicle or the vehicle-mounted electronic device mounted on the vehicle as a public key; an encryption unit, which uses the key to encrypt the update software to generate encrypted update software; as well as A sending unit sends the encrypted update software to the vehicle.
2. The information processing device according to claim 1, wherein: The inherent number includes vehicle identification information, a vehicle electronic device number or a software number.
3. The information processing device according to claim 1, wherein: The key generation unit generates the key by attribute-based encryption.
4. An information processing system, characterized in that: comprising: the information processing device according to claim 1; and an in-vehicle electronic device mounted on a vehicle for receiving updated software, The vehicle-mounted electronic device comprises: a receiving unit, which receives the encrypted update software; an on-vehicle storage unit having a non-rewritable area for storing the inherent number; and A decryption verification unit decrypts and verifies the encrypted update software using the stored unique number.
5. The information processing system according to claim 4, characterized in that The decryption verification unit stops the software update process when decryption or verification based on the unique number cannot be performed.
6. An on-vehicle electronic device mounted on a vehicle, characterized in that: have: a receiving unit that receives the encrypted update software encrypted by a key that specifies at least one of the unique numbers of the vehicle or the in-vehicle electronic device as a public key; an on-vehicle storage unit having a non-rewritable area for storing the inherent number; and A decryption and verification unit decrypts and verifies the encrypted update software using the stored unique number.
7. The vehicle-mounted electronic device as claimed in claim 6, characterized in that , The decryption verification unit stops the software update process when decryption or verification based on the unique number cannot be performed.
8. The vehicle-mounted electronic device as claimed in claim 6, characterized in that , The inherent number includes vehicle identification information, an on-vehicle device number or a software number.
9. The vehicle-mounted electronic device as claimed in claim 6, characterized in that , The key is generated using attribute-based cryptography.
Citation Information
Patent Citations
Vehicle communication device, vehicle access control system, management device, vehicle access control method, and vehicle access control program
WO2019224912A1