The present invention relates to access control. In particular it relates to access control using a blockchain data structure.

Computing resources such as hardware, software or combination resources are increasingly deployed in a distributed manner. Resources can include, for example: security services such as antimalware, proxy, antivirus, scanning or protective services; data storage services such as real or virtualised memories, data stores or databases; middleware services such as messaging middleware software, transaction handling software and the like;

business process automation such as commercial applications, bespoke business process software and the like; network services such as telecommunications, communication facilities, internet servers or websites; directory services such as registries; media services such as audio, video or multimedia; network access facilities; entertainment services such as computer entertainment software, video games and the like; social media services; and other resources or services as will be apparent to those skilled in the art. Distributed computing environments are environments in which computer systems, services and supporting or offered resources (whether hardware, software or a combination) are distributed physically and/or virtually with a dependence on communications networks for interoperability.

Furthermore, consumers of such resources are increasingly detached from the providers of the resources such that there may be no pre-existing relationship, knowledge or trust between consumers and providers.

Access control for computing resources is a requirement where resources are restricted. Such restrictions can be imposed, for example, to manage load or contention for resources, to ensure approval to access resources, or to secure sensitive or limited resources. Access control therefore varies by consumer such that different consumers can have different access control permissions for a particular resource. Managing access control permissions for all possible consumers is a considerable challenge for resource providers that causes considerable overhead.

To alleviate these challenges role-based access control systems can be employed by resource providers. Role-based access control is technique for regulating access to resources based on defined consumer roles. A role is a definition of a class of access for one or more users and can include a definition of access permissions, resources and the like. Accordingly, role-based access control simplifies access control management for resource providers by requiring only consumer role associations and role definitions. However, the distributed nature of computer systems and computing resources means that computing solutions are increasingly no longer under common or centralised control or administration. For example, cloud computing services can be comprised of multiple computing resources distributed across potentially many physical and/or virtualised computer systems anywhere in the world with each such system being administered separately or in groups/associations. Access control mechanisms in this context require sharing and synchronising access control data such as user roles and role definitions across all resource providers in all systems. Efficiently maintaining such shared access control information in a manner that reduces inconsistencies or synchronisation delays imposes a considerable burden for computer systems and the network.

Accordingly it would be beneficial to provide access control mechanisms that mitigates these challenges.

The present invention accordingly provides, in a first aspect, a computer implemented method of a resource provider for access control for a restricted resource in a network connected computer system, wherein a blockchain data structure accessible via the network stores digitally signed records validated by network connected miner software components including a provider record associated with the resource provider, the method comprising: identifying an access control role definition for access to the resource, the role including a specification of access permissions; receiving a request from a resource consumer for access to the resource; communicating, to the resource consumer, an indication of a quantity of a cryptocurrency required for access to the resource; in response to a determination that the required quantity of cryptocurrency is transferred to the provider record in the blockchain, the transfer being caused by a blockchain transaction including an identification of the role and the transaction being validated by a miner component, granting the consumer access to the resource in accordance with the role definition. Preferably the identification of the role in the blockchain transaction is obfuscated such that it is not discernible without a shared secret.

Preferably the cryptocurrency is a pre-existing cryptocurrency in which some quantity of tradeable units of the pre-existing cryptocurrency is associated with the resource or the resource provider.

Preferably the method further comprises determining the quantity of a cryptocurrency required for access to the resource based on a state of operation of the resource provider. Preferably the method further comprises determining the quantity of a cryptocurrency required for access to the resource based on one or more of: an extent of consumption of the resource; and a degree of contention for access to the resource. The present invention accordingly provides, in a second aspect, a network connected computer system for access control for a restricted resource comprising a processor and data store, wherein a blockchain data structure accessible via the network stores digitally signed records validated by network connected miner software components including a provider record associated with a resource provider, and wherein the processor is adapted to undertake the steps of: identifying an access control role definition for access to the resource, the role including a specification of access permissions; receiving a request from a resource consumer for access to the resource; communicating, to the resource consumer, an indication of a quantity of a cryptocurrency required for access to the resource; in response to a determination that the required quantity of cryptocurrency is transferred to the provider record in the blockchain, the transfer being caused by a blockchain transaction including an identification of the role and the transaction being validated by a miner component, granting the consumer access to the resource in accordance with the role definition.

The present invention accordingly provides, in a third aspect, a computer program element comprising computer program code to, when loaded into a computer system and executed thereon, cause the computer to perform the steps of a method as described above.

A preferred embodiment of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a block diagram of a computer system suitable for the operation of

embodiments of the present invention; Figure 2 is a component diagram of a network connected computer system arrangement in accordance with embodiments of the present invention;

Figure 3 is a flow diagram illustrating a method of access control for a restricted resource of a resource provider in a network connected computer system in accordance with embodiments of the present invention; and Figure 4 is a flow diagram illustrating a method of access control for a restricted resource of a resource provider in a network connected computer system in accordance with alternative embodiments of the present invention. Figure 1 is a block diagram of a computer system suitable for the operation of

components in embodiments of the present invention. A central processor unit (CPU) 102 is communicatively connected to storage 104 and an input/output (I/O) interface 106 via a data bus 108. The storage 104 can be any read/write storage device such as a random access memory (RAM) or a non-volatile storage device. An example of a non-volatile storage device includes a disk or tape storage device. The I/O interface 106 is an interface to devices for the input or output of data, or for both input and output of data. Examples of I/O devices connectable to I/O interface 106 include a keyboard, a mouse, a display (such as a monitor) and a network connection. Figure 2 is a component diagram of a network connected computer system arrangement in accordance with embodiments of the present invention. A network 200 is provided as a wired or wireless physical or virtual communication medium for communicatively connecting computing components such as computer systems, data storage systems, physical or virtualised components such as software stacks and the like. The network 200 is depicted as a single continuous entity though it will be appreciated that the network 200 could have any communications network topology and/or arrangement. In some embodiments the network 200 is a series of communicatively connected networks or a logical arrangement of networks or subnetworks operating over potentially numerous underlying physical networks. In some embodiments the network 200 is the internet. In communication with the network is provided a blockchain database 208 as a sequential transactional database or data structure that may be distributed and is communicatively connected to a network 200. The blockchain database 208 is a sequential transactional database that may be distributed. Sequential transactional databases are well known in the field of cryptocurrencies and are documented, for example, in "Mastering Bitcoin. Unlocking Digital Crypto-Currencies." (Andreas M. Antonopoulos, O'Reilly Media, April 2014). For convenience, the database is herein referred to as blockchain 208 though other suitable databases, data structures or mechanisms possessing the characteristics of a sequential transactional database can be treated similarly. The blockchain 208 provides a distributed chain of block data structures accessed by a network of nodes known as a network of miner software components or miners 210. Each block in the blockchain 208 includes one or more record data structures associated with entities interacting with the blockchain 208. Such entities can include software components or clients for which data is stored in the blockchain 208. The association between a record in the blockchain 208 and its corresponding entity is validated by a digital signature based on a public/private key pair of the entity. In one embodiment the blockchain 208 is a BitCoin blockchain and the blockchain 208 includes a Merkle tree of hash or digest values for transactions included in each block to arrive at a hash value for the block, which is itself combined with a hash value for a preceding block to generate a chain of blocks (i.e. a blockchain). A new block of transactions is added to the blockchain 208 by miner components 210 in the miner network. Typically, miner components are software components though conceivably miner components could be implemented in hardware, firmware or a combination of software, hardware and/or firmware. Miners 210 are communicatively connected to sources of transactions and access or copy the blockchain 208. A miner 210 undertakes validation of a substantive content of a transaction (such as criteria and/or executable code included therein) and adds a block of new transactions to the blockchain 208. In one embodiment, miners 210 add blocks to the blockchain 208 when a challenge is satisfied - known as a proof-of-work - such as a challenge involving a combination hash or digest for a prospective new block and a preceding block in the blockchain 208 and some challenge criterion. Thus miners 210 in the miner network may each generate prospective new blocks for addition to the blockchain 208. Where a miner satisfies or solves the challenge and validates the transactions in a prospective new block such new block is added to the blockchain 208. Accordingly the blockchain 208 provides a distributed mechanism for reliably verifying a data entity such as an entity constituting or representing the potential to consume a resource.

While the detailed operation of blockchains and the function of miners 210 in the miner network is beyond the scope of this specification, the manner in which the blockchain 208 and network of miners 210 operate is intended to ensure that only valid transactions are added within blocks to the blockchain 208 in a manner that is persistent within the blockchain 208. Transactions added erroneously or maliciously should not be verifiable by other miners 210 in the network and should not persist in the blockchain 208. This attribute of blockchains 208 is exploited by applications of blockchains 208 and miner networks such as

cryptocurrency systems in which currency amounts are expendable in a reliable, auditable, verifiable way without repudiation and transactions involving currency amounts can take place between unrelated and/or untrusted entities. For example, blockchains 208 are employed to provide certainty that a value of cryptocurrency is spent only once and double spending does not occur (that is spending the same cryptocurrency twice). The arrangement of Figure 2 further includes a network connected resource provider 202 component as a software, hardware, firmware or combination component having associated a computing resource 203 (such as a resource of the type hereinbefore described) for provision to consuming entities in the system such as the resource consumer 206. The resource consumer 206 is a network connected software, hardware, firmware or combination component that seeks to consume the resource 203 provided by the resource provider 202. The resource consumer 202 has associated a record in the blockchain 208. Access to the resource 203 by the consumer 206 is controlled based on an access control mechanism partly implemented by an authorisation server 204. The authorisation server 204 is a software, hardware, firmware or combination component adapted to grant, preclude and/or revoke access to the resource 203. For example, in one embodiment the resource provider 202 is a cloud computing service provider providing a resource 203 as a cloud computing service such as a data storage service. In such an exemplary embodiment the authorisation server 204 is a component of an organisation having multiple resource consumers including consumer 206, such as an employer organisation having multiple employees. In an alternative exemplary embodiment the resource 203 is a media resource and the authorisation server 204 is a network connected authorisation service for providing access to the resource 203 by client computer systems such as web browsers as consumers 206 distributed over the network 200.

In summary, in use, the authorisation server 204 communicates with the resource provider 202 to identify an access control role definition for access to the resource 203. A role definition is a definition of access control permissions for a particular consumer 203 or class or type of consumer 203 and permissions can define access rights and/or capabilities that are grantable to such consumer(s) depending on the particular nature of the resource 203. For example, a data storage resource can have role permissions defining access to read, write, delete and create data. In a further example, a network communication resource can have role permissions defining access to send and receive data via the network. The role definition is stored by the resource provider 202 and the authorisation server 204.

A new or derived cryptocurrency is defined as a quantity of tradeable units of value and recorded in the blockchain 208. Preferably the quantity of cryptocurrency is recorded in association with the authorisation server 204 such as by association with a record for the authorisation server 204 in the blockchain 208. Such a record can be a blockchain account or contract. Preferably the cryptocurrency is a bespoke cryptocurrency generated specifically for the purposes of access control, such new cryptocurrency being associated with the resource 203, a set of resources, the resource provider 202 and/or the authorisation server 204. Alternatively the cryptocurrency is an existing cryptocurrency for which some quantity of cryptocurrency is adapted for specific association with the resource 203, a set of resources, the resource provider 202 and/or the authorisation server 204.

For example, one blockchain-based environment suitable for the implementation of embodiments of the present invention is the Ethereum environment. The paper "Ethereum: A Secure Decentralised Generalised Transaction Ledger" (Wood, Ethereum, 2014) (hereinafter Ethereum) provides a formal definition of a generalised transaction based state machine using a blockchain as a decentralised value-transfer system. In an Ethereum embodiment the cryptocurrency is defined as a new unit of tradeable value by an Ethereum account having executable code for handling expenditure of the currency.

In an alternative embodiment, blockchain 208 is a BitCoin blockchain and a derivative of BitCoin cryptocurrency is employed, such as by marking units of BitCoin for associate to the resource 203, a set of resources, the resource provider 202 and/or the authorisation server 204. For example, Coloredcoins can be used to create a dedicated cryptocurrency that can be validated by the miners 210 (see, for example, "Overview of Colored Coins" (Meni Rosenfeld, December 4, 2012) and "Colored Coins Whitepaper" (Assia, Y. et al, 2015) and available at

docs.google.eom/document/d/1 AnkP_cVZTCMLIzw4DvsW6M8Q2JC0llzrTLuoWu2z1 BE).

In one embodiment the cryptocurrency is defined by the authorisation server 204 and identified to the resource provider 202. In an alternative embodiment the cryptocurrency is defined by the resource provider 202 and some quantity of the cryptocurrency is provided to the authorisation server 204 by way of a blockchain transaction to transfer cryptocurrency to the blockchain record associated with the authorisation server 204.

In use the consumer 206 authenticates with the authorisation server 204 using any suitable authentication method as well known to those skilled in the art (e.g. shared secret, biometric, etc.). Once authenticated the authorisation server 204 determines which access control role, if any, the consumer 206 should have. The authorisation server 204 effects authorisation of the consumer 206 by generating a new transaction for the blockchain 208 to transfer a quantity of cryptocurrency from the blockchain record for the authorisation server 204 to a blockchain record for the consumer 206. The consumer 206 may not have a preexisting blockchain record such as a blockchain account or contract for the access control cryptocurrency and, in such cases, a transaction is generated by the authorisation server 204 for submission to the blockchain 208 to generate a new record for the consumer 206. The transaction for transferring cryptocurrency to the consumer record includes an identification of the role. The consumer record is adapted to store the role identification. The transaction(s) generated by the authorisation server 204 are received by the miners 210 who seek to validate the transactions (including checking the validity of the ownership of cryptocurrency by the authorisation server 204 as a basis for the transfer to the consumer record) before being committed to the blockchain 208.

The transfer of cryptocurrency to the consumer record in the blockchain 208 constitutes an authorisation of the consumer 206 to access the resource 203 according to the role stored in the consumer record. Accordingly this authorisation can be confirmed by reference to the blockchain 208. Notably, the blockchain 208 can be implemented as a public data structure on the network 200 and accordingly the authorisation for access to the resource 203 is readily identified by any entity communicatively connected to the network from any network connected location. Subsequently the resource provider 202 uses the confirmed ownership of a quantity of the cryptocurrency by the consumer 206 as indicated in the blockchain 208 to grant access to the resource 203 by the consumer 206. The inclusion of the role identification in the consumer record also provides for the application of appropriate access permissions by the resource provider 202. Embodiments of the present invention therefore provide for consistent and distributed access to verifiable access control information for network connected entities accessing the blockchain 208. Further, trust between the consumer 206 and resource provider 202 is not required. The resource provider 202 need only be aware of the cryptocurrency and role definition and is abstracted from any complexity surrounding individual consumer access control permissions or roles. The authorisation server 204 is able to implement an access control mechanism for consumers 206 even before the consumers are known.

Figure 3 is a flow diagram illustrating a method of access control for a restricted resource 203 of a resource provider 202 in a network connected computer system in accordance with embodiments of the present invention. Initially at step 350 a role is defined by or using the authorisation server 204 including a definition of access control permissions for a class, type or category of consumer. The role definition is stored by the resource provider 202. In an alternative embodiment the role is defined by or using the resource provider 202 directly. At step 352 an identification of the role is received by the authorisation server 204.

Subsequently, at step 354, the consumer 206 authenticates with the authorisation server 204 and requests authorisation to access the resource 203. The authorisation server generates a transaction for the blockchain 208 at step 356 for transferring a quantity of cryptocurrency to the consumer record in the blockchain 208. The transaction includes an identification of the role and is signed by the authorisation server 204. In one embodiment the consumer record does not exist and an additional transaction is generated by the authorisation server 204 to generate the consumer record for association with the consumer 206. The transaction(s) is/are received by miners 210 and validated at step 358 for inclusion in a new block for addition to the blockchain at step 360. Thus the transaction results in the transfer of cryptocurrency to the consumer record in the blockchain 208, the consumer record including an identification of the role.

In one embodiment the identification of the role in the blockchain is obfuscated such that the role of the consumer 206 or the resource or resource provider accessed by the consumer 206 is not discernible from the blockchain. For example, the role identifier can be encrypted by the resource provider or a convention or rule can be defined between the resource provider 202 and the authorisation server 204 defining how the role identifier will be obfuscated, codified or stored in a manner that it cannot be interpreted or understood by other entities. Subsequently, at step 362, the consumer 206 requests that the resource provider 202 grant the consumer 206 access to the resource 203. The request includes an identification of the consumer record in the blockchain 208 such as an address of an account or contract in the blockchain 208. At step 364 the resource provider 202 interrogates the blockchain 208 based on the consumer address to determine whether the consumer is in possession of the requisite cryptocurrency for the resource 203. Notably, the cryptocurrency can be resource specific or resource provider specific. Further, the cryptocurrency could be specific to the authorisation server. In any event the cryptocurrency is defined such that the resource provider 202 can determine that possession of a quantity of the cryptocurrency sufficiently validates access to the resource. Where the resource provider 202 confirms that the consumer 206 is in possession of the required cryptocurrency the resource provider 202 accesses the role identification in the consumer record on the blockchain 208. Any obfuscation of the role identification is processed by the resource provider 202 (such as decryption, decoding or interpreting the representation of the role identifier) in order to determine the appropriate role at step 366. Finally, at step 368 the resource provider 202 grants access to the resource 203 in accordance with the permissions defined in the role identifier.

The transfer of cryptocurrency to the consumer record in the blockchain 208 by the authorisation server 204 thus constitutes the granting of access to the resource 203.

Revocation or modification of such access can be achieved in a number of ways.

Modification can be achieved by modification of the role definition or revocation of an existing authorisation and issuance of a new authorisation (such as a new cryptocurrency).

In one embodiment access can be revoked by rendering the cryptocurrency invalid for access to the resource 203. This approach will affect all consumers authorised by the authorisation server 204 using the same cryptocurrency. Where revocation is required on a consumer level granularity, a forced expenditure of the quantity of cryptocurrency in the customer record can be undertaken. Thus a new blockchain transaction cen be generated that transfers the quantity of cryptocurrency owned by the consumer 206 to another blockchain record, such as a record associated with the authorisation server 204 or the resource provider 202. Expending cryptocurrency requires that a transaction is digitally signed by the owner of the currency and accordingly a total expenditure transaction would need to be signed by the consumer 206 (as owner of the consumer record). Thus, in such embodiments, it is necessary for the authorisation server 204 to have access to the private key for the consumer 206. In an alternative embodiment the consumer record 206 is not generated and signed with the private key of the consumer 206 but is alternatively signed by 5 a new private key generated by the authorisation server 204 specifically for the access control cryptocurrency transaction. The new private key can be shared securely between the authorisation server 204 and the consumer 206 and thus expenditure of the cryptocurrency can be achieved by both the authorisation server 204 and the consumer 206, such as to effect revocation of authorisation to access the resource 203.

10 One challenge when permitting the consumer 206 to perform transactions in respect of the consumer record is that the consumer 206 could conceivably transfer all or part of the access control cryptocurrency to a third party - such as a third party not authorised by the authorisation server 204. To mitigate this problem a multisignature approach can be adopted such that the consumer record is signed twice - once by the private key shared by the

15 authorisation server 204 and the consumer 206 and once by the private key that is secret to the authorisation server 204. Using such a multisignature approach there can be no valid transactions for transfer of the cryptocurrency owned by the consumer 206 without being signed by both the shared private key and the authorisation server's 204 private key.

It can be beneficial for the resource provider 202 to adapt access control to the resource 20 203 depending on context and circumstances. For example, where the resource 203 is in high demand and there is contention for access to the resource 203 or the resource 203 is heavily utilised affecting, for example, performance or accessibility of the resource, it can be beneficial to throttle, control, constrain or restrict access to the resource 203. Such changes to access to the resource 203 can also be desirable depending on a state of operation of the 25 resource provider 202 itself, such as when the provider 202 is experiencing high utilisation or workload, particular operating conditions such as temperature, malfunction, update, repair, infection with malware and the like. Furthermore, it can be desirable for the resource provider 202 to restrict an extent to which the authorisation server 204 is able to grant access to the resource 203. An alternative arrangement according to some embodiments of the present 30 invention providing these additional facilities is described below with respect Figure 4.

Figure 4 is a flow diagram illustrating a method of access control for a restricted resource of a resource provider in a network connected computer system in accordance with alternative embodiments of the present invention. Steps 450 to 460 of Figure 4 are identical to steps 350 to 360 of Figure 3 and these will not be repeated here. The arrangement of 35 Figure 4 differs from that of Figure 3 in that access to the resource 203 is provided depending not only on possession by the consumer 206 of a quantity of cryptocurrency but also on the particular quantity of cryptocurrency possessed by the consumer 206. Thus at step 462 the consumer 206 requests access to the resource 203 by the resource provider 202. The resource provider 202 responds at step 464 with a quantity of cryptocurrency required to access the resource 203. In one embodiment the request at step 462 is supplemented by parameters such as an extent, time period, amount or other measure of usage of the resource 203. Further, in some embodiments the quantity of cryptocurrency indicated by the resource provider at step 202 can be determined based on factors such as operating factors, situational factors, resource consumption, extent of consumption or other factors. Subsequently, at step 466 the consumer 206 generates a blockchain transaction to transfer a quantity of cryptocurrency to the resource provider 202, such as by transferring cryptocurrency to a blockchain record for the resource provider 202. The transaction involves expenditure of cryptocurrency possessed by the consumer 206 in the consumer record in the blockchain 208 and accordingly the transfer also includes the role identifier stored in the consumer record. The transaction by the consumer 206 is signed by the consumer 206. In embodiments where a shared private key is used to sign the consumer record (shared by the consumer 206 and the authorisation server 204) then the transaction is signed using the shared key. Further, in transactions where multiple signatures are used to sign the consumer record then the multiple signatures are used to sign the transaction (notably this may involve the consumer 206 communicating with the authentication server 204 to have the transaction signed by the authentication server 204). The transaction is submitted to the miners 210 for validation at tep 468 and entry on the blockchain 208 resulting in an update to the consumer record and the provider record at step 470. Subsequently the resource provider 202 can interrogate the blockchain 208 to determine, check or identify that a cryptocurrency transaction has taken place and that a requisite amount of the required cryptocurrency has been received by the provider 202 in the provider record. When this is confirmed the provider 202 determines 474 the role for the consumer 206 based on the role identification from the transaction and provides 476 the resource to the consumer in accordance with the role permissions. One particularly advantageous application of the methodology of Figure 4 is when the resource provider 202 or resource 203 enters a critical situation or condition, such as an acute shortage or emergency situation. In such situations a quantity of cryptocurrency required for consumption of the resource can be elevated by one or more orders of magnitude such that a majority of consumers will have insufficient cryptocurrency to consume the resource 203. In parallel to this inflation of the cryptocurrency requirement a new quantity of cryptocurrency can be transferred - of an appropriate order of magnitude to permit consumption of the resource 203 - to a specific authorisation server for dissemination between particular consumers for which access to the critical resource is essential.

For example, in an emergency situation where access to a communication network is essential, access to the network can be restricted to only critical consumers (such as emergency services or the like) by elevating the cryptocurrency cost beyond the reach of non-critical consumers and disseminating quantities of cryptocurrency to critical consumers.

Insofar as embodiments of the invention described are implementable, at least in part, using a software-controlled programmable processing device, such as a microprocessor, digital signal processor or other processing device, data processing apparatus or system, it will be appreciated that a computer program for configuring a programmable device, apparatus or system to implement the foregoing described methods is envisaged as an aspect of the present invention. The computer program may be embodied as source code or undergo compilation for implementation on a processing device, apparatus or system or may be embodied as object code, for example. Suitably, the computer program is stored on a carrier medium in machine or device readable form, for example in solid-state memory, magnetic memory such as disk or tape, optically or magneto-optically readable memory such as compact disk or digital versatile disk etc., and the processing device utilises the program or a part thereof to configure it for operation. The computer program may be supplied from a remote source embodied in a communications medium such as an electronic signal, radio frequency carrier wave or optical carrier wave. Such carrier media are also envisaged as aspects of the present invention.

It will be understood by those skilled in the art that, although the present invention has been described in relation to the above described example embodiments, the invention is not limited thereto and that there are many possible variations and modifications which fall within the scope of the invention.

The scope of the present invention includes any novel features or combination of features disclosed herein. The applicant hereby gives notice that new claims may be formulated to such features or combination of features during prosecution of this application or of any such further applications derived therefrom. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the claims.