Authentication system, on-board device, and authentication program

Abstract

To improve the reliability of data access authentication.SOLUTION: An authentication system 1 comprises a plurality of on-vehicle devices 2 and an authentication server 3. When acquiring a diagnosis request, the authentication server 3 determines a first security level related to an access to data to be read of a vehicle for which an access is requested based on the type of an operator, an IP address, and a DID included in the diagnosis request. The DID indicates the type of the data to be read. The on-vehicle device 2 determines a second security level based on vehicle position information and the DID. When successful in verification using first and second keys for authentication generated based on the first and second security levels, the on-vehicle device 2 permits transmission of the data to be read from the on-vehicle device 2 to the authentication server 3.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a technique for performing authentication for an access request. [Background technology]

[0002] Patent Document 1 describes an in-vehicle device that sets decryption conditions for decrypting encrypted vehicle data according to the country or region the vehicle is traveling in. As a result, the in-vehicle device described in Patent Document 1 can appropriately set data users who are permitted to read vehicle data, even if the data users who are permitted to read vehicle data change as the country or region in which the vehicle is traveling changes. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2021-100153 Summary of the Invention [Problem to be solved by the invention]

[0004] After detailed consideration by the inventors, it was found that simply setting permission conditions based on the country or region in which the vehicle is traveling may result in access to vehicle data being permitted even in cases where access to vehicle data should be denied.

[0005] The present disclosure aims to improve the reliability of data access authentication. [Means for solving the problem]

[0006] One aspect of the present disclosure is an authentication system (1) that includes a plurality of on-vehicle devices (2) and a server (3), and performs authentication for an access request that requests access to target data, which is vehicle data of at least one of a plurality of vehicles. The authentication system includes a first security level determination unit (S70 to S100, S110, S113, S115), a second security level determination unit (S250 to S270), and an authentication unit (S280 to S300).

[0007] The first security level determination unit is configured to, upon receiving the access request, determine a first security level for the access request based on access request information regarding access to the target data.

[0008] The second security level determination unit is configured to determine a second security level regarding access to the target data of the target vehicle based on a target vehicle position that is the position of the target vehicle that is the target of the access request and the type of the target data.

[0009] The authentication unit is configured to permit transmission of the target data to the server if verification is successful using a first authentication key generated based on the first security level and a second authentication key generated based on the second security level.

[0010] The authentication system of the present disclosure configured in this manner determines a first security level based on the access request information and a second security level based on the location of the target vehicle. This allows the authentication system of the present disclosure to perform verification using not only the location of the target vehicle but also the access request information, thereby more appropriately managing access to the target data. Therefore, the authentication system of the present disclosure can improve the reliability of data access authentication.

[0011] Another aspect of the present disclosure is a server of an authentication system, comprising a first security level determination unit. The server of the present disclosure is a server included in the authentication system of the present disclosure, and can obtain the same effects as the authentication system of the present disclosure.

[0012] Yet another aspect of the present disclosure is an in-vehicle device of an authentication system, comprising a second security level determination unit and an authentication unit. The in-vehicle device of the present disclosure is an in-vehicle device included in the authentication system of the present disclosure, and can obtain the same effects as the authentication system of the present disclosure.

[0013] Yet another aspect of the present disclosure is an authentication method executed in a server of an authentication system, which, upon receiving an access request, determines a first security level for the access request based on access request information regarding access to target data.

[0014] The authentication method of the present disclosure is a method executed in the authentication system of the present disclosure, and by executing this method, it is possible to obtain the same effects as the authentication system of the present disclosure. Yet another aspect of the present disclosure is an authentication program for causing a server computer to function as a first security level determination unit.

[0015] A computer controlled by the authentication program of the present disclosure can constitute a part of the authentication system of the present disclosure, and can obtain the same effects as the authentication system of the present disclosure. Yet another aspect of the present disclosure is an authentication program for causing a computer of an in-vehicle device to function as a second security level determination unit and an authentication unit.

[0016] A computer controlled by the authentication program of the present disclosure can constitute a part of the authentication system of the present disclosure, and can obtain the same effects as the authentication system of the present disclosure. [Brief explanation of the drawings]

[0017] [Figure 1] FIG. 1 is a block diagram showing a configuration of an authentication system. [Figure 2]FIG. 2 is a block diagram showing the configuration of an in-vehicle device. [Figure 3] FIG. 2 is a block diagram showing the configuration of an authentication server. [Figure 4] FIG. 2 is a functional block diagram showing the functional configuration of an in-vehicle device and an authentication server. [Figure 5] 3A and 3B are diagrams illustrating the configuration of tables in an in-vehicle device and an authentication server. [Figure 6] 5 is a flowchart showing a server authentication process according to the first embodiment. [Figure 7] 10 is a flowchart showing a vehicle authentication process. [Figure 8] 10 is a flowchart illustrating a key comparison process. [Figure 9] 10 is a flowchart showing a release process. [Figure 10] 10 is a flowchart showing an authentication failure process. [Figure 11] 10 is a flowchart showing a server authentication process according to the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0018] [First embodiment] A first embodiment of the present disclosure will be described below with reference to the drawings. As shown in FIG. 1, the authentication system 1 of this embodiment includes a plurality of vehicle-mounted devices 2 and an authentication server 3.

[0019] The in-vehicle device 2 is mounted on a vehicle and has a function of performing data communication with the authentication server 3 via a wide area wireless communication network NW. The authentication server 3 has a function of performing data communication with the in-vehicle device 2 via the wide area wireless communication network NW.

[0020] A remote diagnosis website accessible via a wide area wireless communication network NW is installed on the authentication server 3. The remote diagnosis website provides a remote vehicle diagnosis service to a service recipient who accesses the website using a communication device such as a personal computer or a tablet terminal.

[0021] 2, the in-vehicle device 2 includes a control unit 11, a CAN communication unit 12, a storage unit 13, and a communication unit 14. CAN is an abbreviation for Controller Area Network and is a registered trademark.

[0022] The control unit 11 is an electronic control device mainly composed of a microcomputer including a CPU 21, a ROM 22, a RAM 23, etc. Various functions of the microcomputer are realized by the CPU 21 executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 22 corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program results in the execution of a method corresponding to the program. Note that some or all of the functions executed by the CPU 21 may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the control unit 11 may be one or more.

[0023] The CAN communication unit 12 is connected to a plurality of ECUs via a CAN bus so as to be able to communicate data with them, and transmits and receives data in accordance with the CAN communication protocol. The plurality of ECUs 111, 112, 113, 114, etc. connected to the CAN communication unit 12 specifically include an engine ECU 111 that controls the engine, a brake ECU 112 that controls the brakes, a steering ECU 113 that controls the steering, and a meter ECU 114 that is provided on the instrument panel and controls meters that display various vehicle statuses. FIG. 2 shows only the ECUs 111, 112, 113, and 114 as the ECUs connected to the CAN communication unit 12. The in-vehicle device 2 may include a communication unit that performs data communication with the ECUs using a communication protocol other than the CAN communication protocol (e.g., an Ethernet communication protocol) instead of or in addition to the CAN communication unit 12. Ethernet is a registered trademark.

[0024] The storage unit 13 is a storage device for storing various data. The communication unit 14 performs data communication with the authentication server 3 via the wide area wireless communication network NW.

[0025] As shown in FIG. 3, the authentication server 3 includes a control unit 31, a communication unit 32, and a storage unit 33. The control unit 31 is an electronic control device mainly composed of a microcomputer including a CPU 41, a ROM 42, a RAM 43, etc. Various functions of the microcomputer are realized by the CPU 41 executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 42 corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU 41 may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the control unit 31 may be one or more.

[0026] The communication unit 32 performs data communication with a plurality of vehicle-mounted devices 2 via the wide area wireless communication network NW. The storage unit 33 is a storage device for storing various data.

[0027] 4, the authentication server 3 includes functional blocks realized by the CPU 41 executing a program stored in the ROM 42, such as a diagnosis control unit 51, an operator determination unit 52, an ECU information determination unit 53, a position information determination unit 54, a security level determination unit 55, and a key generation unit 56. The authentication server 3 also includes a user information table 57, a DID information table 58, a position information table 59, a policy information table 60, and a key table 61. These tables 57 to 61 are stored in the storage unit 33.

[0028] The in-vehicle device 2 includes functional blocks realized by the CPU 21 executing a program stored in the ROM 22, such as a diagnosis control unit 71, an ECU information determination unit 72, a location information determination unit 73, a security level determination unit 74, a key generation unit 75, and a data acquisition unit 76. The in-vehicle device 2 also includes a DID information table 77, a location information table 78, a policy information table 79, a key table 80, and a database 81. These tables 77 to 80 are stored in the storage unit 13. The database 81 stores vehicle data related to the vehicle in which the in-vehicle device 2 is installed, and is provided in the storage unit 13.

[0029] The diagnosis control unit 51 receives a diagnosis request from an operator via the browser 4 and controls remote diagnosis to remotely diagnose the in-vehicle device 2 based on the diagnosis request. The browser 4 is software installed in a communication device (for example, a personal computer or a tablet terminal) and has a function of accessing the authentication server 3 via a wide area wireless communication network NW.

[0030] In this embodiment, the operator is classified into one of the vehicle owner, OEM, and third party. The vehicle owner is the owner of the vehicle that is the subject of remote diagnosis (hereinafter referred to as the vehicle to be diagnosed). The OEM is the vehicle manufacturer that produced the vehicle to be diagnosed. OEM stands for Original Equipment Manufacturer. The third party is a third party other than the vehicle owner or OEM. Examples of third parties include a repair shop for the vehicle to be diagnosed and a vehicle insurance company.

[0031] Based on the diagnosis request, the operator determination unit 52 identifies the security level of the operator (hereinafter referred to as the user security level) by referring to the user information table 57. The user security level is information indicating the level of the access right of the operator.

[0032] The ECU information determination unit 53 identifies the security ID of the data to be read from the vehicle to be diagnosed (hereinafter referred to as "read target data") by referring to the DID information table 58 based on the diagnosis request. The security ID is information for leveling the characteristics of the read target data. The security ID may be an ID of a data category or data attribute classified from a security perspective. For example, it may be an ID of personal information, semi-personal information, vehicle manufacturer-exclusive information, open information, etc.

[0033] The location information determination unit 54 identifies the policy ID by referring to the location information table 59 based on the IP address of the connection source. The policy ID is information for identifying security policy information. For example, if security policies differ for each country or region, the security policy is identified by the policy ID. The security policy information is information that associates security IDs with security levels and determines what vehicle data should be handled at what security level.

[0034] The security level determination unit 55 refers to the policy information table 60 based on the policy ID and the security ID to identify the security level of the data to be read (hereinafter referred to as the data security level).

[0035] The key generating unit 56 generates a first authentication key by referring to the key table 61 based on the user security level. The diagnosis control unit 71 receives a data transmission request from the authentication server 3 and controls data transmission to transmit the data to be read to the authentication server 3 based on the data transmission request.

[0036] The ECU information determination unit 72 refers to the DID information table 77 based on the data transmission request to identify the security ID of the data to be read. The position information determination unit 73 identifies the policy ID by referring to the position information table 78 based on the position of the vehicle.

[0037] The security level determination unit 74 identifies the data security level by referring to the policy information table 79 based on the policy ID and security ID. The key generating unit 75 generates a second authentication key by referring to the key table 80 based on the data security level.

[0038] The data acquisition unit 76 acquires the data to be read from the database 81 if the authentication using the second authentication key is successful. 5, the user information table 57 is a table that associates a user ID with a user security level. The user ID is information that identifies an operator.

[0039] In the user information table 57 of this embodiment, for example, "1," "2," and "3" are set as user IDs. The user IDs "1," "2," and "3" correspond to "vehicle owner," "OEM," and "third party," respectively. The user IDs "1," "2," and "3" are associated with security levels "1," "2," and "3," respectively.

[0040] The DID information tables 58 and 77 are tables that associate the data ID (hereinafter referred to as DID) of the data to be read with the security ID. The data ID is information that identifies the data.

[0041] In the DID information tables 58 and 77 of this embodiment, for example, "1," "2," and "3" are set as DIDs. DID "1" is information indicating that the data is related to the ECU that controls the airbag. DID "2" is information indicating that the data is related to the ECU that controls the engine. DID "3" is information indicating that the data is related to the ECU that controls the air conditioner. DIDs "1," "2," and "3" are associated with security IDs "1," "2," and "3," respectively. Note that DIDs may be assigned to each data type regardless of which ECU it is for.

[0042] The location information tables 59 and 78 are tables that associate location IDs with policy IDs. The location ID is information that indicates the country or region where the operator or the vehicle to be diagnosed is located.

[0043] In the position information tables 59 and 78 of this embodiment, for example, "1" and "2" are set as location IDs. The location ID "1" is information indicating that the operator or the vehicle to be diagnosed is located in "Germany." The location ID "2" is information indicating that the operator or the vehicle to be diagnosed is located in "France." The location IDs "1" and "2" are associated with the policy IDs "1" and "2," respectively.

[0044] The policy information tables 60 and 79 are tables that associate policy IDs with security policy information. In the policy information tables 60 and 79 of this embodiment, for example, "1" and "2" are set as policy IDs. The policy IDs "1" and "2" are associated with the security policy information SP1 and SP2, respectively.

[0045] In the security policy information SP1, security IDs "1", "2", and "3" are associated with security levels "1", "2", and "3", respectively. Security level "1" is a level at which only the vehicle owner is permitted to access data. Security level "2" is a level at which the vehicle owner and OEM are permitted to access data. Security level "3" is a level at which the vehicle owner, OEM, and third parties are permitted to access data.

[0046] In the security policy information SP2, security IDs "1," "2," and "3" are associated with security levels "1," "3," and "3," respectively. The key tables 61 and 80 are tables that associate security levels with storage locations of private keys. The private keys are stored in HSMs provided in the key generation units 56 and 75, respectively. HSM stands for Hardware Security Module.

[0047] In the key tables 61 and 80 of this embodiment, security levels "1," "2," and "3" are associated with HSM addresses "0x00000000," "0x11111111," and "0x22222222," respectively. In this embodiment, the encryption method for the private key is "HMACSHA256." Here, differences in key strength may be established, with a low security level being 128 bits and a high security level being 256 bits.

[0048] Next, a description will be given of the procedure of the server authentication process executed by the authentication server 3. The server authentication process is a process that is repeatedly executed while the control unit 31 is in operation. 6, the CPU 41 of the control unit 31 first determines in S10 whether or not a diagnostic request has been received via the browser 4. The diagnostic request includes a user authentication token, the DID of the data to be read, a vehicle ID that identifies the vehicle from which the data to be read is to be read (hereinafter referred to as the read target vehicle), and the IP address set in the communication device that has the browser 4 that sent the diagnostic request installed. Furthermore, the user authentication token includes the above-mentioned user ID and a password for accessing the authentication server 3.

[0049] Here, if a diagnosis request has not been received, the CPU 41 ends the server authentication process. On the other hand, if a diagnosis request has been received, the CPU 41 acquires a user authentication token from the received diagnosis request in S20. Furthermore, the CPU 41 acquires a user ID from the user authentication token in S30. Then, in S40, the CPU 41 checks whether the operator identified by the user ID is a "valid user." Specifically, the CPU 41 determines that the operator is a "valid user" if the user ID acquired in S30 exists in a registered user table in which the user ID of the "valid user" is registered. The registered user table is stored in the storage unit 33.

[0050] Next, in S50, the CPU 41 determines whether the operator who sent the diagnostic request via the browser 4 is a "valid user" based on the confirmation result in S40. If the operator is not a "valid user," the CPU 41 executes authentication failure processing in S60 and terminates the server authentication processing. In the authentication failure processing, the CPU 41 discards the received diagnostic request and further stores an audit log in the storage unit 33 indicating that user authentication failed.

[0051] If the operator is determined to be a "valid user" in S50, the CPU 41 refers to the user information table 57 in S70 to identify the user security level corresponding to the user ID acquired in S30.

[0052] Furthermore, in S80, the CPU 41 refers to the DID information table 58 to identify the security ID corresponding to the DID included in the received diagnostic request. In addition, the CPU 41 identifies a policy ID in S90. Specifically, the CPU 41 first identifies the country or region where the operator is located based on the IP address included in the received diagnosis request, and sets a location ID corresponding to the identified country or region. The CPU 41 then refers to the location information table 59 to identify a policy ID corresponding to the set location ID.

[0053] Furthermore, in S100, the CPU 41 identifies the data security level corresponding to the security ID and policy ID identified in S80 and S90 by referring to the policy information table 60. For example, if the policy ID is "1" and the security ID is "2," the data security level is "2." Also, if the policy ID is "2" and the security ID is "2," the data security level is "3."

[0054] Then, in S110, the CPU 41 determines whether the user security level is lower than the data security level. Specifically, the CPU 41 determines whether a user security level value LV1_u indicating the value of the user security level is greater than a data security level value LV1_d indicating the value of the data security level. If the user security level is higher than or the same as the data security level, the CPU 41 determines that the user has access authority to the data. Note that a security level value of 1 is the highest security level.

[0055] The user security level values ​​LV1_u corresponding to the user security levels "1", "2", and "3" are 1, 2, and 3, respectively. Also, the data security level values ​​LV1_d corresponding to the data security levels "1", "2", and "3" are 1, 2, and 3, respectively.

[0056] Here, if the user security level is lower than the data security level, the CPU 41 proceeds to S60. On the other hand, if the user security level matches the data security level or is higher than the data security level, the CPU 41 transmits a data transmission request to the in-vehicle device 2 of the vehicle identified by the vehicle ID in S120. The data transmission request includes a session number for identifying the data transmission request, the DID of the data to be read, and a request parameter (for example, information specifying specific data from among multiple data to be read identified by the DID). Furthermore, the request parameter may specify whether to abort the read as an error when access to some data of the data to be read is impossible, or to read and execute only accessible data.

[0057] Then, in S130, the CPU 41 determines whether or not a seed, which will be described later, has been received from the in-vehicle device 2, which is the destination of the data transmission request sent in S120. If the seed has not been received, the CPU 41 waits until the seed is received by repeating the process of S130. Upon receiving the seed, the CPU 41 generates a first authentication key in S140. Specifically, the CPU 41 first identifies the storage location of the private key corresponding to the user security level identified in S70 by referring to the key table 61. The CPU 41 then accesses the identified storage location of the HSM to acquire the private key corresponding to the identified user security level (hereinafter referred to as the first security level). Next, the CPU 41 adds the value of the request parameter included in the data transmission request and the value of the received seed, and uses, for example, the SHA-256 hash function to obtain a 256-bit hash value from the sum. The CPU 41 then encrypts the obtained hash value with the private key obtained from the HSM to generate the first authentication key.

[0058] When the processing of S140 is completed, the CPU 41 transmits, at S150, the first authentication key generated at S140 and the session number linked to the seed received at S130 to the in-vehicle device 2 of the vehicle identified by the vehicle ID, and terminates the server authentication processing.

[0059] Next, a description will be given of the procedure of the vehicle authentication process executed by the in-vehicle device 2. The vehicle authentication process is a process that is repeatedly executed while the control unit 11 is operating. When the vehicle authentication process is executed, the CPU 21 of the control unit 11 first determines in S210 whether or not a data transmission request has been received from the authentication server 3, as shown in Fig. 7. If a data transmission request has not been received, the CPU 21 terminates the vehicle authentication process. On the other hand, if a data transmission request has been received, in S220 a seed is generated by generating a random number, and the generated seed is associated with a session number included in the data transmission request. The session number is associated with the DID of the data to be read and the request parameters included in the transmission request.

[0060] Furthermore, in S230, the CPU 21 transmits the seed generated in S220 and the associated session number to the authentication server 3. Then, in S240, the CPU 21 determines whether or not the first authentication key has been received from the authentication server 3. If the first authentication key has not been received, the CPU 21 waits until the first authentication key is received by repeating the process of S240. Then, upon receiving the first authentication key, the CPU 21 first acquires, in S250, the DID included in the data transmission request corresponding to the session number received together with the first authentication key received in S240. The CPU 21 then refers to the DID information table 77 to identify the security ID corresponding to the DID acquired from the data transmission request.

[0061] Furthermore, the CPU 21 identifies a policy ID at S260. Specifically, the CPU 41 first acquires vehicle position information (e.g., latitude and longitude) indicating the position of the vehicle on which the in-vehicle device 2 is installed from an ECU installed in the vehicle. The in-vehicle device 2 performs data communication with the ECU installed in the vehicle in accordance with UDS. UDS is an international standard for diagnostic communication and is an abbreviation for Unified Diagnostic Services. Next, the CPU 41 identifies the country or region where the vehicle is located based on the acquired vehicle location information, and sets a location ID corresponding to the identified country or region.The CPU 21 then refers to the location information table 59 to identify a policy ID corresponding to the set location ID.

[0062] In addition, in S270, the CPU 21 identifies the data security level corresponding to the security ID and policy ID identified in S250 and S260 by referring to the policy information table 79. Hereinafter, the data security level identified in S270 will be referred to as the second security level.

[0063] Then, in S280, the CPU 21 executes a key comparison process (to be described later) for comparing the first authentication key received from the authentication server 3 with the second authentication key generated by the in-vehicle device 2. Next, in S290, the CPU 21 determines whether the first authentication key and the second authentication key match based on the comparison result in S280. If the first authentication key and the second authentication key match, that is, if the verification using the first authentication key and the second authentication key is successful, the CPU 21 executes a release process, which will be described later, in S300 and ends the vehicle authentication process.

[0064] On the other hand, if the first authentication key and the second authentication key do not match, i.e., if the verification using the first authentication key and the second authentication key fails, the CPU 21 executes the authentication failure processing described below in S310 and terminates the vehicle authentication processing.

[0065] Next, the procedure for the key comparison process executed in S280 will be described. When the key comparison process is executed, as shown in FIG. 8, first, in S410, the CPU 21 sets the second security level value LV2 to the value of the second security level.

[0066] Then, in S420, the CPU 21 determines whether or not the second security level value LV2 is greater than 0. If the second security level value LV2 is equal to or less than 0, the CPU 21 ends the key comparison process.

[0067] On the other hand, if the second security level value LV2 is greater than 0, the CPU 21, at S430, identifies the storage location of the private key corresponding to the second security level value LV2 by referring to the key table 80, and obtains the private key by accessing the identified storage location of the HSM.

[0068] Next, in S440, CPU 21 generates a second authentication key. Specifically, CPU 21 first obtains a 256-bit hash value by using, for example, the SHA-256 hash function from the sum of the value of the request parameter included in the data transmission request corresponding to the session number received together with the first authentication key received in S240 and the value of the seed associated with this session number. CPU 21 then generates the second authentication key by encrypting the obtained hash value with the private key obtained in S430.

[0069] Furthermore, in S450, the CPU 21 compares the first authentication key received in S240 with the second authentication key generated in S450. Then, in S460, the CPU 21 determines whether the first authentication key and the second authentication key match based on the comparison result in S450. If the first authentication key and the second authentication key do not match, the CPU 21 subtracts 1 from the second security level value LV2 in S470 and proceeds to S420. On the other hand, if the first authentication key and the second authentication key match, the CPU 21 ends the key comparison process. Note that, although in this embodiment it is defined that the smaller the security level value, the higher the security level, it may also be defined that the larger the security level value, the higher the security level.

[0070] Next, the procedure of the release process executed in S300 will be described. When the release process is executed, as shown in Figure 9, first, at S510, CPU 21 obtains from database 81 data corresponding to the DID included in the data transmission request corresponding to the session number received together with the first authentication key received at S240.

[0071] Furthermore, the CPU 21 transmits the data acquired in S510 to the authentication server 3 in S520. Then, at S530, the CPU 21 stores an audit log indicating that the authentication was successful in the storage unit 13, and ends the cancellation process. This cancellation process is an authentication success process, and executes a process to respond to the data transmission request. Note that the data corresponding to the DID may be acquired by having the corresponding ECU transmit the data.

[0072] Next, the authentication failure process executed in S310 will be described. When the authentication failure process is executed, as shown in FIG. 10, first, in S610, the CPU 21 discards the seed generated in S220 and the second authentication key generated in S440.

[0073] Furthermore, in S620, the CPU 21 transmits to the authentication server 3 an error code indicating that the authentication has failed. Furthermore, in S630, the CPU 21 transmits an authentication failure signal indicating that the authentication has failed to the CAN bus. As a result, the ECUs 111, 112, 113, and 114 connected to the in-vehicle device 2 via the CAN bus receive the authentication failure signal. Then, for example, the ECU 114 that has received the authentication failure signal executes a process for displaying the fact that the authentication has failed on a meter.

[0074] Next, in S640, the CPU 21 stores an audit log indicating that the authentication has failed in the storage unit 13, and ends the authentication failure process. The authentication system 1 configured as above includes a plurality of vehicle-mounted devices 2 and an authentication server 3, and performs authentication in response to an access request requesting access to at least one of the data to be read in a plurality of vehicles.

[0075] When the authentication server 3 receives a diagnostic request, it determines a first security level for access to the data to be read of the vehicle that is the subject of the access request (hereinafter referred to as the target vehicle) based on the type of operator, the IP address, and the DID included in the diagnostic request.

[0076] Specifically, the authentication server 3 determines the data security level based on the IP address and DID, and further determines the user security level based on the type of operator. If the user security level matches the data security level or is higher than the data security level, the authentication server 3 determines the user security level as the first security level. Furthermore, if the authentication server 3 determines the user security level as the first security level, it transmits a data transmission request to the in-vehicle device 2 of the target vehicle, requesting transmission of the data to be read.

[0077] The vehicle-mounted device 2 determines the second security level based on the vehicle position information and the DID included in the data transmission request. If the vehicle-mounted device 2 succeeds in verification using the first authentication key generated based on the first security level and the second authentication key generated based on the second security level, the vehicle-mounted device 2 allows the transmission of the data to be read from the vehicle-mounted device 2 to the authentication server 3.

[0078] Such an authentication system 1 determines a first security level based on the type and location of the operator, and determines a second security level based on the location of the vehicle equipped with the on-board device 2. This allows the authentication system 1 to perform verification using not only the vehicle location but also the type and location of the operator, thereby more appropriately managing access to data to be read. Specifically, even if both the operator and the target vehicle move across countries or regions, the authentication system 1 can appropriately manage the operator's access to vehicle data using the security level determined based on the country or region in which the operator and the target vehicle are located. This allows the authentication system 1 to improve the reliability of data access authentication.

[0079] The authentication server 3 also acquires a seed from the in-vehicle device 2 of the target vehicle, and generates a first authentication key by encrypting a hash value of the acquired seed with a secret key that is preset according to the first security level.

[0080] The in-vehicle device 2 then generates a second authentication key by encrypting the hash value of the generated seed with a secret key preset according to the second security level. The in-vehicle device 2 then compares the first authentication key with the second authentication key to determine whether the first security level matches the second security level and whether the first security level is higher than the second security level.

[0081] Such an authentication system 1 can prevent the occurrence of a situation in which data access authentication is performed using a tampered first authentication key. The authentication server 3 generates a first authentication key by encrypting a hash value of the acquired seed. The in-vehicle device 2 generates a second authentication key by encrypting a hash value of the generated seed. This allows the authentication system 1 to reduce the data size of the generated first and second authentication keys.

[0082] The authentication server 3 is also configured to transmit request parameters specifying the data to be read to the in-vehicle device 2 of the target vehicle. The authentication server 3 then generates a first authentication key by encrypting, with a private key, a hash value calculated to include the acquired seed value and the request parameter value. The in-vehicle device 2 then generates a second authentication key by encrypting, with a private key, a hash value calculated to include the generated seed value and the request parameter value.

[0083] Such an authentication system 1 generates an authentication key using not only a seed but also a request parameter, thereby further reducing the occurrence of a situation in which data access authentication is performed using a tampered first authentication key.

[0084] Furthermore, when it is determined that the authentication has failed, the in-vehicle device 2 notifies the target vehicle of the fact that the authentication has failed. In this way, when the authentication has failed, the authentication system 1 can make the occupant of the target vehicle aware of the fact that the authentication has failed.

[0085] In the above-described embodiment, the authentication server 3 corresponds to the server, S70 to S110 correspond to the processing as a first security level determination unit, S250 to S270 correspond to the processing as a second security level determination unit, and S280 to S300 correspond to the processing as an authentication unit.

[0086] Furthermore, the data to be read corresponds to the target data, the type of operator, IP address and DID correspond to the access request information, the operator corresponds to the source of the access request, the IP address corresponds to the access request location, the DID corresponds to the type of target data, and the location indicated by the vehicle location information corresponds to the target vehicle location.

[0087] Furthermore, S140 corresponds to processing as the first key generation unit, S440 corresponds to processing as the second key generation unit, the private key obtained in S140 corresponds to the first encryption key, and the private key obtained in S440 corresponds to the second encryption key.

[0088] In addition, the hash value calculated in S140 from the sum of the seed value and the request parameter value corresponds to the first calculated value, and the hash value calculated in S440 from the sum of the seed value and the request parameter value corresponds to the second calculated value.

[0089] Furthermore, S120 corresponds to the processing performed by the transmission request unit, the data transmission request corresponds to the data transmission request, and S630 corresponds to the processing performed by the authentication notification unit. [Second embodiment] A second embodiment of the present disclosure will be described below with reference to the drawings. In the second embodiment, only the parts that are different from the first embodiment will be described. The same reference numerals will be used to designate common components.

[0090] The authentication system 1 of the second embodiment differs from the first embodiment in that the server authentication process has been changed. As shown in FIG. 11, the server authentication process of the second embodiment differs from the first embodiment in that the processes of S105, S113, and S115 are added and that the process of S145 is executed instead of S140.

[0091] That is, when the process of S100 ends, the CPU 41 determines whether or not to adopt the user security level for authentication in S105. If the user security level is to be adopted, the CPU 41 proceeds to S110.

[0092] Also, in S110, if the user security level matches the data security level or is higher than the data security level, the CPU 41 sets the user security level identified in S70 as the security level for generating the first authentication key (hereinafter referred to as the first security level) in S113, and proceeds to S120.

[0093] If the user security level is not adopted in S105, the CPU 41 sets the first security level to the data security level identified in S100 in S115, and proceeds to S120.

[0094] Furthermore, if a seed is received in S130, the CPU 41 generates a first authentication key in S145. Specifically, the CPU 41 first identifies the storage location of the private key corresponding to the first security level set in S113 or S115 by referring to the key table 61. The CPU 41 then acquires the private key corresponding to the first security level by accessing the identified storage location in the HSM. Next, the CPU 41 adds the value of the request parameter included in the data transmission request and the value of the received seed, and obtains a 256-bit hash value from the resulting sum using, for example, the SHA-256 hash function. The CPU 41 then encrypts the obtained hash value with the private key obtained from the HSM, thereby generating a first authentication key.

[0095] The authentication system 1 configured in this manner determines the first security level based on the IP address and the DID. Such an authentication system 1 can perform authentication for transmission of data to be read to the authentication server 3 based on the location of the operator and the type of data to be read, without taking into account the type of operator.

[0096] In the embodiment described above, steps S70 to S100, S110, S113, and S115 correspond to the processing performed by the first security level determination unit. Although one embodiment of the present disclosure has been described above, the present disclosure is not limited to the above embodiment and can be implemented in various modifications.

[0097] [Variation 1] In the above embodiment, when authentication fails, an audit log indicating that authentication has failed is stored. However, if the number of authentication failures within a predetermined determination period (e.g., three minutes) reaches a predetermined determination count (e.g., three times) or more, the authentication system 1 may be configured to not accept the same access request until a predetermined specified time (e.g., three minutes) has elapsed. This allows the authentication system 1 to prevent unauthorized access to vehicle data through a DoS attack. DoS stands for Denial of Service.

[0098] [Variation 2] In the above embodiment, the diagnosis request and data transmission request include one DID. However, the diagnosis request and data transmission request may include multiple DIDs. In this case, it is determined for each of the multiple DIDs whether to permit transmission of read-target data to the authentication server 3. If transmission of read-target data is not permitted for some DIDs, transmission of read-target data may be prohibited for all DIDs, or transmission of read-target data may be permitted only for permitted DIDs.

[0099] The control unit 11, 31 and its method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the control unit 11, 31 and its method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit 11, 31 and its method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible recording medium. The method for implementing the functions of each unit included in the control unit 11, 31 does not necessarily need to include software; all of the functions may be implemented using one or more hardware components.

[0100] In the above embodiments, multiple functions of one component may be realized by multiple components, or one function of one component may be realized by multiple components. Furthermore, multiple functions of multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Furthermore, part of the configuration of the above embodiments may be omitted. Furthermore, at least part of the configuration of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0101] In addition to the above-mentioned in-vehicle device 2 and authentication server 3, the present disclosure can also be realized in various forms, such as a system including the in-vehicle device 2 and the authentication server 3 as components, an authentication program for causing a computer to function as the in-vehicle device 2 and the authentication server 3, a non-transient physical recording medium such as a semiconductor memory on which this authentication program is recorded, and an authentication method. [Explanation of symbols]

[0102] 1...Authentication system, 2...In-vehicle device, 3...Authentication server

Claims

1. a plurality of on-board devices (2) mounted on a plurality of vehicles, respectively, configured to transmit vehicle data relating to the vehicles in which they are mounted; a server (3) installed outside the plurality of vehicles and configured to acquire the vehicle data from the plurality of on-board devices by performing data communication with the plurality of on-board devices; An authentication system (1) for performing authentication for an access request requesting access to target data, which is the vehicle data of at least one of a plurality of vehicles, comprising: a first security level determination unit (S70 to S100, S110, S113, S115) configured to, upon receiving the access request, determine a first security level for the access request based on access request information regarding access to the target data; a second security level determination unit (S250 to S270) configured to determine a second security level regarding access to the target data of the target vehicle based on a target vehicle position, which is the position of the target vehicle that is the vehicle that is the target of the access request, and the type of the target data; an authentication unit (S280 to S300) configured to permit transmission of the target data to the server when verification using a first authentication key generated based on the first security level and a second authentication key generated based on the second security level is successful; An authentication system comprising:

2. 2. The authentication system according to claim 1, The first security level determination unit (S70 to S100, S110, S113) determines the first security level based on the type of access request source that has requested access to the target data.

3. 3. The authentication system according to claim 1 or 2, An authentication system in which the first security level determination unit (S80 to S100, S115) determines the first security level based on the access request location, which is the location of the access request source that requested access to the target data, and the type of the target data.

4. The authentication system according to any one of claims 1 to 3, The server a first key generation unit (S140) configured to acquire a seed from the in-vehicle device of the target vehicle, and to generate the first authentication key by encrypting a value associated with the acquired seed with a first encryption key that is preset according to the first security level; Each of the plurality of in-vehicle devices An authentication system comprising a second key generation unit (S440) configured to generate the second authentication key by encrypting a value associated with the generated seed with a second encryption key preset according to the second security level.

5. 5. The authentication system according to claim 4, An authentication system wherein the value associated with the seed is a hash value of the seed.

6. 6. The authentication system according to claim 4 or claim 5, the server is configured to transmit a request parameter specifying the target data to the in-vehicle device of the target vehicle; the first key generation unit generates the first authentication key by encrypting, with the first encryption key, a first calculated value calculated so as to include a value related to the acquired seed and the value of the request parameter; An authentication system in which the second key generation unit generates the second authentication key by encrypting a second calculated value calculated to include a value related to the generated seed and the value of the request parameter with the second encryption key.

7. 3. The authentication system according to claim 2, the first security level determination unit determines a first data security level for access to the target data of the target vehicle based on an access request location, which is a location where the access request source is located, and the type of the target data, and further determines a first user security level for access to the target data of the target vehicle based on the type of the access request source, and determines the first user security level as the first security level when the first user security level matches the first data security level or when the first user security level is higher than the first data security level; The server An authentication system comprising a transmission request unit (S120) configured to send a data transmission request to the on-board device of the target vehicle when the first security level determination unit determines the first user security level as the first security level, requesting the transmission of the target data.

8. The authentication system according to any one of claims 1 to 7, An authentication system comprising: an authentication notification unit (S630) configured to notify the target vehicle that the authentication has failed when the authentication unit determines that the authentication has failed.

9. a plurality of on-board devices (2) mounted on a plurality of vehicles, respectively, configured to transmit vehicle data relating to the vehicles in which they are mounted; a server (3) installed outside the plurality of vehicles and configured to acquire the vehicle data from the plurality of on-board devices by performing data communication with the plurality of on-board devices; The in-vehicle device of the authentication system (1) performs authentication for an access request requesting access to target data, which is the vehicle data of at least one of the plurality of vehicles, The server a first security level determination unit (S70 to S100, S110, S113, S115) configured to, upon receiving the access request, determine a first security level for the access request based on access request information regarding access to the target data; The in-vehicle device a second security level determination unit (S250 to S270) configured to determine a second security level regarding access to the target data of the target vehicle based on a target vehicle position, which is the position of the target vehicle that is the vehicle that is the target of the access request, and the type of the target data; an authentication unit (S280 to S300) configured to permit transmission of the target data to the server when verification using a first authentication key generated based on the first security level and a second authentication key generated based on the second security level is successful; An in-vehicle device comprising:

10. a plurality of on-board devices (2) mounted on a plurality of vehicles, respectively, configured to transmit vehicle data relating to the vehicles in which they are mounted; a server (3) installed outside the plurality of vehicles and configured to acquire the vehicle data from the plurality of on-board devices by performing data communication with the plurality of on-board devices; An authentication program executed by the on-board device of an authentication system (1) that performs authentication for an access request requesting access to target data that is the vehicle data of at least one of a plurality of vehicles, The server a first security level determination unit (S70 to S100, S110, S113, S115) configured to, upon receiving the access request, determine a first security level for the access request based on access request information regarding access to the target data; The authentication program causes the computer of the vehicle-mounted device to: a second security level determination unit (S250 to S270) configured to determine a second security level regarding access to the target data of the target vehicle based on a target vehicle position, which is the position of the target vehicle that is the vehicle that is the target of the access request, and the type of the target data; and an authentication unit configured to permit transmission of the target data to the server when verification using a first authentication key generated based on the first security level and a second authentication key generated based on the second security level is successful (S280 to S300); Certification program to function as.

Images