CONIKS (KEY TRANSPARENCY)cs261/fa18/slides/keytransp.pdf · SSL/TLS HTTP + SSL/TLS Certificate...

CONIKS (KEY

TRANSPARENCY)

Slides adapted from Marcela Melara

Any scriber for today?

• Sign up for presentations or scribers

The problem of the PKI (Public key

infrastructure)• A long standing problem has been to distribute public

keys securely in the presence of attackers

• Use cases:

• Secure messaging: Alice needs to send an encrypted message to

Bob and needs Bob’s public key to encrypt the message

• Web surfing and https: when Alice’s browser contacts amazon.com

over https, we need Amazon’s PK

• Man in the middle attacker can intercept PK and return

incorrect PK

“Secure” Communication Today

Email Providerfoo.com

UserAlice

UserBob

HTTP +

SSL/TLS

HTTP +

SSL/TLS

Certificate Authority

SSL/TLS Certificate:

(foo.com, PKf)

Attack: Hackers


UserAlice

UserBob

HTTP +

SSL/TLS

HTTP +

SSL/TLS



(foo.com, PKf)

Attack: Disgruntled Employees


UserAlice

UserBob

HTTP +

SSL/TLS

HTTP +

SSL/TLS



(foo.com, PKf)

Attack: Provider Coercion


UserAlice

UserBob

HTTP +

SSL/TLS

HTTP +

SSL/TLS



(foo.com, PKf)

CAs are Vulnerable


UserAlice

UserBob

HTTP +

SSL/TLS

HTTP +

SSL/TLS



(foo.com, PKf)

CAs are Vulnerable


UserAlice

UserBob

HTTP +

SSL/TLS

HTTP +

SSL/TLS



(foo.com, PKf)

Hackerfoo.com

“hey, I’m foo.com”

CAs are Vulnerable


UserAlice

UserBob

HTTP +

SSL/TLS

HTTP +

SSL/TLS



(foo.com, PKf)

Hackerfoo.com

Certificate: (foo.com, PKevil)

Attack: Fraudulent Certificates


UserAlice

UserBob

HTTP +

SSL/TLS

HTTP +

SSL/TLS



(foo.com, PKf)

Attack: Fraudulent Certificates


UserAlice

UserBob

HTTP +

SSL/TLS

HTTP +

SSL/TLS



(foo.com, PKf)

Hackerfoo.com

Certificate: (foo.com, PKevil)

Need End-to-End Encryption…


UserAlice

UserBob

E2E Encryption E2E Encryption

… But Key Management is Hard

Decentralized Key Management

UserAlice

UserBob

PKAlice: DEF456

PKBob: 123ABC

Manual key exchange

Decentralized Key Management

UserAlice

UserBob

Alice trusts PKBob

Bob trusts PKAlice

Mutual Endorsement

Decentralized KM: Pitfalls

UserAlice

UserBob

PKAlice: DEF456

PKBob: 123ABC

Lost keys

Decentralized KM: Pitfalls

UserAlice

UserBob

PKAlice: DEF456

PKBob: 123BAC

Mistakes transferring keys

Should be

AB

PGP Key Servers


UserAlice

UserBob

E2E Encryption E2E Encryption

PGP Key Server X

PKBob PKAlice

PGP Key Servers

Key Signing Parties

Trusting the Web of Trust

XKCD, Responsible Behavior

Crux of WoT Issues

[1] A. Whitten and J. D. Tygar. Why Johnny can’t encrypt: a usability evaluation of PGP 5.0. USENIX Security, Aug. 1999

[2] S. Gaw, E. W. Felten, and P. Fernandez-Kelly. Secrecy, flagging, and paranoia: Adoption criteria in encrypted email. CHI, Apr 2006.

• Decentralized model: people reason about encryption.

• Studies:

• Unintuitive and error-prone.

• Users don’t understand encryption.

• Leak private information.

Register (alice→ PKA)

Better: Centralized Key Management

Email + Key Providerfoo.com

UserAlice

UserBob

1 1 Register (bob → PKB)


Better: Centralized Key Management


UserAlice

UserBob

1 Look up Alice’s public key: PKA

2

Send message encrypted to PKA, signed by SKB

33


Insider Attacks, still.


UserAlice

UserBob

1 Look up Alice’s public key: PK’A

2

This isn’t Alice’s

real key!

Insider Attacks, still.


UserAlice

UserBob

Read message encrypted to PK’A

4

Send message encrypted to PK’A , signed by SKB

3

Old Approach: Correct Identities

Alice

[email protected]

Certificate

Name: [email protected]: 456DEFOwner: AliceSigned by: CA

Bob’s

real-world

friend Alice?

New Approach: Consistent Identities

• Users expect consistency of online identities.

• Separate real-world identity from online identity.

• Certificates make no statement about correctness.

Consistency

Non-EquivocationNo unexpected key changes

Key seen by Alice = Key seen by BobAlice’s key today = Alice’s key yesterday

Solution: a promising new generation

• CONIKS

• An alternative Public Key Infrastructure (PKI)

• Embedded in Google’s project called Key Transparency or Trillian

• The key data structure is the Log-backed Verified Map

• Certificate Transparency

• Similar technology to Key Transparency but aimed at certificates

• Currently mandated by Chrome, other browser support coming up

CONIKS [Melara et al. 2014]

• End-User Key Management Service.

• Consistent name-to-key bindings.

• Verifiable key directories → Untrusted identity providers.

• Clients verify consistency in-band.

→automated key management

CONIKS Overview

Untrusted Identity Provider

foo.com

ClientA

ClientB

User Alice

User Bob

Register (alice→ PKA) 1 1

Register (bob → PKBs)

CONIKS Overview


foo.com

ClientA

ClientB

User Alice

User Bob

Look up the public key for alice: PKA

2

3

Send message encrypted to PKA , signed by SKB

4 Look up public key for bob: PKB, verify signature, decrypt using SKA

Strawman Design


foo.com

Client A

Client B

Client C

Client D

N = 4

Validity Checks O(N) storage per client

Non-equivocation Checks O(N2) downloads per client

CONIKS Design

• Divide time into epochs.

• Providers generate snapshots of directory.

→ Clients do not check individual bindings.

• Providers distribute snapshots to other providers.

→ Build publicly verifiable history

• Non-repudiation: Snapshots are digitally signed.

Efficient Snapshots

foo.com

ialice :PKAlice

H(subL) H(subR)

H(subL) H(subR)

root

H(subL) H(subR)

icharlie : PKCharlie

iemily : PKEmily

igeorge : PKGeorge

Efficient Snapshots

foo.com

ialice :PKAlice

H(subL) H(subR)

H(subL) H(subR)

root

H(subL) H(subR)


iemily : PKEmily

igeorge : PKGeorge

0

0 0

1

11

Checking Consistency

• Use snapshots to check for consistency.

• Clients need to ensure bindings are included in snapshots.

• Lookups: prove inclusion of bindings in directory.

• Clients check validity, non-equivocation.

• Providers cross-verify each other for non-equivocation.

Proving Inclusion: Authentication Paths

foo.com

ialice :PKAlice

H(subL) H(subR)

H(subL) H(subR)

root

H(subL) H(subR)


0

0

1

1

Proving Inclusion: Authentication Paths

foo.com

ialice :PKAlice

H(subL) H(subR)

H(subL) H(subR)

root

0

0

Checking Non-Equivocation:

Snapshot History

H(seed) root0

Snapshot0

0 -1

H(rootprev-1) rootprev

Snapshotprev

tprev tprev-1

H(rootprev) roott

Snapshott

t tprev

…

Trillian calls this: Log-backed Verified Map

H(seed) root0

Snapshot0

0 -1

H(rootprev-1) rootprev

Snapshotprev

tprev tprev-1

H(rootprev) roott

Snapshott

t tprev

…

H(root’prev-1) root’prev

Snapshot’prev

tprev tprev-1

H(root’prev) root’t

Snapshot’t

t tprev

Checking Non-Equivocation:

Snapshot History

The server can try a fork attack, but after fork the provider must

maintain these forked hash chains for the rest of time, and not

allow clients seeing one branch of the hash chain to

communicate with anyone seeing the other branch.

CONIKS Protocols

• Registration: New bindings/updated keys.

• Lookups: Clients check bindings are included in directory.

• Monitoring: Clients check for validity of bindings.

• Auditing: Clients & providers check for non-equivocation.


Registration Protocol


foo.com

ClientA

ClientB

User Alice

User Bob

2Temporary binding = [(alice→ PKA) + next epoch],Sig(TB)

3

Generate key pair (PKA, SKA)

1

CONIKS Protocols

• Registration: new bindings/updated keys.




Lookups without Inclusion Proofs


foo.com

ClientA

ClientB

User Alice

User Bob

Provider regularly generates and publishes snapshots


PKA

PKB…

Publish new snapshot including PKA



foo.com

ClientA

ClientB

User Alice

User Bob

Look up the public key for alice: PK’A

This isn’t alice’s

real key!

Return Fake Key



foo.com

ClientA

ClientB

User Alice

User Bob

Verify & accept snapshot

No proof fake key is inconsistent with snapshot

PKA

PKB…



foo.com

ClientA

ClientB

User Alice

User Bob



Provider can read Bob’s message

Lookup Protocol

• Ensures bindings are consistent with snapshots.

• Prevents malicious providers from publishing fake keys

and not leaving any evidence of the misbehavior.

Lookup (alice→ PKA)

Lookup Protocol


foo.com

ClientA

ClientB

User Alice

User Bob

1Send proof of inclusion:Authentication path for (alice→ PKA)

2

Verify auth. path

3

CONIKS Protocols





Communication without Monitoring


foo.com

ClientA

ClientB

User Alice

User Bob


Look up the public key for alice: PKA

Epoch 1: Key has not Changed


foo.com

ClientA

ClientB

User Alice

User Bob

Send message encrypted to PKA, signed by SKB


Epoch 1: Provider cannot read Bob’s message



foo.com

ClientA

ClientB

User Alice

User Bob

Look up the public key for alice: PK’A

This isn’t Alice’s

real key!

Epoch 2: Key has been Changed


foo.com

ClientA

ClientB

User Alice

User Bob




Epoch 2: Provider can read Bob’s message

Monitoring Protocol

• Ensures public keys do not change unexpectedly.

• Prevents malicious providers from getting away with

replacing existing keys.

Lookup (alice→ PKA)

Monitoring Protocol


foo.com

ClientA

ClientB

User Alice

User Bob

1 Send (alice→ PKA) + authentication path

2

Verify validity of binding & auth. path

3

CONIKS Protocols





Register (bob → PKB)

Communication without Auditing


foo.com

ClientA

ClientB

User Alice

User Bob


Clients register legitimate Keys



foo.com

ClientA

ClientB

User Alice

User Bob

client B sees PK’A as alice’s public key

Provider creates two versions of its Directory

client A sees PK’B as bob’s public key



foo.com

ClientA

ClientB

User Alice

User Bob

Provider presents two different but valid snapshots

Verify & accept snapshot SA

Verify & accept snapshot SB

PKA

PK’B

SA

…

PK’APKB

SB

…

Auditing Protocol

• Ensures clients have consistent views of directories.

• Clients query random other providers for snapshots

observed from given provider.

• Prevents malicious providers from getting away with

publishing inconsistent versions of key directory.

Verify foo.com’ssnapshot history

Auditing Protocol


foo.com

ClientA

UserAlice

Distribute signed snapshot



bar.com

ClientB

1


rando.com

1

Send most recent snapshot

Request most recent snapshot

Auditing Protocol


foo.com

ClientA

UserAlice


bar.com

ClientB

2


rando.com


4



11

3

Checking Snapshot History

Valid MatchCheck signature

on snapshotCompare H(rootprev) of cached

and new snapshot

rootprev

Check passed

Checking Snapshot History

FailNot matching

ValidCheck signature

on snapshotCompare H(rootprev) of cached

and new snapshot

rootprev

Request snapshot observed for foo.com

Request snapshot observed for foo.com

Auditing Protocol


foo.com

ClientA

UserAlice


bar.com

ClientB

5


rando.com

Compare observed snapshots for foo.com

6

5

Privacy problems with this protocol?

• Auditors see contents of directory

• Authentication paths reveal other entries in the directory

Prototype Implementation

• CONIKS Chat: Secure chat service.

• Stand-alone provider alongside XMPP server.

• Supports registration, lookups and basic auditing.

Server performance

Client Overheads

• N ≈ 4 bill. users, n ≈ 2 mill. updates/epoch,

d = 24 epochs/day.

Download

Requirements

Storage

Requirements

Lookup (per binding) < 1.4KB 0B

Monitoring (epoch) < 800B ~ 300B

Monitoring (day) < 20KB ~ 300B

Auditing (epoch, per snapshot) ~ 100B ~ 100B

Auditing (day, per snapshot) ~ 2.5KB ~ 100B

Client Overheads

• N ≈ 4 bill. users, n ≈ 2 mill. updates/epoch,

d = 24 epochs/day.

Download

Requirements

Storage

Requirements

Lookup (per binding) < 1.4KB ~ 300B

Monitoring (epoch) < 800B ~ 300B

Monitoring (day) < 20KB ~ 300B

Auditing (epoch, per snapshot) ~ 100B ~ 100B

Auditing (day, per snapshot) ~ 2.5KB ~ 100B

CONIKS summary

• CONIKS is an efficiently verifiable, privacy-preserving key

management service for end-user public keys.

• End-to-end security can be practical for end-users.

• Some industry adoption: e.g. Google’s Key Transparency

CONIKS (KEY TRANSPARENCY)cs261/fa18/slides/keytransp.pdf · SSL/TLS HTTP + SSL/TLS Certificate...

Documents

Transcript of CONIKS (KEY TRANSPARENCY)cs261/fa18/slides/keytransp.pdf · SSL/TLS HTTP + SSL/TLS Certificate...