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

UNIT 1: Fundamentals of Lightweight Cryptography for Resource-Constrained Environments

1.0 Introduction & Motivation

Lightweight Cryptography is the design and implementation of cryptographic algorithms and protocols optimized for environments with severe resource constraints—limited power, processing capability, memory, and bandwidth.

[!TIP] Exam Focus: Always link a constraint (e.g., "limited RAM") to a design choice (e.g., "small state size") when explaining suitability.

2.0 Lightweight Cryptographic Primitives: Design & Analysis

2.1 Block Ciphers

Design Strategies for Lightweight Block Ciphers:

• Reduced Round Count: Fewer rounds than AES (e.g., 31 for PRESENT vs. 10 for AES-128) but with stronger per-round diffusion.

• Simpler S-Boxes & Permutations: Use small, fixed S-Boxes (e.g., 4-bit in PRESENT) and bit/byte-level permutations instead of complex MixColumns.

• Lightweight Key Schedule: Avoid expensive key expansion; use simple round key derivation (e.g., XOR with constants, rotate).

• Structure Choice: Often use Substitution-Permutation Network (SPN) (PRESENT) or Feistel Network (CLEFIA) for balanced performance.

Components:

• Substitution Box (S-Box): Provides confusion. Non-linear mapping (e.g., 4-bit input → 4-bit output). Design goal: low gate count, good differential/linear properties.

• Permutation Layer: Provides diffusion. Spreads bit influence across the state. Often a simple bit-shuffle or rotation.

Modes of Operation for Lightweight Block Ciphers:

• Purpose: Allow encryption of data longer than block size, provide confidentiality/authenticity.

• Common Lightweight Modes: CTR (Counter) mode is highly favored—parallelizable, requires only encryption, no padding. CBC can be used but is sequential and needs padding. Specialized modes like CTR_DRBG for randomness generation.

[!TIP] Common Pitfall: Do not confuse "lightweight mode" with a new mode; it's often the same mode (CTR) implemented efficiently on a lightweight cipher.

2.2 Stream Ciphers

• Design Principle: Generate a pseudorandom keystream bit-by-bit/byte-by-byte, XOR with plaintext. Must be efficient in hardware/software.

• Vulnerability - Birthday Attack: Relies on collisions in internal state after ~√(state size) outputs. To resist: ensure large enough internal state (e.g., >128 bits) and proper state update.

• Design Optimization: Use simple update functions (LFSRs, NLFSRs), minimize memory footprint, avoid complex operations. Example: Trivium (80/128-bit state) or Grain (80-bit LFSR + 80-bit NLFSR).

2.3 Cryptographic Hash Functions

• Purpose: Produce a fixed-size digest (hash) from arbitrary input. Properties: pre-image resistance, second pre-image resistance, collision resistance.

• Lightweight Hash Design: Small internal state (e.g., 256-bit output, but 512-bit or less internal), compression function based on lightweight block cipher (e.g., PHOTON uses PRESENT-like permutations) or dedicated design (e.g., SPONGENT).

• Real-World Application: Integrity checking of firmware updates in IoT sensors, lightweight authentication (e.g., hash-based message authentication code - HMAC) where full signatures are too heavy.

2.4 Symmetric vs. Asymmetric Cryptography

[!TIP] Exam Answer: "Symmetric crypto is suitable because it uses fast operations (XOR, table lookups); asymmetric is unsuitable due to high computational cost (modular arithmetic)."

3.0 Key Management in Lightweight Cryptography

3.1 Core Concepts & Challenges

• Definition: The process of generating, distributing, storing, rotating, and revoking cryptographic keys.

• Critical Importance: Security of the entire system fails if keys are compromised.

• Specific Challenges in Constrained Devices:

  1. Storage: Limited non-volatile memory to store keys securely.

  2. Distribution: No secure channel; often pre-provisioned or via key agreement with minimal overhead.

  3. Lifecycle: Difficult to update/revoke keys remotely due to bandwidth/power limits.

  4. Scalability: Managing keys for thousands of nodes.

3.2 Architectural Approaches

3.3 Group Key Management for IoT

• Integration: Symmetric group keys (shared by all/many group members) are essential for efficient broadcast/multicast (e.g., sensor data to controller).

• Key Considerations for Evaluating New Protocols:

  1. Communication Overhead: Number of messages, size per message (must be minimal).

  2. Computation per Node: CPU cycles, memory usage during join/leave.

  3. Scalability: Performance degradation as group size grows.

  4. Forward/Backward Secrecy: Compromise of one node shouldn't reveal past/future group keys.

  5. Resilience to Node Capture: Ability to re-key efficiently if a device is physically compromised.

3.4 Protocol Integration

• Goal: Adapt standard secure protocols (IPSec, TLS) for constrained devices (e.g., 6LoWPAN networks).

• Methods:

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

  • Use ECDH (Elliptic Curve Diffie-Hellman) with small curves (e.g., Curve25519) for key exchange instead of RSA.

  • Implement header compression (e.g., in CoAP) to reduce overhead.

  • Example: TinyDTLS—a DTLS implementation for constrained devices, using ECC and lightweight ciphers.

4.0 Security Evaluation & Design Philosophy

• Open Design & Public Scrutiny: Algorithms must be publicly specified and open to cryptanalysis. Secrecy of design is not a substitute for sound engineering ("Kerckhoffs's principle").

• Role of Cryptanalysis: Attempts to break the cipher (differential, linear, algebraic attacks) validate its security margin. A cipher surviving years of public analysis is trusted.

• Trade-offs: The core triangle: Security (bits of security, e.g., 80-bit vs 128-bit) vs. Performance (gate count, energy/bit) vs. Cost (silicon area, implementation complexity). Designers must pick a point based on application threat model.

• Long-Term Viability: Consider cryptographic agility—ability to replace the cipher if broken. Avoid overly novel designs with little analysis. Prefer ciphers from standardization efforts (e.g., NIST LWC competition finalists like ASCON, GIMLI).

[!TIP] Exam Answer Structure: "Public scrutiny allows global experts to find flaws. Cryptanalysis provides evidence of security margin. Without both, a cipher's long-term viability is questionable."

5.0 Threat Landscape for Constrained Devices

• How Threats Differ:

  • Physical Access: Devices are often deployed in unattended, hostile environments (e.g., smart meters, wildlife sensors). Physical tampering and side-channel attacks (power analysis, timing attacks) are primary threats, not just remote network attacks.

  • Limited Computational Power: Attacker can launch brute-force or dictionary attacks more easily if keys are weak (e.g., 40-bit keys).

  • Network Exposure: Often use insecure wireless links (e.g., 802.15.4), making eavesdropping and packet injection easy.

  • Software Complexity: Simple firmware may have implementation bugs (buffer overflows) rather than complex protocol flaws.

• Implications for Threat Model: Must assume physical compromise is possible. Therefore, key storage must be tamper-resistant (if possible), and protocols must support node revocation and key re-establishment.

6.0 Foundational Concepts

• Definition of an "Operation": The fundamental unit of computational work in a cipher. Can be:

  • Gate Delay: Time for a logic gate (AND, OR, XOR) to propagate in hardware.

  • Instruction Cycle: Time for a CPU instruction (e.g., ADD, LOAD) in software.

  • S-Box Lookup: Often counted as a single table lookup operation.

• Resource Metrics:

  • Gate Equivalents (GE): Hardware area measure. 1 GE ≈ area of a 2-input NAND gate. Critical for hardware footprint.

  • Energy Consumption: Joules/bit or μJ/operation. Critical for battery life.

  • RAM/ROM Footprint: Bytes of memory used for code (ROM) and data (RAM). Critical for microcontrollers.

  • Cycle Count: Number of clock cycles for a full encryption. Critical for software speed.

[!TIP] Exam Question: "What does an 'operation' mean?" → Answer: "It is the basic computational step (e.g., gate delay, instruction cycle) used to measure a cipher's efficiency in hardware or software."