RECENT BLOG NEWS

wolfCrypt has been listed on the CMVP IUT List for FIPS 140-3! We are currently working with our testing lab to get validated as quickly as possible with the new FIPS standard from the NIST. wolfSSL is the first software library on the FIPS 140-3 IUT list for embedded development.

FIPS 140-3 involves a few significant changes, and wolfSSL is prepared to deliver the first and best implementation of FIPS 140-3.

FIPS 140-3 is the replacement for FIPS 140-2, so it is always a good idea to switch over to it as soon as possible. You will also want wolfSSL’s FIPS 140-3 Certificate for reasons including:

– Conditional Algorithm Self-Testing (CAST): Testing Streamlined – only test algorithms when they will be first used, or at will
– Addition of TLS v1.2 KDF (RFC7627) and v1.3 KDF (RFC8446)
– Addition of SSH KDF
– Addition of explicit testing of 3072-bit and 4096-bit RSA
– Addition of RSA-PSS
– Addition of HMAC with SHA-3
– Addition of AES-OFB mode
– Addition of external seeding source callback function for Hash_DRBG
– Removal of insecure algorithms: 3DES and MD5

For more information, please visit our FIPS page here.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Love it? Star wolfSSL on GitHub!

Last year was an excellent year for wolfSSL! We progressed on all of our critical performance vectors, including technical leadership, top notch support, sales growth and new design wins. The sheer volume of new code that we produced, in conjunction with our new products and design wins, is impressive to say the least. Additionally, we made the migration from a strictly on-prem based testing rig to a hybrid rig. Our new rig harnesses the power of cloud computing, and allows us to even further improve on our testing in order to bring you the best tested TLS. Thank you for reading, and please contact us if there is something that you would like on the wolfSSL roadmap for 2022!

wolfSSL Technical Progress

A total of 5 releases of the wolfSSL embedded TLS library were delivered in 2021, each with bug fixes, enhancements, and new feature additions. Highlights of these releases included:

1. New Hardware and OS Ports

• Linux Kernel Crypto API (KCAPI) – Allows for offloading of crypto operations to kernel hardware or software.  Support includes AES-CBC, AES-GCM, SHA-2, and HMAC. Also possible to use RSA, DH and ECC with custom kernel modules.
• Linux Kernel Module build option (–enable-linuxkm), which is also supported with FIPS modes of operation using FIPS compliant integrity checks and conditional algorithm self tests (CASTs). Compliance up to the latest FIPS 140-3.
• NXP i.MX CAAM – QNX 
• NXP SE050 
• IOT-Safe (SIM card PK)
• Cypress/Infineon PSoc6
• Renesas RA6M4, RX65N, RX72N, TSIP, SCE Protected Mode (see our new GitHub repository)
• Fusion RTOS
• Dolphin Emulator

2. New Software Ports!

1. Bind DNS 
2. Cjose 
3. HaProxy
4. Kerberos
5. Libest 
6. libmobiledevice
7. Net-SNMP 
8. NTP 
9. OpenVPN 
10. OpenLDAP 
11. OpenPegasus 
12. OpenResty 
13. PyOpenSSL 
14. Python 
15. Rsyslog 
16. sblim-sfcb 
17. Socat 
18. Tcpdump 
19. libSSH2 
20. Zephyr

3. Updates to Existing Ports

• STM32: Supported platforms now include G0 and U5
• Fixes for NXP mmCAU/LTC, Microchip ATECC608, Espressif ESP32, ST STM32 PKA AES-GCM, Renesas RA6M3
• Updated project ports:
  1. Stunnel 5.57 
  2. Qt 5.15
  3. Apache 2.4.51
  4. Socat 1.7.4.1
  5. lighttpd 1.4.51 
  6. OpenSSH 8.8

4. Operating System Updates

• WIN32 WinCE wolfCrypt port
• TI-RTOS port maintenance

5. Compiler and IDE Updates

• Android
• STM32
• GCC Makefile
• Espressif ESP-IDF
• INTIME
• QNX

6. Post Quantum Algorithm Support

1. Removed legacy QSH and NTRU support.
2. Added support for FALCON signature schemes in TLS 1.3 (Levels 1, 5)
3. Added support for KEMs in TLS 1.3 as groups and hybridized groups with NIST ECC Curves: 
   1. SABER (Levels 1, 3, 5)
   2. KYBER (Levels 1, 3, 5) and KYBER 90S  (Levels 1, 3, 5)
   3. NTRU HRSS (Level 3) and HPS  (Levels 1, 3, 5)
4. Full interoperability of algorithms we implemented against the OQS team’s OpenSSL fork. 
5. Integrations with Open Source projects allowing use of post-quantum algorithms with the following popular projects: 
   1. Apache
   2. Nginx
   3. Lighttpd
   4. cURL
   5. MariaDB
   6. Stunnel
6. Joint integration with the OQS team to patch Wireshark, making it aware of and display the new algorithms and their variants.

7. New Hardware Crypto Support

• IotSAFE support
• Renesas RA6M4 SCE Protected Mode support
• Renesas RX65N / RX72N TSIP 1.14 support

8. Improvements to Existing Hardware Crypto Support

• Fixed DCP port 
• Fixed Psoc6 SHA512 regressions
• Fixed broken ECC public key computation in PR in NXP LTC
• Fix for STM32 PKA ECC point mapping

9. New and Updated Algorithms

• New Post-Quantum Algorithm support, as mentioned above. 
• Added ECCSI and SAKKE for Identity-based Encryption.
• Added support for streaming AES-GCM.
• Added streaming API for Ed25519 and Ed448.
• Added ISO 18033 and SEC 1 implementations of ECIES.

10. Algorithm Performance Optimization

• Improved TFM and SP math implementation of addmod_ct and submod_ct for a 30% improvement in performance of ECC operations.

11. New and Updated Build Options

• S/MIME support (–enable-smime)
• –enable-wolfsentry and –with-wolfsentry=
• –enable-wolftpm
• –enable-caam
• –enable-kcapi
• –enable-eccsi
• –enable-sakke
• –enable-wolfclu
• –enable-curl
• –enable-reproducible-build
• –enable-aesgcm-stream
• –enable-ed25519-stream
• –enable-ed448-stream
• –enable-linuxkm-pie
• –enable-keying-material
• –enable-iotsafe
• –enable-iotsafe-hwrng
• –enable-sp=
  1. smallfast
  2. smallec1024
  3. smallp1024
  4. small1024
  5. ec1024
  6. p1024
  7. 1024
  8. asm
• –enable-context-extra-user-data
• –enable-aescbc-length-checks
• –enable-altcertchains
• –enable-sblim-sfcb
• –enable-crypttests-libs
• –enable-benchmark
• –enable-aligndata
• –enable-error-queue-per-thread
• –with-max-rsa-bits=
• –with-max-ecc-bits=
• –with-liboqs=
• –with-se050=
• –enable-bind
• –enable-libssh2
• –enable-net-snmp
• –enable-ntp
• –enable-openresty
• –enable-rsyslog
• –enable-smime
• –enable-tcpdump
• –enable-krb

12. TLS Additions and Updates

• Session Ticket (Added AES GCM support)
• TLS export/import
• Keying Material Exporters for TLS (RFC 5705)
• S/MIME (Secure/Multipurpose Internet Mail Extensions)
• Asynchronous TLS v1.3 TLSX ECC/DH keygen/agree
• TLS 1.3 Updates
  1. Better Interop
  2. Better Portability
  3. Better Testing
  4. More Cipher Suites
• Crypto Callbacks extended: Ed/X25519, SHA2-384/512, AES CCM, CMAC
• TLS v1.3 sniffer / DH Extra / Static Ephemeral
• LWIP Native Support (IP stack)
• DTLS
  1. Resend the previous DTLS handshake flight only on a network read timeout (WOLFSSL_DTLS_RESEND_ONLY_TIMEOUT)
  2. Change default DTLS future packet behavior. Messages from “too far into the future” are now accepted.

13. Single Precision Math Updates

• Significant SP math performance improvements
• Windows now has assembly code implementation for Intel x86 64-bit that increases performance by 5 to 10 times!
• C only implementation has had significant improvements that have major impacts on performance. 32-bit code most significantly 25% for 2048-bit operations and 50% and more for larger sizes.
• Improved performance of ARM Thumb code by 30-40%.
• On Aarch64, improved performance of P-384 operations by 65-100%.

14. FIPS 140-2 and 140-3 Validation News!

• FIPS 140-3 support merged, including Linux Kernel Module support
• 28 140-2 (Cert 3389) OE additions!

15. Testing

• More continuous integration testing added, including cppcheck static analysis
• Added support for Google Compute Engine to supplement testing slave farm in CI ecosystem, testing capabilities are now dynamically scalable based on test load and internal developer activity
• Expanded API testing coverage with OpenSSL compatibility layer additions

16. Examples

• New Post-Quantum cryptography example.
• New wolfSSL CAN Bus example.
• New RIOT-OS example using lwIP POSIX sockets.

17. Additional Product Enhancements

• Revamped Documentation
  • wolfCLU
  • wolfMQTT
  • wolfSentry
  • wolfSSL
  • wolfTPM

• wolfMQTT (4 releases)
  • SN feature enhancements
    1. Will Topic update and Will Message update
    2. Publish with QoS-1
    3. Receiving Disconnect Packet while going to sleep
    4. New callback for REGISTER topic ID from gateway when client subscribes to wildcard topics
    5. Handling PINGREQ message from the gateway to client
    6. New example added for QoS level -1 feature
  • HiveMQ Cloud compatibility with SNI feature
  • Huge improvements to multithread and non-blocking features
  • Examples
    1. TLS mutual auth in client examples
    2. Add ability to publish files from example client

• wolfSSH (3 releases)
  • Easier build with wolfSSL
  • Added remote port forwarding
  • Improved keep alive
  • Small stack option for embedded builds
  • SFTP Support for FATFS
  • Added support of 192 and 256 bit AES keys
  • Improved build options to leave out unwanted algorithms
  • Improved interoperability with other tools
    1. Dropbear
    2. Firezilla
    3. winSCP
  • Support for EWARM
  • MQX IDE build added

• wolfTPM (4 releases)
  • Added examples for symmetric key generation, NV, remote attestation, make credential, PCR read and GPIO.
  • Support for QNX
  • Example for QEMU with wolfTPM
  • Improved documentation

• wolfBoot (3 releases)
  • New architectures
    1. ARMv8-M
    2. PowerPC
    3. ARM Cortex-R
  • Measured boot
  • Support for Trustzone-M
  • New memory model
  • RSA4096 using SP
  • WOLFBOOT_SMALL_STACK
  • Delta updates
  • New HAL:
    1. STM32L4
    2. STM32L0x3
    3. STMU575xx
    4. NXP i.MX-RT1060
    5. NXP T2080
    6. TI TMS570LC435

• wolfSentry (3 releases, all preview/beta)
  • Dev phases 1, 2, 3, completed – static firewall, with action plugins, POC notifications via plugin, and configuration updates at any time.
  • Full configuration loaded from JSON, with streaming load and all-or-none semantics
  • Advanced lock facility complete, with ports for semaphore back ends under POSIX, MacOS-X, and FreeRTOS.  Implements shareable, promotable, timeout-capable, deadlock-safe locks.
  • POC integration with LWIP, under Linux and FreeRTOS, demonstrating filtering at the IP stack level, including filtering by MAC address, filtering of ICMP, and pre-accept filtering.
  • Port to STM32 (FreeRTOS+LWIP)
  • Turnkey integration with libwolfssl via the –enable-wolfsentry option, allowing post-accept filtering of incoming connections, and demonstrating pre-connect filtering of outbound connections, via integrations in the example client and server.

• wolfEngine (1 release)
  • wolfEngine made public on GitHub and first official release with version 0.9.0.
  • Allows users to achieve FIPS compliance with wolfCrypt FIPS + OpenSSL. Supports all algorithms in wolfSSL’s FIPS certificate (and others):
    1. SHA-1
    2. SHA2 (224, 256, 384, 512)
    3. SHA3 (224, 256, 384, 512)
    4. DES3-CBC
    5. AES w/ 128, 192, and 256 bit keys. ECB, CBC, CTR, GCM, and CCM modes.
    6. DRBG
    7. RSA
    8. DH
    9. ECC. ECDSA, ECDH, EC key generation. Curves P-192, P-224, P-256, P-384, P-521.
    10. HMAC
    11. CMAC
    12. HKDF
    13. PBKDF2
    14. TLS PRF
  • Support for OpenSSL 1.0.2 and 1.1.1.
  • Runs on macOS, Windows, Linux.
  • Integrates seamlessly with anything that uses OpenSSL, including:
    1. OpenSSH
    2. nginx
    3. stunnel
    4. OpenVPN
    5. curl
    6. libssh2
    7. libssh
    8. ntpd
    9. mongoDB
    10. Node.js
    11. radius
    12. radsec
    13. syslog-ng
    14. grpc
    15. dhcpd
    16. dhclient
  • See wolfProvider for OpenSSL 3.0.0 support.

• wolfProvider (code available on GitHub)
  • wolfProvider made public on GitHub.
  • Allows users of OpenSSL 3.0.0 to achieve FIPS 140-3 Compliance
  • Supports:
    1. AES-GCM/CCM/CTR/CBC/ECB
    2. MD5/SHA-1/SHA2/SHA3/SHAKE256
    3. DRBG
    4. RSA/RSA-PSS
    5. DH
    6. ECDH/ECDSA/EC KeyGen with P-192/P-224/P-256/P-384/P-521
    7. HMAC/CMAC/GMAC
    8. HKDF/PBKDF2/PKCS12 PBKDF2/TLS 1.3 KDF/TLS1 PRF
  • Runs on Linux

• wolfCLU (1 release)
  • Additional support added for multiple commands:
    1. ecparam
    2. pkey
    3. req
    4. crl
    5. pkcs12 (parsing)
    6. rsa
    7. rand
    8. s_client
    9. dgst
    10. verify
    11. rsa
    12. md5
  • Added in a logging layer and mapping of errors to stderr
  • Increased unit tests with ‘make check’ and include running tests as a pre-commit hook
  • Support for parsing and using basic config files when doing ‘req’ or ‘ca’ operations
  • Enhancements to existing commands:
    1. x509 , -noout and print out of specific parts of certificate
    2. x509 , -days for setting number of days valid
    3. x509 , -pubout to display the public key
    4. More descriptive version print out
    5. PEM output for RSA/ECC key generation
  • Initial integration of FIPS 140-3 use
  • Refactoring of directories and test certificate locations
  • Resolve warnings and issues from using -Wall and static analysis tools

• cURL (8 releases)
  • https://curl.se/changes.html 

• wolfSSL JNI/JSSE (2 releases)
  • wolfCrypt FIPS 140-3 and FIPS Ready compatibility
  • JSSE level memory leak fixes, along with earlier internal memory cleanup.
  • Addition of Socket method wrappers for use of wrapped inner Socket objects in WolfSSLSocket
  • Updated Android AOSP support
  • JSSE level fixes for SSLContext, SSLSocket
  • Fixes for static analysis warnings (Infer), exception cases, connection closures, and more.

• wolfCrypt JNI/JCE (1 release)
  • wolfCrypt FIPS 140-3 and FIPS Ready compatibility
  • Compatibility with wolfSSL “–enable-all” and additional build fixes

• wolfSSL Python
  • Added OpenSSL compatibility layer. 
  • Updated example certifications.

• wolfCrypt Python
  • Added signature generation and verification.
  • Now works with FIPS ready.
  • Support for ed448, PEM RSA keys, and more.

• wolfCrypt DO-178C
  • wolfCrypt 2
    • AES GCM
    • Environment:
      • Ultrazed-EG(on A53), little endian
      • GCC compiler that comes with Xilinx SDK 2017.4
      • Run Azure RTOS ThreadX SMP version 5.8 on the A53 cores
  • wolfCrypt 3
    • SHA-256
    • SHA-384
    • HMAC (SHA-256)
    • HMAC (SHA-384)
    • HASH-DRBG SHA-256
    • AES GCM
    • AES CMAC
    • ECC – P384 (sign/verify/shared secrets)
    • ECC key export
    • X509 cert verify
    • Environment:
      • NXP S32V234 (on A53)
      • Arm Developer Studio version 2019.0-1, with armclang
      • 1120 compiler version 6.12.1

wolfSSL Top 10 Blog Posts/Technical Announcements

1. wolfSSL Software Development Process
2. Riding the CAN bus 
3. wolfSSL Quality Assurance
4. wolfEngine and OpenSSL Provider Solution Now Public! 
5. wolfSSL Support for DO-178 DAL A
6. Sniffing traffic with TLS v1.3
7. First wolfCrypt DO-178 SOI Audits
8. wolfSSL NXP SE050 Support 
9. Integration of the Falcon Signature Scheme into wolfSSL
10. wolfCrypt FIPS 140-2 on ARM

2021 Webinars

The wolfSSL team hosted and/or participated in a total of 58 webinars this year. Check out our top 5 webinars of the year.

1. Everything you need to know about FIPS 140-3
2. wolfEngine : wolfCrypt as an Engine for OpenSSL
3. Secure Element or TPM : how to include hardware security in your project using wolfSSL and wolfBoot
4. Secure and Reliable Firmware Updates with wolfBoot
5. Beyond DO-178: Building Secure Solutions for Future Aviation Systems

We host at least one webinar per week, make sure you are checking out our blog page to find out about our webinars! Check out our youtube page for all of our previous webinars!

wolfSSL Organizational Growth

• wolfSSL added 9 new team members in 2021. Additions included salespeople, engineers, administrators, and interns.
• We expanded our customer base considerably, are now securing connections for over 2,000 products, have partner relationships with over 40 vendors, and are securing well over 2 Billion connections on any given day, worldwide.
• wolfSSL represents one of the largest teams focused on a single implementation of TLS/Crypto worldwide. If you know of anyone who fits the following description, please let us know.

wolfSSL Events and Tradeshows

The wolfSSL team participated in a total of 16 events in 2021! As part of these events we were in 11 cities, 5 US states, and 4 countries! We participated in a total of 6 virtual events and were fortunate to attend 10 in-person events. The events we participated this last year included:

1. Black Hat Asia
2. cURL Up
3. Mobile World Congress
4. Black Hat 2021
5. Sea Air Space
6. ICMC
7. SIdO Lyon
8. IoT Tech Expo North America
9. CyberSatGov
10. it-sa
11. Internet of Things World
12. Aerospace Tech Week (FACE)
13. NXP Connects (EMEA)
14. NXP Connects (AMEC)
15. TU Automotive Detroit (now Automotive Tech Week)
16. NXP Connects (APAC)

In summary, we had a great year! 2021 was successful on multiple fronts, and we look forward to serving our customers and community with ever more secure and functional software in 2022. 

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Here at wolfSSL, we have been supporting your FIPS needs for several years now with our FIPS Ready, certificate #2425 and certificate #3389 source bundles.  This support is going to continue with the soon to be granted FIPS 140-3 certificate. With the new certificate coming soon, we thought this might be a good time to do a bit of house cleaning.

As certificate #2425 has been added to the NIST sunset list as of June 2021, we will be removing the FIPS v1 feature from wolfSSL.

Customers who still need this feature are encouraged to move to the upcoming FIPS 140-3 certificate if timelines permit.  However, if customers need a solution in the near term, they can move to certificate #3389 which sunsets in 2024.  

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Here at wolfSSL, we strive to support our customers’ needs for customization and finding the right trade-offs. The following table is a list of the top 10 things you can do with wolfSSL’s configuration flags.

Note that some of these flags can be combined while others are mutually exclusive. Please feel free to experiment with different combinations.

Want more? You can see a full list of our configuration flags by downloading our latest release and executing the following command:  ./configure –help

Still hungry? You can get detailed documentation about our configuration flags from “Chapter 2: Building wolfSSL” in the wolfSSL  Manual which can be found here: https://www.wolfssl.com/documentation/wolfSSL-Manual.pdf.  Need some expert advice? 

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

We now support wolfCrypt as a PKCS11 provider for applications to consume. The new wolfPKCS11 library adds a PKCS11 layer on top of the wolfCrypt API’s to enable customers who wish to standardize on an API interface or may already have developed code against PKCS #11.

PKCS #11 is an OASIS standard for “Cryptographic Token Interface Base Specification” (A.K.A Cryptoki). It defines an API interface for communicating with Hardware Security Modules (HSM) to provide cryptography support such as RSA and ECC. It allows enumeration of devices and features using a shared or static library.

A good introduction to PKCS #11 can be found here: 

http://wiki.ncryptoki.com/introduction-to-pkcs-11-specifications.ashx

The source code is in a new GitHub repository here:

https://github.com/wolfSSL/wolfPKCS11

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfCLU (wolfSSL command line utility) has seen many feature additions! One of the features added was support for the command ‘ca’. This command now can handle basic conf. files for use with signing certificates. It is useful in projects to make a quick certificate with a given CA while avoiding having to write the code and create an application. This feature was one of many that has recently been added. Check out the repository here for the current bleeding edge of wolfCLU (https://github.com/wolfSSL/wolfclu).

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

A new version of wolfBoot (1.10) has been recently released and can be downloaded from our website, or cloned from our github repository. A full list of features can be found in our Changelog.

As we recently announced, we have ported wolfBoot to run as an EFI application to verify the subsequent stages in the boot chain of a x86_64 PC. We have improved the configuration for some of the supported platforms and targets. Finally, because of improved support for delta updates and one new signature verification algorithm (Ed448), this new version adds even more unique characteristics that you won’t find in any other existing secure boot solutions.

Here is a summary of our users’ favorite unique features, now fully supported in wolfBoot 1.10:

Secure, compact, fast, FIPS-compliant cryptographic library

wolfBoot’s main task is to ensure that only a trusted firmware image can run on the target device, as indicated by RFC9019. It uses signature verification on the  firmware image every time the device starts or when a firmware update is received, OTA or through any custom transport.

wolfBoot relies on wolfCrypt cryptographic engine to support the widest range of options for signature verification algorithms, including: ECC-256, RSA up to 4096 bit, Ed25519 and Ed448. 

Thanks to a wide choice of hardware security modules and crypto co-processors supported by wolfCrypt; wolfBoot can offload all cryptographic operations to dedicated hardware components when available, cutting down boot time and run-time resources.

Simplicity and portability

wolfBoot does not depend on any specific libraries, except for wolfCrypt. It does not rely on any operating system environment, driver, platform or toolchains.

wolfBoot can secure the boot process of any standalone applications as well as complex operating systems, from small class-I microcontrollers up to Rich Execution Environments, on a wide range of microcontrollers and processors architectures (ARM, x86, PowerPc, RISC-V, and more). It can manage the initialization of Trusted execution environments (TEE) (e.g. TrustZone-M in ARM Cortex-M33).

The build-time configuration is concentrated in a single configuration file, and a command-line wizard is made available to ensure a quick and painless integration.

The key command line tools, ‘sign’ and ‘keygen’ (for Windows, Linux, MacOS), distributed along with wolfBoot, follow the development of all the features supported by the bootloader to the latest version. They are easy to use, widely documented, and simple to  integrate with any deploy mechanism and back-end update services.

Roll-back: the bootloader “rescue” mode

wolfBoot stores a copy of the old firmware that gets replaced during the update. Mistakes can happen when building or transmitting a firmware update; even if the firmware is trusted and authenticated through wolfBoot it might still introduce bugs and issues in the field that may prevent the device from being reachable again. For this reason, wolfBoot implements a mechanism that requires the firmware to confirm that the system is working as expected after the update. In absence of this confirmation, at the next reboot wolfBoot considers the update as failed, and restores the original image from the backup taken during the update.

Use any external storage, with confidentiality

Some microcontrollers may not have enough flash space to accommodate two versions of the firmware in the internal FLASH. The only requirement on these system is normally that only the current executing firmware image should be stored in FLASH, where it can be eXecuted in Place (XiP). Most systems don’t support XiP on external storage supports, but that space can still be allocated to store updates and host the swap space required by wolfBoot to perform the update.

Thanks to a transparent, generic external flash interface, wolfBoot can use any external non-volatile memory support to host update and swap partitions, maximizing the space available in the internal FLASH for the running software.

Neighbor systems can host a virtual partition for the wolfBoot target, using any communication bus to implement remote, emulated memory access.

Encryption and decryption is done at runtime by wolfBoot when accessing these external storage devices for writing and reading, respectively. This mechanism prevents wiretapping or intercepting the firmware images when they are transferred on the BUS (SPI, CAN, Uart,…) that connects to the storage device.

Examples distributed with wolfBoot showcase this feature, with common SPI FLASH targets, and emulated remote storage, on a neighbor system via UART.

Self-update: can a secure bootloader update itself?

wolfBoot offers the possibility to authenticate and install a newer version of itself. A special update package can be created with the key tools, containing an update for the bootloader itself. wolfBoot will parse, authenticate and install the update by temporarily executing a copy of itself in RAM.

Incremental updates: faster OTA transfers with “delta updates”

wolfBoot supports incremental updates, based on a specific older version. Thesign tool can create a small “patch” that only contains the binary difference between the version currently running on target and the update package, a ‘delta update’ package. This package is processed by wolfBoot to reconstruct a complete image of the resulting update. The authenticity of the update is verified twice: first when the package is received before applying the patch, and then after the patch is applied, every time the new firmware is staged for boot.

What feature would you like to see in the next release of wolfBoot? Contact us at facts@wolfssl.com with any comments or questions!
Check out our GitHub page for the full documentation, and to stay up to date with our latest developments. And while you are there, consider giving the wolfBoot project a star!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Join us for a comprehensive presentation on how to leverage wolfSSL for all of your automotive security needs. Out expert engineers will go through a variety of different use cases, stories, and examples, each with specific engineering details. Bring your questions for the Q&A session to follow!

Watch the webinar here: Looking Under the Hood – Everything you need to know about automotive security that you’re too afraid to ask: wolfSSL Automotive Stories and Examples!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

At wolfSSL, we have been developing a TPM stack with customers for many years called wolfTPM, a portable, open-source TPM stack with backward API compatibility, designed for embedded use. It is highly portable, and has native support for Linux and Windows. RTOS and bare metal environments can take advantage of a single IO callback for SPI hardware interface, no external dependencies, and compact code size with low resource usage.

wolfTPM offers API wrappers to help with complex TPM operations like attestation and examples to help with complex cryptographic processes like the generation of Certificate Signing Request (CSR) using a TPM.

Due to wolfTPM’s portability, it is generally very easy to compile on new platforms.

Here are a few reasons to use wolfTPM over other secure elements:

1) It is based on a widely accepted standard TCG TPM 2.0.

2) There are many chip vendors options and they are pin compatible.

3) Support for RSA. All TPM’s support at least RSA 2048 (the STSAFE and ATECC do not).

4) More NV storage

5) Measured Boot (PCR’s)

6) Advanced Policy management

7) Seal/unseal data based on private key or PCR state.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Love it? Star wolfSSL on GitHub.

There has been a little turmoil between the CAVP and the FIPS community regarding the TLS KDF. The CAVP deprecated testing of the kdf-component-tls-1.0 at the beginning of the year. The community wasn’t ready and it was temporarily un-deprecated. wolfSSL and our wolfCrypt cryptography library are ready for the transition to the RFC7627 TLS KDF.

The kdf-component-tls-1.0 KDF is the standard TLSv1.2 KDF described in RFC5246. The preferred algorithm is the KDF described in RFC7627, also know as Extended Master Secret. This uses the TLSv1.2 KDF and replaces the client and master random values with hashes of the handshake messages up to the key exchange. This cryptographically ties the TLS master secret to the handshake. wolfSSL has enabled Extended Master Secret as a default since 2016.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.