This work focus on the auditability of information systems at the public administration. On such systems, end-users perform actions that leave digital traces. Such traces are recorded and stored in log files (or audit logs), which are analysed when needed.
JusticeChain proposes using blockchain technology to make the storage of access logs more resilient while supporting such a multi-stakeholder scenario, in which different entities have different access rights to data.
Why the need for this expensive technology? In the case of the Portuguese Judicial system, there are several stakeholders with different trust levels, hence justifying the utilization of a technology that decentralizes trust.
The blockchain that was used was Hyperledger Fabric because it is a permissioned, private, scalable blockchain, that can address the primary needs of the government. If you do not know how Fabric works, check my article, which provides a wide overview. The solution is divided between the blockchain client components and the blockchain components.
The blockchain components have two components:
1) The log manager aims to allow an information system to store applicational logs, gathered by an oracle. The oracle captures logs from an information system and redirects them to the JusticeChain client.
2) The audit manager allows authorized entities (e.g., auditors) to retrieve the contents of the blockchain (i.e., audit logs, transaction history). It is accessible by auditors and network admins.
The only entities that can create audit logs are Loggers (loggers can not update or delete them). Auditors and Network Admins can see the audit logs they are entitled to analyse, but can not create, delete or update them. The blockchain components are implemented with NodeJS and the Hyperledger Composer API (soon available on my Github).
The blockchain components are implemented with Hyperledger Composer. Hyperledger Composer is an abstraction built on top of Hyperledger Fabric and makes the chaincode development easier.
The data model embedded in the Composer definition is the following:
The asset to protect, Log, can be of different types. A Logger creates Logs, and an Auditor can access logs, depending on the permissions. Administrators from different stakeholders manage the Logger and Auditor entities in a distributed way (i.e., manage their attributes and permissions).
Chaincode written in Javascript implements the logic described above, and Composer access control rules enforce the restrictions concerning the --audit logs' access.
Concerning the blockchain solution, we have a consortium formed by four organisations (A, B, C, L), operating on channel C1. The network has an orderer O, which follows network configurations NC, and belongs to organisation L. There are two chaincodes installed on peers.
Chaincode S1 allows peer nodes to query audit logs, while chaincode S2 allows peers to create applicational logs. Therefore, only peer nodes that correspond to Loggers should have S2 installed. L-CA is the certificate authority, managed by the leading organisation, L. A certificate authority issues cryptographic identities for all participants on the network. Finally, the blockchain client components are connected to the blockchain (via channel 1).
In the next article, more details about the blockchain and blockchain client components will be presented and analysed, as well as our evaluation methodology (spoiler, using Caliper).
I hope you liked it 😃. Please make sure to check my Github Sponsors page🚀
Thanks very much for reading 🙏. You Rock 💪