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

1.0 Introduction & Motivation

Lightweight Cryptography refers to cryptographic primitives (ciphers, hash functions) specifically designed for resource-constrained environments like IoT devices, RFID tags, and sensor nodes.

Primary Drivers (Constraints):

• Power/Energy: Limited battery life; need for ultra-low energy consumption.

• Computation: Low processor speed (8/16-bit), minimal clock cycles.

• Memory: Tiny RAM (bytes to a few kilobytes) and ROM/Flash.

• Bandwidth & Latency: Low data rates, high latency networks.

• Physical Size & Cost: Minimal gate count (hardware area) and low production cost.

Core Trade-off: Security vs. Efficiency. Performance metrics include:

• Gate Count (hardware area in GE - Gate Equivalents)

• RAM (bytes)

• Energy Consumption (µJ/bit or nJ/bit)

• Latency (cycles/byte)

• Throughput (bits/sec at a given area/power)

[!TIP] Exam Focus: Be prepared to list specific constraints (power, area, memory) and explain the fundamental security-efficiency trade-off.

2.0 Block Ciphers: Design & Examples

2.1 Core Design Goals

• Minimize gate count (hardware area).

• Minimize RAM usage (for state and key schedule).

• Reduce energy per bit encrypted.

• Maintain adequate security margin against known attacks.

2.2 Design Strategies vs. Traditional Ciphers (e.g., AES)

2.3 Analysis of Specific Cipher Families

• DES-based (Legacy Optimization):

  • DESL: DES with Lightweight S-Boxes (4x4) and reduced rounds.

  • DESXL: DESL with eXtended Life (larger key, more rounds). Focus on reusing DES core logic.

• Modern Designs:

  • PRESENT: Bit-oriented Feistel network. Uses 4x4 S-Box and bit permutation. Extremely hardware-efficient (~1k GE). Design Philosophy: Optimize for smallest possible area.

  • CLEFIA: Byte-oriented Feistel (like AES). Uses 8x8 S-Boxes and 4x4 MDS matrix. Balanced design for both hardware and software. Design Philosophy: Provide good performance across platforms with strong security.

2.4 Role & Design of Substitution Boxes (S-Boxes)

• Purpose: Provide non-linearity and confusion (Shannon). Resists linear and differential cryptanalysis.

• Implementation Trade-offs:

  • Look-Up Table (LUT): Fast, but consumes ROM/RAM. Area scales with S-Box size (e.g., 8x8 = 256 bytes).

  • Combinational Logic: Area-efficient for small S-Boxes (e.g., 4x4). No memory, but may have higher delay.

  • Lightweight Trend: Prefer smaller S-Boxes (4x4) implemented as logic circuits to save area.

2.5 Public Scrutiny & Cryptanalysis

• Open Design Process: Cipher specifications, S-Box design criteria, and rationale must be publicly available.

• Role of Cryptanalysis: Academic and public analysis is the only reliable way to discover vulnerabilities. It builds confidence or breaks the cipher.

• Long-term Viability: A cipher's survival depends on withstanding years of intense public scrutiny without a practical break. "Security by obscurity" is unacceptable.

[!TIP] Exam Focus: Be ready to contrast PRESENT (bit-oriented, min area) vs. CLEFIA (byte-oriented, balanced). Know why S-Box size matters (area vs. security). Public scrutiny is a must-mention for any cipher's credibility.

3.0 Modes of Operation for Lightweight Ciphers

3.1 Concept & Necessity

A Mode of Operation defines how to repeatedly apply a block cipher (with block size n) to encrypt data longer than n bits. Provides confidentiality and/or authenticity for variable-length messages.

3.2 Requirements for Lightweight Modes

• Low Overhead: Minimal extra data (IV, counter, nonce).

• Minimal State: Small internal memory for chaining values.

• Parallelizability: Ability to process blocks independently for speed.

• Random Access: Ability to decrypt any block without processing predecessors.

3.3 Example Modes for Lightweight Context

• Counter (CTR) Mode:

  • How: Encrypt successive counter values (nonce || counter) to generate keystream. XOR with plaintext.

  • Benefits for Lightweight: Highly parallelizable, random access (seek to any block), no chaining, minimal state (just counter). Widely recommended for constrained devices.

  • Formula: $$\displaystyle C_i = P_i \oplus E_K(\text{Nonce} || \text{Counter}_i) $$

• Cipher Block Chaining (CBC):

  • Drawbacks: Sequential (cannot parallelize encryption), requires padding, larger state (previous ciphertext), vulnerable to padding oracle attacks. Generally unsuitable for very constrained settings.

• Lightweight-Specific: Often just CTR with carefully managed nonce (e.g., device-specific, message counter) to minimize transmission overhead.

[!TIP] Exam Focus: CTR mode is the go-to answer for lightweight contexts. Know its advantages (parallel, random access) over CBC's drawbacks (sequential, padding).

4.0 Stream Ciphers & Hash Functions

4.1 Stream Ciphers

• Fundamental Principle: Generate a pseudo-random keystream $Z$ from a secret key $K$ and IV. Ciphertext $$\displaystyle C = P \oplus Z $$.

• Specific Vulnerability - Birthday Attack on State:

  • If the internal state size is $n$ bits, after about $$\displaystyle 2^{n/2} $$ keystream blocks, a state collision becomes probable (two different IVs lead to same internal state).

  • This can compromise security if the keystream reuse is detectable.

• Design Optimization: Use a sufficiently large state (e.g., > 128 bits) and a robust state update function to make birthday collisions infeasible in the device's lifetime, while keeping the update logic simple.

4.2 Cryptographic Hash Functions

• Purpose: Map arbitrary-length input to fixed-length output (digest). Used for data integrity, message authentication codes (HMAC), commitment, and key derivation (KDF).

• Lightweight Requirements:

  • Small internal state/compression function (low RAM).

  • Low gate count for the compression function.

  • Trade-off on Output Size: 128-bit output may be acceptable for constrained integrity (vs. 256-bit for general use).

• Real-World Application Example:

  • PHOTON or SPONGENT (sponge-based lightweight hashes) used in RFID authentication protocols to provide integrity and device authentication with minimal hardware.

[!TIP] Exam Focus: Link stream cipher state size to birthday bound ($$\displaystyle 2^{n/2} $$). For hashes, know they are used for integrity and key derivation in IoT protocols, with examples like PHOTON.

5.0 Key Management for Lightweight Cryptography

5.1 Core Concept & Lifecycle

Key Management encompasses generation, distribution, storage, usage, rotation, and destruction of cryptographic keys throughout their lifecycle.

5.2 Specific Challenges for Resource-Constrained Devices

• Secure Storage: Lack of TPM/Secure Element. Keys stored in volatile RAM or unprotected flash are vulnerable to physical capture.

• Secure Establishment: High-cost asymmetric operations (e.g., RSA) are prohibitive. Need efficient symmetric or lightweight asymmetric (ECC) key agreement.

• Scalability: Managing keys for thousands/millions of IoT devices in a network is a logistical nightmare.

5.3 Centralized vs. Distributed Key Management

5.4 Integration into Standard Protocols (IPSec/TLS)

• Adaptations for Constrained Devices:

  • Use lightweight cipher suites (e.g., PRESENT-CTR instead of AES-GCM).

  • Session Resumption: Reuse previously negotiated keys to avoid full handshake cost.

  • Header Compression: Use 6LoWPAN or CoAP to compress IPSec/TLS headers.

  • Minimal Handshake: Use pre-shared keys (PSK) instead of expensive certificate-based authentication.

  • Example: TLS-PSK or DTLS with lightweight ciphers for CoAP.

5.5 Group Key Management for IoT

Key Considerations for Protocol Evaluation:

1. Scalability: How does communication/computation overhead grow with group size N? (Aim for O(log N) or O(1)).

2. Re-keying Efficiency: Cost to change the group key (e.g., after a member joins/leaves). Should be low.

3. Join/Leave Handling: Protocol complexity for member addition/removal.

4. Forward & Backward Secrecy: Compromise of a member's key should not reveal past (forward) or future (backward) group keys.

5. Resilience to Node Capture: Impact if a physical device is stolen.

6. Communication Overhead: Number and size of messages for key distribution.

Integration of Symmetric Key Management:

• Logical Key Hierarchy (LKH): A centralized group manager holds a tree of symmetric keys. To re-key, it sends encrypted new keys only to affected subgroups (O(log N) messages). Balances centralized control with scalable distribution.

• Pairwise Key Approach: Each pair of members shares a unique symmetric key. Group key is encrypted under all pairwise keys (O(N) messages - not scalable).

• Hybrid: Use a lightweight asymmetric (e.g., ECC) for initial group join, then switch to symmetric group key for data encryption.

[!TIP] Exam Focus: Centralized (KDC) vs. Distributed comparison is a high-frequency question. For group key management, LKH is the classic scalable solution. Always mention forward/backward secrecy and scalability (O(log N)) as key metrics.

6.0 Suitability & Threat Landscape

6.1 Why Traditional Cryptography (AES, RSA, SHA-2) is Often Unsuitable

• AES: 128-bit block size may be large for tiny packets; S-Box is 256-byte LUT (too big for some ROM); software implementations can be slow on 8-bit MCUs.

• RSA/ECC (Asymmetric): Extremely high computational cost (modular exponentiation). RSA-2048 is completely infeasible; even ECC (256-bit) is heavy for frequent key exchange.

• SHA-2: Large internal state (256/512 bits), high gate count. SHA-256 is too heavy for many sensor nodes.

6.2 Security Threats for Tiny Devices vs. Traditional Computers

6.3 "Operation" in a Computer Context

An operation is a fundamental computational step. For comparing algorithm efficiency on constrained devices:

• Hardware: 1 gate delay (time for signal to propagate through a logic gate).

• Software: 1 CPU instruction cycle (e.g., on an 8-bit AVR, a 32-bit add may take 4 cycles).

• Metric: Cycles per byte (cpb) or gate-equivalents (GE) for area. Efficiency is measured in operations per joule.

[!TIP] Exam Focus: Contrast threats: physical capture & side-channels are paramount for IoT. Define "operation" as a gate delay (hardware) or instruction cycle (software).

7.0 Symmetric vs. Asymmetric Cryptography in Constrained Settings

7.1 Fundamental Difference

• Symmetric: Same secret key $K$ for encryption and decryption (or MAC generation/verification). Examples: AES, PRESENT, HMAC.

• Asymmetric (Public-Key): Uses a key pair: Public key ($PK$) for encryption/signature verification, Private key ($SK$) for decryption/signature. Examples: RSA, ECC.

7.2 Comparative Analysis for Lightweight Applications

[!TIP] Exam Focus: Symmetric is for bulk encryption; asymmetric is for key exchange/signatures – this is the golden rule. Emphasize that ECC is the only feasible asymmetric option for many IoT devices, but still costly compared to symmetric.