1437  Security Properties and Best Practices

Prerequisites: E5: Key Renewal

This enables: Cyber Security Methods | Zero-Trust Security | Threat Modeling

1437.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Map Security Properties to Encryption Levels: Understand which E1-E5 level provides each security property
  • Design Defense-in-Depth Architectures: Combine multiple encryption layers for comprehensive protection
  • Evaluate Encryption Tradeoffs: Make informed decisions about symmetric vs asymmetric, per-device vs shared keys
  • Apply Best Practices: Implement comprehensive encryption for real-world IoT deployments

1437.2 Security Properties Achieved

The five-level encryption architecture addresses common IoT security requirements:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
graph TB
    subgraph Properties["Security Properties"]
        Access[Access Control<br/>Privacy]
        Auth[Authentication]
        Integrity[Data Integrity]
        Confid[Confidentiality]
        Fresh[Data Freshness]
        NonRep[Non-Repudiation]
    end

    subgraph Mechanisms["Encryption Mechanisms"]
        E1[E1: Link Layer<br/>AES-128 Shared Key]
        E2[E2: Device-Gateway<br/>AES-256 Unique Keys]
        E3[E3: Device-Cloud<br/>End-to-End AES-256]
        E4[E4: Gateway-Cloud<br/>TLS/SSL Certificates]
        E5[E5: Key Renewal<br/>RSA Signatures]
    end

    E1 -->|Provides| Access
    E1 -->|Provides| Confid
    E2 -->|Provides| Auth
    E2 -->|Provides| Integrity
    E2 -->|Provides| Fresh
    E3 -->|Provides| Confid
    E4 -->|Provides| Confid
    E4 -->|Provides| Auth
    E5 -->|Provides| Auth
    E5 -->|Provides| NonRep

    style Properties fill:#E6F2FF,stroke:#2C3E50,stroke-width:2px
    style Mechanisms fill:#D4F4DD,stroke:#16A085,stroke-width:2px

Figure 1437.1: Security properties matrix showing how E1 through E5 encryption levels provide access control, authentication, data integrity, confidentiality, freshness, and non-repudiation

1437.2.1 Access Control (Privacy)

Mechanism: AES-128 at link layer (E1)

  • Only nodes with shared key can access network routing
  • Unknown nodes rejected at first hop
  • Hardware implementation in radio (no MCU interrupt)
  • Preserves energy by not waking MCU for invalid packets

1437.2.2 Authentication

Mechanism: Private keys (E2, E5)

  • Each device has unique key pair
  • Server stores all device public keys
  • Signature verification proves origin
  • Prevents spoofing attacks

1437.2.3 Data Integrity

Mechanism: Hash algorithms (E2)

  • SHA-256 checksums verify content
  • Detects tampering or corruption
  • Sequence numbers prevent reordering
  • Combined with encryption prevents modification

1437.2.4 Data Confidentiality

Mechanism: Multi-layer encryption (E1-E4)

  • E1: Network-level protection
  • E2/E3: End-to-end protection
  • E4: Transport security
  • Defense in depth approach

1437.2.5 Data Freshness

Mechanism: Sequence numbers and timestamps (E2)

  • Each packet has unique seed
  • Prevents replay attacks
  • Gateway filters duplicate packets
  • Time-based validity windows

1437.2.6 Non-Repudiation

Mechanism: RSA signatures (E5)

  • Legal proof of message origin
  • Cannot deny sending signed message
  • Important for sensitive sensor data
  • Regulatory compliance support
TipLayered Encryption: Defense in Depth

The five-level encryption architecture demonstrates defense in depth—if one layer is compromised, others still provide protection:

  • E1 fails (shared key leaked): E2 still protects individual device data
  • E2 fails (device key extracted): E1 prevents network access by unauthorized nodes
  • E3 fails (cloud encryption broken): E1+E2 protect in-network communications
  • E4 fails (TLS vulnerability): E1-E3 still encrypt the underlying data

Best practice: Always implement multiple encryption layers. Single-layer encryption is a single point of failure—one compromise exposes everything.

1437.3 Encryption Tradeoffs

TipTradeoff: Symmetric vs Asymmetric Encryption for IoT

Decision context: When selecting encryption for IoT device communications, data storage, or key exchange mechanisms.

Factor Symmetric (AES) Asymmetric (RSA/ECC)
Speed 100-1000x faster Computationally intensive
Key Management Pre-shared keys required Public key can be freely distributed
Memory Footprint 256-512 bytes for AES 2-8 KB for RSA; 512 bytes for ECC
Power Consumption ~10 uJ per operation ~1000 uJ per RSA operation
Forward Secrecy Not inherent (requires key rotation) Achievable with ephemeral keys (ECDHE)
Authentication No inherent identity proof Digital signatures prove identity

Choose Symmetric Encryption when:

  • Processing high-volume data on constrained devices (sensors, actuators)
  • Battery life is critical and encryption frequency is high
  • Keys can be securely pre-provisioned during manufacturing
  • Real-time performance is required (sub-millisecond latency)

Choose Asymmetric Encryption when:

  • Establishing initial secure channels between unknown parties
  • Key exchange is needed without pre-shared secrets
  • Digital signatures are required for non-repudiation
  • Device identity verification or certificate-based authentication is needed

Default recommendation: Use hybrid approach - asymmetric encryption (ECC preferred for IoT) for key exchange and authentication, then symmetric encryption (AES-128/256) for bulk data protection.

TipTradeoff: Per-Device Keys vs Shared Network Keys

Decision context: When provisioning encryption keys for an IoT deployment, you must decide between unique keys per device or shared keys across device groups.

Factor Per-Device Keys Shared Network Keys
Provisioning Complexity High (unique key per device) Low (one key for all devices)
Compromise Blast Radius One device only All devices using that key
Key Storage Scales with device count Constant regardless of scale
Device Authentication Implicit (key proves identity) Requires additional identity mechanism
Key Rotation Complex (update each device) Simpler (update once, propagate)
Manufacturing Integration Requires secure provisioning line Standard production process
Revocation Granular (revoke single device) All-or-nothing

Choose Per-Device Keys when:

  • Deployment scale exceeds 100 devices (blast radius becomes significant)
  • Device compromise is realistic (public locations, physical access possible)
  • Regulatory requirements mandate device-level accountability
  • Devices have secure elements or TPMs for key protection
  • Long deployment lifespan (10+ years) where some devices will be compromised

Choose Shared Network Keys when:

  • Small, controlled deployment (<50 devices in secured facility)
  • All devices are physically secured against tampering
  • Rapid deployment is prioritized over security granularity
  • Budget constraints prevent secure provisioning infrastructure
  • Prototyping or proof-of-concept before production security

Default recommendation: Always use per-device keys in production deployments. Modern IoT platforms (AWS IoT, Azure IoT Hub) provide automated per-device key provisioning.

1437.4 Common Pitfalls

WarningCommon Pitfalls in Encryption Architecture

1. Relying on Link Layer Encryption Alone (E1)

  • Mistake: Assuming that enabling Zigbee or Wi-Fi encryption (E1) is sufficient
  • Why it happens: Link layer encryption is “on by default” giving false sense of security
  • Solution: Implement defense-in-depth with multiple layers. In 2017, KRACK demonstrated WPA2 (E1) vulnerabilities could expose traffic

2. Using Shared Network Keys Across All Devices

  • Mistake: Deploying the same encryption key to thousands of IoT devices
  • Why it happens: Per-device keys seem operationally complex
  • Solution: Implement unique per-device keys with automated provisioning. The 2020 Philips Hue vulnerability showed how a single Zigbee key could unlock entire networks

3. Skipping E5 Key Rotation Due to “Perfect Forward Secrecy”

  • Mistake: Assuming ECDHE in TLS provides permanent protection without key renewal
  • Why it happens: PFS protects past sessions if long-term keys are compromised
  • Solution: Implement scheduled key rotation. Best practice: rotate session keys daily, device identity keys annually

1437.5 Worked Example: Smart Home Hub Security Architecture

1437.6 Worked Example: Designing Encryption for a Smart Home Hub

Scenario: You are designing the security architecture for a smart home hub that connects to 50+ devices: smart locks, cameras, thermostats, and sensors. The hub has a Cortex-M4 processor (168 MHz, 256 KB RAM, 1 MB flash), runs on mains power, and connects to a cloud platform via Wi-Fi.

Goal: Design a multi-layer encryption architecture (E1-E5) that protects different data types appropriately.

Data classification:

Data Type Sensitivity Confidentiality Integrity Availability
Lock commands Critical High Critical High
Camera video High High Medium Medium
Temperature readings Low Low Medium Low
Device state (on/off) Medium Medium Medium High
User credentials Critical Critical Critical Medium
Firmware images High Medium Critical Low

Threat model:

Threat Attack Vector Impact Likelihood
Eavesdropping Sniff Wi-Fi/Zigbee Privacy breach, lock codes exposed High
Replay attack Capture and replay lock command Unauthorized entry Medium
Man-in-middle Intercept cloud connection Command injection Medium
Key extraction Physical access to hub Full system compromise Low

Layer assignments:

Layer Implementation Protects Algorithms
E1 (Link) Zigbee network key Local device-to-hub AES-128-CCM (Zigbee 3.0)
E2 (Device-Hub) Per-device keys Individual device secrets AES-128-GCM + sequence numbers
E3 (Device-Cloud) Not used - Hub terminates all connections
E4 (Hub-Cloud) TLS 1.3 Cloud communication ECDHE-P256 + AES-128-GCM
E5 (Key Renewal) Certificate-based Long-term security ECDSA-P256, 90-day rotation

Why E3 is skipped: The hub acts as a trusted gateway. End-to-end encryption from sensors to cloud would require more capable sensors and prevent local automation.

Computational budget analysis:

Operation Time (Cortex-M4) Per-Second Capacity
AES-128-GCM (128 bytes) 0.15 ms 6,600 blocks
ECDSA-P256 verify 25 ms 40 signatures
ECDHE key exchange 50 ms 20 key agreements
SHA-256 (1 KB) 0.5 ms 2,000 hashes

Optimization decisions:

Challenge Solution Impact
TLS handshake latency Session resumption (PSK) 50ms to 5ms for repeat connections
Camera video encryption AES-CTR (parallelizable) 30% faster than GCM for video
Battery device overhead Integrity-only option 50% less computation for sensors

Lock command security (defense in depth):

# Lock command structure (48 bytes total)
lock_command = {
    "device_id": "lock-001",      # 12 bytes
    "action": "unlock",            # 1 byte
    "sequence": 847291,            # 4 bytes (monotonic)
    "timestamp": 1704825600,       # 4 bytes (Unix time)
    "nonce": "a7b9c2d4e5f6",       # 12 bytes (from challenge)
    "user_id": "user-42",          # 8 bytes
    "hmac": "..."                  # 16 bytes (AES-CMAC)
}

def validate_lock_command(cmd, expected_nonce, last_seq):
    # Check sequence number (replay)
    if cmd.sequence <= last_seq:
        raise ReplayError("Sequence too old")

    # Check timestamp (stale command)
    if abs(time.now() - cmd.timestamp) > 2:
        raise StaleError("Command expired")

    # Check nonce (man-in-middle)
    if cmd.nonce != expected_nonce:
        raise AuthError("Invalid challenge response")

    # Verify HMAC (integrity + authentication)
    if not verify_hmac(cmd, device_key):
        raise AuthError("HMAC verification failed")

    return True

Key hierarchy:

Master Key (in secure element)
+-- Hub Identity Key (ECDSA-P256, permanent)
|   +-- Used for: Device attestation, cloud authentication
+-- Cloud Session Keys (AES-128, derived per connection)
|   +-- Used for: TLS 1.3 traffic protection
+-- Device Group Keys (AES-128, per device type)
|   +-- Used for: Broadcast commands to all locks, all lights
+-- Per-Device Keys (AES-128, unique per device)
    +-- Used for: Individual device commands and responses

Rotation schedule:

Key Type Rotation Period Trigger
Cloud TLS session 1 hour Time-based
Device session keys 24 hours Time-based
Hub identity certificate 2 years Certificate expiry
Compromised device key Immediate Manual revocation

Key decisions made and why:

Decision Choice Rationale
E3 (end-to-end) Not implemented Hub acts as trusted gateway; avoids sensor complexity
Cipher suite AES-128-GCM Hardware acceleration available, 128-bit sufficient
Lock protection Sequence + timestamp + nonce Triple defense against replay
Key storage Secure element for master Hardware protection prevents extraction

Quantified security posture:

  • Eavesdropping protection: All sensitive data encrypted (E1 + E2 + E4)
  • Replay attack window: 2 seconds maximum for lock commands
  • Key extraction difficulty: Secure element requires $10K+ attack
  • Firmware integrity: ECDSA signature verification on all updates
  • Computational overhead: < 5% CPU for typical traffic

1437.7 Summary

This chapter covered security properties and best practices:

  • Six Security Properties: Access control, authentication, data integrity, confidentiality, freshness, and non-repudiation each mapped to specific encryption levels (E1-E5)
  • Defense in Depth: Multiple encryption layers ensure that compromise of any single layer doesn’t expose the entire system
  • Symmetric vs Asymmetric: Use hybrid approach—asymmetric for key exchange, symmetric for bulk data
  • Per-Device vs Shared Keys: Always use per-device keys in production to limit blast radius of compromise
  • Threat-Model-Driven: Security decisions should be based on actual threat landscape, not checkboxes

1437.8 Knowledge Check

Answer the questions below. Each explanation targets a common misconception.

Question 1: At which layer does TLS/SSL primarily provide encryption?

TLS sits between applications and transport (e.g., TCP), securing the transport channel. Application payload formats are still an application concern, but TLS provides the encrypted tunnel.

Question 2: What distinguishes end-to-end encryption from hop-by-hop transport encryption?

With end-to-end encryption, only the communicating endpoints can decrypt the data; gateways, brokers, and proxies can forward traffic but can’t read the protected payload.

Question 3: If you don’t trust the gateway operator and want the payload to stay confidential end-to-end, which level best matches that goal?

E3 is the “untrusted gateway” case: the device encrypts to the cloud (or cloud key material), so the gateway can route traffic but cannot decrypt the application payload.

1437.9 What’s Next

You have completed the Encryption Architecture series. Continue your security journey with:

1437.11 Alternative Source Figures

Diagram showing symmetric encryption flow where sender transmits plaintext through encryption algorithm using encryption key to produce ciphertext, which travels over channel where interceptor can observe but not decrypt

Symmetric encryption process showing sender, encryption algorithm, ciphertext transmission with interceptor threat, decryption algorithm, and receiver

Source: University of Edinburgh - IoT Systems Security Course

Public key encryption diagram showing sender encrypting unencrypted message with receiver's public key to produce encrypted ciphertext, transmission over network, then receiver using their private key to decrypt

Asymmetric encryption using public and private key pairs

Source: University of Edinburgh - IoT Systems Security Course

Complete five-level IoT encryption architecture showing E1 link layer, E2 device-to-gateway, E3 device-to-cloud, E4 gateway-to-cloud TLS, and E5 asymmetric key renewal working together for defense-in-depth protection

Complete IoT security scheme

Source: CP IoT System Design Guide, Chapter 6 - Security and Privacy