5  Security Properties & Practices

Prerequisites: E5: Key Renewal

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

5.1 Learning Objectives

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

• Map Security Properties to Encryption Levels: Explain 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

In 60 Seconds

Cryptographic security properties — confidentiality, integrity, authenticity, and non-repudiation — define exactly what protection a cryptographic scheme provides and what attacks it resists.

For Beginners: Security Properties & Practices

This hands-on chapter lets you practice cryptographic techniques for IoT security. Think of it as a locksmith training course – you learn to work with encryption tools, set up secure channels, and test your implementations in a safe environment before applying them to real systems.

Sensor Squad: The Five-Level Security Shield!

“We have learned about E1 through E5 – now let us see how they all work together!” Max the Microcontroller said, drawing a big chart. “Each encryption level provides different security properties, and together they create a complete shield.”

Sammy the Sensor pointed to the chart. “E1 at the link layer gives us access control – only authorized devices can join the network. E2 at the device-to-gateway level adds authentication – the gateway knows exactly which device sent each message. E3 gives us end-to-end confidentiality – even untrusted gateways cannot peek at our data.”

“E4 adds data integrity and freshness,” Lila the LED continued. “Integrity means nobody tampered with the data. Freshness means the data is current, not a replayed old message. And E5 with asymmetric encryption gives us non-repudiation – a device cannot deny that it sent a message, because only its private key could have created the signature.”

“The best practice is defense in depth – use multiple levels together,” Bella the Battery summarized. “E1 keeps outsiders away. E2 gives per-device accountability. E3 protects data end-to-end. E4 ensures nothing was changed. E5 manages key rotation. Each level covers a different threat. No single level is enough on its own, but together they create a security shield that is incredibly hard to break through!”

How It Works: Security Properties Mapping to E1-E5

Understanding how each encryption layer provides specific security properties:

1. Access Control (E1): Link-layer AES-128 shared key prevents unauthorized devices from joining the network—only devices with the key can transmit valid frames
2. Authentication (E2, E5): E2 uses per-device symmetric keys with HMAC to verify message origin; E5 uses asymmetric private keys and digital signatures for stronger identity proof
3. Data Integrity (E2): HMAC/CMAC message authentication codes combined with sequence numbers detect tampering and prevent packet reordering
4. Confidentiality (E1-E4): Multi-layer encryption ensures data remains secret even if one layer is compromised—defense in depth
5. Freshness (E2): Sequence numbers and timestamps prevent replay attacks—gateway rejects old packets
6. Non-Repudiation (E5): Digital signatures (RSA or ECC) provide legal proof of message origin—sender cannot deny sending signed messages

Each security property maps to specific cryptographic mechanisms at specific layers. No single layer provides all properties - defense-in-depth requires multiple layers working together.

5.2 Security Properties Achieved

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

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

5.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

5.2.2 Authentication

Mechanism: Per-device keys (E2) and digital signatures (E5)

• E2: Each device has a unique symmetric key; HMAC proves the message originated from a known device
• E5: Asymmetric key pairs enable digital signatures—server stores public keys and verifies signatures
• Combined approach prevents spoofing: E2 for lightweight per-packet authentication, E5 for strong identity proof

5.2.3 Data Integrity

Mechanism: HMAC/CMAC authentication codes (E2)

• HMAC-SHA-256 or AES-CMAC verify content has not been altered
• Detects both intentional tampering and accidental corruption
• Sequence numbers prevent packet reordering and insertion
• Combined with encryption prevents modification of ciphertext

5.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

5.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

5.2.6 Non-Repudiation

Mechanism: Digital signatures—RSA or ECC (E5)

• Legal proof of message origin that third parties can verify
• Sender cannot deny sending a signed message
• ECC (ECDSA) preferred for IoT due to smaller key sizes and lower computation
• Important for sensitive sensor data and regulatory compliance

Layered 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.

5.3 Encryption Tradeoffs

Tradeoff: 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.

Tradeoff: 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.

5.4 Common Pitfalls

Common 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

5.5 Worked Example: Smart Home Hub Security Architecture

5.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.

Step 1: Classify Data and Threats

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

Step 2: Design Encryption Layers

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.

Step 3: Handle Constrained Resources

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

Step 4: Implement Replay Protection

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

Step 5: Key Management Design

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

Final Result

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

Putting Numbers to It: Multi-Layer Encryption Cascade Cost

Cumulative encryption overhead for E1-E5 defense-in-depth

\[\text{Total Overhead} = \sum_{i=1}^{5} \text{Overhead}_i\]

Working through an example:

Given: 64-byte sensor payload through full E1+E2+E3+E4+E5 stack

Step 1: E1 link-layer (AES-128-CCM, 8-byte MIC) \[\text{E1 Packet} = 64 + 13 \text{ (nonce)} + 8 \text{ (MIC)} = 85 \text{ bytes}\]

Step 2: E2 device-gateway (AES-256-GCM, 16-byte tag) \[\text{E2 Packet} = 85 + 12 \text{ (nonce)} + 16 \text{ (tag)} + 4 \text{ (seq)} = 117 \text{ bytes}\]

Step 3: E3 device-cloud (nested encryption, nonce derived from E2 sequence number, +16-byte GCM tag) \[\text{E3 Packet} = 117 + 16 = 133 \text{ bytes}\]

Step 4: E4 TLS record (5-byte header + 16-byte tag) \[\text{E4 Packet} = 133 + 5 + 16 = 154 \text{ bytes}\]

Step 5: E5 signature metadata (not per-packet, amortized cost: 0) \[\text{E5 Overhead} = 0 \text{ bytes}\]

\[\text{Total Packet} = 154 \text{ bytes}\]

\[\text{Total Overhead} = \frac{154 - 64}{64} \times 100 = 140.6\%\]

Result: Full E1-E5 encryption stack adds 140% overhead (90 bytes of security headers for 64 bytes of payload), but provides defense-in-depth against all major attack vectors.

In practice: Over LoRaWAN (51-byte application payload limit at EU868 DR0), full E1-E5 stack is impossible—must choose 2-3 layers based on threat model. Over cellular (1500-byte MTU), overhead is acceptable. Security architecture must match available bandwidth.

viewof payloadSize = Inputs.range([8, 256], {value: 64, step: 8, label: "Payload size (bytes)"})

viewof enableE1 = Inputs.toggle({label: "E1: Link Layer (AES-128-CCM)", value: true})

viewof enableE2 = Inputs.toggle({label: "E2: Device-Gateway (AES-256-GCM)", value: true})

viewof enableE3 = Inputs.toggle({label: "E3: Device-Cloud (nested GCM)", value: true})

viewof enableE4 = Inputs.toggle({label: "E4: TLS 1.3 Record", value: true})

encryptionOverheadCalc = {
  let size = payloadSize;
  const layers = [];
  let current = size;

  if (enableE1) {
    const e1 = current + 13 + 8;
    layers.push({name: "E1 (AES-128-CCM)", added: "13-byte nonce + 8-byte MIC", bytes: e1, overhead: e1 - current});
    current = e1;
  }
  if (enableE2) {
    const e2 = current + 12 + 16 + 4;
    layers.push({name: "E2 (AES-256-GCM)", added: "12-byte nonce + 16-byte tag + 4-byte seq", bytes: e2, overhead: e2 - current});
    current = e2;
  }
  if (enableE3) {
    const e3 = current + 16;
    layers.push({name: "E3 (nested GCM)", added: "16-byte tag (nonce derived)", bytes: e3, overhead: e3 - current});
    current = e3;
  }
  if (enableE4) {
    const e4 = current + 5 + 16;
    layers.push({name: "E4 (TLS 1.3)", added: "5-byte header + 16-byte tag", bytes: e4, overhead: e4 - current});
    current = e4;
  }

  const totalOverhead = current - size;
  const pct = ((totalOverhead / size) * 100).toFixed(1);
  const fitsLoRaWAN = current <= 51;
  const fitsCellular = current <= 1500;

  let rows = layers.map(l => `<tr><td>${l.name}</td><td>${l.added}</td><td>+${l.overhead} bytes</td><td>${l.bytes} bytes</td></tr>`).join("");

  return html`<div style="border-left: 4px solid #3498DB; padding: 12px 16px; margin: 16px 0; background: #f8f9fa; border-radius: 0 4px 4px 0;">
    <strong>Multi-Layer Encryption Overhead Calculator</strong>
    <table style="width:100%; margin-top:8px; border-collapse:collapse; font-size:0.9em;">
      <thead><tr style="border-bottom:2px solid #3498DB;">
        <th style="text-align:left; padding:4px;">Layer</th>
        <th style="text-align:left; padding:4px;">Added Fields</th>
        <th style="text-align:left; padding:4px;">Overhead</th>
        <th style="text-align:left; padding:4px;">Cumulative</th>
      </tr></thead>
      <tbody>
        <tr><td>Payload</td><td>---</td><td>---</td><td>${size} bytes</td></tr>
        ${rows}
      </tbody>
    </table>
    <p style="margin-top:8px;"><strong>Total packet:</strong> ${current} bytes | <strong>Overhead:</strong> ${totalOverhead} bytes (${pct}%)</p>
    <p style="margin:4px 0;">
      <span style="color: ${fitsLoRaWAN ? '#16A085' : '#E74C3C'};">${fitsLoRaWAN ? '✓' : '✗'} LoRaWAN EU868 DR0 (51-byte limit)</span> |
      <span style="color: ${fitsCellular ? '#16A085' : '#E74C3C'};">${fitsCellular ? '✓' : '✗'} Cellular (1500-byte MTU)</span>
    </p>
  </div>`;
}

Concept Relationships

Concept	Builds On	Enables	Related To
Access Control	E1 link-layer encryption	Network membership control	WPA2, Zigbee network keys
Authentication	Asymmetric cryptography	Device identity verification	E2/E5 private keys, PKI
Data Integrity	Hash functions (SHA-256)	Tamper detection	E2 checksums, sequence numbers
Confidentiality	Multi-layer encryption	Defense-in-depth protection	E1-E4 layers, hybrid encryption
Freshness	Timestamps, sequence numbers	Replay attack prevention	E2 nonces, smart meter security
Non-Repudiation	Digital signatures (RSA/ECC)	Legal proof of origin	E5 signatures, audit trails

Key Dependencies: Each security property requires specific cryptographic mechanisms. Access control uses shared keys. Authentication uses private keys. Integrity uses hashes. Confidentiality uses encryption. Freshness uses counters. Non-repudiation uses signatures. Complete IoT security requires all six properties working together across E1-E5 layers.

Label the Diagram

💻 Code Challenge

Order the Steps

:

5.7 What’s Next

If you want to…	Read this
Learn algorithms that provide these properties	Symmetric Encryption
Understand asymmetric algorithms and signatures	Asymmetric Encryption
Study TLS security properties in practice	TLS and DTLS for IoT
Explore cryptography in the full architecture	Encryption Architecture & Levels

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

Related Chapters

5.8 Visual Reference Gallery

AI-Generated Visual: AES Encryption Process

Figure 5.2: AES Encryption Process - Block cipher transformations for IoT data protection

AI-Generated Visual: Asymmetric Encryption Architecture

Figure 5.3: Asymmetric Encryption - Public/private key cryptography for IoT

AI-Generated Visual: DTLS Handshake Protocol

Figure 5.4: DTLS Handshake - Secure datagram transport for constrained IoT devices

5.9 Alternative Source Figures

Academic Resource: Edinburgh IoT Security - Symmetric Encryption Model

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

Academic Resource: Edinburgh IoT Security - Asymmetric (Public Key) Encryption

Asymmetric encryption using public and private key pairs

Original Source Figure: Complete Security Scheme (Alternative View)

Complete IoT security scheme

🔗 Match the Concepts