T-BOX and IVI security authentication method and system, electronic equipment and computer readable medium

Abstract

The invention provides a T-BOX and IVI security authentication method and system, and belongs to the field of intelligent driving, IVI confirms the identity of a T-BOX by verifying whether Key'is equal to Key, because data C1 is encrypted by using a public key PK1box of the T-BOX, only the legal T-BOX with a corresponding private key SK1 can correctly decrypt the Key, and any counterfeit device without a private key cannot pass the verification; the T-BOX confirms the identity of the IVI by verifying whether the IV'is equal to the IV, because the data C2 is encrypted by using the public key PK2ivi of the IVI, only the legal IVI with the corresponding private key SK2 can correctly decrypt the IV, illegal equipment is effectively prevented from accessing the system, and the credibility of both communication parties is ensured from the source.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving technology, and in particular to a T-BOX and IVI security authentication method, system, electronic device and computer-readable medium. Background Technology

[0002] TelematicsBOX, or T-BOX for short, is also known as a Telematics Control Unit (TCU). It is an intelligent terminal device that integrates a processor, GPS module, 4G / 5G module (including SIM card functionality), and supports multiple interfaces (such as CAN bus, USB, RS-232, Bluetooth, etc.). In vehicle-to-everything (V2X) systems, the T-BOX plays a crucial role, supporting communication and data exchange between vehicles and external networks, enabling seamless communication and data exchange between vehicles (V2V), vehicles and infrastructure (V2I), and vehicles and the Internet (V2N).

[0003] In-Vehicle Infotainment (IVI) is an intelligent in-vehicle platform that integrates navigation, communication, entertainment, and vehicle control functions. As a core component of the smart cockpit, it undertakes human-vehicle interaction and vehicle networking services. Developed based on an automotive-grade processor, the system connects to the vehicle bus via the CAN-BUS protocol, supports voice control, multi-screen interaction, and online services, covering scenarios such as driver assistance and remote diagnostics.

[0004] Currently, the USB communication between T-BOX and IVI uses security authentication based on the Xtea algorithm, which has a short key length and a fixed number of iterations, resulting in low security performance. Summary of the Invention

[0005] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes a T-BOX and IVI security authentication method and system.

[0006] In a first aspect, this application provides a T-BOX and IVI security authentication method, which includes the following steps:

[0007] VI generates a key Key and encrypts Key to obtain data C1;

[0008] T-BOX acquires data C1 and decrypts data C1 to obtain Key'. T-BOX generates an initialization vector IV, concatenates IV and Key', and encrypts the concatenated data to obtain data C2.

[0009] IVI retrieves data C2 and decrypts data C2 to obtain IV and Key';

[0010] IVI verifies whether Key' matches Key; and when they match, IVI encrypts IV to obtain data C3;

[0011] T-BOX acquires data C3 and decrypts data C3 to obtain IV';

[0012] T-BOX verifies whether IV' is consistent with IV.

[0013] In some embodiments, when the T-BOX verifies that IV' matches IV, IVI sends a handshake message to the T-BOX within a preset time.

[0014] In some embodiments, after the T-BOX verifies that IV' matches IV, IVI encrypts the business data to obtain data C4.

[0015] The T-BOX acquires data C4 and decrypts it to obtain the corresponding business data.

[0016] In some embodiments, the IVI encrypts the business data to obtain data C4, including:

[0017] The data C4 is encapsulated into an HDLC frame, and the encapsulated data C4 is sent to the T-BOX.

[0018] In some embodiments, both the IVI and the T-BOX generate their own public-private key pairs. The IVI sends the generated public key to the T-BOX, and the T-BOX sends the generated public key to the IVI.

[0019] In some embodiments, the step of encrypting the Key to obtain data C1 includes: the IVI encrypting the Key using the public key sent by the T-BOX, and sending the encrypted data C1 to the T-BOX.

[0020] In some embodiments, if the IVI verifies that the Key' does not match the Key, the T-BOX is deemed invalid, the IVI disconnects the Socket connection with the T-BOX, and re-initiates the connection.

[0021] Secondly, this application provides a T-BOX and IVI security authentication method, including a T-BOX and an IVI, wherein the T-BOX and IVI perform the security authentication method.

[0022] Thirdly, this application also provides an electronic device, including:

[0023] One or more processors;

[0024] Memory, used to store one or more programs;

[0025] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods.

[0026] Fourthly, this application also provides a computer-readable medium storing a computer program that, when executed by a processor, implements the steps of any of the methods described.

[0027] The T-BOX and IVI security authentication method provided by this invention verifies the identity of the T-BOX by checking if Key' equals Key. Since C1 is encrypted using the T-BOX's public key PK1_box, only a legitimate T-BOX with the corresponding private key SK1 can correctly decrypt Key. Any counterfeit device without the private key cannot pass this verification. The T-BOX verifies the identity of the IVI by checking if IV' equals IV. Since C2 is encrypted using the IVI's public key PK2_ivi, only a legitimate IVI with the corresponding private key SK2 can correctly decrypt IV, effectively preventing unauthorized devices from accessing the system and ensuring the trustworthiness of both communicating parties from the source. Attached Figure Description

[0028] Figure 1 This is a logical schematic diagram of an embodiment of the T-BOX and IVI security authentication method of the present invention;

[0029] Figure 2 This is a flowchart illustrating the steps of an embodiment of the T-BOX and IVI security authentication method of the present invention;

[0030] Figure 3 This is a block diagram of the T-BOX and IVI security authentication system of the present invention;

[0031] Figure 4 This is a schematic diagram of the structure of an embodiment of the electronic device of the present invention. Detailed Implementation

[0032] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0033] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0034] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0035] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0036] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0037] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0038] In related technologies, the USB communication between T-BOX and IVI uses security authentication based on the Xtea algorithm, which has a short key length and a fixed number of iterations, resulting in low security performance.

[0039] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a T-BOX and IVI security authentication method.

[0040] like Figure 1 and Figure 2 As shown, the T-BOX and IVI security authentication method includes the following steps:

[0041] Step 0: IVI generates the symmetric key Key.

[0042] Specifically, IVI randomly generates a 128-bit AES key for subsequent symmetric encryption.

[0043] Understandably, the generated key will be used for subsequent encryption and authentication. Only the IVI knows the key, but it needs to be securely transmitted to the T-BOX.

[0044] Step 1: IVI uses the public key generated by T-BOX to encrypt the Key to obtain data C1.

[0045] Specifically, the IVI uses the T-BOX's public key PK1box to encrypt the Key using RSA2048, obtaining encrypted data C1. The IVI then sends data C1 directly to the T-BOX in hexadecimal format (without encapsulating it into an HDLC frame). HDLC (High-level Data Link Control) is a set of protocols used for transmitting data between network nodes.

[0046] It is understandable that, depending on the key generated in Step 0, only T-BOX holding the private key SK1 can decrypt data C1, ensuring the secure transmission of the key. The message format is hexadecimal data, and the key length is 16 bytes.

[0047] Step 2: Decrypt data C1 using T-BOX to obtain Key'.

[0048] Specifically, after receiving data C1, T-BOX uses its private key SK1 to perform RSA2048 decryption to obtain Key' (128 bits).

[0049] It is understandable that if the data C1 sent in Step 1 is successfully decrypted, the Key' should be consistent with the Key generated by IVI, but T-BOX has not yet verified this at this time.

[0050] Step 3: T-BOX generates initialization vector IV.

[0051] Specifically, T-BOX randomly generates a 128-bit initialization vector (IV) for AES-CBC mode.

[0052] Step 4: T-BOX uses the public key generated by IVI to encrypt IV and Key' to obtain data C2.

[0053] Specifically, T-BOX seamlessly concatenates IV and Key' (32 bytes in total), then uses IVI's public key PK2ivi for RSA2048 encryption to obtain encrypted data C2; T-BOX sends data C2 directly to IVI in hexadecimal format (without encapsulating HDLC frames).

[0054] This is understandable, as it relies on the Key' from Step 2 and the IV from Step 3. Only the IVI holding the private key SK2 can decrypt data C2, ensuring the secure transmission of the IV and Key'.

[0055] Step 5: Decrypt data C2 using IVI to obtain IV and Key'.

[0056] Specifically, after receiving data C2, the IVI uses its private key SK2 to perform RSA2048 decryption to obtain the IV and Key'.

[0057] It is understandable that, depending on the data C2 sent in Step 4, after decryption, the IVI obtains the IV generated by the T-BOX and the returned Key'.

[0058] Step 6: IVI verification to see if Key' is equal to Key.

[0059] Specifically, IVI compares Key' (obtained from decrypting data C2) with the initially generated Key (Step 0).

[0060] If they match, the T-BOX is considered valid (because only the T-BOX can correctly decrypt data C1 to obtain the Key).

[0061] If there is a discrepancy, the T-BOX is deemed invalid, and the IVI terminates the Socket connection and re-initiates the connection.

[0062] It is understandable that the Key from Step 0 and the Key from Step 5 are required to complete the IVI authentication of the T-BOX.

[0063] As can be understood, this embodiment uses IVI authentication for the T-BOX. The IVI verifies the identity of the T-BOX by verifying that Key' == Key. Because data C1 is encrypted using the T-BOX's public key PK1_box, only a legitimate T-BOX with the corresponding private key SK1 can correctly decrypt the Key.

[0064] Step 7: When the IVI verifies that Key' matches Key, the IVI uses the T-BOX public key to encrypt the IV to obtain data C3.

[0065] It is understandable that: IVI uses T-BOX's public key PK1box to encrypt IV (obtained from Step 5) using RSA2048, obtaining encrypted data C3; IVI sends data C3 directly to T-BOX in hexadecimal format (without encapsulating HDLC frames).

[0066] This is understandable, as it relies on the IV obtained in Step 5. This step sends the IV back to the T-BOX for verification.

[0067] Step 8: T-BOX decrypts data C3 to obtain IV'.

[0068] Specifically, after receiving data C3, T-BOX uses its private key SK1 to perform RSA2048 decryption to obtain IV'.

[0069] It is understandable that, based on the data C3 sent in Step 7, after decryption, T-BOX obtains the IV' returned by IVI.

[0070] Step 9: T-BOX verifies whether IV' is equal to IV.

[0071] Specifically, T-BOX compares IV' (obtained from data C3 decryption) with the initially generated IV (Step 3).

[0072] If they match, the IVI is considered valid (because only the IVI can correctly decrypt data C2 to obtain the IV).

[0073] If there is a discrepancy, the IVI is deemed invalid, and the T-BOX terminates the Socket connection and re-accepts the IVI connection.

[0074] It is understandable that Step 3 IV and Step 8 IV' are required to complete T-BOX's IVI certification.

[0075] As can be understood, this embodiment authenticates the IVI via T-BOX. The T-BOX verifies the IVI's identity by checking whether IV' equals IV. Because data C2 is encrypted using the IVI's public key PK2_ivi, only a legitimate IVI with the corresponding private key SK2 can correctly decrypt the IV.

[0076] Based on the above steps, the IVI verifies the legitimacy of the T-BOX, and the T-BOX verifies the legitimacy of the IVI, thus completing the security authentication between the T-BOX and the IVI.

[0077] In the preferred solution, Step 10 is added: IVI sends a handshake message.

[0078] Specifically, after successful two-way authentication and within a preset time, the IVI sends a handshake message (data) to the T-BOX. The handshake message is encapsulated using HDLC. The specific time is: after the IVI sends IV' to the T-BOX, it waits for 2 seconds.

[0079] It is understandable that this step is performed after authentication is completed, and both the IVI and T-BOX are legitimate, based on which business communication between the IVI and T-BOX begins.

[0080] Step 11: IVI uses AES to encrypt the business data to obtain data C4.

[0081] Specifically, the IVI uses the negotiated Key (Step 0) and IV (Step 5) to encrypt the service data using AES128-CBC, resulting in encrypted data C4. Then, data C4 is encapsulated into an HDLC frame and sent to the T-BOX; all subsequent service data must be encapsulated using HDLC.

[0082] It is understandable that encrypted communication begins with the Key from Step 0 and the IV from Step 5.

[0083] Step 12: T-BOX uses AES to decrypt data C4 to obtain the corresponding business data.

[0084] Specifically, after receiving C4, T-BOX uses the negotiated Key' (Step 2) and IV (Step 3) to perform AES128-CBC decryption to obtain the corresponding business data, and then parses the data according to the business protocol and distributes it for processing.

[0085] This is understandable, as it relies on the Key from Step 2 and the IV from Step 3. This step completes the decryption and processing of business data.

[0086] It should be noted that this scheme securely negotiates the session key (Key) and initialization vector (IV) used for subsequent symmetric encryption. Key and IV remain encrypted throughout transmission. Key is securely transmitted to the T-BOX via data C1 (RSA+PK1_box). IV and Key' (used for confirmation) are securely transmitted to the IVI via data C2 (RSA+PK2_ivi). Although this scheme does not use temporary asymmetric key pairs generated for each session to achieve perfect forward security, the fact that Key and IV are short-term keys randomly generated for each communication represents a significant security improvement compared to using fixed symmetric key schemes. This greatly enhances the security level of the smart cockpit, prevents unauthorized access and communication, and reduces security risks.

[0087] Furthermore, this scheme cleverly combines the advantages of asymmetric and symmetric encryption. It uses asymmetric encryption (RSA). Although computationally expensive, the number of key exchanges and authentications is low (only 3), making it perfectly acceptable, and it offers extremely high security. It also uses symmetric encryption (AES). AES encryption and decryption are extremely fast with minimal overhead, making it ideal for real-time encrypted transmission of large amounts of business data. The necessary computational resources are consumed to ensure maximum security when establishing a secure channel, while efficient algorithms are used during actual data transmission, ensuring the entire system is both secure and smooth.

[0088] Furthermore, since all subsequent business data uses high-strength AES encryption, even if an attacker intercepts data C4, they cannot decrypt the original information. Even if an attacker records the entire authentication process (C1, C2, C3) and resends it, verification will fail. This is because the IVI generates a new random key each time, and the T-BOX generates a new random IV each time. Resentting data C1 will not allow the T-BOX to obtain the correct key for this session, and resentting data C2 / C3 will also fail key / IV verification. Due to the use of two-way authentication, an attacker cannot impersonate either party. Even if an attacker intercepts data C1, they cannot decrypt it using SK1, nor can they forge data C2 that can pass IVI verification (because there is no SK2 to encrypt the correct key).

[0089] It should be noted that all business data follows the pattern of Steps 11 and 12: the IVI uses AES to encrypt the data and encapsulates it with HDLC, and the T-BOX decrypts and processes it. Only Steps 1, 4, and 7 directly send RSA encrypted data (without HDLC encapsulation); all other business communications require HDLC encapsulation.

[0090] It is understood that the T-BOX and IVI security authentication method provided in this embodiment achieves two-way identity authentication and key negotiation through asymmetric encryption, establishing a secure channel for symmetric encrypted communication. It effectively prevents identity forgery, data eavesdropping, and replay attacks, while achieving an optimal balance between security and communication efficiency. It is a practical security authentication solution that meets current vehicle network security requirements.

[0091] Furthermore, the public keys generated by the IVI and T-BOX public-private key pairs provided in the above method of this embodiment need to be exchanged, specifically including:

[0092] Key pair generation: IVI and T-BOX each generate a set of RSA2048 public and private key pairs in the development environment. Specifically, IVI generates SK2 (private key) and PK2_ivi (public key), and T-BOX generates SK1 (private key) and PK1_box (public key).

[0093] During the software development phase, public keys are exchanged through a secure channel: IVI pre-installs its public key PK2_ivi into T-BOX, and T-BOX pre-installs its public key PK1_box into IVI.

[0094] It is understandable that this exchange process should be completed in a controlled development environment to ensure the authenticity and integrity of the public key.

[0095] Furthermore, whether IVI encrypts and stores the vehicle's private key and the T-BOX's public key is up to IVI to decide.

[0096] Furthermore, the AES encryption key (Key) is generated: the Key is 128 bits, or 16 bytes.

[0097] Specifically, the key required for generating the AES-CBC-128 algorithm on the vehicle's infotainment system is shown in the following Java code:

[0098]

[0099] Furthermore, in the generation of the initialization vector (IV), the IV is generated on the T-BOX side and is also 128 bits, or 16 bytes.

[0100] Furthermore, in the seamless concatenation of IV and KEY', IV||KEY', meaning the first 16 bytes are the IV value and the last 16 bytes are the KEY' value. This totals 32 bytes.

[0101] Furthermore, the vehicle-mounted system uses the T-BOX public key PK1 to encrypt the generated key using RSA2048, and then sends the encrypted data C1 to the T-BOX. The RSA algorithm padding method is "RSA / ECB / PKCS1Padding". The reference code (Java) is as follows:

[0102]

[0103] Furthermore, the padding method for AES is "AES / CBC / PKCS5Padding". The sample Java code is as follows:

[0104]

[0105]

[0106] Based on the same inventive concept, see [link to inventive concept] Figure 3 The present invention also provides a T-BOX and IVI security authentication system, including a T-BOX and an IVI, wherein the T-BOX and IVI perform the security authentication method described above.

[0107] Specifically, before performing security authentication, both T-BOX and IVI generate public-private key pairs, with T-BOX sending its public key to IVI and IVI sending its public key to T-BOX. During security authentication, both T-BOX and IVI perform the corresponding encryption, decryption, and verification actions according to the above process steps, specifically Steps 0-10. Only after both parties' legitimacy is effectively verified will IVI send AES-encrypted and HDLC-encapsulated business data to T-BOX. After receiving the encrypted and encapsulated business data from IVI, T-BOX uses the negotiated Key and IV to AES-decrypt it, parses the data portion according to the business protocol, and distributes it to the corresponding business layer for processing, specifically Steps 11-12.

[0108] It should be noted that the secure authentication system provided by this invention securely negotiates the session key (Key) and initialization vector (IV) used for subsequent symmetric encryption, and both Key and IV remain encrypted throughout transmission. Key is securely transmitted to the T-BOX via data C1 (RSA+PK1_box). IV and Key' (used for confirmation) are securely transmitted to IVI via data C2 (RSA+PK2_ivi). Although this scheme itself does not use temporary asymmetric key pairs generated for each session to achieve perfect forward security, because Key and IV are short-term keys randomly generated for each session, even if the key for a particular session is cracked, it cannot be used to decrypt past or future communication sessions (unless the RSA private key itself is leaked). This represents a significant security improvement compared to using a fixed symmetric key scheme.

[0109] Furthermore, this scheme cleverly combines the advantages of asymmetric and symmetric encryption. While asymmetric encryption (RSA) is computationally intensive, it's only used for key exchange and authentication, requiring only a few iterations (only 3), making it perfectly acceptable and offering extremely high security. Symmetric encryption (AES) is extremely fast with minimal overhead, making it ideal for real-time encrypted transmission of large amounts of business data. The necessary computational resources are consumed to ensure maximum security when establishing a secure channel, while efficient algorithms are used during actual data transmission, ensuring the entire system is both secure and smooth.

[0110] Furthermore, since all subsequent business data uses high-strength AES encryption, even if an attacker intercepts data C4, they cannot decrypt the original information. Even if an attacker records the entire authentication process (C1, C2, C3) and resends it, verification will fail. This is because the IVI generates a new random key each time, and the T-BOX generates a new random IV each time. Resentting data C1 will not allow the T-BOX to obtain the correct key for this session, and resentting data C2 / C3 will also fail key / IV verification. Due to the use of two-way authentication, an attacker cannot impersonate either party. Even if an attacker intercepts data C1, they cannot decrypt it using SK1, nor can they forge data C2 that can pass IVI verification (because there is no SK2 to encrypt the correct key).

[0111] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 4 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the T-BOX and IVI security authentication methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0112] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0113] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0114] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0115] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the T-BOX and IVI security authentication methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0116] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described T-BOX and IVI security authentication method.

[0117] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0118] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0119] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0120] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0121] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0122] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0123] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0124] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0125] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0126] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A T-BOX and IVI security authentication method, characterized in that, It includes the following steps: IVI generates a key Key and encrypts Key to obtain data C1; T-BOX acquires data C1 and decrypts data C1 to obtain Key'. T-BOX generates an initialization vector IV, concatenates IV and Key', and encrypts the concatenated data to obtain data C2. IVI retrieves data C2 and decrypts data C2 to obtain IV and Key'; IVI verifies whether Key' matches Key; and when they match, IVI encrypts IV to obtain data C3; T-BOX acquires data C3 and decrypts data C3 to obtain IV'; T-BOX verifies whether IV' is consistent with IV.

2. The T-BOX and IVI security authentication method according to claim 1, characterized in that, When T-BOX verifies that IV' matches IV, IVI sends a handshake message to T-BOX within a preset time.

3. The T-BOX and IVI security authentication method according to claim 1, characterized in that, Once T-BOX verifies that IV' matches IV, IVI encrypts the business data to obtain data C4; The T-BOX acquires data C4 and decrypts it to obtain the corresponding business data.

4. The T-BOX and IVI security authentication method according to claim 3, characterized in that, The IVI encrypts the business data to obtain data C4, which includes: The data C4 is encapsulated into an HDLC frame, and the encapsulated data C4 is sent to the T-BOX.

5. The T-BOX and IVI security authentication method according to claim 1, characterized in that, Both IVI and T-BOX generate their own public-private key pairs. IVI sends the generated public key to T-BOX, and T-BOX sends the generated public key to IVI.

6. The T-BOX and IVI security authentication method according to claim 5, characterized in that, The process of encrypting the Key to obtain data C1 includes: IVI encrypting the Key using the public key sent by T-BOX, and sending the encrypted data C1 to T-BOX.

7. The T-BOX and IVI security authentication method according to claim 1, characterized in that, If the IVI verifies that the Key' does not match the Key, it considers the T-BOX invalid, disconnects the Socket connection with the T-BOX, and re-initiates the connection.

8. A T-BOX and IVI security authentication method, characterized in that, It includes a T-BOX and an IVI, wherein the T-BOX and IVI perform the security authentication method according to any one of claims 1 to 7.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images