Qwen2.

5-Max

Cryptographic Controls in IoT Communication Protocols

Challenges for IoT Developers

 Understanding interactions between di erent IoT protocols.

 Layering security optimally across protocols.

IoT Communication Protocols with Built-in Security

1. ZigBee

 Underlying Security : Leverages IEEE 802.15.4 MAC layer.

 AES encryption (128-bit key) for confidentiality and data integrity.

 Optional security services (encryption and MAC can be disabled).

 Security Configurations :

 No security: No encryption or authentication.

 AES-CBC-MAC: Data authentication (32-bit, 64-bit, or 128-bit MAC; no

encryption).

 AES-CTR: Encryption only (no authentication).

 AES-CCM: Encryption + authentication (32-bit, 64-bit, or 128-bit MAC).

 Key Management :

 Master Keys : Pre-installed by vendors for key exchange.

 Link Keys : Unique per node for secure node-to-node communication.

 Network Keys : Shared across all nodes for secure broadcast

communication.

 Key Establishment Options :

 Pre-installed keys.

 Transported from the ZigBee Trust Center.

 Established using SKKE (Symmetric Key Establishment) or CBKE

(Certificate-Based Key Establishment).

 Trust Center Link Keys (TCLK) : Used to transport new network keys securely.

 Challenges :
  Key rotation must be pre-defined.

 Link keys require more memory, which may not be available on all IoT
devices.

2. Bluetooth-LE

 Based on Bluetooth Core Specification v4.2 .

 Security Concepts :

 Pairing: Devices create shared secret keys.

 Bonding: Storing pairing keys for future use (trusted device pair).

 Device Authentication: Verification of trusted keys.

 Encryption: Scrambling plaintext into ciphertext.

 Message Integrity: Protects against tampering.

 Device Association Models :

 Numeric Comparison : User confirms a six-digit number displayed on

both devices.

 Just Works : For devices without displays (no user confirmation).

 Out-of-Band (OOB) : Uses another protocol (e.g., NFC) for secure pairing.

 Passkey Entry : Six-character passkey entered on one device and

confirmed on another.

 Cryptographic Keys :

 Temporary Key (TK) : Input for deriving short-term key (STK).

 Short-Term Key (STK) : Used for secure distribution of key material.

 Long-Term Key (LTK) : Generates 128-bit key for link-layer encryption.

 Connection Signature Resolving Key (CSRK) : Signs data at the ATT layer
for message integrity.

 Identity Resolving Key (IRK) : Generates private addresses for privacy

protection.

 Privacy Protections :

 IRK generates private addresses (device-generated or controller-

generated).
3. Wi-Fi

 Includes inherent cryptographic controls:

 Confidentiality, integrity, and authentication.

 Commonly used for wireless links in IoT devices.

4. Near Field Communication (NFC)

 No Native Cryptographic Protection :

 Endpoint authentication can be applied during NFC negotiation.

 Use Case :

 Short-range communication for establishing out-of-band pairings (e.g.,

Bluetooth).

Summary

 ZigBee :

 AES encryption and MAC-based integrity.

 Three types of keys: Master, Link, and Network.

 Key management is complex; requires rotation and memory

considerations.

 Bluetooth-LE :

 Multiple pairing models (Numeric Comparison, Just Works, OOB, Passkey

Entry).

 Uses multiple cryptographic keys (TK, STK, LTK, CSRK, IRK).

 Supports signed data and privacy protections.

 Wi-Fi :

 Inherent cryptographic controls for secure communication.

 NFC :

 No native cryptography but supports secure out-of-band pairing.

Qwen2.5-Max
Detailed Points on Cryptographic Controls in IoT Communication Protocols

1. ZigBee

Underlying Security Framework

 ZigBee leverages the IEEE 802.15.4 MAC layer for its cryptographic controls.

 AES Algorithm : Uses a 128-bit key for both encryption/decryption and

data integrity.

 Message Authentication Code (MAC) : Appended to data frames for

integrity verification.

 Optional Security Services : Encryption and MAC capabilities can be

disabled depending on configuration.

Security Configuration Options

ZigBee provides multiple security configurations based on the level of protection

required:

1. No Security :

 No encryption or data authentication.

2. AES-CBC-MAC (Data Authentication Only):

 AES-CBC-MAC-32 : Data authentication using a 32-bit MAC; no

encryption.

 AES-CBC-MAC-64 : Data authentication using a 64-bit MAC; no

encryption.

 AES-CBC-MAC-128 : Data authentication using a 128-bit MAC; no

encryption.

3. AES-CTR (Encryption Only):

 Data is encrypted using AES Counter Mode (AES-CTR) with a 128-bit key;
no authentication.

4. AES-CCM (Encryption + Authentication):

 AES-CCM-32 : Encrypted data with 32-bit MAC for authentication.

 AES-CCM-64 : Encrypted data with 64-bit MAC for authentication.

 AES-CCM-128 : Encrypted data with 128-bit MAC for authentication.

Key Management

ZigBee relies on three types of cryptographic keys for securing communication:

1. Master Keys :

 Pre-installed by vendors.

 Used for secure key exchange transactions between two ZigBee nodes.

2. Link Keys :

 Unique per node.

 Enable secure node-to-node communications.

 Trust Center Link Keys (TCLK): Shared between a ZigBee node and the
trust center, allowing transport of new network keys.

3. Network Keys :

 Shared across all nodes in a ZigBee network.

 Provisioned by the ZigBee Trust Center .

 Support secure broadcast communication.

Key Establishment Methods

ZigBee nodes can obtain keys through one of the following methods:

1. Pre-Installed Keys :

 Keys are pre-loaded into devices during manufacturing.

2. Transported Keys :

 Keys (except master keys) are securely transported from the ZigBee Trust
Center.

3. Dynamic Key Establishment :

 Symmetric Key Establishment (SKKE): Generates link keys dynamically.

 Certificate-Based Key Establishment (CBKE): Uses certificates for secure

key generation.

Key Rotation

 ZigBee keys must be refreshed periodically to maintain security.

 Rotating keys ensures that compromised keys do not persist in the network.

Challenges
 1. Memory Constraints :

 Link keys require more memory resources, which may not be available on
resource-constrained IoT devices.

2. Complex Key Management :

 Setting up and maintaining a robust key management strategy is

challenging.

 Requires careful planning for key distribution, rotation, and revocation.

2. Bluetooth-LE

Bluetooth Core Specification v4.2

 Defines security concepts and mechanisms for Bluetooth-LE communication.

Security Concepts

1. Pairing :

 Devices create shared secret keys during the pairing process.

2. Bonding :

 Pairing keys are stored for future use, forming a trusted device pair.

3. Device Authentication :

 Verifies that paired devices possess trusted keys.

4. Encryption :

 Scrambles plaintext data into ciphertext to ensure confidentiality.

5. Message Integrity :

 Protects against tampering by verifying the integrity of transmitted data.

Device Association Models

Bluetooth-LE supports four models for device association:

1. Numeric Comparison :

 A six-digit number is displayed on both devices.

 The user confirms if the numbers match.

 Note: In Bluetooth 4.2, the six-digit number is not directly tied to

encryption operations.
 2. Just Works :

 Designed for devices without displays.

 Similar to Numeric Comparison but does not require user confirmation.

3. Out-of-Band (OOB) :

 Uses another protocol (e.g., NFC) for secure pairing.

 NFC exchanges device Bluetooth addresses and cryptographic

information.

4. Passkey Entry :

 A six-character passkey is entered on one device and confirmed on

another.

Cryptographic Keys

Bluetooth-LE uses multiple cryptographic keys for di erent security functions:

1. Temporary Key (TK) :

 Determined by the pairing method.

 Input for deriving the Short-Term Key (STK).

2. Short-Term Key (STK) :

 Used for secure distribution of key material.

 Derived from TK and random values exchanged during pairing.

3. Long-Term Key (LTK) :

 Generates a 128-bit key for link-layer encryption.

4. Connection Signature Resolving Key (CSRK) :

 Signs data at the ATT layer for message integrity.

 Includes a counter to prevent replay attacks.

5. Identity Resolving Key (IRK) :

 Generates private addresses based on a device's public address.

 Provides privacy protection by masking the device's identity.

Privacy Protections

 Bluetooth-LE supports two options for privacy:

1. Device-Generated Private Address :

  The device generates its own private address using IRK.

2. Controller-Generated Private Address :

 The Bluetooth controller generates the private address.

Replay Protection

 Bluetooth-LE includes a counter mechanism in signed data to prevent replay

attacks.

3. Wi-Fi

Inherent Cryptographic Controls

 Wi-Fi protocols include built-in cryptographic features:

 Confidentiality : Ensures data cannot be read by unauthorized parties.

 Integrity : Protects against tampering.

 Authentication : Verifies the identity of communicating devices.

Use Case

 Commonly used as the wireless link for IoT devices due to its widespread
availability and robust security.

4. Near Field Communication (NFC)

No Native Cryptographic Protection

 NFC itself does not implement cryptographic controls.

 However, endpoint authentication can be applied during NFC negotiation.

Use Case

 NFC is often used as a first-step protocol for establishing out-of-band pairings.

 Example: NFC can securely exchange Bluetooth addresses and cryptographic

information for Bluetooth pairing.

Summary

1. ZigBee :
  Relies on IEEE 802.15.4 MAC layer for AES encryption and MAC-based
integrity.

 Supports multiple security configurations (encryption, authentication, or

both).

 Uses three types of keys: Master, Link, and Network.

 Key establishment methods include pre-installation, transport, and

dynamic generation.

 Challenges include memory constraints and complex key management.

2. Bluetooth-LE :

 Based on Bluetooth Core Specification v4.2.

 Provides pairing, bonding, device authentication, encryption, and

message integrity.

 Supports four device association models: Numeric Comparison, Just

Works, OOB, and Passkey Entry.

 Uses multiple cryptographic keys (TK, STK, LTK, CSRK, IRK).

 Includes privacy protections and replay prevention mechanisms.

3. Wi-Fi :

 O ers inherent cryptographic controls for confidentiality, integrity, and

authentication.

 Widely used for wireless links in IoT devices.

4. NFC :

 Lacks native cryptographic protection but supports secure out-of-band

pairings.

 Often combined with other protocols (e.g., Bluetooth) for enhanced

security.

Qwen2.5-Max

Detailed Points on Cryptographic Controls in IoT Messaging Protocols

1. MQTT (Message Queuing Telemetry Transport)

Authentication
  MQTT supports sending a username and password as part of the CONNECT
message.

 Security Risk : The username and password are sent in plaintext unless
additional security measures are applied.

Confidentiality and Integrity

 To prevent Man-in-the-Middle (MITM) attacks:

 TLS (Transport Layer Security) must be enabled.

 Ideally, end-to-end TLS connectivity should be used between endpoints

(not just gateway-to-gateway).

 Mutual Authentication using certificates is recommended to validate both

client and server identities.

2. CoAP (Constrained Application Protocol)

Authentication Options

 CoAP supports multiple authentication mechanisms for device-to-device

communication.

 These can be combined with Datagram TLS (DTLS) for enhanced confidentiality
and authentication.

Security Modes

CoAP defines the following security modes based on cryptographic material:

1. NoSec (No Security) :

 DTLS is disabled.

 No protocol-level security is provided.

 Use Case : May be acceptable if alternate security mechanisms (e.g.,

IPsec or secure link layer) are in place.

 Recommendation : Not recommended due to lack of inherent security.

2. PreSharedKey (PSK) :

 DTLS is enabled.

 Devices use pre-shared keys for node-to-node communication.

 These keys can also function as group keys for multicast communication.
 3. RawPublicKey :

 DTLS is enabled.

 Devices use an asymmetric key pair without certificates (raw public key).

 Public keys are validated using out-of-band mechanisms .

 Each device has:

 An identity derived from its public key.

 A list of trusted node identities it can communicate with.

4. Certificate :

 DTLS is enabled.

 Devices use an asymmetric key pair with an X.509 certificate (RFC5280).

 Certificates bind the device to its subject and are signed by a common
trust root.

 Each device maintains:

 A list of trusted root certificates (trust anchors) for validating other

certificates.

Reference

 CoAP security modes are defined in [RFC7252, Section

9]([Link] #section-9).

3. DDS (Data Distribution Service)

Security Features

 The Object Management Group's (OMG) DDS security specification provides:

 Endpoint Authentication : Verifies the identity of communicating devices.

 Key Establishment : Establishes cryptographic keys for secure

communication.

Message Security

 Data Origin Authentication :

 Uses HMAC (Hash-based Message Authentication Code) to ensure

messages originate from authenticated sources.
  Supported Authentication Mechanisms :

 Digital certificates.

 Identity/Authorization tokens.

4. REST (Representational State Transfer)

Authentication and Confidentiality

 REST APIs typically rely on TLS for:

 Authentication.

 Confidentiality of data in transit.

Basic Authentication

 REST supports basic authentication , where credentials are passed as plaintext.

 Security Risk : Credentials are vulnerable to interception unless protected

by TLS.

 Recommendation : Avoid using basic authentication even under TLS.

Token-Based Authentication

 A more secure approach is to use token-based authentication mechanisms:

 Examples: OpenID Connect (identity layer) on top of OAuth2 .

 Tokens provide:

 Authentication.

 Authorization (if needed).

Additional Security Controls

 When using OAuth2 or similar token-based systems:

 Implement additional security controls to mitigate risks such as token

theft or misuse.

 Refer to best practices and guidelines for securing OAuth2

implementations.

Summary

MQTT
  Supports username/password authentication (sent in plaintext unless secured).

 Requires TLS for confidentiality and integrity.

 Mutual authentication using certificates is recommended.

CoAP

 Supports multiple authentication mechanisms.

 Security modes include:

 NoSec : No protocol-level security (not recommended).

 PreSharedKey : Pre-shared keys for node and group communication.

 RawPublicKey : Asymmetric keys without certificates.

 Certificate : X.509 certificates for mutual authentication.

 Combines with DTLS for confidentiality and authentication.

DDS

 Provides endpoint authentication and key establishment.

 Uses HMAC for data origin authentication.

 Supports digital certificates and identity/authorization tokens.

REST

 Relies on TLS for authentication and confidentiality.

 Avoid basic authentication (credentials in plaintext).

 Use token-based authentication (e.g., OpenID Connect over OAuth2).

 Implement additional security controls for token-based systems.

Qwen2.5-Max

Detailed Points on Identity and Access Management (IAM) for IoT

1. Introduction to IoT Identity and Access Management

 Traditional IAM Focus :

 Historically, security administrators managed identities and access for

people interacting with IT systems.

 Bring Your Own Device (BYOD) :

  Allowed authorized individuals to use personal devices (e.g.,
smartphones, laptops) for corporate network services.

 Security assurances included strong passwords, virus scanners, and disk

encryption.

 IoT IAM Challenges :

 Rapid addition of diverse IoT devices to networks.

 Sharing data and devices across organizations.

 Maintaining privacy while collecting, storing, and sharing consumer data.

2. Holistic IAM Program for IoT

 Alignment with Governance Models :

 IoT IAM strategies should align with existing organizational governance

and IT systems.

 Integration with PACS/LACS :

 Physical Access Control Systems (PACS) : Manage physical access

policies.

 Logical Access Control Systems (LACS) : Manage identity, authentication,

and authorization for digital resources.

 Integration of IoT devices with PACS/LACS enables controlled adoption of

IoT in organizations.

3. The Identity Lifecycle for IoT Devices

The identity lifecycle for IoT devices involves the following phases:

Phase 1: Establish Naming Conventions and Uniqueness Requirements

 Uniqueness :

 Ensures each device has a unique identifier.

 Can be randomized or deterministic (e.g., algorithmically sequenced).

 Examples:

 Simple counter-based identifiers.

 Manufacturer ID + Product Line ID + Counter.

  Randomized values combined with static fields.

 Globally Unique Identifier (UUID) : A standardized method for ensuring

uniqueness.

Phase 2: Logical Identification for Authentication and Access Control

 Assign logical identifiers to devices based on their operational context.

 Logical IDs help support authentication and access control functions.

Phase 3: Naming Devices

 Each device must have a name or identifier that computing resources can
understand.

 Challenges:

 Avoid duplication of identities within the information domain.

 Example: Using usernames like <lastname_firstname_middleinitial> for

humans.

 For IoT devices, identifiers such as UUIDs or Electronic Serial Numbers

(ESNs) are commonly used.

Phase 4: Attributes for Attribute-Based Access Control (ABAC)

 Device attributes can include:

 Manufacturer.

 Type.

 Serial number.

 Deployment date.

 Location.

 These attributes enable Attribute-Based Access Control (ABAC) :

 Policies are defined not just by device identity but also by its properties
(attributes).

 Allows complex, context-aware access rules.

Phase 5: Removal of Device Identity

 Remove the device's identity from the system when it is decommissioned or no

longer needed.
4. IoT Messaging Protocols and Device Identification

 MQTT :

 Includes a ClientID field for transmitting a broker-unique client identifier.

 The ClientID is used to maintain state in broker-client communication

sessions.

 Other Protocols :

 IoT messaging protocols often include mechanisms to transmit unique

identifiers for devices.

5. Amazon IoT Example

Amazon IoT uses a Thing Registry service to manage IoT device identities:

 Attributes Captured :

 Name of the device ("thing").

 Manufacturer.

 Type.

 Serial number.

 Deployment date.

 Location.

 Use in ABAC :

 Attributes are used to define access control policies.

 Enables rich, context-aware rules for access decisions.

6. Infrastructure Components for IoT IAM

 Public Key Infrastructure (PKI) :

 PKI is critical for provisioning authentication credentials.

 Provides mechanisms for issuing, managing, and revoking digital

certificates.

 Authentication Credentials :

 Certificates.
  Pre-shared keys.

 Raw public keys.

 Authorization and Access Control :

 Define policies for granting or denying access to resources.

 Leverage ABAC for dynamic, attribute-driven access decisions.

7. Key Considerations for IoT IAM

 Scalability :

 Manage identities for thousands or millions of devices.

 Interoperability :

 Ensure compatibility with existing IT systems and protocols.

 Security :

 Protect against unauthorized access and ensure privacy.

 Lifecycle Management :

 Implement processes for provisioning, updating, and decommissioning

device identities.

Summary

1. IAM for IoT :

 Extends traditional IAM to manage identities and access for IoT devices.

 Aligns with governance models and integrates with PACS/LACS systems.

2. Identity Lifecycle :

 Includes naming conventions, uniqueness requirements, logical

identification, and removal of identities.

 Uses UUIDs, serial numbers, or other unique identifiers.

3. Messaging Protocols :

 MQTT and other protocols support unique identifiers for devices.

4. Amazon IoT Example :

 Uses Thing Registry to capture device attributes for ABAC.

 5. Infrastructure :

 PKI is essential for managing authentication credentials.

 Authorization leverages ABAC for context-aware access control.

6. Challenges :

 Scalability, interoperability, security, and lifecycle management are key

considerations.

Qwen2.5-Max

Simplified Detailed Points on IoT Identity and Access Management

1. Secure Bootstrapping

 What is Bootstrapping?

 The process of provisioning a trusted identity for a device within a system.

 Starts during manufacturing and continues through the supply chain.

 Key Features :

 Unique identifiers (e.g., serial numbers, ROM-stored IDs).

 Manufacturer-specific cryptographic keys for secure hando s.

 Use of Public Key Infrastructure (PKI) to establish trust.

 Challenges :

 Preventing rogue devices, cloning, or compromised keys.

 Protecting private keys during generation or transfer.

 Securing devices during supply chain gaps.

2. Credential and Attribute Provisioning

 After Bootstrapping :

 Operational credentials (e.g., certificates, keys) are provisioned for secure

communication.

 Best Practices :

 Use certificates for authentication whenever possible.

  Generate key pairs locally on the device or centrally with strong security
controls.

 Avoid sharing private keys over insecure channels.

3. Authentication Credentials

Passwords

 Some protocols (e.g., MQTT) use username/password for authentication.

 Security Risks :

 Passwords sent in plaintext unless protected by TLS.

 Di icult to manage passwords across many devices.

 Recommendations :

 Rotate passwords regularly (e.g., every 30 days).

 Monitor account activity and privileged access.

Symmetric Keys

 Shared keys used for authentication via Message Authentication Codes (MACs).

 Keys are established ahead of time or using secure protocols.

Certificates

 Preferred method for IoT authentication.

 Use X.509 certificates with hierarchical naming (e.g., organization, common

name).

 AWS IoT supports one-click certificate generation but recommends local key pair
generation for better control.

Biometrics

 Emerging trend for IoT authentication (e.g., fingerprints, voice prints).

 Useful as a second factor or for password-less authentication.

4. IoT IAM Infrastructure

802.1x Authentication

 Limits IP-based IoT device access to networks.

  Requires an access point and an authentication server (e.g., RADIUS).

Public Key Infrastructure (PKI)

 PKIs issue digital certificates to devices for cryptographic functions.

 How It Works :

 Devices generate key pairs locally or centrally.

 Certificates are signed by a Certificate Authority (CA) and stored securely.

 Trust Stores :

 Securely store public/private keys and trust anchors.

 Implemented in hardware (e.g., HSMs) or software.

Revocation Support

 Devices need to know when credentials are revoked.

 Methods:

 CRLs : Periodic lists of revoked certificates.

 OCSP : Real-time queries to check certificate validity.

 OCSP Stapling : Pre-generated OCSP responses included with

certificates.

5. Authorization and Access Control

OAuth 2.0

 Token-based framework for accessing resources without passwords.

 IoT Adaptations :

 Compact encoding schemes (e.g., CBOR) for constrained devices.

 Specifies access rights as URIs with allowed actions (e.g., GET, POST).

 Security Best Practices :

 Use TLS for all interactions.

 Securely store client credentials (client_id, client_secret).

 Shorten token expiry times and revoke tokens for suspicious activity.

MQTT Access Controls

  Publish/subscribe protocol with topic-level permissions.

 Implementation :

 Maintain Access Control Lists (ACLs) pairing topics with authorized

clients.

 Use client IDs or usernames for authorization.

 Optionally require certificate-based authentication.

ZigBee Access Controls

 Each transceiver manages an ACL to determine trusted neighbors.

 ACL includes neighbor address, security policy, key, and initialization vector (IV).

6. Privacy Considerations

 Anonymous PKIs :

 Designed to protect privacy by preventing association of credentials with

users/devices.

 Example: SCMS for connected vehicles.

 SSL Pinning :

 Pins trusted server certificates directly into the device trust store.

 Ensures devices only trust specific servers, even if the trust infrastructure
is compromised.

7. Account Management

 Monitoring :

 Regularly audit administrative credentials (e.g., SSH keys, passwords).

 Track credential strength (e.g., cipher suites, key lengths).

 Updates :

 Rotate credentials (e.g., certificates, keys, passwords) regularly.

 Use automated tools like Let’s Encrypt for certificate management.

 Suspension/Deletion :

 Suspend accounts instead of deleting them for forensic purposes.

  Delete accounts and encryption keys after decommissioning devices to
prevent misuse.

Summary

1. Secure Bootstrapping :

 Establishes initial trust using unique IDs, keys, and PKI.

 Mitigates risks like rogue devices and key compromise.

2. Credential Provisioning :

 Use certificates for secure authentication.

 Generate keys locally or centrally with strong controls.

3. Authentication Options :

 Passwords (with TLS), symmetric keys, certificates, and biometrics.

4. IAM Infrastructure :

 Leverage 802.1x, PKI, trust stores, and revocation mechanisms.

5. Authorization :

 Use OAuth 2.0 for token-based access control.

 Implement fine-grained access controls in protocols like MQTT and

ZigBee.

6. Privacy :

 Adopt anonymous PKIs and SSL pinning for privacy protection.

7. Account Management :

 Monitor, update, suspend, and delete accounts securely.