On personal computers ?

On personal computers ?

• On personal computers ?

• Self-administration, security

• On a cloud service ?

• May worsen the privacy problem

• PlugDB: a secure personal Web which…

• is self-administered
• interfaces with user devices
• stores, indexes, queries, recovers data
• authenticates, evaluates access & usage control

• …and offers strong privacy and security guarantees

Token Characteristics :

• Token Characteristics :

• High security:

• High ratio Cost/Benefit of an attack;
• Secure against its owner;

• Modest computing resources (~10Kb of RAM, 50MHz CPU);

• Low availability: physically controlled by its owner; connects and disconnects at it will

PROBLEM :

• PROBLEM :

• How to perform global queries on the asymmetric architecture? (i.e. using data from many/all cells)

Several approaches are possible to securely perform global computations:

• Several approaches are possible to securely perform global computations:
• Use only an untrusted server/cloud/P2P and use generic (and costly) algorithms. (e.g. Secure Multi-Party Computing [Yao82, GMW87, CKL06], fully homomorphic encryption [Gent09]) Problem = COST
• Use only an untrusted server/cloud/P2P and develop a specific algorithm for each specific class of queries or applications. (e.g. DataMining Toolkit [CKV+02]) Problem = GENERICITY
• Introduce a tangible element of trust, through the use of a trusted component and develop a generic methodology to execute any centralized algorithm in this context. ([Katz07, GIS+10, AAB+10])  Problem = TRUST

Querier:

• Querier:

• Shares the secret key with TDSs (for encrypt the query & decrypt result).

• Classical Access control policy (e.g. RBAC):

• Cannot get the raw data stored in TDSs (get only the final result)
• Can obtain only authorized views of the dataset ( do not care about inferential attacks)

• Supporting Server Infrastructure:

• Doesn’t know query (so, attributes in GROUP BY clause) b/c query is encrypted by Querier before sending to SSI.

• Has prior knowledge about data distribution.

• Honest-but-curious attacker: Frequency-based attack

• Malicious attacker: detect to deter

The main difficulty is with AGGREGATE QUERIES !!

• The main difficulty is with AGGREGATE QUERIES !!

• Solutions vary depending on which kind of encryption is used, how the SSI constructs the partitions, and what information is revealed to the SSI.

• Secure aggregation solution (presented briefly here)

• Noise-based solutions (see paper)

• random (white) noise
• noise controlled by the complementary domain

• Histogram-based solutions (see paper)

• We investigate these solutions along the directions of performance and security.

Secure Aggregation Efficiency problem :

• Secure Aggregation Efficiency problem :

• nDet_Enc on AG  SSI cannot gather tuples belonging to the same group into same partition.

Distribution of AG is discovered and distributed to all TDSs.

• Distribution of AG is discovered and distributed to all TDSs.

• TDS allocates its tuple to corresponding bucket.

• TDS send to SSI: {h(bucketId),nDet_Enc(tuple)}

• Consequences :

Internal time consumption

• Internal time consumption

Dataset size Ttuple : varies from 5 to 65 million

• Dataset size Ttuple : varies from 5 to 65 million

• Number of groups G : varies from 1 to 106

• Number of TDSs participating in the computation as a percentage of all TDSs connected at a given time Ttds : varies from 1% to 100%).

• We fix two parameters and vary the other, measuring : execution time, parallelism of the protocol, total load, maximum load on one TDS

• When the parameters are fixed :

• Ttuple =106, G=103, % of TDS connected = 10% of Ttuple.

• We also compute and use the optimal value for all reduction factors as well as for.

• In the figures, we plot two curves for Rnf_Noise protocols RN (nf = 2) and WN (nf = 1000) to capture the impact of the ratio of fake tuples.

Total Load

• Total Load

Select ..

• Select ..

• From ..

• Where ..

• Group By AG

• G = card (AG)

• Security: S_Agg > ED_Hist

• Performance:

• G > 10:
• ED_Hist faster than S_Agg
• G <= 10:
• ED_Hist slower than S_Agg

SQL (With SMIS)

• SQL (With SMIS)

• Queries here do not have joins !
• Take into account more attack models (e.g. Broken Tokens)
• Field experiment on usability (with ISN / A. Katsouraki PhD thesis)

• Private/Secure MapReduce (With LIPN -- some results in Coopis’15)

• Investigate compatibility of our protocols.
• Develop new protocols.
• Check performance !

• Secure Graph computations (With LIX)

• Study social networking applications
• Secure K-core and k-truss computations (Rossi PhD thesis)

• Anonymisation

• Axel Michel’s Ph.D. : participation in aggregate queries with user constraints (k-anon)

Trusted Cells “Core”

• Trusted Cells “Core”

• Important features already devised (Inria + INSA CVL)
• Authentification, Relational DBMS + RBAC, Search engine, (global) anonymization, distributed SQL, secure data recovery…
• Contact me for refs 
• Many interesting perspectives
• Usage control & enforcement, data sharing schemes, complex computation (sandboxes), other data types (eg, time series), global computing models (eg, Map Reduce), etc.
• Integrated into a platform for education (PlugDB)
• “Systèmes d’Information Privacy-by-Design” at ENSIIE, UVSQ, INSA CVL : Tutorials, exercises, project topics…  develop a community !

• Beyond Tamper Resistant HW

• Results are useable even with lower trust elements.
• Include social trust / reputation.
• Use virtualization.