1434  E5: Key Renewal and Asymmetric Cryptography

Prerequisites: E3-E4: Transport and End-to-End Encryption

This enables: Security Properties and Best Practices | Cyber Security Methods

1434.1 Learning Objectives

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

• Implement E5 Key Renewal: Design periodic key refresh using asymmetric encryption
• Compare RSA vs ECC: Select appropriate algorithms based on device constraints and security requirements
• Calculate Cryptographic Performance: Analyze TLS handshake time, energy consumption, and fleet throughput
• Design Key Rotation Strategies: Implement automated key lifecycle management for long-term deployments

1434.2 E5: Key Renewal with Asymmetric Encryption

Time: ~12 min | Level: Advanced | Unit: P11.C08.U06

Figure 1434.1: Key renewal process (E5)

Purpose: Periodically refresh symmetric keys using asymmetric encryption.

Characteristics:

• RSA public/private key pairs
• Asymmetric encryption for key exchange
• Authentication and non-repudiation
• Returns to AES for data encryption (performance)

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
sequenceDiagram
    participant Device as IoT Device<br/>(RSA Key Pair)
    participant Server as Key Server<br/>(RSA Key Pair)

    Note over Device,Server: E5: Periodic Key Renewal

    Device->>Server: Public Key (PubD)
    Server->>Device: Public Key (PubS)

    Note over Server: Generate New<br/>AES-256 Key

    Server->>Server: Encrypt Key<br/>with PubD
    Server->>Server: Sign with<br/>PrivS

    Server->>Device: Encrypted Key<br/>+ Signature

    Device->>Device: Verify Signature<br/>with PubS
    Device->>Device: Decrypt Key<br/>with PrivD

    Note over Device,Server: Both now have<br/>new AES key

    Device->>Server: Acknowledge<br/>(encrypted with new AES key)

    Note over Device,Server: Switch to new key<br/>for E1/E2/E3 encryption

Figure 1434.2: E5 asymmetric key renewal workflow showing server generating new AES session key, encrypting with device RSA public key, signing with server private key for authentication

1434.2.1 E5 Implementation Details

Algorithm: RSA-2048 or ECC P-256 for key exchange + digital signatures

Key Renewal Process:

Step	Actor	Action	Purpose
1	Device/Server	Generate RSA/ECC key pairs	One-time setup during provisioning
2	Both	Exchange public keys	Establish trust relationship
3	Server	Generate new AES-256 session key	Create fresh symmetric key
4	Server	Encrypt AES key with device’s public key	Secure key transport
5	Server	Sign encrypted key with server private key	Prove authenticity
6	Device	Verify signature with server public key	Authenticate sender
7	Device	Decrypt AES key with device private key	Recover session key
8	Device	Send acknowledgment encrypted with new AES key	Confirm receipt
9	Both	Switch to new AES key for E1/E2/E3	Activate new encryption

Asymmetric Algorithms Comparison:

Algorithm	Key Size	Security Level	Speed	IoT Suitability
RSA-2048	2048 bits	112-bit security	Slow	High power consumption
RSA-3072	3072 bits	128-bit security	Very slow	Too heavy for constrained devices
ECC P-256	256 bits	128-bit security	Fast	Recommended for IoT
ECC P-384	384 bits	192-bit security	Moderate	High-security IoT
Ed25519	256 bits	128-bit security	Very fast	Best for signatures

1434.2.2 Why Use Asymmetric Encryption for Key Renewal?

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
graph TB
    subgraph Symmetric["Symmetric Key Distribution Problem"]
        S1[Need new AES key]
        S2[How to send it securely?]
        S3[Need encryption to send key...]
        S4[Chicken-and-egg problem!]
        S1 --> S2 --> S3 --> S4
    end

    subgraph Asymmetric["Asymmetric Key Solution"]
        A1[Generate new AES key]
        A2[Encrypt with public key<br/>Anyone can encrypt]
        A3[Only device can decrypt<br/>Private key needed]
        A4[New AES key securely delivered!]
        A1 --> A2 --> A3 --> A4
    end

    style Symmetric fill:#F8D7DA,stroke:#E74C3C,stroke-width:2px
    style Asymmetric fill:#D4F4DD,stroke:#16A085,stroke-width:2px

Figure 1434.3: Comparison showing symmetric encryption requires secure pre-shared channel to distribute keys (chicken-egg problem), while asymmetric encryption allows public key distribution over insecure channels

Security Properties:

• Authentication: RSA/ECC signatures prove key origin
• Non-Repudiation: Server cannot deny sending key (legal proof)
• Forward Secrecy: Compromised old key doesn’t reveal past sessions
• No Pre-Shared Secret: Public keys can be distributed openly
• Performance: Asymmetric crypto is 100-1000x slower than AES

Best Practice:

Use asymmetric encryption (E5) only for key exchange, then switch to symmetric encryption (AES) for bulk data. This hybrid approach combines the security of RSA/ECC with the speed of AES—exactly how TLS and most secure protocols work.

questionModule = await import("https://ngcharithperera.github.io/iotclass/assets/js/inline-knowledge-checks.js")

InlineKnowledgeCheck6 = {
  const question = {
    id: "encrypt_arch_key_rotation_strategy",
    question: "Your fleet of 10,000 industrial IoT sensors uses AES-256 for E2 encryption with static keys provisioned during manufacturing. The devices operate for 10 years without firmware updates. An attacker compromises one device after 5 years, extracting its AES key. They've been passively capturing all network traffic since deployment. What is the FULL blast radius of this compromise?",
    options: [
      "The attacker can decrypt only that device's traffic going forward---they cannot decrypt past traffic because AES-256 provides perfect forward secrecy",
      "The attacker can decrypt that device's past and future traffic (5 years captured + 5 years remaining), but other devices remain secure because each has unique E2 keys",
      "The attacker can decrypt all 10,000 devices' traffic because manufacturing-provisioned keys are typically batch-shared across production runs to simplify provisioning",
      "The attacker can decrypt nothing---hardware security modules (HSMs) prevent key extraction even with physical device access and debug interfaces"
    ],
    correctIndex: 1,
    difficulty: "advanced",
    feedback: {
      correct: "Correct! This demonstrates why E5 (Key Rotation) is critical for long-term deployments. With static keys, the attacker can decrypt ALL 5 years of captured traffic retroactively and continue monitoring for the remaining 5 years. However, because you implemented E2 with unique per-device keys, the compromise is limited to ONE device. **Key rotation (E5) would limit the blast radius** to just the rotation period (e.g., 1 year instead of 10).",
      incorrect: "Not quite. AES-256 does NOT provide forward secrecy---that requires ephemeral key exchange (ECDHE). With static keys, all past captured traffic can be decrypted. The question states E2 with unique per-device keys, so one compromise doesn't expose the fleet. The correct answer is **Option B**. E5 would further limit exposure to just the current rotation period."
    }
  };
  return questionModule.createMultipleChoiceWidget(question);
}

1434.3 Key Rotation Strategies and Schedules

NoteDeep Dive: Key Rotation Implementation

Effective key rotation prevents long-term key compromise while minimizing operational overhead.

Rotation schedule recommendations:

Key Type	Rotation Period	Rationale
Link keys (E1)	Never / On compromise	Changing affects all devices
Device keys (E2)	Annually or on compromise	Balance security vs complexity
Session keys (E3/E4)	Per connection or daily	Forward secrecy
Master keys (E5)	Bi-annually	Certificate validity periods

Automated key rotation implementation:

import time
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.kdf.hkdf import HKDF

class KeyRotationManager:
    """
    Manages key lifecycle for IoT deployment.
    Supports scheduled rotation and emergency re-keying.
    """
    def __init__(self, device_id: str, key_server_url: str):
        self.device_id = device_id
        self.key_server = key_server_url
        self.current_key = None
        self.key_generation = 0
        self.key_valid_until = 0
        self.rotation_interval = 86400 * 90  # 90 days

    async def check_rotation_needed(self) -> bool:
        """Check if key rotation is due."""
        if self.current_key is None:
            return True

        # Time-based rotation
        if time.time() > self.key_valid_until:
            return True

        # Usage-based rotation (e.g., after N encryptions)
        if self.encryption_count > 1_000_000:
            return True

        return False

    async def rotate_key(self):
        """
        Perform key rotation using E5 asymmetric exchange.
        """
        # Step 1: Generate ephemeral ECDH key pair
        private_key = ec.generate_private_key(ec.SECP256R1())
        public_key = private_key.public_key()

        # Step 2: Request new key from server
        response = await self.key_server.request_key_rotation(
            device_id=self.device_id,
            device_public_key=public_key.public_bytes(...),
            current_generation=self.key_generation
        )

        # Step 3: Derive shared secret using ECDH
        server_public_key = load_public_key(response['server_public_key'])
        shared_secret = private_key.exchange(ec.ECDH(), server_public_key)

        # Step 4: Derive new symmetric key using HKDF
        hkdf = HKDF(
            algorithm=hashes.SHA256(),
            length=32,  # 256-bit AES key
            salt=response['salt'],
            info=b'iot-session-key-v1'
        )
        new_key = hkdf.derive(shared_secret)

        # Step 5: Verify key transition
        if await self.verify_new_key(new_key, response['verification_token']):
            self.transition_to_new_key(new_key)

    def transition_to_new_key(self, new_key: bytes):
        """Atomic key transition with overlap period."""
        # Keep old key valid for grace period (handles in-flight messages)
        self.previous_key = self.current_key
        self.previous_key_expiry = time.time() + 300  # 5 minute overlap

        # Activate new key
        self.current_key = new_key
        self.key_generation += 1
        self.key_valid_until = time.time() + self.rotation_interval
        self.encryption_count = 0

Compliance requirements:

Standard	Key Rotation Requirement
PCI-DSS	Annually minimum, on compromise
HIPAA	Risk-based, document rationale
NIST 800-57	Based on key type and algorithm
IEC 62443	Zone-specific, documented policy

1434.4 Worked Example: TLS Handshake Performance Analysis

NoteReal-World Problem: Smart Meter Fleet Registration

This worked example demonstrates how encryption algorithm choice impacts large-scale IoT deployments, particularly during device provisioning and registration.

Context: A utility company is deploying 10,000 smart meters that must register with their cloud platform using TLS mutual authentication. Each device must complete a full TLS handshake to establish secure communication.

Given:

Parameter	Value
Device MCU	ARM Cortex-M4 @ 80 MHz
RSA-2048 signature verification	200 ms on MCU
ECDSA-256 signature verification	50 ms on MCU
RSA-2048 key generation	30 seconds on MCU
ECDSA-256 key generation	500 ms on MCU
Power during crypto operations	50 mW
Network round-trip time	50 ms

Problem: Compare RSA-2048 vs ECDSA-256 for device registration. Calculate handshake time, energy consumption, and fleet registration throughput.

---

1434.4.1 Step 1: Single Device Handshake Time Analysis

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
gantt
    title TLS Handshake Timing Comparison
    dateFormat X
    axisFormat %L ms

    section RSA-2048
    ClientHello to ServerHello (network)    :rsa1, 0, 50
    Server Certificate Verify              :rsa2, after rsa1, 200
    Key Exchange                           :rsa3, after rsa2, 100

    section ECDSA-256
    ClientHello to ServerHello (network)    :ecc1, 0, 50
    Server Certificate Verify              :ecc2, after ecc1, 50
    Key Exchange (ECDHE)                   :ecc3, after ecc2, 30

Figure 1434.4: TLS handshake timing comparison showing RSA-2048 taking 350ms total versus ECDSA-256 taking 130ms total

RSA-2048 Handshake Breakdown:

\[T_{RSA} = T_{network} + T_{verify} + T_{keyex}\]

\[T_{RSA} = 50\text{ ms} + 200\text{ ms} + 100\text{ ms} = 350\text{ ms}\]

ECDSA-256 Handshake Breakdown:

\[T_{ECDSA} = T_{network} + T_{verify} + T_{keyex}\]

\[T_{ECDSA} = 50\text{ ms} + 50\text{ ms} + 30\text{ ms} = 130\text{ ms}\]

Speedup Factor:

\[\text{Speedup} = \frac{T_{RSA}}{T_{ECDSA}} = \frac{350\text{ ms}}{130\text{ ms}} = 2.69\times\]

---

1434.4.2 Step 2: Energy Consumption per Handshake

Energy equals power multiplied by time. With MCU consuming 50 mW during cryptographic operations:

RSA-2048 Energy:

\[E_{RSA} = P \times T_{RSA} = 50\text{ mW} \times 350\text{ ms} = 17.5\text{ mJ}\]

ECDSA-256 Energy:

\[E_{ECDSA} = P \times T_{ECDSA} = 50\text{ mW} \times 130\text{ ms} = 6.5\text{ mJ}\]

Energy Savings with ECC:

\[\text{Savings} = \frac{E_{RSA} - E_{ECDSA}}{E_{RSA}} \times 100\% = \frac{17.5 - 6.5}{17.5} \times 100\% = 62.9\%\]

ImportantBattery Impact

For a battery-powered smart meter with 2,400 mAh @ 3.3V (28.5 kJ total capacity):

• RSA: 28,500 J / 0.0175 J = 1.63 million handshakes before battery depletion
• ECDSA: 28,500 J / 0.0065 J = 4.38 million handshakes before battery depletion

ECDSA enables 2.7x more reconnection events over device lifetime!

---

1434.4.3 Step 3: Fleet Registration Throughput

For the utility company registering 10,000 devices:

\[\text{Throughput}_{RSA} = \frac{3600\text{ s}}{0.35\text{ s/device}} = 10,286\text{ devices/hour}\]

\[\text{Throughput}_{ECDSA} = \frac{3600\text{ s}}{0.13\text{ s/device}} = 27,692\text{ devices/hour}\]

Time to Register 10,000 Device Fleet:

\[T_{fleet,RSA} = \frac{10,000}{10,286} = 0.97\text{ hours} \approx 58\text{ minutes}\]

\[T_{fleet,ECDSA} = \frac{10,000}{27,692} = 0.36\text{ hours} \approx 22\text{ minutes}\]

---

1434.4.4 Final Answer Summary

Metric	RSA-2048	ECDSA-256	Improvement
Handshake time	350 ms	130 ms	2.7x faster
Energy per handshake	17.5 mJ	6.5 mJ	63% less energy
Fleet registration (10K)	58 minutes	22 minutes	2.7x faster
Public key size	256 bytes	32 bytes	8x smaller
Security level	112-bit	128-bit	ECC is stronger

TipKey Insight: ECC is Strongly Preferred for Constrained IoT

ECDSA-256 (or Ed25519) should be the default choice for IoT device authentication:

1. Faster: 2.7x faster handshakes improve user experience
2. Energy Efficient: 63% less energy extends battery life
3. Smaller Keys: 8x smaller certificates reduce storage and bandwidth
4. Better Security: 128-bit security (ECC-256) exceeds 112-bit (RSA-2048)

When to Use RSA: Only if legacy infrastructure requires RSA, or for root CA certificates.

1434.5 Hash Collision Probability Calculator

NoteUnderstanding Hash Collisions and the Birthday Paradox

Hash functions are critical for IoT firmware verification, password storage, and message authentication (HMAC). Understanding collision probability helps you select appropriate hash sizes for your security requirements.

The Birthday Paradox: In a room of just 23 people, there’s a 50% chance two share a birthday. With 365 days available, this seems counterintuitive—but it’s a fundamental property of randomness that affects cryptographic hash security.

viewof hashBits = Inputs.select([64, 128, 160, 224, 256, 384, 512], {
  value: 256,
  label: "Hash Output Size (bits)"
})

viewof numItems = Inputs.range([1, 10000000000], {
  value: 1000000,
  step: 1,
  label: "Number of Items to Hash (e.g., firmware updates, messages)"
})

viewof hashAlgorithm = Inputs.select(
  ["MD5 (128-bit)", "SHA-1 (160-bit)", "SHA-256 (256-bit)", "SHA-384 (384-bit)", "SHA-512 (512-bit)", "SHA3-256 (256-bit)"],
  {value: "SHA-256 (256-bit)", label: "Hash Algorithm"}
)

collisionData = {
  const bits = hashBits;
  const n = numItems;

  // Birthday paradox approximation: P(collision) = 1 - e^(-n^2/(2*H))
  const hashSpace = Math.pow(2, bits);

  const exponent = -(n * n) / (2 * hashSpace);
  const collisionProbability = 1 - Math.exp(exponent);
  const collisionPercent = collisionProbability * 100;

  // How many items needed for 50% collision probability
  const items50Percent = Math.sqrt(2 * hashSpace * Math.log(2));

  // Security classification
  let securityLevel = "";
  let recommendation = "";

  if (bits < 128) {
    securityLevel = "Inadequate";
    recommendation = "Hash is too short - collisions are feasible. DO NOT USE for security.";
  } else if (bits < 256) {
    if (collisionProbability > 1e-10) {
      securityLevel = "Moderate";
      recommendation = "Collision risk exists at scale. Consider SHA-256 or larger.";
    } else {
      securityLevel = "Good";
      recommendation = "Acceptable for most IoT applications.";
    }
  } else {
    securityLevel = "Excellent";
    recommendation = "Collision probability is negligible - suitable for all IoT security applications.";
  }

  // Algorithm-specific warnings
  let algorithmWarning = "";
  if (hashAlgorithm.includes("MD5")) {
    algorithmWarning = "MD5 is cryptographically broken - collisions can be generated in seconds. Never use for security!";
  } else if (hashAlgorithm.includes("SHA-1")) {
    algorithmWarning = "SHA-1 is deprecated - practical collision attacks exist (Google SHAttered, 2017). Migrate to SHA-256.";
  }

  return {
    bits,
    numItems: n,
    hashSpace,
    collisionProbability,
    collisionPercent,
    items50Percent,
    securityLevel,
    recommendation,
    algorithmWarning
  };
}

md`### Hash Collision Probability Analysis

**Configuration:**
- **Hash Algorithm**: ${hashAlgorithm}
- **Hash Size**: ${collisionData.bits} bits
- **Items Hashed**: ${collisionData.numItems.toLocaleString()}

**Collision Risk:**

| Metric | Value |
|:-------|:------|
| **Probability of Collision** | ${collisionData.collisionPercent < 1e-10 ? collisionData.collisionProbability.toExponential(4) : collisionData.collisionPercent.toFixed(10)}% |
| **Security Level** | ${collisionData.securityLevel} |
| **Items for 50% Collision** | ${collisionData.items50Percent < 1e10 ? collisionData.items50Percent.toExponential(2) : "~2^" + (collisionData.bits/2).toFixed(0)} items |

**Recommendation**: ${collisionData.recommendation}

${collisionData.algorithmWarning ? "**CRITICAL WARNING:** " + collisionData.algorithmWarning : ""}
`

Use Cases by Hash Size:

Hash Size	Security Level	Suitable For	Attack Resistance
64-bit	Inadequate	Checksums only (CRC32)	Collisions trivial
128-bit	Weak	Non-security uses	Birthday attack feasible
160-bit	Deprecated	Legacy systems (SHA-1)	Broken (SHAttered 2017)
256-bit	Standard	Firmware verification, HMAC	Secure for decades
384-bit	High Security	Government, defense	Post-quantum resistant
512-bit	Maximum	Ultra-high security	Overkill for most IoT

InlineKnowledgeCheck7 = {
  const question = {
    id: "encrypt_arch_pki_certificate_authority",
    question: "Your company deploys 50,000 smart meters using X.509 certificates for TLS authentication. Each meter has a device certificate signed by your intermediate CA, which is signed by a trusted root CA. An attacker compromises your intermediate CA's private key. What is the immediate security impact, and what is your BEST mitigation response?",
    options: [
      "Impact: Minimal---the root CA's private key is still secure. Response: Rotate the intermediate CA at next scheduled maintenance",
      "Impact: Catastrophic---attacker can generate valid certificates for any device. Response: Immediately revoke the intermediate CA using CRL/OCSP, deploy new intermediate CA, and re-issue all 50,000 device certificates",
      "Impact: Moderate---attacker can only generate new certificates, but cannot decrypt past TLS sessions. Response: Revoke intermediate CA and add compromised certificate serial numbers to CRL",
      "Impact: Limited to new device onboarding---existing device certificates remain valid. Response: Issue new intermediate CA for future deployments"
    ],
    correctIndex: 1,
    difficulty: "advanced",
    feedback: {
      correct: "Exactly right! This is a PKI nightmare scenario. With the intermediate CA private key compromised, the attacker can generate valid certificates for ANY device. Your existing 50,000 certificates are now untrusted. **Immediate response required**: 1) Revoke the compromised intermediate CA via CRL/OCSP, 2) Deploy a new intermediate CA signed by root, 3) Re-issue all 50,000 device certificates. This is extremely disruptive but unavoidable.",
      incorrect: "Not quite. A compromised intermediate CA is catastrophic---the attacker can issue unlimited valid certificates. Existing certificates become untrusted because they were issued by a compromised CA. The correct answer is **Option B**: full fleet re-certification is required."
    }
  };
  return questionModule.createMultipleChoiceWidget(question);
}

1434.6 Summary

This chapter covered E5 key renewal and asymmetric cryptography:

• E5 Purpose: Periodic refresh of symmetric keys using asymmetric encryption (RSA/ECC) for long-term security
• Hybrid Approach: Use asymmetric crypto for key exchange, symmetric crypto for bulk data (how TLS works)
• ECC Advantages: 2.7x faster, 63% less energy, 8x smaller keys than RSA-2048 with equal or better security
• Key Rotation: Implement automated rotation schedules based on key type and compliance requirements
• Hash Selection: Use SHA-256 minimum for security applications; avoid MD5 and SHA-1

1434.7 What’s Next

Continue to Security Properties and Best Practices to understand how all five encryption levels (E1-E5) work together to provide defense-in-depth security, and learn how to design comprehensive encryption architectures for real-world IoT deployments.

NoteRelated Chapters

• E3-E4: Transport and End-to-End - TLS configuration
• Security Properties - Defense-in-depth strategies
• Encryption Principles - Cryptographic fundamentals
• Cyber Security Methods - Authentication using encryption