Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
2Activity
0 of .
Results for:
No results containing your search query
P. 1
Providing Anonymity for RFID Systems

Providing Anonymity for RFID Systems

Ratings: (0)|Views: 65|Likes:
Published by JournalofICT
Journal of Information and Communication Technologies, ISSN 2047-3168, Volume 3, Issue 3, March 2013

http://www.jict.co.uk
Journal of Information and Communication Technologies, ISSN 2047-3168, Volume 3, Issue 3, March 2013

http://www.jict.co.uk

More info:

Categories:Types, Research
Published by: JournalofICT on Mar 10, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/09/2013

pdf

text

original

 
JOURNAL OF INFORMATION AND COMMUNICATION TECHNOLOGIES, VOLUME 3, ISSUE 3, MARCH 201316
Providing Anonymity for RFID Systems
Wissam Razouk, Ferucio Laurentiu
Ţ
iplea, Abderrahim Sekkaki and Cosmin Varlan
 
Abstract
—Radio Frequency Identification (RFID) is considered as the next generation technology, and is certainly playing animportant role for several applications. Therefore, security is a pressing need for various cases. However, Low-cost RFID tagsare very constrained devices and cannot apply the existing cryptographic algorithms due to computation and memory sizerestrictions. Consequently, RFID systems are vulnerable to numerous security attacks, which imply many privacy issues. In thispaper, we propose a security protocol that fits low-cost RFID tags requirements, and provides data protection and locationprivacy for the consumer. Moreover, different from previous works, our protocol enables searching on encrypted data withoutleaking any information, and provides also protection based on the assumption that the server is not necesserally considered asa trusted third party. We present the formal proof of correctness of our scheme based on GNY Logic.
Index Terms
—RFID Security, Anonymity, Formal Verification, GNY Logic, Security Protocols.
——————————
 
u
 
——————————
1 I
NTRODUCTION
RFID systems have become widely used in access controland security applications, and more significantly in in-dustries that require tracking or identification of productslike the supply chain management or the manufacturingprocess. The potential benefits of RFID applications aremultiple; first, unlike barcodes, RFID tags do not requirea line of sight to be read; they can be read from distanceand from any orientation. Therefore, a huge number of tags can be scanned remotely at once and very quickly.Second, bar codes are in most cases scanned only once atthe checkout during the lifetime of the item. On the otherhand, RFID systems have read and write capabilities,which allow for data to be changed dynamically at anytime. Thus, RFID systems can be deployed in a way inwhich numerous supply chain management applicationscan be simultaneously implemented, benefiting all enti-ties involved in the commercial transaction process (themanufacturers, the retailers and the users).An RFID system typically consists of three main compo-nents; the readers (or transceivers), the tags (or transpond-ers) and a back end database. The reader starts the com-munication by querying the tag and transferring energy byemitting electronic waves. The tag charges up and uses RFenergy to send the stored data.
1.1
 
RFID Security and Privacy Requirement
Many studies have developed a classification of RFID at-tacks and presented several analyses of potential securitytreats in RFID systems. We describe below some securitygoals; nevertheless, we refer the reader to the studies [2],[6], [1], [9], [5] for a comprehensive and detailed descrip-tion of possible attacks.We summarize the RFID security requirement as fol-lows:
Resistance to tag impersonation attacks:
The protocolshould not allow the authentication of fake tags as long asthe tags are not compromised.
Resistance to DoS attacks:
Power interruption or faultinduction should not compromise future communicationor make hijacking possible.
Resistance to replay attacks:
Impersonation using previ-ous messages should not be possible.
Backward and forward traceability:
Should be providedeven if the tag is compromised. An attacker should not beable to identify past or future interactions [7].To avoid privacy treats the protocol should also satisfythe following requirements [8]:
Resistance to traceability
: The tag's messages should beanonymous and randomized. Hence, an adversary shouldnot be able to link messages to each other or to the tag.
Resistance to information leakage:
Only a genuine read-er should be able to access the information associatedwith a tag [8].
1.2
 
RFID Performance Requirements
In order to fit the low-cost RFID tags requirements, a secu-rity protocol has to fulfill the following conditions:
Computational capabilities:
Cost effective RFID tags arevery constrained devices and cannot afford very intensivecomputations due to their low power and small memorysize. Thus the computational effort required at the tagside is considered as an important criterion.
Storage abilities:
The protocol should not exceed the ca-pacity of the tag, as low-cost RFID tags have very limitedstorage area
Message traffic:
For performance optimization reasons,the number and size of the messages exchanged betweenreaders and tags should be minimized [7].
Scalability:
The readers usually have to perform an ex-haustive search over a list of entries in order to identify orauthenticate a tag. This has to be done in a reasonabletime to provide scalability.The rest of this paper is organized as follows: First, wesummarize the relevant related work in Section 2, thenwe present our security protocol in Section 3. In section 4,we formally verify the proposed scheme. Next, we dis-cuss the security and performance evaluation in Section 5.
 ———————————————— 
 
 
Wissam Razouk and Abderrahim Sekkaki are with the Department of  Mathematics and Computer Science, Hassan II University, Casablanca, Morocco.
 
 
Ferucio Laurentiu Tiplea and Cosmin Varlan are with the Faculty of Com- puter Science, “
Alexandru Ioan Cuza
” University of Iasi, Iasi, Romania.
 
 
17
Finally, we make conclusions in Section 5.
2 R
ELATED
W
ORK
 
The hash lock scheme
was first proposed by Weis et al. [10],followed by
the improved hash-lock scheme
where a randomvalue is generated by the tag to avoid traceability attacks.However, their protocol is considered insecure, as eaves-dropping and impersonating attacks can easily be done.In the same way, Henrici et al. [4] presented
the random-ized hash lock scheme
where the tag is authenticated withits ID hashed together with a transaction number. Thetag's identifier is refreshed using a random value sent bythe reader. Their protocol is simple but cannot resist man-in-the-middle attacks; since messages between the tagand reader can be relayed, and an attacker can be easilyauthenticated by the reader before the next session.Indeed, the one-wayness of hash functions is consideredas an efficient solution for low-cost RFID tags [11], andmany proposals were published to address RFID securityissues using this cryptographic tool, but obtaining a max-imum security for these very constrained devices is stillconsidered as a real challenge [15].
3
 
T
HE
P
ROPOSED
S
ECURITY
P
ROTOCOL FOR
RFID
 
S
YSTEMS
 
3.1
 
Notations and Assumptions
We use the following notations to describe the protocolthroughout the paper:Our protocol works with the assumption that the tag hasa hash function, a re-writable memory EEPROM and thecapability to keep state during a single session.Usually, in the previous proposed protocols in the litera-ture, the server S is assumed to be a TTP (Trusted thirdparty) and the communication channel between the read-er R and server S is secure. However, we assume that S isnot necessarily a TTP and the communication channel between R and S is insecure.We also assume that R and S have normally sufficientcomputation abilities; and thus, can support cryptograph-ic operations.
3.2
 
Initial Setup
1.
 
Each tag stores initially a pointer encrypted withthe server's secret key. In addition, T possesses ahash function which is used to com-pute
))(,,(
 E  N  N  H 
 R
.
Also, a counter C is in-cremented after each query to keep the protocollightweight and produce randomness in the tag'sresponse; thus, we choose to generate the pseudorandom number
 N 
using
)(
 N  H 
R
 , insteadof implementing a random number generator onthe tag side, wich is not easy and practical on low-cost RFID tags.2.
 
The reader stores the encrypted pointers, and pos-sesses a random number generator to gener-ate
 R
 N 
. A secret key
R
 K 
is also necessary to re-trieve the encrypted data received from the server.3.
 
The server S has a secret key
 K 
to retrieve Pfrom
)(
 P  E 
and stores also the encrypted infor-mation related to the tag.
3.3
 
Detailed Description
The general description of the proposed scheme is de-tailed as follows:
Step 1
The reader R generates a fresh random nonce
R
 N 
.Then R sends
 R
 N 
along with the request to the queriedtag T. In our scheme
 R
 N 
is very important, as it is in-cluded in the tag's answer to prevent from replay attacksand detect illegitimate responses.
Step 2
When queried, the tag T generates a fresh randomnumber
 N 
 , this nonce is hashed together with the read-er's nonce
 R
 N 
and the encrypted pointer
)(
 P  E 
to forma one-time-use authentication key. Then T sends
 N 
along with the output of the computedhash
))(,,(
 E  N  N  H 
 R
. This allows protecting the pro-tocol from replay and man-in-the-middle attacks. There-fore, the reader is able to verify the freshness of the re-ceived message.
Step 3
When the reader receives the tag's response, R ver-ifies at first whether the forwarded message is valid ornot by computing H' using
 N 
and
 R
 N 
for the storedencrypted pointers, and comparing H' with H until amatch is found. This proves that the message is fresh andgenuine, mainly because it was generated using the read-er's and tag's nonce, and also the secret encrypted pointer.If the received message is valid, R can easily forward theencrypted pointer
)(
 P  E 
to the server.
Step 4
The server is not considered as a trusted third par-ty since it stores only the encrypted information anddoesn't know about the decryption process. Thus, whenthe pointer has been recovered using the server's secretkey
 K 
 , S can easily access the encrypted data to be sentin the next step to the reader.
Step 5
Finally, the reader receives the encrypted infor-mation and retrieves data using its private key
R
 K 
.
TABLE
 
1P
ROTOCOL
N
OTATIONS
 
RFID tag
R
RFID reader
 
S
 
The server that stores the encryptedf data
 
N
T
 
A random number generated by the tag
 
N
R
A random number generated by the read-erK
S
 The secret key of the serverK
R
 The secret key of the readerPA pointerDDataHThe output of the hash functionE
K
(M)An encrypted message M with the key K
Fig.1. Description of the proposed protocol.
 
18
4
 
F
ORMAL VERIFICATION
 
Formal methods have a very important role in examiningsecurity protocols. Numerous logic techniques have high-lighted many protocol weaknesses, and are consideredsuccessful [13]. Furthermore, the designers are forced tomake security assumptions, and to achieve well-definedauthentication goals. In this paper we use GNY Logic(Gong L., Needham R., and Yahalom R.) [3], which is adirect successor to BAN [14] logic; it is considered rea-sonably powerful in its capacity to reveal whether a secu-rity protocol is ambiguous, incorrect, inconsistent or in-complete [13]. Indeed, message extensions are used inGNY Logic to describe the formalization of the protocol.Thus, the involved parties can transfer and reason abouttheir beliefs. Moreover, unlike BAN Logic which assumesthat all parties are honest and competent, it is possible todeal with diverse levels of trust.In this section, we show the correctness of our scheme based on GNY Logic [3]. Precisely, it means that after theprotocol execution, both parties T and S are sure that thereceived messages are fresh. They should also believe thatthey are sharing secrets in case the communication chan-nel is insecure.
4.1
 
Formalization of the Protocol Steps
The conventional notations are not suitable for manipula-tion in logic. Thus, the first step in logic-based verificationconsists of avoiding ambiguity by specifying the protocolin a logical language, and expressing the messages of theprotocol as a logical formula. In this section, we simplifythe proposed protocol as a generic type. Then we formal-ize it for verification purposes as presented in Table 2.In S1, the tag is told a random nonce
 R
 N 
from the reader,which is going to be included in the tag's response in or-der to enable the security check on the reader’s side. In-deed; in S2, the reader receives the tag's nonce
 N 
alongwith
))(,,(
 E  N  N  H 
 R
. After the reader has found amatch for the received hash, the back-end server is told inS3, the encrypted pointer
)(
 P  E 
. In S4, the reader is toldthe encrypted data
)(
 D E 
R
stored in the server using theaddress contained in the recovered pointer P. The rele-vant GNY Logic notations are listed in the Appendix.
4.2
 
Specification of the Initial Assumptions
The second step in the logic-based formal verificationincludes the beliefs and possessions of the different par-ties at the beginning of each session of the protocol. In-deed, unlike most of the proposed security protocols inthe literature, we assume that the server is not a trustedparty. Thus, the information is not stored in clear, andonly a genuine reader possesses the key to recover theencrypted data. The formalization of the initial assump-tions for our scheme is listed as shown in Table 3.The first three rows state that the tag has a hash functionand stores the encrypted pointer and a counter. While theassumption (4) states that the reader possesses the en-crypted pointer. The next row states that the server storesonly the encrypted data. Each principal believes in itsnonce freshness in (6) and (7). Finally, the last row isabout a recognizability assumption; the reader recognizesthe encrypted pointer.
4.3
 
Specification of the Protocol Goals
The third step of logic-based formal verification concernsexpressing in the language of logic the beliefs and posses-sions of the involved principals at the end of a successfulprotocol run. The goals of the proposed scheme are de-tailed in table 4.The first row states that the reader believes that the re-ceived information is fresh. The goal G2 states that thereader is able to recognize the formula. The goals G3 andG4 are about authentication; each principal should be-lieve that the received information was conveyed by itscounterpart. The Goals in G5 and G6 concern the confi-dentiality of the information.
Protocol Generic Type
M1:
 
 R
 N  R
:
 
M2:
 
))(,,(,:
 E  N  N  H  N  R
 KS  R
 
M3:
 
)(:
 E  R
 KS 
 
M4:
 
)(:
D E  R
 KR
 
Formalized Protocol
S1:
 
 R
 N 
 S2:
 
))(,,(,
 E  N  N  H  N  R
 KS  R
 S3:
 
)(
 P  E 
 KS 
 S4:
 
)(
 D E  R
 KR
 
TABLE
 
2
 
F
ORMALIZATION OF THE
P
ROTOCOL
S
TEPS
 
G1:
 
)))(,,(,(#
 E  N  N  H  N  R
 KS  R
 
G2:
 
)))(,,((
 E  N  N  H  R
 KS  R
Ο
 
G3:
 
)))((~
 E  R
 KS 
 
G4:
 
)))((~
D E  R
 KS 
 
G5:
D R
 G6:
 
TABLE
 
4
 
G
OALS OF THE
P
ROPOSED
P
ROTOCOL
 
1:
 
)(
 X  H 
 
2:
 
)(
 P  E 
 KS 
 
3:
 
 
4:
 
)(
 P  E  R
 KS 
 
5:
)(
 D E 
 KR
 6:
)(#
 N 
 7:
)(#
 R
 N  R
 8:
))((
 E  R
Ο
 
TABLE
 
3I
NITIAL
A
SSUMPTION FOR
P
ROOF
 

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->