Category: Uncategorized

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.

If you have any questions or run into any issues, 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

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 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 any questions or run into any issues, contact us at facts@wolfssl.com, 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 any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

The CAN bus is becoming ubiquitous in vehicle and factory automation the world over. The devices it connects are becoming more powerful and more connected to the outside world. As such security for the devices on this bus is becoming more and more important.

In a previous post we mentioned that we have provided an example of how to use wolfSSL on the CAN bus to encrypt connections between devices. But that is only one part of the equation, filtering traffic so that only expected packets make it through is another required part.

wolfSentry is already a very powerful IDS that can run on lightweight embedded devices. Now we have an example of how to use this on the CAN bus.

The example is based on our previous wolfSSL CAN bus example, so it uses TLS 1.3 for the message payload, but it also uses wolfSentry to filter the target and source addresses for ISO-TP’s “Normal fixed addressing”. This addressing scheme is compatible with many other CAN bus standards.

You can find this example in the wolfSentry codebase on GitHub (https://github.com/LinuxJedi/wolfsentry/tree/can-bus/examples/Linux-CANbus). It uses the Linux kernel SocketCAN functionality but can be easily adapted to work with other CAN bus implementations.

In addition to the above we have also created our own ISO-TP layer which is part of wolfSSL. This cuts down the implementation size significantly as you just need to hook in the CAN bus send and receive functionality. The wolfSSL example (and therefore the wolfSentry example) has been updated to use this new implementation.

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

Exciting News! Join us for an informative webinar hosted by Chris Conlon from wolfSSL, and Guillaume Crinon and Ellen Boehm from KEYFACTOR!

Join us on 7/27/2023 for an exciting and informative webinar! We are delighted to bring together two innovative companies, wolfSSL and KEYFACTOR. It is your chance to discover how wolfSSL and KEYFACTOR can empower your security solutions and enhance your development process! Our experts are eager to share their knowledge and answer your questions! Don’t miss your opportunity to connect virtually with our experts!

As a device manufacturer, you understand the critical role of hardware flexibility in implementing robust security measures. Throughout the webinar, we will delve into the importance of creating hardware that can adapt and evolve over time, from the initial stages of product development to its useful life over several years. We will also explore the significance of anticipating the emergence of upcoming standards, regulations, and technology, and how your hardware design can comply with future requirements.

• Don’t miss this exceptional opportunity to connect virtually with our experts and gain invaluable insights that will empower your security solutions as a device manufacturer. Take a step closer to a more secure and successful future for your products!

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

Are you looking for an excellent Windows SSHd service? wolfSSL is adding Windows support for our SSHd implementation! This allows for running wolfSSHd as a service in Windows 10 and newer environments, handling SFTP, SCP and shell connections. 

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

On i.MX8 devices there is a SECO (https://www.nxp.com/docs/en/application-note/AN12906.pdf) hardware module available for heightened security. This module handles AES operations, limited ECC operations, key storage, and provides a RNG. wolfSSL has long since been expanded to make use of the SECO where possible. A full step by step guide for building wolfSSL and setting up Linux to be used with SECO can be found in the recent document addition here: (https://www.wolfssl.com/documentation/manuals/wolfssl/chapter02.html#building-for-nxp-caam).

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

wolfBoot is now ported and available for intel Tiger Lake systems! wolfBoot leverages wolfCrypt DO-178 for its cryptographic functionality. The initial operating system targeted for boot is Green Hills Integrity, but we expect to add support for DDCI’s DEOS, SYSGO, Wind River’s VxWorks, and LynxOS over time. Currently, wolfCrypt is in service or “in the air” protecting avionic systems and has completed multiple SOI audit cycles. wolfBoot’s current status is that it is ported and tested for Tiger Lake, fully trimmed, and ready to enter the SOI process this year.

You can download the non DO-178C source code and documentation from our download page, or clone the repository from github. If you have any questions, comments or suggestions, send us an email at facts@wolfssl.com, or call us at +1 425 245 8247.

A quite unique feature of wolfBoot is the possibility to update the firmware using signed incremental updates.

The mechanism relies on a delta algorithm that produces a small update package. Instead of transferring the entire binary image of the firmware update, incremental updates only contain the binary difference with the previous version.

Distributing a new version of the firmware, even if it contains only a few modifications to the existing code, currently requires to transfer, verify and install the complete firmware image. Using incremental updates instead will result in a very small package, only containing the binary difference from the current firmware version. The package will still be signed, authenticated and checked for integrity using wolfBoot built-in image verification. WolfBoot will apply the binary difference in place on the BOOT partition in the FLASH memory.

There are multiple advantages of opting for such a mechanism: the firmware image, normally very large, must be transferred to the target system. On small-bandwidth networks such as LP-WAN, typically the bit-rate is too low to consider full updates, while a delta-based, incremental mechanism would make it usable. Moreover, from the point of view of non-volatile memory usage, it will no longer be needed to reserve two partitions of the same size by dividing the usable FLASH memory. The update partition may become much smaller since it will only be used to store the delta, freeing up space to allow a larger firmware to run in the BOOT partition.

At wolfSSL we are constantly adding new features and expanding the possibilities to secure your embedded systems. Let us know what you think about incremental updates in wolfBoot, and give us feedback about what you would like to see next in our products, by contacting us at facts@wolfssl.com, or call us at +1 425 245 8247