Contact Us

FortifyIQ Software Cryptography FAQ FAQ

FAQ Categories

Basics on Protected Cryptography

What are side-channel and fault-injection attacks, and why would my device need protection against them?

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.

AES is a standard encryption algorithm that is mathematically secure. However, on real embedded devices, attackers can sometimes recover keys or data by observing side-channel leakage (power use, EM emissions, timing) or by inducing faults. Protected AES adds safeguards against these attacks so the keys and encrypted data remain secure.

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.

Security Foundations

FortifyIQ’s cryptographic 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).

The libraries are built to meet the most stringent security requirements. SCA and FIA resistance has been thoroughly validated to comply with top cryptographic regulatory standards.

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 cryptographic libraries 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.

Fault Injection Prevention and Detection

At the algorithmic and implementation levels, we harden cryptographic operations so that injected faults (such as changing gate states) do not reveal secrets.

  • Prevention ensures that injected faults do not compromise the cryptographic computation, even if the fault is undetected.
  • Detection identifies abnormal fault behavior and can trigger countermeasures such as halting the computation or raising an alert.

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.

Comparison to Lightweight Cryptography: Ascon

Only FortifyIQ offers high-performance software cryptographic libraries that enable regulatory compliance at all levels.

  • If you need encryption/decryption: Our protected AES libraries deliver performance on par with Ascon, while meeting even the strictest security compliance standards, including resilience to cache, side-channel, and fault injection attacks.
  • If you use Ascon for lightweight software applications: We offer a configurable AES implementation that is far more cryptographically secure, resistant to side-channel and fault-injection attacks, and fully compliant with regulatory standards. Size and performance can be tuned to your requirements.
  • If you need AES plus hashing: Our high-performance AES + CCM implementation delivers both encryption and authentication in a compliant, hardened package.

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 

  • Encryption/Decryption: Our protected AES libraries deliver performance on par with Ascon and significantly outperform PRESENT in most software environments, while meeting the strictest security compliance standards, including resilience to cache, side-channel, and fault-injection attacks.
  • Authentication: Our AES-CCM libraries offer full protection and compliance readiness that neither Ascon nor PRESENT provides in their standard software forms.

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.

Performance & Deployment

FortifyIQ’s STORM AES is viable for demanding applications, delivering::

  • Up to 100 Mbps on a 1.2 GHz ARM processor
  • Up to 900 Mbps on a 3.4 GHz laptop

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 hardened asymmetric cryptographic library is therefore minimized to its use during startup and update, and to applications where asymmetric crypto is actively used during runtime.

Yes. FortifyIQ’s 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.

Use FortifyIQ’s hardware IP cores when your application needs high throughput, low power, and minimal area, such as in real-time or performance-critical environments. These are delivered as soft macros and are integration-ready. Choose our software cryptographic libraries for legacy or cost-constrained systems where hardware integration isn’t viable. They share the same SCA/FIA-hardened countermeasures as our hardware cores, and can reach up to 900 Mbps on standard CPUs.

Yes. Both the cryptographic 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:

  • You are starting with a software prototype and plan to migrate to hardware in a later silicon revision.
  • You are deploying in isolated or constrained environments (e.g., TEEs) while keeping the same API and high-assurance cryptographic behavior across software and hardware.
  • You want to evaluate performance, power, or cost trade-offs between hardware and software without rewriting your application code.
  • Your product line spans devices with and without cryptographic accelerators, and you want to maintain a single firmware base.
  • You are combining FortifyIQ’s software with other hardware or software components (e.g., using hardware ECC/RSA with FortifyIQ’s hardened AES and HMAC libraries).

FortifyIQ’s unified API reduces integration effort, simplifies testing, and supports long-term maintainability across diverse hardware configurations.

Yes. They are fully compatible with over-the-air (OTA) deployment strategies, enabling you to secure devices already in the field through firmware updates alone.

Compliance & Validation

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. The libraries have been tested against side-channel attacks using TVLAevaluations to meet the demands of high-assurance standards, exceeding 100K traces with no leakage detected. FIAprotection is achieved via fault detection and shutdown mechanisms without the need for hardware sensors.

Yes. FortifyIQ’s cryptographic 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.

Technical Integration

FortifyIQ’s high-assurance libraries run on a wide range of processors, from microcontrollers (MCUs) to high-performance CPUs (MPUs), including:

  • ARM (Cortex‑M, Cortex‑R, Cortex‑A)
  • RISC‑V (with or without crypto extensions)
  • x86 / x64 (with or without AES‑NI)

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:

  • Start with software during early development or in lower-cost devices
  • Migrate to hardware for higher performance, lower latency, or power efficiency
  • Mix and match, e.g., using software AES and HMAC alongside hardware ECC/RSA or PQC

This flexibility allows you to meet evolving performance and security needs across a range of devices, from legacy systems to next-generation SoCs.

Yes. FortifyIQ’s hardened cryptographic libraries integrate seamlessly with existing hardware IP, including FortifyIQ’s CryptoBoxes or standalone RSA, ECC, and PQC accelerators from the FortiPQC product line. If your system already includes a hardware public-key engine but lacks hardened AES, HMAC, or PQC support, you can simply add FortifyIQ’s software libraries for symmetric encryption, integrity checks, or post-quantum algorithms. All components use a unified API, ensuring consistent integration across software and hardware.

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.

The Post Quantum Era

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.

Yes. Our high-assurance PQC libraries are OTA updatable, so devices can receive security updates as new threats arise, as well as newly standardized algorithms by NIST, hardened against side-channel and fault injection attacks.

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 RAM/ROM footprint to standard optimized unhardened implementations. 

Still Have Questions?

Ask us!

FortifyIQ AES Algorithm
AVA_VAN.5 Evaluation & Validation Summary
SGS Brightsight Common Criteria Laboratory
“Summary. The leakage analysis (Welch t-test) on over 30 million traces did not show statistically significant first- and second-order differences between trace sets with fixed and random inputs. The template-based DPA analysis, on the pseudo-random trace set for the profiling phase (15 million traces) and on a sub-set of 300k fix input traces for matching phase targeting the first-round S-box output, and template attack on ciphertext, did not indicate any potential information leakage.”
“The results for the soft IP presented in the report were obtained on the TOE which is the basic hardware implementation of the soft IP without additional levels of security (e.g. that are present in a secure silicon layout). Therefore the internal strength of the soft IP itself was evaluated. This indicates that the investigated features and parameters of the soft IP implementation should be robust against SCA and fault injection attacks in different implementations including ASIC. Nevertheless, according to the Common Criteria rules, the strength of the final composite product must be evaluated on its own”
Request Technical Details