Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD, LOCKING SYSTEM FOR CONTROLLING ACCESS TO A RESOURCE AND A LOCKING DEVICE
Document Type and Number:
WIPO Patent Application WO/2021/053131
Kind Code:
A1
Abstract:
A method of controlling access to a resource, wherein the method comprises receiving, from a user, an access request comprising a user public key for identifying the user, a lock public key for identifying a locking device restricting access to the resource, and a digital signature generated based on a user private key corresponding to the user public key. The method further comprises verifying an authenticity of the access request; upon determining the access request being unauthentic, denying access to the resource; upon determining the access request being authentic, the method further comprising: determining whether the user is authorised to access the resource by accessing authentication information of the user managed by a smart contract stored on a blockchain; upon a positive authentication result, granting access to the resource by unlocking the locking device; upon a negative authentication result, denying access to the resource.

Inventors:
SALVADOR SAMUEL (ES)
Application Number:
PCT/EP2020/076081
Publication Date:
March 25, 2021
Filing Date:
September 18, 2020
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
GUNNEBO AB (SE)
International Classes:
G07C9/00
Domestic Patent References:
WO2019120493A12019-06-27
Foreign References:
US20190130086A12019-05-02
US10325428B12019-06-18
Attorney, Agent or Firm:
AWA SWEDEN AB (SE)
Download PDF:
Claims:
CLAIMS

1. A method of controlling access to a resource, the method comprising: receiving, from a user, an access request comprising a user public key for identifying the user, a lock public key for identifying a locking device restricting access to the resource, and a digital signature generated based on a user private key corresponding to the user public key; verifying an authenticity of the access request; upon determining the access request being unauthentic, denying access to the resource; upon determining the access request being authentic, the method further comprising: determining whether the user is authorised to access the resource by accessing authentication information of the user managed by a smart contract; upon a positive authentication result, granting access to the resource by unlocking the locking device; upon a negative authentication result, denying access to the resource.

2. The method according to claim 1 , wherein the step of verifying the authenticity of the access request comprises: verifying the authenticity of the access request based on the user public key and the digital signature of the access request.

3. The method according to claim 1 or 2, wherein the authentication information of the user comprises: a lock public key for identifying a locking device restricting access to a resource that the user is allowed to access.

4. The method according to claim 3, wherein the authentication information of the user further comprises a condition for the user being allowed to access the resource.

5. The method according to claim 3, wherein the step of determining whether the user is authorised to access the resource comprises: upon determining the authentication information of the user comprising the lock public key for identifying the locking device, resulting the positive authentication result; upon determining the authentication information of the user not comprising the lock public key for identifying the locking device, resulting the negative authentication result.

6. The method according to any one of claims 1 -5, wherein the step of determining whether the user is authorised to access the resource comprises: running a blockchain node for accessing the authentication information of the user; wherein the blockchain node belongs to a peer-to-peer network of a blockchain storing the smart contract.

7. The method according to claim 6, wherein the blockchain node is a full node comprising a local copy of information of the blockchain stored in the full node; wherein the method further comprises: accessing the authentication information of the user from the local copy of information of the blockchain.

8. The method according to claim 6, wherein the blockchain node is a light node comprising a local copy of a chain of block headers of the blockchain stored in the light node; wherein the method further comprises: transmitting a first request to at least one full node of the peer-to-peer network of the blockchain, for accessing the authentication information of the user; wherein the first request comprises information for identifying the smart contract and the user public key; transmitting a second request to the at least one full node for receiving a proof information for verifying the validity of the authentication information of the user; receiving the authentication information of the user and the proof information; determining whether the received the authentication information of the user is valid based on the proof information; upon determining the authentication information of the user being invalid, denying access to the resource.

9. The method according to claim 8, wherein the proof information is a Merkle proof.

10. The method according to claim 8 or 9, wherein one request comprising both the first and the second request is transmitted.

11. The method according to any one of claims 1 -10, wherein the step of determining whether the user is authorised to access the resource comprises: connecting to a remote node having a copy of information of the blockchain, for accessing the authentication information of the user, wherein the remote node is not a part of the peer-to-peer network of a blockchain storing the smart contract.

12. The method according to any one of claims 1-11, further comprising: the locking device transmitting a transaction to the smart contract for updating the authentication information of the user; and/or the user transmitting a transaction to the smart contract for updating the authentication information of the user.

13. The method according to claim 12, wherein the transaction is transmitted to the smart contract via a node belonging to the peer-to-peer network of the blockchain.

14. The method according to any one of claims 12-13, wherein when the locking device transmitting the transaction, the transaction comprises a digital signature generated based on a lock private key corresponding to the lock public key for identifying the locking device.

15. The method according to any one of claims 1-14, wherein prior to the step of receiving the access request, the method further comprises: generating the access request by the user interacting with an interface of a user device; transmitting the access request, by the user device.

16. The method according to claim 15, prior to the step of generating the access request, the method comprises: the user device authenticating the user by receiving from the user at least one of: a password, a PIN code, a gesture, a key fob, and biometric data comprising a voice, a fingerprint, an iris scanning image or a face scanning image.

17. The method according to any one of claims 1-16, wherein the access request comprises additional information for preventing a replay attack; and wherein the additional information comprises: information for indicating a valid period of the access request, and/or a session token generated by the locking device.

18. The method according to claim 17, the method further comprising: verifying whether the access request is valid based on the additional information; upon determining the access request being invalid, denying access to the resource.

19. The method according to claims 17 or 18, wherein when the additional information comprises the session token, prior to the step of receiving the access request, the method further comprising: receiving, from the user, a session token request for the locking device generating the session token.

20. The method according to any one of claims 1 -19, wherein prior to the step of receiving the access request, the method comprises: encrypting the access request by the lock public key for identifying the locking device.

21. The method according to any one of claims 1 -20, wherein the blockchain is a public blockchain or a private blockchain.

22. The method according to any one of claims 1 -21 , wherein the smart contract comprises a user data of the user, and wherein the user data comprises: a name of the user, an authorization of the user, indicating a lock public key for identifying a locking device restricting access to a resource that the user is authorised to access, and a role of the user.

23. The method according to claim 22, wherein the smart contract comprises a one-to-one mapping relationship for mapping the user public key to the user data of the user.

24. The method according to any one of claims 22-23, wherein the smart contract comprises: a creating user function for creating a user data for a new user, and creating a one-to-one mapping relationship for mapping a user public key of the new user to the created user data of the new user; and/or a deleting user function for deleting a user data of an existing user, and overwriting or deleting a one-to-one mapping relationship for mapping a user public key of the existing user to the user data of the existing user.

25. The method according to claim 1-24, wherein the smart contract comprises a role data, comprising: a name of the role, an authorization of the role, indicating a lock public key for identifying a locking device restricting access to a resource that a user having been assigned the role being authorised to access.

26. The method according to claim 25, wherein the smart contract comprises: a creating role function for creating a role data for a new role; and/or a deleting role function for deleting an existing role data; and/or an adding role function for assigning a role to a user; and/or a removing role function for deleting a role of a user. 27. The method according to any one of claims 1-26, wherein the smart contract comprises an authorization data, and wherein the authorization data comprises: an authorization, indicating a public lock key for identifying a locking device restricting access to resource that a user or a user having been assigned to a role is authorised to access, a time information for indicating an expiry of the authorization, and a condition for indicating a requirement must be met before and/or during an authentication.

28. The method according to claim 27, wherein the smart contract comprises: an adding user authorization function for adding an authorization data for a user; and/or an adding role authorization function for adding an authorization data for a role; and/or a removing user authorization function for removing an existing authorization data for a user; and/or a removing role authorization function for removing an existing authorization data for a role.

29. The method according to any one of claims 27-28, wherein the authorization data further comprises: a type of authorization.

30. The method according to any one of claims 1-29, wherein the smart contract comprises a condition data, comprising: a temporal condition, for indicating a time limit of a user being authorised to access a resource; and/or a locking status condition, for indicating a locking status of a different locking device for a user being authorised to access a resource.

31. The method according to claim 30, wherein the smart contract comprises: an adding condition function for adding a new condition data for an authorization; and/or a removing condition function for removing an existing condition data for an authorization.

32. The method according to any one of claims 30-31 , wherein the condition information further comprises: a positional condition, for indicating a geolocation requirement for the locking device and/or a different locking device controlling access to a resource, which a user is authorised to access.

33. The method according to any one of claims 1-32, wherein the smart contract comprises a plurality of owner addresses for invoking a plurality of functions of the smart contract.

34. The method according to claim 33, wherein the smart contract comprises: an adding owner address function for adding a new owner address; and/or a removing owner address function for removing an existing owner address.

35. The method according to any one of claims 1-34, further comprising: executing an owner consensus algorithm prior to executing a function of the smart contract; upon receiving an approval of a predetermined number of all the owner addresses, executing the function of the smart contract.

36. The method according to any one of claims 1-35, further comprising: detecting a locking status of the locking device; wherein the locking status comprises: the locking device being unlocked or locked.

37. The method according to any one of claims 1-36, further comprising: the locking device receiving a GPS information indicating a geolocation of the locking device; the locking device recording the GPS information.

38. The method according to claim 37, wherein the locking status further comprises the GPS information.

39. The method according to any one of claims 1-38, wherein the resource comprises an article attached to an RFID tag; and wherein the method further comprises: detecting, by an RFID reading device, a presence of the article by detecting a presence of the RFID tag; and recording the detected presence of the article.

40. The method according to claim 39, wherein the locking status further comprises: the detected presence of the article.

41. The method according to claim 39 or 40, further comprises: detecting, by the RFID reading device, an absence of the article by detecting an absence of the RFID tag; and recording the detected absence of the article.

42. The method according to any one of claims 1-41 , wherein the resource comprises a plurality of articles each attached to a respective RFID tag; and wherein the method further comprises: detecting a number of the plurality of articles, and/or a change of the number of the plurality of articles; and recording the detected number and/or the detected change of the number.

43. The method according claim 42, wherein the step of detecting the number of the plurality of articles comprises: detecting, by an RFID reading device, a presence of each of the plurality of articles by detecting its RFID tag; calculation the number of the plurality of articles based on a number of the detected presences of articles.

44. The method according to claim 43, further comprising: recording an event data for recording the locking status of the locking device, and/or a change of the locking status of the locking device; wherein the event data comprises: a type of an event, a timestamp of a happening of the event, a trigger of the event, and a status of the locking device before the happening of the event, and/or after the happening of the event, and/or when the event data is created.

45. The method according claim 44, wherein the trigger comprises at least one of: the positive authentication result, the negative authentication result, a change of the resource, e.g., a presence of a new article, an absence of an existing article of the resource.

46. The method according to any one of claims 37-45, further comprising recording locally in a memory of the locking device, or in the smart contract.

47. The method according to claim 46, wherein when the event data is recorded in the smart contract, the smart contract comprises: an adding event function for adding a new event data and a mapping relationship between the new event data and a locking device; and/or a removing event function for removing an existing event data, and/or for removing an existing mapping relationship between of the existing event and a locking device.

48. The method according to any one of claims 1-47, further comprising: the user transmitting a status request to the locking device for requesting a locking status of the locking device; wherein the status request comprises: the user public key for identifying the user, the lock public key for identifying the locking device, and a digital signature generated based on the user private key corresponding to the user public key.

49. The method according to claim 48, wherein the status request further comprises information for indicating which part of the locking status is requested.

50. The method according to any one of claims 48-49, wherein the locking status of the locking device is locally stored in the memory of the locking device, and wherein the method further comprises: the locking device transmitting at least a part of the locking status of the locking device to the user.

51. A method of controlling access to a resource, the method comprising: receiving, from a user, a closing request for locking a locking device restricting access to the resource, wherein the closing request comprises a user public key for identifying the user, a lock public key for identifying the locking device, and a digital signature generated based on a user private key corresponding to the user public key; verifying an authenticity of the closing request; upon determining the closing request being authentic, the method further comprising: determining whether the user is authorised to lock the locking device by accessing authentication information of the user managed by a smart contract; upon a positive authentication result, locking the locking device.

52. A locking device configured to control access to a resource, the locking device comprising a lock unit, configured to unlock or lock based on a control signal; wherein the locking device further comprises a control circuit configured to perform:

- a request receiving function, configured to receive a request from a user, wherein the request comprises a user public key for identifying the user, a lock public key for identifying a locking device, and a digital signature generated based on a user private key corresponding to the user public key; - a request verifying function, configured to verify an authenticity of the request; wherein upon determining the request being authentic, the control circuit is configured to perform:

- a user authentication function, configured to perform a user authentication by accessing authentication information of the user managed by a smart contract; wherein upon a positive authentication result, the user authentication function is configured to generate a control signal for controlling the lock unit in response to the received request.

53. The locking device according to claim 52, wherein the request is an access request for accessing the resource, or a closing request for restricting access to the resource.

54. The locking device according to claim 53, wherein when the request is the access request, the lock unit is configured to unlock based on the control signal; and wherein when the request is the closing request, the lock unit is configured to lock based on the control signal.

55. The locking device according to claim 52, wherein the request is a status request for requesting a locking status of the locking device; wherein the locking status of the locking device is locally stored in the memory of the locking device; wherein the control circuit is further configured to perform:

- a status transmitting function, configured to transmit at least a part of the locking status of the locking device to the user.

56. The locking device according to any one of the claims 52-55, wherein the locking device is configured to connect to a GPS unit for receiving a GPS information for indicating a geolocation of the locking device.

57. The locking device according to claim 56, wherein the GPS unit and the locking device is integrated as one device.

58. The locking device according to any one of the claims 52-57, wherein the locking device is configured to connect to an RFID reading device for detecting an RFID tag attached to an article belonging to the resource. 59. The locking device according to claim 58, wherein the RFID reading device and the locking device is integrated as one device.

60. The locking device according to any one of the claims 52-59, wherein the locking device is implemented in a storage device for theft-proof storage of valuable articles.

61. A locking system for controlling access to a resource, the system comprising: a locking device according any one of claims 52-60; a smart contract configured to manage authentication information of a user; and a user device configured to communicate with the locking device and/or the smart contract.

Description:
METHOD. LOCKING SYSTEM FOR CONTROLLING ACCESS TO A

RESOURCE AND A LOCKING DEVICE

Technical field

The present document relates to a method, a system for controlling access to a resource, and a locking device configured to control access to a resource. Particularly, it relates to a blockchain based method, system and locking device for controlling access to a resource.

Background

Access control normally refers to a selective restriction of access to a resource, e.g., a physical property or an immaterial property, in the fields of physical security and information security. The act of accessing can be such as passing a turnstile, and reading/writing a piece of information on a medium. The permission to access may be one time or multiple times.

Traditional physical access control is accomplished through keys and locks. When a door is locked, only someone with a key can enter through the door; when the door is open, only someone with the key can lock the door to prevent others from entering, depending on how the lock is configured. However, mechanical locks and keys cannot provide restriction of the key holder, and other conditions of access, including specific times or dates. Further, when a mechanical key is lost or the key holder is no longer authorized to access, the locks must be replaced.

Electronic access control has thus been developed for solving some of the above limitations of the traditional physical access control by mechanical locks and keys. Credentials and/or authentications have been used to replace the mechanical keys. The combination of a user name and a secret password is a widely used example of credentials. Other forms of credentials include, e.g., biometrics (fingerprints, voice recognition, retinal scans), public key certificates, and so on. When an access is granted, the resource may be accessible for a predetermined time and the unlocking may be recorded. When an access is denied, the resource remains restricted and the attempted access may be recorded. For an electronic access control system or an electronic locking system, a fundamental part is the information related to the authentications of credentials, e.g. the information related to the users, the locks restricting the resources, etc. Current electronic locking systems generally store authentication information either locally in each individual lock, or in a centralized database which can be accessed through an intranet or remotely over the internet by the lock and/or the user.

Storing the authentications information locally in each lock ensures that the information will be available during authentication. However, the maintenance of the locking system may be inefficient, as each lock has to be updated separately.

An advantage of using a centralized database for storing the authentications information is that all necessary information can be stored in one place, which reduces the complexity of the system maintenance, e.g., adding new users, modifying existed access rights. However, the centralized database also has a number of drawbacks.

One problem is that the centralized database becomes a single point of failure for the locking system. If the system hosting or communicating with the centralized database fails due to e.g., lack of power or a malicious attacking, the entire locking system will no longer function. For example, an attacker could coordinate a distributed denial of service attack to overwhelm a server hosting the centralized database, to make the locking system unusable.

The database may be hosted by a third party, which makes the operators of the locking systems dependent on the third party and requires them to trust it to maintain a high degree of data security. However, ensuring that the authentication information is protected from manipulation both externally and internally is a very difficult task and always comes with a certain risk.

Thus, there is a need to provide an improved access control method and system, and an improved locking device configured to control access to a resource, such that a more secure and robust access control may be provided and the maintenance of the system may be simplified.

Summary

It is an object of the present disclosure, to describe an access control method and system, and a locking device configured to control access to a resource, which eliminate or alleviate at least some of the disadvantages of the prior art.

According to a first aspect, there is provided a method of controlling access to a resource. The method comprises: receiving, from a user, an access request comprising a user public key for identifying the user, a lock public key for identifying a locking device restricting access to the resource, and a digital signature generated based on a user private key corresponding to the user public key; verifying an authenticity of the access request; upon determining the access request being unauthentic, denying access to the resource; upon determining the access request being authentic, the method further comprising: determining whether the user is authorised to access the resource by accessing authentication information of the user managed by a smart contract; upon a positive authentication result, granting access to the resource by unlocking the locking device; upon a negative authentication result, denying access to the resource.

The inventive concept is to provide an alternative way to control access to a resource by using a smart contract stored on a blockchain.

A smart contract may be a piece of code. The smart contract may be created and stored in the blockchain. Upon creation, the smart contract receives its own address that a user can send a transaction for invoking functions of the smart contract. When a transaction for invoking a function of a smart contract is included in the blockchain, each node of the peer to peer network of the blockchain may individually execute the function and update the blockchain according to the outcome of executing the function.

The smart contract may comprise variables and functions for operating and/or interacting with a locking system. For example, the information of the user (user device) and the locking device of the locking system may be stored and managed by the smart contract.

Typically, an owner consensus is required before executing the function of the smart contract, e.g., a function modifier that requires the approval of a predetermined number of all current owners of the smart contract, i.e. owner addresses.

The user and the locking devices may be identified using the public key cryptography scheme of the blockchain in the locking system. For example, the user may be provided a user public key, also known as a user address; and the locking device may be provided with a lock public key, also known as a lock address. The user may be provided with a user private key corresponding to the user public key. The locking device may be provided with a lock private key corresponding to the lock public key. The private keys are only known to the owner of the keys.

The access request can be transmitted from the user to the locking device via a wire or wirelessly, by any communication protocol, e.g., short range communications, such as Bluetooth or Wi-Fi, or long range communications such as the Internet.

In short, a blockchain is a distributed ledger of transactions with a decentralized consensus mechanism. Transactions are broadcasted over a peer-to-peer network of the blockchain and are organized into groups called blocks. The blocks are linked to each other by having a hash of the previous block’s content included in the next block, which creates a chain of blocks, i.e. the blockchain. New blocks added to the blockchain are only accepted by the network if they have been validated by so called miners, that are generally either economically incentivized or selected by the network to create and validate new blocks.

The hash-linked structure of the blockchain makes it resistant to changes and the validation done by the miners ensures that the network can reach consensus on the ordering of the blocks. Blockchains typically use public key cryptography to identify users and verify the authenticity of transactions. More specifically, each user has a pair of cryptographic keys: a public key that can be shared to anyone in the network, and a mathematically related private key keeping secretly to the user. The public key, sometimes called address, is used as a unique identifier for identifying the user and is normally referred to when sending or receiving transactions in a blockchain protocol. The private key can be used to generate a unique digital signature on a piece of data, e.g., a transaction, for proving ownership of the public key. Since the unique digital signature can only be generated by knowing the associated private key to the public key, it can be seen as a verifiable approval of the data by the user owning the public key, for example a transaction sent from it.

The previous generations of blockchains were only used to achieve decentralized consensus around the ordering of cryptocurrency transactions, for example Bitcoin. The latest generation of blockchains, for example Ethereum, functions as a distributed computing platform and/or database.

The blockchain used in the invention can either be a public or private blockchain. An advantage of a public blockchain is that it does not require any maintenance by the operators of the locking system, since it is maintained by the public, decentralized blockchain network due to the economic incentives of the protocol. However, because of this, public blockchains typically have transaction fees and longer transaction times than private blockchains. Although this makes it inconvenient to change information in the smart contract, e.g., the authorizations of a user, it does not affect the process of authenticating a user that requests to access a locking device since this does not require broadcasting any transactions to the blockchain. These factors make a public blockchain more suitable for use in environments where the operators of the locking system either lack the resources or deem it inconvenient to run and/or maintain a private blockchain, such as in home offices, small offices or commercial businesses.

However, if the operators of the locking system have a need for fast transaction times, a high transaction throughput or limited visibility of transactions, a private blockchain may be a better option than the public blockchain. The private blockchain has access restricted to the only participating parties, who maintain the blockchain collaboratively by running blockchain full nodes that validate transactions. Such full nodes can either be run on servers or desktop computers that the participating parties operate themselves, or on cloud platforms such as AWS or Microsoft Azure that run the full nodes for them. This type of blockchain is more suitable for high secured environments that have a need for a collaborative system, for example in the relationship between retailers, banks and CIT (Cash-In- Transit) companies.

The locking system can operate in a same way no matter the smart contract is running/storing in a private or public blockchain. However, the type of node that the locking device runs and uses to access the authentication information stored in the smart contract may be different. If a public blockchain is used, it is more suitable for the locking device to run a light node and send a request to a full node of the blockchain network for accessing the data they need. If a private blockchain is used, the locking device may preferably run its own full node and may have a direct access to a local copy of all data of the smart contract and the blockchain.

The method may be advantageous as it may provide a way to store the information used by the locking system and the locking device for authenticating a user, which is not only robust and secure, but also easy to update and maintain. Thus, the maintenance of the locking system and the locking device may be simplified and facilitated. The security of the information, and that of the locking system and the locking device using the information, may be improved.

The step of verifying the authenticity of the access request may comprise: verifying the authenticity of the access request based on the user public key and the digital signature of the access request.

The authentication information of the user may comprise: a lock public key for identifying a locking device restricting access to a resource that the user is allowed to access.

The authentication information of the user may further comprise a condition for the user being allowed to access the resource.

The condition may be a temporal condition comprising a time restriction for the user being allowed to access the resource.

The step of determining whether the user is authorised to access the resource may comprise: upon determining the authentication information of the user comprising the lock public key for identifying the locking device, resulting the positive authentication result; upon determining the authentication information of the user not comprising the lock public key for identifying the locking device, resulting the negative authentication result.

The step of determining whether the user is authorised to access the resource may comprise: running a blockchain node for accessing the authentication information of the user; wherein the blockchain node may belong to a peer-to-peer network of a blockchain storing the smart contract.

A device may access information stored on the blockchain, including a smart contract stored on it. The device may run a blockchain node for accessing the information. By running a node, the device may connect to the peer-to-peer network of the blockchain, listen to transactions and/or participate in verifying and updating the blockchain.

The blockchain node may be a full node comprising a local copy of information of the blockchain stored in the full node; wherein the method may further comprise: accessing the authentication information of the user from the local copy of information of the blockchain.

A full node stores a copy of all information of the blockchain, including the history of state transitions. The full node participates in verifying transactions and updating the blockchain.

However, running a full node in a public blockchain network typically requires a large amount of memory resource for storing the local copy, and a fast memory read/write speed. Such a memory may be a solid state drive, SSD, of a large memory size.

Prior to the step of accessing the authentication information, the method may comprise synchronising the local copy of information of the blockchain with the blockchain.

The blockchain node may be a light node comprising a local copy of a chain of block headers of the blockchain stored in the light node. The method may further comprise: transmitting a first request to at least one full node of the peer-to-peer network of the blockchain, for accessing the authentication information of the user; wherein the first request comprises information for identifying the smart contract and the user public key; transmitting a second request to the at least one full node for receiving a proof information for verifying the validity of the authentication information of the user; receiving the authentication information of the user and the proof information; determining whether the received the authentication information of the user is valid based on the proof information; upon determining the authentication information of the user being invalid, denying access to the resource.

A light node does not have a local copy of the entire information of a blockchain, as a full node. Instead, the light node has a local copy of a chain of block headers of the blockchain.

Each block in the blockchains has a block header. The block header is a packet of metadata for the block in the blockchain. The block header typically comprises the data necessary to verify whether this block is valid according to e.g., a consensus mechanism of the blockchain. The block may be considered valid if it has been validated according to the consensus algorithm used by the blockchain. The block header may comprise data that proves this, e.g., the data may be signatures of all “block validators” in a private blockchain that has to be included in each block header for the corresponding blocks to be considered valid.

The block header may comprise other information, e.g., a timestamp of when this block was created, and other miscellaneous information such as a current difficulty level if a Proof-of-Work consensus mechanism is used, the block’s number in the chain, etc.

The chain of block headers has a much smaller size than the entire blockchain. A size of the chain of block headers may be on the order of a gigabyte or less, and can therefore be downloaded and updated in a short time. The requirements to the memory for storing the local copy of the chain of block headers are less demanding, comparing to that for the full node.

Thus, if a public blockchain is used, a device of a reduced hardware capacity may run a light node, for accessing information of the blockchain. Further, since a synchronization of a light node may be fast, e.g., less than a minute, running a light node may be suitable for those devices having a less stable connection such that synchronisation is needed frequently.

The proof information may be a Merkle proof.

One request comprising both the first and the second request may be transmitted.

The blockchain node may be a remote node, and the method may further comprise: connecting to a full node having a copy of information of the blockchain, for accessing the authentication information of the user.

The locking device may connect to a remote node, which is not a node within the peer-to-peer network of the blockchain. That is, the locking device may be required to trust a full node hosted by a third party to provide authentication information of the user.

This may further reduce the hardware requirements comparing to the alternative of running the light node. One drawback is that it is extremely difficult, if not impossible, to verify the validity of any data. However, if the remote node is run by a trusted party, running a remote node would be a viable alternative for accessing information from the smart contract and/or the blockchain.

The method may further comprise: the locking device transmitting a transaction to the smart contract for updating the authentication information of the user; and/or the user transmitting a transaction to the smart contract for updating the authentication information of the user.

The transaction may be transmitted to the smart contract via a node belonging to the peer-to-peer network of the blockchain.

The transaction, or a message comprising the transaction may be transmitted to a node of the blockchain network. The transaction may comprise information specifying which smart contract and/or what function of the smart contract the sender invokes.

The method may further comprise: the node receiving the transaction and verifying an authenticity of the transaction; upon determining the transaction being unauthentic, discarding the transaction; upon determining the transaction being authentic, broadcasting the transaction to other nodes belonging to the peer-to-peer network of the blockchain.

Moreover, the method may further comprise: the smart contract executing a consensus algorithm for the transaction; upon an agreement on the transaction, the smart contract updating the authentication information of the user based on the transaction.

When the locking device transmitting the transaction, the transaction may comprise a digital signature generated based on a lock private key corresponding to the lock public key for identifying the locking device.

Prior to the step of receiving the access request, the method may further comprise: generating the access request by the user interacting with an interface of a user device; transmitting the access request, by the user device.

The user device may be a smartphone, a tablet, a computer.

Prior to the step of generating the access request, the method may comprise: the user device authenticating the user by receiving from the user at least one of: a password, a PIN code, a gesture, a key fob, and biometric data comprising a voice, a fingerprint, an iris scanning image or a face scanning image.

The access request may comprise additional information for preventing a replay attack; and wherein the additional information may comprise: information for indicating a valid period of the access request, and/or a session token generated by the locking device.

The method may further comprise: verifying whether the access request is valid based on the additional information; upon determining the access request being invalid, denying access to the resource.

A replay attack, also known as a playback attack, is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This may be carried out by an unauthorised party who intercepts the data and re-transmits it.

When the additional information comprises the session token, prior to the step of receiving the access request, the method may further comprise: receiving, from the user, a session token request for the locking device generating the session token.

Prior to the step of receiving the access request, the method may comprise: encrypting the access request by the lock public key for identifying the locking device. The blockchain may be a public blockchain or a private blockchain.

The smart contract may comprise a user data of the user, and wherein the user data may comprise: a name of the user, an authorization of the user, indicating a lock public key for identifying a locking device restricting access to a resource that the user is authorised to access, and a role of the user.

The smart contract may comprise a one-to-one mapping relationship for mapping the user public key to the user data of the user.

The smart contract may comprise: a creating user function for creating a user data for a new user, and creating a one-to-one mapping relationship for mapping a user public key of the new user to the created user data of the new user; and/or a deleting user function for deleting a user data of an existing user, and overwriting or deleting a one-to-one mapping relationship for mapping a user public key of the existing user to the user data of the existing user.

The smart contract comprises a role data, comprising: a name of the role, an authorization of the role, indicating a lock public key for identifying a locking device restricting access to a resource that a user having been assigned the role being authorised to access.

The smart contract may comprise: a creating role function for creating a role data for a new role; and/or a deleting role function for deleting an existing role data; and/or an adding role function for assigning a role to a user; and/or a removing role function for deleting a role of a user.

The smart contract may comprise an authorization data, and wherein the authorization data may comprise: an authorization, indicating a public lock key for identifying a locking device restricting access to resource that a user or a user having been assigned to a role is authorised to access, a time information for indicating an expiry of the authorization, and a condition for indicating a requirement must be met before and/or during an authentication.

The smart contract may comprise: an adding user authorization function for adding an authorization data for a user; and/or an adding role authorization function for adding an authorization data for a role; and/or a removing user authorization function for removing an existing authorization data for a user; and/or a removing role authorization function for removing an existing authorization data for a role.

The authorization data may further comprise: a type of authorization.

The smart contract may comprise a condition data, comprising: a temporal condition, for indicating a time limit of a user being authorised to access a resource; and/or a locking status condition, for indicating a locking status of a different locking device for a user being authorised to access a resource.

The smart contract may comprise: an adding condition function for adding a new condition data for an authorization; and/or a removing condition function for removing an existing condition data for an authorization.

The condition information may further comprise: a positional condition, for indicating a geolocation requirement for the locking device and/or a different locking device controlling access to a resource, which a user is authorised to access.

The smart contract may comprise a plurality of owner addresses for invoking a plurality of functions of the smart contract.

The smart contract may comprise: an adding owner address function for adding a new owner address; and/or a removing owner address function for removing an existing owner address.

The method may further comprise: executing an owner consensus algorithm prior to executing a function of the smart contract; upon receiving an approval of a predetermined number of all the owner addresses, executing the function of the smart contract.

It is known that the smart contract is not a single entity and can therefore not execute any function or code by itself. Thus, in the application, “executing a function or a piece of code of the smart contract” may refer to executing the function or the code of the smart contract individually by each node in the blockchain network, when the condition for executing is met. Then each node may update its own copy of the blockchain according to an outcome of executing the function or piece of code.

The method may further comprise: detecting a locking status of the locking device; wherein the locking status comprises: the locking device being unlocked or locked.

The method may further comprise: the locking device receiving a GPS information indicating a geolocation of the locking device; the locking device recording the GPS information.

The locking status may further comprise the GPS information.

The resource may comprise an article attached to an RFID tag; and wherein the method may further comprise: detecting, by an RFID reading device, a presence of the article by detecting a presence of the RFID tag; and recording the detected presence of the article. The locking status may further comprise: the detected presence of the article.

The method may further comprise: detecting, by the RFID reading device, an absence of the article by detecting an absence of the RFID tag; and recording the detected absence of the article.

The resource may comprise a plurality of articles each attached to a respective RFID tag; and wherein the method may further comprise: detecting a number of the plurality of articles, and/or a change of the number of the plurality of articles; and recording the detected number and/or the detected change of the number.

The step of detecting the number of the plurality of articles: detecting, by an RFID reading device, a presence of each of the plurality of articles by detecting its RFID tag; calculation the number of the plurality of articles based on a number of the detected presences of articles.

The method may further comprise: recording an event data for recording the locking status of the locking device, and/or a change of the locking status of the locking device; wherein the event data comprises: a type of an event, a timestamp of a happening of the event, a trigger of the event, and a status of the locking device before the happening of the event, and/or after the happening of the event, and/or when the event data is created.

The trigger may comprise at least one of: the positive authentication result, the negative authentication result, a change of the resource, e.g., a presence of a new article, an absence of an existing article of the resource.

The method may further comprise recording locally in a memory of the locking device, or in the smart contract.

When the event data is recorded in the smart contract, the smart contract may comprise: an adding event function for adding a new event data and a mapping relationship between the new event data and a locking device; and/or a removing event function for removing an existing event data, and/or for removing an existing mapping relationship between of the existing event and a locking device.

The method may further comprise: the user transmitting a status request to the locking device for requesting a locking status of the locking device; wherein the status request may comprise: the user public key for identifying the user, the lock public key for identifying the locking device, and a digital signature generated based on the user private key corresponding to the user public key. The status request may further comprise information for indicating which part of the locking status is requested.

The locking status of the locking device may be locally stored in the memory of the locking device, and wherein the method may further comprise: the locking device transmitting at least a part of the locking status of the locking device to the user.

Alternatively, or in combination, the locking status of the locking device may be stored in the smart contract. The locking device may access the locking status of the locking device by running a blockchain node. However, storing the locking status in the smart contract may require to broadcast transactions constantly for updating the locking status. Thus, in this case, using the private blockchain would be a better option than using the public blockchain.

The above mentioned features of the method, when applicable, apply to the following second, third and fourth aspects as well. In order to avoid undue repetition, reference is made to the above.

According to a second aspect, there is provided a method of controlling access to a resource. The method comprises: receiving, from a user, a closing request for locking a locking device restricting access to the resource, wherein the closing request comprises a user public key for identifying the user, a lock public key for identifying the locking device, and a digital signature generated based on a user private key corresponding to the user public key; verifying an authenticity of the closing request; upon determining the closing request being authentic, the method further comprising: determining whether the user is authorised to lock the locking device by accessing authentication information of the user managed by a smart contract; upon a positive authentication result, locking the locking device.

According to a third aspect, there is provided a locking device configured to control access to a resource. The locking device comprises a lock unit, configured to unlock or lock based on a control signal; wherein the locking device further comprises a control circuit configured to perform:

- a request receiving function, configured to receive a request from a user, wherein the request comprises a user public key for identifying the user, a lock public key for identifying a locking device, and a digital signature generated based on a user private key corresponding to the user public key;

- a request verifying function, configured to verify an authenticity of the request; wherein upon determining the request being authentic, the control circuit is configured to perform:

- a user authentication function, configured to perform a user authentication by accessing authentication information of the user managed by a smart contract; wherein upon a positive authentication result, the user authentication function is configured to generate a control signal for controlling the lock unit in response to the received request.

The request may be an access request for accessing the resource, or a closing request for restricting access to the resource.

When the request is the access request, the lock unit may be configured to unlock based on the control signal; and wherein when the request is the closing request, the lock unit may be configured to lock based on the control signal.

The request may be a status request for requesting a locking status of the locking device; wherein the locking status of the locking device may be locally stored in the memory of the locking device; wherein the control circuit may be further configured to perform:

- a status transmitting function, configured to transmit at least a part of the locking status of the locking device to the user.

The locking device may be configured to connect to a GPS unit for receiving a GPS information for indicating a geolocation of the locking device.

The GPS unit and the locking device may be integrated as one device.

The locking device may be configured to connect to an RFID reading device for detecting an RFID tag attached to an article belonging to the resource.

The RFID reading device and the locking device may be integrated as one device.

The locking device may be implemented in a storage device for theft- proof storage of valuable articles.

According to a fourth aspect, there is provided a locking system for controlling access to a resource. The system comprises: a locking device, a smart contract configured to manage authentication information of a user; and a user device configured to communicate with the locking device and/or the smart contract. Brief Description of the Drawings

The invention is defined by the appended independent claims. Embodiments are set forth in the appended dependent claims, and in the following description and drawings.

Fig. 1 illustrates an example of a locking system for controlling access to a resource.

Fig. 2 is a flow chart of a method of controlling access to a resource.

Figs 3-4 illustrate two examples of a method of controlling access to a resource.

Fig. 5 illustrates an example of transmitting a transaction to a blockchain.

Fig. 6 illustrates an example of a chain of block headers.

Description of Embodiments

Fig. 1 illustrates an example of a locking system 10 configured to control access to a resource.

The locking system 10 comprises a smart contract 2 comprising authentication information for determining whether a user is authorised to access the resource restricted by a locking device 4.

The smart contract 2 may be stored and executed on a blockchain 1. The smart contract 2 may comprise a function which can be invoked by receiving a piece of information, e.g., a transaction. The smart contract 2 may further comprise data for operating the locking system 10.

The locking system 10 may comprise a user device 3 associated to a user. The user device 3 may comprise a processing unit, a communication unit, and a memory. The user device 3 can be a smartphone, a tablet, a laptop computer or a desktop computer.

The user device 3 may be provided with an interface configured to interact with the user. For example, the user may initiate an access request for accessing the resource, by interacting with the interface. The interface may comprise at least one of a display, a keyboard, a touch screen, and a button. The user device 3 may communicate with the locking device 4 wirelessly, or via a wire.

The user device 3 may be provided with a software application for interacting with the user through the interface. The application may require an initial, local authentication for the user to access it, e.g., asking the user to provide at least one authentication factor, such as, a password, a PIN code or biometric data such as a fingerprint, an iris scan or a face scan. The data required for authenticating the provided authentication factor may be stored locally in the memory of the user device 3. Furthermore, the user device 3 may also store the user public key and the associated user private key in its memory.

The locking system 10 comprises at least one locking device 4. The locking device 4 may be used in a safe for theft- and/or fireproof storage of valuable items and/or documents. Alternatively, the locking device may be used for a door to a building, a storage facility, cupboards or drawers, or the like.

The locking device 4 may be capable of executing software, storing data, communicating with the smart contract 2 and the user device 3. The locking device 4 may send a transaction, to the blockchain 1 , for e.g., updating locking device related information in the smart contract 2. The locking device 4 may generate a digital signature for the transaction by using the lock private key associated to the lock public key stored in the memory of the locking device 4.

The locking device 4 may communicate with the smart contract 2 via a node belonging to a peer-to-peer network of the blockchain 1.

The locking device 4 comprises a lock unit configured to unlock and lock in response to a control signal. The lock unit may be an electronic lock. The lock unit may comprise at least one actuator, which may be configured to move a locking member from an locking position to an unlocked position and vice versa. The locking member may be the member that actually causes the locking of e.g. a door or a drawer to a cabinet. Alternatively, the locking member may have a blocking function, which immobilizes a member that actually causes the locking.

The locking device 4 comprises a control circuit configured to carry out functions and operations of the locking device 4. The control circuit 10 may comprise a processor, such as a central processing unit (CPU), microcontroller unit (MCU), or microprocessor. The processor may be configured to execute program codes in order to carry out functions and operations of the locking device 4.

Functions and operations of the locking device 4 may be embodied in the form of executable logic routines (e.g., lines of code, software programs, etc.) that are stored on a non-transitory computer readable medium, and are executed by the control circuit.

Furthermore, the functions and operations of the locking device 4 may be a stand-alone software application or form a part of a software application that carries out additional tasks related to the locking device 4. The described functions and operations may be considered a method that the corresponding device is configured to carry out. Also, while the described functions and operations may be implemented in software, such functionality may as well be carried out via dedicated hardware or firmware, or some combination of hardware, firmware and/or software.

The locking device 4 may further comprise any of a memory, a power unit, a communication unit, and an input/output (I/O) unit.

The memory may be one or more of a buffer, a flash memory, a hard drive, a removable medium, a volatile memory, a non-volatile memory, a random access memory (RAM), or another suitable device. In a typical arrangement, the memory may include a non-volatile memory for long term data storage and a volatile memory that functions as a system memory for the control circuit. The memory may exchange data with the control circuit over a data bus. Accompanying control lines and an address bus between the storage and the control circuit also may be present.

The power unit may comprise a power cable connected to an external power supply. For example, the power unit may be connected to a power source of a safe that the locking device 4 is mounted on. This may allow the locking device 4 to be manufactured at a lower cost and a smaller size.

Alternatively, or in combination, the power unit may comprise a battery. This may provide a more robust locking device 4 which functions even when a power failure happens.

The locking device 4 may communicate with the nodes of the blockchain peer-to-peer network, and retrieve information from the nodes. For example, the locking device 4 may establish a connection to the node, or the user device 3 via a nearby device, e.g., a router, either via a cable or wirelessly (e.g., WLAN). The locking device 4 may establish a connection by connecting to a proxy device. The locking device 4 may establish a connection by directly connecting to a mobile communication network, such as 2G, 3G, 4G or 5G mobile communication network. The communication unit of the locking device 4 may be configured to communicate with another device with at least one communication protocol. The control circuit is configured to perform a request receiving function, configured to receive a request from a user (sent by the user device 3 associated to the user). The request comprises a user public key for identifying the user (for identifying the user device 3 associated to the user), a lock public key for identifying the locking device 4, and a digital signature generated based on a user private key corresponding to the user public key.

The control circuit is configured to perform a request verifying function, configured to verify an authenticity of the request.

Upon determining the request being authentic, the control circuit is configured to perform a user authentication function, which is configured to perform a user authentication by accessing authentication information of the user managed by the smart contract 2.

Upon a positive authentication result, the user authentication function is configured to generate a control signal for controlling the lock unit in response to the request. When the request is an access request for accessing the resource, the lock unit may be configured to unlock according to the generated control signal. When the request is a closing request for restricting access to the resource, the lock unit may be configured to lock according to the generated control signal.

The locking device 4 may store a locking status of the locking device 4 locally in the memory of the locking device 4. The locking device 4 may detect and/or update the locking status continuously or periodically. The locking status may be stored in a Status data structure in the memory.

The locking status may comprise the locking device 4 being unlocked or locked.

The locking status may comprise additional information related to the status of the locking device 4, such as:

• a current geolocation of the locking device 4, and/or

• information regarding the resource restricted by the locking device 4.

The current geolocation of the locking device 4 may be detected by a GPS unit.

The information regarding the resource may comprise a number of the articles of the resource, a change of the number of articles of the resource, a type of articles of the resource. The information regarding the articles of the resource may be detected by a RFID reading device configured to read an RFID tag attached to each article of the resource restricted by the locking device 4.

The locking status may comprise: whether the locking device 4 is active or inactive, whether a copy of a latest block header chain of the blockchain is stored in the memory of the locking device 4, whether a copy of a list of full nodes of the blockchain that the locking device 4 is currently connected to is stored in the memory of the locking device 4, etc.

The control circuit may be configured to perform a detect status function, configured to detect the locking status of the locking device 4.

The user device 3 may transmit a status request to the locking device 4 for requesting the locking status of the locking device 4. The status request may comprise:

• the user public key for identifying the user,

• the lock public key for identifying the locking device 4, and

• a digital signature of the above data, generated based on the user private key corresponding to the user public key.

• The status request may be a digital message sent by the user device 3 to the locking device 4, for requesting the locking status of the locking device 4.

The status request may be authenticated in a way similar to the access request. That is, the locking device 4 may verify an authenticity of status request. If the status request is not authentic, the locking status of the locking device 4 will not be transmitted to the user device 3. If the status request is authentic, the locking device 4 may determine whether the user is authorised to access the locking status of the locking device 4. If the user is authorised to access the locking status, the requested locking status of the locking device 4 will be transmitted to the user device 3. If the user is not authorised to access the locking status, the locking status of the locking device 4 will not be transmitted to the user device 3.

When the locking status of the locking device 4 is stored locally in the memory of the locking device 4, locking device 4 may have a direct access to the locking status.

When the locking status of the locking device 4 is stored in the smart contract 2 instead of its memory, the locking device 4 may access the locking status of the locking device 4 by running a blockchain node to access the locking status stored in the smart contract 2. The control circuit may be configured to perform a status retrieving function, configured to accessing the locking status of the locking device by running a blockchain node.

In response to the received status request for requesting a locking status of the locking device, the control circuit may be configured to perform a status transmitting function, configured to transmit at least a part of the locking status of the locking device 4 to the user.

The locking device 4 may be configured to connect to a GPS unit for receiving a GPS information for indicating a geolocation of the locking device 4. The GPS unit may be connected directly to the locking device 4, e.g., via GPIO (General-purpose input/output) pins or a USB cable. The locking device 4 may be connected to the GPS unit wirelessly, e.g., via Bluetooth or Wi-Fi.

Alternatively, the GPS unit and the locking device may be integrated as one device.

The locking device 4 may be configured to record a geolocation, and/or an entire history of geolocations of the locking device 4, and/or a change of the geolocation of the locking device 4. The GPS information may be stored locally in the memory of the locking device 4, and/or in the smart contract.

The locking status of the locking device 4 may comprise the GPS information and/or the geolocation.

The GPS information and/or the geolocation may be used for tracking a displacement of the locking device 4 and/or for tracking a displacement of a storage device, e.g., a safe or a cash deposit machine, that the locking device 4 is implemented in.

Further, the geolocation of the locking device 4 may be used as a condition of the user authentication. For example, a user is only allowed to access the resource when a positional condition that the locking device 4 being located within a building is satisfied. Thus, the GPS information and/or the geolocation may be used to further improve the security of the locking system .

The locking device 4 may be configured to connect to an RFID reading device for detecting an RFID tag attached to an article belonging to the resource. The RFID reading device may have a sufficiently long reading range for detecting all RFID tags attached to the articles of the resource.

When the locking device 4 is implemented in a safe or cabinet, the reading range of the RFID reading device may need to be long enough for detecting any RFID tag within the safe or cabinet. The RFID reading device may be connected directly to the locking device 4, e.g., via GPIO (General-purpose input/output) pins or a USB cable. The locking device 4 may be connected to the RFID reading device wirelessly, e.g., via Bluetooth or Wi-Fi. Alternatively, the RFID reading device and the locking device 4 may be integrated as one device.

The RFID tag may be read-only, or read-write. The RFID tag may be either passive or active, i.e. powered by radio waves transmitted by the RFID reading device or by a battery within the RFID tag, respectively. Each RFID tag may be provided with a unique identity, ID. The unique ID may be transmitted to the RFID reading device as a response to an inquiry sent from the RFID reading device. When the response comprising the unique ID of the RFID tag is received by the RFID reading device, it may be considered that a presence of the article attached to the RFID tag is detected.

Similarly, the RFID reading device may detect an absence of an existing article by detecting an absence of an existing RFID tag.

The detected presence and/or absence of the article may be stored locally in the memory of the locking device 4, or in the smart contract 2. The locking status may comprise the detected presence and/or absence of the article.

When the resource comprises a plurality of articles each attached to a respective RFID tag, the RFID reading device may detect a number of the plurality of articles, and/or a change of the number of the plurality of articles. The number and/or the change of the number of the plurality of articles may be monitored continuously or periodically, by the RFID reading device.

The change of the number of the plurality of articles may be use as a trigger to generating an event data. The event data may comprise:

• a type of an event,

• a timestamp of a happening of the event,

• a trigger of the event.

The event data may additionally comprise a status of the locking device before the happening of the event, and/or after the happening of the event, and/or when the event data is generated.

The trigger of the event may comprise a positive authentication result, and a negative authentication result. That is, access to the resource is granted or denied, when the request is the access request for accessing the resource. The trigger of the event may comprise a change of the resource, e.g., a presence of a new article, an absence of an existing article of the resource. For example, when a new RFID tag is detected by the RFID reading device, it is known that a new article is present within, e.g., the safe; when a previously detected RFID tag is no longer detected, it is known that a previously existing article attached to the previously detected RFID tag has been removed e.g., from the safe.

When an event data is generated, it can be stored locally in the memory of the locking device 4, or in the smart contract 2. When stored locally, the locking device 4 may keep an array of at least a few most recently generated event data in the memory.

The event data may be stored in the smart contract 2 by having the locking device 4 broadcasting a transaction comprising the event data to a node of the blockchain peer-to-peer network. The transaction may invoke a function of the smart contract 2 for recording or adding the event data in the smart contract 2.

The event data may be accessed by an authorized user by transmitting a status request to the locking device 4. For example, a system administrator may be authorized to access an event data triggered by a detection of an article being taken out.

When the event data is stored in the smart contract 2, the smart contract 2 may comprise a mapping function eventLog configured to map a lock public key to an array comprising the events data generated by the locking device 4. The event data may be stored in an order in the array, i.e. the first event data generated by the locking device 4 at index 0 of the array and the most recent event data at the end of the array.

The smart contract may comprise an adding event function addEvent for adding a new event data and a mapping relationship between the new event data and a locking device generated the new event data. The addEvent function may takes the new event data as an argument and append it to the eventLog array of the lock public key of the locking device 4 which transmits the transaction comprising the new event data. Thus, the locking device 4 may only be allowed to add an event data to its own eventLog.

The smart contract may comprise a removing event function removeEvent for removing an existing event data, and/or for removing an existing mapping relationship between the existing event data and the locking device generated the existing event data. The removeEvent function may take the lock public key that maps to the eventLog that an event data is to be removed from, and the index of the specific event data to be removed in the array, as inputs. However, this removeEvent function may require an owner consensus before executing.

When the locking device 4 stores an event log in the memory, the status request may additionally request a part of, or a full event log stored in the memory of the locking device 4.

The status request may additionally comprise:

• an identifier for specifying which information the user device 3 asked for, e.g., the full event log or whether the locking device 4 being unlocked or locked.

In connection with fig. 2, the method of controlling access to a resource will be discussed in more detail.

The method 200 of controlling access to a resource comprises: receiving, from a user an access request in step S201 ; verifying an authenticity of the access request in step S202; upon determining the access request being unauthentic, denying access to the resource in step S206; upon determining the access request being authentic, the method further comprising: determining whether the user is authorised to access the resource by accessing authentication information of the user managed by a smart contract in step S203; upon a positive authentication result, granting access to the resource by unlocking the locking device in step S205; upon a negative authentication result, denying access to the resource in step S206.

The access request comprises a user public key for identifying the user (and/or the user device 3 associated to the user), and a lock public key for identifying the locking device 4 restricting access to the resource. The access request comprises a digital signature generated based on a user private key corresponding to the user public key and at least some of the data included in the access request.

The access request may be a digital message sent from the user device 3 to the locking device 4.

The access request may be encrypted by the lock public key for identifying the locking device 4. The lock public key may be included in an initial request from the user device 3 to the locking device 4.

The access request 5 may be transmitted from the user device 3 to the locking device 4 by any communication protocol, including but not limited to a short range communication, such as Bluetooth or Wi-Fi, or a long range communication such as the Internet. In the step 202, upon receiving the access request, the locking device 4 may verify the authenticity of the access request. The locking device 4 may verify the authenticity of the access request based on the user public key and the digital signature of the access request. For example, the locking device 4 may verify that the digital signature of the access request is valid for the user public key included in the access request. Since the digital signature of the access request is generated based on the user private key, upon the digital signature being verified to be valid, it is considered that the user device 3 transmitting the access request actually owns the user private key corresponding to the user public key included in the access request.

The access request may comprise additional information for preventing a replay attack. For example, the additional information may comprise a time limit for indicating a valid period of the access request. When the time limit expires, the access request may be considered invalid by the locking device 4. The validity of the access request may be checked prior or after the step S202.

The method 200 may comprise determining whether the time limit expires by comparing the time limit with a current time. The “current time” may be a time that the locking device 4 receives from a real-time system, e.g., the GPS unit, or a timestamp included in a latest block header that the locking device 4 stored locally in its memory.

Alternatively, or in combination, the user device 3 may transmit a request to the locking device 4 requesting for a session token, e.g., a one time, pseudo-random session token, preferably having an expiry time. Upon receiving the request, the locking device 4 may generate and transmit the requested session token to the user device 3. The locking device 4 may store the requested session token, and preferably its expiry time, locally in the memory of the locking device 4. The access request in the step S201 may comprise the session token received from the locking device 4. Upon receiving the access request, the locking device 4 may determine whether the session token included in the access request is the same as its own copy stored in the memory. The locking device 4 may further determine whether the session token is still valid or is expired based on its expiry time. If the session token is not the same as its own copy and/or the session token is expired, the locking device 4 may deny access to the resource.

The request for a session token may comprise the lock public key. The method 200 may comprise determining whether the session token included in the access request matches its own copy, and/or whether the session token included in the access request is expired or not. These steps may be performed prior or after the step S202.

Analogously, any type of requests between the user device 3 and the locking device 4, e.g., the access request, the closing request and the status request, may comprise at least one of the following additional information for preventing the replay attack:

• a time limit for indication an expiry time/date after which the request is no longer valid, and/or

• a session token generated by the locking device 4.

In step S203, the locking device 4 may run a node for accessing the authentication information of the user managed by the smart contract 2.

The locking device 4 may run a light node for connecting to a node in the blockchain peer-to-peer network, downloading a chain of block headers, and storing the downloaded chain of block headers in its memory.

The locking device 4 may store an address of the smart contract 2 for identifying the smart contract 2, its own lock public key and the associated lock private key in its memory. The locking device 4 may store software in its memory for operating the locking device and performing all the functions of the locking device 4 described in the present application.

Upon the locking device 4 running a light node, the locking device 4 only has block headers stored in its memory, and not a full copy of all the information of the blockchain 1. Thus, the locking device 4 may access the authorization information of the user from the smart contract 2 in order to determine whether the user is authorised to access the resource.

The light node may be connected to one or multiple full nodes 5 of the blockchain peer-to-peer network. The locking device 4 may send a first request for accessing the authentication information of the user in the smart contract 2, to at least one of these full nodes 5. The full node 5 may be hosted by an operator.

The first request may comprise information for identifying the smart contract 2, e.g., an address of the smart contract 2, and the user public key for identifying the user (the user device 3 associated to the user), such that the full node 5 receiving the first request may know which data is needed and where to find the data. The locking device 4 may send a second request to the full node 5 for requesting a Merkle proof of authentication information for a specific block header stored locally in its memory. The Merkle proof may be used to verify whether the authentication information is included in a state Merkle root hash of the specified block header stored in the memory of the locking device 4.

The first and second requests may be sent as two separate requests, as indicated above. Alternatively, these two requests may be combined as one request.

The request may be sent over a communication protocol used by the full node 5 which the locking device 4 is connected to via the light node, for example by an RPC request over HTTP.

Upon receiving the authentication information and optionally the Merkle proof from the full node 5, the locking device 4 may verify the Merkle proof against the block header stored in its local memory. If successful, the locking device 4 may determine whether the user is authorised to access the resource based on the received authentication information. If unsuccessful, the locking device 4 may deny access to the resource.

In connection with fig. 6, the Merkle proof is described in detail. The Merkle proof is a type of lightweight proof. In short, if the locking device 4 running a light node needs to verify a data of a smart contract, the locking device 4 may request that data together with a Merkle proof of the data from the full node 5 and then verify that the data provided is valid based on the Merkle proof.

The block header may comprise root hashes of Merkle trees, which are cryptographic, tree-like data structures that can be used to represent a large amount of data in the compact form cryptographic hash, which may be used to represent information contained within the block.

For example, a value of each node in a Merkle tree is the cryptographic hash of its child nodes, except for the leaf nodes which are hashes of one of the pieces of the data that the Merkle tree should represent. For example, a binary Merkle tree, wherein each parent node always has two child nodes, representing a unique set of transactions, may be created by hashing each transaction separately and putting each hash in a leaf node. The Merkle tree may then built by hashing pairs of leaf nodes to generate a set of parent nodes, which are then hashed in pairs to generate another set of grand parent nodes, etc. This generation process may be repeated until a single root node being generated, which has a hash that is uniquely defined by the tree’s leaf nodes, i.e. the set of transactions. A single change in any leaf node results in a change in the hashes of all its ancestor nodes and ultimately the hash of the root node. When the Merkle tree is high enough, the leaf nodes may fit any amount of data within it and generate a unique root hash for representing that data.

Blockchains generally represent both transactions and their current states, e.g., the values of variables in the smart contract 2, in the Merkle root hashes included in the block headers.

Thus, one property of a Merkle tree is that a leaf node may be proven to be contained in the Merkle tree’s root hash without knowing all other leaf nodes. That is, only the hashes of the nodes that lead out to the leaf node’s branch may be needed to verify that the leaf node is included in the root hash. Thus, the amount of data necessary for verifying any data is much smaller than that of all the leaf nodes.

Fig. 6 illustrates an example of a chain of block headers locally stored in the memory of the locking device 4. Only three block headers of the chain are illustrated in the example. A transaction Tx3 is recorded by a child node of a block having the block header in the middle of the three block headers in fig. 6. The data needed to verify that the transaction Tx3 is included in the Merkle root hash of the middle block header of fig. 6 may be the transaction Tx3 itself, and the two hashes Hash01 and Hash2 in its branch. If these needed data are provided to the locking device 4 by the full node 5, it may calculate the resulting Merkle root hash and verify whether the result agrees with the Merkle root hash of the block header stored locally in its memory.

Although the height of the Merkle tree in a public blockchain is typically much higher than the one in fig. 6, the concept of a Merkle proof is the same. In fact, though the amount of leaf nodes grows exponentially in the height of the tree, the amount of hashes needed for a Merkle proof only grows linearly. The amount of data and calculation involved for verifying a data, e.g., a transaction, may be reduced by using a Merkle proof to prove that a leaf node is included in a root hash.

The method 200 may comprise after retrieving the authentication information from the smart contract 2, the locking device 4 verifying whether the user is authorised to access the resource, based on the retrieved authentication information.

The authentication information may comprise a lock public key for identifying a locking device restricting access to a resource that the user is allowed to access. If the lock public key of the authentication information does not match the lock public key for identifying the locking device 4, a negative authentication result may be generated and the access may be denied.

The authentication information may comprise a condition for the user being allowed to access the resource. If the condition is not met, e.g., if the authorization is expired, a negative authentication result may be generated and the access may be denied. The lock unit of the locking device 4 may remain locked.

If a positive authentication result is generated, the access may be granted. The lock unit of the locking device 4 may be unlocked.

The locking devices 4 may run its own full node locally. Running a full node may be done by connecting to a blockchain peer-to-peer network, downloading a full version of the blockchain 1 in the memory of the locking devices 4, and verifying that new blocks added to the blockchain 1 are valid according to a consensus mechanisms used by the blockchain 1. When running the full node, the locking device 4 has a direct access to the authentication information stored in the smart contract 2 and can verify the authorizations of a user without connecting to another node of the blockchain peer-to-peer network.

Upon the locking device 4 running the full node comprising the local copy of information of the blockchain, the locking device 4 may access the authentication information of the user from the local copy of information of the blockchain 1.

When the full node connects to the blockchain network for a first time, or when it has been offline, it may need to update its local copy of the information of the blockchain 1 to be synchronised with the blockchain 1. The synchronisation of the full node may include downloading the new blocks, verifying the transactions within the new blocks, running functions of a smart contract which have been invoked, and updating its local copy accordingly.

If a public blockchain is used, e.g., the Ethereum main blockchain, a size required to store the local copy may be in the order of hundreds of gigabytes and the size may increase continuously. Thus, the synchronisation may be a lengthy process. The exact time needed for synchronizing a blockchain varies depending on many factors, including the hardware capacity, and the speed of the connection. It is not uncommon to take several days for the full node to finalise its first synchronization. Since a device running a full node has access to all information on the blockchain, the device may verify all information on the blockchain locally, which is both secure and robust. Further, no third party is involved in the authentication process. However, due to the demanding requirements for running a full node of a public blockchain network, the device may preferably be a desktop computer or a server, rather than a mobile phone, or a locking device

Alternatively, the locking device 4 may connect to a remote node, e.g., a full node having a copy of information of the blockchain. The authentication information of the user may be accessed by connecting to the remote node. However, no proof, such as the Merkle proof, may be provided by such remote node. Though it is possible to run the remote node on a server and have the locking device 4 connect to it, the server can become a single point of failure.

Furthermore, the locking device 4 may connect to other, additional full nodes of the blockchain network and to request information from them as well, which makes the system more robust.

The smart contract 2 may comprise a user data of the user. The user data may be stored in a User data structure. The user data may comprise:

• a name of the user,

• an authorization of the user, indicating a lock public key for identifying a locking device restricting access to a resource that the user is authorised to access, and

• a role of the user.

The smart contract 2 may comprise a one-to-one mapping relationship for mapping the user public key to the user data of the user. When knowing the user public key, the user data stored in the smart contract 2 may be accessed by mapping to the user data associated to the known user public key based on the mapping relationship.

An example of the User data structure comprises the following attributes:

• string name

• Authorization [ ] authorizations

• int [] rolelndexes

The string name may refer to the name of the user in the form of a string, e.g. 'Alice", or “Administrator”. The Authorization [ ] authorizations may refer to an array of Authorization data structure which may specify a lock public key for identifying a locking device restricted a resource that the user has authorization to access and optionally, the conditions required to be met for accessing.

The int [ ] rolelndexes may refer to an array of the indexes of the Role data structure in an array createdRoles that this user has been assigned to. The “Int” here may refer to an integer data type.

The User data structure may comprise additional attributes.

The smart contract 2 may comprise a creating user function createUser for creating a user data for a new user. The function createUser may take the attributes of the User data structure and optionally other miscellaneous attributes, as well as the user public key, as input. The function createUser may create the User data structure, and create the mapping relationship between the newly created User data structure and the user public key as arguments.

To make the User data structures accessible in another way, the created User data structures may be also appended to an array users in the smart contract 2. The authorizations of the newly created User data structure may be initially empty.

The smart contract 2 may comprise a deleting user function deleteUser for deleting an existing user data. The deleteUser function may remove the corresponding user that owns the user public key which maps to the existing user data. The deleteUser function may take the user public key that maps to the user data to be deleted, as input, and may overwrite the mapping relationship between the user public key and the associated User data structure with a value null.

The deleteUser function may also delete the User data structure from the array users that it is appended to. This may effectively delete a user completely from the locking system and make the user unable to access any locking device of the locking system, since it is impossible to retrieve a User data structure from the user’s user public key at all.

The smart contract 2 may comprise a role data, comprising:

• a name of the role,

• an authorization of the role, indicating a lock public key for identifying a locking device restricting access to a resource that a user having been assigned the role being authorised to access.

The role data may be used to create a standardized set of authorizations that multiple users can be assigned to. The role data may be stored in a Role data structure similar to the User data structure. Each created role data may be stored in the array createdRoles in the smart contract 2. The Role data structure may comprise the following attributes:

• string name

• Authorization!] authorizations

Similar to the attribute of the User data structure, the string name may refer to the name of the role in a string, for example "Employee" and “visitor”.

Similar to the attribute of the User data structure, Authorization! ] authorizations may refer to an array of Authorization data structure which may specify a lock public key that all users assigned to the role has authorization to access and optionally, the conditions required to be met for accessing.

The smart contract 2 may comprise a creating role function createRole for creating a role data for a new role. The function createRole may take the required attributes of the Role data structure, such as the string name, as input, to create the new Role data structure. The function createRole may add the new Role data structure to the createdRoles array in the smart contract 2. The newly created Role data structure may initially have an empty authorizations array.

The smart contract 2 may comprise a deleting role function deleteRole for deleting an existing role data from the smart contract 2. The function deleteRole may take the data necessary to identify the Role data structure, e.g., its index in the array createdRoles, and set a value null at that index in the array. It is also possible to delete the Role data structure completely in the smart contract 2. However, it would cause a shift of all of following indexes of the array createdRoles, and these Role data structures of the array createdRoles must be re-indexed such that the correct Role data structure may be identified based on the index of the array createdRoles.

The smart contract 2 may comprise an adding role function addRole for assigning a new role to a user. The function addRole may add a Role data structure to the index of the Role in the array createdRoles. This may allow changes to be made to a Role data structure without updating every related User data structure. The function addRole may take the data necessary to identify the User and Role data structures, e.g., the user public key mapping to a specific User and the index of the Role data structure in the array createdRoles that the user should be assigned.

The smart contract 2 may comprise a removing role function removeRole for deleting an existing role for a user. The function removeRole may remove a Role data structure from a User data structure. The function removeRole may take the data necessary to identify the User and Role data structures, e.g., the user public key that maps to a specific User data structure and the index of the Role data structure in the array createdRoles, and remove its index in the array rolelndexes of the User data structure.

The smart contract 2 may comprise authorization data, comprising:

• an authorization, indicating a public lock key for identifying a locking device restricting access to resource that a user or a user having been assigned to a role is authorised to access,

• a time information for indicating an expiry of the authorization, and

• a condition for indicating a requirement must be met before and/or during an authentication.

The authorizations data may be stored in the Authorization data structure comprising information related to a user’s authorization to a locking device and the conditions required to be met for accessing it.

For example, the Authorization data structure may contain the following attributes:

• address lockAddress

• timestamp expiryDate

• Condition[] conditions

The address lockAddress may refer to a lock public key that the authorization refers to.

The timestamp expiryDate may refer to a date/time that after which the authorization expires. An expired authorization is no longer valid.

The Condition! ] conditions may refer to an array of Conditions that must be met for the user to be given access to the resource the locking device having the lock public key restricted. The Conditions may be verified if they are met before and/or during the authentication process.

The smart contract 2 may comprise an adding user authorization function addUserAuthorization and an adding role authorization function addRoleAuthorization, for adding an authorization data for a User or Role data structure, respectively. The functions addUserAuthorization and addRoleAuthorization may take the data necessary to identify a User or Role data structure, e.g., the user public key that maps to the User data structure and the index of the Role data structure in the array createdRoles, respectively, as well as the lock public key for identifying the locking device that the Authorization referred to, as input. The newly created Authorization data structure’s array conditions may be initially empty.

Similarly, the smart contract 2 may comprise a removing user authorization function removeUserAuthorization, and a removing role authorization function removeRoleAuthorization, for removing an existing authorization data for a User or Role data structure, respectively. The functions removeUserAuthorization and removeRoleAuthorization may take the data necessary to identify the User or Role data structure, and the data for identifying the Authorization data structure that is to be removed from the array authorizations in either the User or Role data structure and simply removes the Authorization from the array.

The smart contract 2 may comprise a condition data, comprising:

• a temporal condition, for indicating a time limit of a user being authorised to access a resource; and/or

• a locking status condition, for indicating a locking status of a different locking device.

The condition data may be stored in a Condition data structure in the smart contract 2. The Condition data structure may store data of an expression that can be evaluated to a boolean value, i.e. true or false, which may specify a requirement that has to be satisfied for the authentication process to be valid. The Condition data structures can be added to the array conditions that each Authorization data structure comprises.

The condition data may can specify a wide range of requirements. A couple of examples are described here.

A temporal condition may be a condition which specifies a time restriction for when a user has authorization to access a resource restricted by a locking device. The "current time" may be needed for determining whether a temporal condition is met or not, i.e. the expression is true or false. The “current time” may be a time that the locking device 4 receives from a real-time system, e.g., the GPS unit, or a timestamp included in a latest block header that the locking device 4 stored locally in its memory. For example, a temporal condition can specify that a user (a user device associated to the user), identified by a user public key, is only allowed to access during daytime between 8 AM to 5 PM. This condition may be used to assigning access right to company employees.

A locking condition may be a condition which specifies a requirement of a different locking device that has to be met before a user can be given access. The locking condition may comprise the lock public key for identifying the different locking device. The locking condition may comprise the required condition to be met for the different locking device, e.g., the different locking device must be unlocked or locked.

The locking device 4 may determine whether the different locking device meets the required condition in multiple ways. One way would be to store this information in the smart contract 2, for example with a mapping function locklsOpen mapping each lock public key to a boolean value. This boolean value may be updated by having each locking device sending a transaction including information of itself e.g., whether it is unlocked or locked, to the blockchain during the authentication process. One way would be to have these two locking devices to communicate with each other directly, in a way similarly to the communication between the locking device 4 and the user device 3. The locking device that need to verify whether the condition is met may send a request to the different locking device asking for its status during the authentication process, and wait for a response before the authentication process continues.

If the locking device is connected to the GPS unit, the Authorization data structure stored in the smart contract 2 may have an additional type of Condition, a positional condition, that specifies a requirement on the geolocation of the locking device that has to be satisfied before and/or during the authentication process for it to be successful.

The positional condition may be specified in the Authorizations of the User or Role data structure. Thus, different users and roles may have same or different geolocation conditions on where they will be allowed to access the resource restricted by the locking device.

The smart contract 2 may comprise an adding condition function addCondition for adding a new condition data for an authorization. The function addCondition may take the data necessary to identify a specific Authorization data structure and the data that specifies a boolean expression that is contained within the Condition, as inputs. The function addCondition may verify whether it can be evaluated to a boolean value.

And, if so, the function addCondition may add the Condition to the array conditions in the Authorization data structure.

The smart contract 2 may comprise a removing condition function removeCondition for removing an existing condition data for an authorization. The function removeCondition may takes the data necessary to identify a specific Authorization and the Condition that is to be removed from the array conditions in the Authorization data structure, and simply removes the Condition from it.

The smart contract 2 may comprise a plurality of owner addresses. It is known that once the smart contract has been created and uploaded to the blockchain, it is not in control of any single party, and thus, its content can’t be modified. One way to modify the content of the smart contract, as described in detail herein, is to provide a code capable of modifying the content, e.g., the functions of the smart contract which are capable to make changes to the contents of the smart contract. However, it has to ensure that only the owners of the locking system can invoke such functions. Thus, the owner addresses may be used for approving important changes to the content of the smart contract, such as changing an authorization of a user, which is enforced by the owner consensus function modifier which is to be described below.

The owner addresses can either be held by a single operator of the locking system or by multiple parties that are using the locking system collaboratively.

The smart contract 2 may comprise an adding owner address function for adding a new owner address. The smart contract may comprise a removing owner address function for removing an existing owner address.

The user public key, i.e. the user address that deploys the smart contract 2 to the blockchain 1 is set as a single initial owner address. Except for this initial owner address, the adding and removing owner address functions are examples of functions that require an owner consensus before the execution of the function.

The smart contract 2 may execute an owner consensus algorithm prior to executing a function of the smart contract 2. Upon receiving an approval of a predetermined number of all the owner addresses, the smart contract 2 may execute the function of the smart contract 2.

Owner consensus is a condition that is required by any function in the smart contract 2 that makes an administrative change, e.g., a function for adding a new user, a function for removing an authorization for a user, etc. The function enforcing the owner consensus is known as a function modifier, which is a special type of function that can be invoked by other functions in the smart contract 2 to verify that a condition is met before the function is executed. Thus, an approval of a predetermined number of all current owner addresses is needed for executing the function. The predetermined number may be set upon deployment of the smart contract 2 to the blockchain 1 and can only be changed by a function in the smart contract 2 that itself requires owner consensus.

The smart contract 2 can be deployed and interacted with a device by the device sending a transaction to the blockchain 1. For example, a standardized smart contract may be deployed and interacted with through a software application that the locking system’s operator can access. The software application may be stored in a device, e.g., a smart phone, a tablet, a computer or a server, provided with an internet access. The transaction may be sent to a full node belonging to the blockchain peer-to-peer network, which could either be a full node hosted by the operator of the locking system or a third party, for example a blockchain infrastructure company.

The method 200 may comprise the locking device 4 transmitting a transaction to the smart contract 2 for updating the authentication information of the user. The transaction may comprise a digital signature generated based on a lock private key corresponding to the lock public key for identifying the locking device 4.

The method 200 may comprise the user device 3 transmitting a transaction to the smart contract 2 for updating the authentication information of the user. The transaction may be transmitted to the smart contract 2 via a node belonging to the peer-to-peer network of the blockchain. The transaction may be transmitted to the smart contract 2 at any time, e.g., before, during, or after the authentication.

The method 200 may comprise the smart contract 2 executing a consensus algorithm for the transaction; upon an agreement on the transaction, the smart contract updating the authentication information of the user based on the transaction.

Since anyone can see and interact with the smart contract on the blockchain, it is necessary to restrict who can change the information managed by the smart contract, and/or to restrict which information managed by the smart contract can be changed, such as the authentication information of a user. Thus, the owner addresses may be used to approve such changes.

The method 200 may comprise the node receiving the transaction and verifying an authenticity of the transaction; upon determining the transaction being unauthentic, discarding the transaction; upon determining the transaction being authentic, broadcasting the transaction to other nodes belonging to the peer-to-peer network of the blockchain.

After the locking device 4 transmitting a transaction to the smart contract 2, e.g., when it is to grant a one-time access for a user, the locking device 4 would have to verify that the transaction has been included in the blockchain 1 before proceeding with the authentication process. When running a light node, the locking device 4 may send a request for accessing the updated data of the blockchain and a Merkle proof of the updated data, or a Merkle proof of the transaction newly included in the blockchain 1 , to a full node 5. When running a full node, the locking device 4 may verify locally whether the transaction has been included, without sending any request to other full nodes in the network.

An example of the authentication information of the smart contract 2 will be described herein.

The authentication information of the user may comprise the User data structure of the user (the user device 3 associated to the user) transmitting the access request. The User data structure may include one array of authorizations and one array of rolelndexes. The authentication information of the user may comprise the Role data structure. The exact role of the user may be retrieved by using the indexes contained within rolelndexes from the createdRoles array in the smart contract 2.

The authentication information of the user may be retrieved by sending requests for the data, and optionally a Merkle proof of it to a full node when the locking device 4 runs a light node, or be retrieved from its local copy of the blockchain when the locking device 4 running a full node.

Once the authentication information is available, the locking device 4 may search the authorizations arrays of both the User and Role data structures for an Authorization that refers to its own lock public key locally stored in its memory. Additionally, the locking device 4 may verify whether the conditions are met, e.g., whether the locking device’s geolocation meets the positional condition. An Authorization found in the authorizations array of a User data structure may be configured to have a higher authority level than an Authorization found in the authorizations array of a Role data structure. That is, the authorization of the User data structure may override the authorization of the Role data structure. It may allow a user to be assigned a role of a basic set of authorizations. When needed, the user may be given an additional authorization that override the role’s authorization. The flexibly of the method and the system may be improved.

If the Authorization with a highest authority level is valid, the locking device 4 may retrieve the array conditions contained within the Authorization data structure, evaluate all of the Conditions. In order to verify whether the conditions are met, the locking device 4 may send the status request for inquiring locking status of a different locking device. All of the Conditions of the Authorization data structure must be met, i.e. true, for granting the access.

In addition to the access request, a method of controlling access to a resource may comprise receive the closing request for locking a locking device restricting access to the resource. The closing request may be used for locking the locking device when the lock unit of the locking devices 4 do not or cannot be locked automatically.

The closing request may comprise a user public key for identifying the user, a lock public key for identifying the locking device, and a digital signature generated based on a user private key corresponding to the user public key. The method may comprise verifying an authenticity of the closing request; upon determining the closing request being authentic, the method further comprising: determining whether the user is authorised to lock the locking device by accessing authentication information of the user managed by a smart contract; upon a positive authentication result, locking the locking device.

The closing request may be a digital message sent from the user device 3 to the locking device 4. The closing request may comprise information similar to that of the access request, except upon a positive authentication result, the locking device is configured to lock instead of to unlock.

The examples and features discussed above involving the access request apply analogously to the method involving the closing request. The locking device 4 may perform the same authentication process as when it the access request is received. For example, the locking device 4 may verify whether the closing request is authentic and whether the user has a valid authorization for the lock public key of the locking device 4. This may be done by either sending a request for the authentication information and a Merkle proof of it to a full node, or by retrieving the authentication information from its local copy of the blockchain.

It is assumed that the lock unit of the locking device 4 may be automatically locked after it is unlocked. For example, the lock unit of the locking device 4 may be automatically locked after it has been unlocked for 10 seconds, or when a door of the storage device (or a similar physical barrier) the locking device is implemented in is closed. The closing request may provide additional control to the locking system in case the locking device is unlocked. Thus, the security of the system may be improved.

In addition to the access and closing request, as described above, there may be one more type of request, i.e. the status request for requesting the locking status of the locking device 4.

Accordingly, the authorization data may comprise information for indicating a type of authorization.

The different types of authorizations may be stored in a data structure in the smart contract 2. The data structure may be used to identify the type of an authorization, and may have at least a value indicating whether the authorization is related to an access, closing or status request, i.e. Access/Close or Status. For example, the different types of authorizations may be stored in an enum, which is a customizable data type that can only take on a limited set of values defined in its declaration.

When the authorization type is indicated as Access/Close, it may refer to an authorization type which allows a user to access the resource by unlocking the locking device restricted the resource, and/or an authorization type which allows a user to restrict the resource by locking the unlocked locking device restricted the resource.

When the authorization type is indicated as Status, it may refer to an authorization type which allows a user to access at least a part of the locking status and/or event log of the locking device 4, by sending a status request.

The locking system may be configured such that a more granular level of authorization types may be defined. The authorization type may be configured such that a user may be authorised for requesting and accessing the locking status of a locking device, and/or which part of the locking status the user is authorised to access. For example, a new authorization type for requesting only the geolocation of the locking device 4 may be used. For example, a new authorization type for requesting whether the locking device is unlocked or locked may be used. That is, a user may be given authorization to request and access only a part of the locking status of the locking device, but not all of the locking status.

The Authorization data structure stored in the smart contract 2 may additionally comprise the following attribute:

• AuthorizationType type.

The AuthorizationType type may refer to the type of authorization. The authorization type is set during the creation of an Authorization data structure, e.g., by the functions addUserAuthorization and/or addRoleAuthorization,

In connection with fig. 3, an example of a method of controlling access to a resource is described in detail.

In fig. 3, the method comprises a user interacting with the user device 3 via an interface of the user device 3, to initiate a process of controlling access to the resource. Then, the access request is generated and transmitted to the locking device 4.

The locking device 4 receives the access request transmitted by the user device 3. The access request is firstly verified whether it is authentic and/or valid. That is, to verify whether the access request is sent by the user device 3 and/or to verify whether the access request is still a valid request. If the access request is considered to be unauthentic and/or invalid, the access to the resource is denied and the process ends. The locking device remains locked.

If the access request passes the verification, the process continues. In the example of fig. 3, the locking device runs a full node. That is, the locking device 4 has a local copy of the whole blockchain 1 , including the smart contract 2 managing the authentication information.

Based on the authentication information, the locking device 4 determines whether the user is authorised to access the resource or not. When it is determined the user being not authorised to access, the access is denied and the process ends. The locking device remains locked. When it is determined the user being authorised to access, the access is granted and the locking device is unlocked for the user. The process ends. The locking device may become locked automatically after it has been unlocked, e.g., for 10 seconds.

The access request used in this example may be changed to the closing request for locking the locking device 4. The process of controlling access to the resource is largely analogous to the example in fig. 3. The major difference is that when the user is authorised to lock the locking device, the locking device is locked and the process ends; when the user is not authorised to lock the locking device, the locking device remains unlocked and the process ends.

If the full node has been offline for a while, the locking device 4 may need to synchronise the local copy with the blockchain 1 to ensure that the local copy can represent the latest information of the blockchain 1.

In connection with fig. 4, an example of a method of controlling access to a resource is described in detail.

In fig. 4, the steps of transmitting, receiving and verifying the access request are the same as those of fig. 3.

In the example of fig. 4, the locking device runs a light node. That is, the locking device does not have the local copy of the whole blockchain, as when it runs a full node in fig. 3.

In order to continue the user authentication, the locking device 4 has to send a request to a full node 5 for accessing authentication information of the user managed by the smart contract 2. The locking device 4 also requests for a Merkle proof for the authentication information it requested.

After the full node 5 receives the request for the authentication information and the Merkle proof, it retrieves the requested authentication information, generates the requested Merkle proof, and transmits it back to the locking device 4.

The locking device 4 determines whether the received authentication information is valid by checking the Merkle proof. If the received authentication information is invalid, the access is denied and the process ends. If the received authentication information is valid, the locking device 4 determines whether the user is authorised to access the resource or not, based on the received authentication information. When it is determined the user being not authorised to access, the access is denied and the process ends. The locking device remains locked. When it is determined the user being authorised to access, the access is granted and the locking device is unlocked for the user. The process ends. The access request used in this example may be changed to the closing request for locking the locking device 4. The process of controlling access to the resource is largely analogous to the example in fig. 4. The major difference is that when the user is authorised to lock the locking device, the locking device is locked and the process ends; when the user is not authorised to lock the locking device, the locking device remains unlocked and the process ends.

In connection with fig. 5, an example of transmitting a transaction to a blockchain is described in detail.

In fig. 5, the method comprises the user interacting with the user device 3 via the interface of the user device 3, to initiate a process of sending a transaction to the blockchain 1. The user may also specify the transaction, e.g., by indicating what the user would like to include in the transaction. The transaction may comprise information specifying which smart contract and/or what function of the smart contract the sender invokes. For example, the transaction may comprise information specifying that the user device 3 would like to be assigned to a new role.

According to the user’s input, the user device 3 creates the transaction. The user device 3 creates a digital signature for the created transaction by using the user private key. Then, the user device 3 transmits the created transaction with the digital signature to the full node 5 belonging to the peer to peer network of the blockchain.

The full node 5 receives the transaction and verifies the authenticity of the transaction. For example, the authenticity of the transaction may be verified based on the digital signature of the transaction.

Upon determining the transaction being unauthentic, the full node discards the transaction without broadcasting it further to other nodes of the blockchain network.

Upon determining the transaction being authentic, the full node broadcasts the transaction to other nodes belonging to the peer-to-peer network of the blockchain 1.

The locking device 4 may generate and transmit a transaction to the full node for broadcasting further. The process of generating, transmitting the transaction would be largely analogous to the example described in connection to fig. 5.