## Privacy Mode Plugin for Greenfield
Currently, the Greenfield permissions are associated with the data resources and accounts/groups, and the group definitions are stored on the Greenfield blockchain publicly with on-chain plaintext access control list (ACL).
We propose a privacy mode for Greenfield based on Ghostor (USENIX NSDI 2020, invented by Yuncong Hu et al.), which hides user identity in the groups by using data-centric key distribution and encrypted ACLs instead of on-chain plaintext ACLs.
The design of the privacy mode is compatible with the existing permission module on Greenfield, is plug-and-play, and each resource can choose whether to use privacy mode with the Ghostor plugin.
Research paper: Ghostor: Toward a Secure Data-Sharing System from Decentralized Trust (NSDI 2020)
https://www.usenix.org/system/files/nsdi20-paper-hu-yuncong.pdf
## Design of the privacy mode based on Ghostor
Each object is corresponding to a pair of read (or write) permission keys. Only authorized users who present the correct signatures can read (or write) the object.
The access control is managed by the key distribution process. The group membership list is stored in the object header, and each entry of this list is the permission signing keys encrypted under a specific user’s public key. Only the user who can decrypt this entry can obtain the permission signing key and access the object.
## Example of the privacy mode
In the example of 17.4.4 in the BNB Greenfield whitepaper, we can do the following:
Let’s say Greenfield has two accounts, Bob(0x1110) and Alice(0x1111). A basic example scenario would be:
-
Bob uploaded a picture named avatar.jpg into a bucket named “profile"; (Bob created read permission key pairs and write permission key pairs).
-
Bob grants the GetObject action permission for the object avatar.jpg to Alice; (Bob uses Alice’s public key to encrypt a read signing key and put the ciphertext in the object header).
-
when Alice wants to read the avatar.jpg; (Alice should decrypt the header and obtain the read signing key to produce the signature. The SP should check the signature is correct using the object read verification key.)
The similar idea can be applied to group management:
-
Bob creates a group named “Games”, and creates a bucket named “profile”. (Bob created the encryption key pairs for the group “Games”, and created copy permission key pairs for “profile”).
-
Bob adds Alice to the “Games” group. (Bob encrypted the decryption key for the “Games” group using Alice public key and put it into the “Games” group header).
-
Bob put a picture avatar.jpg to the bucket profile and grants the CopyObject action permission to the group “Games”. (Bob encrypted the copy signing key for “profile” using the encryption key for the “Games” group and put it into the “profile” header).
-
When Alice wants to copy the object avatar.jpg . (Alice should first decrypt the “Games” group header using her own decryption key and obtain the group decryption key. Alice then decrypts the “profile” header using the group decryption key to obtain the copy signing key. Finally, Alice signs the signature using the copy signing key).
-
BNB Greenfield checks the signature using the copy verification key.
I saw another team working on this using Bplus to encrypt the data on a separate middle layer.