Communication Phase

As shown in Figure 4.2, the proposed protocol is described in detail according to the sequence of messages exchange. A one session of multi-level authentication process is from step 1 to step 4.

Step 1: In this step, R usually applies a collision-avoidance protocol like the secure binary tree walking or any other anti-collision protocol. R generates a fresh random nonce, N^BR^B, and sends N^BR^B

to query T ^nearby.

Step 2: When T is queried by R ^, T yields X and D to R . X is composed of TID and the output of keyed hash function, H^BBID^B(N^BR^B). TID is used as the identification information to DB ^{and HB}BID^B(N^BR^B) value can be used to verify the legitimate R ^{with NBRB} .The key, Kt1, shared by T ^and DB ^{is aimed} to authenticate the validity of T. Moreover, BID is the shared secret between R ^and T^.

Step 3: R creates the keyed hash value with N^BR^B by BID after step 1. Until receives response, R uses the value to do X-or function with X, and will get TID. R will also get the non-secure data D^B0 ^Bfrom T. After that, R encrypts TID and N^BR^B together with the key Kr and then forwards it to DB^. At the same time, R also transmits RID to DB for identification. Within this step, DB authenticates R ^and T consequently with RID and TID, respectively.

‧ At first, DB judges whether the forwarded RID is legal or not by searching with reader information throughout reader database table. If RID is registered, DB takes the corresponding key Kr so it can decrypt the received data. Kr is the shared secret key only between R ^and DB^{, so} DB can detect the illegal R and discards the forwarded message.

‧ Furthermore, DB gets TID and verifies it from tag’s information of database. Then, DB authenticates T ^{with Kt1 and Kt2}. If the authentication is failed, DB will terminate in this session.

Since DB initially stores the unique chip serial number, ID, and temporary ID index TID .DB can evaluate the linkage between the forwarded authentication information H^Bkt2^B(ID)with Kt1 and T itself in order to prevent forgery. Forgery can be detected and prevented by DB ^{at this} moment.

At the same time, DB detects and prevents the man-in-the-middle attack since N^BR^B is used as the factor of the man-in-the-middle attack detection. Similarly, the replay attack can be also detected and prevented simultaneously.

Step 4 : DB encrypts the corresponding security data and N^BR^B in accordance with level of reader.

Then, DB replies the message E^BKr^B (D^BL^B, N^BR ^B). After this step, the corresponding decryption process, D^BKr^B (D^BL^B, N^BR ^B), is processed by R to get security data. Thus, security data of T is securely obtained only by the legitimate R although the adversary eavesdrops the reply messages on the insecure channel.

Figure 4. 2 Communication Phase

In [20], J. Yang et al. proposed a scheme with key changed in every session. In our opinion, changing key every session is a heavy computation cost for database server.

As shown in Figure 4.3, there are five steps in the process of updating Key Kt1 and Kt2, and since step 1 to step 3 is the same as in communication phase, we don’t explain again, and we focus on step 4 and step 5.

Step 4: After DB received the message 3, DB ^verifies T and detects the key Kt1 is overdue. Then, DB generates a new key Kt1’ substitute Kt1 for T and also alter the corresponding TID by using the new key Kt1’. Afterward DB calculates K^Bnew^B=Kt1’⊕Kt1⊕Kt2, Y=H^BKt1^B(H^BKt2^B(ID)⊕N^BR^B⊕Kt1’) and encrypts them with N^BR^B and corresponding security data in accordance with level of reader.

Then, DB replies the message E^BKr^B (K^Bnew^B, N^BR^B, Y, D^B1^B). After this step, the corresponding decryption process, D^BKr^B (K^Bnew^B, N^BR^B, Y, D^BL ^B), is processed by R to get security data.

Step 5: Since R meets the update message, R sends Y, K^Bnew^B, to T to update Kt1 stored in T^{. After} that, T obtains the new key Kt1’ by doing XOR function with Knew, Kt1 and Kt2. T ^also calculates H^BKt1^B (H^BKt2^B (ID)⊕ N^BR^B⊕ Kt1’) and compare with Y, then Kt1’ substitutes Kt1. Up to now, update process of Kt1 is completed.

In other case, DB detects that the key Kt2 is overdue on Step 4, and then Kt2 will be updated .The update process of Kt2 is similar to Kt1.Use Kt2’ instead of Kt1’ from Step 4 to Step5 explained above. The most important change is Y=H^BKt2^B(H^B_Kt1^B(ID)⊕NR⊕Kt2’) in Kt2 update process.

Figure 4. 3 Key Update Phase (for K

K

)

Besides updating key in T, the key Kr in R will be also updated by DB. The key update protocol for Kr is shown in Figure 4.4. There are three steps described below.

Step 1 : In this step, R keeps the record of Kr, once Kr is overdue, R sends request to DB voluntarily. R generates a fresh random nonce, N^BR^B, and H^BBID^B( N^BR^B, Kr), an output of keyed one-way hash function. R sends them encrypted with Kr as update information and RID to DB^.

Step 2 : At first, DB searches the RID in reader table and find out the related key Kr to decrypt the received message. Then, DB verifies whether the forwarded N^BR^B is valid by comparing the value H^BBID^B( N^BR^B, Kr). BID and Kr is the shared secret key between DB ^and R^{, so} DB ^can recognize it legal R or not. If R is legal, DB generates a fresh random nonce, N^BDB^B, and a new key Kr’ for the R, and hide Kr in Z=Kr’⊕BID⊕Kr. Afterward DB encrypts them together with a output of the keyed one-way hash function, H^BBID^B( N^BDB^B, Kr’),by Kr, and sends it to R. At the same time, the nonce N^BR^B obtained from R is also retransmitted to R^.

Step 3 : R checks the nonce N^BR^B, and confirms it sent by R itself in step 1 before. After that, R decrypts the message and does X-or function with Z, BID, and Kr, so R obtains the new key Kr’.Kr’ is used to verify the value H^BBID^B( N^BDB^B, Kr’). If R successfully finishes the verification, R uses Kr’ replace Kr, and then encrypts N^BDB^B by Kr’ as a reply message to DB^{. On} DB ^side, DB checks the nonce N^BDB^B, if it is admissible, DB will also replace Kr by Kr’ in R table.

Figure 4. 4 Key Update Phase (for Kr)

BID is an identifier of a DB, both authorized R ^and T from the same system has the same share secret BID in the beginning. Moreover, BID plays a major role in every phase, here, it is recommended that DB changes BID after a period of time avoid various attacks, and DB ^will also ask R/T updating their BID in their memory. New BID is the hash value of old BID, BID^Bi+1^B=H(BID^Bi^B). Every time when DB ^request R/T to update BID, they hash BID in hand until get the same value with DB^’s.

Chapter 5