From df16d6f825f140baf7fff9ef3db67f2eda7ebb61 Mon Sep 17 00:00:00 2001 From: yzr95924 Date: Fri, 23 Sep 2022 23:21:05 +0800 Subject: [PATCH] update the paper list --- .../Post-Dedup}/MeGA-ATC'22.md | 0 StoragePaperNote/DeltaCompression-FAST'12.md | 34 ----- StoragePaperNote/NeXUS-DSN'19.md | 39 ------ StoragePaperNote/SGXExplained-IACR'16.md | 128 ------------------ StoragePaperNote/SecDep-MSST'15.md | 113 ---------------- StoragePaperNote/TinyLFU-ToS'17.md | 35 ----- 6 files changed, 349 deletions(-) rename StoragePaperNote/{ => Deduplication/Post-Dedup}/MeGA-ATC'22.md (100%) delete mode 100644 StoragePaperNote/DeltaCompression-FAST'12.md delete mode 100644 StoragePaperNote/NeXUS-DSN'19.md delete mode 100644 StoragePaperNote/SGXExplained-IACR'16.md delete mode 100644 StoragePaperNote/SecDep-MSST'15.md delete mode 100644 StoragePaperNote/TinyLFU-ToS'17.md diff --git a/StoragePaperNote/MeGA-ATC'22.md b/StoragePaperNote/Deduplication/Post-Dedup/MeGA-ATC'22.md similarity index 100% rename from StoragePaperNote/MeGA-ATC'22.md rename to StoragePaperNote/Deduplication/Post-Dedup/MeGA-ATC'22.md diff --git a/StoragePaperNote/DeltaCompression-FAST'12.md b/StoragePaperNote/DeltaCompression-FAST'12.md deleted file mode 100644 index 5244cd2..0000000 --- a/StoragePaperNote/DeltaCompression-FAST'12.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -typora-copy-images-to: ../paper_figure ---- -WAN Optimized Replication of Backup Datasets Using Stream-Informed Delta Compression ------------------------------------------- -| Venue | Category | -| :------------------------: | :------------------: | -| FAST'12 | Delta compression | -[TOC] - -## 1. Summary -### Motivation of this paper -- Motivation -Improved compression is needed to make WAN replication practical. -> deduplication + delta compression - -It proposes a new method which not only eliminates duplicate regions of files (deduplication) but also compresses *similar* regions of files with **delta compression**. - - - - -### Method Name - -### Implementation and Evaluation - -## 2. Strength (Contributions of the paper) -1. New architecture: -adds *stream-informed* delta compression to already existing deduplication systems and eliminates the need for new, persistent indexes. - - -## 3. Weakness (Limitations of the paper) - -## 4. Some Insights (Future work) - diff --git a/StoragePaperNote/NeXUS-DSN'19.md b/StoragePaperNote/NeXUS-DSN'19.md deleted file mode 100644 index 54f9695..0000000 --- a/StoragePaperNote/NeXUS-DSN'19.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -typora-copy-images-to: ../paper_figure ---- -NEXUS: Practical and Secure Access Control on Untrusted Storage Platforms using Client-side SGX ------------------------------------------- -| Venue | Category | -| :------------------------: | :------------------: | -| UCC'19 | Data Encryption | -[TOC] - -## 1. Summary - -### Motivation of this paper -- Motivation - - File sharing: allow user to store, share and synchronize files online. - - Secure issues: - - frequent data breaches - - data confidentiality and integrity - - **Purely cryptographic approaches** incur very high overheads on user revocation. - - when decrypting files on a client machine, the encryption key is inevitably exposed to the client application and can be cached by the user. (need *re-encryption*) - - Existing approaches - - require server-side hardware support (limits their availability for users of personal cloud storage services) - - should not rely on the service provider - - -### NEXUS -- Main Idea - - Leverage Intel SGX to provide efficient access control and policy management - - client-side cryptographic operations implemented inside an SGX enclave. - - embeds user-specified access control policies into *files' cryptographically protected metadata*. (enforced by the enclave, smaller attached metadata) - -### Implementation and Evaluation - -## 2. Strength (Contributions of the paper) - -## 3. Weakness (Limitations of the paper) - -## 4. Some Insights (Future work) - diff --git a/StoragePaperNote/SGXExplained-IACR'16.md b/StoragePaperNote/SGXExplained-IACR'16.md deleted file mode 100644 index 58117b9..0000000 --- a/StoragePaperNote/SGXExplained-IACR'16.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -typora-copy-images-to: ../paper_figure ---- -Intel SGX Explained ------------------------------------------- -| Venue | Category | -| :------------------------: | :------------------: | -| IACR'16 | SGX | -[TOC] - -## 1. Overview - -- The root problem (confidentiality and integrity) - - Secure remote computation: executing software on a remote computer **owned and maintained by an untrusted party**. - - leveraging trusted hardware inn the remote computer - - relies on **software attestation** - - prove to a **user** that he is communicating with a specific piece of software running in a secure container hosted by the trusted hardware. - - Proof is a signature that certifies the hash of the secure container's contents. - -- Enclave - - Secure container - - contains the private data in a computation - - the code that operates on that data - -## 2. SGX programming model -### 2.1 SGX Physical Memory Organization -- Processor Reserved Memory (PRM) - - PRM is a subset of DRAM that cannot be directly accessed by other software. - - CPU's integrated memory controllers also reject DMA transfers targeting the PRM. - - ![image-20200717161721279](../paper_figure/image-20200717161721279.png) - -- Enclave Page Cache (EPC) - - Since a system can have multiple enclaves on a system at the same time, the EPC is split into 4KB pages that can be assigned to different enclaves. - - the same page size as the architecture's address translation feature. - - the EPC is managed by the same system software that manages the rest of the computer's physical memory - - a hypervisor or an OS kernel uses **SGX instructions** to allocate unused pages - - Most EPC pages are initialized by copying data from a non-PRM memory page. - -- Enclave Page Cache Map (EPCM) - - As the system software is not trusted, SGX processors check the correctness of the system software's allocation decisions. - - SGX records some information about the system software's allocation decisions for each EPC page in EPCM (store in "trusted memory") - - ![image-20200717175301020](../paper_figure/image-20200717175301020.png) - - page type: - - PT_REG (regular type): enclave's code and data - - PT_SECS (SGX Enclave Control Structures): store per-enclave metadata - -### 2.2 The memory layout of an SGX enclave -Describe the interaction between enclaves and non-enclave software - -- The Enclave Linear Address Range (ELRANGE) - - Each enclave designates an area in its **virtual address space**, call (ELRANGE) - - map the code and sensitive data stored in the enclave's EPC pages - - the virtual address space outside ELRANG is mapped to access non-EPC memory via the same virtual address. - - ![image-20200717223501471](../paper_figure/image-20200717223501471.png) - - when an enclave represents a **dynamic library**, it is natural to set ELRANGE to the memory range reserved for the library by the loader. - -## 3. Enclave Programming -- Several terms need to be clarified - - ECALL: "Enclave Call", a call made into an interface function within the enclave - - OCALL: "Out Call", a call made from within the enclave to the outside application - - Trusted Thread Context: the context for a thread running inside the enclave - - Thread control structure (TCS) - - Thread data/thread local storage: data within the enclave and specific to the thread. - - State save area: a data buffer which holds register state when an enclave must exit due to an interrupt or exception. - - Stack: a stack located within the enclave - -- General design approach - - identify the application's secret - - identify the providers and consumers of those secrets - - determine the enclave boundary - - tailor the application components for the enclave - -### 3.1 Enclave definition language (EDL) -An enclave must expose an API for untrusted code to call in (ECALLs) and express what functions provided by the untrusted code are needed (OCALLs). -> both ECALLs and OCALLs are defined by developers using EDL, they consist the enclave boundary. - -- EDL syntax - - An enclave's bridge functions - - ECALLs are prototyped in the trusted section, and OCALLs are prototyped in the untrusted section. - - the *Edger8r* tool that is included with the Intel SGX SDK parses the EDL file and generates a series of **proxy functions**. - - these proxy functions are wrappers around the real functions that are prototyped in the EDL. - - Each ECALL and OCALL gets a pair of proxy functions (a trusted half and untrusted half) - - trusted proxy functions: $EnclaveName$\_t.h and $EnclaveName$\_t.c - - untrusted proxy functions: $EnclaveName$\_u.h and $EnclaveName$\_u.c -```c++ -enclave { - // Include files - // Import other edl files - // Data structure declarations to be used as parameters of the function prototypes in edl - - trusted { - // Include file if any. It will be inserted in the trusted header file (enclave_t.h) - // Trusted function prototypes (ECALLs) - }; - - untrusted { - // Include file if any. It will be inserted in the untrusted header file (enclave_u.h) - // Untrusted function prototypes (OCALLs) - }; -}; -``` - -- The proxy functions are responsible for: - - Marshaling data into and out of the enclave - - Placing the return value of the real ECALL or OCALL in an address referenced by a pointer parameter - - Returning the success of failure of the ECALL and OCALL itself as an "sgx_status_t" value. - - - -- ECALL and OCALL processes - - Program does not call the ECALL and OCALL function **directly**. - - make an ECALL: - - call the untrusted proxy function for the ECALL, which in turn calls the trusted proxy function inside the enclave. - - that proxy then calls the "real" ECALL and the return value propagates back to the untrusted function. - -![image-20200718163048858](../paper_figure/image-20200718163048858.png) - -- The process to build a enclave program - - write the Enclave Definition Language (EDL) - - write the application that uses the enclave - - define the global enclave id - - As it is in the untrusted application, we must include "sgx_urts.h" - - include: "sgx_create_enclave" function, officially initialize the enclave instance. - - include: "sgx_destroy_enclave()" function, destroy the targeted enclave. - - also include "Enclave_u.h", which will include all of the ECALL proxies generated from the EDL file after compilation - - define the functions which should be put in enclave (e.g., in "Enclave.h") - - put those functions in the trusted section of "Enclave.edl" - diff --git a/StoragePaperNote/SecDep-MSST'15.md b/StoragePaperNote/SecDep-MSST'15.md deleted file mode 100644 index 40937b8..0000000 --- a/StoragePaperNote/SecDep-MSST'15.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -typora-copy-images-to: ../paper_figure ---- -SecDep: A User-Aware Efficient Fine-Grained Secure Deduplication Scheme with Multi-Level Key Management ------------------------------------------- -| Venue | Category | -| :-----: | :------------------: | -| MSST'15 | Secure Deduplication | -[TOC] - -## 1. Summary -### Motivation of this paper -Convergent encryption suffers brute-force attacks or incurs large computation overheads. -> 1. deterministic and keyless issues. -> 2. for chunk-level deduplication: each chunk performs the time-consuming RSA-OPRF protocol to generate message-locked key. (incur significant computation overhead) - -Existing key management approaches of convergent encryption incur -> 1. large key space overhead -> 2. single-point-of-failure - -This paper proposes the SecDeup which exploits redundant data distribution among and inside users, and use variants of CE to make a trade-off between **data security and duplicate detection performance**. - -**Key Observation** -1. Cross-user redundant data are mainly from the duplicate files. Inside-user redundant data are mainly from the duplicate chunks. -2. Cross-user level deduplication and inside-user deduplication schemes face different security challenges. -> Cross-user level deduplication: high overhead. - -### SecDep -- Key Idea -Instead of using global chunk-level deduplication, SecDep combines cross-user file-level and inside-user chunk-level secure deduplication to eliminate more redundant data. -> file-level deduplication: server-aided hash convergent encryption -> chunk-level deduplication: user-aided convergent encryption -> cross-user file-level and inside-user chunk-level deduplication - -- System Model - -![1558614554155](paper_figure/1558614554155.png) - -- Threat Model -Mainly focus on internal adversaries which can -> 1. compromising the SP -> 2. colluding with users -> 3. stealing data from the DKS - -Security Goal -> 1. data confidentiality: the data copies are secure to -> 2. security of keys: - -- User-Aware Convergent Encryption (UACE) - - -- Multi-Level Key Management -It includes three kinds of keys: file-level keys, chunk-level keys, share-level keys. - -![1558623033915](paper_figure/1558623033915.png) - -- Security analysis -Ensure **data confidentiality** and **key security**. Consider two types of adversaries: -> internal adversary (mainly focus on): -> external adversary: could resist the external attacks by authentication. - -1. security of data -> including data confidentiality and integrity - -2. security of keys -> distribute keys in several key servers by using the known SSSS (secret sharing). - -3. security of SecDep -**Best case**: the adversary only compromise the SP, but cannot access to DKS -> the adversary cannot know the content of other users data even if it can perform brute-force attacks. - -**Semi-best case**: the adversary has compromisd, and can access to DKS -> SecDep can ensure data security, the adversary cannot break the encryption key due to not knowing the user's secret. - -**Worst casr**: the adversary obtains some users' secrets -> SecDep can still ensure security for unpredictable data that are not falling into a known set. - -### Implementation and Evaluation -- Evaluation -Compare with: -> Baseline: without any security mechanisms. -> DupLESS-chunk: chunk-level DupLESS -> DupLESS-file: file-level DupLESS -> SecDep - -Dataset: -> 1. synthetic dataset: -> 2. real-word datasets: - -1. Sensitivity study on size & number of files -2. Sensitivity study on average chunk size -3. - -## 2. Strength (Contributions of the paper) -1. A modified version of CE: user-aware convergent encryption (UACE) approach to resist brute-force attack and reduce time overhead. -2. Multi-level key management (MLK): ensure key security and reduce key space overheads. - -3. This paper considers the issue of the key space overhead -> rarely to consider in other papers - -## 3. Weakness (Limitations of the paper) -1. This paper intends to only eliminate duplicate files across different users, but it can only obtain the storage saving of majority of duplicate data. -> incur the loss of dedup factor compared with (2.8-7.35%) - - -## 4. Future Works -1. This paper gives a good summary of state-of-art secure deduplication schemes. - -2. RSA-OPRF protocol is time-consuming -> will incur huge computation and time overheads for chunk-level deduplication. -> Large number of chunks incur hugh computation overheads - -3. This paper argues suggests that cross-user redundant data are mainly from duplicate files. \ No newline at end of file diff --git a/StoragePaperNote/TinyLFU-ToS'17.md b/StoragePaperNote/TinyLFU-ToS'17.md deleted file mode 100644 index ffb92bc..0000000 --- a/StoragePaperNote/TinyLFU-ToS'17.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -typora-copy-images-to: ../paper_figure ---- -TinyLFU: A Highly Efficient Cache Admission Policy ------------------------------------------- -| Venue | Category | -| :------------------------: | :------------------: | -| ToS'17 | Cache | -[TOC] - -## 1. Summary -### Motivation of this paper -- Perfect LFU (PLFU): is an **optimal** policy when the access distribution is **static** - - Limitations: - - the cost of maintaining a complete frequency histogram for all data items ever accessed is prohibitively high. - - cannot adapt to dynamic changes in the distribution. - -### Method Name - -### Implementation and Evaluation - -## 2. Strength (Contributions of the paper) - -## 3. Weakness (Limitations of the paper) - -## 4. Some Insights (Future work) -- Locality - - characterize the access frequency of all possible data items through a **probability distribution** - - the probability distribution is highly skewed (a small number of objects are much more likely to be accessed than other objects). -- Least frequently used (LFU) - - When the probability distribution of the data access pattern **constant** over time, it is easy to show that the LFU yields the highest cache hit ratio. -- LRU v.s. LFU - - LRU can be implemented much more efficiently than LFU. - - LRU can automatically adapt to temporal changes in the data access patterns and to bursts on the workloads. -