# Enhancing Security and Privacy in Healthcare Systems Using a Lightweight RFID Protocol

^{1}

^{2}

^{3}

^{4}

^{5}

^{*}

## Abstract

**:**

## 1. Introduction

## 2. Related Work

## 3. Proposed Lightweight RFID Protocol

**Step 1:**- The scheme involves the reader and tag exchanging random numbers. The ${R}_{R}$ is a random number generated by a reader, and it is encrypted with a preshared key ${K}_{SR}$ between the reader and tag. The resulting value ${N}_{R}^{{}^{\prime}}={R}_{R}\oplus {K}_{SR}$ is stored by the reader in ${M}_{1}$, which is a message sent through a public channel to the tag.
**Step 2:**- The tag decrypts the random number by computing ${R}_{R}={N}_{R}^{{}^{\prime}}\oplus {K}_{RT}$, where ${K}_{RT}$ is a preshared key among the tag and reader. The tag generates its random number ${R}_{T}$ and sets a mark value of 00, thus indicating the start of the session. The tag then encrypts its random number with ${K}_{RT}$ and stores the result in ${N}_{R}^{{}^{\prime}}$ as ${N}_{R}^{{}^{\prime}}={R}_{T}\oplus {K}_{RT}$. The tag also calculates $Cro(RID\oplus TID,K)$ and stores it in ${M}_{2}$, which is sent to the reader through a public channel.
**Step 3:**- The reader decrypts the tag’s random number by computing ${R}_{T}={N}_{T}^{{}^{\prime}}\oplus {K}_{RT}$, where ${N}_{T}^{{}^{\prime}}$ is the value received in ${M}_{2}$. The reader then encrypts the tag’s nonce and the reader’s nonce using a preshared key ${K}_{SR}$ between the server and reader. This results in ${N}_{R}^{{}^{\u2033}}={R}_{R}\oplus {K}_{SR}$ and ${N}_{T}^{{}^{\u2033}}={R}_{T}\oplus {K}_{SR}$ (the double primes indicate the second encryption). The reader then calculates $Cro(RID\oplus TID,K)$ and stores it along with ${N}_{T}^{{}^{\u2033}}$ and ${N}_{R}^{{}^{\u2033}}$ in ${M}_{3}$, which is sent directly to the server.
**Step 4:**- The server attains the random numbers of the reader and tag by decrypting them with ${K}_{SR}$ as ${R}_{R}={N}_{R}^{{}^{\u2033}}\oplus {K}_{SR}$ and ${R}_{T}={N}_{T}^{{}^{\u2033}}\oplus {K}_{SR}$, respectively. The server searches the ID table $IDT$ for the index corresponding to the value received in ${M}_{3}$, which is $Cro(TID\oplus RID,K)$. The protocol stops if the index value does not match an index in $IDT$. If the index value matches an index in $IDT$, a ${R}_{S}$ random number is produced by the server, which then encrypts it with ${K}_{SR}$ and stores the result in ${N}_{S}^{{}^{\prime}}={R}_{S}\oplus {K}_{SR}$. The server then calculates $Cro(RID\oplus TID,{N}_{S}^{{}^{\prime}}\oplus k)$, $Rot(K\oplus TID,RID\oplus k)$, and $k\oplus {N}_{S}^{{}^{\prime}}$ and stores all three values in ${M}_{4}$, which is sent to the reader through a public channel.
**Step 5:**- The reader checks the $TID$ and obtains ${R}_{S}$ as follows. First, it computes the hamming weight of $K\oplus TID$, which is denoted by $W(TID\oplus K)$. Then, it computes $K\oplus K\oplus TID$. Using these values, it obtains $TID$ and ${R}_{S}$ as $TID=Cro(TID\oplus RID,K\oplus {N}_{S}^{{}^{\prime}})$ and ${R}_{S}={N}_{S}^{{}^{\prime}}\oplus KST\oplus K\oplus K$, respectively. The reader then compares the received value $Cro(TID\oplus RID,K\oplus {N}_{S}^{{}^{\prime}})$ with the calculated value to verify. If they match, it stores $TID\oplus {R}_{R}$ and ${N}_{S}^{{}^{\u2033}}={R}_{S}{K}_{RT}$ in ${M}_{5}$ and forwards ${M}_{5}$ to the tag through a public channel.
**Step 6:**- The tag first obtains a random number ${R}_{S}={N}_{S}^{{}^{\u2033}}\oplus {K}_{KRT}$. Then, it performs an XOR operation between the $TID$ and the previously received ${R}_{R}$, which is denoted as $TID\oplus {R}_{R}$. Next, it checks if $TID=TID\oplus {R}_{R}\oplus {R}_{R}$. After that, it updates the session number K by acquiring three random numbers: ${R}_{S},{R}_{R},$ and ${R}_{T}$. Specifically, K is replaced with ${K}_{new}$, where ${K}_{new}=Cro({N}_{R}\oplus {N}_{R}\oplus {N}_{T},K)$. Remember that K is the default value mutually exchanged by the reader, tag, and server in the first session. Before initiating the next phase, the tag stores $Cro(TID,{K}_{new}\oplus RID)$ in ${M}_{6}$ and is shared with the reader.
**Step 7:**- The K in the server and reader is updated. Since some of the parameters are already calculated and present in the reader and server, such as $RID,TID,{R}_{S},{R}_{R},{R}_{T},$ and K, they take advantage of this fact and execute $Cro(RID\oplus TID,Cro({R}_{S}\oplus {R}_{R}\oplus {R}_{T},K))$ to obtain ${K}_{new}$. They then compare it with the ${K}_{new}$ received from the tag, which is denoted as M7= $Cro(RID\oplus TID,{K}_{new})$. If they match, the reader updates ${K}_{new}=Cro({R}_{S}\oplus {R}_{R}\oplus {R}_{T},K)$. After this step, some verification operations are performed for the consistency of ${K}_{new}$ in the tag, reader, and server. Finally, the reader shares M7 with the server.
**Step 8:**- The server calculates $Cro(RID\oplus TID),$ and $Cro({R}_{R}\oplus {R}_{S}\oplus {R}_{T},K)$ and checks them with $Cro(RID\oplus TID,{K}_{new})$; after that, it updates ${K}_{new}=Cro({R}_{R}\oplus {R}_{S}\oplus {R}_{T},K)$ and stores ${K}_{new}\oplus {R}_{T}\oplus {R}_{R}$ in M8. The server sends M8 to the reader via an insecure channel.
**Step 9:**- The reader verifies the consistency of ${K}_{new}$ and calculates $XORs{K}_{new}$, ${R}_{T}$, and ${N}_{R}$; it then stores them in ${M}_{9}$ as ${M}_{9}={K}_{new}\oplus {R}_{T}\oplus {N}_{R}$. The reader also sends them to the tag, but it stores them within ${M}_{9}$ before sending them to the tag. Thus, ${M}_{9}$ is sent to the tag through a public channel.
**Step 10:**- In addition, both the reader and tag perform the same operations to confirm ${K}_{new}$ by obtaining it with the help of the operation $({K}_{new}\oplus {R}_{T}\oplus {R}_{R})\oplus {R}_{T}\oplus {R}_{R}$, and they validate it against the previous value ${K}_{new}$ that was calculated before. If the verification process does not encounter any problems and is smooth, the $Mark$ value is set to 01, thereby indicating that the synchronization regarding K is completed.
**Step 11:**- The reader receives a notification from the tag to update the record. The reader stores mark value XOR with ${R}_{s}$ in M11; it then forwards $Mark$ to the server, which means the value is 01 at the server side. A new record $\{Cro(RID\oplus TID,{K}_{new})$, $Rot({K}_{new}\oplus TID,{K}_{new}\oplus RID)\}$ is produced and added to the index table IDT. The tag then sets the $Mark$ value to 10 after receiving a notification that the data has finished updating. The proposed authentication protocol is completed.

## 4. Computation Cost Comparison

## 5. Security Analysis

#### 5.1. Automated ProVerif Security Proof

- Query 1 tests the event injection for the server. It checks if the ProVerif response confirms that the connection on the server is successfully opened and closed. The query result indicates that the event injection from end_S(IDS[]) to start_S(IDS[]) is true, meaning that the server’s communication channel is functioning correctly.
- Query 2 tests the event injection for the reader. It verifies if the ProVerif response confirms that the connection on the reader is successfully opened and closed. The query result indicates that the event injection from end_R(IDR[]) to start_R(IDR[]) is true, thereby indicating that the reader’s communication channel is functioning correctly.
- Query 3 focuses on the event injection for the tag. It checks if the ProVerif response confirms that the connection on the tag is successfully opened and closed. The query result indicates that the event injection from end_T(IDT[]) to start_T(IDT[]) is true, thus implying that the tag’s communication channel is functioning correctly.
- Query 4 examines the security/strength of the secret key KNEW by checking if it is susceptible to an attacker. The ProVerif response indicates that KNEW is secure, given that the result of not attacker(KNEW[]) is true. Therefore, the secret key KNEW is deemed secure, and an attacker cannot intercept it from the public channel.

#### 5.2. BAN Logic Security Proof

- Goal 1: $S|\equiv R\equiv \{Cro(RID\oplus TID),K\}$
- Goal 2: $S|\equiv R|\equiv \left\{Cro(RID\oplus TID,K\oplus {N}_{S}^{{}^{\prime}})\right\},{\{Rot(K\oplus TID,K\oplus RID)\parallel {N}_{S}^{{}^{\prime}}\oplus K\}}_{K}$
- Goal 3: $R|\equiv T\left\{Cro(RID\oplus TID.{K}_{new})\right\}{K}_{new}$
- Goal 4: $T|\equiv R\equiv \{{K}_{new}\oplus {N}_{T}^{{}^{\prime}}\oplus {N}_{R}^{{}^{\prime}}\}{K}_{new}$
- Goal 5: $T|\equiv R|\equiv S\stackrel{{K}_{new}}{\u27f7}T$

#### 5.2.1. Idealized Form

- M1: ${N}_{R}^{{}^{\prime}}<{R}_{R}>KRT$
- M2: $Cro<RID\oplus TID>K,N{T}^{{}^{\prime}}<{R}_{T}>KRT$
- M3: $Cro<RID\oplus TID>K,N{R}^{{}^{\u2033}}<{R}_{R}>KSR,{N}_{T}^{{}^{\u2033}}<{R}_{T}>{K}^{SR}$
- M4: $Cro<RID\oplus TID,K\oplus N{S}^{{}^{\u2033}}>,Rot<K\oplus TID,K\oplus RID>,<K\oplus {N}_{S}^{{}^{\prime}}>$
- M5: $<TID>RR,{N}_{S}^{{}^{\u2033}}<{R}_{S}>KRT$
- M6: $Cro<RID\oplus TID,{K}_{new}<{R}_{R}\oplus {R}_{S}\oplus {R}_{T},K>>$
- M7: $\left({K}_{new\oplus {R}_{T}\oplus {R}_{R}}\right)$
- M8: $(Mark\oplus {R}_{S})$

#### 5.2.2. Assumption

- A 1: $T|\equiv \phantom{\rule{4pt}{0ex}}T\stackrel{K}{\u27f7}R,R|\equiv \phantom{\rule{4pt}{0ex}}R\stackrel{K}{\u27f7}T$
- A 2: $R|\equiv \phantom{\rule{4pt}{0ex}}R\stackrel{K}{\u27f7}S,S|\equiv \phantom{\rule{4pt}{0ex}}S\stackrel{K}{\u27f7}R$
- A 3: $S|\equiv \phantom{\rule{4pt}{0ex}}S\stackrel{K}{\u27f7}T,T|\equiv \phantom{\rule{4pt}{0ex}}T\stackrel{K}{\u27f7}S$
- A 4: $R|\Rightarrow {R}_{R},R|\equiv \#\left({R}_{R}\right),R|\equiv T|\equiv S\stackrel{{R}_{R}}{\Rightarrow}R$
- A 5: $T|\Rightarrow {R}_{T},T|\equiv \#\left({R}_{T}\right),T|\equiv R|\equiv S\stackrel{{R}_{T}}{\Rightarrow}T$
- A 6: $S|\Rightarrow {R}_{S},S|\equiv \#\left({R}_{S}\right),S|\equiv R|\equiv T\stackrel{{R}_{S}}{\Rightarrow}S$
- A 7: $T|\equiv R\equiv S\equiv \#(K)$

#### 5.2.3. Idealized form Verification

- V 1: $S<{Cro(RID\oplus TID,K)}_{K},{N}_{R}^{{}^{\prime}},{N}_{T}^{{}^{\prime}}\left(A2\right)$, which demonstrates that only the reader and the server (as well as any other entities that they believe know the value of K) can access S. Combining this with the message seeing rule, P < (X, Y) |- P < X, we obtain

- V 2: $S{\left\{Cro(RID\oplus TID,K)\right\}}_{K}$, where Cro is a cryptographic function, $RID$ and $TID$ are identifiers, and K is the shared secret key.

- V 3: $S\equiv R\mid \neg {Cro(RID\oplus TID,K)}_{K}$

- V 4: $S\equiv S\oplus {\{Cro(RID\oplus TID,K)\}}_{K}$

- V 5: $S\equiv R\equiv {Cro(RID\oplus TID,K)}_{K}$Hence, according to the above proof process, the first goal (Goal 1) has been achieved. Similarly, we can compute the message sent to the reader from the server as
- V 6: $R<\{Cro(RID\oplus TID,K\oplus {N}_{S}^{{}^{\prime}}).Rot(K\oplus TID,K\oplus RID){N}_{S}^{{}^{\prime}}\oplus K\}{>}_{K}$, namely, the Goal 2.By the same procedure, we can compute Goals 3 and 4. According to (A 1, A 2, A 3) and the process of front demonstration, we can obtain $T\equiv {R}^{K}\stackrel{{K}_{\mathrm{new}}}{\u27f7}T,\phantom{\rule{1.em}{0ex}}\mathrm{and}\phantom{\rule{1.em}{0ex}}R\equiv S\stackrel{{K}_{\mathrm{new}}}{\u27f7}R$. Moreover, we combine secret rules and message keys. Given $P\equiv R\stackrel{K}{\u27f7}{R}_{1}\equiv P\equiv {R}_{1}\stackrel{K}{\u27f7}R$ and $P\equiv Q\equiv R\stackrel{K}{\u27f7}{R}_{1}\equiv P\equiv {R}_{1}\stackrel{K}{\u27f7}R$, we can see that
- V 7: $T{\equiv}_{R}S\stackrel{{K}_{\mathrm{new}}}{\u27f7}T$Hence, all the protocol goals have been proved to secure the proposed scheme logically.

#### 5.2.4. Goals

- The server $L{S}_{j}$ believes that ${U}_{i}$ and $L{S}_{j}$ share a secret parameter $DI{D}_{i}$;
- $L{S}_{i}$ believes in ${U}_{i}$ and ${U}_{i}$ also believes that ${U}_{i}$ and $L{S}_{j}$ share the secret value $DI{D}_{i}$;
- ${U}_{i}$ believes that $L{S}_{j}$ shares the secret key of $DI{D}_{i}$ with ${U}_{i}$;
- ${U}_{i}$ believes in $L{S}_{j}$ and also believes that $L{S}_{j}$ shares a secret key $DI{D}_{i}$ with ${U}_{i}$.

## 6. Informal Security Analysis

## 7. Conclusions

## Author Contributions

## Funding

## Institutional Review Board Statement

## Informed Consent Statement

## Data Availability Statement

## Conflicts of Interest

## References

- Lee, I.; Lee, K. The Internet of Things (IoT): Applications, investments, and challenges for enterprises. Bus. Horizons
**2015**, 58, 431–440. [Google Scholar] [CrossRef] - Mahmood, K.; Arshad, J.; Chaudhry, S.A.; Kumari, S. An enhanced anonymous identity-based key agreement protocol for smart grid advanced metering infrastructure. Int. J. Commun. Syst.
**2019**, 32, 16. [Google Scholar] [CrossRef] - Vijayakumar, P.; Obaidat, M.S.; Azees, M.; Islam, S.H.; Kumar, N. Efficient and Secure Anonymous Authentication with Location Privacy for IoT-Based WBANs. IEEE Trans. Ind. Inform.
**2020**, 16, 2603–2611. [Google Scholar] [CrossRef] - Mishra, D.; Rana, S. A provably secure content distribution framework for portable DRM systems. J. Inf. Secur. Appl.
**2021**, 61, 102928. [Google Scholar] [CrossRef] - Gao, M.; Lu, Y. URAP: A new ultra-lightweight RFID authentication protocol in passive RFID system. J. Supercomput.
**2022**, 78, 10893–10905. [Google Scholar] [CrossRef] - Shariq, M.; Singh, K.; Maurya, P.K.; Ahmadian, A.; Taniar, D. AnonSURP: An anonymous and secure ultralightweight RFID protocol for deployment in internet of vehicles systems. J. Supercomput.
**2022**, 78, 8577–8602. [Google Scholar] [CrossRef] - An, Y.; Zhang, Y.; Cao, W.; Tong, Z.; He, Z. A Lightweight and Practical Anonymous Authentication Protocol Based on Bit-Self-Test PUF. Electronics
**2022**, 11, 772. [Google Scholar] [CrossRef] - Rana, S.; Mishra, D. Secure and ubiquitous authenticated content distribution framework for IoT enabled DRM system. Multimed. Tools Appl.
**2020**, 79, 20319–20341. [Google Scholar] [CrossRef] - Chander, B.; Gopalakrishnan, K. A secured and lightweight RFID-tag based authentication protocol with privacy-preserving in Telecare medicine information system. Computer Commun.
**2022**, 191, 425–437. [Google Scholar] [CrossRef] - Chen, Y.; Chou, J.S.; Lin, C.F.; Wu, C.L. A Novel RFID Authentication Protocol based on Elliptic Curve Cryptosystem. IACR Cryptol. EPrint Arch.
**2011**, 2011, 381. [Google Scholar] - Bilal, Z.; Masood, A.; Kausar, F. Security analysis of ultra-lightweight cryptographic protocol for low-cost RFID tags: Gossamer protocol. In Proceedings of the 2009 International Conference on Network-Based Information Systems, Indianapolis, IN, USA, 19–21 August 2009; pp. 260–267. [Google Scholar]
- Abughazalah, S.; Markantonakis, K.; Mayes, K. Secure improved cloud-based RFID authentication protocol. In Data Privacy Management, Autonomous Spontaneous Security, and Security Assurance; Springer: Berlin/Heidelberg, Germany, 2015; pp. 147–164. [Google Scholar]
- Xie, W.; Xie, L.; Zhang, C.; Zhang, Q.; Tang, C. Cloud-based RFID authentication. In Proceedings of the 2013 IEEE International Conference on RFID (RFID), Penang, Malaysia, 30 April–2 May 2013; pp. 168–175. [Google Scholar]
- Fan, K.; Jiang, W.; Li, H.; Yang, Y. Lightweight RFID Protocol for Medical Privacy Protection in IoT. IEEE Trans. Ind. Inform.
**2018**, 14, 1656–1665. [Google Scholar] [CrossRef] - Kaul, S.D.; Awasthi, A.K. RFID authentication protocol to enhance patient medication safety. J. Med. Syst.
**2013**, 37, 9979. [Google Scholar] [CrossRef] - Chou, J.S. An efficient mutual authentication RFID scheme based on elliptic curve cryptography. J. Supercomput.
**2014**, 70, 75–94. [Google Scholar] [CrossRef] - Liao, Y.P.; Hsiao, C.M. A secure ECC-based RFID authentication scheme integrated with ID-verifier transfer protocol. Ad Hoc Netw.
**2014**, 18, 133–146. [Google Scholar] [CrossRef] - Zhao, Z. A secure RFID authentication protocol for healthcare environments using elliptic curve cryptosystem. J. Med. Syst.
**2014**, 38, 46. [Google Scholar] [CrossRef] - Peeters, R.; Hermans, J. Attack on Liao and Hsiao’s Secure ECC-Based RFID Authentication Scheme Integrated with ID-Verifier Transfer Protocol. Cryptology ePrint Archive. 2013. Available online: https://eprint.iacr.org/2013/399.pdf (accessed on 15 March 2023).
- Farash, M.S.; Nawaz, O.; Mahmood, K.; Chaudhry, S.A.; Khan, M.K. A provably secure RFID authentication protocol based on elliptic curve for healthcare environments. J. Med. Syst.
**2016**, 40, 165. [Google Scholar] [CrossRef] - Srivastava, K.; Awasthi, A.K.; Kaul, S.D.; Mittal, R. A hash based mutual RFID tag authentication protocol in telecare medicine information system. J. Med. Syst.
**2015**, 39, 153. [Google Scholar] [CrossRef] [PubMed] - Li, C.T.; Weng, C.Y.; Lee, C.C. A secure RFID tag authentication protocol with privacy preserving in telecare medicine information system. J. Med. Syst.
**2015**, 39, 77. [Google Scholar] [CrossRef] - Jin, C.; Xu, C.; Zhang, X.; Li, F. A secure ECC-based RFID mutual authentication protocol to enhance patient medication safety. J. Med. Syst.
**2016**, 40, 12. [Google Scholar] [CrossRef] [PubMed] - Prakash Pokala, J.; Reddy, M.C.; Bapana, S.; Vorugunti, C.S. A secure RFID protocol for telecare medicine information systems using ECC. In Proceedings of the 2016 International Conference on Wireless Communications, Signal Processing and Networking (WiSPNET), Chennai, India, 23–25 March 2016; pp. 2295–2300. [Google Scholar]
- Zhou, Z.; Wang, P.; Li, Z. A quadratic residue-based RFID authentication protocol with enhanced security for TMIS. J. Ambient Intell. Humaniz. Comput.
**2019**, 10, 3603–3615. [Google Scholar] [CrossRef] - Safkhani, M.; Vasilakos, A. A new secure authentication protocol for telecare medicine information system and smart campus. IEEE Access
**2019**, 7, 23514–23526. [Google Scholar] [CrossRef] - Zheng, L.; Song, C.; Cao, N.; Li, Z.; Zhou, W.; Chen, J.; Meng, L. A new mutual authentication protocol in mobile RFID for smart campus. IEEE Access
**2018**, 6, 60996–61005. [Google Scholar] [CrossRef] - Chen, X.; Geng, D.; Zhai, J.; Liu, W.; Zhang, H.; Zhu, T. Security analysis and enhancement of the most recent RFID protocol for telecare medicine information system. Wirel. Pers. Commun.
**2020**, 114, 1371–1387. [Google Scholar] [CrossRef] - Shariq, M.; Singh, K.; Maurya, P.K.; Ahmadian, A.; Ariffin, M.R.K. Urasp: An ultralightweight rfid authentication scheme using permutation operation. Peer- Netw. Appl.
**2021**, 14, 3737–3757. [Google Scholar] [CrossRef] - Xiao, L.; Xie, S.; Han, D.; Liang, W.; Guo, J.; Chou, W.K. A lightweight authentication scheme for telecare medical information system. Connect. Sci.
**2021**, 33, 769–785. [Google Scholar] [CrossRef]

Notations | |||
---|---|---|---|

Notation | Description | Notation | Description |

${R}_{R}$ | Random Nonce of Reader | ${R}_{S}$ | Random Number of Server |

${R}_{T}$ | Random Number of Tag | $TID$ | Tag ID |

$RID$ | Reader ID | ${K}_{RT}$ | Preshared Key between $Reader$ and $Tag$ |

${K}_{SR}$ | Preshared Key between $Server$ and $Reader$ | ⊕ | The XOR Operation |

K | Current Session Number | ${K}_{new}$ | Next Session Number |

$Cro(x,y)$ | Cross Operation | $Rot(x,y)$ | Rotation Operation, $x=W\left(y\right)$ |

$Mark$ | Status of Last Session | ${N}_{R}^{{}^{\prime}}$ | Random number of Reader ${R}_{R}$ xor with ${K}_{RT}$ |

${N}_{T}^{{}^{\prime}}$ | Random number of Tag ${R}_{T}$ xor with ${K}_{RT}$ | ${N}_{S}^{{}^{\prime}}$ | Random number of server ${R}_{S}$ xor with ${K}_{SR}$ |

${N}_{T}^{{}^{\u2033}}$ | Random number of Tag ${R}_{T}$ xor with ${K}_{SR}$ | ${N}_{S}^{{}^{\u2033}}$ | Random number of server ${R}_{S}$ xor with ${K}_{RT}$ |

**Table 2.**Computation cost comparison (∧ represents exponentiation, ⊕ indicates the XOR operation, “$\left|\right|$” is the cascading operation, “Hash” is the hash operation, and “Cro” is the cross operation defined previously. Similarly, PRNG stands for pseudo-random number generator, while “Rot” indicates the displacement operation, and the cost of operations such as ⊕ and “Rot” are relatively lower).

Schemes | Cost |
---|---|

Kaul et al. [15]. | $\oplus ,PRNG,Hash$ |

Chien Protocol [10]. | $\oplus ,\wedge ,\left|\right|,Rot$ |

Gossamer Protocol [11]. | $\oplus ,\wedge ,Ro{t}^{2}$ |

Xie Protocol [13]. | $\oplus ,\left|\right|,Hash$ |

Sarah Protocol [12]. | $\oplus ,\wedge ,\left|\right|,Hash$ |

Fan Protocol [14]. | $\oplus ,\left|\right|,Cro,Rot$ |

Proposed Scheme | $\oplus ,Cro$ |

Query | ProVerif Response |
---|---|

Query inj-event(end_S(IDS[])) ==>inj-event(start_S(IDS[])) Completing… Starting query inj-event(end_S(IDS[])) ==>inj-event(start_S(IDS[])) | inj-event(end_S(IDS[])) ==>inj-event(start_S(IDS[])) is true. |

Query inj-event(end_R(IDR[])) ==>inj-event(start_R(IDR[])) Completing… Starting query inj-event(end_R(IDR[])) ==>inj-event(start_R(IDR[])) | inj-event(end_S(IDR[])) ==>inj-event(start_S(IDR[])) is true. |

Query inj-event(end_T(IDT[])) ==>inj-event(start_T(IDT[])) Completing… Starting query inj-event(end_T(IDT[])) ==>inj-event(start_T(IDT[])) | inj-event(end_T(IDT[])) ==>inj-event(start_T(IDT[])) is true. |

Query not attacker(KNEW[]) Completing… Starting query not attacker(KNEW[]) | not attacker(KNEW[]) is true. |

Notations | Description |
---|---|

$Q|\equiv X$ | Q believing in X |

$Q\u22b2X$ | Q sees which is X |

$Q|\equiv T$ | Q believes T’s action. E.g., $Q|\equiv T|\equiv X$ |

means Q believes T believes X is true | |

$Q|\sim X$ | Q once says X |

$Q\Rightarrow X$ | Q has full jurisdiction beyond X |

$\#\left(X\right)$ | X is updated and fresh |

${\left(C\right)}_{k}$ | Combine conditions C by the use of k |

${\left(C\right)}_{k}$ | Carry out hash operation on C; use X |

${\left(X\right)}_{K}$ | Message of hash X with a key K |

$Q\stackrel{k}{\u27f7}T$ | Q and T used to interact using the shared key k |

with each other | |

$DI{D}_{i}$ | Session key $DI{D}_{i}$ used one time in the |

current section | |

$\frac{Q|\equiv Q\stackrel{K}{\u27f7}T.q\u22b2<X{>}_{K}}{Q|\equiv T|\sim X}$ | Rule of Message-Meaning |

$\frac{Q|\equiv \#(X)}{Q|\equiv \#(X,Y)}$ | Rule of Concatenation-Freshness |

$\frac{Q|\equiv \#(X),Q|\equiv T|\sim X}{Q|\equiv T|\equiv X}$ | Rule of Verification-Nonce |

$\frac{Q|\equiv T\Rightarrow X,Q|\equiv T|\equiv X}{Q|\equiv X}$ | Rule of Jurisdiction |

Security Criteria | Description |
---|---|

Tag Anonymity (R1) | Tag anonymity ensures privacy and prevents unauthorized tracking by concealing the identity of the tag or device that transmits information in a system or protocol. |

Reply Attack (R2) | A malicious actor intercepts and retransmit legitimate data or actions to deceive a system, thereby compromising its integrity and security. |

Synchronization Attack (R3) | It occurs when an attacker manipulates the coordination among the different entities to disrupt normal operations or gain unauthorized access. This attack compromises the targeted system’s integrity, availability, or confidentiality by exploiting timing or communication dependencies. |

Forward Secrecy (R4) | A security vulnerability where the exposure of a long-term secret key does not compromise the privacy of previous communications. This ensures that historical data remains safeguarded, even if the private key is compromised. |

Mutual Authentication (R5) | Mutual authentication is a security measure where both parties involved in a communication process verify each other’s identities, thereby establishing trust and preventing unauthorized access or impersonation. This ensures that the reader, tag and server confirm each other’s authenticity before establishing a connection. |

DoS Attack (R6) | An adversary inundates a target system or network with high requests or traffic, thus resulting in service disruption or unavailability for legitimate users. The goal is to deplete system resources and impede its ability to handle legitimate requests. |

Impersonation Attack (R7) | It occurs when an attacker assumes a false identity by posing as a legitimate user or entity in a cybersecurity breach. By exploiting this deception, the attacker aims to gain unauthorized access, deceive others, and potentially engage in malicious actions such as manipulating or stealing sensitive information while bypassing security measures. |

Insider Attacker (R8) | It occurs within an organization and involves trusted individuals such as employees or contractors with authorized access. Leveraging their privileged positions, these attacks target system compromises, data theft, or infrastructure damage, thus posing significant risks due to the insider’s knowledge and authorized access. |

Formal Verification (R9) | Formal verification means the proposed scheme security test uses well-known automated tools such as ProVerif. It also test the correctness of the proposed scheme using BAN Logics. |

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |

© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Khan, M.A.; Ullah, S.; Ahmad, T.; Jawad, K.; Buriro, A.
Enhancing Security and Privacy in Healthcare Systems Using a Lightweight RFID Protocol. *Sensors* **2023**, *23*, 5518.
https://doi.org/10.3390/s23125518

**AMA Style**

Khan MA, Ullah S, Ahmad T, Jawad K, Buriro A.
Enhancing Security and Privacy in Healthcare Systems Using a Lightweight RFID Protocol. *Sensors*. 2023; 23(12):5518.
https://doi.org/10.3390/s23125518

**Chicago/Turabian Style**

Khan, Muhammad Ayaz, Subhan Ullah, Tahir Ahmad, Khwaja Jawad, and Attaullah Buriro.
2023. "Enhancing Security and Privacy in Healthcare Systems Using a Lightweight RFID Protocol" *Sensors* 23, no. 12: 5518.
https://doi.org/10.3390/s23125518