Tokoin: A Coin-Based Accountable Access Control Scheme for Internet of Things
Chunchi Liu, Minghui Xu, Hechuan Guo, Xiuzhen Cheng, Yinhao Xiao, Dongxiao Yu, Bei Gong, Arkady Yerukhimovich, Shengling Wang, Weifeng Lv
JJOURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 1
Tokoin: A Coin-Based Accountable AccessControl Scheme for Internet of Things
Chunchi Liu, Minghui Xu, Hechuan Guo, Xiuzhen Cheng,
Fellow, IEEE,
Yinhao Xiao, Dongxiao Yu,Bei Gong, Arkady Yerukhimovich, Shengling Wang, and Weifeng Lv
Abstract —With the prevalence of Internet of Things (IoT) applications, IoT devices interact closely with our surrounding environments,bringing us unparalleled smartness and convenience. However, the development of secure IoT solutions is getting a long way laggedbehind, making us exposed to common unauthorized accesses that may bring malicious attacks and unprecedented danger to our dailylife.
Overprivilege attack , a widely reported phenomenon in IoT that accesses unauthorized or excessive resources, is notoriouslyhard to prevent, trace and mitigate. To tackle this challenge, we propose Tokoin-Based Access Control (TBAC), an accountable accesscontrol model enabled by blockchain and Trusted Execution Environment (TEE) technologies, to offer fine-graininess, strongauditability, and access procedure control for IoT. TBAC materializes the virtual access power into a definite-amount and securecryptographic coin termed “tokoin” (token+coin), and manages it using atomic and accountable state-transition functions in ablockchain. A tokoin can be created only by the resource owner, and is programmed with a fine-grained access policy defining “ who isallowed to do what at when in where by how ”. Such a policy specifies the access requirements (the ) to be satisfied for grantingthe access, and access behavioral constraints (the ) that must be strictly followed during the resource access. To the best of ourknowledge, we are the first to realize such an access procedure control that governs actual access operations throughout the wholeaccess process. The strong-auditability is achieved with blockchain and a TEE-enabled trusted access control object such that trustcan be extended from on-chain to off-chain making all access activities securely monitored and auditable. The tokoin is peer-to-peertransferable, and can be modified only by the resource owner when necessary, realizing a dynamic and flexible access control that canaccommodate the ever-changing physical world, without relaxing any security requirement. We fully implement TBAC with well-studiedcryptographic primitives and blockchain platforms and present a readily available APP for regular users. We also present a case studyto demonstrate how TBAC is employed to enable autonomous in-home cargo delivery while guaranteeing the access policycompliance and home owner’s physical security by regulating the physical behaviors of the deliveryman. Index Terms —Access Control; Access Procedure Control; Fine-Graininess; Strong Auditability; Overprivilege Attack; Blockchain; IoT;Trusted Execution Environment. (cid:70)
NTRODUCTION W ITH the rapid development of the Internet of Things(IoT), IoT devices have become much smaller,smarter, and powerful than ever before. Iconic productssuch as Google Home, Amazon Alexa, and Samsung Smart-Things have brought great convenience to human life. Ac-cording to [1], household penetration of smart home willreach 36.6% by the end of 2020 and is expected to hit57.2% by 2025. Unfortunately, it has been widely reportedby many researchers [2] [3] and major public media [4] [5][6] that a variety of mainstream IoT devices, including the • C. Liu, M. Xu (corresponding author), X. Cheng, and A. Yerukhimovichare with Computer Science Department, The George WashingtonUniversity. E-mail: { liuchunchi, mhxu, cheng, arkady } @gwu.edu • H. Guo and D. Yu are with School of Computer Science and Technology,Shandong University. E-mail: { ghc, dxyu } @sdu.edu.cn • Y. Xiao is with Guangdong University of Finance and Economics. E-mail:[email protected] • B. Gong is with Beijing University of Technology. E-mail:tekkman [email protected] • S. Wang is with Beijing Normal University. E-mail: [email protected] • W. Lv is with Beihang University. E-mail: [email protected] ones mentioned above, have been secretly accessed withoutauthorization, which greatly undermines the security andprivacy of an ordinary user.Unauthorized access attacks can be ascribed as overpriv-ilege attacks that aim to access unauthorized or excessiveresources in stealth, making it hard to trace what havehappened and who are responsible for the bad. Such attacksare very common in practice and effectively defending themis a grand challenge in IoT security. They are mainly causedby three significant design deficiencies of current IoT accesscontrol schemes: coarse granularity of the access policy, weak auditability towards all access activities, and lack ofaccess procedure control . Coarse granularity refers to a lowexpressiveness of access policy – an inability to preciselydefine the required conditions for granting the access andthe procedure the access must follow. Weak auditability, asthe name implies, is an inability to securely log all accessactivities in detail. Lack of access procedure control refersto the missing of continuously examining the behavioralobedience to the pre-defined access policy during resourceaccess. This is a systematic neglect in current access controlschemes, where the action of resource access is narroweddown to a decision-making process that only relies on theinitial, static access conditions at the moment when the ac-cess is requested, ignoring the access procedure that actuallymanipulates different resources with different access rights a r X i v : . [ c s . CR ] N ov OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 2 at different instant of time. Coarse granularity is the directcause of overprivilege attacks, weak auditability implies theimpotence of holding the attackers accountable, while thelack of access procedure control results in oversights to suchattacks in action. Many IoT access control mechanisms havebeen proposed in recent years, but unfortunately almostall of them suffer from one or more of the deficienciesmentioned above [7].The design objective of our Tokoin-Based Access Con-trol mechanism (TBAC) is to provide fine-grained accesscontrol for IoT applications that can not only verify theconditions for granting the access rights but also regulatethe access procedure ensuring that the access policy isstrictly followed in whole, with all activities logged forauditing purpose. In TBAC, an access power is created,stored, transferred, revoked, and redeemed in the form ofan accountable digital asset, namely a tokoin (token+coin),which is managed securely and auditably as a cryptographiccoin with the assistance of blockchain and Trusted ExecutionEnvironment (TEE) technologies. Any user can issue tokoinsrepresenting access powers to its own resources, and anyaccess activity must be granted by redeeming a tokoin,which relies on a TEE-enabled trusted access control objectto objectively verify the access conditions and monitor thewhole access procedure. A tokoin carries a fine-grainedaccess policy specified by the resource owner to define theaccess conditions to be met and the access procedure tobe followed. We detail TBAC in this paper by making thefollowing contributions.First, by combining token and coins together, we ma-terialize the “virtual” access right into a definite-amount,cryptographically-secure and accountable digital asset thatis a tokoin. A tokoin can only be created and revoked by theresource owner, who also has the exclusive right to defineand dynamically modify the access policy of its resource.By this way the resource owner can take full control ofthe access to its resource down to each access activity andbehavior, without the need of delegating or relying on anyuntrustworthy third party such as a server. Note that atokoin itself is capable of peer-to-peer delegation and re-distribution, permitting increased flexibility.Second, a tokoin carries the so-called access policyspecified by the resource owner, which defines the accessconditions to be met and the access procedure to be fol-lowed. The stands for who is allowed to do what at when in where by how , where the present the accessconditions that must be satisfied in order for an accessrequest to be granted, and the describes the accessprocedure that must be strictly followed. This policymodel provides fine-grained access control as it can not onlyprecisely describe the access conditions but also capture thecontextual relationships among all access constraints andactions via operators such as Boolean logic. To the bestof our knowledge, we are the first to consider the accessprocedure control in order to guarantee access compliancethroughout the whole process of access activities.Third, TBAC makes use of transferable tokoins to repre-sent access powers. This permits high user flexibility whilepreserving strong security by first adopting a blockchain forsecure tokoin storage and atomic tokoin transfer and thenemploying a TEE-enabled trusted access control object to verify whether or not the access conditions and procedurefollow the predefined fine-grained access policy. Nomatter who possesses the tokoin, only the desired subjectunder the user-defined access conditions can redeem access.In summary, TBAC achieves fine-graininess, strong account-ability, and access procedure control by adopting tokoinsthat define the access policy, and the blockchainand TEE technologies to securely log all on-chain/off-chainactivities. TBAC is secure against various attacks such astokoin forgery, theft, and access policy violation.Fourth, a complete and effective access control schemeshould implement the three processes of Authentication,Authorization and Auditing to ensure that an authenticsubject is authorized to access the right amount of resource,no more no less, under verifiable conditions following afully accountable procedure. We detail all the tokoin func-tion implementations to demonstrate how these three pro-cesses are realized and fully protected in TBAC. We alsoprovide Go-Tokoin and Ethereum-Tokoin, the two proto-types of the TBAC scheme, with the former following thenative design (Tendermint-BFT) for best performance andthe latter showing the adaptivity of TBAC to mainstreamblockchain platforms (Ethereum). The TEE-enabled accesscontrol object is implemented in ARM Cortex-M33 basedmicrocontroller protected by the ARMv8-M TrustZone, tosecurely sample the physical environment for access con-dition verification and access procedure monitoring. To thebest of our knowledge, we are the first to develop on theCortex-M series TEE microcontrollers, which are specificallydesigned for low-cost trustworthy embedded systems bysupporting hardware-level program security isolation. Asthe Cortex-M series TEE microcontrollers offer very littleusable libraries, we build our access control object roughlyfrom the bare metal level, thus facing a great engineeringchallenge. A friendly TBAC Android App is also developedfor convenience and better user experience. All codes areopen-sourced and available at Github.Lastly, we present a TBAC-assisted in-home cargo deliv-ery case study to demonstrate how TBAC is utilized for realworld applications. This case study permits autonomousin-home delivery, in which a deliveryman can open thesmart door and put the cargo down on its own in thedesignated area (e.g., mud area), and the access procedurecontrol guarantees that the deliveryman’s actual behaviordoes not violate the access policy (e.g., not entering themain room) and ultimately the home owner’s physical secu-rity. More importantly, this case study provides a seamlessintegration of blockchain and IoT to extend the on-chaintrustworthiness to off-chain physical world. This piece ofwork itself has its own significance in many IoT applicationsthat require trusted management. Our case study also showsthat secure and accountable accesses to physical resourcescan be achieved by techniques that are used to be onlyavailable in the digital world.The paper is organized as follows. We first present themost related work and analyze the existing challenges inSection 2. Then we propose our tokoin based access controlmodel TBAC in Section 3 and detail its implementation inSection 4. The TBAC-assisted in-home cargo delivery casestudy is presented in Section 5. We conclude this paper witha future research discussion in Section 6. OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 3
ACKGROUND AND R ELATED W ORK
In this section, we first introduce two major categories ofexisting access control schemes, namely Access Control Ma-trix (ACM) and Capability-based Access Control (CapBAC);then we discuss their design deficiencies, analyze howthese deficiencies jointly cause the overprivilege challengeand how the actual Industrial implementations worsen thecorresponding problem; finally we present the current coun-termeasures to tackle the challenge.
There exist many access control schemes such as Role-basedAccess Control (RBAC), Attribute-based Access Control(ABAC), Access Control Matrix (ACM), Access Control Lists(ACL), and Capability-based Access Control (CapBAC).Most of them can be classified into two categories, namelyAccess Control Matrix (ACM) and Capability-based AccessControl (CapBAC) [8] [9].
An ACM refers to a table that lists precise security entriesrecording which user or group has which privileges overwhat resources. These security entries are also called secu-rity references. A reference server stores these referencesand upon access request, it looks up the references andjudges whether the access requester passes the referencecheck or not. Typical examples of ACM include the AccessControl List (ACL) from the Unix file system, which defineswhether or not a specific user has Read/Write/Executeprivileges over a file, and the Role-based Access Control(RBAC), which extends the minimum subject unit from anindividual to a user group. RBAC is proved to be equivalentto ACM with respect to the policies they can represent [10].Attribute-based Access Control (ABAC) is an improvementover RBAC that requires more contextual attributes fromthe access subject, and combines them with boolean logic toachieve a finer granularity of access control [11]. As ABACexplicitly stores policy scripts in an access matrix [12] [13],we classify it to the ACM category.
CapBAC makes use of a certificate-like capability (token) torepresent the access privilege and realize direct peer-to-peeraccess control. After authentication, the access server issuesa token, possessing which gives right to access certain re-sources within a certain period of time. This is more widelyused in Industry, and the most popular CapBAC schemesinclude OAuth, OAuth2, and JSON Web Token (JWT). Therealso exist mechanisms that decentralize CapBAC, whichare mainly based on the simple marriage of blockchaintechnologies and CapBAC schemes [14].
Both ACM and CapBAC have pros and cons. ACM is fea-tured by precise definitions of simple access privileges suchas read or write, and is easy to implement for a small scalesystem. However, as the number of users and the granu-larity of access conditions increase, higher-dimensional data is needed, making ACM excessively larger and sparser. Tokeep ACM practically small, the operations and the policygranularity must be limited. Obviously, this makes it hard torelease a precise amount of resource, hence causing the riseof the coarse granularity problem where the access targetand method are defined vaguely. This coarse granularity isattributed to ACM’s user-centric nature, and its inabilityto depict complex contextual relationships. An exemplaryattempt to overcome the coarse granularity challenge isABAC, as it adds more attributes and permits contextualrelationships among the attributes through boolean logiccombinations. Note that ABAC is close to a satisfactorysolution against coarse granularity, but it suffers from highcomplexity and verbosity, making it increasingly dim forfuture worldwide adoptions [15] [16]. CapBAC provides anunforgeable certificate-like capability (token) to prove anentitled access power, but it also puts up with the coarsegranularity problem. This is because the creation of accesstokens does not mandate a fine-grained access policy. Forthis reason an OAuth token issued to access one photo ina smartphone can be maliciously (and easily) exploited toaccess all photos in the smartphone [17].
The weak auditability problem refers to an inability to mon-itor all access control activities, including authorization, au-thentication, redemption, etc. In ACM, most access auditinglogs are recorded on the victim device, thus an attacker canuse the excessive control power obtained from unauthorizedattacks to easily (and in fact, commonly, found by Cozzi etal. [18]) delete the logged evidence without being caught.To make things even worse, a large portion of devicesand platforms such as Nest and Samsung SmartThings inpractice, even do not log access activities [19].CapBAC is also vulnerable to the weak auditabilityproblem. In most mainstream projects and standards, oncean access capability is issued, no constraint is placed toprotect the use of such capability – the access privilegeis technically unlimited. We take the most popular andwidely used CapBAC protocol OAuth 2.0 as an example :after initial authorization, the OAuth protocol creates anon-cryptographic token and transfers it through SSL/TLSto the subject, requiring the subject to be responsible forkeeping the token confidential. Nevertheless, in all CapBACschemes, whoever possesses the token is assumed to be thelegit access subject, and can access the resource withoutfurther authentication and auditing. As a result, it is easy toimpersonate or steal a token to perform unlimited amountof unauthorized accesses without being detected [21] [3]. The lack of access procedure control is a systematic neglectin both ACM and CapBAC. This problem is caused by thecurrent access decision-making process that requires onlyan instantaneous check on access conditions at the momentwhen the access is requested. After a decision is made,the task of access control is accomplished, leaving a lot ofroom for the actual access behaviors to completely go wild.Therefore it is not surprising to observe that most, if not
1. OAuth 1.0 is proved to be insecure and deprecated [20]
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 4 all, overprivilege attacks are explicitly discoverable duringthe access process. The lack of access procedure control maynot seem to be a big problem in classic computer systems inwhich an access control scheme mainly plays the role of adoor lock safeguarding the jewels inside a cabinet, assumingthat a subject is the legal owner of all jewels inside thecabinet as long as the subject provides the right code toopen the lock. But for IoT applications that are deployed inopen and distributed environments in recent years, wherean access event typically involves a procedure of manip-ulating different resources with different access rights atdifferent instant of time, access condition verification aloneis insufficient and an effective access procedure control isobviously needed.
Obviously, when an access control scheme suffers fromcoarse granularity, it is easy to release more resource thanone needs. This directly gives rise to the so-called overpriv-ilege challenge, which can be further worsened by the weakauditability problem, where an access scheme fails to auditall activities, and the lack of access procedure control, whichgives unlimited opportunities for the attacker to manipulate.Overprivilege has been a popular open research topic for along time [22] [23] [24], yet there still lack effective solutions.With the fast and prevalent penetration of IoT appli-cations in our daily life, the overprivilege challenge be-comes increasingly grave and intolerable, especially whenconsidering the situations where relevant cyber threats areextended onto our real-life security. Imagine how threaten-ing it can be in a world where Alexa’s red light goes on tosecretly record our daily conversations and the smart doorlock is opened up by an adversary behind the scenes. Felt etal. found that overprivilege vulnerabilities exist in over one-third of the Android-driven IoT devices [25], and Fernandes et al. reported that in Samsung SmartThings platform over55% of SmartApps are overprivileged due to coarse accesscontrol granularity [3]. Zhang et al. discovered that attackerscan create malicious apps on the Amazon skill platform toperform overprivilege attacks and conduct eavesdroppingactivities through Alexa [26]. Such attacks have occurredrepeatedly on many off-the-shelf products such as AmazonAlexa and Google Home all over the United States, and havebeen reported by many mainstream public media [5] [4] [6].In summary, due to the lack of an accountable andfine-grained access control scheme that can also monitorthe access procedure, an adversary can easily over-accessthe designated resources, or even perform unauthorizedaccesses. One can see that overprivileged accesses wreakhavoc, thus effective solutions are desperately needed.
In Industry, the common practice of IoT access control iseither open-port direct control or server-assisted remote con-trol . These two common implementations largely ignorethe three requirements of fine-graininess, strong auditibility,and access procedure control. As shown in Fig. 1a, the open-port direct control requiresIoT devices and their drivers’ network ports open at all a. Open-port Direct Control b. Server-assisted Access ControlIoT Device (Potentially Malicious) Access Server
IoT DeviceUser User (Network Penetrating)Remote Attacker
Fig. 1: Two Major Types of Industrial Implementations onIoT Access Controltimes; thus any user can freely connect and control thedevices without authentication. It was originally proposedto decrease authentication latency and implementation com-plexity, and had once become increasingly popular untilthe first IoT botnet Mirai exploited such vulnerability andcompromised more than 65,000 IoT devices within the first20 hours after its initial release in August 2016, with over600,000 devices infected at peak [27]. Note that Mirai simplyflooded SYN messages on TCP port 23 (telnet) and achievedsuch results. Even now more than 62% of IoT devicestested were still found vulnerable to remote access attacksexploiting open ports and weak credentials [28]. It is clearthat this open-port direct control implementation is near-defenseless, not to mention the close-to-none auditability,fine-granularity, and access procedure control. Thereforemany mainstream manufacturers switched to the server-assisted remote control in recent years.
As shown in Fig. 1b. IoT devices are connected to theiraccess servers that are run by their manufacturers/serviceproviders. If a user wants to access and operate its device,a request needs to be sent to the access server. Then theserver authenticates the user’s identity with typically ausername-password pair, and performs controls towards theIoT device on behalf of the user. From a technical perspective,the access control decision is made by the server, not theuser, and the actual operating commands can only be issuedfrom the access server.It may sound weird that the owner of a device does nothave actual access power over the device, but it’s true. Mostoff-the-shelf IoT devices such as Samsung SmartThings,Apple Homekit or Amazon Alexa, use a close-source plat-form to support very limited programming towards thedevices, thus greatly limits the access policy granularity[3]. On the other hand, with the access server having thetechnically highest control privilege, the service providerscan only make legal-level promises against unauthorizedaccesses [29]. If the access server itself is compromised byan adversary who then commits an unauthorized accessactivity, it can erase the log evidence with root privileges[18]; therefore auditability is very vulnerable in server-assisted access control. Additionally, as in open-port di-rect control, access procedure control cannot be realized inserver-assisted remote control.
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 5
Most countermeasures that attempt to mitigate the overpriv-ilege challenge are based on security analysis, in which theoverprivilege vulnerabilities are inspected as programmingdeficiencies and identified based on the learned charac-teristics. Fernandes et al. uncovered a severe overprivilegevulnerability in the Samsung SmartThings platform, whichallows attackers to falsely turn on a fire alarm [3], butthey did not propose any effective defense mechanism. Jia et al. presented a graph-based algorithm to automaticallyexcavate the overprivilege weaknesses in a smart homesystem [30]. Celik et al. hand-crafted 20 common flawedapps, with which a model-checking based solution wasdeveloped to automatically identify the flaws [31]. In sum-mary, all the mechanisms mentioned above mitigate theoverprivilege challenges by first discovering the vulnerabil-ities, then learning features from them, and finally detectingtheir presence in a general environment. Their false-negativerates are usually high, and emerging vulnerabilities (e.g.,zero-day vulnerabilities) are hard to be detected.
Blockchain can provide a trustworthy environment formany applications, ranging from secure transactions [32]to trusted verifiable computing [33]. Apart from the accesscontrol works mentioned above, researchers also resortedto blockchain technologies. However, current blockchain-based access control schemes are mostly the simple mar-riages of blockchain and existing solutions, thus sufferingfrom the same open challenges.For examples, Pinjala et al. proposed a decentralizedframework based on IOTA blockchain to create and man-age the access capability tokens [34]; Zhang et al. devel-oped an ACL-based access control scheme on top of mul-tiple Ethereum smart contracts [35], following the clas-sical coarse-grained Unix style { Read, Write, Execute } →{
Allow, Deny } ; Xu et al. presented BlendCAC, which em-ploys Ethereum smart contracts in replacement of the tradi-tional capability access server to issue and manage coarse-grained Linux-style access capabilities [14]; Maesa et al. implemented a blockchain-based ABAC scheme, where ablockchain is used to record the location of an externallystored ABAC policy [36]. Although the scheme in [36] has abetter policy granularity, they all suffer from other problemsof overprivilege challenge, weak auditability, and lack ofaccess procedure control.The status-quo urges us to ponder the following ques-tion: can we design an accountable and fine-grained accesscontrol scheme that can precisely define the access privi-lege and control the access procedure while enforcing highauditability on all operations towards an access activity?To answer this question, we strive to design a secure,accountable and fine-grained access control scheme that al-lows owners to have cryptographic level security confidenceover the uses of their resources without crossing the ac-cess policy boundaries defined by themselves. We leverageblockchain and cryptographic primitives to instantiate ac-cess capabilities into secure and accountable cryptographicassets, namely tokoins, and design TBAC, a fine-grained and accountable access control model that supports accessprocedure control, to overcome all the challenges analyzedabove and realize the design goals of effective access control. OKOIN -B ASED A CCESS C ONTROL
Tokoin-Based Access Control (TBAC) is a general accesscontrol model that employs cryptographic coins to rep-resent access privileges. Tokoin is termed by combining“token” and “coin”, for the purpose of materializing accesscapabilities as atomic, accountable, and transferable digitalassets. In this section, we present our design goals, securityassumptions, threat model, and an overview on TBAC.
The major objective of TBAC is to provide a flexible andgeneral access control model that can offer fine-grained and fully-accountable control over the access of private digitalor physical resources. TBAC should be flexible enough tosupport simple access control tasks that mainly requireidentity authentication, as well as complex ones that requireexternal environment data inputs. It should be able to pre-cisely define who , what , where , when , and how , the five criticalelements that determine the fine-graininess level of an accesscontrol scheme, to answer the question of who is allowed to dowhat in where at when by how . This is termed as the ac-cess policy, where the four W ’s specify the access conditionsthat must be met in order for an access request to be grantedwhile the H describes the exact access procedure that mustbe strictly followed during access. Only the resource ownerhas the right to define and modify a access policy,and its five elements can be dynamically changed such thatthe owner can flexibly control the access to its resource at itsown will. In TBAC, this access policy is minted intoa tokoin, and within its whole lifetime, all actions towardsthe tokoin are securely logged for auditing purpose.TBAC should comply with the AAA requirements, i.e.,it must clearly and precisely define the Authentication, Au-thorization, and Auditing processes that should be imple-mented by all complete and secure access control schemesfrom the information security perspective [37]. The Authen-tication process is an act of establishing or confirming theidentity or capability as authentic; the Authorization processdetermines whether a person or a process is authorized toperform a given access activity; and the Auditing processlogs all access events that have security significance. To achieve the objectives mentioned above, TBAC makestwo important system requirements to assure security.First, TBAC relies on a database that supports securetokoin storage, atomic tokoin transfer, and accountable ac-tivity auditing. Such properties are very similar to whatblockchain can provide. As a result, blockchain is adoptedin TBAC. More specifically, the existence of a blockchainsystem that is provably secure for trusted storage (fork-free)and state transitions is assumed by TBAC. It is employed tomanage all operations over a tokoin as transactions such
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 6 that the tokoin can be securely stored and all (on-chain)activities over it can be logged for auditing purpose.Second, TBAC requires a reliable access control objectthat works on behalf of the resource owner to verify tokoincapability validity, check if the fine-grained access condi-tions are met, make actual access decisions, and monitorthe access procedure. This requires the access control objectto have secure connections with the blockchain for tokoinreception and with the resource for access control. Consider-ing the AAA requirements, RACO needs to establish a trustenvironment that directly extends that of the blockchain,i.e., extending trust from on-chain to off-chain, such thatone can be sure that the access policy carried by a tokoin isstrictly followed during access and all access-related activi-ties are securely logged. To achieve this objective, we adopta Trusted Execution Environment (TEE), a special kind oftrusted hardware that has a tamper-proof area for secureprograms, to host the access control object and other securesoftware in TBAC for information collection to realize secureand accountable access control.Conceptually, TEE is a tamper-resistant processing en-vironment enabling isolation and secure storage within achipset [38]. Technically speaking, a TEE implements fun-damental functions such as secure boot, runtime isolation,secure storage, secure scheduling, trusted I/O, and trustedremote management. The program executed in TEE resistssoftware attacks as well as physical tampering such that theauthenticity, integrity, and confidentiality of the codes andruntime states are guaranteed. In this paper, we assumethat long-range vulnerabilities do not tamper programswithin the TEE secure zone, and that any local program canbe executed as expected. However, physical damages andattacks towards TEE hardware are out of the scope of thispaper, thus will not be considered.
In this paper, we consider a general but powerful adversary A who knows the details of the TBAC construction proce-dure, has access to all public functions, and can read publicrequests and messages. A may compromise a fraction of theparticipants but this fraction is not large enough to thwartthe normal secure operations of the underlying blockchainsystem. It aims to perform an overprivileged access (anunauthorized access is deemed as a special kind of over-priviledged access) to the private resource. In practice, thisadversary can be a remote attacker that can penetrate thelocal network, or a local attacker, or the hosting access serverof the resource, which are popular in current IoT industry. * Owner SubjectCirculator
Access Control Object ① AuthorizationProcess ② Transfer Process ③ Redeem ProcessModify/Revoke Process (optional) On-chain Operations
Off-chain Operations
Fig. 2: Overview on TBAC
Typically an access control scheme consists of the followingentity roles. An owner owns a piece of private resource D ,which could be a hardware device or a software program.The owner authorizes a subject to access its resource undera series of restrictions including access conditions and anaccess procedure, which together define the access policy .In TBAC we have a more refined definition of the entityroles, denoted by R = { r O , r S , r C , r ACO } , where r O isthe resource owner who issues a tokoin t along with anaccess policy t. policy for its resource D , r C is the circulator,who must be the current holder, of the tokoin t that helpstransfer t to a legit subject r S . An access control object r ACO is the local robust access control module that actuallycontrols the access to D on behalf of r O . Upon subject r S ’s tokoin redemption request, r ACO verifies if the tokoincapability is valid and if the conditions required by theaccess policy are met; and if yes, grants the access to r S andmonitors the access procedure. Note that r C , the circulatorand current holder of t , could be the r O , or a r S , or anyother legitimate participant in TBAC. Also note that r S doesnot have to be one specific participant – it could be a groupof participants possessing certain legitimacies to access theresource D . We further emphasize that the minimum atomicaccess privilege in TBAC is a tokoin capability, which is anactual instantiation of the privilege. Within a tokoin accessactivity, a participant can only have one role. However, itcan participate in multiple activities of different tokoins,thus can have a different role in each respective activity atany instant of time. In TBAC, a participant can be uniquelyidentified by its address or a public key issued by thesystem. TBAC intends to let the resource owner completely controlthe access privileges over its resources. To achieve thisgoal, it manages the access control powers in the formof secure, atomic, accountable and policy-programmablecryptographic coins. This approach is featured by fourproperties: only the resource owner can create, modify, orrevoke a tokoin in order to completely control the access toits resource; the current holder of a tokoin can atomicallytransfer the tokoin but only a legit subject can redeem thetokoin; all conditions required by the access policy mustbe met upon redemption and the exact access proceduredefined by the access policy must be strictly followed forcorrect resource access; all access activities must be auditedin a secure, accountable, and fine-grained way.Fig. 2 illustrates the operations of our TBAC model.When the owner r O of resource D wants to authorize asubject r S to access D , r O drafts an access policy andsecurely creates a tokoin. Then the owner r O transfers thetokoin to the first circulator r C , as demonstrated by theAuthorization Process 1 in Fig. 2.The tokoin circulator r C , if it is not the final subject,accountably transfers the tokoin to another participant whenneeded. This can help the resource owner to deliver theaccess capability to a legit subject, or dynamically delegate adifferent group of subjects to access its resource during the OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 7 tokoin transfer process as the resource owner can modify atokoin before it is redeemed (labeled by a ∗ in Fig. 2). How-ever, although the transfer of a tokoin is allowed betweenany two participants, the final tokoin redemption must beperformed by a legit subject. By this way one can permita great access privilege management flexibility while stillguaranteeing that the final access activity strictly followsthe owner’s discretion. This can motivate new methodsin physical resource management such as allowing secureresource rent, trading of hardware/software resource right-of-use, or assigning someone to run an errand more flexibly.We provide a case study where autonomous secure in-homeparcel deliveries are enabled for the convenience of ordinarypeople. This is the Transfer Process 2 in Fig. 2.Finally, when a legit subject r S possesses the tokoinand wishes to redeem for resources, the redemption processchecks if all conditions defined in the access policy are metto ensure that it is indeed a legit subject to access the rightresource under correct conditions. The redemption processalso needs to monitor the access procedure, if defined bythe access policy, to make sure that the procedure is strictlyfollowed. Such a design can guarantee that despite theflexibility of the access power transfer process, the finalredemption must follow user-defined access rules. Any vi-olation per the access policy renders the access fail. This isthe Redemption Process 3 in Fig. 2.We would like to emphasize that an access policy carriedby a tokoin can be flexibly defined at any graininess levelper the resource owner’s preferences/needs, by inputtingvalues at different granularity to the who , what , where , when ,and how fields. Moreover, the who field in the access policycan specify a group of legit subjects to access the resource asthe resource owner may not be aware of the exact subjectwhen the tokoin is minted. Additionally, the owner canmodify any component of the access policy in a tokoin orsimply revoke the tokoin as long as it is not redeemed,providing strong fine-grained control over its resource ac-cess privileges at any instant of time. On the other hand,one can see that TBAC is applicable to the access controlsover both digital resources as well as physical resources,as the five fields of a access policy do not rely onany resource-specific feature. Nevertheless, as a general fine-grained access control model, TBAC needs to be instantiateddifferently for different applications. We detail the TBACimplementation in the next section and present a case studyto demonstrate its applications in Section 5. To achieve the goal of providing fine-grained accountableaccess control, a tokoin in TBAC must possess the followingproperties:
Security : A tokoin is a materialized entity of a secureand accountable access power, in the form of a cryp-tographic coin. It cannot be falsely created, tamperedwith, used, or revoked by an adversary.
Atomicity : The transfer of a tokoin requires the simultane-ous arrival at the receiver and removal from the sender,making it hard to double-redeem the tokoin.
Strong Auditability : All current or historical activitiesover or changes to a tokoin, as well as all activities during the access to the resource based on the policycarried by a tokoin, are securely audited.
Fine-Grained Access Policy : The access policy carried bya tokoin specifies such that a user can preciselydescribe both the access conditions (the ) to bechecked before granting the access, and the access be-havioral constraints (the ) after granting the access.The fine granularity level is exclusively determined bythe resource owner. Access Procedure Control : A tokoin should carry accessconditions for pre-access compliance verification andaccess restrictions for during-access behavior obediencemonitoring.
Direct Access Privilege Sovereignty : The access privilegeover a piece of resource can only be defined and issuedby the resource owner via a tokoin at its discretionwhen needed, without intervention of any third partyaccess server.
Transferability of Access Power : A tokoin can be trans-ferred peer-to-peer from one holder to another througha properly audited procedure, if needed.
Dynamic Access : The access privilege carried by a tokoincan be modified or revoked at anytime and these ac-tions should be performed only by the tokoin owner.
Definite-amount of Access : Obviously, the number oftimes a tokoin is allowed to be redeemed can be easilyspecified by the access policy, successfully preventingthe tokoin from being unlimitedly used.One can see that there exist five operations over atokoin:
Create , Transfer , Modify , Revoke , and
Redeem . Whena tokoin t needs to be created, the resource owner sends anauthenticated Create message carrying the access policy tothe blockchain, which verifies the message, creates a tokoinand assembles it as a transaction, then places it into the nextblock. When t needs to be transferred, modified, revoked,or redeemed, a corresponding authenticated message needsto be sent to the blockchain, commanding the blockchain totransfer, modify, revoke or redeem t . More specifically, allthe tokoin manipulation functions are performed on-chainby passing authenticated messages, and each operation isrecorded as a transaction such that all operations over atokoin can be securely logged for auditing purpose.Note that the AAA processes are realized by the fivetokoin manipulation functions with the assistance of theunderlying blockchain and reliable access control object viaauthenticated messages in TBAC. In the following sectionwe present a detailed implementation of these tokoin ma-nipulation functions to illustrate how AAA are achieved. Intuitively, TBAC may suffer from two attacks: tokoinforgery and access policy violation. As mentioned in Sec-tion 3.1.2, TBAC makes two system requirements: 1) ablockchain distributed ledger that is provably secure tosupport trusted storage and atomic state transitions; and 2)a reliable access control object r ACO that can securely retrieveaccess policies from a tokoin in blockchain, make accessdecisions according to the access conditions, and monitorthe access procedures. As all operations of a tokoin areperformed on-chain and all messages are authenticated viaprovably secure signatures, the first requirement guarantees
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 8 that an adversary cannot forge a tokoin by spoofing alegitimate signature to create a tokoin for or transfer a tokointo itself, or fork a chain to include its own tokoin makingthe forked chain a legitimate one. On the other hand, thesecond requirement ensures that the access policy definedby the resource owner is strictly followed, no more no less.Based on these considerations, one can safely conclude thatTBAC is secure against tokoin forgery attacks and accesspolicy violation attacks.
YSTEM I MPLEMENTATION
In this section, we detail an implementation of the TBACmodel. We first provide a system description on TBAC, thenpresent its Authentication, Authorization, and Auditingprocesses, and finally describe a native and a more adaptiveTBAC prototype implementations, followed by an AndroidApp for regular users.
TBAC employs a blockchain to fulfill the security require-ments of secure tokoin storage, atomic tokoin transfer, andaccountable activity auditing, and a trusted execution envi-ronment (TEE) to collect trusted environment evidence andmake correct final access control decisions.
A tokoin t = ( t ID , pk O , pk H , policy , isValid ) , where pk O and pk H are respectively the public keys of the owner andcurrent holder of t , t ID is a number uniquely identifying t among all the tokoins generated by the owner pk O , policy defines who is allowed to do what by how in where at when ,and isValid is a binary indicator with isValid = 1 if andonly if t is still valid (not redeemed and not revoked).Note that a tokoin t is uniquely identified in TBAC by thetwo-tuple pk O and t ID , denoted by pk O || t ID , as two tokoinsgenerated by different participants may have the same t ID .For conciseness, isValid is omitted and t is used instead of pk O || t ID to identify a tokoin, if clear from context.A fine-grained access policy answers who is allowed to dowhat at when in where by how , where who is a legit subjectthat may not be known before tokoin t is minted, thus weemploy a cryptographic Accumulator in t. policy to define agroup of subjects who are allowed to redeem t and accessthe resource what . The spatio-temporal access constraints,i.e., when and where , can be sampled from a device such as aGPS receiver at redemption. The access procedure is strictlydefined by how , which can be specified by atomic actions tomanipulate the resource. Whether or not such a procedureis strictly followed can be monitored by a software programor a hardware device such as a video camera. Note that onecan have multiple atomic actions and constraints as well astheir relationships (e.g., “and”, “or”, “not”) defined in policy ,capturing the contextual relationships, to precisely describeunder which condition and how the resource should beaccessed, to realize access control at the user-defined grain-iness level.TBAC relies on a blockchain public ledger for securestorage and atomic state transfer. The ledger is maintainedby all the blockchain nodes participating in consensus and block construction. A tokoin is stored on-chain and all thetokoin manipulation operations are performed on-chain viafunction calls that are realized by passing messages, i.e., thefunction caller sends a message to all blockchain nodes fortokoin Create , Transfer , Modify , Revoke , and
Redeem . Allthe messages must be signed by the function caller’s secretkey and all blockchain nodes receiving the message mustfirst verify its authenticity based on the carried signature. InTBAC, a message from caller pk i has the following format: msg : [ t, op, { policy } , { pk (cid:48) } ] σ pki (1)where op is the operation code that distinguishes whichfunction to be called for tokoin t , the braces contain op-tional information, with { policy } holding a valid policy if op = create or modify and { pk (cid:48) } being a new receiver’saddress if op = transfer , and σ pk i is the message signaturesigned by the secret key of the function caller pk i for messageauthenticity verification. Note that the message actuallyincludes the composite ID pk i || t ID of t but we use t insteadof pk i || t ID here for better clarity. Definition 1.
For a set of participants P = { P , . . . , P n } ,TBAC defines the following nine functions: Gen:
The function
Gen generates keys for the partici-pants in TBAC. When called by participant P i ∈ P , Gen produces a public/secret key pair ( pk i , sk i ) , returns sk i tothe caller and broadcasts the public key pk i to all P j ∈ P .Note that pk i can be used to uniquely identify P i . Verify:
The function
Verify supports overloading. Oninputs of σ and pk , it outputs 1 if and only if signature σ wasindeed signed by participant pk ; on input of t , it outputs 1 ifand only if tokoin t is still valid ( t. isValid = 1 ); and on inputsof t , pk , and role , it outputs 1 if and only if participant pk holds the role in tokoin t . Create:
The function
Create creates a new tokoin t . Oninput of an access policy , it outputs a tokoin t = ( t ID , pk i ,pk i , policy , isValid= to the caller P i , who then acquires role r O . Transfer:
The function
Transfer transfers a tokoin t toa different holder. When called by participant P i ∈ P , itrequires Verify ( t, pk i , r C ) = 1 . On inputs of a receiver pk j and a valid tokoin t = ( t ID , pk O , pk i , policy ) , it modifies t tobe ( t ID , pk O , pk j , policy ) , i.e., changing the current holder of t from pk i to pk j , who then acquires role r C . Modify:
The function
Modify modifies the access pol-icy of a tokoin t . When called by participant P i ∈ P , itrequires Verify ( t, pk i , r O ) = 1 . On inputs of a valid tokoin t = ( t ID , pk O , pk H , policy ) and an updated policy policy ∗ , itmodifies t to be ( t ID , pk O , pk H , policy ∗ ) . Revoke:
The function
Revoke revokes a tokoin t . Whencalled by participant P i ∈ P , it requires Verify ( t, pk i , r O ) =1 . On input of a valid tokoin t it outputs a null tokoin ⊥ with isValid = 0 . Redeem:
The function
Redeem allows Object r ACO toredeem resource D . When called by participant P i ∈ P with tokoin t , it requires Verify ( t, pk i , r S ) = 1 . On inputof a valid tokoin t , it releases resource D and revokes t if PolicyCheck ( t. policy ) = 1 ; otherwise, it transfers t back to r S . PolicyCheck:
The function
PolicyCheck samples the cur-rent digital or physical environment and verifies whether
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 9 the redemption conditions and procedure are completelysatisfied. On input of t. policy , it returns 1 if and only if allthe access conditions are met and the access procedure isstrictly followed. Auditing:
The function
Auditing logs all activities(mainly the function calls of
Gen , Create , Transfer , Modify , Revoke , and
Redeem ) and writes them as a script into thecorresponding transactions on the blockchain public ledger.Among these nine functions,
Gen is used during par-ticipant registration,
Create , Transfer , Modify , Revoke , and
Redeem are used to manipulate a tokoin,
Auditing is calledby all the above six functions before their returns to logall activities for auditing purpose,
Verify is called by thefive tokoin manipulation functions to ensure authenticityand operation privilege, and
PolicyCheck is called only by
Redeem for redemption policy verification.A participate can be a regular blockchain node or a userwho is able to talk with the blockchain via a secure channel.Whenever a participant needs to
Create , Transfer , Modify , Revoke , or
Redeem a tokoin, a signed message is sent to theblockchain who then verifies the message authenticity. Thecapability of the function caller also needs to be examinedbefore tokoin manipulation. A tokoin stays on-chain beforebeing redeemed and a new transaction is issued whenever afunction call is made for a tokoin operation. The transactioncontains the tokoin as well as a script describing the callingmessage and the activities caused by the operation forauditing purpose.The nine functions defined above constitute a com-plete TBAC scheme that complies with the AAA stan-dard mentioned earlier to control the uses of the resource D . The Authentication process comprises the functions Verify and
PolicyCheck , with
Verify essentially verifying thefunction caller’s identity as well as its tokoin capabilityand
PolicyCheck authenticating the current policy uponaccess. The Authorization process is made up of five func-tions
Create , Transfer , Modify , Revoke , and
Redeem , with
Create creating a tokoin defining the access privilege while
Transfer , Modify , and
Revoke making proper modificationsto the tokoin capability, and
Redeem finally taking backthe tokoin capability and redeeming the agreed resource.Function
Auditing implements the Auditing process, makingaccountable audits over all activities and modifications tothe access tokoin.In the following subsections we outline our TBAC build-ing blocks, detail the designs of the AAA processes, andpresent our prototype implementations.
In our TBAC implementation, we utilize multiple key cryp-tographic primitives that are previously proved secure andcomputationally accessible. They are carefully chosen to ful-fill TBAC’s security requirements while not over-qualifiedfor the tasks and not increasing unnecessary overhead.
Tendermint-BFT:
TBAC runs on top of a blockchainsystem. We select a consortium (permissioned) chain settingin which the blockchain security largely relies on the con-sensus process (we don’t consider network layer attacks).For the best collective reliability, we choose Tendermint-BFTas our consensus algorithm. Tendermint-BFT belongs to the Byzantine Fault Tolerance (BFT) consensus family, and it isan improved version over the popular Practical-BFT (PBFT).Ordinary BFTs like PBFT must know the total numberof participating nodes a prior , and may also suffer fromSybil attacks. Tendermint-BFT addresses these challengesby assigning different weights to different validator nodes(where PBFT basically assumes the same weight for everynode). The weights can be quantified by stakes, or otherresources or self-defined security indices. This provides bothflexibility and reliability as the security anchors can becarefully selected to enhance performance. Tendermint-BFTis secure (and fork-proof) when less than one third of thenodes are malicious, according to the security analysis inBuchman et al. [39].
Digital Signature:
Digital Signature allows anyone toverify whether a message is indeed signed by the claimedsigner, and is not altered in transit. Our actual TBAC im-plementation employs ECDSA following the NIST standardbecause it uses a shorter 256-bit key and has a lightercomputation burden compared to the RSA-backed DSA,thus especially suitable for embedded systems. In TBAC,signatures are adopted to verify function callers’ identitiesfor the purpose of granting them different tokoin manipula-tion privileges.
Cryptographic Accumulator:
Cryptographic Accumula-tor is an active research topic in cryptography. It describesa set of public keys with a short, verifiable signature. Givena public key, it can efficiently verify whether or not thiskey is a member of the group. In TBAC, we make use of acryptographic accumulator to authenticate a dynamic group of subject identities – we do not need to define the exact subject who is allowed to finally redeem the tokoin, butrather specify a group of subjects. This is reasonable as wemight not know who is the final subject when we mint atokoin. As shown in our case study, the subject must be alicensed deliveryman but it is hard to know ahead of timethe exact deliveryman who actually redeems the tokoin.Therefore we do not appoint an exact deliveryman whenthe tokoin is created; instead, we employ a crptographicaccumulator to specify a group of licensed deliverymenwho can be legal subjects to redeem a tokoin. Technically,a cryptographic accumulator is usually implemented by astrong one-way hash function that satisfies the commutativelaw.
The Authentication process verifies the authenticity of anidentity or a tokoin capability in TBAC. In service of theAuthorization process, the Authentication process in TBACmakes use of functions
Verify () and PolicyCheck () . Implementation of
Verify () . As mentioned in Sec-tion 4.1.1,
Verify () is an overloading function that performsthe tasks of verifying a message signature, a tokoin validity,or a participant’s access privilege over a tokoin. To verify adigital signature, Verify () takes inputs σ and pk , and outputs1 if and only if σ was indeed signed by pk according toECDSA. To verify the validity of a tokoin t , Verify () takesinput t and outputs t. isValid . If Verify () takes inputs t , pk , OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 10 and role i.e., to verify the role of participant pk in t , we needto consider two different cases: • if role = r S , i.e., pk ’s subject role needs to be verified, Verify () needs to check the cryptographic accumulator acc stored in the access policy carried by t and return 1if and only if pk is indeed a legitimate subject for t ; • if role (cid:54) = r S , Verify () returns 1 if and only if t.pk O = pk if role = r O , or t.pk H = pk if role = r C . Verify ( t, pk, role ) must be called by all the tokoin manip-ulation functions (except Create ) as role defines the privilegeof a participant over tokoin t . For example, Redeem shouldbe called only by a legit subject while only the owner ofa tokoin can modify the tokoin. Note that separating theverification of a tokoin holder and a legit subject is a goodidea because we do not restrain the transfer of a tokoin,but we do have a clear definition on the subjects. In otherwords, there could be a case where the tokoin is transferredto a wrong participant who is not a subject, but we permitonly legit subjects to access.The implementation of
PolicyCheck () requires a secureand reliable access control object r ACO that samples thecurrent environment to verify whether the access constraintsare satisfied and whether the access procedure is strictlyfollowed. It is essentially a trusted data intake source thatis external to the blockchain system. In TBAC, we employTEE to host r ACO as it provides a trusted execution environ-ment that physically isolates security-sensitive programs toprevent them from being tampered with.To fully implement
PolicyCheck () , we need the object r ACO to do two things: to securely collect the evidence fromthe physical or digital environment upon receiving thetokoin redeem call, and to securely communicate with theblockchain system, parse the tokoin to extract the accesspolicy, and then compare the policy carried by the tokoinwith the evidence collected from the environment to decidewhether the access constraints are satisfied and whether theaccess procedure is strictly followed.Collecting evidence from the TEE environment is nottrivial. A possible approach is to implement the drivers ofthe monitoring devices for evidence collection in the TEEsecure zone and connect them directly to the external cor-responding physical devices, to make sure that the devicescan collect correct and authentic data without suffering fromdata interception or alteration. For example, in our casestudy, we implement the driver of a GPS receiver to verifythe spatio-temporal access constraints and that of a camerato monitor the access procedure in a TEE hardware pluggedinto the sensor controller. Note that for a more complicatedapplication, multiple controllers with the TEE hardware canbe connected via secure protocols such as SSL/TLS to mon-itor a large environment. Under the security assumptionthat the TEE secure zone is physically isolated and tamper-free, one can safely accept the evidence as it is directly andsecurely captured.Next we implement the access control object r ACO as ablockchain client inside the TEE secure zone to ensure thatit can directly communicate with the blockchain networkthrough a secure communication channel supported byexisting techniques such as SSL/TLS. Such a design allows r ACO to work independently as a light-weight blockchainnode that does not participate in ledger maintenance and consensus but can listen on the network layer messageswithout relying on any unreliable proxy. After securelyfetching the access policy t. policy from tokoin t , r ACO firstchecks whether the redeem request does come from a legitsubject. This can be done by verifying whether the subjectis a member defined by the
Accumulator in t. policy . Then r ACO checks whether other access constraints such as thespatio-temporal constraints are satisfied by sampling thecorresponding devices, and if yes, r ACO grants the accessby starting the access procedure, which first converts theactions defined in t. policy into instructions to make theresource available to the subject. During this procedure r ACO keeps on communicating with the resource to be accessedand meanwhile sampling the monitoring devices to ensurethat the access procedure is strictly followed. If any viola-tion is detected during the access procedure, the access isimmediately stopped and appropriate measures are taken.It is all to these implementation considerations that make r ACO securely verify whether the access constraints andprocedure are met upon redemption. Note that all activitiesinvolved in
PolicyCheck () are recorded in the TEE securezone and will be logged in the blockchain as the transactionscript when Redeem () is completed. tokoin x TX Script
AccessPolicy
Owner pk Holder pk ID Block j tokoin y transaction … operations Prev. Hash
Block i tokoin x-1 TX Script
Access
Policy
Owner pk Holder pk ID tokoin … Block k tokoin x+1 TX Script
AccessPolicy
Owner pk Holder pk ID tokoin … operations transaction … transaction … transaction … transaction … Fig. 3: Block Structure and URPOAs mentioned earlier, an Authorization process deter-mines whether a person or a process is authorized to per-form a given access activity. In TBAC, this process grantsa privilege to access the resource, modify the privilege, orredeem a tokoin under correct access policy. It includesthe following five functions, whose implementations aredetailed in sequel:1)
Create () : create a new tokoin;2) Modify () : modify the access policy of an existing tokoin;3) Transfer () : transfer a tokoin to another participant;4) Revoke () : revoke a tokoin;5) Redeem () : take in a tokoin and redeem the resource.The implementations of these five functions require ex-planation of the storage of tokoins. As said earlier, a tokoin OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 11 should be stored securely and can be transferred atomically.To achieve this goal, we develop the UnRedeemed PolicyOutput (URPO) model, which is similar to Bitcoin’s UTXOmodel, to manage the tokoins in the distributed ledger. Anyoperation over a tokoin, including the creation of the tokoin,starts from a message sent to all blockchain miner nodesfor verification and consensus approval. If successful, theprocess takes in an existing tokoin if available, performs theoperations as requested, and stores the processed tokoin inthe next block within the ledger. This whole process is calleda policy transaction , and its output is either a newly createdtokoin for
Create or a modified one with the same t ID and pk O as the input tokoin. As long as this policy transactionoutput is not redeemed or revoked, the tokoin remains valid( t. isValid = 1 ).The main purpose of this design is to maintain highatomicity and accountability of the tokoin operations, whichimplies that only atomic and one-to-one transitions canbe allowed to operate a tokoin. Each transaction must beverified by all validating nodes in the blockchain withpublic knowledge, and no tokoin can be forged or forfeitedout of thin air. The block structure is illustrated in Fig. 3.Each block contains a number of tokoins and each tokoincontains its native information as well as a TX Script fieldlogging the corresponding message for and activities overthe tokoin. An access policy within a tokoin is representedin the form of JSON key-value pairs for its simplicity [40],[41], as illustrated in Fig. 3. One can see that such a structureallows users to flexibly define their own access policies atdifferent granularity levels.Any registered participant can create a tokoin, as longas it represents itself and issues access only to its ownresource. To make a tokoin
Create () call, the participantsends out a message msg : [ pk O || t ID , create , policy ] σ rO signedby its secret key sk O to the blockchain system, where t ID is designated by the participant and pk O || t ID is thecomposite ID of the created tokoin that is globally uniqueinside the blockchain. With the public key available, theminer nodes can Verify ( σ pk O , pk O ) , and create a new tokoin t = ( t ID , pk O , pk O , policy , isValid= . Upon the creation of t , the participant acquires the role of r O with respect to t .All actions performed during the creation of tokoin t arelogged in TX Script and recorded with t in the next block asillustrated in Fig. 3.The implementations of Modify () and Transfer () aresimilar to that of Create () , in that they all require an au-thenticated request message carrying the corresponding opcode sent to the blockchain system. But there are subtletiesthat differ them significantly: Modify () can be called onlyby a tokoin owner, and it changes the access policy of thetokoin; Transfer () , on the other hand, can be called only bythe current holder of a tokoin, and it carries the public key pk (cid:48) H of the next holder thus changing the current holder ofthe tokoin upon completion. Accordingly, the message for Modify () has a format of [ t, modify , policy* ] σ rO and that for Transfer () has a format of [ t, transfer , pk (cid:48) H , ] σ rC , for tokoin t .When receiving a Modify () message, the verifiers in theblockchain system first check whether Verify ( t, pk O , r O ) =1 , and if yes, the access policy of the tokoin is changed andthe corresponding transaction is recorded in the next block.Note that a revision on an access policy can modify any key- value pair of the policy, and can add new or delete existingkey-value pairs, to redefine the access policy. Also note thatthe values within a policy are all plaintext modifiable exceptthe access subject group, which consists of one or more in-dividuals and is described by a cryptographic accumulator;therefore, to add or delete subject pk (cid:48) , Add/Del
ACC ( pk (cid:48) ) and Update
ACC () should be called to add or delete the subjectand update the value of Accumulator in the access policy.Similarly, when receiving a
Transfer () message, the verifiersfirst check whether Verify ( t, pk O , r C ) = 1 , and if yes, thecurrent holder of the tokoin is changed to pk (cid:48) H and thecorresponding transaction is recorded in the next block.Note that Modify () and Transfer () do not create a newtokoin but revise certain field of an existing tokoin, and therevision actions are recorded in the TX Script field of thecorresponding transactions.The implementation of
Revoke () is rather simple. Torevoke a tokoin t , the owner of t sends out a message msg : [ t, revoke ] σ rO to the blockchain system, in which theverifiers first check whether Verify ( t, pk O , r O ) = 1 , and ifyes, t. isValid is set to 0 nullifying the tokoin t in the system.Note that only the owner of t can revoke t .The implementation of Redeem () is a bit compli-cated. Upon receiving a Redeem () message msg :[ t, redeem ] σ rS from a subject r S , the verifiers need to check Verify ( t, pk O , r S ) = 1 , and if yes, t is transferred to r ACO ,who then calls
PolicyCheck () to redeem the requested re-source. If PolicyCheck () successfully returns, which meansthat the access process is successful, r ACO invalidates thetokoin t and then sends a confirmation message to thetokoin owner r O . All activities in the redeem process,including those from PolicyCheck () , are recorded in the TX Script field of the transaction for
Redeem () . Auditability and traceability are native in TBAC, as alloperations over a tokoin and all resource access activitiesare logged within the
TX Script field of a transaction storedin the blockchain. Such auditing evidence is publicizedand verified by the whole blockchain system, and as aresult, it is globally legit. Under the security assumptionthat the blockchain system is free from forking and theconsensus process is not compromised, the auditability oftokoin manipulation and access control activities can besecurely guaranteed.
There are three unique distinctions that differentiate TBACfrom other access control models. First, fine-grained ac-cess control can be achieved by realizing an access policythat defines who is allowed to do what at when in whereby how , where who , what , when and where constitute theaccess constraints that must be satisfied in order for anaccess request to be granted and how describes the accessprocedure that must be strictly followed to guarantee accesssafety while avoiding access violations. Second, an accessprivilege, which is intrinsically metaphysical, is transformedto a digital asset, i.e., a tokoin, that is stored in a blockchainand managed with atomic and accountable operations asif it is a cryptographic coin. Third, the validation of theaccess policy is performed at the TEE secure zone that OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 12 physically protects all related programs and securely col-lects environment evidence for correct access decisions andaccess procedure monitoring. These design considerationsensure that TBAC can provide fine-grained and accountableaccess (procedure) control with cryptographic level securityconfidence while making unauthorized access impossible.Now one can safely claim that TBAC ensures all accessactivities to be securely restrained to what the resourceowner has authorized to ( no overprivilege ) and to be publiclyrecorded with no stealthy access ( no weak auditability ). Our TBAC system consists of three components: (1) ablockchain-based distributed ledger that securely managesthe tokoin access capabilities, supports secure atomic tokoinoperations in the form of transactions, and logs all activitieswith security significance for auditing purpose, (2) a trustedlocal access control system within a TEE chipset that hoststhe programs of embedded blockchain clients and sensordrivers in its secure zone for collecting trusted environmentevidence upon redemption and making correct, attack-freeaccess control decisions, and (3) an App-based user interfacefor a good user experience.We have two implementations of the first component: anative implementation
Go-Tokoin in Go language (Golang)that follows our original design for the best performance,and an Ethereum based implementation
Ethereum-Tokoin in Solidity that shows adaptivity of TBAC to mainstreamblockchain platforms. We run Ethereum-Tokoin in bothEthereum Mainnet and Quorum, a consortium fork versionof Ethereum that uses Raft or Istanbul-BFT consensus . Thetokoin functions are tested on the Native Go-Tokoin and theadaptive Ethereum-Tokoin. The experiments are run withseven virtual nodes on top of a PC with the followingsetup: 8-Core Intel i7-6700HQ @ 2.6GHz, 16G memory,Ubuntu 18.04.1 GNU/Linux. We record and analyze theperformance of the implementations for the same case studyin Section.5. One can preview the results in Fig. 8, whichindicate that our native Go-Tokoin takes typically 40-60 mil-lisecond to confirm each transaction, while the Ethereum-Tokoin in Quorum consortium chain takes about 1 second(more than a magnitude) and that in Mainnet takes about 30to 50 seconds (one more magnitude than that). We implement the main blockchain system of TBAC withover 4000 line of codes in Golang, including the Tendermint-BFT consensus and the intercommunication protocols be-tween a participant and the blockchain ledger. Golang isselected because it is a memory-safe, high-concurrent, high-usable language that is quite popular in the security com-munity. As we build our native system pretty much fromscratch, we concentrate on flexibility and customized opti-mization while strictly following the detailed constructionpresented in Section 4.1.1. A complete working system isavailable in Github at https://github.com/zhuaiballl/Go-Tokoin.
2. https://github.com/jpmorganchase/quorum
Although our Go-Tokoin native implementation has betterperformance and more design flexibility as demonstrated byour case study in Section 5, we still want TBAC to be readilyavailable in other mainstream blockchain platforms. Thuswe implement all required TBAC functions in EthereumSolidity, in the form of a smart contract (technically calledinterface). As we manage tokoins as digital assets, we de-velop the interface on top of Ethereum ERC token standards,which stand for Ethereum Improvement Proposals. PopularERC token standards include ERC-20, ERC-777, etc.; how-ever most of them create coins that are fungible , which meansthat all the coins are identical and of the same data. Thiscan perfectly serve the need of cryptocurrency, but clearly itcannot meet the need of TBAC, as we may modify and re-voke a tokoin, and need to trace and audit all tokoins. Thuswe choose ERC-721, a special ERC token standard that isoften used to represent the different ownerships over digitalassets or collectibles, and can be tracked individually. Then,we develop our own TBAC Smart Contract interface ontop of ERC 721, implementing the aforementioned TBAC-specific functions, Ethereum events, and data members.Each user can mint a tokoin by creating a tokoin smartcontract. Users can directly implement their tokoin contractswith Remix-Ethereum IDE, or simply use the TBAC mo-bile App (presented in the following subsection) to auto-generate one. We keep this open-source on the Github athttps://github.com/DES-PER-ADO/Ethereum-Tokoin.The implementation of Ethereum-Tokoin is harder thanthat of the native Go-Tokoin in two aspects. First, alter-ing access policies in Ethereum-Tokoin is hard, as smartcontracts do not allow data post-alteration whatsoever. Weemploy an engineering trick to decouple the logic and thedata with two different contracts to mitigate this problem.Second, during the tokoin redemption process, we need tointake trusted data from our TEE counterpart and sensors.However, taking in exogenous, non-blockchain generateddata from external sensors into a smart contract is cumber-some. This is because of the intrinsic exclusiveness and de-terministic requirements of the smart contract environment.It is null to upload data from a single point to the smartcontract, as the Ethereum VM requires the same logic andsame data input at all nodes. To overcome this problem,we require r ACO to post the sensor data through command sendTransaction to the full blockchain public network.
The most popular hardware-assisted TEEs include IntelSoftware Guard Extensions (SGX), ARM Trustzone tech-nology, and AMD Secure Execution Environment. In ourimplementation, we adopt the ARMv8-M TrustZone, whichwas introduced by ARMv6 around 2002 and then becamepopular due to its low-power consumption. It is comprisedof three components, namely the secure zone, the non-secure callable interface, and the non-secure zone. The se-cure code in the secure zone has higher privilege and canaccess resources in both secure and non-secure zones, whilethe non-secure zone is isolated from secure resources andprograms.To implement the TEE-enabled access control object,we adopt LPC55S69-EVK, an ARM Cortex-M33 based mi-
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 13 crocontroller secured by the ARMv8-M TrustZone. This isbecause LPC55S69-EVK is one of the very few off-the-shelfchipsets that support the ARM Cortex-M33 architecture.Compared to the Cortex-A series, Cortex-M33 has a muchlower cost ($10 for Cortex-M33 compared to ∼ $200 forCortex-A and ∼ $400 for Intel SGX), and its secure areaand non-secure area can be precisely partitioned, providingstrong flexibility. The cost we have to pay is the availabilityof a very little library for development, thus a majority ofour codes are written by us in C and Assembly. Compared tothe rich libraries of Inter SGX and Cortex-A with developer-friendly IDEs, it looks like we build the TEE system directlyon a baremetal MCU. This part takes up about 6000 lines ofcode.Recall that we require r ACO to achieve two objectives: i)to securely collect information that can verify whether theaccess policy is strictly followed, and ii) to securely com-municate with the blockchain system. The information thatshould be collected is application-specific, and is dependenton the access policy specified by the tokoin t . For example,if when and where are defined in t. policy , one can employa GPS receiver to realize the first goal by implementingits driver in the TEE secure zone and connecting the ex-ternal GPS hardware with its driver directly without anyintermediary. To realize the second goal, we implement ablockchain client inside the TEE secure zone to ensure thatit can communicate directly to our blockchain network via aSSL/TLS secure communication channel. After fetching theaccess policy t. policy , its contents are parsed, based on whichcorrect information can be collected to verify whether theaccess constraints ( who , what , when and where ) are satisfiedand the access procedure ( how ) is strictly followed. If yes,the tokoin redemption process is successfully completed.The code for our robust access control object is application-specific as the access policy (condition and procedure) ver-ification are dependent on particular applications, and theone for the in-home cargo delivery case study is available athttps://github.com/DES-PER-ADO/TACO. To avoid users from being messed up with different pro-gramming languages, and more importantly, to provide abetter user experience with no code exposure, we developan easy-to-use TBAC mobile APP in Android, namely TAP,that integrates a TBAC interface with a script/contractwrapper. The purpose of TAP is to keep users from beingexposed to Solidity, Javascript, Golang, or C code.When a user logs in with its credentials (for example ausername-password pair or a private key), TAP identifies itsidentity, searches for all active tokoins the user is associatedwith, and lists them in different categories based on theuser’s role as does by a wallet. If the user wishes to carry outan operation over a particular tokoin, the tokoin needs to beclicked and the required information needs to be input viathe tokoin interface. The input information is then wrappedinto Go-Tokoin scripts, or compiled by the solc
EthereumJavascript commands.We notice that TAP needs to take different steps for dif-ferent blockchain platforms. For Ethereum-Tokoin, we needto initialize a contract, manage tokoins within an existingcontract, or query the public on-chain data. To initialize a contract, a user can either implement its own contract ormodify a default one and define the access policy at theadministrative level. Next, the solc compiler compilesthe created contract into an EVM-compatible EthereumABI, which is then wrapped into the Javascript command .calcContract.new() from the
Web3.js library. Tomanage tokoins, the user can skip solc and directly wrapthe parameters captured by the textbox and scroll-lists theminto JS commands. These operations must be sent usingthe sendTransaction() command from the
Web3.js library. To query the public on-chain data, call() is used.For Go-Tokoin, we do not need an overqualified virtualmachine; instead, one can simply capture the parameters,wrap them in a msg with different opcodes, and thensend the message via .sendTX . One can see that TAPimproves the usability by providing a simple interface forthe users to interact with TBAC. Similarly, the code of TAPis application-specific and the one for our in-home cargodelivery case study is available at https://github.com/DES-PER-ADO/TAP-Cargo-Delivery
Secure Zone
TACO
Blockchain Network
TACO
Initialization
1. Key Generation2. Standard Pattern Generation3. Key/Pattern Registration
Confirm andFinalize
Sign Result with Private Key
Permitted Space Prohibited SpaceDeliveryman
Transfer Tokoin
Subject ID, Tokoin Validity &
Access Constraint
Verification
Start
CASE_1: OVERTIME
CASE_2: OVER-PRIVILEDGE
CASE_3: SUCCESS
Create Tokoin
Monitor and Determine Overprivileged-Access
Redeem TokoinDoor UnlocksAccount Initialization
1. Key Generation
2. Client Registration
Non-secure Zone
Fig. 4: TBAC Assisted In-home Cargo Delivery
ASE S TUDY : TBAC-A
SSISTED I N - HOME C ARGO D ELIVERY
In this section, we report a case study that employs TBAC toassist in-home cargo delivery. This case study demonstrateshow TBAC and IoT can seamlessly work together to controla smart lock in a secure, fine-grained, and accountablemanner for safe in-home delivery.In the US, online-purchased merchandises are usuallydelivered to the outside doorstep of a house, thereby riskof being stolen. With the help of the smart door lock, adeliveryman can open the house door and leave the cargoinside. This may seem to be a good solution and in fact ithas been adopted by Amazon [29]. Nevertheless, by signingup for this in-home delivery service, users would surrenderto the unlimited, unconditional, and unauditable accessesto their homes as an unlimited access token is issued fromthe door lock manufacturer’s access server to Amazon afterauthorizing Amazon the access privilege to the door. It mayget worse if the Amazon’s server is compromised or thetoken is stolen or abused. In this section, we show thatwith TBAC, one can have high confidence that only the
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 14 customer-approved accesses can take place, with a completeauditing. We also emphasize that with a fine-grained accesspolicy specified by the customer, a robust access controlobject can monitor the delivery procedure to ensure thatthe deliveryman does not intrude the house by doing morethan dropping the package.Fig. 4 demonstrates our TBAC-assisted in-home cargodelivery case study. When an order is placed, a tokoinspecifying the detailed access policy to the customer’s houseis also created. The order and the tokoin are sent together tothe seller, who then transfers the tokoin to the first courierof the package when it leaves the warehouse. In transit thetokoin changes its holder when the package is handed toa different courier. The customer can monitor this processvia TAP and can change the access policy based on theshipment status. When a courier arrives at the doorstep ofdestination house, the tokoin is redeemed and the package isdropped inside home if access policy verification succeeds.For security and safety, the access policy specifies that thedeliveryman cannot walk out of the mud area to enter themain house. Thus a video camera is adopted to monitor theprocedure and a violation is reported immediately whendetected. In the following we present this case study in twoprocesses: an initialization process and a delivery process.
The initialization process consists of customer account ini-tialization and the robust access control object initialization.Note that we assume that the seller and its couriers areTBAC clients thus no extra work is needed here. For theease of presentation, we name a TBAC access control objecta
TACO . Camera LPC55S69-EVK Testboard for Debug
Fig. 5: Experiment Setup of TEE
Account Initialization.
Upon initialization, a customercalls the
Gen function to generate a pair of keys sk and pk ,registers itself with and broadcasts its public key pk to theblockchain network, and keeps the private key sk to itself.The customer downloads the TAP software and becomes aTBAC participant who can talk with the blockchain securely. TACO
System Configuration.
To establish the
TACO for our in-home cargo delivery case study, we adopt anLPC55S69-EVK microcontroller secured by an ARMv8-MTrustZone, a smart lock, a GPS receiver, and a low voltageUART serial image sensor camera. In addition, a testboard is utilized for debugging purpose. Upon initialization,
TACO generates a secret key sk and a paired public key pk usingcrypto-libraries in LPC55S69-EVK. Then it broadcasts its pk to the blockchain for self-registration. The pk is used as theaddress and the unique identifier of the TACO system in theblockchain.
TACO also uses the camera to capture the nor-mal background of the home mud area when nobody showsup, and stores it as a
STANDARD PATTERN into its securezone for future detection of over-privileged behaviors suchas the deliveryman walking out of the mud area to enter themain room. The pk and the STANDARD PATTERN are thenregistered as a transaction in the blockchain.Note that we have implemented the drivers of a GPSreceiver and a UART serial camera in the secure zone, whichdirectly connects to the corresponding devices for securedata collection. Also in our case study
TACO is able tocommand the smart lock via secure communications withthe lock server, who can securely talk with the smart lock,thus avoiding the hassle of writing a driver in the securezone and connecting it to the lock. Fig. 5 illustrates the TEEsetup with the sensor camera – the GPS receiver is omittedfor better illustration.
The delivery process is depicted in Fig. 4, whose steps aredetailed as follows.
Create a tokoin.
Before an order is placed, the customermints a tokoin by sending msg : [ pk || t ID , create , policy ] σ rO tothe blockchain, who then creates a tokoin t and logs it in atransaction. The policy specifies who (any legit deliveryman)is allowed to do what (cargo delivery) in where (address ofthe house) at when (e.g., 2-3PM tomorrow) by how (enterthe house, drop the package in the mud area, then leavethe house in 5 minutes). See Fig. 6(a) and Fig. 6(b) for anillustration. The tokoin t and the order together are thensent to the seller. Transfer the tokoin.
The seller then assigns a courierto this order, and transfers t to the courier via a Transfer message when the package is handed to the courier. Aswe discussed before, t can be freely transferred among thecouriers through a standard transfer operation, which easesthe re-distribution of the delivery job for better logisticconvenience. Besides, the customer has the right to trackthe tokoin through a tokoin map as shown in Fig. 6(c). Itcan also modify the tokoin (e.g., changing the delivery timewindow) during this process at its will before the tokoin isredeemed. Redeem the tokoin.
A deliveryman arrives at the houseaddress and wishes to redeem the tokoin t to complete thejob. Redeem is then called, which sends the tokoin t to TACO , who would perform the following tasks for tokoinredemption.
Access Condition Verification.
After receiving t , TACO needs to
Verify : 1. whether t is a valid tokoin; 2. whetherthe deliveryman is a legit subject according to the crypto-graphic accumulator carried by t. policy ; and 3. whether thespatio-temporal access conditions are met, i.e., the time ofdelivery and the delivery address are all consistent withwhat are specified by t. policy . If all verifications succeed, TACO instructs the smart door lock to open the door and letthe deliveryman in to drop the package.
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 15 (a) Creating tokoin (b) Detailed information of a tokoin (c) Geographic trace of a tokoin
Fig. 6: Android Tokoin Activities for Cargo Delivery (a) An actual frame of a
TACO camera capture (b) A
TACO captured patternof benign behavior (c) A
TACO captured patternof minor violation behavior (d) A
TACO captured patternof a major violation behavior
Fig. 7: A Set of Actual Captures of
TACO for Overprivileged-Access Monitoring
Access Procedure Monitoring.
After entering the house, thedeliveryman should drop the package in the mud area andleave in time specified by t. policy . To monitor this process, TACO constantly reads inputs from the UART serial cameraand checks the position of the deliveryman by detectingmoving objects in the video. Specifically,
TACO computesthe difference between the
STANDARD PATTERN and everyvideo frame, and adds them up as a differential monitoringpattern, which is obviously a bitmap with boolean 1 forpresence and 0 for absence of the deliveryman. The deter-mination of a violation, i.e., an overpriviledged access, isdetected if there is a boolean 1 out of the mud area, see theillustration in Fig. 7, which uses an imaginary red line torepresent the boundary of the mud area.There are two possible types of violations: • Case 1: the deliveryman stays longer than the timespecified by t. policy . In this case, TACO would first ringan alarm bell, then send a signed
OVERTIME messageto the customer. If the deliveryman does not leaveimmediately,
TACO may call the police. • Case 2: the deliveryman walks out of the permittedmud area to enter the main room. If this case is de-tected, as shown Fig. 7(c)(d), the corresponding pat-tern of motion trajectory is recorded as a proof of anover-privileged behavior; then
TACO sends a signed
OVER-PRIVILEGED PATTERN to the blockchain andtakes appropriate measures such as locking the smartdoor and calling the police.
Post-Access Management.
If no violation is detected,
TACO sends a signed
SUCCESS to the blockchain after the deliv-eryman successfully drops the package in the mud area andleaves the house. Note that all the data for access condi-tion verification and access procedure monitoring must besigned with the private key of
TACO and stored within theTEE secure zone. This can guarantee the integrity and thetrustworthiness of the data. The data itself or a digest of thedata (if the data is too big) is also sent to the blockchain tobe included in the transaction as a script for auditing the
Redeem operation.The total time for each tokoin manipulation function is
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 16
Create Transfer Redeem PolicyCheck Revoke ModifyGo-Tokoin 46.5 51.3 1033.4 975.6 61.6 54.7Tokoin (on Quorum)1025.0 1027.6 2966.0 1942.0 1024.3 1019.1on Eth Mainnet 37382 40233 52946 39936 18421 23909Results added 915ms from TACOResults added 915ms from TACORedeem included PolicyCheck time in Go and Quorum Ethereum-Tokoin in Quorum Ethereum-Tokoin in Mainnet Create Transfer Redeem PolicyCheck Revoke Modify L a t e n c y ( m s ) i n L o g S c a l e Go-Tokoin Ethereum-Tokoin in Quorum Ethereum-Tokoin in Mainnet
Fig. 8: function Execution Timesreported in Fig. 8. This figure shows the performance ofdifferent TBAC implementations, in logarithmic scale. Thereason why we choose log scale is because the confirmationtimes of Go-Tokoin and Ethereum-Tokoin in three differentplatforms vary up to two magnitudes. Our native Go-Tokointakes typically 40-60 milliseconds to confirm each trans-action, while the Ethereum-Tokoin in Quorum consortiumchain takes about 1 second (more than a magnitude) andthat in Mainnet takes about 30 to 50 seconds (one moremagnitude than that). One should notice that Go-Tokointakes much longer time in
Redeem , which includes the timefor
PolicyCheck . This is because
Redeem requires
TACO to sample the sensor readings, analyze the data, and takecorresponding actions if needed, and communicate the data(or its digest) back to blockchain. Note that the time formonitoring the access procedure is excluded. Besides, thetransaction cost on the Ethereum Mainnet is about 2967kGas on average ($14.7 USD, in July 16, 2019), while ourconsortium Go-Tokoin is free.
We notice that there exist other works that use TEE toperform trustworthy operations. However, most of themare prohibitively expensive, mainly because they use themore-easy-to-implement but expensive chipsets such as theIntel SGX or the Cortex A-series high-performance chipset.Such chipsets are mostly priced around $300 ∼ $400, whichis not practical for general systems used in our daily life.Cortex M-series chipsets are specifically designed for em-bedded systems and real time responses. This series hasvery few usable libraries, kernels, and operating systems,which poses a great engineering challenge on us. We buildthe system almost from the bare metallevel. To the bestof our knowledge, we are the first to implement such atrustworthy system using the challenging yet cheap CortexM23 MCU, which is priced around $10. ONCLUSIONS AND F UTURE R ESEARCH
In this paper we propose TBAC, an accountable accesscontrol model that makes use of blockchain and TEE tech-nologies to realize its goals of offering fine-graininess, strongauditability, and access procedure control. The basic idea ofTBAC is to mint a tokoin that materializes the “virtual”access right into a cryptographically secure digital assetsuch that the resource owner can take full control of the access to its resource, without the need of delegating orrelying on any third party such as a server. The access con-straints and the access procedure as well as their contextualrelationships can be precisely defined in a tokoin, whichconstitutes the access policy, thus realizing fine-graininessand access procedure control. Moreover, all actions overthe tokoin, either on-chain or off-chain, can be securelylogged, facilitated by the blockchain and a robust accesscontrol object (implemented within the TEE secure zone) forpolicy compliance verification, realizing strong auditability.We also present a TBAC-assisted in-home cargo deliverycase study to demonstrate the effectiveness of TBAC insecuring the procedure for a deliveryman to open a doorand drop the package in the mud area of the room withoutentering the main room. Our TBAC design and the casestudy demonstrate a remarkable idea of extending trustfrom on-chain to off-chain, which has its own significancewith broad applications and will be further investigated inour future research.On the other hand, a tokoin in TBAC can be securelytransferred and audited through a standardized process.This enables a new paradigm of trustworthy resource man-agement such as secure IoT resource rental, trading ofIoT resource right-of-use, or flexible errand delegation. Forexample, a senior executive may need a secretary to rebook aflight, change a hotel reservation, or reply a specific email onits behalf. The current solution is to provide the username/-password pair or a picture of the credit card to the secretary.This certainly harms privacy and is undoubtedly highly in-secure. If TBAC is properly applied, the executive can issuea tokoin to precisely specify the permitted operations with-out disclosing username/password or credit card informa-tion. This motivates us to investigate application-orientedTBAC implementations to address various domain-specificchallenges in our future research. A CKNOWLEDGMENTS
It was partially supported by the National Key R&DProgram of China under grant 2019YFB2102600, the Na-tional Natural Science Foundation of China under grantsU1811463, 61971014, 61832012, 61771289, and 11675199, andthe National Science Foundation of the US under GrantsIIS-1741279 and CNS-1704397. R EFERENCES { USENIX } SecuritySymposium ( { USENIX } Security 18) , pages 33–47, 2018.[3] Earlence Fernandes, Jaeyeon Jung, and Atul Prakash. Securityanalysis of emerging smart home applications. In
OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 17
Proceedings of the IEEE , 107(8):1608–1631, June 2019.[8] I Indu, PM Rubesh Anand, and Vidhyacharan Bhaskar. Identityand access management in cloud environment: Mechanisms andchallenges.
Engineering science and technology, an internationaljournal , 21(4):574–588, 2018.[9] Anthony Harrington and Christian Jensen. Cryptographic accesscontrol in a distributed file system. In
Proceedings of the eighth ACMsymposium on Access control models and technologies , pages 158–165,2003.[10] Gregory Saunders, Michael Hitchens, and Vijay Varadharajan.Role-based access control and the access control matrix.
ACMSIGOPS Operating Systems Review , 35(4):6–20, 2001.[11] Vincent C Hu, David Ferraiolo, Rick Kuhn, Arthur R Friedman,Alan J Lang, Margaret M Cogdell, Adam Schnitzer, KennethSandlin, Robert Miller, Karen Scarfone, et al. Guide to attributebased access control (abac) definition and considerations (draft).
NIST special publication , 800(162), 2013.[12] G ¨unter Karjoth, Andreas Schade, and Els Van Herreweghen. Im-plementing acl-based policies in xacml. In , pages 183–192. IEEE,2008.[13] Sonia Jahid, Imranul Hoque, Hamed Okhravi, and Carl A Gunter.Enhancing database access control with xacml policy. In
Proceed-ings of the ACM Conference on Computer and Communications Security(CCS) , pages 130–133, 2009.[14] Ronghua Xu, Yu Chen, Erik Blasch, and Genshe Chen. Blendcac: Ablockchain-enabled decentralized capability-based access controlfor iots. In , pages 1027–1034. IEEE, 2018.[15] Andras Cser. Xacml is dead. Available at https://go.forrester.com/blogs/13-05-07-xacml is dead/.[16] Markus Lorch, Seth Proctor, Rebekah Lepro, Dennis Kafura, andSumit Shah. First experiences using xacml for access control indistributed systems. In
Proceedings of the 2003 ACM workshop onXML security , pages 25–37, 2003.[17] Earlence Fernandes, Amir Rahmati, Jaeyeon Jung, and AtulPrakash. Decentralized action integrity for trigger-action iot plat-forms. In
Proceedings 2018 Network and Distributed System SecuritySymposium , 2018.[18] Emanuele Cozzi, Mariano Graziano, Yanick Fratantonio, and Da-vide Balzarotti. Understanding linux malware. In , pages 161–175. IEEE, 2018.[19] Roei Schuster, Vitaly Shmatikov, and Eran Tromer. Situationalaccess control in the internet of things. In
Proceedings of the 2018ACM SIGSAC Conference on Computer and Communications Security ,pages 1056–1073, 2018.[20] Dick Hardt et al. The oauth 2.0 authorization framework. Techni-cal report, RFC 6749, October, 2012.[21] Pili Hu, Ronghai Yang, Yue Li, and Wing Cheong Lau. Applicationimpersonation: problems of oauth and api design in online socialnetworks. In
Proceedings of the second ACM conference on Onlinesocial networks , pages 271–278, 2014.[22] Yuan Tian, Nan Zhang, Yueh-Hsun Lin, XiaoFeng Wang, BlaseUr, Xianzheng Guo, and Patrick Tague. Smartauth: User-centeredauthorization for the internet of things. In { USENIX } SecuritySymposium ( { USENIX } Security 17) , pages 361–378, 2017.[23] Earlence Fernandes, Justin Paupore, Amir Rahmati, DanielSimionato, Mauro Conti, and Atul Prakash. Flowfence: Practicaldata protection for emerging iot application frameworks. In { USENIX } Security Symposium ( { USENIX } Security 16) , pages 531–548, 2016.[24] Amit Kumar Sikder, Hidayet Aksu, and A Selcuk Uluagac.6thsense: A context-aware sensor-based attack detector for smart devices. In { USENIX } Security Symposium ( { USENIX } Secu-rity 17) , pages 397–414, 2017.[25] Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, andDavid Wagner. Android permissions demystified. In
Proceedingsof the 18th ACM conference on Computer and communications security ,pages 627–638, 2011.[26] N. Zhang, X. Mi, X. Feng, X. Wang, Y. Tian, and F. Qian. Danger-ous skills: Understanding and mitigating security risks of voice-controlled third-party functions on virtual personal assistant sys-tems. In , pages1381–1396, May 2019.[27] Manos Antonakakis, Tim April, Michael Bailey, Matt Bernhard,Elie Bursztein, Jaime Cochran, Zakir Durumeric, J Alex Halder-man, Luca Invernizzi, Michalis Kallitsis, et al. Understanding themirai botnet. In { USENIX } Security Symposium ( { USENIX } Security 17) \ nodeId=202104340.[30] Yizhen Jia, Yinhao Xiao, Jiguo Yu, Xiuzhen Cheng, Zhenkai Liang,and Zhiguo Wan. A novel graph-based mechanism for identifyingtraffic vulnerabilities in smart home iot. In IEEE INFOCOM 2018-IEEE Conference on Computer Communications , pages 1493–1501.IEEE, 2018.[31] Z Berkay Celik, Gang Tan, and Patrick D McDaniel. Iotguard:Dynamic enforcement of security and safety policy in commodityiot. In
NDSS , 2019.[32] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system.Technical report, Manubot, 2019.[33] Ranjit Kumaresan and Iddo Bentov. How to use bitcoin toincentivize correct computations. In
Proceedings of the 2014 ACMSIGSAC Conference on Computer and Communications Security , pages30–41, 2014.[34] Sandeep Kiran Pinjala and Krishna M Sivalingam. Dcaci: A de-centralized lightweight capability based access control frameworkusing iota for internet of things. In , pages 13–18. IEEE, 2019.[35] Yuanyu Zhang, Shoji Kasahara, Yulong Shen, Xiaohong Jiang, andJianxiong Wan. Smart contract-based access control for the internetof things.
IEEE Internet of Things Journal , 6(2):1594–1605, 2018.[36] Damiano Di Francesco Maesa, Paolo Mori, and Laura Ricci.Blockchain based access control services. In , pages1379–1386. IEEE, 2018.[37] Ravi Sandhu and Pierangela Samarati. Authentication, accesscontrol, and audit.
ACM Computing Surveys (CSUR) , 28(1):241–243, 1996.[38] Mohamed Sabt, Mohammed Achemlal, and Abdelmadjid Bouab-dallah. Trusted execution environment: what it is, and what itis not. In , volume 1, pages57–64. IEEE, 2015.[39] Ethan Buchman, Jae Kwon, and Zarko Milosevic. The latest gossipon bft consensus. arXiv preprint arXiv:1807.04938 \ grammar.html. OURNAL OF L A TEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 18
Chunchi Liu obtained his PhD degree from TheGeorge Washington University, Washington DC,USA, in 2020, and his BS degree with distinctionfrom Beijing Normal University, Beijing, China,in 2017, both in Computer Science. His cur-rent research focuses on Blockchain, Internet ofThings, Security, and Applied Cryptography.
Minghui Xu is a PhD student in ComputerScience at The George Washington Univer-sity, Washington DC, USA. He received hisBS degree in Physics in 2018 and minored inComputer Science during 2016-2018 from Bei-jing Normal University, Beijing, China. His cur-rent research focuses on distributed computing,blockchain, and quantum computing.
Hechuan Guo is a PhD student in Com-puter Science at Shandong University, Qingdao,China. He received his BS Degree in ComputerScience in 2017 and MS degree in Engineeringin 2020, both from Beijing Normal University,Beijing, China. His current research focuses onBlockchain, Consensus Protocols, Security, andApplied Cryptography.
Xiuzhen Cheng received her MS and PhD de-grees in computer science from University ofMinnesota – Twin Cities, in 2000 and 2002, re-spectively. She was a faculty member at theDepartment of Computer Science, The GeorgeWashington University, from 2002-2020. Cur-rently she is a professor of computer scienceat Shandong University, Qingdao, China. Herresearch focuses on blockchain computing, IOTSecurity, and privacy-aware computing. She is aFellow of IEEE.
Yinhao Xiao received his Ph.D. degree in com-puter science from The George Washington Uni-versity, Washington, DC, USA, in 2019. He isa faculty member with the School of Informa-tion Science, Guangdong University of Financeand Economics, Guangzhou, China. His currentresearch interests include IoT security, smart-phone security, and binary security.
Dongxiao Yu received his BS degree in Math-ematics in 2006 from Shandong University, andPhD degree in Computer Science in 2014 fromThe University of Hong Kong. He became anassociate professor in the School of ComputerScience and Technology, Huazhong Universityof Science and Technology, in 2016. Currentlyhe is a professor in the School of Computer Sci-ence and Technology, Shandong University. Hisresearch interests include wireless networking,distributed computing, and graph algorithms.
Bei Gong received his BS degree from Shan-dong University in 2005, and Ph.D. degree fromBeijing University of Technology in 2012. Cur-rently he is an associate professor in ComputerScience at Beijing University of Technology. Hisresearch interests include trusted computing,Internet of things security, mobile Internet ofthings, mobile edge computing.
Arkady Yerukhimovich is an assistant profes-sor at The George Washington University sinceFall 2018. Prior to that, he was a research scien-tist in the Secure Resilient Systems and Technol-ogy Group at MIT Lincoln Laboratory where heworked on applying tools from theoretical cryp-tography for practical applications. He receivedhis PhD in August 2011 under Jonathan Katzin the Computer Science department at the Uni-versity of Maryland. His research aims to enablecollaboration between distrusting parties.
Shengling Wang is a professor in College of In-formation Science and Technology, Beijing Nor-mal University. She received her Ph.D. in 2008from Xi’an Jiaotong University. After that, she didher postdoctoral research in the Department ofComputer Science and Technology at TsinghuaUniversity. Then she worked as a faculty mem-ber from 2010 to 2013 in the Institute of Com-puting Technology of the Chinese Academy ofSciences. Her research focuses on mobile/wire-less networks, game theory, and crowdsourcing.