On personal computers ?

Yüklə 445 b.
ölçüsü445 b.

On personal computers ?

  • On personal computers ?

  • 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



    • 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:

  • 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)

    • 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.

Yüklə 445 b.

Dostları ilə paylaş:

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2022
rəhbərliyinə müraciət

    Ana səhifə