Patent Description:
An in-vehicle system of an automobile is beginning to be connected to a center system and a device outside the vehicle. Accompanying therewith, preparation against cyber security attacks from outside the vehicle has become important. However, many of the control devices mounted in the in-vehicle system operate with limited resources. Patent Literature <NUM> discloses a multiprocessor system that executes processing while mutually using resources of each of a plurality of processors, the multiprocessor system including an execution permission determination means that determines whether or not to permit execution of processing belonging to a second processor using resources of the second processor by a first processor.

In the invention described in Patent Literature <NUM>, safety measures are not sufficient. In particular, in an environment in which a multiprocessor core is mounted, when an unauthorized message is received, a countermeasure when the first verification is broken or avoided is not sufficient. Patent Literature <NUM> discloses a method for inter-controller communication in a protocol agnostic manner.

An arithmetic device according to a first aspect of the present invention is set forth in claim <NUM>.

According to the present invention, in an environment in which a multiprocessor core is mounted, even if the first verification is broken or avoided when an unauthorized message is received, the target device can be protected from the unauthorized message by the second verification.

Hereinafter, an embodiment of an arithmetic device according to the present invention will be described with reference to <FIG>.

<FIG> is a hardware configuration diagram of an arithmetic device <NUM> according to the present invention. In the arithmetic device <NUM>, a first core <NUM>, a second core <NUM>, a third core <NUM>, an interface unit <NUM>, a RAM <NUM>, and a ROM <NUM> are connected via a communication bus <NUM>. The first core <NUM>, the second core <NUM>, and the third core <NUM> develop and execute the programs stored in the ROM <NUM> in the RAM <NUM>, thereby implementing the functions described later. Hereinafter, the first core <NUM>, the second core <NUM>, and the third core <NUM> are collectively referred to as a core <NUM>. Each of the first core <NUM>, the second core <NUM>, and the third core <NUM> is a physical core, and may be independently packaged, or the core <NUM> may be enclosed in one package.

Note that the ROM <NUM> stores verification determination information <NUM>, verification request destination information <NUM>, and authority management information <NUM>. The verification determination information <NUM>, the verification request destination information <NUM>, and the authority management information <NUM> are referred to by the core <NUM>. Specific description of the verification determination information <NUM>, the verification request destination information <NUM>, and the authority management information <NUM> will be given later.

The interface unit <NUM> receives a communication message from outside the arithmetic device <NUM> and saves the communication message in the RAM <NUM>. In addition, the interface unit <NUM> transmits information saved in the RAM <NUM> or the RAM <NUM> to the outside of the arithmetic device <NUM> as a communication message. The communication bus standard to which the interface unit <NUM> corresponds is CAN (registered trademark), LIN (registered trademark), FlexRay (registered trademark), Ethernet (registered trademark), or the like. The interface unit <NUM> may correspond to at least one communication standard.

The communication message is electronic data transmitted and received through communication, and is also referred to as a "packet", a "data frame", a "datagram", or the like. Furthermore, the communication message does not have to be a "packet" or the like itself, and may be, for example, a plurality of "packets" or the like combined or decoded according to a predetermined procedure. Furthermore, the communication message may be the entire message including the header or only the payload excluding the header.

<FIG> is a functional configuration diagram of the arithmetic device <NUM>. The arithmetic device <NUM> is connected to a first bus <NUM>, a second bus <NUM>, and a third bus <NUM>. The arithmetic device <NUM> is mounted on a vehicle, for example, the first bus <NUM> and the second bus <NUM> are communication buses connected to the outside of the vehicle, and the third bus <NUM> is a communication bus connected to the inside of the vehicle. The second bus <NUM> can also be referred to as an "internal communication bus", and the third bus <NUM> can also be referred to as an "external communication bus". For example, a message received from the outside of the vehicle by a wireless communication unit (not illustrated) is input to the arithmetic device <NUM> via the first bus <NUM> and the second bus <NUM>, and output to the third bus <NUM> inside the vehicle via the arithmetic device <NUM>. An electronic control device that controls the vehicle is connected to the third bus <NUM>. In the present embodiment, an operation for describing verification of authenticity of a communication message received by the arithmetic device <NUM> via the first bus <NUM> will be mainly described.

The relationship between the communication bus and the core <NUM> illustrated in <FIG> is conceptual, and a message input from each communication bus is first processed by the connected core <NUM>. For example, when the arithmetic device <NUM> receives a message from the first bus <NUM>, which is a situation mainly described in the present embodiment, the first core <NUM> first performs a process. Specifically, the first core <NUM> performs the first verification, and the other cores perform the second verification. Details will be described later. Hereinafter, the first verification may be referred to as "first verification" or "first verification". Hereinafter, the second verification may be referred to as "second verification" or "second verification".

Each of the first bus <NUM>, the second bus <NUM>, and the third bus <NUM> may be physically a plurality of communication buses. Standards of communication buses to which each of the first bus <NUM>, the second bus <NUM>, and the third bus <NUM> corresponds may all be the same or may be different. The standard of the communication bus to which the first bus <NUM>, the second bus <NUM>, and the third bus <NUM> correspond is the standard of the interface unit <NUM> illustrated in <FIG> or the like.

The arithmetic device <NUM> includes, as its functions, a first verification unit <NUM>, a second verification unit <NUM>, a control unit <NUM>, a verification destination determination processing unit <NUM>, a verification request processing unit <NUM>, and an authority management unit <NUM>. In the present embodiment, the first core <NUM> executes the first verification unit <NUM>, the second core <NUM> executes the second verification unit <NUM>, the control unit <NUM>, the verification destination determination processing unit <NUM>, and the verification request processing unit <NUM>, and the third core <NUM> executes the second verification unit <NUM>, the control unit <NUM>, and the authority management unit <NUM>.

The second verification unit <NUM> and the control unit <NUM> are executed by both the second core <NUM> and the third core <NUM>. This does not mean that two cores perform one processing in cooperation, but that each core can execute processing independently. That is, each of the second verification unit <NUM> and the control unit <NUM> may be executed by the second core <NUM> or may be executed by the third core <NUM>. Which core performs the above-described process will be described later. Note that since the same output can be obtained for a certain input, the second verification unit <NUM> and the control unit <NUM> are denoted with the same reference numerals regardless of the core that executes the same, and means for realizing each may be different. For example, the program code for the second core <NUM> to realize the second verification unit <NUM> and the program code for the third core <NUM> to realize the second verification unit <NUM> may not be the same.

The first verification unit <NUM> and the second verification unit <NUM> verify the authenticity of the communication message received by the arithmetic device <NUM>. The first verification unit <NUM> and the second verification unit <NUM> are executed by different cores. In the present embodiment, verification of authenticity of a communication message received by the arithmetic device <NUM> via the first bus <NUM> will be mainly described as described above. Therefore, the verification unit of the first core <NUM> that first verifies the communication message is named differently from the verification units of the second core <NUM> and the third core <NUM> for the sake of convenience. The first verification unit <NUM> and the second verification unit <NUM> may verify the authenticity of the communication message through the same method or may verify the authenticity of the communication message through different methods.

The verification destination determination processing unit <NUM> executed by the second core <NUM> determines whether or not the second core <NUM> itself executes the second verification of the communication message, that is, the operation of the second verification unit <NUM>. In a case where the verification destination determination processing unit <NUM> determines that the second verification of the communication message should be requested to a processor core other than itself, the verification request processing unit <NUM> executed by the second core <NUM> requests the processor core corresponding to a predetermined rule to verify the communication message.

The control unit <NUM> executed by the second core <NUM> and the third core <NUM> executes a predetermined process according to the given authority.

The authority management unit <NUM> executed by the second core <NUM> and the third core <NUM> controls the authority to be given to each core <NUM> according to the processing content. The authority control is, for example, permission to access a specific area of the RAM <NUM>. The authority management unit <NUM> controls the authority only for the processing content of which authenticity is confirmed in the verification result of the second verification unit <NUM>. That is, in a case where the authenticity cannot be confirmed by any of the first verification unit <NUM> and the second verification unit <NUM>, the authority is not changed. The authority management unit <NUM> is preferably provided only in the third core <NUM> that is not directly connected to the outside of the vehicle.

<FIG> is a diagram illustrating an example of the verification determination information <NUM>. The verification determination information <NUM> has a plurality of records, and each record has fields of a processing ID <NUM> and a processing propriety <NUM>. The processing ID <NUM> is an identifier for identifying processing contents to be executed. The processing ID <NUM> may have any format as long as it can be identified, and may be any numerical value as illustrated in <FIG>, an IP address, or the like. The processing propriety <NUM> indicates whether or not the second core <NUM> itself processes the communication message having the processing ID <NUM> of the same record. In the example illustrated in <FIG>, "<FIG>" indicates that the second core <NUM> itself performs processing, and "<NUM>" indicates that a core other than the second core <NUM> performs processing. The processing ID <NUM> may be included in the communication message, and when the processing ID is distinguished for each communication message, the communication ID may be used as the processing ID.

The verification destination determination processing unit <NUM> refers to the verification determination information <NUM> to determine whether or not the second core <NUM> processes the received communication message. The verification destination determination processing unit <NUM> first specifies the processing ID of the received communication message. Next, the verification destination determination processing unit <NUM> reads the propriety of the process corresponding to the specified processing ID from the verification determination information <NUM>. When the read processing propriety is "<NUM>", it is determined that the second core <NUM> performs the process, and when the read processing propriety <NUM> is "<NUM>", it is determined that the second core <NUM> does not perform the process.

<FIG> is a diagram illustrating an example of the verification request destination information <NUM>. The verification request destination information <NUM> has a plurality of records, and each record has fields of a processing ID <NUM> and a core ID <NUM>. The processing ID <NUM> is an identifier for identifying processing contents to be executed, and is the same as _701 of the verification determination information <NUM>. The core ID <NUM> indicates an identifier of the core <NUM> that verifies a communication message having the processing ID <NUM> of the same record. The core ID <NUM> is any of, for example, "0x001" corresponding to the first core <NUM>, "0x002" corresponding to the second core <NUM>, or "0x003" corresponding to the third core <NUM>. However, in the present embodiment, since the first core <NUM> performs the first verification, the core <NUM> indicated by the core ID <NUM> of the verification request destination information <NUM> is either the second core <NUM> or the third core <NUM>.

The verification request processing unit <NUM> refers to the verification request destination information <NUM> to specify the verification request destination of the received communication message. The verification request processing unit <NUM> first specifies a processing ID of the received communication message. Next, the verification request processing unit <NUM> reads the core <NUM> that performs the second verification of the communication message having the specified processing ID from the verification determination information <NUM>. When the read core ID <NUM> is "0x002", the second core <NUM> itself is requested to perform the process, and when the read core ID is "0x003", the third core <NUM> is requested to perform the process.

<FIG> is a diagram illustrating an example of the authority management information <NUM>. The authority management information <NUM> has a plurality of records, and each record has fields of a processing ID <NUM>, a first core authority <NUM>, a second core authority <NUM>, and a third core authority <NUM>. The processing ID <NUM> is an identifier for identifying processing contents to be executed, and is the same as _701 of the verification determination information <NUM> and _801 of the verification request destination information <NUM>. Each of the first core authority <NUM>, the second core authority <NUM>, and the third core authority <NUM> indicates presence or absence of authorization to each of the first core <NUM>, the second core <NUM>, and the third core. In the example illustrated in <FIG>, "<NUM>" indicates that the authority is not to be given, and "<NUM>" indicates that the authority is to be given.

In the example illustrated in <FIG>, only the presence or absence of authorization is illustrated, but the type, range, and the like of the authority to be given may also be illustrated. The type of authority is, for example, only reading, only writing, reading and writing, and the like. The range of authority is, for example, a range of street number in an address space or a temporal range in which authority is given.

The authority management unit <NUM> refers to the authority management information <NUM> and gives the authority necessary for the process caused by the received communication message. The authority management unit <NUM> first specifies the processing ID of the received communication message. Next, the authority management unit <NUM> gives authority to the core <NUM> corresponding to the specified processing ID. For example, when the processing ID is "0x002", the authority management unit <NUM> gives authority to the second core <NUM> and the third core.

<FIG> is an overall processing sequence diagram of the authentication system when the first core <NUM> receives a communication message. In step S301, the first verification unit <NUM> verifies the authenticity of the communication message received via the interface unit <NUM> on the basis of a predetermined rule. In the subsequent step S302, the first core <NUM> notifies the second core <NUM> that the communication message has been received. Note that in a case where the authenticity cannot be confirmed in step S301, the first core <NUM> performs abnormality handling process.

In the subsequent step S303, the verification destination determination processing unit <NUM> realized by the second core <NUM> determines whether or not to request the core <NUM> other than itself, that is, other than the second core <NUM> to perform the second verification of the communication message of which the authenticity has been verified in step S301. However, in the description of this drawing, it is assumed that the verification destination determination processing unit <NUM> determines in step S303 that the verification is to be requested to the core <NUM> other than itself.

The verification request processing unit <NUM> determines the core <NUM> to be a verification destination to which the second verification of the communication message is requested (step S304), and notifies the core <NUM> of the verification request (step S305). In step S306, the second verification unit <NUM> of the third core <NUM> verifies the authenticity of the communication message of which the first verification has been performed in step S301 based on a predetermined rule. In step S307, the second verification unit <NUM> confirms the presence or absence of authenticity, which is the verification result of step S306.

In step S308, in a case where the authenticity is confirmed in step S307, the authority management unit <NUM> confirms whether or not it is necessary to give authority in the processing of the communication message. In step S309, the authority management unit <NUM> gives the authority determined to be necessary in step S308, that is, updates the authority. In step S310, the third core <NUM> notifies the second core <NUM> of the verification result confirmed in step S307.

In step S311, the verification request processing unit <NUM> confirms authenticity and authorization according to the verification result notified in step S310. In step S312, the control unit <NUM> executes the communication message according to a predetermined processing. In step S313, the second core <NUM> notifies the third core <NUM> that the processing of the communication message has completed.

In step S314, when receiving the completion notification notified in step S313, the authority management unit <NUM> confirms whether or not the authority has been given in step S309. In step S315, when it is confirmed in step S314 that the authority has been given, the authority management unit <NUM> cancels the given authority.

According to the above steps, in the authentication processing system, when the arithmetic device <NUM> receives a communication message from outside the device, in addition to the first verification by the first core <NUM>, the second core <NUM> or the third core <NUM> executes the second verification via the second core <NUM> that has not received a message from outside the device, and the vehicle can be maintained in a safe state against unauthorized communication transmitted from outside the vehicle.

<FIG> is a flowchart illustrating processes related to step S301 to step S302 of the first core <NUM> in <FIG>. Specifically, the flowchart illustrated in <FIG> illustrates a process of verifying the communication message and notifying the second core <NUM> of the reception of the communication message.

In step S401, the first core <NUM> receives a communication message from outside the device using the interface unit <NUM>. In the subsequent step S402, the first core <NUM> verifies whether or not the communication message received in step S401 is a correct communication message using the first verification unit <NUM>. For example, the first verification unit <NUM> may adopt any one of the following three determination methods or may adopt other methods.

A first method is a method of determining as correct when a communication ID included in the communication message is a predetermined communication ID, and determining as not correct when the communication ID is not the predetermined communication ID. A second method is a method of determining as correct when a communication message is received within a predetermined communication cycle, and determining as not correct when the communication message is not received within the communication cycle. A third method is a method of determining as correct when a value of a message authentication code (MAC) included in the communication message matches a value of a MAC generated on the basis of the communication message, and determining as not correct when the values do not match.

In step S403, the first core <NUM> proceeds to step S405 when determining that the communication message is correct in step S402, and proceeds to step S404 when determining that the communication message is not correct. In step S404, the first core <NUM> executes a predetermined abnormality handling process. For example, the first core <NUM> may discard the received communication message, and in addition, may notify the inside and outside of the device that an abnormality has occurred.

In step S405, the first core <NUM> notifies the second core <NUM> that the communication message has been received. However, the first core <NUM> may notify the predetermined core <NUM> other than the second core <NUM>, or may notify the core <NUM> corresponding to the communication ID included in the communication message. Furthermore, the first core <NUM> may check the processing load of the core <NUM> other than itself and notify the core <NUM> in which the processing load is less than or equal to a certain standard, or may notify all the processor cores other than itself.

Through the above steps, the first core <NUM> can verify the received communication message and notify another processor core of the reception of the communication message based on the verification result.

<FIG> is a flowchart illustrating processing of the second core <NUM> in <FIG>, that is, processes from step S303 to step S305 and processes from step S311 to step S313. Specifically, the flowchart illustrated in <FIG> illustrates a process of determining the necessity of verification of a communication message, determining a verification destination according to the determination result, and executing a control process according to the verification result.

In step S501, the second core <NUM> receives the notification on the reception of the communication message from the first core <NUM> and acquires the communication message. In step S502, the second core <NUM> acquires the communication ID included in the received communication message. In step S503, the verification destination determination processing unit <NUM> of the second core <NUM> refers to the verification determination information <NUM> and determines whether or not the communication ID acquired in step S502 is a processing target of the second core <NUM> itself. For example, when the processing ID included in the communication message acquired in step S501 is "0x002", the verification destination determination processing unit <NUM> determines that the communication message is not the verification target since the processing propriety <NUM> is "<NUM>" in the verification determination information <NUM> illustrated in <FIG>.

In step S504, the second core <NUM> verifies whether or not the communication message received in step S501 is a correct communication message using the second verification unit <NUM>, and proceeds to step S509. For example, when the communication ID included in the communication message is a predetermined communication ID, determination is made as correct.

In step S505, the verification request processing unit <NUM> of the second core <NUM> refers to the verification request destination information <NUM>, and selects a verification request destination. For example, when the processing ID of the communication message acquired in step S501 is "0x002 ", the verification request processing unit <NUM> selects the third core <NUM> as the verification request destination since the core ID <NUM> associated with the processing ID <NUM> is" 0x003" in the verification request destination information <NUM> illustrated in <FIG>.

In step S506, the verification request processing unit <NUM> of the second core <NUM> transmits a verification request notification to the verification request destination selected in step S505. In step S507, the second core <NUM> waits for the result of the verification request transmitted in step S506 to be returned. In step S508, the second core <NUM> proceeds to step S509 when receiving the verification result, and returns to step S507 when not receiving the verification result.

In step S509 executed after step S504 or when an affirmative determination is made in step S508, the second verification unit <NUM> of the second core <NUM> confirms the result of the second verification process, and proceeds to step S510 when determination is made that there is an abnormality, and proceeds to step S511 when determination is made that there is no abnormality. In step S510, the second core <NUM> executes a predetermined abnormality handling process. For example, the received communication message may be discarded, and in addition, the occurrence of an abnormality may be notified to the inside and outside of the device. In step S511, the second core <NUM> executes a predetermined control corresponding to the processing ID.

Through the above processes, the second core <NUM> can determine the necessity of verification of the communication message, determine the verification destination according to the determination result, and execute the control process according to the verification result.

<FIG> is a flowchart illustrating processes from step S306 to step S310 and from step S314 to step S315 of the third core <NUM> in <FIG>. Specifically, the flowchart illustrated in <FIG> illustrates process of performing the second verification process and updating the authority according to the verification result.

In step S601, the third core <NUM> receives a notification on the reception of the communication message from the second core <NUM> and acquires the communication message. In step S602, the second verification unit <NUM> of the third core <NUM> verifies whether or not the communication message received in step S601 is a correct communication message.

In step S603, the second verification unit <NUM> of the third core <NUM> confirms the result of the second verification process, and proceeds to step S604 if there is abnormality, and proceeds to step S605 if there is no abnormality. In step S604, the third core <NUM> executes a predetermined abnormality handling process. For example, the received communication message may be discarded, and in addition, the occurrence of an abnormality may be notified to the inside and outside of the device.

In step S605, the authority management unit <NUM> of the third core <NUM> acquires the processing ID included in the communication message, and refers to the authority management information <NUM> to confirm whether or not the processing ID requires authority change. For example, if it is unnecessary to give authority to all the cores, authority change is unnecessary. In step S606, the authority management unit <NUM> of the third core <NUM> proceeds to step S607 when determining that the authority change is necessary in step S605, and proceeds to step S608 when determining that the authority change is not necessary.

In step S607, the third core <NUM> refers to the authority management information <NUM> using the authority management unit <NUM>, and updates the authority of the corresponding processing ID. In step S608, the third core <NUM> notifies the second core <NUM> of the verification result in step S602. In the subsequent step S609, the third core <NUM> waits for the control completion notification from the second core <NUM>. In step S610, the third core <NUM> proceeds to step S611 when receiving the completion notification of the control process from the second core <NUM>, and returns to step S609 when not receiving the completion notification.

In step S611, the third core <NUM> confirms the presence or absence of authority change in step S607. For example, an update presence/absence flag having an initial value of "<NUM>" is stored in the RAM <NUM>, and the third core <NUM> updates the update presence/absence flag to "<NUM>" when the authority management unit <NUM> changes any of the authorities, and determines the presence or absence of authority change when the authority management unit <NUM> confirms the value of the update presence/absence flag.

In step S612, the third core <NUM> proceeds to step S613 when determining that the authority has been changed in step S611, and terminates the present process when determining that the authority has not been changed. In step S613, the third core <NUM> changes the authority updated in step S607 to the authority before the update using the authority management unit <NUM>.

Through the above process, the third core <NUM> can perform the second verification process and update the authority according to the verification result.

The embodiment described above has the following operation effects.

At least one of the verification determination information <NUM> and the verification request destination information <NUM> may be stored in the ROM <NUM> of the arithmetic device <NUM>. When the verification determination information <NUM> is not stored in the ROM <NUM>, the verification destination determination processing unit <NUM> uses the verification request destination information <NUM> as a substitute for the verification determination information <NUM>. That is, _34 can be a substitute for the verification determination information <NUM> by reading the verification request destination information <NUM> and determining whether or not the core ID <NUM> indicates the second core <NUM>.

In addition, when the verification request destination information <NUM> is not stored in the ROM <NUM>, the verification request processing unit <NUM> determines the third core <NUM> as the verification request destination without any reference. This is because when there are only <NUM> cores, only the third core <NUM> remains according to the method of elimination. Specifically, the cores capable of executing the second verification process are two cores excluding the first core <NUM> that has performed the first verification process, where if the second core <NUM> does not execute the second verification process, only the third core <NUM> can execute the second verification process.

The present modified example has the following operation effects.

(<NUM>) The arithmetic device <NUM> includes three cores. The second core <NUM> includes a verification request processing unit <NUM> that requests the third core <NUM> to execute the second verification process when the verification destination determination processing unit <NUM> determines that the second core <NUM> does not execute the second verification process.

In the embodiment described above, the verification destination determination processing unit <NUM> and the verification request processing unit <NUM> determine the core <NUM> to execute the second verification process only from the processing ID, which is the identifier included in the message. However, the verification destination determination processing unit <NUM> and the verification request processing unit <NUM> may determine the core <NUM> to execute the second verification process based on the instruction content of the message. More specifically, even in a case of determining that the second core <NUM> executes the second verification process based on the identification information, the verification destination determination processing unit <NUM> and the verification request processing unit <NUM> may determine that the third core <NUM> executes the second verification process when the instruction content of the message meets a predetermined condition.

The predetermined condition regarding the message is, for example, the following two cases. The first case is a case where an instruction to transfer at least a part of the message to the third bus <NUM>, which is a communication bus connected to the inside of the vehicle, is included. The second case is a case where authority is given in the processing of the message.

(<NUM>) The arithmetic device <NUM> is mounted on a vehicle. The arithmetic device <NUM> is connected to a first bus <NUM>, a second bus <NUM>, which are external communication buses of the vehicle, and a third bus <NUM>, which is an internal communication bus. The first core <NUM> and the second core <NUM> transmit and receive messages to and from the external communication bus. The third core <NUM> transmits and receives messages to and from the internal communication bus. Even in a case of determining that the second core <NUM> executes the second verification process based on the identification information, the verification destination determination processing unit <NUM> and the verification request processing unit <NUM> of the second core <NUM> may determine that the third core <NUM> executes the second verification process when the instruction content of the message meets a predetermined condition.

In the embodiment described above, the verification destination determination processing unit <NUM> and the verification request processing unit <NUM> are provided in the second core <NUM>. However, the verification destination determination processing unit <NUM> and the verification request processing unit <NUM> may be provided in the third core <NUM>. In this case, the verification destination determination processing unit <NUM> and the verification request processing unit <NUM> may be provided only in the third core <NUM>, or may be provided in the second core <NUM> and the third core <NUM>.

Note that, in the embodiment, the operation for describing the verification of the authenticity of the communication message received by the arithmetic device <NUM> via the first bus <NUM> has been mainly described, but in practice, the verification of the authenticity of the communication message received by the arithmetic device <NUM> via the second bus <NUM> is also performed, and hence a configuration in which the verification destination determination processing unit <NUM> and the verification request processing unit <NUM> are also provided in the first core <NUM> is also assumed.

<FIG> is a functional configuration diagram of the arithmetic device <NUM> according to a third modified example. <FIG> illustrates the maximum possible configuration, and the verification in the first core <NUM> and the second core <NUM> can also be referred to as both the first verification unit <NUM> and the second verification unit <NUM> depending on the input source of the message, and hence the verification unit 30A is defined to serve as both verification units. As illustrated in <FIG>, the functional configurations of the first core <NUM> and the second core <NUM> are the same, and the functional configuration of the third core <NUM> further includes an authority management unit <NUM> in addition to the functional configurations of the first core <NUM> and the second core <NUM>.

(<NUM>) The arithmetic device <NUM> includes three or more cores that perform arithmetic processing. An interface unit <NUM> that receives a message from the outside of the arithmetic device <NUM>; a first verification unit <NUM> that performs a first verification process on the message; a second verification unit <NUM> that performs a second verification process on the message; and a specifying unit that specifies a core to execute the second verification process based on identification information included in the message, that is, a verification destination determination processing unit <NUM> and a verification request processing unit <NUM> are provided. The first verification unit <NUM> and the second verification unit <NUM> are realized by different cores. Therefore, various variations can be given in the functional configuration of the arithmetic device <NUM>.

In the embodiment described above, the arithmetic device <NUM> includes three cores. However, the arithmetic device <NUM> may include four or more cores. In this case, in the verification request destination information <NUM>, the variation of the value of the core ID <NUM> increases according to the number of cores. In addition, in the authority management information <NUM>, a field of each record has a field corresponding to the number of cores. However, since the processing propriety <NUM> of the verification determination information <NUM> can only take the value of "<NUM>" or "<NUM>", there is no formal difference.

At least one of the first core <NUM>, the second core <NUM>, and the third core <NUM> may be realized by a field programmable gate array (FPGA) which is a rewritable logic circuit or an application specific integrated circuit (ASIC) which is an application specific integrated circuit. According to the fifth modified example, the arithmetic device <NUM> can be realized by various hardware configurations.

The third core <NUM> may execute the control process when determining that there is no abnormality in step S603 of <FIG>. That is, in the embodiment, the control process is executed by the second core <NUM>, but the control process may be executed by the third core <NUM>.

In the embodiment described above and the modified examples, the configuration of the functional block is merely an example. Some functional configurations illustrated as separate functional blocks may be integrally configured, or a configuration illustrated in one functional block diagram may be divided into two or more functions. In addition, some of the functions of each functional block may be included in another functional block.

Although not specifically described in the above-described embodiment, the encryption key and the seed merely need to be safely distributed, managed, and updated, and distribution and update may be performed at an arbitrary timing such as at the time of starting/stopping of the engine of the vehicle, at the time of product development, and at the time of maintenance.

Claim 1:
An arithmetic device (<NUM>) comprising a first core (<NUM>), a second core (<NUM>), and one or more other cores that perform arithmetic processing, wherein
the first core (<NUM>) includes a first verification unit (<NUM>) that performs a first verification process on a message received from outside of the arithmetic device (<NUM>), and
the second core (<NUM>) includes a verification destination determination processing unit (<NUM>) that determines, based on identification information included in the message, whether or not the second core (<NUM>) executes a second verification process on the message; and
characterised in that
the second core (<NUM>) further includes a verification request processing unit (<NUM>) that, when the verification destination determination processing unit (<NUM>) determines that the second core (<NUM>) does not execute the second verification process based on the identification information, specifies, based on the identification information, one of the other cores that executes the second verification process and requests execution of the second verification process.