Lightweight Cryptography (CY-802 (C)) - Unit 5 Short Notes

UNIT 5: LIGHTWEIGHT CRYPTOGRAPHY

I. FOUNDATIONS & MOTIVATION

Definition and Need for Lightweight Cryptography

Lightweight cryptography provides security for resource-constrained devices (IoT sensors, RFIDs, smart meters) where traditional cryptography (AES, RSA) is too costly.

• Key Constraints:

  • Power/Energy: Battery-operated, need ultra-low consumption.

  • Computational Throughput: Low clock speeds, limited instructions per cycle.

  • Memory: Tiny RAM (bytes) and ROM (hundreds of bytes).

  • Hardware Area: Minimal gate count for cheap, small chips.

Comparison with Traditional Cryptography

• Limitations of Standard Algorithms:

  • AES: 128-bit state, complex S-Box, larger footprint.

  • RSA/ECC: High computational cost, large key sizes.

  • SHA-2: Large internal state (256+ bits).

• Fundamental Trade-off: Security vs. Efficiency (speed, size, power). Lightweight designs sacrifice some security margin for drastic efficiency gains, but must maintain sufficient resistance to known attacks.

Basic Concepts

• "Operation" in Computation: Refers to a basic hardware logic gate (AND, OR, XOR) or a CPU instruction cycle. Cost is measured in gate equivalents (GE) or cycles per byte (cpb).

• Symmetric vs. Asymmetric in Lightweight Contexts:

  • Symmetric (Block/Stream Ciphers, Hashes): Dominant. Low cost, fast, suitable for encryption/authentication.

  • Asymmetric (PKI): Rarely used directly on constrained nodes due to high cost. Often offloaded to a gateway.

[!TIP] Exam Focus: Be ready to list at least two specific resource constraints (Power, Memory, Area, Speed) and explain why AES/RSA are unsuitable.

II. LIGHTWEIGHT BLOCK CIPHERS

Design Strategies and Philosophies

Goal: Minimize cost while maintaining security.

• Reduce Rounds: Fewer rounds than AES (10) → faster, smaller.

• Simplify Round Function: Use smaller S-Boxes (4-bit vs. 8-bit), simpler linear layer (bit permutation vs. MixColumns).

• Optimize Components: Design for hardware efficiency (bit-serial implementations) or software efficiency (byte-oriented, ARM-friendly).

• Key Schedule: Often simpler/weaker than AES to save ROM/power, but this is a potential attack surface.

Specific Lightweight Block Cipher Families

Core Components

• Substitution Box (S-Box):

  • Function: Provides confusion (non-linearity), hiding key-material relationship.

  • Lightweight Design: Small size (4-bit), low implementation cost (fewer gates/ROM), but must resist linear/differential attacks.

• Permutation/Diffusion Layer:

  • Function: Provides diffusion, spreads bit influence across the block.

  • Lightweight Strategy: Simple bit permutations (wiring) are extremely cheap in hardware vs. matrix multiplications (AES MixColumns).

Modes of Operation for Lightweight Ciphers

• Purpose: Extend block cipher to encrypt messages >1 block, provide confidentiality/integrity.

• Lightweight-Suitable Modes:

  • CTR (Counter): Parallelizable, random access. Good for constrained devices needing speed.

  • Authenticated Encryption Modes: OCB, CLOC/CLEW (designed for lightweight). Provide confidentiality + integrity in one pass, reducing overhead.

• Trade-offs: State size (nonce/counter memory), per-block overhead, need for unique nonces.

[!TIP] Common Pitfall: Don't confuse modes (how to use a block cipher) with the cipher itself. A mode like CTR uses the underlying block cipher (e.g., PRESENT) as a primitive.

III. KEY MANAGEMENT FOR LIGHTWEIGHT CRYPTOGRAPHY

Fundamentals of Key Management

Secure lifecycle: Generation → Distribution → Storage → Use → Rotation → Revocation.

• Specific Challenges in Constrained Devices:

  • Secure Storage: Minimal non-volatile memory; keys vulnerable if device is captured.

  • Energy Cost: Key establishment protocols (e.g., Diffie-Hellman) are computationally heavy.

  • Physical Vulnerability: Easy access for side-channel attacks (power analysis) and tampering.

Key Management Architectures

Integration with Standard Protocols

• Problem: Full TLS/IPSec too heavy (handshake, certificates).

• Strategies:

  • Cipher Suite Downgrading: Use lightweight cipher (e.g., PRESENT) within TLS record layer.

  • Session Resumption: Reuse established keys to avoid full handshake.

  • Gateway Offloading: Heavy PKI operations done by a capable gateway; constrained nodes use symmetric keys with it.

Group Key Management for IoT

• Requirements: Many-to-many communication, dynamic membership (join/leave), low overhead per device.

• Key Evaluation Considerations:

  1. Communication/Computation Overhead: Messages and operations per join/leave.

  2. Scalability: How overhead grows with group size N.

  3. Rekeying Efficiency: Cost to update group key upon membership change.

  4. Forward/Backward Secrecy: Compromised node shouldn't access past/future group keys.

  5. Resilience to Capture: Impact if one device is physically compromised.

• Symmetric Key Integration: Often use a group key (shared symmetric key) for broadcast encryption. This group key can be derived from individual pairwise keys (e.g., each device shares a key with the group controller) using a key derivation function (KDF).

[!TIP] Exam Answer Structure: For "key considerations," list them as bullet points (Scalability, Rekeying Cost, Secrecy, Resilience). For "symmetric integration," describe the controller-pairwise-group hierarchy.

IV. OTHER LIGHTWEIGHT CRYPTOGRAPHIC PRIMITIVES

Lightweight Cryptographic Hash Functions

• Purpose: Integrity (message authentication codes - MACs), key derivation, digital signatures (with PK).

• Design Strategies: Reduce internal state size (e.g., 256-bit → 128-bit), simpler round functions (e.g., SPONGENT, QUARK based on sponge construction).

• Real-World Application: RFID tag authentication (tag computes hash of ID+nonce), sensor network data integrity (tiny MAC).

Lightweight Stream Ciphers

• Design Principles: Small internal state (e.g., 64-128 bits), efficient state update (LFSR-like or NLFSR), non-linear output function.

• Vulnerability: Birthday Attack & State Collisions

  • If internal state is n bits, after about $$\displaystyle 2^{n/2} $$ output bits, state collisions become probable (birthday paradox).

  • Attacker observes keystream, finds two positions with same internal state → can recover state/keystream.

• Design Optimization for Resistance:

  1. Increase Internal State Size: Trade-off with memory/throughput.

  2. Use Non-Linear Filtering/Combination: Makes state evolution non-linear, harder to correlate.

  3. Proper Initialization: Ensure all states reachable from key/IV are strong (no weak keys).

[!TIP] Key Formula: Birthday bound for state collision is approximately $$\displaystyle 2^{n/2} $$ outputs for an n-bit state. This sets a lower bound on state size for security.

V. SECURITY, SCRUTINY & PRACTICAL CONSIDERATIONS

Role of Open Design and Public Cryptanalysis

• Importance: "Security by obscurity" fails. Long-term viability requires public scrutiny.

• Process: Proposal → Community Analysis (attacks, improvements) → Refinement → Standardization (e.g., NIST LWC Competition selecting algorithms like ASCON, GIMLI).

• Security Margins: Conservative designs have more rounds than the best known attack requires. Provides buffer against future cryptanalysis.

Threat Model for Tiny Devices

Threats differ due to physical accessibility:

1. Invasive Attacks: Probing, microprobing, fault injection (laser, voltage glitch) to extract keys or induce errors.

2. Non-Invasive Side-Channel Attacks:

   • Power Analysis (SPA/DPA): Monitor power consumption to correlate with secret operations.

   • Timing Attacks: Measure operation times.

   • EM Emissions: Capture radiated signals.

3. Limited Countermeasures: Constrained devices cannot afford heavy shielding or constant-time implementations easily.

Evaluating Suitability for IoT Applications

Holistic assessment beyond benchmarks:

• Algorithm Agility: Ability to swap primitives if one is broken.

• Resistance Profile: Security against cryptanalytic attacks and implementation attacks (side-channels).

• Standardization Status: NIST LWC finalists/standardized algorithms (e.g., ASCON) have higher trust.

• Implementation Quality: Availability of open-source, audited, constant-time implementations for target platform (HW/SW).

[!TIP] Exam Link: Questions on "open design" should mention NIST LWC competition as the modern standardization process. Questions on "threats" must distinguish logical attacks (cryptanalysis) from physical attacks (side-channel, fault).