Typically, low-cost EPC C1G2 passive RFID tags have non-volatile (EEPROM) memory of 1000bits to 1kilobyte (KB) [59]. However, recent RFID application proposals such as plans by Airbus to track flyable aircraft parts and components, as well as store data, such as information regarding a part’s initial construction and maintenance demands have introduced passive RFID tags with even higher memory capabilities (4KB to 8KB) [162].
Also, Atmel Corporation has introduced passive RFID tags that can support memory of between 1KB and 64KB [41].
The main requirements of the proposed approach is the storage of{Gid, T Gs, Tid, Ts, V Ts, V Ts} and 128bit PRNG, once per tag. The tag also stores {Rid, RTs, Rr−1} for each reader that is authorized to access the tag. Depending on the memory capabilities of the tag, An appropriate key length is chosen to achieve a desired level of security. Let the storage requirement for each ID be 96bits (e.g., Tid = 96bits), secret be 256 bits (e.g., Ts = 256bits) and 128 bits for each pseudo-random number. Thus the storage requirements are (96 + 256 + 96 + 256 + 128 + 128 + 128) = 1088/8 = 136bytes once per tag; and 96 + 128 + 128 = 352/8 = 44bytes per reader. This is not excessive for applications using low cost tags that require security. Hence a tag with 8KB storage capability can store up to a maximum of 167 readers (8192− 136)/44 = 183.
Given the length L of 256bits for Ts, the probability of an attacker correctly guessing Ts is 2256. Another consideration is the length of the key required to support a certain number of tags. The design of the scheme requires that the value of Tsis unique for each tag in the system. This means that with a key length of L = 256bits, the number of tags that can be supported in the system is limited to 2256. This is more than sufficient for a majority of applications. Finally, it is noted that the use of the XOR operator raises the expectation that its operands have equal bit lengths in order to prevent information leakage. As all the parameters are not of equal length, a simple modification to the standard XOR operation is suggested to meet the requirements. As an example, in the computation V 1 = Ts⊕ Tid⊕ P RNG(V Ts⊕ Vr), the operand lengths are unequal.
Here, it is recommended that the largest operand is XOR-ed with a concatenation of the XOR of the other operands. In this instance, the implementation would be V 1 = Ts⊕(Tid⊕P RNG(V Ts⊕Vr)||Tid⊕P RNG(V Ts⊕Vr)|| ... Tid⊕P RNG(V Ts⊕Vr)).
4.7 Summary
In this chapter, a robust grouping proof protocol for EPC C1G2 tags was proposed, based on simple XOR and 128bit PRNG functions. The protocol does not use hash functions which makes it viable for large scale implementations using low-cost passive tags. Formal security analysis shows that the protocol meets the necessary security requirements of RFID systems. Forward security, which is an open research issue has been addressed in the proposed protocol. Also, unlike any other protocol, the integrity of the incoming messages are verified, hence avoiding generation of invalid proofs. By taking a holistic approach to grouping proofs, the protocol meets the unique design requirements that has been identified thus far by the research community. Simulation study of the scheme showed the performance of the protocol to be within acceptable limits making it practical.
Chapter 5
Grouping Proof - Protocol II
In this chapter, a Grouping Proof protocol is proposed that uses probabilistic encryption based on quadratic residuosity. The significance of this protocol is that it provides zero knowledge to the attackers since it does not transmit the tag secret during the protocol run. After summarizing the contributions, the workings of the protocol is presented, followed by the detailed security analysis using the formal analysis models described in Chapter 3. Then, the work is compared with the contributions made by others in terms of both security and performance. A simulation study shows the performance of the proposed protocol in a simulated environment and the simulation results are compared with other methods. Finally, the chapter is concluded with the recommended parameter settings for the proposed scheme.
5.1 Introduction
As this chapter is an extension to the previous chapter, please refer to Section 4.1.1 where the design requirements for grouping proof are discussed and Section 4.1.2 where the application of the protocol is discussed. For a complete understanding on grouping proofs and the related work in this area, please refer to Chapter 2. Here, one additional motivation to this work is presented. For more details, please refer to Section 1.6.
5.1.1 Motivation
Transmitting the secret keys during the protocol run using some encryption technique is a common practice. Hence, there is a heavy reliance on the strength of the encryption technique for the protocol to be secure. While this may not be an issue with higher-end tags, it is challenging to achieve the same level of security with low-cost passive tags where the computational resources are low. Therefore, it is imperative to have methods that would: i) use less computational resources on the tag; ii) achieve the required level security without using hash functions or other complex encryption schemes; iii) and ideally not have to transmit the secret key during the protocol run. The proposed scheme in the previous chapter achieves the first two goals and this scheme achieves all three goals.
79
5.1.2 Contributions
The main contributions of this work can be summarized as:
• A secure zero knowledge grouping proof protocol that uses probabilistic encryp-tion based on quadratic residuosity. The protocol provides zero knowledge to the attackers by not transmitting the tag secret during the protocol run while still proving the authenticity of the tags involved in the grouping proof. The security correctness and privacy properties are proved using formal analysis models and shown to achieve the highest level of security.
• A secure zero knowledge grouping proof protocol that meets the unique design requirements that has been identified thus far by the research community. To my knowledge, none of the existing protocols verify the integrity of the messages, making them vulnerable to active-attacks or invalid proof generation. Also, the proposed protocol is resistent to active-attacks; provides forward security solving the open research issue [105, 123]; and is resilient to m-DoP attacks (where m represents multiple illegitimate tags) as opposed to 1-DoP [102].
• A secure zero knowledge grouping proof protocol that does not use hash functions or other complex encryption schemes. Operations of the tags are limited to modulo (MOD), exclusive-or (XOR) and 128bit PRNG functions. Thus, the proposed protocol achieves compliance with EPC C1G2 standard and also makes it a viable option for large-scale implementations on passive tags.
5.2 The Proposed Protocol
In this section, an abstract version of the proposed protocol is presented first, followed by the definition of the zero knowledge property. A detailed description of the three phases of the protocol (initialization phase, grouping proof collection phase and proof-verification phase) is then presented. The grouping proof collection phase is broken down into two parts: 1) collect partial proofs from each tag and 2) compile the whole proof and send it to the verifier. To enhance readability, clarity and easier understanding, the first part is further broken down into four steps giving a thorough explanation for each step. Table 5.1 provides a brief description for the notations that are used in the proposed protocol. The following assumptions are made: a) All entities of the RFID system have polynomially bounded resources b) The setup phase is carried out in a secure environment and c) A Trusted Timestamp Server (T T S) is used which is secure.
To understand the probabilistic encryption scheme, refer to Section 3.1.2 and for a synopsis of the protocol, refer to Section 4.2.1. Let us now look at the initialization phase of the protocol.
5.2.1 Initialization Phase
Let T (Tid1, Tid2, ...Tidm) be the tag-group where m is the number of tags in the group.
Let u be the number of protocol runs pre-authorized for a reader. During the initializa-tion phase, the verifier pre-computes informainitializa-tion for u protocol runs and stores them in the reader. Initialization is shown below for one tag-group and one run.
5.2. THE PROPOSED PROTOCOL 81
Table 5.1: Notations used in the Protocol Notation Description
h(.) Represents one-way keyed hash function; used only for pre-computation purposes
GID, Gid Tag Group ID and pre-computed value of h(GID, hs1) T ID, Tid Unique Tag ID and pre-computed value of h(T ID, hs2) RID, Rid Unique Reader ID and pre-computed value of h(RID, hs3)
hs1, hs2, hs3 Unique secrets used in h(.) to compute Gid, Tid, Ridrespectively; known only to the verifier
Gs Shared secret between the tags in a tag group
Ts Secret key unique to each tag in the system. Let Ts be of the form Ts1||Ts2||Ts3||...Tsk where k represents k-bits in Ts.
Rs Secret key unique to each reader in the system
Gj Represents the jthtag group; (j = 1, 2...p); p indicates the number of tag groups that a reader R is authorized to run the grouping proof protocol for.
rn Represents the protocol run number
Tr, Tr Tr is the current secret for the protocol run shared between the verifier and a tag and changes after each run. Tr is the previous value of Tr. Rr, Rnr Rr is the current secret for the protocol run shared between the reader
and a tag and changes after each run. Rrnis the next value of Rr. Vr Pseudo-random number generated by the verifier for each run of the
protocol
Br{1..m} Pseudo-random numbers generated by the reader during a protocol run,
for tags 1..m in a tag group.
Trindex Pseudo-random number generated by a tag during a protocol run, where index represents the random bit positions x, y, z sent by the verifier to the tag.
ΔT S Time window before which grouping proof should end
Ektv(CT S) Encrypted current timestamp CT S using secret key ktv shared between verifier and T T S
T S{1..m} Stores the result of Ektv(CT S) (encrypted current timestamp) for tags 1..m in a tag group
T Sf, T Se Future timestamp when the protocol has to run and the end timestamp that marks the end of the protocol run.
Ekrv(P ) Encrypt proof P using secret key krv shared between verifier and the reader
T, R, V Indicates tag, reader and verifier respectively
1. Initialize each tag in the tag-group with a pseudo random number Tr as Tr ← P RN G().
2. Let rn= 1 for the first run.
3. Generate future timestamp T Sf, when the protocol is to be run.
4. Generate a pseudo random number Vr for the run, as Vr← P RNG() 5. Compute G1= Gid⊕ P RNG(Gs⊕ Vr)
6. For each tag j, (where j = 1 to m) in the tag-group
• Select 3 distinct integers x, y, z randomly, s.t (1 ≤ x, y, z ≤ k)
• Using Tid and Tr of the jth tag:
– Compute Hj = Tid⊕ P RNG(Tr⊕ Vr)
– Compute μj = P RN G(Tid⊕ Tr)⊕ (x||y||z||Vr) – Update Tr as Tr← P RNG(Tr) for that tag.
• This ensures that Tid, x, y, z and Vr are stored in the reader in an encrypted form.
7. Next tag j
8. The verifier repeats the Steps 3− 7 for u runs, during which time, it increments rn by 1 for each run. The verifier also ensures that T Sf for a given run is greater that its previous run.
Data storage in each entity is described below:
• The Verifier stores all the information that is generated and computed during the initialization process, apart from storing the IDs and secrets of all the entities and the two prime numbers e, f .
• Each tag stores the tuple {Gid, Gs, Tid, Ts, Tr, Tr, Rid, Rr, Br−1, rn, h, w}. Initially, Tr = Tr and rn= 1 which increments by 1 after each successful run.
• The readers stores {Rid, Rs}, and the tuple {Gid, rn, T Sf, G1, H{1..m}, μ{1..m}, Rr{1..m}, Rrn
{1..m}}. A sample access list AL is shown in Table 5.2.
• Note that the reader does not store any sensitive information such as IDs and secrets. As seen above, G1, H{1..m}, and μ{1..m} are encrypted and without the knowledge of the IDs/secrets/pseudo random numbers, the reader (or an attacker) cannot decipher any information. It is important to note that Gid, Tid, and Ridare already in a pre-computed encrypted form using hs1, hs2, hs3 respectively, which are known only to the verifier. The unencrypted timestamp T Sf stored in the reader acts as a scheduler so the reader can start the protocol run at appropriate times. It is not transmitted during the protocol run. Hence, all the information stored in the reader are well protected.
5.2.2 Grouping Proof Collection Phase
Once the setup phase is complete, the connection to the verifier is not needed anymore.
The reader can function independently since it is equipped with all the necessary in-formation to gather grouping proofs whenever required. This makes the verifier totally offline. As noted earlier, the collection phase has two parts. The details are presented below.
PART 1: Here, the reader gathers partial-proof from each tag, for all m tags and is composed of 4 steps. Steps 1 and 2 are shown in Figure 5.1, and Steps 3 and 4 are shown in Figure 5.2.
Step 1: The reader starts the protocol run when the timestamp T Sf stored in it becomes true. It computes its challenge, gets the current timestamp from T T S and sends them along with the pre-computed server challenge, to tag 1. This step is described below.
5.2. THE PROPOSED PROTOCOL 83
Table 5.2: Sample Access List Stored in a Reader Gid rn T Sfi G1i Hi{1..m} μi{1..m} Rr{1..m} Rrn sends T S1 to the reader. As soon as T T S sends the first timestamp, it marks the beginning of the protocol run.
• The reader computes I1 = Rid⊕ P RNG(T S1⊕ Br1) which is used by the tag to authenticate the reader.
• Finally, it sends G1, H1, μ1, I1, δa, δb, T S1 to Tag 1.
Step 2: Tag 1 validates the incoming messages, authenticates the reader, computes its partial-proof and sends it back to the reader. This step is described below.
• Using stored {Rid, Rr}, tag extracts Br1 from δa as P RN G(Rid⊕ Rr)⊕ δa→ Br1
• Then, using Br1, I1, T S1, the tag verifies if Rid = I1 ⊕ P RNG(T S1 ⊕ Br1). If successful, it authenticates the reader and also confirms the message integrity of δa, I1, T S1. If the Rid check fails, these tasks are repeated using δb. If either one results in a successful match for Rid, the protocol proceeds, otherwise it aborts.
• The tag then checks if Br = Br−1. If yes, it does not respond and the protocol aborts. This is to make sure that an attacker is not replaying the message from the previous run. This attack cannot be attempted using the messages from the runs before that, since the Rid is matched only using Rror Rnr and everything else will fail. Messages from a genuine reader will always be fresh since Br is freshly generated every time. If it is not a replayed message, the tag updates Br−1 as Br−1 ← Br.
Reader Step 1 Br1 ← P RNG()
G1 ← G1⊕ Br1; H1 ← H1⊕ Br1; μ1 ← μ1⊕ Br1
δa= P RN G(Rid ⊕ Rr)⊕ Br1; δb = P RN G(Rid⊕ Rrn)⊕ Br1
Get T S1 from T T S
I1 = Rid⊕ P RNG(T S1⊕ Br1)
Send G1, H1, μ1, I1, δa, δb, T S1 to Tag 1
Tag 1 Step 2
Extract: P RN G(Rid⊕ Rr)⊕ δa → Br1
If (Rid = I1⊕ P RNG(T S1⊕ Br1)) Reader Authenticated;
Message Integrity of δa, I1, T S1 Verified Else
Use δb to extract Br1 and try again. If unsuccessful, abort.
If Br = Br−1 then abort; else Br−1 ← Br
Extract: G1⊕ Br1 → G1; H1⊕ Br1 → H1; μ1⊕ Br1 → μ1
Extract: P RN G(Tid ⊕ Tr)⊕ μ1 → x||y||z||Vr
If (Gid = G1⊕ P RNG(Gs⊕ Vr) and Tid = H1⊕ P RNG(Tr ⊕ Vr)) then
Group ID & Tag ID Verified;
Message Integrity of G1, H1 and μ1 Verified Else
Use Tr to extract x, y, z, Vr and try again.
If unsuccessful, abort;
S1 = Tsx ⊕ P RNG(Tid⊕ Tsy)⊕ P RNG(T S1⊕ Tsz ⊕ Vr) J1 = Gid⊕ P RNG(Gs⊕ Vr)⊕ Br1
K1 = null
For index in x, y, z Trindex ← P RNG() If S1[index] = 0 then
K1 = K1 || (Trindex)2 mod h else if S1[index] = 1 then
K1 = K1 || w . (Trindex)2 mod h Endif
Next index
Compute L1 = Rid⊕ P RNG((J1||K1)⊕ Br1 ⊕ Rr) Send J1, K1, L1 to Reader
Figure 5.1: Proposed Zero Knowledge Grouping Proof Protocol - Step 1 & 2
5.2. THE PROPOSED PROTOCOL 85
• The original pre-computed G1, H1, μ1 are then extracted as G1⊕ Br1 → G1; H1⊕ Br1 → H1 and μ1⊕ Br1 → μ1.
• The tag then extracts x||y||z||Vr from μ1 as P RN G(Tid⊕ Tr)⊕ μ1 → x||y||z||Vr. It then verifies if (Gid= G1⊕ P RNG(Gs⊕ Vr) and Tid= H1⊕ P RNG(Tr⊕ Vr)).
If the check fails, the tag uses Tr and repeats the operation. If either one results in a Gid, Tid match, it confirms that the messages are for this tag. Otherwise the protocol aborts.
• Using x, y, z as index, tag selects the subset of the secret Ts as Tsx, Tsy, Tsz. It then computes S1= Tsx⊕ P RNG(Tid⊕ Tsy) ⊕P RNG(T S1⊕ Tsz⊕ Vr) and J1 = Gid⊕ P RNG(Gs⊕ Vr)⊕ Br1 and initializes K1 = null.
• The tag then generates 3 pseudo-random numbers Trindexwhere index {x, y, z}.
Then, if the bit value of S1[index] = 0 the tag computes K1 = K1||(Trindex)2 mod h. If the bit value of S1[index] = 1 the tag computes K1 = K1|| w . (Trindex)2 mod h. This computation of random squares or random pseudosquares enables the tag to prove to the verifier that it has the right secret Ts, without having to reveal it, thereby providing zero knowledge to the attackers.
• Finally, the tag computes L1 = Rid⊕ P RNG((J1||K1)⊕ Br1⊕ Rr) and then sends J1, K1, L1 to the reader. This is used for verifying message integrity.
Step 3: Here, the reader validates the response from tag 1, computes the reader challenge, gets the current timestamp from T T S and sends them to tag 2 along with the pre-computed server challenge and the partial-proof from the first tag.
• Using the stored Rid, Rr and the received values J1, K1, L1, the reader verifies if Rid = L1⊕ P RNG((J1||K1)⊕ Br1 ⊕ Rr). If successful, it authenticates the tag and also confirms the integrity of the messages J1, K1, L1. Otherwise, the above step is repeated using Rnr. If either one results in a successful match for Rid, the protocol proceeds, otherwise it aborts.
• The reader then extracts J1 as J1 ⊕ Br1 → J1. It then updates Rr ← Rnr and Rnr ← P RNG(Rnr).
• For the next tag, the reader generates a fresh Br2 and computes J1 ← J1⊕ Br2; H2 ← H2 ⊕ Br2 and μ2 ← μ2 ⊕ Br2; δa = P RN G(Rid ⊕ Rr) ⊕ Br2 and δb = P RN G(Rid⊕ Rnr)⊕ Br2.
• It then gets the next timestamp T S2from T T S and computes I2 = Rid⊕P RNG(K1
⊕T S2⊕ Br2) and sends J1, K1, H2, μ2, I2, δa, δb and T S2 to tag 2.
Step 4: Here, Tag 2 computes its partial-proof using the partial-proof from the tag 1 and sends it back to the reader. As the operations are similar to Tag 1, only the minor variations are pointed out below.
• The tag authenticates the reader and verifies the integrity of the messages δa, K1, I2, T S2. It then verifies if the messages are not replayed. If not, it extracts J1, H2, μ2 and verifies Tag ID and Group ID using them. To ensure that the other participant belongs to the same group as itself, Tag 2 uses the received J1.
Reader Step 3 If Rid= L1⊕ P RNG((J1||K1)⊕ Br1⊕ Rr)
Tag Authenticated;
Message Integrity of J1, K1, L1 Verified else
Use Rnr above and try again. If unsuccessful, abort.
Extract J1 as J1⊕ Br1 → J1 Rr← Rnr; Rnr ← P RNG(Rnr);
Br2 ← P RNG()
J1← J1⊕ Br2; H2← H2⊕ Br2; μ2← μ2⊕ Br2
δa= P RN G(Rid⊕ Rr)⊕ Br2; δb= P RN G(Rid⊕ Rnr)⊕ Br2
Get T S2from T T S
I2= Rid⊕ P RNG(K1⊕ T S2⊕ Br2) Send J1, K1, H2, μ2, I2, δa, δb, T S2 to Tag 2
Tag 2 Step 4
Authenticate Reader & Verify Message Integrity of δa, K1, I2, T S2. Verify if Br = Br−1. If not, extract J1, H2, μ2and verify Group ID and Tag ID using them. These steps are similar to Tag 1.
S2= Tsx⊕ P RNG(Tid⊕ Tsy)⊕ P RNG(K1⊕ T S2⊕ Tsz⊕ Vr) J2= Gid⊕ P RNG(Gs⊕ Vr)⊕ Br2
K2= null
For index in x, y, z Trindex← P RNG() If S2[index] = 0 then
K2= K2 || (Trindex)2mod h else if S2[index] = 1 then
K2= K2 || w . (Trindex)2 mod h Endif
Next index
Compute L2= Rid⊕ P RNG((J2||K2)⊕ Br2⊕ Rr) If Rid matched using δa then Rr← P RNG(Rr) If Tid matched using Tr
Tr ← Tr; Tr ← P RNG(Tr); rn+ + Send J2, K2, L2 to Reader
Figure 5.2: Proposed Zero Knowledge Grouping Proof Protocol - Step 3 & 4
• It then computes S2using the partial-proof K1as in S2 = Tsx⊕ P RNG(Tid⊕ Tsy)
⊕P RNG(K1 ⊕ T S2⊕ Tsz ⊕ Vr). J2, K2, L2 are computed similar to Tag 1. J2 contains the same group information as J1. But this computation is done by each tag so the next tag that is processed knows that its predecessor belongs to the same group as itself.
• Tag 2 updates Tr ← Tr, Tr ← P RNG(Tr) and increments rn by 1. This is done only if Tidwas matched using Tr. If Tr was used, this update is not performed. It also updates Rr as Rr ← P RNG(Rr) if Rid was matched using δa.
• Tag 2 then sends J2, K2, L2 to the reader.
5.2. THE PROPOSED PROTOCOL 87
The same procedure is repeated for all the m tags, with the mth tag taking inputs J(m−1), K(m−1), Hm, μm, Im, δam, δbm, T Sm. After receiving Jm, Km, Lm from the last tag, the reader gets T S from T T S and computes I, δa, δb
. The last message com-puted/sent/received by the reader is represented with the index , when the reader processes tag 1 again. The reader sends Jm, Km, H1, μ1, I, δa, δb, T S to the first tag.
Tag 1 repeats its operations as in Step 2, computes J, K, L and sends it to the reader.
At this point, it updates Rr, Trand increments rnby 1. The reader verifies the message integrity as before and if it is successful, it gets the end timestamp T Sefrom TTS which marks the end of the protocol run. This process is depicted in Figure 5.3.
Repeat the process from Tag 3 to Tag m
-and complete the proof with Tag 1 Tag3
-and complete the proof with Tag 1 Tag3