View page as slide show

Introduction to lightweight security protocols

Pekka Jäppinen, Lappeenranta University of Technology

Lightweight security protocol

  • Lightweight does not imply that solution is in anyway less secure than heavyweight solution
  • Lightweight solution is designed by keeping in mind the restrictions of small devices…
    • Computational power, memory, storage space, Available Energy
  • … while maintaining adequate performance
  • There is no official definition when solution can be called as lightweight
    • Everyone has their own perspective on lightweight
    • Context dependent
      • What might be light in software is not necessarily light on hardware

Need for lightweight solutions

  • Ubiquitous Computing
    • Computing and communication capabilities are implemented in ever smaller and less powerful devices.
  • Traditional crypto requirements are too high for simple systems
    • Sensor networks, RFID tags.
    • Martin Feldhofer, Christian Rechberger: A case against currently used Hash functions in RFID protocols
  • Privacy and security concerns are affecting on acceptance of new technologies

What has been done

  • Lightweight crypto is closely tied to RFID security
    • RFID tag is currently the weakest computational apparatus that is commonly used and requires security.
  • Lot of solutions have been proposed
    • Ari Juels: RFID Security and Privacy: A research Survey
    • Selwyn Piramuthu: Protocols for RFID tag/reader authentication
    • Gildas Avoine RFID security and privacy lounge at contains list of research papers around RFID security and privacy
  • The actual weight of solution are hardly ever evaluated or compared to other solutions

Measuring the weight

  • There are no set definitions for measuring the weight of solution
  • On security protocols there is hardly ever any metrics backing up the claim for lightweightness
    • Protocol developers rarely think about hardware and they lack the knowledge on what should be measured
    • Big differences in actual weight between different “lightweight” solutions
  • Cryptoalgorithm developers usually provide some metrics describing the weight of their solution
    • Crypto people work close to hardware
    • hardware efficiency is commonly used in comparison of algorithms

Suggested metrics of measuring and comparing the weight

  • Algorithms: Martin Feldhofer, Johannes Wolkerstorfer: Strong Crypto for RFID Tags - A Comparison of Low-Power Hardware Implementations
    • Chip area
    • Clock cycles
    • Power consumption
  • Protocols: Denis Trcek, Damjan Kovac: Formal Apparatus for measurement of lightweight protocols
    • Chip area

Measurement: chip area

  • Required chip area can be estimated in terms of required logical (NAND) gates
  • The more gates are needed the more expensive the solution will be.
  • More gates requires more power
  • For RFID tag available chip area for security features can be assumed between 1000 and 10000 gates (feldhofer and wolkerstorfer)
    • Simpler the tag higher the proportional cost from security
    • EPC tag has ~10000 Gates from which ~2000 could be reserved for security (Juels and Weis)

chip area for protocols

  • Memory gates
    • gates needed for storing data like pseudonyms, challenges, random numbers, history data, middle results like chaining vectors etc.
  • Processing gates
    • gates needed for algorithms, random number generation, mathematical functions etc.
  • Communication gates
    • mainly buffers

Some Chip area cost estimations

Hash functions SHA-256: 10868 SHA-1: 8120
Asymmetric Encryption ECC-192: 23600 WIPR: 5705
Symmetric Encryption AES-128: 3400 DESL: 1848
XOR function 4 G
Storage 5-8 G / bit (temporary and long term storage)


  • RFID tag has to respond to the reader within certain time
  • Slowness in response easily accumulates if there are hundreds or thousands of small devices to communicate with
  • The speed of implementation is dependent on the clock speed of the platform it is run.
    • Performance of algorithm can be measured by estimating the amount of clock cycles needed.


  • Communication time should be taken also into accoun
    • Most cases the communication time is same on different solutions
    • Probabilistic authentication (HB+, HB++ etc.) can be very slow although it requires very little computational power
      • computational complexity has been moved to communication complexity.
      • latency slows down the system
  • performance vs security
    • In probabilistic authentication the more rounds you have the longer the authentication takes but more sure you can be on the authenticity
      • 1 challenge 50%, 2 challenges 75%, 3 challenges 87.5% …

Parallel vs serial implementation

  • Parallel is faster than serial
    • more operations / clock cycle
  • Parallel solution requires more gates
    • Gates are not reused
    • Serial solution requires counter
  • Parallel requires more energy / clock cycle, serial requires more total energy
    • tags that get power from reader has limit on energy/ clock cycle
    • battery powered tags prefer small total amount of energy to keep long battery life

Asymmetric weight

  • Communicating devices may have different computational capabilities
    • mobile phone - desktop computer
    • RFID tag - RFID system backend server
  • Put the more powerful device do all the hard calculations
    • In RSA you can select encryption power so that encryption is simple, while decryption will require more computational time
    • Use of random small seed on weak device


  • Lightweight solutions are needed when we surround ourselves with more computing devices
  • Solution is not lightweight just if the developer says so.
    • So far there are no lightweight hash functions (that I know of).
    • It is possible to estimate the basic weight parameters of the protocol without doctorate degree in digital electronics.
  • Used platform and type of use affects what would be optimal solution
    • parallel vs. serial
  • When one device has more power than the other, take advantage of that.
Last modified: 2013/07/01 14:42