Lightweight Encryption for Email Ben Adida ben@mit.edu 7 July - - PowerPoint PPT Presentation

Lightweight Encryption for Email

Ben Adida ben@mit.edu 7 July 2005 joint work with Susan Hohenberger and Ronald L. Rivest MIT Cryptography and Information Security Group

Motivation

• To Improve/Restore the Usefulness of Email
• Lightweight Trust for Email Signatures

[ACHR2005]

• Can we get reasonable encryption from

similar simplified key management?

Lightweight Signatures

• Makes forging email from bob@foo.com

as difficult as receiving Bob’s email.

• No explicit user key management
• Uses only existing infrastructure

ID-Based Crypto

Review

keyserver

Alice Bob

MSK MPK "bob@foo.com" PKbob SKbob

ID-based Domains

Bob Alice

SKalice@wonderland.com SKbob@foo.com MPKwonderland.com MPKfoo.com

wonderland.com

keyserver

MSKwonderland.com

foo.com

keyserver

MSKfoo.com

Review

DNS to distribute Master Public Keys

wonderland.com key server

MSKwonderland.com DNS

wonderland.com foo.com

MPKwonderland.com MPKfoo.com

Publish

[DomainKeys] Review

MPKwonderland.com

Email-Based Authentication

[Gar2003]

Alice

wonderland.com

incoming mail server

wonderland.com

keyserver

MSKwonderland.com SKalice@wonderland.com

Review

Alice

SKalice@wonderland.com

Lightweight Sigs

Review

foo.com Network Wonderland.com Network

wonderland.com

key server

foo.com

key server

Bob Alice

PUBLISH

DNS

wonderland.com foo.com

PUBLISH

MPKfoo

1 1

MPKwonderland

From: Alice To: Bob Subject: Guess? I heard that... I'm serious! Signed:

Alice

3 4

“alice@wonderland.com”

MPKbank

5 6

SKA

2

For Encryption?

foo.com Network Wonderland.com Network

wonderland.com

key server

foo.com

key server

Bob Alice

PUBLISH

DNS

wonderland.com foo.com

PUBLISH

MPKfoo

1 1

MPKwonderland

From: Alice To: Bob Subject: Guess? I heard that... I'm serious! Signed:

Alice

3 4

“alice@wonderland.com”

MPKbank

5 6

SKA

2

?

Threat Model

• Assume your incoming mail server

won’t actively spoof/attack you.

• Signatures

If the MSK is compromised, simply change the MSK/MPK (DNS updates).

• Encryption

Different story....

Threat #1: MSK compromise

• all past encrypted emails

are immediately compromised.

• if the MSK compromise is

discreet, then all future encrypted emails are also compromised. (hacking into a keyserver).

Alice

SKalice@wonderland.com

wonderland.com

MSKwonderland

Splitting Keys

wonderland.com

MSKwonderland,1

wonderland.com

MSKwonderland,0

wonderland.com

MSKwonderland,2

Alice SKAlice

wonderland.com,0

SKAlice

wonderland.com,1

SKAlice

wonderland.com,2

SKAlice

wonderland.com

MPKwonderland

MPKwonderland,0 MPKwonderland,1 MPKwonderland,2

Threat #2: Corrupt Mail Server

• a corrupt incoming

mail server can decrypt and read all secret key material.

• a passive corrupt

mail server can intercept all emails.

• even MSK splitting

doesn’t help.

Alice

wonderland.com

incoming mail server

SKalice@wonderland.com

wonderland.com

MSKwonderland.com

Recombining Keys

Bob

foo.com

key server DNS foo.com

MPKfoo.com

SKBob

foo.com

MPKBob+foo.com (MSKBob, MPKBob)

SKBob

Bob

• Bob generates a new

MPK/MSK pair

• The combined SK

matches the combined MPK.

• The combined MPK

provides certification and protection.

• The second MPK

component needs no certification!

Single Core Solution

params MSK1 MPK1 MSK2 MPK2 SK1 SK2

bob@foo.com

CombineSecretKey SKcombined CombineMasterKey MPKcombined

bob@foo.com

VerifySecretShare

SK1 MPK1

Building These Features on Boneh-Franklin and Waters Identity-Based Encryption

Bilinear Maps

Review

e : G1 × G1 → G2 g, h generate G1 e(ga, hb) = e(g, h)ab e(ug, h) = e(u, h)e(g, h) Z = e(g, h) generates G2 G1 G2

ga Zab hb

e G1, G2, both of prime order q

Boneh-Franklin Keys

Review

MSK = s ∈ Zq MPK = gs ∈ G1 Public Parameters: G1, G2, q, g, H PKID = H(ID) SKID = H(ID)s

Splitting & Recombining Boneh-Franklin Keys

MSK1 = s1 MSK2 = s2 MPK1 = gs1 MPK2 = gs2

CombineMasterKey

MPK = MPK1 · MPK2 = gs1+s2 SK2 = H(ID)s2 SK1 = H(ID)s1

CombineSecretKey

SK = SK1 · SK2 = H(ID)s1+s2 Effective MSK = s1 + s2 [BF2000]

Waters Keys

Review

Public Parameters: G1, G2, q, g, h, F MSK = hs MPK = gs PKID = F(ID) SKID = (hsF(ID)r, gr)

Splitting & Recombining Waters Keys

MPK1 = gs1 MPK2 = gs2

SK2 = (hs2F(ID)r2, gr2) SK1 = (hs1F(ID)r1, gr1)

MSK1 = hs1 MSK2 = hs2

CombineMasterKey

MPK = MPK1 · MPK2 = gs1+s2

CombineSecretKey

SK = (hs1F(ID)r1 · hs2F(ID)r2, gr1 · gr2) = (hs1+s2F(ID)r1+r2, gr1+r2)

Effective MSK = gs1+s2

Additional Details

• Malicious Share Generation:

NIZK Proof of Knowledge of MSK share

• Malicious SK Distribution:

k-out-n shares using Lagrange coefficients [GJKR99]

Putting it All Together

foo.com

key server #1

foo.com

key server #2

Bob SKfoo.com

Bob,1

SKfoo.com

Bob,2

3

foo.com

incoming mail server GenerateShare

(MSKBob, MPKBob)

4

Lightweight

• Cert. Server

(bob@foo.com, MPKBob)

5

CombineMasterKey

MPKfoo.com

6

bob@foo.com

DNS foo.com CombineMasterKey

MPKfoo.com

1

MPKfoo.com

2

1 2

MPKfoo.com

Alice

From: Alice To: Bob Subject: Secret

Encrypt CombineSecretKey

SKBob

SKBob

Bob

7

Alice’s Point of View

• Finding Bob’s Public Key:

automatic: a lookup, a computation against MPK. No trust decision necessary.

• Decryption Key Management:

automatic, just upgrade the mail client

• Key Revocation, etc...:

automatic, with upgraded mail client Automation!

Summary

• Lightweight key infrastructure

is not enough for encryption

• To protect against MSK compromise:

key splitting

• To protect against mail server compromise:

key recombination

• Both can be accomplished with the same

trick on Boneh-Franklin and Waters keys

Questions?

Backup Slides

Another Solution

yahoo.com

incoming mail server

gmail.com

incoming mail server

Alice SKAlice

yahoo.com

SKAlice

gmail.com