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 (all levels) 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) and Common Criteria up to AVA_VAN.5, enabling compliance in regulated industries.
Comparison to Lightweight Cryptography:
Ascon
How do FortifyIQ’s protected software libraries compare to lightweight algorithms like Ascon or PRESENT?
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.
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, 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 the 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?
On average, our protected AES is about 10× slower than unprotected AES. However, performance remains practical for demanding applications:
- Up to 100 Mbps on a 1.2 GHz ARM processor
- Up to 900 Mbps on a 3.4 GHz laptop
This makes our solution viable even for high-performance use cases.
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 PKA (asymmetric crypto) library with AES or HMAC?
No. The PKA 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 PKA 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?
Regarding AES-256 and HMAC-SHA-512 (which are also inherently quantum-ready, thus recommended), RAM requirements start as low as X KB, depending on the configuration. The full library typically fits within XX KB RAM, making it deployable on constrained MCUs and embedded systems.
- AES with encryption only: 4 KB of RAM and 25 KB of ROM or flash memory.
- AES with encryption and decryption: X KB of RAM and 25 KB of ROM or flash memory.
- HMAC SHA2: 2 KB of RAM and 64 KB of ROM or flash memory.
- PKA (asymmetric ECC): X KB of RAM and X KB of ROM or flash memory.
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, 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 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.
For use cases targeting SESIP Level 4, our software includes:
- AES and HMAC implementations that pass TVLA testing with over 100,000 traces
- Public key and post-quantum cryptography libraries with algorithm-level protections
- Design documentation suitable for integration into evaluated platforms
SESIP Level 5 alignment may be achievable when the libraries are deployed within a system that provides formal verification of the full hardware-software stack.
Technical Integration
What processors are supported?
The libraries are processor-agnostic and run on any architecture with RAM, including, for example:
- ARM (Cortex-M/R/A)
- RISC-V (with or without crypto extensions)
- x86/x64 (with or without AES-NI)
They are optimized for smart cards, constrained MCUs, and general-purpose CPUs, using primarily lookup tables (LUTs) and minimal RAM, making them suitable for highly resource-limited platforms.
How does the FIA protection work in software?
Fault attacks like voltage glitches or clock manipulation are detected using algorithm-level redundancy. When a fault is detected, the operation halts securely — no external fault sensors are required.
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 PKA 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?
Yes. FortifyIQ’s hardened software cryptographic libraries can be used alongside your existing hardware crypto, whether standard or SCA/FIA-hardened. For example, if you already have a hardware public key accelerator (PKA) but lack hardened AES or HMAC, you can deploy FortifyIQ’s software libraries for symmetric crypto and integrity checks. All FortifyIQ libraries use a common abstraction layer, making integration seamless across software and hardware.
The Post
Quantum Era
Will your AES software's secure implementation still be secure with quantum computers?
AES-256 is secure with quantum computers. As is HMAC-512.
What do you propose as a replacement for the classical SW PKA in the PQC era?
PQC itself is the SW public key for the Quantum Era.
Do you have SW hybrid PKA 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 the PQC standards changed in the future? Would your secure SW PQC be updatable/upgradable?
Yes. This is an advantage of software over hardware. The changes can be met, and an OTA would be available to our customers.
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 PCS 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.