Video file tamper-proofing method and device, electronic equipment and readable storage medium
By generating asymmetric key pairs, numbering video frames, extracting key data, calculating chained hash digests, and then encrypting and embedding the data into the video frames, the problem of low efficiency and poor reliability in existing video anti-tampering processing technologies is solved, achieving efficient and reliable anti-tampering of video files.
Patent Information
- Application Number
- CN202511845017.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-09
- Publication Date
- 2026-02-10
AI Technical Summary
Existing technologies are inefficient and unreliable in video anti-tampering processing, making it difficult to meet real-time or near-real-time processing requirements and unable to accurately locate the tampering position, especially when faced with common tampering methods such as frame deletion and frame order swapping.
By generating asymmetric key pairs, video frames are numbered and key data is extracted. After calculating the chained hash digest, the data is encrypted and embedded into the video frames to generate a tamper-proof video file.
It improves the efficiency and reliability of video anti-tampering processing, can sensitively detect tampering and locate the tampering location, and ensure the integrity and authenticity of video content.
Smart Images

Figure CN121509712A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of digital information security technology, and in particular to methods, devices, electronic devices and readable storage media for preventing video files from being tampered with. Background Technology
[0002] In critical areas such as public safety, judicial evidence collection, and digital rights management, video files are often stored, transmitted, and distributed as core evidence or important digital assets. To ensure the authenticity and integrity of their content, existing technologies mainly rely on two approaches: one is digital watermarking technology, which embeds visible or invisible identification information into the video footage to achieve source tracing and tampering detection; the other is cryptographic digest technology, which calculates the hash value of the entire video file and digitally signs it to verify whether the file has been completely tampered with.
[0003] However, existing technical solutions have common shortcomings when facing the actual needs of video anti-tampering. Digital watermarking schemes usually involve complex encoding and decoding processes, which consume a lot of computing resources and have low processing efficiency. Moreover, the embedding operation may have an irreversible impact on the original video quality. On the other hand, global summary-based schemes are difficult to meet the requirements of real-time or near real-time processing due to the large amount of data they process. Furthermore, once the verification fails, it is impossible to accurately locate the specific location of the tampering and cannot effectively deal with common tampering methods such as frame deletion and frame order transposition. As a result, the efficiency and reliability of video anti-tampering processing are low. Summary of the Invention
[0004] In view of this, the embodiments of this application provide at least a method, apparatus, electronic device and readable storage medium for preventing video file tampering, which improves the efficiency and reliability of video tampering prevention processing by extracting key data and binding it with chain hash.
[0005] This application mainly includes the following aspects: In a first aspect, embodiments of this application provide a method for preventing tampering with video files, the method comprising: Generate an asymmetric key pair for the video file to be processed; Each video frame of the video file to be processed is numbered according to time sequence, and key data is extracted from the encoded data of each video frame according to the encoding type of each video frame. For any of the video frames, a chain hash digest of the video frame is calculated based on the video frame number, the encoded data length of the video frame, the key data of the video frame, and the chain hash digest of the previous video frame. The chain hash digest of the video frame is encrypted based on the private key in the asymmetric key pair, and the encryption result is embedded into the video frame to obtain a tamper-proof video frame. Based on each of the tamper-proof video frames and the public key of the asymmetric key pair, a tamper-proof video file is generated.
[0006] Secondly, embodiments of this application also provide a video file anti-tampering device, the video file anti-tampering device comprising: The key generation module is used to generate asymmetric key pairs for the video files to be processed; The data extraction module is used to number each video frame of the video file to be processed according to the time sequence, and extract key data from the encoded data of each video frame according to the encoding type of each video frame. The digest generation module is used to calculate the chain hash digest of any video frame based on the video frame number, the encoded data length of the video frame, the key data of the video frame, and the chain hash digest of the previous video frame. The data encryption module is used to encrypt the chain hash digest of the video frame based on the private key in the asymmetric key pair, and embed the encryption result into the video frame to obtain a tamper-proof video frame. The file generation module is used to generate tamper-proof video files based on each of the tamper-proof video frames and the public key of the asymmetric key pair.
[0007] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the memory communicate through the bus. The machine-readable instructions are executed by the processor to perform the steps of the video file anti-tampering method described above.
[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the video file anti-tampering method described above.
[0009] The video file anti-tampering method, apparatus, electronic device, and readable storage medium provided in this application include: generating an asymmetric key pair for the video file to be processed; numbering each video frame of the video file according to time sequence, and extracting key data from the encoded data of each video frame according to the encoding type of each video frame; for any video frame, calculating a chain hash digest of the video frame based on the video frame number, encoded data length, key data, and the chain hash digest of the previous video frame; encrypting the chain hash digest of the video frame based on the private key in the asymmetric key pair, and embedding the encryption result into the video frame to obtain the anti-tampering processed video frame; and generating an anti-tampering processed video file based on each anti-tampering processed video frame and the public key of the asymmetric key pair. In this way, by binding key data extraction with chain hashing, the efficiency and reliability of video anti-tampering processing are improved.
[0010] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0012] Figure 1 The flowchart illustrates a method for preventing video file tampering provided in an embodiment of this application. Figure 2 A schematic diagram illustrating the key data extraction and encryption result embedding in an embodiment of this application is shown; Figure 3 This illustration shows one of the functional block diagrams of a video file anti-tampering device provided in an embodiment of this application; Figure 4 This illustration shows a second functional block diagram of a video file anti-tampering device provided in an embodiment of this application; Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation
[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0014] To facilitate understanding of this application, the technical solutions provided in this application will be described in detail below with reference to specific embodiments.
[0015] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for preventing video file tampering provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the video file anti-tampering method includes the following steps: S101, Generate an asymmetric key pair for the video file to be processed.
[0016] Here, a dedicated asymmetric encryption key pair is generated for each video file that needs protection. This key pair contains a private key and a public key; the private key is used to generate an anti-counterfeiting signature, and the public key is used for subsequent public verification.
[0017] In this embodiment, the private key is securely stored by the video generator or management platform, while the public key can be published along with the video file. This method ensures that the verification credentials for each video file are independent, and even if the public key information of one file is leaked, it will not compromise the security of other files.
[0018] S102, number each video frame of the video file to be processed according to the time sequence, and extract key data from the encoded data of each video frame according to the encoding type of each video frame.
[0019] Here, all frames of the video to be processed are sequentially numbered to determine their unique positions. At the same time, the encoding format of each frame is analyzed to distinguish its frame type (e.g., whether it is a keyframe containing complete information or a predicted frame that depends on information from other frames), and based on this, a small segment of data that can represent the characteristics of that frame is extracted from its original encoded data stream.
[0020] In this embodiment, the sequential numbering starts from 0 and increments. When parsing the video file, the type of each frame is identified according to the encoding standard. For example, for keyframes, a relatively large number of bytes are extracted as features starting from their data header; for non-keyframes, a relatively small number of bytes are extracted. The extracted data originates from the encoded compressed data itself, eliminating the need for complete video decoding and pixel-level processing, thus significantly reducing the amount of data processing.
[0021] S103, for any one of the video frames, calculate the chain hash digest of the video frame based on the video frame number, the encoded data length of the video frame, the key data of the video frame, and the chain hash digest of the previous video frame.
[0022] Here, a unique digital digest (hash value) is calculated for the current video frame. This calculation takes into account not only the frame's identification information (number), size information (length), and feature information (key data), but also the digest result of the previous frame, so that the digest of each frame is closely bound to its own content and historical sequence, forming a chain structure with sequential relationships.
[0023] In this embodiment, the current frame number, total data length in bytes, extracted key data, and the hash digest value calculated from the previous frame are sequentially concatenated into a data block. Then, a cryptographic hash function is used to calculate this data block, and the output is the chained hash digest of the current frame. For the first frame of the video sequence, since there is no previous frame, a predefined, fixed initialization value is used to participate in its digest calculation, thereby initiating the entire chained process.
[0024] S104, encrypt the chain hash digest of the video frame based on the private key in the asymmetric key pair, and embed the encryption result into the video frame to obtain the tamper-proof video frame.
[0025] Here, the private key generated in step S101 is used to perform an encryption operation on the calculated chain hash digest to generate a digital signature for the frame. Subsequently, this signature data is combined with the original video frame data in a specific manner to generate a new data unit containing the signature information.
[0026] In this embodiment, the encryption operation generates a unique ciphertext signature corresponding to the frame and its historical chain. This signature data is directly appended to the end of the original video frame's encoded data, becoming part of that frame. This data appending method does not change the original visual encoded content of the video frame, thus ensuring that the authenticity of the original video footage remains unaffected.
[0027] S105, generate a tamper-proof video file based on each of the tamper-proof video frames and the public key of the asymmetric key pair.
[0028] Here, all video frames that have completed the signature embedding process are reassembled according to their original time order, associated with the corresponding public key, and packaged, and finally output as a complete and self-verifiable video file.
[0029] In this embodiment, the processed video frames are written into a standard video file container. Simultaneously, the public key corresponding to the signatures of these frames is also included in this file, for example, as file metadata or an auxiliary part. The resulting video file contains not only the video content that can be decoded and played normally, but also all the information necessary to verify the integrity of each frame and the authenticity of the sequence.
[0030] Furthermore, the step of extracting key data from the encoded data of each video frame according to the encoding type of each video frame includes: Step a1: If the encoding type of the video frame is a keyframe, then extract data of a first preset length from the starting position of the encoded data of the video frame as key data.
[0031] Please see here. Figure 2 , Figure 2 This is a schematic diagram illustrating the key data extraction and encryption result embedding in an embodiment of this application. For example... Figure 2 As shown, a keyframe (e.g., an I-frame) is an independent frame in a video coding sequence, containing complete picture information. It typically has a large data volume and does not depend on other frames during decoding. Therefore, extracting relatively more data from the beginning of its encoded data allows for a more comprehensive capture of the frame's core coding features, providing sufficient information for subsequent summary calculations and ensuring that any modifications to the frame's data can be sensitively detected.
[0032] In this embodiment, the specific value of the first preset length can be adjusted according to video encoding parameters and security requirements. For example, in a typical implementation, a keyframe can be configured to extract 1024 bytes from the beginning of the encoded data as its key data. If the original encoded data length of the keyframe is less than this preset value, then all of its data is extracted.
[0033] Step a2: If the encoding type of the video frame is a non-key frame, then extract data of a second preset length from the starting position of the encoded data of the video frame as key data; wherein, the first preset length is greater than the second preset length.
[0034] Here, as Figure 2As shown, non-keyframes (such as P-frames or B-frames) record the differences between the frame and the reference frame, and their data volume is usually much smaller than that of keyframes. Although the data volume is small, the encoded data at the beginning of the frame still contains important motion vectors, residuals, and other key compression information. Extracting a relatively small amount of representative data can significantly reduce the amount of data processing while ensuring tamper-proof sensitivity. Specifying that the second preset length is smaller than the first preset length conforms to the data characteristics of video coding, achieving a balance between computational efficiency and security strength.
[0035] In this embodiment, the second preset length is less than the first preset length. For example, 512 bytes can be extracted from the beginning of the encoded data as key data for a non-key frame. If the original encoded data length of the non-key frame is less than this preset value, all of its data is extracted. This differentiated extraction strategy fully utilizes the encoding characteristics of the video stream and achieves effective extraction of key information for each frame without excessively increasing the computational burden.
[0036] Further, calculating the chained hash digest of the video frame based on the video frame number, the encoded data length of the video frame, the key data of the video frame, and the chained hash digest of the previous video frame includes: Step b1: Combine the video frame number, the encoded data length, the key data, and the chained hash digest of the previous video frame into a data block to be processed in a predetermined order.
[0037] Here, the ordered concatenation of all input elements required for computation is a prerequisite for generating a unique and deterministic hash digest. Combining the frame number, data length, key data, and the digest value of the previous frame in a fixed order ensures that the binary representation of the input data block is absolutely unique for a given video frame. This combination method not only incorporates the static features of the current frame but also encodes temporal correlations into the data block by introducing the dynamic digest of the previous frame, laying the foundation for forming an inseparable verification chain.
[0038] In the embodiments of this application, such as Figure 2 As shown, the predetermined order can be: first, place the video frame numbers. Secondly, the total length of the encoded data in this frame in bytes. Next is the key data extracted in step S102. Finally, the chained hash digest calculated from the previous video frame is concatenated. For example, this can be achieved through simple byte concatenation operations. This is used to generate the final data blocks to be processed. For the first frame, its... Fill with a preset initial value (such as a sequence of all zeros).
[0039] Step b2: Perform a hash algorithm operation on the data block to be processed to generate a chained hash digest of the video frame.
[0040] Here, a cryptographic hash function is applied to the combined data block to generate a fixed-length, unique, and irreversible digest. The one-way and collision-resistant nature of the hash algorithm ensures that the original data cannot be deduced from the digest, and it is extremely difficult to find two different data blocks that produce the same digest. This step compresses the data block containing chained association information into a concise representative value, which is the chained hash digest of this frame. It will be used for signing this frame and as one of the key inputs for calculating the digest of the next frame.
[0041] In this embodiment, the SHA-256 hash algorithm can be used to process the data block generated in step b1. The SHA-256 algorithm outputs a fixed-length hash value of 256 bits (32 bytes), which has high security. The specific calculation can be expressed as follows: The result of the calculation That is, as a chained hash digest of the current video frame, it uniquely represents the association state of this frame and all its historical frames.
[0042] Furthermore, embedding the encryption result into the video frame to obtain the tamper-proof video frame includes: Step c1: Encapsulate the encryption result into a data unit that conforms to the video encoding format.
[0043] Here, as Figure 2 As shown, chained hash digest The encryption result using the private key can be used This indicates that directly using the original encrypted byte stream might not be compatible with video encoding systems or could be ignored by the player. Therefore, the encrypted result needs to be organized into a standardized, recognizable, and parsable data structure unit according to the syntax defined by the target video encoding standard (such as H.264 / AVC, H.265 / HEVC). This encapsulation ensures that the data can be correctly processed by standard video processing tools (such as encoders, decoders, and analyzers) while maintaining seamless integration with the original video stream.
[0044] In this embodiment of the application, the encryption result can be... Encapsulation can be performed as a supplementary enhancement information unit or a user-defined private data block. For example, in the H.264 standard, it can be encapsulated as a SEINAL unit with its payload type specified as user-unregistered information; or, at the video file container level, it can be defined as a box with a private data type. The encapsulation process includes adding necessary header information (such as data type identifier and length field) and footer checksum information (if needed) to form a complete and independent data unit.
[0045] Step c2: The data unit is appended to the encoded data of the video frame to obtain the tamper-proof video frame.
[0046] Here, as Figure 2 As shown, "appended after" means placing the encapsulated data unit at the end of the original video frame's encoded data, either spatially or logically, to form a new, extended data sequence. This operation does not insert into or modify the original video frame's encoded data stream itself, thus completely preserving the lossless nature of the original video content. This data unit, as an appendage to the video frame, is stored and transmitted along with the frame data.
[0047] In this embodiment, after encoding a video frame, the data unit generated in step c1 is directly written to the end of the original encoded bitstream of that frame. For example, for an H.264 bitstream organized in the form of a NAL unit stream, an SEI NAL unit encapsulating the encryption result is written immediately after the NAL unit containing the frame slice data. In the final video file or bitstream, the data of this frame is represented as: [original frame encoded data] + [encapsulated encrypted data unit]. This results in a tamper-proof video frame that contains its own integrity signature and does not affect the original visual content.
[0048] Furthermore, when the video frame is the first frame of the video file to be processed in time sequence, the chain hash digest of the previous video frame is a preset initial value.
[0049] Here, the core of chained hashing lies in the fact that the digest of the current frame depends on the digest of the previous frame. For the starting frame of a video sequence, there is no true previous frame and its digest. Therefore, a definite, consensus-based initial value must be defined to initiate the entire chained hashing process to ensure its integrity and reproducibility. The digests of all subsequent frames are derived directly or indirectly from this initial value, making the integrity verification of the entire video file a coherent and indivisible whole.
[0050] In this embodiment, the preset initial value can be a fixed, publicly available numerical value. For example, a sequence of all-zero bytes (0x00…00) with a length equal to the output size of the hash algorithm (e.g., 256 bits for SHA-256) can be used as the initial value. This initial value must remain consistent at the video file generation end and the subsequent verification end to ensure that both ends can independently calculate the exact same chained hash digest sequence, which is the basis for achieving reliable verification.
[0051] Furthermore, the method also includes: Step d1: Obtain the tamper-proof video file as the video file to be verified, and obtain the public key of the video file to be verified.
[0052] Here, the verification process begins by obtaining the target video file to be verified and the credential for verifying its legitimacy, namely the public key. This video file is a tamper-proof file with an embedded cryptographic digest. The public key, paired with the private key used to generate the file, is the unique credential for decrypting and verifying the validity of the digital signature.
[0053] In this embodiment, the video file to be verified may originate from an external system, storage medium, or network transmission. The public key is typically provided along with the video file, for example, as a specific metadata field within the video file container, an accompanying certificate file, or information explicitly specified in the file header. The verifier needs to correctly parse the video file structure to extract the video data stream and public key information.
[0054] Step d2: For each video frame of the video file to be verified, calculate the first chain hash digest of the video frame to be verified based on the video frame number, the encoded data length of the video frame to be verified, the key data of the video frame to be verified, and the chain hash digest of the previous video frame to be verified.
[0055] Here, to verify the integrity of the video content, the verifier needs to simulate the computation process at the generation end, independently recalculating the chained hash digest for each frame, called the first chained hash digest. The elements relied upon for the calculation are completely consistent with those at the time of generation, including key data re-extracted from the encoded data of the current frame according to the same rules. By reproducing this chained calculation, a digest value that should theoretically be consistent with the original signature can be obtained.
[0056] In this embodiment, the verifier sequentially reads each frame of the video file to be verified. First, the frame is parsed to obtain its number (e.g., from the timing information of the file or container format) and its encoded data length is determined. Next, based on the frame's encoding type, key data is extracted again from the starting position of its encoded data, following the same first preset length (keyframe) or second preset length (non-keyframe) rule as when it was generated. Then, these elements (number, length, key data) are concatenated with the calculated chain hash digest of the previous frame (using the same preset initial value for the first frame), and the same hash algorithm (e.g., SHA-256) is used to calculate the first chain hash digest of the current frame, denoted as . This process continues throughout the entire video sequence.
[0057] Step d3: Extract the encryption result of the video frame to be verified from the video frame to be verified, and decrypt the encryption result of the video frame to be verified using the public key of the video file to be verified, to obtain the second chain hash digest of the video frame to be verified.
[0058] Here, the verifier needs to obtain the digital signature (i.e., the encrypted result) of the original digest from the generator and attempt to recover it. This is done by locating and extracting the previously embedded encrypted data unit from the video frame data and decrypting it using the obtained public key. If the public key matches the private key used for signing, and the signature has not been tampered with since its generation, the decryption will succeed, restoring the original chain hash digest value.
[0059] In this embodiment, the verifier, based on the video encoding format, parses and extracts encapsulated data units (such as SEI NAL units or private data blocks) from the end of the data in each video frame to be verified or from a specified position. The encryption result is then obtained from the payload of this unit. Next, using the public key obtained in step d1, an asymmetric decryption operation is performed on this ciphertext data. If the key pairing is successful and the data is complete, a plaintext digest value is obtained after decryption. This is the chain hash digest calculated and signed by the generator at that time, denoted as the second chain hash digest. .
[0060] Step d4: Verify whether the video frame to be verified has been tampered with based on the first chained hash digest and the second chained hash digest.
[0061] Here, the first chain hash digest obtained by independent computation is... The second chain hash digest recovered from the signature A comparison is performed. Consistency is the direct basis for determining whether the frame has been tampered with since it was signed. If the two are completely consistent, it proves that the frame content is complete and has not been modified; if they are inconsistent, it indicates that the frame content or its association in the chain has been damaged, i.e., it has been tampered with.
[0062] In this embodiment of the application, the first chained hash digest of each frame is... With the second chain hash digest A precise comparison is performed. If the frames match, the frame passes the integrity verification. If they do not match, the frame has been tampered with. The verification results can be output in real time, for example, marking the sequence number of the tampered frame, or terminating the verification and issuing an alarm when the first mismatched frame is encountered. By comparing each frame one by one, this method can not only detect content tampering, but also sensitively detect tampering behaviors such as frame deletion, insertion, or reordering due to chain-like correlation.
[0063] Furthermore, the method also includes: Step e1: Obtain the private key verification information corresponding to the video file to be verified, which is recorded by the publisher's system.
[0064] Here, to trace the source of a video file's distribution, it's necessary not only to verify the content's integrity but also to verify that the public key it carries originates from a trusted publisher. Therefore, the verifier needs to obtain authoritative credentials—specifically, private key verification information—from the publisher or its authorized trusted platform to verify the public key's legitimacy. This information is the ultimate basis for determining whether the public key has been misused or forged.
[0065] In this embodiment, the private key verification information can be a credential securely stored in the publisher's system that is directly related to the private key S1 used when the video file to be verified was generated. For example, the publisher platform can maintain a legitimate key pair database. When verification is required, the verifier queries the platform for the private key S1 bound to the video file identifier (such as file ID) or the digital certificate issued by it; alternatively, the publisher can pre-distribute a verification file containing its root certificate or authorization information to the verification terminals. Obtaining this information is a prerequisite for trusted source verification.
[0066] Step e2: Pair the public key of the video file to be verified with the private key verification information to confirm the publication source of the video file to be verified.
[0067] Here, the public key S2 extracted from the video file to be verified will be cryptographically paired with the private key verification information obtained from the publisher's system. The core is to verify whether the public key S2 and the private key S1 held and recognized by the publisher constitute a valid asymmetric key pair. If the pairing is successful, it proves that the public key was indeed authorized and generated by the publisher, thus confirming that the video file originated from the publisher; otherwise, it indicates that the file's origin is suspicious or the public key has been tampered with.
[0068] In this embodiment, a specific pairing verification method is as follows: the publishing system provides a digital certificate issued by its root private key, containing public key S2 information. The verifier uses the publishing system's root certificate (public key) to verify the signature validity of the digital certificate. If the verification passes, the legitimacy of public key S2 is proven. Another more direct method is that the verifier performs a pairing operation between the private key S1 (or a token signed with S1) obtained from the publishing system and the public key S2 to be verified (for example, using S1 to decrypt test data encrypted by S2, or verifying a signature generated by S1 that corresponds to S2). If the operation is successful, the pairing relationship is proven to be valid. Through this step, on the basis of content integrity, trusted authentication of the video file publisher's identity is further achieved.
[0069] This application provides a method for preventing video file tampering, comprising: generating an asymmetric key pair for the video file to be processed; numbering each video frame of the video file according to time sequence, and extracting key data from the encoded data of each video frame according to the encoding type of each video frame; calculating a chain hash digest of the video frame for any given video frame based on the video frame number, encoded data length, key data, and the chain hash digest of the previous video frame; encrypting the chain hash digest of the video frame based on the private key in the asymmetric key pair, and embedding the encryption result into the video frame to obtain a tamper-proof video frame; and generating a tamper-proof video file based on each tamper-proof video frame and the public key of the asymmetric key pair. In this way, by binding key data extraction with chain hashing, the efficiency and reliability of video tamper-proof processing are improved.
[0070] Based on the same application concept, this application also provides a video file anti-tampering device corresponding to the video file anti-tampering method provided in the above embodiments. Since the principle of the device in this application is similar to the video file anti-tampering method in the above embodiments of this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.
[0071] Please see Figure 3 , Figure 3 This is one of the functional block diagrams of a video file anti-tampering device provided in an embodiment of this application. For example... Figure 3As shown, the video file anti-tampering device 300 provided in this application embodiment includes: The key generation module 310 is used to generate asymmetric key pairs for the video file to be processed.
[0072] The data extraction module 320 is used to number each video frame of the video file to be processed according to the time sequence, and extract key data from the encoded data of each video frame according to the encoding type of each video frame.
[0073] The digest generation module 330 is used to calculate the chain hash digest of any video frame based on the video frame number, the encoded data length of the video frame, the key data of the video frame, and the chain hash digest of the previous video frame.
[0074] The data encryption module 340 is used to encrypt the chain hash digest of the video frame based on the private key in the asymmetric key pair, and embed the encryption result into the video frame to obtain a tamper-proof video frame.
[0075] The file generation module 350 is used to generate a tamper-proof video file based on each of the tamper-proof video frames and the public key of the asymmetric key pair.
[0076] Furthermore, when the data extraction module 320 extracts key data from the encoded data of each video frame according to the encoding type of each video frame, the data extraction module 320 is specifically used for: If the encoding type of the video frame is a keyframe, then data of a first preset length is extracted from the starting position of the encoded data of the video frame as key data. If the encoding type of the video frame is a non-key frame, then data of a second preset length is extracted from the starting position of the encoded data of the video frame as key data; wherein, the first preset length is greater than the second preset length.
[0077] Furthermore, when the digest generation module 330 calculates the chained hash digest of the video frame based on the video frame number, the encoded data length of the video frame, the key data of the video frame, and the chained hash digest of the previous video frame, the digest generation module 330 is specifically used for: The video frame number, the encoded data length, the key data, and the chained hash digest of the previous video frame are combined into a data block to be processed in a predetermined order. A hash algorithm is performed on the data block to be processed to generate a chained hash digest of the video frame.
[0078] Furthermore, when the data encryption module 340 embeds the encryption result into the video frame to obtain a tamper-proof video frame, the data encryption module 340 is specifically used for: The encryption result is encapsulated into a data unit that conforms to the video encoding format; The data unit is appended to the encoded data of the video frame to obtain the tamper-proof video frame.
[0079] Further, please refer to Figure 4 , Figure 4 This is a second functional block diagram of a video file anti-tampering device provided in an embodiment of this application. Figure 4 As shown, the video file anti-tampering device 300 also includes: The file acquisition module 360 is used to acquire the tamper-proof video file as the video file to be verified, and to acquire the public key of the video file to be verified.
[0080] The second digest generation module 370 is used to calculate a first chain hash digest for each video frame to be verified in the video file to be verified, based on the video frame number, the encoded data length of the video frame to be verified, the key data of the video frame to be verified, and the chain hash digest of the previous video frame to be verified.
[0081] The file decryption module 380 is used to extract the encryption result of the video frame to be verified from the video frame to be verified, and to decrypt the encryption result of the video frame to be verified using the public key of the video file to be verified, so as to obtain the second chain hash digest of the video frame to be verified.
[0082] The tamper verification module 390 is used to verify whether the video frame to be verified has been tampered with based on the first chained hash digest and the second chained hash digest.
[0083] Furthermore, the file acquisition module 360 is also used for: Obtain the private key verification information corresponding to the video file to be verified, recorded by the publisher's system; The public key of the video file to be verified is paired with the private key verification information to confirm the publication source of the video file to be verified.
[0084] This application provides a video file anti-tampering device, comprising: a key generation module for generating an asymmetric key pair for the video file to be processed; a data extraction module for numbering each video frame of the video file according to time sequence and extracting key data from the encoded data of each video frame according to the encoding type of each video frame; a digest generation module for calculating a chain hash digest of any video frame based on the video frame number, encoded data length, key data, and the chain hash digest of the previous video frame; a data encryption module for encrypting the chain hash digest of the video frame based on the private key in the asymmetric key pair and embedding the encryption result into the video frame to obtain the anti-tampering processed video frame; and a file generation module for generating an anti-tampering processed video file based on each anti-tampering processed video frame and the public key of the asymmetric key pair. Thus, by binding key data extraction with chain hashing, the efficiency and reliability of video anti-tampering processing are improved.
[0085] Based on the same application concept, please refer to Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 500 includes a processor 510, a memory 520, and a bus 530.
[0086] The memory 520 stores machine-readable instructions executable by the processor 510. When the electronic device 500 is running, the processor 510 and the memory 520 communicate through the bus 530. When the machine-readable instructions are executed by the processor 510, the steps of the video file anti-tampering method provided in the above embodiment are executed. For specific implementation methods, please refer to the method embodiment, which will not be repeated here.
[0087] Based on the same concept, this application also provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it executes the steps of the video file anti-tampering method provided in the above embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.
[0088] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and unit can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0089] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0090] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0091] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0092] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0093] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0094] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the technical scope disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.
Claims
1. A method for preventing tampering with video files, characterized in that, The method includes: Generate an asymmetric key pair for the video file to be processed; Each video frame of the video file to be processed is numbered according to time sequence, and key data is extracted from the encoded data of each video frame according to the encoding type of each video frame. For any of the video frames, a chain hash digest of the video frame is calculated based on the video frame number, the encoded data length of the video frame, the key data of the video frame, and the chain hash digest of the previous video frame. The chain hash digest of the video frame is encrypted based on the private key in the asymmetric key pair, and the encryption result is embedded into the video frame to obtain a tamper-proof video frame. Based on each of the tamper-proof video frames and the public key of the asymmetric key pair, a tamper-proof video file is generated.
2. The video file anti-tampering method according to claim 1, characterized in that, The step of extracting key data from the encoded data of each video frame according to the encoding type of each video frame includes: If the encoding type of the video frame is a keyframe, then data of a first preset length is extracted from the starting position of the encoded data of the video frame as key data. If the encoding type of the video frame is a non-key frame, then data of a second preset length is extracted from the starting position of the encoded data of the video frame as key data; wherein, the first preset length is greater than the second preset length.
3. The video file anti-tampering method according to claim 1, characterized in that, The calculation of the chained hash digest of the video frame based on the video frame number, the encoded data length of the video frame, the key data of the video frame, and the chained hash digest of the previous video frame includes: The video frame number, the encoded data length, the key data, and the chained hash digest of the previous video frame are combined into a data block to be processed in a predetermined order. A hash algorithm is performed on the data block to be processed to generate a chained hash digest of the video frame.
4. The video file anti-tampering method according to claim 1, characterized in that, The step of embedding the encryption result into the video frame to obtain the tamper-proof video frame includes: The encryption result is encapsulated into a data unit that conforms to the video encoding format; The data unit is appended to the encoded data of the video frame to obtain the tamper-proof video frame.
5. The video file anti-tampering method according to claim 1, characterized in that, When the video frame is the first frame of the video file to be processed in time sequence, the chain hash digest of the previous video frame is a preset initial value.
6. The video file anti-tampering method according to claim 1, characterized in that, The method further includes: Obtain the tamper-proof processed video file as the video file to be verified, and obtain the public key of the video file to be verified; For each video frame of the video file to be verified, a first chain hash digest of the video frame to be verified is calculated based on the video frame number, the encoded data length of the video frame to be verified, the key data of the video frame to be verified, and the chain hash digest of the previous video frame to be verified. Extract the encryption result of the video frame to be verified from the video frame to be verified, and decrypt the encryption result of the video frame to be verified using the public key of the video file to be verified, to obtain the second chain hash digest of the video frame to be verified. The video frame to be verified is checked for tampering based on the first chained hash digest and the second chained hash digest.
7. The video file anti-tampering method according to claim 6, characterized in that, The method further includes: Obtain the private key verification information corresponding to the video file to be verified, recorded by the publisher's system; The public key of the video file to be verified is paired with the private key verification information to confirm the publication source of the video file to be verified.
8. A video file anti-tampering device, characterized in that, The video file anti-tampering device includes: The key generation module is used to generate asymmetric key pairs for the video files to be processed; The data extraction module is used to number each video frame of the video file to be processed according to the time sequence, and extract key data from the encoded data of each video frame according to the encoding type of each video frame. The digest generation module is used to calculate the chain hash digest of any video frame based on the video frame number, the encoded data length of the video frame, the key data of the video frame, and the chain hash digest of the previous video frame. The data encryption module is used to encrypt the chain hash digest of the video frame based on the private key in the asymmetric key pair, and embed the encryption result into the video frame to obtain a tamper-proof video frame. The file generation module is used to generate tamper-proof video files based on each of the tamper-proof video frames and the public key of the asymmetric key pair.
9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the video file anti-tampering method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, performs the steps of the video file anti-tampering method as described in any one of claims 1 to 7.