Even if an encryption algorithm like AES or HMAC-SHA2 is mathematically secure, real devices can leak information through the way they operate. For example, attackers might measure power use, electromagnetic signals, or timing to guess secret keys (side-channel attacks), or deliberately cause errors in the device to bypass security (fault-injection attacks).
Devices that are physically exposed, like embedded chips in consumer electronics, IoT devices, or smart cards, can be vulnerable. Protection against these attacks ensures that sensitive data, keys, and integrity checks remain secure, even if attackers can observe or tamper with the device.
Note: If the device is fully secured in a controlled environment where attackers cannot get close, standard encryption is usually sufficient.
HMAC-SHA2 ensures message integrity and is mathematically strong. On unprotected chips, secret keys or internal computations can leak or be corrupted, allowing attackers to forge messages or bypass integrity checks. Protected HMAC-SHA2 prevents these real-world attacks.
Not necessarily. If your embedded device is in a fully controlled environment where attackers (including insiders) cannot get physically close or interfere with it, standard AES and HMAC-SHA2 are usually sufficient. Protection becomes critical only when the device is exposed to side-channel or fault-injection attacks.
That said, if your device needs high-assurance certification, you will need protected cryptography.
FortifyIQ’s software libraries use the same proprietary protection algorithms we apply in our hardware IP cores. These techniques, proven in lab validation both in hardware and in software, mask sensitive intermediate values, randomize execution behavior, and detect and prevent fault injection attempts, ensuring strong resistance to side-channel attacks without requiring hardware countermeasures.
Yes. FortifyIQ’s patented STORM (for AES) and Threshold Implementation (for HMAC-SHA2) countermeasures share the same security-proven mathematical basis as our hardware protections. These algorithms, implemented in our software, have been validated to meet the highest standards for physical security, FIPS 140-3 (levels 1-4) and Common Criteria AVA_VAN.5, demonstrating resilience against both Side-Channel Attacks (SCA) and Fault Injection Attacks (FIA).
All known cache attack techniques are rendered ineffective by our implementations. This includes both time-based and power-based variants.
Yes. Our libraries are designed to bypass unprotected hardware crypto and add hardened protection via software, even on deployed devices.
Absolutely. Our software can serve as a drop-in secure replacement, making it possible to retrofit protection where hardware can’t be changed.
Our protected AES and HMAC-SHA2 libraries meet the security requirements for FIPS 140-3 (Levels 1–4), SESIP Levels 1-5 and Common Criteria up to AVA_VAN.5, enabling compliance in regulated industries.
At the algorithmic and implementation levels, we harden cryptographic operations so that injected faults (such as changing gate states) do not reveal secrets.
No. Some classes of FI, such as Statistical Ineffective Fault Attacks (SIFA), rely on faults that cause no change whatsoever and are therefore inherently undetectable. FortifyIQ uses mathematical countermeasures that prevent sensitive information from being leaked, rather than relying on detection.
Only FortifyIQ offers high-performance software cryptographic libraries that enable regulatory compliance at all levels.
FortifyIQ’s high-performance software cryptographic libraries are compliant with FIPS 140-4 levels 1-4, SESIP Levels 1-5, and Common Criteria up to AVA_VAN.5
Ascon and PRESENT are strong choices for minimizing size and power, but they are not optimized for high-assurance environments or regulatory compliance. FortifyIQ’s AES libraries offer proven, validated resistance to side-channel and fault-injection attacks, and are certified-ready for FIPS 140-3 and Common Criteria requirements that lightweight ciphers typically cannot meet in software today. PRESENT, in particular, is vulnerable to certain attacks if not implemented with extra protections, and its smaller block size (64 bits) can be a limitation for modern security requirements.
Yes. Our AES implementation is configurable for code size, RAM, and throughput trade-offs. In its smallest form, it is on par with Ascon’s memory footprint while maintaining full protection against side-channel and fault-injection attacks. PRESENT is not available in software.
Migration is straightforward, whether from hardware or software implementations. Both algorithms can be supported in parallel during transition, and FortifyIQ provides an API-compatible abstraction layer to ease integration.
The reference software for Ascon and PRESENT is free and open source. However, the hardware IP involves licensing, integration, and validation costs, similar to AES hardware cores.
FortifyIQ’s STORM AES is viable for demanding applications, delivering::
This makes it faster than unprotected TinyAES, and slower (by about 10x) than the highly optimized unprotected OpenSSL that uses CPU AES acceleration instructions.
No. Asymmetric cryptography (such as ECC or RSA) is typically used only during infrequent operations, such as secure boot, key exchange, or firmware verification. These actions occur at startup or update time, not during regular device operation. Once the device is running, it uses faster symmetric algorithms (like AES and HMAC) for all ongoing cryptographic tasks. So your device operates at full speed during normal use, and the impact of using a software secure implementation of asymmetric cryptography is therefore minimized to its use during startup and update, and to applications where asymmetric crypto is actively used during runtime.
Yes. FortifyIQ’s software cryptographic libraries are modular and can be used independently. If your application requires only encryption or decryption, you can use the hardened AES library on its own. Similarly, HMAC-SHA2 can be used independently for message authentication or integrity checks. Each library is fully protected against side-channel and fault injection attacks and does not depend on the others.
No. The ECC/RSA library is also modular and typically used only for specific tasks like secure boot, digital signatures, or key exchange. If your application does not require asymmetric cryptography, you can use just AES, HMAC, or both.
Yes. Our licensing model is designed to support post-production and fielded devices, making it ideal for long product lifecycles.
Yes. Both the software libraries and hardware IP cores are delivered with a documented abstraction layer that exposes a unified API. This means your application code interacts with the same interface, regardless of whether the underlying implementation is software or hardware.
This flexibility is especially useful when:
FortifyIQ’s unified API reduces integration effort, simplifies testing, and supports long-term maintainability across diverse hardware configurations.
Our techniques minimize overhead through efficient use of look-up tables and redundant Tlogic. The energy use is approximately 10x that of unprotected cryptography in software. Full energy profiles for typical MCUs will be available soon.
Our cryptographic libraries meet the requirements of FIPS 140-3 Levels 3,4, Common Criteria AVA_VAN.5, and SESIP Levels 1-5, forming a strong foundation for compliance across regulated domains. This includes medical (IEC 62304, FDA guidance), automotive (ISO/SAE 21434), (IEC 62443), and IoT (EN 303 645, NISTIR 8259) frameworks, where it is ready for cryptographic module certification.
Yes. FortifyIQ’s software libraries are designed to meet the security requirements of SESIP at all levels, including resistance to side-channel and fault injection attacks, secure cryptographic implementation practices, and documented design.
FortifyIQ’s high-assurance libraries run on a wide range of processors, from microcontrollers (MCUs) to high-performance CPUs (MPUs), including:
The libraries are tailored to the device’s processor, memory, and performance characteristics, ensuring optimal use of available resources. They are optimized for smart cards, constrained MCUs, and general-purpose CPUs using lookup tables (LUTs) on ROM and minimal RAM, making them suitable even for highly resource-limited platforms.
Yes. FortifyIQ provides both software libraries and hardware IP cores with a unified, documented abstraction layer, so you can switch between software and hardware implementations without changing your code. This makes it easy to:
This flexibility allows you to meet evolving performance and security needs across a range of devices, from legacy systems to next-generation SoCs.
Our secure AES and HMAC libraries are successfully deployed on a legacy 1 GHz ARM processor, encrypting/decrypting video streams at large scale. Their security has been validated and meets the highest assurance requirements.
Yes, both AES-256 and HMAC-512 are inherently secure with quantum computers.
PQC itself is the SW public key for the Quantum Era.
Yes. During this transition period, many systems require both classical and post-quantum public key algorithms for compatibility and future-proofing.
We provide a hybrid software solution that includes both classical public key cryptography (such as RSA and ECC) and post-quantum cryptography (like Kyber and Dilithium), allowing you to support both in your product today, using only software.
Our PQC meets the highest cryptographic security standards. It is algorithmically protected from side-channel and fault injection attacks, similarly to our other products.
The differences between hardware and software implementations regarding performance are significant. If your performance and power requirements are lenient, we suggest a software implementation, since it is flexible and cheap.
Our high-assurance PQC libraries deliver comparable performance and ROM footprint to standard (naive) implementations, while requiring less data RAM.
Ask us!
