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 as one of our sources of value, attendees look on in slight bewilderment - How can you revoke access to data already shared?

A fundamental principle to understand about revocation is that nobody can ever force a recipient (in the NuCypher cryptology, we always call this Character “Bob”) to forget what they have already seen.

In the context of relatively static data such as your name, ID number, or favourite movie -- ok the last one may/may not be all that static -- revoking access is ineffective if the recipient has already seen it - it's not like they can unsee it. This concept is true in any access management scenario - Bob can always scrawl down the shared information on a piece of paper and secretly stuff it in his pocket.

However, in the context of dynamic data such as medical data (heart rates, blood pressure, glucose levels), measurements from an IoT device, group chats, or location data, it is possible to cease providing access to new data. Revocation in this context means that from that point onwards, any newly generated data will no longer be shared with a recipient previously granted access to the data. Of course, the data shared with the recipient before the revocation occurred has already been seen by the recipient.

Using NuCypher's proxy re-encryption, Alice provides an encryption key to Enrico (the Encryptor), and grants access to the encrypted data to a particular Bob by issuing a policy, that includes a re-encryption key. She sends this policy to Ursula(s) (Ursula is the "proxy" in proxy re-encryption and the Character in our narrative who performs this re-encryption operation).

Subsequently, Ursula(s) can now re-encrypt encrypted data, produced by Enrico, for Bob. When Ursula(s) re-encrypt data for Bob i.e. transform the encrypted data to be instead encrypted under Bob's public key, Bob can decrypt the data using his private key.

To revoke access at a later date, Alice will send a revocation command to Ursula(s) to delete the policy and therefore stop re-encrypting data for that particular Bob. Any new data produced is no longer re-encrypted for Bob. Bob’s requests to Ursula(s) for re-encryption are consequently denied, and Bob is precluded from accessing that data.

Revocation is even more potent when data that could be obtained before the revocation occurred was never accessed. For instance, in the diagram above suppose that Bob never accessed the encrypted data between t₂ and t_n (e.g. he never got around to it, or his queries are throttled such that he only accesses part of the dataset) - i.e. Bob only viewed data that was available at t₁ - and revocation occurred at t_n. At time t_n+1 Bob will still be unable to access data added between t₂ and t_n; even though the policy was issued during that timeframe. Because Bob always needs re-encryption operations to access data, once the policy is revoked and re-encryption is no longer allowed, no data can be accessed.

It might also be the case that Bob wants his access revoked. Imagine a scenario where Alice and Bob work for the same company and are collaborating on a project. Alice has issued a policy for Bob's laptop and another for Bob's cell phone so that each device can access her data. Suppose that Bob's laptop has been lost or stolen. Ideally, Bob would then want Alice to revoke access to his laptop but not his cell phone, which is still in his possession. In this case, each device is its own "Bob" sharing recipient (in our narrative).

A Bob can be revoked without affecting other Bobs because access revocation for a particular dataset is per policy, i.e. per Bob. Alice must issue a policy to Ursula(s) for each Bob that she wants to grant access. Only then can Ursula(s) re-encrypt the encrypted data for each Bob. Therefore, Alice can share the same data with multiple Bobs, and revoke access to a particular Bob without disrupting the access of the other Bobs.

The ease of revocation through NuCypher's proxy re-encryption ensures that data owners continue to maintain control over access to their data even after previously granting access to a recipient.