Job Posting: Embedded Systems Software Engineer

wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. wolfSSL develops, markets and sells the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, and wolfSSH.

Job Description:

Currently, we are seeking to add a senior level C software engineer with 5-10 years experience interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.  Experience with hardware-based cryptography is a plus.

Operating environments of particular interest to us include Linux, Windows, Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments such as Android and iOS is also a plus, but not required.

Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.

How To Apply

To apply or discuss, please send your resume and cover letter to resumes@wolfssl.com

AES-SIV Added to wolfCrypt

wolfSSL is happy to announce that we’ve recently added support for AES-SIV (synthetic initialization vector). Our implementation is based on the specification in RFC 5297. SIV mode is designed to be resistant to security degradation from accidental nonce reuse. Notably, AES-SIV is a mandatory AEAD algorithm for network time protocol (NTP) servers supporting network time security (NTS), per RFC 8915. We added AES-SIV to support our chrony 4.1 port, which is one of the only major NTP implementations that currently supports NTS.

Please reach out to facts@wolfssl.com if you have any questions about AES-SIV or our chrony port!

Math Library Improvements in wolfSSL 5.1.1

Significant improvements to the C-only implementation of Single Precision math for P-256 and P-384 have been made in wolfSSL 5.1.1. Previously the Montgomery reduction implementation was performed generically. This function makes up a significant proportion of the time to perform ECC operations. By adding an optimised implementation the performance of the 32-bit C code improved by up to 80%! The 64-bit C code saw similar improvements.

Also the Aarch64 implementation of P-384 got an optimised version of the Montgomery reduction operation too. This improved its performance by up to 150%!

From fuzz testing, it was found that the implementation finding the square root modulo a prime (used in uncompressing a point) was not handling a value of zero correctly and resulted in the function not returning. This corner case will not occur with valid points. Compressed points are not recommended and disabled by default, but the fix was required to protect against potential attacks.

Bug fixes for the SP general math library were made for 5.1.1. These included fixes to sanity check values passed to sp_gcd (used in but not affecting RSA key generation) and better checking of maximum size of numbers when dividing. Also, when compiling for MIPS 32-bit, some compilers didn’t like the register names ‘$lo’ and ‘$hi’. These have been changed to ‘%lo’ and ‘%hi’ respectively.

The Single Precision code was also fixed around modular exponentiation. When the modulus is even or the exponent is 0 then we now error out. These are not use cases that are hit in normal operation.

A couple of bug fixes were made in the TFM implementation of our math library as well. An improved Montgomery reduction for Intel x86_64 was added in 5.0.0 and fixed to work reliably in this release. Also some out of memory error handling was improved around this same function.

A full list of what was changed can be found in the wolfSSL ChangeLog (https://www.wolfssl.com/docs/wolfssl-changelog/).
For questions about wolfSSL or about the latest release contact us at facts@wolfssl.com

wolfSSL Support for DO-178 DAL A

wolfSSL is adding support for complete RTCA DO-178C level A certification! wolfSSL will offer DO-178 wolfCrypt as a commercial off -the-shelf (COTS) solution for connected avionics applications. Adherence to DO-178C level A will be supported through the first wolfCrypt COTS DO-178C certification kit release that includes traceable artifacts for the following encryption algorithms:

  • SHA-256 for message digest.
  • AES for encryption and decryption.
  • RSA to sign and verify a message.
  • chacha20_poly1305 for authenticated encryption and decryption.
  • ECC to sign, verify and share secrets.
  • HMAC  for keyed-hashing for message authentication.

The primary goal of this initial release is to provide the proper cryptographic underpinnings for secure boot and secure firmware update in commercial and military avionics. wolfSSL brings trusted, military-grade security to connected commercial and military aircraft. Avionics developers now have a flexible, compact, economical, high-performance COTS solution for quickly delivering enhanced, secure communications that can be readily certified to DO-178. In addition, any of the FIPS 140-2 validated crypto algorithms can be used in DO-178 mode for combined FIPS 140-2/DO-178 consumption. The wolfCrypt cryptography library has been FIPS 140-2 validated (Certificate’s #2425 and #3389). For additional information, contact us at fips@wolfssl.com

Optimization Support

We understand that securely rebooting avionic systems has rigorous performance requirements. As such, we’re here to help with cryptographic performance optimizations through our services organization. 

Release Plan

  • Basic crypto for secure boot and secure firmware updates – Available Now!
  • wolfBoot Secure Boot – Q1, 2022
  • wolfSSL – Q2, 2022
  • wolfDTLS – Q2, 2022

To download and view the most recent version of wolfSSL, the wolfSSL GitHub repository can be cloned from here: https://github.com/wolfssl/wolfssl.git, and the most recent stable release can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/.

For more information, please visit the wolfSSL DO-178 product page: https://www.wolfssl.com/wolfssl-support-178-dal/.

Questions? Contact us at facts@wolfssl.com.

Post-Quantum Goodies in wolfSSL 5.1.1: FALCON

This is a quote from a message posted by Dustin Moody of NIST on the NIST PQC Forum at https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/fvnhyQ25jUg :

“Yes - the 3rd round will shortly be ending.  NIST is actively writing the 3rd Round report which will 
explain our rationale for which algorithms we will standardize.   We hope to be able to announce the 
results and report not later than the end of March.”

Dustin Moody, Feb. 9, 2022

So, we can expect some news from NIST in a month or so. With this in mind, we thought this might also be a good time to talk about the FALCON Signature Scheme integration in the wolfSSL v5.1.1 release and some of the other work we have done around post-quantum cryptography.

The FALCON Signature Scheme is a post-quantum algorithm that is a finalist of round 3 of the NIST PQC competition. It shows much promise in that while its artifacts are large and key generation and signing are a bit slower than currently standardized algorithms, signature verification times are much faster which bodes well for IoT and constrained devices.  You can compare the speed in our benchmarking data that can be found in Appendix G of our wolfSSL Manual: https://www.wolfssl.com/documentation/wolfSSL-Manual.pdf

The good news for our customers that want to experiment with FALCON is that it couldn’t be easier! All you need to do is build liboqs, rebuild wolfSSL and add the –with-liboqs flag.  If you built your application to statically link with wolfSSL, you will need to rebuild your application.  If you dynamically link, you do not need to rebuild.  All you have to do now is  swap out your certificates with FALCON certificates!  No code changes are required for your application. You can find instructions and a script for generating a  FALCON certificate chain here: https://github.com/wolfSSL/wolfssl-examples/tree/master/pq

For customers who want to see post-quantum algorithms working in a real world use-case, we have instructions for you to build a quantum-safe apache web server and curl web client. All you need to do is follow the instructions here: https://github.com/wolfSSL/osp/blob/master/apache-httpd/README_post_quantum.md

Finally, just a few words regarding motivation.  Most people understand the harvest and decrypt threat model and thus see the urgency for moving to post-quantum key establishment. However, seeing the motivation for signature schemes might be harder. Suppose you are deploying authentication algorithms on devices that have long lifetimes and are hard to update.  A good example of this might be firmware for industrial machinery or cars.  If the lifetime of your deployment exceeds the time to a cryptographically relevant quantum computer, then you should probably consider experimenting to understand the impact of post-quantum algorithms sooner rather than later.

A full list of what was changed can be found in the wolfSSL ChangeLog (https://www.wolfssl.com/docs/wolfssl-changelog/).
For questions about wolfSSL or about the latest release contact us at facts@wolfssl.com

wolfCrypt and FIPS 140-3

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 want an up to date cryptography library and TLS stack that is ready for FIPS 140-3, contact us at fips@wolfssl.com.
Love it? Star wolfSSL on GitHub!

Deprecation of FIPS v1

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.  Customers who will be impacted by the removal of this feature for any reason are encouraged to get in touch with their account representative or email us at .

Top 10 wolfSSL Library Configurations

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.

Task Configure Flag(s) Details
Get Ready for Your First FIPS Customer –enable-fips=ready You will need to have a fips-ready bundle which is available as both an open source code bundle or under a proprietary license.
Become DO-178 Compliant –enable-sp-math We have taken ECC in sp_c32.c in the SP-Math Library through DO-178C certification.
Make Your Application Secure from Side-Channel Attacks –enable-sp-math –enable-sp-math-all

CFLAGS=”WOLFSSL_SP_CACHE_RESISTANT”

or

–enable-fastmath –enable-harden 

Our SP-Math Library is always timing resistant and runs private key operations in constant time.  Our Fast Math Library can be made timing resistant by enabling the hardened build.
Reduce Your Stack Usage –enable-smallstack and –enable-smallstackcache Allocating memory on the heap will be favored over the stack.
Reduce Your Heap Usage –enable-static-memory All memory that wolfSSL LIbrary allocates will be on the stack as local variables.
Reduce Your Code Size –enable-sha3=small –enable-aesgcm=small –enable-lowresource

CFLAGS=”-DNO_ERROR_STRINGS -DNO_INLINE -DCURVED25519_SMALL -DUSE_SLOW_SHA” -DUSE_SLOW_SHA256 -DUSE_SLOW_SHA612”

This will come at a cost of algorithm speed and memory usage.
Make a Really Small PSK-Only wolfSSL Library –enable-leanpsk PSK stands for pre-shared key. Approximate build size for wolfSSL on an embedded system with this enabled is 21kB.
Make a Really Small Client-Only wolfSSL Library –enable-leantls This produces a small footprint TLS client that supports TLS 1.2 client only, ECC256, AES128 and SHA256.
Use Only wolfCrypt –enable-cryptonly This enables a wolfCrypt-only build, greatly reducing the size. No TLS, no SSL.
Figure Out What is Going on Under the Hood –enable-debug This will build the wolfSSL Library with debug symbols so you can use your debugger to step through the code as it executes.  Also, if you call wolfSSL_Debugging_ON() lots of debugging messages will be printed to stderr.

 

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? You can get in touch with your sales representative or email us at facts@wolfssl.com to start a consulting session with the expert engineers on the wolfSSL Inc. team.

wolfSSL provider support for PKCS11

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

For questions please email facts@wolfssl.com

wolfCLU ‘ca’ Command Added

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).

For questions about wolfCLU contact us at facts@wolfssl.com

Posts navigation

1 2 3