Metal A Metadata-Hiding File-Sharing System Weikeng Chen Raluca Ada Popa UC Berkeley
End-to-end encrypted file sharing Academia: DepSky, M-Aegis, Mylar, Plutus, ShadowCrypt, Sieve, SiRiUS Industry:
Encryption is not enough: Metadata still leaks • User identities: who read or wrote a file • File access patterns: which file is being read or written
Encryption is not enough: Metadata still leaks ACL: The attacker sees: Doctor, Alice • The doctor is accessing a file • The file is #1 #1 #2 #3 #1 • #1’s access control list Doctor Doctor
An attack using file access patterns Cancer Heart Diabetes #1 #2 #3 Filenames are also encrypted Doctor
An attack using file access patterns See counts of file access 1 Cancer Heart Diabetes #1 #2 #3 Read diabetes treatment Doctor Patient
An attack using file access patterns See counts of file access 1 1 Cancer Heart Diabetes #1 #2 #3 Read cancer treatment Doctor Patient
An attack using file access patterns Public database on disease incidence rate 239 37 877 Cancer Diabetes Heart 2.49 2. 49 ‰ 0. 0.39 39 ‰ 8. 8.61 61 ‰ Cancer Heart Diabetes #1 #2 #3 Doctor
An attack using file access patterns Cancer Heart Diabetes Filenames inferred Cancer Heart Diabetes #1 #2 #3 Doctor
Reveal a patient’s disease I saw Alice in the waiting room Cancer Heart Diabetes Cancer Heart Diabetes #1 #2 #3 Read a treatment Doctor Alice
Reveal a patient’s disease Alice has cancer Cancer Heart Diabetes Cancer Heart Diabetes #1 #2 #3 Read a treatment Doctor Alice
Encryption is not enough: Metadata still leaks • User identities: who read/wrote a file • File access patterns: which file is being read/written
Existing solution: PIR-MCORAM [MMRS17] Single-server, secure against malicious users Scan all the files Lower bound: Single-server construction has linear server computation in # of files Example: Access a 64KB file in a million-file storage PIR-MCORAM’s amortized time > "# min
Existing solution: Anonymous RAM [BHKP16] Assumes two semi-honest servers that do not collude Logarithmic overhead Server 1 Does not support file sharing Server 2 Expensive zero-knowledge proofs
Metal Assumes two semi-honest servers that do not collude Logarithmic overhead Server 1 Support file sharing Server 2 Much faster 500 × faster than PIR-MCORAM and 20 × faster than AnonRAM
Metal’s three components Anonymous access control See paper Permission sharing Oblivious storage with malicious users
Metal’s threat model Server 1 Some users can be malicious Server 2
Metal’s goals Any given access should be oblivious among all the files Privacy accessible by the honest users Efficiency
Metal’s file layout Decryption key: Server 1 secret-shared between the two servers Server 2
Secure two-party computation (S2PC) [Yao86] Input Output ! " # " Security guarantee: S2PC Each server only learns its own # 1 , # 2 = ((! 1 , ! 2 ) input and output Input Output ! + # +
Our S2PC uses reactive Yao’s protocol … The S2PC is a continuous service , Stateful S2PC rather than a one-time computation …
Strawman 1: All files in S2PC Read #1 #1 #3 #2 Security goal: • No server sees the file
Strawman 1: All files in S2PC Read #1 #1 #3 #2 S2PC Security goal: • No server sees the file #1
Strawman 1: All files in S2PC each bit Read #1 256 bits #1 #3 #2 S2PC Problem: Very large S2PC circuit #1
Oblivious RAM [Goldreich86, Ostrovsky90] Access a file in a way that hides which file and is efficient I don’t know which file Read/write a file ORAM protocol ORAM Client ORAM Server The ORAM server only accesses log(N) files
Strawman 2: S2PC + ORAM ORAM Client ? S2PC ORAM ORAM Server Client
Strawman 2: S2PC + ORAM Read #1 S2PC Problem: Read #1. Still very large S2PC circuit ORAM (e.g., 75 s per access) ORAM Server Client ORAM protocol
Technique: Synchronized inside-outside ORAM Observation: For efficiency, data should be outside S2PC Synchronize Small indices Big file data ORAM IndexORAM DataORAM Accessed by Accessed by Yao’s protocol public-key protocols Challenge: Synchronizing IndexORAM and DataORAM
Encryption in DataORAM • Use ElGamal encryption • One can rerandomize a ciphertext using the public key Can be leveraged in designing oblivious protocols DataORAM
ORAM access In ORAM, access to a file downloads data on a path Path ! ORAM Client ORAM Server
Synchronized ORAM access in Metal Path ! ORAM Client IndexORAM
Synchronized ORAM access in Metal Secret-share the position To Server 1 Path ! Pos (1) Pos = 2 Pos (2) To Server 2 ORAM Client The desired file IndexORAM
Synchronized ORAM access in Metal Challenge: Pos (1) Obtains the data obliviously Pos (2) DataORAM
Synchronized ORAM access in Metal Challenge: Pos (1) Obtains the data obliviously Uses secret-shared doubly oblivious transfer Pos (2) DataORAM A rerandomized ciphertext of the file
Synchronized ORAM access in Metal Challenge: Pos (1) Obtains the data obliviously The two servers then run Pos (2) threshold decryption to return the plaintext data. DataORAM Only the user sees the data
ORAM update The client updates the ORAM by reorganizing the files Path ! 1 , ! 2 ORAM Client ORAM Server
Synchronized ORAM update in Metal Path ! 1 , ! 2 ORAM Client IndexORAM Challenge: securely apply the same update on DataORAM
Technique: Tracking and permutation generation Old A B C --- --- the ORAM update can be expressed as a permutation New A --- B --- C Path ! 1 , ! 2 σ ORAM Client IndexORAM
Synchronized ORAM update in Metal Secret-share the permutation Path ! 1 , ! 2 To Server 1 σ (1) σ σ (2) To Server 2 ORAM Client IndexORAM
Synchronized ORAM update in Metal Challenge: σ (1) Applies the permutation, but hides the permutation Each server performs a secret share of permutation in turn σ (2) DataORAM
Synchronized ORAM update in Metal Challenge: σ (1) Applies the permutation, but hides the permutation Applied σ (1) Each server performs a secret share of permutation in turn σ (2) Ciphertexts are rerandomized during the permutation. DataORAM Applied σ (2)
Synchronized IndexORAM and DataORAM Synchronize IndexORAM DataORAM The two techniques improve over S2PC + ORAM by 20 ×
Evaluation setup Metal is implemented in C/C++ using the Obliv-C platform [ZE15] Evaluation setup: Two servers, one in Northern California, one in Oregon • One client, in Canada •
Metal’s file access latency The file access latency is within a few seconds 500 × faster than PIR-MCORAM and 20 × faster than AnonRAM
Metal A Metadata-Hiding File-Sharing System www.oblivious.app Thank you!
Recommend
More recommend
