JP6950540B2 - Network system - Google Patents

Description

The present disclosure relates to network systems.

An information processing device has been proposed in which a general-purpose processing CPU is configured to execute data encryption, decryption, authentication, etc. instead of the security processing CPU even when the security processing CPU fails (for example, a patent). See Reference 1.).

Japanese Unexamined Patent Publication No. 2015-119357

However, in the information processing device described in Patent Document 1, if a part other than the security processing CPU in the cryptographic hardware fails, data authentication or the like may not be executed. For example, in the information processing device described in Patent Document 1, when the secure storage device fails, an error occurs in accessing the secure storage device from the general-purpose processing CPU, and the general-purpose processing CPU generates data. There is a risk that authentication etc. cannot be executed.

In one aspect of the present disclosure, it is desirable to provide a network system capable of executing data authentication by a method different from the above-mentioned prior art when data authentication fails.

One aspect of the disclosure is a network system. The network system is a plurality of electronic devices configured to function as a node of the first network (1A) and also as a node of the second network (1B) constructed independently of the first network. (2A, 2B, 2C, 2D) is included. The plurality of electronic devices are configured to be able to communicate with the first network and external devices outside the second network via the first network.

At least one of the plurality of electronic devices is configured to be functional as a requesting device (2B). Further, at least one electronic device among the plurality of electronic devices is configured to be able to function as a request destination device (2C). When one of the plurality of electronic devices functions as the requesting device, at least one electronic device different from the requesting device is configured to be able to function as the requesting device.

When the authentication target data to be authenticated is transmitted to the requesting device via the first network, the requesting device receives the authentication target data and executes the authentication processing for the authentication target data (the requesting device receives the authentication target data). S120, S210-S250). When the authentication is successful in the requesting device, the content of the authentication target data is used in the processing after the successful authentication (S140). If the requesting device fails to authenticate, the proxy request data for requesting the requesting device to perform the authentication processing on behalf of the requesting device is transmitted to the requesting device via the second network (S150, S160). ..

After receiving the proxy request data, the request destination device receives the authentication target data (S510, S514, S520) each time the authentication target data is transmitted to the request source device via the first network (authentication target data). Is executed (S540). When the authentication is successful in the request destination device, the authenticated data including the contents of the authentication target data for which the authentication is successful is transmitted to the request source device via the second network (S550, S560).

When the requesting device receives the authenticated data, it uses the content of the authentication target data included in the authenticated data (S450). In addition, after the request source device transmits the proxy request data, when the authentication target data is received, the request source device executes the authentication process for the authentication target data, and whether the request source device continues to fail in authentication. Is executed (S182, S610-S630).

According to the network system configured in this way, even if the requesting device fails to authenticate the authentication target data, if the requesting device succeeds in authenticating the authentication target data, the requesting device is included in the authenticated data. The data to be authenticated can be used. Therefore, for example, even if there is a problem such as a failure in the hardware or software required to execute the authentication process in the requesting device, the requesting device can use the authenticated authentication target data. ..

In addition, after receiving the proxy request data, the request destination device receives the authentication target data and executes the authentication process for the authentication target data every time the authentication target data is transmitted to the request source device via the first network. Then, the authenticated data is transmitted to the requesting device. Therefore, the requesting device can continuously receive the authenticated data from the requesting device without transmitting the proxy request data to the requesting device each time the authentication target data is received. Therefore, the load on the requesting device can be reduced as compared with the case where the requesting device is configured to send the proxy request data to the requesting device each time it receives the authentication target data. In addition, the load on the network can be reduced by the amount that the transmission frequency of the proxy request data is reduced.

Further, after the request source device transmits the proxy request data, when the authentication target data is received, the request source device executes the authentication process for the authentication target data, and whether or not the request source device continues to fail in authentication. Execute the confirmation process to confirm. Therefore, the requesting device can execute more appropriate processing according to the result of the confirmation processing. For example, as a result of the confirmation process, if the state in which the authentication fails in the requesting device continues, the authentication by the requesting device can be continued on behalf of the requesting device.

Further, as a result of the confirmation process, if the state in which the authentication fails in the requesting device does not continue, the proxy for authentication by the requesting device can be stopped. Alternatively, it is possible to notify that the requesting device is in a state where the proxy for authentication may be stopped. Further, it is possible to save as diagnostic information that the proxy for authentication by the requesting device may be stopped.

The above-mentioned authentication target data, proxy request data, and authenticated data may be data transmitted in one transmission unit, or data divided into a plurality of transmission units and sequentially transmitted. There may be. When the data is divided into multiple transmission units and transmitted sequentially, each time one unit of data is transmitted from the transmitting side to the receiving side, the data reception of one unit of data is completed from the receiving side to the transmitting side. Data indicating that this has been done may be transmitted. That is, other data may be transmitted between the start of transmission of the authentication target data, the proxy request data, and the authenticated data and the completion of transmission.

In addition, the reference numerals in parentheses described in this column and the scope of claims are described in order to make it easier to understand the correspondence with the specific configuration exemplified as one aspect in the embodiment described later. The description does not mean that the technical scope of the present disclosure is limited to the same scope as the embodiments described later.

It is explanatory drawing which shows the network system. It is explanatory drawing which shows the ECU. It is explanatory drawing which shows the structure of the data transmitted in a network. It is a flowchart of the process to execute when the ECU which becomes a request source device receives data from a global bus. It is a flowchart of a message authentication process. It is a flowchart of return confirmation processing. It is a flowchart of the process executed when the ECU serving as a request destination device receives data from a local bus. It is a flowchart of the process executed when the ECU serving as a request destination device receives data from a global bus. It is a flowchart of the process to execute when the ECU which becomes a request source device receives data from a local bus.

Next, the above-mentioned network system will be described with reference to exemplary embodiments.
[Network system configuration]
The network system 1 shown in FIG. 1 is, for example, an in-vehicle network system mounted on an automobile. The network system 1 has a plurality of ECUs 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, 3E, 3F, 3G, 3H, CGW4, a plurality of global buses 5A, 5B, 5C, a local bus 6, and the like. ECU is an abbreviation for "Electronic Control Unit". CGW is an abbreviation for "Central Gateway".

The ECUs 3A, 3B, 2A, and 2B are connected to the global bus 5A. The ECUs 2C, 2D, 3C, and 3D are connected to the global bus 5B. The ECUs 3E, 3F, 3G, and 3H are connected to the global bus 5C. For example, ECUs that are functionally classified into the same system are connected to the global buses 5A to 5C. For example, a body ECU is connected to the global bus 5A. A control system ECU is connected to the global bus 5B. An information system ECU is connected to the global bus 5C.

The global buses 5A to 5C are connected to each other via CGW4. With these configurations, the ECUs 2A to 2D, the ECUs 3A to 3H, the CGW 4 and the global buses 5A to 5C form the first network 1A. The ECUs 2A to 2D are connected to the local bus 6. As a result, the ECUs 2A to 2D and the local bus 6 form the second network 1B. That is, the ECUs 2A to 2D are configured to function as the nodes of the first network 1A and also to function as the nodes of the second network 1B. The ECUs 2A to 2D configured in this way correspond to the electronic device referred to in the present disclosure.

In the first network 1A and the second network 1B, data is transmitted by broadcast communication to the nodes constituting each network. However, the first network 1A and the second network 1B are independent networks. Therefore, for example, even when data is transmitted in the first network 1A, the data is not transmitted to the second network 1B. Similarly, even if data is transmitted in the second network 1B, the data is not transmitted to the first network 1A.

The CGW 4 intervenes between the global buses 5A to 5C and relays data from one of the global buses to the remaining global buses. Further, the CGW 4 is configured to be connectable to the external communication path 7, and relays data between the external communication path 7 and the global buses 5A to 5C. As a result, the ECUs 2A to 2D and the ECUs 3A to 3H can communicate with an external device (not shown) via the first network 1A. The second network 1B is not provided with a node that can be connected to an external communication path. Therefore, the node of the second network 1B cannot communicate with the external device via the second network 1B.

The external communication path 7 may be at least one of a wireless communication path and a wired communication path. Further, the external communication path 7 may be at least one of a communication path that can be connected to a single device and a communication path that can be connected to a plurality of devices. The communication path that can be connected to a plurality of devices may be, for example, a communication path that can be connected to an external network in which a plurality of devices are included as nodes. The external communication path 7 may be entirely composed of a dedicated line or partially composed of a public line.

In this embodiment, the above three global buses 5A to 5C are illustrated, but the number of global buses is arbitrary. For example, the number of global buses may be two or less or four or more. In this embodiment, the above twelve ECUs 2A to 2D and ECUs 3A to 3H are illustrated, but the number of ECUs is arbitrary. For example, the number of ECUs may be 11 or less or 13 or more. In the present embodiment, the above ECUs 2A to 2D are connected to the local bus 6, but at least one of the ECUs 3A to 3H may be connected to the local bus 6. Alternatively, at least one of ECUs 3A to 3H may be connected to a local bus different from the local bus 6.

[ECU configuration]
Next, the internal configuration of the ECU will be described. In the following description, the ECU 2B shown in FIG. 2 will be taken as an example. However, in the present embodiment, the ECUs 2A, 2C, and 2D are configured in the same manner as the ECU 2B. Further, in the present embodiment, the ECUs 3A to 3H are different from the ECU 2B in that they are not connected to the second network 1B, but are configured in the same manner as the ECU 2B in other points.

As shown in FIG. 2, the ECU 2B includes a CPU 11, a RAM 12, a flash memory 13, a first communication unit 16, a second communication unit 17, and the like. The first communication unit 16 is a network interface for connecting to the global bus 5A. The second communication unit 17 is a network interface for connecting to the local bus 6. The various functions of the ECUs 2A to 2D are realized by the CPU 11 executing various processes according to a program stored in the non-transitional substantive recording medium. In this example, the flash memory 13 corresponds to a non-transitional substantive recording medium.

When the CPU 11 executes various processes according to the program, the program stored in the flash memory 13 may be configured to be loaded into the main memory configured by the RAM 12. In this case, the CPU 11 executes various processes according to the program stored in the main memory. When the CPU 11 executes various processes according to the program, the method corresponding to the program is executed, and various functions included in the ECUs 2A to 2D are realized. However, the method for realizing various functions included in the ECUs 2A to 2D is not limited to software, and a part or all of the functions may be realized by using hardware in which a digital circuit, an analog circuit, or the like is combined.

Various storage areas are secured in the RAM 12 and the flash memory 13. As a main storage area related to the present embodiment, the reception data buffer 12A is secured in the RAM 12. A common key storage unit 13A, a CVN storage unit 13B, and a diagnostic storage unit 13C are secured in the flash memory 13. The reception data buffer 12A is a buffer for temporarily storing data received via the first network 1A.

The received data is sequentially stored in the reception data buffer 12A, and when the storage area is full, new data is overwritten and stored in the area in which the oldest data is stored. The size of the reception data buffer 12A is such that at least a certain period of data (for example, 20 milliseconds) can be reliably accumulated in consideration of the situation where the amount of data received via the first network 1A is maximized. The size is secured.

The common key storage unit 13A stores a common key used when executing message authentication for received data in a process described later. The CVN storage unit 13B stores a list of CVNs required for confirming whether or not the data transmission source is a legitimate request destination device in the process described later. CVN is an abbreviation for "Calibration Verification Numbers". The CVN is a collation code generated based on software mounted on the ECU or the like.

It is obligatory by laws and regulations to equip the ECU mounted on the vehicle with a function of generating and outputting a CVN. When a plurality of ECUs mounted on a vehicle generate CVN, different CVN is generated for each ECU. In the present embodiment, the CVNs generated and output by the ECUs 2A to 2D are collected and listed at the time of vehicle production and stored in the CVN storage unit 13B.

When the software mounted on the ECU is updated, or when the software mounted on the ECU is tampered with, the CVN generated in the ECU changes. Therefore, the CVN stored in the CVN storage unit 13B at the time of vehicle production is compared with the CVN output from the ECU, and if the comparison results do not match, the ECU that outputs the CVN is replaced or the software is tampered with. You can suspect that it was there. When the software mounted on the ECU is properly updated, the CVN stored in the CVN storage unit 13B may be updated by the CVN output from the updated ECU.

Diag information is stored in the diagnosis storage unit 13C. As the diagnosis information, for example, when a failure or the like is detected in the ECU 2B, a diagnosis code corresponding to the cause of the failure is stored. As the diagnosis information, in addition to the diagnosis code, various information useful for identifying the cause of failure may be stored. As for what kind of information is stored, for example, the information arranged according to the diagnostic code may be stored, or the information arranged regardless of the diagnostic code may be stored.

[Overview of authentication process]
The node of the first network 1A can receive the data arriving via the external communication path 7. Therefore, for example, it is important to take appropriate measures against such malicious data on the assumption that malicious malicious data may be transmitted from an unauthorized external device connected to the external communication path 7. Become. Further, even when the programs are tampered with in the ECUs 2A to 2D and the ECUs 3A to 3H, or when the ECU is replaced with an illegal ECU, the illegal data transmitted from such an illegal ECU is dealt with. It is important to take appropriate measures.

Therefore, in the network system 1 of the present embodiment, the ECUs 2A to 2D and the ECUs 3A to 3H execute the authentication process when the data is received via the first network 1A, and confirm the validity of the data. In the present embodiment, the ECUs 2A to 2D and the ECUs 3A to 3H confirm the validity of the data by message authentication. As shown in FIG. 3, the data D1 transmitted in the first network 1A includes an ID, normal data, encrypted data, and the like. Although the data D1 includes control codes, data, and the like other than these, the description thereof will be omitted because they are not related to this processing.

The ID is an identifier that can include various information such as information indicating the type of data, information indicating the content of data, information indicating the node of the source, information indicating the node of the destination, and information indicating the priority during communication. Is. The data D1 transmitted from the source node to the first network 1A by broadcast communication is received by all the nodes other than the source node in the first network 1A. The node that has received the data D1 can determine whether or not the data should be processed based on the ID included in the data D1.

Normal data is the actual part of the data that the source node attempts to send to the destination node. The encrypted data is data obtained by encrypting normal data by a predetermined encryption method using a common key commonly used by the nodes of the first network 1A. The common key is stored in the above-mentioned common key storage unit 13A. The encrypted data included in the data D1 is obtained by encrypting normal data using a common key at a source node that transmits the data D1 and extracting a part of the encrypted data. The reason for extracting a part of the encrypted data is to reduce the amount of data. If it is not necessary to reduce the amount of data, all of the encrypted data may be used as encrypted data.

When performing message authentication on the node that has received the data D1 as described above, the normal data contained in the data D1 is taken out, the taken out normal data is encrypted in the same procedure as the source node, and the encryption is performed. Extract a part of the converted data. Since the encrypted data generated in the receiving node in this way is generated using the same common key as the source node, it usually matches the encrypted data contained in the data D1.

However, if the normal data is falsified during transmission or if the data is garbled, the encrypted data generated by the receiving node and the encrypted data contained in the data D1 will not match. Alternatively, if an unauthorized node that does not know the common key transmits data, proper encrypted data cannot be generated, so that the encrypted data generated by the receiving node and the encrypted data contained in the data D1 do not match. Become. Therefore, the receiving side node determines that the authentication has been established when the encrypted data generated by the receiving side node and the encrypted data included in the data D1 match. On the other hand, if the encrypted data generated by the receiving node and the encrypted data contained in the data D1 do not match, it is determined that the authentication has failed.

Further, in the network system 1 of the present embodiment, the ECUs 2A to 2D can transmit data via the second network 1B. However, unlike the first network 1A, the second network 1B is a network isolated from the outside of the second network 1B. Therefore, unlike the first network 1A, at least illegal data is not transmitted from the outside of the second network 1B.

Therefore, when the ECUs 2A to 2D receive the data via the second network 1B, they do not execute the authentication process unlike the case of the first network 1A. Therefore, as shown in FIG. 3, the data D2 transmitted in the second network 1B is data that includes ID, normal data, and the like, but does not include encrypted data.

[Authentication agency mechanism]
When the authentication is successful in the above-mentioned authentication process, the ECUs 2A to 2D and the ECUs 3A to 3H use the above-mentioned data D1 in the process after the successful authentication. To give a specific example, for example, normal data is taken out from the data D1, and arithmetic processing using the normal data as a variable, control based on the normal data, branch processing in which a judgment is divided according to the normal data, and the like are executed. ..

On the other hand, of the ECUs 2A to 2D and the ECUs 3A to 3H, the ECUs 2A to 2D request the other ECU to perform the authentication on behalf of the other ECU when the authentication fails in the above-mentioned authentication process. This is because the authentication may have failed not because the data D1 is invalid but because of a failure of the ECU that executes the authentication process. The ECU that fails in the authentication becomes the requesting device when the authentication fails.

Here, the description will be continued on the assumption that the ECU 2B fails to authenticate in the authentication process and becomes the requesting device. The ECU 2B, which is the request source device, selects the request destination device from the ECUs 2A, 2C, and 2D (that is, an ECU other than the request source device). Here, the description will be continued on the assumption that the ECU 2B selects the ECU 2C as the request destination device. The ECU 2B, which is the request source device, requests the proxy of the authentication process by transmitting data to the ECU 2C selected as the request destination device via the second network 1B.

In the following description, the data D1 that is received by the requesting device via the first network 1A and is the target of the authentication process is referred to as the authentication target data. Further, in order to request the proxy of the authentication process, the data transmitted from the request source device to the request destination device via the second network 1B is referred to as proxy request data. In the case of the present embodiment, the proxy request data and which ECU has been selected as the request destination device are indicated by the ID in the proxy request data.

Specifically, as the ID indicating that the data is the proxy request data, a plurality of IDs associated with each of the ECUs 2A to 2D that can be selected as the request destination device are prepared. When requesting the ECU 2C to perform the authentication process on behalf of the user, an ID corresponding to the ECU 2C is selected, and the proxy request data including the ID is transmitted to the second network 1B by broadcast communication.

When the ECU 2C receives the proxy request data, it recognizes that the ECU 2C has been selected as the request destination device based on the ID included in the data, and executes the process as the request destination device as an opportunity. The ECUs 2A and 2D also receive the proxy request data transmitted from the ECU 2B. However, since it can be determined that the data does not need to be dealt with by the ECUs 2A and 2D based on the ID included in the data, the processing after the determination is not executed.

The ECU 2C, which is the request destination device, executes an authentication process by message authentication on the data to be authenticated. In the present embodiment, the ECU 2C has the reception data buffer 12A as described above, and stores the data received via the first network 1A in the reception data buffer 12A for a certain period of time. Therefore, when the ECU 2C receives the proxy request data, the ECU 2C searches the received data buffer 12A for the target authentication target data based on the information contained in the proxy request data, and performs the authentication process for the authentication target data. Run. Instead of using the reception data buffer 12A as described above, the data to be authenticated may be provided from the ECU 2B to the ECU 2C.

When the authentication target data is successfully authenticated by the request destination device ECU 2C, the ECU 2C transmits the authenticated data including the contents of the authentication target data that has been successfully authenticated to the ECU 2B via the second network 1B. The fact that the data is authenticated is indicated by the ID in the authenticated data. The ECU 2B, which is the requesting device, can recognize that the authentication in the requesting device has succeeded by receiving the authenticated data. Therefore, when the ECU 2B receives the authenticated data, the ECU 2B can execute the desired processing by using the authentication target data included in the authenticated data.

Therefore, according to the network system 1 configured in this way, even if the authentication of the authentication target data fails in the ECU 2B, if the authentication target data is successfully authenticated in the ECU 2C, the ECU 2B is the authentication target included in the authenticated data. Data can be used. Therefore, for example, even if there is a problem such as a failure in the hardware or software required to execute the authentication process in the ECU 2B, the ECU 2B can use the authenticated authentication target data.

[Details of processing executed in the requesting device and the requesting device]
Next, the processes executed in the request source device and the request destination device described above will be described with reference to the flowcharts shown in FIGS. 4 to 9. In the ECU serving as the requesting device described above, the processes shown in FIGS. 4, 5, 6, and 9 are executed. Further, in the ECU serving as the request destination device, the processes shown in FIGS. 5, 7 and 8 are executed. Here, the description will be continued on the assumption that the ECU 2B is the requesting device and the ECU 2C is selected as the requesting device, as in the above-mentioned example.

As shown in FIG. 4, the ECU 2B receives data from the global bus 5A in S110. Subsequently, the ECU 2B determines in S112 whether or not the data received from the global bus 5A is the authentication target data. The authentication target data is data transmitted to the first network 1A by an ECU other than the ECUs 2B and 2C by broadcast communication. Here, as an example, it is assumed that the ECU 3H has transmitted the authentication target data, and the following description will be continued. When the ECU 3H transmits the authentication target data, the authentication target data reaches all the nodes other than the ECU 3H in the first network 1A. The node that has received the authentication target data determines whether or not the data should be processed based on the ID included in the authentication target data. Further, in the case of the present embodiment, at least in the ECUs 2A to 2D, when the authentication target data is received, the authentication target data is stored in the reception data buffer 12A.

If the data received in S110 is data other than the data to be authenticated, it is determined as NO in S112, and the process proceeds to S114. In S114, the ECU 2B executes a process corresponding to received data other than the authentication target data. As the process executed in S114, various processes depending on the function of the ECU 2B can be considered, but since the process itself is not a main part in the present embodiment, further description will be omitted. After the execution of S114, the process shown in FIG. 4 is terminated.

If the data received in S110 is the data to be authenticated, YES is determined in S112, and the process proceeds to S116. In S116, the ECU 2B determines whether or not the proxy request flag is off. The proxy requested flag is a flag whose initial value is turned off, and when the ECU 2B requests another ECU to perform authentication on behalf of the other ECU in the process described later, the flag is turned on in S170 described later. Here, the description will be continued assuming that the proxy requested flag is set to the initial value (that is, off).

If the proxy request flag is off, it is determined as YES in S116, and the process proceeds to S120. In S120, the ECU 2B executes the message authentication process. The details of this message authentication process are shown in FIG. When the message authentication process is started, the ECU 2B extracts the normal data and the encrypted data included in the data to be processed in S210 as shown in FIG. The data to be processed here is the authentication target data received in S110.

Subsequently, the ECU 2B encrypts the normal data with the common key in S220 to generate the encrypted data. The data encrypted here is normal data extracted from the data to be processed in S210. Subsequently, the ECU 2B determines in S230 whether or not the received encrypted data and the generated data match. If the received encrypted data and the generated data match, it is determined as YES in S230, and the process proceeds to S240.

If the process proceeds to S240, the authentication is established in the ECU 2B, the process shown in FIG. 5 is completed, and the process proceeds to S130 in FIG. On the other hand, if the received encrypted data and the generated data do not match, it is determined as NO in S230, and the process proceeds to S250. If the process proceeds to S250, the authentication has failed in the ECU 2B, the process shown in FIG. 5 is terminated, and the process proceeds to S130 in FIG.

The ECU 2B determines in S130 whether or not the authentication has been established. If the authentication is established in S240 described above, YES is determined in S130, and the process proceeds to S140. In S140, the ECU 2B takes out the normal data included in the authentication target data and uses it in the subsequent processing. As the "subsequent processing" referred to here, various processing according to the function of the ECU 2B can be considered, but since the processing itself is not a main part in the present embodiment, further description will be omitted. After the execution of S140, the process shown in FIG. 4 is terminated.

On the other hand, if the authentication fails in S250 described above, NO is determined in S130, and the process proceeds to S150. In S150, the ECU 2B takes out the ID included in the authentication target data and discards the other parts. Subsequently, the ECU 2B creates proxy request data including the extracted ID in S160, sets an ID for making an authentication proxy request to one request destination device in the proxy request data, and sets the proxy request data locally. Send to bus 6.

In the present embodiment, as described above, it is assumed that the ECU 2C is selected as the request destination device. Therefore, in S160, an ID for making an authentication proxy request to the ECU 2C is set in the proxy request data. As the ID for making the authentication proxy request, a plurality of different IDs are prepared in advance for each ECU that can be the request destination device. As will be described in detail later, when the ECU 2B requests the ECU 2C to perform the authentication on behalf of the ECU 2C in S160, the ECU 2B will receive the authenticated data from the ECU 2C thereafter.

After finishing S160, the ECU 2B subsequently turns on the proxy request flag in S170. The proxy request flag is turned on in S170 when the ECU 2B requests the ECU 2C to perform authentication on behalf of the ECU 2C in S160. Subsequently, the ECU 2B executes the diagnostic storage process in S172, and stores the diagnostic information in the diagnostic storage unit 13C. In S172, a diagnostic code indicating that the authentication has failed in the ECU 2B, various peripheral information considered to be useful for identifying the cause of the authentication failure, and the like are stored in the diagnostic storage unit 13C. After the execution of S172, the process shown in FIG. 4 is terminated.

The process shown in FIG. 4 is executed in the ECU 2B each time the ECU 2B receives data from the global bus 5A. When the processing shown in FIG. 4 is executed a plurality of times and the ECU 2B requests the ECU 2C to perform authentication on behalf of the ECU 2C in S160 and the proxy requested flag is turned on in S170, the process shown in FIG. 4 is shown next. When the process is executed, it is determined as NO in S116. In this case, the ECU 2B executes the return confirmation process in S182.

The return confirmation process of S182 is a process as shown in FIG. 6 in detail. When the process shown in FIG. 6 is started, the ECU 2B determines in S610 whether or not it is the timing to confirm the return. More specifically, in S610, it is determined whether or not it is time to confirm whether or not the ECU 2B returns to the state in which the authentication process is executed by itself from the state in which the ECU 2B requests the ECU 2C to perform the authentication on behalf of the user.

Various specific examples of the confirmation timing referred to in S610 can be considered. For example, the confirmation may be performed every time a predetermined time (for example, one hour) elapses, or the confirmation may be performed every time the vehicle travels a predetermined distance. Alternatively, confirmation may be performed each time the number of times the ECU 2B receives data from the global bus 5A reaches a predetermined number of times. If the reception cycle of the authentication target data can be assumed, the confirmation may be performed at a predetermined number of times the reception cycle.

When it is the timing to confirm the return, it is determined as YES in S610, and the ECU 2B executes the message authentication process in S620. This message authentication process is the process shown in FIG. However, since the details of the process shown in FIG. 5 have already been described, the repeated description will be omitted. Subsequently, the ECU 2C determines in S630 whether or not the authentication is established.

If the authentication is established in S630, it is determined as YES in S630, and the process proceeds to S640. In S640, the ECU 2B takes out the normal data included in the authentication target data and uses it in the subsequent processing. As the "subsequent processing" referred to here, various processing according to the function of the ECU 2B can be considered, but since the processing itself is not a main part in the present embodiment, further description will be omitted.

Subsequently, the ECU 2B transmits the stop request data for requesting the continuation stop of the proxy processing to the local bus 6 in S650. The cancellation request data can be indicated by the ID included in the cancellation request data. As will be described in detail later, when the ECU 2B requests the ECU 2C to continue and stop the proxy processing in S650, the ECU 2C subsequently stops transmitting the authenticated data to the ECU 2B.

Next, the ECU 2B turns off the proxy request flag in S660. Subsequently, the ECU 2B executes the diagnostic storage process in S670 and stores the diagnostic information in the diagnostic storage unit 13C. In S670, a diagnostic code indicating that the ECU 2B has returned to a state in which the authentication process can be executed is stored in the diagnostic storage unit 13C. After the execution of S670, the process shown in FIG. 6 is terminated.

If it is not the timing to confirm the return in S610 described above, NO is determined in S610 and the process proceeds to S680. Further, if the authentication fails in S630 described above, it is determined as NO in S630, and the process proceeds to S680. When proceeding from S610 or S630 to S680, the ECU 2B discards the received data received from the global bus 5A.

As will be described in detail later, when the ECU 2B requests the ECU 2C to perform the authentication on behalf of the ECU 2C in S160 of FIG. 4, the ECU 2B will receive the authenticated data from the ECU 2C thereafter. Therefore, when the proxy request flag is on (that is, NO in S116 of FIG. 4), the authentication target data received from the global bus 5A becomes unnecessary data for the ECU 2B. Therefore, if it is determined in S610 of FIG. 6 that it is not the timing to confirm the return, the process immediately proceeds to S680, the received authentication target data is discarded, and the process shown in FIG. 6 ends.

On the other hand, in S610 of FIG. 6, when it is determined that it is the timing to confirm the return, the processing steps after S620 are executed. However, if the state in which the authentication fails continues, it is determined as NO in S630. In this case, since the ECU 2B continues to receive the authenticated data from the ECU 2C, the authentication target data received from the global bus 5A becomes unnecessary data for the ECU 2B. Therefore, if it is determined in S630 of FIG. 6 that the authentication is not established, the process proceeds to S680, the received authentication target data is discarded, and the process shown in FIG. 6 ends.

When the above-described processing is being executed in the ECU 2B, the processing shown in FIGS. 7 and 8 is executed in the ECU 2C. The process shown in FIG. 7 is a process executed by the ECU 2C when the ECU 2C receives data from the local bus 6. The process shown in FIG. 8 is a process executed by the ECU 2C when the ECU 2C receives data from the global bus 5B. First, the process shown in FIG. 7 will be described.

As shown in FIG. 7, the ECU 2C receives data from the local bus 6 in S310. Subsequently, the ECU 2C determines in S320 whether or not the data received in S310 is the proxy request data addressed to the ECU 2C. Here, it can be determined that the data is the proxy request data and that the data is addressed to the ECU 2C based on the ID included in the received data. When the above-mentioned S160 is executed in the ECU 2B, the proxy request data is transmitted to the second network 1B by broadcast communication. Therefore, the proxy request data reaches all the nodes other than the ECU 2B in the second network 1B.

When the ECU 2C receives the proxy request data addressed to the ECU 2C, the ECU 2C determines YES in S320 and proceeds to S325. In S325, the ECU 2C turns on the proxy continuation flag. Subsequently, the ECU 2C acquires the authentication target data to be processed from the reception data buffer 12A in S330. As described above, when the ECU 2B creates the proxy request data in S160, the proxy request data including the ID extracted from the authentication target data is created. Therefore, in S330, the ECU 2C searches the received data buffer 12A for data having an ID that matches the "ID extracted from the authentication target data" included in the proxy request data, and the data is processed. Acquire as authentication target data.

Subsequently, the ECU 2C executes a message authentication process on the authentication target data found from the received data buffer 12A in S340. This message authentication process is the process shown in FIG. However, since the details of the process shown in FIG. 5 have already been described, the repeated description will be omitted. When the message authentication process is executed in S340, the "data to be processed" in S210 of FIG. 5 is the authentication target data found from the received data buffer 12A in S330.

Subsequently, the ECU 2C determines in S350 whether or not the authentication has been established. If the authentication is established in S340, it is determined as YES in S350, and the process proceeds to S360. In S360, the ECU 2B takes out the normal data included in the authentication target data, creates the authenticated data including the normal data, adds the CVN to the authenticated data, and transmits the authenticated data to the local bus 6. The authentication data can be indicated by the ID included in the authenticated data.

The CVN added to the authenticated data is a CVN generated in the ECU 2C. After the execution of S360, the process shown in FIG. 7 is terminated. On the other hand, if the authentication fails in S340, it is determined as NO in S350, and the process proceeds to S370. In S370, the ECU 2B transmits failure notification data indicating an authentication failure to the local bus 6. The failure notification data can be indicated by the ID included in the failure notification data. After the execution of S370, the process shown in FIG. 7 ends.

When the above-mentioned S360 is executed in the ECU 2C, the authenticated data is transmitted to the second network 1B by broadcast communication. Therefore, the authenticated data transmitted from the ECU 2C reaches all the nodes other than the ECU 2C in the second network 1B. When the above-mentioned S370 is executed in the ECU 2C, the failure notification data is transmitted to the second network 1B by broadcast communication. Therefore, the failure notification data transmitted from the ECU 2C reaches all the nodes other than the ECU 2C in the second network 1B.

If it is not the proxy request data in S320 described above, it is determined as NO in S320, and in that case, the ECU 2C determines in S372 whether or not it is the stop request data. The stop request data is data transmitted when the ECU 2B executes the above-mentioned S650. It can be determined that the data is the cancellation request data based on the ID included in the received data. When the ECU 2C receives the stop request data, it is determined as YES in S372, and the ECU 2C turns off the proxy continuation flag in S374. After the execution of S374, the process shown in FIG. 7 ends.

If it is not the cancellation request data in S372 described above, it is determined as NO in S372. In that case, the ECU 2C executes processing corresponding to the received data other than the proxy request data and the cancellation request data in S380. As the process executed in S380, various processes depending on the function of the ECU 2C can be considered, but since the process itself is not a main part in the present embodiment, further description will be omitted. After the execution of S380, the process shown in FIG. 7 is terminated.

Next, the process shown in FIG. 8 will be described. As shown in FIG. 8, the ECU 2C receives data from the global bus 5B in S510. Subsequently, the ECU 2C stores the received data in the received data buffer 12A in S512. By executing S512, as described above, the received data buffer 12A stores the data received via the first network 1A for the latest fixed period.

Subsequently, the ECU 2C determines in S514 whether or not the received data is addressed to another ECU. If the received data is destined for another ECU, it is determined to be YES in S514, and the ECU 2C determines whether or not the proxy continuation flag is turned on in S516. When the proxy continuation flag is turned on, it is determined as YES in S516, and the ECU 2C determines in S520 whether or not the data is the authentication target data to be processed.

When ECU 2B is the request source device for authentication agency and ECU 2C is the request destination device for authentication agency, among the data received from the global bus 5B, the data addressed to ECU 2B and requiring authentication is the authentication target to be processed in S520. Corresponds to the data. If the data received by the ECU 2C in S510 is the data addressed to the ECU 2B, it is determined to be YES in S514.

Further, when the proxy continuation flag is turned on in S325 described above, it is determined to be YES in S516. Then, when the data received by the ECU 2C in S510 is the authentication target data to be processed, it is determined as YES in S520 and the process proceeds to S540. In S540, the ECU 2C executes a message authentication process for the authentication target data received by the ECU 2C in S510.

This message authentication process is the process shown in FIG. However, since the details of the process shown in FIG. 5 have already been described, the repeated description will be omitted. When the message authentication process is executed in S540, the "data to be processed" in S210 of FIG. 5 is the authentication target data received by the ECU 2C in S510. Subsequently, the ECU 2C determines in S550 whether or not the authentication is established.

If the authentication is established in S540, YES is determined in S550, and the process proceeds to S560. In S560, the ECU 2B takes out the normal data included in the authentication target data, creates the authenticated data including the normal data, adds the CVN to the authenticated data, and transmits the authenticated data to the local bus 6. The authentication data can be indicated by the ID included in the authenticated data. S560 is a processing step similar to that of S360 described above. After the execution of S560, the process shown in FIG. 8 is terminated.

On the other hand, if the authentication fails in S540, it is determined as NO in S550, and the process proceeds to S570. In S570, the ECU 2B transmits failure notification data indicating an authentication failure to the local bus 6. S570 is a processing step similar to that of S370 described above. After the execution of S570, the process shown in FIG. 8 is terminated. If the surrogate continuation flag is not on (that is, is off) in S516 described above, it is determined as NO in S516. In this case, since the authentication is not requested by another ECU, the received data is discarded in S575. After the execution of S575, the process shown in FIG. 8 is terminated.

Further, in the above-mentioned S520, if the data is not the authentication target data to be processed, it is determined as NO in S520. In this case, although the authentication is requested by another ECU on behalf of the user, the received data is discarded in S575 because the data is not the authentication target data to be processed. After the execution of S575, the process shown in FIG. 8 is terminated. In S514 described above, when the received data is not destined for another ECU (that is, the data is destined for ECU 2C), it is determined as NO in S514, and in that case, the ECU 2C corresponds to the received data in S580. Execute the process. As the process executed in S580, various processes depending on the function of the ECU 2C can be considered, but since the process itself is not a main part in the present embodiment, further description will be omitted. After the execution of S580, the process shown in FIG. 8 is terminated.

When the above processing is being executed in the ECU 2C, the processing shown in FIG. 9 is executed in the ECU 2B. As shown in FIG. 9, the ECU 2B receives data from the local bus 6 in S410. Subsequently, the ECU 2C determines in S420 whether or not the data received in S410 is authenticated data. Here, it can be determined that the data is authenticated based on the ID included in the received data. When the above-mentioned S360 or S560 is executed in the ECU 2C, the authenticated data is transmitted to the second network 1B by broadcast communication. Therefore, the authenticated data reaches all the nodes other than the ECU 2C in the second network 1B.

If the data is authenticated in S420 described above, it is determined to be YES in S420. In that case, the ECU 2B determines in S425 whether or not the spoofing confirmation OK flag is off. The spoofing confirmation OK flag is a flag that is turned on in S445 described later when the initial value is turned off and spoofing confirmation is properly executed in S430 and S440 described later. Here, the description will be continued assuming that the spoofing confirmation OK flag is set to the initial value (that is, off).

When the spoofing confirmation OK flag is turned off, it is determined as YES in S425. In that case, the ECU 2B executes spoofing confirmation for the authenticated data by executing S430 and S440. Specifically, the ECU 2B takes out the CVN added to the authenticated data in S430. Then, in S440, it is determined whether or not the CVN is appropriate. In S440, the CVN extracted from the received authenticated data is compared with the CVN stored in the CVN storage unit 13B. Since the CVNs generated and output by the ECUs 2A to 2D are stored in the CVN storage unit 13B, the CVN corresponding to the ECU 2C is selected as a comparison target in S440.

As a result of this comparison, if both are in agreement, the CVN is appropriate, and it is determined to be YES in S440, and the process proceeds to S445. When the process proceeds to S445, it means that the spoofing confirmation has been properly executed, and the ECU 2B turns on the spoofing confirmation OK flag. Then, the ECU 2B takes out the normal data included in the authenticated data in S450 and uses it in the subsequent processing. As the "subsequent processing" referred to here, various processing according to the function of the ECU 2B can be considered, but since the processing itself is not a main part in the present embodiment, further description will be omitted. After the execution of S450, the process shown in FIG. 9 ends.

On the other hand, in S440 described above, if the comparison results do not match, there is a high possibility that the CVN extracted from the received authenticated data is inappropriate. In this case, there is a possibility that a node other than the ECU 2C impersonates the ECU 2C and transmits the authenticated data. Alternatively, the software of the ECU 2C may have been tampered with, or the ECU 2C may have been replaced. Therefore, under such a situation, even if the authenticated data is received, the reliability of the authenticated data itself is low.

Therefore, if the comparison results in S440 described above do not match, the CVN is inappropriate, and it is determined as NO in S440, and the process proceeds to S460. In S460, the ECU 2B discards the received authenticated data and uses the fail-safe data in the subsequent processing. The fail-safe data is data that is used as a substitute when the authentication target data or the authenticated data received by the ECU 2B cannot be used due to a problem.

Such fail-safe data may be stored in the flash memory 13 in advance, for example. Alternatively, if the data to be authenticated has been received for a long period of time longer than a certain period in the past, the average value, maximum value, minimum value, etc. are calculated over time and prepared so that it can be used as fail-safe data at any time. You may keep it. The form in which the fail-safe data is prepared may be optimized in consideration of the behavior of the control target by the ECU 2B and the like. After the execution of S460, the process shown in FIG. 9 ends.

The process shown in FIG. 9 is executed in the ECU 2B each time the ECU 2B receives data from the local bus 6. At that time, if the processing step of S430-S445 is executed once, it is considered that the authenticated data can be trusted even if it is not executed every time thereafter. Therefore, when the spoofing confirmation OK flag is not off (that is, when it is on), it is determined as NO in S425, and the process proceeds to S450 without executing S430-S445. As a result, the load on the ECU 2B can be reduced by the amount that S430-S445 is not executed.

Further, in the above-mentioned S420, if the data received in the above-mentioned S410 is not the authenticated data, it is determined as NO in the S420. Judge whether or not. Here, it can be determined that the data is failure notification data based on the ID included in the received data. If it is the failure notification data, it is determined as YES in S470, and the process proceeds to S460 described above. Since S460 has already been described, repeated description will be omitted. After the execution of S460, the process shown in FIG. 9 ends.

If it is not the failure notification data in S470 described above, it is determined as NO in S470. In that case, the ECU 2B executes the process corresponding to the received data other than the authenticated data and the failure notification data in S480. As the process executed in S480, various processes depending on the function of the ECU 2B can be considered, but since the process itself is not a main part in the present embodiment, further description will be omitted. After the execution of S480, the process shown in FIG. 9 ends.

[effect]
As described above, according to the above network system 1, even if the authentication of the authentication target data fails in the ECU 2B, if the authentication target data is successfully authenticated in the request destination device ECU 2C, the request source device ECU 2B The contents of the authentication target data included in the authenticated data can be used. Therefore, for example, even if there is a problem such as a failure in the hardware or software required to execute the authentication process in the ECU 2B, the ECU 2B uses the contents of the authentication target data authenticated by the ECU 2C. Period processing can be executed.

Further, in the case of the present embodiment, the ECU 2C, which is the request destination device, turns on the proxy continuation flag in S325 after receiving the proxy request data. After that, the ECU 2C executes S514-S560 every time the authentication target data is transmitted to the requesting device ECU 2B via the first network 1A, and transmits the authenticated data to the ECU 2B. Therefore, the ECU 2B can continuously receive the authenticated data from the ECU 2C without transmitting the proxy request data to the ECU 2C each time the authentication target data is received. Therefore, the load on the ECU 2B can be reduced as compared with the case where the ECU 2B is configured to transmit the proxy request data to the ECU 2C each time the authentication target data is received. In addition, the load on the second network 1B can be reduced by the amount that the transmission frequency of the proxy request data is reduced.

Further, in the case of the present embodiment, after the proxy request data is transmitted, when the authentication target data is received, the ECU 2B executes the authentication process for the authentication target data in S620, and the state in which the authentication fails in the ECU 2B continues. A confirmation process (that is, S610-S630) for confirming whether or not the data is displayed is executed. Therefore, the ECU 2B can execute a more appropriate process according to the result of the confirmation process.

Specifically, as described above, if the state in which the authentication fails in the ECU 2B continues, the result becomes NO in S630, and the authentication by the ECU 2C can be continued on behalf of the user. Further, if the state in which the authentication fails in the ECU 2B does not continue, YES is set in S630, S650 can be executed, and the proxy for authentication by the ECU 2C can be stopped.

Alternatively, the fact that the proxy for authentication by the ECU 2C may be stopped can be saved as diagnostic information by S670. In the case of the present embodiment, the diagnostic information is saved by S172 even when the ECU 2B starts the proxy request. Therefore, it is possible to know after the fact when the ECU 2B starts the proxy request and then stops the proxy request and returns to the normal state based on the diagnostic information.

[Other Embodiments]
Although the network system has been described above with reference to exemplary embodiments, the above-described embodiments are merely exemplified as one aspect of the present disclosure. That is, the present disclosure is not limited to the above-described exemplary embodiments, and can be implemented in various forms without departing from the technical ideas of the present disclosure.

For example, in the above embodiment, the ECU 2B serves as the requesting device and the ECU 2C serves as the requesting device, but any of the ECUs 2A to 2D may serve as the requesting device. Further, among the ECUs 2A to 2D, any of the ECUs other than the requesting device may be the requesting device. Further, the ECUs 3A to 3H may be connected to the local bus 6, and in that case, the ECUs 3A to 3H may be the request source device or the request destination device.

Further, in the above embodiment, an example of performing the authentication process by message authentication is shown, but the authentication may be performed by a method other than the message authentication, or the message authentication and the method other than the message authentication may be used together. .. For example, in the above embodiment, the normal data and the encrypted data are transmitted, the normal data is encrypted on the receiving side, and the encrypted data and the encrypted data are compared to determine whether or not the authentication is successful. However, other authentication procedures can be adopted. For example, even if normal data and encrypted data are transmitted, the encrypted data is decrypted on the receiving side, and the decrypted data is compared with the normal data to determine whether or not authentication is successful. good.

Further, in the above embodiment, by transmitting the CVN when transmitting the authenticated data, the receiving side confirms whether or not the source of the authenticated data is an appropriate node. However, the authenticated data If it is possible to transmit an eigenvalue that can confirm whether or not the source of the node is an appropriate node, it is arbitrary whether or not the eigenvalue is CVN. Further, if a mechanism for confirming whether or not the source of the authenticated data is an appropriate node is separately provided in addition to the mechanism illustrated in the above embodiment, whether or not the node is an appropriate node exemplified in the above embodiment. You may omit the mechanism to confirm whether or not. Alternatively, even when it is sufficiently reliable that the source of the authenticated data is an appropriate node, the mechanism for confirming whether or not the node is an appropriate node illustrated in the above embodiment may be omitted.

Further, in the above embodiment, once it is confirmed whether or not the source of the authenticated data is an appropriate node, the confirmation is omitted from the second time onward, but the same confirmation is omitted from the second time onward. It may be carried out without.

Further, in the above embodiment, in S172 and S670, an example of storing the diagnostic information in the diagnostic storage unit 13C is shown, but in addition to storing the diagnostic information in such a non-volatile storage area, the diagnostic information is output as a predetermined value. It may be output first. For example, diagnostic information may be output to a display device such as a display or a warning light mounted on a vehicle.

Alternatively, the diagnostic information may be output to a wireless communication device mounted on the vehicle. In this case, the wireless communication device can further transmit the diagnostic information by wireless communication, and the receiving device that receives the diagnostic information can save or output the diagnostic information. Such a receiving device may be a wireless communication terminal (for example, a smartphone or a personal computer) owned by the user of the vehicle, or when the state of the customer's vehicle is managed by a car dealer or the like. It may be configured as a management device installed in an automobile dealer or the like. If such a management device is provided, an event that has occurred in the customer's vehicle can be easily grasped by an automobile dealer or the like.

Further, in the above embodiment, a plurality of global buses 5A, 5B, 5C are connected to each other by a single CGW 4, but if a plurality of global buses 5A, 5B, 5C are configured to be connectable to each other. , Multiple gateways may be adopted. For example, by connecting the global bus 5A and the global bus 5B at the first gateway and connecting the global bus 5B and the global bus 5C at the second gateway, the global bus 5A and the global bus 5C are two gateways. And may be configured to be communicable via the global bus 5B.

In addition to the above, the function realized by one component in each of the above embodiments may be configured to be realized by a plurality of components. Further, the function realized by a plurality of components may be configured to be realized by one component. Further, a part of the configuration of each of the above embodiments may be omitted. In addition, at least a part of the configuration of each of the above embodiments may be added or replaced with respect to the configuration of the other embodiment. In addition, all aspects included in the technical idea specified from the wording described in the claims correspond to the embodiment of the present disclosure.

In addition to the network system described above, an electronic device capable of configuring the network system of the present disclosure, a vehicle equipped with the network system of the present disclosure, a program for operating a computer as the electronic device referred to in the present disclosure, and this program are recorded. The present disclosure can also be realized in various forms such as a recording medium.

[supplement]
As is clear from the exemplary embodiments described above, the network system of the present disclosure may further include the following configurations.

In one aspect of the present disclosure, the requesting device may be configured to execute the authentication process and the confirmation process at a frequency lower than the frequency of receiving the authentication target data after the proxy request data is transmitted (). S610-S630).

In one aspect of the present disclosure, the requesting device may be configured to store or output information indicating that the authentication has failed when the authentication fails in the authentication process (S172).
In one aspect of the present disclosure, if the requesting device can confirm by the confirmation process that the state in which the authentication fails in the requesting device does not continue, the requesting device requests the requesting device to stop the authentication process on behalf of the requesting device. The cancellation request data for this purpose may be configured to be transmitted to the request destination device via the second network (S650). The requesting device may be configured to return to the state of executing the authentication process when the authentication target data is received after the cancellation request data is transmitted (S660).

In one aspect of the present disclosure, the requesting device may be configured to store or output information indicating the return when the state returns to the state in which the authentication process is executed (S670).

1 ... Network system, 1A ... First network, 1B ... Second network, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, 3E, 3F, 3G, 3H ... ECU, 5A, 5B, 5C ... Global Bus, 6 ... Local bus, 7 ... External communication path, 11 ... CPU, 12 ... RAM, 12A ... Received data buffer, 13 ... Flash memory, 13A ... Common key storage, 13B ... CVN storage, 13C ... Diag storage , 16 ... 1st communication department, 17 ... 2nd communication department.

Claims (5)

A plurality of electronic devices (2A, 2B) configured to function as a node of the first network (1A) and also as a node of the second network (1B) constructed independently of the first network. , 2C, 2D)
The plurality of electronic devices are configured to be able to communicate with the first network and external devices outside the second network via the first network.
At least one of the plurality of electronic devices is configured to be functional as a requesting device (2B).
At least one of the plurality of electronic devices is configured to be functional as a requesting device (2C).
When one of the plurality of electronic devices functions as the requesting device, at least one electronic device different from the requesting device is configured to be able to function as the requesting device.
When the authentication target data to be authenticated is transmitted to the request source device via the first network, the request source device receives the authentication target data and authenticates the authentication target data. The process is executed (S120, S210-S250), and if the authentication is successful, the content of the authentication target data is used in the process after the successful authentication (S140), and if the authentication fails, the request is made. It is configured to transmit the proxy request data for requesting the destination device to perform the authentication process to the request destination device via the second network (S150, S160).
After receiving the proxy request data, the request destination device receives the authentication target data each time the authentication target data is transmitted to the request source device via the first network (S510, S514). , S520) When the authentication process for the authentication target data is executed (S540) and the authentication is successful, the authenticated data including the contents of the authentication target data that has been successfully authenticated is sent to the requester via the second network. Configured to transmit to the device (S550, S560),
When the requesting device receives the authenticated data, the requesting device is configured to utilize the content of the authentication target data included in the authenticated data (S450).
After the proxy request data is transmitted, when the requesting device receives the authentication target data, the requesting device executes an authentication process for the authentication target data, and the requesting device continues to fail in authentication. It is configured to execute a confirmation process for confirming whether or not it is present (S182, S610-S630).
Network system. The network system according to claim 1.
After the proxy request data is transmitted, the request source device is configured to execute the authentication process and the confirmation process at a frequency lower than the frequency of receiving the authentication target data (S610).
Network system. The network system according to claim 1 or 2.
The requesting device is configured to store or output information indicating that the authentication has failed when the authentication fails in the authentication process (S172).
Network system. The network system according to any one of claims 1 to 3.
When the requesting device can confirm by the confirmation process that the state in which the authentication fails in the requesting device does not continue, the requesting device is stopped to request the requesting device to stop the authentication processing on behalf of the requesting device. The request data is configured to be transmitted to the request destination device via the second network (S650).
After the cancellation request data is transmitted, the requesting device is configured to return to the state of executing the authentication process when the authentication target data is received (S660).
Network system. The network system according to claim 4.
When the requesting device returns to the state in which the authentication process is executed, the requesting device is configured to save or output information indicating the return (S670).
Network system.

Images