1 / 17

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

eve-howell
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Broadcast Encryption with Multiple Trust Authorities Alexander W. Dent Information Security Group Royal Holloway, University of London

  2. 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]

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

  4. 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”

  5. 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”

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

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

  8. 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”

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

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

  11. 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”

  12. Boneh-Boyen MTA-WIBE The Boneh-Boyen HIBE/WIBE Ghost authorities

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

  14. 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:

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

  16. 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:

  17. 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?

More Related