Lane line data secure transmission architecture

Abstract

The invention relates to the technical field of safe intelligent traffic, and discloses a lane line data safe transmission architecture, which comprises a multi-layer data safety protection system constructed between a terminal and a server, and comprises a data encryption layer for encrypting lane line data collected by the terminal through a preset key and transmitting the encrypted lane line data to the server; according to the data integrity verification layer, after the encrypted lane line data is transmitted to a server, verification elements of the encrypted lane line data are recorded based on the block chain data layer, and the data are automatically verified through a pre-compiled smart contract; and the data security communication layer is used for establishing encryption service and identity authentication from a terminal to a server through a TLS protocol in combination with a public key infrastructure of the block chain. According to the invention, a data security protection system including data encryption, data integrity and secure communication is constructed, so that the security and integrity of the lane line data are ensured, and the problems of data tampering and privacy disclosure in the lane line acquisition and transmission process are effectively prevented.

Description

Technical Field

[0001] The present invention relates to the technical field of secure intelligent transportation, and particularly relates to a lane line data secure transmission architecture. Background Art

[0002] With the development of autonomous driving, lane line data, as a key traffic information resource, not only affects the driving safety of vehicles, but is also the basis for various advanced driver assistance systems and autonomous driving functions. Functions such as lane departure warning, lane keeping assistance, and automatic lane change all rely on real-time and accurate lane line information. The sources of lane line data are diverse, covering in-vehicle sensors, roadside infrastructure sensors, and cloud data platforms. These data need to be transmitted between different nodes such as vehicles and the cloud, roadside units and vehicles, and vehicles and vehicles. However, during the data collection and transmission process, many security challenges are faced, including problems such as data tampering and privacy leakage. Summary of the Invention

[0003] Aiming at the problems of the security of lane line data in collection and transmission in the prior art, the present invention provides a lane line data secure transmission architecture. By constructing a data security protection system including a data encryption layer, a data integrity layer, and a secure communication layer, it can ensure the security and integrity of lane line data throughout its life cycle, and effectively prevent problems such as data tampering and privacy leakage during the collection and transmission of lane line data. The specific technical solutions are as follows:

[0004] A lane line data secure transmission architecture includes constructing a multi-layer data security protection system between a terminal and a server, including:

[0005] Data Encryption Layer: Encrypt the lane line data collected by the terminal with a preset key, and transmit the encrypted lane line data to the server;

[0006] Data Integrity Verification Layer: When the encrypted lane line data is transmitted to the server, record the verification elements of the transmission of the encrypted lane line data based on the blockchain data layer, and automatically verify the data through a pre-compiled smart contract;

[0007] Data Secure Communication Layer: Establish an encrypted service and identity authentication from the terminal to the server through the TLS protocol combined with the public key infrastructure of the blockchain.

[0008] Preferably, the encrypting the lane line data collected by the terminal with a preset key and transmitting the encrypted lane line data to the server includes:

[0009] Randomly generate a shared key between the terminal and the server;

[0010] Generate a key pair including a public key and a private key according to the shared key;

[0011] Use the public key to encrypt the symmetric key to generate the encrypted symmetric key;

[0012] Store the encrypted symmetric key in the terminal, and use the symmetric key to encrypt the lane line data collected by the terminal device;

[0013] Transmit the encrypted lane line data to the server.

[0014] Preferably, the encrypting the lane line data collected by the terminal device using the symmetric key includes:

[0015] Perform data padding on the lane line data collected by the terminal device to obtain lane line data that meets the encryption requirements;

[0016] Use the symmetric key to encrypt the lane line data that meets the encryption requirements.

[0017] Preferably, after the encrypted lane line data is transmitted to the server, based on the blockchain data layer, record the verification elements of the transmission of the encrypted lane line data, and automatically verify the data through the pre-compiled smart contract, including:

[0018] After the encrypted lane line data is transmitted to the server, record the verification elements of each transmission of the encrypted lane line data based on the blockchain data layer;

[0019] Verify whether the verification elements of the latest received lane line data match the recorded verification elements;

[0020] If the result matches, it means that the transmitted data is complete. If the result does not match, trigger the exception handling process.

[0021] Preferably, the verification elements include at least one of a hash value, a timestamp, a device ID, a serial number, and a geographical location.

[0022] Preferably, when the verification element is a hash value, after the encrypted lane line data is transmitted to the server, based on the blockchain data layer, record the verification elements of the transmission of the encrypted lane line data, and automatically verify the data through the pre-compiled smart contract, including:

[0023] After the encrypted lane line data is transmitted to the server, enable off-chain transaction technology, record each encrypted lane line data based on the distributed file system of the blockchain data layer, calculate the hash value of each time, and synchronize the off-chain calculation results to the main chain;

[0024] Use the hash value of the latest received encrypted lane line data as the condition to trigger the pre-compiled smart contract, and verify whether the latest calculated hash value matches the hash value result previously recorded on the blockchain data layer according to the pre-compiled smart contract deployed on the blockchain contract layer;

[0025] If the result matches, the pre-compiled smart contract returns an acknowledgement signal indicating that the transmitted data is complete. If the result does not match, the pre-compiled smart contract triggers an exception handling process.

[0026] Preferably, establishing the encryption service and identity authentication from the terminal to the server through the TLS protocol combined with the public key infrastructure of the blockchain includes:

[0027] The terminal sends a first request message to the server. The first request message includes the TLS version, cipher suite, and extension field information supported by the terminal. The extension field includes the parameters related to the supported blockchain PKI.

[0028] The server receives the first request message and sends a first response message. The first response message includes the cipher suite and session ID selected by the server, and a digital certificate. The issuance and management of the digital certificate are completed in cooperation with IPFS and the blockchain PKI. The digital certificate contains the server public key.

[0029] The terminal verifies the digital certificate. After successful verification, it generates a pre-master secret key, encrypts it with the server public key, and sends it to the server. The generation process of the pre-master secret key is synchronized to the blockchain.

[0030] The server decrypts the pre-master secret key using its private key.

[0031] The terminal and the server generate a session key based on the pre-master secret key, and the generation process is synchronized to the blockchain.

[0032] The terminal and the server send a ChangeCipherSpec message to enable session key encryption.

[0033] The terminal sends a Finished message encrypted with the session key to verify the integrity of the handshake and establish a data security communication layer between the terminal and the server.

[0034] Preferably, the terminal verifying the digital certificate includes checking the certificate validity period, verifying the integrity and credibility of the certificate, and querying the certificate revocation status.

[0035] Compared with the prior art, the beneficial effects of the present invention are:

[0036] A lane line data security transmission architecture of the present invention constructs a data security protection system including a triple protection framework of a data encryption layer, a data integrity and anti-tampering layer, and a secure communication layer. In the first layer, the data encryption layer encrypts the original data generated by Internet of Things devices, locking the integrity and privacy of the data at the source. In the second layer, the data integrity and anti-tampering layer uses blockchain technology to record the verification elements of lane line data, and automatically verifies the consistency and authenticity of the data through pre-compiled contracts, preventing data from being tampered with from the cloud. In the third layer, the secure communication layer provides encryption and identity authentication from the terminal to the cloud through the TLS protocol combined with the public key infrastructure PKI of the blockchain. It can guarantee the security and integrity of lane line data throughout its life cycle, and effectively prevent the problems of data tampering and privacy leakage during the collection and transmission of lane lines. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to actual scale.

[0038] Figure 1 It is a schematic diagram of a lane line data security transmission architecture of the present invention.

[0039] Figure 2 It is a flowchart for the generation and management of the terminal encryption key of the present invention.

[0040] Figure 3 It is a data encryption flowchart of the present invention.

[0041] Figure 4 It is an encrypted data verification flowchart of the present invention.

[0042] Figure 5 It is a data security communication flowchart of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0043] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0044] It should be understood that when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, wholes, steps, operations, elements and / or components, but do not preclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or their combinations.

[0045] It should also be understood that the terms used in the specification of the present invention are for the purpose of describing particular embodiments only and are not intended to limit the present invention. As used in the specification of the present invention and the appended claims, unless the context clearly dictates otherwise, the singular forms "a", "an" and "the" are intended to include the plural forms.

[0046] It should be further understood that the term "and / or" used in the specification of the present invention and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0047] For the following embodiments, please refer to Figures 1 to 5 .

[0048] Please refer to Figure 1 , the embodiment of the present application provides a lane line data secure transmission architecture, including building a multi-layer data security protection system between the terminal and the server, including:

[0049] Data encryption layer: Encrypt the lane line data collected by the terminal with a preset key and transmit the encrypted lane line data to the server;

[0050] Data integrity verification layer: When the encrypted lane line data is transmitted to the server, based on the blockchain data layer, record the verification elements of the encrypted lane line data transmission, and automatically verify the data through a pre-compiled smart contract;

[0051] Data secure communication layer: Establish an encrypted service and identity authentication from the terminal to the server through the TLS protocol combined with the public key infrastructure of the blockchain.

[0052] In the data encryption layer of this embodiment, when the terminal collects data, it immediately encrypts the data with a preset key and then sends it to the server (cloud), locking the confidentiality of the data at the source. In this embodiment, the preset key uses the Advanced Encryption Standard AES-256 to encrypt the original data generated by the terminal. The terminal is an Internet of Things device, including but not limited to cameras, lidar, mobile laser scanning, and drones, etc., which are used to collect the detailed layout of the markings. The data encryption layer is the foundation of the entire security architecture, that is, encrypting the data to be transmitted from the source. The AES-256 encryption algorithm is used to ensure the data transmission between the Internet of Things device and the server. AES-256 is a symmetric encryption algorithm with a key length of 256 bits, and its encryption and decryption speeds are fast, suitable for real-time data transmission. Choosing AES-256 as the encryption algorithm is because of its high security, high encryption efficiency, and good compatibility.

[0053] The data integrity verification layer provides further defense for the cloud data (the data received by the server). First, the data layer in the blockchain technology is used to record the verification elements of each lane line data transmission. Specific smart contracts are deployed in the contract layer of the blockchain to verify the authenticity and consistency of the data. When the lane line data is uploaded to the server, the smart contract will automatically execute with the upload of the verification elements of the newly received lane line data as the trigger condition, and check whether the hash value of the newly uploaded lane line data matches the verification elements previously stored in the blockchain data layer. If the two are consistent, it proves that the data has not been tampered with; otherwise, it indicates that the data has been modified, and corresponding measures should be taken to handle the abnormal situation at this time.

[0054] The data security communication layer establishes a secure transmission channel from the terminal to the server (the data in the cloud) through the TLS / SSL protocol, which can effectively resist the risks of the public network environment. The TLS / SSL protocol in this embodiment is established by using the Transport Layer Security TLS or its predecessor, the Secure Sockets Layer SSL protocol, combined with the Public Key Infrastructure (PKI) of the blockchain. The TLS / SSL protocol not only provides end-to-end encryption services but also supports the identity authentication function, ensuring that the identities of both communication parties are true and reliable, thus effectively preventing network security threats such as man-in-the-middle attacks.

[0055] A lane line data security transmission architecture of the present invention constructs a data security protection system including a triple protection framework of a data encryption layer, a data integrity and a secure communication layer. The first layer is the data encryption layer, which encrypts the original data generated by the Internet of Things devices, locking the integrity and privacy of the data from the source end. In the second layer, the data integrity and anti-tampering layer, the verification elements of the lane line data are recorded using blockchain technology, and the consistency and authenticity of the data are automatically verified through pre-compiled contracts, preventing data from being tampered with from the cloud. In the third layer, the secure communication layer, through the TLS protocol combined with the public key infrastructure PKI of the blockchain, provides encryption and identity authentication from the terminal to the cloud. It can guarantee the security and integrity of the lane line data throughout its life cycle, and effectively prevent the problems of data tampering and privacy leakage during the acquisition and transmission of the lane line data.

[0056] Specifically, please refer to Figure 2 The encryption of the lane line data collected by the terminal with a preset key and the transmission of the encrypted lane line data to the server include:

[0057] Step 1: Generate a shared key randomly between the terminal and the server;

[0058] Generate a 256-bit shared key between the terminal and the server using a random number generator. Specifically, the "secrets" library in Python can be used to generate the key. For example, the generated key key is: \xc1\xa68\x86\xebz\x00\x85z5\x03\xc9\r\x8agvs\xe9\xb4WQ\xdb+Xx\x85\xef\xfc\x1c-\x7f\. This key is represented in the form of a byte string. Each byte is represented by two hexadecimal digits. For example, \xc1 represents a byte with a decimal value of 193. The entire string consists of 32 such bytes, so there are a total of 64 hexadecimal digits.

[0059] Step 2: Generate a key pair including a public key and a private key according to the shared key;

[0060] Step 3: Encrypt the symmetric key with the public key to generate the encrypted symmetric key;

[0061] The secure distribution of keys is an important part of data encryption. In this embodiment, the asymmetric encryption algorithm RSA is used to distribute the symmetric key. For example, the "cryptography" library in Python is used to distribute the key. First, a symmetric key with a length of 32 bytes is generated, and then an RSA key pair with 2048 bits is created. Then, the public key is serialized into the PEM format, which is used for the format of exchanging the public key. Finally, the previously generated symmetric key is encrypted with the OAEP padding mode and the SHA-256 hash algorithm using the public key. The distributed key is stored in the IoT device and the server cloud using a secure chip to ensure that the key is not leaked.

[0062] Step 4: Store the encrypted symmetric key in the terminal, and use the symmetric key to encrypt the lane line data collected by the terminal device;

[0063] Specifically, the use of the symmetric key to encrypt the lane line data collected by the terminal device includes:

[0064] Perform data padding on the lane line data collected by the terminal device to obtain lane line data that meets the encryption requirements;

[0065] Use the symmetric key to encrypt the lane line data that meets the encryption requirements.

[0066] In this embodiment, preprocessing is done before data encryption, mainly to ensure that the format of the original data meets the encryption requirements. Data encryption is performed using the symmetric key generated by the "cryptography" library introduced above. First, a random AES key with a length of 32 bytes is generated; then, a 16-byte initialization vector (IV) is generated. The IV is necessary for encryption in the CBC mode, which ensures that even the same plaintext will produce different ciphertexts. Next, an AES-256 encryptor instance is created, which specifies the use of the AES-256 algorithm, the key, the CBC mode, and the IV.

[0067] Since AES requires the input data length to be an integer multiple of 16 bytes for block ciphers, for encrypting the padded data using the update method of the encryptor, the case where the data length is not a multiple of 16 bytes can be handled using a padding function and combined with the finalize method to complete the encryption process.

[0068] Step 5: Transmit the encrypted lane line data to the server.

[0069] In this embodiment, by encrypting the data collected by the IoT device terminal, it can be ensured that the original data generated by the IoT device is fully protected during the transmission process, preventing the data from being intercepted or tampered with by a third party.

[0070] Specifically, after the encrypted lane line data is transmitted to the server, the verification elements of the transmission of the encrypted lane line data are recorded based on the blockchain data layer, and the automatic verification of the data through the pre-compiled smart contract includes:

[0071] After the encrypted lane line data is transmitted to the server, the verification elements of each transmission of the encrypted lane line data are recorded based on the blockchain data layer; the verification elements include at least one of a hash value, a timestamp, a device ID, a serial number, and a geographical location.

[0072] Verify whether the verification elements of the latest received lane line data match the recorded verification elements;

[0073] If the result matches, it means the transmitted data is complete. If the result does not match, an exception handling process is triggered.

[0074] Specifically, please refer to Figure 3 When the verification element is a hash value, after the encrypted lane line data is transmitted to the server, the verification elements of the transmission of the encrypted lane line data are recorded based on the blockchain data layer, and the automatic verification of the data through the pre-compiled smart contract includes:

[0075] After the encrypted lane line data is transmitted to the server, off-chain transaction technology is enabled, and each time the encrypted lane line data is recorded based on the distributed file system of the blockchain data layer, and the hash value of each time is calculated, and the calculation result off-chain is synchronized to the main chain;

[0076] In this embodiment, the location and calculation method of calculating the hash value are optimized. The new lane line data is stored using the distributed file system, and the oracle service provided by Chainlink is used for off-chain calculation to perform complex calculation tasks in an environment outside the main chain, and then the hash value result is returned to verify the hash value stored in the data layer of the main chain. This can not only save the storage space of the main chain, but also improve the data synchronization response rate of each node of the blockchain.

[0077] Using the hash value of the latest received encrypted lane line data as the condition to trigger the pre-compiled smart contract, and verifying whether the latest calculated hash value matches the hash value result previously recorded on the blockchain data layer according to the pre-compiled smart contract deployed on the blockchain contract layer;

[0078] In this embodiment, the smart contract uses a pre-compiled contract. Using a pre-compiled contract to perform a specific operation such as hash calculation is often more efficient than an ordinary smart contract.

[0079] If the result matches, the pre-compiled smart contract returns an acknowledgment signal indicating that the transmitted data is complete. If the result does not match, the pre-compiled smart contract triggers an exception handling process.

[0080] The data integrity verification layer is used for the data integrity and anti-tampering layer. In another embodiment, please refer to Figure 4 , and its specific implementation is as follows:

[0081] (1) Data preparation stage: The terminal encrypts the collected raw data through the first-layer data encryption layer, and then calculates the SHA-256 hash value of the encrypted data. This hash value is used as a data voucher to check whether the data has been tampered with. In this way, even if the data is intercepted during transmission, the attacker cannot easily modify the data.

[0082] 1) Import the hashlib library to generate the SHA-256 hash value. Crypto.Cipher.AES and Crypto.Random in the PyCryptodome library are used for AES-256 encryption.

[0083] 2) Store the raw data in a byte string.

[0084] 3) Generate a random key and encrypt the data with the key. For the AES-256 encryption algorithm, the key length must be 32 bytes (i.e., 256 bits), and get_random_bytes(32) is used to generate a random key.

[0085] 4) Initialize the AES encryptor, create an AES encryption object, and use the EAX mode to provide authenticated encryption to ensure that the data is both encrypted and its integrity can be verified.

[0086] 5) Encrypt the data. Use the created AES encryptor to encrypt the data and return two results: the encrypted text ciphertext and an authentication tag. This tag is used to verify the data integrity.

[0087] 6) Calculate the SHA-256 hash value of the encrypted data and use the SHA-256 algorithm to generate the hash value.

[0088] (2) Blockchain recording stage: The terminal or edge gateway packs the encrypted data hash value information into a transaction and adds it to the data layer of the blockchain. This information is permanently stored, and due to the immutability of the blockchain, the integrity of the data is guaranteed.

[0089] (3) Smart contract verification stage: When the newly encrypted lane line data is uploaded from the terminal to the cloud, off-chain transaction technology is enabled. Specifically, a distributed file system is used to store the new lane line data, and the oracle service provided by Chainlink is used to calculate the hash value. The off-chain calculation result is synchronized to the main chain, and predefined logic is executed through a precompiled contract, that is, comparing the hash value of the newly uploaded data with the corresponding hash value previously recorded on the blockchain. If the two match, the smart contract returns a confirmation signal indicating that the data has not been tampered with; if they do not match, the smart contract triggers an exception handling process, such as issuing an alarm, recording a log, or taking other measures.

[0090] By constructing a data integrity and anti-tampering layer through the above steps, secondary protection is carried out at the server cloud to ensure high security and integrity of the data at the cloud. Blockchain technology is used to record the key information of each data transmission, and the authenticity of the data is automatically verified through a smart contract, thereby preventing the data from being tampered with during the transmission process. This multi-level approach not only improves the security of the system but also enhances transparency and traceability.

[0091] Specifically, please refer to Figure 5 The establishment of encryption services and identity authentication from the terminal to the server through the combination of the TLS protocol and the public key infrastructure of the blockchain includes:

[0092] The first step: The terminal sends a first request message to the server. The first request message includes the TLS version, cipher suite, and extension field information supported by the terminal. The extension field includes parameters related to the blockchain PKI supported.

[0093] For example, the terminal sends a ClientHello message to the server. This message contains information such as the TLS version, cipher suite, and extension field supported by the client. The extension field includes parameters related to the blockchain PKI supported.

[0094] The second step: The server receives the first request message and sends a first response message. The first response message includes the cipher suite and session ID selected by the server, and a digital certificate. The issuance and management of the digital certificate are completed in cooperation with IPFS and the blockchain PKI. The digital certificate contains the server public key.

[0095] In this embodiment, the server responds to the client with a ServerHello message, which contains information such as the encryption suite and session ID selected by the server. Then the server sends its digital certificate, which contains the public key of the server. The issuance and management of the certificate are coordinated through IPFS and blockchain PKI, that is, off-chain transaction technology and the main chain, to ensure the transparency and immutability of the certificate. The server not only sends its own digital certificate but also a complete certificate chain (including intermediate certificates and root certificates). These certificates are registered and verified on IPFS and finally synchronized to the blockchain to ensure the credibility of the certificate chain. After sending the digital certificate and its own certificate chain, the server sends a ServerHelloDone message, indicating that the server has completed the initial handshake phase.

[0096] Step 3: The terminal verifies the digital certificate. After passing the verification, it generates a pre-master secret, encrypts it with the server's public key, and sends it to the server. The generation process of the pre-master secret is synchronized to the blockchain;

[0097] The terminal verifies the server's digital certificate. It mainly checks whether the certificate is within the valid period; verifies the integrity and credibility of the certificate through the monitoring system of off-chain transactions. At the same time, the monitoring system queries the revocation status of the certificate in real time and synchronizes the corresponding results to the main chain. After verifying the digital certificate, the terminal generates a pre-master secret, encrypts it with the server's public key, and then sends it to the server. The generation process of the pre-master secret is recorded in the monitoring system of off-chain transactions, and the relevant results are packaged and synchronized to the blockchain to increase transparency and subsequent review.

[0098] Step 4: The server decrypts the pre-master secret using its private key;

[0099] Step 5: The terminal and the server generate a session key based on the pre-master secret. The generation process is synchronized to the blockchain;

[0100] The terminal and the server respectively use the pre-master secret and other information in the handshake process to generate a session key. The generation process of the session key also needs to be recorded in the monitoring system of off-chain transactions, and the relevant results are packaged and synchronized to the blockchain to ensure the transparency and immutability of key generation.

[0101] Step 6: The terminal and the server send a ChangeCipherSpec message to enable session key encryption;

[0102] Both the terminal and the server send a ChangeCipherSpec message, indicating that subsequent messages will be encrypted using the session key. Immediately afterwards, the terminal sends a Finished message. The content of the message is mainly a hash value used to verify the integrity of the handshake process, and the Finished message is also encrypted with the session key.

[0103] Step 7: The terminal sends a Finished message encrypted with the session key to verify the integrity of the handshake and establish a data security communication layer between the terminal and the server.

[0104] In this embodiment, by using the blockchain for certificate management, in the traditional PKI, certificates are issued and managed by a centralized certificate authority. However, in the blockchain PKI, the issuance and management of certificates can be decentralized. That is, the blockchain can serve as a decentralized certificate distributed storage system, and relevant certificates and certificate revocation information can be recorded in the blockchain PKI. Multiple trusted nodes jointly participate in the certificate issuance and verification process, reducing the risk of single-point failures. Additionally, by using the blockchain for identity management, the combination of the blockchain and PKI can achieve multi-factor authentication. In addition to the traditional username and password, digital signatures based on the blockchain or biometric recognition (such as fingerprints, facial recognition) can also be used for identity verification. These authentication information can be stored on the blockchain to improve the security of identity verification. At the same time, in this embodiment, the storage locations of certificate and identity authentication-related information are also optimized. The distributed file system (IPFS) is combined with the blockchain and is mainly used to store relevant certificate content, information on the process of certificate status transformation, and identity authentication-related information, and then the results are summarized on the blockchain PKI. This can alleviate the problems of limited storage space and high costs on the main chain by storing off-chain. The above process enhances the real-time certificate verification status. In the traditional Online Certificate Status Protocol, the terminal IoT device needs to query the certificate status from the Online Certificate Status Protocol responder, which may lead to privacy leakage and delays. Through the blockchain, the server can attach the Online Certificate Status Protocol response when responding to the ClientHello message, and these responses can be verified by the nodes on the blockchain to ensure the credibility of the responses. In short, the terminal can directly query the status of the certificate from the blockchain instead of relying on a centralized Online Certificate Status Protocol responder. Through the immutable feature of the blockchain, the source and historical records of data can be traced, improving the transparency and traceability of the architecture.

[0105] In this embodiment, automated management is also achieved by using smart contracts. Through smart contracts, automatic renewal and revocation of certificates can be realized. For example, when a certificate is about to expire, the smart contract can automatically trigger the certificate renewal process; when an accident occurs to a certificate, the smart contract can automatically revoke the certificate; in addition, automated identity verification is achieved through smart contracts. For example, when a user attempts to access a certain resource, the smart contract can automatically verify the user's digital signature and identity information to ensure the accuracy and efficiency of identity verification.

[0106] In this embodiment, to relieve the burden on the main chain, a monitoring system is used to regularly check the validity period of the certificate, and this process is carried out off-chain transactions. When the certificate is about to expire, the off-chain service can automatically trigger the certificate renewal process. The off-chain service generates a certificate renewal request, which is submitted to the blockchain through an off-chain transaction. The smart contract automatically processes the renewal request and records the new validity period of the certificate on the blockchain. This can ensure the transparency and immutability of the renewal process. The smart contract can trigger the off-chain service to notify the certificate holder of the success or failure of the renewal. Similarly, when an accident occurs to the certificate or for automated authentication, it will also be completed in the form of cooperation between off-chain transactions and the main chain. Using off-chain transaction technology to optimize the blockchain can not only solve the problem of limited space on the main chain but also solve the response rate of the blockchain.

[0107] After the terminal and the server handshake and negotiate the key to establish a connection, the two parties transmit data through the session key, and all messages are recorded in the monitoring system of the off-chain transaction, and the relevant results are packaged and synchronized to the blockchain to increase the transparency and immutability of the data. Through the blockchain, all activities during the data transmission process can be monitored and audited in real time. Any abnormal behavior (such as invalid certificate, key negotiation failure, etc.) will be quickly discovered and processed (terminate the connection and record the abnormal event), improving the security and reliability of the architecture.

[0108] Those of ordinary skill in the art can realize that the units of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components of each example have been generally described according to their functions in the above description. Whether these functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0109] In the embodiments provided by the present invention, it should be understood that the division of units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units can be combined into one unit, one unit can be split into multiple units, or some features can be ignored, etc.

[0110] In addition, the functional units in each embodiment of the present invention can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0111] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes: various media such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs that can store program codes.

[0112] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the various embodiments of the present invention, and they should all be covered by the scope of the claims and the description of the present invention.

Claims

1. A lane line data secure transmission architecture, including building a multi-layer data security protection system between the terminal and the server, characterized in that, Including: Data encryption layer: Encrypt the lane line data collected by the terminal with a preset key and transmit the encrypted lane line data to the server; Data integrity verification layer: When the encrypted lane line data is transmitted to the server, record the verification elements of the transmission of the encrypted lane line data based on the blockchain data layer, and automatically verify the data through a pre-compiled smart contract; Data security communication layer: Establish an encrypted service and identity authentication from the terminal to the server through the TLS protocol combined with the public key infrastructure of the blockchain.

2. The lane line data secure transmission architecture according to claim 1, wherein The encrypting the lane line data collected by the terminal with a preset key and transmitting the encrypted lane line data to the server includes: Randomly generate a shared key between the terminal and the server; Generate a key pair including a public key and a private key according to the shared key; Use the public key to encrypt the symmetric key to generate an encrypted symmetric key; Store the encrypted symmetric key in the terminal, and use the symmetric key to encrypt the lane line data collected by the terminal device; Transmit the encrypted lane line data to the server.

3. The lane line data secure transmission architecture according to claim 2, wherein The encrypting the lane line data collected by the terminal device with the symmetric key includes: Perform data padding on the lane line data collected by the terminal device to obtain lane line data that meets the encryption requirements; Encrypt the lane line data that meets the encryption requirements with the symmetric key.

4. The lane line data secure transmission architecture according to claim 1, characterized in that, The when the encrypted lane line data is transmitted to the server, record the verification elements of the transmission of the encrypted lane line data based on the blockchain data layer, and automatically verify the data through a pre-compiled smart contract includes: When the encrypted lane line data is transmitted to the server, record the verification elements of each transmission of the encrypted lane line data based on the blockchain data layer; Verify whether the verification elements of the latest received lane line data match the recorded verification elements; If the result matches, it means the transmitted data is complete. If the result does not match, trigger an exception handling process.

5. The lane line data secure transmission architecture according to claim 4, wherein The verification elements include at least one of a hash value, a timestamp, a device ID, a serial number, and a geographical location.

6. The lane line data secure transmission architecture according to claim 5, characterized in that When the verification element is a hash value, the when the encrypted lane line data is transmitted to the server, record the verification elements of the transmission of the encrypted lane line data based on the blockchain data layer, and automatically verify the data through a pre-compiled smart contract includes: When the encrypted lane line data is transmitted to the server, enable off-chain transaction technology, record each encrypted lane line data based on the distributed file system of the blockchain data layer, calculate the hash value of each time, and synchronize the off-chain calculation result to the main chain; Use the hash value of the latest received encrypted lane line data as the condition to trigger the pre-compiled smart contract, and verify whether the latest calculated hash value matches the hash value result previously recorded on the blockchain data layer according to the pre-compiled smart contract deployed on the blockchain contract layer; If the result matches, the pre-compiled smart contract returns a confirmation signal indicating that the transmitted data is complete. If the result does not match, the pre-compiled smart contract triggers an exception handling process.

7. The lane line data secure transmission architecture according to claim 1, wherein The establishing an encrypted service and identity authentication from the terminal to the server through the TLS protocol combined with the public key infrastructure of the blockchain includes: The terminal sends a first request message to the server, and the first request message includes the TLS version, cipher suite, and extension field information supported by the terminal; the extension field includes the blockchain PKI-related parameters supported. The server receives the first request message and sends a first response message, and the first response message includes the cipher suite selected by the server, session ID, and digital certificate. The issuance and management of the digital certificate are completed in cooperation with the blockchain PKI through IPFS, and the digital certificate contains the server public key. The terminal verifies the digital certificate, generates a pre-master secret after verification, encrypts it with the server public key, and sends it to the server. The generation process of the pre-master secret is synchronized to the blockchain. The server decrypts the pre-master secret using the private key. The terminal and the server generate a session key based on the pre-master secret, and the generation process is synchronized to the blockchain. The terminal and the server send a ChangeCipherSpec message to enable session key encryption. The terminal sends a Finished message encrypted with the session key, verifies the integrity of the handshake, and establishes a data security communication layer between the terminal and the server.

8. The lane line data secure transmission architecture according to claim 7, characterized in that, The terminal's verification of the digital certificate includes checking the certificate validity period, verifying the integrity and credibility of the certificate, and querying the certificate revocation status.

Images