Agenda

1. DCACI: A Decentralized Lightweight CapabilityBased Access Control Framework using IOTA forInternet of ThingsSandeep Kiran Pinjala1,2and Krishna M. Sivalingam11Dept. of Computer Science and Engineering, Indian Institute of Technology Madras, Chennai, India2HCL Technologies, Chennai, IndiaEmail: sandeepkiranp@gmail.com, cs16s001@smail.iitm.ac.in, skrishnam@iitm.ac.in, krishna.sivalingam@gmail.com

2. Agenda • Introduction • Problem Statement • IOTA • DCACI Architecture • DCACI Operations • DCACI Results • Conclusion and Summary

3. Introduction

4. Internet Of Things (IoT) is a network of physical objects connected to the internet. For example bulbs, thermostats, wearable items etc • These devices are constrained in terms of processing power, storage and battery life. • It is expected that number of connected IoT devices would be around 30 billion by 2020. • Most of the IoTdevises are available in the open environment which make them susceptible to unauthorized access.

5. Problem Statement

6. Access Control refers to the process of providing resource access only to authorized users. • How do we provide access control across administrative domains in a smart-city like deployment? • Access Control Lists (ACLs), Role Based Access Control (RBAC), Attribute Based Access Control (ABAC) do not scale well to Operational Technology (OT) environment. • In Capability Based Access Control (CapBAC), capability tokens are issued to users that uniquely identify the user and the action that the user can perform on the specified resource. • Contextual information like place, time of access etc can be embedded into the issued token.

7. Access control challenges in IoT • Each Administrative domain might follow its own Authentication and Authorization policy which may not be compatible with other domains. • There is no common platform for storing and enforcing the policies across domains. • There is no centralized authority to verify the integrity of the stored policies. Even if such a centralized authority were to be present, it could be a single point of failure • Since there is no common platform, ensuring privacy of subjects and objects when enforcing the policies across domains becomes challenging. • Having a single Distributed Database for all the administrative domains would partially solve the above problems but there are issues like maintainability and scalability that needs to be addressed.

8. IOTA

9. IOTA (https://www.iota.org/) is the 3rd generation public permission less Distributed Ledger, based on Directed Acyclic Graph (DAG). IOTA calls this DAG, Tangle. • The Tangle is not same as Blockchain • The Tangle is a data structure based on DAG. Each square represents a single transaction. Each transaction always validates 2 previous non validated transactions. https://forum.iota.org/t/iota-consensus-masterclass/1193

10. IOTA Features • Scalability • Decentralization • No Transaction Fees • Quantum computing protection

11. IOTA - Scalability • Unlike BlockChains, Network becomes stronger when number of transactions increases. IOTA Tangle scale Blockchain usability

12. IOTA - Decentralization • IOTA has no miners. Every transaction maker is also a transaction validator which means every transaction maker actively participates in consensus. • In BitCoin most hashing power is concentrated in few mining pools https://www.blockchain.com/en/pools

13. IOTA – No Transaction Fees • IOTA has no transaction fees which means IOTA can be used for micropayments. • You can send one IOTA to an address with no fees charged. • Making micropayments in Bitcoin network makes no sense if the fees are higher than transaction value.

14. IOTA – Quantum Computing Protection • Quantum computers will be able to crack current data encryption methods much faster than classical computers • IOTA uses Winternitz One- Time Signature scheme which is quantum-resistant algorithm.

15. IOTA Masked Authenticated Messaging (MAM) • Message is Encrypted (Masked) • Message is confirmed to be coming from the device (Authenticated) • Continuous message stream is created on the Tangle and will carry on until the device stops publishing the data (Messaging) • MAM is a module built on top of IOTA that makes it possible to send messages fully encrypted from authenticated parties.

16. IOT MAM Modes • IOTA uses Merkle Tree based signature scheme for storing encrypted data on Tangle. It supports the following three modes. In all the modes, the Merkle tree’s root is needed to decrypt the MAM message. • Public Mode – The Merkle Tree’s root is the address of the transaction that the message is published to. Anyone stumbling across the message can decode it using the address of the message. • Private Mode – The Hash of the Merkle root is used as the message address. Even if a user has the message address, he cannot decrypt the message. • Restricted Mode – Similar to Private Mode, the address of the message is the Hash of the Merkle’s root. But in addition to root, a side key is also needed to decrypt the MAM message. The side has to be distributed to channel subscribers.

17. Comparison of DCACI and other Blockchain based access control mechanisms

18. DCACI Architecture

19. IOTA Tangle 2b. Publish Token to Tangle 3. Update Token 4b. Publish Delegated Token Domain B Owner Domain A Owner 1. GrantAccess 2a. Capability Token 5. GetAccess 6. Accept/Reject 4a. Delegate Token

20. Why use Tangle to store Cap Tokens? • Data stored on the Tangle cannot be tampered. • Consensus protocol ensures that transactions are valid. • Tangle is a Distributed Ledger. No single point of failure • Scalable. No limit on how many Cap Tokens can be stored on the Tangle. • Public database. Useful for cross-organizational authorization policies. • Through MAM, IOTA provides a way to store encrypted and signed Capability tokens on the Tangle. • Partition tolerance with offline Sub-Tangle

21. DCACI Operations

22. DCACI : GrantAccess • A user who wishes to access a resource in a domain must first make a GrantAccess request to the destination Domain Owner • It is assumed that the request is made over a secure communication channel and the user is properly authenticated.

23. DCACI : GrantAccess • Domain owner evaluates local access policies to accept or reject the request. • If the request is accepted, Domain Owner generates a Capability token listing the resources, actions and constraints that apply to the User. • The Domain Owner must hold an IOTA SEED to publish MAM data. • The generated token is published onto Tangle using MAM in restricted mode. The domain owner generates a random side key for encrypting the MAM data. A copy of the token is also returned to the User. • If the user has requested for “delegation capability” and if the local policy allows it, the domain owner also sends the side_key (or the HASH of it) to the user to be used during delegation.

24. Capability Token

25. DCACI : UpdateAccess • Domain Owner can perform updates to already issued Capability Tokens. • UpdateAccess does not involve the User to which the token was issued. • Updates can be triggered based on some local conditions like, change in local policy, capability revocation, suspension, additional constrainst etc. • Updated token is pushed as a next message in MAM stream. • The last token in the MAM stream always reflects the current state of the token.

26. DCACI : UpdateAccess id: 123AjXYz Status: Active . condition: C1 . id: 123AjXYz Status: Disable . condition: C1 . id: 123AjXYz Status: Active . condition:C1 condition:C2 . id: 123AjXYz Status: Revoked . condition:C1 condition:C2 . Address: A1 Address: A2 Address: A3 Address: A4

27. DCACI : DelegateAccess • Users may want to delegate full or partial capabilities they received from the Domain Owner to other users. • For example, if a contractor has been given access to First floor of a building for renovation, he may wish to delegate access to a room in the First floor to a sub-contractor. • DelegateAccess is between delegator and delegatee and does not involve Domain Owner. • Similar to GrantAccess, the Delegator issues a Delegated Capability Token to the Delegatee and also creates a new MAM stream on the Tangle. • Delegator must have an IOTA SEED to publish MAM data. The side key used for encrypting the MAM stream is the HASH of the side key used for encrypting the parent MAM stream. • The Delegator may wish to perform UpdateAccess on the delegated tokens.

28. DCACI : DelegateAccess

29. id: 123AjXYz Status: Disable . condition: C1 CurrentAddr: AB1 id: 123AjXYz Status: Active . condition: C1 CurrentAddr: AB1 id: 123AjXYz Status: Active . condition: C1 CurrentAddr: AB1 DCACI: Token Updation and Delegation A -> B Address : AB1 Address : AB3 Address : AB2 id: 432DSDA8 ParentID: 123AjXYz Status: Active . condition: C1 condition: C2 CurrentAddr: BC1 ParentAddr: AB1 B -> C Address : BC1 id: 4324DAKM6 ParentID: 432DSDA8 Status: Active . condition: C2 condition: C3 condition: C4 CurrentAddr: CD1 ParentAddr: BC1 id: 4324DAKM6 ParentID: 432DSDA8 Status: Active . condition: C2 condition: C3 CurrentAddr: CD1 ParentAddr: BC1 C -> D Address : CD1 Address : CD2

30. DCACI : GetAccess • Invoked by the user when it wants to perform a specific operation on a resource for which it holds a capability token. • User submits the Capability Token along with the request to the destination Domain Owner. • It is assumed that the Domain Owner authenticates the user (“subject” attribute in the Cap Token) and that the Cap token and request are transferred via a secure channel. • Presented token could be the one directly issued by the Domain Owner or one that has been delegated across multiple levels. • Domain Owner runs PathBuilding, PathValidation and TokenEvalation algorithms to grant/reject the access request.

31. Path Building Transaction Failed User presents his Capability Token Is Token == Active && Token == Valid Push Token to Stack No Extract ParentAddress Is ParentAddress Empty? Yes Yes Path Validation Extract CurrentAddress from Token Walk across all the CapTokens at CurrentAddress in MAM and get the last token No Set CurrentAddress = ParentAddress Is Token == Active && Token == Valid No Yes

32. Path Validation Token = POP( ) initialize WorkingSet from Token DeviceSet ResourceSet ConditionSet RightsSet DelegationDepth Is Token Delegable && DelegationDepth > 0 Yes Is Stack Empty? Token Evaluation Yes No No Abort Transaction if Stack is not Empty Token = POP( ) *From Token DeviceSet = {DeviseSet} ∩ {Token.Device} ResourceSet = {ResourceSet} ∩ {Token.Resource} ConditionSet = {ConditionSet} + {Token.Condition} RightsSet = {RightsSet} ∩ {Token.Rights} DelegationDepth= DelegationDepth - 1

33. GetAccess - Token Evaluation • The user request is evaluated against DeviceSet, ResourceSet, ConditionSet and RightSet outputs of PathValidation algorithm. • If the request matches all of the above, Access is granted. Otherwise it is rejected.

34. Results

35. System • Domain Owner service implemented in Node.js that continuously listens for requests from Users. • The owner is in charge of a set of IoT devices comprising of a set of resources and certain actions pertaining to those resources. • User requests are fired from a Node.js application that submits the GrantAccess and GetAccess requests.

36. Setup • Domain Owner service was run on a Raspberry Pi 1 node with quad-core ARM v7 CPU and 1GB RAM running RaspbianGNU/Linux 9 OS. • The owner service was connected to IOTA Public node https://nodes.thetangle.org/. • User requests for GrantAccess and GetAccess were generated from two systems with 1GB RAM, 1 CPU 2.4 Ghz Intel(R) Xeon(R) CPU processor running Ubuntu 18.04.1 LTS. • A separate application was run on the Raspberry Pi node to randomly update the issued capability tokens. • In order to support delegation, the user system was also running the same domain owner service.

37. Output • GrantAccess request from user #node ../access.js 7001 GRANT owner1 subject0 caprequest.json yqIdl3S0b0.key was saved! Access Token received for subject0 The file yqIdl3S0b0.token was saved! • UpdateAccess #node access.js 7002 UPDATE 4E0JfCWe1P Access Update requested for Capability Token 4E0JfCWe1P Access Updated!

38. Output • DelegateAccess #node ../access.js 9002 DELEGATE delegate.json Subject=subject0 Issuer=subject2 EyJc9AEhx5.key was saved! Delegated Access Token received for subject0 The file EyJc9AEhx5.token was saved! • GetAccess #node ../access.js 7000 GET request.jsonnJfSkSfaCk.token Access requested for Capability Token nJfSkSfaCk, Issuer: owner0, Subject: subject0 Access Granted!

40. Detailed time consumption of DCACI Operations

41. Conclusion and Summary

42. A proposal for decentralized capability based access control mechanism for IoT (DCACI) based on IOTA’s Tangle. • DCACI supports Grant, Get, Update and Delegate operations with inherent privacy protection. • A concept-proof prototype has been built with RaspBerry Pi acting as a domain owner and user requests being fired from a low end Ubuntu machine. • Simulation results show that our proposed mechanism provides a scalable and fine-grained access control mechanism for IoT networks.

43. Thank you!