Content deleted Content added
DanShearer (talk | contribs) Clarify one-way relationship with role-based encryption |
m →Challenges: Minor rewording and correcting a run-on sentence. |
||
Line 19:
===Challenges===
Although the ABE concept is very powerful and a promising mechanism, ABE systems suffer mainly from two drawbacks:
Other main challenges are:
Line 31:
A simple but constrained solution is to include a time attribute. This solution would require each message to be encrypted with a modified access tree {{samp|T0}}, which is constructed by augmenting the original access tree {{samp|T}} with an additional time attribute. The time attribute, {{samp|ζ}} represents the current ‘time period’. Formally, the new access structure {{samp|T0}} is as follows: {{samp|T0 = (T AND ζ)}}. For example, {{samp|ζ}} can be the ‘date’ attribute whose value changes once every day. It is assumed that each non-revoked user receives his fresh private keys corresponding to the ‘date’ attribute once each day directly from the mobile key server MKS (which is the central authority) or via the regional delegates. With a hierarchical access structure, the key delegation property of CP-ABE can be exploited to reduce the dependency on the central authority for issuing the new private keys to all users every time interval. There are significant trade-offs between the extra load incurred by the authority for generating and communicating the new keys to the users and the amount of time that can elapse before a revoked user can be effectively purged. This above solution has the following problems:
# Each user X needs to periodically receive from the central authority the fresh private key corresponding to the time attribute, otherwise X will not be able to decrypt any message.
# It is a lazy revocation technique.
# This scheme requires an implicit time synchronization (a loose time synchronization may be sufficient) among the authority and the users.
| |||