# Hierarchical access control using CP-ABE

Is it possible to use CP-ABE to provide a layered (hierarchical) organization?

For example, If I have 100 records, I will encrypt the first 10 records (lowest level) to be decrypted using certain attributes. The next level can for instance decrypt up to 20 records.

Encryption depends on a secret $s$ for the first ten records and a different secret s' for the next 10 records. How could I give the higher level in an organization a key that could decrypt all 20 records?

I am trying to avoid giving people in the higher level the secret of the lower level.

• Your question is not entirely clear. First you write that in the lowest level of people can only decrypt the first 10 records, but then you you say that the next-higher level can decrypt up to 20 records. Is the order of those 20 records important or can those be any 20 records not necessarily including the 10 records from the lowest level? – Artjom B. Nov 21 '16 at 19:49

## 2 Answers

I can discern two cases here:

1. A strict hierarchy
2. A partial hierarchy

Using 1, "Hierarchical access control" as a term used with encryption implies that some users have more decryption power than others. Especially in access control modelling, hierarchy is usually "strict". This means that if A > B (A is "higher", and has "more" decryption power than B) then A can decrypt everything B can. If there are items B can decrypt but A cannot, A and B would not be on the same path in the hierarchy tree (i.e. A and B are in this case always comparable).

Using 2, the hierarchy would not be strict: there would be cases where A and B are not comparable, but in most cases it can be stated whether A > B or B < A.

For case 1, CP-ABEs offer a feature called "delegation". In a CP-ABE terms, this is relatively straightforward: if A > B, then the secret (attribute) key set of B will be a subset of that of A. (Remember though, that the mapping of real-life attributes to the scheme access structure may not be straightforward). Thus it should be easy to create a strict hierarchy.

Additionally, monotone CP-ABEs have the property that for an arbitrary scheme-supported set of users it is always possible to construct a hierarchy (possibly by adding virtual users).

However, if you want to use just cryptography to implement a strict access control hierarchy, hierarchical identity-based encryption (HIBE, e.g. https://eprint.iacr.org/2005/015.pdf) would be conceptually simpler, and probably more efficient).

Case 2 does not seem a matter of the cryptographic scheme, but a matter of the actual access control policy. If the policy does not include negative statements, most CP-ABE schemes will be able to support it (per encryption).

A completely another question is, what kind of access control features it is in general possible to enforce by content encryption only (Blu-Ray IPR yes, to some extent, but not for example general workflows).

Well, 1 way I could suggest is to encrypt the sensitive records with a more restrictive tree policy, obtain the cipher C and C', concatenate that ciphers with less sensitive records, encrypt that concatenation with a less restrictive tree policy and so on so forth.... Each level of encryption can be done with a new MK if u want a different secret s to be used each time. But you could of course reuse the same s, that could possibly result in collisions occurring.

In this sense a user who has all the requires attributes will be able to decipher the text till the deepest cipher level.

But keep in mind CP-ABE way more computationally expensive then KP-ABE, which means speed will be an issue.

Perhaps you might want to take a look at Fuzzy IBE as an alternative to implement that technique as it is much more computationally friendly when compared to CP-ABE (Here is a simple explanation on it https://eprint.iacr.org/2004/086.pdf). In this method, you can do it with the same s or without the same s but the difference in this version would be that the threshold of a key, as opposed to being the number of nodes that fulfils a policy tree of a CP-ABE cipher, would be a value explicitly set by one encrypting a , in this case, record.

Repeat the same procedure above encrypt records, while setting the threshold on each level to be smaller than the previous one.

Hope this helps.

• I've performed some benchmarks and I can say that "CP-ABE way more computationally expensive then KP-ABE" is plainly false. If schemes of both flavors are based on the same assumptions using the same techniques, they will have equivalent runtimes over the whole encryption-decryption cycle. Of course, the encryption and decryption are not equal, so they will be different in those two flavors, but if you add the runtimes of enc & dec together, the sums will be the same for both flavors. – Artjom B. Nov 21 '16 at 22:50
• First you're proposing that restrictive policies are used for higher level records, but your "example" doesn't involve any policy. Instead, it seems to me that you're doing multiple encryptions for some reason. I don't think this is necessary. Also, your use of Fuzzy IBE is not entirely clear here. Can you give some actual examples for both? – Artjom B. Nov 21 '16 at 22:53
• Well for the false part it depends on the type of e function your run (Weil pairing, Tate pairing etc) which can be computed by Millers algorithm, will affect computational cost cause if you look at how the calculations are done for both KP-ABE and CP-ABE you'll see encryption and decryption methods are different, with CP-ABE running more steps to derive with the cipher text. Decryption is also more complex as opposed to KP-ABE... I can't really give u an example as for the implementation part cause in order to show you ill need to write out an essay and I am not that free. – INeedInsecticideToKillBugs Nov 22 '16 at 7:08
• And multiple encryptions to hide data that is more sensitive within the encrypted data. The multiple encryptions is meant to act as a hierarchy level. It's abit hacky but there is currently no possible way to decrypt the same data with different secret s within one encryption call. Sorry if I disappoint you with my answer or reply but this is the best i got. One more note, runtime grows exponentially as data size grows. – INeedInsecticideToKillBugs Nov 22 '16 at 7:11
• Ignore the one more note part... that was written by a friend of mine running a prank while i was in the loo... – INeedInsecticideToKillBugs Nov 22 '16 at 7:14