A car sentry mode video security transmission system and method

Abstract

The application discloses a kind of car sentry mode video safety transmission systems and methods, it is related to safety transmission field, the system includes: vehicle terminal, cloud server and user terminal;Vehicle terminal is used to determine session key based on user end public key and car end temporary private key, according to session key, using 128-bit advanced encryption standard counter mode to the video file of sentry mode collection is encrypted, obtains encrypted video file, and generates metadata file;Cloud server is used to store encrypted video file and metadata file, and according to the request of user terminal metadata file and encrypted video file are sent to user terminal;User terminal is used to determine session key according to user end private key and car end temporary public key in metadata file, and according to session key, using 128-bit advanced encryption standard counter mode to encrypted video file is decrypted.The application can safely protect sentry mode video, and improve the experience of user.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of secure transmission, in particular to a vehicle sentry mode video secure transmission system and method. BACKGROUND

[0002] With the popularization and promotion of intelligent networked vehicles, vehicle safety is paid more and more attention by vehicle owners, society and the country. The vehicle sentry mode is like a "bodyguard", which monitors the environment around the vehicle through the camera on the vehicle, and can quickly record video and notify the vehicle owner if a collision, car scratching, or someone stealing something occurs. However, the video uploaded to the cloud is in plaintext, which may contain the privacy of the vehicle owner, the location of the vehicle, and the information of the surrounding people. If the leakage occurs during transmission or storage, the consequences are not only personal privacy leakage and economic damage to enterprises, but also may cause threat to life, so the demand for encryption of video data of sentry mode function is increasing day by day.

[0003] Therefore, how to securely store video data, reliably distribute the key to the vehicle owner, and how the vehicle owner authorizes the cloud and the vehicle sharer to view the encrypted video have become the key to the promotion of the sentry mode. SUMMARY

[0004] The purpose of the present application is to provide a vehicle sentry mode video secure transmission system and method, which can improve the security of vehicle video and improve user experience.

[0005] To achieve the above purpose, the present application provides the following solutions:

[0006] In a first aspect, the present application provides a vehicle sentry mode video secure transmission system, comprising a vehicle terminal, a cloud server and a user terminal.

[0007] The vehicle terminal is configured to determine a session key based on a user terminal public key and a vehicle terminal temporary private key, encrypt a video file collected by the sentry mode using a 128-bit advanced encryption standard counter mode according to the session key to obtain an encrypted video file, and generate a metadata file; the metadata file includes sentry trigger event metadata and a vehicle terminal temporary public key.

[0008] The cloud server is configured to store the encrypted video file and the metadata file, and send the metadata file and the encrypted video file to the user terminal according to a request of the user terminal.

[0009] The user terminal is configured to determine a session key according to a user terminal private key and the vehicle terminal temporary public key in the metadata file, and decrypt the encrypted video file using a 128-bit advanced encryption standard counter mode according to the session key.

[0010] The user terminal public key, the user terminal private key, the vehicle terminal temporary public key and the vehicle terminal temporary private key are all keys generated by using a 256-bit key elliptic curve encryption algorithm.

[0011] In an embodiment, the vehicle terminal performs local negotiation by using an elliptic curve temporary Diffie-Hellman protocol according to the user terminal public key and the vehicle terminal temporary private key, to obtain a session key.

[0012] In an embodiment, the vehicle terminal is further configured to sign the metadata file by using a vehicle terminal private key; and the user terminal is further configured to verify the metadata file by using a vehicle terminal public key; the vehicle terminal private key and the vehicle terminal public key are both keys generated by using a 256-bit key elliptic curve encryption algorithm.

[0013] In an embodiment, the vehicle terminal transmits the encrypted video file and the metadata file to the cloud server by using a secure channel established by bidirectional authentication.

[0014] In an embodiment, the user terminal includes a vehicle owner terminal and a sharer terminal.

[0015] The vehicle owner terminal is configured to obtain a session key according to a user terminal private key and a vehicle terminal temporary public key in a metadata file, and decrypt the encrypted video file by using a 128-bit advanced encryption standard counter mode according to the session key.

[0016] The sharer terminal is configured to generate a video viewing request according to the metadata file to be viewed, and send the video viewing request to the vehicle owner terminal.

[0017] The vehicle owner terminal is further configured to generate a vehicle owner temporary public-private key pair according to the video viewing request, determine a local session key according to a vehicle owner temporary private key and a sharer public key, encrypt the session key by using the local session key, and insert the vehicle owner temporary public key and the encrypted session key into the metadata file to be viewed and send the metadata file to the sharer terminal.

[0018] The sharer terminal is further configured to obtain a session key according to a sharer private key and a vehicle owner temporary public key in the metadata file to be viewed, and decrypt the encrypted video file by using a 128-bit advanced encryption standard counter mode according to the session key.

[0019] The vehicle owner temporary public-private key pair, the sharer public key and the sharer private key are all keys generated by using a 256-bit key elliptic curve encryption algorithm.

[0020] In an embodiment, the shared terminal is further configured to sign the metadata file to be viewed by using a shared private key; and the owner terminal is further configured to verify the metadata file to be viewed by using a shared public key, and generate an owner temporary public-private key pair after the verification is passed.

[0021] In an embodiment, the owner terminal is configured to perform local negotiation by using an elliptic curve temporary Diffie-Hellman protocol according to the owner temporary private key and the shared public key, and determine a local session key.

[0022] In an embodiment, the owner terminal is further configured to send the metadata file to be viewed after signing by using an owner terminal private key; and the shared terminal is further configured to verify the metadata file to be viewed by using an owner terminal public key; the owner terminal private key and the owner terminal public key are both generated by using a 256-bit key elliptic curve encryption algorithm.

[0023] In a second aspect, the application provides a vehicle sentinel mode video safety transmission method, comprising:

[0024] The vehicle terminal determines a session key based on a user terminal public key and a vehicle terminal temporary private key, encrypts a video file collected in the sentinel mode by using a 128-bit advanced encryption standard counter mode according to the session key, obtains an encrypted video file, and generates a metadata file; the metadata file includes sentinel trigger event metadata and a vehicle terminal temporary public key;

[0025] The cloud server stores the encrypted video file and the metadata file, and sends the metadata file and the encrypted video file to the user terminal according to a request of the user terminal;

[0026] The user terminal determines a session key according to a user terminal private key and the vehicle terminal temporary public key in the metadata file, and decrypts the encrypted video file by using a 128-bit advanced encryption standard counter mode according to the session key.

[0027] The user terminal determines a session key according to a user terminal private key and the vehicle terminal temporary public key in the metadata file, and decrypts the encrypted video file by using a 128-bit advanced encryption standard counter mode according to the session key.

[0028] In an embodiment, determining the session key based on the user terminal public key and the vehicle terminal temporary private key comprises: performing local negotiation by using an elliptic curve temporary Diffie-Hellman protocol according to the user terminal public key and the vehicle terminal temporary private key, and obtaining the session key.

[0029] According to the specific embodiments provided in the application, the application has the following technical effects: the application provides an automobile sentry mode video safety transmission system and method, a key generated by using a 256-bit key elliptic curve encryption algorithm and a 128-bit advanced encryption standard counter mode are used to encrypt a video file collected in a sentry mode, the sentry mode video can be safely protected, and when a user receives a metadata file notification, the video has been encrypted and uploaded, the waiting time for the user to click to negotiate a key and then encrypt is reduced, and the user experience is improved. BRIEF DESCRIPTION OF DRAWINGS

[0030] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed in the embodiments. Obviously, the drawings in the following description are only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0031] Figure 1 A structural schematic diagram of an automobile sentry mode video safety transmission system provided in an embodiment of the application.

[0032] Figure 2 A timing diagram of video encryption, key distribution and owner decryption in an embodiment of the application.

[0033] Figure 3 A timing diagram of a shared person viewing an encrypted video in an embodiment of the application.

[0034] Figure 4 A flowchart of an automobile sentry mode video safety transmission method provided in an embodiment of the application. DETAILED DESCRIPTION

[0035] The technical solutions in the embodiments of the application will be described clearly and completely in the following with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only some of the embodiments of the application, but not all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the protection scope of the application.

[0036] In order to make the above-mentioned purposes, features and advantages of the application more obvious and easy to understand, the application will be further described in detail in the following with reference to the drawings and specific embodiments.

[0037] First, some technical terms involved in the embodiments of the application are introduced.

[0038] (1) Counter (CTR) mode of the Advanced Encryption Standard (AES).

[0039] AES is an internationally recognized block symmetric encryption algorithm, with a block length and key length of 128 bits, 192 bits or 256 bits, and a multi-round nonlinear iteration structure, and is widely used in the field of global data encryption. CTR mode is one of the important working modes supported by AES, with unique technical advantages and application scenarios.

[0040] In CTR mode, a counter mechanism is introduced in the encryption process. The initial value of the counter is usually set by the user or generated through a specific initialization vector, and it will be incremented (usually by 1) in the encryption process. Each counter value is processed by the AES encryption algorithm to generate a keystream block, which is then XORed with the corresponding plaintext block to obtain the ciphertext block. For example, if the plaintext is divided into P1, P2, P3, …, etc. blocks of 128 bits, the initial value of the counter is Ctr0, and the keystream block K0 = AES (Ctr0) is obtained after AES encryption, then the ciphertext block C1 = P1 ⊕ K0; the counter value is incremented to Ctr1, K1 = AES (Ctr1), C2 = P2 ⊕ K1, and so on. The decryption process is the reverse operation, and the same keystream block is generated by the same counter value sequence, and the ciphertext block is XORed to restore the plaintext.

[0041] CTR mode converts block encryption algorithm into stream encryption algorithm, enabling parallel processing of the encryption process. Since the encryption of each plaintext block depends on the encryption result of the corresponding counter value, multiple plaintext blocks can be encrypted simultaneously, greatly improving encryption efficiency, especially for scenarios involving massive data processing. At the same time, this mode supports random access, i.e. without decrypting the entire ciphertext sequence, the ciphertext block at a specific position can be directly decrypted, which is of great significance in applications such as encryption and decryption of data fragments in network transmission that require fast access to partial data.

[0042] Compared to other working modes of AES, CTR mode significantly improves encryption performance while maintaining the high-strength encryption characteristics of AES algorithm. Its parallel processing capability enables encryption speed to be fully optimized in a multi-core processor environment, meeting the needs of scenarios such as large data storage encryption and high-speed network communication encryption, which have extremely high requirements for encryption efficiency. In addition, CTR mode has limitations on error propagation, as the transmission error of a ciphertext block only affects the recovery of the plaintext corresponding to that block, unlike the Cipher-Block Chaining (CBC) mode, which causes decryption errors for multiple subsequent blocks, enhancing the reliability of data transmission and highlighting the application advantage in complex network environments.

[0043] (2) 256-bit Secure Hash Algorithm (SHA256).

[0044] SHA256 is an important member of the SHA-2 series of hash algorithms, playing a key role in ensuring information integrity. Its core features are built around the core needs of hash algorithms and are widely used in various information security scenarios around the world.

[0045] SHA256 adopts the Merkle-Damgård structure, and the input message is grouped into 512-bit data blocks for processing. The algorithm generates a 256-bit fixed-length digest value through a series of complex operations, including message expansion and compression function operations. The message expansion process expands the input message into a longer message sequence according to specific rules to meet the needs of subsequent compression function operations; the compression function performs multiple rounds of processing on the expanded message based on logical operations and shift operations, so that any slight change in the input message will cause a significant difference in the output digest value, i.e., the avalanche effect that is crucial to hash algorithms.

[0046] In the digital signature scenario, SHA256 is used to hash the message to generate a message digest, and then the digest is signed using an asymmetric encryption algorithm. The verifier compares the SHA256 digest recalculated from the message with the received signature to ensure that the message has not been tampered with during transmission and that the source is reliable; in the message authentication code generation and verification, SHA256 is combined with a key to generate a message authentication code using a keyed hash algorithm (Hash-based Message Authentication Code-SHA256, HMAC-SHA256). The receiver uses the same key and SHA256 algorithm to recalculate the authentication code for comparison, thereby confirming the integrity and authenticity of the message; in addition, in some password applications that require random number generation, SHA256 can also be part of a random number generator, which outputs a sequence of numbers with a certain randomness by hashing the initial seed value.

[0047] SHA256 has high security and performs well in resisting collision attacks, making it one of the most widely used hash algorithms internationally. Compared to SHA-1 and other algorithms whose security has been questioned, SHA256 can provide stronger security and is widely used in e-commerce, digital certificates, blockchain, and other fields, effectively ensuring data integrity and reliability and reducing security risks caused by data tampering.

[0048] (3) Elliptic Curve Cryptography with 256-bit key (ECC 256) algorithm.

[0049] As an internationally recognized asymmetric encryption standard, ECC 256 is based on the Elliptic Curve Cryptography (ECC) system. Its core advantage is that it has a shorter key length while maintaining the same level of security. The security of 256-bit ECC is equivalent to that of a 2048-bit Rivest-Shamir-Adleman (RSA) public key encryption system, and its computational efficiency is significantly higher than that of traditional asymmetric algorithms.

[0050] ECC 256 uses specific elliptic curve parameters (such as the recommended secp256r1 curve), and the curve equation is y 2 = x 3 + ax + b, where a and b are curve coefficients, x is the independent variable, y is the dependent variable, and the finite field is the prime field GF (p), which ensures that the curve has the property of resisting elliptic curve discrete logarithm problems, which is the core basis of its security.

[0051] ECC 256 not only supports encryption and decryption, but also integrates digital signature and key agreement functions. Its signature process usually combines a hash algorithm (such as SHA256) to generate a signature by encrypting the message hash value. Verification needs to verify the validity of the signature and the integrity of the message. The encryption process uses a public key encryption and a private key decryption mode, and the ciphertext contains elliptic curve points, symmetric key encryption results, and other information to ensure data confidentiality. In terms of key agreement, ECC 256 can use Diffie-Hellman (DH) and other protocols to securely generate a shared key between communication parties without directly transmitting the key.

[0052] Compared with traditional asymmetric algorithms such as RSA, ECC 256 has a shorter key length, which saves resources in storage and transmission, and has higher computational efficiency, which can significantly improve the speed of encryption and decryption, signature verification, and other operations, especially suitable for resource-constrained scenarios such as mobile devices and Internet of Things devices. In addition, the security of ECC 256 has been widely recognized by the international cryptography community and is widely used in the fields of finance, communication, and the Internet worldwide. It can meet the high security requirements and adapt to the performance limitations of various devices, and has high practical value.

[0053] (4) Elliptic Curve Diffie-Hellman (ECDH) protocol.

[0054] ECDH protocol, as a key exchange protocol based on elliptic curve cryptography, plays a key role in modern information security. Its core advantage is that it can securely negotiate a shared key between two communicating parties in an insecure communication channel without the need to pre-share any secret information.

[0055] The security of the ECDH protocol is firmly based on the difficulty of the elliptic curve discrete logarithm problem. Given two points P and Q on an elliptic curve, Q = k·P, where k is an integer and "·" represents the elliptic curve point multiplication operation, it is computationally infeasible to efficiently solve for k given P and Q. This property provides a solid security guarantee for the ECDH protocol.

[0056] Protocol parameter setting: The two communicating parties must agree on a specific elliptic curve in advance, such as secp256r1 widely adopted internationally, or ECC 256K1P256V1 curve in international standards. At the same time, a base point G (also known as a generator) on the curve needs to be determined. These curve parameters directly determine the security strength of the algorithm. For example, a 256-bit elliptic curve has the same security as a 3072-bit integer field in the traditional DH protocol.

[0057] Compared with the traditional DH protocol based on large integer operations, the ECDH protocol has significantly shorter key lengths at the same security level, and its computational complexity is also smaller, making it very suitable for resource-constrained scenarios such as mobile devices and Internet of Things terminals, while ensuring security and reducing the consumption of device computing resources and power.

[0058] Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) protocol is a key exchange protocol that combines elliptic curve cryptography and ephemeral DH, mainly used to securely negotiate session keys in an insecure network environment. Compared with the traditional DH algorithm based on large integer factorization, ECDHE uses point operations on elliptic curves to achieve key exchange, providing the same security level with shorter key lengths and higher computational efficiency, making it suitable for resource-constrained scenarios (such as mobile devices and Internet of Things). And ECDHE generates a temporary key pair for each session, which is discarded after the session ends. Even if the private key is later compromised, it cannot decrypt historical session data, so it has forward security.

[0059] The ECDHE protocol is widely used in the TLS / SSL protocol to establish a secure network connection, guarantee the confidentiality and integrity of data in the transmission process, realize the secure communication between a remote user and an enterprise internal network in a virtual private network (VPN), and ensure the security of message transmission between users in instant messaging software. In addition, in some scenarios, the ECC 256K1 algorithm is often combined to realize the key agreement function similar to ECDH, which not only meets the compliance requirements of information security, but also fully plays the advantages of the elliptic curve cryptography system.

[0060] The application uses the ECC 256K1 method similar to ECDHE to negotiate a session key, and uses the negotiated session key to encrypt the video through the AES 128 CTR mode, which can effectively guarantee the confidentiality, integrity and availability of the video data, and provides a complete and perfect solution with minimal system modification for the safe processing of the car sentinel mode video.

[0061] In an exemplary embodiment, as shown in Figures 1 to 3 A car sentinel mode video secure transmission system is provided, which includes a vehicle terminal 101, a cloud server 102 and a user terminal 103. The vehicle terminal 101 and the user terminal 103 are both installed with an application program to realize corresponding functions.

[0062] The vehicle terminal 101 is configured to determine a session key based on a user terminal public key and a vehicle terminal temporary private key, encrypt a video file collected in a sentinel mode by using a 128-bit advanced encryption standard counter mode according to the session key, obtain an encrypted video file, and generate a metadata file. The metadata file includes sentinel trigger event metadata and a vehicle terminal temporary public key. The sentinel trigger event metadata includes information such as the time of a sentinel event trigger and a threat level. A video file is recorded by a surround camera when a threat touches the vehicle, forming a video file collected in a sentinel mode.

[0063] In a specific application example, a camera on the vehicle shoots a 1-minute video when the sentinel mode is triggered, then adjusts the frame rate and code rate, can also splice 4-way surround videos, and desensitizes the face and vehicle license plate according to the requirements of the national standard GBT44464, and saves them into a video file.

[0064] The vehicle terminal 101 performs local negotiation by using an elliptic curve temporary Diffie-Hellman protocol according to the user terminal public key and the vehicle terminal temporary private key, and obtains the session key. The user terminal public key is obtained when the user binds a mobile phone.

[0065] The vehicle terminal 101 is further configured to sign the metadata file by using a vehicle terminal private key.

[0066] The vehicle-mounted terminal 101 transmits the encrypted video file and the signed metadata file to the cloud server 102 through a secure communication channel established by bidirectional TLS 1.2 or above authentication.

[0067] The cloud server 102 is configured to store the encrypted video file and the metadata file, and send the metadata file and the encrypted video file to the user terminal 103 according to a request of the user terminal 103.

[0068] The user terminal 103 and the cloud server 102 establish a secure communication channel by bidirectional TLS 1.2 or above authentication.

[0069] The cloud server 102 is further configured to perform authentication and authorization of the user terminal 103, including user login authentication and verification of user identity. If the vehicle is in a sharing state or a rental state, the metadata file is pushed to a shared terminal.

[0070] The user terminal 103 is configured to determine a session key according to a user terminal private key and a vehicle terminal temporary public key in the metadata file, and decrypt the encrypted video file by using a 128-bit advanced encryption standard counter mode according to the session key.

[0071] The user terminal 103 is further configured to verify the metadata file by using a vehicle terminal public key. Specifically, after receiving the metadata file pushed by the sentinel alarm event, the vehicle owner uses the vehicle terminal public key obtained during vehicle owner binding to verify the metadata file, so as to ensure the authenticity and integrity of the data. After verification, the user can view the video list and select a video to be decrypted and played.

[0072] In one specific application example, the user terminal 103 includes a vehicle owner terminal and a shared terminal.

[0073] The vehicle owner terminal is configured to determine a session key according to a user terminal private key and a vehicle terminal temporary public key in the metadata file, and decrypt the encrypted video file by using a 128-bit advanced encryption standard counter mode according to the session key.

[0074] Specifically, the vehicle owner terminal uses the user terminal private key and the vehicle terminal temporary public key in the metadata file to negotiate and restore the session key. After downloading the encrypted video file through the encrypted video link provided by the cloud server 102, the vehicle owner terminal decrypts and views the video by using the AES128 algorithm CTR mode and the session key.

[0075] The shared terminal is configured to generate a video viewing request according to the metadata file to be viewed, and send the video viewing request to the vehicle owner terminal.

[0076] Specifically, the sharer terminal signs the metadata file to be viewed by using the sharer private key. The signed metadata file is sent to the owner terminal as a video viewing request through various channels. Specifically, it can be transmitted to the cloud server 102 using a mobile application, sent to the application of the owner terminal by the cloud server 102 through a secure channel, or sent to the owner terminal in the form of information using WeChat, a mini program, a Feishu, and a short message, which are non-secure channels.

[0077] After receiving the video viewing request, the owner terminal verifies the metadata file to be viewed by using the sharer public key (obtained when sharing the vehicle), and after the verification is passed, generates an owner temporary public-private key pair according to the video viewing request, determines a local session key according to the owner temporary private key and the sharer public key, encrypts the session key using the local session key, and inserts the owner temporary public key and the encrypted session key into the metadata file to be viewed and sends it to the sharer terminal. The owner terminal is also used to sign the metadata file to be viewed by using the owner terminal private key and send it to the sharer terminal to protect the integrity and authenticity of the file.

[0078] Specifically, the owner terminal determines the local session key by using the elliptic curve temporary Diffie-Hellman protocol according to the owner temporary private key and the sharer public key.

[0079] The sharer terminal is also used to verify the metadata file to be viewed by using the owner terminal public key, and after the verification is passed, obtains the session key according to the sharer private key and the owner temporary public key in the metadata file to be viewed, and decrypts the encrypted video file by using the 128-bit advanced encryption standard counter mode according to the session key.

[0080] The user terminal public key, the user terminal private key, the car terminal temporary public key, the car terminal temporary private key, the car terminal private key, the car terminal public key, the owner temporary public-private key pair, the owner terminal private key, the owner terminal public key, the sharer public key, and the sharer private key are all keys generated by using a 256-bit key elliptic curve encryption algorithm.

[0081] Further, the present application can also use quantum algorithms to implement key management and distribution, further improve security, and combine a trusted execution environment to make the whole life cycle of video data more secure, further improve the popularity and security of the car sentinel mode.

[0082] The security of the car sentinel mode video security transmission system provided by the present application is analyzed as follows.

[0083] (1) Confidentiality analysis: The file is encrypted using AES 128 CBC mode, making it more difficult to crack. ECC 256K1 is used to negotiate the session key in a similar way to ECDHE, as the elliptic curve discrete logarithm problem is difficult to solve, even if others intercept the public key, they cannot obtain the session key, ensuring the confidentiality of the key.

[0084] (2) Authenticity analysis: To ensure the authenticity of the metadata file, ECC 256K1 digital signature mechanism is introduced. The specific process is as follows: the generator of the metadata file uses its own ECC 256K1 private key to sign the file, generating a unique digital signature; the receiver uses the public key of the signer to verify the signature after obtaining the metadata file and the signature. Since the ECC 256K1 private key is only held by the signer, any third party without the private key cannot forge a valid signature, and the public nature of the public key ensures that the receiver can easily verify the legality of the signature. Through this process, the receiver can determine whether the metadata file is generated by a legitimate sender, effectively resisting the security threat of attackers forging metadata and impersonating legitimate subjects to communicate, and technically ensuring the authenticity of the metadata source.

[0085] (3) Integrity analysis: The integrity of the metadata file is also guaranteed by the ECC 256K1 private key signature and public key verification mechanism. The ECC 256K1 signature process does not directly encrypt the file itself, but first performs SHA256 hash operation on the metadata file to generate a fixed-length message digest, and then encrypts the digest with the private key to form the signature. The hash function has an "avalanche effect" - even a single bit of change in the metadata file will cause the generated message digest to change dramatically. Therefore, if the metadata file is tampered with during transmission or storage, the receiver will immediately detect that the file integrity is compromised when the decrypted digest obtained by the public key does not match the digest obtained by rehashing the received file. This "signature bound to the file, tampering invalid" feature ensures that the metadata file has not been modified by unauthorized parties from generation to reception, and the original information remains intact.

[0086] (4) Anti-attack analysis.

[0087] Anti-brute force capability: ECC 256K1 algorithm uses 256-bit key length, and AES 128 algorithm uses 128-bit key length, both of which far exceed the cracking ability of current mainstream attack methods. Taking brute force cracking as an example, for the AES128 algorithm with a 128-bit key, the attacker needs to try The possible key combination, even if the current most advanced supercomputer, to complete all attempts need to spend far more than the history of human civilization time; and 256-bit ECC 256K1 key makes the cracking difficulty exponentially increases, from the point of view of computing resources and time cost, brute force cracking is almost impossible to complete the task. At the same time, the design of AES128 and ECC 256K1 algorithm itself has high complexity, its round function, permutation operation, nonlinear transformation and other links are strictly analyzed and verified by cryptography, which can effectively resist differential analysis, linear analysis and other classical attack methods against block cipher and public key cryptography.

[0088] Anti-middleman attack capability: the system integrates TLS / SSL protocol for identity authentication, and in the early stage of communication establishment, through the digital certificate chain verification mechanism, the identity of the communication parties is ensured to be legal. If an attacker tries to insert between the two communication parties and pretend to be an "intermediary" to intercept and tamper with information, it will be identified and blocked by the TLS / SSL protocol because it cannot provide a legal digital certificate, thereby effectively preventing the security risks of eavesdropping, tampering or forgery caused by man-in-the-middle attacks.

[0089] In summary, the present application provides a high-strength encryption algorithm, a secure key negotiation mechanism, a digital signature verification, and a multi-protection of TLS1.2 version or above protocol, and the system forms a comprehensive security protection system in terms of confidentiality, authenticity, integrity and attack resistance, which can effectively resist various common network attacks and security threats.

[0090] Based on the same inventive concept, the embodiments of the present application also provide a car sentinel mode video security transmission method for applying the car sentinel mode video security transmission system described above. The implementation scheme for solving the problem provided by the method is similar to the implementation scheme described in the system, so the specific limitations in one or more method embodiments provided below can refer to the limitations of the system described above, and will not be described here.

[0091] As shown in Figure 4 The car sentinel mode video security transmission method includes the following steps 401 to 403.

[0092] Step 401: determining a session key based on a user-side public key and a car-side temporary private key through a vehicle-mounted terminal, encrypting a video file collected in a sentinel mode by using a 128-bit advanced encryption standard counter mode according to the session key to obtain an encrypted video file, and generating a metadata file. The metadata file includes sentinel trigger event metadata and a car-side temporary public key.

[0093] Among them, the local negotiation is performed by using an elliptic curve temporary Diffie-Hellman protocol according to the user-side public key and the car-side temporary private key to obtain the session key.

[0094] Step 402, storing the encrypted video file and the metadata file by the cloud server, and sending the metadata file and the encrypted video file to the user terminal according to the request of the user terminal.

[0095] Step 403, determining a session key by the user terminal according to the user terminal private key and the vehicle terminal temporary public key in the metadata file, and decrypting the encrypted video file by using the counter mode of the 128-bit advanced encryption standard according to the session key.

[0096] The user terminal public key, the user terminal private key, the vehicle terminal temporary public key and the vehicle terminal temporary private key are all keys generated by using a 256-bit key elliptic curve encryption algorithm.

[0097] The application uses video file encryption to solve the problem that anyone can view the video in the cloud. The cloud server cannot decrypt and view the video of the vehicle owner at will. When a third party needs to verify the video, the vehicle owner can authorize the viewing of specified videos, while minimizing changes to existing business processes. The vehicle owner can normally view the sentinel video, reducing the waiting time of the vehicle owner due to encryption, and improving user experience. In addition, after the vehicle is shared or rented, the sharer or renter can be authorized to view the sentinel video, and the vehicle owner and the sharer do not need to interact in real time.

[0098] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant regulations.

[0099] In the application, all actions of obtaining signals, information or data are performed under the premise of complying with the corresponding data protection regulations and policies of the place, and under the premise of obtaining authorization from the owner of the corresponding device.

[0100] The technical features of the above embodiments can be combined in any way. To make the description concise, not all possible combinations of the technical features in the above embodiments are described, but as long as the combinations of the technical features do not exist, they should be considered as the scope of the description.

[0101] The principles and implementation modes of the application are described by using specific examples in this paper, and the above examples are only used to help understand the method and its core idea; at the same time, for those skilled in the art, according to the idea of the application, the specific implementation mode and application range will be changed. In conclusion, the content of the description should not be understood as a limitation of the application.

Claims

1. A vehicle sentry mode video security transmission system, characterized in that, The system includes: an in-vehicle terminal, a cloud server, and a user terminal; The vehicle-mounted terminal is used to determine a session key based on the user's public key and the vehicle's temporary private key. According to the session key, it encrypts the video file captured in sentry mode using a counter mode of 128-bit advanced encryption standard to obtain an encrypted video file and generate a metadata file. The metadata file includes sentry trigger event metadata and the vehicle's temporary public key. The vehicle-mounted terminal obtains the session key by locally negotiating using the elliptic curve temporary Diffie-Hellman protocol based on the user's public key and the vehicle's temporary private key. The cloud server is used to store the encrypted video file and the metadata file, and sends the metadata file and the encrypted video file to the user terminal according to the user terminal's request; The user terminal is used to determine the session key based on the user terminal private key and the vehicle terminal temporary public key in the metadata file, and to decrypt the encrypted video file using the 128-bit Advanced Encryption Standard counter mode based on the session key. The vehicle-mounted terminal is also used to sign the metadata file using the vehicle-mounted private key; the user terminal is also used to verify the signature of the metadata file using the vehicle-mounted public key. The vehicle-side private key, the vehicle-side public key, the user-side public key, the user-side private key, the vehicle-side temporary public key, and the vehicle-side temporary private key are all keys generated using a 256-bit elliptic curve cryptography algorithm.

2. The vehicle sentry mode video security transmission system according to claim 1, characterized in that, The vehicle-mounted terminal uses a secure channel established through two-way authentication to transmit the encrypted video file and the metadata file to the cloud server.

3. The vehicle sentry mode video security transmission system according to claim 1, characterized in that, The user terminal includes the vehicle owner's terminal and the terminal of the user being shared with; The vehicle owner terminal is used to obtain a session key based on the user terminal private key and the vehicle terminal temporary public key in the metadata file, and to decrypt the encrypted video file using the 128-bit Advanced Encryption Standard counter mode based on the session key. The recipient's terminal is used to generate a video viewing request based on the metadata file to be viewed, and send it to the vehicle owner's terminal; The vehicle owner terminal is also used to generate a temporary public-private key pair for the vehicle owner based on the video viewing request, determine a local session key based on the temporary private key of the vehicle owner and the public key of the recipient, encrypt the session key using the local session key, and insert the temporary public key of the vehicle owner and the encrypted session key into the metadata file to be viewed and send it to the terminal of the recipient. The terminal being shared with is also used to obtain a session key based on the private key of the recipient and the temporary public key of the vehicle owner in the metadata file to be viewed, and to decrypt the encrypted video file using the 128-bit Advanced Encryption Standard counter mode based on the session key. The vehicle owner's temporary public-private key pair, the shared public key, and the shared private key are all keys generated using a 256-bit elliptic curve cryptography algorithm.

4. The vehicle sentry mode video security transmission system according to claim 3, characterized in that, The terminal of the recipient is also used to sign the metadata file to be viewed using the recipient's private key; the terminal of the vehicle owner is also used to verify the signature of the metadata file to be viewed using the recipient's public key, and generate a temporary public-private key pair for the vehicle owner after the signature verification is successful.

5. The vehicle sentry mode video security transmission system according to claim 3, characterized in that, The vehicle owner's terminal uses the elliptic curve temporary Diffie-Hellman protocol to negotiate locally based on the vehicle owner's temporary private key and the shared public key to determine the local session key.

6. The vehicle sentry mode video security transmission system according to claim 3, characterized in that, The vehicle owner terminal is also used to sign the metadata file to be viewed using the vehicle owner's private key and then send it to the shared terminal; the shared terminal is also used to verify the signature of the metadata file to be viewed using the vehicle owner's public key; both the vehicle owner's private key and the vehicle owner's public key are keys generated using a 256-bit elliptic curve cryptography algorithm.

7. A method for secure video transmission in vehicle sentry mode, using the vehicle sentry mode video security transmission system according to any one of claims 1-6, characterized in that, The method includes: The in-vehicle terminal determines a session key based on the user's public key and the vehicle's temporary private key. Using this session key, the video file captured in sentry mode is encrypted using a 128-bit advanced encryption standard counter mode to obtain an encrypted video file. A metadata file is then generated, and the vehicle's private key is used to sign the metadata file. The metadata file includes sentry trigger event metadata and the vehicle's temporary public key. Determining the session key based on the user's public key and the vehicle's temporary private key includes: locally negotiating the session key using an elliptic curve temporary Diffie-Hellman protocol based on the user's public key and the vehicle's temporary private key. The encrypted video file and the metadata file are stored on a cloud server, and the metadata file and the encrypted video file are sent to the user terminal according to the user terminal's request; The user terminal uses the vehicle-side public key to verify the signature of the metadata file, determines the session key based on the user terminal private key and the vehicle-side temporary public key in the metadata file, and decrypts the encrypted video file using the 128-bit Advanced Encryption Standard counter mode based on the session key. The vehicle-side private key, the vehicle-side public key, the user-side public key, the user-side private key, the vehicle-side temporary public key, and the vehicle-side temporary private key are all keys generated using a 256-bit elliptic curve cryptography algorithm.

Images