A Reliability Guaranteed Solution for Data

Storing and Sharing

BEJAWADA PAVANI
Author: Bejawada Pavani (e-mail: pavanibejawada27@gmail.com).

ABSTRACT Digital data certified by reputable organizations hold significant value and are often shared or
stored on the internet. However, several challenges arise: (1) How to ensure the anonymity of
organizations issuing certificates? (2) How to securely store valuable digital data within the system? and (3)
How can individuals verify the reliability of shared data while maintaining content confidentiality, and how
to ensure the safety, transparency, and fairness of the data sharing process? To address these challenges,
we propose a comprehensive framework comprising data producing, data storing, and data sharing
schemas. In the data producing schema, we implement a group signature scheme for a consortium of
reputable organizations offering similar services. Each organization within the group processes raw data
from a data owner to generate valuable digital data and issues a certificate on the ciphertext of this data.
In the data storing schema, the data owner uploads their data to the public Inter-Planetary File System
network and records the access address of the stored data along with the corresponding certificate on the
blockchain ledger. In the data sharing framework, every participant within the system has the capability to
confirm the trustworthiness of shared data prior to initiating a data sharing request with the data owner.
The data sharing process is facilitated through a smart contract, and involved parties are required to
escrow funds to incentivize honesty. The data storing and sharing schemas ensure various security
properties, including confidentiality, integrity, privacy, non-repudiation, and anonymity, thereby
addressing the aforementioned challenges comprehensively.

INDEX TERMS Blockchain, IPFS, data storing, data sharing.

I. INTRODUCTION security in both centralized and decentralized

Has become increasingly popular due to its ability to
handle large volumes of data generated by IoT devices.
However, centralized architectures are susceptible to
single points of failure and data breaches, raising concerns
about data security and privacy.
On the other hand, decentralized architectures offer an
alternative approach to data storing and sharing. In
decentralized architectures, data is distributed across
multiple nodes, reducing the risk of single points of failure
and enhancing data resilience. Blockchain technology, in
particular, has gained attention for its ability to create
decentralized and immutable ledgers, ensuring data
integrity and transparency.
Despite the benefits of decentralized architectures,
challenges remain in terms of scalability and efficiency.
Additionally, ensuring data privacy and confidentiality in
decentralized systems requires careful design and
implementation of cryptographic techniques and access
control mechanisms. In this context, our proposed schemas
for data producing, storing, and sharing offer a
comprehensive solution to address the challenges of data
architectures By leveraging technologies such as
group signatures, blockchain, and smart contracts, our
schemas aim to provide a secure, transparent, and
efficient framework for handling valuable digital data
while preserving data privacy and confidentiality.
Studies [3]–[7] have explored methods for
safeguarding the security and privacy of data storage
and sharing, proposing encryption algorithms and
access control models [8]–[11]. Murat Kantarcioglu et
al. [12] introduced SECUREDL to protect sensitive data
in databases. However, centralized architectures face
limitations including data security vulnerabilities and
availability issues [13], where stored data may be
illicitly accessed, modified, or removed, and services
may become unavailable during system crashes or
attacks.
In contrast, decentralized architectures often leverage
blockchain (BC) technology due to its anonymity,
transparency, decentralization, and auditability [14]–
[ 16]. However, existing solutions lack features for
verifying the accuracy and reliability of shared data on
the blockchain network, particularly data certified by
reputable organizations.
1
Reputable organization (RO) are considered as
meaningful data (MD). For instance, in the medical
field, a diagnostic result of an electronic medical
record is published by a reputable medical
organization with highly skilled doctors, which is
MD. In the education field, a lecture that is
assessed and certified by a professional board of a
reputable university is MD. MD needs to be
securely stored on the system, besides a data
owner (DO) can completely share or
commercialize his/her MD to other people or
organizations on the network. Data sharing
methods must ensure that requesters can verify
the reliability and accuracy of shared data before
deciding to perform a data-sharing contract.
In the conventional data sharing approach, the
integrity of shared data relies on the mutual trust
between the two partners involved in the
exchange process. For example, doctors/hospitals
absolutely believe that medical records received
from their patients are integrity. At times,
Responsible Organizations (ROs) must guarantee
anonymity in the Metadata (MD) they generate
themselves. And the privacy of DO also needs to
be protected as they don’t want anyone to know
which RO’s service they used. In In addition,
ensuring anonymity for all parties involved in the
sharing process and verifying the reliability of
shared data while maintaining content privacy are
essential considerations.
Data storage and sharing solutions for certified
digital data must fulfill the following requirements:
• For data storage: Protect the anonymity of
certificate authorities and the privacy of data
owners (DO) regarding stored data; Ensure
confidentiality and integrity of data stored within
the system.
• For data sharing: Enable everyone on the
system to verify the reliability of shared data
without accessing its contents; Facilitate direct
data sharing between data owners (DO) and data
users (DU) without intermediaries.The system
serving data storage and sharing must ensure
availability, integrity, and scalability.
Nevertheless, existing solutions fail to fulfill all
the aforementioned requirements. In this paper,
we introduce data production, storage, and
sharing schemes to address these shortcomings..
We consider RO as a data provider (DP), and DPs
providing the same type of In our paper, we
introduce a comprehensive framework for data
production, storage, and sharing, addressing key
2
challenges in ensuring data accuracy, privacy, and
reliability. The following summarizes our
contributions::
• Proposal of a data production scheme ensuring
accuracy and reliability of meaningful data (MD)
produced by data providers (DP), while
safeguarding DP anonymity and data owner (DO)
privacy.
• Introduction of a data storage scheme utilizing
blockchain (BC) technology and Inter-Planetary File
System (IPFS) for secure data storage.
• Design of a data sharing scheme featuring
Purchase and Resolve algorithms, along with fraud
prevention measures, to facilitate safe,
transparent, and fair data transactions.
• Evaluation of the proposed system and schemes,
assessing their advantages, security features, and
performance characteristics.
II. RELATED WORK
The prevailing trend in blockchain (BC)-based data
storing and sharing solutions involves leveraging
BC for transactions and managing metadata, while
actual data can be stored either centrally or
decentrally. Centralized storage solutions entail
encrypting data before transmission to service
providers, ensuring privacy but risking availability.
To counteract this, decentralized platforms like
IPFS have emerged.
In terms of data sharing, solutions like those
proposed by Qi Xia et al. [17] and Zheng Xiaochen
et al. [18] employ BC frameworks for sharing
electronic medical records (EMRs), albeit relying
on intermediaries like key keepers or verifiers.
Privacy-preserving solutions [19] address EMRs
sharing but lack mechanisms for data reliability
verification. Similarly, solutions like MedBlock [20]
focus on synchronous data storage but lack robust
reliability verification mechanisms.
Peer-to-peer solutions [22]–[24] encrypt data
before uploading to IPFS, employing smart
contracts for access distribution. However,
reliability verification before access remains a
challenge. Recent efforts like PrivySharing [25]
prioritize confidentiality and access control, yet fail
to provide mechanisms for data reliability
verification. Likewise, BC-based mechanisms for
privacy-preserving data sharing [26] lack adequate
reliability verification mechanisms.

III. PRELIMINARIES
A. BLOCKCHAIN
BC technology operates as a decentralized ledger,
structured as a linked list of blocks where each
block references its predecessor via a hash
pointer. The initial block, known as the genesis
block, lacks a parent block. Blocks comprise a
header containing metadata like block ID, version,
previous hash, and timestamp, along with a body
storing transactions. BC networks feature user
nodes, responsible solely for transactions, and
miner nodes, tasked with verifying transactions,
creating blocks, and maintaining the ledger. The
ledger contains immutable blocks, agreed upon by
honest miners, ensuring data integrity. Each node
possesses a public/private key pair for transaction
signing, with the public key serving as the BC
address. BC networks, categorized as public,
private, or consortium, facilitate direct
communication among nodes via a peer-to-peer
network. Consensus protocols like Proof-of-Work
(PoW), Proof-of-Stake (PoS), and Proof-of-Activity
(PoA) synchronize ledger data among miners,
ensuring network integrity and consensus. one of
the consensus protocols can be deployed in a BC
system. Some examples of consensus protocols:
• Proof-of-Work (PoW) [28]: Each miner has to
find a nonce value such that the hash value of
the combination of the new block and the
nonce must be equal to or smaller than a
target hash value H(nonce k prev_hash k tx k
... k tx) < target [29].
• Proof-of-Stake (PoS) [15], [30]: At each mining
round, a miner owning a certain amount of
the network’s total value has a high
probability to propose a new block.
Depending on the particular applications the
stake value will be indicated.
• Proof-of-Authentication (PoAh) [31]: The basic
idea of PoAh is that a normal node records
transactions into a new block. Then, the node
signs on the block before transmitting it to
trusted nodes for verifying. After successful
verification, a trusted node broadcasts the
verified block together with its PoAh
identification to the network. Other nodes
validate the Proof of Authority with the
information provided to incorporate this
block into their local blockchain..
• Proof-of-Activity (PoA) [32]: PoA is a hybrid
consensus protocol between PoS and PoW,
where each miner tries to generate an empty
block header that satisfies PoS requirement,
and then switching to PoS, this block needs to
be signed by a certain amount of stakeholders
to be a valid block.
Ethereum BC, proposed by Vitalik Buterin [33], is
a decentralized turing-complete platform called
Ethereum Virtual Machine (EVM). The programs
that run on EVM are called smart contracts. A
contract is a set of functions defined by a sequence
of bytecode instructions and is executed
automatically when specific conditions are met
[34]. Solidity stands as the predominant
programming language for crafting smart
contracts.
B. IPFS
IPFS, introduced by Juan Benet, functions as a
peer-to-peer distributed file system. Each IPFS
node begins with a key pair (private key and
corresponding public key) and is identified by a
NodeID generated from its public key. There are
three node types within an IPFS network:[36]:
• Client node: This type of nodes uses the
network to store or distribute data.
• Retrieval miner node: A retrieval miner node
is responsible for distributing objects to other
nodes on the network. However, objects are
temporarily cached on its local storage and
are removed periodically by the garbage
collection process.
• Storage miner node: Storage miner nodes
offer extensive storage space and high-speed
processing capabilities to the network.. The
cluster and pinning services can be used in
these nodes for replicating data on cluster
nodes and keep objects available to the
network.
Each file on IPFS is identified by the hash value of
its content, serving as its access address on IPFS.
Uploaded files are organized into objects, each
comprising two fields: the data field, storing binary
data, and the links field, containing an array of
links to related objects. Each link consists of three
components: a name serving as an alias, the hash
value of the pointed object, and the size of the
object. Objects can hold up to 256 kilobytes (KB) of
data. If a file is smaller than 256 KB, it is stored in
3
one object with an empty link field. Otherwise, the
file is divided into 256 KB chunks, managed using
the Merkle DAG (Merkle Directed Acyclic Graph)
data structure.
C. GROUP SIGNATURE
Group signatures, as introduced by Chaum and van
Heyst [38], enable a member of a group to sign a
message anonymously on behalf of the group.
Verifiers can confirm the validity of the signature
without knowing which specific group member
performed the signing. A typical group signature
scheme consists of three main components: group
members, a group manager, and a revocation
manager. The group manager oversees the
establishment and management of the group,
while the revocation manager handles the process
of revoking the anonymity of group members who
have signed a particular signature. Upon
registration and approval by the group manager, a
group member gains the ability to sign digital data
on behalf of the group.Definition 1. (Group
signature). A group signature scheme GS =
(KeyGen,Sign,Verify,Tracing,Vertracing) consists of
the following five algorithms [39]:
• (gpk,gmk,grk,gsk) ← KeyGen : On
input 1 and 1 , output the group’s public key
λ n
gpk, the membership manager’s secret key
gmk, the revocation manager’s secret key grk,
and gsk is an n-element vector of keys with
gsk[i] being the secret signing key of element
i,
1 ≤ i ≤ n.
• σ ← Sign(gpk,gsk[i],M): Given the group’s
public key gpk, a secret key gsk[i] of the i-th
group member, and a message M, issue a
signature σ.
• 0,1 ← Verify(gpk,M,σ): Given the group’s
public key gpk, a message M, and a signature
σ, output 1 if the signature is valid, otherwise
0.
• (i,arg) ← Tracing(σ,M,grk,gpk): Given a
signature σ, a message M, the revocation
manager’s secret key grk, and the group’s
public key gpk, outputs an identity i ∈ [n] and
an argument arg.
• 0,1 ← Vertracing(σ,M,gpk,i,arg): Given a
signature σ, a message M, a group public key
gpk, an identity i of a group member, and an
4
argument arg, output 1 if and only if arg was
generated by tracing or 0 indicating failure.
A group signature scheme must satisfy the
security requirements [39]: Unforgeability,
anonymity, unlinkability, no framing, and
unforgeability of tracing verification.
TABLE 1. Notations
Notation Description
λ Security parameter
n Number of group members
[n] The set of 1,...,n
H The cryptographic hash function
k String concatenation
make_proc(x) The function produces a raw data x to
digital data
:≡ The procedure can be executed through
human intervention.
Rand_Key(·) Random key generation algorithm
Ek(x) Symmetric encryption of x using key k
Dk(x) Symmetric decryption of x using key k
PCS(x,k) The public-key cryptosystem with a
message x and a key k
IV. THE PROPOSED SCHEMES
In this section, we will propose the system model,
threat model, security features, system setup, and
proposed schemes. The paper provides the
notations used, listed in Table.
A. SYSTEM MODEL
Fig. 1 presents our system model. There are four
parties in our schemes.
(i) Data owner: DO is a person who owns
raw data (RD),DO provides RD to a particular DP
for generating MD. DO has the right to store and
share MD, unaltered or modified, for those in
need.
(ii) A group of DPs: Which is created by the
group manager, each DP is an organization that
has the function and means for generating MD
from the DO’s RD. Data Processor (DP) does not
possess ownership of Metadata (MD) and thus
lacks the authority to offer or utilize MD without
the consent of the Data Owner (DO).. DPs in the
group provide the same type of service.
(iii) Data user: DU is a person or organization
who wouldlike to use MD created by DP.
(iv) Decentralized storage (DS): DS mainly
stores EMDand returns the address of EMD to DU.
We use a public IPFS as DS.
(v) Blockchain system: We use BC to reserve
informationof MD and achieve data sharing. The
group manager predefined policies in the smart
contracts to ensure data sharing securely.
FIGURE 1. Our general system model
Our system offers Data Producing, Data Storing,
and Data Sharing defined as follows:
• Data Producing: Which is a manual
procedure, where RD from DO as input, it
outputs MD and some related information
(generated by DP) to DO.
• Data Storing: Using EMD and the relevant
information provided by the Data Owner (DO)
as input, the system stores EMD on IPFS and
initiates a blockchain transaction to store the
access address of EMD (on IPFS) along with
the related information.
• Data Sharing: Upon receiving a store
transaction on the blockchain as input, the
system verifies the integrity of the Metadata
(MD) and executes the smart contract to
enable Data Users (DU) to access the
Metadata..
B. THREAT MODEL
In each of our schemes, we consider the following
threat model.
• Data Producing: DO and DP are involved. We
assume both DO and DP are trusted.
• Data Storing: DO, IPFS, and BC systems are
involved. We presume DO is trusted, and that
IPFS nodes and BC nodes faithfully adhere to
the predefined protocol. However, it's
acknowledged that these nodes may have
access to the contents of data stored on the
systems.. Such nodes’ compromise the
confidentiality of stored data.
• Data Sharing: There are DO, DU, IPFS and BC
systems involved. We assume DO and DU are
untrusted, IPFS and BC systems are similar to
Data Storing scheme. Specifically, DO may
provide the invalid decryption key of EMD to
DU, and DU may submit a dispute resolution
request while it has received the valid
decryption key of EMD.
C. SECURITY FEATURE
System security features as follows:
• Confidentiality: Only authorized individuals
can access the content of EMD stored on BC
and IPFS..
• Integrity: DO is unable to tamper with the
data received from DP.
• Privacy: Based on data stored on BC,
everyone cannot know which DP DO
cooperated.
• Non-repudiation: Parties cannot deny
transactions they have submitted in the data
sharing scheme.
• Anonimity: Everyone cannot know the real
name of participants take part in the data
storing and sharing schemes, and cannot
distinguish which DP generated MD.
D. SYSTEM SETUP
1) THE GROUP OF DPs
The group manager chooses a security parameter λ
and the group signature scheme GS to generate
keys for n group member. Specifically, the group
manager has a public/private key pair (PKGM,SKGM);
the revocation manager owns a public key PKRM
and a private key SKRM; gsk[i] and IdDP[i] are a
private key and an identifier of the i-th group
member respectively, where 1 ≤ i ≤ n; and along
with the group public key (GPK).
2) THE BLOCKCHAIN SYSTEM
DO, DU, and the group manager each initializes an
account on BC system. Particularly, DO owns a
public key PKDO and a private key SKDO; DU also has
a public key PKDU and a private key SKDU; Similarly,
the group manager has a public/private key pair
(PKBCGM,SKBCGM). On the BC network, users use
their public key as a BC address, for instance PKDU
is as DU’s BC address, each transaction must be
5
signed by the transaction’s initiator. The BC system
provides the public BC address.
FIGURE 2. Our proposed data producing scheme
E. DATA PRODUCING
In the data producing scheme, DO transfers RD to
a particular DP in the group, for instance the i-th
DP. After receiving RD, DP performs the Produce
algorithm to generate MD, CERT, and DPInfo. To
guarantee the confidentiality of MD within the
data storing and sharing schemes, DP encrypts MD
to create EMD and subsequently generates a CERT
for EMD.. Later, DP sends these result data to DO
via the security channel. After receiving the results
data, DU verifies the accuracy of MD and DPInfo.
In this scheme, DO and DP are considered to know
each other, therefore, it is not necessary to secure
the identity of each other. This means that DO
knows the identifier of the DP and the group public
key of the group of DPs. The data producing
scheme is described in Fig. 2, Steps involved:
(1) DO transfers RD (in materials form or digital
original data) to a particular DP of the group via a
security channel. (2) After receiving RD, DP
produces MD, CERT, and DPInfo using the Produce
algorithm which includes nine steps: Step 1: DP
uses the make_proc function and the procedure
:≡ to produce MD in digital form.
Step 2: DP creates the identifier of MD by using the
cryptographic hash function provided by the
system. The output is denoted by IdMD.
Step 3: DP executes the Rand_Key procedure to
generate a key K.
6
Step 4: DP encrypts DP's IdDP and K using PKDO
and PCS provided by the system. The output is
labeled as DPInfo
Step 5: DP encrypts DP’s IdDP and K using PKDO
and PCS provided by the system, resulting in
DPInfo.. Step 6: DP encrypts DPInfo and IdMD
using PKRM and PCS.. The output is denoted by
EId.
Step 7: DP generates a signature on EMD using
the Sign algorithm of GS, alongside the group
public key gpk and the group member secret
key of DP, referred to as gks[i]. The resulting
output is denoted by SD.
Step 8: The certificate of MD (denoted by CERT)
includes SD and EId.
Step 9: The algorithm produces EMD, CERT,
and DPInfo as outputs.
Top of Form
. (3) DP sends EMD, CERT, and DPInfo to DO
via a secure channel.
(4) After receiving data from DP, DO verifies the
accuracy of MD and DPInfo as follows: Step 1: DO
decrypts DPInfo using SKDO and PCS
IdDP[i] k K ← PCS(DPInfo,SKDO)
Step 2: DO compares IdDP[i] with the DP’s
information that DO knew before. If they are the
same, go to the next step. Otherwise, stop
verifying.
Step 3: DO decrypts EMD using K and the
decryption algorithm:
MD ← DK(EMD)
Step 4: DO recalculates an identifier for MD:
IdMD ← H(MD)
Algorithm 1: Produce
Input: RD, IdDP[i], gsk[i], gpk, PKDO, PKRM Output:
EMD, CERT, DPInfo
1: Produce MD from RD
MD :≡ make_proc(RD)
2: Create an identifier for MD
IdMD ← H(MD)
3: Generate a random key K
K ← Rand_Key(·)
4: Encrypt MD using K and the encryption algorithm
EMD ← EK(MD)
5: Encrypt the DP’s IdDP and K using PKDO and PCS
 DPInfo ← PCS(IdDP[i] k K,PKDO)
6: Encrypt DPInfo and IdMD using PKRM and PCS
EId ← PCS(DPInfo k IdMD,PKRM)
7: Sign on EMD using gpk, gsk[i], and GS.Sign
SD ← GS.Sign(gpk,gsk[i],EMD)
8: Certificate CERT includes (SD,EId)
CERT = (SD,EId)
9: return (EMD,CERT,DPInfo)
Step 5: DO checks the accuracy of DP’s
information.
True/False ← (PCS(DPInfo k IdMD,PKRM) ==
CERT.EId)
If it returns True, go to the next step. Otherwise,
stop verifying.
Step 6: DO checks the accuracy of MD using the
Verify algorithm of GS
True/False ← GS.V erify(gpk,CERT.SD,EMD)
If it returns True, DO has received accurate and
reliable data. Otherwise, ignore the transaction.
FIGURE 3. The transaction in the data storing scheme
F. DATA STORING
In this scheme, DO uploads EMD to IPFS, and
the access address of EMD along with related
information are stored in a BC transaction. This
transaction information serves as part of the
data sharing scheme. Fig. 4 illustrates the data
storing scheme, which involves the following
steps:
(1) DO uploads EMD to IPFS.
FIGURE 4. Our proposed data storing scheme
(2) After successful upload, IPFS returns the access
address of EMD (denoted by EMD_Link) to DO.
(3) DO submits the TX :: Store_Data
transaction to the BC system, as shown in Fig.
3, This encompasses the following
information::
- DO0s BC address: The BC address of DO. - Public
BC address: The public BC address of the BC
system.
- EMD_Link, CERT, and DPInfo.
- Paymentadd: Payment wallet address of DO. -
Prices: The amount of money that a buyer has to
pay to DO.
- SC: The smart contract address is used for the
sales/purchase process.
If the DO’s signature on this transaction is valid, BC
miners will store this transaction on their ledger.
(4) DO lookups the TX :: Store_Data transaction on
the BC ledger:
TX ← Ledger
Later, DO checks the query result. If TX is not null,
DO has stored data successfully.
G. DATA SHARING
In this scheme, the process of purchasing or selling
data between DO and DU is facilitated through the
Purchase algorithm, with the Resolve algorithm
utilized for dispute resolution if necessary. EMD is
treated as shared data, and the BC serves as the
data market, allowing anyone in the system to find
and purchase the required data. In the data
sharing scheme, participants are required to
provide escrow to the smart contract managed by
the group manager. If any fraudulent activity is
detected, the escrow of the offending party will be
forfeited. Fig. 5 outlines the data sharing scheme,
which involves the following steps:
7
(1)DU initiates the Purchase algorithm, outlined in
Algorithm 2, to search for and acquire the
necessary shared data. Specifically, DU can verify
the reliability of the shared data using the Verify
algorithm of the group signature scheme GS (lines
1-3). It's important to note that DU can only verify
the validity of the shared data but cannot access
its contents. If the shared data is deemed valid, DO
executes the Contract :: Share_Data smart
contract as specified in the TX :: Store_Data
transaction.
cryptosystem, with the output denoted by k0,
and transmitted to DU for decryption.
k0 ← PCS(K,PKDU)
After receiving the key information, DU uses the
DU’s private key to decrypt k’ and get K, then using
K to decrypt the shared data (EMD) (lines 10-11).
K ← PCS(k0,SKDU)
MD ← DK(EMD)

If K is valid, DU performs the TX :: V erify_Key

transaction of Contract :: Share_Data, in which
the Status field is set to V alid (line 12-13),
otherwise, both DU and DO will go to the Resolve
algorithm (line 15). The transactions of the
Purchase algorithm are shown in Fig. 6.
(2) When receiving the request for dispute
resolution from Algorithm 2: Purchase
Input: TX’
Output:
MD DU:
1: Search shared data
2: Download EMD on IPFS
3: if (GS.V erify(gpk,CERT.SD,EMD) ==
FIGURE 5. Our proposed data sharing scheme 1) then
4: Submit TX :: Request_Buy_Data transaction of
the Contract :: Share_Data smart contract
TX :: Request_Buy_Data transaction (line 4). This 5: end DO:
operation is akin to submitting a data buying 6: Submit TX :: Reply_Buy_Data of Contract ::
request to DO. In this transaction, DU also Share_D
transfers a specified amount of money to the
ata DU:
smart contract as an escrow asset. The contract
7: Submit TX :: Transfer_Money transaction to
information is then communicated to DO by the
system application. If DO accepts DU’s request, DO, in which the Money field is the price of
DO initiates the TX :: Reply_Buy_Data the shared data.
transaction of the Contract :: Share_Data smart 8: Submit TX :: Transfer_Bill of Contract ::
contract and simultaneously transfers an escrow Share_Data DO:
payment to the smart contract (line 6). Upon
receiving the transaction from DO, DU executes 9: Submit TX :: Transfer_Key of Contract::
the TX :: Transfer_Money transaction to transfer Share_Data DU:
the agreed-upon payment to DO (line 7). 10: Decrypt k0 and get K
Subsequently, DU sends the bill information to K ← PCS(k0,SKDU)
DO via the TX :: Transfer_Bill transaction of the 11: Decrypt EMD
Contract :: Share_Data smart contract (line 8). If MD ← DK(EMD)
DO has received the payment according to the
12: if (K is valid) then
bill information sent from DU, DO initiates the
TX :: Transfer_Key transaction to send the secret 13: Submit TX :: V erify_Key with the Status
key K to DU for decrypting the shared data (line field is set to Valid
9). Here, K is encrypted using a public-key 14: else
15: Go to the Resolve protocol

8
 16: end
17: return (MD)
DU, the group manager perform the Resolve
algorithm, summarized in Algorithm 3, to
determine who is a scammer. Because the group
manager acts as the referee in the smart contract,
the group manager can track all transactions of
this contract and can know the information of the
shared data (EMD_Link,CERT). In the Resolve
algorithm, the group manager initiates the TX ::
Dispute_Key_Request transaction of the contract
to request DO to furnish the decryption key of the
shared data (line 1).. DO submits the TX ::
Dispute_Key_Reply transaction to the group
manager, in which K is encrypted by PKBCGM and
PCS
(line 2):
EK0 ← PCS(K,PKBCGM)
The transaction of the Resolve algorithm are
shown in Fig. 7. Once receiving the response from
DO, the group manager decrypts EK0 using SKBCGM
and PCS to obtain the secret key K (line 5), and
then uses K to decrypt EMD (line 6). If K is invalid,
the group manager concludes that
FIGURE 6. The transactions in the Share_Data contract
DO is a scammer (lines 7-8). Otherwise, the group
manager encrypts K using the DU’s public key PKDU
and PCS (line 10), it outpust EK10. Finally, the
group manager gets k0 in the TX :: Transfer_Key
transaction, and compares k0 with EK10, if they are
the same, DU is a scammer (DU has received a
valid key but still request for dispute resolution).
On the contrary, DO has sent an invalid decryption
key of the shared data to DU, hence, DO is a
scammer, in this case, the group manager will also
send the valid key K to DU
(lines 11-17).
The rules of the data sharing scheme are
outlined as follows:
• The escrow deposit should be set at 2 or 3
times the price of the shared data to
promote honesty among participants..
• If Data User (DU) has completed the escrow
and submitted the TX :: Request_Buy_Data
transaction, yet Data Owner (DO) fails to
execute the TX :: Reply_Buy_Data transaction.
After a certain amount of time, the smart
contract will automatically return the escrow
deposit to DU.
• If both DO and DU have made escrow,
however DU doesn’t submit the TX ::
Transfer_Money transaction to DO. After a
certain amount of time, the smart contract
will also transfer the escrows back to DU and
DO.
• If DU has already submitted the TX ::
Transfer_Bill transaction, but DO doesn’t
perform the TX :: Transfer_Key of Contract ::
Share_Data within the allotted time, the DO’s
escrow will be lost, and the
Algorithm 3: Resolve
Input: TX’
Output: DO, DU Group manager:
1: Submit TX :: Dispute_Key_Request to
DO DO:
2: Submit TX :: Dispute_Key_Reply to the
group manager
Group manager:
3: Access EMD_Link and download EMD on IPFS
4: Get related transactions of the smart contract
5: Decrypt EK0 using SKBCGM and PCS to get K
K ← PCS(EK0,SKBCGM)
9
6: Decrypt EMD V. SECURITY ANALYSIS
MD ← DK(EMD) In this paper, we integrate blockchain (BC), Inter-
7: if (K is invalid) then Planetary File System (IPFS), and the group
8: SCA ← DO signature scheme to formulate the data
9: else producing, data storing, and data sharing schemes.
10: Encrypt K using PKDU and PCS The data producing scheme facilitates the creation
EK10 ← PCS(K,PKDU) of meaningful data for DO, which can
11: Get k in TX :: Transfer_Key of Contractsubsequently be stored or shared within the
0

system. Our proposed data storing and data

Share_Data
sharing schemes offer several advantages over
12: if (EK10 == k0) then
existing solutions surveyed in Section II. In this
13: SCA ← DU
section, we elaborate on the benefits, security
14: else
features, and performance characteristics of these
15: SCA ← DO
schemes.
16: Send K to DU
17: end A. ADVANTAGES
18: end 1) Proactivity
19: return (SCA) • In the data storing scheme: DO is proactive in
storing EDM on IPFS. Specifically, DO can use
some of his/her devices to join the IPFS
network, then upload EMD on these nodes.
And DO can also remove EMD stored on
his/her devices.
• In the data sharing scheme: DU can fully
verify the reliability of shared data (EMD)
he/she needs before performing the Purchase
algorithm of the data sharing scheme.
Particularly, DU accesses EMD_Link and
downloads EMD. Then DU uses the Verify
FIGURE 7. The transactions in the Resolve algorithm
algorithm of the group signature scheme GS
provided by the system, the group public key
gpk, and SD in CERT stored in the TX ::
smart contract will also return DU’s escrow to Store_Data transaction to verify the reliability
DU. of EMD as follows: True/False ← GS.V
• If DU has already received a valid key from erify(gpk,CERT.SD,EMD) Besides, the sharing
DO, but DU doesn’t make the TX :: V process is done directly between DU and DO
erify_Key transaction of the contract within a without depending on any intermediaries.
certain time, the secret key is considered a This process is performed by the Purchase
valid key and the contract is automatically algorithm of the data sharing scheme.
completed.
• Once the scammer has been identified by the 2) Transparency and fairness in data sharing
Resolve algorithm, the scammer's escrow will • All transactions in the data sharing scheme
be forfeited, and the escrow in the smart are recorded on the BC ledger, which means
contract will be refunded to the honest party. that they are publicly traceable to the
associated addresses.
• Parties involved in the data sharing process
have to transfer escrow to the smart contract
to encourage honesty. In the event of a
dispute, the group manager will resolve this
dispute through the Resolve algorithm of the
data sharing scheme. As a result, the
scammer will lose his/her deposit.
10
B. SECURITY FEATURES
1) Confidentiality
• In the data storing scheme, Metadata (MD) is
encrypted by the secret key generated by DP
before being uploaded to IPFS.. To retrieve
MD’s content, any requestors need to know
the secret key to decrypt such data. Note that
the secret key is encrypted by PKDO before
storing on BC. Therefore, it is very challenging
for the attacker to guess the secret key to
decrypt and obtain MD on IPFS.
• In the data sharing scheme, the decryption
key of EMD will also be encrypted by DU’s
public key in the smart contract. Therefore,
only DU can decrypt and obtain the secret key
for decrypting EMD. In dispute resolution, the
decryption key of EMD is also encrypted
before sending to the group manager.
2) Integrity
In the data sharing scheme, the validity of the
encrypted meaningful data (EMD) is verified using
the certificate (CERT) issued by the Data Producer
(DP). As CERT is generated by DP, it serves as a
means to verify the authenticity and integrity of
EMD. Therefore, even if the Data Owner (DO)
modifies the meaningful data (MD) to create a
new version, they cannot generate a valid
certificate for this modified data because DO lacks
the necessary group member key required for
generating certificates. This mechanism ensures
the integrity and reliability of the shared data.
3) Privacy
The utilization of the group signature scheme
ensures that everyone accessing the stored data
on the blockchain system can verify the accuracy
and reliability of the meaningful data (MD) without
being able to comprehend its content.
Additionally, the group signature scheme
guarantees that the identity of the Data Producer
(DP) within the group used by the Data Owner
(DO) remains undisclosed. This anonymity feature
maintains the confidentiality of the DP's
involvement in generating the MD while still
allowing verification of the data's integrity and
authenticity.
4) Non-repudiation
In both the data storing and data sharing schemes,
every participant is required to sign their
blockchain transactions using their private keys.
Miners on the blockchain network discard
transactions with invalid signatures, preventing
adversaries from impersonating others to execute
transactions. Furthermore, valid transactions are
recorded in the immutable public ledger of the
blockchain, making it impossible for adversaries to
deny their involvement in transactions.
5) Anonymity
In the blockchain network, users are identified
solely by their public keys, without the need for
additional personal information, and their
corresponding private keys are used to generate
transaction signatures. As a result, all blockchain
nodes, Data Users (DUs), and Data Owners (DOs)
cannot ascertain each other's real identities in
transactions. Additionally, the group signature
scheme ensures the anonymity of Data Producers
(DPs). Specifically, no party, including the
revocation manager and the group manager, can
ascertain the identities of group members who
have generated and issued certificates for
Meaningful Data (MD). The anonymity of DPs is
only compromised if both the group manager and
the revocation manager collaborate.
C. PERFORMANCE FEATURES
In the proposed system, the BC transaction system
and the IPFS storage system achieve the properties
as follows:
1) Availability
In our system, both the IPFS storage system and
the BC (Blockchain) system are peer-to-peer
networks with numerous nodes, making it
challenging for adversaries to disrupt these
systems. In the IPFS system, data availability is
ensured even if adversaries attempt to
compromise nodes. If adversaries remove EMD
from a compromised IPFS node, the data may still
be cached on other nodes in the network for a
certain period. Additionally, since the IPFS network
is open, users (DUs) can utilize their devices to join
the network and activate pinning and clustering
services, further enhancing data availability
Similarly, in the BC transaction system, data
consistency and availability are maintained
through synchronization between miner nodes. If
some miner nodes become unavailable due to
denial-of-service (DoS/DDoS) attacks or hardware
errors, the BC system will continue to function as
11
other miner nodes will still uphold the network.
This distributed nature of both IPFS and BC
systems makes them resilient to disruptions and
ensures data availability even in the face of
adversarial attacks or node failures..
2) Integrity
In the IPFS storage system, data integrity is
maintained through the use of hash values, which
serve both as identifiers and access addresses for
the stored data. Any modifications to the data
would result in a change in the hash value, leading
to a new access address. This ensures that the
integrity of the stored data can be verified, as any
tampering would be immediately detected
Similarly, in the BC transaction system, data stored
on the ledger is immutable and synchronized
across miner nodes. Adversaries would face
significant challenges in attempting to modify
ledger data, as doing so would require
compromising the majority or all of the miner
nodes, which is highly unlikely given the
decentralized nature of the network. As a result,
the integrity and immutability of data stored on
the BC ledger are effectively maintained, providing
a high level of security against tampering or
unauthorized modifications.
3) Scalability
Both the IPFS storage system and the BC
transaction system are the peer-to-peer networks,
hence, the expansion is simply adding some nodes
to the networks.
VI. CONCLUSIONS AND FUTURE WORK
In this paper, we propose three schemes: data
producing, data storing, and data sharing. In the
data producing scheme, we view Responsible
Organization (RO) as the Data Processor (DP), with
a group manager organizing a set of DPs offering
the same type of services.. DP can generate MD
from RD sent from DO, and then issues a
certificate on EMD.
In the data storing scheme, we provide not only
the confidentiality and integrity of the stored data
but also the anonymity of DP and the privacy of DO
which have not been fulfilled in the existing
solutions.
In the data sharing scheme, all participants within
the system have the capability to authenticate the
reliability of shared data prior to submitting a
12
sharing request to the Data Owner (DO).. Note that
everyone can only verify the reliability of the
shared data but cannot read its contents. This
property could not be fulfilled by existing
solutions. In addition, the data sharing process is
done directly between DO and DU without
depending on any intermediaries.
The results of the security analysis show that the
proposed schemes meet the security properties
including confidentiality, integrity, privacy, non-
repudiation, and anonymity.
In our future work, we will apply the proposed
system to specific applications such as IoT,
electronic medical records. We will then evaluate
and optimize the scheme.
REFERENCES
[1] D. Reinsel, J. Gantz, and J. Rydning, “The digitization of the
world from edge to core,” Framingham: International Data
Corporation, 2018.
[2] M. F. Bari, R. Boutaba, R. Esteves, L. Z. Granville, M. Podlesny,
M. G. Rabbani, Q. Zhang, and M. F. Zhani, “Data center
network virtualization: A survey,” IEEE Commun. Surveys
Tuts., vol. 15, no. 2, pp. 909-928, 2nd Quarter 2013.
[3] L. Jiang, L. Da Xu, H. Cai, Z. Jiang, F. Bu, and B. Xu, “An IoT-
oriented data storage framework in cloud computing
platform,” IEEE Trans. Ind. Informat., vol. 10, no. 2, pp. 1443-
1451, May 2014.
[4] T. A. M. Phan, J. K. Nurminen, and M. Di Francesco,“Cloud
databases for Internet-of-Things data,” in Proc. IEEE Int. Conf.
Internet Things Green Comput. Commun. Cyber Phys. Soc.
Comput., Taipei, Taiwan, pp. 117-124, Sep. 2014.
[5] K. Yasumoto, H. Yamaguchi, H. Shigeno,“Survey of Real-time
Processing Technologies of IoT Data Streams,” Journal of
Information Processing, vol. 24, no. 2, pp. 195-202, 2016.
[6] A. Kumar, N. C. Narendra, and U. Bellur,“Uploading and
replicating Internet of Things (IoT) data on distributed cloud
storage,” in Proc. IEEE 9th Int. Conf. Cloud Comput., pp. 670–
677, 2016.
[7] K. Hossain, M. Rahman, and S. Roy,“Iot data compression and
optimization tech-niques in cloud storage: current prospects
and future directions,” International Journal of Cloud
Applications and Computing (IJCAC), 9(2), pp. 43-59, 2019.
[8] J. D. Bokefode, A. S. Bhise, P. A. Satarkar, and D. G.
Modani,“Developing a secure cloud storage system for storing
IoT data by applying role based encryption,” Procedia
Computer Science, 89(2), pp. 43-50, 2016.
[9] W. Wang, P. Xu, and L. T. Yang,“Secure data collection,
storage and access in cloud-assisted IoT,” IEEE Cloud Comput.,
vol. 5, no. 4, pp. 77–88, Jul. 2018.
[10] M. Rashid, S. A. Parah, A. R. Wani, and S. K. Gupta,“Securing E-
Health IoT Data on Cloud Systems Using Novel Extended Role
Based Access Control Model,” in Internet of Things (IoT),
Springer, Cham, pp. 473-489, 2020.
[11] R. Arora, A. Parashar, and C. C. I. Transforming,“Secure user
data in cloud compu-ting using encryption algorithms,”
International journal of engineering research and applications,
3(4), pp. 1922-1926, 2013.
[12] M. Kantarcioglu, and F. Shaon, “Securing big data in the age of
AI," in 2019 First IEEE International Conference on Trust,
Privacy and Security in Intelligent Systems and Applications
(TPS-ISA), IEEE, pp. 218-220, 2019.
13