In May of 2022, The National Institute of Standards and Technologies (NIST) released a white paper with a promising perspective on the role of blockchain at the OSI physical layer by way of access control systems:
“Blockchain can be utilized for access control systems as a trustable alternative for a single entity/organization or a member of a large-scale system to enforce access control policies. The robust, distributed nature of blockchain technology can overcome the limitations of traditional access control systems in a decentralized and efficient way.”
Meanwhile, The Institute of Electrical and Electronics Engineers (IEEE) Identity of Things Working Group has been working with a global consortium on the development of the IEEE P2958 standards:
OODA Loop Sponsor
This standard “defines a decentralized identity and access management (IAM) framework for the Internet of Things (IoT) based on emerging concepts such as decentralized identifiers (DIDs) and verifiable credentials (VCs). The framework addresses the integration of DIDs and VCs into the lifecycle of IoT devices as well as the decentralized IoT security services such as device authentication, data authorization, and access control.”
These projects offer a great overview of the promise of blockchain technologies at the physical device layer and opportunities for the creative development of an innovation marketplace for novel defensive cybersecurity platforms. We review the NIST and IEEE efforts here in two separate posts. We begin with the NIST white paper.
Blockchain for Access Control Systems – NIST IR 8403 (1)
NIST’s Computer Security Division, Information Technology Laboratory’s white paper on Blockchain for Access Control Systems presents general information for blockchain access control systems from the views of blockchain system properties, components, functions, and supports for access control policy models. Considerations for implementing blockchain access control systems are also included.
“The rapid development and wide application of distributed network systems have made network security – especially access control and data privacy – ever more important.”
Blockchain technology offers features such as……Decentralization
High confidence; and
Tamper-resistance…
….which are advantages to solving……Auditability;
Resource consumption
Scalability;
Central authority; and
Trust issues…
…all of which are challenges for network access control by traditional mechanisms.
Audience
This document assumes that readers are access control system experts who also have basic network and blockchain expertise. Because of the constantly changing nature of the information technology (IT) industry, readers are strongly encouraged to take advantage of other resources (including those referred in this document) for more current and detailed information.
Executive Summary/Introduction
“The robust, distributed nature of blockchain technology can overcome the limitations of traditional access control systems in a decentralized and efficient way.”
Access control is concerned with determining the allowed activities of legitimate users and mediating every attempt by a user to access a resource in the system. The objectives of an access control system are often described in terms of protecting system resources against inappropriate or undesired user access.
From a business perspective, this objective could just as well be described in terms of the optimal sharing of information. As current information systems and network architectures evolve to be more lightweight, pervasive, and interactive – such as the cloud and Internet of Things (IoT) – there is a need for an access control mechanism to support the requirements of decentralization, scalability, and trust for accessing objects, all of which are challenging for traditional mechanisms.
Access control (AC) is concerned with determining the allowed activities of legitimate users and mediating every attempt by a user to access a resource in the system. The objectives of an access control system are often described in terms of protecting system resources against inappropriate or undesired user access. From a business perspective, this objective could just as well be described in terms of the optimal sharing of information. As current information systems and network architectures evolve to be more lightweight, pervasive, and interactive – such as the cloud and Internet of Things (IoT) – there is need for an access control mechanism to support the requirements of decentralization, scalability, and trust for accessing objects, all of which are challenging for traditional mechanisms.
Blockchains are tamper-evident and tamper-resistant cryptographically linked blocks of data (which create digital ledgers) implemented in a distributed fashion (i.e., without a central repository) and usually without a central authority (i.e., a bank, company, or government). It uses replicated, shared, and synchronized digital blocks between the users of a private or public distributed computer network located in different sites or organizations. Blockchain can be utilized for access control systems as a trustable alternative for a single entity/organization or a member of a large-scale system to enforce access control policies. The robust, distributed nature of blockchain technology can overcome the limitations of traditional access control systems in a decentralized and efficient way. It is supported by the following infrastructural properties that are not included in traditional access control mechanisms unless specifically implemented:Tamper-evident and tamper-resistant design prevents the alteration of access control data (i.e., attributes, policy rules, environment conditions, and access requests) and access control logs (i.e., request permissions and previous access control data) and reduces the probability of frauds.
The control of authorization processing is decentralized, and the storage of access control data/logs has no single point of failure, thus providing more system tolerance and availability.
The traceability of blocks allows access control data/logs and system states to be seen and tracked.
The execution of arbitrary programs in smart contracts allows for controls on distributed access control data and authorization processes.
Consensus mechanisms and protocols jointly regulate the participating access control entities/organizations in determining policy rules through blocks or smart contracts.
Blockchain properties improve the security, flexibility, scalability, integrity, and confidentiality of AC data/logs and processes (compared to traditional AC systems) by allowing organizations to verify and audit AC data transactions and processes to track the states of their AC systems hosted on distributed sites [SP162]. This document presents analyses of blockchain AC systems from the perspectives of properties, components, architectures, and model supports, as well as discussions on considerations for implementation. It should not be deemed comprehensive due to the diverse applications of business and mission requirements. Before selecting and deploying a blockchain AC product or technology, the host organization should augment considerations in this document with testing and independent product reviews.
Blockchain System Components and Advantages for Access Control (AC) Systems
Blockchain systems provide an alternative (or complementary) system for reliability, security, accountability, and scalability for AC systems.
Blockchain characteristics – such as transparency, distributed computing/storage, and a tamper-evident/tamper-resistant design – help to prevent AC data from being accessed or modified by malicious users. Access logs are also recorded in blocks that allow for the detection of malicious activities. Blockchain system components and their advantages for AC systems are:A node is an individual computer system within a blockchain network. It can act as an AC system’s entity or organization and is called an AC node within the AC network. AC nodes
including lightweight nodes (i.e., a node that does not store or maintain a copy of the blockchain), full nodes (i.e., a node that stores the entire blockchain and ensures that
transactions are valid), and publishing nodes (i.e., a full node that also publishes new blocks). Lightweight nodes must pass their transactions to full nodes. Depending on the design of the AC system, AC nodes can act as host servers for AC data (e.g., subject/object attributes, environment conditions, and policy rules) or as administrators for AC policy management and enforcement.
A block contains trustable and tamper-resistant AC data as well as a history of access logs without third parties or centralized management. Distributed blocks solve the single point of failure problem and provide information for distributed architectures, which often involve a much larger set of AC entities or organizations. Distributed ownership of blocks is necessary because of possible trust, security, and reliability concerns that are associated with the centralized management of AC enforcement or AC data ownership [IR8202].
Full blockchain nodes are not only a repository of AC data and logs of blocks but can also store objects. Even though blockchain contents are tamper-evident and tamper-resistant, [Kuhn] proposed a data structure with similar features to a blockchain – the data block matrix data structure – that allows for the deletion of arbitrary records and preserves hash-based integrity assurance that other blocks are unchanged. Such a feature may be incorporated into AC systems that require integrity and privacy protection such that organizations or users are able to delete all information related to a particular access request.
A consensus mechanism ensures that only valid transactions are recorded on the blockchain. Different kinds of consensus mechanisms can be used for AC systems, including proof of work (PoW), proof of stake (PoS), and single committee-based [LQLL]. For mandatory AC (MAC) policies, the integrity and consistency of AC administrations are maintained by consensus mechanisms configured for permissioned blockchains. Consensus mechanisms configured for permissionless blockchains are crucial for discretional AC (DAC) policies due to the dynamic management requirement for scalability and decentralization of the system.
What Next? Considerations for Blockchain-based AC Systems
Blockchain is particularly applicable to access control for network systems where authorization processes are based on subject and object attribute data because it improves security, flexibility and scalability for management, and the enforcement of access control data and processes. It also improves the capability of organizations to verify and audit access control processes with function calls to track the global access control system state. Blockchain system components can function as a resource repository or executable process, allowing it to be neutral for access control policy models. As blockchain access control systems address some challenges from traditional mechanisms, the management, security, privacy, performance, and standardization of the implementation need to be considered.
This section discusses considerations for the implementation of the blockchain AC system from the perspectives of the management, security, privacy, performance, and standardization of AC systems.
Management ConsiderationsBlockchain AC system management needs to coordinate with the business and resource requirements of the systems. For instance, a federated AC system may spread over multiple organizations for cooperation and communication between participating organizations. Hence, AC policies need to be flexible and fine-grained.
A blockchain AC system can transform the policy evaluation process to executable smart contracts so that each organization can control its own system while communicating with other federated organizations.
Optionally, some federation schemes may use the blockchain as a database for storing only the policies but not use the blockchain for access enforcement, such that PDP and PEP functions are performed off-the-chain. However, the main problems of the traditional mechanism, like single point of failure, will be inherited [GBHC].
In addition, considerations should include governance frameworks for legal processes, applicable smart contracts, and the responsibilities of participating AC nodes even though the AC system is based on permissioned blockchains.
Another challenge of managing blockchain AC systems is to develop a trust management and evaluation framework for the decentralization of constrained resource systems, such as an IoT network, where each AC node embedded in a device has limited battery power, memory capacity, and processing speed, and it is often impossible to store extensive interaction history or employ heavy-weight security functions (e.g., microservice of mesh service for SecDevOps implementation).
General AC management requirements, such as allowing runtime policy rule changes and policy administration delegation, may further complicate the design of the blockchain AC system, especially the consensus mechanisms and smart contract functions [IR7874].
Security ConsiderationsAny vulnerability of a blockchain AC system on the level of the entire system or an underlying function of a smart contract can be hacked (e.g., reentrancy vulnerability) or misused. For instance, the publicly available smart contract’s byte code might generate erroneous system state data that will be securely logged on the blockchain.
The only way to fix errors is to delete, correct, and redeploy the entire smart contract. Thus, it is necessary for smart contracts to be correctly deployed (i.e., they work as intended by the developer and cannot be exploited by attackers).
Optimizing smart contract codes can effectively reduce potential vulnerabilities and ensure the efficient execution of contracts. For instance, running smart contracts in parallel can speed up contract execution but requires the consideration of how to execute contracts that depend on each other at the same time (especially for dynamic AC policy models).
Further, smart contracts might require communicating with out-of-chain services, such as receiving AC data from a PIP host, and rely on the oracle of off-chain resources from trusted third parties to retrieve the data and then push them to the blockchain at predetermined times. Although existing oracles are well-tested, their use may introduce a potential point of failure (e.g., an oracle might be unable to push out or provide erroneous data) [KLG].
Due to the tamper-evident and tamper-resistant design of blockchain systems, the system performance evaluation should include extensive and possibly expensive reviews of the smart contract performed by experts before its deployment [SGLSFB, KLG].
If smart contracts are required to provide a way to report and correct any errors, then the system should allow actions to nullify and replace a smart contract. Protocol of the consensus mechanism is another security concern of vulnerability. For example, PoS mechanisms are vulnerable to attacks such as nothing-at-stake, grinding, long-range, and stake bleeding attacks.
PoW and PoS mechanisms may cause low throughput and long transaction confirmation delay, leading to weak consistency problems because an AC process cannot be finalized until its block reaches a certain depth in the blockchain.
These might degrade the performance of AC process, so consistency – including common-prefix, chain growth, and chain quality properties of the consensus mechanism – needs to be considered [PDA].
Migrating from a legacy centralized system to a blockchain AC system needs to address the changes in security assumptions and the assurances of tools and communication protocols for the new decentralized architecture. For example, reimplementing a system using a smart contract language requires changes to secure programming practices, or changing a legacy protocol to Hypertext Transfer Protocol Secure (HTTPS) requires new communications acknowledgments.
Privacy ConsiderationsStoring AC data and logs on the blockchain raises questions of privacy as all subjects can see all entries, and auditable access history in the blockchain can violate user privacy.
The exposed information may also provide information for attacking systems or users. If regulations require AC data owners who are accountable for all data privacy, then instead of storing private data on the blockchain, consider storing index numbers that are tied to private data in an off-the-chain system.
Thus, subjects can own, secure, and even delete their privacy data. Otherwise, methods or tools facilitating cryptography need to be considered for privacy protection [GT].
Performance ConsiderationsThe performance of a blockchain AC system should consider process throughput and confirmation delay. The former refers to the number of AC access requests/processes that the AC system can confirm per unit time (e.g., the Ethereum blockchain can verify 14 transactions per second, which is slow compared to Visa, which can handle up to 24,000 transactions per second), while the latter measures the time it takes for them to be finalized. A blockchain AC system may generate a large volume of access requests that need to be processed and handled or a large number of AC nodes that generate a large amount of data to form an oversized chain (e.g., IoT AC system) [ZZH].
In such cases, AC requests/processes may be constrained by the fact that blockchain data can only be added, not deleted. Due to the scalability limitation of the block memory size, a reduction in performance (bottleneck for the end users) is inevitable. The consequences will be increased synchronization time, increased commission fees (if required), and increased time to confirm an AC request/process [PDA, KLG].
Scalability is another performance concern, and one of the major affecting factors is the consensus mechanism’s consistency and liveness. Consistency means that legitimate AC nodes have an identical view of the AC system state, and liveness means that a valid AC process is sure to be processed and written on the blockchain for a certain period along with the ability to respond to and recover from an attack.
To address these issues, a consensus mechanism can be adjusted to decrease resource consumption, especially for resource-constrained AC systems such as IoT AC systems (it has some disadvantages on security regarding to immutability). For example, the AC system uses a permissionless type of blockchain.
Although the PoW algorithm enables security in the blockchain, it wastes resources. Thus, consider switching from the PoW algorithm to others that can improve scalability as well as lower fees and energy costs (if required) for AC processes [GBHC, KLG], such as proof-of-activity (PoA) or delegated proof-of-stake (DPoS).
The selection of consensus mechanisms also needs to comply with the AC policy models applied. When an AC node is under attack (e.g., DDoS), a blockchain AC system may not have sufficient performance for AC functions, such as the distribution of policy and capturing log files in real-time. Alternative communication channels or appropriate safeguard mechanisms might be required to handle such situations.
As a result, a blockchain AC system must consider hardware and communication limitations in order to economically design an architecture for its memory that is lightweight with limited computing and communication power and storage capabilities, especially for systems with massive AC nodes.
Considerations must also include a fast response consensus mechanism to comply with performance requirements.
Standardization ConsiderationsA blockchain AC system may handle a variety of devices, infrastructures, and governments. For example, a system may have different types of AC data (e.g., types of subject or object attribute values) or proprietary protocols between AC nodes that make it difficult to communicate using a single blockchain platform.
Thus, assurance and standardization of the guidelines allow for universal acceptance of the AC data and smart contracts for AC processing [RGD, PDA].
No comments:
Post a Comment