cryptography 4 people - ibm · 3/16/2017 · 3 zisc lunch seminar 15.3.2017 - jan camenisch - ibm...

© 2016 IBM Corporation

Cryptography 4 PeopleDatabasesJan CamenischPrinciple RSM; Member, IBM Academy of TechnologyIBM Research – Zurich

@JanCamenischibm.biz/jancamenisch

ZISC Lunch Seminar, ETH Zurich, March 15, 2017

© 2016 IBM Corporation2 ZISC Lunch Seminar 15.3.2017 - Jan Camenisch - IBM Research - Zurich

We increasingly conduct our daily task electronically, in an increasingly electronic environment, and

Facts

....are becoming increasingly vulnerable to cybercrimes


33% of cyber crimes, including identity theft, take less time than to make a cup of tea.

Facts


10 Years ago, your identity information on the black market was worth $150. Today….

Facts


$4'500'000'000 cost of identity theft worldwide

Facts


ﾩ

Houston, we have a problem!


ﾩ

Houston, we have a problem!

“Buzz Aldrin's footprints are still up there”(Robin Wilton)


Computers don't forget

! Apps built to use & generate (too much) data

! Data is stored by default

! Data mining gets ever better

! New (ways of) businesses using personal data

! Humans forget most things too quickly

! Paper collects dust in drawers


Where's all my data?

The ways of data are hard to understand

! Devices, operating systems, & apps are getting more complex and intertwined

– Mashups, Ad networks– Machines virtual and realtime configured– Not visible to users, and experts– Data processing changes constantly

! IoT makes things harder still– unprotected network, – devices with low footprint– different operators– no or small UI

→ No control over data and far too easy to loose them


The real problem

Applications are designed with the sandy beach in mind but are then built on the moon.

– Feature creep, security comes last, if at all– Everyone can do apps and sell them – Networks and systems hard not (well) protected


We need paradigm shift: build stuff for the moon

rather than the sandy beach!

Security & Privacy is not a lost cause!


That means:! Data minimization in all applications! Encrypt every bit! Attach usage policies to each bit

Cryptography can do that!

Security & Privacy is not a lost cause!


Mix Networks

Priced OT

Private information retrieval

Onion Routing

e-voting

Confirmer signatures

Group signatures

Anonymous Credentials

OT with Access Control

Oblivious Transfer

Blind signatures

Secret Handshakes

Group signatures

Pseudonym Systems

Searchable Encryption

Homomorphic Encryption

Cryptography to the Aid!


Unlinkable Identifiers for Databases [Camenisch&Lehmann CCS' 15, EuroS&P 17]


How to maintain related yet distributed data?

Example use case: social security system! Different entities maintain data of citizens! Eventually data needs to be exchanged or correlated

Health Insurance

HospitalDoctor B

Doctor A

Welfare CenterTaxAuthority

Pension Fund


IoT Use case – Car Example

garage

insurer

road infrastructure

sellermanufacturer

parts provider

Many other different use case: IoT, Industry 4.0, Home Appliances, Metering, ...


Requirements

! Data originating from (or being related to) an individual! Interactions with many different parties who share, exchange, and store data! Data needs to be protected

– Stored in encrypted form– Anonymized– Stored distributedly (different data base, different data controller)– User needs to be informed where data resides, how it is processed etc

! Still different parties want to use data– No too much anonymized, otherwise not usable anymore– If somewhat anonymized, how can user still keep track?

! How can we do this?


Globally Unique Identifier

! user data is associated with globally unique identifier– e.g., social security number, insurance ID

! different entities can easily share & link related data records

ID Data

Bob.0411

Carol.2503

Dave.1906

ID Data

Alice.1210

Bob.0411

Carol.2503

Hospital

Doctor A

Record ofBob.0411?


Globally Unique Identifier

! user data is associated with globally unique identifier– e.g., social security number, insurance ID

! different entities can easily share & link related data records

+ simple data exchange

– no control about data exchange– if records are lost, pieces can be linked together– data has high-value requires strong protection→

ID Data

Bob.0411

Carol.2503

Dave.1906

ID Data

Alice.1210

Bob.0411

Carol.2503

Hospital

Doctor A

Record ofBob.0411?


Using Privacy-ABCs to derive Identifiers

! Use user generated pseudonym– Needs to be consistent

• per database• across databases

ID Data

fadl039nd

d028naid8

10nziadod

Doctor A

ID Data

o1anlpzAd

Landi1nad

p1msLzna

Hospital


Users' Keys:! One secret Identity (secret key)! Many Public Pseudonyms (public keys)! Variation: domain pseudonym – unique per domain

Privacy-protecting authentication with Privacy ABCs

→ use a different identity for each database or even each record


Certified attributes from Identity provider! Issuing a credential


Name = Alice DoeBirth date = April 3, 1997



- eID with age ≥ 12

Proving identity claims! but does not send credentials! only minimal disclosure



! Use Domain pseudonym! Plus proof that there is a real person behind

ID Data

fadl039nd

d028naid8

10nziadod

Doctor A

ID Data

o1anlpzAd

Landi1nad

p1msLzna

Hospital



! Use Domain pseudonym! Plus proof that there is a real person behind! Can use credentials to transfer data

ID Data

fadl039nd

d028naid8

10nziadod

Doctor A

ID Data

o1anlpzAd

Landi1nad

p1msLzna

Hospital



! Use Domain pseudonym! Can use credentials to transfer data

– data exchange needs to involve user

+ control about data exchange+ lost records are cannot be linked together

ID Data

fadl039nd

d028naid8

10nziadod

Doctor A

ID Data

o1anlpzAd

Landi1nad

p1msLzna

Hospital


Local Pseudonyms & Trusted “Converter”

! central converter derives independent server-local identifiers from unique identifier! user data is associated with (unlinkable) server-local identifiers aka “pseudonyms”! only converter can link & convert pseudonyms

→ central hub for data exchange

Main ID ID-A ID-H

Alice.1210 Hba02 7twnG

Bob.0411 P89dy ML3m5

Carol.2503 912uj sD7Ab

Dave.1906 5G3wx y2B4m

Converter

ID Data

ML3m5

sD7Ab

y2B4m

ID Data

Hba02

P89dy

912uj

Hospital

Doctor A



Record of ML3m5 ?



Record of P89dy from Hospital?

ID Data

ML3m5

sD7Ab

y2B4m

ID Data

Hba02

P89dy

912uj

Hospital

Doctor A

Main ID ID-A ID-H





Converter






Record of ML3m5 ?

+ control about data exchange+ if records are lost, pieces cannot be linked together

– converter learns all request & knows all correlations

ID Data

ML3m5

sD7Ab

y2B4m

ID Data

Hba02

P89dy

912uj

Hospital

Doctor A

Main ID ID-A ID-H





Converter






Record of ML3m5 ?


– converter learns all request & knows all correlations

ID Data

ML3m5

sD7Ab

y2B4m

ID Data

Hba02

P89dy

912uj

Hospital

Doctor A

Main ID ID-A ID-H





Converter

How can be make the converter less trusted?


(Un)linkable Pseudonyms | Pseudonym Generation

Pseudonym for Bob.0411 @ Doctor A

P89dy

! converter & servers jointly derive pseudonyms from unique identifiers– servers do not learn unique identifiers, converter does not learn the

pseudonyms

ID Data

Hba02

P89dy

912uj

Doctor A

Main ID

Alice.1210

Bob.0411

Carol.2503

Dave.1906

Converter



pseudonyms! only converter can link & convert pseudonyms

→ but does so in a blind way

(Un)linkable Pseudonyms | Pseudonym Conversion

ID Data

Hba02

P89dy

912uj

Doctor A

Main ID

Alice.1210

Bob.0411

Carol.2503

Dave.1906

Converter


Record of P89dy

at Hospital

Record of P89dy

at Hospital

Record of P89dy

at Hospitalblind conversion request





ID Data

ML3m5

sD7Ab

y2B4m

ID Data

Hba02

P89dy

912uj

Hospital

Doctor A

Main ID

Alice.1210

Bob.0411

Carol.2503

Dave.1906

Converter


Record of P89dy

at Hospital

Record of P89dy

at Hospital

Record of P89dy


Record of ML3m5 ?

Record of P89dy ?

Record of P89dy ?

blind conversion

unblinding conversion response





ID Data

ML3m5

sD7Ab

y2B4m

ID Data

Hba02

P89dy

912uj

Hospital

Doctor A

Main ID

Alice.1210

Bob.0411

Carol.2503

Dave.1906

Converter


Record of P89dy

at Hospital

Record of P89dy

at Hospital

Record of P89dy



+ converter does not learn pseudonyms in request →can not even tell if requests are for the same pseudonym+ converter can not link data itself




Record of ML3m5 ?

Record of P89dy ?

Record of P89dy ?

blind conversion

unblinding conversion response

(Un)linkable Pseudonyms | Security

ID Data

ML3m5

sD7Ab

y2B4m

ID Data

Hba02

P89dy

912uj

Hospital

Doctor A

Converter


! pseudonyms are unique & consistent– generation is deterministic, injective and consistent with blind conversion

(Un)linkable Pseudonyms | Consistency

P89dy

ML3m5

ID Data

ML3m5

sD7Ab

y2B4m

ID Data

Hba02

P89dy

912uj

Hospital

Doctor A

Main ID

Alice.1210

Bob.0411

Carol.2503

Dave.1906

Converter


ID Data

6Wz6P

fX4o7

RtE14

! pseudonyms are unique & consistent– generation is deterministic, injective and consistent with blind conversion– conversions are consistent and transitive

Invoice for ML3m5

(Un)linkable Pseudonyms | Consistency

Insurance

$$

$

Invoice for P89dy

Invoice for RtE14

ID Data

ML3m5

sD7Ab

y2B4m

ID Data

Hba02

P89dy

912uj

Hospital

Doctor A

Converter


(Un)linkable Pseudonyms | Construction

! security formally defined in the Universal Composability (UC) framework– ideal functionality describing the optimal behaviour of such a system– converter and servers can be fully corrupt

! provably secure construction based on – homomorphic encryption scheme (ElGamal encryption) – verifiable pseudorandom function (Dodis-Yampolskiy-PRF)– pseudorandom permutation (“lazy sampling”)– dual-mode and standard signature schemes (AGOT+, Schnorr signatures)– zero-knowledge proofs (Fiat-Shamir NIZKs with trapdoored ElGamal)


Construction


High-level Idea | Pseudonym Generation

Converter Xxnymi,A

! converter X and server SA jointly compute a pseudonym nymi,A for user uidi

X's input: unique user-id uidi and server ID SA

1) compute global core identifier using secret key k

zi PRF(k,uid← i)

2) compute server-local “inner” pseudonym using server-specific secret key xA

xnymi,A z← ixA

3) compute final pseudonym using a secret key kA nymi,A PRP(k← A,xnymi,A)

k, skX, for each server: xA, xB, xC, …

kA, skAServer A


High-level Idea | Pseudonym Conversion

Converter X

! server SA wishes to convert a pseudonym nymi,A for server SB

SA's input: nymi,A, SB, qid

k, skX , for each server: xA, xB, xC, …

Server A

Server B

kA, skA

kB, skB



Converter X




xnymi,A = zixA

xnymi,B = zixB

nymi,A

nymi,B

Server A

Server B

kA, skA

kB, skB



Converter X




xnymi,A = zixA

xnymi,B = zixB

nymi,A

nymi,B

xnymi,B = xnymi,A xB /xA

PRP(kB, xnymi,B)

PRP-1(kA, nymi,A)

Server A

Server B

kA, skA

kB, skB



Converter X




C, SB, qid

1) re-obtain xnymi,A PRP← -1(kA, nymi,A)

2) encrypt xnymi,A under SB's and Converter X's keyC Enc(p← kX , (Enc(pkB, xnymi,A))

Server A

Server B

kA, skA

kB, skB



Converter X

Server A



3) decrypt first layer asC' Dec(s← kX , C)

4) blindly transform encrypted pseudonymC'' C' ← Δ with Δ = xB / xA

C'' = Enc(pkB, xnymi,A) xB / xA

C'' = Enc(pkB, PRF(k,uidi) xA) xB / xA

C'' = Enc(pkB, PRF(k,uidi) xB) C'' = Enc(pkB, xnymi,B)


Server B

kA, skA

kB, skB



C, SB, qid



Converter X



3) decrypt first layer asC' Dec(s← kX , C)

4) blindly transform encrypted pseudonymC'' C' ← Δ with Δ = xB / xA

C'' = Enc(pkB, xnymi,A) xB / xA

C'' = Enc(pkB, PRF(k,uidi) xA) xB / xA

C'' = Enc(pkB, PRF(k,uidi) xB) C'' = Enc(pkB, xnymi,B)

k, skX , for each server: xA, xB, xC, …C'', SA, qid

5) decrypt inner pseudonym xnymi,B Dec(sk← B , C'')

6) compute final pseudonym as nymi,B PRP(k← B, xnymi,B)



C, SB, qid Server A

Server B

kA, skA

kB, skB


High-level Idea | Active Corruptions

Converter X

Server A

Server B

Converter X xnymi,A Server A

xnymi,A PRF(k,uid← i) xA

C'' ← Dec(skX , C) xB / xA

GenerationConversion

nymi,A PRP(k← A,xnymi,A)

C, SB, qid

C'', SA, qid

C Enc(pk← X , (Enc(pkB, xnymi,A))

nymi,B PRP(k← B,Dec(skB , C''))


High-level Idea | Active Corruptions (Server)

Converter X

Server A

! ensure that servers can convert only their pseudonyms

Server B






C, SB, qid

C'', SA, qid





Converter X

Server A

! ensure that servers can convert only their pseudonyms → generation: “bind” pseudonym nymi,A to server SA via server-specific signature

conversion: SA proves that C contains a correctly signed pseudonym

Server B






C, SB, qid, πA

C'', SA, qid





Converter X

Server A



! challenge: how to sign pseudonyms in a blind conversion?

Server B






C, SB, qid, πA

C'', SA, qid





Converter X

Server A



! challenge: how to sign pseudonyms in a blind conversion? “→ dual-mode” signatures: signature on ciphertext, can be “decrypted” to signature on

plaintext

Server B






C, SB, qid, πA

C'', SA, qid




High-level Idea | Active Corruptions (Converter)

Converter X

Server A

! ensure consistency of pseudonyms and conversions even in the presence of a corrupt converter

→ let converter X prove correctness of his computations via NIZKs

Server B






C, SB, qid, πA

C'', SA, qid




High-level Idea | Active Corruptions (Converter)

Converter X

Server A

! ensure consistency of pseudonyms and conversions even in the presence of a corrupt converter

→ let converter X prove correctness of his computations via NIZKs! pseudonym generation can be anonymous or not

→ non-anon: Server SA can verify that xnymi,A was correctly derived from uidi option important for bootstrapping / migration

Server B

Converter X xnymi,A, πnym,, (uidi) Server A







C, SB, qid, πA

C'', C ,πA ,πX , SA, qid


(Un)linkable Pseudonyms | Efficiency & Summary

efficiency– security against corrupt converter and corrupt servers:

• generation (X +SA): 15 exponentiations + 8 pairings• conversion (X +SA+SB): 84 exponentiations + 30 pairings

– more efficient variant if converter is honest-but-curious (but servers fully corrupt)• generation (X +SA): 7 exponentiations• conversion (X +SA+SB): 40 exponentiations + 16 pairings

(un)linkable pseudonyms with minimally trusted converter– unlinkable data storage with controlled data exchange

• servers maintain data w.r.t. local, random-looking pseudonyms• pseudonyms can only be linked via a central converter

– conversions done in a blind way → converter must not be a trusted entity– efficient and provably secure protocol

→ paradigm shift: unlinkable as default, linkable only when necessary

(most exp. can be merged into multi-exponentiations)


Further Research Needed!

!Securing the infrastructure & IoT– “ad-hoc” establishment of secure authentication and communication – audit-ability & privacy (where is my information, crime traces)– security services, e.g., better CA, oblivious TTPs, anon. routing, …

!Usability

– HCI– Infrastructure (setup, use, changes by end users)

!Provably secure protocols– Properly modeling protocols (UC, realistic attacks models, ...)– Verifiable security proofs– Retaining efficiency


Further Research Needed!

!Quantum Computers–Lots of new crypto needed still–Build apps algorithm agnostic

!Towards a secure information society–Society gets shaped by quickly changing technology–Consequences are hard to grasp yet–We must inform and engage in a dialog


Conclusion

Let engage in some rocket science!! Much of the needed technology exists! … need to use them & build apps “for the moon”! … and make apps usable & secure for end users

Thank you!Joint work w/ Anja Lehmann

[email protected] @JanCamenisch ibm.biz/jancamenisch

mailto:[email protected]

cryptography 4 people - ibm · 3/16/2017 · 3 zisc lunch seminar 15.3.2017 - jan camenisch - ibm...

Documents