Introduction
Related work
Preliminary
Hyperledger fabric
Interplanetary file system (IPFS)
Elliptic curve Digital signature algorithm (ECDSA)
Proxy Re-encryption (PRE)
Attribute-based signature encryption (ABSE)
System model
Hospital blockchain system (HB)
Doctor (D)
Patient (P)
Interplanetary File System (IPFS)
The proposed scheme
Notation | Description |
---|---|
\({\varvec{I}\varvec{n}\varvec{f}\varvec{o}}_{\varvec{X}}\)
| The registration information of all participants in the system |
\({\varvec{S}\varvec{K}}_{\varvec{X}}\), \({\varvec{P}\varvec{K}}_{\varvec{X}}\)
| public-private key pairs of\(X\)
|
\(\varvec{G}\)
| A generator for the elliptic group |
\({\varvec{C}\varvec{e}\varvec{r}\varvec{t}}_{\varvec{X}}\)
|
\(X\)‘s digital certificate
|
\({\varvec{r}\varvec{o}\varvec{l}\varvec{e}}_{\varvec{X}}\)
|
\(X\)‘s attribute
|
\(\varvec{f}\left(\varvec{m}\right)\)
| The function \(f(\cdot)\) for the elliptic curve that embeds the message\(m\)
|
\({\varvec{P}}_{\varvec{m}}\)
|
\(m \text{E}\text{m}\text{b}\text{e}\text{d}\text{d}\text{i}\text{n}\text{g} \text{d}\text{a}\text{t}\text{a} \text{i}\text{n}\text{t}\text{o} f(\cdot)\)
|
\({\varvec{f}}^{-1}\left(\bullet \right)\)
| The inverse function of\(f\left(\cdot \right)\)
|
\({\varvec{J}}_{\varvec{P}\varvec{i}}\)
| Patient P’s transaction information in the chain |
\(\varvec{t}\varvec{i}\varvec{m}\varvec{e}\varvec{s}\varvec{t}\varvec{a}\varvec{m}\varvec{p}\)
| Current timestamp |
\({\varvec{M}}_{\varvec{P}\varvec{i}}\)
| Patient information and corresponding encrypted EMR |
\(({\varvec{C}}_{\varvec{A}}, {\varvec{C}}_{\varvec{B}})\)
| User ciphertext encrypted with encryption key |
\(({\varvec{C}\varvec{'}}_{\varvec{A}},{ \varvec{C}\varvec{'}}_{\varvec{B}})\)
| User ciphertext encrypted with re-encryption key |
\(({\varvec{Q}}_{\varvec{X}\varvec{j}}, {\varvec{T}}_{\varvec{X}\varvec{j}})\)
| The \(jth\) signature generated by user\(X\)
|
\(({\varvec{x}}_{\varvec{i}}, {\varvec{y}}_{\varvec{i}})\)
| A random point on an elliptic curve |
\(\stackrel{-}{{\varvec{x}}_{\varvec{i}}}\)
| Point \(({x}_{i}, {y}_{i})\) convert \({x}_{i}\) to an integer |
\({\varvec{H}}_{\varvec{X}\varvec{j}}\)
| The \(jth\) hash generated by user\(X\)
|
\({\varvec{r}\varvec{K}}_{\varvec{A}\to \varvec{B}}\)
\(\varvec{n}\)
\(\varvec{e}\)
| Proxy re-encryption key generated from \(A\) to\(B\)
the elliptic curve of order Bilinear mapping |
System overview
-
Step 1: Doctors and patients are required to register through HB. When a registration request is received, HB creates public-private key pairs and digital certificates for every user and sends them to the corresponding recipients. It is worth noting that every certificate contains a specific set of predetermined characteristics, which includes role.
-
Step 2: The EMR is encrypted by the patient and then uploaded to IPFS storage. Following that, patients sign the information returned by IPFS to upload it to the blockchain.
-
Step 3: The doctor desires to access the patient’s EMR and initiates an access request to HB. Subsequently, the HB assesses compliance with the access policy before granting the request. If the HB grants approval, the patient receives the request message from the doctor. Subsequently, the patient utilizes the doctor’s public key to execute a proxy re-encryption algorithm and sends the resulting data back to the HB. The doctor receives the patient’s authorization information through HB and gets the ciphertext for the patient’s corresponding EMR on IPFS using the hash value. Finally, the doctor can decrypt the EMR with his private key.
Construction of the proposed scheme
Registration phase
-
Step 1. To register, User X registers through the client and sends the registration information \({Info}_{X}\) to HB.
-
Step 2. Upon validation of user X’s registration information, HB returns the key pair \({(SK}_{X},{PK}_{X})\) and the user’s certificate \({Cert}_{X}\) to user X, where \({PK}_{X} = {SK}_{X}G\).
-
Step 3. The user X saves \({({Info}_{X},SK}_{X},{PK}_{X},{Cert}_{X})\).
EMR storage phase
-
Step 1: The Patient P first constructs a function on the medical record data \({m}_{{P}_{i}}\).$$P{m}_{{P}_{i}}=f\left({m}_{{P}_{i}}\right)$$(1)
-
Step 2: P packages his EMR-related information.
-
Step 3: P sends \(({ Q}_{{P}_{i1}}, {T}_{{P}_{i1}})\) and \({M}_{{P}_{i}}\) to IPFS for storage. Once received by IPFS, it will calculate \({H}_{{P}_{i2}}\) and return \({H}_{{P}_{i2}}\) to P.
-
Step 4: Once P receives \({H}_{{P}_{i2}}\) from IPFS, P will select a random number \({k}_{3}\) and call the ECDSA signature algorithm to generate a signature \(({ Q}_{{P}_{i2}}, {T}_{{P}_{i2}})\).
-
Step 5: Once the HB system receives \({H}_{{P}_{i2}}\) and \(({ Q}_{{P}_{i2}}, {T}_{{P}_{i2}})\) sent by the patient, the nodes participating in the consensus in the HB system will calculate the hash value of the transaction \({H}_{{P}_{i2}}\) and call the verification algorithm to verify the validity of the signature \(({ Q}_{{P}_{i2}}, {T}_{{P}_{i2}})\) sent by the patient.
Request for data access phase
-
Step 1: Doctor D generates the request message:\({Req}_{{D}_{i}} ( I{nfo}_{{D}_{i}} , {Cert}_{{D}_{i}} , operation , object , timetamp)\). Then, he selects a random number \({k}_{4}\) and calculates\({H}_{{D}_{i1}}\) and \(({Q}_{{D}_{i1}}, {T}_{{D}_{i1}})\).
-
$${H}_{{D}_{i1}} = hash \left({Req}_{{D}_{i}}\right)$$(10)
-
Step 2: Once HB receives the message \({H}_{{D}_{i1}}\) and\(({Q}_{{D}_{i1}}, {T}_{{D}_{i1}})\) sent by the doctor, it will immediately verify the signature \(({Q}_{{D}_{i1}}, {T}_{{D}_{i1}})\).
-
Step 3: Once patient P receives the requested information from doctor D through the HB system, patient P will be able to obtain the public key \({PK}_{{D}_{i}}\) of doctor D from the information \({Req}_{{D}_{i}}\), to set the re-encryption key \({rk}_{{P}_{i}\to {D}_{i}}\) in combination with its private key \({SK}_{{P}_{i}}\).
-
Step 4: Once doctor D receives the patient P’s authorization message \({Aut}_{{P}_{i}}\) through the HB system, doctor D can obtain the hash address of patient P’s encrypted EMR and find the corresponding EMR on IPFS. Because patient P has set the key for proxy re-encryption, doctor D can decrypt the EMR using the private key \({SK}_{{D}_{i}}\).
Analysis and performance evaluation
Functional analysis
Data integrity
Access control
Traceability
Scalability
Security analysis
-
Resistance to Replay Attack. In our scheme, random numbers and timestamps are used for each round of interaction. Due to the randomness of the random number and the freshness of the timestamp, the replay behavior will be accurately judged. Therefore, the proposed protocol withstands the replay attack.
-
Resistance to Man-in-the-Middle Attack. Because of the open nature of wireless channels, adversary can intercept messages in transit. If the adversary wanted to tamper with the intercepted message, it would need random numbers and associated private keys, which is impossible to achieve. Therefore, the proposed protocol withstands the man-in-the-middle attack.
-
Resistance to Stolen Verifier Table Attack. The proposed scheme adopts the blockchain technology of distributed architecture, no entity needs to maintain the verifier table, which avoids the risk of the verification table being stolen. Therefore, the proposed protocol withstands the stolen verifier table attack.
-
Resistance to Collusion Attack. The proposed scheme computes the re-encryption key \({rk}_{{P}_{i}\to {D}_{i}}\) by utilizing \({SK}_{{P}_{i}}\) of patient and \({PK}_{{D}_{i}}\) of doctor. Furthermore, patient’s key is well protected by the PRE algorithm. Therefore, our proposed scheme is well protected against collusion attacks.
Computation cost
Scheme Phase | Mani et al. [18] | Chen et al. [28] | Egala et al. [39] | Ours |
---|---|---|---|---|
Data storage |
\(2{T}_{eo}+\)2\({T}_{so}+\)
3\({T}_{ho}+{2T}_{vo}\)
|
\({2T}_{eo}+\)4\({T}_{so}+\)
\({5T}_{vo}\)
|
\({T}_{eo}+\)2\({T}_{so}+\)
\({2T}_{ho}+{2T}_{vo}\)
|
\({T}_{eo}+\)2\({T}_{so}+{3T}_{ho}+{T}_{vo}\)
|
Data access |
\({4T}_{so}{+2T}_{ho}+\)
\({3T}_{vo}+{T}_{do}\)
|
\({5T}_{so}+{6T}_{vo}+\)
\({T}_{rk}{+T}_{ho}+\)
\({2T}_{do}+{2T}_{reo}\)
|
\({3T}_{so}{+4T}_{ho}+\)
\({3T}_{vo}+2{T}_{do}\)
|
\({T}_{rk}+{T}_{reo}+{2T}_{so}{+2T}_{ho}+{T}_{vo}+{T}_{do}\)
|