SEGGER emCrypt: Cryptographic Primitives for Indian Custom-Crypto Teams on Cortex-M

Every Indian product team shipping a commercial Cortex-M device with cryptographic operations inside it, token authentication for an API, encrypted storage of patient data, AES-GCM protection of a proprietary wireless protocol, a custom key-exchange between a master controller and a constrained sensor node, or an ECDSA-signed licence file for a paid feature, eventually runs into the same library-selection question: what do we link against for AES, SHA, HMAC, and the ECC math, and what can we defend to our security-review team and our procurement team a year from now? The usual three candidates, roll-your-own, a deprecated open-source fork, or a heavyweight desktop crypto library, each fail a different test. This post walks through SEGGER emCrypt, the commercial cryptographic primitives library that sits below emSecure, emSSL, and emSSH in the SEGGER stack, and that Indian custom-crypto teams can also call directly from their own application code. GSAS Micro Systems is the authorized Indian engineering partner for SEGGER Microcontroller GmbH, and we support emCrypt licensing, integration, hardware-accelerator binding, and bring-up from our offices across India.

The Indian custom-crypto problem

The teams that need a standalone crypto primitives library in India are the ones where the security requirement is embedded in the product’s core value proposition rather than handed to them by a cloud SDK:

Scenarios in this article are illustrative, common patterns Indian engineering teams encounter, not specific named customers.

• Illustrative scenario, smart-meter. A typical Bengaluru-area smart-meter team designing under BIS IS 15959 needs AES-256-GCM to encrypt meter-to-DCU telemetry, HMAC-SHA-256 to authenticate control commands, and HKDF to derive per-session keys from a device-unique master key. None of this is a cloud SDK call; it is the product’s own protocol, and the crypto runs on a Cortex-M4 with 256 KB of flash and no TLS stack above it.
• A typical Pune-area EV-charging station OEM shipping OCPP messages over TLS also needs the underlying ECDSA primitives to sign its device-attestation payloads, and a CTR_DRBG to generate nonces. The TLS stack does most of the heavy lifting, but the product’s own attestation code calls the primitives directly.
• A typical Chennai-area medical-device maker exporting AES-encrypted patient data to a USB drive needs AES-256-CBC with PKCS#7 padding, a PBKDF2 key-derivation from a clinician-entered passphrase, and a SHA-256 integrity check, all running on a Cortex-M7 with emUSB-Device and emFile underneath.
• Illustrative scenario, consumer IoT. A typical Hyderabad-area consumer-IoT team shipping a product that works entirely offline, no cloud, no app server, no TLS, still needs AES to encrypt a local configuration blob in flash, HMAC to prevent tampering, and a seeded PRNG to produce session nonces for its BLE pairing flow.
• Indian defence-electronics OEMs needing FIPS-aligned primitives, AES-256, SHA-384, ECDSA P-384, HMAC-SHA-384, to qualify a product under the customer’s security specification. The exact programme is rarely namable publicly, but the engineering requirement is concrete: a defensible commercial library that a security reviewer can audit.

In every case the team is not building TLS. They are not building SSH. They are building their own cryptographic protocol on top of well-understood primitives, and they need those primitives to be correct, portable, performant, and commercially supported. emCrypt is designed for exactly this slot.

What emCrypt actually provides

emCrypt is SEGGER’s standalone cryptographic primitives library. It is written in portable C, ships with no dependency on an RTOS or a file system, and targets every Cortex-M and Cortex-A part SEGGER’s toolchain supports. The API surface covers the primitives a modern embedded crypto protocol needs:

• Symmetric block ciphers. AES in 128-, 192-, and 256-bit key lengths, operating in ECB, CBC, CTR, GCM, and CCM modes. 3DES is available for legacy interoperability with older systems that still demand it; SEGGER does not recommend it for new designs.
• Stream ciphers and AEAD. ChaCha20 as a standalone stream cipher and ChaCha20-Poly1305 as an authenticated encryption with associated data (AEAD) construction. ChaCha20-Poly1305 is the better choice on Cortex-M parts without AES hardware acceleration, it is substantially faster in pure software than AES-GCM.
• Hash functions. SHA-1 for legacy interoperability, the full SHA-2 family (SHA-224, SHA-256, SHA-384, SHA-512), and SHA-3 for teams standardizing on the newer NIST hash.
• Message authentication codes. HMAC over the full SHA-2 family, and CMAC over AES. HMAC-SHA-256 is the baseline for most Indian commercial products; CMAC is the choice where a team wants to amortize one AES hardware block across both encryption and authentication.
• Key derivation. PBKDF2 for passphrase-to-key derivation (the classic “clinician types a passphrase, the product derives an AES key”) and HKDF for the more modern key-schedule patterns used in protocols like Noise and TLS 1.3.
• Public-key primitives. RSA signature generation and verification, RSA encryption and decryption, ECC scalar multiplication over the NIST P-256, P-384, and P-521 curves, and Curve25519 / Ed25519 for teams choosing the modern curves over the NIST ones.
• Random number generation. CTR_DRBG and HMAC_DRBG, both seeded from the platform’s hardware TRNG (ST TRNG on STM32, Nordic RNG peripheral on nRF52/nRF53, Renesas TRNG on RA, and so on). The DRBG layer is what the application actually calls; the seed path is a small amount of glue code that the GSAS integration team helps wire up on each silicon family.

That list is the minimum toolkit a credible embedded crypto protocol needs. It is also, notably, smaller than the surface of a desktop-class library, there is no X.509 parser, no OCSP client, no TLS state machine, because those concerns live in emSSL, emSSH, and emSecure. emCrypt is deliberately the primitives layer, nothing more.

Pure software today, hardware-accelerated tomorrow

emCrypt is portable C. It runs on any Cortex-M, with no hardware accelerator, and it will produce correct answers and acceptable performance on an 80 MHz Cortex-M4 sensor node. For a meaningful fraction of Indian product teams, that is where the story ends, the pure-software path is fast enough for the product’s duty cycle.

For teams where performance or power dominates, the second half of the story matters. Every modern Cortex-M family from the major silicon vendors now ships with some form of cryptographic hardware acceleration:

• STM32: CRYP (AES), HASH (SHA), PKA (public-key accelerator), and TRNG on the L4, L5, U5, H5, H7, WBA, and WL families
• NXP i.MX RT: CAAM on the higher-end parts, DCP on the lower-end parts, for AES and SHA offload
• Nordic: CryptoCell 312 on nRF52840 and nRF5340 for AES, SHA, and ECC
• Renesas RA: the Secure Crypto Engine (SCE) on RA4 and RA6, covering AES, SHA, RSA, and ECC
• Microchip SAM: TrustZone-backed crypto on SAM L11 and the newer SAM families

emCrypt’s internal structure lets the AES, SHA, and public-key routines be rebound to the vendor HAL calls that drive the hardware block, typically through a thin shim layer. The application code does not change; the AES_GCM_Encrypt call still looks identical. What changes is that the work now runs on the CRYP block instead of the Cortex-M core, which delivers an order-of-magnitude speedup on the AES path and frees the core to do the parts of the protocol the hardware does not cover. For a smart meter team that needs to AES-GCM-encrypt thousands of telemetry records per day on a battery-powered node, the hardware-accelerated path is the difference between a 5-year and a 15-year battery life.

The GSAS engineering team works with Indian product teams on the vendor-HAL binding step, it is not difficult, but it is the kind of integration work that benefits from having done it before on the same silicon family.

emCrypt versus the alternatives

The library-selection conversation on any Indian commercial product eventually lands on a comparison. The honest version is:

• mbedTLS / Mbed-Crypto. Competent, widely used, open-source, and free. Larger footprint in the configurations that matter for a constrained Cortex-M, less commercial accountability when something breaks on a Friday night, and the project has had end-of-life and version-fork events in its history that have surprised teams mid-programme. For a prototype or a startup, mbedTLS is fine. For a commercial product shipping at volume where procurement wants a supported contract, emCrypt is the defensible choice.
• wolfCrypt. A direct commercial competitor, comparable API surface, comparable footprint, comparable performance. The choice between wolfCrypt and emCrypt for an Indian team usually comes down to the rest of the stack: if the product already uses emNet, emFile, embOS, or emUSB, emCrypt drops in with zero additional vendor relationships, zero additional contracts, and a single support line for the entire middleware stack.
• tinycrypt. A BSD-licensed library with a deliberately narrow scope, AES, SHA-256, ECC P-256, and not much else. Fine for a product that genuinely needs only those four primitives. Inadequate the moment the protocol reaches for PBKDF2, HKDF, P-384, ChaCha20-Poly1305, or AES-GCM.
• Rolling your own. Do not. Every Indian product team that has tried has discovered, usually during the security review three weeks before the launch date, that their AES implementation has a timing side-channel, their ECC implementation misses an edge case in the point-doubling, or their DRBG does not actually reseed. A correct cryptographic primitives library is not a junior-engineer Friday-afternoon project.

emCrypt is the commercial choice. It is not the only credible option, but it is the one that slots into the SEGGER middleware stack without adding vendor friction.

Indian integration patterns we see

The GSAS engineering team has helped Indian product teams integrate emCrypt into a range of product types over the last few years. The patterns that come up most often:

• Smart-meter encrypted uplink: AES-256-GCM for the meter-to-DCU message payload, HMAC-SHA-256 for the authenticated control-command path, CTR_DRBG for session nonces, and HKDF to derive per-session keys from a device-unique master key injected at the factory via Flasher Secure. See the Flasher Secure encrypted-firmware post for the factory-side mechanics.
• Encrypted USB patient-data export: AES-256-CBC with PBKDF2-derived keys, SHA-256 integrity check, and the whole thing running on a Cortex-M7 with emUSB-Device presenting a mass-storage interface and emFile providing the FAT layer on top of the encrypted blob.
• BLE proprietary pairing: ECDH over Curve25519 for the key agreement, ChaCha20-Poly1305 for the session AEAD, and HKDF to derive the session keys from the shared secret. The whole flow fits in well under 20 KB of code on a Nordic nRF52840 and delivers stronger security than the default Bluetooth pairing stack on the same silicon.
• Factory-signed licence files: ECDSA P-256 signature verification on a per-boot licence blob, pairing naturally with emSecure-ECDSA for the higher-level signing workflow. See the emSecure secure-boot post for the signing-workflow side.

None of these are exotic protocols. They are the everyday custom-crypto patterns that commercial Indian products use when they cannot outsource the entire security question to a TLS library.

Further reading

• SEGGER emCrypt product page at segger.com
• SEGGER emSecure product page at segger.com
• SEGGER emCrypt at GSAS
• SEGGER emSecure at GSAS
• SEGGER emSSL at GSAS
• SEGGER Flasher Secure at GSAS
• SEGGER emSecure-RSA and emSecure-ECDSA for Indian secure boot on Cortex-M
• SEGGER Flasher Secure for encrypted firmware delivery to Indian EMS
• SEGGER at GSAS

Why GSAS for the Indian rollout

A cryptographic primitives library is easy to pick incorrectly and hard to replace once the product is shipping. GSAS Micro Systems is the authorized Indian engineering partner for SEGGER Microcontroller GmbH, and we work with Indian product teams on the full emCrypt rollout, library licensing and supply in INR, silicon-family binding to the hardware crypto accelerators on STM32, i.MX RT, nRF52/nRF53, Renesas RA, and Microchip SAM, integration with the rest of the SEGGER middleware stack, and security-review support for the custom protocols the product team writes on top. Teams across Bengaluru, Chennai, Hyderabad, Delhi NCR, Mumbai, and Pune reach the GSAS engineering desk for emCrypt architecture reviews, commercial proposals, and on-site bring-up. When your next product’s security review asks what crypto library it links against, the answer you want is a supported commercial name with a defensible API surface, not a forked open-source project and a shrug.