FortifyIQ Software Cryptography FAQ FAQ
Security
Foundations
How does SCA protection work in software?
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.
Is it possible to implement AES and HMAC in software and expect it to be protected from physical attacks?
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).
How effective is the protection against side-channel and fault injection attacks?
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.
How effective is the protection against caching attacks?
All known cache attack techniques are rendered ineffective by our implementations. This includes both time-based and power-based variants.
Is it possible to secure a chip that has no protected cryptography in hardware?
Yes. Our libraries are designed to bypass unprotected hardware crypto and add hardened protection via software, even on deployed devices.
Can these libraries replace unprotected AES in hardware on already manufactured chips?
Absolutely. Our software can serve as a drop-in secure replacement, making it possible to retrofit protection where hardware can’t be changed.
What level of security certification is achievable with these libraries?
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
How does FortifyIQ protect against fault injection (FI) attacks?
At the algorithmic and implementation levels, we harden cryptographic operations so that injected faults (such as changing gate states) do not reveal secrets.
What is the difference between FI prevention and FI detection?
- 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.
Can all fault injections be detected?
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
How do FortifyIQ’s protected software libraries compare to lightweight algorithms like Ascon or PRESENT?
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.
What does FortifyIQ offer in protected software libraries compared to lightweight algorithms like Ascon or PRESENT?
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.
Why choose AES over Ascon or PRESENT if they are designed for lightweight use cases?
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.
Can FortifyIQ libraries be tuned to be as small as Ascon or PRESENT for constrained MCUs?
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.
If I already use Ascon or PRESENT in my product, how hard is it to switch to FortifyIQ’s AES?
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.
Are Ascon and PRESENT free in both hardware and software?
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
What’s the performance impact compared to unprotected AES in software?
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.
Does using secure software ECC (or other asymmetric crypto) significantly slow down my device?
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.
Can I use just the AES or HMAC library without the others?
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.
Do I need to use the ECC/RSA (asymmetric crypto) library with AES or HMAC?
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.
Can we license this for legacy devices already in production?
Yes. Our licensing model is designed to support post-production and fielded devices, making it ideal for long product lifecycles.
When should I use FortifyIQ’s hardware IP vs. software cryptographic libraries?
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.
Can I switch between FortifyIQ's software and hardware cryptography without changing my code?
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:
- You are starting with a software prototype and plan to migrate to hardware in a later silicon revision.
- 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.
What are the memory/RAM requirements?
- AES with encryption only: 4 KB of RAM.
- AES with encryption and decryption: ~16 KB of RAM.
- HMAC SHA2: 2 KB of RAM
What’s the energy overhead for protection?
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.
Can these libraries be delivered via OTA update?
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
What certifications do these libraries support?
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.
Has the protection been validated?
Yes. The libraries have been tested against side-channel attacks using TVLA evaluations to meet the demands of high-assurance standards, exceeding 100K traces with no leakage detected. FIA protection is achieved via fault detection and shutdown mechanisms without the need for hardware sensors.
Do FortifyIQ’s software cryptographic libraries support SESIP Level 3 or higher?
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.
Technical Integration
What processors are supported?
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.
Can I combine FortifyIQ’s software and hardware cryptography solutions?
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.
Can I combine FortifyIQ’s software crypto with the hardware IP I already have?
Have your secure crypto libraries already been deployed in the field? If so, do you have any indication to share about their security efficiency?
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
Will your AES software's secure implementation still be secure with quantum computers?
Yes, both AES-256 and HMAC-512 are inherently secure with quantum computers.
What do you propose as a replacement for the classical SW ECC/RSA in the PQC era?
PQC itself is the SW public key for the Quantum Era.
Do you have SW hybrid ECC/RSA solutions for the transition period to PQC?
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.
What if new attacks on PQC emerge in the future? Will your software remain secure?
Yes. Our high-assurance PQC libraries are OTA updatable, so devices can receive security updates as new threats arise.
Is your software implementation of PQC security-certifiable? If so, to which level?
Our PQC meets the highest cryptographic security standards. It is algorithmically protected from side-channel and fault injection attacks, similarly to our other products.
Do you have data about the performance penalty of SW PQC vs your HW PQC IPs?
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.
Do you have a comparison of the performance of your protected PQC libraries vs unprotected implementations?
Our high-assurance PQC libraries deliver comparable performance and ROM footprint to standard (naive) implementations, while requiring less data RAM.
