Alice is a data provider and Bob and Charlie are consumers. Alice has a set of data assets $A_*$. Alice wants to share some of her assets with Bob, some with Charlie (they are not necessarily mutually exclusive).

Apart from the common assets she has shared between Bob and Charlie, she doesn't want the adversaries to access each-others access-restricted data assets. Say if Bob has been given access to $A_1, A_2, A_3$; and Charlie has been given access to $A_3, A_4, A_5$ Bob should not be able access $A_4$ and $A_5$.

Alice also wants to be able to withdraw the access she has granted to adversaries. Say, Alice revokes Charlie's access to $A_3$, even though Charlie used to have access to $A_3$ he should no longer be able to access $A_3$ once his access is revoked. (Note: Charlie might have pro-actively backed-up the data somewhere prior to his access being revoked, we assume they have no means of doing that, or we simply take that risk)

Even though Alice has some means of secure channels between Bob and Charlie, she doesn't have the bandwidth to handle transferring the data she has. Alice wants to place the data encrypted in a public place and issue certification to adversaries to decrypt the data at will.

One solution I have in mind is as follows:

  • Alice encrypts all her assets with a different random key. And uploads the encrypted data to the public storage.
  • Whenever she wants to grant access to any of her assets she simply provides the key and path of the data to any of the adversaries.
  • When she wants to revoke the grants to a specific asset, she deletes the current encrypted version of the asset and issues a new encrypted version and uploads it. And shares the new key with other adversaries that still has access rights to it.

However in this protocol, the overhead of revoking someone's access is quite a burden. We would like to avoid re-encrypting the data. Not sure if there are solutions and schemes that can be employed here, but I'm curious to know if a better protocol exists.

  • 1
    $\begingroup$ In my opinion, it seems quite impossible that Alice can revoke an user without "re-process" the part of the database that was granted to this user. A solution, instead of re-encrypting, Alice might be able to "re-key" the encrypted values. For example let $[r,rk+m]$ be a ElGamal Ciphertext under public key $[k]$ and secret key $k$, Alice is able to compute $[r,rk+rk'+m]$ and refresh the secret key to be $k+k'$. I wonder if this can be done in the private key setting! $\endgroup$ – AntonioFa May 8 '19 at 10:46
  • $\begingroup$ Is it a problem if Charlie can retain access to revoked assets just by making a backup of a small part of each asset? If not, key wrapping could help reduce Alice's revocation workload. If it is, I also see no way around Alice having to re-encrypt and republish the whole asset every time she revokes someone's access to it. $\endgroup$ – Ilmari Karonen May 10 '19 at 9:38
  • $\begingroup$ @Ilmari Karonen Can you elaborate a bit more on key wrapping? $\endgroup$ – zetaprime May 10 '19 at 22:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.