Video security transmission method and system

Abstract

The present invention belongs to the field of communication technology, and provides a video security transmission method and system. The method comprises: slicing the audio data to be processed in units of GOP to obtain video slices to be sent; encrypting and encapsulating each video slice to be sent through a custom private transmission protocol, specifically including constructing header information according to the video data type and data length, calculating verification parameters, and multiple rounds of encryption processing; and sending the encrypted and encapsulated video slices to the receiving end. The present invention effectively solves the risk of being monitored, intercepted, and cracked during the transmission of video data, thereby more effectively realizing the secure transmission of video data.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a video security transmission method and system. Background Art

[0002] With the development of the times and the advancement of streaming network technology, video transmission is becoming more and more common in society, and all walks of life are using streaming transmission to varying degrees. However, traditional streaming protocols are not encrypted and are at risk of being monitored, intercepted or cracked.

[0003] In order to protect the privacy and security of video content, if the video data is not encrypted, the privacy and security of the user's audio and video data cannot be guaranteed. Especially in the process of large-scale video transmission, once it is monitored or intercepted, it will cause serious user data loss and give users a poor experience.

[0004] Therefore, it is necessary to provide a new video security transmission method and system to solve the above problems. Summary of the invention

[0005] The present invention aims to provide a video security transmission method and system to solve the risks of video transmission being monitored, intercepted or cracked in the prior art, the privacy and security of the user's audio and video image data cannot be guaranteed, and the technical problems such as further improving the secure transmission of video data are solved by the present invention. The technical problems to be solved by the present invention are achieved through the following technical solutions.

[0006] The first aspect of the present invention proposes a video security transmission method, which includes: slicing the audio data to be processed in units of GOP to obtain video slices to be sent; encrypting and encapsulating each video slice to be sent through a custom private transmission protocol, specifically including constructing header information according to the video data type and data length, calculating verification parameters, and multiple rounds of encryption processing; and sending the encrypted and encapsulated video slices to the receiving end.

[0007] The second aspect of the present invention proposes a video security transmission system, which is the video security transmission method described in the first aspect of the present invention, and the video security transmission system includes: a slicing processing module, which is used to slice the audio data to be processed in units of GOP to obtain video slices to be sent; an encryption and encapsulation processing module, which encrypts and encapsulates each video slice to be sent through a custom private transmission protocol, specifically including constructing header information according to the video data type and data length, calculating verification parameters, and multiple rounds of encryption processing; a sending module, which sends the encrypted and encapsulated video slices to the receiving end.

[0008] The third aspect of the present invention provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the video security transmission method described in the first aspect of the present invention.

[0009] A fourth aspect of the present invention provides a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the video security transmission method described in the first aspect of the present invention.

[0010] The embodiments of the present invention include the following advantages:

[0011] Compared with the prior art, the present invention specifically encrypts the video data in units of GOP, and encrypts and encapsulates each video slice to be sent through a custom private transmission protocol, specifically including constructing header information according to the video data type and data length, calculating verification parameters, and performing multiple rounds of encryption processing with randomly generated keys, and the randomly generated keys correspond to each GOP one by one; the encrypted and encapsulated video slices are sent to the receiving end, which effectively solves the risk of being monitored, intercepted, and cracked during the video data transmission process, thereby more effectively realizing the secure transmission of video data. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 It is a flow chart of the steps of the video security transmission method of the present invention;

[0013] Figure 2 is a schematic diagram of an application example of audio data to be processed in the video security transmission method of the present invention;

[0014] Figure 3 It is a schematic diagram of calculating the verification parameters of the video slice to be sent in the video security transmission method of the present invention;

[0015] Figure 4 It is a structural block diagram of the video security transmission system of the present invention;

[0016] Figure 5 is a schematic structural diagram of an electronic device embodiment according to the present invention;

[0017] Figure 6 It is a schematic diagram of the structure of a computer-readable medium embodiment according to the present invention. DETAILED DESCRIPTION

[0018] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0019] In view of the above problems, the present invention proposes a video security transmission method. The method slices the audio data to be processed in units of GOP to obtain video slices to be sent; encrypts and encapsulates each video slice to be sent through a custom private transmission protocol, specifically including constructing header information according to the video data type and data length, calculating verification parameters, and multiple rounds of encryption processing; and sends the encrypted and encapsulated video slices to the receiving end. Specifically, the video data is encrypted in units of GOP, and then encapsulated through a private protocol. The randomly generated key corresponds to each GOP one by one, which effectively solves the risk of being monitored, intercepted, and cracked during the video data transmission process, thereby more effectively realizing the secure transmission of video data.

[0020] Example 1

[0021] Refer to the following Figure 1 , Figure 2 , Figure 3 , the contents of the present invention will be described in detail.

[0022] Figure 1 It is a flow chart of the steps of the video security transmission method of the present invention.

[0023] like Figure 1 As shown, in step S101, the audio data to be processed is sliced ​​in units of GOP to obtain video slices to be sent.

[0024] In a specific implementation, the audio data to be processed is encoded in units of pictures, and the encoded binary pictures are called video frames, including I frames (key frames), P frames (predicted frames), B frames (bidirectionally predicted frames), and IDR frames (Instantaneous Decoding Refresh Frames).

[0025] Specifically, the audio data to be processed may be video data that needs to be securely transmitted for video conferencing, distance education, telemedicine, etc. However, it is not limited thereto, and may also be surveillance videos of a certain area, security surveillance videos, and other privacy video data that needs to be protected. In addition, it may also be live videos, on-demand videos, and other videos that need to protect content copyright and security.

[0026] A segment of audio data to be processed is sliced ​​into GOP units. Each GOP is an independent video frame sequence, specifically including one video frame, or multiple consecutive video frames.

[0027] Specifically, Figure 2The bar graph shown is a compressed audio data to be processed (specifically a video clip), which contains multiple video frames, where the first bar graph represents the current IDR frame, the middle bar graphs are P frames, and the last bar graph represents the next IDR frame.

[0028] It should be noted that GOP (Group of Pictures) is a concept in video coding, which represents a group of continuous image frames, starting from one IDR and ending at the next IDR. The above is only described as an optional example and cannot be understood as a limitation of the present invention.

[0029] Next, in step S102, each video slice to be sent is encrypted and encapsulated through a custom private transmission protocol, specifically including constructing header information according to the video data type and data length, calculating verification parameters, and performing multiple rounds of encryption processing.

[0030] Specifically, the data structure of the self-defined private transmission protocol includes a protocol header, a data load part, and a check calculation part. The self-defined private transmission protocol is used to encapsulate the audio data to be processed.

[0031] The protocol header is represented by Header, which contains basic information of the data, such as data type (for example, music, video, key, etc.), data length, data encryption status, etc.

[0032] By designing a concise and comprehensive header structure, the accuracy and completeness of the data information to be encapsulated are ensured.

[0033] The data payload portion is represented by Payload, and the data payload portion is used to carry actual music, video or key data, that is, to carry the segmented data to be sent.

[0034] For the verification calculation part, for example, a checksum (expressed as Checksum) is calculated for data integrity verification of the video slice to be sent, or verification of specified data in the video slice to be sent. The specific use of an efficient checksum algorithm ensures the integrity and accuracy of the data transmission process of the video slice to be sent.

[0035] Specifically, the combined calculation method is used to calculate the verification parameters of the video slice to be sent using the following expression. Figure 3 :

[0036] C(X) = CRC(X) + SHA(X) (1)

[0037] Among them, C(X) is the check value after combining all data blocks of the video slice to be sent; CRC(X) is the combination of CRC check values ​​corresponding to each data block in the video slice to be sent; SHA(X) is the combination of hash values ​​corresponding to each data block in the video slice to be sent.

[0038] The calculation of CRC (X) (i.e., the combination of CRC check values) specifically includes: first calculating the polynomial value, remainder value, and check value of the video slice to be sent. That is, CRC (X) = P (X) mod (x d ^64 + 1)<<64, where “<<” is a bit operation in computers, indicating left shift, and “<<64” means left shift 64 bits.

[0039] The following expression is used to calculate the polynomial value of all data blocks of the video slice to be sent.

[0040] P(X) = x1^64 + a_63x2^63 + ... + a_1x n + a_0 (2)

[0041] Where: P(X) is the polynomial value of all data blocks of the video slice to be sent, X represents all data blocks of the video slice to be sent, X= , d is a positive integer, represents the dth data block, n represents the number of data blocks of the video slice to be sent; a_63 to a_0 are polynomial coefficients corresponding to the data group values ​​of each data block.

[0042] The following expression is used to calculate the remainder value of all data blocks of the video slice to be sent.

[0043] R(X) = P(X) mod (x d ^64 + 1) (3)

[0044] Where R(X) is the remainder value of all data blocks of the video slice to be sent; P(X) is the polynomial value of all data blocks of the video slice to be sent, X represents all data blocks of the video slice to be sent, X= , d is a positive integer, represents the dth data block, n represents the number of data blocks of the video slice to be sent; x d ^64 + 1 represents the divisor of the dth data block of the video slice to be sent.

[0045] The following expression is used to calculate the check value corresponding to each data block of the video slice to be sent.

[0046] CRC(X) = R(X)<<64 (4)

[0047] Among them, CRC(X) is the combination of CRC check values ​​corresponding to each data block in the video slice to be sent; R(X) is the remainder value of all data blocks of the video slice to be sent; X is all data blocks of the video slice to be sent, X= , d is a positive integer, represents the dth data block, n represents the number of data blocks of the video slice to be sent; wherein, "<<" is a bit operation in the computer, representing left shift, and "<<64" represents left shift of 64 bits.

[0048] The following expression is used to calculate the hash value corresponding to each data block of the video slice to be sent.

[0049] SHA(X) =H(X) = (h_0 + h_1 + ... + h_i) mod 2^32 (5)

[0050] Among them, H(X) is the combination of hash values ​​corresponding to each data block in the video slice to be sent, that is, SHA(X); X is all the data blocks of the video slice to be sent, X= , d is a positive integer, represents the dth data block, n represents the number of data blocks of the video slice to be sent; h_0 to h_i are the components of the hash value of the dth data block of the video slice to be sent, i is a positive integer, and h_i is a hash function, which is as follows:

[0051] h_i = (h_{i-1} + (x_i \* 2^32) + (k_i \* 2^32)) mod 2^32 (6)

[0052] Wherein, h_i is the i-th component of the hash value of all data blocks of the video slice to be sent, and i is a positive integer; h_{i-1} is the i-1-th component of the hash value of all data blocks of the video slice to be sent; x_i is the i-th byte of the current data block of the video slice to be sent; k_i is a random constant value, specifically including a character string randomly generated using letters, numbers, underscores or other symbols, and a specified number. Optionally, the specified number is, for example, 80 to 150. For example, k_i = 0x5a827****999.

[0053] It should be noted that in the SHA-1 algorithm, the random constant value k_i is used to prevent collision attacks. A collision attack is an attack method in which an attacker tries to find two different input messages so that their hash values ​​are the same. The SHA-1 algorithm uses random constant values ​​to make the hash value more random, thereby improving the security of the video slice to be sent during the transmission process. The randomness and security of the hash value are ensured by adjusting the above-mentioned specified number. Theoretically, the more random constant values ​​there are, the higher the randomness and security of the hash value. However, the number of random constant values ​​will also affect the performance of the hash algorithm. The more random constant values ​​there are, the longer the calculation time of the hash algorithm. In order to ensure a long calculation time, the number of random constant values ​​is adaptively adjusted to 80 to 150. Preferably 80, 100 and 110. The above is only explained as an optional example and cannot be understood as a limitation of the present invention.

[0054] Specifically, according to the protocol header in the data structure of the custom private protocol, the header information is constructed according to the data type and data length of the video slice and key to be sent. Each video slice to be sent (ie, GOP data) is an independent video frame sequence, specifically including one video frame, or multiple consecutive video frames.

[0055] Next, the data payload part in the data structure of the custom private protocol may carry audio data and key data.

[0056] Each round of encryption processing of each video slice to be sent includes the following operations: byte substitution, row shift, column mixing and round key addition. Specifically, the aes-192 algorithm is used to perform the multiple rounds of encryption processing, specifically 8 to 15 rounds. Preferably, 12 or 13 rounds.

[0057] According to the data structure of the custom private protocol and the calculated verification parameters, the video slices to be sent after multiple rounds of encryption are encapsulated to obtain encrypted and encapsulated video slices.

[0058] The following encryption expression is used to perform multiple rounds of AES encryption on each video slice to be sent according to the randomly generated key:

[0059] Use the following expression to perform the byte replacement process (i.e. SubBytes):

[0060] S(z) = Sbox[z] (7)

[0061] Among them, S(z) represents the replacement value of the input byte of the current data block of the video slice to be sent; Sbox is a predefined replacement table configured in AES encryption, and z is the input byte of the current data block of the video slice to be sent.

[0062] Use the following expression for row shifting (ShiftRows):

[0063] R(z) = (z<<s) | (x d >>(8 - s)) (8)

[0064] Where R(z) represents the shift amount of the input byte of the current data block (this current data block belongs to x d ); z is the input byte of the current data block (this current data block belongs to x d ), s is the threshold of the shift amount of the input byte of the current data block (depending on the size of each data block in the AES encryption process). Here, "<< " is a bit operation in the computer, representing left shift, and z<<s means z is shifted left by s bits; ">> " is a bit operation in the computer, representing right shift, and x d >>8 - s means x d is shifted right by 8 - s bits; x d belongs to X, X is all data blocks of the video slice to be sent, X = , d is a positive integer, represents the d-th data block, and n represents the number of data blocks of the video slice to be sent.

[0065] Use the following expression for column mixing (MixColumns):

[0066] M(z) = (z<<1) ^ (z>>7) ^ (z<<4) ^ (z>>4) ^ (z<<2) ^ (z>>2) ^ (z<<1)^ (z>>1) (9)

[0067] Where M(z) represents the column mixing value of the input byte of the current data block, z is the input byte of the current data block (this current data block belongs to x d ), here, "<< " is a bit operation in the computer, representing left shift, and ">> " is a bit operation in the computer, representing right shift.

[0068] Use the following expression for the encryption round (AddRoundKey):

[0069] C(x d ) = S(x d ) ^ K(x d ) (10)

[0070] Where C(x d ) is the data group value after encryption processing of the d-th data block x d of the video slice to be sent in a certain encryption round; S(x d) is the dth data block x of the video slice to be sent in a certain encryption round d In the byte replacement process (i.e., SubBytes), the output after a certain round of encryption is K(x d ) is the dth data block x in a certain encryption round d Key Bytes, x d Belongs to X, X is all the data blocks of the video slice to be sent, X= , d is a positive integer, represents the dth data block, and n represents the number of data blocks of the video slice to be sent.

[0071] After the above multiple rounds of encryption processing, the encrypted video slices to be sent are obtained, which are expressed by the following expression:

[0072] C = E (K, P) (11)

[0073] Among them, C represents the encrypted video slice to be sent; K represents the key; and P represents the video slice to be sent.

[0074] Next, in the verification calculation part of the data structure of the custom private protocol, according to the above expressions (1) to (6), a verification parameter (such as a checksum) is calculated for each video slice to be sent and the constructed header information.

[0075] To further illustrate the calculation process of the verification parameters, the following is a sample code in C language:

[0076] / / CRC64 polynomial

[0077] #define CRC64_POLY 0xC96C5795D7870F42ULL

[0078] / / SHA-1 constant

[0079] #define SHA1_K0 0x5A827999

[0080] #define SHA1_K1 0x6ED9EBA1

[0081] #define SHA1_K2 0x8F1BBCDC

[0082] #define SHA1_K3 0xCA62C1D6;

[0083] / / CRC64 function

[0084] uint64_t crc64(const uint8_t *data, size_t len) {

[0085] uint64_t crc = 0;

[0086] for (size_t i = 0; i<len; i++) {

[0087] uint8_t byte = data[i];

[0088] crc = (crc>>8) ^ (byte ^ (crc&0xFF));

[0089] crc = (crc>>8) ^ (CRC64_POLY&(crc&0xFF));

[0090] }

[0091] return crc;

[0092] };

[0093] / / SHA-1 function

[0094] void sha1(const uint8_t *data, size_t len, uint8_t *digest) {

[0095] uint32_t h0, h1, h2, h3, h4;

[0096] uint32_t w

[80] ;

[0097] h0 = 0x67452301;

[0098] h1 = 0xEFCDAB89;

[0099] h2 = 0x98BADCFE;

[0100] h3 = 0x10325476;

[0101] h4 = 0xC3D2E1F0;

[0102] for (size_t i = 0; i<len; i += 64) {

[0103] for (size_t j = 0; j<16; j++) {

[0104] w[j] = ((uint32_t *)data)[j];

[0105] }

[0106] for (size_t j = 16; j<80; j++) {

[0107] w[j] = (w[j - 3]^ w[j - 8] ^ w[j - 14]^ w[j - 16])<<1;

[0108] }

[0109] uint32_t a, b, c, d, e;

[0110] a = h0;

[0111] b = h1;

[0112] c = h2;

[0113] d = h3;

[0114] e = h4;

[0115] for (size_t j = 0; j<80; j++) {

[0116] uint32_t f;

[0117] if (j<20) {

[0118] f = (b&c) | ((~b)&d);

[0119] f += SHA1_K0;

[0120] } else if (j<40) {

[0121] f = b ^ c ^ d;

[0122] f += SHA1_K1;

[0123] } else if (j<60) {

[0124] f = (b&c) | (b&d) | (c&d);

[0125] f += SHA1_K2;

[0126] } else {

[0127] f = b ^ c ^ d;

[0128] f += SHA1_K3;

[0129] }

[0130] a = (a<<5) | (a>>27);

[0131] e += f + w[j];

[0132] b = c;

[0133] c = d;

[0134] d = e;

[0135] e = a;

[0136] }

[0137] h0 += a;

[0138] h1 += b;

[0139] h2 += c;

[0140] h3 += d;

[0141] h4 += e;

[0142] }

[0143] digest[0] = (h0>>24)&0xFF;

[0144] digest[1] = (h0>>16)&0xFF;

[0145] digest[2] = (h0>>8)&0xFF;

[0146] digest[3] = h0&0xFF;

[0147] digest[4] = (h1>>24)&0xFF;

[0148] digest[5] = (h1>>16)&0xFF;

[0149] digest[6] = (h1>>8)&0xFF;

[0150] digest[7] = h1&0xFF;

[0151] digest[8] = (h2>>24)&0xFF;

[0152] digest[9] = (h2>>16)&0xFF;

[0153] digest

[10] = (h2>>8)&0xFF;

[0154] digest

[11] = h2&0xFF;

[0155] digest

[12] = (h3>>24)&0xFF;

[0156] digest

[13] = (h3>>16)&0xFF;

[0157] digest

[14] = (h3>>8)&0xFF;

[0158] digest

[15] = h3&0xFF;

[0159] digest

[16] = (h4>>24)&0xFF;

[0160] digest

[17] = (h4>>16)&0xFF;

[0161] digest

[18] = (h4>>8)&0xFF;

[0162] digest

[19] = h4&0xFF;

[0163] };

[0164] / / CRC64 combined with SHA-1 function

[0165] void crc64_sha1(const uint8_t *data, size_t len, uint8_t *digest) {

[0166] uint64_t crc = crc64(data, len);

[0167] sha1(data, len, digest);

[0168] / / Append the CRC64 value to the SHA-1 hash value

[0169] digest

[20] = (crc>>56)&0xFF;

[0170] digest

[21] = (crc>>48)&0xFF;

[0171] digest

[22] = (crc>>40)&0xFF;

[0172] digest

[23] = (crc>>32)&0xFF;

[0173] digest

[24] = (crc>>24)&0xFF;

[0174] digest

[25] = (crc>>16)&0xFF;

[0175] digest

[26] = (crc>>8)&0xFF;

[0176] digest

[27] = crc&0xFF;

[0177] }.

[0178] In a specific application example, it specifically includes a sending end, a receiving end capable of performing data transmission with the sending end, and a key management service end capable of performing data transmission with the sending end and the receiving end. The key management service end corresponds to a key management server.

[0179] Specifically, the key management server provides key management services, including random key generation, association between a key and a unique key identifier, key rotation, and key distribution.

[0180] Optionally, a strong random number generator is used to generate a key, and each video slice to be sent corresponds to a randomly generated key, thereby ensuring the randomness and unpredictability of the key.

[0181] The key management service distributes keys from the key server to the sender and receiver through a secure method (such as TLS).

[0182] Additionally, randomly generated keys are stored encrypted and physically and logically protected using a Hardware Security Module (HSM).

[0183] Optionally, the key management service includes regular key replacement, which can reduce the risk of key leakage.

[0184] Preferably, each key is associated with a unique key ID for identifying the key used in data transmission using a private protocol.

[0185] It should be noted that the above is only described as an optional example and should not be understood as a limitation to the present invention.

[0186] Next, in step S103, the encrypted and encapsulated video slices are sent to the receiving end.

[0187] Specifically, when the receiving end receives the video slice from the sending end, the following steps are performed:

[0188] Step S201: parsing the header information in the encrypted and encapsulated video slice.

[0189] Read the received data type according to the protocol and obtain the payload data length and check parameters

[0190] Step S202: Perform verification calculation of verification parameters.

[0191] Check whether the load calculation is successful, mainly to verify correctness and completeness

[0192] Step S203: Decrypt the data according to the parsed header information and the verification calculation result.

[0193] Specifically, the decryption process includes:

[0194] The decryption process can be divided into the following steps:

[0195] Reverse shift steps (i.e. InvShiftRows);

[0196] Inverse byte replacement step (i.e. InvSubBytes);

[0197] Inverse column mixing step (i.e. InvMixColumns);

[0198] Inverse encryption round step (i.e. InvAddRoundKey).

[0199] Below is a detailed description of each step and the formulas used:

[0200] For the retrograde shift step, the following expression is used, which represents the retrograde shift:

[0201] R^{-1}(x d ) = (x d >>s) | (x d <<(8-s)) (12)

[0202] Where R^{-1}(z) represents the data block x d The data block obtained after reverse shift, x d Belongs to X, X is all the data blocks of the video slice to be sent, X= , d is a positive integer, represents the dth data block, n represents the number of data blocks of the video slice to be sent; "<<" is a bit operation in the computer, indicating left shift, ">>" is a bit operation in the computer, indicating right shift, x d >>s represents data block x d Shift right by s bits, x d <<(8-s) indicates data block xd Shift left by 8-s bits, where s is the data block x d The threshold for the amount of shifting of the input bytes (depending on the block size of the AES encryption process).

[0203] For the inverse byte replacement step, the following expression is used to represent the inverse byte replacement:

[0204] S^{-1}(x d ) = Sbox^{-1}[x d ] (13)

[0205] Among them, S^{-1}(x d ) represents the output data block obtained by performing inverse byte replacement on the input data block xd, x d Belongs to X, X is all the data blocks of the video slice to be sent, X= , d is a positive integer, represents the dth data block, n represents the number of data blocks of the video slice to be sent; Sbox^{-1} is a predefined substitution table in AES decryption.

[0206] For the reverse column confusion step, the following expression is used to represent the reverse column confusion:

[0207] M^{-1}(x d ) = (x d >>1) ^ (x d <<7) ^ (x d >>4) ^ (x d <<4) ^ (x d >>2) ^ (x d <<2)^ (x d >>1) ^ (x d <<1) (14)

[0208] Among them, M^{-1}(x d ) represents data block x d The data block obtained after reverse column confusion, x d Belongs to X, X is all the data blocks of the video slice to be sent, X= , d is a positive integer, represents the dth data block, n represents the number of data blocks of the video slice to be sent; "<<" is a bit operation in the computer, indicating left shift, and ">>" is a bit operation in the computer, indicating right shift.

[0209] For the inverse encryption round step, the following expression is used to represent the inverse encryption round:

[0210] P(x d) = S^{-1}(x d ) ^ K(x d )

[0211] Among them, P(x d ) represents the data block S^{-1}(x d ) and the decryption round key K(x d ) performs an XOR operation to obtain the decrypted data block P(x d ).

[0212] It should be noted that x d Represents the index of the data block, S^{-1} represents the inverse byte substitution table, K represents the decryption round key, R^{-1} represents the reverse row shift, and M^{-1} represents the reverse column confusion.

[0213] The decryption process of AES-192 needs to repeat the above steps multiple times, using different round keys and rounds each time. Finally, the decrypted data block P(x d ).

[0214] Specifically, let the AES decryption function be D, then P = D (K + C), where C is the encrypted and encapsulated video slice, K is the key, and P is the decrypted video data, that is, the decrypted data block P (x d ). For example, if the encrypted and encapsulated video slice C and the key K are input as parameters of the decryption function, the decryption function will output the decrypted video data P.

[0215] In this example, the randomly generated key is sent to the sending end and the receiving end, and the key is encrypted and stored.

[0216] Preferably, the randomly generated key type, the data type and the data length of the video slice to be sent construct the following extended content of the header information: encryption status, reserved field length.

[0217] After decryption, use a customized player to pull the stream for playback. First obtain the corresponding key, then obtain the encrypted GOP data, and play it after decryption.

[0218] It should be noted that the above is only described as an optional example and should not be understood as a limitation to the present invention.

[0219] In addition, the drawings are only schematic illustrations of the processes included in the method according to an exemplary embodiment of the present invention, and are not intended to be limiting. It is easy to understand that the processes shown in the drawings do not indicate or limit the time sequence of these processes. In addition, it is also easy to understand that these processes can be performed synchronously or asynchronously, for example, in multiple modules.

[0220] Compared with the prior art, the present invention specifically encrypts the video data in units of GOP, and encrypts and encapsulates each video slice to be sent through a custom private transmission protocol, specifically including constructing header information according to the video data type and data length, calculating verification parameters, and performing multiple rounds of encryption processing with randomly generated keys, and the randomly generated keys correspond to each GOP one by one; the encrypted and encapsulated video slices are sent to the receiving end, which effectively solves the risks of being monitored, intercepted, and cracked, and thus more effectively realizes the secure transmission of video data.

[0221] Example 2

[0222] The following is a system embodiment of the present invention, which can be used to implement the method embodiment of the present invention. For details not disclosed in the system embodiment of the present invention, please refer to the method embodiment of the present invention.

[0223] Figure 4 4 is a schematic structural diagram of an example of a video security transmission system according to the present invention.

[0224] A second aspect of the present disclosure provides a video security transmission system 400, which adopts the video security transmission method described in the first aspect of the present disclosure.

[0225] Reference Figure 4 The video security transmission system 400 includes a slicing processing module 410, an encryption encapsulation processing module 420, and a sending module 430.

[0226] In a specific implementation, the slice processing module 410 is used to slice the audio data to be processed in units of GOP to obtain video slices to be sent. The encryption and encapsulation processing module 420 performs encryption and encapsulation processing on each video slice to be sent through a custom private transmission protocol, specifically including constructing header information according to the video data type and data length, calculating verification parameters, and multiple rounds of encryption processing. The sending module 430 sends the encrypted and encapsulated video slices to the receiving end.

[0227] According to an optional implementation, the encryption and encapsulation processing of each video slice to be sent is performed through a custom private transmission protocol, including: constructing header information according to the protocol header in the data structure of the custom private protocol, specifically according to the data type and data length of the video slice to be sent and the key, and each video slice to be sent is an independent video frame sequence, specifically including one video frame, or multiple consecutive video frames.

[0228] The data payload part in the data structure of the custom private protocol can carry audio data and key data.

[0229] According to an optional implementation, the video compression processing method includes: verifying the calculation part in the data structure of the custom private protocol, and using a cyclic redundancy check combined with a hash algorithm to calculate a verification parameter to ensure the integrity and security of the data transmission process.

[0230] C(X) = CRC(X) + SHA(X)

[0231] Where C(X) is the checksum of all data blocks of the video slice to be sent; CRC(X) is the combination of the CRC checksum values ​​corresponding to each data block in the video slice to be sent, CRC(X)=P(X) mod (x d ^64 + 1)<<64, P(X) is the polynomial value of all data blocks of the video slice to be sent, X represents all data blocks of the video slice to be sent, X= , d is a positive integer, represents the dth data block, n represents the number of data blocks of the video slice to be sent; "<<" is a bit operation in the computer, indicating a left shift, and "<<64" represents a left shift of 64 bits; SHA(X) is a combination of hash values ​​corresponding to each data block in the video slice to be sent; wherein, the calculation of CRC(X) specifically includes: first calculating the polynomial value, remainder value, and check value of the video slice to be sent.

[0232] According to an optional implementation manner, it further includes: using the following encryption expression, according to the randomly generated key, performing multiple rounds of encryption processing on each video slice to be sent, each round of encryption processing includes using a combined calculation method, using the following expression, to calculate the verification parameter of the video slice to be sent:

[0233] According to an optional implementation manner, the following expression is used to calculate the hash value corresponding to each data block of the video slice to be sent:

[0234] SHA(X) =H(X) = (h_0 + h_1 + ... + h_i) mod 2^32

[0235] Among them, H(X) is the combination of hash values ​​corresponding to each data block in the video slice to be sent, that is, SHA(X); X represents all data blocks of the video slice to be sent, X= , d is a positive integer, represents the dth data block, n represents the number of data blocks of the video slice to be sent; h_0 to h_i are the components of the hash value of the dth data block of the video slice to be sent, i is a positive integer, and h_i is a hash function, which is as follows:

[0236] h_i = (h_{i-1} + (x_i \* 2^32) + (k_i \* 2^32)) mod 2^32

[0237] Among them, h_i is the i-th component of the hash value of all data blocks of the video slice to be sent, and i is a positive integer; h_{i-1} is the i-1-th component of the hash value of all data blocks of the video slice to be sent; x_i is the i-th byte of the current data block of the video slice to be sent; k_i is a random constant value, specifically including randomly generating a specified number of strings using letters, numbers, underscores or other symbols.

[0238] According to an optional implementation, a key management service is provided, specifically including random key generation, association between a key and a unique key identifier, key rotation, and key distribution.

[0239] When the randomly generated key is sent to the sender and receiver, the key is encrypted and stored.

[0240] According to an optional implementation manner, when the receiving end receives the video slice from the sending end, the following steps are performed:

[0241] Parse the header information in the encrypted and encapsulated video slices;

[0242] Perform verification calculations of verification parameters;

[0243] Data decryption is performed based on the parsed header information and verification calculation results.

[0244] According to an optional implementation, the construction of header information based on the video data type and data length further includes: randomly generated key type, data type and data length of the video slice to be sent, and construction of the following extended content in the header information: encryption status, reserved field length.

[0245] According to an optional implementation method, a customized player is used to pull the stream for playback, first obtain the corresponding key, then obtain the encrypted GOP data, and play it after decryption.

[0246] It should be noted that the video security transmission method executed by the video security transmission system in this embodiment is substantially the same as the video security transmission method in Embodiment 1, and therefore, the description of the same parts is omitted.

[0247] Compared with the prior art, the present invention specifically encrypts the video data in units of GOP, and encrypts and encapsulates each video slice to be sent through a custom private transmission protocol, specifically including constructing header information according to the video data type and data length, calculating verification parameters, and performing multiple rounds of encryption processing with randomly generated keys, and the randomly generated keys correspond to each GOP one by one; the encrypted and encapsulated video slices are sent to the receiving end, which effectively solves the risks of being monitored, intercepted, and cracked, and thus more effectively realizes the secure transmission of video data.

[0248] Figure 5 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.

[0249] like Figure 5 As shown, the electronic device is presented in the form of a general computing device. The processor may be one or more and work in coordination. The present invention does not exclude distributed processing, that is, the processor may be dispersed in different physical devices. The electronic device of the present invention is not limited to a single entity, but may also be the sum of multiple physical devices.

[0250] The memory stores a computer executable program, which is usually a machine-readable code. The computer-readable program can be executed by the processor to enable the electronic device to perform the method of the present invention, or at least part of the steps in the method.

[0251] The memory includes a volatile memory, such as a random access memory unit (RAM) and / or a cache memory unit, and may also be a non-volatile memory, such as a read-only memory unit (ROM).

[0252] Optionally, in this embodiment, the electronic device further includes an I / O interface, which is used for the electronic device to exchange data with an external device. The I / O interface can represent one or more of several types of bus structures, including a storage unit bus or a storage unit controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of a variety of bus structures.

[0253] It should be understood that Figure 5 The electronic device shown is only an example of the present invention, and the electronic device of the present invention may also include elements or components not shown in the above examples. For example, some electronic devices also include display units such as display screens, and some electronic devices also include human-computer interaction elements such as buttons, keyboards, etc. As long as the electronic device can execute the computer-readable program in the memory to implement the method of the present invention or at least part of the steps of the method, it can be considered as an electronic device covered by the present invention.

[0254] Through the above description of the implementation, it is easy for those skilled in the art to understand that the example implementation described here can be implemented by software, or by combining software with necessary hardware. Figure 6 As shown, the technical solution according to the embodiment of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes a number of commands to enable a computing device (which can be a personal computer, a server, or a network device, etc.) to execute the above method according to the embodiment of the present invention.

[0255] The software product may be any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0256] The computer readable storage medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The readable storage medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with a command execution system, device, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the above.

[0257] Program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0258] The computer-readable medium carries one or more programs (eg, computer-executable programs). When the one or more programs are executed by a device, the computer-readable medium implements the method of the present disclosure.

[0259] Those skilled in the art will appreciate that the above modules can be distributed in the device according to the description of the embodiment, or can be changed accordingly and only used in one or more devices different from the embodiment. The modules of the above embodiments can be combined into one module, or further divided into multiple sub-modules.

[0260] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the exemplary embodiments described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the embodiment of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several commands to enable a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiment of the present invention.

[0261] The exemplary embodiments of the present invention are specifically shown and described above. It should be understood that the present invention is not limited to the detailed structure, configuration or implementation method described herein; on the contrary, the present invention is intended to cover various modifications and equivalent configurations included in the spirit and scope of the appended claims.

Claims

1. A video security transmission method, characterized in that: The video security transmission method comprises: Slice the audio data to be processed in units of GOP to obtain video slices to be sent; Each video slice to be sent is encrypted and encapsulated through a custom private transmission protocol, which includes constructing header information according to the video data type and data length, calculating verification parameters, and performing multiple rounds of encryption processing; The encrypted and encapsulated video slices are sent to the receiving end, where: According to the protocol header in the data structure of the custom private protocol, the header information is constructed according to the data type and data length of the video slice and the key to be sent. Each video slice to be sent is an independent video frame sequence, specifically including one video frame, or multiple consecutive video frames; The data payload part in the data structure of the custom private protocol can carry audio data and key data; The following encryption expression is used to perform multiple rounds of encryption processing on each video slice to be sent according to the randomly generated key. Each round of encryption processing includes using a combined calculation method to calculate the verification parameters of the video slice to be sent using the following expression: C(X) = CRC(X) + SHA(X) Where C(X) is the checksum of all data blocks of the video slice to be sent; CRC(X) is the combination of the CRC checksum values ​​corresponding to each data block in the video slice to be sent, CRC(X)=P(X) mod (x d ^64 + 1) << 64, P(X) is the polynomial value of all data blocks of the video slice to be sent, X represents all data blocks of the video slice to be sent, X= , d is a positive integer, x d represents the dth data block, n represents the number of data blocks of the video slice to be sent; "<<" is a bit operation in the computer, indicating a left shift, and " << 64" represents a 64-bit left shift; SHA(X) is a combination of hash values ​​corresponding to each data block in the video slice to be sent; wherein, the calculation of CRC(X) specifically includes: first calculating the polynomial value, remainder value, and check value of the video slice to be sent; The following expression is used to calculate the hash value corresponding to each data block of the video slice to be sent: SHA(X) =H(X) = (h_0 + h_1 + ... + h_i) mod 2^32 Among them, H(X) is the combination of hash values ​​corresponding to each data block in the video slice to be sent, that is, SHA(X); X represents all data blocks of the video slice to be sent, X= , d is a positive integer, x d represents the dth data block, n represents the number of data blocks of the video slice to be sent; h_0 to h_i are the components of the hash value of the dth data block of the video slice to be sent, i is a positive integer, and h_i is a hash function, which is as follows: h_i = (h_{i-1} + (x_i \* 2^32) + (k_i \* 2^32)) mod 2^32 Wherein, h_i is the i-th component of the hash value of all data blocks of the video slice to be sent, and i is a positive integer; h_{i-1} is the i-1-th component of the hash value of all data blocks of the video slice to be sent; x_i is the i-th byte of the current data block of the video slice to be sent; k_i is a random constant value, specifically including a character string of a specified number randomly generated using letters, numbers, underscores or other symbols; When the receiving end receives the video slice from the sending end, it performs the following steps: Parse the header information in the encrypted and encapsulated video slices; Perform verification calculations of verification parameters; Data decryption is performed based on the parsed header information and verification calculation results.

2. The video security transmission method according to claim 1, characterized in that: Video compression processing methods include: In the verification calculation part of the data structure of the custom private protocol, a cyclic redundancy check is used in combination with a hash algorithm to calculate a verification parameter to ensure the integrity and security of the data transmission process.

3. The video security transmission method according to claim 1, characterized in that: Provide key management services, including random key generation, association between keys and unique key identifiers, key rotation, and key distribution; When the randomly generated key is sent to the sender and receiver, the key is encrypted and stored.

4. The video security transmission method according to claim 1, characterized in that: The step of constructing header information according to the video data type and data length further includes: The randomly generated key type, the data type and data length of the video slice to be sent are used to construct the following extended content in the header information: encryption status and reserved field length.

5. The video security transmission method according to claim 3, characterized in that: Further including: Use a customized player to pull the stream for playback. First obtain the corresponding key, then obtain the encrypted GOP data, and play it after decryption.

6. A video security transmission system, characterized in that: It implements the video security transmission method according to any one of claims 1 to 5, and the video security transmission system comprises: The slice processing module is used to slice the audio data to be processed in units of GOP to obtain video slices to be sent; The encryption and encapsulation processing module encrypts and encapsulates each video slice to be sent through a custom private transmission protocol, including constructing header information according to the video data type and data length, calculating verification parameters, and performing multiple rounds of encryption processing; The sending module sends the encrypted and encapsulated video slices to the receiving end.

Images