In the smart-city paradigm, data sharing is one of the pillars needed for its full implementation. Among the other aspects, we refer to the opportunity for users (citizens, companies, organizations) of exploiting data sources managed both by institutional parties and third parties involved in the smart-city life. Open-data is an answer to above need, but, sometimes data cannot be disclosed publicly, coming to the concept of closed data. In this case, access control takes a fundamental role. The problem is not trivial, since we deal with a highly open and dynamic environment, and, at the same time, that a certain level of accountability should be guaranteed to contrast misbehaviour and solve possible legal controversies. In this paper, we propose a solution based on the combination of Ethereum smart contracts, eIDAS-based attribute and identity management, and the distributed le system IPFS.
problem are described. Then, in Section 4, we explain the architecture of our proposal and the actors involved in it. We brie y analyze, in Section 5, the most important security aspects and properties of our solution. In Section 6, some features of the implementation phase of the proposal are described. In Section 7 we survey the related work. Finally, in Section 8 we draw the conclusions and the we sketch future works. 2
In this section we present some background concepts to better introduce, later, our proposal.
Ethereum is a public blockchain-based platform that allows the development of
decentralized applications (Dapps) able to interact with each other in a secure and fast way [
Smart contracts are used also as agreements between users that do not trust or do not know each other and, for these reasons, they de nitely represent the killer feature of Ethereum. Furthermore, everything that is on a smart contract is permanently stored in the Ethereum blockchain to guarantee the traceability of actions.
Access control is one of the hottest and trend topics of the last decades in the IT world. Indeed, to guarantee a right, secure and non-invasive mechanism that enable or not the access to the resource is always necessary. In particular, an access control mechanism should satisfy, among the others, the following properties: it does not have to allow nonauthorized people to access the resource and it does not have to deny authorized people not to access the resource. The type of access must be subject of authorizations as well. There exist many families of access control, such as Mandatory Access Control and Discretional Access Control, for what concerns the exibility of authorization rules, Role-Based
what concerns the way to associate authorizations to subjects.
In particular, Attribute-Based Access Control (ABAC) is de ned as an access control mechanism in which authorization is computed evaluating the ful llment of one (or more) required attribute. The National Institute of Standards and Technology (NIST) de nes
As a matter of facts, after some decades of supremacy Role-Based Access Control (RBAC), ABAC is emerging as de nitely more suitable than RBAC to large environments, in which de ned roles must be set by the management and associated with people, resulting in what is known as role explosion. In our context (i.e., smart city), ABAC is the elective choice.
Nowadays, cities face di erent problems and challenges to improve their citizens' quality
of life [
IPFS is a peer-to-peer distributed le system that connects all computing devices with the
same system of les [
In the widest interpretation of the concept of a smart city, one of the main challenges is to
guarantee a secure, trusted and fast data sharing. This may have a signi cant impact both
in open-government policies that are crucial in smart cities [
In this scenario, it is fundamental to implement an access control mechanism that is able to decide who can read what, by taking into account the fact that we operate in an open environment, in which interested subjects cannot be predetermined. It is worth noting that, although smart cities should provide open data, which are accessible with no limitation, also closed data are relevant for the full implementation of smart-knowledge-based communities. Therefore, access control becomes necessary.
To better explain, consider the following example. Suppose that some closed data are produced by a smart city entity like a hospital or a court. Since we are talking about sensitive data, it is reasonable to think of some policies for which only people belonging to the medical board (in the case of healthcare data) or lawyers (in the case of law data) can access.
As seen above, there are many access control models but, among all, due to the open nature of our scenario, Attribute-Based Access Control (ABAC) seems the most suitable one because neither identities nor roles are able to capture all the conditions which should be satis ed by subjects to access information. Moreover, ABAC allows us to implement anonymous-credential mechanisms to avoid that sensitive data of subjects are disclosed to possibly untrusted parties and, thus, to preserve privacy.
Obviously, if we think about a smart city and its data it is clear that it is necessary to ensure properties like accountability, privacy, trust and non-repudiability (among the others). In this sense, Ethereum blockchain perfectly ts with these requirements. Another motivation that led us to choose Ethereum is that the mechanism of veri cation of attributes must be trusted. Furthermore, the usage of an Ethereum smart contract enforces the attribute-based access control mechanism without any privacy leakage, since attribute-based authorizations are anonymous and prevent any disclosure of personal, sensitive, and not required information.
Anyway, Ethereum, as every blockchain, is not the most suitable platform for sharing and
storing large les since the blockchain is replicated on many nodes and a lot of storage space is
required without serving an immediate purpose [
InterPlanetary File System (IPFS) is a particularly interesting protocol peer to peer le
sharing platform that combines le sharing and hashes. Cryptographic hashes serve to securely
identify a le's content. IPFS makes it possible to store and share large les more e ciently and
it is based on cryptographic hashes that can easily be stored on a blockchain. Unlike existing
cloud storage, IPFS has the advantage that data is distributed and stored in di erent parts of
the world and not on a central server [
In this section, we propose our solution regarding the scenario discussed above.
First, we de ne all actors involved in it, then we present all the steps needed to reach our goal.
Our idea is the following. Suppose that the smart city produces, owns and provides data that it wants to share not to everybody but only to who ful lls some requirements. To be more concrete, but without loss of generality, we describe our solution in the healthcare setting, although it can be easily extended to every typical context of smart cities (e.g., transport, commercial and law data, etc.). In our proposal, we assume that documents stored on IPFS are already encrypted and, for this reason, objects of our access control authorizations are keys instead of nal resources.
In our solution, we de ne the following actors:
Identity Provider IP , whose task is the management and veri cation of user identities; Attribute Provider AP , whose task is the management and veri cation of user attributes;
Publish Smart Contract P SC, an Ethereum Smart Contract used for the publication of documents on IPFS; Access Smart Contract ASC, an Ethereum Smart Contract used for verifying the policy and, where appropriate, for granting the key for the decryption of the document; Oracle O, that is used by ASC for checking the validity of the certi cate of U ; Content Manager CM , who is in charge of encrypting documents, publishing them on IPFS, associating them to the right policy and addressing the key-request when U ful lls its requirements;
Ethereum, a public blockchain allowing the development of smart contracts. Once de ned all entities involved in our proposal, let's describe the steps of our solution:
In this rst phase, the CM associates the document di with the policy p^. If p^ does not exists, CM will generate it compliant with the XACML standard.
In particular, every category has a set of attributes related to and, as a consequence, a di erent policy. In our scenario, we refer to the category of healthcare data, where, for the sake of presentation, the attribute to be ful lled is to be a doctor.
CM encrypts di with a symmetric encryption function (such AES) by using the key related to the policy associated with healthcare data. Indeed, in accordance with the above, every category (and every policy) has a di erent encryption key. Let us denote by k^ the key associated with the policy p^. Now, CM obtains the encrypted document ei. The goal of this step is to publish on IPFS the encrypted document ei and the related policy p^. This could be achieved through di erent ways. Indeed, CM could simply publish it directly with an IPFS client. Anyway, accordingly to the accountability features aimed by our proposal, we allow the publication only trough the Ethereum smart contract. In detail, CM calls a function of the P SC through her/his Ethereum address ET HCM with ei as input obtaining as output the IPFS-hash hi related to ei. At the same time, CM calls another function of the same smart contract P SC to publish on IPFS the policy p^, if it still does not exist in the Ethereum environment, thus obtaining the IPFS-hash hp^.
At this point, CM maps hi with the corresponding policy hp^ on the P SC. The result is a mapping between the policy p^ and the list of documents associated with. Furthermore, there is a mapping between the area of interest (in this case, healthcare) and p^.
In this phase, the user U requests to ASC the policy that she/he has to satisfy related
to healthcare, obtaining hp^. Now, similarly to the Publication phase, U could obtain the
document directly with an IPFS-client, but again, our protocol enforces U to get it only
via ASC. At this point, U knows p^ and she/he can see that the attribute required is to be
a doctor. For the assessment of the attributes owned by users, we apply an eIDAS-based
approach [
U goes to ASP to request, by playing the role of Service Provider the assertion in which there is the information certifying the attribute to be a doctor; through a SAML2-compliant schema, ASP forwards the request to the Identity Provider IP ; after that, IP contacts the Attribute Provider AP (in the use case, the medical board) asking for the certi cation of the attribute being a doctor; now, AP sends the reply to IP , which will contact ASP to communicate the information obtained through an assertion. Finally, ASP returns to U the assertion and the nonce related to. In particular, the nonce allows applications to correlate the identi er of the assertion with the initial authentication request and it is used also to avoid replay attacks (see Section 5).
ET HU sends a transaction to ASC calling a function in which she/he puts the hashed identi er of the assertion and the nonce as input. The smart contract, now, has to verify the validity of the assertion and, as a consequence, the real possession of the attribute required by the policy p^. To do that, ASC invokes the Oracle O, that is in charge of checking the overall validity of the previous steps with IP .
If the check succeeds, ASC emits an event in which it con rms the satisfaction of the policy.
In this step, CM sees the event of success on the blockchain (it can be done via a client application that is able to show, and possibly lter, events) and CM sends a transaction blockchain to ET HU with the information about k^. Obviously, before to send the transaction, CM should encrypt the key to prevent from its disclosure to all blockchain. To reach this goal, CM encrypts k^ with U 's public key, obtaining EpUk(k^). The result is an ethereum transaction from CM to ET HU through the ASC having as input data EpUk(k^). We remind that input data is an optional eld of an ethereum transaction that can be used to share other information.
Finally, U is the only one who can decrypt, with her/his private key, the chipered key EpUk(k^). After the derivation of k^, U is able to dechiper also ei, thus obtaining di. 5
In this section, we brie y analyze the main security aspects that are involved in our proposal. This paper, indeed, can be view as a position paper presenting some results obtained in an industrial research project still alive. A more detailed analysis is then forwarded to the next steps of our work.
Let us begin with the de nition of the adversarial model, that is particularly relevant for our
proposal because by modeling the role of attackers, with their capabilities and goals, we could
help to improve the cyber defense [
In particular, the Access Service Provider could operate in a malicious way since it could give the wrong assertion to the wrong users. Anyway, this attack is contrasted by using the
coincide, so the ASP is not able to give the wrong response to the wrong applicant.
In sum, we do not require the ASP more trust then that one required by the eIDAS regulation. In addition to the standard security properties and assumptions, such as those ones related to the Ethereum blockchain and IPFS protocols, we assume that user's secret information and data are not disclosed to the public world and that users do not collude each other as well.
The goal of the attacker is to break, at least, one of the following secure properties: availability, non-repudiation, accountability, integrity and con dentiality.
In our proposal, data are stored on IPFS while their identi ers are stored on the Ethereum blockchain. This combination of these two technologies contrasts attacks on availability. Indeed, the usage of IPFS avoids the central and unique point of failure, since data are duplicated on multiple and random IPFS peers. Moreover, the DoS attack, in which the attacker oods the Ethereum network with a huge amount of requests, would be very expensive because every Ethereum transaction and every call to a function of an Ethereum smart contract has a cost in terms of gas.
Non-repudiation is obtained. In fact, every action is logged into Ethereum and it can be veri ed at any time and, in addition, Ethereum transactions are not editable after been mined. They are also signed by the Ethereum private key, that is known and kept only by the owner of the address. Furthermore, non-repudiation is ensured by our protocol also during the phases involving the publication of documents and policies on IPFS and the downloading of such les from IPFS. In particular, although these operations could be carried out by using a standard IPFS client application, we implemented an alternative approach, based on smart contracts, enforcing the non-repudiability of the overall protocol.
We can distinguish two di erent domains of interest: that one on the blockchain and the other one o -chain. Concerning the former, accountability is ensured similarly to the nonrepudiation property. Instead, if we think to the o -chain side of our proposal, accountability is reached because only the Identity Provider and the Attribute Provider(s) know exactly the link between the identity of the user and its related Ethereum address. So, if for any reason it is necessary to reveal this mapping, it could be done by merging information from di erent parties.
Data integrity is, again, reached thanks to IPFS by the usage of the IPFS-cryptographichash that is carried out for every document published on the InterPlanetary File System. Con dentiality is obtained as well, because sensitive and closed data are chipered by the Content Manager and the decryption key is given only to those users that ful ll the policy associated with them. Furthermore, the Content Manager, before sending to the user the key, encrypts it with the ethereum public key of herself/himself, that can be easily derived from the Ethereum address. So, even if the Content Manager sends the key by using Ethereum, nobody can actually understand it excepts for the interested user.
Finally, our protocol reaches the goal of privacy requirement, since the Content Manager is not aware of personal and sensitive information about users except for their attributes and their Ethereum addresses. In this case, the level of protection of these data is that one related to the pseudonymity provided by the Ethereum blockchain itself, that is not full. However, if the user wants to preserve better her/his privacy, she/he can generate a new Ethereum wallet for every operation, making attacks on pseudonymity not realizable anymore.
To implement our proposal, we used many di erent technologies and framework to integrate IPFS and XACML with ethereum smart contracts.
In particular, these are, among the others, the most relevant ones:
RemixIDE [
For the sake of presentation, we show only the most interesting details we faced during the implementation of our solution and we miss some other details.
First, we developed a JavaScript web-page containing a form allowing the submission of les on IPFS that interfaces with the smart contract showed in Figure 1 in a transparent way. 1 pragma s o l i d i t y 0 . 5 . 8 ; 2 3 contract SimpleStorage f 4 string ipfsHash ; 5 6 7 98 g 10 11 12 g 13 g function s e t ( string memory x ) public f
ipfsHash = x ; function get ( ) public view returns ( string memory) f return ipfsHash ; Moreover, the web-page returns the IPFS-cryptographic-hash identi er of the document submitted and all this operation is permanently stored in Ethereum. This is done thanks to the JavaScript code shown in Figure 2.
In particular, after the connection with the library web3js, captureFile is the function to bu ering the le once submitted on IPFS and onSubmit is used for the acquisition of the hash computed by IPFS. The operation carried out for the submission of the policy on IPFS via smart contract are the same. In Figure 3 there is the portion of the smart contract that is in charge of mapping the IPFS-hash of the document and its related IPFS-hash policy. 1 address content manager ; 2 mapping( string => F i l e ) public f i l e M a p ; 3 string [ ] public f i l e P o l i c y ; 4 5 constructor ( ) public f 6 content manager = msg . sender ; 78 g 9 modifier onlyCM ( ) f 10 require ( content manager == msg . sender ) ; 11 ; 1123 g 14 function createMapping ( string memory ipfsHash , string memory p o l i c y H a s h ) public onlyCM f f i l e M a p [ i p f s H a s h ] . i p f s H a s h = p o l i c y H a s h ; f i l e M a p [ i p f s H a s h ] . p o l i c y H a s h = p o l i c y H a s h ; f i l e P o l i c y . push ( i p f s H a s h ) ;
It is worth noting that the function createMapping can be called only by the Content Manager (in this case, the deployer of the smart contract) thanks to the modi er onlyCM. Indeed, the modi er is a function of Solidity that, when it is added to the declaration of a function, limits the access to the function itself to those users who satisfy its requests.
Another interesting aspect about the implementation regards the request of the policy from the Ethereum smart contract to the IPFS network because the policy is written with XACML, an XML-like language and there is need to parse the result. This has been solved as shown in Figure 4. 1 pragma s o l i d i t y 0 . 5 . 8 ; 2 3 import " ./ O r a c l i z e . sol " ; 4 5 contract P o l i c y i s u s i n g O r a c l i z e f 6 bytes32 public o r a c l i z e I D ; 7 string public r e s u l t s ; 8 event L o g O r a c l i z e R e s u l t ( string r e s u l t ) ; 9 10 11 1123 g 14 15 function i p f s ( ) payablef
OAR = O r a c l i z e A d d r R e s o l v e r I ( " a d d r e s s " ) ;
Now that the smart contract has obtained the attribute (or attributes) required by the policy, it compares it to the attribute that is in the certi cate presented by the user to the same smart contract. If the information completely overlaps, then the Content Manager generates a transaction to the user in which she/he speci es the key associated with the policy after encrypting it with the user's ethereum public key. 7
In this section, we investigate the state of the art regarding data access control on distributed information in a smart city environment.
For smart cities, cloud computing has become an important infrastructure as it can provide
secure and reliable data storage and sharing. However, in the cloud storage system, the cloud
server cannot be considered completely reliable. Therefore, several studies have focused on
access control for smart city data using the cloud. In particular, the study [
In [
Always in the context of smart cities, several studies were carried out relating to access
control and IoT. The IoT protocols must provide data security, in particular, they must guarantee
data updating, integrity, con dentiality, authentication, and access control. The access control
is perhaps the most important aspect of intelligent cities since the unauthorized access to critical
infrastructures can endanger the inhabitants of smart cities (i.g. unauthorized access to tra c
lights can cause accidents and tra c congestion and cause huge nancial losses). Access control
also faces several challenges such as limited resources of IoT devices, often with a limited power
budget. Furthermore, access control must provide a high degree of scalability. The study [
Unfortunately, the data collected and processed by IoT systems are vulnerable to threats of
availability, integrity, and privacy. The work [
Many studies have focused on the use of blockchain technology as an access control manager
for distributed systems. In [
Moreover, the authors of [
In the paper [
To the best of our knowledge, our proposal is the only one that tries to exploit the advantages of both smart contracts and ABAC into a smart city scenario with distributed information. 8
In this paper, we propose a solution based on Ethereum smart contracts for the access control on distributed information in a smart city scenario. In general, enforcing access control via smart contracts has the drawback that, although in pseudonymous form, the logic of access control is part of the smart-contract storage. Therefore, it is public, and this could be in general a serious threat to privacy of users and organizations. This drawback does not regard our approach, because the scenario we consider is that of access control policies attribute-oriented, of public utility for proper categories of users. Thus we can obtain the advantages in terms of transparency, veri ability, trustworthiness, accountability given by smart contracts. The integration with the eIDAS ecosystem for attribute certi cation, contributes to make concrete our approach, together with the state-of-the-art technologies used in our solution that are, besides Ethereum, XACML for the implementation of the enforcement into smart contracts and IPFS as distributed le system. As a position paper, this work does not include a careful security analysis. This is planned as future work, together with a full implementation of all the components of the solution.
This paper is partially supported by the project \SecureOpenNets-Distributed Ledgers for Secure Open Communities", funded by Ministry of Research and Education (MIUR), project id ARS01 00587. The authors are grateful to Laura Manganaro for her suggestions regarding the implementation aspects of our proposal.