Hardware Design and Analysis of HB Type Lightweight ... · Electronic Product Code Class 1...

Hardware Design and Analysis of HBType Lightweight AuthenticationProtocols for Pervasive Devices

Dennis A. N. Gookyi1,and Kwangki Ryoo*2,

Department of Information and Communication EngineeringHanbat National University, Daejeon

34158,South Korea

[email protected],[email protected]

Corresponding author*

Phone: +82-10-5234-0569

February 4, 2018

AbstractBackground/Objectives: In this paper, we provide

the hardware design of four earlier lightweight authentica-tion protocols categorized as Hopper-Blum (HB) and Hopper-Blum-Munilla-Peinado (HB-MP) type protocols: HB, HB+,HB-MP, and HB-MP+.

Methods/Statistical analysis: Linear feedback shiftregisters were employed to generate random numbers andbits.Two dot product units: Block (using XOR and ANDgates) and serialized (one XOR, one AND gate) are designedto provide atradeoff between area and latency.One roundone-way function is designed to generate round keys for HB-MP+ protocol.The protocols were designed using VerilogHDL, simulated with Modelsim SE and synthesized withXilinx Design Suite 14.3.

Findings: Though the securities of HB authenticationprotocols are well established, the real world hardware im-plementations have been neglected. With no hardware im-plementation results for HB type authentication protocols,

1

International Journal of Pure and Applied MathematicsVolume 118 No. 19 2018, 1927-1946ISSN: 1311-8080 (printed version); ISSN: 1314-3395 (on-line version)url: http://www.ijpam.euSpecial Issue ijpam.eu

1927

it is difficult to ascertain their suitability for constrained de-vices like the RFID tag. We, therefore, propose, design, andimplement hardware architectures for the protocols. Theprotocols are analyzed by comparing their hardware area,total cycles and the total number of bits used for authenti-cation.We synthesizedusing four Field Programmable gatearray (FPGA) families and simulated the architectures toinvestigate their feasibility in the real world. From our hard-ware and simulation results, the protocols consume veryminimal hardware area but require a lot of time for authen-tication.The implication of results is that the HB authenti-cation protocols could be implemented on very constraineddevices but at the cost of anincrease in latency.This researchcould be a starting point of future HB type lightweight au-thentication hardware architectures.

Improvements/Applications: In the future, we willbe investigating techniques to reduce the authentication timeand also implementing a unified architecture of the proto-cols in a System-on-Chip (SoC) application.

Key Words: Lightweight Authentication, HB proto-col, Pervasive Device, RFID, Hardware Architecture

1 Introduction

In this era of connected devices, basic everyday devices are givencomputing capabilities. These devices termed pervasive devices in apervasive computing environment are given capabilities that enablethem to perform useful and sensitive tasks and functions saving theerror prone human time. One technology that has grown rapidlyin this era of connected devices is the Radio Frequency Identifica-tion (RFID) technology. The RFID system is simply the wirelesscommunication between a tag and a reader. The reader generallyqueries the tag attached to a host for some information about thehost. As of any other communication protocol, the RFID tech-nology has some security concerns. As the communication used iswireless, some of the concerns include Confidentiality, Integrity, Au-thentication, Non-repudiation, and Availability1. RFID tags gen-erally consist of an antenna and Integrated Circuit (IC). The ICsconsist of some logic gates and memory. For the mass deploy-ment of RFID technology in pervasive computing, it is important

2

International Journal of Pure and Applied Mathematics Special Issue

1928

to choose tags that will alleviate the cost of implementation. TheElectronic Product Code Class 1 Generation 2 (EPC C1G2) pas-sive tags are a perfect fit for mass deployment. The ICs of thesetags has about 1000 10000 gates out of which only about 2002000 is dedicated to security components2. With these constraints,Bogdanovet al3, Paulo et al4 and Ryoo et al5 proposed and im-plemented lightweight encryption algorithms that could curb theConfidentiality and Integrity concerns. The solution to the authen-tication issue has been grouped into four categories based on thecryptographic functions used on the tag side by Cheinet al6. Table1 illustrates the categories. This paper focuses on the lightweightauthentication class of protocols. The protocols in this class can beimplemented with pseudorandom number generators and cyclic re-dundancy check. The earliest form of a lightweight authenticationprotocol was proposed by Hopper and Blum which will go on tobe known as the HB7 authentication protocol. The first proposalwas designed to be used by a human without any computing aidand therefore was very simple. This protocol has been scrutinizedwith regards to its security and several other protocols have beendesigned and therefore all later versions have been termed HB typeauthentication protocols. Though the securities of these protocolsare well established, the real world hardware implementations havebeen neglected. With no hardware implementation results for HBtype authentication protocols, it is difficult to ascertain their suit-ability for constrained devices like the RFID tag. In this paper, wepropose, design, and implement hardware architectures for HB7,HB+8, HB-MP9 and HB-MP+10 protocols. The protocols are ana-lyzed by comparing their hardware area, total cycles and the totalnumber of bits used for authentication. The rest of this paper is or-ganized as follows: Section 2 describes the HB type protocols flow,Section 3 describes the hardware implementation of the of the pro-tocols, Section 4 shows the simulation and synthesis results of thehardware structures and the conclusion and future work is coveredin Section 5.

TABLE 1.Class of Authentication Algorithms

3


1929

2 HB Type Lightweight Authentication

Protocols

The HB type protocols provide authentication for pervasive deviceswithout the use of complex mathematical operators. The security ofthe protocol is dependent on the learning parity with noise (LPN)problem11 given probability (η ) and noise bit (v) such that theη[ν= 1] ∈{0, 0.5}. Here, we describe the flow of each protocol.

2.1 HB Authentication Protocol

The HB authentication protocol was proposed to be as simple aspossible because it involved human authentication without comput-ing devices. Figure 1 illustrates the authentication flow between thetag and the reader. Both the reader and the tag share a k bit se-cret key x. the reader starts by generating a random number aiand sending it to the tag. The tag computes zi and sends it to thereader. This goes on for n rounds after which the reader acceptsthe tag if cnt = nη.

Fig. 1. HB Authentication Protocol Flow

4


1930

2.2 HB+ Authentication Protocol

The HB+ authentication protocol is a variant of the HB protocolthat was developed by Juels and Wess in 2005. It is also an im-provement over the HB authentication protocol because it is statedto be resistant to active attacks. Both reader and tag share twok bit secret keys x and y. The algorithm for the protocol is givenin Figure 2 where it is repeated for n rounds. The reader and tagstart by exchanging random numbers bi and ai respectively.

Fig. 2. HB+ Authentication Protocol Flow

2.3 HB-MP Authentication Protocol

The HB-MP authentication protocol is a variant of the HB+ pro-tocol that was developed by Munilla and Peinado in 2007. It is alsoan improvement over the HB+ authentication protocol because it isstated to be resistant to both active attacks and man-in-the-middleattacks. Both reader and tag share two k bit secret keys x andy. The algorithm for the protocol is given in Figure 3 where itis repeated for n rounds. The reader generates and sends randomnumber ai to the tag. Each round generates a round key by rotatingkey x by the bits in key y.

5


1931

Fig. 3. HB-MP Authentication Protocol Flow

2.4 HB-MP+ Authentication Protocol

The HB-MP+ authentication protocol is a variant of the HB pro-tocol that was developed by Leng et al in 2008. It is an enhancedversion of the HB-MP protocol that eliminates several vulnerabil-ities and keeps the simplicity of the original HB protocol. Bothreader and tag share ak bit secret keyx. The algorithm for the pro-tocol is given in Figure 4 where it is repeated for n rounds. Fromthe Figure, the round key is the unit that generates the round keysfor each round of authentication.

Fig. 4. HB-MP+ Authentication Protocol Flow

3 Proposed Hardware Architectures for

HB Protocols

As stated earlier the security of the HB type authentication proto-cols have received a lot of attention from researchers disregardingtheir feasible implementation in the real world. Here, we take aclose look at some of the constraints of EPC C1G2 tags and theirlimitations imposed on authentication protocols. These limitationsare summarized in Table 2.• Tag memory: According to the EPC C1G2 standard12, the

tag implements memory that is organized into four memory banks:reserved memory, EPC memory, TID memory and user memory.The reserved memory stores a 32-bit access password and a 32bit kill password. The EPC (Electronic Product Code) memory

6


1932

stores 96 bit of information about the attached host. The TID(Tag Identifier) memory stores an 8 bit ISO/IEC 15963 allocationclass identifier. The user memory allows for user data storage andit is user defined. For our implementation, we concatenate the 32-bit access password and the 32 bit kill password to form our 64-bitkey. The 96 bit EPC is also utilized.•Total authentication time: EPC C1G2 tags have an opera-

tional frequency of 100 KHz and the number of tags to authenti-cate per second is approximated at 200 tags. This, therefore, im-plies that the authentication time per tag is set to about 5,000,000ns. With this limitation, we set the number of rounds for each HBprotocol to 64 rounds.•Bandwidth: EPC C1G2 tag transmission bandwidth is set in

the range of 40 - 640 kbps. Taking the upper limit of 640 kbps (thiscould be unrealistic) and the total authentication time per tag of0.005s, we would limit the number of bits transferred between tagand reader to 3200 bits.•Area (in GE and slices): Out of about a 1000 - 10000 gate

equivalents (GE) used in the implementation of RFID tag circuitry,only about 200 - 2000 GEs are reserved for security purposes. Thisaccounts for no more than 20 percentage of the available hardwareresources. Considering that we are implementing our proposed ar-chitectures in FPGA, we need to translate this into slices. EachFPGA device has different counts of slices, therefore, using theIGLOO nano FPGAs13 (which consist of 100 - 3000 slices) as abenchmark, we propose that the upper and lower bound RFID cir-cuitry should be 100- 3000 slices out of which 20 - 600 slices (20percentage of the available hardware resources) should be reservedfor security purposes.

TABLE 2.EPC C1G2 Tag Limitations

7


1933

3.1 Hardware Implementation of HB Authen-tication Protocol

Three main components can be deduced from the HB protocol flowin Figure 1: A dot product unit, a random bit generator and a XORgate. The block diagram of the proposed hardware architecture ofHB authentication protocol is shown in Figure 5. From the blockdiagram we now describe the various components used on the tagside of the protocol:•Registers: From the block diagram, two main registers are used

for storing permanent and changing variables. The reader ran numregister is a 64-bit register that stores the random number fromthe reader. The key register is a 64-bit register that stores thepermanent secret shared key.•Random bit unit: A 4 bit Linear Feedback Shift Register

(LFSR) shown in Figure 6 is used to generate a 1-bit pseudo-randomnumber (PRN). The LFSR is designed using four D-type flip-flops.This unit takes 4 bits from the key register and rbu valid in fromthe control unit and produces a 1 bit PRN ran bit every round.•Dot product unit: The dot product unit is used to compute

the dot product of the key and the reader ran number. This unit isimplemented in two different ways giving a tradeoff between hard-ware area and throughput. The first implementation calculates thedot product using AND (&) and XOR(∧) gates in the computation:(key and reader ran num). This method leads to fast computationbut an increase in hardware area as seen in Figure 7. In the secondmethod, the inputs to the dot product unit are serialized by usingonly one AND gate, one XOR gate and a multiplexer as shown inFigure 8. This type of implementation leads to increase in the num-ber of clock cycles while the hardware area is significantly reduced.•Control unit: The control unit generates signals that acti-

vate the individual components in the block diagram. The unitgenerates a dot valid in signal to activate the dot product unit,rbu valid out signal to control the random bit unit and the tagvalid out signal to indicate an end of the operation.

8


1934

Fig. 5. Hardware Block Diagram of HB Protocol

Fig. 6. A 4-bit Linear Feedback Shift Register

Fig. 7. High Throughput Dot Product Unit

Fig. 8.Low Area Dot Product Unit

9


1935

3.2 Hardware Implementation of HB+ Authen-tication Protocol

From the HB+ authentication flow in Figure 2, four main compo-nents are needed for its implementation: a random number unit, adot product unit, a random bit unit and a XOR gate. The randombit unit is the same as the one used for HB authentication and thisis shown in Figure 6. The block diagram of the proposed hardwarearchitecture of HB+ authentication protocol is shown in Figure 9.From the block diagram we now describe the various componentsused on the tag side of the protocol:•Registers: From the block diagram, three main registers are

used for storing permanent and changing variables. The readerran num register is a 64-bit register that stores the random numberfrom the reader. The key1 and key2 registers are 64-bit registersthat store the permanent secret shared keys.•Dot product unit: The dot product unit is the same unit that

is used for HB authentication. HB+ authentication, however, re-quires the use of two dot product units to compute the dot productof ran num and key1 and also the dot product of reader ran numand key2 . To save hardware area, only one dot product unit is de-signed and two multiplexers are employed to select either ran numor reader ran num and key1 or key2 .•Random number unit: The EPC C1G2 standard states that

tags shall implement a 16 bit random or pseudorandom numbergenerator (RNG/PRNG). The RNG/PRNG should meet the fol-lowing requirements:

The probability that a 16-bit random number (RN16) from thePRNG/RNG unit has a value of j for any j, is always bounded by0.8/216 < P (RN16 = j) < 1.25/216.

Given a tag population of up to 10,000 tags, the probability thatany two or more tags generate the same sequence of RN16 shouldbe less than 0.1%

We choose to generate our random numbers using the linearfeedback shift register (LFSR) method. A 16 bit LFSR meets thefirst requirement of the EPC C1G2 standard because, given a 16-bit input, it produces a total of 216-1 unique numbers. Thereforethe probability that two numbers repeating is negligible.

Again implementing a 16 bit LFSR on tags with different keys

10


1936

as inputs to the LFSR fulfills the second requirement of the EPCC1C2 standard.

A 64-bit random number is generated by concatenating four 16bit LFSR. Figure 10 illustrates a 64 bit LFSR using four 16 bitLFSR. It takes 16 clock cycles to produce the first random number.AKARI114 is one the best known PRNG for constrained devices.It uses about 1980 gates for implementation. The downside tothis algorithm is that it uses about 66 clock cycles to generate onerandom number.•Control unit: The control unit is responsible for generating

control signals to control the individual components in the block di-agram. Signals such as dot valid in ,rbu valid in, and rnu valid inare generated to control the dot product unit, the random bit unitand the random number unit respectively.

Fig. 9. Hardware Block Diagram of HB+ Protocol

Fig. 10. A 64-bit Linear Feedback Shift Register

11


1937

3.3 Hardware Implementation of HB-MP Au-thentication Protocol

From Figure 3 which illustrates the HB-MP authentication flow, sixmain units are involved in the operation of the protocol: A randombit unit, a key generation unit, dot product unit, XOR gate, and acomparator unit. The dot product unit, random bit unit and therandom number unit are the same as the ones used in HB+ authen-tication. The block diagram of the proposed hardware architectureof HB-MP authentication protocol is shown in Figure 11. From theblock diagram we now describe the various components used on thetag side of the protocol:•Registers: From the block diagram, three main registers are

used for storing permanent and changing variables. The readerran number register is a 64-bit register that stores the random num-ber from the reader. The key1 and key2 registers are 64-bit registersthat store the permanent secret shared keys.•Key generation unit: Unlike HB and HB+, HB-MP authenti-

cation generates a new key for each round of authentication. Thisis achieved with a key generation unit. This unit takes as its inputskey1 and key2.key1 is then left rotated by the most significant bitof key2 as shown in Figure 12.•Comparator: The comparator unit inputs include xor out, dot

out2 and ran num[63:0]. The xor out is compared to the dot out2and if this comparison is true, the ran num[63:0] is assigned to thetag out else a new ran num has to be generated and the comparisonis done over and over again. To avoid the situation of generatingthe ran num over and over again, the results of several tests showthat just by flipping 1 bit of ran num make xor out equivalent todot out2. The circuit for generating the tag out is shown in Figure13.•Control unit: The control unit generates control signals that

include dot valid in , rbu valid in, rnu valid in and key valid in.These signals control components that include the dot product unit,random bit unit, random number unit and the key generation unitrespectively.

12


1938

Fig. 11. Hardware Block Diagram of HB-MP Protocol

Fig. 12. HB-MP Round Key Generation

Fig. 13. Output Generation

3.4 Hardware Implementation of HB-MP+ Au-thentication Protocol

The only difference between HB-MP and HB-MP+ is in the waythe round keys are generated for each round of authentication. Theblock diagram of the proposed hardware architecture of HB-MP+authentication protocol is shown in Figure. 14. The functional

13


1939

blocks which include dot product unit, comparator, random bitunit and random number unit are the same as the ones used forHB-MP protocol. The rest of the blocks are described as below:•Registers: From the block diagram, two main registers are used

for storing permanent and changing variables.Thereader ran numberregister is a 64-bit register that stores the random number from thereader. The key register is a 64-bit register that stores the perma-nent secret shared key.•Key generation unit: Unlike the HB-MP protocol which pro-

poses the use of simple rotation to generate the round keys foreach round of authentication, the developers of HB-MP+ did notspecifically propose any method for generating the round keys. Thecondition they gave was that the key generation algorithm shouldbe a one-way function. We, therefore, propose a very lightweightone round hash function for generating the round keys as shownin Figure 15. The input to this unit is the key and the reader rannum. From the figure:

A = reader ran num[31:0], B = key[31:0], C = reader ran num[63:32], D = key[63:0] and E = 32’h9E3779B7. The block Ft isgiven by Ft = (B & D) | (∼ B ∧ E) | B where &, | and ∼ indicatesAND, OR and NOT gates respectively. The round key functiongenerated this way serves as a one-way function.

Fig. 14. Hardware Block Diagram of HB-MP+ Protocol

14


1940

Fig. 15. Key Generation of HB-MP+ Protocol

4 Results and Discussions

The hardware architectures of the HB type authentication protocolswere designed using Verilog Hardware description language (HDL).The software used for synthesis purposes is the Xilinx ISE 14.3. Thedesign was synthesized with four FPGA families: Spartan 3E usingdevice XC3S500E, Spartan 6 using device XC6SLX100, Virtex 4using device XC4VLX80 and Virtex 7 using device XC7V2000T.The synthesis results for each device gave the number of slices usedand the number of Lookup Tables (LUTs) used and also calculatesthe maximum frequency (using the critical path). For the purposesof simulation which will be discussed in the next section, we usedModelsim SE simulator. The results of the synthesis are tabulatedin Table 3.

Table 3.Synthesized Results for HB Protocols

15


1941

4.1 Simulation of Proposed Hardware Designs

The hardware architecture of HB authentication protocol is simu-lated using ModelSim SE software. The rest of the protocols followthe same procedure. The detailed authentication flow between thereader and the tag is shown in Figure 16. From Figure 16, at thestart of the authentication protocol, the tag first reads the sharedsecret key from memory. The reader then generates a random num-ber and sends it to the tag. The tag generates a random bit andcomputes z tag and sends it to the reader. The reader computesz out and compares it to z tag and if it does not match, it incre-ments cnt else it maintains it. The tricky part at the reader side isthat it has to authenticate the tag based on the probability of noisebit been 1. Since it is difficult to generate pseudorandom bits witha fixed probability, we have to calculate the pseudorandom bit usedby the tag at the reader side. This is generated simply by: noise bit= z out ∧ z tag. If the noise bit is 1, noise cnt is incremented elseit is maintained. The key is then shifted and a new random num-ber is generated by the reader and given to the tag. This goes onfor 64 rounds and at the end, cnt is compared to noise cnt and ifthey match the tag is accepted else it is rejected. Summary of thesimulation is tabulated in Table 4.

16


1942

Fig. 16. Flow Chart of HB Protocol Simulation Module

Table 4.EPC C1G2 Tag Limitations

5 Conclusion

In this paper, we propose the hardware architectures for HB, HB+,HB-MP, and HB-MP+. These protocols are termed lightweightauthentication protocols and are to be implemented in RFID tagswhich are constrained in terms of hardware area, authenticationtime and bandwidth. We synthesized and simulated the architec-tures to investigate their feasibility in the real world. From our

17


1943

hardware and simulation results, the protocols consume very mini-mal hardware area but require a lot of time for authentication. Inthe future, we will be investigating techniques to reduce the au-thentication time and also implementing a unified architecture ofthe protocols in a System-on-Chip (SoC) application.

AcknowledgmentThis research was supported by the research fund of Hanbat

National University in 2017.

References

[1] RanasingheD, Engels D, Cole P,Low-cost RFID Systems: Con-fronting Security and Privacy.In Proceedings of Auto-ID LabsResearch Workshop, 2004.

[2] Armknect F, Hamann M, Mikhalev V, Lightweight Authen-tication Protocols on Ultra-constrained RFIDs Myths andFacts. LNCS, Springer-Heidelberg, 2014, 8651, pp.1-18.

[3] Bogdanov A, Paar C, Poschmann A, PRESENT: An Ultra-Lightweight Block Cipher. Cryptographic Hardware and Em-bedded Systems CHESS, LNCS, Springer-Verlag, 2007, 4727,pp.450-466.

[4] Paulo P, Richardo C, Compact CLEFIA Implementationon FPGAs. IEEEInternational Conference on Field Pro-grammable Logic and Applications, Chania, 2011, pp.512-517.

[5] Gookyi D A N, Park S Y, Ryoo K K, The Efficient Hard-ware Design of a New Lightweight Block Cipher. InternationalJournal of Control and Automation, 2017, 10(1),pp.431-440.

[6] Chein H Y, SASI: A New Ultra-Lightweight RFID Authenti-cation Protocol Providing Strong Authentication and StrongIntegrity. IEEE Transaction on Dependable and Secure Com-puting, 2007, 4(4), pp.337-340.

[7] Hopper N J, Blum M, Secure Human Identification Proto-cols. Advances in cryptology ASIACRYPT 2001, Springer,2001,pp.52-56.

18


1944

[8] Juels A, Weis S A, Authenticating Pervasive Devices with Hu-man Protocols. Advances in Cryptology Crypto 2005, LNCS,Springer-Berlin, 2005, 3621, pp.293-308.

[9] Munilla J, Peinado A, HB-MP: A Further Step in the HB-Family of Lightweight Authentication Protocols. ComputerNetworks, 2009, 51(9), pp.2262-2267.

[10] Leng X, Mayes K, Markantonakis K, HB-MP+ Protocol: AnImprovement on the HB-MP Protocol. In RFID, 2008 IEEEConference on, 2008, pp.118-124.

[11] Levieil E, Fouque P A, An Improved LPN Algorithm. In Secu-rity and Cryptography Networks, Springer, 2016, pp.348-359.

[12] EPCglobalInc, Class-1 Generation-2 UHD RFID Protocol forCommunication at 860 MHz to 960 MHz (Version 1.2.0). EPC-global, 2008,

[13] Microsemi, IGLOO Nano FPGA. Available viawww.microsemi.com, 2017.

[14] Martin H, Millan E S, Entrena L, Peris-Lopez P, Hernandez-Castro J C, AKARI-X: A Pseudorandom Number Generatorfor Secure Lightweight Systems. Proceedings in IEEE IOLTS,2011, pp.228-233.

[15] Ain Q U, Mujahid U, Najam-ul-Islam, Hardware Implementa-tion of Ultra-lightweight Cryptographic Protocols. IEEE Inter-national Conference on Computing, Communication and Secu-rity, 2015,pp.1-8.

19


1945

Hardware Design and Analysis of HB Type Lightweight ... · Electronic Product Code Class 1...

Documents

Transcript of Hardware Design and Analysis of HB Type Lightweight ... · Electronic Product Code Class 1...