Month: July 2023

We are excited to announce that wolfSSL has added support for the hitch project!
Hitch is a scalable TLS/SSL proxy developed by Varnish software. It’s designed to handle tens of thousands of connections efficiently on multicore machines. wolfSSL has recently added support for hitch as part of our open source support efforts. This means you get to use all of the features of wolfSSL like full TLS 1.3 support, FIPS certification and QUIC support with hitch.

To build hitch with the wolfSSL lightweight SSL/TLS library, you will currently need to use the master branch of wolfSSL, and our patch for hitch found here: https://github.com/wolfSSL/osp/tree/master/hitch

First, build wolfSSL as follows:

./autogen.sh
./configure --enable-hitch
make
sudo make install

Then, apply the hitch patch from above and build hitch as follows:

patch -p1 < /hitch/hitch_1.7.3.patch
autoreconf -ivf
./configure --with-wolfssl
make

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

Please join us for an informative webinar about the release of wolfSSL’s SM cipher implementations.

As many people know, Chinese government regulators are now mandating use of SM2, SM3 and SM4 in critical systems, including automobiles, avionics, power systems, and communication systems. Since many of our customers are multi-nationals that do business in China, they have been requesting the addition of these algorithms in wolfSSL products.

We recently released our supported versions of SM2, SM3, and SM4, with the intention to release the ZUC stream cipher at some point this year to completely satisfy SM9. We are also in contact with labs regarding support of OSCCA certification at some point in the future. This is really great news for our customers in Chinese markets!

For those readers considering using wolfSSL products, here’s some additional notes:

1. The SM Ciphers are fully supported in wolfSSL’s TLS 1.3 and DTLS 1.3 implementations.
2. wolfSSH, wolfBoot and our other products will support ShangMi ciphers.
3. ARM, Intel, and RiscV assembly is in the works for our SM implementations for maximum performance
4. We support bare metal for SM2, SM3, and SM4.
5. We have maximized performance and minimized size, so the ShangMi algorithms will work well for embedded systems use cases on a wide variety of microcontrollers (MCU’s). They will be available for all of the MCU silicon that we currently support, including STM32, NXP i.MX, RISC-V, Renesas RA, RX, and Synergy, Nordic NRF32, Microchip PIC32, Infineon Aurix, TI MSP, and many others.
6. Our GPLv2 versions of the SM ciphers are available on GitHub and for download here: https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src

Commercially licensed versions are available.

Register now to reserve your seat!

As always, our webinars will include Q&A sessions throughout the webinar.

If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

We have with the merge of our PR#6400 integrated the ARIA cipher for customers who sell into the South Korean market. The ARIA cipher has been adopted as the national standard in South Korea in various software and hardware products. We now have support for ARIA_128 and ARIA_256 in GCM mode. This pull request also contains crypto callback usage of the MagicCrypto library (from Dream Security) for signature, hashing and key agreement.

To get started, simply place the MagicCrypto library and header files in a folder called MagicCrypto in the root of the wolfSSL repository. To build, run the following:

./configure –enable-aria –enable-cryptocb –enable-all && make all

The following is an example using our own sample programs. To start a daemon server run:

./examples/server/server -i -x -v 3 -A ./certs/ca-ecc-cert.pem -k ./certs/ecc-key.pem -c ./certs/intermediate/server-chain-ecc.pem -V -l ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ECDSA-ARIA256-GCM-SHA384

The client can be run as follows:

./examples/client/client -v 3 -l ECDHE-ECDSA-ARIA128-GCM-SHA256 -A ./certs/ca-ecc-cert.pem -k ./certs/ecc-client-key.pem -c ./certs/intermediate/client-chain-ecc.pem -C

If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL is excited to announce we are adding support for the LMS and HSS post-quantum stateful hash-based signature schemes to our wolfCrypt embedded crypto engine. This will be achieved by experimental integration with the hash-sigs LMS/HSS library, similar to our previous libOQS integration.

Leighton-Micali Signatures (LMS), and its multi-tree variant, the Hierarchical Signature System (HSS), is a post-quantum, stateful hash-based signature scheme. It is noted for having small public and private keys, and fast signing and verifying. Its signature sizes are larger, but are tunable via its Winternitz parameter. Furthermore, stateful hash-based signature schemes are founded on the security of their underlying hash functions and Merkle trees (typically implemented with SHA-256), which are not expected to be broken by the advent of cryptographically-relevant quantum computers. For these reasons they have been recommended by NIST SP 800-208 and the NSA’s CNSA 2.0 suite.

Because of their unique strengths and characteristics, and NIST and NSA backing, LMS and HSS are of particular interest for offline firmware authentication and signature verification, especially on embedded or constrained systems that are expected to have a long operational lifetime and thus need to be resilient against a quantum-enabled future. Furthermore, the CNSA 2.0 timeline has specified that stateful hash-based signature schemes should be used exclusively by 2030, and adoption should begin immediately. In fact, adoption of LMS is the earliest requirement in the CNSA 2.0 suite timeline.

If you’re curious and want to learn more, see the following pull request links:

• https://github.com/wolfSSL/wolfssl/pull/6564
• https://github.com/wolfSSL/wolfssl-examples/pull/390
• https://github.com/wolfSSL/documentation/pull/101

If the podcast sparks some further questions that you have, you can reach out to facts@wolfssl.com, or call us at +1 425 245 8247 to continue the conversation with us here at wolfSSL!

wolfSSL has tested and provides support for a range of public key cryptographic algorithms on the Microchip Trust Anchor (TA100) – Automotive Grade security IC. This includes RSA with 2048-bit key size as well as ECC with 256 key size, supporting both NIST Prime and Brainpool curves. It’s worth noting that the TA100 is a more recent addition compared to the previously supported ATECC508 or ATECC608. To enable this specific configuration, you can use either the Autoconf option by running “./configure –enable-microchip=100” or set the preprocessor define CFLAGS=”-DWOLFSSL_MICROCHIP_AT100″.

The TA100 is a secure element from Microchip portfolio of CryptoAutomotive™ security ICs.The module offers various security features such as code authentication (secure boot), MAC generation for message authentication, support for secure firmware updates, authentication for Qi 1.3 wireless charging, and multiple key management protocols including TLS. It is a highly secure solution offering features such as key agreement and sign-verify authentication. It supports various asymmetric, symmetric, and hashing security protocols to ensure robust protection.

The TA100 is compatible with a range of microprocessors (MPUs) and microcontrollers (MCUs), including our AVR® and ARM® processor-based MCUs and MPUs. Its versatility allows for seamless integration into different system architectures.

For more details on TA100, see https://www.microchip.com/en-us/product/ta100

If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247

wolfSSH can make use of X.509 certificates when verifying the peer! Both on the client side and on the server side. The implementation follows RFC 6187 and adds x509v3-ecdsa-sha2-* and x509v3-ssh-rsa to the key exchange algorithms. Instead of the public key, the whole certificate is passed along during authentication and then verified by the peer using a CA or an authorized key file. Having the option to verify the client’s certificate using a CA allows for any clients with a valid, signed certificate, to connect without needing to update an authorized key file. This includes the support for verifying certificate chains!

To build wolfSSH with X.509 support the enable option (–enable-certs) can be used. For example “./configure –enable-certs”. One thing to note is that wolfSSH also has FPKI support. If the wolfSSL being linked to has been built with FPKI support (happens with –enable-all) then the macro WOLFSSH_NO_FPKI can be used to turn off the FPKI certificate checks in wolfSSH. (–enable-certs CPPFLAGS=”-DWOLFSSH_NO_FPKI”). The example echoserver has some X.509 support but if wanting to leverage X.509 verification in multiple parts of the SSH handshake then the wolfSSHd application should be used on the server side, enabled with (–enable-sshd) or the wolfSSH library API themselves in your own application.

This is an example of what X509 certificate use looks like with wolfSSH!

Configure wolfSSH library:

./configure --enable-sshd --enable-certs CPPFLAGS=-DWOLFSSH_NO_FPKI && make 

Create sshd config file that reads in certificates:

cat sshd_config

Port 22222
Protocol 2
LoginGraceTime 600

TrustedUserCAKeys /path/to/wolfssh/keys/ca-cert-ecc.pem
HostKey /path/to/wolfssh/keys/server-key.pem 
HostCertificate /path/to/wolfssh/keys/server-cert.pem

Run wolfSSHd application:

./apps/wolfsshd/wolfsshd -D -f ./sshd_config

Connect to wolfSSHd using the wolfSSH client:

./examples/client/client -u fred -i ./keys/fred-key.der -J ./keys/fred-cert.der -A ./keys/ca-cert-ecc.der

Note that the wolfSSHd application will check that ‘fred’ is a valid user on the system and the client will check the IP of the host.

The example certificate has a host IP set to 127.0.0.1 :

server-cert.pem:

            X509v3 Subject Alternative Name: 
                DNS:example, IP Address:127.0.0.1

The example user certificate fred-cert.der specifies the user name “fred” in a UPN (User Principal Name) extension. This is an Other type subject alternative name which has the format <user>@<domain>. Having the user name set here in the certificate binds the certificate to the user “fred” and makes it so that it can not be used by other user names.

For questions about X.509 use with wolfSSH contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Looking to add SSL/TLS to your Keil project?

The wolfSSL embedded SSL/TLS library is a lightweight SSL/TLS library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments – primarily because of its small size, speed, and feature set. For Keil MDK and uVision users we provide a CMSIS pack that enables them to utilize the library on their platform. The pack is integrated into the Keil MDK and includes wolfCrypt and TLS examples which allow for quick adoption of our library into embedded targets.

It’s now possible to compile wolfSSL with Keil’s v6 compiler. We tested the wolfSSL v5.6.3 Keil pack with the v6.19 compiler and were able to get it building without making a single code change.

Follow the guide below to try the pack out on your target.

Guide: https://github.com/wolfSSL/wolfssl/blob/master/IDE/MDK5-ARM/README.md

For questions, comments or suggestions please email facts@wolfssl.com or call us at +1 425 245 8247.

wolfSSL has significant improvements on how we parse and encode ASN.1 data like certificates and keys.

Parsing X.509 certificates, and RSA and ECC keys is important to do correctly. In fact, vulnerabilities come from not checking the validity of the encoding correctly! Reading outside the encoded data can result in crashing of your application or device.

To simplify the code and to make it as safe as possible, templates have been introduced that describe the format of data to be parsed or encoded. Using common functions that validity check the ASN.1 structure on parsing means fewer places for bugs. It also means less code!

Extensive testing has been performed on the new code including external fuzz testing. We are now confident the new code works just as well as the original implementation.

When using configure.ac to produce a Makefile, the new template code is compiled by default. For embedded customers, you will need to define: WOLFSSL_ASN_TEMPLATE.

To use the original code, either configure with —enable-asn=original or remove the WOLFSSL_ASN_TEMPLATE define. This code will be removed in future releases for reasons of maintenance so we encourage you to try out the new template code.

If you have questions about optimizing wolfSSL please contact us at facts@wolfssl.com or or call us at +1 425 245 8247.

The size of software builds can often be a concern for developers, particularly in embedded systems or other resource-constrained environments. Recently, a change was made to the wolfSSL library that has resulted in smaller build sizes when used with the popular cURL library. 

The change in question was made in a pull request to the wolfSSL library on GitHub, specifically pull request #6320. Which removes the need for using:

–enable-opensslextra 

and instead only requires:

–enable-opensslextra=x509small CPPFLAGS=-DHAVE_CURL  

This compiles out a lot of compatibility layer functionality (used for ripping out and replacing OpenSSL) that is not needed by cURL. Mainly this change is to reduce the code footprint size of the wolfSSL library. This change can be especially beneficial in resource-constrained environments where smaller builds are crucial.

If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247.