## 3 The Proposed Scheme
### The Migration Registration Phase  
Before starting this phase, a patient (\(U\)) forwards \((UID_{U},ID_{U})\) to a hospital certification authority (\(HCA\)) for migration certification registration with a secure channel. After receiving this identity \((UID_{U},ID_{U})\), the HCA keeps this link information and generates \(Cert_{i}\) certification with \(ID_{i}\) for EHR migration and forwards this \(Cert_{i}\) to the patient \(U\).  
When \(U\) performs this phase with the server \(V\) of the current hospital, \(U\) forwards a patient migration registration request to a server (\(V\)). After receiving this request, the server \(V\) forwards this request to the \(HCA\) to help \(U\) obtain the permission signature from \(HCA\). \(V\) first prepares two hash functions: one is \(H_{1}\), and the other is \(H_{2}\), where \(H_{1}:Z_{n}^{*}\rightarrow\{0,1\}^{I}\) and \(H_{2}:Z_{n}^{*}\rightarrow\{0,1\}^{I}\).  
* First, \(U\) has prepared their biometric value \(Bio_{U}\) and computed a random value \(r_{B_{U}}\) with a random number \(r_{U}^{\prime\prime}\in Z_{n}^{*}\), where \(r_{B_{U}}=r_{U}^{\prime\prime}\oplus H_{1}(Bio_{U})\). After the above is computed successfully, the forward their identity \(ID_{U}\), which is computed from \(H_{1}(r_{U}^{\prime\prime}||UID_{U})\) and encrypted via real identity cipher-text \(C_{HCA}=AE_{pk_{HCA}}(r_{U}^{\prime\prime},Bio_{U},\\ UID_{U},Cert_{U},EHR_{U}\oplus r_{U}^{\prime\prime})\) with public key \(pk_{U}\) and their certificate \(cert_{U}\) with their biometric information \(r_{B_{U}}\), to the server \(V\). It also generates the applicant-delegated migration signature \(S_{U}\), where the signature \(S_{U}\) is to be the \(Sig_{U}(Agree_{V->W},\\ UID_{U},ID_{U},EHR_{U}\oplus r_{U}^{\prime\prime})\) with the registration identity \(ID_{U}\), real identity \(UID_{U}\), and EHR migration delegated agreement \(Agree_{V->W}\) with final ciper-text \(EHR_{U}\oplus r_{U}^{\prime\prime}\). \(U\) then prepares the random number \(r_{V}^{\prime\prime}\), where \(r_{V}^{\prime\prime}=r_{V}\oplus r_{B_{U}}\), and forwards these files to the server \(V\) with \((r_{V}^{\prime\prime},C_{HCA},S_{U},Cert_{U},Agree_{V->W})\).
* After \(V\) receives these messages, it can check the \(S_{U}\) with the above messages and forward the \(C_{HCA}\) to the \(HCA\). When \(HCA\) has received this message with \(S_{U}\), it can decrypt \(C_{HCA}\) to obtain all parameters. First, it can fetch the random value \(r_{V}^{\prime\prime}\oplus r_{B_{U}}=r_{V}\) and verify the signature \(S_{U}\) with other parameters. If they are valid, it saves these files for data recovery usage. It then generates \(S_{HCA}\), which is \(Sig_{HCA}(S_{U},Date,ID_{U})\). Finally, it returns \((S_{HCA},H_{1}((r_{V}+1)||r_{HCA}),(r_{V}+1)\oplus r_{HCA},Date,ID_{U},S_{U})\) to the server \(V\).  
* \(V\) receives this message tuple, where one is \((S_{HCA},H_{1}((r_{V}+1)|r_{HCA}))\) and the other is \(((r_{V}+1)\oplus r_{HCA},Date,ID_{U},S_{U})\), and it can verify the signature \(S_{HCA}\) with the above parameters and compute \(r_{HCA}=(r_{V}+1)\oplus(r_{V}+1)\oplus r_{HCA}\). When the above messages are valid, \(V\) returns \(H_{1}(r_{HCA}+1)\) and forwards it back to the server \(HCA\). In addition, it also generates a signature \(Sig_{V}(S_{HCA},S_{U},Agree_{V->W})\) as the receipt \(S_{V}\) and finishes this phase after forwarding \(S_{V}\) and \(S_{HCA}\). We demonstrate in the Figure 1.