DCACI A Decentralized Lightweight Capability Based Access Control

DCACI: A Decentralized Lightweight Capability Based Access Control Framework using IOTA for Internet of Things Sandeep Kiran Pinjala 1, 2 and Krishna M. Sivalingam 1 1 Dept. of Computer Science and Engineering, Indian Institute of Technology Madras, Chennai, India 2 HCL Technologies, Chennai, India Email: sandeepkiranp@gmail. com, cs 16 s 001@smail. iitm. ac. in, skrishnam@iitm. ac. in, krishna. sivalingam@gmail. com 1

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

Introduction 3

• Internet Of Things (Io. T) 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 Io. T devices would be around 30 billion by 2020. • Most of the Io. T devises are available in the open environment which make them susceptible to unauthorized access. 4

Problem Statement 5

• 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 (Cap. BAC), 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. 6

• Access control challenges in Io. T • 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. 7

IOTA 8

• IOTA (https: //www. iota. org/) is the 3 rd 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 9

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

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

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

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. 13

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 quantumresistant algorithm. 14

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. 15

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. 16

Comparison of DCACI and other Blockchain based access control mechanisms DCACI WAVE Blend. CAC Fair. Access Block. Chain Based Access Control Technology IOTA Ethereum Bitcoin Meant for IOT? Yes yes No Provides Encryption Yes no yes No Provides Integrity Protection Yes yes Yes Access Control Strategy Capability Based Role Based Capability Based Attribute Based Distributed Server Architecture yes No yes Capability Delegation yes yes yes Capability Revocation yes yes no yes Context Aware yes no Transaction Fees no yes yes 17

DCACI Architecture 18

IOTA Tangle 2 b. Publish Token to Tangle 3. Update Token Domain A Owner 4 b. Publish Delegated Token ess c c A nt a r G ken o 1. T lity i b a ap cess C c. A a t 2 ect 5. Ge j e R pt/ e c c 6. A Domain B Owner 4 a. Delegate Token 19

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 20

DCACI Operations 21

DCACI : Grant. Access • A user who wishes to access a resource in a domain must first make a Grant. Access 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. 22

DCACI : Grant. Access • 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 23 HASH of it) to the user to be used during delegation.

Capability Token 24

DCACI : Update. Access • Domain Owner can perform updates to already issued Capability Tokens. • Update. Access 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. 25

DCACI : Update. Access id: 123 Aj. XYz Status: Active. condition: C 1. Address: A 1 id: 123 Aj. XYz Status: Disable. condition: C 1. Address: A 2 id: 123 Aj. XYz Status: Active. condition: C 1 condition: C 2. Address: A 3 id: 123 Aj. XYz Status: Revoked. condition: C 1 condition: C 2. Address: A 4 26

DCACI : Delegate. Access • 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. • Delegate. Access is between delegator and delegatee and does not involve Domain Owner. • Similar to Grant. Access, 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 Update. Access on the delegated tokens. 27

DCACI : Delegate. Access 28

A -> B B -> C id: 123 Aj. XYz Status: Active. condition: C 1 Current. Addr: AB 1 id: 123 Aj. XYz Status: Disable. condition: C 1 Current. Addr: AB 1 id: 123 Aj. XYz Status: Active. condition: C 1 Current. Addr: AB 1 Address : AB 2 Address : AB 3 id: 432 DSDA 8 Parent. ID: 123 Aj. XYz Status: Active. condition: C 1 condition: C 2 Current. Addr: BC 1 Parent. Addr: AB 1 Address : BC 1 C -> D id: 4324 DAKM 6 Parent. ID: 432 DSDA 8 Status: Active. condition: C 2 condition: C 3 Current. Addr: CD 1 Parent. Addr: BC 1 id: 4324 DAKM 6 Parent. ID: 432 DSDA 8 Status: Active. condition: C 2 condition: C 3 condition: C 4 Current. Addr: CD 1 Parent. Addr: BC 1 Address : CD 2 DCACI: Token Updation and Delegation 29

DCACI : Get. Access • 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 Path. Building, Path. Validation and Token. Evalation algorithms to grant/reject the access request. 30

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

Path Validation Token = POP( ) initialize Working. Set from Token 1. Device. Set 2. Resource. Set 3. Condition. Set 4. Rights. Set 5. Delegation. Depth Yes Token Evaluation Yes Is Stack Empty? No Token = POP( ) Is Token Delegable && Delegation. Depth > 0 No Abort Transaction if Stack is not Empty *From Token 1. Device. Set = {Devise. Set} ∩ {Token. Device} 2. Resource. Set = {Resource. Set} ∩ {Token. Resource} 3. Condition. Set = {Condition. Set} + {Token. Condition} 4. Rights. Set = {Rights. Set} ∩ {Token. Rights} 5. Delegation. Depth = Delegation. Depth - 1 32

Get. Access - Token Evaluation • The user request is evaluated against Device. Set, Resource. Set, Condition. Set and Right. Set outputs of Path. Validation algorithm. • If the request matches all of the above, Access is granted. Otherwise it is rejected. 33

Results 34

System • Domain Owner service implemented in Node. js that continuously listens for requests from Users. • The owner is in charge of a set of Io. T 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 Grant. Access and Get. Access requests. 35

Setup • Domain Owner service was run on a Raspberry Pi 1 node with quad-core ARM v 7 CPU and 1 GB RAM running Raspbian GNU/Linux 9 OS. • The owner service was connected to IOTA Public node https: //nodes. thetangle. org/. • User requests for Grant. Access and Get. Access were generated from two systems with 1 GB 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. 36

Output • Grant. Access request from user #node. . /access. js 7001 GRANT owner 1 subject 0 caprequest. json yq. Idl 3 S 0 b 0. key was saved! Access Token received for subject 0 The file yq. Idl 3 S 0 b 0. token was saved! • Update. Access #node access. js 7002 UPDATE 4 E 0 Jf. CWe 1 P Access Update requested for Capability Token 4 E 0 Jf. CWe 1 P Access Updated! 37

Output • Delegate. Access #node. . /access. js 9002 DELEGATE delegate. json Subject=subject 0 Issuer=subject 2 Ey. Jc 9 AEhx 5. key was saved! Delegated Access Token received for subject 0 The file Ey. Jc 9 AEhx 5. token was saved! • Get. Access #node. . /access. js 7000 GET request. json n. Jf. Sk. Sfa. Ck. token Access requested for Capability Token n. Jf. Sk. Sfa. Ck, Issuer: owner 0, Subject: subject 0 Access Granted! 38

Average time taken by DCACI Operations in seconds 5 4 3. 5 3 2. 5 2 1. 5 1 0. 5 0 4. 46 4. 33 4. 05 1. 95 Grant. Access Get. Access Update. Access Delegate. Access 39

Detailed time consumption of DCACI Operations 40

Conclusion and Summary 41

• A proposal for decentralized capability based access control mechanism for Io. T (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 Rasp. Berry 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 Io. T networks. 42

Thank you! 43