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

UNIT 3: LIGHTWEIGHT CRYPTOGRAPHY

1.0 Foundational Challenges & Motivation for Lightweight Cryptography

Definition: Lightweight Cryptography focuses on designing cryptographic primitives (ciphers, hash functions) that provide adequate security while minimizing resource consumption (area, power, energy, memory, processing cycles) for resource-constrained devices.

Why Traditional Algorithms (AES, RSA, SHA-2) Are Often Unsuitable:

• High Computational Complexity: Operations (e.g., AES's SubBytes, RSA's modular exponentiation) require many CPU cycles or large hardware gates.

• Large Memory Footprint: Significant RAM for intermediate states and ROM for lookup tables (e.g., AES S-Box) or code.

• High Power/Energy Consumption: Unsuitable for battery-powered or energy-harvesting devices (e.g., RFID tags, sensor nodes).

• Hardware Area (Gate Count): Traditional designs are too large for ultra-low-cost integrated circuits.

Typical Application Domains:

• Internet of Things (IoT) devices (smart sensors, wearables)

• Radio-Frequency Identification (RFID) tags

• Wireless Sensor Networks (WSNs)

• Embedded systems (automotive, industrial control)

[!TIP] Exam Focus: Be prepared to list specific resource constraints (power, area, memory) and example device types (RFID, sensor node) when explaining motivation.

2.0 Lightweight Block Ciphers: Design and Examples

2.1 Core Design Strategies

2.2 Analysis of Specific Ciphers

A. PRESENT

• Structure: Substitution-Permutation Network (SPN).

• Parameters: 64-bit block size, 80-bit or 128-bit key.

• Design: Uses a single 4-bit S-Box (optimized for hardware) and a bit permutation layer. 31 rounds.

• Goal: Extremely low gate count (~1,000 GE for 80-bit key) for hardware implementation.

B. CLEFIA

• Structure: Feistel-like network with a double Feistel function (two parallel F-functions per round).

• Parameters: 128-bit block size, 128/192/256-bit keys.

• Design: Uses two different 8-bit S-Boxes and a 4x4 MDS matrix for diffusion. More conservative security margin than PRESENT.

• Goal: Good software performance on 8/16/32-bit microcontrollers while maintaining hardware efficiency.

C. DESL / DESXL

• Philosophy: Legacy-based adaptation of DES.

• Design: Reduces DES's 16 rounds to a much smaller number (e.g., 8 for DESL) and uses a smaller/larger key schedule. Aims for compatibility with existing DES hardware.

2.3 Substitution Boxes (S-Boxes) in Lightweight Ciphers

• Function: Provide non-linearity (confusion) to resist linear and differential cryptanalysis.

• Design Considerations:

  • Size: Often 4-bit (16 elements) to minimize memory (e.g., PRESENT) vs. AES's 8-bit (256 elements).

  • Security Criteria: Must satisfy properties like non-linearity, strict avalanche criterion (SAC), bit independence criterion (BIC).

  • Implementation Cost: Small S-Boxes are cheaper in hardware (fewer gates) and software (smaller lookup table).

2.4 Comparison with Traditional Ciphers (e.g., AES)

[!TIP] Common Pitfall: Do not say lightweight ciphers are less secure. They aim for sufficient security (e.g., 80-bit security) with drastically lower resources. Their round count may be higher to compensate for simpler components.

3.0 Modes of Operation for Lightweight Block Ciphers

Purpose: To securely encrypt/decrypt messages longer than one block and provide additional properties like confidentiality + integrity (AEAD).

Common Modes & Suitability:

• ECB (Electronic Codebook): Insecure for repeated data. Not recommended for any multi-block message.

• CBC (Cipher Block Chaining): Requires IV and sequential encryption. High memory overhead (needs full previous ciphertext block). Poor for parallelism.

• CTR (Counter): Highly suitable. Turns block cipher into stream cipher. Parallelizable (encryption/decryption). Only needs a nonce and counter. Low memory overhead. Primary choice for many lightweight applications.

• OFB/CFB: Turn block cipher into stream cipher. OFB can pre-compute keystream. CFB has error propagation. Less common in modern lightweight specs.

Lightweight-Specific/Optimized Modes:

• CTR with simple nonce management: Often used with a counter and a fixed nonce per session.

• Lightweight AEAD Modes: Modes like OCB, CCM, GCM are often too heavy. Research focuses on modes like ASCON (NIST LWC winner) which provides integrated AEAD with minimal overhead.

Trade-offs:

[!TIP] Exam Answer: When asked for a mode example, CTR is the safest answer for its parallelism and low memory. For authenticated encryption, mention ASCON or COLM as lightweight AEAD examples.

4.0 Key Management for Lightweight Cryptography

Core Challenge: Securely distributing, storing, and updating cryptographic keys on devices with limited secure storage, low computational power, and often no real-time clock (RTC).

4.2 Centralized vs. Distributed Architectures

4.3 Integration into Standard Protocols

• DTLS (Datagram TLS): TLS variant for UDP. Uses lightweight cipher suites (e.g., AES-CCM, but now moving to LWC). Handshake is heavy; often pre-shared keys (PSK) are used.

• CoAP (Constrained Application Protocol) Security: Typically uses PSK mode of DTLS or OSCORE (Object Security for Constrained RESTful Environments) which provides end-to-end security at the application layer, independent of underlying transport.

4.4 Group Key Management for IoT

Key Considerations for Protocol Selection:

1. Scalability: Must support thousands of nodes with minimal per-node state.

2. Re-keying Efficiency: Ability to efficiently change group key when a node joins/leaves (compromise) without re-keying all nodes ($O(1)$ or $O(\log n)$ cost ideal).

3. Resilience to Node Capture: Compromise of one node should not reveal the group key or keys of other groups (forward/backward secrecy).

4. Communication Overhead: Number of messages and size must be minimal.

5. Synchronization: Tolerance for clock drift if time-based.

Integrating Symmetric Key Management:

• Devices are pre-loaded with a unique individual key (shared with a central controller) and a group key.

• Join: Controller encrypts new group key with device's individual key and sends it.

• Leave/Re-key: Controller generates new group key, encrypts it with each remaining member's individual key (or a key tree), and broadcasts. Key tree (e.g., LKH - Logical Key Hierarchy) reduces overhead from $O(n)$ to $O(\log n)$.

4.5 Specific Challenges

• Secure Key Storage: Use of Physically Unclonable Functions (PUFs) or secure elements (costly). Often, keys are stored in plain flash if no secure hardware.

• Distribution: Pre-provisioning (factory-loaded keys) is most common. Public-key distribution is often too heavy.

• Update & Revocation: Extremely difficult without a reliable network or secure storage. Often requires physical access or a secure broadcast from a base station.

[!TIP] Exam Focus: For group key management, always mention LKH (Logical Key Hierarchy) as a standard technique to achieve $O(\log n)$ re-keying cost. Contrast centralized (KDC) vs. distributed (pairwise) clearly.

5.0 Lightweight Cryptographic Hash Functions

Purpose & Security Requirements:

• Purpose: Produce a fixed-size digest from arbitrary input. Used for integrity, digital signatures, MACs, key derivation.

• Requirements: Pre-image resistance, second pre-image resistance, collision resistance. For lightweight, also low area, low power, small memory.

Design Strategies:

1. Sponge Construction: (Used by Keccak/SHA-3, PHOTON, SPONGENT).

   • Absorbs input in chunks, then "squeezes" output.

   • Advantage: Flexible output length, internal state can be small.

   • Lightweight tweak: Reduce state size (e.g., PHOTON uses 100-256 bit state vs. SHA-3's 1600-bit).

2. Simplified Compression Function: Based on a lightweight block cipher or dedicated round function with fewer rounds.

Examples of Lightweight Hash Functions:

• PHOTON: Sponge-based. Uses a variant of the AES S-Box. Designed for very low area (e.g., 100-bit state for PHOTON-100).

• SPONGENT: Another sponge construction. Focus on minimal hardware footprint.

• QUARK: Family of lightweight hash functions and MACs based on the sponge paradigm, targeting RFID applications.

Real-World Applications:

• Message Authentication Codes (MACs): e.g., Lightweight MACs like GMAC (based on AES in GCM mode, but heavy) or SPONGENT-based MACs.

• Digital Signatures: Used with lightweight public-key schemes (e.g., ECC on constrained devices) to sign document hashes.

• Integrity Checks: In IoT protocols (e.g., CoAP options) where full SHA-256 is too expensive.

6.0 Lightweight Stream Ciphers

Fundamental Operation: Generates a pseudo-random keystream $Z$ from a secret key $K$ and optional nonce $IV$. Ciphertext $$\displaystyle C = P \oplus Z $$. Decryption is identical: $$\displaystyle P = C \oplus Z $$.

Design Principles for Efficiency & Security:

• Small Internal State: Reduces memory/area. Trade-off: smaller state may be vulnerable to state recovery attacks.

• Simple Update Function: Fast software/hardware implementation (e.g., LFSR-based like Trivium, or ARX-based like Salsa20).

• Long Period: Keystream must not repeat within expected usage.

• Resistance to Distinguishing Attacks: Keystream should be computationally indistinguishable from random.

Analysis of Specific Attacks & Countermeasures:

• Birthday Attack (on state):

  • Principle: After about $$\displaystyle \sqrt{2^n} $$ keystream blocks (where $n$ is state size), collisions in internal state become likely.

  • Countermeasure: Use a sufficiently large state (e.g., > 128 bits). Ensure the re-keying frequency is much lower than $$\displaystyle \sqrt{2^n} $$.

• Related-Key / IV Reuse Attacks:

  • Principle: Reusing the same $(K, IV)$ pair completely breaks confidentiality.

  • Countermeasure: Strict nonce management. Never reuse $(K, IV)$. For lightweight, often a counter or frame counter is used as nonce.

Trade-offs:

• Security vs. State Size: Larger state -> more secure against state recovery, but more memory.

• Speed vs. Complexity: ARX ciphers are fast in software but may have higher energy. LFSR-based are very cheap in hardware.

• Initialization Phase: Some ciphers have a slow "warm-up" phase before producing keystream (e.g., Trivium's 1152 cycles). This impacts latency.

[!TIP] Exam Answer: For "optimize to resist birthday attack," state: "Ensure the internal state size $n$ is large enough such that the expected keystream output before re-keying is significantly less than $$\displaystyle 2^{n/2} $$."

7.0 Security Evaluation, Threats, and Broader Considerations

Importance of Public Design & Extensive Cryptanalysis:

• Kerckhoffs's Principle: Security should rely only on the key, not algorithm secrecy.

• Community Scrutiny: Public design allows global experts to find flaws. "Many eyes" is essential, especially for new, less-analyzed lightweight ciphers.

• Long-term Viability: An algorithm that withstands years of public cryptanalysis is trusted for long-lived IoT deployments.

Common Threat Models for Tiny Devices:

1. Physical Access & Node Capture: Attacker has the device. Can perform invasive attacks (microprobing, decapping), semi-invasive (laser fault injection), or read non-volatile memory to extract keys.

2. Side-Channel Attacks (SCA): Exploit physical leakage:

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

   • Timing Attacks: Measure operation times.

   • Electromagnetic (EM) Analysis.

3. Software-Based Attacks: Exploit implementation bugs (buffer overflows, poor RNG).

4. Network Attacks: Eavesdropping, message injection, replay (due to poor nonce management).

How Threats Differ from Traditional Environments:

• Physical Proximity: Attacker can often physically obtain the device (unlike a remote server).

• No Secure Perimeter: Devices are deployed in unattended, hostile environments.

• Limited Defenses: Often no secure boot, no trusted execution environment (TEE), no hardware security module (HSM).

• Cost Constraints: Cannot afford expensive countermeasures (shielding, secure elements).

Role of Standardization Bodies (e.g., NIST LWC Competition):

• Vetting Process: Multi-year competition with public submissions, cryptanalysis, and performance evaluation.

• Creates Trust: Standardized algorithms (e.g., ASCON winner) have undergone rigorous review.

• Promotes Interoperability: Provides a common set of algorithms for IoT ecosystems.

Long-term Viability vs. Short-term Efficiency:

• Short-term Efficiency: Choosing the absolute smallest/fastest algorithm today.

• Long-term Viability: Choosing an algorithm with a large security margin (more rounds than minimally needed) that will resist future cryptanalytic advances over the device's lifetime (5-10 years).

• Guideline: Prefer algorithms with public design, extensive analysis, and standardization over obscure, "optimized" ones with no scrutiny.

[!TIP] Exam Focus: When discussing security, always link the threat to the constraint. Example: "Side-channel attacks are particularly severe for lightweight devices because they often lack hardware countermeasures like masking or secure memory."