broadcast encryption with multiple trust authorities

Broadcast Encryption with Multiple Trust Authorities

Alexander W. Dent

Information Security Group

Royal Holloway, University of London

Table of Contents

• Broadcast encryption in multiple domains

(Or what we tried to do...) [8 slides]

• Our scheme

(Or how we achieved our aim...) [4 slides]

2

Broadcast Encryption with Multiple Trust Authorities• Broadcast encryption in structured organisations• Broadcast encryption in collaborations• The simple solution?• An example use scenario

3

Broadcast encryption

• Encrypt a message using a pattern (ID1,ID2, * ,ID4).

• Key for any identity which matches pattern can decrypt the ciphertext.

4

Public parameters

“Trust authority”

“Department 1” “Department 2”

“Project 1” “Project 2”

“User 1” “User 2”

Setup algorithm

Key generation algorithm

Key derivation algorithm

Broadcast encryption

• (TA,Dept,Project,User) targets a specific individual.

• (TA,Dept, * , * ) targets all members of a specific department.

• (TA, * ,Project, * ) targets all users of a specific project.

• Etc.

5

Public parameters

“Trust authority”

“Department”

“Project”

“User”

Multiple trust authorities

• What if multiple institutions want to collaborate on a project?

• We would want:– Each trust authority retains control of its own trust

domain and keys.– Trust domains can be set up independently of all

other trust domains.– Trust authorities can easily form coalitions.– Membership of one coalition does not give that TA

rights in any other coalition.

6

Multiple trust authorities

7

Public parameters

“Trust authority”

“Department 1” “Department 2”

“Project 1” “Project 2”

“User 1” “User 2”

“Trust authority”

“Department 1” “Department 2”

“Project 1” “Project 2”

“User 1” “User 2”

(Public) protocol

(Broadcast) key update message

(Broadcast) key update message

Multiple trust authorities

• To address the coalition, use coalition master key (derived from master keys of coalition TAs).

• (TA,Dept,Proj,User) targets a single user.

• (TA,Dept, * , * ) targets a department under one TA.

• ( * , * ,Proj, * ) targets all users on a project regardless of their TA.

• Users decrypt with their coalition decryption keys.

8

Public parameters

“Trust authority”

“Department”

“Project”

“User”

Assumptions

• All TAs have to use the same scheme.

• All TAs have to use same public parameters (and trust them).– Common problem with common solutions.

• All TAs have to use the same naming structure in their trust domains.– TA1 has (TA,Dept,Proj,User)– TA2 has (TA,Sector,Supervisor,Building,User)

9

Assumptions

• Why not use a single new WIBE scheme?– It cannot be set up in advance and every new

coalition requires a new WIBE scheme.– It’s unclear who should hold the master

private key for the coalition WIBE.– Every existing member of the trust authority

would have to re-register and obtain a new key for the coalition.

10

Usage scenarios

• Use on joint projects is clear.• Suppose a number of

manufacturers are building general purpose sensors for use in multiple projects.

• (Man,Type, * , * ) could be used for software updates.

• ( * ,Type,Proj, * ) could be used to update mission parameters.

11

Public parameters

“Sensor Type”

“Project”

“Sensor Identity”

“Manufacturer”

Boneh-Boyen MTA-WIBE

• The Boneh-Boyen HIBE/WIBE• Ghost authorities

12

Our scheme

• Based on the Boneh-Boyen WIBE– Abdalla et al. (2006) and Boneh-Boyen (2004).

• Selective-identity IND-CPA secure in the standard model– Full CPA security achieved in ROM– Normal trick of hashing user identities

• Selective-identity IND-CCA secure in the standard model via novel Boneh-Katz transform (which applies to WIBEs too).

13

Boneh-Boyen HIBE

14

Public parameters(g1, g2, u10,u11,u20,u21,...)

Master private key:Master public key:

g2α

g1α

Level one key: (g2α(u10·u11

ID1)r, g1r)

Level two key: (g2α(u10·u11

ID1)r(u20·u21ID2)s, g1

r, g1s)

Our scheme

• Our scheme shows that two TAs can cooperate to create a “ghost” super TA.

• Each TA can figure out their key in this new hierarchy, but not the super TA’s key or each other’s keys.

15

TA1 TA2

Ghost “super” TA

Our scheme

16

Public parameters(g1, g2, u00,u01,u10,u11,u20,u21,...)

Master private key:Master public key:

g2α

g1α

(g2α(u10·u11

TA2)t, g1t)

Level one key: (g2α(u00·u01

TA1)r(u10·u11ID1)s, g1

r, g1s)

g2β

g1β

TA1 TA2

(g2 α+β(u10·u11

TA1)x, g1x)

g2α+β

g1α+β

GHOST

(g2α+β(u10·u11

TA2)t, g1t)

(g2 β(u10·u11

TA1)x, g1x)

Conclusion

• We proposed a new functionality for encryption between trust domains.

• Instantiated that scheme with a novel version of the BB-WIBE.

• Gave a new transform for creating CCA-secure WIBEs from CPA-secure WIBEs.

• Other functionalities?

17

Questions?