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

UNIT 5: Lightweight Cryptography for Resource-Constrained Environments (Database Security Context)

I. Introduction to Lightweight Cryptography

Definition and Scope

Lightweight cryptography provides security primitives (ciphers, hash functions, key management) specifically designed for devices with severe resource constraints—such as IoT sensors, RFID tags, wearables, and edge database nodes. It contrasts with traditional cryptography (e.g., AES-256, RSA-2048, ECC-256) by prioritizing minimal area (hardware footprint), power consumption, energy efficiency, throughput, and latency over maximum security margins.

Motivation and Need

• Resource constraints: Limited battery power, small RAM/ROM (often < 10 KB), low clock speeds (MHz range), narrow bandwidth.

• Application domains: Smart agriculture sensors, industrial IoT controllers, embedded database systems in edge computing, wearable health monitors.

• Database security context: Securing data at rest in edge databases, authenticating sensor data streams, encrypting lightweight DBMS logs.

Why Traditional Cryptography is Unsuitable (High-frequency: Q12, Q13, Q17)

Traditional algorithms (AES, RSA, SHA-256) are impractical due to:

1. High computational overhead: RSA operations can require millions of clock cycles; AES-128 needs ~10k gates in hardware.

2. Large memory footprint: Code size and RAM usage exceed available memory (e.g., AES-128 requires ~10 KB ROM).

3. Inefficient communication: Large ciphertext expansion and packet overhead unsuitable for low-bandwidth networks.

Key Performance Metrics

Basic Computing Operations in Constrained Devices (Q18)

An "operation" refers to a fundamental computing step measured by:

• Gate count (hardware): Number of logic gates required.

• Clock cycles (software/processor): CPU cycles needed.

• Energy consumption: Joules or nanojoules per operation.

[!TIP] In exams, define operation as "the basic unit of computational work, typically measured in gate equivalents for hardware or clock cycles for software."

II. Lightweight Block Ciphers

A. Design Strategies and Philosophies (High-frequency: Q2, Q3)

• Reduced algorithmic complexity: Fewer rounds (e.g., PRESENT uses 31 vs AES’s 10), simpler round functions (e.g., bit-oriented permutations).

• Optimized S-Box design: Small lookup tables (4-bit vs 8-bit), hardware-friendly (minimize depth), or software-friendly (byte-oriented).

• Lightweight key schedules: On-the-fly key generation, reduced memory for round keys.

• Trade-offs: Security margin vs. performance; resistance to cryptanalysis (differential, linear) vs. simplicity.

• Examples:

  • PRESENT: Substitution-Permutation Network (SPN), 64-bit block, 80/128-bit key, 31 rounds.

  • SIMON/SPECK: ARX (Add-Rotate-XOR) design, balanced for hardware/software.

  • DESL/DESXL: Modified DES with reduced S-Boxes and key schedule.

B. Modes of Operation (Q1)

• Purpose: Extend block cipher to arbitrary-length data.

• Common modes: ECB, CBC, CTR, OFB, CFB.

• Lightweight considerations:

  • Low memory: Modes requiring minimal state (e.g., CTR vs CBC).

  • Parallelizability: CTR mode allows parallel encryption/decryption.

  • Error propagation: Limited in CTR/CFB (bit errors affect only corresponding bit).

• Example: CTR mode is preferred for constrained devices due to parallel processing and no padding overhead.

C. Security Analysis of Lightweight Block Ciphers

• Open design principle: Public scrutiny ensures long-term viability (see V.A).

• Known attacks: Related-key, differential, linear cryptanalysis; security margin measured by number of rounds broken.

• Evaluation criteria:

  • Security margin: Rounds needed for security vs. implemented rounds.

  • Side-channel resistance: Minimal power/EM leakage, constant-time implementations.

[!TIP] Always mention "security margin" when discussing lightweight cipher security—examiners look for this term.

III. Stream Ciphers and Lightweight Hash Functions

A. Stream Ciphers (Q14)

• Fundamentals: Generate pseudorandom keystream $$\displaystyle z_i $$ from internal state; ciphertext $$\displaystyle c_i = p_i \oplus z_i $$. Synchronous (state independent of plaintext) or self-synchronizing.

• Vulnerabilities:

  • Birthday attack: Exploits state reuse; probability $$\displaystyle \approx 2^{-n/2} $$ for $n$-bit state.

  • Distinguishing attacks: Detect non-randomness in keystream.

  • State compromise: If state revealed, all past/future keystream compromised.

• Design optimizations: Large internal state ($\geq$ 128 bits), nonlinear update functions, efficient initialization.

• Examples: Trivium (80-bit state, 288-bit key), Grain (80-bit state), HC-256 (256-bit state).

B. Lightweight Hash Functions (Q6)

• Purpose: Data integrity, authentication, lightweight digital signatures (e.g., for RFID tags).

• Design approaches:

  • Sponge construction (PHOTON, QUARK): Absorb-pad-squeeze phases, flexible output length.

  • Davies-Meyer: Block cipher-based compression.

  • Merkle-Damgård: Iterative compression (e.g., reduced SHA-3 candidates).

• Performance: Area < 5k GE, throughput > 100 Mbps at low power.

• Real-world applications:

  • RFID authentication: QUARK for tag-reader mutual auth.

  • Sensor network integrity: PHOTON for data aggregation.

  • Lightweight blockchain: Sponge-based hashing for IoT transactions.

IV. Key Management for Resource-Constrained Devices (Core: Q5, Q7, Q8, Q9, Q10)

A. Fundamentals and Challenges (Q5)

• Key lifecycle: Generation → Distribution → Storage → Rotation → Revocation → Destruction.

• Specific challenges:

  • Limited secure storage: Hardware secure modules (HSMs) often absent; keys stored in volatile memory.

  • Low computational power: Asymmetric operations (RSA, ECC) expensive; prefer symmetric key exchange.

  • Scalability: Millions of devices; group key management overhead.

  • Secure provisioning: Initial key injection physically or via secure channel.

[!TIP] For Q5, emphasize "limited secure storage" and "low computational power for asymmetric ops" as primary challenges.

B. Centralized vs. Distributed Key Management (Q7)

C. Integration into Standard Security Protocols (Q8)

• IPSec adaptation:

  • Lightweight cipher suites in ESP (e.g., PRESENT-CTR, SIMON-CTR).

  • Simplified IKE: Use ECC with small curves (e.g., Curve25519) for key exchange; reduce packet exchanges.

• TLS adaptation:

  • Lightweight cipher suites: AES-CCM, ChaCha20-Poly1305 (software-efficient).

  • Optimized handshake: Session resumption, compressed certificates.

• Challenges: Maintaining forward secrecy and authentication while reducing handshake rounds and computational cost.

D. Group Key Management for IoT (Q9, Q10)

• Requirements:

  • Scalability: Support thousands of nodes.

  • Efficient rekeying: Low join/leave latency (< 1 sec).

  • Forward/backward secrecy: Compromised node cannot access past/future keys.

  • Low communication: Minimal messages per rekeying.

• Symmetric vs. asymmetric approaches (Q10):

  • Symmetric: LKH (Logical Key Hierarchy)—key tree, $O(\log n)$ rekeying messages.

  • Asymmetric: TGDH (Tree-based Group Diffie-Hellman)—contributory key agreement, higher computation.

  • Hybrid: Use asymmetric for initial key establishment, symmetric for data encryption.

• Evaluation considerations for new protocols:

  • Device capabilities (CPU, memory).

  • Network topology (star, mesh).

  • Application type (smart home vs. industrial IoT).

  • Resistance to collusion attacks.

[!TIP] For group key questions, always mention LKH and TGDH as examples, and highlight $O(\log n)$ rekeying cost as a key efficiency metric.

V. Security Analysis, Threats, and Design Principles

A. Open Design and Cryptanalysis (Q4)

• Principle: "Security through transparency"—algorithms public, only keys secret.

• Role of public scrutiny:

  • Community validation of security claims.

  • Identification of subtle vulnerabilities (e.g., related-key attacks on SIMON).

  • Long-term viability through iterative improvements.

• Case studies:

  • PRESENT: Withstood years of analysis but has related-key attacks on reduced rounds.

  • SIMON: NSA design; initial skepticism due to lack of public process, later cryptanalysis revealed weaknesses in some variants.

[!TIP] For Q4, stress that open design enables peer review and builds trust, unlike proprietary algorithms.

B. Threat Landscape for Constrained Devices (Q15)

• Physical attacks:

  • Side-channel: Power analysis, timing attacks (exploiting variable operations).

  • Fault injection: Glitching to bypass checks.

  • Probing: Physical access to extract keys from memory.

• Protocol attacks:

  • Replay attacks: Reusing captured packets (common in sensor networks).

  • Man-in-the-middle: During key exchange if authentication weak.

  • Denial-of-service: Resource exhaustion (e.g., forcing heavy crypto operations).

• Differences from traditional computers:

  • Limited defenses: No MMU, no secure boot, minimal crypto acceleration.

  • Physical accessibility: Devices often deployed in unattended environments.

  • Resource exhaustion: Attacks that drain battery or CPU are catastrophic.

C. Symmetric vs. Asymmetric Cryptography (Q16)

[!TIP] For Q16, state that asymmetric is too heavy for data encryption in constrained devices; used only for key establishment.

VI. Application in Database Security Context

• Securing data in constrained database systems:

  • Lightweight encryption (PRESENT, SIMON) for data at rest in edge DBMS (e.g., SQLite on Raspberry Pi).

  • Efficient integrity checks: Lightweight hash (PHOTON) for sensor data stored in time-series DBs.

  • Access control: Symmetric key-based authentication for database queries.

• Protocol integration for database communication:

  • Securing database queries/responses in IoT networks using lightweight TLS (ChaCha20-Poly1305).

  • Group key management for collaborative DB apps (e.g., smart agriculture: multiple sensors writing to shared DB).

  • Example: LKH for rekeying when sensors join/leave agricultural monitoring network.

VII. Conclusion and Future Directions

• Key challenges: Balancing security vs. performance, side-channel resistance, scalable key management.

• Standardization efforts:

  • NIST Lightweight Cryptography Project: Evaluating candidates (e.g., ASCON, GIMLI).

  • ISO/IEC 29192: Lightweight cryptography standards.

• Emerging trends:

  • Post-quantum lightweight cryptography: Lattice-based schemes with small keys.

  • Hardware-software co-design: Custom instructions for lightweight ciphers.

  • AI-assisted cryptanalysis: Machine learning to find new attacks.

[!TIP] In exams, always link lightweight crypto to IoT/edge database scenarios—show you understand the application context.