ISO/IEC 29192-4: Lightweight Cryptography — Part 4: Asymmetric Mechanisms

Public-key cryptography on constrained devices has long been considered impractical due to the enormous computational cost of modular exponentiation required by traditional algorithms like RSA. ISO/IEC 29192-4 changes this paradigm by standardising lightweight asymmetric mechanisms built on elliptic-curve cryptography (ECC) and identity-based cryptography (IBC), enabling key exchange and digital signatures on devices with limited CPU, memory, and energy budgets.

A 256-bit ECC signature provides security equivalent to a 3 072-bit RSA signature but can be computed in a fraction of the time and with vastly smaller key storage. For an 8-bit MCU, an ECC point multiplication can complete in under 100 ms at 8 MHz, making public-key crypto viable even on sensor-class devices.

Elliptic-Curve Based Signature Schemes

EC-DSA and EC-GDSA for Lightweight Environments

The standard specifies two elliptic-curve digital signature algorithms optimised for constrained implementation: EC-DSA (Elliptic Curve Digital Signature Algorithm) and EC-GDSA (Elliptic Curve German Digital Signature Algorithm). Both operate over prime-field curves (GF(p)) with key sizes of 160–256 bits. The standard defines a minimal set of curve parameters that balance security with computational efficiency — curves are chosen with cofactor h = 1 to simplify implementation, and with pseudo-random or special primes (e.g., NIST P-256 or Curve25519) that enable fast reduction.

On constrained platforms, signature verification is typically 2–3 times faster than signature generation because verification uses the public key (a point on the curve) while generation uses the private key (a scalar). If your application primarily involves devices signing data and a powerful gateway verifying, this asymmetry works in your favour.

Identity-Based Cryptography (IBC)

Eliminating Certificate Overhead

One of the most innovative features of ISO/IEC 29192-4 is the inclusion of identity-based signature and encryption mechanisms. In IBC, the public key is derived directly from an identifier string — such as a device serial number, email address, or MAC address — eliminating the need for public-key infrastructure (PKI) certificates. A trusted Private Key Generator (PKG) computes the corresponding private key and distributes it to the device during provisioning. This dramatically reduces storage and communication overhead, as no certificate chains need to be transmitted or validated.

Mechanism	Type	Key Size (bits)	Signature Size	Hardware Cost	Certificate-Free
EC-DSA	Digital signature	160–256	320–512 bits	~10 000–15 000 GE	No
EC-GDSA	Digital signature	160–256	320–512 bits	~10 000–15 000 GE	No
IBC (signature)	Identity-based signature	160–256	320–512 bits	~12 000–18 000 GE	Yes
IBC (encryption)	Identity-based encryption	160–256	N/A	~12 000–18 000 GE	Yes
EC-KA	Key agreement	160–256	N/A	~8 000–12 000 GE	No

Engineering Design Insights

Hybrid Approaches for Practical Systems

Pure asymmetric cryptography is still too expensive for the most constrained Class 1 devices. The standard therefore encourages hybrid approaches: use a lightweight asymmetric mechanism (e.g., EC-KA key agreement from 29192-4) to establish a shared secret, then switch to a symmetric lightweight cipher (PRESENT or Trivium from Parts 2 and 3) for bulk data encryption. This hybrid model provides the key-management advantages of public-key cryptography while keeping the per-byte encryption cost low.

Side-Channel Resistance for ECC

Elliptic-curve scalar multiplication is vulnerable to timing and power-analysis attacks if not implemented with care. ISO/IEC 29192-4 mandates the use of Montgomery ladder or double-and-add-always algorithms to ensure constant-time execution, and recommends projective-coordinate representations to avoid expensive modular inverses during point addition. Implementations that pass the standard’s test vectors with fewer than 5 % performance overhead for side-channel countermeasures are considered compliant.

The hybrid ECC + lightweight symmetric model is now the de facto security architecture for modern IoT platforms such as TLS 1.3 for constrained devices (EDHOC) and the LoRaWAN specification, proving the practical value of ISO/IEC 29192-4’s approach.

Identity-based encryption shifts trust to the Private Key Generator. If the PKG is compromised, all user private keys derived from it are compromised. This key-escrow property is fundamental to IBC and must be accounted for in system-level threat models — never use IBC in applications that require non-repudiation.

Frequently Asked Questions

Q1: Is ECC on an 8-bit MCU practical without a hardware accelerator?
Yes — a 160-bit scalar multiplication can be done in software in 1–5 seconds on an 8-bit MCU. For applications where key exchange happens once per session (minutes or hours), this is acceptable. Hardware accelerators can reduce this to milliseconds.

Q2: What curves are recommended for IoT applications?
The standard recommends secp160r1, secp192r1, and secp256r1 for general use, and special curves such as Curve25519 for high-security Diffie-Hellman key agreement. The choice depends on the target security level and the available code size.

Q3: How do I bootstrap trust in the PKG for IBC?
The PKG’s public parameters must be pre-provisioned in the device firmware or obtained over an authenticated channel (e.g., during manufacturing). ISO/IEC 29192-4 does not define this bootstrap process; it is assumed to be handled by the system’s secure provisioning infrastructure.

Q4: Can identity-based encryption replace TLS in IoT?
For many use cases, yes. IBC eliminates certificate exchange and validation, which are among the most computationally expensive parts of a TLS handshake on constrained devices. However, IBC is not a drop-in replacement — the key-escrow property requires careful system architecture.