## 4 HMBAC Design and Implementation
### HMBAC Architecture Design  
The system architecture is designed with real-world requirements in mind, notably those of the medical sector. Note, however, that other digital environments can easily be supported. Figure 3: HMBAC access model: element sets and relations. \begin{table}
\begin{tabular}{c} \hline \hline \multicolumn{2}{c}{**Basic Sets and Functions**} \\ \hline -_U, Au, S, K, D:_ finite sets of users, authorities, subjects, keys, domains \\ -_UIA, OA, AK: finite sets of user, object and keys attribute functions \\ - _PBC, DBc:_ fine sets of Proxy and Domain blockchain services \\ -_IDP, CDP:_ fine sets of inter and cross domain policies \\ -_OB, OP, DAS:_ fine sets of objects, operations and data services \\ -_attType_ : \(UA=\{set\}\), defines user attributes to be set valued only. \\ -_attType_ : \(AK=\{set\}\), defines keys attributes to be set valued only \\ Each attribute \(att_{U}\) in \(UA\) maps users or authorities to a set of attribute \\ values in \(Range(att_{U})\). Formally, \(att_{u}:\)\(U\cup Au\to 2^{Range(att_{U})}\) \\ Each attribute \(att_{OB}\) in OA maps objects in OB to attributes values. \\ Formally, \(att_{OB}:OB\to 2^{Range(att_{U})}\) \\ Each attribute \(att_{K}\) in AK maps keys in K to attribute values. \\ Formally, \(att_{K}:K\to 2^{Range(att_{E})}\) \\ Direct \(UAu:\)\(U\to 2^{Au}\), mapping each user to a set of authorities. \\ Direct \(DAu:\)\(D\to 2^{Au}\), mapping each domain to a set of authorities. \\ \hline \multicolumn{2}{c}{**Effective Attributes of Users, Subjects and Keys**} \\ \hline For each attribute \(att_{U}\) in \(UA\), \(effectiveAu\)\(att_{U}:\)\(Au\to 2^{Range(att_{U})}\) \\ For each attribute \(att_{U}\) in \(UA\), \(effectiveLu\)\(att_{U}:\)\(Id\to 2^{Range(att_{U})}\) \\ \(US:S\to U\), mapping each subject to a user \\ For each attribute \(att_{U}\) in \(UA\), \(effectiveS\)\(att_{U}:S\to 2^{Range(att_{U})}\), \\ mapping each subject to a set of values for \(its\)\(effectiveLu\)\(att_{U}\). \\ For each attribute \(att_{K}\) in \(AK\), \(effectiveS\)\(att_{K}:K\to 2^{Range(att_{K})}\). \\ \hline \multicolumn{2}{c}{**Attribute verification function (AVF)**} \\ \hline A subject \(s\in S\) is allowed to perform \(op\in OP_{AVF}\) on a service \\ \(sr\in PBC\) if the \(effectiveS\)\(att_{U}\in UA\). Formally, \\ \(OP_{AVF}(s:S,\)\(sr:PBC)=True\) \\ \hline \multicolumn{2}{c}{**Authorization function (AF)**} \\ \hline A subject \(s\in S\) is allowed to perform \(op\in OP_{AF}\) on a service \\ \(sr\in DBC\) if the \(effectiveS\)\(att_{U}\) satisfy policies stated in \\ \(AutHD_{\mathcal{B}}(s:S,\)\(sr:IDP\cup CDP)\). Formally, \\ \(AutHD_{\mathcal{B}}(s:S,\)\(sr:IDP\cup CDP)=True\) \\ \hline \multicolumn{2}{c}{**Decryption function (DF)**} \\ \hline A subject \(s\in S\) is allowed to perform an operation \(op\in OP_{DF}\) \\ on an object \(ob\in OB\) in data access services \(ds\in DAS\), if \\ \(\{OP_{AVF}(s:S,sr:PBC)\cap AutHD_{\mathcal{B}}(s:S,sr:IDP\cup CDP)\}=True\) \\ and has keys \(k\in K\) such as \(OP_{DF}(ob\in OB|ob_{k}\in K|s_{k}\in K)=True\). \\ \hline \end{tabular}
\end{table} 
Table 2: Basic sets and functions of the HMBAC model. The _Blockchain Infrastructure_ is a middleware that implements all system services and provides controlled access to data, which are maintained off-chain individually by each stakeholder. It implements the hierarchical multi-blockchain, which consists of one Proxy Blockchain (PBC) and one or more Domain Blockchains (DBCs). As described in Section 3.2, the PBC acts as a single access point for users, while the DBCs enable the management, implementation and enforcement of flexible and granular access policies at the domain level. The integration of the blockchain components is supported by special-purpose APIs both for inter-blockchain synchronization (Inter-BC API), user interaction (Frontend API), and data (Database API). Finally, _Data Layer_ contains the individually managed databases that store all data off-chain and ABE encrypted.