Interacting with the Internet of Things using Smart Contracts and Blockchain Technologies
IInteracting with the Internet of Things usingSmart Contracts and Blockchain Technologies
Nikos Fotiou, Vasilios A. Siris, and George C. Polyzos
Mobile Multimedia Laboratory, Department of InformaticsSchool of Information Sciences and TechnologyAthens University of Economics and Business76 Patision, Athens 10434, Greece { fotiou, vsiris, polyzos } @aueb.gr Abstract.
Despite technological advances, most smart objects in theInternet of Things (IoT) cannot be accessed using technologies designedand developed for interacting with powerful Internet servers. IoT usecases involve devices that not only have limited resources, but also theyare not always connected to the Internet and are physically exposed totampering. In this paper, we describe the design, development, and evalu-ation of a smart contract-based solution that allows end-users to securelyinteract with smart devices. Our approach enables access control, Thingauthentication, and payments in a fully decentralized setting, taking atthe same time into consideration the limitations and constraints imposedby both blockchain technologies and the IoT paradigm. Our prototypeimplementation is based on existing technologies, i.e., Ethereum smartcontracts, which makes it realistic and fundamentally secure.
Keywords:
IoT; Distributed Ledger Technologies; Ethereum; Interop-erability; Access Control; Authentication; Payments
The Internet of Things (IoT) is an emerging paradigm that has alreadyattracted the attention of both academia and industry. The IoT is ex-pected to penetrate various aspects of our life, allowing the creation ofcyber-physical applications that will improve our living conditions by en-abling healthier and cheaper agricultural products, smarter energy pro-duction and consumption, safer transportation, better entertainment andwellness activities, and innovative services. The IoT will be composed ofsmart devices and protocols that will allow human-to-device and device-to-device interactions. Nevertheless, these devices–henceforth simply re-ferred to as Things–as well as the mainstream IoT use cases, present somelimitations and particularities that create the need for new, innovativeinteraction protocols. In particular, Things will be far less powerful thantraditional Internet clients and servers. Furthermore, Things will not al-ways be connected to the Internet, e.g., in order to preserve energy orbecause they will be physically located in places where Internet access isnot possible (at times). Finally, it should be easier for a malicious user to a r X i v : . [ c s . CR ] J a n amper with a Thing, hence Things should not be used for storing “im-portant” secrets or for processing very sensitive information. To this end,in this paper we design, implement and evaluate a solution that enablessecure interaction with the IoT by leveraging blockchain technologies andsmart contracts.A blockchain is an append-only ledger of transactions distributed through-out a network. Transactions are validated by a number of network nodesand are added in the ledger upon consensus, assuring this way that nosingle entity has control over the ledger. A smart contract is a distributedapplication that lives in the blockchain. Users can interact with a smartcontract by sending transactions to its “address” in the blockchain. Forany interaction with a smart contract, all operations are executed by theblockchain, in a deterministic and reliable way. Smart contracts can ver-ify blockchain user identities and digital signatures and they can performa number of operations. The code of a smart contract is immutable and itcannot be modified even by its owner/creator. Moreover, all transactionssent to a contract are recorded in the blockchain.Although, blockchains and smart contracts–henceforth simply referredto as Distributed Ledger Technologies (DLTs)–are considered a “demo-cratic” way for maintaining transactions [2] and are envisioned to pro-vide novel security mechanisms [7], they have some properties that limittheir (direct) applicability in the context of the IoT. Firstly, interactingwith a DLT involves some computationally intensive security operations(e.g., the creation of a digital signature). Secondly, DLTs require users tomaintain a private key: this key is an important secret that protects theassets of the users stored in the blockchain. Thirdly, information storedin smart contracts is public, hence smart contracts cannot be used forstoring, e.g., user credentials, access control policies, etc. Similarly, infor-mation stored in smart contracts is immutable and all interactions witha smart contract are recorded in the blockchain, hence it is trivial for athird party to deduce, for example, all modifications to an access controlpolicy. Finally, smart contracts cannot directly interact with the physi-cal world: the execution of a smart contract relies solely on informationstored in the blockchain.In this paper, we design and build a solution that allows users to securelyinteract with the IoT using DLTs even if Things are not connected to theInternet continuously or directly. Our solution, which is built using theEthereum transaction ledger [10], takes into consideration the limitationsand particularities of the IoT and the DLTs, is secure and realistic. Withour approach we make the following contributions: – We enable access control, Thing authentication, and payments in adecentralized, secure, and efficient way. – We build on existing technologies and do not propose a new blockchain,neither yet another specification for smart contracts. – We preserve end-user privacy (to the degree that it is preserved bythe specific blockchain used). – We assure that Things are oblivious to the existence of the blockchain,do not store any blockchain-specific secret and the underlay blockchaintechnology is completely transparent to the Things.
System Overview
Our solution leverages our previous work, published in [5], that allowsa Thing and an authorized user to establish a shared, session specificsecret key; this key can be used for securing (using symmetric encryption)all message exchanges. This operation is achieved with the help of athird party, referred to as the
Access Control Provider . From a veryhigh perspective, the solution described in [5] operates as follows. ACPsmaintain a user management system, as well as access control policies,associated with a (Thing provided) resource. Furthermore, each Thingshares a unique key with each ACP that handles access to its resources.Whenever a user requests a protected resource, the Thing generates a token and sends it back to the user. The token is sent in plaintext overan unsecured communication channel: mechanisms (not detailed in thispaper) make sure that any message modification, replay and man inthe middle attack can be detected. ACPs and Things can calculate anew secret key, referred to as the session key using a secure keyed-hashmessage authentication code (HMAC) with inputs the shared secret keyand the generated token. ACPs are responsible for authenticating usersand for securely transmitting the session keys to the authorized ones.The solution described in [5] assures that the session keys calculated byan ACP and a Thing are the same if (a) the user is interacting with thereal Thing, (b) the user is authorized to access the resource, (c) the userhas not lied about his identity, and (d) no messages have been modified.Otherwise, the calculated session keys will be different, hence it will notbe possible for the user to communicate with the Thing. In other words,this solution offers Thing and user authentication, user authorization,message integrity protection, and session key agreement. Furthermore,this solution has two notable properties: (a) the Thing does not have tobe able to communicate with the ACP (as a matter of fact the Thingcan be completely disconnected from the rest of the world) and (b) theACP does not have to be aware of the services provided by the Things,i.e., an ACP and the service provider can be two distinct entities.In this work we consider a similar setup with the addition that usershave to make some form of payment (not necessarily monetary) to theservice providers–henceforth they will be simply referred to as providers–every time they interact with a protected resource. In order to give abetter overview of our system we present the use case of a “smart coffeemachine.” In this use case, a smart coffee machine is installed in a sharedkitchen of a building where the offices of many companies are located.Users interact with the coffee machine using their mobile phones and Wi-Fi direct. The coffee machine operator has come to an agreement withone of the companies located in that building, Company A, and eachemployee of that company is offered 300 free cups of coffee per year. Everytime an employee of Company A wishes to order a coffee the followingprocess is followed. The employee sends a request to the coffee machine,the coffee machine sends a token, the employee authenticates with theCP of Company A and receives the session key, the employee pays thecoffee machine operator (the first 300 times 0.00 EUR and then with thevalue of the coffee), the employee sends a coffee request encrypted withthe session key, and finally the coffee machine sends a receipt encryptedwith the session key and disposes the coffee. All interactions among theuser, the ACP, and the coffee operator (but not between the user andthe coffee machine) utilize a smart contract, stored in a blockchain. Oursystem achieves the following: – Low complexity . Coffee machines are oblivious about the existenceof the blockchain and perform only some very lightweight operations.ACPs are not aware of the services the coffee machine operator of-fers, neither do they have to handle payments. The coffee machineoperator does not have to be aware of the user management systemof Company A. – Support for payments . A smart contract makes sure that usershave the necessary amount of money required for an order. Further-more, the same contract makes sure that all payments are made priorto placing the order. – User privacy protection . No user personal information is stored inthe blockchain. Similarly, coffee machines learn nothing about users. – Endpoint authentication . A smart contract makes sure that auser is authenticated and that the ACP and the coffee machine in-deed share a secret key before the user places the order , by utilizingthe session key.Our system does not provide any guarantees for the interactions thattake place in the physical world, e.g., in our use case, our system doesnot guarantee that the coffee machine does deliver the requested coffee.However, the interaction and payment is recorded in the blockchain (inan immutable way), which can be used as proof in court, if it comes tothat. In our system, service providers and users own a blockchain specific pub-lic/private key pair. We refer to the public key of a user as P user , andto the encryption of a message m using (the private key correspondingto) P user as E user ( m ). For simplicity, we assume that an ACP knowsall P user of its users and all access control policies are based on thesekeys. ACPs, access control policies, smart contracts, and resources areidentified by a URI. We refer to a URI of an entity as URI entity . Smartcontracts implement functions, which can be invoked using transactions,and generate events; f ( x, y, z ) denotes the invocation of a function f For simple access control policies, e.g., lists of blockchain specific public keys, thisauthentication process can take place over the blockchain, otherwise, further infor-mation has to be exchanged using an off-chain communication channel.ith arguments x, y, z , and E ( x, y, z ) denotes an event E with argu-ments x, y, z . Our system uses a keyed-hash message authentication code(HMAC), as well as a simple hash function. We refer to the digest of amessage m using an HMAC function H and a key k as H k ( m ) and tothe hash of a message m as H ( m ). As already discussed, an ACP and aThing end up generating a session key. We refer to this key as sk andto the encryption of a message m , using sk and a symmetric encryptionalgorithm as C sk ( m ). For each user P user there is a cost for accessinga resource URI resource . This cost is known to the smart contract. Sim-ilarly to users, each ACP owns a blockchain specific public/private keypair denoted by P ACP . The protocols described in the following assume a setup phase.During this phase, the smart contract is configured with the available
URI resource and the corresponding
URI policy and P ACP . For simplicityof presentation it is assumed that each
URI resource is protected by asingle
URI policy provided by a single P ACP . Straw man approach
Firstly, we present a simple protocol thatimplements our solution. This protocol is illustrated in Figure 1. Thisprotocol is based on a smart contract that provides the following meth-ods: – request (deposit, token,
URI resource ): Examines if the deposit of theuser suffices for accessing the resource
URI resource . If this is true, itcreates a DEPOSIT event with arguments, P user , token, URI policy ,and
URI resource . – authorize ( P user , token, URI resource , E user ( sk )): Transfers the de-posit that the user P user made (when she invoked the request method)to the service provider. Then it creates a KEY event using themethod input parameters as arguments.With this protocol, initially, a user P user requests a protected resourcefrom a Thing and the Thing responds with a token (generated using theprocess described in [5]) and the URI of a smart contract that protectsthe requested resource. Then, the user invokes the request method of thesmart contract. The DEPOSIT event is broadcast and received by theappropriate ACP which examines if P user can be authorized to access URI resource . If this is true, the ACP generates the session key sk (usingthe process described in [5]), encrypts it using P user , and invokes the authorize method of the smart contract. The smart contract examinesif the ACP that invoked the authorize method is allowed to do so. Thischeck is simply implemented by examining if the public key of the entitythat invoked that method is equal to the P ACP of the legitimate ACP.The drawback of the straw man approach is that the payment to theprovider takes place without any check. Note that with the solution de-scribed in [5], the user is able to perform certain verifications after tryingto use the received sk . However, with the straw man approach, these ver-ifications can only be used for a dispute resolution. ay provider KEY(P user , token, URI resource, E user (sk)) DEPOSIT(P user , token, URI
Policy,
URI resource ) (3) request(deposit, token, URI resource )(4) authorize(P user, token, URI resource, E user (sk))ACP Contract User Thing (1) GET resource (2) URI Contract , token(5) C sk (request) Fig. 1.
The straw man protocol.
A first construction
We now present an improvement to the strawman approach by allowing an ACP to verify that a user is communicat-ing with a legitimate Thing (Figure 2). In order to achieve this goal, weextend the request method of the smart contract to include an additionalfield, i.e., H sk ( token ). The value for this field is provided by the Thing,in its response to a user request. Furthermore, we extend the DEPOSITevent to include this field. Now an ACP, after generating the sk , cal-culates H sk ( token ), and checks if the value of the latter calculation isequal to the value provided by the Thing. If this is true, then the Thingis considered legitimate. (5) C sk (request)(4) authorize(P user, token, URI resource, E user (sk)) DEPOSIT(P user , token, URI
Policy
URI resource, H sk (token)) (2) URI Contract , token, H sk (token) (3) request(deposit, token, URI resource , H sk (token)) ACP Contract User Thing(1) GET resourceKEY(P user , token, URI resource, E user (sk))Pay provider Fig. 2.
Our first construction.
A second construction
We now extend our previous constructionto enable smart contracts to verify the relationship between a Thingand an ACP, i.e., the contract can verify that the Thing and the ACPindeed share a secret key. This functionality is achieved by having theuser “challenging” the Thing during her request. The challenge used isa random number, which the Thing should obfuscate in a way that onlyan ACP that shares a secret key with the Thing could read. The smartontract should therefore learn the challenge from the user and shouldexpect it from the ACP. In order to “hide” the challenge we leverage ahash function using the process described below.The Thing responds to a challenge with H ( H sk ( challenge )). Given achallenge, only an entity that can generate the session key sk can calcu-late H sk ( challenge ). Note that, in addition to the Thing, this key can becalculated by the ACP that protects the resources stored in that Thing.Furthermore, given H sk ( challenge ) any entity, including the smart con-tract, can easily calculate H ( H sk ( challenge )) (but the reverse processis not possible due to the properties of the hash functions). Hence, the request method is extended to include H ( H sk ( challenge )) and the au-thorize method is extended to include H sk ( challenge ). Then, the smartcontract can calculate the hash H sk ( challenge ), received by the ACP,and compare the output to the hash value it received from the user. Ifboth hash outputs are the same, the contract sends the KEY event. (2) URI
Contract , token, H(H sk (challenge))(4) authorize(P user, token, URI resource, E user (sk)), H sk (challenge)) (3) request(deposit, token, URI resource , challenge, H(H sk (challenge)))ACP-Provider Contract User Thing(1) GET resource, challengeDEPOSIT(P user , token, URI Policy
URI resource, challenge) (5) C sk (request)KEY(P user , token, URI resource, E user (sk))Pay provider Fig. 3.
Our second construction.
We have implemented the presented solution using Ethereum smart con-tracts. This technology has some limitations that have led us to certaindesign choices. In particular, although each user in Ethereum owns apublic/private key pair, a smart contract has access only to each user’s“address”, i.e., the last 20 bytes of the hash of her public key. This meansthat users have to explicitly include their public keys with every smartcontract function invocation; in our implementation we have added anadditional field in each function which is used for storing callee’s publickey. Furthermore, Ethereum keys are constructed using the secp256k1elliptic curve; encrypting content using this curve can be cumbersomesince specialized constructions, such as the elliptic curve integrated en-cryption scheme [9], are required. For these reasons we have selected to Source code of our implementation can be found at: https://github.com/SOFIE-project/spiotot use Ethereum’s keys in our constructions, but instead we are usingkeys based on the Curve25519 elliptic curve [1]. Curve25519 is a wellsupported, fast curve which is ideal for key establishment, as it allowsa user A to generate a symmetric encryption key that can be used forcommunicating with a user B , using only B (cid:48) s public key.The main constructions of our smart contract, which is deployed in alocal testbed, are implemented in five functions: requestS (), request request request () method for our three pro-tocols (straw man, first construction, and second construction), and authorize authorize authorize () methodfor the first two protocols and for the last protocol respectively. The ta-ble below illustrates the cost, measured in Ethereum “gas,” for invokingeach function. Function Cost measured in gas requestS() 123.186request1() 128.218request2() 253.488authorize1() 57.950authorize2() 63.746
Table 1.
Cost for invoking smart contract functionsEndpoints are implemented using JavaScript. Interactions with the Ethereumblockchain are implemented using the Ethereum JavaScript API, whereascryptographic operations are implemented using the TweetNaCl library. Prior work on blockchain-assisted access control has proposed schemesthat store access control policies in the blockchain. For example, Maesa etal. [3] use the Bitcoin blockchain to store “Right Transfer Transactions”,i.e., a transaction that indicates that a user is allowed to access a partic-ular resource. These transactions are then used by “Policy EnforcementPoints.” Zyskind et al. [11] use the Bitcoin blockchain to store access con-trol polices to protect personal data. Similarly, Shafagh et al. [8] storeaccess control policies in the Bitcoin blockchain for controlling accessto data produced by IoT devices. However, storing so sensitive informa-tion in the blockchain clearly constitutes a privacy and security threat.Even if we ignore the fact that blockchain should not be used for stor-ing “secrets”, the immutability of the blockchain may allow 3 rd partiesto deduce information about the access patterns of a particular user, oreven about the security policies of a content owner.A growing body of work propose the use of custom blockhains in orderto overcome similar challenges. For example, Dorri et al. [4] implement https://github.com/ethereum/web3.js/ https://tweetnacl.js.or custom made blockchain for a smart home application and considerper-home miners, which also act as trusted proxies for the home devices.Similarly, Ouaddah et al. [6] propose a blockchain solution that can beused for providing access control for IoT applications. Such approacheshowever, provided they are secure, require a critical mass of users thatwill adopt the proposed technology. In this paper we presented a solution that allows end-users to interactwith IoT devices. The proposed design, which is based on DLTs, en-ables access control, Thing authentication, and payments, protecting atthe same time end-users’ privacy. These properties are achieved withoutrequiring Things to be capable of interacting with DLTs; instead end-users seamlessly and transparently bridge smart contracts with Thingsand the physical world. Our construction protects end-users from mali-cious Things, since it withholds payments until the relationship betweena Thing and its owner is verified. Furthermore, by recording all criticalinformation in the blockchain, our solution facilitates dispute resolution.Finally, our Ethereum-based implementation proves that our solutioncan be realized with existing technologies.In our implementation, each user is using two pairs of public/privatekeys, one for the blockchain operations and one for encrypting the secretinformation of our protocol. Furthermore, these pairs are decoupled. Theuse of multiple, decoupled key pairs enable some interesting extensionsto our system. For example, a user may use different blockchain-specifickeys in each transaction avoiding this way tracking by 3 rd parties. Fur-thermore, a user may include in a request () transaction the pubic key ofanother user or back-end service, e.g, an additional access control servicethat will forward the session key to the user only if certain conditionsare met.The use of the blockchain technology adds a layer of protection to oursystem against (D)DoS attacks. With our solution attackers would re-quire to pay a fiscal cost in order to attack an ACP. Furthermore, smartcontracts are replicated to multiple nodes (miners) which execute themsimultaneously, providing this way redundancy to our system. Finally,since all events are broadcasted, an ACP can be easily moved (or repli-cated) to a new network location. It is in our future work plans to furtheranalyze and measure this feature of the blockchain technology.Compared to traditional Internet applications, IoT applications have aunique property: they involve interactions with the physical world. Theoutcomes of these interactions cannot be easily verified by the cyberworld. This can be easily understood when our solution is considered:it is not easy to verify that the key provided by the Thing owner is thecorrect one and, even more obvious, it is not easy to verify that Thingsrespond with a correct answer to user requests. Although blockchaintechnologies are a useful tool that can be used by humans to verify thatall physical activities took place correctly, the interweaving of the phys-ical and the cyber world creates challenges that cannot yet be overcomein a guaranteed secure manner using only technological means. cknowledgments The research reported here has been undertaken in the context of projectSOFIE (Secure Open Federation for Internet Everywhere), which has re-ceived funding from EU’s Horizon 2020 programme, under grant agree-ment No. 779984 (and at AUEB it is managed through AUEB-RC). Theauthors thank Dmitrij Lagutin for his valuable comments.
References
1. Bernstein, D.J.: Curve25519: New Diffie-Hellman speed records. In:M. Yung, Y. Dodis, A. Kiayias, T. Malkin (eds.) Public Key Cryptog-raphy - PKC 2006, pp. 207–228. Springer Berlin Heidelberg, Berlin,Heidelberg (2006)2. Cohn, J., Finn, P., Nair, S., Sanjai, P.: Device democracy: Savingthe future of the Internet of Things. IBM Institute for BusinessValue (2014). URL . (last accessed 30 Aug. 2018)3. Di Francesco Maesa, D., Mori, P., Ricci, L.: Blockchain based accesscontrol. In: L.Y. Chen, H.P. Reiser (eds.) Distributed Applicationsand Interoperable Systems, pp. 206–220. Springer International Pub-lishing (2017)4. Dorri, A., Kanhere, S.S., Jurdak, R., Gauravaram, P.: Blockchain forIoT security and privacy: The case study of a smart home. In: 2017IEEE International Conference on Pervasive Computing and Com-munications Workshops (PerCom Workshops), pp. 618–623 (2017)5. Fotiou, N., Kotsonis, T., Marias, G.F., Polyzos, G.C.: Access con-trol for the Internet of Things. In: 2016 ESORICS InternationalWorkshop on Secure Internet of Things (SIoT), pp. 29–38 (2016)6. Ouaddah, A., Abou Elkalam, A., Ait Ouahman, A.: Fairaccess: anew blockchain-based access control framework for the Internet ofThings. Security and Communication Networks (18), 5943–5964(2015)7. Polyzos, G.C., Fotiou, N.: Blockchain-assisted information distribu-tion for the Internet of Things. In: Proceedings of the 2017 IEEEInternational Conference on Information Reuse and Integration, pp.75–78 (2017)8. Shafagh, H., Burkhalter, L., Hithnawi, A., Duquennoy, S.: Towardsblockchain-based auditable storage and sharing of IoT data. In:Proceedings of the 2017 on Cloud Computing Security Workshop,CCSW ’17, pp. 45–50. ACM, New York, NY, USA (2017)9. Shoup, V.: A proposal for an ISO standard for public key encryp-tion. Cryptology ePrint Archive, Report 2001/112 (2001). https://eprint.iacr.org/2001/112
10. Wood, G.: Ethereum: A secure decentralised generalised transactionledger. Ethereum Project Yellow Paper151