It is very often the case that critical data or critical devices are co-managed by stakeholders from different domains. Any access to such resources should ideally be transparent to all stakeholders involved, and the access itself should comply with any policies set by the resource owner(s). However, this is not what usually happens in today's systems.
Let's take for example the case of a smart medical device. Although the device is acquired by a hospital,
its tuning might be performed by a certified partner of the vendor. Any changes made by the certified partner
to the medical device firmware or configuration, should be transparent to the hospital's medical and technical
staff. In the same way, the changes should also be transparent to the device vendor technical staff. Moreover,
once a change has been made it must not be repudiated as the change may carry serious repercussions (such
as patient injury or lead to wrong diagnosis / treatment by doctors).
For an action to occur on the medical device it must comply with the access policy
requirements set by the hospital. However, the actor in this case (the certified partner employee)
might not be an entity known by the hospital information systems and therefore it might not be
possible to apply a fine-grained systems level policy to cover the related actions. In such cases, it is often the
case that unlimited rights are granted to the technician making the changes, and his/her identity
is authenticated at the systems level through shared (hard-coded) service credentials that are
embedded in the device. These credentials present a potential risk for the security of the device hosting
organization and they cannot be easily managed. Moreover, the certified partner acts in a way that is
not transparent to the hospital's staff, "hiding" behind the partner's contractual relationship with the vendor.
If we look at the various requirements and issues we've mentioned up to now, it becomes apparent
that if access is authenticated through cryptography and mediated through a blockchain architecture
then it would be possible to have all stakeholders become witnesses of any access attempt made to the critical
resource. Access policy rules may be implemented as smart contracts upon the blockchain infrastructure, however
there is still one important piece of the puzzle missing. How are we going to refer to an actor's identity (and/or relevant cryptographic keys) in our policy, when such actors are not known beforehand and are not part of the device hosting organization (or not even the domain the organization belongs to)?
The paper entitled "A hierarchical multi blockchain for fine grained access to medical data" by Vangelis Malamas, Panayiotis Kotzanikolaou, Thomas K. Dasaklis and Mike Burmester provides a solution to this problem. It combines blockchain technology
with Ciphertext-Policy Attribute Based Encryption (CP-ABE), where holders of some commonly agreed attributes (e.g. someone bearing the role of a researcher, or a doctor etc.) are able to decrypt the relevant data. Each organization then simply needs to generate the required keys for its subjects and then notify others on the blockchain
platform about these subjects. Subject rights (or attributes if you like) may also be provided under a lease, with an organization stating that the referenced subject holds this attribute only for a certain period of time (e.g. on-duty doctor in ER, this Friday 08:00 to 16:00).
The paper uses two layers of blockchains (i.e. it is a hierarchical multi-blockchain system) where the first
layer disseminates events (such as access requests) and subject information to all stakeholders, regardless
of the domain they belong to, while the second layer disseminates information within particular domains (e.g. hospitals, device vendors etc.) and applies intra-domain policies. Once an access request lands on the first layer (also known as "proxy blockchain"), it is routed to the second layer (the "domain blockchains") for domain-specific processing, and only then reaches the information systems of the resource provider. Please note that the platform considers that the sensitive information found in the information systems of the resource provider are already encrypted using two methods, against a key that is domain-specific and against a suitable key for the intended (attribute-wise) audience. Therefore the information can only be
reclaimed after passing through the domain-specific blockchain and then by applying a suitable operator key (a key holding the appropriate attributes) at the client side app. To be precise, the information found in the resource
provider is protected through standard symmetric key encryption, however the relevant encryption keys are then
protected through the above elaborate encryption scheme.
As part of the ΜΕΛΙΤΥ national research project, CENSUS created Janus, a proof-of-concept implementation of such a system, using Hyperledger Fabric for the blockchain implementation and a custom Hashicorp Vault plug-in for secure key management. The proof-of-concept implementation considers an information system deployed by a fictitious governmental organization, where users from different stakeholder institutions (of different domains, e.g. Hospitals, Medical Device Vendors) gain access to the system via Electron app clients. Such an Electron app client will authenticate to and communicate with a back-end system belonging to the relevant stakeholder. Hospital Researchers may typically query the platform for disease data across hospitals connected to the system, doctors in ER may query across hospital databases for records of a patient that is currently in ER, while medical device vendors may conduct queries regarding the installation base of a particular medical device and its firmware status. Such sample requests are demonstrated on the video shown below.