Fast Antinoise RFID-Aided Medical Care System

Abstract

We propose a grouping proof scheme to help the nursing staff on their final check automatically before a medicine round. During the medicine round, even though their RFID reader is offline, our method can generate multiple proofs for each patient and help the medical caretakers follow the five-right policy to correctly administer the drugs to their patients. Besides, because our scheme enables a nurse to target specific group tags during a medicine round, it is able to generate proofs even when the illegitimate tags are on site. We prove that our generated proof is reliable because it can resist most security threats and guarantee the integrity of the proof. Besides, our proposed scheme guarantees anonymity on the RFID tags, so the patients' sensitive information and location privacy can be protected. Last, we run a simulation to show that compared with the related methods our proposed scheme requires the least transmission time and the lowest computation loads to generate a proof.

1. Introduction

With the help of Radio Frequency Identification (RFID) technology, the identification process in medical treatment has been made simple. The automatic checking processes are able to mitigate two kinds of errors: action-based errors (slips) and memory-based errors (lapses) [1]. To avoid such medical malpractices, people used to rely on cross-check and proper labeling of medicines. These preventive mechanisms are aimed at achieving five rights: right patient, right medication, right dose, right route, and right time [2].

But cross-check is a labor-intensive and time-consuming work. Therefore, RFID-based automated inpatient medication systems are proposed to assist healthcare providers to double-check administration of medicines and to provide auditable evidence for medication safety [3–5]. These schemes are based on a yoking-proof [6], which collects information from tags with a reader and then records each tag's messages with a trustworthy verifier. Within a very limited time, a yoking-proof has to use the tags' identities and their messages to make a proof to the verifier via a reader, verifying that these tagged objects are all within the reader's read range in a specific timeframe. When a medical dispute arises, a nursing staff can use the grouping proof to testify that the inpatient, nurse, and prescribed medicine all stay in a specific area at a specific time. This proof may serve as evidence that right medicine has been administered to the right inpatient at the right time.

However, adversaries may forge a yoking-proof with replay attacks. They can replay prerecorded proofs to evade the check on each tag's presence in their own groups. Hence, Saito and Sakurai [7] use timestamps to replace the random numbers in a yoking-proof. Piramuthu [8] adds a verifier-generated nonce into the initiated message to avoid replay attacks. These protocols, however, are vulnerable to multiproof session attacks [9, 10], in which an adversary can eavesdrop on two simultaneous proofs and then interweave the captured parts of the two proofs to generate the third proof to evade checking. For this reason, both Peris-Lopez et al. and Wu et al. propose new grouping proof schemes [9–11] that can prevent adversaries from splitting a sniffed grouping proof and resist impersonation attacks [12]. That is, even though an attacker can eavesdrop on multiple proofs simultaneously, he is unable to forge a proof to pass the check.

Besides the security issues, Lien et al. [13] use XOR to create a reading order independent grouping proof (ROIGP), which reduces the time that a trusted verifier takes to check every possible sequence of generating a proof. However, ROIGP uses unicast to send its request messages and therefore it has to spend much time on collecting tags' proofs. In order to decrease the time on information gathering, Sun et al. [14] propose a grouping proof scheme, in which a reader broadcasts the request message to all tags. Thus, every tag is able to simultaneously create its unique signature for the received message. This scheme is group size insensitive because it allows each tag to compute its proofs in parallel, and therefore it has higher scalability.

Another security issue in current approaches is that a reader may not be able to connect a verifier while creating proofs [3, 5, 14–17]. There will be no trusted timer. For example, when nursing staff distribute medicine to inpatients in medicine rounds, their readers may be offline [4] and the readers' time cannot be trusted. Some offline grouping proofs [3, 5, 14] deploy RFID's timeout mechanism to keep the protocol's important messages on the tag. If timeout occurs, these messages are cleared so as to certify that the proofs are generated within the same timeframe. Burmester and Munilla [15] set a timer on their tag 1. If the proofing result is not returned to tag 1 within the timeframe, timeout occurs. But in healthcare services, time is an important issue for offline grouping proofs [16, 17] to achieve the five rights. Lin et al.'s scheme [16] uses a trusted time database to verify a reader's time. Ma et al.'s offline grouping proof [17] utilizes a clock tag's system time as a trusted timestamp when making proofs.

Apart from the offline issues, a medicine round requires exact distribution of multiple portions of medicine to different inpatients [18, 19]. In such a case, it will be impractical for nursing staff to take one portion of medicine to one inpatient at a time, and different groups of tagged items will be mixed up within the same read range of a reader. To the best of our knowledge, current grouping proof schemes [5, 14–17] need a reader to collect information from every tag in its reading range. Besides, the schemes [3, 5–8, 13–17, 20] cannot target specific group tags [21], whose proofs may include nontargeted tags or tags not on site. If a medical dispute arises, these schemes that have included extra medicines for proofing can only indicate medication errors, even though right medicines have been administered to right inpatients.

In order for a nursing staff to generate multiple offline grouping proofs in a medicine round, we propose a novel scheme to generate grouping proofs when targeted tags and nontarget tags are mixed up. The major objective of our proposed method is that our generated proof can serve as evidence to show that the nurse has carried out “five rights” when administrating medications: right patient, right medicine, right route, right time, and right dose [2]. For reducing the time of generating proofs, our scheme is designed to make a reader send queries by broadcast and to use an order independent function to create proofs. Therefore, each tag is able to compute its proofs in parallel. We will analyze the performance of the pipelining in Section 4 and show that our scheme takes the fewest instruction counts to create a proof than other group proofing schemes. Furthermore, our scheme allows multiple readers to create their proofs at the same time and the same place. It has flexibility to create different proofs in a medicine round and to generate proofs as evidence showing that the nurse has fulfilled the five rights in this medicine round. Besides, our scheme is secure against most attacks in grouping proofs [6–10, 21].

The main contributions of our protocol include the following: (1) it is able to generate proofs when targeted tags and nontarget tags are mixed up; (2) the time of generating a proof does not increase with the number of tags in a group; (3) it requires the fewest messages to generate a proof; (4) it has flexibility of generating a grouping proof in an online or offline medicine round; (5) it has flexibility of generating proofs for all tags or selected tags; (6) it allows multiple readers to generate proofs simultaneously; (7) it automates the five-right checking in a medicine round; (8) it guarantees the anonymity of tags protecting patients' privacy; and (9) it can provide reliable proofs because it is able to ensure message integrity and to prevent attacks [21] on grouping proofs, including replay of sniffed communications and multiproof session attacks.

The organization of this paper is as follows. Preliminaries and steps of our grouping proof protocol will be elaborated in Section 2. Section 3 provides a security analysis of our method, including potential threats and the levels of trust. A performance evaluation and comparison are conducted in Section 4. A conclusion is drawn in Section 5.

2. Antinoise Multiple Grouping Proof

We propose a grouping proof protocol that can generate multiple proofs at one time whether the reader is connected to a verifier or not. These generated proofs can serve as evidence to show if a nurse has fulfilled five rights in her medication services. With the help of RFID, current medication procedures have become more automatic and save more time in cross-check. It reduces the need of labor work and decreases medication errors and medical disputes in a medicine round. When a nursing staff provides medication services in a medicine round, the work can be divided into two phases [22], as depicted in Figure 1: (1) final checking before a medicine round and (2) administration of drugs during a medicine round. Therefore, our scheme is designed to generate different proofs in two phases. Figure 1(a) depicts the first phase: the nurse's reader is connected to a verifier, and it sends queries to all medicines on site to generate a proof to ensure that every dispensed medicine and no extra medicines is on the drug trolley ready for administration. Figure 1(b) shows the second phase: the nurse's reader sends a multicast message to her tag, the target inpatient, and his medicines to collect their messages for generating proofs. The reader sends the proofs back to the verifier if it is able to connect the verifier; otherwise, the reader stores the proofs until it connects the verifier (as the dash line in Figure 1(b) shows).

Figure 1

Two phases of proofing in a medicine round: (a) generating a proof for all tags and (b) generating a proof for selected tags.

To automate our medicine round proof procedure, our protocol requires every nurse's ID, prescribed medicine pack, and inpatient's wristband to be equipped with an RFID tag. All tags are physically secured and free from being compromised by adversaries. Computation power of these tags is high enough to run asymmetric cipher algorithms [23–25]. After admission, a patient is labeled with an RFID wristband that contains an identification (ID) number and some extra information, for example, his doctor's ID. Before a nurse takes a medicine round, he/she is equipped with a hand-held clinical assistant RFID reader that is authorized to access a trustworthy verifier and the hospital information system (HIS) [26], and the reader is communicating with them through a secure channel. The proof that our scheme generates is based on the integration of information that the RFID reader accesses from tags and of the information that is retrieved from hospital applications. Such proof can be used to lower the chance of nursing staff's slips and lapses in a medicine round and to certify that in a medicine round a nurse has made the five rights. The proof serves as evidence and is stored in a verifier, which is trusted and cannot be compromised.

To ensure that our scheme is able to be secure against malicious attempts, our infrastructure includes an attacker who is able to eavesdrop the reader-tag communications. And the insider intends to do the following two malicious things. First, a nurse may modify the time of a medicine round trying to hide his/her medical malpractices, such as a delayed medication service. Second, a nurse may forge a proof to cover his/her absence in a medicine round.

Our protocol consists of three parts: initialization, proofing, and verification. The three parts will be elaborated in the following subsections.

2.1. Initialization

When a nurse receives the drug administration chart for a medicine round, which specifies the time, rout, name list of inpatients, and their prescribed medicines, he/she is assigned a hand-held clinical assistant reader. The reader belongs to a reader set R that consists of n readers that have been assigned to the nursing staff for their medicine rounds; that is, $R=\left\{R_1,R_2,\dots ,R_j,\dots ,R_{n-1},R_n\right\}$ . Without loss of generality, the nurse, whose tag ID is $T_{\mathrm{0,0}}^j$ , is assigned a reader $R_j$ . After the reader and the verifier adopt existing secure mutual authentication protocols like Kerberos [27] and Public Key Infrastructure (PKI) [28] to authenticate each other, the verifier reads the nurse's ID $T_{\mathrm{0,0}}^j$ through the reader, and then the verifier sets the flag ${FA}_0={\{\mathrm{0,1}\}}^1$ to configure reader $R_j$ to collect information from all tags or selected tags within the read range for proofing. Also, the verifier sets ${FC}_0={\{\mathrm{0,1}\}}^1$ to configure that the verifier can provide a trusted timestamp for the proof or not. As the flow chart shows in Figure 2(a), the verifier writes three parameters into the reader for final checking, that is, ${FA}_0=\mathrm{1}$ , ${FC}_0=\mathrm{1}$ , and a random generated number ${NV}_0$ . In doing so, the verifier configures the reader $R_j$ (the blue reader in Figure 3) to collect proofs from all the tags within its reading range, and the reader does not need a timestamp from the trustworthy clock tag. ${FC}_0$ is set as 1 only when the reader is connected with the verifier, and when the verifier receives the proof, it checks the correctness of the proof immediately. After the nurse collects the proof with the configure reader (the steps of proof generation will be elaborated in Section 2.2), the reader sends the proof to the verifier for checking if the collected proof is the same as the proof generated by the verifier; see Section 2.3.

Figure 2

Flowchart of group proofing: (a) before medicine round and (b) during medicine round.

Figure 3

Infrastructure of our grouping proofs.

If the collected proof is verified, it means that the medicines on the trolley match the doctors' prescribed medicines. As shown in Figure 2(b), verifier writes the following k sets of parameters into the reader $R_j$ for configuration, so that the nurse can take $R_j$ to scan k patients in the medicine round. Consider

$$\begin{array}{cc}& \left\{\left({FA}_p,{FC}_p,E_{gpk}\left(N{V}_p,K{S}_p,{AH}_{SK}\left({NV}_p\parallel K{S}_p\right)\right)\right):{FA}_p=\mathrm{0},\hspace{0.17em}\hspace{0.17em}{FC}_p=\mathrm{0},\hspace{0.17em}\hspace{0.17em}\forall p\in \mathbb{N},\hspace{0.17em}\hspace{0.17em}\forall p\in \left[\mathrm{1},k\right]\right\}.\end{array}$$

(1)

The message $E_{gpk}$ ( ${NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p)$ ) is encrypted by a group key $gpk$ using current approaches like Chinese Remainder Theorem [29], ID-based encryption (IBE) [30], or ABE [31]. It ensures that only the authorized group members can decrypt the message and retrieve the randomly generated session key ${KS}_p$ and the random number ${NV}_p$ . Here, the authorized group members include the nurse with tag ID $T_{\mathrm{0,0}}^j$ ; his/her patient with tag ID $T_{p,1}^j$ ; and the patient's $mp-1$ medicines with tag IDs $T_{p,2}^j,T_{p,3}^j,\dots ,T_{p,mp}^j$ . The details of how the approaches generate a multicast message to the authorized tags in a group are not the focus of our research, so we will leave it out of discussion here.

As the purple reader is depicted in Figure 3, when flag ${FC}_{\mathrm{1}}=\mathrm{0}$ and flag ${FA}_{\mathrm{1}}=\mathrm{0}$ , a nurse takes reader $R_j$ to scan and receive messages from the tag group ( $T_{\mathrm{0,0}}^j,T_{\mathrm{3,1}}^j,T_{\mathrm{3},\mathrm{2}}^j,T_{\mathrm{3},\mathrm{3}}^j,T_{\mathrm{3},\mathrm{4}}^j$ ) of the third patient. Because flag ${FC}_{\mathrm{1}}$ is set as 0, the reader needs a trusted time from clock tag ${TC}_q$ . The dash line means that when the nurse delivers the medicines to his/her third patient, the reader stores the proof if it cannot connect the verifier; otherwise, the reader sends the proof back to the verifier right after the proof is generated (more details are provided in Section 2.2). Next, the reader sends the stored proofs to the verifier for checking; see Section 2.3.

2.2. Proof Generation

When a nurse takes his/her reader $R_j$ with flag ${FC}_p$ set as 1 to scan all tags on site (phase 1 of the medicine round), it means that the reader is connected with a trustworthy verifier and we use the verifier's system time as trusted time. So, we do not need a clock tag to provide trusted time, and the protocol (see Figure 4) jumps to step 3 to broadcast flag ${FC}_p=1$ , flag ${FA}_p=1$ , and the buffered messages (during initialization, if ${FA}_p=1$ , the verifier sends ${NV}_p$ to reader) to all the tags on site. When the tags receive the message ${NV}_p$ , each tag generates a random number $r_i$ . And, each of the tags uses the key $K_i$ shared with the verifier to hash $r_i$ , ${NV}_p$ , and their own identifier $T_{p,i}^j$ , that is, $H_{K_i}(N{V}_p\parallel T_{p,i}^j\parallel r_i)$ . Finally, each of the tags returns the generated messages and $r_i$ to the reader in step 4. When the reader collects messages from all of tags on site, it generates the final proof ${OP}_p=\{F{A}_p,\left(r_i,H_{K_i}\left(N{V}_p\parallel T_{p,i}^j\parallel r_i\right)\right):\forall i,p\in \mathbb{N}$ ,   $\forall i\in \left[\mathrm{2},mp\right]$ ,   $\forall p\in \left[\mathrm{1},k\right]\}$ and sends the proof to the verifier.

Figure 4

Grouping proof generation of selected tags. ${}^{\ast 1}$ If $F{A}_p=0$ , then $Q_p={NV}_p$ ; else $Q_p=E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))$ . ${}^{\ast 2}{STC}_p$ is sent to the tag only when $F{C}_p$ equals 0. ${}^{\ast 3}{B}_i$ is sent to the reader only when $F{C}_p$ equals 0.

When a nurse takes his/her reader $R_j$ which has been configured with ${FC}_p$ = 0, the reader has to send the buffered message $E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))$ (when ${FA}_p=0$ ) to the clock tag to obtain the trusted starting time of the proof. When the clock tag receives $E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))$ , it uses the key ${KC}_q$ , which is shared with the verifier, to hash the message $E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))$ and the message received time ${ST}_p$ as ${STC}_q=H_{{KC}_q}(E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))\parallel {ST}_p)$ . Next, the clock tag buffers ${ST}_p$ and returns ${STC}_p$ to the reader to prevent unauthorized modifications and replay attacks. When the reader $R_j$ receives the time-stamped message ${STC}_p$ from the clock tag, it sends ${STC}_p$ , flags ${FA}_p=0$ , flag ${FC}_p$ = 0, and the buffered message $E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))$ to the authorized tags by multicasting. When each of the tags receives the message with flag ${FA}_p=0$ , the tag uses its private key ${SK}_i$ to decrypt $E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))$ to retrieve ${NV}_p^{\prime }$ , session key ${KS}_p^{\prime }$ , and their message authentication code ${AH}_{SK}{\left({NV}_p\parallel K{S}_p\right)}^{\prime }.$ These tags use the retrieved ${NV}_p^{\prime }$ and ${KS}_p^{\prime }$ to compute ${AH}_{PK}({NV}_p^{\prime }\parallel K{S}_p^{\prime })$ and compare it with the message authentication code ${AH}_{SK}{\left({NV}_p\parallel K{S}_p\right)}^{\prime }$ , so as to authenticate the received message $E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))$ . If it is authenticated, each of these tags generates a random number $r_i$ and uses the key $K_i$ shared with the verifier to hash $r_i$ and the received ${NV}_p$ and ${STC}_p$ , so as to generate $H_{K_i}\left({NV}_p\parallel {STC}_p\parallel r_i\right)$ . Also, each of the tags encrypts $r_i$ , ${NV}_p$ , and its identifier $T_{p,i}^j$ with the session key ${KS}_p$ and then sends the encrypted message ${SE}_{{KS}_p}\left({N{V}_p\oplus T}_{p,i}^j\oplus r_i\right)$ , key-hashed value $H_{K_i}\left({NV}_p\parallel {STC}_p\parallel r_i\right)$ , and the random number $r_i$ back to the reader. Afterwards, these tags update the tag-verifier shared key $K_i$ as ${KS}_p\oplus K_i$ . When the reader receives the messages from all tags in this group, the reader sends to the clock tag $E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))$ and the XOR result of all the received $H_{K_i}\left({NV}_p\parallel {STC}_p\parallel r_i\right)$ . When the clock tag receives the messages at the time $ST$ , it checks whether the time from the buffered timestamp ${ST}_p$ to $ST$ is over the threshold. If all tags' messages are generated within the maximum proofing timeframe, the clock tag uses the key ${KC}_q$ shared with verifier to encrypt the buffered timestamp as ${SE}_{{KC}_q}({ST}_p)$ and then takes ${KC}_q$ to hash the received message and timestamp $S{T}_p$ :

$$\begin{array}{cc}& H_{{KC}_q}\left(S{T}_p\oplus H_{K_{\mathrm{0}}}\left(N{V}_p\parallel ST{C}_p\parallel r_{\mathrm{0}}\right)\oplus H_{K_{\mathrm{1}}}\left(N{V}_p\parallel ST{C}_p\parallel r_{\mathrm{1}}\right)\oplus \cdots \oplus H_{K_{mp}}\left(N{V}_p\parallel ST{C}_p\parallel r_{mp}\right)\right).\end{array}$$

(2)

Next, the reader receives from the clock tag message 6, which consists of $T{C}_q$ , ${SE}_{{KC}_q}({ST}_p)$ , and $H_{{KC}_q}\left(S{T}_p\oplus H_{K_{\mathrm{0}}}\left(N{V}_p\parallel ST{C}_p\parallel r_{\mathrm{0}}\right)\oplus H_{K_{\mathrm{1}}}\left(N{V}_p\parallel ST{C}_p\parallel r_{\mathrm{1}}\right)\oplus \cdots \oplus H_{K_{mp}}\left(N{V}_p\parallel ST{C}_p\parallel r_{mp}\right)\right)$ . Apart from the data in message 6, the reader also takes the following data to generate a proof ${OP}_p$ : every tag's $r_i$ and ${SE}_{{KS}_p}\left({N{V}_p\oplus T}_{p,i}^j\oplus r_i\right)$ , which are received in message 4; timestamp $ST{C}_p$ , which is received in message 2; and the flag ${FA}_p$ and $E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))$ , which are received during initialization. Consider

$$\begin{array}{cc}& {OP}_p=\left\{F{A}_p,{TC}_q,{SE}_{{KC}_q}\left({ST}_p\right),{STC}_p,E_{gpk}\left({NV}_p,K{S}_p,{AH}_{SK}\left({NV}_p\parallel K{S}_p\right)\right),H_{{KC}_q}\left(S{T}_p\oplus H_{K_{\mathrm{0}}}\left({NV}_p\parallel ST{C}_p\parallel r_{\mathrm{0}}\right)\oplus H_{K_{\mathrm{1}}}\left({NV}_p\parallel ST{C}_p\parallel r_{\mathrm{1}}\right)\oplus \cdots \oplus H_{K_u}\left({NV}_p\parallel ST{C}_p\parallel r_{mp}\right)\right),\left(r_i,{SE}_{{KS}_p}\left({N{V}_p\oplus T}_{p,i}^j\oplus r_i\right)\right):\forall i\in \mathbb{N},\hspace{0.17em}\hspace{0.17em}\forall i\in \left[\mathrm{0},mp\right]\right\}.\end{array}$$

(3)

If the reader can connect the verifier, it sends the generated proof $O{P}_p$ to the verifier; otherwise, it buffers the proof. The reader repeats the 6 steps in Figure 4 to generate a proof for each inpatient that the nurse needs to visit in a medicine round. The reader sends to the verifier all the buffered proofs for verification once it connects the verifier. If we need to check whether the nurse has administrated right medicine and right dose to the right inpatients in time, the reader requires connection with the verifier throughout the medicine round to avoid queuing delay.

2.3. Verification of Proof Correctness

Through a secure channel a nurse sends proof ${OP}_p$ to the verifier to check its correctness and integrity. If the verifier receives ${OP}_p$ with flag ${FA}_p=1$ (in phase 1), it checks if the time, from the issuing of the request to the receiving of ${OP}_p$ , is short enough for the reader to have scanned these tags at the same time. Then the verifier uses the received random number $r_i^{\prime }$ with all the tags' identifiers to compute all the possible $H_{K_i}\left(N{V}_p\parallel T_{p,i}^j\parallel r_i\right)$ and compares each of them with the received $H_{K_i}{\left(N{V}_p\parallel T_{p,i}^j\parallel r_i\right)}^{\prime }$ to obtain the received tag group

$$\begin{array}{cc}& \left\{\left\{T_{\mathrm{1},\mathrm{2}}^{j\prime },T_{\mathrm{1},\mathrm{3}}^{j\prime },T_{\mathrm{1},\mathrm{4}}^{j\prime },\dots ,T_{\mathrm{1},u\mathrm{1}}^{j\prime }\right\},\left\{T_{\mathrm{2},\mathrm{2}}^{j\prime },T_{\mathrm{2},\mathrm{3}}^{j\prime },T_{\mathrm{2},\mathrm{4}}^{j\prime },\dots ,T_{\mathrm{2},u\mathrm{2}}^{j\prime }\right\},\dots ,\left\{T_{k,\mathrm{2}}^{j\prime },T_{k,\mathrm{3}}^{j\prime },T_{k,\mathrm{4}}^{j\prime },\dots ,T_{k,uk}^{j\prime }\right\}\right\}.\end{array}$$

(4)

Last, the verifier compares whether the received tag group matches the expected tag group   $\{\{T_{1,2}^j,T_{1,3}^j,T_{1,4}^j,\dots ,T_{1,m1}^j\},\{T_{2,2}^j,T_{2,3}^j,T_{2,4}^j,\dots ,T_{2,m2}^j\},\dots ,\{T_{k,2}^j,T_{k,3}^j,T_{k,4}^j,\dots ,T_{k,mk}^j\}\}$ , checking if all the expected medicines are on the drug trolley and confirming that there is no other unprescribed medicine on that cart.

When the verifier receives proof ${OP}_p$ with flag ${FA}_p=0$ (in phase 2), it takes the proof and runs the following steps to check the five rights of a medicine round:

$$\begin{array}{cc}& {OP}_p=\left\{F{A}_p,{TC}_q,{SE}_{{KC}_q}\left({ST}_p\right),{STC}_p,E_{gpk}\left({NV}_p,K{S}_p,{AH}_{SK}\left({NV}_p\parallel K{S}_p\right)\right),H_{{KC}_q}\left(S{T}_p\oplus H_{K_{\mathrm{0}}}\left({NV}_p\parallel ST{C}_p\parallel r_{\mathrm{0}}\right)\oplus H_{K_{\mathrm{1}}}\left({NV}_p\parallel ST{C}_p\parallel r_{\mathrm{1}}\right)\oplus \cdots \oplus H_{K_u}\left({NV}_p\parallel ST{C}_p\parallel r_{mp}\right)\right),\left(r_i,{SE}_{{KS}_p}\left({N{V}_p\oplus T}_{p,i}^j\oplus r_i\right)\right):\forall i\in \mathbb{N},\hspace{0.17em}\hspace{0.17em}\forall i\in \left[\mathrm{0},mp\right]\right\}.\end{array}$$

(5)

• (1)

  Check the “right time.” The verifier uses the identifier ${TC}_q$ in ${OP}_p$ to find the key ${KC}_q$ shared with the clock tag. It takes ${KC}_q$ to decrypt ${SE}_{{KC}_q}{\left({ST}_p\right)}^{\prime }$ to retrieve the starting time ${ST}_p^{\prime }$ of the proof. To authenticate the sender and to check the integrity of the starting time ${ST}_p^{\prime }$ , the verifier computes $ST{C}_p^{\prime }=H_{{KC}_q}(E_{gpk}{\left({NV}_p,K{S}_p,{AH}_{SK}\left({NV}_p\parallel K{S}_p\right)\right)}^{\prime }\parallel {ST}_p^{\prime })$ . Then it checks the administration chart with ${ST}_p^{\prime }$ to ensure that the medicines have been administrated at right time.

• (2)

  Verify the correctness of the proof. The verifier uses the buffered session key $K{S}_p$ , buffered nonce $N{V}_p$ , and the received nonce $r_i$ to decrypt tag i's anonymous identity ${SD}_{{KS}_p}({SE}_{{KS}_p}{\left({N{V}_p\oplus T}_{p,i}^j\oplus r_i\right)}^{\prime })\oplus r_i^{\prime }\oplus N{V}_p$ and to obtain tag i's identifier $T_{p,i}^j$ . So we can associate $T_{p,i}^j$ with the nonce $r_i$ and the key $K_i$ shared with tag i. The verifier updates all the recognized tags' shared key $K_i$ as ${KS}_p\oplus K_i$ , which avoids desynchronization of $K_i$ with tags. Furthermore, in order to check the correctness of the received proof $H_{{KC}_q}{\left(S{T}_p\oplus H_{K_{\mathrm{0}}}\left({NV}_p\parallel {STC}_p\parallel r_{\mathrm{0}}\right)\oplus H_{K_{\mathrm{1}}}\left({NV}_p\parallel {STC}_p\parallel r_{\mathrm{1}}\right)\oplus \cdots \oplus H_{K_{mp}}\left({NV}_p\parallel {STC}_p\parallel r_{mp}\right)\right)}^{\prime }$ , the verifier compares it with the calculated proof $H_{{KC}_q}\left({ST}_p^{\prime }\oplus H_{K_{\mathrm{0}}}\left({NV}_p\parallel {STC}_p^{\prime }\parallel r_{\mathrm{0}}^{\prime }\right)\oplus H_{K_{\mathrm{1}}}\left({NV}_p\parallel {STC}_p^{\prime }\parallel r_{\mathrm{1}}^{\prime }\right)\oplus \cdots \oplus H_{K_{mp}}\left({NV}_p\parallel {STC}_p^{\prime }\parallel r_{mp}^{\prime }\right)\right)$ in one shoot. Because the nonce $r_i$ was associated with $K_i$ in our scheme, the verifier does not require $\mathrm{O}({mp}^{\mathrm{2}})\ast \mathrm{O}(mp!)$ times of calculation to compare all possible combinations the proof that can be generated by the nonce $r_i$ and the key $K_i$ .

• (3)

  Check the remaining four rights. When the verifier receives proofs of all k inpatients in this medicine round, it checks the sequence of these k inpatients' identifiers $T_{p,1}^j$ in the proofs. If the sequence is in an ascending order, the verifier ensures that the nurse has taken the right route. Finally, the verifier takes the set of identifier $\left\{T_{\mathrm{0,0}}^{j\prime },T_{p,1}^{j\prime },T_{p,2}^{j\prime },\dots ,T_{p,mp}^{j\prime }\right\}$ which is retrieved in step 2 to check the administration chart to ensure the nurse with $T_{\mathrm{0,0}}^j$ had administrated right medicine and right dose $T_{p,2}^j,T_{p,3}^j,\dots ,T_{p,mp}^j$ to the right patient $T_{p,1}^j$ .

3. Security Analysis

In our Antinoise Multiple Grouping Proof (ANGMP) protocol, we assume that the wired networks and wireless communications are secured and that we can leave them out of discussion in the following security analysis. Rather, our analysis will be focused on the security issues between a nurse's reader and the tags.

Antireplay Attack. Even though an adversary can pass the verification of our medicine check by replaying the logged message 4 when the same nonce ${NV}_p$ is eavesdropped on twice, the nurse will be notified that the proof has failed. It is because the verifier will detect an extra tag in the final proof. Therefore, the replayed message is still unable to evade our proof verification.

At the medicine round phase, we require that every verifier-tag communication contains a nonce $N{V}_p$ in each session and that these messages are encrypted by the shared keys ${KC}_q$ and $K_i$ and by the group key $gpk$ . Therefore, adversaries or readers (the nurse) are not able to evade our verification simply by replaying the logged messages.

Antitag Impersonation Attack. A tag that does not have the key $K_i$ to decrypt the startup message $E_{gpk}({NV}_p,K{S}_p,{AH}_{SK}({NV}_p\parallel K{S}_p))$ , which is encrypted with its group key $gpk$ , cannot generate a correct responding message for proof generation. Therefore, the tags that do not belong to this proofing session are unable to masquerade as a member of this group.

Anti-Multiproof Session Attack. In our protocol, the proof generated by a tag is encrypted with the session key $K{S}_p$ . When an adversary shuffles the eavesdropped proofs from different sessions, the proofs will be detected by the verifier as forged ones. Therefore, attackers cannot launch a multiproof session attack to interweave the blocked proofs in different simultaneous proof generation sessions.

Anticoncurrency Attack. Since each tag only needs to send one message in a session, there will be no overwriting of the computation results caused by race condition during the proof in our protocol. And our tags can use the group key to authenticate the request messages sent from the reader, so our scheme can avoid the concurrency attack.

Forward Secrecy. We use the verifier-tag shared key $K_i$ to encrypt the message that is sent from a tag and that contains the inpatient's identifier. The key is updated after each complete session. Therefore, even though an adversary compromises a tag, he cannot retrieve the information from previous logged messages in former sessions.

Anonymity. In our scheme, each tag $T_{p,i}^j$ chooses a nonce $r_i$ as a blinding factor. The adversaries cannot predict the outcome without knowing $r_i$ , the verifier-tag shared key $K_i$ , or the session key $K{S}_p$ , for example, $K{S}_p$ and $r_i$ in the anonymous identifier ${SE}_{{KS}_p}\left({N{V}_p\oplus T}_{p,i}^j\oplus r_i\right)$ and $K_i$ and $r_i$ in the hashed messages of tag i   $H_{K_i}\left({NV}_p\parallel {STC}_q\parallel r_i\right)$ and $H_{K_i}\left(N{V}_p\parallel T_{p,i}^j\parallel r_i\right)$ .

Antitracking Attack. Since our protocol is able to guarantee the anonymity of a tag and the nonces and the keys used to encrypt or hash the message are updated after every complete session, the tag ID $T_{p,i}^j$ can be protected and the adversary cannot track a tag by finding the relationship between any two messages generated by the same tag.

Guarantee of Five Rights. To sum up, an adversary is not able to launch a replay attack, multiproof session attack, and concurrency attack, nor can he make tag impersonation, to generate a valid proof evading our verification. And, the verifier uses ${ST}_p^{\prime }$ to check the administration chart to ensure that the medicines have been administrated at the right time in the first step of Section 2.3. The verifier also checks the order of all received proofs to ensure that the nurse has followed the right route in a medicine round. Besides, it takes the set of identifier $\left\{T_{\mathrm{0,0}}^{j\prime },T_{p,1}^{j\prime },T_{p,2}^{j\prime },\dots ,T_{p,mp}^{j\prime }\right\}$ , which are retrieved in step 2 from a proof to check the administration chart, so as to ensure that the nurse whose tag identifier is $T_{\mathrm{0,0}}^j$ has administrated right medicine and right dose $T_{p,2}^j,T_{p,3}^j,\dots ,T_{p,mp}^j$ to the right patient $T_{p,1}^j$ at the third step of Section 2.3.

3.1. Comparison

Here we compare our proposed scheme Antinoise Multiple Grouping Proof (ANMGP) with current grouping proof schemes in terms of certain security issues: replay attack, multiproof session attack, concurrency attack, tracking attack, and tag impersonation attack. The comparison results are shown in Table 1, in which “O” denotes that the scheme is secure against the threat; “X” the scheme is vulnerable to the threat; and “△” the scheme is secure only when certain circumstances have been satisfied.

Table 1

Comparison of resistance to attacks.

Protocol	Replay	Multiproof session	Concurrency	Tracking attack	Tag impersonation
Saito and Sakurai [7]	X	O	O	X	X
Piramuthu [8]	O	X	X	X	O
Bolotnyy and Robins [20]	O	O	X	X	O
Peris-Lopez et al. [9]	O	O	X	X	O
Lien et al. [13]	O	O	X	X	O
Sun et al. [14]	O	O	△	O	O
Ma et al. [17]	O	O	O	X	O
Peris-Lopez et al. [32]	O	O	X	X	O
Lin et al. [16]	O	O	X	X	O
Peris-Lopez et al. [11]	O	O	O	O	O
Sundaresan et al. [21]	O	O	O	O	O
ANMGP	O	O	O	O	O

Table 1 shows that our grouping proof is able to resist most of known threats to current grouping proof schemes. Saito and Sakurai's scheme [7] has been found unable to resist replay attacks [14, 21] because their tags' messages do not include a nonce. Piramuthu's method [8] suffers from multiproof session attacks [9, 10] because their first tag does not confirm the final proof. Many of the proposed schemes [8, 9, 13, 17, 20] are vulnerable to concurrency attacks as pointed out in Sun et al.'s and Sundaresan et al.'s research [14, 21]. The scheme [32] proposed by Peris-Lopez et al. also suffers from concurrency attacks because of the race condition [33]. In their scheme, when a tag receives other proofing requests before it finishes the previous one in the latter steps, the tag overwrites the former computing results. In Sun et al.'s scheme [14], when a tag belongs to two simultaneous proof-generation groups, it suffers from the race condition problem. And this renders their method prone to concurrency attacks. The schemes [11, 14, 21] and our proposed scheme ANMGP are able to guarantee the anonymity of tags. These schemes change the keys or the nonces in every tag-generated message to remove the connection between any two of their tag-generated messages. Therefore, they can prevent an adversary from sniffing the tag messages to track their tags' location. Saito and Sakurai's scheme [7] has been proved vulnerable to tag impersonation attack [10] because the verifier fails to authenticate the proof. As Table 1 depicts, the schemes [11, 21] and our proposed ANMGP are able to resist all the threats discussed above. However, the schemes [11, 21] cannot satisfy the requirements of five rights; see Table 2.

Table 2

Comparison of five-right checking.

Protocol	Right medicine	Right dose	Right patient	Right time	Right route
Saito and Sakurai [7]	O	O	O	△	X
Piramuthu [8]	O	O	O	X	X
Bolotnyy and Robins [20]	O	O	O	X	X
Peris-Lopez et al. [9]	O	O	O	△	X
Lien et al. [13]	O	O	O	X	X
Sun et al. [14]	O	O	O	X	X
Ma et al. [17]	O	O	O	O	X
Peris-Lopez et al. [32]	O	O	O	△	X
Lin et al. [16]	O	O	O	△	X
Peris-Lopez et al. [11]	O	O	O	△	X
Sundaresan et al. [21]	O	O	O	△	X
ANMGP	O	O	O	O	O

Table 2 depicts that verification of “right medicine,” “right dose,” and “right patient” has already been included in current grouping proofs. During a medicine round, the reader may not be able to connect the backend system. But the schemes [7, 9, 11, 16, 21, 32] do not provide a mechanism to stamp trustworthy time on their proofs when the nurse needs to generate multiple proofs in a medicine round (c.f. Table 3). Instead, they provide trustworthy time only when the reader is connected to the backend systems. Unlike the schemes above, Ma et al. [17] and ANMGP stamp trustworthy time on every individual offline proofs to guarantee right time. Besides, compared with the related schemes, ours is the only one that checks all the identifiers and the time sequence with the administration chart to ensure right route.

Table 3

Comparison of features in proof generation.

Protocols	Forward secrecy	Anonymity	Trustworthy time	Offline	Order independent	Simultaneity	Designatinggenerator
Saito and Sakurai [7]	X	X	△2	X	X	X	X
Bolotnyy and Robins [20]	X	X	X	X	X	X	X
Lien et al. [13]	X	X	X	X	O	X	X
Sun et al. [14]	O	O	X	O	O	O	X
Ma et al. [17]	X	O	O	O	X	X	X
Lin et al. [16]	X	X	△2	△3	X	X	X
Peris-Lopez et al. [11]	O	O	△1	△3	X	X	X
Sundaresan et al. [21]	O	O	△2	△3	X	X	O
ANMGP	O	O	O	O	O	O	O

△¹: proofs' timestamps are scheduled time, not ward visiting time.

△²: need to connect the backend system.

△³: need to get online for trustworthy time.

4. Performance

This section analyzes the communication and computation loads of our protocol and compares our protocol with the schemes that are able to generate a proof including three or more tags. Our comparison is focused on their supported functions, message lengths, and computation time. For fair comparison, the 2-tag proof schemes that we have discussed in the previous section will not be included in our performance analysis. We use Ciphertext-Policy Attribute-Based Encryption (CPABE) [31] to set the attributes and types (inpatient, nurse, doctor, and medicine), and we also use the CPABE's key generation function, $KeyGen$ , to generate the shared keys and their corresponding group keys.

Table 3 depicts the comparison results between our proposed ANMGP and other grouping proof schemes. We use “O” to denote that the scheme is capable of this function, “X” to denote that the scheme fails to achieve this function, and “△”to denote that the scheme can achieve this function only when certain circumstances have been satisfied.

Table 3 shows the supported features of current proofing schemes. It has been pointed out in [14, 21] that the schemes [7, 13, 16, 17, 20] cannot guarantee forward secrecy because their tags use permanent secrets. And the schemes [7, 13, 16, 20] have been found by [14, 21] unable to keep the anonymity of a patient's identifier. The schemes [13, 14, 20] do not stamp the start/end time on their proofs, and consequently there is no trustworthy time for the verifier to ensure when proofs are generated. Even though the schemes [7, 16, 21] stamp their time on the proofs, the schemes [7, 16, 21] need to connect the backend system to get time for each proof. The proofs of the schemes [11, 32] contain only the scheduled time for a medicine round, not the real ward-visiting time. Therefore, the schemes [7, 11, 16, 21, 32] cannot provide trustworthy timestamps for each of their proofs when the nurse needs to generate multiple offline proofs in a medicine round. The schemes [7, 13, 20] need to connect the backend systems to generate their proofs. Therefore, they cannot make offline proofs. The schemes [7, 11, 16, 21] need to go online to obtain trustworthy time for each of their proofs. The schemes [13, 14] and our proposed ANMGP achieve order independence because we fuse the tag-generated proofs with the operator XOR, which fulfills the commutative principle. Unlike those schemes that have to generate the proofs sequentially, Sun et al. [14] and our ANMGP multicast queries to all their tags in the same group. Also the RFID readers use order independence operators to fuse proofs. Sun et al. tags and ours can calculate the proofs simultaneously. The schemes [7, 11, 13, 16, 17, 20] cannot designate tags to generate proofs because they collect the proofs of all the tags on site. Although Sun et al.'s scheme [14] uses multicast to collect the proofs of the same group's tags, their first message includes all the tags on site to form the group. So they cannot designate the proof generator. Sundaresan et al.'s scheme [21] and our proposed scheme ANMGP are able to filter the proofs when our targeted tags and nontarget tags are mixed up. As Table 3 shows, compared with related grouping schemes, our proposed scheme ANMGP is the only one that is able to achieve simultaneity and to designate a specific proof generator.

The following subsections will compare the performance of our proposed proofing schemes (ANMGP-MC for medicine checking proof; ANMGP-MR for medicine round proof) with that of related grouping proof schemes. The comparison includes the transmission time, computation time, and the total time that is required for each of the schemes to generate a proof with m tags in a group.

4.1. Comparison of Transmission

In this subsection, we compare the transmission cost of our proposed ANMGP with that of related work. Besides, the transmission cost of sending a message from a reader to a tag is different from sending a message from a tag to a reader, so we analyze them separately in Table 4, in which $L_{RNG}$ denotes the length of a nonce and a timestamp, $L_M$ the length of a message authentication code (MAC), $L_H$ the length of a hash value, $L_I$ the length of a tag's identifier or a reader's identifier, $L_{SE}$ the message length after symmetric encryption, and $L_{AE}$ the message length after asymmetric encryption. To simplify computation, we do not take query messages into consideration.

Table 4

Comparison of message length.

Schemes	Reader to tag	Tag to reader
Saito and Sakurai [7]	$$L_{RNG}+m{L}_M$$	$$m{L}_M+L_{SE}$$
Bolotnyy and Robins [20]	$$\left(m+\mathrm{1}\right)\left(L_I+L_{RNG}+L_M\right)$$	$$\left(m+\mathrm{1}\right)\left(L_I+L_{RNG}+L_M\right)+L_M$$
Lien et al. [13]	$$L_{RNG}+m\left(\mathrm{4}{L}_I+\mathrm{2}{L}_M\right)$$	$$m\left(\mathrm{4}{L}_I+L_{RNG}+\mathrm{2}{L}_M\right)$$
Sun et al. [14]	$$\mathrm{3}{L}_H$$	$$m\left(L_I+\mathrm{2}{L}_{SE}\right)$$
Ma et al. [17]	$$\mathrm{5}m{L}_{RNG}+\mathrm{4}{L}_{RNG}$$	$$\left(m+\mathrm{1}\right)(L_I+\mathrm{4}{L}_{RNG})+\mathrm{2}{L}_{RNG}$$
Lin et al. [16]	$$m{L}_{RNG}$$	$$m\left(L_M+L_I\right)$$
Peris-Lopez et al. [11]	$$L_{RNG}+\mathrm{2}m\left(L_{RNG}+L_{SE}\right)$$	$$m\left(\mathrm{4}{L}_{SE}+L_{RNG}\right)$$
Sundaresan et al. [21]	$$\mathrm{8}m{L}_{RNG}$$	$$\mathrm{4}m{L}_{RNG}$$
ANMGP-MC	$$L_{RNG}$$	$$m\left(L_{RNG}+L_M\right)$$
ANMGP-MR	$$\mathrm{3}{L}_{AE}+\mathrm{2}{L}_M$$	$$\left(m+\mathrm{1}\right)\left(L_{SE}+L_{RNG}+L_M\right)+L_M$$

m denotes the number of tags in a group.

According to EPC Class-1 Gen2 standard [34], the highest transmission rate from a reader to a tag is 160 kbps and from a tag to a reader is 640 kbps. We use the transmission rate and the message lengths that we have calculated in Table 4 to compute the transmission time between a tag and its reader. With $L_{RNG}$ , $L_M$ , $L_H$ , and $L_{SE}$ assumed to be 64 bits, $L_{AE}$ 600 bits, and $L_I$ 40 bits, we add up the reader-to-tag transmission time and the tag-to-reader transmission time to calculate each scheme's overall transmission time, as depicted in Figure 5. Figure 5(a) compares the transmission time of our ANMGP-MC with that of the other grouping proof generation schemes which fuse the proofs of all tags on site. The comparison of transmission time between Sundaresan et al.'s scheme and our ANMGP-MR, both of which are able to target specific group tags, is shown in Figure 5(b).

Figure 5

Comparison of transmission time required to generate m-tag proofs: (a) collecting from all tags on sites and (b) collecting from appointed tags.

Figure 5(a) shows that our proposed ANMGP-MC has the shortest transmission time. Even though our reader has to send the initialization message to m tags, the total message lengths do not increase with the number of tags because ANMGP-MC's initialization message is broadcast to the tags. Besides, the reader-to-tag transmission rate is much lower than the tag-to-reader rate [34], so our ANMGP-MC has the shortest transmission time when compared with other proof generation schemes. This can also explain why ANMGP-MR's transmission time is shorter than Sundaresan et al.'s [21], as shown in Figure 5(b).

4.2. Comparison of Computation

In this subsection, we compare our proposed ANMGP with the related schemes in terms of their computation cost. In Table 5, $T_{RNG}$ denotes the time to generate a pseudorandom number, $T_H$ the time to hash a message, $T_M$ the time to compute a message authentication code, $T_{SE}$ the time to do en/decryption with a symmetric key, and $T_{AD}$ the time to decrypt a message with a private key. Since the computation cost of XOR and comparison operators is rather low if compared with crypto algorithms, we do not take them into consideration in our computation time analysis.

Table 5

Comparison of computation time.

Schemes	Tag	Reader	Total
Saito and Sakurai [7]	$$m{T}_M+T_{SE}$$	0	$$m\left(T_M\right)+T_{SE}$$
Bolotnyy and Robins [20]	$$m\left(T_{RNG}+T_M\right)$$	0	$$m\left(T_{RNG}+T_M\right)$$
Lien et al. [13]	$$m\left(T_{RNG}+T_M\right)+\mathrm{2}{T}_M$$	0	$$m\left(T_{RNG}+T_M\right)+\mathrm{2}{T}_M$$
Sun et al. [14]	$$\mathrm{2}{T}_{SE}$$	$$\mathrm{2}{T}_H+T_{SE}$$	$$\mathrm{3}{T}_{SE}+\mathrm{2}{T}_H$$
Ma et al. [17]	$$m\left(\mathrm{12}{T}_{RNG}\right)+T_H+\mathrm{8}{T}_{RNG}$$	0	$$\mathrm{13}m{T}_{RNG}+\mathrm{10}{T}_{RNG}+T_H$$
Lin et al. [16]	$$m\left(T_M+\mathrm{2}{T}_H\right)$$	0	$$m\left(T_M+\mathrm{2}{T}_H\right)$$
Peris-Lopez et al. [11]	$$m\left(T_{RNG}+\mathrm{7}{T}_{SE}\right)$$	$$m\left(T_{RNG}+\mathrm{5}{T}_{SE}\right)$$	$$m\left(\mathrm{2}{T}_{RNG}+\mathrm{12}{T}_{SE}\right)$$
Sundaresan et al. [21]	$$\mathrm{11}m{T}_{RNG}$$	$$\mathrm{6}\left(m-\mathrm{1}\right)T_{RNG}+\mathrm{3}{T}_{RNG}$$	$$\mathrm{17}m{T}_{RNG}-\mathrm{3}{T}_{RNG}$$
ANMGP-MC	$$T_M+T_{RNG}$$	0	$$T_M+T_{RNG}$$
ANMGP-MR	$$T_{AD}+\mathrm{4}{T}_M+\mathrm{2}{T}_{SE}+T_{RNG}$$	0	$$T_{AD}+\mathrm{4}{T}_M+\mathrm{2}{T}_{SE}+T_{RNG}$$

m denotes the number of tags in a group.

For fair comparison of computation time among the schemes listed in Table 5, we use the clock cycles required to run a DESLite [20, 35] to calculate all schemes' $T_{SE}$ , use the clock cycles required to run a PRNG [36] to determine the value of $T_{RNG}$ , use the clock cycles required to run a MAC and a hash [20, 35] to compute the $T_M$ and $T_H$ , and use the clock cycles [35, 37] to calculate the $T_{AD}$ . According to Man et al. [38], a lightweight passive tag can run 3.55 mega clock cycles per second, so that we can calculate the time required for proofing in each scheme, as depicted in Figure 6.

Figure 6

Comparison of computation time required to generate m-tag proofs: (a) collected from all tags on site and (b) collected from target tags.

Figure 6(a) shows that if compared with other schemes our proposed ANMGP-MC requires the fewest computation loads to generate a proof for all the tags. It is because we require the tags to compute their proofs in parallel, and all they need to do is to generate a message authentication code and a nonce. As Figure 6(b) shows, our ANMGP-MR takes shorter computation time than Sundaresan et al.'s scheme [21], and ANMGP-MR's computation load does not increase with the number of tags because our tags are able to calculate the proofs simultaneously.

5. Conclusion

We propose a grouping proof generation algorithm ANMGP, which is able to help a nurse to do his/her final check automatically before a medicine round. During the medicine round, even though his/her RFID reader is offline, ANMGP can also help his/her correctly administer the drugs to his/her patients. Besides, because our scheme enables the nursing staff to target specific group tags during a medicine round, it is able to generate proofs when illegitimate tags are mixed up with the targeted and the nontargeted tags. Our security analysis has shown that ANMGP is a reliable proofing scheme because it can resist most security threats, such as eavesdropping, replay attacks, concurrency attacks, tracking attacks, and multiproof session attacks. ANMGP also helps the nursing staff to achieve five rights in his/her medicine round automatically. And, since it guarantees anonymity and forward secrecy on the tags, the patients' sensitive information and location privacy can also be protected.

Moreover, we analyze and compare our tag's computational loads and the transmission time with those of other related schemes. The comparison results show that our proposed scheme requires the least time for proofing. To sum up, our proposed ANMGP is the only proofing scheme that can target specific group tags, achieve simultaneity, and have high efficiency.