Conference PaperPDF Available

Double-Blind Consent-Driven Data Sharing on Blockchain

  • IBM - IBM Research Australia
Double-Blind Consent-Driven Data Sharing on Blockchain
Kumar Bhaskaran, Peter Ilfrich, Dain Liffman, Christian Vecchiola, Praveen
Jayachandran, Apurva Kumar, Fabian Lim, Karthik Nandakumar, Zhengquan Qin,
Venkatraman Ramakrishna, Ernie GS Teo
IBM Research, {peter.ilfrich, dainliff, christian.vecchiola}, {praveen.j,
kapurva}, {flim, nkarthik, qinzq, vramakr, ernieteo}
Chun Hui Suen±
Blockchain Lead
Abstract Blockchains are designed for trustworthy and
transparent execution of transactions involving multiple
parties. An important class of applications requires data to be
shared selectively among mutually anonymous transacting
peers while retaining the tamper-resistant evidentiary and
validation features of a blockchain. KYC validations of
corporate customers by banks is one example, where both
banks and customers benefit from sharing process and data on
a blockchain network. However, sharing of confidential KYC
data must be authorized by customers, and a bank-customer
relationship must be kept secret from other banks in the
network. In this paper, we describe the design and
implementation of a smart contract for consent-driven and
double-blind data sharing on the Hyperledger Fabric
blockchain platform. We show how a KYC application was
built around this model to address the needs of the banks while
meeting regulatory requirements.
Keywords- blockchain, smart contract, KYC, privacy, access
control, consent, double-blind, cryptography
Blockchains (distributed ledgers) are cryptographically-
linked sequences of transaction records or blocks, maintained
through consensus by networks of transacting peers [6].
Peers may also run smart contracts (decentralized replicated
applications), so-called because blockchain transaction
updates represent the results of collective agreements [7].
Controlling network membership using permissions provides
added trust and performance over public blockchains.
Though transparency of state and execution, assurance,
and process efficiency, are key features of blockchains for
real-world applications, an important class of applications
needs privacy as well as auditability. In such applications,
minimal agreement on processes is sufficient if it obviates
the need for trusted third-parties. For example, financial and
healthcare service providers (e.g., banks, hospitals, and
insurance companies) conducting Know-Your-Customer
(KYC) processes [8] will benefit not just by sharing
customer data but also the work involved in validating these
records. Service customers (data owners) will also benefit by
avoiding the need to repeat the same processes with multiple
providers. Yet customers must have full control over how
their data is shared, and providers must keep their customer
relationships anonymous from other providers to comply
with regulations and maintain their competitiveness.
Providing such guarantees on a blockchain network is
fundamentally challenging as privacy and transparency are
conflicting objectives. Though attempts have been made to
provide privacy for cryptocurrency [3] and some types of
smart contracts [1], the applications of these methods are
limited or require some third-party involvement. Our key
contribution in this paper is the demonstration of a smart
contract on a permissioned blockchain network to ensure that
(i) data is never shared among the peers without explicit
consent from the owners, and (ii) the peer identities are
hidden from each other even while they collectively agree on
the outcomes of transactions. Not only can this model be
applied to a variety of applications, but it can also be
implemented using any commercial smart contract platform
that supports the building of permissioned networks.
Our target application involves multiple service providers
and customers who may not trust each other. They seek cost
savings, process efficiency, and better customer experience,
which can be provided by participation in a blockchain
network, if privacy and access controls are guaranteed.
A. Application Model and Entities
Participants in an application include service providers,
customers, and regulators or auditors. A customer possesses
private data that must be shared with a provider to obtain
services. Different providers process such data using similar
activities (e.g., validations), making these activities amenable
to decentralized execution as smart contracts. Depending on
its current role, a provider can have (i) access to customer
data, (ii) consent from customer but no access to data, or (iii)
no consent from customer or access to data. Providers must
often comply with government-mandated regulations; hence
regulators must be able to audit transaction records.
B. Application Security and Privacy Constraints
The application can be implemented as a smart contract
on a blockchain network if it guarantees the following:
Anonymity of relationships: The relationship
between a service provider and customer is
confidential; e.g., the knowledge that a provider has
access to a customer’s data. Therefore, the real
identity of a provider must remain hidden even while
data is shared or validated.
Customer consent: A customer’s explicit consent is
required for a provider to acquire or process its data.
Access granularity is application-dependent.
Dynamic access control: A customer may grant or
revoke consent to a provider at any time, resulting in
the instantaneous gain or loss of access to data.
Providers on a network can read and refresh customer
data if they possess consent. Revocation of consent applies
only to future updates to data; access to previous versions of
a data unit, which a provider already possesses, cannot be
undone. Clearly, these constraints are not a natural fit for a
blockchain application that provides consensus-based shared
reality across the network to promote transparency and
global visibility. The anonymity constraint is at cross-
purposes with a smart contract’s need to obtain consensus on
transaction results. The selective consent and dynamic
permission constraints are at cross-purposes with the global
visibility features a blockchain is designed to provide.
C. Solution: Double-Blind Anonymous Data Sharing
We handle these challenges by augmenting the smart
contract with additional components and protocols. Our
solution assumes the existence of a basic smart contract that
a data-sharing application must implement as follows:
Step 1: A customer provides private data to one of
the service providers off the blockchain network.
Step 2: The provider processes the data, adds
attributes and metadata, and submits it to the
blockchain for validation and recording.
Step 3: The replicated contract application validates
the data and the authority of the provider to submit it
before approving it for recording through consensus.
Step 4: When another service provider needs to read
or refresh data, it accesses its copy of the distributed
ledger. The customer does not need to resubmit the
data nor does the provider need to reprocess it.
In a conventional blockchain, Steps 2 and 3 would reveal
a customer-provider relationship, and automatic access to
data (Step 4) would violate the customer consent rule. We
use the following mechanisms to avoid these pitfalls:
Public key infrastructure: A PKI issues certificates
to providers, customers, and auditors.
Anonymizing provider identity: A provider’s real
identity must not be visible to other providers during
data recording or access. We use a certificate with a
public key and anonymized fields (issued by the
PKI) as a pseudonym, for reasons outlined below.
Consent on ledger: A cryptographically secure
consent from the customer, associated with a
provider’s pseudonym, is generated off-blockchain
and recorded on the shared ledger after validation.
Encryption of data: The customer’s private data is
encrypted before submission to the blockchain for
validation and recording, preventing other providers
who don’t have the decryption key from accessing it.
Encryption of document-guarding keys: The
symmetric keys used to encrypt data are themselves
encrypted using the public key of a provider that
possesses consent and recorded on the ledger.
Key-sharing on blockchain: A provider that wishes
to get access to customer data issues a key request on
the smart contract. Another provider that already
possesses the key encrypts it using the requestor’s
public key and records it on the ledger. The contract
does not permit key-recording unless customer
consent for the requestor is present on the ledger.
Figure 1. Double-Blind Data Sharing on Blockchain
Figure 1 illustrates the double-blind data sharing model,
so-called because providers can share data and keys with
each other and validate each other’s permissions without
knowing their real identities. Only customers’ identities are
public while their data is protected from inadvertent leakage.
Data collection and validation in a Know-Your-Customer
(KYC) is a prime example of the application modeled in
Section II. Below, we describe how this process works in the
real-world, and how we can optimize it using blockchains.
A. Know-Your-Customer Validations
KYC is a set of processes that financial institutions like
banks must perform before providing services to a customer,
such as opening a bank account. KYC is mandated by
regulatory bodies and exists to detect and prevent nefarious
activities like money-laundering. It begins with Customer
Due Diligence (CDD), or the collection and validation of a
customer’s identity, assets, and associations. This is typically
manual, time-consuming, costly, and error-prone, especially
for corporate customers. Such customers must repeat this
process with other banks they seek services from, which is
wasteful in time, money, and effort. Verifying banks’
compliance with regulations is challenging for authorities,
with frequent fines and legal disputes often being the result.
Therefore, using a blockchain network to connect banks and
customers is an attractive proposition, as an instance of CDD
for onboarding of a customer need be done just once (see
Figure 2.) A bank’s validation of customer info is recorded
on the blockchain and can be used by other banks.
Subsequent profile updates will also incur minimal overhead
for customers as well as banks. Though a centralized KYC
coordinator yields similar cost and time savings, the
blockchain avoids the need to invest trust in a third-party. It
also provides visibility and standardizes the onboarding
process, which provides increased confidence in leveraging
data from another provider. Blockchain also provides a
natural audit trail for all updates to the customer record,
making it easy to track the origin of any incorrect customer
data. But because documentation provided by a customer is
private, and banks do not wish to forego their competitive
advantage by revealing their respective customer lists to
other banks, a conventional smart contract system must be
enhanced with the mechanisms we presented in Section II.
Figure 2. Existing KYC Process versus Shared KYC on Blockchain
B. Shared KYC on Blockchain
Banks and customers can share the KYC process using a
blockchain network (see Figure 2.) A customer portal is the
representative, and the entry point, for one or more
customers in the network. It manages customer data and
credentials, and interfaces with banks to provide consent and
data. Though a customer can run its own exclusive portal,
that may be beyond the means of most business entities other
than large corporates, as running a portal requires significant
resources. It is more feasible for smaller customers to share a
portal and use thin clients to interface with it. The other
application mechanisms are independent of the number of
such portals, and so we will assume without loss of
generality that only one portal exists.
Figure 3. Shared KYC Application Architecture
The information about a customer sought by banks is
collectively referred to as its KYC profile. Information
sought by each bank for their specific onboarding processes
can be different but will be a subset of this profile. Each
bank, as a profile collector and validator, owns a blockchain
peer, which maintains a copy of the ledger and runs
replicated smart contract code. A peer is owned by every
regulator (to audit compliance) and customer portal (to
manage consent) too. The network must be permissioned,
and have an identity provider for enrollment of banks,
customers, and regulators. A key- and certificate-provider
serves as the PKI, enabling participants to generate
public/private key pairs, and accepting certificate signing
requests (CSRs.) Identity, key, and certificate provisioning,
can be performed by a single module in practice.
In the bottom layer of the shared KYC application
(Figure 3) lies the smart contract, or replicated code, which
records customer consent, profile, and other artifacts, on the
ledger after cryptographic validation (see Section IV.) For
KYC, the basic document-sharing contract can be augmented
with as rich a feature set as desired without impacting
privacy properties. In the middle layer lie modules that
submit transactions to the contract and query it for
information. The Bank and Customer Portal APIs also
communicate with each other for consent and profile
management. In the top layer lie web servers offering UIs to
view and process KYC data. They interface with the
blockchain through the middle layer using a REST protocol.
We selected Hyperledger Fabric™ (HLF) to implement a
proof-of-concept shared KYC application based on double-
blind data sharing. In addition to offering peer- and smart
contract-building support, it offers membership services
providers (MSPs) for identity and certificate provisioning.
A. Overview: Hyperledger Fabric
HLF is a platform for building permissioned blockchains,
and its evolution and design choices have been influenced by
the need to support business use cases. The first generation
(HLF v0) is based on conventional blockchain design
involving identical peers with replicated code and data. The
second generation (HLF v1) has a significantly different
design and feature set. Where v0 supports consensus using
the Practical Byzantine Fault Tolerance (PBFT) protocol
[9], v1 separates transaction validation (using pluggable
endorsement policies) and block ordering (using Kafka) [10].
In HLF v1, the endorsement role is optional for a peer, unlike
in v0; every peer is a committer in both. A single trusted
membership service in v0 evolved into multiple separate
organizations in v1. HLF v1 also allows peers to maintain
multiple sub-chains (called channels.) HLF v0 supports two
types of similar x.509 certificates issued by the membership
service: (i) long-lived enrollment certificates (ECerts) for
identification, and (ii) short-lived anonymous transaction
certificates (TCerts), which allow clients to submit
blockchain transactions without revealing their identities.
(Note: the private keys of TCerts are derived from that of the
owner’s ECerts, thereby linking them cryptographically)
[12]. HLF v1 eschews these certificates in favor of pluggable
certificate authorities (CAs.)
We implemented prototypes on both v0 and v1 to prove
that our solution is platform-agnostic. In v1, we did not need
the channels feature, but our design’s reliance on TCerts led
us to implement a simple equivalent feature.
B. Double-Blind Data Sharing Mechanisms
Inspired by the BitCoin technique of associating value
with anonymous public keys, data sharing in our
implementation of shared KYC on HLF is based on profile
data being associated with anonymous certificates
representing banks a customer is getting services from. Just
as Bitcoins cannot be spent without proving possession of
private keys, KYC data can only be shared with banks
possessing the right private keys. Unlike in Bitcoin, we
support consent registration and revocation, and enable
sharing of a profile with multiple banks simultaneously.
Following our design in Section III, each bank, customer
portal, and regulator runs a peer (see Section III) in an HLF-
based shared KYC network. In the v1 implementation, every
peer is an endorser and all participants join a single channel.
Through the API layer, every participant joins the network
through an enrollment process that results in each of them
getting login credentials and an ECert. A customer similarly
enrolls in the network, but through the customer portal. One
or more certificate authorities representing the participants
are registered on the shared ledger during the bootstrap
process. These authorities will be used to validate bank and
customer certificates during smart contract operations.
ECerts are used in our application to assert identity of
banks and customers, embedded in the Common Name (e.g.,
CN=My Bank.) TCerts, in addition to their cryptographic
uses, represent bank pseudonyms for customers to give
consent to. Their Common Names can be general or
randomized (e.g., CN=Transaction Certificate,
CN=abcd-1234.) During smart contract operation, both
TCerts and ECerts are certified by the certificate authorities
registered during bootstrap.
Every customer is issued a unique user identification
number (UIN) and ECert, signed and attested by a registered
certificate authority. The customer’s profile, linked to its
UIN, consists of documents attesting identity, associations,
addresses, etc. Each document has a type (e.g., passport),
which is the most basic access control unit in our application.
When a customer wishes to share its profile with a bank, a
digital proof of a consent (consisting of the UIN, terms and
conditions, and selected document types) is created in
concert with the bank and cryptographically validated in the
contract (see Section D.)
Customers share unencrypted profile data with banks,
which use symmetric keys to encrypt the data, one for every
<document type, customer> pair (this can be done at other
granularities too.) The first bank that records documents of a
given type on the ledger generates a new symmetric key for
encryption. To share with another bank, the public key in the
TCert of the latter is used to encrypt this symmetric key.
C. Data Model and Chaincode
Though Fabric ledger data is organized as a key-value
store, it is possible to overlay a tabular structure for ease of
use. Wrapper functions in the smart contract enable data
reads and writes through combinations of attributes that are
converted into keys for direct store access. Figure 4
illustrates the logical “tables” representing data units and
relationships among them. The customer UIN is part of the
primary key for each table. Each consent record is also
indexed by document type and bank TCert (in SHA-256
hashed form for reduced storage and faster lookups.) Each
customer profile document has a globally unique ID in
addition to a type; lists of these IDs and types are stored in a
separate profile table. A document is stored as an encryption
of the plaintext using a 256-bit AES (symmetric) key.
Separate tables are used to store (i) AES keys encrypted
using the public keys in the TCerts, and (ii) the full TCerts.
Figure 4. Data Model: (ro ws representing values are shaded)
The smart contract, or chaincode in Fabric parlance, is a
collection of functions that uses the ledger as its only source
of state information and supports invocations (reads and
writes) and queries (only reads) through gRPC connections.
Key functions with permitted roles are listed below (Table I.)
Names Role Function description
(I) RecordConsent Bank
Adds customer consent for <bank
TCert, document type list>; validates
bank signatures
(I) RevokeConsent Customer
Removes customerconsent for <bank
TCert, document type>; validates
customer signature
(I) RecordDocument Bank
Records encrypted document;
validates customer’s signatur e; checks
presence of consent for bank’s
(I) RequestKey Bank Records need for an AES document-
decryption key;
no ledger updates
(I) FulfillKey Bank
Records <AES key encrypted using
requestor’s TCert public key>; checks
presence of consent for requestor
(Q) GetDocument All Retrieves encrypted document
(Q) GetProfile All Retrieves list of document IDs
D. Protocols
We focus on two protocols (flows) exercising chaincode
functions that are designed to satisfy the privacy constraints.
Our sample network has two participating banks: ABank and
BBank. A single customer CCorp is represented by a
customer portal CP. As pre-requisites, we assume that
ABank, BBank, and CCorp have enrolled in the blockchain
network, obtaining login IDs, ECerts, and a pool of TCerts
(for later use.) CCorp’s profile, which contains a document
D of type DT, is stored with CP. PKI root (authority)
certificates have been recorded on the ledger during
chaincode instantiation (bootstrap) for validation of banks’
and customers’ certificates.
Figure 5. Protocol: Consent Generation and Recording on Blockchain
CCorp’s consent for ABank to manage documents of type
DT is created through one round trip interaction between the
ABank and CP API modules (see Section III.) As shown in
Figure 5, CCorp sends a consent structure with its UIN
embedded to ABank. which selects a unique TCert for
<CCorp, DT>. It signs (i) the consent using the private key
corresponding to that TCert, and (ii) the TCert itself with its
publicly known ECert. CP can thus validate both the bank’s
ownership of the TCert and its real identity. Next, CP signs
both the consent and ABank’s TCert using CCorp’s ECert
private key. The consent and set of signatures are validated
in the chaincode upon a RecordConsent invocation: (i)
ABank’s TCert ownership, (ii) CCorp’s signature over that
TCert, and (iii) CCorp’s ECert using the pre-recorded
authority certificate on the ledger. This protocol ensures that
the bank cannot forge a real customer’s consent, nor will a
man-in-the-middle attack during the CPABank connection
be effective. ABank can still create a valid consent using a
fake customer, but that customer’s signature will get
invalidated in chaincode, and that bank will not get access to
any real documents. (Note: we rely on the PKI module to be
trustworthy and to conduct identity checks before issuing
credentials to real customers.)
To record document D on the ledger, CP uploads it to
ABank through a REST API. ABank generates a 256-bit AES
key K, encrypts D using K, and invokes a RecordDocument
operation. When BBank subsequently receives consent from
CCorp using the protocol in Figure 5, it does not require CP
to resend D to it. Instead, its API module automatically
triggers a RequestKey operation, which through the event
mechanism, prompts ABank to share the AES key K on the
blockchain in encrypted form using the FulfillKey operation
(Figure 6.) This protocol does not result in the revelation of
ABank’s and BBank’s real identities to each other, but only
their TCerts (TCA and TCB), which simultaneously serve
cryptographic purposes. The chaincode rejects requests and
fulfillments unless suitable consent records are present on the
ledger. Also, any future update to D just requires an upload
by CCorp to CP; no changes to consent records are required.
Figure 6. Protocol: Anonymous AES Key-Sharing on Blockchain
CP invokes a RevokeConsent operation, as a bank cannot
be trusted to process its own revocation. This results in
deletion of a consent record. Upon receiving an event, a bank
(selected by CP) that still possesses consent generates a new
AES key, and re-encrypts and updates documents on the
ledger. The old AES key is now effectively invalid.
Our application also provides mechanisms for regulators
to identify banks involved in KYC data exchanges (to verify
CDD.) The nature of these mechanisms and KYC regulatory
issues are beyond the scope of this paper. Prototypes of the
KYC application were built on (i) a single virtual machine
(VM) running a network of docker containers, and (ii) a
network of VMs in a cloud. The application can also be
deployed in a high-security business network; e.g., the IBM
Blockchain Platform on Linux One Z system [11].
We evaluate how this implementation satisfies the
privacy constraints. Using TCerts to hide bank-customer
relationships from plain view ensures that only an auditor
with privileged access to the PKI, and no other bank on the
network, will be able to infer a bank’s identity by examining
the ledger. Identity leakage through social engineering
attacks is hard as banks uses different TCerts for different
customers and document types. This satisfies the anonymity
constraint. The consent constraint is satisfied by using
RecordConsent and RevokeConsent to instantaneously reflect
a customer’s wishes on the shared ledger. The
RecordDocument, RecordKey, and FulfillKey invocations are
guarded in chaincode by a consent table check, thereby
fulfilling the access control constraint.
Trust is mostly decentralized in the blockchain-based
shared KYC application. But a single customer portal
serving multiple customers is effectively a trusted third
party. This can be mitigated by having a reputed private or
governmental agency run the portal. The PKI similarly must
be trusted and protected, as the anonymity of the banks relies
on its discretion. A single source of trust can be eliminated in
HLF v1 by bootstrapping the blockchain with CA certificates
from multiple external PKIs for transaction validation.
A. Storage Analysis and Scalability Extensions
The KYC process does not need to support transactions
at high volume. Document collections, validations, and
version updates, are infrequent operations; hence storage
concerns far outweigh transaction speeds. There are many
design considerations that must be weighed to design the
storage for such Blockchain-based business networks. For
instance: what information is best stored on the ledger vs
what is best stored off-chain. A full analysis of application
storage is beyond the scope of this paper, but preliminary
measurements indicate that disk usage on each peer grows
linearly with the profile size, with a significant overhead.
This indicates that our solution, though it is ideal from a
security (and trust) standpoint, may not scale with increase in
profile size. Using an off-chain high-performance database to
store profile data may increase performance and minimize
storage overhead over time. Such a storage must be
architected to ensure access control, data encryption, and
secure storage of keys. The ledger then just needs to store
hashes of profile documents for validation, and links to the
off-chain database (these links can be encrypted too.)
However, this solution may not be able to protect data from
tampering and corruption at blockchain standards.
B. Other Applications
We have demonstrated how a KYC process can be
shared by banks and customers using a blockchain and this is
made possible through the double-blind data share model.
This solution can be extrapolated to handle other applications
with similar privacy constraints. Healthcare is one example,
where a patient’s records may need to be collected and
validated repeatedly by different healthcare and insurance
providers, albeit with patient’s consent. Services requiring
background checks may also benefit from our solution.
The two fundamental pillars of our proposed solution are
distributed consent management and double-blind
(anonymous) data sharing. Guaranteeing the anonymity of
blockchain transactions is a well-studied problem, with most
of the proposed solutions relying on zero knowledge proofs.
Sasson et al. [3] proposed Zerocash, which employed zero-
knowledge Succinct Non-interactive ARguments of
Knowledge (zk-SNARKs) to achieve decentralized
anonymous payments. While this construction does indeed
guarantee strong transaction privacy, it comes at the cost of
auditability. Since auditability is often a legal and regulatory
requirement in many applications, enhancements to Zerocash
(e.g., [4] and [5]) have been proposed to achieve both
privacy and accountability. Furthermore, schemes such as
Zerocash focus more on payments and are often difficult to
generalize to other applications that do not involve transfers
or sharing of assets. A more generalized framework called
Hawk was proposed for building privacy-preserving smart
contracts [1]. However, execution of Hawk contracts
requires a special party called the manager, who can see the
user’s data though he cannot prevent the correct execution of
the protocol.
Going beyond transaction anonymity, attempts have also
been made in the literature to achieve the twin goals of
privacy and distributed consent management. For example, a
privacy-enhancing cloud identity ecosystem was proposed in
[2] for user identity management. Like our proposed
solution, [2] uses a blockchain to record user consent and
enable anonymous sharing of user data. However, the key
limitation of this identity ecosystem is the need for trusted
entities called Digital Lock Box Providers, who securely
store the cryptographic keys protecting users’ data and
release it only upon user authentication. Decentralizing the
consent validation step and key release process without
compromising on the auditability is the most significant
contributions of the proposed solution.
While a number of commercial solutions like kyc-,, and Fides ( claim to
enable blockchain-based KYC verification, none of these
solutions provides a fool-proof mechanism for documents to
be validated by a trusted participant in the network before
they are recorded on the blockchain. This distinction is
critical because privacy-preserving sharing of validation
among multiple banks is more valuable than sharing of the
document itself. Other commercial products like spend their effort on data standardization and
harmonization of KYC processes across multiple
organizations, while settling for a simple centralized solution
that relies on a trusted third-party. Our proposed solution will
also greatly benefit from such standardization efforts.
Blockchains represent the future of transactions and are
beginning to transform entire industries. Consequently, there
is considerable interest in exploring blockchains for various
industry use cases. They are particularly useful in supporting
multi-party business transactions where the entities need not
trust each other. The immutable, cryptographically secured,
and replicated, ledger, consensus to validate transactions, and
permissioned access are all attractive salient attributes for
enterprises to consider blockchains as the future transaction
network. However, there are many fundamental challenges
that remain to be addressed such as the tradeoffs between
preserving privacy and promoting transparency. A classic
example of this is the shared KYC use case that is germane
to many industries including finance, health and government.
We have demonstrated through an innovative and novel
double-blind consent-driven data sharing model that
blockchains provide a compelling platform – safe, secure and
scalable for businesses to transact while meeting industry
and regulatory requirements. This holds significant promise
for wider adoption of blockchain in the industry.
The authors would like to acknowledge Josh Andres
(IBM Research – Australia) for help with web portal UI
design, Ivor Zhou (ICBI, Singapore) for help with testing the
application, and Shantanu Godbole and Juhnyoung Lee
(ICBI, Singapore) for management support and guidance in
validating the solution with industry participants.
[1] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk:
The Blockchain Model of Cryptography a nd Privacy-Preserving
Smart Contracts,” IEEE Symposium on Security and Privacy, 2016,
pp 839-858.
[2] “Consumer Digital Identity: Leveraging Distributed Privacy
Enhancing Technology,” (White Paper: Secure Key):
[3] E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer,
and M . Virza, “ Zerocash: Decentralized Anonymous Payments from
Bitcoin,” IEEE Symposium on Security & Privacy (Oakland) 2014,
pp 459-474, IEEE, 2014.
[4] C. Garman, M. Green, and I. Miers, “Accountable privacy for
decentralized anonymous payments”, International Conference on
Financial Cryptography and Data Security (Barbados), pp. 81-98,
[5] “Zero-knowledge Security La yer to be Added to Quorum Blockchain
Platform”, Press Release: m.html
[6] A. M. Antonopoulos, “Ma stering Bitcoin: Unlocking Digital Cr ypto-
Currencies” (1st ed.). O'Reilly Media, Inc., 2014.
[7] “A Next-Generation Smart Contract and Decentrali zed Application
Platform” (White paper):
[8] “What it means to Know Y our Customer’”:
[9] M. Castro and B. Liskov, “Practical Byzantine Fault Tolerance”, In
Proceedings of the Third Symposium on Operating Systems Design
and Implementation (OSDI '99). USENIX Association, Berkeley, CA,
USA, 173-186, 1999.
[10] N. Garg, “Apache Kafka. Packt Publishing”, 2013.
[11] “IBM Blockchain Platform”:
[12] “Hyperledger Fabric v0.6.1: Protocol Specification”:
± Dr. Chun Hui Suen was a member of IBM Research when the work described in this paper was completed.
... Regarding the privacy preserving technique applied for securing blockchain database, CP-ABE has received the attention of several research works [17]- [21], [24], [26], [27]. In [17], Bramm et al. proposed a Blockchain-based Distributed Attribute-Based Encryption (BDABE) scheme allows the attributes to be created and deleted dynamically at any time by a transaction on the blockchain. ...
... In [26], Bhaskaran et al. proposed a design and implementation of a smart contract for consent-driven and double-blind data sharing on the Hyperledger Fabric blockchain platform. The smart contract for generating customer's consent was developed and published on the blockchain. ...
... We compare the functional system between our proposed scheme with two blockchain-based KYC schemes [3], [26], and two blockchain-based IDM schemes including L. Guo et al.'s scheme [21] and S. Gao et al.'scheme [24]. As shown in Table 3, all schemes use blockchain and cloud storage. ...
Full-text available
The electronic know your customer (e-KYC) is a system for the banking or identity provider to establish a customer identity data verification process between relying parties. Due to the efficient resource consumption and the high degree of accessibility and availability of cloud computing, most banks implement their e-KYC system on the cloud. Essentially, the security and privacy of e-KYC related documents stored in the cloud becomes the crucial issue. Existing e-KYC platforms generally rely on strong authentication and apply traditional encryption to support their security and privacy requirement. In this model, the KYC system owner encrypts the file with their host’s key and uploads it to the cloud. This method induces encryption dependency and communication and key management overheads. In this paper, we introduce a novel blockchain-based e-KYC scheme called e-KYC TrustBlock based on the ciphertext policy attribute-based encryption (CP-ABE) method binding with the client consent enforcement to deliver trust, security and privacy compliance. In addition, we introduce attribute-based encryption to enable the privacy preserving and fine-grained access of sensitive transactions stored in the blockchain. Finally, we conduct experiments to show that our system is efficient and scalable in practice.
... In paper (Bhaskaran et al., 2018) the work of the author has based on a user-associated consent-driven mechanism, in which a double-blind data-sharing approach is used for KYC (know your customer) validation using a blockchain system for banking institutions. This provides the dynamic access control of data sharing. ...
Blockchain since 2009 has been gaining more popularity in various fields to use in numerous applications to overcome the security issues such as privacy, transparency, and mutability of data in the process of data sharing. Process of data sharing has many addressed and unaddressed challenges such as information encryption and decryption, data authentication, storage security, latency time, transfer speed of data, detecting malicious nodes, prevent the computer system from attacks, trust in the sharing process. In this chapter, the authors have reviewed the data sharing paper based on blockchain technology and presented the analysis of various techniques used in the information sharing process. The comprehensive analysis is categorizing in the following areas like incentive mechanism-based work, IoT-based data sharing, healthcare data sharing, and internet of vehicle data sharing using blockchain.
... Recently, Blockchain has been utilized in applications that require data to be shared [13,14,15,16]. Blockchain is a distributed and shared transaction ledger by all participating in the system [17,18]. ...
This study presents a new generalized recommender system framework based on Blockchain technology called BC-Rec. Blockchain technology is a decentralized data-sharing ledger across a large network of untrusted entities. The presented idea is motivated by the fact that e-business platforms share common data about users, items, and sellers. In other words, a new user/seller in a particular e-business platform may be a trusted user/seller in other e-business platforms. Also, a new item in a particular marketplace may have a historical record in other marketplaces. The core idea behind BC-Rec is to adopt Blockchain technology to share the data required to generate the recommendation between the e-business platforms. BC-Rec architecture is designed based on a permission-less public Blockchain network, Ethereum Blockchain. The key feature of BC-Rec is the smart contract deployed to determine the agreement between certain entities on the Blockchain. We expect that the proposed framework will help alleviate cold-start, sparsity, and shilling attack problems.
... Li et al. introduced DMMS [9], a solution that exploits blockchain technology for medication history management and electronic prescriptions. Bhaskaran et al. [12] proposed a solution to store consumers' data in encrypted form on blockchain. Entities that wish to get access can raise consent requests on the chain, and the data owners can provide such consent in a cryptographically secure manner using standard encryption with event pub/sub. ...
Full-text available
A blockchain is a digital record that stores transactions publicly after nodes have verified them. The nodes validate each transaction, and the cryptography hash function secures the transactions. A transaction is linked by the hash value of the previous transaction. No one can amend or alter a transaction once it is added to the blockchain, but it can be viewed publicly, bringing transparency to the system [1]. To validate a transaction, blockchain employs some proof-of-work and proof-of-stake techniques. In the previous years, the growth of blockchain innovation has demonstrated that it offers a vast range of use cases. The combination of blockchain technology and smart contracts allows for a great deal of flexibility to develop, design, and implement real world problems at a lower cost and less time than traditional third-party systems [2]. This section covers introduction of smart contracts and off-chain contracts. The section also covers the literature survey.
Full-text available
The Know Your Client (KYC) process is an essential part of the financial ecosystem. The KYC process requires banks to validate and verify primary documents. The market these days, though, is flooded with KYC utilities that facilitate this process and share these documents with multiple entities, however they provide very little value addition. Blockchain technology, with its concept of immutable timestamped ledgers and distributed systems, can effectively facilitate banks to improve their KYC methods by allowing near real-time data exchange among various entities for quicker and effective validation ensuring data integrity alongside bringing down the time and costs significantly.
Full-text available
Despite the rapid digital transformation of banks and financial institutions, state-of-the-art Know Your Customer (KYC) processes still require customers to provide multiple artifacts to the different banks they collaborate with. In an era where data sharing is facilitated from a technological and a regulatory point of view, there is huge potential for improving the efficiency of KYC processes. However, this requires a trustful environment for exchanging data across the various stakeholders, including customers, banks, and other financial organizations. This chapter illustrates how blockchain technology can be used to foster such a trusted environment. It also presents the implementation of a decentralized KYC solution over the Hyperledger Fabric permissioned blockchain infrastructure.
Full-text available
Thesis (Ph. D.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, February 2001. Includes bibliographical references (p. 163-168).
Full-text available
This paper describes a new replication algorithm that is able to tolerate Byzantine faults. We believe that Byzantinefault -tolerant algorithms will be increasingly important in the future because malicious attacks and software errors are increasingly common and can cause faulty nodes to exhibit arbitrary behavior. Whereas previous algorithms assumed a synchronous system or were too slow to be used in practice, the algorithm described in this paper is practical: it works in asynchronous environments like the Internet and incorporates several important optimizations that improve the response time of previous algorithms by more than an order of magnitude. We implemented a Byzantine-fault-tolerant NFS service using our algorithm and measured its performance. The results show that our service is only 3% slower than a standard unreplicated NFS. 1 Introduction Malicious attacks and software errors are increasingly common. The growing reliance of industry and government on online information...
Conference Paper
Decentralized ledger-based currencies such as Bitcoin provide a means to construct payment systems without requiring a trusted bank. Removing this trust assumption comes at the significant cost of transaction privacy. A number of academic works have sought to improve the privacy offered by ledger-based currencies using anonymous electronic cash (e-cash) techniques. Unfortunately, this strong degree of privacy creates new regulatory concerns, since the new private transactions cannot be subject to the same controls used to prevent individuals from conducting illegal transactions such as money laundering. We propose an initial approach to addressing this issue by adding privacy preserving policy-enforcement mechanisms that guarantee regulatory compliance, allow selective user tracing, and admit tracing of tainted coins (e.g., ransom payments). To accomplish this new functionality we also provide improved definitions for Zerocash and, of independent interest, an efficient construction for simulation sound zk-SNARKs.
Mastering Bitcoin: Unlocking Digital Crypto-Currencies
  • A M Antonopoulos
A. M. Antonopoulos, "Mastering Bitcoin: Unlocking Digital Crypto-Currencies" (1st ed.). O'Reilly Media, Inc., 2014.