RECENT BLOG NEWS
wolfSSL expands capabilities with ISO 26262 documentation for ASIL compliance
If you’re developing safety-critical automotive systems, chances are you’ve encountered the stringent requirements of ISO 26262, the standard governing functional safety for road vehicles. Achieving Automotive Safety Integrity Level (ASIL) compliance can be a daunting process, but wolfSSL has taken a significant step to support developers: the library now includes ISO 26262 documentation to aid in certification.
This development marks a major milestone for teams integrating wolfSSL to build secure and safe automotive systems. Here’s why.
What is ISO 26262 and ASIL?
ISO 26262 defines a structured approach for ensuring safety in automotive systems, from design to decommissioning. It includes ASIL levels (A-D) to assess risk, with ASIL D representing the highest safety requirements.
For cryptographic libraries like wolfSSL, demonstrating compliance requires detailed documentation, including failure mode analysis, software development lifecycle processes, and verification evidence.
How Does wolfSSL’s ISO 26262 Documentation Help?
With the provided ISO 26262 documentation, wolfSSL assists customers during the compliance process for automotive developers by offering:
- Pre-validated Artifacts: Access to the documentation allows developers to directly reference wolfSSL’s safety processes and testing in their safety case.
- Reduced Certification Time: By leveraging wolfSSL’s compliance resources, developers can focus on their application logic without reinventing the wheel for cryptographic layers.
- Confidence in Security and Safety: The inclusion of ISO 26262 ensures that wolfSSL adheres to rigorous safety and quality standards, providing a secure foundation for automotive systems.
Use Cases for WolfSSL in Automotive
WolfSSL’s compact size and high performance make it an excellent fit for embedded systems like:
- Secure Vehicle-to-Everything (V2X) communication
- In-car infotainment systems
- Advanced driver-assistance systems (ADAS)
- Electric vehicle (EV) battery management systems
Taking the Next Step
Whether you’re retrofitting cryptography into an existing system or building a new solution from the ground up, wolfSSL’s new ISO 26262 documentation reduces the friction for compliance while delivering the performance and security you trust.
Whether you’re integrating cryptography into an existing system or developing a new solution, wolfSSL’s ISO 26262 documentation simplifies the path to compliance, ensuring that your project can meet functional safety standards while maintaining robust performance and security.
Get in touch with the team
Contact us at facts@wolfSSL.com or +1 425 245 8247 to learn more about ISO26262 compliance, or if you are interested to hear more about our support for safety certifications.
Download wolfSSL Now
Deprecation Notice: liboqs Integration
Soon wolfSSL will no longer utilize the liboqs library. This change is intended to simplify the maintenance of the wolfSSL codebase by reducing the line count.
The wolfSSL library already provides its own implementations of post-quantum algorithms, including Kyber and Dilithium. To enable these algorithms, users can simply configure wolfSSL with the following options:
--enable-kyber --enable-dilithium
Note that the --with-liboqs
configure option will no longer be present.
The wolfSSL team would like to extend our gratitude to the Open Quantum Safe (OQS) team for their hard work and dedication to promoting quantum-safe cryptography. Their efforts have been invaluable to the community.
If you have any questions or concerns about this deprecation, please don’t hesitate to reach out to facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Why Transition to DTLS 1.3 is Crucial for CNSA 2.0 Compliance and Cybersecurity
As we advance towards stronger cybersecurity measures, adhering to the latest security standards is crucial. Transitioning to DTLS 1.3 is becoming a necessity for anyone still using DTLS 1.2. Here are four compelling reasons why now is the perfect time to make the switch:
- Full Control over the Migration Process
Typically, you control both the server and client, giving you complete control over the DTLS 1.3 migration. This flexibility allows for a smoother transition without disruption to your existing systems. - Support for Post-Quantum Cryptography
The upcoming enhancements to TLS and DTLS include support for ML-DSA (post-quantum authentication) and ML-KEM (key exchange algorithms), but these cryptographic advancements will only be available in TLS 1.3 and DTLS 1.3. Migrating now future-proofs your system against quantum threats. - NSA’s CNSA 2.0 Guidance
According to the NSA’s CNSA 2.0, these post-quantum algorithms should have already been implemented by 2024 in cloud services, with a mandate for their use by 2025. DTLS 1.3 is the only version that supports these algorithms, migrate now to ensure compliance with CNSA 2.0 standards. - Competitive Advantage for Vendors
If your software still uses DTLS 1.2 and is sold to government agencies in the U.S., transitioning to DTLS 1.3 is becoming urgent. This ensures your products meet the necessary security standards and helps you maintain a competitive edge in the market.
Plan your migration to DTLS 1.3 today. The migration to DTLS 1.3 isn’t just a technical upgrade. It is a strategic move to ensure CNSA 2.0 compliance and enhance your system’s security. Start planning your migration strategy today to stay ahead of future cryptographic challenges.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: Post Quantum Cryptography Update
Secure Your Future: NIST PQC Standards and CNSA 2.0
Quantum computing is on the horizon, bringing new challenges to traditional cryptographic methods. To address these, NIST’s Post-Quantum Cryptography (PQC) standards and CNSA 2.0 guidelines provide essential tools for ensuring data protection in the quantum era.
Join wolfSSL Senior Software Developer Anthony Hu in this exclusive webinar to explore quantum-resistant solutions and practical strategies for preparing your systems.
What you’ll learn:
- NIST PQC Standards and CNSA 2.0 Updates: Understand their importance for securing critical systems.
- Key Exchange Mechanisms: Compare NIKE and KEM in the context of quantum resistance.
- Performance Insights: Benchmark ECC against ML-DSA and ML-KEM.
- wolfSSL’s PQC Readiness: Discover migration strategies and collaborative efforts to adopt quantum-resistant solutions.
And more..
Register Now: Post Quantum Cryptography Update
Date: February 5th | 10 AM PT
Secure your spot today to gain actionable insights and stay ahead of quantum threats.
Register here
As always, our webinar will include Q&A throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
wolfTPM Release v3.8.0
We are pleased to announce the release of wolfTPM 3.8.0, our latest version with several important enhancements.
What’s New
This release includes a range of fixes and improvements that enhance the overall quality and reliability of wolfTPM. These changes are designed to support the delivery of high-quality production-grade products that meet the needs of our customers.
Key Changes
- Session Auth Improvements: We’ve fixed an issue with bound session authentication, ensuring that TPM 2.0 authenticated sessions with binding work correctly. Additionally, we’ve added comprehensive test cases to verify the functionality.
- Bus Protection: Our implementation of the TCG “bus protection guidance” now includes a comprehensive example, making it easier for developers to ensure their applications meet these critical security standards. For more information on our bus protection guidance, please refer to the TCG’s bus protection guidance document.
- Build Support: We’ve improved support for building wolfTPM against older wolfCrypt versions, including updated CI tests.
- HAL IO Improvements: We’ve added HAL IO support for Microchip I2C bit-bang driver
TPM 2.0 Use Cases
wolfTPM is designed to provide a robust and secure foundation for a wide range of applications, from IoT devices to high-end servers. Here are some examples of how wolfTPM 3.8.0 can help:
- Secure Boot: wolfTPM provides a robust secure boot mechanism, ensuring that only authorized firmware can be loaded on the platform.
- Platform Firmware Updates: Our implementation of bus protection guidance includes support for secure firmware updates, making it easier to keep platforms up-to-date and secure.
- Key Management: wolfTPM can be used to manage cryptographic keys securely, providing a reliable and efficient way to handle sensitive data.
- Hardware-Level Isolation: wolfTPM’s hardware-level isolation features provide a robust security foundation for applications that require high levels of isolation.
- Trusted Execution Environments (TEEs): wolfTPM is designed to work seamlessly with TEEs, providing a secure environment for executing critical functions.
Getting Started
Download the latest version of wolfTPM 3.8.0 today! Check out the complete ChangeLog for full details.
As always, we appreciate your contributions and feedback. If you have any questions or suggestions, please email facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfBoot release: v.2.4.0
We are excited to announce the release of wolfBoot 2.4.0, the latest version of our universal secure bootloader. This update brings enhanced platform support, new features, and performance improvements to keep offering the best secure boot solution for all embedded systems.
Integration with wolfHSM and Improved delta updates
A major highlight of this release is the integration with wolfHSM, enabling secure key management through an externally-managed HSM. This integration allows for the transparent management and revocation of the stored public key, as well as support for post-quantum algorithms (ML-DSA).
Delta update detection mechanism has been improved and is now more reliable, with the addition of extra procedures for identifying base image versions.
New hardware targets and platform enhancements
wolfBoot 2.4.0 adds support for the NXP Layerscape LS1028A platform, extending compatibility with high-performance devices.
Support for existing platforms, including ARMv7-M/ARMv8-M, x86-FSP and Xilinx UltraScale+, has been updated with enhanced ARMASM integration, and improved QSPI DMA for efficient memory interaction. Support for Intel TigerLake has improved, with the addition of GDT table support.
New assembly optimizations introduced in latest wolfCrypt have introduced a significant improvement in boot time performance across all ARM family, from Cortex-M devices such as STM32 microcontroller up to the most powerful microprocessors supported.
Bug fixes and updated modules
Key fixes address potential issues in flash write-once mode. Moreover, the core modules have been updated to the latest versions, including wolfSSL 5.7.6 and wolfTPM 3.8.0.
wolfBoot security is powered by wolfCrypt. This means that the secure boot process can be certified to meet FIPS 140-3 requirements and DO-178C safety regulations.
Looking Ahead: Exciting Roadmap for 2025
This year, we’re setting our sights on expanding wolfBoot’s capabilities even further. Planned features include support for running wolfBoot as a supervisor in TrustZone-A, platform support for i.MX-8, and integration with the STM32 MP1 series. Stay tuned for these and more as we continue to innovate and enhance secure boot for all embedded systems.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL JNI/JSSE 1.15.0 Now Available
wolfSSL JNI/JSSE 1.15.0 is now available for download! This release contains a number of bug fixes and changes to the JNI and JSSE layers.
wolfSSL JNI/JSSE allows for easy use of the native wolfSSL SSL/TLS library from Java. The thin JNI wrapper can be used for direct JNI calls into native wolfSSL, or the JSSE provider (wolfJSSE) can be registered as a Java Security provider for seamless integration underneath the Java Security API. wolfSSL JNI/JSSE provides TLS 1.3 support and can also support running on top of the wolfCrypt FIPS 140-3 validated cryptography module.
Changes in this release are summarized below, but please see ChangeLog.md for a full list.
JSSE System/Security Property Support:
- wolfssljni.debug – a new System property that enables JNI-level debug logging. This will add debug logs for the lower-level “com.wolfssl.*” classes that are part of the thin wolfSSL JNI wrapper. This is helpful for those users who are using the thin wolfSS JNI wrapper, or for JSSE-level users who need additional low-level debug logging support.
JSSE Changes:
- Close the underlying Socket when SSLSocket startHandshake() fails before an exception is thrown and returned to the caller.
- Fix a potential NullPointerException in SSLSocket Input/OutputStream that could happen in a threaded environment with some threads blocked in select()/poll().
- Add support for SSLSession.getRequestedServerNames() to return the client’s SNI (Server Name Indication) request on the server side.
- Add checks for legacy DHE keys for cipher suites using keys less than 1024 bits.
- Optimize Java byte array creation in SSLEngine objects when receiving app data. This has a positive impact on performance by reducing garbage collector pressure.
- Add the ability for SSLSocket.close() to interrupt read()/write() operations waiting in select()/poll(). This can speed up the return of threads blocked in read or write operations when the socket is closed, instead of waiting for the socket timeout to occur.
JNI Changes:
- Always call wolfSSL_get1_session() inside WolfSSLSession.getSession() for more consistent native memory handling and cleanup.
- Call wc_RunAllCast_fips() with wolfCrypt FIPS builds if available. This will run all FIPS Conditional Algorithm Self Tests (CAST) up front when the wolfJSSE provider is registered.
- Add the ability to pass CFLAGS to java.sh (ie: CFLAGS=”-DTEST_DEFINE” ./java.sh)
- Remove incorrect ATOMIC_USER preprocessor gate around native wolfSSL_GetSide() inside JNI glue code.
Example Changes:
- Updates the example Android Studio project, defining WOLFSSL_CERT_REQ and WOLFSSL_CUSTOM_CONFIG. These defines are either not needed, or automatically set when building native wolfSSL on a Linux/Unix platform with “./configure –enable-jni”.
Testing Changes:
- Add GitHub Actions PRB test for Maven (Linux, macOS) builds
- Add JUnit tests for SSLSession state at various points throughout the handshake
- Add GitHub Actions PRB test for native wolfSSL with NO_SESSION_CACHE_REF defined
- Add GitHub Actions PRB test for WOLFJNI_USE_IO_SELECT
wolfSSL JNI/JSSE 1.15.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. For any questions, or to get help using wolfSSL products in your projects, contact us at support@wolfSSL.com.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfCrypt JNI/JCE 1.8.0 Now Available
wolfCrypt JNI/JCE 1.8.0 is now available for download! This release contains a number of bug fixes, changes and new features to help better support usage from applications and 3rd party frameworks that consume wolfJCE internally.
wolfCrypt JNI/JCE allows for easy use of the native wolfCrypt cryptography library from Java. The thin JNI wrapper can be used for direct JNI calls into native wolfCrypt, or the JCE provider (wolfJCE) can be registered as a Java Security provider for seamless integration underneath the Java Cryptography API. wolfCrypt JNI/JCE can also support running on top of the wolfCrypt FIPS 140-3 validated cryptography module.
Changes in this release are summarized below, but please see ChangeLog.md for a full list.
New JCE Functionality:
- Support for two new Java Security properties designed for use in edge cases where wolfJCE is being used with wolfCrypt FIPS 140-2/3 and the wolfJCE WKS KeyStore is replacing JKS and/or PKCS12 type KeyStore usage from applications for more complete FIPS compliance. Setting these properties to “true” will result in wolfJCE fake registering support for JKS and/or PKCS12 KeyStore support, but will automatically map it down to WKS KeyStore support internally. This can be helpful if using wolfJCE underneath Java code that hard-codes JKS/PKCS12 KeyStore types which cannot be changed, but the actual KeyStore files on disk can be updated to WKS type.
- wolfjce.mapJKStoWKS
- wolfjce.mapPKCS12toWKS
JNI and JCE Changes:
- FIPS Conditional Algorithm Self Tests (CASTs) are now run once up front if wolfJCE is used with wolfCrypt FIPS 140-3, to prevent threaded app errors.
Example Changes:
- Updated Android Studio example project CMakeLists.txt, defining WOLFSSL_CUSTOM_CONFIG
- Addition of a JCE cryptography benchmark app (examples/provider/CryptoBenchmark.java). Basic AES-CBC/GCM benchmarks are in place now, but will be expanded to other algorithms in the near future.
Testing Changes:
- Addition of GitHub Action testing for Maven (pom.xml) builds on macOS and Linux
wolfCrypt JNI/JCE 1.8.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfCrypt JNI/JCE User Manual can be found here. For any questions, or to get help using wolfSSL products in your projects, contact us at support@wolfssl.com.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
TLS vs. SSH: When To Use Which
TLS and SSH are both widely used protocols used for creating secure connections between two systems over a secure network. But, they are designed for different use cases, so today we are going to take a quick dive into when you should use which.
About TLS
TLS (Transport Layer Security) is what is most commonly used to secure connections to the web, it is the successor to SSL (Secure Sockets Layer) to which wolfSSL gets part of its name. Today, almost all websites use TLS and most web browsers expect a website to use TLS when connecting. It has other use cases, such as email and VNC.
In general, TLS is designed so that a client can authenticate that the intended web server is where the data transfer is happening, and encrypt the data in transit.
About SSH
SSH (Secure SHell) is likely well known if you have used a Linux or Unix-based system before. It is typically used to remotely log into a server and execute commands on that server, as well as transfer files. It is ideal for remote shell or desktop access to machines over an unsecured network.
In addition to our namesake product, wolfSSL, we have a product called wolfSSH, which can provide lightweight SSH client and server support for embedded platforms.
Key Differences
Authentication
SSH allows for many different authentication methods, from basic passwords to keys and certificates. TLS typically relies on a trusted CA (Certificate Authority) for the authentication. Both TLS and SSH support OCSP for certificate revocation status.
Feature Set
SSH not only handles the basic authentication and encryption, but provides the next layer of features, such as shell access, file transfer and port forwarding. TLS is typically a secure wrapper around regular plain protocols.
Another feature SSH provides is the concept of channels. This allows multiplexing of multiple services over one SHH connection. For example, a single connection can have a shell, file transfer and multiple ports forwarded simultaneously.
Performance
TLS, particularly version 1.3, has a very low number of round trips required to handshake between the client and server. Whereas the handshake for SSH is a lot more involved, this can make a new connection a lot more expensive on a high-latency network.
Once the connection is established, the performance of each should be relatively similar, depending on the encryption algorithms used.
Ease Of Use
TLS is designed to be relatively easy to use, in particular, there is a low barrier to entry for the client user. SSH can be more difficult to configure and typically has more steps for the end user due to the mutual authentication.
Summary
Both TLS and SSH are essential parts of securing traffic over untrusted networks. TLS is very useful to wrap existing protocols with a layer of security, whereas SSH is ideal for remote command access to a system and network tunnels.
If you wish to learn more or have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
wolfSSL on STM32 MPUs
STMicroelectronics recently released a new range of ARM based MPUs. These are industrial grade ARM microprocessors that provide excellent performance as well as many useful features. ST have released OpenSTLinux to run on these chips, but they have also made a version of their bare-metal HAL API which works with these chips.
The wolfSSL team has recently ported wolfSSL to bare metal for the STM32MP135F in this range. This chip has a single-core 1GHz ARM Cortex-A7 which has hardware crypto acceleration features. There have been multiple parts to this work, which I will walk through in this post.
HAL porting
The previous AES, HASH and PKA HAL acceleration for STM32 MCUs has been ported to work with the STM32MP13 HAL. Every hardware acceleration feature we have previously supported for STM32 MCUs works with this MPU.
During testing, we clocked the MPU at 650MHz, which is the default high clock speed for bare-metal. At this speed we can get 12MB/sec AES-CBC, 9MB/sec AES-GCM and 90MB/sec SHA256. This is with the core clocked at only 65% of its maximum speed.
Extra hash support
We didn’t just stop there: we also added HAL acceleration for additional SHA types. With this MPU, we can now accelerate SHA-384, SHA-512 and SHA3 types. All also achieving around 85-90MB/sec. This is a 10-30x improvement over what you would typically see when running software-based algorithms for these types on the same hardware.
All the work we did to add these hash types should be easily portable to ST MCUs that support those types in the HAL. You can email us at support@wolfSSL.com if you wish for us to assist you with this porting work.
wolfSSL Example
Setting up and running the MPU in bare-metal mode can be a little bit tricky, so on top of all of this, we created a documented example so that you can create an echo client. This example is designed to be used with the STM32MP135F-DK development board. It uses FreeRTOS and LwIP, so it can be extended to do other things.
The example is available on our wolfssl-examples-stm32 GitHub repository.
There is also a README available in the main wolfSSL source tree, which can guide you through using wolfCrypt with the STM32MP135F.
What about Linux?
For those who want to use OpenSTLinux, wolfSSL “just works”. Using ST’s cross-compile toolchain, you can compile wolfSSL just like you would for any other Linux installation. On Linux, this is the wolfCrypt benchmark results:
------------------------------------------------------------------------------ wolfSSL version 5.7.4 ------------------------------------------------------------------------------ Math: Multi-Precision: Wolf(SP) word-size=32 bits=4096 sp_int.c Single Precision: ecc 256 384 rsa/dh 2048 3072 4096 asm sp_cortexm.c wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) RNG 10 MiB took 1.049 seconds, 9.537 MiB/s AES-128-CBC-enc 20 MiB took 1.003 seconds, 19.931 MiB/s AES-128-CBC-dec 20 MiB took 1.075 seconds, 18.597 MiB/s AES-192-CBC-enc 20 MiB took 1.198 seconds, 16.697 MiB/s AES-192-CBC-dec 20 MiB took 1.254 seconds, 15.947 MiB/s AES-256-CBC-enc 15 MiB took 1.063 seconds, 14.105 MiB/s AES-256-CBC-dec 15 MiB took 1.076 seconds, 13.943 MiB/s AES-128-GCM-enc 10 MiB took 1.044 seconds, 9.577 MiB/s AES-128-GCM-dec 10 MiB took 1.018 seconds, 9.822 MiB/s AES-192-GCM-enc 10 MiB took 1.130 seconds, 8.846 MiB/s AES-192-GCM-dec 10 MiB took 1.128 seconds, 8.867 MiB/s AES-256-GCM-enc 10 MiB took 1.191 seconds, 8.393 MiB/s AES-256-GCM-dec 10 MiB took 1.204 seconds, 8.307 MiB/s GMAC Table 4-bit 20 MiB took 1.014 seconds, 19.716 MiB/s CHACHA 35 MiB took 1.102 seconds, 31.750 MiB/s CHA-POLY 30 MiB took 1.173 seconds, 25.586 MiB/s POLY1305 120 MiB took 1.027 seconds, 116.896 MiB/s SHA 45 MiB took 1.029 seconds, 43.727 MiB/s SHA-256 25 MiB took 1.042 seconds, 23.988 MiB/s HMAC-SHA 45 MiB took 1.075 seconds, 41.845 MiB/s HMAC-SHA256 25 MiB took 1.029 seconds, 24.291 MiB/s RSA 2048 public 1400 ops took 1.043 sec, avg 0.745 ms, 1342.619 ops/sec RSA 2048 private 100 ops took 2.532 sec, avg 25.324 ms, 39.488 ops/sec DH 2048 key gen 86 ops took 1.007 sec, avg 11.707 ms, 85.419 ops/sec DH 2048 agree 100 ops took 1.194 sec, avg 11.939 ms, 83.763 ops/sec ECC [ SECP256R1] 256 key gen 1500 ops took 1.023 sec, avg 0.682 ms, 1466.898 ops/sec ECDHE [ SECP256R1] 256 agree 700 ops took 1.037 sec, avg 1.482 ms, 674.714 ops/sec ECDSA [ SECP256R1] 256 sign 1200 ops took 1.109 sec, avg 0.924 ms, 1081.961 ops/sec ECDSA [ SECP256R1] 256 verify 700 ops took 1.146 sec, avg 1.638 ms, 610.589 ops/sec
Details on this can also be found in the wolfSSL STM32MP13 README.
If you have questions about any of the above, please contact us at facts@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now
wolfBoot Support for NXP QorIQ Platforms
wolfBoot supports a wide range of NXP QorlQ platforms. In this post, we will highlight supported platforms, key features, and how wolfBoot ensures security and reliability for PowerPC-based embedded systems.
Why wolfBoot for NXP QorIQ?
wolfBoot is a highly suitable secure boot solution for modern embedded systems. wolfBoot is a U-Boot replacement to improve security. wolfBoot supports features like TPM, encrypted updates, external flash partitions, differential updates, and side channel hardening (armored mode). Production support, commercial grade product, safety critical certified DO178 and FIPS 140-3. Its lightweight design, independence from specific platforms, and ease of integration make it a one-stop solution for developers aiming to improve firmware security.
Key advantages:
- Efficient and Lightweight: Perfect for resource-constrained environments.
- Broad Compatibility: Supports PowerPC and Arm-based platforms.
- Flexible Integration: Simplifies secure firmware updates and key management.
Supported NXP QorIQ PPC Platforms
LS1028A
- Overview: ARMv8-A architecture with dual Cortex-A72 cores for industrial and networking applications.
- Features: Integrated TSN (Time-Sensitive Networking), high-speed I/O, and robust peripheral support.
- Tested Environment: LS1028ARDB Reference Board.
T1024
- Overview: Dual-core 64-bit PowerPC processor based on the e5500 core, designed for embedded control and communication.
- Features: Virtualization, encryption acceleration, and advanced networking capabilities.
- Applications: Secure gateways, industrial automation, and telecom systems.
- Tested Environment: T1024RDB with NOR flash using IFC.
T2080
- Overview: High-performance quad-core 64-bit processor using the e6500 core with AltiVec technology for vector processing.
- Features: Exceptional performance for data-intensive workloads and advanced signal processing.
- Tested Environment: NAII 68PPC2 hardware.
P1021
- Overview: A dual-core PPC e500v2 processor.
- Features: Optimized for secure boot from NAND flash via eLBC (Enhanced Local Bus Controller).
- Boot Details: Supports first-stage boot loader and execution of wolfBoot for secure firmware validation and application loading.
- Applications: Ideal for industrial controllers and embedded systems requiring high reliability.
- Tested Environment: P1021RDB with NAND boot source using eLBC
How wolfBoot Secures NXP QorIQ Systems
wolfBoot ensures safe and trusted execution of firmware with:
- Secure Boot: Prevents unauthorized firmware from running.
- Signed Updates: Employs ECC/RSA cryptography for firmware authenticity.
- Customizable Configurations: Provides example setups for easier implementation across platforms.
Conclusion
Whether you’re working on NXP QorIQ PowerPC platforms or other architectures, wolfBoot is designed to deliver the best security and support. Its compatibility with wide ranges of different processors makes it essential for secure embedded systems development.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
Weekly updates
Archives
- February 2025 (3)
- January 2025 (23)
- December 2024 (22)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)