Decentralizing Data Privacy
cryptography level: intermediate
Many articles were published resently where Blockchain and DLT systems criticized from data privacy. Such law as GDPR, HIPPA are formulated to prevent personal data storing directly on the blockchain. This prohibits us from using this technology to its full potential. However, Blockchain is a technology and as many other it’s a part of architectural design.
Blockchain is a distributed network and data written on it will be available for other participants. Thus, If application records health check results directly on blockchain to increase efficiency of data processing between group of physicians, it means that data will be available for other participants and application’s owner itself. The article introduces re-encryption scheme where users are owners of their data. They decide who will have granted access.
Identity based proxy re-encryption (PRE) is a cryptographic method developed to delegate the decryption right from one party (the delegator) to another (the delegatee). Semi-trusted proxy can transform a ciphertext for Alice into another ciphertext that Bob can decrypt. However, the proxy can learn nothing about the corresponding plaintext. Encrypted data can be stored anywhere — in IPFS, Swarm, S3, Storj or any kind of decentralized or centralized storage. When storing the data, the users to whom they delegate access is not necessarily known in advance.
A naive solution for the secure access delegation problem would be to use conventional encryption techniques (e.g., AES, RSA) and to share the decryption key with the parties designated by the data owner. Symmetric encryption cannot be used alone, since it implies that the same key is shared between producers, owner and consumers or, at least, that for each piece of encrypted data, producers and owner agree on a key, which is extremely inefficient. With respect to public-key cryptography, the problem is that the producers do not necessarily know in advance who are the intended consumers of the encrypted information.
The rest of the article is organized as follows. It starts from “Terms & Definitions” where briefly reviewed the preliminaries of pairing and IBE. Then explained how IBE works and finally PRE itself.
Terms and Definitions:
Identity-based cryptography (IBE) is a type of public-key cryptography in which a publicly known string representing an individual or organization is used as a public key. The public string could include an email address, domain name, or a physical IP address. Usually PRE is built on top of IBE schema.
Pairing-based cryptography is the use of a pairing between elements of two cryptographic groups to a third group. Pairings allow for three-party mathematical protocols. Bilinear maps are the tool of pairing-based crypto (see pic.1). A pairing works on a special pairing-friendly elliptic curve. Weil pairing is sample of such bilinear map.
To explain benefits of pairing cryptography let’s compare 2 different implementations of IBE to exchange messages encrypted by known ID (e.g email address).
Presets: In both cases the central system C exist and it has PrivKey(C) & PubKey(C), where public key is known to every user.
IBE over RSA:
All messages go through the C. Every user knows only PubKey(C) and encrypts the message with that public key. C decrypts the message, and re-encrypts it with the intended PubKey(recipient). If IBE implemented over RSA the C knows all user’s public keys.
IBE over Pairing:
Each users obtain their PrivKey(user) from C. To send an email, sender computes PubKey(reciepent) using recipient’s id (e.g email address) & the PubKey(C).
In pairing model C not need to do anything in particular at the time the email is sent. This prevents C from becoming a network bottleneck when traffic increases.
How IBE works?
An IBE scheme uses a trusted third party called a Private Key Generator (PKG). To set up, the PKG generates a master secret and system parameters. The PKG may have many clients. Each client has some ID, which is simply a string that identifies it — e.g., the client’s email address. The main algorithms in IBE are as follows.
- Setup — generates public params and master key by given security input:
- [OUT] Select bilinear map e of two cyclic groups (G, Gt) of prime order p
- [OUT] Select random generator g of G
- [OUT] Define hash function H → G
- [OUT] Pick master key a and set public key pk of PKG:
- Key-gen — generates User’s secret key by params & existing MK
- [IN] Identity string id
- [IN] Public params
- [IN] Master Key a
- [OUT] Calculate Public (pk) & Secret (sk) keys by id:
- Ecryption — sender computes ciphertext c for message m by id
- [IN] Message m
- [IN] Identity string id
- [OUT] Pick random r
- [OUT] Cyphertext c = (c1, c2):
- Decryption — reciepent recovers m by cyphertext c and id
- [IN] Encrypted message c = (c1, c2)
- [IN] Identity string id
- [IN] Recipient’ private key pk for id
- [OUT] Decrypted message m:
PKG generates the private keys of all of its clients. IBE has two negative consequences: 1) private key escrow is inherent in this system — i.e., a PKG can easily decrypt its clients’ messages; and 2) the PKG must send client private keys over secure channels, making private key distribution difficult.
There are number of variant systems have been proposed which remove the escrow and improve weak sides.
What is PRE?
With the increasing privacy concerns over personal data, proxy re-encryption, in particular IBE proxy re-encryption schemes, will find more and more applications. For example, in the healthcare domain, many regulations, such as HIPPA, require that the patient is the owner of his personal health record and should control the disclosure policy for his Personal Health Record (PHR).
A PRE scheme can be classify by 3 categories: Directionality, Number of hops and Interactivity.
A PRE scheme is unidirectional if the re-encryption keys enable the trans- formation of ciphertexts only in one direction, from delegator to delegatee, and is bidirectional otherwise.
Number of hops:
PRE scheme is single-hop (or single-use) if a re-encrypted ciphertext cannot be re-encrypted again, while it is multi-hop (or multu-use) if ciphertexts are re-encryptable multiple times.
If the secret key of the delegatee is not needed in the re-encryption key generation process, then the scheme is not interactive (i.e., since he does not have to participate in the process). Otherwise, we say it is interactive.
There are 5 basic algorothms of PRE:
- KeyGen(n) → (pkA, skA).
The key generation algorithm KeyGen outputs a pair of public and secret keys (pkA, skA) for user A.
- ReKeyGen(pkA, skA, pkB, skB) → rk(a→b).
On input the pair of public and secret keys (pkA, skA) for user A and the pair of public for user B, the re-encryption key generation algorithm ReKeyGen outputs a re-encryption key rk(a→b).
- Encryption(pkA, m) → cA.
On input the public key pkA and a message m ∈ M, the encryption algorithm Encryption outputs a ciphertext cA ∈ C.
- ReEncryption(rk(a→b), cA) → cB.
On input a re-encryption key rk(a→b) and a ciphertext cA ∈ C, the re-encryption algorithm ReEncryption outputs a second ciphertext cB ∈ C or the error symbol ⊥ indicating cA is invalid.
- Decryption(skA,cA) → m.
On input the secret key skA and a ciphertext cA ∈ C, the decryption algorithm Decryption outputs a message m ∈ M or the error symbol ⊥ indicating cA is invalid.
There are many PRE algorithms exist. They have different properties and need to acheive specific requirements. BBS98 is an example of interactive, multi-hop algorithm, but it’s non-collusion resistant. AFGH is a non-interactive and single-hop.
- jPBC is library for pairing-based cryptography written in Java.
- NuCypher and NICS jointly work on a nice project of a decentralized key management system, that offers cryptographically-enforced access control services. This system operates in a decentralized way and uses advanced cryptographic techniques developed by NICS, such as proxy re-encryption, threshold cryptography and zero-knowledge proofs, that securely embed access control functionality at the encryption level. The ultimate goal of this project is to create a basic infrastructure for the development of secure DApps (decentralized applications), which in turn will lead to numerous applications in many fields, such as fintech, identity management, and other.
- Nuñez, D., Agudo, I. and Lopez, J., 2017. Proxy Re-Encryption: Analysis of constructions and its application to secure access delegation. Journal of Network and Computer Applications, 87, pp.193–209.
- Wang, Xu An, et al. “Identity Based Proxy Re-Encryption Scheme (IBPRE+) for Secure Cloud Data Sharing.” Intelligent Networking and Collaborative Systems (INCoS), 2016 International Conference on. IEEE, 2016.
- Ibraimi, Luan, et al. “A type-and-identity-based proxy re-encryption scheme and its application in healthcare.” Workshop on Secure Data Management. Springer, Berlin, Heidelberg, 2008.
- D. NUÑEZ, “UMBRAL: A THRESHOLD PROXY RE-ENCRYPTION SCHEME”, https://github.com/nucypher/umbral-doc/blob/master/umbral-doc.pdf.