An online playing content tamper-proofing method and system based on encryption algorithm

Abstract

The application provides an online playing content anti-tampering method and system based on an encryption algorithm. First, an original content stream to be played is acquired, a unique content identifier is generated according to the binary data distribution mode, and a dynamic encryption key is generated according to a preset rule. The dynamic encryption key is obtained through nonlinear transformation of the identifier and XOR operation with a random number sequence. The original content stream is encrypted in blocks using the dynamic encryption key, and a timestamp mark is added to each block. Integrity check information is generated according to the order of the encrypted content blocks and the timestamp, and is associated with the encrypted stream and stored in a distributed permission chain node with a Byzantine fault tolerance mechanism. When the encrypted stream is received in real time by a playing end, the check information is acquired synchronously. The content block integrity and time sequence consistency are verified through reverse decryption and dynamic hash comparison. If an anomaly is detected, a tampering alarm is triggered, and the online playing content safety is effectively guaranteed.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and more specifically, to a method and system for preventing tampering with online playback content based on encryption algorithms. Background Technology

[0002] In today's era of rapid digital information dissemination, the security and integrity of online content are of paramount importance. With the rapid development of internet technology, various types of online video and audio content are widely distributed; however, this content faces numerous risks of tampering during transmission and storage.

[0003] Currently, existing technologies have certain limitations in ensuring the tamper-proof nature of online content. Some traditional methods rely solely on simple hash algorithms to verify content integrity, but hash algorithms are susceptible to collision attacks, making it difficult to guarantee the authenticity and tamper-proof nature of the content. Moreover, these methods lack the extraction and utilization of deep-level features of content data, failing to accurately identify the original content.

[0004] In terms of key generation, traditional methods often use fixed keys or keys generated based on simple rules, resulting in low security, vulnerability to cracking, and an inability to adapt to complex and ever-changing network environments and increasing security demands. In data storage and transmission, some technologies do not adequately consider data reliability and consistency. Ordinary storage methods are susceptible to single points of failure; if a storage node malfunctions, data loss or corruption may occur. Furthermore, data integrity is difficult to guarantee when facing interference from malicious nodes. In addition, existing technologies are insufficient in content timing verification, failing to effectively detect whether the order of content blocks has been altered and unable to promptly identify content tampering caused by timing discrepancies. Summary of the Invention

[0005] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a method for preventing tampering of online playback content based on an encryption algorithm, the method comprising:

[0006] The original content stream to be played is obtained, and a unique content identifier is generated based on the binary data distribution pattern of the original content stream. The unique content identifier is used to characterize the data form characteristics of the original content stream.

[0007] A dynamic encryption key is generated based on the unique content identifier and a preset key generation rule. The generation process of the dynamic encryption key includes performing a nonlinear transformation on the unique content identifier and performing an XOR operation with a random number sequence.

[0008] The original content stream is divided into blocks and encrypted based on the dynamic encryption key to generate an encrypted content stream, and a timestamp is added to each content block during the encryption process.

[0009] Integrity verification information is generated based on the sequential arrangement and timestamp of the encrypted content blocks, and the integrity verification information is associated with the encrypted content stream and stored in a distributed blockchain node. The distributed blockchain node is a permissioned blockchain node with Byzantine fault tolerance mechanism.

[0010] When receiving encrypted content streams in real time at the playback end, the associated integrity verification information is obtained synchronously. The integrity and timing consistency of the content blocks are verified by reverse decryption and dynamic hash comparison. When a hash conflict or timestamp anomaly is detected, a content tampering alarm is triggered.

[0011] In another aspect, embodiments of the present invention also provide an online playback content anti-tampering system based on an encryption algorithm, including a processor and a machine-readable storage medium connected to the processor. The machine-readable storage medium is used to store programs, instructions, or code, and the processor is used to execute the programs, instructions, or code in the machine-readable storage medium to implement the above-described method.

[0012] Based on the above, this application's embodiments generate unique content identifiers based on the binary data distribution pattern of the original content stream. These unique content identifiers undergo nonlinear transformation and are XORed with a random number sequence. This effectively avoids the problem of easily cracked keys generated by traditional fixed keys or simple algorithms. The nonlinear transformation increases the complexity and unpredictability of key generation, while the random number sequence further enhances the randomness of the key. This ensures that each generated dynamic encryption key has extremely high security and uniqueness, not only improving encryption strength and preventing easy decryption and tampering of encrypted content, but also allowing the dynamic keys generated based on different original content to adapt to diverse security needs in different playback scenarios, enhancing the versatility and adaptability of the entire anti-tampering scheme. Block encryption of the original content stream, coupled with timestamps and distributed blockchain node storage, achieves dual protection of content integrity and temporal consistency. Block encryption improves encryption efficiency and security; the independent encryption of each content block ensures that even if some data is tampered with, it can be detected promptly. The timestamps provide a clear record of the content block's temporal sequence, which, combined with integrity verification information, forms a comprehensive content status recording system. The distributed blockchain nodes employ permissioned chain nodes with Byzantine fault tolerance, ensuring not only decentralized and tamper-proof data storage but also data reliability and consistency even in the face of partial node failures or malicious attacks. This addresses security risks during the transmission and storage of online content, significantly enhancing content credibility and tamper resistance. At the playback end, the system simultaneously acquires associated integrity verification information upon receiving the encrypted content stream. Reverse decryption and dynamic hash comparison verify the integrity and temporal consistency of content blocks, achieving efficient and accurate content verification. The combination of dynamic hash comparison and timestamp verification quickly detects any hash conflicts or timestamp anomalies, promptly triggering content tampering alerts. This real-time verification mechanism, closely integrated with the overall encryption and storage system, forms a closed-loop anti-tampering system, providing comprehensive protection throughout the entire lifecycle of content creation, transmission, storage, and playback. This effectively prevents online content from being tampered with at any stage, providing users with a safe and reliable playback environment and comprehensively improving the security and reliability of online content. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of the execution flow of the online playback content anti-tampering method based on encryption algorithm provided in the embodiments of the present invention.

[0014] Figure 2 This is a schematic diagram of exemplary hardware and software components of an online playback content anti-tampering system based on encryption algorithms provided in an embodiment of the present invention. Detailed Implementation

[0015] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating a method for preventing tampering with online playback content based on an encryption algorithm, according to an embodiment of the present invention. The following is a detailed description of this method.

[0016] Step S110: Obtain the original content stream to be played, and generate a unique content identifier based on the binary data distribution pattern of the original content stream. The unique content identifier is used to characterize the data form characteristics of the original content stream.

[0017] In this embodiment, a video stream is used as the original content stream to be played as an example. For this video stream, a unique content identifier is generated according to a prescribed method. Specifically, the video stream consists of a series of data frames. First, the metadata of each data frame is extracted, such as the resolution, frame rate, color encoding, and other related metadata information. For example, the data frame resolution is 1920x1080, the frame rate is 60fps, and the color encoding is RGB24-bit. For this metadata information, the statistical mean and variance are calculated on a preset dimension. Assuming that on the resolution dimension, the mean is (1920+1080) / 2 = 1500 (this is just a simple example calculation method), and the variance is a value obtained according to a specific calculation method. Then, these mean and variance are input into a preset hash function, such as the SHA-256 hash function, to obtain the initial hash value. The obtained initial hash value is assumed to be a string of hexadecimal characters.

[0018] Next, the initial hash value can be processed using a cyclic shift method, such as shifting each byte 3 bits to the left (this is just an example shift amount), to obtain the initial hash value after the cyclic shift. Then, the binary sequence of the first N data blocks is extracted from the video stream, assuming N is 10 data blocks based on the video stream length. Each data block has a certain byte length, and it is divided into high-order and low-order segments according to the parity of the bytes. For example, if the binary sequence of a data block is 11010101, then the odd-numbered bits 1100 are the high-order segments, and the even-numbered bits 1011 are the low-order segments. The high-order and low-order segments are XORed separately to generate an intermediate identifier code. Assuming the XOR result of the high-order segment is 1010 and the XOR result of the low-order segment is 0101, the concatenated intermediate identifier code is 10100101. Finally, this intermediate identifier code is concatenated with the initial hash value after the cyclic shift to obtain the concatenated data. The concatenated data is then subjected to a second hash operation, for example, using the MD5 hash function. The output of the second hash operation is truncated into a fixed-length string, such as a 16-character string. This string is the unique content identifier, which can uniquely represent the data format characteristics of the video stream, including metadata-related characteristics and the binary distribution characteristics of some data blocks.

[0019] Step S120: Generate a dynamic encryption key according to the unique content identifier and the preset key generation rules, wherein the generation process of the dynamic encryption key includes performing a nonlinear transformation on the unique content identifier and performing an XOR operation with a random number sequence.

[0020] Continuing with the example of the unique content identifier generated from the video stream, firstly, a random number sequence of the same length as the unique content identifier is generated. Assuming the unique content identifier is 16 characters, the random number sequence will also consist of 16 random numbers. This random number sequence can then be divided into multiple sub-sequences, for example, four sub-sequences of length 4. For the unique content identifier, a non-linear transformation is performed to convert each character into an ASCII code value. Assuming one character in the unique content identifier is 'A', its ASCII code value is 65. The converted ASCII code value is then XORed with the corresponding sub-sequence to generate the initial key base value. For example, if the sub-sequence is 1234, an XOR operation (bitwise XOR) with 65 is performed to obtain a portion of the initial key base value. The millisecond-precision value of the current system timestamp is obtained, for example, 1609324567890 milliseconds. This value is converted to binary format and then embedded into a specified position in the initial key base value, such as bits 5-12 (this is just an example position), resulting in the initial key base value after embedding the timestamp. Next, the hardware fingerprint information of the playback device is collected. For a video playback device, the processor serial number is assumed to be 123456789, the motherboard identifier is ABCDEFGHI, and the network card MAC address is 00-11-22-33-44-55. These raw hardware identifier sets are then de-identified by removing preset sensitive fields, such as the last three digits of the MAC address, to generate a standardized device feature summary value.

[0021] Then, the standardized device feature digest value is input into a collision-resistant hash function, such as the SHA-384 hash function, and multiple rounds of byte padding and bit extension operations are performed to generate a fixed-length hash digest value. Assume this hash digest value is a 32-byte hexadecimal string. The hash digest value is converted to a binary sequence format and divided into multiple consecutive first binary segments according to a preset bit width. Assuming a bit width of 8 bits, it is divided into multiple 8-bit binary segments. The complete byte data of the initial key base value after the embedded timestamp is extracted, converted to a binary sequence format, and divided into second binary segments equal in number to the first binary segments. Each first binary segment and its corresponding second binary segment are cyclically shifted left according to a shift step parameter. After each shift, a logical AND operation is performed on the corresponding bit values ​​to generate a convolution intermediate result sequence. All convolution intermediate result sequences are concatenated sequentially into a global binary stream. Parity bit removal and byte boundary alignment are performed on the global binary stream to generate intermediate key data. Finally, the intermediate key data undergoes byte substitution and row shifting, for example, according to the byte substitution table and row shifting rules in the AES encryption algorithm, to generate the final dynamic encryption key. This final dynamic encryption key is then fragmented and stored on multiple secure storage nodes, such as three different server nodes, with each server node storing a portion of the key fragments.

[0022] Step S130: Based on the dynamic encryption key, the original content stream is divided into blocks for encryption to generate an encrypted content stream, and a timestamp is added to each content block during the encryption process.

[0023] Continuing with the video stream example above, the video stream is first divided into multiple content blocks of equal length according to a preset segmentation strategy. Assuming the total length of the video stream is 10,000 bytes, and each content block is 1,000 bytes, it will be divided into 10 content blocks. For each content block, padding bytes are inserted at the end to ensure its length meets the requirements of the encryption algorithm. For example, the AES encryption algorithm requires the content block length to be a multiple of 128 bits (16 bytes). If the original length of the content block is insufficient, padding bytes are added. An independent initialization vector is generated for each content block. The initialization vector can be randomly generated 16 bytes of data. The initialization vector is XORed with the leading part of the dynamic encryption key to generate the block encryption seed. Assuming the leading part of the dynamic encryption key is 16 bytes and the initialization vector is 010101010101010101010101010101, the block encryption seed is obtained after the XOR operation. Then, a symmetric encryption algorithm based on a block cipher seed is used to encrypt the content blocks. Taking AES as an example, the block cipher seed is used as the initialization parameter for the cipher feedback mode, and the last byte of the ciphertext of the previous content block is used as the feedback parameter for the current content block. For example, when encrypting the first content block, since there is no last byte of the ciphertext from the previous content block, a preset initial value is used; subsequent content blocks use the last byte of the encrypted previous content block. After encryption, the block cipher seed, initialization vector, and ciphertext data of each content block are concatenated into triplets. For example, if the block cipher seed is 16 bytes, the initialization vector is 16 bytes, and the ciphertext data is 1000 bytes, they are concatenated sequentially. A header containing the content block sequence number and a millisecond-level timestamp is appended to the beginning of the concatenated triplets. Assuming the content block sequence number is 1 and the timestamp is 1609324567890 milliseconds, this information is combined into a header and appended to the beginning. After obtaining all encrypted content blocks, during the sequential reassembly of these blocks, the block encryption seeds of each content block are extracted at a preset ratio to form a seed verification chain. Assuming the extraction ratio is 10%, one seed is extracted from every 10 block encryption seeds to form the seed verification chain. This seed verification chain is then XORed with a global checksum and appended to the end of the reconstructed data stream. The global checksum can be a checksum calculated from all relevant data in the entire video stream. Thus, during the decryption verification phase, the block encryption seeds can be used to reconstruct the encryption feedback chain and perform reverse verification with the initialization vector data from the integrity verification information obtained from the blockchain.

[0024] Step S140: Generate integrity verification information according to the sequential arrangement and timestamp of the encrypted content blocks, and associate the integrity verification information with the encrypted content stream and store it in a distributed blockchain node. The distributed blockchain node is a permissioned blockchain node with Byzantine fault tolerance mechanism.

[0025] For the encrypted video content blocks mentioned above, the process begins by traversing each encrypted content block. First, the timestamp of each encrypted content block is extracted and its sequence number is combined to form a basic verification tuple. For example, the timestamp of the first encrypted content block is 1609324567890 milliseconds, and its sequence number is 1, forming the basic verification tuple (1, 1609324567890). This basic verification tuple can then be serialized, for example, converted into a byte stream of a specified format. Next, the hash value of this basic verification tuple based on the dynamic encryption key is calculated using the previously generated dynamic encryption key. Assume the resulting hash value is a string of hexadecimal characters. This hash value is then concatenated with the ciphertext data of the corresponding encrypted content block to generate a local verification unit. For example, the hash value is concatenated with 1000 bytes of ciphertext data. All local verification units are arranged sequentially. The Merkle tree root hash value of all local verification units is calculated. A Merkle tree is a hash-based data structure that calculates the root hash value through layer-by-layer hash calculations. Assume the obtained Merkle root hash value is a 32-byte hexadecimal character. This Merkle root hash value is combined with a global checksum, which is a checksum previously calculated for the entire video stream. The combined data is then packaged together with the metadata of the encrypted content stream, which may include information such as the video stream's format and duration. This package is then written to a distributed ledger across multiple blockchain nodes via a smart contract. These blockchain nodes are permissioned blockchain nodes with Byzantine fault tolerance. For example, there are five such blockchain nodes, each storing the data, and the consistency and correctness of the data are ensured among the blockchain nodes through Byzantine fault tolerance.

[0026] Step S150: When receiving the encrypted content stream in real time at the playback end, the associated integrity verification information is obtained synchronously. The integrity and timing consistency of the content block are verified by reverse decryption and dynamic hash comparison. When a hash conflict or timestamp anomaly is detected, a content tampering alarm is triggered.

[0027] In detail, when playing the encrypted video stream at the playback end, upon receiving the encrypted content stream, the initialization vector and ciphertext data of each content block are parsed in real time, and the timestamp and content block sequence number are separated. For example, upon receiving the first encrypted content block, the parsed data includes a 16-byte initialization vector, 1000 bytes of ciphertext data, a timestamp of 1609324567890 milliseconds, and a content block sequence number of 1. The fragments of the dynamically encrypted key stored on the secure nodes are then used for reassembly. Fragments are retrieved from the three server nodes where the key fragments were previously stored and reassembled to obtain the complete dynamically encrypted key.

[0028] Then, a reverse decryption operation is performed on each content block, decrypting it according to the reverse encryption process to generate a temporary plaintext data block. Based on the decrypted temporary plaintext data block, the keyed hash value is recalculated using the previous dynamic encryption key and the same calculation method. This keyed hash value is then compared item by item with the local verification units stored in the blockchain to determine if any hash collisions exist.

[0029] For example, the hash value of a local verification unit stored in the blockchain, which is a string of hexadecimal characters, is compared with the recalculated hash value. If they are not equal, a hash collision occurs. Simultaneously, the difference in timestamps between adjacent content blocks is checked to see if it falls within a preset threshold range. Assuming the preset threshold is 500 milliseconds, if the difference in timestamps between adjacent content blocks exceeds this threshold, a timestamp jump anomaly is detected. Furthermore, the continuity and non-repetition of content block sequence numbers are verified; if sequence number breaks occur, the error is detected.

[0030] When a mismatch is detected between the key hash value and the local verification unit stored in the blockchain, an anomaly in timestamp transition, or a broken sequence number, the playback process is interrupted and a tampering alert data packet containing an anomaly location marker is sent to the monitoring node. For example, if the problem occurs in the second content block, a tampering alert data packet containing information such as "second content block is abnormal" is sent to the monitoring node for further processing, such as investigating the source of the tampering and taking remedial measures.

[0031] Based on the above steps, this embodiment generates a unique content identifier based on the binary data distribution pattern of the original content stream. This unique content identifier undergoes a non-linear transformation and is XORed with a random number sequence. This effectively avoids the problem of easily cracked keys generated by traditional fixed keys or simple algorithms. The non-linear transformation increases the complexity and unpredictability of key generation, while the random number sequence further enhances the randomness of the key. This ensures that each generated dynamic encryption key has extremely high security and uniqueness, not only improving encryption strength and preventing easy decryption and tampering of encrypted content, but also allowing the dynamic keys generated based on different original content to adapt to diverse security needs in different playback scenarios, thus enhancing the versatility and adaptability of the entire anti-tampering scheme. Block encryption of the original content stream, coupled with timestamps and distributed blockchain node storage, achieves dual protection of content integrity and temporal consistency. Block encryption improves encryption efficiency and security; the independent encryption of each content block ensures that even if some data is tampered with, it can be detected promptly. The timestamps provide a clear record of the content block's temporal sequence, which, combined with integrity verification information, forms a comprehensive content status recording system. The distributed blockchain nodes employ permissioned chain nodes with Byzantine fault tolerance, ensuring not only decentralized and tamper-proof data storage but also data reliability and consistency even in the face of partial node failures or malicious attacks. This addresses security risks during the transmission and storage of online content, significantly enhancing content credibility and tamper resistance. At the playback end, the system simultaneously acquires associated integrity verification information upon receiving the encrypted content stream. Reverse decryption and dynamic hash comparison verify the integrity and temporal consistency of content blocks, achieving efficient and accurate content verification. The combination of dynamic hash comparison and timestamp verification quickly detects any hash conflicts or timestamp anomalies, promptly triggering content tampering alerts. This real-time verification mechanism, closely integrated with the overall encryption and storage system, forms a closed-loop anti-tampering system, providing comprehensive protection throughout the entire lifecycle of content creation, transmission, storage, and playback. This effectively prevents online content from being tampered with at any stage, providing users with a safe and reliable playback environment and comprehensively improving the security and reliability of online content.

[0032] In one possible implementation, step S110 includes:

[0033] Step S111: Extract the metadata of each data frame in the original content stream, and calculate the statistical mean and variance of the metadata on a preset dimension.

[0034] In detail, the video stream mentioned earlier consists of numerous data frames. First, the metadata of each data frame is extracted. Taking a single data frame as an example, its metadata includes information such as resolution, frame rate, and encoding format. Assume a data frame has a resolution of 1920x1080, a frame rate of 25fps, and an encoding format of H.264. The statistical mean and variance are calculated along a preset dimension. For example, for the resolution dimension, the width (1920) and height (1080) are added together and then divided by 2 to obtain a mean of 1500 (this is just a simplified calculation illustration). The variance is then calculated using the variance calculation method to obtain a variance value.

[0035] Step S112: Input the statistical mean and variance into a preset hash function to generate an initial hash value, and perform a diffusion process based on cyclic displacement on the initial hash value to obtain the initial hash value after diffusion processing.

[0036] In detail, the statistical mean and variance of the metadata calculated above across various preset dimensions are input into a preset hash function, such as the SHA-256 hash function. The hash function calculates an initial hash value, which is a hexadecimal character sequence of a set length. Then, this initial hash value undergoes a cyclic shift-based diffusion process, assuming each byte is cyclically shifted 2 bits to the left (this is just an example). This process yields the diffused initial hash value.

[0037] Step S113: Extract the binary sequence of the first N data blocks in the original content stream, and divide it into high-order segments and low-order segments according to byte parity, where N is a positive integer dynamically adjusted according to the length of the content stream.

[0038] Since the video stream length is fixed, N is dynamically adjusted based on this length and can be flexibly designed. For example, if the video stream length is 16 units, and N is half the video stream length, i.e., N = 8, then the first 8 data blocks are extracted. Each data block has a corresponding binary sequence, such as 1010110011010011. The binary sequence of each data block is divided into high-order and low-order segments according to byte parity. For example, in the above binary sequence, the odd-numbered bits 101101 are the high-order segments, and the even-numbered bits 011001 are the low-order segments.

[0039] Step S114: Perform an XOR operation on the high-order segment and the low-order segment respectively to generate an intermediate identifier code, and then concatenate the intermediate identifier code with the initial hash value after diffusion processing to obtain the concatenated data.

[0040] Step S115: Perform a second hash operation on the concatenated data, and truncate the output of the second hash operation into a fixed-length string as the unique content identifier.

[0041] For example, for the high-order segment 101101 and the low-order segment 011001 of the first data block, a part of the intermediate identifier code is obtained by bitwise XOR. The results calculated from all data blocks are combined to form the intermediate identifier code. Finally, this intermediate identifier code is concatenated with the initial hash value after diffusion processing to obtain the concatenated data. A secondary hash operation is performed on this concatenated data, such as using the MD5 hash function. The output of the secondary hash operation is truncated into a fixed-length string, assuming it is truncated to a string of 20 characters. This string is the unique content identifier, which can uniquely represent the characteristics of the video stream in terms of data format, including metadata-related characteristics and some characteristics related to the binary distribution of data blocks.

[0042] In one possible implementation, step S120 includes:

[0043] Step S121: Generate a random number sequence with the same length as the unique content identifier, and divide the random number sequence into multiple sub-sequence segments.

[0044] Step S122: Perform a nonlinear transformation on the unique content identifier to convert each character of the unique content identifier into an ASCII code value, and perform an XOR operation with the corresponding sub-sequence segment to generate an initial key base value.

[0045] Step S123: Obtain the millisecond-precision value of the current system timestamp, convert the millisecond-precision value into binary format, and embed it into the specified position of the initial key base value to obtain the initial key base value after embedding the timestamp.

[0046] Step S124: Extract the hardware fingerprint information of the playback device, calculate the hash digest of the hardware fingerprint information, and perform a circular convolution operation between the hash digest and the initial key base value after embedding the timestamp.

[0047] Step S125: Perform byte substitution and row shifting on the result of the circular convolution operation to generate the final dynamic encryption key, and store the key fragments of the final dynamic encryption key to multiple secure storage nodes.

[0048] Taking the generated unique content identifier as an example, since it is a string of a set length, a random number sequence of the same length as the unique content identifier is generated. Assuming the unique content identifier is 20 characters, the random number sequence will be 20 random numbers. This random number sequence is then divided into multiple sub-sequences, for example, five sub-sequences of length 4. A non-linear transformation is performed on the unique content identifier, specifically converting each character of the unique content identifier to its ASCII code value. For example, the character 'A' in the unique content identifier has an ASCII code value of 65. The converted ASCII code value is then XORed with the corresponding sub-sequence. For example, if a sub-sequence is 1234, it is XORed with 65 (bitwise XOR) to obtain a portion of the initial key base value. The final initial key base value is obtained by processing all characters.

[0049] Obtain the current system timestamp with millisecond precision, assuming the value is 1609324567890 milliseconds. Convert this value to binary format, for example, to a binary number of a specified length. Then, embed this binary system timestamp value into a specified position in the initial key base value, assuming it is embedded into the 8th bit starting from the 3rd bit (this is just an example position), thus obtaining the initial key base value after embedding the timestamp.

[0050] For devices playing videos, their hardware fingerprint information is extracted, including the processor serial number, motherboard identifier, and network card MAC address. Assuming the processor serial number is 123456789, the motherboard identifier is ABCDEFGHI, and the network card MAC address is 00-11-22-33-44-55, the original hardware identifier set is first de-identified by removing preset sensitive fields, such as the last three digits of the MAC address, generating a standardized device feature digest value. This device feature digest value is then input into a collision-resistant hash function, such as the SHA-384 hash function, performing multiple rounds of byte padding and bit extension operations to generate a fixed-length hash digest value, assuming it is a 32-byte hexadecimal character sequence. This hash digest value is then converted to a binary sequence format and divided into multiple consecutive binary segments according to a preset bit width; assuming a bit width of 8 bits, it is divided into multiple 8-bit binary segments. The complete byte data of the initial key base value embedded with a timestamp is extracted, converted to a binary sequence format, and divided into binary segments equal in number to the number of binary segments in the hardware fingerprint hash digest. The binary segment of each hardware fingerprint hash digest and the corresponding binary segment of the initial key base value are cyclically shifted left according to a preset shift step parameter. After each shift, a logical AND operation is performed on the corresponding bit values ​​to obtain a convolutional intermediate result sequence. All convolutional intermediate result sequences are concatenated sequentially into a global binary stream. Parity bit removal and byte boundary alignment are performed on this global binary stream to obtain intermediate key data. Finally, byte substitution and row shifting are performed on this intermediate key data, for example, according to the byte substitution table and row shifting rules in the AES encryption algorithm, to generate the final dynamic encryption key. The key fragments of this final dynamic encryption key are stored on multiple secure storage nodes, such as three different server nodes, with each node storing a portion of the key fragments to improve security.

[0051] In one possible implementation, step S130 includes:

[0052] Step S131: Divide the original content stream into multiple content blocks of equal length according to a preset block division strategy, and insert padding bytes at the end of each content block to make the length of the content block meet the requirements of the encryption algorithm.

[0053] In this embodiment, for the aforementioned video stream, it is assumed that the preset segmentation strategy divides the video stream into content blocks of 1000 bytes each. The video stream has a certain byte length, and it is divided into multiple content blocks of equal length according to this segmentation strategy. Since encryption algorithms (such as AES encryption) have requirements on the length of content blocks, which must be a specified length (e.g., a multiple of 128 bits, or 16 bytes), padding bytes are inserted at the end of each content block. For example, if a content block is originally 900 bytes long, which is 6 bytes short of a multiple of 16 bytes, 6 bytes of padding bytes are inserted at the end to ensure that the length of the content block meets the encryption algorithm's requirements.

[0054] Step S132: Generate an independent initialization vector for each content block, and perform an XOR operation between the initialization vector and the leading part of the dynamic encryption key to generate a block encryption seed.

[0055] The initialization vector is a randomly generated data set of a predetermined length, let's say 16 bytes. For example, the initialization vector generated for the first content block might be 010101010101010101010101010101. The initialization vector is then XORed with the leading part of the dynamic encryption key to generate the block encryption seed. Assuming the leading part of the dynamic encryption key is 16 bytes, for example, 111111111111111111111111111111111, a bitwise XOR operation is performed between this key and the initialization vector 0101010101010101010101010101010101; the result is the block encryption seed.

[0056] Step S133: The content block is encrypted using a symmetric encryption algorithm based on the block encryption seed, wherein the block encryption seed is used as the initialization parameter of the ciphertext feedback mode, and the last byte of the ciphertext of the previous content block is used as the feedback parameter of the current content block and input into the encryption algorithm.

[0057] Taking the AES encryption algorithm as an example, the block encryption seed is used as the initialization parameter for the cipher feedback mode. When encrypting the first content block, since there is no ciphertext ending byte from the previous content block, a preset initial value may be used (this initial value is set according to the encryption algorithm's specifications). When encrypting the second content block, the ciphertext ending byte from the first content block is used as the feedback parameter for the current content block (i.e., the second content block) and input into the encryption algorithm, and so on, encrypting each content block.

[0058] Step S134: After encryption is completed, the block encryption seed, initialization vector and ciphertext data of each content block are concatenated into a triplet, and a marker header containing the content block number and millisecond-level timestamp is appended to the head of the triplet concatenation data to obtain all encrypted content blocks.

[0059] For each content block, its block encryption seed, initialization vector, and ciphertext data are concatenated into a triplet. For example, a content block might have a 16-byte block encryption seed, a 16-byte initialization vector, and 1000 bytes of ciphertext data, which are concatenated in sequence. A header containing the content block sequence number and a millisecond-level timestamp is appended to the beginning of the triplet concatenation. Assuming the first content block has a sequence number of 1 and a timestamp of 1609324567890 milliseconds, this information is combined into a header and appended to the beginning. This process is repeated for all content blocks to obtain all encrypted content blocks.

[0060] In step S135, when sequentially reassembling all encrypted content blocks, the block encryption seeds of each content block are extracted according to a preset ratio to form a seed verification chain. This seed verification chain is then XORed with the global verification code and appended to the end of the reassembled data stream. Specifically, the block encryption seeds are used in the decryption verification phase to reconstruct the encryption feedback chain and are used for reverse verification with the initialization vector data in the integrity verification information obtained from the blockchain.

[0061] Assuming a preset ratio of 10%, one block encryption seed is extracted from every 10 content blocks to form a seed verification chain. For example, with 100 content blocks, 10 block encryption seeds are extracted. A global checksum exists, calculated from all relevant data in the video stream using a predefined method. The extracted seed verification chain and the global checksum are XORed and fused, and the result is appended to the end of the reconstructed data stream. During the decryption verification phase, the block encryption seed can be used to reconstruct the encryption feedback chain and can be used for reverse verification with the initialization vector data in the integrity verification information obtained from the blockchain. For example, during decryption, the initialization vector data in the integrity verification information obtained from the blockchain, combined with the block encryption seed, is used to verify the integrity of the content blocks and the correctness of the encryption process.

[0062] In one possible implementation, step S140 includes:

[0063] Step S141: Traverse each encrypted content block and extract the timestamp of the encrypted content block and the content block sequence number to form a basic verification tuple.

[0064] In this embodiment, for the encrypted content blocks of the video stream that have undergone block encryption processing, taking the first encrypted content block as an example, its timestamp and content block number are extracted to form a basic verification tuple. The timestamp is 1609324567890 milliseconds, and the content block number is 1, so the basic verification tuple is (1, 1609324567890). This process is repeated for each encrypted content block to obtain the corresponding basic verification tuple.

[0065] Step S142: Serialize the basic verification tuple and calculate the keyed hash value of the basic verification tuple based on the dynamic encryption key.

[0066] Serialization converts the basic checksum tuple into a byte stream according to specific rules. This includes arranging content block numbers and timestamps in a specific byte order and performing corresponding encoding conversions based on data type to ensure data consistency and accuracy during subsequent computation and storage. After serialization, a keyed hash value based on the dynamic encryption key is calculated for the basic checksum tuple. This is done using the previously generated dynamic encryption key and a specific hash algorithm (e.g., HMAC-SHA256). The serialized checksum data and the dynamic encryption key are used as input, and the hash algorithm calculates a keyed hash value, which is a hexadecimal character sequence of a specific length.

[0067] Step S143: Concatenate the key hash value with the ciphertext data of the corresponding encrypted content block to generate a local verification unit, and arrange all local verification units in order.

[0068] Taking the first encrypted content block as an example, assuming its ciphertext data is 1000 bytes and its key hash value is a 32-byte hexadecimal character sequence, these two parts of data are concatenated together in order to form a local verification unit. The same operation is performed on each encrypted content block to obtain all local verification units, and all local verification units are arranged according to the order of the encrypted content blocks.

[0069] Step S144: Calculate the Merkle root hash value of all local verification units, combine the Merkle root hash value with the global check code, package the combined data together with the metadata of the encrypted content stream, and write it to the distributed ledger of multiple blockchain nodes through a smart contract.

[0070] A Merkle tree is a hash-based data structure. When constructing a Merkle tree, each local check unit is treated as a leaf node. Starting from the leaf node, the hash value is calculated upwards. For example, for every two adjacent local check units, their data is concatenated, and then the hash value is calculated to obtain the hash value of the parent node. This process is repeated until the hash value of the root node is calculated. The hash value of the root node is the Merkle tree root hash value, which is a hexadecimal character sequence of a specific length. A global checksum is also present, which is a checksum obtained from the previously processed data across the entire video stream using a specific calculation method. The Merkle tree root hash value and the global checksum are combined, for example, by concatenating them in a specific order.

[0071] Finally, the combined data is packaged together with the metadata of the encrypted content stream. This metadata includes information such as the video stream format (e.g., H.264), duration (assumed to be 120 minutes), and resolution (1920x1080). This information, along with the previously combined data, is packaged into a data block according to a specific format. A smart contract then writes this packaged data block to the distributed ledger of multiple blockchain nodes. These blockchain nodes are permissioned blockchain nodes with Byzantine fault tolerance; for example, there are five such nodes. Each node receives the data block and stores and manages it according to the blockchain mechanism, ensuring data consistency, integrity, and security. In subsequent verification processes, integrity verification information can be obtained from these distributed ledgers to verify the integrity and correctness of the encrypted content stream.

[0072] In one possible implementation, step S150 includes:

[0073] Step S151: When receiving the encrypted content stream at the playback end, the initialization vector and ciphertext data of each content block are parsed in real time, and the timestamp mark and content block sequence number are separated.

[0074] Taking the first received content block as an example, the playback device accurately parses out the initialization vector and ciphertext data of that content block. Assuming the initialization vector is 16 bytes, such as 0101010101010101010101010101, the ciphertext data is 1000 bytes. Simultaneously, a timestamp and a content block sequence number are extracted from the content block; here, the timestamp is 1609324567890 milliseconds, and the content block sequence number is 1. This process is repeated for each received content block.

[0075] Step S152: Use the dynamic encryption key stored in the secure node to fragment and reassemble, and perform reverse decryption operation on each content block to generate temporary plaintext data blocks.

[0076] Previously, the dynamic encryption key was fragmented and stored across multiple secure nodes, such as three different server nodes. The playback device retrieved key fragments from these server nodes and reassembled them according to predetermined rules to obtain the complete dynamic encryption key. This complete dynamic encryption key was then used to perform a reverse decryption operation on each content block. For the first content block parsed earlier, the dynamic encryption key, initialization vector, and ciphertext data were used to perform reverse calculations, following the reverse process of an encryption algorithm (such as AES), to generate a temporary plaintext data block. This temporary plaintext data block represents the initial decryption result and indicates a possible portion of the original video stream.

[0077] Step S153: Recalculate the keyed hash value based on the decrypted temporary plaintext data block, and compare the keyed hash value with the local verification units stored in the blockchain item by item to determine whether there is a hash collision.

[0078] For example, using the same hash algorithm as before at the encryption end (e.g., HMAC-SHA256), a new keyed hash value is calculated by taking the temporary plaintext data block and the dynamic encryption key as input. This keyed hash value is a hexadecimal character sequence of a specific length. This recalculated keyed hash value is then compared item by item with the local checksums stored in the blockchain. The local checksum corresponding to the content block is retrieved from the blockchain. Assuming the keyed hash value in the local checksum stored in the blockchain is another hexadecimal character sequence of a specific length, the two are compared bit by bit. If any bit is different, a hash collision is identified.

[0079] Step S154: Detect whether the timestamp difference between adjacent content blocks is within the preset condition threshold range, and verify the continuity and non-repetition of the content block sequence number to determine whether there is an abnormal timestamp jump or a sequence number break.

[0080] Taking the first and second content blocks as examples, the timestamp of the first content block is 1609324567890 milliseconds, and the timestamp of the second content block is 1609324568000 milliseconds. Assuming the preset threshold range is 500 milliseconds, the difference between the two timestamps is calculated to be 110 milliseconds, which is within the threshold range. Simultaneously, the continuity and non-repetition of the content block sequence numbers are verified. The first content block has a sequence number of 1, and the second content block has a sequence number of 2. The sequence numbers of each content block are verified sequentially according to the receiving order to ensure they are continuous and non-repetitive. If the timestamp difference between adjacent content blocks exceeds the preset threshold range, it is determined that there is a timestamp jump anomaly; if the content block sequence numbers are discontinuous or repetitive, it is determined that there is a sequence number break.

[0081] Step S155: When it is detected that the hash value with key does not match the local verification unit stored in the blockchain, there is a timestamp jump abnormality, or there is a sequence number break, the playback process is interrupted and a tampering alarm data packet containing an abnormal position marker is sent to the monitoring node.

[0082] For example, if an anomaly is detected when verifying the second content block, the tampering alert data packet will contain location marker information such as "an anomaly has occurred in the second content block". This tampering alert data packet will be sent to the monitoring node. After receiving the data packet, the monitoring node can take further measures based on the information in it, such as investigating the source of the tampering and notifying relevant parties.

[0083] In one possible implementation, the method further includes:

[0084] Step S210: Record the location information and anomaly type of the abnormal content block detected when the content tampering alarm is triggered, and generate a security event log containing timestamps, device identifiers and anomaly characteristics.

[0085] For example, when playing a video stream, if a tampering alert is detected for the third content block, the location information of the abnormal content block is "the third content block". The anomaly type could be a hash collision or a timestamp jump anomaly; let's assume it's a hash collision anomaly. The timestamp is 1609324568000 milliseconds (corresponding to the timestamp of the third content block), and the device identifier is a specific identifier of the playback device, such as the device's serial number 123456789, motherboard identifier ABCDEFGHI, network card MAC address 00-11-22-33-44-55, etc., processed identification information. The anomaly characteristic is a hash value mismatch. This information is combined to generate a security event log, which records detailed information about this tampering event for subsequent analysis and tracing.

[0086] Step S220: Obtain the corresponding content block of the original encrypted content stream from the backup storage node and perform hash consistency verification to confirm the specific stage where the tampering occurred.

[0087] The backup storage node stores a copy of the original encrypted content stream, from which the original encrypted content block corresponding to the third content block is retrieved. Assuming the ciphertext data of this original encrypted content block is 1000 bytes, its hash value is first calculated using the same hash algorithm (e.g., SHA-256) used in the encryption process, resulting in a hexadecimal character sequence of a specific length as the original hash value. This original hash value is then compared with the hash value in the corresponding local verification unit retrieved from the blockchain during tamper detection. If the two are not equal, it can be confirmed that tampering occurred during the transmission or storage of this content block, thus pinpointing the specific point of tampering as the operation related to this content block.

[0088] Step S230: Activate the emergency playback strategy, replace the tampered part with pre-generated secure cache content, and display a content integrity warning on the user interface.

[0089] The pre-generated security cache content is prepared in advance to deal with this tampering scenario. Assuming this security cache content is for a portion of the video stream content in the third content block, replacing the tampered content of the third content block with this security cache content allows the video stream to continue playing. Simultaneously, a content integrity warning is displayed on the user interface, for example, a pop-up message appears on the video playback screen stating, "Video content integrity has been affected; some content has been replaced. Please be aware," informing the user that a content integrity issue has occurred during video playback.

[0090] Step S240: Encrypt the relevant data of the tampering event and synchronize it to all blockchain nodes, update the global blacklist record and trigger the smart contract execution penalty mechanism.

[0091] The data related to the tampering event includes the location information, anomaly type, timestamp, and device identifier of the abnormal content block. This information is encrypted using a specific encryption algorithm (such as AES), resulting in encrypted data. This encrypted data is then synchronized to all blockchain nodes, such as the five permissioned blockchain nodes with Byzantine fault tolerance mentioned earlier. Simultaneously, the global blacklist is updated. If the tampering was caused by a specific device or source, the relevant identifier is added to the global blacklist to prevent further malicious operations. Furthermore, the smart contract execution penalty mechanism is triggered. The smart contract punishes the parties responsible for the tampering (if identifiable) according to preset rules, such as restricting their access to certain resources or imposing economic penalties.

[0092] Step S250: Perform a self-test on the decryption module of the playback terminal to verify the integrity of the dynamic encryption key and the authentication status of the storage node, and initiate a key rotation request when the preset state is triggered.

[0093] In this embodiment, the decryption module of the playback terminal is responsible for decrypting the encrypted content stream. First, it verifies the integrity of the dynamic encryption key. This is achieved by checking the key's length, format, and partial checksums to ensure the key has not been tampered with or corrupted. For example, it checks if the dynamic encryption key's length is the expected length, performs a preset checksum calculation on a portion of the key's bytes, and compares it with a pre-stored checksum. Simultaneously, it verifies the authentication status of the storage node to ensure that the key fragments obtained from the security node come from a legitimate and authenticated storage node. If, during the verification process, the integrity of the dynamic encryption key is compromised or the authentication status of the storage node is problematic—for example, the key length is incorrect or the authentication identifier of the storage node does not match—a preset state is triggered. At this point, the playback terminal initiates a key rotation request, which is sent to the key management node to request the regeneration of a new dynamic encryption key to ensure the security of subsequent playback.

[0094] In one possible implementation, step S124 includes:

[0095] Step S1241: Collect the original hardware identifier set of the processor serial number, motherboard identifier and network card MAC address of the playback terminal device, perform de-identification processing on the original hardware identifier set, remove preset sensitive fields and generate a standardized device feature summary value.

[0096] Assuming the processor serial number is 123456789, the motherboard identifier is ABCDEFGHI, and the network card MAC address is 00-11-22-33-44-55, this information constitutes the original set of hardware identifiers. This original set of hardware identifiers then undergoes de-identification processing, removing preset sensitive fields to protect device privacy and generating a standardized device feature digest value. For example, the preset sensitive field might be the last three digits of the network card MAC address. After removing these, the remaining processor serial number, motherboard identifier, and the first three digits of the network card MAC address are processed using a specific algorithm to obtain a standardized device feature digest value.

[0097] Step S1242: Input the standardized device feature digest value into the collision-resistant hash function, perform multiple rounds of byte padding and bit extension operations, and generate a fixed-length hash digest value.

[0098] Collision-resistant hash functions can be SHA-384 hash functions. In this process, multiple rounds of byte padding and bit extension operations are performed. Byte padding is to ensure the input data meets the block size requirement of the hash function. For example, if the hash function requires a certain number of bytes for the input data block, and the device feature digest value is less than that number of bytes, byte padding is performed. Bit extension operations expand the data according to the internal rules of the hash function. After multiple rounds of such operations, a fixed-length hash digest value is generated. Assume this hash digest value is a 32-byte hexadecimal character sequence.

[0099] Step S1243: Convert the hash digest value into a binary sequence format, divide it into multiple consecutive first binary segments according to a preset bit width, and generate the displacement step size parameter of the circular convolution based on the bit length of the first binary segments.

[0100] Assuming a preset bit width of 8 bits, the binary sequence is divided into segments of 8 bits each. Simultaneously, the shift step size parameter for the circular convolution is generated based on the bit length of the first binary segment. For example, if the first binary segment is 8 bits, the shift step size parameter might be 2 bits according to a predefined rule (this is just an example based on the predefined rule).

[0101] Step S1244: Extract the complete byte data of the initial key base value after the embedded timestamp, convert the complete byte data into a binary sequence format, and then divide it into a second binary segment with the same number of segments as the first binary segment.

[0102] Assume the initial key base value after embedding the timestamp is a byte data of a specific length, for example, 20 bytes. This complete byte data is converted into a binary sequence format, and then divided into a second binary segment equal in number to the first binary segment.

[0103] Step S1245: Perform a cyclic left shift operation on each first binary segment and the corresponding second binary segment according to the displacement step size parameter. After each shift, perform a logical AND operation on the corresponding values ​​of the two binary segments to generate a convolution intermediate result sequence.

[0104] For example, if the first binary segment is 10101010 and the corresponding second binary segment is 11001100, with a shift step of 2 bits, then circularly shifting the first binary segment left by 2 bits results in 10101010 becoming 10101010 (the circular left shift still leaves the original value; this is just an example). Then, performing a logical AND operation on the corresponding bit values ​​of the two binary segments—10101010 and 11001100—results in 10001000, which is an intermediate convolution result. This process is repeated for each corresponding binary segment to generate a sequence of intermediate convolution results.

[0105] Step S1246: Concatenate all intermediate convolution result sequences in sequence into a global binary stream, perform parity bit removal and byte boundary alignment on the global binary stream, and generate intermediate key data for subsequent byte replacement and row shifting.

[0106] In this embodiment, the global binary stream is formed by sequentially concatenating the intermediate convolutional result sequences. Parity bit removal and byte boundary alignment are performed on this global binary stream. Parity bit removal removes parity bits used for verification purposes, and byte boundary alignment ensures that the data is in the correct byte boundary position during subsequent processing (such as byte substitution and row shifting). After these processes, intermediate key data is generated, which can be used for subsequent byte substitution and row shifting.

[0107] The method further includes:

[0108] Step S310: Bind the device feature digest value to the generation cycle of the dynamic encryption key, and perform dynamic binding verification within each key update cycle.

[0109] Step S320: During the key usage phase, the consistency between the current device feature digest and the key binding value is verified in real time, and a secondary authentication process is triggered when a device replacement is detected.

[0110] Step S330: The device binding information is encrypted and embedded into the header metadata area of ​​the content stream, and a forced matching verification is performed during the decryption process.

[0111] Assuming the dynamic encryption key is generated and updated daily, the binding relationship between the device feature digest value and the newly generated dynamic encryption key is checked every time the key is updated. During key usage, the consistency between the current device feature digest and the key binding value is verified in real time. For example, during video streaming, each time the dynamic encryption key is used for decryption, the consistency between the current device feature digest and the key binding value is checked. If a device change is detected, such as a change in processor serial number or motherboard identifier, a secondary authentication process is triggered. This secondary authentication process may include re-collecting device hardware information, recalculating the hash digest value, and re-performing binding verification.

[0112] Finally, the device binding information is encrypted and embedded into the header metadata area of ​​the content stream, and a mandatory matching verification is performed during the decryption process. Device binding information includes the device feature digest value and the binding relationship between the device and the key. This information is encrypted using a specific encryption algorithm (such as AES encryption) and embedded into the header metadata area of ​​the content stream (such as the previously mentioned video stream). During decryption, the encrypted device binding information is first extracted from the header metadata area of ​​the content stream. After decryption, a mandatory matching verification is performed between this information and the current device feature digest value and key binding relationship of the playback device. If they do not match, the playback content cannot be decrypted normally, thus ensuring the security of the playback content and the legitimacy of the device.

[0113] In one possible implementation, the method further includes:

[0114] Step S410: Insert an independently incrementing counter field at the beginning of each content block of the encrypted content stream. The initial value of the counter field is set according to the last M digits of the generation timestamp of the first content block. Each time the encrypted content block is transmitted to the playback end, the counter field increments by a preset step size to generate a globally monotonically increasing counter sequence, where M is a positive integer greater than 3.

[0115] In this embodiment, the initial value of the counter field is first determined based on the last M digits of the timestamp of the first content block's generation, where M is a positive integer greater than 3; let's assume M is 5. Assuming the timestamp of the first content block's generation is 1609324567890 milliseconds, the last 5 digits, 7890, are taken as the initial value of the counter field. Subsequently, each time an encrypted content block is transmitted to the playback end, the counter field increments by a preset step size, for example, a preset step size of 1, thus generating a globally monotonically increasing counter sequence. For the second content block, the value of its counter field is 7891, for the third content block it is 7892, and so on.

[0116] Step S420: Concatenate the current value of the counter field with the hardware fingerprint hash value of the playback terminal to generate a device binding counter identifier code, and input the device binding counter identifier code into a preset elliptic curve signature algorithm to generate a counter signature data block.

[0117] The hardware fingerprint hash value of the playback device is a fixed-length hash digest value obtained by collecting the processor serial number, motherboard identifier, and network card MAC address of the playback device, and then performing de-identification, hash calculation, and other operations. Assuming this hardware fingerprint hash value is a 32-byte hexadecimal character sequence, it is concatenated with the current value of the counter field (e.g., 7895 for a content block) in a specific order to form a device binding counter identifier. This device binding counter identifier binds the content block to the playback device and associates it with the counter value. Next, this device binding counter identifier is input into a preset elliptic curve signature algorithm to generate a counter signature data block. The elliptic curve signature algorithm, based on specific elliptic curve mathematics principles, uses the device binding counter identifier as input data and generates a counter signature data block of a specific length and format. This counter signature data block contains the signature information of the device binding counter identifier and can be used to verify the integrity and origin of the data.

[0118] Step S430: Concatenate the counter signature data block with the ciphertext data of the corresponding content block to generate an enhanced encrypted content block with signature verification, and write the counter signature data blocks of all enhanced encrypted content blocks into the read-only storage partition of the blockchain in the transmission order.

[0119] Taking a content block as an example, assuming its ciphertext data is 1000 bytes and its counter signature data block is 64 bytes, these two parts are concatenated in sequence to form an enhanced encrypted content block. Then, the counter signature data blocks of all enhanced encrypted content blocks are written to the blockchain's read-only storage partition in transmission order. This read-only storage partition is specifically used to store these signature data blocks for use in subsequent verification processes. Because they are written in transmission order, the order of the signature data blocks corresponding to each content block can be determined based on the writing order.

[0120] Step S440: When decrypting the enhanced encrypted content block at the playback end, the current value of the counter field is extracted and verified to conform to the global monotonically increasing law. The elliptic curve signature parameters are reconstructed according to the device-bound counter identifier code to verify the integrity of the counter signature data block. When a jump, duplication, or signature verification failure is detected in the counter field value, the original counter signature data block is obtained from the read-only storage partition of the blockchain for reverse parsing, the location index of the abnormal content block is located, and a tampering rollback instruction is triggered.

[0121] When decrypting an enhanced encrypted content block at the playback end, the current value of the counter field is first extracted. For a received enhanced encrypted content block, the value of the counter field is extracted from its header, for example, the value 7898. Then, it is verified whether this value conforms to a globally monotonically increasing pattern. It is checked whether this value is 1 greater than the counter field value of the previous received content block (because the preset step size is 1). If so, it conforms to the pattern. Simultaneously, the elliptic curve signature parameters are reconstructed based on the device-bound counter identifier to verify the integrity of the counter signature data block. Following the reverse process of generating the device-bound counter identifier, the device-bound counter identifier is reconstructed from the existing hardware fingerprint hash value at the playback end and the extracted counter field value. Then, the integrity of the counter signature data block is verified using the device-bound counter identifier according to the verification rules of the elliptic curve signature algorithm. If a jump in the counter field value is detected, for example, the value suddenly changes from 7898 to 7890 (not conforming to the monotonically increasing pattern), or the value is repeated, or the signature verification fails (for example, the signature data does not match the recalculated signature), the original counter signature data block is retrieved from the read-only storage partition of the blockchain for reverse parsing. By parsing the original counter signature data block, the location index of the abnormal content block can be located. For example, if during the parsing process it is found that the relationship between a certain signature data block and other data blocks does not conform to expectations, it can be determined that the content block corresponding to that signature data block is an abnormal content block, thereby triggering a tampering rollback instruction.

[0122] Step S450: According to the tampering rollback instruction, obtain the encrypted data of the original content block from the backup storage node to replace the tampered content block, and re-insert the replaced content block into the counter field and update the global monotonically increasing sequence. After the content block replacement is completed, regenerate the device binding counter identifier code and the corresponding counter signature data block based on the updated counter field, and synchronously overwrite the corresponding position of the read-only storage partition of the blockchain with the newly generated counter signature data block.

[0123] The backup storage node stores a copy of the original encrypted content stream. Based on the index of the located abnormal content block, the ciphertext data of the corresponding original content block is retrieved from the backup storage node. Assuming the abnormal content block is the fifth block, its original ciphertext data is retrieved. This original ciphertext data then replaces the tampered content block. The replaced content block is then re-inserted into the counter field, and the global monotonically increasing sequence is updated. Since the replaced content block may change the order of the counter fields, the values ​​of the counter fields need to be readjusted. For example, if the counter field value of the replaced content block was 7902 before the replacement, it is adjusted to 7903 after the replacement (following the global monotonically increasing rule), and the entire global monotonically increasing sequence is updated to ensure that the counter field values ​​of subsequent content blocks are also adjusted accordingly. After the content block replacement is completed, the device-bound counter identifier and the corresponding counter signature data block are regenerated based on the updated counter field. The device-bound counter identifier is then regenerated using the updated counter field value and the hardware fingerprint hash value of the playback terminal, following the previous method. This device-bound counter identifier is then input into the elliptic curve signature algorithm to generate a new counter signature data block. Finally, the newly generated counter signature data block is synchronously overwritten to the corresponding location in the read-only storage partition of the blockchain to ensure that the signature data block stored in the blockchain matches the replaced content block.

[0124] Step S460: Monitor the verification status of the counter field during the decryption process on the playback end in real time. When a preset number of verification failure events occur consecutively, freeze the access permission of the current dynamic encryption key and generate a key reset request to be sent to the key management node. After the key management node receives the key reset request, it generates a new dynamic encryption key fragment based on the original counter sequence stored in the blockchain and the device-bound counter identifier code, and encrypts and transmits the new dynamic encryption key fragment to the secure storage area of ​​the playback end.

[0125] Throughout the decryption process, the counter field value of each content block is continuously checked to ensure it meets requirements, along with the verification result of the corresponding counter signature data block. If a preset number of verification failures occur consecutively, for example, three times, and the counter field verification or signature verification fails for three consecutive content blocks, access to the current dynamic encryption key is frozen. This is to prevent potential malicious attacks or data tampering from further affecting the decryption process. Simultaneously, a key reset request is generated and sent to the key management node. This request contains necessary information, such as the playback device's identification information and the current verification failure details. Upon receiving the key reset request, the key management node generates a new dynamic encryption key fragment based on the original counter sequence stored on the blockchain and the device-bound counter identifier. The original counter sequence stored on the blockchain records the counter value changes of the content block from initial encryption to transmission. Combined with the device-bound counter identifier, this provides sufficient information for generating the new dynamic encryption key fragment. The new dynamic encryption key fragment is then encrypted and transmitted to the secure storage area of ​​the playback device. A specific encryption transmission method is used, such as encrypting the new dynamic encryption key fragment with a different key, to ensure security during transmission.

[0126] Step S470: After loading the new dynamic encryption key fragment on the playback terminal, restart the decryption process and initialize the verification module of the counter field, synchronously clear the historical verification failure records and restore the continuous playback of the content stream.

[0127] In this embodiment, after the new dynamic encryption key fragments are loaded into the secure storage area of ​​the playback terminal, the decryption operation is restarted according to the initial decryption process of the encrypted content stream. Simultaneously, the verification module for the counter field is initialized, previous verification status records are cleared, and preparation is made for re-verification of the counter field. Furthermore, historical verification failure records are simultaneously cleared, removing previously recorded information such as the number of verification failures. This restores the continuous playback of the content stream, allowing normal playback to resume from the point where the problem occurred or from the beginning, ensuring that the video stream playback can continue in a secure and intact state.

[0128] Figure 2 The illustration shows exemplary hardware and software components of an online content anti-tampering system 100 based on encryption algorithms, which can implement the ideas of this application, according to some embodiments of this application. For example, a processor 120 can be used in the online content anti-tampering system 100 based on encryption algorithms and to perform the functions in this application.

[0129] The online content anti-tampering system 100 based on encryption algorithms can be a general-purpose server or a special-purpose server; both can be used to implement the online content anti-tampering method based on encryption algorithms of this application. Although only one server is shown in this application, for convenience, the functions described in this application can be implemented in a distributed manner on multiple similar platforms to balance the load.

[0130] For example, the online content anti-tampering system 100 based on encryption algorithms may include a network port 110 connected to a network, one or more processors 120 for executing program instructions, a communication bus 130, and various forms of storage media 140, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the online content anti-tampering system 100 based on encryption algorithms may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The methods of this application can be implemented according to these program instructions. The online content anti-tampering system 100 based on encryption algorithms also includes an input / output (I / O) interface 150 between the computer and other input / output devices.

[0131] For ease of explanation, only one processor is described in the online content anti-tampering system 100 based on encryption algorithms. However, it should be noted that the online content anti-tampering system 100 based on encryption algorithms in this application may also include multiple processors. Therefore, the steps performed by one processor as described in this application may also be performed jointly or individually by multiple processors. For example, if the processor of the online content anti-tampering system 100 based on encryption algorithms performs steps A and B, it should be understood that steps A and B may also be performed jointly by two different processors or individually by one processor. For example, the first processor performs step A, the second processor performs step B, or the first processor and the second processor jointly perform steps A and B.

[0132] Furthermore, this embodiment of the invention also provides a readable storage medium, wherein computer-executable instructions are preset in the readable storage medium, and when the processor executes the computer-executable instructions, the above-mentioned method for preventing tampering of online playback content based on encryption algorithms is implemented.

[0133] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A method for preventing tampering with online playback content based on an encryption algorithm, characterized in that, The method includes: The original content stream to be played is obtained, and a unique content identifier is generated based on the binary data distribution pattern of the original content stream. The unique content identifier is used to characterize the data form characteristics of the original content stream. A dynamic encryption key is generated based on the unique content identifier and a preset key generation rule. The generation process of the dynamic encryption key includes performing a nonlinear transformation on the unique content identifier and performing an XOR operation with a random number sequence. The original content stream is divided into blocks and encrypted based on the dynamic encryption key to generate an encrypted content stream, and a timestamp is added to each content block during the encryption process. Integrity verification information is generated based on the sequential arrangement and timestamp of the encrypted content blocks, and the integrity verification information is associated with the encrypted content stream and stored in a distributed blockchain node. The distributed blockchain node is a permissioned blockchain node with Byzantine fault tolerance mechanism. When receiving encrypted content streams in real time at the playback end, the associated integrity verification information is obtained synchronously. The integrity and timing consistency of the content blocks are verified by reverse decryption and dynamic hash comparison. When a hash conflict or timestamp anomaly is detected, a content tampering alarm is triggered.

2. The method for preventing tampering of online playback content based on encryption algorithms according to claim 1, characterized in that, The generation of a unique content identifier based on the binary data distribution pattern of the original content stream includes: Extract the metadata of each data frame in the original content stream, and calculate the statistical mean and variance of the metadata on a preset dimension; The statistical mean and variance are input into a preset hash function to generate an initial hash value, and the initial hash value is subjected to a diffusion process based on cyclic displacement to obtain the initial hash value after diffusion processing. Extract the binary sequence of the first N data blocks in the original content stream, and divide it into high-order segments and low-order segments according to byte parity, where N is a positive integer dynamically adjusted according to the length of the content stream; The high-order segment and the low-order segment are XORed and superimposed to generate an intermediate identifier code. The intermediate identifier code is then concatenated with the initial hash value after diffusion processing to obtain the concatenated data. A second hash operation is performed on the concatenated data, and the output of the second hash operation is truncated into a fixed-length string as the unique content identifier.

3. The method for preventing tampering of online playback content based on encryption algorithms according to claim 1, characterized in that, The step of generating a dynamic encryption key based on the unique content identifier and a preset key generation rule includes: Generate a random number sequence with the same length as the unique content identifier, and divide the random number sequence into multiple sub-sequence segments; The unique content identifier is subjected to a non-linear transformation to convert each character of the unique content identifier into an ASCII code value, and then XORed with the corresponding subsequence segment to generate an initial key base value. Obtain the millisecond-precision value of the current system timestamp, convert the millisecond-precision value into binary format, and embed it into the specified position of the initial key base value to obtain the initial key base value after embedding the timestamp; Extract the hardware fingerprint information of the playback device, calculate the hash digest of the hardware fingerprint information, and perform a circular convolution operation on the hash digest and the initial key base value after embedding the timestamp; The result of the circular convolution operation is subjected to byte substitution and row shifting to generate the final dynamic encryption key, and the key fragments of the final dynamic encryption key are stored in multiple secure storage nodes.

4. The method for preventing tampering of online playback content based on encryption algorithms according to claim 1, characterized in that, The step of performing block encryption on the original content stream based on the dynamic encryption key to generate an encrypted content stream, and attaching a timestamp to each content block during the encryption process, includes: The original content stream is divided into multiple content blocks of equal length according to a preset block division strategy, and padding bytes are inserted at the end of each content block to make the length of the content block meet the requirements of the encryption algorithm. A unique initialization vector is generated for each content block, and the initialization vector is XORed with the leading part of the dynamic encryption key to generate a block encryption seed. The content block is encrypted using a symmetric encryption algorithm based on the block encryption seed, wherein the block encryption seed is used as the initialization parameter of the cipher feedback mode, and the last byte of the ciphertext of the previous content block is used as the feedback parameter of the current content block and input into the encryption algorithm. After encryption is completed, the block encryption seed, initialization vector and ciphertext data of each content block are concatenated into triples, and a marker header containing the content block number and millisecond-level timestamp is appended to the head of the concatenated triple data to obtain all encrypted content blocks; When sequentially reassembling all encrypted content blocks, the block encryption seeds of each content block are extracted according to a preset ratio to form a seed verification chain, and the seed verification chain is XORed with the global verification code and then appended to the end of the reassembled data stream; wherein, the block encryption seeds are used to reconstruct the encryption feedback chain during the decryption verification stage, and are used to perform reverse operation verification with the initialization vector data in the integrity verification information obtained from the blockchain.

5. The method for preventing tampering of online playback content based on encryption algorithms according to claim 1, characterized in that, The step of generating integrity verification information based on the sequential arrangement and timestamp of the encrypted content blocks, and associating the integrity verification information with the encrypted content stream and storing it in a distributed blockchain node, includes: Traverse each encrypted content block and extract the timestamp of the encrypted content block and the content block number to form a basic verification tuple; The basic verification tuple is serialized, and the keyed hash value of the basic verification tuple based on the dynamic encryption key is calculated. The key hash value is concatenated with the ciphertext data of the corresponding encrypted content block to generate a local verification unit, and all local verification units are arranged in order. The Merkle root hash value of all local verification units is calculated, and the Merkle root hash value is combined with the global check code. The combined data is then packaged together with the metadata of the encrypted content stream and written to the distributed ledger of multiple blockchain nodes through a smart contract.

6. The method for preventing tampering of online playback content based on encryption algorithms according to claim 1, characterized in that, When receiving the encrypted content stream in real time at the playback end, the associated integrity verification information is obtained synchronously, and the integrity and temporal consistency of the content blocks are verified by reverse decryption and dynamic hash comparison, including: When receiving encrypted content streams at the playback end, the initialization vector and ciphertext data of each content block are parsed in real time, and the timestamp and content block sequence number are separated. The data is reassembled using the dynamically encrypted key stored on the secure node, and each content block is decrypted in reverse to generate a temporary plaintext data block. The keyed hash value is recalculated based on the decrypted temporary plaintext data block, and the keyed hash value is compared with the local verification units stored in the blockchain item by item to determine whether there is a hash collision. Detect whether the timestamp difference between adjacent content blocks is within a preset threshold range, and verify the continuity and non-repetition of content block sequence numbers to determine whether there are timestamp jump anomalies or sequence number breaks. When it is detected that the hash value with key does not match the local verification unit stored in the blockchain, there is an abnormal timestamp jump, or there is a broken sequence number, the playback process is interrupted and a tampering alarm data packet containing an abnormal position marker is sent to the monitoring node.

7. The method for preventing tampering of online playback content based on encryption algorithms according to claim 6, characterized in that, The method further includes: Record the location information and anomaly type of the abnormal content block detected when the content tampering alarm is triggered, and generate a security event log containing timestamps, device identifiers and anomaly characteristics; Retrieve the corresponding content blocks of the original encrypted content stream from the backup storage node and perform hash consistency verification to confirm the specific step in which the tampering occurred; Activate the emergency playback strategy, replace the tampered part with pre-generated secure cache content, and display a content integrity warning in the user interface; The data related to the tampering incident is encrypted and synchronized to all blockchain nodes, the global blacklist record is updated, and the smart contract execution penalty mechanism is triggered. The decryption module on the playback end performs a self-check to verify the integrity of the dynamic encryption key and the authentication status of the storage node, and initiates a key rotation request when a preset state is triggered.

8. The method for preventing tampering of online playback content based on encryption algorithms according to claim 3, characterized in that, The steps include extracting the hardware fingerprint information of the playback device, calculating the hash digest of the hardware fingerprint information, and performing a circular convolution operation between the hash digest and the initial key base value embedded with a timestamp, including: Collect the original hardware identifier set of the processor serial number, motherboard identifier and network card MAC address of the playback terminal device, perform de-identification processing on the original hardware identifier set, remove preset sensitive fields and generate a standardized device feature summary value; The standardized device feature digest value is input into the collision-resistant hash function, and multiple rounds of byte padding and bit extension operations are performed to generate a fixed-length hash digest value. The hash digest value is converted into a binary sequence format, divided into multiple consecutive first binary segments according to a preset bit width, and the displacement step size parameter of the circular convolution is generated based on the bit length of the first binary segment. Extract the complete byte data of the initial key base value after the embedded timestamp, convert the complete byte data into a binary sequence format, and then divide it into a second binary segment with the same number of segments as the first binary segment; Perform a cyclic left shift operation on each first binary segment and its corresponding second binary segment according to the shift step parameter. After each shift, perform a logical AND operation on the corresponding values ​​of the two binary segments to generate a sequence of intermediate convolution results. All intermediate convolution result sequences are concatenated into a global binary stream in sequence. Parity bit removal and byte boundary alignment are performed on the global binary stream to generate intermediate key data for subsequent byte replacement and row shifting. The method further includes: The device feature digest value is bound to the generation cycle of the dynamic encryption key, and dynamic binding verification is performed in each key update cycle; During the key usage phase, the consistency between the current device feature digest and the key binding value is verified in real time, and a secondary authentication process is triggered when a device replacement is detected. Device binding information is encrypted and embedded into the header metadata area of ​​the content stream, and forced matching verification is performed during the decryption process.

9. The method for preventing tampering of online playback content based on encryption algorithms according to claim 1, characterized in that, The method further includes: An independently incrementing counter field is inserted at the beginning of each content block in the encrypted content stream. The initial value of the counter field is set according to the last M bits of the generation timestamp of the first content block. Each time the encrypted content block is transmitted to the playback end, the counter field increments by a preset step size to generate a globally monotonically increasing counter sequence, where M is a positive integer greater than 3. The current value of the counter field is concatenated with the hardware fingerprint hash value of the playback terminal to generate a device-bound counter identifier code, and the device-bound counter identifier code is input into a preset elliptic curve signature algorithm to generate a counter signature data block. The counter signature data block is concatenated with the ciphertext data of the corresponding content block to generate an enhanced encrypted content block with signature verification, and the counter signature data blocks of all enhanced encrypted content blocks are written into the read-only storage partition of the blockchain in the transmission order. When decrypting the enhanced encrypted content block at the playback end, the current value of the counter field is extracted and verified to conform to the global monotonically increasing law. The elliptic curve signature parameters are reconstructed according to the device-bound counter identifier code to verify the integrity of the counter signature data block. When a jump, duplication, or signature verification failure is detected in the counter field value, the original counter signature data block is obtained from the read-only storage partition of the blockchain for reverse parsing, the location index of the abnormal content block is located, and a tampering rollback instruction is triggered. According to the tampering rollback instruction, the encrypted data of the original content block is obtained from the backup storage node to replace the tampered content block. The replaced content block is then re-inserted into the counter field and the global monotonically increasing sequence is updated. After the content block replacement is completed, the device binding counter identifier code and the corresponding counter signature data block are regenerated based on the updated counter field. The newly generated counter signature data block is then synchronously overwritten to the corresponding position of the read-only storage partition of the blockchain. The system monitors the verification status of the counter field during the decryption process at the playback end in real time. When a preset number of verification failure events occur consecutively, the access permissions of the current dynamic encryption key are frozen and a key reset request is generated and sent to the key management node. After the key management node receives the key reset request, it generates a new dynamic encryption key fragment based on the original counter sequence stored in the blockchain and the device-bound counter identifier code, and encrypts and transmits the new dynamic encryption key fragment to the secure storage area of ​​the playback end. After loading the new dynamic encryption key fragment on the playback terminal, the decryption process is restarted and the verification module of the counter field is initialized. Historical verification failure records are cleared synchronously and the continuous playback of the content stream is restored.

10. A system for preventing tampering with online playback content based on an encryption algorithm, characterized in that, The online playback content anti-tampering system based on encryption algorithm includes a processor and a memory, the memory and the processor are connected, the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to implement the online playback content anti-tampering method based on encryption algorithm as described in any one of claims 1-9.

Images