What exactly do we mean by access revocation?

The topic of access revocation tends to be a confusing one in the context of encryption and data sharing. In our presentations, when we mention the ease of access revocation with proxy re-encryption, attendees sometimes look on in slight bewilderment - How can you revoke access to data already shared?


This is a companion discussion topic for the original entry at https://blog.nucypher.com/p/a7372e37-6a7c-464e-959a-fb5e9fb4b701/

In the scheme described it seems that Bob can access all of Alice’s encrypted files that he can get hold of, at least until access is revoked.

Suppose Alice has a set of files (Set X) she needs to share with Bob, because they are working on the same project or similar, and another set of files (Set Y) that she does not want to share with Bob. However the files in both Set X and Set Y are located in the same file server and Bob has full access to the file server. Given that the file contents are necessarily unknown how can Alice prevent Bob from accessing the files in Set Y? My thought would be for Alice and Bob to have a multitude of public/private keys for the different projects they are working on in addition to their own personal key, or am I missing something?

Hi Simon,

Great question. In your scenario Set X and Set Y would use a different ‘label’ for the data, and Alice can use a different private/public key pair for different labels. In that way, Alice can grant access to Bob for Set X but not for Set Y. Bob doesn’t necessarily need a multitude of private/public key pairs, even though he can if he desires.

The fact that Bob has access to the entire file server is irrelevant because all of the data is encrypted and the only way for Bob to view the data is to have it re-encrypted. Data that Bob has been granted access to will be re-encrypted by the relevant Ursulas, but data that he has not been granted access to will NOT be re-encrypted and therefore Bob can’t access that data.

In our scheme, data is stored uses a KEM/DEM approach, where the bulk data is encrypted using a random symmetric key, and the symmetric key is then encrypted using an asymmetric public key (the public key associated with the ‘label’). The encrypted symmetric key is called a ‘Capsule’. For a diagram of the encryption process, see http://docs.nucypher.com/en/latest/architecture/character.html#enrico-encrypt.

So when Bob goes to the file server, all of the data stored is encrypted using various symmetric keys that he does not know. The only way for him to view the data is to have the relevant Capsules associated with the label that he has been granted access to re-encrypted for him and then he can decrypt the bulk data. For a diagram of that process, see http://docs.nucypher.com/en/latest/architecture/character.html#bob-retrieve.

Overall, because Bob always needs re-encryption to access data, if affords Alice a continuous level of control over her data.

Hi Derek,

Thanks for the response and confirmation that different public/private keys for different labels was the way to go. Am I correct in assuming that the KEM/DEM approach is similar to the ‘hybrid’ / ‘envelope’ encryption approach (AES for the data with RSA or similar for encrypting the AES key, and the ‘encrypted file’ consisting of the AES encoded data and the RSA encoded key(s)) though with different encryption algorithms?

I do have a second question. Suppose there were N people in Alice’s company and she wants to share an encrypted document with all of the them (for example Alice works in HR and needs to share the company handbook which by company policy needs to be encrypted). Am I am correct in understanding the basic implementation would be as follows:

  1. Alice generates a ‘for publication to company’ label with associated public/private key.

  2. Alice issues policies for N-1 people allowing them to access documents encrypted under the ‘for publication to company’.

  3. Alice encrypts the company handbook under the ‘for publication to company’ public key.

  4. When other staff access the document the capsule associated with the company handbook would need to be regenerated as required.

Would this place an administrative burden on Alice’s (and other staff members) in managing the various keys and polices as people leave / join the company, particularly if N is large? Suppose Bob joins the company - does everybody need to create policies to add Bob, or is there some central mechanism for this to automatically add a policy for Bob to access Alice’s ‘for publication to company’ documents (which sounds very much like a master key and so I would be doubtful about this).

The usual approach would be introduce ‘group’ public/private keys, in this case a ‘company group’, with the implementation becoming something like:

  1. A ‘company group’ public / private key pair would be generated and policies issued allowing all the N people in the company access.

  2. Alice would need to have a ‘for publication to company’ label with associated public/private key.

  3. Alice would issue a policy allowing the ‘company group’ access to documents under her ‘for publication to company’ label.

  4. Alice would encrypted the company handbook under the ‘for publication to company’ public key.

  5. An automated process would regenerate the capsule under the ‘company group’ public key, allowing everyone in the company to access the company handbook.

The idea being that the membership of the ‘company group’ could be centrally managed via policies by single person (HR I guess in this case) making Alice’s and everybody else’s life easier. Is this implementation in line with what you are expecting and does the system allow chaining of policies making the ‘automated’ process unnecessary - i.e. Bob requests the handbook and the system recognises that two policies exist - Alice’s policy allowing the ‘company group’ access and the ‘company group’ policy allowing Bob access?

Currently, we use ChaCha20-Poly1305 for the DEM and elliptic curve cryptography (secp256k1 by default) for the KEM.

  1. Alice generates a ‘for publication to company’ label with associated public/private key.
  2. Alice issues policies for N-1 people allowing them to access documents encrypted under the ‘for publication to company’.
  3. Alice encrypts the company handbook under the ‘for publication to company’ public key.
  4. When other staff access the document the capsule associated with the company handbook would need to be regenerated as required.

For your HR scenario, the steps are correct. However, for step #4 in our terminology, we would say that each member of the staff would need to get the capsule re-encrypted (NOT 'regenerated’) for them.

Would this place an administrative burden on Alice’s (and other staff members) in managing the various keys and polices as people leave/join the company, particularly if N is large?

When someone joins, Alice would simply need to issue a policy for that particular person - all other previously existing policies remain valid. When some leaves, Alice would just delete the policy for that particular person - and again all other previously existing policies remain valid.

Alice is simply managing the issuance and revocation of policies. This is how you ensure that data owners maintain ultimate control over their data.

Of course, infrastructure can be built so that profiles of staff members, that include their public keys could be provided so that Alice can easily grant access to them. That would, however, be a layer built on top of the NuCypher Network.

Suppose Bob joins the company - does everybody need to create policies to add Bob, or is there some central mechanism for this to automatically add a policy for Bob to access Alice’s ‘for publication to company’ documents (which sounds very much like a master key and so I would be doubtful about this).

Only the data owner who wants to share data would need to issue a policy for Bob, everyone else who is a consumer of the data would have to do nothing extra.

The usual approach would be to introduce ‘group’ public/private keys, in this case a ‘company group’

That can be done, but in that case, each staff member would require access to the ‘group’ private key which is not ideal. Even worse, if a staff member leaves the company and has knowledge of the private key, you could have a data breach on your hands. To prevent that, you would then have to revoke access to the old group key and re-issue a new policy to a new group key, and then share that group key with the remaining staff members. This is essentially the shortcoming of plain old public-key cryptography.

The idea being that the membership of the ‘company group’ could be centrally managed via policies by single person (HR I guess in this case) making Alice’s and everybody else’s life easier.

As mentioned above, I think that tooling and infrastructure can be built on top of the NuCypher Network to make the administration part easier for individuals - our philosophy has always been to have the data owner dictate who can/can’t access their data. Group policy/key type practices can definitely be incorporated into our workflow, but you should consider what level of security is desired for the use case.

Hi Derek,

I am not suggesting that the group private key is shared among everyone in that group, only that there is an administrator of the group who along holds the private key and whose responsibility it is to add or remove members via creation of policies. Anyway to recap and rephrase the question by setting out some implementation scenarios:

  1. In the default scenario Alice is personally responsible for adding and deleting policies for users. For situations where the documents only need to be shared among a small number of people this is fine, but where for example the documents need be accessed by all users in the company or department this can be mean adding / deleting policies on a daily or weekly basis. Further, where there are a lot of Alices in the company (people creating documents that need to be shared among all users in the department / company) then there is a lot of administration overhead in communicating the necessary changes to these Alices and implementing the policies. Suppose there are M Alices and N users in the company than MxN policies would be needed.

  2. If infrastructure is provided to make life easier for Alice, i.e. suggesting policies to be added / deleted corresponding to the changes in the various sets of users Alice needs to share information with, then i) Alice is likely to blindly follow the recommendations but would be held responsible for adding / deleting the policies, ii) Alice would still need to click on various buttons to implement the changes (else she would in effect be handing over control of her private key) and iii) where there are multiple Alices then MxN policies would still be required.

  3. What I was suggesting was the creation of a group public / private key for a whole company group (and similar for departments and sharing documents with external organisations). The private key would be held by the administrator of the group, probably the HR manager. For Alice to share files protected by her ‘for all company users’ key to all users in the company then she just needs to create a policy allow the company group to access the information. Here i) Alice does not need to click on anything as users join and leave the company, indeed she does not need to know of the movement or indeed existence of various staff (for example in sharing with external organisations), ii) the HR manager is solely responsible for ‘adding / removing’ users to the company group via policies, and iii) only M + N polices are required.

My question was that in scenario 3 above, does the system support the chaining of policies? I.e. If i) Alice encrypts a file under her ‘for all company users’ key and creates a policy allowing the ‘company group’ (single public key) access to those files, and ii) the HR manager has added a policy allowing Bob to access files encrypted under the ‘company group’, then can Bob access documents Alice as encrypted under her ‘for all company users’ key in a single step or are multiple re-encryptions required? If multiple re-encryptions are required does Bob have the authority to request the first re-encryptions (from Alice to the company group)? I believe the answer is yes in both cases.

Thanks

Simon

Hi Simon,

These are great clarifying questions.

I’m definitely not trying to downplay your scenarios, or discredit group keys - I’m just pointing out what possible compromises are being made for convenience.

For instance, Alice can grant access to her data just to the HR administrator (or manager etc.) who can then grant access to others in the department. However, Alice has now ceded control of her data to the HR administrator who she must now trust to act in her best interest. Effectively the administrator becomes a new Alice that grants access to others. Perhaps this is fine, perhaps it is not, depends on the use case, and what you want to achieve/prevent. This is relevant to your “chaining of policies”. Yes, anyone/any entity granted access to data, once they have accessed and obtained/stored the data, can therefore now dictate access to the data they have obtained.

That being said it isn’t instantaneous chaining like you get Alice’s data directly and then that goes through two re-encryptions in one shot; one re-encryption from Alice to the administrator and, then another from administrator to you - this is because our scheme is “single-hop” - see the whitepaper. Rather, you would get the administrator’s data which is encrypted for them, and then get that re-encrypted for you.

Remember that the NuCypher Network is just a layer that other systems can be built on top of. I can imagine some system on top of NuCypher that groups individual user profiles each with their own private/public key. Alice can log into such a system, and say ‘grant access to members of some group’, and that system handles the creation of the policies for each individual belonging to the group. Alice has less administrative overhead in that case, but still maintains control over her data.

This is definitely not the ONLY way, but it is an option. The system can be bespoke to the relevant organization and their various use cases and corporate privacy policies. It is up to organizations to decide how they would want to use our privacy layer, we try not to dictate how it should be used, other than stating the benefits.

For very wide-reaching corporate documents, a philosophical question can be asked about who really “owns” the document. Is it Alice, is it the team, the department, the company as a whole. This may influence who controls the sharing of the document - i.e. a common employee, a manager, a group of managers, department head,…? Again, depends on the situation, but anyone/any entity can be the proverbial “Alice” i.e. the data owner who dictates access to the data.

Hi Derek,

Thanks for the quick response. I realise that the NuCypher Network is something to be built on top of but wanted to understand how it would handle some scenarios that we meet before investing a lot of time on building a test implementation, etc.

With regards to ‘single-hop’ and policy chaining. In the Alice’s ‘all company users’ key -> ‘Company Group’ key -> Bob’s key scenario where Bob is looking to access a document in his possession that has encrypted by Alice under her ‘all company user’ key. Does this mean:

  1. Bob needs to first request a re-encrypted copy of Alice’s file under the the ‘company group’ key, and then would need to request that the re-encryped is again re-encrypted under his own key? Or
  2. the Administrator would need to request a re-encrypted copy of the file first and only then can Bob can request a second re-encrypted version of the same under his own key, i.e. Bob is not ‘authorised’ to request the first re-encrypted copy?

Regarding group keys - note that in scenario 3 above, Alice is not ceding access to all her data to the HR manager, just the data that she has encrypted with the ‘for all corporate users’ key. The rest of her data will no doubt be encrypted with other keys. The point here is that the HR manager is the gatekeeper for who is a member of the company and not Alice. The advantage is that instead of the HR manager having to communicate changes in membership to all the Alices and have them add / delete policies individually, the HR manager could do this themselves via adding / deleting policies associated with the ‘company group’. Use of a group key means a lower communication overhead, fewer policies and a clearer chain of responsibility.

There is another scenario which we frequently meet in which group keys are useful is in supply chains / process chains:

Alice needs to provide information with another organisation within a process chain, say the tax office. Both the tax office and Alice’s company use the same encryption system. In the tax office, userX is in charge of dealing with files, not only from Alice’s company, but also a lot of other companies.

Without group keys Alice will add a policy for userX. However when userX changes job role the tax office will need to notify all the various companies about this change and expect them to update their policies accordingly, which is an administrative overhead.

With a group key (or placeholder key if that is a better term), userX creates a ‘from companies’ group key and adds policies to allow various member or departments in the tax office access to the files. Alice in turn adds the relevant policy allowing the tax office ‘from companies’ key access to those files encrypted under her ‘for tax office use’ key. Now when userX changes job role, the ‘from companies’ public key can be revoked and reissued with the private key for the same under userY in the tax office who is now in charge of dealing with files. The question is, would the existing policies remain with the ‘from companies’ key after reissuing or will UserY need to recreate the relevant polices for the keys?

Thanks

Simon

#2 above is correct. This inherently means that two policies need to created: Alice needs to create one for the Administrator, and the Administrator needs to create one for Bob.

Note - I did not say Alice was ceding access, she is ceding control, because now it is up to the HR manager to grant access to anyone they want. What if Alice decides that for some reason, someone specific in the company/group (who has not left the company) should not have access to her data, then Alice would have to get the HR manager to change that person’s permission as part of the group - so the HR manager has control. In this case, the HR manager is really just another proverbial Alice - which, again, MAY be fine from an administrative perspective for your use case, but it is worth noting that detail.

Our system still works in this case, and you use the multi-step policy that we talked about previously. I think this is what you are getting at but I’ll just reiterate. Alice grants access to some key for that tax office. That key does not have to be assigned to some specific person or group - it could be just the tax office’s relationship key pair used to interact with Alice. The tax office then issues their own internal policies that enable re-encryption from that relationship key to specific people in the tax office. That way the tax office controls access to the data internally, including revoking userX when they change roles and granting for userY, AND Alice can still revoke access to the overall tax office if she wanted to.

Our framework also includes additional features such as policy expiration - so if Alice only works with the tax office during tax season, she can setup the policy to automatically expire after x days when the tax season is over.

Hi Derek,

Regarding the #2 being correct answer. The question is not whether two policies are necessary. The question was if Alice’s policy and the Administrator’s policy are already in existence can Bob access Alice’s document without any further intervention from the Administrator? For Bob to access the file, the file would first need to be re-encrypted from Alice’s public key to the Administrator’s public key, and then from the Administrator’s public key to Bob’s public key. Is Bob able to perform the first step? In other words can Bob request that the file is re-encrypted from Alice’s public to the Administrator’s public key (given that the relevant policies already exist)?

If the answer to the above question is yes, then Bob would need to know about Alice’s policy which doesn’t directly relate to him. As it is easy to envisage longer policy chains, would I be correct in assuming by extension that Bob has knowledge of all policies in the system, or at least as a minimum that he has know of the policy chains that eventually provide him access rights?

If the answer to the above question is no, then the consequence is despite Bob having the relevant file encrypted under Alice’s public key and there is a chain of policies assigning him right of access to the file (Alice -> Administrator -> Bob) then Bob is still not able to access the file. Instead Bob needs to wait for the Administrator to encrypt the file under the Administrator’s public key and have the Administrator pass him that version of the file. Here if the Administrator is on holiday then Bob has a problem.

On the second point in your reply - regarding Alice ceding control of who in the company should access files encrypted under her ‘for all company users’ to the HR manager. For the scenario described I don’t believe we would have any issues with that as the control of membership of the company user group is under the HR manager anyway. If Alice wanted to unilaterally decide who should be in the company, then there is nothing stopping her creating another key pair labelled something like ‘People who I think should be in this company’, creating the relevant policies and encrypting documents under that. However if she missed out users who were in the company or failed to delete ex-company users and started publishing the encrypted files containing internal company content as being accessible by company users only then I would expect HR and security take the necessary action.

The third point was about whether the system retained policies for keys when they are reissued. Suppose Alice has a key with a long list of policies, and her private key is compromised. Her key pair is reissued - does she need to create a new set of policies for the reissued key or does that need to be handled by the system build on top of the NuCypher Network? I suspect it is the latter.

Thanks

Simon

Bob cannot make the request to have Alice’s data re-encrypted for the Administrator, this is fundamental to the single-hop feature. The Administrator has to get the data re-encrypted first, and then Bob can get the subsequent data re-encrypted from the Administrator to himself.

Yes.

If that is the case, that’s fine, but as an optimization then Alice should just encrypt her generated data with an encrypted key defined by the HR manager. No use Alice granting a policy just to the HR manager, and then having the HR manager create policies to control who to share with. Alice should just encrypt data using the HR manager’s relevant public key directly. The real proverbial Alice (who controls access) is just the HR manager in this case.

If Alice’s private key is compromised, then her data is at risk, and Alice will need to:

  1. revoke all the old policies that created re-encryption keys from using that private key
  2. peform a key rotation on her data to be encrypted under the newly issued encryption key
  3. create all new policies using her newly issued key

The key rotation on the data could be a temporary policy between Alice and herself, and once completed for all of her data the policy can also be revoked. The NuCypher API provides the APIs to revoke and create individual policies, but the determination of all of the policies to revoke and re-create will need to be handled by a layer above.

Hi Derek,

Again thank you for the answers. I am fine with recreation of policies when keys are reissued and the answers relating to user groups.

Regarding the scenario where there is a re-encryption chain of userA -> userB -> userC. I am curious as to why re-encryption is restricted to a single-hop in the implementation, i.e. userB needs to personally re-encrypt the file that was under userA’s public key and make the file available to userC before userC can re-encrypt it under their own key. From the description of Umbra Pre, userC does not need access to the private keys of userA and userB or the underlying plain text in order to make multiple hops (i.e. perform the hops userA -> userB and then from userB -> userC), all userC needs is the original file encrypted under userA’s public key. Is the single-hop limitation a theoretical issue, a technical limitation (would need to perform a search of all policies in the system) or a restriction imposed for philosophical reasons?

Thanks

Simon

Hi Simon,

The Umbral scheme that NuCypher uses is single-hop. Umbral uses an ephemeral interim key pair when creating the re-encryption key from Alice to Bob, to make it non-interactive i.e. needing the recipient’s public key instead of their private key to create the re-encryption key. This ephemeral key trick makes the scheme single-hop. For more details on the ephemeral key trick, check out the NuCypher whitepaper.

Hi Derek,

Thanks. I read the white paper now understood what is meant by single-hop as opposed to multiple-hop. I guess I am looking for a multiple-hop implementation for our own needs.

Simon