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

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

1.0 Introduction & Motivation for Lightweight Cryptography

Definition & Scope:

Lightweight cryptography refers to cryptographic primitives (ciphers, hashes) designed for extremely limited resources—minimal gate count, energy, memory, and power consumption.

Resource-Constrained Environments:

• Internet of Things (IoT) sensors, RFID tags, embedded systems, wireless sensor networks (WSNs).

• Primary Constraints:

  • Computational power (slow CPUs, 8/16-bit microcontrollers)

  • Energy consumption (battery-powered, energy-harvesting)

  • Memory/storage (RAM: 100s of bytes, ROM: 1000s of bytes)

  • Bandwidth (low data rates)

  • Cost (per-unit cost sensitivity)

Why Traditional Cryptography is Unsuitable:

• AES: Requires ~10k-40k gates, 128-bit block, 10+ rounds—high latency/energy for tiny devices.

• RSA/ECC: Asymmetric operations are computationally heavy (modular exponentiation, point multiplication); ECC-256 requires ~10k-100k cycles on 8-bit MCU.

• SHA-256: Large internal state (256-bit) and many rounds increase memory and energy use.

[!TIP] Exam Focus: Be ready to list at least two specific constraints (e.g., gate count, energy per byte) and two traditional algorithms (AES, RSA) with reasons for their unsuitability.

Role in Database Security Context:

Secures data at rest and in transit in IoT/edge database systems where sensors/actuators generate/consume data that feeds into larger database systems. Ensures confidentiality/integrity from device to cloud/edge database.

2.0 Symmetric Key Primitives: Block Ciphers

2.1 Design Philosophies & Strategies

• Core Goals: Minimize gate count (hardware), RAM/ROM footprint, energy/bit, latency.

• Key Trade-off: Security vs. Efficiency.

  • Smaller block/key sizes (e.g., 64-bit block vs. 128-bit) reduce state but increase birthday bound collision risk.

  • Reduced rounds lower latency but may weaken security margin.

• Architectural Choices:

  • Bit-oriented vs. Byte-oriented: Bit-oriented (PRESENT) cheaper on 8-bit MCUs; byte-oriented (CLEFIA) efficient on 32-bit.

  • ARX (Add-Rotate-XOR) vs. S-Box based: ARX (SIMON) uses simple operations, no look-up tables; S-Box based provides strong non-linearity but needs memory.

  • Feistel vs. SPN: Feistel (CLEFIA) allows smaller implementation (half-block processing); SPN (PRESENT) often more parallelizable.

• Key Schedule Optimization: Simple, low-cost key schedule (e.g., PRESENT uses constant rotations and S-Box) vs. complex, security-focused (AES).

2.2 Comparison with Traditional Block Cipher Design (AES)

Security Implications of Simplifications:

• Smaller block size → birthday paradox collision after ~$$\displaystyle 2^{32} $$ blocks (vs. $$\displaystyle 2^{64} $$ for 128-bit).

• Reduced rounds → smaller security margin against differential/linear attacks.

• Simple key schedule → potential related-key attacks.

2.3 Analysis of Specific Lightweight Block Ciphers

• PRESENT:

  • 64-bit block, 80/128-bit key, 31-round SPN.

  • 4-bit S-Box (8 entries), 4-bit permutation layer.

  • Design Goal: Extremely low gate count (~1k GE) for hardware (RFID).

  • Trade-off: High round count (31) compensates for small S-Box.

• CLEFIA:

  • 128-bit block, 128/192/256-bit key, Feistel structure.

  • Variable rounds: 18 (128-bit key) to 24 (256-bit).

  • Uses two 8-bit S-Boxes and a 4x4 MDS matrix.

  • Design Goal: Balance efficiency and security; suitable for both hardware/software.

• DESL / DESXL:

  • Lightweight variants of DES.

  • Reduced rounds (DESL: 12 rounds vs. DES 16), larger key (DESXL: 184-bit).

  • Use larger S-Boxes or multiple S-Boxes per round to boost security.

2.4 Internal Components: The Substitution Box (S-Box)

• Function: Primary non-linear confusion layer in SPN ciphers. Resists linear and differential cryptanalysis.

• Design Criteria for Lightweight S-Boxes:

  1. Low Implementation Cost: Small size (4-bit), minimal logic gates or simple ROM.

  2. Cryptographic Strength: High non-linearity, low differential uniformity (max. probability ≤ $$\displaystyle 2^{-2} $$ for 4-bit), balanced output.

  3. Resistance to Attacks: No fixed points, no opposite points.

• Examples:

  • PRESENT S-Box: 4-bit, 8-entry, optimized for low gate count.

  • SIMON: Uses ARX, no S-Box; non-linearity from AND operations.

[!TIP] Common Pitfall: Remember that a "good" S-Box for lightweight crypto balances implementation cost (gate count) with cryptographic strength (non-linearity metrics). Don't just copy AES's S-Box—it's too heavy.

3.0 Modes of Operation for Lightweight Block Ciphers

Purpose: Extend block cipher to encrypt data > block size, provide confidentiality/authenticity, handle partial blocks.

Common Modes & Suitability:

Lightweight-Specific Considerations:

• Minimize State: CTR mode only needs counter + nonce; CBC needs full previous ciphertext.

• Avoid Padding: CTR and CFB handle partial blocks natively.

• Low Latency: CTR allows pre-computation of keystream blocks.

• Example: PRESENT-CTR is standardized in ISO/IEC 29192-2.

[!TIP] Exam Answer Template: For "example mode used with lightweight ciphers," state: "CTR mode is often preferred. It turns the block cipher into a stream cipher, allowing parallel encryption/decryption, random access to ciphertext blocks, and no padding requirement—critical for constrained devices with small buffers."

4.0 Stream Ciphers in Constrained Environments

Fundamental Operation: Generates a pseudorandom keystream $$\displaystyle z_i $$ from a secret internal state. Ciphertext: $$\displaystyle c_i = m_i \oplus z_i $$.

• Synchronous: Keystream independent of plaintext/ciphertext.

• Self-synchronizing: Keystream depends on previous ciphertext (e.g., CFB).

Design Goals: Minimal internal state size (e.g., 64-128 bits), simple update function, fast throughput.

Vulnerability: Birthday Attack & State Collisions

• Principle: After generating $\approx \sqrt{N}$ keystream bits (where $$\displaystyle N = 2^{\text{state size}} $$), collisions in internal state become likely (birthday paradox).

• Impact: If state size = 64 bits, collision expected after $$\displaystyle 2^{32} $$ bits (~512 MB). Attacker can recover state or predict future keystream.

• Small State Risk: Many lightweight stream ciphers (e.g., early Grain variants) had 80-bit state → vulnerable to state recovery attacks with $$\displaystyle 2^{40} $$ complexity.

Design Optimizations to Resist Attacks:

1. Sufficiently Large State: Ensure state size ≥ 128 bits for long-term security ($$\displaystyle 2^{64} $$ effort).

2. Robust Key/IV Setup: Strong initialization mixing to avoid weak keys.

3. Periodic Re-seeding: Refresh state from a master key after limited keystream output (e.g., $$\displaystyle 2^{40} $$ bits).

4. Non-linear Filter Functions: Combine multiple LFSRs with non-linear Boolean functions to thwart correlation attacks.

[!TIP] Key Formula: Birthday bound collision probability ≈ $$\displaystyle 1 - e^{-k(k-1)/(2N)} \approx k^2/(2N) $$ for $k$ outputs and $N$ state space. For security, require $k \ll \sqrt{N}$.

5.0 Cryptographic Hash Functions for Lightweight Applications

Purpose: Data integrity, message authentication (HMAC), digital signatures, key derivation (KDF).

Design Constraints:

• Small digest size (e.g., 128-bit vs. 256-bit) to reduce output transmission/storage.

• Low memory footprint (small internal state).

• Fast computation on 8/16-bit MCUs.

• Often based on sponge or permutation constructions.

Examples of Lightweight Hash Functions:

• PHOTON: Sponge-based, 256-bit state, supports 80-256-bit digests. Uses AES-like S-Box but optimized.

• SPONGENT: Variant of Keccak with reduced rounds and state size (e.g., 88-bit state for 80-bit security).

• Quark: Ultra-lightweight, 64-bit state, designed for RFID (e.g., 112-bit security with 448 cycles/byte).

Real-World Applications (Database Security Context):

1. RFID Tag Authentication: Hash-based challenge-response to verify tag identity before allowing database access.

2. Lightweight HMAC for Sensor Networks: Ensures integrity of sensor readings sent to edge database (e.g., HMAC-PHOTON).

3. Key Derivation: Derive session keys from a master key for constrained device-to-gateway communication.

6.0 Key Management for Lightweight Cryptography

6.1 Core Concept & Challenges

• Definition: Secure generation, distribution, storage, rotation, destruction of cryptographic keys.

• Specific Challenges:

  • Secure Storage: Limited secure memory (e.g., no TPM); keys often stored in plain flash.

  • Secure Establishment: High-cost asymmetric operations (ECC) may be prohibitive; need low-overhead protocols.

  • Scalability: Large IoT networks (1000s of nodes) require efficient group key management.

6.2 Centralized vs. Distributed Key Management

6.3 Symmetric Key Management Integration

• Used in lightweight group key management for IoT.

• Mechanisms:

  • Key Tree (LKH): Logical key hierarchy; re-keying cost $O(\log n)$ per join/leave.

  • Key Graph: More flexible topology; re-keying cost depends on graph structure.

  • Pre-shared Key Matrices: Each node stores $O(\sqrt{n})$ keys for $n$-node group; join/leave cost $O(1)$.

6.4 Group Key Management for IoT: Key Considerations

When evaluating a new protocol, assess:

1. Communication Overhead: Messages count and size (critical for low-bandwidth).

2. Computational Cost: Per-node cost for join/leave (e.g., number of encryptions, hash ops).

3. Memory Requirements: Key state storage per node (keys, key tree nodes).

4. Forward Secrecy: Compromised node cannot decrypt past group communications.

5. Backward Secrecy: New member cannot decrypt past group communications.

6. Compromise Resilience: Impact of capturing one/multiple nodes.

7. Scalability: Performance degradation with group size $n$.

6.5 Integration into Standard Protocols (IPSec / TLS)

• Adapting Handshakes: Replace RSA/ECDHE with lightweight ECC (e.g., Curve25519) or pre-shared keys (PSK).

• Lightweight Cipher Suites: Use PRESENT-CTR or SIMON-128/256 instead of AES-GCM.

• Session Resumption: Use abbreviated handshakes (session tickets/IDs) to avoid full key exchange.

• Gateway/Translator Role: Constrained devices communicate with a gateway that terminates full TLS and speaks lightweight protocol to device. Gateway acts as protocol converter and security mediator.

[!TIP] Exam Answer Structure for Integration: "For constrained devices, TLS can be adapted by: (1) Using ECC with small curves (Curve25519) for key exchange, (2) Selecting lightweight cipher suites (PRESENT-CTR), (3) Employing session resumption to reduce handshake cost, and (4) Deploying a gateway that bridges between lightweight and standard TLS."

7.0 Foundational Security & Implementation Considerations

7.1 Critical Role of Open Design and Public Scrutiny

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

$$\boxed{\text{Security} = f(\text{Key}) \text{ not } f(\text{Algorithm})}$$

• Importance of Cryptanalysis: Widespread review discovers flaws (e.g., related-key attacks on PRESENT, weak keys in Grain).

• Balancing Act: Open design invites attacks on specific constrained implementations (side-channel), but secrecy only delays inevitable discovery.

7.2 Threat Model Differences: Tiny Devices vs. Traditional Computers

7.3 Symmetric vs. Asymmetric Cryptography in Constrained Settings

• Symmetric (Block/Stream/Hash): Same key for encryption/decryption. Primary choice for data encryption/authentication due to low cost (e.g., PRESENT, PHOTON).

• Asymmetric (ECC/RSA): Different keys (public/private). Used sparingly for key establishment/authentication due to high cost (ECC point multiplication ~10k-100k cycles). Often offloaded to gateway.

7.4 Understanding "Operation" in a Computational Context

• Definition: A basic atomic action performed by a processor (e.g., bitwise AND/OR/XOR, addition, rotation, table lookup, memory access).

• Relevance: Cost of lightweight algorithms measured in:

  • Gate Equivalents (GE): Hardware area.

  • CPU Cycles: Software execution time.

  • Energy per Operation: e.g., pJ/op for specific instructions.

• Example: PRESENT's round function ≈ 100-200 8-bit MCU cycles; AES-128 ≈ 1000-2000 cycles.

[!TIP] Final Reminder: In exams, always link concepts back to the database security context—e.g., key management ensures secure data access from IoT devices to the database; lightweight hashes verify sensor data integrity before database insertion.