A video encryption and decryption method based on vehicle-mounted storage system
By identifying and encrypting the I-frame start position in the H.264 naked stream video file in the on-board storage system and AES encrypting the offset list, the problem of quickly encrypting and decrypting real-time video data under limited resources is solved, and data security and real-timeness are achieved.
Patent Information
- Application Number
- CN202411508002.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-28
- Publication Date
- 2025-03-07
- Estimated Expiration
- 2044-10-28
AI Technical Summary
In an on-board storage system, how to quickly encrypt real-time video data under limited resources and perform lossless decryption when it needs to be viewed, especially in high-speed mobile scenarios.
By identifying the location of each I-frame start NALU in the H.264 naked stream video file, encrypting the first several consecutive bytes, hiding the I-frame start position, and AES encrypting the encrypted offset list and adding it to the end of the file.
It realizes the rapid encryption and decryption of video data in vehicle-mounted scenarios with limited resources and high-speed changes in video data, ensuring the security and real-timeness of the data.
Smart Images

Figure CN119031190B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present invention relate to the technical field of vehicle-mounted video images, and in particular to a video encryption and decryption method based on a vehicle-mounted storage system. Background Art
[0002] The on-board storage system of an autonomous vehicle can safely store the H.264 raw video data collected by the camera during the autonomous driving process so that it can be retrieved and viewed when determining the responsibility of a traffic accident. In order to ensure the security, reliability and integrity of the video data, it is essential to encrypt and decrypt the on-board video data.
[0003] However, the vehicle storage system is subject to the limited vehicle space. Usually, the volume should not be too large, the components should not be too many, and the system's memory resources and CPU resources are relatively limited. In the scenario of high-speed vehicle movement, the video data changes very quickly, and the real-time requirements for encryption and decryption are very high. How to quickly encrypt real-time video data with limited resources and perform lossless decryption when it needs to be viewed is an urgent problem to be solved. Summary of the invention
[0004] The embodiment of the present invention provides a video encryption and decryption method based on a vehicle-mounted storage system to solve the above technical problems.
[0005] In a first aspect, an embodiment of the present invention provides a video encryption method based on a vehicle-mounted storage system, comprising:
[0006] Get the vehicle-mounted raw video stream file to be encrypted;
[0007] According to the NAL synchronization header and the NAL type field, the position of the starting NALU of each I frame in the vehicle-mounted bare stream video file is identified;
[0008] Encrypt the first several consecutive bytes of the start NALU of each I frame to hide the position of the start NALU of each I frame, wherein the first several consecutive bytes cover the NAL synchronization header, NAL type field, and part of the image data of the start NALU of each I frame;
[0009] Encrypt the position offset of the starting NALU of each I frame, add the NAL synchronization header and the NAL type field before the encrypted data, and together form a NALU of a custom type, wherein the custom type is identified by an unused value in the NAL type field;
[0010] The NALU of the custom type is added to the end of the encrypted vehicle-mounted bare stream video file to obtain a complete vehicle-mounted encrypted video file.
[0011] In a second aspect, an embodiment of the present invention provides a video decryption method based on a vehicle-mounted storage system, comprising:
[0012] Obtaining a vehicle-mounted encrypted video file to be decrypted, wherein the first several consecutive bytes of each I-frame start NALU in the vehicle-mounted encrypted video file are encrypted, and the first several consecutive bytes cover the NAL synchronization header, NAL type field, and part of the image data of each I-frame start NALU, resulting in the inability to identify the position of each I-frame start NALU;
[0013] According to the NAL synchronization header, identifying the NALU at the end of the vehicle-mounted encrypted video file;
[0014] If the value of the NAL type field in the tail NALU represents an agreed custom type, decrypt the data after the NAL type field to obtain the position offset of the starting NALU of each I frame in the vehicle-mounted encrypted video file;
[0015] Several consecutive bytes starting from each offset are decrypted respectively to restore the first several consecutive bytes of the start NALU of each I frame.
[0016] In a third aspect, an embodiment of the present invention further provides a vehicle-mounted storage system, comprising: an encryption module, a storage module and a decryption module;
[0017] The encryption module is used to obtain a vehicle-mounted bare stream video file to be encrypted; according to the NAL synchronization header and the NAL type field, the position of each I-frame starting NALU in the vehicle-mounted bare stream video file is identified; the first several consecutive bytes of each I-frame starting NALU are encrypted to hide the position of each I-frame starting NALU, wherein the first several consecutive bytes cover the NAL synchronization header, the NAL type field, and part of the image data of each I-frame starting NALU; the position offset of each I-frame starting NALU is encrypted, and the NAL synchronization header and the NAL type field are added before the encrypted data to jointly constitute a NALU of a custom type, wherein the custom type is identified by an unused value in the NAL type field; the NALU of the custom type is added to the end of the encrypted vehicle-mounted bare stream video file to obtain a complete vehicle-mounted encrypted video file and store it in the storage module;
[0018] The decryption module is used to obtain the vehicle-mounted encrypted video file in the storage module; identify the NALU at the end of the vehicle-mounted encrypted video file according to the NAL synchronization header; if the value of the NAL type field in the NALU represents an agreed custom type, decrypt the data after the NAL type field to obtain the position offset of the starting NALU of each I frame in the vehicle-mounted encrypted video file; and decrypt several consecutive bytes starting from each offset to restore the first several consecutive bytes of the starting NALU of each I frame.
[0019] In summary, the embodiment of the present invention provides a video encryption and decryption method based on a vehicle storage system. When encrypting, first find the position of the starting NAL of all I frames in the H.264 raw stream file, encrypt the first several consecutive bytes of the NAL of each I frame, and record the offset of this position (encrypted position) in the file into a list. When the entire file is encrypted, the offset list data is encrypted by AES, and the ciphertext of the offset list plus the data structure formed by the NAL synchronization header and the NAL type are saved at the end of the file. When getting the encrypted file for decryption, first find the NAL data structure of the offset, decrypt it to obtain the plaintext of the offset list, and then decrypt the first several consecutive bytes of the NAL of each key frame I frame according to the offset list. The decrypted plaintext replaces the ciphertext of the original position, and then performs related operations such as decoding.
[0020] In particular, several consecutive bytes encrypted in this embodiment include the NAL synchronization header of the I frame start NALU, the NAL type, and part of the I frame image data, which can hide the position of the I frame and part of the image content. After the I frame disappears, the P frame needs the I frame to decode, so the P frame cannot be decoded. This embodiment uses a small amount of encrypted bytes to make all video images undecodable, which is particularly suitable for vehicle-mounted scenarios with limited resources, but high-speed changes in video data and extremely high real-time requirements. BRIEF DESCRIPTION OF THE DRAWINGS
[0021] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0022] Figure 1 It is a schematic diagram of the data structure of an H.264 raw stream video provided by an embodiment of the present invention;
[0023] Figure 2 It is a data structure diagram of a NALU provided by an embodiment of the present invention;
[0024] Figure 3 is a flow chart of a video encryption method based on a vehicle-mounted storage system provided by an embodiment of the present invention;
[0025] Figure 4 Schematic diagram of the position of the starting NALU of each I frame in a video file provided by an embodiment of the present invention;
[0026] Figure 5is a schematic diagram of the first 32 bytes of an I frame including a NAL synchronization header provided by an embodiment of the present invention;
[0027] Figure 6 yes Figure 5 The original position diagram of the 32 bytes in the vehicle-mounted raw stream video file is shown;
[0028] Figure 7 yes Figure 6 The schematic diagram of the video data after the 32 bytes shown are replaced with ciphertext;
[0029] Figure 8 Schematic diagram of a vehicle-mounted bare stream video file after the I frame disappears provided by an embodiment of the present invention
[0030] Fig. 9 is a schematic diagram of video data before and after encryption provided by an embodiment of the present invention;
[0031] Fig.10 is a flow chart of a video decryption method based on a vehicle-mounted storage system provided by an embodiment of the present invention;
[0032] Fig.11 It is a structural schematic diagram of a video encryption system based on a vehicle-mounted storage system provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0033] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be described clearly and completely below. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work belong to the scope of protection of the present invention.
[0034] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.
[0035] In the description of the present invention, it is also necessary to explain that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.
[0036] The embodiment of the present invention provides a video encryption and decryption method based on a vehicle-mounted storage system, which is applicable to the case of encrypting and decrypting H.264 raw stream video data collected by a vehicle-mounted camera. In order to illustrate these methods, the data structure of H.264 raw stream video is first introduced. Specifically, Figure 1 As shown in the figure, in H.264 raw video, images are organized in GOP (Group of Picture, sequence). One GOP is a data stream of image encoding, starting with SPS (Sequence Parameter Set) and ending with the next SPS. The first image of a GOP is called IDR (Instantaneous Decoder Refresh) image. IDR images are all I-frame images, which include complete image content. There are also multiple P-frame images stored after the I-frame image. The P-frame image does not include complete image content, but only includes the difference information between itself and the I-frame image in the same GOP. Therefore, the decoding of the P-frame image requires the help of the I-frame image.
[0037] Furthermore, the smallest unit of H.264 raw video data is NALU (Network Abstract Layer Unit), and SPS, PPS (Picture Parameter Set), IDR, B, and P information are all carried in NALU. Figure 2As shown, the data structure of NALU includes a NAL (Network Abstract Layer) synchronization header, a NAL type field, and a data part. Among them, the NAL synchronization header identifies the starting position of a NALU through a specific value (00000001H, a hexadecimal number, where each two digits represent a byte). That is, if 00000001 is identified in the raw video file, it means that the current and subsequent data are a NALU. The NAL type field is after the NAL synchronization header and includes 2 bytes. Different values can be used to identify the data content stored in the subsequent data part. For example, when the NAL type field value is 7, it indicates that the data part of the current NALU stores SPS; when the NAL type field value is 8, it indicates that the data part of the current NALU stores PPS; when the NAL type field value is 5, it indicates that the data part of the current NALU stores I-frame images. In other words, the NALU where SPS, PPS, and I-frames are located can be identified through the NAL synchronization header and the NAL type field.
[0038] Based on the above data structure, Figure 3 1 is a flow chart of a video encryption method based on a vehicle storage system provided by an embodiment of the present invention. The method is applicable to the case where a raw video file is securely stored in a vehicle storage system, and can be executed by a processing chip or encryption module in the vehicle storage system. Figure 3 As shown, the method specifically includes:
[0039] S110: Obtain the vehicle-mounted raw video stream file to be encrypted.
[0040] This step obtains the traffic video collected by the vehicle-mounted camera. The video is H.264 raw video data, and the file storing the data is called a raw stream video file.
[0041] S120: Identify the position of the starting NALU of each I frame in the vehicle-mounted bare stream video file according to the NAL synchronization header and the NAL type field.
[0042] An I frame includes at least one NALU. This step finds the starting NAL of all I frames in the H.264 raw stream file (i.e., the first NAL in the I frame) according to the data structure of the H.264 raw stream video data. Specifically, first, all NAL synchronization headers in the vehicle-mounted raw stream video file can be identified, and then the NAL type field after each NAL synchronization header can be read; if the value of a NAL type field represents the starting NALU of an I frame (the first NALU with a value of 5), then the NALU where the field is located is the starting NALU of an I frame, and the starting position of the NAL synchronization header is the position of the starting NALU of the I frame. Figure 4The position of the start NALU of each I frame located in a video file (referred to as I frame position) is exemplarily displayed.
[0043] S130, encrypting the first several consecutive bytes of the NALU starting from each I frame to hide the position of the NALU starting from each I frame, wherein the first several consecutive bytes cover the NAL synchronization header, the NAL type field, and part of the image data of the NALU starting from each I frame.
[0044] This step will partially encrypt the starting NALU of each I frame. The encrypted object includes the NAL synchronization header and the NAL type field. By encrypting them, the position of the starting NALU of each I frame can be hidden, resulting in the inability to locate the I frame, read the I frame image, and decode the P frame image. The encrypted object also includes part of the content of the I frame image. Compared with simply performing parameters other than the image, this embodiment also encrypts part of the image data, which not only ensures the security of the image data, but also takes into account the limited resources and high real-time requirements in the vehicle storage system.
[0045] Optionally, for the starting NALU of any I frame, after encrypting the first several consecutive bytes of the NALU, the number of bytes of the ciphertext and the original plaintext are the same; the encrypted ciphertext can be used to replace the original plaintext to obtain the encrypted I frame starting NALU. That is, the ciphertext is stored in the position of the original file, which does not affect the number of bytes of the original plaintext.
[0046] In a specific implementation, the number of the plurality of consecutive bytes is 32 bytes, which completely covers key header information such as the NAL synchronization header and the NAL type field, and also covers a portion of the image data. Figure 5 The following table shows the 32 bytes in an I frame, including the NAL synchronization header (referred to as the NAL header). Its original position in the file is as follows: Figure 6 As shown in the red box in the figure, after the 32 bytes are encrypted by AES (Advanced Encryption Standard), the ciphertext is saved in the original location of the file, and the result is as follows Figure 7 The video data shown in the figure has no NAL synchronization header at this time, and the starting NALU of the I frame cannot be identified. The P frame needs the I frame to be decoded, so the P frame cannot be decoded. The file after the I frame disappears is as follows Figure 8 and Fig. 9 As shown in the figure, AES is a symmetric encryption algorithm with the advantage of fast encryption speed and the AES key must be saved separately.
[0047] It should be noted that Figure 5 , Figure 6 and Figure 7 The blue background part in the image represents the bytes included in the currently viewed I frame. Figure 5 and Figure 7 When a frame is selected in the upper window, the bytes corresponding to the frame in the lower hex viewer window are automatically displayed with a blue background. Figure 6 This is an enlarged view of the hex viewer window. Due to space limitations, the bytes of the selected I frame are not fully displayed in the figure, but the starting position of the frame can still be seen from the blue background.
[0048] S140, encrypting the position offset of the starting NALU of each I frame, adding a NAL synchronization header and a NAL type field before the encrypted data, together forming a NALU of a custom type, wherein the custom type is identified by an unused value in the NAL type field.
[0049] After the NALU is encrypted, the position offset of each hidden I-frame starting NALU needs to be recorded additionally for decryption. Optionally, each position offset can be stored in an offset list, and the list is encrypted using the AES method. In order to match the data structure of the bare stream video file and avoid additional construction of complex protocols for reading offset information during decryption, this embodiment customizes a new NALU data structure through unused values in the NAL type field for storing the encrypted offset list.
[0050] In a specific implementation, the custom data structure is shown in Table 1, wherein the synchronization header is the NAL synchronization header, the NAL type field adopts the unused reserved type adopted by H264, the length field is used to record the number of bytes occupied by the following offset data, and the offset data part is used to store the encrypted offset list, wherein the length field and the offset data part are both the data part in the NALU.
[0051] Table 1
[0052]
[0053] S150: Add the NALU of the custom type to the end of the encrypted vehicle-mounted bare stream video file to obtain a complete vehicle-mounted encrypted video file.
[0054] The encrypted files cannot be played in players such as VLC (VideoLAN Client).
[0055] Furthermore, in order to adapt to the characteristics of limited resources and real-time requirements in the vehicle storage system, the above embodiment encrypts the starting position of the I frame and part of the data of the I frame image. When the amount of data of the I frame image is very large, the plaintext content is exposed too much, and the possibility of obtaining the plaintext through appropriate matching or brute force cracking increases. Therefore, this embodiment provides two dynamic encryption methods to expand the encrypted content and encryption complexity to take into account both real-time and security:
[0056] In the first dynamic encryption method, when identifying NALUs according to the NAL synchronization header and the NAL type field in S120, in addition to identifying the position of the starting NALU of each I frame in the vehicle-mounted bare stream video file, the position of the NALU where each SPS is located, the position of the NALU where each PPS is located, and the position of the NALU where each P frame is located can also be identified. For example, refer to Figure 4 Each "H264 Sequence Parameter Set" record in green font is a NALU storing SPS, each "H264 Picture Parameter Set" record in red font is a NALU storing PPS, and each "H264 P slice #" record in blue font is a NALU storing P frame. This step identifies the starting position of the NAL synchronization header in these NALUs.
[0057] Correspondingly, when data encryption is performed in S130, in addition to encrypting the first several consecutive bytes of the starting NALU of each I frame to hide the position of the starting NALU of each I frame, it is also possible to: encrypt all NALUs where each SPS and each PPS are located (including the NAL synchronization header, the NAL type field and the data part) to hide the position of the NALU where each SPS and each PPS are located, as well as the specific SPS parameters and PPS parameters; and encrypt the first several consecutive bytes of the NALU where each P frame is located (including the NAL synchronization header, the NAL type field and part of the image data) to hide the position of the NALU where each P frame is located, as well as part of the image data.
[0058] Correspondingly, when the hidden NALU position offset is encrypted and stored in S140, in addition to encrypting the position offset of the starting NALU of each I frame, the position offset and byte number of the NALU where each SPS is located, the position offset and byte number of the NALU where each PPS is located, and the position offset and byte number of the NALU where each P frame is located can also be encrypted (if the encrypted byte number of the P frame is different from that of the I frame, the byte number is encrypted; if the encrypted byte number of the P frame is the same as that of the I frame, the byte number may not be encrypted), and the four encrypted contents are stored together in the preset type of NALU.
[0059] In the above method, the NALU position and data content of SPS, PPS, I frame and P frame are hidden at the same time, making almost all the key information in image decoding impossible to locate and read, greatly improving the security of data. At the same time, SPS and PPS are used to store key parameters in image decoding. Figure 6 It can be seen that compared with the I frame, the amount of NALU data where SPS and PPS are located is very small. Therefore, this embodiment adopts different encryption strategies for the characteristics of SPS, PPS, I frame and P frame: SPS and PPS encrypt the entire NALU, I frame and P frame encrypt the first several consecutive bytes of the starting NALU, and realize dynamic encryption for NAL type. The total number of encrypted bytes is also relatively small. Compared with encrypting the entire I frame image, the encryption efficiency is still greatly improved, which meets the timeliness requirements of the vehicle system.
[0060] It should be noted that since the length of the NALU where the SPS and PPS are located is uncertain, when recording the position offset through the NAL of the reserved type (ie, custom type), it is also necessary to record the number of bytes of the NALU where each SPS and PPS are located. If the number of encrypted bytes of the P frame is different from that of the I frame, it is also necessary to record the number of encrypted bytes of each P frame for use in the decryption process.
[0061] The second dynamic encryption method is that when identifying NALU according to the NAL synchronization header and the NAL type field in S120, in addition to identifying the position of the starting NALU of each I frame in the vehicle-mounted bare stream video file, the position of the NALU where the first P frame after each I frame is located can also be identified. Through this position, the length of each I frame can be determined. Figure 4 , the blue font "H264 P slice #1", "H264 P slice #5", "H264 P slice #9", "H264 P slice #13", "H264 P slice #17", "H264 P slice #21" and "H264 P slice #25" are the locations of the NALU where the first P frame after the I frame is located.
[0062] Accordingly, when data encryption is performed in S130, the length of the data to be partially encrypted in the I frame can be determined according to the length of each I frame. In general, the larger the length of the I frame, the more bytes should be encrypted, so that the ciphertext and plaintext parts maintain a certain ratio, avoiding excessive exposure of the plaintext part and increasing the possibility of ciphertext cracking. Optionally, since the video data is aligned with 16 bytes in processing, this embodiment is based on The number of encrypted bytes is increased according to the rule, which is convenient for byte alignment and improves the processing efficiency of the computer. Among them, m is an integer related to the length of the I frame, 0 m≤N, N is the preset maximum multiple of 16 bytes. That is to say, the number of bytes encrypted continuously cannot be increased indefinitely, and a maximum multiple should be set, and N is usually greater than 3. It should be emphasized that even if the encrypted bytes increase, in this embodiment, the encryption is still performed from the first several consecutive bytes of the NALU starting from the I frame, and the encryption object always includes the NAL synchronization header, the NAL type field and part of the image data, so as to achieve the purpose of hiding the I frame position and encrypting part of the image.
[0063] In a specific implementation, the process of performing dynamic encryption according to the length of the I frame may include the following steps:
[0064] Step 1: Determine N+1 standard data block lengths for partially encrypting the I frame according to the following formula:
[0065]
[0066] in, Indicates that the index is n The number of bytes included in the standard data block length, 0≤n≤N; Indicates the ratio of the number of bytes in the encrypted part to the number of bytes in the unencrypted part of each data block. , The value of can be pre-set according to the desired security. Under the basic strategy of partially encrypting key data in the vehicle system, this embodiment sets the expected To ensure data security, The larger it is, the higher the security.
[0067] Step 2: For any I frame, if n Under a certain value (i.e., when n=a certain value), the number of bytes included in the I frame can be L satisfy , then for any I frame starting NALU consecutive bytes to be encrypted. The encryption length can make the ratio of the encrypted part to the unencrypted part greater than or equal to , to meet the safety requirements. Among them, From this time Substituting into formula (1) and calculating, we can know from the range of the independent variable in formula (1) that at this time Must meet 0≤ ≤N, so n The value of must be greater than 0, otherwise Will not exist. n The value of is the above The m in.
[0068] Step 3: If the number of bytes included in any I frame , then there is no n make , indicating that the I frame data volume is relatively large, The encryption length cannot meet the expected ratio At this time, we give up increasing the proportion of the encrypted part by continuing to increase n, but instead divide the entire I frame data into blocks, and use differentiated block strategies to increase the difficulty of data decryption and improve data security. Optionally, you can initialize the variable x =2, and divide any I frame into x If the data blocks cannot be evenly divided, the number of bytes in the last data block can be reduced. n The number of bytes that each data block can include under a certain value satisfy Established, for any I frame starting NALU consecutive bytes, and the following x- 1 data block before The consecutive bytes are encrypted separately. , that is, each data block is still larger than the number of bytes of the data block corresponding to the maximum encryption length, then x The value of plus 1 returns the value of dividing any I frame into x The operation of each data block is repeated until the encryption is completed.
[0069] For example, when N>3, if the number of bytes included in an I frame is , but the number of bytes exceeding is not large, the original I frame is divided into two data blocks, each of which uses a 32-byte encryption length, and continues to use Compared with the encryption length of and due to the existence of blocks, it is necessary to accurately identify the position of each data block during decryption, which further increases the difficulty of decryption and is a more effective encryption method.
[0070] Accordingly, when the position offset of the NALU is encrypted and stored in S140, in addition to encrypting the position offset of the starting NALU of each I frame, the length of the encrypted bytes in each revelation NALU can also be encrypted. and the number of data blocks x (When not divided into blocks x =1) to encrypt, and store the encrypted contents of the three items together in a NALU of a preset type. Optionally, the length of the encrypted bytes is not stored. and the number of data blocks xInstead, a decryption method matching the above encryption method (steps 1 to 3) is agreed upon in the decryption module or decryption device so that the decryption module or decryption device automatically calculates the length of the encrypted bytes and the number of data blocks.
[0071] In summary, the first dynamic encryption method realizes the dynamic adjustment of the encryption strategy with the NALU type, and the second dynamic encryption method realizes the dynamic adjustment of the encryption strategy with the length of the I frame. Both can improve data security and take into account encryption efficiency and data security. In practical applications, the two dynamic encryption methods can be used separately or at the same time, such as encrypting all NALUs where SPS and PPS are located, determining the number of bytes encrypted by the starting NALU header of the I frame according to the length of the I frame, and encrypting the starting bytes of the P frame, etc. This embodiment does not make specific restrictions.
[0072] Fig.10 : is a flow chart of a video decryption method based on a vehicle storage system provided by an embodiment of the present invention. The method is applicable to the case of decrypting a vehicle-mounted encrypted video file obtained by the method described in any of the above embodiments, and can be executed by a processing chip or decryption module in the vehicle storage system, or by an electronic device independent of the vehicle storage system, and this embodiment does not impose any specific restrictions. Fig.10 As shown, the method specifically includes:
[0073] S210. Obtain an in-vehicle encrypted video file to be decrypted, wherein the first several consecutive bytes of the starting NALU of each I frame in the in-vehicle encrypted video file are encrypted, and the first several consecutive bytes cover the NAL synchronization header, NAL type field, and part of the image data of the starting NALU of each I frame, resulting in the inability to identify the position of the starting NALU of each I frame.
[0074] That is to say, the vehicle-mounted encrypted video file to be decrypted in this embodiment is encrypted using the method described in any of the above embodiments.
[0075] S220: Identify the NALU at the end of the vehicle-mounted encrypted video file according to the NAL synchronization header.
[0076] This unit is the NALU added to the end of the file in any of the above embodiments, and is used to store a position offset list of the starting NALU of each I frame.
[0077] S230: If the value of the NAL type field in the tail NALU represents an agreed custom type, decrypt the data after the NAL type field to obtain the position offset of the starting NALU of each I frame in the vehicle-mounted encrypted video file.
[0078] When encrypting a video file in any of the above embodiments, it is necessary to agree with the decryption module or the decryption device on the custom type (i.e., the reserved type). The decryption module or the decryption device further verifies whether the last NALU of the file is a custom NALU data structure according to the type; if so, the data portion of the NALU is decrypted, and optionally, when AES encryption is used, the decryption is also performed using AES decryption; if not, it indicates that the file obtained in S210 is an unencrypted file or a file with encryption problems, and the current decryption method is terminated.
[0079] S240, decrypting a number of consecutive bytes starting from each offset respectively to restore the first several consecutive bytes of the start NALU of each I frame.
[0080] After decrypting the offset list plaintext, locate the starting NALU of each I frame according to the offset list, and decrypt several consecutive bytes starting from this position. The number of decrypted bytes at this time is consistent with the number of bytes in the encryption link. For example, encryption uses 32 bytes and decryption also uses 32 bytes. The decrypted plaintext replaces the ciphertext in the original position to obtain the plaintext raw stream video file. Subsequently, the I frame and P frame can be decoded according to the plaintext file to extract the video data.
[0081] Furthermore, under the above two dynamic encryption methods, this embodiment also provides two matching dynamic decryption methods:
[0082] The first dynamic decryption method corresponds to the first dynamic encryption method, that is, the NALU where each SPS and each PPS in the vehicle-mounted encrypted video file is located, and part of the data of the NALU where each P frame is located is also encrypted, and the starting position offset and number of bytes of each SPS and each PPS, and the starting position offset of each P frame (including the number of encrypted bytes if necessary) are encrypted and stored in the NALU at the end of the vehicle-mounted encrypted video file. At this time, after decrypting the data after the NAL type field in S230, in addition to obtaining the position offset of the starting NALU of each I frame in the vehicle-mounted encrypted video file, the position offset and number of bytes of the NALU where each SPS is located, the position offset and number of bytes of the NALU where each PPS is located, and the position offset of the NALU where each P frame is located (including the number of encrypted bytes if necessary) can also be obtained. For ease of distinction and description, this embodiment refers to the position offset and byte number corresponding to SPS as the first position offset and the first byte number, respectively, the position offset and byte number corresponding to PPS as the second position offset and the second byte number, respectively, the position offset corresponding to I frame as the third position offset, and the position offset and byte number corresponding to P frame as the fourth position offset and the fourth byte number, respectively.
[0083] Correspondingly, when decrypting according to the offset in S240, in addition to decrypting several consecutive bytes starting from each third position offset respectively to restore the first several consecutive bytes of the starting NALU of each I frame, the continuous bytes starting from each first position offset and the number of first bytes can also be decrypted to restore the NALU where each SPS is located; the continuous bytes starting from each second position offset and the number of second bytes can be decrypted to restore the NALU where each PPS is located; and the continuous bytes starting from each fourth position offset and the number of fourth bytes can be decrypted to restore the first several consecutive bytes in the NALU where each P frame is located.
[0084] This decryption method also realizes the dynamic adjustment of the decryption strategy with the NAL type. The NALU types and position offsets that need to be decrypted and identified are increased, and the decryption strategies corresponding to different NALU types are also different, which improves security performance.
[0085] The second dynamic decryption method corresponds to the second dynamic encryption method, that is, the number of bytes continuously encrypted in each I frame changes dynamically with the length of the I frame. At this time, if the number of encrypted bytes and the number of data blocks are stored in the preset type of NALU, then after decrypting the data after the NAL type field in S230, in addition to obtaining the position offset of the starting NALU of each I frame in the vehicle-mounted encrypted video file, the number of data blocks can also be obtained. x and the number of encrypted bytes in each data block Correspondingly, when decrypting according to the offset in S240, each I frame is first divided into blocks according to the number of data blocks, and then the front of each data block is The consecutive bytes are decrypted separately, including the first NALU of the I frame start consecutive bytes.
[0086] Optionally, if the number of encrypted bytes and the number of data blocks are not stored in a preset type of NALU, but a decryption method matching the same is agreed upon with the encryption module, then when decrypting the I frame in S240, the NALU where the first P frame is located after the position offset of any I frame can be identified according to the NAL synchronization header and the NAL type field; and according to the starting position of the NALU where the first P frame is located, the length of the I frame with the any offset as the starting position is determined; then, according to the I frame length, the number of data blocks divided when the I frame is encrypted is determined. x , and the number of encrypted bytes M in each data block; decrypt the M consecutive bytes starting from any of the offsets, and the first M consecutive bytes of each subsequent data block (if any), respectively.
[0087] In a specific implementation, the process of performing dynamic decryption according to the length of the I frame may include the following steps:
[0088] Step A: Determine N+1 standard data block lengths for partial decryption according to the following formula:
[0089]
[0090] in, Indicates that the index is n The number of bytes included in the standard data block length, 0≤n≤N; Indicates the ratio of the number of bytes in the encrypted part to the number of bytes in the unencrypted part of each data block. , the value of r is the same as that in the encryption method.
[0091] Step B: For any I frame, if n Under a certain value, the number of bytes included in the I frame can be L satisfy , then for any I frame starting NALU consecutive bytes to decrypt. n The value of must also be greater than 0.
[0092] Step C: If the number of bytes included in any I frame , then initialize the variable x =2, and divide any I frame into x data blocks. n The number of bytes that each data block can include under a certain value satisfy Established, for any I frame starting NALU consecutive bytes, and the following x- The first consecutive bytes of a data block, and the subsequent x- The first consecutive bytes of a data block are decrypted separately. , then x Add 1, return the value of dividing any I frame into x The operation of each data block is repeated until the decryption is completed.
[0093] In summary, the embodiment of the present invention provides a video encryption and decryption method based on a vehicle storage system. When encrypting, first find the position of the starting NAL of all I frames in the H.264 raw stream file, and perform AES encryption on the first several consecutive bytes of the NAL starting from each I frame, and the ciphertext is also stored in the original position of the file; the offset of this position (encrypted position) in the file is recorded in a list, and when the entire file is encrypted, the offset list data is encrypted by AES, and the ciphertext of the offset list plus the data structure formed by the NAL synchronization header and the NAL type are saved at the end of the file. When getting the encrypted file for decryption, first find the NAL data structure of the offset, perform AES decryption to obtain the plaintext of the offset list, and then decrypt the first several consecutive bytes of the NAL of each key frame I frame according to the offset list, and the decrypted plaintext replaces the ciphertext at the original position, and then perform related operations such as decoding.
[0094] In particular, several consecutive bytes encrypted in this embodiment include the NAL synchronization header of the I frame start NALU, the NAL type, and part of the I frame image data, which can hide the position of the I frame and part of the image content. After the I frame disappears, the P frame needs the I frame to decode, so the P frame cannot be decoded. This embodiment uses a small amount of encrypted bytes to make all video images undecodable, which is particularly suitable for vehicle-mounted scenarios with limited resources, but high-speed changes in video data and extremely high real-time requirements.
[0095] In addition, in order to avoid the situation where the I frame is too long and the security performance is reduced due to encryption of part of the data, the embodiment of the present invention provides two matching dynamic encryption and decryption methods, which respectively implement dynamic encryption and dynamic decryption for NALU type and I frame length, and by slightly increasing the amount of encrypted data and diversifying the dynamic encryption strategies, the difficulty of ciphertext cracking is greatly improved while ensuring timeliness, thereby fully ensuring information security.
[0096] Fig.11 FIG. 1 is a schematic diagram of a video encryption system based on a vehicle-mounted storage system provided by an embodiment of the present invention. Fig.11As shown, the system includes an encryption module, a storage module and a decryption module, wherein the encryption module is used to obtain a vehicle-mounted bare stream video file to be encrypted; according to the NAL synchronization header and the NAL type field, the position of each I-frame starting NALU in the vehicle-mounted bare stream video file is identified; the first several consecutive bytes of the starting NALU of each I-frame are encrypted to hide the position of the starting NALU of each I-frame, wherein the first several consecutive bytes cover the NAL synchronization header, the NAL type field, and part of the image data of the starting NALU of each I-frame; the position offset of the starting NALU of each I-frame is encrypted, and the NAL synchronization header and the NAL type field are added before the encrypted data to jointly constitute a NALU of a custom type, wherein the custom type is identified by an unused value in the NAL type field; the NALU of the custom type is added to the end of the encrypted vehicle-mounted bare stream video file to obtain a complete vehicle-mounted encrypted video file and store it in the storage module.
[0097] The decryption module is used to obtain the vehicle-mounted encrypted video file in the storage module, wherein the first several consecutive bytes of the starting NALU of each I frame in the vehicle-mounted encrypted video file are encrypted, and the position of the starting NALU of each I frame cannot be identified, wherein the first several consecutive bytes cover the NAL synchronization header, the NAL type field, and part of the image data of the starting NALU of each I frame; according to the NAL synchronization header, the NALU at the end of the vehicle-mounted encrypted video file is identified; if the value of the NAL type field in the NALU represents an agreed custom type, the data after the NAL type field is decrypted to obtain the position offset of the starting NALU of each I frame in the vehicle-mounted encrypted video file; and several consecutive bytes starting from each offset are decrypted respectively to restore the first several consecutive bytes of the starting NALU of each I frame.
[0098] The embodiment of the present invention is based on the same inventive concept as the video encryption method and decryption method based on the vehicle storage system in any of the above embodiments, is applicable to any limitation in any of the above embodiments, and can achieve the beneficial effects of any of the above embodiments.
[0099] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the technical solutions of the embodiments of the present invention.
Claims
1. A video encryption method based on a vehicle storage system, characterized in that: include: Get the vehicle-mounted raw video stream file to be encrypted; According to the NAL synchronization header and the NAL type field, the position of the starting NALU of each I frame in the vehicle-mounted bare stream video file is identified; Encrypt the first several consecutive bytes of the start NALU of each I frame to hide the position of the start NALU of each I frame, wherein the first several consecutive bytes cover the NAL synchronization header, NAL type field, and part of the image data of the start NALU of each I frame; Encrypt the position offset of the starting NALU of each I frame, add the NAL synchronization header and the NAL type field before the encrypted data, and together form a NALU of a custom type, wherein the custom type is identified by an unused value in the NAL type field; The NALU of the custom type is added to the end of the encrypted vehicle-mounted bare stream video file to obtain a complete vehicle-mounted encrypted video file.
2. The method according to claim 1, characterized in that The step of identifying the position of the starting NALU of each I frame in the vehicle-mounted bare stream video file according to the NAL synchronization header and the NAL type field includes: Identify each NAL synchronization header in the vehicle-mounted bare stream video file; According to the NAL type field after each NAL synchronization header, identify the starting NALU of each I frame; The starting position of the NAL synchronization header of each starting NALU is used as the position of the starting NALU of each I frame.
3. The method according to claim 1, characterized in that The encryption of the first several consecutive bytes of the starting NALU of each I frame includes: Encrypt the first several consecutive bytes of the starting NALU of any I frame, and the number of bytes of the encrypted ciphertext is the same as the original plaintext; The encrypted ciphertext is used to replace the original plaintext to obtain an encrypted I frame start NALU.
4. The method according to claim 1, characterized in that: The step of identifying the position of the starting NALU of each I frame in the vehicle-mounted bare stream video file according to the NAL synchronization header and the NAL type field comprises: identifying the position of the NALU where each SPS is located, the position of the NALU where each PPS is located, the position of the starting NALU of each I frame, and the position of the NALU where each P frame is located in the vehicle-mounted bare stream video file according to the NAL synchronization header and the NAL type field; The encrypting of the first several consecutive bytes of the NALU starting from each I frame to hide the position of the NALU starting from each I frame includes: encrypting all the NALUs where each SPS and each PPS are located to hide the position of the NALU where each SPS and each PPS are located; encrypting the first several consecutive bytes of the NALU starting from each I frame to hide the position of the NALU starting from each I frame; and encrypting the first several consecutive bytes of the NALU where each P frame is located to hide the position of the NALU where each P frame is located; The encryption of the position offset of each I frame starting NALU includes: encrypting the position offset and byte number of the NALU where each SPS is located, the position offset and byte number of the NALU where each PPS is located, the position offset of each I frame starting NALU, and the position offset of each P frame NALU.
5. The method according to claim 1, characterized in that The step of identifying the position of the starting NALU of each I frame in the vehicle-mounted bare stream video file according to the NAL synchronization header and the NAL type field comprises: identifying the position of the starting NALU of each I frame in the vehicle-mounted bare stream video file and the position of the NALU where the first P frame after each I frame is located according to the NAL synchronization header and the NAL type field; The encrypting of the first several consecutive bytes of the starting NALU of each I frame includes: determining the length of any I frame according to the position of the starting NALU of any I frame and the position of the NALU where the first P frame after the any I frame is located; encrypting the first several consecutive bytes of the starting NALU of any I frame according to the length, wherein the number of the several consecutive bytes is is the preset maximum multiple of 16 bytes, and m is an integer related to the length.
6. The method according to claim 5, characterized in that The step of encrypting the first several consecutive bytes of the start NALU of any I frame according to the length includes: According to the following formula, the N+1 standard data block lengths for partial encryption of the I frame are determined: ; in, Indicates that the index is n The number of bytes included in the standard data block length, 0≤n≤N; Indicates the ratio of the number of bytes in the encrypted part to the number of bytes in the unencrypted part of each data block, where r is the default value, 0 1; if n Under a certain value, the number of bytes included in any I frame can be L satisfy For any I frame starting NALU consecutive bytes to be encrypted; If the number of bytes included in any I frame ,initialization x =2, divide any I frame into x data blocks; if n The number of bytes that each data block can include under a certain value satisfy , for any I frame starting NALU consecutive bytes, and the following x- 1 data block before consecutive bytes are encrypted separately; if ,Will x Add 1, return the value of dividing any I frame into x The operation of each data block is repeated until the encryption is completed.
7. A video decryption method based on a vehicle storage system, characterized in that: include: Obtaining a vehicle-mounted encrypted video file to be decrypted, wherein the first several consecutive bytes of each I-frame start NALU in the vehicle-mounted encrypted video file are encrypted, and the first several consecutive bytes cover the NAL synchronization header, NAL type field, and part of the image data of each I-frame start NALU, resulting in the inability to identify the position of each I-frame start NALU; According to the NAL synchronization header, identifying the NALU at the end of the vehicle-mounted encrypted video file; If the value of the NAL type field in the tail NALU represents an agreed custom type, decrypt the data after the NAL type field to obtain the position offset of the starting NALU of each I frame in the vehicle-mounted encrypted video file; Several consecutive bytes starting from each offset are decrypted respectively to restore the first several consecutive bytes of the start NALU of each I frame.
8. The method according to claim 7, characterized in that The NALUs where each SPS and each PPS are located in the vehicle-mounted encrypted video file are all encrypted, the first several consecutive bytes of the NALU where each P frame is located are encrypted, and the starting position offset and number of bytes of each SPS and each PPS, as well as the starting position offset of each P frame are encrypted and stored in the NALU at the end; The decrypting of the data after the NAL type field to obtain the position offset of the starting NALU of each I frame in the vehicle-mounted encrypted video file includes: decrypting the data after the NAL type field to obtain the first position offset and the first byte number of the NALU where each SPS is located, the second position offset and the second byte number of the NALU where each PPS is located, the third position offset of the starting NALU of each I frame, and the fourth position offset of the NALU where each P frame is located; The decrypting of several consecutive bytes starting from each offset to restore the first several consecutive bytes of the starting NALU of each I frame includes: decrypting the consecutive bytes with the first position offset as the starting point and the number of first bytes as the starting point to restore the NALU where each SPS is located; decrypting the consecutive bytes with the second position offset as the starting point and the number of second bytes as the starting point to restore the NALU where each PPS is located; decrypting several consecutive bytes starting from each third offset to restore the first several consecutive bytes of the starting NALU of each I frame; decrypting several consecutive bytes starting from each fourth offset to restore the first several consecutive bytes of the NALU where each P frame is located.
9. The method according to claim 7, characterized in that: The decrypting of a number of consecutive bytes starting from each offset respectively includes: Based on the NAL synchronization header and NAL type field, identify the NALU where the first P frame after any offset is located; Determine, according to the starting position of the NALU where the first P frame is located, the length of the I frame with any offset as the starting position; Determine, according to the length of the I frame, the number of data blocks used for partial encryption of the I frame and the number of bytes M to be encrypted in each data block; The M consecutive bytes starting from any of the offsets and the first M consecutive bytes of each subsequent data block are decrypted respectively.
10. A vehicle-mounted storage system, characterized in that: include: Encryption module, storage module and decryption module; The encryption module is used to obtain a vehicle-mounted bare stream video file to be encrypted; according to the NAL synchronization header and the NAL type field, the position of each I-frame starting NALU in the vehicle-mounted bare stream video file is identified; the first several consecutive bytes of each I-frame starting NALU are encrypted to hide the position of each I-frame starting NALU, wherein the first several consecutive bytes cover the NAL synchronization header, the NAL type field, and part of the image data of each I-frame starting NALU; the position offset of each I-frame starting NALU is encrypted, and the NAL synchronization header and the NAL type field are added before the encrypted data to jointly constitute a NALU of a custom type, wherein the custom type is identified by an unused value in the NAL type field; the NALU of the custom type is added to the end of the encrypted vehicle-mounted bare stream video file to obtain a complete vehicle-mounted encrypted video file and store it in the storage module; The decryption module is used to obtain the vehicle-mounted encrypted video file in the storage module; identify the NALU at the end of the vehicle-mounted encrypted video file according to the NAL synchronization header; if the value of the NAL type field in the NALU represents an agreed custom type, decrypt the data after the NAL type field to obtain the position offset of the starting NALU of each I frame in the vehicle-mounted encrypted video file; and decrypt several consecutive bytes starting from each offset to restore the first several consecutive bytes of the starting NALU of each I frame.
Citation Information
Patent Citations
Audio and video data encryption and decryption method and device based on rtmp and readable storage medium
CN110881142A
Data processing method and device, electronic equipment and computer medium
CN118012611A