CN112738194A

CN112738194A - Access control system for safe operation and maintenance management

Info

Publication number: CN112738194A
Application number: CN202011557599.0A
Authority: CN
Inventors: 不公告发明人
Original assignee: Nanjing Liancheng Technology Development Co ltd
Current assignee: Nanjing Liancheng Technology Development Co ltd
Priority date: 2020-12-25
Filing date: 2020-12-25
Publication date: 2021-04-30

Abstract

The invention discloses an access control system for safe operation and maintenance management, which is characterized in that an intelligent contract used for representing an access control strategy and the access control system using the access control strategy are uniformly deployed on the same block chain; the system further comprises a data storage library, an index server, a strategy execution module, a strategy management module, a collection module and a forwarding module. By the invention, the security audit function of the access control system for the security operation and maintenance management can be enhanced.

Description

Access control system for safe operation and maintenance management

Technical Field

The invention relates to the technical field of distributed architecture, 4A (Authentication Authorization, Account number, and Audit Audit), block chain and network security, in particular to an access control system for security operation and maintenance management.

Background

Currently, most existing digital resources (e.g., servers, databases, services, and even smart objects, from smart watches to unmanned cars) have been connected to the internet because of the ever-expanding coverage of internet connections. It is clear that if such connectivity could provide new and better functionality on the one hand, but on the other hand also brings new security risks for unauthorized access to these resources. To prevent privacy violations and false or malicious use, these resources need to be protected by appropriate security mechanisms, e.g., deployment of access control systems. The access control system is able to control attempts to access these resources, granting access rights only to those users who actually have the corresponding rights in a particular access context. Therefore, in order to control and reduce the security risk, an enterprise as the owner of the digital resource should urgently need to deploy and run an access control system; however, due to the configuration, deployment, and management of the access control system, a large economic burden is placed on the enterprise as the owner of the digital resource, including hardware costs (purchase costs of the server/virtual machine hosting the access control system), software costs (the access control system may need to pay a fee on a regular basis), and human costs (the cost of time spent by the administrator in managing the access control system). In view of this, another solution is that the enterprise as the owner of the digital resource directly outsources the access control function to the access control system provided by the trusted third party (for example, as a service lease, the third party will access the access control function), so as to solve the urgent need of the enterprise (especially the vast middle and small-sized enterprises). Since access control systems implemented in the form of cloud services have been commercialized and developed in recent years, such as OpenPMF-SCaaS, ACaaS, etc., and these cloud services generally use open platform APIs in a manner that its users are not limited by the use of a specific implementation, a third party can also uniformly manage policies for all resources that it owns using these services. For example, Amazon provides users of aws (Amazon Web service) with an Access control service called identity and Access management, iam (identity and Access management). IAM allows Amazon users to manage access to their AWS services and resources by creating and managing their users and groups of users and defining appropriate permissions to allow or deny access to their resources.

Disclosure of Invention

In order to solve the technical problem, the invention provides an access control system for safe operation and maintenance management. An alternative solution for outsourcing the access control function to a third party is provided for a large number of medium and small enterprises as owners of digital resources. The scheme has the auditability characteristic of the access control strategy, and can avoid the defects that the access control system of a third party has access control such as configuration error of the access control strategy or wrong access control, and a tenant cannot locate faults, search reasons and collect evidences.

An access control system for safe operation and maintenance management is characterized in that an intelligent Contract Smart Contract and the access control system are deployed on the same block chain; the system also comprises a data storage library, an index server module, a strategy execution module, a strategy management module, a collection module and a forwarding module;

the data storage library is used for storing and managing the attributes of the intelligent contracts;

the index server is used for quickly searching and positioning an intelligent contract based on the current access request, wherein the intelligent contract comprises an access control rule related to the access request;

the strategy execution module evaluates the access request based on the intelligent contract and returns an evaluation result (namely, access is allowed, access is denied, and the strategy is uncertain or inapplicable);

the policy management module, the component responsible for managing access control policies, acts as a policy repository to retrieve the access requests as they are evaluated, another function of the policy management module is policy editing to help policy makers create, modify, query and delete access control policies;

the acquisition module serves as an access control system and a plurality of protocol data acquisition plug-ins and provides an interface for interaction with each data repository;

the forwarding module functions as a scheduling component in a decision flow.

Further, the smart contracts, referred to as smart policies;

further, the intelligent policy further includes the following steps:

compiling XACML strategy;

policy transformation from XACML to smart contracts;

such contracts are deployed over blockchains.

The invention has the technical effects that:

the invention provides an access control system for safe operation and maintenance management, which is characterized in that an intelligent contract used as an access control strategy and the access control system using the access control strategy are uniformly deployed on the same block chain; the system further comprises a data storage library, an index server, a strategy execution module, a strategy management module, a collection module and a forwarding module. By the invention, the security audit function of the access control system for the security operation and maintenance management can be enhanced.

Drawings

FIG. 1 is a schematic diagram of the XACML architecture of an access control system for secure operation and maintenance management;

FIG. 2 is a schematic diagram of an access control system for secure operation and maintenance management;

fig. 3 is a schematic diagram of an XACML to identity parser of an access control system for security operation and maintenance management.

Detailed Description

The invention is described in further detail below with reference to the figures and examples:

in the present application, an alternative solution for outsourcing the access Control function to a third party is provided for an enterprise as a digital resource owner, namely an access Control system acs (access Control system) for secure operation and maintenance management based on the block chain technology. The system is compliant with the XACML standard and implemented in the form of intelligent contracts (Smart contracts), and these intelligent contracts and access control systems are deployed, stored, and executed uniformly across the blockchain. The method has the idea that the access control strategy is converted into a code program of an executable intelligent contract, management is carried out through a block chain, integrated safe operation and maintenance management is achieved, the auditability characteristic of the access control strategy is achieved, and the defects that access control of a third party such as configuration errors or errors of the access control strategy occurs in an access control system of a third party, and therefore fault locating, reason searching and evidence collecting of tenants cannot be achieved. Generally, the access control policies of the third party's access control system are created and managed by the resource owner, and these access control policies are not viewable by the tenant and/or user and/or the user leasing the third party's access control system. The third party is in full charge of the operation, maintenance and management of the access control system.

the acquisition module serves as an access control system and a plurality of protocol data acquisition plug-ins and provides an interface interacting with each data repository so as to retrieve and update values of attributes, wherein the acquisition module comprises a WMI (wireless multimedia interface) protocol data acquisition plug-in, an HTTP (hyper text transport protocol) protocol data acquisition plug-in, an MML (multimedia messaging language) protocol data acquisition plug-in, an SNMP (simple network management protocol) protocol data acquisition plug-in, a syslog protocol data acquisition plug-in and the like; the plug-in for collecting various protocol data is responsible for collecting data based on the protocol, such as an SNMP protocol plug-in, and is responsible for collecting SNMP MIB data based on an SNMP protocol, and also such as a syslog protocol plug-in, and is responsible for collecting reported event information based on the syslog protocol;

the forwarding module functions as a scheduling component in a decision flow.

The access control system for block chain-based security operation and maintenance management can help the security operation and maintenance management in many aspects, such as:

(1) and correctly tracking the safe operation and maintenance data by using the block chain: under the consensus of most people, the substitution of real values and false values of the safety operation and maintenance data measurement is prevented;

(2) by using the block chain technology, the safe operation and maintenance data can exchange data under the condition that a third party is not involved in establishing trust, and the block chain provides a distributed trust environment for data sharing;

(3) the operation and deployment costs of secure operation and maintenance management may be reduced because it supports P2P (Peer to Peer) communications;

(4) under the condition that the data are not matched, the equipment with the fault can be easily detected by means of a hash mechanism of the block chain technology;

(5) by integrating the block chain technology into the network security, a safe operation and maintenance management environment with low operation cost and high efficiency can be formed.

In the present application, the resource to be protected (i.e. the access rules of the intelligent contract) and the system protecting it are both deployed on the same blockchain. The present application provides certain advantages over outsourcing the access control process to a third party, for example, where both the enterprise that is the owner of the digital resource and the principal/user that issued the access request can easily detect improper authorization or denial of access, due to evidence of improper behavior that can be publicly reviewed. In fact, a third party access control service may maliciously force the system to return a denial, thereby prohibiting access by a certain user, even though policy may grant it access rights. Instead, it may even return permissions when the policy is not satisfied, allowing access by users without corresponding rights. In both cases, neither the enterprise nor the user, who is the owner of the digital resource, can check the correctness of the access decision process results afterwards, since the access context details considered may no longer be available. In contrast, in the blockchain scenario of the present application, both the enterprise and the user or principal, as owners of the digital resources, are able to validate each access request evaluation policy due to the transparency and auditability characteristics inherited from the blockchain technology. In fact, the user can always browse the block chain and control the access requests and then attribute values performed on a given resource, and make decisions on the access results returned as a response to their access requests.

The access control system is responsible for protecting the resources of an application scenario by checking access requests performed by users of that scenario in a given access context. In other words, the ACS decides whether these users have the right to perform the access they requested in the current access context or must deny these accesses. These rights are represented by an access control policy, which is composed of a set of conditions that are evaluated according to the current access context in order to make an access decision each time an access request is received. In some cases, the right to perform an access is not static, and therefore is constantly verified throughout the access itself, in order to interrupt it when the access context changes. A model for defining an existing Access right, for example, a mandatory Access Control mac (regulatory Access Control), a free Access Control dac (decentralized Access Control), a role-based Access Control, etc., wherein an Attribute-based Access Control ABAC (Access-based Control) model represents an Access context by a set of attributes describing relevant characteristics of a subject/or a user, a resource, and an environment, and uses an Access Control policy consisting of a set of conditions for values of the attributes. Examples of attributes of subscriber S may be, for example: the ID of S, the job ID of the company, the role of S in the company, the name of the project assigned to S, the amount of resources S is currently using, etc. Examples of attributes paired with data D may be: item D belongs to, the privacy level (e.g., public, internal, or confidential) assigned to such data, the ID of the producer of D, etc. A very simple example of an ABAC strategy: if D belongs to one of the items assigned to S, the user S is allowed to access the document for item D. This policy compares only attribute values representing items assigned to the user with attribute values representing item documents.

There are a number of programming languages currently available for writing the ABAC policy, and the extensible Access Control Markup language XACML (eXtensible Access Control Markup language), one of the most popular languages, is described below.

XACML is a standard that defines an XML-based language to express ABAC policies, requests, and responses. The request is for an attribute value that must be provided by the user to represent the access context in the same format as the policy. For example, a user may provide their user id, the resource id of the resource to be accessed, and the operation id of the operation to be performed on the resource. Instead, the response contains decisions related to the request that was previously represented in the same format. The response may be allowed, denied, uncertain (in the case of errors or missing values) or inapplicable (request to override any policy). The access decision process is based on policies and policy sets. A policy set is a collection of policies or other policy sets. Instead, each policy contains a target and a set of rules. The goal is a set of simplified conditions on users, resources, and operations that must be satisfied before a policy can be applied to a request. Each rule represents an internal target (only associated with the rule) and a condition that represents a boolean function over any complex combination of functions on a set of attributes. Upon request, the target and the rule are evaluated with the current attribute value to return a decision. Since a policy set may contain multiple policies, each returning an access decision, while the policy itself may contain multiple rules, each returning a potentially different result, all of these decisions need to be correctly combined to obtain the final result. This is achieved by a combination algorithm, either at the policy set hierarchical level (i.e., a policy combination algorithm) or at the policy hierarchical level (i.e., a rule combination algorithm). Each algorithm defines a method of appropriately combining the results of different individual evaluations to generate a unique authorization decision. For example, one of the algorithms is an overwrite-enabled algorithm. It states that if at least one component (rule or policy) returns an allowance, the end result is an allowance. In XACML, few combinatorial algorithms are available as criteria, but more algorithms can be defined themselves as needed.

XACML is not only capable of representing policies and requests/responses, but also provides a corresponding architecture, as shown in fig. 1:

1. policy Enforcement point PEP (policy Enforcement point)

The policy enforcement point PEP is a component paired with the resource to be protected, which is able to intercept and suspend access requests in order to perform policy evaluation. In particular, the PEP collects access requests and a set of available attributes, which triggers the decision process and enforces the relevant results by actually allowing or denying the execution of the access;

2. policy Administration Point PAP (policy Administration Point)

The policy management point PAP is a component responsible for managing access control policies. Its main function is to act as a policy repository storing policies in order to retrieve them when evaluating access requests. Another related function of PAP involves policy authoring, thereby assisting its users (i.e., the policy maker) in creating and modifying policies. PAP can also support more sophisticated policy making and management functions;

3. attribute manager AM (Attribute manager)

The property manager AM is a component that actually manages the properties of the user, resource and environment, allowing the access control system to retrieve and update their values. Each application scenario has its specific AM, depending on the attributes associated with the scenario. The AM may be part of the authorization service itself, may run on other computers in the same domain, may run in other administrative domains, or may even be run by a third party. Existing services can be utilized as AM;

4. policy Information Point PIP (policy Information points)

In most cases, the set of attributes required for policy evaluation is managed by a set of different AMs, each AM having its own protocol for collecting current attribute values. The policy information point PIP acts as a plug-in to the access control system, providing an interface to interact with each property manager, allowing retrieval and updating of the latest values of the properties;

5. policy Decision point PDP (policy Decision Point)

The policy decision point PDP is an evaluation engine. It takes policy, access request and current attribute values as inputs, evaluates the policy and returns the relevant access decision (i.e., allowed, denied, uncertain or not applicable);

6. context handler CH (context handler)

The context handler CH is a component that acts as an orchestrator of the decision flow, interacting with other (previously described) components of the architecture to manage the workflow of the decision flow.

With respect to the block chain technique, the following will be described:

blockchain technology allows the construction of an immutable, distributed, always available, secure, publicly accessible database (ledger). It relies on a distributed consensus protocol (consensus) to manage this repository in a distributed manner (e.g., to decide which valid new data to add). The different types of blockchains differ substantially in the level of trust associated with write and read operations. A write operation refers to the ability to update the ledger, i.e. write a new piece of content on the ledger, while a read operation refers to the ability to read existing content. Historically, blockchain techniques were introduced at the earliest to support cryptocurrency. In this case, the blockchain is used as a common ledger to store transactions (transactions) that transfer value between entities. Bitcoin cryptocurrency protocols were used on the first blockchain at the earliest, but since then some interesting new open source blockchain software has emerged. In this application, one of them, etherhouse (Ethereum) is used. In the present application, a basic understanding of the protocol is provided, omitting most of the implementation details that are not relevant to the present application.

EtherFang began with a simple assumption that bitcoin style cryptocurrency was coupled with Turing's full application. Because of the ethernet currency on which the protocol is based, it can still be considered a cryptocurrency. The way value management is expressed in ethernet coins is in principle not much different from the way value is managed in bitcoin. The system exchanges values based on pseudonymous entities (masked by addresses) through special data structures called transactions, which are broadcast to the underlying communication network. These transactions are eventually validated and then their effects are applied by updating the global state (record value is passed to the new owner). Since the reference scenario is an untrusted distributed system, a distributed coherency algorithm is required to reach a protocol where a new transaction is considered valid. Like bitcoin, the distributed coherency algorithm currently used is based on PoW (Proof-of-Work), even though different coherency algorithm schemes have been proposed. Pending transactions (i.e., transactions waiting to be validated) are grouped by the validator node (called miners) into a data structure called a block. One of the miners (miners) will eventually win the PoW consensus competition, whose block will be securely added to the globally recognized chain of blocks (i.e., the block and the Transaction transactions it contains may be said to have been mined). This chain of blocks determines the global state to which each new block addition is an update.

A new contribution of the etherhouse protocol is to use not only blockchain storage value transfer, but also code programs. In addition to traditional value exchange transactions, users may also create transactions with executable turing/computer full code programs. Those code programs deployed on blockchains are referred to as intelligent contracts. The transaction carrying the contract payload is first broadcast to the network. The result is that the load is deployed as a code program linked by its public address. Any new transaction may then refer to this address to trigger execution of a function within the contract, carry the function parameters within the transaction payload, and display the final return value to the outside. Basically, a smart contract contains some data storage space and some callable functions. The smart contracts themselves may create new contracts like ordinary users and send payments or function calls between them. Validating (e.g., adding it to a block) a transaction that contains a code program (calling a contract function or deploying a new contract) means executing such a code program and updating the global state accordingly. This means that the global state can be viewed as a virtual machine (called etherhouse virtual machine etheremum vm or EVM) running all code programs on the blockchain. At the same time, the miners (miner) who added the transaction with the code program to all the directed blocks actually executed the code program, so the code program execution was replicated among all the miners (miner). The intelligent contract is written in a low level bytecode language interpreted by the EVM. High-level languages have also been developed whose programs can be compiled with EVM bytecode (generating a.bin file containing compiled contract binary files and a. abi file containing contract interface specifications) to simplify the encoding procedure of human intelligent contracts. The most common of these languages is a JavaScript style language called Solidity.

It must be noted that each transaction must pay a fee proportional to its complexity to reimburse miners (miner) for the effort of maintaining the EVM. Each operation of the EVM is assigned (via a protocol) a price proportional to its burden on the user (i.e., the number of computational steps required to perform it and its stored weight), called gas, and the total gas of a transaction is the sum of all the gas of each instruction it contains. This is the gas consumed by the authentication transaction. The entity (user or contract) that creates the transaction needs to determine two parameters, namely the gas limit and the gas price. The gas quota is the maximum amount of gas that a transaction is allowed to consume, and if this quota is exceeded, all of the gas is consumed, but the execution impact on the state is eliminated. This helps to avoid stalling the EVM by too long or even infinite calculations. In addition, a block gas quota is associated with each block to guarantee that all transactions in that block execute a computational quota. The gas price is set by the user as the amount the user is willing to pay per unit of gas. Miners (miner) can freely choose which kind of miners (miner) transaction, so they can reject transactions with a gas price that is too low.

The application provides a new application scenario of an access control system based on a block chain. In this reference scenario, the resources that are desired to be protected by the access control system of the present application are intelligent contracts deployed and executed on the same blockchain. For clarity, this application refers to these smart contracts as smart resources. And it is noted that no assumptions are made about intelligent resources, i.e. they can be contracts of any kind, the execution of which needs to be protected by the access control system for reasons that are not relevant here. The access control system is independent of the particular operation that the smart resource implements (even though of course the access rights of the operation are represented by policies defined for the particular smart resource). Further, it is noted that in the present application, the term smart resources is used to emphasize that the entity being controlled as a resource is actually an intelligent contract. It is pointed out at this point that smart resources should not be mistaken for smart devices, i.e. connected devices capable of autonomous operation.

An access control policy example of a scenario may control access to operations provided by contracts that manage and maintain payment and financial records for an enterprise. For example, on the attributes of a user, resource, or environment, it may be a condition that only a recognized accountant can update a corporate balance sheet, employees can require payouts only after completing certain tasks assigned to them, and corporate managers can require bonuses only under certain external objectives (e.g., corporate share prices rising above a certain threshold).

In this case, the access control system based on the block chain has the following advantages:

1. the intelligent resource creator is relieved of the effort to design and develop specific code programs for managing access control. Notably, the method of the present application also eliminates the effort of an intelligent contract creator to rewrite the access control logic embedded in their smart resource code program each time the corresponding access control policy changes. In addition, the application can automatically embed the access control logic into the intelligent resource without the effort of an intelligent contract creator;

2. the access control logic is clearly separated from the intelligent resource logic. This simplifies the smart resource owner and the access requesting user proving that the access control policy actually implemented is actually the policy declared by the smart resource owner. In addition, updating when the strategy is changed is also simplified. Since the intelligent resources and access control logic and decisions are stored on the blockchain, the access requesting agent or user can examine the transactions recorded on the blockchain to verify the cause of any access decisions and protect them from improper denial of access.

The basic idea of the method of the present application is to utilize a blockchain to store access control policies and management attributes and to perform an access decision process, i.e. to evaluate the relevant policies utilizing the required attributes whenever an access control request is issued by a user wishing to access a resource. The present application represents access control policies by intelligent contracts, called intelligent policies, created by an enterprise that is the owner of digital resources and stored on a blockchain by appropriate transactions. Since the blockchain is an only additional ledger, once uploaded, the intelligent policy will always be stored on the blockchain. However, it may be logically replaced by simply uploading a new blockchain on the blockchain, or even disabled by an appropriate transaction. The execution of the access decision process also utilizes blockchains. In fact, each time a user issues an access request, an appropriate message is issued on the blockchain to trigger the execution of the intelligent policy. This message results in the evaluation of the intelligent policy and the generation of relevant access decisions (e.g., allow or deny). The evaluation of such policies is performed entirely on the blockchain. For simplicity, the present application states "intelligent policy evaluation is performed on blockchains," which means that intelligent policy execution is replicated between miners (miners).

How to represent the access control policies, how to create and store them on the blockchain, how to revoke or update them, and how to evaluate them by retrieving the required attributes to generate access decisions will be described in detail below. The architectural components of the present application are defined on the basis of blockchain technology, as shown in fig. 2.

It is apparent that the type of resource to be protected can affect the structure of the policy enforcement module responsible for interacting with it, as well as the structure of other components of the system. For example, if the resource to be protected is an intelligent contract, the policy enforcement module will be part of such an intelligent contract. However, some components of the architecture are not dependent on the application scenario, either being placed at the off-chain front end or in the blockchain environment of fig. 2 on-chain. Scenario-related components are depicted in a "scenario-dependent" box as shown in fig. 2, as they may be placed on-chain or off-chain (possibly split between the two) depending on the particular characteristics of the application scenario. Note that the downlinker front end can be deployed on the resource to be protected, as well as on a trusted third party to the resource.

Further, note that the architecture of a blockchain-based access control system is typically independent of the particular underlying blockchain technology selected, provided that such blockchains support intelligent contracts. However, although the use of the present application does not require technical knowledge of the underlying blockchain technique, the user may need to provide some further blockchain related information. For example, in an implementation based on an etherhouse blockchain, a payment of gas is required. This means that the user does need to have a wallet to use the application and provide (non-private) information about the wallet and the information needed to perform additional operations, such as signing blockchain transactions.

1. Data storage library

In this application, attributes representing user, resource, and environmental characteristics are also stored on the blockchain and managed by a set of intelligent contracts. In this way, the advantages of the blockchain can also be utilized for attribute management. In fact, the values of the attributes are not alterable, since they are stored on the blockchain, and they are auditable, since their updating can only be performed by blockchain transactions, which are also recorded on the blockchain. After XACML naming, contracts that store attribute sets can be viewed as data stores, and therefore, they are referred to as intelligent data stores. In the present application, it is assumed that there is an ecosystem of data stores deployed and maintained by third parties, for example, an intelligent contract for an enterprise may provide public information about its employees (e.g., their roles). The data repository may also require some form of payment (either on-chain or off-chain) to use its services, and thus the data repository market naturally occurs. The data repository is invoked by the intelligent policy to retrieve the current values of the attributes it manages. Invoking the intelligent policy portion of the data store may be viewed as an acquisition module.

2. Intelligent contract

Smart contracts, also known as smart policies. The solution provided by the present application focuses primarily on the ABAC policy, although it is believed that it can be easily extended to cover other access control models. The ABAC policy consists of a set of rules that are conditional on attributes representing the access context, which are combined together by a suitable combining algorithm, and which must be satisfied accordingly to grant the requested access rights. XACML is employed for policy writing because it is a very expressive language, allowing complex ABAC policies to be written. In addition, since it is a well-known standard, some tools for policy editing and management are available. In the present application, the XACML policy is correctly converted into an intelligent contract, called intelligent policy, in order to store and execute it on the blockchain. An intelligent policy can be viewed as an executable version of the XACML policy, in other words, after XACML naming, it can be said at all that the intelligent policy embeds an index server that customizes the access path for executing a particular XACML policy and the acquisition modules needed to collect the policy attribute values.

The intelligent strategy creation process includes three steps:

1) compiling XACML strategy;

2) policy transformation from XACML to smart contracts;

3) such contracts are deployed over blockchains. Policy writing is performed by the enterprise, who is the owner of the digital resource, using existing XACML editing tools. The second operation involves policy management and is therefore taken care of by the policy management module. In contrast, intelligent policy deployment requires interaction with the blockchain, so this functionality is delegated to the forwarding module.

The life cycle of the intelligent policy begins when an enterprise, as the owner of a digital resource, writes a new XACML policy to define the access rights of its resource and submits it to the policy management module. The policy transformation module is a sub-module of the policy management module that transforms the logic represented by the XACML policy into an intelligent policy. An intelligent policy is not simply a rewrite of the XACML policy, but it also contains all the logic (i.e., executable code program) that implements the policy evaluation. For example, each XACML statement that references an attribute translates into inserting a function call in the smart contract to retrieve the current attribute value from the corresponding data store each time the smart policy is invoked. This is possible because in the method of the present application, the data store is also represented as an intelligent contract stored on a blockchain. Predicate sets on attribute values contained in the rules are also converted into executable code programs, and intelligent policies include logic that combines the results provided by the rules into a single decision (allow or deny). To summarize, encoding policies as intelligent policies allows block chain executable policies to be written from XACML policies. The intelligent policy is delegated to the index server and collection module, and the forwarding module, which also has some scheduling functions in fig. 2.

Once converted, the intelligent policy is deployed on the blockchain by the forwarding module responsible for issuing policy conversion transactions. The expenses associated with intelligent policy deployment are paid by the policy creator, since the policy creator is an entity or user defined to have access control over the resource.

An enterprise as the owner of the digital resource may decide to revoke its intelligent policy at any time. This is achieved in the present application by inserting a self-destruction function in the intelligent strategy. Contracts enforce constraints that only the enterprise that is the owner of the digital resource (i.e., the creator of the contract) is allowed to invoke this function by issuing policy Update transactions, PUTrans (policy Update transactions). Because businesses that are owners of digital resources are the people who issue revocation operations, they also pay the cost of revocation policies. Note that in most blockchain technologies currently available, the blockchain is immutable, so the smart contract is not actually removed from the chain, but it is only disabled, allowing audits. In fact, in this case, the intelligent policy is marked as being non-invokable, so future invocations of the contract will fail as expected, but at the same time, the actual contract is still publicly visible in the chain.

Updating an intelligent policy means changing the relevant intelligent contract. Also, blockchains typically do not allow the code program of the intelligent contract to be altered. Thus, updating an intelligent contract (e.g., an intelligent policy) simply means deploying a new intelligent contract and using its new address wherever needed, rather than the previous address.

The intelligent policy evaluation is performed each time a user attempts to access a protected resource, causing the policy enforcement module to invoke the blockchain based access control system. To trigger the execution of the intelligent policy, the policy enforcement module creates an access request and sends it to the forwarding module, which in turn invokes the intelligent policy.

In some cases, the forwarding module is external to the blockchain (the policy enforcement module may also be external). Thus, the forwarding module creates a transaction called a policy evaluation transaction (PETRans) and submits it to the blockchain. In other scenarios, both the policy enforcement module and the forwarding module are on the blockchain (i.e., they are also embedded in the smart contract). In this case, the forwarding module sends a message (typically a smart contract function call) to the smart policy using a blockchain communication mechanism. Although in a different form than a transaction (which can only be created by an external account), this message has the same task and effect, so in both cases the subsequent evaluation process is exactly the same.

Evaluating a transaction (or message) triggers a main () method that executes an intelligent policy that coordinates the execution of the policy evaluation process. In particular, updated values for all attributes required to evaluate a policy are collected. This phase is performed by the acquisition module implementing the functions of the intelligent strategy. These functions issue messages that trigger the execution of the data store corresponding to the desired attributes. The retrieved attribute values are then used to perform a function corresponding to the index server customized for the particular policy. This will generate a decision to return as a result of the policy evaluation. Note that the attribute values are retrieved in a lazy manner, i.e., they are retrieved only when needed for function evaluation. The present application selects a lazy solution to minimize the number of external calls performed by the intelligent policy. In fact, each attribute is generally retrieved by calling a different contract (corresponding data store), an expensive operation (in terms of cost consumed) that is simply not useful if the value is not actually used. Lazy attribute value retrieval allows for cheaper and faster policy evaluation.

The cost of the evaluation process is paid by the user making the access request (as the user will be the entity that benefits from the granted access). This may prevent users from sending spam requests to the system, as they are limited in their value. This also means that the user needs to manage the wallet holding value on the underlying blockchain and to interact with the access control system (e.g. for signing transactions) to verify payment of the required fees.

In one embodiment, the EtherFang blockchain protocol was chosen because it fits well into the Smart contracts and is now a widely used blockchain. Then select identity as the programming language to write the intelligent contract and select Java to write the part of the framework under the chain. For the Java client to interact with geth, the Java library of Web3j is used. Web3j is a lightweight library that supports all of the JSON-RPC APIs provided by geth. It also allows Java smart contract function wrappers to be automatically created from the identity ABI files.

The component responsible for intelligent policy transformation is a policy transformation module. The policy transformation module is written in java, whose task is to transform the XACML policy written by the enterprise as the owner of the digital resource into a Solidity intelligence contract.

How the XACML policy is converted to Solidity to generate the body of the evaluated function will be shown below. However, smart policies also contain some utility functions that are the same for all policies (e.g., invoking a self-destruction function to override the smart policy).

XACML policies consist of a policy target and a set of rules, each including their target and conditions, and focus on the transformation of policy targets and rules because the conditions of the transformation are very similar. The goal is a combination of < Match … </Match > elements, each of which will be referred to as MatchE in the following work. Each MatchE is converted to a check instruction that is embedded in the evaluate function. The Solidity function used to implement the check instruction is derived from the XACML MatchId field and the data type is derived from XACML. The data type fields of < AttributeValue > and < AttributeDesignator >. The check to be performed requires access to the current value of the attribute at the time of the request. Therefore, the intelligent policy must also be able to retrieve these values in order to calculate the decision result. In the application, the acquisition module function in the intelligent strategy is integrated into the data repository through the intelligent contract message. Any enterprise that is the owner of the digital resource that creates a new policy needs to specify the data store to query in the policy to retrieve the required attribute values. To this end, for each MatchE, the enterprise, as the owner of the digital resource, selects the data repository to be invoked by specifying in the < attributedesignesignesigner > tag the name of the data repository function through the attributeld field and the address of the data repository through the issue field. Each MatchE returns a boolean result that is correctly combined by the concatenation or disjunction defined by the policy by the tags < AllOf > and < AnyOf >, respectively. In fig. 3, an example of how components of an XACML policy are converted into smart contracts for corresponding smart policies is shown.

Note that this process is theoretically applicable to any type of MatchE, converting any possible XACML policy into an intelligent policy. In practice, this may not be feasible because of technical limitations in the intelligent contract programming language employed or the underlying blockchain used to run them. For example, the Solidity language employed herein has well-known limitations in processing dynamic arrays (e.g., returning arrays of strings between function calls). Thus, the parser of embodiments of the present application is designed to convert some simple operands and data types (e.g., operands over a set of values are not considered) that allow for some common ABAC policies to be expressed. Performing more complex operations on more complex data types may result in more complex checks, which in turn results in more expensive intelligent contracts. In general, any XACML operation and data type can be represented by designing or using the appropriate libraries, so long as the underlying blockchain supports it, thereby preserving the versatility of the scheme. The smart contracts may call library functions (defined by library smart contracts, if necessary) like ordinary programs. Special libraries may be written and built for different data types and operations.

Finally, the evaluation function needs to return the result of the decision process. One solution is to simply save the results as data in the contracted state, but the application chooses to trigger an event that contains the request id (i.e., the transaction id encoding the program access request) and the corresponding result. Events are data saved in the EVM log, not contract memory space, and the result of returning an evaluation function with them is a cheaper way to store the decisions for each request, at the cost of making them invisible and therefore unavailable to contracts.

An important description of the resolver is provided below. Since XACML is derived from XML, the parser is implemented as a classical XML parser. Therefore, it has a linear computational complexity. However, performing it on the ether house blockchain is too resource intensive. For any policy (except the simplest policy), execution of the parser may cause an exception (i.e., an error that occurs when execution exceeds the blocking gas limit). Furthermore, assume that the smart contract executing the parser can deploy itself without raising a gas exception; even if the parser can be deployed and executed as an intelligent contract, it can be very expensive to pass the XACML policy to it as a parameter of its execution. XACML is a very verbose language, and message size is a scarce and expensive resource on the blockchain. In summary, implementation and execution of resolvers via smart contracts on blockchains does not yield any real advantage, while being undoubtedly cumbersome for the entire blockchain community and expensive for individual users. The user can check the parser results (i.e. the smart policy code program) before deployment so any errors or fraudulent activity of the parser can be detected and prevented. Furthermore, once the parser is deployed, the user of any other given intelligent policy code program can check whether it represents a certain XACML policy by running the parser itself and checking whether the results obtained match. In this way, any user can verify that the enterprise that is the owner of the digital resource is protecting their resource using the policy they claim to be (if challenged, publish the required information to prove that they have no fraudulent intent in line with the interests of the owner of the resource) by checking the corresponding intelligent policy code program.

To further illustrate the present application, the embodiment of FIG. 2 will be described in detail below. In this case, the resource to be protected is an intelligent contract, called smart resource, deployed on a blockchain, the owner being the author of such a contract. In contrast, subjects are blockchain users who call intelligent resources to benefit from the functionality provided. The operations that a principal may perform on a smart resource are represented by calls to functions provided by its smart contract. In order to protect their intelligent resources, owners want certain critical functions to be performed only by the subject who owns the corresponding rights. Thus, to define these permissions, the smart resource owner defines a set of XACML policies, where each policy defines the permissions to access a function of the smart resource. In particular, each of these XACML policies specifies rules and conditions that apply only to a particular function of a particular smart resource, because the target portion of each of these policies contains a predicate that is satisfied when the value of the attribute resource _ id is equal to the address of the smart resource, and the action _ id attribute is equal to the name of the function that the policy references. Note that this would not prevent the resource owner from defining multiple policies that apply to the same action _ id attribute value, nor would it prevent a policy with multiple rules that apply to the same action _ id attribute value, since it would be a valid XACML policy set. As usual, XACML policy and rule combination algorithms will resolve possible conflicts between these policies and rules. Furthermore, the system still accepts any valid XACML policies, so no policy and its rules are needed to specify the limits on the attribute action _ id values. If no restrictions on a particular action _ id value, i.e., on a particular function of the smart resource, are defined, the policy/rule will control access to all functions of the smart resource.

In this embodiment, the intelligent contracts developed on the Etherhouse blockchain, are programmed in a reliable manner, with the lower end of the chain written in Java, and the geth node accessed through the web3j is bridged over the blockchain. As shown in fig. 2, the implementation of each component in the present embodiment will be described below.

Block chain based access control systems aim at easy integration into existing scenarios by integrating policy enforcement modules into the access interfaces of protected resources. In an embodiment scenario, the code program that implements the policy enforcement module task is embedded into the code program of the smart resource itself. In particular, each function of the smart resource that needs to be protected must invoke the access control system of the present application as a first operation to perform an evaluation of the access control policy, i.e. it must issue a policy evaluation message to trigger the execution of the smart policy associated with the smart resource. Therefore, the address of the smart policy must be directly embedded into the policy enforcement module that invokes such policy evaluation, thereby playing the role of the policy management module (i.e., policy retrieval). In other words, it can be said that a part of the policy management module also runs on the blockchain. The decision returned by the intelligent policy will determine whether to execute the actual code program of the intelligent resource function. The policy management module of the present application is the component responsible for policy management and retrieval. The main task of the access control system based on the blockchain is to convert XACML policies written by the resource owner into intelligent policies and to manage the mapping between the resources and the related intelligent policies to allow them to be invoked on the blockchain. In an intelligent resource scenario, the policy management module tasks related to intelligent policy creation are performed by modules outside the blockchain (i.e., the down-chain policy management modules it runs within the blockchain access control system front-end). This component is also responsible for inlining the policy enforcement module code program into the smart resource, which in effect includes creating a message (not shown in fig. 2) that triggers the execution of an evaluation function of the smart policy by an appropriate add-on module named resource inlining point. To do so, the under-chain policy management module requires input of a smart resource contract code program and a corresponding XACML policy. Then, the strategy conversion module generates the intelligent strategy and correctly embeds the calling of the intelligent strategy in the intelligent resource function through the RIP. Of course, the intelligent policy needs to be deployed on the blockchain first in order to retrieve its address to embed in the modified intelligent resource code program. Note that the deployment phase may choose to be performed directly by the resource owner, rather than by the forwarding module, using only the front end as a conversion tool to make this approach preferable.

Alternatively, the under-chain policy management module may also be implemented as an intelligent contract and deployed on the blockchain. This would not require a forwarding module and therefore the entire system would reside on the chain.

In one embodiment, RIP utilizes the concept of function modifiers provided by the solid programming language to embed policy enforcement module functionality into smart resources. In Solidity, function modifiers are used to wrap functions around a given code program. The execution of the function may be controlled by creating modifiers containing checks at the beginning and stopping execution when a require function identity construct fails. To this end, the present application provides a fixed-base contract named linker that acts as a bridge between intelligent resources and intelligent policies. It contains a constructor that requires the address of the intelligent policy as a parameter to enforce the link between the policy and the resource. A modifier is then defined for enforcing the access request computation. This modifier only calls the evaluate function of the intelligent policy and stops execution if false is returned. The smart resource contract need only specify that it inherits from the linker and adds modifiers to the signature of each function, not just the key functions.

The forwarding module manages access to the blockchain on behalf of the policy management module and the policy enforcement module, respectively. At policy creation time, the forwarding module receives an intelligent policy written in Solidity from the policy management module and compiles the Solidity code program into EVM bytecode using a solc compiler. The forwarding module then wraps it into a transaction using web3j for deployment through the geth node onto the chain of ether house blocks. At this stage, the forwarding module may choose to perform additional checks on the contract deployment transaction. For example, it may query the blockchain (using the geth node) to check whether the policy creator has sufficient credit in his account to pay the expected gas cost, or it may check whether the data store invoked by the intelligent policy is actually present on the chain.

Notably, the contract deployment transaction needs to be signed by the paying user. In particular, once a transaction is ready to be signed, the resource owner can see it (possibly with an automated tool), sign it, and then pass the signed transaction back. In this embodiment, the user interacts with the system through an interactive interface, first asking the user to insert the policy to be added, and then notifying them of the derived smart contract and the associated deployment transaction waiting to be signed. The user can then check whether the transaction correctly represents the policy they want and, if they are satisfied, can communicate with the signed version of the transaction. Once the forwarding module receives the signed transactions, it checks the signatures and if they are correct, it sends them to the geth node for broadcast to the ethernet communication network.

The forwarding module receives an acknowledgement or error message depending on whether the deployment was successful. This method ensures that private information of the user's wallet is not revealed to the framework system. Once the transaction is actually inserted into the block by the miners (miner), i.e. the intelligent policy is on the block chain, the forwarding module receives the contract address from geth, which is returned to the under-chain policy management module and then embedded into the intelligent resource code program by RIP. Note how RIP requires such an address to instantiate a linker correctly, so it is necessary to deploy intelligent policies before intelligent resources. This is semantically correct because it prevents the owner from deploying unprotected resources.

In contrast, in the smart resource scenario, the role of the forwarding module is minimal, since the code program in the smart resource that is in-line by RIP calls the execution of the appropriate smart policy, and actually implements the functions of the policy execution module and forwarding module of the generic architecture together by a identity modifier.

The original traditional functions of the index server and the acquisition module are combined into an intelligent strategy. This contract is dynamically generated by the policy management module from the XACML policy and, once deployed, resides on the chain of etherhouse blocks in the EVM bytecode. As previously described, the decision process of the index server is implemented by non-centralized execution of the evaluation function of the contract, and attribute value retrieval is performed directly to the datastore on the same chain by a function call of the contract. All communication is achieved through intelligent contract function calls and event triggers, which are implicitly managed by the etherhouse protocol.

The main advantage of the present application is that the policy management and evaluation process is performed on the blockchain, which makes the present application inherit the technical advantages of blockchain, i.e. it is auditable, high availability, distributed (and thus no single point of failure or attack), tamper resistant, etc.

Since the execution of the intelligent policy contract is performed by the blockchain, it is out of the control of the enterprise as the owner of the digital resource and the subject of the request. They cannot forge the wrong decisions. More importantly, the policies that have been executed and the associated evaluation results are stored on the blockchain for each access request, thereby allowing for auditability. Thus, any user whose access request is fraudulently denied by the resource owner can use the data stored on the blockchain to prove that access should be granted. Since the blockchain is immutable, even if the intelligent policy is revoked, its code program and the entire access request log are still stored on the blockchain and accessible. Thus, long-term auditability is supported.

This is a related advantage of running an access control system on the premises of the enterprise as the owner of the digital resource. In fact, the blockchain represents a trusted execution environment for performing the decision-making process and a trusted storage system for storing result access decisions. Instead, running the access control system at the site of the resource owner will enable him to modify the execution of the decision-making process, thereby forging a false access decision and/or storing a decision in the access log that is different from the actual evaluation of the policy. It is clear that if on the one hand the application is employed it would be relieved of the responsibility of the resource owner to install and manage the access control system at his site, on the other hand it may bring some cost to the blockchain transaction (for example, in the case of the etherhouse protocol, the gas cost is required to deploy and execute the intelligent contracts).

Deploying and executing the access control system described herein with a licensed blockchain (e.g., Hyperridge Fabric) is a possible solution to reduce such costs. In fact, introducing a trust level allows the use of less complex, less costly distributed consistency algorithms by allowing only trusted miners (miners) to add new blocks in the chain. Furthermore, if fully publicly priced, the cryptocurrency supported by the licensed blockchain is not expected to experience high price fluctuations, and therefore it is more stable and predictable even from a pure currency perspective. It has to be noted that in the present application auditability relates to the storage and evaluation of access control policies, i.e. policies that have been uploaded onto the blockchain and decisions that have been made regarding rights to access resources. With respect to the issue of performing these decisions, the key component in actually performing the decisions is the policy enforcement module. If the resource to be protected is a conventional digital resource, the policy enforcement module will not be deployed on the blockchain. Thus, the actual implementation stage does not benefit from the advantages of blockchains, including auditability. Thus, the policy enforcement module may fraudulently ignore access decisions received from the block link and may even discard access requests to avoid invoking evaluation of the intelligent policy, e.g., due to a malicious resource owner. In contrast, in the intelligent resource scenario described in one embodiment, both the policy enforcement module and the resource to be protected are located on the blockchain, thus allowing the policy enforcement module code program to check and access the auditability of decision enforcement.

It is clear that the present application does not relieve the resource owner of the responsibility of taking other typical security measures on their resources depending on the type of resource (e.g., for the server, please install all the newly available security patches to the operating system immediately).

One obvious consequence of auditability is a potential privacy issue. In practice, the access control policy, the access request and the associated access decision are stored on the blockchain. The use of a public blockchain means that all users of the blockchain can read this data and all miners (miners) can read it in order to execute the intelligent policy contract when invoked. The only anonymity protection mechanism provided by most blockchain protocols today is the use of pseudonyms. This property is weaker than proper anonymity, which ensures that a user can participate in a protocol that is hidden behind any number of randomly generated identifiers that do not carry any information between them, nor information about the identity of the user.

Due to the pseudonym property, access requests and related access decisions, although open access is possible, are not directly tied to the true identity of the user performing the request, but only to their anonymous ID. However, in some access control scenarios, some participants need to know the true identity of the user, conflicting with the user's pseudonym. For example, an enterprise that is the owner of digital resources should know which ids have been assigned to those users for which they should enforce policies based on identity. Furthermore, in some cases, some attribute providers (i.e., entities that own a data store to maintain user attributes) should also know the true user identity, since these entities must assign the correct attribute values for each ID, and must update these values if necessary.

In addition, some methods for breaking the user pseudonym are proposed in the prior art, which are mainly based on the pseudonym behavior on the block chain. The most studied so-called unsigned attacks mainly involve bitcoin protocols and rely on heuristic rule based clustering to try to group together all pseudonym IDs belonging to the same user, but similar approaches are possible for similar blockchain protocols.

If the access control system provided herein restricts access to smart contracts, privacy related to access control events is not a concern of the present application. In fact, the resources protected by the present application are intelligent contracts, and therefore their invocation and execution have been registered on the blockchain. Thus, in this case, the present application does not introduce more major privacy issues than have been accepted using the selected blockchain protocol. It is noted here that auditability and privacy issues are both sides of a coin, as they both stem from blockchain techniques, i.e. storing information in a tamper-free and publicly accessible manner. Thus, the desired system transparency should not be hampered when attempting to address privacy concerns. This can be achieved by restricting access to given information by interested parties, the simplest method being to use a private blockchain. In such a system, write (adding new blocks to the chain) and read (accessing information stored in the blocks) operations are limited to trusted parties only. Even though data may be encrypted in the private chain to further restrict access to information to other parties, there is still a sufficient number of miners (miners) to be able to recognize such information in order to process it effectively and clearly. Since such a private blockchain does not solve the general problem, it will limit itself to replacing this problem with the need of a trusted third party.

If the information is also ambiguous to the miners (miners), they cannot check their meaning and therefore they cannot guarantee their content. To achieve a consistent chain without revealing information, complex encryption techniques are required. For example, homomorphic encryption can be used to process encrypted data without first decrypting. Alternatively, zero knowledge proof may be used to ensure that certain constraints are enforced without revealing private information. Unfortunately, the main problem with this approach is often their price. For example, homomorphic encryption is still expensive for complex computations. Note that some notable exceptions to the privacy aware blockchain are available.

Currently, the main approach to achieving privacy in the presence of smart contracts is to simply encrypt the contract data and calls, storing only such fuzzy information on the chain (either directly or through cryptographic hashes).

It is noted here that if the intelligent resource outsources a third party, this means that the user must rely on the third party service to write all the access control logic. However, this does not impose strict trust requirements on such third parties. In fact, the service should build an intelligent policy and integrate an intelligent resource contract, but it requires user approval (i.e., its signature) to deploy. This means that the user can check before deployment whether the service is malicious and, if not satisfied, can stop the deployment at any time.

Such code writing of the present application has significant advantages in terms of user effort and avoidance of errors. Since the intelligent policy is automatically generated and linked to the intelligent resource, any human error can be avoided. Furthermore, since the user does not have to write an implementation of the access control contract, but instead relies on a solution that statically writes programs, checking for contract security is easier and more versatile. Of course, this may also result in fewer errors in the general intelligent resource implementation, as the user may focus all of his efforts and attention on the access rules logic on the access control side. Finally, the modularity introduced when separating the control logic from the intelligent contract to be controlled allows two contracts to be deployed and managed separately. Since this results in two different transactions, this means that a more costly contract is deployable because the two transactions may fit into different blocks even though their total cost is greater than the block gas limit.

The complexity of the intelligent strategy depends on the number of matches in the original XACML strategy and their respective complexity (depending on the operation and data type of the individual matches). The present application is the conversion of an entire XACML policy into a single intelligent contract. In general, block chain protocols employ techniques to price and charge for scarce resources (e.g., storage and computation) on the chain by scaling. In such a scenario, as XACML policies increase in complexity, the corresponding smart policies become more expensive in terms of cost. Most blockchain protocols have a limit on the maximum block size (primarily to ensure reasonable block propagation times between peers), and therefore have a hard limit on transaction size. This introduces a hard limit on the maximum size (i.e., complexity) of the smart contracts (including the intelligent policies deployed and executed), which in turn limits the maximum complexity of XACML policies supported by the system. For example, in one embodiment, the application is developed at an Etherhouse that uses mandatory gas consumption to pay for transactions and limits the size of each block by specifying a block gas quota (i.e., the maximum cumulative gas allowed to be consumed by all transactions in that block). Thus, the complexity of the XACML policy that can be expressed is limited by the current block gas quota of the etherhouse blockchain.

However, it is easy to circumvent this since the policy complexity constraint comes from the underlying blockchain protocol, not the application itself. In fact, XACML policies of arbitrary complexity can be managed by splitting the generated intelligent policies into a plurality of intelligent contracts, i.e. enhancing the policy transformation module, in order to transform XACML policies in a set of interconnected intelligent contracts. Since the complexity of a policy depends on the MatchE it implements, which is converted into a check inside the evaluation function of the smart policy, it is sufficient to split the evaluation function check between different contracts. A corresponding intelligent policy is represented by a set of intelligent contracts, rather than a single contract, which would contain one main intelligent contract as the entry point for invoking the evaluation function and other functions, while the body of the evaluation function would contain an external call to a second intelligent contract, responsible for computing only the MatchE part of the policy, invoking a third party contract to compute another part of MatchE, and so on, until all matches in the original policy are implemented by intelligent contracts. The last intelligent contract returns a result that is passed to the caller, which combines it with the result of evaluating its portion of MatchE, and passes this new result to the caller, and so on, until the result is returned to the master intelligent policy intelligent contract that ultimately returns a global result.

Of course, this process can be efficiently designed to allow calls to be evaluated as short as possible. Only the policy transformation module needs to be changed because once deployed, the master smart policy contract is still the only point to trigger policy evaluation. Splitting the intelligent policy into different contracts is transparent to other modules of the system. As long as the individual contracts representing smart policies are individually smaller than the gas limit, they can be inserted into the block and any policy can be deployed. The only disadvantage is that the smart policy requires multiple deployment transactions, increasing deployment costs (since multiple transactions typically require multiple cumulative transactions). Note that in general, the latency required to validate many small transactions does not have to be increased compared to large transactions, because many small transactions can better fit into the free space available in a block, whereas large transactions must wait for a single block with a large amount of free space.

The former approach does not reduce the overall cost of intelligent policy deployment (rather, it may increase the cost). It only allows for exceeding the consumption limits of a single contract. Furthermore, the solution of the present application only relates to policy deployment and not to policy enforcement. If it is required to perform the evaluation process on the chain, it needs to be triggered by a single transaction that must respect the block gas limit.

Finally, the proposed blockchain access control system can be enhanced by introducing further functions, like delegation functions, in order to be successfully applied in more application scenarios. Delegation is a mechanism that allows a user, say a, to have another user, say B, act on his behalf, i.e. user a is enabled, and by which a user, say a, is allowed to have another user, say B, act on his behalf, i.e. user a is enabled by delegation. When a user actively performs a delegation operation (i.e., without centralized control or policy owner intervention), policy violation may result from such delegation. Thus, to specify who can delegate and avoid policy violations due to delegation, some delegation-enabled authorization systems allow a decider to specify a set of delegation authorization rules, i.e., policy rules that control who can delegate which rights to other users and/or which additional rights to other users can be delegated are obtained by delegation of each user.

To support delegation, the block chain based access control system of the present application can be modified as follows:

1. a new evaluateWithDeletation function is added in the intelligent strategy;

2. to write the evaluatewithremoval function (described below), the PTP is modified to translate the delegation authorization rules contained in the policy;

3. the policy enforcement module is also modified to allow processing of access requests with delegation;

4. the policy management module and forwarding module are enriched to handle new createdeletion requests;

5. a new intelligent entity smart delay is introduced to represent delegation on across block chains.

When user a wants to delegate the right to perform operation o on resource r to user B, it starts the createdeletion process by calling the policy management module. The policy management module requests a new createdeletion transaction (processed by the forwarding module) that deploys a new intelligent delegation on chain that contains specified delegation data, e.g., user a's ID, operation o, resource r, user B's ID, and a delegation expiration date. Since user a requests the creation of a new delegate, his cost is paid by a and is completely independent of the wisdom policy and resource owner.

To perform a delegation operation on a resource, B submits a delegation access request to the policy enforcement module, specifying a link to the intelligent delegation (i.e. the address of the corresponding intelligent contract), which link assumes that they are granted access rights. The policy enforcement module triggers the intelligent policy evaluation process by creating a transaction that calls the evaluatewithremoval function of the intelligent policy (instead of the evaluate function) and passes the intelligent delegation link as a parameter.

The evaluatewithremoval function checks if an intelligent delegation was created, retrieves the required delegation information from it, and checks them against delegation authorization rules. Note that this is possible because evaluatewithremoval is written by a modified policy transformation module that has transformed them into executable code, similar to how it transforms conventional policy rules into evaluate functions. If the delegation authorization rule is satisfied, the evaluateWithDeligation function will call the evaluate function, designate A as the requesting user, instead of B, and return an access decision accordingly.

In the above solution, instead of a simple solution of storing delegation information directly in an intelligent policy, delegation is represented using a dedicated new entity, smart delay, for two reasons: cost and safety. The use of external entities in intelligent policies may have any number of delegations without affecting the intelligent policy. Saving all delegation information in an intelligent policy would instead inflate it and could slow down the lookup operations for all users accessing it. In addition, users other than the policy owner are allowed to store data in the contract, which would expose the contract to attacks, such as denial of service attacks, by filling in with useless delegation.

The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention; all equivalent changes and modifications made according to the present invention are considered to be covered by the scope of the present invention.

Claims

1. An access control system for safe operation and maintenance management is characterized in that an intelligent Contract Smart Contract and the access control system are deployed on the same block chain; the system also comprises a data storage library, an index server module, a strategy execution module, a strategy management module, a collection module and a forwarding module;

the forwarding module functions as a scheduling component in a decision flow.

2. A security operation and maintenance management access control system as claimed in claim 1, wherein said smart contract is called smart policy.

3. The access control system of claim 2, wherein the intelligent policy further comprises the following steps:

compiling XACML strategy;

policy transformation from XACML to smart contracts;

such contracts are deployed over blockchains.