Database Security (CY-802 (A)) - Unit 4 Short Notes

UNIT 4: Lightweight Cryptography for Resource-Constrained Environments

I. Foundations and Motivation

Lightweight Cryptography refers to cryptographic primitives and protocols specifically designed for environments with severe constraints on power consumption, memory (RAM/ROM), processing capability, and bandwidth.

Why Traditional Crypto (AES, RSA) is Unsuitable:

Threat Landscape Differences:

• Physical Access: Tiny devices are often physically exposed, increasing risk of side-channel attacks (power analysis, timing).

• Communication: Often use insecure wireless channels (e.g., IoT sensor networks).

• Scalability: Massive deployments (thousands of nodes) create key management nightmares.

• Update Mechanism: Firmware updates are difficult; algorithms must be robust long-term.

Basic Computing Operations in Constrained Context:

An "operation" refers to the fundamental hardware-executable instruction. Key metrics are:

• Gate Equivalents (GE): Hardware area cost.

• CPU Cycles: Time cost on a microcontroller.

• Energy (nJ/bit): Power consumption per bit processed.

[!TIP] Exam Focus: Be prepared to list specific constraints (power, memory, etc.) and quantify them (e.g., "AES requires ~3400 GE, while PRESENT requires ~1000 GE").

II. Lightweight Symmetric Cryptographic Primitives

A. Block Ciphers

Design Strategies (vs. Traditional like AES):

Specific Cipher Families:

• PRESENT: 31-round SPN. 64-bit block, 80/128-bit key. Uses 4-bit S-Box and simple bit permutation layer. Designed for ultra-low hardware cost (~1000 GE).

• CLEFIA: 18/22/26-round Feistel (for 128/192/256-bit keys). 128-bit block. Uses two F-functions per round. More flexible key length, better software performance than PRESENT.

• DESL/DESXL: Modifications of DES for lightweight contexts.

  • DESL: Reduced to 12 rounds, uses single 16-bit S-Box (from original 8x8).

  • DESXL: Extended key size (184-bit), modified S-Boxes for better security.

Role of S-Boxes: Provide non-linearity and confusion. In lightweight ciphers, they are the main source of security but also a memory cost. 4-bit S-Boxes (16 entries) are common, trading some security for massive memory savings vs. 8-bit (256 entries).

Modes of Operation for Lightweight Contexts:

• Purpose: Extend block cipher to encrypt data longer than block size, provide confidentiality/authenticity.

• Common Modes:

  • CTR (Counter): Highly preferred. Parallelizable, random access, no padding. Low latency.

  • CBC (Cipher Block Chaining): Sequential, requires padding. Higher latency.

  • Lightweight-Specific Modes: Often combine encryption & authentication (AEAD) to reduce overhead.

    • Example: CCM (Counter with CBC-MAC). Used in many IoT standards (e.g., IEEE 802.15.4).

    • Example: OCB (Offset Codebook). High performance, but patent issues historically.

• Constraint Considerations: State size (IV + counter), parallelization capability, and total number of block cipher calls per message.

[!TIP] Exam Focus: Contrast PRESENT (SPN) vs. CLEFIA (Feistel). Know that CTR mode is favored for its parallelism. Expect a question linking S-Box size to memory footprint.

B. Stream Ciphers

Core Vulnerability: Birthday Attack on IV/Keystream.

If the same IV (Initialization Vector) is reused with the same key, the XOR of two ciphertexts reveals the XOR of two plaintexts: $$\displaystyle C_1 \oplus C_2 = P_1 \oplus P_2 $$. Birthday Paradox: After generating $$\displaystyle \sqrt{2^n} $$ bits of keystream (where $n$ is internal state size), collisions become probable, potentially revealing state.

Design Optimizations:

1. Large Internal State: Increase $n$ to delay birthday bound (e.g., 128+ bits).

2. Robust IV Loading: Ensure IV uniquely determines a different internal state. Never reuse (Key, IV) pair.

3. Efficient Keystream Generation: Use simple, fast update functions (e.g., LFSR-based like Trivium, or NLFSR like Grain).

4. Periodicity: Ensure keystream period is vastly larger than any single message.

C. Cryptographic Hash Functions

Purpose & Properties: Map arbitrary input to fixed-size output (digest). Requires:

• Pre-image resistance

• Second pre-image resistance

• Collision resistance (hardest to achieve)

• Avalanche effect

Lightweight Design Trade-offs:

• Output Size: Smaller digest (e.g., 128-bit vs. 256-bit) saves bandwidth/computation but reduces collision resistance (birthday attack complexity $$\displaystyle O(2^{n/2}) $$).

• Compression Function: Often based on lightweight block ciphers (e.g., PHOTON uses PRESENT-like permutations) or dedicated designs (e.g., SPONGENT, Quark based on sponge construction).

• Iterations: Fewer rounds to save energy, balanced against security.

Real-World Applications:

• IoT Authentication: Device fingerprinting, message authentication codes (MACs) for sensor data.

• Low-Power Networks: Integrity checks in protocols like CoAP (Constrained Application Protocol) or LoRaWAN.

• Blockchain Light Clients: Merkle tree proofs using compact hashes.

[!TIP] Exam Focus: Link hash function output size to collision resistance via birthday paradox. Know that lightweight hashes often use sponge or compression-function-based designs.

III. Key Management in Resource-Constrained Settings

A. Core Concepts & Challenges

Goal: Secure generation, distribution, storage, rotation, and revocation of cryptographic keys throughout their lifecycle.

Specific Challenges for Constrained Devices:

• Secure Storage: No secure element (TPM). Keys stored in vulnerable flash/EEPROM.

• Distribution: No public-key infrastructure (PKI) overhead. Symmetric key pre-distribution is unscalable.

• Scalability: Millions of devices. Group key management must be $O(\log N)$ rekeying cost.

• Energy: Key exchange protocols must minimize radio-on time and computations.

• Revocation: Efficiently removing compromised devices from a group.

B. Management Approaches

Comparative Analysis for Lightweight:

• Centralized: Device complexity is very low (just store shared key with KDC). But KDC becomes a high-value target and communication bottleneck.

• Distributed (Group): Devices store $O(\log N)$ keys for LKH. Join/Leave operations require rekeying messages sent to affected subgroup, not all. Forward Secrecy is challenging without public-key crypto.

C. Integration with Security Protocols (IPSec/TLS)

Adaptations for Constrained Devices:

1. Cipher Suite Selection: Mandate lightweight suites.

   • TLS: Use TLS_PSK_WITH_AES_128_CCM_8 (pre-shared key) or TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 (ECC + ChaCha20).

   • IPSec: Use AES-CCM or AES-GCM (if hardware supported) for ESP.

2. Handshake Optimization:

   • Resume Sessions: Use session tickets or session IDs to avoid full handshake.

   • Pre-Shared Keys (PSK): Eliminate expensive public-key ops. Key distribution is the challenge.

   • Elliptic Curve Cryptography (ECC): Use curves with fast arithmetic (e.g., Curve25519) if asymmetric is needed. Smaller keys (256-bit) than RSA (2048-bit).

3. Energy-Aware Session Management: Short session lifetimes to limit exposure, but balance against re-handshake cost.

D. Group Key Management for IoT

Key Evaluation Considerations for a New Protocol:

1. Scalability: Rekeying cost after one device joins/leaves. Aim for $O(\log N)$ messages.

2. Join/Leave Efficiency: Message complexity and computation per device.

3. Forward Secrecy (FS): Compromised device cannot decrypt past group traffic. Requires individual key updates.

4. Backward Secrecy (BS): New member cannot decrypt past traffic. Requires rekeying upon join.

5. Computational Cost: Operations per device (encryptions, hashes, modular exponentiations).

6. Resilience: Tolerance to packet loss during rekeying.

Integration of Symmetric Key Management:

• LKH (Logical Key Hierarchy): Classic approach. Devices store a binary tree of keys. Rekeying updates keys on the path from leaf to root. Cost: $O(\log N)$ encryptions per rekey, $O(\log N)$ keys stored per device.

• Key Derivation: Use a group master key (GMK) and a public counter/nonce to derive session keys: $$\displaystyle K_{session} = KDF(GMK, \text{counter}) $$. Reduces need for frequent distribution.

• Distribution Mechanisms: Rekey messages encrypted with individual keys (from LKH) or subgroup keys.

[!TIP] Exam Focus: Know LKH by name and its $O(\log N)$ property. Distinguish FS (compromised device can't read future) from BS (new device can't read past). Always mention trade-offs.

IV. Security Evaluation and Long-Term Viability

Importance of Open Design & Public Scrutiny:

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

• Community Analysis: More eyes find more flaws. Attacks (differential, linear, algebraic) are often discovered by independent researchers.

• Confidence: Algorithms like PRESENT and SIMON/SPECK (though controversial) gained traction through public competition and analysis.

Role of Cryptanalysis:

• Attack Models for Constrained Devices:

  • Side-Channel: Power analysis (DPA, CPA), timing attacks. Most practical threat.

  • Brute-Force: Limited by key size (e.g., 80-bit key is borderline for long-term).

  • Cryptanalytic: Differential, linear, integral attacks reducing effective rounds.

• Assessment: Number of broken rounds vs. full rounds. Security margin.

Ensuring Long-Term Viability:

1. Standardization (NIST LWC Project): NIST's call for lightweight crypto algorithms (2019-2024). Finalists (e.g., ASCON, GIMLI, Xoodoo) undergo intense scrutiny.

2. Iterative Improvement: Based on cryptanalysis findings, designers may tweak S-Boxes, round counts, or key schedules.

3. Implementation Security: Focus on constant-time, masking countermeasures against side-channels.

[!TIP] Exam Focus: Link open design to Kerckhoffs's principle. Side-channel attacks are the primary concern for tiny devices, not just theoretical cryptanalysis.

V. Comparative and Contextual Topics

Symmetric vs. Asymmetric in Constrained Environments:

Application-Specific Security for IoT/Database Edge:

• Sensor Node (Ultra-constrained): Use PRESENT-80 in CTR mode for data encryption. Pre-shared keys with gateway. LKH for group updates.

• Edge Gateway (Less constrained): Handles TLS with ChaCha20-Poly1305, terminates IPSec. Manages group keys for downstream sensors.

• Database at Edge: Encrypt sensitive columns with lightweight block cipher. Use hash-based MAC for integrity. Key stored in secure element if available.

Future Directions:

• Post-Quantum Lightweight: Lattice-based or hash-based signatures (e.g., SPHINCS+) optimized for small devices.

• Hardware/Software Co-design: Ciphers designed for specific microcontrollers (e.g., ARM Cortex-M).

• Authenticated Encryption with Associated Data (AEAD): Standard for IoT (e.g., ASCON, AEGIS).

• PUF (Physical Unclonable Function): For key derivation/device authentication without stored secrets.

[!TIP] Exam Focus: In a "compare" question, structure answer around computation, key size, and use case. For database security context, think "data-at-rest" (symmetric) vs. "access control" (may need asymmetric for initial auth).

\boxed{\text{Core Exam Formula: Security Margin = (Full Rounds) - (Broken Rounds)}} \boxed{\text{Birthday Bound Collision Complexity} = O(2^{n/2}) \text{ for } n\text{-bit output}} \boxed{\text{LKH Rekeying Cost} = O(\log N) \text{ messages/encryptions}}}