About this series:
OWSAP released it latest 2021 version of signature Top 10 threats for all web based service (LINK HERE). Interestingly, "broken access control" made it into the top spot! Not sure if this is anecdotal, but the top comment in HackerNews regards this release also stated that it is becoming more popular for any apps that built with external Baas and authproviders have only little or non awareness on the protection on the access token. At the time that we make use of these Baas framwrok and other low-code tools focusing on product and UI/UX we should also possess adequate security expertise and right mindset!
In this series, we are reviewing serveral papers which try to address the issues of cross vendor/cloud/agent delegation in context of IoT.
1.1 Context of The Problem
Cross-vendor/cloud/device management and automation are common in today's IoT clouds. As more IoT functionality is deployed in the real world, the problem of delegating control can become very complex.
Given the complex and inconsistent mechanisms of different clouds, device delegation in chain in a cross-cloud environment become insecure and can be exploited to obtain unauthorized access to devices and resources due to a loss of control of the delegation.
The key issues that we can identify in are as followed:
- IoT clouds use various authentication methods, with some employing custom authorization and secret sharing mechanisms.
- They are employing contradictory mechanism for generating public and private credentials using cryptographic material retrieved from a device or parent delegator. The secret of the parent supplied to the delegatee could be accidentally exposed.
- In the absence of an effective approach to authorization verification, unauthorized access is permitted even after revocation, resulting in inconsistency of policy down to the delegation chain.
To get answers of these challenge. In this series, we are reviewing serveral papers which try to address the issues of delegation of IoT in different context.
1.2 Cross Cloud Delegation in Cloud.
Cross-cloud delegation have been a common practice in IoT application [1]. The access of IoT through the cloud is often characterized by layers of procedures. The procedure is adopted by mainstream IoT device vendors (e.g., August, LIFX, iHome, IKEA, etc.), and common IoT cloud, such as SmartThings, Google and Amazon. The first step of IoT connectivity is to register the IoT device with its vendor’s cloud. Vendor’s cloud manages authentication and message exchange as well as the commands to devices. The second step is delegating the access and control to common IoT cloud service.
A common example of cross delegation is demonstrated in [1]. A user accesses through the Google Home app, which has been granted access rights to all devices in her possession, she could control her smart bulb in the Philips cloud, smart lock in the SmartThings cloud, smart plug in the iHome cloud, and so on.
Different IoT devices frequently support a variety of delegation operations, such as issuing an OAuth token or secret URL to the delegatee cloud or hosting APIs for the delegatee cloud to use. With the access token from vendor’s cloud, an authorized Google user can issue commands through Google to SmarThings in order to operate on the device
1.3 Delegation Chain in Clouds
After receiving delegations from other clouds and their own users, different IoT clouds have their own permission systems for delegating to the next levels, forming a delegation chain. In principle, each downstream delegatee in a delegation chain shall follow the procedures and input constraints of its upstream delegator. All parties in a delegation chain shall have delegation policies that are consistent with their individual security policies, ensuring that they are not exposed to new threats in the delegation process. When there are new threats, all delegates shall be subject to the same level of security control.
1.4 Delegation Issues in Applications
While overprivileged end-devices are common security issues in IoT authorization, it is observed a new kind of overprivilege exists that the described functionalities of an IoT does not aligned with the actual capability. For instance, the event trigger on closing windows to turn on the air conditioning is indeed also unlocking the door. The mains reasons are that users have limited understanding of the delegation and actual capability of device so they cannot supervise the permission and identify the problem of over privileges.
1.5 Related Technology in Authorizations
1.5.1 Smart Contract with Distributed Ledger
Smart contract in a blockchain address the issues of a trusted third party and has been actively studied in the realm of IoT. The relationship is built by storing the parent’s block 's hash in a child's block header. Transactions are hashed and stored in the block. The two hashes are further hashed to generate the next hash. Afterall, the process generates a single hash that record all the transaction. Consensus is reached by algorithm of Proof-of-Work. With a publicly available blockchain all other users can verify the smart contract and do the auditing for user permission.
1.5.2 Role-Based Access Control (RBAC)
Usage of RBAC has been renown in cloud infrastructure application [2], in the process of authorization and permission control of computing resources as well as users and service accounts. Keystore, the authorization system used in OpenStack, also controls resources permission using the RBAC model [3]. To authorize an action for a user, a token is issued containing a list of roles. To secure an entity or a limited subset of resource, one or more roles with the necessary permissions are specified.
Nevertheless, delegation can be difficult to implement with RBAC based system, because the process of delegation involves associating API calls to roles dynamically, granting and then revoking user permission to perform actions on a given subset of available resources. For related work in delegation with RBAC, the work in [4] has established the model of WRBAC to delegation in a workflow context, offers a fine-grained delegation and proven revocation mechanism.
2.2 Challenging Issues in Solving The Problems
2.2.1 Heterogeneity
Heterogeneity of IoT and cloud services is one of the main challenges. Failure to provide a consistent and verifiable cross-cloud delegation protocol makes it difficult for delegations across conventional IoT clouds to work properly, let alone the severe policy design or implementation flaws. The heterogeneous and ad-hoc processes of delegation have resulted in contradictory IoT cloud delegation policies. Even though various studies have proposed mechanisms in delegation, without an overview of the security constraints of other parties, a delegation mechanism could come to the point that the delegation policy of a delegator could jeopardize the security of a delegate and vice versa.
2.2.2 Authorization Delegation in Different Contexts
The requirements of delegation differ in different context. The context has given different purpose for a single device situated in different location.
In smart city initiatives, a smart city IoT networks necessitate many-to-many coordination between decoupled senders and recipients, as well as decentralized control delegation to implement which devices should connect with which others. Existing end-to-end encryption protocols, especially SSL/TLS, have traditionally catered for one-to-one communication between two principals. These protocols do not appear to be a suitable match for large-scale systems.
In a smart home scenario, an administrator creates a few delegations that include all activities within a static group of family members, and these delegations are rarely removed. To monitor various IoT systems, users often need to install different vendor's applications. Centralized platforms for managing devices from various vendors have emerged and accrued the issues of delegation chain in cross IoT cloud.
The use case of smart hotel applies to a small group of service and a small number of users. The delegation scale is small yet dynamic. Delegations are created and revoked frequently as hotel visitors keep moving in and out of the hotel.
Reference
[1] B. Yuan, Y. Jia, L. Xing, D. Zhao, X. Wang, D. Zou, H. Jia and Y. Zhang, "Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation," in 29th USENIX Security Symposium, 2020.[2] Amazon Web Service, "Authenticating users with Role-Based Access Control (RBAC)," [Online]. Available: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Clusters.RBAC.html. [Accessed 1 April 2021].
[3] N. Tapas, F. Longo, G. Merlino and A. Puliafito, "Experimenting with smart contracts for access control and delegation in IoT," Future Generation Computer Systems, vol. 111, no. 2020, pp. 324-338, 2020.
[4] J. Wainer, A. Kumar and P. Barthelmess, "DW-RBAC: A formal security model of delegation and revocation in workflow systems," Information Systems, vol. 32, no. 2007, pp. 365-384, 2005.
[5] E. Cho, M. Park, H. Lee, J. Choi and T. T. Kwon, "D2TLS: Delegation-based DTLS for Cloud-based IoT Services," in Proceedings of the International Conference on Internet of Things Design and Implementation, New York, United States, 2019.
[6] S. Kumar, Y. Hu, M. P. Andersen, R. A. Popa and D. E. Culler, "JEDI: Many-to-Many End-to-End Encryption and Key Delegation for IoT," in 28th USENIX Security Symposium, Santa Clara, United States, 2019.
[7] Y. Tian, N. Zhang, Y.-H. Lin, X. Wang, B. Ur, X. Guo and P. Tague, "SmartAuth: User-Centered Authorization for the Internet of Things," in 26th USENIX Security Symposium, Vancouver, Canada, 2017.
Leave a Reply