Forem: Pratha Maniar

Secure Firmware Updates with a Secure Element: Building Trust Into the Bootloader

Pratha Maniar — Fri, 22 May 2026 10:33:13 +0000

Imagine your embedded device is deployed somewhere in the field - a smart meter, an industrial sensor, a vehicle ECU. You find a critical bug. You push a fix. The device downloads the new firmware over the air and flashes it.

But here's the uncomfortable question: how does the device know that firmware actually came from you?

Anyone sitting on the same network could send a firmware package. A compromised update server could serve a malicious binary.

Without a proper trust mechanism, your device is one bad OTA away from running someone else's code.

This is the problem a Secure Element solves - and this post walks through exactly how it works, from the chip itself to the bootloader verification flow.

What Is a Secure Element?

A Secure Element (SE) is a small, tamper-resistant chip whose one job is to safely store cryptographic keys and run crypto operations - without ever exposing those keys to the outside world.

Think of it as a locked safe soldered onto your board. Even if an attacker gets full control of your main CPU, dumps your flash, or probes your bus lines, the keys inside the SE remain out of reach.

It protects against:

Physical attacks (chip probing, decapping, glitch injection)
Software attacks (privilege escalation, memory dumps)
Side-channel attacks (power analysis, timing attacks)

Common SE chips used in embedded systems: ATECC608A, SE050, TPM 2.0.

What Can a Secure Element Do?

A secure element is not just a key storage box - it is a self-contained cryptographic engine. Here is what it can do:

1. Key generation and storage - private keys are created and stored inside the chip and never leave it, not even during factory programming

2. Digital signatures (ECDSA - Elliptic Curve Digital Signature Algorithm / Ed25519) - signs or verifies data using stored keys; the core operation behind firmware verification

3. Key agreement (ECDH - Elliptic Curve Diffie-Hellman) - two parties derive a shared encryption key from exchanged public keys, without the secret ever crossing the wire

4. Symmetric encryption (AES - Advanced Encryption Standard) - encrypts and decrypts data directly on-chip; used to protect firmware package contents in transit

5. Hashing (SHA-256 - Secure Hash Algorithm) - computes a fixed 32-byte fingerprint of any data; one byte changed equals a completely different hash

6. True random number generation (TRNG) - hardware entropy source for generating nonces, session keys, and signature randomness

7. Monotonic counter - a number that only goes up, never down, even across power cycles; blocks firmware downgrade attacks

8. Certificate storage - stores X.509 certificates to prove device identity during TLS(Transport Layer Security) or OTA authentication

Why Firmware Updates Need Signature Verification?

When a device receives an OTA update, it has no way of knowing by default whether that firmware is genuine or has been tampered with.

An attacker could:

Intercept the OTA transfer and swap in malicious firmware
Replay an older, vulnerable firmware version
Extract a key from plain flash memory, sign a fake binary, and serve it

Signature verification closes this. The firmware is cryptographically signed by the manufacturer before it ever leaves the build system. The bootloader verifies that signature on the device before touching a single flash sector. If verification fails, nothing gets flashed.

The Secure Element is what makes this guarantee solid - the verification key lives inside hardware-protected storage, not in flash memory where it can be read or replaced.

The Verification Flow - Step by Step

On the Manufacturer Side

Firmware binary is compiled, and a version header is attached (version number, hardware revision, and magic bytes).
A SHA-256 hash of the entire firmware is computed - a fixed 32-byte fingerprint of the binary.
That hash is signed using an ECDSA private key stored in a Hardware Security Module (HSM - Hardware Security Module) on the build server. The result is a signature.
Package is uploaded to the OTA server. The final package ships as:

{ firmware binary + version header + ECDSA signature }

On the Device Side - Inside the Bootloader

1. Firmware package arrives and is written to a staging area in flash.
   (Primary firmware slot is untouched at this point.)

2. Bootloader reads the firmware header:
   - Magic number   → is this a valid package format?
   - Hardware rev   → is this firmware built for this exact hardware?
   - Version number → is this newer than what is currently running?

3. Bootloader computes SHA-256 over the full firmware binary.
   → 32-byte hash of exactly what was received.

4. Bootloader hands the hash + the signature to the Secure Element:
   SE.verify(hash, signature, public_key)

5. Secure Element runs ECDSA verification internally:
   - Uses the public key it has stored inside it
   - Mathematically checks whether the signature was produced
     by the matching private key over this exact hash
   - Returns PASS or FAIL - nothing else leaves the SE

6a. PASS:
    → Erase the primary firmware slot
    → Copy firmware from staging to primary slot
    → Increment the SE monotonic counter (locks out older versions)
    → Reboot and jump to new firmware entry point

6b. FAIL:
    → Erase the staging area
    → Boot the existing firmware as a safe fallback
    → Log the failure for reporting on next server connection

The key insight: the private key that signed the firmware on the build server never exists on the device. Only the public key is on the device - locked inside the SE. A public key can verify signatures but cannot create them. So even if an attacker fully dumps the device's flash, they cannot forge firmware that passes verification.

Anti-Rollback: Why a Valid Signature Is Not Enough

Here is a subtle attack worth understanding. Firmware v1.2 had a vulnerability - you patched it in v1.3. But v1.2 was real firmware, signed by your real private key. Its signature is completely valid.

An attacker replays the old v1.2 package. Signature check passes. Device flashes vulnerable firmware. You are back to square one.

The fix is the SE monotonic counter - a number stored inside the SE that only ever increments.

SE stores: minimum_allowed_version = 1.3

Bootloader receives firmware v1.2:
  1.2 < 1.3  →  REJECTED, even though signature is valid.

After successfully flashing v1.4:
  SE increments counter → minimum_allowed_version = 1.4
  This cannot be undone by software.

Because the counter is inside the SE, no software attack - not even a full OS compromise - can reset it.

Conclusion

Firmware security is not just about encryption or passwords. It is about establishing a chain of trust - from the moment code leaves your build system to the moment a device executes it.

The Secure Element is the hardware anchor of that chain. The private key stays with you. The public key stays locked in silicon on the device. The bootloader does the verification. And the monotonic counter makes sure there is no going back.

How Does a Fingerprint Turn Into a Secure Digital Identity?

Pratha Maniar — Fri, 19 Dec 2025 06:58:47 +0000

Fingerprint-Based Security: From Capture to Secure Matching

In a world where passwords are forgotten, stolen, or guessed, biometrics provides a far more reliable form of security, an identity based on who you are. Among all biometric technologies, fingerprint recognition remains the most widely deployed due to its accuracy, speed, and ease of use.

But what really happens when a finger touches a sensor?
How does a physical pattern on human skin turn into a secure digital identity?

Let’s explore the complete journey, from fingerprint formation to secure matching.

1. What Is a Biometric System?

A biometric system identifies or verifies an individual using unique biological traits. Fingerprints are especially effective because they are unique, permanent, and easy to capture.

Biometric systems operate in two main phases:

Enrollment – registering a user’s biometric data.
Authentication – verifying identity using live input.

2. Ridges and Valleys: The Foundation of Fingerprints

A fingerprint is made up of alternating raised lines (ridges) and depressions (valleys) on the surface of the skin.

Ridges are the elevated portions that make contact with a surface.
Valleys are the spaces between ridges.

These ridge-valley patterns form unique shapes such as loops, whorls, and arches, which are determined before birth and remain stable throughout life.

3. How a Fingerprint Image Is Generated

When a finger is placed on a fingerprint sensor, ridges touch the surface while valleys remain slightly away.

Depending on the sensor type:

Capacitive sensors detect electrical differences between ridges and valleys.
Optical sensors detect reflected light from ridge contact points.
Ultrasonic sensors map depth variations using sound waves.

This interaction creates a contrast-rich image, where:

Dark areas usually represent ridges.
Light areas represent valleys.

This raw image is the digital representation of the fingerprint’s physical structure.

4. Pre-Processing: Enhancing Ridges and Valleys

The raw fingerprint image may contain noise due to finger pressure, moisture, or skin condition. To improve clarity, the system performs preprocessing, which includes:

Contrast normalization.
Noise reduction.
Ridge enhancement.
Binarization (ridges vs valleys).
Thinning (reducing ridges to single-pixel width). These steps sharpen the ridge-valley structure, making feature extraction more reliable.

5. Feature Extraction: Identifying Unique Points

Rather than storing the entire fingerprint image, the system extracts distinct features, mainly minutiae points.

Minutiae occur where:

A ridge ends.
A ridge split into two (bifurcation).

Each minutia is defined by:

Its location.
Its orientation.
Its type. A fingerprint typically contains dozens of usable minutiae, which together form a unique digital signature.

6. Enrollment: Creating a Secure Fingerprint Template

During enrollment:

Minutiae are extracted from each scan.
A stable reference template is generated.
The template is encrypted and stored securely.

7. Secure Storage: Protecting Biometric Identity

Because biometric data cannot be changed like a password, security is critical. Modern systems use:

Encrypted template storage.
Secure elements or trusted execution environments.
Hardware-based cryptographic protection.

This ensures fingerprints cannot be reconstructed even if storage is compromised.

8. Authentication: Matching Ridges and Patterns

During authentication:

A live fingerprint is captured.
Its features are extracted.
The live template is compared with the stored template.

Matching algorithms align ridge patterns, compare minutiae relationships, and compute a similarity score. Access is granted only if the score crosses a secure threshold.

9. Accuracy and Anti-Spoofing Measures

To prevent fake fingerprints, systems use liveness detection, checking factors like skin conductivity, ridge deformation, and depth/texture variations to ensure the fingerprint comes from a real, live finger.

Conclusion

Fingerprint biometrics use unique ridge and valley patterns to create a secure digital identity. From image capture to minutiae extraction and encrypted matching, every step ensures accuracy, privacy, and security.

What seems like a simple touch is actually a powerful combination of biology, signal processing, cryptography, and embedded engineering, making fingerprints one of the most trusted security mechanisms in modern systems.

A Deep Dive Into ESP-CSI: Channel State Information on ESP32 Chips

Pratha Maniar — Wed, 19 Nov 2025 12:21:23 +0000

Most people know Wi-Fi only as a way to connect phones, laptops, and IoT devices to the internet. But Wi-Fi can do much more.

Espressif’s ESP-CSI (Channel State Information) technology allows ESP32-series chips to “sense” what is happening in the environment using only Wi-Fi signals-no cameras, no radar, no extra sensors.

Every Wi-Fi signal changes as it passes through a room.
People, walls, furniture, movement-everything affects the signal slightly.
ESP-CSI captures these tiny changes in the Wi-Fi channel and turns them into meaningful data.

This makes it possible to detect:

Human presence
Motion
Gestures
Indoor positioning
Environmental changes

And all of this works using only an ESP chip and Wi-Fi.

Why Is ESP-CSI Better Than RSSI?

Normally, Wi-Fi devices only report RSSI (Received Signal Strength Indicator), which is a single number representing signal strength.
However, CSI provides much more detailed information, including:

How each frequency of the Wi-Fi signal was changed.
How much it was absorbed or reflected.
How much noise is in the environment.
How the signal phase rotated.
How the signal was delayed.

Aspect	RSSI	CSI
What it shows	Overall signal strength (one value)	Detailed channel info (amplitude + phase per subcarrier)
Detail Level	Low	Very high
Sensitivity	Detects big changes only	Detects tiny movements (even breathing)
Use Cases	Basic connection quality, coarse location	Motion sensing, presence, gesture, indoor positioning
Interference	Easily affected	More stable if environment doesn’t change
Accuracy	Low	High

How Does ESP-CSI Work?

Wi-Fi uses OFDM, which splits one Wi-Fi channel into many smaller frequencies called subcarriers. Each Wi-Fi packet carries amplitude and phase information for every subcarrier.

When these subcarriers travel through the environment, they get affected by:

People absorbing energy.
Moving objects shifting the wave pattern.
Walls reflecting the signal.
Furniture and air slightly bending the waves.

The ESP chip measures two things for each subcarrier:

Amplitude-how strong the signal became.
Phase-how much the wave rotated or was delayed.

Together, this forms the CSI (Channel State Information) array.

When someone moves:

Amplitude values fluctuate.
Phase values shift in characteristic patterns.
Even small movements cause detectable changes.

These tiny variations act as “clues” about what happened in the environment. The ESP device captures this at the PHY layer, then exposes it to the user through CSI callback events in Espressif’s API.

Features of ESP-CSI

1. Detailed Channel Insights
CSI provides amplitude and phase information for every Wi-Fi subcarrier, giving much more detail than a single RSSI value. This allows precise sensing of environmental changes.

2. No Extra Hardware Required
Works on standard ESP32-series chips (ESP32, S2, C3, C6, etc.) using built-in Wi-Fi no special sensors or NICs needed.

3. High Sensitivity
Can detect both large movements and very small changes, such as breathing or slight object shifts.

4. Real-Time Processing
ESP chips can analyze CSI data locally and instantly, enabling fast responses without needing external servers.

5. Flexible Operating Modes
Supports multiple ways to collect CSI, including sniffer mode, router-based CSI, and device-to-device communication for advanced setups.

6. Stable and Robust
CSI amplitude data stays reliable even with typical indoor interference like chargers or other electronic devices.

7. Easy Software Integration
Fully supported in ESP-IDF and compatible with Espressif cloud tools, with open-source utilities to process and analyze CSI data.

Where Is ESP-CSI Used?

Human activity detection: Detect presence, movement, gestures, or even subtle actions like breathing-useful for security, elder care, and smart homes.

Indoor positioning: Provide accurate indoor location tracking for people or devices in buildings like malls, airports, and hospitals.

Environmental monitoring: Sense small changes in the environment through Wi-Fi signal variations.

Intrusion detection: Act as a motion sensor to detect unauthorized movement without cameras.

Asset tracking: Track the real-time location of important items in places like warehouses or hospitals.

Smart home automation: Enable location-based actions, such as auto-adjusting lights, AC, or appliances.

Chip Performance Ranking

Espressif categorizes the CSI capability of its chips approximately in the following order.
ESP32-C5 ＞ ESP32-C6 ＞ ESP32-C3 ≈ ESP32-S3 ＞ ESP32.

Meaning:

Newer chips, like C5 & C6, → better CSI quality.
C3 & S3 → good general performance.
Original ESP32 → lowest but still works.

How Can ESP-CSI Be Implemented?

Espressif provides three ways to obtain CSI data.

Method 1: Getting CSI from a Router (get_router_csi)

Setup: One ESP device + a router.
Process: ESP sends ping packets to the router. The router replies with packets containing CSI information. ESP receives those packets and extracts CSI (amplitude, phase, etc.). This is the simplest method-ideal for beginners.

Method 2: Exchanging CSI Between Two ESP Devices (get_device_csi)

Setup: Two ESP chips + router acting as a relay.
Process: Both ESP devices send ping packets to the router. The router forwards packets to the correct device. When Device B receives a ping from Device A, it replies with CSI. Device A then extracts CSI information.

Method 3: Getting CSI Using a Dedicated Packet Sender (get_broadcast_csi)

Setup: A device that sends broadcast packets + multiple ESP receivers.
Process: The transmitter sends broadcast packets on different Wi-Fi channels. All ESP devices (in monitor mode) receive these packets. Each ESP extracts CSI data independently.

Want to dive deeper?
Check out Espressif’s official CSI documentation here:
https://docs.espressif.com/projects/esp-techpedia/en/latest/esp-friends/solution-introduction/esp-csi/esp-csi-solution.html