An internet content full life cycle publishing management and dynamic maintenance system
Patent Information
- Application Number
- CN202611080402.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-20
- Publication Date
- 2026-10-09
AI Technical Summary
[0007]本发明的目的在于提供一种互联网内容全生命周期发布管理及动态维护系统,以解决现有技术中内容下架无法强制执行、访问控制可被绕过、缺乏细粒度动态权限调度以及缺乏密码学可证明的全生命周期溯源审计等技术问题
实现密码学断言级内容撤回,即便第三方拥有内容密文的完整副本,在系统执行撤回操作后,因内容密钥已从密钥生成中心层面安全擦除且内容标识符已写入默克尔撤回树,任何解密凭证请求均将被密码验证与密钥调度网关拒绝,幽灵副本的内容在语义层面彻底不可访问,从根本上解决了传统内容分发网络缓存时延窗口问题。
Smart Images

Figure CN122891305A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of information security and cryptography technology, and in particular relates to an Internet content full lifecycle publishing management and dynamic maintenance system. Background Technology
[0002] Modern internet content publishing typically employs an architecture of origin server storage and content delivery network (CDN) for accelerated distribution. Content creators upload their content to object storage services. After review by the content management system, the system pushes the content's access address to the CDN for global node caching and distribution. End users then retrieve the content from the nearest CDN node. In this architecture, once the CDN node cache is established, its lifecycle is determined by the CDN's own lifetime policy, rather than being directly controlled by the origin server.
[0003] The existing technology has the following drawbacks: Flaw 1: Content removal commands cannot be enforced, leading to the continuous propagation of "ghost copies." Existing content management systems only modify status fields in the application-layer database for content removal and deletion operations, failing to reach content copies already cached by content distribution network nodes, mirrored on third-party platforms, or stored locally on user terminals. Content distribution network cache refreshes have minute-level latency, and third-party platform mirrors and user terminal local caches are completely unaffected by this request. The root cause is the lack of a strong cryptographic binding between the logical removal status of content and the physical accessibility of content data, preventing status updates from penetrating the distribution network layer.
[0004] Defect 2: Access control relies on front-end application logic, posing a security risk of being bypassed. Traditional systems use cookie verification, token authentication, and database status queries as access control methods. Once the application layer logic has vulnerabilities or is bypassed (such as directly accessing the content delivery network origin address or object storage pre-signed address), access control becomes ineffective, lacking mandatory cryptographic protection. The data itself is stored in plaintext or weakly protected form, and application layer authentication is the only protective barrier. Once this barrier fails, the content is completely exposed.
[0005] Deficiency 3: Lack of fine-grained dynamic permission adjustment capabilities. Existing digital rights management systems (such as Microsoft PlayReady and Google Widevine) use access policies at the user subscription level, failing to recognize the real-time dissemination characteristics of content itself (such as abnormally high-frequency forwarding and cross-border dissemination). When compliance policies change, the system cannot automatically identify the affected content and adjust its access permissions in a timely manner, still requiring manual intervention and failing to meet dynamic compliance requirements.
[0006] Deficiency 4: Lack of traceable, full-lifecycle auditing methods. Existing systems rely on database logs or application-layer logs for recording content operations. These logs are maintained by the platform itself and are susceptible to tampering, failing to provide cryptographically non-repudiable evidence. Furthermore, there is a lack of effective technical means to track the cross-platform evolution of AI-generated content. Summary of the Invention
[0007] The purpose of this invention is to provide an Internet content full lifecycle publishing management and dynamic maintenance system to solve the technical problems in the prior art, such as the inability to enforce content removal, the possibility of bypassing access control, the lack of fine-grained dynamic permission scheduling, and the lack of cryptographically provable full lifecycle traceability and auditing.
[0008] This invention is implemented as follows: an Internet content full lifecycle publishing management and dynamic maintenance system, which includes a content full lifecycle management module, a dynamic attribute perception and strategy engine, a key generation center, a password verification and key scheduling gateway, a Merkel revocation state service, and a lifecycle hash chain service. The content lifecycle management module is used to assign a globally unique content identifier to the content to be published, initialize the content state machine, and coordinate the other modules to perform corresponding operations when the content status changes; the content state machine has a status value of one of the following: draft, under review, published, under compliance review, removed, or destroyed. The dynamic attribute perception and strategy engine is used to continuously collect real-time propagation behavior characteristics of content in a sliding time window manner, calculate the propagation behavior anomaly score, and drive the automatic generation, downgrade update or attribute key revocation of the encrypted access policy based on the comparison result of the score and the preset threshold. The key generation center is used to manage the master key of the ciphertext policy attribute base encryption system, issue private keys carrying attribute sets to users, and destroy the content key using a secure erasure method when a revocation instruction is received. The password verification and key scheduling gateway, as the only interaction entry point between the client and the key system, is used to verify the requester's attribute credentials, the withdrawal status of the query content in the Merkel withdrawal tree, and decide whether to issue a decryption credential to the client. The Merkel retraction state service is used to maintain a Merkel retraction tree covering all retracted content identifiers, update the tree structure when content is retracted, generate a new global state root hash, and broadcast the digitally signed new global state root hash to all cryptographic verification and key scheduling gateway nodes. The lifecycle hash chain service is used to generate chain node snapshots at each key node of the content lifecycle, which include the perceived hash value, lifecycle status, operation timestamp, predecessor node hash digest and operator digital signature, and to anchor adjacent snapshots in a chain to form an immutable audit chain.
[0009] Furthermore, the system also includes a hybrid encrypted content package generation mechanism: after the content lifecycle management module assigns a content identifier to the content, the system randomly generates a 256-bit symmetric content key and uses AES-256-GCM mode to encrypt the original content data to generate ciphertext. The ciphertext contains the ciphertext body, authentication tag, and random initialization vector. The key generation center uses a ciphertext policy attribute base encryption algorithm with the system public key and initial access policy to encrypt the content key, generating a key ciphertext package. The key ciphertext package embeds a complete description of the access policy, and any attribute private key holder that does not meet the policy cannot recover the content key from the key ciphertext package. The system encapsulates the content ciphertext, key ciphertext package, content identifier, and global state root hash at the time of publication into a hybrid encrypted content package, uploads it to object storage, and distributes it to edge nodes via the content distribution network cache. The content exists in ciphertext form throughout the distribution network, and its physical accessibility is determined by the cryptographic control plane, decoupled from the application layer authentication logic.
[0010] Furthermore, the propagation behavior features collected by the dynamic attribute perception and strategy engine include: the number of times the content is forwarded within the sliding time window, the number of newly accessed nodes, the cross-regional diffusion rate, and the number of content variants detected through perception hash comparison; the dynamic attribute perception and strategy engine uses historical baseline data as a reference to calculate the standardized deviation of each feature dimension relative to the baseline mean and baseline standard deviation, multiplies the deviation of each dimension by the corresponding preset weight coefficient, and sums them to obtain a propagation behavior anomaly score with a value range of 0 to 1, and the sum of the weight coefficients of each dimension is 1; when the anomaly score exceeds the warning threshold but does not exceed the revocation threshold, a strategy downgrade operation is performed; when the anomaly score exceeds the revocation threshold, an attribute key revocation operation is performed; the warning threshold is 0.6, and the revocation threshold is 0.85.
[0011] Furthermore, the policy downgrade operation includes: the dynamic attribute awareness and policy engine adds additional restrictions to the original access policy to generate a new downgrade policy; the key generation center uses the new downgrade policy to re-execute the ciphertext policy attribute base encryption to generate a new key ciphertext package, replacing the original key ciphertext package field in the mixed encrypted content package in the object storage; the attribute private key holder who does not meet the new downgrade policy will be denied access by the password verification and key scheduling gateway when requesting decryption credentials again.
[0012] Furthermore, the content-oriented retraction process of the Merkel retraction tree includes: the content lifecycle management module sends a key destruction instruction to the key generation center, and the key generation center completely erases the content key using a secure deletion method involving multiple overwrites; the content lifecycle management module sends a write-to-retraction-tree instruction to the Merkel retraction state service, carrying the content identifier and retraction timestamp; the Merkel retraction state service calculates the leaf node hash value obtained by using the SHA-256 hash algorithm on the concatenated data of the content identifier and the retraction timestamp, inserts it into the Merkel retraction tree, and recalculates the hash values of each intermediate node from bottom to top to the root node, generating a new global state root hash; the Merkel retraction state service concatenates the new global state root hash with the broadcast timestamp, signs it using the ECDSA algorithm, and broadcasts it to all cryptographic verification and key scheduling gateway nodes in the form of a signed state update message; the cryptographic verification and key scheduling gateway updates the locally cached global state root hash after verifying the validity of the signature.
[0013] Furthermore, the password verification and key scheduling gateway's process for verifying the revocation status of a decryption credential request includes: requesting the Merkel revocation status service for a Merkel existence proof path for the target content identifier; using the locally cached global state root hash as a trusted anchor, calculating the hash layer by layer upwards in conjunction with the existence proof path, and verifying whether the calculation result is consistent with the locally cached global state root hash; if consistent, confirming that the content identifier exists in the revocation tree, refusing to issue the decryption credential and returning a revocation status code; the computational complexity of the entire verification process increases logarithmically with the total number of leaf nodes in the revocation tree.
[0014] Furthermore, the global state root hash is broadcast in the form of a state update message with a digital signature. The cryptographic verification and key scheduling gateway updates the locally cached global state root hash only after verifying the validity of the signature upon receiving the broadcast, in order to prevent forged state update attacks.
[0015] Furthermore, the chain node snapshot generation process of the lifecycle hash chain service includes: running a multimodal perceptual hash algorithm on the content data at the current moment to extract the perceptual hash value; taking the SHA-256 digest value of the previous chain node snapshot as the predecessor anchor field, where the predecessor anchor field for the first node is a string of all zero bytes; concatenating the content identifier, perceptual hash value, lifecycle state, operation timestamp, and predecessor anchor field to form the original snapshot data; the party responsible for the operation of the current node using its ECDSA private key to perform a digital signature on the SHA-256 digest of the original snapshot data; encapsulating the original snapshot data and the signature value into a complete chain node snapshot, calculating its SHA-256 digest value, and persistently writing it to immutable storage.
[0016] Furthermore, when the lifecycle hash chain service detects an edit event, it automatically calculates the Hamming distance between the current node's perceived hash value and the predecessor node's perceived hash value. The Hamming distance is defined as the sum of the number of bits with a value of 1 after the two hash values are XORed. If the Hamming distance is greater than the substantial tampering threshold, it is determined that substantial content tampering has occurred, and an early warning notification is sent to the dynamic attribute perception and strategy engine. The dynamic attribute perception and strategy engine then decides whether to trigger the permission scheduling process. The substantial tampering threshold is 10% of the perceived hash bit length.
[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: This achieves cryptographic assertion-level content revocation. Even if a third party possesses a complete copy of the encrypted content, after the system performs the revocation operation, because the content key has been securely erased from the key generation center and the content identifier has been written into the Merkle revocation tree, any decryption credential request will be rejected by the cryptographic verification and key scheduling gateway. The content of the ghost copy is completely inaccessible at the semantic level, fundamentally solving the caching latency window problem of traditional content delivery networks.
[0018] By constructing a cryptographic-level mandatory access control system, the content data is stored in encrypted form on the distribution network. Even if the application layer authentication logic is completely bypassed, the content data remains inaccessible at the cryptographic algorithm level. The access control is independent of and not subject to the front-end application logic layer.
[0019] The system enables adaptive permission scheduling without relying on manual intervention. When abnormal content dissemination behavior is detected, the system can automatically trigger attribute key revocation or policy downgrade to meet dynamic compliance requirements without the need for manual intervention by operations personnel.
[0020] It provides cryptographically provable end-to-end non-repudiation auditing capabilities. Operations at any lifecycle node leave a cryptographic snapshot with a digital signature. Any substantial tampering can be automatically detected by the Hamming distance comparison mechanism, and the responsible party can be uniquely identified by the signing public key of the corresponding node. Attached Figure Description
[0021] Figure 1 This is a schematic diagram of the overall system architecture of the present invention; Figure 2 This is a schematic diagram illustrating the content encryption, packaging, and publishing process. Figure 3 This is a schematic diagram of the dynamic attribute permission scheduling process; Figure 4 A schematic diagram of Merkel's withdrawal tree structure and withdrawal verification process; Figure 5 This is a schematic diagram of the lifecycle hash chain structure; Figure 6 A schematic diagram illustrating the complete process of client decryption credential request and access control. Detailed Implementation
[0022] To further understand the invention's content, features, and effects, the following embodiments are provided, and detailed descriptions are given in conjunction with the accompanying drawings.
[0023] The structure of the present invention will now be described in detail with reference to the accompanying drawings.
[0024] I. System Overall Architecture The Internet content full lifecycle publishing management and dynamic maintenance system proposed in this invention adopts the core architecture concept of separating the data plane and the cryptographic control plane. Without subverting the existing content distribution network and cloud storage infrastructure, it introduces a cryptographic verification and key scheduling gateway as the core control plane to achieve cryptographic level control over the physical accessibility of content.
[0025] The overall system architecture is as follows Figure 1 As shown, it is divided into three layers: the end-user layer, the data layer, and the cryptographic control layer. The end-user layer includes various access terminals such as PC clients, mobile clients, and third-party platform access nodes. The data layer includes the content delivery network edge node group and object storage. The content stored in the content delivery network nodes is presented in a hybrid encrypted ciphertext format. The cryptographic control layer consists of six core functional modules: content lifecycle management module, dynamic attribute awareness and policy engine, key generation center, cryptographic verification and key scheduling gateway, Merkel revocation state service, and lifecycle hash chain service.
[0026] The responsibilities of the six core functional modules are as follows: The content lifecycle management module is responsible for managing the state transition of content from creation to archiving and destruction, maintaining the content's metadata and lifecycle state machine, and the state value can be one of the following enumerated values: draft, under review, published, under compliance review, removed, destroyed, etc.
[0027] The dynamic attribute awareness and strategy engine is responsible for collecting real-time propagation behavior characteristics of content, and combining them with the compliance rule base to dynamically generate or update encrypted access policies based on encrypted policy attributes of the content.
[0028] As the root of trust in the system, the key generation center is responsible for managing the master key of the ciphertext policy attribute-based encryption system, issuing user attribute private keys, and securely erasing the content key when a revocation command is received.
[0029] The password verification and key scheduling gateway serves as the sole interaction point between the client and the key system. It is responsible for verifying the requester's attributes, querying the withdrawal tree status, and deciding whether to issue decryption credentials to the client.
[0030] The Merkel retraction state service is responsible for maintaining the complete state of the Merkel retraction tree, updating the tree structure and broadcasting the new global state root hash to the entire network when content is retracted.
[0031] The Lifecycle Hash Chain Service is responsible for generating cryptographic snapshots and maintaining the hash chain at key nodes in the content lifecycle.
[0032] II. Content Encryption, Packaging, and Publishing Process Content encryption, packaging, and publishing process as follows Figure 2 As shown, before entering the distribution network, content must undergo a hybrid encryption and encapsulation process to bind the physical data of the content to the cryptographic control plane. The specific steps are as follows: The content lifecycle management module assigns a globally unique content identifier to each piece of content to be published. This identifier is a 128-bit UUID string used to uniquely identify the content object globally within the system. Simultaneously, the module initializes the content's state machine, setting the initial state to draft and recording a creation timestamp with millisecond-level precision.
[0033] The content lifecycle management module calls the lifecycle hash chain service to generate the first lifecycle snapshot at the initial node of the content. The lifecycle hash chain service uses the perceptual hash algorithm to extract multimodal feature digests from the original content data, and uses the content owner's private key to digitally sign the concatenated data of the content identifier, perceptual hash value, timestamp and initial state to generate the first chain node snapshot, whose SHA-256 digest value serves as the starting point of the hash chain.
[0034] The content lifecycle management module requests the initial encrypted policy attribute base encryption access policy corresponding to the content identifier from the dynamic attribute awareness and policy engine. The dynamic attribute awareness and policy engine generates an initial access policy tree (e.g., "role is a registered user and region is not a restricted region") based on metadata such as content category tags and target audience, and returns the initial policy to the content lifecycle management module.
[0035] The system randomly generates a 256-bit symmetric content key and uses AES-256-GCM mode to encrypt the original content data, generating ciphertext content. The ciphertext content includes the ciphertext body, authentication tag, and random initialization vector.
[0036] The key generation center uses the ciphertext policy attribute-based encryption algorithm to encrypt the content key with the system public key and the initial access policy tree, generating a key ciphertext package. The key ciphertext package contains a complete description of the access policy, and any attribute private key holder that does not meet the policy cannot recover the content key from the key ciphertext package.
[0037] The system encapsulates the encrypted content, key encrypted package, content identifier, and current global state root hash provided by the Merkel retraction state service into a hybrid encrypted content package. The global state root hash serves as the compliance state anchor point at the time of content publication and is used for subsequent retraction verification.
[0038] The hybrid encrypted content package is uploaded to object storage, with the storage path associated with the content identifier, triggering content delivery network cache preheating, and then distributing the hybrid encrypted content package to edge nodes. At this point, the content exists in encrypted form throughout the distribution network, and its physical accessibility is determined by the cryptographic control plane, decoupled from application-layer authentication logic.
[0039] III. Adaptive Ciphertext Policy Attribute-Based Encryption Permission Scheduling Mechanism Based on Behavior Awareness and Dynamic Compliance The dynamic attribute permission scheduling process is as follows: Figure 3 As shown, the dynamic attribute awareness and policy engine continuously monitors the real-time propagation behavior characteristics of content, and automatically triggers the update of the encrypted policy attribute base encryption policy and the revocation of the attribute key when an anomaly is detected, realizing adaptive permission scheduling without relying on application layer intervention. The specific steps are as follows: The propagation behavior collector uses a 5-minute sliding time window (this duration can be configured by the administrator) to continuously collect content propagation behavior data from various content distribution nodes, social relationship graph interfaces, and third-party platform monitoring interfaces, and extracts the following feature dimensions: the number of forwards within the time window, the number of new access nodes, the cross-regional diffusion rate, and the content variant detection count (the number of content variants detected through perceptual hash comparison), which together constitute the propagation behavior feature vector at the current moment.
[0040] The dynamic attribute awareness and strategy engine uses historical baseline data as a reference to calculate the standardized deviation of each dimension in the feature vector relative to the baseline mean and standard deviation. The deviation of each dimension is multiplied by the corresponding preset weight coefficient and then summed to obtain a propagation behavior anomaly score with a value range of 0 to 1. The larger the value, the more abnormal the propagation behavior. The weights of each dimension are pre-configured by the system administrator according to the compliance policy, and the sum of the weights of each dimension is 1.
[0041] The dynamic attribute awareness and policy engine compares the anomaly score with the warning threshold (value 0.6) and the revocation threshold (value 0.85). If the anomaly score does not exceed the warning threshold, the current propagation behavior is determined to be within the normal range, the current round of scheduling ends, and the next time window begins. If the anomaly score exceeds the warning threshold but does not exceed the revocation threshold, a policy downgrade operation is performed. If the anomaly score exceeds the revocation threshold, an attribute key revocation operation is performed.
[0042] The execution process of the policy downgrade operation is as follows: The dynamic attribute awareness and policy engine adds additional restrictions to the original access policy based on the specific value of the current anomaly score, and generates a new downgrade policy. For example, it adds constraints such as "must meet real-name authentication attributes" or "regional restriction". The dynamic attribute awareness and policy engine sends the new policy to the key generation center. The key generation center uses the new policy to re-execute the ciphertext policy attribute base encryption on the content key, generates a new key ciphertext package, and replaces the original key ciphertext package field in the mixed encrypted content package with the new key ciphertext package, and updates it to the object storage. If the original attribute private key holder does not meet the additional conditions in the new policy, it will be rejected by the password verification and key scheduling gateway when requesting decryption credentials next time, and will not be able to continue to access the content.
[0043] The execution process of attribute key revocation is as follows: The dynamic attribute awareness and policy engine sends an attribute key revocation command for the content identifier to the key generation center. The key generation center first destroys the content key corresponding to the content identifier from the key management library; then it notifies the Merkel revocation state service to write the content identifier into the Merkel revocation tree, triggering the revocation tree update and broadcasting the new global state root hash; after receiving the new global state root hash, the cryptographic verification and key scheduling gateway updates the locally cached state root hash. Afterwards, any decryption credential request for this content identifier will be rejected because the revocation tree query returns a revocation conclusion. Even if the client holds a historically cached key ciphertext packet, because the content key has been destroyed, the cryptographic verification and key scheduling gateway no longer issues valid decryption factors, and the client cannot complete decryption at the cryptographic level.
[0044] IV. Content-oriented retraction mechanism based on Merkel retraction tree Merkel's withdrawal tree structure and withdrawal verification process are as follows: Figure 4 As shown, the Merkel retraction state service maintains a Merkel retraction tree covering all retraction content identifiers, and periodically broadcasts the root node hash (i.e., the global state root hash) to all cryptographic verification and key scheduling gateway nodes to achieve cryptographically verifiable retraction state synchronization across the network. The specific steps are as follows: When the content lifecycle management module receives a targeted withdrawal instruction for a certain content (the source may be manual operation, regulatory department instruction, or automatic triggering by dynamic attribute perception and strategy engine), the content lifecycle management module first updates the status of the content in the state machine to "removed" and records the withdrawal timestamp with millisecond precision. At the same time, it triggers the lifecycle hash chain service to generate a withdrawal event snapshot node on the hash chain.
[0045] The content lifecycle management module sends a key destruction command to the key generation center. The key generation center securely erases the content key from the key management storage using a secure deletion method that involves multiple overwrites, ensuring that the content key is completely unrecoverable from the key generation center level.
[0046] The content lifecycle management module sends a write-to-retraction-tree instruction to the Merkel retraction-state service, carrying the content identifier and retraction timestamp parameters. The Merkel retraction-state service concatenates the content identifier and retraction timestamp, calculates the leaf node hash value using the SHA-256 hash algorithm, and inserts this leaf node hash value into the leaf node level of the Merkel retraction tree. Subsequently, it recalculates the hash values of all intermediate nodes on the affected path from bottom to top until the root node, generating a new global state root hash.
[0047] The Merkel retraction state service concatenates the new global state root hash with the broadcast timestamp, digitally signs the message using its ECDSA signing private key, and broadcasts it as a signed state update message to all cryptographic verification and key dispatch gateway nodes. Upon receiving the broadcast, the cryptographic verification and key dispatch gateway verifies the signature validity before updating its locally cached global state root hash to prevent forged state update attacks.
[0048] When a client requests a content decryption credential from the cryptographic verification and key dispatch gateway, the gateway requests a proof of retraction existence for that content identifier from the Merkel retraction state service. The Merkel retraction state service searches for the corresponding leaf node in the retraction tree. If it exists, it returns a set of hash paths from the leaf node to the root node, i.e., the Merkel proof path, which contains the hash values of sibling nodes at each level along the path from leaf to root.
[0049] The cryptographic verification and key scheduling gateway uses the locally cached global state root hash as a trusted anchor. Combining the Merkel proof path and leaf node hashes, it calculates the hash layer by layer upwards from the leaf nodes, verifying whether the final calculation result equals the locally cached global state root hash. If they are equal, it proves that the content identifier does indeed exist in the revocation tree. The cryptographic verification and key scheduling gateway rejects this decryption credential request and returns a content revocation status code to the client. The computational complexity of the entire verification process increases logarithmically with the total number of leaf nodes in the revocation tree.
[0050] In the event that the cryptographic verification and key dispatch gateway refuses to respond, even if the client holds a complete copy of the hybrid encrypted content package obtained from the content delivery network, it cannot obtain any valid decryption factor from the cryptographic verification and key dispatch gateway, and the original content key has been destroyed at the key generation center level. Therefore, the client cannot perform effective decryption of the ciphertext at the cryptographic level, and the content of the ghost copy is completely inaccessible at the semantic level, achieving a cryptographic assertion-level retraction effect.
[0051] V. Multimodal Content Lifecycle Hash Chain Mechanism Lifecycle hash chain structure as follows Figure 5 As shown, the lifecycle hash chain service generates a cryptographic snapshot with a digital signature and timestamp at each key lifecycle node of the content, and anchors adjacent snapshots in a chain to form an immutable lifecycle hash chain. The specific steps are as follows: At each key event node in the content lifecycle (including but not limited to content creation, content publication, content secondary editing, cross-platform distribution of content, content status change, content withdrawal or destruction), the lifecycle hash chain service triggers the snapshot generation process for the current node.
[0052] The lifecycle hash chain service runs a multimodal perceptual hash algorithm on the current content data to extract the perceptual hash value; if it is a non-data change event such as a state change, the perceptual hash value of the previous version of the content data is used. At the same time, the current lifecycle state and operation timestamp are recorded.
[0053] The lifecycle hash chain service takes the SHA-256 digest value of the snapshot of the previous chain node as the predecessor anchor field (for the first node, the predecessor anchor field is defined as an all-zero byte string), and concatenates it with the content identifier, perceptual hash value, lifecycle status and operation timestamp of the current node to form the original snapshot data of the current node.
[0054] The party responsible for the operation of the current node (the content owner, platform reviewer, or system automation module, depending on the event type) uses its ECDSA private key to perform a digital signature on the SHA-256 digest of the original snapshot data, generating a signature value.
[0055] The original snapshot data and the signature value are encapsulated together into a complete chain node snapshot. The SHA-256 digest value of the node is calculated, and the chain node snapshot and digest value are persistently written to the immutable storage of the lifecycle hash chain service (append-write storage based on log structure).
[0056] In content traceability or compliance audit scenarios, the lifecycle hash chain service provides a traceability verification interface. By sequentially verifying the validity of the signature of each node between any two nodes and verifying the consistency between the predecessor anchor field of each node and the actual hash value of the predecessor node, the verifier can prove that the operation record within that interval has not been tampered with, and the responsible party can be uniquely identified by the signature public key of the corresponding node.
[0057] For substantial tampering detection in secondary editing scenarios: Whenever a new editing event triggers the generation of a chain node, the lifecycle hash chain service automatically calculates the Hamming distance between the current node's perceived hash value and the predecessor node's perceived hash value (i.e., the sum of the number of bits with a value of 1 after the two hash values are XORed). If the Hamming distance is greater than the preset substantial tampering threshold (this threshold is taken as 10% of the perceived hash bit length, for example, the threshold for a 64-bit hash is 6), it is determined that substantial content tampering has occurred. The lifecycle hash chain service sends an early warning notification to the dynamic attribute perception and strategy engine, which then decides whether to trigger the permission scheduling process.
[0058] VI. Complete Process of Client-Side Decryption Credential Request and Access Control The complete process of client decryption credential request and access control is as follows: Figure 6 As shown, the specific steps are as follows: When a user initiates a content access request, the client pulls a hybrid encrypted content package from the edge node of the content delivery network, obtaining the content ciphertext, the key ciphertext package, the content identifier, and the global state root hash at the time of publication.
[0059] The client sends a decryption credential request to the password verification and key scheduling gateway, carrying the content identifier and user attribute credentials. The password verification and key scheduling gateway verifies the validity of the user attribute credentials signature, queries the Merkel withdrawal status service for the withdrawal status of the content identifier, obtains the Merkel proof path, and verifies the validity of the proof path using the locally cached global state root hash. If the verification result shows that the content has been withdrawn, a rejection response and withdrawal status code are returned to the client, and the process terminates.
[0060] If the content is not revoked, the password verification and key scheduling gateway requests a decryption factor from the key generation center. The key generation center verifies whether the user's attribute private key meets the currently effective ciphertext policy attribute-based encryption access policy. If the attribute meets the policy, the key generation center returns the decryption factor, which is the intermediate result obtained by decrypting the key ciphertext packet using the user's attribute private key to perform the ciphertext policy attribute-based encryption part. If the attribute does not meet the policy, it returns insufficient permissions, and the password verification and key scheduling gateway returns an insufficient permissions response to the client.
[0061] The password verification and key scheduling gateway encapsulates the decryption factor into a decryption credential and sends it to the client. The client uses the decryption credential to recover the content key from the key ciphertext packet, and uses the content key to perform AES-256-GCM decryption on the content ciphertext to obtain the content plaintext and present it to the user. The overall process reflects the architectural concept of separating the data plane and the cryptographic control plane. The password verification and key scheduling gateway is always on the only path for the client to obtain the content key.
[0062] VII. Alternative Implementation Methods In an alternative implementation, the ciphertext policy attribute-based encryption can be replaced with a proxy re-encryption mechanism. The content key is encrypted and encapsulated using the content owner's public key. When authorization is required for a specific user, the key generation center uses a proxy re-encryption key to convert the ciphertext from being encrypted with the owner's public key to being encrypted with the user's public key. This conversion process does not expose the plaintext of the content key. When authorization is revoked, the key generation center destroys the proxy re-encryption key, and the user can no longer receive new re-encrypted ciphertext. Combined with the Merkle revocation tree mechanism of this invention, cryptographically provable targeted revocation can also be achieved. This alternative method is particularly suitable for content distribution scenarios with precise point-to-point authorization.
[0063] In another alternative implementation, the centralized key generation center can be replaced by a decentralized key committee built on threshold cryptography, in which multiple independent key nodes jointly hold master key shards. The attribute key issuance operation can be completed only when any number of nodes that meet the threshold cooperate, thereby eliminating single point of failure and single point of trust risk. This is more suitable for multi-platform joint governance scenarios. This alternative method is fully compatible with the Merkle withdrawal tree and lifecycle hash chain mechanism of the present invention.
Claims
1. A system for managing and dynamically maintaining the entire lifecycle of internet content publishing, characterized in that: include: The content lifecycle management module is used to assign a globally unique content identifier to the content to be published, initialize the content state machine, and coordinate the other modules to perform corresponding operations when the content status changes. The state value of the content state machine is one of the following: draft, under review, published, under compliance review, removed, or destroyed. The dynamic attribute awareness and strategy engine is used to continuously collect real-time propagation behavior characteristics of content in a sliding time window manner, calculate the propagation behavior anomaly score, and drive the automatic generation, downgrade update or attribute key revocation of the encrypted access policy based on the comparison result of the score and the preset threshold. The key generation center manages the master key of the ciphertext policy attribute-based encryption system, issues private keys carrying attribute sets to users, and destroys the content key using a secure erasure method when a revocation command is received. The password verification and key dispatch gateway, as the sole interaction point between the client and the key system, is used to verify the requester's attribute credentials, the retraction status of the query content in the Merkel retraction tree, and decide whether to issue decryption credentials to the client. The Merkel retraction state service is used to maintain a Merkel retraction tree covering all retracted content identifiers. When content is retracted, the tree structure is updated, a new global state root hash is generated, and the digitally signed new global state root hash is broadcast to all cryptographic verification and key dispatch gateway nodes. The Lifecycle Hash Chain Service is used to generate chain node snapshots at key nodes in the content lifecycle, which include the perceived hash value, lifecycle status, operation timestamp, predecessor node hash digest, and operator digital signature, and to anchor adjacent snapshots in a chain to form an immutable audit chain.
2. The Internet content full lifecycle publishing management and dynamic maintenance system according to claim 1, characterized in that, The system also includes a hybrid encrypted content packet generation mechanism: After the content lifecycle management module assigns a content identifier to the content, the system randomly generates a 256-bit symmetric content key and uses AES-256-GCM mode to encrypt the original content data to generate content ciphertext. The content ciphertext includes the ciphertext body, authentication tag and random initialization vector. The key generation center uses the ciphertext policy attribute base encryption algorithm to encrypt the content key with the system public key and the initial access policy, generating a key ciphertext package. The key ciphertext package embeds a complete description of the access policy. Any attribute private key holder that does not meet the policy cannot recover the content key from the key ciphertext package. The system encapsulates the encrypted content, key encrypted packet, content identifier, and global state root hash at the time of publication into a hybrid encrypted content packet, uploads it to object storage, and distributes it to edge nodes via the content delivery network cache. The content exists in encrypted form throughout the distribution network, and its physical accessibility is determined by the cryptographic control plane, decoupled from the application layer authentication logic.
3. The Internet content full lifecycle publishing management and dynamic maintenance system according to claim 1, characterized in that, The propagation behavior characteristics collected by the dynamic attribute perception and strategy engine include: the number of times the content is forwarded within the sliding time window, the number of new access nodes, the cross-regional diffusion rate, and the number of content variants detected by perception hash comparison. The dynamic attribute perception and strategy engine uses historical baseline data as a reference to calculate the standardized deviation of each feature dimension relative to the baseline mean and baseline standard deviation. The deviation of each dimension is multiplied by the corresponding preset weight coefficient and then summed to obtain a propagation behavior anomaly score with a value range of 0 to 1. The sum of the weight coefficients of each dimension is 1. When the anomaly score exceeds the warning threshold but does not exceed the revocation threshold, the dynamic attribute perception and policy engine performs a policy downgrade operation. When the anomaly score exceeds the revocation threshold, it performs an attribute key revocation operation. The warning threshold is 0.6, and the revocation threshold is 0.
85.
4. The Internet content full lifecycle publishing management and dynamic maintenance system according to claim 3, characterized in that, The policy downgrade operation includes: The dynamic attribute awareness and strategy engine adds extra restrictions to the original access strategy to generate a new degradation strategy; The key generation center re-executes the ciphertext policy attribute base encryption using the new downgrade strategy to generate a new key ciphertext package, replacing the original key ciphertext package field in the mixed encrypted content package in the object storage. Private key holders whose attributes do not meet the new downgrade policy will be denied access by the password verification and key scheduling gateway on their next request to decrypt credentials.
5. The Internet content full lifecycle publishing management and dynamic maintenance system according to claim 1, characterized in that, The Merkel withdrawal tree content-directed withdrawal process includes: The content lifecycle management module sends a key destruction command to the key generation center, which then uses a secure deletion method involving multiple overwrites to completely erase the content key from the key management storage. The content lifecycle management module sends a write-to-retraction-tree instruction to the Merkel retraction-state service, carrying the content identifier and retraction timestamp. The Merkel retraction-state service calculates the leaf node hash value by using the SHA-256 hash algorithm on the concatenated data of the content identifier and the retraction timestamp, inserts it into the Merkel retraction-tree, and recalculates the hash values of each intermediate node on the affected path from bottom to top to the root node, generating a new global state root hash. Merkel withdraws the state service by concatenating the new global state root hash with the broadcast timestamp, signing it with the ECDSA algorithm, and broadcasting it to all cryptographic verification and key scheduling gateway nodes as a signed state update message. The cryptographic verification and key scheduling gateways only update the locally cached global state root hash after verifying the validity of the signature.
6. The Internet content full lifecycle publishing management and dynamic maintenance system according to claim 5, characterized in that, The process by which the cryptographic verification and key scheduling gateway verifies the withdrawal status of the decryption credential request includes: The cryptographic verification and key scheduling gateway withdraws the state service request to Merkel for the Merkel existence proof path for the target content identifier, the Merkel existence proof path containing an ordered set of the hash values of each sibling node on the path from the leaf node to the root node; The cryptographic verification and key scheduling gateway uses the locally cached global state root hash as a trusted anchor point, and calculates the hash layer by layer upwards in combination with the existence proof path to verify whether the calculation result is consistent with the locally cached global state root hash. If they match, the content identifier is confirmed to exist in the withdrawal tree, the decryption credential is refused to be issued, and a withdrawal status code is returned; the computational complexity of the entire verification process increases logarithmically with the total number of leaf nodes in the withdrawal tree.
7. The Internet content full lifecycle publishing management and dynamic maintenance system according to claim 1, characterized in that, The chain node snapshot generation process of the lifecycle hash chain service includes: Run a multimodal perceptual hash algorithm on the current content data to extract the perceptual hash value; Take the SHA-256 digest value of the snapshot of the previous chain node as the predecessor anchor field. For the first node, the predecessor anchor field is a string of all zero bytes. Concatenate the content identifier, perceptual hash value, lifecycle status, operation timestamp with the predecessor anchor field to form the original snapshot data. The party responsible for the operation of the current node uses its ECDSA private key to perform a digital signature on the SHA-256 digest of the original snapshot data; The original snapshot data and signature value are encapsulated into a complete chain node snapshot, its SHA-256 digest value is calculated, and it is persistently written to immutable storage.
8. The Internet content full lifecycle publishing management and dynamic maintenance system according to claim 7, characterized in that, When the lifecycle hash chain service detects an edit event, it automatically calculates the Hamming distance between the current node's perceived hash value and the predecessor node's perceived hash value. The Hamming distance is the sum of the number of bits with a value of 1 after the two perceived hash values are XORed. If the Hamming distance is greater than the substantial tampering threshold, it is determined that substantial content tampering has occurred, and an early warning notification is sent to the dynamic attribute perception and strategy engine. The dynamic attribute perception and strategy engine decides whether to trigger the permission scheduling process. The substantial tampering threshold is 10% of the perceived hash bit length.
9. The Internet content full lifecycle publishing management and dynamic maintenance system according to claim 2, characterized in that, The process of a client accessing content includes: The client pulls a hybrid encrypted content packet from the edge node of the content delivery network and sends a decryption credential request carrying the content identifier and user attribute credentials to the password verification and key dispatch gateway. After the password verification and key scheduling gateway completes the withdrawal status verification, if the content has not been withdrawn, it requests a decryption factor from the key generation center. The key generation center verifies whether the user attribute private key meets the currently effective ciphertext policy attribute-based encryption access policy. If it does, it returns the decryption factor obtained by performing partial decryption of the key ciphertext packet using the user attribute private key. The password verification and key scheduling gateway encapsulates the decryption factor into a decryption credential and sends it to the client. The client uses the decryption credential to recover the content key from the key ciphertext packet, and uses the content key to perform AES-256-GCM decryption on the content ciphertext to obtain the content plaintext.