DAM-Chain: Digital Asset Management Platform using Blockchain and ABAC

This report introduces DAM-Chain, a novel digital asset management (DAM) platform designed to enhance the management and security of digital assets in an open, decentralized environment. The core innovation lies in its integration of blockchain technology with attribute-based access control (ABAC). The platform, called DAM-Chain, leverages the immutable and transparent nature of blockchain to ensure verifiable and traceable access control processes. It introduces Transaction-based Access Control (TBAC) to facilitate flexible and diverse permission management. The paper details four transaction types: subject registration, object escrowing and publication, access request, and grant, along with the corresponding algorithms. By combining ABAC's flexible authorization mechanisms with blockchain's security features, DAM-Chain aims to provide a robust solution for managing digital assets with enhanced security, transparency, and control. The report also discusses the advantages of blockchain in DAM, the challenges in integrating access control, and the contributions of the proposed DAM-Chain platform, highlighting its potential to address the limitations of traditional DAM systems.

Digital Asset Management with Distributed Permission
over Blockchain and Attribute-based Access Control
Yan Zhu1∗, Yao Qin1, Zhiyuan Zhou1, Xiaoxu Song1, Guowei Liu2, William Cheng-Chung Chu3
1School of Computer and Communication Engineering,
Univerisity of Science and Technology Beijing,Beijing 100083,China
2Beijing Municipal Commission of Economy and Informatization,Beijing 100101,China
3Department of Computer Science,Tunghai University Taichung,Taiwan
∗Email: [e-mail]
Abstract—Digitalassetmanagement(DAM) has increasing
benefitsin booming globalInterneteconomy,but it is still a
great challenge for providing an effective way to manage,store,
ingest,organize and retrieve digital asset.To do it,we present a
new digital asset management platform, called DAM-Chain, with
Transaction-based Access Control(TBAC) which integrates the
distribution ABAC model and the blockchain technology.In this
platform,the ABAC provides flexible and diverse authorization
mechanismsfor digital assetescrowed into blockchain while
the blockchain’s transactions serve as verifiable and traceable
medium of access request procedure.We also present four types
of transactions to describe the TBAC access controlprocedure,
and provide the algorithms of these transactions corresponding
to subject registration,object escrowing and publication,access
request and grant.By maximizing the strengths of both ABAC
and blockchain,this platform can supportflexible and diverse
permission management, as well as verifiable and transparent ac-
cess authorization process in an open decentralized environment.
Index Terms—digitalassetmanagement;blockchain;access
control; transaction; attribute-based
I. INTRODUCTION
Digitalassetmanagement(DAM) provides a way to or-
ganise companysvaluable files,called digitalassets,in a
way thatmakes them quick-to-find and easy to access.In an
information economy,everyone can gain a huge advantage
overtheircompetitors by handling theirdigitalassets more
effectively than others. We all process digital assets, whether as
documents, audible content, motion picture, and other relevant
digital data that are currently in circulation, or files sent to us
via email,all of which bring us wealth.Therefore,effective
digital asset management has taken on increased importance.
A DAM system represents an intertwined structure incor-
porating both software and hardware and/or other services in
orderto manage,store,ingest,organize and retrieve digital
assets.Moreover,it providesthe unbroken maintenance of
the ownership ofa digitized objectwhile permitting access
to those who have obtained rights to thataccess.The digital
asset management offers many advantages and benefits, which
consist of
1) the ability to dynamically distribute assets to internal
and external teams;
2) a place to quickly find and retrieve assets;
3) the ability for the owner to control who else may view,
use,or modify the assets; and
4) a mechanism to keep track of assets’ history,so as to
reuse them for maximizing their value.
DAM has increasing benefits in booming globalInternet
economy,but it is still a greatchallenge forconstructing
an effective DAM.Fortunately,blockchain technology may
be one of the effective ways to solve this problem.Exactly,
blockchain is a digital decentralized ledger that keeps a record
of all transactions thattake place across a peer-to-peernet-
work.The features of blockchain,including decentralization,
tamper-proof, and traceability, stem from its cryptographically
secure data structure [1] thattakes a number of records and
puts them in a block (like collating them on to a sheet).As
shown in Fig. 1, each block is then chained to the next block,
using a cryptographic hash. In addition, the Merkle hash tree,
as a type of binary tree,is introduced to guarantee thatthe
transaction details are validated,and thus cannotbe altered
later on. In virtue of decentralized nature and above-mentioned
properties, the blockchain allow mutually distrustful parties to
transact securely without trusted third parties.
Prev hash Tx hash nonce
hash hash
Tx a Tx b Tx c Tx d
Block header
Prev hash
Tx hash
nonce
Prev hash
Tx hash
nonce
Prev hash
Tx hash
nonce
Block Block Block
Block
Block header
Fig. 1. Block structure of blockchain.
Blockchain technology should be a preeminent solution for
DAM because itprotects the ownership of digitalassets and
protects the information from being misused.Firstly,it is not
easy to modify digitalassets stored on blockchain because
the assets are stored with a hash.In fact,it is distributed to
a large number of validators which makes itextremely hard
to tamper any data in blockchain.Secondly,the validity of a
193
2018 IEEE International Conference on Services Computing
2474-2473/18/$31.00 ©2018 IEEE
DOI 10.1109/SCC.2018.00032

DAM transaction is determined by consensus of the various
computers or nodes in the network instead of having a central
trusted or officialrecord.Moreover,blockchain can be used
to verify the transferof ownership ofdigitalassets oreven
just the rightto accessand use such assets.In summary,
digitalassetmanagementcould leverage security properties
of blockchains,which include:
• Impossibility of counterfeit,
• Immutability,
• Disintermediation and ease of transfer,and
• Transparency and ease of auditing.
Therefore,there is no denying in the fact that Blockchain has
immense potential to become an important component of any
DAM strategy.
Although blockchain provides some unique properties for
distributing and managing digital asset, it is still unable to meet
the requirements offlexibility,diversity,and dynamicity for
permission management. For example, if requesters want to get
access to a certain digital asset, they must have the permission
of whoever manages itand provide some declarations (or at
least hints about how to transact on the required digital asset).
More concretely, in the healthcare system the patient’s medical
records mustfollow strictaccess constraints to preventthe
leakage of sensitive information.Or,the distribution of copy-
righted media must be consistent with copyright requirements,
such as,some movies can only be played in a specific region
or a certain device.To overcome this problem,it is a direct
and effective method to introduce access controltechnology
into DAM.
In the last two years, several new researches have addressed
the problem ofintegrating accesscontroland blockchain
technology.For example,Ouaddah etal. proposed a frame-
work, called FairAccess,for accesscontrolin Internet-of-
Things(IoT) on the blockchain [2].This framework used
organization-based access control (OrBAC) to enable users to
own and control their data. However, the granularity of OrBAC
is not enough to realize digital asset management considering
that its organization structure may remain relatively fixed over
time. Xu et al. also proposed a distributed ledger based access
control(DL-BAC) schemefor Web applications[3]. This
scheme adapt access control list (ACL) to realize a lightweight
decision-making and granting access.For the future work,
they plan to extend the privacy enhanced DL-BAC to support
morecomplex accesspoliciesincluding role-based access
control(RBAC) and so on.To addressthe same problem,
Azaria et al. used the blockchain to implement a decentralized
medicalrecord access and permission management[4] with
authentication,confidentiality and accountability.Xia et al.
also proposed a blockchain-based data sharing framework [5]
which allows access to only invited,and hence verified users.
As a result of this design, further accountability is guaranteed
as all usersare already known and a log oftheiractions
is keptby the blockchain.In general,these researches have
enlightening significance for our research.
To implement a flexible, diverse and dynamic access control
in DAM, in this paper we intentto introduce attribute-based
access control(ABAC) [6] into the blockchain.ABAC pro-
vides an efficient approach to accommodate a wide breadth of
access controlpolicies and simplify permission management.
Recently,severalpracticalframeworks,such asExtensible
Access ControlMarkup Language (XACML)[7] and Next
Generation Access Control(NGAC), have been proposed to
providea standardized way forexpressing and enforcing
vastly diverse access control policies on various types of data
services.These frameworks possess two major features:
• Diversification:the ability to extractattributevalues
from multi-source,various places,differenttypes,e.g.,
GPS location,time,visitor traffic,or threat level;
• Dynamicity:the ability to provide runtime supportfor
acquiring thepolicy and attributesassociated with a
subject,object,action,or environmentin which access
requests occur.
In otherword,accesscontrollogic of ABAC engine can
determine who should have access to whatresources under
whatcircumstances and by taking whatactions.Hence,the
ABAC is particularly usefulfor an open environment,such
as blockchain.However,we should note thatthere existstill
several actual challenges that need to be solved.
One of the core challengesto be addressed ishow to
integrate access control mechanisms in ABAC into blockchain.
An effective solution for this problem is to constructvarious
blockchain’s transactions corresponding to the steps of access
control procedure, e.g., store, ingest, organize and retrieve, for
digitalassetmanaged by DAM.By means of this approach,
a registered useris allowed to publish his/herown digital
assets to all members in blockchain, and then the platform can
ensure the member’s access abided by common ABAC’s rules.
Furthermore,these transactionsrecorded in the blockchain
achievethe goal of ownership claiming,assetescrowing,
transparency and verification of all steps.
Our Contribution.In this paper we focus on a new genera-
tion of digitalassetmanagementplatform in a decentralized
organization oralliance.This platform can supportflexible
and diverse permission management, as well as verifiable and
transparentaccess process.Exactly,we notonly provide a
complete new access control framework and procedure, but al-
so conduct researches on concrete implementation techniques.
Our contributions are listed as follows:
• We presenta new digitalassetmanagementplatfor-
m, called DAM-Chain,with Transaction-based Access
Control(TBAC) which integrates the distribution ABAC
modeland the blockchain technology.In this platform,
the ABAC providesflexible and diverse authorization
mechanisms fordigitalassetescrowed into blockchain,
and the transactions in blockchain serve as verifiable and
traceable medium of access request procedure.
• We presentfour typesof transactionsto describe the
TBAC accesscontrolprocedure,and providethe al-
gorithms ofthese transactions corresponding to subject
registration,objectescrowing and publication,access
requestand grant.Moreover,the Bitcoin-type crypto-
194

graphic scripts are designed to guarantee authorization
relationship among these transactions.
Organization.The restof the paper is organized as follows.
We describe our TBAC framework and various transactions in
Section II and IV.The paper concludes in Section VI.
II. SYSTEM FRAMEWORK
Digitalassetmanagement(DAM) has increasing benefits
in booming globalInterneteconomy,butit is still a great
challenge forproviding an effective way to manage,store,
ingest,organize and retrieve digitalassets.To achieve our
goal, we introducethe distributed ABAC modelinto the
exiting blockchain for utilizing the policies to restrictuser’s
access. Moreover, we intend to design new transaction-enabled
mechanismsto guarantee the enforcementof these access
policies correctly.These mechanisms would provide a good
solution forenhancing the creditability ofpolicy decision-
making,as wellas attribute diversification and dynamicity.
This new solution should be sufficiently generalto provide
the following functions:
• Asset security: by using transactions,it needs to imple-
ment adequate authorization protocols to identify owner-
ship and permit transfer or issuance of assets.
• Secure asset issuance:the shared objects are escrowed
into blockchain by using a verifiable transaction, and then
the accessrulesand policieswill be used to prevent
unauthorized entities from accessing to the object in the
open environment.
• Distributed Permission:multiple authorization centers
and all relevantpartscan make a comprehensiveness
decision ofaccessrequestby providing thedifferent
attributes and certifications.
Blockchain and ABAC model also provide some good proper-
ties to implement our goal,e.g.,the blockchain’s transactions
inherently provideauthenticity,integrality,traceability and
somewhatanonymous,and the ABAC modelis featured as
flexibility, dynamicity and diversity for resource management.
A. Standard ABAC Model
We illustrate the standard ABAC modelgiven by NIST,
which is the foundation ofsubsequentresearch.Within the
NIST’s ABAC model [6], there exist four kinds of entities, i.e.,
subject,object,action,and environment.The characteristics
of these entities are defined as attributes.According to these
attributes,access policy extracted from common rules is used
to determine whether a subject requests to perform operations
on objects should be allowed under a specific environment.
The ABAC’s reference architecture isshown in Fig.2.
This architecture includes four service nodes such as policy
enforcementpoint(PEP), policy decision point(PDP), pol-
icy information point(PIP), and policy administration point
(PAP). Also, PDP and PEP functionality can be distributed or
centralized, and they constitute so-called authorization service
(AS). For an access request,the workflow of this architecture
is described as follows:
1) The PEP intercepts the access requestfrom an authen-
ticated subject and sends the request to the PDP.
2) The PDP makesaccessdecision according to access
policy generated by PAP and the attributes of subject,
object,and environment obtained by querying the PIP.
3) The final decision result given by the PDP is sent to the
PEP, and then the PEP fulfills (either permits or denies)
the access request according to the decision of PDP.
Policies
Environment
Attributes
Subject
Attributes
Object
Attributes
Action
Attributes Make Decision Permit/Deny
Fig. 2. The NIST’s ABAC model.
The above architecture is also composed of two repositories
and many environmentperception modules.Two repositories
store and manage common access rules and entity attributes,
respectively.The environment perception module can acquire
the environmentinformation atthe currenttime relevantto a
request,in which these information may include the current
time,location,threat level,device’s type,etc.
B. Threat Model
In this work, we mainly consider the threats from the semi-
trusted cloud server and malicious client in an open and large-
scale resource sharing.Here,we first assume cloud itself
is semi-trusted,which meansit honestly followsprotocols
and does notpollute data integrity actively as a malicious
adversary, but it may try to find out as much secret information
of stored data as possible. Malicious clients may try to access
the data withoutpermission by data owner.The goalof our
system is to guarantee thatonly authorized clientcan access
the data and conversely unauthorized clients or cloud will learn
nothing by using access control and resource encryption.
In addition,we assumethatour TBAC is deployed in
an open and untrusted environment.All componentsare
decentralized and distributed acrossthe complete platform.
Moreover,the attackercan eavesdrop and counterfeitthe
communication between any two componentsin platform.
However,we do not assume that the attacker can corrupt any
functionalcomponents.To these assumptions,the security of
TBAC focuses mainly on three aspects:transaction security,
authorization security,and decision-making security.We dive
into the details as follows.
III. OUR TBAC PLATFORM
We present a new digital asset management platform, called
DAM-Chain,with transaction-based access control(TBAC)
platform on blockchain and cloud storage to realize our design
195

Blockchain
User Owner
Policy
Enforcement
Point (PEP)
Policy Decision
Point (PDP)
Attribute
Grant
Unit(AGU)
Policy Depository
Serverδ PDSε
Object
DETRequest Decision
Request Attribute
Token
Request
Policy
Request Data Depository
Server (DDS)
Authorization Service Unit (ASU)
ART
signature
Cloud Computing
Environment
Fig. 3. The framework of TBAC model.
goal. This platform uses the blockchain as the core of resource
distribution and sharing while introducing ABAC modelto
implement flexible resource access authorization.
A. Our TBAC Construction
The TBAC platform isperfectly engaged in “off-chain”
storage,where blockchain as objectdirectory is adopted for
the retrievalservice of resources,and the DDSs are actually
used to deposit them by using cloud computing environment.
The advantage of this storage way is to reduce the overhead
of user’s management data. Considering the privacy of shared
objects,they willbe stored into the DDSs in an encrypted
way.The encryption process is implemented by the object’s
owner before submitting into the DDS.
As shown in the Fig.3, the new TBAC consistsof a
blockchain and some additional modules under ABAC model.
These additional modules are described as follows.
• Data DepositoryServer (DDS): storesthe owner’s
escrow objects, and provides access service for the shared
objects.
• Authorization Service Unit(ASU): evaluates and en-
forces access decisions in response to the request from a
subject requesting access to a protected object.
• Policy Depository Server (PDS): manages and retrieves
common accessrules,and producesthe accesspolicy
from the rules according to the user’s request.
• Attribute Grant Unit (AGU):serves as the acquisition
source of attribute values required for policy evaluation.
The presented TBAC platform is consistent with the NIST’s
ABAC model [6], so thateach module containsa certain
functional point in the ABAC model.Specifically,the AGUs,
as function extension of the PIPs, are dispersed into the whole
blockchain network,e.g.,environmentattribute values could
come from a client-side equipmentwhere the user sends an
accessrequest.Moreover,the attribute,acquired from the
AGU, would be issued in a way of verifiable security Token,
called attributeToken,in order to preventa forgery of
attribute.
The PDS can be considered as a specific implementation of
the PAP in the ABAC model.It is responsible for managing
the common access rules which can be combined together to
express policy according to the user’s access request.
The ASU, including PEP and PDP, is main execution agent
to monitor,evaluate,and enforce the decision in termsof
the user’s access require.PEP and PDP functionality may be
puttogether or separated from each other.For example,the
overall ASU can be deployed on the client side. However, this
setting,which requires high communication and computation
overheads,is not suitable for lightweight devices.Instead,we
would prefer to putthe PDP into the blockchain’s node,but
to lay the PEP into the client’s application in order to improve
the performance.
B. The Workflow of TBAC
The TBAC platform provides the entire process manage-
mentof resource distribution and sharing,including subject
register,resource publish,permission managementof access
acquire.In TBAC, any user mustregister to the platform by
a certain AGU.For a registered user,the AGU manages the
user’s subjectattributes and submits the user’s information
(encapsulated into subjectregistration transaction,SRT)
into the blockchain.
While intending to share resource,the ownersendsthe
encrypted objectand its attribute information to a DDS,and
then the DDS submits the object’s information (encapsulated
into objectescrow transaction,OET) into the blockchain.
By means of this approach,the DDS implements the object
escrow and the ownership claiming.
We next turn our attention to the process of access request.
After a subjectapplies for access to an encrypted object,the
PEP of ASU interprets and transfers this request (called access
requesttransaction,ART) to the PDP and allblockchain
nodes, and then waits for the decision result. The workflow of
policy decision-making is described as follows.
1) Generating Policy: upon receiving the request, the PDP
inquires of PDS about its access policy. In response, the
PDS produces the policy relevantto the requestfrom
196

policy repository,and then generates and sends itand
the corresponding cryptographic policy to the PDP.
2) AcquaintingTokens:upon receiving theresponsive
policy,the PDP selectsthe necessary attributesthat
satisfy thepolicy,and then queriestheseattributes’
tokensto the relevantAGUs. In response,the AGU
generates and returns the attribute Tokens if the queried
attributes are valid at the current time.
3) Making Decision:the PDP makes the access control
decision based on the received cryptographic policy and
the attribute Tokens.If the decision resultis True,the
PDP confirms this resultto blockchain by sending its
ART signature to allnodes.It finally sends the Token
(called Authorized Token) of decision result to the PEP.
4) Decrypting Object: for an authorized decision, the PEP
firstly requests the DDS to pass the targetobjectback.
The DDS returnsthe encrypted objectand appends
its signature into the corresponding ART Transaction.
The PEP nextusesthe authorized Token to decrypt
the returned object,and then confirmsthis accessto
blockchain by sending its ART signature to all nodes.
5) Confirming Transaction:when allblockchain nodes
receive the confirmation signature from the PEP,the
blockchain platform starts the consensus protocol to con-
firm thatthe ART transaction is complete,and records
the complete ART (called access granted transaction,
AGT) into the blockchain.Finally,the PEP fulfills the
operation requested by the subject.
The only thing thatis necessary for the subjectis to authen-
ticate his identity before entering the platform.Moreover,it
is unnecessary for subject to retain any key corresponding to
resource decryption.This means there is no need for the user
to perform any cryptographic operation in addition to applying
for an access request.
In the TBAC platform,an attribute Token is a one-time
security proof for the authorized attribute issued by the AGU.
We consider the Token as a public verifiable “ticket” to prove
that the attribute is what they claim to be.This ticket usually
contains the information of the issuer, attributes, issue time, as
well as a tag,where the tag is a simple signature that verifies
the authenticity of allother information by using the issuer’s
public key.
C. Access Rules and Policies in ABAC
In TBAC, we constructthe PDS by using XACML that
defines a policy specification language and reference architec-
ture for ABAC implementation.Let S = {s, o, a, e} denote a
set that consists of subject,resource,action,and environment
attribute. Here, attribute instances are specified as name-value
pairs,where attribute name denotes the property orcharac-
teristic associated with certain attribute in S.For example,
in a medicalsetting,Role(s) = doctor denotes the attribute
name Role associated with a subjects is doctor,similarly,
W ard(o) = pediatrics, ResourceID(o) = medical −
records,T ime(e) = 12 : 11,and so on.
In TBAC, an access policy is composed of a target and a set
of rules.A targetdefines a simple Boolean condition that,if
satisfied by the attributes,establishes the need for subsequent
evaluation by a PDP. We use the form of “attribute category :
attribute name :attribute value” to express attribute instance,
where symbol‘:’ is used as separator.For example,“subject
: role : doctor” denotes Role(s)= doctor. Considering a
targetmay contain multiple attribute instance,we provides
a way of reconciling these individualdecisions,called ”one-
and-only”,to restrictthateach attributemustsatisfy one
condition.The targetof this example appliesto ”All read
or write accesses to medicalrecords by a doctor or intern”,
thatis, target(s, o, a):= role(s) ∈ {doctor, intern} ∧
resouceID(o) = mdecial− records ∧ actionID(a) ∈
{read, write}.
In additionto a target,a rule includesa seriesof
Boolean conditionsthatif evaluated Truehavean effec-
t of either“Permit” or“Deny”.The conditionsof a rule
are typically more complex and may include functionsin-
volving logicaloperators(e.g.,and,or) and relation oper-
ations(e.g.,≤, ≥, =)for the comparison ofattribute val-
ues. For example,the first rule denotesthat any access
requestwill be deniedif the ward assignedby subject
is not the sameward wherethe patientis located,i.e.,
rule1(s, o) := W ardAssignment(s) = W ardLocation(o).
Similarly,the second rule denotes rule2(s, a) := role(s) =
intern ∧ actionID(a) = write, and thethird rulealso
is rule3(s, o):= role(s) = doctor ∧ patientstatus(o)=
critical. Finally,we discuss the severalstandard combining
methodsthatcombine multiple rulesinto a single policy,
including the following:
• Permit-overrides: if any decision evaluates to Permit, then
the result is Permit,otherwise the result is Deny.
• Deny-overrides: if any decision evaluates to Deny,or no
decision evaluates to Permit, then the result is deny. If all
decisions evaluate to Permit,the result is Permit.
In this example, we apply for the permit-overrides to integrate
rule1,rule2 and rule3 together,that is,
policy(s, o, a, e):= target(s, o, a) ∧ (¬(rule1(s, o) ∨
rule2(s, a)) ∨ rule3(s, o))
denotes the access is denied if only the conditions stated in
rule1 orrule2 apply exceptfor the access undera critical
situation.
IV. TBAC T RANSACTIONS
The TBAC platform employstransactionsto ensure that
only transactionsconforming to therequisitepoliciesare
authorized and registered into the blockchain.Basically,a
transaction is a data structure that encodes a transfer of access
requestand authorization process among participants in the
platform.Everything in the blockchain is designed to ensure
thattransactions can be created,propagated on the network,
validated,and finally added to the blockchain (as the global
ledger). In the proposed TBAC platform, there exists four main
197

transactions to enforce fine-grained access policies. These four
transactions are described as blow.
A. Subject Registration Transaction
The SRT is used to record the information of one or more
subjects,and mustbe signed and issued by the AGU who
manages the subject’s attribute information.In Algorithm 1
we show a high-levelexample of how a SRT transaction is
constructed.The public keys ofsubjects are converted into
Pay-to-Public-Key scriptPubKey scripts(explained below),
while the outputscripts are accompanied by signature of the
corresponding AGU’s private key.
Algorithm 1 Procedure for creating SRT.
Input: Subject information; Subject attributes; Authentication
information; AGU information;
Output: Subject registration transaction;
1: /*List all subjectsand theirinformation,attributesand
authentication information*/
2: for all subject S do
3: public-attr ← get S’s attributes information;
4: pub,priv ← get S’s keypair;
5: addr ← get pub’s hash;
6: scriptPK ← (OP PUSHDATA(33),pub,OP CHECK-
SIG);
7: Add (addr,tx index,public-attr,scriptPK)to list of
subject;
8: end for;
9: /*Specify AGU’s information*/
10: AGU ← AGU’s network address;
11: pub,priv ← get AGU’s key pair;
12: sig ← signpriv (All except scriptSig in SRT);
13: scriptSig ← (OP PUSHDATA(72),sig);
14: Transaction ← (version,AGU, subject,time,tx index,
scriptSig);
15: return Transaction;
An instance of the executing resultof Algorithm 1,where
the SRT contains fourtypes ofinformation:1) subjectin-
formation,e.g.,subject’swalletaddress(called addr)and
this transaction’s index and sequence number(expressed as
tx index#sequence); 2) subject attributes,e.g.,the list of pub-
lic attributes (public-attribute);3) authentication information,
e.g.,the scriptof public key (scriptPubKey);and 4)AGU
information,e.g.,AGU’s network address(AGU) and the
script of its signature (scriptSig).
Similarto Bitcoin,the walletis used to store the user’s
public/private key pair.When the user is registered into the
platform,the walletsoftware is installed and a public/private
key pairwith an elliptic curve digitalsignature algorithm
(ECDSA) is generated.The public key is then hashed and
this hash value serves as the walletaddress (“addr”) thatis
transfered from/to in TBAC.
The above-mentioned scripts are sequences of instructions
called opcodes that get executed by all entities in our platform.
In particular,our TBAC platform makesuse of Bitcoin’s
scripting language,thatis stack-based and withoutloops.
Moreover,TBAC employs five kinds of scripts.We here give
all the types as follows:
• Type I: pay-to-public-key contains two components:
scriptPubKey: <pubKey>,OP CHECKSIG
scriptSig: <sig>
• Type II: pay-to-public-key-hash contains two compo-
nents:
scriptPubKey: OPDUP,OP HASH160,<pubKeyHash>,
OP EQUALVERIFY, OP CHECKSIG
scriptSig: <sig>,<pubkey>
• Type III: pay-to-script-hash contains two components:
scriptPubKey: OPHASH160,<scriptHash>,OP EQUAL
scriptSig: <sig>,<script>
• Type IV: multiple signature contains two components:
scriptPubKey: M,<pubKey A>,<pubKey B>,
<pubKey C>,N, OP CHECKMULTISIG
scriptSig: OP 0,<sig B>,<sig C>
• Type V: OP Return contains two components:
scriptPubKey: OPRETURN, <data>
scriptSig: NULL
For example,the subject’s scripttakes the structure of Type
I to store the user’s public-key into “scriptPubKey”,in which
OP PUSHDATA(33) is to push the subsequent 33-byte public
key into the stack, and “OP CHECKSIG” expects two values
on the stack to be verified.Similarly,the AGU’s script
“scriptSig” takes the structure of Type I to push the 72-byte
AGU’s signature into the stack by using OP PUSHDATA(72).
The execution process of scripts refers to [8].
B. Object Escrow Transaction
The OET, as escrow credential and ownership claim, is used
to record various information of protected objects.Algorithm
2 describes the procedure of an OET transaction,where the
OET requires the signatures from both the owner and the DDS
who is the actualobject’s depository.Thanks to openness of
blockchain,the OETs are publicly accessible to allmembers
in the whole platform,so thatany membercan retrieve the
required objects conveniently.
The structure ofOET produced by Algorithm 2 can be
divided into two parts:one is the owner’sprofile and the
other is the escrowed objects’ profile.This kind of structure
describes the “one-to-many” relationships between the owner
and the escrowed objects.
The owner’s profile contains two types of information:1)
the owner’sinformation,i.e., the owner’sSRT index and
sequence number(ownertx index),which is used to find
owner’sinformation stored in the corresponding SRT;and
2) ownership claim,i.e.,the scriptof the owner’s signature
(scriptSig). As mentioned above, the script of TBAC currently
utilizes two differentscriptSig/scriptPubKey pairs which can
be cryptographically linked together to enforce the agreement.
This kind of agreementcan be assessed by using the public-
key (scriptPubKey) to verify its holder’s signature (scriptSig).
198

The scriptscriptSig storesthe owner’sECDSA signature
overthe transaction itself.This signature,verified by the
scriptPubKey in SRT related to owner tx index,proves that
the objects in this transaction were possessed by the subject
in the SRT.
Algorithm 2 Procedure for creating OET.
Input: Profile of owner; Profile of escrowed objects;
Output: Object escrow transaction;
1: /*Specify owner*/
2: ownertx index ← the owner’s SRT index#sequence
3: for all escrowed object O do
4: name ← get O’s identity;
5: attribute ← get O’s attributes;
6: DDS ← get DDS’s URL address;
7: pub,priv ← get DDS’s keypair;
8: sig ← signpriv (O’s information and attributes);
9: scriptSig ← OP PUSHDATA(72) sig;
10: Add (name, DDS, tx index, attribute, scriptSig) to list
of escrow;
11: end for;
12: pub,priv ← get owner’s key pair by owner’s SRT;
13: sig ← signpriv (All except scriptSig in OET);
14: scriptSig ← (OP PUSHDATA(72),sig);
15: Transaction ← (version,ownertx index,escrow,time,
tx index,scriptSig);
16: return Transaction;
The profileof escrowed objectconsistsof threeparts:
1) objectinformation,e.g.,the object’sname (name),the
DDS’s address (expressed by URL),and its transaction index
(tx index);2) objectattributes,e.g.,the list of attributes
(attribute); and 3) escrow credential, i.e., the DDS’s signature
(scriptSig).This signature,authenticated by the PKIpublic-
key certificate obtained from the URL ofDDS1, proves the
object was escrowed by the owner of the certificate.
C. Access Request Transaction
The ART is a credible ticketto take note aboutobject’s
access procedure in the form of transaction logs.It contains
all necessary information of access request generated by PEP,
and these information will be used by the subsequent decision-
making forthe access request.As shown in Fig.4, we de-
scribes the procedure of an ART transaction. Considering that
the ART contains severalunauthorized signatures (expressed
by empty),it is not allowed to append into the blockchain
as a valid accesspermission.In ABAC, accessrequestis
generally used to specify whatsubjectwants to have access
to whatobjectwith whatkinds ofactions.For this reason,
the ART oughtto contain three segments(subject,object,
action) of an access request.As shown in Fig.4, the subject
segment consists of the subject’s SRT index (txindex) and the
subject’s signature (scriptSig),which can be verified by the
1Several entities, including DDS, PDP, PEP and AGU, utilize PKI certificate
to issue their public keys.The SRT may be another option for issuing their
public key.
scriptPubKey in the indexed SRT. In the same way, the object
segment consists of the object’s OET index (tx index) and an
empty DDS’s signature (DDS Sig),which will be verified by
the PKI certificate issued by the DDS.The action segment is
the list of all authorized operations, each of which is expressed
as “company.technology#action”.
{
"ver": "ART",
"PEP": pep-server.healthgrades.com,
"PDP": pdp-server.beaumont.org,
"subject":{
"tx_index": 322810234#0,
"scriptSig": "OP_PUSHDATA(22) 00141b0f7c787311455b
3c2272d3869d76176db3d9fe",
},
"object":{
"tx_index": 322786399#0,
"DDS_Sig": "OP_PUSHDATA(72) 2044022049bde80a68
3a220a1a2754dd...b2b63cce11",
},
"action":[
"org.apache.pdfbox.pdfctrl#read",
"com.sun.java.drawgraph#append"
]
"time": 1515658108,
"declaretimeouts": 10m,
"tx_index": 323175628,
"PDP_Sig": "OP_PUSHDATA(72) 30141b0f7c787311455b
3c2272d3869d76...176db3d9fe",
"PEP_Sig": "OP_PUSHDATA(72) 304502210d12a190c59f2a1
d58f3205060...d8f81601"
"hash":"ef4e4e679ea137def17821ba98129...6be9ac8d2"
}
Fig. 4. Example of access request transaction.
In addition,the ART contains the information thatis used
to provide dynamic authentication from relevantauthorized
entities in TBAC platform.These authentication information
consists of the PEP/PDP address (expressed by URL) and their
signatures (PEPSig and PDP Sig),as well as access request
time and period of validity. As mentioned in Section III-B, the
initialsignatures of DDS,PEP,and PDP are empty,butthey
will be signed according to the order of PDP,DDS and PEP
for a valid request.
D. Access Granted Transaction
The AGT is the final form of ART after all empty signatures
are fulfilled,and then itwill be stored into blockchain as
an accesslog once allof signaturesare validated by the
block generator.For the sake ofclarity,we nextdescribe
the authentication relationship between the above-mentioned
transactions(including SRT,OET and AGT) and different
entities (PDP,PEP, DDS, AGU, etc.) from an AGT-centered
viewpoint.
The AGT is submitted to the blockchain untilthe four
signatures in AGT are checked.Among subject’s scriptSig,
DDS Sig, PEP Sig and PEP Sig, only the scriptSig is written
in scripting language. So that, the signature of subject is veri-
fied by performing function executeScript which sequentially
executes the scriptSig and scriptPubKey written in scripting
language, and then the sigVerify function is called respectively
to verify the signature ofthe DDS,the PDP,and the PEP
through using public-key certificates issued by the CA.
199

V. SYSTEM ANALYSIS
A complete authentication system can be generated from
complex authorization or permission relationship among trans-
actions and platform’s entities.Algorithm 3 is used to imple-
ment this procedure of AGT verification.
Algorithm 3 Procedure to verify AGT
Input: Access granted transaction;
Output: valid or invalid;
1: /*Verify each signature in the transaction*/
2: scriptPubKey ← extract from SRT according to subject’s
tx index;
3: if executeScript(scriptSig,scriptPubKey)==false then
4: return invalid;
5: end if
6: DDS Pub ← get DDS’s public key from CA;
7: if sigVerify(DDS Pub,DDS Sig)==false then
8: return invalid;
9: end if
10: PDP Pub ← get PDP’s public key from CA;
11: if sigVerify(PDP Pub,DDS Sig)==false then
12: return invalid;
13: end if
14: PEP Pub ← get PEP’s public key from CA;
15: if sigVerify(PEP Pub,DDS Sig)==false then
16: return invalid;
17: end if
18: return valid;
For an access request,the subjectsegment of AGT is used
to pointto a requester’s SRT thatcontains the public key of
the requester.Such that,the requester’s signature in the AGT
can be verified by using this public key.For the accessed
object, the object segment in the AGT points to the OET which
contains the address of the corresponding DDS. The public key
certificate of DDS can be obtained according to this address.
Therefore, any one can use the DDS signatures, stored in both
the object in AGT and the eacrow in OET, to validate the DDS
authorization. The owner segment in OET can also help us to
find out the SRT of object’s owner through the txindex,and
the owner claims ownership of the object using the signature
signed by his private key.Finally,the PDPSig and PEP Sig
in AGT are considered as access permissions issued by the
PDP and the PEP. In addition, the AGU in SRT stores its own
address which is convenient for acquire the subject’s attributes.
According to the above description,our TBAC platform
implements these functions as follows:
• Access Openness: the platform supports data sharing and
exchanging with unlimited number of users in the public
network environment.
• Authorized Trusteeship: after signing the object escrow
transaction,the ownersdo not need to participate in
subsequent access authorization.
• Rule Generality: the rules in TBAC can support the gen-
eral security restrictions(such asread-up/write-down),
and they can change as required.
• Policy Dynamics:for the currentrequest,the policy is
produced dynamically from the security rules according
to the current state of the request.
• Access Traceability: the process of digital asset sharing
and exchanging is traceable via transactions,and their
access authorizations are cryptographically verifiable.
VI. CONCLUSIONS
In this paperwe take transaction as a bridge to integrate
ABAC and blockchain into a new platform for resource dis-
tribution and sharing. Our proposed platform supports flexible
and diverse permission management, as well as verifiable and
transparent access authorization process. We hope our researc
could provide useful reference for globe resource sharing.
ACKNOWLEDGMENT
The work is supported by Beijing MunicipalCommission
of Economy and Information Technology (The project entitled
“Research on network security of big data in E-government”),
the National Natural Science Foundation of China (Grant No.
61472032),NSFC-Genertec JointFund ForBasic Research
(GrantNo. U1636104),Joint Research Fund forOverseas
Chinese Scholarsand Scholarsin Hong Kong and Macao
(GrantNo. 61628201)and NationalKey R&D Program of
China (Grant No.2017YFB0802503).
REFERENCES
[1] I.-C. Lin and T.-C. Liao, “A survey of blockchain security issues
and challenges.” IJ Network Security, vol. 19, no. 5, pp. 653–659,
2017.
[2] A. Ouaddah,A. Abou Elkalam,and A.Ait Ouahman,“Fairac-
cess:a new blockchain-based access controlframework for the
internet of things,” Security and Communication Networks, vol. 9,
no.18,pp.5943–5964,2016.
[3] L. Xu, L. Chen,N. Shah,Z. Gao,Y. Lu, and W.Shi, “Dl-bac:
Distributed ledger based access control for web applications,” in
Proceedings of the 26th International Conference on World Wide
Web Companion.InternationalWorld Wide Web Conferences
Steering Committee,2017,pp.1445–1450.
[4] A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, “Medrec: Us-
ing blockchain for medical data access and permission manage-
ment,” in Open and Big Data (OBD),InternationalConference
on. IEEE, 2016,pp.25–30.
[5] Q. Xia, E. B. Sifah, A. Smahi, S. Amofa, and X. Zhang, “Bbds:
Blockchain-based data sharing for electronic medical records in
cloud environments,” Information,vol. 8, no.2, p. 44,2017.
[6] V. Hu, D. Ferraiolo, D. Kuhn, A. Schnitzer, K. Sandlin, R. Miller,
and K. Scarfone, “Guide to attribute based access control (abac)
definition and considerations,” pp.162–800,01 2014.
[7] R. Nasim and S.Buchegger,“Xacml-based access controlfor
decentralized online social networks,” in Proceedings of the 2014
IEEE/ACM 7th InternationalConference on Utility and Cloud
Computing.IEEE Computer Society,2014,pp.671–676.
[8] I. Giechaskiel,C. Cremers,and K.B. Rasmussen,“On bitcoin
security in thepresenceof broken crypto primitives.”IACR
Cryptology ePrint Archive,vol.2016,p. 167,2016.
200