Proof of Retrievability Deduplication via Secret Key Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional proof of retrievability methods in cloud storage systems fail to account for storage-efficiency requirements like multi-tenancy and data deduplication, leading to inefficiencies and security concerns due to the need for shared secret material among tenants.
Innovation Solution
A method that divides files into chunks, computes secret keys, and generates chunk identifiers, allowing for deduplication of both file data and proof-of-retrievability tags across untrusted tenants without requiring shared secret material, using oblivious key generation and erasure coding for enhanced security and efficiency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional proof of retrievability methods are used with shared secret material among tenants, then verification of data integrity is improved, but storage overhead and security risks increase due to inability to deduplicate tags across untrusted tenants
Solution Approach 1:
The system segments the secret key into multiple shares using secret sharing schemes, distributing them across different tenants. Each tenant receives only their portion of the key material, enabling individual tag generation without requiring full key sharing. This segmentation allows deduplication of proof tags while maintaining security among untrusted tenants.
Solution Approach 2:
The patent introduces a trusted third party or intermediary entity that facilitates key generation and distribution. This intermediary helps establish shared secret material without requiring direct trust between tenants, enabling proof of retrievability verification while allowing tag deduplication across tenants through controlled key sharing mechanisms.
2Reliability
If each tenant constructs and stores their own proof tags independently, then security and trust among tenants is maintained, but storage efficiency deteriorates due to inability to deduplicate tags
Solution Approach 1:
The patent creates a universal key sharing mechanism that enables multiple tenants to generate proofs using shared secret material. This universal approach allows the same proof tags to be generated for identical data across different tenants, enabling deduplication while maintaining the ability to verify data integrity for each tenant independently.
Solution Approach 2:
The system merges the key generation process across tenants through secret sharing, combining individual tenant keys into a shared secret structure. This merging enables tag deduplication by allowing identical proofs to be generated for the same data, while the distributed nature of the shared secret maintains security and trust boundaries among tenants.
3Ease of operation
If secret material is shared among tenants for proof generation, then proof of retrievability verification is enabled, but security deteriorates due to trust requirements among untrusted tenants
Solution Approach 1:
The patent implements preliminary key setup and secret sharing before data storage and proof generation. By pre-distributing key shares and establishing trust boundaries in advance, the system enables proof verification without requiring ongoing trust or direct key sharing between tenants during operation, reducing security risks from malicious behavior.
Solution Approach 2:
A trusted intermediary or authority is introduced to manage key distribution and verification processes. This intermediary acts as a neutral party that enables proof of retrievability verification while preventing direct trust requirements between untrusted tenants, mitigating security risks through controlled mediation of cryptographic operations.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The present invention relates to a method for storing data on a storage entity (SE), comprising the steps of: a) Dividing a file to be stored into a number of chunks by a client, b) Computing a secret key for each chunk of said file, c) Computing for each chunk a chunk identifier by said client, d) Checking, by said SE, if one or more of said chunks have already been stored based on said computed chunk identifiers, e) In case one or more of said chunks have not already been stored: - Encoding the corresponding chunks; - Computing chunk tags for said chunks using said computed secret key; - Storing said encoded chunks and said chunk tags.