A media forensics verification method based on ring verification

Abstract

The present application relates to the technical field of digital media forensics, and discloses a media forensics verification method based on ring verification. The method comprises starting a verification process synchronously when media is captured, and generating original verification codes bound to media sources. Verification data packets are embedded in media files, link codes are calculated based on complete files containing the data packets, and a one-way verification chain that cannot be tampered with is formed by link codes of previous and subsequent files. A cryptographic tree structure is constructed based on all link codes in the chain. The method deeply integrates verification information with media files, so that the files themselves become carriers of their authenticity, and any tampering will cause the verification chain to break. The constructed tree structure supports quick positioning and independent verification of any segment in a large number of media files, without the need to traverse the entire linear chain, thereby improving the efficiency and reliability of forensics.

Description

Technical Field

[0001] This invention relates to the field of digital media forensics technology, specifically a media forensics verification method based on ring verification. Background Technology

[0002] Current methods for verifying the authenticity of media data often rely on externally attached digital signatures, digital watermarks, or timestamp-based evidence storage technologies. These methods are typically independent of the media data capture process, performing post-processing after the media file is generated, or storing verification information as a separate file or remote database record. Conventional chain-based verification technologies, such as hash chains or blockchain evidence storage, often associate the media file content with hash values, separating the verification identifier from the media file entity itself. These schemes treat verification data and media content as two independent objects, resulting in insufficient tightness and real-time nature of their association, leaving room for subsequent tampering or replacement. The media file itself and the credentials proving its authenticity are easily separated or altered during storage and transmission, making it difficult to form an inseparable whole of evidence.

[0003] Existing linear verification methods face efficiency bottlenecks when dealing with massive, continuous media streams forensics. When verifying the authenticity of a specific media segment and its position within the complete record, it typically requires starting from a beginning point or checkpoint, calculating and comparing hash values ​​one by one, and performing linear backtracking or sequential verification. This process is time-consuming and computationally resource-intensive, failing to meet the practical needs of quickly locating and instantly verifying any segment in the historical record. Especially in scenarios involving long-duration, multi-file media recordings, the verification latency and high computational overhead limit the practicality and scalability of forensic techniques. Summary of the Invention

[0004] The purpose of this invention is to provide a media forensics verification method based on ring verification to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides a media forensics verification method based on ring verification, the method comprising:

[0006] Construct a closed-loop verification logic structure starting from the media source, and based on this structure, start a dynamic verification process synchronously when the media capture process is started, so as to process media data blocks in real time and generate verification identifiers.

[0007] In the dynamic verification process, an original verification code bound to the initial state of the media source is defined and generated, and the original verification code serves as the starting point of the entire verification chain.

[0008] When generating the first media file, the attribute information of the media source is encapsulated with the original verification code to form the first verification data packet, and the first verification data packet is written into the designated data area of ​​the first media file;

[0009] Calculate the overall characteristics of the first media file after the first verification data packet is written, and use the overall characteristics as the first link code;

[0010] When generating subsequent media files, the link code corresponding to the previous media file is combined with the attribute information of the media source to form the current verification data packet, and then written into the current media file;

[0011] Calculate a new link code for the current media file to which the current verification data packet is written, so that the preceding and following media files form a one-way verification chain through the link code;

[0012] Based on all the link codes in the one-way verification chain, a cryptographic tree structure for fast verification and retrieval is constructed.

[0013] When performing forensic verification on any media file, the authenticity, continuity, and ownership of the media file are verified by extracting and comparing relevant node data in the cryptographic tree structure.

[0014] Preferably, constructing a closed-loop verification logic structure starting from the media source includes:

[0015] Analyze the output logic of the media acquisition device to determine the order rules and timestamp continuity rules for media file generation;

[0016] Based on the aforementioned sequence rules and timestamp continuity rules, a conceptual verification loop is designed that points from the starting media file to the ending media file and then back to the starting media file.

[0017] In the conceptual verification loop, a forward verification data input interface and a backward verification data output interface are preset for each media file.

[0018] Preferably, defining and generating an initial verification code bound to the initial state of the media source includes:

[0019] Collect a set of static attributes of the media source device, wherein the set of static attributes includes at least the device serial number, geographic coordinates, initial time, and encoding format;

[0020] Standardize and concatenate all elements of the static attribute set to generate an initial information string;

[0021] The initial information string is processed using a cryptographic hash function to generate a fixed-length digest value, which is then set as the original verification code.

[0022] Preferably, the step of encapsulating the attribute information of the media source with the original verification code to form the first verification data packet includes:

[0023] Create a structured data container, which contains metadata fields and verification code fields;

[0024] Populate the static attribute set into the metadata fields of the structured data container;

[0025] The original verification code is populated into the verification code field of the structured data container;

[0026] The structured data container that has been filled is serialized and encoded to generate the first verification data packet.

[0027] Preferably, the overall characteristics of the first media file after the calculation is written to the first verification data packet include:

[0028] Read the complete binary content of the first media file that has the first verification data packet embedded in it;

[0029] Perform a cryptographic hash operation on all the binary content to obtain a unique hash value;

[0030] Name the hash value as the first link code and store the first link code in the local verification log.

[0031] Preferably, combining the link code corresponding to the previous media file with the attribute information of the media source includes:

[0032] Retrieve the most recently stored link key from the local verification log and use it as the forward link key;

[0033] Extract the timestamp information of the current media file's generation time from the attribute information of the media source;

[0034] The forward link code and the timestamp information are merged to generate a new combined information string.

[0035] Preferably, calculating the new link code for the current media file to be written into the current verification data packet includes:

[0036] Perform a hash operation on the combined information string to generate a combined verification code;

[0037] The combined verification code and the attribute information of the media source are encapsulated together into the current verification data packet and written into the current media file;

[0038] The complete content of the current media file that has been written to the current verification data packet is hashed to generate a new link code, and the local verification log is updated with the new link code.

[0039] Preferably, constructing a cryptographic tree structure for fast verification and retrieval based on all link codes in the one-way verification chain includes:

[0040] The link codes generated by each media file in the one-way verification chain are used as leaf nodes of the cryptographic tree structure in the order in which the media files are generated.

[0041] Starting from the leaf node, merge the hash values ​​of two adjacent nodes and calculate the hash value of the parent node. Recursively execute this process until a unique root node hash value is generated.

[0042] The root node hash value is used as the final verification anchor for the entire media stream sequence.

[0043] Preferably, the step of verifying the authenticity, continuity, and ownership of the media file by extracting and comparing relevant node data in the cryptographic tree structure includes:

[0044] Extract the verification data packet embedded in the media file to be verified, and parse the media source attribute information and verification code from the verification data packet;

[0045] Locate the leaf node corresponding to the media file to be verified in the cryptographic tree structure and obtain the hash value of the leaf node;

[0046] Calculate the overall hash value of the media file to be verified, and compare the overall hash value with the hash value of the leaf node. If they match, the media file is determined to be genuine; otherwise, the verification is deemed to have failed.

[0047] Based on the cryptographic tree structure, starting from the leaf node, the hash value of the parent node is verified level by level upwards to see if it is correctly generated by merging the hash values ​​of adjacent child nodes and performing a hash operation, until the root node. If all parent node hash values ​​are verified to be correct, the media file is determined to be continuous; otherwise, the verification is determined to have failed.

[0048] Media source attribute information is extracted from the verification data packet and compared with the pre-registered media source attributes. If all attributes match, the media file is determined to belong to the correct entity; otherwise, the verification is deemed to have failed.

[0049] Preferably, the step of standardizing and concatenating all elements of the static attribute set to generate an initial information string includes:

[0050] Perform formatting on each element in the static attribute set to remove redundant characters and unify the data into a preset standardized format;

[0051] All formatted elements are sorted according to a preset attribute order to form an ordered sequence of elements;

[0052] By using a specified delimiter character, all elements in the ordered sequence of elements are concatenated sequentially to generate the final initial information string.

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

[0054] By embedding the verification data packet within the media file and calculating the link code based on the complete file including the data packet, an inseparable, strong binding relationship is established between the verification information and the media file entity. The verification logic is no longer external or parallel, but internalized within the file generation process. Any tampering with the file content, even a single pixel or byte, will cause a change in the overall hash value of the file, invalidating the calculated link code and immediately breaking the subsequent verification chain. Simultaneously, any attempt to tamper with or delete the embedded verification data packet will also be detected because it alters the source data used to calculate the link code. This design makes the file itself the bearer of its authenticity and integrity, achieving self-contained, self-verifying strong integrity protection and eliminating the possibility of the verification information and media file being separated and tampered with.

[0055] By using the link key generated in chained verification as the basic element, a cryptographic tree structure is constructed, transforming linear time-series verification into efficient tree-indexed verification. The introduction of the tree structure eliminates the need for lengthy linear traversals from the starting point of the chain when verifying any single file within a massive media dataset. During verification, only the verification data packet corresponding to the target file, the link key, and the hash values ​​of a few sibling nodes along the path from the root node to a leaf node in the tree structure are required. This allows for rapid verification of whether the file belongs to the original chain and confirms its exact position within the complete sequence through a finite number of hash calculations. This reduces the time complexity and computational overhead of the verification operation, enabling rapid location, independent verification, and continuity proof of any segment in large-scale, long-sequence media data streams. Attached Figure Description

[0056] Figure 1 This is a schematic diagram illustrating the working principle of the media forensics verification method based on ring verification described in this invention.

[0057] Figure 2 A flowchart for constructing the closed-loop verification logic structure;

[0058] Figure 3A flowchart for generating the original verification code;

[0059] Figure 4 Comparison chart of character lengths before and after standardization of static attributes of media source devices;

[0060] Figure 5 A comparison chart showing the time consumption of linear verification and tree verification in media forensics as a function of the number of files. Detailed Implementation

[0061] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] Please see Figure 1 This invention provides a media forensics verification method based on loop verification. The method includes: constructing a closed-loop verification logic structure starting from the media source, and synchronously starting a dynamic verification process when the media capture process starts. This dynamic verification process is responsible for processing media data blocks in real time and generating corresponding verification identifiers. In the dynamic verification process, an initial verification code bound to the initial state of the media source is first generated, which constitutes the starting point of the entire verification chain. When the first media file is generated, the attribute information of the media source is encapsulated with this initial verification code to form the first verification data packet, and written to a designated data area of ​​the first media file. The overall characteristics of the first media file after the first verification data packet is written are calculated, and this overall characteristic is used as the first link code. For each subsequently generated media file, the link code corresponding to the previous media file is combined with the attribute information of the media source to form the current verification data packet and written to the current media file. A new link code is calculated for the current media file that has been written to the current verification data packet, thereby enabling the preceding and following media files to form a unidirectional verification chain through these link codes. Based on all the link codes generated in this one-way verification chain, a cryptographic tree structure for rapid verification and retrieval is further constructed. When forensic verification of any media file is required, the authenticity, continuity, and ownership of the media file can be comprehensively verified by extracting and comparing the relevant node data in this cryptographic tree structure.

[0063] Example 1: See Figure 2The closed-loop verification logic structure is constructed by analyzing the output logic of the media acquisition device. This process requires determining the order rules and timestamp continuity rules for media file generation. Based on the determined order rules and timestamp continuity rules, a conceptual verification loop is designed, pointing from the starting media file to the ending media file and then back to the starting media file. In this conceptual verification loop, a forward verification data input interface and a backward verification data output interface are preset for each media file.

[0064] In practical implementation, the construction of the closed-loop verification logic structure begins with analyzing the output logic of a specific media acquisition device. Analyzing the output logic of the media acquisition device is a prerequisite for determining the media file generation order rule and the timestamp continuity rule. In an example scenario, the media acquisition device is a recorder with video recording capabilities. After starting recording, the recorder generates a series of media files at fixed time intervals or file size thresholds. The output media files follow the naming rule of "device number_serial number_start time.mp4", where the serial number starts from 0001 and increments, and the start time is the Greenwich Mean Time (GMT) at which the media file recording begins. Based on the analysis of the recorder's output logic, the order rule is determined to be that the serial numbers of the media files must be consecutive and monotonically increasing. The timestamp continuity rule is determined to be that the difference between the end timestamp of the previous media file and the start timestamp of the next media file must be less than or equal to a preset tolerance threshold, used to indicate that the recording process has not been interrupted by human intervention. The expression for this timestamp continuity rule is:

[0065] in: This represents the end timestamp of the nth media file. This represents the start timestamp of the (n+1)th media file. This indicates the preset time tolerance threshold.

[0066] In some embodiments, the process of designing a conceptual verification loop based on the determined sequence rules and timestamp continuity rules is as follows: The conceptual verification loop is a logical structure whose starting point is the first media file with sequence number 0001, and whose ending point is the last media file with sequence number N. The conceptual verification loop requires that, starting from the media file with sequence number 0001, each media file points to the next media file with an incrementing sequence number through its backward verification data output interface, until the last media file with sequence number N. The last media file with sequence number N, in turn, is linked back to the first media file with sequence number 0001 through its backward verification data output interface, thus logically forming a closed loop. It can be understood that in the conceptual verification loop, each media file has a pre-defined forward verification data input interface and a backward verification data output interface. The forward verification data input interface is used to receive verification data transmitted from the preceding media file or the initial state of the media source, and the backward verification data output interface is used to output the link code generated by the current media file to the subsequent media files. Optionally, when the media file is the last media file in the proof-of-concept loop, its backward verification data output interface points to the first media file in the proof-of-concept loop, thus completing the logical loop closure.

[0067] In practical implementation, data comparison can clearly demonstrate the verification of the sequence rule. For example, consider a sequence of media files: file A contains sequence number 0005 in its name, file B contains sequence number 0006, and file C contains sequence number 0008. Comparison reveals that the sequence numbers of files B and C are not consecutive, with the media file containing sequence number 0007 missing, violating the sequence rule. Simultaneously, data comparison regarding the timestamp continuity rule shows that file A's end timestamp is 12:00:30, and file B's start timestamp is 12:00:35. With a preset tolerance threshold Δ of 2 seconds, the calculated absolute value of the time difference is 5 seconds. Since 5 seconds exceeds the 2-second tolerance threshold, this violates the timestamp continuity rule, indicating an unexpected recording interval between the generation of files A and B.

[0068] Example 2: See Figure 3The generation process of the original verification code bound to the initial state of the media source is as follows: A set of static attributes of the media source device is collected. This set of static attributes includes at least the device serial number, geographic coordinates, initial time, and encoding format. Each element in the static attribute set is formatted to remove redundant characters and unify the data into a preset standardized format. All formatted elements are sorted according to a preset attribute order to form an ordered sequence. All elements in this ordered sequence are concatenated sequentially using a specified delimiter to generate the final initial information string. A cryptographic hash function is used to operate on this initial information string to generate a fixed-length digest value, which is then set as the original verification code.

[0069] In practice, the generation of the original verification code bound to the initial state of the media source begins with the collection of static attribute sets of the media source device. In an example scenario, the media source device is a recorder of model XC-100. The collected static attribute set specifically includes the following elements: device serial number "SN-2024-00123", geographical coordinates "39.9042,116.4074", initial time "2024-05-20T08:00:00Z", and encoding format "H.264". Performing formatting on each element in the static attribute set is a necessary step in generating a standardized initial information string. Formatting requires removing redundant characters and unifying the data into a preset standardized format. For example, the device serial number "SN-2024-00123" is made free of all possible whitespace characters, the geographic coordinates "39.9042,116.4074" are made into a format with four decimal places and longitude and latitude separated by commas, the initial time "2024-05-20T08:00:00Z" is made into a Coordinated Universal Time format conforming to the ISO 8601 standard, and the encoding format "H.264" is made into a format with uppercase letters connected by periods.

[0070] In some embodiments, all formatted elements are sorted according to a preset attribute order to form an ordered element sequence. The preset attribute order is device serial number, geographic coordinates, initial time, and encoding format. Therefore, the resulting sequence is ["SN-2024-00123", "39.9042,116.4074", "2024-05-20T08:00:00Z", "H.264"]. All elements in the ordered element sequence are then concatenated sequentially using a specified delimiter character, the vertical bar "|", to generate the final initial information string. The generated initial information string is "SN-2024-00123|39.9042,116.4074|2024-05-20T08:00:00Z|H.264". Data comparison clearly demonstrates the importance of formatting and sorting. For example, consider another set of unstandardized static attributes: device serial number "SN-2024-00123", geographic coordinates "39.9042,116.4074", initial time "2024 / 05 / 2008:00:00", and encoding format "h264". Directly concatenating these attributes without standardization might produce the string "SN-2024-00123|39.9042,116.4074|2024 / 05 / 2008:00:00|h264". This string differs from the standardized string in terms of spaces, separators, time format, and capitalization. The process of using a cryptographic hash function to generate a fixed-length digest value from the initial information string can be represented by the following formula:

[0071]

[0072] in: This represents the original verification code. This indicates the selected cryptographic hash function, such as SHA-256. This represents the final generated initial information string. The SHA-256 hash function is used to calculate a 64-bit hexadecimal digest value, such as "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef1234". This digest value is set as the original verification code.

[0073] Optionally, different formatting rules can lead to drastically different initial information strings and thus different original verification codes. If the preset attribute order is changed to encoding format, initial time, geographic coordinates, and device serial number, the generated initial information string will become "H.264|2024-05-20T08:00:00Z|39.9042,116.4074|SN-2024-00123", and its hash calculation result will be completely different. In practice, the generation of the original verification code depends entirely on the standardized concatenation and hash calculation of the static attribute set. Any modification to the content, order, or formatting rules of the static attribute set elements will result in a change to the original verification code.

[0074] See Figure 4 This graph focuses on the core steps of static attribute set formatting. The vertical axis represents the four types of static attributes of the media source device, and the horizontal axis represents the character length of the attribute information. Two types of grayscale bars are used to distinguish the difference in character length between standardized and unstandardized data. The graph visually demonstrates the effect of removing redundant characters and unifying the data format. Through standardization, the character length of the attribute information is more concise and the format is more uniform. This provides a standardized data foundation for subsequently concatenating the initial information string in a preset order and calculating the original verification code of fixed length. It is a visual representation of the data standardization step in the original verification code generation process and also confirms the logic that standardization is a prerequisite for generating a unified initial information string.

[0075] Example 3: The process of encapsulating the media source's attribute information and the original verification code to form the first verification data packet involves creating a structured data container containing metadata fields and a verification code field. A static attribute set is filled into the metadata field of the structured data container, and the original verification code is filled into its verification code field. The filled structured data container is then serialized and encoded to generate the first verification data packet. Calculating the overall characteristics of the first media file after the first verification data packet is written requires reading the entire binary content of the first media file with the embedded verification data packet and performing a cryptographic hash operation on this entire binary content to obtain a unique hash value. This hash value is named the first link code and stored in the local verification log.

[0076] In practice, the process of encapsulating the media source's attribute information and the original verification code to form the first verification data packet begins with creating a structured data container. This structured data container can be designed with a specific data format containing metadata fields and verification code fields, such as JSON, XML, or a custom binary structure. In the example scenario, the structured data container uses JSON format, containing a metadata field object named "metadata" and a verification code field string named "initial_verification_code". The media source's attribute information is a static attribute set, which includes the device serial number, geographic coordinates, initial time, and encoding format. Populating the static attribute set into the structured data container's metadata fields means creating corresponding key-value pairs within the "metadata" field object, for example, {"device_sn":"SN-2024-00123","geo":"39.9042,116.4074","start_time":"2024-05-20T08:00:00Z","codec":"H.264"}. Filling the original verification code into the verification code field of the structured data container means assigning the string value of the original verification code, such as "a1b2c3d4e5f6...", to the "initial_verification_code" field.

[0077] In some embodiments, the filled structured data container is serialized and encoded to generate the first verification data packet. Serialization and encoding is the process of converting the data structure in memory into a byte stream that can be stored or transmitted. Serialization using JSON format generates a compact string, such as {"metadata":{"device_sn":"SN-2024-00123",...},"initial_verification_code":"a1b2c3d4e5f6..."}, which is the first verification data packet. It can be understood that calculating the overall characteristics of the first media file after the first verification data packet is written requires reading all the binary content of the first media file that has the first verification data packet embedded. All binary content includes the video and audio data streams of the media file itself, as well as the serialized bytes of the first verification data packet written to the specified data area. A cryptographic hash operation is performed on all binary content to obtain a unique hash value, which is named the first link code. The process of cryptographic hash operation can be represented as:

[0078]

[0079] in: This represents the first linker code obtained through calculation. This function represents a hash operation performed on the complete binary content of a file. This represents the complete binary content of the first media file after embedding the first verification data packet. The first link code is stored in a local verification log, which can be a separate database table, a log file, or a secure memory area. The storage operation includes recording the value of the first link code, the corresponding media file identifier, and the generation timestamp. Data comparison can demonstrate the determinism of the process. Using different serialization formats to encapsulate the same set of static attributes and the original verification code, or writing the verification data packet to different byte offsets in the media file, will result in different media file... The binary content changes, and then through the function The first link code obtained by calculation The results will be completely different. Optionally, the structured data container design can include a version number field to identify the version of the encapsulation format, and the serialization encoding can optionally include a length prefix or checksum. In practice, cryptographic hashing of the entire binary content ensures that even if a single bit of the media file's main data changes, or the embedded verification data packet is tampered with, the calculated first link code will undergo unpredictable changes.

[0080] Example 4: When generating subsequent media files, the link code corresponding to the previous media file is combined with the attribute information of the media source. This process retrieves the most recently stored link code from the local verification log as the forward link code. The timestamp information of the current media file's generation time is extracted from the media source's attribute information, and the forward link code is merged with this timestamp information to generate a new combined information string. To calculate a new link code for the current media file to be written into the current verification data packet, a hash operation needs to be performed on the combined information string to generate a combined verification code. This combined verification code and the media source's attribute information are encapsulated together into the current verification data packet and written to the current media file. A hash operation is performed on the complete content of the current media file that has been written into the current verification data packet to generate a new link code, and this new link code is used to update the local verification log.

[0081] In practice, when generating subsequent media files, the link key (called the "forward link key") corresponding to the previous media file is combined with the attribute information of the media source. This process begins by retrieving the most recently stored link key from the local verification log as the forward link key. In an example scenario, the media source device continuously records and generates multiple media files. After generating the first media file, the system calculates and stores the link key for that file, denoted as the first link key L1. At this time, the most recently stored link key in the local verification log is L1. When the system starts processing the second media file, it needs to retrieve its forward link key. The most recently stored link key (i.e., the first link key L1) retrieved from the local verification log then becomes the forward link key used to generate the second media file. The timestamp information of the current media file's generation time is extracted from the media source's attribute information. The timestamp information is a Coordinated Universal Time (UTC) string accurate to milliseconds, such as "2024-05-20T08:00:30.500Z". The forward link code L1 is merged with the timestamp information "2024-05-20T08:00:30.500Z" to generate a new combined information string. The merging operation is usually done by string concatenation, for example, "f1e2d3c4b5a6…|2024-05-20T08:00:30.500Z".

[0082] In some embodiments, to calculate a new link code for the current media file to which the current verification data packet is written, a hash operation needs to be performed on the combined information string to generate a combined verification code. The calculation of the combined verification code can be expressed as:

[0083]

[0084] in: This represents the combined verification code generated from the nth media file. This function represents the hash operation performed on the combined information string. This indicates the link code corresponding to the previous media file. This represents the timestamp information indicating the time when the nth media file was generated. This represents the string concatenation operator. Taking the forward link key L1 as "f1e2d3c4b5a6…" and the timestamp "2024-05-20T08:00:30.500Z" as an example, the combined information string is "f1e2d3c4b5a6…|2024-05-20T08:00:30.500Z". Performing a SHA-256 hash operation on this string yields the combined verification code C2. This can be understood as encapsulating the combined verification code along with the media source's attribute information into a current verification data packet and writing it to the current media file. The encapsulation process is similar to the first verification data packet but the content differs. The current verification data packet contains the current media source's attribute information and the calculated combined verification code C2. The encapsulated data is then written to a specified data area of ​​the second media file.

[0085] In practice, a new link code is generated by hashing the complete content of the current media file, which has been written to the current verification data packet, and the local verification log is updated with the new link code. The complete content of the current media file includes its original media data and the newly written current verification data packet containing the combined verification code C2. The calculation process can be described as reading the entire binary byte stream of the second media file, applying a hash function to it, and obtaining a hash value L2, which is the new link code. Updating the local verification log with the new link code L2 means overwriting or appending the most recently stored link code in the local verification log from L1 to L2, preparing for obtaining the forward link code when generating the next media file. Data comparison can clearly show the continuity of the combination process and data changes. Refer to Table 1, which shows the data flow of the combined information string and the generated link code when generating three media files consecutively.

[0086] Table 1: Link Code Calculation Data Flow Table During Continuous Media File Generation

[0087]

[0088] Optionally, the extracted timestamp information can include more granular attributes, such as recording frame rate or scene identifier. The operation of retrieving the most recently stored link code from the local verification log needs to handle the case where the log is empty during the system's first run; in this case, the original verification code should be used as the forward link code. A hash function is performed on the combined information string. Functions that can be used to calculate the overall hash of a file While both use the SHA-256 algorithm, they logically represent different computation stages and inputs. The implementation of the SHA-256 algorithm includes padding and chunking the input data, following a standard algorithmic flow to convert data of arbitrary length into a fixed-length 256-bit hash value. When calculating the combined verification code, the input is a string of combined information formed by concatenating the forward link code and timestamp information. However, when calculating the new link code, the input is the entire byte stream of the current media file, including video data, audio data, and embedded verification data packets. It can be understood that any tampering with the content of the previous media file will affect its link code. Changes to any timestamp generated on the current media file Tampering, or modifying the current media file F after writing the verification data packet. n All modifications will be made through a hash function. and The cascading computation ultimately leads to a mismatch in all subsequent link codes, thus disrupting the continuity of the verification chain.

[0089] Example 5: Constructing a cryptographic tree structure based on all link codes in a one-way verification chain requires using the link codes generated by each media file in the one-way verification chain as leaf nodes of the cryptographic tree structure, in the order in which the media files were generated. Starting from a leaf node, the hash values ​​of two adjacent nodes are merged, and the hash value of the parent node is calculated. This process is recursively executed until a unique root node hash value is generated. This root node hash value is used as the final verification anchor point for the entire media stream sequence. Verification is completed by extracting and comparing the relevant node data in this cryptographic tree structure. Specifically, the verification data packet embedded in the media file to be verified is extracted, and the media source attribute information and verification code are parsed from the verification data packet. The leaf node corresponding to the media file to be verified is located in the cryptographic tree structure, and its hash value is obtained. The overall hash value of the media file to be verified is calculated, and this overall hash value is compared with the leaf node hash values. If they match, the media file is determined to be authentic. Based on a cryptographic tree structure, starting from the leaf nodes, the system verifies each parent node's hash value by merging the hash values ​​of its adjacent child nodes and performing a hash operation, up to the root node. If all parent node hash values ​​are verified correctly, the media files are considered continuous. Media source attribute information is extracted from the verification data packet and compared with pre-registered media source attributes. If all attributes match, the media file is considered to belong to the correct entity.

[0090] In practical implementation, constructing a cryptographic tree structure based on all link codes in the one-way verification chain requires assigning the link codes generated by each media file in the one-way verification chain as leaf nodes of the cryptographic tree structure in the order in which the media files were generated. Assuming an example scenario, the one-way verification chain contains four media files with corresponding link codes M1, M2, M3, and M4, these link codes are assigned as the four leaf nodes of the cryptographic tree structure in the order they were generated. Starting from the leaf nodes, the hash values ​​of adjacent nodes are merged, and the hash value of the parent node is calculated. This process is recursively executed until a unique root node hash value is generated. For a tree with four leaf nodes M1, M2, M3, and M4, the hash values ​​of adjacent leaf nodes M1 and M2 are first merged, and similarly, the hash values ​​of M3 and M4 are merged. The merging operation is typically string concatenation or binary concatenation. Then, a cryptographic hash operation is performed on each merged result to generate the first-level parent node hash values ​​R12 and R34. Next, the hash values ​​of the first-level parent nodes R12 and R34 are merged again and hashed to generate a unique root node hash value, Rroot. The process of generating the parent node hash value can be expressed by the following formula:

[0091] in: Indicates child nodes and The calculated hash value of the parent node, The symbol represents a function that performs a cryptographic hash operation on the merged string. This represents a concatenation operation for strings or binary data. It can be understood that using the root node hash value Rroot as the final verification anchor for the entire media stream sequence means that regardless of the number of media files, the integrity status of the entire sequence can ultimately be represented by this single root node hash value.

[0092] In some embodiments, the authenticity, continuity, and attribution of a media file are verified by extracting and comparing relevant node data in a cryptographic tree structure. The specific process is as follows: Extract the verification data packet embedded in the media file to be verified, and parse the media source attribute information and verification code from the verification data packet. For example, if the second media file in the example needs to be verified, read and parse its verification data packet from a specified data area of ​​the file to obtain the encapsulated device serial number, timestamp attribute information, and combined verification code. Locate the leaf node corresponding to the media file to be verified in the cryptographic tree structure and obtain the leaf node hash value. For the second media file, its corresponding leaf node hash value in the tree should be M2. Calculate the overall hash value of the media file to be verified. This calculation process is consistent with the process of generating the link code, that is, read the current complete binary content of the media file and perform the same hash operation. Compare the hash value obtained from the operation with the leaf node hash value M2 obtained from the tree structure. If the two are completely consistent, it is determined that the content of the media file has been authentic and has not been tampered with since its generation; otherwise, the verification fails. Data comparison can clearly demonstrate the verification logic. If the video content of the second media file is modified by one pixel, its overall hash value will change and will inevitably not match the preset leaf node hash value M2.

[0093] In practical implementation, based on a cryptographic tree structure, the hash value of a parent node is verified level by level upwards from the leaf node to ensure it is correctly generated by merging the hash values ​​of adjacent child nodes and performing a hash operation, up to the root node. Taking the aforementioned tree structure as an example, when verifying the second media file, in addition to verifying its leaf node M2, it is also necessary to verify whether its parent node R12 is correctly generated from M1 and M2, i.e., to calculate... Check if it equals the stored R12, then verify if the root node Rroot is correctly generated from R12 and R34, i.e., calculate... Is it equal to the stored Rroot? If all parent node hash values ​​are verified correctly, the path from the leaf node where the file is located to the root node is determined to be complete and continuous, thus ensuring the continuity of the media file in the original sequence. Optionally, if the hash value of any intermediate parent node fails verification, it indicates that the continuity of the media file sequence under that node's branch has been disrupted. Media source attribute information is extracted from the verification data packet and compared with pre-registered media source attributes. The pre-registered media source attributes are the original attribute set recorded in trusted storage by the media source device during initialization. If all attributes extracted from the verification data packet, such as device serial number, initial time, and encoding format, are completely consistent with the pre-registered attributes, the media file is determined to belong correctly and indeed originate from the claimed media source device; otherwise, the verification fails.

[0094] See Figure 5This graph focuses on the core optimization goal, addressing the efficiency bottleneck of linear verification: the horizontal axis represents the number of media files, and the vertical axis represents the verification time. The two curves correspond to the time changes of linear verification and tree-based verification, respectively. The graph visually demonstrates how transforming the high time complexity of linear verification into the efficient index verification of tree-based verification is particularly effective in scenarios with massive amounts of media files. Tree-based verification can significantly reduce time consumption and computational overhead, meeting the practical needs of rapid location and immediate verification.

[0095] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0096] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A media forensics verification method based on ring verification, characterized in that, The method includes: Construct a closed-loop verification logic structure starting from the media source, and based on this structure, start a dynamic verification process synchronously when the media capture process is started, so as to process media data blocks in real time and generate verification identifiers. In the dynamic verification process, an original verification code bound to the initial state of the media source is defined and generated, and the original verification code serves as the starting point of the entire verification chain. When generating the first media file, the attribute information of the media source is encapsulated with the original verification code to form the first verification data packet, and the first verification data packet is written into the designated data area of ​​the first media file; Calculate the overall characteristics of the first media file after the first verification data packet is written, and use the overall characteristics as the first link code; When generating subsequent media files, the link code corresponding to the previous media file is combined with the attribute information of the media source to form the current verification data packet, and then written into the current media file; Calculate a new link code for the current media file to which the current verification data packet is written, so that the preceding and following media files form a one-way verification chain through the link code; Based on all the link codes in the one-way verification chain, a cryptographic tree structure for fast verification and retrieval is constructed, including: The link codes generated by each media file in the one-way verification chain are used as leaf nodes of the cryptographic tree structure in the order in which the media files are generated. Starting from the leaf node, merge the hash values ​​of two adjacent nodes and calculate the hash value of the parent node. Recursively execute this process until a unique root node hash value is generated. The root node hash value is used as the final verification anchor point for the entire media stream sequence; When performing forensic verification on any media file, the authenticity, continuity, and ownership of the media file are verified by extracting and comparing relevant node data in the cryptographic tree structure.

2. The media forensics verification method based on ring verification as described in claim 1, characterized in that, The construction of a closed-loop verification logic structure starting from the media source includes: Analyze the output logic of the media acquisition device to determine the order rules and timestamp continuity rules for media file generation; Based on the aforementioned sequence rules and timestamp continuity rules, a conceptual verification loop is designed that points from the starting media file to the ending media file and then back to the starting media file. In the conceptual verification loop, a forward verification data input interface and a backward verification data output interface are preset for each media file.

3. The media forensics verification method based on ring verification as described in claim 1, characterized in that, The definition and generation of an initial verification code bound to the initial state of the media source includes: Collect a set of static attributes of the media source device, wherein the set of static attributes includes at least the device serial number, geographic coordinates, initial time, and encoding format; Standardize and concatenate all elements of the static attribute set to generate an initial information string; The initial information string is processed using a cryptographic hash function to generate a fixed-length digest value, which is then set as the original verification code.

4. The media forensics verification method based on ring verification as described in claim 3, characterized in that, The step of encapsulating the media source's attribute information with the original verification code to form the first verification data packet includes: Create a structured data container, which contains metadata fields and verification code fields; Populate the static attribute set into the metadata fields of the structured data container; The original verification code is populated into the verification code field of the structured data container; The structured data container that has been filled is serialized and encoded to generate the first verification data packet.

5. The media forensics verification method based on ring verification as described in claim 1, characterized in that, The overall characteristics of the first media file after the first verification data packet is written include: Read the complete binary content of the first media file that has the first verification data packet embedded in it; Perform a cryptographic hash operation on all the binary content to obtain a unique hash value; Name the hash value as the first link code and store the first link code in the local verification log.

6. The media forensics verification method based on ring verification as described in claim 5, characterized in that, The step of combining the link code corresponding to the previous media file with the attribute information of the media source includes: Retrieve the most recently stored link key from the local verification log and use it as the forward link key; Extract the timestamp information of the current media file's generation time from the attribute information of the media source; The forward link code and the timestamp information are merged to generate a new combined information string.

7. The media forensics verification method based on ring verification as described in claim 6, characterized in that, The calculation of the new link code for the current media file to be written to the current verification data packet includes: Perform a hash operation on the combined information string to generate a combined verification code; The combined verification code and the attribute information of the media source are encapsulated together into the current verification data packet and written into the current media file; The complete content of the current media file that has been written to the current verification data packet is hashed to generate a new link code, and the local verification log is updated with the new link code.

8. The media forensics verification method based on ring verification as described in claim 1, characterized in that, The step of verifying the authenticity, continuity, and ownership of the media file by extracting and comparing relevant node data in the cryptographic tree structure includes: Extract the verification data packet embedded in the media file to be verified, and parse the media source attribute information and verification code from the verification data packet; Locate the leaf node corresponding to the media file to be verified in the cryptographic tree structure and obtain the hash value of the leaf node; Calculate the overall hash value of the media file to be verified, and compare the overall hash value with the hash value of the leaf node. If they match, the media file is determined to be genuine; otherwise, the verification is deemed to have failed. Based on the cryptographic tree structure, starting from the leaf node, the hash value of the parent node is verified level by level upwards to see if it is correctly generated by merging the hash values ​​of adjacent child nodes and performing a hash operation, until the root node. If all parent node hash values ​​are verified to be correct, the media file is determined to be continuous; otherwise, the verification is determined to have failed. Media source attribute information is extracted from the verification data packet and compared with the pre-registered media source attributes. If all attributes match, the media file is determined to belong to the correct entity; otherwise, the verification is deemed to have failed.

9. The media forensics verification method based on ring verification as described in claim 3, characterized in that, The step of standardizing and concatenating all elements of the static attribute set to generate an initial information string includes: Perform formatting on each element in the static attribute set to remove redundant characters and unify the data into a preset standardized format; All formatted elements are sorted according to a preset attribute order to form an ordered sequence of elements; By using a specified delimiter character, all elements in the ordered sequence of elements are concatenated sequentially to generate the final initial information string.

Images