A method, system and medium for decrypting a digital creative file

Abstract

The application provides a kind of secondary creative file decryption method, system and medium, it is related to file encryption field, comprising: using party obtains the decryption file sent by copyright party via authorization center;Using party changes the decryption file and generates secondary creative file;Using party sends the secondary creative file to the auditing party;The auditing party sends equipment code to the using party;Using party generates Chinese character activation code for secondary creative file and the equipment code, and sends to the auditing party;The auditing party uses the Chinese character activation code, and decrypts the secondary creative file.This way, using party can obtain the authorization of copyright party as a prerequisite, and the plaintext content of secondary creative file is obtained safely and in compliance by sending secondary creative file and decryption application to copyright party, which not only guarantees the copyright rights of copyright party, but also provides a legal decryption way for using party, and promotes the benign interaction between creation and use in file encryption field.

Description

Technical Field

[0001] This invention relates to the field of file encryption technology, and more specifically, to a method, system, and medium for decrypting duplicate files. Background Technology

[0002] With increasingly stringent data security compliance regulations, various confidentiality reviews and compliance verifications are becoming more routine and rigorous. Currently, critical data and related software products that do not employ domestically developed cryptographic technologies that meet national cryptographic assessment standards not only struggle to meet compliance requirements but also face security risks such as data breaches and unauthorized access. Against this backdrop, the application of domestically developed encryption algorithms has become increasingly important and urgent.

[0003] However, in practical applications, copyright holders often need to encrypt the original files to ensure their security during transmission and storage. Users, after obtaining authorization, then need to create derivative works from these encrypted files and obtain the plaintext content for further use or dissemination. Existing file encryption and decryption methods, while satisfying copyright protection, often fail to meet the needs of users for derivative works, or the derivative work process is cumbersome and lacks security, thus failing to effectively promote a positive interaction between creation and use in the field of file encryption. Summary of the Invention

[0004] To address the aforementioned problems, this invention proposes a method, system, and medium for decrypting derivative files. The aim is to provide copyright holders and users with a secure, compliant, and efficient solution for decrypting derivative files by introducing an authorization center as a neutral third party and combining domestically developed encryption algorithms and security technologies such as USB flash drive keys. In a first aspect, embodiments of this invention provide a method for decrypting and authorizing derivative files, the method comprising:

[0005] The user obtains the decrypted file sent by the copyright holder through the authorization center;

[0006] The user modifies the decrypted file to generate a derivative file;

[0007] The user sends the modified document to the reviewer.

[0008] The reviewer sends the device code to the user;

[0009] The user generates a Chinese activation code based on the modified document and the device code, and sends it to the reviewer;

[0010] The reviewer used the Chinese character activation code to decrypt the derivative file.

[0011] As one possible implementation, the method further includes:

[0012] The user sends the modified file and the application for decryption of the modified file to the copyright holder so that the copyright holder can provide an authorization document or an authorization QR code.

[0013] The user decrypts the modified file based on the authorization document or authorization QR code.

[0014] As one possible implementation, the method further includes:

[0015] The user sends the modified document and the application for declassification of the modified document to the copyright holder so that the copyright holder can provide the plaintext of the modified document.

[0016] As one possible implementation, after the user sends the derivative document to the reviewer, the method further includes:

[0017] The user will send the user's USB key to the reviewer so that the reviewer can use the user's USB key to decrypt the modified file;

[0018] Before the user sends the user's USB key to the auditor, the method further includes:

[0019] The copyright holder submits the copyright holder's authorization information to the authorization center. The copyright holder's authorization information includes user identifier, number of authorized clients, types of encryptable files, list of authorized software and / or authorization time.

[0020] Based on the copyright holder's authorization information, the authorization center generates an authorization file according to preset rules and sends it to the copyright holder;

[0021] The authorization center writes the private key corresponding to the copyright holder's user identifier under the authorization center system parameters into the copyright holder's USB key, and then sends the copyright holder's USB key to the copyright holder;

[0022] The authorization center issues the corresponding USB key to the number of authorized clients to the copyright holder.

[0023] The user sends authorization information, including user identification, to the copyright holder;

[0024] Based on the user's authorization information, the copyright holder generates a user identifier private key, writes it into the user's USB flash drive key, and then sends the user's USB flash drive key to the user.

[0025] As one possible implementation, the user obtains the decrypted file sent by the copyright holder through an authorization center, including:

[0026] Copyright holders and users apply for authorization from the licensing center;

[0027] The copyright holder uses a domestically developed encryption algorithm to encrypt the original file, resulting in an encrypted file and a QR code encrypted ciphertext, which is then sent to the user.

[0028] The user can decrypt the encrypted file by sending a QR code encrypted with ciphertext to the authorization center, or the user can decrypt the encrypted file using the user's USB flash drive key, which is issued by the authorization center.

[0029] As one possible implementation, applying for authorization using a directional authorization center includes:

[0030] Send user authorization information, including user identifier, mobile phone number and / or terminal ID, to the Directional Authorization Center;

[0031] Based on the user's authorization information, the authorization center sends a fragment of the collaborative signature identifier private key to the user.

[0032] As one possible implementation, the copyright holder uses a domestically developed encryption algorithm to encrypt the original file, obtaining an encrypted file and a QR code encrypted ciphertext, which is then sent to the user, including:

[0033] The copyright holder generates the file encryption key and the key encryption key;

[0034] The copyright holder encrypts the file encryption key with the key encryption key to obtain the ciphertext of the file encryption key;

[0035] The copyright holder uses the file encryption key to encrypt the original file, thus obtaining the encrypted original file;

[0036] The copyright holder uses the aforementioned key to encrypt the key and generate a lineage code and a file control code;

[0037] The copyright holder generates an encrypted file based on the user identifier, the ciphertext of the file encryption key, the encrypted original file, the lineage code, the file control code, and / or the list of licensed software, and sends it to the user.

[0038] The user sends the device identification code to the copyright holder;

[0039] The copyright holder generates an authorization QR code based on the user identifier, the key encryption key, and / or the user's device identification code.

[0040] The copyright holder uses white-box technology to encrypt the authorized QR code, forming encrypted QR code text, and sends it to the user.

[0041] Secondly, embodiments of the present invention provide a secondary creation file decryption system, including: a copyright holder, a user, an authorization center, and an auditing party;

[0042] The copyright holder uses this to send encrypted files to the user.

[0043] The user obtains the decrypted file sent by the copyright holder through the authorization center; modifies the decrypted file to generate a secondary creation file; sends the secondary creation file to the reviewer; generates a Chinese character activation code based on the secondary creation file and the device code, and sends it to the reviewer.

[0044] The authorization center is used to assist the user in obtaining the decrypted files sent by the copyright holder;

[0045] The reviewer sends the device code to the user and uses the Chinese character activation code to decrypt the modified file.

[0046] As one possible implementation, the system further includes: a copyright holder's USB flash drive key and a user's USB flash drive key, wherein the copyright holder's USB flash drive key is used to connect with the copyright holder, and the user's USB flash drive key is used to connect with the user, and both the copyright holder's USB flash drive key and the user's USB flash drive key are issued by the authorization center.

[0047] Thirdly, embodiments of the present invention provide a readable storage medium having executable instructions stored thereon, wherein the executable instructions, when executed by a processor, implement the method described in the first aspect.

[0048] The embodiments of the present invention provide a method, system, and medium for decrypting and authorizing derivative files. The user obtains a decrypted file sent by the copyright holder through an authorization center; the user modifies the decrypted file to generate a derivative file; the user sends the derivative file to an auditor; the auditor sends a device code to the user; the user generates a Chinese character activation code for the derivative file and the device code, and sends it to the auditor; the auditor uses the Chinese character activation code to decrypt the derivative file.

[0049] In this way, users can create derivative works on decrypted files with the authorization of the copyright holder, and obtain the plaintext content of the derivative files securely and compliantly by sending the derivative files and decryption applications to the copyright holder. This not only protects the copyright holder's rights, but also provides users with a legal way to decrypt derivative files, promoting positive interaction between creation and use in the field of file encryption. Attached Figure Description

[0050] Figure 1 This is an exemplary architecture diagram in which an embodiment of the present invention can be applied;

[0051] Figure 2 This is a flowchart illustrating how a user obtains a decrypted file sent by a copyright holder through an authorization center, as provided in an embodiment of the present invention.

[0052] Figure 3This is a flowchart of an embodiment of the decryption and authorization method for secondary files provided in this invention.

[0053] Figure 4 This is a schematic diagram of the structure of a computer suitable for implementing embodiments of the present disclosure. Detailed Implementation

[0054] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0055] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0056] Figure 1 An exemplary architecture 100 is shown, representing an embodiment of the secondary file decryption method, system, and medium of the present invention.

[0057] like Figure 1 As shown, architecture 100 may include an authorization center 101, a copyright holder 102, a user 103, and an auditor 107. The authorization center 101 can configure a copyright holder USB key (SUKEY) 104 and a user USB key (CUKEY) 105. Network 106 serves as the medium providing a communication link between the authorization center 101, copyright holder 102, user 103, and auditor 107. The authorization center 101, copyright holder 102, user 103, and auditor 107 are terminal devices, on which various communication client applications can be installed, such as file distribution applications, voice recognition applications, short video social applications, audio and video conferencing applications, live video streaming applications, document editing applications, input method applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc. Network 106 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc. The copyright holder's USB key (SUKEY) 104 and the user's USB key (CUKEY) 105 are USB keys, i.e., USB keys. The copyright holder's USB key (SUKEY) 104 is connected to the copyright holder 102, and the user's USB key is connected to the user 103.

[0058] Authorization Center 101, Copyright Holder 102, User 103, and Reviewer 107 can be either hardware or software. When Authorization Center 101, Copyright Holder 102, User 103, and Reviewer 107 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, smart home appliances, wearable devices, and desktop computers. When Authorization Center 101, Copyright Holder 102, User 103, and Reviewer 107 are software, they can be installed on the terminal devices listed above. They can be implemented as multiple software programs or software modules (e.g., used to provide file distribution services) or as a single software program or software module. No specific limitations are made here.

[0059] In some cases, the decryption method for secondary creation files provided by this invention can be executed by the authorization center 101, the copyright holder 102, the user 103, and the reviewer 107.

[0060] In some cases, the decryption method for duplicate files provided by this invention can be jointly executed by the authorization center 101, the copyright holder 102, the user 103, and the reviewer 107. For example, the step of "the copyright holder and the user applying for authorization from the authorization center" can be executed by the copyright holder 102 and the user 103, and the steps of "the authorization center generating an authorization file, a copyright holder USB key (SUKEY), and at least one user USB key (CUKEY) based on the copyright holder's authorization information, and distributing them to the copyright holder" can be executed by the authorization center 101. This invention does not limit this aspect.

[0061] It should be understood that Figure 1 The number of Authorization Center 101, Copyright Holder 102, User 103, Copyright Holder USB Key (SUKEY) 104, User USB Key (CUKEY) 105, and Auditor 107 in the diagram is merely illustrative. Depending on implementation needs, any number of Authorization Center 101, Copyright Holder 102, User 103, Copyright Holder USB Key (SUKEY) 104, User USB Key (CUKEY) 105, and Auditor 107 can be included.

[0062] Before explaining the decryption and authorization method for secondary creation files in this invention, it is first necessary to define a secondary creation file. A secondary creation file refers to a new file generated by a user after obtaining a decrypted file sent by the copyright holder and performing secondary processing operations such as modification, editing, and creation on the decrypted file. This new file contains part or all of the content of the original file, and also incorporates the user's creativity, modifications, or supplementary information, thus forming a file form with unique value and meaning. In the decryption and authorization method of this invention, the generation and use of secondary creation files are the core links. Through a specific decryption and authorization process, it is ensured that secondary creation files are distributed and used under the premise of legality and security.

[0063] Before decrypting the derivative works, the user needs to obtain the decryption file from the copyright holder. For instructions on how to obtain the decryption file from the copyright holder, please refer to [link / reference needed]. Figure 2 , Figure 2 The process of a user obtaining a decrypted file sent by the copyright holder through an authorization center is shown, including steps 201 to 204:

[0064] Step 201: The copyright holder and the user apply for authorization from the authorization center.

[0065] The copyright holder, also known as the data provider, refers to the entity that generates valuable data files. This entity encrypts the data files and then distributes them to data users. The data provider must use a file distribution server version.

[0066] After obtaining encrypted data files and authorization from the copyright holder, the user uses this data to create new data files.

[0067] The Authorization Center, acting as the key generation hub, is responsible for generating and managing the keys for copyright holders and users, thereby ensuring the security of the entire file distribution process. Each copyright holder and user is equipped with a corresponding USB key, which stores a private key generated by the Authorization Center and identifies the user accordingly. The Authorization Center generates a public-private key pair for file encryption. The public key is embedded in the software client that can be installed by all three parties, while the private key is stored by the Authorization Center. This private key is used by the Authorization Center to sign the software client's authorization document, and the software client uses the public key to verify the authorization document.

[0068] Before encryption and authorization can be performed, both the copyright holder and the user need to apply for authorization from the authorization center. Before receiving this information, the authorization center needs to initialize and build a key generation system, specifically including: ① generating file encryption public-private key pairs and system parameters, for example, system parameter name OLYM_GIS_SM9, version 1; ② generating authorization file signing public-private key pairs, for example, PubKey_Lic, PrvKey_Lic; ③ building the authorization center to allow applications for authorization files and creating USB flash drive keys.

[0069] When a copyright holder applies for authorization from the licensing center, they first submit their authorization information. This information includes, but is not limited to, user identifiers, the number of authorized clients, the types of files that can be encrypted, a list of authorized software, and the authorization period. It should be noted that both the copyright holder and the user have unique user identifiers, which end with a '~' counter, starting at 1, for example, "XXX Province YYY City ZZZ Organization ~1". To update, the counter is incremented at the end, for example, ending with '~2'. The number of authorized clients refers to the number of users the copyright holder needs to authorize. The types of files that can be encrypted are set according to the requirements for file distribution.

[0070] After receiving this information, the authorization center generates an authorization file according to preset rules and then sends it to the copyright holder. It should be noted that the authorization file includes the copyright holder's user identifier, the number of authorized clients, the types of files that can be encrypted, a list of authorized software, the authorization time (CTIME), and the authorization center's signature on the authorization information (e.g., using a PrvKey_Lic signature).

[0071] After receiving this information, the authorization center will write the private key corresponding to the copyright holder's user identifier under the authorization center's system parameters into the copyright holder's USB key (SUKEY), and prepare at least one user USB key (CUKEY) corresponding to the number of authorized clients. This information will then be securely distributed to the copyright holder. Secure distribution refers to the secure physical transmission of both the copyright holder's USB key (SUKEY) and the user's USB key (CUKEY). Authorization files can be distributed via USB key or network.

[0072] The relevant personnel will insert the copyright holder's USB key (SUKEY) into the copyright holder's computer and launch the copyright holder's software client for distributing files. The software client can then import the license file, verify the license file, and initialize the copyright holder's USB key (SUKEY), file encryption master key (MFEK), and key encryption key (EFEKK).

[0073] Specifically, first verify the authorization file (e.g., using PubKey_Lic verification in the software). Then verify the legitimacy of the copyright holder's USB key (SUKEY), including confirming it is a copyright holder USB key (SUKEY) type (not a user's USB key). Next, create the copyright holder's key information within the copyright holder's USB key (SUKEY), including generating a file encryption public / private key pair and system parameters (e.g., "XXX Province YYY City ZZZ Organization_KGC" as the domain name, version 1). Then, generate the relevant key information for the file encryption master key (MFEKK) within the copyright holder's USB key (SUKEY): a random encryption master key identifier (MKID) and the file encryption master key (MFEKK). Finally, optionally, the file encryption master key (MFEKK) can be encrypted and exported as a backup using the user identifier (XXX Province YYY City ZZZ Organization~1) under the system parameters.

[0074] The FEK (File Encryption Key) is the "small key" that directly encrypts the original file. It is randomly generated and does not need to be updated; its encrypted version is present at the beginning of the file. The EFEKK (Key Encryption Key) is a "middle-level key" specifically used to "lock" the FEK. It is derived from the root key MFEKK based on the EKID, and it updates whenever the EKID changes. The MFEKK (File Encryption Master Key) is the "master key" of the entire system. It is a 32-byte key randomly generated by the copyright holder and used to derive the EFEKK. Its update changes the corresponding identifier MKID. The MKID (File Encryption Master Key Identifier) ​​is a 4-byte "identity tag" attached to the "master key MFEKK," consisting of 1 byte version and 3 bytes of random data. The EKID (Key Encryption Key ID) is a 12-byte "identity code" specifically identifying the FEK, composed of 4 bytes of MKID and 8 bytes of DBID. The 8-byte DBID is an "auxiliary code," composed of 2 bytes of protection period start time (BEGINTIME) plus a 6-byte hash value calculated from relevant information, used to distinguish keys for different periods.

[0075] It should be noted that the software client can be configured with key update policies that are valid monthly, quarterly, semi-annually, annually, 3-yearly, or permanently to address potential security threats. Specifically, a start time (BEGINTIME) is generated based on the current time. A file encryption master key (MFEKK) is generated using the copyright holder's USB key (SUKEY) based on the encryption master key identifier (MKID), user identifier, and start time (BEGINTIME). The start time (BEGINTIME) defines the lifecycle of the encryption key (EFEKK), including monthly, quarterly, semi-annual, annual, 3-yearly, and permanently valid options. For monthly updates, it's the first day of the current month (e.g., 2025-02-01); for quarterly updates, it's the start day of the current quarter (e.g., 2025-04-01), and so on. The date is converted to a 16-bit integer, representing the number of days since 2025-01-01.

[0076] There are two ways to apply for authorization using the Directional Authorization Center:

[0077] The first method involves the user sending user authorization information, including a user identifier, to the copyright holder; based on the user authorization information, the copyright holder generates a user identifier private key, writes it into the user's USB flash drive key (CUKEY), and sends it to the user.

[0078] Since the copyright holder receives multiple user USB key (CUKEY) from the authorization center, they can generate a private key corresponding to the user's identifier under the system parameters based on the user's authorization information and write it into the user USB key (CUKEY). Authorized users can then connect to the user USB key (CUKEY), write the device ID into it, and decrypt encrypted files. Furthermore, the maximum number of device IDs that can be written into the user USB key (CUKEY) can be set to enhance its security.

[0079] The second method involves the user sending authorization information, including user identifier, mobile phone number, and / or terminal ID (e.g., application software ID), to the authorization center; based on the user's authorization information, the authorization center sends a fragment of the collaborative signature identifier private key to the user.

[0080] After obtaining the authorization information, the authorization center verifies the uniqueness of the complete user identifier to ensure no duplicates. Then, it sends an SMS verification code to the corresponding mobile phone number. Upon receiving the verification code from the user, the center associates the user identifier, mobile phone number, and / or terminal ID, and sends a collaborative signature identifier private key fragment to the user via the user's mobile phone number. The user can then launch the software client for distributing files and use the collaborative signature identifier private key fragment to complete the authorization request. After verifying the correctness of the collaborative signature identifier private key fragment, the authorization center completes the authorization process, and the user can then decrypt encrypted files via the authorization QR code. Furthermore, the user can request a change of mobile phone number by sending an SMS to the authorization center; the specific process is not restricted here.

[0081] The two authorization methods can be used individually or in combination. For frequently used or internally used devices, the user's USB key (CUKEY) can be used for convenient operation. For temporarily added devices, authorization can be done through the authorization center. This can handle emergencies without the need for advance authorization planning (obtaining the user's device information) or concerns about inconvenience or insufficient quantity of user USB keys (CUKEY). It provides a secure, flexible, and quick binding process, improving the efficiency of file transfer.

[0082] Step 202: The copyright holder uses a domestically developed encryption algorithm to encrypt the original file, obtaining an encrypted file and a QR code encrypted ciphertext, which is then sent to the user.

[0083] The file encryption process using domestically developed encryption algorithms must follow a layered key protection logic and proceed in an orderly manner step by step.

[0084] First, preliminary preparations are carried out. The copyright holder randomly generates a 32-byte file encryption master key (MFEKK) and a 4-byte file encryption master key identifier (MKID) consisting of 1 byte of version information and 3 bytes of random data, thus initializing the master key. The software client selects a monthly, quarterly, semi-annual, annual, 3-year, or permanently valid key update cycle according to actual needs. Based on the current time, the data protection cycle start time (BEGINTIME) is determined, converted into the number of days from 2025-01-01, and then converted into a 2-byte 16-bit integer. Using BEGINTIME, the data owner identifier, and MKID as input parameters, a hash value is generated through a hash algorithm. The first 6 bytes of this hash value are extracted and concatenated with the 2-byte BEGINTIME to form an 8-byte DBID. Finally, the 4-byte MKID is further concatenated with the 8-byte DBID to obtain a 12-byte key encryption key ID (EKID).

[0085] After completing the preliminary preparations, the copyright holder uses the generated MFEKK to derive the key encryption key (EFEKK) from the EKID, and uses this as the dedicated key for encryption work; then a file encryption key (FEK) is randomly generated for directly encrypting the original file, and this key does not need to be updated later.

[0086] Next, the core encryption process begins. First, the FEK is encrypted using EFEKK to generate ciphertext FEK (FKCTX), which is stored in the header of the file to be encrypted, providing a basis for subsequent decryption. Then, the unencrypted FEK is used to encrypt the original target file (DATA), generating an encrypted file (DCTX) that cannot be directly read. The key encryption key (EFEKK) is used to generate the lineage code (LNC) and file control code (FCTL). Finally, the copyright holder's user identifier, the key encryption key ID (EKID), the ciphertext of the file encryption key (FKCTX), the lineage code (LNC), the file control code (FCTL), and / or the encrypted original file (DCTX), along with the list of licensed software, are integrated to generate the final encrypted file, which is then sent to the user.

[0087] The lineage code (LNC) is a 16-byte data stored in the header of the encrypted file. It identifies that the file belongs to a batch of data encrypted and protected by the file encryption key (FEK), thus representing the ownership of the original file. Although the file contains the data owner, the key encryption key ID (EKID), and the ciphertext of the file encryption key (FKCTX), the consistency of these data is protected by a QR code (MAC) generated by the file encryption key (FEK), which can be tampered with. This data requires the file encryption key (FEK) to participate in the calculation. The file encryption key (FEK) is encrypted by the key encryption key (EFEKK) to form the ciphertext of the file encryption key (FKCTX), which is stored in the header of the encrypted file (16 bytes or 32 bytes).

[0088] The File Control Code (FCTL) is a 16-byte data stored in the header of an encrypted file. It identifies the user of the file, the time frame of use, the number of uses, and records the original file's usage permissions. This data requires the File Encryption Key (FEK) for calculation.

[0089] The ciphertext of the file encryption key (FKCTX) is the ciphertext of the file encryption key FEK. FEK is encrypted by the key encryption key (EFEKK) to form FKCTX, which is present in the header of the encrypted file (16 bytes or 32 bytes).

[0090] After the copyright holder sends the encrypted file to the user, the user will send a Device Identifier (DEV) to the copyright holder. Device Identifier (DEV): A unique identifier extracted by the software client from the user's or copyright holder's device.

[0091] The copyright holder generates an authorization QR code using either method a or b, based on their own user identifier, key encryption key ID (EKID), key encryption key (EFEKK), user's device identifier (DEV), authorization validity period, and purpose: a. Encrypting with authorization center system parameters and user identifier to form encrypted ciphertext (CTX) and authorization QR code (LMAC); b. Encrypting with copyright holder system parameters and user identifier to form encrypted ciphertext (CTX) and authorization QR code (LMAC). Then, using white-box technology, they encrypt the QR code to form encrypted ciphertext (LCTX) and send it to the user.

[0092] Step 203: The user sends a QR code to the authorization center to verify and decrypt the encrypted file.

[0093] The user sends the encrypted QR code to the authorization center; the authorization center uses the user's corresponding private key to decrypt the encrypted QR code, obtaining the copyright holder's user identifier and key encryption key; the authorization center generates a Chinese character verification code based on the copyright holder's user identifier and key encryption key; the authorization center sends the Chinese character verification code and key encryption key to the user; the user decrypts the encrypted file based on the Chinese character verification code and key encryption key.

[0094] Specifically, users can send a QR code to the authorization center to encrypt and decrypt the encrypted file in two ways:

[0095] The first method involves the user obtaining the encrypted QR code (LCTX) and sending it to the authorization center. The authorization center uses the file encryption public-private key pair to generate the identifier private key used by the user when applying for authorization. This is then decrypted to obtain information such as the copyright holder's user identifier, the key encryption key ID (EKID), and the key encryption key (EFEKK). Relevant personnel from the user enter the copyright holder's user identifier into the client software. These personnel then scan the QR code (without the EKID information) on the software client and submit it to the authorization center. The authorization center then encrypts and distributes the most recently encrypted key encryption key ID (EKID). The encryption key (EFEKK) is used to generate a 17-character Chinese character verification code. Relevant personnel on the user's software client input this 17-character verification code to recover part of the encryption key's ID (EKID, last 48 bits: EKIDR, where EKIDR is 6 bytes, representing the 6-byte hash information within EKID) and the complete encryption key (EFEKK). The user's software client injects EKIDR and the encryption key (EFEKK) into the kernel. Combined with the software client's public key, the user can then open the encrypted file in authorized software and decrypt it.

[0096] The second scenario involves a user encountering a lack of authorization to access an encrypted file. In this case, the user's client software can generate an authorization QR code. The user's personnel scan the client software's QR code (containing complete EKID information) and submit it to the authorization center. The authorization center then uses the encrypted key's ID (EKID) to generate a 13-character verification code. The user's personnel input this verification code into the client software to reconstruct the complete EKID. The client then injects the EKID and EKK into its kernel, combining them with the client's public key, allowing the user to open the encrypted file within the authorized software.

[0097] Step 204: The user decrypts the encrypted file using the user's USB flash drive key.

[0098] The user decrypts the QR code encrypted ciphertext (LCTX) using a white-box decryption tool to obtain the encrypted ciphertext (CTX). Then, using the user's USB drive key (CUKEY), the user decrypts the encrypted ciphertext (CTX) to obtain the key encryption key (EFEKK). In reality, the key encryption key (EFEKK) does not leave the user's USB drive key (CUKEY); instead, it is provided to the user in the form of a handle. The user uses the ciphertext of the file encryption key (FKCTX), lineage code (LNC), file control code (FCTL), license time (CTIME), copyright holder's user identifier, copyright holder's key encryption key ID (EKID), and user's device identifier (DEV) to access the user's USB drive key (CUKEY) or kernel, decrypts it to obtain the file encryption key (FEK), and then decrypts the original encrypted file (DCTX) in memory to obtain the original file (DATA).

[0099] Through the steps described above, copyright holders and users can securely and efficiently complete the file distribution and decryption process offline. In this process, the licensing center plays a crucial role, not only generating and managing licensing files but also ensuring the security and traceability of the entire distribution process. The copyright holder uses a carefully designed encryption mechanism to transform the original file into an encrypted file, along with rich access control information such as lineage codes and file control codes. This information plays a key role in verification and control during subsequent file use.

[0100] After receiving the encrypted file, the user applies for authorization using different methods depending on whether an authorization QR code has been obtained simultaneously. Regardless of the method, the ultimate goal is to obtain the key information needed to decrypt the file. Once authorization is successful, the user can use the user's USB key (CUKEY) to decrypt the file. During this process, the key encryption key (EFEKK) is provided in the form of a handle, ensuring that the key information is not leaked to unauthorized entities.

[0101] Furthermore, the entire file distribution system considers a balance between flexibility and security. By providing two authorization methods, the system can handle both regular device usage scenarios and flexibly respond to temporary device additions in emergency situations. Simultaneously, by setting a maximum number of device IDs that can be written to the user's USB drive key (CUKEY), and utilizing mechanisms such as lineage codes and file control codes, the system effectively enhances the security and controllability of file transfer.

[0102] Based on this, continue to refer to Figure 3 The diagram illustrates a flow 300 of an embodiment of a method for decrypting and authorizing secondary files according to the present invention, which includes the following steps 301 to 304:

[0103] Step 301: The user obtains the decrypted file sent by the copyright holder through the authorization center.

[0104] The user obtains the decrypted file sent by the copyright holder through the authorization center. This decrypted file has passed the key verification of the authorization center and the encryption authorization verification of the copyright holder, ensuring the legality and integrity of the file. The specific process is described in the previous embodiment and will not be repeated here.

[0105] Step 302: The user modifies the decrypted file to generate a secondary file.

[0106] Based on their own business needs or creative expansion, users can modify the decrypted file by changing its content, adjusting its format, and adding information to generate a secondary file that integrates the core information of the original file with their own innovative achievements. Furthermore, after performing any operation on the decrypted file, when the user stores the generated secondary file, a file encryption key (FEK) is randomly generated. This ciphertext (FKCTX) of the generated file encryption key is then encrypted using the encryption key (EFEKK) from the user's USB key (CUKEY) or the software client. The file encryption key (FEK) is then used to encrypt the secondary file, forming the encrypted original file (DCTX) of the secondary file.

[0107] Step 303: The user sends the modified file and the declassification application for the modified file to the copyright holder so that the copyright holder can provide the plaintext of the modified file.

[0108] Declassification refers to the process by which a user, after generating and encrypting a derivative document, requests a declassification application from the copyright holder to obtain a plaintext version for further use or distribution. This application must include information about the original encrypted file (DCTX) of the derivative document, such as file identifiers, encryption method descriptions, and the user's identity verification information, ensuring the legitimacy and authenticity of the application source. Upon receiving the declassification application, the copyright holder will first verify the user's identity and permissions to confirm their eligibility to obtain the plaintext of the derivative document. After successful verification, the copyright holder will use its encryption key (EFEKK) or relevant decryption tools to decrypt the original encrypted file (DCTX) of the derivative document, restoring the plaintext content. The copyright holder will then return the decrypted plaintext to the user, completing the declassification process. Throughout this process, the copyright holder must ensure the security of the decryption operation, preventing key leakage or interception of the plaintext file during transmission, thereby protecting the rights and data security of both parties. The copyright holder can decrypt the file using its stored file encryption key (FEK) and save it as plaintext before sending it to the user.

[0109] This allows users to easily send their derivative works to higher-level organizations for review. Higher-level organizations do not need to directly handle complex decryption processes; they only need to receive the plaintext derivative works from the copyright holder for review. This process not only simplifies the document flow but also ensures the security and integrity of the document content during transmission, avoiding the risk of information leakage due to improper decryption. Simultaneously, when providing the plaintext, the copyright holder can flexibly set usage permissions for the derivative works based on the user's declassification request, such as the number of reads and printing restrictions, further strengthening the management and control of the derivative works.

[0110] As one possible implementation, the method further includes:

[0111] Step 304: The user sends the modified file and the modified file decryption application to the copyright holder so that the copyright holder can provide an authorization document or authorization QR code.

[0112] Decryption refers to the process where a user needs to decrypt encrypted derivative works for further editing or distribution. In this process, the user must submit a formal decryption request to the copyright holder. This request must include complete information about the original encrypted file (DCTX) of the derivative work, including but not limited to the file's unique identifier and encryption algorithm parameters. It must also include the user's multi-factor authentication information to prove the legitimacy and reliability of the request's source. Upon receiving the decryption request, the copyright holder will initiate a rigorous multi-factor verification mechanism to comprehensively assess whether the user has the legal authority to obtain decryption authorization for the derivative work. After confirming the authorization is valid, the copyright holder will use its proprietary encryption key (EFEKK) or a professional decryption system to perform a secure decryption operation on the original encrypted file (DCTX) of the derivative work, accurately restoring the original data content. Afterward, the copyright holder will selectively generate an authorization document or dynamically generate an authorization QR code and provide it to the user, depending on their specific needs. Once the user obtains the authorization document or scans the authorization QR code, they can complete the decryption process according to the preset security protocol and then proceed with subsequent editing or content distribution.

[0113] The user's software client can display and select which user units to send files to, obtain decryption authorization, and then generate a decryption application for the secondary creation file based on this. The encrypted secondary creation file is then sent to the copyright holder via a secure transmission channel. The copyright holder first locates the corresponding key, then verifies the key (searching for the corresponding key file in the file's directory; if not found, searching through the software client). The key's legality is verified by comparing key information such as the File Lineage Code (LNC) and File Control Code (FCTL). After relevant reviewers conduct a dual review of the compliance of the secondary creation file decryption application and the copyright association of the secondary creation file, the decryption authorization operation is performed on the secondary creation file, generating a decryption authorization (authorization file / 30 Chinese characters) containing the copyright holder's signature, authorization validity period, and unique file identifier. This decryption authorization is then transmitted to the user via a secure method such as an encrypted network or USB flash drive key.

[0114] Step 305: The user decrypts the modified file based on the authorization document or authorization QR code.

[0115] Users can manually input decryption authorization or import a complete authorization file through the client software. After the system automatically verifies the validity and timeliness of the decryption authorization signature, the directory where the secondary creation file is located will automatically generate a decrypted usable file and display the corresponding file storage path in a pop-up window, thus completing the entire decryption process of the secondary creation file.

[0116] As one possible implementation, the method further includes:

[0117] Step 306: The user sends the modified document to the reviewer.

[0118] The reviewer is an independent third-party organization or superior authority with professional review qualifications and authority, responsible for conducting a comprehensive and detailed compliance review and content evaluation of the derivative works submitted by the user. After completing the creation and encrypted storage of the derivative works, if the user needs to submit the files to the reviewer for review, they can send the derivative works to the receiving address or system platform designated by the reviewer through secure and reliable transmission channels, such as encrypted network transmission or mailing with the user's USB flash drive key (CUKEY). During the transmission process, the user must ensure the security and integrity of the file transmission to prevent the file from being tampered with or leaked during transmission. After receiving the derivative works, the reviewer will strictly review the content, format, copyright ownership, etc. of the file according to the established review standards and procedures, and issue a detailed review report and feedback, providing improvement suggestions and guidance to the user. After obtaining authorization to decrypt the derivative works, the user should package the derivative works and the accompanying file reading client software together and send them to the reviewer according to business collaboration needs. The sending method can be encrypted email, WeChat Work, or other channels with secure transmission capabilities to avoid file leakage during transmission.

[0119] Step 307: The reviewer sends the device code to the user.

[0120] Upon receiving the modified files and related software from the user, the auditor will first perform a preliminary integrity check to ensure the files have not been damaged or tampered with during transmission. Subsequently, the auditor will initiate an internal review process, which may include multiple stages such as compliance review of the file content, verification of copyright ownership, and technical security assessment. During the review process, if any issues are found or further information is needed, the auditor will promptly communicate with the user. Upon completion of the review, the auditor will generate a unique device code, which will serve as an authentication identifier for the user's device. The auditor will send this device code to the user via encrypted email, WeChat Work, or other secure transmission channels for subsequent file decryption or access.

[0121] Step 308: The user generates a Chinese character activation code based on the secondary creation file and the device code, and sends it to the reviewer.

[0122] After obtaining the device code provided by the reviewer, the user will use client software to scan and parse the device code information. Combined with important parameters such as the encryption key ID (EKID) of the secondary creation file and its own user identifier, the user will generate a Chinese character activation code that uniquely corresponds to the device code. This ensures that the activation code can only be used on the device designated by the reviewer, and the user will promptly send this Chinese character activation code to the reviewer.

[0123] The Chinese character activation code encompasses both the basic information of the derivative work and the device code of the reviewer, thus ensuring the uniqueness and security of the activation code. After generating the activation code, the user will send it to the reviewer for verification via secure means such as encrypted email or WeChat Work. Upon receiving the activation code, the reviewer will perform a reverse parsing and verification process to confirm the validity of the activation code and its correspondence with the derivative work and the device code. After successful verification, the reviewer will return verification confirmation information to the user, providing corresponding support for subsequent file decryption or access operations. Simultaneously, after receiving the device code QR code sent by the reviewer, the user will use the built-in scanning function of the client software to scan and identify it, accurately extracting the core device code data contained within. Then, this core data is deeply integrated with relevant information of the derivative work, such as the file's unique identifier and generation timestamp, as well as the user's own user account, permission level, and other identity information. Through specific encryption algorithms and encoding rules, this diverse information is transformed into a Chinese character activation code composed of multiple Chinese characters. During the generation process, the system performs multiple verification and error correction processes to ensure that the generated Chinese character activation code is accurate and highly unique. After generation, the user will encrypt the activation code again to prevent it from being stolen or tampered with during transmission. Then, the encrypted activation code will be quickly and securely sent to the receiving port designated by the reviewer through a pre-set secure communication channel, such as an encrypted internal network channel or a securely certified third-party communication platform.

[0124] Step 309: The reviewer uses the Chinese character activation code to decrypt the secondary creation file.

[0125] The reviewer enters the received Chinese activation code into the activation interface of the client software. After the system verifies the matching degree and validity of the activation code and the device code, it automatically decrypts the modified file and unlocks the functions required for review, such as viewing and annotating the file.

[0126] After successfully decrypting the derivative work document, the reviewer can conduct a detailed review of its content, including but not limited to textual content, formatting specifications, and copyright information. During the review process, the reviewer can use the annotation function provided by the client software to mark in detail any problems or areas for improvement in the document and add corresponding review comments. These annotations and comments will be directly linked to specific locations in the document, facilitating subsequent review and modification by the user. Simultaneously, the reviewer will generate a detailed review report based on the review results, including review conclusions, existing problems, and improvement suggestions, and will provide feedback to the user through a secure transmission channel. Upon receiving the review report, the user can modify and improve the derivative work document according to the comments in the report to ensure that the document meets relevant requirements and standards.

[0127] In this way, even without prior planning of device compatibility information for users and reviewers, the device code and Chinese character activation code can be dynamically generated for quick binding, effectively dealing with temporary and urgent review collaboration situations, and improving collaboration efficiency while ensuring security.

[0128] As one possible implementation, the method further includes:

[0129] Step 310: The user sends the user's USB key (CUKEY) to the auditor so that the auditor can use the user's USB key (CUKEY) to decrypt the encrypted file.

[0130] For long-term collaborating reviewers or for derivative works involving high-confidentiality documents, users can send their authorized and bound USB key (CUKEY) to the reviewers. The reviewers can then insert the USB key into a designated terminal device and launch the client software. The file permissions can be directly verified using the private key information stored in the USB key, without the need for additional activation codes. This allows for secure and convenient decryption of the encrypted files using the user's USB key (CUKEY), further meeting the usage needs of different collaborative scenarios.

[0131] In summary, the file decryption method proposed in this invention achieves high security and flexibility in the distribution, decryption, secondary creation, and re-decryption processes of files through a carefully designed encryption and authorization mechanism. This method not only fully considers the balance of rights between copyright holders and users but also ensures the traceability and controllability of the entire file circulation process by introducing an authorization center as a core role. In practical applications, copyright holders can flexibly control the decryption permissions and scope of use of files, effectively preventing unauthorized copying and dissemination; while users can, under the premise of ensuring security, perform secondary creation and reuse of files according to their own needs, greatly enhancing the use value of the files. Simultaneously, the system provides multiple authorization methods and decryption means to adapt to the needs of different scenarios, properly addressing both regular device use and temporary collaboration in emergency situations. Furthermore, by introducing dynamic binding mechanisms such as device codes and Chinese character activation codes, the system further enhances the security of file circulation, ensuring that only authorized devices and personnel can access and decrypt files.

[0132] The following is for reference. Figure 4 It shows a schematic diagram of the structure of a computer 400 suitable for implementing the electronic device of the present invention. Figure 4 The computer 400 shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0133] like Figure 4As shown, computer 400 may include a processing device (e.g., central processing unit, graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from storage device 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the operation of computer 400. Processing device 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0134] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows computer 400 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 A computer 400 with various electronic devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0135] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 409, or installed from a storage device 408, or installed from a ROM 402. When the computer program is executed by a processing device 401, it performs the functions defined in the methods of the embodiments of the present invention.

[0136] It should be noted that the computer-readable medium described above in this invention can be a computer-readable signal medium, a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor device or apparatus, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be executed by instructions, used by a device or apparatus, or used in conjunction with it. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with instructions, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0137] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0138] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the following functions: Figure 2-3 The methods illustrated in the embodiments and their alternative implementations are methods.

[0139] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0140] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using dedicated hardware-based implementations that perform the specified functions or operations, or using a combination of dedicated hardware and computer instructions.

[0141] The units or modules described in the embodiments of the present invention can be implemented in software or hardware. In some cases, the user identifier of a unit or module does not constitute a limitation on the unit itself.

[0142] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for decrypting duplicate files, characterized in that, The method includes: The user obtains the decrypted file sent by the copyright holder through the authorization center; The user modifies the decrypted file to generate a derivative file; The user sends the modified document to the reviewer. The reviewer sends the device code to the user; The user generates a Chinese activation code based on the modified document and the device code, and sends it to the reviewer; The reviewer used the Chinese character activation code to decrypt the derivative file.

2. The method according to claim 1, characterized in that, The method further includes: The user sends the modified file and the application for decryption of the modified file to the copyright holder so that the copyright holder can provide an authorization document or an authorization QR code. The user decrypts the modified file based on the authorization document or authorization QR code.

3. The method according to claim 1, characterized in that, The method further includes: The user sends the modified document and the application for declassification of the modified document to the copyright holder so that the copyright holder can provide the plaintext of the modified document.

4. The method according to claim 1, characterized in that, After the user sends the derivative document to the reviewer, the method further includes: The user will send the user's USB key to the reviewer so that the reviewer can use the user's USB key to decrypt the modified file; Before the user sends the user's USB key to the auditor, the method further includes: The copyright holder submits the copyright holder's authorization information to the authorization center. The copyright holder's authorization information includes user identifier, number of authorized clients, types of encryptable files, list of authorized software and / or authorization time. Based on the copyright holder's authorization information, the authorization center generates an authorization file according to preset rules and sends it to the copyright holder; The authorization center writes the private key corresponding to the copyright holder's user identifier under the authorization center system parameters into the copyright holder's USB key, and then sends the copyright holder's USB key to the copyright holder; The authorization center issues the corresponding USB key to the number of authorized clients to the copyright holder. The user sends authorization information, including user identification, to the copyright holder; Based on the user's authorization information, the copyright holder generates a user identifier private key, writes it into the user's USB flash drive key, and then sends the user's USB flash drive key to the user.

5. The method according to claim 1, characterized in that, The user obtains the decrypted file sent by the copyright holder through the authorization center, including: Copyright holders and users apply for authorization from the licensing center; The copyright holder uses a domestically developed encryption algorithm to encrypt the original file, resulting in an encrypted file and a QR code encrypted ciphertext, which is then sent to the user. The user can decrypt the encrypted file by sending a QR code encrypted with ciphertext to the authorization center, or the user can decrypt the encrypted file using the user's USB flash drive key, which is issued by the authorization center.

6. The method according to claim 5, characterized in that, Apply for authorization using the Directional Authorization Center, including: Send user authorization information, including user identifier, mobile phone number and / or terminal ID, to the Directional Authorization Center; Based on the user's authorization information, the authorization center sends a fragment of the collaborative signature identifier private key to the user.

7. The method according to claim 5, characterized in that, The copyright holder uses a domestically developed encryption algorithm to encrypt the original file, obtaining an encrypted file and a QR code encrypted ciphertext, which is then sent to the user, including: The copyright holder generates the file encryption key and the key encryption key; The copyright holder encrypts the file encryption key with the key encryption key to obtain the ciphertext of the file encryption key; The copyright holder uses the file encryption key to encrypt the original file, thus obtaining the encrypted original file; The copyright holder uses the aforementioned key to encrypt the key and generate a lineage code and a file control code; The copyright holder generates an encrypted file based on the user identifier, the ciphertext of the file encryption key, the encrypted original file, the lineage code, the file control code, and / or the list of licensed software, and sends it to the user. The user sends the device identification code to the copyright holder; The copyright holder generates an authorization QR code based on the user identifier, the key encryption key, and / or the user's device identification code. The copyright holder uses white-box technology to encrypt the authorized QR code, forming encrypted QR code text, and sends it to the user.

8. A secondary file decryption system, characterized in that, include: Copyright holders, users, licensing centers, and reviewers; The copyright holder uses this to send encrypted files to the user. The user obtains the decrypted file sent by the copyright holder through the authorization center; Modify the decrypted file to generate a secondary file; send the secondary file to the reviewer; generate a Chinese activation code based on the secondary file and the device code, and send it to the reviewer. The authorization center is used to assist the user in obtaining the decrypted files sent by the copyright holder; The reviewer sends the device code to the user and uses the Chinese character activation code to decrypt the modified file.

9. The system according to claim 8, characterized in that, The system also includes: a copyright holder USB key and a user USB key. The copyright holder USB key is used to connect with the copyright holder, and the user USB key is used to connect with the user. Both the copyright holder USB key and the user USB key are issued by the authorization center.

10. A readable storage medium having executable instructions stored thereon, characterized in that, When the executable instructions are executed by the processor, they implement the method of any one of claims 1 to 7.

Images