Broadcast encryption with multiple trust authorities
This presentation is the property of its rightful owner.
Sponsored Links
1 / 17

Broadcast Encryption with Multiple Trust Authorities PowerPoint PPT Presentation


  • 60 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Broadcast Encryption with Multiple Trust Authorities

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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

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]


Broadcast encryption with multiple trust authorities1

Broadcast Encryption with Multiple Trust Authorities

Broadcast encryption in structured organisations

Broadcast encryption in collaborations

The simple solution?

An example use scenario


Broadcast encryption

Broadcast encryption

Public parameters

Setup algorithm

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

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

Key generation algorithm

“Trust authority”

Key derivation algorithm

“Department 1”

“Department 2”

“Project 1”

“Project 2”

“User 1”

“User 2”


Broadcast encryption1

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.

Public parameters

“Trust authority”

“Department”

“Project”

“User”


Multiple trust authorities

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.


Multiple trust authorities1

Multiple trust authorities

Public parameters

(Public) protocol

“Trust authority”

“Trust authority”

“Department 1”

“Department 2”

“Department 1”

“Department 2”

“Project 1”

“Project 2”

“Project 1”

“Project 2”

“User 1”

“User 2”

“User 1”

“User 2”

(Broadcast) key update message

(Broadcast) key update message


Multiple trust authorities2

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.

Public parameters

“Trust authority”

“Department”

“Project”

“User”


Assumptions

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)


Assumptions1

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.


Usage scenarios

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.

Public parameters

“Manufacturer”

“Sensor Type”

“Project”

“Sensor Identity”


Boneh boyen mta wibe

Boneh-Boyen MTA-WIBE

The Boneh-Boyen HIBE/WIBE

Ghost authorities


Our scheme

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


Boneh boyen hibe

Boneh-Boyen HIBE

Public parameters

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

Master private key:

Master public key:

g2α

g1α

(g2α(u10·u11ID1)r, g1r)

Level one key:

(g2α(u10·u11ID1)r(u20·u21ID2)s, g1r, g1s)

Level two key:


Our scheme1

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.

Ghost “super” TA

TA1

TA2


Our scheme2

Our scheme

Public parameters

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

TA1

GHOST

TA2

Master private key:

Master public key:

g2α

g1α

g2α+β

g1α+β

g2β

g1β

(g2α(u10·u11TA2)t, g1t)

(g2 β(u10·u11TA1)x, g1x)

(g2 α+β(u10·u11TA1)x, g1x)

(g2α+β(u10·u11TA2)t, g1t)

(g2α(u00·u01TA1)r(u10·u11ID1)s, g1r, g1s)

Level one key:


Conclusion

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?

Questions?


  • Login