Deep & Reinforcement Learning (CY-802 (B)) - Unit 2 Short Notes

UNIT 2: FUNDAMENTALS AND DESIGN OF LIGHTWEIGHT CRYPTOGRAPHY

I. INTRODUCTION & MOTIVATION

A. The Need for Lightweight Cryptography

• Definition: Cryptography tailored for resource-constrained devices (e.g., IoT sensors, RFID tags, embedded systems) with severe limitations.

• Primary Constraints:

  • Area/Gate Count: Minimal silicon footprint (often < 1000 GE).

  • Power/Energy: Battery-powered or energy-harvesting; ultra-low consumption.

  • Memory: Limited RAM (bytes to KB) and ROM/Flash (KB).

  • Processing Speed: Low clock rates (MHz), 8/16-bit microcontrollers.

  • Bandwidth: Low data rates, small packet sizes.

• Contrast: Traditional devices (laptops, servers) have abundant power, memory, and processing capability, allowing complex algorithms like AES-256 or RSA-2048.

B. Threats to Tiny Devices

• Unique Threat Model:

  • Physical Access: Easy capture/tampering (side-channel attacks, probing, reverse engineering).

  • Simple Communication Interception: Wireless (RFID, BLE, ZigBee) is inherently broadcast.

  • Limited Defenses: No secure OS, minimal physical security, often deployed in unattended environments.

• Difference from Traditional Computers: Threats are more physical and pervasive; software-only attacks (e.g., malware) are less common initially but the device's simplicity is its primary vulnerability.

[!TIP] Exam Focus: Always link a constraint (e.g., "low RAM") to a design choice (e.g., "small S-Box") and a resulting threat (e.g., "vulnerable to side-channel if not balanced").

II. LIGHTWEIGHT BLOCK CIPHERS: DESIGN AND ANALYSIS

A. Core Components and Primitives

1. Modes of Operation

• Purpose: Allow a block cipher (fixed block size, e.g., 64/128 bits) to securely encrypt data longer than its block size.

• Lightweight-Suitable Modes:

  • CTR (Counter): Parallelizable, random access, requires unique nonce. Good for streaming.

  • CCM (Counter with CBC-MAC): Provides authentication (AEAD). Widely used in IoT (e.g., IEEE 802.15.4).

  • OCB (Offset Codebook): Highly efficient AEAD, but historically patent-encumbered.

  • GCM (Galois/Counter Mode): Very fast in hardware, but requires large tables/polynomial multiplication—can be heavy for tiny devices.

• Trade-off: Security (nonce reuse catastrophic in CTR/CCM), efficiency (parallel vs. serial), memory (state size for MAC).

2. Substitution Box (S-Box)

• Function: The primary non-linear confusion component. Maps input bits to output bits in a non-linear, key-independent (or dependent) lookup table.

• Lightweight Design Considerations:

  • Small Size: 4-bit (16 entries) or 8-bit (256 entries) are common. Smaller = less memory.

  • Implementation: Efficient in hardware (combinational logic) or software (lookup table vs. bit-sliced).

  • Security Properties: High non-linearity, low differential uniformity, resistance to algebraic attacks (low degree, no low-degree inverses).

B. Design Philosophies and Strategies

1. General Lightweight Design Principles

• Reduce Operations: Fewer rounds, smaller S-Boxes, simpler round functions (e.g., avoid complex mix columns).

• Hardware Optimization:

  • Bit-Serial: Processes 1 bit per cycle. Minimizes area (gate count) at cost of speed.

  • Bit-Parallel: Processes full word (e.g., 8/16/32 bits). Faster but larger area.

  • Metric: Area x Time (AT) product or AT² for holistic hardware efficiency.

• Software Optimization:

  • Byte-Oriented: Align with 8-bit MCU registers.

  • Minimize Table Lookups: Cache-friendly, avoid ROM accesses.

  • Use Simple Operations: XOR, rotations, additions—cheap on all platforms.

• Core Trade-off: Security Margin vs. Resource Efficiency. Reducing rounds/size lowers security margin.

2. Contrast with Traditional Ciphers (e.g., AES)

[!TIP] Common Pitfall: "Fewer rounds = less secure." Not always; a well-designed 31-round 4-bit S-Box cipher can be as secure as a 10-round 8-bit one. Security is about total diffusion and non-linearity.

C. Case Studies of Specific Lightweight Block Ciphers

1. PRESENT

• Target: Hardware (RFID, ultra-constrained).

• Structure: 31-round SPN.

• Block/Key Size: 64-bit block, 80/128-bit key.

• Round Function:

  • AddRoundKey: XOR 64-bit round key.

  • S-Layer: Apply 16 parallel 4-bit S-Boxes (same box).

  • P-Layer: Bit permutation (simple wiring, no logic).

• Key Schedule: Simple, generates 64-bit round keys from 80/128-bit master key.

• Security: Resistant to known attacks up to ~25 rounds. Concern: small block size (64-bit) vulnerable to birthday bound collisions after ~2³² blocks.

2. CLEFIA

• Target: Software/Hardware balance (slightly less constrained than PRESENT).

• Structure: Feistel-type with a "double-Feistel" inner round structure.

• Block/Key Size: 128-bit block, 128/192/256-bit key.

• Round Function:

  • Uses two 8-bit S-Boxes (S0, S1) and a 4x4 MDS matrix for diffusion.

  • More complex than PRESENT, but still efficient on 8/16-bit CPUs.

• Comparison to PRESENT: Larger block (128-bit), more software-friendly, slightly larger area but better security margin against generic attacks.

3. DES-based Lightweight Variants (DESL/DESXL)

• Approach: Modify the legacy DES structure (Feistel, 16 rounds) for efficiency.

• Changes:

  • DESL: Simplified key schedule (fewer round keys generated).

  • DESXL: Larger key size (184-bit) by expanding key schedule.

• Security Implications: Inherits DES's 64-bit block size (birthday problem) and potential structural weaknesses from decades of scrutiny. Generally not recommended for new designs; serves as a lesson in "security by obscurity" vs. open design.

D. The Role of Open Design and Public Cryptanalysis

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

• Process:

  1. Open Publication of specification.

  2. Public Cryptanalysis by academic/industrial community.

  3. Refinement based on attacks or Retirement if broken.

• Case Study: PRESENT is open, extensively analyzed, and remains a NIST lightweight candidate. Ciphers with closed designs (e.g., some proprietary RFID tags) are inherently distrusted.

• Impact: Lack of scrutiny = unknown weaknesses. Successful attacks (e.g., related-key, differential) can invalidate a cipher's security claims.

[!TIP] Exam Answer Structure for Open Design: 1) Define open design. 2) Explain why it's crucial (finds flaws, builds confidence). 3) Give a positive example (PRESENT) and negative implication (proprietary ciphers are risky).

III. LIGHTWEIGHT STREAM CIPHERS

A. Fundamentals and Use Cases

• When to Use: Low-latency streaming data (e.g., real-time sensor data, voice), where block cipher padding/modes are inefficient.

• Core: Generate a pseudorandom keystream from an internal state; ciphertext = plaintext XOR keystream.

B. Design for Security and Efficiency

• State Size Optimization: Must be large enough to resist state collision attacks.

• Birthday Attack on State: If internal state size is n bits, after generating ~2^(n/2) bits of output, two different internal states may produce the same output sequence with high probability.

  • Mitigation: State size n should be at least 2 * desired security level (e.g., for 128-bit security, state ≥ 256 bits). This is a major challenge for ultra-lightweight designs.

• Trade-offs: Larger state = more memory/registers, but better security. Initialization phase (IV loading) must also be secure against related-IV attacks.

IV. LIGHTWEIGHT HASH FUNCTIONS

A. Purpose of Cryptographic Hash Functions

• Core Properties:

  • Pre-image Resistance: Given hash h, hard to find any m such that hash(m) = h.

  • Second Pre-image Resistance: Given m1, hard to find m2 ≠ m1 with hash(m1)=hash(m2).

  • Collision Resistance: Hard to find any pair (m1, m2) with hash(m1)=hash(m2).

• Applications: Message integrity (HMAC), digital signatures (hashing before signing), key derivation (HKDF), commitment schemes.

B. Lightweight Hash Function Design

• Approaches:

  1. Dedicated Designs (e.g., PHOTON, SPONGENT): Based on sponge construction or AES-like permutations with small internal state (e.g., 100-256 bits). Optimized for area.

  2. Block Cipher-Based (e.g., Davies-Meyer): Use a lightweight block cipher as the compression function. Flexible but may inherit block cipher's block size issues.

• Output Size vs. Security: For constrained apps, 128-bit output may suffice (vs. 256-bit standard). Security level is limited by birthday bound on collisions: ~2^(output_size/2).

C. Real-World Lightweight Hashing Applications

• RFID Tag Authentication: Prove identity without storing large keys; hash-based challenge-response.

• Sensor Node Integrity: Verify firmware updates or data packets with minimal code.

• Lightweight Blockchain: For IoT, use truncated hashes (e.g., 128-bit) to reduce transaction size and computation.

V. KEY MANAGEMENT FOR LIGHTWEIGHT CRYPTOGRAPHY

A. Fundamental Concepts

• Symmetric: Same key for encrypt/decrypt. Challenge: Secure distribution and storage of the secret key on all devices.

• Asymmetric: Public/private key pairs. Challenge: Computationally heavy (RSA/ECC), often unsuitable for core data encryption on tiny devices.

• Core Challenges: Secure key storage (often in volatile memory), secure initial distribution (manufacturing), key lifecycle (update, revoke), and minimizing per-operation overhead.

B. Centralized vs. Distributed Key Management

C. Symmetric Key Management in Practice

• Pre-distribution: Keys embedded during manufacturing (secure facility required).

• Key Update: Use a key derivation function (KDF) from a master key and a counter/nonce to generate session keys. Avoids storing many keys.

• Re-keying: Periodic update to limit exposure if a key is compromised.

D. Group Key Management for IoT

• Specific Challenges:

  • Dynamic Membership: Nodes joining/leaving (e.g., mobile sensors, device failure).

  • Secure Multicast: One transmission decryptable by all group members.

  • Scalability: Protocol overhead must not grow linearly with group size.

• Key Considerations for Evaluation:

  1. Communication Overhead: Number of messages needed for join/leave.

  2. Computation Cost per Node: Especially for re-keying after a member change.

  3. Resilience to Node Capture: If one node is compromised, does it reveal the group key?

  4. Forward Secrecy: A compromised node should not decrypt past group communications.

  5. Backward Secrecy: A leaving node should not decrypt future group communications.

  6. Scalability: How does cost grow with N (group size)?

E. Integration into Standard Protocols

• Problem: Standard TLS (RSA/ECC handshake, AES-GCM) and IPSec (IKEv2) are too heavy for Class 1/2 IoT devices (e.g., 8-bit MCU, < 10KB RAM).

• Adaptations:

  • Cipher Suite Selection: Use lightweight suites (e.g., TLS_ECDHE_ECDSA_WITH_AES_128_CCM or TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305). ChaCha20 is often faster than AES on software-only platforms.

  • Handshake Simplification: Use pre-shared keys (PSK) mode in TLS 1.2/1.3 (TLS_PSK_WITH_AES_128_CCM). Avoids expensive public-key ops.

  • Session Resumption: Use PSK resumption or session tickets to avoid full handshake on reconnection.

  • Compressed Headers: Use CoAP (Constrained Application Protocol) with DTLS instead of full HTTP/TLS.

VI. SECURITY CONSIDERATIONS & COMPARISONS

A. Why Traditional Cryptography is Unsuitable

1. Code Size: RSA/ECC libraries can be > 20KB; AES-128 ~2-10KB. Tiny devices may have < 32KB total flash.

2. Memory Footprint: RSA 2048-bit operations require > 1KB RAM. Many sensors have < 1KB RAM.

3. Processing Speed: A single RSA-1024 signature can take seconds on an 8-bit MCU; AES-128 encrypts in milliseconds.

4. Energy Consumption: Public-key ops consume orders of magnitude more energy than symmetric ops (battery life impact).

B. Symmetric vs. Asymmetric in Constrained Settings

• Symmetric (AES, PRESENT, ChaCha20): Fast, low energy, small code. Use for bulk data encryption/decryption, MACs.

• Asymmetric (ECC, RSA): Slow, high memory/energy. Use only for initial key exchange, digital signatures (where absolutely necessary).

• Lightweight Asymmetric: Use ECC with small curves (e.g., Curve25519, NIST P-192) instead of RSA. Still heavy, but the least heavy option. Risk: smaller key sizes offer lower security (e.g., 160-bit ECC ≈ 1024-bit RSA).

C. Holistic Security for Tiny Devices

• Beyond Algorithms: A secure device needs:

  • Secure Boot: Verify firmware integrity at startup.

  • Secure Storage: Protect keys in flash/EEPROM (hardware encryption or obfuscation).

  • Physical Tamper Resistance: Coatings, sensors, zeroization on breach.

  • Secure OS/RTOS: Minimal, privilege-separated, with crypto drivers.

• System Stack View: Weakest link determines security. A perfect lightweight cipher is useless if keys are stored in plaintext or the random number generator is flawed.

[!TIP] Final Exam Checklist: For any "explain" question on lightweight crypto, always touch on: Constraint -> Design Choice -> Security Implication. Example: "Small RAM -> 4-bit S-Box -> potentially lower non-linearity, but acceptable if rounds are sufficient."