Data right confirmation method based on subject and object binding

Abstract

The invention discloses a data right confirmation method based on subject and object binding. The method comprises the following steps: preparing a data injection container; data ID creation and permission configuration; and data right confirmation and guarantee. The ownership relation is defined, the ownership and the use right of data are clearly defined through binding of the subject and the object, disputes are reduced, and the rights and interests of the owner are guaranteed; the data security is enhanced: an owner ID is encrypted and an access rule is configured, illegal access and data leakage are prevented, and the data security is improved; operation traceability is realized: a data operation log system is convenient for accurate traceability operation, and data management transparency and controllability are enhanced; and data circulation is promoted: the right confirmation is clear, so that the data is smoothly circulated in a legal compliance framework, and the data market vitality and the resource allocation efficiency are improved.

Description

Technical Field

[0001] The present invention relates to the field of data management and security, and focuses on realizing a data rights confirmation method by binding a subject and an object, so as to solve the problems of unclear data ownership and usage rights and security management. Background Art

[0002] In the digital age, data is an important asset, but it is difficult to define ownership and usage rights because it is easy to copy, spread and process. Traditional methods lack an effective binding mechanism, resulting in unclear data ownership. For example, in data sharing and trading, the source of data is difficult to trace, illegal use is frequent, and malicious attackers exploit loopholes to obtain and abuse data, damaging the interests of owners and hindering the healthy development of the data market. Summary of the invention

[0003] In order to solve the defects in the prior art, the present invention discloses a data rights confirmation method based on subject-object binding, and its technical solution is as follows: A data rights confirmation method based on subject-object binding includes the following steps: (I) Step 1: Data injection container preparation stage 1. Data integrity check Before injecting data into the container, the data provider must perform a data integrity check. Use a hash function (such as MD5 or SHA-256) to calculate the data hash value and compare it with the pre-stored original data hash value. The hash function processes the data in blocks and uses specific logical operations to obtain a fixed-length hash value. Different data has different hash values ​​(high probability). MD5 generates a 128-bit hash value, and SHA-256 generates a 256-bit hash value. If the calculated hash value is consistent with the original hash value, it indicates that the data is complete; otherwise, the data may be damaged during transmission or storage and needs to be repaired or retrieved, thereby ensuring that the data injected into the container is accurate and reliable, laying the foundation for subsequent processing.

[0004] 2. Data format standardization Standardize the data format according to predefined format specifications. Text data from different sources are uniformly encoded in UTF-8 format, and numerical data are uniform in precision and unit. This process requires analyzing the differences in data structure and format, and converting according to the target format requirements. For example, sales data from multiple departments contains dates and currency values ​​in different formats. After processing, they can be unified into the "YYYY-MM-DD" date format and specific currency format, which is convenient for integration, analysis and management, reduces errors caused by format differences, and improves data processing efficiency.

[0005] (II) Step 2: Data ID creation and permission configuration stage 1. Data ID creation and modification (data owner operation) The data owner uses a globally unique identifier (GUID) algorithm to create a unique ID for the data to be injected into the container. The GUID algorithm combines the computer network card MAC address (if the owner's device has a network card), the current precise timestamp (accurate to nanoseconds), a custom namespace (which can be defined based on the owner's organization or project), high-quality random or pseudo-random numbers (to ensure ID randomness), and timing information (record creation order) to generate a 128-bit globally unique identifier. When creating an ID, the data owner must ensure that it is closely associated with the key attributes of the data (such as data type, source system, creation purpose, etc.) for subsequent identification and management. When data is updated, merged, or split, the owner can modify the ID according to the actual situation to ensure the accuracy and validity of the ID, and synchronize the modification records to the data management system.

[0006] 2. User permission settings (related to ordinary users) The role-based access control (RBAC) model sets permissions for different user roles. The RBAC model associates roles with permissions, which are defined based on the data operation type (read, write, modify, delete, etc.) and the scope of the data object. Taking an e-commerce company as an example, ordinary employees only read part of the data (such as individuals are responsible for basic order information), department managers read and write data related to their department, and senior administrators manage all data. Permission setting information is stored in the access control list (ACL), which stores the correspondence between users or roles and permissions in the form of a list, and is used to quickly verify security and compliance when accessing data.

[0007] 3. Data access rule configuration (visitor related) Configure visitor access rules based on data sensitivity and visitor sources. External visitors to the corporate official website can only access public data (product introductions, news, etc.) and can only browse. Visitors from partner companies are granted limited read permissions for specific project data (such as project progress data) according to the agreement, and cannot access other data. By setting access control logic on the server side, the visitor identity and requested data scope are determined to ensure data security and prevent unauthorized access and abuse.

[0008] 4. Binding of data subject and object

[0009] Identify the data subject (owner, creator, etc.) and use digital certificate technology to bind the subject information and data ID. Digital certificates follow the X.509 standard and contain fields such as version, serial number, signature algorithm identifier, issuer name, validity period, subject name, and subject public key information. After issuing a certificate to a subject, the subject's identity is verified with the help of a public key infrastructure (PKI). For example, in a financial institution, traders (subjects) and transaction data (objects) are bound through IDs to establish a subject-object mapping relationship, laying the foundation for rights confirmation.

[0010] 5. Data encryption storage (homomorphic encryption application) The data is encrypted using a lattice-based homomorphic encryption algorithm. The security of the lattice-based homomorphic encryption algorithm is based on difficult problems on the lattice (such as the shortest vector problem, the nearest vector problem, etc.). The encryption process includes key generation, encryption, decryption and other steps. The key generates a public key and a private key. The encryption uses the public key to convert the plaintext into ciphertext, and the decryption uses the private key to restore the plaintext. Homomorphic encryption allows specific calculations to be performed on the ciphertext (such as homomorphic operations of addition and multiplication), and the calculation result is still the ciphertext. The encryption key is stored and distributed through a secure key management system (KMS). KMS uses a key encapsulation mechanism based on homomorphic encryption to protect data confidentiality and improve data availability and processing flexibility in the encrypted state.

[0011] (III) Step 3: Data confirmation and protection stage 1. Data access and operation records Establish a data access and operation log system. Use high-precision timestamp technology (such as atomic clocks or network time protocols to obtain precise time, with millisecond accuracy) to record data access time, verify the identity of the accessing user through digital certificates (based on asymmetric encryption and digital signature technology), and record the access data ID, access type (read, write, modify, delete, etc.) and results. For data operations, record the operation time, personnel, content (values ​​before and after modification, batch modification range rules, etc.) and data status before and after the operation (using data snapshot technology) to achieve traceability of operations, facilitate audit monitoring, and ensure data security.

[0012] 2. Data ownership protection mechanism (homomorphic encryption enhancement) Use digital watermarking technology to embed ownership information into data. Digital watermarks are divided into visible and invisible watermarks. After invisible watermarks are embedded in data, they do not affect the visual or usage effect. Extraction requires specific algorithms and keys. When creating or updating data, the owner's identifier (company name, personal ID, etc.) is encoded and embedded into the data carrier according to certain rules. At the same time, the data containing ownership information is re-encrypted using homomorphic encryption technology to ensure the confidentiality and integrity of ownership information in circulation and storage. Authorized users use decryption keys to obtain and verify ownership information, strengthen ownership protection, and improve the security and innovation of the ownership confirmation system.

[0013] The present invention also discloses a data rights confirmation device based on subject-object binding, which is characterized by: Data injection container preparation module Use data verification algorithms to verify data integrity and ensure that the data is correct before injecting it into a specific container. At the same time, convert the data into a unified format according to the container requirements, and convert business data in various formats into a structured database format to build a stable processing environment for subsequent rights confirmation operations. Data ID creation and permission configuration module

[0014] The owner injects an ID in the form of a unique identifier encrypted by an encryption algorithm to ensure security and uniqueness; the owner configures access rules for the container and sets permissions based on user roles. If the administrator has full control, ordinary users can only read or partially modify, and visitors can only view specific public data to bind the data subject and object; according to business needs, set access time to allow ordinary users to access relevant data; integrate an alarm mechanism with the security monitoring system to notify the owner and administrator in case of illegal access; formulate access denial policies and record denial logs; Data confirmation and protection module The first two steps realize the binding of the subject and the object in the container and clarify the ownership; establish a data operation log system to record the operator, the time accurate to milliseconds, and the operation content, to ensure data security and effective confirmation of rights, and promote legal circulation and utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 This is a flow chart of the data rights confirmation method based on subject and object binding of the present invention. DETAILED DESCRIPTION

[0016] A data rights confirmation method based on subject-object binding includes the following steps: (I) Step 1: Data injection into container preparation phase implementation 1. Data integrity verification implementation In the cross-domain data interaction scenario, taking the Internet of Medical Things (IoMT) as an example, the data transmission between the medical equipment (such as smart blood glucose meters, heart monitors, etc.) of Hospital A and the telemedicine data center. The data provider (i.e. the medical device itself) needs to perform strict data integrity verification before injecting the patient's physiological data (such as blood glucose level, heart rate, blood pressure, etc.) into the data storage container (the storage server of the data center). The SHA-256 hash function is used to calculate the data hash value. During the calculation, the continuously collected physiological data is divided into blocks according to a fixed time interval (such as the data collected every 5 minutes as a data block), and each block of data generates a hash value through complex logical operations. For example, each data block is first bit-reversed (each bit of data is inverted), and then a bitwise AND operation is performed (the adjacent two bits of data are ANDed) to obtain the intermediate value, and finally the intermediate values ​​of all data blocks are combined into a 256-bit hash value through a specific algorithm.

[0017] Hospital A stores the original data hash value in a local high-security encrypted storage device, which is protected by a high-strength password (such as a 256-bit AES encryption password) and can only be accessed by authorized equipment maintenance personnel and data security administrators. After the medical device calculates the hash value, it sends the hash value to the data server of Hospital A through a secure network transmission protocol (such as a TLS / SSL encrypted channel). The server obtains the original hash value from the encrypted storage device for comparison. If the comparison is consistent, it indicates that the data is complete and can be injected into the storage container of the data center; if it is inconsistent, the data repair mechanism is immediately triggered.

[0018] The data repair mechanism first checks the network connection status. If it is determined that the data error is caused by network transmission, try to retransmit the data. If the hash value is still inconsistent after retransmission, due to the sensitivity and importance of medical data, Hospital A will notify the data center to suspend the processing of the patient's data and contact the medical device manufacturer. The manufacturer remotely diagnoses whether the equipment is faulty. If the equipment is faulty, arrange technicians to repair it on site or update the equipment software remotely, and restore the data from the local cache of the device (if any). If the data in the cache is also damaged, according to the timestamp of the medical record, restore the most recent complete data from the previous regular data backup (stored in Hospital A's dedicated backup server, using redundant storage technology to ensure that data is not lost), recalculate the hash value and transmit it to the data center for verification and storage, and record the entire repair process (including repair time, cause, equipment involved and data scope, etc.) for subsequent audit and analysis.

[0019] 2. Implementation of data format standardization Considering that different medical devices may come from different manufacturers, the data formats vary greatly. For example, the blood glucose value data format output by a certain brand of blood glucose meter is "XX.XXmmol / L", while other devices may use the format of "XXmg / dL", and the date and time format may also be different (such as "YYYY / MM / DD HH:MM:SS" or "DD - MM - YYYY HH:MM"). According to the pre-established medical data format specifications, the pre-processing server in the data center will convert the data format before injecting it into the container.

[0020] For blood glucose value data, the system first identifies the unit format of the data. If it is "mg / dL", it is converted to the "mmol / L" format according to the conversion formula (1mmol / L = 18mg / dL), and two decimal places are uniformly retained. For the date and time format, it is uniformly converted to the "YYYY - MM - DD HH:MM:SS" format by parsing the separators and digital positions in the string. During the conversion process, the system also performs a data range check. For example, the blood glucose value should be within a reasonable range (such as between 2.5mmol / L and 25mmol / L. Exceeding this range may indicate data abnormality), and the time should be logical (such as not earlier than the device activation time and not later than the current time). If data abnormalities are found, the system marks the data and notifies the data administrator of Hospital A for verification and processing. It may be necessary to re-collect data or check the status of the equipment to ensure that the data format of the injection container is uniform and accurate.

[0021] (II) Step 2: Data ID creation and permission configuration phase implementation 1. Implementation of data ID creation and modification (data owner operation) In cross-domain scientific research cooperation projects, multiple research institutions (such as the biological laboratory of university A, the genetic research center of institute B, etc.) are involved in sharing gene sequencing data. The data owner (such as the chief researcher in charge of the sequencing project) creates a unique ID for the data to be injected into the container (the data sharing platform of the cooperation project). The owner uses the network interface of the device to obtain the MAC address of the computer network card (if the device supports it), combines the current timestamp accurate to nanoseconds (obtaining the synchronized time from a high-precision time server), the namespace customized based on the name of the cooperation project and the research field to which it belongs (such as "GENE_SEQ_PROJECT_ABC" for gene sequencing project ABC), high-quality random numbers generated by a cryptographically secure random number generator (to ensure the uniqueness of the ID worldwide), and the timing information of the creation order (a digital sequence that increases from 1) and other elements, and uses the GUID algorithm to generate a 128-bit globally unique identifier as the data ID.

[0022] When creating an ID, the owner records the relationship between each element and the data in detail, for example, key attributes such as sequencer model and sample source species are associated with the ID, and stored in the metadata database in the data management system of the collaborative project. The database uses a relational database management system (such as MySQL), and ensures data security and recoverability through regular backups (such as daily full backups and hourly incremental backups) and off-site backups (stored on servers in different geographical locations). When the data is updated due to new analysis results or supplementary experiments, the owner modifies the ID according to the updated content, such as adding a version number in the namespace (such as "GENE_SEQ_PROJECT_ABC_V2") or updating the timing information, and records the reason for the modification (such as "updating the data ID to reflect data changes due to the introduction of a new analysis algorithm") and the modification time in the metadata database so that other partners can understand the change history and logic of the data.

[0023] 2. Implementation of user authority settings (related to ordinary users) Taking the cross-domain e-commerce logistics cooperation project as an example, it involves multiple roles such as e-commerce platforms, logistics companies and suppliers. Permissions are set based on the RBAC model. For ordinary employees of the e-commerce platform (such as order processors), their role is defined as "order processing", and they are only granted the authority to read and process order-related data (such as order information, customer addresses, product lists, etc.), and cannot modify logistics and distribution related data (such as logistics order numbers, delivery status, etc.). The dispatcher role of the logistics company is defined as "logistics dispatch", with read and write permissions, and can view and update the transportation status of goods, vehicle dispatch information, etc., but cannot modify the order details of the e-commerce platform. The salesperson role of the supplier is defined as "supply management", which can only read the order data related to the goods they supply (such as order quantity, estimated delivery time, etc.), and cannot modify other data.

[0024] Permission setting information is stored in the access control list (ACL). The ACL is stored in a centralized database (such as the main database of the e-commerce platform) and its security is ensured by strict access control (such as only system administrators and authorized security personnel can modify the ACL). When a user accesses data, the system verifies the user's identity and permissions by querying the ACL. For example, when an e-commerce platform order processor logs in to the system to access order data, the system queries the ACL to verify whether he has the corresponding permissions. If the permission verification passes, access is allowed; otherwise, access is denied and the access attempt information (including access time, user identity, requested data resources, etc.) is recorded in the system's audit log to ensure the security and compliance of data access.

[0025] 3. Data access rule configuration (visitor related) implementation In the cross-domain enterprise data sharing platform scenario, enterprise A allows an external enterprise (enterprise B) to access some of its public data (such as product catalogs, corporate news, etc.) and data related to specific cooperation projects (such as data on joint marketing activities). For visitors from enterprise B to access the data of enterprise A, the data sharing platform server first verifies the identity source of the visitor. Before accessing, visitors from enterprise B need to obtain digital identity credentials (including enterprise B's logo, visitor's personal identity information and scope of authority, etc.) through an identity authentication agency recognized by enterprise A (such as a third-party authentication platform).

[0026] When a visitor initiates a data access request, the platform server parses the digital identity credentials in the request to determine whether it belongs to company B and whether the permissions meet the requirements. If the visitor requests to access public data (such as a product catalog), the platform directly allows access and records the access log (including access time, visitor identity, data page accessed, etc.). If a request is made to access specific cooperative project data, the platform further checks whether its scope of authority covers the project data. For example, if the cooperative project stipulates that the marketing department personnel of company B can only access the effect data of the promotion activity, when the marketing personnel request to access the data, the platform verifies their permissions and allows access; if they request to access the project budget data (beyond the scope of authority), the platform denies access and records detailed denial information (including denial time, visitor identity, requested data resources, denial reason, etc.). At the same time, the platform limits the visitor's access frequency, such as no more than 10 visits to the same page per minute, to prevent malicious crawlers or abuse of access and ensure data security.

[0027] 4. Implementation of data subject and object binding In cross-domain financial data trading scenarios, investors (data subjects) conduct stock trading through securities trading platforms, and the generated trading data (data objects) need to be bound to the subject and object. When registering on a securities trading platform, investors apply for a digital certificate from a digital certificate authority (CA), submitting personal identity information (such as name, ID number, contact information, etc.) and a public key (the public key portion of a public-private key pair generated locally by the investor). CA verifies the authenticity and legitimacy of the investor's identity by checking information with authoritative institutions such as the public security system and the banking system. After the review is passed, the CA uses its own private key to sign the digital certificate to ensure the authenticity and integrity of the digital certificate. When an investor trades stocks, the securities trading platform automatically binds the investor's digital certificate to the ID of the transaction data. At the same time, the object information of the transaction data is recorded in detail, including stock code, transaction quantity, transaction price, transaction time, transaction type (buy or sell), etc., and this information is associated with the data ID and stored in the transaction database. The database uses a high-security database management system (such as Oracle database, which is configured with powerful user authentication, access control and data encryption functions) to ensure the secure storage of data.

[0028] During data access and trading, the platform verifies the investor's digital certificate to determine their access rights and operation rights to trading data. For example, when an investor queries his or her own trading history, the platform obtains the investor's digital certificate and verifies the certificate's signature, validity period, and whether the investor's identity matches the data subject. If the verification is successful, the investor can view his or her own trading records; if the investor attempts to modify or delete completed trading records (beyond his or her authority), the platform denies access and records security events (including access attempt time, investor identity, requested data operations, and reasons for denial, etc.), ensuring the security of financial trading data and the protection of investor rights.

[0029] 5. Implementation of data encryption storage (homomorphic encryption application) Taking a cross-domain big data medical research project as an example, multiple medical institutions (such as Hospital C, Hospital D, etc.) and scientific research institutions (such as Research Institute E) share patients' medical data (such as electronic medical records, imaging data, etc.) for joint research. The data is encrypted and stored using a lattice-based homomorphic encryption algorithm. In the key generation phase, a dedicated key management agency (KMA) generates public and private keys using mathematical algorithms related to difficult lattice problems (such as the shortest vector problem). The public key is distributed to various medical institutions and scientific research institutions through a secure key distribution channel (such as encrypted using homomorphic encryption technology and transmitted over a dedicated network), and the private key is kept securely by the KMA.

[0030] When medical institutions inject patient data into storage containers (such as distributed cloud storage services), the data is encrypted using a public key. For example, for text data in a patient's electronic medical record (such as medical history, diagnosis results, etc.), it is first converted into a format suitable for encryption (such as encoding characters into digital sequences) and then encrypted. Image data (such as X-rays, CT scan images, etc.) are first preprocessed (such as compression, split into small blocks), and then each small block of data is encrypted. The encrypted medical data is stored in a distributed storage system in ciphertext form to ensure the confidentiality of the data during storage.

[0031] The lattice-based homomorphic encryption algorithm has additive and multiplicative homomorphic properties. In joint research, researchers can perform specific statistical analysis operations directly on the ciphertext, such as calculating the incidence of a certain disease in a certain number of patients (additive homomorphic operation) or calculating the correlation of patient recovery rates under different treatment plans (multiplicative homomorphic operation) without decrypting the data first. The calculation results are still in ciphertext form, and only authorized institutions with private keys (such as KMA or specific researchers in authorized scientific research institutions) can decrypt and view the final results. In this way, during the entire data sharing and research process, patient medical data is always encrypted, effectively protecting patient privacy, while improving the availability and processing flexibility of encrypted data, providing strong support for cross-domain medical big data research.

[0032] (III) Step 3: Implementation of data rights confirmation and protection stage 1. Data access and operation record implementation In the cross-domain cloud computing service scenario, enterprise F uses the computing resources of the cloud service provider to store and process enterprise data, and users (employees or authorized partners of enterprise F) access this data through the Internet. The cloud service provider has established a comprehensive data access and operation log system. When a user accesses data, the system uses an atomic clock to obtain a timestamp accurate to milliseconds to record the access time. The atomic clock synchronizes with the time signal of the global satellite navigation system (such as GPS or Beidou) to ensure high precision and accuracy of time.

[0033] At the same time, the user's identity is verified through a digital certificate. When the user logs in to the cloud service platform, the digital certificate is submitted. The platform uses the public key of the certificate authority (CA) to verify whether the signature of the certificate is valid, check whether the certificate is within the validity period, and extract the user identity information in the certificate (such as user name, company, user role, etc.). The system records the access data ID (obtained by querying the metadata in the cloud storage system), the access type (such as read, write, modify, delete, etc., determined according to the operation type requested by the user, such as GET in the HTTP request method for reading, POST for writing or modifying, etc.) and the result (success or failure) in detail. If the access request is allowed, the system records the result as "success" and records the amount of data returned to the user (such as the number of bytes of data read); if the access request is rejected (such as due to insufficient permissions or data does not exist), the system records the result as "failure" and records the reason for rejection (such as "insufficient permissions, the user does not have permission to write to the data" or "the data does not exist, the requested data ID is invalid").

[0034] These access records are stored in the cloud service provider's distributed log database, which uses shard storage and redundant backup technology (such as sharding data through multiple servers and regularly backing up data to off-site servers) to ensure high data availability and scalability. For example, logs are stored in shards according to the user's company or region to facilitate query and management. When enterprise F needs to audit data access, the cloud service provider can provide the corresponding access log data according to enterprise F's requirements. Enterprise F can understand the data access behavior of employees and partners by analyzing the log data, and promptly discover abnormal situations (such as unauthorized access, frequent data reading, etc.) to ensure data security.

[0035] 2. Implementation of data rights confirmation mechanism (homomorphic encryption enhancement) In the cross-domain digital content copyright protection scenario, content creators (such as writers, photographers, musicians, etc.) upload their works to digital content distribution platforms (such as online book platforms, photo library platforms, music platforms, etc.). The platform uses digital watermarking technology to embed ownership information into the data. For example, for e-books uploaded by writers, the platform encodes information such as the author's name, work ID, and creation time, and then embeds the encoded watermark information into the text content through a specific algorithm based on the book's text structure and format (such as chapter division, paragraph layout, etc.). This may be to modify the encoding value of certain specific characters or insert hidden marks at specific locations in the text, while ensuring that the book with the embedded watermark has no obvious difference in reading experience from the original book.

[0036] At the same time, the data containing ownership information is encrypted again using homomorphic encryption technology. During the upload process of the work, the platform uses a lattice-based homomorphic encryption algorithm to encrypt the work data (including text content, pictures, audio, etc.), and stores the encrypted work on the platform's server. When a copyright dispute occurs, the platform or copyright management agency can use the decryption key to decrypt the work, obtain the ownership information therein, and verify the ownership of the work. For example, if a work is suspected of infringement, the copyright management agency can obtain the encrypted work provided by the platform, decrypt it with the decryption key, extract the watermark information, and compare it with the information provided by the creator to determine the true owner of the work, protect the rights and interests of the creator, and enhance the security and innovation of the entire data confirmation system, effectively solving the copyright confirmation and protection issues in the process of cross-domain dissemination and use of digital content.

[0037] The above shows and describes the basic principles, main features and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions only describe the principles of the present invention. The present invention may be subject to various changes and improvements without departing from the spirit and scope of the present invention. These changes and improvements fall within the scope of the present invention. The scope of protection claimed by the present invention is defined by the attached claims and their equivalents.

Claims

1. A data rights confirmation method based on subject-object binding, characterized by comprising the following steps: Step 1: Prepare the data injection container Use data verification algorithms to verify data integrity and ensure that the data is correct before injecting it into a specific container. At the same time, convert the data into a unified format based on container requirements and convert business data in multiple formats into a structured database format. Step 2: Data ID creation and permission configuration The owner injects an ID in the form of a unique identifier encrypted by an encryption algorithm to ensure security and uniqueness; the owner configures access rules for the container and sets permissions based on user roles. The administrator has full control, while ordinary users can only read or partially modify data. Visitors can only view specific public data and bind data subjects and objects; ordinary users are allowed to access relevant data at set access times based on business needs; an alarm mechanism is integrated with the security monitoring system to notify owners and administrators in case of illegal access; access denial policies are formulated and denial logs are recorded; Step 3: Data Confirmation and Protection The first two steps realize the binding of the subject and the object in the container and clarify the ownership; establish a data operation log system to record the operator, the time accurate to milliseconds, and the operation content to ensure data security and effective rights confirmation.

2. According to claim 1, a data rights confirmation method based on subject-object binding is characterized by: The step 1 further includes the following contents: Data integrity check The hash value of the data is calculated using a hash function and compared with the pre-stored hash value of the original data. The hash function processes the data in blocks and uses specific logical operations to obtain a fixed-length hash value. Different data has different hash values. If the calculated hash value is consistent with the original hash value, it indicates that the data is complete. Otherwise, the data may be damaged during transmission or storage and needs to be repaired or retrieved. Data format standardization Standardize the data format according to predefined format specifications; uniformly encode text data from different sources into UTF-8 format, and unify the precision and units of numerical data; analyze data structure and format differences, and convert according to the target format requirements.

3. According to the data rights confirmation method based on subject-object binding according to claim 1, its characteristics are: The step 2 further includes the following contents: Data ID creation and modification The data owner uses the globally unique identifier GUID algorithm to create a unique ID for the data to be injected into the container; User Permission Settings The role-based access control (RBAC) model sets permissions for different user roles. The RBAC model associates roles with permissions, which are defined based on data operation types and data object scopes. Permission setting information is stored in the access control list (ACL), which stores the correspondence between users or roles and permissions in the form of a list. Data access rule configuration Configure visitor access rules based on data sensitivity and visitor sources; external visitors to the corporate official website can only access public data and can only browse; visitors from partner companies are granted limited read permissions for specific project data according to the agreement and cannot access other data; By setting access control logic on the server side, the visitor identity and the scope of the requested data can be determined; Binding of data subject and object Identify the data subject and use digital certificate technology to bind the subject information and data ID; Digital certificates follow the X.509 standard and after issuing a certificate to a subject, the subject's identity is verified with the help of a public key infrastructure; Data encryption storage The data is encrypted using a lattice-based homomorphic encryption algorithm. The security of the lattice-based homomorphic encryption algorithm is based on the lattice difficulty problem. The encryption process includes key generation, encryption, and decryption steps. The key generates a public key and a private key. The public key is used to convert plain text into cipher text for encryption, and the private key is used to restore plain text for decryption. Homomorphic encryption allows specific calculations to be performed on ciphertext, and the calculation results are still ciphertext; The encryption keys are stored and distributed through the secure key management system KMS. KMS adopts a key encapsulation mechanism based on homomorphic encryption to protect data confidentiality.

4. According to claim 3, a data rights confirmation method based on subject-object binding is characterized by: The GUID algorithm combines the computer network card MAC address, the current precise timestamp, a custom namespace, high-quality random or pseudo-random numbers, and timing information elements to generate a 128-bit globally unique identifier; when creating an ID, the data owner must ensure that it is closely associated with the key attributes of the data for subsequent identification and management; when the data is updated, merged, or split, the owner modifies the ID based on the actual situation to ensure the accuracy and validity of the ID, and synchronizes the modification records to the data management system.

5. According to claim 1, a data rights confirmation method based on subject-object binding is characterized by: The step three further includes the following contents: Data access and operation record implementation In the cross-domain cloud computing service scenario, enterprise F uses the computing resources of the cloud service provider to store and process enterprise data, and users access this data through the Internet; The cloud service provider has established a comprehensive data access and operation log system. When a user accesses data, the system uses an atomic clock to obtain a timestamp accurate to milliseconds to record the access time. The atomic clock is synchronized with the time signal of the global satellite navigation system; Implementation of data rights confirmation and protection mechanism In the cross-domain digital content copyright protection scenario, content creators upload their works to the digital content distribution platform; the platform uses digital watermarking technology to embed ownership information into the data; The data containing ownership information is encrypted again using homomorphic encryption technology. During the upload process of works, the platform uses a lattice-based homomorphic encryption algorithm to encrypt the work data and stores the encrypted works on the platform's server. When a copyright dispute occurs, the platform or copyright management agency can use the decryption key to decrypt the work, obtain the ownership information therein, and verify the ownership of the work.

6. According to claim 5, a data rights confirmation method based on subject-object binding is characterized by: Verify user identity through digital certificates. When users log in to the cloud service platform, they submit digital certificates. The platform uses the public key of the certificate authority (CA) to verify whether the signature of the certificate is valid, check whether the certificate is within the validity period, and extract the user identity information in the certificate. The system records the access data ID and access type in detail, which is determined according to the type of operation requested by the user; if the access request is allowed, the system records the result as "success" and the amount of data returned to the user; if the access request is denied, the system records the result as "failure" and the reason for the denial.

7. A data rights confirmation device based on subject-object binding, characterized by: Data injection container preparation module Use data verification algorithms to verify data integrity and ensure that the data is correct before injecting it into a specific container. At the same time, convert the data into a unified format based on container requirements and convert business data in multiple formats into a structured database format. Data ID creation and permission configuration module The owner injects an ID in the form of a unique identifier encrypted by an encryption algorithm to ensure security and uniqueness; the owner configures access rules for the container and sets permissions based on user roles. If the administrator has full control, ordinary users can only read or partially modify, and visitors can only view specific public data to bind the data subject and object; according to business needs, set access time to allow ordinary users to access relevant data; integrate an alarm mechanism with the security monitoring system to notify the owner and administrator in case of illegal access; formulate access denial policies and record denial logs; Data confirmation and protection module The first two steps realize the binding of the subject and the object in the container and clarify the ownership; establish a data operation log system to record the operator, the time accurate to milliseconds, and the operation content to ensure data security and effective rights confirmation.

Images