RECENT BLOG NEWS

Are you interested in incorporating the best tested cryptography with FIPS certification into your C# project? wolfSSL has a C# wrapper that makes it easy to get started with TLS connections in C# projects. We are constantly working on, and expanding the C# wrapper and have recently added wrappers for inspecting X509 certificates. Now users can view peer certificates with verification callback functions.

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 not only remained far ahead of our competitors in 2019, but we also proceeded to extend our lead with massive success and growth. We grew our business dramatically, primarily based on our technological superiority and ongoing investments in testing and quality. We delivered TLS 1.3 ahead of the market, MISRA-C cryptography for the automotive market, FIPS for our government consumers and DO-178 for avionics. We also remain the best-tested product on the market, as witnessed by our additional fuzz testing resources from both internal and external sources. We have also been through a number of additional code audits from our large consumers. Finally, we engaged some of the best code auditors and testers in the world to review our code. Lots of testing and lots of eyeballs have come together to produce the best-tested TLS and cryptography code on the market today. Thank you for your interest in wolfSSL! We are off to a great start in 2020 and will strive to live up to your expectations again in the rest of 2020!

Reminder: If your TLS and cryptography provider does not do fuzz testing, you are exposed.

wolfSSL Technical Progress

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

1. New Hardware and OS Ports

• Renesas RX65N
• SiFive HiFive E31 RISC-V core family
• SiFive HiFive Unleashed board
• Telit IoT AppZone SDK
• Deos Safety Critical RTOS
• Zephyr Project
• Espressif ESP32-WROOM
• Espressif ESP-IDF
• Cypress WICED Studio
• ARM MDK CMSIS RTOS v2
• Sysgo PikeOS and ELinOS

2. New Software Ports!

• Apache web server (–enable-apache-httpd, WOLFSSL_APACHE_HTTPD)
• OpenVSwitch
• Google WebRTC
• Over 198 new OpenSSL compatibility API added
• Qt (–enable-qt, –enable-qt-test, WOLFSSL_QT)
• OpenVPN

3. Updates to Existing Ports

• Arduino (updated/refactored default settings, improved sketch examples)
• Xilinx (updates to Xilinx FreeRTOS build)
• Nginx (updated 1.15.0 patch, added 1.16.1 and 1.17.5 support)

4. Operating System Updates

• Micrium uC/OS-III (port update, adjustments for static and inline macros)
• Windows (fixes for custom ECC curves, directory functions)
• NetBSD (default build and mutex usage)
• SafeRTOS (fixes for build issues)
• VxWorks (port updates)
• Yocto Linux (ease of use improvements, updates, build instructions)

5. Compiler and IDE Updates

• IAR-EWARM (Cortex-M changes, compiler warning fixes)
• Renesas CS+ (improve user settings support, updated examples)
• XCode (Project file update, iPhone simulator on i386 build fixes)
• Visual Studio (fixes for build warnings, wrapper for snprintf)
• Cygwin (fixes for visibility tags)

6. TLS 1.3 Updates

• Better Interop
  • Interop fixes and better version negotiation
• Better Portability
  • Portability improvements (simplify time requirement, XTIME_MS)
• Better Testing
  • Additional fuzz testing!
  • Automated testing of select Embedded Targets
  • Better customer testing (known use-cases and configurations)
• More Cipher Suites
  • Addition of NULL cipher suites (TLS_SHA256_SHA256, TLS_SHA384_SHA384)

7. New Hardware Crypto Support

• ARM CryptoCell-310 on nRF52840
• Renesas TSIP on RX65N
• PKCS#11 support for HMAC, AES-CBC, and RNG
• Intel QuickAssist v1.7 driver support
• Intel QuickAssist RSA key generation and SHA-3 support
• STM32WB PKA ECC signature verification

8. Improvements to Existing Hardware Crypto Support

• STM32 (improved AES-GCM performance)
• STSAFE (wolfSSL crypto callback support, better error code handling)
• TI (updates to existing hardware crypto)
• NXP mmCAU performance improvements (35-78%!)
• Crypto callbacks (added 3DES support, improved features)
• Fixes to Microchip ATECC508/608A, AES-NI, AVX2, ARMv8, devcrypto/afalg, ST CubeMX

9. New and Updated Algorithms

• Addition of Ed25519ctx and Ed25519ph (sign/verify – RFC 8032)
• Addition of Blake2s (32-bit Blake2 support)
• CMS / PKCS#7 Improvements

10. Algorithm Performance Optimization

• ARM Architecture
  • ChaCha20 using SIMD NEON extension
  • Poly1305 using SIMD NEON extension
  • Curve25519/Ed25519
  • SHA-384/512 using SIMD NEON extension

11. New and Updated Build Options

• “–enable-ecccustcurves=all” – Enable all curve types
• “–enable-16bit” – Enable 16-bit compiler support
• “–enable-rsavfy” – RSA verify only build
• “–enable-rsapub” – RSA public only build
• “–enable-armasm” – Updated for ease of use with autotools
• “–enable-fallback-scsv” – Fallback SCSV, server-side
• “–enable-titancache” – New session cache size, can hold over 2 million sessions

12. TLS Extension Support Additions and Updates

• Added TLS Trusted CA extension
• Added Encrypt-then-MAC for TLS 1.2 and below
• Ability to disable Signature Algorithms extensions
• Parsing efficiency improvements to SNI extension
• Additional error checking when parsing ALPN

13. Single Precision Math Updates

• Cortex-M support
• Support for prime checking
• Specialized implementation of mod exp when base is 2
• Support for 4096-bit RSA and DH operations

14. FIPS 140-2 Validation News!

• Support for wolfCrypt FIPS v4.0.0 certificate #3389
• New “FIPS Ready” initiative
• Addition of wolfRand build option to configure.ac
• FIPS 140-2 OE additions
  • HP Imaging & Printing Linux 4.9 running on HP PN 3PZ95-60002 with ARM Cortex-A72 with and without PAA**
    • Includes ARMv8/NEON assembly optimizations w/PPA**
  • Linux 4.4 (Ubuntu 16.04 LTS) running on Intel Ultrabook 2 in 1 with an Intel® Core™ i5-5300U CPU @2.30GHz x 4 with and without PAA**
    • Includes Intel AESNI and RDSEED support w/ PAA**
  • OpenRTOS v10.1.1 running on STMicroelectronics STM32L4R9I-DISCO (Discovery Kit) with a STMicroelectronics STM32L4Rx (no PAA**)
  • Windows 10 Enterprise running on Radar FCL Package Utility with Intel® Core™ i7-7820 @2.9GHz x 4 with and without PAA**
    • Includes Intel AESNI and RDSEED support w/ PAA**
  • Windows 10 running on Intel Ultrabook 2 in 1 with an Intel® Core™ i5-5300U CPU @2.30GHz x 4 with and without PAA**
    • Includes Intel AESNI and RDSEED support w/ PAA**

** (Processor Algorithm Accelerator)

15. Testing

• Fixes for Coverity, scan-build, and cppcheck reports
• Enhancements to test cases for increased code coverage
• More Pull Request and Nightly tests
• ABI compliance testing for a subset of APIs’

16. Examples

• New Coldfire MCF5441X NetBurner example
• New Visual Studio solution for Microsoft Azure Sphere Devices
• New NXP Kinetis Design Studio (KDS) example project

17. Additional Product Enhancements

• wolfMQTT (2 releases)
  • Multithreaded support (–enable-mt)
  • Port Updates
    • Visual Studio
    • NXP MQX / RTCS
    • Microchip Harmony
  • Examples
    • New multithread example
    • Azure authentication update
    • Default broker for example
    • New simple client example
    • New non-blocking example

• wolfSSH (3 releases)
  • Client-side public key authentication support
  • Callback function to the check public key sent
  • SFTP client and server support for Windows CE, Micrium 3, MQX 4.2
  • Port updates for Nucleus and Windows
  • Window size optimizations
  • Better automated and fuzz testing!
  • Updates to non blocking support
  • More examples: Renesas CS+, SFTP
  • Support for AES-CTR connections added
  • Improved interoperability and reliability
  • TCP port forwarding
  • Global request message support
  • Client side pseudo terminal support

• wolfTPM (3 releases)
  • Support for Microchip ATTPM20
  • Support for Barebox
  • Support for multiple concurrent process
  • Improvements for chip detection, compatibility and startup performance
  • Better testing with new API unit test framework
  • Support for NV with authentication
  • New wrappers and examples for HMAC/AES, ECDHE and PCR
  • Added examples for TLS client/server
  • Stack use reductions
  • Expanded benchmark support
  • Crypto callback flags for FIPS mode and Symmetric options
  • Support for ST33 TPM2_SetMode command (low-power savings)

• wolfBoot (3 releases)
  • Compile options for Cortex-M0
  • Support for RV32 RISC-V architecture
  • STM32F76x/77x hardware-assisted dual-bank support
  • New HAL support
    • Atmel SAMR21
    • TI CC26X2
    • NXP/Freescale Kinetis SDK
    • RV32 FE310 (SiFive HiFive-1)
    • STM32L0
    • STM32G0
    • STM32F7
    • STM32H7
    • STM32WB55
  • Support for ECC-256 DSA
  • Support for external flash for Update/Swap
  • Anti-rollback protection
  • New Python tools for key generation and signing
  • Ability to move flash-writing functions to RAM
  • Ability for bootloader to update itself
  • TPM2.0 support
    • Integration with wolfTPM
    • Extended STM32 SPI driver to support dual TPM/FLASH communication
    • Tested on STM32 with Infineon 9670
    • RSA 2048 bit digital signature verification

• cURL
  • New option for commercial support

• wolfSSL-py (2 releases)
  • Python3 fixes
  • Native feature detection

• wolfCrypt-py (1 release)
  • Added Ed25519 cipher
  • Added methods for ECC key handling
  • New methods for raw sign/verify on Ed25519
  • RSA new methods: make_key() encode_key()
  • Native feature detection based on wolfSSL build

wolfSSL Top 10 Blog Posts/Technical Announcements

• wolfCrypt as an engine for OpenSSL:
  • https://www.wolfssl.com/wolfcrypt-engine-openssl/
• Differences between TLS 1.2 and TLS 1.3:
  • https://www.wolfssl.com/differences-between-tls-12-and-tls-13-5/
• wolfSSL Integration with cURL:
  • https://www.wolfssl.com/wolfssl-integration-curl/
• wolfSSL FIPS-Ready:
  • https://www.wolfssl.com/wolfssl-fips-ready-2/
• wolfCrypt FIPS New Certification TLS 1.3 FIPS Support
  • https://www.wolfssl.com/tls-1-3-combined-fips-fips-tls13-7/
• TLS 1.3 Performance Analysis(series)
  • https://www.wolfssl.com/tls-1-3-performance-analysis-client-server-authentication/
  • https://www.wolfssl.com/tls-1-3-performance-analysis-throughput/
  • https://www.wolfssl.com/tls-1-3-performance-analysis-client-server-authentication/
  • https://www.wolfssl.com/tls-1-3-performance-analysis-server-pre-generation/
  • https://www.wolfssl.com/tls-1-3-performance-analysis-pre-shared-key-psk/
  • https://www.wolfssl.com/tls-1-3-performance-part-2-full-handshake-2/
  • https://www.wolfssl.com/tls-1-3-performance-analysis-resumption/
• wolfSSL Support for DO-178 DAL A:
  • https://www.wolfssl.com/wolfssl-announces-addition-support-178-dal-2-2-2/
• Remote firmware updates for embedded systems with wolfBoot
  • https://www.wolfssl.com/remote-firmware-updates-embedded-systems/#more-36115
• OpenSSL Compatibility Layer Expansion
  • https://www.wolfssl.com/openssl-compatibility-layer-expansion-2/
• Need a Secure Bootloader Misra-C?
  • https://www.wolfssl.com/need-secure-bootloader-misra-c/

2019 Webinars

1. The Advantages of Using TLS 1.3
2. wolfSSL: TLS 1.3, OpenSSL Comparison
3. Introduction to Secure Boot
4. Migrating from OpenSSL to wolfSSL
5. Security in Avionics

wolfSSL Organizational Growth

• 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 job postings URL (https://uw.joinhandshake.com/jobs/2905385?ref=preview-header-click)
• We have expanded our customer base considerably, are now securing connections for over 1000 products, have partner relationships with over 30 vendors, and are securing well over 2 Billion connections on any given day, worldwide.
• wolfSSL increased its presence in Europe with 2 new members to the team in 2019.
• We got the word out! wolfSSL attended over 62 trade-events (see below). You may ask yourself, why is wolfSSL visiting so many venues? The answer: we are trying to save the world from using bad implementations of Crypto and TLS.

wolfSSL Events and Tradeshows

The wolfSSL team participated in a total of 62 events in 2019, which was up from 50 in 2018 (and 30 in 2017)! As part of these events we were in 44 cities, 18 US states, and 10 countries! The events we participated this last year included:

1. CES (Las Vegas, NV)
2. Smart Factory Expo (Tokyo, Japan)
3. Japan IT Week West (Osaka, Japan)
4. Embedded Tech India Expo (New Delhi, India)
5. FOSDEM (Brussels, Belgium)
6. DistribuTECH (New Orleans, LA)
7. ET Nagoya (Nagoya, Japan)
8. Embedded World 2019 (Nuremberg, Germany)
9. RSA (San Francisco, CA)
10. Medtec Japan 2019 (Tokyo, Japan)
11. MtoM Embedded Systems (Paris, France)
12. Black Hat Asia 2019 (Marina Bay Sands, Singapore)
13. cURL UP (Prague, Czech Republic)
14. NXP Tech Days Chicago (Chicago IL)
15. SIdO (Lyon, France)
16. Japan IT Week Spring (Tokyo, Japan)
17. NXP Tech Days MInneapolis (Minneapolis, MN)
18. IoT Tech Expo Global (London, England)
19. LinuxFest (Bellingham, WA)
20. Satellite 2019 (Washington, DC)
21. NXP Tech Days Seattle (Bellevue, WA)
22. ICMC (Vancouver, BC)
23. Internet of Things World (Santa Clara, CA)
24. ESC Boston (Boston, MA)
25. Wireless IoT (Tokyo, Japan)
26. RTCA (Crystal City, VA)
27. TU Automotive (Zurich, Switzerland)
28. Risc-V Summit (Zurich, Germany)
29. NXP Connects (Santa Clara, CA)
30. Embedded Tech West (Osaka, Japan)
31. IoT TechExpo Europe (Amsterdam, Netherland)
32. Sensors Expo West (San Jose, CA)
33. IoT Security Forum (Tokyo, Japan)
34. Microchip Master 2019 (Phoenix, AZ)
35. Black Hat 2019 (Las Vegas, Nevada)
36. NXP Tech Days (Irvine, CA)
37. Billington International Cyber Security Summit (Washington, DC)
38. RIOT Summit (Helsinki, Finland)
39. NXP Tech Days Boston (Boston, MA)
40. IoT World Asia 2019 (Singapore)
41. ST Dev Con (Santa Clara, CA)
42. FACE Consortium (Dayton, OH)
43. Federal Identity Forum (Tampa, FL)
44. ST Tech Tour (Vancouver, BC)
45. ArmTech Con (San Jose, CA)
46. NXP Tech Days Detroit (Detroit, MI)
47. Japan IT Week Autumn (Chiba Makuhari Messe, Japan
48. ST Tech Tour (Minneapolis, MN)
49. Xilinx XSWG (Longmont, CO)
50. Embedded Conference Scandinavia (Stokholm, Sweden)
51. ETSI/IQC Quantum Safe Cryptography Workshop (Seattle, WA)
52. ST Tech Tour (Boston, MA)
53. NXP Tech Days Toronto (Toronto, Canada)
54. Xilinx XWSG (Herndon, VA)
55. IoT Tech Expo North America (Stanta Clara, CA)
56. Embedded Technology/IoT Technology East (Pacifico Yokohama, Japan)
57. Open Source Conference (Tokyo, Japan)
58. Embedded Software Engineering Kongress (Sindelfingen, Germany)
59. Xilinx XWSG (Munich, Germany)
60. ARM Tech Symposium (Tokyo, Japan)
61. RSC-V Summit (San Jose, CA)
62. Tron Show (Tokyo, Japan)

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

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

wolfSSL 4.4.0 introduces new ChaCha20/Poly1305 API’s for AEAD to allow “chunked” updates of data followed by a final calculation for the authentication tag. This uses the same “Init”, “Update”, “Final” conventions commonly available with our hash algorithms.

New API’s are available by default and can be disabled using: NO_CHACHAPOLY_AEAD_IUF.

wc_ChaCha20Poly1305_CheckTag
wc_ChaCha20Poly1305_Init
wc_ChaCha20Poly1305_UpdateAad
wc_ChaCha20Poly1305_UpdateData
wc_ChaCha20Poly1305_Final
wc_Poly1305_Pad
wc_Poly1305_EncodeSizes

These additions resulted in the following additional enhancements to the wolfSSL library and regression testing:

1. Refactor of functions wc_ChaCha20Poly1305_Encrypt and wc_ChaCha20Poly1305_Decrypt to use the new ChaChaPoly_Aead context and the new init/update/final functions.
2. Refactor of the Poly1305 AEAD / MAC to reduce duplicate code (Footprint Optimizations)
3. Tests for TLS v1.3 interop and ChaCha20/Poly1305 AEAD test vectors.

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

wolfSSL 4.4.0 adds support for building Qt 5.12 and 5.13 against the wolfSSL embedded SSL/TLS library instead of the default OpenSSL backend!  Using wolfSSL as a TLS provider in Qt can have many advantages, depending on application and industry.  Some of these may include:

• Progressive TLS protocol support (up to TLS 1.3)
• Smaller footprint size (wolfSSL is up to 20 times smaller than OpenSSL)
• Extensive testing (wolfSSL is the best-tested SSL/TLS implementation available today)
• Certifications (FIPS 140-2, DO-178C)
• Portability (wolfSSL supports over 30 operating systems)
• Hardware cryptography support
• Commercial support
• Consulting services and training available

To compile wolfSSL for Qt, we have added a new configure option named “–enable-qt“.  To compile Qt with the wolfSSL patch:

1. Follow the Building Qt Guide to download needed Qt dependencies and initialize the Qt repository.
2. Change directories into the qt5 directory and checkout a branch between 5.12-5.13.

$ cd qt5
$ git checkout [branch_name]

3. Apply the wolfSSL Qt patch file to qt5.

$ cd qt5/qtbase
$ patch -p1 < /path/to/wolfssl_qt_src.patch

4. Link to wolfSSL directly by setting the WOLFSSL_LIBS variable.

$ export WOLFSSL_LIBS="-L/path/to/wolf-install/lib -lwolfssl"

5. Configure Qt using the “-wolfssl-linked” option, and add wolfSSL header directories to the include path.

$ ./configure -wolfssl-linked -I/path/to/wolf-install/include/wolfssl -I/path/to/wolf-install/include

6. Build Qt.

$ make

7. Test the build.

$ make test

8. Or, run tests individually:

$ qtbase/tests/auto/network/ssl/qsslcertificate/tst_qsslcertificate
$ qtbase/tests/auto/network/ssl/qasn1element/tst_qasn1element
$ qtbase/tests/auto/network/ssl/qpassworddigestor/tst_qpassworddigestor 
$ qtbase/tests/auto/network/ssl/qsslcipher/tst_qsslcipher
$ qtbase/tests/auto/network/ssl/qssldiffiehellmanparameters/tst_qssldiffiehellmanparameters
$ qtbase/tests/auto/network/ssl/qsslellipticcurve/tst_qsslellipticcurve 
$ qtbase/tests/auto/network/ssl/qsslerror/tst_qsslerror 
$ qtbase/tests/auto/network/ssl/qsslkey/tst_qsslkey 
$ qtbase/tests/auto/network/ssl/qsslsocket/tst_qsslsocket
$ qtbase/tests/auto/network/ssl/qsslsocket_onDemandCertificates_member/tst_qsslsocket_onDemandCertificates_member
$ qtbase/tests/auto/network/ssl/qsslsocket_onDemandCertificates_static/tst_qsslsocket_onDemandCertificates_static

wolfSSL’s port into Qt has not been merged upstream yet, and is currently distributed in patch form.

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

Don’t miss this hot topic! wolfSSL Chris Conlon, Engineering Manager presents:

https://resources.qt.io/videos/ssl-tls-in-qt-introduction-to-wolfssl-wolfssl-qt-virtual-tech-con-2020 

Qt has traditionally used OpenSSL as the provider for SSL/TLS in Qt Network for secure network communications. Qt developers who are looking for a lightweight, progressive, and well-tested SSL/TLS implementation will be happy to learn how Qt can be used with the wolfSSL embedded SSL/TLS library.

wolfSSL provides progressive SSL/TLS protocol support up to TLS 1.3, maintains a minimal memory footprint, and focuses on extensive testing to reduce bugs and vulnerabilities. This session provides an overview of wolfSSL and advantages it brings to Qt developers when used in place of OpenSSL. Viewers will gain insight into how they can build Qt with wolfSSL, learn about the current state of SSL/TLS and the cryptography algorithms it uses, and have a chance to ask the experts about their SSL/TLS questions.

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

wolfSSL Inc is adding support for the SSH-AGENT authentication to wolfSSH. The SSH-AGENT allows one to log in through multiple machines with a single private key on one’s local terminal. A good example is logging onto a test server and then accessing GitHub with git which uses SSH. Git will ask SSH on the test server to sign its handshake message, and that request is forwarded back to your local terminal over the SSH tunnel where the data is signed with your private key. No fuss, no muss. The wolfSSH agent will interoperate with OpenSSH and Dropbear.

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

Did you know that the wolfSSL embedded SSL/TLS library supports the Renesas Trusted Secure IP Driver (TSIP) and has been tested on the Renesas RX65N platform? Using the TSIP driver, wolfSSL can offload supported cryptographic and TLS operations to the underlying Renesas hardware for increased performance.

wolfSSL has been integrated with the following TSIP capabilities:

• TSIP driver open/close
• Random number generation, tested with SP 800-22
• SHA-1 and SHA-256 hash function support
• AES-128-CBC and AES-256-CBC support
• TLS capabilities including:
  • Root CA verification
  • Client and/or Server certificate verification including intermediate certificate verification
  • Support for four TLS cipher suites:
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_128_CBC_SHA256
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_AES_256_CBC_SHA256

The following benchmarks show the performance improvement when using hardware cryptography on the Renesas RX65N through the Renesas TSIP driver.

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

wolfSSL is developing a library to handle the location of where crypto operations run amongst multiple cores. For large systems that have many sign/verify operations happening at once this library would be able to distribute those sign/verify requests based on a user’s input. In addition to managing where the operation runs it can be used to plug in hardware acceleration for handling requests that come in. An example use case would be having 3 cores for generic lower priority operations and saving 1 core that has hardware acceleration for fast, real time responses, that would run high priority operations.

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

The new Automated Cryptographic Validation Protocol is the successor to the two decade old CAVP system from NIST. The ACVP system is intended to alleviate the manual steps of the older process, creating a more efficient and effective method for cryptographic algorithm testing and validation. The project started in 2016 and is currently executing the final Phase 4 objectives. More information from NIST’s website about the ACVP project can be found here:
https://csrc.nist.gov/Projects/Automated-Cryptographic-Validation-Testing

When completed, ACVP will be required for FIPS 140 compliance. wolfSSL is ready, and has already begun submitting algorithms to the NIST Demo server using the wolfACVP client library. Those results can be viewed here.

wolfSSL wants to make your FIPS 140, TLS, embedded, or IoT project successful!

Download the latest release from https://www.wolfssl.com/download/
or from our GitHub page at https://github.com/wolfSSL/wolfssl
While you’re there, show us some love by starring our project!

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

This post was written by Guido Vranken and originally published on his blog (May 13, 2020).

Larry Stefonic of wolfSSL contacted me after he’d noticed my project for fuzzing cryptographic libraries called Cryptofuzz. We agreed that I would write a Cryptofuzz module for wolfSSL.

I activated the wolfSSL module for Cryptofuzz on Google’s OSS-Fuzz, where it has been running 24/7 since. So far, Cryptofuzz has found a total of 8 bugs in wolfCrypt.

Larry and Todd Ouska then asked me if I was interested in writing fuzzers for the broader wolfSSL library. I was commissioned for 80 hours of work.

I started by implementing harnesses for the TLS server and client. Both support 5 different flavors of TLS: TLS 1, 1.1, 1.2, 1.3 and DTLS.

wolfSSL allows you to install your own IO handlers. Once these are in place, each time wolfSSL wants to either read or write some data over the network, these custom handlers are invoked, instead calling recv() and send() directly.

For fuzzing, this is ideal, because fuzzers are best suited to operate on data buffers rather than network sockets. Working with actual sockets in fuzzers is possible, but this tends to be slower and more complex than piping data in and out of the target directly using buffers.

Hence, by using wolfSSL’s IO callbacks, all actual network activity is sidestepped, and the fuzzers can interact directly with the wolfSSL code.

Emulating the network

In the write callback, I embedded some code that specifically checks the outbound data for uninitialized memory. By writing this data to /dev/null, it can be evaluated by valgrind and MemorySanitizer.

Furthermore, I ensured that my IO overloads mimic the behavior of a real network.

On a real network, a connection can be closed unexpectedly, either due to a transmission failure, a man-in-the-middle intervention or as a deliberate hangup by the peer.

It is interesting to explore the library’s behavior in the face of connection issues, as this can activate alternative code paths that normally are not traversed, so this strategy harbors the potential to find bugs that are missed otherwise.

For example, what if wolfSSL wants to read 50 bytes from a socket, but the remote peer sends only 20?

These are situations that are feasible if an attacker were to deliberately impose transfer throttling in their communication with an endpoint running wolfSSL.

Addition and subtraction have shown to pose a challenge in programming, especially when they pertain to array sizes; many buffer overflows and infinite loops in software (not wolfSSL in particular) can be traced back to off-by-one calculations and integer overflows.

Networking software like wolfSSL needs to keep a tally of completed and pending transmissions and in light of this it is a worthwhile experiment to observe what will happen when faced with uncommon socket behavior.

Finding instances of resource exhaustion

Buffer overflows are not the only kind of bug software can suffer from.

For example, it would be unfortunate if an attacker could bring down a TLS server by sending a small, crafted packet.

Fuzzing can be helpful in finding denial of service bugs. Normally, fuzzers use code coverage as a feedback signal. By instead using the branch count or the peak memory usage as a signal, the fuzzer will tend to find slow inputs (many branches taken means a long execution time) or inputs that consume a lot of memory, respectively.

Several years ago I implemented some modifications to libFuzzer which allow me to easily implement fuzzers that find denial-of-service bugs. For my engagement with wolfSSL, I applied these techniques to each fuzzer that I wrote. I ended up providing three binaries per fuzzer:

• a generic one that seeks to find memory bugs, using code coverage as a signal
• one that tries to find slow inputs by using the branch count as a signal
• one that finds inputs resulting in excessive heap allocation

Emulating allocation failures

Using wolfSSL_SetAllocators(), wolfSSL allows you to replace its default allocation functions. This opens up interesting possibilities for finding certain bugs.

One thing I did in my custom allocator was to return an invalid pointer for a malloc() or realloc() call requesting 0 bytes. This way, if wolfSSL would try to dereference this pointer, a segmentation fault will occur.

This special code is needed because even AddressSanitizer will not detect access to a 0-byte allocated region, but it is important to test for, as such behavior can lead to real crashes on systems like OpenBSD, which intentionally return an invalid pointer from malloc(0), just like my code does.

Another possibility of implementing your own memory allocator is that it can be designed to fail sometimes.

On most desktop systems, malloc() always succeeds, but that may not be the case universally, especially not on resource-constrained systems which cannot resort to page swapping for acquiring additional memory.

Allocation failures activate code paths which are normally not accounted for by unit tests. I implemented this behavior for all fuzzers I wrote for wolfSSL.

In the TLS-specific code, 5 bugs were found.

Fuzzing auxiliary code

TLS is large and complex, and it can take fuzzers a while to traverse all its code paths, so in the interest of efficiency, I wrote several additional fuzzers specifically aimed at subsets of the library, like X509 certificate parsing (historically a wellspring of bugs across implementations), OCSP request and response handling (for which a subset of HTTP is implemented) and utility functions like base64 and base16 coders.

This approach found 9 additional bugs.

Testing the bignum library

wolfSSL comes with a bignum library that it uses for asymmetric cryptography. Because it is imperative that computations with bignums are sound, I took a project of mine called bignum-fuzzer (which has also found security bugs in other bignum libraries, like OpenSSL’s CVE-2019-1551) and appropriated it for use with wolfSSL. It is not only able to find memory bugs, but also incorrect calculation results.

I set out to test the following sub-libraries in wolfSSL:

• Normal math
• Single-precision math (–enable-sp)
• Fastmath (–enable-fastmath)

5 instances of incorrect calculations were found. The other bugs involved invalid memory access and hangs.

wolfSSH

In addition to wolfSSL and wolfCrypt, I also spent some time looking at wolfSSH, which is the company’s SSH library offering.

In this component I uncovered 7 memory bugs, 1 memory leak and 1 crash bug.

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