CONIKS (KEY TRANSPARENCY) Slides adapted from Marcela Melara The - - PowerPoint PPT Presentation

▶
coniks key transparency
SMART_READER_LITE
LIVE PREVIEW

CONIKS (KEY TRANSPARENCY) Slides adapted from Marcela Melara The - - PowerPoint PPT Presentation

Nov 01, 2022 322 likes •923 views

[USENIX Security 15, Marcela S. Melara, Aaron Blankstein, Joseph Bonneau, Edward W. Felten, Michael J. Freedman] CONIKS (KEY TRANSPARENCY) Slides adapted from Marcela Melara The problem of the PKI (Public key infrastructure) A long

slide-1
SLIDE 1

CONIKS (KEY TRANSPARENCY)

Slides adapted from Marcela Melara [USENIX Security ’15, Marcela S. Melara, Aaron Blankstein, Joseph Bonneau, Edward W. Felten, Michael J. Freedman]

slide-2
SLIDE 2

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
  • ver https, we need Amazon’s PK
  • Man in the middle attacker can intercept PK and return

incorrect PK

slide-3
SLIDE 3

Register (alice à PKA)

Centralized Key Management

Email + Key Provider foo.com User Alice User Bob

1 1 Register (bob à PKB)

slide-4
SLIDE 4

Register (alice à PKA)

Centralized Key Management

Email + Key Provider foo.com User Alice User Bob

1 Look up Alice’s public key: PKA 2 Send message encrypted to PKA, signed by SKB 3 3

slide-5
SLIDE 5

Register (alice à PKA)

Still, Key Server Compromise

Email + Key Provider foo.com User Alice User Bob

1 Look up Alice’s public key: PK’

A

2 This isn’t Alice’s real key!

Equivocates: returns incorrect value

slide-6
SLIDE 6

Still, Key Server Compromise

Email + Key Provider foo.com User Alice User Bob

Read message encrypted to PK’

A

4 Send message encrypted to PK’

A ,

signed by SKB 3

slide-7
SLIDE 7

KT’s Approach: Consistent Identities

  • Users expect consistency of online identities.
  • Certificates make no statement about correctness.
slide-8
SLIDE 8

Consistency

Non-Equivocation No unexpected key changes Key seen by Alice = Key seen by Bob Alice’s key today = Alice’s key yesterday

slide-9
SLIDE 9

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, supported by Firefox and others

These are essentially blockchains, with decentralized security but hosted centrally

slide-10
SLIDE 10

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

slide-11
SLIDE 11

CONIKS Overview

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob Register (alice à PKA) 1 1 Register (bob à PKBs)

slide-12
SLIDE 12

Using CONIKS for E2E Encryption

Untrusted Identity Provider foo.com Client A Client B

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

slide-13
SLIDE 13

Strawman Design

Untrusted Identity Provider 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

slide-14
SLIDE 14

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.
slide-15
SLIDE 15

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

snapshot = root signed by provider

slide-16
SLIDE 16

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 1 1 1

username -> index; arrange usernames based on index in the leaves

slide-17
SLIDE 17

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.
slide-18
SLIDE 18

Proving Inclusion: Authentication Paths

foo.com

ialice: PKAlice H(subL) H(subR) H(subL) H(subR) root H(subL) H(subR) icharlie: PKCharlie 1 1

A user can ask the server to prove inclusion of a binding (i->PK) against a signed snapshot: this can be the owner of the binding, or a user wanting to fetch the PK for i

slide-19
SLIDE 19

Proving Inclusion: Authentication Paths

foo.com

ialice: PKAlice H(subL) H(subR) H(subL) H(subR) root

slide-20
SLIDE 20

What we have so far

  • A client, say Alice can check that her binding is correct in

a signed snapshot

  • Another client fetching Alice’s key can check Alice’s

binding against the signed snapshot

  • What is missing?
  • Provider can equivocate about the signed snapshot (e.g., give

different signed snapshots

  • How to address this?
slide-21
SLIDE 21

Checking Non-Equivocation: Snapshot History

H(seed) root0 Snapshot0

  • 1

H(rootprev-1) rootprev Snapshotprev tprev tprev-1 H(rootprev) roott Snapshott t tprev

… Trillian calls this: Log-backed Verified Map

The provider gives the signed last snapshot to other providers, who check that it is well-formed (e.g., it contains a hash of the previous snapshot) and cross-check that they all received the same snapshot

Blockchain!

slide-22
SLIDE 22

Why do we need to chain the hashes?

  • Otherwise, providers need to exchange the whole history

to check for consistency

  • With a hash chain forks are not possible
  • Why?
  • Collusion resistance of the hash
slide-23
SLIDE 23

H(seed) root0 Snapshot0

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

slide-24
SLIDE 24

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.
slide-25
SLIDE 25

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.
slide-26
SLIDE 26

Register (alice à PKA)

Registration Protocol

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob 2 Temporary binding = [(alice à PKA) + next epoch], Sig(TB) 3 Generate key pair (PKA, SKA) 1 Check ``alice’’ is not taken already Why do we need this “promise” signed? (provider might discard update forever)

slide-27
SLIDE 27

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.
slide-28
SLIDE 28

Lookups without Inclusion Proofs

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob

Provider regularly generates and publishes snapshots

Register (alice à PKA)

PKA PKB

…

Publish new snapshot including PKA

slide-29
SLIDE 29

Lookups without Inclusion Proofs

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob Look up the public key for alice: PK’

A

This isn’t alice’s real key!

Return Fake Key

slide-30
SLIDE 30

Lookups without Inclusion Proofs

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob Verify & accept snapshot

No proof fake key is inconsistent with snapshot

PKA PKB

…

slide-31
SLIDE 31

Lookups without Inclusion Proofs

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob Read message encrypted to PK’

A

Send message encrypted to PK’

A ,

signed by SKB

Provider can read Bob’s message

slide-32
SLIDE 32

Lookup Protocol

  • Ensures bindings are consistent with snapshots.
  • Prevents malicious providers from publishing fake keys

and not leaving any evidence of the misbehavior.

slide-33
SLIDE 33

Lookup (alice à PKA)

Lookup Protocol

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob 1 Send proof of inclusion: Authentication path for (alice à PKA) 2 Verify auth. path 3

slide-34
SLIDE 34

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.

What can happen without monitoring?

slide-35
SLIDE 35

Communication without Monitoring

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob Register (alice à PKA) Look up the public key for alice: PKA

Epoch 1: Key has not Changed

slide-36
SLIDE 36

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob Send message encrypted to PKA, signed by SKB

Communication without Monitoring

Epoch 1: Provider cannot read Bob’s message

slide-37
SLIDE 37

Communication without Monitoring

Untrusted Identity Provider foo.com Client A Client B

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

slide-38
SLIDE 38

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob Read message encrypted to PK’

A

Send message encrypted to PK’

A ,

signed by SKB

Communication without Monitoring

Epoch 2: Provider can read Bob’s message

slide-39
SLIDE 39

Monitoring Protocol

  • Ensures public keys do not change unexpectedly.
  • Prevents malicious providers from getting away with

replacing existing keys.

slide-40
SLIDE 40

Lookup (alice à PKA)

Monitoring Protocol

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob 1 Send (alice à PKA) + authentication path 2 Verify validity of binding & auth. path 3

Every user is responsible for monitoring their binding How often does each user need to check his/her binding?

slide-41
SLIDE 41

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.

What can happen without auditing?

slide-42
SLIDE 42

Register (bob à PKB)

Communication without Auditing

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob Register (alice à PKA)

Clients register legitimate Keys

slide-43
SLIDE 43

Communication without Auditing

Untrusted Identity Provider foo.com Client A Client B

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

slide-44
SLIDE 44

Communication without Auditing

Untrusted Identity Provider foo.com Client A Client B

User Alice User Bob

Provider presents two different but valid snapshots

Verify & accept snapshot SA Verify & accept snapshot SB

PKA PK’B

SA

…

PK’A PKB

SB

…

The attacker can provide different but well-formed snapshots

slide-45
SLIDE 45

Auditing Protocol

  • Ensures clients have consistent views of directories.
  • Clients query random other providers for snapshots
  • bserved from given provider.
  • Prevents malicious providers from getting away with

publishing inconsistent versions of key directory.

slide-46
SLIDE 46

Verify foo.com’s snapshot history

Auditing Protocol

Untrusted Identity Provider foo.com Client A

User Alice Distribute signed snapshot Verify foo.com’s snapshot history

Untrusted Identity Provider bar.com Client B

1

Untrusted Identity Provider rando.com

1

slide-47
SLIDE 47

Send most recent snapshot Request most recent snapshot

Auditing Protocol

Untrusted Identity Provider foo.com Client A

User Alice

Untrusted Identity Provider bar.com Client B

2

Untrusted Identity Provider rando.com

Verify foo.com’s snapshot history 4 Verify foo.com’s snapshot history Verify foo.com’s snapshot history 1 1 3

slide-48
SLIDE 48

Checking Snapshot History

Valid Match Check signature

  • n snapshot

Compare H(rootprev) of cached and new snapshot rootprev Check passed

slide-49
SLIDE 49

Checking Snapshot History

Fail Not matching Valid Check signature

  • n snapshot

Compare H(rootprev) of cached and new snapshot rootprev

slide-50
SLIDE 50

Request snapshot

  • bserved for foo.com

Request snapshot

  • bserved for foo.com

Auditing Protocol

Untrusted Identity Provider foo.com Client A

User Alice

Untrusted Identity Provider bar.com Client B

5

Untrusted Identity Provider rando.com

Compare observed snapshots for foo.com 6 5

Is it clear why foo cannot equivocate?

slide-51
SLIDE 51

Privacy problems with this protocol?

  • Auditors and the provider see contents of directory
  • Authentication paths reveal other entries in the directory
slide-52
SLIDE 52

Prototype Implementation

  • CONIKS Chat: Secure chat service.
  • Stand-alone provider alongside XMPP server.
  • Supports registration, lookups and basic auditing.
slide-53
SLIDE 53

Server performance

slide-54
SLIDE 54

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

slide-55
SLIDE 55

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

slide-56
SLIDE 56

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

slide-57
SLIDE 57

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

slide-58
SLIDE 58

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
slide-59
SLIDE 59

Open questions/projects

Progress on any of:

  • Scalability:
  • Users should not have to check their bindings every epoch
  • Provider should be able to scale to the whole world of people and

IoT devices, wants to generate a snapshot every second

  • Privacy:
  • Provider sees who talks to who
  • Auditors sees many bindings and changes