12  Encryption and the Key Hierarchy

In 60 Seconds

BLE encryption uses AES-CCM with 128-bit keys, but security depends on how keys are generated during pairing. The key hierarchy flows from Temporary Key to Short Term Key to Long Term Key, with IRK for address privacy and CSRK for data signing. Match pairing method to data sensitivity: “Just Works” for public data only, Numeric Comparison for personal data, Out-of-Band for medical or financial applications.

Quick Check: Bluetooth Security Boundary

12.1 Minimum Viable Understanding

BLE encryption uses AES-CCM with 128-bit keys, but the real security depends on how those keys are generated during pairing. The key hierarchy flows from Temporary Key (TK) to Short Term Key (STK) to Long Term Key (LTK), with IRK for address privacy and CSRK for data signing. Always match your pairing method to data sensitivity: “Just Works” for public data only, Numeric Comparison for personal data, and Out-of-Band (OOB) for medical, financial, or industrial applications.

12.2 Learning Objectives

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

• Explain BLE Encryption Architecture: Describe how AES-CCM-128 encryption and key generation methods work together in BLE
• Analyze Key Hierarchy: Distinguish the roles of LTK, IRK, and CSRK in BLE security and justify when each is applied
• Apply Security Decision Framework: Select appropriate security levels for different IoT application contexts
• Implement Best Practices: Configure secure pairing and key storage for IoT deployments

For Beginners: Bluetooth Encryption and Keys

Bluetooth encryption protects data by scrambling it so that only devices with the right key can read it. Think of encryption keys as the secret decoder ring that two devices share during pairing. Without the key, intercepted Bluetooth data looks like random noise to an eavesdropper.

BLE Key Management Pattern

Treat BLE security as a key lifecycle problem, not just an encryption switch.

• Pairing chooses how trustworthy the generated keys are.
• Encryption protects traffic only after the link has agreed on keys.
• Bonding stores long-term keys so devices can reconnect without repeating pairing.
• IRK supports privacy by resolving rotating private addresses for bonded devices.
• CSRK supports signed data on unencrypted links, but it does not replace encryption for sensitive traffic.
• Stored keys need protection, revocation, and re-authentication policies for high-risk commands.

12.3 Prerequisites

Before diving into this chapter, you should be familiar with:

• Bluetooth Security: Pairing Methods: Understanding BLE pairing process and method comparison
• Basic Cryptography Concepts: Familiarity with AES encryption and key exchange (ECDH)

12.4 BLE Encryption Architecture

BLE supports multiple encryption architectures depending on the pairing method and Bluetooth version. The diagram below shows the key generation process for Legacy Pairing, LE Secure Connections, and BR/EDR Secure Connections.

Figure 12.1: Source: University of Edinburgh IoT Security Course

Key Generation Methods:

• LE Legacy: Uses s1(AES-128) with TK, Mrand, and Srand. This provides basic protection but can be vulnerable if the temporary key has low entropy or the pairing exchange is captured.
• LE Secure Connections: Uses f5(AES-CMAC-128) with DHKey, nonces, and device addresses. P-256 ECDH protects the pairing exchange against passive eavesdropping.
• BR/EDR Secure Connections: Uses h6 and h7 based on AES-CMAC-128 to derive cross-transport keys from the BR/EDR link key and salt material.

12.5 BLE Key Hierarchy

Understanding the BLE key hierarchy is essential for implementing secure IoT applications:

Figure 12.2: BLE Encryption Key Hierarchy and Management

Key Types Explained:

• TK (Temporary Key): Generated during pairing, depends on pairing method
• STK (Short Term Key): Session encryption key derived from TK using the s1 function with AES-128; used only for the initial encrypted session in legacy pairing, then replaced
• LTK (Long Term Key): 128-bit key stored after bonding; enables reconnection without re-pairing. In legacy pairing, identified by the EDIV (Encrypted Diversifier) and Rand (64-bit random number) values
• IRK (Identity Resolving Key): Enables private address resolution for privacy; allows a bonded device to resolve resolvable private addresses back to the known identity
• CSRK (Connection Signature Resolving Key): Signs unencrypted data packets to verify integrity and authenticity over unencrypted LE links
• DHKey: In LE Secure Connections (BLE 4.2+), the Diffie-Hellman shared secret computed from P-256 ECDH; the basis for deriving MacKey and LTK via the f5 function

12.5.1 Knowledge Check: BLE Key Roles

12.6 Security Decision Framework

12.6.1 Choosing the Right BLE Security Level

Use “Just Works” ONLY when:

• Public beacon data (no sensitive information)
• Read-only sensor broadcasting (weather station)
• Device has no display, keyboard, or NFC
• Data is already encrypted at application layer
• Example: Public temperature beacon in park
• Risk acceptance: Anyone can read data (that’s the intent)

Use Passkey Entry when:

• Device has display OR keyboard (not both)
• Static PIN acceptable (e.g., printed on device)
• Moderate security sufficient
• Example: Wireless keyboard (displays 6-digit PIN)
• Security: 1 million possible PINs (secure if random)
• Weakness: Static PIN vulnerable if observed

Use Numeric Comparison when:

• Both devices have displays
• User can verify 6-digit code
• High security required
• Example: Smartphone pairing with tablet
• Security: 1 million codes + visual verification (prevents MITM)
• Best for: Consumer IoT (phones, smartwatches, tablets)

Use Out-of-Band (OOB) when:

• Maximum security required
• Device has NFC or can display QR code
• Medical, financial, or industrial applications
• Example: Payment terminal with NFC
• Security: Attacker must compromise both channels (Bluetooth + NFC/QR)
• Best for: Smart locks, medical devices, payment systems

12.6.2 Security Method Comparison

• Just Works: Provides no user-authenticated verification and no MITM protection. Use it only when the data is public or already protected above the BLE link.
• Passkey Entry: A 6-digit passkey gives about 20 bits of user-authenticated entropy when the passkey is random and protected from observation.
• Numeric Comparison: Both users verify the same displayed code, giving strong MITM protection when users actually compare the values.
• Out of Band (OOB): Moves the pairing secret to a separate channel such as NFC or QR. Security depends on that channel being hard for the attacker to observe or modify.

Numbers explained:

• 0 bits (Just Works): No user-authenticated verification - vulnerable to active MITM during pairing
• ~20 bits (6-digit PIN): About 1,000,000 possibilities - treat as modest entropy
• OOB: Security depends on the out-of-band channel and the secret you exchange

Putting Numbers to It

The brute-force attack time against a passkey depends on entropy and attack rate:

\[T_{attack} = \frac{2^{entropy}}{R_{attempts}} \times 0.5\]

where \(R_{attempts}\) is the number of pairing attempts per second (factor 0.5 assumes average case).

Example: A 6-digit PIN (000000-999999) provides: - Entropy: \(\log_2(1,000,000) = 19.93\) bits - If attacker attempts 10 pairings/second: \(T_{attack} = \frac{2^{19.93}}{10} \times 0.5 = \frac{1,000,000}{10} \times 0.5 = 50,000\) seconds ≈ 13.9 hours

For LE Secure Connections with rate limiting (1 attempt per 30 seconds after 3 failures): - Effective rate: 0.033 attempts/second - \(T_{attack} = \frac{1,000,000}{0.033} \times 0.5 \approx 15,000,000\) seconds ≈ 174 days

Rate limiting transforms a short practical attack window into a much longer one. Production BLE devices should implement retry delays and lockout behavior for repeated failed pairing attempts.

Interactive: BLE Brute-Force Attack Time Calculator

Adjust PIN length and rate limiting to see how they affect brute-force attack duration.

viewof pinDigits = Inputs.range([4, 8], {
  value: 6,
  step: 1,
  label: "PIN Digits"
})

viewof maxAttempts = Inputs.range([1, 10], {
  value: 3,
  step: 1,
  label: "Attempts Before Lockout"
})

viewof lockoutSeconds = Inputs.range([10, 300], {
  value: 60,
  step: 10,
  label: "Lockout Duration (seconds)"
})

viewof attemptSpeed = Inputs.range([0.5, 5], {
  value: 1,
  step: 0.5,
  label: "Seconds per Attempt"
})

{
  const totalCombinations = Math.pow(10, pinDigits);
  const avgToGuess = totalCombinations / 2;

  // Without rate limiting
  const unlimitedTime = avgToGuess * attemptSpeed;
  const unlimitedDays = unlimitedTime / 86400;

  // With rate limiting
  const cycleTime = (maxAttempts * attemptSpeed) + lockoutSeconds;
  const cycles = avgToGuess / maxAttempts;
  const limitedTime = cycles * cycleTime;
  const limitedDays = limitedTime / 86400;

  const slowdownFactor = (limitedTime / unlimitedTime).toFixed(1);

  const color1 = "#2C3E50";
  const colorLimited = limitedDays > 100 ? "#16A085" : limitedDays > 30 ? "#E67E22" : "#E74C3C";
  const colorUnlimited = unlimitedDays > 100 ? "#16A085" : unlimitedDays > 30 ? "#E67E22" : "#E74C3C";

  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 1.2rem; font-family: Arial, sans-serif;">
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 1rem; margin-bottom: 1rem;">
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${color1};">
        <div style="font-size: 0.85rem; color: #666;">Total Combinations</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${color1};">${totalCombinations.toLocaleString()}</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${colorUnlimited};">
        <div style="font-size: 0.85rem; color: #666;">Without Rate Limiting</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${colorUnlimited};">${unlimitedDays < 1 ? (unlimitedTime / 3600).toFixed(1) + " hours" : unlimitedDays.toFixed(1) + " days"}</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${colorLimited};">
        <div style="font-size: 0.85rem; color: #666;">With Rate Limiting</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${colorLimited};">${limitedDays < 1 ? (limitedTime / 3600).toFixed(1) + " hours" : limitedDays > 365 ? (limitedDays / 365).toFixed(1) + " years" : limitedDays.toFixed(0) + " days"}</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid #16A085;">
        <div style="font-size: 0.85rem; color: #666;">Slowdown Factor</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: #16A085;">${slowdownFactor}x</div>
      </div>
    </div>
    <div style="font-size: 0.8rem; color: #666;">Rate limiting (${maxAttempts} attempts then ${lockoutSeconds}s lockout) slows brute-force by ${slowdownFactor}x. A ${pinDigits}-digit PIN has ${totalCombinations.toLocaleString()} combinations.</div>
  </div>`;
}

12.6.3 Security Selection Decision Tree

Figure 12.3: BLE Security Method Selection Decision Tree

12.6.4 Security Decision Matrix

• Public data: Link encryption may be optional when the information is intentionally public. Sign data if integrity matters.
• Personal data: Use AES-CCM link encryption, LE Secure Connections, bonding, and privacy addresses.
• Medical or safety data: Use authenticated pairing such as Numeric Comparison or OOB, protect firmware updates, and establish a strong device identity.
• Financial or high-value data: Prefer OOB pairing where possible, hardened key storage, and application-layer authentication and authorization.
• Industrial control data: Add application-layer integrity checks, logging, and lifecycle key management on top of link-layer encryption.

Note: Compliance requirements vary by jurisdiction and product. Link-layer encryption is important, but it is not sufficient on its own for most regulated systems.

12.7 Best Practices

Do:

• Pair in a controlled environment when the device protects sensitive data.
• Use Numeric Comparison or OOB when the device capability and risk model allow it.
• Store bonded keys in the strongest available platform keystore or secure element.
• Update firmware regularly and protect update packages with signatures.
• Remove unused pairings and provide a clear revocation path.

Don’t:

• Use “Just Works” for sensitive data.
• Pair unknown devices into a trusted fleet.
• Assume short radio range is a security boundary.

12.8 Common Pitfalls

Pitfall: Using “Just Works” Pairing Because the Device Has No Display

The Mistake: Implementing “Just Works” pairing for displayless IoT devices (sensors, beacons, smart plugs) because “there’s no way to show a PIN,” leaving devices permanently vulnerable to MITM attacks during every pairing attempt.

Why It Happens: Developers assume display-based verification (Numeric Comparison, Passkey) is the only option for secure pairing.

The Fix: Use Out-of-Band (OOB) pairing with a physical channel that attackers cannot intercept:

Figure 12.4: OOB pairing options for displayless BLE devices

Pitfall: Assuming Bonded Keys Are Secure Forever After Initial Pairing

The Mistake: Pairing a BLE device once with strong security (Numeric Comparison or OOB), then assuming the bonded connection is permanently secure - without protecting stored keys or implementing re-authentication for sensitive operations.

Why It Happens: Developers focus security effort on the initial pairing ceremony, but forget that Long Term Keys (LTK) stored in flash memory can be extracted, cloned, or used by anyone with physical access to either device.

The Fix: Implement defense-in-depth beyond pairing: protect key storage, add application-layer authorization, and consider periodic re-authentication:

• Secure key storage: Use a hardware-backed keystore or secure element when available. Avoid storing LTK, IRK, or CSRK in ordinary application flash without access controls.
• Command authorization: Treat low-risk reads differently from high-risk actions. A sensor read may only require an encrypted BLE link, while an unlock, dose, reset, or firmware update should require recent user authorization or a physical confirmation.
• Time-bounded trust: Require re-authentication for sensitive commands after a short timeout rather than trusting an old bonded session indefinitely.
• Revocation: Implement “forget this device” so both sides delete bonded keys. For managed fleets, support admin revocation when phones, tablets, or gateways are lost.
• Auditability: Log pairing, bonding, revocation, and sensitive-command events so security incidents can be investigated.

12.9 Understanding Checks

Understanding Check: Smart Lock Security Breach

Scenario: A startup launches a Bluetooth smart lock for Airbnb hosts. During beta testing, security researchers demonstrate they can unlock any door during the initial pairing process by sitting in a car 20 meters away with a laptop. The lock uses “Just Works” pairing for “convenience” - no PIN entry required.

Think about:

1. How can an attacker unlock the door without physical access?
2. What specific vulnerability in “Just Works” pairing enables this attack?
3. The lock has AES-128 encryption AFTER pairing - why doesn’t that prevent the attack?
4. How would you redesign the lock’s security?

Key Insight: Authentication happens BEFORE encryption. “Just Works” provides:

• No user-authenticated verification step during pairing
• No protection against active MITM or pairing hijack during setup
• Link encryption does not help if the attacker becomes the paired/bonded device

Secure redesign options:

• Numeric Comparison: require the installer to confirm a code shown by the lock and the phone
• OOB commissioning: use an internal QR code / NFC tap so physical access is required to enroll
• Application-layer authorization: even after pairing, require explicit authorization for “unlock” commands

Understanding Check: Bonding vs. Pairing Trade-offs

Scenario: You’re managing a fleet of 100 Bluetooth-connected medical devices (insulin pumps) in a hospital. Nurses complain that re-pairing tablets to pumps every shift change (3x/day) wastes 5 minutes per device. IT Security insists that bonding is disabled because “stored keys are a security risk if tablets are lost or stolen.”

Think about:

1. What’s the actual security difference between pairing-only and bonding?
2. How much time is wasted without bonding? (100 devices x 3 shifts x 5 min)
3. Can you implement bonding securely with proper key management?
4. What’s the risk if a bonded tablet is stolen?

Key Insight: Bonding = convenience vs. security trade-off, but can be mitigated:

With Bonding (SECURE implementation):

• Pair once, but store keys using a hardware/OS-backed keystore (when available)
• Require user authentication (PIN/biometric) before high-risk actions
• Support revocation (remove bonds when a tablet is lost) and remote wipe
• Consider a periodic re-authentication policy based on your risk model
• Log pairing/connection events for auditability

Figure 12.5: Secure BLE bonding implementation workflow

Understanding Check: Weak PIN Attack Vector

Scenario: A device uses LE Legacy pairing and relies on a short, printed passkey/PIN (“unique per device”) for security. The team assumes “it’s encrypted, so it’s safe.”

Think about:

1. Why does low-entropy user input (e.g., a 4-6 digit passkey) matter?
2. Why can Legacy pairing be risky if an attacker records the pairing transcript?
3. What changes when you use LE Secure Connections?
4. Beyond pairing, what authorization checks should still exist for safety-critical commands?

Key Insight: Strong ciphers don’t help if key agreement/authentication is weak.

Risk framing (order-of-magnitude):

• 4-digit PIN: 10,000 guesses
• 6-digit passkey: 1,000,000 guesses (approximately 20 bits)

Safer alternatives:

1. Prefer LE Secure Connections with Numeric Comparison or OOB when possible
2. Avoid static/shared passkeys; treat printed codes as a usability step, not a long-term secret
3. Add application-layer authorization (e.g., signed “unlock” commands, role checks) even after pairing
4. Plan for revocation (remove bonds when devices are replaced/lost)

12.9.1 Knowledge Check: BLE Key Hierarchy

12.9.2 Knowledge Check: BLE Security Levels

12.9.3 Knowledge Check: LE Secure Connections

12.10 Worked Example: Quantifying BLE Pairing Attack Surfaces

Scenario: Choosing Pairing Security for a Smart Insulin Pump

A medical device manufacturer is designing a BLE-connected insulin pump. The pump communicates with a companion smartphone app to receive bolus dose commands. The design team must choose the appropriate BLE security level.

Threat Analysis – What Happens If Pairing is Compromised?

An attacker who performs a MITM during pairing becomes the bonded device. They can then issue insulin dose commands. This is a life-safety risk.

Quantifying Attack Windows by Pairing Method:

• Just Works: The risk is active MITM or pairing hijack during the setup window because there is no user-authenticated check.
• Passkey with Legacy pairing: The risk is a captured pairing exchange combined with low-entropy passkey material.
• Numeric Comparison: The risk shifts from cryptographic guessing to user verification failure or social engineering.
• OOB using NFC or QR: The attacker must compromise the out-of-band channel as well as the BLE exchange, which materially raises the bar.

Why OOB + Application-Layer Auth is the Right Answer:

1. OOB pairing via NFC: The nurse taps the pump to the phone. An attacker must be physically within 4 cm – essentially impossible without being noticed in a clinical setting.

2. Application-layer dose verification: Even after pairing, the app signs each dose command with the user’s PIN. The pump verifies the signature before executing. An attacker who somehow bonds still cannot issue a valid dose command without the clinician’s PIN.

3. Key rotation: The pump re-pairs weekly. Compromised keys expire automatically.

Cost of Each Security Layer:

• OOB pairing: Adds hardware or provisioning-flow complexity, but removes the remote pairing MITM path.
• Application-layer PIN or role check: Adds a small user step for high-risk commands, but blocks unauthorized commands even if a bond is misused.
• Periodic re-authentication: Adds occasional friction, but limits how long a compromised bond remains useful.
• Combined result: Pairing protects the link, authorization protects the action, and revocation limits persistence.

Key Insight: OOB pairing removes the primary remote MITM path, while application-layer authorization adds an independent barrier for dose commands. Neither layer alone is sufficient for a life-safety device, but together they provide defense-in-depth with manageable user friction.

Concept Relationships:

• Key hierarchy and bonding: Session keys and stored keys determine whether reconnection can happen securely without re-pairing.
• Pairing methods and key generation: Authentication strength during pairing determines whether encryption protects the right peer.
• IRK and privacy: Identity resolving keys allow bonded devices to recognize private rotating addresses without exposing a stable public address.
• CSRK and data integrity: Signature keys verify authenticity on unencrypted LE links, but they are not a substitute for encryption where confidentiality matters.
• AES-CCM-128 and link encryption: Link encryption protects post-pairing traffic once trusted keys are available.
• P-256 ECDH and LE Secure Connections: Elliptic curve key exchange protects the pairing exchange against passive eavesdropping.

12.11 Practice Activities

Interactive Quiz: Match BLE Encryption Key Types

Interactive Quiz: Sequence LE Secure Connections Key Generation

12.12 See Also

• Bluetooth Security: Labs and Defense-in-Depth - Hands-on security demonstrations
• Bluetooth Security: Pairing Methods - Choosing appropriate pairing for threat model
• Cryptography Fundamentals for IoT - AES and key exchange basics

12.13 Diagram and Code Practice

Label the Diagram

Code Challenge

12.14 Start With the Story

Pairing is only the start of trust. The long-term behavior depends on which keys are created, where they are stored, how identity is resolved, what gets encrypted, and what happens when a device is lost or reset.

Read this chapter as a key lifecycle record. Follow LTK, IRK, CSRK, ECDH, bonding, privacy, and revocation from first pairing through reconnection so the security design has an audit trail.

12.15 Deep Dive: Key Lifecycle, Privacy Addresses, and Signed Data Evidence

Encryption is only part of the BLE security record. When pairing includes bonding, the devices persist a small key hierarchy, and each key supports a different claim:

Key	What it proves	Common review failure
LTK	The bonded peer can re-enable AES-CCM link encryption on reconnection.	The device reconnects but refuses to encrypt, or stale LTK material survives a reset.
IRK	A bonded peer can resolve a rotating private address back to the known identity.	A restored gateway cannot recognize a tag after address rotation because its bond table lost the IRK.
CSRK	A receiver can verify signed data and reject replayed signed writes without encrypting the whole link.	A signed command counter is not checked, or stale CSRKs remain trusted after device removal.

Figure 12.6: Key-management lifecycle evidence loop with generation, provisioning, protected storage, purpose-key derivation, rotation, revocation, destruction, and audit evidence

For BLE bonds, the key inventory should name each LTK, IRK, and CSRK owner, purpose, state, storage boundary, and revocation path. Reset, transfer, and support problems usually come from stale bonded material rather than from AES itself.

Resolvable Private Addresses make the IRK role concrete. A sensor can rotate its over-the-air address periodically so a passive scanner sees unrelated-looking identifiers, while a bonded gateway uses the stored IRK to resolve those addresses as the same trusted device. If the gateway database is restored without the bond table, increasing transmit power or changing the LTK will not help; the fix is restoring or re-establishing the IRK-bearing bond.

CSRK signed data is a different tradeoff. A peripheral can accept a write over an unencrypted link when the packet includes a signature computed with the CSRK and a monotonically increasing counter. The receiver checks the signature and rejects stale counters, which gives authenticity and replay protection, but not confidentiality. Use this only when the profile supports signed data and the command is not secret; medical readings, credentials, ownership changes, and other sensitive operations should bring up an encrypted LTK-protected link and still apply application authorization.

Bond deletion must remove all relevant keys. Keeping a stale LTK can preserve unwanted encrypted access, keeping a stale IRK can keep an old device recognizable, and keeping a stale CSRK can keep old signed commands trusted after the user thought the bond was gone.

12.16 Summary

This chapter covered BLE encryption and key management:

• Encryption Architecture: AES-CCM-128 with 128-bit keys, three key generation methods (Legacy, LE Secure Connections, BR/EDR)
• Key Hierarchy: TK -> STK -> LTK, plus IRK for privacy and CSRK for signatures; legacy pairing uses EDIV+Rand to identify the LTK on reconnection
• LE Secure Connections: Introduced in BLE 4.2, uses P-256 ECDH to prevent passive eavesdropping of the pairing exchange; LTK and MacKey derived via the f5 function
• Security Decision Framework: Match pairing method to data sensitivity and device capabilities
• Best Practices: Use secure key storage, implement authorization layers, plan for revocation
• Common Pitfalls: OOB alternatives for displayless devices, defense-in-depth beyond initial pairing

12.17 What’s Next

Prioritize these follow-up chapters based on the security question you need to answer next:

• Hands-on BLE security labs: bt-security-labs-defense.html to apply key concepts in ESP32 BLE security demonstrations and attack/defense scenarios.
• Pairing methods in depth: bt-security-pairing-methods.html to compare Just Works, Passkey, Numeric Comparison, and OOB with threat-model analysis.
• Cryptography foundations: ../cryptography/encryption-principles-and-crypto-basics.html to review AES-CCM, ECDH, and the primitives underlying BLE key generation.
• IoT authentication patterns: ../authentication/authentication-access-control-index.html to extend BLE pairing security with application-layer identity and authorization.
• IoT threat landscape: ../security-threats/threats-introduction.html to place BLE attack vectors in the broader context of IoT security risks.

12.18 Key Takeaway

Bluetooth encryption is only as strong as key generation, pairing method, storage, and renewal behavior. Protect long-term keys and choose pairing modes that match the threat model and device interface.