Data is nowadays an invaluable resource, indeed it guides all business decisions in most of the computer-aided human activities. Threats to data integrity are thus of paramount relevance, as tampering with data may maliciously affect crucial business decisions. This issue is especially true in cloud computing environments, where data owners cannot control fundamental data aspects, like the physical storage of data and the control of its accesses. Blockchain has recently emerged as a fascinating technology which, among others, provides compelling properties about data integrity. Using the blockchain to face data integrity threats seems to be a natural choice, but its current limitations of low throughput, high latency, and weak stability hinder the practical feasibility of any blockchain-based solutions. In this paper, by focusing on a case study from the European SUNFISH project, which concerns the design of a secure by-design cloud federation platform for the public sector, we precisely delineate the actual data integrity needs of cloud computing environments and the research questions to be tackled to adopt blockchain-based databases. First, we detail the open research questions and the difficulties inherent in addressing them. Then, we outline a preliminary design of an effective blockchain-based database for cloud computing environments.
1https://securityintelligence.com/sabotage-the-latest-threat-to-the-financialbanking-industry/ and availability, once integrity is compromised there is no way to restore the original data, it is lost forever. Therefore, as integrity attacks are subtle to be detected and really effective, in this paper we focus on data integrity rather than confidentiality or availability.
Data integrity issues are exacerbated in cloud computing environments, as data owners
hardly control where their data are stored, who can actually access them, and in which way.
Nevertheless, more and more private and public organisations are outsourcing their data,
because “it relieves the burden of maintenance cost as well as the overhead of storing data
locally” [
Data integrity is commonly assured by using, on one hand, cryptographic tools (i.e., digests, asymmetric keys) and, on the other hand, appropriate data replication strategies. The cryptographic tools are indeed used to sign single pieces of data, so that any forging attack can be promptly detected via cryptographic signature validations. Indeed, an attack to be effective would require the violation of the secret keys, thus to update data signatures and circumvent the cryptographic integrity checks. These attacks are challenging to carry out, but once realised they are practically undetectable. Therefore, it is highly advocated to exploit appropriate data replication strategies to ensure anyhow data integrity.
Replicating and distributing data over a set of nodes critically hamper the violation of data integrity: an attacker should compromise, without being detected, all the replicated data. This replication approach is widely adopted in practice, like, e.g., in the context of cloud computing environments, where there is abundance of distributed storage resources. However, although replication surely increases the burden for a successful attack in a cloud setting, cloud providers themselves can collude with attackers for easily violating data integrity. To inhibit these collusion attacks and to avoid blind trust on the integrity guarantees claimed by cloud providers, we advocate an innovative exploitation of the blockchain technology to design and implement a distributed, secure blockchain-based database for cloud computing environments.
Intuitively, a blockchain can be seen as a replicated database distributed among thousands
of nodes belonging to diverse parties. In its first conception it has been used as public ledger for
Bitcoin transactions [
Despite the time-related obstacle, the intrinsic replication and distribution features of blockchains prompt their wide adoption in cloud settings. In this paper, we first shed light, by introducing a few open research questions, on the issues of employing blockchain “as-is”. Then, we present practical research directions that lead the way to effective blockchain-based databases for cloud computing environments. On the one hand, we elaborate on the issues of time-dependent integrity, lack of performance and absence of stability. On the other hand, we propose an innovative blockchain-based database that permits balancing strong integrity guarantees with appropriate performance and stability properties.
Structure of the paper. We first focus in Section 2 on a specific class of scenarios related to SUNFISH, a European project about secure-by-design cloud federation, and to the data threats its case studies prompt. In Section 3 we describe the blockchain technology, its data integrity properties and current limitations, while we outline in Section 4 the research questions to address to realise effective blockchain-based databases. In Section 5 we present our solution tackling such questions and its application to the SUNFISH cloud federation case study. Finally, after a brief discussion on related work in Section 6, we draw conclusions in Section 7. 2
Nowadays, an urgent need of public and private companies is to prompt and support
interoperability and cooperation among their already deployed (private) cloud systems (see, e.g., the
ENISA report in [
The SUNFISH proposal is Federation-as-a-Service (FaaS) [
The intrinsic goal of cloud federations is sharing services among members by creating regulated, secured inter-cloud interactions. The rules governing these interactions, hence the service usage, are defined in specific contracts. For instance, a member providing a service may require that only specific consumers can use it and that the service outputs have to be masked for privacy reasons. Due to the high sensitivity of the data managed by cloud federations (e.g., personal and medical data in case of the public sector), FaaS must provide high assurances about the compliance of the member contracts. Indeed, besides the runtime enforcing of the contracts, FaaS has to guarantee the integrity of contracts, namely that they cannot be tampered with and that all involved members must be aware of their existence. Additionally, to ensure non-repudiable evidences of contract enforcement, all the inter-cloud interactions have to be monitored and the logs stored with strong integrity guarantees.
Most of all, to foster a wide adoption of cloud federations, FaaS advocates the absence of a centralised governance. As a matter of fact, among federation members there cannot be designed a leader (i.e., there is no primus inter pares ), rather federation members form a network of peers. To this aim, FaaS seeks to establish a decentralised, democratic federation governance, hence it must rely on an opportunely defined, distributed database ensuring strong integrity guarantees. The novel design solution for FaaS advocated by the SUNFISH project is based on the exploitation of a blockchain. To properly address the feasibility of such a solution, significant threats to data integrity have to be identified. 2.1
The threats to the data integrity in the context of cloud federation can be multiple and variegated. Our focus is on the database storing the governance data of a federation, hence on data whose corruption critically affects the whole federation and its security. The threats we consider span from malicious alterations of data, to data updates without all the involved members informed. More specifically, we can enumerate the following threats: T1 An attacker violates the integrity of the data by directly altering (part of) the database. T2 A federation member updates the database without informing the other members. T3 Multiple federation members collude to maliciously altering (part of) the database.
Threat T1 is straightforward, while Threat T2 is due to the democratic nature of a SUNFISH federation. For instance, adding to the database a log entry about a fake inter-cloud interaction between members A and B, hence without the A and B being informed, is a clear integrity violation. Therefore, the process of adding data to the database should rely on opportunely devised consensus schemas. However, as pointed out in Threat T3, even consensus schemas can be attacked: federation members can collude together to alter the database integrity. For instance, given a member A providing to the federation a service s, the other members can collude to compromise s by, e.g., storing false information on the service (i.e., altering the contracts regulating the provisioning of s, or removing log entries about inappropriate uses of s) to obtain advantages and causing the detriment of A. 3
The blockchain is a quite novel technology that has appeared on the market in the recent
years, firstly used as public ledger for the Bitcoin cryptocurrency [
The original mining process, still used for Bitcon and Ethereum [
PoW-based blockchains enjoy many fascinating properties related to data integrity, which
follow from the mining process and from the full replication of the blockchain on a large number
of nodes. Indeed, when a block is part of the chain, all miners have agreed on its contents,
hence it is practically non-repudiable and persistent (unless an attacker has the majority of
miners’ hash power that are able to create a fork of the chain). Assuming a majority of hash
power controlled by honest miners, the probability of a fork of depth n is O(2−n) [
However, PoW-based blockchains have a main drawback: performance. This lack of
performance is mainly due to the broadcasting latency of blocks on the network and the time-intensive
task of PoW. As a matter of fact, each transaction stored on a blockchain has a high
confirmation latency, which causes an extremely low transaction throughput. In Bitcoin, the average
latency is 10 minutes, and the throughput is about 7 transactions per second [
Another relevant concern related to the use of the blockchain regards its stability. Although,
e.g., the Bitcoin’s blockchain has worked quite well so far, there is no universally accepted
academic work explaining either why this has happened, or whether it will continue in the
future, or how long it will [
In the context of cloud computing environments, the blockchain could be exploited to realise a database ensuring strong integrity guarantees. In particular, the blockchain could be used to store the logs of database operations, thus to avoid the data threats presented in Sec. 2.1. However, current blockchains cannot be employed “as-is” due to various deficiencies. In the following, we address the main issues related to data integrity, performance limitations, and blockchain stability.
How to Measure Data Integrity? Once data has been included in a block, if we assume a majority of honest miners, we can be highly confident that the chances of data alteration decrease exponentially over time (see Sec. 3). Data integrity is indeed strictly related to these chances. The more unlikely it is that data can be tampered with, the stronger the integrity guarantees we can claim. However, being dependent on time introduces critical aspects to address for ensuring data integrity: there is hardly information on the effective integrity guarantees once a transaction has just been sent to the blockchain. These observations suggest that data integrity on blockchain cannot be simply seen as a binary property, which either holds or does not, but it should be intended as a more complex, quantitative concept. This amounts to take multiple factors into account, including the time and parties’ awareness. The described issues thus lead us to formulate this research question: Q1 How can we quantitatively characterise data integrity guarantees, in order to enable comparison among different blockchain-based database solutions? Reasonable approaches to answer to this question should be based on the the effort an attacker would spend to compromise data integrity without being detected.
How to Improve Performance? The performances currently achievable with PoW-based blockchains are really poor as compared with classical database technologies. The experimented latency and throughput are almost incompatible with the requirements of the considered cloud scenarios. In this sense, a challenging and fundamental research problem regards the investigation of novel blockchain designs aimed at delivering performances aligned to today’s requirements, while keeping the needed integrity guarantees.
Q2 How can we design a blockchain-based database with better performances compared to a
PoW-based blockchain “as-is”, and with comparable data integrity guarantees? The resulting designs should be flexible enough to enable variable tradeoff between performance and integrity, thus to choose the setting that better fits the requirements.
How to Enhance Stability? Current PoW-based permissionless blockchains rely on a marketdependent cryptocurrency that may make the storing of data highly expensive and too dependent on market variations, i.e. it cannot ensure stability. Likewise poor performance cut out many possible practical applications, unsatisfactory stability assurances can severely restrict the applicability of blockchain to database. Enhancing the stability of PoW-based permissionless blockchains, e.g. Bitcoin’s, amounts to alter the currency incentives underlying the mining process. Due to the large economic interests and speculation behind cryptocurrencies, such an amendment is practically infeasible. A more viable path is exploiting permissioned blockchains, where incentives do not depend on cryptocurrencies. The described path corresponds to answering the following research question: Q3 How can we setup a permissioned blockchain having stronger stability compared to existing
PoW-based blockchains, while preserving required guarantees on data integrity? The resulting blockchain will guarantee a stable support for the development of distributed databased, as it is needed, e.g., in cloud computing environments. 5
In this section we tackle the research questions just raised and we outline our proposal for a more effective blockchain-based database. This proposal is thus intended to be part of the SUNFISH project for ensuring high data integrity guarantees (hence, to deal with the data threats presented in Sec. 2.1) and, at the same time, for being compliant with the performance and stability requirements needed in a cloud computing environment.
Our blockchain-based database aims at providing a replicated database whose integrity is testified via adequate evidences stored on a innovative designed blockchain system. Namely, we devise a two-layer blockchain that, via the first-layer, ensures adequate performance and, via a principled exploitation of the second-layer, ensures strong integrity guarantees. More specifically, the first-layer employs a lightweight distributed consensus protocol that assures low latency and high throughput. This layer aims at quickly and reliably storing evidences of every operations carried out on a distributed database. However, this layer provides weak data integrity guarantees due to the lack of PoW. Thus, the second-layer is designed as a PoW-based blockchain that stores evidences of (a part of) the database operations logged by the first-layer. These evidences are stored with strong data integrity guarantees but with poor performance. Indeed, the principled interaction between the two layers permits obtaining an overall performance improvement and effective assurances on data integrity.
In the following, we first present our proposal (Sec. 5.1), then we comment on the research questions (Sec. 5.2) and finally show how the proposal deals with the identified threats (Sec. 5.3). 5.1
In this section we introduce our proposal for an effective blockchain-based database. Blockchain is appropriately exploited to ensure the integrity of distributed replicas of a database, i.e. to store persistent evidences of the database operations that cannot be repudiated. The use of blockchain ensures not only integrity guarantees, but also fully distributed control of the database data. This intrinsic characteristic makes our proposed database feasible to be used in the context of FaaS federations. Figure 1 graphically depicts the proposed blockchain-based database distributed on three clouds member of a federation.
The member clouds operating on the database issue operations through the Database Interface. The operations are first logged via appropriate evidences by the the first-layer blockchain, then they are executed on the distributed DB replicas. More specifically, the first-layer blockchain is permissioned, and features one miner on each member cloud. The miners, by relying on a public/private key pair to sign messages, achieve consensus by means of the socalled mining rotation consensus mechanism. Namely, it divides the time into rounds and, for each round, elects a miner as a leader. The leader is then in charge of receiving new operations, signing them with its private key, and broadcasting them to the other miners. Once all miners have signed the operations, they can become part of the blockchain: all the miners add these operations to their local ledger, and apply them to their local replica.
The interaction with the second-layer PoW-based blockchain is realised via a blockchain anchoring technique. The anchoring technique is a timed operation that permits linking a specific (part of) the first-layer blockchain with (a block of) the second-layer blockchain. In particular, at certain intervals of time, a witness transaction containing the hash of the first-layer blockchain up to the current operation is sent to the second-layer blockchain and, consequently, stored as immutable, irreversible transaction. These hashes act as forensics evidence for proving and validating the integrity of the data stored in the first-layer blockchain. 5.2
In the following, by referring to our proposal for blockchain-based databases, we introduce our preliminary answers to the research questions previously reported.
Measuring Data Integrity. Our answer to Question Q1 is to measure the integrity as the effort required for an attacker to change data in the blockchain without being noticed. Quantifying this measure highly depends on the nature of the considered blockchain, but in general a desiderata is that the longer data are stored in a blockchain, the greater the effort an attacker should pay to break data integrity.
In our two-layer blockchain, the integrity measure on the evidences of a database operation
is crucially affected by which of the chain contains the evidences. Indeed, if the evidences are
only on the first-layer, the effort required for an attacker corresponds to compromise all the
replicas of the first-layer. However, as soon as the hash of the corresponding evidences has been
stored in the second-layer, an attacker should also subvert the integrity of the PoW, thus the
data integrity measure would be higher. As a matter of fact, on PoW-based blockchains like
Bitcoin’s, the attacker effort is close to infinite [
Enhancing Stability. Permissionless blockchains like Bitcoin’s and Ethereum’s are natural candidates for the second-layer blockchain. To enhance their stability, i.e. Question Q3, we advocate the use of a blockchain that does not feature a market-dependent cryptocurrency and mining incentive mechanisms. Broadly speaking, the stability needs for blockchain highly depend on the application context. For example, in the case of the SUNFISH case studies, which address the European public sector, the need of stability is of paramount importance. In this context, we could hence envision a European permissioned PoW-based blockchain that will offer a common, stable underlying support for all European administrations. 5.3
With reference to the threats outlined in Sec. 2.1, in this section we explain how the solution we propose successfully addresses them.
The effort required for an attacker to tamper with stored data (Threat T1) has been previously discussed in this section. At the very least, all the miners of the first-layer blockchain should be compromised, e.g. stealing their private keys. In the setting of FaaS, this would requires attacking multiple distributed cloud providers simultaneously. Even if this unlikely situation occurs, the anchoring with the second-layer blockchain ensures that only the latest set of operations on the database can be subverted; all the others are testified by immutable, irreversible evidences.
The consensus algorithm featured by the first-layer blockchain takes by design into account all the miners, hence the member clouds. Therefore, there cannot be any database operation completed without all the members being aware of it (Threat T2).
Collusion attacks (Threat T3) are instead equivalent to compromising first-layer blockchain miners. All the private keys of these miners are required to sign the messages needed to complete a database operation, thus even in the case of a single honest member attacked by a coalition formed by all the others, such honest member could successfully react. Namely, it could prevent a malicious database operation to complete by not sending its message within the consensus protocol. If the coalition attack was instead aimed to alter an information already stored in the first-layer blockchain, this means that such information has been previously agreed on by all the members, thus an honest member could then prove it owns the intact version by showing the messages previously signed and sent by the other members (when the consensus on that information was firstly achieved). 6
Data Integrity is a well known problem in computing systems, especially for cloud environments,
where users outsource their data. The task of checking data integrity for a user having relatively
poor computing devices might be very heavy due to huge amount of data to download. Ateniese
et al. [
The first-layer blockchain we use to improve performance is inspired by Bitcoin-NG [
A remarkable work aimed at improving performance while providing security guarantees
is RSCoin [
In this paper we identified the requirements and research questions to be addressed to realise a blockchain-based database for cloud computing environments, grounding on real needs arisen in the European project SUNFISH. Our main contribution is the proposal of a high-level solution which answers these questions, and lies the foundations for the design of a blockchain-based database able to provide the desired guarantees on data integrity, performance, and stability.
This work paves the way to appealing future works. The direction we propose can be further investigated by realising a working prototype to validate the effectiveness of our solution, in terms of achievable latency and throughput. Furthermore, a more thorough and formal examination of the tradeoff between performance and data integrity guarantees is required to prove the efficacy of our design against the identified threats. It is worth finally noticing that our blockchain-based database proposal, in this preliminary design, has been designed upon a total consensus mechanism. The approach surely permits to achieve integrity among the distributed replicas and to simplify the thread addressing. However, its availability can be critically affected by violating only a single miner. On the path of deploying such a database, we are designing an appropriate fault-tolerant consensus algorithm that permits combination of integrity with also availability. Finally, researching on the feasibility of realising more stable blockchains is fundamental to enable their wide adoption as reliable storage infrastructures, e.g. in the context of cloud computing environments.
This work has been supported by the European Commissions H2020 Programme under the SUNFISH project, grant N.644666.