coniks (key transparency)cs261/fa18/slides/keytransp.pdf · ssl/tls http + ssl/tls certificate...
TRANSCRIPT
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
Email Providerfoo.com
UserAlice
UserBob
HTTP +
SSL/TLS
HTTP +
SSL/TLS
Certificate Authority
SSL/TLS Certificate:
(foo.com, PKf)
Attack: Disgruntled Employees
Email Providerfoo.com
UserAlice
UserBob
HTTP +
SSL/TLS
HTTP +
SSL/TLS
Certificate Authority
SSL/TLS Certificate:
(foo.com, PKf)
Attack: Provider Coercion
Email Providerfoo.com
UserAlice
UserBob
HTTP +
SSL/TLS
HTTP +
SSL/TLS
Certificate Authority
SSL/TLS Certificate:
(foo.com, PKf)
CAs are Vulnerable
Email Providerfoo.com
UserAlice
UserBob
HTTP +
SSL/TLS
HTTP +
SSL/TLS
Certificate Authority
SSL/TLS Certificate:
(foo.com, PKf)
CAs are Vulnerable
Email Providerfoo.com
UserAlice
UserBob
HTTP +
SSL/TLS
HTTP +
SSL/TLS
Certificate Authority
SSL/TLS Certificate:
(foo.com, PKf)
Hackerfoo.com
“hey, I’m foo.com”
CAs are Vulnerable
Email Providerfoo.com
UserAlice
UserBob
HTTP +
SSL/TLS
HTTP +
SSL/TLS
Certificate Authority
SSL/TLS Certificate:
(foo.com, PKf)
Hackerfoo.com
Certificate: (foo.com, PKevil)
Attack: Fraudulent Certificates
Email Providerfoo.com
UserAlice
UserBob
HTTP +
SSL/TLS
HTTP +
SSL/TLS
Certificate Authority
SSL/TLS Certificate:
(foo.com, PKf)
Attack: Fraudulent Certificates
Email Providerfoo.com
UserAlice
UserBob
HTTP +
SSL/TLS
HTTP +
SSL/TLS
Certificate Authority
SSL/TLS Certificate:
(foo.com, PKf)
Hackerfoo.com
Certificate: (foo.com, PKevil)
Need End-to-End Encryption…
Email Providerfoo.com
UserAlice
UserBob
E2E Encryption E2E Encryption
… But Key Management is Hard
Decentralized Key Management
UserAlice
UserBob
Alice trusts PKBob
Bob trusts PKAlice
Mutual Endorsement
Decentralized KM: Pitfalls
UserAlice
UserBob
PKAlice: DEF456
PKBob: 123BAC
Mistakes transferring keys
Should be
AB
PGP Key Servers
Email Providerfoo.com
UserAlice
UserBob
E2E Encryption E2E Encryption
PGP Key Server X
PKBob PKAlice
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)
Register (alice→ PKA)
Better: Centralized Key Management
Email + Key Providerfoo.com
UserAlice
UserBob
1 Look up Alice’s public key: PKA
2
Send message encrypted to PKA, signed by SKB
33
Register (alice→ PKA)
Insider Attacks, still.
Email + Key Providerfoo.com
UserAlice
UserBob
1 Look up Alice’s public key: PK’A
2
This isn’t Alice’s
real key!
Insider Attacks, still.
Email + Key Providerfoo.com
UserAlice
UserBob
Read message encrypted to PK’A
4
Send message encrypted to PK’A , signed by SKB
3
Old Approach: Correct Identities
Alice
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
Untrusted Identity Provider
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
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
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)
icharlie : PKCharlie
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)
icharlie : PKCharlie
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.
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.
Register (alice→ PKA)
Registration Protocol
Untrusted Identity Provider
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: Clients check bindings are included in directory.
• Monitoring: Clients check for validity of bindings.
• Auditing: Clients & providers check for non-equivocation.
Lookups without Inclusion Proofs
Untrusted Identity Provider
foo.com
ClientA
ClientB
User Alice
User Bob
Provider regularly generates and publishes snapshots
Register (alice→ PKA)
PKA
PKB…
Publish new snapshot including PKA
Lookups without Inclusion Proofs
Untrusted Identity Provider
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
Lookups without Inclusion Proofs
Untrusted Identity Provider
foo.com
ClientA
ClientB
User Alice
User Bob
Verify & accept snapshot
No proof fake key is inconsistent with snapshot
PKA
PKB…
Lookups without Inclusion Proofs
Untrusted Identity Provider
foo.com
ClientA
ClientB
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
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
Untrusted Identity Provider
foo.com
ClientA
ClientB
User Alice
User Bob
1Send proof of inclusion:Authentication path for (alice→ PKA)
2
Verify auth. path
3
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.
Communication without Monitoring
Untrusted Identity Provider
foo.com
ClientA
ClientB
User Alice
User Bob
Register (alice→ PKA)
Look up the public key for alice: PKA
Epoch 1: Key has not Changed
Untrusted Identity Provider
foo.com
ClientA
ClientB
User Alice
User Bob
Send message encrypted to PKA, signed by SKB
Communication without Monitoring
Epoch 1: Provider cannot read Bob’s message
Communication without Monitoring
Untrusted Identity Provider
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
Untrusted Identity Provider
foo.com
ClientA
ClientB
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
Monitoring Protocol
• Ensures public keys do not change unexpectedly.
• Prevents malicious providers from getting away with
replacing existing keys.
Lookup (alice→ PKA)
Monitoring Protocol
Untrusted Identity Provider
foo.com
ClientA
ClientB
User Alice
User Bob
1 Send (alice→ PKA) + authentication path
2
Verify validity of binding & auth. path
3
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.
Register (bob → PKB)
Communication without Auditing
Untrusted Identity Provider
foo.com
ClientA
ClientB
User Alice
User Bob
Register (alice→ PKA)
Clients register legitimate Keys
Communication without Auditing
Untrusted Identity Provider
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
Communication without Auditing
Untrusted Identity Provider
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
Untrusted Identity Provider
foo.com
ClientA
UserAlice
Distribute signed snapshot
Verify foo.com’ssnapshot history
Untrusted Identity Provider
bar.com
ClientB
1
Untrusted Identity Provider
rando.com
1
Send most recent snapshot
Request most recent snapshot
Auditing Protocol
Untrusted Identity Provider
foo.com
ClientA
UserAlice
Untrusted Identity Provider
bar.com
ClientB
2
Untrusted Identity Provider
rando.com
Verify foo.com’ssnapshot history
4
Verify foo.com’ssnapshot history
Verify foo.com’ssnapshot history
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
Untrusted Identity Provider
foo.com
ClientA
UserAlice
Untrusted Identity Provider
bar.com
ClientB
5
Untrusted Identity Provider
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.
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 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
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