## 4 HMBAC Design and Implementation
### Janus Implementation
#### 4.3.5 Distributed ABE Decryption Implementation  
As described in Section 4.2.2, our goal is to cryptographically enforce a single point of entry for the system users; which means that even if a user has all the roles required for accessing some data, an extra layer of encryption will prevent access to the data outside the Janus system. The challenge, from an implementation perspective, is to create a cryptographic mechanism that will force users to access the data only through the application while ensuring fined-grained access according to predefined access policies and at the same time will remain resistant to collisions. To achieve this, we modified the implementation of the MA-CP-ABE scheme of [7], by distributing the decryption functionality between the user and the domain blockchain. We used as a basis the Python implementation of the original scheme in the _Charm_ encryption library.  
Since directly applying ABE encryption and decryption is not efficient, we have applied a hybrid encryption approach, where the data are symmetrically encrypted, while the symmetric keys are ABE encrypted. In each stakeholder database, each data item, say \(d_{i}\), is initially encrypted with a distinct symmetric (AES) key \(k_{i}\) as: \(c_{i}=AES(d_{i},k_{i})\). Then, each data encryption key \(k_{i}\) is encrypted by ABE, based on all access policies that allow access to the particular item, which are extended to include the domain attribute key of the relevant domain. For example, assume that personal information \(d_{i}\) of a patient should be available to the patient's family doctor or any doctor in the case of emergency treatment of the patient. In that case, the key \(k_{i}\) would be encrypted by ABE as follows:  
\[e_{1} =Enc\big{(}k_{i},\mathbb{P},\mathrm{GP},\{PK_{doctor},PK_{fDoctor},PK_{H}\}\big{)}\] \[e_{2} =Enc\big{(}k_{i},\mathbb{P},\mathrm{GP},\{PK_{doctor},PK_{onDuty},PK_{H}\}\big{)}\]  
Each symmetrically encrypted data item \(c_{i}\) is sent to the DBC through the Database API, along with all ABE encryptions of \(k_{i}\), in this example \(e_{1},e_{2}\). The KSSC has access to the domain's vault, where the hospital domain attribute key pair \(PK_{H},SK_{H}\) is stored. Using \(SK_{H}\) it will generate _on-the-fly_, the hospital domain attribute key for the requesting user, i.e., \(K_{\mathit{UL\, hospitals}}=\mathit{KeyGen}(\mathrm{GID}_{\mathrm{U}},\mathrm{GP}, \mathit{attr.hospitals},SK_{H})\) and use it to partially decrypt the data. The user will be able to actually decrypt the data, only if: (i) the KSSC has partially decrypted the data with the domain attribute key and (ii) the user has the relevant attribute keys for (at least) one of the above access policies, i.e., \(\{K_{\mathit{UL\,doctor}},\ K_{\mathit{UL\,fDoctor}}\}\) or \(\{K_{\mathit{UL\,doctor}},\ K_{\mathit{UL\,onDuty}}\}\).  
We implemented the MA-ABE decryption scheme of [7] in Go as a Hashicorp Vault plug-in and integrated this into KSSC. The KSSC may trigger \(sysDecrypt()\), executed in the domain's Vault instance, which generates the domain attribute key for a given GID and uses it to perform partial ABE decryption. In this way, the domain attribute key is accessible only for requests that have already been authorized by ACSC. At the same time, it is never given to users, to prevent off-system data access.