Encryption and Authentication Techniques for Embedded Systems

Why Encryption and Authentication Matter

Embedded and IoT devices collect sensitive data (health metrics, location, industrial readings) and control physical systems (door locks, motors, valves). Without proper encryption and authentication:

• Anyone can read your sensor data in transit
• An attacker can impersonate your device or your server
• Unauthorized users can send commands to your device
• Credentials stored on the device can be extracted

Encryption protects data confidentiality. Authentication verifies identity. Both are essential for any connected embedded system.

Symmetric Encryption

How It Works

Symmetric encryption uses the same key for both encryption and decryption. Both the sender and receiver must have the same secret key.

Sender:    Plaintext + Key → [Encrypt] → Ciphertext
Receiver:  Ciphertext + Key → [Decrypt] → Plaintext

Example:
  Key:        "mysecretkey12345" (128-bit)
  Plaintext:  "Temperature: 23.5C"
  Ciphertext: "a7f2b9c1e8d4..." (unreadable without key)

Common Symmetric Algorithms

Algorithm	Key Size	Block Size	Status
AES-128	128 bits	128 bits	Standard, recommended for embedded
AES-256	256 bits	128 bits	Higher security, slightly slower
ChaCha20	256 bits	Stream	Fast in software (no hardware AES)
DES/3DES	56/168 bits	64 bits	Deprecated, do NOT use

AES (Advanced Encryption Standard) is the most widely used. Many modern microcontrollers (ESP32, STM32, nRF52) have hardware AES accelerators that encrypt data much faster and with less power than software implementations.

AES Example on ESP32

#include "mbedtls/aes.h"

void encrypt_data(const uint8_t *key, const uint8_t *input,
                  uint8_t *output, size_t length) {
    mbedtls_aes_context aes;
    mbedtls_aes_init(&aes);

    // Set encryption key (128-bit)
    mbedtls_aes_setkey_enc(&aes, key, 128);

    // Encrypt each 16-byte block
    for (size_t i = 0; i < length; i += 16) {
        mbedtls_aes_crypt_ecb(&aes, MBEDTLS_AES_ENCRYPT,
                               input + i, output + i);
    }

    mbedtls_aes_free(&aes);
}

Important: Never use ECB (Electronic Codebook) mode for real data, as it leaks patterns. Use CBC, CTR, or GCM mode instead. GCM is preferred because it provides both encryption and authentication (AEAD).

Asymmetric Encryption (Public-Key Cryptography)

How It Works

Asymmetric encryption uses a key pair: a public key (shared freely) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the private key.

Key Generation:
  Generate key pair → Public Key + Private Key

Encryption:
  Sender:    Plaintext + Receiver's PUBLIC key → Ciphertext
  Receiver:  Ciphertext + Receiver's PRIVATE key → Plaintext

Digital Signature:
  Signer:    Hash(data) + Signer's PRIVATE key → Signature
  Verifier:  Hash(data) + Signer's PUBLIC key → Valid or Invalid

Common Asymmetric Algorithms

Algorithm	Key Size	Use Case	Embedded Suitability
RSA	2048-4096 bits	Encryption, signatures	Slow, large keys (not ideal for constrained devices)
ECDSA	256 bits	Digital signatures	Fast, small keys, ideal for embedded
ECDH	256 bits	Key exchange	Fast, small keys
Ed25519	256 bits	Digital signatures	Very fast, simple, modern

ECC (Elliptic Curve Cryptography) is preferred for embedded systems because it provides equivalent security to RSA with much smaller keys and faster computation. A 256-bit ECC key provides roughly the same security as a 3072-bit RSA key.

Hashing

A hash function takes any input and produces a fixed-size output (the hash or digest). Hashes are one-way: you cannot recover the original data from the hash.

SHA-256("Hello") → "185f8db32271fe25f561a6fc938b2e26..."
SHA-256("hello") → "2cf24dba5fb0a30e26e83b2ac5b9e29e..."
  (completely different output for a tiny change)

Uses in embedded systems:

• Verifying firmware integrity (secure boot)
• Password storage (store hash, not plaintext)
• Data integrity checks (detect corruption)
• HMAC (Hash-based Message Authentication Code) for message authentication

Algorithm	Output Size	Status
SHA-256	256 bits (32 bytes)	Recommended standard
SHA-384/512	384/512 bits	Higher security, more computation
MD5	128 bits	Broken, do NOT use for security
SHA-1	160 bits	Deprecated, do NOT use for security

TLS (Transport Layer Security)

TLS is the protocol that puts the “S” in HTTPS. It provides encrypted, authenticated communication between your device and a server. TLS combines symmetric encryption, asymmetric encryption, and hashing into a complete secure communication channel.

TLS Handshake (Simplified)

Device                                  Server
  |                                       |
  |--- ClientHello (supported ciphers) -->|
  |                                       |
  ||
  |                                       |
  |  Both sides now have shared secret     |
  |  All further data encrypted with AES   |
  |                                       |
  ||

TLS on Embedded Devices

Most embedded TLS implementations use mbedTLS (formerly PolarSSL). It is lightweight and runs on microcontrollers with as little as 64KB ROM and 16KB RAM.

// ESP32 HTTPS request with TLS (ESP-IDF)
esp_http_client_config_t config = {
    .url = "https://api.example.com/data",
    .cert_pem = server_root_ca_cert,  // CA certificate to verify server
    .client_cert_pem = client_cert,   // Optional: mutual TLS
    .client_key_pem = client_key,
};

esp_http_client_handle_t client = esp_http_client_init(&config);
esp_http_client_perform(client);
esp_http_client_cleanup(client);

Mutual TLS (mTLS)

Standard TLS only verifies the server. Mutual TLS also verifies the device. The device presents its own certificate, proving its identity to the server. This is the standard authentication method for AWS IoT, Azure IoT, and Google Cloud IoT.

Standard TLS:   Device verifies Server (one-way)
Mutual TLS:     Device verifies Server AND Server verifies Device (two-way)

Authentication Methods

1. Pre-Shared Key (PSK)

A secret key is loaded onto the device during manufacturing. Simple but does not scale well (each device needs a unique key).

2. Certificate-Based (X.509)

Each device has a unique certificate signed by a Certificate Authority (CA). The server verifies the certificate to authenticate the device. This is the most secure and scalable approach.

Manufacturing:
  1. Generate key pair on device (or externally)
  2. Create Certificate Signing Request (CSR)
  3. CA signs the CSR → device certificate
  4. Store certificate + private key on device

Runtime:
  Device presents certificate → Server verifies with CA → Authenticated

3. Token-Based (JWT, API Key)

The device uses a token (like a JSON Web Token) to authenticate with cloud services. Simpler than certificates but tokens can expire and need refreshing.

Storing Secrets on Embedded Devices

Where you store keys and certificates matters:

Method	Security	Notes
Hardcoded in source code	Very poor	Anyone with the binary can extract them
Separate flash partition	Low	Better but still readable with physical access
Encrypted flash	Medium	Protected if flash encryption is enabled
Secure element (ATECC608)	High	Hardware crypto chip, keys never leave the chip
TrustZone secure storage	High	Hardware-isolated secure world (Cortex-M33+)

For production IoT devices, consider using a secure element like the Microchip ATECC608A/B. It stores private keys in tamper-resistant hardware and performs crypto operations internally. The private key never leaves the chip, making extraction virtually impossible.

Security Best Practices

1. Use TLS for all network communication. Never send data in plaintext.
2. Use AES-GCM or ChaCha20-Poly1305 for symmetric encryption (they provide both encryption and integrity).
3. Use ECC (ECDSA/Ed25519) instead of RSA for embedded devices. Smaller keys, faster operations.
4. Never hardcode secrets in source code. Use secure storage or a secure element.
5. Use unique credentials per device. If one device is compromised, only that device is affected.
6. Rotate keys and certificates. Plan for how to update credentials if they are compromised.
7. Validate all input. Never trust data from external sources without validation.
8. Keep crypto libraries updated. Vulnerabilities in crypto implementations are regularly discovered and patched.

Summary

Security in embedded systems is built on three pillars: encryption (protecting data), authentication (verifying identity), and integrity (detecting tampering). Use AES for symmetric encryption, ECC for asymmetric operations, SHA-256 for hashing, and TLS for secure communication. Store secrets in hardware secure elements when possible. Every connected device should use TLS with at minimum server authentication, and production IoT devices should implement mutual TLS with per-device certificates. Security is not optional; it is a core requirement for any device that connects to a network.