SEGGER emSecure-RSA and emSecure-ECDSA for Indian Secure Boot on Cortex-M

Every Indian product team shipping a Cortex-M device today, whether it is a consumer IoT gateway, a CDSCO-registered patient monitor, an IATF 16949 automotive ECU, a BIS-certified smart meter, or a DGQA-reviewed defence subsystem, has the same problem sitting on the critical path between R&D and mass production: how do you prove that the firmware running on the device is the firmware your engineering team actually built and released, and not a modified image injected somewhere between the build server and the contract manufacturer? That question is the secure-boot problem, and in India the regulatory and OEM-customer pressure to answer it with a contractually defensible process is increasing every quarter. This post walks through how SEGGER emSecure-RSA and emSecure-ECDSA solve the signing and verification halves of the problem on Cortex-M targets, and how they pair with Flasher Secure on the production floor to close the loop with the Indian contract-manufacturing partner ecosystem. GSAS Micro Systems is the authorized Indian engineering partner for SEGGER Microcontroller GmbH, and we support every element of this workflow, library licensing, bootloader integration, Flasher deployment, and production-line commissioning, from our offices across India.

The Indian secure-boot problem in plain terms

Before the library discussion, it is worth stating the threat model the way an Indian product team typically encounters it:

• Supply-chain injection. The firmware binary travels from the R&D team’s build server in Bengaluru or Pune to a contract manufacturer in Chennai, Pune, or a tier-3 town. At some point during that transit, or during a night shift on the CM floor, a modified image could be substituted for the authorized one. Without a cryptographic signature on the image, neither the OEM nor the CM’s own quality team can prove at the point of programming that the binary is genuine.
• Field firmware updates. Once a device is in the field, OTA firmware updates are a second injection point. A malicious actor with access to the update channel, or with physical access to the device’s external flash, can write a modified image and let the bootloader run it. Again, without a signature verification on every boot, the device has no way to refuse the modified image.
• Regulatory expectations. CDSCO Medical Device Rules (and IEC 62304 downstream) treat firmware integrity as part of the device-history-record. IATF 16949 and the customer-specific requirements from Indian Tier-1 automotive customers require authenticated firmware artifacts. BIS IS 15959 for smart metering and the CEA guidelines for grid-connected equipment increasingly reference signed firmware. The DGQA and iDEX review process for defence electronics treats firmware provenance as a mandatory evidence item. The specific wording varies; the required engineering capability does not.

The required capability reduces to: produce a firmware image with a cryptographic signature at release time, and verify the signature on the device before every boot or update. emSecure-RSA and emSecure-ECDSA are the two SEGGER libraries that implement exactly this, nothing more, nothing less, in a form that slots into a Cortex-M bootloader with minimal ceremony.

emSecure-RSA and emSecure-ECDSA: the two libraries

SEGGER ships emSecure as two sibling libraries, selected by the algorithm family the product team picks for their root-of-trust:

• emSecure-RSA implements RSA signature verification on the target, with support for RSA-1024, RSA-2048, RSA-3072, and RSA-4096 key lengths. It is a pure-software implementation, no hardware crypto accelerator is required. It runs on a Cortex-M0+, a Cortex-M4, a Cortex-M7, or any other Arm target SEGGER’s toolchain supports. Typical verification latency on a Cortex-M4 at 72 MHz for RSA-2048 is on the order of a few hundred milliseconds; RSA-4096 is several times that. The signature itself is fixed-size: 256 bytes for RSA-2048, 512 bytes for RSA-4096. RSA is the conservative choice, well understood, broadly accepted by regulators, and easy to explain to a non-cryptographer auditor.

• emSecure-ECDSA implements Elliptic Curve DSA signature verification, with support for the NIST P-256, P-384, and P-521 curves. It is smaller in both code footprint and signature size, a P-256 signature is 64 bytes, versus 256 bytes for RSA-2048, and it is substantially faster on the same Cortex-M silicon. For a BLE-battery-powered sensor node where flash and boot-time matter, ECDSA is almost always the better choice. For a product where the customer’s security team has pre-approved RSA and wants nothing else, RSA is fine.

Both libraries are standalone, they do not require an RTOS, a file system, or a network stack underneath them. They can be integrated into a bare-metal bootloader in a few hundred lines of glue code. They are built to run in the same flash partition as the bootloader itself, which means the signature-check code is part of the root-of-trust and is therefore protected by the same flash write-protect bits that protect the bootloader.

emSecure versus emCrypt: where the line is

Indian product teams sometimes confuse emSecure with emCrypt, because both are SEGGER security libraries and both ship with the broader emSSL / emNet stack. The distinction is important for procurement and for bill-of-materials decisions.

emCrypt is the low-level cryptographic primitives library. It provides AES (including AES-GCM and AES-CCM), SHA-1, SHA-256, SHA-384, SHA-512, HMAC, HKDF, PBKDF2, RSA math, ECC math over the NIST curves, and the random-number infrastructure. It is the library you reach for when you need AES-CBC encryption inside your application code, or when you are building a custom crypto protocol.

emSecure is the higher-level signing and verification library. It builds on emCrypt internally, the SHA hash and the RSA or ECC math come from emCrypt, but it exposes a two-function API on the target: “is this signature valid for this binary?” and “what is the signer’s identity?” Everything else is hidden. You do not write AES calls in a bootloader that uses emSecure; you write emSecure_Verify(...).

The licensing pattern is that most Indian product teams starting from scratch need both libraries, because emSecure’s internal dependencies pull in the emCrypt primitives it uses. Teams already licensing emSSL or emSSH often already have emCrypt in their BOM, and emSecure is the incremental addition.

The two-side signing workflow

The way emSecure is used in practice is as a two-side tool. There is a signing side that runs offline on a secured OEM machine, and there is a verification side that runs on every target device.

Signing side: offline, on the OEM’s secured workstation

SEGGER ships command-line signing tools with the emSecure library package. A release engineer on the Indian OEM’s build machine, typically a hardened Linux or Windows workstation inside the R&D network in Bengaluru, Pune, or Hyderabad, runs the signing tool against the release firmware binary and the OEM’s private key. The output is a signed firmware image: the original binary plus an appended signature blob plus the minimal metadata (signer identity, algorithm identifier, timestamp) needed for the target-side verifier to locate the signature and route it to the right algorithm.

Critical points for Indian OEMs:

• The signing key must never leave the signing workstation. Store it in a hardware security module if the OEM’s compliance posture requires one; store it in an encrypted keystore otherwise. Access to the signing machine becomes the control point for what firmware can reach the CM.
• The signing step is part of the release process, not the build process. Build servers produce unsigned images for continuous integration and automated test. Only the release engineer, with explicit authorization, runs the signing tool on the approved candidate build.
• Every signed release is logged. Version, SHA-256 of the pre-signed binary, timestamp, signer identity, approval reference. This log is the audit trail your CDSCO or DGQA reviewer will ask for.

Verification side: on the Cortex-M target’s bootloader

On the target device, the bootloader is linked against emSecure-RSA or emSecure-ECDSA and contains the OEM’s public key, hardcoded or stored in a dedicated flash region that is write-protected at programming time. On every power-up, the bootloader’s sequence is:

1. Compute the SHA-256 hash of the application image in flash.
2. Call emSecure_Verify() with the hash, the appended signature, and the hardcoded public key.
3. If the verification succeeds, jump to the application entry point.
4. If the verification fails, refuse to boot the application, log the failure, and either halt or enter a safe-mode recovery image.

This is a few hundred lines of bootloader code on top of the standard Cortex-M bring-up, and it is the only path by which the application ever gets executed. The same verification path runs on every OTA update before the new image is activated, see the embOS bootloader and OTA pattern post for the full dual-bank OTA flow that emSecure plugs into.

Pairing with Flasher Secure for the production-floor handoff

The signed image still needs to be programmed into the target at the Indian CM. This is the point at which Flasher Secure and the Flasher Secure Server (FSS) on the OEM side become critical:

• The OEM uploads the signed firmware image to FSS on the OEM’s secure infrastructure, typically hosted inside the OEM’s own Bengaluru or Pune network so that no firmware ever transits a third-party cloud.
• FSS authorizes a specific Flasher Secure unit on the Indian CM’s programming line to program a specific number of units, for example, 5,000 units over a 24-hour window.
• The CM operator pulls an authorized job onto the programming rack at the CM in Chennai, Pune, or wherever the line is running. Flasher Secure programs each unit with the signed image; the signature is already baked into the binary, so there is nothing extra for the CM to get right.
• After the authorized count is consumed, the Flasher Secure unit stops programming until the next authorization arrives. The CM cannot over-produce, and the CM cannot substitute a modified image, because any modified image would fail the bootloader’s emSecure verification on first power-up and the unit would flunk final-test.

The SEGGER Flasher Secure encrypted-firmware post covers the CM-line mechanics in detail. The important point for this post is that emSecure and Flasher Secure are complementary: emSecure enforces the cryptographic verification on the target; Flasher Secure enforces the authorized-programming count at the factory. Together they eliminate both the supply-chain injection risk and the over-production risk in one coordinated workflow.

Indian programme patterns that benefit most

• CDSCO medical device OEMs filing under IEC 62304, every signed release is logged, the signature is verified on every boot, and the device-history-record has a cryptographic chain of custody from the R&D build machine to the deployed device. SEGGER’s SystemView IEC 62304 evidence workflow complements this on the runtime-observation side.
• Indian Tier-1 automotive suppliers shipping ECUs to global OEM customers whose supplier manuals already require signed firmware and a documented production-authorization log. The embOS-Safe ISO 26262 automotive post covers the functional-safety side that sits alongside.
• Indian defence electronics programmes under iDEX and DGQA: firmware provenance is a mandatory evidence item in the review package, and an emSecure-backed bootloader is the cleanest way to produce that evidence.
• Indian smart-meter OEMs under BIS IS 15959: signed firmware is an explicit requirement for grid-connected metering equipment, and the OEMs that pass BIS type-testing with the least rework are the ones who chose their signing library at project start, not at certification crunch time.

Further reading

• SEGGER emSecure product page at segger.com
• SEGGER emCrypt product page at segger.com
• SEGGER emSecure at GSAS
• SEGGER emCrypt at GSAS
• SEGGER Flasher Secure at GSAS
• SEGGER Flasher Secure for encrypted firmware delivery to Indian EMS
• SEGGER embOS bootloader and OTA reference on STM32 and nRF52
• SEGGER emNet and emSSL for TLS from Indian IoT devices to AWS IoT Mumbai and Azure IoT Central India
• SEGGER at GSAS

Why GSAS for the Indian rollout

emSecure is not a library you drop into a bootloader over a weekend without thinking. The key-management, release-engineering, factory-authorization, and audit-trail pieces all matter as much as the C code. GSAS Micro Systems is the authorized Indian engineering partner for SEGGER Microcontroller GmbH, and we work with Indian OEMs end-to-end, library licensing and supply in INR, bootloader integration assistance, Flasher Secure deployment on the CM line, and training for the OEM release engineering team. Teams across Bengaluru, Chennai, Hyderabad, Delhi NCR, Mumbai, and Pune reach us for architecture reviews, commercial proposals, and on-site bring-up support. When the next audit asks how your firmware reached the field, your answer should be a signed binary, a logged release, and a verifiable root-of-trust, not a shrug.