968

IEEE TRANSACTIONS ON MOBILE COMPUTING,

VOL. 8,

NO. 7, JULY 2009

Message Authentication in Computationally Constrained Environments

Benjamin Arazi, Senior Member, IEEE
AbstractRFID and Wireless Sensor Networks exemplify computationally constrained environments, where the compact nature of the components cannot support complex computations or high communication overhead. On the other hand, such components should support security applications such as message integrity, authentication, and time stamping. The latter are efficiently implemented by Hash Message Authentication Codes (HMAC). As clearly stated in the literature, current approved implementations of HMAC require resources that cannot be supported in constrained components. An approach to implement a compact HMAC by the use of stream ciphering is presented in this paper. Index TermsSecured communications, HMAC, constrained environments, challenge response, stream ciphers.

1
1.1

INTRODUCTION
The Challenge Response CR, generated in the interrogated component (top of the figure), is the MAC of three values: 1) the components secret key K, 2) a random challenge C received from the interrogator, and 3) the message M whose authenticity is to be proved. Subsequently, the interrogated component transmits: 1) the components public key P K, which is an encrypted version of K issued by the system manager and stored in the component, 2) M, and 3) CR. Upon receiving the above three values, the interrogator performs the operations shown at the bottom of the figure. The interrogator first retrieves K out of the received P K, using a system decryption key. In practice, the system decryption key is not necessarily stored at the interrogators facility. Here, the interrogation operations can be performed in an external secure place. Under another version, the key K of the interrogated component is retrieved from a secured network, rather than being recovered by decrypting a value P K submitted by the component. The interrogating receiver then has the same three values that generated the MAC at the interrogated component. The same MAC is now calculated at the interrogating receiver, and the output is compared to the received CR. If the two values match, the integrity and authenticity of the received message is confirmed. The interrogated components response CR is unique, as it depends on the private secret key K which differs for different components. The procedure prevents replay attacks, since the response sent by the interrogated component depends on the real-time random challenge C sent by the interrogator. The same mechanism can also be used in access control, preventing illegal writings of a message M into the component, by still executing a MAC operation in the component. Here, the component challenges the external party, asking it to prove that it knows the components secret key. In this scenario, the direction of flow of C and M in Fig. 1 is reversed. It is the component which generates C. The comparison of the MAC values is done in the component. Upon success, M is allowed to be written.
Published by the IEEE CS, CASS, ComSoc, IES, & SPS

MAC and Challenge-Response Interrogation ESSAGE integrity and authenticity, and replay prevention, are essential in security-related communications. Here, a receiver is expected to be able to verify that a received message, originally transmitted by a valid source, was not changed. Also, the receiver has to verify that the message was not transmitted by a cloned source, and is not a retransmission of an originally genuine message transmitted in the past by a valid source. Technically, verifying message integrity and authenticity is based on the receivers ability to prove to itself that the transmitter stores a valid secret key that was used when the message was transmitted. Surely, symmetric and asymmetric cryptographic schemes can also be used in satisfying the above. In this paper, we treat the case where the facility at the data source has limited resources. In such environments, message integrity and authenticity is usually verified using Message Authentication Code (MAC). MACM; K is a one-way transformation of the message M and a secret key K shared with the verifier. The values M and MACM; K are both sent to the verifier. Upon receiving these values, the verifier generates himself a value MAC 0 M; K based on the received M and the value of K known to him. If MAC 0 M; K = MACM; K, the verifier decides that the message is authentic and equals its original value. If an attacker has access to an oracle which possesses K and generates MACs for messages M chosen by the attacker, it should be infeasible to guess the MAC value for any new message not interrogated before. To prevent illegal replaying, there is also a need for a time-dependent proof. This is achieved by a challenge-response interrogation procedure, as depicted in Fig. 1.

. The author is with the Department of Electrical and Computer Engineering, Ben Gurion University, Beer Sheva 84105, Israel. E-mail: arazi@ee.bgu.ac.il. Manuscript received 23 Mar. 2008; revised 20 Nov. 2008; accepted 10 Feb. 2009; published online 11 Feb. 2009. For information on obtaining reprints of this article, please send e-mail to: tmc@computer.org, and reference IEEECS Log Number TMC-2008-03-0104. Digital Object Identifier no. 10.1109/TMC.2009.40.
1536-1233/09/$25.00 2009 IEEE

ARAZI: MESSAGE AUTHENTICATION IN COMPUTATIONALLY CONSTRAINED ENVIRONMENTS

969

section. This general approach is especially suitable when dealing with constrained hardware resources. Even if text is a few hundred of bits long, where K is about 100 bits, it would still be recommended to process text in parts. This is the approach taken in this paper.

1.3

Fig. 1. MAC-based challenge-response procedure.

There are other variations to the circuit of Fig. 1. For example, in some cases, there is no message M to be authenticated, and the purpose of the interrogation is just to verify that the interrogated component really has the valid K associated with P K. In other cases, like prevention of car-theft, K is installed in advance in the interrogated component and the interrogating transmitter-receiver. Here, P K and its handling are redundant.

1.2 MAC and HMAC in the Context of This Paper As described above, MACM; K is a one-way transformation of the message M and a secret key K. The implementation this transformation can be based on various approaches. Hash Message Authentication Code (HMAC) is a hash transformation parameterized with a secret key. That is, it is an implementation of MACM; K. In this paper, we treat a standardized HMAC, specified in [1] , [2], [3], [4]. The security of such implementations has been revised [5], stating that the attacks do not contradict the security proof of HMAC, but they improve our understanding of the security of HMAC based on the existing cryptographic hash functions. The suggested implementation of HMAC is of the form
HMAC text; K HKout kHKin ktext; where H is a cryptographic hash function, Kin and Kout are two keys, derived from K, k denotes a concatenation, and text is the text to be hashed together with K. In relation to the challenge response procedure of Fig. 1, we adopt an implementation where text CkM. The following is one recommended way of constructing Kin and Kout out of K. Let K be b-bytes long. opad and ipad denote b-byte values, consisting, respectively, of b repetitions of the byte 01011100 and 00110110. Then, Kout K opad and Kin K ipad, where denotes an XOR. Any standard hash (e.g., SHA-1 [6]), as well as the above specified HMAC implementation, is specified in a way which facilitates the processing of a relatively long text, by iteratively processing it in parts. That is, text is broken into sections, which are processed one at a time. Each such section is processed by a one-way block transformation whose parameters are limited in size to that of the processed . . . .

Interrogation in Highly Constrained Environments Radio Frequency IDentification (RFID) facilitates, by definition, identification by wireless communications. In many applications an RFID tag is required to prove the authenticity of data it transmits. The American Government Accountability Office (GAO) states that RFID tag should resist counterfeiting or cloning, replay, and eavesdropping [7]. Other RFID security considerations concern user privacy, and more. European efforts in this direction are described in [8]. An extensive RFID-security bibliographical list, updated on a continuous basis, can be found in [9]. Still, under the current state of affairs the Dutch RFID Transit Card has been hacked before it was even deployed [10]. It is claimed that E-Passports can be cloned in minutes [11]. It was shown how it is possible to clone RFID cards, or to insert malware that dupes an unsuspecting and apparently, relatively unsophisticatedcard reader into unlocking the building for an intruder [12]. The use of RFID in medical applications presents special security demands. In an article carrying the very serious title RFID can prevent drug deaths, it is stated that the inherent problem with EPC [RFID] technology, from a pharmaceutical perspective, is the lack of anticloning features in the EPC chip itself [13]. RFID is also being used in medication control [14]. There is no way that such systems will pass regulations like The Health Insurance Portability and Accountability Act (HIPAA) without assuring patients privacy. Implementing hashing in RFID is the subject of numerous papers. Samples of articles on this issue include [15], [16], [17], [18], [19], [20], [21]. More can be found in [9]. Two main constraints are considered here: 1) Costs: Wide adoption of RFID is crucially dependent on the price of a tag. This is translated into a limited number of logic gates used in the tag. 2) Power consumption: An RFID tag is operated by a magnetic field radiated from the reader. It does not have its own power source. This puts a severe limitation on the number of gates that can operate simultaneously. The following representing statement [15] summarizes the issue: Tag MAC functionality would allow tags to authenticate themselves, but is beyond current lowcost tag resources. An accurate analysis [16] states that the implementation of SHA-1 requires 12,000 logic gates, while the cost constraints of an RFID tag permit the use of no more than 2,500 gates. It should be noted that hardware implementations of hash transformations do exist. For example, phone cards used in Europe are based on a very low cost proprietary microchip that hashes together the cards information content and some secret codes. A TI technology for cattheft prevention recently received attention, as it was broken, not necessarily due to a faulty design, but due to the selection of a short key [22]. The circuit is considered proprietary, although its design leaked to the public. Such

970

IEEE TRANSACTIONS ON MOBILE COMPUTING,

VOL. 8,

NO. 7, JULY 2009

examples further emphasize the need for an approved, well-analyzed, widely accepted, nonproprietary methodology for designing compact circuits that implement a secure MAC.

1.4 Stream Ciphers A stream cipher is a symmetric encryptor (i.e., the transmitter and receiver share the same secret key). The key forms a seed which generates a pseudorandom keystream. At the transmitting end, this keystream is XORed with the cleartext stream, yielding a ciphertext stream. The receiver, having the same seed key, generates synchronously the same keystream. XORing with the received ciphertext yields the cleartext back. Stream ciphers operate at a higher speed than block ciphers and have relatively low hardware complexity. Fundamental security requirements that should be satisfied by a stream cipher concern randomness characteristics of the generated keystream and inability to recover the secret seed key by knowing the generated keystream. Development and analysis of stream ciphers are subject of continuous activities. A current major project is eSTREAM, organized by the EU ECRYPT [23]. 1.5 Related Work and the Structure of the Paper As indicated, compact MAC implementations in constrained environments are of the essence. Possible implementations of hash in constrained environments, based on block ciphers, are surveyed in [21]. On the other hand, activities in stream ciphering are continuously being pursued. Secure and well-analyzed stream ciphers offered by the eSTREAM project are very compact and use limited hardware resources. Techniques for implementing MAC based on stream ciphers can therefore offer high efficiency, possibly consuming minimal resources while being highly secured. Such implementations have already been introduced [24], [25], [26], [27]. These approaches concern stream-cipher-based designs dedicated to MAC implementations, combining hashing and encryption within an integrated solution. Other approaches to the use of stream-ciphers-related techniques in MAC implementations concern streaming macs [28] and energy scalable universal hashing [29], [30]. These again integrate hashing and encryption as a design philosophy. It is the purpose of this paper to illuminate the use of stream ciphers in compact hashing from a different angle. Here, a one-way block transformation, based on a stream cipher, is first implemented as a stand-alone universal circuit. This can then also be turned into an HMAC implementation. Techniques for turning a stream cipher into a one-way block transformation are presented in Section 2. The presentation includes security analysis, while considering the specific scenarios where the offered solution is intended to be deployed. Ways of iterating a one-way block transformation, based on stream ciphering, for the purpose of performing a general hash, are presented in Section 3. This turns into HMAC transformation by implementing HMAC text; K HKout kHKin ktext. A case study is treated and analyzed in detail in Section 4.

Fig. 2. One-way block transformation based on stream cipher.

ONE-WAY TRANSFORMATIONS BASED ON STREAM CIPHERING

2.1 Block Transformation Based on Stream Cipher A stream cipher exhibits the following features:
It produces a pseudorandom keystream output which is very strongly dependent on a parameterizing secret key S. (We purposely denote the parameterizing key differently from the secret key K used in the intended MAC application.) A minor change in S causes major output changes. 2. The underlying security of the cipher is measured in terms of the difficulty in retrieving S, given an output keystream of any feasible length. The circuit of Fig. 2 presents an approach for utilizing the above two features of a stream cipher in implementing a one-way block transformation. The input block S, acting as the parameterizing key of the stream cipher, yields a keystream that enters a Cyclic Redundancy Code (CRC) circuit. The circuit is clocked for a number of cycles that is significantly larger than the length of S. The final content of the CRC register is the output block B. That is, the circuit transforms the input block S into the output block B. 1.

2.2

Security Considerations

2.2.1 The One-Way Strength of the Transformation Surely, recovering S from a compressed version of the ciphers output keystream, even if the compression is based on a simple linear CRC, cannot have a lower complexity than the recovery of S from a fully given keystream. As the latter is expected to be infeasible for secure cipher, the irreversibility of the transformation of Fig. 2 is at least as strong as the underlying security of the cipher. 2.2.2 Randomness Features of the Output and the Purpose of the CRC Circuitry Basically, even if a short section of the output is stored, without entering a long keystream into a CRC circuitry, the one-way feature of the transformation is still kept. However, a relatively short string does not exhibit randomness properties and rather represents a limited event that may have a problematic pattern. Therefore, generating a relatively long keystream and entering it into a CRC circuitry, which preserves the randomness of its input, is desired. 2.2.3 Balanced Mapping We treat the case where the mapping S !B is many-to-one. Let fSi g be a set of inputs that maps to the same destination B1 , while the set fSj g maps to B2 . The output string of a

ARAZI: MESSAGE AUTHENTICATION IN COMPUTATIONALLY CONSTRAINED ENVIRONMENTS

971

stream cipher exhibits randomness properties and strong dependence on each bit of the seed key S. A compressed version of the output string which still keeps the randomness of the full string (e.g., CRC circuitry) is expected to provide the same output features. The transformation is therefore expected to be balanced, in the sense that fSi g and fSj g are expected to have a similar cardinality.

2.2.4 Resistance to Correlation Attacks One of the devastating attacks on stream ciphers, under which many were proved to be vulnerable, is based on establishing the validity of a partial guess of the secret key by correlating the outcome of the guess with a given output string of the cipher. Such an attack needs an output string whose length is considerably higher than the guessed value. In this respect, compressing the output string of the cipher into a block which is not longer than the parameterizing key leaves an external output too short for correlation analysis. 2.2.5 Collision Attacks in Challenge-Response Scenario A one-way many-to-one mapping is expected to also resist a collision attack. That is, it should be difficult to provide two different S that are mapped to the same B. It is essential to notice that in a challenge-response application, which is the ultimate aim of this paper, collision is not an issue [31], [21]. This observation is made clear when observing Fig. 1. The input K to the MAC in the interrogated component is known only to a valid party. A cheating party has to come up with a correct MAC output CR, not knowing K and unable to predict the specific random challenge C sent from the interrogator. An ability to perform here a collision attack is therefore irrelevant. (It is noted that the random input C to the MAC at the interrogated component, which facilitates the mitigation of a collision attack, is generated at the interrogator. The component therefore does not need random number generator circuitry, keeping the theme of low-cost implementation.) The above consideration has another fundamental aspect, relevant to the compact implementations proposed in this paper. As a cheater has no benefit from a successful collision attack, the application is of complexity On rather p than O n (characterizing the fact that birthday attacks are irrelevant here). As seen later, it is proposed to treat values which are about 100 bits, a rather safe size. 2.2.6 Related-Key Attacks A related-key attack is based on the assumption that an attacker observes the operation of a cipher under different keys, where some relationship among the keys is known to him. It is essential that the same key never be used more than once in a stream cipher. The best would be to use a randomly generated key for each new use of the cipher. (Two randomly generated keys can statistically be similar, but there is no algorithm associating the two. That is, a related-key attack does not concern the case of two slightly different keys whose similarity cannot be modeled.) Related-key attacks on stream ciphers concern key scheduling. This relates to applications where practical circumstances dictate the use a fixed key master key, which is randomized in a key-scheduling process, to yield a different key for each communication session. The mere existence of the key-scheduling process

Fig. 3. Processing the input in parts and where H is based on stream ciphering.

opens a possibility for related-key attack (i.e., the session keys are related). This is well clarified by the attack on Wired Equivalent Privacy (WEP) which uses the stream cipher RC4 to protect WiFi wireless networks [32]. The stream cipher implementation proposed in this paper, as depicted in Fig. 2, concerns the inability to recover the parameterizing key out of the generated keystream. This security is associated with the fundamental requirement that a stream cipher must satisfy, whereby a key generated by an isolated event (no relation to other keys) cannot be recovered from the generated keystream. It should further be emphasized that a fundamental feature of a stream cipher requires that two slightly different parameterizing keys yield keystreams having a major, unrelated, difference. It should further be noted that for the implementation treated in this paper, whereby the stream cipher acts as hash, a related-key attack on the cipher is associated with collision attack on the hash. Yet, as discussed before, collision attack is irrelevant in the cases where the hash is used in a challenge response implementation.

ITERATIONS OF THE ONE-WAY BLOCK TRANSFORMATION

3.1 Implementing an HMAC General hashing means transforming chained input blocks into an output block of a fixed, relatively small, length. This is performed by iterations, where input blocks enter one at a time and are combined with an accumulated value that consists of the hashing performed so far. When the iterations are complete (i.e., the entire input chain has been processed) the output should be the hash of the entire input. Such a procedure can follow the guidelines presented in [33]. An approach for iterating a one-way block transformation, based on stream ciphering, is depicted in Fig. 3. Here, the Linear Feedback Shift Register (LFSR) that processes the ciphers parameterizing key consists of two parts, of lengths t and r. Like a usual execution of a longinput hash transformation, the process consists of consecutive iterations. The number of iterations is the number of t-bit blocks of which the input data consists. (Possible padding may take place, to make the length of the input data a multiple of t.) The procedure starts when a predetermined initializing value IV , which is a system parameter, forms the r rightmost

972

IEEE TRANSACTIONS ON MOBILE COMPUTING,

VOL. 8,

NO. 7, JULY 2009

Fig. 5. Initializing the LFSR.

Fig. 4. DECIM (v2).

bits of the LFSR. These are concatenated with t bits of the input data. The formed r t bits play the role of the input block S of Fig. 2, generating an output block B of r bits. The block B now forms the r rightmost bits of the LFSR for the next iteration, concatenated with the next t bits of the input data, etc. When the process terminates, that is, the t-bit input blocks are exhausted, the output block B is the final output of the hash. Such a procedure, whereby B is updated in each iteration based on the preceding value of B and a new t-bit data block, starting with an initializing predetermined seed, is standard [6]. Being able to perform a hashing H on chained input blocks, an HMAC is implemented as HMAC text; K HKout kHKin ktext.

between the keys Kin and Kout in the HMAC implementation: HMAC text; K HKout kHKin ktext. In the standard, these keys are related by: Kout K opad and Kin K ipad. It is shown that this HMAC resists a related-key attack if generally the underlying compression function is a Pseudorandom Function (PRF). It is shown that under this condition, the HMAC is also a PRF. When generating HKout kHKin ktext, the output of the last iteration when generating HKin ktext, is strongly dependent on Kin (i.e., similar Kin yield totally different outputs). The same goes when hashing the concatenation Kout kHKin ktext. This strong dependence on Kin and Kout , which forms the foundations for the security of an HMAC, also has related-key aspects.

A CASE STUDY

3.2

Security Considerations and Requested Features of the Stream Cipher

3.2.1 Considerations per Iteration Each iteration in the described process performs a one-way block transformation on a r t-bits block. All security considerations presented in Section 2.2 apply to each individual iteration of the HMAC. This applies to the irreversibility of the transformation; the strong dependence on each input bit; randomness of the output; balanced mapping; correlation attack; and collision attack. 3.2.2 Considering the Transition from a Single-Block Transformation to Sequential Processing The transition from the structure depicted in Fig. 2 to that of Fig. 3 has its own security implications. Even if the stream cipher facilitates a strong one-way block transformation, the cipher should also provide for secured iterative implementation. In this respect, there is a need for an available wellanalyzed stream cipher which is based on having an initializing nonsecret value being a part of the parameterizing key. One of the eSTREAM candidates, which has this property, is treated in detail in Section 4. 3.2.3 HMAC Related-Key Attack Related-key attack pertaining to stream ciphering considerations have been treated in Section 2.2. HMAC aspects of such an attack are addressed in [34]. A related-key attack potentially concerns here the danger posed by a relation

4.1 DECIM (v2) and its HMAC Configuration DECIM (v2) was developed by a team of 13 researches from various industrial and academic French institutes [35]. Besides its established and highly scrutinized security, DECIM (v2) was selected in this paper as a case study for two purposes. First, it implements a principle whereby the key consists of a secret part and an initializing public value. This suits very well the hashing procedure of Section 3.1 and the security consideration raised in Section 3.2.2. Second, the size of its parameters suits the practical applications intended to be served by the HMAC proposed in this paper. DECIM (v2) is depicted in Fig. 4. The top register is a 192-bit LFSR. The transformation f is a Boolean function of 13 inputs. ABSG is a simple 1-bit input 1-bit output procedure. The LFSR is initialized with an 80-bit secret key K and a 64-bit public value IV . The rest of the 192 bits are a function (XOR operations) of the 144 bits of K and IV . After forming this initial content, the circuit is clocked 4 192 768 times under the configuration of Fig. 5. After these 768 shifts, the circuit of Fig. 4 starts generating its keystream. The circuit of Fig. 6 implements the hash transformation of Fig. 3 based on DECIM (v2). In the first iteration, the initial left 80 bits of the LFSR consist of the first 80 bits of the message to be hashed. The next 64 bits consist of a predetermined initializing value IV . The rest of the bits of the LFSR are formed according to DECIM specifications. After 768 shifts under the configuration of Fig. 5, the circuit is configured according to Fig. 6, and clocked for a prescribed number of times, yielding a 64-bit content of the CRC register. It is suggested that the ABSG should

ARAZI: MESSAGE AUTHENTICATION IN COMPUTATIONALLY CONSTRAINED ENVIRONMENTS

973

has to be hashed, yielding the HMAC. The latter hash is performed by padding W with two bytes (suggested possibility, two opad bytes), yielding a 160-bit value that is hashed by two iterations of the process of Section 3.1.

4.4 Hardware Resources Berbain et al. [35] include an accurate hardware evaluation. The 192 flip-flops of the LFSR and the XOR gates require 2,339 gates. The implementation of f and ABSG respectively requires 87 and 67 gates. The implementation of the circuit of Fig. 6 further requires a 64-bit CRC. If a 192-bit LFSR requires 2,339 gates, then a 64-bit CRC requires 780 gates. Altogether, the circuit of Fig. 6 requires about 3,300 gates.

5
Fig. 6. Configuring DECIM (v2) as an HMAC.

CONCLUSION

generate at least 768 keystream bits. The rationale is that the randomization performed in Fig. 5, and the randomization of the keystream that enters the CRC, are characterized by similar demands. The content of the CRC register now forms the new IV , used in the next iteration, where the left 80 bits of the LFSR are a new section of the input data, etc. After all the input data are shifted in, the final content of the CRC register is the HMAC output.

4.2 Security Considerations This implementation was selected for the purpose of satisfying the specification of Section 3.2.2. That is, it provides for a transition from the one-way transformation of Fig. 2 to the iteration procedure depicted in Fig. 3 without changing the analyzed and scrutinized infrastructure of the cipher. In particular it is noted that the existence of the initializing value IV , and the strong dependence of the keystream on this value, is a part of the definition of the cipher. DECIM (v2) Implementation in RFID Environment In a practical RFID scenario, the message M is an Electronic Product Code (EPC) currently specified to consist of 96 bits [?]. Concerning the sizes of the other values treated in Fig. 1, the challenge C and the challenge response CR are proposed to consist of 64 bits, where Kin and Kout are 80 bits. As described before, there is a possibility of having a single 80-bit K, yielding Kout K opad and Kin K ipad, where opad and ipad, respectively, consist of 10 repetitions of 01011100 and 00110110. We propose that text in the expression HMAC text; K HKout kHKin ktext will consist of the concatenation CkM. It is noted that DECIM (v2) processes an 80-bit key and a 64-bit initial value IV . These two values, respectively, suit the values t and r of the hash implementation of Section 3.1. That is, the hash processes 80 bits per iteration. Kin ktext is a 240-bit value. (text consists of a concatenation of C and M, which are, respectively, 64 and 96 bits. Kin is 80 bits.) It is hashed into a 64-bit value V by three iterations of the process of Section 3.1. V is now concatenated with Kout , giving a 144-bit value W that 4.3

RFID and Wireless Sensor Networks pose a need for efficient implementation of MAC. To achieve efficiency, while not sacrificing security, there is a need to evaluate new approaches, while also utilizing any characteristic of the specific implementation of MAC that can enhance efficiency. A complete highly compact MAC implementation, based on stream ciphering, was presented. The principle was to implement a hash transformation based on the stream cipher, where the strength of the hash is associated with the underlying security of the cipher. The hash is then utilized to implement HMAC, based on standard procedures. A specific implementation, based on DECIM (v2), a highly scrutinized stream cipher, was presented and analyzed in detail.

REFERENCES
[1] [2] [3] [4] [5] M. Bellare, R. Canetti, and H. Krawczyk, Keying Hash Functions for Message Authentication, Proc. Ann. Intl Cryptology Conf. (CRYPTO 96), pp. 1-15, 1996. H. Krawczyk, M. Bellare, and R. Canetti, HMAC: Keyed-Hashing for Message Authentication, IETF RFC 2104, 1997. ANS Institution, Keyed Hash Message Authentication Code, ANSI X9.71, 2000. National Institute of Standards and Technology, The KeyedHash Message Authentication Code (HMAC), FIPS PUB 198, Information Technology Laboratory, 2002. J. Kim, A. Biryukov, B. Preneel, and S. Hong, On the Security of HMAC and NMAC Based on HAVALl, MD4, MD5, SHA-0 and SHA-1, Proc. Conf. Security and Cryptography for Networks (SCN 06), pp. 242-256, 2006. National Institute of Standards and Technology, Secure Hash Standard, FIPS PUB 180-1, Information Technology Laboratory, 1995. GAO, GAO-05-551 Radio Frequency Identification Technology, www.gao.gov/new.items/d05551.pdf, May 2005. European Commission, Draft Recommendation on RFID Privacy and Security, http://www.edri.org/edrigram/number6.4/ecrecommandation-rfid, Feb. 2008. G. Avoine, RFID Security & Privacy Lounge, www.avoine.net/ rfid/, 2009. P. Siekerman and M. van der Schee, Security Evaluation of the Disposable OV-chipkaart v1.7, System and Network Eng. Dept., Univ. of Amsterdam, Apr. 2008. PCWorld, E-Passports Can be Cloned in Minutes, Claims Researcher, pcworld.about.com/od/dataprotection/E-PassportsCan-Be-Cloned-in-M.htm, Aug. 2008. K.J. Higgins, RFID under Attack Again, www.darkreading.com, Apr. 2007. Drugresearcher, Breaking News on Drug DiscoveryRFID Can Prevent Drug Deaths,www.drugresearcher.com/Researchmanagement/RFID-can-prevent-drug-deaths, Aug. 2004.

[6] [7] [8] [9] [10] [11] [12] [13]

974

IEEE TRANSACTIONS ON MOBILE COMPUTING,

VOL. 8,

NO. 7, JULY 2009

[14] J. Antokol, RFID and Healthcare: Privacy and Security Considerations, http://www.rfidconsultation.eu/docs/ficheiros/ antokol.pdf, May 2006. [15] S. Sarma, S. Weis, and D. Engels, RFID Systems and Security and Privacy Implications. Cryptographic Hardware and Embedded Systems, Proc. Workshop Cryptographic Hardware and Embedded Systems (CHES 02), vol. 2523, pp. 454-469, 2002. [16] M. Ohkubo, K. Suzuki, and S. Kinoshita, Cryptographic Approach to Privacy-Friendly Tags, Proc. RFID Privacy Workshop, Nov. 2003. [17] I. Vajda and L. Buttyan, Lightweight Authentication Protocols for Low-Cost RFID Tags, Proc. Second Workshop Security Ubiquitous Computing (Ubicomp 03), Oct. 2003. [18] G. Avoine and P. Oechslin, A Scalable and Provably Secure Hash-Based RFID Protocol, Proc. Second IEEE Intl Workshop Pervasive Computing and Comm. Security (PerSec 05), pp. 110-114, 2005. [19] K. Rhee, J. Kwak, S. Kim, and D. Won, Challenge-Response Based RFID Authentication Protocol for Distributed Database Environment, Proc. Intl Conf. Security in Pervasive Computing (SPC 05), Apr. 2005. [20] M. Feldhofer and C. Rechberge, A Case against Currently Used Hash Functions in RFID Protocols, RFID Security Workshop (RFIDSec 06), printed handout, July 2006. [21] A. Bogdanov, G. Leander, C. Paar, A. Poschmann, M. Robshaw, and Y. Seurin, Hash Functions and RFID Tags: Mind the Gap, Proc. Workshop Cryptographic Hardware and Embedded Systems (CHES 08), 2008. [22] S. Bono, M. Green, A. Stubblefield, A. Juels, A. Rubin, and M. Szydlo, Security Analysis of a Cryptographically Enabled RFID Device, Proc. USENIX Security Symp., pp. 1-16, 2005. [23] ECRYPT, The Estream Project, The eSTREAM Portfolio, revision 1, Sept. 2008. [24] H. Krawczyk, LFSR-Based Hashing and Authentication, Proc. Ann. Intl Cryptology Conf. (CRYPTO 94), pp. 129-139, 1994. [25] B. Zoltak, VMPC-MAC: A Stream Cipher Based Authenticated Encryption Scheme, Cryptology ePrint Archive, Report 2004/ 301, 2004. [26] D. Whiting, B. Schneier, S. Lucks, and F. Muller, PhelixFast Encryption and Authentication in a Single Cryptographic Primitive, Ecrypt Stream Cipher Project, Report 2005/020, 2005. [27] K. Wirt, ASC a Stream Cipher with Built in MAC Functionality, Intl J. Computer Science, vol. 2, pp. 131-136, 2007. [28] P. Hawkes, M. Paddon, and G.G. Rose, The Mundja Streaming MAC, Cryptology ePrint Archive, Report 2004/271, 2004. [29] J. Kaps, K. Yuksel, and B. Sunar, Energy Scalable Universal Hashing, IEEE Trans. Computers, vol. 54, pp. 1484-1495, 2005. [30] J. Black, S. Halevi, H. Krawczyk, T. Krovetz, and P. Rogaway, UMAC: Fast and Secure Message Authentication, Proc. Ann. Intl Cryptology Conf. (CRYPTO 99), pp. 216-233, 1999. [31] B. Schneier, Schneier on SecuritySHA-1 Has Been Broken, http://www.schneier.com/blog/archives/2005/02/, 2009. [32] S. Fluhrer, I. Mantin, and A. Shamir, Weaknesses in the Key Scheduling Algorithm of RC4, Proc. Ann. Intl Cryptology Conf. (CRYPTO 01), pp. 1-24, 2001. [33] O. Dunkelman and E. Biham, A Framework for Iterative Hash FunctionsHAIFA, Proc. Second Cryptographic Hash Workshop, Aug. 2006. [34] M. Bellare, New Proofs for NMAC and HMAC: Security without Collision-Resistance, Proc. Ann. Intl Cryptology Conf. (CRYPTO 06), pp. 602-619, 2006. [35] C. Berbain, O. Billet, A. Canteaut, N. Courtois, B. Debraize, H. Gilbert, L. Goubin, A. Gouget, L. Granboulan, C. Lauradoux, M. Minier, T. Pornin, H. Sibert, and C. Berbain, Ecrypt Phase 3 DECIM 2 2007, http://www.ecrypt.eu.org/stream/decimp3.html, 2009.

Benjamin Arazi is a professor in the Department of Electrical and Computer Engineering at Ben-Gurion University, Israel, and a former chairman of this department. He has been involved in information assurance research and education for the past 25 years. He is the author of an MIT Press book on coding theory. His current interests include certification protocols, wireless sensor networks security, critical infrastructures, and food supply chain security. He developed a computer arithmetic algorithm, named after him, that serves as standard practice in the smartcard industry and developed a cryptographic arithmetic algorithm that appears in Knuths The Art of Computer Programming. He is also an IEEE Distinguished Lecturer and a senior member of IEEE.

. For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib.