[Avg. reading time: 14 minutes]

Encryption in IoT Upper Stack

Two foundational concepts that help protect data are hashing and encryption.

Hashing & Encryption

Hashing: One-Way Fingerprint

Hashing is like creating a digital fingerprint of data. It takes input (e.g., a message or file) and produces a fixed-length hash value.

• One-way function: You can’t reverse a hash to get the original data.
• Deterministic: Same input = same hash.
• Common use: Password storage, data integrity checks.

Use-case: When sending firmware updates to IoT devices, the server also sends a hash. The device re-hashes the update and compares — if it matches, the data wasn’t tampered with.

import hashlib
print(hashlib.sha256(b"iot-data").hexdigest())

Online Hash Generator

Encryption

Encryption transforms readable data (plaintext) into an unreadable format (ciphertext) using a key. Only those with the key can decrypt it back.

Two Types

Symmetric

• Same key to encrypt and decrypt. Example: AES

ASymmetric

• Public key to encrypt, private key to decrypt. Example: RSA

Use-case: Secure communication between sensors and cloud, protecting sensitive telemetry, encrypting data at rest.

sequenceDiagram
    participant Sensor
    participant Network
    participant Cloud

    Sensor->>Network: Temp = 28.5 (Plaintext)
    Network-->>Cloud: Temp = 28.5

    Note over Network: Data can be intercepted

    Sensor->>Network: AES(TLS): Encrypted Payload
    Network-->>Cloud: Encrypted Payload (TLS)
    Cloud-->>Cloud: Decrypt & Store

https://github.com/gchandra10/python_encryption_example.git

Encryption plays a critical role in securing IoT systems beyond the device level. Here’s how it applies across the upper layers of the stack:

📶 Communication Layer – Data in Transit

Purpose: Protect data from eavesdropping or tampering during transmission.

Best Practices:

• Enforce TLS 1.2 or higher
• Use certificate pinning for mutual authentication
• Disable weak ciphers (e.g., RC4, SSLv3)

Refer to our MQTT Publisher.py example

sequenceDiagram
    participant Client (paho)
    participant Broker

    Note over Client (paho): Initiates TLS connection

    Client (paho)->>Broker: ClientHello (supported TLS versions, random, cipher suites)
    Broker->>Client (paho): ServerHello + X.509 Certificate

    Note over Client (paho): Verifies broker's cert (using CA trust store)

    alt Key Exchange (e.g., ECDHE)
        Client (paho)->>Broker: Key share (public part)
        Broker-->>Client (paho): Server key share
        Note over Client (paho),Broker: Both derive shared symmetric key
    end

    Client (paho)->>Broker: Finished (encrypted with session key)
    Broker->>Client (paho): Finished (encrypted)

    Note over Client (paho),Broker: Secure channel established (TLS)

    Client (paho)->>Broker: MQTT CONNECT (encrypted, includes username/password)
    Broker-->>Client (paho): CONNACK (encrypted)

    Client (paho)->>Broker: PUBLISH sensor/temp (encrypted payload)
    Broker-->>Client (paho): PUBACK (encrypted)

💾 Data Layer – At Rest

Purpose: Prevent unauthorized access to stored data on device, gateway, or cloud.

Best Practices:

• Use AES-256 for data encryption
• Integrate with HSMs or cloud-native KMS (e.g., AWS KMS)
• Enforce encryption policies (e.g., block unencrypted uploads)

🧱 Application Layer – API & Payload Encryption

Purpose: Protect sensitive data in payloads, configs, or tokens.

Best Practices:

• Use HMACs for integrity verification
• Use JWE (JSON Web Encryption) for sensitive tokens
• Sign firmware/images with RSA or ECC

Cloud & IAM Layer – Secrets and Identity

Purpose: Secure identity tokens, secrets, and environment variables.

Best Practices:

• Encrypt secrets using cloud-native KMS (e.g., AWS KMS, Azure Key Vault)
• Use tools like HashiCorp Vault to manage secrets
• Apply token expiration and rotation policiesVer 6.0.5