The explosion of the digital technologies is afecting several and diferent sectors. In this scenario the public sector has a crucial role. The eGovernment (eGov) sector has to adopt the necessary methodologies and technologies in order to enable the digital applications for the own clients, namely the citizens. A powerful data sharing together with the data integrity and the temporal traceability is strongly recommended in the public sector. This concept is an important key factor for the transparency between citizens and the public entities. In this direction the Proof of Existence (PoE) gives the possibility to certify the ownership of a specific document. The paper analyzes the diferent architectures for the information systems used in typical public scenarios. Peer-to-peer architectures as Bitcoin blockchains also analyzed in order to evaluate their contribution for a transparent PoE in a public context. The final conclusions remark the importance of the data integrity verification and the temporal traceability enabled by the bitcoin blockchain.
1. Introduction between citizens and the public entities. In this direction the Proof of Existence (PoE) gives the possibility to certify the ownership of a specific document. The paper presents how the bitcoin distributed architecture is useful for the PoE in a public context. The section 2 illustrates the traditional approach for information systems and the diferent architectures used for eGov. The section 3 describes the bitcoin blockchain technology. The section 4 analyzes a possible implementation of a blockchain-based information system for eGov applications. In the section 5 final conclusions are evidenced.
The explosion of the digital technologies is afecting
several and diferent sectors: eHealth [
One of the most challenging applications is the public sector, whose scenario has a crucial role. The eGov- In the eGov context, the interaction between citizens ernment (eGov) sector has to adopt the necessary me- and public entities takes place in diferent ways dethodologies and technologies in order to enable the pending on the information systems and architectures digital applications for the own clients, namely the cit- that are used. By the first proprietary information sysizens [18]. This digitalization process forces the public tems we moved to the cloud-based information followentities to guarantee the integrity of the digital data ing diferent paradigms, as Service as a Service (SaaS), exchanged not only with the citizens but also with o- Platform as a Service (PaaS), Infrastructure as a Service ther public entities. A powerful data sharing together (IaaS). All these information systems can be based on with the data integrity and the temporal traceability is diferent architectures: centralized, decentralized and strongly recommended in the public sector. This con- distributed scheme [19]. All of them present issues recept is an important key factor for the transparency garding security and data management. In particular, in case of a document transmission procedure or digital payments, the necessity for guaranteeing data integrity is very important [20].
© 2020 Copyright for this paper by its authors. Use permitted under Creative CPWrEooUrckReshdoinpgs IhStpN:/c1e6u1r3-w-0s.o7r3g CCoEmUmoRns WLiceonrsekAsthtriobuptioPnr4o.0cIneteerdnaitniognasl ((CCC EBYU4R.0)-.WS.org)
In a centralized information system, each client can The figure 2 depicts a decentralized information sysinterface with a single server for a given service [21]. tem [22]. The server 2 and server 3 are linked among As shown in Figure 1, if the citizen A needs to bene- theme and they interact with the citizen B. The citizen ift from the services of the municipality will be con- A instead interacts with the server 1 because he has a nected to the dedicated server (server 1). If the citizen municipality active session.
A needs for interaction with Tax Register (server 2) or Server 2 and server 3 interact with each other but Land Register (server 3), he has to open other sessions not with the server 1. They cannot share the data stored on diferent server (e.g. server 2 and server 3). In this on the server 1. We have only a partial sharing of inforsystem, the citizen A may prove the PoE only to the mation: from/to server 2 to/from server 3. The secuserver 1 within the same session. In order to submit rity management can regard the server 2 and server 3. the PoE to the server 2 and to server 3, the citizen A Server 1 can follow other policies or trusted third party needs to: certifications. The data repository is centralized for each data type or service. Security policies are man• connect to them aged by a trusted third party. Since not all the servers are linked among them, the data sharing is quite dif• open other sessions ifcult and it can be afected by errors. Data integrity • transfer the signed document should be guaranteed by a trusted third party. In a system of this type, the citizen A is in the same situation described in the previous section. Citizen A may prove PoE only to the server with an active session. In case of PoE submission to the server 2 and server 3, citizen A needs to connect to them, to open other sessions and transfer the signed document. The citizen B can instead submit the PoE to the server 2 or to the server 3 thanks to the active session on server 2. Anyway, he cannot forward it to the server 1. In order to do it citizen B has to open a new session on it. In this scenario the same issues of the previous scenario are identified: PoE corruption, digital identity theft and alteration of e-mail notification.
stead can forward the PoE to the server 2 or to the server 3 server thanks to the active sessions. Anyway, the citizen B cannot forward the PoE to the server 1. To do it, the citizen B has to open other session on the server 1. The data repository is centralized for each data type or service. Security policies are managed by a trusted third party. Since not all the servers are linked among them, the data sharing is quite dificult and it can be afected by errors. Data integrity should be guaranteed by a trusted third party. In this scenario several issues can be identified. The PoE can be altered by the citizens and the public entities. In fact, timestamp or the document can be modified. The digital identity of the citizen A can be stolen or snifed. The e-mail notifications can be also corrupted.
client nodes can connect to one of the network servers. As shown in the figure 3, the citizen A may access the services of the municipality through the server 1. If the citizen A needs to access the other servers, the server 1 can manage the interconnections with them. The citizen B is in the same situation of the citizen A. After accessing the server 3, he can be redirected to the server 2 or server 1 for other services.
All the servers can interact among them. This enables the data sharing. Security vulnerabilities can also occur in this scenario. The PoE can be altered by the citizens and the public entities. In fact, timestamp or the document can be modified. Data integrity should be guaranteed by a trusted third party. The PoE can be altered by the citizens and the public entities. In fact, timestamp or the document can be modified. There is any possibility to prove the temporality of the actions of the data.
system can adopt a peer-to-peer scheme. All the nodes can represent either client either server (Figure 4). This scenario is well modelled by the bitcoin blockchain. It refers to a “Public Distributed Verifiable Cryptographic Ledger” [23] [24]. These important properties are deifned as follows: • Ledger: is a verifiable transactional database. Every peer can download locally the ledger and then hold it on a local device.
actions exchanged among them. The technology uses ECDSA cryptography curve to authenticate and identify the nodes. Moreover, it allows the nodes to securely manage and add transactions to the ledger. The transactions are verified and confirmed by dedicated nodes (mining nodes). This implies there is no need for a central authority [25].
When a peer wants to connect to the bitcoin blockchain, it has to download a dedicated software tool. This generates a couple of keys, a private and a public key locally, which are to be used for transactions.
• Private key: 256-bit hexadecimal number • Public key: 130-bit hexadecimal number • Bitcoin address: 160-bit hash of the public portion of a public/private ECDSA keypair • Amount of bitcoin to spend 3.2. Transactions
the Unspent Transaction Output (UTXO). The unlock- In the bitcoin blockchain, each block of data is linked ing script is a dedicated script containing the condi- to the successive with specific criteria based on transtions enabling the transactions between the nodes. Fi- action hashing. When a block is validated and another nally, a sequence number is present. It is a number block needs for validation, a Merkle Tree cryptograused for updating unconfirmed time-locked transac- phy scheme is adopted (Figure 7). In fact, transactions tions before their finalization. It is currently disabled. ID are hashed through a double SHA (256) algorithm, Figure 5 shows an example of bitcoin transactions. as shown in Figure 7.
The result of this double hash is put into the block 3.3. Block Information header as TX_root record. Prev_Hash record in the current block header is the result of the previous block All transactions are included in blocks. Each block hashing using SHA (256) algorithm. contains information of several transactions made by This mechanism for chaining the data blocks gives the nodes belonging to the blockchain. These informa- the possibility to trace all the transactions between the tion are globally published and distributed. As shown nodes in terms of how, from-to and when an amount in the Figure 6, they mainly refer to: of bitcoin was spent.
block has to be validated by the miner nodes. The proof of work is a set of data to hardly produce for some nodes and easily for other ones.
Bitcoin blockchain adopts the hashcash proof of work based on a partial hash inversion. A miner node must complete the proof of work requested by a specific block. The dificulty of this work is runtime adjusted in order to respect the maximum temporal interval of 10 minutes for the generation of a new block. A block is validated if its hash result is less than a target value. After a block validation, a miner node receives a reward (e.g. in bitcoin) for the completed work.
Some strategies for securing data in applications concerning smart objects have been proposed in the literature [26], [27]. Nevertheless, the bitcoin blockchain, with its decentralized structure, can be very useful in the eGov scenario. The possibility of the nodes to communicate in a peer-to-peer modality is positive from a social participation point of view. Citizen and public entities are nodes of the same blockchain. They can read, write and share the same data included into the blocks. This approach can increase the citizen’s trust in public authorities. The need for transparency by the citizens is an important enabler for a blockchainbased infrastructure. In the previous eGov infrastructure it is not possible by the citizens or public entities to assure the Proof-of-Work of a document and to guarantee the data integrity without the involvement 4.1. Processes of a trusted third party. In any case this cannot exclude the risk of data corruption of modification. In a peer-to-peer scheme as that provided by the bitcoin blockchain, the involvement of a trusted third party for the security certification is not necessary anymore.
Citizens and public entities have the same permissions (Figure 8). In this context Municipality is the Peer 1, the Tax Register is the peer 2, the Land Register is the Peer 3, the Parking Center is the Peer 4, Citizen A is the Peer 5 and the Citizen B is the Peer 6. They can manage and share the data among them through the blockchain.
The data exchange in the bitcoin blockchain is enabled by a specific record of a transaction called OP_ RETURN [28]. It a valid opcode used in a bitcoin not spendable transaction, which allows the insertion of a data stream with a maximum length of 80 Bytes. In this way the citizens can share the hashes of documents (e.g. SHA (256)) through the OP_RETURN opcode. The peers hold a local copy of the bitcoin ledger containing all transactions among all the nodes belonging to the blockchain. Finally, the peers manage the same wallet as defined in Section 3.
traditional and the blockchain-based.
The traditional approach expects the document sendon a pair of keys (public key and private key). The previous network architectures manage services and data with the involvement of a trusted third party for the security certification. The blockchain scheme does not need it. All the nodes participate to the blockchain and guarantee themselves. They can share data with anonymity. The Bitcoin Address is used for authentication and 2-factor authorization. The other network architectures use a User ID (UID) and a Password (PWD).
They can be afected by a temporary server unavailability with negative efects on services and data exchanged.
Adopting a peer-to-peer scheme, a blockchain architecture can guarantee the connection of at least one server. Anyway, each node holds locally a copy of the ledger containing all transaction information. Finally, the most important aspect is related to the data integrity and to the temporal data traceability. All timestamp stored in the blocks are linked among them. It is quite impossible to modify or corrupt a particular data block because an attacker should resolve all hashes of all the data blocks belonging to the bitcoin blockchain. ing to a specific server. The control of data integrity can be separately performed by the citizen and public entities control on own devices. Each of them can verify a data integrity that can be diferent from the other. With the blockchain-based approach, the citizen A can access the server 1 for municipality services. He can compute the document hash and store it into the OP_RETURN record of an unspendable bitcoin transaction. The same situation is for the citizen 5. Conclusion B. Once the not spendable transaction is confirmed, the document is oficially certified and demonstrated The necessity for guaranteeing the integrity of data to exist before the time the transaction was confirmed. and consequentially the PoE is an important topic for In this way the other peers (server 2 and server 3) from the eGov environment. This enable a major transpapublic entities can verify the PoE. Within the bitcoin rency and trust in the public entities by the citizens. blockchain, they can search for the following informa- Since the public entities will become more digitalized tion: in the next years, the information systems have to base on reliable network infrastructures. This paper ana• Bitcoin Address of citizen A lyzed diferent preferred information configurations: • Transaction ID (TxID) centralized, decentralized and distributed. All of them can be afected by the risk of the data corruption. The • Block height PoE becomes crucial to certify by citizens or public entities. A blockchain-based system can be used for 4.2. Block information PoE guaranteeing thanks to its peer-to-peer scheme. Citizens and public entities can exchange hashed data The corresponding block is shown in Figure 10. We stored in an option bitcoin record, the OP_RETURN. In suppose it as the successive block of block listed in this way the data integrity can be verified comparing Figure 4. Not only data in the present block header the exchanged hashes. Moreover, the temporal traceare diferent from the previous one, but also those in ability is also made possible due to the linked timesthe block body. Being a not spendable transaction, the tamps stored in the block headers. Next works will corresponding amount is equal to 0.0 Satoshi. Hashes be focused on an experimental implementation and on are put into the OP_RETURN of an unspendable trans- innovative hashing algorithms for data integrity guaraction. They are included in the block. anteeing.