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

UNIT 2: Lightweight Cryptography for Database Security

I. Introduction to Lightweight Cryptography in Constrained Database Environments

Definition: Cryptographic techniques optimized for devices with severe resource limitations (e.g., IoT sensors, embedded systems, lightweight database applications).

Motivation: Traditional algorithms (AES, RSA) are too resource-intensive for constrained environments.

Primary Constraints:

• Computational power: Slow CPUs, limited clock rates.

• Memory: Small RAM/ROM (often < 1 KB).

• Energy: Battery-powered, low energy budget.

• Bandwidth: Limited communication capacity.

Inadequacy of Traditional Algorithms:

• AES: 128-bit block, 10+ rounds, large S-Boxes (8-bit), high gate count (~3000–4000 GE in hardware).

• RSA: Asymmetric, large key sizes (≥1024 bits), modular exponentiation—prohibitively slow and memory-heavy.

Threat Landscape for Tiny Devices:

• Physical capture (side-channel attacks).

• Eavesdropping on wireless links.

• Node compromise leading to key extraction.

• Resource exhaustion attacks (Denial-of-Service).

[!TIP] Exam focus: List constraints and give specific examples (e.g., AES gate count, RSA key size).

II. Lightweight Block Ciphers: Design and Analysis

A. Fundamental Design Strategies

Core Design Goals:

1. Minimize area (gate count in hardware, code size in software).

2. Reduce power consumption (fewer operations, efficient logic).

3. Lower latency (fast encryption/decryption).

Trade-offs: Security vs. Efficiency vs. Implementation Cost (e.g., fewer rounds → faster but potentially less secure).

Contrast with Traditional Design (AES):

• AES: Prioritizes security and flexibility (supports 128/192/256-bit keys), uses large S-Boxes, wide state (128-bit).

• Lightweight: Extreme resource minimization, often fixed key/block sizes, simpler operations (bit permutations, small S-Boxes).

B. Modes of Operation for Lightweight Ciphers

Purpose:

• Encrypt data longer than block size.

• Provide semantic security (indistinguishability under chosen plaintext attack).

Common Lightweight-Suitable Modes:

• CTR (Counter): Parallelizable, random access, no padding.

• CBC (Cipher Block Chaining): Requires IV, sequential, provides integrity if combined with MAC.

• OFB (Output Feedback): Turns block cipher into stream cipher, limited error propagation.

Example Application:
PRESENT in CTR mode for sensor data streams. Each block uses counter || nonce, enabling parallel decryption.

[!TIP] CTR mode is often preferred for lightweight due to parallelism and no chaining delay.

C. Case Studies: PRESENT and CLEFIA

PRESENT (2007):

• Design Philosophy: Hardware-centric, ultra-lightweight for RFID tags.

• Structure: 31-round Feistel network, 64-bit block, 80/128-bit key.

• Components: 4-bit S-Box (hardware-efficient), bit permutation layer.

• Target: Extremely low gate count (~1000 GE).

CLEFIA (2007, Sony):

• Design Philosophy: Balanced hardware/software, suitable for consumer devices.

• Structure: Feistel with 4-round F-function, 128-bit block, 128/192/256-bit key.

• Components: 8-bit S-Box (better diffusion), 4-round F-function with two 32-bit branches.

• Target: Good software performance on 8/16-bit CPUs.

Comparative Analysis:

DESL/DESXL: Variants of DES with reduced rounds and larger keys; less adopted than PRESENT/CLEFIA.

[!TIP] PRESENT: 4-bit S-Box for hardware efficiency; CLEFIA: 8-bit for software speed. Remember block size difference.

D. Substitution Boxes (S-Boxes)

Function: Provide confusion—non-linear substitution obscuring key-ciphertext relationship.

Design Considerations:

• Size:

  • 4-bit S-Box (16 entries): Small hardware footprint, less diffusion per round.

  • 8-bit S-Box (256 entries): Better diffusion, larger memory/area.

• Implementation:

  • Hardware: Combinational logic (gate count critical).

  • Software: Table lookup (ROM size) vs. bit-sliced (no table, more operations).

• Security Criteria: High nonlinearity, low differential uniformity to resist linear/differential cryptanalysis.

E. Stream Ciphers in Lightweight Contexts

Vulnerability: Birthday Attack:

• If internal state size is $n$ bits, collisions become likely after $$\displaystyle \approx \sqrt{2^n} $$ output bits.

• Probability of collision after $k$ bits:

$$P \approx \frac{k^2}{2^{n+1}}$$

• \boxed{P(\text{collision}) \approx \frac{k^2}{2^{n+1}}}

Design Optimizations:

• Increase state size: Larger $n$ raises birthday bound (e.g., 80-bit state → risk at ~$$\displaystyle 2^{40} $$ bits).

• Output function design: Ensure output depends on entire state to avoid early collisions.

• Example: Trivium (80-bit state) uses nonlinear feedback to resist attacks.

[!TIP] State size must be > security parameter (e.g., 80-bit security needs ~160-bit state due to birthday bound).

III. Cryptanalysis and the Open Design Paradigm

Open Design Principle: Cryptographic algorithms should be publicly specified and scrutinized—"security through obscurity" is flawed.

Role of Cryptographic Community:

• Propose attacks (linear, differential, algebraic, side-channel).

• Evaluate security margins (e.g., reduced-round versions).

• Suggest improvements.

Ensuring Long-Term Viability:

• Extensive cryptanalysis over years (e.g., AES took 5+ years).

• Standardization (NIST, ISO) requires public competition and analysis.

• Example: PRESENT withstood years of analysis; some lightweight ciphers broken quickly (e.g., KATAN had weaknesses).

[!TIP] Open design allows "many eyes" to find flaws—critical for lightweight ciphers with smaller security margins.

IV. Key Management for Resource-Constrained Database Systems

A. Core Concepts and Specific Challenges

Key Management Lifecycle: Generation, distribution, storage, rotation, revocation, destruction.

Challenges:

• Secure Storage: Limited non-volatile memory; keys in insecure flash.

• Distribution: No initial secure channel; may require pre-shared keys or expensive public-key.

• Rotation: Frequent rotation needed but costly in energy/computation.

• Revocation: Hard to propagate in low-bandwidth networks.

B. Centralized vs. Distributed Key Management

Security Implications:

• Centralized: Simpler but vulnerable to KDC attacks; requires secure KDC.

• Distributed: More resilient but susceptible to man-in-the-middle without authentication.

C. Integration into Standard Security Protocols

Adapting IPSec/TLS for Constrained Environments:

• Lightweight Cipher Suites: Replace AES with PRESENT or SPECK in TLS cipher suite list.

• Session Resumption: Use session tickets/IDs to avoid full handshake (reduces 2–3 round trips).

• Compression & Minimization: Strip unnecessary extensions, use raw public keys instead of X.509.

• Example: CoAP (Constrained Application Protocol) uses DTLS with lightweight ciphers.

D. Group Key Management for IoT Database Applications

Key Evaluation Considerations:

1. Scalability: Efficient support for many members (e.g., LKH scales as $O(\log n)$ rekey messages).

2. Communication Overhead: Messages per join/leave; bandwidth cost.

3. Computational Cost: Key derivation operations per node (should be minimal).

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

5. Backward Secrecy: New member shouldn't access past group communications.

Integration of Symmetric Techniques:

• Use Logical Key Hierarchy (LKH): Each node holds individual key + shared keys with parent in tree. Rekey only affected nodes.

• Combine with pairwise symmetric keys for initial authentication, then derive group key via KDF.

• Example: Sensor network base station manages group key using LKH with pre-installed symmetric keys.

[!TIP] Group key management often uses symmetric key trees (LKH) to balance overhead and secrecy—common in IoT.

V. Lightweight Cryptographic Hash Functions

Purpose:

• Data integrity (detect tampering).

• Message authentication (with HMAC).

• Key derivation (from master key).

Design Principles:

• Sponge Construction (Keccak): Absorb phase (input), squeeze phase (output). Flexible output length, compact state.

• Compact Internal State: Reduce memory (e.g., 256-bit state vs. 512-bit in SHA-2).

• Efficient Operations: Bitwise rotations, additions (avoid 32-bit multiplies).

Real-World Applications:

• Lightweight MACs: e.g., PMAC-TLIGHT using PRESENT for sensor database authentication.

• Integrity Checks: Hash stored records in embedded databases to detect corruption.

• Key Derivation: Derive session keys from master key with lightweight hash (e.g., PHOTON).

VI. Foundational Cryptographic Concepts

A. Symmetric vs. Asymmetric Cryptography

Why Asymmetric is Expensive:

• Operations: Modular exponentiation (many multiplications).

• Memory: Large integers (hundreds of bytes).

• Example: RSA-1024 requires ~10,000 multiplications vs. AES-128 ~1000 operations.

[!TIP] Symmetric is default for constrained devices; asymmetric only for initial key exchange if absolutely necessary.

VII. Computational Operations and Practical Constraints

Meaning of "Operation":

• Basic CPU instructions: bitwise (XOR, AND, OR, NOT), shifts/rotates, additions (mod $$\displaystyle 2^8 $$, $$\displaystyle 2^{16} $$), table lookups.

• In hardware: gate-level operations (e.g., 2-input NAND, XOR gates).

• Cost: Each operation consumes energy; count correlates with power draw.

Why Standard Methods Fail:

1. Excessive Memory Footprint: AES requires 128-bit state (~16 bytes) plus round keys—too large for devices with <1 KB RAM.

2. High Cycle Count: AES-128: 10 rounds × ~40 operations/round = 400+ operations per block. Lightweight ciphers like PRESENT: 31 rounds but simpler ops (bit permutations, 4-bit S-Box) → lower total cost.

3. Hardware Implementation: AES's S-Boxes are complex in hardware; lightweight use smaller S-Boxes or bit-oriented designs.

Energy Consumption Link:

• Battery life critical: more operations → more power → shorter battery.

• Example: AES-128 on 8-bit CPU may take 1000 cycles; PRESENT may take 500 cycles with simpler ops → lower energy per cycle.

• \boxed{\text{Energy} \propto \text{Operation Count} \times \text{Energy per Operation}}

[!TIP] Define "operation" in context: e.g., on an 8-bit AVR, an 8-bit XOR is one operation; a 4-bit S-Box lookup might be 4 table lookups or combinatorial logic.