CN112822196B

CN112822196B - Communication method and system for central domain control

Info

Publication number: CN112822196B
Application number: CN202110023949.3A
Authority: CN
Inventors: 刘宗成; 陈芮; 游锋; 王君; 徐二勇
Original assignee: Chongqing Branch of DFSK Motor Co Ltd
Current assignee: Chongqing Branch of DFSK Motor Co Ltd
Priority date: 2021-01-08
Filing date: 2021-01-08
Publication date: 2022-11-29
Anticipated expiration: 2041-01-08
Also published as: CN112822196A

Abstract

The application relates to a communication method and a system for central domain control; the method comprises the following steps: when the actuator is on line, sending a pre-agreed on-line request and self identity information to the controller; the controller generates a first private key and a first public key and sends the first public key to the executor in a response mode; the actuator encrypts the second private key and sends the second private key to the controller, and simultaneously sends the software interface ciphertext and the interface snapshot to the controller; the controller decrypts the software interface ciphertext and calculates the snapshot of the decrypted interface by using the same snapshot algorithm; the controller compares the calculated snapshot with the received interface snapshot; and if the snapshot is successfully matched, the controller is connected with the actuator, and data transmission is carried out through a software interface of the actuator. The communication method CAN realize the handshake authentication of the actuator of the CAN in the vehicle and the central domain control controller, realize the plug and play of the CAN nodes, and CAN ensure the communication safety in the vehicle.

Description

Communication method and system for central domain control

Technical Field

The application relates to the technical field of in-vehicle communication control, in particular to a communication method and system for central domain control.

Background

At present, the software defined automobile concept is more mature, and the SOA architecture concept CAN not be realized for the traditional vehicle-mounted bus CAN bus development. The traditional distributed architecture is gradually converted into a domain control architecture and a central domain control architecture. The number of controllers is gradually reduced, and the CAN nodes are gradually changed into actuators from the controllers.

With the development of new technologies such as internet of vehicles, OTA, and automatic driving, OEMs (Original Equipment manufacturers) pay more attention to vehicle information security. In CAN bus based vehicle models, most OEMs focus on TSP platform-to-vehicle TBOX information security, and there are few in-vehicle information transmission schemes, mainly because in-vehicle information security encryption (SecOC) has high requirements for network bandwidth, and CAN bus bandwidth is often not sufficient to support.

Disclosure of Invention

To overcome, at least in part, the problems in the related art, the present application provides a centrally-controlled communication method and system.

According to a first aspect of embodiments of the present application, a central domain-controlled communication method is provided, including:

when the actuator is on line, sending a pre-agreed on-line request and self identity information to the controller;

the controller generates a first private key and a first public key and sends the first public key to the executor in a response mode;

the executor encrypts the second private key and then sends the second private key to the controller, and simultaneously sends the software interface ciphertext and the interface snapshot to the controller;

the controller decrypts the software interface ciphertext and calculates the snapshot of the decrypted interface by using the same snapshot algorithm;

the controller compares the calculated snapshot with the received interface snapshot;

if the snapshot is successfully matched, the controller is connected with the actuator, and data transmission is carried out through a software interface of the actuator; if the snapshot match fails, the connection fails.

Further, the identity information of the actuator is an MAC address; accordingly, the controller generates a first private key and a first public key, including:

the controller records the MAC address of the actuator after receiving the online request, and simultaneously generates a pair of secret keys comprising a first private key and a first public key.

Further, the actuator encrypts a second private key by using a first public key and then sends the second private key to the controller;

and the software interface ciphertext is generated by encrypting the executor through a second private key.

Further, the controller decrypts the software interface ciphertext, including:

the controller receives the encrypted second private key sent by the actuator, and decrypts the second private key through the first private key of the controller to obtain the second private key;

and decrypting the software interface ciphertext by adopting the second private key.

Further, the method further comprises:

if the snapshot matching fails, the controller does not respond to the actuator within a preset time period, and simultaneously activates an error counter and adds 1;

when the counter reaches a preset upper threshold, the controller no longer responds to the actuator.

Further, the method further comprises:

and after the controller is connected with the actuator, data transmission is carried out in an encryption mode.

Further, the data transmission in an encrypted manner includes:

the signal receiving terminal firstly sends an encryption request to encrypt a plaintext and sends an encryption mode to the signal sending terminal;

the signal sending terminal sends a random number to the signal receiving terminal for security authentication after receiving the encryption request, and encrypts the demand message according to a request mode after the authentication is passed;

the signal receiving end decrypts the received encrypted information, sends a confirmation instruction to the signal sending end after confirming without errors, and sends an abnormal instruction when errors exist;

the signal sending end continuously sends the encrypted ciphertext after receiving the confirmation instruction; and when an abnormal instruction is received, adding 1 to the counter, and recovering the sending mode before the encryption.

Further, the method further comprises:

and when the authentication is not passed, the signal sending end ignores the encryption request.

Further, the method further comprises:

when the signal sending end receives the abnormal instruction, sending a retry instruction to the signal receiving end so that the signal receiving end sends the encryption request again;

and when the counter reaches a preset upper limit threshold value, the signal sending end does not respond to the encryption request any more.

According to a second aspect of embodiments of the present application, there is provided a centrally-controlled communication system, comprising: an actuator and a controller;

The technical scheme provided by the embodiment of the application has the following beneficial effects:

the communication method CAN realize the handshake authentication of the actuator of the CAN in the vehicle and the central domain control controller, realize the plug and play of the CAN nodes, and CAN ensure the communication safety in the vehicle.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

Fig. 1 is a flow chart illustrating a centrally-hosted communication method in accordance with an example embodiment.

FIG. 2 is an interaction flow diagram illustrating handshake authentication of an actuator and a controller in accordance with an example embodiment.

Fig. 3 is an interaction flow diagram illustrating an encrypted communication process in accordance with an example embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the present application. Rather, they are merely examples of methods and systems consistent with certain aspects of the application, as detailed in the appended claims.

FIG. 1 is a flow chart illustrating a centrally-hosted communications method in accordance with an exemplary embodiment. The method may comprise the steps of:

step S1: when the actuator is on line, sending a pre-agreed on-line request and self identity information to the controller;

step S2: the controller generates a first private key and a first public key and sends the first public key to the executor in a response mode;

and step S3: the executor encrypts the second private key and then sends the second private key to the controller, and simultaneously sends the software interface ciphertext and the interface snapshot to the controller;

and step S4: the controller decrypts the software interface ciphertext and calculates the snapshot of the decrypted interface by using the same snapshot algorithm;

step S5: the controller compares the calculated snapshot with the received interface snapshot;

step S6: if the snapshot is successfully matched, the controller is connected with the actuator, and data transmission is carried out through a software interface of the actuator; if the snapshot match fails, the connection fails.

It should be noted that, the premise of implementing the communication method of the present application is that: the CAN executor has unified application program software interface, asymmetrical algorithm with algorithm logic controlled in the central domain.

The following describes the scheme of the present application in an expanded manner by taking the GDC and the PDC as examples, in combination with a specific application scenario.

In some embodiments, the identity information of the actuator is a MAC address; accordingly, the controller generates a first private key and a first public key, including:

In some embodiments, the executor encrypts a second private key by using a first public key and sends the second private key to the controller;

In some embodiments, the controller decrypts the software interface cryptogram, including:

and decrypting the software interface ciphertext by adopting a second private key.

In some embodiments, the method further comprises:

As shown in fig. 2, the handshake authentication process in the present application includes the following steps:

1. when the PDC is online, the actuator sends an agreed online instruction, sends a request connection service in a diagnosis instruction mode, and sends the identity information (MAC address) of the PDC to a central domain control GDC;

2. after receiving the instruction, the GDC records the MAC address of the PDC, generates a pair of keys (a public key 1 and a private key 1) at the same time, and sends the public key to the PDC in a response mode;

after receiving the public key 1, the PDC encrypts a private key 2 sent by the PDC through the public key 1 (the private key 2 is encrypted by the public key 1) and sends the encrypted private key 2 to the GDC, and simultaneously feeds back a software interface ciphertext (the PDC is encrypted by the private key 2) and a snapshot of the interface to the GDC;

after receiving the ciphertext of the private key 2 sent by the PDC, the GDC decrypts the ciphertext through the private key 1 to obtain the private key 2;

5. after the private key 2 is obtained, decrypting the received software interface ciphertext, and calculating the snapshot of the decrypted interface by using the same snapshot algorithm;

6. comparing the decrypted snapshot with the snapshot sent by the received PDC;

7. if the snapshot matching is successful, a connection is established, and data transmission is performed through an interface of the PDC.

8. If the snapshot matching fails, the connection fails, the PDC is not responded within 10s, and meanwhile, an error counter is activated and is +1;

after 9.10s, performing a second connection attempt, and if the step 7 is successfully performed and the step fails, performing a counter of +1 again;

10. when the counter reaches 3, the PDC (MAC address is the unique id) is no longer responded to and its MAC address is blacklisted.

In some embodiments, the method further comprises:

In some embodiments, the data transmission in an encrypted manner includes:

a signal receiving terminal firstly sends an encryption request to encrypt a plaintext and sends an encryption mode to a signal sending terminal;

the signal sending end sends a random number to the signal receiving end for security authentication after receiving the encryption request, and encrypts the demand message according to a request mode after the authentication is passed;

the signal receiving end decrypts the received encrypted information, sends a confirmation instruction to the signal sending end after confirming no error, and sends an abnormal instruction when errors exist;

the signal sending end continuously sends the encrypted ciphertext after receiving the confirmation instruction; and when an abnormal instruction is received, adding 1 to the counter, and recovering the sending mode before encryption.

In some embodiments, the method further comprises:

As shown in fig. 3, the encrypted communication process of the present application includes the following steps:

1. the signal receiving end firstly sends out an instruction to request to encrypt the plaintext and sends the encryption mode to the signal sending end (the Motorola LSB, motorola MSB and Inter in the arrangement format of different signals in the encryption mode value message, see figure 1);

2. when the trigger instruction is a defined first Byte (0) of the periodic message is FF, the trigger condition is, for example, the interaction ID:310FF 37 41 62 7F E0 01 6A; byte (1) is 37, the lower 4 bits are 7, corresponding to the Inter format, the first important signal requirement is Inter, and so on, and can be defined by self;

the message format is shown in the following table:

3. after receiving the instruction, the signal sending end sends a random number to carry out security authentication, the authentication is not passed, the encryption request is ignored, the authentication is passed, and the demand message is encrypted according to a request mode;

4. the signal receiving end analyzes the received information in the arrangement format defined by the signal receiving end, and sends a confirmation instruction after confirming that no error exists, and sends an abnormal instruction by mistake;

5. the signal sending end continuously sends the encrypted ciphertext after receiving the confirmation instruction until the encryption request is obtained again;

6. when the signal sending end receives an abnormal instruction, the counter is +1, the sending mode before encryption is recovered, the instruction sending end is sent to request the sending end to send the encryption request again, and the step 5 is passed, but the step 6 is not passed;

7. and when the counter =3, the signal sending end does not respond to the plaintext encryption request any more, and reports the problem to the TSP platform end.

By adopting the scheme to carry out encrypted data transmission, the encryption of plaintext information can be carried out on the premise of not occupying a large amount of bandwidth, and the safe encryption of information in the vehicle is realized.

Embodiments of the present application also provide a central domain controlled communication system, including an actuator and a controller.

When the executor is on line, a pre-agreed on-line request and self identity information are sent to the controller.

The controller generates a first private key and a first public key and responsively transmits the first public key to the actuator.

And the actuator encrypts the second private key and sends the second private key to the controller, and simultaneously sends the software interface ciphertext and the interface snapshot to the controller.

The controller decrypts the software interface ciphertext and calculates the snapshot of the decrypted interface by using the same snapshot algorithm.

The controller compares the computed snapshot with the received interface snapshot. If the snapshot is successfully matched, the controller is connected with the actuator, and data transmission is carried out through a software interface of the actuator; if the snapshot match fails, the connection fails.

It is understood that the same or similar parts in the above embodiments may be mutually referred to, and the same or similar parts in other embodiments may be referred to for the content which is not described in detail in some embodiments.

It should be noted that, in the description of the present application, the terms "first", "second", etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. Further, in the description of the present application, the meaning of "a plurality" means at least two unless otherwise specified.

Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and the scope of the preferred embodiments of the present application includes other implementations in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present application.

It should be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.

It will be understood by those skilled in the art that all or part of the steps carried by the method for implementing the above embodiments may be implemented by hardware related to instructions of a program, which may be stored in a computer readable storage medium, and when the program is executed, the program includes one or a combination of the steps of the method embodiments.

In addition, functional units in the embodiments of the present application may be integrated into one processing module, or each unit may exist alone physically, or two or more units are integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. The integrated module, if implemented in the form of a software functional module and sold or used as a separate product, may also be stored in a computer-readable storage medium.

The storage medium mentioned above may be a read-only memory, a magnetic or optical disk, etc.

In the description of the present specification, reference to the description of "one embodiment," "some embodiments," "an example," "a specific example," or "some examples" or the like means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

While embodiments of the present application have been shown and described above, it will be understood that the above embodiments are exemplary and should not be construed as limiting the present application and that changes, modifications, substitutions and alterations in the above embodiments may be made by those of ordinary skill in the art within the scope of the present application.

Claims

1. A method of centrally-controlled communication, comprising:

when the executor is on line, sending a pre-agreed on-line request and an MAC address of the executor to the controller;

the controller records the MAC address of the actuator after receiving the online request, simultaneously generates a pair of secret keys comprising a first private key and a first public key, and sends the first public key to the actuator in a response mode;

if the snapshot is successfully matched, the controller is connected with the actuator, and data transmission is carried out through a software interface of the actuator so as to realize plug and play of the actuator; if the snapshot match fails, the connection fails.

2. The method of claim 1, wherein the executor encrypts a second private key with a first public key and sends the encrypted second private key to the controller;

3. The method of claim 2, wherein the controller decrypts the software interface cryptogram, comprising:

the controller receives the encrypted second private key sent by the actuator, and decrypts through the first private key of the controller to obtain the second private key;

4. The method according to any one of claims 1-3, further comprising:

5. The method according to any one of claims 1-3, further comprising:

6. The method of claim 5, wherein the cryptographically transferring data comprises:

7. The method of claim 6, further comprising:

8. The method of claim 6, further comprising:

9. A centrally-controlled communication system, comprising: an actuator and a controller;

when the actuator is on line, sending a pre-agreed on-line request and an MAC address of the actuator to the controller;

the actuator encrypts the second private key and sends the second private key to the controller, and simultaneously sends the software interface ciphertext and the interface snapshot to the controller;

if the snapshot is successfully matched, the controller is connected with the actuator, and data transmission is carried out through a software interface of the actuator so as to realize plug and play of the actuator;

if the snapshot match fails, the connection fails.