Low-Exponent RSA Licenses on Constrained Hardware
Helios Licensing issues 300,000 signed license files for on-premise software. Each license contains the customer name, seat count, and expiry date; the vendor signs it with RSA-2048 using public exponent e=3 and PKCS#1 v1.5 with SHA-256. A small C parser on the customer's server verifies the signature and then trusts the fields. Activation traffic uses TLS 1.2 with RSA key exchange and AES-128-CBC. A hardware partner proposes moving offline verification to a microcontroller with 8 KB of RAM and a 200 ms budget, using 1024-bit RSA keys and the same v1.5 padding, because 'verification with e=3 is cheap.' The security team notes that a 2010-era parser bug allowed a forged signature when a field contained extra bytes. Management wants a 10-year licensing roadmap.
1. Is e=3 itself the defect? Explain the actual failure mode behind the 2010 forgery and recommend a signature scheme for a 10-year roadmap.
Read the worked answer
No. A small public exponent is not inherently weak; RSA security depends on modulus size and padding, and e=3 only makes public operations fast. The 2010 bug is the classic PKCS#1 v1.5 verification failure: the parser accepted extra bytes or did not check the full encoded digest structure, so an attacker could craft a value that verified without the private key. With e=3, such format bugs are easier to exploit because the attacker can compute a cube root over the integers.
The lesson is strict, constant-time verification against a known-good encoding, not a ban on e=3. For a 10-year roadmap, move new licenses to RSA-PSS with SHA-256 and a 2048- or 3072-bit key, or to Ed25519. PSS is randomized and has a clean security proof; Ed25519 is fast and has small keys. Keep v1.5 only for legacy verification, and reject non-canonical encodings. Do not let the microcontroller constraint drive the trust anchor down to 1024-bit RSA.
2. Assess the 1024-bit RSA and 200 ms proposal. What key size and verification approach would you accept for offline license checks on an 8 KB RAM device?
Read the worked answer
1024-bit RSA provides roughly 80 bits of security and has been deprecated for government use for over a decade; NIST guidance treats 2048-bit RSA as the minimum through 2030 and 3072-bit for beyond. A 10-year license roadmap cannot anchor trust in 1024-bit keys.
The 200 ms budget is not the constraint it appears to be: RSA verification with e=3 is cheap, and a 2048-bit verification on a small Cortex-M class device is typically a few milliseconds, not 200. The 8 KB RAM limit matters more for TLS handshakes than for raw signature verification; a 2048-bit modulus is 256 bytes, and the parser can be written without large buffers. Accept 2048-bit RSA with PSS and strict parsing, or Ed25519 if the crypto library fits and has been validated. Measure the actual stack and heap, not the vendor's claim. If the device truly cannot do 2048-bit, change the device or move verification to a secure element; do not weaken the whole licensing trust chain.
3. What is wrong with RSA key exchange plus AES-128-CBC for activation traffic, and what should replace it? Consider forward secrecy and padding.
Read the worked answer
Static RSA key exchange encrypts a pre-master secret under the server's long-term RSA key. Anyone who records the traffic and later obtains that private key can decrypt every captured session; there is no forward secrecy. That is unnecessary exposure, and it is exactly the pattern that harvest-now-decrypt-later attacks exploit.
AES-128-CBC in TLS 1.2 is also a poor choice: CBC requires MAC-then-encrypt constructions that have produced padding-oracle attacks such as Lucky 13, and the cipher suite in question uses SHA-1 for the MAC. Replace it with TLS 1.3, or TLS 1.2 with ECDHE and AES-128-GCM or ChaCha20-Poly1305. ECDHE gives forward secrecy; GCM is AEAD and removes padding oracles. Use an RSA-PSS or ECDSA certificate for authentication, disable static RSA and CBC suites, and set HSTS. If legacy clients cannot do TLS 1.3, terminate them on a separate gateway with tight monitoring and a defined retirement date. The activation server's certificate key must be protected in an HSM because it is a high-value signing key.